73723115 cp13 motorola umts

CHAPTER 2NETWORK ARCHITECTURE

CHAPTER 3NETWORK SERVICES

CHAPTER 4UMTS PROTOCOLS

CHAPTER 5DATA FLOW AND

TERRESTRIAL INTERFACES

CHAPTER 1INTRODUCTION

CHAPTER 7THE PHYSICAL LAYER

CHAPTER 8RRM FUNCTIONS

ANNEXE A GLOSSARYCHAPTER 6 W-CDMA THEORY

TRAINING MANUAL

CP13

UMTS OVERVIEW

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

VERSION1 REV 7

TR

AIN

ING

MA

NU

AL

CP13FOR TRAINING

PURPOSES ONLY–

THIS MANUALWILL NOT BE

UPDATED

VE

RS

ION

1 RE

V 7

UM

TS

OV

ER

VIE

W

�MOTOROLA LTD. 2003 CP13: UMTS Overview


i

GSM

CP13UMTS Overview

� Motorola 2002All Rights ReservedPrinted in the UK.

Version 1 Rev 7

�MOTOROLA LTD. 2003CP13: UMTS Overview


ii

Copyrights, notices and trademarks

CopyrightsThe Motorola products described in this document may include copyrighted Motorola computerprograms stored in semiconductor memories or other media. Laws in the United States and othercountries preserve for Motorola certain exclusive rights for copyright computer programs, including theexclusive right to copy or reproduce in any form the copyright computer program. Accordingly, anycopyright Motorola computer programs contained in the Motorola products described in this documentmay 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 byimplication, estoppel or otherwise, any license under the copyrights, patents or patent applications ofMotorola, except for the rights that arise by operation of law in the sale of a product.

RestrictionsThe software described in this document is the property of Motorola. It is furnished under a licenseagreement 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 bylaw. No part of the software or documentation may be reproduced, transmitted, transcribed, storedin a retrieval system, or translated into any language or computer language, in any form or by anymeans, without prior written permission of Motorola.

AccuracyWhile reasonable efforts have been made to assure the accuracy of this document, Motorolaassumes no liability resulting from any inaccuracies or omissions in this document, or from the useof the information obtained herein. Motorola reserves the right to make changes to any productsdescribed herein to improve reliability, function, or design, and reserves the right to revise thisdocument and to make changes from time to time in content hereof with no obligation to notify anyperson of revisions or changes. Motorola does not assume any liability arising out of the applicationor use of any product or circuit described herein; neither does it convey license under its patentrights of others.

Trademarks

and MOTOROLA are registered trademarks of Motorola Inc. Intelligence Everywhere, M-Cell and Taskfinder are trademarks of Motorola Inc.All other brands and corporate names are trademarks of their respective owners.

.

.

.

Version 1 Rev 7



iii

Contents

General information 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Reporting safety issues 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Warnings and cautions 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General warnings 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General cautions 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Devices sensitive to static 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 1Introduction 1–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives 1–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UMTS Services 1–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IMT-2000 Roadmap 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IMT-2000 Objectives 1–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Research and Proposal 1–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proposals 1–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Standardisation (1998) 1–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Harmonisation (1999) 1–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CDMA-2000 1–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multi-carrier 1–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Direct-Sequence (DS) 1–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permitted Carrier Combinations 1–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cdma2000 Evolution 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UMTS Terrestrial Radio Access (UTRA) 1–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FDD Mode 1–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UTRA TDD Mode 1–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

World-wide Spectrum Allocation for IMT-2000 1–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WARC 92 1–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WARC 2000 1–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

European Frequency Allocations 1–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Licence Allocation in the UK 1–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 2Network Architecture 2–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives 2–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UMTS Domains 2–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UMTS Architecture – Release 1999 2–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Core Network (CN) Entities 2–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Access Network (AN) Entities 2–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Mobile Station (MS) 2–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UMTS Network – Release 1999 2–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Entities of the CN-CS Domain 2–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Entities Common to the CS and PS Domains 2–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Overview of GSN3/USP1 architecture 2–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Components of the GSN Complex 2–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



iv

Packet switch core network components 2–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Motorola C–SGSN 2–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–SGSN Functionality 2–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

GGSN 2–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GGSN functionality 2–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Motorola Charging Gateway (CGW) 2–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Charging Gateway functionality 2–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Communications Hub 2–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CommHub functionality 2–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

DNS/NTP Server 2–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DNS/NTP Server functionality 2–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IP Backbone 2–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Border Gateway 2–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Firewall 2–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SS7 Nodes 2–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Home Location Register (HLR) / Authentication Centre (AuC) 2–32. . . . . . . . . . . . . . . Mobile Switching Centre (MSC) / Visitor Location Register (VLR) 2–32. . . . . . . . . . . . SMS Gateway MSC (SMS–GMSC) / SMS Inter–working MSC (SMS–IWMSC) 2–32CAMEL GSM SCF / P–SCP 2–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Equipment Identity Register (EIR) 2–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Nodes for value added services 2–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lawful Intercept Administrative Node (LIAN) 2–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gateway Mobile Location Centre (GMLC) 2–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

GPRS/UMTS Interfaces 2–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UMTS Terrestrial Radio Access Network (UTRAN) 2–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UTRAN Functions 2–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Radio network Controller (RNC) 2–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling Radio Network Controller (CRNC) 2–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Serving Radio Network Controller (SRNC) 2–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Drift Radio Network Controller (DRNC) 2–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Node B 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wideband Digital Modem (WDM) 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Wideband Transceiver (WBX) 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Linear Power Amplifier (LPA) 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

User Equipment (UE) 2–48. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction to User Equipment 2–48. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UE Architecture 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrated Circuit (IC) Card 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminal Equipment (TE) 2–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile Equipment (ME) 2–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MT Functionality 2–54. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Network Evolution 2–56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Product evolution 2–56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Servers 2–58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 3Network Services 3–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives 3–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



v

Introduction to Network Services 3–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Classification of Services 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multimedia services: 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supplementary services 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Teleservices 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bearer Services 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Capabilities 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Description of Services 3–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Transfer 3–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Traffic characteristics 3–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Quality 3–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Supported Bit Rates 3–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Quality of Service 3–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

QoS Attributes 3–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Security Architecture 3–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Security and Privacy 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User authentication: 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network authentication: 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Confidentiality 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data integrity 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile equipment identification 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Authentication and Key Agreement 3–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distribution of authentication data from HE to SN 3–22. . . . . . . . . . . . . . . . . . . . . . . . . . Authentication and Key Agreement 3–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ciphering Algorithms 3–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F8 3–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F9 3–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Generation of Authentication Vectors/Tokens 3–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SQN and RAND 3–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication Key Management Field 3–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Algorithms f1 –f5 3–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AUTN and AV 3–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

USIM Authentication Function 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Retrieval of SQN 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Computation of X-MAC 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verification of SQN 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Computation of CK and IK 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Authentication Response 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Access Link Data Integrity 3–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data integrity protection method 3–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Input parameters to the integrity algorithm 3–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ciphering of User/Signalling Data 3–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Input parameters to the cipher algorithm 3–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 4UMTS Protocols 4–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives 4–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction to UMTS Protocols 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access Stratum 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Non-Access Stratum 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



vi

General Protocol Model 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Horizontal Layers 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vertical Planes 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IuCS Protocol Structure 4–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control Plane Protocol Stack 4–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport Network Control Plane Protocol Stack 4–6. . . . . . . . . . . . . . . . . . . . . . . . . . User Plane Protocol Stack 4–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IuPS Protocol Structure 4–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control Plane Protocol Stack 4–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport Network Control Plane Protocol Stack 4–8. . . . . . . . . . . . . . . . . . . . . . . . . . User Plane Protocol Stack 4–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Iub Protocol Structure 4–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control Plane Protocol Stack 4–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport Network Control Plane Protocol Stack 4–10. . . . . . . . . . . . . . . . . . . . . . . . . . User Plane Protocol Stack 4–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Iur Protocol Structure 4–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control Plane Protocol Stack 4–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport Network Control Plane Protocol Stack 4–12. . . . . . . . . . . . . . . . . . . . . . . . . . User Plane Protocol Stack 4–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Radio Interface Protocol Architecture 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RRC Functions 4–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Protocol Stacks 4–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Plane Protocol Stack (Dedicated Channels CS-Domain) 4–26. . . . . . . . . . . . . . . Dedicated Channel Frame Protocol (DCH FP) 4–28. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Control Plane Protocol Stack (UE-CN SIGNALLING, Dedicated Channels, CS-Domain) . . . . . . . 4–30

RANAP Services 4–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SCCP 4–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MTP3-B 4–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SAAL-NNI 4–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Control Plane Protocol Stack (UE-CN Signalling, Shared Channels, CS-Domain) 4–32. . . . RACH/FACH/ DSCH Frame Protocol 4–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

User Plane Protocol Stack (Dedicated Channels, PS-Domain) 4–34. . . . . . . . . . . . . . . . . . . . GPRS Tunnelling Protocol, User Plane (GTP-U) 4–34. . . . . . . . . . . . . . . . . . . . . . . . . . . Path Protocols 4–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Control Plane Protocol Stack(UE-CN Signalling, Dedicated Channels, PS-Domain) 4–36. . . . . . . . . . . . . . . . . . . . . . . . . . .

Stream Control Transmission Protocol 4–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . M3UA 4–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



vii

Chapter 5Data Flow and Terrestrial Interfaces 5–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives 5–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Terrestrial Interfaces 5–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ATM Principles 5–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Asynchronous Transfer Mode (ATM) 5–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Virtual Channels and Paths 5–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use of Virtual Channels and Paths 5–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Virtual Connection and Path Switching 5–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ATM Adaptation Layers (AALs) 5–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The ATM Adaptation Process 5–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Convergence Sub-Layer (CS) 5–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Segmentation and Reassembly 5–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ATM Adaptation Layer 2 (AAL2) 5–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPCS 5–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ATM Adaptation Layer 5 (AAL 5) 5–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E1 Architecture 5–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logical Links 5–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E1 5–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . T1 5–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ATM Cell to E1 Cell Mapping 5–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E Link Multiplexing 5–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Inverse Multiplexing for ATM (IMA) 5–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Synchronous Digital Hierarchy (SDH) 5–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SDH Drop and Insert 5–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Simplification 5–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Survivability 5–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Control 5–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bandwidth on Demand 5–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Principles of SDH 5–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ATM to STM Mapping - VC4 5–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Typical UMTS Transport Network 5–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 6W-CDMA Theory 6–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives 6–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Multiple Access Schemes 6–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

W-CDMA Characteristics 6–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Re-Use of Frequency 6–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Re-Use of Codes 6–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Spectral Efficiency (GSM and UMTS) 6–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Direct Spread (DS)-CDMA Implementation 6–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transmitter 6–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Receiver 6–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



viii

Spreading 6–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Orthogonal Codes 6–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Channelisation Code Tree 6–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

De-spreading Other Users Signals 6–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Processing Gain 6–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exercise 1 - Spreading 6–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Scrambling 6–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Scrambling Codes vs Channelisaton Codes 6–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Short Codes vs Long Codes 6–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Scrambling and Summation 6–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

De-Scrambling and Data Recovery 6–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Multi-path Radio Channels 6–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Matched Filter Operation 6–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The RAKE Receiver 6–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 7The Physical Layer 7–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



ix

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PICH Channel Structure. 7–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Discontinuous Reception (DRX) on the PICH 7–33. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Secondary Common Control Physical Channel (S-CCPCH) 7–36. . . . . . . . . . . . . . . . . . . . . . . Secondary CCPCH Fields 7–37. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Pysical Random Access Channel (PRACH) 7–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure of the PRACH 7–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Random Access Transmission 7–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PRACH Pre-amble 7–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure of the random-access transmission 7–39. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure of PRACH Message Part 7–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Acquisition Indicator Channel AICH) 7–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AICH signature patterns 7–43. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Relationship Between PRACH and AICH 7–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Downlink Dedicated Physical Channels (DL-DPCH) 7–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . DL-DPCH Structure 7–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Downlink Slot Formation in Case of Multi-Code Transmission 7–48. . . . . . . . . . . . . . .

Uplink Dedicated Physical channels (UL-DPCH) 7–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Random Access Procedure in Detail 7–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Random access parameters 7–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical random access procedure 7–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASC to Access Class Mapping 7–56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RACH access slot sets 7–57. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RACH sub-channels 7–57. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RACH Access Slot Availability 7–62. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scaling Factor 7–68. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PRACH/Access Service Class/ Sub channel/Signature Mapping 7–70. . . . . . . . . . . . .

PCPCH (Physical Common Packet Channel) and Associated Physical Signals 7–72. . . . . . CPCH Status Indicator Channel (CSICH) 7–74. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPCH transmission 7–76. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPCH Access Preamble Acquisition Indicator Channel (AP–AICH) 7–78. . . . . . . . . . CPCH Collision Detection/Channel Assignment Indicator Channel (CD/CA–ICH) . . . . . . . 7–80Physical Common Packet Channel (PCPCH) 7–84. . . . . . . . . . . . . . . . . . . . . . . . . . . . . DL–DPCCH for CPCH 7–86. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Downlink Flow Process 7–88. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Uplink Flow Process 7–90. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Radio Frame Equalisation 7–90. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rate Matching 7–90. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DTX 7–90. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



x

Chapter 8Radio Resource Management Functions 8–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives 8–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Radio Resource Management 8–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UE RRC States 8–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Idle Mode 8–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connected Mode 8–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Physical Layer Measurements 8–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UE Measurements 8–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UTRA Measurements 8–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Compressed Mode 8–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Cell Selection/Re-selection 8–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Immediate Cell Evaluation 8–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell Re-selection 8–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Macro Diversity 8–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Handover 8–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handover Strategy 8–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handover Causes 8–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Soft and Softer Handover 8–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

S-RNS Relocation 8–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Power Control 8–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Site Selection Diversity Power Control (SSDT) 8–24. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Open Loop Power Control 8–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Closed Loop Power Control (Inner Loop) 8–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Closed Loop Power Control (Outer Loop) 8–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Multi-Cell Power Control 8–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Site Select Diversity Transmission 8–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Space Time Transmit Diversity (STTD) 8–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Closed Loop Mode Transmit diversity 8–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Admission Control 8–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quality of Service (QoS) 8–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Load 8–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Load Control 8–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 9Annexe A A9–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives A9–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Paging for a UE in Idle Mode A9–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Paging for the UE in RRC Connected Mode A9–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RRC Connection Establishment A9–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RRC DCH Release A9–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RA Update A9–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SRNC Relocation A9–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



xi

��

Version 1 Rev 7



xii

Version 1 Rev 7 General information



1

General information

Important notice

If this manual was obtained when attending a Motorola training course, it will not beupdated or amended by Motorola. It is intended for TRAINING PURPOSES ONLY. If itwas supplied under normal operational circumstances, to support a major softwarerelease, then corrections will be supplied automatically by Motorola in the form ofGeneral Manual Revisions (GMRs).

Purpose

Motorola cellular communications manuals are intended to instruct and assist personnelin the operation, installation and maintenance of the Motorola cellular infrastructureequipment and ancillary devices. It is recommended that all personnel engaged in suchactivities be properly trained by Motorola.

WARNING Failure to comply with Motorola’s operation, installation andmaintenance instructions may, in exceptional circumstances,lead to serious injury or death.

These manuals are not intended to replace the system and equipment training offered byMotorola, although they can be used to supplement and enhance the knowledge gainedthrough such training.

ETSI standards

The standards in the table below able are protected by copyright and are the property ofthe European Telecommunications Standards Institue (ETSI).

ETSI specification number

GSM 02.60 GSM 04.10 GSM 08.08

GSM 03.60 GSM 04.11 GSM 08.16

GSM 03.64 GSM 04.12 GSM 08.18

GSM 04.01 GSM 04.13 GSM 08.51

GSM 04.02 GSM 04.60 GSM 08.52

GSM 04.03 GSM 04.64 GSM 08.54

GSM 04.04 GSM 04.65 GSM 08.56

GSM 04.05 GSM 08.01 GSM 08.58

GSM 04.06 GSM 08.02 GSM 09.18

GSM 04.07 GSM 08.04 GSM 09.60

GSM 04.08 GSM 08.06

Figures from the above cited technical specifications standards are used, in this trainingmanual, with the permission of ETSI. Further use, modification, or redistribution is strictlyprohibited. ETSI standards are available from http://pda.etsi.org/pda/ andhttp://etsi.org/eds/

Version 1 Rev 7General information



2

Data encryption

In order to avoid electronic eavesdropping, data passing between certain elements in theGSM and GPRS network is encrypted. In order to comply with the export and importrequirements of particular countries, this encryption occurs at different levels asindividually standardised, or may not be present at all in some parts of the network inwhich it is normally implemented. The manual set, of which this manual is a part, coversencryption as if fully implemented. Because the rules differ in individual countries,limitations on the encryption included in the particular software being delivered, arecovered in the Release Notes that accompany the individual software release.

Cross references

Throughout this manual, cross references are made to the chapter numbers and sectionnames. The section name cross references are printed bold in text.

This manual is divided into uniquely identified and numbered chapters that, in turn, aredivided into sections. Sections are not numbered, but are individually named at the top ofeach page, and are listed in the table of contents.

Text conventions

The following conventions are used in the Motorola cellular infrastructure manuals torepresent 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, andenvironmental variables that appear on the screen are shown likethis.

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 key.

Version 1 Rev 7 Reporting safety issues



3

Reporting safety issues

Introduction

Whenever a safety issue arises, carry out the following procedure in all instances.Ensure that all site personnel are familiar with this procedure.

Procedure

Whenever a safety issue arises:

1. Make the equipment concerned safe, for example by removing power.

2. Make no further attempt to adjust or rectify the equipment.

3. Report the problem directly to the Customer Network Resolution Centre, Swindon+44 (0)1793 565444 or China +86 10 68437733 (telephone) and follow up with awritten report by fax, Swindon +44 (0)1793 430987 or China +86 1068423633 (fax).

4. Collect evidence from the equipment under the guidance of the Customer NetworkResolution Centre.

Version 1 Rev 7Warnings and cautions



4

Warnings and cautions

Introduction

The following describes how warnings and cautions are used in this manual and in allmanuals of this Motorola manual set.

Warnings

Definition of Warning

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, forexample, 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 data in/outconnectors. Laser radiation can come from either the data in/outconnectors or unterminated fibre optic cables connected to datain/out connectors.

Failure to comply with warnings

Observe all warnings during all phases of operation, installation and maintenance of theequipment described in the Motorola manuals. Failure to comply with these warnings,or with specific warnings elsewhere in the Motorola manuals, or on the equipmentitself, violates safety standards of design, manufacture and intended use of theequipment. Motorola assumes no liability for the customer’s failure to complywith these requirements.

Cautions

Definition of Caution

A caution means that there is a possibility of damage to systems, software or individualitems 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 due calibration date;arrange for calibration to be carried out.

Version 1 Rev 7 General warnings



5

General warnings

Introduction

Observe the following specific warnings during all phases of operation, installation andmaintenance of the equipment described in the Motorola manuals:

� Potentially hazardous voltage

� Electric shock

� RF radiation

� Laser radiation

� Heavy equipment

� Parts substitution

� Battery supplies

� Lithium batteries

Failure to comply with these warnings, or with specific warnings elsewhere in theMotorola manuals, violates safety standards of design, manufacture and intended use ofthe equipment. Motorola assumes no liability for the customer’s failure to comply withthese requirements.

Warning labels

Warnings particularly applicable to the equipment are positioned on the equipment.Personnel working with or operating Motorola equipment must comply with any warninglabels fitted to the equipment. Warning labels must not be removed, painted over orobscured in any way.

Version 1 Rev 7General warnings



6

Specific warnings

Specific warnings used throughout the GSM manual set are shown below, and will beincorporated into procedures as applicable.

These must be observed by all personnel at all times when working with the equipment,as must any other warnings given in text, in the illustrations and on the equipment.

Potentially hazardous voltage

WARNING This equipment operates from a hazardous voltage of 230 Vac single phase or 415 V ac three phase supply. To achieveisolation of the equipment from the ac supply, the ac inputisolator must be set to off and locked.

When working with electrical equipment, reference must be made to the Electricity atWork Regulations 1989 (UK), or to the relevant electricity at work legislation for thecountry in which the equipment is used.

NOTE Motorola GSM equipment does not utilise high voltages.

Electric shock

WARNING Do not touch the victim with your bare hands until theelectric circuit is broken.Switch off. If this is not possible, protect yourself with dryinsulating material and pull or push the victim clear of theconductor.ALWAYS send for trained first aid or medical assistanceIMMEDIATELY.

In cases of low voltage electric shock (including public supply voltages), serious injuriesand even death, may result. Direct electrical contact can stun a casualty causingbreathing, and even the heart, to stop. It can also cause skin burns at the points of entryand exit of the current.

In the event of an electric shock it may be necessary to carry out artificial respiration.ALWAYS send for trained first aid or medical assistance IMMEDIATELY.

If the casualty is also suffering from burns, flood the affected area with cold water to cool,until trained first aid or medical assistance arrives.

RF radiation

WARNING High RF potentials and electromagnetic fields are present inthis equipment when in operation. Ensure that alltransmitters are switched off when any antenna connectionshave to be changed. Do not key transmitters connected tounterminated cavities or feeders.

Relevant standards (USA and EC), to which regard should be paid when working with RFequipment are:

� ANSI IEEE C95.1-1991, IEEE Standard for Safety Levels with Respect to HumanExposure to Radio Frequency Electromagnetic Fields, 3 kHz to 300 GHz.

� CENELEC 95 ENV 50166-2, Human Exposure to Electromagnetic Fields HighFrequency (10 kHz to 300 GHz).

Version 1 Rev 7 General warnings



7

Laser radiation

WARNING Do not look directly into fibre optic cables or optical datain/out connectors. Laser radiation can come from either thedata in/out connectors or unterminated fibre optic cablesconnected to data in/out connectors.

Lifting equipment

WARNING When dismantling heavy assemblies, or removing orreplacing equipment, a competent responsible person mustensure that adequate lifting facilities are available. Whereprovided, lifting frames must be used for these operations.

When dismantling heavy assemblies, or removing or replacing equipment, the competentresponsible person must ensure that adequate lifting facilities are available. Whereprovided, lifting frames must be used for these operations. When equipments have to bemanhandled, reference must be made to the Manual Handling of Loads Regulations1992 (UK) or to the relevant manual handling of loads legislation for the country in whichthe equipment is used.

Parts substitution

WARNING Do not install substitute parts or perform any unauthorizedmodification of equipment, because of the danger ofintroducing additional hazards. Contact Motorola if in doubtto ensure that safety features are maintained.

Battery supplies

WARNING Do not wear earth straps when working with standby batterysupplies.

Lithium batteries

WARNING Lithium batteries, if subjected to mistreatment, may burstand ignite. Defective lithium batteries must not be removedor replaced. Any boards containing defective lithiumbatteries must be returned to Motorola for repair.

Contact your local Motorola office for how to return defective lithium batteries.

Version 1 Rev 7General cautions



8

General cautions

Introduction

Observe the following cautions during operation, installation and maintenance of theequipment described in the Motorola manuals. Failure to comply with these cautions orwith specific cautions elsewhere in the Motorola manuals may result in damage to theequipment. Motorola assumes no liability for the customer’s failure to comply with theserequirements.

Caution labels

Personnel working with or operating Motorola equipment must comply with any cautionlabels fitted to the equipment. Caution labels must not be removed, painted over orobscured in any way.

Specific cautions

Cautions particularly applicable to the equipment are positioned within the text of thismanual. These must be observed by all personnel at all times when working with theequipment, as must any other cautions given in text, on the illustrations and on theequipment.

Fibre optics

CAUTION Fibre optic cables must not be bent in a radius of less than30 mm.

Static discharge

CAUTION Motorola equipment contains CMOS devices. These metaloxide semiconductor (MOS) devices are susceptible todamage from electrostatic charge. See the section Devicessensitive to static in the preface of this manual for furtherinformation.

Version 1 Rev 7 Devices sensitive to static



9

Devices sensitive to static

Introduction

Certain metal oxide semiconductor (MOS) devices embody in their design a thin layer ofinsulation that is susceptible to damage from electrostatic charge. Such a charge appliedto the leads of the device could cause irreparable damage.

These charges can be built up on nylon overalls, by friction, by pushing the hands intohigh insulation packing material or by use of unearthed soldering irons.

MOS devices are normally despatched from the manufacturers with the leads shortedtogether, for example, by metal foil eyelets, wire strapping, or by inserting the leads intoconductive 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 followingprecautions 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 toreplace 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 cottonoverall is preferable.

� If possible work on an earthed metal surface or anti-static mat. Wipe insulatedplastic 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 anearthed surface.

� Take care when removing components connected to electrostatic sensitivedevices. These components may be providing protection to the device.

When mounted onto printed circuit boards (PCBs), MOS devices are normally lesssusceptible to electrostatic damage. However PCBs should be handled with care,preferably by their edges and not by their tracks and pins, they should be transferreddirectly from their packing to the equipment (or the other way around) and never leftexposed on the workbench.



1–1

Chapter 1

Introduction

Version 1 Rev 7



1–2

Version 1 Rev 7



1–3

Chapter 1Introduction 1–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives 1–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UMTS Services 1–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IMT-2000 Roadmap 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IMT-2000 Objectives 1–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Research and Proposal 1–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proposals 1–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Standardisation (1998) 1–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Harmonisation (1999) 1–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CDMA-2000 1–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multi-carrier 1–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Direct-Sequence (DS) 1–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permitted Carrier Combinations 1–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cdma2000 Evolution 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UMTS Terrestrial Radio Access (UTRA) 1–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FDD Mode 1–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UTRA TDD Mode 1–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

World-wide Spectrum Allocation for IMT-2000 1–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WARC 92 1–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WARC 2000 1–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

European Frequency Allocations 1–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Licence Allocation in the UK 1–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



1–4

Version 1 Rev 7 Objectives



1–1

ObjectivesOn completion of this chapter the student should be able to:

� State the services UMTS aims to provide.

� State the IMT-2000 objectives

� Describe the evolution of UMTS from 2G systems.

� Describe the UMTS operating modes.

� State the frequency allocations for UMTS.

Version 1 Rev 7UMTS Services



1–2

UMTS ServicesUMTS is expected to deliver voice, graphics, video and other broadband informationdirect to the user, regardless of location, network or terminal. These fully personalcommunication services will provide terminal and service mobility on fixed and mobilenetworks, taking advantage of the convergence of existing and future fixed and mobilenetworks and the potential synergies that can be derived from such convergence. Thekey benefits that UMTS promises include improvements in quality and security,incorporating broadband and networked multimedia services, flexibility in service creationand ubiquitous service portability.

Networked multimedia includes services such as pay-TV; video and audio-on-demand;interactive entertainment; educational and information services; and communicationservices such as video-telephony and fast, large file transfer.

UMTS services are also likely to be used by other sectors, including systems with limitedmobility (e.g. in areas with low population density), and in private/corporate markets,ranging from home use to wireless PBXs, emergency and cordless systems.

Version 1 Rev 7 UMTS Services



1–3

UMTS Services

CP13_Ch1_02

Voice·

Graphics·Internet·Conferencing·Video·Text·

Version 1 Rev 7IMT-2000 Roadmap



1–4

IMT-2000 RoadmapThe diagram opposite points out the possible routes to 3G. On one extreme we see theroute taken by 3GPP culminating in the adoption of W-CDMA. Centre stage we see theroute chosen by the UWC 136 supporters. UWC 136 will be built on TDMA technology byenhancing its modulation techniques to meet ITUs requirements for IMT2000. Far rightwe see the route chosen for 3GPP2 which has its origins in the IS95 standards known asCDMAOne 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 StandardInstitute

GPRS General Packet Radio Service

EDGE Enhanced Data rates for Global Evolution

UWCC Universal Wireless CommunicationCommittee

TIA Telecommunication Industry Association

3GPP Third Generation Partnership Project

UWC Universal Wireless Communications

3GPP2 Third Generation Partnership Project 2

Version 1 Rev 7 IMT-2000 Roadmap



1–5

IMT-2000 Roadmap

GSM TDMA (IS – 136) IS–95A

CP13_Ch1_05

GPRS

EDGE

IS–95B

W–CDMA

3GPP

UWC–136

UWCC

cdma2000

3GPP2

CDG

TIA

UWCC

T1

GSM Association

ETSI

3G

2.5G

2G

Version 1 Rev 7IMT-2000 Objectives



1–6

IMT-2000 ObjectivesThe objectives of IMT-2000 are to encourage global service provision and convergenceof the many, essentially competing, wired and wireless access technologies currently inuse. IMT-2000 aims to be a global standard that provides the flexibility required byexisting operators to seamlessly evolve there networks towards the needs theirsubscribers in the future. In doing IMT-2000 is expected to reduce the“telecommunications gap”, by offering cost effective access to telecommunicationsfacilities to the billions of people who do not currently have a phone.

IMT-2000 incorporates many current radio access technologies, including both terrestrialand satellite components. Fixed and mobile access, on both public and private networks

Will offer a much wider range of services and types of terminals than any of thepreceding radio access technologies.

Version 1 Rev 7 IMT-2000 Objectives



1–7

IMT-2000 Objectives

CP13_Ch1_06

Global service capabilities

Terrestrial and satellite components

Flexible/seamless service

Wider range of services/terminals

Fixed/Mobile and Public/Private

Improved operational efficiencies

·

····

·Reduce the “Telecommunications gap”·

Version 1 Rev 7Research and Proposal



1–8

Research and ProposalHaving laid down the basic framework of requirements, the ITU invited research activitiesto identify a suitable radio access scheme to fulfil the IMT-2000 aims and objectives.Most of this research activity was undertaken in by standards development organisationsand industry in Europe, The United States, Japan and Korea. Many different radioaccess technologies (both terrestrial and satellite), and multiple access methodologieswere considered, with the majority being based upon Code Division Multiple Access(CDMA) and Time Division Multiple Access (TDMA).

Proposals

At the June 1998 deadline, ITU had received a total of 16-proposals, all of which wouldmeet or exceed the basic aims and objectives of IMT-2000. The proposals included 10terrestrial and six satellite based radio access technologies. Of the terrestrial options,only 2 were TDMA based, with the remainder proposing CDMA; either narrow band,wideband or multi-carrier

The main European contender was Universal Terrestrial Radio Access (UTRA), althoughnow generally accepted as translating to “UMTS” terrestrial radio Access. UTRAproposed a wide band, Direct Spread CDMA (DS-CDMA) and includes a combinationCDMA/TDMA mode. UTRA was designed to be backward compatible with existing GSMMobile Application Part (MAP) core network.

Another dominant proposal was also based on DS-CDMA, but called for the use ofmultiple narrow band carriers in the down link and is hence referred to as Multi CarrierCDMA (MC-CDMA). The MC schema make the re-use of existing IS-95 and PCSfrequencies for 3G more feasible. This, along with the fact that a ANSI-41 core wasspecified, make the proposal more attractive to current IS-95 operators in the US andAsia.

Version 1 Rev 7 Research and Proposal



1–9

Research and Proposal

CP13_Ch1_06a

EuropeW–CDMAW–TDMATDMA/CDMAOFDMAODMA

JapanW–CDMAW–TDMAOFDMA

USAW–CDMAS N/AW–TDMAMC–CDMAWIMS W–CDMAWP–CDMA

KoreaW–CDMA(Asynch)W–CDMA(Synch)

June 199810 Terrestrialproposals to ITU8 x CDMA2 x TDMA

Version 1 Rev 7Standardisation (1998)



1–10

Standardisation (1998)At the close of the research and proposal phase in June 1998, ten suitable terrestrialradio access technologies had been proposed. Each proposal naturally tended to favourcompatibility with the existing 2G systems in the proposing bodies region, and ITUaccepted this need for “Flexible/Seamless” migration. However, it became evident thatalthough many technical aspects of the proposals were similar, allowing each region toindependently define its own specifications would, in addition to being a waste ofresources, mean that equipment compatibility on a global basis would be very difficult toachieve.

ITU therefore started initiatives to achieve further standardisation. From these initiativestwo forums were created, the Third Generation Partnership Project (3GPP) and 3GPP

3GPP

The standards development organisations involved in the creation of 3GPP were,Association of Radio Industries and Businesses (ARIB) from Japan, the EuropeanTelecommunications Standards Institute (ETSI), The Telecommunications TechnologyAssociation (TTA) of Korea and T1P1 for the USA. The partners agreed to joint effortsfor the standardisation of W-CDMA based on the UTRA Proposal. Later during 1999,The China Wireless Telecommunications Standards Group (CWTS) also joined 3GPP. Aswell as the SDOs, manufacturers and operators also have membership of 3GPP, alongwith industry interest groups such as the GSM association, UMTS forum, Global MobileSuppliers Association, Ipv6 Forum and the Universal Wireless CommunicationsConsortium (UWCC).

3GPP2

Work done by TIA and TTA was merged to form 3GPP2, focused on the development ofCDMA2000, a multi-carrier solution. This activity is running in parallel with the 3GPPproject, with participation from ARIB, TTC and CWTS as member organisations.

Version 1 Rev 7 Standardisation (1998)



1–11

Standardisation

CP13_Ch1_06b

T1P1 TTA

ETSIARIB/TTC

CWTS

3rd GenerationPartnership Project

(3GPP)

Standardisation for acommon W–CDMA Specification

3rd GenerationPartnership Project 2

(3GPP2)

Standardisation for a common MC–CDMA Specification

TTA

TIA

Version 1 Rev 7Harmonisation (1999)



1–12

Harmonisation (1999)During the spring of 1999 several operators and manufacturers met to seek furtherconvergence of the CDMA based 3G solutions (UTRA W-CDMA and CDMA2000). As aresult of these meetings, the Operators Harmonisation Group (OHG) was founded andagreed to adopt a “Harmonised” global 3G CDMA standard consisting of three modes:

1. A direct spread wide band CDMA, Known as UTRA Frequency Division Duplex(FDD).

2. A wideband CDMA/TDMA option, known as UTRA Time Division Duplex (TDD).

3. A multi-carrier CDMA option, known as CDMA2000 (or 1X/3X).

The main technical impacts of the harmonisation activities were as follows:

1. The change of the UTRA FDD and TDD Chip rate from 4.096 Mcps to 3.84 Mcps.

2. The inclusion of a common pilot channel for UTRA FDD.

3. A requirement for ALL core networks to support all radio access technologies.

Version 1 Rev 7 Harmonisation (1999)



1–13

Harmonisation

Manufacturers and Operators Agreed to Adopt aHarmonised Global 3rd Generation Standard Consistingof Three Modes:

� Multi carrier CDMA

� Direct Spread CDMA (UTRA FDD)

� Time Division Duplex (UTRA TDD)

Main Technical Impacts:

� All Core Networks To Support All Air I/F Alternatives

� Change of UTRA FDD & TDD Chip Rates from 4.096 Mcps to 3.84 Mcps

� Inclusion of a Common Pilot for UTRA FDD

CP13_Ch1_p13

Version 1 Rev 7CDMA-2000



1–14

CDMA-2000CDMA-2000, the 3G system promoted by 3GPP2, is based upon the IMT-2000 proposalknown as Multicarrier CDMA (MC-CDMA). 3GPP2 has specified an air interface systemthat is backward compatible with existing IS-95 systems. This approach being necessarybecause in North America, IS-95 networks already use the frequency spectrum allocatedfor 3G. CDMA-2000 must therefore coexist with the older systems on the same radiofrequency bands.

For CDMA-2000, the carrier composition can be different in downlink and uplink (knownas Forward and Reverse links respectively for this system). Carrier composition isdetermined by the Spreading Rate employed. Two Spreading Rates are currentlydefined by 3GPP2.

� Spreading Rate 1 (SR1) - SR1 is often refered to as “1X”. In this mode, bothforward and reverse links use a single, Direct-Sequence spread carrier, with a chiprate of 1.2288 Mcps. Allowing for the required “Guard Bands” this requires a RFcarrier Bandwidth of 1.25 MHz.

� Spreading Rate 3 (SR3) - SR3 is often referred to as “3X”. A SR3 ForwardCDMA Channel uses 3–Direct-Sequence spread carriers (i.e. Multi-Carrier), eachwith a chip rate of 1.2288 Mcps and a bandwidth of 1.25 Mhz. A SR3 ReverseCDMA channel uses a single Direct–Sequence spread carrier with a chip rate of3.6964 Mcps

Multi-carrier

In Multi-carrier configurations, multiple (up to 12) narrow band (1.25 MHz) carriers can beused to provide a single composite forward radio link. Early deployments of CDMA-2000will, as described above, utilise three such carriers and is referred to as “3X” mode.

As these carriers have the same bandwidth as IS-95, they can be used in overlay modewith IS-95. This is possible because CDMA-2000 spreading codes can be chosen to beorthogonal with the code in IS-95, thus minimising inter-system interference. Closetiming synchronisation within and between different systems is also essential for this typeof operation.

Direct-Sequence (DS)

In the Direct-Sequence configuration, the whole available link bandwidth is allocated toone direct spread narrow band (SR1) or wideband (SR3) carrier.

CDMA-2000 does not use time synchronisation on the uplink and therefore cannot usecodes that are orthogonal with IS-95. Thus, when using SR3, splitting the reverse linkcarrier into several narrow band components, as with the forward Llnk, yields no benefits.

Permitted Carrier Combinations

� Foward Link - DS SR1. Reverse Link - DS SR1 (Currently Deployed as 1X)

� Forward Link - MC SR3. Reverse Link - DS SR1 (Future 3X Evolution Path)

� Forward Link - MC SR3. Reverse Link - DS SR3 (Future 3X Evolution Path)

Version 1 Rev 7 CDMA-2000



1–15

CDMA-2000 Modes

Direct SpreadConfiguration

(SR1)

Direct SpreadConfiguration

(SR3)

Multi–CarrierConfiguration

(SR3)

Version 1 Rev 7CDMA-2000



1–16

cdma2000 Evolution

cdma2000 systems, based upon 3GPP2 Spreading Rate 1 standards, commonly knownas “cdma200 1x “ are currently being deployed throughout North America and Asia.These systems provide a packet data service, offering an average user data rate of 144kb/s. In addition, when compared with IS-95 A/B, a 50% increase in voice capacity isobtained. This system uses a single 1.25 Mhz bandwidth carrier pair and, is capable ofco-existing with IS-95 on the same radio spectrum.

However, cdma2000 1x alone, cannot provide the IMT-2000 objective of ISDN H12channel equivalence, this being data services at 2.048 Mb/s. To obtain this rate, furtherevolution is required. Three evolution options are available, as follows:

Spreading Rate 3 (SR3)

The original 3GPP2 specifications included standards for a SR3 service, commonlyreferred to as “cdma2000 3x ”. As previously described, this mode uses multiple narrow(1.25 Mhz) band channels in the forward direction and, a single wideband (5 Mhz) DirectSequence carrier in the reverse direction, to achieve the require data bandwidth. Therequirements for large spectrum allocations and the inability to co-exist with IS-95systems, makes this option the least attractive to operators.

cdma2000 1x Evolution - Data Only (1xEV-DO)

Technical innovations since the 3GPP2 specifications were originally drafted, have led toa numbers of options being proposed to enhance the SR1 or cdma2000 1x system. Thefirst of these is known as “1xEV-DO“. This system provides a standalone packet dataservice, offering maximum data rates of 2450 kb/s, with a user data throughput of600kb/s being a practical figure. A 1.25Mhz carrier pair is required to provide thisservice. Concurrent voice services may be offered by the operator using IS-95 A/B orcdma2000 1x, using separate radio spectrum allocations.

cdma2000 1x Evolution - Data and Voice (1xEV-DV)

By using sophisticated Modulation techniques, “1XEV-DV” provides a method ofobtaining both voice and high speed data, including real time data services, using asingle 1.25 Mhz carrier pair. This system is 100% backward compatible with bothcdma2000 1X and IS-95 A/B systems.

Version 1 Rev 7 CDMA-2000



1–17

cdma2000 Evolution

IS–95 A/B

Cdma2000 (1x)

Cdma2000 (3x)cdma2000(1xEV –DO)

Cdma2000(1xEV –DV)

IS–95 A/B

Cdma2000 (1x)

Cdma2000 (3x)cdma2000(1xEV –DO)

Cdma2000(1xEV –DV)

CP13_Ch1_6g

Version 1 Rev 7UMTS Terrestrial Radio Access (UTRA)



1–18

UMTS Terrestrial Radio Access (UTRA)3GPP is the organisation that develops specifications for a 3G system based on theUMTS Terrestrial Radio Access (UTRA) radio interface, which is primarily designed tooperate with an enhanced GSM core network. The UTRA system provides for twooperating modes, Frequency Division Duplex (FDD) and Time Division Duplex (TDD)

FDD Mode

In the FDD mode of operation, uplink and downlink transmissions use separate radiocarriers in different sub-bands of the IMT-2000 spectrum allocation. These “paired” radiocarriers must be separated by a minimum of 130 MHz. Each radio carrier is allocated abandwidth of 5 Mhz, in each direction.

The 5 MHz of bandwidth of each radio carrier is shared among multiple users. Individualusers are separated using Channelisation Codes, which give a unique signature to thatuser. The exact code assigned to a user, determines how much of the shared bandwidthresource that user is allocated.

The number of users that can be accommodated on a radio carrier is dependent uponthe resource requirements of those users. The higher the data rate of a user, the greaterthe bandwidth required to transport that data, therefore the lower the number of usersthat can be supported. The theoretical maximum number of users per carrier is 512, thisbeing limited by the number of available Channelisation Codes. In practice this figure willbe much lower.

Because separate uplink and downlink radio frequencies are used both network, anduser can transmit and receive simultaneously, allowing full duplex operation. However, inaddition to the transfer of user data the radio interface must support certain Layer 1control procedures (e.g. power control). These procedures must be performed at regularintervals, and to define these intervals a radio frame and timeslot structure is defined.Each carrier is divided into 10 milli-second Radio Frames and each frame is furtherdivided into 15 timelsots.

It should be noted that unlike GSM, where Mobile Stations are allowed to transmit andreceive in set timeslots, UMTS User Equipments operating in FDD mode can transmitand receive in every timeslot, during every radio frame.

Version 1 Rev 7 UMTS Terrestrial Radio Access (UTRA)



1–19

UTRA FDD Mode

CP13_Ch1_6e

10 ms

TS0 TS14

190 MHz

10 ms

TS0 TS14

10 ms

TS0 TS14

190 MHz

10 ms

TS0 TS14

Version 1 Rev 7UMTS Terrestrial Radio Access (UTRA)



1–20

UTRA TDD Mode

The TDD UTRA mode differs from the FDD mode in that both uplink and downlinktransmissions use the same 5 MHz bandwidth carrier, providing a service without therequirement for “paired” radio carriers. Future allocations of radio spectrum to UMTSmay not permit the use of paired bands as radio spectrum becomes a more scarcecommodity. Since uplink and downlink share the same frequency, the links must besegregated using the time domain

The physical structure of the TDD radio interface is similar to that of UTRA FDD, in that a10 ms frame, divided into 15 timeslots is used. The 15 timeslots can be dynamicallyallocated between uplink and downlink directions, thus the capacity of the links can bedifferent. This capability makes TDD well suited to asymmetric services.

With such a flexibility, the TDD mode can be adapted to different configurations ofuplink/downlink timeslot usage. However, in any configuration at least one timeslot hasto be allocated for the uplink and at least one time slot allocated for the uplink. In eitherdirection, A given user may be allocated resources within a single timeslot or multipletimeslots.

Within each timeslot, the data part of each physical channel is defined using a uniquechannelisation code. In the downlink, 16 codes are used per time slot. Multiple parallelphysical channels can be used to support higher data rates for a single user. The 16codes in each timeslot may be also be shared by multiple users.

In the uplink direction either 1, 2, 4 8, or 16 codes may be used, with each code againdefining an individual physical channel. A User may use a maximum of two physicalchannels per timeslot simultaneously. The larger the number of codes that are used, thelower will be the data rate supported by each code.

Version 1 Rev 7 UMTS Terrestrial Radio Access (UTRA)



1–21

UTRA TDD Mode

10 ms

10 ms

10 ms

10 ms

OR

OR

OR

(Examples Only)

10 ms

10 ms

10 ms

10 ms

OR

OR

OR

10 ms

10 ms

10 ms

10 ms

OR

OR

OR

(Examples Only)

CP13_Ch1_6f

Version 1 Rev 7World-wide Spectrum Allocation for IMT-2000



1–22

World-wide Spectrum Allocation for IMT-2000

WARC 92

The allocation of frequencies per region after the World Administration Radio Conference(WARC 92) meeting has been varied. IMT-2000 recognised the frequencies to be1885Mhz to 2025Mhz in the lower and 2110Mhz to 2200Mhz in the upper band. Eachband has been sub-divided into Mobile Satellite Service (MSS) and Terrestrial IMT-2000parts.

Not all countries are able to utilise the full ITU spectrum allocation as existing serviceshave already been allocated frequencies in these bands. Therefore there are someregional variations, as can bee seen from the diagram opposite.

� Europe has used part of the band for DECT - which has very low penetration. Italso has GSM 1800 at the lower edge. The band is also split in FDD and TDDbands.

� China has left the band clear and will start IMT-2000 activities soon. This will besplit into WLL and Mobile.

� Japan has developed with Korea the DoCoMo system which is pre release 99 andwill launch Q4 2000/Q1 2001.

� In North America most of the IMT-2000 spectrum has already been allocated tosecond-generation PCS networks, deployed on 5-MHz sub-bands. This makesCDMA-2000 and EDGE the most attractive option to operators in this region, asthese systems are backward compatible with IS-95B and IS-136, and can co-existin the same spectrum

WARC 2000

More recently the WARC 2000 meeting, held in Istanbul, has allocated a further 519 MHzof radio spectrum for 3G services. Again not all regions will be able to make full use ofthis spectrum.

The frequency bands added are:

806 MHz - 960 MHz

1710 MHz - 1885 MHz

2500 MHz - 2690 MHz

Version 1 Rev 7 World-wide Spectrum Allocation for IMT-2000



1–23

World-wide Spectrum Allocation for IMT-2000

A D B F E C A D B F E C

CP13_Ch1_07

ITU Allocations

Europe

China

JapanKorea (w/o PHS)

NorthAmerica

1850 1900 1950 2000 2050 2100 2150 2200 2250 Mhz

MSS = Mobile Satellite

Services

MDS = Multipoint Service/

Mobile Data Service

1850 1900 1950 2000 2050 2100 2150 2200 2250 Mhz

IMT 2000 MSS

1885 1900 1980 2010 2025

UMTS MSS

1880

IMT 2000 MSS

WLL WLL

GSM 1800

DECT GSM 1800

IMT 2000 MSS

1893 1919

PHS

MSS PCS

1990

IMT 2000 MSS

2110 2170 2200

UMTS MSS

IMT 2000 MSS

IMT 2000 MSS

MSS M D S

Reserve

2160

Version 1 Rev 7European Frequency Allocations



1–24

European Frequency AllocationsWhen studying the frequency allocation for Europe more closely we can see thefollowing.

It is split into two frequency bands:

� Lower 1900MHz - 2025MHz

� Upper 2110MHz - 2200MHz

Owing to the asymmetric nature of the frequency allocation, frequencies have beenallocated into paired and unpaired bands.

The frequency range 1920 - 1980 MHz and 2110 - 2170 MHz are available to operatorsas paired bands, these support UTRA Frequency Division Duplex (FDD) and are bestsuited to symmetric services such as telephony. A minimum frequency separation of130MHz has been specified between transmit and receive frequencies.

In the lower band, 1900 - 1920 MHz and 2010 - 2025MHz are available as unpairedbands. These can support UTRA Time Division Duplex (TDD), which is best suited toasymmetrical services such as the Internet.

Version 1 Rev 7 European Frequency Allocations



1–25

European Frequency Allocations

CP13_Ch1_08

GSM 1800

DECT

TD

D

Uplink 12 x 5 MHz

1805

1920

1980

2010

2020

2025

1900

1880

SP

A

MS

S

FD

D

TD

D

20MHz 60MHz 30MHz

MS

S

FD

D

2200

2110

2170

Downlink 12 x 5 MHz 6 x 5 MHz

140MHz

190MHz between up– link and down–link

60MHz 30MHz

90MHz

Version 1 Rev 7Licence Allocation in the UK



1–26

Licence Allocation in the UKIn the UK the spectrum was divided into five licenses. The four incumbent operators weresuccessful in obtaining a license each, which left one for a new entrant. License A, whichis 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

Version 1 Rev 7 Licence Allocation in the UK



1–27

Licence Allocation in the UK

CP13_Ch1_09

D E C A

Unpaired carriers

1900 MHz 1920 MHz

1902.4 MHz 1922.8 MHz

0.4 MHz guard band

14.6 MHz Licence A

10.0 MHz Licence C

14.8 MHz Licence B

10.0 MHz Licence E

10.0 MHz Licence D 1980 MHz

0.3 MHz guard band

1977.2 MHz

2110 MHz

2112.8 MHz

14.6 MHz Licence A

10.0 MHz Licence C

14.8 MHz Licence B

10.0 MHz Licence E

10.0 MHz Licence D 2170 MHz

0.3 MHz guard band

2167.2 MHz

0.3 MHz guard band

Version 1 Rev 7Licence Allocation in the UK



1–28



2–1

Chapter 2

Network Architecture

Version 1 Rev 7



2–2

Version 1 Rev 7



2–3

Chapter 2Network Architecture 2–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives 2–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UMTS Domains 2–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UMTS Architecture – Release 1999 2–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Core Network (CN) Entities 2–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Access Network (AN) Entities 2–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Mobile Station (MS) 2–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UMTS Network – Release 1999 2–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Entities of the CN-CS Domain 2–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Entities Common to the CS and PS Domains 2–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Overview of GSN3/USP1 architecture 2–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Components of the GSN Complex 2–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Packet switch core network components 2–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Motorola C–SGSN 2–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–SGSN Functionality 2–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

GGSN 2–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GGSN functionality 2–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Motorola Charging Gateway (CGW) 2–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Charging Gateway functionality 2–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Communications Hub 2–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CommHub functionality 2–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

DNS/NTP Server 2–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DNS/NTP Server functionality 2–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IP Backbone 2–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Border Gateway 2–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Firewall 2–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SS7 Nodes 2–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Home Location Register (HLR) / Authentication Centre (AuC) 2–32. . . . . . . . . . . . . . . Mobile Switching Centre (MSC) / Visitor Location Register (VLR) 2–32. . . . . . . . . . . . SMS Gateway MSC (SMS–GMSC) / SMS Inter–working MSC (SMS–IWMSC) 2–32CAMEL GSM SCF / P–SCP 2–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Equipment Identity Register (EIR) 2–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Nodes for value added services 2–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lawful Intercept Administrative Node (LIAN) 2–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gateway Mobile Location Centre (GMLC) 2–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

GPRS/UMTS Interfaces 2–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UMTS Terrestrial Radio Access Network (UTRAN) 2–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UTRAN Functions 2–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Radio network Controller (RNC) 2–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling Radio Network Controller (CRNC) 2–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Serving Radio Network Controller (SRNC) 2–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Drift Radio Network Controller (DRNC) 2–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Node B 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wideband Digital Modem (WDM) 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Wideband Transceiver (WBX) 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Linear Power Amplifier (LPA) 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



2–4

User Equipment (UE) 2–48. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction to User Equipment 2–48. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UE Architecture 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrated Circuit (IC) Card 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminal Equipment (TE) 2–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile Equipment (ME) 2–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MT Functionality 2–54. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Network Evolution 2–56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Product evolution 2–56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Servers 2–58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .




2–1


� Name and state the purpose of the UMTS Domains

� Describe the architecture of a UMTS network.

� Describe the purpose of the major network components.

� Describe the options for evolution to future releases.

Version 1 Rev 7UMTS Domains



2–2

UMTS Domains

Domain split

A basic architectural split is between the user equipment (terminals) and theinfrastructure. This results in two domains: the User Equipment Domain and theInfrastructure domain . User equipment is the equipment used by the user to accessUMTS services. User equipment has a radio interface to the infrastructure. Theinfrastructure consists of the physical nodes which perform the various functions requiredto terminate the radio interface and to support the telecommunication servicesrequirements of the users. The infrastructure is a shared resource that provides servicesto all authorised end users within its coverage area. The reference point between theuser 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 offunctionality. These equipment types are referred to as user equipment (terminals), andthey may also be compatible with one or more existing access (fixed or radio) interfacese.g. dual mode UMTS-GSM user equipment. The user equipment may include aremovable smart card that may be used in different user equipment types. The userequipment is further sub-divided in to the Mobile Equipment Domain (ME) and theUser Services Identity Module Domain (USIM). The reference point between the MEand the USIM is termed the “Cu” reference point.

Mobile equipment Domain

The Mobile Equipment performs radio transmission and contains applications. Themobile equipment may be further sub-divided into several entities, e.g. the one whichperforms the radio transmission and related functions, Mobile Termination , (MT), andthe one which contains the end-to-end application or (e.g. laptop connected to a mobilephone), Terminal Equipment , (TE).

USIM Domain

The USIM contains data and procedures which unambiguously and securely identifyitself. These functions are typically embedded in a standalone smart card. This device isassociated to a given user, and as such allows to identify this user regardless of the MEhe uses.

Infrastructure Domain

The Infrastructure domain is further split into the Access Network Domain , which ischaracterized by being in direct contact with the User Equipment and the Core NetworkDomain . This split is intended to simplify/assist the process of de-coupling accessrelated functionality from non-access related functionality and is in line with the modularprinciple adopted for the UMTS. The Access Network Domain comprises roughly thefunctions specific to the access technique, while the functions in the Core networkdomain may potentially be used with information flows using any access technique. Thissplit allows for different approaches for the Core Network Domain, each approachspecifying distinct types of Core Networks which can be connected to the AccessNetwork Domain, as well as different access techniques, each type of Access Networkconnected to th Core Network Domain. The reference point between the access networkdomain and the core network domain is termed the “lu” reference point.

Version 1 Rev 7 UMTS Domains



2–3

UMTS Domains

CP13_Ch2_02

Home Network Domain

Transit Network Domain

Serving Network Domain

Core Network Domain

Access Network Domain

Mobile Equipment

Domain

USIM Domain


User Equipment Domain

Iu [Yu]Uu

[Zu]

CuSIM

CARD

Version 1 Rev 7UMTS Domains



2–4


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

Core Network Domain

The Core Network Domain consists of the physical entities which provide support for thenetwork features and telecommunication services. The support provided includesfunctionality such as the management of user location information, control of networkfeatures and services, the transfer (switching and transmission) mechanisms forsignalling and for user generated information.

The core network domain is sub-divided into the Serving Network Domain , the HomeNetwork Domain and the Transit Network Domain . The reference point between theserving network domain and the home network domain is termed the [Zu] referencepoint. The reference point between the serving network domain and the transit networkdomain is termed the [Yu] reference point.


The serving network domain is the part of the core network domain to which the accessnetwork domain that provides the user’s access is connected. It represents the corenetwork functions that are local to the user’s access point and thus their location changeswhen the user moves. The serving network domain is responsible for routing calls andtransport user data/information form source to destination. It has the ability to interactwith the home domain to cater for user specific data/services and with the transit domainfor non-user specific data/services purposes.

Home Network Domain

The home network domain represents the core network functions that are conducted at apermanent location regardless of the location of the user’s access point. The USIM isrelated by subscription to the home network domain. The home network domaintherefore contains at least permanently user specific data and is responsible formanagement of subscription information. It may also handle home specific services,potentially not offered by the serving network domain.


The transit network domain is the core network part located on the communication pathbetween the serving network domain and the remote party. If, for a given call, the remoteparty is located inside the same network as the originating UE, then no particularinstance of the transit domain is activated.

Version 1 Rev 7 UMTS Domains



2–5

UMTS Domains

CP13_Ch2_02

Home Network Domain



Core Network Domain


Mobile Equipment

Domain

USIM Domain


User Equipment Domain

Iu [Yu]Uu

[Zu]

CuSIM

CARD

Version 1 Rev 7UMTS Architecture – Release 1999



2–6

UMTS Architecture – Release 1999The diagram opposite illustrates the basic configuration of a Public Land Mobile Network(PLMN) supporting UMTS and GSM/GPRS. This architecture is as defined in Release1999 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 explainedbellow. These two domains are overlapping, i.e. they contain some common entities. APLMN 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” foruser traffic as well as all the entities supporting the related signalling. A “CS type ofconnection” is a connection for which dedicated network resources are allocated at theconnection establishment and released at the connection release. The entities specific tothe 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” foruser traffic as well as all the entities supporting the related signalling. A “PS type ofconnection” transports the user information using autonomous concatenation of bitscalled packets: each packet can be routed independently from the previous one. Theentities 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 PSDomains:

� HLR – The Home Location Register

� AUC – Authentication Centre

� EIR – Equipment Identity Register

Version 1 Rev 7 UMTS Architecture – Release 1999



2–7

UMTS Architecture – Release 1999

CP13_Ch2_11

GMSC GGSNAuC

HLR

EIR

SGSNVLR

MSC

VLR

MSC

SIM

ME

USIM

Um Um

CN

BSC

BTS BTS

BSC

BTS BTS

RNC

Node B Node B

RNC

Node B Node B

H Gc

GrD

C

Gi

Gs

GfFG

E

Gp

GnPSTN PSTN

Abis

Gb

BSS

Abislublub

RNSRNSBSS

SIM–ME I/f

or

MS

Cu

Uu

IuPSIuCSIuPS IuCS

A

Iur

Version 1 Rev 7UMTS Architecture – Release 1999



2–8

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 MultipleAccess (TDMA) based technology to access the Mobile Station whereas the RNS offersa 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 theentity responsible for communicating with Mobile Stations in a certain area. Similarly, inPLMNs supporting GPRS, the BSS is viewed by the SGSN through a single Gbinterface. The functionality for the A interface is described in GSM 08.02 and for the Gbinterface in TS 23.060. The radio equipment of a BSS may support one or more cells. ABSS 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 BaseTransceiver 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-interfaceas 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 singleIu-PS interface. The functionality for the Iu-CS interface is described in TS 25.410 andfor the Iu-PS interface in TS 23.060. The radio equipment of a RNS may support one ormore cells. A RNS may consist of one or more base stations. The RNS consists of oneRadio 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; itcomprises the Mobile Equipment (ME) and the Subscriber Identity Module (SIM), calledUser Services Identity Module (USIM) for Release 99 and following releases. The MEcomprises the Mobile Termination (MT) which, depending on the application andservices, may support various combinations of Terminal Adapter (TA) and TerminalEquipment (TE) functional groups. These functional groups are described in GSM 04.02.

Version 1 Rev 7 UMTS Architecture – Release 1999



2–9

UMTS Architecture – Release 1999

CP13_Ch2_11

GMSC GGSNAuC

HLR

EIR

SGSNVLR

MSC

VLR

MSC

SIM

ME

USIM

Um Um

CN

BSC

BTS BTS

BSC

BTS BTS

RNC

Node B Node B

RNC

Node B Node B

H Gc

GrD

C

Gi

Gs

GfFG

E

Gp

GnPSTN PSTN

Abis

GbBSS

Abislublub

RNSRNSBSS

SIM–ME I/f

or

MS

Cu

Uu

IuPSIuCSIuPS IuCS

A

Iur

Version 1 Rev 7UMTS Network – Release 1999



2–10

UMTS Network – Release 1999The diagram opposite shows a simplified schematic of a Release 1999 UMTS Network.It illustrates only those entities associated with providing a UMTS service (i.e. excludesany 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 radiosystem and the fixed networks. The MSC performs all necessary functions in order tohandle the circuit switched services to and from the mobile stations. In order to obtainradio coverage of a given geographical area, a number of base stations are normallyrequired; i.e. each MSC would thus have to interface several base stations. In additionseveral MSCs may be required to cover a country. The Mobile-services Switching Centreis an exchange which performs all the switching and signalling functions for mobilestations located in a geographical area designated as the MSC area. The main differencebetween a MSC and an exchange in a fixed network is that the MSC has to take intoaccount the impact of the allocation of radio resources and the mobile nature of thesubscribers and has to perform procedures required for the location registration (see TS23.012) and procedures required for handovers (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 toan MSC. This MSC will interrogate the appropriate HLR and then route the call to theMSC where the mobile station is located. The MSC which performs the routing functionto the actual location of the MS is called the Gateway MSC (GMSC). The acceptance ofan interrogation to an HLR is the decision of the operator. The choice of which MSCscan act as Gateway MSCs is for the operator to decide (i.e. all MSCs or somedesignated MSCs).

The Visitor Location Register (VLR)

A mobile station roaming in an MSC area is controlled by the Visitor Location Register incharge of this area. When a Mobile Station (MS) enters a new location area it starts aregistration procedure. The MSC in charge of that area notices this registration andtransfers to the Visitor Location Register the identity of the location area where the MS issituated. If this MS is not yet registered, the VLR and the HLR exchange information toallow the proper handling of calls involving the MS. A VLR may be in charge of one orseveral MSC areas. The VLR contains also the information needed to handle the callsset-up or received by the MSs registered in its database. The following elements areincluded:

� The International Mobile Subscriber Identity (IMSI);

� The Mobile Station International ISDN number (MSISDN);

� The Mobile Station Roaming Number (MSRN), see TS 23.003 for allocationprinciples;

� 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.

Version 1 Rev 7 UMTS Network – Release 1999



2–11

UMTS Network – R99

CP13_2_3a

Node B Node B

Iub Iub

RNC

UTRAN

Node B Node B

Iub Iub

RNC

HLRVLRAuC

GMSC

MSC

GGSN

SGSN

CN–CS CN–PS

CN Domain

Iu–CS Iu–PS

PSTN

OMC–T(Transport)

OMC–U(UTRAN)

Iur

Uu

User Equipment

RNS RNS

PDN

Version 1 Rev 7UMTS Network – Release 1999



2–12

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 mobilesubscribers, 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 MSCwhere the MS is registered (e.g. the MS Roaming Number, the VLR Number, theMSC Number, the Local MS Identity).

� If GPRS is supported, location information enabling the charging and routing ofmessages in the SGSN where the MS is currently registered (e.g. the SGSNNumber).

� The types of identity are attached to each mobile (e.g. International Mobile StationIdentity (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 mobilesubscriber to allow the International Mobile Subscriber Identity (IMSI) to be authenticatedand to allow communication over the radio path between the mobile station and thenetwork to be ciphered. The AuC transmits the data needed for authentication andciphering via the HLR to the VLR, MSC and SGSN which need to authenticate a mobilestation. The Authentication Centre (AuC) is associated with an HLR, and stores anidentity key for each mobile subscriber registered with the associated HLR. This key isused 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 mobilestation and the network.

The Equipment Identity Register (EIR)

The Equipment Identity Register (EIR) in the GSM system is the logical entity which isresponsible for storing in the network the International Mobile Equipment Identities(IMEIs), used in the GSM system. The equipment is classified as “white listed”, “greylisted”, “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 inthe GSM system. An EIR shall as a minimum contain a “white list” (Equipment classifiedas “white listed”). See also TS 22.016 on IMEI.

Version 1 Rev 7 UMTS Network – Release 1999



2–13

UMTS Network –R99

CP13_2_3a

Node B Node B

Iub Iub

RNC

UTRAN

Node B Node B

Iub Iub

RNC

HLRVLRAuC

GMSC

MSC

GGSN

SGSN

CN–CS CN–PS

CN Domain

Iu–CS Iu–PS

PSTN

OMC–T(Transport)

OMC–U(UTRAN)

Iur

Uu

User Equipment

RNS RNS

PDN

Version 1 Rev 7 Overview of GSN3/USP1 architecture



2–14

Overview of GSN3/USP1 architecture

Components of the GSN Complex

The GSN Complex consists of:

� C–SGSN

� GGSNs

� CommHub

� Charging Gateway (CGW)

� DNS/NTP Server

� Dynamic Load Balancer (DLB) – an optional component for improved GGSN loadbalancing .

Some of these network elements may not be present in a GSN Complex.

There may be one or more GSN Complexes in a PLMN.

The GSN Complex equipment also interfaces with other equipment that is needed for thepacket domain operation:

� RADIUS server (customer–furnished)

� DHCP server (customer–furnished)

� Firewall (customer–furnished)

� Border Gateway (customer–furnished)

� LIAN

� Bill System (BS) (customer–furnished).

Version 1 Rev 7 Overview of GSN3/USP1 architecture



2–15

Components of the GSN Complex

The GSN Complex consists of:

� C–SGSN

� GGSNs

� CommHub


� DNS/NTP Server

� Dynamic Load Balancer (DLB) – an optional component for improved GGSN load balancing.

Some of these network elements may not be present in a GSNComplex.

There may be one or more GSN Complexes in a PLMN.

The GSN Complex equipment also interfaces with otherequipment that is needed for the packet domain operation:

� RADIUS server (customer–furnished)

� DHCP server (customer–furnished)

� Firewall (customer–furnished)

� Border Gateway (customer–furnished)

� LIAN

� Bill System (BS) (customer–furnished).

CP13_Ch2_p15

Version 1 Rev 7Packet switch core network components



2–16

Packet switch core network componentsThe Motorola GSN3/USP1 solution contains the packet switch core network elements:C–SGSN and GGSN.

A number of network elements are also needed for the packet domain operation. Thesenetwork elements are:


� DNS/NTP server

� Dynamic Load Balancer (DLB) – an optional component for improved GGSN loadbalancing

� IP router/CommHub

� Motorola OMC–S/T server

� Cisco Management (CW4MW) Server

� Domain Manager Server (optional)

� O&M, consisting of the following applications:

– C–SGSN Local Manager

– CGW Local Manager

Clients for the CW4MW, Motorola OMC–S/T and Domain Manager.

Version 1 Rev 7 Packet switch core network components



2–17

Packet Switch Core Network Components

IP Backbone

FE

E1 E1

GSN Complex

FE

FW BG

CommHub/IPRouter

GGSN CGW

ATM N/W FR N/W ForeignPLMN

LIAN

DHCPServer

RNC PCU

LocationService

EIR

HLR MSC/VLR

P–SCP

PDN

RADISServer

GSN

OMC–S/TServer

BS

DNS/NTP

ServerDLB

CW4MW

Server

DMServer

SS7 N/W

SMS GMSCSMS–IWMSC

STM–1

C-–SGSN

Motorola–supplied equipment is shown at the network element(node) level. Multiplicity of links and nodes are shown withinthe GSN Complex but no inference should be drawn regardingthe exact number of links and nodes present. Customer–fur-nished equipment, non–GSN3/USP1 equipment, communica-tion networks and links connecting the above are only shownat the logical level, i.e. no inference can be drawn from thisdiagram about their physical implementation, multiplicity, etc.

Motorola supplied equipment for GSN3/USP1

Equipment outside the scope of GSN3/USP1 (typicallycutomer–furnished but some can be Motorola equip-ment (e.g. RNC and PCU)

Communication network

Version 1 Rev 7Motorola C–SGSN



2–18

Motorola C–SGSN

C–SGSN Functionality

The Common SGSN supports GPRS for GSM (that is, the Gb interface is supported bythe C–SGSN) and/or UMTS (that is, the Iu interface is supported by the C–SGSN).

The C–SGSN is the subsystem that controls the communication between the MobileSystem (MS) and a PDN host by supporting the Gb and Iu–PS interfaces to theBSS/PCU and the UTRAN, respectively, on the one side, and the Gn/Gp interface to theGGSN on the other. All bearer and control traffic from the MS and the PDN passesthrough the C–SGSN.

In the case of GPRS, the primary role of the C–SGSN is to maintain a logical link witheach MS, providing a reliable and secure data channel as the MS moves between cells.This link is implemented over the Logical Link Control (LLC) layer of the Gb interface. Inthe UMTS case, the radio resource functions are placed within the UTRAN and theC–SGSN is not involved with the radio resource allocations.

The C–SGSN mediates access to network resources on behalf of the MS andimplements the packet scheduling policy between different QoS classes. It is responsiblefor establishing the Mobility Management (MM) context upon MS attachment and thePacket Data Protocol (PDP) context with the GGSN upon activation.

The C–SGSN also collects charging data for all PDP and MM contexts and SMSsessions, generates Call Detail Records (S–CDR, M–CDR, S–SMO–CDR,S–SMT–CDR), and sends those records to the CGW utilizing the Ga interface.

Version 1 Rev 7 Motorola C–SGSN



2–19

C–SGSN Functionality

IP Backbone

FE

E1 E1

GSN Complex

FE

FW BG

CommHub/IPRouter

GGSN CGW


LIAN

DHCPServer

RNC PCU

LocationService

EIR

HLR MSC/VLR

P–SCP

PDN

RADISServer

GSN

OMC–S/TServer

BS

DNS/NTP

ServerDLB

CW4MW

Server

DMServer

SS7 N/W

SMS GMSCSMS–IWMSC

STM–1

C–SGSN

Version 1 Rev 7GGSN



2–20

GGSN

GGSN functionality

The GGSN is the logical point of PDN interconnection to a GPRS network supporting theGi reference point. This interface provides access by MS subscribers to devices attachedto one or more external PDNs. The PDP used between the MS and the external PDNhosts is currently IPv4. For a given PDP context, the MS is always anchored to oneGGSN as it moves amongst different SGSN nodes. The GGSN provides network accessto external hosts wishing to communicate with mobile subscribers. The GGSN directsmobile–terminated packets to the SGSN that is currently serving the MS, allowing theMS to move freely within the coverage area of its home or foreign network.

The GGSN provides the following primary functions:

� Layer 3 routing.

� PDP context management (manages active MS to PDN routes).

� GTP encapsulation/decapsulation at the Gn/Gp interface.

� GPRS to PS network access via the Gi interface.

� RADIUS Proxy Client interface for end user authentication and accounting.

� DHCP Proxy Client interface for end user dynamic IP address allocation.

� APN configuration for management of mode of access to a PDN.

� PDP Context Charging data collection and subsequent forwarding to a CGW.

If configured accordingly, the GGSN can implement access restriction capabilityapplicable to mobile stations outside of the home PLMN (foreign mobile stations) basedon the mobile’s Mobile Country Code (MCC) and Mobile Network Code (MNC).

The GGSN also collects charging data for all PDP contexts, creates G–CDRs, and sendsthose CDRs to the CGW over the Ga interface. The GGSN may optionally suppressrecord generation based on Charging Characteristics flags.

The GGSN provides the interface to SGSNs in the home PLMN over the Gn interfaceand to SGSNs in visited PLMNs over the Gp interface. When a GGSN is co–located withthe C–SGSN, the physical interface is frequently configured for Fast Ethernet. Anenterprise GGSN may be connected to the C–SGSN through a WAN interface (forexample, Frame Relay, ATM, and so on). The GGSN does not provide the Gc interfacein GSN3/USP1 USP1 and it relies on the C–SGSN to access the HLR on its behalf andto provide the GTP to MAP conversion.

The GPRS standards define a network identity called an Access Point Name (APN) toidentify the part of the network where a user session is established. Each GGSN isconfigured with a list of APNs that it supports. The GGSN is responsible for allocating IPaddresses to MSs as part of PDP context activation. The GGSN may be configured toaccess external support servers to provide services for the dynamic IP addressing ofMSs using the Dynamic Host Configuration Protocol (DHCP) and to provide securitysuch as authentication of users accessing a network at an APN using RemoteAuthentication Dial–In User Service (RADIUS) and AAA.

Version 1 Rev 7 GGSN



2–21

GGSN

IP Backbone

FE

E1 E1

GSN Complex

FE

FW BG

CommHub/IPRouter

GGSNCGW


LIAN

DHCPServer

RNC PCU

LocationService

EIR

HLR MSC/VLR

P–SCP

PDN

RADISServer

GSN

OMC–S/TServer

BS

DNS/NTP

ServerDLB

CW4MW

Server

DMServer

SS7 N/W

SMS GMSCSMS–IWMSC

STM–1

C–SGSN

Version 1 Rev 7Motorola Charging Gateway (CGW)



2–22

Motorola Charging Gateway (CGW)

Charging Gateway functionality

The Charging Gateway (CGW) provides a mechanism for transferring charginginformation from the SGSNs and the GGSNs to the Network Operator’s chosen BillingSystem (BS). The CGW concept enables a Network Operator to have just one logicalinterface between the CGW and the Billing System.

The CGW collects Call Detail Records (CDR) from both the C–SGSN and GGSN. CDRsare sent from both nodes to the CGW over the Ga interface using GTP’.

The CGW supports the following functions:

� CDR collection

� CDR validation

� CDR safe storage

� CDR reporting

� CDR routing (based on various criteria)

� CDR expediting (based on Charging Characteristics)

Version 1 Rev 7 Motorola Charging Gateway (CGW)



2–23

Charging Gateway (CGW)

IP Backbone

FE

E1 E1

GSN Complex

FE

FW BG

CommHub/IPRouter

GGSN CGW


LIAN

DHCPServer

RNC PCU

LocationService

EIR

HLR MSC/VLR

P–SCP

PDN

RADISServer

GSN

OMC–S/TServer

BS

DNS/NTP

ServerDLB

CW4MW

Server

DMServer

SS7 N/W

SMS GMSCSMS–IWMSC

STM–1

C–SGSN

Version 1 Rev 7Communications Hub



2–24

Communications Hub

CommHub functionality

A platform for all IP switching, the CommHub is the central connection point for allcommunication within GSN elements, and between the GSN and outside networkelements. It fulfils, among others, the functions of the backbone LAN and backbone IProuter.

The CommHub provides Ethernet connectivity, switching and IP routing capabilitybetween the network elements in the GSN Complex (that is, C–SGSN, GGSNs, CGW,DNS server, DLBs and Firewall).

The CommHub also performs IP network security functions. For example, packetaddress filtering is performed so that only those packets addressed to an MSsub–network are accepted. Packets directly addressed to one of the GSNs or to someother IP sub–network are discarded. This prevents the CommHub from being used todirectly access the GSNs, or as a relay between two external (non–GPRS) IP networks.

The IDS module provides intrusion detection by monitoring core traffic forsuspicious data signatures that would indicate a security breach. Alarmgeneration and shunning of possible attack are the main functions, but isconfigurable for more comprehensive features as required. It is shown onthe CommHub as an optional security enhancement.

Version 1 Rev 7 Communications Hub



2–25

Communications Hub

IP Backbone

FE

E1 E1

GSN Complex

FE

FW BG

GGSN CGW


LIAN

DHCPServer

RNC PCU

LocationService

EIR

HLR MSC/VLR

P–SCP

PDN

RADISServer

GSN

OMC–S/TServer

BS

DNS/NTP

ServerDLB

CW4MW

Server

DMServer

SS7 N/W

SMS GMSCSMS–IWMSC

STM–1

C–SGSN

CommHub/IPRouter

Version 1 Rev 7DNS/NTP Server



2–26

DNS/NTP Server

DNS/NTP Server functionality

The DNS/NTP Server provides the GSN system components with an internal DomainName Service (DNS) and Network Time Protocol (NTP).

The GSNs require accurate time information for generating accounting records, alarmsand logs. The Network Time Protocol (NTP) is used to synchronise the time of acomputer client or server to another server or high stratum reference time source. Itprovides client accuracies typically within a millisecond on LANs and up to a few tens ofmilliseconds on WANs, relative to a primary server synchronised to Co–ordinateUniversal Time (UTC) via a Global Positioning Service (GPS) receiver, for example.Typical NTP configurations utilize multiple redundant servers and diverse network paths,in order to achieve high accuracy and reliability.

The DNS Server provides name to IP address translation services. The two main usageof DNS within the GPRS core network is to translate routing area codes into C–SGSN IPaddresses during GPRS attach and routing area update procedures, and to translate theAccess Point Name (APN) to the IP address of a GGSN or a GGSN load balancingdevice, during the PDP context activation procedure.

The content of the GSN DNS Server is names and IP addresses associated with theGSN infrastructure equipment and its interfaces to external networks. A name can be apiece of hardware or software. Within the GPRS network a name is most commonly anyof the following:

� GGSN.

� C–SGSN.

� Module within a GGSN or C–SGSN.

� Access Point Name.

� External network link.

� Other IP end–point.

Each of these names will map to a unique IP address, which can be routed by the routingentity in the GSN (C–SGSN, Router, and so on). Hence the lookup and name resolutionservice offered by the DNS ties together the entire network and maintains connectivitybetween all components. A DNS is essential to the operation of all networks beyondthose of the most rudimentary size.

Version 1 Rev 7 DNS/NTP Server



2–27

DNS/NTP Server

IP Backbone

FE

E1 E1

GSN Complex

FE

FW BG

CommHub/IPRouter

GGSN CGW


LIAN

DHCPServer

RNC PCU

LocationService

EIR

HLR MSC/VLR

P–SCP

PDN

RADISServer

GSN

OMC–S/TServer

BS

DNS/NTP

Server

DLB

CW4MW

Server

DMServer

SS7 N/W

SMS GMSCSMS–IWMSC

STM–1

C–SGSN

Version 1 Rev 7IP Backbone



2–28

IP BackboneThe (intra–PLMN) IP Backbone interconnects the SGSNs, the GGSNs, and othernetwork elements within a PLMN, which communicate via IP. It consists of all the routers,switches, LAN, and WAN links in this IP network. The IP Backbone can be viewed as thecollection of switching/routing equipment residing in different GSN Complexes plus theWAN links interconnecting these complexes.

The external interfaces such as the Gi and the Gp interfaces need to be secure. TheGGSN provides the option of IPSec on the Gi interface via the ISA card withoutimpacting performance. For the Gp interface 3GPP recommends the use of a BorderGateway (BGW). The GSN supports this function via the use of an external routerproviding the BGW functionality. If the GGSN is located remotely then this BGW mayalso be used to provide security on the Gn interface. For additional security a Firewallfunction may need to be implemented at the network edge (optional).

In general the router shall be capable of the following functions to be configured as anedge router/FW/BGW.

� Address Filtering

� Anti–spoofing

� Intrusion Detection

� IPSec

� Routing Protocols (OSPF, RIP, and so on)

� Access Control Lists – Filtering of packets based on source and/or destination IPaddresses, connection port, application, or traffic flow direction

� Audit Trail

� NAT/PAT

Version 1 Rev 7 IP Backbone



2–29

IP Backbone

IP Backbone

FE

E1 E1

GSN Complex

FE

FW BG

CommHub/IPRouter

GGSN CGW


LIAN

DHCPServer

RNC PCU

LocationService

EIR

HLR MSC/VLR

P–SCP

PDN

RADISServer

GSN

OMC–S/TServer

BS

DNS/NTP

ServerDLB

CW4MW

Server

DMServer

SS7 N/W

SMS GMSCSMS–IWMSC

STM–1

C–SGSN

Version 1 Rev 7Border Gateway



2–30

Border Gateway

The Border Gateway provides inter–PLMN domain routing over the Gp interface, routingbetween the PLMN and PDN over the Gi interface, and potentially routing betweengeographically–separated GSN Complexes within a PLMN over the Gn interface. TheBG requires external routing using the BGP4 external routing protocol.

The Border Gateway function also provides screening and optional firewall functions TheBG resides as a logical software function or as a dedicated appliance. The BG is used forthe GSN Complex as an edge router on the IP backbone.

The Border Gateway is customer–furnished equipment. The BG used in the referenceGSN Complex architecture is a Cisco 7206VXR with NPE400 and 512MB RAM,equipped with one GE interface and two OC3 interfaces.

The deployed functions and features of the Border Gateway in a GPRSNetwork are generally the responsibility of the Network Operator. TheNetwork Operator should be compatible with the GSM Association IREGSubgroup Inter–PLMN roaming specification and comply with the GSM03.60 or 3GPP 23.060 standard.

Firewall

Firewalls (FW) are designed to protect the resources of the GSN from attempted attackson its network resources. A firewall may be implemented as a software feature that runson an IP router or as a separate, stand–alone appliance. The FW capabilities may bedesigned as a two tiered subsystem in conjunction with a BG .The BG router connectingthe outside network to the inside network provides the first layer of security. The secondlayer of the FW subsystem may use routers configured with a FW feature set or withspecialized FW appliance.

Implementing a FW will always impact performance. The more options implementedwithin the firewall the larger the impact. It is recommended that the BGW and FW beimplemented on dedicated hardware for larger systems where performance is critical. Notonly separate hardware alleviates the performance problems the separately implementedFW provides a buffer between the internal and external networks. The BGW will beaware of the addresses of the external network and the BNET/C–SGSN will be aware ofthe internal addresses and the FW can translate between the two without exposing oneto the other. All packets moving through the firewall are inspected based on theestablished security policy and filtered accordingly.

The other traffic that needs to be routed through the FW is the DNS exchanges betweenthe GSN DNS server and the external DNS servers. A DNS proxy is attached to theFirewall that is used to respond to DNS queries for inter–PLMN roaming.

The Firewall is customer–furnished equipment. The FW used in the referenceconfiguration is the Cisco PIX 535. It supports a data throughput of 1.7 Gbps maximumin clear text with reduced throughput at 170 Mbps (estimated) when IPSec support with3–DES encryption is needed. It supports, among others, the GE interface.

Version 1 Rev 7 Border Gateway



2–31

Border Gateway

IP Backbone

FE

E1 E1

GSN Complex

FE

FW BG

CommHub/IPRouter

GGSN CGW


LIAN

DHCPServer

RNC PCU

LocationService

EIR

HLR MSC/VLR

P–SCP

PDN

RADISServer

GSN

OMC–S/TServer

BS

DNS/NTP

ServerDLB

CW4MW

Server

DMServer

SS7 N/W

SMS GMSCSMS–IWMSC

STM–1

C–SGSN

Version 1 Rev 7SS7 Nodes



2–32

SS7 Nodes

Home Location Register (HLR) / Authentication Centre (AuC)

The HLR is the central repository for subscription and subscriber location information in aGSM/UMTS network. The HLR is used by both the CS domain and the PS domain.

The AuC stores the authentication key for GSM/UMTS subscribers and, on request,provides authentication vectors to the MSC and the C–SGSN for authentication of theMS’s and to enable encryption of traffic over the air interface. The AuC may beco–located with the HLR.

Mobile Switching Centre (MSC) / Visitor Location Register (VLR)

The MSC provides the CS domain switching capability in a GSM/UMTS network.

If the optional Gs interface is installed between the MSC and the C–SGSN, CSprocedures (e.g. IMSI attach, LA update, CS paging) can take place between the MSand the MSC via the C–SGSN.

The VLR contains subscription and MM state information for MS’s served by an MSC.The VLR is often co–located with the MSC.

SMS Gateway MSC (SMS–GMSC) / SMS Inter–working MSC (SMS–IWMSC)

The SMS–GMSC and the SMS–IWMSC are special nodes for handling SMS. Theyinteract with the SM–SC, the MSC and the C–SGSN for delivery of short messages.SMS can be delivered via the MSC, or via the C–SGSN if the MS, C–SGSN and theSMS–GMSC/SMS–IWMSC support delivery via the PS domain (GPRS).

The SMS–IWMSC processes MO short messages. The SMS–GMSC processes MTshort messages.

CAMEL GSM SCF / P–SCP

The CAMEL GSM SCF / P–SCP is an Intelligent Network (IN) component that supportsthe CAMEL Prepaid service logic for all GSM services (circuit switched voice & data,packet switched data and SMS). It controls the behaviour of network switching nodes(C–SGSN, MSC) related to CAMEL services supported by those nodes. For GPRS, theP–SCP supports CAMEL phase 3 logic and detection points.

Equipment Identity Register (EIR)

The EIR stores the identity of the Mobile Terminal (MT) equipment and allows the MSCand the C–SGSN to verify if an MT is invalid or black–listed.

Version 1 Rev 7 SS7 Nodes



2–33

SS7 Nodes

IP Backbone

FE

E1 E1

GSN Complex

FE

FW BG

CommHub/IPRouter

GGSN CGW


LIAN

DHCPServer

RNC PCU

LocationService

EIR

HLR MSC/VLR

P–SCP

PDN

RADISServer

GSN

OMC–S/TServer

BS

DNS/NTP

ServerDLB

CW4MW

Server

DMServer

SS7 N/W

SMS GMSC

SMS–IWMSC

STM–1

C–SGSN

Version 1 Rev 7Nodes for value added services



2–34

Nodes for value added services

Lawful Intercept Administrative Node (LIAN)

The LIAN handles the Lawful Intercept operation for the PS domain. The LIAN interactswith one or more Law Enforcement Agency (LEA) that request LI service, and with theSGSNs in the PLMN. The LIAN manages the list of MS’s for which intercept warrantshave been issued by the LEAs and distribute this list to the SGSNs. The LIAN collectsintercept reports from the SGSNs, processes the reports and deliver them to theinterested LEAs.

Gateway Mobile Location Centre (GMLC)

A Gateway Mobile Location Centre (GMLC) is the first node an external LCS clientaccesses in a PLMN (the Le reference point is supported by the GMLC). The GMLC mayrequest routing information from the HLR via the Lh interface to determine a subscriber’scurrent C–SGSN. The GMLC sends positioning requests to the C–SGSN and receivesfinal location estimates via Lg interface using MAP procedures. The C–SGSN determinesthe subscriber’s current location using one of the following methods:

For subscribers in 2G mode, the current Cell ID is reported. If the current Cell ID isunknown, then the C–SGSN sends a page request to locate the target MS.

For subscribers in 3G mode, the C–SGSN reports the service area or Cell ID in whichthe target MS is located; The C–SGSN sends a location request message to the UTRAN,which determines the location of the target MS and sends a location report to C–SGSN.

Version 1 Rev 7 Nodes for value added services



2–35

Value Added

IP Backbone

FE

E1 E1

GSN Complex

FE

FW BG

CommHub/IPRouter

GGSN CGW


LIAN

DHCPServer

RNC PCU

LocationService

EIR

HLR MSC/VLR

P–SCP

PDN

RADISServer

GSN

OMC–S/TServer

BS

DNS/NTP

ServerDLB

CW4MW

Server

DMServer

SS7 N/W

SMS GMSCSMS–IWMSC

STM–1

C–SGSN

Version 1 Rev 7GPRS/UMTS Interfaces



2–36

GPRS/UMTS Interfaces

Interface System Plane Between Protocols

Gn Both User GSNs (CSGSN to CSGSN orCSGSN to GGSN)

GTP/UDP/IP/L2/L1

Gn Both Control GSNs GTPC/UDP/IP/L2/L1

Gb GSM User/Control

CSGSN to BSS BSSGP/FR/E1

IuPS UMTS Control UTRAN to CSGSN RANAP/SCCP/SS7/ATM

IuPS UMTS User UTRAN to CSGSN GTPU/UDP/IP/AAL5/ATM

Gs Both Control CSGSN to MSC/VLR BSSAP+/SCCP/MTP3/MTP2/L1

Gd Both Control CSGSN to SMSMSC MAP/TCAP/SCCP/MTP3/MTP2/L1

Gr Both Control CSGSN to HLR MAP/TCAP/SCCP/MTP3/MTP2/L1

Ga Both User/Control

CSGSN to CGWGGSN to CGW

GTP’/UDP/IP/L2/L1

Gp Both User GSNs belonging to differentPLMNs

GTP–U/UDP/IP/L2/L1

Gp Both Control GSNs belonging to differentPLMNs

GTP–C/UDP/IP/L2/L1

Gi Both User/Control

GGSN to PDN Application/TCP(UDP)/IP/L2/L1/GRE+/PPP

Ge Both Control CSGSN to GSMSCP CAP/TCAP/SCCP/MTP3/MTP2/L1

Gf Both Control SGSN to EIR MAP/TCAP/SCCP/MTP3/MTP2/L1

CP13_Ch2_p36

Version 1 Rev 7 GPRS/UMTS Interfaces



2–37

GPRS/UMTS Interfaces

�

�(

�"

�

#

�(

��

$

&

� �#�!! #��#��'��%�#&��%��#'�%��

� �#�!! #��#'�%��

��

��

%�(

� �

�'��%��

��

��

�

��

��

��

��

#��

��

� !! #��)&'�"

�

��

�

�

�

��

�

��

Version 1 Rev 7UMTS Terrestrial Radio Access Network (UTRAN)



2–38

UMTS Terrestrial Radio Access Network (UTRAN)The UTRAN consists of a set of Radio Network Subsystems (RNSs) connected to theCore Network through the IuCS and IuPS. An RNS consists of a Radio NetworkController (RNC) and one or more Node Bs. A Node B is connected to the RNC throughthe 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. AnRNC may include a combining/splitting function to support combination/splitting ofinformation streams.

Inside the UTRAN, the RNCs of the Radio Network Subsystems can be interconnectedtogether through the Iur. Iu(s) and Iur are logical interfaces. Iur can be conveyed overdirect physical connection between RNCs or virtual networks using any suitable transportnetwork.

UTRAN Functions

The following is a list of the functions performed by the UTRAN sub-systems. Thesefunctions 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 1999.

� Broadcast/Multicast Information Distribution

� Broadcast/Multicast Flow Control

� CBS Status Reporting

Version 1 Rev 7 UMTS Terrestrial Radio Access Network (UTRAN)



2–39

UMTS Terrestrial Radio Access Network (UTRAN)

c

Node B Node B

Iub Iub

RNC

Node B Node B

Iub Iub

RNC

Core Network

Iu Iu

IurRNS RNS

Version 1 Rev 7Radio network Controller (RNC)



2–40

Radio network Controller (RNC)A Radio Network Controller (RNC) is a network component within the PLMN with thefunctions to support one or more Node B, Cell and/or User Equipment.

Typically one RNC can support up to 300 Node Bs, which in turn can provide resourcesfor up to 6 cells. However, it should be noted that the ultimate limiting factor in planningthe number of RNCs required within a PLMN will be the traffic capacity that the RNC cansupport. Typical values will start at around 1000 Erlang, rising to 10,000 Erlang asnetworks mature.

A Radio Network Controller (RNC) can be considered to operate in one or more of thefollowing 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 overallcontrol 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

Version 1 Rev 7 Radio network Controller (RNC)



2–41

UTRAN CRNC Functions

CP13_Ch2_05

Controlling of the Radio Resources

Provision of Services to the Node–B

Load and Congestion Control

Admission Control

Code Allocation for new Radio Links

·

···

·Iu

lur

Iu C–RNCC–RNC




2–42

Serving Radio Network Controller (SRNC)

A Serving RNC is the RNC located within a Serving RNS (SRNS). SRNS is a role anRNS 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 theUE.

� 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.




2–43

UTRAN SRNC Functions

CP13_Ch2_06

Termination of the Radio Resource Control Signallingbetween 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·

S–RNC

Outer Loop Power Control·Macro–diversity Combining and Splitting·




2–44

Drift Radio Network Controller (DRNC)

A Drift RNC is located within a Drift RNS. DRNS is role that an RNS can take withrespect to a specific connection between a UE and UTRAN.

A DRNS is any RNS that supports the Serving RNS by providing radio resources via thecell(s) it controls, to provide additional radio bearer services for a specific connectionbetween a UE and UTRAN.

There may be zero, one or more DRNSs associated with a specific connection betweena UE and UTRAN.

The main functions of a DRNC are:

� Macro-diversity combining and splitting.

� No L2 processing, i.e. no re-transmissions, acknowledgements or negativeacknowledgements.

� Transparent routing of data on the Iub and Iur Interfaces, except when Common orshared channels are used.




2–45

UTRAN DRNC Functions

CP13_Ch2_07

Macro–diversity Combining and Splitting

No L2 Processing

Transparent Routing except for Common/Shared Channels

···

D–RNCS–RNC

Version 1 Rev 7Node B



2–46

Node BA Node B is a logical node in the RNS that is in charge of radio transmission andreception in one or more cells. Each Node B is Identified within the UTRAN by a uniqueNode B ID. Typically a Node B will support up to six cells. Each cell is a specific radiocoverage area and is Identified by a unique Cell ID, which will be broadcast across theentire cell area.

The diagram opposite shows the typical architecture of a Motorola 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 trafficthroughput and to allow trunking across multiple carriers/sectors. This gives advantagesin terms of availability and also allows the Node B to efficiently handle non-uniform trafficdistributions. Up to 6 WDMs can be installed per Node B cabinet and the WDM is fullycompliant to the June 01 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 digitalbaseband worlds. On the forward link the WBX accepts baseband digital data from theWDM via the baseband bus, formats this data to UMTS air interface requirements, andproduces a modulated RF signal at the required carrier frequency for further amplificationand transmission via the appropriate antenna.

On the reverse link the received signals are amplified, filtered, down-converted, sampledand digitally processed. Digital data is then output to the WDMs via the baseband busfor further processing. Each WBX contains two receiver line-ups, for the main anddiversity 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 consists of either 3 or 6 hybrid matrixespower amplifiers. Each amplifier should be thought of as part of an overall poweramplification resource which can be distributed between sectors and carriers to providepower 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 tomeet new operator requirements. The input matrix accepts the composite signals foreach sector for amplification. Up to six LPA modules contribute to amplifying all signalspresented at the input ports. The output matrix ensures proper distribution of theamplified signals to the correct sector output, whilst minimising the amount of energypresented at the other sector outputs.

Version 1 Rev 7 Node B



2–47

Node B Architecture

CP13_2_7a

WBX

WDM(s)Iub

123

1231

2

3

ToAntenna

O/PMatrix

I/PMatrix

1

2

3

Trunkedlinear

123

123

123

Version 1 Rev 7User Equipment (UE)



2–48

User Equipment (UE)

Introduction to User Equipment

UMTS aims to offer service capabilities that enable a wide variety of services to beimplemented. Such services range from simple services like speech, to complexmultimedia services containing several simultaneous media components that place totallydifferent requirements on the system and on the terminal equipment. By standardisingservice capabilities rather than actual services, more flexibility is available for serviceproviders/network operators to create unique services. The same principle also appliesfor UMTS terminals, i.e. the types of terminals are not standardised and are therefore notlimited in any way. A wide range of terminal types is likely in the UMTS environment, e.g.speech only terminals, videophones, data terminals, wideband data terminals, faxterminals, multi–band/multi–mode terminals and any combination of the aforementioned.

Terminal development trends for today’s terminals are mainly towards higher integrationlevels resulting in smaller size. The goal of “four 100’s” has been a rule of thumb targetfor handsets, i.e., 100 hour standby, 100 cc size, 100 gram weight and also 100 MIPSperformance. The size targets have already been achieved and any requirement forsmaller terminals is questionable from the usability and physical size limitationsperspective. The other target parameters have no maximum limitations. On the otherhand, we can see the following further trends for near future terminals:

� Application specific terminals (smart traffic, vending machine radio, etc.);

� Increased number of value adding features (graphics, smart messaging, PCconnectivity and compatibility, memory databases, speech recognition, messagingfeatures, display functions, and different source coding methods (e.g., JPEG));

� Support for higher number of source codecs (several speech codecs);

� Multiband terminals (e.g., GSM in 900MHz and DCS1800);

� Multimode terminals (e.g., UMTS/GSM dualmode terminal);

� Dynamic SW configurability;

These trends are more than likely to continue in the future. Multiband and multimodeterminals with high integration levels would be preferred by the users. Technologicaldevelopment of these terminals relies on new packaging and interconnectiontechnologies, as well as technological steps like SW–radio. The concept trends of mobilehandheld terminals is likely to diverge from simple speech terminals towards a variety ofdifferent types, e.g., communicators, wearable phones, data terminals, etc. The dominantrole of speech terminals will be challenged in the future by these new data– andmultimedia–oriented terminals.

Version 1 Rev 7 User Equipment (UE)



2–49

User Equipment

CP13_Ch2_09

Speech Only

Videophones

Data Terminals

Wideband Data Terminals

Fax Terminals

·

···

·Application Specific Terminals·Multiband/Multimode Terminals·Dynamic Software Configurability·Value Adding Features·




2–50

UE ArchitectureThe UMTS UE will consists of a number of logical software and hardware modules.Although these modules may be delivered by a single vendor as single physical andindivisable package, it is also possible that they will be independent physical units.

The reference architecture showing the modules of the UE, along with theircorresponding network functions are illustrated opposite and described in the followingparagraphs.

Integrated Circuit (IC) CardThe IC card is the module on which are implemented the user and subscriptiondependent functions of the UE. The primary component of the IC card is the UserService Identity Module (USIM)

The mandatory requirements for IC Cards used for holding USIM application, are relatedto the need to have one USIM application on the IC card, as well as to the securityissues. The following functionality is required from the IC card holding a USIMapplication:

� Physical characteristics same as used for GSM SIM

� The support of one USIM application

� The support of one or more user profile on the USIM

� Possibility to update USIM specific information over the air, (e.g. such informationas service profile information, algorithms, etc.) in a secure and controlled manner.

� Security mechanisms to prevent USIM application specific information fromunauthorised access or alteration.

� User authentication.

In addition to the mandatory functions, the IC Card may support the following additional,optional functionality

� The support for more than one simultaneous application (Multiple USIM, Ecashand/or some other applications).

� Possibility to have shared applications/files between multiple subscriptions,including ADNs, other user/SP controlled files and data.

� Possibility for some applications/files to be restricted to one or some of thesubscriptions, under user/SP control.

� Inclusion of a payment method (electronic money and/or prepaid and/orsubscription details)

� An interface allowing highly secure downloading and configuration of newfunctionality, new algorithms and new applications into the IC card as well asupdating the existing applications, algorithms and data.

� Support for storing and possibly executing encryption related information, such askeys and algorithms.

� In multi application cards a functionality to prevent the unauthorised access andalteration of USIM specific information by other applications residing on the card.

� The ability to accept popular value–adding IC card applications, such as digitalsignature applications, EMV credit/debit card, electronic purses such as Mondexand Visacash, etc.

� Possibility for one UMTS SP to block multiple subscription on the card the SP hasissued.

Shared applications could include databases (e.g. telephone books), service profiles (e.g.controlling divert information), users preferences (e.g. short dialling codes) andSP–specific parameters inside a USIM application (e.g. call barring tables).




2–51

UE Architecture

CP13_Ch2_09b

MTRT

NT

TA

IC CARD

USIM

TERMINALEQUIPMENT

MOBILEEQUIPMENT

UTRAN

CORENETWORK

TERMINALEQUIPMENT

R

TuIu

USEREQUIPMENT

(UE)

USERAPPLICATION

USERAPPLICATION




2–52

Terminal Equipment (TE)

The TE is the part of the UE on which the users end-to-end application functionsexecute, terminating the services transported via the UMTS bearers. The TE is regardedas a service dependent component, interacting with a peer TE in the external network.

Mobile Equipment (ME)

The ME is the users subscription independent, but mobile system dependent componentof the UE. It will terminate all control plane functions and the user plane UMTS bearer.The ME consists of the following modules:

� Terminal Adaptation Function (TAF)

� Mobile Termination (MT)

TAF

The TAF provided the interaction between the TE and MT, via the R interface/referencepoint. This may include the ability of the TE to control the MT by, for example, the use ofcommands sets ( e.g. Modem AT control commands).

MT

THE MT is the telecom service independent, but UMTS dependent portion of the UEwhich terminates the radio transmissions to and from the network. Within the MT twofurther modules are defined.

The Radio Termination (RT) which is dependent upon the the radio access network. Asingle RT will provide common functions for all services using the same radio accesstechnology. For UMTS the RT terminates the UTRAN physical layer (Uu interface) andalso encompasses the the Access–Stratum layer 2 and layer three protocols (seechapter 4 for further details)

The RT interfaces to the Network Termination (NT) , at the Tu reference points. Whilethe RT is RAN dependent, the NT is CN dependent, and thus terminates, at the servingnetwork, the Non–access Stratum layer 3 protocols, for functions such as mobilitymanagement, call control, session management, etc. To fulfil many of these functions,the NT must have access to information stored on the USIM (e.g. security information),this is accessed via the interface at the Cu reference points.




2–53

UE Architecture

CP13_Ch2_09b

MTRT

NT

TA

IC CARD

USIM

TERMINALEQUIPMENT

MOBILEEQUIPMENT

UTRAN

CORENETWORK

TERMINALEQUIPMENT

R

TuIu

USEREQUIPMENT

(UE)

USERAPPLICATION

USERAPPLICATION




2–54

MT Functionality

The UMTS standards do not restrict the functionality of the terminals in any way. Thestandards should allow terminal specific features and functions to exist. However, aminimum set of mandatory functions are required in order to ensure proper behaviour ofthe system, and relate mainly to the interaction with the terminal and the network. Otheroptional features are supported by the standard, allowing additional functionality forUMTS terminals

Mandatory Functions

The following functions should be considered mandatory for all UMTS terminals:

� Terminal IC Card interface;

� SP and Network registration and deregistration;

� Location update;

� Originating or receiving a connection oriented or a connectionless service;

� An unalterable equipment identification;

� Basic identification of the terminal capabilities;

� Terminals capable for emergency calls should support emergency call without aUSIM;

� Support for the execution of algorithms required for authentication and encryption;

Additional Features

The Standard should support the following additional functionality for UMTS terminals:

� A mechanism to download service related information (parameters, scripts or evensoftware), new protocols, other functions and even new APIs into the terminal;

� An API capability to allow information transfer through a well known interface;

� Maintenance of the VHE using the same user interface and or another interfacewhile roaming;

� Optional insertion of several cards. An example scenario for this feature is a faxmachine with a multiple IC card slots, where several users could insert their ICcard and receive faxes.




2–55

UE Functions

CP13_Ch2_09c

At least one IC Card interface

SP and Network Registration/Deregistration

Location Update

MO or MT of services

Unalterable Equipment ID

·

···

·Basic ID of Equipment Capabilities·Emergency calls without USIM·Dynamic Software Configurability·Support of Authentication and Encryption·

Mandatory Functions

CP13_Ch2_09c

Support for download of service related information

API capability through well known interfaces

Support of VHE

Optional insertion of multiple IC cards

····

Optional Functions

Version 1 Rev 7Network Evolution



2–56

Network EvolutionThe 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 thesubject of staged “future” releases of 3GPP Technical Specifications, Known as Release4 (previously known as Release 2000) and Release 5. Motorola will track this evolutionthrough its core network (GSN) product, which will also evolve in a series of stages todeliver aspects of ‘all-IP’ functionality. The 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 4:

Using IP options on the open interfaces

Since most of the GPRS core network interfaces are already based on IP, this is arelatively straightforward change. For the GSN, the Iu-ps interface operates using adifferent protocol stack for signalling which uses SCTP protocol rather than C7 MTP3b atthe 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 tocarry all signalling traffic. This would require software upgrade within the GSN, and theaddition of a signalling gateway at the edge of the network to interwork between the C7and IP protocol stacks.

Initially, this reduces the need for operators to maintain a separate and expensive C7signalling network. Longer term, it also allows inter-network signalling traffic to be routedvia IP which can be secured using IPSec, both saving costs and increasing security. Forinteroperability with other vendors, existing Release 99 interfaces are retained as aconfigurable option.

Separation of bearer and control

Our GSN architecture follows the current GPRS standard that uses the same SGSNnode to handle both signalling and bearer traffic, although these are physically processedon different cards.

By ensuring there are separate routes and processing cards for both types of traffic, ahigher 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 numberof subscribers, context activations etc) and for bearer load (based on number of packetsper second, total throughput etc). A distributed GSN is also enabled at this stage, withredundant routers providing 99.999% system availability using some 99.9% availabilitycomponents.

Version 1 Rev 7 Network Evolution



2–57

Network Evolution

Ch2_08a.ai

IP Intranet

HSS/SDB

Network Control Elements

Call State Control FunctionCall Control + SGSN functionality

GPRS/UMTSIntranet

RNC Servers

Node B Node B Node B

SDUs

3G RAN

IP/ATM

OMCs

OMCsRadioSGSNGGSN

Transport

ManagementElements

GGSNGateway

PSTNGateway

C7Gateway

BorderGateway

MAP, CAMEL,

INAP

PSTNVoice

OtherPLMNGSNs

Gateways

Location

Prepaid

MExE

WAP

Feature Servers

ApplicationServersIu (cs & ps)

Other RANIur

PDNData




2–58

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 theneed for an MSC.

The evolved SGSN is termed the Call State Control Function (CSCF) and provides thecall control aspects, and along with the GGSN, also provide the functionality to allowcalls to and from IP end points that may be an IP-enabled phone, enterprise IP-basedPBX, PC, or any other voice-enabled IP device.

The PSTN gateway provides the interworking functionality for MS to PSTN, or PSTN toMS 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 avoice 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 alsoprovides 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 ofnew elements, including packet and circuit gateways and further processing. The IMoverlay uses the SIP multimedia call model, DIAMETER or RADIUS authentication andbilling, 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 ofthis technology, which takes full advantage of widespread IP deployment andaccessibility in this timeframe.

Application Servers

In addition to providing telecommunications services (Voice and data) it is envisaged thatnetwork 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 berequired.

Network services are covered in further detail in the next chapter.

Version 1 Rev 7 Network Evolution



2–59

Network Evolution

Ch2_08a.ai

IP Intranet

HSS/SDB

Network Control Elements

Call State Control FunctionCall Control + SGSN functionality

GPRS/UMTSIntranet

RNC Servers

Node B Node B Node B

SDUs

3G RAN

IP/ATM

OMCs

OMCsRadioSGSNGGSN

Transport

ManagementElements

GGSNGateway

PSTNGateway

C7Gateway

BorderGateway

MAP, CAMEL,

INAP

PSTNVoice

OtherPLMNGSNs

Gateways

Location

Prepaid

MExE

WAP

Feature Servers

ApplicationServersIu (cs & ps)

Other RANIur

PDNData




2–60



3–1

Chapter 3

Network Services

Version 1 Rev 7



3–2

Version 1 Rev 7



3–3

Chapter 3Network Services 3–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives 3–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction to Network Services 3–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Classification of Services 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multimedia services: 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supplementary services 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Teleservices 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bearer Services 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Capabilities 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Description of Services 3–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Transfer 3–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Traffic characteristics 3–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Quality 3–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Supported Bit Rates 3–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Quality of Service 3–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

QoS Attributes 3–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Security Architecture 3–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Security and Privacy 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User authentication: 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network authentication: 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Confidentiality 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data integrity 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile equipment identification 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Authentication and Key Agreement 3–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distribution of authentication data from HE to SN 3–22. . . . . . . . . . . . . . . . . . . . . . . . . . Authentication and Key Agreement 3–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ciphering Algorithms 3–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F8 3–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F9 3–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Generation of Authentication Vectors/Tokens 3–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SQN and RAND 3–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication Key Management Field 3–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Algorithms f1 –f5 3–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AUTN and AV 3–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

USIM Authentication Function 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Retrieval of SQN 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Computation of X-MAC 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verification of SQN 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Computation of CK and IK 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Authentication Response 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Access Link Data Integrity 3–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data integrity protection method 3–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Input parameters to the integrity algorithm 3–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ciphering of User/Signalling Data 3–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Input parameters to the cipher algorithm 3–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



3–4




3–1


� Describe the UMTS service objectives

� Describe the UMTS service classifications

� Describe Quality of Service Architecture

� Describe the UMTS Security Architecture

Version 1 Rev 7Introduction to Network Services



3–2

Introduction to Network ServicesThis chapter describes the Service Principles for PLMNs specified by 3GPP.

3GPP specifications provide integrated personal communications services. The systemwill support different applications ranging from narrow-band to wide-bandcommunications capability with integrated personal and terminal mobility to meet the userand service requirements of the 21st century.

3GPP specifications allow the realisation of a new generation of mobile communicationstechnology for a world in which personal communications services should allowperson-to-person calling, independent of location, the terminal used, the means oftransmission (wired or wireless) and the choice of technology. Personal communicationservices should be based on a combination of fixed and wireless/mobile services to forma 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 aneasy to use and uniform way in all environments

� To allow differentiation between service offerings of various serving networks andhome environments.

� To provide a wide range of telecommunications services, including those providedby fixed networks and requiring user bit rates of up to 2 Mbits/s, as well asservices special to mobile communications. These services should be supported inresidential, public and office environments and in areas of diverse populationdensities. These services are provided with a quality comparable with thatprovided by fixed networks such as ISDN.

� To provide services via hand held, portable, vehicular mounted, movable and fixedterminals (including those which normally operate connected to fixed networks), inall environments (in different service environments - residential, private domesticand different radio environments) provided that the terminal has the necessarycapabilities.

� To provide support of roaming users by enabling users to access services providedby 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 pedestrianuser to access all services normally provided by fixed networks.

� To provide within the office environment the capability to enable a pedestrian userto 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 regulatoryauthority.

� To provide support for interfaces which allow the use of terminals normallyconnected to fixe networks.

Version 1 Rev 7 Introduction to Network Services



3–3

UMTS Service Objectives

� Single integrated system

� Differentiation between service offerings of various serving networks andhome environments.

� A wide range of telecommunications services.

� Services via hand held, portable, vehicular mounted, movable and fixedterminals 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 fixednetworks.

� Within the office environment, all services normally provided by PBXs andLANs

� Provide a substitute for fixed networks

� Support interfaces which allow the use of terminals normally connected tofixed networks.

CP13_Ch3_p3

Version 1 Rev 7Classification of Services



3–4

Classification of Services

Multimedia services:

Multimedia services combine two or more media components (e.g. voice, audio, data,video, pictures) within one call. For some services, synchronisation between the media isnecessary (e.g. synchronised audio and video). A multimedia service may involvemultiple parties, multiple connections, and the addition or deletion of resources and userswithin a single call.

Supplementary services

A supplementary service modifies or supplements a basic telecommunication service.Consequently, it cannot be offered to a user as a stand alone service. It shall be offeredtogether or in association with a basic telecommunication service. The samesupplementary service may be applicable to a number of basic telecommunicationservices.

Teleservices

Teleservices provide the full capabilities for communications by means of terminalequipment, network functions and possibly functions provided by dedicated centres. Themethodology used covers both single media and multimedia services, the single mediaservices being a particular type of multimedia services. Multimedia services are classifiedinto categories with similar functional characteristics. The six categories are multimediaconference services, multimedia conversational services, multimedia distributionservices, multimedia retrieval services, multimedia messaging services and multimediacollection services.

Bearer Services

Bearer services provide the capability for information transfer between access points andinvolve only low layer functions.

PS and CS domains provide a specific set of bearer capabilities. The Circuit bearerservices are described in 22.002. The packet services (GPRS) is described in TS 22.060.

Service Capabilities

Service capabilities are based on functionality and mechanisms/toolkits such as providedby SAT, MExE, IN and CAMEL. These service capabilities can be made visible to theapplications through an application interface.

Version 1 Rev 7 Classification of Services



3–5

Classification of Services

� Multimedia Services

� Supplementary Services

� Teleservices

� Bearer Services

� Service Capabilities

CP13_Ch3_p5a

Definition of Teleservices and Bearer Services

TE MT PLMNpossibletransit

network

Terminatingnetwork

Bearer services

Teleservices

UE

UE: User EquipmentMT: Mobile TerminationTE: Terminal EquipmentTAF: Teminal Adaption Function

TETAF

Version 1 Rev 7Description of Services



3–6

Description of ServicesBearer services are characterised by a set of end-to-end characteristics withrequirements on QoS. The characteristics and requirements cover major networkscenarios, i.e. the cases when the terminating network is PSTN, ISDN, GSM, IPnetworks/LANs, X.25 and a PLMN.

Quality of Service is the quality of a requested service (Teleservice or Bearer Service orany other service, e.g. customer care) as perceived by the customer. QoS is alwaysmeant end-to-end. Network Performance of several network elements of the originatingand terminating network(s) contribute to the QoS as perceived by the customer includingterminals and terminal attachments. In order to offer the customer a certain QoS theserving network needs to take into account network performance components of theirnetwork, reflect the performance of the terminal and ad sufficient margin for theterminating networks in case network performance requirements cannot be negotiated.

As far as the QoS to the subscriber is concerned network elements have to providesufficient performance (reflecting possible performance constraints in terminatingnetworks) so that the PLMN cannot be considered as a bottleneck.

This section outlines the requirements on bearer services in two main groups;

� Requirements on information transfer,

� Information quality characteristics, which describe the quality of the userinformation transferred between two or more access points.

It shall be possible to negotiate / re negotiate the characteristics of a bearer service atsession / connection establishment and during an on going session / connection.

Information TransferRequirements on information transfer, which characterise the networks transfercapabilities for transferring user data between two or more access points. Thesecharacteristics include the following:

Connection oriented / connectionless servicesBoth Connection oriented and connectionless services shall be supported.

Traffic type. It is required that the bearer service provides one of the following:

� guaranteed/constant bit rate,

� non-guaranteed/dynamically variable bit rate

� real time dynamically variable bit rate with a minimum guaranteed bit rate.

Real time and non real time applications shall be supported.

Real time video, audio and speech shall be supported. This implies the:

� ability to provide a real time stream of guaranteed bit rate, end to end delay anddelay variation.

� ability to provide a real time conversational service of guaranteed bit rate, end toend delay and delay variation.

Non real time interactive and file transfer service shall be supported. This implies the:

� ability to support message transport with differentiation as regards QoS betweendifferent users.

Multimedia applications shall be supported. This implies the:

� ability to support several user flows to/from one user having different traffic types(e.g. real time, non real time)

Version 1 Rev 7 Description of Services



3–7

Information Transfer Characteristics

CP13_Ch3_18

Connection Oriented Services

Connectionless Services

Bearer Service must provide one of the following

Guaranteed/Constant Bit Rate

Non–guaranteed/Dynamically Variable Bit Rate

Real Time/Dynamically Variable Bit Rit With Minimum Guaranteed Bit Rate

Real Time Video, Audio and Speech

Non Real Time Interactive and File Transfer Services

Multimedia Applications




3–8

Traffic characteristics

It shall be possible for an application to specify its traffic requirements to the network byrequesting a bearer service with one of the following configurations

Point-to-Point

� Uni-Directional

� Bi-Directional

Symmetric

Asymmetric

Uni-Directional Point-to-Multipoint

� Multicast

� Broadcast

A multicast topology is one in which sink parties are specified before the connection isestablished, or by subsequent operations to add or remove parties from the connection.The source of the connection shall always be aware of all parties to which the connectiontravels.

A broadcast topology is one in which the sink parties are not always known to the source.The connection to individual sink parties is not under the control of the source, but is byrequest of each sink party.




3–9

Traffic Characteristics

CP13_Ch3_19

Point–to–Point

Uni–Directional

Bi–Directional

Symetric

Asymmetric

Uni–Directional Point–to–Multipoint

Multicast

Broadcast




3–10

Information Quality

Information quality characterises the bit integrity and delay requirements of theapplications.

Maximum transfer delay

Transfer delay is the time between the request to transfer the information at one accesspoint to its delivery at the other access point.

Delay variation

The delay variation of the information received information over the bearer has to becontrolled to support real-time services. The possible values for delay variation are not alimited set, but a continuous range of values.

Bit error ratio

The ratio between incorrect and total transferred information bits. The possible values forBit error ratio are not a limited set, but a continuous range of values.

Data rate

The data rate is the amount of data transferred between the two access points in a givenperiod of time.




3–11

Information Quality Characteristics

Errortolerant

Errorintolerant

Conversational(delay <<1 sec)

Interactive Streaming Background(delay >10 sec)

Conversationalvoice and video

Voice messagingStreaming audio

and videoFax

E–mail arrivalnotificationFTP, still image,

paging

E–commerce,WWW browsing,Telnet,

interactive games

(delay approx 1 sec) (delay 10 sec)

CP13_Ch3_p11

Version 1 Rev 7Supported Bit Rates



3–12

Supported Bit RatesIt shall be possible for one application to specify its traffic requirements to the network byrequesting a bearer service with any of the specified traffic type, traffic characteristics,maximum transfer delay, delay variation, bit error ratios & data rates. The network shouldsatisfy these requirements without wasting resources on the radio and network interfacesdue to granularity limitations in bit rates.

It is possible for one mobile termination to have several active bearer servicessimultaneously, each of which could be connection oriented or connectionless.

The only limiting factor for satisfying application requirements shall be the cumulative bitrate per mobile termination at a given instant (i.e. when summing the bit rates of onemobile termination’s simultaneous connection oriented and connectionless traffic,irrespective of the traffic being real time or non real time) in each radio environment:

� At least 144 kbits/s in rural outdoor radio environment.

� At least 384 kbits/s in urban/suburban outdoor radio environments.

� At least 2048 kbits/s in indoor/low range outdoor radio environment.

Version 1 Rev 7 Supported Bit Rates



3–13

Supported Bit Rates

CP13_Ch3_08

At Least 144 Kbps in Rural Outdoor Radio Environments(<500km/h)

At Least 384 Kbps in Urban/Suburban Outdoor Radio Environments(<100km/h)

At Least 2048 Kbps in Indoor/Low Range Outdoor Radio Environments(<10km/h)

···

Version 1 Rev 7Quality of Service



3–14

Quality of ServiceNetwork 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 heis satisfied with the provided QoS or not. To realise a certain network QoS a BearerService with clearly defined characteristics and functionality is to be set up from thesource to the destination of a service. The diagram opposite illustrates the QoS classesfor UMTS.

The main distinguishing factor between these QoS classes is how delay sensitive thetraffic is: Conversational class is meant for traffic which is very delay sensitive whileBackground class is the most delay insensitive traffic class.

Conversational and Streaming classes are mainly intended to be used to carry real-timetraffic flows. Interactive class and Background are mainly meant to be used by traditionalInternet applications like WWW, Email, Telnet, FTP and News. Due to looser delayrequirements, compared to conversational and streaming classes, both provide bettererror 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 withInternet and multimedia a number of new applications will require this scheme, forexample voice over IP and video conferencing tools. Real time conversation is alwaysperformed between peers (or groups) of live (human) end-users. This is the only schemewhere the required characteristics are strictly given by human perception. (e.g. The realtime data flow is always aiming at a live (human) destination).

Interactive class

Interactive traffic is the other classical data communication scheme that on an overalllevel is characterised by the request response pattern of the end-user. At the messagedestination 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 thatthe content of the packets shall be transparently transferred (with low bit error rate).Examples are: web browsing, data base retrieval, server access.

Streaming Class

This scheme is one of the newcomers in data communication, raising a number of newrequirements in both telecommunication and data communication systems. It ischaracterised by the fact that the time relations (variation) between information entities(i.e. samples, packets) within a flow shall be preserved, although it does not have anyrequirements on low transfer delay. The delay variation of the end-to-end flow shall belimited, to preserve the time relation (variation) between information entities of thestream. When the user is looking at (listening to) real time video (audio) the scheme ofreal time streams applies.

Background Task

Background traffic is one of the classical data communication schemes that on an overalllevel is characterised by that the destination is not expecting the data within a certaintime. The scheme is thus more or less delivery time insensitive. Another characteristic isthat the content of the packets shall be transparently transferred (with low bit error rate).

Examples are background delivery of E-mail notification, SMS, download of databasesand reception of measurement records.

Version 1 Rev 7 Quality of Service



3–15

Quality of Services

CP13_Ch3_9a.ai

Quality of Service Classes

ConversationalConversational Voice

Videophone, interactive Games

StreamingAudio/Video Streaming, FTP

InteractiveVoice Mesaging

Web Browsing, E–Commerce

BackgroundE–mail Arrival Notification

Fax

Maximum bitrateGuaranteed bitrateDelivery orderMaximum SDU sizeSDU format information bitsSDU error ratioResidual bit error ratioDelivery of erroneous SDUsTransfer DelayTraffic Handling PriorityAllocation/Retention Priority

Still Image, Paging

Version 1 Rev 7QoS Attributes



3–16

QoS AttributesUMTS bearer service attributes describe the service provided by the UMTS network tothe user of the UMTS bearer service. A set of QoS attributes (QoS profile) specifies thisservice.

Maximum bitrate (kbps)

Maximum number of bits delivered by UMTS and to UMTS at a SAP within a period oftime, 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 (providedthat 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 definedonly for conforming traffic.

Residual bit error ratio

Indicates the undetected bit error ratio in the delivered SDUs. If no error detection isrequested, 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 deliveredSDUs during the lifetime of a bearer service, where delay for an SDU is defined as thetime 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 bearercompared to the SDUs of other bearers.

Allocation/Retention Priority

Specifies the relative importance compared to other UMTS bearers for allocation andretention of the UMTS bearer. The Allocation/Retention Priority attribute is a subscriptionattribute which is not negotiated from the mobile terminal.

Version 1 Rev 7 QoS Attributes



3–17

UMTS Bearer QoS Attributes

CP13_Ch3_10a.ai

Traffic Class

Maximum bitrate

Delivery order

Maximum SDU size

SDU format information

SDU error ratio

Residual bit error ratio

Delivery of erroneous SDUs

Transfer delay

Guaranteed bit rate

Traffic handling priority

Allocation/Retention priority

Conversationalclass

Streamingclass

Interactiveclass

Backgroundclass

X X X XX X X XX X X X

X X X XX X X XX X X X

X X X XX

X XX X

X X

Version 1 Rev 7The Security Architecture



3–18

The Security ArchitectureFive security feature groups are defined. Each of these feature groups meets certainthreats, accomplishes certain security objectives:

Network access security (I): the set of security features that provide users with secureaccess 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 theprovider domain to securely exchange signalling data, and protect against attacks on thewireline network.

User domain security (III): the set of security features that secure access to mobilestations.

Application domain security (IV): the set of security features that enable applications inthe user and in the provider domain to securely exchange messages.

Visibility and configurability of security (V): the set of features that enables the user toinform himself whether a security features is in operation or not and whether the use andprovision of services should depend on the security feature.

Version 1 Rev 7 The Security Architecture



3–19

The Security Architecture

CP13_Ch3_12

Application Stratum

Transport Stratum

Home Stratum/ Serving Stratum

AN

(IV)

(I) (III) (V)

(I) (I)

(I)

(II)

(I)MT

TE USIM

User Application Provider Application

SN

HE

Version 1 Rev 7Security and Privacy



3–20

Security and Privacy

User authentication :

The property that the serving network (SN) corroborates the identity of the user;

Network authentication :

The property that the user corroborates that he is connected to a serving network that isauthorised by the users HE to provide him services; this includes the guarantee that thisauthorisation is recent.

Confidentiality

Cipher algorithm agreement: the property that the MS and the SN can securelynegotiate the algorithm that they shall use subsequently;

Cipher key agreement : the property that the MS and the SN agree on a cipher key thatthey may use subsequently;

Confidentiality of user data: the property that user data cannot be overheard on theradio access interface;

Confidentiality of signalling data: the property that signalling data cannot beoverheard on the radio access interface.

Data integrity

Integrity algorithm agreement: the property that the MS and the SN can securelynegotiate the integrity algorithm that they shall use subsequently;

Integrity key agreement: the property that the MS and the SN agree on an integrity keythat they may use subsequently;

Data integrity and origin authentication of signalling data: the property that thereceiving entity (MS or SN) is able to verify that signalling data has not been modified inan unauthorised way since it was sent by the sending entity (SN or MS) and that the dataorigin of the signalling data received is indeed the one claimed.

Mobile equipment identification

In certain cases, SN may request the MS to send it the mobile equipment identity of theterminal. The mobile equipment identity shall only be sent after authentication of SN withexception of emergency calls. The IMEI should be securely stored in the terminal.However, the presentation of this identity to the network is not a security feature and thetransmission of the IMEI is not protected. Although it is not a security feature, it shouldnot be deleted from UMTS however, as it is useful for other purposes.

Version 1 Rev 7 Security and Privacy



3–21

Security and Privacy

� User Authentication� Network Authentication� Confidentiality� Data integrity� Mobile equipment identification

CP13_Ch3_p21

Version 1 Rev 7Authentication and Key Agreement



3–22

Authentication and Key AgreementAuthentication and Key Agreement (AKA) achieves mutual authentication by the userand the network showing knowledge of a secret key K which is shared between andavailable only to the USIM and the AuC in the user’s HE. In addition the USIM and theHE keep track of counters SEQMS and SEQHE respectively to support networkauthentication. The method was chosen in such a way as to achieve maximumcompatibility with the current GSM security architecture and facilitate migration fromGSM to UMTS. The method is composed of a challenge/response protocol identical tothe GSM subscriber authentication and key establishment protocol combined with asequence number-based one-pass protocol for network authentication derived from theISO 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 nauthentication vectors (the equivalent of a GSM “triplet”) to the VLR/SGSN. Eachauthentication vector consists of the following components: a random number RAND, anexpected response XRES, a cipher key CK, an integrity key IK and an authenticationtoken AUTN. Each authentication vector is good for one authentication and keyagreement between the VLR/SGSN and the USIM.

Authentication and Key Agreement

When the VLR/SGSN initiates an authentication and key agreement, it selects the nextauthentication vector from the array and sends the parameters RAND and AUTN to theuser. The USIM checks whether AUTN can be accepted and, if so, produces a responseRES 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/SGSNconsiders 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/SGSNto the entities which perform ciphering and integrity functions.

Version 1 Rev 7 Authentication and Key Agreement



3–23

Authentication and Key Agreement

CP13_Ch3_13a

MS SN/VLR HE/HLR

Authentication request

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

RES(i)

Compare RES(i) and XRES(i)

Compute CK(i) and IK(i) Select CK(i) and IK(i)

Distribution authentication vectors

from HE to SN

Authentication Key

Generate vectors AV (1 . . . n)

Version 1 Rev 7Ciphering Algorithms



3–24

Ciphering AlgorithmsThe ciphering algorithms used in UMTS are shown on the slide opposite. As can be seena lot of different algorithms are active in the UMTS system. Algorithms f1 to f5 are of thetype that are used to compute numbers in use for authentication procedures, they will bediscussed in the UMTS Advanced courses.

Two very important algorithms, f8 and f9 are also shown, they have the followingfunctions.

F8

This algorithm will perform the ciphering function. The ciphering function is performedeither 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 isperformed in the RLC sub-layer.

� If a radio bearer is using the transparent RLC mode, ciphering is performed in theMAC sub-layer (MAC-d entity).

Ciphering when applied is performed in the S-RNC and the ME and the context neededfor 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 thenetwork are considered sensitive and must be integrity protected. Therefore a messageauthentication function has been developed to solve this problem. The MS will still gothrough the initial RRC connection establishment sequence and perform the set-upsecurity functions. After this however some signalling messages will be encoded usingthe 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 integrityprotection procedure.

AK Anonymity Key

AKA Authentication andkey agreement

AUTN AuthenticationToken

MAC The messageauthentication codeincluded in AUTN,computed using f1

XRES Expected Response

Version 1 Rev 7 Ciphering Algorithms



3–25

Ciphering Algorithms

CP13_Ch3_14

F1 – Message authentication function used to compute MAC·

F3 – Key generating function used to compute CK·F2 – Message authentication function used to compute RES and XRES·F1* – Message authentication function used to compute MAC–S·

F5* – Key generating function used to compute AK in re–synchronisation procedures·F5 – Key generating function used to compute AK in normal procedures·F4 – Key generating function used to compute IK·

K–Long–term secret key shared between the USIM and the AuC·

F9 – Signalling elements between the UE and RNC·F8 – Data transfer between the UE and RNC·

Version 1 Rev 7Generation of Authentication Vectors/Tokens



3–26

Generation of Authentication Vectors/TokensUpon the receipt of the authentication data request from the VLR/SGSN, the HE mayhave pre-computed the required number of authentication vectors and retrieve them fromthe HLR database or may compute them on demand. The HE/AuC sends anauthentication response back to the VLR/SGSN that contains an ordered array of nauthentication vectors AV(1..n). The diagram opposite shows the generation of anauthentication vector AV by the HE/AuC.

SQN and RAND

The HE/AuC starts with generating a fresh sequence number SQN and an unpredictablechallenge 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 clockgiving 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 thealgorithms 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 thealgorithm and key used to generate a particular authentication vector, or set the numberof 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 amessage authentication function.

An expected response XRES = f2K (RAND) where f2 is a (possibly truncated) messageauthentication 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 theauthentication Vector (AV:=RAND||XRES||CK||IK||MAC) are constructed from theproducts of the algorithms.

Here, AK is an anonymity key used to conceal the sequence number as the latter mayexpose the identity and location of the user. The concealment of the sequence number isto protect against passive attacks only. If no concealment is needed then f5 ≡ 0 (AK =0).

Version 1 Rev 7 Generation of Authentication Vectors/Tokens



3–27

Generation of Authentication Vectors/Tokens

CP13_Ch3_14a

Generate SQN

Generate RAND

f1

AMF

SQN RAND

K

AUTN := SQN ⊕ AK || AMF || MAC

AV := RAND || XRES || CK || IK || AUTN

MAC XRES CK IK AK

f2 f3 f4 f5

Version 1 Rev 7USIM Authentication Function



3–28

USIM Authentication FunctionThe VLR/SGSN invokes the procedure by selecting the next unused authenticationvector from the ordered array of authentication vectors in the VLR/SGSN database. TheVLR/SGSN sends to the USIM the random challenge RAND and an authentication tokenfor 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 withMAC which is included in AUTN. If they are different, the user sends user authenticationreject back to the VLR/SGSN with an indication of the cause and the user abandons theprocedure. In this case, VLR/SGSN shall initiate an Authentication Failure Reportprocedure towards the HLR. VLR/SGSN may also decide to initiate a new identificationand 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 sendssynchronisation failure back to the VLR/SGSN including an appropriate parameter, andabandons the procedure.

If the sequence number is considered to be in the correct range however, the USIMcomputes RES = f2K (RAND) and includes this parameter in a user authenticationresponse 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 theexpected response XRES from the selected authentication vector. If XRES equals RESthen the authentication of the user has passed. The VLR/SGSN also selects theappropriate 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 Reportprocedure towards the. VLR/SGSN may also decide to initiate a new identification andauthentication procedure towards the user.

Version 1 Rev 7 USIM Authentication Function



3–29

USIM Authentication Function

CP13_Ch3_15a

f1

SQN ⊕ AK

RAND

K

Verify MAC = XMAC

Verify that SQN is in the correct range

XMAC RES CK IK

AK

f2 f3 f4

f5

AUTN

⊕

SQN

AMF MAC

(USIM)

Version 1 Rev 7Access Link Data Integrity



3–30

Access Link Data IntegrityMost control signalling information elements that are sent between the MS and thenetwork are considered sensitive and must be integrity protected. A messageauthentication function shall be applied on these signalling information elementstransmitted between the ME and the RNC.

Data integrity protection method

The diagram opposite illustrates the use of the integrity algorithm f9 to authenticate thedata integrity of a signalling message. Based on the input parameters the user computesmessage authentication code for data integrity MAC-I using the integrity algorithm f9. TheMAC-I is then appended to the message when sent over the radio access link. Thereceiver computes XMAC-I on the message received in the same way as the sendercomputed MAC-I on the message sent and verifies the data integrity of the message bycomparing 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 valueper logical signalling channel. COUNT-I is derived from a count of the number of RRCSDUs send/received.

IK

The integrity key IK is 128 bits long. There may be one IK for CS connections (IKCS) andone IK for PS connections (IKPS). IK is established during UMTS AKA as the output ofthe integrity key derivation function f4.

FRESH

The network-side nonce FRESH is 32 bits long. There is one FRESH parameter valueper user. The input parameter FRESH protects the network against replay of signallingmessages by the user. At connection set-up the RNC generates a random value FRESHand sends it to the user in the (RRC) security mode command. The value FRESH issubsequently used by both the network and the user throughout the duration of a singleconnection. This mechanism assures the network that the user is not replaying any oldMAC-Is.

DIRECTION

The direction identifier DIRECTION is 1 bit long. The direction identifier is input to avoidthe use of identical set of input parameter values up-link and down-link messages. Thevalue of the DIRECTION is 0 for messages from UE to RNC and 1 for messages fromRNC to UE.

MESSAGE

The signalling message itself with the radio bearer identity. The latter is appended in frontof the message. Note that the radio bearer identity is not transmitted with the messagebut it is needed to avoid that for different instances of message authentication codes thesame set of input parameters is used.

Version 1 Rev 7 Access Link Data Integrity



3–31

Access Link Data Integrity

CP13_Ch3_16a

COUNT–I

MESSAGE

DIRECTION

FRESH

f9

MAC–I

SenderUE or RNC

COUNT–I

MESSAGE

DIRECTION

FRESH

f9

XMAC–I

ReceiverRNC or UE

IK IK

Version 1 Rev 7Ciphering of User/Signalling Data



3–32

Ciphering of User/Signalling DataUser data and some signalling information elements are considered sensitive and mustbe 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 timeswhen the signalling procedures permit it.

These needs for a protected mode of transmission are fulfilled by a confidentialityfunction 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 plaintextby applying a keystream using a bit per bit binary addition of the plaintext and theciphertext. The plaintext may be recovered by generating the same keystream using thesame 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 valueper logical signalling channel. COUNT-C is derived from a count of the number ofRLC/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 theoutput 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 andmultiplexed on a single 10ms physical layer frame. The radio bearer identifier is input toavoid 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 avoidthe use of identical set of input parameter values up-link and down-link messages. Thevalue of the DIRECTION is 0 for messages from UE to RNC and 1 for messages fromRNC to UE.

LENGTH

The length indicator LENGTH is 16 bits long. The length indicator determines the lengthof the required keystream block. LENGTH shall affect only the length of theKEYSTREAM BLOCK, not the actual bits in it.

Version 1 Rev 7 Ciphering of User/Signalling Data



3–33

Ciphering of User/Signalling Data

CP13_Ch3_17

Sender UE or RNC

Receiver RNC or UE

COUNT–C

BEARER

DIRECTION

LENGTH

f8CK

COUNT–C

BEARER

DIRECTION

LENGTH

f8CK

KEYSTREAM BLOCK

⊕PLAINTEXT BLOCK

KEYSTREAM BLOCK

⊕CYPHERTEXT BLOCK

Version 1 Rev 7Ciphering of User/Signalling Data



3–34



4–1

Chapter 4

UMTS Protocols

Version 1 Rev 7



4–2

Version 1 Rev 7



4–3

Chapter 4UMTS Protocols 4–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives 4–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction to UMTS Protocols 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access Stratum 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Non-Access Stratum 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General Protocol Model 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Horizontal Layers 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vertical Planes 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IuCS Protocol Structure 4–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control Plane Protocol Stack 4–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport Network Control Plane Protocol Stack 4–6. . . . . . . . . . . . . . . . . . . . . . . . . . User Plane Protocol Stack 4–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IuPS Protocol Structure 4–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control Plane Protocol Stack 4–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport Network Control Plane Protocol Stack 4–8. . . . . . . . . . . . . . . . . . . . . . . . . . User Plane Protocol Stack 4–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Iub Protocol Structure 4–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control Plane Protocol Stack 4–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport Network Control Plane Protocol Stack 4–10. . . . . . . . . . . . . . . . . . . . . . . . . . User Plane Protocol Stack 4–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Iur Protocol Structure 4–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control Plane Protocol Stack 4–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport Network Control Plane Protocol Stack 4–12. . . . . . . . . . . . . . . . . . . . . . . . . . User Plane Protocol Stack 4–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Radio Interface Protocol Architecture 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RRC Functions 4–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Protocol Stacks 4–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Plane Protocol Stack (Dedicated Channels CS-Domain) 4–26. . . . . . . . . . . . . . . Dedicated Channel Frame Protocol (DCH FP) 4–28. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Control Plane Protocol Stack (UE-CN SIGNALLING, Dedicated Channels, CS-Domain) . . . . . . . 4–30

RANAP Services 4–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SCCP 4–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MTP3-B 4–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SAAL-NNI 4–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



4–4

Control Plane Protocol Stack(UE-CN Signalling, Shared Channels, CS-Domain) 4–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RACH/FACH/ DSCH Frame Protocol 4–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

User Plane Protocol Stack(Dedicated Channels, PS-Domain) 4–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

GPRS Tunnelling Protocol, User Plane (GTP-U) 4–34. . . . . . . . . . . . . . . . . . . . . . . . . . . Path Protocols 4–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Control Plane Protocol Stack(UE-CN Signalling, Dedicated Channels, PS-Domain) 4–36. . . . . . . . . . . . . . . . . . . . . . . . . . .

Stream Control Transmission Protocol 4–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . M3UA 4–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .




4–1


� 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

� Describe the Radio Interface Protocol Architecture

� Describe the functions and service provided by the following Radio InterfaceProtocols:

Medium Access Control (MAC)

Radio Link Control (RLC)

Packet Data Convergence Protocol (PDCP)

Broadcast Multicast (BMC)

Radio Resource Control (RRC)

� Describe selected end-to-end protocol stacks

Version 1 Rev 7Introduction to UMTS Protocols



4–2

Introduction to UMTS Protocols

As has been outlined in previous chapters, one of the underlying principles in the designand development of UMTS is to prepare a universal infrastructure able to carry bothexisting and future services. All design work should be such that technological andevolution changes in one part of the network should have no (or at least minimal impacton other network components or services.

From a protocol perspective, this is acheived by confining , as far as is reasonablypracticable, protocol functions and services within on or several physical domains. Tothis end, the 3G protocol arch itecture can be divided into two strata.

� Access Stratum

� Non-Access Stratum

Access Stratum

The Access Startum (AS) is a functional entity that encompasses radio protocolsbetween the UE and the UTRAN and, terrestrial interface (Iu) protocols between theUTRAN and the Core Network (CN). These protocols all terminate within the UTRAN.

Non-Access Stratum

The Non-access Stratum (NAS) includes CN protocols that form a direct connectionbetween the UE and the CN itself. The NAS is transparent to the UTRAN and thus theseprotocols do not terminate in the UTRAN.

The NAS protocols encompass functions such as; Mobility Management (MM), CallControl (CC), Short Message Services (SMS) and Suplementary Services (SS)associated with the circuit switched CN and, GPRS Mobility Management (GMM),Session Managment (SM) and GPRS SMS assocoiated with the packet switched CN.

The NAS tries to remain independent of the underlying radio technology. Thus the NASprotocols can remain unchanged regardless of the radio access network (RAN) thatcarries them

Version 1 Rev 7 Introduction to UMTS Protocols



4–3

UMTS Protocol Architecture

CP13_Ch4_00

CoreNetworkProtocols

CoreNetworkProtocols

RadioProtocols

RadioProtocols

IuProtocols

IuProtocols

Access Stratum

Non–Access Stratum

UE UTRAN Core Network

Uu–Interface Iu–Interface

Version 1 Rev 7General Protocol Model



4–4

General Protocol ModelThe Protocols in the UTRAN are designed according to a set protocol model. Thestructure consists of Layers (Horizontal) and Planes (Vertical). All these entities areindependent of each other and can be changed at any time. It is also important to notethat 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 atthe Layers and Planes.

Horizontal LayersThe General protocol stack only consists of two layers, the Transport Network Layer andthe Radio Network Layer. From the bottom, the Physical layer (Part of the TransportNetwork Layer) will provide the physical medium for transmission. Above the Physicallayer is the Transport layer (Part of the Transport Network Layer) which contains thetransport protocols. These protocols are not defined within the UMTS specifications. TheTransport Network Protocol proposed for UMTS is ATM. The top layer is called the RadioNetwork layer, this is the layer responsible for all UTRAN related tasks. The tasksperformed 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 allUMTS specific signalling. The protocols used for the control plane are the RANAPprotocol for the Iu interface, the RNSAP protocol for the Iur interface and the NBAPprotocol for the Iub interface. These are all termed Application protocols and will be usedfor tasks like setting up bearers to the UE. Operation & Maintenance actions will alwaysset 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 theData Bearer. Each Data Stream is identified and characterised by one or more frameprotocols.

Transport Network Control Plane

This plane is used for all signalling that must be transferred in the Transport Layer anddoes not include any Radio Network Layer information. The protocol used for the ControlPlane is called Access Link Control Application Protocol (ALCAP). This protocol willhandle the setting up of Data Bearers for the User Plane of the Transport layer. Theintroduction of the ALCAP protocol made it possible for the Application Protocols to runwith complete independence of the data bearing technology. It should be noted that weshall not use the ALCAP protocol in the setting up of the Signalling Bearers for theApplication Protocols or for ALCAP.

Transport Network User Plane

Both the Signalling Bearer (for Applicatio Protocol) in the Control Plane and the DataBearer in the User Plane belong to the Transport Network Layer. The Data bearers in theTransport Network User Plane are directly controlled by the Transport Network ControlPlane during real time operations. The control of the Signalling Bearer(s) for ApplicationProtocol are considerede Operations and Maintainance functions.

Version 1 Rev 7 General Protocol Model



4–5

General Protocol Model

CP13_Ch4_01

Radio Network

Layer

Transport Network

Layer

Control Plane

Application Protocol

Signalling Bearer(s)


ALCAP(S)

Signalling Bearer(s)

User Plane

Data Stream(s)

Data Bearer(s)

Physical Layer



Version 1 Rev 7IuCS Protocol Structure



4–6

IuCS Protocol StructureAs can be seen form the IuCS protocol stack, it resembles the UMTS Protocol Modelvery closely and so it will be the case for all other Interfaces. Two different layers can bedetected, the Transport Network Layer and the Radio Network Layer. The Physical layerin 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 isthat 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 NetworkApplication 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 UEs

� 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 Networkto Network Interfaces

SSCF Service Specific Co-ordination functions

SSCOP Service Specific Connection OrientatedProtocol

AAL5 ATM Adaptation Layer 5

Transport Network Control Plane Protocol Stack

The Transport Network Protocol Stack consists of Signalling protocols for setting up ofthe AAL2 Connections in the User Plane. Again broad band SS7 signalling protocols arebeing used.

User Plane Protocol Stack

This is a very simple combination of protocols with the User plane being directly on top ofAAL2, which is responsible for segmenting the data to ATM cells. Note that a dedicatedAAL2 connection will be reserved for each user’s CS service.

Version 1 Rev 7 IuCS Protocol Structure



4–7

IuCS Protocol Structure

CP13_Ch4_02

Radio Network

Layer

Transport Network

Layer

Control Plane

RANAP


AAL5

User Plane

Iu UP Protocol Layer

Physical Layer

SCCP

MTP3b

SSCF–NNI

SSCOP

ATM

AAL5

SSCF–NNI

MTP3b

Q.2150.2

SSCOP

Q.2630.1

AAL2



Version 1 Rev 7IuPS Protocol Structure



4–8

IuPS Protocol StructureAgain, two different layers can be detected, the Transport Network Layer and the RadioNetwork Layer. The Physical layer in the Transport Network Layer consist of normal OSIL1 specified protocols like E1, STM, Fibre Optic or even Microwave.


The Protocol used on the Radio Network Layer is again RANAP and the functions arethe same then for the IuCS.

The broad band 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 forpacket switched information.

M3UA SS7 and MTP3b User Adaptation Layer

SCTP Stream Control Transmission Protocol (Designed forsignalling transport in the Internet)

IP Internet Protocol


This Plane is not applied to the IuPS.


Normal GPRS Tunnelling Protocol (GTP) tunnelling will be used over User DatagramProtocol (UDP) which is a connectionless protocol. Multiple packets and flows will bemultiplexed on one or more AAL.

Version 1 Rev 7 IuPS Protocol Structure



4–9

IuPS Protocol Stack

CP13_Ch4_03

Radio Network

Layer

Transport Network

Layer

Control Plane

RANAP


AAL5

User Plane

Iu UP Protocol Layer

SSCOP

AAL5



Physical Layer

ATM

Physical Layer

IP

UDP

GTP–U

SSCF–NNI

ATM

IP

M3UA

SCCP

MTP3b

SCTP

Version 1 Rev 7Iub Protocol Structure



4–10

Iub Protocol StructureAs with the Iu interface, two different layers can be detected, the Transport NetworkLayer and the Radio Network Layer. The Physical layer in the Transport Network Layerconsist of normal OSI L1 specified protocols like E1, STM, Fibre Optic or evenMicrowave. On OSI L2 is the ATM protocol, one thing to note is that the first two OSIlayers will form a common bearer for all three planes above.


The Protocol used on the radio Network Layer is called NBAP. This protocol is in turndivided into the Common NBAP (C-NBAP) and Dedicated NBAP (D-NBAP). TheC-NBAP defines all common procedures carried out like Operations & Maintenance taskthrough channels like Random Access Channel (RACH) and PAging Channel (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 Initialization of Node-B and/or Cell specific measurements

The main functions of D-NBAP are:

� Set-up, 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

� Downlink Power Drifting Correction

� Radio link Fault Management


Again the usage of broad band SS7 signalling can be seen.


The User Plane Protocol Stack consists of all the Control and User frame protocols beingused in order to pass the information on to the Node-B and then finally the UE. Threebasic type of transmissions are defined. Transparent, Unacknowledged orAcknowledged. The lower layers is a simple combination of protocols with the User planebeing directly on top of AAL2 which is responsible for segmenting the data to ATM cells.

Version 1 Rev 7 Iub Protocol Structure



4–11

Iub Protocol Stack

CP13_Ch4_04

Radio Network

Layer

Transport Network

Layer

Radio Network Control Plane

NBAP


AAL5

User Plane

Physical Layer

SSCF–UNI

SSCOP

ATM

AAL5

SSCF–UNI

Q.2150.2

Q.2630.1

SSCOP

AAL2

DC

H F

P

RA

CH

FP

FAC

H F

P

PC

H F

P

DS

CH

FP

US

CH

FP

CP

CH

FP

Version 1 Rev 7Iur Protocol Structure



4–12

Iur Protocol StructureThe Iur was originally developed to support Soft Handovers, but has since been changedto have 4 main distinct functions that will be discussed in this section. Again two differentlayers can be detected, the Transport Network Layer and the Radio Network Layer. ThePhysical layer in the Transport Network Layer consist of normal OSI L1 specifiedprotocols 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 planesabove.


The Protocol used on the radio Network Layer is called RNSAP, this protocol could runon Broad Band SS7 protocols or IP based signalling. The 4 main functions of thisprotocol include the following:

� Support for basic Inter RNC Mobility

� Support for Dedicated Channel Traffic

� Support for Common Channel Traffic

� Support of Global Resource Management


The Transport Network Protocol Stack is more complex than any other interface. This ismainly due to 4 different uses as specified above. Signalling and Data will be carriedbetween different Node-B’s on either broad band SS7 Interfaces or IP based Interfaces.


This is a very simple combination of protocols with the User plane being directly on top ofAAL2, which is responsible for segmenting the data to ATM cells.

Version 1 Rev 7 Iur Protocol Structure



4–13

Iur Protocol Stack

CP13_Ch4_05

Radio Network

Layer

Transport Network

Layer

Control Plane

RNSAP


User Plane

DCHFP

AAL2


ATM

Physical Layer

AAL5

M3UA

SCCP

MTP3b

SSCF–NNI SCTP

SSCOP IP

AAL5

Q.2150.1

M3UAMTP3b

SSCF–NNI SCTP

SSCOP IP

CCHFP

Q.2630.1


Version 1 Rev 7Radio Interface Protocol Architecture



4–14

Radio Interface Protocol ArchitectureThe 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 isdescribed in detail in later chapters

Layer 2 is split into following sublayers: Medium Access Control (MAC), Radio LinkControl (RLC), Packet Data Convergence Protocol (PDCP) and Broadcast/MulticastControl (BMC).

Layer 3 and RLC are divided into Control (C-) and User (U-) planes. PDCP and BMCexist in the U-plane only.

In the C-plane, Layer 3 is partitioned into sublayers where the lowest sublayer, denotedas 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 ofthe Access Stratum; it provides the Access Stratum Services to higher layers. The higherlayer signalling such as Mobility Management (MM) and Call Control (CC) are assumedto belong to the non-access stratum.

The diagram opposite shows the radio interface protocol architecture. Each block inrepresents an instance of the respective protocol. Service Access Points (SAP) forpeer-to-peer communication are marked with circles at the interface. The SAP betweenMAC and the physical layer provides the transport channels. The SAPs between RLCand 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 GeneralControl (GC), Notification (Nt) and Dedicated Control (DC) SAPs.

Also shown in the figure are connections between RRC and MAC as well as RRC and L1providing local inter-layer control services. An equivalent control interface exists betweenRRC and the RLC sublayer, between RRC and the PDCP sublayer and between RRCand BMC sublayer. These interfaces allow the RRC to control the configuration of thelower layers. For this purpose separate Control SAPs are defined between RRC andeach lower layer (PDCP, RLC, MAC, and L1).

Version 1 Rev 7 Radio Interface Protocol Architecture



4–15

Radio Interface Protocol Architecture

CP13_Ch4_06

L3

L2/PDCP

L2/BMC

L2/RLC

L2/MAC

L1PHY

PDCP

PDCP

RLC

BMC

RRC

RLC

MAC

RLC

RLC

RLC

RLC

RLC

RLC

cont

rol

cont

rol

cont

rol

control

LogicalChannels

TransportChannels

cont

rol

Duplication avoidance

GC Nt DCC–plane signalling U–plane information

GC Nt DC

UuS boundary

Version 1 Rev 7MAC Layer Functions



4–16

MAC Layer Functions

Mapping between logical and Transport channels

The MAC layer performs cross mapping of information between logical channels (to/fromhigher level protocols) and the appropriate transport channel, according to the type ofinformation to be transferred. Logical and transport channel types are covered in moredetail in a later chapter.

Transport format selection

MAC will select the most appropriate Transport format (from the transport formatcombination set) for each transport channel, depending upon the instantaneous sourcerate.

Priority handling of Data Flows

Priority handling of data flows of a single UE using multiple Services, is achieved byselecting 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 toreceive data in the downlink. Use of these shared resources is dynamically scheduled bythe 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, theMAC-sh will identify the source or destination UE by including a Radio NetworkTemporary Identifier (RNTI) in the MAC header.

MUX/DEMUX of PDUs into Transport Blocks

MAC handles the service multiplexing for both common and dedicated transportchannels. However, it should be noted that MAC multiplexing of dedicated channels canonly be performed for services with the same QoS parameters, while physical layermultiplexing makes it possible to multiplex any type of service, including those withdifferent QoS parameters.

Version 1 Rev 7 MAC Layer Functions



4–17

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 SelectionCP13_Ch4_p17

Version 1 Rev 7MAC Layer Functions



4–18

Traffic Volume Monitoring

MAC receives RLC PDUs together with status information on the amount of data in theRLC buffer. MAC compares the amount of status corresponding to a transport channelwith the thresholds set by RRC. If the amount of data is too high or too low, MAC sendsa traffic volume status measurement to RRC. RRC uses these reports to triggerreconfiguration of the Radio Bearers/Transport channels.

Dynamic Transport Channel Type Switching

Based upon a switching decision received from RRC, MAC is able to execute switchingof 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 aciphering algorithm.

Access Service Class Selection

UEs are allocated to one of eight Access Service Classes, to provide different prioritiesfor service resources. MAC indicates the ASC associated with a PDU received from thephysical layer.

Version 1 Rev 7 MAC Layer Functions



4–19

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 SelectionCP13_Ch4_p17

Version 1 Rev 7RLC Protocol



4–20

RLC ProtocolThe radio link control (RLC) protocol provides segmentation and retransmission servicesfor both user and control data

The diagram opposite gives an overview model of the RLC layer. The figure illustratesthe different RLC peer entities. Each RLC instance is configured by RRC to operate inone of three modes

� Transparent Mode (Tr)

� Unacknowledged Mode (UM)

� Acknowledged Mode (AM)

The mode to be used is determined by the SAP into which the higher layer deliver theirPDUs. The mode chosen indicates which services and functions are to be applied andwhat (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 resultof the CRC check is delivered to RLC together with the actual data.

Version 1 Rev 7 RLC Protocol



4–21

RLC Protocol Model

CP13_Ch04_08

Tr–SAP UM–SAP AM–SAP UM–SAP Tr–SAP

AM–EntityTransmitTr–Entity

TransmitUM–Entity

ReceiveTr–Entity

ReceiveUM–Entity

Transmitting Side Receiving Side

Version 1 Rev 7RRC Functions



4–22

RRC FunctionsThe Radio Resource Control (RRC) layer handles the control plane signaling of Layer 3between the UEs and UTRAN. The RRC performs the following functions:

Broadcast of information provided by the non-access stratum (CoreNetwork)

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 performsthe scheduling, segmentation and repetition. This function supports broadcast of higherlayer (above RRC) information. This information may be cell specific or not. As anexample RRC may broadcast Core Network location service area information related tosome 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 performsthe scheduling, segmentation and repetition. This function supports broadcast of typicallycell-specific information.

Establishment, re-establishment, maintenance and release of anRRC connection between the UE and UTRAN

The establishment of an RRC connection is initiated by a request from higher layers atthe UE side to establish the first Signaling Connection for the UE. The establishment ofan RRC connection includes an optional cell re-selection, an admission control, and alayer 2 signaling link establishment. The release of an RRC connection can be initiatedby a request from higher layers to release the last Signaling Connection for the UE or bythe RRC layer itself in case of RRC connection failure. In case of connection loss, the UErequests 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 RadioBearers can be established to an UE at the same time. At establishment andreconfiguration, the RRC layer performs admission control and selects parametersdescribing the Radio Bearer processing in layer 2 and layer 1, based on information fromhigher layers.

Assignment, reconfiguration and release of radio resources for theRRC 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 radiobearers related to the same RRC connection. RRC controls the radio resources in theuplink and downlink such that UE and UTRAN can communicate using unbalanced radioresources (asymmetric uplink and downlink). RRC signals to the UE to indicate resourceallocations for purposes of handover to GSM or other radio systems.

Version 1 Rev 7 RRC Functions



4–23

RRC Functions

� Broadcast of information related to the non-access stratum (CoreNetwork)

� Broadcast of information related to the access stratum

� Establishment, maintenance and release of an RRC connectionbetween the UE and UTRAN

� Establishment, reconfiguration and release of Radio Bearers

� Assignment, reconfiguration and release of radio resources for theRRC 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 Dynamic Channel Allocation (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.CP13_Ch4_p23

Version 1 Rev 7RRC Functions



4–24

RRC connection mobility functionsThe RRC layer performs evaluation, decision and execution related to RRC connectionmobility during an established RRC connection, such as handover, preparation ofhandover to GSM or other systems, cell re-selection and cell/paging area updateprocedures, 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 layercan also initiate paging during an established RRC connection.

Routing of higher layer PDUsThis function performs at the UE side routing of higher layer PDUs to the correct higherlayer entity, at the UTRAN side to the correct RANAP entity.

Control of requested QoSThis function shall ensure that the QoS requested for the Radio Bearers can be met. Thisincludes the allocation of a sufficient number of radio resources.

UE measurement reporting and control of the reportingThe measurements performed by the UE are controlled by the RRC layer, in terms ofwhat to measure, when to measure and how to report, including both UMTS air interfaceand other systems. The RRC layer also performs the reporting of the measurementsfrom the UE to the network.

Outer loop power controlThe RRC layer controls setting of the target of the closed loop power control.

Control of cipheringThe RRC layer provides procedures for setting of ciphering (on/off) between the UE andUTRAN.

Arbitration of radio resources on uplink DCHThis 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 modeSelection of the most suitable cell based on idle mode measurements and cell selectioncriteria.

Integrity protectionThis function adds a Message Authentication Code (MAC-I) to those RRC messages thatare considered sensitive and/or contain sensitive information.

Allocation of radio resources for CBS

This function allocates radio resources for CBS based on traffic volume requirementsindicated by BMC. The radio resource allocation set by RRC (i.e. the schedule formapping of CTCH onto FACH/S-CCPCH) is indicated to BMC to enable generation ofschedule messages. The resource allocation for CBS shall be broadcast as systeminformation.

Configuration for CBS discontinuous receptionThis function configures the lower layers (L1, L2) of the UE when it shall listen to theresources allocated for CBS based on scheduling information received from BMC.

Version 1 Rev 7 RRC Functions



4–25

RRC Functions

� Broadcast of information related to the non-access stratum (CoreNetwork)

� Broadcast of information related to the access stratum

� Establishment, maintenance and release of an RRC connectionbetween the UE and UTRAN

� Establishment, reconfiguration and release of Radio Bearers

� Assignment, reconfiguration and release of radio resources for theRRC 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 Dynamic Channel Allocation (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.CP13_Ch4_p23

Version 1 Rev 7Protocol Stacks



4–26

Protocol StacksThe following pages construct the protocol stacks for each UMTS network entity. Theexact protocol structure is dependent upon which Core Network domain (CS or PS) isproviding the Bearer Service, and whether the information transfer is user plane orcontrol plane.

User Plane Protocol Stack (Dedicated Channels CS-Domain)

The diagram opposite shows the User plane protocol stack for user plane data transfer,using dedicated channels via the CN-PS. The user CS payload will be received at theMSC from the external network (e.g. the PSTN. The protocols used the transfer thePayload 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 Iuinterface 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 areestablished towards one given UE, then these RABs make use of several Iu UP protocolinstances. These Iu UP instances are established, relocated and released together withthe Associated RAB.

The Iu UP Protocol is defined with modes of operation, which can be activated on a RABbasis rather than on A CN domain or service basis. This makes the protocolindependent of the CN domain and to have limited or no dependency with the TransportNetwork Layer. This provides the flexibility to evolve services regardless of the CNdomain. The Iu UP mode of operation determines if and which set of features shall beprovided. 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 UPprotocol 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 protocollayer is crossed though by PDUs being exchanged between upper layers and thetransport network layer, no Iu UP overhead is added to the payload.

The support modes are intended for those RABs that do require particular features fromthe 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 thepayload. The Iu UP Support mode is prepared to support variations. However, the onlysupport mode currently defined in 3GPP specifications; namely Support Mode forPredefined SDU size (SMpSDU), and provides the following functions.

� Transfer of user data;

� Initialisation

� Rate Control

� Time Alignment

� Handling of Error Events

� Frame Quality Classification

Version 1 Rev 7 Protocol Stacks



4–27

User Plane Protocol Stack (Dedicated ChannelsCS-Domain)

CP13_Ch4_15

lu–UP

RLC

CS Payload

CS Payload

Phys

AAL2

ATM

Phys

RLC

MAC–d

Split/ Comb

Phys

Split/ Comb

Phys

DCH FP

AAL2

ATM

Phys

MAC–d

Split/ Select

DCH FP

AAL2

ATM

Phys

lu–UP

AAL2

ATM

Phys Phys

UE Node B SRNC MSC PSTN

Version 1 Rev 7Protocol Stacks



4–28

Dedicated Channel Frame Protocol (DCH FP)

User data is received at the SRNC, via the transport layer and Iu UP protocol and thepassed to the Radio Interface Control protocols for RLC and MAC processing asappropriate. The resultant Transport Blocks are delivered to the DCH FP.

DCH FP transfers DCH data frames every transmission time interval from the SRNC tothe Node B fro downlink transfer and from Node B to the SRNC for uplink transfer. AnOptional error detection mechanism may be used to protect the data transfer if needed.At the transport channel set-up it shall be specified if the error detection on the User datais 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.

Version 1 Rev 7 Protocol Stacks



4–29

User Plane Protocol Stack(Dedicated Channels CS-Domain)

CP13_Ch4_16

lu–UP

RLC

CS Payload

CS Payload

Phys

AAL2

ATM

Phys

RLC

MAC–d

Split/ Comb

Phys

Split/ Comb

Phys

DCH FP

AAL2

ATM

Phys

MAC–d

Split/ Select

DCH FP

AAL2

ATM

Phys

lu–UP

AAL2

ATM

Phys Phys

UE Node B SRNC MSC PSTN

Version 1 Rev 7Control Plane Protocol Stack (UE-CN SIGNALLING, Dedicated Channels, CS-Domain)



4–30

Control Plane Protocol Stack (UE-CN SIGNALLING, DedicatedChannels, CS-Domain)

The diagram opposite illustrates the protocol stack for UE to CN signalling, when the UEis connected to the network and operating in dedicated mode.

RANAP Services

RANAP provides the signalling service between UTRAN and the CN that is required tofulfil the RANAP functions. RANAP services are divided into three groups based onService access Points.

General control services

General control services are related to the whole Iu interface instance between RNC andlogical CN domain, and are accessed in CN through the General Control SAP. Theyutilise 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 areaccessed in CN through the Notification SAP. They utilise connectionless signallingtransport provided by the Iu signalling bearer.

Dedicated control services

Dedicated control services are related to one UE, and are accessed in CN through theDedicated Control SAP. RANAP functions that provide these services are associated withIu signalling connection that is maintained for the UE in question. The Iu signallingconnection is realised with connection oriented signalling transport provided by the Iusignalling 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 andestablishment of a connection oriented link mobile by mobile basis.

MTP3-B

MTP3-b provides message routing, discrimination and distribution (for point-to-point linkonly), signalling link management load sharing and changeover/back between link withinone 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 statusmechanisms are provided. SSCOP provides mechanisms for the establishment andrelease of connections and the reliable exchange of signalling information betweensignalling entities. Adapts the upper layer protocol to the requirements of the Lower ATMcells.

Version 1 Rev 7 Control Plane Protocol Stack (UE-CN SIGNALLING, Dedicated Channels, CS-Domain)



4–31

Control Plane Protocol Stack (UE-CN SIGNALLING,Dedicated Channels, CS-Domain)

CP13_Ch4_17

RRC

RLC

MAC–d

Combining

Phys

UE

Split/ Comb

Phys

DCH FP

AAL5

ATM

Phys

Node

RLC

MAC–d

Split/ Comb

DCH FP

AAL5

ATM

Phys

SRNC

RRC

RANAP

MS

RANAP

SCCP

MTP3–b

SAAL– NNI

ATM

Phys

SCCP

MTP3–b

SAAL– NNI

ATM

Phys

Version 1 Rev 7Control Plane Protocol Stack (UE-CN Signalling, Shared Channels, CS-Domain)



4–32

Control Plane Protocol Stack (UE-CN Signalling, SharedChannels, CS-Domain)

The diagram opposite illustrates the protocol stack for UE to CN signalling, when the UEis connected to the network and operating on shared or common channels. The stackdiffers 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 variousAAL2 connections coming from multiple SRNCs into MAC-c/sh. The MUX-2 boxrepresents the multiplexing of various instances of MAC-d from the same SRNC intoAAL2, 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 TransportBlocks between the Node B and the DRNC for common/shared channels. These FPswill 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 thefollowing services:

� Support of transport channel synchronisation mechanism.

� Support of Node synchronisation mechanism.

� DSCH TFCI signalling.

Version 1 Rev 7 Control Plane Protocol Stack (UE-CN Signalling, Shared Channels, CS-Domain)



4–33

Control Plane Protocol Stack(UE-CN Signalling, SharedChannels, CS-Domain)

CP13_Ch4_18

MUX1

Phys

RACH/FACH/DSCH

FPAAL5

ATM

Phys

MAC–c/shRACH/FACH/DSCH

FPAAL5

ATM

Phys

AAL2

ATM

Phys

UE Node B CRNC SRNC CN

RRC

RLC

MAC–d

RRC

RLC

MAC–d

SCCP

RANAP

MAC–c/sh

Phys

MUX2

AAL2

ATM

Phys

RANAP

SCCP

MTP3–b

SAAL–NNI

ATM

Phys

MTP3–b

SAAL–NNI

ATM

Phys

Version 1 Rev 7User Plane Protocol Stack (Dedicated Channels, PS-Domain)



4–34

User Plane Protocol Stack (Dedicated Channels, PS-Domain)The diagram opposite shows the user plane protocol stack for user data transfer, usingdedicated channels via the CN-PS. The user CS payload will be received at the GGSNfrom the external network (e.g. the Internet). The protocols used to transfer the payloadacross 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 externalPDN. Typically these will be IP based and addressed to an application running on thetarget UE. Alternate transport mechanisms, such as X25, may also be used. TheT-PDUs will be presented to GTP, via the appropriate NSAPI for the source protocol. ForUMTS the second version of GTP (version 1) will be used.

GTP allows multi-protocol packets to be tunnelled through the UMTS/GPRS Backbonebetween GSNs and is necessary to forward packets between an external packet datanetwork 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 implementedby 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 MSsare 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/oreach 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 atunnel endpoint in the receiving GTP-U protocol entity. The TEID values are negotiatedand exchanged between tunnel endpoints using control plane procedures defined inprotocols such as GTP-C (or RANAP, over the Iu) messages during the activation of thePDP context or RAB.

Path Protocols

UDP/IP is the only path protocol defined to transfer GTP messages in the version 1 ofGTP.

UDP

A User Datagram Protocol (UDP) compliant with STD 0006 shall be used. The UDPdestination port number for GTP-U messages is 2152.

IP

An Internet protocol compliant with STD 0005 shall be used. The IP destination addressin a GTP message shall be the IP address of the destination GSN/RNC. The sourceaddress shall be the IP address of the originating GSN/RNC.

Version 1 Rev 7 User Plane Protocol Stack (Dedicated Channels, PS-Domain)



4–35

User Plane Protocol Stack(Dedicated Channels, PS-Domain)

CP13_Ch4_19

UE Node B SRNC SGSN PDNGGSN

AAP

Split/ Comb

DCH FP

PDCP

RLCGTP–U GTP–U GTP–U

IP IP

AAP

IP

PDCP

RLC

MAC–d

Comb

Phys Phys

AAL2

ATM

Phys

MAC–d

Split CombDCH

FP

AAL2

ATM

Phys

UDP

IP

AAL5

ATM

Phys

UDP

IP

AAL5

ATM

Phys

UDP

IP

L2

Phys

GTP–U

UDP

IP

L2

Phys Phys

IP

Phys

Version 1 Rev 7Control Plane Protocol Stack



4–36

Control Plane Protocol Stack(UE-CN Signalling, Dedicated Channels, PS-Domain)

Stream Control Transmission Protocol

The basic service offered by SCTP is the reliable transfer of user messages betweenpeer SCTP users. It performs this service within the context of an association betweentwo SCTP endpoints. SCTP is connection-oriented in nature, but the SCTP association isa broader concept than the TCP connection. SCTP provides the means for each SCTPendpoint to provide the other endpoint (during association startup) with a list of transportaddresses (i.e., multiple IP addresses in combination with an SCTP port) through whichthat endpoint can be reached and from which it will originate SCTP packets. Theassociation 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. AnRNC equipped with the M3UA stack option shall have client functionality. This enablesthe RNC to report to the SGSN when it is a newly introduced entity in the network.

Version 1 Rev 7 Control Plane Protocol Stack



4–37

Control Plane Protocol Stack(UE-CN Signalling,Dedicated Channels, PS-Domain)

CP13_Ch4_20

RRC

RLC

MAC–d

Combining

Phys

UE

Split/ Comb

Phys

DCH FP

AAL5

ATM

Phys

Node

RLC

MAC–d

Split/ Comb

DCH FP

AAL5

ATM

Phys

SRNC

RRC

CN

RANAP

SCCP

M3UA

RANAP

SCCP

M3UA

SCTP

IP

SAAL– NNI

ATM

Phys

SCTP

IP

SAAL– NNI

ATM

Phys

Version 1 Rev 7Control Plane Protocol Stack



4–38



5–1

Chapter 5

Data Flow and Terrestrial

Interfaces

Version 1 Rev 7



5–2

Version 1 Rev 7



5–3

Chapter 5Data Flow and Terrestrial Interfaces 5–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives 5–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Terrestrial Interfaces 5–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ATM Principles 5–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Asynchronous Transfer Mode (ATM) 5–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Virtual Channels and Paths 5–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use of Virtual Channels and Paths 5–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Virtual Connection and Path Switching 5–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ATM Adaptation Layers (AALs) 5–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The ATM Adaptation Process 5–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Convergence Sub-Layer (CS) 5–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Segmentation and Reassembly 5–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ATM Adaptation Layer 2 (AAL2) 5–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPCS 5–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ATM Adaptation Layer 5 (AAL 5) 5–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E1 Architecture 5–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logical Links 5–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E1 5–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . T1 5–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ATM Cell to E1 Cell Mapping 5–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E Link Multiplexing 5–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Inverse Multiplexing for ATM (IMA) 5–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Synchronous Digital Hierarchy (SDH) 5–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SDH Drop and Insert 5–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Simplification 5–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Survivability 5–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Control 5–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bandwidth on Demand 5–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Principles of SDH 5–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ATM to STM Mapping - VC4 5–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Typical UMTS Transport Network 5–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



5–4




5–1


� 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.

Version 1 Rev 7Terrestrial Interfaces



5–2

Terrestrial InterfacesOne very important aspect that is sometimes overlooked is the transport mediumrequired between the different entities. In the case of UMTS the Network Operator willrun into problems if the wrong links are utilised. Speed of transfer and cost will be two ofthe major determining factors when planning the UMTS network. Other issues that needto be addressed are the types of converting equipment used between the different typesof Terrestrial Interfaces. In the following pages a closer look will be taken at theseaspects.

It should also be mentioned that as data rates increase the use of E1/T1 systemsbecome more difficult. ATM is the preferred transport mechanism on the CN. Voice andIP over ATM is conducted using ATM adaptation layers.

Version 1 Rev 7 Terrestrial Interfaces



5–3

Terrestrial Interfaces

CP13_Ch5_10

UE Node B RNC SGSN GGSNCS PS Network

CDMA – FDD CDMA – TDD

ATM E1

ATM SDH IP

IP X25

Uu Iub Iups GN

Version 1 Rev 7ATM Principles



5–4

ATM PrinciplesATM is used to transfer different types of information with different rate factors over oneor more common link with a high bit rate. This properties makes ATM an extremely usefulsystem when it comes to wideband or broadband data transfer.

With the standards in place it is now possible for packet switching techniques like FrameRelay or ATM to deliver high quality speech. Some of the intrinsic advantages ATM hasover 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 ATMheader. This helps in reducing the packetization delay significantly, which is one ofthe major delay parameters.

� It supports extensive QoS (Quality of Service) parameters, which allows voicetraffic to be transmitted across the network in a reliable jitter-free way.

� Various ATM Adaptation Layers (AALs) support various service classescapabilities.

� ATM switches have always been designed with effective traffic managementcapabilities, for example, call admission control, usage parameter control, trafficshaping, etc.

� Single network for voice, data, and video.

� Interworking with PSTN is relatively straightforward.

Version 1 Rev 7 ATM Principles



5–5

ATM Principles

CP13_Ch5_12

Fixed Bit Stream

Variable Bit Stream

Discontinues Bit Stream

Version 1 Rev 7Asynchronous Transfer Mode (ATM)



5–6

Asynchronous Transfer Mode (ATM)Asynchronous Transfer Mode (ATM) is a technology originally designed for LANs thathave 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 remaining48 user data, called the payload.

The fixed length cell gives some key advantages over variable length structures. The firstis that short cells can be switched quickly and economically. Secondly the queuingcaused by long, variable length frames can be reduced to the wait time for a single 53Octet frame, allowing time dependent voice and video to be transported.

ATM can provide both CBR and VBR transport.

Version 1 Rev 7 Asynchronous Transfer Mode (ATM)



5–7

Asynchronous Transfer Mode (ATM)

CP13_Ch5_13

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

·······

·

Version 1 Rev 7Virtual Channels and Paths



5–8

Virtual Channels and PathsOn physical level ATM connects via the specification of Virtual Paths (VPs) and VirtualChannels (VCs). A Virtual Channel will be located inside a Virtual Path. A Virtual ChannelIdentifier (VCI) will identify the Virtual Channel and the Virtual Path Identifier (VPI) willidentify the Virtual Path (VP).

In total we could have up to 256 addresses for a VP User to Network Interface (UNI) and4096 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 ChannelConnection. This connection in turn may consist of a number of VC and VPcomponents. 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 twoconsecutive ATM entities where a VCI value is assigned, remapped or removed. Forexample, 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 twoconsecutive ATM entities where a VPI value is assigned, remapped or removed. Forexample, 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.

Version 1 Rev 7 Virtual Channels and Paths



5–9

Virtual Channels and Paths

Use of Virtual Channels and Paths

CP13_Ch5_15

ATM Path

Virtual Path (VP)

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_16

Virtual Channel Connection Endpoints

Virtual Channel Connection

Virtual Channel Link Virtual Channel Link

Virtual Path Link Virtual Path LinkVC Switch – VCI and VPI

values change

Virtual Path Connection

Virtual Path Connection Endpoints

VP Switch VC Switch ATM END

SYSTEM

ATM END

SYSTEM

Version 1 Rev 7Virtual Connection and Path Switching



5–10

Virtual Connection and Path SwitchingWhen addressing is carried out on VP level only a VP address would be needed since allthe VCs are inside the VP. Therefore we would only switch on VP level like illustrated inthe diagram. If however VCs need to be switched a VP Switch combined with a VCSwitch would be needed.

The switching in ATM could get complicated at times therefore special tools have beendeveloped to help with this aspect.

Version 1 Rev 7 Virtual Connection and Path Switching



5–11

Virtual Connection and Path Switching

CP13_Ch5_17

VC Switch

VP SwitchVP Switch

Endpoint of VPC

Representation of VC and VP Switching Representation of VP Switching

Version 1 Rev 7ATM Adaptation Layers (AALs)



5–12

ATM Adaptation Layers (AALs)The ATM Adaptation Layer (AAL) is the protocol used between the ATM layer itself andhigher layers. The main functionality is to adapt the information coming in from the higherlayers so they can be transferred onto ATM. This is what gives ATM its powerful propertyof transferring many traffic types, and ensures appropriate service characteristics areprovided.

The AALs are divided into 5 different categories, where AAL1 has the lowest delay andAAL5 the highest. This means that services like speech will tend to go towards a lowerAAL number.

Horizontally the AAL protocol is divided into the Convergence Sublayer (CS) and theSegmentation and Reassemble Sublayer (SAR).

Version 1 Rev 7 ATM Adaptation Layers (AALs)



5–13

ATM Adaptation Layers

CP13_Ch5_11

Class A Class B Class C Class D

Timing Relation Required Not Required

Bit Rate

Connection Rate

Examples

Service Type to be used

Constant Variable

Connection Orientated

Connection Less

Emulation of Circuits

CPCM

Variable Bit Rate Video

Connection Orientated Data

Transmission

Connection Less Data

Transmission

AAL 1 AAL 2AAL 3/4 or

AAL 5

Version 1 Rev 7The ATM Adaptation Process



5–14

The ATM Adaptation ProcessThe AAL consists of two sub-layers; The Convergence sub-layer (CS) and thesegmentation and reassembly sub-layer (SAR).

Convergence Sub-Layer (CS)

The function of the CS is to divide very long packets into fixed-length packets calledCS-service data units (CS-SDUs). It may add header and/or trailer information to theCS-SDU to generate a CS-protocol data unit (CS-PDU). Finally it passes theCS-PDUs to the SAR.

Segmentation and Reassembly

At the source end, the SAR sub-layer is responsible for segmenting each CS-PDUreceived from the CS sub-layer into fixed-length SAR-SDUs according to the applicationtraffic type. The SAR then appends a header and/or trailer to each SAR-SDU togenerate 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 belongingto the same CS-PDU and presenting the reassembled CS-PDU to the CS.

Version 1 Rev 7 The ATM Adaptation Process



5–15

Generic AAL Process

CP13_Ch5_31

User

Header TrailerUser

TCS–SDUH

SAR–SDU TH

SAR–PDU SAR–PDUHH

TCS–SDUH TCS–SDUH

SAR–SDU TH

CSPROCESS

SARPROCESS

ATMLAYER

CS–PDU

SAR–PDU

ATM Cell

Version 1 Rev 7ATM Adaptation Layer 2 (AAL2)



5–16

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 commonATM layer connection.

AAL2 is a lot more efficient at transporting voice as there is a more efficient use ofbandwidth 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. CommonPart Convergence Sub-layer (CPCS), over which may operate zero or more ServiceSpecific 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 CPSHeader. The header contains; The Channel ID (CID) which identifies the sub-streamwithin the AAL2 connection. The Length indication (LI) indicates the length of the

CPS-INFO payload. The User-to-User Indication (UUI) carries information between theSSCSs/Applications running above the CPS. The Header Error Control (HEC) can beused to report errors within the header.

Dependent upon size multiple CPS Packets, from different sources, can be multiplexedto form 47 Octet CPS-SDUs, (If necessary, padding can be added to give 47-Octets). Afurther header is added to the SDU to yield a 48 Octet CPS-PDU. The CPS-PDU headercontains an Offset Field (OSF) which is a pointer to the first octet of the next CPS-Packetin 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 ATMlayer, to be built directly into an ATM cell.

Version 1 Rev 7 ATM Adaptation Layer 2 (AAL2)



5–17

AAL 2

CP13_Ch5_32

HEADER OSF SN P Info Packets or padding

CID 8bits

LI 6bits

UUI 5bits

HEC 5bits

CPS–Information field VARIABLE 1 – 64 Octets

3–Octet CPS Header User Information

CPS–PDU

ATM Cell (53–Octets)

CPS–Packet

CPS–SDU Header CPS–SDU

OSF 6bits

SN 1bit

P 1bit

Info packets or padding 47 Octets

Version 1 Rev 7ATM Adaptation Layer 5 (AAL 5)



5–18

ATM Adaptation Layer 5 (AAL 5)The most recent of the adaptation layers, AAL 5 is also becoming the most popular andhas largely superseded AAL3/4. Often referred to as the Simple And EfficientAdaptation Layer (SEAL), it supports a wide variety of applications. It is the adaptationlayer of choice for the ATM signalling protocol on VCI 5. MPEG video and Frame Relayalso use AAL 5. Unlike AAL2 (or AAL 3/4) AAL5 does not support multiplexing of datafrom multiple higher layer applications

AAL 5 takes any user data, normally as a frame, adds some padding and an 8-bytetrailer so that the whole of the resulting CPCS PDU is N x 48-bytes long. The PDUs arethen 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 thatit is the last cell. The ATM layer then sets the “End of User Data” bit in the ATM header toinform the receiving end.

In the receiver, the ATM layer passes the payloads up to the SAR sublayer. When thelast cell arrives, it is recognised by the ATM layer. The ATM layer informs the SAR layerthat the payload is the last for that frame. The SAR presents the assembled PDU to theCS. The CS performs a CRC on the PDU and compares this with the last 4 bytes in thetrailer. If the CRCs match, the CS then checks the 2-byte Length Indicator (LI). The LIfield indicates the amount of user data in the PDU so that the CS can remove thepadding and recover the user data. Should the CRC not match, then the whole PDU isdiscarded. AAL 5 relies on the application to recover from lost frames. For videoapplications, the last correct frame received would be repeated. For LAN data, thetransport protocol would arrange for re-transmission of the missing frame.

CPI Common Part Indicator LI Length Indicator

PDU Protocol Data Unit AAL ATM Adaption Layer

SDU Service Data Unit CRC Cyclic Redundancy Check

CPCS Common Part ConvergenceSublayer

SAR Segmentation andReassembly

Version 1 Rev 7 ATM Adaptation Layer 5 (AAL 5)



5–19

AAL5

CP13_Ch5_33

User Data

1 – 65,535 bytes

H SAR Payload

SAR Payload

CPCS–PDU Payload PAD UUI CPI LI CRC

H SAR Payload

SAR Payload

H SAR Payload

SAR Payload

0–47 1 1 2 4

AAL 5SDUs

ATMCELLS

SARPDUs

CPCSPDUs

Version 1 Rev 7E1 Architecture



5–20

E1 Architecture

Logical Links

We have seen some of the mediums over which the data is transmitted, now let usconsider 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 LogicalLink. The format of the data is dependent on where in the system the data is and whatsort of data needs to be transferred.

E1

In the European GSM system the basic building block of data that gets carried aroundthe 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. Channel0 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 perframe, output bit rate, encoding law and the dedicated signalling and synchronisationchannels.

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 is1.544 Mbit/s and the signalling used in the frame is only used once every 6th frame,instead of every frame in E1.

Version 1 Rev 7 E1 Architecture



5–21

E1 Architecture

CP13_Ch5_22

T1/DS1

E1

Frequency

Sampling Rate

Bits per Sample

Bits per Frame

PCM Channels per FrameOutput Bit Rate

Encoding Law

Signalling Capabilities

300 – 3400Hz

8000Hz

8

193

24

1.544 Mb/s

µ Law

1st bit in frame – Sync

1 bit in timeslots 6 and 12

Frequency Range

Sample Rate

Bits per Sample

Time Slots per Frame

Output Bit Rate

Encoding Law

Signalling Capabilities

300 – 3400Hz

8000Hz

8

32

2.048 Mb/s

A LAW

TS16 Signalling

TS0 Sync

Version 1 Rev 7ATM Cell to E1 Cell Mapping



5–22

ATM Cell to E1 Cell MappingThe ATM cell is mapped into bits 9 to 128 and bits 137 to 256 (i.e. time slots 1 to 15 andtime slots 17 to 31) of the 2048 kbit/s frame as specified in ITU-T RecommendationG.704[2] and as shown in the Figure opposite. The ATM cell octet structure shall bealigned with the octet structure of the frame.

There shall be no relationship between the beginning of an ATM cell and the beginningof an 2048 kbit/s transmission frame. Since the frame payload capacity (30 octets) is notan integer multiple of cell length (53 octets), ATM cells will cross the E1 frame boundary.

Version 1 Rev 7 ATM Cell to E1 Cell Mapping



5–23

ATM Cell to E1 Cell Mapping

CP13_Ch5_34

TS0Synch

TS16Sig

ATM Mapping Field15 Octets

ATM Mapping Field15 Octets

125 µS E1 frames - 256 bits per frame

Version 1 Rev 7E Link Multiplexing



5–24

E Link MultiplexingThe standard E1 and T1 streams can be further multiplexed to put more channels overone transmission path.

Version 1 Rev 7 E Link Multiplexing



5–25

E Series Hierarchies

CP13_Ch5_23

E1

2.048 Mb/s

E2

8.448 Mb/s

E3

34.368 Mb/s

E4

139.264 Mb/s

E5

564.992 Mb/s

x 4

x 4

x 4

x 4

30 TCH

120 TCH

480 TCH

1,920 TCH7,680 TCH

Version 1 Rev 7Inverse Multiplexing for ATM (IMA)



5–26

Inverse Multiplexing for ATM (IMA)Inverse Multiplexing for ATM (IMA) is a methodology which provides a modularbandwidth, for user access to ATM networks and for connection between ATM networkelements, at rates between the traditional order multiplex level. An example is to achieverates 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 ofcombining the transport bandwidths of multiple links (e.g., DS1/E1 links) grouped tocollectively provide higher intermediate rates.

The ATM Inverse Multiplexing technique involves inverse multiplexing andde-multiplexing of ATM cells in a cyclical fashion among links grouped to form a higherbandwidth logical link whose rate is approximately the sum of the link rates. This isreferred to as an IMA group. The figure opposite provides a simple illustration of the ATMInverse Multiplexing technique in one direction. The same technique applies in theopposite direction.

IMA groups terminate at each end of the IMA virtual link. In the transmit direction, theATM cell stream received from the ATM layer is distributed on a cell by cell basis, acrossthe multiple links within the IMA group. At the far-end, the receiving IMA unit recombinesthe 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 permitreconstruction of the ATM cell stream at the receiving end of the IMA virtual link. Thereceiver end reconstructs the ATM cell stream after accounting for the link differentialdelays, smoothing CDV introduced by the control cells, etc. These cells, defined as IMAControl Protocol (ICP) cells, provide the definition of an IMA frame. The transmitter mustalign the transmission of IMA frames on all links. This allows the receiver to adjust fordifferential link delays among the constituent physical links. Based on this requiredbehavior, the receiver can detect the differential delays by measuring the arrival times ofthe IMA frames on each link.

At the transmitting end, the cells are transmitted continuously. If there are no ATM layercells to be sent between ICP cells within an IMA frame, then the IMA transmitter sendsfiller cells to maintain a continuous stream of cells at the physical layer. The insertion ofFiller cells provides cell rate decoupling at the IMA sublayer. The Filler cells should bediscarded by the IMA receiver.

Version 1 Rev 7 Inverse Multiplexing for ATM (IMA)



5–27

Inverse Multiplexing and De-multiplexing of ATM cells

CP13_Ch5_35

PHY

PHY

PHY

IMA Group IMA Group

PHY

PHY

PHY

Physical Link #0

Physical Link #1

Physical Link #2

Original ATM Cell Stream to ATM Layer

Single ATM CellStream from ATM Layer

Tx direction: cells distributed across links in round robin sequence Rx direction: cells recombined into single ATM stream

IMA Frames

CP13_Ch5_36

ATM F ATM ICP2 ATM F F ATM ICP0ATM F F ATM ICP1F Link 0

ICP2 F ATM FF ICP0 F ATM FATM ICP1 ATMATM ATMATM Link 1

ATM ICP2ATM FF F ICP0ATM ATMATM F ICP1ATM ATMATM Link 2

IMA Frame 2 IMA Frame 1 IMA Frame 0

M–1 2 3 1 0 M–1 2 3 1 0 M–1 2 3 1 0

ICP1 ICP Cell in Frame # 1 F Filler Cell ATM ATM Layer Cell

Time

Version 1 Rev 7Synchronous Digital Hierarchy (SDH)



5–28

Synchronous Digital Hierarchy (SDH)With the advent of fully digital and synchronous networks the CCITT defined a newmultiplexing hierarchy called Synchronous Digital Hierarchy (SDH). In the USA is calledSynchronous Optical Network (SONET) with the two major differences being terminologyand 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) andmultiples of 4n.

This basic rate is known as a Synchronous Transport Module level 1 (STM-1), higherrates are STM-4 and STM-16.

As with PDH, the signal is repetitive frames with a repeat period of 125µs. Any of thePDH rates can be multiplexed into the STM-1.

The main advantages of SDH are:

� It allows direct access to tributary signals without demultiplexing the compositesignal.

� It supports advance operations, administration and maintenance by dedicatingchannels for this purpose. The network can therefore be reconfigured undersoftware control from remote terminals.

� Overhead bytes have been preserved for growth to support services andtechnologies of the future.

Version 1 Rev 7 Synchronous Digital Hierarchy (SDH)



5–29

SDH

CP13_Ch5_19

SDH Bit Rates

Synchronous Transport Module

Transmission Rate

STM – 1

STM – 4

STM – 16

STM – N

155.52 Mb/s

622.08 Mb/s

2,488.32 Mb/s

N x 155.52 Mb/s

Version 1 Rev 7SDH Drop and Insert



5–30

SDH Drop and InsertSDH overcomes the limitations of plesiochronous networks, and will allow transmissionnetworks to evolve to meet the demands of emerging broadband services.

Network Simplification

Synchronous transmission equipment eliminates the multiplexer mountain, leading tolower equipment and maintenance costs, and improved service provisioning. Thediagram shows how 2Mb/s channels can be dropped and inserted from a SynchronousTransfer Module, Type 1 (STM-1) by means of remote commands at a networkmanagement station. The flexibility of SDH transmission is attractive to carriers becauseit offers the potential of generating new revenues.

Survivability

SDH includes overheads for end-to-end monitoring and maintenance of transmissionequipment; the network management station can immediately identify the failure of linksand equipment. Furthermore, as shown in the diagram, an SDH network can beconstructed with a self-healing ring architecture that automatically re-routes traffic untilthe 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 forperformance monitoring, equipment configuration, resource management, networksecurity, inventory management, network planning and network design. Since all ofthese management operations can be performed remotely, SDH offers the possibility ofcentralised network management and provisioning, with associated cost savings.

Bandwidth on Demand

The flexibility of SDH allows carriers to allocate network capacity dynamically in thatusers 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.

Version 1 Rev 7 SDH Drop and Insert



5–31

SDH Drop and Insert

CP13_Ch5_38

SDH Mux

2Mb/s interface

1 63 2

SDH Mux

2Mb/s interface

SDH Mux

2Mb/s interface

SDH Mux

2Mb/s interface

155Mb/s alternate routing using ring topology

Management of 2Mb/s traffic

155Mb/s

155Mb/s

155Mb/s

Version 1 Rev 7Principles of SDH



5–32

Principles of SDHAlthough a full description of SDH is beyond the scope of this course, this section willcover the main principles.

The diagram shows the SDH multiplex structure, indicating how an STM is formed fromvarious PDH traffic rates. The following terms are used in the diagram, and furtherexplained below:

� C - Container

� VC - Virtual Container

� TU - Tributary Units

� TUG - Tributary Unit Group

� AU - Administrative Unit

� AUG - Administrative Unit Group

� STM - Synchronous Transfer Module

The following table lists the container size suffices used when referring to equivalentPDH traffic rates within SDH signals:

Container 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

Version 1 Rev 7 Principles of SDH



5–33

Principles of SDH

CP13_Ch5_37

STM–1 AUG AU–4

TU–3

VC–4

VC–3

VC–11

VC–12

VC–2

VC–3

C–11

C–12

C–2

C–3

C–4 140 Mbit/s

45 Mbit/s 34 Mbit/s

6 Mbit/s

2 Mbit/s

1.5 Mbit/s TU–11

TU–12

TU–2 TUG–2

AU–3

x1

x3

x3

TUG–3 x1

x7

x7 x1

x3

x4

STM–0

Version 1 Rev 7ATM to STM Mapping - VC4



5–34

ATM to STM Mapping - VC4B-ISDN maintains a transmission rate of 155.520 Mbps or 622.080 Mbps. The physicalmedium can be optical with an extension capability of 0 - 800m or coaxial cable with anextension capability of 0 - 100m.

The SDH-based signal is formed by filling the VC-4 payload space of an STM frame withATM cells and the OAM ( Operations, Administration & Maintenance ) signals aretransported via STMs SOH or POH ( Section overhead, Path overhead ). Since, in caseof the transmission speed being 155.520Mbps, only 149.760Mbps is filled with ATM cellsand the other 5.760Mbps is filled with STM frame overheads (SOH, POH, Pointer ).Identifying cell boundaries is done using HEC or an SDH overhead.

Version 1 Rev 7 ATM to STM Mapping - VC4



5–35

ATM to STM Mapping

CP13_Ch5_20

1 octet 260 octets

SOH

SOH

AU4–PTR

3

1

5

VC–4

STM–1

VC–4 POH

ATM Cell

53 octets

9 octets 261 octets

J1

B3

C2

G1

H4

Version 1 Rev 7Typical UMTS Transport Network



5–36

Typical UMTS Transport NetworkThe diagram opposite shows a typical implementation of an ATM transport network tosupport the UMTS interfaces. The UMTS nodes as shown are connected to a singleSDH ring, whereas there may actually be several rings involved depending on thenetwork 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 isutilised 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 andreverse IMA capability. For a large number of Node B’s, the transport network will haveto provide a significant number of E1 interfaces.

The ATM switch will be utilised for VP and VC switching and will be expected to provideaggregation of logical interfaces to physical interfaces via VP and VC switching. TheATM network is also expected to be configurable to limit the throughput of a givenphysical interface. For example, the RNC STM-1 physical interfaces need to be limitedto a bandwidth of 100Mbps due to the hardware limitations.

Version 1 Rev 7 Typical UMTS Transport Network



5–37

ATM Transport Network

CP13_Ch5_39

Node B

SGSN

MSCu

RNC

RNC

RNC

Node BNode B

Node BNode B

ATM Mux

OMCATM Switch

ATM Switch

Ethernet

Ethernet (Option under investigation)

STM–1

STM–1

STM–1

STM–1

STM–1

E1, IMA

E1, IMA

E1, IMA E1, IMA

SDH Ring (STM–1/STM–4/STM–16)

Version 1 Rev 7Typical UMTS Transport Network



5–38



6–1

Chapter 6

W-CDMA Theory

Version 1 Rev 7



6–2

Version 1 Rev 7



6–3

Chapter 6W-CDMA Theory 6–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives 6–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Multiple Access Schemes 6–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

W-CDMA Characteristics 6–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Re-Use of Frequency 6–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Re-Use of Codes 6–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Spectral Efficiency (GSM and UMTS) 6–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Direct Spread (DS)-CDMA Implementation 6–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transmitter 6–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Receiver 6–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Spreading 6–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Orthogonal Codes 6–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Channelisation Code Tree 6–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

De-spreading Other Users Signals 6–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Processing Gain 6–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .




Scrambling 6–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Scrambling Codes vs Channelisaton Codes 6–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Short Codes vs Long Codes 6–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Scrambling and Summation 6–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

De-Scrambling and Data Recovery 6–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Multi-path Radio Channels 6–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Matched Filter Operation 6–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The RAKE Receiver 6–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



6–4




6–1


� Describe various options for multiple access schemes.

� State the Characteristics of UMTS W-CDMA.

� State why W-CDMA has been chosen for the UMTS multiple access scheme.

� Describe W-CDMA spreading and depreading procedures.

� Describe the use of orthagonal codes and the channelisation code tree.

� Describe the scrambling and summation process.

� Describe the effects of multi-path radio channels and the purpose of the RAKEreceiver.

Version 1 Rev 7Multiple Access Schemes



6–2

Multiple Access SchemesThere are 3 forms of multiple access schemes, frequency, time and code. The majorissue 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 thetraditional analogue system. With FDMA, only one subscriber is assigned to a channel atone time. Other subscribers cannot access this channel until the original call isterminated or handed off to a different channel.

Time Division Multiple Access (TDMA)

TDMA is a common multiple access technique employed in digital cellular systems. Itdivides radio channels into time slots to obtain higher capacity. As with FDMA, no otherconversations 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 channelat the same time. CDMA users can share the same frequency channel because theirconversations are distinguished only by digital code.

Version 1 Rev 7 Multiple Access Schemes



6–3

Multiple Access Schemes

CP13_Ch6_01

CDMA

TDMA

Frequency

Power

FDMA

Frequency

Power

Time

Time

Time

Frequency

Codes

Version 1 Rev 7W-CDMA Characteristics



6–4

W-CDMA CharacteristicsThe vital statistics for our W-CDMA UMTS system is shown opposite. Don’t be confusedby the slots and frames, this is not a TDMA system, every user does share the sameband. The frames and slots are used for interleaving, power control.

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 randomcode bit.

The carrier spacing of 200 kHz is used to allow re-farming of GSM frequencies whichhave been set at 200 kHz spacing.

The frame length is set at 10 ms. Each frame is split into 15 timeslots each timeslotcontains user data, power control and signaling data.

The UMTS system does not require synchronisation due to the framing structure and useof matched filters for the framing alignment.

The spreading factor is the ratio between the user data and the chip rate. As the userdata increases this factor will vary between 4 and 512. The spreading factor is a roughindication of the number of users in the system.

The user data rates available in the FDD system is up to 384 Kbps.

Version 1 Rev 7 W-CDMA Characteristics



6–5

W-CDMA Characteristics

CP13_Ch6_03

Multiple Access Scheme

Duplexing Method

Chip Rate

Bandwidth

Carrier Spacing

Frame Length

Slots per Frame

Inter–cell Synchronization

Spreading Factor

User Data Rate

CDMA

FDD

3.84 Mcps

5 MHz

200 kHz Raster

10 ms

15

None

Variable (4–512)

3–384 Kbps

Version 1 Rev 7Re-Use of Frequency



6–6

Re-Use of FrequencyMobile telephones and cell broadcast networks use cellular radio, a technique developedin recent years to enable the use of mobile telephones. It would be impossible to provideeach 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 thenumber of users in the area. In cities cells are small whereas in rural areas cells aremuch larger.

In GSM cells use a set of frequencies that are different from any neighbouring cell, butcan be the same as another cell as long as it is far enough away.

For UMTS, a frequency re-use of one, may be employed. This means that all cells withina given geographical area, or even an entire network may use the same carrierfrequency.

An alternate method of discriminating between neighbouring cells must therefore befound.

Version 1 Rev 7 Re-Use of Frequency



6–7

Re-Use of Frequency

CP13_Ch6_14

1

2

5

3

7

41 6

2

5

3

7

4

1 6

2

5

3

7

4

1 6

2

5

3

7

4

16

2

5

3

7

41 6

2

3

4

1

2

5

7

4

6

3

Version 1 Rev 7Re-Use of Codes



6–8

Re-Use of CodesCodes are used to uniquely identify a cell in the network. Frequency planning is more orless a thing of the past but code planning will have to be implemented. Code planning willbe much easier then frequency planning since we have 512 Codes to play with, the codere-use pattern will thus be extremely large.

Codes can be reused when the separation between cells containing the same channelset is far enough apart so that co-channel interference can be kept below acceptablelevels. The number of cells in a cluster is 512, which provides greater separationbetween co-channel cells than GSM.

Version 1 Rev 7 Re-Use of Codes



6–9

Re-Use of Codes

CP13_Ch6_15

14 6

1615

13

741 27

2830

3129

36 37

225

35

3234

23 39

2018

38

2221

17 19

1110

12

247 4

1

6

5

41

245

3340

26

Version 1 Rev 7Spectral Efficiency (GSM and UMTS)



6–10

Spectral Efficiency (GSM and UMTS)The Slide opposite shows how spectrally efficient UMTS and GSM is in comparison toeach other when employed in a multi-cellular structure.

The capacity, which Shannon derived in 1947, provided a Law, which we now callShannons Law. This details the digital capacity of the link given the transmit power andthe 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.

Version 1 Rev 7 Spectral Efficiency (GSM and UMTS)



6–11

Spectral Efficiency (GSM and UMTS)

CP13_Ch6_06

7 x 200 kHz = 1.4 MHz

1 Call = 25 kHz

8 Calls = 200 kHz Carrier

1 Call = 25 kHz

GSM

7 Cells, 5 MHz

1 Call = 2.8 kHz

256 Calls = 5 MHz Carrier

1 Call = 19.4 kHz

UMTS – SF256

Version 1 Rev 7Direct Spread (DS)-CDMA Implementation



6–12

Direct Spread (DS)-CDMA Implementation

Transmitter

The digital modulator will take digital speech/data and multiply it with the spreading code.

The radio modulator moves the baseline signal from the digital modulator onto a 2Ghzcarrier to produce the W-CDMA output.

Receiver

The modulated carrier is moved by the radio demodulator to the digital demodulatorwhich can be very complicated due to the large number of users.

Here the input is multiplied by the de-spreading codes to produce digital speech.

Version 1 Rev 7 Direct Spread (DS)-CDMA Implementation



6–13

Direct Spread (DS)-CDMA Implementation

CP13_Ch6_26

Single User Channel

5 MHz

Multiple User ChannelMultiple User Channel Output

0

0

Input External Interference

Radio Modulator

Digital Signal

Digital Signal

Spreading Code

Generator

Digital Modulator

Digital Modulator

Radio Modulator

C o m b i n e r

S p l i t t e r

Digital Signal

Digital Signal

Digital Demodulator

Radio Demodulator

Radio Demodulator

Digital Demodulator

t0

RxRadio Carrier

Radio Carrier

Tx

W–CDMA Modulated Carrier

Spreading Code

Generator

5 MHz 5 MHz

Version 1 Rev 7Spreading



6–14

SpreadingThe spreading operation is the multiplication of each user data bit with a “SpreadingCode” , which is a pre-defined bit pattern. To discriminate between User data “bits” andspreading code “bits”, the symbols in the spreading code are referred to as “Chips”. Thechip rate for UMTS is fixed at 3.84 Mcs. After the spreading operation each “Bit” of thedata signal is represented by a number of “chips”.

The number of chips representing each bit is referred to as the “Spreading Factor” (SF)and is given by dividing the chip rate by the source signal bit rate; in this example:

3.84

Mcs / 480 kBs = (SF=8)

The spreading operation has resulted in an increase of the “signalling rate of the userdata, in this case by a factor of 8, and corresponds to a widening of the “spectrum”occupied by the user data signal. Due to this, CDMA systems are more genericallyreferred to as “Spread Spectrum” systems.

The SF is also referred to as the Processing Gain (PG), which is expressed as a Decibelratio and describes the gain or amplitude increase that will be applied to the signal at thereceiving station as a result of the despreading operation. This concept is described inmore detail later in this chapter

Version 1 Rev 7 Spreading



6–15

Spreading

Data 480 kB/s

Spreading

Code

3.84 Mcs

Spread Data

1

–1

1

–1

1

–1

Version 1 Rev 7Spreading



6–16

De-spreading

De-spreading is performed at the receiving station (UE or Node B) by multiplying the chiprate, spread user data signal by a chip rate spreading code. By using the samespreading code as used at the transmitting station for the spreading operation, themultiplication of the two chip rate signals will reproduce the original bit rate user datasignal.

To aid accurate recovery of the user data, a Correlation Receiver is employed in mostCDMA systems. The correlation receiver integrates the product of the de-spreadingprocess on a chip-by-chip basis. In the upper diagram opposite, the example shownillustrated that for a perfectly received de-spread signal, the correlation receiver outputhas effectively “Lifted” the amplitude of the received signal by a factor of 8, a function ofthe processing gain.

Version 1 Rev 7 Spreading



6–17

De-spreading (desired signal)

CP13_Ch6_26b

Spread Data

Spreading

Code

Correlation RX

Integrator O/P

Recovered Data

1 –1

1 –1

1 –1

Version 1 Rev 7Orthogonal Codes



6–18

Orthogonal CodesTransmissons from a single source are separated by channelisation codes. Thechannelisation codes of UTRA are based upon the Orthogonal Variable Spreading Factor(OVSF) technique.

There are a finite number of OVSF codes available, and some restrictions in their use.

OVSF codes are, as their name implies, orthogonal codes. Orthogonal codes possessgood cross correlation properties allowing easy discrimination between signals producedusing correctly selected codes. For OVSF the cross correlation between codes is zero,meaning interferer signals between different codes is effectively “zero” after correlation.

Version 1 Rev 7 Orthogonal Codes



6–19

Orthogonal Codes

CP13_Ch6_18

Channelisation codes known as ”OVSF codes areused to distinguish individual physical channels

The ”OVSF codes” limit the number of users per carrier

OVSF codes are orthogonal codesThe cross correlation between orthogonal codes is zero

1 1 1 1

1 1–1 –1

1–1

1–1

–1 –1

11

Version 1 Rev 7Channelisation Code Tree



6–20

Channelisation Code TreeFor separating channels from the same source, channelisation codes called OrthogonalVariable Spreading Factors are used.

The lines in the diagram represent codes, these are Orthogonal Variable SpreadingFactor (OVSF) codes, allowing to mix in the same timeslot channels with differentspreading factors while preserving the orthogonality. The OVSF codes can be definedusing the code tree shown above.

Each level in the code tree defines a Spreading Factor (SF) indicated in the figure. Allcodes within the code tree cannot be used simultaneously in a given timeslot. A code canbe used in a timeslot if and only if no other code on the path from the specific code to theroot of the tree or in the sub-tree below the specific code is used in this timeslot. Thismeans that the number of available codes in a slot is not fixed but depends on the rateand spreading factor of each physical channel.

The spreading codes can be used to identify individual channels, but a mobile usuallyhas to identify the base station that it is currently parented on. A long code (PN) isusually used for that.

Version 1 Rev 7 Channelisation Code Tree



6–21

Channelisation Code Tree

CP13_Ch6_13

(1, –1, –1, 1, –1, 1, 1, –1)

Cch, 8, 7

Cch, 8, 6(1, –1, –1, 1, 1, –1, –1, 1)

(1, –1, 1, –1, –1, 1, –1, 1)

Cch, 8, 5

Cch, 8, 4

(1, –1, 1,– 1, 1, –1, 1, –1)

(1, 1, –1, –1,– 1, –1, 1, 1)

Cch, 8, 3

Cch, 8, 2

(1, 1, –1, –1, 1, 1, –1, –1)

(1, 1, 1, 1, –1, –1, –1, –1)

Cch, 8, 1

Cch, 8, 0(1, 1, 1, 1, 1, 1, 1, 1)Cch, 4, 0

Cch, 4, 1

Cch, 4, 2

Cch, 4, 3

(1, 1, 1, 1)

(1, 1, –1, –1)

(1, –1, 1, –1)

(1, –1, –1, 1)

Cch, 2, 0

Cch, 2, 1

(1, 1)

(1, –1)

Cch, 1, 0

(1)

SF = 1 SF = 2 SF = 4 SF = 8

Version 1 Rev 7De-spreading Other Users Signals



6–22

De-spreading Other Users SignalsIt must be remembered that in a CDMA system, all users are potentially transmitting onthe same frequency. This means that at any given receiver station, in addition to thedesired signal, multiple “Interferer” signals will also be received. It is the task of thecorrelation receiver to reject these interferer signals.

The lower diagram opposite shows the effect of dispreading and correlation at a givenreceiving station (e.g UE “A”), on an interferer signal, (e.g a signal transmitted on thesame carrier for reception by UE “B”). The de-spreading/correlation of the interferersignal will result in a crosscorrelation of zero. (i.e. the output of the integration processwill be zero.) This process is only true when correctly selected “Orthogonal SpreadingCodes” are employed.

Version 1 Rev 7 De-spreading Other Users Signals



6–23

De-spreading (Interferer Signals)

CP13_CH6_13a

Data for UE B

Spreading Codefor UE B

Spread Datafor UE B

Spread Codefor UE A

1–1

1–1

1–1

1–1

1–1

Recovered Dataat UE A

Correlation RIntegrator O/Pat UE A

This example shows the correlator output when UE A triesto despread UE B’s spread data

Version 1 Rev 7Processing Gain



6–24

Processing GainProcessing Gain can be defined as the Chip Rate divided by the bit rate. This gives aratio 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 is used even inspace transmissions. Processing gain will determine how much the received signal canbe lifted out of the noise floor.

There is one simple rule to follow, the higher the SF the higher the processing gain willbe, the lower the SF the lower the processing gain. As we know, the SF is also inverselyproportional to the speed of the transmission. This means that the higher the speed oftransmission the lower the processing gain will be. Due to this relationship the poweroutput must be increased of any transmitter if the transmission rate is increased due tothe loss in Processing Gain.

This will also mean that if the Frame Error Rate (FER) is increased on the receiver sidethe power must be increased or the transmission rate must drop on the transmitter sideto meet the FER requirement.

Version 1 Rev 7 Processing Gain



6–25

Processing Gain

CP13_Ch6_16

PG = 10 x log (Chip Rate/Bit Rate)

or

PG = 10 x log (SF)

Version 1 Rev 7Exercise 1 - Spreading



6–26

Exercise 1 - SpreadingThis Exercise demonstrates the Modulo-2 Addition, Spreading Factor usage, CodeLengths and in general will give the student a feel for the Spreading Principle.

The Lecturer should use this exercise as an example.

NOTES

_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Version 1 Rev 7 Exercise 1 - Spreading



6–27

Exercise 1 - Spreading

CP13_Ch6_22

Spreading

De–spreading

C/I = 5 dB – 6 dB

= –1 dB

S/N = 5dB

Calculation Box

SF = 4

PG = 4 (ratio)PG = 6 dB

Data

Spreading Code

Spread Data

Spreading Code

De–spread Data

1–1

1–1

1–1

1–1

1–1




6–28

Exercise 2 - SpreadingTo 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 SFand PG. See if it matches with the answers provided.

Note the irregular structure in the answer.

NOTES

_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

_________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________




6–29


CP13_Ch6_23

C/I = 5 dB – 6 dB

= –1 dB

S/N = 5dB

Calculation Box

SF = 4

PG = 4 (ratio)PG = 6 dB

Spreading

De–spreading

Data

Spreading Code

Spread Data

Spreading Code

De–spread Data

Wrong Spreading Code

De–spread Data Wrong Code

1–1

1–1

1–1

1–1

1–1

1–1

1–1




6–30

Exercise 3 - SpreadingIn 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

_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

_________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________




6–31


P13_Ch6_24

C/I =

= –1 dB

S/N = 5db

Calculation Box

SF =

PG =PG =

Spreading

De–spreading

–1

1–1

1–1

1–1

1–1

1–1

1–1

Data

Spreading Code

Spread Data

Spreading Code

De–spread Data

WrongSpreading Code

De–spread DataWrong Code

1

Version 1 Rev 7Scrambling



6–32

ScramblingAs previously described, OVSF spreading codes can be used to separate individualusers on a common RFcarrier freq. However, because of the need to maintainorthogonality of codes, the number of codes available is very limited (512 Downlink, 256Uplink). These 512 code must be reused in every cell, as such they do not becomeunique to a cell and users located at the boundaries of cells, would receive transmissionsusing the same OVSF code, from more than one cell. For UMTS therefore, OVSF codesare used only as Channelisation Codes, used identify individual Physical Channels. Afurther coding, process, known as a “Scrambling” is performed, in order to discriminatebetween the transmissions between different cells on the downlink and different UEs onthe uplink.

Each physical channel is first individually spread to chip rate using a channelisation code(Cch sf,k) taken from the OVSF code tree, resulting in an increase in bandwidth of thesignal form “Bit Rate” to “Chip Rate”

The Sequence of chips produced by the channelisation process is then “Scrambled”,using a chip-to-chip multiplication with a complex-valued scrambling code (Csc). Thecode chosen is used to identify the source of the signal. As scrambling is performed ontop of spreading, it has no further effect on the bandwidth of the signal.

Although the primary purpose of using a scrambling code is to identify all channels from asingle source, that single source may use more than scrambling code. For example, inthe downlink, a cell may transmit using one of 16 possible scrambling codes. Afterscrambling, all physical channels are then combined, using complex addition, beforebeing forwarded to the RF Modulator for transmission.

Version 1 Rev 7 Scrambling



6–33

Scrambling

CP13_Ch6_35

Cch SF,x Csc,x

Cch SF,x Csc, x

Cch SF,x Csc,x

Channel xData

Channel yData

Channel zData

Σ

Version 1 Rev 7Scrambling Codes vs Channelisaton Codes



6–34

Scrambling Codes vs Channelisaton CodesThe Slide shows the major differences between Scrambling Codes (SC) andChannelisation Codes (CC).

Version 1 Rev 7 Scrambling Codes vs Channelisaton Codes



6–35

Scrambling Codes vs Channelisation Codes

CP13_Ch6_12

CC SC

Usage Uplink

Length Uplink

Number of Codesavailable

Code Family

Spreading

Separation of Data & Control Channels(from the same UE)

Separation of channels to different UEs

Separation of UEs

Separation of CellsUsage Downlink

Length Downlink 4 – 512 Chips

No effect on Bandwidth

LC=10ms = Gold CodeSC = Extended S2 Family

Uplink = 2 – 1 = 16,777,215

LC =38400 Chips

LC – 10ms=38400 Chips orSC = 66.7us = 256 Chips

Increases Tx Bandwidth

512 Uplink and Downlink

OVSF

4 – 256 Chips

24

Downlink = 2 – 1 = 262,143(truncated to 8,192)

18

Version 1 Rev 7Short Codes vs Long Codes



6–36

Short Codes vs Long CodesShort codes and Long codes are both used in the UMTS system. The main advantage ofShort Codes is that they have good Auto Correlation properties. This means that they arevery easy to synchronise to.

The main advantage of long codes is that they have excellent cross correlationproperties. This means that they are very resistant to interference from other codes in thenetwork.

Version 1 Rev 7 Short Codes vs Long Codes



6–37

Short Codes vs Long Codes

CP13_Ch6_21

Short codesCode sequence length <TimeslotCode sequence repeated within every timeslotGood auto correlation propertiesBad cross correlation propertiesPlanning Difficult

Code sequence length >> TimeslotCode sequence repeated for each Radio FrameBad auto correlation properties (long repetition cycle)Good cross correlation propertiesPlanning easy

Long codes

Version 1 Rev 7Scrambling and Summation



6–38

Scrambling and SummationThe diagram opposite illustrates the process of scrambling and summation of multiplechannels, prior to modulation onto the RF carrier and transmission over the UMTS airinterface (Uu).

For the purposes of this example, three separate data streams (Channels X, Y and Z),each carrying a user bit sequence of “0,1,1,0”, have been spread using channelisationcodes of Cch 8,1 , Cch 8,2 and Cch 8,3 respectively.

The spread signals are then independently scrambled using a single scrambling code.The resultant chip sequences are then combined using complex addition, to produce themulti level digital baseband signal, that will be used to modulate the RF carrier.

Version 1 Rev 7 Scrambling and Summation



6–39

Scrambling and Summation

CP13_Ch6_36

Spread DataChannel X Cch 8,1

Spread DataChannel Y Cch 8,2

Spread DataChannel Z Cch 8,3

Scramblingcode

Channel X afterscrambling

Channel Y afterscrambling

Channel Z afterscrambling

Complex addedscrambled codes

1–1

1–1

1–1

1–1

1–1

1–1

1–1

+3

+2+1–1–2–3

Version 1 Rev 7De-Scrambling and Data Recovery



6–40

De-Scrambling and Data RecoveryThe diagram opposite illustrates the processes of de-scrambling of a complex scrambledsignal and the recovery of user data from one channel.

The input signal, (derived from the example on the preceding page) is first de-scrambledby multiplication with the specified scrambling code. The result is a combined version ofall received channels, represented by a complex chip sequence.

The dispreading process must now be performed to recover the user data. The exampleillustrates the recovery of the data for Channel “X” from the preceding page. Byperforming a direct multiplication of the complex signal with the appropriatechannelisation code, the illustrated correlation receiver output will be obtained. As canbe seen, the integrated output indicates “Bit Values” of “0,1,1,0”, the expected result forthis example.

Version 1 Rev 7 De-Scrambling and Data Recovery



6–41

De-Scrambling and Data Recovery

CP13_Ch6_37

ReceivedScrambled

ScramblingCode

De–scrambledSignal

Chan Code forChan Y (Cch8.2)

CorrelationOutput

+3+2+1–1–2–3

1–1

+3+2+1–1–2–3

Version 1 Rev 7Multi-path Radio Channels



6–42

Multi-path Radio ChannelsRadio propagation for mobile communications suffers greatly from the effects of mulipathreflections, diffractions and attenuation of the signal energy. These effects are causes byobjects such as buildings, hills, etc, resulting “Multipath Propagation”, which has twomain effects upon the signal.

Inter-symbol Interference

Inter-symbol interference occurs when the signal energy from more than one radio path,pertaining to a single symbol (or chip in the case of W-CDMA), such that the energy fromthe various paths overlaps. This results in the smearing of the signal, such that is hard todefine where one chip starts and one chip ends and the true value of the chips may bedistorted. This problem can be resolved, providing the delay between the two paths isgreater than one chip period (0.26uS at 3.84 Mcs. This equates to a path lengthdifference of 78 m). Delays of 1 or 2 micro seconds are typical in urban areas, with 20uSpossible in hilly areas.

Signal Fade

In multi-path situations where path lengths are multiples of half a wavelength of thereceived frequency (7cm at 2GHz), the signals on two (or more) paths will arrive inanti-phase to each other. This results in cancellation of the signals, causing fast orRayleigh fading. Such fading can result in signal level drops in the order of 20 to 30 dB,making the reception of error free data bits very difficult.

Version 1 Rev 7 Multi-path Radio Channels



6–43

Multi-path Radio Channels

CP13_6_38

Version 1 Rev 7Matched Filter Operation



6–44

Matched Filter OperationThe main task of the matched filter is to determine the timing reference of the informationas it arrives at the receiver.

The filter will perform a chip-by-chip comparison of the received signal against a known“Pilot” reference, to identify multiple copies of the same chip pattern.

After several iterations of the multiple paths have been accumulated, the time dispersionbetween the two paths can be calculated and tracked, allowing the paths to beseparated.

Version 1 Rev 7 Matched Filter Operation



6–45

Matched Filter Operation

CP13_Ch6_27

RFFront EndCircuitry

MatchedFilter

Slot WiseAccumulation

Version 1 Rev 7The RAKE Receiver



6–46

The RAKE ReceiverThe RAKE receiver performs a similar (but not identical) function to the equaliser inGSM. Instead of training bits, the pilot signals (all zeros) are used as a basis for thesearch for the best path. The rake receiver then constructs its fingers to track the othermulti-path rays by stepping through delays one chip at a time until it finds another, lowerlevel pilot. It can then use the weightings to bring the rays into phase and constructiveaddition. Note that the different rays are uncorrelated if the delay difference is greaterthan one chip.

The effect of the propagation environment on spread spectrum modulated signals is toproduce a series of signal components that have traversed differing paths. This is knownas multipath interference and, depending on whether or not there is a significant speculamultipath component, the envelope of the multipath signal may be Rician or Rayleighdistributed.

Multipath results in two signal perturbations, known as Inter-Symbol Interference (ISI)and fading. Both introduce severe degradation in the system performance. ISI createssignal components that are delayed into the next signal period, making these signalsoverlap and therefore interfere with one another. Fading is caused by signals of oppositephase cancelling in the receiver. To combat this, a RAKE receiver may be used. This isthe type of receiver shown in the figure and contains many signal paths, each with anindividual delay. These delays are changed so as the total delay from the transmitter forall paths is the same and thus when combined they are in-phase.

Version 1 Rev 7 The RAKE Receiver



6–47

The RAKE Receiver

CP13_Ch6_28

�0

Cch sf,k

Cch sf,k

Cch sf,k

Cch sf,k

�1

��

��

�1

�2

�3

Version 1 Rev 7The RAKE Receiver



6–48



7–1

Chapter 7

The Physical Layer

Version 1 Rev 7



7–2

Version 1 Rev 7



7–3

Chapter 7The Physical Layer 7–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PICH Channel Structure. 7–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Discontinuous Reception (DRX) on the PICH 7–33. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Secondary Common Control Physical Channel (S-CCPCH) 7–36. . . . . . . . . . . . . . . . . . . . . . . Secondary CCPCH Fields 7–37. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Pysical Random Access Channel (PRACH) 7–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure of the PRACH 7–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Random Access Transmission 7–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PRACH Pre-amble 7–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure of the random-access transmission 7–39. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure of PRACH Message Part 7–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



7–4

Acquisition Indicator Channel AICH) 7–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AICH signature patterns 7–43. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Relationship Between PRACH and AICH 7–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Downlink Dedicated Physical Channels (DL-DPCH) 7–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . DL-DPCH Structure 7–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Downlink Slot Formation in Case of Multi-Code Transmission 7–48. . . . . . . . . . . . . . .

Uplink Dedicated Physical channels (UL-DPCH) 7–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Random Access Procedure in Detail 7–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Random access parameters 7–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical random access procedure 7–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASC to Access Class Mapping 7–56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RACH access slot sets 7–57. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RACH sub-channels 7–57. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RACH Access Slot Availability 7–62. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scaling Factor 7–68. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PRACH/Access Service Class/ Sub channel/Signature Mapping 7–70. . . . . . . . . . . . .

PCPCH (Physical Common Packet Channel) and Associated Physical Signals 7–72. . . . . . CPCH Status Indicator Channel (CSICH) 7–74. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPCH transmission 7–76. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPCH Access Preamble Acquisition Indicator Channel (AP–AICH) 7–78. . . . . . . . . . CPCH Collision Detection/Channel Assignment Indicator Channel (CD/CA–ICH) . . . . . . . 7–80Physical Common Packet Channel (PCPCH) 7–84. . . . . . . . . . . . . . . . . . . . . . . . . . . . . DL–DPCCH for CPCH 7–86. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Downlink Flow Process 7–88. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Uplink Flow Process 7–90. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Radio Frame Equalisation 7–90. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rate Matching 7–90. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DTX 7–90. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .




7–1


� 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.

Version 1 Rev 7Physical Layer Services



7–2

Physical Layer ServicesThe Physical Layer (L1) will be the main discussion in this section since this is wheremost of the air interface tasks are performed.

The physical layer offers data transport services to higher layers. The access to theseservices is through the use of transport channels via the MAC sub-layer. The physicallayer is expected to perform the following functions in order to provide the data transportservice.

� 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 transportchannels (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 (forexample support a speech bearer) they should be assured of successful interworking.Moreover, different implementation options of the same (optional) feature would lead toincompatibility between UE and network. Therefore, this shall be avoided.

Version 1 Rev 7 Physical Layer Services



7–3

Physical Layer Services

CP13_Ch7_02

Macrodiversity distribution, combining 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.

Version 1 Rev 7QPSK



7–4

QPSKThe modulation scheme used in W-CDMA is quadrature phase shift keying (PSK) whichallows 2 bits to be sent per symbol (I and Q). The reason for using QPSK is that it isfairly resilient to amplitude variations. The major problem with CDMA is that all users areon the same frequency and thus interfering with each other.

Version 1 Rev 7 QPSK



7–5

QPSK

CP13_Ch6_09

QPSK

(0,0)

I

QQ

2 bits per symbol

(0,1)

(1,0)(1,1)

Version 1 Rev 7Channel Locations



7–6

Channel LocationsThe Radio Interface is the section of the network between the UE and the Network. Thissection of the network is where the biggest limitation lies at the moment, it is the mostvulnerable section and therefore very complex methods have to be invented in order totransmit the required data at the high speeds that is demanded of today’s networks. Theradio interface is composed of Layers 1, 2 and 3.

The slide opposite shows the UTRA radio interface protocol architecture around thephysical 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 ischaracterized by how the information is transferred over the radio interface.

MAC offers different Logical channels to the Radio Link Control (RLC) sub-layer of Layer2. The type of information transferred characterizes a logical channel.

Physical channels are defined in the physical layer. In FDD mode, physical channels aredefined 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 theTDD mode the physical channels is also characterized by the timeslot. The physical layeris controlled by RRC.

Version 1 Rev 7 Channel Locations



7–7

Channel Locations

CP13_Ch7_08

Layer 2

Layer 1

Logical Channels

Transport Channels

Physical Channels

MAC

Physical Layer

UE

Version 1 Rev 7Structure of Transmission



7–8

Structure of TransmissionThe physical layer receives information, on a transport channel, as Transport Blocks (orTransport Block sets) from Layer 2. This information will consist of User Plane or ControlPlane 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 1controlinformation must be transmitted on the physical channel along with the transport channelinformation.

As previously discussed, even when FDD mode is in use, a Radio Frame/Time Slotstructure is observed. (A 10 mS radio frame is divided into 15 timeslots). Though it isimportant to note that any given radio bearer is able to use all timeslots in every radioframe.

Downlink Transmission

On the downlink each timeslot will contain transport channel information and Layer 1control information in time-multiplex. Each timeslot will contain fields supporting transportblock information, interspersed with Layer 1 control fields. The exact structure of thefields is dependent upon the type of physical channel in use, and is described in detaillater 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 resultin a “Bursty” transmission, which would generate audio band noise perceptible to theother party in a voice call.

To overcome this problem, the transport channel information and Layer 1 controlinformation are I/Q code multiplexed within each timeslot, allowing them to be transmittedin parallel. This make the transmission of Layer 1 control information continuous andhence prevents bursty transmission, even when DTX is applied.

Version 1 Rev 7 Structure of Transmission



7–9

Structure of Transmission

CP13_Ch7_07

I

Q

Version 1 Rev 7Channels on the Air Interface



7–10

Channels on the Air InterfaceThe slide opposite shows the most common channels used on the air interface. Thechannels are divided horizontally into the Physical Channels (PCHs), the TransportChannels (TCHs) and the Logical Channels (LCHs). Vertically they are divided into 2channel types, the Dedicated Channels and the Common channels. Dedicated Channelsare dedicated to one UE only and Common Channels can be shared by multiple UEs.

Version 1 Rev 7 Channels on the Air Interface



7–11

Channels on the Air Interface

Version 1 Rev 7Logical Channels



7–12

Logical ChannelsThe MAC layer provides data transfer services on logical channels. A set of logicalchannel 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 thenetwork does not know the location cell of the UE, or, the UE is in the cell connectedstate (utilising UE sleep mode procedures).

Common Control Channel (CCCH)

Bi-directional channel for transmitting control information between network and UEs. Thischannel is commonly used by the UEs having no RRC connection with the network andby the UEs using common transport channels when accessing a new cell after cellreselection.

Dedicated Control Channel (DCCH)

A point-to-point bi-directional channel that transmits dedicated control informationbetween a UE and the network. This channel is established through RRC connectionset–up procedure.

Traffic Channels

Dedicated Traffic Channel (DTCH)

A Dedicated Traffic Channel (DTCH) is a point-to-point channel, dedicated to one UE, forthe 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 forall or a group of specified UEs.

Version 1 Rev 7 Logical Channels



7–13

Logical Channels

CP13_Ch7_10

DCCH DTCH BCCH PCCH CCCH CTCH

Between MAC and Higher Applications

U–RNTI PTM

Version 1 Rev 7Transport Channels



7–14

Transport ChannelsThe physical layer offers information transfer services to MAC and higher layers. Thephysical layer transport services are described by how and with what characteristics datais transferred over the radio interface. An adequate term for this is ’Transport Channel’. Ageneral classification of transport channels is into two groups:

� Common transport channels (where there is a need for inband identification of theUEs when particular UEs are addressed.

� Dedicated transport channels (where the UEs are identified by the physicalchannel, i.e. code and frequency for FDD and code, time slot and frequency forTDD).

Random Access Channel (RACH)

A contention based uplink channel used for transmission of relatively small amounts ofdata, 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 channelonly exists in FDD mode and only in the uplink direction. The common packet channel isshared by the UEs in a cell and therefore, it is a common resource. The CPCH is fastpower controlled.

Forward Access Channel (FACH)

Common downlink channel without closed-loop power control used for transmission ofrelatively 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, usedin 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 allowingefficient UE sleep mode procedures. Currently identified information types are paging andnotification. 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.

Version 1 Rev 7 Transport Channels



7–15

Transport Channels

CP13_Ch7_11

Between the Physical Layer and MAC

CCH

BCH PCH FACH USCHDSCH

RACH CPCHDCH

Version 1 Rev 7Physical Channels



7–16

Physical Channels

Common Physical Channels (CPCHs)

P-SCH ; S-SCH Primary Synchronisation Channel; Secondary SynchronisationChannel

Synchronisation to the network

P-CCPCH Primary Common Control Physical Channel

Cell Information and 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 carrypacket-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 hasbeen send up

DSCH

Carry information associated with the DCHs

P-CPICH;S-CPICH

Primary Common Pilot Indicator Channel; Secondary PilotIndicator Channel

Helps with channel estimation and shows the attractiveness of thecell

DPDCHDPCCH

Dedicated Physical Channels

Uplink and downlink control and data information; Dedicated to asingle user

Version 1 Rev 7 Physical Channels



7–17

Physical Channels

Version 1 Rev 7Channel Mapping



7–18

Channel MappingThe diagram opposite summarises the mapping of logical channels onto transportchannels, and transport channels onto physical channels.

The DCHs are coded and multiplexed, as described later in this chapter, and the resultingdata stream is mapped sequentially (first-in-first-mapped) directly to the physicalchannel(s).

The mapping of BCH and FACH/PCH is equally straightforward, where the data streamafter coding and interleaving is mapped sequentially to the Primary and SecondaryCCPCH respectively. Note that the BCCH logical channel can be mapped to both BCHand 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 thephysical 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 channelsbut do not have transport channels or indicators mapped to them. Physical signals maybe associated with physical channels in order to support the function of physicalchannels. SCH, CPICH, and AICH are classified as physical signals and hence are notshown on the map opposite.

Version 1 Rev 7 Channel Mapping



7–19

Channel Mapping

CP13_Ch7_14

CTCHCCCHBCCHPCCH DCCHDTCH

DCCHDTCHCCCH

DSCHFACHBCHPCH DCH

PrimaryCCPCH

SecCCPCH

DPDCHDPCCHPDSCH

DPDCHDPCCHPRACH

DCHCPCHRACH

Uplink Downlink

PagingControlChannel

BroadcastControChannel

CommonControlChannel

CommonTrafficChannel

DedicatedControl ChannelDedicatedTraffic Channel

DownloadSharedChannel

PhysicalDownloadChannel

PCPCH

Version 1 Rev 7Generic Frame Structure



7–20

Generic Frame StructureThe diagram opposite illustrates the generic frame structure, use to delimit the transfer ofunits 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 frameis defined as “A processing duration which consists of 15 timeslots. The length of aradio frame corresponds to 38,400 chips.” With a system chip rate of 3.84 McpS beingemployed, 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 asingle frame. To accommodate these procedures, a system frame is defined. The framewithin the system frame structure is identified by a System Frame Number (SFN), whichis a 12 bit binary number, thus a System Frame can consist of 4096 frames.

Timeslot

Each radio frame consists of 15 timeslots. “A slot duration consists of fields containingbits. The length of the slot always corresponds to 2560 chips.” The time duration of atimeslot is approximately 666 uS. The number of fields within each timeslot is dependentupon the physical channel in use. Similarly the number of bits which can beaccommodate by a timeslot is dependent upon the spreading factor in use for thatphysical channel.

Version 1 Rev 7 Generic Frame Structure



7–21

Generic Frame Structure

CP13_Ch7_29

Time Slot = 2560 chips

TS0 TS1 TSn

Frame0

Framen

TS13 TS14

Frame4094

Frame4095

10ms

666µs

SLOT

FRAME

SYSTEM FRAME

40.96 secs

Version 1 Rev 7Synchronisation Channel (SCH)



7–22

Synchronisation Channel (SCH)The Synchronisation Channel (SCH) is a downlink signal used for cell search. The SCHconsists of two sub channels, the Primary and Secondary SCH. The 10 ms radio framesof 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 PrimarySynchronisation Code (PSC) denoted cp in the diagram, transmitted once every slot. ThePSC is the same for every cell in the system.

The Secondary SCH

The Secondary SCH consists of repeatedly transmitting a length 15 sequence ofmodulated codes of length 256 chips, the Secondary Synchronisation Codes (SSC),transmitted in parallel with the Primary SCH. The SSC is denoted cs

i,k in the diagram,where i = 0, 1, …, 63 is the number of the scrambling code group, and k = 0, 1, …, 14 isthe slot number. Each SSC is chosen from a set of 16 different codes of length 256. Thissequence on the Secondary SCH indicates which of the code groups the cell’s downlinkscrambling code belongs to.

Modulation Symbol “a”

The primary and secondary synchronization codes are modulated by the symbol a shownin the diagram, which indicates the presence/ absence of STTD encoding on theP-CCPCH and is given by the following table:

P-CCPCH STTD encoded a = +1

P-CCPCH not STTD encoded a = -1

Version 1 Rev 7 Synchronisation Channel (SCH)



7–23

Synchronisation

CP13_Ch7_21

acp

acsi,0

acp

acsi,1

acp

acsi,2

acp

acsi,3

acp

acsi,14

Tslot = 2560 chips

256 chips

PrimarySCH

SecondarySCH

One 10ms SCH radio frame

Version 1 Rev 7Synchronisation (Cell Search) Procedure



7–24

Synchronisation (Cell Search) ProcedureDuring the cell search, the UE searches for a cell and determines the downlinkscrambling code and frame synchronisation of that cell. The cell search is typicallycarried out in three steps:

Step 1: Slot synchronisation

During the first step of the cell search procedure the UE uses the SCH’s primarysynchronisation code to acquire slot synchronisation to a cell. This is typically done with asingle matched filter (or any similar device) matched to the primary synchronisation codewhich is common to all cells. The slot timing of the cell can be obtained by detectingpeaks 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 secondarysynchronisation code to find frame synchronisation and identify the code group of the cellfound in the first step. This is done by correlating the received signal with all possiblesecondary synchronisation code sequences, and identifying the maximum correlationvalue. Since the cyclic shifts of the sequences are unique the code group as well as theframe synchronisation is determined.

Step 3: Scrambling-code identification

During the third and last step of the cell search procedure, the UE determines the exactprimary scrambling code used by the found cell. The primary scrambling code is typicallyidentified through symbol-by-symbol correlation over the CPICH with all codes within thecode group identified in the second step. After the primary scrambling code has beenidentified, the Primary CCPCH can be detected, and the system and cell specific BCHinformation can be read.

If the UE has received information about which scrambling codes to search for, steps 2and 3 above can be simplified.

Version 1 Rev 7 Synchronisation



7–25

SynchronisationScramblingCode Group

slot number

#0 #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14Group 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

Version 1 Rev 7Common Pilot Channel (CPICH)



7–26

Common Pilot Channel (CPICH)The CPICH is a fixed rate (30 kbps, SF=256) downlink physical channel that carries apre-defined bit/symbol sequence. The diagram opposite shows the frame structure of theCPICH.

In case transmit diversity (open or closed loop) is used on any downlink channel in thecell, the CPICH shall be transmitted from both antennas using the same channelizationand scrambling code. In this case, the pre-defined symbol sequence of the CPICH isdifferent for Antenna 1 and Antenna 2, see figure 14. In case of no transmit diversity, thesymbol 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 referencefor 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 downlinkDPCH. If this is the case, the UE is informed about this by higher-layer signalling.

Version 1 Rev 7 Common Pilot Channel (CPICH)



7–27

CPICH Frame Structure

CP13_Ch7_25

Slot #0 Slot #1 Slot #i Slot #14

Pre–defined symbol sequence

Tslot = 2560 chips, 20 bits = 10 symbols

1 radio frame: Tf = 10ms

Modulation pattern for Common Pilot Channel

CP13_Ch7_25a

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 1

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#iFrame Boundary

Frame#i+1

Version 1 Rev 7P-CCPCH Frame Structure



7–28

P-CCPCH Frame StructureThe Primary CCPCH is a fixed rate (30 kbps, SF=256) downlink physical channels usedto 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 TFCIand no pilot bits are transmitted The Primary CCPCH is not transmitted during the first256 chips of each slot. Instead, Primary SCH and Secondary SCH are transmitted duringthis period.

Version 1 Rev 7 P-CCPCH Frame Structure



7–29

P-CCPCH Frame Structure

CP13_Ch7_19


Data18 bits

Tslot = 2560 chips, 20 bits

Tf = 10ms

(Tx OFF)

256 chips

Version 1 Rev 7SCH and P-CCPCH



7–30

SCH and P-CCPCHThe diagram opposite shows the construction of the SCH and the P-CCPCH. It is thusclear that different channels can be multiplexed onto one link. The structure of these 2Physical Channels are very important to the synchronization process.

Version 1 Rev 7 SCH and P-CCPCH



7–31

SCH and P-CCPCH

CP13_Ch7_20

Frame 0

Data on P–CCPCH

SCH

Frame 1

Data on P–CCPCH Data on P–CCPCH

Frame 2

Version 1 Rev 7 Paging Indicator Channel (PICH)



7–32

Paging Indicator Channel (PICH)

PICH Channel Structure.

The Paging Indicator Channel (PICH) is a fixed rate (SF=256) physical channel used tocarry the Paging Indicators (PI). The PICH is always associated with a S-CCPCH towhich a PCH transport channel is mapped.

The diagram illustrates the frame structure of the PICH. One PICH radio frame of length10 ms consists of 300 bits (b0, b1, …, b299). Of these, 288 bits (b0, b1, …, b287) are usedto carry Paging Indicators. The remaining 12 bits are not formally part of the PICH andshall not be transmitted. The part of the frame with no transmission is reserved forpossible 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 pagingindicator PIp, where p is computed as a function of the PI computed by higher layers, theSFN 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):

(

)

(

)

(

) NN

SFN

SFNSFNSFNPIp

mod144

144mod512/

64/8/18

×

+++×+=

The mapping from {PI0, …, PIN-1} to the PICH bits {b0, …, b287} are according to table22.

If a Paging Indicator in a certain frame is set to ”1” it is an indication that UEs associatedwith this Paging Indicator should read the corresponding frame of the associatedS-CCPCH.




7–33

Structure of Paging Indicator Channel (PICH)

CP13_Ch7_30

One radio frame (10 ms)

288 bits for paging indication

b0

12 bits (transmission off)

b1 b287b288 b299

Mapping of Paging Indicators (PI) to PICH bits

CP13_Ch7_31

Number of PI per frame (N)

N=18

N=36

N=72

N=144

Plp = 1

{b16p, ...,b16p+15} = {-1,-1,...,-1}

{b8p, ...,b8p+7} = {-1,-1,...,-1}

{b4p, ...,b4p+3} = {-1,-1,...,-1}

{b2p,b2p+1} = {-1,-1}

Plp = 0

{b16p, ...,b16p+15} = {+1,+1,...,+1}

{b8p, ...,b8p+7} = {+1,+1,...,+1}

{b4p, ...,b4p+3} = {+1,+1,...,+1}

{b2p,b2p+1} = {+1,+1}

Discontinuous Reception (DRX) on the PICH

The PICH Channel is used to alert the mobile that a possible paging message will bebroadcast to it on the PCH channel. Each mobile will calculate a paging occasion, whichit listens to for such an alert. In order to save on UE battery life the time betweenmonitoring the paging occasions can be altered, also the number of paging indicators perframe that carry the alerts may be configured. These settings are all broadcast in the Cellsystem information messages.

The main parameters that determine the time between the UE monitoring its pagingindicator are as follows:




7–34

DRX Cycle length.

The DRX Cycle Length is made up of a number of system Frames (each 10msecsduration). It is this period that determines how long the mobile is actually in DRX modethus conserving battery power. The cycle is repeated continuously and the UE must onlybecome active once during each cycle. The duration of the cycle is variable and maybealtered to suit network conditions.

Paging Occasion.

The Paging Occasion determines the frame number the UE becomes active in, duringthe DRX Cycle.

Paging Indicator.

The Paging Indicator is repeated multiple times per System Frame. The UE calculateswhich Paging Indicator to listen to using network–determined parameters.

The mobile listens to the system information messages to obtain the parameters requiredfor receiving paging indicators in the selected cell. It then performs a standard calculationusing the cell parameters and its IMSI. The result of this calculation is a single pagingindicator during the DRX cycle time. In other words the mobile must power up and listento the calculated paging indicator (now know as its paging occasion) between a repetitionperiod of 80msecs to 5.12secs (DRX Cycle Period).

The diagram opposite illustrates the frame structure of the PICH.




7–35

Discontinuous Reception Parameters on the PICH

Frame. 10msecs

DRX Cycle, 80msecs to 5.12seconds

Paging Indicators 18,36,72 or 144 per 10msecs PICH Frame.

Calculated Paging OccasionUE is in DRX until this Paging Indicator

CP13_Ch7_21a

Version 1 Rev 7Secondary Common Control Physical Channel (S-CCPCH)



7–36

Secondary Common Control Physical Channel (S-CCPCH)The Secondary CCPCH is used to carry the FACH and PCH. There are two types ofSecondary CCPCH: those that include TFCI and those that do not include TFCI. It is theUTRAN that determines if a TFCI should be transmitted, hence making it mandatory forall UEs to support the use of TFCI. The set of possible rates for the Secondary CCPCHis the same as for the downlink DPCH. The frame structure of the Secondary CCPCH isshown opposite.

The parameter k in the diagram determines the total number of bits per downlinkSecondary CCPCH slot. It is related to the spreading factor SF of the physical channelas SF = 256/2k. The spreading factor range is from 256 down to 4. The values for thenumber of bits per field are given in the table opposite. The channel bit and symbol ratesgiven in the table are the rates immediately before spreading.

The FACH and PCH can be mapped to the same or to separate Secondary CCPCHs. IfFACH and PCH are mapped to the same Secondary CCPCH, they can be mapped to thesame frame.

The main difference between a CCPCH and a downlink dedicated physical channel isthat a CCPCH is not inner-loop power controlled.

The main difference between the Primary and Secondary CCPCH is that the transportchannel mapped to the Primary CCPCH (BCH) can only have a fixed predefinedtransport format combination, while the Secondary CCPCH support multiple transportformat combinations using TFCI. Furthermore, a Primary CCPCH is transmitted over theentire cell while a Secondary CCPCH may be transmitted in a narrow lobe in the sameway as a dedicated physical channel (only valid for a Secondary CCPCH carrying theFACH).

For slot formats using TFCI, the TFCI value in each radio frame corresponds to a certaintransport format combination of the FACHs and/or PCHs currently in use. Thiscorrespondence is (re-)negotiated at each FACH/PCH addition/removal.

Version 1 Rev 7 Secondary Common Control Physical Channel (S-CCPCH)



7–37

S-CCPCH Frame Structure

CP13_Ch7_23


Data Ndatabits

Pilot Npilotbits

TFCI NTFCIbits

Tslot = 2560 chips, 20*2kbits (k = 0..6)

1 radio frame: Tf = 10ms

Secondary CCPCH Fields

Slot Format#i

Channel BitRate (kbps)

ChannelSymbol Rate

(ksps)

SF Bits/ Frame Bits/Slot

Ndata Npilot NTFCI

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.

Version 1 Rev 7Pysical Random Access Channel (PRACH)



7–38

Pysical Random Access Channel (PRACH)

Structure of the PRACH

The random-access transmission is based on a Slotted ALOHA approach with fastacquisition indication. The UE can start the random-access transmission at the beginningof a number of well-defined time intervals, denoted access slots. There are 15 accessslots 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 givenby higher layers and is based upon the Access Service Class (ASC) of the UE

Random Access Transmission

The structure of the random-access transmission is also shown opposite. Therandom-access transmission consists of one or several preambles of length 4096 chipsand 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 oflength 16 chips. There are a maximum of 16 available signatures

Version 1 Rev 7 Pysical Random Access Channel (PRACH)



7–39

RACH access slot numbers and their spacing

CP13_Ch7_32

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

5120 chips

Access slot

radio frame: 10 ms radio frame: 10 ms





Structure of the random-access transmission

CP13_Ch7_33

Message part

10 ms (one radio frame)

Message part

20 ms (two radio frames)

PreamblePreamblePreamble

4096 chips

PreamblePreamblePreamble

4096 chips

Version 1 Rev 7Pysical Random Access Channel (PRACH)



7–40

Structure of PRACH Message Part

The structure of the Random-access message part is shown opposite. The 10 msmessage is split into 15 slots, each of length Tslot = 2560 chips. Each slot consists of twoparts, a data part that carries Layer 2 information and a control part that carries Layer 1control 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 spreadingfactor of 256, 128, 64, and 32 respectively for the message data part. The value for thenumber 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 coherentdetection and 2 TFCI bits. This corresponds to a spreading factor of 256 for the messagecontrol 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-accessmessage.

The Random Access Channel(s) (RACH) is characterised by:

� Existence in uplink only

� Limited data field

� Collision risk

� Open loop power control

Version 1 Rev 7 Pysical Random Access Channel (PRACH)



7–41

Structure of the PRACH Message Part

CP13_Ch7_24


Data Ndatabits

Pilot Npilotbits

TFCI NTFCIbits


Message part radio frame TRACH = 10ms

Data

Control

Random-access message data fields

CP13_Ch7_24a

Slot Format #i Channel Bit Rate (kbps)

Channel Symbol Rate

(ksps)

SFBits/

Frame Bits/Slot Ndata

0 15 15 256 10 10 150

1 30 30 128 20 20 300

2 60 60 64 40 40 600

3 120 120 32 80 80 1200

Version 1 Rev 7Acquisition Indicator Channel AICH)



7–42

Acquisition Indicator Channel AICH)The Acquisition Indicator channel (AICH) is a fixed rate (SF=256) physical channel usedto carry Acquisition Indicators (AI). Acquisition Indicator AIs corresponds to signature son 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 oflength 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 chipswith no transmission that is not formally part of the AICH. The part of the slot with notransmission is reserved for possible use by CSICH or possible future use by otherphysical 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

0js,sj bAIa

s

where AIs, taking the values +1, -1, and 0, is the acquisition indicator corresponding tosignature s and the sequence bs,0, …, bs,31 is given in the table opposite. Thereal-valued symbols, aj, are spread and modulated in the same fashion as bits whenrepresented in { +1, -1 } form.

Version 1 Rev 7 Acquisition Indicator Channel AICH)



7–43

Structure of Acquisition Indicator Channel (AICH)

CP13_Ch7_34

AS # 14 AS # 0 AS # 1 AS # i AS # 14 AS # 0

20 ms

a0 a31a30a2a1 Transmission Off

Al part = 4096 chips, 32 real–valued symbols 1024 chips

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

Version 1 Rev 7Relationship Between PRACH and AICH



7–44

Relationship Between PRACH and AICHThe PRACH contains two sets of access slots as shown below. Access slot set 1contains PRACH slots 0 – 7 and starts τp–a chips before the downlink P–CCPCH framefor which SFN mod 2 = 0. Access slot set 2 contains PRACH slots 8 – 14 and starts(τp–a –2560) chips before the downlink P–CCPCH frame for which SFN mod 2 = 1.

AICH accessslots

10 ms

#0 #1 #2 #3 #14#13#12#11#10#9#8#7#6#5#4τp–a

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

PRACHaccess slots

SFN mod 2 = 0 SFN mod 2 = 1

10 ms

Access slot set 1 Access slot set 2

Version 1 Rev 7 Relationship Between PRACH and AICH



7–45

PRACH/AICH Relationship

AICH accessslots

10 ms

#0 #1 #2 #3 #14#13#12#11#10#9#8#7#6#5#4τp–a

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

PRACHaccess slots


10 ms


Version 1 Rev 7Downlink Dedicated Physical Channels (DL-DPCH)



7–46

Downlink Dedicated Physical Channels (DL-DPCH)

DL-DPCH Structure

There is only one type of downlink dedicated physical channel, the Downlink DedicatedPhysical Channel (downlink DPCH).

Within one downlink DPCH, dedicated data generated at Layer 2 and above, i.e. thededicated transport channel (DCH), is transmitted in time-multiplex with controlinformation generated at Layer 1 (known pilot bits, TPC commands, and an optionalTFCI). The downlink DPCH can thus be seen as a time multiplex of a downlink DPDCHand a downlink DPCCH, compare subclause.

The diagram opposite shows the frame structure of the downlink DPCH. Each frame oflength 10 ms is split into 15 slots, each of length Tslot = 2560 chips, corresponding to onepower-control period. The parameter k in the diagram determines the total number of bitsper downlink DPCH slot. It is related to the spreading factor SF of the physical channelas SF = 512/2k. The spreading factor may thus range from 512 down to 4. The exactnumber of bits of the different downlink DPCH fields (Npilot, NTPC, NTFCI, Ndata1 andNdata2) is dependent upon the SF. What slot format to use is configured by higher layersand can also be reconfigured by higher layers.

There are basically two types of downlink Dedicated Physical Channels; those thatinclude 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 betransmitted 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 thereceiving node.

TPC symbol will indicate a step increase or decrease of transmitter power by thereceiving node.

TPC Bit Pattern Transmitter powercontrol command

NTPC = 2 NTPC = 4 NTPC = 8

11

00

1111

0000

1111 1111

00000000

1

0

Version 1 Rev 7 Downlink Dedicated Physical Channels (DL-DPCH)



7–47

Frame Structure for Downlink DPCH

CP13_Ch7_16


Data 1 TPC TFCI Data 2 Pilot

Npilot bits

DPDCH DPCCH DPDCH DPCCH

One radio frame = 10ms

Tslot = 2560 chips

Version 1 Rev 7Downlink Dedicated Physical Channels (DL-DPCH)



7–48

Downlink Slot Formation in Case of Multi-Code Transmission

For slot formats using TFCI, the TFCI value in each radio frame corresponds to a certaincombination of bit rates of the DCHs currently in use. This correspondence isre-negotiated at each DCH addition/removal.

When the total bit rate to be transmitted on one downlink CCTrCH exceeds the maximumbit rate for a downlink physical channel, multicode transmission is employed, i.e. severalparallel downlink DPCHs are transmitted for one CCTrCH using the same spreadingfactor. 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 dataduring 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

Version 1 Rev 7 Downlink Dedicated Physical Channels (DL-DPCH)



7–49

Downlink Slot Format in Case of Multi-Code Transmission

CP13_Ch7_17

TPC TFCI Pilot

DPDCHDPDCH

One Slot (2560 chips)

Physical Channel 1

Physical Channel L

Physical Channel 2

TransmissionPower

TransmissionPower

TransmissionPower

Version 1 Rev 7Uplink Dedicated Physical channels (UL-DPCH)



7–50

Uplink Dedicated Physical channels (UL-DPCH)There are two types of uplink dedicated physical channels, the uplink Dedicated PhysicalData Channel (uplink DPDCH) and the uplink Dedicated Physical Control Channel (uplinkDPCCH).

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 1control information consists of known pilot bits to support channel estimation for coherentdetection, transmit power-control (TPC) commands, feedback information (FBI), and anoptional transport-format combination indicator (TFCI). The transport-format combinationindicator informs the receiver about the instantaneous transport format combination ofthe transport channels mapped to the simultaneously transmitted uplink DPDCH radioframe.

There is one and only one uplink DPCCH on each radio link.

The diagram opposite shows the frame structure of the uplink dedicated physicalchannels. 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. Itis related to the spreading factor SF of the DPDCH as SF = 256/2k. The DPDCHspreading factor may range from 256 down to 4, giving data rates between 15kbs and960kbs The spreading factor of the uplink DPCCH is always equal to 256, i.e. there are10 bits per uplink DPCCH slot. What slot format to use is configured by higher layers andcan also be reconfigured by higher layers.

The FBI bits are used to support techniques requiring feedback from the UE to theUTRAN Access Point, including closed loop mode transmit diversity and site selectiondiversity 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-rateservices). It is the UTRAN that determines if a TFCI should be transmitted and it ismandatory for all UEs to support the use of TFCI in the uplink.

Multi-code operation is possible for the uplink dedicated physical channels. Whenmulti-code transmission is used, several parallel DPDCH are transmitted using differentchannelization codes. However, there is only one DPCCH per radio link.

Version 1 Rev 7 Uplink Dedicated Physical channels (UL-DPCH)



7–51

Frame Structure for Uplink DPDCH/DPCCH

CP13_Ch7_18


DPDCH

DPCCH

DataNdatabits

PilotNpilotbits

TFCINTFCIbits

FBINFBIbits

TPCNTPCbits


Tf = 10ms

Version 1 Rev 7The Random Access Procedure in Detail



7–52

The Random Access Procedure in Detail

Random access parameters

PRACH

– Access Slot (FDD only).

– Preamble scrambling code (FDD only).

– Available preamble signatures (FDD only).

– Spreading factor for data part.

– Power control info:

– UL target SIR;

– primary CCPCH DL TX Power;

– UL interference;

– power offset (Power ramping) (FDD only).

– Access Service Class Information (PRACH Partitioning):

– Available signatures for each ASC (FDD only).

– Available Subchannels for each ASC.

– AICH transmission timing parameter (FDD only).

Physical random access procedure

The physical random–access procedure shall be performed as follows:

1. Derive the available uplink access slots, in the next full access slot set, for the setof available RACH sub–channels within the given ASC. Randomly select oneaccess slot among the ones previously determined. If there is no access slotavailable in the selected set, randomly select one uplink access slot correspondingto the set of available RACH sub–channels within the given ASC from the nextaccess slot set. The random function shall be such that each of the allowedselections is chosen with equal probability.

2. Randomly select a signature from the set of available signatures within the givenASC. The random function shall be such that each of the allowed selections ischosen with equal probability.

3. Set the Preamble Retransmission Counter to Preamble Retrans Max.

4. Set the parameter Commanded Preamble Power to Preamble_Initial_Power.

5. In the case that the Commanded Preamble Power exceeds the maximum allowedvalue, set the preamble transmission power to the maximum allowed power. In thecase that the Commanded Preamble Power is below the minimum level required,set the preamble transmission power to a value, which shall be at or above theCommanded Preamble Power and at or below the required minimum power.Otherwise set the preamble transmission power to the Commanded PreamblePower. Transmit a preamble using the selected uplink access slot, signature, andpreamble transmission power.

Version 1 Rev 7 The Random Access Procedure in Detail



7–53

Decrement Preamble Transmissioncounter M

Y

N

Indicate to higher layerthat maximum number ofpreamble cycles have beenreached (TX status”unsuccessful”)

Ack

(PRACH message part transmitted)End

N

Y

M = Mmax

N

Y

NOTE: MAC–c/sh receivesRACH tx control parameters fromRRC with CMAC–CONFIG–Req–primitive whenever one of theparameters is updated

ASC selection:

End

Start

Get RACH tx control parametersfrom RRC: Mmax, NB02min,NB01Max, set of ASC parameters

Any data to betransmitted?

M = 0

Update RACH tx controlparameters

Set Timer T2 (10 ms)Wait expiryTime T2 (10ms)

Wait expiryTime T2 (10ms)

Set and wait expirytimer TB01 (NB01*10ms)

(PRACH partition i, Pi)

Draw random number 0�Ri<1

R�Pi?

Send PHY–ACCESS=REQ(start of L1 PRACHtransmission procedure)


L1 access info?No Ack Nack

Send PHY–DATA=REQindicate TX status to higherlayer




7–54

6. If no positive or negative acquisition indicator (AI ≠ +1 nor –1) corresponding to theselected signature is detected in the downlink access slot corresponding to theselected uplink access slot:i. Select the next available access slot in the set of available RACH

sub–channels within the given ASC.

ii. Randomly select a new signature from the set of available signatures withinthe given ASC. The random function shall be such that each of the allowedselections is chosen with equal probability.

iii. Increase the Commanded Preamble Power by ∆P0 = Power Ramp Step[dB]. If the Commanded Preamble Power exceeds the maximum allowedpower by 6dB, the UE may pass L1 status (”No ack on AICH”) to the higherlayers (MAC) and exit the physical random access procedure.

iv. Decrease the Preamble Retransmission Counter by one.

v. If the Preamble Retransmission Counter > 0 then repeat from step 5.Otherwise pass L1 status (”No ack on AICH”) to the higher layers (MAC)and exit the physical random access procedure.

7. If a negative acquisition indicator corresponding to the selected signature isdetected in the downlink access slot corresponding to the selected uplink accessslot, pass L1 status (”Nack on AICH received”) to the higher layers (MAC) and exitthe physical random access procedure.

8. Transmit the random access message three or four uplink access slots after theuplink access slot of the last transmitted preamble depending on the AICHtransmission timing parameter. Transmission power of the control part of therandom access message should be P p–m [dB] higher than the power of the lasttransmitted preamble. Transmission power of the data part of the random accessmessage is set according to subclause 5.1.1.2.

9. Pass L1 status ”RACH message transmitted” to the higher layers and exit thephysical random access procedure.




7–55

Decrement Preamble Transmissioncounter M

Y

N

Indicate to higher layerthat maximum number ofpreamble cycles have beenreached (TX status”unsuccessful”)

Ack

(PRACH message part transmitted)End

N

Y

M = Mmax

N

Y

NOTE: MAC–c/sh receivesRACH tx control parameters fromRRC with CMAC–CONFIG–Req–primitive whenever one of theparameters is updated

ASC selection:

End

Start

Get RACH tx control parametersfrom RRC: Mmax, NB02min,NB01Max, set of ASC parameters

Any data to betransmitted?

M = 0

Update RACH tx controlparameters

Set Timer T2 (10 ms)Wait expiryTime T2 (10ms)


Set and wait expirytimer TB01 (NB01*10ms)

(PRACH partition i, Pi)

Draw random number 0�Ri<1

R�Pi?

Send PHY–ACCESS=REQ(start of L1 PRACHtransmission procedure)


L1 access info?No Ack Nack

Send PHY–DATA=REQindicate TX status to higherlayer




7–56

ASC to Access Class Mapping

All UEs are members of one out of ten randomly allocated mobile populations, defined asAccess Classes 0 to 9. The population number is stored in the SIM/USIM. In addition,mobiles may be members of one or more out of 5 special categories (Access Classes 11to 15), also held in the SIM/USIM. These are allocated to specific high priority users asfollows. (The enumeration is not meant as a priority sequence):

Class 15 PLMN Staff

Class 14 Emergency Services

Class 13 Public Utilities (e.g. water/gas suppliers)

Class 12 Security Services

Class 11 For PLMN Use

If the UE is a member of at least one Access Class, which corresponds to the permittedclasses as signalled over the air interface, and the Access Class is applicable in theserving network, access attempts are allowed. Otherwise access attempts are notallowed.

Access Classes are applicable as follows:

Class 0–9 Home and Visited PLMNs

Class 11 and 15 Home PLMN only

Classes 12, 13, 14 Home PLMN and visited PLMNs ofhome country only.

Any number of these classes may be barred at any one time.

An additional control bit known as ”Access Class 10” is also signalled over the airinterface to the UE. This indicates whether or not network access for Emergency Calls isallowed for UEs with access classes 0 to 9 or UEs without an IMSI. For UEs with accessclasses 11 to 15, Emergency Calls are not allowed if both ”Access class 10” and therelevant Access Class (11 to 15) are barred. Otherwise, Emergency Calls are allowed.

All Emergency Calls use ASC0, and all ACs being in the range from 0 to 9 are mapped toASC1.

The AC10 to AC15 are in turn mapped to ASCi, where i=2,…,7 respectively. Mappingfunction is specified by fixed assignment AC to ASC based on OMC provisionedparameters.




7–57

Access Service Class to Access Class Mapping

ACASC

0–91st IE

102nd IE

113rd IE

124th IE

135th IE

146th IE

157th IE

ACASC

0–91

100

112

124th IE

135th IE

146th IE

157th IE

ACASC

0–91

100

113

124

135th IE

146th IE

157th IE

Partitions not available (i.e. not configured)

CP13_Ch7_p72

RACH access slot setsThe PRACH contains two sets of access slots as shown in Figure 2. Access slot set 1contains PRACH slots 0 – 7 and starts p–a chips before the downlink P–CCPCH framefor which SFN mod 2 = 0. Access slot set 2 contains PRACH slots 8 – 14 and starts(p–a –2560) chips before the downlink P–CCPCH frame for which SFN mod 2 = 1.

RACH sub-channelsA RACH sub–channel defines a sub–set of the total set of uplink access slots. There area total of 12 RACH sub–channels. RACH sub–channel #i (i = 0, …, 11) consists of thefollowing uplink access slots:

– Uplink access slot #i leading by τp–a chips the downlink access slot #i contained withinthe 10 ms interval that is time aligned with P–CCPCH frames for which SFN mod 8 = 0or SFN mod 8 = 1.

– Every 12th access slot relative to this access slot.

The access slots of different RACH sub–channels are also illustrated in the Table below.

Table 7-1 The available uplink access slots for different RACH sub–channels

Sub-channel number

SFN modulo 8 ofcorrespondingP-CCPCH frame

0 1 2 3 4 5 6 7 8 9 10 11




7–58

Sub-channel number

0 0 1 2 3 4 5 6 7

1 12 13 14 8 9 10 11

2 0 1 2 3 4 5 6 7

3 9 10 11 12 13 14 8

4 6 7 0 1 2 3 4 5

5 8 9 10 11 12 13 14

6 3 4 5 6 7 0 1 2

7 8 9 10 11 12 13 14

Each 10msecs RACH frame is associated with a set of sub channel numbers as shownin the table above. There are 12 sub channels for each 10msec RACH frame. Each subchannel number is either associated with a RACH access slot number or it there is noassociation and the field is blank. Remember there are 15 RACH access slots




7–59

RACH Access Slot Availability

AICH accessslots

10 ms

#0 #1 #2 #3 #14#13#12#11#10#9#8#7#6#5#4τp–a

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

PRACHaccess slots


10 ms


RACH Sub-Channels

Sub-channel number

SFN modulo 8of

correspondingP-CCPCH

frame

0 1 2 3 4 5 6 7 8 9 10 11

0 0 1 2 3 4 5 6 7

1 12 13 14 8 9 10 11

2 0 1 2 3 4 5 6 7

3 9 10 11 12 13 14 8

4 6 7 0 1 2 3 4 5

5 8 9 10 11 12 13 14

6 3 4 5 6 7 0 1 2

7 8 9 10 11 12 13 14




7–60

The Sub Channel frames are repeated over a cycle of eight 10msecs frames (Modulo 8).Each of the eight sub channel frames indicates different RACH access slot availability.The UE will use the current Sub channel frame as part of the decision in selecting aRACH access slot in which to transmit.




7–61

RACH Subchannels

CP13_Ch7_24b

1 2 3 4 5 6 7 8 9 10 11 12 13 14 151 2 3 4

10msecs 10msecs

RACH ACCESS SLOTS

Frame 0 1 2 3 40 5 6 77

Frame 1 13 1412 8 9 10 11

1 2 3 4Frame 2 0 5 6 7

Sub Channel Number

0 1

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

2 3 4 5 6 7 8 9 10 11

0 1 2 3 4 5 6 7 8 9 10 11

0 1 2 3 4 5 6 7 8 9 10 11




7–62


Each Access Service class is mapped to a network parameter ‘Assigned sub channelnumber’. This is broadcast in System information number 5 for every cell. The parameteris made up of 3 or 4 bits that are repeated 4 or 3 times in order to make up a 12 bitpattern. This pattern is then logically anded to a parameter ‘Available Sub channelnumber’. This is a 12 bit bitmap which represents the available sub channel numbers foreach access service class. The result of this ‘and’ operation is then combined again withthe current sub channel frame. The result of this is another 12 bit bitmap where a logical1 indicates the indicated sub channel is available for use (and consequently the RACHAccess Slot) and a 0 means it cannot be used. This is illustrated in the diagram opposite.




7–63


CP13_Ch7_Rach access slot avail

The b Bitmaps are logically added to the 12 bit Bitmap using the AND function

Sub Slots Allowed – 12 Bit Bitmap

Sub Slots Allowed – 12 Bit Bitmap

&

=

Frame 1

The Result Of combining Sub slots allowed, b bits and Sub channels allowed is sub channels 9 and 11Thus a mobile in an Access Service class with this set of b bits may choose partion 9 or 11 for this frame

For this frame the UE would choose frompartitions 13, 9 or 11.

&

b3, b2, b1, b0 or b2, b1, b0 are set for each Access Service Class

.

They are repeated 3 or 4 times to make a bitmap of 12 Bits

0 1 0 0 1 1 0 0 0 1 10

b1b2 b0 b1b2 b0 b1b2 b0 b1b2 b0

1 0 1 1 0 1 1 0 1 1 0 1

0 0 0 0 0 0 0 01 1 10

0 1 0 0 1 1 0 0 0 1 10

b1b2 b0b3 b1b2 b0b3 b1b2 b0b3

1 0 11 1 0 11 1 0 11

0 1 0 0 1 1 0 0 0 1 10

12 13 14 8 9 10 11

0 0 0 0 0 1 0 0 0 1 0 1

12 13 14 8 9 10 11

0 1 0 0 1 1 0 0 0 1 0 1




7–64

Persistence Value and PRACH Partitioning

Each Access Service class (ASC) is defined by an identifier I (0–7). This identifier is thenmapped to one of more PRACH Access Slots (max 15). The mapped slots are thenknown as a PRACH Partition. One or more ASC maybe mapped to the same PRACHAccess slot therefore the subsequent partitions for each ASC may overlap each other.Associated with each ASC is a Persistence value. This value (1–8) is used to influencethe probability of a PRACH Pre–amble being transmitted in the selected PRACH accessslot.




7–65

Persitence Value and PRACH Partitioning

An ASC Is defined by an identifier, i, that defines acertain partition of the PRACH resources and anassociated persistence value Pi

The persistence values Pi to be associated with eachASC shall be derived from the dynamic persistencelevel N = 1, ... , 8

CP13_Ch7_p63

ASC #1

P(N) P(N) P(N)P(N)P(N)P(N)P(N)1Pi

0 1 2 3 4 5 6 7




7–66

Calculating the persistence value

The Persistence value is between 1 and 8 and is determined by the network for eachASC. The Value programmed is multiplied in the formula P(N) = 2 –(N–1). The valuesthat result are between 0 and 1. These are then compared with a Random Numberbetween 0 and 1, in 0.1 steps, generated by the UE. If the Persistence value is equal orless than the random number then the Access procedure is allowed to continue. If it isgreater then the UE must wait 10msecs and try again with a new set of values.




7–67

Calculating the Persistence Value

Example if N = 2 the P(N) = 0.5

The UE chooses a random number between 0 and 1in 0.1 steps. It then compares this with the P(N)value and if equal or less it can then continue withthe access procedure, if not it tries again 10msecslater

ASC #1

P(N) P(N) P(N)P(N)P(N)P(N)P(N)1Pi

0 1 2 3 4 5 6 7

P(N) = 2 –(N–1) N = 1 to 8

S = 0 to 1 in 0.1 steps

CP13_Ch7_p65




7–68

Scaling Factor

The Scaling Factor is optional and if implemented only applies to ASC 2 to 7. Ifimplemented the Scaling Factor has the effect of altering the probability of the accessprocedure continuing onto transmission of a pre–amble or waiting 10msecs andrecalculating all access parameters again. The example opposite shows how the accessprocedure is allowed if a scaling factor is applied but not allowed if it was not applied. TheScaling Factor maybe dynamically controlled by the network for access controlprocedures. It has a range of 0 to 1 in 0.1 steps and is multiplied with the calculatedPersistence value to produce the new result for comparison with the UE generatedRandom number.




7–69

Scaling Factor

Example: with a persistence value of 0.5 and a random number of0.4 the access procedure would not continue. If a scaling factor of0.1 were applied, the new persistence value would be 0.05 and theUE would be able to continue with the access procedure

ASC #1

S5P(N) S6P(N) S7P(N)S4P(N)S3P(N)S2P(N)P(N)1Pi

0 1 2 3 4 5 6 7

The Scaling Factor is optional and if implemented only applies toAccess service classes 2 to 7.

The Scaling Factor value can be within the range of0 in 0.1 increments.If implementing the Scaling Factor has the effect ofaltering the probability of access procedurecontinuing by making the persistence value smalleror larger.

CP13_Ch7_p67




7–70

PRACH/Access Service Class/ Sub channel/Signature Mapping

The diagram opposite shows several PRACH channels and their mapping to pre–amblescrambling codes, Access Service Classes, Sub channels and available pre–amblesignatures. It also shows that the different ASCs are mapped to different PRACH slots.Each pre–amble signature is also associated to a particular PRACH access slot (0–15).In this way Partitions maybe created for the exclusive use of particular ASCs. Notethough that it is also possible for all ASCs to share the same pre–amble signature, subchannel and pre–amble scrambling code as this is a contention based access systemand collisions are possible between UEs requesting network resources.




7–71

PRACH/Access Service Class/Subchannel/SignatureMapping

avai

labl

e pr

eam

ble

sign

atur

es (

max

16)

avai

labl

e

subc

hann

els

(max

12)

PR

AC

H p

artit

ions

(one

par

titio

n pe

r A

SC

,

max

. 8 p

er P

RA

CH

)

AS

C 0

AS

C 1

AS

C 2

AS

C 0

AS

C 1

AS

C 2

PR

AC

H

(max

16

per

cell)

PR

AC

H 0

PR

AC

H 1

RA

CH

(max

16

per

cell)

RA

CH

0R

AC

H 1

Pre

ambl

e sc

ram

blin

g co

de

(max

16

per

cell)

Pre

ambl

e

scra

mbl

ing

code

0

Pre

ambl

e

scra

mbl

ing

code

1

015

011

015

011

AS

C 3

AS

C 0

AS

C 1

AS

C 2

PR

AC

H 2

RA

CH

2

Pre

ambl

e

scra

mbl

ing

code

2

09

011

AS

C 0

AS

C 1

PR

AC

H 3

RA

CH

3

Pre

ambl

esc

ram

blin

g

code

2

1015

011

Par

titio

n no

t av

aila

ble

on P

RA

CH

2

Par

titio

n no

t av

aila

ble

on P

RA

CH

3

Cod

ing

Cod

ing

Cod

ing

Cod

ing

CP13_Ch7_p69

Version 1 Rev 7PCPCH (Physical Common Packet Channel) and Associated Physical Signals



7–72

PCPCH (Physical Common Packet Channel) and AssociatedPhysical Signals

Physical Channels/Signals Required to support the CPCH

The Following parameters are required for the PCPCH:

PCPCH

– CPCH Set ID to which this PCPCH belongs.

– Parameters related to the AP preamble:

– Access Preamble (AP) scrambling code;

– available AP signatures/sub channels for access request;

– Parameters related to the CD preamble:

– CD preamble scrambling code;

– available CD signatures/subchannels;

– Parameters related to PCPCH message part:

– PCPCH scrambling code;

– PCPCH Channelisation code;

– data rate (spreading factor);

– N_frames_max: Maximum length of CPCH message in radio frames.

CD/CA–ICH

– CPCH Set ID.

– Scrambling code.

– Channelisation code.

– Tx diversity mode.

NOTE This physical channel is used in conjunction with PCPCH whenChannel Assignment is active.

CSICH

– CPCH Set ID.

– Scrambling code.

– Channelisation code.

– Tx diversity mode.

NOTE The values for the parameters need to be consistent with theAP–AICH that is time–multiplexed with this CSICH.

DL–DPCCH for CPCH

– The downlink DPCCH for CPCH is a special case of downlink dedicated physicalchannel of the slot format #0. The spreading factor for the DL–DPCCH is 512

Version 1 Rev 7 PCPCH (Physical Common Packet Channel) and Associated Physical Signals



7–73

Channels required to support an UL Common PacketChannel

� Pysical Common Packet Channel - PCPCH

� Access Preamble Acquisition Indicator Channel(AP-AICH)

� Collision Detection/Channel Assignment IndicatorChannel - CD/CA-ICH

� CPCH Status Indicator Channel - CSIC H

� Downlink Dedicated Physical Control Channel forCPCH - DL-DPCCH for CPCH

CP13_Ch7_p74




7–74

CPCH Status Indicator Channel (CSICH)

In order to avoid unnecessary access attempts when all CPCH channels are occupied,thus improving CPCH throughput, the UE will ascertain the current status of the CPCHsusing the CSICH.

The CSICH “Broadcasts” Status Indicators (SIs), which convey the following information:

� When Channel Assignment is NOT Active

In this mode, the CSICH conveys the PCPCH Channel Availability value, which isa 1 to 16 bit value which indicates the availability of each of the 1 to 16 definedPCPCHs in the PCPCH set. This information is known as the PCPCH ResourceAvailability Value (PRA).

� When Channel Assignment is Active

in this mode, the CSICH conveys two pieces of information. Firstly the PRA valueof the 1 to 57 defined PCPCHs. Secondly the Minimum Available SpreadingFactor (MASF) value indicates the MASF that can be supported by the CCPCHset. All spreading factors greater than the MASF are available.

The CSICH is a fixed rate (SF=256) physical channel used to carry CPCH statusinformation and May share the same physical channel resources as the AICH(Channelization and scrambling codes). A CSICH is always associated with a physicalchannel used for transmission of CPCH AP–AICH and uses the same channelization andscrambling codes.

The figure opposite illustrates the frame structure of the CSICH. The CSICH frameconsists of 15 consecutive access slots (AS) each of length 40 bits. Each access slotconsists of two parts, a part of duration 4096 chips with no transmission that is notformally part of the CSICH, and a Status Indicator (SI) part consisting of 8 bitsb8i,….b8i+7, where i is the access slot number. The part of the slot with no transmission isreserved for use by AICH, AP–AICH or CD/CA–ICH. The modulation used by the CSICHis the same as for the PICH. The phase reference for the CSICH is the Primary CPICH.




7–75

Structure of CPCH Status Indicator Channel (CSICH)

AS #14 AS #0 AS #1 AS #i AS #14 AS #0

b8i b8i+1

4096 chips

Transmission off

SI part

20 ms

b8i+7b8i+6

CP13_Ch7_p76




7–76

CPCH transmission

The CPCH transmission is based on DSMA–CD approach with fast acquisition indication.The UE can start transmission at the beginning of a number of well–definedtime–intervals, relative to the frame boundary of the received BCH of the current cell.The access slot timing and structure is identical to RACH.

Having determined, by monitoring the CSICH, that CPCH resources are currentlyavailable, the UE will, when requested by the MAC layer, commence the actual accessprocedure, as follows:

Access Segment

The UE starts transmission of Access Preambles on a randomly selected PCPCH fromthe set of available PCPCH Channels, using a randomly selected CPCH-AP signaturefrom the set of available signatures, at the initial power level (PCPCH) supplied by theMAC layer.

If the UE does not detect the Positive or negative acquisition indicator (AI) correspondingto the the selected signature in the downlink AP-AICH slot corresponding to the selecteduplink slot, the will re-check the PRA of the selected PCPCH, and if it is found to beunavailable, the procedure will be aborted and a failure message sent to the MAC layer.

Provided the SI still shows the selected PCPCH as available, the UE will select the nextavailable access slot on the selected PCPCH, Increase the preamble transmission powerby the specified offset ∆P, decrease the AP retransmission counter (if the APretransmission counter < 0, the UE aborts the access attempt) and repeats the APTransmission.

On receipt of a positive acknowledgement (the AP-AICH signature corresponds to the APsignature), the access segment ends and the contention resolution segmentcommences. If a negative acknowledgement is received (AP-AICH and AP signaturesdo not match), the UE aborts the access attempt.

Contention Resolution Segment

So far the PCPCH access procedure has been identical to that of the PRACH accessprocedure and thus only a very simple contention resolution procedure has beencompleted. It is therefore still possible that more than one UE has “Accepted the positiveacknowledgement”, with the potential for data collision when their data parts aresubsequently transmitted. As each PRACH message part transmission can only last amaximum of two radio frames, this is of little significance. However, on the PCPCH, theUE may be expected to transmit a significant amount of data (up to 64 radio framesduration), with data collisions severely degrading the QoS of the service. Further stepsare thus introduced to counter this problem.

In the contention resolution segment the UE randomly selects a Collision Detection (CD)signature from the CD signature set, selects a a CD access slot sub-channel from theCD sub-channel group supported in the cell and transmits a CD preamble at the samepower level as the last AP, then waits for the CD/CA-ICH.

Receipt of a positive CD-I (CD-I Signature matches CD signature), enable the UE toproceed with a Power Control preamble Transmission on the selected PCPCH. IfChannel Assignment is active, the CD/CA-ICH will also carry a Channel AssignmentIndicator (CA-I), indicating on which PCPCH to transmit, this may be the UE selectedPCPCH or an alternative selected by the network.

If at anytime no acknowledgement or a negative acknowledgement is received, the UEwill abort the procedure.




7–77

Structure of CPCH transmission

AP–AICH

APs

P0P1 P1

0 or 8 slotsPower ControlPreamble

InformationandControl Data

Power Control, Pilot and CPCHcontrol commands

Ta

p–p p–cdp cdp–pcp

p–a1 a1–cdp cdp–a2

DPCCH (DL)

PCPCH (UL)

[Example shown is for Tcpch=0]CD/CA

CD/CA–ICH

CP13_Ch7_p78




7–78

CPCH Access Preamble Acquisition Indicator Channel (AP–AICH)

The Access Preamble Acquisition Indicator channel (AP–AICH) is a fixed rate (SF=256)physical channel used to carry AP acquisition indicators (API) of CPCH. AP acquisitionindicator APIs corresponds to AP signature s transmitted by UE.

AP–AICH and AICH may use the same or different channelisation codes. The phasereference for the AP–AICH is the Primary CPICH. The Figure below illustrates thestructure of AP–AICH. The AP–AICH has a part of duration 4096 chips where the APacquisition indicator (API) is transmitted, followed by a part of duration 1024chips with notransmission that is not formally part of the AP–AICH. The part of the slot with notransmission is reserved for possible use by CSICH or possible future use by otherphysical channels.

The spreading factor (SF) used for channelisation of the AP–AICH is 256.

1024 chips

Transmission Off

AS #14 AS #0 AS #1 AS #i AS #14 AS #0

a1 a2a0 a31a30

API part =4096 chips, 32 real–valued symbols

20 msCP13_Ch7_p79




7–79

Structure of AP Acquisition Indicator Channel (AP-AICH)

1024 chips

Transmission Off

AS #14 AS #0 AS #1 AS #i AS #14 AS #0

a1 a2a0 a31a30

API part =4096 chips, 32 real–valued symbols

20 msCP13_Ch7_p80




7–80

CPCH Collision Detection/Channel Assignment Indicator Channel (CD/CA–ICH)

The Collision Detection Channel Assignment Indicator channel (CD/CA–ICH) is a fixedrate (SF=256) physical channel used to carry CD Indicator (CDI) only if the CA is notactive, or CD Indicator/CA Indicator (CDI/CAI) at the same time if the CA is active. Thestructure of CD/CA–ICH is shown below. CD/CA–ICH and AP–AICH may use the sameor different channelisation codes.

The CD/CA–ICH has a part of duration of 4096chips where the CDI/CAI is transmitted,followed by a part of duration 1024chips with no transmission that is not formally part ofthe CD/CA–ICH. The part of the slot with no transmission is reserved for possible use byCSICH or possible future use by other physical channels.

The spreading factor (SF) used for channelisation of the CD/CA–ICH is 256.

1024 chips

Transmission Off

AS #14 AS #0 AS #1 AS #i AS #14 AS #0

a1 a2a0 a31a30

CDI/CAIpart =4096 chips, 32 real–valued symbols

20 msCP13_Ch7_p81




7–81

Structure of CD/CA Indicator Channel (CD/CA-ICH)

1024 chips

Transmission Off

AS #14 AS #0 AS #1 AS #i AS #14 AS #0

a1 a2a0 a31a30

CDI/CAIpart =4096 chips, 32 real–valued symbols

20 msCP13_Ch7_p82




7–82

Power Control Preamble Segment

Having passed contention resolution, the UE may optionally commence a power controlpreamble segment.

The UE transmits a Power Control Preamble, starting at a specified time intervalsmeasured from the commencement of the CD Preamble. The initial transmission powerof the power control preamble shall be Pp–m [dB] higher than the power of the CDpreamble.

A PCPCH power control preamble is a period when both the UL PCPCH control part andthe associated DL DPCCH are transmitted prior to the start of the uplink PCPCH datapart.

The length of the power control preamble is a higher layer parameter, Lpc–preamble andcan take the value 0 slots or 8 slots. The uplink PCPCH data part shall not commencebefore the end of the power control preamble.

Message Part

The transmission of the message portion of the burst starts immediately after the powercontrol preamble. Power control in the message part is conducted using the DL DPCCH.

During the first few frames of the Data Transmission, the UE tests the value of “Start ofMessage Indicator” received from DL–DPCCH for CPCH during the first NStart_Messageframes after Power Control preamble. Start of Message Indicator is a known sequencerepeated on a frame by frame basis. The value of NStart_Message shall be provided bythe higher layers. If the UE does not detect Start of Message Indicator in the firstNStart_Message frames of DL–DPCCH for CPCH after Power Control preamble, the UEaborts the access attempt and sends a failure message to the MAC layer. Otherwise, UEcontinuously transmits the packet data.

If the UE detects loss of DPCCH DL during transmission of the power control preambleor the packet data, the UE halts CPCH UL transmission, aborts the access attempt andsends a failure message to the MAC layer.

The UE may send empty frames after the end of the packet to indicate the end oftransmission. The number of the empty frames is set by higher layers.

NOTE If the Lpc–preamble parameter indicates a zero length preamble,then there is no power control preamble and the messageportion of the burst starts cd–p–pc–p ms after the initiation ofthe CD Preamble. In this case the initial transmission power ofthe control part of the message part shall be Pp–m [dB] higherthan the power of the CD preamble.




7–83

Structure of CPCH transmission

AP–AICH

APs

P0P1 P1

0 or 8 slotsPower ControlPreamble

InformationandControl Data

Power Control, Pilot and CPCHcontrol commands

Ta

p–p p–cdp cdp–pcp

p–a1 a1–cdp cdp–a2

DPCCH (DL)

PCPCH (UL)

[Example shown is for Tcpch=0]CD/CA

CD/CA–ICH

CP13_Ch7_p84




7–84

Physical Common Packet Channel (PCPCH)

The CPCH transmission is based on DSMA–CD approach with fast acquisition indication.The UE can start transmission at the beginning of a number of well–definedtime–intervals, relative to the frame boundary of the received BCH of the current cell.The access slot timing and structure is identical to RACH.

The PCPCH access transmission consists of one or several Access Preambles [A–P] oflength 4096 chips, one Collision Detection Preamble (CD–P) of length 4096 chips, aDPCCH Power Control Preamble (PC–P) which is either 0 slots or 8 slots in length, anda message of variable length Nx10 ms.

Each message consists of up to N_Max_frames 10 ms frames. N_Max_frames is ahigher layer parameter. Each 10 ms frame is split into 15 slots, each of lengthTslot = 2560 chips. Each slot consists of two parts, a data part that carries higher layerinformation and a control part that carries Layer 1 control information. The data andcontrol parts are transmitted in parallel.

The spreading factor for the control part of the CPCH message part shall be 256.

Pilot Npilot bits

TPC NTPC bits

DataNdata bits


Tslot = 2560 chips, 10*2k bits (k=0..6)

1 radio frame: Tf = 10 ms

Data

Control FBI NFBI bits

TFCI NTFCI bits

CP13_Ch7_p85




7–85

Frame structure for uplink Data and Control PartsAssociated with PCPCH

Pilot Npilot bits

TPC NTPC bits

DataNdata bits


Tslot = 2560 chips, 10*2k bits (k=0..6)

1 radio frame: Tf = 10 ms

Data

ControlFBI

NFBI bitsTFCI

NTFCI bits

CP13_Ch7_p86




7–86

DL–DPCCH for CPCH

The downlink DPCCH for CPCH is a special case of downlink dedicated physical channelof the slot format #0. The spreading factor for the DL–DPCCH is 512. The figure belowshows the frame structure of DL–DPCCH for CPCH.

TPCNTPC bits

TFCINTFCI bits

CCCNCCC bits

PilotNpilot bits



One radio frame, Tf = 10msCP13_Ch7_p87

DL–DPCCH for CPCH consists of known pilot bits, TFCI, TPC commands and CPCHControl Commands (CCC). CPCH control commands are used to support CPCHsignalling. There are two types of CPCH control commands: Layer 1 control commandsuch as Start of Message Indicator, and higher layer control command such asEmergency Stop Command.

The CCC field above is used for the transmission of CPCH control command. On CPCHcontrol command transmission request from higher layer, a certain pattern is mappedonto CCC field, otherwise nothing is transmitted in CCC field. There is one to onemapping between the CPCH control command and the pattern. In case of EmergencyStop of CPCH transmission, [1111] pattern is mapped onto CCC field. The EmergencyStop command shall not be transmitted during the first NStart_Message frames of DLDPCCH after Power Control preamble.

Start of Message Indicator shall be transmitted during the first NStart_Message frames ofDL DPCCH after Power Control preamble. [1010] pattern is mapped onto CCC field forStart of Message Indicator. The value of NStart_Message shall be provided by higher layers.




7–87

Frame structure for downlink DPCCH for CPCH

TPCNTPC bits

TFCINTFCI bits

CCCNCCC bits

PilotNpilot bits



One radio frame, Tf = 10msCP13_Ch7_p88

Version 1 Rev 7Downlink Flow Process



7–88

Downlink Flow ProcessThe 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 everytransmission time interval. The transmission time interval is transport-channel specificfrom 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.

Version 1 Rev 7 Downlink Flow Process



7–89

Transport channel multiplexing structure for downlink

CP13_Ch7_36

PhC

H#2

PhC

H#1

Rate matching

TrBk concatenation / Code block segmentation

1st insertion of DTXindication

CRC attachment

Channel coding

Rate matching

1st interleaving

Radio frame segmentation

2nd insertion of DTXindication

Physical channel segmentation

2nd interleaving

Physical channel mapping

TrCH Multiplexing

CCTrCH

Version 1 Rev 7Uplink Flow Process



7–90

Uplink Flow ProcessThe uplink flow process is largely the same as that for the downlink, and is illustrated inthe 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 thatthe output can be segmented in data segments of equal size. Radio frame sizeequalisation is only performed in the UL (DL rate matching output block length is alwaysan integer multiple of the frame length).

Rate Matching

The rate matching operation in the uplink, is a much more dynamic process that mayvary on a frame-by-frame basis. The rate matching operation needs to take into accountthe the number of bits coming from all transport channels. When the data rate of oneservice, the dynamic rate matching adjusts the rates of the remaining service as well sothat all symbols in the radio frame will be used.

For example if with two transport channels, one has a momentary zero rate, ratematching used repetition to increase the symbol rate for the other service sufficiently sothat 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

Version 1 Rev 7 Uplink Flow Process



7–91

Uplink Flow Process

CP13_Ch7_44

TrBk concatenation / Code block segmentation

1st interleaving

CRC attachment

Channel coding

Radio Frame equalisation

Radio frame segmentation

Rate matching

TrCH Multiplexing

Rate matchingP

hCH

#1

PhC

H#2

Physical channel segmentation

2nd interleaving

Physical channel mapping

CCTrCH

Version 1 Rev 7Uplink Flow Process



7–92



8–1

Chapter 8

Radio Resource Management

Functions

Version 1 Rev 7



8–2

Version 1 Rev 7



8–3

Chapter 8Radio Resource Management Functions 8–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives 8–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Radio Resource Management 8–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UE RRC States 8–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Idle Mode 8–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connected Mode 8–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Physical Layer Measurements 8–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UE Measurements 8–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UTRA Measurements 8–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Compressed Mode 8–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Cell Selection/Re-selection 8–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Immediate Cell Evaluation 8–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell Re-selection 8–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Macro Diversity 8–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Handover 8–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handover Strategy 8–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handover Causes 8–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Soft and Softer Handover 8–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

S-RNS Relocation 8–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Power Control 8–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Site Selection Diversity Power Control (SSDT) 8–24. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Open Loop Power Control 8–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Closed Loop Power Control (Inner Loop) 8–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Closed Loop Power Control (Outer Loop) 8–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Multi-Cell Power Control 8–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Site Select Diversity Transmission 8–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Space Time Transmit Diversity (STTD) 8–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Closed Loop Mode Transmit diversity 8–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Admission Control 8–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quality of Service (QoS) 8–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Load 8–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Load Control 8–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



8–4




8–1


� Describe basic Radio Resource and Mobility Management functions.

Version 1 Rev 7Radio Resource Management



8–2

Radio Resource ManagementRadio Resource Management (RRM) is responsible for the air Interface utilisation. RRMguarantees that services will be provided according to the necessary quality that isexpected from the network. It is divided into 5 different sections:

� Cell Selection/Reselection

� Handover

� Power Control

� Admission Control

� Load Control

Version 1 Rev 7 Radio Resource Management



8–3

Radio Resource Management

CP13_Ch9_01

Handovers

Power Control

Admission Control

Load Control

Cell Selection / Reselection

Version 1 Rev 7UE RRC States



8–4

UE RRC StatesThe two basic operational modes of the UE are Idle Mode and Connected Mode. Theconnected mode can be further divided into service states, which define what kind ofphysical channels a UE is using. The diagram opposite shows the main RRC servicestates in the connected Mode. It also shows the transitions between idle mode andconnected 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) aPLMN to contact. The UE looks for a suitable cell of the chosen PLMN, chooses that cellto 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 receivesystem information messages broadcast from the cell. The UE stays in idle mode untilsuch time as it transmits a request to establish a RRC connection. In Idle mode the UE isidentified by IMSI, TMSI and P-TMSI. The UTRAN has no information of its own aboutindividual idle mode UEs and can only address, for example, all UEs in a cell or all UEsmonitoring a paging group.-

Connected Mode

Cell DCH

In Cell DCH state a dedicated physical channel is allocated to the UE and the UE isknown by its serving RNC on a cell or active set level. The UE performs measurementsand sends measurement reports according to measurement control information receivedfrom the RNC. The DSCH can also be used in this state, and Ues with certaincapabilities 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 FACHchannels can be used, both for transferring signalling messages and small amounts ofdata. In this state the UE is also capable of monitoring the broadcast channel to acquiresystem 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 CellUpdate message to the RNC so the RNC knows the UE location on a cell level. ForIdentification, a C-RNTI in the MAC PDU header separates UEs from each other in acell. When the LIE performs cell reselection it uses an U-RNTI when sending the CellUpdate message, so the UTRAN can route the message to the current serving RNC ofthe UE, even if the first RNC receiving the message is not the current SRNC. TheU-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 modeand accesses the other system according to that systems’s access procedure

Version 1 Rev 7 UE RRC States



8–5

UE RRC Connection States

CP13_Ch8_03a

Idle Mode

UTRAN Connected Mode

Cell DCH

Cell FACH

URA PCH

Cell PCH

Version 1 Rev 7UE RRC States



8–6

Cell PCH

In the Cell PCH state the UE is still known on a cell level in the SRNC, but it can bereached only via the paging channel. In this state the battery consumption is less than incell 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 theUE performs cell reselection, it moves autonomously to the Cell FACH state to executethe Cell Update procedure, after which it re-enters the Cell PCH state if no other activityis triggered during the Cell Update procedure.

If the new cell belongs to another RAN system, such as GPRS, the UE enters idle modeand 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 executeCell 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 itslocation to the SRNC. This is achieved with the URA Update procedure (the UE entersthe 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 URAidentification from the list of URAs in a cell does it need to execute the URA UpdateProcedure. This overlapping URA feature is needed to avoid pin-pong effects in possiblenetwork configuration, where geographically succeeding base stations are controlled bydifferent RNCs.

The UE leaves the connected mode and returns to idle mode when the RRC connectionis released or at RRC connection failure.

Version 1 Rev 7 UE RRC States



8–7

UE RRC Connection States

CP13_Ch8_03a

Idle Mode

UTRAN Connected Mode

Cell DCH

Cell FACH

URA PCH

Cell PCH

Version 1 Rev 7Physical Layer Measurements



8–8

Physical Layer MeasurementsThe majority of radio resource management functions rely on the exchange of Layer 1measurement reports between the UTRAN and the UE.

To initiate a specific measurement at the UE, the UTRAN transmits a ’measurementcontrol 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 modethe measurement control message is broadcast in a System Information message.When the reporting criteria is fulfilled the UE shall answer with a ’measurement reportmessage’ to the UTRAN including the measurement ID and the results.

UE Measurements

CPICH RSCPReceived Signal Code Power, the received power on one code measured on the PrimaryCPICH.

SIRSignal to Interference Ratio, defined as: (RSCP/ISCP)×(SF/2). The SIR shall bemeasured on DPCCH after RL combination.

UTRA carrier RSSIReceived Signal Strength Indicator, the wide-band received power within the relevantchannel bandwidth. Measurement shall be performed on a UTRAN downlink carrier.

GSM carrier RSSIReceived Signal Strength Indicator, the wide-band received power within the relevantchannel bandwidth. Measurement shall be performed on a GSM BCCH carrier.

CPICH Ec/NoThe received energy per chip divided by the power density in the band. The Ec/No isidentical to RSCP/RSSI. Measurement shall be performed on the Primary CPICH.

Transport channel BLEREstimation of the transport channel block error rate (BLER). The BLER estimation shallbe based on evaluating the CRC on each transport block after RL combination.

UE transmitted powerThe total UE transmitted power on one carrier.

UE Rx-Tx time differenceThe difference in time between the UE uplink DPCCH/DPDCH frame transmission andthe 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 GSMThe 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 GSMfrequency j received closest in time after the time TRxSFNi.

Version 1 Rev 7 Physical Layer Measurements



8–9

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

Version 1 Rev 7Physical Layer Measurements



8–10

UTRA Measurements

RSSI

Received Signal Strength Indicator, the wide-band received power within the UTRANuplink carrier channel bandwidth in an UTRAN access point.

SIR

Signal to Interference Ratio, is defined as: (RSCP/ISCP)×SF. Measurement shall beperformed on the DPCCH after RL combination in Node B

Transmitted carrier power

Transmitted carrier power, is the ratio between the total transmitted power and themaximum transmission power. Total transmission power is the mean power [W] on onecarrier 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 configuredmaximum power for the cell.

Transmitted code power

Transmitted code power, is the transmitted power on one channelisation code on onegiven scrambling code on one given carrier. Measurement shall be possible on theDPCCH-field of any dedicated radio link transmitted from the UTRAN access point andshall 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) ofRL-combined DPDCH data. Transport channel BER is only required to be reported forTrCHs that are channel coded.

Physical channel BER

The Physical channel BER is an estimation of the average bit error rate (BER) on theDPCCH 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 thecorresponding uplink DPCCH/DPDCH frame from the UE.

PRACH Propagation delay

Propagation delay is defined as one-way propagation delay as measured during eitherPRACH or PCPCH access.

Acknowledged PRACH preambles

The Acknowledged PRACH preambles measurement is defined as the total number ofacknowledged PRACH preambles per access frame per PRACH. This is equivalent tothe number of positive acquisition indicators transmitted per access frame per AICH

Version 1 Rev 7 Physical Layer Measurements



8–11

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

Version 1 Rev 7Compressed Mode



8–12

Compressed ModeIn addtion to monitoring Node Bs on the same carrier, the UE must be able to monitor forpotential target resources on other UMTS carriers, and in the case of dual mode UEs onalternative RAN technologies (e.g GSM/GPRS). This will involve at minimum retuning ofthe UEs receiver elements to a new radio frequency. As the transfer of informationbetween network and UE is continuous in a CDMA system, time must be “created” forthe 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 compressedinto the remaining timeslots within that radio frame.

As illustrated in the figure opposite, the instantaneous transmit power is increased in thecompressed frame in order to keep the quality (BER, FER, etc.) unaffected by thereduced processing gain. The amount of power increase depends on the transmissiontime reduction method What frames are compressed, are decided by the network. Whenin compressed mode, compressed frames can occur periodically, as illustrated, orrequested on demand. The rate and type of compressed frames is variable and dependson the environment and the measurement requirements. The maximum idle length isdefined 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 creatingtransmission 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 oneradio frame to enable the transmission of the information bits in the remaining time slotsof a compressed frame.

Compressed mode by higher layer scheduling

Compressed mode can be obtained by higher layer scheduling. Higher layers then setrestrictions 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 thecompressed radio frame is then known and a transmission gap can be generated.

Version 1 Rev 7 Compressed Mode



8–13

Compressed Mode

CP13_Ch9_04

Transmission gap available for inter–frequency measurements

One frame (10 ms)

Version 1 Rev 7Cell Selection/Re-selection



8–14

Cell Selection/Re-selectionThe goal of the cell selection procedures is to fast find a cell to camp on. To speed upthis process, at ”power up” or when returning from ”out of coverage”, the UE shall startwith the stored information from previous network contacts. If the UE is unable to findany 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 aforbidden PLMN and enter a ”limited service state”. In this state the UE regularly attemptto find a suitable cell on a valid PLMN. If a better cell is found the UE has to read thesystem information for that cell. The cell to camp on is chosen by the UE on link qualitybasis. However, the network can set cell re-selection thresholds in order to take othercriteria 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 thepower consumption in the UE. In order to achieve that, an ’Immediate Cell EvaluationProcedure’ at call set up can ensure that the UE transmits with the best cell, whilekeeping the power consumption low.

Immediate Cell Evaluation

It is important that the UE chooses the best cell (according to the chosen criteria) prior toa random access on the RACH. This is the aim of the immediate cell evaluation. Thisprocedure shall be fast and there shall not be any hysteresis requirements between thedifferent cells. However, it must be possible to rank two neighbouring cells by means ofan offset. This offset is unique between two cells. This implies that this value must be apart of the system information in the serving cell. This offset is introduced for systemtuning purposes, in order to ’move’ the ’cell border’.

Before the access on the RACH can be initiated the UE also needs to check the relevantparts of system information for making the access. The time it takes to perform animmediate cell evaluation and select a new cell is dependent on the time it takes to readthe system information. This can be optimised by the scheduling of the systeminformation at the BCCH, the better scheduling the faster cell evaluation. In particular, atcall set up, it would be important to select the optimal cell, i.e. the one where the UEuses the lowest output power.

Cell Re-selection

The cell reselection procedure is a procedure to check the best cell to camp on. Theevaluation of the measurements for this procedure is always active, in idle mode, afterthe cell selection procedure has been completed and the first cell has been chosen. Thegoal of the procedure is to always camp on a cell with good enough quality even if it isnot the optimal cell all the time.

It is also possible to have a “time to trigger” and hysteresis criteria in the cell reselectionto control the number of cell reselections. The parameters needed for the cell reselectionprocedure (e.g., the offset value and the hysteresis) are unique on a cell to neighbour cellrelation 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 readthe system information in the neighbouring cells before the cell reselection procedurefinds a neighbouring cell with better quality.

Version 1 Rev 7 Cell Selection/Re-selection



8–15

Cell Selection/Re-selection

CP13_Ch9_15QS

Camped normally

NAS registration

rejected

no suitable

cell found

Initial Cell Selection

Cell Reselection

Immediate Cell

Evaluation

Cell Selection when leaving

connected mode

Stored Information

Cell Selection

Connected Mode

1

go here whenever a new PLMN

is selected

cell information stored for the PLMN

no cell information stored for the PLMN

no suitable cell found


suitable cell found


suitable cell found

suitable cell selected

trigger

suitable cell found

return to idle mode

leave idle mode

best suitable

cell selected

Camped on Any Cell

suitable cell found

Any Cell Reselection

Immediate Cell

Evaluation

Cell Selection when leaving

connected mode

Connected Mode

(Emergency calls only)

1 USIM inserted

no acceptable cell found

no acceptable cell found

an acceptable cell found

acceptable cell selected

trigger

acceptable cell found

return to idle mode

leave idle mode

best acceptable cell selected

Any Cell Selection

1

go here when no USIM in the UE

Version 1 Rev 7Macro Diversity



8–16

Macro DiversityMacrodiversity provides an improved error correction capability through the use ofcombining/splitting at the RNC and Node B. Communications will be sent via the Iurinterface from the RNC in the D-RNS to the RNC in the S-RNS and on to the Iu to thecore network.

This function controls the duplication/ replication of information streams to receive/transmit the same information through multiple physical channels from/ towards a singlemobile terminal.

This function also controls the combining of information streams generated by a singlesource (diversity link), but conveyed via several parallel physical channels (diversitysub-links). Macrodiversity control should interact with channel coding control in order toreduce the bit error ratio when combining the different information streams. In somecases, depending on physical network configuration, there may be several entities thatcombine the different information streams, i.e. there may be combining/splitting at theS-RNC, D-RNC or Node B level. This function is located in the UTRAN.

Version 1 Rev 7 Macro Diversity



8–17

Macro Diversity

CP13_Ch9_04

D–RNS

UTRANlu

RNC RNC RNC

S–RNS

Version 1 Rev 7Handover



8–18

Handover

Handover Strategy

The handover strategy employed by the network for radio link control determines thehandover decision that will be made based on the measurement results reported by theUE/RNC and various parameters set for each cell. Network directed handover might alsooccur for reasons other than radio link control, e.g. to control traffic distribution betweencells. The network operator will determine the exact handover strategies. Possible typesof 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 ahandover 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

Version 1 Rev 7 Handover



8–19

Handover

Handover Strategy Handover Causes

Handover 3G -3G;

FDD soft/softer handover;

Uplink quality;

Uplink signal measurements;FDD soft/softer handover;

FDD inter-frequency hard handover;

Uplink signal measurements;

Downlink quality;

FDD/TDD Handover;

TDD/FDD Handover;

Downlink signal measurements;

Distance;TDD/FDD Handover

TDD/TDD Handover;

Handover 3G 2G (e g Handover to GSM);

Distance

Change of service;

Better cell;Handover 3G - 2G (e.g. Handover to GSM);

Handover 2G - 3G (e.g. Handover fromGSM)

Better cell;

O&M intervention;( gGSM). Directed retry;

Traffic;Traffic;

Pre-emption

Version 1 Rev 7Soft and Softer Handover



8–20

Soft and Softer HandoverSoft Handover is a handover in which the mobile station starts communication with a newNode-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 theprovision of macro-diversity transmission. This intrinsic characteristic terminology tendsto identify Soft Handover with macro-diversity even if they are two different concepts. Asa result of this definition there are areas of the UE operation in which the UE isconnected to a number of Node-Bs. With reference to Soft Handover, the ”Active Set” isdefined as the set of Node-Bs the UE is simultaneously connected to (i.e., the UTRAcells 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 functionevaluates if any Node-B should be added to (Radio Link Addition), removed from (RadioLink Removal), or replaced in (Combined Radio Link Addition and Removal) the ActiveSet. This procedure is known as the ”Active Set Update” procedure.

Version 1 Rev 7 Soft and Softer Handover



8–21

Soft Handover Procedure

CP13_Ch9_06

Eb/(No + lo)

Time

Tadd

Tdrop

Cell B Cell A

Add ADrop B Relative

Threshold

AbsoluteThreshold

Version 1 Rev 7S-RNS Relocation



8–22

S-RNS RelocationThis functionality allows moving the Serving RNS functionality from one RNC to anotherRNC, e.g. closer to where the UE has moved during the communication. The ServingRNS Relocation procedure may be applied when active cell management functionalityhas created a suitable situation for it. Both UTRAN and CN are involved.

Version 1 Rev 7 S-RNS Relocation



8–23

S-RNS Relocation

CP13_Ch9_07

RNC RNC

lu lu

D–RNS

S–RNS

S–RNSStep 1

Step 2

RNClur lur

Version 1 Rev 7Power Control



8–24

Power ControlPower control controls the level of the transmitted power in order to minimise interferenceand 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 ErrorRate 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 parametersare 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.

Version 1 Rev 7 Power Control



8–25

Power Control

CP13_Ch9_08


Closed Loop Power Control (Inner Loop)

Closed Loop Power Control (Outer Loop)

Site Selection Diversity Power Control

Version 1 Rev 7Open Loop Power Control



8–26

Open Loop Power ControlIn UTRAN, open loop power control is applied only immediately prior to initiating atransmission on the PRACH.

The UE determines an estimation of the downlink pathloss between the base station andthe UE by measuring the UTRA carrier received signal strength at the mobile. Throughthe medium of the System Information messages on the P-CCPCH, the UE will alsohave 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 requiredto achieve the access requirements of the cell it wishes to connect to. The UE will nowsend its first RACH Pre-amble at this calculated value. If no positive or negativeacquisition indicator is detected, the UE will increase its power by the requiredpower-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 retriesvalue is exceeded.

If a positive Ack is received, the UE will again adjust its output power, according to anoffset value notified by the cell, and transmit the RACH message part. On receipt of theRACH Message part, the UTRAN can accurately calculate the uplink path loss andinitiate the use of closed loop power control.

Version 1 Rev 7 Open Loop Power Control



8–27


CP13_Ch9_17

UE monitors Common Pilotand Broadcast information,and calculates DL path Loss

Only used prior to initial transmission on PRACH

Using DL path loss as”perceived” UL pathloss, UE calculates TXpower O/P requiredaccess network

Version 1 Rev 7Closed Loop Power Control (Inner Loop)



8–28

Closed Loop Power Control (Inner Loop)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 all UEs in a cell transmit onthe 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 thereceived uplink signal-to-interference ratio (SIR) at a given SIR target (SIRtarget). Theserving 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 commandsonce per slot, using the TPC symbols in each time slot, according to the following rule: ifSIRest > SIRtarget then the TPC command to transmit is ”0”, while if SIRest < SIRtargetthen the TPC command to transmit is ”1”. The UE uses this information to deriveTPC_cmd.

After deriving of the TPC_cmd, the UE shall adjust the transmit power of the uplink with astep ∆ (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-specifichigher-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 thevalue 1 dB and if ”TPC-StepSize” has the value ”dB2”, then ∆TPC shall take the value2 dB.

A similar process is used in the downlink, to control the relative power weighting to beapplied to each downlink dedicated channel.

Version 1 Rev 7 Closed Loop Power Control (Inner Loop)



8–29

Closed Loop Power Control (Inner Loop)

CP13_Ch9_18

Node B Monitors UL SignalInterference Ratio (SIR)And compares againstTarget SIR level

Inner Loop Power Control command rate is 1500 Hz

Node B sends Transmit Power Control (TPC)information to UE, adjusting UEtransmit power output in an attempt toacheive target SIR

Version 1 Rev 7Closed Loop Power Control (Outer Loop)



8–30

Closed Loop Power Control (Outer Loop)While Closed loop power control (Inner Loop) is used to maintain a target SIR, Outerloop power control adjusts the SIR target in the base station according to the needs ofthe individual radio link and aims at a constant quality, usually defined as a certain targetbit error rate (BER) or frame error rate (FER). The reason for adjusting the target is tocompensate 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 dataframe 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 willin 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 functionshould be performed after a possible soft handover combining has been performed.

Version 1 Rev 7 Closed Loop Power Control (Outer Loop)



8–31

Closed Loop Power Control (Outer Loop)

CP13_Ch9_19

SRNC target qualityValue sent to Node Bas New Target SIRvalue for Inner LoopPower Control

Outer Loop Power Controlcommand rate is 10–100 Hz

Node B receives UL dedicatedchannel data, which is passedserving RNC along with a Qualityestimate of the Transport Channel

SRNC

SRNC Checks FERand adjusts targetquality value forthe UL

Version 1 Rev 7Multi-Cell Power Control



8–32

Multi-Cell Power ControlAs we have seen the UE has the ability to receive and process the transmitted downlinkfrom several Node Bs simultaneously. By the same token several Node Bs will besending conflicting power control commands to the one UE. In this situation the UE willalways ramp its power down unless all received power control commands require it topower up.

Version 1 Rev 7 Multi-Cell Power Control



8–33

Multi-Cell Power Control

CP13_Ch9_09

Node B

Node B

Node B

Node B

Increase

Increase Increase

Decrease

Mobile Decreases Tx Power

Mobile Increases Tx Power

Version 1 Rev 7Site Select Diversity Transmission



8–34

Site Select Diversity TransmissionSite Selection Diversity Transmit Power Control (SSDT) is a form of power control for thedownlink that can be applied while a UE is in soft handover (SHO). This section explainshow SSDT works, and provides some examples when SSDT should be used. In SHO, aUE has DL connections to more than one cell. Thus, one UE contributes to the DLinterference in several cells. SSDT is a power control method that reduces the DLinterference generated while the UE is in SHO. The principle of SSDT is that the best cellof the active set is dynamically chosen as the only transmitting site, and the other cellsinvolved turn down their DPDCHs. The DPCCH is transmitted as normally.

Each cell is given a temporary identification number. The UE measures the pilot power ofthe PCCPCHs, and chooses the best one as its ’primary’ cell. The temporary id of thisprimary cell (the ’primary id’) is transmitted on the UL DPCCH to all Node Bs of the activeset. A cell that has been selected as primary station transmits its dedicated channels withthe power necessary to reach the desired SIR target, whereas all other cells switch offtheir downlink DPDCH transmission. The ’primary id’ is updated by the UE at a frequencyof 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 maintainsynchronisation, the ’secondary’ cells continue to transmit pilot information on theDPCCH.

The prerequisite for using SSDT during an RRC connection or during a part of an RRCconnection is that all Node-Bs involved support SSDT. SSDT is controlled by L3procedures. The control involves assignment of temporary IDs, setting an SSDT modeand switching SSDT on or off. The control information itself (temporary IDs) terminates inthe L1 of Node B and UE respectively.

Version 1 Rev 7 Site Select Diversity Transmission



8–35

Site Select Diversity Transmission

CP13_Ch9_10

Version 1 Rev 7Space Time Transmit Diversity (STTD)



8–36

Space Time Transmit Diversity (STTD)The open loop Downlink Transmit Diversity employs a space time block coding basedtransmit diversity. The STTD encoding is optional in UTRAN. STTD support is thusmandatory at the UE. A block diagram of the transmitter and a generic STTD encoderare shown in the slide opposite. Channel coding, rate matching and interleaving is doneas 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:

CP13_Ch9_21

b0 b1 b2 b3

–b2 b3 b0 –b1

b0 b1 b2 b3

Version 1 Rev 7 Space Time Transmit Diversity (STTD)



8–37

Space Time Transmit Diversity (STTD)

CP13_Ch6_31

InterleaverRate Matching

Channel Encoder

STTD Encoder

M U X

M U X

Diversity Pilot

PilotTPC

TFI

Data

Ant 1

Ant 2

Ant 1

Ant 2

Channelizaton code and long scrambling code C,

spreading length = M

Tx Antenna 1

Tx Antenna 2

QPSK symbols

Version 1 Rev 7Closed Loop Mode Transmit diversity



8–38

Closed Loop Mode Transmit diversityThe general transmitter structure to support closed loop mode transmit diversity forDPCH transmission is shown opposite. Channel coding, interleaving and spreading aredone as in non-diversity mode. The spread complex valued signal is fed to both TXantenna branches, and weighted with antenna specific weight factors w1 and w2. Theweight factors are complex valued signals (i.e., wi = ai + jbi ), in general.

The weight factors (actually the corresponding phase adjustments in closed loop mode 1and phase/amplitude adjustments in closed loop mode 2) are determined by the UE, andsignalled to the UTRAN access point (=cell transceiver) using the D-bits of the FBI fieldof uplink DPCCH.

For the closed loop mode 1 different (orthogonal) dedicated pilot symbols in the DPCCHare sent on the 2 different antennas. For closed loop mode 2 the same dedicated pilotsymbols in the DPCCH are sent on both antennas.

Version 1 Rev 7 Closed Loop Mode Transmit diversity



8–39

Closed Loop Mode Transmit diversity

CP13_Ch9_20

∑

Determine FBI messagefrom Uplink DPCCH

CPICH2

x

x

Ant1

W2

x

∑

Spread/scramble

CPICH1W1 Tx

Ant2

Rx

Tx

Weight Generation

W2W1

DPCCH

DPCCHDPCCH

Rx

Version 1 Rev 7Admission Control



8–40

Admission ControlIn CDMA networks the ’soft capacity’ concept applies. Each new call that is establishedwill increase the interference level in the network, this will effect quality of all otherongoing calls in the network. Therefore it is very important to control the access to thenetwork 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 theUE. This is an example of the services required.

Service Domain TransportChannel

Type of Service CACPerformed

Voice CS DCH Premium Yes

Streaming PS DCH Premium Yes

Web

Browsing

PS DSCH Assured Service Yes

E-mail PS DSCH Best Effort No

System Load

Admission Control is performed according to the current system load and the requiredservice. The call should be blocked if none of the suitable cells can efficiently provide theservice required by the UE at call set up (i.e., if, considering the current load of thesuitable cells, the required service is likely to increase the interference level to anunacceptable value). This would ensure that the UE avoids wasting power affecting thequality of other communications. In this case, the network can initiate a re-negotiation ofresources 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 QoSparameters.

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-layersare configured accordingly.

Version 1 Rev 7 Admission Control



8–41

Admission Control

RRM Entity

2. Mapping Qos ParameterType of ServiceCAC

3. Resource Allocation

CP13_Ch9_11

1. RANAPMessage

4. RANAPMessage

RANAP

RRC

RLC

MAC

4. CPHY–RLSetup–REQ

4. CMACConnection

4. CRLC Config

Version 1 Rev 7Load Control



8–42

Load ControlThis Management task ensures that the system will never be overloaded and remainsstable. A well planned system will seldom overload, however if such a condition doesoccur 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

Version 1 Rev 7 Load Control



8–43

Load Control

CP13_Ch9_12

Downlink fast load control

Uplink fast load control

Handover to another W–CDMA carrier

Handover to GSM

Reduce packet data throughput

Decrease bit rate of real time users

Drop calls in a controlled fashion

Version 1 Rev 7Load Control



8–44



A9–1

Chapter 9

Annexe A

Version 1 Rev 7



A9–2

Version 1 Rev 7



A9–3

Chapter 9Annexe A A9–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectives A9–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Paging for a UE in Idle Mode A9–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Paging for the UE in RRC Connected Mode A9–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RRC Connection Establishment A9–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RRC DCH Release A9–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RA Update A9–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SRNC Relocation A9–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Version 1 Rev 7



A9–4




A9–1


� Describe selected UMTS Signalling Flow procedures.

Version 1 Rev 7Paging for a UE in Idle Mode



A9–2

Paging for a UE in Idle ModeThis example shows how paging is performed for a UE in RRC Idle Mode. The UE maybe paged for a CS or PS service. Since the UE is in RRC Idle Mode, the location is onlyknown 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 andRNC2) via a RANAP message called the Paging message .

Parameters Sent:

CN Domain Indicator, Permanent NAS UE Identity, Temporary UE Identity, PagingCause.

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 forNAS signalling connection establishment follows. NAS message transfer can nowbe performed.

This procedure described for RRC idle mode, applies also to the RRC connectedmode in the case of CELL_PCH and URA_PCH states.

Version 1 Rev 7 Paging for a UE in Idle Mode



A9–3

Paging for UE in Idle Mode

CP13_Ch10_01

UE Node B 1.1

Node B 2.1

RNC 1

RNC 2 CN

RANAP

RANAP

RANAP

RANAP

2.PCCH: Paging Type 1

3.PCCH: Paging Type 1

1. Paging

1. Paging

Version 1 Rev 7Paging for the UE in RRC Connected Mode



A9–4

Paging for the UE in RRC Connected ModeThis will occur in case the position of the UE is already known; a mobility managementsession 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 ConnectedMode (CELL_DCH and CELL_FACH states) when the UTRAN co-ordinates the pagingrequest 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, TemporaryUE Identity, Paging Cause.

2. SRNC sends RRC message Paging Type 2 .

Version 1 Rev 7 Paging for the UE in RRC Connected Mode



A9–5

Paging for UE in RRC Connected Mode

CP13_Ch10_02

CN

RRC

RANAP

RRC

RANAP1. Paging

UE Serving RNC

2. DCCH Paging Type 2

Version 1 Rev 7RRC Connection Establishment



A9–6

RRC Connection EstablishmentThe following example shows establishment of a RRC connection in dedicated transportchannel (DCH) state.

The following sequence are identified:

1. The UE initiates set-up of an RRC connection by sending RRC message ConnectionRequest 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 radioresources for the RRC connection. When a DCH is to be set-up, NBAP message RadioLink 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 (TDDonly), Power control information.

3. Node B allocates resources, starts PHY reception, and responses with NBAPmessage, Radio Link Setup Response . Parameters used: Signalling link termination,Transport layer addressing information (AAL2 address, AAL2 Binding Identity) for the IubData Transport Bearer.

4. SRNC initiates set-up of Iub Data Transport bearer using ALCAP protocol. Thisrequest contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to theDCH. 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 TransportBearer by means of exchange of the appropriate DCH Frame Protocol frames DownlinkSynchronisation 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 FormatSet, 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.

Version 1 Rev 7 RRC Connection Establishment



A9–7

RRC Connection Establishment

CP13_Ch10_03

RRC

UEServing

RNCNode B

Serving RNS

NBAP

DCH

RRC

NBAP

NBAP NBAP

DCH

DCH DCH

RRC

RRC

RRC

RRC

Allocate RNTI Select L1 and L2

parameters

Start Rx

4. ALCAP Iub Data Transport Bearer Setup

Start Rx

1. CCCH: RRC Connection Request

2. Radio Link Setup Request

3. Radio Link Setup Response

5. Downlink Synchronisation

6. Uplink Synchronisation

7. CCCH: RRC Connection Setup

8. DCCH: RRC Connection Setup Complete

Version 1 Rev 7RRC DCH Release



A9–8

RRC DCH ReleaseThis example shows RRC Connection release of a dedicated channel, in the case ofmacrodiversity on two Nodes-Bs; the first one connected to the Serving RNC, the secondone to the Drift RNC.

1. The CN initiates the release of a dedicated Channel by sending the message IuRelease Command to the SRNC. Parameters used: Cause.

2. The SRNC confirms the release by sending an Iu Release Complete message tothe 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 RRCconnection release.

Parameters: Cause.

5. Message RRC Connection Release Complete from UE to SRNC to confirm theRRC connection release.

6. The SRNC initiates the release of the link by sending the Radio Link Deletion tothe Node B (SRNC).

7. The SRNC initiates the release of the link by sending the Radio Link Deletion tothe Drift RNC.

8. The Drift RNC initiates the release of the link by sending the Radio Link Deletionto the Node B (Drift RNC).

9. The Node B (SRNC) confirms the release of the link by sending the Radio LinkDeletion Response to the SRNC.

10. The Node B (Drift RNC) confirms the release of the link by sending the Radio LinkDeletion Response to the Drift RNC.

11. The Drift RNC confirms the release of the link by sending the Radio Link DeletionResponse to the SRNC.

12. The Node B (SRNC) initiates release of Iub Data Transport bearer using ALCAPprotocol.

13. The Node B (Drift RNC) initiates release of Iub Data Transport bearer usingALCAP protocol.

14. The Drift RNC initiates release of Iur Data Transport bearer using ALCAP protocol.

Version 1 Rev 7 RRC DCH Release



A9–9

RRC DCH Release

CP13_Ch10_04

RRC

NBAP

RRC

NBAP

NBAP

NBAP

RNSAP

RRC

RRC

NBAP

NBAP

NBAP

NBAP

RANAP

Node BServing RNS

UE Node BDrift RNS

Drift RNC

Serving RNC

CN

RANAP RANAP

RANAP

RNSAPRNSAP

RNSAP

1. Iu Release

2. Iu Release

3. ALCAP Iu Bearer Release

4. RRC connection Release

5. RRC Connection Release Complete

6. Radio Link Deletion



9. Radio Link Deletion Response

10. Radio Link Deletion Response

11. Radio Link

12. ALCAP Iub Bearer Release

13. ALCAP Iub Bearer Release ALCAP Iur Bearer Release

Complete

Complete

DeletionResponse

Version 1 Rev 7RA Update



A9–10

RA UpdateThis example shows location registration when changing Routing Area including changeof 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 RRCconnection. This RRC connection can have been established beforehand due to ongoinginter-working between UE and 3G-MSC/VLR or be established only for this locationregistration procedure towards the 3G-SGSN. For each indicated MM message sent inthis 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 initialmessage Routing Area Update Request (old P-TMSI, old RAI, etc.) to the new3G-SGSN. The old P-TMSI and the old RAI are assigned data in UMTS. TheSRNS transfers the message to the 3G-SGSN. The sending of this message to3G-SGSN will also imply establishment of a signalling connection between SRNSand 3G-SGSN for the concerned UE. The UTRAN shall add the RAC and the LACof the cell where the message was received before passing the message to theSGSN.

2. The new 3G-SGSN send an SGSN Context Request (old P-TMSI, old RAI) to theold 3G-SGSN to get the IMSI for the UE. (The old RAI received from UE is used toderive the old 3G-SGSN identity/address.) The old 3G-SGSN responds withSGSN Context Response (e.g. IMSI, PDP context information and Authenticationtriplets).

3. Security functions may be executed.

4. The new 3G-SGSN informs the HLR of the change of 3G-SGSN by sendingUpdate 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 CancelLocation Ack.

6. The HLR sends Insert Subscriber Data (IMSI, subscription data) to the new3G-SGSN. The new 3G-SGSN acknowledges with Insert Subscriber Data Ack.

7. The HLR acknowledges the Update GPRS Location by sending Update GPRSLocation 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 ifsubscription checking fails, then the new 3G-SGSN rejects the Routing AreaUpdate Request with an appropriate cause. If all checks are successful, then thenew 3G-SGSN responds to the UE with Routing Area Update Accept (newP-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 releasethe signalling connection towards the SRNS for the concerned UE. The SRNS willthen release the RRC connection if there is no signalling connection between3G-MSC/VLR and SRNS for the UE.

Version 1 Rev 7 RA Update



A9–11

RA Update

CP13_Ch10_05

Old 3G_SGSN

UE HLRSRNSNew

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 Location5. Cancel Location

6. Insert Subscriber Data

6. Insert Subscriber Data Ack

7. Update GPRS Location Ack8. RA upd Accept (new RAI, new P–TMSI

9. RA update complete

10. Release

10. RRC connection release

5. Cancel Location Ack

Version 1 Rev 7SRNC Relocation



A9–12

SRNC RelocationThis example shows SRNS relocation when the source RNC and target RNC areconnected 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 RNCfunctionality is to be relocated. The source SRNC sends SRNC Relocationrequired messages to the MSC. This message includes parameters such as targetRNC identifier and an information field that shall be passed transparently to thetarget RNC.

2. Upon reception of SRNC Relocation required message the Anchor MSC preparesitself for the switch and determines from the received information that the SRNCrelocation will (in this case) involve another MSC. The Anchor MSC will then senda Prepare SRNC Relocation Request to the applicable non-anchor MSC, includingthe information received from the Source RNC.

3. The non-anchor MSC will send a SRNC Relocation Request message to the targetRNC. This message includes information for building up the SRNC context,transparently sent from Source RNC (UE ID, No of connected CN nodes, UEcapability information), and directives for setting up Iu user plane transportbearers. When Iu user plane transport bearers have been established, and targetRNC has completed its preparation phase, SRNC Relocation Proceeding 1message is sent to the non-anchor MSC.

4. The Prepare SRNC Relocation Response that is sent from non-anchor MSC toAnchor MSC will contain the “SRNC Relocation Proceeding 1 received” commandfrom the target RNC.

5. When the “SRNC Relocation Proceeding 1” command has been received in theAnchor MSC, the user plane transport bearers has been allocated between thetarget 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 CNside for the SRNC relocation by sending the SRNC relocation proceeding 2message 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 thetarget RNC. The target RNC executes switch for all bearers at the earliest suitabletime 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 isincluded by the non-anchor MSC in the “Complete SRNC relocation message” thatis sent to the anchor MSC. Upon reception of this message, the Anchor-MSCswitches from the old Iu transport bearers to the new ones.

8. After a successful switch at the Anchor MSC, a release indication is sent towardsthe Source RNC. This will imply release of all UTRAN resources that were relatedto this UE.

9. When the target RNC is acting as SRNC, it will send New MM System Informationto the UE indicating e.g. relevant Routing Area and Location Area. Additional RRCinformation may then also be sent to the UE, e.g. new RNTI identity.

Version 1 Rev 7 SRNC Relocation



A9–13

SRNC Relocation

CP13_Ch10_06

UE Source RNC

Target RNC

Anchor MSC HLR Non–anchor

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

6. SRNC Reloc Commit

7. SRNC Reloc Complete

7. Complete SRNC Reloc

8. Release

9. New MM System Info

10. Routing Area Update

(a)

(b)

Version 1 Rev 7SRNC Relocation



A9–14

10TH JULY 95 Manual Title Goes Here


G–1

Glossary of technical terms andabbreviations

10TH JULY 95Manual Title Goes Here


G–2

Numbers



G–3

Numbers# Number.

2 Mbit/s link 4-wire As used in this manual set, the term applies to the EuropeanE1 digital line or link which can carry 30 A-law PCM channelsor 120 16 kbit/s channels.

3GPP 3rd Generation Partnership Program.

A



G–4

AAAL 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.

B



G–5

BBCH Broadcast Channel. (Transport Channel)

The BCH is a downlink transport channel that is used tobroadcast system and cell specific information. The BCH isalways transmitted over the entire cell.

BER Bit Error Rate.

BLER Block Erasure Rate.

BS Billing System.

BTS Base Transmitter Station.

C



G–6

CCAC Connection Admission Control.

To decide whether a new ATM or AAL2 connection can beaccepted, meeting its QoS requirements and still maintainingthe QoS of already established connections and if so whatresources 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 iscontinuously transmitted over the entire cell. Primary CCPCHis a fixed rate (32 kbit/s) downlink physical

The Secondary CCPCH is a constant rate (which may differfor 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 secondaryCCPCHs. A secondary CCPCH is only transmitted whenthere is data available, and may be transmitted in a narrowlobe (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 doesnot break up the signal into time slots or frequency bands.The signals are decoded by using knowledge of the user’scode. CDMA is a form of spread-spectrum, a family of digitalcommunication techniques. The basic principle ofspread-spectrum is the use of noise-like carrier waves, andbandwidths much wider than that required for simplepoint-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. CellIDCell 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.

C



G–7

Control-plane and user-plane functions that pertain to themanagement of the radio resources for a particular Node B orcell/sector within the Node B.

CS-Service Domain Circuit Switched-Service Domain.

D



G–8

DDAC 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 isused to carry user or control information between the networkand a mobile station. The DCH is transmitted over the entirecell or over only a part of the cell using lobe-formingantennas.

DL Downlink.

DPC Digital Processing and Control.

DPCCH Dedicated Physical Control Channel. (Physical Channel)

The DPCCH is an uplink physical channel that is used tocarry control information of known pilot bits to supportchannel estimation for coherent detection, transmit powercontrol (TPC) commands, and an optional transport formatindicator (TFI). The TFI informs the receiver about theinstantaneous parameters of the different transport channelsmultiplexed 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 usedto 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 tocarry dedicated data generated for the DCH. There may bezero, 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 aparticular user’s radio access signalling and bearerconnection to the Iur interface.

DSCH Downlink Shared Channel.

The DSCH is a downlink transport channel shared by severalUEs carrying dedicated control or traffic data.

DSI De-serialising Interface.

DSP Digital Signal Processor.

DTCH Dedicated Transport Channel.

DTX Discontinuous Transmission.

E



G–9

EE1 2 Mbit/s digital transmission link (32 x 64 kbit/s timeslots).

EEPROM Electrically Erasable Programmable ROM.

F



G–10

FFACH Forward Access Channel. (Transport Channel)

The FACH is a downlink transport channel that is used tocarry control information to a mobile station when the systemknows the location cell of the UE. The FACH may also carryshort user packets. The FACH is transmitted over the entirecell or over only a part of the cell using lobe-formingantennas.

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.

G



G–11

GGa 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 thatare not specific to any particular call (user connection) or anyparticular Node B.

Represents the RNC functions that are not covered by any ofthe other three types (See, CRNC, DRNC and SRNC). Thisalso relates to global functions such as transit or ATMfunctions.

GSM Global System for Mobile Communications.

GSNu GPRS Support Node, specific to UMTS.

High performance broadband packet-switching node.

GUI Graphical User Interface.

H



G–12

HHard Handover A category of handover procedures where all the old radio

links in the UE are abandoned before the new radio links areactivated.

HLR Home Location Register.

I



G–13

IID 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 Networkdomains.

Iub Interface between Node B and RNC network elements.

The information exchange is for the purpose of passingsignalling and data information, and supporting logical O&Mprocedures.

Iu-BC Interface between the SRNC and the CBC for the BroadcastDomain of the Core Network.

Iu-CS Interface between the SRNC and the MSCu for the CircuitSwitched-Service Domain of the Core Network.

Iu-PS Interface between the SRNC and the SGSNu for the PacketSwitched-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.

K



G–14

K

L



G–15

LLA Location Area.

LLMF Low Level Maintenance Functions.

LMT Local Maintenance Terminal.

LPA Linear Power Amplifier.

LPF Low Pass Filter.

LVDS Low Voltage Digital Signal.

M



G–16

MMAC Media Access Control.

MSCu Mobile Switching Centre, specific to UMTS.

MIB Management Information Base.

MMI Man Machine Interface.

MPROC Master Processor.

N



G–17

NNBAP 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 radiotransmission/reception in one or more cells to/from the UE.

Node B ID identifies the Node B within UTRAN (used formeasurement reporting for instance).

NPC Network Parameter Control.

NRT Non Real Time.

O



G–18

OO&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 controllingOMC-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.

P



G–19

PPACE Payload Active CP2 Emulator.

PCCPCH Primary Common Control Physical Channel.

The PCCPCH is a downlink physical channel that carries theBCH.

PCH Paging Channel. (Transport Channel)

The PCH is a downlink transport channel that is used to carrycontrol information to a mobile station when the system doesnot know the location cell of the UE. The PCH is alwaystransmitted 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 tocarry the RACH.

PS-Service Domain Package Switched-Service Domain.

PSM Power Supply Module.

PSTN Public Switched Telephone Network.

PSU Power Supply Unit.

Q



G–20

QQoS Quality of Service.

QPSK Quadrature Phase Shift Keying.

R



G–21

RRA 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 carrycontrol information from a mobile station. The RACH mayalso carry short user packets. The RACH is always receivedfrom 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 radioresources.

RNL Radio Network Layer.

RNS Radio Network System.

The RNS is responsible for the resources andtransmission/reception in a set of cells. The RNS is furtherbroken down into RNC and Node B network elements.

RNSAP Radio Network Subsystem Application Part.

Radio network signalling over the Iur between the SRNC andDRNC.

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.

S



G–22

SSAAL Signalling AAL.

SAR Segmentation and Re-assembly.

SCCPCH Secondary Common Control Physical Channel.

The SCCPCH is a downlink physical channel that carries theFACH and PCH to support a mobile phone call.

SCH Synchronisation Channel. (Physical Channel)

The SCH is a downlink signal used for cell search andconsists of two sub channels.

The Primary SCH consists of an unmodulated orthogonalcode (of length 256 chips) transmitted once every slot and isthe same for every Node B in the system.

The Secondary SCH consists of repeatedly transmitting asequence of 16 unmodulated orthogonal codes (of length 256chips) in parallel with the primary SCH. The sequence on thesecondary SCH indicates to which of the 32 different codegroups the Node B downlink scrambling code belongs. 32sequences are used to encode the 32 different code groups,each containing 16 scrambling codes to uniquely determineboth 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 linksare added and abandoned in such a manner that the UEalways keeps at least one radio link to the UTRAN. Thistypically involves multiple Node Bs.

Softer Handover Is a type of handover that involves one or more cells of thesame Node B.

SPROC System Processor.

Is a MPC750 processor that is responsible for executing all ofthe site resident software.

SRNC Serving Radio Network Controller.

Control-plane functions that pertain to the management of aparticular user’s radio access signalling and bearerconnection to the Iu-CS interface.

User-plane functions that pertain to the management of thebearer data stream for a particular user’s radio accesssignalling and bearer connection to the Iu-PS interface.

T



G–23

TTFCI 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.

U



G–24

UUBR 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 elementand UE.

The information exchange is for the purpose of passingsignalling and data information.

V



G–25

VVCAT Vector Capture and Analysis Tool.

VC Virtual Channel.

VCC Virtual Channel Connection.

VP Virtual Path.

VPC Virtual Path Connection.

W



G–26

WWAN Wide Area Network.

WCDMA Wideband CDMA.

WDM Wideband Digital Modem.

X



G–27

X

Y



G–28

Y

Z



G–29

Z

Z



G–30

73723115 cp13 motorola umts

Documents

fibre optic

wforeignplmnliandhcpserverrnc

dismantling

safety issue

inappstnvoiceotherplmngsnsgatewayslocationprepaidmexewapfeature

violates safety

linear power

visitor location