v01 0108 en

Network, About
Wireless Service Provider Solutions
About the UMTS Network

UMT/DCL/DD/0001 01.08/EN Preliminary October 2001 411--8111--101
< 01 >
: About the UMTS Network

Document number: UMT/DCL/DD/0001 411--8111--101 Document status: Preliminary Document issue: 01.08/EN Product release: UMTS01 Date: October 2001
Wireless Service Provider Solutions
Copyright ! 2001 Nortel Networks, All Rights Reserved Printed in France

NORTEL NETWORKS CONFIDENTIAL: The information contained in this document is the property of Nortel Networks. Except as specifically authorized in writing by Nortel Networks, the holder of this document shall keep the information contained herein confidential and shall protect same in whole or in part from disclosure and dissemination to third parties and use for evaluation, operation and maintenance purposes only. You may not reproduce, represent, or download through any means, the information contained herein in any way or in any form without prior written consent of Nortel Networks. The following are trademarks of Nortel Networks: *NORTEL NETWORKS, the NORTEL NETWORKS corporate logo, the NORTEL Globemark, UNIFIED NETWORKS, e--mobility, Passport, Shasta, Contivity, Preside. All other brand and product names are trademarks or registred trademarks of their respective holders.
Nortel Networks Confidential
Publication History
iii
PUBLICATION HISTORY
System release: UMTS01
October 2001 Issue 01.08/EN Preliminary Update August 2001 Issue 01.07/EN Draft Updated items Chapter 1: General UMTS description Chapter 6: Core Network Chapter 8: OAM July 2001 Issue 01.06/EN Preliminary Update after review (Minutes UMT/DCL/GES/0011). Updated items Chapter 2: Services 2.3 Main UMTS Mechanisms: removed. Chapter 6: Core Network 6.4.2 (GGSN), 6.4.3 (MSC), and 6.4.4 (HLR) updated. Chapter 8: OA&M Completely rewritten. June 2001 Issue 01.05/EN Draft Updated items Chapter 6: Core Network 6.4.1 Wireless Gateway
iv
Publication History
Chapter 8: OA&M OA&M hardware platform (chapter 8. paragraph 3) moved to section 8. paragraph 9. New items Chapter 9: Regulatory Information May 2001 Issue 01.04/EN Preliminary Updated items Chapter 1: UMTS general description 1.2.2 Core network 1.6.3 Physical overview (Figure 1-7) 1.7 UMTS traffic classes : moved to chapter 2 (services) Chapter 4: iRNC 4.2.4 Network management interface 4.3.2 Mechanical structure 4.3.3.3 Electrical characteristics 4.4 iRNC configurations Chapter 5: iBTS 5.1.1 iBTS features and functions 5.2 iBTS hardware structure (complete update) 5.3 iBTS configuration rules Chapter 6: Core Network 6.1 Core network architecture 6.4.1.1 Wireless gateway introduction Chapter 8: OA&M Complete update. New items Chapter 1: UMTS general description 1.4 UMTS architecture (core network) 1.5 OA&M Chapter 4: iRNC 4.5 Network management
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
Publication History
January 2001 Issue 01.03/EN Preliminary Update after review (Minutes UMT/DCL/GES/0001). Updated items Remove the revision bars present in the document. The release number present in the bottom page (UMTS V01) should be identical to the release referenced in the manual (UMTS01). About this document Reference a UMTS glossary. The UMTS glossary will be available as a specific NTP: UMT/DCL/DD/0004. In the applicability, replace applies to by implements. Chapter 4: iRNC Update figure 4-1 (iRNC cabinet: physical architecture). Update figures 4-2 (iRNC presentation: front face) and 4-3 (iRNC presentation: rear face) . Chapter 6: Core network 6.4: Core network components Description of the following components:
" Wireless gateway " GGSN " MSC " HLR " SIG
Remove 6.6: Billing. Chapter 8: OAM Update from the following documents:
" Notice of Decision (October 2000) " UMTS OAM Box List (UMT/OAM/DD/004 01.03/EN) " Preside Wireless Internet Release 3.0 : paragraph 1.1
vi
Publication History
December 2000 Issue 01.02/EN Draft Updated items Chapter 1 (UMTS general description) 1.4 Physical overview 1.5 UMTS traffic classes (moved from 2.2.3) 1.6 Spectrum constraints (moved from 2.2.4) Chapter 3 (Access network) split into three chapters: WCDMA principles iRNC iBTS Chapter 8: OAM Add four figures describing the OAM server configurations. New items Chapter 3: WCDMA principles Chapter 4: iRNC Chapter 5: iBTS November 2000 Issue 01.01/EN Draft Creation Sent to Mike Reids team (Core network) for comments and update.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
Table of contents
vii
About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Applicability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How this document is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vocabulary conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1 1 1 1 2 3
Whats new in this UMTS network release . . . . . . . . . . . . . . . . . . . . . . . . . . . UMTS general description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Coverage area of the UMTS network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nortel Networks UTRAN solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Core Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nortel Networks Core Network solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UMTS interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UMTS Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Spectrum constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operation Administration and Maintenance (OAM) . . . . . . . . . . . . . . . . . . . Physical overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . From GSM to UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WCDMA principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Different types of WCDMA system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Spread spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Code multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Downlink transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 6 9 11 13 15 18 22 24 25 27 30 33 37 41 42 45 47 48
viii
Table of contents
Uplink transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interference performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rake receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Macro-diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UMTS handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iRNC presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iRNC features and functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iRNC hardware structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iRNC C- Node modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iRNC I- node modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iRNC configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iRNC tools and utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iBTS description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iBTS operational features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iBTS cabinet description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Presentation of the iBTS outdoor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Presentation of the iBTS indoor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Description of the digital shelf of the iBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . Description of the RF block of the iBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iBTS tools and utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration rules of the iBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . STSR configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50 52 53 57 58 59 65 67 69 72 75 78 82 83 84 85 89 91 95 100 102 103 104 105
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
Table of contents
ix
Nortel Networks Core Network solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wireless Gateway introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wireless Gateway interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wireless Gateway features and functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wireless Gateway Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wireless Gateway software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wireless Gateway hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GGSN introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GGSN interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GGSN features and functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GGSN hardware structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GGSN configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MSC introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3G-MSC/Call Server features and functions . . . . . . . . . . . . . . . . . . . . . . . . . . 3G- MSC/Call Server software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3G- MSC Call Server hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HLR introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HLR features and functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HLR interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HLR hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HLR software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SIG introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SIG features and functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SIG hardware structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
106 109 110 114 118 122 125 132 134 135 142 145 146 147 150 151 154 155 158 159 161 164 165 166
Table of contents
UMTS interfaces introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UTRAN interfaces introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol structure of the UTRAN network interfaces . . . . . . . . . . . . . . . . . . UTRAN protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UTRAN protocol stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Radio interface (Uu) introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Channel definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Radio interface protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping of radio protocols on network elements . . . . . . . . . . . . . . . . . . . . Layer 1 description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol suite for packet services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Iu interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Core Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GPRS/UMTS interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ga Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gd interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gi interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gn Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gp interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gr and Gr interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gs and Gs interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OAM hardware description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
170 171 172 176 178 181 184 186 188 189 190 191 196 202 204 205 206 207 211 220 221 227 228 234
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
Table of contents
xi
OAM software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backup, restore and install (BRI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wireless Service Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OCAN general presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accounting Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Regulatory information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
243 246 250 254 255 257 263 264 267 268 272 275 277
xii
List of figures
Figure 1 -- UMTS01 release architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2 -- Example of UMTS PLMN coverage area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 3 -- UTRAN architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4 -- UMTS01 Core Network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5 -- Spectrum allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6 -- UMTS network solution with OAM susbsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7 -- Physical architecture of the UMTS01 solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 8 -- Multimedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 9 -- Global mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 10 -- UMTS supplementary services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 11 -- QoS architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 12 -- CDMA (IS95, 3G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 13 -- WCDMA: FDD or TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 14 -- DS--CDMA principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 15 -- Spread spectrum: transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 16 -- Spread spectrum: reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 17 -- Code multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 18 -- Downlink transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 19 -- Uplink transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 20 -- Power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 21 -- Macro--diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 22 -- Different types of handover in UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 23 -- Criteria of decision for soft handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 24 -- Soft handover principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 25 -- iRNC cabinet: physical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 26 -- iRNC PCM--x configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 27 -- iRNC SDH--x configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 28 -- Data flow of the uplink path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 29 -- Data flow of the downlink path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 30 -- Outside view (iBTS outdoor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 31 -- Inside view (iBTS outdoor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 32 -- Bulkhead front view (iBTS outdoor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 33 -- Outside view (iBTS indoor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 34 -- Inside view (iBTS indoor 600) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 35 -- Inside view (iBTS indoor 700) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 36 -- Bulkhead topview (iBTS indoor 600) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 37 -- Bulkhead topview (iBTS indoor 700) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 38 -- Front view of the digital shelf (iBTS outdoor and iBTS indoor 700) . . . . . . . . . . . . Figure 39 -- Front view of the digital shelf (iBTS indoor 600) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 40 -- Front view of the MCPA shelf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 12 14 20 26 28 32 33 35 37 40 41 42 43 45 46 47 49 51 54 58 60 62 64 70 79 80 87 88 91 92 94 95 96 97 98 99 101 101 102
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
List of figures
xiii
Figure 41 -- UMTS01 Core Network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 42 -- The Wireless Gateway within the UMTS network . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 43 -- UMTS Iu protocol stacks and WG components . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 44 -- Wireless Gateway shelves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 45 -- Wireless Gateway hardware structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 46 -- Connectivity to GGSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 47 -- Summary of Shasta GGSN interworking components . . . . . . . . . . . . . . . . . . . . . . . Figure 48 -- GTP architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 49 -- Shasta--GGSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 50 -- UMTS Circuit Core Network products for UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 51 -- Serving area of a CS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 52 -- XA--Core Multiprocessor Architecture with XAI Midplane+ . . . . . . . . . . . . . . . . . . . Figure 53 -- HLR basic cabinets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 54 -- HLR software structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 55 -- HP9000 N4000 front exterior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 56 -- Telecom Signaling Unit: Front view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 57 -- Telecom signaling unit: Back view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 58 -- SIG system cabinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 59 -- UTRAN interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 60 -- General model of UTRAN interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 61 -- UTRAN protocol stacks (control plane) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 62 -- UTRAN protocol stacks (user plane) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 63 -- UTRAN protocol stacks (ALCAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 64 -- Uu protocol layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 65 -- NAS/AS concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 66 -- Mapping logical to transport channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 67 -- Mapping transport to physical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 68 -- Mapping of radio protocols on network elements . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 69 -- Protocol suite for packet services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 70 -- Data and control fields at layer 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 71 -- Frame/Timeslot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 72 -- User service multiplexing for layers 1 and 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 73 -- Iu circuit--switched protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 75 -- UTRAN--to--Core Network interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 76 -- User plane transparent mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 77 -- Iu user plane using support mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 78 -- IP network interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 79 -- Transparent mode for basic Internet service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 80 -- Transparent mode for dedicated Intranet access . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 81 -- GTP protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
107 111 113 119 125 133 136 137 143 146 147 153 159 163 166 167 167 168 171 173 178 179 180 182 183 184 185 188 190 191 193 195 196 198 199 200 207 208 209 211
xiv
List of figures
Figure 82 -- Message sequence for PDP context activation procedure . . . . . . . . . . . . . . . . . . . Figure 83 -- Message sequence for PDP context deactivation procedure . . . . . . . . . . . . . . . . . Figure 84 -- Example of a pair of GSN nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 85 -- Message sequence for the echo response procedure on signaling path and data path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 86 -- Location of the Gr interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 87 -- Location of the Gr interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 88 -- Protocol stacks for MC, SIG, and HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 89 -- OAM functional architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 90 -- Physical OAM architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 91 -- Ultra Enterprise 4503 server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 92 -- Dual T3 disk array devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 93 -- Generalized FC&P software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 94 -- Fault Management architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 95 -- UTRAN configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 96 -- OCAN position in an operator network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 97 -- Input/Output data of the OCAN -- Functional view . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 98 -- Performance Management architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 99 -- ATM network components and communication protocols . . . . . . . . . . . . . . . . . . . .
215 217 218 219 222 223 224 229 235 237 239 244 246 251 258 260 264 274
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
List of tables
xv
Table 1 -- UMTS Core Network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 2 -- Traffic classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 3 -- UMTS Core Network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23 38 202
xvi
List of tables
PAGE INTENTIONALLY LEFT BLANK
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
About this document
ABOUT THIS DOCUMENT

This document is the UMTS Overview.
Applicability
This manual is applicable to the UMTS01 release of Nortel Networks. The UMTS01 release implements the UMTS Release 99 (3GPP) architecture.
Audience
This manual is intended for operations, maintenance, and other personnel who need an overview of the UMTS system.
Related Documents
UMT/DCL/DD/0002 411-8111-905: UMT/DCL/DD/0003 411-8111-906: UMT/DCL/DD/0004 411-8111-804: UMT/DCL/DD/0007 411-8111-907: 411-8111-903: 411-2231-010: 411-2831-010: 411-5221-926: UMT/DCL/DD/0010 411-8111-510: UMT/DCL/DD/0012 411-8111-512: 411-8111-503: 411-8111-504: 450-3031-338: About the iBTS About the iRNC UMTS Terminology About the UMTS OAM Main and Performance Servers UMTS Wireless Gateway User Guide Circuit Core Networks Call Server Product Guide Circuit Core Networks HLR Product Guide Shasta GGSN User Guide About the UMTS Access Network OAM UMTS Access Network OAM Commands UMTS Circuit Core Network OAM Overview UMTS Packet Core Network OAM Module Overview Preside for UMTS Solution Guide
References
3GPP standards: http://www.3gpp.org/3G_Specs/3G_Specs.htm
About this document
How this document is organized

In a continuous effort to improve our documentation, we are preparing its delivery through the web. This leads to a new global organization of the Nortel Networks technical publications. The information will be broken down into modules, with each module containing elementary information such as the procedure to replace a particular equipment, or the description of a particular component. The modules are designed in order to deliver just enough information to provide the user with the solution required to perform his current task. These modules will usually be delivered on CD-ROMs or through the web. The user will access this information by browsing, navigating from one module to another, or by using a search engine. In its current version, this NTP has been written as a series of modules. The modules are arranged one after the other in logical order. The table of contents helps you to access the right module. Be careful, while screening the table of contents, since all the modules will be displayed with the same level of importance. UMTS general description gives a functional and physical overview of UMTS. It briefly describes the UMTS interfaces. Services describes the UMTS services: new services, the transition from GSM to UMTS, and the main UMTS mechanisms. WCDMA principles gives the principles of WCDMA: different types of WCDMA (FDD/TDD), spread spectrum, code multiplexing, interference performance, power control, rake receiver, and soft handover. iRNC describes the features and functions, interfaces, location, and hardware structure of the iRNC. iBTS describes the features and functions, interfaces, location, and hardware structure of the iBTS. Core Network describes the main components of the Core Network. UMTS interfaces describes the UMTS interfaces: UTRAN, UTRAN-Core Network, and Core Network. OA&M gives a general view of the UMTS OA&M Regulatory information contains regulatory information for the iBTS and the iRNC. Appendices ATM gives the ATM (Asynchronous Transfer Mode) key principles. IP gives the IP (Internet Protocol) key principles.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
About this document
Vocabulary conventions
Lists of terms used in NTPs are in: UMT/DCL/DD/0004 411-8111-804: UMTS Terminology
About this document
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
Whats new in this UMTS network release

For the UMTS01 system delivery, the supplementary information concerning the UMTS network is the following: iBTS " new features according to the system release change " new configuration rules " new hardware modules " external battery cabinet OAM " OCAN: Off--line Configuration Management for UMTS Access Network " BRI: Backup, restore and install " WSM: Wireless Service Management The following modules contain this new information: iBTS " iBTS operational features " Outdoor physical layout " Indoor physical layout " Configuration rules of the iBTS OAM " OCAN general description " BRI general description " WSM general description
UMTS general description

Introduction The Universal Mobile Telecommunication System (UMTS) is a 3G wireless standard, incorporating mobile cellular and other functionality. It is based on a WCDMA (Wide Band Code Division Multiple Access) Access Network and a MAP (Mobile Application Part) Core Network. Through the packet Core Network and next generation technology used for the RAN (Radio Access Network), UMTS provides a reduction of costs for operators. It allows an increase in capacity as well as the evolution towards multimedia services. UMTS is one of the technologies which allow Internet services to be made easily available via wireless. It also offers Nortel Networks customers the benefits of a system that brings together the companys wireless expertise with its Internet know--how. The UMTS Nortel Networks Solution is available as an Access Network, a Core Network or as a complete Network Solution. The UMTS Nortel Networks solution offers wireless Internet services with the same quality of service as that which is offered today for voice telephony services. Major UMTS components The UMTS Release 99 architecture, defined by 3GPP, is composed of three major components: UE (User Equipment) The User Equipment (UE) is composed of three parts: " USIM card (Universal Subscriber Identity Module--card). The USIM is a smart card that allows the identification of any subscriber by the network. In particular, the subscriber can borrow any mobile without changing anything from the network point of view on condition they keep the same USIM--card. " handset, including the radio equipment (receiver--transceiver) and the Man--Machine Interface (MMI). In UMTS, rich multimedia, WAP, and other services are supported by a wide array of handset options. " battery UTRAN (UMTS Terrestrial Radio Access Network) UMTS uses a new radio technology called WCDMA (Wide Band Code Division Multiple Access) for the access network. WCDMA is based on CDMA and differs from GSM technology. The introduction of a new radio technology led to the creation of a completely new radio access infrastructure. This infrastructure is known as the UTRAN. CN (Core Network) The CN is split into: " CS (Circuit Switched) domain The CS domain is an evolution of GSM, with substitution of the Iu-CS interface for the A interface and relocation of the transcoders to the CN side of the Iu CS interface. The CS domain uses 64 kbit/s TDM (Time Division Multiplexed) channels or ATM (Asynchronous Transfer Mode) transport. This domain provides a similar set of services to those provided by GSM.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
" PS (Packet Switched) domain The PS domain is based on GPRS, with substitution of the Iu-PS interface for the Gb interface. The most significant addition is a viable architecture for the QoS (Quality of Service). This is essential for the support of voice and other real--time media services on the PS domain. Other efficiency improvements have been made to the GTP (GPRS Tunneling Protocol) used between the GSNs (GPRS Switching Nodes) and also to mobility mechanisms. These changes are designed to make real--time services viable over a packet infrastructure. The interface between the UTRAN and the Core Network is the Iu interface. The Iu interface has two variants: Iu-CS This is used for circuit services. The Iu-CS is an evolution of the GSM A interface. Iu-PS This is used for packet services. The Iu-PS replaces the GPRS Gb interface for UMTS services. The PS and CS domains within the Core Network provide two possible options for the implementation of services: on a packet--based infrastructure on a circuit--based infrastructure They also offer an evolution path in the longer term towards an entirely packet-based infrastructure. For Release 99, the key issue is which services will be supported by which domains. One example is whether operators will want to use the PS domain for voice services. The UMTS01 release of Nortel Networks is compliant with the UMTS Release 99 (3GPP).
Figure 1
UMTS01 release architecture
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
UTRAN
The UTRAN uses the WCDMA radio technology. The UTRAN is composed of several Radio Network Subsystems (RNS). An RNS covers a certain geographical area and is equivalent to the GSM BSS. Each RNS is composed of one Radio Network Controller (RNC) and several node Bs. A node B is a logical node responsible for radio transmission/reception in one or more cells to/from the user equipment. Note: In a future release, the different RNSs will be interconnected through the Iur interface of each RNC to form a network. WCDMA WCDMA is a completely different interface from the TDMA (Time Division Multiple Access) radio technology used by GSM. WCDMA is based on CDMA and differs from GSM technology. The major difference is that instead of using narrow radio channels which are time-division multiplexed, WCDMA uses wide radio channels. Each communication channel is identified by a unique code so that they may share the same radio spectrum. This allows much greater flexibility in the characteristics of the traffic channel that can be offered to the user. It also enables easier radio planning. There is no longer a requirement to ensure that a buffer zone exists between transmitters using the same radio frequencies. RNC The RNC is the central element in the UTRAN. Its main function is to control and manage the RAN (Radio Access Network) and the radio channels. The RNC supports the following interfaces, standardized by 3GPP: Iub Iub is the interface between an RNC and a node B. Iu Iu is the interface between the UTRAN and the CN. The Iu interface has two variants: Iu-CS for circuit services, Iu-PS for packet services. Iur Iur is the interface between two RNCs. It will be used in a future UMTS release. Uu Uu is the radio interface between UTRAN and UEs. Note: Iu, Iub, and Iur interfaces rely on ATM.
10
Node B A node B is a logical node responsible for radio transmission/reception in one or more cells to/from the user equipment. A node B provides the following interfaces: Iub interface towards the RNC Uu interface towards the User Equipment (UE)
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
11
Coverage area of the UMTS network

Several area types have been defined in UMTS to handle user mobility: Location Area (LA) Routing Area (RA) UMTS Registration Area (URA) Location Area (LA) A UMTS Location Area contains a group of cells, each cell belonging to one LA. LAs are used by the Core Network CS domain to get information on the user location when in Idle mode. One LA consists of a number of cells belonging to RNCs that are connected to the same CN node, for example on Call Server. The mapping between one LA and the RNCs is handled within the Call Server owning the LA. Routing Area (RA) A UMTS RA contains a group of cells, with each cell belonging to one and only one RA. RAs are used by the Core Network PS domain to get information on the user location when in Idle mode. One RA consists of a number of cells belonging to RNCs that are connected to the same CN node, for example to one Call Server. The mapping between one RA and RNCs is handled within the SGSN owning the RA. UMTS Registration Area (URA) URA is a new concept for the use of UTRAN only (i.e. URA are not seen by CN). As for LA and RA, a URA contains a group of cells, each cell belonging to one URA. URA are used by UTRAN to get information on the user position when the mobile is in connected mode, but not using a logical channel. This notion is not mandatory for UTRAN, but it allows to define trade--offs between UE position accuracy and signalling load. The following relations between LA and RA are possible: RA and LA are identical. An RA is a subset of one, and only one, LA, meaning that a RA does not span over more than one LA.
12
Figure 2 Example of UMTS PLMN coverage area
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
13
Nortel Networks UTRAN solution

iRNC The iRNC is the e--mobility Internet RNC. It is the 3GPP--compliant UMTS RNC developed by Nortel Networks. The generic term iRNC is used throughout this document to designate the e--mobility Internet RNC. The iRNC allows mobility between UMTS and GSM networks. The main functions of the iRNC are to control and manage: the RAN (Radio Access Network) the signaling between the different CN elements and the RNS the node Bs the radio resources of the corresponding node Bs. The iRNC houses the following cabinets: the C--Node (Control Node) The C--Node is an ATM--based engine that support UMTS call processing and signaling as well as OAM of both the RNC and the node Bs. the I--Node (Interface Node) This is based on Passport 15000. It is a high--capacity ATM switch, in charge of the connectivity (User Plane) of the iRNC. the Access Node This optional cabinet is used for a PCMx configuration. It is a Passport 7480 switch. The main function of the Access Node is to convert the STM1 links into PCM links and vice versa. iBTS The iBTS is the e--mobility Internet BTS. It is the 3GPP--compliant UMTS node developed by Nortel Networks. The generic term iBTS is used throughout this document to designate the e--mobility Internet BTS. The following types of iBTS are available: e--mobility Internet BTS ---- indoor version (600 and 700) e--mobility Internet BTS ---- outdoor version Nortel Networks UTRAN architecture The following figure shows the Nortel Networks UTRAN architecture.
14
Figure 3
UTRAN architecture
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
15
Core Network
Introduction The Core Network is responsible for subscriber connection services as with 2G systems. Although the technology and procedures may change to improve the efficiency of these services, they remain conceptually the same as in 2G. Subscriber management Subscriber management services provide similar services as in 2G but are more complex due to the nature of the subscriber environment. Accounting includes circuit, packet and location information and well as subscription levels and QoS information. The QoS model itself is enhanced to be able to transport a wide range of service types across the UMTS system. Access to networks The UMTS CN also provides accesses to a wide variety of other networks and service platforms. Service examples The communication services are mainly dealt with by the CN itself whereas entertainment, telemetric services, travel and similar services are more likely to be provided by third-party service providers. Many of these services exist today, such as the Web-based services. The CN provides access to these services for mobile and fixed subscribers alike. Core Network architecture (Release 99) The Core Network (Release 99 of 3GPP) is split into two domains: CS (Circuit Switched) Traffic arriving over the Iu interface destined for the CS domain is routed from the Wireless Gateway to the Call Server. Following transcoding, the bearer channels are routed to the Call Server using standard 64 kbit/s TDM links. The Radio Access Network Application Part (RANAP) CS signaling is routed to the Call Server over IP, where the call is processed in a traditional manner (translations, routing and service invocation). Communication with the SS7 environment is performed utilizing the SS7 capabilities of the Call Server hardware. TDM connectivity to both the Wireless Gateway and the PSTN is provided via the DTC hardware. PS (Packet Switched) Traffic for the PS Domain is processed in the Wireless Gateway in a manner similar to the handling of GSM GPRS data traffic. The SGSN performs setup and routing of data sessions to the GGSN for access into the Internet or corporate Intranets utilizing GPRS Tunneling Protocol (GTP) tunnels. Major Core Network components The Core Network contains the following major components: Serving GPRS Support Node (GGSN) The SGSN requests location information from the HLR through the Gr interface. It performs setup and routing of data sessions.
16
Transcoder and Rate Adaptation Unit (TRAU) The TRAU is a device that takes UMTS speech packets and converts them into standard ISDN 64 kbit/s speech packet. In UMTS, this functionality is part of the Core Network. Gateway Global Packet Radio Services (GPRS) Support Node (GGSN) The GGSN provides the point of interconnection with external packet data networks (PDN) for Public Land Mobile Networks (PLMN) supporting UMTS. This interconnection utilizes the Gi interface. The GGSN stores routing information for attached UMTS users. The routing information is used to tunnel Protocol Data Units (PDU) to the current 3G--SGSN serving the MS. 3G--MSC/Call Server The 3G--MSC is responsible for circuit domain call processing and circuit--switched data. In future releases, the 3G--MSC will be evolved to the Nortel Networks call server. Home Location Register (HLR) The HLR is a network database used for permanent management of mobile subscribers within a PLMN. It is accessible from the 3G--SGSN and the 3G--MSC. The HLR has been enhanced to include UMTS subscription data and routing information. SS7 IP Gateway (SIG) The SIG is responsible for interworking IP and SS7 as transport protocols. The SIG receives MAP messages on IP that are destined for the HLR and transmits the MAP messages over standard SS7 protocols: SCCP, MTP3, MTP2, and MTP1. Likewise, the SIG receives MAP messages from the HLR over standard SS7 protocols and transmits them to the 3G--SGSN over IP. Other Core Network elements The following elements are also part of the Core Network: VLR (Visitor Location Register) The VLR contains all subscriber data required for call handling and other purposes for mobile subscribers currently located in the area controlled by the VLR. The VLR supports a mobile paging and tracking subsystem in the local area where the mobile is presently roaming. AuC (Authentication Center) The AuC is a database that contains secret subscriber keys and security algorithms. It generates security information for authentication and ciphering. For security reasons the AuC often has an internal interface with the HLR. However this is a choice of implementation. It is up to the HLR to start security algorithms located in the AuC. EIR (Equipment Identity Register) The EIR is a database that stores IMEIs used within a GSM or UMTS network. Additionally, the register may store the status of said IMEI (classified as white listed, gray listed or black listed). An MSC queries an EIR to determine the status of a mobile station based on the IMEI obtained from that mobile station. SMS Gateway MSC This entity acts as an interface between a Short Message Service Center and the PLMN, to allow short messages to be delivered to mobile stations from the Service Center (SC).
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
17
SMS Interworking MSC This entity acts as an interface between a Short Message Service Center and the PLMN, to allow short messages to be submitted from the mobile station to the SC. GMSC (Gateway MSC) If a network delivering a call to the PLMN cannot interrogate the HLR, the call is routed to an MSC. This MSC will interrogate the appropriate HLR and then route the call to the MSC where the mobile station is located. The MSC that performs the routing function to the actual location of the MS is called the GMSC (Gateway MSC). IWF (Interworking Function) The IWF is a functional entity associated with the MSC. The IWF provides the functionality necessary to allow interworking between a PLMN and the fixed networks (ISDN, PSTN and PDNs). The functions of the IWF depend on the services and the type of fixed network. The IWF is required to convert the protocols used in the PLMN to those used in the appropriate fixed network. The IWF may have no functionality when the service implementation in the PLMN is directly compatible with that used by the fixed network. DNS server This translates between Fully Qualified Domain Names and IP address. It is used to translate the Access Point Names requested by the subscribers to the IP address of the access point. DHCP server This assigns IP addresses as required.
18
Nortel Networks Core Network solution

The UMTS01 solution of Nortel Networks is compliant with the UMTS Release 99 of 3GPP. It provides a compliant Iu interface from the Wireless Gateway to the iRNC. The Wireless Gateway is based on the Passport 15000 hardware. In conjunction with the Wireless Gateway: A TDM-based DMS--MSC terminates the CS domain traffic. The GGSN terminates the PS domain traffic. CS domain Traffic arriving over the Iu interface destined for the CS domain is routed from the Wireless Gateway to the MSC. AMR (Adaptive Multi--Rate) transcoding is performed on the voice traffic in the Wireless Gateway prior to routing to the MSC (the MSC does not have transcoding capabilities). Following transcoding, the bearer channels are routed to the MSC utilizing standard 64 kbit/s TDM links. The RANAP CS signaling is routed to the MSC over IP. The call is processed in a traditional manner (ithat is to say translation, routing and service invocation). This may include interworking with the PSTN via an appropriate signaling system (for example ISUP) where required. Communication with the SS7 environment is still performed utilizing the integral SS7 capabilities of the DMS hardware. TDM connectivity to both the Wireless Gateway and the PSTN is provided via the DTC hardware (Digital Trunk Controller). PS domain Traffic for the PS domain is processed in the Wireless Gateway in a manner similar to the handling of GPRS data traffic. The existing capabilities of the SGSN are utilized to set up and route the calls to the GGSN for access into the Internet or corporate Intranets utilizing GTP tunnels. SS7 queries (for example to the HLR) are routed utilizing the SIGTRAN protocol in the SS7 gateway (SIG). This gateway provides packet to SS7 interworking capabilities. Main Core Network components The main Core Network components in the UMTS01 release are: Wireless Gateway The Wireless Gateway (WG) is a common Iu interface termination point for both PS and CS domains. It houses the 3G--SGSN functionality (PS domain) and the TRAU functionality (CS domain). GGSN The GGSN performs functions that are similar to the gateway MSC, but for packet data. The GGSN provides the point of interconnection with external PDNs (Packet Data Network) for the wireless PLMN supporting GPRS. This interconnection is performed via the Gi interface. The Nortel Networks 3G--GGSN is the Shasta--GGSN.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
19
3G--MSC The 3G--MSC provides the call, service and mobility--related processing functions required to support speech calls in the network. It also takes part in combined PS/CS procedures such as RA/LA update, combined GSM/GPRS attach and detach. The Nortel Networks 3G--MSC is the UMTS/DMS MSC. HLR The HLR is a database that contains permanent subscriber data, such as provisioning and service information. It also contains dynamic information, such as the user equipments current location, which it gets from the VLR. The Nortel Networks HLR is the UMTS/DMS HLR. UMTS01 Core Network architecture The Core Network architecture for the UMTS01 release is described in the following figure.
20
Figure 4 UMTS01 Core Network architecture
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
21
Please refer to the following documents for more detailed information on the Core Network: NTP 411--8111--903 UMTS Wireless Gateway User Guide NTP 411--2231--010 Circuit Core Networks Call Server Product Guide NTP 411--2831--010 Circuit Core Networks HLR Product Guide NTP 411--5221--926 Shasta GGSN User Guide
22
UMTS interfaces
The modules that make up the UMTS network are linked to one another through the following interfaces: Access Network inferfaces Access Network to Core Network interface Core Network interfaces Access Network interfaces Uu interface (UMTS user interface) This is the interface between a node B and UE. It is dependent on the technology used on the radio interface. Iub interface (UMTS node B interface) This is the interface between an RNC and its node Bs. Iur interface (UMTS RNC interface) This is the interface between two RNCs. It has been defined to support specific functions such as handover without having the Core Network involved. The Iur interface is not supported in the UMTS01 release. Access Network to Core Network interface Iu interface (UMTS interface) This is the interface between the Core Network and the access network. The Core Network can be connected to different access networks using the Iu interface. Core Network interfaces UMTS interfaces are defined by GSM and UMTS specifications. UMTS interface Iu replaces GSM A--Interface between the radio network and the switch. Interfaces B--G are unchanged from GSM and use the Mobile Application Part (MAP) protocols to exchange the data necessary to provide mobile service. The following table describes the circuit and packet core network interfaces.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
23
Table 1 UMTS Core Network interfaces Interface Name Iu CS Iu PS B Core Network interface description Circuit switched interface between the Call Server and RNS via the WG. Packet switched interface between the SGSN (included in WG) and RNS. Interface between the Call Server (CS) and VLR using MAP/TCAP signalling over CCS7 SCCP and MTP. The CS contains both the CS and VLR functionality (that is the CS is co--located with the VLR. Therefore the B--Interface (CS <--> VLR) is an internal interface only. Interface between the Call Server and HLR using MAP/TCAP signalling over CCS7 SCCP and MTP. Interface between the HLR and VLR using MAP/TCAP signalling over CCS7 SCCP and MTP. Interface between Call Servers using MAP/TCAP signalling over CCS7 SCCP and MTP. ISUP, or some other Call Control protocol is also exchanged to permit inter CS calls to be established. Interface between CSs and EIR using Map/TCAP signalling over CCS7 SCCP and MTP. Interface between VLRs using MAP/TCAP signalling over CCS7 SCCP and MTP. This interface is used to exchange the data related to the location of the mobile station and to the management of the subscriber. The main service provided to the mobile subscriber is the capability to transfer packet data within the whole service area. The SGSN informs the HLR of the location of a mobile station managed by the latter. The HLR sends to the SGSN all the data needed to support the service to the mobile subscriber. Exchanges of data may occur when the mobile subscriber requires a particular service, when he wants to change some data attached to his subscription or when some parameters of the subscription are modified by administrative means. Signalling on this interface uses the Mobile Application Part (MAP), which in turn uses the services of Transaction Capabilities (TCAP). These interfaces are used to support mobility between the SGSN and GGSN. The Gn interface is used when GGSN and SGSN are located inside one PLMN. The Gp--interface is used if GGSN and SGSN are located in different PLMNs. The Gn/Gp interface also includes a part which allows SGSNs to communicate subscriber and user data, when changing SGSN. Signalling on this interface uses the User Datagram Protocol, UDP/IP. Interface between the GGSN and the Internet.
C D E
F G Gr
Gn, Gp
Gi
24
UMTS Protocols
The UMTS protocols are split into: UTRAN protocols Core Network protocols UTRAN protocols Three main control protocols exist in the UTRAN: RANAP (Radio Access Network Application Protocol) This protocol is used between RNC and Core Network (CS or PS domain). It is an evolved GSM BSSMAP protocols. It is used for: RAB management, relocation of SRNC, transport of NAS signaling messages, paging, controlling the security mode, location reporting... NBAP (Node B Application Protocol) This protocol is used between an RNC and its node Bs. It is used for: cell configuration management, radio link management and supervision, measurements made on common and dedicated resources, system information management. RNSAP (Radio Network Subsystem Application Protocol) This protocol is used between 2 RNCs. It is used for: radio link management, physical channel reconfiguration, relocation execution, measurement on dedicated resources, paging. The protocol SSCOP (Service Specific Connection Oriented Protocol) allows to increase the reliability of the signaling connection, using error detection, error correction and integrity check algorithms. Core Network protocols There are several signaling protocols used in the Core Network. The nodes within the network can be addressed with either MTP3 point codes or IP addresses. The main signaling protocols used in the Core Network are: GTP (GPRS Tunneling Protocol) The GTP protocol used to control IP tunnels between the RNC and the GGSN is a connectionless protocol. As it relates to the IP world, the nodes use IP addresses. UDP (User Datagram Protocol) The UDP protocol is used to control the connectionless datagram communications. RANAP (Radio Access Network Application Part) RANAP is used for the Iu--CS and Iu--PS interface. Some of the RANAP procedures are connection oriented and therefore the SCCP layer of SS7 is used. TCAP (Transaction Capabilities Application Part) TCAP provides dialogue control for CAP/INAP and MAP protocols. These are connection oriented and use the services of SCCP. ISUP (ISDN User Part) ISUP, between the Call server and the PSTN, may require the services of SCCP for certain types of configuration, but more usually uses MTP3 directly.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
25
Spectrum constraints
All the previously-mentioned requirements created the need to allocate a new part of the spectrum to provide more capacity. An important effort (driven by the ITU--R) was made to standardize a world--wide system. The role of the ITU--R was to define a new part of the spectrum available everywhere so as to support this new concept of mobility. The ITU--R defined the IMT--2000 recommendations which cover satellite, terrestrial and local environment wireless access. Proposals The three main continental bodies proposed candidate solutions for the terrestrial part of the IMT--2000 recommendations according to the available spectrum and technological background. The proposed solutions were UTRA for ETSI (Europe), WCDMA for TTC/ARIB (Japan) and CDMA2000 for TIA (USA). Finally, Japan and Europe decided to merge and created a common group called 3GPP (3rd Generation Project Partnership) which has defined the UMTS specification whereas the USA has stayed with CDMA2000. Nevertheless, all the proposals including satellite aspects are based on some variations of the CDMA technologies which offer the best spectrum efficiency for multimedia services. The terrestrial IMT--2000 candidates operate in the 2-GHz band with 5-MHz carriers. Two 60-MHz bands are paired for operation in the FDD (Frequency Domain Duplex) mode where one distinct frequency is used for each transmission direction. A non--paired 50-MHz band is used in the TDD (Time Division Duplex) mode where time multiplexing is used for both transmission directions with only one frequency. The following figure describes the frequency plan for IMT--2000 as well as the spectrum occupation in the different regions.
26
Figure 5 Spectrum allocation
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
27
Operation Administration and Maintenance (OAM)

The Nortel Networks UMTS Network Solution is available as an Access Network, a Core Network or as a complete network solution. The Uu radio interface, PSTN voice interface, Gi interface to external networks and Gp interface to other Public Land Mobile Networks delineate the complete Nortel Network UMTS Networks Solution. The OAM subsystem is that part of the Nortel Networks UMTS network solution that is dedicated to supporting OAM of the network, as opposed to directly providing service to subscribers. OAM functionality is provided primarily with Preside--branded software products, and the over--all OAM Subsystem is branded as Preside for Wireless Internet Solution for UMTS. As the Nortel Networks UMTS network solution integrates a large variety of network elements with differing OAM requirements, the OAM subsystem is corresponding large and complex. Though the local terminal interfaces for each of the nodes could be considered to be part of the OAM subsystem, this description will not address them. Please refer to the documentation for each element of the network for local interface information.
28
Figure 6 UMTS network solution with OAM susbsystem
Centralized, integrated OAM The OAM subsystem provides integrated, centralized network management for both cost and efficiency reasons. Centralized network management allows for efficiencies of scale in the operating organization. Integrated network management provides users with tools to support the network as a system, rather than as a collection of individual elements.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
29
Access, Core Network and solution offerings The Nortel Networks UMTS network solution is a available as an Access Network, a Core Network or as a complete network solution. The OAM subsystem supports all three of these different offerings with the same hardware platforms. The capacity of the OAM subsystem is scaled for the different offerings by adjusting the amount of hardware in each of the hardware platforms. The differing functionality between the offerings is provided through use of different combinations of OAM software, not through fundamental changes to the supporting hardware and architecture. National and Regional Operations Centers (NOC/ROC) For large networks, the OAM subsystem is tiered into a National Operations Center (NOC) and subsidiary Regional Operations Centers (ROC). The NOC provides a network--wide facility for back--up of OAM subsystem data and management of the OAM software applications, as well as network--wide fault surveillance. This chapter focuses on the ROC -- the NOC is implemented using a subset of the ROC hardware and software, configured for the NOC application. OAM product evolution The OAM subsystem is expected to evolve significantly during the early releases of the UMTS network solution (V1.0, V1.1, V1.2). This document describes the planned V1.2 release; current product will not match the configuration or functionality described in this document. Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as progress in engineering and manufacturing may warrant.
30
Physical overview
The flexibility of the cellular system enables the operator to easily increase the equipment capacity according to traffic needs. The number of links needed to connect the system units depends on the amount of traffic that must be handled. UTRAN The Nortel Networks UTRAN is made up of a set of RNCs (iRNCs) which are connected to node Bs (iBTSs). iRNC The iRNC is made up of the following cabinets: " Control Node, based on Nortel Networks GSM BSC E3 technology This accomodates up to thirty removable modules. The modules are electrically--shielded metal boxes that have identical dimensions. Modules, cable-connections, air--filter assemblies, and other maintenance items can be accessed from the front of the frame. Cable--trough covers protect the cable runs and cable connections. " Interface Node, based on Passport This accomodates up to eighteen removable modules. The mechanical structure is identical to the Control Node. The Control Node and the Interface Node are connected via two OC3/STM1 optical fibers which carry the ATM cells. " Access Node, an optional cabinet used for a PCMx configuration. This is a Passport 7480 switch. It converts the STM1 links into PCM links and vice versa. iBTS The iBTS is available in indoor or outdoor versions. The iBTS is modular in design for easy network growth and flexibility, to manage diverse traffic requirements. The increase of capacity is provided via the simple addition of modules, as opposed to the addition of an entire cabinet. Core Network The primary nodes in the Nortel Networks UMTS CN architecture are as follows: Wireless Gateway The Wireless Gateway is based on the Passport 15000. Two shelves can be fitted into one cabinet. Each shelf has 16 slots for processing cards. Two types of card are provisioned in the WG: " CP (Control Processor) " FP (Functional Processor): ATM, E3/DS3, SGSN, VSP. Two slots are reserved for CP cards and 14 slots are available per shelf for FP cards. Different types of FP can be mixed in the shelf to achieve optimal WG configuration.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
31
GGSN The following hardware components are required to provide the basic GGSN functionality: " Shasta 5000 BSN " Service Creation System (SCS) Server and Client The Shasta 5000 BSN provides the packet processing functionality for the GGSN. The SCS server and client are used for configuring the Shasta 5000 BSN. A single SCS server and client can be used to provision multiple Shasta 5000 BSNs in the customer network. To support GGSN functionality, the software loads with GGSN functionality are required for both SCS and Shasta 5000 BSN hardware platforms. The following external components can provide additional services or alternatives to basic functionality when working with the Shasta GGSN: " Charging Gateway Function (CGF) " RADIUS Server " Application Server " Tariff Server HLR The HLR is a database that contains permanent subscriber data, such as provisioning and service information. It also contains dynamic information, such as the user equipments current location, which it gets from the VLR. The base of HLR hardware consists of either XA--Core or CCN XA--Core SE, depending on the configuration: " HLR cabinets They house all HLR hardware. An example of HLR cabinet lineup is: one for HLR with XA--Core base, and one for HLR with XA--Core SE base. " HLR with XA--Core base The XA--Core equipment includes three cabinets: the dual--plane combined core (DPCC) cabinet, the Enhanced Network (ENET) cabinet, and the Link Peripheral Processor (LPP) cabinet. " Equipment common to all CCN HLRs The Cabinetized Trunk Module Equipment (CTME) cabinet contains maintenance trunk modules configured as Office Alarm Units. Input/output equipment includes the Cabinetized Input/Output Equipment (CIOE) cabinet and the Maintenance and Administration Position The Cabinetized Power Distribution Center (CPDC) cabinet provides direct current power distribution and protection to the other cabinets in the HLR lineup. 3G--MSC/Call Server The UMTS01 Call Server uses the DMS--MSC XA--Core with a SuperNode cabinet base for its hardware platform. XA--Core (eXtended Architecture Core) is designed as a next generation replacement for the computing module (CM) and system load module (SLM) within MSC systems. XA--Core is designed as a direct replacement for the CM/SLM and, as such, fits cleanly into the CCN architecture. Physical architecture The physical architecture of the UMTS network, for the UMTS01 release, is described in the following figure.
32
Figure 7 Physical architecture of the UMTS01 solution
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
33
Services
New services For the first time in mobile communications, a network platform provides high--speed data and multimedia services. The service and application capabilities of UMTS far exceed those available with second-generation networks. Multimedia In UMTS networks, it is possible for one mobile termination to have several active bearer services simultaneously, each of which can be connection oriented or connectionless. The access network has the possibility of seeing all the bearers allocated to a user. This possibility provides efficient multiplexing on the radio interface and better radio mobility support. Multiple information sources are available using audio, text and video with a quality of service previously unavailable via wireless networks. The capability for simultaneous sessions for example, allows a customer to conduct a voice call while at the same time accessing information via a web--browser. The following figure is an example of a multimedia service. Several sessions with different quality of service requirements are active simultaneously between end users. Figure 8 Multimedia
34
Global mobility The development of new information technologies beyond plain voice services (Internet, multimedia) has led to an extension of the concept of mobility. With cordless systems, the mobility concept was restricted to a small geographical area (home). With the development of cellular technologies, mobility was extended to large areas (countries) thanks to the roaming service. The satellite provided world--wide coverage, but with smaller capacity. Each time, the user had to choose the appropriate technology according to his service expectations and local constraints. The idea behind the global mobility concept is to use all these technologies to offer the best service to the user according to the environmental constraints. It also offers a seamless continuity when moving from one zone to another (anywhere--anytime communication). A unique mobile terminal associated with a unique personal number will provide the service ubiquity without awareness of the underlying network and of the used technology (such as satellite for rural). In this context, the purpose of the VHE (Virtual Home Environment) concept is to offer the user the same communication environment as in his/her nominal zone regardless the position and the network used. Global mobility is described in the following figure.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
35
Figure 9 Global mobility
VHE (Virtual Home Environment) The VHE offers customers homogenous access to services via many different terminal types and across different networks. Through the use of shared or customized interfaces, the customer can access a personal portfolio of services in the same way. The access is indifferently via the home network or via roaming. Much of the customer value comes via the customization of services which are possible with the concept of VHE. Each customer can define the particular portfolio of services which he/she wishes to access via the customized portal. These services are available to the customer in all environments, whether on the home network or when roaming on another network.
36
Examples of applications Nortel Networks provides platforms that support and manage applications to all market segments. The following applications are given as examples: E--commerce Nortel Networks can support service providers evolution towards ASPs (Application Service Provider), by delivering hosting applications for an application server. From this server, the ASP can offer secured access to accounts by subscriptions, via the Internet or managed IP networks. Unified Messaging Nortel Networks provides operators with the possibility of offering a unified messaging service to their end customers. Unified messaging allows customers to efficiently receive and handle messages of all kinds, including e--mail, voicemail, fax and SMS through their choice of interface no matter where they are. Users can be notified of incoming messages via their mobile terminal, along with how many messages and what type. They can access these messages using the same terminal, regardless of whether the message is voice, text or video. This service can be combined with the Preside service management software from Nortel Networks, providing service control, customer care and billing, service activation, policy services, and service assurance. Prepaid Nortel Networks provides a solution which allows operators to co--ordinate both voice and data services on one single prepaid balance. Nortel Networks employs the ServiceBuilder Intelligent Network platform to support these prepaid data and voice services. The interworking is accomplished using the Intelligent Networking CAMEL standard. The implementation of the CAMEL standard allows multi--vendor interworking.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
37
From GSM to UMTS

Compatibility with 2G services One of the key constraints on UMTS is service compatibility with 2G systems. On the one hand UMTS is a new network that integrates a new technology on the access networks, and introduces new concepts and enhanced features as compared with the previous generations. On the other hand it has been decided that there should be no restriction in terms of supplementary services, bearer services and teleservices for a mobile user already using a 2G system. Therefore, the following has been decided: All the bearer services currently defined in GSM shall be available in UMTS. This includes circuit-switched transparent/non transparent, and packet-switched services. All the teleservices currently defined in GSM shall be available in UMTS. This includes services such as speech, point--to--point or cell broadcast short message service, and access to IP. All the supplementary services currently defined in GSM shall be available in UMTS: call transfer, call diversion. The following figure describes the UMTS supplementary services. Figure 10 UMTS supplementary services
Smooth transition from GSM to UMTS The objective of a progressive transition from GSM to UMTS is essential both to protect GSM investments and to minimize UMTS introduction costs.
38
Consequently, UMTS will first be introduced into the GSM coverage as local spots. This implies the following technical requirements: availability of dual--mode GSM--UMTS mobiles interconnection of UMTS devices with existing GSM infrastructure management of handover from GSM to UMTS In a first step, the UMTS access network will be linked to the GSM core network through the A interface for the MSC and through the Gb interface for the SGSN. In this phase, available services are mainly GSM services whereas high--rate services will only be available in a second phase. UMTS traffic classes Four traffic classes have been identified in UMTS: Conversational The conversational class is the typical class for speech telephony. The conversational call is the most demanding one in terms of transfer delays (the maximum affordable value is given by human perception). Streaming The streaming class has the same real--time constraints as the conversational class. However, since it is a one--way class of service (the user is just listening or viewing) the streaming class is less transfer--delay sensitive than the conversational class. Interactive The interactive class is not as real--time constraining as the conversational and streaming classes. However, the interactive class requires a very low bit-error rate. Background The background class is quite equivalent to the interactive class. The only difference is that the background class is less delivery-time sensitive, and has a lower priority than the interactive class. Table 2 Traffic classes Conversational class conversational RT Preserves time relation (variation) between information entities of the stream. Conversational pattern (stringent and low delay). voice Streaming class streaming RT Preserves time relation (variation) between information entities of the stream. Interactive class Interactive best effort Request response pattern. Preserve payload content. Background Background best effort Destination is not expecting the data within a certain time. Preserves payload content.
Traffic class Fundamental characteristics
Example of the application
streaming video
Web browsing, FTP
Background download of emails, SMS
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
39
Quality of Service (QoS) Quality of Service is defined as the collective effect of service performances that determines the satisfaction of a user of a service. It is characterized by the combined aspects of performance factors applicable to all services, such as the following: service support performance service operability performance service accessiblity performance service retainability performance service integrity performance service security performance The QoS model for UMTS is broken into several levels: End--to--end Service End--to--end service requires that the QoS demanded by an application can be delivered. The application type and therefore the type of QoS requested is outside of UMTS. This implies that UMTS must provide a translation mechanism for application QoS requests. UMTS bearer service This level provides the translation to/from the external application requests. Inside UMTS, this layer negotiates a QoS across the UMTS network. CN bearer and radio access bearer This level is responsible for ensuring the correct QoS in the CN and the UTRAN. It uses the services of the BS managers below, which allocate the resources. The CN manager is responsible for checking the subscriber information. The RAB manager is responsible for checking that the UTRAN has the resources to provide the requested QoS. QoS architecture is described in the following figure.
40
Figure 11 QoS architecture
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
41
WCDMA principles
Introduction WCDMA (Wideband Code Division Multiple Access) builds on the experience of the past 10 years of CDMA being used as a multiple access technology for cellular systems. CDMA is fundamentally different from the access technologies used in 1st generation systems and other 2nd generation systems. First generation analog systems used FDMA (Frequency Division Multiple Access), while second generation systems used Frequency and TDMA (Time Division Multiple Access), often referred to as FTDMA. In CDMA systems such as IS95 and UMTS, the user is allocated a carrier frequency and a code known as a pseudo random noise code. The narrowband voice signal is spread over the wideband carrier using the pseudo noise code which spreads the energy of the transmitted signal over the carrier spectrum. The receiver then uses the same code to decode the transmitted wideband signal and recover the narrowband signal. Because the bandwidth of each carrier is 5 MHz, the air interface used for UMTS is described as Wideband CDMA (WCDMA). Figure 12 CDMA (IS95, 3G)
42
Different types of WCDMA system

Wideband CDMA differs from 2nd generation CDMA systems by the bandwidth of the carriers. The carrier bandwidth defined for UMTS is 5 MHz whereas the bandwidth used for 2nd generation systems such as IS95 is 1.25 MHz. Two different types of WCDMA system have been defined for UMTS: FDD (Frequency Division Duplex): WCDMA in frequency division duplex mode TDD (Time Division Duplex): CDMA in time division duplex mode Figure 13 WCDMA: FDD or TDD
FDD mode is the preferred mode for macro--cellular applications.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
43
TDD mode is the preferred mode for the unpaired part of the spectrum. In TDD, each time slot can be assigned a different direction. So the TDD mode offers a great flexibility to manage duplex and asymmetric traffic. The TDD spectrum will be used for low mobility coverage in urban areas. Both of these systems are variants of what is known as DS--CDMA (Direct Sequence CDMA). DS-CDMA In direct sequence CDMA, the modulated narrowband information--bearing signal has a code signal applied to it directly to give a broadband spread spectrum signal. Figure 14 DS-CDMA principle
The rate of the code generator is referred to as the chip--rate. The key criterion for spreading is that the chip--rate of the code signal is considerably higher than that of the information--bearing signal. FDD mode FDD is a duplex method whereby the uplink and the downlink transmissions use 2 separate frequency bands: Uplink: 1920 MHz -- 1980 MHz Downlink: 2110 MHz -- 2170 MHz Each carrier is 5--MHz wide and the uplink channel is 190 MHz away from the downlink. So, up to 12 pairs of carriers are available.
44
CDMA in FDD mode shares many common characteristics with 1st and 2nd generation systems that used FDMA and FTDMA. As with those systems, separate frequency bands are reserved for uplink communications and downlink communications. This separation obviously guarantees isolation between the two communication channels and perfect symmetry in capacity for both directions. Whereas this is efficient for voice communication, it can become inefficient as data services such as Internet browsing become more popular. TDD mode TDD is a duplex method whereby the uplink and the downlink transmissions are carried over the same frequency using synchronized time intervals. The carrier still uses a 5 MHz band. In the IMT--2000 spectrum allocation, 35 MHz have been reserved for TDD services. In TDD mode the uplink and downlink communications occur on the same carrier, without any fixed duplex separation. The allocation of codes and bandwidth is made as a function of demand in the uplink or downlink directions. In this way, CDMA in TDD mode is more adapted for non--symmetrical data services.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
45
Spread spectrum
CDMA falls into the family of transmission systems known as spread spectrum. The main characteristics of spread spectrum systems are the following: The bandwidth of the transmitted signal, Bt, is much larger than the bandwidth of the information--bearing signal, Bi. The radio--frequency bandwidth of the transmitted signal is independent of any of the characteristics of the information--bearing signal. The processing gain (Gp) in CDMA systems is defined by: G# = Bt/Bi As the pseudo--random noise codes are highly decorrelated, the receiver is able to recover the signal. A spread spectrum signal can only be recovered by using the same pseudo--random noise code. Any other spread signal remains spread unless the correct code is applied to it. Transmission Spreading the spectrum consists in increasing artificially the modulation rate (chip rate). This allows the energy of the information signal to be spread on a wide frequency band without modifying the data rate. The number of chips per bit is called the Spreading Factor (SF). It defines the data service required for the user. For UMTS: Bit rate x SF = 3.84 Mchip/s (Chip rate) Figure 15 Spread spectrum: transmission
Reception To be able to perform the de-spreading operation, the receiver must know the sequence used to spread the data signal.
46
The spreading sequence of the received signal and the locally--generated spreading sequence must be synchronized. This synchronization must be accomplished at the beginning of the reception and maintained until the whole signal has been received. Figure 16 Spread spectrum: reception
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
47
Code multiplexing
All WCDMA users occupy the same frequency at the same time. Frequency and time cannot be used as discriminators. WCDMA operates by using codes to discriminate between users. Using the correct code sequence, the receiver can decipher the required transmission channel. Users are discriminated by means of the spreading codes. Figure 17 Code multiplexing
48
Downlink transmission
A mobile station is surrounded by base stations, all of which transmit on the same WCDMA frequency. It must be able to discriminate between the different cells of the different base stations and listen to only one set of code channels. Therefore two types of code are used: Channelization code The users data are spread synchronously with different channelization codes. The orthogonality properties of OVSF enable the UE to recover each of its bits without being disrupted by other user channels. Scrambling code The scrambling code is used for base station and mobile station identification, it reduces the interference with neighboring cells since the same channelization codes are used. It is important to maintain correct cross--correlation characteristics between the different scrambling codes in order not to decode an interferer. These scrambling codes are allocated to the mobile users. This allocation does not change during the communication, unless the base station can be notified of the change. Similar to the re--use of frequency in GSM, scrambling codes are necessarily re--used.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
49
Figure 18 Downlink transmission
50
Uplink transmission
The WCDMA system must be able to uniquely identify each mobile station that may attempt to communicate with a base station. The different uplink code channels are distinguished by different MS scrambling codes. They may be scrambled by either long or short scrambling codes. Orthogonality from spreading codes is lost because there is no longer a synchronous transmission. Nevertheless scrambling codes reintroduce some kind of reduced orthogonality thanks to their cross--correlation properties.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
51
Figure 19 Uplink transmission
52
Interference performance
The processing of a CDMA system as regards intrasystem interference is the main difference when compared with other 1st and 2nd generation systems. The network operator is no longer required to plan the frequencies in the network and to identify the zones of interference. The radio engineer must now allocate codes to each base station and monitor the overall noise level of the network. Intranetwork interference no longer occurs at precise frequencies, instead the interference is spread over the whole bandwidth. Similarly, narrowband extranetwork interference has little impact on the performance of the system as only a small proportion of the signal bandwidth is affected. The quality of the communication remains mostly unchanged.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
53
Power control
Introduction One of the key elements in determining the capacity and performance of a wideband CDMA system is the use of power control. In the uplink, all users are using the same frequency channel at the same time. This involves considerable extra performance constraints on the receiver to distinguish between each of the users. Unless the codes being used are perfectly orthogonal and synchronized, the receiver will have difficulty in decoding the signals. The receiver constraints are increased if the various signals arrive at different power levels. The following diagram shows the need for power control.
54
Figure 20 Power control
Without power control, the signal arriving at the receiver from user 2 will be drowned out by the signal arriving from user 1. With power control, all signals should arrive at the receiver with the same mean power, thus reducing the noise level at the receiver. In the downlink, there is a similar need to reduce the interference between cells which in WCDMA are transmitting on the same frequency. As the base station is in continuous communication with the mobile, it must use its transmission energy as efficiently as possible. It is thus preferable that the base Station uses downlink power control to guarantee that enough energy is available to support as many users in the cell as possible.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
55
Two types of power control are used: inner loop The inner loop is controlled by the node B. The uplink and downlink mechanisms for the inner loop power control are described in the following. outer loop The outer loop is controlled by the RNC. The uplink and downlink mechanisms for the outer loop power control are described in the following. Inner loop power control The inner loop aims at compensating for fast fading. It applies to the uplink and downlink for all dedicated physical channels. The node B receiver compares the received signal--to--interference ratio with a SIR--Target. It sends increase/decrease commands to the UE several times per frame. Uplink power control For the uplink, inner loop power control checks the transmit power of the dedicated physical channels. The inner loop power control located in the iBTS receives: " the quality target from the uplink outer loop power control (located in the RNC) " the quality estimates of the uplink physical control channel (performed in the iBTS). The power control commands are sent to the UE. Downlink power control For the downlink, inner loop power control checks the transmit power of the dedicated physical channels. The inner loop power control located in the UE receives: " the quality target from the downlink outer-loop power control located in the UE " the quality estimates performed by the UE on the downlink dedicated physical control channel The power control commands are sent to the iBTS which adjusts the transmitter output power of a code channel accordingly. Benefits Up to 256 users can use the same frequency in a WCDMA system. The inner loop power control is used to balance the power of the different users. It prevents the node B receiver for being blinded for some users. Outer loop power control uplink outer loop power control The uplink outer loop power control sets the quality target for the inner loop power control. It consists in providing the UE with a target BLock Error Rate (BLER) for one or more reference transport channels. The UE uses this target to update its downlink outer loop power control in such a way that the quality target is met for the required transport channels. The BLER is stored in the RRM database (in the RNC) and assigned according to the set of QoS parameters received from the core network.
56
downlink outer loop power control The downlink outer loop power control regulates the power of dedicated physical channels. The RNC may further use the downlink outer loop control procedure to control the downlink outer loop in the UE. System parameters are used to prevent the UE from increasing its downlink SIR target value above its current value. Benefits These features aim at optimizing the quality and capacity from the UE, cell and RNC perspective. This is done through a dynamic management of the allocated radio resources using inputs from the measurement and monitoring functions. Dynamic resource management is a key function for maximizing quality of service and spectrum efficiency.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
57
Rake receiver
One of the key components in a WCDMA system is the rake receiver. The rake allows the system to take advantage of multipath diversity. The uplink signal undergoes many different reflections and attenuations, leading to the receivers getting a number of different signals of different signal strengths with different arrival times. The rake receiver is able to receive each of these signals, de--spread them and combine them to give an improvement in performance. The rake is made up of individual correlators or fingers which separate individual multipath signals onto a number of receiver elements, each of which deals with a multipath signal.
58
Macro-diversity
Macro--diversity is used to transmit the same signal via two or more cells, in order to counteract interference. Figure 21 Macro-diversity
Two types of macro--diversity are available: combining macro--diversity This function is used to combine uplink transport blocks. It combines the transport blocks coming from the node Bs participating in the UE active set into a single flow of transport blocks. splitting macro--diversity This function is used to duplicate downlink transport blocks. It broadcasts the transport blocks to all node Bs participating in the UE active set.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
59
UMTS handovers
Although more than one frequency can exist in a UMTS network, handover is usually to the same frequency. Three types of handover are used in UMTS: Soft handover The UE can communicate with more than one cell at a time if more than one cell meets the energy/noise requirements. This means that the UE can send the same information (coded differently) to more than one base station. The UE receives the incoming information from more than one base station. The UE exchanges the same information with two base stations. As this increases the chances of interpreting the received signal, the UE can transmit with reduced power. This mechanism reduces the background noise it creates for other users. If the UE continues to move, the first base stations signal will become unacceptable. The UE will drop the connection and continue communication on the second base station only. Softer handover If the UE is in communication with two base stations, it will have two channels on the Iub interface. However, if both cells are controlled by the same base station or the two base stations have the same site controller, the base station can interpret the two incoming signals. The base station only sends one incoming signal to the RNC. If a UE hands over from one cell to another and both cells belong to the same node B, the channel on the Iub interface will not be changed. This is known as a softer handover. Hard handover If the UE must hand over to a different frequency (whether on another system like GSM or GPRS, or not), this is known as a hard handover.
60
Figure 22 Different types of handover in UMTS
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
61
Criteria of decision for soft handover Ec/No measures the strength of the pilot. Thanks to this parameter, the readability of the associated traffic channel (corresponding to this pilot) can be predicted. This measurement is used for cell selection and reselection, and for handover preparation. It can be degraded by strong RF from other cells or sectors. The UE continuously checks all available pilots, measures the strength of these pilots with the Ec/No parameter. It informs the system of all suitable pilots. Using measurements of the UE and some predefined thresholds, the SRNS will decide to add or to delete a radio link for that mobile. The mobile will assign its rake receiver fingers according to the orders of the SRNS. In the case where the UE has established several radio links with different Node Bs (or different sectors of the same antenna), each end of the link (that is to say the SRNC and the UE) will choose what works best, on a frame--by--frame basis. Users are totally unaware of handovers. The criteria of decision for soft handover are described in the following figure.
62
Figure 23 Criteria of decision for soft handover
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
63
Soft handover principle Soft handover is the procedure by which the UE can be in relation with several Node Bs (maximum of 6 in theory) at the same time, possibly controlled by different RNCs. In the uplink, the UE emits only once, and the information is received by several node Bs. However, in the downlink, the UE receives the same packet several times. Soft handover still occurs within the UTRAN. It applies in FDD mode only. An Iur interface is necessary. It may be followed by an SRNS relocation procedure. For the uplink way, the UE has the same scrambling code and the same OVSF code, which is known by the node Bs concerned. For the downlink way, the node Bs have different scrambling codes and different OVSF codes, known by the UE. The soft handover principle is described in the following figure.
64
Figure 24 Soft handover principle
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
65
iRNC presentation
The 3GPP--compliant UMTS RNC developed by Nortel Networks is named iRNC. Most of the iRNC interfaces provide the ability to build multi--vendor solutions and the main part of the iRNC is built upon the Passport 15000 technology. The main functions of the iRNC are to control and manage: the RAN (Radio Access Network) the signaling between the different CN (Core Network) components and the RNS (Radio Network System) the node Bs and their corresponding radio resources There are two types of iRNC, according to whether they are included into: a PCM--x configuration or an SDH--x configuration. iRNC for a PCM-x configuration The iRNC for a PCM--x configuration is housed in three separate cabinets: the C--Node (Control Node) the I--Node (Interface Node) The Access Node C-Node This is a high-speed processor based on the ATM/IP protocol. It manages the UMTS call and the signalling processing along with the integrated access network OAM. The OAM of the iRNC as well as the logical OAM of the Node B are interfaced through the C--Node. It is a highly available, robust, carrier--grade system with all the call processing and radio functions being protected against failure by: an internal star architecture a dual ATM backplane redundant modules I-Node This provides the connectivity of the user plane with a large array of possible interfaces. For example, it enables the connection of the iRNC to the WG (Wireless Gateway) through STM--1 optical fibers. It is used to support: IP/ATM protocol frame relay voice services
66
Access Node The Access Node enables connection on the Iub interface of the: iRNC via STM--1 optical fibers nodes Bs via 120$ohm or 75--ohm E1 PCM electrical links The Access Node cabinet is built upon the Passport 7480 technology. iRNC for an SDH-x configuration The iRNC for an SDH--x configuration is housed in one cabinet which mainly contains the two following nodes: the C--Node (Control Node), the I--Node (Interface Node) C-Node This is a high-speed processor based on the ATM/IP protocol. It manages the UMTS call and the signalling processing along with the integrated access network OAM. The OAM of the iRNC as well as the logical OAM of the Node B are interfaced through the C--Node. It is a highly available, robust, carrier--grade system with all the call processing and radio functions being protected against failure by: an internal star architecture a dual ATM backplane redundant modules I-Node This provides the connectivity of the user plane with a large array of possible interfaces. For example, it enables the connection of the iRNC to the WG (Wireless Gateway) through STM--1 optical fibers. It is used to support: IP/ATM protocol frame relay voice services
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
67
iRNC features and functions

The iRNC supports all the interfaces defined by the 3GPP for UMTS and provides an industry--leading capacity and performance for operators. The iRNC is located on a platform that is deployed globally across wireless and high--speed packet networks. It provides the following main features: high capacity distributed architecture a large variety of transmission interfaces differentiated services proven carrier grade scalability simple yet powerful OAM High capacity The iRNC supports a high capacity per shelf solution. It is based on off--the--shelf processing technology. This will enable the operator to upgrade the iRNC by just upgrading boards as opposed to a fork--lift solution. This provides investment protection for the operator. Distributed architecture The iRNC enables distributed architecture over an ATM network which provides significant flexibility regarding how to deploy and grow the network. The iRNC houses both the following separate nodes: the control node server, which processes the control plane the interface node server, which processes the user plane The C--Node and the I--Node are connected via two (RX/TX) STM--1 optical fibers. Large variety of transmission interfaces A variety of transmission interfaces and traffic grooming functions have been integrated for ingress into the iRNC from the Node B. This will provide a flexibility of the transmission architectures that the operator wants to implement. This has been done in the iRNC architecture by decoupling the Radio functions from the transmission functions. The radio functions are further decoupled in the control plane and the user plane. This architecture ensures that the transmission does not limit the radio functions. Differentiated services The iRNC is powered with enhanced Radio Resource Management algorithms built on Nortel Networks CDMA and data experience. This enables the telecommunication carriers to differentiate customers (gold, silver, bronze, etc.) and to differentiate services. The telecommunication carriers have the ability to optimize the spectrum to match their respective market demographics in order to meet/exceed their respective business objectives.
68
Proven carrier grade Capacity grotwth is faciltated by hot insert of new modules and load balancing. All the service--critical elements are spared. Scalability The iRNC will allow scalable growth from a minimum configuration at network launch to full capacity configuration through software upgrades and interface board additions. The telecommunication carriers can then optimize investment by only making capacity upgrades when customer demand requires it. Simple yet powerful OAM The Nortel Networks solution is based on providing a simple and intuitive OAM that is powerful in doing cross--checks to ensure that proper provisioning is done.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
69
iRNC hardware structure

The iRNC cabinet contains mainly two sets of modules which house boards and processors. They provide each logical unit with the processing power it needs. Both two set of modules are split up as follows: The first set of modules is mainly dedicated to the control plane. It is housed in the C-Node. The second set of modules is mainly dedicated to the user plane. It is housed in the I-Node. The following figure shows the C--Node modules, the I--Node modules and the main iRNC interfaces.
70
Figure 25 iRNC cabinet: physical architecture
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
71
C-Node The C--Node houses the main types of processing unit in the following modules: OMU modules TMU-R modules ATM_SW modules, it is also named CC-1: CAM Controller 1 MMS modules I-Node The I--Node houses houses the main types of processing unit in the following modules: 16p OC-3/STM-1 modules CP3 modules Fabric modules PS FP modules
72
iRNC C- Node modules

The purpose of this part is to give a high level presentation of the processing modules in an iRNC C--Node: OMU module TMU-R module ATM-SW module MMS module OMU module The OMU modules are the OAM front end for the C--Node. They are provisioned in pairs to provide redundancy. One is running in active mode when the other is running in passive mode. They perform in a dual--mode (active/passive) the following operations: manages and supervises each resource inside the C--Node runs and controls the ATM_SW (also named CC--1) and TMU--R modules manages the interface with the Preside Wireless Platform manages the SCSI disks, which are housed in a MMS module provides the system maintenance (by using the TML or the Preside Wireless Platform via HUB access) Provide an Ethernet access via TCP/IP to and the Preside network wireless platform (MDM) To install each OMU module, a double slot must be available for each of them. An OMU module contains a VME interface for: OMU--SBC board It is a standard VME board of the shelf, which houses a CPU to compute different functions in the module. OMU--TM assembly It is a standard board of the shelf, which interfaces the the PCI bus with the SCSI/P. OMU--PMC assembly It is a standard board of the shelf, which interfaces the the PCI bus with the SCSI/P. Each OMU module can access: one private disk for its private data two shared disks managed in a mirroring way They are used to save the data in the event of an OMU module failure or a disk failure. For more information on an OMU module refer to C--Node OMU module: functional presentation.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
73
TMU-R module The TMU--R module manages the UMTS protocols in a large acceptance. It performs the following operations: provides processing power for the CallP (Call Processing) terminates the UMTS protocols for the Iu, Iub and Iur interfaces For more information on an TMU--R module refer to C--Node TMU--R module: functional presentation ATM_SW module From a hardware perspective, the ATM subsystem is a key factor for the platform robustness and scalability. This subsystem provides reliable backplane board interconnection with live insertion capabilities. The following figure shows a hardware overview of the ATM_SW module. The ATM_SW module performs: ATM switching internal ATM 25 adaptation The ATM25 internal links, which are located on the control node backplane, are performed in a dual star architecture. These links are used to connect both ATM_SW modules and each of them to the TMU--R modules and the OMU modules. external ATM 155 interface adaptation The ATM155 external links are used to connect each ATM_SW module to each 16p OC--3/STM--1 module, which are located in the interface node, via both STM--1 optical fibers. A single slot is used to install each ATM_SW module, which houses the following boards: a computer board named: ATM_SW--SBC It houses the ATM Cell Switch. an adapter board named: ATM_SW--TM It is used to interface the ATM_SW--SBC with: " the ATM25 links " the ATM155 links " the LEDs For more information on an ATM_SW module refer to C--Node ATM_SW module: functional presentation. MMS module The MMS modules are the data and software repositories. The RAID (Random Array of Inexpensive Disks) architecture, an industry standard, ensures that the data and the softwares are secured and still accessible in the event of a software or hardware failure. The control node houses four MMS modules. Each of them contains an SCSI hard disk. They are split up as follows: two shared hard disks managed in a mirroring way for both OMU modules
74
Each of them is used to save the data in the event of a software or hardware failure in the OMU module or the MMS module. one private disk for the OMU--A module It is used to save the private data for the OMU--A module. one private disk for the OMU--B module It is used to save the private data for the OMU--B module. The MMS module provides circuitry and mechanical features. It is compliant with the control node hardware architecture. For more information on an MMS module refer to C--Node MMS module: functional presentation.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
75
iRNC I- node modules

The purpose of this part is to give a high level presentation of the processing modules in an iRNC I--Node: CP3 module 16p OC-3/STM-1 module Packet Server module Fabric module CP3 module The CP3 module controls overall processing on the I--Node. It is located on the front panel of the I--Node and it performs the following main functions: controls of the base iRNC I--Node functions such as boots, loading, fault detection, sparing, etc. collects and maintains the I--Node inventory and the statistical data maintains the routing tables performs the SVC call setup routing requests provides the system maintenance (by using the TML or the Preside Wireless Platform via HUB access) control over standard ATM PVC connections on the external interfaces manages the for loads and logs Provide an Ethernet access via TCP/IP to and the Preside network wireless platform (MDM) While containing a standard core computing engine with a disk drive, the module also contains the external synchronization interface (E1) along with operations on Ethernet access ports. The CP3 can operate in redundancy mode. In redundancy mode, two CP3s are required on the I--Node. Both CP3 modules contain duplicated information and are connected to the two fabric modules with redundant links. While one CP3 operates as the active module, the second module operates in warm standby mode to provide high availability. In addition, the CP3 module contains a standard core computing engine with a disk drive, as well as: circuits to provide a Stratum--3 timing reference the external clock synchronization for the E1 PCM links operation access ports (Ethernet, RS--232 interfaces) for external interfaces For more information on a CP3 module refer to iRNC I--Node: CP3 modules. 16p OC-3/STM-1 module The 16p OC--3/STM--1 module is a Passport Frame Processor. It provides sixteen single mode ports and supports an UNI (User--Network Interface) or ATM Passport--Passport interface for each OC--3/STM--1 port.
76
It is located on the front panel of the I--Node and it houses the following main functions: 16 ports of OC--3/STM--1 payload SONET and SDH transmission types, on the same board optical fibers in single mode only SONET APS with automatic protection switching and redundancy mode (1+1) 16 k--per--port connection space or 64k--per--module connection space 6 k SVC connections software handling capability per FP ATM services with rt--VBR and nrt--VBR traffic services and UBR and CBR traffic services ATM Networking with SVC, PVC, SPVC, SVP, PVP and SPVP traffic management with scheduling, queuing, shaping, congestion control and CAC VPT: Virtual Path Termination UNI and NNI capabilities The 16p OC--3/STM--1 module can operate in redundancy mode. In this mode, two 16p OC--3/STM--1 are required on the I--Node. Both 16p OC--3/STM--1 modules contain duplicated information and are connected to the two fabric modules with redundant links. While one 16p OC--3/STM--1 module operates as the active module, the second module operates in warm standby mode to provide high availability. For more information on a 16p OC--3/STM--1 module refer to <module>. Packet Server module The Packet Server module also called PS FP module or 6mPktServSP FP (6--module Packet Server Frame Processor), is a server FP which provides services for the other interfaces in the I--Node. In--order to maximize utility of the Packet Server module, it is based on industry standard PMCs (PCI Mezzanine Cards). A Packet Server FP module houses 6 PMCs to support radio bearer processing and protocol conversion. The main features of the Packet Server FP module are: improves the speed and reliability of the hardwares evolution to remove from the application the need to drive the technology evolution The Packet Server FP module is located on the front panel of the I--Node and it performs the following main functions: manages the AAL2 SARing (Segmentation And Re--assembling) function for the AAL2 protocol manages for the user plane: the user plane processing, the Radio protocol handling (MAC, RLC and PDCP), the interface bearer protocols and the Macro--Diversity Handover (frame selection, buffering, synchronization, combining/splitting) manages all radio resources for the R--Man (Resource Manager) The Packet Server module can operate in redundancy mode. In this mode, two Packet Server modules are required on the I--Node. Both Packet Server modules contain duplicated information and are connected to the two fabric modules with redundant links. While one Packet Server module operates as the active module, the second module operates in warm standby mode to provide high availability. For more information on a Packet Server module refer to iRNC I--Node: Packet Server modules.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
77
Fabric module The Fabric module provides the centralized resources required to support the I--Node applications. It is connected by high speed serial bidirectional 3.2 Gbit links to the switching elements which reside on each Fabric module. It is located on the rear panel and it operates in redundancy mode. For this mode two fabric module are used. Both Fabric modules contain duplicated information and are connected to each other by redundant links. While one fabric module operates as the active module, the second module operates in warm standby mode to provide instant availability. For more information on a Fabric module refer to iRNC I--Node: Fabric modules.
78
iRNC configuration
The iRNC cabinet can be connected in the AN (Access Network) according to the following types of hardware configuration: a PCM--x configuration a SDH--x configuration The following figures show respectively: the iRNC in a UTRAN network for a PCM--x configuration the iRNC in a UTRAN network for a SDH--x configuration
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
79
Figure 26 iRNC PCM-x configuration
80
Figure 27 iRNC SDH-x configuration
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
81
PCM-x configuration The PCM--x configuration is used to connect the iRNC on the Iub interface to a node B through an Access Node cabinet which is built upon the Passport 7480 technology. The Access Node cabinet is used to connect: the I--Node through the STM--1 optical fibers the node Bs through the 120-- % or 75-- % E1 PCM electrical links The other STM--1 optical fibers connect the I--Node to: the neighbouring iRNCs through the Iur interface the CN (Core Network) through the Iu interface. SDH-x configuration The SDH--x configuration is used to connect the iRNC directly on the Iub interface to node Bs through STM--1 optical fibers (without E1 PCM electrical links). The other STM--1 optical fibers connect the I--Node to: the neighbouring iRNCs through the Iur interface the CN (Core Network) through the Iu interface
82
iRNC tools and utilities

The iRNC has several tools, among which the TML. The TML hardware is a PC. It works under windows and behaves like a Java browser. The TML is connected to iRNC through Ethernet connections on the OMU module inside the C--Node or the CP3 module inside the I--Node. The operator can plug in on the active or passive modules, provided that the LED status is correct. The TML can also be plugged in a hub that is hosted in the cabling area interface of the iRNC. The TML interface is independent from the iRNC software evolutions. The TML application software is hosted on the OMU module inside the C--Node or on the CP3 module inside the I--Node. The TML is also used for the iRNC installation and the test and maintenance activities. Using the TML for iRNC installation The TML can be used to boot the OMU module and to install the software inside the iRNC. It is used to read and to modify the customization parameters of the iRNC (iRNC number, IP address, PCM type, etc.) In addition, the TML is used to manage the private and the shared mirrored hard disks inside the C--Node (MMS module) as well: format, initialization, and duplication. Using the TML for test and maintenance The information about the configuration of the different hardware modules can be read from the TML: board identification and states software version software and patch markers The TML is used to perform a whole set of tests to check the integrity of the iRNC configuration: check the good functioning of a hardware module, the communication between two hardware modules, perform loop--back testing. Some of these tests can be performed with the module on--line and others require to put the module offline (via a TML command) and then run the tests.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
83
iBTS description
Introduction A node B is a logical node responsible for radio transmission/reception in one or more cells to/from the User Equipement. A node B provides the following interfaces: the Iub interface towards the iRNC the Uu interface towards the User Equipment (UE) A node B may consists of one or several iBTSs. The iBTS product is a line of products that cover different customers requirements: the outdoor BTS product (iBTS outdoor) the indoor BTS product (iBTS indoor 600 and iBTS indoor 700) The main functions of the iBTS are the following: to provide the means of communication between a UE and a network via Transport Channels. to provide the UE with some physical layer channels which are necessary to synchronize the downlink and also to perform cell selection/reselection and handover preparation to provide measurement information to the RNC for radio resource management (handover, power control) The iBTS is modular in design for easy network growth and flexibility, to manage diverse traffic demands. Common modules are used to grow the iBTS to increase capacity as demand requires. The increase of capacity is provided via the simple addition of modules, as opposed to the entire addition of cabinets. iBTS location The iBTS outdoor can be installed on two types of site: on terraces of buildings at ground level The iBTS indoor can be installed inside premises, if an air exchanger is provided in these premises. iBTSs are connected to their controller (iRNC) in a star configuration.
84
iBTS operational features

The main characteristics of the iBTS are the following: no need for an extra site cabinet (iBTS outdoor) for user space and batteries easy installation and commissioning a flexible product: possible growth from low to high capacity without any additional cabinets front access only PCM internal protection most common modules between the iBTS outdoor and the iBTS indoor iBTS indoor powered in dc or ac The iBTS is a low capacity solution that can grow in a modular way to full capacity. The iBTS supports the following functions: radio access and modem (modulation/demodulation, frequency up/down--conversion, amplification) call processing (channel set--up and management for both common and dedicated channels, cell management, power control, handover and measurement) configuration and supervision synchronization (to retrieve a highly stable radio frequency from either the network interface)
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
85
Functional architecture
Functional design iBTS archithecture is based on the following principle: best in class in terms of volume and size best in class in terms of capacity: three carriers no need for extra site cabinet The user space and the batteries are integrated in the cabinet (iBTS outdoor) operation efficiency: low power supply easy installation and commisioning possible growth from low capacity to high capacity in one cabinet maintenance facilities: modular design, hardware and software diagnostics for fault isolation mechanisms and fast reconfiguration software upgrade with minimum service downtime low accoustic noise for easy site deployment multi mode evolution to GSM/UMTS Functional characteristics The iBTS supports the following functions: network interface management radio access and modem call processing configuration and supervision performance monitoring Radio access and modem These function are: modulation, frequency--up conversion, amplification reception, frequency--down conversion, digitizing, and demodulation of the radio signal Call processing The call processing function is in charge of te radio resource management inside the iBTS. This function manages the UMTS services (described in 3GPP standards) and the internal services used for configuration and implementation purposes.
86
The call processing function is also in charge of channel set--up and management for both the common and dedicated channels, cell management, power control, handover, and measurement processing. The dedicated channel management includes setup, release, and modification procedures. The cell management includes the setup, deletion, and modification of a cell. The common channel management includes setup, release, and modification procedures. The power control is used to control the power emission of the user equipment. The handhover is a special case of soft handover called softer handover: the same BTS manages the cells that are communicating with the user equipment. Call processing is mapped on to the CCM, CEM, and TRM modules. Configuration/supervision This function is in charge of configuring and supervising the modules that ensure inventory information, reporting, and plug & play management. There are five modules that play a significant role in the delivery of this functionality: GPSAM CCM TRM interconnection module BIP (indoor cabinet) The remote inventory functionality allows the UMTS OAM access to determine the state of the iBTS and its composition. The remote inventory is done for the following modules: DDM, MCPA, CEM, CCM, TRM. Performance monitoring This function is in charge of performing and reporting radio measurements.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
87
Data flow description Figure 28 Data flow of the uplink path
88
Figure 29 Data flow of the downlink path
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
89
iBTS cabinet description

Shelves description The iBTS cabinet consists of the following elements: The digital shelf which consists of four types of module: " CCM (Core Control Module) in charge of OAM management, call processing, internal/external data flow switching/combining " CEM (Channel Element Module) in charge of call processing, base band transmit/receive digital signal processing " TRM (Transmit Receive Module) in charge of receive/transmit channelizer function, radio signal function, and supporting radio shelf connectivity interface " GPSAM (GPS and Alarm Module) in charge of supporting internal and external alarms The RF block which contains the RF modules: " MCPA (Multi Carrier Power Amplifier) in charge of boosting the RF signal delivered by the TRM module " DDMs (Dual Duplexer Module) consisting of a double duplexer LNA chain, one for the main path, the other for the diversity path The following table shows the number of modules in the complete configuration (available for future versions). Digital shelf CCM 2 2 2 TRM 4 4 3 CEM 6 6 4 GPSAM 1 1 1 RF shelf MCPA 6 6 6 DDM 6 6 6 Power Rectifier plinth 6+1 7+1 --------
complete configuration iBTS outdoor iBTS indoor 700 iBTS indoor 600
The following table shows the number of modules in the V1.2 configuration. Digital shelf CCM 1 1 1 TRM 1 1 1 CEM 1 1 1 GPSAM 1 1 1 RF shelf MCPA 3 3 3 DDM 3 3 3 Power Rectifier plinth 6+1 7+1 --------
V1.0b V1 0b configuration iBTS outdoor iBTS indoor 700 iBTS indoor 600
The interconnection module, which interconnects the digital signals and the power supply between the digital shelf modules, the power supply unit, and the RF module. In the indoor cabinet, the BIP (Breaker Interface Panel) which is located at the top of the cabinet. The BIP provides the distribution of the dc power to the modules, the distribution of the digital signaling from the digital shelf to the MCPAs and the DDMs.
90
The PCM and alarm protection, which provide lightning protection for up to eight PCM links and the connections for 16 external alarms and six remote controls, and also their protection against electrical disturbances that could occur between the iBTS and the customer equipment. The cooling system, which provides the climatic control for the iBTS. It consists of a iDACS for the outdoor cabinet and of one fan tray for the indoor cabinet . Power supply interface iBTS outdoor The iBTS outdoor is proposed in ac only. The cabinet is powered by the ac mains: 220--240 V single phase, 50--60 Hz 208--240 V split single phase, 50--60 Hz 230--400 V three phase, 50--60 Hz iBTS indoor The indoor iBTS must be supplied with --48 V dc only. iBTS indoor 700 with ac plinth The 700--iBTS can be externally powered through an ac plinth: 120--208 V three phase, 50--60 Hz The dc power system shelf of the ac plinth which consists of: a dc distribution module which provides five dc circuits breakers a SPCM (Single Power Control Module) which controls the ac power system up to eight rectifiers and a redundant rectifier which provide a nominal --48 V dc, 5640 W power network internal to the iBTS cabinet
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
91
Presentation of the iBTS outdoor

The iBTS outdoor is a single cabinet closed by two doors. Figure 30 Outside view (iBTS outdoor)
92
Figure 31 Inside view (iBTS outdoor)
The cabinet is divided into: the iDACS (internet Direct Ambient Cooling System) which is the cooling unit of the cabinet the main compartment the bulkhead which allows cable connection and lightning protection
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
93
The main compartment is divided into two parts: the left part which includes: " the dc power system shelf: the dc distribution module, the SPCM (Single Power Control Module), the rectifiers (up to seven) " the digital shelf " the battery system the right part which includes: " the ac distribution module " the RF block " the user space and its ICO " the interconnection module " the ac filtering box
94
Figure 32 Bulkhead front view (iBTS outdoor)
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
95
Presentation of the iBTS indoor

The iBTS indoor is a single 600mm--wide cabinet (iBTS indoor 600) or single 700mm--wide cabinet (iBTS indoor 700) closed by two doors. Figure 33 Outside view (iBTS indoor)
96
Figure 34 Inside view (iBTS indoor 600)
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
97
Figure 35 Inside view (iBTS indoor 700)
The cabinet is divided into several shelves: the breaker interface panel the interconnection module the RF block
98
the digital shelf the cooling unit An optional ac power plinth is used in conjunction with the iBTS indoor 700. All the cables enter the cabinet from a cable bulkhead located at the top of the cabinet. Figure 36 Bulkhead topview (iBTS indoor 600)
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
99
Figure 37 Bulkhead topview (iBTS indoor 700)
100
Description of the digital shelf of the iBTS

The digital shelf houses all the digital modules of the iBTS. The digital shelf is common to the iBTS indoor 700 and the iBTS outdoor and houses up to 12 modules. These modules share ten slots in the iBTS indoor cabinet. Backplane functionalities The backplane board is part of the digital shelf. It is in charge of supporting all internal links and electrical interfaces between the modules of the digital shelf. All modules and cables carrying external signals plug into connectors mounted on the backplane board. The backplane board accomodates several high speed signals up to 1.3 Gbit/s. It supports --48 V or + 24 V power supply. The backplane provides Inter--module connections and --48 V dc. Physical description of the digital shelf T bar rails are used in the digital shelf to guide the modules during insertion and removal operations. The digital shelf houses up to 10 modules (iBTS indoor 600) or 12 modules (iBTS outdoor and iBTS indoor 700), in complete configuration (for future versions), with flexible positions: CCM (Core Control Module) CEM (Channel Element Module) TRM (Transceiver Receiver Module) GPSAM (GPS interface and Alarm Module) All the modules are removable and are 50--mm wide. All the cables providing interconnection between the modules are mounted at the front of them.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
101
Figure 38 Front view of the digital shelf (iBTS outdoor and iBTS indoor 700)
F=Filler: module available for future versions Figure 39 Front view of the digital shelf (iBTS indoor 600)
F=Filler: module available for future versions
102
Description of the RF block of the iBTS

The RF block contains the MCPA and the DDM modules. The RF block is common to the iBTS indoor and the iBTS outdoor. The number of modules depends on the iBTS configuration. Physical description The RF block contains the RF modules: One MCPA shelf that contains six slots. In the three MCPAs configuration, these MCPAs are housed in slots 1, 3, and 5. There is no electrical backplane in the MCPA shelf: all the interconnection cables are mounted at the front of the MCPAs. One DDM shelf that contains three DDMs. All the cables providing interconnection between the modules are mounted at the front of them. Figure 40 Front view of the MCPA shelf
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
103
iBTS tools and utilities

The iBTS has two main maintenance tools: the OAM Access (Operation, Administration and Maintenance) and the TIL (Terminal for Local Installation). The Operation and Maintenance center for Node B is responsible for the configuring and supervising functions. The main OAM functions are the following: operation and maintenance alarm management configuration and supervision performance monitoring The TIL is composed of a laptop PC (with Web browser) connected to the iBTS. The TIL is used to install and commission the iBTS. The TIL performs the following: It displays the existing hardware of the iBTS product. It automatically displays new hardware. It provides basic maintenance and test capabilities for all iBTS modules. It allows users to save reports (alarm, test reports) on the PC. It retrieves the hardware and software module configuration. It downloads new software of iBTS modules.
104
Configuration rules of the iBTS

The iBTS has the following characteristics: one mode of operation: STSR one frequency carrier Antenna configuration The iBTS can be equipped with: two antennas for single--sector configuration four antennas for bi--sector configuration six antennas for three--sectors configuration Frequency carriers The iBTS supports multi--carriers configuration and allows 5 MHz operation in the STSR configuration.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
105
STSR configuration
STSR configuration stands for Sectorial Transmit Sectorial Receive. It is the standard three--sector configuration. The iBTS is logically declared at the iRNC as three cells. The user equipment reports measurements for the three sectors and softer handover is controlled by the network. The power allocation in STSR is independant across sectors. The iBTS supports the STSR1 configuration: one carrier per sector. The STSR1 configuration requires: one TRM which allows the reception of up to 6 signals (3x2) one CCM one CEM which is configured for three sectors x two carriers three MCPAs (one per sector) three DDMs (one per sector) iBTS outdoor The outdoor cabinet equipment layout follows the rules described in the following table: Digital shelf CCM 1 TRM 1 CEM 1 GPSAM 1 RF shelf MCPA 3 DDM 3 Power Rectifier 4+1
45 -W 45W configuration STSR1 iBTS indoor
The indoor cabinet equipment layout follows the rules described in the following table: Digital shelf Configuration STSR1 CCM 1 TRM 1 CEM 1 GPSAM 1 RF shelf MCPA 3 DDM 3 Power Rectifier plinth 7+1
106
Nortel Networks Core Network solution

The UMTS01 release of Nortel Networks UMTS solution is compliant with the UMTS Release 99 of 3GPP. The Core Network is split into CS and PS domains. It provides a compliant Iu interface from the Wireless Gateway to the iRNC. The Wireless Gateway is based on the Passport 15000 hardware. Main Core Network components The main Core Network components in the UMTS01 release are: Wireless Gateway The Wireless Gateway (WG) is a common Iu interface termination point for both PS and CS domains. It houses the 3G--SGSN functionality (PS domain) and the TRAU functionality (CS domain). GGSN The GGSN performs functions that are similar to the gateway MSC, but for packet data. The GGSN provides the point of interconnection with external PDNs (Packet Data Network) for the wireless PLMN supporting GPRS. This interconnection is performed via the Gi interface. The Nortel Networks 3G--GGSN is the Shasta--GGSN. 3G--MSC The 3G--MSC provides the call, service and mobility--related processing functions required to support speech calls in the network. It also takes part in combined PS/CS procedures such as RA/LA update, combined GSM/GPRS attach and detach. The Nortel Networks 3G--MSC is the UMTS/DMS MSC. HLR The HLR is a database that contains permanent subscriber data, such as provisioning and service information. It also contains dynamic information, such as the user equipments current location, which it gets from the VLR. The Nortel Networks HLR for the UMTS01 release is the UMTS/DMS HLR. UMTS01 Core Network architecture The Core Network architecture for the UMTS01 release is described in the following figure.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
107
Figure 41 UMTS01 Core Network architecture
108
Please refer to the following documents for more detailed information on the Core Network: NTP 411--8111--903 UMTS Wireless Gateway User Guide NTP 411--2231--010 Circuit Core Networks Call Server Product Guide NTP 411--2831--010 Circuit Core Networks HLR Product Guide NTP 411--5221--926 Shasta GGSN User Guide
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
109
Wireless Gateway introduction

The WG provides signaling and bearer services across both circuit and packet domains, as well as communication between the core and access networks. The WG is actually part of both the 3G--MSC and the 3G--SGSN according to the 3G standards definitions. For more detailed information about the WG, refer to NTP 411--8111--903 UMTS Wireless Gateaway User Guide. The WG is located between the RNC and the other core network nodes. The functional elements of the WG include the following: 3G--SGSN The 3G--SGSN performs mobility management, session management, implements authentication procedures, and routes data for the UMTS packet domain. Signaling gateway (SG) The SG processes the protocol layers that are involved in the transport of circuit and packet signaling between the UMTS Access Network and either the 3G--MSC/Call Server or the 3G--SGSN. Virtual media gateway (VMG) The VMG provides the Transcoding and Rate Adaptation Unit (TRAU) and Echo Cancellation functionality for the Core Network circuit domain and handles the allocation and call setup of the circuit domain Bearer Channel because it implements the Q.2630 and Q.2150 protocols. Aggregation node (AN) The AN provides connectivity between the Passport nodes providing SG, 3G--SGSN, and VMG functionality, and the external transport networks used for the Iu and Gn interfaces.
110
Wireless Gateway interfaces

The main Wireless Gateway interfaces are the following: Iu Interface The Iu interface is the name given to the logical connection between the access and core networks. In the Nortel Networks implementation, this is the interface between the RNC and the WG. It is split into Iu--CS (Circuit Switched) and Iu--PS (Packet Switched). Gn interface This is the interface between the 3G--SGSN and an GGSN. The transport layer of the Gn interface is based on IP over ATM. Gp interface This is the interface between an 3G--SGSN in one PLMN and a GGSN in a different PLMN. It is also the name of the interface between a 3G--SGSN and a SGSN in a different PLMN, for 3G--2G SGSN handover. Note: Gn and Gp interfaces share the same physical interface. Gr Interface This is the SS7 interface between the SIG and the HLR. The following figure describes the Wireless Gateway interfaces in the UMTS network.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
111
Figure 42 The Wireless Gateway within the UMTS network
Iu interface The transport layer of the Iu interface is based on ATM and supports PVCs connected to the AN. The Iu interface is the equivalent of the A interface in GSM and the Gb interface in GPRS. It is an open interface defined between the UMTS terrestrial radio access network (UTRAN) and the core network (CN). Between these two entities, the Iu interface provides the following: An abstract view of the UTRAN resources to the CN CN parameters to the UTRAN for its management
112
Functions across the Iu interface include the following: radio access bearer (RAB) management (for establishment, modification, and release) Iu link management (asynchronous transfer mode virtual circuit (ATM VC), ATM adaption layer 2 and layer 5 connections (AAL2 and AAL5), and GPRS tunneling protocol user plane (GTP--U) mobility management, for example: handover, serving radio network subsystem (SRNS) relocation, and paging security radio resource management (broadcast) service and network access (tracing and reporting) Iu signaling coordination (multiple Iu signaling connections are managed which requires coordination on the Iu interface) transport of circuit traffic in AAL2 transport of packet traffic in AAL5 marked with quality of service (QoS) Iu user plane (UP) management (frame protocol initialization and management). The Iu protocol stacks and their relation with the Wireless Gateway components is given in the following figure.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
113
Figure 43 UMTS Iu protocol stacks and WG components
114
Wireless Gateway features and functions

The wireless gateway (WG) is built upon the Nortel Networks Passport 15000 (15K) product. Passport is a high--speed packet switch providing networking services. The WG is a component of both the UMTS circuit and packet domain core networks. The WG can support a packet--only UMTS network, or both packet and circuit domain networks concurrently. Wireless Gateway components The main application components of the WG include the following: Signaling gateway (SG) The SG is required in all WG configurations. The SG application is responsible for all of the protocols in the control plane for the packet and circuit domains as well as the protocols in the bearer control plane of the circuit domain. The SG supports a linkset to each radio network controller (RNC). The linkset forms a logical connection between the RNC and the core network for signaling. Each linkset is composed of one or more Iu links. Multiple links can be provisioned to provide for greater capacity and reliability. The SG and its related Iu links reside on different FPs, which may also be on different shelves from each other or from the SG. Virtual media gateway (VMG) VMGs are an optional component of the WG and are not required if only the packet domain is being supported. Each VMG is a collection of media gateways (MGs). MG functions are implemented on dedicated voice services processors (VSP--Ts) and their TDM Interface FPs. The VMG is responsible for establishing user plane bearer connections between the RNC and the Call Server. The bearer plane connection management protocols are implemented through Q.2630. Third--generation serving general packet radio services support node (3G--SGSN) The 3G--SGSN is an optional node in the WG. The 3G--SGSN performs similar functions as the 3G--MSC, except that it processes packet data instead of circuit--switched data. One of the main roles of the 3G--SGSN is to perform data packet routing, using IP as the network layer protocol. Another key role of the SGSN is Mobility Management. This encompasses activities such as Session Management and state control. Mobility management also handles data packet routing on the downlink to the mobile station, including location tracking and authentication between the MS, user, and network using information on the subscriber--identity module (SIM) card. Aggregation node (AN) The AN is a required node in the WG. The AN is a Passport 15K shelf that connects to every other shelf in the WG. It also connects to external networks that transport Iu and Gn traffic, as well as DNS queries, billing records downloads, lawful intercepts, Gr and other traffic. While each shelf within a WG is limited to supporting only UMTS wireless--specific applications (for example, several SGs, a 3G--SGSN, and VMGs), the AN supports only Passport Carrier Data Networks features. The AN allows the WG configuration to change internally, to add capacity or perform maintenance, without affecting the transport network or re--engineering network connectivity. Note: The term FP (functional processor) is used to encompass the processor card. Node is used synonymously with shelf.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
115
Redundancy Redundant hardware and software mechanisms are an important issue to help ensure a reliable network. The Passport 15k provides a journaling mechanism whereby an application can journal data from an active instance of the application on one card to an inactive instance of the application on a standby card. Whenever the active card goes down due to a software or hardware failure or a software upgrade, the standby card will become active along with all the applications on the card. The journaling mechanism is not specific to any FP. Any FP that can be spared (that is, provisioning for a main card and a spare Card is allowed) can use the journaling framework. It is important to define a few terms: 1+1 Redundancy The redundancy scheme in which two functional processors (FPs) are used to behave as a single FP. The active FP has a standby FP. The standby cannot be used while the active FP is in service. Therefore, there is no load sharing of the standby FP. It remains idle until it becomes the active FP. Hot standby The standby FP is loaded with the same provisioning information as the active FP. It also receives information from the active FP on the state of current processes and stored information. If there is a failure of the active FP, the standby assumes the active FP role and begins processing information. Because it has copies of the active information of the failed FP, there is no loss of service and no impact to the network. Cold standby The standby FP is loaded with the same provisioning information as the active FP. It does not receive information from the active FP on the state of current processes and stored information. If there is a failure of the active FP, the standby assumes the active FP role and begins processing information. All dynamic information is lost, which may result in the need to restart any in--progress information depending on the application that was running on the failed FP (for example, mobiles attached to the network, message queries waiting on a response, and so on). Qualty of service (QoS) The WG, specifically the 3G--SGSN, supports routing of packet-domain traffic using Quality of service (QoS) parameters. Quality of service is defined as the collective effect of service performances which determines the satisfaction of a user of a service. It is characterized by the combined aspects of performance factors applicable to all service characteristics such as: service support performance service operability performance service accessibility performance service retainability performance service integrity performance service security performance In turn, the UMTS bearer service is made up of the radio bearer service, the Iu bearer, and the backbone bearer. Application--level QoS signaling must be translated at the UMTS network borders into UMTS QoS signaling. The UMTS QoS signaling is then translated between radio, Iu, and backbone bearers to achieve a consistent QoS within the UMTS network.
116
A bearer service manager in the CN works with bearer service manager functions in the mobile, radio access network and core network border gateway to control the admission to, and set up of, QoS services. Admission will be based on subscription to a given priority, the service level, and the currently available resource. QoS may be renegotiated at any time during a session. UMTS will be required to support the use of multiple applications on the MT (or equipment connected to it), which will have varying QoS requirements. To make efficient use of resources, a QoS specific to each application class needs to be provided. To enable this procedure, the concept of PDP subcontexts has been introduced. Once a PDP context has been established, subsequent flows (PDP subcontexts) can be established with the same IP address and access point name (APN) as the original flow, but with a different QoS. This removes the need to renegotiate addressing and APN every time a new QoS flow is established. Each QoS flow will have a flow template associated with it, which the MT and CN gateway will use to determine which flow to direct traffic to by matching the QoS requirements of the traffic to the traffic flow templates. Handover The WG supports handover for both the circuit and packet domains. In the circuit domain, handover is controlled by the 3G--MSC; there are no specific enhancements required by the WG. In the packet domain, the 3G--SGSN is responsible for all handover procedures. The 3G--SGSN supports the following: 3G--2G SGSN handover 2G--3G SGSN handover Both of these handovers are handled as defined by the UMTS specifications. The general procedures used in 2G and 3G handovers are as follows: UMTS (CS) to GSM This requires: " on the UMTS side: RANAP relocation (and Q.2630.1 when AAL2 connections can be released) " on the GSM side: MAP signaling between MSCs and BSSMAP handover signaling The anchor point is the UMTS MSC. Classmark and ciphering information is sent to the 2G side. The 3G--MSC does the conversion from RANAP to BSSMAP so the message sent over the E interface is a MAP message with BSSMAP encapsulated. GSM to UMTS (CS) This requires BSSMAP handover on GSM side, MAP signaling between MSCs, and RANAP relocation signaling on UMTS side (plus Q.2630.1 for AAL2 connection establishment). The anchor point is the GSM MSC. The 3G--MSC receives the BSSMAP message encapsulated in the MAP message from the 2G--MSC, and from this, it needs to do the following: " convert the BSSMAP message to its RANAP equivalent for sending over the Iu interface to the RNC " derive UMTS ciphering keys from the GSM ciphering keys The UE capability information, which is the radio part of the classmark, has to be sent over the BSSMAP message old BSS to new BSS info for interworking with 3G.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
117
UMTS (PS) to GPRS The trigger for this handover is a GMM (GPRS Mobility Management) routing area update. GTP messages are exchanged between the two SGSNs. The 3G--SGSN requests the context from the old SRNS through a new RANAP procedure (one that has no equivalent in BSSMAP), the SRNS context request. This procedure enables the source RNC to give information to the SGSN such as uplink/downlink GTP/packet data control protocol PDU sequence numbers. A new RANAP procedure SRNS data forward command initiates the forwarding of the data from the source RNC to the 2G--SGSN. The RANAP Iu release complete is only sent when all the data has been forwarded or on timer expiry. Again classmarks (MS radio capabilities and MS network capabilities) are handled differently in UMTS and in GPRS so the GMM and GTP messages transfer the classmark information to be used in GPRS. GPRS to UMTS (PS) This is similar to the existing inter--SGSN routing area update from GPRS. The trigger for the handover is a GMM routing area update. GTP messages are exchanged between the 2 SGSNs. Because the mobile has moved to 3G, the procedure is then similar to the setup of a new call in 3G as follows: " A new GMM (or packet mobility management (PMM)) message service request is sent to the 3G--SGSN, which instructs it to start ciphering " RANAP security messages are exchanged to set ciphering and integrity. " The RANAP RAB assignment procedure is then executed. " Data is forwarded from the 2G--SGSN to the 3G--SGSN.
118
Wireless Gateway Configurations

The WG application and all of its components are supported only on the Passport 15000 product. The WG is a multi--shelf application, which means that WG components can be provisioned on multiple Passport 15000 shelves and communicate and function as a single logical WG. Interconnection between shelves must be through ATM. Currently, there is not a limit on the number of Passport 15000 shelves functioning as a single logical WG. The WG is designed to provide a highly available, robust, and scalable architecture. The flexibility of the system makes it easy to configure according to each customer s network needs. A few designations are introduced here to frame the discussion of engineering a WG. Note: Regardless of which FPs are placed into a shelf or how it is configured, the same software load is used for all WG shelves except the Aggregation Node (AN). The AN uses a standard Passport load, while all other WG shelves use the same wireless software load.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
119
Figure 44 Wireless Gateway shelves
The Wireless Gateway contains different types of shelf: A shelf B shelf C shelf A shelf The A shelf is a combination of 3G--SGSN and SG applications. It consists of the following configuration: two CP3s One active and one in standby for redundancy.
120
one USC One active. four + SGs Two active SGs, each with a hot standby for redundancy. More SGs can be added by using spare slots two + USDs Both USDs are active and load share. If one fails the other will be available to assume additional traffic up to its capacity limit. two MAPs One active and one in cold standby for redundancy. two billing/legal intercept One active and one in hot standby for the billing application two Iu link FPs One active and one in standby for redundancy. The active FP also provides input/output (I/O) connectivity for the USD applications for packet bearer traffic and intershelf communication. Three slots remain open for additional FPs, which increase the capacity of the WG. This configuration provides for support of a minimum of four RNCs and, with an aggregation node, a complete packet domain WG. B shelf The B shelf is only supported in a single configuration and is required for support of circuit domain traffic. For that configuration, it consists of the following: two CP3s One active and one in standby for redundancy two Iu Link FPs One active and one in standby for redundancy. The active FP also provides input/output (I/O) connectivity for the media gateway applications and intershelf communication. eight VSP--Ts All VSP--Ts are active and available for circuit traffic. Each VSP--T provides TRAU functionality as well as an Iu--CS signaling link to the 3G--MSC. four 32--port TDM--to--ATM FPs All TDM Interface FPs are active and used for circuit bearer traffic. This configuration provides for support of 3,840 Voice circuits, or 3,456 Voice circuits and 384 circuits of switched data, depending on configuration The number of RNCs supported depends on configuration.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
121
Note: The B shelf is configurable as to which MGs support a particular SG, and therefore an RNC, but there are no options in how many or which type of FPs are installed in the shelf. Future WG releases may change this restriction. C shelf The C shelf is added when additional signaling gateway capacity is needed; that is, when more RNCs must be supported by a single WG, and there is no open slot available on the A shelf. This shelf consists of Iu links and signaling gateways only. Those applications are added as needed, requiring two slots in the shelf for each addition to provide an active and a standby FP. Minimum WG circuit and packet configuration A minimum WG that supports both circuit and packet domain services would consist of five Passport shelves, and therefore three Passport 15K cabinets. The five shelves would consist of the following: one aggregation node two B shelves two A shelves one empty shelf available for capacity expansion or additional Passport services
122
Wireless Gateway software

This module examines the individual software applications in the Nortel Networks core network (CN) wireless gateway (WG) architecture. These include the following: Signaling gateway (SG) Virtual media gateway (VMG) Third--generation serving general packet radio services support node (3G--SGSN) Aggregation node (AN) The SG is required in all WG configurations; therefore, it is examined first. The VMG is an optional component of the WG that is required only for support of circuit traffic. It and other components of the circuit domain are examined next. The 3G--SGSN is an optional component of the WG that is needed only for support of packet data. It and other nodes of the packet domain are then examined. Finally, the required aggregation node is explained. Note: The term FP (functional processor) is used to encompass the processor card. Node is used synonymously with shelf. Signaling gateway The SG application is responsible for all of the protocols in the control plane for the packet and circuit domains as well as the protocols in the bearer control plane of the circuit domain. The SG supports a linkset to each radio network controller (RNC). The linkset forms a logical connection between the RNC and the core network for signaling. Each linkset is composed of one or more Iu links. Multiple links can be provisioned to provide for greater capacity and reliability. The SG and its related Iu links reside on different FPs, which may also be on different shelves from each other or from the SG. The main functions of the SG include the following: The SG processes the protocol layers that are involved in the transport of circuit and packet signaling between the UMTS access network and either the 3G_MSC/3G--MSC or 3G--SGSN The SG provides an IU signaling link between the core network (3G--MSC and 3G--SGSN) and Access networks (RNC) The SG provides an SS7 interface between the 3G--MSC and SG to relay signaling messages The SG controls the media gateway (MG). The SG has an signaling gateway protocol engine (SGPE) entity that does not have explicit knowledge of the transport layer that the MG manages, but can control it through a MGCP--type request. For UMTS01, the SGPE speaks to the MGPE. The SG -- PS Layer 3 Relay entity forwards radio access network application part (RANAP) messages from the RNC to the UMTS subscriber control (USC). The SG -- mobility environment locator (MEL) entity locates the mobility environment for uplink PDUs. For the PS domain, this entity must be able to identify which USC the SG must send the datagram to. For the CS domain, connectivity to more than one call server will not be supported in UMTS01. The SG -- CS Layer 3 Relay relays, alters, or interworks layer 3 signaling messages. For UMTS01, it will merely relay (and alter where necessary) RANAP messages between the RNC and the call server. This entity also interfaces SGPE so that bearer connections can be made and broken.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
123
Virtual media gateway The VMG establishes user plane bearer connections between the RNC and the call server. The bearer plane connection management protocols are implemented here (Q.2630). VMGs are an optional component of the WG and are not required if only the packet domain is being supported. VMGs provide a pool of transcoding and rate adaptation units (TRAUs) to each SG; and since each SG supports a single RNC, each VMG is associated with an RNC. Each VMG is a collection of media gateways (MGs), which may be spread across any number of Passport 15000 Shelves. The main functions of the VMG include the following: The VMG establishes user plane bearer connections between the RNC and the call server. The VMG handles allocation and call setup of circuit domain Channel because it implements the Q.2630 and Q.2150. VMGs provide the transcoding and rate adaptation units (TRAU) for the core network circuit domain. The VMG provides echo cancellation functionality for the core network circuit domain. The VMG provides circuit data services. 3G-SGSN The 3G--SGSN is built upon the Nortel Networks Passport 15K product. Passport is a high--speed packet switch providing an integrated set of data, voice, video, and image networking services. Note: A node functioning as a 3G--SGSN does not support other GSM applications, such as GSM Passport interworking function (GPP IWF), PCUSN or GPRS. The node only supports the 3G--SGSN functionality. The 3G--SGSN performs similar functions to those of the MSC except that it processes packet--switched data instead of circuit--switched data. The main functions of the 3G--SGSN include the following: Detecting new UMTS and/or GPRS Mobile Stations (MS) in its service area Performing security functions for authenticating the MS access to the network Sending and receiving data packets between the MS and other network elements such as GSN, RNC, HLR, and others Performing mobility and session management functions for the MS inside its service area Generating billing records for the MSs data traffic usage Handling requested as well as negotiated QoS information for the MS Providing capabilities for intercepting the MSs data traffic and mobility and session events and generate records of the intercepted events Interworking with other network node entities, such as SGSN, GGSN, HLR, and others, directly or indirectly by supporting some of the 3G--SGSN network interfaces Intershelf communication The WG is a collection of applications spread across multiple Passport shelves. This requires that the applications communicate with each other across shelves or by intershelf communication.
124
The communication areas that require messages leaving or entering a shelf can be summarized as follows: Iu The Iu interface is for ATM PVCs only. No other type of ATM virtual circuits is supported. Gn The Gn interface supports IP PVCs (GTP messages over IP, over ATM or Ethernet). Iu--CS Signaling and bearer control --RNC to CN signaling messages must be relayed from the WG to the 3G--MSC. This messaging utilizes a form of SS7. The lowest protocol layer, MTP2, exists on the VSP--T in the media gateway. Hence messages must be relayed from the SG to the MG. Call control for establishing circuit bearer channels, which uses the ASPEN protocol, also requires messaging from the SG to the MG. The SG--to--MG messaging uses IP--PVCs, or IP messages over ATM. Iu--PS Messaging Internal messages are exchanged using ATM--SVCs between the following: " SG and USC " SC and USD " USC and MAP application " USC and billing application " USC and legal intercept " USD and legal intercept Aggreagation Node The aggregation node (AN) is a Passport 15K shelf that connects to every other shelf in the WG. It also connects to external networks that transport Iu and Gn traffic, as well as other traffic, potentially. While each shelf within a WG is limited to supporting only UMTS wireless--specific applications (for example, several SGs, a 3G--SGSN, and VMGs), the AN supports only Passport carrier data networks features. All multi--shelf communication is routed through the AN; this guarantees an upper bound on the latency of intershelf communication that might not be possible were a standard ATM network used to interconnect the shelves. All Iu and Gn traffic is routed through the AN. The AN allows the WG configuration to change internally, to add capacity or perform maintenance, without affecting the transport network or re--engineering network connectivity. The AN is a required node in the WG.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
125
Wireless Gateway hardware

This module gives a summary of the hardware components of the Passport 15000 platform functioning as a wireless gateway (WG). For additional information on the Passport hardware, refer to the following NTPs: -- 214--1501--200 Passport 15000 Hardware Description -- 214--1501--210 Passport 15000 Hardware Installation Guide-- 214--1501--215 Passport 15000 Hardware Maintenance Guide. Figure 45 Wireless Gateway hardware structure
Two shelves can be fittted into one cabinet. Each shelf has 16 slots for processing cards. Two types of card are provisioned in the WG: CP (Control Processor) FP (Functional Processor) Two slots are reserved for CP cards and 14 slots are available per shelf for FP cards. Different types of FP can be mixed in the shelf to achieve optimal WG configuration. Card summary and reliability The following table provides a summary of the WG hardware components and the applications that use them.
126
Card name CP3 4--port 0C3/STM--1 multi--mode ATM FP
Abbreviation CP3 OC3/STM1
PEC code See Note 2 NTHR 17DA
WG applications used by HLR SIM, OAM Signaling gateway, USD, Iu Link A,B,&C --shelf input/output (I/O), aggregation node Signaling gateway, USD, Iu link A,B,&C --shelf input/ output (I/O), aggregation node Media gateway Media gateway
MTBFs (hrs) See note 1 154,282 194,742
4--port OC3/STM--1 single--mode ATM FP
OC3/STM1
NTHR 21DA
194,742
Voice services processor --turbo 32 Port TDM to ATM functional processor cards General services processor
VSP--T
NTHW 87AA NTHW 92AA
96,096 (see Note 3) 435,372
2PGPDSK
NTHW 10AA
USC Billing Legal Intercept MAP Media gateway
154,282 (see Note 4)
Multi--port aggregate device (mux for TDM card) 16--Port OC3/STM--1 single mode ATM FP Fabric card Cooling unit controller Alarm BITS module
E3 RAD MULTIPLEXER DC 75 ohms
NT042 1AA NTHW 21AA
665,760
Aggregation node 526,316 7,352,228 9,708,738
Note 1: The values in this table represent the entire FP being unavailable for service. No analysis has yet been completed on the reliability of the WG or groups of its components (for example, the B shelf). Note 2: A CP3 is delivered as part of a 15K cabinet or shelf assembly and is typically not ordered separately; therefore, no PEC is presented here. Note 3: This card is not yet GA. The failure rate has been taken from the original analysis for the NTFN87AA, but an updated analysis is not expected to result in a change by more than 10%. Note 4: This FP is new. It is a modification of the existing CP3 FP and as such, the MTBF of that FP is assumed. However, values may change once the FP is GA and available for further analysis.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
127
Passport 1500 The WG is a UMTS application running on a Passport 15000, which is a 16-slot Passport node. The design of the 16--slot Passport platform provides an ideal software and hardware base for the WG. The design of the Passport is flexible and can be upgraded for smooth transition to future multimedia networks. Key components of this strategy include the following: Capability for both frame and cell switching Modularity in both software and hardware design A highly reliable multiprocessor architecture State--of--the--art fault--tolerant software The WG hardware consists of the following components: frame breaker interface panel shelf assembly cooling unit In this document, port refers to the part of a data processor that is dedicated to a single channel for the purpose of receiving data from or transmitting data to one or more remote devices. FP is the term used to encompass the processor card section. Node is used synonymously with shelf. Passport 15K dual node cabinet assembly with one 15K shelf This assembly is an E1--balanced, single shelf kit consisting of the following: 18--slot dc power shelf NEBS 2000 frame assembly cable mounting brackets power cable lower shelf BIP alarm cable assembly (lower shelf) two E1 BITS CP3 control processors two Fabric card alarm/BITS E1--balanced card cooling unit power cable assembly EBIP assembly with two breaker modules and two filler modules Passport 15000 shelf assembly cooling unit assembly (lower) two top shelf filler panels (1000 mm and 800 mm) power interface module MAC address module Zone 2 anchoring kit It can be ordered in either 75 or 120 OHMS.
128
Passport 15K shelf This component is an additional shelf ordered to fill in the upper half of a 15K cabinet assembly. It consists of an E1--balanced, upper--shelf upgrade kit, which includes the following: 18--slot dc power shelf power cable upper shelf two E1 BITS CP3 control processors two Fabric cards alarm/BITS E1 balanced card cooling unit power cable assembly two breaker modules Passport 15000 shelf assembly cooling unit assembly (upper) power interface module MAC address module Frame The SGSN installs easily in the lower portion of a 15K network equipment--building system (NEBS) 2000 frame assembly. Breaker interface panel The breaker interface panel (BIP) provides a central location where redundant input dc power feeds (nominal --48/--60 V) of up to 100 A are connected and routed to two or four breaker interface modules (BIMs). Power is distributed from the BIMs to the shelves and cooling units. Passport supports the use of either a two--BIM (single--shelf) or four--BIM (dual shelf) BIP. The BIP also contains an alarm module which monitors system components, generates alarms, and controls LED status indicators. Shelf assembly The NEBS 2000 frame supports two shelf assemblies: an upper and a lower. Each shelf assembly contains a separate Passport 15000. The shelf is divided into two card cages, located one above the other. The card cages house the function and processor cards that manage the node and provide interfaces for connection to high--speed data networks. The components that make up the shelf assembly allow the processor cards to perform as follows: Intercommunicate (across both card cages) Support alarm, timing, and node addressing Support the cooling fans which dissipate the heat generated by the Passport 15000 The shelf assembly can contain up to 16 function and control processors: A total of 14 function processors and two control processors Each processor card slides into its allocated shelf slot, labeled 0 to 15, where its connector engages with a connector on the backplane. Shelf slots are allocated as follows: Function processors can occupy any of slots 2 to 15 Control processors occupy slots 0 and 1 only
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
129
Ejector latches at the top and bottom of the front panel of each processor card secure it in place. A lock latch prevents tampering. Slots not occupied by a function or control processor are fitted with blank cards to ensure proper cooling of the node, and for electro--magnetic interference (EMI) protection and safety compliances. Blank cards are labeled Blank. Access to the function and control processors is from the front. The faceplate of each processor card contains connectors and an LED status indicator. A shelf assembly is made up of the following components: Control processor cards 4--port 0C3/STM--1 single--mode ATM function processor (FP) cards The 4--port 0C3/STM--1 single mode ATM FP can be used in the A, B, and C shelves of the WG for the Iu link application, for shelf interconnection and bearer plane connectivity. It can also be used in the aggregation node. Note: The 4--port OC3/STM--1 multi--mode ATM FP can also be used instead of the 4--port OC3/STM--1 single mode ATM FP. 4--port OC3/STM--1 multi--mode ATM function processor (FP) cards The 4--port 0C3/STM--1 multi--mode ATM FP can be used for the SG, the USD, A, B, and C shelves of the WG for the Iu Link application, for shelf interconnection and bearer plane connectivity. It can also be used in the aggregation node. Note: The 4--port OC3/STM--1 single mode ATM FP can also be used instead of the 4--port OC3/STM--1 multi--mode ATM FP. 16--port OC3/STM--1 single--mode ATM function processor (FP) cards The 16--Port OC3/STM--1 single mode ATM FP can be used in the aggregation node to connect to all of the of other WG shelves. It supports 1--to--1 redundancy. Note: An attenuator is needed between the aggregation node and the WG nodes. Additional numbers of this FP can be used to connect to the ATM network external to the WG for the Gn and/or Iu interface. VSP--T cards The VSP--T card used is supported only on the Passport 15000 shelf. It has 2 SPMs and 10 VPM daughter modules. It is used to perform the transcoding and rate adaptation (TRAU) function within the core network. The VSP--T and the 32 Port TDM interface card logically make up a media gateway function within the WG. 32 Port TDM processor cards This FP provides a TDM interface between the wireless gateway and the 3G--MSC for circuit bearer plane traffic and for an SS7 interface for signaling messages. Multiport aggregate device The multiplexer is integrated with the Passport shelf and demultiplexes the E3 interface of the 32 Port TDM card to 32 E1 interfaces.
130
General services processor (2PGPDSK) cards An SP module PPC 512MB 12GHD ETHERNET. This processor can be used for the USC, MAP, call intercept, or billing applications of the 3G--SGSN. It is the same FP used in the GPRS SGSN. Common backplane The backplane is located at the rear of the shelf assembly between the processor cards and the Fabrics. The backplane spans both card cages and extends over the full height and width of the shelf. The backplane is a 20--layer printed circuit board containing 8 signal layers and 12 power/ground layers and is located between the processor cards and the Fabrics. Each processor card connects to the backplane with four Z--PACK connectors with a total of 658 pins per processor card slot, plus additional pins for the Fabric card, MAC address module, alarm/BITS module, and the power interface modules (PIMs). The backplane is referred to as the common backplane because it is the point across which all processor cards and Fabric cards in a shelf intercommunicate. The backplane provides redundant 3.52 Gbit/s serial links between the processor cards and the Fabric cards to support power and signal distribution. The high--speed lines on the backplane have a nominal impedance of 50 ohm and 100 ohm differential to reduce signal ringing and reflections caused by impedance mismatches. The serial link architecture of the backplane allows for hot--swapping packs by isolating each card to a single Fabric port, preventing card failures from propagating through the switching Fabric. The backplane also provides links between adjacent FPs for functions such as sparing, clock distribution, and distribution of --48/--60 V dc. The Passport 15000 backplane is the point across which all processor cards and Fabric cards in a shelf intercommunicate. The backplane can function in dual-- or single--Fabric mode. Dual--Fabric mode is the standard mode used by the Passport 15000. Fabric cards The Fabric cards are located at the rear of the Passport 15000 shelf assembly. Each shelf contains two Fabric cards enclosed in a carrier module. These cards are located one above the other at the rear of the shelf assembly. The upper and lower Fabric cards are rotated 180 degrees relative to each other to minimize serial link lengths. Each Fabric is an individual switch embedded in a chip set. Each card consists of a 254 mm tall by 406 mm wide PCB module. It provides 16 input ports and 16 output ports. A single Fabric provides 3.52 Gbit/s bandwidth for each input and output port, for a total throughput of 56.3 Gbit/s. The Fabrics provide eight high--speed serial links for each input and output port, with each line operating at 440 Mbit/s. The Fabric cards provide the shelf with two redundant 16x16 switching elements for interconnecting up to 16 processor cards. Both Fabrics are used to carry traffic, although a single Fabric can handle all traffic carried by a fully provisioned and configured Passport 8380 G. Under normal circumstances, each processor card transmits to and receives from half the processors on the upper Fabric (usually labeled the X Fabric) and half on the lower Fabric (the Y Fabric). Power interface modules (PIMs) Four power interface modules (PIMs) are located along the left side of the rear of the Passport 15000 shelf assembly. Each PIM provides a point at which power cables from the BIP are connected. Each shelf assembly contains four PIMs: two for A power feeds and two for B feeds. Each PIM provides separate power filtering for the portions of the shelf it supports. The PIMs also provide termination for the shelf clocks and for the secondary control bus.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
131
Media access control (MAC) address module The media access control (MAC) address module is located on the left side of the rear of the Passport 15000 shelf assembly, between the two Fabric cards and between the PIMs of the upper and lower module cage. The MAC address module is a field--replaceable unit (FRU) that provides the shelf with media access control (MAC) addresses for the control and function processors. The MAC address module contains a circuit board with an 87C51 8--bit micro controller and a Z--PACK connector used to provide an interface to the shelf backplane. The module contains the base MAC address and the range of MAC addresses available for assignment (based on the base address value). During the Passport boot sequence, the control processor takes the range stored in the MAC address module, divides this value by the number of functional processors, and distributes to each functional processor a base value and range. Alarm/BITS module The alarm/BITS module is located at the right side of the rear of the Passportn15000 shelf assembly, between the upper and lower Fabric modules. The alarm/BITS module is a field--replaceable unit (FRU) which terminates cables carrying alarm signals (from the cooling unit and BIP), and BITS signals, and passes the information over the shelf backplane to the control processors and expansion slots. The alarm/BITS module contains the following connectors: -- BITS ports -- Cooling unit alarm connector -- BIP alarm connector Cooling unit The Passport NEBS 2000 frame has two cooling units located in the middle of the frame, between the upper and lower shelf assemblies. The upper cooling unit pushes air from the fan under the modules in the upper shelf assembly and out through the exhaust plenum under the BIP. The lower cooling unit pulls air in from the bottom of the frame, over the modules in the lower shelf assembly and out through the fan assembly. Each cooling unit consists of three fans and a cooling unit backplane located in a common shelf. Each cooling unit is controlled by temperature sensors located in the shelf assembly. Passport uses forced air for cooling internal assemblies. The intake draws air from both the base and front of the frame, and forces it vertically through the shelf where it exhausts to the rear of frame at the cable management section. The NEBS 2000 frame is also equipped with air filters to prevent dust and other airborne contaminants from being drawn into the shelf assemblies by the cooling units. Each cooling unit is equipped with LEDs to indicate the units status. The following table lists the possible LED displays. LED color Green light on Red light on Description Unit on, no fault detected Fan fault, missing fan or temperature sensor detected. A FANFAIL signal is sent to the alarm/ BITS module, and the remaining fans are switched to the high speed setting.
132
GGSN introduction
The Gateway GPRS Support Node (GGSN) functionality is common between GPRS and Universal Mobile Telecommunication System (UMTS) networks. The GGSN is the element defined the GPRS/UMTS system to provide interconnection between the GPRS/UMTS IP backbone network and the external packet data network. The GGSN is the single interconnection point between the Public Land Mobile Network (PLMN) and a particular Packet Data Network (PDN), which can be an Internet Service Provider (ISP) or a Corporate Intranet. Accordingly, a GGSN maintains a one-to-many relationship with Serving GPRS Support Node (SGSNs), which may be in either the Home Public Land Mobile Network (HPLMN) or the Visiting Public Land Mobile Network (VPLMN) for roaming subscribers. The GGSN is primarily responsible for packet routing and controlling access to the public data network (PDN), which includes the following general functions: Routing Tunneling Security Mobile subscriber user authentication IP address allocation GGSN accounting The GPRS/UMTS specifications clearly define interfaces between network elements and reference points on the external system. The following figure shows the various components connected to the GGSN to provide the GGSN functionality.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
133
Figure 46 Connectivity to GGSN
The Nortel Networks GGSN for the UMTS01 release is the Shasta GGSN. It is made of: Shasta 5000 BSN Service Creation System (SCS) server and client The Shasta 5000 BSN provides the packet processing functionality for the GGSN. The SCS server and client are used for configuring the Shasta 5000 BSN.
134
GGSN interfaces
The following is a list of the GGSN interfaces that are defined by the standards: Ga This is the interface between GGSN and CGF (Charging Gateway Function) for billing. Gc This is the interface between GGSN and HLR used for network-initiated calls. Gi This is the interface between GGSN and an external PDN. Gn This is the interface between GGSN and SGSN. Gp This is the interface between GGSN and a VPLMNs SGSN.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
135
GGSN features and functions

The Gateway GPRS Support Node (GGSN) functionality is added to the Shasta 5000 BSN to allow use of the existing set of Shasta 5000 BSN features. GPRS Tunneling Protocol (GTP) and other wireless--specific functionality such as Access Point Name (APN) and GGSN accounting are added to the Shasta 5000 BSN. The following new functionality is added to the Shasta 5000 BSN for the Shasta GGSN: GTP (Version 0 and Version 1) IP and Point--to--Point Protocol (PPP) Protocol Data Unit (PDU) type over GTP GTP--L2TP tunnel switching (L2TP over IPSec is optional) for PPP PDU type ONLY GTP--IPSec APN configuration Mobile subscriber user authentication (including anonymous mode) via RADIUS GGSN accounting (GTP protocol) GGSN Operations, Administration, and Maintenance (OA&M) (includes statistics, logs, GTP active session management) Wireless services (Tariff and Wireless Application Protocol (WAP) services) To support the functionality listed above, the Shasta GGSN must interwork with different components within the PLMN and/or the public data network. The following figure summarizes the supported protocols for interworking with different external components with the Shasta GGSN.
136
Figure 47 Summary of Shasta GGSN interworking components
GTP protocol One of the main functions of the GGSN is to provide routing and tunneling functionality for the PLMN. To provide the routing and tunneling capability, a GTP tunnel is established between the GGSN and other GSNs within the same or another PLMN. The GTP tunnel implements the GTP protocol. Shasta GGSN supports GTP Version 0 defined in GSM 09.60, ver. 7.5.0 and Version 1 defined in 3G TS 29.060 for both PPP and IP PDU types. Shasta GGSN supports up to 16 primary (GTP V0) PDP contexts per mobile subscriber. Each individual PDP context has its own IP address. Shasta GGSN supports the mobile initiated PDP Context Activation procedure only.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
137
Figure 48 GTP architecture
Tunneling on the Gi interface Tunneling on the Gi interface is supported to facilitate Corporate Access for mobile subscribers to a private Intranet. This access type provides more security for the subscribers data traffic. The Shasta GGSN supports the following types of outbound tunneling on the Gi interface: L2TP tunnel L2TP over IPSec (optional)
138
IPSec tunnel APN configuration The Access Point Name (APN) is used to identify the data session requested by the mobile subscriber for a specific GTP session establishment. When a Create PDP Context Request is received on the Shasta GGSN, the APN is specified within the message. Using the APN requested by the subscriber, the subscriber information is retrieved from the configuration database. From the APN received within the Create PDP Context Request, the following information can be determined: mobile subscriber user authentication (if required) the method of subscriber authentication (if required) the method of IP address allocation if subscription is required for the GTP session GGSN accounting information (such as interim accounting time/volume limit and/or if hot billing is required) Wireless services the subscriber is subscribed to, such as tariff or application services Outbound tunneling (if required) IP services (if applied) Mobile subscriber user authentication Shasta--GGSN supports normal user authentication and anonymous mode userauthentication when operating in non--transparent mode. Anonymous mode user authentication is supported for a GTP tunnel with IP PDU type ONLY. Anonymous mode user authentication can be specified for an individual APN. When a Create PDP Context Request of IP PDU type without the Protocol Configuration Options (PCO) optional IE is received for an APN that allows anonymous mode user authentication, then the actual MSISDN is used as the User Name and umts is used as the Password for the user authentication with RADIUS. Otherwise, the User Name and Password information is obtained from the PCO IE in the Create PDP Context Request. If Authentication is required for an APN that does not allow anonymous mode authentication, and the PCO IE is not included in the Create PDP Context Request, the Create PDP Context Request is rejected and the GTP tunnel is not set up. The following authentication service is supported on the Shasta GGSN: RADIUS authentication IP address allocation The following IP address allocation methods are supported by the Shasta GGSN: RADIUS (Static IP address allocation if using RADIUS authentication.) Local IP address pools (Dynamic IP address allocation) IP address as specified in the Create PDP Context Request (Static IP address allocation via Home Location Registry (HLR)) Overlapping private IP addresses are supported for the Direct Tunneled Virtual Private Network model since a each VPN uses its own routing table. GGSN accounting
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
139
GGSN specific accounting is supported by the Shasta GGSN. The accounting procedure and the protocol used for GGSN accounting is specified in the GPRS specification defined in 3G TS 32.015, ver. 3.2.0, Charging and Billing. The GTP protocol is used for transferring the GGSN accounting record (G--CDR) from the GGSN to the Charging Gateway Function (CGF). The GGSN is the anchor of the GPRS/UMTS data call and has most of the information contained in the PDP context. The GGSN is responsible for collecting charging information related to the external data network usage and charging information on usage of the GPRS network resources related to the GGSN. Packet data volume in both uplink and downlink directions is counted separately. GTP on Shasta GGSN supports both GTP Version 0 and Version 1 header formats with a fallback mechanism of falling back from GTP Version 1 to GTP Version 0. For the Shasta GGSN, 2 CGFs can be configured per GGSN. The primary CGF is used for normal accounting record transfer. The secondary CGF is used only when the primary CGF is not accessible. If both CGFs are not accessible, the accounting records are stored on the Shasta GGSN local disk. If the local disk is full, new accounting records are dropped. Accounting cannot be turned off; billing records are continuously created. If there is not a CGF connected, then the records are sent to disk and the operator must periodically delete billing records to prevent disk overflow. Two streams of accounting are supported on the Shasta GGSN: Regular billing Hot billing (the Hot billing option allows the transfer of the GGSN billing records from the GGSN to the CGF when the record is generated) The accounting stream to use on the GGSN for a specific APN is configured by the SCS. For prepaid subscribers, the billing is tracked by the Service Control Point (SCP) and the accounting record generated by the GGSN indicates that the subscriber has prepaid service active. The CGF and the downstream processor should take appropriate action to prevent duplicate billing for the prepaid subscribers. OA&M The Shasta GGSN supports statistics and logs for Operations, Administration, and Maintenance (OA&M) purposes. The Shasta GGSN uses a modified version of the existing Shasta 5000 BSN OA&M system to support GGSN specific statistics. The Service Creation System (SCS) is used for Shasta GGSN configuration, policy and profile creation, subscriber provisioning, monitoring and troubleshooting. The SCS is based on a distributed client/server architecture that supports multiple concurrent users. Services The Shasta GGSN supports Prepaid and GeoZone GPRS Tariffing service (based on Nortel Networks implementation) and interworks with the Service Control Point (SCP) and the Wireless Application Protocol (WAP) gateway and other servers.
140
SCP/Application server addresses are configurable through SCS for a specific APN. For subscribers that have prepaid service and/or tariff service configured through the SCS, the specific service information is captured in the GGSN accounting record. The CGF is responsible for processing the services records accordingly. For prepaid service, the SCP keeps track of the service being used, the GGSN accounting records are captured for information only, and the CGF is responsible for ensuring that the subscriber is not billed twice. Prepaid services Prepaid service is one of the tariffing services supported by the Shasta GGSN. The prepaid service allows users to pay for services in advance. As the user consumes the services, the GPRS/UMTS system keeps track of resources used and deducts charges from the user s account. The user can purchase PDP context time or packet volume in advance. GeoZone service The GeoZone service is another tariffing service supported on the Shasta GGSN. It allows different tariffing based on where (geographically) the subscriber originates the PDP context. This is indicated in the Global Cellid (Nortel Networks extension optional IE) of the Create PDP Context request message. Wireless application services Shasta GGSN supports Wireless Application Protocol (WAP) service by communicating with the Application server through the Wireless RADIUS Application Protocol (WRAP). IP services IP services on the Shasta--GGSN apply only to the subscriber data traffic on the Gi interface. The following Shasta 5000 BSN IP Services are applicable to the Shasta--GGSN: " Policing The purpose of a traffic policing policy is to restrict the data throughput coming from the subscriber side (that is, coming from the Gn interface, going out to the Gi interface). It protects the network from traffic in excess of the subscriber s contracted rate. The policing function relies on the results of the DiffServ marking in conjunction with bandwidth limits to set different drop priorities. " Traffic Shaping Traffic shaping allows overall rate limits and per connection rate limits to be applied to traffic coming from the Internet to the subscriber (from the Gi interface). A traffic shaping policy is a set of rules that are defined on a per--flow basis. A flow is defined by a source address, destination address and service type. " Policy Based Forwarding Policy based forwarding allows traffic from the subscriber (that is, from the Gn interface) to be redirected based on a set of policies or rules. It essentially just forwards packets of matching conversations (flows) out the interface chosen by performing a route lookup on the IP address specified in the matching rules action. The destination of the packet must be only a single hop away from the current location where the packet is being forwarded. Defining a policy based forwarding policy requires specifying a flow (defined by a source address, destination address and service type), and then specifying an action for that flow type. The action can be either default (do nothing) or steering, which then requires a forwarding IP address to be defined.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
141
" Personal network portals A personal network portal (PNP) intercepts a subscriber s HTTP request and redirects the subscriber to a URL on the Personal Network Portal web site. " DiffServ Marking DiffServ Marking can be used in both directions, that is, out both the Gi and Gn interfaces. However, since the IP packet is encapsulated within a GTP tunnel on the Gn interface, Egress DiffServ Marking would essentially be useless. DiffServ is a shortened version of Differentiated Services. Differentiated Services allows scalable service differentiation within a network. DiffServ marking refers to marking the IP packets to provide different classes of service. There are four AF classes -- 1 (worst) to 4 (best) -- which describe the relative priority of the traffic. Within each AF class, there are three different levels of drop precedence (DP) -- 1 (best) to 3 (worst) -- which define how likely the traffic is to be discarded if the network experiences congestion or if the subscriber exceeds the traffic contract. Therefore, DiffServ marking can provide 12 different classes of service. It is also possible to alias an IP packet to have a certain DiffServ marking; this allows the packet to be treated as if it had a certain marking without actually changing the contents of the IP header.
142
GGSN hardware structure

The following hardware components are required to provide the basic GGSN functionality: Shasta 5000 BSN Service Creation System (SCS) Server and Client The Shasta 5000 BSN provides the packet processing functionality for the GGSN. The SCS server and client are used for configuring the Shasta 5000 BSN. A single SCS server and client can be used to provision multiple Shasta 5000 BSNs in the customer network. To support GGSN functionality, the software loads with GGSN functionality are required for both SCS and Shasta 5000 BSN hardware platforms. The following external components can provide additional services or alternatives to basic functionality when working with the Shasta GGSN: Charging Gateway Function (CGF) RADIUS Server Application Server Tariff Server
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
143
Figure 49 Shasta-GGSN
Shasta 5000 BSN hardware description The Shasta GGSN functionality is supported on the Shasta 5000 BSN without any hardware modifications. Only a subset of the hardware supported by the Shasta 5000 BSN is supported in the Shasta GGSN configuration. A Shasta 5000 BSN shelf consists of the following cards: Switch Fabric Card (SFC) -- provides ATM interconnect and queuing between cards Control and Management Card (CMC) -- responsible for system management functions Subscriber Service Card (SSC) -- delivers scalable processing for high touch services Line Cards -- provides physical connectivity into and out of the shelf The following cards are supported on the Shasta GGSN: SFC: 10 Gbps Switch Fabric (NTJT20CA) CMC: 1 GByte (NTJT22DA) SSCII (with 4 SSM and 3DES) (NTJT29BB)
144
Physical connectivity The Shasta GGSN supports the following line cards as physical interfaces on the Gn, Gp and Gi interfaces: 4 port ATM STM--1/OC--3 (NTJT30AA/NTJT30BA) 8 port Fast Ethernet (NTJT36CA) The Shasta GGSN also supports the following interface on the Management Ethernet ports: 2 port 10/100 BaseT Ethernet on CMC card SCS server/client For more information about the SCS server and client hardware requirements, refer to Nortel Networks Shasta 5000 Broadband Service Node Service Creation System Installation Guide, Version 2.5 (part number 01446--01).
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
145
GGSN configuration
The recommended configuration for the Shasta GGSN consists of the following components: 2 Shasta 5000 BSNs (for packet processing) 1 SCS server and client (for GGSN configuration) The recommended Shasta GGSN configuration is: 1 Shasta 5000 BSN Chassis 2 CMCs (1 GBytes) 2 SFCs (10 GBytes) 6 SSCs with 4 SSMII each 2 or more lines on each interface (Gn and Gi interface)
146
MSC introduction
The UMTS01 MSC of Nortel Networks is the UMTS DMS/MSC or 3G--MSC Call Server (CS). The Call Server (CS) performs all of the switching functions needed for the user equipment located in its geographical area. The UMTS01 Call Server is a XA Core--based switching architecture packaged to support the switching functions required for mobile stations located in an associated geographical area, called the UMTS PLMN. The CS takes into account the mobile nature of the subscriber which includes: authentication ciphering location register updating It also allows mobile subscriber interworking to the public network. The following figure summarizes the Nortel Networks Circuit Core Networks (CCN) products available for UMTS. Figure 50 UMTS Circuit Core Network products for UMTS
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
147
3G- MSC/Call Server features and functions

The Call Server supports the switching functions required for mobile stations located in the UMTS PLMN. The major functions of the CS are: CS mobile call handling The CS performs switching functions for all Mobile Stations (MS) located in its geographical area. This area is known as the Serving Area. The following figure gives an example of CS serving area. Figure 51 Serving area of a CS
148
The CS switching functions occur between Mobile Subscribers in a PLMN or between Mobile Subscribers and telephones and services in the Public Switched Telephone Network (PSTN) or Integrated Services Digital Network (ISDN). To perform its switching and call processing functions, the CS interacts with other nodes in the PLMN and with land networks. The CS mobile call handling provides: " Mobile Subscriber call establishment, re--establishment, and routing " Dialed digits Translations " Call Control and signaling " Data Call handling " Management of procedures for calls " Locating and contacting Mobile Stations for call termination " Handover of call from one cell to another " Support of inter--PLMN roaming " Echo control Billing data capture, formatting, and teleprocessing CS captures and formats billing data for mobile originated and mobile terminated calls. The billing data is stored on the Billing Server and is transferred to a downstream processor using the File Transfer, Access and Management (FTAM) protocol. The Billing Server relieves the CCNCCN--core processors from storing and teleprocessing billing data. The CS provides partial billing capabilities for long--duration calls. By recording data on the call at pre--determined intervals, the CS limits the maximum billable time lost to the established interval. Authentication and Ciphering The CS performs steps in the Authentication process, which prevents unregistered users from accessing the PLMN. In the Authentication process, the CS communicates with the VLR and the Mobile Station. The Authentication process also involves the Authentication Center (AUC), which is co--located with the Home Location Register (HLR). Ciphering is used for the transmission of user data or of confidential network parameters, and for ensuring privacy. CS Supplementary Services A supplementary service modifies or supplements basic telecommunication services. It cannot be offered to a subscriber as a stand--alone product. The CS supports the following Supplementary Services: " Number Identification " Call Offering " Call Completion " Multi--party calling " Charging " Call Restriction " Call Independent Supplementary Services " Local Number Portability " Proprietary services
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
149
Gateway CS functions In addition to hosting a Visitor Location Register, any CS in a PLMN may be designated as a Gateway Call Server (GMSC). A GCS is capable of interrogating a Mobile Subscriber s HLR to obtain the information required to terminate calls to that Mobile Subscriber. A GMSC may serve as an interface between PLMNs or between a PLMN and a PSTN. CS external interfaces The CS interfaces with the following entities: " other nodes, including the VLR, CCN HLR, Equipment Identity Register (EIR), and SMS--SC " the Radio Network Subsystem " other CSs " the Public Switched Telephone Network " the Interworking Function (IWF) unit " the ISDN Primary Rate Interface (PRI)
150
3G- MSC/Call Server software

The CS software is developed on the Communications Software Products (CSP) architectural layer suitable for deployment to all UMTS markets. The CS Software is broken into a number of discrete functional units, each of which provides for the operation of different functions within the CS. The functions are: UMTS Interfaces Call Processing/Protocol Interworking Mobility Procedures Data Services Supplementary Services Short Message Service PSTN Interworking Visitor Location Register Intelligent Networking
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
151
3G- MSC Call Server hardware

The UMTS01 Call Server uses the DMS--MSC XA--Core with a SuperNode cabinet base for its hardware platform. XA--Core (eXtended Architecture Core) is designed as a next generation replacement for the computing module (CM) and system load module (SLM) within MSC systems. XA--Core is designed as a direct replacement for the CM/SLM and, as such, fits cleanly into the CCN architecture. In order to allow a clean fit into existing MSC frames, XA--Core is incorporated into a single shelf of the same height and form--factor as existing MSC shelves. To allow circuit packs to fit into both front and rear slots, a midplane shelf design has been adopted that provides for 18 slots in the front and 14 slots in the rear. In the SuperNode--XA configuration, the CM and SLM shelves are replaced with one XA--Core shelf. XA--Core is comprised of a single shelf containing the following three types of cards (referred to as packs): processor element (PE) input/output processor (IOP) packs shared memory (SM) packs Together, these packs form a high--performance, multiprocessing compute engine that is completely scalable in terms of processing, memory, and I/O capability. Adjusting the capacity of the system or adding another interface is as simple as plugging in a new pack. The operation of XA--Core is based on multiple packs (PE packs and IOP packs) operating on a single, large, shared memory system. This memory system, comprised of multiple shared memory (SM) packs and simply referred to as shared memory contains all data store for XA--Core, while all program store is stored locally in cache on every processor pack. As with all multiprocessing systems, the trick is to choose an efficient method of dividing up the work load among processors such that real gains in processing capacity can be realized. In addition, XA--Core was challenged with the need to have most legacy application software run without modification. To achieve this, XA--Core divides up the work load based on processes. Fundamentally, when a processor becomes free, it runs the scheduler to get the next process waiting to run, and then executes it until swapped out by the scheduler. To meet the demands that the XA--Core architecture places on inter--card connectivity, a point--to--point midplane technology called eXtended Architecture Interconnect (XAI) is employed. As shown in the following figure , XAI provides individual point--to--point connections between PE packs and IOP packs via the SM packs. All transmit links out of a PE or IOP are monitored by all SM packs, and all return links (transmit out of the SM) are monitored by all PE and IOP packs. An address field in every transaction allows each pack to determine if that transaction is destined for it or not. All links are bit--serial, gigabit links with non--contact connections at the receive ports. This allows packs to be live--inserted, and also prevents a failed receive port from potentially disabling a link that is still being shared by other packs.
152
PE pack The PE pack is based on the PowerPC series of microprocessors. Instead of having two processor cards running in lock--step sync (as in SuperNode), XA--Core uses a variable number of processor packs with each one executing completely independently. Fault detection on the PE pack is provided by running two processors in sync on each PE pack and matching all bus transactions. A symmetric multiprocessing architecture was chosen, meaning that there is no permanently assigned master PE pack. All PE packs are treated identically such that any PE pack can and does run all code. As long as at least one PE pack is operating without a fault, the system will operate. SM pack The SM pack provides for the mutual exclusion of data necessary to allow multiple processors to execute simultaneously. This mutual exclusion is based on the concept of ownership of data. Once a PE accesses a piece of data, it owns that data until it is done with it. If a second processor attempts to access that data before it has been released by the first, the shared memory pack will send a collision notification to the second processor, telling it to terminate the data access. This blocking will cause the second processor to abort its execution and notify shared memory to return all of the data changed by the aborted task to their previous values. This is termed a process rollback. The processor then re--runs the scheduler so that it can be attempted later. XA-Core input/output (I/O) XA--Core input/output (I/O) and mass storage requirements are addressed with a generic IOP pack and a set of small daughter cards (termed packlets) that insert into the IOP pack. Each packlet provides some type of I/O or storage service, and each IOP pack can accept up to two packlets. Services are provided by population XA--Core with an appropriate number or IOP packs and, in turn, populating each IOP pack with the required packlets. The following packlets are available: SCSI tape (transportable mass storage) SCSI disk (non--transportable mass storage) RS--232C/422 reset terminal interface (RTIF) link OC--3 core to message switch interconnect (CMIC) link Data transfers Most data transfers between PE packs and IOP packs will take place via queues in shared memory. Because IOP packs do not have matched processors like PE packs do, they do not have the fault detection required to be allowed to access shared memory unchecked. To provide the necessary protection, IOP packs are only allowed to write to special areas in shared memory called staging areas. These areas are set up specifically to provide a region in which to locate queues that need to be written into by the IOP. Any IOP write access outside of these areas will be faulted. This restriction does not apply to read accesses, so IOP packs are allowed global read access to any data they may need.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
153
Figure 52 XA-Core Multiprocessor Architecture with XAI Midplane+
154
HLR introduction
The Home Location Register (HLR) is a database that contains permanent subscriber data, such as provisioning and service information, and dynamic information, such as the UEs current location, which it gets from the VLR. The HLR is a UMTS users home base of information that is to say, it is the database to query for information about an instance of UE, regardless of that UEs current geographical location. The HLR supports call routing and controls Supplementary Services. The UMTS01 HLR of Nortel Networks is the UMTS DMS/HLR.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
155
HLR features and functions

The HLR is a database that holds information about User Equipment (UE). The HLR performs the following functions: Handles permanent data (identification, subscription information, service limitation) of subscribers Handles temporary subscriber data: " current VLR and SGSN addresses where the UE roams " security information Dialogue with the Authentication Center (AuC) database The HLR supports the following functions: Application Context Negotiation support The HLR supports Mobile Application Part (MAP) Application Context (AC) negotiations. Application Context negotiation allows the highest supported AC version to be used in a mixed--phase Public Land Mobile Network (PLMN). This allows the HLR to negotiate with another entity, such as a VLR, in a Public Land Mobile Network (PLMN) to determine the highest common version of an AC supported by both entities. Call Routing Support The HLR supports call routing to user equipment by providing the CCN CS with information about the whereabouts of the user equipment. In order to do this, HLR interacts frequently with the different Visitor Location Registers (VLRs) where the user equipment are currently located. HLR then provides CCN CS with this information. Equal Access Support For the North American marketplace, the HLR provides support for Equal Access. Equal Access is defined as the ability of a user to choose an interexchange carrier (IC/INC) for call attempts that do not terminate on their network or within a local exchange network directly connected to their network. Intelligent Network Support HLR incorporates proprietary extensions to support the implementation of Intelligent Network (IN) support at the CCN CS. Home Subscriber Trace (HST) Support The Home Subscriber Trace monitors the effectiveness of a new network, ensures all the features are operating correctly, assesses the usage of features such as call forwarding, and ensures that subscribers are not misusing the network. The HLR keeps a record of which subscribers have Home Subscriber Tracing activated in its database. MAP Messages are used to activate and deactivate tracing at the subscriber s current VLR while they are in the HPLMN. Inter--PLMN Roaming Support HLR supports user equipment in roaming to other Public Land Mobile Networks (PLMNs), both within and outside of the home country of the user equipment. This allows user equipment to receive incoming and place outgoing calls while outside of the home PLMN. HLR offers the flexibility of a Roaming Restriction mechanism that allows the HLR operator to specify, on a per--subscriber basis, exactly to which VLR areas and PLMNs a UE can and cannot roam.
156
HLR uses a Service Screening mechanism to control the level of services available to a UE. Service Screening can either prevent a UE from roaming to a PLMN that does not support particular services, or restrict particular services while the UE roams. Service Screening details are determined by the HLR operator. Dual International Mobile Subscriber Identity (IMSI) Support Support for Alias IMSIs allows each Subscriber to be identified by one IMSI and one Alias IMSI. This functionality provides support for markets where user equipment need two methods of identification. Identification methods may be either as part of their Home Network via their IMSI, or part of some Partner Network via an Alias--IMSI. The Subscriber Identity Module (SIM) card in the user equipment automatically switches between the two IMSIs based on the current location of the user equipment. Call Intercept Support Call Interception support capabilities on the HLR are implemented in accordance with the Communications Assistance for Law Enforcements Agencies act (CALEA). This functionality is only available and applicable in the North American market Region. Call Intercept System (CIS) is the Nortel Networks term for the components that specifically provide national security agencies or the service provider (on request from the security agency) to monitor and intercept calls involving target UE. Supplementary services support The HLR provisions, controls, and manages Supplementary Services information. All Supplementary Services are provisioned through the HLR, which stores Supplementary Services information of the UE, determines its applicability to calls, and manages interaction among the different Supplementary Services. The HLR allows Supplementary Services to be provisioned against individuals (IMSIs) and against Basic Service Groups. Short Messages Service support Short Message Service (SMS) is a service that provides the means of sending messages of a limited size to and from user equipment. The HLR supports Mobile--Terminated and Mobile--Originated SMS. For Mobile--Terminated SMS, HLR provides the Short Message Service Gateway Mobile--services Switching Center with routing information for user equipment so that a short message may be dispatched to that user equipment. For Mobile--Originated SMS, the HLR is responsible for the provisioning and de--provisioning of the service and propagating the subscription changes to the VLR. Mobile--originated and mobile--terminated data services support HLR supports Mobile--originated and Mobile--terminated data services, which are provisioned at the HLR. The UE may have more than one Bearer Service or Teleservice provisioned. Mobile--originated General Packet Radio Service (GPRS) Tunneling Protocol (GTP) Support In GPRS, GTP tunnels are built between the SGSN and the GGSN. In UMTS, the GTP tunnel is extended to the RNC. The GTP Control Plane which sets up, modifies, and clears GTP tunnels, is replaced on the Iu interface by RANAP procedures. All UMTS user--related information to perform routing and data transfer is stored in the Home Location Register (HLR). The HLR stores the routing information and maps the International Mobile Subscriber Identity (IMSI) to one or more Packet Data Protocols (PDP). The Gr Interface connects the 3G SGSN and the HLR.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
157
HLR Extensible Quality of Service (Ext QoS) data services support The Extensible Quality of Service (Ext--QoS) is a set of parameters provisioned at the Home Location register (HLR) as per Packet Data Protocol (PDP) context and provided to the Third Generation Serving GSN Support Node (3G SGSN) through the Insert Subscriber Data (ISD) message. The Update GTP Location (UGL) message, sent from the 3G SGSN to the HLR, includes an optional enhancement support indicator parameter that indicates if the 3G SGSN supports Ext--QoS. If this parameter is received, the Ext--QoS data is sent as part of the PDP contexts. The maximum number of PDPs for each subscriber is increased from a maximum of 5 to 20. Ext--QoS data is mandatory for UMTS Third Generation (3G) subscribers. Charging characteristics support Table GHLRPDP contains data relating to the PDP: " The PDP charging characteristic is stored as part of the PDP context and sent to the 3 GSGSN as part of the ISD message. The charging characteristic parameter is optional for 3G subscribers. The possible charging characteristic values are as follows: " Normal charging " Prepaid charging " Charging by hot billing " Flat rate charging HLR Extended Architecture Core (XA--Core) Support The XA--Core allows a greater number of active subscribers on the HLR. The HLR functions on the multiprocessor XA--Core platform with the new monitoring CAPACITY tool, replacing the old HLRCAP tool.
158
HLR interfaces
The HLR provides the network with facilities for examining permanent data and examining and modifying temporary data. HLR handles transactions with the CS and nodes, which either request information from the HLR, or update the information currently held in HLR. HLR also initiates transactions with the VLR to complete incoming calls and update subscriber data. Network nodes, including HLR, use Mobile Application Part (MAP) interfaces to communicate. The HLR--to--SGSN interface is the Gr--Interface. The HLR--to--CS interface is the C--Interface. The HLR--to--VLR interface is the D--Interface. The HLR--to--AUC interface is proprietary. The HLR--to--Maintenance and Administration Position interface is the Administrative interface.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
159
HLR hardware
The base of HLR hardware consists of either XA--Core or XA--Core SE, depending on the configuration. HLR cabinets HLR hardware is implemented in unified steel structure cabinets. The top of the cabinet contains a Frame Supervisory Panel (FSP), which is used for alarm monitoring and reset control for power converters. The bottom of the cabinet contains the integral cooling unit (for applications that require cooling), which provides forced air ventilation for the cabinet. Inter--cabinet cabling can be routed within the electromagnetic interference (EMI) shield horizontally between the cabinets. The cabinets have two center--open doors in the back and front. " Cabinet dimensions All HLR cabinets are 1829 mm (72 inches) high and support four shelves that are each 330 mm (13 inches) high and 660 mm (26 inches) deep. The cabinets are one of two different widths, depending on the cabinet: " Dual Plane Combined Core (DPCC), Enhanced Network (ENET), and Link Peripheral Processor (LPP) cabinets are 1067 mm (42 inches) wide. " Cabinetized Trunk Mobile Equipment (CTME), Cabinetized Input/Output Equipment (CIOE), and Cabinetized Power Distributed Center (CPDC) cabinets are 711 mm (28 inches) wide. The following figure shows the basic layout of both cabinet sizes. Figure 53 HLR basic cabinets
160
HLR with CCN XA--Core base HLR includes the following equipment when CCN XA--Core is the base: " CCN core, which resides in the Dual--plane combined core cabinet " CCN bus (message switch), which resides in the DPCC cabinet " Enhanced Network, which resides in the ENET cabinet " Link Peripheral Processor, which resides in the LPP cabinet Equipment common to all HLRs The HLR equipment, which is included with HLR regardless of whether it is based on CCN XA--Core or CCN XA--Core SE is the following: " The Cabinetized Trunk Module Equipment (CTME) cabinet contains maintenance trunk modules configured as Office Alarm Units. " Input/output equipment, including the Cabinetized Input/Output Equipment (CIOE) cabinet and the Maintenance and Administration Position. " The Cabinetized Power Distribution Center (CPDC) cabinet provides direct current power distribution and protection to the other cabinets in the HLR lineup.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
161
HLR software
The HLR software is developed on the CSP architectural layer for deployment to all UMTS markets. The HLR software is broken into discrete functional units which provide for the operation of different functions within the HLR. This set of functions is listed below: UMTS Based--Product Layer The UMTS--based product layer contains software specific to a particular HLR product such as UMTS. This layer includes software specific to the UMTS markets. UMTS Market Specific Proprietary Services " SIM Replacement A Subscriber Identity Module (SIM) card is used in identifying any subscriber to a UMTS network. A subscribers SIM card has a finite life expectancy and it is necessary to replace the SIM card periodically. This service facilitates the replacement process. " Supplementary Services Provides capability to the HLR to provide proprietary services, such as Class of Service and number translations. " Operator Services Provides proprietary network services to mobile network operators. " Alternate Line Service Alternate Line Service (ALS) is a non--UMTS defined service. It associates two MSISDN numbers with a subscriber (IMSI) for telephony calls. UMTS Services This layer contains the software related to UMTS defined services. " Supplementary Services Provides capability to the HLR to modify or supplement basic telecommunications services, such as call waiting and call barring. " Short Message Service The HLR supports the UMTS Short Message Service. This service allows for messages of a limited size to be sent from a Service Center to a mobile (SM MT) and from a mobile to a Service Center (SM MO). " Data Service The HLR supports the circuit--switched data services. " Speech The HLR supports telephony and emergency speech services. UMTS Base " Call Routing Support The HLR supports call routing to mobile stations by providing the CCN CS with information about the location of mobile stations.
162
" Equal Access Support For the North American marketplace, the HLR provides support for equal access. Equal access is defined as the ability of a user to choose an interexchange carrier (IC/INC) for call attempts that do not terminate on their network or within a local exchange network directly connected to their network. " Operator Determined Barring Operator Determined Barring (ODB) is a service that allows the network operator or service provider to regulate access by the subscribers to UMTS services. These services are regulated by barring certain categories of outgoing or incoming calls or of roaming. One application of ODB might be to those subscribers who have not promptly paid their bills. " Intelligent Network Support HLR incorporates proprietary extensions to support the implementation of Intelligent Network (IN) support at the CCN CS. " Inter--PLMN Roaming Support HLR supports Mobile Stations in roaming to other Public Land Mobile Networks (PLMNs), both within and outside of the Mobile Station s home country. " Subscriber Database Management Manages the storage of subscriber information. " Authentication Generates security--related parameters used to ensure that only authorized Third Generation (3G) UE have access to the Public Land Mobile Network (PLMN). " Messaging and Signaling Supports the following HLR functions: -- UMTS--defined Mobile Application Part (MAP) protocols -- Hybrid protocol stack in addition to standard UMTS stack -- HLR network interface. HLR/AuC interfaces HLR provides the network with facilities for examining permanent data and examining and modifying temporary data. HLR handles transactions with the CS and nodes, which either request information from the HLR, or update the information currently held in HLR. HLR also initiates transactions with the VLR to complete incoming calls and update subscriber data. Network nodes, including HLR, use Mobile Application Part (MAP) interfaces to communicate. The following are the specific HLR MAP interfaces: " CS to HLR/AuC (C--interface) " HLR to VLR (D--interface) " The HLR/AuC to Maintenance and Administration Position interface is the Administrative interface. " HLR/AuC to 3G SGSN (Gr--interface) Shared Layer Shared layer contents are obtained from the Shared Library. The Shared Library is a central repository for storage of software features and frameworks utilized by multiple products. This centralized database provides a means for the management of common software allowing market and product independence, allows for the evolution of services, and is a cost--effective structure for software reuse.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
163
Telecom Layer The Telecom layer includes general purpose utilities and maintenance systems for CCN telecommunications products. These utilities include CCS7, call processing base and run--time support, ENET and JNET maintenance, and basic translations. This layer does not necessarily contain all the functionality required to place calls. Base Layer The Base layer contains resource management for system resources, maintenance systems for general purpose computing devices, and operations, administration, and maintenance (OA&M) for the system. Figure 54 HLR software structure
164
SIG introduction
The SIG provides interworking between GPRS/UMTS nodes in an IP network and GSM nodes in an SS7 network.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
165
SIG features and functions

The SIG provides interworking between GPRS/UMTS nodes in an IP network and GSM nodes in an SS7 network. Multiple SGSNs exist in the GPRS/UMTS network, making the SIG responsible for routing messages from the GSM HLR to the correct SGSN. The SIG also routes messages originating from the SGSN to the MSC/VLR or HLR. Additionally, the SIG converts TCAP/GSM MAP messages originating from the GSM HLR in the SS7 network to UDP/IP messages. These messages contain the GSM MAP client interface for GSM messages destined for the GPRS SGSN nodes. For messages originating from the SGSN IP network and destined for the HLR SS7 network, the SIG converts the UDP/IP messages into TCAP/GSM MAP messages. The SIG supports messaging operations between the SGSN (IP network) and HLR (SS7 network) in order to provide location management, subscriber management, authentication management, and fault recovery.
166
SIG hardware structure

The SIG is a HA (High Availability) system that uses Hewlett Packard 9000 N series servers and HP TSU (Telecom Signaling Unit) SS7 units to achieve a high degree of reliability. HP9000 N4000 system The SIG system includes two Hewlett Packard (HP) 9000 N4000 servers. Figure 55 HP9000 N4000 front exterior
The HP9000 N4000 includes the following components: CPU - one or four 550 MHz PA8600 processors Memory: up to 16 Gbytes 12 Hotplug 64-bit 60 MHz PCI I/O slots OS - HP-UX 11.0 DVD drive
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
167
HP Telecom Signaling Unit (TSU) Figure 56 Telecom Signaling Unit: Front view
Figure 57 Telecom signaling unit: Back view
Location The HP9000 N4000 based HP system, including both servers and TSUs, resides in a single standard HP cabinet.
168
Figure 58 SIG system cabinet
Physical characteristics HP system cabinets Depth: 1000 mm Width: 600 mm Height: 200 cm Weight: 250 kg HP9000 N4000 server Depth: 812 mm Width: 482 mm Height: 445 mm
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
169
TSU Depth: 464.21 mm Width: 431.8 mm Height: 86.89 mm Electrical characteristics HP9000 N4000 ac input power: 200-240 V, autorange 50-60 Hz Current requirements at 220V: 13.8 A TSU ac/dc Input power: 100-127/200-240 V Current requirements at 120 V: 3.0 A Current requirements at 240 V: 1.3 A dc/dc Input power: -40 to -72 V dc Current requirements: 8.0 A
170
UMTS interfaces introduction

The UMTS interfaces are split into: UTRAN interfaces UTRAN--to--Core Network interfaces Core Network interfaces
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
171
UTRAN interfaces introduction

The UTRAN interfaces are split into: Network interfaces: " Iub interface The Iub interface is between RNC and node B. This interface is an equivalent to the GSM Abis O&M and RSL. As opposed to the GSM case, this interface will be defined in standardization committees (with the exception of node B specific O&M), allowing node Bs and RNCs from different manufacturers to be connected. " Iur interface The Iur interface is between RNCs. There is no equivalent to this interface in GSM. This interface has been defined to serve macrodiversity functions coming from the CDMA radio technology. " Iu interface The Iu interface is between RNC and either SGSN (for the packet domain) or MSC (for the circuit domain). This interface is an equivalent to the A GSM interface. Radio interface: " Uu interface The Uu interface is the radio interface used between node B and UE. As opposed to the other UTRAN interfaces, Uu is dependent on the technology used on the radio interface (that is, WCDMA or TD/CDMA). Figure 59 UTRAN interfaces
172
Protocol structure of the UTRAN network interfaces

The UTRAN network interfaces use the following protocol structure: Radio network layer All UTRAN--related issues are visible only in the radio network layer. Transport network layer The transport network layer represents standard transport technology to be used for UTRAN, but without any UTRAN specific requirements. The following figure represents the general protocol model that applies to the UTRAN network interface protocols: Iu, Iub and Iur.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
173
Figure 60 General model of UTRAN interfaces
Radio network layer The radio network layer is split into two planes: User plane This plane carries user data: voice, packets. It includes the data streams and the data bearers. The data streams are characterized by one or more frame protocols specified for the interface.
174
Control plane This plane carries all the signalings: this means CC (Calll Control) messages. It includes the application protocols, and the signaling bearer for transporting the application protocols messages. These application protocols are mainly used for setting up bearers. Transport network layer The transport network layer is split into three parts: Control plane User plane ALCAP (Access Link Control Application Part) ALCAP is the protocol used by the transport network layer to set up the transport network user plane. Network protocols This paragraph lists all the technologies and network layer names that have been defined for the network protocols: Iu interface Iub interface Iur interface Iu interface Regarding the Iu interface, the PS and CS planes have been separated, since different protocol stacks have been defined as regards the Core Network domain in use. No ALCAP is available for the packet service, since the user plane is based on a connectionless IP-based protocol stack. Packet--switched Iu-PS Network layer Transport layer Circuit--switched Iu-CS Network layer Transport layer C-Plane RANAP SCCP AAL5 ALCAP -AAL2 Sig AAL5 AAL2 U-Plane Iu--UP C-Plane RANAP SCCP AAL5 ALCAP N/A N/A N/A U-Plane Iu--UP GTP/UDP/IP AAL5
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
175
Iub interface The following table presents the protocols used by the network and transport layers for the Iub interface. Iub Network layer Transport layer C-Plane NBAP SCCP AAL5 ALCAP -AAL2 Sig AAL5 AAL2 U-Plane
In future evolutions, new transport stacks may de defined. Iur interface The following table presents the protocols used by the network and transport layers for the Iur interface. Iur Network layer Transport layer C-Plane RNSAP SCCP AAL5 ALCAP -AAL2 Sig AAL5 AAL2 U-Plane
In future evolutions, new transport stacks may de defined.
176
UTRAN protocols
The following protocols are used in the UTRAN network interfaces: NBAP (Node B Application Protocol) NBAP is carried by the Iub interface between the RNC and the node B. Node B O&M functions have been defined within the NBAP protocol. Some functions that existed in GSM have no equivalent in NBAP due to the fact that some radio protocol layers (RLC/MAC) have moved up to the RNC. NBAP supports the following functions: " Common transport channels management " Radio resource management " Cell configuration management " Resource event management " Measurement reporting " System information update " Radio link management (addition, deletion, ...) " Power control RNSAP (Radio Network Sub--system Application Protocol) RNSAP is carried by the Iur interface between RNCs. Due to the notion of Drift and Serving RNC, this interface will support functions which are also defined over the Iub and the Iu interfaces. RNSAP supports the following functions: " Radio link management (addition, deletion, ...) " Transfer of uplink and downlink signalling " Measurement reporting " Power control " Load management " Paging " Relocation RANAP (Radio Access Network Application Protocol) RANAP is carried by the Iu interface between the RNC and the Core Network. This protocol is derived to some extend from the A interface protocol. Therefore, many of the functions defined in GSM have an equivalent in RANAP. Apart from these functions, some new ones have been created, specific to UMTS. They actually come from the principle of independence of the Core Network and the Access Network.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
177
RANAP supports the following functions: " Relocation (equivalent to GSM handover) " RAB management (equivalent to GSM assignment) " Transport of DTAP (non--access stratum signalling messages) " Paging " Security (ciphering and integrity check) " CN information broadcast " Overload control over Iu
178
UTRAN protocol stacks

Control plane protocol stacks The UTRAN protocol stacks for the control plane are described in the following figure. Figure 61 UTRAN protocol stacks (control plane)
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
179
User plane protocol stacks The UTRAN protocol stacks for the user plane are described in the following figure. Figure 62 UTRAN protocol stacks (user plane)
180
ALCAP protocol stacks The UTRAN protocol stacks for ALCAP are described in the following figure. Figure 63 UTRAN protocol stacks (ALCAP)
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
181
Radio interface (Uu) introduction

The radio interface (Uu) is split into three protocol layers: Physical layer (L1) Layer 1 supports all the functions required for transmission of bit streams on the physical medium. It is also in charge of the measurement function consisting in indicating to higher layers: " the FER (Frame Error Rate) " the SIR (Signal to Interference Ratio) " interference power " transmit power It is basically composed of a layer 1 management entity, a transport channel entity, and a physical channel entity. Data link layer (L2) The layer 2 protocol is responsible for providing functions such as mapping, ciphering, retransmission, segmentation. Network layer (L3) Layer 3 is split into two parts: " Access Stratum The Access Stratum part is composed of the RRC (Radio Resource Control) entity and the duplication avoidance entity. " Non Access Stratum The Non Access Stratum part is composed of the CC (Call Control) and MM (Mobility Management) parts.
182
Figure 64 Uu protocol layers
Non Access Stratum/Access Stratum (NAS/AS) UMTS specifications provide a model in which mobile network interactions are split into two areas as shown in the following figure: NAS (Non Access Stratum) The NAS layer handles every user--network function such as: call control, packet and circuit mobility management, supplementary services, session management, ... AS (Access Stratum) The AS layer is actually defined as a bearer for the NAS functions, and therefore is completely dependent on the technology used on the radio interface.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
183
Figure 65 NAS/AS concepts
The Core Network cannot be completely independent of the Access Network technology. The Iu interface content (between Core Network and Access Network) is actually tied to the technology used on the radio interfacce. So when other access technologies are defined (such as SRAN for satellites), the corresponding Iu interfaces will be defined as well. Actually, this is already the case for Core Networks handling both 2G and 3G access technologies.
184
Channel definition
Three types of channel have been defined within UTRAN: Logical channels Logical channels are the services offered by layer 2 to the higher layers. Logical channels are mapped onto transport channels by the MAC layer being part of layer 2. Transport channels Transport channels are the services offered by layer 1 to the higher layers. A transport channel is defined by how the data is transferred over the air interface (this means interleaving depth, channel coding, ...). Transport channels are mapped onto physical channels by layer 1. Physical channels Physical channels are used on the radio interface between peer L1 entities. The physical channels correspond to different radio frame types and content. The mapping of these channels is described in the following figures. Figure 66 Mapping logical to transport channels
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
185
Figure 67 Mapping transport to physical channels
Transport Channels DCH RACH CPCH BCH FACH PCH
Physical Channels Dedicated Physical Data Channel (DPDCH) Dedicated Physical Control Channel (DPCCH) Physical Random Access Channel (PRACH) Physical Common Packet Channel (PCPCH) Common Pilot Channel (CPICH) Primary Common Control Physical Channel (P--CCPCH) Secondary Common Control Physical Channel (S--CCPCH) Synchronisation Channel (SCH)
DSCH
Physical Downlink Shared Channel (PDSCH) Acquisition Indication Channel (AICH) Page Indication Channel (PICH)
186
Radio interface protocols

The main radio interface protocol layers are the following: MAC (Medium Access Control): layer 2 RLC (Radio Link Control): layer2 PCDP (Packet Data Convergence Protocol): layer 2 RRC (Radio Resource Control): layer 3 Another layer 2 protocol has been added to this list: BMC (Broadcast/Multicast Control). This layer is used by UTRAN to schedule the cell broadcast/multicast messages on the radio interface. MAC The main function of the MAC layer is to act as a relay between the physical layers (which only handle the transport channels) and the communication layers (which offer SAPs (Service Access Point) to the upper layers). Therefore, the MAC layer handles all the functions such as multiplexing of data links on a radio bearer according to requested priority, and selection of the user data transport format. The MAC layer provides: mapping of logical channel to transport channels selection of transport format multiplexing of the data flows of one user. Since UMTS is multimedia, a user may activate several services at the same time, possibly having different profiles (priority, QoS parameters...). Therefore the MAC layer is in charge of multiplexing all the flows on the resources allocated to the user multiplexing of users on a common transport channel. This function is activated when common transport channels such as DSCH or FACH are used. multiplexing (or scheduling) of broadcast, notification and paging messages on the PCH and BCH transport channels traffic volume monitoring RLC The RLC layer main function is the transfer of data from either the user or the control plane over the radio interface. The RLC works in acknowledged, unacknowledged or transparent transfer mode. The RLC provides: segmentation/reassembly of SDUs error correction in acknowledged transfer mode The UTRAN radio protocol architecture presents several RLC boxes at the RLC level, since there is actually one RLC context per data link. The RLC layer makes no difference between the user plane and the control plane. The same set of services is proposed by RLC to both planes.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
187
PDCP The PCDP layer has two main functions: compression of protocol headers in TCP/IP or UDP/IP streams buffering and numbering of N--PDU The header compression mechanism has many benefits (decreases packet loss rate over the radio, improves interactive class traffic response time, ...). Basically, the header compression process works on the assumption that most of the header fields in the IP protocol suites remain constant for a significant period of time. This assumption removes all redundant information (this includes source and destination addresses). Therefore, once this information has been sent, there is no need to send it again if there is no change. PDCP works in such a way that it makes the UTRAN radio protocol layers independent of the network protocols that are being used. Therefore, the use of IPv4, IPv6, or any protocol suite as a network protocol is transparent to all the UTRAN functions below PDCP. RRC The main functions of the RRC layer are the following: management of radio resource (establishment, release, reconfiguration) management of RRC connection between the UE and the network (establishment, release) RRC offers three SAPs (Service Access Points) to the upper layers (in the UE) or to the Core Network/non access stratum: GC (General Control): non access stratum information broadcasting Nt which is used for broadcasting paging or notifications DC (Dedicated Control): request for connections BMC The BMC layer is responsible for broadcast or multicast message scheduling and transmission on the radio interface. Therefore, there is a lot of interaction between the BMC and the RRC layers to allocate capacity for broadcasting on the radio, and traffic volume monitoring. The broadcast service is inherited from the GSM (Cell Broadcast Service). It allows delivery of general information messages from a Broadcast Center to all the mobile users in a given area, which was defined as a group of cells in GSM. This may be a geographical area (using geographical coordinates) in UMTS. The role of the BMC layer is to make sure the request from the broadcast center (the message to be broadcast and the associated repetition scheme) is fulfilled. The multicast service has a lot of points in common with the broadcast service. The difference is that multicast is used to prevent non authorized users from decoding and reading messages sent by the network.
188
Mapping of radio protocols on network elements

The following figure shows the protocol termination for the DCH transport channel for the control/user planes. The part of physical layer terminating in the serving RNC is the topmost macro--diversity combining and splitting function for the FDD mode. If no macrodiversity applies, the physical layer is terminated in node B. There may be a drift RNC between the SRNC and the node B (which means an RNC that actually controls the node B). Figure 68 Mapping of radio protocols on network elements
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
189
Layer 1 description
The following functions are performed by the physical layer when receiving data from higher layers to be transmitted on the radio interface: add a CRC to each transport block transport block concatenation and code block segmentation channel coding rate matching interleaving radio frame segmentation multiplexing of transport channels into a coded composite transport channel (CCTrCH) physical channel segmentation when more than one physical channel is used mapping to physical channels I/Q branch mapping spreading (using channelization code) scrambling (using complex or not scrambling code) modulation
190
Protocol suite for packet services

This figure is an overview of the protocol suite used for packet services. Figure 69 Protocol suite for packet services
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
191
Physical channels
Physical channel classification The physical channels can be split into 4 groups: downlink common shared resource for data or common purpose channels: -- CPICH -- CCPCH -- SCH -- DSCH -- AICH -- PICH dedicated to carry user specific data or control information in the downlink: -- DPDCH -- DPCCH common shared resource for data or common purpose channels: -- PRACH -- PCPCH uplink dedicated to carry user specific data or control information in the uplink: -- DPDCH -- DPCCH
All the channels in the previous table carry user data, except for some common downlink physical channels: CPICH, SCH, AICH, PICH. These four channels only serve Layer 1 functions. Since they are not used to carry user information, they are not mapped to transport channels. The SCH (Synchronization channel) is used for the cell search procedure. The AICH (Acquisition Indicator CHannel) is used to send RACH preamble acknowledgement from the network. The RACH and associated procedure are used to access the network. The PICH (Page Indication CHannel) carries indication on UEs that paging information is available on the secondary CCPCH (which carries the PCH transport channel). Data and control fields for layer 1 The following figure describes data and control for layer 1. Figure 70 Data and control fields at layer 1
192
Every information item to be transmitted on the radio interface coming from higher layers (the MAC layer) is considered by layer 1 as pure data, irrespective of the nature of the information to be transported. This information may be either: user information such as voice, IP packets, circuit data, ... control information from UTRAN. This means radio resource signaling due to handover, radio resource allocation, ... control information from the Core Network such as call control or mobility management messages The control information handled by layer 1 is not known by the higher layers. This control information is made up of: TFCI (Transport Format Combination Indicator) This field is used by the receiving entity to decode the received frame. The TFCI bits are spread on the 15 slots of the frame. The default length of the TFCI field is 30 bits, which means that each radio timeslot contains 2 bits of the TFCI. TPC (Transmit Power Control) The TPC command is valid for each slot. Pilot bits which are used to support channel estimation for coherent detection FBI: Feedback information. This field is used to support techniques requiring feedback between the UE and the UTRAN. Since it is used by the network, it is only present in uplink frames. Description of frame/timeslot The UTRAN radio interface is basically composed of frames: Each frame contains 15 time slots containing 2560 chips. This gives a chip rate of 3.84 Mchip/s (2560 chips x 15 TS / 10ms = 3.84 Mchips/s).
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
193
Figure 71 Frame/Timeslot
Options on the radio interface The network may use the following techniques on the radio interface, as an option. Use of SSDT (Site Selection Diversity Transmit) SSDT is an optional macro diversity method in the soft handover mode. Use of OTSR (Omni Tx Sectored Rx) UE service multiplexing With 3rd generation networks comes the possibility to allow support of multiple and simultaneous user flows. As an example, a 3rd generation terminal may provide both Web and voice services at the same time. All the services provided at a given time may have different characteristics in terms of transfer delay and QoS parameters in general. As a consequence, the communication layers are very much involved as regards service multiplexing. This is due to the different service requirements that have been requested by the user applications. The following figure provides a global picture of what is performed by layers 1 and 2 regarding user service multiplexing.
194
To allow the UTRAN to offer the QoS requested by the Core Network, the notion of transport format has been created. The transport formats are only known at the UTRAN level, and therefore are completely hidden from the Core Network. The aim of transport format selection is to allow the communication layers to put a higher priority to a data stream as compared to the others. The prioritization is performed through the provision of a high bit-rate transport format to transport channels having a high precedence.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
195
Figure 72 User service multiplexing for layers 1 and 2
196
Iu interface
Introduction The Iu interface connects the UTRAN to the Core Network. It is broken down into Iu circuit switched (Iu--CS) and Iu packet switched (Iu--PS). Iu interface in the circuit domain, Iu--CS The following figure illustrates the circuit switched protocol stacks for the control plane (C--plane) and user plane (U--plane), as defined in the standards. Iu circuit-switched protocols Figure 73
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
197
Iu interface in the packet domain, Iu--PS The following figure illustrates the packet switched protocol stacks for the control plane (C--plane) and user plane (U--plane), as defined in the standards. Iu packet-switched protocols Figure 74
Note: The SCTP/UDP/IP protocol stack is not supported on the Iu interface. Only the SCCP/MTP3b/SSCF--NNI/SSCP is supported by the WG in UMTS01. Like the radio interface, the Iu interface (UTRAN--CN) carries two protocols: RANAP User plane
198
Figure 75 UTRAN-to-Core Network interface
RANAP protocol The RANAP protocol supports all the signaling between UTRAN and core network for many functions (such as RAB assignment, relocation, ...). It is also used to transfer the UE--Network signaling (such as the MM and CC protocol layers) The user plane is used to transfer all user data between the core network and the UTRAN. The user plane is used for different applications: voice, AMR, packet data. User Plane (UP) protocol The Iu UP protocol supports different modes of operation that can be activated on a Radio Access Bearer (RAB) basis depending on the service required by the end user. Operation mode selection is fixed by the CN for the duration of the RAB and indicated to the UTRAN in the Iu control plane at RAB establishment (assignment or relocation). Two modes of operation for the protocol are defined: transparent mode support mode User plane transparent mode The transparent mode is intended for the RABs that do not require any particular feature from the Iu UP protocol other than transfer of user data. In this mode, the Iu UP protocol instance does not perform any Iu UP protocol information exchange with its peer over the Iu interface.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
199
The typical services that use this mode are the following: packet data circuit switched type of data such as modem and fax The following figure shows the functional model of the Iu user plane using transparent mode. The Iu data frames are transferred transparently from the CN to UTRAN radio protocols. Figure 76 User plane transparent mode
User plane support mode The support mode is intended for services (RABs) that require a particular feature from the Iu UP protocol in addition to the transfer of user data. When operating in a support mode, the peer Iu UP protocol instances exchange Iu UP control frames in addition to the user data frames.
200
The functions provided by the support mode are the following: Transfer of user data (as for the transparent mode) Initialization This function is used to configure the transcoder (on the CN side) with the PDU sizes that will be used. Rate control This function is used in AMR to change the transcoder source rate in the downlink. Time alignment This function remains for further study. Handling of abnormal event The following figure shows the functional model of the Iu user plane using support mode. Figure 77 Iu user plane using support mode
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
201
The functions used for the Iu user plane support mode are: Frame handler This function performs all the UP framing, de--framing and header CRC check operations. Procedure control This function performs all the control functions offered by the support mode. This means: " initialization " rate control " frame alignment " handling of abnormal event NAS data streams This function performs the UP frame payload CRC check.
202
Core Network Interfaces
UMTS interfaces are defined by GSM and UMTS specifications. UMTS interface Iu replaces GSM A--Interface between the radio network and the switch. Interfaces B--G are unchanged from GSM and use the Mobile Application Part (MAP) protocols to exchange the data necessary to provide mobile service. The following table describes the circuit and packet core network interfaces. Table 3 UMTS Core Network interfaces
Interface Name Iu CS Iu PS B
Core Network interface description Circuit switched interface between the Call Server and RNS via the WG. Packet switched interface between the SGSN (included in WG) and RNS. Interface between the Call Server (CS) and VLR using MAP/TCAP signalling over CCS7 SCCP and MTP. The CS contains both the CS and VLR functionality (that is the CS is co--located with the VLR. Therefore the B--Interface (CS <--> VLR) is an internal interface only. Interface between the Call Server and HLR using MAP/TCAP signalling over CCS7 SCCP and MTP. Interface between the HLR and VLR using MAP/TCAP signalling over CCS7 SCCP and MTP. Interface between Call Servers using MAP/TCAP signalling over CCS7 SCCP and MTP. ISUP, or some other Call Control protocol is also exchanged to permit inter CS calls to be established. Interface between CSs and EIR using Map/TCAP signalling over CCS7 SCCP and MTP. Interface between VLRs using MAP/TCAP signalling over CCS7 SCCP and MTP. Interface between GGSN and Charging Gateway Function (CGF) This interface is used to exchange the data related to the location of the mobile station and to the management of the subscriber. The main service provided to the mobile subscriber is the capability to transfer packet data within the whole service area. The SGSN informs the HLR of the location of a mobile station managed by the latter. The HLR sends to the SGSN all the data needed to support the service to the mobile subscriber. Exchanges of data may occur when the mobile subscriber requires a particular service, when he wants to change some data attached to his subscription or when some parameters of the subscription are modified by administrative means. Signalling on this interface uses the Mobile Application Part (MAP), which in turn uses the services of Transaction Capabilities (TCAP).
C D E
F G Ga Gr
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
203
Interface Name Gn, Gp
Core Network interface description These interfaces are used to support mobility between the SGSN and GGSN. The Gn interface is used when GGSN and SGSN are located inside one PLMN. The Gp--interface is used if GGSN and SGSN are located in different PLMNs. The Gn/Gp interface also includes a part which allows SGSNs to communicate subscriber and user data, when changing SGSN. Signalling on this interface uses the User Datagram Protocol, UDP/IP. Interface between the GGSN and the Internet.
Gi
204
GPRS/UMTS interfaces
The UMTS Core Network uses a set of interfaces introduced for GPRS. The GSM Packet Radio Service (GPRS) specifications define various interfaces. These interfaces exist between GPRS elements and reference points on the internal and external sides of the GPRS system. This following GPRS interfaces are used for UMTS: Ga Gd Gi Gn Gp Gr Gs and Gs
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
205
Ga Interface
Ga interfaces the GSNs and the CGF. The GSNs and the CGF are enhanced to support the GTP protocol for the Ga interface (GSNs to CGF). GTP can be used to collect CDRs from any GPRS element that supports this interface. This feature is desirable for operators who have multiple GPRS suppliers in the core network and plan to collect billing records at a common CGF platform.
206
Gd interface
The Gd interface is defined between the SGSN and the GMSC/IWMSC. The interface is capable of utilizing the GPRS backbone to deliver SMS messages. The Gd interface is similar to the Gr interface. Benefits of this method of SMS delivery include: optimization of network resources decreased SMS delivery time decreased messaging overhead.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
207
Gi interface
Gi interfaces the GGSN with a data packet network (PDN). The PDN can be either a corporate Intranet or an Internet service provider (ISP). GSSN01/02 supports an Internet protocol (IP) PDN. Typically, IP networks use IP routers to perform the interworking with subnetworks. From the IP networks point of view, the GGSN is an IP router. The interworking point with IP networks is at the Gi reference point as shown in AUCUN LIEN . Figure 78 IP network interworking
Terminal equipment
Gi
Terminal equipment IP network(s)
PLMN GPRS network
Accessing the Internet GPRS Technical Specification 9.61 mandates the following two modes of access to the PLMN: transparent access to the Internet non-transparent access to the Internet Note: The terms transparent and non-transparent describe the connectivity from the perspective of the GGSN. Transparent access to the Internet With transparent access, the GPRS operator offers basic ISP (Internet Service Provider) service. The mobile does not send any authentication request at PDP context activation and the GGSN does not take part in the user authentication or authorization process. GPRS provides cursory authentication as part of the network access control procedures executed between the MS and the SGSN. The operator issues the GPRS user a public IP address. The IP address is allocated either at subscription or at PDP context activation. When the IP address is allocated at subscription, the process is called static address allocation. When the IP address is allocated at PDP context activation, the process is called dynamic address allocation.
208
The transparent case provides at least a basic ISP service. As a consequence of this, it may provide a bearer service for a tunnel (for example, IPSec, PPTP, L2TP) to a private Intranet. User level configuration then may be carried out between the MS and the Intranet/ISP and is transparent to the GGSN. The following figures illustrate two possible transparent configurations. Figure 79 Transparent mode for basic Internet service
DHCP SGSN SGSN GPRS PLMN GGSN SGSN Router 2 DNS 1 ($) Radius Operator IP network Address allocation
Internet Router
Address Pools
Router Firewall
Address allocation
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
209
Figure 80 Transparent mode for dedicated Intranet access
DHCP SGSN 1 Address allocation
SGSN GPRS PLMN SGSN Router
($) Radius
Router Firewall
Intranet
GGSN Address Pools 2 Address allocation
Radius
Services
DHCP DNS
Non-transparent access to an Intranet or ISP With non-transparent access, the GGSN facilitates user access to the ISP or Intranet. The basic principles of non-transparent GPRS access are The MS is allocated a private IP address belonging to the ISP or Intranet. The GGSN requests user authentication using the user authentication information contained in the Protocol Configuration Option IE at PDP (Packet Data Protocol) context activation. A basic security protocol, such as IPSec, is used between the GGSN and the ISP or Intranet if the connection is over an insecure IP network. In UMTS01, Nortel Networks offers one type of non-transparent interconnection to external IP networks. This type of non-transparent interconnection is called a simplified non-transparent access. Simplified non-transparent access The simplified non-transparent access mode is a Nortel Networks solution that provides ISP and Intranet interconnectivity. It is a simulated PPP PDU type of interconnection. The simplified non-transparent access mode is an open standards solution (with respect to IETF) that is interoperable with CPE tunnel servers (the Intranet external gateway).
210
In the simplified non-transparent access mode, the GGSN: terminates a GTP tunnel from the SGSN on an activated PDP context and creates an associated PPP session that runs over an L2TP tunnel to the external PDN The tunnel mapping at the GGSN is one-to-one (GTP to PPP). The GGSN may create the L2TP tunnel using IPSec transfer mode if data transfer is over an insecure network (such as the Internet). In this configuration, the GGSN functions as a LAC (L2TP access controller). The termination point of the L2TP tunnel is called the L2TP network server (LNS). This configuration implicitly gives multi-customer capability for authentication and IP assignment. With simplified non-transparent access mode, the GGSN participates in security but not in user authentication. Authentication is performed by the far-end. Gi interface protocols The following protocols are used on the Gi interface: IP protocol Tunneling protocol IP protocol For UMTS01, the Gi interface uses IP v4 for interworking with external PDNs. The GGSN supports IP fragmentation. Tunneling protocol Normally, the type of tunnel implemented between the GGSN and the external IP network is based on mutual agreement. IPSec is supported and recommended if connectivity is established across an insecure network. IPSec minimizes exposure to security risk. IPSec supports both the AH and ESP headers. The UMTS01 release bases the non-transparent mode of access on the simplified non-transparent access mode or L2TP over IPSec. The GPRS specifications suggest a one-to-one tunnel mapping from GTP to IPSec. However, the L2TP over IPSec solution offers the following advantages: It supports overlapping IP addresses allowing multi-customer capability. It provides a high level of interoperability with other vendors. Other tunneling protocols are supported on the CES, such as PPTP and L2F. These tunnels currently are not used for GPRS configurations but can be used for other purposes such as remote customer administration support.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
211
Gn Interface
Gn interfaces the GPRS Support Nodes (GSN) within a PLMN. Gn interface protocol The Gn interface uses GTP (GPRS tunneling protocol). The GTP protocol is implemented by SGSNs and GGSNs. GTP is the means by which tunnels are established, used, managed, and released. (A tunnel forwards packets between an external packet data network and a mobile station (MS) user.) GTP carries multiprotocol packets through the GPRS backbone between GPRS Support Nodes (GSNs). For protocols that need a reliable data link (for example, X.25), GTP tunnels use TCP/IP. For protocols that do not need a reliable data link (for example, Internet protocol), GTP tunnels use UDP/IP. The following figure shows the protocol stack for GTP. Figure 81 GTP protocol stack
Relay Relay GMM/SM LLC BSSGP NS LIBis SGSN SNDCP GTP UDP/TCP IP L2 L1 Gn IP GTP UDP/TCP IP L2 L1 L2 L1 GGSN IP
In the signaling plane, GTP specifies a tunnel control and management protocol. This protocol allows the SGSN to provide GPRS network access for a UE. Signaling is used to create, modify, and delete tunnels. In the transmission plane, GTP uses a tunneling mechanism to provide service for carrying user data packets.
212
GTP handles both signaling messages and user data traffic. GTP signaling messages create, modify, and delete tunnels. Functionally, GTP in the SGSN handles the following functions: It interacts with SM (Session Management) in the SGSN to initiate all GTP signaling messages or handle signaling messages coming from the GGSN node. It interacts with the SNDCP layer to handle user data packets from and to the SNDCP layer. It interacts with the UDP/TCP IP layers to GTP messages (both signaling and T-PDU data packets) from and to its peer GGSN node. It handles echo messages between GSNs. GTP reliable delivery of signaling messages Multiple signaling messages are allowed to be sent simultaneously over a single path. Each request message should be responded to within the T3_RESPONSE time frame. If no response is received within that time period, the message is resent. This retry is repeated for up to N3_REQUEST times unless a response is received. To have each request message properly retransmitted when needed, each request message is assigned a counter. Each counter determines if the limit on the N3_REQUESTS times for an individual signaling message is exceeded. Although multiple signaling messages are sent simultaneously, their waiting for a response is handled independently. Waiting for a response for one message does not block the delivery of other messages. This setup has the following advantages: It uses the GTP layer efficiently. Multiple GTP signaling messages can be sent simultaneously to lower layers. GTP message types Following is a list of the various types of GTP message: Echo request and response An echo request is sent on a path to another GSN to determine if the GSN is alive. An echo request message may be sent for each path in use. A path is considered to be in use if at least one PDP context uses the path to the other GSN. When and how often an echo request message is sent is specified during implementation. However, an echo request may not be sent more often than once every 60 minutes on each path. An echo response is sent in response to a received echo request. The recovery information element contains the local restart counter value for the GSN that sends the echo response message. The GSN that receives the echo response from a peer GSN compares the received restart counter value with the previous restart counter value stored for the peer GSN. If a previous value was not stored, the received restart counter value is stored for the peer GSN. If the previously stored restart counter value differs from the received restart counter value, the GSN that sent the echo response message is considered restarted by the GSN that received the message. The new restart counter value is stored by the receiving entity. If the sending GSN is a GGSN and the receiving GSN is an SGSN, the SGSN notifies an affected MS the next time the MS contacts the SGSN. An affected MS is an MS that has at least one activated PDP context using the restarted GGSN. The SGSN considers all PDP contexts using the path as inactive.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
213
Version not supported This message contains only the GTP header. This message indicates the latest GTP version supported by the GTP entity on the identified UDP/IP address. Create PDP context request and response The SGSN node sends a create PDP context request to a GGSN node during the GPRS PDP context activation procedure. A valid request initiates the creation of a tunnel between a PDP context in an SGSN and a PDP context in a GGSN. If the procedure is not successfully completed, the SGSN repeats the create PDP context request message to the next GGSN address in the list of IP addresses (if there is another address). If the list is exhausted, the activation procedure fails. The GGSN node sends a create PDP context response to an SGSN node in response to the create PDP context request message. The cause value in the response message indicates if a PDP context was created in the GGSN. A PDP context was not created in the GGSN if the cause value differs from request accepted. Delete PDP context request and response An SGSN node sends a delete PDP context request message to a GGSN node during either: " the GPRS detach procedure, or " the GPRS PDP context deactivation procedure Also, the GSGN sends a delete PDP context request message to a SGSN during the PDP context deactivation initiated by the GGSN procedure. The request is used to deactivate an activated PDP context. The delete PDP context response message is sent only when the context has an idle timeout or the administrator forcibly deleted the context. Error indication The SGSN sends an error indication message to the GGSN if: " a PDP context does not exist " the PDP context is inactive for a received G-PDU " a Mobility Management (MM) context does not exist for a received G-PDU When the GGSN receives an error indication, the GGSN deletes its PDP context and notifies the operation and maintenance network element. A new SGSN sends this message to an old SGSN if an active PDP context does not exist for a received G-PDU. The old SGSN deletes its PDP context and notifies the operation and maintenance network element. Also, a GGSN sends an error indication to the SGSN if a PDP context does not exist for a received G-PDU. The SGSN tells the MS when a PDP context is deleted due to the reception of an error indication. The MS then requests the PDP context be re-established. Identification request and response A new SGSN sends an identification request message to an old SGSN when an MS (at GPRS attach) indicates it has changed SGSNs since detach. The old SGSN sends an identification response message to the new SGSN in response to a previous identification request message. If the cause value is request accepted, the response contains IMSI information, possibly one or several authentication triplet information elements, and optional vendor or operator-specific information.
214
SGSN context request and response A new SGSN sends an SGSN context request message to an old SGSN in an effort to obtain MM and PDP contexts for an MS. The old SGSN sends an SGSN context response message to the new SGSN in response to the request message. If the cause value is Request accepted, the response message contains the following: " a flow label signaling field " IMSI information element " possibly one or several receive state variable information elements " mobility management and security parameters " active PDP contexts from the old SGSN " optional vendor or operator-specific information SGSN context acknowledge A new SGSN sends an SGSN context acknowledge message to an old SGSN in response to the SGSN context response message. This message indicates the new SGSN has correctly received PDP context information and is ready to receive data packets identified by the corresponding TID values. The old SGSN forwards user data packets only after receiving the SGSN context acknowledge message. GTP message flows The following discusses the message flow that exists among GTP-related components. The following scenarios illustrate the details of the message flows: PDP context activation and deactivation echo request and response error PDP context activation During the PDP context activation procedure, the SGSN sends a created PDP context request to a GGSN. The GGSN IP address is the first IP address in the list of IP addresses provided by the DNS server. The DNS server provides the IP addresses in its response to the query of the Access Point Name (APN) received in the activate request. Note: A list of IP addresses represents a list of Gn interfaces. GTP path management messages monitor a Gn interface if the interface is used by some PDP context(s). GTP also maintains the link status of each monitored interface. Note: If the previous try fails on a PDP Context Activation request, GTP tries each of the addresses in the address list. GTP tries the addresses in order from the first address to the last address, regardless of the recorded link status of the aforementioned interface. This is because the link status information is inaccurate since only one echo message can be sent every 60 seconds. Note: The link status of a path indicates if a path failure occurred and how long the path has been in a failed status. When the age of a path failure exceeds a predefined value, the GGSN on the path is considered out of service.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
215
The following figure illustrates the message sequence for the PDP context activation procedure. Figure 82 Message sequence for PDP context activation procedure
The steps for the PDP context activation are the following: 1 2 3 The SM sends a message to trigger the SGSN/GTP to send a GTP create PDP context request message to the proper GGSN/GTP node. The SGSN/GTP message (create PDP context request) establishes a tunnel to the GGSN node to create a PDP context in the GGSN node. A timer of T3_Response is started. The GGSN/GTP message (create PDP context response) tunnels to the GTP in SGSN node. The timer is stopped.
Note: GTP uses a timer and a counter for each outgoing signaling message. For each signaling message sent out, a response is received before the T3_response timer expires. If a timeout occurs, the GTP resends the message for another N3_requests-1 time.
216
Note: The create PDP context response message may optionally include a recovery IE (Information Element) in it. GTP checks the recovery IE to see if the peer GGSN has restarted. If the peer GGSN has restarted, the GTP must notify the SM of the change so the SM can take proper action on it. Note: If PDP context activation fails on one Gn interface, GTP repeats the create PDP context request to the next GGSN address if one exists. PDP context deactivation (UE initiated) During the PDP context deactivation procedure, the SGSN sends a delete PDP context request to a GGSN. The request is used to deactivate an activated PDP context. The GSN sends a delete PDP context response in response to a delete PDP context request. The GSN always replies to a request even if the PDP context does not exist. The following figure illustrates the message sequence for the PDP context deactivation procedure.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
217
Figure 83 Message sequence for PDP context deactivation procedure
The steps for PDP context deactivation are the following: 1 2 3 The SM sends a message to trigger the SGSN/GTP to send a GTP Delete PDP Context Request message to the proper GGSN node. The SGSN/GTP message (Delete PDP Context Request) tunnels to the GGSN node to delete a PDP Context. A timer of T3_Response is started. The GGSN/GTP message (Delete PDP Context Response) tunnels to the GTP in SGSN node. The timer is stopped.
Note: GTP uses a timer and a counter for each outgoing signaling message. For each signaling message sent out, a response is received before the T3_response timer expires. If a timeout occurs, the GTP resends the message for another N3_requests-1 times. 4 The message is forwarded to the SM.
218
Echo request on signaling path and data path A path is a physical connection (direct or indirect) between a pair of source and destination IP addresses. Path management can be performed on any path in use. The path is considered to be in use if at least one PDP context uses the path to the other GSN. AUCUN LIEN shows an example of a pair of GSN nodes. In this example, each Gn interface has four paths (one signaling path and three data paths). Figure 84 Example of a pair of GSN nodes
SGSN Sign. path Data path Data path Data path Path 1 Path 2 Path 3 Path 4
GGSN Sign. path
If all paths in the example are in use, the system may send an echo request message for each signaling path. These messages are sent to determine if the peer GSN is alive. The SGSN GTP uses a timer and a counter for each echo request message that it sends. A response must be received before the T3_response timer expires. If a timeout occurs, the GTP resends the message for another N3_REQUESTS-1 times (five times by default). If the response is not received after the N3_REQUEST times of attempts, the path is considered down. Echo response on signaling path and data path The SGSN responds to any echo request it receives. The following figure shows the message sequence for the echo response procedure.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
219
Figure 85 Message sequence for the echo response procedure on signaling path and data path
The steps for the echo response are the following: 1 2 The GGSN sends a GTP echo request message to the SGSN. This message occurs at a certain rate (for example, five minutes). The SGSN sends an echo response with recovery to the GGSN to tell the GGSN node its current status.
Note: The restart counter values in the SGSN/GTP message is included in order to tell if the SGSN node has restarted or not.
220
Gp interface
Gp which exists between BGs (Border Gateway) for inter--PLMN roaming allows subscribers to access the HPLMN GGSN from a VPLMN SGSN through a highly secure interface, that is to say an IPSec tunnel. The Gp interface consists of the same signalling messages as those defined for the Gn interface, except the GSNs are located in different GPRS PLMNs. Supported Gp signaling includes the same set of tunnel management and path management messages as supported on the Gn interface.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
221
Gr and Gr interfaces
The Gr interface is used between an SGSN and an HLR. Since the SGSN and the HLR contain and communicate using different protocols, the protocol messages must be routed through a conversion entity. In the GPRS application, this entity is known as the SS7/IP Gateway, or SIG. The use of the SIG requires two types of interface: the Gr interface the Gr interface Purpose of the Gr interface The Gr interface is used between the SIG and the HLR. All operations relevant to SS7 signaling and the HLR in the GPRS system are handled through the Gr interface that uses the MAP (Mobile Application Part). The following figure shows the location of the Gr interface.
222
Figure 86 Location of the Gr interface
SS7 Network Gr DMS/HLR Gr Gr SS7/IP Gateway SGSN
SGSN DMS/HLR Console
IP Network
Purpose of the Gr interface The Gr interface is a Nortel Networks proprietary signaling protocol that interfaces the SIG and the SGSN. The Gr interface uses a protocol layer called SGSN MAP Clients to SS7/IP Gateway Interface Protocol (SSIP). The SSIP protocol layer transports MAP data to and from the IP network as defined in the GSM 09.02 specification. The SSIP protocol layer contains MAP Intent data and information that allows nodes to identify and correlate MAP dialogs. The following figure shows the location of the Gr interface.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
223
Figure 87 Location of the Gr interface
SGSN
Gr Nortel Networks SS7/IP Gateway (SIG)
SGSN
Gr Gr
Gr
HLR
SGSN
GGSN IP network SS7 network
In the Nortel Networks GPRS implementation, the SIG provides the TCAP and MAP protocol functions. The SIG also performs the SS7 and IP interworking functions between the SGSN and HLR. Message protocol stacks The Gr and Gr interfaces use different protocol stacks. The Gr interface uses the protocol stack used by the SGSN. This protocol stack is referred to as the SGSN MAP Client (MC) protocol stack. The Gr interface uses the protocol stack used by the HLR. The following figure illustrates the message protocol stacks for the SGSN MC, SIG, and HLR.
224
Figure 88 Protocol stacks for MC, SIG, and HLR
HP SS7/IP Gateway Interworking SGSN MC SSIP UDP IP L2 L1 SSIP UDP IP L2 L1 MAP TCAP SCCP MTP3 MTP2 L1
HLR MAP TCAP SCCP MTP MTP2 L1
Gr interface
Gr interface
The SGSN MC protocol stack As previously stated, the Gr interface uses the SGSN MC protocol stack. MAP Client (MC) is an application that resides on the SGSN. MAP Client enables the SGSN to: receive a decoded MAP message from the HLR through the SIG send a decoded MAP message to the HLR through the SIG The SGSN MC protocol stack is comprised of the SSIP, UDP, and IP protocol layers. The following paragraphs describe the SSIP, UDP, and IP layers. SSIP layer The SSIP portion of the stack performs the following functions: It supports signaling exchange with the HLR through the SIG. It receives, sends, and processes messages from the SIG. It supports the following mobility management operations: " updateGprsLocation " reset " insertSubscriberData
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
225
" deleteSubscriberData " cancelLocation " sendAuthenticationInfo It provides MAP Client Timer for the following messages: " insertSubscriberData " sendAuthenticationInfo " updateGprsLocation It provides retry attempts for the following messages when the MAP Client Timer expires: " sendAuthenticationInfo " updateGprsLocation It maps messages sent and received between the MAP Client and the SIG. It counts the number of messages received in the SGSN. It counts the number of messages sent by the SGSN. It handles errors. It counts mobility management operations. It counts errors. UDP layer The UDP (User Datagram Protocol) layer is a TCP/IP protocol that defines the use of unacknowledged datagrams. UDP assumes that the IP protocol is used as the underlying layer 3 protocol. UDP segments are often used for low-priority data or on high-reliability networks. UDP also is used when an application already provides an integrity function and does not need to duplicate that function through TCP. In GPRS, UDP is the transport layer for SGSN application programs (for example, GTP). UDP sends messages to other GPRS nodes with a minimum of protocol mechanism. UDP is transaction-oriented. Delivery and duplication protection is not guaranteed with UDP. IP layer The IP (Internet Protocol) layer is a connectionless datagram service that provides internetwork-wide addressing fragmentation and re-assembly time-to-live control of datagrams checksum verification of header contents HLR protocol stack As previously stated, the Gr interface uses the HLR protocol stack shown in AUCUN LIEN . The following paragraphs describe the TCAP, SCCP, and MTP layers found in the protocol stack. For a description of the MAP layer, refer to the GSM 09.02 specification.
226
TCAP layer This layer of the protocol stack provides the signaling function for network databases. TCAP is an SS7 application protocol that provides the platform to support non-circuit related, transaction-based information exchange between network entities. SCCP layer SCCP is part of the ITU-T No 7 signaling protocol and the SS7 protocol. SCCP provides additional routing and management functions for transferring messages other than call setup between signaling points. SCCP supports TCAP. MTP layers The MTP layers provide functions for basic routing of signaling messages between signaling points.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
227
Gs and Gs interfaces
Gs interfaces an SGSN and an MSC/VLR. Since the SGSN and the MSC/VLR communicate using different protocols, the messages are routed through SIG for conversion. The interface between the SIG and the SGSN is known as the Gs interface. Purpose of the Gs interface The Gs interfaces the SIG and the MSC/VLR. Purpose of the Gs interface The Gs is a Nortel Networks proprietary interface for passing decoded/encoded messages between the SGSN and the SIG. The Gs interface uses TCP/IP transport between the SGSN and SIG. The SIG encodes/decodes the SS7/TCAP/BSSAP messages destined for/received from the MSC/VLR in the SS7 network.
228
OAM
The Nortel Networks OAM solution for Network Management is branded PWI (Preside for Wireless Internet). It delivers an integrated UMTS management platform for the Access and the Core Network. Introduction The management layer includes functions and tools in the following areas: Integrated Management Platform (NSP: Network Service Platorm) Fault Management Configuration Management Performance Management Charging Gateway Function (CGF) Policy Services Management OSS Interfaces The OAM system uses: an IP network to interconnect the OAM components a client--server architecture to support centralized storage and processing of information,while at the same time distributing processor and memory--intensive graphical user interfaces amongst multiple client workstations, and reducing the required network bandwidth to network management workstations a distributed software architecture that integrates a number of existin OAM products into a single system, without particular regard to the physical boundaries of the hardware platforms that run the software stand--alone or semi--independent OAM systems for some components where the maturity of the technology does not permit full integration Nevertheless, the various boxes in the UMTS OAM subsystem do have clearly defined functions and relationships with each other and with the UMTS network elements. OAM features and functions The OAM system is made of a set of devices. The OAM features are distributed on these devices. The OAM system contains the following components: Main server Performance server OCAN (Off--line Configuration Management for UMTS Access Network) Network management workstation SDM (Supernode Data Manager) Shasta SCS (Service Creation System)
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
229
CGF (Charging Gateway Function) LIG--A (Legal Intercept Gateway-- Administrative part) CIPC (Call Intercept Provisioning Center) SNMP data collector Backup and restore server Figure 89 OAM functional architecture
Main server The main server collects and processes fault information for almost all of the elements in the network, and provides fault reporting and analysis services to the Network Management Workstations so that users can monitor the health of the network.
230
The main server also consolidates configuration data and configuration and working state control for Passport-based elements of the UMTS network. It provides configuration management services for these elements to the Network Management Workstations so that users can examine and change the configuration of the Passport-based network elements and enable or disable equipment and services in those network elements. Fault information The main server collects fault information from the following UMTS network elements: " iBTS (via mediating software in the iRNC Control Node) " iRNC Control Node " Wireless Gateway " UMTS DMS/MSC (via mediating software in the SDM) " UMTS DMS/HLR (via mediating software in the SDM) " GGSN (Shasta Broadband Service Node) " IWF (Inter Working Function) " PP7K " DNS and DHCP servers " Charging Gateway Server " LIG--D (Legal Intercept Gateway -- Delivery part) The main server does not collect fault information from the Radius server. The main server provides a variety of fault information storage, analysis and display services to the network management workstations, including: " graphical network display, with graphical alarm indications, network element grouping and drill--down capabilities " real--time filtering and display of fault messages " storage, filtering and analysis of historical fault information " rule--based correlation and analysis of fault information to abstract problems from raw data and help determine root causes. " SMTP trouble--ticket interface to external trouble management systems Configuration information and control The main server consolidates access to configuration information and configuration and operational state control for the following elements: " iRNC Control Node " iRNC Access Node " Wireless Gateway " IWF (Inter--Working Function) " PP7K The main server also interfaces to the Off--line Configuration Management for UMTS Access Networks tool (OCAN).
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
231
The main server is not involved in configuration and operational state control of the following network components: " UMTS DMS/MSC " UMTS DMS/HLR " GGSN " DNS, DHCP and Radius servers " CGF " LIG--D Performance server The performance server collects historical and real--time performance data and provides storage, filter, analysis and display services to the network management workstations. Historical performance data The performance server collects historical performance data from the following UMTS network components: " iBTS (via software in the iRNC Control Node) " iRNC Control Node " iRNC Interface Node " Wireless Gateway " IWF " UMTS DMS/MSC " UMTS DMS/HLR The performance server does not collect historical performance data from the following UMTS network components: " GGSN " SS7--to--IP Gateway (SIG) " DNS, DHCP and Radius servers " CGF Real--time performance data The performance server collects real--time performance data from the following UMTS network components: " iRNC Control Node " iRNC Interface Node " Wireless Gateway " SIG (SS7--to--IP Gateway) " GGSN " LIG--D " DNS, DHCP and Radius servers
232
The performance server does not collect real--time performance data following UMTS network components: " iBTS " UMTS DMS/MSC " UMTS DMS/HLR OCAN The Off--line Configuration Management for UMTS Access Network runs on a PC. It provides special tools for managing the configuration of the Access network. It interfaces with the Main Server rather than directly with the Access Network components. Network management workstation (U5 or PC) The network management workstation is either a Sun U5 or an Intel PIII--based personal computer. The network management workstation off-loads user-interface management from the following components: Main server Performance server SDM Shasta SCS Application server CGF The network management workstation runs the NSP application, which integrates user access to network management services into a single user interface. In some cases, the network management workstation must access two devices to manage some of the network elements. For example, the network management workstation uses the main server to obtain fault information regarding the UMTS DMS/MSC, but the network management workstation uses the SDM to access configuration information for the UMTS DMS/MSC. Thiis is not visible to the user. SDM (Supernode Data Manager ) Each DMS-MSC or DMS-HLR must have its own SDM. The SDM supports a number of element management services for the DMS-MSC and DMS-HLR, including fault, configuration and performance information management services. The user accesses these services via client software on the network management workstation. The SDM also runs optional software applications, including SBA (Supernode Billing Application) (see NTP--411--431--301) and PS (Provisioning Server). The SBA provides improved accounting data collection and forwarding relative to the base DMS capabilities. The PS provides a proprietary protocol interface so that third--party systems can provision service for subscribers through the SDM. The SDM sends fault information to the main server, but communicates configuration and historical performance information directly with the client PC. The Supernode Billing Application provides circuit core network accounting information to the CGF. The PS sends and receives subscriber provisioning information from the customers subscriber care systems.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
233
Shasta SCS (Service Creation System) The Shasta SCS provides configuration services, including service provisioning, for the GGSN. The network management workstation communicates configuration information directly with the SCS rather than through the main server. The SCS sends fault information to both the SCS and to the main server. There is no automated synchronization between the fault information on the SCS and the fault information on the main server. CGF (Charging Gateway Function) The CGF accumulates accounting information from the following UMTS network components: iBTS (via software in the iRNC Control Node and the 3G--SGSN) iRNC Control Node (via software in the 3G--SGSN) DMS/MSC (via the Supernode Billing Application in the SDM) GGSN (Shasta Broadband Service Node) The CGF post-processes the information it receivesfrom the various sources, aggregates it and passes it on to an external billing system. LIG-A (Legal Intercept Gateway - Administrative part) The LIG--A provides centralized packet call interception for multiple Wireless Gateways. The LIG--A is provided by Comverse and runs on a Sun workstation. CIPC (Call Intercept Provisioning Center) The CIPC provides centralized circuit call interception provisioning for multiple call servers. The CIPC runs on an HP B2000. Refer to NTP 411--4241--550 CNN CS/HLR Call Intercept OA&M Manual for more information. SNMP data collector The SNMP data collector collects SNMP data from the GGSN. Backup and restore server The backup and restore server provides a single point for managing both network configuration data and OAM subsystem software. It uses Computer Associates software management products.
234
OAM hardware description

The UMTS OAM solution uses a limited range of hardware platforms for a large range of applications. This use of common hardware platforms reduces support cost and spares inventories.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
235
Figure 90 Physical OAM architecture
236
OAM hardware components The OAM system contains the following hardware components: servers dual disk array devices client " client workstations " PC Client OAM Network equipment " " " " " " " Ethernet switch switch/router terminal server Ethernet Hub (optional) printer Uninterruptible Power Supply (UPS) terminal server and modem
Servers The following servers are used for OAM: E4500 E250 U10 E450 E4500 The E4500 is used for the Main Server and the Performance Server. This server contains the following components: two (Performance Server) or four (Main Server) Central Processing Units (CPUs), 400 MHz, with 8 Mbytes of external cache memory and 2 Gbytes of RAM each two internal disk boards of 2 x 18.2 Gbytes two graphic input/output (I/O) boards (one graphic board and one SBUS board, Fast Ethernet, SCSI-2, two FC-AL sockets) three mandatory power/cooling modules and one optional power/cooling module one internal 4-mm DDS-4 drive (20 to 40 Gbytes) one internal Digital Video Disk--Read Only memory (DVD-ROM) four GBIC modules 100 Mbyte/s FC-AL for connection to disk array device two Quad fast Ethernet SBUS boards one graphic controller (Creator 3D) one key in the locked position This means that the system is running in secure mode and will not respond to commands from the console for Open Boot Prom (OBP). one 21 color graphic monitor with one keyboard (optional) one international type 6 country kit (optional) See the OAM Main and Performance Server Reference Manual (UMT/DCL/DD/0007) for complete details.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
237
Figure 91 Ultra Enterprise 4503 server
238
E250 The E250 is used for the following applications: Shasta S CS server Policy services for application manager, directory/server manager, database/server manager, Radius server CGF Centralized backup and restore The E250 is a workgroup server with 2 CPUs and 6 -- 36.4--Gbyte hard disks. Dimensions are 51.7 cm high, 26.2 cm wide (35.3 with castors), 73.2 cm deep. Weight is approximately 118 lb fully configured. U10 The U10 is used for DNS and DHCP server. The U10 is a workstation computer. It is used for the distributed DNS and DHCP functions in the UMTS network. Dimensions are 40.2 cm high, 17.6 cm wide, 43.5 cm deep. Weight is approximately 44 lb. A large number of relatively small DNS and DHCP servers are used in preference to a smaller number of large servers because of network performance considerations. E450 The Sun E450 is used as a central server for data backup and software management for the OAM subsystem itself in large networks (more than 1000 iBTS). The Sun E450 is a workgroup server with 4 CPUs, 4GB RAM and 4x18GB hard disks. Dual disk array devices The disk array device is called StorEdge Array by Sun. The disk array device provides a server extension. It consists of two drive ends that are equipped with nine disks each. The following components are accessible: disk drive The nine disk drives are located behind the panel at the front of the disk array device. One disk array device is equipped with 9 disks of 73 Gbyte. controller board The controller board contains the Redundant Array of Inexpensive Disk (RAID), one host Fibre Channel Interface, an Ethernet 10BaseT interface, an RS-232 serial port, and 256 Mbyte of high-speed SDRAM data cache. interconnect board This board contains the interface and two connectors for interconnecting multiple disk array devices. power and cooling unit There are two modules for redundancy with a power supply, two cooling fans, an uninterruptible power supply (UPS) battery, and status indicator LEDs for ac power. The dual disk array devices are shown in the following figure.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
239
Figure 92 Dual T3 disk array devices
240
Client Two types of client are used in OAM: client workstation " U5 The U5 is used as a Network Management Workstation. It supports client software for the various network management applications. For UMTS version 1.2, it supports the software for a 3GPP--compliant fault management interface. This software is to be integrated into the Main Server for later releases. The U5 is a desktop computer system. Dimensions are 11.2cm high, 43.6cm wide and 43.9cm deep (4.4 x17.2x17.3 ), plus monitor. Weight is approximately 18kg (36lb). PC client The PC is used as a Network Management Workstation. It supports client software for the various network management applications. The PC is a desktop computer system. The recommended minimum configuration is " Pentium III 866Mhz or higher " 512 MB RAM " 30 GB disk " DVD ROM drive " Floppy drive " Ethernet interface card " Color graphics board " 19--inch color monitor " Windows NT 4.0 Service Pack 6a Ethernet switch The OAM segments by a filtering device to guarantee bandwidth to the OAM equipment. This is especially important for the connections to the servers and to the switches and routers that connect a given site to the UMTS network and to other OAM sites. Nortel Networks supports two Ethernet switches for this application: the Business Policy Switch 2000 and the Passport 8600 with 6 or 10 slots. The Business Policy Switch 2000 is an Ethernet switch with QoS and 4 auto--sensing Ethernet 10Base--T/100Base--TX ports. It is a stackable switch (up to 8 boxes and 192 Ethernet ports) depending on the required Ethernet connections. The stack has a redundant fail--safe cascade architecture that uses a loop connection. WAN access The OAM LAN--to--WAN interface is through a switch/router with Ethernet ports on one side and IP over ATM ports on the other. The switch or router is used to connect servers to network elements, remote PWI clients, and any remote external manager. A customer may require two routers or switches for each site for redundancy. Nortel Networks recommends the Passport 7480 with 16 slots (14 functional processors) for WAN access. It can provide 2--100Mb Ethernet ports on one functional processor, as well as V35, V11, DS1, DS3, E1, E3 and OC3 interfaces, and can handle IP, X25, Frame Relay, ATM and PPP protocols.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
241
Ethernet hub Network management workstations can connect to the Ethernet LAN via a hub instead of directly to a port on the Ethernet switch. Nortel Networks recommends the BayStack 253 Ethernet hub for this purpose. The BayStack 253 is a member of the BayStack 250 series and has 24 auto--sensing Ethernet 10Base--T/100Base--TX ports. It is stackable (up to 5 boxes and 120 Ethernet ports) depending on the required number of Ethernet connections. Terminal server The terminal server connects serial port A on the various servers to the LAN so that crafts people can access the system console on each server from a single workstation using Telnet. Nortel Networks recommends the NBase Xyplex 1600 series terminal server. The 1600 terminal server has a 10 Mb Ethernet port on one side and several RS232/V24 115.2 kbps serial ports on the other side (the exact number depends on the model of terminal server). UPS (Uninterruptable Power Supply) Nortel Networks strongly recommends a UPS to protect the servers against short power--supply failures and micro--cuts. Most hardware outages are due to power failures. Nortel Network recommends the APC Matrix 5000 UPS, depending on the load to be secured. Printers Nortel Networks recommends the LEXMARK T614N printer with a direct connection to the Ethernet LAN to be shared by all users at a given site. Cabinets Nortel Networks recommends the Sun 72 cabinet to rack--mount the servers and storage arrays. The Ethernet switch, hub, terminal server and WAN access switch/router can also be mounted in the Sun 72 cabinet. Fault protection strategy The protection strategy for the OAM hardware consists of two parts: fault tolerance of the basic Sun 4500 hardware, and an emergency recovery strategy using cold--standby of redundant servers. The Sun 4500 uses redundant power supplies, cooling modules, processors, memory and mass storage, and the operating system software automatically recovers from the failure of a redundant component and redistributes the processing load until the failed component can be replaced. Power supplies, cooling modules and individual disks in a RAID array can be replaced without service interruption. Emergency recovery plans call for daily data backups and the use of cold standby servers. Cold standby servers are servers connected to the Ethernet LAN with a complete but inactive software installation. Three hardware configurations are proposed: 1 site -- server redundancy 2 sites -- 1+1 site redundancy 3 or more sites -- 2:1 site redundancy
242
OAM IP network The UMTS OAM&P subsystem relies on a IP network in addition to the UMTS transport network for communication with network entities. The exact design of this network is different for each network, but the over--all layout is conceptually similar to that shown in the figure. The DNS, DHCP and Radius servers are actually network elements, but are included in the figure because they may be resident on the same LAN as the rest of the OAM servers.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
243
OAM software
Each type of network management service is described separately according to the FCAPS model (Faults, Configuration, Accounting, Performance, Security). The following architectural model describes the layering of the software in the OAM subsystem. The model is one of layers, as depicted in the figure: Presentation Processing Mediation Element Management Systems Network Elements Note that Accounting and Security, having very different processing and user interface requirements from Faults, Configuration and Performance, are not part of this architecture.
244
Figure 93 Generalized FC&P software architecture
Presentation The Presentation layer is the layer that the user sees. This software is (typically) located on the PWI Client computer. Note that this is not one piece of software, but a collection of several pieces, including the NSP client and various client packages like the Shasta SCS client (GUI) and the OMC--S client (GUI). This off loads the machines responsible for the actual data processing. Processing The Processing layer collects, processes, stores and retrieves fault and performance information. The processing of configuration information typically occurs at a higher (Presentation) or lower (element management or network element) layer. This works well from a technical standpoint, but makes it a little more difficult to understand the software. The processing layer resides on the Main and Performance servers. The individual software applications at the Processing layer are called Building Blocks. For more information on Building Blocks, refer to NTP--450--3031--338 Preside for UMTS Solution Guide.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
245
Mediation The Mediation layer adapts information from the various network elements and element management systems to a common interface on the processing layer so that a variety of network products can be managed using the same Processing and Presentation layers. The software in the Mediation layer goes by a number of different names, depending on the exact products involved; in the UMTS product, the objects in this layer are all called device adaptors (DA). Most, but not all of the device adapters are on the main server. EMS (Element Management System) The EMSs, where they exist, each perform Fault, Configuration and Performance data processing for a single type of network element. The Mediation layers integrates them into the over--all OAM subsystem. Some of the ElMSs reside on the main server, others reside on stand--alone or other shared platforms. NEs (Network Element) The NEs include all of the UMTS networks elements, as well as some of the OAM subsystem platforms, like the CGF. Though the CGF is not essential to carrying UMTS user traffic, from a fault, configuration and performance data management perspective, it emits data just like any other network element.
246
Fault Management
This module describes the functional blocks (primarily software) that collect, store, analyze and present fault information. Figure 94 Fault Management architecture
Fault Management Software implementation The Fault Management software is implemented in the following elements: Main server SDM Shasta SCS Application Server and Server Managers Network management workstation
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
247
Main server The main server contains three kinds of fault management software: Element Managers Device Adapters NSP and other Fault Mangement applications Element Managers Element Managers collect fault information from UMTS network elements and forward it to the NSP and other Fault Management software via device adapters that adapt the element managers native data formats to a common format. Element managers include the following: Access Module The Access Module provides fault and configuration management services for the access network. For Fault Management, it integrates fault information from the iBTS and iRNC Control Node, and from the iRNC Interface Node via fault information collected by Multi--service Data Manager and forwarded to the Access Module. The access module then provides the fault information to the access device adaptor. Multi--service Data Manager The Multi--service Data Manager is the element manager for Passport--based devices (iRNC Control Node excepted for historical reasons). It provides fault, configuration and performance management services for Passport--based devices, including iRNC Interface Node, Wireless Gateway, IWF (Inter--Working Function), PP7K. It also integrates fault information from IP--based devices by means of the fault management adapter. It provides fault management information to the NSP and other Preside Service Assurance software via the Multi--service Data Manager Device Adaptor. FMA (Fault Mangement Adapter) The FMA is not a device adapter in that it does not interface an element management system to the Preside Service Assurance software. Instead, it interfaces devices that produce fault information in the form of SNMP trap messages to the Multi--service Data Manager element manager. These devices include the CGF, the SS7/IP Gateway, the LIG--D and the GGSN. DA (Device Adapter) Device Adapters interface individual element managers to NSP and other Preside Service Assurance software. Device Adapters used for Fault Management include: Access Device Adapter Multi--service Data Manager Device Adapter XA--Core Device Adaptor (for element managers for XA--Core--based DMS systems) NSP and other Service Assurance Software The NSP and other Preside Service Assurance Software integrate and process the fault information from the element managers for presentation to the users via the PWI Client computers. The various fault management software available includes (but is not limited to): Fault Management (collection) The core software is the Fault Management software building block, which collects together the fault information from all of the different sources and then provides it to the other fault management software.
248
NSP (Network Services Platform) NSP provides a graphical user interface for network management. Users may define hierarchical groups of network elements. Elements may be members of multiple groups so that users can define views of the network that are best suited to their job. When a user views a group in NSP, NSP provides the number of alarms in the group as well as the severity of the most critical alarm. If a user opens the group to view the network elements, they see a summary of alarms for each element, as well as the most severe alarm for that element. If the user would like more detailed information, they are able to select an element and invoke an Alarm display. This is a textual display that provides more information about the alarms on the network element in question. When users need the ability to dig deeper into problems facing the network element that cannot be done with the native NSP tools, NSP provides the capability for a user to launch external applications (based on a pre--defined configuration). The launching of these tools is done in context . This means that any information the tool needs about the NE is passed to it (that is IP address, NE name, ...) HFB (Historical Fault Browser) HFB stores fault information and lets users retrieve it, filter it and generate reports based on it using a graphical user interface. PA (Problem Avisor) PA uses a user--defined rule base to identify patterns or correlations in fault information. These correlations are used to abstract problems from the fault information. The PA reports and stores problems, recommends corrective action (as stored in the rule base) and lets users can manage problem in much the same way people are used to managing alarms. TT (Trouble Ticketing) TT provides an SMTP interface toexternal Trouble Management Systems (Remedy and Clarify, for example). Users can raise a trouble ticket on the external system directly from the PWI Client and link it to an alarm in the OAM subsystem; users of the trouble management system can then manage the alarm directly from the external system. External OSS interface A 3GPP--compliant interface is provided to external Operations Support Systems. SDM The SDM--FT (Supernode Data Manager) is the hardware platform for the element manager for the UMTS DMS/MSC and the UMTS DMS/HLR. A number of element management applications can run on the SDM -- the OMC--S element manager provides fault, configuration and performance management services for the UMTS DMS/MSC and the UMTS DMS/HLR. The SDM forwards fault information to the XA--Core Device Adaptor. Shasta SCS The Shasta SCS provides fault and configuration management for the GGSN. However, the fault management in the SCS is not integrated into the over--all fault management supported by the NSP. Instead, the GGSN sends SNMP traps directly to the FMA on the main server. The OAM subsystem does not synchronize the SCS and NSP.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
249
(AS) Application Server and SM (Server Manager) The AS and the SMs together form the element management system for the DNS, DHCP and Radius servers. The AS manages the user interface to the database and the directory. The SMs in turn manage the interface to the DNS, DHCP and Radius servers. It is not significant from an OAM point of view as to which hardware platforms support the database, directory and Web--logic server. The AS hardware supports both the AS software and the Preside Policy Services Device Adaptor. The AS forwards fault information to the Preside Policy Services Device Adaptor, which in turn forwards fault information to the NSP and Preside Service Assurance Software on the main server. Network management workstation The software running on the network management workstation ties the rest of the Fault Management together into a single graphical user interface. It supports clients for functionality beyond simple reporting (that is, for Historical Fault Browser, Problem Advisor and Trouble Ticketing).
250
Configuration Management
This module describes the functional blocks (primarily software) that collect and store configuration management information, and allow users to change the configuration of network elements. Configuration in this context includes the configuration of purely software components, configuration of data required to support hardware components and querying and changing of the actual working state of the equipment (for example, In Service or Out Of Service, or Active versus Locked.)
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
251
Figure 95 UTRAN configuration
252
Configuration Management software implementation The Configuration Management software is implemented in the following elements: Main server OCAN SDM Shasta SCS Application Server and Server Managers Network management workstation Backup and restore server Main server The main server supports two element management applications, the Access Module and the Multi--service Data Manager. The Access Module provides fault and configuration management services for the access network. For configuration management, it integrates configuration and working state control for the iBTS and iRNC Control Node, and for the iRNC Interface Node via the Multi--service Data Manager. The access GUI on the PWI client provides the user interface to the configuration and working state control in the Access Module. The Multi--service Data Manager manages Passport--based devices (iRNC Control Node excepted for historical reasons). It provides fault, configuration and performance management services for Passport--based devices, including: iRNC Interface Node Wireless Gateway IWF PP7K The Multi--service Data Manager provides configuration and working state control services for the iRNC Interface Node to the Access Module. The MDM Architect GUI on the PWI Client provides the user interface to the configuration services in the Multiservice Data Manager. OCAN The OCAN (Off--line Configuration Management for UMTS Access Networks) provides specialized tools for managing the configuration of the Access Network. It allows the user to build the configuration of the network and verify it off--line, and then down--load the configuration in bulk to multiple network elements. It also allows the user to upload the configuration from the network elements to capture changes to RF tuning and other data made on the fly . SDM The SDM (Supernode Data Manager) is the hardware platform for the element manager for the UMTS DMS/MSC and the UMTS DMS/HLR. A number of element management applications can run on the SDM -- the OMC--S element manager provides fault, configuration and performance management services for the UMTS DMS/MSC and the UMTS DMS/HLR. The OMC--S GUI on the networkmanagement workstation provides the user interface to the configuration services on the OMC--S. The Provisioning Server (PS) is an optional application that runs on the SDM that is attached to the UMTS DMS/HLR. It provides a protocol interface for external systems to configure services for mobile subscribers.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
253
Shasta SCS The Shasta SCS provides fault and configuration management for the GGSN. The SCS GUI on the network management workstation provides the user interface to the configuration management services on the SCS. Application Server and Server Manager The Application Server and the Server Managers together form the element management system for the DNS, DHCP and Radius servers. The Application Server manages the user interface to the Database and the Directory. The Server Managers in turn manage the interface to the DNS, DHCP and Radius servers. It is not significant from an OAM point of view as to which hardware platforms support the Database, Directory and Web--logic server. Network Management Workstation NSP Desktop GUI and associated software The NSP GUI and associated software integrates the various configuration management tools into a single user interface. The Preside Desktop GUI allows the user to launch the various configuration tools directly from the graphical network display by selecting the icon representing the network element the user wishes to configure and launching the configuration tool, either with a double--click or by selecting the tool from a pop--up menu (depending on the network element and the specific configuration of the Preside Desktop GUI). The configuration tools available on the Preside Desktop GUI include: " SA (Service Accounting) GUI -- this is the user interface for the Charging Gateway Function " Access GUI -- this is the user interface for the Access Module, which allows the user to configure and control the Radio Access Network. " MDM Architect -- this is the configuration tool for Passport--based devices, including: iRNC Interface Node, Wireless Gateway, IWF,PP7K " SIG (SS7/IP Gateway) CLI (Command Line Interface) -- this is the user interface to the SIG. " OMS--C GUI -- this is the OMC--S client software. It has the same functionality as when the OMC--S is deployed in a stand--alone workstation. " SCS GUI -- This is the Shasta SCS Client. It has the same functionality as when the SCS is deployed in a stand--alone workstation. " PS (Policy Services) GUI -- This is the Management Console for the Server Managers, and the DHCP, DNS and Radius servers. Backup and Restore Server The Backup and Restore Server provides data security services to the following: Main Server Performance Server Shasta SCS Charging Gateway Function Application Server and Server Managers
254
Backup, restore and install (BRI)

BRI refers to the backup, restoral and initial installation of software and system configuration information. Functionally, BRI is a sub--set of the Configuration category in the FCAPS model, but in the UMTS OAM subsystem, BRI for the OAM subsystem and many system components is the responsibility of a software subsystem separate from the integrated configuration management subsystem. An additional BRI server at the NOC can provide a central repository for software (as opposed to configuration information) and drive both individual software installations on new equipment and upgrades of software across many network components. BRI server The BRI Server provides a central location for backup and restoral of software and configuration information on the servers of the OAM subsystem. It runs on the Backup and Restore Server. BRI agents The BRI agents provides local services to the BRI Server. BRI Agents run on: the Main Server the Performance Server the Charging Gateway Function server the Shasta SCS server the Policy Services servers (Application Server, Directory and Database) MDM The configuration data stored in MDM serves as the backup for the configuration data in the actual network elements. MDM backs up the software and configuration data for: the Wireless Gateway the Interworking Function ther PP7K MDM also provides configuration information for the iRNC Interface Node to the Access Module, but backup of this network element is the responsibility of the Access Module. Access module The configuration data stored in the access module serves as the backup for the configuration for the iRNC Control and Interface Nodes. In turn, the iBTS configuration information stored in the iRNC Control Node serves as the backup for the iBTS. Off-line Configuration Management for UMTS Access Network (OCAN) The Off--line Configuration Management for UMTS Access Networks tool allows the user to upload the configuration from the network elements (via the Access Module) to capture changes to RF tuning and other data made on the fly . The operating company is responsible for deciding whether the files backed up by the BRI agent to the BRI server or the files uploaded to the Off--line Configuration Management for UMTS Access Networks tool should be considered the masters Shasta SCS The Shasta SCS backs up the configuration of the GGSN.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
255
Wireless Service Management

Wireless Service Management (WSM) is an extension to Configuration Management for the UMTS network. Specifically, it supports the configuration of network elements in order to provide service for specific subscribers. This includes everything from assignment of IP addresses (depending on the access model), configuration of authentication and authorization data, allocation of network resources (like voice mail storage) and so on. WSM components WSM consists of: Order Management System (OMS) OMS interface agents Objectel network inventory management system ASAP service activation system In addition, the WSM solution presumes that the customer is using a Clarify Customer Relationship Management system (CRM), and that Internet Name and Address and Radius services are provided using Nortel Networks Policy Services. CRM The Clarify CRM (Customer Relationship Management) serves as the UMTS networks master customer information database. It defines both who the subscribers are and what services they have subscribed to. Changes to the CRM are propagated through the WSM to affected network elements. In the event of a mis--match between information in the CRM and the network elements, the information in the CRM is considered to be correct. OMS (Order Management System) The Order Management System automates the task of implementing service orders across the network. It takes provisioning events generated by the CRM and follows a task flow to make the required changes happen. This could involve querying Objectel to determine what resources are available, directing ASAP to implement changes to the HLR (via the Provisioning Server on the SDM) and directing Policy Services (via the Application Server) to change the Directory for internet services. OMS interface agents The interface agents adapt both the OMS protocol (XML over HTTP) and the OMS API actions (for example, Add Subscriber ) to the Policy Services, ASAP and Objectel software. Though logically separate, the interface agents are implemented in a single multi--threaded process rather than as a number of separate processes. Objectel (Network Inventory Management System) Objectel maintains an inventory database of network resources that are consumed in the provisioning of services to individual subscribers. Examples of inventory include voicemail storage and HLR table space. The OMS can reserve network resources in Objectel, query resources assigned to a specific subscriber or free resources assigned to a specific subscriber. Objectel can implement a number of different algorithms for determining the resource pool (for example, which HLR) in which to make a resource reservation for a particular subscriber.
256
ASAP (Service Activation) ASAP carries out the configuration of network elements to implement a provisioning action. It interfaces to the UMTS network itself through the Provisioning Server (PC) in the CCN--HLR and the interfaces to applications and services, such as voicemail, WAP servers and SMS servers. WSM hardware The WSM software runs on a mix of Unix and Windows NT computing platforms. A final decision on what hardware will be used has not been made at this time.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
257
OCAN general presentation

OCAN overview The Off--line Configuration Management for UMTS Access Network (OCAN) is the Nortel Networks UMTS Access Network configuration tool. This product is an external application of the Nortel Networks OAM Access software. The OCAN offers a centralized configuration of all Nortel Networks RNS (multiple OAM Access) and a graphic representation of all RNS network elements and links. It also provides a centralized view of all UMTS Access Network parameters (frequency plans, hand--over, power control and radio resource management). The position of the OCAN in an operator network is illustrated in the following figure.
258
Figure 96
OCAN position in an operator network
Design
Cell planning
Optimization
Densification
Access Network Design Tools
Creation
Modification
Audit
OCAN
OAM Access
Access Network
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
259
Product definition The OCAN is a high--performance tool that helps design and configure the Access part of a UMTS network, based on UMTS recommendations. The OCAN tool can be used for configuration at every stage of an Access Network management: Data engineering of a new network Data engineering for network expansion or/and densification Data engineering for network optimization such as a frequency plan change. To perform these operations, the OCAN manages Access data coming from various sources (see the following figure): input data such as DRF Data Request Forms (Access Network parameters in ASCII file format) issued by customer Access Network Design tools, and database import coming from the OAM Access output data such as formatted DRF
260
Figure 97
Input/Output data of the OCAN - Functional view
Access Network Design Tools
DRF files
OCAN Network Configuration Tool
DRF files
OAM Access
Product scalability The OCAN can support either all or only some regions of a UTRAN network configuration. That means from a few hundred cells up to thousands in a workable and acceptable environment in terms of performances. Nevertheless operators can use several OCAN tools to follow the regional split of their network.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
261
OCAN architecture The OCAN is a database PC application. It is based upon an engine that provides high--level capabilities and manages a DRF database. On top of this generic layer, a Microsoft COM layer provides a translation function that builds the object model from the DRF database. The COM layer also provides the configuration assistants and the checks. The aim of this tool is to manage the database designed for engineering: load/export of files in DRF format, datafill assistant, network checks, equipment model management, audit. Four functional levels are defined to perform the OCAN engineering: Database level: to provide database services (database management, checks, loaders, etc.) based on the Microsoft MSDE software. Core mechanism level: to provide configuration mechanisms (templates, equipment models, session log, default values and datafill rules, etc.). Graphical network operation level: to provide network operation services (network tree explorer, site creation, parenting management, internal views). Audit and report level: to provide audits on a full network or nodes and offer an open access to the OCAN database. The extracted information can be treated with Microsoft Office facilities like Excel. The PWI Offline Configuration architecture is illustrated by the following figure. Note that a single Offline Configuration client can support multiple PWI Main Servers, and thus can support very large networks.
262
A TCP/IP connection with the OAM Access is mandatory in order to emulate an OAM Access session.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
263
Accounting Management
This paragraph describes the functional blocks of the OAM subsystem that collect accounting data. Charging Gateway Function The Charging Gateway Function provides accounting management for the UMTS network. The Charging Gateway Function is based on Nortel Networks Service Accounting software. It accumulates and integrates accounting information from iBTS (via 3G--SGSN) iRNC Control Node (via 3G--SGSN) 3G--SGSN GGSN UMTS DMS/MSC (via SDM running SBA) The Charging Gateway Function passes on accounting data to an external billing system. SDM The SDM (Supernode Data Manager) is the hardware platform for the element manager for the UMTS DMS/MSC and the UMTS DMS/HLR. It can run an optional accounting data package, the Supernode Billing Application, which provides enhanced account relative to the base DMS accounting services. For more information on SBA, see NTP 411--4231--301 Supernode Billing Application OA&M Manual.
264
Performance Management
This module describes the functional blocks of the OAM subsystem that collect, store, analyze and display data related to the performance of the UMTS network. Performance Management is split into: Historical Performance Management Historical Performance Management handles data that is used for long term maintenance, planning and growth of the network. Real--Time Performance Management Real--Time Performance Management is about performance data that can be collected and analyzed in real--time to support day--to--day traffic management decisions. It is a separate system within the UMTS OAM subsystem. Figure 98 Performance Management architecture
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
265
Historical Performance Management Historical Peformance Management is distributed on the following OAM elements: Performance Server SDM SIG CLI NSP GUI Performance Server The Performance Server supports two performance data collection applications, three performance data mediation applications and one performance data analysis application. Data collection -- APM and MDP The Performance Server supports two performance data collector applications: " the Access Performance Manager The Access Performance Manager (APM) collects data from the iBTS and the iRNC Control Node and forwards it to the Performance Management Optimization application for storage, processing and display to the end--user. " the Management Data Provider. The Management Data Provider collects performance data from Passport--based devices (except for the PP7K), using FTP to make periodic bulk transfers, reducing the load on the OAM data network. It forwards data regarding the iRNC Interface Node to the Performance Management Optimization application to be combined with the data from the Access Performance Manager for storage, processing and display to the end user. Mediation -- ADI, PDI and CDI The Performance Server supports three mediation applications: " the Access Data Interface " the Packet Data Interface " the Circuit Data Interface These applications adapt the performance data from the three different domains to a common format for the performance data processing and storage application, Performance Management Optimization. Processing -- PMO The Performance Management Optimization application provides storage, retrieval, analysis and display functions for performance data. Its primary focus is on the air interface but integrates data from across the domains to provide performance reports. Preside Performance Data Manager and Preside Performance Reporting provide storage, threshold monitoring, filtering and report--generation for performance data. Users access these applications through the Network Management Workstation. SDM The SDM runs the OMC--S element management application. The OMC--S provides fault, configuration and performance management services for the CCN--CS and the CCN--HLR. Users access performance management services through the Network Management Workstation. As well, the OMC--S provides raw counters to the Performance Management Optimization application via the Circuit Data Interface.
266
SIG CLI Performance data for the SS7/IP Gateway is available through the SIG command line interface, which can be accessed via the Network NSP GUI Users access the performance management applications through the NSP GUI. Real-time Performance Management The OAM subsystem collects and presents real--time performance data from two elements: Performance Server Network management workstation Performance Server Two applications for collecting real--time performance reside on the Performance Server: the MDM Performance Monitor The MDM Performance Monitor collects real--time performance data from the following Passport--based devices " iRNC Control Node " iRNC Interface Node " Wireless Gateway " IWF (Inter--Working Function) The MDM Performance Monitor forward performance data to the MDM GUI on the for display to the users. the Advent Net SNMP data collector The Advent Net application is a MIB browser that allows the user to poll the following devices for real--time performance data: " Charging Gateway Function " SIG (SS7/IP Gateway) " GGSN " LIG--D " DNS, DHCP and Radius servers Network management workstation The Network Management Workstation runs the MDM GUI which present the real--time performance data to the users.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
267
Security Management
Security Management in the context of the UMTS OAM subsystem refers to access control for users of the OAM subsystem. This is enforced through the use of password protection on individual network elements, element managers, and through the NSP client software. The Netscape Directory Service (NDS) provides authentication for logon of users of the NSP client. This is an LDAP directory that is used by NSP to store user, group and NSP configuration information, and is resident on the Main Server. In addition, the NSP client will enforce access controls to allow an administrator to restrict a user to viewing only the areas they have access to. It also restricts the users from accessing any information, or performing any tasks they are not permitted to do. The design of the UMTS OAM subsystem assumes that the underlying data network is isolated from all external networks. Many of the network elements in the UMTS network have command line interfaces accessible via Telnet. Network administrators should take this into account in administering the network elements.
268
Regulatory information
Regulatory requirement compliance The equipment generates, uses, and can radiate radio frequency energy. If not installed and used in accordance with the instruction manual, the equipment may cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference. The EMC requirements have been selected to ensure an adequate level of compatibility for apparatus at residential, commercial, and light industrial environments. The levels however, do not cover extreme cases which may occur in any location but with a low probability of occurrence. In particular, it may not cover those cases where a potential source of interference which is producing individually repeated transient phenomena, or continuous phenomena, is permanently present, for example a radar or broadcast site in the near vicinity. In such a case it may be necessary to either limit the source of interference, or use special protection applied, to the interfered part, or both. For the integrity of the product, the antistatic wrist shall always be used for any operation and maintenance on Nortel Networks systems. Compliance for American countries (North and South) The Nortel Networks UMTS iBTS has not been qualified against American market requirements since the currently supported frequency bands do not correspond to the allocated UMTS spectrum. As a consequence, Nortel Networks iRNC has not been demonstrated to comply with American market requirements. Updates will be made to this section when appropriate. iRNC compliance The Nortel Networks iRNC has been demonstrated to comply (either by testing or file submission) with the essential requirements of the following European directives : EMC directive (89/336/EMC) The following standard has been applied to demonstrate compliance with this European Directive : EMC : ETS 300 386 version 1.2.1 In addition, the iRNC has been demonstrated to comply with the following standard: Safety : EN 60950, Edition 3, 2000
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
269
iBTS compliance As a radio product, the Nortel Networks UMTS iBTS falls under the requirement of the RTTE (Radio and Telecom Terminal Equipment) European directive 1999/5/EEC. The RTTED directive covers essential requirements in the field of : protection of the Health and Safety of the user and any other person, including the objectives with respect to safety requirements contained in the Low Voltage directive (73/23/EEC) the protection requirements with respect to EMC contained in Directive 89/336/EEC effective use of the Radio spectrum allocated to terrestrial/space radio communication and orbital resources so as to avoid harmful interference The routes and standards used to demonstrate compliance with these essential requirements are outlined in the following paragraphs. iBTS safety Compliance with the essential requirements of Safety has been demonstrated using EN 60950, edition 3, 2000. iBTS EMC Compliance with the essential requirements of EMC has been demonstrated using 3GPP TS 25.113 version 3.4.0 standard. iBTS radio compliance Compliance with the essential requirements of effective use of the radio spectrum has been demonstrated using 3GPP TS 25.141 version 3.5.0 standard. iBTS health protection RTTE directive health requirement covers the field of human exposure to radio frequency electromagnetic fields. As there is currently no well established test specification and requirements within Europe, it has been deemed sufficient to demonstrate compliance with the North American requirements (FCC OET bulletin 65) through calculation as described in the following: iBTS radiation The maximum radiated power level authorized by the standard (TS 25.113) is 30 dBm (or E = 5.4 mV/m) for frequencies above 1 GHz. As a consequence, the maximum power density radiated by the iBTS will be S=7.9*10--9 mW/cm@ (according to FCC OET bulletin 65, S=E@/3770). The North American maximum permissible exposure level for the general population (uncontrolled exposure areas) ranges from S = 0.66 mW/cm@ to S=1.0 mW/cm@ for frequencies between 1 GHz and 1.5 GHz and S= 1.0 mW/cm@ for frequencies.
270
Radiation of a system Assumptions: " iBTS configured with 2 Power Amplifiers (PA) on a sector, PAs configured in 45--Watt mode. " Feeder losses ~ 1 dB. " Antenna gain : G = 18 dBi ~ 63 The power delivered to the antenna (per PA) is P=PA power DDM losses Feeder losses ~ 45 dBm (~ 31.6 W). As per FCC OET Bulletin 65, the power density can be estimated by S=P*G/4&R@ (R is the distance to the source). The Maximum Permissible Exposure level for uncontrolled access locations is S = 1 mW/cm@ (at UMTS frequencies). Thus the safe approach distance for general population is R=5.63 m. This distance is the one at which the limit level will be reached in the main beam of the antenna and would usually be achieved by the fact that this antenna is mounted on a pole. Conclusions As demonstrated before, it is deemed that the Nortel Networks iBTS complies with the general requirements (FCC OET Bulletin 65) for health protection. It should also be noted that exposures inside a building can be expected to be reduced by at least 10 to 20 dB due to the attenuation caused by building materials in the wall and roof of the building (source : FCC OET bulletin 65). Other compliances In addition to the aforementioned compliances, and as a voluntary demonstration of compliance, the Nortel Networks iRNC and iBTS comply (as appropriate) with the essential requirements of CTR 12 / CTR 13 on E1 PCM lines. These standards cover essential requirements for the physical and electrical characteristics of the terminal equipment interface for unstructured leased lines (U2048S) and structured leased lines (D2048S). Conformance with these requirement does not guarantee end--to--end interoperability. Compliances for other regions/countries For countries outside Europe and the Americas, the requirements of European countries usually apply. It is not possible to list all the applicable approvals / compliances as they will be dependent on the markets and products considered. Please contact your local Nortel Networks representative for more information. Operational conditions The aforementioned standards compliance of the products are based on the following operating conditions (called normal operation): Doors shall be closed and/or covers shall be in place. External cables shall be of the same type as specified by Nortel Networks. No modification of any mechanical or electrical characteristics of the product shall be made. Any change or modification made to the product without written approval from Nortel Networks releases Nortel Networks from subsequent responsibility regarding the standards compliance.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
271
Cable specifications The compliance to the aforementioned standards has been verified using cables as specified by Nortel Networks. The continuing compliance of the product relies upon use of the correct cabling scheme as well as use of identical type cables as specified by Nortel Networks. Refer to the installation guides for details on cable specifications. Product labeling The label may be located inside or outside the product, provided that the operation and/or maintenance personnel have the information when working on the product. American countries (North and South) Not applicable European Union countries This module gives the regulatory information specific to the Eurpoean Union contries for the iRNC and the iBTS. iRNC labelling To indicate compliance with the European directives (EMC and Low voltage), Nortel Networks iRNC bears the following information in a conspicuous location:
Manufacturers name Equipment designation Nominal voltage operating range and maximum rated current iBTS labelling To indicate compliance with the European RTTE Directive, the Nortel Networks UMTS iBTS bears the following information in a conspicuous location :
Manufacturers name Equipment designation Nominal voltage operating range and maximum rated current Labelling for other regions / countries Labeling for other regions and countries is performed as appropriate and required by the local regulatory framework.
272
ATM
ATM is a high--speed, low--delay, multiplexing and switching technology which can support any type of traffic. This technology was born out of the standardization efforts for Broadband ISDN which began in the CCITT in the mid--1980s. It was originally intimately bound up with the emerging Synchronous Digital Hierarchy (SDH). ATM key principles The key principles of ATM can be summed up in the following characteristics: layer 2 protocol connection oriented fixed length cells transparency transport of all services quality of service statistical multiplexing Layer 2 protocol ATM is considered as a layer 2 protocol in the OSI model. As a layer 2 protocol, or data--link protocol, ATM is concerned with the following functions: flow control between Customer Premises Equipment (CPE) and Data Terminal Equipment (DTE), and DTE to DTE detection of corrupted data sequencing of traffic conversion of a bit stream from the physical layer to a stream of frames for use by the network layer Connection oriented ATM is connection--oriented. That is, a direct connection is made between the source and the destination host for the data to transfer over. The addressing resolution occurs during call set--up and all data is routed at full speed through the network. This connection is referred to as a virtual circuit. Fixed-length cells ATM is a packet--oriented transfer mode based on fixed--length cells. Each cell consists of an information field and a header, which is used to determine the virtual channel and to perform the appropriate routing. An ATM cell is 53 bytes long, with 5 bytes of header information about the cell, and 48 bytes of user payload. Fixing the size of the packets ensures that no time-sensitive information is blocked behind an inordinately long cell. Transparency The information field of ATM cells is carried transparently through the network. No processing such as error control is performed on it inside the network.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
273
Transport of all services ATM supports the transport of all services, including connectionless services. To accommodate the various services, an adaptation function is provided to fit the information of all services into ATM cells. Quality of Service One of the key ideas in ATM is the idea of Quality of Service (QoS). As ATM was designed to support all types of traffic, including time-sensitive services, it was necessary to implement a system that would guarantee different levels of performance for different types of service. Five different types of service can be requested, each service class guaranteeing different levels of bandwidth, delay and jitter. Statistical multiplexing To use the available bandwidth as efficiently as possible, ATM employs statistical multiplexing. Statistical multiplexing allocates bandwidth only as needed, aggregating all traffic flows to minimize the need for transmission capacity. ATM network architecture The ATM network contains two main components: the ATM end--station (also known as the CSU) The end--station is equipped with Network Interface Cards (NICs) which handle the convergence and Segmentation and Recovery (SAR) of non--ATM protocols using the ATM Adaptation Layers (AAL). the ATM core switch The core switch has two main functions: " error detection " cell forwarding Four major AALs are presently supported: AAL--1 AAL--2 AAL--3/ 4 AAL--5 Each one is used for a different application. AAL--2 is the most interesting for UMTS networks as it defines the adaptation characteristics of time-constrained services such as voice and video, which can have variable bit rates.
274
Figure 99 ATM network components and communication protocols
Advantages of ATM The advantages of ATM are as follows: It provides variable bandwidth services (that is, statistical multiplexing). It supports non--standard virtual bit--rates. It supports the SDH hierarchy. It supports a wide variety of traffic types and multiple protocols. It facilitates time--sensitive services through the small fixed cell size.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
275
IP
Internet Protocol (IP) or Transmission Control Protocol/Internet Protocol (TCP/IP) as it is often referred to, describes the family of protocols which drive the Internet today. Indeed, any data network using IP is now referred to simply as Internet. IP is a mature technology, having been first introduced before the arrival of high--speed silicon circuits and, as such, is very simple and robust. IP key principles The key principles of IP can be summed up in the following characteristics: layer 3 protocol datagram connectionless logical addressing routing quality of service network management Layer 3 protocol IP is considered as a layer 3 protocol within the OSI model. Layer 3 or network layer protocols are responsible for the following functions: segmentation and re--assembly of large user data packets addressing delivery of user data QoS negotiation internetworking operations Datagram The fundamental component of an IP traffic flow is called a datagram. A datagram is a variable-length packet containing the header and the user payload. The datagram was designed to facilitate efficient transfer of user data. Only a small amount of overhead is needed to process and forward the datagram. The overhead generally takes up less than 1% of the transmitted bytes. Connectionless IP is a connectionless protocol. That is, traffic is routed on a hop--by--hop basis. At each node (called a router) within the network, the IP datagram header must be processed. The address is resolved and the packet is forwarded to either the next router along the path or directly to the destination host.
276
Logical addressing IP uses logical addressing to provide a uniform method of addressing all the nodes within a network regardless of their physical network connections. These logical addresses are structured in a notation called dotted--decimal. Routing The process by which an IP node forwards a data packet is called routing. In routing, the IP node examines the headers of an incoming datagram and extracts the destination address information. The router then consults its internal routing table to find out if it has a direct connection to the destination host. If there is no direct connection, the router calculates a cost value for all the possible routes to the final destination. The router then sends the datagram on the route with the lowest cost. Quality of Service The Integrated Services Architecture (ISA) is an attempt to bring QoS to IP--based networks. Resource Reservation Protocol (RSVP) is the part of the initiative that has had the most success. As in ATM, it attempts to define service levels in terms of constant bit rates, minimum delays and jitter guarantees. However, ISA has not had widespread success and it continues to be difficult to give guaranteed service levels in the connectionless domain. Network management IP was designed for simplicity and, as such, most of the network management and error checking procedures are moved to the upper layer protocols. This allows for efficient transfers, but lacks the network integrity to support time--sensitive applications. Advantages of IP IP has many advantages, some of which are given here: It is available on all platforms. It is a mature technology, well tested in the LAN and WAN. It is very efficient, only 1% is overhead. There is a large array of IP vendors and products.
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
277
Network animation
This UMTS overview has described the main components of the Nortel Networks UMTS01 solution. The following animation shows how a call progresses through the UMTS network. You must first select the type of call: voice or data. In both modes, you can unroll the animation continuously or step--by--step.
278
UMT/DCL/DD/0001 411--8111--101
Preliminary
01.08/EN
October 2001
UMTS01
Wireless Service Provider Solutions About the UMTS Network

Copyright ! 2001 Nortel Networks, All Rights Reserved NORTEL NETWORKS CONFIDENTIAL: The information contained in this document is the property of Nortel Networks. Except as specifically authorized in writing by Nortel Networks, the holder of this document shall keep the information contained herein confidential and shall protect same in whole or in part from disclosure and dissemination to third parties and use for evaluation, operation and maintenance purposes only. You may not reproduce, represent, or download through any means, the information contained herein in any way or in any form without prior written consent of Nortel Networks. The following are trademarks of Nortel Networks: *NORTEL NETWORKS, the NORTEL NETWORKS corporate logo, the NORTEL Globemark, UNIFIED NETWORKS, e-mobility, Passport, Shasta, Contivity, Preside. All other brand and product names are trademarks or registred trademarks of their respective holders. Publication Reference UMT/DCL/DD/0001 411-8111-101 01.08/EN October 2001 Printed in France
For more information, please contact: For all countries, except USA: Documentation Department 1, Place des Frres Montgolfier GUYANCOURT 78928 YVELINES CEDEX 9 FRANCE Email : umts-gsm.ntp@nortelnetworks.com Fax : (33) (1) 39-44-50-29 In the USA: 2221 Lakeside Boulevard Richardson TX 75082 USA Tel: 1-800-4 NORTEL 1-800-466-7838 or (972) 684-5935
Internet Address: http://www.nortelnetworks.com

v01 0108 en

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

v01 0108 en

Caricato da

Copyright:

Formati disponibili

Network, About

Wireless Service Provider Solutions

About the UMTS Network

: About the UMTS Network

About the UMTS Network

Wireless Service Provider Solutions

Copyright ! 2001 Nortel Networks, All Rights Reserved Printed in France

Nortel Networks Confidential

About the UMTS Network

Nortel Networks Confidential

Nortel Networks Confidential

About the UMTS Network

Nortel Networks Confidential

Nortel Networks Confidential

About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

About the UMTS Network

Nortel Networks Confidential

50 52 53 57 58 59 65 67 69 72 75 78 82 83 84 85 89 91 95 100 102 103 104 105

Nortel Networks Confidential

About the UMTS Network

Nortel Networks Confidential

Nortel Networks Confidential

About the UMTS Network

Nortel Networks Confidential

8 12 14 20 26 28 32 33 35 37 40 41 42 43 45 46 47 49 51 54 58 60 62 64 70 79 80 87 88 91 92 94 95 96 97 98 99 101 101 102

Nortel Networks Confidential

About the UMTS Network

Nortel Networks Confidential

Nortel Networks Confidential

About the UMTS Network

Nortel Networks Confidential

PAGE INTENTIONALLY LEFT BLANK

Nortel Networks Confidential

About this document

ABOUT THIS DOCUMENT

About the UMTS Network

About this document

Nortel Networks Confidential

How this document is organized

Nortel Networks Confidential

About this document

About the UMTS Network

About this document

Nortel Networks Confidential

PAGE INTENTIONALLY LEFT BLANK

Nortel Networks Confidential

Whats new in this UMTS network release

About the UMTS Network

Nortel Networks Confidential

UMTS general description

Nortel Networks Confidential

About the UMTS Network

Nortel Networks Confidential

UMTS01 release architecture

Nortel Networks Confidential

About the UMTS Network

Nortel Networks Confidential

Nortel Networks Confidential

Coverage area of the UMTS network

About the UMTS Network

Nortel Networks Confidential

Figure 2 Example of UMTS PLMN coverage area

Nortel Networks Confidential