Umts PDF

Principes et volutions de l'UMTS
sous la direction de Xavier Lagrange

fait partie de la srie RSEAUX ET TLCOMS dirige p a r Guy Pujolle
TRAIT I C 2 INFORMATION - C O M M A N D E - COMMUNICATION
SOUS la d i r e c t i o n s c i e n t i f i q u e de B e r n a r d D u b u i s s o n
Le trait Information, C o m m a n d e , C o m m u n i c a t i o n rpond au besoin

de disposer d'un ensemble complet des connaissances t f et mthodes
ncessaires la matrise des systmes technologiques.
Conu volontairement dans un esprit d'change disciplinaire, le trait IC2

est l'tat de l'art dans les d o m a i n e s suivants retenus p a r le comit
scientifique :
Rseaux et tlcoms
Traitement du signal et de l'image
Informatique et systmes d'information
Systmes automatiss et productique
Managment et gestion des STICS
Cognition et traitement de l'information
C h a q u e ouvrage prsente aussi bien les aspects f o n d a m e n t a u x

qu'exprimentaux. Une classification des diffrents articles contenus
dans chacun, une bibliographie et un index dtaill orientent le lecteur
vers ses points d'intrt immdiats : celui-ci dispose ainsi d'un guide pour
ses rflexions ou p o u r ses choix.
Les savoirs, thories et mthodes rassembls d a n s chaque ouvrage ont

t choisis p o u r leur pertinence dans l'avance des connaissances ou p o u r
la qualit des rsultats obtenus dans le cas d'exprimentations relles.
Liste des auteurs
Jean-Marie B O N N I N
ENST Bretagne
Rennes
Bruno J E C H O U X
Mitsubishi Electric ITCE
Rennes
Paul J O L I V E T
LG Electronics
Paris
Xavier L A G R A N G E
ENST Bretagne
Rennes
Philippe MARTINS
ENST
Paris
Loutfi NUAYMI
ENST Bretagne
Rennes
Sami T A B B A N E
Sup'Com
Tunis
Tunisie
Table des matires
Chapitre 1. Introduction l'talement de spectre 19

Xavier LAGRANGE
1.1. Introduction 19
1.2. Rappels de communication numrique 20
1.2.1. Principes des modulations numriques 20
1.2.2. Modle de transmission en bande de base 26
1.2.3. Action du canal de transmission 27
1.3. Etalement squence directe 29
1.3.1. Bits et chips 29
1.3.2. Bilan nergtique 30
1.3.3. Gain d'talement 32
1.3.4. Rcepteur en bande de base 33
1.3.5. Principes du rcepteur Rake 36
1.3.6. Intrt de l'talement de spectre pour combattre les multitrajets . 37
1.4. Principe du multiplexage par des codes orthogonaux 39
1.4.1. Matrices d'Hadamard et codes de Walsh 39
1.4.2. Multiplexage par les codes 41
1.4.3. Codes OVSF 43
1.5. Utilisation du CDMA en radiomobile 44
1.5.1. Diffrenciation des stations de base 44
1.5.2. Principe de transmission sur la voie descendante 48
1.5.3. Principe de rception sur la voie descendante 49
1.5.4. Principe de transmission sur la voie montante 49
1.6. Bibliographie 51
10 Principes et volutions de l'UMTS
Chapitre 2. L'interface radio UTRA-FDD 53

X a v i e r LAGRANGE et S a m i TABBANE
2.1.1. Architecture matrielle de l'UMTS 54
2.1.2. Architecture en couches 54
2.2. Caractristiques gnrales de la couche physique de l'UTRA-FDD . . 56
2.2.1. Caractristiques principales de l'UTRA-FDD 56
2.2.2. Trame de base 56
2.2.3. Modulation 58
2.3. Canaux physiques de donnes 58
2.3.1. Transmission descendante sur canal ddi (DPCH) 58
2.3.2. Canal physique descendant partag (PDSCH) 60
2.3.3. Canal de diffusion de donnes (S-CCPCH) 62
2.3.4. Transmission montante sur canal ddi ? 62
2.3.5. Canal d'accs PRACH 64
2.4. Canaux physiques de contrle 65
2.4.1. Canaux de synchronisation P-SCH et S-SCH 65
2.4.2. Canal pilote CPICH 67
2.4.3. Canal de diffusion des informations systme (P-CCPCH) 67
2.4.4. Canaux d'indication depaging (PICH) 68
2.4.5. Canal d'acquittement de prambule (AICH) 69
2.4.6. Autres canaux physiques 69
2.5. Principes des chanes de transmission 69
2.5.1. Chane de transmission sur la voie descendante 69
2.5.2. Chane de transmission sur la voie montante 70
2.6. Gestion de format de transport 70
2.6.1. Notion de format de transport 71
2.6.2. Combinaison de formats de transport 73
2.6.3. Variation dynamique des combinaisons de format de transport. . 74
2.6.4. Canaux de transport 76
2.7. Couche MAC
2.7.1. Fonctions de la couche MAC 77
2.7.2. Canaux logiques 79
2.7.3. Format des PDU de niveau MAC 80
2.7.4. Mode circuit et mode paquet 81
2.8. Synthse sur les diffrents canaux de l'UMTS et exemples 82
2.8.1. Exemple de canaux de donnes 82
2.8.2. Canaux physiques, de transport et logiques 84
2.9. Procdures radio 84
2.9.1. Mcanisme de recherche de cellule 84
2.9.2. Veille sur une cellule 85
Table des matires 11
2.9.3. Accs (sur PRACH) 89

2.9.4. Gestion du handover 91
2.10. Transmission de donnes haut dbit (HSDPA) 96
2.10.1. Canaux logiques et physiques pour le support du HSDPA . . . . 97
2.10.2. Codage et modulation adaptatifs (AMC) 98
2.10.3. Technique HARQ 100
2.10.4. Fast cell site selection (FCSS) 100
2.10.5. Squencement des paquets 101
2.10.6. Contraintes au niveau du nud B et des terminaux 101
2.11. Conclusion 102
2.12. Rfrences 102
Chapitre 3. Le mode UTRA-TDD et ses performances 105

Bruno JECHOUX
3.1. Philosophie de l'UMTS-TDD * 105
3.1.1. Effet proche-loin 107
3.1.2. Capacits du canal en UTRA-TDD et en UTRA-FDD 108
3.1.3. Gestion de l'interfrence extra-cellulaire 110
3.1.4. Facteur d'talement variable et multicode 110
3.1.5. Limitations du mode TDD 111
3.2. Introduction la norme : TD-CDMA et TD-SCDMA 112
3.2.1. Caractristiques d'UTRA-TDD 3,84 Mchips 112
3.2.2. Canaux physiques 114
3.2.3. Procdures de la couche physique 117
3.2.4. Caractristiques d'UTRA-TDD 1,28 Mchips 118
3.2.5. Procdures spcifiques du 1,28 Mchips TDD 120
3.3. Estimation de canal multi-utilisateur 121
3.3.1. Description du problme 121
3.3.2. Modlisation 122
3.3.3. Les estimateurs de canaux : estimateur maximum
de vraisemblance/filtrage adapt 125
3.3.4. Choix des midambules 126
3.3.5. Mise en uvre de l'estimateur de canal maximum
de vraisemblance 128
3.3.6. Performances de l'estimateur de canal maximum
de vraisemblance 129
3.4. Dtection conjointe 131
3.4.1. Description du problme, modlisation 132
3.4.2. Critres de rsolution du systme d'quations linaires 135
3.4.3. Performances de la dtection conjointe 138
3.4.4. Rduction de la complexit de la dtection conjointe 139
3.5. Allocation dynamique des ressources 141

3.5.1. Allocation des ressources aux cellules (DCA lente) 143
3.5.2. Allocation des ressources aux services (DCA rapide) 143
3.6. Synchronisation du rseau (3,84 Mchips TDD) 144
3.6.1. Prsynchronisation par le rseau 145
3.6.2. Synchronisation fine par horloge de rfrence (de type G P S ) . . . 145
3.6.3. Mcanisme de synchronisation fine 145
3.7. Annexe : modlisation du canal radio mobile 149
Chapitre 4. Le contrle de puissance dans l'UMTS 153

Loutfi NUAYMI
4.2. Prsentation du modle et formalisation du problme 154
4.2.1. Capacit et contrle de puissance dans un rseau cellulaire
CDMA 157
4.2.2. Classification des mthodes de contrle de puissance proposes . 160
4.3. Contrle de puissance et autres fonctions de la gestion
des ressources radio 165
4.3.1. Accs et contrle d'admission 165
4.3.2. Respiration de cellules 166
4.3.3. Contrle de puissance et soft handover 168
4.4. Le contrle de puissance dans les systmes 3G 168
4.5. Contrle de puissance en UTRA-FDD 170
4.5.1. Principes gnraux 170
4.5.2. La voie montante (uplink) 173
4.5.3. La voie descendante (downlink) 176
4.6. Contrle en UTRA-TDD 179
4.6.1. Rappels sur UTRA-TDD 179
4.6.2. La voie montante (uplink) 179
4.6.3. La voie descendante {downlink) 181
4.6.4. Frquences de mise jour du contrle de puissance de la voie
descendante de UTRA-TDD 181
4.7. Contrle de puissance dans la proposition cdma2000 182
4.8. Imperfection du contrle de puissance 183
Chapitre 5. Couverture d'un rseau cellulaire CDMA 187

Loutfi NUAYMI
5.1. Prsentation du problme 187
5.2. Modle utilis 190
5.3. Estimation simple de la capacit d'un rseau cellulaire CDMA 192

5.4. Dfinitions et relations utiles pour la liaison uplink 193
5.4.1. Dfinitions 193
5.4.2. Relations utiles 195
5.5. Dfinitions et relations utiles pour la liaison downlink 202
5.5.1. Dfinitions 203
5.5.2. Relations utiles 204
5.6. Algorithme de prvision de la couverture d'un rseau CDMA
par calcul itratif des charges des cellules 207
5.7. Dtails supplmentaires sur l'algorithme de calcul des charges 208
5.7.1. Imperfection du contrle de puissance 208
5.7.2. Interfrence de canaux adjacents 209
5.7.3. Sectorisation 209
5.7.4. Soft handover 209
5.8. Conclusion et discussion 210
5.9. Bibliographie * 210
5.10. Annexe : notations utilises dans ce chapitre 212
Chapitre 6. Le rseau d'accs UTRAN 215

X a v i e r LAGRANGE
6.1. Architecture gnrale 215

6.1.1. Rappel sur le rseau d'accs de GSM 215
6.1.2. Elments du rseau d'accs UTRAN 218
6.2. Rappels sur les architectures en couches des rseaux 224
6.2.1. Signalisation smaphore 224
6.2.2. Architecture en couches d'un rseau ATM 228
6.2.3. Rseaux IP 234
6.3. Principes gnraux de l'architecture en couches dans UTRAN 236
6.3.1. Strates d'accs et de non-accs 236
6.3.2. Notion de support de transport (transport bearer) 237
6.3.3. Notion de support d'accs radio (RAB, Radio Access Bearer) . . 238
6.3.4. Les diffrents plans 239
6.4. Pile de protocoles de l'UTRAN avec un rseau de transport ATM . . . 240
6.4.1. Interface Uu 240
6.4.2. Interfaces lu 242
6.4.3. Interface Iub 245
6.4.4. Interface Iur 246
6.4.5. Synthses des piles de protocoles 247
6.5. Pile de protocoles de l'UTRAN avec un rseau de transport IP 250
6.6. Prsentations des protocoles sur l'interface radio 252
6.6.1. Couche MAC 252
6.6.2. Couche RLC 253

6.6.3. Couche RRC 255
6.7. Exemples de procdures de signalisation 258
6.7.1. Etablissement d'une connexion RRC et son utilisation 259
6.7.2. Libration d'une connexion RRC 261
6.7.3. Etablissement d'une connexion RRC sur canaux FACH-RACH . 262
6.7.4. Etablissement d'un RAB 263
6.7.5. Libration d'un RAB 264
6.7.6. Gestion de la macrodiversit {soft handover) 264
6.7.7. Procdures de relocalisation 267
Chapitre 7. Le cur de rseau UMTS 271

J e a n - M a r i e BONNIN
7.1 Introduction 271

7.2. Cur de rseau en GSM et GPRS 273
7.2.1. Architecture du rseau GSM avant le GPRS 273
7.2.2. Cur de rseau GPRS : un premier pas vers l'UMTS 275
7.3. Architecture du cur de rseau en Release 99 283
7.3.1. Services offerts par le cur de rseau 284
7.3.2. Principaux concepts 285
7.3.3. Entits du domaine circuit 287
7.3.4. Entits du domaine paquet 288
7.3.5. Architecture en couches 292
7.3.6. Entits communes aux deux domaines 294
7.3.7. Intgration des domaines PS et CS 295
7.4. Gestion des appels et des sessions 296
7.4.1. Services IP proposs aux utilisateurs 296
7.4.2. Etats de fonctionnement d'un mobile 300
7.4.3. Attachement aux domaines PS et CS 302
7.4.4. Gestion des appels du domaine CS 305
7.4.5. Gestion des sessions du domaine PS 307
7.5. Gestion de l'itinrance 316
7.5.1. Gestion de la mobilit 317
7.5.2. Gestion de la mobilit inter rseau 321
7.5.3. Interaction avec MobileIPv4 322
7.6. Gestion de la qualit de service 326
7.6.1. Les classes de services dfinies 326
7.6.2. Une architecture complte 328
7.6.3. Exemple de mise en uvre dans le cur de rseau paquet 331
7.7. Evolution vers un cur de rseau tout IP 332
7.7.1. Evolutions de la Release 4 333
7.7.2. Evolutions prvisibles de la Release 5 334

7.8 Conclusion 335
Chapitre 8. Les architectures de services de l'UMTS 339

P h i l i p p e MARTINS
8.1. Historique de l'volution des services dans les rseaux radio-mobiles . 339
8.1.1. Des services supplmentaires CAMEL 339
8.1.2. Evolutions vers VHE et OSA 341
8.1.3. Evolutions vers IP 341
8.2. Rappels sur les rseaux intelligents 341
8.2.1. Notion de segment d'appel 341
8.2.2. Evolution et structure des standards 342
8.2.3. Le modle conceptuel du rseau intelligent 344
8.2.4. Le plan fonctionnel rparti * 345
8.2.5. Exemples de services rseau intelligent 355
8.2.6. CAMEL et les rseaux intelligents 358
8.3. Prsentation de CAMEL 358
8.3.1. Diffrentes phases de CAMEL 358
8.3.2. Architecture fonctionnelle 361
8.3.3. Les marques CAMEL 362
8.4. CAMEL et le domaine circuit 364
8.4.1. Les automates CAMEL phase 3 du domaine circuit 364
8.4.2. Evolution des automates en phase 4 366
8.5. CAMEL et le domaine paquet 369
8.5.1. Automate d'attachement-dtachement GPRS 370
8.5.2. Exemple d'activation de service 370
8.5.3. Automate de contexte 371
8.5.4. Exemple de service sur acfivation d'un contexte 373
8.6. CAMEL et les changes de SMS 374
8.6.1. CAMEL phase 3 et les envois de SMS 374
8.6.2. CAMEL Phase 4 et la rception de SMS 376
8.7. CAMEL phase 4 et le sous-systme IP multimdia 376
8.7.1. Introduction SIP 376
8.7.2. SIP et le sous-systme IP multimdia 379
8.7.3. CAMEL phase 4 et le sous-systme IP multimdia 381
8.8. Prsentation d'OSA 381
8.8.1. Introduction 381
8.8.2. Services apports par OSA 382
8.8.3. Typologie des interface OSA 383
a
Chapitre 9. Terminal mobile et environnements d'applications 387

Paul JOLIVET
9.2. L'quipement utilisateur en 3G 388
9.2.1. L'quipement mobile (ME) 389
9.2.2. La carte puce (UICC) et ses applications 392
9.2.3. Le rapport de force terminal-carte 395
9.3. Environnements propritaires - environnements standards 396
9.3.1. Diffrentes ressources pour diffrentes applications 397
9.3.2. Les diffrents environnements 397
9.3.3. Interfonctionnement des environnements 400
9.3.4. Les services d'Internet Mobile 404
9.3.5. L'approche standard des environnements existants 405
9.3.6. L'approche offre de services en packages 406
9.4. Virtual Home Environment * 407
9.5. Le tlchargement 408
9.5.1. Les applications du tlchargement 408
9.5.2. Synchronisation 409
9.5.3. Fonctionnalits lies au tlchargement d'applications 410
9.5.4. Environnements applicatifs et tlchargement 411
9.5.5. Supports de communication du rseau 3G 412
9.6. Conclusion 414
9.7. Annexes 415
9.7.1. La standardisation ct terminaux 415
9.7.2. Rfrences 418
Chapitre 10. Scurit du systme UMTS 423

Paul JOLIVET
10.1.Introduction 423
10.1.1. Exemples d'attaques sur un rseau mobile 423
10.1.2. Mcanismes de scurit 424
10.2 Principes de la scurit en UMTS 425
10.2.1. Les lments matriels lis la scurit 426
10.2.2. Identit sur le rseau UMTS 426
10.2.3. Identification de l'utilisateur 427
10.2.4. Lignes directrices des algorithmes d'authentification 428
10.2.5. Authentification en UMTS 430
10.2.6. Intgrit des messages 432
10.2.7. Chiffrement des donnes 433
10.2.8. Aspects protocolaires 436
10.3. Les attaques possibles - Les protections 438
1
10.3.1. Parades - Protection 438

10.4. UICC et AuC, cl de vote du systme 438
10.4.1. Scurit et carte puce 439
10.4.2. UICC et USIM 440
10.4.3. Utilisation de base 440
10.4.4. Scurit et IP Multimedia 441
10.4.5. Scurit et service de diffusion multimdia (MBMS) 442
10.4.6. Scurit et appels de groupe (VGCS) 443
10.4.7. Scurit et I-WLAN 444
10.4.8. Scurit et terminal rparti entre plusieurs priphriques 445
10.5. Applications et scurit 445
10.5.1. Interfonctionnement des applications et pare-feu 445
10.5.2. Tlchargement d'applications 446
10.6. Roaming et scurit 447
10.6.1. Accs aux donnes de scurit 447
10.6.2. Accs de multiples rseaux 447
10.6.3. Algorithmes de conversion, fonctionnalit 2G 447
10.6.4. Roaming 2G/3G, authentification et chiffrement 448
10.7. Interception lgale 448
10.7.1. Les rsolutions de la Communaut Europenne 448
10.7.2. La mise en place dans les pays, le cas du Royaume-Uni 449
10.7.3. Interception et standardisation 450
10.8. Protection du rseau UMTS 451
10.8.1. Le rseau nominal 451
10.8.2. Les lments du rseau - interfaces 451
10.9. Conclusion 454
10.10 Annex ^Bibliographie et Rfrences 454
10.10.1. Bibliographie 454
10.10.2. Spcifications - Standards 455
10.10.3. Sites Internet 457
Glossaire 459
Index 471
Chapitre 1
Introduction l'talement de spectre
1.1. Introduction
L'UMTS (Universal Mobile Tlcommunications Systems) doit permettre une pa-

noplie de services nettement plus large que les systmes de deuxime gnration
comme GSM (Global System for Mobile communications) qui se cantonnait la t-
lphonie et aux messages courts (SMS, Short Message Service). A terme, l'ensemble
du rseau UMTS (accs, rseau cur) doit voluer dans le sens de la convergence
tlphonie-donnes vers un rseau tout IP. Dans une premire phase (correspondant
la release 99), la diffrence majeure avec le GSM vient de l'interface radio. Celle-ci
repose sur l'talement de spectre squence directe.
L'talement de spectre consiste transmettre une information sur un signal occu-

pant un spectre nettement plus grand que le minimum ncessaire. Cette technique a t
d'abord utilise dans les systmes militaires des fins de discrtion et parce qu'elle
offre une bonne rsistance aux brouillages hostiles. Depuis le milieu des annes 90,
elle est utilise dans certains systmes radiomobiles cellulaires. Ce chapitre a pour ob-
jet d'en donner les principes gnraux. Il commence par un rappel de communication
numrique sur les notions de voie en phase et de voie en quadrature et une prsentation
de la notion trs importante d'nergie d'un bit. Il aborde ensuite le principe d'tale-
ment squence directe et dcrit le principe gnral de fonctionnement d'un rcepteur.
Le CDMA (Code Division Multiple Access) est ensuite expliqu en tant que technique
de multiplexage. Le chapitre se conclut sur la mise en uvre de l'talement de spectre
squence directe et du CDMA dans les systmes cellulaires.
Chapitre rdig par Xavier L A G R A N G E .

-2,5 -2 -1,5 -1 -0,5 0 0,5 1 1,5 2 2,5

Figure 1.1. Exemple d'un signal modul en QPSK
1.2. Rappels de communication numrique
1.2.1. Principes des modulations numriques
1.2.1.1. Transmission d 'une suite de symboles

Pour transmettre une information d'un point un autre, on utilise un signal sinu-
sodal haute frquence (dans le contexte radiomobile de 2 MHz 2 GHz) dont on
modifie l'amplitude, la phase ou la frquence [BAU 02]. Nous nous restreignons aux
modulations de phase, utilises dans les systmes radiomobiles de troisime gnra-
tion.
Pour une transmission numrique, on met l'information par groupes d'lments

binaires appels symboles. Pendant la dure d'un symbole Ts, la grandeur modifie
(dans ce chapitre, la phase) reste constante. On peut donc considrer la transmission
d'un symbole unique. Cela permet de raisonner sur des signaux nergie finie. La
transmission de la suite d'lments binaires est analyse en considrant une rptition
de l'mission d'un symbole avec un dcalage d'un nombre entier de priode Ts. Soit
S (t) un signal modul transportant une suite de symboles, le signal S (t) s'crit sous
la forme :
[1 1]
o k est un indice croissant avec le temps, rrik est le symbole transmis l'instant
kTs c'est--dire pendant l'intervalle [kTs - Ts/2, kTs + Ts/2] et smk (t) le signal
modul, d'nergie finie, correspondant au symbole m/t.
Dans toute la suite, nous raisonnerons sur la transmission d'un seul symbole. Pour
simplifier l'criture, on note ce symbole m. Nous raisonnons donc sur sm (t), plus
facile manipuler que le signal S (t). Nous allons crire sous diverses formes ce
signal sm (t) dans le cas particulier de la modulation de phase.
Introduction l'talement de spectre 21
Figure 1.2. Transmission d'un symbole
1.2.1.2. Ecriture sous forme relle d'un signal modul

Considrons une modulation o M tats de phases sont utiliss et o M est une
puissance de 2. On groupe log 2 (M) bits en 1 symbole pour obtenir un symbole m
parmi les M symboles possibles (m = O...Af 1). Nous obtenons la premire forme
d'criture du signal sm{t) : *
m(t) = 9 (t) cos (27rj c t + 2irra/M + <p) [1.21
o <p est la phase l'origine des temps.
La fonction g dsigne une fonction d'nergie finie Eg. La fonction g s'annule

donc ncessairement en oo et +oo. Un exemple simple de fonction g est la fonction
crneau :
r g(t) = jJTs Si \t\ < Ts/2

1
\ g(t) = 0 si \t\ > Tl/2
L'nergie d'un signal g{t) est dfinie par E = f*^ g2 (t) dt. On en dduit pour
la fonction g(t) considre : E = J^Xs/2 Eg/Tsdt soit E = Eg.
Nous considrons dans ce chapitre que la fonction g(t) est la fonction crneau.
Cette fonction a pour principal inconvnient d'avoir un spectre tal sur tout l'es-
pace des frquences. Or, dans un systme de transmission, on utilise une bande de
frquence limite, c'est--dire qu'on filtre le signal mis. Il est donc prfrable d'uti-
liser une fonction g(t) dont le spectre est limit. Pour ce faire, on filtre le signal avant
l'mission. Cette tape est appele mise en forme ou puise shaping.
EXEMPLE - Considrons une modulation 2 tats (M = 2). Les valeurs possibles de
m sont 0 et 1. On a sm(t) = sjEg/Ts cos (2TT/C + rrnr) pour t G }~Ts/2, Ts/2[ en
prenant <p = 0 et la fonction crneau pour g. Il s'agit de la modulation BPSK (Binary

Phase Shift Keying).
EXEMPLE - Considrons une modulation 4 tats (M = 4). Les valeurs possibles
de m vont de 0 3. On a sm(t) = y/Eg/Ts cos (27rf c t mir/2 H- 7r/4) en prenant
<p = 7T/4. Il s'agit de la modulation QPSK (Quaternary Phase Shift Keying).
1.2.1.3. Ecriture sous forme complexe d'un signal modul

En utilisant une notation complexe, on peut crire s m () sous une autre forme :
8m(t) = (s (;t) ej(^fct+2nm/M+^ [M]
o j dsigne le nombre imaginaire tel que j2 = 1 et dsigne la partie relle

d'un nombre complexe. En modifiant lgrement la prsentation, nous obtenons la
deuxime forme d'criture du signal sm(t) :
Sm{t) = (ej2/M+i*g (t) ej27rfct) [1.5]
Cette criture en notation complexe fait apparatre que la transposition la fr-

f
quence fc peut tre vue comme une simple multiplication par le signal qui ne
dpend pas de l'information transmise.
1.2.1.4. Ecriture en phase et en quadrature d'un signal modul

En repassant en notation relle, on obtient la troisime forme d'criture du signal :
sm(t) = cos (2irm/M + ip) g (t) cos (27rf c t)

- sin {2-Km/M + <p) g (t) sin ( 2 ? r f c t ) [ 1.6]
Sous cette forme, le signal s (t) s'exprime comme une combinaison linraire de deux
sinusodes en quadrature de phase. On appelle le premier terme la voie en phase et le
deuxime la voie en quadature.
EXEMPLE - En BPSK, on peut crire sm(t) = y/Eg/Ts cos (27rf c t) (on a + ou -
suivant la valeur du bit m). On note que la voie en quadrature est toujours nulle.
EXEMPLE.- En QPSK, on peut crire le signal sous la forme :
sm(t) = cos (mn/2 + TT/4) yJ~/Ts cos ( 2 ? r f c t )
- sin (ra7r/2 + tt/4) YJEG/TS sin (2?vf c t)

1.2.1.5. Energie d'un symbole et d'un bit

Dfinissons les deux signaux suivants :
fi(t) = xl~g(t) cos (2nfct) [1.7]
h (t) = -xl^-g(t)sm(2<Kfct) [1.8]
Ces deux signaux ne diffrent que par la phase. Ils ont donc mme nergie. Calculons
l'nergie pour f\ :
-t-oo
+oo
E= I ff(t)dt " [1.9]
/ -oo /?
On a donc :
2 p-t-OO
E= g2{t)s2(27rfct)dt [1.10]
Joo
En utilisant les formules trigonomtriques :
+
f 92(t)s(47Tfct)d?j [1.11]
La fonction g (t) a, par dfinition, une nergie Eg, donc f* g2 (t) = Eg. En
pratique, la fonction g2 (t) est une fonction paire, donc g2 (t) cos (47T fct) dt =
0. On en dduit E 1. D'autre part, on a :
-t-oo 2 p~r
/
fi (t) h (t)dt = - g2(t) cos ( 2 ; T f c t ) sin (2Trf c t) dt [1.12]
-oo ^g Joo
On peut en dduire, aprs quelques calculs lmentaires :
+oo
[1.13]
/ -oo h(t)f2(t)dt = o
Les deux signaux / i e t sont donc orthogonaux et d'nergie 1. L'nergie du signal

s m (t) se calcule comme pour /i (t). On obtient :
[1.14]
Posons Es = Eg/2. Le paramtre Es reprsente l'nergie du signal sm (t) utilis

pour transmettre un symbole. Par extension, on considre qu'il reprsente l'nergie
d'un symbole.
Nous obtenons la quatrime forme d'criture du signal sm(t) comme une combi-
naison linaire de deux signaux sinusodaux orthogonaux d'nergie 1 affects de deux
coefficients am et bm : *-
[1.15]
avec, dans le cas d'une modulation de phase M tats :
[1.16]
[1.17]
Le premier signal est appel signal en phase et le deuxime signal en quadrature. Il

est possible de considrer deux voies de transmission : la voie en phase appele voie
I, qui transporte a m , et la voie en quadrature appele voie Q, qui transporte bm.
Il est commode d'crire la paire ( a m , 6 m ) sous la forme d'un seul nombre com-
plexe am -(- jbm. En passant en criture complexe, on obtient la cinquime et dernire
forme d'criture du signal sm (t) :
[1.18]
avec / (t) = h W " 3h W = y f f g d ( t ) exp (j2tt/ c ^). La fonction / (t) a tou-

jours une nergie gale 1, quelle que soit la fonction g (t) choisie. On peut donc
considrer que l'nergie du signal est seulement transporte par am et bm.
EXEMPLE - Dans le cas de la B P S K , on utilise seulement la voie I. Un symbole cor-

respond un bit. Les valeurs possibles de am sont donc { y/b, +y/b} , o Eb
dsigne l'nergie d'un bit (gale ici l'nergie d'un symbole).
EXEMPLE - Dans le cas de la Q P S K , on utilise la fois la voie en phase et en qua-
drature. On a am = y/s cos (m7r/2 + 7T/4) et bm = y/Es {mn/2 4- 7T/4) . Les
valeurs possibles de am et de bm sont donc j y/Es/2, +y/Es/2^. Deux bits sont
groups en 1 symbole. L'nergie d'un bit est la moiti de celle d'un symbole : Eb =
Es/2. On peut donc rcrire les valeurs possibles de am et bm comme { - +>/&}.
Les modulations Q P S K et B P S K sont donc trs voisines : dans la Q P S K , on utilise les
deux voies en phase et en quadrature, dans la B S P K on n'utilise que la voie en phase
(voir figure 1.3).
Figure 1.3. Modulations BPSK et QPSK
La chane d'mission d'un signal modul numriquement peut tre vue comme
suit (voir partie de droite de la figure 2.18) : un flux d'lments binaires est group en
deux suites de symboles ; chaque symbole est affect d'une nergie ; deux symboles
sont mis sous forme d'un nombre complexe avec une composante en phase et une
autre en quadrature. On peut voir cette tape comme une modulation en bande de
base . On passe ensuite la mise en forme du signal qui consiste utiliser un filtre
passe-bas (ce qui revient utiliser une fonction g{t) diffrente de la fonction crneau).
La dernire tape consiste transposer le signal en frquence par simple multiplication
par la fonction complexe exp(j27r/ c ).
1.2.1.6. Conclusion
Un signal numrique peut tre considr comme une suite de symboles complexes,
chaque symbole possdant une certaine nergie. L'axe des rels correspond la voie
en phase et l'axe des imaginaires la voie en quadrature. En modulation BPSK, on
transmet des lments binaires seulement sur la voie en phase (un symbole = un bit).
En modulation QPSK, on utilise la fois la voie en phase et la voie en quadrature.
Sur chaque voie, on transmet des lments binaires. Un symbole complexe transporte
donc 2 bits.
1.2.2. Modle de transmission en bande de base
Dans le modle de transmission considr, la dernire tape l'mission consiste

oprer la transposition de frquence. De faon rciproque en rception, on fait une
transposition en frquence pour repasser en bande de base par une multiplication par
exp( j2irfct). Dans le reste du chapitre, nous raisonnons sur un modle en bande de
base sans prendre en compte la transposition en frquence, comme indiqu la figure
1.4. Pour une justification prcise mais longue qu'un tel modle ne modifie pas les
rsultats prsents, on peut consulter [PRO 01].
transposition transposition
en frquence en frquence
Figure 1.4. Modle de transmission en BPSK et modle quivalent en bande

de base
On suppose galement dans ce chapitre que la fonction g{t) est une fonction cr-
neau simple et que la modulation utilise est la BPSK (c'est--dire que l'on n'utilise
que la voie en phase). Le cas de la QPSK peut facilement se traiter en considrant deux
transmissions en parallle sur les 2 voies en quadrature et en phase. Pour la BPSK. la
dure d'un symbole est la mme que la dure d'un bit :TB = TS. Pour un flux binaire
mis dbit Rf, = 1/7},, on peut donc crire le signal mis (en bande de base) sous la
forme :
[1.19]
o f ( t ) = y/2/Th pour \t\ < Tb/2 et f(t) = 0 sinon (fonction crneau d'nergie 1) et
bk = +1 ou 1. On peut prendre par exemple la correspondance : pour un bit valant
0, bk = +1 et pour un bit valant 1,6* = 1. On note que l'indice k est ici un indice
rfrenant le ke bit mettre (et non un indice donnant la valeur utilise parmi toute
les valeurs possibles comme l'indice m au paragraphe 1.2.1).
1.2.3. Action du canal de transmission
Dans cette partie, nous prsentons le modle de canal de transmission. Celui-ci est
utilis pour montrer les avantages de l'talement de spectre dans la partie suivante.
1.2.3.1. Canal bruit sans multitrajets

Le signal aprs modulation se propage sur le support de transmission. Il subit un
retard, un affaiblissement, des distorsions et des brouillages. L'affaiblissement a pour
effet de rduire considrablement la puissance du signal reu. Dans tous les rcepteurs,
un amplificateur permet de disposer d'un signal de puissance voisine de celle du signal
mis. Pour simplifier les critures et sans perte de gnralits, on considre que le ou
les amplificateurs rtablissent le mme niveau d'nergie que celui du signal mis : en
d'autres termes, on ne tient pas compte de l'affaiblissement.
Dans une premire tape, on nglige les distorsions et on considre que le brouillage
revient ajouter au signal transmis un signal alatoire dont le niveau est distribu sui-
vant une gaussienne. Ce signal est appel bruit additif blanc gaussien (AWGN, Ad-
ditive White Gaussian Noise). Il a une nergie infinie mais une puissance finie. Sa
densit spectrale de bruit est constante de valeur Nq/2, quelle que soit la frquence
considre. Sur une bande W ramene en bande de base, la densit spectrale est NO.
Dans un systme radiomobile, le bruit gaussien correspond non seulement au bruit

propre du rcepteur (bruit thermique) mais galement l'ensemble des interfrences,
notamment l'interfrence co-canal due la rutilisation de la mme frquence sur
plusieurs cellules.
Le signal reu s'crit donc :
R(t) = S(t) + n(t) [1.20]
Un tel modle de canal est appel canal AWGN. Notons qu' l'mission il y a un
ensemble discret de signaux possibles. A la rception, le bruit a pour effet de faire
passer les valeurs dans un espace continu.
1.2.3.2. Canal multitrajets

Dans les rseaux radiomobiles, le rcepteur est rarement en visibilit directe de
l'metteur. Les obstacles dans un milieu urbain ou rural (immeubles, vgtation, mo-
biliers urbains, vhicules, personnes, etc.) provoquent des rflexions, des diffractions
et de la diffusion (voir [PAR 00] et [LAG 00]). Un rcepteur reoit un signal com-
posite comprenant divers chos d'un mme signal mis. Chaque signal suit un trajet
particulier et il arrive donc avec un dcalage par rapport aux autres. La propagation
est dite multitrajets.
On caractrise un canal de propagation par sa rponse implusionnelle, c'est--

dire l'volution du signal reu si on met une impulsion. La rponse impulsionnelle
dpend troitement de l'environnement particulier dans lequel on se place mais on
peut identifier des caractristiques communes suivant le type d'environnement (urbain,
rural, montagneux). On dfinit ainsi des canaux standards avec des valeurs de retard
fixes mais un affaiblissement et une phase alatoires.
Un canal multitrajet est quivalent un filtre : la rponse impulsionnelle du canal

est la rponse impulsionnelle du filtre. La fonction de transfert du filtre est la trans-
forme de Fourier de la rponse implusionnelle. On dfinit la barde de cohrence du
canal comme la plage de frquences l'intrieur de laquelle le canal prsente un gain
quasi-constant et une phase linaire. A l'intrieur de la bande de cohrence, le canal
peut tre considr comme plat.
La fonction de transfert d'un canal multitrajets peut s'crire de faon trs gn-
rale :
[1.21]
o T dsigne le retard voluant au cours du temps t et o S est la fonction de Dirac.

Les paramtres T{(t) reprsentent les retards des diffrents trajets; les coefficients
complexes a(t) donnent la phase et l'amplitude de chaque trajet.
Un modle couramment utilis consiste supposer que la variation au cours du

temps des diffrents paramtres est lente par rapport au dbit de transmission. On
considre donc que ces paramtres sont constants au cours d'une transmission d'un
bloc d'information mais peuvent varier d'une transmission l'autre. Plus prcisment,
on suppose que les r* sont fixes et ne dpendent que de l'environnement (urbain dense,
rural, montagneux, etc.) et que les coefficients Ci sont alatoires : la phase est uni-
formment distribue et l'amplitude suit une loi de Rayleigh [JAK 94]. Les modles
prcisent la valeur moyenne de l'amplitude. Un des modles proposs dans [SMG 98]
est prsent la figure 1.5. On peut crire, pour une transmission :
[1.22]
o Ai est une variable alatoire de Rayleigh dont la moyenne est donne par le modle
et fa est une variable alatoire uniformment distribue entre 0 et 2tt.
Puissance
moyenne
1.3. Etalement squence directe
1.3.1. Bits et chips
Considrons une suite de donnes transmise en bande de base un dbit Rb (R

pour Rate). L'talement de spectre consiste multiplier la suite de donnes par une
squence prdfinie PN(t) valant +1 ou 1 et variant un rythme Rc = nRb. Nous
constatons que l'talement revient augmenter artificiellement le dbit d'un facteur n.
Le paramtre n est appel facteur d'talement. Pour simplifier, nous utiliserons dans
ce chapitre un exemple avec n = 8 ; dans la pratique, le paramtre n est gnralement
une puissance de 2 largement suprieure 10, typiquement 64, 128, 256 ou 512. Aprs
multiplication, le Signal varie donc un rythme bien suprieur au dbit symbole. La
partie lmentaire de la squence s'appelle un chip.
Soit S(t) la suite de donnes mettre. Le signal en bande de base aprs talement
Setale(t) S'crit :
Setaleit) = S(t).PN(t) [1.23]
On donne un exemple de signal tal dans la figure 1.6 avec n = 8. Notons que
l'opration de multiplication revient transmettre +PN(t) pendant Tb si on transmet
un bit 0 et PN(t) si on transmet un bit 1 si on considre une nergie gale 1.
Le chapitre considre une squence PN(t) valeurs relles mais il est possible de
considrer une squence PN(t) complexe. Avec une modulation QPSK, la squence
PN(t) prend ses valeurs parmi {1, j, 1, j}.
Figure 1.6. Principe de base de l'talement squence directe
1.3.2. Bilan nergtique
La suite de donnes tant mise un dbit Rb, la dure d'un bit est Tb = l/Rb- Le
dbit en chips par seconde du signal tal est Rc = nRb. La dure d'un chip est donc
Tc = Tb/n.
Soit Ec l'nergie d'un chip. Comme la squence PN(t) vaut +1 ou 1, la mul-

tiplication par PN(t) ne change pas la puissance du signal. La puissance du signal
d'origine est gale la puissance du signal tal. On peut donc crire :
Eb/Tb = Ec/Tc [1.24]
On en dduit aisment :
Eb = nEc [1.25]
L'quation 1.25 montre que l'nergie d'un bit est rpartie sur l'ensemble des chips.
1.3.2.1. Spectre du signal tal

Considrons la suite des donnes transmises par l'metteur. Pour un observateur
extrieur, cette suite apparat comme alatoire. La densit spectrale de puissance de
S(t) est donc celle d'un signal alatoire NRZ. Elle est donne par (voir [GLA 96]) :
f sin(7r/T b )Y
[1.26]
Densit spectrale de puissance
-8 -7 -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8
frquence
(en multiples de MTb)
Figure 1.7. Comparaison des spectres du signal en bande de base

et du signal tal
Si on choisit une squence d'talement qui ressemble un squence alatoire, le

signal aprs talement apparat comme un signal alatoire mais un rythme Rc. La
densit spectrale (j>c{f) du signal aprs talement est :
(y
En exprimant cette densit en fonction de Eb, Tb et de n, on obtient :
M n = -n ( s\ i n 0 ir/
7TfTb/n
n ) y 2J H.28]
Les deux densits spectrales sont reprsentes dans la figure 1.7. L'talement a
pour effet de multiplier la largeur du spectre d'un facteur n. Le paramtre n mrite
donc bien son nom de facteur d'talement. La figure 1.7 donne le spectre pour une
fonction g{t) crneau. Dans la pratique, on utilise une fonction qui donne un spectre
plus reserr : la majorit de l'nergie est concentre dans la bande W = l/Tc (c'est--
dire entre - 1 / 2 T c et 4-1/2T c ). Cependant, le rapport entre le spectre du signal avant
talement et aprs talement reste toujours n.
Notons que pour bnficier d'un rel talement du spectre, la squence utilise
doit tre pseudoalatoire, d'o la notation PN (Pseudo Noise). Par exemple, on ne peut
faire un talement avec une squence priodique telle q u e + 1 + 1 + 1 + 1 11 1 1.

Toute squence pseudoalatoire est ncessairement priodique mais sa priode est
longue (voir paragraphe 1.5.1.1). Dans le systme amricain IS-95, on utilise par
exemple une squence de longueur 2 15 soit 32 768 et un talement de 64. La lon-
gueur de la squence est bien plus longue que le paramtre n.
Notons qu'il existe d'autres techniques d'talement de spectre que celle dcrite
dans ce paragraphe, la principale tant le saut de frquence. Si on fait varier la fr-
quence porteuse sur laquelle on transmet le signal, on a galement un talement de
spectre. Si la variation est plus lente que le dbit symbole, on parle de saut de fr-
quence lent ou Slow Frequency Hopping. Si la variation est plus rapide ou du mme
ordre, on parle de Fast Frequency Hopping.
1.3.3. Gain d'talement
Nous considrons une transmission d'un signal QPSK ou BSPK sur un canal
AWGN (voir paragraphe 1.2.3.1), c'est--dire ajoutant un bruit gaussien au signal
transmis. La probabilit d'erreur sur un bit (lorsqu'on utilise un filtre adapt), est don-
ne par la formule suivante, que nous admettons [PRO 01 ] :
o EB dsigne l'nergie d'un bit, Nq la densit spectrale de puissance du bruit et

Q (t) = f O
t'
O -j=e
1 !2dx. Par exemple, un rapport Eb/N0 de 6 dB conduit un taux
t
d'erreur bit de 10 - 3
Soit C la puissance du signal mis. Dans une transmission sans talement, la lar-
gueur de bande du signal est W = L/TB (en considrant la bande de Nyquist). La
puissance du signal est donc C = EB/TB. Si, la rception, on filtre le signal sur la
bande W, la puissance du bruit est WNQ. Le rapport signal bruit en puissance est
donc :
C/N = EB/N0 1.301
Sans talement de spectre, il faut donc un rapport C/N de 6 dB pour obtenir un

taux d'erreur bit de 1 0 - 3 .
Nous admettons galement que la formule 1.29 est inchange par l'talement de
spectre. La puissance du signal reste la mme mais la largeur de bande est augmente
Wc = 1/TC. On a donc C/N = (Eb/Tb)/(N0WC). On peut donc tablir :
C/N = -Eb/N0 [1.31]

n
En chelle logarithmique, on obtient :
(C/N)dB = (Eb/N0)iB - 101ogi 0 n [1.32]
Considrons un systme avec un facteur d'talement n = 128. Pour avoir un taux

d'erreur bit de 1 0 - 3 , il est toujours ncessaire d'avoir un Eb/N0 de 6 dB mais celui-ci
est obtenu par avec un signal sur bruit de 6 101og 10 (128) = 13 dB. Or -13 dB
correspond un rapport 200 en puissance. Cela signifie qu'on tolre une puissance
de bruit gale 200 fois la puissance du signal ! Grce l'talement, on peut avoir un
faible taux d'erreur, mme lorsque le signal tal reu est compltement noy dans
le bruit. En consquence, on appelle le paramtre n le gain d'talement.
On peut exprimer la formule 1.31 sous une autre forme en fonction de la bande W
(gale 1/T C ) et du dbit utilisateur Rb (gal l/Tb). On obtient :
W C
Ek/N0 = - - [..33]
1.3.4. Rcepteur en bande de base
1.3.4.1. Rcepteur simple sur un canal parfait

Considrons une transmission sans aucun bruit, ni aucune interfrence. Le canal
a pour seul effet de retarder le signal d'une dure TQ. Soit Srecu le signal reu. On a
Srecu(t) = Setale {t ~ TQ), SOit :
Srecu M = S(t - r0).PN{t - T0 ) [1.34]
On vrifie aisment que pour tout t, PN(t).PN*(t) = 1, o PN(t) dsigne le

conjug du complexe PN*(t) (si l'talement est rel, PN*(t) = PN(t)). Pour re-
trouver le signal d'origine, il faut donc multiplier le signal reu par PN*(t - TQ). En
effet:
Srecu(t).PN*(t - TQ) = S(t - R0).PN{t - R0).PN*{t - r 0 ) [1.35]

On a donc :
[1.36]
On note qu'il est ncessaire pour la rception d'estimer la valeur de tq. Cela si-
gnifie qu'il y a une synchronisation faire en rception. Dans la pratique, le canal va
perturber le signal mis et introduire, par exemple, des erreurs sur quelques chips. Il
n'est alors pas possible d'utiliser un systme si simple car il n'y a pas de critre de
dcision pour dterminer le bit mis l'origine. Pour permettre une dtection simple,
on va utiliser un intgrateur.
1.3.4.2. Rcepteur simple sur un canal avec bruit additif

On considre maintenant un canal qui introduit un bruit gaussien (canal AWGN
prsent au paragraphe 1.2.3.1). Le signal reu s'crit donc par rapport au signal mis :
[1.37]
o n(t) est reprsente le bruit alatoire gaussien.
On rajoute au rcepteur simple prsent au paragraphe 1.3.4.1, un intgrateur qui

agit sur une dure bit T^. Cela a pour effet de raliser une corrlation entre le signal
reu et la squence PN(t) dcal de r0 :
[1.38]
Figure 1.8. Principe d'un rcepteur avec un corrlateur
Le schma bloc d'un rcepteur simple est prsent dans la figure 1.8. A la sortie du
corrlateur , on chantillonne le signal toutes les dures bits La dtection consiste
regarder le signe du signal reu. On peut galement mettre une dtection seuil :
pour considrer qu'on a un bit 0 ou un bit 1, il faut que le niveau soit en valeur absolue
suprieur un seuil donn. Dans le cas contraire, on est dans le cas d'un effacement
(on sait qu'un bit est reu mais sa valeur est considre comme inconnue).
Figure 1.9. Exemple de rception d'une squence bruite
Pour illustrer le principe de fonctionnement du rcepteur, on considre une trans-

mission de quelques bits (0, 0 ,1 ,0) dans le modle en bande de base comme indiqu
la figure 1.9 et on suppose que le bruit est constant pendant une dure chip. Il peut
conduire modifier le signe du chip reu et introduire une erreur. Considrons le 3e bit
mis. Si on faisait une rception indpendante de chaque chip, on aurait une erreur sur
les trois premiers chips et sur le septime la rception car le bruit est suffisamment
important pour changer le signe du signal. Grce l'intgration sur l'ensemble des
chips constituant le bit, la rception du bit est correcte. Nous voyons de manire plus
intuitive l'intrt de l'talement de spectre, prsent au paragraphe 1.3.3. Cet effet
peut s'exprimer mathmatiquement en combinant les quations 1.23, 1.37 et 1.38 :
On en dduit :
soit :
[1.41]
A la sortie du corrlateur, le bit est affect d'un certain bruit reprsent par le
terme de droite de l'quation 1.41. Le bruit et la squence PN(t) sont dcorrls. Par
consquent, le terme de droite est proche de 0. Avec une analyse plus pousse base sur
l'nergie, on peut ainsi justifier que l'quation 1.29 reste valide pour un signal tal.
Le corrlateur a pour effet de dstaler le signal alors qu'il ne dstal pas
le bruit comme on le voit la figure 1.10. Notons que le fonctionnement du rcepteur
suppose qu'on est capable d'estimer la valeur du dlai de propagation r 0 .
Densit spectrale de puissance
Figure 1.10. Action du dstalement sur les spectres du signal et du bruit
1.3.5. Principes du rcepteur Rake
Dans un canal multitrajets, un rcepteur avec un simple filtre adapt ne peut

suffire. On reoit plusieurs chos dcals dans le temps du mme signal : par rapport
au trajet principal, les chos vont engendrer de l'interfrence, ce qui va augmenter
le risque d'erreur. On utilise dans ce cas un rcepteur rateau ou rcepteur Rake.

Le fonctionnement d'un tel rcepteur suppose qu'on est capable d'estimer la rponse
impulsionnelle du canal, c'est--dire de connatre les paramtres fa et Ai de l'quation
1.22.
Un rcepteur rake est compos d'une batterie de corrlateurs, chaque corrlateur

tant accord sur un trajet comme illustr la figure 1.11. La corrlation est faite
entre le signal reu et la squence d'talement affecte d'un retard particulier. Pour
une bonne rception, le retard utilis doit correspondre au retard provoqu par un des
trajets du canal. Chaque corrlateur correspond une branche du rateau. Dans l'idal,
il faut autant de branches qu'il y a de trajets sur le canal de propagation. Dans la
pratique, on est limit, pour des raisons de puissance de calcul, quelques branches.
Chaque trajet i est affect d'une phase particulire fa et d'un affaiblissement Ai.
On recombine les sorties des diffrents corrlateurs aprs intgration en corrigeant la
phase (multiplication par exp( jfa)) et affectant un gain gal Ai. On peut montrer
que cela permet une recombinaison optimale. Intuitivement, on peroit bien qu'il faut
pondrer par un coefficient d'autant plus fort une branche que le trajet correspondant
est reu fortement (c'est--dire que Ai est fort).
Figure 1.11. Principe du rcepteur Rake
1.3.6. Intrt de l'talement de spectre pour combattre les multitrajets
Comme indiqu au paragraphe 1.2.3.2, un canal multitrajet est quivalent un

filtre : la rponse impulsionnelle du canal est la rponse impulsionnelle du filtre. La
fonction de transfert du filtre est la transforme de Fourier de la rponse implusion-
nelle. On dfinit la bande de cohrence du canal comme la plage de frquences
l'intrieur de laquelle le canal prsente un gain quasi constant et une phase linaire. A
l'intrieur de la bande de cohrence, le canal peut tre considr comme plat.
Considrons un signal de dure symbole Ts et un canal de bande de cohrence Bc.

La bande de frquence occupe par le signal peut tre assimile W = 1 /Ts. Nous
considrons l'exemple suivant : une transmission 10 kbit/s, soit Ts 0,1 ms et
W 10kHz, et une bande de cohrence gale 100 kHz. Si on transmet directement

le signal, alors la bande de cohrence est suprieure la bande du signal : le canal
peut tre considr comme plat. Si les phases des diffrents trajets composant le canal
se combinent bien, l'amplitude du signal reu est importante. Sinon, l'amplitude peut
tre faible : c'est le phnomne bien connu d'vanouissement. L'vanouissement peut
atteindre 40 dB. La rception est donc trs sensible aux multitrajets.
Figure 1.12. Intrt de l'talement de spectre pour un canal multirajets
Considrons le mme exemple mais avec un systme talement d'un facteur 128.
La bande du signal aprs talement est donc gale 1,28 MHz et elle est suprieure
la bande de cohrence. Il n'y a donc pas de phnomne d'vanouissement mais
seulement un filtrage du signal (voir figure 1.12). Avec un traitement appropri, il est
plus facile de rcuprer le signal. L'talement de spectre rduit fortement la probabilit
des vanouissements mais ne les empche pas compltement : il est reste possible que,
sur une large plage de frquences, le canal affaiblisse fortement le signal.
On tudie maintenant les phnomnes au niveau temporel en supposant qu'il n'y

a que 2 trajets sur le canal. Pour fixer les ides, on prend ro = 0 et t\ = 2^s. Sans
talement, la dure d'un symbole dans l'exemple considr est de 0,1 ms : elle est
grande devant les retards et il n'y a donc pas d'interfrence intersymbole. Avec tale-
ment, la dure d'un chip vaut Tc = 100/128, soit 0,78 jus. Si un bit est mis t = 0,
le premier chip est reu t = 0 suivant le trajet principal et t = 2/xs par le second
trajet. Or t = 2ps, le rcepteur est en train de recevoir le troisime chip. Avec un
rcepteur Rake 2 branches, on peut isoler les deux trajets : une branche est accorde
sur le trajet principal, l'autre sur le trajet retard de t\. Notons qu'il n'est pas possible
d'isoler deux trajets qui diffrent de moins d'une dure chip Tc (c'est--dire que l'on
ne peut rien faire si t\ < Tc). En conclusion, l'talement provoque de l'interfrence
intersymbole (ici un symbole est un chip) mais il est facile, grce au rcepteur Rake,
de s'en affranchir.
1.4. Principe du multiplexage par des codes orthogonaux
Le multiplexage a pour principe de transmettre plusieurs signaux en parallle sans

que l'un n'interfre avec l'autre. Les techniques de multiplexage les plus anciennes
sont le FDMA (Frequency Division Multiple Access) et le TDMA (Time Division Mul-
tiple Access). Dans ce paragraphe, nous prsentons le CDMA (Code Division Multiple
Access). Nous avons pris le parti de diffrencier le CDMA de l'talement de spectre
bien que les systmes cellulaires dsigns sous le vocable CDMA utilisent ces deux
techniques. Dans cette prsentation, nous ne faisons pas de considration sur l'nergie
et considrons le flux de donnes comme une suite de bits transmis un dbit
Nous reprenons la convention du paragraphe 1.3 : valeur +1 pour un bit 0 et -1 pour
un bit 1.
Comme dans l'talement de spectre, on multiplie, en CDMA, la valeur trans-

mettre par une squence de chips un dbit suprieur Rc = nRb. Cependant, la s-
quence a des caractristiques diffrentes. La longueur de la squence est toujours gale
au facteur d'talement n. Le multiplexage des diffrents flux s'effectue en choissant
des squences ayant de bonnes proprits d'orthogonalit. Ce sont les squences de
Walsh engendres partir des matrices d'Hadamard [GLI 03].
1.4.1. Matrices d'Hadamard et codes de Walsh
1.4.1.1. Construction et proprits des matrices d'Hadtnard

Les matrices d'Hadamard Hn sont construites rcursivement partir d'une matrice
de dimension un H\ = (+1) et de la relation de rcurrence :
[1.42]
Les dimensions des matrices d'Hadamard sont des puissances de 2. On vrifie de

faon trs simple deux proprits :
[1-43]
[1.44]
o In est la matrice identit de dimension n et l'exposant T dsigne la transpose

d'une matrice. La premire proprit signifie que la matrice est symtrique et que la
nime ligne et la nime colonne sont identiques. La deuxime proprit signifie que le
produit scalaire d'une ligne l et d'une colonne c donne 0 pour l ^ ce t 1 pour l = c.
Du fait de la symtrie de la matrice, on a la mme proprit pour deux lignes / et V.
Une ligne de la matrice d'Hadamard est appele un code de Walsh. D'aprs les
remarques prcdentes, les n codes de Walsh sont orthogonaux entre eux. On peut
faire les remarques supplmentaires suivantes :
- chaque ligne contient autant de + que de , sauf la premire ligne qui ne contient
que des + ;
- l'orthogonalit entre deux codes diffrents n'est gnralement pas conserve si
on dcale un code par rapport l'autre, elle est cependant conserv entre la premire
ligne et les autres lignes quel que soit le dcalage ;
- l'orthogonalit est conserve si on affecte des poids diffrents chaque code ;
- si on multiplie chaque ligne de la matrice par la mme squence quelconque, les
proprits d'orthogonalit des lignes entre elles sont conserves.
1.4.1.2. Exemples de codes de Walsh de longueur 8

On calcule facilement H2 :
[1.451
Aprs deux rcurrences, on obtient :
On constate bien sur cet exemple que la premire ligne n'est compose que de +1
et les autres lignes d'autant de -1 que de +1. Considrons l'avant-dernire ligne w6
de la matrice Hg, la dernire ligne w-j et la dernire ligne dcale circulairement d'un
chip vers la droite wtj. On calcule aisment le produit scalaire entre les codes wq et
wj not < wq, W7 > :
< w6,w7 >= 1 - 1 + 1 - 1 + 1 - 1 + 1 - 1 [1.471
On obtient donc < >= 0. Les deux codes sont donc orthogonaux. Le
lecteur peut vrifier aisment que tous les produits scalaires de deux codes diffrents
sont galement nuls. On vrifie de faon similaire que < gwQ,g'wi >= 0 pour toute
valeur de g et g' : la proprit d'orthogonalit reste vraie quels que soient les poids
affects chaque code. Cela signifie qu'on peut affecter des puissances diffrentes
aux codes sans perdre l'orthogonalit. En revanche, on calcule < w e , w f j >= +4.
Ces deux codes ne sont pas orthogonaux. Cela signifie qu'on ne peut tolrer aucune
dsynchronisation entre les codes si on veut garder l'orthogonalit.

1.4.2. Multiplexage par les codes
1.4.2.1. Principe du multiplexage

En considrant une matrice d'Hadamard de dimension 71, on dispose de n codes
orthogonaux entre eux. Il est possible de transmettre n flux simultanment. Soit un
utilisateur i qui produit un flux binaire bi (kT b ) o k est un indice croissant avec le
temps. L'utilisateur i se voit affecter un code Wi o Wi est une ligne de la matrice d'Ha-
damard. Aprs talement, le signal est bi (kTb) Wi. Le multiplexage des n utilisateurs
consiste transmettre globalement :
n-l
S{kTb) = J2bj(kTb)j [1-481
j=0
Cela signifie qu'on transmet {kTb) Wj,0 pendant le premier temps-chip

puis bj (kT b ) Wjt 1 pendant le deuxime et ainsi de suite, en dsignant par Wjj
la l-me partie du code de walsh j.
1.4.2.2. Principe du dmultiplexage

A la rception, pour extraire la donne transmise par l'utilisateur i, il suffit de faire
le produit scalaire du signal reu et de la squence Wi (voir figure 1.13). En effet on
a:
< S (kTb), Wi >= ^n
3=1
bj (kTb) < Wj,Wi > [1.49]
Les diffrents codes sont orthogonaux entre eux (< Wj,Wi >= 0 pour i ^ j) et
on a < Wi, Wi >= n, on en dduit :
< S (kTb), Wi >= nbi (kTb) 11.50]
On peut donc facilement rcuprer le bit bi (kTb).
Figure 1.13. Multiplexage et dmultiplexage en CDMA
Dans un systme radiomobile, les multitrajets dont les retards sont suprieurs
une dure chip, vont crer des chos. Comme l'orthogonalit des squences n'est pas
conserve par un dcalage, cela va entraner de l'interfrence. En revanche, on peut
remplacer la somme de l'quation 1.48 par une somme pondre (avec des facteurs
diffrents pour les diffrents utilisateurs) sans aucunement perturber la rception.
flux multiplex
Figure 1.14. Exemple de multiplexage de deux flux en CDMA
1.4.2.3. Exemple de multiplexage en CDMA

On considre des squences de Walsh de longueur 8 et deux flux auxquels sont
affects les codes w$ et wj. Sur le flux 6, on transmet +1 et sur le flux 7 on transmet
- 1 . Le flux multiplex est 0 + 2 0 - 2 0 - 2 0 + 2 (voir figure 1.14). Le produit
scalaire de ce flux par w^ donne 0 + 2 0 + 2 0 + 2 + 0 + 2 = 8. Le dmultiplexage
pour le flux 6 redonne bien un bit +1. Le produit scalaire du flux multiplex par wj
donne + 0 - 2 - 0 2 0- 2 + 0- 2 = - 8 , ce qui redonne bien un bit -1.
1.4.3. Codes OVSF
Il est possible d'obtenir les mmes squences que celles de Walsh mais dans un
ordre diffrent. Soit Cn la matrice des codes et C^n.i la i + Ie ligne de cette matrice.
La rcurence est donne par :
1.51]
avec Ci = (Ci,o) = 1.
On peut prsenter l'ensemble des codes ainsi gnrs sous la forme d'un arbre
comme le montre la figure 1.15. Chaque code C n ,i a deux fils, C2n,2i et C2n,2i+i> qui
correspondent respectivement l'enchanement (-l-Cî, +C n > i) et (+C n ,i, C n ,i). A
titre d'exercice, le lecteur peut vrifier qu'on retrouve les codes de Walsh construits
avec les matrices d'Hadamard. On le peroit intuitvement partir des similarits sur
les rcurrences de construction. Par exemple Cs,i = w 4.
Figure 1.15. Arbre des codes OVSF (d'aprs 25.213)
La prsentation des codes orthogonaux sous la forme C2n,i permet de combiner de

faon simple des codes de longueur diffrente tout en gardant des proprits d'ortho-
gonalit. En d'autre termes, elle permet de transmettre plusieurs flux d'information
des dbits diffrents en gardant l'orthogonalit. Nous l'expliquons sur un cas particu-
liers qui peut tre gnralis sans problme. Considrons un utilisateur 1 transmettant
un dbit D avec le code C2n,i et un utilisateur 2 transmettant un dbit double avec

le code C n > i. Notons que, pour ce dernier, le code est plus court. Considrons le temps
bit de l'utilisateur 1. Il transmet un bit 61, soit la squence biC^n,!- Pendant le mme
temps l'utilisateur 2 transmet deux bits 62 et b'2. Aprs talement, on a ^CVu suivi de
Soit le produit scalaire des deux s-

quences transmises pendant un temps-bit du premier utilisateur. Par construction,
C2n, 1 quivaut Cn>0 suivi de Cn,o- On a donc :
[1-52]
On en dduit :
*
[1.53]
Les squences Cn$ et C n ,i tant orthogonales, on obtient PS = 0.
De faon gnrale, on peut combiner tout code Cn^ avec un autre code plus long
Cpj si ce dernier n'est pas un descendant de CnOn peut par exemple transmettre
4 flux un dbit D avec les codes Cs,o Cg,3 et un flux un dbit 4D avec le code
C2,i- La possiblit de moduler les dbits explique la dnomination OVSF (Orthogonal
Variable Spreading Factor) donne aux codes de Walsh prsents de cette faon.
1.5. Utilisation du CDMA en radiomobile
Un systme radiomobile est compos d'un ensemble de stations de base. Il faut que
la station de base puisse transmettre vers plusieurs utilisateurs et que les diffrentes
stations de base puissent transmettre sans se perturber l'une l'autre. Pour y parvenir,
les systmes cellulaires dits CDMA combinent le CDMA avec des codes orthogonaux
et l'talement de spectre avec des squence pseudoalatoires.
1.5.1. Diffrenciation des stations de base
Considrons d'abord la voie descendante en supposant, temporairement, que chaque

station de base n'met que vers un mobile. Le mobile reoit un signal utile de sa station
de base et des interfrences des stations de base voisine. Pour permettre au rcepteur
de fonctionner correctement, il est ncessaire que l'ensemble des interfrences ait une
caractristique proche d'un bruit Gaussien. Le choix de la squence PN(t) est parti-
culirement important pour garantir cette proprit.
1.5.1.1. Utilisation des m-sequences

Les systmes tels qu'IS-95 utilisent des squences PN, appeles m-sequences. Une
telle squence peut tre engendre partir d'un polynme binaire p{x) primitif sur
GF(2) (GF, Gallois Field) et d'un registre dcalage comportant m bascules rebou-
cl linairement (c'est--dire avec des portes ou exclusif guillemotright) [GAR 00].
On engendre alors une squence binaire de longueur n = 2m 1. Un exemple est
donn la figure 1.16 avec le polynme p(x) = x3 + x + 1. La squence obtenue
est 1110100. Cette squence est priodique ; on peut prendre de manire quivalente
n'importe quelle permutation de la squence, par exemple 0100111 (ou n'importe
quelle permutation de la squence inverse 0010111). En raisonnant sur des niveaux +
et , on obtient H 1- H .
Figure 1.16. Gnration d'une squence PNde longueur 8
Les squences PN ont de bonnes proprits d'autocorrlation (voir figure 1.17).

Si l'on considre une squence priodique, l'autocorrlation peut s'crire pour toute
valeur de k (entier relatif) :
1.54]
Le lecteur peut vrifier titre d'exercice que l'autocorrlation vaut n pour k = 0

et pour toute valeur de k multiple de n et vaut -1 partout ailleurs (voir figure 1.17).
Figure 1.17. Autocorrlation (priodique) d'une squence PN
Les squences PN sont de longueur n 2m 1. Il est en gnral plus commode

d'avoir une squence d'une longueur puissance de 2. On insre un bit supplmentaire
dans la squence pour cela. Par exemple, on ajoute un + la squence H H ,

ce qui permet d'avoir autant de + que de . Les proprits d'autocorrlation sont
lgrement modifies mais le pic de corrlation reste visible (voir figure 1.18).
Figure 1.18. Autocorrlation d'une squence

obtenue partir d'une m-squence
1.5.1.2. Systmes cellulaires synchrones
Dans un systme bas sur une utilisation des m-sequences, on utilise la mme s-
quence pour toutes les stations de base. Si deux stations de base transmettent avec la
mme squence affecte d'une mme phase, il est impossible la rception de sparer
les deux missions (on nglige les dlais de propagation). Pour permettre dans tous
les cas de diffrencier deux stations de base, on affecte chaque station la mme s-
quence mais avec un dcalage particulier. Cela ncessite que toutes les stations de base
soient synchronises. On a alors un systme synchrone. Entre un mobile et diffrentes
stations de base, les dlais de propagation ne sont pas identiques. Il faut donc que le
dcalage soit suffisamment important pour rester prsent la rception du mobile.
Dans le systme IS-95, la squence a une priode de 2 15 (ce qui correspond

une dure de 26,67 ms). Le dbit des donnes encodes est de 19,2 kbit/s. Le facteur
d'talement est de 64, ce qui donne un dbit chip de 1,228 Mchip/s. Une rfrence
temporelle est fournie par des rcepteurs GPS (Global Positionning System). A chaque
station de base, l'oprateur affecte un dcalage en multiple de 64 chips. Il y a donc
512 valeurs de dcalage possible. Un dcalage de 64 chips correspond 52pts, soit
une distance de 15 km. Un mobile dont la diffrence de distance par rapport deux
stations de base est de quelques kilomtres n'a donc aucun risque de confondre les
deux stations de base.
L'impratif de synchronisation des stations de base en IS-95 a t peru comme

rdhibitoire pour son adoption par les europens dans le cadre de l'UMTS. Notons
que cela rend le rseau tributaire d'un rseau de satellites matris par un pays non
europen.
Figure 1.19. Corrlation et autocorrlation de deux squences de Gold

de longueur 32
1.5.1.3. Utilisation des squences de Gold

Si l'on considre deux metteurs utilisant chacun une squence d'talement propre
et transmettant chacun un signal sur le mme canal radio, il faut pouvoir isoler chaque
signal la rception. Cela ncessite d'avoir une corrlation faible entre les squences.
Lorsqu'on fait l'intercorrlation de deux squences PN diffrentes, il n'y a pas n-
cessairement de bonnes proprits d'intercorrlation. Cependant il est possible de
construire des squences ayant une faible intercorrlation partir des squences PN.
Ce sont les squences de Gold [Gol 68]. Elles sont engendres partir de deux s-
quences PN (voir [DIN 98] et [SAN 04] pour le principe de construction).
A partir de 2 squences PN de longueur n = 2m 1, il est possible de construire

m
2 +1 squences de Gold de longueur n. En dehors du pic obtenu lorsqu'on compare
la squence elle-mme sans dcalage, la fonction de corrlation est borne en valeur
absolue par 2 m 2 +1 pour m impair et 2 + 1 pour m pair. La corrlation entre deux
squences diffrentes est contenue dans la mme borne. Par exemple, pour m = 8, on
obtient des squences de Gold de longueur 256 dont la corrlation varie entre -33 et
+33. Pour une squence de longueur 32, les bornes sont -9 et +9, comme on le constate
sur la figure 1.19.
1.5.1.4. Systmes asynchrones

Dans l'UMTS, on utilise des squences de Gold obtenues partir de de m-
sequences de longueur 2 25 1. La longueur de la squence est donc de 33 millions de
chips. On n'utilise qu'un extrait de 38 400 chips, ce qui donne une priode de rpti-
tion de 10 ms. Il y a 512 squences diffrentes. Pour diffrencier deux stations de base,
l'oprateur affecte chaque station de base une squence. Grce aux proprits des
squences d'intercorrlation de Gold, il n'y a pas besoin de synchronisation entre les
stations de base. L'interfrence cre par les stations de bases voisines la rception
d'un mobile est assimilable un bruit gaussien [TAN 04]. On peut donc bnficier
du gain d'talement. Il est possible d'utiliser la mme frquence sur l'ensemble des
stations de base d'un rseau.
Figure 1.20. Exemple d'affectation de squences de Gold aux stations de base
1.5.2. Principe de transmission sur la voie descendante
La transmission sur la voie descendante combine l'utilisation de codes orthogo-

naux (Walsh ou OVSF) pour permettre un multiplexage de plusieurs transmissions
et de squences PN pour permettre une rutilisation de la mme frquence sur diff-
rentes cellules. Le principe de transmission est illustre la figure 1.21. On applique
chaque canal (c'est--dire chaque transmissions vers un mobile particulier) une s-
quence de Walsh et une amplification particulire (gain gi). Les diffrents canaux sont
additionns et on applique l'ensemble le code d'embrouillage spcifique la station
de base. Ce schma gnral simplifi s'applique tant IS-95 et au CDMA-2000 qu'
l'UMTS. La squence pseudoalatoire applique une station de base s'appelle le
code d'embrouillage ou scrambling code.
Le nombre de codes de Walsh de longueur N est limit N. Pour permettre de

transmettre plus de N flux simultanment, il est possible d'allouer des codes dits se-
condaires (c'est le cas pour l'UMTS). Cela revient affecter un deuxime code d'em-
brouillage la station de base. L'interfrence intracellulaire est alors importante car il
n'y a pas orthogonalit entre les codes primaires et les codes secondaires.
Notons que si l'on considre un canal particulier, on peut voir l'mission comme
faite en une seule tape : une multiplication par une squence PN(t)Wi(t) o Wi(t)
est la i-me squence de Walsh rpte priodiquement.
Figure 1.21. Principe de transmission sur la voie descendante

d'un systme radiomobile CDMA
Figure 1.22. Combinaison des codes orthogonaux et des codes de Gold

sur la voie descendante
1.5.3. Principe de rception sur la voie descendante
Le rcepteur dans le mobile est de type Rake. Pour dcoder le canal i, le mobile
peut appliquer le schma de la figure 1.11 en remplaant PN*(t) par PN*(t)Wi(t).
Le fonctionnement du rcepteur Rake ncessite d'estimer les diffrents trajets du

canal de propagation. Cette estimation se fait sur une suite de chips prdfinis qui
ne transportent pas d'information. Cette suite peut tre contenue dans chaque bloc de
donnes mis par la station de base vers le mobile (voir chapitre 2). On parle alors
de squence pilote. On peut galement utiliser un canal entier, appel canal pilote
[VIT 95]. La solution retenue gnralement est d'utiliser le code de Walsh 1, vu sa
forme particulire. La station de base ne transmet aucune donne sur ce code, il reste
donc constamment +1. Le code d'embrouillage de la station de base se retrouve donc
directement.
1.5.4. Principe de transmission sur la voie montante
Dans un systme cellulaire CDMA, les diffrents mobiles transmettent sur la mme
frquence, qu'ils soient dans la mme cellule ou dans une cellule diffrente. Cela pro-
voque, comme sur la voie descendante, un interfrence sur la voie montante.
Les mobiles d'une mme cellule sont des distances diffrentes de la station de
base. Si on utilisait des codes orthogonaux pour diffrencier les mobiles, il faudrait
une synchronisation extrmement prcise pour compenser la dure chip aprs le d-
lai de propagation et faire en sorte que les signaux la rception restent orthogonaux.
Cela n'est pas possible dans la pratique. On utilise par consquent des squences pseu-
doalatoires pour diffrencier les mobiles entre eux. Dans la plupart des cas (exception
faite de l'UMTS TDD), la squence pseudoalatoire est propre au mobile et elle ne
dpend pas de la station de base laquelle il est rattach. Il n'y a donc jamais ortho-
gonalit entre deux signaux transmis par des mobiles diffrents, qu'ils soient dans la
mme cellule ou dans des cellules diffrentes. Le principe de transmission est indiqu
dans la figure 1.23. Pour que la rception se passe correctement la station de base, il
est ncessaire que les diffrents mobiles soient reus avec un puissance voisine (voir
chapitre 4). Le contrle de puissance est vital sur la voie montante.
Figure 1.23. Principe de transmission sur la voie montante

d'un systme radiomobile CDMA
Dans le systme IS-95, la squence PN est une m-squence de longueur 2 42

1. Elle dure environ 41 jours ; la phase est spcifique chaque mobile et calcule
partir de l'identit du mobile. Dans l'UMTS, on utilise des squences de Gold ou des
squences appeles S(2).
Figure 1.24. Utilisation de squences propres au mobile sur la voie montante
Notons que l'mission du mobile n'est pas lie une cellule particulire. Cette
caractristique facilite le soft-handover (voir dfinition au chapitre 6) car deux stations
de base peuvent tre en rception du signal mis par le mobile. L'inconvnient est
qu'il est ncessaire que la station de base connaisse la squence utilise par le mobile
pour le recevoir. Il y en a un trs grand n o m b r e possible et la station de base ne peut
pas la dcouvrir toute seule. Tout change est donc prcd d ' u n accs alatoire qui
comprend la transmission de la squence utilise par le mobile la station de base.
Cet change se fait en utilisant une squence donne parmi un n o m b r e restreint de
squences possibles.
1.6. Bibliographie
[BAU 02] B A U D O I N G . , Radiocommunications numriques . 1 , Principes, modlisation et

simulation, Dunod, Paris, 2 0 0 2 .
[DIN 98] D I N A N E., JABBARI B., Spreading Codes for Direct Sequence CDMA and Wide-
band CDMA Cellular Network , IEEE Communications Magazine, vol. 36, n9, p. 48-54,
1998.
[GAR 00] GARG V. K., IS-95 CDMA and cdma2000 : cellular/PCS systems implementation,
Prentice Hall, Upper Saddle River, NJ, 2000.
[GLA 96] G L A V I E U X A . , J O I N D O T M., Communications numriques : introduction, Masson,
Paris, 1996.
[GLI 03] GLISIC S. G., Adaptive WCDMA : theory andpractice, John Wiley and sons, Chi-
chester, GB, 2003.
[JAK94] JAKES W. C., Ed., Microwave mobile communications, IEEE Press, Piscataway,
N.J., 1994.
[LAG00] LAGRANGE X., Ed., Les rseaux radiomobiles, Collection IC2, Herms, Paris,
2000.
[PAR 00] PARSONS J., The Mobile Radio Propagation Channel, John Wiley and sons, Chi-
chester (GB), 2nd dition, 2000.
[PRO 01] PROAKIS J. G., Digital Communications, Me Graw Hill, 2001.
[SAN 04] S A N C H E Z J . , T H I O U N E M . , UMTS, Herms Science, Paris, 2e d. rev. et augm.
dition, 2004.
[SMG 98] SMG2 E., Selection procdures for the choice of radio transmission technologies
of the universal mobile tlcommunications system (UMTS 30.03), Rapport nETSI TR
101 112 v.3.2.0, ETSI, Avril 1998 1998.
[TAN 04] TANNER R., WOODARD J., Eds., WCDMA : requirementsandpraticaldesign, John
Wiley and sons, Chichester, GB, 2004.
[VIT 95] VLTERBL A., CDMA. Principles of Spread Spectrum Communication, Addison-
Wesley, 1995.
Chapitre 2
L'interface radio UTRA-FDD
L'UMTS possde deux modes de transmission sur la voie radio. En mode FDD
(Frequency Division Duplex), on spare la voie montante de la voie descendante en
utilisant deux frquences diffrentes. Par opposition, le mode TDD (Time Division
Duplex) consiste transmettre les deux voies sur la mme frquence mais des
instants diffrents. Les recommandations du 3GPP proposent les deux modes FDD
et TDD et dsignent l'interface radio par le sigle UTRA, Universal Terres trial
Radio Access. Le mode UTRA-FDD est caractris par l'utilisation du CDMA avec
possibilit d'avoir un facteur d'talement important (512) d'o l'appellation
WCDMA (Wideband CDMA).
Dans ce chapitre nous prsentons les mcanismes de l'interface radio d'UTRA-

FDD sans aborder les changes protocolaires qui sont prsents dans le chapitre 6.
Aprs une rapide prsentation de l'architecture gnrale de l'UMTS et de
l'architecture en couches de l'interface radio, nous prsentons la couche physique et
les diffrents canaux physiques. Nous dtaillons ensuite les concepts de format de
transport et de canaux de transport. Ensuite nous abordons les fonctions de la couche
MAC (Mdium Access Control) et les mcanismes radio (slection, handover).
Ceux-ci font partie de la couche RRC (Radio Resource Control) (voir chapitre 6)
mais sont galement fortement lis aux aspects physiques. Le chapitre se conclut par
une prsentation d'HSDPA (High Speed Data Packet Access) qui est une volution
importante permettant d'augmenter les dbits offerts.
Chapitre rdig par Xavier LAGRANGE et Sami TABBANE.

2.1. Introduction
2.1.1. Architecture matrielle de l'UMTS
Comme pour GSM, on fait la diffrence entre le rseau d'accs de l'UMTS

appel UTRAN, Universal Terres trial Radio Access Network, et le rseau cur
(Core Network). Le rseau cur est compos de l'ensemble des commutateurs, des
bases de donnes et des routeurs qui permettent le transport de l'information et la
gestion de l'utilisateur sur l'ensemble d'un territoire.
Le rseau d'accs UTRAN est compos des stations de base dployes sur le
territoire. Les recommandations utilisent le terme de nud B (Node B). Plusieurs
nuds B sont relis un RNC {Radio Network Controller) (voir figure 2.1). Le rle
du RNC est de grer la ressource radio et donc de contrler les nuds B. Les
fonctions du Nud B et du RNC sont prsentes en dtail dans le chapitre 6. Le
mobile est appel UE, User Equipement.
UTRAN Rseau Coeur
Figure 2.1. Place de l'UTRAN dans le rseau UMTS
2.1.2. Architecture en couches
L'architecture des couches basses sur l'interface radio est illustre sur la
figure 2.1. La couche 1 traite du niveau physique (codage canal, entrelacement,
talement, modulation). Diffrents niveaux de protections sont disponibles et
dfinissent diffrents canaux de transport. La couche 2 est dcoupe en plusieurs
sous-couches :
L ' interface radio UTRA-FDD 55
- la couche MAC, Mdium Access Control, permet le multiplexage de plusieurs

flux sur un mme canal de transport, ces diffrents flux peuvent concerner le mme
utilisateur ou diffrents utilisateurs selon les cas ;
- la couche RLC, Radio Link Control, permet de fiabiliser, si ncessaire, la
liaison grce un protocole de liaison de donnes ;
- la couche BMC, Broadcast/Multicast Control permet de diffuser des messages
plusieurs mobiles ;
- la couche PDCP, Packet Data Convergence Protocol, permet de supporter
diffrents protocoles rseau (IPv4, IPv6, autres) et offre galement un service de
compression d'en-tte.
La gestion des ressources radio est assure par la couche RRC, Radio Resource
Control, de niveau 3. Cette couche contient des mcanismes protocolaires entre le
mobile et le rseau d'accs (envoi d'un message d'allocation de canal, change de
messages de handover, transmission de mesures). Elle contient galement des
mcanismes internes lis au contrle des couches infrieures. Par exemple, les
messages RRC dterminent un ensemble de codages correcteurs possibles qui sont
appliqus par la couche physique. Comme on le constate sur la figure 2.2, la
majorit des couches en dessous de RRC peuvent tre contrles.
[source 25.301]
Figure 2.2. Architecture en couches sur l'interface radio

Donnes et signalisations sont transportes de faon similaire par la couche

physique. La sparation entre plan usager et plan contrle se fait au niveau MAC.
Diffrentes entits RLC transportent les donnes et la signalisation. La couche RRC
appartient au plan contrle. Les couches BMC et PDCP au plan usager.
La pile de protocole est dfinie entre le mobile et l'UTRAN. En gnral, l'entit

de niveau physique est situe dans le nud B et les entits de niveau suprieur sont
situes dans le RNC mais il y a des exceptions pour la couche MAC (voir
paragraphe 2.10).
2.2. Caractristiques gnrales de la couche physique de FUTRA-FDD
2.2.1. Caractristiques principales de l'UTRA-FDD
L'UTRA-FDD repose sur le CDMA large bande 3,84 Mchip/s. Sur la voie
descendante, les canaux sont spars par les codes OVSF qui sont orthogonaux entre
eux. Un code d'embrouillage est appliqu aux missions de la station de base pour la
diffrencier de ses voisines. Sur la voie montante, la sparation se fait grce un
code pseudo alatoire propre chaque mobile.
Les bandes de frquences prvues pour l'UTRA-FDD sont de 1 920 MHz

1 980 MHz pour la voie montante et de 2 110 2 170 MHz pour la voie descendante
[25.104]. L'cart duplex entre voie montante et voie descendante est donc de
190 MHz. Les bandes sont dcoupes en blocs de 5 MHz, chaque bloc pouvant
accueillir une porteuse. Si toute la bande prvue est disponible on dispose de
2 x 60 MHz soit 12 porteuses duplex. On estime 4 le nombre typique d'oprateurs
par pays, chaque oprateur dispose donc de 3 porteuses duplex.
2.2.2. Trame de base
L'interface UTRA-FDD ne repose pas sur le TDMA (Time Division Multiple

Access) mais uniquement sur le CDMA (Code Division Multiple Access) ou
multiplexage par les codes. Cependant, elle est organise partir d'une trame
temporelle de 10 ms, structure comme une suite de 15 intervalles de temps ou slots
de 10/15 ms, soit 666,67 [is. Lorsqu'une transmission entre un mobile et la station
de base se fait, elle occupe tous les slots successifs de la trame ( la diffrence d'un
systme TDMA o on occupe un seul slot de la trame). Le slot sert dfinir la
granularit du contrle de puissance : au sein d'un slot, la puissance est constante
mais entre deux slots successifs, il peut y avoir variation de la puissance transmise.
Figure 2.3. Trame de base en UTRA-FDD
Chaque trame est numrote de 0 4 095. Ce numro est appel SFN, System
Frame Number. Il est incrment de 1 chaque nouvelle trame de 10 ms avec une
numrotation modulo 4 096. Le numro SFN permet de dfinir de faon prcise des
structures sur plusieurs trames. Par exemple, lorsqu'un bloc de donnes est tal sur
4 trames, le bloc commence systmatiquement lorsque SFN modulo 4 vaut 0.
L'accs alatoire en UTRA-FDD possde une composante en code mais

galement une composante temporelle puisqu'il repose sur l'Aloha synchonis ou
Aloha slott. Le slot utilis est un slot de dure double du slot lmentaire, soit
1 333,33 (as. Cette dure permet de s'assurer qu'il n'y a pas collision entre deux
missions sur des slots diffrents quels que soient les dlais de propagation entre les
mobiles et la station de base (voir paragraphe 2.9.3).
Figure 2.4. Slots d'accs et trame 20 ms en UTRA-FDD
2.2.3. Modulation
L'UMTS utilise une modulation QPSK, Quaternary Phase Shift Keying [Pro 01].
On peut considrer la modulation QPSK comme deux modulations binaires, l'une
sur la voie en phase (voie I) et l'autre sur la voie en quadrature (voie Q) (voir
chapitre 1). Sur chaque voie, on transmet un bit par symbole. Une autre approche
consiste considrer qu'on transmet dans le plan complexe et qu'un symbole
correspond un nombre complexe parmi les 4 suivants :
V2/2(-l-y) et V2/2(l-y).
Le dbit de la modulation est de 3,84 Msymboles/s. Du fait de l'utilisation de

l'talement de spectre, on transmet des chips et non des bits. La transmission se fait
donc 3,84 Mchip/s sur chaque voie. On note qu'il s'agit de chips dans le plan
complexe.
2.3. Canaux physiques de donnes
Dans cette partie, nous prsentons les principaux canaux utiliss pour transporter
des donnes des couches suprieures. Nous appelons un tel canal canal physique
de donnes bien que cette dnomination ne soit pas systmatiquement reprise par
les spcifications. Bien sr, les donnes transportes au niveau physique peuvent
correspondre de la signalisation au niveau suprieur. La caractristique de ces
canaux est qu'ils transportent des lments binaires non interprts par la couche
physique.
2.3.1. Transmission descendante sur canal ddi (DPCH)
Nous prsentons dans ce paragraphe l'organisation de la transmission de la

station de base vers le mobile (voie descendante) en mode ddi, c'est--dire
lorsqu'un code OVSF est allou un mobile donn, par exemple parce qu'il est en
communication. Le canal utilis dans ce cas s'appelle un DPCH, DedicatedPhysical
Channel.
Pendant un slot, la station de base transmet 2 560 chips complexes. Comme il y a

15 slots en une trame de 10 ms, le dbit en chips complexes est donc de
2 560/(10/15) kchip/s soit 3,84 Mchip/s. Ces 2 560 chips sont organiss en 4 parties
diffrentes :
- u n champ TFCI (Transport Format Combination Indicator) donne, parmi un
ensemble de schmas de codage et d'entrelacement prdfinis, le schma utilis ;
- un champ TPC (Transmit Power Control) indique au mobile s'il doit
augmenter ou diminuer sa puissance sur la voie montante ;
- u n champ Pilot contient une squence prdfinie qui permet au mobile de
sonder le canal de transmission ;
- les donnes sont spares en deux champs, le premier champ tant plus court
que le second.
Les champs pilote, TFCI et TPC sont ncessaires pour permettre le contrle
physique de la liaison. Ils forment le DPCCH, Dedicated Physical Control Channel.
Les champs de donnes forment le DPDCH, Dedicated Physical Data Channel.
L'appellation de donnes est faite dans le contexte de la couche physique. En

vocabulaire OSI, les 2 champs de donnes constituent un SDU (Service Data Unit)
et par consquent un segment de PDU (Protocol Data Unit) de niveau MAC, ce
dernier pouvant contenir aussi bien des donnes utilisateurs que de la signalisation.
Source : d'aprs [25.211]
Figure 2.5. Principes de transmission sur la voie descendante (canal ddi)
Donnes TPC TFCI Pilote Total Facteur Chips Dbit

(champ 1 + champ 2 (bits) (bits) (bits) (bits) d'talement pilotes donnes
en bits) (kbit/s)
0 + 2 2 2 4 2 048 3
0+4 2 0 4 10 512 2 048 6
2+6 2 2 8 2 048 12
2 + 8 2 0 8 2 048 15
2+10 2 2 4 1 024 18
2 + 12 2 0 4 20 256 1 024 21
2+12 2 2 2 512 21
2+14 2 0 2 512 24
6 + 22 2 2 8 1 024 42
6 + 26 2 2 4 40 128 512 48
6 + 28 2 0 4 512 51
12 + 48 4 8 8 80 64 512 90
28+112 4 8 8 160 32 256 210
56 + 232 8 8 16 320 16 256 432
120 + 488 8 8 16 640 8 128 912
248 + 1 000 8 8 16 1 280 4 64 1872
Figure 2.6. Schmas de transmission sur la voie descendante (canal ddi)

Les spcifications prcisent 16 formats possibles de transmission suivant le

facteur d'talement utilis, la taille du champ pilote et la prsence ou non du champ
TFCI. Il existe, de plus, un mode compress que nous ne prsentons pas par souci de
simplification. Les principaux formats sont prsents dans la figure 2.6 ainsi que les
dbits bruts de donnes. Quel que soit le facteur d'talement utilis (SF, Spreading
Factor), un slot correspond toujours 2 560 chips complexes mais la quantit de
donnes transportes varie. Par exemple, avec un facteur d'talement de 128, on
peut transmettre 28 bits (en deux champs de 6 et 22 bits), soit 42 kbit/s, tandis qu'un
facteur de 8 permet de transmettre 608 bits, soit 912 kbit/s. Ce dernier facteur est
utilis pour un circuit offrant un dbit utilisateur de 384 kbit/s.
2.3.2. Canal physique descendant partag (PDSCH)
En tudiant le tableau de la figure 2.6, on constate que les canaux physiques

ddis contiennent une quantit non ngligeable de bits de contrle : pour une
transmission 21 kbit/s, il y a 6 bits de contrle pour 14 bits de donnes, soit 43 %.
Les recommandations dfinissent un canal sur la voie descendante qui ne contient
que des bits de donnes et permet d'atteindre des dbits plus levs qu'un canal
ddi pour un mme facteur d'talement. Il s'agit du PDSCH, Physical Downlink
Shared Channel (voir figure 2.7). Le terme partag (shared) fait rfrence au fait
qu'il peut contenir sur des trames successives des donnes destines diffrents
mobiles. Le destinataire des donnes est indiqu dans les informations de couches
suprieures. Le dbit brut maximal qu'on peut atteindre est de 1 920 kbit/s (voir
figure 2.8).
Figure 2.7. Structure du PDSCH

Donnes Etalement Dbit de donnes

(kbit/s)
20 256 30
40 128 60
80 64 120
160 32 240
320 16 480
640 8 960
1 280 4 1 920
Figure 2.8. Schmas de transmission sur le PDSCH
Le canal PDSCH a t conu pour permettre un mode paquet sur la voie radio1.
Il est toujours utilis conjointement avec un canal physique ddi car il est
ncessaire de contrler physiquement toute liaison. En particulier, le canal physique
contient un champ TFCI partag en 2 parties, l'une portant sur le PDSCH, l'autre
sur le canal ddi lui-mme. Un exemple d'utilisation est montr en figure 2.9. Trois
utilisateurs consultent, par exemple, un serveur. Pour chacun, un circuit bas-dbit
support par le DPCH est tabli pour la signalisation, ce circuit consomme peu de
ressources. Lorsque des donnes sont transmises vers un utilisateur, on utilise le
PDSCH qui dispose d'un dbit lev et ncessite donc un faible talement. Le
principe gnral est de transmettre un instant donn vers un utilisateur le plus
rapidement possible en utilisant la totalit du PDSCH (premire transmission dans le
dessin) mais rien n'empche de diviser le PDSCH en code entre plusieurs
utilisateurs (deuxime transmission sur le dessin).
temps
Figure 2.9. Principe d'utilisation du PDSCH
1. Le canal PDSCH n'est pas utilis dans les rseaux oprationnels en 2004. Il est cependant
prsent dans cet ouvrage car les mmes principes sont repris pour HSDPA.
2.3.3. Canal de diffusion de donnes (S-CCPCH)
Lorsque le rseau a besoin de diffuser des donnes plusieurs mobiles, il peut

utiliser le canal de contrle commun secondaire (S-CCPCH, Secondary Common
Control Physical Channel). Ce canal est improprement appel canal physique de
contrle. 11 n'a aucune action de contrle au niveau physique mais il est utilis pour
transporter des donnes fournies par les couches suprieures : appel en diffusion des
mobiles (paging), diffusion de donnes un ensemble de mobiles ou un mobile
particulier (voir canal de transport FACH). La notion de contrle se rapporte
donc au niveau suprieur et non au niveau physique.
Le canal S-CCPCH peut contenir une information de transport (champ TFCI) et

des bits pilotes mais ce n'est pas obligatoire. La prsence du TFCI permet d'utiliser
dynamiquement plusieurs formats de transport. Dans le cas o le rseau transmet des
donnes un seul mobile et o la position du mobile est connue approximativement,
il est possible de transmettre le signal en direction du seul mobile concern (beam-
forming). Le mobile doit alors disposer de bits pilotes pour faire correctement le
sondage du canal (analyse des multitrajets et ajustement du rcepteur en rteau).
Le facteur d'talement du S-CCPCH peut varier de 4 256. Suivant la prsence

ou non des champs TFCI et des bits pilotes, la taille des donnes encodes varie de
10 bits 1 272. Les dbits correspondants vont de 15 kbit/s 1 908 kbit/s au niveau
physique. Ce dbit inclut donc les donnes aprs codage correcteur et il correspond
typiquement un dbit utile de 7 600 kbit/s environ.
Figure 2.10. Format du canal S-CCPCH
2.3.4. Transmission montante sur canal ddi
La transmission sur la voie montante est diffrente de celle de la voie

descendante. On dfinit les canaux physiques de donnes DPDCH et de contrle
DPCCH respectivement partir des voies en phase et en quadrature. Sur chaque
voie, 2 560 chips rels sont transmis pendant un slot. Le facteur d'talement pour le
canal de contrle est toujours gal 256, ce qui donne 10 bits de contrle physique.
La rpartition des bits diffre selon les cas. Les champs sur la voie montante sont les
suivants (voir figure 2.11) :
- un champ TFCI (Transport Format Combination Indicator) donne, parmi un
ensemble de schmas de codage et d'entrelacement prdfinis, le schma utilis ;
- un champ TPC (Transmit Power Control) contient une commande pour
contrler la puissance de la voie descendante ;
- un champ FBI (Feed Back Indicator) donne une indication sur la puissance de
transmission et permet de raliser la boucle ferme de contrle de puissance de la
voie descendante ;
- un champ Pilot contient une squence prdfinie qui permet la station de
base de sonder le canal de transmission.
Figure 2.11. Principes de transmission sur la voie montante (canal ddi)
DPDCH sur voie I DPCCH sur voie Q (15 kbit/s)

Donnes Facteur Dbit des Bits TPC TFCI FBI Total Facteur Chips
d'talement donnes pilotes d'talement pilotes
SF (kbit/s) SF
10 256 15 8 2 0 0 2 048
20 128 30 7 2 0 1 1 792
40 64 60 6 2 2 0 10 256 1 536
80 32 120 6 2 0 2 1 536
160 16 240 5 2 2 1 1 280
320 8 480 5 1 2 2 1 280
640 4 960
Figure 2.12. Schmas de transmission sur le canal physique ddi montant (DPCH)
Le facteur d'talement sur le canal de donnes DPDCH peut varier de 256 4, ce

qui permet d'envisager des dbits bruts de 15 960 kbit/s. Il est possible (voir
section 2.5.2) de disposer de plusieurs DPDCH et d'augmenter encore les dbits.
2.3.5. Canal d'accs PRACH
Le canal d'accs (PRACH, Physical Random Access Channel) permet au mobile

d'mettre des messages sans utiliser le code d'embrouillage qui lui est propre. En
consquence, un message peut tre envoy par le mobile tout moment mais
l'mission peut entrer en collision avec d'autres transmissions du mme type. Le
mcanisme d'accs est dcrit dans le paragraphe 2.9.3.
La structure du canal PRACH est indique la figure 2.13. Elle est proche de
celle du canal de donnes sur la voie montante. Les donnes sont transmises sur la
voie en phase et le contrle sur la voie en quadrature. Le contrle de puissance se
fait uniquement en boucle ouverte. Il n'y a donc pas de bits TPC mais seulement les
bits pilotes et le champ TFCI pour indiquer le format de transport utilis.
Plusieurs facteurs d'talement peuvent tre utiliss sur le PRACH. Les dbits
correspondants sont donns dans le tableau de la figure 2.14 pour permettre de
comparer le poids du contrle par rapport aux donnes. Parler de dbit a peu de sens
puisque le canal PRACH est utilis pour des transmissions courtes : la transmission
se fait pendant une ou deux trames de 10 ms et s'arrte ensuite. Il vaut mieux
raisonner en taille de message. Avec un codage typique, le canal PRACH permet de
transporter de 9 150 octets. En comparaison, le canal RACH de GSM ne permet
que de transmettre un octet. Il est donc envisageable dans l'UMTS de faire de la
transmission de paquets sur la voie montante sur le PRACH dans le cas d'une
transmission de faibles volumes d'information (tlmesures, ...).
Source : 25.211
Figure 2.13. Structure du canal PRACH

Donnes Contrle
Donnes Facteur Dbit des Pilot TFCI Total Facteur Chips Dbit de
(bits) d'talement donnes d'talement pilotes contrle
(kbit/s) (kbit/s)
10 256 15 8 2 10 256 2048 15
20 128 30
40 64 60
80 32 120
Figure 2.14. Schmas de transmission sur le canal PRACH
2.4. Canaux physiques de contrle
Dans cette partie, nous prsentons les principaux canaux utiliss par les mobiles
pour contrler certains paramtres de la couche physique : synchronisation, mesure
de puissance, surveillance de la station de base de service, mise en mode conomie.
Ces canaux ne sont pas tous dsigns comme canaux de contrle par la norme. En
gnral, ils ne transportent pas de donnes relatives aux couches suprieures.
2.4.1. Canaux de synchronisation P-SCH et S-SCH
2.4.1.1 .Canalprimaire de synchronisation (P-SCH)

Toute station de base d'un rseau d'accs UTRAN de type FDD met
rgulirement un code prdfini. Celui-ci permet au mobile de se synchroniser et,
par l-mme, de vrifier qu'il est bien l'coute d'un rseau UMTS. L'mission
rgulire de ce code prdfini constitue le canal primaire de synchronisation
(P-SCH, Primary Synchronization Channel).
Le code utilis est une suite de 256 chips base sur une squence gnralise de
Golay [25.213]. Elle a de bonnes proprits d'auto-corrlation. Quand un mobile est
sous tension, il examine les frquences de la bande UMTS et fait une corrlation
entre la suite de chips reue sur cette frquence et le code du P-SCH (principe du
filtre adapt). En dtectant les pics de corrlation, le mobile dtecte les stations de
base proximit et peut se synchroniser sur leur mission. Le code tant transmis
sur chaque slot (de 666 (as), le mobile n'est synchronis qu'au niveau slot et non au
niveau trame de 10 ms (voir figure 2.15). De plus, du fait de multitrajets, deux pics
de corrlation peuvent correspondre l'mission d'une mme station de base. Le
mobile n'est pas capable de diffrencier ce cas de deux missions de stations de base
diffrentes avec une synchronisation trs proche.
66 Principes et volutions de l ' U M T S
256 chips
complexes
SCH primaire J^- # gb

SCH secondaire J L^
SCH<tR H B B code OVSF

CPICH I j I ! I I C256.0
sloto slot 1 slot 14 temPs
trame de 10 ms
r
CPICH Squence de 20 bits 0
avec talement 256
2560 chips complexes
Figure 2.15. Structure des canaux de synchronisation et pilote
2.4.1.2. Canal secondaire de synchronisation (S-SCH)

Le canal secondaire de synchronisation (S-SCH, Secondary Synchronization
Channel) a deux objectifs : permettre au mobile de dterminer le dbut de la trame
de 10 ms et diffrencier l'mission d'une station de base de ses voisines.
Le canal de synchronisation secondaire est constitu de transmissions de codes

de 256 chips chaque slot, comme pour le canal de synchronisation primaire, mais
ce n'est pas le mme code chaque slot. On a une squence de 15 codes successifs
(/', C/' 1 ,... C/ 1 4 ) o i est un indice dfinissant une squence parmi 64 squences
diffrentes [25.213] ; par consquent la priode de rptition de chaque squence
correspond une trame de 10 ms. Les squences (CJ', Cs''\... CslM) possdent de
bonnes proprits d'autocorrlation et d'intercorrlation. Pour chaque squence,
toute permutation ne redonne pas la mme squence, ni aucune autre. Par exemple,
(C/ 7 , C/' 8 ,... C/ 1 4 , C/ 0 ,... C/ 6 ) est diffrent de (C/, C/' 1 ,... C/' 14 ) pour tout y, y
compris j = i.
Aprs avoir tabli la synchronisation slot, le mobile recherche la squence (C,' 0,

C/ ,... C/' 14 ) parmi les 64 squences possibles. Une fois qu'il l'a trouve, il
1
identifie le dbut de la trame (voir figure 2.15). L'oprateur affecte des squences
diffrentes des stations de base qui peuvent interfrer : le canal de synchronisation
secondaire est donc caractristique d'une station de base dans une zone
gographique donne. L'oprateur peut rutiliser le mme code sur deux stations de
base si celles-ci sont suffisamment loignes.
2.4.2. Canal pilote CPICH
Le canal pilote commun la cellule (CPICH, Common Pilot Channel) a pour

objet de permettre au mobile de dterminer le code d'embrouillage utilis par la
station de base et fournit un signal continu autorisant des mesures d'nergie pour
dterminer, par exemple, la station de base dont il est le plus proche.
Le CPICH correspond l'mission dans chaque slot de 20 bits, tous 0, avec un

talement de 256 (on utilise le code OVSF Cch,256,o)- Le code d'embrouillage de la
cellule est appliqu au CPICH comme aux autres canaux. La squence de chips
transmise correspond donc toujours au code d'embrouillage.
Lorsque le mobile est synchronis grce l'coute des SCH, il ne connat pas le
code d'embrouillage mais seulement le groupe auquel appartient cette squence. En
effet, la recommandation dfinit une correspondance entre un groupe de 8 codes
d'embrouillage et la squence utilise sur le canal SCH secondaire (il y a en effet
512 codes d'embrouillage soit 64 x 8 pour 64 squences de S-SCH). Le mobile peut
essayer successivement les 8 possibilits pour dterminer la squence rellement
utilise.
2.4.3. Canal de diffusion des informations systme (P-CCPCH)
Le canal de contrle commun primaire (P-CCPCH, Primary Common Control

Physical Channel) permet de diffuser les informations systme utiles pour que le
mobile puisse se mettre en veille sur le rseau. Ce canal est diffus sur l'ensemble
de la cellule.
La structure du P-CCPCH est complmentaire de celle des canaux de

synchronisation. Afin de se rapprocher d'une puissance de transmission totale
constante au cours du temps, le P-CCPCH n'est vritablement actif que lorsque les
canaux de synchronisation sont inactifs. Il contient donc 2 5 6 0 - 2 5 6 = 2 304 chips
complexes. Le facteur d'talement utilis est 256, ce qui permet donc de transmettre
18 bits par slot.
Le mobile doit pouvoir lire les informations du P-CCPCH sans connaissance

pralable de la configuration de la cellule. Le P-CCPCH est transmis sur le code
OVSF C256,i [25.213]. Sur le canal, la configuration des autres canaux physiques lui
est indique.
Contrairement aux autres canaux prsents dans cette partie, le P-CCPCH

transporte des donnes des couches suprieures. Cependant ces donnes sont
toujours des donnes de contrle au niveau 3 (messages RRC). C'est ce qui explique
la dnomination Control pour ce canal.
SCH pi J5 a. H
CPICH ' -- r" I " " code OVSF C256.0
P-CCPCH ^ ^ ' " J code OVSF C256 1
sloto slot 1 slot 14 temPs
trame de 10 ms
P-CCPCH Squence de 18 bits

avec talement 256
2304 chips complexes
4 -
Figure 2.16. Structure du canal P-CCPCH
2.4.4. Canaux d'indication de paging ( P I C H )
Un mobile en veille doit constamment couter le rseau pour dtecter un

ventuel appel en diffusion [paging). Si les cellules sont de grande capacit et les
zones de paging tendues, l'oprateur doit configurer un canal S-CCPCH dbit
assez important car un grand nombre d'appels en diffusion doit tre coul. Les
mobiles consomment une nergie non ngligeable pour dcoder tous les messages
d'appel alors qu'une infime proportion les concerne.
Pour rduire la consommation des mobiles en coute des appels, on utilise un

principe de subdivision de la population en groupes de paging . Un mobile
appartient un groupe de paging donn en fonction, par exemple, de son identit.
Sur un canal particulier, le rseau transmet rgulirement un indicateur de paging
pour chaque groupe. Si l'indicateur est inactif, le mobile n'a pas besoin de dcoder
les messages d'appels : aucun mobile de son groupe n'est appel et il peut s'abstenir
de dcoder le canal S-CCPCH. Si l'indicateur est actif, un message d'appel peut lui
tre envoy, il doit alors dcoder le canal.
Le canal d'indication de paging est appel PICH, Paging Indicator Channel. Il

utilise un code d'talement de taille 256, ce qui offre une capacit de 300 bits toutes
les 10 ms. Un code rptition est utilis pour rduire le taux d'erreur. Le taux de
codage peut varier de 1/16 1/2 suivant la configuration du rseau. Cela permet de
transmettre de 18 144 indications de paging. On peut dfinir un cycle sur plusieurs
trames de 10 ms et constituer ainsi un nombre bien suprieur de groupes de paging
(voir [25.211]).
2.4.5. Canal d'acquittement de prambule (AICH)
Lors de l'accs alatoire (voir section 2.9.3), le mobile met un prambule parmi
16 prambules possibles dans un slot d'accs. Grce au canal AICH, Acquisition
Indicator Channel, le rseau peut indiquer les prambules qui ont t correctement
reus. On peut voir le canal AICH comme tant compos de 16 canaux transportant
chacun un bit d'indication d'acquisition par prambule possible dans un slot
d'accs. Ces 16 canaux sont multiplexs en CDMA par des codes de Walsh de
longueur 32 (on utilise seulement 16 codes parmi les 32 possibles). L'ensemble est
tal par un code OVSF de longueur 256 librement choisi par l'oprateur. La
longueur en chips est donc de 32 x 256=4 096 chips. Le slot d'accs est de 5 120
chips. Il y a donc 1 024 chips non utiliss et utilisables dans le futur.
2.4.6. Autres canaux physiques
Les recommandations spcifient d'autres canaux physiques que ceux prsents

dans ce chapitre. Le PCPCH, Physical Common Packet Channel, est un canal qui
permet de disposer d'un accs alatoire plus performant. Le terminal met un
prambule comme pour le RACH, ce prambule est acquitt mais il y a une phase
supplmentaire de dtection de collision. Cela permet une transmission plus longue
et contrle en puissance. Le PCPCH est coupl avec des canaux physiques
d'indication qui sont des extensions de l'AICH : l'AP-AICH, Access Preamble
Acquisition Indicator Channel, le CD/CA-ICH, Collision Detection/Channel
Assignment Indicator Channel, et le CSICH, CPCH Status Indicator Channel. Il est
galement coupl avec un DPCCH descendant pour permettre le contrle de
puissance.
2.5. Principes des chanes de transmission
2.5.1. Chane de transmission sur la voie descendante
Sur la voie descendante, la station de base transmet plusieurs flux en parallle

diffrents mobiles sur un support physique unique. Le principe de transmission est
prsent dans la figure 2.17. Chaque flux de la couche physique un dbit D est
dcoup en deux flux par un convertisseur srie/parallle (passage dans le plan
complexe). Il est ensuite mis en canal par un code OVSF (Orthogonal Variable
Spreading Factor). Le facteur d'talement est fonction du dbit D de telle sorte que
le dbit en sortie est toujours de 3,84 Mchips complexes par seconde. Les diffrents
canaux sont ensuite amplifis en fonction de l'algorithme de contrle de puissance.
Aprs sommation, on applique le code d'embrouillage propre la station. Enfin, on
passe dans l'tage de modulation. Pour les canaux de synchronisation dont la

structure est particulire, on n'applique pas le code d'embrouillage.
Le code d'embrouillage a une longueur de 38 400 chips. Il correspond donc la

trame de 10 ms. La norme a dfini 512 codes de brouillage utilisables organiss en
64 groupes de 8 codes.
Le symbole j dsigne le nombre complexe tel que j2 = -1. Le symbole /' est un indice de canal.
Figure 2.17. Multiplexage et modulation sur la voie descendante
2.5.2. Chane de transmission sur la voie montante
Sur la voie montante, les missions des diffrents mobiles s'additionnent sur le
canal de propagation radio. La figure 2.18 prsente la chane de transmission pour
un mobile. Il y a toujours un seul canal de contrle. Il est possible de multiplexer
plusieurs canaux physiques de donnes pour un mme mobile en utilisant des codes
OVSF diffrents (et qui sont orthogonaux). Il n'est pas sr que cette possibilit
prvue par la norme soit vraiment utilise.
2.6. Gestion de format de transport
La couche physique gre galement le codage correcteur d'erreur. Pour

permettre une grande souplesse dans le choix du type de codage, les
recommandations introduisent la notion de format de transport.
Figure 2.18. Multiplexage et modulation sur la voie montante pour le canal ddi
2.6.1. Notion de format de transport
Dans les communications radiomobiles, le canal de transmission est trs

fluctuant. Il n'est pas possible de dfinir un codage correcteur unique et applicable
toutes les situations. Dans l'UMTS, on dfinit un grand nombre de schmas de
codage. Il n'y a pas de schma de codage impos pour un service donn. C'est
l'oprateur de choisir le codage plus adapt un service donn dans des conditions
donnes. Cependant, les recommandations spcifient un principe gnral de codage
avec un large choix possible l'intrieur de ce cadre gnral [25.212].
Le codage porte systmatiquement sur des blocs de donnes appels blocs de

transport (transport block). Un bloc est ventuellement protg par un code
dtecteur d'erreur de type CRC (Cyclic Redundancy Check) ; le bloc protg passe
ensuite par un codeur convolutionnel, soit de type classique, soit de type turbo
(Parallel Concatenated Convolutional Code) (pour le fonctionnement du codage
correcteur d'erreur, voir le chapitre 3 de [LAG 00]). Le taux de codage est de 1/2 ou
1/3. Le bloc encod est alors entrelac et peut tre ensuite poinonn ou bien tendu
par rptition de certains bits pour se conformer une taille impose par la couche
physique (nombre de bits de donnes disponibles sur le canal physique). Cette
opration est appele adaptation de dbit ou rate matching. La transmission du bloc
encod peut se faire sur une dure suprieure une trame de 10 ms. Le TTI,
Transmission Time Jnterval, est le paramtre dfinissant l'talement d'un bloc
encod. Ce paramtre peut valoir 1, 2, 4 ou 8 trames de 10 ms. Le bloc encod est
donc segment suivant la valeur du TTI. Un deuxime entrelacement peut tre
effectu avant la rpartition des bits sur les champs de donnes des canaux
physiques.
Il est possible de transporter plusieurs blocs de transport dans un mme TTI.

Dans ce cas, le canal de transport accepte un ensemble de blocs de transport, appel
Transport Block Set.
Figure 2.19. Principe gnral du codage dans l'UMTS
Les recommandations proposent une bote outils de codage. Le choix d'un

outil dans cette bote forme ce qu'on appelle un format de transport . Les
paramtres d'un format de transport sont lists dans le tableau de la figure 2.20.
Par exemple, prendre un bloc de 244 bits, ajouter un CRC de 16 bits, puis passer
le tout par un codage convolutionnel de taux 1/3 et le transmettre sur 2 trames, soit
un TTI de 20 ms, constitue la dfinition d'un format de transport. Dans ce cas,
l'ensemble des blocs de transport est rduit un seul bloc.
Lorsqu'un support radio (radio bearer) est tabli, le format de transport est
prcis dans le message d'allocation RRC : longueur du CRC, type de correction
d'erreur, valeur du TTI. Ces paramtres sont valables pour toutes les transmissions.
Il est cependant possible, par un change de messages RRC, de les modifier : les
recommandations parlent de paramtres semi-statiques. En revanche, la taille de
bloc de transport et le nombre de blocs de transport peuvent varier dynamiquement,
c'est--dire chaque transmission. L'ensemble des valeurs possibles est prcis
dans les messages RRC d'tablissement ou de modification. A chaque transmission,
le champ TFCI permet au rcepteur de retrouver les valeurs utilises.
Taille du bloc de Transport variable dynamiquement paramtres

transport Block Size dynamiques :
Nombre de Transport variable dynamiquement ensemble de valeurs
blocs de Block Set Size dfinis par
transport signalisation RRC
24
16
Dtection CRC 12
Paramtres
d'erreur 8 semi-statiques
0
taux 1 (pas de codage)
Code taux 1/2 une valeur
convolutionnel choisie parmi
n possibles
Correction taux 1/3 par signalisation
d'erreur RRC
Turbo-code taux 1/3
Nombre de 1 trame ( 10 ms)
trames de 10 ms Valeur du TTI 2 trames (20 ms)
pour la 4 trames (40 ms)
transmission 8 trames (80 ms)
Figure 2.20. Paramtres d'un format de transport
2.6.2. Combinaison de formats de transport
Les recommandations spcifient un large ventail de schmas de codage. Dans

certains cas, les lments binaires d'un bloc de donnes transmettre n'ont pas tous
la mme sensibilit aux erreurs. En particuliers pour la parole, la qualit perceptible
la restitution dpend plus de la rception correcte de certains bits que d'autres (en
simplifiant l'extrme, les bits de poids forts sont plus importants que les bits de
poids faible). Il est donc intressant de combiner les formats de transport et de
permettre, pour un flux venant d'une seule source, de coder diffrentes parties de ce
flux de manire diffrente. On obtient le concept canal de transport composite ou
CCTrCH (Coded Composite Transport Channel).
Dans l'exemple reprsent, on considre qu'il n'y a qu'un bloc de transport par ensemble de
bloc de transports et que tous les diffrents canaux de transport ont le mme TTI pour
simplifier la reprsentation.
Figure 2.21. Principe du canal de transport composite
Par exemple, le codeur de parole de type EFR (Enhanced Full Rate) produit des
blocs de 244 bits toutes les 20 ms. Au lieu de coder uniformment les 244 bits, on
les diffrencie en 3 classes A, B et C. Il y a respectivement 81 bits de classe A (la
plus sensible aux erreurs), 103 bits de classe B et 60 bits de classe C. Par exemple
[LEC 02], on protge la classe A par un CRC de 8 bits puis un code convolutionel
de taux 1/3, la classe B par un code convolutionnel de taux 1/2 et on ne protge pas
les bits de classe C. On a ainsi 3 canaux de transport diffrents mais qui sont utiliss
simultanment. Les 3 canaux ont le mme TTI.
2.6.3. Variation dynamique des combinaisons de format de transport
Un canal de transport composite est l'quivalent de plusieurs canaux de transport

multiplexs. Sur chaque canal de transport, il y a possibilit de faire varier les
paramtres dynamiques (tailles de blocs de transport et nombre de blocs). Soient n et
p respectivement le nombre de canaux de transport et le nombre de valeurs de

paramtres dynamiques. En considrant que tous les canaux ont le mme TTI, il y a
p" combinaisons possibles. Pour viter une signalisation trop gourmande, seul un
nombre restreint de combinaisons est autoris. Ces combinaisons sont indiques lors
de rtablissement du support radio (radio bearer) et numrotes. Le TFCI,
Transport Format Combination Indicator, permet d'indiquer la combinaison utilise
parmi celles autorises.
Si l'on considre les canaux de transport dfinis pour le codeur AMR. On a un

canal composite form de 3 canaux en parallle (voir tableau de la figure 2.22). Sur
les canaux 1 et 2, il y huit tailles de blocs possible, sur le canal 3, il y a en a trois.
Au lieu des 8 x 8 x 3 = 192 combinaisons possibles, seules 8 sont autorises (voir
tableau de la figure 2.23).
DCH 1 DCH 2 DCH 3

Numro du Taille du Numro du Taille du Numro du Taille du
format de bloc de format de bloc de format de bloc de
transport transport transport transport transport transport
1 81 1 103 1 60
2 65 2 99 2 40
3 75 3 84 3 0
4 61 4 87
5 58 5 76
6 55 6 63
7 49 7 54
8 42 8 53
paramtres statiques paramtres statiques paramtres statiques

pour DCH 1 pour DCH 2 pour DCH 3
CRC 8 CRC 0 CRC 0
Codage Convoi. Codage Convoi. Codage taux 1
1/3 1/2
TTI 20 ms TTI 20 ms TTI 20 ms
Figure 2.22. Exemple de formats de transport {pour la voix AMR)

Valeur TFCI Numro de Format Numro de Format Numro de Format

sur DCH 1 sur DCH 2 sur DCH 3
1 1 1 1
2 2 2 2
3 3 3 3
4 4 4 3
5 5 5 3
6 6 6 3
7 7 7 3
8 8 8 3
Figure 2.23. Exemple de combinaisons de formats de transport et de dfinition

de TFCI (pour la voix AMR)
2.6.4. Canaux de transport
Les canaux physiques sont dfinis comme pouvant transporter des donnes sans
aucune protection. Les canaux de transport permettent le transport de donnes avec
un certain degr de protection contre les erreurs. Plus gnralement un canal de
transport est li la manire dont les donnes sont transmises : diffuses sur toute la
cellule, transmises un utilisateur particulier, transmises en association avec un
mcanisme d'conomie d'nergie, etc.
Les recommandations dfinissent deux types de canaux de transport : les canaux

de transport ddis qui sont affects un terminal particulier et les canaux de
transports communs que tous les mobiles d'une cellule peuvent utiliser.
Il y a un seul type de canal ddi : le DCH (Dedicated Channel). Un DCH utilise

ncessairement un DPDCH (Dedicated Physical Data Channel) mais on peut
multiplexer dynamiquement plusieurs DCH sur un mme DPDCH grce la notion
de combinaison de formats de transport.
Les canaux de transports communs sont plus divers mais on a souvent une
correspondance simple avec chaque canal physique :
- l e canal BCH (Broadcast Channel) est un canal descendant dbit fixe et
relativement faible utilisant le P-CCPCH (Primary Common Control Physical
Channel) ;
- le canal FACH (Forward Access Channel) est un canal descendant diffus sur
toute la cellule en utilisant le canal physique S-CCPCH (Secondary Common
Control Physical Channel ;
- le canal PCH (Paging Channel) est un canal descendant utilisant le S-CCPCH

comme le FACH mais il est associ au mcanisme d'conomie d'nergie disponible
grce au PICH (Paging Indicator Channel) ;
- le canal RACH (Random Access Channel) est un canal montant utilisant le
PRACH;
- le canal DSCH (Downlink Shared Channel) est un canal descendant qui repose
sur le PDSCH (Physical Downlink Shared Channel).
Le tableau de la figure 2.24 synthtise les diffrents canaux de transport.
Canal Nom Sens Canal physique Remarques

BCH Broadcast channel 1 Primary Common Control Diffusion des
Physical Channel informations systme,
(P-CCPCH) dbit faible
FACH Forward access i Secondary Adresse mobile
channel Common explicite inclure
PCH Paging channel 1 Control Phvsical Channel Systmes d'conomie
(S-CCPCH) d'nergie
DSCH Downlink shared i Physical Downlink Donnes en mode
channel Shared Channel paquet (ncessite un
(PDSCH) DCH)
RACH Random access Physical Random Access Donnes limites (ou
channel Channel (PRACH) signalisation)
DCH Dedicated channel u Dedicated Physical Dbit variable
Channel (DPCH) chaque TTI
Adresse MS implicite
Figure 2.24. Canaux de transport et correspondance avec les canaux physiques
2.7. Couche M A C
2.7.1. Fonctions de la couche MAC
La couche MAC (Mdium Access Control) offre des procdures de contrle

d'accs des services de donnes la couche physique par l'intermdiaire des canaux
de transport. La couche MAC multiplexe les canaux logiques sur les canaux
physiques et inversement, grce une table de correspondance. La couche MAC
doit galement ngocier les paramtres de QoS en grant les contentions entre les
demandes de services en tablissant des priorits entre les accs. Les fonctions
principales de la couche MAC sont les suivantes :
- slection du format de transport correspondant chaque canal de transport en
fonction du dbit instantan et des indications de la couche RRC ;
-gestion des priorits entre flux de donnes pour chaque mobile. Lors de la
slection entre plusieurs formats de transport, la couche MAC dtermine les
priorits entre flux de donnes vhiculs sur les canaux de transport correspondants.
Ces priorits sont par exemple bases sur les attributs des services des Bearer Radio,
de l'tat du buffer RLC et les indications de puissance de la couche physique. La
gestion de la priorit est ralise en slectionnant le format de transport pour lequel
les donnes priorit la plus leve sont transportes sur les canaux physiques
haut dbit ;
-gestion dynamique des priorits entre usagers afin d'utiliser les ressources
spectrales efficacement pour le transfert de donnes sporadiques. La couche MAC
gre les priorits sur des canaux de transport communs et partags. Pour les canaux
ddis, l'quivalent de la fonction de priorit est implicitement incluse comme partie
de la fonction de reconfiguration de la sous-couche RRC ;
- organisation des messages de diffusion (broadcast), de paging et de notification ;
- identification des mobiles (UE) sur les canaux communs (voir paragraphe 2.7.2) ;
- adaptation entre les canaux logiques et les canaux de transport ;
-multiplexage et dmultiplexage des PDU en provenance ou mis vers les
couches suprieures vers ou en provenance de la couche physique sur les canaux de
transport communs ainsi que sur les canaux de transport ddis. La couche MAC
supporte le multiplexage des canaux de transport communs, fonction que la couche
physique ne supporte pas. Cette fonction est active quand plusieurs services de
couches suprieures (par exemple RLC) utilisent sur le mme canal de transport.
L'indicateur correspondant est inclut dans l'information de contrle MAC ;
- commutation dynamique de canal de transport. La couche MAC commute les
flux de donnes entre les canaux de transport communs et ddis sur la base des
indications de la couche RRC ;
- chiffrement : cette fonction est ralise par la couche MAC pour le mode RLC
transparent ;
- supervision du volume de trafic. La couche MAC est charge de mesurer le
volume de trafic transport sur les canaux logiques et de reporter ces mesures la
couche RRC. Grce cette information, la couche RRC slectionne les canaux de
transport associs chaque flux de donnes.
La figure 2.25 indique les relations entre la couche MAC et la couche RRC pour
assurer les fonctions et changes prciss plus haut. En particulier, grce ces
changes, la couche MAC assure la gestion de la ressource radio sur le court terme
en fonction des indications gnrales de la couche RRC telles que le choix du format
de transport parmi les formats de transport possibles et ce, en fonction des donnes
de la source, de la charge de la cellule.
Figure 2.25. Relations entre couches MAC, RRC et physique.
2.7.2. Canaux logiques
L'entit de niveau suprieur au niveau MAC (c'est--dire RLC) accde cette

dernire par l'intermdiaire de canaux logiques. Les canaux logiques correspondent
aux diffrents types d'information vhiculs. On fait donc la diffrence ce niveau
entre le contrle (dans le plan C) et les donnes usager (dans le plan U).
Les canaux logiques peuvent tre ddis, c'est--dire que les donnes sont
changs entre le rseau et un mobile particulier, ou bien communes. Dans ce cas,
tout mobile de la cellule peut, soit lire les donnes, soit en envoyer vers le rseau.
Les canaux logiques de contrles sont les suivants :

- le canal BCCH (Broadcast Control Channel) est utilis pour diffuser les
informations de contrle et particulirement le paramtrage de la cellule et du rseau
(voir section 2.9) ;
- le canal PCCH (Paging Control Channel) sert l'envoi des messages de
paging ;
- l e canal CCCH (Common Control Channel) est principalement utilis pour
l'change de messages de contrle entre un mobile et le rseau avant l'tablissement
d'un canal logique ddi ;
- le canal DCCH (Dedicated Control Channel) sert changer les informations

de contrles sur les connexions actives, il est utilis pour l'change de la
signalisation de niveau suprieure (RRC, MM, CC,...).
Les canaux logiques de donnes sont les suivants :

- le canal DTCH (Dedicated Trajfic Channel) permet l'change des donnes
usagers (voix, donnes, images, visiophonie,...) entre un mobile et le rseau ;
- le canal CTCH (Common Trajfic Channel) est un canal descendant qui permet
au rseau de diffuser des donnes. Il peut s'agir par exemple d'informations
routires, mtorologiques, de publicit, etc.
Pour la plupart des canaux, la correspondance entre canal logique et canal de

transport est simple et naturelle : le BCCH est toujours transport par le BCH, le
PCCH par le PCH, etc. La distinction entre les deux concepts peut paratre
artificielle. En revanche, elle a un intrt vident dans le cas des canaux ddis en
termes de gestion de ressources. En effet un canal DTCH peut tre support soit par
un canal de transport DCH, soit par un canal DSCH, soit par un couple FACH-
RACH. Dans le premier cas (utilisation du DCH), cela signifie qu'on fonctionne en
mode circuit : une ressource est alloue pendant toute la connexion et toutes les
donnes sont transmises sur cette ressource. Il est inutile au niveau MAC d'indiquer
l'adresse du mobile.
Si le DTCH est transport par le couple FACH-RACH, cela signifie qu'aucun

code n'est rserv spcifiquement un mobile : on retrouve donc le mode paquet o
la ressource n'est utilise que lorsqu'il y a transmission effective de donnes.
Plusieurs mobiles sont susceptibles d'couter le FACH et il faut que seul le mobile
auquel l'information est destine en tienne compte. Il est ncessaire d'indiquer un
identifiant du mobile dans les donnes transmises (dans le PDU MAC). Plutt que
d'utiliser l'identit complte du mobile (l'IMSI du mobile prend typiquement
8 octets), on utilise un identifiant plus court appel C-RNTI (Cell Radio Network
Temporary Identifier) et cod sur 16 bits. Dans certains cas (suite un changement
de cellule), le C-RNTI qui est attribu au sein d'une cellule ne permet pas
d'identifier sans ambigut le mobile. On utilise alors une identit plus longue sur
32 bits appel U-RNTI (UTRAN Radio Network Temporary Identity).
2.7.3. Format des PDU de niveau MAC
Une MAC PDU comprend un en-tte optionnel et une unit de donne de service
(MAC SDU, MAC Service Data Unit) de tailles variables. Le contenu et la taille de
l'en-tte MAC dpend du type de canal logique. Dans certains cas, aucun paramtre
de l'en-tte MAC n'est ncessaire, c'est le cas pour un canal logique ddi
transport par un canal de transport ddi DCH (exemple du paragraphe 2.8.1). La
taille des MAC SDU dpend quant elle de la taille de la RLC-PDU, qui est dfinie
pendant la procdure d'initialisation de la liaison.
Entte MAC MAC SDU

<
UE-ld
TCTF UE-ld C/T MAC SDU
Type
Figure 2.26. Format de MAC PDU
La MAC PDU comprend les champs suivants :

- T C T F (Target Channel Type Field) : indicateur identifiant la classe de canal
logique utilis sur les canaux de transport FACH et RACH, c'est--dire
l'information sur le transport du BCCH, CCCH, CTCH ou de canal logique ddi ;
- UE-ld : lorsqu'on utilise un canal de transport commun comme support d'un
canal logique ddi, le champ UE-ld permet d'identifier le mobile concern par le
MAC-PDU (destinataire ou expditeur). L'identit peut tre soit un U-RNTI
(UTRAN Radio Network Temporary Identity), soit un C-RNTI (Cell Radio Network
Temporary Identity ;
- UE-ld Type : dtermine si l'UE-Id est un U-RNTI ou un C-RNTI ;
- Champ C/T : identifie le canal logique quand plusieurs canaux logiques sont
transports sur le mme canal de transport. Il est galement utilis pour identifier le
type de canal logique sur les canaux de transport ddis et sur les canaux FACH et
RACH quand ils sont utiliss pour la transmission de donnes usager. La taille du
champ C/T est fixe 4 bits pour les canaux de transport communs et ddis.
2.7.4. Mode circuit et mode paquet
La richesse des canaux radio de l'UMTS permet d'envisager un fonctionnement

en mode circuit et en mode paquet selon diffrentes variantes. Le mode circuit
consiste, de faon classique, allouer un canal physique ddi DPCH pendant toute
la dure d'une communication vocale ou d'une session de donnes.
Le mode paquet peut tre ralis de diverses faons :

- l e rseau alloue un canal physique ddi au mobile seulement lorsqu'il doit
transmettre ou recevoir des donnes, cela n'est envisageable que si les donnes sont
relativement longues car le mcanisme d'allocation est relativement lourd ;
- le rseau alloue un canal physique ddi bas dbit pendant toute la dure de la
session pour contrler la session et utilise le canal ddi DSCH pour transmettre les
donnes au mobile, ce mcanisme est intressant si les transmissions descendantes
sont plus importantes que les transmissions montantes ;
- le rseau utilise le FACH pour les transmissions descendantes et le mobile
utilise le RACH pour les transmissions montantes, les dbits sont limits sur ces
canaux et ce mode est adapt aux transmissions sporadiques de donnes courtes.
Chaque solution peut tre module. Dans la plupart des applications, les
protocoles de niveau suprieur entranent l'change de blocs avec un certain dlai
entre les blocs. On peut donc moduler la premire solution avec une temporisation
qui maintient le canal physique ddi pendant un certain dlai d'inactivit aprs une
transmission. Cette grande souplesse de l'UMTS a comme contrepartie une
complexit pour paramtrer le fonctionnement.
La caractristique commune une session en mode paquet et une

communication en mode circuit est que le mobile est connu du rseau UTRAN. Une
connexion RRC est maintenue entre le mobile et le RNC (voir paragraphe 6.6.3).
2.8. Synthse sur les diffrents canaux de l'UMTS et exemples
2.8.1. Exemple de canaux de donnes
Les nombreux paramtres dfinissant les canaux de transport permettent

d'envisager sur l'interface radio une grande varit de dbits. Dans le tableau 2.27,
on prsente 3 exemples de dbits possibles (12,2 ; 64 et 384 kbit/s) et les principaux
paramtres associs. Le mode utilis est de type circuit. Les donnes utilisateur sont
transportes par le canal logique DTCH ; la signalisation associe pour maintenir la
liaison radio (transmission de mesures par exemple) est transporte sur un DCCH
dont le dbit est toujours de 2,5 kbit/s. Chaque canal logique est transport par un
canal de transport DCH. Les deux canaux de transport forment un canal de transport
composite. L'ensemble est transport par le canal physique de donnes (DPDCH).
Pour chaque dbit utilisateur, on donne le dbit de donnes du canal DPDCH sur la
voie descendante et sur la voie montante.
On constate que pour un service de 12,2 kbit/s, on utilise un DPDCH offrant un

dbit au niveau physique de 42 kbit/s sur la voie descendante et de 60 kbit/s sur la
voie montante. On note galement que les facteurs d'talement sont diffrents du
fait d'une organisation diffrente de la voie montante et descendante. Le facteur
d'talement est infrieur sur la voie montante car le canal DPCCH prend
entirement la voie en en quadrature (c'est--dire que l'on occupe 50 % du canal
physique). Sur la voie descendante, les c h a m p s de contrle occupent nettement

moins que 50 % du total disponible.
Type de service 12,2 kbit/s 64 kbit/s 384 kbit/s

(sur DTCH)
canaux logiques DTCH DCCH DTCH DCCH DTCH DCCH
Taille d'un bloc de 244 100 1280 100 3840 100
transport
TTI 20 ms 40 m s 20 ms 40 ms 10 ms 40 ms
CRC 16 12 16 12 16 12
Codage Codage Codage Turbo Codage Turbo Codage
convolutif convolutif Code convolutif Code convolutif
Taux de codage 1/3 1/3 1/3 1/3 1/3 1/3
voie DPDCH 42 kbit/s 210 kbit/s 912 kbit/s
descendante SF 128 32 8
voie DPDCH 60 kbit/s 240 kbit/s 960 kbit/s
montante SF 64 16 4
Figure 2.27. Principaux paramtres radios pour diffrents types de service
Figure 2.28. Organisation du transport pour un circuit 64 kbit/s sur la voie descendante,
source [25.101]
Figure 2.29. Organisation du transport pour un circuit 64 kbit/s sur la voie montante,
source [25.101]
2.8.2. Canaux physiques, de transport et logiques
La figure 2.30 donne une vue synthtique des principaux canaux en UTRA-
FDD. Mis par quelques diffrences mineures (voir chapitre 3), le tableau
s'applique galement pour UTRA-TDD.
Du point de vue de l'architecture en couches, la diffrenciation entre plan usager

et plan de contrle ne se fait qu'au niveau des canaux logiques : les canaux de
donnes (plan usager) sont reprsents sur fond gris.
2.9. Procdures radio
2.9.1. Mcanisme de recherche de cellule
La procdure de recherche de cellule a lieu lorsque le mobile est l'tat inactif.

Le mobile recherche le code de synchronisation primaire identique pour toutes les
cellules sur le P-SCH (voir paragraphe 2.4.1.1). Il recherche ensuite le pic le plus
important sur le canal SCH secondaire (S-SCH).
Remarque : il n'est pas interdit d'utiliser le DSCH pour transporter du contrle (DCCH) mais
ce n'est pas une utilisation probable.
Figure 2.30. Synthse sur les canaux physiques, de transport et logiques
Quand le code de synchronisation secondaire est dtect, le mobile recherche les

codes d'embrouillage que la station de base utilise parmi les 8 codes du groupe
dfini par le code de synchronisation secondaire (voir figure 2.31). Ds qu'il connat
le code d'embrouillage, il est capable de dcoder tous les canaux. Il peut notamment
dcoder la voie balise, qui est le canal logique BCCH transport dans le BCH
physiquement transmis sur le P-CCPCH. Il peut donc connatre la configuration de
la cellule et du rseau.
2.9.2. Veille sur une cellule
2.9.2.1. Grandeurs mesures par le mobile

Chaque terminal mesure plusieurs indicateurs pour valuer le niveau de
rception et la qualit du signal reu. Les recommandations proposent une panoplie
de mesures possibles et laissent le choix l'oprateur et au constructeur d'utiliser
seulement celles qu'ils considrent comme les plus pertinentes.
Les mesures possibles sont dfinies dans les spcifications [25.215]. Les mesures
de puissance reue permettent, lorsqu'on connat la puissance d'mission, d'estimer
l'attnuation entre la station de base et le mobile et par consquent d'estimer la
distance entre les deux. La mesure du Ec/NO permet d'estimer le niveau
d'interfrence et par consquent de prvoir la qualit de la liaison. Ces mesures se
font gnralement sur le canal pilote car c'est une rfrence stable. Le taux d'erreur
bit permet de mesurer a posteriori la qualit d'une liaison tablie et cette mesure se
fait donc sur un canal de transport. Les recommandations proposent galement
d'utiliser les mesures de diffrences de temps entre des trames venant de 2 stations
de base diffrentes pour acclrer des mcanismes de synchronisation.
Figure 2.31. Fonctionnement gnral du mobile la mise sous tension
Parmi les principales mesures possibles au niveau physique, on peut citer :

- le CPICH RSCP (CPICH Received Signal Power Code) ou niveau de signal
reu sur le canal pilote ;
- le CPICH Ec/NO qui donne le rapport entre l'nergie d'un chip et la densit
spectrale de puissance sur le canal pilote ;
- le UTRA carrier RSSI (.Received Signal Strength Indicator on a UTRA
Carrier) qui donne le niveau total de puissance reue sur une porteuse UTRA ;
- le GSM carrier RSSI {Received Signal Strength Indicator on a GSM Carrier)
qui donne le niveau total de puissance reue sur une porteuse GSM.
On notera qu'un terminal connat sa classe de puissance et la puissance qu'il utilise

en mission. Ce dernier paramtre (UE TX Power) n'est pas vraiment une mesure
mais il est considr comme tel par les recommandations.
2.9.2.2. Critres S et R pour la slection/reslection

Un terminal en veille doit rester l'coute du canal de paging pour dtecter les
appels ventuels. Il doit se positionner sur la station de base qu'il reoit avec la
meilleure qualit et doit vrifier que cette dernire peut lui fournir une qualit de
service suffisante. La norme dfinit plusieurs critres qui permettent au mobile de
slectionner la station de base sur laquelle il se positionne :
- le critre S (pour Selection) permet de vrifier que la station de base est
correctement reue ;
- le critre R (pour Rankirig) permet de classer les stations de base et de choisir
la meilleure station de base parmi les stations de base vrifiant S.
Le critre S est en fait un critre double. Il est vrifi si deux variables sont
positives [25.304] :
Srxlevl > 0 et SqUal > 0
Le critre Srxtevi permet de vrifier que le bilan de liaison est correct, c'est--dire
que l'attnuation n'est pas trop importante pour permettre une rception correcte du
mobile (voie descendante) et de la station de base (voie montante). Il s'exprime
comme suit, avec toutes les grandeurs exprims en chelle logarithmique (dBm pour
les puissances, dB pour les attnuations) :
Srxlevl Qrxlevmeas ~ Qrxlevmin ~ Pcompensation
Dans cette formule, Qrxievmeas dsigne le niveau de signal reu sur le canal pilote
(CPICH RSCP), Qrxievmin dsigne le niveau minimal exig par l'oprateur et diffus
sur le canal BCCH, PCOmpemation dsigne le dficit ventuel de puissance du terminal
dfini comme P compensation = msix(Pcenuie - P mobile, 0) o Pceiiuie est le niveau standard
de puissance indique sur le BCCH et Pmobiie est la puissance maximale du terminal.
La diffrence Qrxlevmeas ~ Qrxlevmin indique la marge en rception. Si le terminal est
moins puissant de P compensation dB que la puissance utiliser dans la cellule, il faut
que la marge soit suprieure de cette valeur pour assurer un bon bilan de la liaison
montante. Cela suppose bien videmment que l'oprateur a bien quilibr sa liaison
la station de base (voir [LAG 00] et [TAB 02]). La formulation du Srx/evi est
identique au critre Cl de GSM (voir le paragraphe 10.1.4 de [LGT 00]).
Le critre Squai permet d'exprimer des exigences de qualit. Il est dfini comme
suit (toutes les grandeurs sont en dB) :
S rxlevl Qqualmeas ~~ Qqualmin
Dans cette formule, Qquaimeas dsigne le rapport Ec/NO mesur sur le canal pilote
(CPICH Ec/NO) et Qquaimin le rapport minimal exig et diffus sur le canal BCCH.
Ce critre permet d'viter un mobile de se caler sur une station de base dont le
niveau de signal serait bon mais qui serait trs fortement interfre et en
consquence incapable d'offrir une qualit de service satisfaisante. Ce critre n'a
pas vraiment d'quivalent dans GSM (on vrifie seulement que le taux d'erreur n'est
pas trop important sur la voie balise).
En gnral, pour un mobile donn, plusieurs cellules vrifient le critre S. Le

mobile utilise le critre R pour les classer et choisit la cellule qui a le plus fort R. Le
mobile tant a priori cal sur une cellule courante dsigne par l'indice s, le critre
R s'crit pour cette cellule :
R.s Qmeas.s Qhyst.s
La variable Qmeas,s dsigne soit le niveau de signal sur le canal pilote (CPICH
RSCP), soit la mesure du Ec/NO sur ce mme canal (CPICH Ec/NO) selon les
indications donnes sur le BCCH. Le paramtre Qhyst,s, diffus sur le BCCH, permet
de favoriser la cellule courante et vite des reslections trop frquentes ; il cre donc
un phnomne d'hystrsis.
Pour une cellule voisine d'indice n, le critre R est dfini comme suit :
R = Q m - Qoffsets n - TEMP_OFFSETn. W{PENALTY_TIMEn - Tn)
o W est la fonction crneau telle que W(x) = 0 pour x < 0 et W(x) = 1 pour x > 0
et Tn est un temporisateur qui est lanc quand une nouvelle cellule est dtecte avec
un niveau suffisant. La variable mesure Qmeas est dfinie comme pour la cellule
courante. Le paramtre QoffsetSi permet de favoriser ou de pnaliser une cellule
voisine par rapport la cellule courante (par exemple on dfavorise une cellule
voisine si elle fait partie d'une zone de localisation diffrente). La valeur
TEMP_OFFSETn permet de dfavoriser une nouvelle cellule pendant les premiers
instants o celle-ci est dtecte. Cela permet d'viter qu'un mobile forte vitesse ne
vienne se positionner sur une micro-cellule. Ce mcanisme adapt aux rseaux
hirarchiques qui combinent micro et macro-cellules est galement prsent dans
GSM (voir explications dtailles dans le paragraphe 10.1.4.2 de [LGT 00]).
Lorsque le mobile est trs proche de la station de base et que la qualit de la

cellule courante est bonne, il est inutile qu'il fasse les mesures pour dterminer le
critre R. En effet, ces mcanismes sont consommateurs d'nergie. Pour minimiser
la consommation des terminaux, les recommandations prvoient la possibilit de
diffuser une valeur de seuil Ssearch sur le BCCH. Lorsque Squaj > Ssearch, le mobile
peut s'abstenir de mesurer les cellules voisines.
2.9.3. Accs (sur PRACH)
Lorsque les mobiles sont en veille, ils accdent au rseau par l'intermdiaire du
canal d'accs alatoire PRACH (.Physical Random Access Channel). Ce canal
constitue une ressource accessible un grand nombre de mobiles de la cellule. Il se
peut que plusieurs mobiles fassent une transmission en mme temps. Ces mobiles
peuvent tre des distances diffrentes de la station de base. S'ils transmettent la
mme puissance, le plus proche est reu par la station de base avec une puissance
trs importante et brouille toutes les autres transmissions. II est donc ncessaire de
trouver un mcanisme pour rendre gales au maximum les probabilits de succs.
De plus, la transmission se fait la mme frquence que les autres transmissions de
la cellule, telles que les canaux ddis. Il faut viter d'utiliser une puissance trop
importante pour l'accs alatoire qui brouillerait l'ensemble des transmissions des
autres mobiles.
L'accs alatoire repose sur les principes suivants :

-choix d'un prambule court parmi 16 possibles, ce qui permet ventuellement
la station de base de dtecter correctement des prambules diffrents mis
simultanment ;
-transmission initiale du prambule faible puissance pour minimiser
l'interfrence sur les transmissions des autres mobiles de la cellule (interfrence
intracellulaire) ;
-rptition du prambule avec une augmentation progressive de la puissance
jusqu' la dtection par la station de base ;
-transmission du message avec la puissance optimale sur une dure de 1 ou 2
trames de 10 ms.
Le terminal choisit alatoirement un prambule parmi les 16 possibles (voir

paragraphe 2.3.2). A partir des mesures faites et de la boucle ouverte de contrle de
puissance, il dtermine une puissance initiale pour le prambule. Il transmet celui-ci
puis coute sur la voie descendante le canal AICH, Acquisition Indicator. Il regarde
si son prambule a t correctement reu ou non. Si ce n'est pas le cas, le mobile
retransmet le prambule en augmentant chaque fois sa puissance d'mission
jusqu' ce que la station de base indique qu'elle reoit le prambule. Lorsque c'est
le cas, le mobile transmet alors le message d'accs en utilisant le PRACH. Suivant
le code d'talement utilis et la dure de transmission, celui-ci peut faire de 9 150
octets utiles.
Le canal AICH est prsent sur tous les slots mais il n'est reprsent que pendant les slots
d'accs que le mobile coute. Le rectangle gris pour l'AICH reprsente une indication
positive de rception du prambule.
Figure 2.32. Principe gnral de transmission sur le RACH
Les diffrents prambules disponibles permettent de minimiser les risques de

collisions [25.213]. Si deux mobiles accdent simultanment au PRACH mais avec
des prambules diffrents et s'ils sont reus par la station de base avec des
puissances voisines, cette dernire pourra diffrencier les demandes d'accs et les
dtecter correctement. Grce la dfinition de slots, l'accs est de type Aloha
synchronis (Slotted Aloha) dont l'efficacit est suprieure l'Aloha simple. Le
principe de slots d'accs permettent galement de dfinir diffrentes classes de
mobiles : certains mobiles se voient autoriss plus de slots d'accs que d'autres et
deviennent ainsi prioritaires.
Le lecteur peut remarquer que le prambule est plus court que le slot d'accs :
4 096 chips correspondent 1 066,67 ps d'mission dans un slot de 1 333,33 ps. Il y
a donc un intervalle de garde de 266,67 ps. En effet, les distances entre les
terminaux et la station de base sont variables et par consquent les dlais de
propagation sont variables. L'intervalle de garde permet d'viter une collision entre
deux transmissions normalement sur des slots diffrents (voir figure 2.33). Un
intervalle de garde de 266,67 ps permet d'envisager des portes maximales de
40 km sans collision. Le mcanisme peut fonctionner pour des distances suprieures

mais l'efficacit est notablement rduite car on se rapproche alors de l'Aloha simple.
slot d'accs
1333,33 us 266,67 (as
0km
Prambule Mobile 2
Figure 2.33. Impact du dlai de propagation dans l'accs alatoire
2.9.4. Gestion du handover
Deux types de handovers sont dfinis dans la norme 3GPP [25.922] : le hard
handover [25.303] et le soft handover. Par dfinition, un soft handover comprend
une phase o le mobile est connect deux stations de base simultanment ou plus ;
cette phase est appele macrodiversit . Le soft handover a lieu lorsqu'un mobile
passe d'une cellule en UTRA-FDD vers une autre cellule en UTRA-FDD avec la
mme porteuse. Le hard handover comprend une phase, ventuellement trs courte,
o le mobile n'est connect aucune station de base. Le hard handover a lieu lors
d'un changement de porteuse et lors d'un passage d'une cellule UTRA-FDD une
cellule d'un autre systme, par exemple GSM.
La dcision de transfert d'un mobile d'une cellule l'autre est prise par le
rseau ; le handover n'existe donc que dans l'tat RRC C E L L D C H o un canal
ddi est allou au mobile et ventuellement dans l'tat CELL FACH o le mobile
qui travaille en mode paquet peut se mettre sous le contrle du rseau (voir
chapitre 6). Dans tous les autres cas, c'est le processus de slection/reslection de
cellule gr par le mobile qui rentre en uvre (voir paragraphe 2.6.2).
Dans ce chapitre, nous nous focalisons sur les aspects du handover lis la
couche physique. L'excution du handover est prsente dans le chapitre 6.
2.9.4.1. Processus de mesures

C'est le RNC qui contrle le processus de mesures. Il dfinit les mesures que le
mobile doit faire, notamment s'il est ncessaire de faire des mesures inter-
frquences et inter-systme (pour permettre par exemple un handover
_
UTRAN->GSM). La principale quantit mesure est le rapport Ec/NO sur les canaux
pilotes des cellules courantes et des cellules voisines.
Le nud B fait galement des mesures en fonction des demandes du RNC. Outre
les mesures radio, on peut trouver par exemple des mesures de volume de trafic.
2.9.4.2. Remonte des mesures

Le mobile effectue les mesures et les remonte vers le rseau. La remonte des
mesures peut tre priodique comme en GSM mais avec une priode paramtrable
de 250 ms 64 secondes. Il est cependant possible de dfinir une remonte des
mesures conditionne par un critre de dclenchement : on parle de remonte sur
vnement. Les recommandations proposent un grand nombre d'vnements : par
exemple, le rapport Ec/NO d'un pilote rentre dans une certaine plage o la quitte, un
pilote d'une cellule hors du soft handover devient meilleur (en Ec/NO) qu'un pilote
d'une cellule active, etc.
2.9.4.3. Dclenchement du handover

Le RNC dcide du handover sur la base des mesures du terminal. La ralisation
du mcanisme de macrodiversit ncessite la gestion deux ensembles de cellules qui
sont grs au niveau du mobile [25.331 ] :
- j e u des cellules actives ou active set : cellules impliques dans une situation de
soft handover (toutes les cellules de cet ensemble sont connectes au mobile
travers une ou plusieurs liaisons) ;
- j e u des cellules voisines ou neighbour set (monitored set) : cellules que le
mobile mesure constamment mais pour lesquelles la valeur de Ec/I0 n'est pas
suffisamment importante pour tre incluses dans la liste active set.
2.9.4.4. Exemple d'algorithme de dclenchement du handover

Les recommandations 3GPP proposent un algorithme de handover [25.922]. Le
principe des premiers algorithmes de soft-handover dvelopps pour IS-95 consistait
intgrer dans les cellules actives toute cellule dont le pilote tait reu au-dessus
d'un certain seuil. Si le seuil est haut, les communications sont coupes pour les
mobiles en bordure de cellules ou l'intrieur d'un btiment car aucune cellule ne
peut rentrer dans Y active set. Si le seuil est bas, les mobiles qui reoivent plusieurs
stations de base avec un fort niveau (car ils sont par exemple en extrieur) sont
connects de multiples stations de base. La consquence est qu'il y a une forte
proportion de mobiles en soft-handover.
Le principe de l'algorithme propos par le 3GPP rside dans la dfinition de

seuils variables : l'ajout d'un pilote se fait par comparaison au meilleur pilote du jeu
courant, le retrait d'un pilote se fait par comparaison au pire ou au meilleur pilote.
Un jeu comporte un nombre maximal de pilotes possibles.
Les paramtres de l'algorithme propos sont :

- valeur de seuil et des diffrents hystrsis ;
- nombre maximal de pilotes actifs ;
- constante de temps avant de modifier le jeu des pilotes actifs.
L'algorithme s'nonce comme suit pour une frquence et pendant au moins AT :

- si EJ0 (pilote candidat) > EJI0 (meilleur pilote du jeu) - Seuil + Hystrsisl A
et le jeu est non plein, alors on ajoute le pilote candidat ;
- si EJh (pilote du jeu) < Ec/I0 (meilleur pilote du jeu) - Seuil - Hystrsisl A et
le jeu est non plein, alors on retire le pilote en question ;
- si EJh (meilleur pilote candidat) > Ec/I0 (pire pilote du jeu) + Hystrsis 1C et
le jeu est plein, alors on sort le pilote le pire et on intgre le meilleur candidat.
La figure 2.34 reprsente un exemple de droulement de handover avec 3

cellules et indique les cellules prsentes dans Y active set.
Figure 2.34. Exemple de droulement d'un soft handover [25.922]
2.9.4.5. Autres cas de handover

Pour assurer une continuit de service, il est ncessaire de permettre le transfert
des mobiles d'un rseau UMTS vers des zones UMTS utilisant d'autres bandes de
frquences, une autre norme (TDD) ou encore vers d'autres systmes couverture
plus tendue tels que le GSM. Ainsi les spcifications UMTS dfinissent le hard
handover qui peut se produire lorsque le mobile doit changer de cellule en
changeant :
- de frquence (FDD inter-frequency hard handover) ;
- de mode (FDD-TDD handover ou TDD-FDD handover) ;
- de systme (3G - 2G handover ou 2G - 3G handover).
Ces diffrents mcanismes dfinis pour assurer la continuit du service entre

diffrents systmes radio ou modes d'accs radio permettent ainsi de prendre en
compte les scnarios de couverture suivants :
- couverture limite dans une couverture tendue fournie par d'autres systmes
radio diffrents ou de modes d'accs radio diffrents ;
-opration de slection la frontire gographique du systme, en cas de
couverture UTRAN tendue d'un ct et d'une couverture tendue d'un autre
systme de l'autre ct ;
-zones de couvertures gographiques colocalises UTRAN et d'un autre
systme radio.
Nous prsentons dans ce paragraphe les principes sur lesquels sont bass ces
diffrents types de handover.
2.9.4.5.1. Mode compress

Afin de permettre le transfert entre cellules utilisant des bandes de frquences
UMTS diffrentes, le mode compress a t dfini (voir figure 2.35). Il permet au
terminal de raliser des mesures sur les autres porteuses tout en communicant sur les
porteuses UTRA-FDD et inversement. Le mode compress permet de crer des
intervalles de temps libres pendant la communication de sorte que le mobile puisse
raliser ses mesures sur les porteuses des rseaux candidats au handover. Pour
maintenir le dbit de transmission constant au niveau de l'utilisateur, le dbit binaire
doit tre augment juste avant et juste aprs l'intervalle de temps tel que la voix
mais pas dans le cas de la navigation Web par exemple, o la transmission sera
retarde pour librer un intervalle de temps. Suite une commande du rseau, le
terminal doit mesurer les cellules d'autres frquences du systme FDD ou TDD ou
d'autres technologies d'accs radio supportes par le terminal (par exemple GSM).
Pour permettre au terminal de raliser ces mesures, le rseau demande au mobile
d'entrer en mode compress. Les fonctionnalits du terminal indiquent sa capacit
raliser des mesures sur d'autres cellules utilisant d'autres frquences et d'autres
systmes.
Dbit 2* R
Dbit R
w
<e
Trame radio Intervalle de temps libr pour les
mesures sur des frquences diffrentes
Figure 2.35. Principe du mode compress
2.9.4.5.2. Handover inter-frquence

Le handover inter-frquence se produit quand le mobile passe d'une zone
couverte par des cellule de mme norme mais utilisant des frquences diffrentes
(cellules micro et cellules macro par exemple).
2.9.4.5.3 Handover inter-mode

Ce type de handover se produit entre deux cellules de modes d'accs radio
diffrents (RAM, Radio Access Mode). Dans le cas o le mobile se trouve dans une
zone couverte par un rseau UMTS fonctionnant en mode TDD, et condition que
le mobile soit bi-mode (FDD-TDD), il pourra, la demande du rseau, raliser des
mesures de niveau de puissance sur les cellules TDD. Ainsi, grce aux mesures de
puissance des bursts mis sur le canal TDD CCPCH (deux fois par trame TDD de
10 ms), l'UTRAN pourra dcider de la cellule cible et du moment du handover.
2.9.4.5.4 Handover inter-systme

Le handover inter-systme se produit entre deux cellules de technologies d'accs
radio diffrentes (RAT, Radio Access Technology). Le cas le plus frquent envisag
est le handover entre UTRA-FDD et GSM/EDGE. Dans ce cas, le mobile pourra,
sur demande du rseau, raliser des mesures sur les canaux communs GSM (et en
particulier les canaux FCCH, Frequency Correction Control Channel, et SCH,
Synchronisation Channel) pendant les priodes libres par activation du mode
compress. Ce sont les couches hautes (rseau et transport) qui envoient les
demandes de handover aux mobiles bi-modes (UMTS-GSM par exemple). Les
informations transmises au mobile pour ce type de handover sont la liste des cellules
mesurer (monitoring set) et ventuellement les paramtres utiliser pour raliser
ces mesures. Le mobile doit dans ce cas raliser des mesures de faon remonter ses
rapports de mesures toutes les 480 ms dans le cas du GSM (ces rapports comportent
les identits des cellules BSIC par exemple).
Dans le cas d'un handover de GSM vers l'UMTS, les paramtres suivants sont
mesurs : Ec/Io sur le canal pilote CPICH (Common Pilot Channel), le RSCP
(Received Signal Code Power) et le RSSI (Received Signal Strength Indicator).
Dans le cas d'un handover d'une cellule UMTS vers une cellule GSM, le niveau
de puissance reue RXLEV_NCELL(/7) pour chaque voie balise GSM n figurant
dans la liste monitoring set.
UTRA-FDD et GSM tant des technologies trs diffrentes, il est difficile de

comparer les rsultats de mesures obtenues sur chaque type de systme. Pour
contourner ce problme, les rsultats de mesures sont compars sparment des
seuils relatifs chaque technologies. Ainsi, des critres spars sont dfinis pour
chaque systme et des paramtres supplmentaires (tels que des offsets) ajustables
par l'oprateur sont dfinis pour permettre un contrle de slection entre les cellules
UTRA-FDD et GSM. Il faut galement inclure les rsultats de mesures ralises sur
les porteuses d'un systme dans les messages d'un systme diffrent (mesures sur
les porteuses GSM remontes sur des messages UMTS par exemple).
2.10. Transmission de donnes haut dbit (HSDPA)
Dans les premires spcifications fonctionnelles de l'UMTS (tablies dans les

annes 90-95), il tait prvu d'offrir un dbit de 2 Mbit/s un usager. Dans la
pratique, le dbit le plus lev est 384 bit/s. Avec un dbit de transmission de
3,84 Mchip/s, offrir 2 Mbit/s un utilisateur ncessite de ddier toutes les ressources
ce dernier et empche, en pratique, tout autre transmission. Pour lever cette
limitation de la premire phase d'UTRA-TDD, une nouvelle technique de
transmission appele HSDPA (High Speed Downlink Packet Access) a t spcifie
partir de la Release 5. Elle est base sur l'utilisation d'une modulation plus
sophistique permettant d'augmenter le dbit de transmission.
Pour augmenter le dbit au niveau applicatif, il ne faut pas se contenter

d'augmenter le dbit sur l'interface radio mais il faut galement rduire le dlai de
transmission. Beaucoup d'applications utilisent en effet le protocole TCP
(Transmission Control Protocol). Celui-ci dispose d'un mcanisme complexe de
fentre d'anticipation qui a pour effet de rduire le dbit lorsque les dlais sont
importants. Les mcanismes de retransmission RLC sont localiss dans le RNC
(voir chapitre 6) dans l'architecture de base de l'UMTS. Les blocs de donnes et
d'acquittement doivent donc traverser l'interface radio et l'interface Iub, ce qui
occasionne un dlai supplmentaire. La philosophie d'HSDPA est donc de transfrer

plusieurs fonctions du RNC vers le nud B. Plus prcisment, on a les principales
volutions suivantes :
-nouveau canal descendant HS-DSCH (High-Speed Downlink Channel) haut
dbit ;
- gestion par le nud B d'un codage et d'une modulation adaptatifs (.Adaptive
Modulation and Coding, AMC) sans contrle de puissance ;
- gestion du squencement des paquets (packet scheduling, PS) par le nud B ;
- technique de retransmission de type ARQ hybride.
Les caractristiques dtailles de chacune de ces modifications sont introduites

ci-aprs.
2.10.1. Canaux logiques et physiques pour le support du HSDPA
HSPDA introduit une volution du DSCH [5, 6] avec la dfinition du canal de

transport HS-DSCH (.High Speed DSCH). Ce canal peut tre utilis pour
l'tablissement d'un contexte PDP unique pour de multiples contextes PDP relatifs
plusieurs usagers.
Comme support du HSDPA, deux canaux physiques ont t introduits :

- le canal HS-PDSCH (High Speed Physical Downlink Shared Channel) permet
le transport du canal HS-DSCH et peut tre partag en temps et en code entre les
usagers connects au nud B ;
- le canal HS-DPCCH (High Speed Dedicated Physical Control Channel) qui est
un canal montant transportant les blocs de signalisation contenant le CQI (Channel
Quality Indicator) utilis par le nud B pour la gestion de la technique AMC.
Outre le canal HS-DSCH utilis pour le transport haut dbit dans le sens
descendant, un second canal logique, le HS-SCCH (High Speed Shared Control
Channel) est introduit pour la fourniture des informations de synchronisation et de
codage au terminal usager. Il permet au mobile d'couter le canal HS-DSCH au
moment et avec le codage fixs par le rseau.
Le tableau de la figure 2.36 reprend les principales diffrences entre les canaux
DSCH et HS-DSCH. Nous prcisons dans la suite de ce paragraphe le
fonctionnement des diffrents mcanismes sur lesquels se base le support HS-
DSCH.
Fonction DSCH HS-DSCH

Facteur d'talement variable (VSF) Oui (4-256) Non (16)
Contrle de puissance rapide Oui Non
Codage et modulation adaptative (AMC) Non Oui
ARQ rapide (HARQ) Non Oui
Multi-code Oui Oui
Intervalle de transmission 10 ou 20 ms 2 ms
Emplacement des fonctions MAC RNC Nud B
Figure 2.36. Principales caractristiques du HS-DSCH par rapport au DSCH
2.10.2. Codage et modulation adaptatifs (AMC)
Les deux fonctions de base de la technique CDMA ont t dsactives dans le

HS-DSCH : facteur d'talement variable et contrle de puissance rapide. Elles ont
t remplaces par un codage et une modulation adaptative (AMC). Bien que
conduisant une efficacit spectrale plus faible, la dsactivation du contrle de
puissance permet de s'affranchir des en-ttes lies ce mcanisme mais ncessite
une adaptation aux conditions de propagation (ce qui est fait grce au codage et la
modulation adaptative). Ainsi, quand les conditions de propagation sont favorables,
les dbits atteints peuvent tre trs levs. D'autre part, la technique AMC permet
l'UE de dterminer la meilleure modulation et le meilleur schma de codage dans
des conditions de propagation donnes, et ce afin de maximiser le dbit de
transmission. L'adaptation se fait chaque TTI (Transmit Time Interval). Pour
amliorer la rapidit d'adaptation de lien et l'efficacit de l'AMC, la dure
d'entrelacement de 10 ou 20 ms a t rduite 2 ms. De plus, si on gardait un TTI
de 10 ms, un dbit de 2 Mbit/s conduirait un bloc de transport de 2 500 octets qui
est une taille suprieure un paquet IP typique ; il faudrait alors attendre plusieurs
paquets pour remplir un bloc et on augmenterait ainsi le dlai de transmission
moyen d'un paquet IP.
Pour atteindre ces hauts dbits, le HSDPA introduit la modulation 16QAM, qui
s'ajoute au schma QPSK. La modulation QAM (Quadrature Amplitude
Modulation) consiste moduler l'amplitude la voie en phase et en quadrature. En 16
QAM, on utilise 2 valeurs absolues d'amplitude. Ces deux niveaux permettent
d'obtenir en fait 4 niveaux d'amplitude : 2 positifs et 2 ngatifs (ce qui peut tre
aussi vu comme un changement de phase de 180). On obtient donc une
constellation de 16 points (voir figure 2.37), d'o la dnomination 16QAM. Cela
permet de transmettre 4 bits par symbole au lieu de 2 en QPSK.
Figure 2.37. Constellation de la modulation 16 QAM
La combinaison de la modulation 16QAM et d'un taux de codage % permet

de cette faon d'obtenir des dbits pics de 712 kbit/s par code (avec un facteur
d'talement SF = 16). Une meilleure robustesse est obtenue avec le schma de
modulation QPSK et un taux de codage VA (au lieu de %) mais le dbit chute alors
119 kbit/s par code. Cinq types de combinaison du codage et de la modulation
(appeles TFRC, Transport Format and Resource Combination) sont dfinis pour
le canal HS-DSCH. Dans de bonnes conditions de propagation radio, un
utilisateur peut recevoir jusqu' 15 codes en parallle, ce qui permet d'atteindre
des dbits maximaux de 10,8 Mbit/s, dbit maximal support en HSDPA (voir
figure 2.38).
TFRC Modulation Taux de codage Dbit binaire Dbit binaire Dbit binaire
(1 code) (5 codes) (15 codes)
1 QPSK % 119 kbit/s 0,6 Mbit/s 1,8 Mbit/s
2 QPSK '/2 237 kbit/s 1,2 Mbit/s 3,6 Mbit/s
3 QPSK 3
/4 356 kbit/s 1,8 Mbit/s 5,3 Mbit/s
4 16 QAM Vi 477 kbit/s 2,4 Mbit/s 7,2 Mbit/s
5 16yQAM VA 712 kbit/s 3,6 Mbit/s 10,8 Mbit/s
Figure 2.38. Exemple de combinaison de formats de transport et de ressources

correspondant aux dbits maximum au niveau 1
La mise en uvre de l'AMC est la suivante : le nud B supervise la qualit du

lien radio descendant en mesurant la puissance mise sur le lien DCH associ
descendant. Le mobile transmet rgulirement des indicateurs de qualit (CQ1) sur
le canal montant HS-DPCCH. Le CQI contient le TFRC et le numro de multi-code
que peut supporter le mobile.
2.10.3. Technique HARQ
UHybrid ARQ (HARQ) mise en uvre permet de minimiser la quantit

d'information retransmise grce aux deux techniques suivantes combines l'ARQ :
le chase combining (CC) et Y incrmental redundancy (IR).
Dans la technique CC, lorsque l'UE reoit un paquet contenant des erreurs, elle
le garde en mmoire et demande au nud B de le retransmettre. Dans le cas o le
paquet retransmis contient galement des erreurs, les deux paquets sont combins en
les pondrant par le rapport signal bruit avant dcodage.
Avec la technique IR, le paquet retransmis utilisera un codage plus robuste que
le paquet prcdent afin d'augmenter la probabilit de bonne rception. Ainsi, lors
de la retransmission, seule une partie de l'information est renvoye de faon
complter les informations dj reues par combinaison (CC).
La mthode d'ARQ de base utilise dans HARQ est de type Stop-and-Wait. Pour
rduire les dlais d'attente des acquittements, N processus Stop-and-Wait en
parallle peuvent tre activs, permettant ainsi aux diffrents processus de
transmettre dans des TTI diffrents. La valeur de N peut tre au maximum de 8. En
pratique, le dlai entre la premire mission et la premire retransmission devrait
tre de l'ordre de 8 12 ms. Le contrle du mcanisme d'ARQ est gr par la
couche MAC. Ainsi, le stockage des blocs non acquitts et l'organisation de la
transmission des retransmissions suivantes n'impliquent pas le RNC. La
signalisation Iub est vite et le dlai de retransmission dans HSDPA est plus faible
que dans le cas des retransmissions par RNC et introduit une gigue plus faible.
Avec une efficacit spectrale optimale et un mcanisme de transmission de type

round-robin, les taux d'erreur bloc (BLER, Block Error Rate) pour des usagers
proches de la bordure de la cellule seront d'environ 30 60 %, alors que pour des
usagers proches du nud B, le BLER sera de 10 20 % la premire mission.
2.10.4. Fast cell site selection (FCSS)
Quand le mobile se dplace dans le rseau, il tablit Y active set pour la gestion
du soft handover. Dans le mcanisme FCSS, le mobile utilise Y active set et
slectionne la cellule pour laquelle les conditions de propagation sont les meilleures.
Grce ce processus, des dbits plus importants peuvent tre atteints par utilisation
du meilleur nud B chaque transmission.
2.10.5. Squencement des paquets
En HSDPA, le nud B est charg de deux nouvelles fonctionnalits : le packet

scheduling (PS), ou squencement des paquets permettant de rduire les dlais de
transmission, et l'adaptation du taux de codage et de modulation.
En fonction de la priorit des paquets et de la disponibilit des ressources, le

nud B squence les paquets transmettre vers les usagers sur le HS-DSCH. Ainsi,
deux utilisateurs peuvent tre multiplexs en temps et/ou en code pour utiliser de
faon plus efficace les ressources disponibles (les UE doivent tre capables de grer
plusieurs classes). Avant de transmettre les donnes sur le HS-DSCH, le nud B
envoie un message de signalisation aux usagers actifs travers le canal HS-SCCH
indiquant le TFRC utilis, l'ensemble de multi-codes ainsi que le contrle du
processus ARQ. Il est transmis deux slots avant le HS-DSCH.
2.10.6. Contraintes au niveau du nud B et des terminaux
Sans HSDPA, les nuds B sont gres par le RNC qui assure le squencement,
les paramtres de codage et la retransmission vers les mobiles. Pour le support du
HSDPA, ces paramtres doivent tre dtermins instantanment en fonction des
conditions de transmission radio (values par les mesures remontes par les
mobiles). Ainsi, pour que les dcisions d'adaptation indiques plus haut soient
ralises rapidement, il est impratif que ces processus soient excuts au niveau des
nodes B et non des RNC. Les fonctions RLC et MAC sont toujours ralises par le
RNC pour les services non-HSDPA. De la mme faon, les handovers doivent tre
assurs par le RNC pour grer la perte de donnes ainsi que la fonction FCSS.
L'introduction du HSDPA ncessite l'introduction de nouveaux types de

terminaux. Cinq principaux paramtres sont utiliss pour dfinir les fonctionnalits
de la couche physique du terminal :
- n o m b r e maximal de multi-codes HS-DSCH que le terminal peut recevoir
simultanment. Au moins 5 multi-codes doivent pouvoir tre supports pour un
fonctionnement multi-code efficace ;
- intervalle inter-TTI minimal (distance entre le dbut du TTI et le dbut du TTI
suivant) : par exemple, si l'intervalle est de 2 ms, cela signifie que le terminal peut
recevoir des paquets HS-DSCH chaque 2 ms ;
-nombre maximal de bits de canal de transport HS-DSCH pouvant tre reus
dans un seul TTI ;
- capacit du terminal supporter la modulation 16QAM.
2.11. Conclusion
Avant d'atteindre sa ple capacity, un systme W C D M A peut tre limit soit par
m a n q u e de puissance, soit par m a n q u e de codes. L ' u n des avantages m a j e u r s du
H S D P A est son c o m p r o m i s entre puissance et code pour s ' a d a p t e r l'tat de la
cellule. Face au dploiement d'alternatives aux rseaux U M T S avec le Wi-Fi,
HSDPA permet l ' U M T S d ' o f f r i r des dbits similaires avec une meilleure
couverture gographique ainsi q u ' u n niveau de scurit plus important.
2.12. Rfrences
[22.129] 3GPP TS 22.129, Handover requirements between UTRAN and GERAN or other
radio systems .
[25.101] 3GPP TS 25.101, User Equipment (UE) radio transmission and reception (FDD)
[25.104] 3GPP TS 25.104, UTRA (BS) FDD; Radio transmission and reception
[25.133] 3GPP TS 25.133, Requirements for support of radio resource management
(FDD) .
[25.211] 3GPP TS 25.211, Technical Spcification; Physical Channels and Mapping of
Transport Channels onto Physical Channels (FDD) .
[25.213] 3GPP TS 25.213, Spreading and modulation (FDD) .
[25.214] 3GPP TS 25.214, Technical Spcification Group Radio Access Network; Physical
layer procdure (FDD) , Release 5, 2002.
[25.215] 3GPP TS 25. 215, Physical layer; Measurements (FDD) .
[25.303] 3GPP TS 25.303, Interlayer procdures in Connected Mode
[25.304] 3GPP TS 25.304, UE Procdures in Idle Mode and Procdures for Cell Reselection
in Connected Mode .
[25.308] 3GPP TS 25.308, Technical Spcification; High Speed Downlink Packet Access
(HSPDA), Overall Description; Stage 2 .
[25.321] 3GPP TS 25.321, Technical Spcification; Physical Channels and Mapping of
Transport Channels onto Physical Channels (FDD) .
[25.331] 3GPP TS 25.331, Technical Spcification, RRC Protocol Spcification .
[25.855] 3G TS 25.855, Technical Spcification; High Speed Downlink Packet Access:
Overall UTRAN Description .
[25.922] 3GPP TR 25.922, Technical Spcification; Radio Resource Management
Stratgies .
[LAG 00] LAGRANGE X (coordinateur), Les rseaux radiomobiles, collection IC2, Herms
Science, 2000.
L' interface radio UTRA-FDD 103
[ L G T 0 0 ] LAGRANGE X , GODLEWSKI P , TABBANE S, Rseaux GSM, Herms Science, 2000.
[ P R O 0 1 ] PROAKIS J . G.,Digital Communications, ME Graw Hill, 2001.
[TAB 02] Sami Tabbane, Ingnierie des rseaux cellulaires,

Herms Science - Lavoisier, 2 0 0 2 .
Chapitre 3
Le mode UTRA-TDD et ses performances
En Europe, le mode UTRA-FDD est le premier mode dploy et le plus rpandu.

Cependant le mode UTRA-TDD (Universal Terres trial Radio Access with Time
Division Duplex), de par la spcificit du duplexage, est considr avec intrt. Dans
ce chapitre, nous dcrivons les principes fondamentaux de l'UTRA-TDD et
justifions sur un plan thorique l'avantage qu'il procure en termes de capacit. Nous
introduisons les principaux lments de la couche physique et tudions en dtail les
techniques spcifiques au mode TDD que sont l'estimation de canal multi-
utilisateurs et la dtection conjointe. Sont galement abordes les spcificits du
mode TDD quant l'allocation de ressources et la synchronisation du rseau.
Les couches suprieures tant communes l'UTRA-TDD et l'UTRA-FDD,

elles ne sont pas traites dans ce chapitre et on peut se rfrer aux informations du
chapitre 2 sur les couches MAC, RLC, les canaux de transport et les canaux
logiques.
3.1. Philosophie de l'UMTS-TDD
Les modes TDD (Time Division Duplex) utilisent un duplex temporel permettant
le partage flexible d'une mme bande de frquence entre les ressources de la voie
montante (Uplink) et celles de la voie descendante (.Downlink) et associent l'accs
multiple en partage de code (CDMA, Code Division Multiple Access) une
composante de partage en temps (TDMA, Time Division Multiple Access).
Chapitre rdig par Bruno JECHOUX.

Chaque porteuse est partage en un nombre fixe d'intervalles de temps (IT) ou

Time Slots qui sont rpartis, symtriquement ou non, de manire flexible, entre voie
montante et voie descendante. Plusieurs transmissions sont possibles simultanment
sur le mme intervalle de temps grce au CDMA : les codes d'talement utiliss
sont orthogonaux en voie descendante comme en voie montante. Un canal physique
correspond donc 1 code d'talement dans un intervalle de temps donn une
frquence donne.
Figure 3.1. Accs multiple en TDD et FDD
On peut noter les particularits suivantes pour le mode TDD de l'UMTS :

- le facteur d'talement (SF, Spreading Factor) est limit 16 ;
- j u s q u ' 16 codes peuvent simultanment tre utiliss dans un mme IT par un
ou plusieurs utilisateurs (dans un cas favorable en terme d'interfrence, en ralit
moins, jusqu' 10 ou 12) ;
- les codes de scrambling sont caractristiques de la cellule et ont une longueur 16 ;
- la trame radio a une dure de 10 ms ;
- e n voie descendante, l'obtention des hauts dbits est faite par empilage de
codes (multicode avec SF = 16) ;
Le mode UTRA-TDD et ses performances 107
- en voie montante, elle se fait par une combinaison de multicode et de facteur

d'talement variable (2 codes par utilisateur au maximum et des facteurs
d'talement variant entre 1 et 16).
Ces caractristiques peuvent se justifier par l'tude des problmes classiques des
communications cellulaires en CDMA que sont l'effet Proche-Loin (Near Far
Effect) et l'interfrence extra cellulaire ([PET 95]).
3.1.1. Effet proche-loin
L'effet proche-loin se produit en voie montante lorsque les signaux de diffrents

mobiles sont reus simultanment au niveau de la station de base. Les mobiles
pouvant se trouver des distances diffrentes de la BTS, les puissances reues sont
alors diffrentes. Dans le cas o les signaux ne sont pas strictement orthogonaux, le
signal le plus fort peut dgrader fortement, voire occulter, le plus faible.
Figure 3.2. Effet proche-loin
Dans le cas du TDD, lors de la transmission en voie montante, les diffrents

signaux d'une mme cellule sont synchroniss et orthogonaux. Le canal de
propagation radio trajet multiples et les imperfections de synchronisation brisent
cette orthogonalit qui n'existe donc plus la rception, mais l'emploi d'un
rcepteur dtection conjointe (algorithme de dtection multi-utilisateur linaire)
permet de la restaurer 1 . Par consquent l'interfrence proche-loin est fortement
1. La complexit de mise en uvre de la dtection conjointe impose d'utiliser des codes

courts (limits par consquent 16).
rduite de telle manire que les puissances reues pour les diffrents liens peuvent
tre trs diffrentes sans consquences notables.
En FDD, o les codes sont longs et non orthogonaux (voie montante)

l'interfrence proche loin est combattue par un contrle de puissance rapide qui
permet la station de base de recevoir la mme puissance pour chacun des liens,
indpendamment de la distance de propagation. L'interfrence est alors minimise et
identique pour chacun des liens.
3.1.2. Capacits du canal en UTRA-TDD et en UTRA-FDD
Il est possible en utilisant la formule de Shannon [SHA 48] de comparer les

capacits du canal d'un systme UTRA-TDD et d'un systme UTRA-FDD. On
considre un systme CDMA avec K utilisateurs en voie montante transmettant un
signal dans une bande de frquence de largeur W o la densit spectrale de bruit
AWGN est N0/2 et la densit d'interfrence est IJ2, la capacit d'un utilisateur
recevant une puissance moyenne S dans un canal AWGN est :
C = W\ og. 1 + [3.1]
(N0+l0)fV
Pour un systme utilisant des codes d'talement orthogonaux (cas UMTS-TDD),

l'interfrence est annule et la capacit de l'utilisateur devient :
W log, 1 + [3.2]
N0fVj
qui est gale la capacit thorique du cas mono utilisateur. Cependant dans un
systme rel, l'orthogonalit restaure des codes la rception est imparfaite et il
reste une interfrence rsiduelle ( l - a ) / 0 , o a est la portion d'interfrence
supprime, comprise entre 0 et 1.
C = W\ og, 1 +
(Ar0+(l-a)/0)r
[3.3]
On considre maintenant la voie montante d'un systme UMTS FDD. Les codes
d'talement PN {Pseudo Noise) ne sont pas orthogonaux et un contrle de puissance
est mis en uvre : les signaux des diffrents utilisateurs sont reus avec la mme
puissance moyenne S (correspondant une puissance moyenne par symbole Ssymb

tale sur L chips) la station de base. La capacit d'un utilisateur est :
Ssymb
C = W log 2 1 + = W log 2 1 + .[3.4]

TVo^ + ^ - l ) ^ S
Svmb
N0W + (K-1)
L'utilisation de codes longs permet de rduire l'interfrence jusqu' faire tendre

asymptotiquement la capacit vers :
C = W\ og 2 1 + [3.5]
NQW
lorsque l'interfrence devient ngligeable devant la puissance de bruit (c'est--

dire quand (K- 1 )/L NQW/SSymb).
Les quations [3.2] et [3.5] sont les mmes, ce qui semble montrer que les
capacits des systmes qui emploient des codes orthogonaux et de ceux bass sur les
codes pseudo-alatoires sont quivalentes. Cependant, dans un systme rel, la
longueur L des codes d'talement est limite et le nombre K de mobiles en
communication est grand, on ne se trouve donc en gnral pas dans le cas o
l'interfrence est ngligeable. De plus, le contrle de puissance ne peut galiser
parfaitement les puissances reues des diffrents utilisateurs, ce qui contribue
galement dgrader la capacit.
Ces considrations de capacit supposent implicitement que les interfrences

sont gaussiennes, il s'agit d'une approximation beaucoup plus proche de la ralit
dans le cas de codes PN longs que de codes orthogonaux courts.
L'utilisation soit de codes orthogonaux courts coupls avec un rcepteur

dtection conjointe, soit de codes pseudo alatoires longs avec un contrle de
puissance parfait et un rcepteur mono utilisateur permet en thorie d'atteindre la
capacit du canal mono utilisateur.
Cependant, dans la ralit, la capacit obtenue par ces 2 approches est limite
respectivement par la restauration imparfaite de l'orthogonalit des codes et par
l'interfrence rsiduelle (dpendant du nombres de communications parallles)
couple aux imperfections du contrle de puissance.
3.1.3. Gestion de r interfrence extra-cellulaire
L'interfrence extra-cellulaire est plus forte aux limites de la cellule. En effet

quand un mobile est proche de la frontire de la cellule, il reoit une interfrence
forte des signaux venant des cellules voisines, et lui-mme interfre fortement avec
celles-ci (que ce soit avec les stations de base ou avec les mobiles).
Figure 3.3. Interfrences extra-cellulaire en bordure de cellule
En TDD, cette interfrence est combattue par l'utilisation d'un code

d'embrouillage caractristique de la cellule et par un mcanisme d'allocation. Le
code d'embrouillage (scrambling) est court (longueur 16), ce qui ne fournit pas
toujours une isolation suffisante par rapport aux cellules voisines. Le mcanisme
d'allocation de canal doit tre rapide (Fast DCA) ; il est bas sur des mesures
d'interfrence sur chaque IT, permettant ensuite de dcider des rallocations des
signaux fortement interfrs dans d'autres IT moins interfrs.
3.1.4. Facteur dytalement variable et multicode
En TDD, deux techniques sont a priori disponibles pour l'obtention de dbits

importants, le multicode et la variation du facteur d'talement (codes OVSF).
L'utilisation de facteurs d'talement variables augmente la complexit du rcepteur
par rapport au multicode qui impose par contre des contraintes suprieures sur les
amplificateurs de puissances utiliss pour la transmission.
En effet dans le cas d'une transmission en multicode, le signal a une forte

dynamique avec un rapport puissance crte/puissance moyenne d'autant plus
important que le nombre de codes est grand. Lors de l'amplification par un
amplificateur haute puissance (AHP), les distorsions non linaires de l'AHP
produisent des intermodulations entre les diffrents codes qui constituent des
interfrences supplmentaires dans le systme causant une augmentation du TEB.
Pour limiter ces interfrences, il faut forcer l'AHP fonctionner en zone linaire
en augmentant la marge ( b a c k - o f f ) entre la puissance maximale d'utilisation et la
limite de saturation de l'amplificateur. Malheureusement, cette solution implique un
faible rendement en puissance de l'amplificateur et donc une consommation
d'nergie accrue, ce qui est trs pnalisant pour l'autonomie des batteries de
mobiles.
Pour tenir compte la fois des contraintes de complexit du rcepteur et de

linarit de l'amplificateur dans le mobile :
- le multicode a t limit 2 codes en voie montante et coupl avec l'utilisation
de facteurs d'talement variables ;
- le facteur d'talement variable a t interdit en voie descendante o le
multicode avec facteur d'talement fixe (SF = 16) est utilis.
Un code unique avec facteur d'talement unit est cependant possible en voie
descendante.
3.1.5. Limitations du mode TDD
3.1.5.1. Pnurie de codes orthogonaux

La longueur maximale des codes d'talement et de scrambling est limite 16
chips pour permettre la dtection conjointe. Or le nombre maximal de codes
orthogonaux de longueur N est gal N. Il n'y a donc que 16 codes orthogonaux
utilisables pour l'ensemble du systme TDD, ce qui est videmment insuffisant pour
supporter le nombre de communications simultanes d'un systme commercial.
Cette limitation est dpasse par l'introduction d'une composante TDMA sous la
forme d'une sparation supplmentaire des utilisateurs sur 15 ou 7 intervalles de
temps, le systme devenant TD-CDMA, et par l'utilisation de codes de scrambling
ddis chaque station de base.
3.1.5.2. Interfrence voie montante/voie descendante

Le TDD tant bas sur un duplex temporel, les signaux voie montante et voie
descendante utilisent la mme bande de frquence et peuvent donc interfrer.
Le problme apparat quand 2 mobiles proches ne sont pas dans le mme tat, le
puissant signal mis par celui qui est en voie montante masque alors le faible signal
reu par celui qui est en voie descendante. Le pire cas est celui o les mobiles sont
la limite de couverture d'une cellule car le signal mis par le mobile en voie
montante est alors la puissance maximale afin de compenser les pertes de
propagation.
L'interfrence voie montante/voie descendante peut tre limite par une gestion
adapte de l'allocation des ressources dans les diffrentes cellules ou vite, au prix
d'une perte de flexibilit du systme, en adoptant une rpartition des priodes voie
montante/voie descendante commune toutes les cellules.
Figure 3.4. Interfrences voie montante/voie descendante
3.2. Introduction la norme : TD-CDMA et TD-SCDMA
A l'UMTS-TDD original (3,84 Mchips TDD) est venu s'ajouter une 2e option, le
1,28 Mchips TDD. Ces deux options diffrent par un certain nombre de
caractristiques de leurs couches physiques ([25.221] [25.225]).
3.2.1. Caractristiques d'UTRA-TDD 3,84 Mchips
Les principales caractristiques de l'UTRA-TDD sont donnes dans la deuxime

colonne du tableau 3.1.
Paramtres et fonctions Valeur/Expression Valeur/Expression
Bande passante 3,84 Mchips 1,28 Mchips

QPSK QPSK (8PSK)
Modulation
16QAM (pour H S D P A 2 ) 16QAM (pour HSDPA)
Sparation des canaux 5,0 MHz/Porteuse 1,6 MHz/Porteuse
Trame TDMA 10ms 10ms (divis en 2 sous-trames)
Mthode de Duplex TDD
Acs multiple TD-CDMA
IT par trame 15 7 (par sous-trame)
Dtection multi-utilisateur, Dtection multi utilisateur (option),
Type de rcepteur
Rake Rake
Synchronisation DL et UL (option) DL et UL
Prcision synchro UL 4 chips 1/8 chip
Diversit de transmission, Rseaux
Modes d'antennes Diversit de transmission
d'antennes actives (option)
Boucle ouverte (dlai : 667- Boucle ferme : 0-200 Hz/sec.
Contrle de puissance voie
4 669 ps si 2 SCH par trame, Boucle ouverte: (dlai de 200 ps
montante (UL)
6 6 7 - 9 3 3 8 ps si 1 SCH) 3575 ps)
Contrle de puissance voie Boucle ferme (de 100 Boucle ouverte
descendante(DL) 700 Hz) Boucle ferme/200 Hz (maximum)
- Turbo codes PCCC 8 tats, rendement 1/3
Codage canal - Codes convolutifs rendement 1/3 ou 1/2 longueur de contrainte 9
- sans codage
Entrelacement sur 1,2,4 ou 8 trames
Estimation de canal Midambules (512 ou 256 chips) Midambules (144 chips)
Codes d'embrouillage longueur 16, caractristique de la cellule
Codes d'talement Orthogonaux (OVSF)
Allocation de canaux Dynamique (DCA)
Facteur d'talement (SF) 1,2,4, 8,16
Handover Hard handover
Adaptation dbit UL 1 ou 2 codes (SF = 1 , 2 , 4, 8 ou 16)
Adaptation dbit DL codes multiples (SF = 1 ou 16)
Rpartition UL/DL Flexible Flexible ( long terme)
Rseau Synchronis au niveau trame
Ressource physique 1 frquence, 1 code et 1 IT (allous de manire identique dans les 2
lmentaire sous-trames pour le mode 1,28 Mchips)
Tableau 3.1. Rsum des couches physiques des modes 3,84 Mchips et 1,28 Mchips
2. High Speed Downlink Packet Access : mode optionnel de transmission paquet bas sur un
canal de transport partag associ une procdure d'adaptation de la modulation (QPSK ou
16QAM) et du rendement de codage en fonction des conditions de canal.
3.2.2. Canaux physiques
3.2.2.1. Structure de trame

L'interface UTRA-TDD est base sur une trame de 10 ms, subdivise en 15 IT
configurables en voie montante ou en voie descendante. Un IT dure donc 10/15 ms soit
667 ps. Un minimum de 1 IT par trame doit tre configur en voie descendante pour
supporter les canaux de synchronisation (SCH, Synchronisation Channel), de diffusion
des informations rseaux et de balise (P-CCPCH, Primary-Common Control Physical
CHannel). De mme, au minimum 1 IT par trame doit tre allou la voie montante
pour supporter le canal d'accs alatoire (PRACH, Physical Random Access Channel).
10 ms
Figure 3.5. Structure de la trame
Les IT sont utiliss pour la transmission de bursts forms de 2 blocs de donnes

encadrant une squence d'apprentissage (midambule) utilise pour l'estimation de
canal, suivi d'une priode de garde (PG) destine viter les interfrences entre IT
conscutifs.
10 ms
Codes multiples, midambules multiples Codes multiples, midambule commun
Non tal, non embrouill Etal et embrouill
Figure 3.6. Illustration de la technique d'accs multiple. Les midambules 1, 2 et 3 sont des
versions dcales cycliquement d'une mme squence de base.
Plusieurs bursts peuvent tre transmis dans un mme IT, les blocs de donnes
des diffrents bursts sont alors diffrencis par leurs codes d'talements diffrents.
Suivant les besoins, chaque burst peut contenir un midambule propre 3 (typiquement
en voie montante o il y a autant de canaux radio estimer que d'utilisateurs) ou ils
peuvent partager le mme midambule si une estimation unique est suffisante,
(typiquement en voie descendante) (voir figure 3.6).
3.2.2.2. Structure des bursts

Les bursts sont systmatiquement constitus d'un midambule encadr de
symboles de donnes. Il existe 2 types de burst pour le trafic (figure 3.7) suivant la
longueur du midambule.
Symboles de donnes Midambule Symboles de donnes PG

976 chips 512 chips 976 chips 96
667 ps
w

667 ps
4
Figure 3.7. Structure des bursts de trafic de type 1 (haut) et de type 2 (bas)
Le burst de type 1 a un midambule long permettant d'estimer un plus grand

nombre de coefficients de canal au prix d'un dbit de donnes infrieur au burst de
type 2.

667 ps
4
Figure 3.8. Structure du burst PRACH
Le burst PRACH, utilis uniquement en voie montante pour l'accs alatoire est
identique au burst de type 1 mais avec une priode de garde double pour tenir
compte de la synchronisation imparfaite (voie descendante uniquement) du mobile
au moment de son mission.
3. C'est--dire une version dcale selon un dcalage qui lui est propre du mme code de base
du midambule.
3.2.2.3. Canal de synchronisation SCH

Le canal de synchronisation est compos de 4 codes de longueur 256 chips mis
simultanment avec un retard T0ffSet> choisi parmi 32 valeurs possibles, par rapport au
dbut de l'IT de manire viter les phnomnes de capture : un code primaire de
synchronisation (PSC, Primary Synchronisation Code) commun toute les cellules
et 3 codes secondaires (SSC, Secondary Synchronisation Code) choisis parmi 16 et
moduls en phase par rapport au PSC. Le SCH est toujours mis dans le mme IT
que le canal de diffusion P-CCPCH et peut tre transmis 1 ou 2 fois par trame selon
la configuration du rseau. Le SCH est transmis avec une longueur d'entrelacement
de 2 trames.
Figure 3.9. Structure du burst de synchronisation
La dtermination des SSC et de leurs modulations indique le code de groupe

(icode group), la position de la trame courante dans la priode d'entrelacement et le
ou les emplacements du P-CCPCH dans la trame. Le code de groupe dfinit le jeu
de paramtres de la cellule avec une incertitude de 1 parmi 4. Il reste ensuite
dterminer le jeu de paramtres de la cellule parmi les 4 possibles, c'est--dire
trouver, par corrlation sur le P-CCPCH, le code de base des midambules et le code
d'embrouillage de la cellule. Le lecteur peut constater, en comparant les canaux de
synchronisation du mode FDD et du mode TDD, que les mmes principes sont
utiliss (synchronisation en 2 phases et indication de codes spcifiques la cellule
sur un canal secondaire) mais avec une implmentation diffrente.
La cellule utilise deux jeux de paramtres alterns de trame en trame pour

moyenner l'interfrence inter cellules.
i
3.2.3. Procdures de la couche physique
3.2.3.1. Contrle de puissance

Le contrle de puissance a pour but de limiter le niveau d'interfrence dans le
systme. Il est utilis la fois en voie montante et en voie descendante mais de
faon diffrente.
En voie descendante, la puissance est pilote par le mobile : lors de la

transmission du premier burst en voie descendante, la puissance de transmission de
la station de base est dfinie par le rseau. Elle est ensuite contrle en boucle
ferme : la rception d'un burst en voie descendante, le mobile mesure la
puissance reue et transmet en voie montante une commande d'ajustement de
puissance (TPC, Transmit Power Control). Le symbole TPC est transmis au dbut
du deuxime bloc de donnes du burst (vol de ressource donnes). Cette commande
est ensuite prise en compte par le rseau pour les transmissions suivantes. Le pas
d'ajustement de puissance, fix par le rseau est de 1, 2 ou 3 dB (voir chapitre 4).
La frquence du contrle de puissance dpend donc de l'allocation des IT ; elle

est au minimum de 100 Hz.
En voie montante, le contrle de puissance fonctionne en boucle ouverte, en

exploitant la rciprocit des canaux voie montante et voie descendante
caractristique du mode TDD. Le mobile mesure la puissance reue sur la voie
balise dont la puissance de transmission est diffuse par le rseau, et en dduit la
perte de propagation qu'il utilise alors pour calculer sa puissance de transmission
uplink selon la formule suivante :
[3.6]
o LPCCPCH dsigne la mesure de la perte de propagation sur la voie balise, L0 la

valeur moyenne long terme de cette mesure, IBTS la puissance des interfrences au
niveau du rcepteur de la station de base, a un paramtre de pondration qui
reprsente le niveau de confiance sur la mesure de perte de propagation (par
exemple en fonction du retard entre le IT balise le plus rcent et l'IT montant),
RSBCIBLE le rapport signal/bruit cible fix par le rseau et C un offset constant fix
par le rseau. Toutes les units sont exprims en chelle logarithmique (dBm pour
IBTS et dB pour les autres grandeurs) sauf le coefficient a.
Le dlai entre mesure et commande est compris entre 1 et 7 IT ou 1 et 14 IT

suivant la configuration de la voie balise.
3.2.3.2. Timing Advance

La priode de garde en fin de burst de longueur 96 chips permet l'absence
d'interfrence entre IT conscutifs dans des cellules de rayon infrieur ou gal
3,75 km. Pour des cellules plus grandes, une fonction d'alignement temporel (TA,
Timing Advance) peut tre active de manire aligner temporellement les bursts au
niveau du rcepteur de la station de base. Quand cette fonction est active,
l'UTRAN mesure en permanence l'instant de rception des bursts mis par le
mobile et lui renvoie par signalisation de haut niveau une commande TA
d'ajustement de l'instant d'mission sur 6 bits 4 chips prs.
3.2.4. Caractristiques dy UTRA-TDD 1,28 Mchips
Le mode 1,28 Mchips, connu galement sous le nom de TD-SCDMA (Time

Division Synchronous Code Division Multiple Access) est la deuxime option de
l'UMTS-TDD. Il est conu pour pouvoir supporter les fonctions de formation de
faisceaux rapide (beamforming), le contrle de puissance en boucle ferme et la
synchronisation en voie montante avec une prcision infrieure un chip. Les
caractristiques sont indiques dans la dernire colonne du tableau 3.1 en
correspondance avec celles du mode 3,84 Mchips.
3.2.4.1. Canaux physiques

Comme dans les autres modes de l'UMTS (3,84 Mcps TDD, FDD) la longueur
de la trame est de 10 ms. En revanche elle est divise en 2 sous-trames de structure
identique de 5 ms chacune.
Figure 3.10. Structure de la sous-trame
Il y a au total 7 IT de trafic partager entre voie montante et voie descendante, le

premier est systmatiquement utilis en voie descendante (TsO en figure 3.10) et le
second en voie montante. Dans chaque trame, il y a 2 transitions voie montante/voie

descendante dont la premire situe entre TsO et Tsl contient les pilotes SYNC-DL
et SYNC-UL et la priode de garde ncessaires la synchronisation en voie
descendante et en voie montante des mobiles par rapport au Node B.
3.2.4.2. Structure des bursts

Il existe 3 types de burst incluant 1 type de burst pour le trafic (figure 3.11),
1 burst DwPTS (figure 3.12) et 1 burst UpPTS (figure 3.13).
Figure 3.11. Structure d'un burst de trafic (864 chips)
Le burst de trafic est constitu de 2 blocs de donnes, sur lequel sont appliqus
un code d'talement et un code d'embrouillement, qui encadrent une squence
d'apprentissage non tale, non embrouille utilise pour estimer le canal, le tout
suivi d'une priode de garde de 16 chips.
Le burst DwPTS est mis par le Node B. Il est compos d'une priode de garde
(PG) de 32 bits et d'une squence pilote SYNC-DL fixe, non brouille. Pour couvrir
les besoins de tout le systme, 32 squences SYNC-DL diffrentes sont prvues.
Lors de la procdure de synchronisation en voie descendante, un mobile dtecte la
squence SYNC-DL transmise dans la cellule et en dduit la position du canal balise
(synchronisation trame) et le code de groupe de la cellule. Ce code de groupe permet
d'identifier tous les paramtres de la cellules (code d'embrouillage et squence
d'apprentissage ddis, organisation des canaux communs...).
Figure 3.12. Structure du burst DwPTS
Le burst UpPTS est compos d'une squence fixe SYNC-UL longue de

128 chips, non brouille, suivi de 32 chips de priode de garde. Il y a 256 squences
SYNC-UL diffrentes pour permettre la synchronisation en voie montante des
mobiles dans tout le systme selon la procdure dcrite dans le paragraphe suivant.
S YNC-UL( 128chips) PG(32chips)
Figure 3.13. Structure du burst UpPTS
3.2.5. Procdures spcifiques du 1,28 Mchips TDD
Du fait de sa conception permettant le support de la synchronisation en voie

montante, le contrle de puissance rapide en boucle ferme de la voie montante et la
formation rapide de faisceaux, la couche physique du mode 1,28 Mchips TDD
comprend plusieurs procdures qui soit n'existent pas dans le 3,84 Mchips TDD,
soit y sont diffrentes :
3.2.5.1. Contrle de puissance

Contrairement celui du 3,84 Mchips TDD, le contrle de puissance du
1,28 Mchips TDD peut fonctionner en boucle ferme galement en voie montante.
Uplink Downlink
Frquence du Variable Variable

contrle de Boucle ferme : 0-200 cycles/sec Boucle ferme : 0-200
puissance Boucle ouverte : (dlai de 200ps 3575 ps) cycles/sec
Pas d'ajustement 1,2,3 dB (boucle ferme) 1,2,3 dB (boucle

ferme)
Tableau 3.2. Caractristiques du contrle de puissance
3.2.5.2. Synchronisation temporelle fine en voie montante

Lors de la mise sous tension, un mobile se synchronise d'abord par rapport aux
signaux reus du rseau (synchronisation en voie descendante ). Il entame ensuite la
synchronisation en voie montante.
3.2.5.2.1. Etablissement de la synchronisation en voie montante

La synchronisation de la voie montante est ralise pendant la procdure d'accs
alatoire (RACH) pralable toute communication. La premire transmission du
mobile vers le Node B est faite dans un IT UpPTS de manire minimiser
l'interfrence dans les IT de trafic. L'instant d'mission est choisi en fonction de la
puissance des signaux reus en voie descendante.
Aprs la dtection de la squence S Y N C U L dans la fentre de recherche, le

Node B value les instants d'arrive et retourne dans un dlai de quatre sous-trames
une information d'ajustement au mobile que celui-ci utilisera pour sa prochaine
transmission. La synchronisation temporelle fine en voie montante est alors tablie.
3.2.5.2.2. Maintenance de la synchronisation en voie montante

La maintenance de la synchronisation en voie montante peut tre ralise en
utilisant le midambule de chaque burst de la voie montante. En effet, les
midambules des diffrents UE transmettant dans le mme IT tant diffrents, le
Node B peut estimer les instants d'arrive respectifs des diffrents UE en valuant la
rponse impulsionnelle de leurs canaux radio et leur retourner ensuite une
commande d'ajustement de l'instant de transmission.
3.2.5.3. Formation rapide de faisceaux

Les caractristiques principales du 1,28 Mchips TDD telles que la structure en
deux sous-trames de 5 ms permettent de mettre en uvre les techniques de
formation rapide de faisceaux pour lesquelles le Node B doit adapter instantanment
l'ensemble de ses faisceaux la rpartition de la charge dans la cellule.
Quand la fonction formation de faisceaux est active, le Node B utilise les

donnes reues des UE en voie montante pour estimer leurs positions et former ensuite
des faisceaux dirigs vers ceux-ci pendant la transmission en voie descendante.
3.3. Estimation de canal multi-utilisateur
3.3.1. Description du problme
Dans un systme classique FDMA ou TDMA, les diffrents utilisateurs sont

spars en temps ou en frquence et l'estimation de canal est gnralement ralise
indpendamment pour chacun d'eux grce l'mission priodique de squences
d'apprentissage exploites par un simple corrlateur. Dans le cas de l'UMTS TDD bas
sur une structure TD-CDMA, les squences d'apprentissage des diffrents utilisateurs
l'intrieur d'un IT sont transmises simultanment et interfrent entre elles, ce qui rend
obsolte l'estimation mono-utilisateur classique. De plus, la connaissance des estims
de canal vu par les autres utilisateurs d'un IT est requise pour appliquer les techniques
de dtection de donnes multi-utilisateur telles que la dtection conjointe.
Il est donc ncessaire de mettre en uvre une technique d'estimation de canal

multi-utilisateur dont l'objectif est de rduire l'interfrence la rception entre les
diffrentes squences d'apprentissage et de permettre l'estimation simultane des
canaux des diffrents utilisateurs. Cela ncessite un choix judicieux des squences
d'apprentissage coupl la mise en uvre d'algorithmes de rduction d'interfrence.
Frquence
Burst (transmis dans un IT)
Figure 3.14. Structure d'un burst UMTS-TDD
3.3.2. Modlisation
Considrons un intervalle de temps o K utilisateurs sont actifs simultanment

en voie montante et mettent donc chacun un burst contenant une squence
d'apprentissage ou midambule. La figure 3.15 reprsente le modle temps discret
dans lequel le midambule m(A) de chaque utilisateur k est convolue avec la rponse
impulsionnelle de son canal radio spcifique h*, tous les signaux tant ensuite
somms avant d'tre altrs de manire identique par le bruit thermique AWGN et
les interfrences extra-cellulaires.
Figure 3.15. Modle temps discret de la communication

Chacun des ûtilisateurs met un midambule de longueur! + W - 1 chips :
T
} k = \ K [3.7]
L+W-1
o mfk) est le f chip du midambule du ke utilisateur.

i
Chaque midambule est convolu par la rponse impulsionnelle de son canal
respectif de longueur maximale W chips.
h(k) ,k = \K [3.8]
2 "W
Seuls L chips sont effectivement utiliss par la station de base pour estimer les
canaux, bien que l'utilisateur mette un midambule m(/r) de longueur L + W- 1
chips, car les W- 1 premiers lments de m u> sont affect par de l'interfrence inter
symbole provenant des donnes du bloc prcdant le midambule convolues par la
rponse impulsionnelle du canal de longueur W chips (L doit donc tre choisi aussi
grand que possible pour garantir un gain de compression suffisant la rception).
Les signaux des diffrents utilisateurs, s'additionnent avant que ne viennent
s'ajouter le bruit et l'interfrence extra-cellulaire. On peut donc crire le signal reu
comme :
K W
e = m<k) *h(k>+n [3.9]
i k = \j = \ W+l j i
o Hj reprsente le bruit et l'interfrence extra-cellulaire de variance a 2 . Cette

quation peut s'crire de manire condense sous la forme matricielle ([STE 94]) :
e
[Z,xl] - G [Lxt/] h [t/xl] + n[Lx 1] [3.10]
avec e = et n = ; h est le vecteur
des rponses impulsionnelles de canal de taille U = KW (U tant le nombre de

coefficients inconnus dterminer par la station de base) obtenu en concatnant les
(k)
K rponses impulsionnelles de canal h de longueur Mchips :
(i)r ,(2)7' (K)T [3.11]

et G est la matrice [L*UJ des codes :
G = [G(1) G (2) ... G(K)] [3.12]
construite partir des sous-matrices de taille [LxW\ :
[3.13]
Ces sous-matrices sont elles mme construites partir des lments du

i (k)
midambule du me utilisateur m de la manire suivante :
g\j = mw\i-j > P u r i = ] L et

J =1 w
[3.14]
Seuls L chips sont effectivement utiliss par la station de base pour estimer les
canaux, bien que l'utilisateur mette un midambule m ( A ) d e longueur L+W-1
chips. La formule [3.10] est un systme de L quations U inconnues pour lequel au
moins une solution exacte existe si U = KW est infrieur ou gal L.
Exemple :
Soit un systme avec K = 2 utilisateurs transmettant dans 2 canaux diffrents de
rponses impulsionnelles o .0) ,h<2) = .(2) .(2) de
longueur W = 2 chips. Ces rponses impulsionnelles forment un vecteur :
.(D ,(2) ,(2) contenant un nombre U = KW = 4 de
coefficients de canal inconnus. Le segment utilisable de longueur L du

midambule doit tre d'au moins 4 chips, par consquent choisissons L = 4. On
obtient alors respectivement pour l'utilisateur 1 et l'utilisateur 2 les midambules :
m( i ) .o> .d) et m<2> = [ . ( 2 ) ,(2) .(2)

m (2) m (2)
de longueur totale L + W -1 = 5 chips qui gnrent les sous-matrices :
<> m\ m<2) m, ( 2 )
m m m (2) m
(2)
(1) et G (2) _
m m' m (2) m (2)

m\ m (2) m (2)
Le m o d e U T R A - T D D et ses performances 125
Ces sous-matrices sont ensuite concatnes pour former la matrice code :
<> m? m, (i2 )
<> <> m\ 2) ni .(2)
G = [G(1) G(2)] =
<> mf m ,(2)
<> mf m. , ( 2 )
qui est une matrice carre puisque L-U .
La formule [3.10] forme alors un systme de 4 quations linaires 4 inconnues

qui s'crit :
e\ m<2) m\ 2)~ V
mf mf <> m? h<" n2
< m? mf> h ?>
+
"3
e 2)
4. mf m? m\ n
A
Chaque lment du vecteur e contient la contribution de chaque midambule

convolu par son canal respectif et augmente du bruit AWGN.
3.3.3. Les estimateurs de canaux :

estimateur maximum de vraisemblance / filtrage adapt
L'estimation \i est maximum de vraisemblance du vecteur h des rponses

impulsionnelles de canal est donne par l'quation [3.15]4 :
HEST = M e avec M = (G H R" 1 G } ' G H R" 1 . [3.15]
Dans le cas habituel o le bruit nest blanc, la matrice de covariance Rn du

vecteur de bruit n est particulirement sympathique car elle est de la forme
diag (a 2 ). La matrice R n ' est donc de la forme diag (l / o2 ). L'estimateur
LxL LxL
maximum de vraisemblance de l'quation [3.15] se simplifie alors en :
h = Me= ( G H G) ' G H e [3.16]
4. la notation X" est l'oprateur transpos conjugu.

qui est l'estimateur au sens des moindre carrs (Least Sum of Squared Errors) et
correspond la matrice pseudo inverse de G. Cette expression se simplifie en
M = G - 1 si U = L car la matrice G est alors carre.
L'estimateur ainsi dcrit ralise donc successivement un banc de filtres adapts,

suivi de la suppression des interfrences entre midambules. En effet, en introduisant
l'expression de e dans l'quation [3.16], on obtient :
h e s t M L = M e = ( G H G)" 1 G H G h + ( G H g ) " ' G H n [3.17]
et on vrifie que la totalit des interfrences entre midambules a t supprime :
êst,ML = h + ( o " g ) ' G " n [3.18]
Le prix payer pour obtenir la suppression de ces interfrences et donc

l'estimation maximum de vraisemblance est la dgradation du RSB pour chaque
lment de hc,s7 en comparaison du RSB qui serait obtenu en sortie d'un simple
filtrage adapt :
h,MF=GHe=G " G h +G"n [3.19]
L'quation [3.19] montre que la dgradation induite du RSB dpend des valeurs
propres de GG et donc que le choix des midambules a un impact sur les
performances.
3.3.4. Choix des midambules
Une recherche exhaustive des K midambules de longueur L + W -1 prsentant

les meilleures proprits d'intercorrlation est inenvisageable. En effet, il a
slections de midambules possibles. Des contraintes supplmentaires sont imposes
pour permettre des rductions de la complexit des calculs, ce qui a pour effet de
rduire le nombre de midambules possibles. Les diffrents midambules sont des
versions dcales cycliquement d'une mme squence de base de longueur L + U- 1,
ce qui limite 2L+U~] le nombre de possibilits. De plus, la squence de base des
midambules est choisie priodique de priode L, ce qui rend les matrices G<k)T
circulantes droite. Enfin, L = U = KW, ce qui rend G et G - 1 circulantes droite et
carres (M = G - 1 ).
Figure 3.16. Drivation de diffrents midambules

partir d'un mme code priodique de base
Exemple :
Pour K = 2 utilisateurs et 2 canaux de rponse impulsionnelle de longueur
W= 2 chips, le nombre total de coefficients de canal inconnus est U = KW = 4 et
L = 4. La squence de base des midambules m est alors de longueur L + U- 1 = 7 et
priodique de priode L = U.
Les midambules des utilisateurs 1 et 2 ont une longueur totale de L + W -1 = 5

chips.
L
et gnrent les sous-matrices G ^ e t G(2) concatnes dans la matrice code, qui

est maintenant circulante droite :
3.3.5. Mise en uvre de l'estimateur de canal maximum de vraisemblance
L'estimateur de canal maximum de vraisemblance peut se faire de deux

manires : par corrlateur cyclique ou bien par FFT (.Fast Fourier Transform).
3.3.5.1. Mise en uvre par corrlateur cyclique

Les matrices G et G"1 tant circulantes droite, la dtermination de h est une
simple corrlation circulaire de e avec une colonne de M (qui peut tre prcalcule),
ralisable par un corrlateur cyclique. Cette mise en uvre est intressante dans le
cas o on n'a besoin d'estimer qu'un petit nombre U0 U de coefficients de canal
(par exemple en voie descendante avec un midambule commun pour tous les
utilisateurs).
3.3.5.2. Mise en uvre complexit rduite par FFT

Une proprit des matrices circulantes droite est que leurs vecteurs propres sont
les colonnes de la matrice inverse DFT, ce qui permet de les diagonaliser facilement
par DFT (Discrte Fourier Transform) et IDFT (la matrice DFT est note W).
En effet, en notant vecteur mj la premire colonne de G compltement

dtermine par les L lments diffrents de la squence de base des midambules :
[3.20]
On peut avantageusement employer des transformes de Fourier rapides pour

faire les DFT et IDFT avec une complexit rduite. De plus, les midambules des
utilisateurs sont connus, ce qui permet de prcalculer les valeurs de A partir des
lments du midambule et de les stocker.
La complexit des transformes de Fourier rapides mises en uvre dpend de L :

le tableau 3.3 donne la complexit gnrale de l'estimateur en utilisant des FFT de
radix 2 quand L est une puissance de 2 (par exemple L = 128 pour le 1,28 Mchips
TDD). La complexit doit tre recalcule au cas par cas quand L n'est pas une
puissance de 2 (par exemple L = 456 ou 192 dans le 3,84 Mchips TDD).
L'estimation maximum de vraisemblance est alors ralise avantageusement au

moyen de :
- une FFT de longueur L sur e ;
- une pondration du rsultat par les coefficients diagonaux de A ;
- une FFT inverse de longueur L sur le rsultat des oprations prcdentes.
Opration Nombre de multiplications complexes

FFT sur e (1/2) x log2(L/2)
Pondration par A L
IFFT sur A We (.U2) x log 2 (I/2)
Total L x (1 + log2(L/2))
Tableau 3.3. Nombre de multiplications complexes dans l'estimation maximum de

vraisemblance par FFT-Radix 2 quand que L est une puissance de 2
3.3.6. Performances de l'estimateur de canal maximum de vraisemblance
Les figures 3.17 et 18 illustrent les performances de l'estimateur de canal multi-

utilisateur maximum de vraisemblance en fonction du nombre de midambules
transmis simultanment, pour le cas du 3,84 Mchips TDD avec des midambules de
512 chips.
La figure 3.17 dtaille l'impact de la prsence simultane de midambules

interfrents transmis forte puissance relative (+10 dB) sur l'estimation du canal
d'un utilisateur. Elle montre une dgradation significative (suprieure 2 dB) pour
les forts RSB avec un seul interfreur, et une trs forte dgradation sur toute la
gamme de RSB considrs lorsque le nombre d'interfreurs est suprieur 2. Cela
illustre la ncessit du contrle de puissance pour un fonctionnement correct de
l'estimateur de canal.
Canal 3GPP-Case 3
( 0dB@ 0ns, -3dB@ 260ns, -6dB@ 521 ns, -9dB@ 781ns) 120 km/h
Figure 3.17. Erreur quadratique moyenne de l'estimation de canal en fonction du nombre de

midambules interfrents +10 dB
La figure 3.18 montre la dgradation de l'estimation de canal en fonction du

nombre d'interfreurs (de puissance identique). Cette dgradation est d'autant plus
forte que le RSB est grand, et atteint 3 dB pour une erreur quadratique moyenne de
0,05 dans le cas o 8 midambules sont transmis simultanment.
Canal 3GPP-Case 3
( 0dB@ 0ns, -3dB@ 260ns, -6dB@ 521 ns, -9dB@ 781ns) 120 km/h
Figure 3.18. Erreur quadratique moyenne de l'estimation de canal5 en fonction du nombre

de midambules interfrents 0 dB
3.4. Dtection conjointe
Bien que le mode TDD de l'UMTS soit synchrone et utilise des codes
d'talement orthogonaux, cette orthogonalit est brise par la transmission dans le
canal radio multitrajet slectif en frquence et le systme subit la rception la
fois de l'interfrence entre symboles d'un mme utilisateur (1ES) et de l'interfrence
d'accs multiple entre symboles d'utilisateurs diffrents (IAM). L'efficacit du
rcepteur conventionnel mono-utilisateur est limite dans cet environnement car il
traite l'interfrence d'accs multiple comme une augmentation du bruit blanc
gaussien. Du fait de l'extension des techniques CDMA, de nouvelles approches ont
t explores, qui utilisent la connaissance a priori des codes d'talement et des
estims de canal des autres utilisateurs pour rduire le niveau d'interfrence d'accs
multiple. Les fondements thoriques du rcepteur multi-utilisateur optimal ont t
dcrits par Verdu [VER 89] mais la puissance de calcul requise pour le mettre en
uvre est prohibitive ; des techniques sous-optimales ont donc t dveloppes,
5. Voir annexe 3.7 pour la description dtaille du modle de canal.

parmi lesquelles les techniques linaires qui ont t regroupes sous le vocable de
dtection conjointe.
L'objectif de la dtection conjointe est, en se basant sur la connaissance des

diffrents codes d'talement utiliss et des estims de canal associs, de dtecter
simultanment les donnes de chacun des utilisateurs prsents dans un IT tout en
minimisant pour chacun d'entre eux l'interfrence provenant des autre utilisateurs.
3.4.1. Description du problme, modlisation
Supposons un systme CDMA synchrone dans lequel K utilisateurs transmettent

simultanment N symboles chacun en utilisant K codes d'talement orthogonaux de
longueur Q chips, transmis travers K canaux multitrajet diffrents (dont les
rponses impulsionnelles s'talent sur au plus L chips) sur une mme bande de
frquence avec Bc = .
Tc
Figure 3.19. Modle temps discret d'une transmission CDMA synchrone en voie montante
Le problme peut tre modlis sous la forme d'une quation matricielle ([KLE 94]
et [PIG 99]) dont on extraira l'estim des donnes transmises au moyen d'un critre
donn (LS, MMSE). Le signal reu peut tre exprim sous la forme :
e=A.d+n [3.21]
L e m o d e U T R A - T D D e t ses p e r f o r m a n c e s 133
ou :
d= ] symboles mis avant talement
e = [ e\>-'> eN.Q>---> eN.Q+ L-1] 7" si nal

re
U
n = [,, '^N.Q^"">nN.Q+L-\\ blanc gaussien additif
A = [A..] i = \...N.Q + L-\ Qt j = \...N.K matrice systme
Figure 3.20. Dtail de la matrice systme
Les lments de A sont construits de la faon suivante :
\bk si k = \...K,n = \...N,w = \...Q + L-\

A =<w
Q (n-\)+w , k+K.(n-\) 0 sinon
Le scalaire bk est dfini comme un lment du vecteur bk = ck * hk (2^ avec
bk,bk,...,bk qui reprsente la rponse impulsionnelle globale du ke

12 Q+L-l
134 Principes et volutions de l'UMTS >
T
utilisateur, hk = hk,hk,...,hk qui reprsente l'estim de la rponse
12 L
T
impulsionnelle du ke canal (L chantillons de dure Tc) et ck = ck ,ck ,...,ck est
1 2 Q
le ke code d'talement (Q bits espacs de Tc). Le paramtre k varie de 1 K.
Chaque bloc de K colonnes de A contient les vecteurs bk qui sont les rponses
impulsionnelles globales des k utilisateurs, c'est--dire pour chacun d'eux la
convolution de la rponse impulsionnelle de son canal par son code d'talement.
Exemple :
Considrons le cas o 2 utilisateurs transmettent chacun 2 symboles de donnes en
utilisant des codes de Hadamard de 4 chips travers 2 canaux diffrents de longueur 3
chips (les signaux considrs sont rels et le bruit est nglig par soucis de clart).
Les codes d'talement utiliss sont par exemple respectivement :
c=[ 1 -1 1 -lj (Q chips)
c2=[\ 1-1 -lj ( Q chips).
Les rponses impulsionnelles des canaux sont :
h =[ 1 1/2] (L chips)
h =[ 1 1/4] (I chips),
et les donnes transmises par les 2 utilisateurs sont d = [ 1 1 ] et d^ = [ 1 -1].

Aprs talement et transmission dans les canaux radio, le signal reu est donc :
e = [2 3/4 -1/4 -7/4 -3/4 -7/4 5/4 3/4 - I/4J

Au niveau du rcepteur, les codes et les canaux tant supposs parfaitement estims,
ils sont utiliss pour construire la matrice systme. Les rponses impulsionnelles
globales des 2 utilisateurs sur leurs canaux radio respectifs sont calcules :
^=[1 -1/2 1/2 -1/2 -1/2J

(Q+L-l chips)
b2 = [l 5/4 - 3/4 - 5/4 -1/4 ] (Q+L-l chips)

puis intgres dans la matrice systme de dimension ( N K ) x (N Q + L - 1) :
3.4.2. Critres de rsolution du systme d'quations linaires
Le principe de la dtection conjointe est de rsoudre l'quation linaire [3.21],

c'est--dire de dterminer un estim d des donnes transmises d en fonction du
signal reu e, de la matrice systme A et de la connaissance ventuelle des
proprits statistiques du bruit AWGN n. Cela peut tre fait selon plusieurs critres
sous-optimaux dcrits dans [KLE 94]. Les plus usuels sont les algorithmes Zro
Forcing Block Linear Equalizer (ZF-BLE) ou galiseur linaire en bloc par forage
zro et le Minimum Mean Square Error Block Linear Equalizer (MMSE-BLE) ou
galiseur linaire en bloc erreur quadratique moyenne minimale.
3.4.2.1. Egaliseur linaire en bloc par forage zro

L'galiseur linaire en bloc par forage zro minimise la forme quadratique :
A A
(e-Ad)H R~\e-Ad) [3.22]
ce qui revient maximiser la probabilit de e pour A et d donns (P(e/A,d)). Rn est

la matrice de covariance du vecteur de bruit n, ce qui mne [HAY 96] et [KLE 94] :
d = (AH R~lA)~lAH R~le

d + (AHR~lA)~lAHR~ln [3.23]
symboles utiles bruit
Cet galiseur est appel forage zro car il limine totalement l'interfrence
entre symbole (IES) et l'interfrence d'accs multiple (IAM), sans tenir compte du
niveau du bruit (l'estim contient la donne elle-mme plus un terme de bruit).
Si les chantillons de bruit sont dcorrls (cas usuel), la matrice de corrlation

du bruit Rn 11 devient
bruit/?" a 22I,I, o
devientCT Oa2a2est
estlala variance du bruit et I est la matrice identit
Les donnes estimes devenant alors :
d = (AH A)~XAH e
+ (AHA)~XAHn [3.24]
symboles utiles bruit
Cet algorithme est trs efficace si le niveau de bruit est faible car le deuxime
terme est alors faible devant le premier.
3.4.2.2. Egaliseur linaire en bloc erreur quadratique moyenne minimale

L'galiseur linaire en bloc erreur quadratique moyenne minimale minimise :
E({d-d)H (d-d)) [3.25]
c'est--dire l'erreur commise sur l'estime elle-mme, ce qui mne [HAY 96] et
[KLE 94] :
d = (AHR~lA + R~l)~lAHR~le
A
l
= H l
(I + (RdA R- A)- )-\dzF-BLE
WQ estimateur de Wiener [3.26]
H nD - R~
= diag(W0).d + diag(W0).d + (A \ A l , D - K -11 1aH n
A + R' )' A R~ 1l
n
symboles IES et IAM bruif
En cas d'chantillons de bruit et de donnes non corrls (cas usuel), l'estim

devient :
d = (AHA+G2I)~1 AHe p 27]

Cet algorithme prsente une meilleure immunit au bruit que l'algorithme par
forage zro car il pondre la suppression d'interfrence en fonction du rapport
entre le niveau d'IAM et le niveau de bruit :
En effet, l'quation [3.27] peut s'crire sans perte de gnralit sous la forme :
[3.28]
o les termes reprsentent

respectivement les puissances de l'IAM, du signal et du bruit.
Lorsque le niveau de bruit est petit par rapport au niveau d'IAM, l'quation
[3.28] se simplifie en :
[3.29]
qui est similaire l'estim obtenu par l'algorithme de forage zro.
En revanche, quand la puissance de l'IAM est petite devant le bruit (c'est--dire

quand l'quation [3.28] se simplifie en :
[3.30]
2
Cette expression peut s'crire, en considrant la puissance moyenne <j e
du signal reu e :
[3.31]
qui est similaire, un coefficient prs, une estimation par filtrage adapt.
On constate donc que si le niveau de bruit est grand devant le niveau

d'interfrence d'accs multiple, l'algorithme se comporte de faon similaire un
banc de filtres adapts alors qu'il se comporte comme un algorithme de forage
zro si l'IAM est grande devant le bruit.
Des galiseurs contre-raction (DFE, Dcision Feedback Equalizers) nomms

MMSE-BDFE et ZF-BDFE ont galement t drivs partir de la mme base
thorique.
Exemple (suite et fin) :

Considrons la rsolution du systme linaire dcrit prcdemment selon le
critre ZF-BLE pour lequel les donnes sont estimes selon l'quation :
De A, on obtient facilement :
3.4.3. Performances de la dtection conjointe
La figure 3.21 illustre les performances de la dtection conjointe en voie

descendante (simulation effectue avec l'algorithme ZF-BLE) dans un canal
multitrajet en fonction du nombre de codes prsents. Le modle de canal utilis dans
la simulation est indiqu en annexe.
Le mode U T R A - T D D et ses performances 139
Voie descendante / Canal Case 3

( 0dB@ 0ns, -3dB@ 260ns, -6dB@ 521 ns, -9dB@ 781ns) 120km/h
Figure 3.21. Performance de la dtection conjointe en voie descendante

en fonction du nombre de codes transmis simultanment
(<contrle de puissance parfait/estimation de canal par midambule)
Les performances de la dtection conjointe dcroissent avec le nombre de codes

transmis simultanment, particulirement pour les faibles TEB. Dans la pratique,
cela implique que le nombre maximum thorique de codes transmis simultanment
(16) ne sera pratiquement jamais atteint et que le systme sera en gnral limit par
l'interfrence un maximum de 10 12 codes par IT.
La figure 3.22 prsente les performances de la dtection conjointe en voie

montante qui sont moindres qu'en voie descendante. Cela est d au fait que le
niveau d'interfrence est plus important en voie montante car le canal radio vu par
chacun des utilisateurs lui est spcifique.
3.4.4. Rduction de la complexit de la dtection conjointe
Le principe de la dtection conjointe prsent prcdemment est de rsoudre

l'quation matricielle e = Ad + n (c'est--dire d'estimer d en connaissant e et a) en
fonction d'un critre prdfini dont les plus rpandus sont le zro forcing (ZF), qui
annule l'interfrence ou l'erreur quadratique moyenne minimum (MMSE). Ces
critres mnent aux solutions suivantes :
d = ( ^ A H A ; _ 1 A H e pour le ZF et d = (Au A + <J 2 \)~ ] A H e pour le MMSE

2
(a tant la variance des lments de n).
La rsolution de cette quation ncessite de calculer A partir de l'estimation de

canal et des squences d'talement, de raliser le produit AH e, de raliser le produit
A" A et enfin de rsoudre un systme linaire de matrice AH A ou AH A + ct2 I de
taille (N.K x N.K). Ces oprations raliser sur des matrices de cette taille sont
extrmement coteuses en puissance de calcul. Une rduction de la complexit est
donc particulirement intressante.
Figure 3.22. Performance de la dtection conjointe en voie montante(

en fonction du nombre de codes transmis simultanment
(icontrle de puissance parfait/Estimation de canal par midambule)
6. Voir annexe pour la description dtaille du modle de canal.

3.4.4.1. Optimisation
Une premire rduction de complexit est obtenue en tenant compte des
caractristiques des matrices A, AH et AH A (identiquement AH A + a 2 I) qui
contiennent de nombreux coefficients nuls dont la position est connue en fonction
des caractristiques de la transmission et qui peuvent donc ne pas tre traits.
D'autre part, la matrice AH A (et identiquement AH A + CJ2I) est hermitienne

semi-dfinie positive, ce qui permet d'employer la dcomposition de Cholesky pour
rsoudre le systme linaire associ avec une complexit de l'ordre de (NK)3/6 au
lieu de (NK)3/3 si on utilise une mthode de rsolution plus gnrale (par exemple la
mthode du pivot).
3.4.4.2. Dcomposition de Cholesky approche

Cependant, la quantit de calcul reste trs importante et peut encore tre
drastiquement rduite en utilisant, par exemple, une dcomposition de Cholesky
approche : en effet une autre proprit des matrices AH A et AH A + a 2 I est qu'elles
sont de type bloc Toeplitz et ne contiennent que P + 1 sous-matrices non nulles
diffrentes de taille [K, K/, P tant la partie entire de ((Q + L - 1 )/Q).
La dcomposition de Cholesky d'une matrice de ce type converge en ligne de

blocs ([PIG 99] et [RIS 73]) : le rsultat de la dcomposition de Cholesky est ici
constitu de N lignes de P + 1 blocs non nuls de taille [K, K]. On peut donc
appliquer cette proprit et ainsi ne calculer que N0 lignes de blocs (avec
NQ <N ) puis obtenir les lignes NQ + 1 N par duplication. Un choix judicieux de
No permet de ne pas avoir d'impact notable sur les performances de la dtection
conjointe. La complexit de la dcomposition est ainsi rduite
proportionnellement (N/N 0 ) 2 .
La rduction de complexit apporte par ces algorithmes permet d'implanter la

dtection conjointe sur DSP [NOG 04].
3.5. Allocation dynamique des ressources
Comme dans tous les rseaux CDMA, la gestion de la ressource radio est trs
importante. En UTRA-FDD, elle est principalement faite par le contrle de
puissance. En UTRA-TDD, le contrle de puissance garde son importance mais il
faut galement dvelopper des algorithmes d'allocation de ressources radio.
Les types d'interfrence prsents en UMTS-TDD sont :

- les interfrences de la voie montante vers la voie descendante, sous la forme
d'interfrences de mobile mobile ;
- les interfrences de la voie descendante vers la voie montante, sous la forme
d'interfrences de station de base station de base ;
- les interfrences internes la voie montante ou la voie descendante, de
mobile station de base et inversement.
Les interfrences voie montante/voie descendante et voie descendante/voie

montante se produisent lorsque les stations de base ne sont pas synchronises ou
lorsque des asymtries diffrentes sont utilises dans des cellules adjacentes (un
intervalle de temps utilis en voie montante dans une cellule est utilis en voie
descendante dans une cellule voisine). Elles peuvent donc tre combattues par la
synchronisation du rseau et l'utilisation de la mme asymtrie dans les cellules
adjacentes.
Le respect de cette dernire condition conduit la perte d'une partie de la

flexibilit du TDD. Cependant, dans le cas de cellules mettant faible puissance, il
est envisageable de faire des exceptions cette rgle ([HOL 00] et [JEO 00]).
Les interfrences voie montante/voie montante ou voie descendante/voie

descendante ne peuvent quant elles tre traites que par l'allocation dynamique de
canaux (DCA, Dynamic Channel Allocation) ([25.922], [ARG 99], [HAA 00]) qui
alloue les ressources physiques lmentaires (combinaison de 1 code, 1 IT et 1
frquence) aux diffrents services en fonction de critres de qualit prtablis de
manire optimiser les performances du systme en termes de probabilit de
blocage, de capacit systme, et de qualit des appels.
La DCA englobe plusieurs mcanismes : le contrle d'admission des appels qui

dfinit quand un appel est accept ou refus par le systme, la stratgie d'allocation
de ressource qui dfinit quelle ressource est alloue un appel lorsqu'il a t accept
et l'algorithme de groupage des ressources qui dcide quand dclencher une
rallocation de ressources en cours d'appel.
Pour ce faire, la DCA est scinde en 2 parties : la DCA lente contrle par le
RNC {Radio Network Controller) qui alloue des sous-ensembles de ressources aux
cellules et la DCA rapide, situe au niveau de chaque station de base, qui alloue les
ressources aux services dans les cellules l'intrieur des sous-ensembles
pralablement allous par la DCA lente.
3.5.1. Allocation des ressources aux cellules (DCA lente)
Dans un systme UMTS TDD, il n'y pas de planification de frquences : une

mme frquence porteuse peut tre utilise dans des cellules adjacentes mais les IT
(slots) sont partags entre cellules.
Les IT de la trame TDD sont utilisables aussi bien en voie montante qu'en voie
descendante ( l'exception de ceux rservs la synchronisation ou la
signalisation commune). L'allocation des ressources en voie montante et voie
descendante adapte donc le systme aux variations dans le temps de l'asymtrie du
trafic.
L'allocation des IT aux cellules (en voie montante comme en voie descendante)
est ractualise priodiquement faible rythme (DCA lente) de faon que des
cellules interfrant fortement utilisent des IT diffrents (voir figure 3.23). Cependant
les ressources alloues des cellules adjacentes peuvent tout de mme se
chevaucher en fonction du niveau d'interfrence entre les cellules.
Pendant les priodes libres entre la rception et la transmission des bursts

successifs, les mobiles peuvent fournir au rseau des mesures (affaiblissement de
parcours sur un sous-ensemble de cellules, interfrence dans les IT diffrents de
celui en cours d'utilisation, BER du lien en cours, puissance de transmission du
mobile dans le lien courant). Ces informations cumules avec celles provenant des
stations de base nourrissent l'algorithme de DCA.
3.5.2. Allocation des ressources aux services (DCA rapide)
L'allocation de ressource rapide consiste allouer un ou plusieurs canaux

physiques un service. Les ressources sont alloues et libres en fonction d'une
liste de prfrence drive de la DCA lente et les diffrents dbits de service sont
supports par agrgation de ressources lmentaires. Cela peut se faire dans le
domaine des codes (codes multiples dans un mme IT = multi code), dans le
domaine temporel (IT multiples dans une mme trame = multi IT) ou par
combinaison des deux.
Le nombre maximal de codes utilisables dans un IT varie en fonction des

circonstances et notamment en fonction des caractristiques du canal.
Pour les services temps rels (RT), les canaux sont allous pour la dure totale
du service et l'allocation ne peut tre modifie que si une procdure de rallocation
est mise en uvre.
Pour les services non temps rel (NRT), les canaux sont allous seulement pour
la dure de transmission d'un paquet selon la procdure du best effort (les
besoins en ressources non satisfaits sont placs en liste d'attente, le nombre de
ressources alloues un service dpend des disponibilits et des autres requtes
traites simultanment).
La procdure de rallocation (handover intracellulaire) peut tre dclenche pour

s'adapter aux variations des conditions d'interfrence, pour limiter la fragmentation
des codes allous sur trop de IT (libration des IT les moins chargs puis
rallocation de canaux) et permettre ainsi de servir des services haut dbit RT ou
encore pour conserver la sparation spatiale des diffrents utilisateurs d'un mme IT
quand des antennes actives sont utilises.
Figure 3.23. Exemple de partage des IT entre cellules (DCA lente)
3.6. Synchronisation du rseau (3,84 Mchips TDD)
Du fait de sa structure de sparation duplex en temps, une synchronisation inter-

cellule est ncessaire pour exploiter pleinement la capacit du systme (en
particulier viter les interfrences de mobile mobile). La prcision de
synchronisation requise est de l'ordre de 3 ps pour l'UTRA TDD.
3.6.1. Prsynchronisation par le rseau
La structure du rseau avec les stations de base (ou Node B) d'un RNS contrl
par un mme RNC permet d'obtenir une synchronisation grossire des Node B d'un
RNS par signalisation sur les interfaces Iub et Iur qui relient les Node B et le RNC.
Du fait des dlais imposs par la transmission sur les interfaces Iub et Iur, la
prcision atteinte est de l'ordre de 5 trames (50 ms), le niveau de prcision suprieur
requis de 3 ps doit alors tre atteint par un mcanisme de synchronisation fine.
3.6.2. Synchronisation fine par horloge de rfrence {de type GPS)
La faon la plus directe de synchroniser finement le rseau UMTS-TDD est

d'utiliser une rfrence de temps externe, par exemple le temps GPS dans chaque
station de base. Malheureusement, cela peut devenir peu pratique ou impossible
dans certains scnarios de dploiement tel qu'un dploiement indoor o une antenne
extrieure est requise pour chaque rcepteur GPS.
3.6.3. Mcanisme de synchronisation fine
Un mcanisme additionnel de synchronisation a t conu pour viter

l'utilisation de rcepteurs GPS. Il est bas sur des transmissions priodiques de
squences de synchronisation spcifiques couples des mesures de temps de trajet.
Ce mcanisme de synchronisation des stations de base permet de synchroniser

les stations de base TDD d'un mme RNS (Radio Network Sub-system) c'est--dire
contrles par un mme RNC (Radio Network Controller). Ce mcanisme ncessite
qu'au moins une des stations de base ait accs une horloge de rfrence sur
laquelle les autres stations vont venir se synchroniser.
Typiquement, les Node B d'un RNS sont informs par le rseau des instants de
transmission ou d'coute des bursts de synchronisation interstation de base dans des
IT de voie montante pour l'accs (uplink RACH) rservs cet effet. Un Node B
qui reoit un burst de synchronisation peut mesurer son cart de synchronisation par
rapport la station de base mettrice et le reporter au RNC. En moyenne, chaque
Node B devrait transmettre une squence de synchronisation toutes les 10 15
secondes et recevoir des squences de synchronisation des cellules voisines toutes
les secondes. A partir des carts de synchronisation mesurs et de l'horloge de
rfrence, le RNC peut driver les corrections d'horloge pour les Node B qu'il
contrle. La procdure peut tre divise en 2 phases, la synchronisation initiale et la
phase de maintient de la synchronisation.
3.6.3.1. Synchronisation initiale

Au dmarrage du rseau, quand il n'y a pas de trafic, les cellules d'un RNS
doivent toutes tre synchronises. Toutes les cellules transmettent successivement
la mme squence de synchronisation. En mesurant les transmissions des cellules
environnantes, chaque cellule peut dterminer son retard relatif et le reporter ainsi
que le rapport signal sur interfrence (RSI) la rception des squences de
synchronisation dtectes au RNC qui les utilise pour ajuster les horloges de
chaque cellule et atteindre la prcision de synchronisation requise. Les Node B
tant grossirement prsynchroniss par leur RNC, la squence de synchronisation
de cellule est reue avec une incertitude temporelle de l'ordre de quelques trames
radio.
3.6.3.2. Phase de maintien de la synchronisation

Dans la phase de maintien de la synchronisation, le rseau supporte du trafic
utilisateur, le mcanisme est conu de manire ne pas gnrer d'interfrences
avec le trafic existant. Les diffrentes cellules d'un RNS utilisent la mme
squence de synchronisation de base mais sont diffrencies par l'application de
dcalages de la squence diffrents. Le RNC dcide quelles sont les cellules qui
doivent transmettre et lesquelles doivent couter et leur communique
respectivement tous les paramtres de transmission, savoir l'instant de
transmission, la puissance de transmission, le code de base, le dcalage
appliquer et les paramtres de rception (code de base et dcalages de code
mesurer dans un IT donn). La drive d'horloge maximale corriger est de
quelques ps. De plus un dcalage supplmentaire de l'ordre de 10-20 ps d au
temps de propagation et au profil du canal doit tre pris en compte.
3.6.3.3. Squences de synchronisation des Nodes B

Les squences de base utilises sont des squences somplmentaires tendues
concatnes (squences CEC) dcrites dans [JEC 01]. Les squences CEC choisies
pour l'UMTS TDD sont construites partir de paires de codes complmentaires de
Golay, dont la somme des fonctions d'autocorrlation est un Dirac [GOL61],
priodiquement tendues de 128 bits puis concatnes.
Exploite avec un rcepteur adquat ([BUD91], [JEC 01]), la squence CEC

permet d'obtenir une fentre d'analyse de largeur 128 bits qui ne prsente aucun pic
secondaire et dont le pic principal est un Dirac. La taille de cette fentre est
suffisante pour satisfaire les contraintes de dlai de propagation maximum et
d'talement de la rponse impulsionnelle du canal.
Figure 3.24. Construction d'une squence CEC partir d'une paire (s(n), g(n))
de squences complmentaires
Le rcepteur adapt (figure 3.25) corrle dans un premier temps les 1 152
premiers bits du signal reu avec une rplique locale de s(n), les 128 premiers bits
parmi les 1 152 bits correspondant s(n) tant supprims. La corrlation avec g(n)
est ensuite ralise de la mme manire sur les 1 152 derniers bits reus. En
supprimant les 128 premiers bits, toute intercorrlation indsirable entre s(n) etg()
due un canal multitrajet dont la longueur de la rponse impulsionnelle est
infrieure 128 bits est vite. Finalement, la somme des autocorrlations est
obtenue aprs addition des rsultats obtenus lors des 2 premires tapes. Pour faire
fonctionner ce rcepteur, il est ncessaire d'tre dans un tat prsynchronis avec
une prcision minimale de 64 bits, ce qui est le cas puisque ce rcepteur n'est
utilis que dans la phase de maintien de la synchronisation. La synchronisation
initiale est effectue par simple corrlation sur une squence unique.
Figure 3.25. Rcepteur pour squences CEC

De plus, une famille de 8 squence dcales, en fait constitues partir de

versions dcales cycliquement (par pas de 128) d'une mme paire de squences
complmentaires peut tre construite partir de chaque paire complmentaire. Du
fait des proprits de complmentarit des codes de base, les squences de cette
famille sont orthogonales entre elles pour tout retard infrieur 64 bits et sont
traites simultanment par le mme rcepteur (caractris par les squences s(n) et
g(n) quel que soit le dcalage cyclique qu'elles aient subies). Les huit dcalages
possibles par squence CEC de base permettent d'assurer l'interoprabilit entre les
Node B dans une zone de dploiement TDD.
Une somme d'autocorrlation typique, obtenue pour le cas ou 3 squences CEC

diffrentes issues de la mme paire de squences complmentaires (de dcalages 0,
256 et 512 bits) sont transmises simultanment est reprsente sur la figure 3.26.
Figure 3.26. Somme d'autocorrlation pour 3 squences CEC orthogonales

(dcalages 0, 256 et 512 bits) transmises simultanment
Dans le cas o l'utilisation simultane de squences CEC dcales n'est pas possible,
notamment lors de la phase de synchronisation initiale et dans le cas de plusieurs rseaux
d'oprateurs diffrents oprant dans une mme zone gographique, des codes de
synchronisation diffrents peuvent galement tre drivs de 8 paires de codes
complmentaires de Golay diffrentes choisies pour leurs proprits de inter corrlation.
3.7. Annexe : modlisation du canal radio mobile
Le canal radio mobile UMTS est typiquement un canal multitrajet dispersif et

slectif en frquence (voir paragraphe 1.2.3.2). Il est modlis par une somme de
trajets retards dont les dlais et les puissances moyennes caractrisent le contexte
gographique (environnement urbain ou rural) et dont les variations d'amplitudes
complexes caractrisent la mobilit. Chacun de ces trajets rsulte lui-mme d'une
somme de microtrajets prsentant des dlais quasi identiques et des attnuations
complexes alatoirement distribues selon une loi gaussienne borne en frquence
par le spectre Doppler. Cette loi gaussienne est centre s'il n'y a pas de microtrajet
direct. Il en rsulte que le module de chacun des trajets obit dans le temps une
distribution de Rayleigh (en l'absence de microtrajet direct) ou de Rice avec un
temps de cohrence dpendant de la mobilit (frquence Doppler).
La rponse impulsionnelle du canal est donc exprime comme une somme

pondre d'impulsions de Dirac de poids complexes hk{t) variant dans le temps.
Dans ce chapitre, les simulations ont t ralises sur le canal Case 3. Il s'agit
d'un canal de test dfini par le 3GPP [25.105] et correspondant un canal multitrajet
rponse impulsionnelle courte et forte mobilit (vitesse de dplacement jusqu'
120 km/h).
Tous les trajets ont un spectre Doppler classique
Tableau 3.4. Paramtres du canal 3GPP-Case 3 ( Vitesse = 120 km/h)

3.8. Bibliographie
[25.922] 3GPP TR 25.922, Radio resource management stratgies .

[25.221] 3GPP TR 25.221, Physical channels and mapping of transport channels onto
physical channels (TDD) .
[25.222] 3GPP TR 25.222, Multiplexing and channel coding (TDD) .
[25.223] 3GPP TR 25.223, Spreading and Modulations (TDD) .
[25.224] 3GPP TR 25.224, Physical layer procdures (TDD) .
[25.225] 3GPP TR 25.225, Physical layer measurements (TDD) .
[25.105] 3GPP TR 25.105, Base Station (BS) radio transmission and reception (TDD) .
[ARG 9 9 ] ARGYROPOULOS Y . , JORDAN S., KUMAR S., Dynamic Channel Allocation in
Interference-Limited Cellular Systems with Uneven Traffic Distribution , IEEE Transactions
on Vehicular Technology, vol. 48, n 1, 1999.
[ B U D 9 1 ] BUDISIN S . Z . , Efficient puise compressor for Golay complementary sequences ,
Electronics Letters, vol. 27, n 3, p. 219-220, 1991.
[ERI 99] Ericsson, New RACH preambles with low auto-correlation side-lobes and reduced
detector complexity , 3GPP TSG RAN RI-99-0205 (disponible l'adresse
http://www.3gpp.org/).
[ G O L 6 1 ] GOLAY M.J.E., Complementary Sris, IRE Trans. on Information Theory,
Vol IT-7, p.82-87, 1961.
[ H A A 0 0 ] HAARDT H . , KLEIN A . , KOEHN R . , OESTREICH S . , PURAT M . , SOMMER V . , ULRICH
T., The TD-CDMA Based UTRA TDD Mode, IEEE Journal on Selected Areas in
Communications, vol. 18, n 8, 2 0 0 0 .
[HAY 96] HAYKIN S., Adaptive filter theory, Prentice Hall, 1996.
[ H O L 00] HOLMA H . , HEIKKINEN S., LEHTINEN O . , TOSKALA A., Interference Considrations
for the Time Division Duplex Mode of the UMTS Terrestrial Radio Access , IEEE Journal
on Selected Areas in Communications, vol. 18, n 8, 2000.
[JEO 0 0 ] JEON W . S . , . J E O N G D.G, Comparison of Time Slot Allocation Stratgies for
CDMA/TDD Systems , IEEE Journal on Selected Areas in Communications, vol. 18, n 7,
2000.
[KLE 94] KLEIN A., KALEH G.K., BAIER P.W., Equalizers for multi-user dtection in code
division multiple access mobile radio systems , IEEE 1994.
[MOT 99] Motorola, Complexity of Multiple channel estimations at the SU , 3GPP-
TSGR1 #4(99)389 (disponible l'adresse http://www.3gpp.org/).
[PET 95] PETERSON R . L . , ZLEMER R.E., BORTH D.E., Introduction to Spread Spectrum
Communications, Prentice hall, 1995.
[ P I G 9 9 ] PIGEONNAT Y . Joint dtection for UMTS : complexity and alternative solutions ,
I E E E 1999.
[ R I S 7 3 ] RISSANEN J . Algorithms for Triangular Dcomposition of Block Hankel and

Toeplitz Matrices with Application to Factoring Positive Matrix Polynomials , Mathematics
of Computation, vol. 2 7 , n 1 2 1 , p. 1 4 7 - 1 5 7 , 1 9 7 3 .
[ N O G 0 4 ] N O G U E T D . , BOUYOUD J . P . , ZAGHDOUDI L . , VARREAU D . , JECHOUX B . , L E CORRE
P., LAGRANGE X . , NASREDDINE J . , A hardware testbed for UMTS-TDD joint dtection
baseband receivers , ISSSTA, 2004.
[JEC 0 1 ] JECHOUX B, RUDOLF M Concatenated Extended Complementary Sequences for

Inter-Base Station Synchronisation in UMTS TDD mode , VTC Fall, 2001.
[ S H A 48] SHANNON C.E. A Mathematical Theory of Communication , The Bell System
Technical Journal, vol. 27, p. 379-423 et 623-656, 1948.
[STEI 9 4 ] STEINER B . , JUNG P Optimum and Suboptimum Channel Estimation for the
Uplink of CDMA Mobile Radio Systems with Joint Dtection , IEEE 1994
[ V E R 89] VERDU S. Computational Complexity of Optimum Multiuser Dtection
Algorithmica, vol. 4, p. 303-312, 1989.
Chapitre 4
Le contrle de puissance dans l'UMTS
4.1. Introduction
La technique d'accs multiple CDMA (Code Division Multiple Access) est

utilise depuis les annes cinquante dans des rseaux militaires. Les avantages viss
taient principalement la confidentialit accrue et la rsistance aux brouillages. Le
premier avantage est d l'utilisation d'un code non divulgu et le second
l'talement de spectre. En raison de l'talement de spectre, la puissance d'un
ventuel brouilleur devait tre bien plus leve.
Au dbut des annes quatre-vingt-dix, l'ide de l'utilisation du CDMA pour les

rseaux sans fil civils [GIL91], [LEE 91] commena s'imposer avec comme
nouvel avantage prvu l'augmentation de l'efficacit de l'utilisation du spectre par
rapport aux techniques bases sur le multiplexage temporel TDMA ou F/TDMA,
accs multiple utilis dans GSM. Le premier rseau cellulaire CDMA, appel IS-95,
a t dploy aux Etats-Unis vers le milieu des annes quatre-vingt-dix.
Les rseaux cellulaires adopts comme systmes dits de troisime gnration

(3G) ont pour technique d'accs multiple le CDMA. Dans ce chapitre, nous
commenons par introduire le contrle de puissance d'un rseau cellulaire CDMA
de faon gnrale. Des lments de calcul de capacit sont donns en vue de justifier
l'aspect indispensable du contrle de puissance dans ce type de rseau. Les
Chapitre rdig par Loutfi NUAYMI.

mthodes gnrales de contrle de puissance ainsi que le lien entre ce dernier et

d'autres procdures de gestion des ressources radio sont considres.
Dans la suite, nous dcrivons le contrle de puissance particulier au systme

UMTS-WCDMA, dans ses deux variantes : UTRA-TDD et UTRA-FDD ainsi que
cdma2000. Les spcifications des groupes de normalisation 3GPP (3rd Gnration
Partnership Project, www.3gpp.org) pour WCDMA et 3GPP2 (3rd Gnration
Partnership Project 2, www.3gpp2.org) pour cdma2000 sont utilises pour les
prsentations des contrles de puissance proposs dans le rseau UMTS.
4.2. Prsentation du modle et formalisation du problme
Dans un rseau du type F/TDMA comme GSM, une planification soigne de la

rpartition des frquences porteuses doit tre effectue. Cette planification doit tre
rgulirement remise jour en fonction des volutions du rseau. Cela n'est pas le
cas dans un rseau cellulaire CDMA o toutes les communications utilisent la mme
bande de frquence, la sparation se faisant partir des codes au niveau du
rcepteur. De nouveaux problmes, par rapport aux rseaux F/TDMA, apparaissent.
Une communication donne subit deux types d'interfrences : intracellulaire et

intercellulaire (voir figure 4.1). A titre de comparaison, il est rappel que, dans le
cas de GSM (F/TDMA), il n'est pas possible en thorie d'avoir deux
communications utilisant la mme frquence un instant donn dans la mme
cellule. D'o l'intrt du contrle de puissance et, plus gnralement, d'une gestion
efficace des ressources radio dans un rseau cellulaire CDMA. C'est ce prix que
les rseaux CDMA peuvent avoir une capacit plus grande que celle d'un rseau
bas sur le TDMA.
Dans ce chapitre, nous considrons le modle suivant. La qualit de la rception

est reprsente par le rapport entre l'nergie d'un bit (Eb) et la densit spectrale de
puissance du bruit (N0), not Eh/N0 [VIT 95]. Ce dernier est directement li au taux
d'erreur binaire (BER, Bit-Error Rate), l'indicateur direct de la qualit de
communication de la couche physique. Le rapport signal sur bruit reu (SIR, Signal-
to-Interference Ratio) est une grandeur physique plus accessible. En effet, le
rcepteur peut estimer la puissance du signal utile reu et celle du bruit en vue de
dduire le SIR. Le rapport EJNoest li au SIR par la relation suivante :
[4.1]
Le contrle de puissance dans 1 ' U MTS 161
o R est le dbit binaire de donnes du signal numrique en bit/s et W la bande

de frquence, en Hz, occupe aprs talement du signal.
Comme toutes les communications utilisent la mme bande de frquence, une communication
donne subira des interfrences des autres communications dans sa cellule {intra-cell
interference) ainsi que celles des communications des autres cellules (inter-cell ou other-cell
interference).
Figure 4.1. Illustration des interfrences dans un rseau cellulaire CDMA

(cas de la voie montante)
La valeur de EJNQ correspondant au seuil de qualit requis, appele valeur-seuil

dans la suite, dpend des paramtres de la transmission (type de modulation, de
codage), de ceux du canal radio (multitrajets, retards, variations du canal) et de ceux
du rcepteur (type d'galiseur,...). Les valeurs usuelles de ce seuil se situent entre 3

et 8 dB.
Le SIR est le rapport de la puissance utile reue, note C, sur le bruit total reu,
not N. Le bruit reu est la somme de l'interfrence note / et du bruit intrinsque de
rception, dit bruit thermique, not N0. Le SIR reu s'crit alors :
Si nous exprimons / comme la somme de l'interfrence intracellulaire ou interne

la cellule, notee Imt et celle intercellulaire ou externe la cellule, note , nous
pouvons crire :
[4.1a]
Dans le cas o les signaux d'une mme cellule sont orthogonaux, l'interfrence
interne la cellule est multiplie par un facteur a, avec a compris entre 0 et 1. Si
l'orthogonalit est parfaite, le coefficient a est gal 1. Pour le calcul du SIR, la
formule [4.1 a] doit alors tre remplace par la formule suivante :
[4.1b]
Les signaux de la voie descendante (downlink, de la base vers les mobiles)

subissent le mme trajet entre une base et un mobile donns. Cela permet de
prserver, jusqu' un certain degr, l'orthogonalit entre les canaux d'une mme
base. Le facteur a de la relation [4.1b] sera donc non ngligeable. Par suite, le
rapport Eb/N0 calcul avec la relation [4.1], o le SIR est calcul avec la relation
[4.1a] sera infrieur sa valeur relle. Le fait d'utiliser la relation [4.1a] pour le
calcul du SIR permet d'viter d'estimer a, ce qui n'est pas simple faire, quitte
adopter une approche pessimiste.
Dans le cas de la voie montante (uplink, des mobiles vers la base), les signaux
suivent des trajets diffrents. Il n'y a pas d'orthogonalit et la relation [4.1a] est
raliste. On cherche plutt avoir une faible corrlation en remplacement de
l'orthogonalit entre les diffrents canaux.
L'interfrence intracellulaire et intercellulaire est la limite la plus importante au

nombre de communications simultanes. Il en rsulte que, pour les deux sens de la
communication, un contrle de puissance efficace est ncessaire pour augmenter la

capacit du rseau.
4.2.1. Capacit et contrle de puissance dans un rseau cellulaire CDMA
Pour les rseaux o le dbit de donnes est le mme dans les voies montante et
descendante, dits dbits symtriques, la voie montante est la plus contraignante
en ce qui concerne la capacit [VIT 95]. Cela est d au problme dit de l'effet
proche-lointain (near-far effect), illustr dans la figure 4.2 et dcrit dans la suite.
Au cas o tous les mobiles mettent avec la mme puissance, c'est--dire en
l'absence de contrle de puissance, un mobile proche de la frontire de la cellule
est reu avec une puissance bien plus petite qu'un mobile proche de la base. Ainsi
le mobile le plus loign risque d'tre noy dans le signal du mobile proche. Le
contrle de puissance doit aussi tenir compte des interfrences venant des autres
cellules.
A partir de la valeur-seuil de EJNQ et du contrle de puissance appliqu, la

capacit du rseau, reprsente par le nombre maximal de communications
simultanes, peut tre estime. Dans la suite, une estimation simple de la capacit
pour un contrle de puissance idal est propose [VIT 95]. Elle est faite dans le cas
de la voie montante.
Une politique idale de contrle de puissance consiste choisir les puissances

d'mission des mobiles de sorte que ces derniers soient reus avec la mme
puissance sur leur base de correspondance, c'est--dire celle qui les relie la partie
fixe du rseau mobile. Dans [NUA 01], il est dmontr que ce contrle de puissance
est optimal, suivant un certain critre bas sur la qualit de communication.
Pour le calcul suivant, nous considrons, dans une premire tape, une cellule
isole. Nous notons la puissance reue par la base partir d'un mobile 7i0. Nous
considrons que cette puissance reue est la mme pour tous les mobiles sur leur
base correspondante. L'interfrence I reue par la base d'une cellule o K
communications simultanes ont lieu est alors donne par :
[4.2]
Les relations [4.1] et [4.2] ainsi que l'hypothse simplificatrice que toutes les
communications ont le mme dbit de donnes R permettent de dduire la valeur
maximale de K en fonction de la qualit de communication requise :
[4.3]
o la valeur-seuil de EJNQ est note (EtJNr et o l'interfrence des mobiles des

cellules voisines n'est pas prise en compte.
Un des atouts majeurs des systmes CDMA est l'augmentation de la capacit

lors d'une transmission discontinue, cette augmentation tant une fonction simple du
taux moyen d'activit. Si le taux d'activit est not (p, et sachant que le nombre K est
assez lev pour pouvoir appliquer la loi des grands nombres, le ternie de gauche
dans l'galit [4.2] est multipli par (p. Cette augmentation est moins directe pour les
systmes F/TDMA o le nombre d'interfrants proches est plus faible et le calcul de
l'augmentation de capacit est plus complexe.
Au cas o tous les mobiles mettent avec la mme puissance (absence de contrle de
puissance), un mobile proche de la frontire de la cellule est reu avec une puissance bien
plus petite qu'un mobile proche de la base.
Figure 4.2. Effet proche-lointain (near-far effect)

On utilise dans la suite :
appel le gain d l'activit de la voix dans la relation [4.3]. Son ordre de

grandeur est autour de 2.
La sectorisation de la station de base et l'isolation spatiale qui en rsulte

introduit un deuxime facteur de gain, not GA. Pour une antenne trisectorielle, GA
devrait tre gal 3 en valeur relle. [LEE 91] estime que des pertes de ldB,
quivalentes un coefficient de 0,8, font passer cette valeur 2,4 en valeur relle.
Enfin, si on suppose que K est assez lev par rapport 1, la relation [4.3] devient :
[4.4]
Considrons maintenant un rseau plusieurs cellules. L'interfrence due aux

cellules voisines est prise en compte par un facteur/ reprsentant le rapport de cette
interfrence, souvent appele other-cell interference, sur l'interfrence interne la
cellule. Ce paramtre dpend du modle de canal radio considr. Des calculs de /
sont proposs dans [COR 98] et [VIT 94]. Un ordre de grandeur de/pour les canaux
usuels est 0,6.
On rcrit alors la relation [4.2] :
[4.5]
La relation [4.4] permet ensuite d'avoir une estimation de la capacit d'une

cellule :
[4.6]
Application numrique : si on prend les valeurs usuelles suivantes GV = 8/3 ;

GA = 2A', /= 0,6 ; (ET,/NO)T=5 (7dB), on peut constater que pour un contrle de
puissance idal, le facteur d'talement (W/R) peut tre pris comme valeur maximale
du nombre de communications simultanes dans une cellule.
L
Nous notons ce stade que ce calcul ne tient pas compte des imperfections
invitables du contrle de puissance (voir paragraphe 4.8), ni d'autre phnomnes
importants comme les variations alatoires dans un rseau cellulaire, les canaux de
contrle, etc. Cependant, [4.6] permet d'avoir une ide du nombre maximal de
mobiles dans une cellule de rseau CDMA.
En l'absence du contrle de puissance, tous les mobiles mettent la mme

puissance. Dans ce cas, les simulations permettent de vrifier que la capacit du
rseau est beaucoup plus petite.
Pour les rseaux cellulaires CDMA dbits symtriques, la voie descendante

est moins contraignante au niveau capacit que la voie montante. La capacit de
la voie descendante a t moins tudie jusqu' prsent. Un exemple de ce type
de calcul est propos dans [LEE 91]. Dans les rseaux o les donnes transmises
auront une part importante (par exemple Internet), la voie descendante aura un
dbit moyen suprieur celui de la voie montante, ce qui fait de la voie
descendante le sens le plus contraignant au niveau de la limitation de la
capacit.
4.2.2. Classification des mthodes de contrle de puissance proposes
Plusieurs classifications sont proposes pour le contrle de puissance des rseaux

mobiles.
4.2.2.1. Contrle de puissance utilisant la puissance ou la qualit reue

On distingue d'une part les contrles de puissance bass sur le niveau de
puissance reue (RxLev ou Rx) et d'autre part ceux bass sur la qualit reue
(RxQual). La qualit de rception correspond au taux d'erreur binaire (BER, Bit-
Error-Rate ). Dans les systmes numriques, le BER de rception est directement li
au rapport signal sur bruit reu ou SIR (voir plus haut). L'estimation de RxQual
passe donc souvent par celle du SIR reu.
Comme l'objectif premier est de garantir une certaine qualit de

communication, les contrles de puissance bass sur le RxQual auront de
meilleures performances que ceux bass sur le RxLev. En contrepartie,
l'estimation de la qualit reue peut tre entache d'erreur. Il peut en rsulter une
dgradation du contrle de puissance.
4.2.2.2. Contrle de puissance distribu ou centralis

Une autre distinction peut tre faite entre le contrle de puissance distribu et celui
centralis. Dans un contrle de puissance distribu, la mise jour de la puissance
mise dans chaque lien est dcide par un lment donn, gnralement le rcepteur de
ce lien. A l'oppos, un organe central, effectuant un contrle de puissance centralis,
dispose des informations ncessaires sur tout le rseau et pourra assigner les
puissances mises tous les metteurs concerns. Un tel organe central ayant des
informations sur tous les canaux radio ne peut pas exister en pratique. Le contrle de
puissance centralis ne peut avoir qu'un intrt thorique, par exemple pour estimer la
performance optimale, pour un critre donn, d'un rseau mobile.
La distinction entre ces deux concepts peut tre retrouve dans deux articles de
Zander, considrs actuellement comme des classiques du sujet en raison du nombre
de publications postrieures qui y font rfrence et qui en ont utilis le modle
matriciel. Dans [ZAN 92], l'auteur propose un contrle de puissance centralis et il
montre qu'il a des performances proches d'un contrle de puissance optimal, le
critre tant la minimisation du taux de coupure du rseau. Zander propose dans la
suite un contrle de puissance distribu dans [ZAN 92a], appel DPC (Distributed
Power Control), et montre qu'il a des performances proches de celles de
l'algorithme propos dans le premier article.
Le principe gnral d'un contrle de puissance distribu bas sur la qualit reue
est illustr dans la figure 4.3.
Le rcepteur estime le rapport signal sur bruit (RSB) reu, not, y,. Cette valeur est transmise
au rcepteur qui l'utilise pour dduire la puissance mettre.
Figure 4.3. Schma de principe du contrle de puissance bas sur le niveau de qualit reue.
4.2.2.3. Boucles de contrle de puissance

En vue de mettre en uvre un contrle de puissance distribu, une boucle de
contrle est souvent utilise. Les considrations classiques des boucles de contrle,
galement appeles boucles d'asservissement, sont alors applicables. Il est alors
possible de considrer une boucle ouverte, c'est--dire sans retour d'information, ou
une boucle ferme.
Dans une boucle ouverte (voir figure 4.4), l'hypothse que le gain du canal radio
est le mme dans les deux sens est ncessaire. En effet, si le mobile doit tre reu
avec une puissance 7io sa station de base de correspondance, ce dernier doit
disposer de l'information sur le gain du canal radio entre le mobile et la base, not
Gmb. La valeur de la puissance d'mission du mobile, note P est alors donne par
la relation suivante :
Pour estimer Gmb, le mobile commence par estimer Gbm, le gain de liaison entre
la base et lui. La valeur de Gbm est donne par la relation suivante :
o Pb est la puissance mise la base, connue par le mobile, et Prb est la

puissance reue par le mobile et mesure par ce dernier. L'hypothse Gbm = G,b
permet de calculer la puissance d'mission du mobile en fonction de termes connus
ou mesurs :
Malheureusement, le gain de liaison est rarement le mme dans les deux sens de
communication car la frquence ou le temps ne sont pas identiques. Une autre
explication de la diffrence est la prsence des trajets multiples. En consquence, la
boucle ouverte est seulement utilise lors de l'accs initial (voir la suite de ce
chapitre). Le reste du temps, une boucle ferme ou, autrement dit, un retour
d'information est indispensable.
Le retour d'information peut tre analogique (par exemple, valeur du gain Gmb)
ou numrique (un ou plusieurs bits donnant une information sur le gain du canal ou
un ordre direct pour la puissance mise), ce qui donne une boucle de contrle
analogique ou numrique. Les systmes 3G utilisent des boucles fermes
numriques uniquement.
Mobile
Dans le but d'tre reu avec une puissance donne la station de base, le mobile estime le
gain du canal radio entre la base et lui, not Gf,m, et considre que le gain est le mme dans
l'autre sens.
Figure 4.4. Contrle de puissance en boucle ouverte
Les paramtres classiques des boucles d'asservissement doivent alors tre mis au
point, savoir : priode de mise jour de la boucle (variation rapide du canal radio),
nombre de bits du retour d'information, protection contre les erreurs de ce dernier,
etc. Les paramtres de l'asservissement sont choisis en fonction de l'environnement
du systme mobile considr : caractristiques du canal radio, type de donnes
transmises, etc.
Un contrle de puissance simple, parfois appel Bang-Bang, consiste

transmettre un bit d'information, ventuellement rpt pour augmenter son
immunit face aux erreurs de transmission, chaque mise jour de la boucle. Ce bit
indique l'metteur d'augmenter ou de diminuer la puissance mise d'une valeur
constante fixe l'avance, suivant que la qualit reue est infrieure ou suprieure
un seuil requis. En pratique, la valeur fixe de la variation est de l'ordre de 1 dB (voir
paragraphe 4.5).
V*. '
Boucle interne (inner loop)
Boucle externe (external loop)
Figure 4.5. Principe gnral du contrle de puissance par boucle externe et boucle interne
Nous montrons dans [NUA 01] que si les paramtres du contrle de puissance
un bit d'information (priode de mise jour, pas de puissance, protection contre les
erreurs de transmission) sont correctement slectionns, ce dernier peut avoir des
rsultats proches du DPC rappel au dbut de ce paragraphe et par suite avoir des
performances proches de celles considres optimales.
Il peut tre avantageux d'utiliser une double boucle de contrle de puissance.

Cela est le cas dans les systmes de rseaux cellulaires de troisime gnration. Le
schma de principe des boucles de contrle de puissance de ces rseaux est
reprsent dans la figure 4.5.
La boucle interne est celle dcrite prcdemment. Son but est d'asservir le
rapport signal sur bruit SIR reu une valeur-seuil fixe (SIRTarget)- Cette valeur-
seuil est fonction du taux d'erreur binaire BER qui doit tre ralis. La relation
entre SIR et BER est fonction des caractristiques de modulation, de codage et
aussi du canal radio (nombre de trajets multiples, etc). Or les communications
dans un rseau cellulaire utilisent des canaux radio diffrents. La boucle de
contrle externe calcule la valeur seuil au lieu de prendre la mme valeur pour
toutes les communications, ce qui reviendrait prendre la valeur la plus
pessimiste. Cela permet de diminuer les interfrences dans un rseau et par suite
permet d'avoir une plus grande capacit.
M
Boucle externe (external loop)
Figure 4.5. Principe gnral du contrle de puissance par boucle externe et boucle interne
Nous montrons dans [NUA 01] que si les paramtres du contrle de puissance
un bit d'information (priode de mise jour, pas de puissance, protection contre les
erreurs de transmission) sont correctement slectionns, ce dernier peut avoir des
rsultats proches du DPC rappel au dbut de ce paragraphe et par suite avoir des
performances proches de celles considres optimales.
Il peut tre avantageux d'utiliser une double boucle de contrle de puissance.

Cela est le cas dans les systmes de rseaux cellulaires de troisime gnration. Le
schma de principe des boucles de contrle de puissance de ces rseaux est
reprsent dans la figure 4.5.
La boucle interne est celle dcrite prcdemment. Son but est d'asservir le
rapport signal sur bruit SIR reu une valeur-seuil fixe (SIRTarget). Cette valeur-
seuil est fonction du taux d'erreur binaire BER qui doit tre ralis. La relation
entre SIR et BER est fonction des caractristiques de modulation, de codage et
aussi du canal radio (nombre de trajets multiples, etc). Or les communications
dans un rseau cellulaire utilisent des canaux radio diffrents. La boucle de
contrle externe calcule la valeur seuil au lieu de prendre la mme valeur pour
toutes les communications, ce qui reviendrait prendre la valeur la plus
pessimiste. Cela permet de diminuer les interfrences dans un rseau et par suite
permet d'avoir une plus grande capacit.
Un des principes de base de l'automatique est que, dans le cas de deux boucles
d'asservissement imbriques, la boucle interne doit tre bien plus rapide que la
boucle externe. Comme ordre de grandeur, le temps de monte de la boucle interne
doit tre de l'ordre de dix fois plus petit que celui de la boucle externe. On pourra
vrifier que cette hypothse est vrifie dans les systmes 3G dans la suite de ce
chapitre. La boucle interne est d'ailleurs souvent appele contrle de puissance
rapide {fast power control).
4.3. Contrle de puissance et autres fonctions de la gestion des ressources radio
Dans un rseau mobile, la procdure de contrle de puissance ne peut tre

dissocie des autres procdures de gestion de ressources radio. Cela est d'autant plus
vrai dans les rseaux mobiles accs multiple CDMA, o la capacit est souvent
limite uniquement par l'interfrence et non par le nombre de canaux disponibles
comme dans le cas de GSM. La gestion de ressources radio dans un rseau cellulaire
est illustre dans la figure 4.6.
4.3.1 .Accs et contrle d'admission
Le contrle d'admission est intimement li au contrle de puissance. En effet, la

dcision sur l'admission doit respecter les contraintes suivantes :
- u n mobile dont l'admission aboutirait un rseau impossible contrler en
puissance doit tre refus. Un rseau est dit impossible contrler en puissance
lorsqu'il n'existe pas de rpartition de puissances mises telle que tous les objectifs
de qualit sont atteints. Si ce mobile tait accept, il faudrait alors, pour diminuer
l'interfrence globale, interrompre une communication, ventuellement diffrente de
celle du nouvel arrivant ;
- un mobile dont l'admission aboutirait un rseau qu'il est toujours possible de
contrler en puissance ne doit pas tre refus.
On peut remarquer que l'interruption d'une communication en cours est plus

gnante que le refus de communication du point de vue des usagers.
Plusieurs algorithmes de contrle d'admission sont proposs pour les rseaux

CDMA. Ils sont rappels dans [NUA 00], o ils sont rpartis sur trois groupes : ceux
bass sur le niveau d'interfrence, ceux bass sur l'estimation du nombre maximal
de communications simultanes et ceux bass sur la prvision de la possibilit de
ralisation du contrle d'admission aprs ventuelle admission du ou des nouveaux
venus.
Pour un mobile qui souhaite commencer une communication, un contrle de

puissance doit tre dfini pour la priode de temps o la communication est en cours
d'tablissement, en plus de celui ayant lieu durant la communication.
Figure 4.6. Gestion des ressources radio dans un rseau mobile
Dans le cadre du contrle d'admission, le dbit de donnes doit tre slectionn.

Dans le cas o le rseau ne peut assurer le dbit de donnes souhait, un dbit plus
faible sera choisi. Il faut ventuellement vrifier que ce dbit impos n'est pas
infrieur au dbit minimal du mobile ou du service considr. Un dbit plus bas
permet d'avoir un objectif de SIR plus faible, voir relation [4.4].
4.3.2. Respiration de cellules
Une faon simple et raisonnablement efficace de choisir une station de base de

correspondance pour un mobile consiste prendre celle dont le signal pilote est le
mieux reu par ce dernier. En prenant la station de base avec le meilleur signal
pilote et si on suppose que cette dernire est la plus proche d'un mobile donn, nous
obtenons alors des cellules symtriques, de formes hexagonales, suivant le modle
classique des rseaux cellulaires [LAG 00].
Cependant, en pratique, la station de base ayant le signal pilote le mieux reu par
un mobile donn n'est pas ncessairement la plus proche en raison des obstacles qui
peuvent exister entre un mobile et les stations de base. Les cellules auront donc des
formes alatoires tout en restant proches du modle hexagonal.
Une faon plus efficace de choisir la station de base pour chaque mobile consiste
le faire suivant des critres autres que celui du signal reu. Il est plus efficace de
choisir la station de base de correspondance de chacun des mobiles actifs de faon
avoir une meilleure capacit globale, chaque instant. On peut remarquer que, si ce
principe est appliqu, un mobile se trouvant une position gographique donne
peut appartenir une cellule qui n'a pas le meilleur signal dans sa position.
Autrement dit, les cellules changent de surface de manire s'adapter la charge de
trafic du rseau.
Dans deux articles [HAN 95] et [YAT 95], publis indpendamment et en mme
temps, l'association du choix de la station de base la gestion des ressources radio
est propose pour augmenter la capacit d'un rseau mobile. En raison de la
variation dynamique de la surface des cellules qui en rsulte, l'appellation de
respiration de cellules (cell breathing) a t propose pour ce concept d'optimisation
du choix de la station de base de correspondance [HAN 95]1.
Figure 4.7. Utilit de la respiration de cellules
En vue d'illustrer le principe de la respiration de cellules, nous considrons que

la station de base avec le meilleur signal pilote est la plus proche. Un exemple
simple de l'utilit de la respiration de cellules est donn dans la figure 4.7. Comme
1. Le terme respiration de cellules dans les rseaux de communications cellulaires a d'autres

comprhensions possibles.
la cellule de droite est beaucoup plus charge que celle de gauche, si le mobile qui
est dans la premire tout en tant proche de la frontire est rattach la cellule de
gauche, le niveau global d'interfrence baisse. Une baisse de l'interfrence globale
est quivalente une augmentation de la capacit dans un rseau cellulaire CDMA.
Dans le cadre de la respiration de cellules, la slection de station de base est

associe au contrle de puissance. En rsum, l'algorithme DPC dj introduit dans
ce chapitre est gnralis de faon choisir, chaque itration, la station de base qui
minimise la puissance mise calcule par la version initiale du DPC en plus de cette
puissance mettre.
4.3.3. Contrle de puissance et soft handover
Le soft handover est l'tat o un mobile est rattach deux ou plusieurs stations
de base. Le soft handover a de nombreux avantages : amlioration de la qualit de
communication des mobiles frontaliers, diminution de la probabilit de coupure lors
d'un handover, etc. Il reprsente un des intrts majeurs du CDMA. Dans certaines
configurations, le soft handover peut tre un tat stable si le mobile reste dans une
zone frontalire.
Dans la voie montante, la procdure de contrle de puissance d'un mobile peut

envoyer deux ordres contradictoires de deux stations de base diffrentes. Par
exemple, une station envoie un ordre d'augmentation de la puissance au mobile
alors qu'une autre lui envoie un ordre de diminution. En effet, les stations de base
envoient leur ordres indpendamment. Dans ce cas, le mobile applique l'ordre qui
aboutit une puissance de transmission minimale. Cela permet de ne pas augmenter
inutilement l'interfrence globale tout en garantissant la qualit de communication
requise, puisqu'au moins l'une des stations de base a son ordre excut.
4.4. Le contrle de puissance dans les systmes 3G
Le contrle de puissance du systme cellulaire de deuxime gnration GSM,

qui est un systme F/TDMA, est moins complexe que celui des systmes 3G, qui
sont du type CDMA. Le contrle de puissance de GSM est dcrit dans [LAG 00].
Dans la partie restante de ce chapitre, nous donnons des lments sur le contrle de
puissance des systmes UTRA-FDD et cdma2000. Ces deux rseaux CDMA ont
chacun un contrle de puissance respectant les principes gnraux rappels dans la
premire partie de ce chapitre. Au niveau de ce chapitre le contrle de puissance du
systme WCDMA est dcrit plus longuement que celui de cdma2000. Pour des
dtails spcifiques sur un contrle de puissance donn, le lecteur est invit se

reporter aux spcifications rfrences dans ce chapitre.
Erreur de trame? 0: augmenter SIRT de Kc6 dB

N: baisser SIR, de dB
Figure 4.8. Contrle de puissance des systmes 3G
Le principe gnral commun du contrle de puissance de ces systmes est

reprsent dans la figure 4.8. Un contrle de puissance combinant deux boucles
fermes est utilis en mme temps qu'un contrle boucle ouverte. Ce dernier est
souvent rserv l'accs initial, o il n'y a pas de retour. Dans la figure 4.8, deux
exemples particuliers de contrle de puissance sont utiliss :
- boucle interne de contrle de puissance ;
- boucle externe de contrle de puissance.
La boucle interne, servant l'asservissement du SIR, est pratiquement toujours

une boucle un bit d'information. Nous avons aussi reprsent dans la figure 4.8
un exemple de boucle externe, servant l'asservissement du FER (Frame Error
Rate, taux d'erreur de trame) en utilisant un paramtre Kc. Le lecteur peut vrifier
que, en rgime permanent, la valeur ralise de FER s'exprime de faon simple en
fonction de Kc :
quelle que soit la valeur de choisie.

4.5. Contrle de puissance en UTRA-FDD
4.5.1. Principes gnraux
L'UTRA (UMTS Terrestrial Radio Access), le systme d'accs radio de UMTS-

WCDMA, dtaill dans les spcifications du consortium 3GPP, a deux variantes :
UTRA-FDD (Frequency-Division Duplexing) et UTRA-TDD (Time-Division
Duplexing) suivant que les deux sens de communication (voie montante et voie
descendante) utilisent chacun une partie du spectre ou tout le spectre mais des
intervalles de temps diffrents [HOL 02].
Le contrle de puissance de UTRA-FDD est dcrit dans la spcification TS

25.214 du consortium 3GPP [25214]. Certains dtails supplmentaires sur la mise en
uvre peuvent tre trouvs dans la TS 25.211. D'autres spcifications contiennent
des dtails supplmentaires sur le contrle de puissance de UTRA-FDD.
4.5.1.1 Boucle interne de contrle de puissance

La trame des canaux physiques ddis de la voie descendante ( trame radio
downlink ) du UTRA-FDD est reprsente dans la figure 4.9. Une trame est forme
de 15 TS {Time Slots, intervalles de temps). La dure d'une trame est 10 ms. Chacun
des TS contient une information binaire appele TPC (Transmission Power Control)
et ralisant le contrle de puissance de la boucle interne de la figure 4.8. Cela
correspond un dbit de contrle de puissance de 1 500 bit/s.
Cette information binaire peut tre transmise sur plusieurs bits. En effet, pour
augmenter l'immunit face aux erreurs de transmission, le bit de contrle de
puissance peut tre rpt une fois dans les trames de la voie montante (voir
figure 4.9, NTPC = 1 ou 2). Le lecteur attentif sait prsent que cette information
binaire transmise sur la voie montante reprsente les informations du contrle de
puissance de la voie descendante. A son tour, le bit de contrle de puissance
transmis sur la voie descendante peut tre rpt 1, 3 ou 7 fois (.NTPC = 2, 4 ou 8).
La boucle interne de contrle de puissance se trouve dans le nud B pour le

contrle de puissance de la voie montante. Le nud B (station de base) dcide,
partir de la qualit reue du signal de la voie montante de chaque mobile si un ordre
d'augmentation ou de diminution de puissance doit tre envoy ce dernier.
La valeur de base du pas de variation de la puissance est de 1 dB (ou 25 %).
D'autres valeurs de ce pas, toujours de l'ordre de 1 dB peuvent tre utilises (voir
ci-dessous). Nous avons tudi les consquences de l'utilisation d'un pas de contrle
de puissance adaptatif dans [NUA 02]. La variation dynamique de ce pas, en accord
avec la vitesse de convergence du contrle, permet d'avoir une petite augmentation

de la capacit d'une cellule CDMA.
One radio frame, T f = 10 ms
Figure 4.9. Trame des canaux physiques ddis de la voie descendante

( trame radio downlink ) du UTRA-FDD {figure extraite de TS 25.211)
Le contrle de puissance rapide est prvu pour les canaux de donnes (voies
montante et descendante) ainsi que certains canaux de contrle.
4.5.1.2. Boucle externe de contrle de puissance

La boucle externe dtermine de faon dynamique l'objectif de qualit raliser
(le SIRTarget) pour la boucle interne de contrle de puissance (voir figure 4.8). Ce
contrle est ralis dans le S RNC (Serving RNC) pour le contrle de puissance de la
voie montante. Pour la voie descendante, c'est aussi le SRNC qui dtermine
l'objectif de qualit en se basant sur le rapport de qualit remont par le UE
[CAS 02]).
4.5.1.3. Contrle de puissance et soft handover

Dans l'tat de soft handover, une station mobile est en liaison avec deux stations
de base (nud B ou Node B) pour sa communication en voie descendante, en voie
montante ou pour les deux voies. Le problme du contrle de puissance durant l'tat
de soft handover est diffrent pour chacun des deux sens de communication.
Pour la voie montante d'un mobile en tat de soft handover, le signal mis par la
station mobile est reu par deux ou plusieurs stations diffrentes. Il est donc
possible, un instant donn, que toutes ces stations n'envoient pas le mme ordre de
contrle de puissance (+1 ou -1). Dans ce cas, il est vident qu'au moins un nud B
demande au mobile de dcrmenter sa puissance d'mission ; le mobile baisse alors

sa puissance du pas de contrle de puissance prvu. Si les commandes sont
unanimes, l'ordre commun est appliqu. Les spcifications de l'UMTS proposent
des rgles plus fines que celles ci-dessus dans le cas o les commandes de contrle
de puissance ne sont pas considres fiables [25.214].
Pour la voie descendante d'un mobile en soft handover, la station mobile reoit
les signaux mis par deux ou plusieurs stations diffrentes. Si les stations de base
concernes mettent jour la puissance prvue pour cette station mobile de faon
indpendante, il existe un risque que les diffrentes puissances d'mission
augmentent ou diminuent de faon incontrle. Ce phnomne est appel power
drifting [HOL 02]. Ce risque est augment avec les erreurs de transmission des
ordres de contrle de puissance. Il est vit grce la centralisation des ordres de
contrle de puissance, c'est--dire les ordres du mobiles, dans un RNC.
4.5.1.4. Contrle de puissance et mode de transmission compress

Le systme UMTS a prvu la possibilit de mesurer les signaux de systmes
diffrents (par exemple, GSM) oprant sur des frquences diffrentes de celle de
l'UMTS. Ces mesures peuvent tre faites pendant des trous de transmission de
donnes prvus dans le cadre du mode appel compressed mode (mode de
transmission compress). Ce mode est possible dans les deux sens de
communication : voie montante et voie descendante.
Dans le cas du mode compress, des mesures doivent tre appliques pour le
contrle de puissance de manire rtablir l'objectif de SIR aprs les trous de
transmission. En effet, durant ces trous de transmission, le contrle de puissance
perd son utilit ainsi que son efficacit. [25.214] propose une nouvelle valeur
l'objectif de SIR utilis dans l'algorithme de contrle de puissance, SIRcm target> SIR
target en mode compress. La valeur de SIRcm target est suprieure SIRT, utilise en
mode normal. Elle est fonction des paramtres du mode compress. Il est galement
possible de prendre un pas de variation de la puissance mise suprieur celle
utilise en mode normal.
4.5.1.5. Contrle de puissance et mode de slection de site (SSDT)

Le mode SSDT {Site Selection Diversity TPC) est un cas particulier de soft
handover. Il peut tre appliqu uniquement pour la voie descendante. Les
informations utilises pour le SSDT sont transmises dans le champ FBI du canal de
contrle de la voie montante DPCCH. Quand le mode SSDT est appliqu, seul le
nud B ayant le meilleur signal au mobile considr (appel primary cell) envoie
son canal de donnes (DPDCH) et son canal de contrle (DPCCH). Les autres
I
nuds B de Y active set mettent uniquement leur canal de contrle. C'est au mobile
de prciser l'UTRAN quel est le nud B de Y active set qu'il reoit le mieux. Un
des avantages possibles du soft handover, la slection du meilleur site (site
selection) est donc ralise par le mobile. L'UTRAN peut aussi utiliser les
informations remontes dans le cadre du SSDT pour le contrle de puissance du
canal de transmission partag PDSCH [25.214].
La station mobile gnrera les commandes de contrle de puissance en voie

montante en se basant sur le signal reu de la primary cell, la seule cellule dans
Y active set qui envoie un canal de donnes.
En ce qui concerne le contrle de puissance de la voie descendante lorsque le

SSDT est appliqu, les procdures du mode normal sont utilises pour la primary
cell ainsi que les autres cellules. Comme prvu dans le SSDT, la transmission est
dsactive dans ces dernires durant les instants rservs au canal de donnes.
4.5.2. La voie montante (uplink)
Le contrle de puissance le plus important est celui qui concerne le canal DPCH,
constitu des canaux DPDCH et DPCCH. Ce dernier reprsente la majorit des
signaux UMTS mis. Le contrle de puissance du canal de contrle (DPCCH) ainsi
que le canal de donnes associ (DPDCH), lorsque ce dernier existe, se font
conjointement. Dans le cas de la voie montante, le DPDCH peut tre dsactiv
durant le mode compress ou lors d'un transmission discontinue (DTX).
4.5.2.1. Contrle de puissance en boucle ferme (ou contrle de puissance rapide)

L'objectif du contrle de puissance en boucle ouverte est donc de raliser
chaque instant l'objectif de SIR, not SIRT (voir figure 4.8). Dans la suite, nous
considrons un mobile en communication avec un nud B. Le cas o le mobile est
en lien avec deux ou plusieurs nud B (soft handover) a dj t dcrit au dbut de
ce paragraphe.
Un rapport de puissance est dfini entre DPDCH et DPCCH. Il est cod sur 4
bits et a donc 16 valeurs possibles. Ce rapport (transmit power offset) est slectionn
par le rseau et, ventuellement, chang par ce dernier. Une fois ce facteur connu, la
mise jour de la puissance mise du DPCCH aura une consquence directe sur celle
du DPDCH.
Le dbit des ordres de contrle de puissance (une information binaire par slot)
est de 1 500 bit/s. Cet ordre est form d'une information binaire (voir ci-dessus). Le
nud B estime le SIR reu du DPCH et gnre cette information de contrle de

puissance qui sera transmise dans le champ TPC de la voie descendante. La valeur
du bit gnr est la suivante :
- s i SIRESR> SIRT, le bit d'information du champ TPC (ordre de contrle de
puissance) est gal 0 ;
- s i SIResl<SIRT, le bit d'information du champ TPC (ordre de contrle de
puissance) est gal 1.
La spcification TS 25.214 (Release 5, mars 2003) ne prcise pas quelle est la

valeur si SIRest = SIRT.
Suivant la valeur de T P C c m d , la puissance d'mission de l'UE est incrmente (TPCcmd = 1),

diminue (TPC cmd = - 1) ou inchange pour chaque time slot de dure 10/15 ms.
Figure 4.10. Principe gnral des algorithmes de contrle de puissance

de la voie montante de l'UMTS
La station mobile (UE) reoit les informations TPC et doit en dduire la

TPC_cmd, commande d'augmentation ou de diminution de la puissance d'un pas fixe,
de l'ordre de 1 dB, pour chaque slot. Cette dcision peut tre faite suivant l'un des
deux algorithmes proposs par le systme UMTS. Un paramtre slectionn par les
couches plus hautes, PC A (Power Control Algorithm), indique l'algorithme
choisir : algorithme 1 ou algorithme 2. Le principe de cette dcision est illustr dans
la figure 4.10.
Dans l'algorithme 1, la puissance d'mission est augmente ou diminue

chaque time slot. Le paramtre TPC_cmd prend la valeur 1 si l'information TPC est 1,
et 1 si l'information TPC est 0.
L'algorithme 2 est une variante de l'algorithme 1 qui permet d'muler des

valeurs plus petites pour le pas de variation de puissance. La puissance d'mission
de la station mobile peut tre incrmente ou diminue une seule fois dans chaque
squence de cinq slots. Une trame UTRA-FDD est dcoupe en trois sries de cinq
slots dans le cadre de l'algorithme 2. Ainsi, TPC_cmd (voir figure 4.10) prend la
valeur 0 pour 4 slots conscutifs et pourra prendre la valeur -1 ou +1 au maximum
trois fois sur une trame donne. Sur le cinquime slot de la squence, TPC_cmd est
dtermine selon les rgles suivantes :
- si les 5 informations TPC de la squence sont gales 1, alors TPC_cmd = 1 ;
- si les 5 informations TPC de la squence sont gales 0, alors TPC_cmd = -\ ;
- dans les autres cas, TPC_cmd = 0.
Dans le cas de soft handover, l'information TPC de chaque slot est dduite
suivant les rgles donnes au dbut de ce paragraphe.
En quelque sorte, l'algorithme 2 est quivalent l'algorithme 1 avec un pas de

puissance plus petit. En effet, pour un pas de variation de puissance, not A, la
puissance d'mission varie de +A ou -A chaque intervalle de temps, avec
l'algorithme 1. Cette puissance variera de +A ou -A tous les cinq intervalles de
temps. On peut alors considrer, ce qui n'est pas entirement rigoureux, que cela est
quivalent une variation de +A/5 ou -A/5 par intervalle de temps.
L'algorithme 2 est plus adapt aux mobiles statiques ainsi que, plus
gnralement, tous les cas o le canal de transmission varie lentement ou pas.
La taille du pas de variation de la puissance est fixe et gale 1 dB pour

l'algorithme 2. Elle est slectionne par l'UTRAN pour l'algorithme 1. Les valeurs
possibles, pour UTRA-FDD, sont 1 et 2 dB [25.331].
Le contrle de puissance de la voie montante ne doit pas aboutir une puissance

d'mission infrieure un minimum autoris ou suprieure un maximum autoris.
Ces valeurs sont donnes dans [25.101]. Cependant, il existe des cas o la puissance
mise par la station mobile peut descendre en-dessous du minimum fix par
[25.101] (voir [25.214]). De plus, les couches plus hautes ont le droit d'imposer des
limites plus strictes que celles donnes par les spcifications.
Notons qu'un contrle de puissance en boucle ferme est dfini pour le canal
PCPCH [25.214], en plus de ceux des canaux ddis des voies montante et
descendante (DPCCH et DPDCH).
4.5.2.2. Contrle de puissance en boucle ferme externe (ou contrle de puissance

lent)
Le contrle de puissance en boucle externe (outer loop power control, voir
figure 4.8) est situ dans le SRNC [25.401]. Ce dernier va fournir l'objectif de SIR
raliser, le SIRT, la boucle interne situe dans le nud B.
Le contrle de puissance en boucle ferme externe est un protocole de niveau 3

(RRC, Radio Resource Control). La spcification TS 25.214 prcise que l'objectif
de SIR est donn par les couches suprieures. Ces derniers appliquent la boucle
externe de puissance mentionne ci-dessus. Cet objectif de SIR peut tre mis jour
toutes les 10 ms [25.302], c'est--dire avec une frquence maximale de 100 Hz. Un
exemple de boucle externe de puissance est indiqu dans la figure 4.8.
4.5.2.3. Contrle de puissance en boucle ouverte

Le contrle de puissance en boucle ouverte est utilis pour l'accs initial de la
station mobile (UE). Ce contrle se base sur les mesures faites par l'UE ainsi que les
informations diffuses par le systme.
Les canaux physiques utilisables en voie montante PRACH et PCPCH sont les
canaux utiliss pour l'accs alatoire des mobiles. Pour utiliser le PRACH, un
mobile choisira alatoirement un slot du PRACH et une puissance initiale donne
par l'UTRAN. Le mobile essaiera nouveau avec une puissance incrmente
chaque fois tant qu'il n'a pas reu une indication confirmant son accs. La puissance
est incrmente par un coefficient impos par la couche RRC, le power ramp step.
La puissance d'mission initiale DPCCH en voie montante est slectionne par

les couches suprieures [25.214], Il s'agit donc, en quelque sorte, d'un contrle de
puissance supplmentaire, en boucle ouverte, donnant la premire puissance
d'mission du mobile avant d'appliquer le contrle de puissance en boucle ferme.
Certains dtails supplmentaires sur le contrle de puissance en boucle ouverte
peuvent tre trouvs dans [25.101].
4.5.3. La voie descendante (downlink)
La figure 4.11 montre l'interfrence entre les liaisons de la voie descendante. On

peut dire que l'objectif du contrle de puissance de la voie descendante sera de
rpartir les puissances de sorte que les mobiles qui sont aux frontires des cellules
ne soient pas trop pnaliss.
Dans la voie descendante, l'orthogonalit est prserve jusqu' un certain degr

(voir section 4.2). En raison des trajets multiples et autres imperfections du canal,
cette orthogonalit n'est donc pas parfaite la rception. Cependant, elle permet la
voie descendante d'avoir des conditions plus favorables que la voie montante. Les
seuils de SIR raliser seront globalement plus faibles.
Le contrle de puissance de la voie descendante de l'UTRA-FDD reprend les

mmes principes que celui de la voie montante (voir plus haut). Certaines variantes
interviennent pour tenir compte des diffrences entre la voie descendante et la voie
montante. Dans ce sous-paragraphe, nous donnons quelques aspects propres au
contrle de puissance de la voie descendante de l'UTRA-FDD, en particulier lorsqu'il
s'agit de paramtres ou procds diffrents de ceux du contrle de puissance de la voie
montante de l'UTRA-FDD dcrit dans le sous-paragraphe prcdent.
4.5.3.1. Contrle de puissance en boucle ferme externe (ou contrle de puissance lent)
Le rapport entre la puissance d'mission du canal ddi de contrle (DPCCH) et
celle du canal ddi de donnes (DPDCH) est dtermin par l'UTRAN. Dans la voie
descendante, ces deux canaux sont multiplexs dans le temps (voir figure 4.9). Les
rapports de puissance des champs TFCI, TPC ainsi que celui des bits pilotes sur la
puissance du champ DPDCH sont les paramtres POl, P02 et P03 (en dB)
respectivement [25.214]. Ces rapports peuvent varier avec le temps.
Figure 4.11. Interfrences dans le cas de la voie descendante d'un rseau cellulaire CDMA
Le mode DPC MODE= 0 est quivalent l'algorithme 1 du contrle de

puissance de la voie montante, c'est--dire que l'information TPC (0 ou 1) est
applique pour la puissance mise en voie descendante, lors de chaque slot. Cette
puissance est alors augmente ou diminue du pas de variation de puissance.
Avec le mode DPC MODE = 1, la puissance d'mission est change une fois
tous les 3 times slots ( 3 x l 0 / 1 5 m s ) . En effet, la station mobile, voyant que
DPC MODE est 1, rpte l'information de TPC (0 ou 1) sur trois slots
conscutifs.
Comme pour la voie montante, le rcepteur, c'est--dire la station mobile, estime

le SIR reu. Il compare ensuite cette valeur estime au SIR seuil (SIR T ) pour dduire
l'information de TPC envoyer dans chaque slot (voir paragraphe 4.5.1).
Un quilibrage de puissance {power balancing) est prvu. Lorsque le pas de

variation de puissance est ajout ou soustrait, un autre terme est ajout la nouvelle
puissance d'mission. La procdure de calcul du terme correspondant au power
balancing est donne dans [25.433].
Un mode limited power increase used (limitation de l'augmentation de la

puissance) peut tre activ. Dans ce cas, un ventuel ordre d'incrmentation de la
puissance d'un pas fixe peut tre inhib et la puissance d'mission en voie
descendante est alors inchange sur le slot. Cette inhibition a lieu quand l'historique
des variations de puissance sur une fentre donne dpasse une limite donne.
Pour finir avec la boucle ferme interne de contrle de puissance de la voie

descendante, il est prvu dans le systme UMTS que l'UTRAN a la possibilit de ne
pas appliquer les commandes TPC de la station mobile dans le cas de congestion ou
dans le cadre d'algorithmes de contrle de puissance autres que les deux proposs
ci-dessus. Comme pour la voie montante, le contrle de puissance de la voie
descendante ne doit pas aboutir, pour un nud B donn, une puissance d'mission
infrieure un minimum autoris ou suprieure un maximum autoris.
4.5.3.2. Contrle de puissance en boucle ferme externe (ou contrle de puissance

lent)
Comme pour la voie montante, un contrle de puissance en boucle externe (outer
loop power control, voir figure 4.8) est appliqu. Il est situ dans le mobile mais le
rseau, c'est--dire le SRNC, peut changer des paramtres. Ce contrle de puissance
va fournir l'objectif de SIR raliser, le SIRT, la boucle interne situe dans le
nud B. Ce contrle de puissance est un protocole de niveau 3 (RRC, Radio
Resource Control).
4.5.3.3. Contrle de puissance en boucle ouverte

Le contrle de puissance en boucle ouverte sur la voie descendante est utilis
pour dterminer la puissance d'mission initiale des canaux ddis en fonction des
mesures remontes par le UE. Comme pour la voie montante, il s'agit donc en
quelque sorte de donner la premire puissance d'mission du mobile avant
d'appliquer le contrle de puissance en boucle ferme.
4.6. Contrle en UTRA-TDD
4.6.1. Rappels sur UTRA-TDD
Le mode UTRA-TDD (Time-Division Duplexing) considre le cas o les

deux voies de communication (montante et descendante) utilisent chacune tout
le spectre allou, des intervalles de temps diffrents (voir chapitre 3). Cela
laisse la possibilit d'avoir une rpartition non symtrique de la bande de
frquence, ce qui peut reprsenter une utilisation plus efficace de cette dernire
dans le cas des transmissions de donnes. Dans la trame de 15 slots sur 10 ms de
UTRA-TDD, n slots seront utiliss pour la voie descendante et 15 - n pour la
voie montante.
Le contrle de puissance de UTRA-TDD est dcrit dans la spcification TS

25.224 du consortium 3GPP [25.224]. Certains dtails supplmentaires sur la mise
en uvre peuvent tre trouves dans la TS 25.221. Des paramtres relatifs aux
contrles de puissance et situs au niveau des metteurs et des rcepteurs, comme
les valeurs minimales et maximales des puissances, le pas de variation des
puissances mises,..., peuvent tre trouvs dans [25.102].
Les canaux physiques ddis (DPCH) ainsi que le canal accs alatoire
(PRACH) sont obligatoirement contrls en puissance [HOL 02].
4.6.2. La voie montante (uplink)
Un contrle de puissance en boucle ouverte est prvu [25.224]. La puissance

d'mission de la base est diffuse par cette dernire. Le mobile peut alors estimer
l'attnuation due la liaison radio (path loss) de la voie descendante (voir
section 4.2 et en particulier la figure 4.4). Cette valeur est suppose gale celle de
la voie montante. Nous la notons Lest.
Chaque mobile calcule et met jour sa puissance d'mission en fonction du gain de liaison estim.
Figure 4.12. Contrle de puissance en boucle ouverte de la voie montante de UTRA-TDD
Ensuite, le mobile dtermine sa puissance d'mission Pejipunk en fonction de Lesh le

gain de liaison estim en voie montante, de l'objectif de SIR, not SIRtarget et de
l'interfrence reue par la base (galement diffuse par cette dernire), note upnnk
[25.31]. La puissance d'mission est alors dduite partir de la relation donnant le SIR
reu par la station de base de correspondance du mobile (puissances en valeurs relles) :
Pe uplink.
SIRinget=Cte- Lest
Iuplink
[4.7]
o cette puissance est calcule de faon avoir le SIR reu gal SIRtarget. La
constante permet d'inclure une marge, de tenir compte du codage, du dtecteur utilis, etc.
Le principe du contrle de puissance en boucle ouverte de la voie montante de

UTRA-TDD est illustr dans la figure 4.12. La formule donnant la puissance mise
(en dBm) du canal ddi DPCH en voie montante est la suivante (tire de [25.331],
o nous crivons en dB et en dBm (uniquement pour Peupiink et Iupimk) les grandeurs
de la formule [4.7] :
[4.8]
o l'utilisation de la moyenne sur une certaine dure de Lesh avec un coefficient

de pondration a (entre 0 et 1), permet de corriger, jusqu' un certain point, l'erreur
dans l'estimation de Lest. Le coefficient a sera d'autant plus proche de 1 que la
qualit de l'estimation est considre bonne. Il peut tre chang de faon dynamique
par les couches suprieures. Le contrle de puissance de la voie montante de UTRA-
TDD est tudi dans [KUR 01], o l'importance du choix de SIRtarget ou, autrement
dit, l'efficacit de la boucle externe de contrle de puissance assure par les couches
suprieures, est souligne.
La trame contient n (avec = 1 1 , dans cet exemple) slots de transmission en voie descendante
(slots downlink) et, par consquence, 15 - n (donc 4, dans l'exemple) slots de transmission en
voie montante (slots uplink). On voit que, pour l'exemple considr, la frquence de mise
jour du contrle de puissance en voie descendante est de 400 Hz (ou bit/s). Les slots de
transmission en voie descendante ne contiennent pas de bit de contrle de puissance [25.221]
car le contrle de puissance en voie montante se fait en boucle ouverte.
Figure 4.13. Trame UTRA-TDD et contrle de puissance
4.6.3. La voie descendante (downlink)
Le mme contrle de puissance que pour UTRA-FDD est appliqu pour la voie
descendante : association de boucle externe et de boucle interne de contrle de
puissance. Les valeurs possibles du pas de variation de la puissance de la boucle
interne pour la voie descendante de UTRA-TDD sont 1, 2 et 3 dB. La taille du pas
de variation de la puissance est slectionne par les couches suprieures [25.224].
4.6.4. Frquences de mise jour du contrle de puissance de la voie descendante

de UTRA-TDD
En vue de prserver la synchronisation et l'efficacit du contrle de puissance, le

systme UTRA-TDD [25.221] impose un minimum de un slot de transmission en
voie montante par trame et un maximum de 13, ce qui est quivalent un maximum
de 14 slots et un minimum de deux slots pour la voie descendante par trame.
On a donc un dbit minimal des commandes de contrle de puissance transmises

en voie montante et donc utilises pour le contrle de puissance de la voie
descendante de 100 Hz (un slot par trame). La figure 4.13 montre une trame UTRA-
TDD o la frquence de mise jour est de 400 Hz.
Le dbit maximal de commandes de contrle de puissance de la voie

descendante correspond au cas o la trame de 10 ms contient 7 ou 8 slots de
transmission en voie montante. Au-del de cette valeur, le nombre de slots de
transmission en voie descendante devient plus faible que le nombre de commandes
de variation de la puisance et toutes les commandes de contrle de puissance ne sont
donc plus utilises. En effet, le lecteur pourra vrifier qu'il est inutile de mettre
jour la puissance de la voie descendante si le slot suivant est un slot de transmission
en voie montante. En se rappelant qu'on a un bit d'information de contrle de
puissance par slot, on peut dduire que le dbit des commandes de contrle de
puissance est entre 100 et 700 Hz pour la voie descendante de UTRA-TDD.
4.7. Contrle de puissance dans la proposition cdma2000
Le principe de base du contrle de puissance est le mme pour cdma2000 et

UTRA-FDD. Une boucle ferme est mise en uvre pour les deux voies de
communication : montante et descendante [CHU 00].
La dure d'une trame est de 20 ms pour les canaux de donnes dans le systme
cdma2000 [3GPP2]. Dans une trame, 16 groupes de contrle de puissance (PCG,
Power Control Group) sont prvus, chacun de ces groupes contenant 1 bit de
contrle de puissance. Ainsi, la frquence des bits de contrle de puissance est de
800 bit/s. Ceci est un dbit nominal car une partie de la trame peut ne pas tre
transmise, ce qui aboutirait une frquence de bits de contrle de puissance
infrieure 800 bit/s. Cette valeur de mise jour du contrle de puissance
(800 bit/s) est du mme ordre de grandeur que celle du systme UTRA-FDD et le
contrle de puissance des deux systmes est qualifi de rapide. Le pas de mise jour
des puissance mises dans cdma2000 est entre 0,25 et 1 dB.
Dans le systme cdma2000, le contrle de puissance en boucle ferme de la voie

montante est associ un contrle de puissance en boucle ouverte. Le principe
gnral est le suivant : si la puissance d'un signal pilote de la base, reu en voie
descendante, donc venant de la station de base, dpasse un certain seuil, la puissance
en voie montante est modifie en fonction de ce rsultat.
4.8. Imperfection du contrle de puissance
Mis en application, le contrle de puissance prsente plusieurs imperfections par

rapport au concept thorique.
Les diffrentes boucles fermes de contrle se basent sur le rapport signal sur bruit
SIR reu. L'estimation de ce dernier ne peut tre totalement prcise. Cette erreur
d'estimation, si elle est trop importante, peut dgrader la boucle ferme d'asservissement
de la puissance mise. La boucle ouverte de contrle, quant elle, se base sur
l'estimation du gain du canal. Cette estimation prsentera galement une certaine erreur.
Les bits de commandes de contrle de puissance, par exemple, un bit

d'information toutes les 0,67 ms pour le systme UTRA-FDD, peuvent subir des
erreurs de transmission. Par exemple, un bit 0 transmis ( baissez la puissance de
transmission de 1 dB ) et mal reu, c'est--dire dcod comme tant 1
( augmentez la puissance de transmission de 1 dB ) aboutira l'effet inverse de
celui escompt. Pour prvenir ce genre de situation, le bit de contrle de puissance
peut tre rpt (voir section 4.5). Un facteur d'talement plus faible, ce qui donne
une meilleure immunit face aux erreurs de transmission peut tre appliqu aux bits
de commandes de contrle de puissance.
Les autres problmes classiques des boucles de contrle numrique sont

galement prendre en compte. Les puissances d'mission (terminaux ou stations
de base) ont une plage limite. A titre d'exemple, la puissance d'mission d'un
terminal UMTS de Classe 3 [25.101] est limite entre 24 dBm (0,25 W) et -50 dBm
(10"8 W). Les commandes de contrle de puissance (voir figure 4.5) ne seront pas
appliques instantanment. L'mission d'une commande et son application sont
spares au minimum par le dlai aller-retour (round trip delay), correspondant la
transmission de la commande de contrle de puissance et l'mission des
informations contrles en puissance. En toute rigueur, un lment retardateur
devrait tre inclus dans le schma du contrle de la figure 4.5.
Les commandes de contrle de puissance deviennent inadaptes si le mobile se

dplace trop rapidement. Cependant, les contrles de puissance des systmes 3G
sont assez rapides pour des vitesses raisonnables de dplacement de mobiles. Il
est bien entendu que les sources d'erreurs du contrle de puissance donnes ci-
dessus ne constituent pas une liste exhaustive.
Des marges ajoutes au seuil requis de qualit, une observation permanente du

rseau mobile en vue de faire rapidement les mises au point ncessaires font que ces
imperfections ne dgradent pas trop les rsultats thoriques attendus du le contrle
de puissance.
4.9. Bibliographie
Les spcifications du 3GPP sont disponibles sur ftp.3gpp.org. Celles du 3GPP2

sont disponibles l'adresse www.3gpp2.org.
[3GPP2] 3GPP2 CS.0002-A, Physical Layer Standard for cdma2000 Spread Spectrum
Systems , Tlcommunications Industry Association, 2002.
[25.101] 3G TS 25.101 v4.0.0 (2001-03), U E Radio Transmission and Reception (FDD)
(Release 4) , 3rd Gnration Partnership Project; Technical Spcification Group Radio
Access Networks, 2001.
[25.102] 3G TS 25.102 v4.0.0 (2001-03), UE Radio Transmission and Reception (TDD)
(Release 4) , 3rd Gnration Partnership Project; Technical Spcification Group Radio
Access Networks, 2001.
[25.214] 3G TS 25.214 v5.4.0 (2003-03), Physical layer procdures (FDD) (Release 5),
3rd Gnration Partnership Project; Technical Spcification Group Radio Access
Networks, 2003.
[25.221] 3G TS 25.221 v5.5.0 (2003-06), Physical channels and mapping of transport
channels (TDD) (Release 5) , 3rd Gnration Partnership Project; Technical
Spcification Group Radio Access Networks, 2003.
[25.224] 3G TS 25.224 v5.4.0 (2003-03), Physical layer procdures (TDD) (Release 5) ,
3rd Gnration Partnership Project; Technical Spcification Group Radio Access
Networks, 2003.
[25.302] 3G TS 25.302 v4.1.0 (2001-06), Services provided by the physical layer (Release
4) , 3rd Gnration Partnership Project; Technical Spcification Group Radio Access
Networks, 2001.
[25.331] 3G TS 25.331 v5.4.0 (2003-03), Radio Resource Control (RRC); Protocol
spcification (Release 5), 3rd Gnration Partnership Project; Technical Spcification
Group Radio Access Networks, 2003.
[25.401] 3G TS 25.401 v4.0.0 (2001-03), UTRAN Overall Description (Release 4) , 3rd
Gnration Partnership Project; Technical Spcification Group Radio Access Networks,
2001.
[25.433] 3G TS 25.433 v4.5.0 (2002-06), UTRAN Iub Interface NBAP Signalling (Release
4) , 3rd Gnration Partnership Project; Technical Spcification Group Radio Access
Networks, 2002.
[CAS 02] CASTRO J. P., The UMTS Network and Radio Access Technology, Wiley, 2001.
[CHU 00] CHULAJATA T . , KWON H. M . , Combinations of Power Control for cdma2000
Wireless Communications System , IEEE Vehicular Technology Confrence 2000 Fall,
VTC2000F, 2000.
[COR98] CORAZZA G. E., D E MAIO G., VATALARO F., C D M A cellular systems

performance with fading, shadowing, and imperfect power control , IEEE Trans. on
Vehicular Technology, vol. 47. n 2, 1998.
et al., On the capacity of a cellular C D M A system," IEEE Trans.
[GIL 9 1 ] GILHOUSEN K . S.
on Vehicular Technology , vol. 40, n 2, 1991.
[HAN 95] HANLY S. V . , An algorithm for combined cell-site selection and power control to
maximize cellular spread spectrum capacity , IEEE Journal on selected areas in
communications, vol. 13, n 7, 1995.
[ H O L 0 2 ] HOLMA H . , TOKSALA A . , WCDMA for UMTS, deuxime dition, Wiley, 2 0 0 2 .
[KUR01] KURJENNIEMI J. et al., Convergence of UTRA TDD Uplink Power Control ,
IEEE Vehicular Technology Confrence 2001 Spring, VTC 2001 Spring, 2001.
[LAG 00] LAGRANGE X . , GODLEWSKI P., TABBANE S., Rseaux GSM, 5me Ed. Herms,
2000.
[LEE91] LEE W.C.Y., Overview of cellular CDMA, IEEE Trans. on Vehicular
Technology, vol. 40, n 2, 1991.
[NUA 0 0 ] NUAYMI L . , GODLEWSKJP., MIHAILESCU C., Call Admission Control Algorithm
for Cellular CDMA Systems Based on Best Achievable Performance , IEEE Vehicular
Technology Confrence 2000 Spring, VTC2000 Spring, 2 0 0 0 .
[NUA 01] NUAYMI L., Contributions sur les algorithmes de contrle de puissance quilibrs
dans les rseaux cellulaires, Rapport de thse de l'Ecole Nationale Suprieure des
Tlcommunications (ENST), Paris, 2001.
[NUA 0 2 ] NUAYMI L . , LAGRANGE X . , GODLEWSKI PU., A Power Control Algorithm for 3 G
WCDMA System , European Wireless 2002, 2 0 0 2 .
Other-cell interference in cellular power-
[VIT 9 4 ] VITERBI A . J., VITERBI A . M . , ZEHAVI E . ,
controlled C D M A ; IEEE Trans. on Communications, vol. 4 2 . , n 2 - 4 , 1 9 9 4 .
[VIT 9 5 ] VITERBI A. J., CDMA Principles of spread spectrum techniques, Addison-Wesley,
1995.
[YAT 95] YATES R . D . , HUANG C . - Y . , Integrated power control and base station
assignment , IEEE Trans. on Vehicular Technology, vol. 44, n 3, Aug. 1995.
Performance of optimum transmitter power control in cellular radio
[ZAN 9 2 ] ZANDER J.,
systems , IEEE Trans. on Vehicular Technology, vol. 41, n 1, 1992.
[ZAN 92a] ZANDER J., Distributed Cochannel Interference Control in cellular radio
systems ,IEEE Trans. on Vehicular Technology, vol 41, n 3, 1992.
Chapitre 5
Couverture d'un rseau cellulaire CDMA
5.1. Prsentation du problme
Dans les rseaux UMTS, bass sur le mode d'accs multiple CDMA (Code
Division Multiple Access) [VIT 95], la couverture est une notion complexe pour les
raisons suivantes :
-elle dpend des interfrences engendres par l'ensemble des autres metteurs,
c'est--dire les autres stations de base ou les autres mobiles. Cette interfrence
dpend donc de la charge du rseau, cette charge tant variable avec le temps ( le
rseau vit ) ;
- elle doit prendre en compte les algorithmes d'allocations de ressources radio,
en particulier celui de contrle de puissance ;
- elle dpend des dbits de donnes dont dispose chacun des utilisateurs car les
rapports signal sur interfrence atteindre sont d'autant plus levs que le dbit
requis est lev.
La couverture doit tre calcule pour les deux voies : montante (uplink) et
descendante {downlink). Cette estimation de couverture d'un rseau cellulaire
CDMA est plus complexe que dans le cas d'un systme F/TDMA comme GSM
[MOU 00].
Chapitre rdig par Loutfi NUAYMI.

En pratique, l'estimation de la probabilit de couverture d'un rseau cellulaire

CDMA est faite pour une charge de rseau donne, ou des donnes statistiques sur la
charge, et des puissances maximales de station de base fixes. Le calcul exact de
couverture doit prendre en compte l'ensemble des lments prcdents
(interfrences, contrle de puissance, puissances maximales des transmetteurs) et il
devient rapidement trs complexe. En pratique, la couverture est dtermine l'aide
de modles et d'approximations. Certains outils proposs, la validit des
approximations et des rsultats sont l'objet de ce chapitre.
Une prsentation synoptique du problme est propose dans la figure 5.1. Les
principaux paramtres sont :
- les positions des stations de base (base stations ou BS) ;
- les donnes ou cartes de trafic, exprimes en Erlang (charge moyenne, dure
moyenne d'un appel, etc.) ;
- les donnes dites radio, incluant les diffrents paramtres techniques des
metteurs ainsi que les dtails des transmissions et les algorithmes d'allocation de
ressources radio.
Une autre donne fondamentale est le type de service : unique (tlphonie) ou

plusieurs services (tlphonie, donnes, vido, Internet, etc).
L'estimation de la qualit est souvent faite travers le rapport signal bruit et

interfrences (SIR, Signal-to-Interference Ratio) reu. Pour cette estimation, on a
donc besoin des conditions et des modles de propagation donnant la relation entre
puissances mises et puissances reues (gain de liaison) ainsi que des facteurs
d'orthogonalit.
Les rsultats du calcul peuvent tre la couverture de la zone et le calcul de la

puissance fournir pour les mobiles et/ou les stations en vue d'assurer une certaine
qualit de couverture. La couverture de la zone peut tre reprsente par la
probabilit qu'un point soit couvert. Ces calculs (et les tracs rsultants) sont faits
pour une rpartition de trafic et une charge offerte donnes. Deux dfinitions
peuvent tre utilises pour la notion de couverture :
- couverture en puissance : un point de la zone couvrir est couvert si la
puissance ou le SIR du signal pilote est suprieur un certain seuil. Notons que,
selon cette dfinition, un point couvert n'est pas sr de pouvoir tablir une
communication. Cela est le cas si l'interfrence est trs proche d'un seuil
correspondant la saturation de la cellule, avant le dbut de la communication du
mobile considr ;
- couverture en disponibilit de communication : en chaque point de la zone, on
cherche calculer la probabilit que le SIR d'une communication tablie entre un
Couverture d'un rseau cellulaire CDMA 189
mobile prsent en ce point et sa base soit suprieure au SIR seuil, correspondant au

seuil de qualit.
Figure 5.1. Position du problme du calcul de la couverture
Plusieurs mthodes sont proposes pour l'estimation de la couverture d'un

rseau CDMA. Dans ce chapitre, nous nous proposons de dcrire une mthode de
simulation statique qui consiste calculer les charges des cellules de faon itrative.
Ce chapitre reprend principalement les travaux de Laiho, Walker et Novosad
([LAI 01, LAI 02] et les complte par des dveloppements thoriques simples qui
ont pour objet de mettre en vidence les principaux phnomnes physiques.
Le reste du chapitre est rparti de la faon suivante : la section 5.2 dcrit le

modle utilis et introduit quelques dfinitions. La section 5.3 passe en revue les
premires mthodes proposes pour l'estimation simple (et par suite trs
approximative) de la capacit d'un rseau cellulaire CDMA. La section 5.4
(respectivement 5.5) prsente les relations utiles pour l'tude du sens uplink
(respectivement downlink). L'algorithme de calcul itratif des charges des cellules
est prsent dans la section 5.6. Certains dtails supplmentaires sur cet algorithme
sont donns dans la section 5.7, avant de conclure dans la section 5.8.
5.2. Modle utilis
Une reprsentation d'un rseau cellulaire CDMA et de l'interfrence qui y existe

est donne dans la figure 5.2. Les notations utilises sont regroupes la fin du
chapitre.
Dans le cadre d'un accs multiple CDMA, tous les signaux subissent un
talement de spectre. Soit R le dbit de donnes avant talement de spectre au cas o
il est commun toutes les communications. Ce dbit est not Rj pour l'usager i,
lorsque les dbits sont diffrents. Le dbit numrique aprs talement (dbit des
chips) est not W. Ce dernier est considr gal la bande de frquence (en Hz)
occupe par le signal tal.
Sur la voie montante, le SIR (Signal to Interference Ratio) pour la

communication i, not y s'exprime en fonction du rapport nergie par bit sur la
densit spectrale du bruit par la relation [VIT 95] :
[5.1]
Le bruit considr est la somme de l'interfrence due aux autres communications

et du bruit thermique de rception.
Pour la liaison descendante (downlink), l'galit devient une ingalit dans la

relation [5.1] :
[5.2]
en raison de l'orthogonalit entre les communications des mobiles d'une mme

cellule. La relation ci-dessus redevient une galit si le facteur d'orthogonalit est
pris en compte dans le calcul du SIR des liaisons downlink (voir sous-
paragraphe 5.5.2). Dans tous les cas, le fait de remplacer l'ingalit de [5.2] par une
galit revient considrer une hypothse (ventuellement) pessimiste.
Figure 5.2. Etude de la liaison montante (uplink) : une communication donne

(en traits continus) reue sur sa base de rattachement subit l'interfrence
due d'autres communications intracellulaires et inter-cellulaires.
5.3. Estimation simple de la capacit d'un rseau cellulaire CDMA
Le problme de l'estimation de la capacit d'un rseau cellulaire CDMA a

suscit une attention particulire ds le dbut des annes 90, poque o le CDMA,
mode d'accs rserv jusque-l aux militaires depuis ses premires applications dans
les annes 50, a t pressenti pour les rseaux de tlphonie mobile civils ([GIL 91,
LEE 91]).
Les premires tudes cherchaient estimer le nombre maximal de

communications simultanes ayant le mme dbit de donnes (tlphonie). Le
rapport nergie sur bit sur la densit spectrale du bruit correspondant au seuil de
qualit (Eh/N0)T est un paramtre important pour l'estimation de la capacit. Les
valeurs typiques se situent entre 4 et 7 dB, suivant le sens de la liaison (uplink ou
downlink), le type de l'galiseur, la modulation et le codage utiliss,
l'environnement radio, etc.
Pour le sens uplink, nous notons fi le rapport de l'interfrence externe sur celle
interne pour une station de base j (voir quation 5.6). Ce facteur est calcul dans
[VIT 91]. Dans un rseau cellulaire de type hexagonal, sa valeur moyenne estime
est de l'ordre de 0,55. Ce facteur est utilis dans [VIT 93] (et repris dans [VIT 95]).
Les auteurs y montrent que le nombre maximal de mobiles dans une cellule est gal
:
o cp est le facteur d'activit commun tous les usagers, GA le gain d la

sectorisation (idalement gal au nombre de secteurs par cellule) et (E b /N 0 ) T le seuil
(threshold) souhait pour le rapport nergie sur bit sur la densit spectrale du bruit
(suppos tre le mme pour tous les mobiles, dans ce chapitre), dans le sens uplink.
Les mthodes ci-dessus permettent une premire estimation, trs approximative,

de la capacit d'un rseau cellulaire CDMA. Des mthodes plus fines sont proposes
dans le but de calculer la couverture du rseau. Entre autres, des calculs de
couverture plus prcis, bass sur le rapport des interfrences, ont t proposs. Ces
calculs font intervenir les probabilits et les statistiques d'interfrences (pour les
notions de Erlang capacity et de tltrafic, voir [COR 98, VIT 93]).
La mthode dite du type Monte-Carlo consiste faire un calcul de couverture

pour une configuration prcise sur des tirages alatoires et rpter le calcul sur un
grand nombre de configurations. Les moyennes des rsultats obtenus donnent alors
la couverture exprime en probabilit de ralisation d'un SIR donn, par exemple.

La mthode Monte-Carlo exige un nombre relativement lev de calculs et, par
suite, des temps de simulation relativement longs, si on souhaite avoir des rsultats
stables (voir, par exemple, [JON 00]).
Une possibilit intressante serait de trouver des mthodes plus sophistiques

que la mthode Monte-Carlo ncessitant des temps de simulation plus courts que
cette dernire tout en ayant des rsultats plus ou moins prcis (c'est--dire proches
de ceux de la mthode Monte-Carlo).
Dans la suite de ce chapitre, nous dcrivons un algorithme qui consiste calculer

de manire itrative la charge de chaque cellule dans un rseau cellulaire CDMA
pour ensuite en dduire la couverture de ce rseau.
5.4. Dfinitions et relations utiles pour la liaison uplink
L'algorithme de prvision de la couverture d'un rseau CDMA par calcul itratif

des charges des cellules est propos pour la premire fois dans [WAC 99]. Il est
aussi dcrit dans [HOL 02] et [LAI 99]. Une synthse est propose dans le
chapitre 3 de [LAI 02].
Dans un rseau cellulaire CDMA, la charge d'une cellule, l'augmentation du

bruit dans cette dernire, les puissances mises et les interfrences moyennes
externes chaque cellule sont lies. La connaissance de ces interfrences (ou, de
manire quivalente, de leurs coefficients) permet de dduire la couverture
partir de ces moyennes. Dans la suite, ces relations sont dtailles et l'algorithme
dcrit.
5.4.1. Dfinitions
5.4.1.1. Couverture
Plusieurs dfinitions peuvent tre utilises. Dans la suite et sauf mention du
contraire, un point de la zone de service est couvert un instant / si le SIR reu en ce
point est suprieur au SIR seuil. Le SIR seuil est li au seuil de rapport nergie sur
bit sur la densit spectrale du bruit (voir l'quation 5.1).
5.4.1.2. Rapport signal bruit ou SIR reu

Le SIR reu est donn par la relation suivante :
o N est le nombre total de mobiles actifs dans la zone couverte. Dans le cas
particulier du downlink, des coefficients d'orthogonalit, idalement gaux zro,
peuvent tre appliqus aux puissances des communications ayant lieu dans la mme
cellule (voir section 5.5).
5.4.1.3. Facteur de charge d'un usager en une cellule donne

Pour une base donne j et pour un usager /, le facteur de charge {user load
factor) est dfini comme le rapport de la puissance venant du mobile i sur la
puissance totale reue la station de base j considre :
R.J,I
n ULj,i ~ C
P +N
Z r.i,k ThJ
k=\ [5.3]
5.4.1.4. Facteur de charge d'une cellule

Il est intressant de considrer le facteur de charge (load factor) sur la voie
montante au niveau d'une cellule j. Il s'agit de la somme des facteurs de charge de
tous les usagers (y compris ceux en dehors de la cellule).
[5.4]
5.4.1.5. Noise Rise (NR)

Le facteur d'augmentation de bruit (NR, Noise Rise) est dfini comme le rapport
de la puissance totale reue par cette dernire (y compris celle venant des usagers en
dehors de la cellule) sur le bruit thermique qu'elle reoit. Ainsi la puissance totale
reue peut tre reprsente comme une augmentation du bruit thermique reu en
l'absence de toute communication :
[5.5]
On peut vrifier que le NR reprsente le rapport de la somme (puissance utile

pour une communication donne + interfrence des autres usagers + bruit
thermique) sur le bruit thennique.
5.4.1.6. Rapport d'interfrences fi de la base j

Le rapport d'interfrences fi correspond au rapport entre l'interfrence externe et
l'interfrence interne la rception de la station de base j. Il s'agit donc la somme
des puissances reues depuis les mobiles des zones de service voisines sur la somme
des puissances reues des mobiles de la zone de service tudie. Ce rapport est
donn par l'expression suivante :
[5.6]
o bj dsigne la station de base avec laquelle correspond le mobile /'. Des calculs
de valeurs moyennes de ce coefficient sont proposs dans [VIT 91 ] ainsi que dans
[COR 98] et [CHE 96], Nous avons dj mentionn ce coefficient dans la
section 5.3 de ce chapitre.
5.4.1.7. Zone de service d'une station

La zone de service d'une station est la zone gographique incluant tous les points
de trafic pris en charge par la station tudie. Elle comprend la zone dans laquelle la
station est meilleur serveur (champ reu diminu de la marge d'interfrence) et la
zone de second serveur dans la limite de la marge de soft handover.
5.4.2. Relations utiles
5.4.2.1. Relation entre NR et facteur de charge

Le facteur de charge d'une station de base peut s'exprimer en fonction des
mobiles de sa cellule et non plus de l'ensemble des mobiles. En effet, d'aprs la
dfinition [5.4], le facteur de charge d'une cellule peut tre rcrit :
soit, par dfinition du facteur de charge individuel :

>
En utilisant le rapport d'interfrence, on en dduit d'aprs [5.6] :
On a donc :
En pratique, les valeurs de r j ^ peuvent facilement dpasser 0,9. [5.7]
Pour une cellule donne, l'augmentation de bruit est directement lie au facteur
de charge. Pour tablir la relation liant les deux quantits, il suffit de rcrire
l'expression donnant Af/ên [5.5] comme suit :
On voit apparatre dans le dnominateur la dfinition du facteur de charge pour

une cellule (en utilisant [5.3] et [5.4]) :
[5.8]
Cette expression fait apparatre que le facteur de charge doit toujours tre
infrieur strictement 1 pour tre dans les conditions de fonctionnement du systme.
Le cas o le facteur de charge est gal 1 correspond la capacit ple, c'est--dire
la capacit maximale qu'on ne peut ni dpasser, ni mme atteindre. En effet, lorsque
le facteur de charge d'une cellule tend vers 1, son facteur d'augmentation de bruit
tend vers l'infini.
5.4.2.2. Relation entre facteur de charge et rapport signal sur bruit (SIR) reu :
Il est possible d'exprimer le rapport signal sur bruit (SIR) en fonction du facteur
de charge de faon trs simple. Sur la voie montante, le SIR reu pour le mobile i
correspondant avec la base j est not y, et est donn par la relation suivante :
[5.9]
On peut rcrire cette dfinition en la modifiant trs lgrement :
[5.10]
On peut donc exprimer y, partir du facteur de charge :
ou inversement :
[5.11]
Le SIR reu y, tant souvent petit par rapport 1 dans le cas d'un rseau CDMA,
la relation [5.14] peut tre approxime par :
[5.12]
5.4.2.3. Relation entre le facteur de charge et le nombre de mobiles pour une base
donne
Dans le cas o tous les usagers ont le mme dbit de donnes R et le mme
facteur d'activit (p, la relation suivante entre le facteur de charge et le nombre de
mobiles pour une base donne peut tre tablie :
[5.13]
Dans [5.13], nous supposons que l'objectif de qualit (E b /N 0 )rest le mme pour
toutes les communications. Comme hypothse supplmentaire, nous considrons
que cet objectif est exactement atteint (hypothse de contrle de puissance parfait).
En effet, les relations [5.12] et [5.1] permettent d'crire, pour une communication i
donne :
[5.14]
Nous introduisons ce stade la variable alatoire binomiale (p reprsentant

l'activit de la communication /'. Nous pouvons alors crire :
[5.15]
La variable (p, est suppose tre de type Bernouilli dans [VEE 99]. Nous n'avons
pas besoin de ce rsultat au niveau de ce chapitre.
Ecrivons l'esprance des deux cts de l'quation prcdente :
[5.16]
o nous avons tenu compte du fait que le facteur d'activit cp et le rapport

nergie par bit sur la densit spectrale du bruit (gal au rapport seuil en cas de
contrle de puissance parfait) sont les mmes pour tous les mobiles.
La sommation de l'quation prcdente sur tous les mobiles de la cellule j

donne : ' -
[5.17]
Si nous considrons que le nombre de mobiles actifs est assez lev par cellule
pour pouvoir considrer la somme de gauche constante, nous pouvons faire
Y approximation consistant supprimer l'esprance :
[5.18]
Il suffit alors de multiplier par (1 +fj) dans les deux cts de l'quation
prcdente et d'utiliser la relation [5.7] pour achever de dmontrer la relation [5.13].
Dans le cas gnral d'un rseau o les mobiles transmettent des dbits
ventuellement diffrents et ont des facteurs d'activit ventuellement diffrents,
nous pouvons tablir la relation suivante en lieu et place de la relation [5.13] :
[5.19]
Les relations [5.13] ou [5.19] permettent de tracer le facteur de charge d'une

cellule en fonction du rapport d'interfrence de la cellule et des rapport de qualit-
seuil, des dbits et des facteurs d'activit de chaque mobile de la cellule. La relation
[5.8] donne alors le NR, ce qui permet de voir le taux de rapprochement de la
capacit ple.
Application numrique :
Considrons un rseau cellulaire o toutes les communications ont le mme type
de service, par exemple la communication vocale, et o les valeurs numriques sont
les suivantes (quelle que soit la communication i) : cp = 0,5 ; (Eb / NQ)iT =7 dB
et Rj= 10 kbit/s. D'autre part, nous considrons que le facteur Jj a une valeur fixe
gale 0,65 et que la bande de frquence West gale 4 MHz.
En utilisant frelations [5.8] et [5.13], nous tablissons facilement la relation

suivante entre le nombre Nj de mobiles dans la cellule /, et l'augmentation du bruit
NRj dans cette cellule :
Cette relation est trace dans la figure 5.3. La valeur 97 est la capacit ple d'une
cellule dans cette application.
5.4.2.4. Relations entre la puissance mise d'un mobile et le NR
Considrons un mobile i rattach la base j et reu avec la puissance Prjj sur sa

base. On peut, partir des relations [5.1], [5.10] et [5.5], exprimer le rapport (EiJNq)
correspondant ce mobile avec l'augmentation de bruit de sa station de base :
[5.20]
Idalement (c'est--dire en ca^de contrle de puissance parfait), la qualit de

communication doit tre gale au seuil requis, d'o :
[5.21]
Paramtres numriques :
Figure 5.3. Augmentation du bruit (NR) en fonction du nombre de mobiles de la cellule

La puissance transmise peut tre crite sous forme de fonction du facteur de

charge de la base de rattachement.
Soit pi la puissance mise par le mobile /'. La puissance reue s'exprime en

fonction du gain de parcours entre le mobile i et sa station de base. Rciproquement,
on peut crire :
[5.21a]
En utilisant [5.8], [5.21] et [5.21a], des manipulations simples permettent

d'exprimer la puissance d'mission ncessaire au mobile, dans l'hypothse d'un
contrle de puissance parfait (l'expression est utilise dans [SCH 01]) :
L'expression [5.22] peut tre simplifie. En effet, si le nombre de mobiles est

grand, on peut faire l'approximation suivante sur [5.21] :
On peut alorSâblir :
[5.22a]
ou, de manire voisine, en utilisant [5.8] :
[5.22b]
Cette quation permet de mettre en vidence le concept d'augmentation de bruit.

En l'absence de toute interfrence, la puissance mettre est proportionnelle au
bruit thermique. En prsence d'interfrence (charge sur le rseau), la puissance est
multiplie par le facteur NRy La capacit ple est donc la capacit qui serait obtenue
si les mobiles avaient une puissance infinie.
Dans le paragraphe suivant, nous donnons les lments d'une tude similaire
pour la liaison downlink.
5.5. Dfinitions et relations utiles pour la liaison downlink
L'tude du sens downlink a longtemps t nglige. En effet, il est moins

simple aborder que le sens uplink (voir ci-dessous) et Viterbi avait dclar que
pour les rseaux dbits symtriques, ce qui est notamment le cas de la
tlphonie, le sens uplink est le sens le plus contraignant au niveau limitation de la
capacit ([VIT 95]).
\
Cependant les rseaux CDMA seront amens court terme transmettre des
donnes, en grande partie. Les dbits de donnes, pour lesquels le sens downlink
aura souvent un dbit moyen bien plus lev que le uplink (par exemple consultation
Internet), pourraient bientt faire du sens downlink le sens le plus contraignant.
D'o l'intrt grandissant pour le downlink. L'autre facteur qui peut rendre le sens
downlink plus contraignant est la contrainte relativement importante, pour diverses
raisons (environnement, techniques,...) sur la puissance maximale des stations de
base.
La liaison descendante (voir figure 5.4) prsente des diffrences par rapport la
liaison montante, en particulier :
- les communications d'une mme cellule se partagent la puissance limite de la
station de base ;
- l'interfrence intracellulaire est reue sur le mme canal que le signal utile,
c'est--dire celui destin au mobile considr. Cette interfrence est nulle dans le cas
(utopique) o l'orthogonalit est parfaitement conserve ;
- le coefficient de l'interfrence externe (voir relation [5.6]) n'est plus le mme
pour les communications d'une mme cellule. Par exemple, il sera plus lev pour
les mobiles proches de la frontire de la cellule.
Ces considrations introduisent des variations dans l'tude du downlink par

rapport au uplink.
Si l'orthogonalit est parfaitement conserve (cas utopique), il n'y a pas d'interfrence entre
les communications d'une mme cellule. Les mobiles situs en bordure de cellule sont
particulirement dfavoriss. La puissance qui leur est transmise doit tre plus leve que
celle des mobiles plus proches de leur base.
Figure 5.4. Etude de la liaison descendante (downlink)
5.5.1. Dfinitions
5.5.1.1. Noise Rise d'une base
Le facteur d ' a u g m e n t a t i o n de bruit sur la voie montante se dfinit pour une base
donne. Il s'agit de l'augmentation relative de la puissance totale mise par la base
entre le cas rel et le cas utopique o il n ' y aucune interfrence entre les diffrentes
communications downlink, y compris entre deux communications base-mobile de

deux cellules diffrentes.
5.5.1.2. Facteur de charge d'une cellule (loadfactor)
Le facteur de charge se dfinit de faon moins claire que sur la voie montante.
L'ide est de trouver une expression pour le facteur de charge qui garde la mme
relation avec le NR que dans le cas du uplink. Pour calculer le facteur de charge, on
se base sur l'hypothse suivante :
Toutes les stations de base mettent avec la mme puissance P
Cette hypothse peut tre considre valable si les stations de base sont
disposes sur une grille rgulire, si la distribution du trafic est uniforme et si les
conditions de propagation sont les mmes sur la zone couverte. On peut aussi
considrer qu'aux heures de pointe (pour lesquelles un rseau est dimensionn), les
stations de base mettent leur puissance maximale, la mme pour toutes.
5.5.2. Relations utiles
Le SIR reu en downlink pour le mobile i correspondant avec la base j est not
yDLJ ; il est donn par la relation suivante :
[5.23]
Dans cette expression, on a introduit le coefficient d'orthogonalit du mobile i,

not a,. Si la base j, laquelle le mobile i est rattach, met une puissance Pj, le
mobile i reoit une puissance (1 - a,)/y comme interfrence. Autrement dit, a, serait
gal 1 si l'orthogonalit tait parfaitement conserve.
Comme on suppose que toutes les stations de base mettent la puissance P, on

peut crire :
[5.24]
En cas de contrle de puissance parfait, nous pouvons crire pour tout mobile i :
[5.25]
Des manipulations simples de [5.24] et [5.25] donnent les relations suivantes :
En faisant la somme pour tous les mobiles /' rattachs la cellule j, on obtient :
[5.26]
Si on introduit les facteurs d'activit, on peut tablir :
[5.26a]
L'expression [5.26a] peut tre vue comme le produit du numrateur et de

l'inverse du dnominateur. On peut vrifier que le numrateur correspond la
puissance totale mise par une base dans le cas o il n'y aucune interfrence entre
les diffrentes communications downlink (y compris entre deux communications
base-mobile de deux cellules diffrentes). L'inverse du dnominateur correspond
un facteur correctif d la prsence des interfrences. On peut donc, par analogie
avec l'quation 5.22, dfinir le facteur de charge r| DLj sur la voie descendante en
posant :
i
[5.27]
avec :
fDL,i= Z f - [5.28]
o nous pouvons vrifier, toujours dans le cadre de l'hypothse de stations de

base pleine puissance, que ce rapport reprsente, pour le mobile i, le rapport
entre la puissance totale reue des bases autres que celle laquelle il est rattach
sur la puissance totale reue de sa base (incluant la puissance qui lui est
destine). Le paramtr-e fou reprsente donc bien le rapport d'interfrences du
mobile i.
Comme pour la voie montante nous pouvons crire :
N: n
^ DL.i P/<P, M
W
[5.28a].
o de manire quivalente, en posant NRDLj = 1/(1 - R\DLJ) :
[5.28b]
Nous retrouvons une formule similaire la formule [5.22b] tablie pour la voie
montante. Le facteur de charge ainsi dfini, et par suite le NR, permettent de
calculer directement les puissances mises des bases. Comme pour la voie montante,
un facteur de charge gal un pour une base correspondra la capacit ple de cette
dernire, en downlink.
Dans le cadre de ce modle, des mthodes sont proposes dans [HIL 00] pour
estimer la capacit du sens downlink d'un rseau CDMA, en particulier pour
UTRA-FDD.
5.6. Algorithme de prvision de la couverture d'un rseau CDMA par calcul

itratif des charges des cellules
L'algorithme de prvision de la couverture d'un rseau CDMA par calcul itratif

des charges des cellules est propos dans [WAC 99]. Il est dcrit dans [HOL 02] et
[LAI 01]. Cet algorithme peut tre subdivis en trois phases (voir figure 5.5).
Figure 5.5. Organigramme de base de l'algorithme dcrit (tude uplink). NR(n) est le NR
d'une base donne pour l'itration n.
La premire phase correspond l'initialisation. En fonction des donnes de trafic

et de charge offerte, une rpartition des mobiles est effectue. Les gains de liaison
sont calculs entre les stations de base et les positions de mobiles et stocks dans
une base de donnes.
La deuxime phase correspond la partie itrative. A partir des valeurs initiales

des augmentations de bruit des stations de base, le calcul itratif fait converger ces
valeurs vers leur valeurs estimes, tout en dterminant quels sont les mobiles en tat
de coupure (outage), c'est--dire qui ne seront pas couverts.
Les rsultats obtenus sont traits et affichs dans la troisime phase. Les rsultats
de gains de liaison maximaux permettent, partir du modle de calcul de gain de
liaison, de dduire les distances maximales et donc les couvertures des diffrentes
stations de base.
Une tude de cas dtaille, faite l'aide de cet algorithme, peut tre trouve dans
le chapitre 8 de [HOL 02].
L'organigramme de la figure 5.5 reprsente les itrations du sens uplink. Lors de

l'application de l'algorithme, les itrations de la deuxime phase doivent tre
appliques pour les deux sens de communication (uplink et downlink). Les
quations du paragraphe 5.5 de ce chapitre sont alors utilises. Le dtail de la partie
downlink de cet algorithme est propos dans [SIP 00]. Aprs convergence, les
rsultats des deux sens sont traits dans la troisime phase.
5.7. Dtails supplmentaires sur l'algorithme de calcul des charges
5.7.1. Imperfection du contrle de puissance
Dans la ralit, le contrle de puissance n'est pas parfait cause des raisons
suivantes ([SIP 99a]) :
- les puissances transmises ne sont pas mises jour de faon continue, elles le
sont dans le cadre d'une boucle ferme chantillonne (voir systme WCDMA) ;
- le pas de mise jour des puissances est compris dans une certaine marge et il
est souvent constant ;
- il existe un dlai non nul entre la mesure du SIR reu (utilis pour la dcision
de mise jour) et la mise jour de la puissance. Cette dernire mesure n'est pas
totalement prcise ;
- des erreurs peuvent avoir lieu lors de la transmission des ordres de mise jour
des puissances ;
- les puissances transmises sont limites dans une certaine marge (valeur
minimale et valeur maximale).
Des tudes thoriques et des simulations montrent que ces imperfections peuvent
tre prises en compte par l'introduction d'un facteur correspondant l'imperfection
du contrle de puissance dans la relation [5.7] qui devient :
N
NULJ= (l + I p c f j ) X ÛLjjt [5-30]
i=l;bj=j
o Ipc est ce facteur. La valeur de IPC dpend du modle adopt pour le canal
radio. Ces valeurs vont de 1,05 1,6 suivant le canal considr ([SIP 99a]).
j
5.7.2. Interfrence de canaux adjacents
Il est possible que plusieurs porteuses CDMA coexistent, ces porteuses

appartenant un mme oprateur ou plusieurs oprateurs. Si deux ou plusieurs
porteuses CDMA coexistent, un calcul d'interfrence de canaux adjacents doit tre
effectu. Un terme reprsentant l'interfrence des canaux adjacents est inclus dans
les formules de calcul de SIR (uplink et downlink). Ce terme est fonction des effets
des filtres appliqus chacune des porteuses autres que celle considre.
5.7.3. Sectorisation
Comme dans l'estimation simple de la section 5.3 de ce chapitre, il est possible,

dans l'algorithme dcrit dans la section 5.6, de tenir compte de la sectorisation. Le
gain de sectorisation est alors inclus dans le calcul du facteur de charge ([LAI 01]) et
des calculs de couverture par secteur peuvent alors tre effectus de manire
analogue ce qui a t prsent jusque-l.
5.7.4. Soft handover
Le soft handover, o un mobile est rattach deux ou plusieurs bases ([VIT 95]),
est un des avantages majeurs des rseaux cellulaires CDMA par rapport aux rseaux
F/TDMA. L'intrt principal du soft handover est l'introduction de la diversit de
transmission. L'algorithme dcrit dans la section 5.6 de ce chapitre ne tient pas
compte du soft handover, c'est--dire que chaque mobile actif est rattach une et
une seule station de base. Les gains de contrle de puissance (quivalents des
baisses de seuil de rapport de qualit reue) dus au soft handover dans WCDMA,
pour le uplink, sont valus en simulation dans [SIP 99b].
5.8. Conclusion et discussion
Dans ce chapitre, nous prsentons le problme de l'tude de la couverture d'un

rseau cellulaire CDMA. Les formules et les relations ncessaires pour ce genre
d'tude sont dtailles. En particulier, nous dcrivons un simulateur statique publi
dans plusieurs papiers de recherche.
Plusieurs extensions de ce genre d'tude peuvent tre envisages, certaines de

ces extensions ayant dj fait l'objet de travaux de recherche. Un point particulier
des rseaux cellulaires CDMA est le choix de la station de base de correspondance
pour chaque mobile actif. L'optimisation de ce choix aboutit une plus grande
capacit du rseau cellulaire CDMA ([NUA 01]). Le choix simple (et donc non
optimal) revient slectionner la base ayant le signal pilote le plus fort (parfois
appele best server) pour chaque mobile. Cette mthode est celle utilise pour
l'algorithme dcrit dans ce chapitre. Un choix plus sophistiqu de la base, dans le
cadre de cet algorithme, devrait aboutir une meilleure couverture.
Dans [SCH 01] et [VEE 99], les distributions de trafic sont utilises pour des
calculs de probabilit bass sur les formules dtailles dans ce chapitre. Les rsultats
des calculs sont des courbes de probabilits de couverture pour une carte donne.
Dans le mme cadre, la couverture et, plus gnralement, l'tude des performances
d'un rseau sans fil CDMA transmettant des donnes est faite dans [TRA 99L
Nous rappelons enfin que toutes ces mthodes dites statiques peuvent tre
valides par les simulations de type Monte-Carlo qui doivent donner des rsultats
proches de la pratique au prix de dures de simulation relativement longues et
parfois prohibitives. La validation finale est, bien entendu, celle des
exprimentations sur le terrain quand le dploiement grande chelle des rseaux
cellulaires CDMA sera en place.
5.9. Bibliographie
[CAS 01] CASTRO J. P., The UMTS Network and Radio Access Technology, Wiley, 2001.
[ C H E 9 6 ] CHEBARO T . , GODLEWSKI P., Average external interference in cellular radio
CDMA systems , IEEE Trans. on Communications, vol. 4 4 , n 1, 1 9 9 6 .
[COR 98] CORAZZA G. E., D E MAIO G., VATALARO F., C D M A cellular systems
performance with fading, shadowing, and imperfect power control , IEEE Trans. on
Vehicular Technology, vol. 47, n 2, 1998.
S. et al., O n the capacity of a cellular
[ G I L 9 1 ] GILHOUSEN K . CDMA system, IEEE
Trans. on Vehicular Technology, vol 40, n 2, 1991.
Hiltunen K . , D E BERNARDI R . , W C D M A downlink capacity estimation , IEEE
[HIL 0 0 ]
Vehicular Technology Confrence 2000 Spring, VTC2000 Spring, 2000.
[ H O L 0 2 ] HOLMA H . , TOKSALA A . , WCDMA for UMTS, Second dition, Wiley, 2002.
[JON 0 0 ] JONES P . , OWEN R . , Sensitivity of UMTS F D D system capacity and coverage to

model parameters , First International Confrence on 3G Mobile Communication
Technologies, 2 0 0 0 .
[LAI 9 9 ]LAIHO-STEFFENS J . , WACKER A . , SIPILA K . , HEISKA K . , The impact of the
subscriber profile on W C D M A radio network performance , IEEE Vehicular Technology
Confrence J 999 F ail, VTC-99F, 1999.
[LAI 0 1 ] LAIHO J., WACKER A . , Radio network planning process and methods for
W C D M A , Annales des Tlcommunications, vol 56, n 5-6, 2 0 0 1 . ^
[LAI 0 2 ] LAIHO J., WACKER A . , NOVOSAD T . , Radio Network Planning and Optimisation for
UMTS, Wiley, 2002.
[LEE91] LEE W . C . Y . , Overview of cellular CDMA, IEEE Trans. on Vehicular

Technology, vol. 40, n 2, 1991.
[MOU 00] MOUROT C., Evolution de l'ingnierie des rseaux radiomobiles , Les rseaux
radiomobiles, ouvrage coordonn par X. Lagrange, Collection IC2, Herms, 2000.
[NUA 0 1 ] NUAYMI L., Contributions sur les algorithmes de contrle de puissance quilibrs
dans les rseaux cellulaires, PhD Report, Ecole Nationale Suprieure des
Tlcommunications (ENST), Paris, 2001.
[SCH 0 1 ] SCHRDER B. et al., A n analytical approach for determining coverage
probabilities in large U M T S networks , IEEE Vehicular Technology Confrence Fall
2001, VTC Fall 2007,2001.
[SIP 99a] SIPILA K . , LAIHO-STEFFENS J., WACKER A., JASBERG M., Modeling the impact of
the fast power control on the WCDMA uplink , IEEE Vehicular Technology Confrence
1999 Spring, VTC '99S, 1999.
[SIP99b] SIPILA K . , JASBERG M . , LAIHO-STEFFENS J., WACKER A . , Soft handover gains in a
fast power controlled W C D M A uplink , IEEE Vehicular Technology Confrence 1999
Spring, VTC99S, 1999.
[SIP 00] SIPILA K . , HONKASALO Z.-C., LAIHO-STEFFENS J., WACKER A., Estimation of
Capacity and Required Transmission Power of WCDMA Downlink Based on a Downlink
Ple Equation , IEEE Vehicular Technology Confrence 2000 Spring, VTC2000 Spring,
2000.
P., LEIBNITZ K . , Teletraffic Models and Planning in Wireless IP

[ T R A 9 9 ] TRAN-GIA
Networks , IEEE Wireless Communications and Networking Confrence,
WCNC'99, 1999.
[VEE 99] VEERAVALLI V . V . , SENDONARIS A., The Coverage-Capacity Tradeoff in Cellular
CDMA Systems , IEEE Trans. on Vehicular Technology, vol. 48, n 5, 1999.
Other-cell interference in cellular power-
[ V I T 9 1 ] VITERBI A . J . , VITERBI A . M . , ZEHAVI E . ,
controlled C D M A , IEEE Trans. on Communications, vol. 4 2 , n 2 - 4 , 1 9 9 4 .
Erlang capacity of a power controlled
[ V I T 9 3 ] VITERBI A . M . , VITERBI A . J . , CDMA
system , IEEE Journal on selected areas in communications, vol. 11, n 6, 1993.
A. J . , CDMA Principles of spread spectrum techniques,
[ V I T 9 5 ] VITERBI
Addison-Wesley, 1995.
Static Simulator for
[ W A C 9 9 ] WACKER A . , LAIHO-STEFFENS J . , SIPILA K . , JASBERG M . ,
Studying W C D M A Radio Network Planning Issues , IEEE Vehicular Technology
Confrence 1999 Spring)VTC'99S, 1999.
5.10. Annexe : notations utilises dans ce chapitre
Note : en rgle gnrale et sauf mention du contraire, les grandeurs valables en

uplink et en downlink (comme par exemple le rapport signal sur bruit ou SIR) ont le
suffixe DL en downlink et aucun suffixe relatif au uplink en uplink.
a, Coefficient d'orthogonalit du mobile i (utilis uniquement pour le

downlink).
B Nombre total de station de base de la zone considre.
bi Base avec laquelle correspond le mobile i.
y,- Rapport signal sur bruit (SIR) reu en uplink du mobile i correspondant
avec la base j.
y DU Rapport signal sur bruit (SIR) reu par le mobile i (en downlink).
(EBIN0)I Rapport nergie par bit sur la densit spectrale du bruit, de la
communication /', en uplink. C'est l'indicateur direct du taux d'erreur binaire et par
suite de la qualit reue. Le bruit considr inclut l'interfrence due aux autres
communications et le bruit thermique de rception.
(E h /N 0 )ij Seuil de qualit requis pour le rapport nergie par bit sur la densit
spectrale du bruit, de la communication i, en uplink.
(EB/N0)DLI Rapport nergie par bit sur la densit spectrale du bruit, de la
communication /, en downlink.
(EB/N0)DLJJ Seuil de qualit requis pour le rapport nergie par bit sur la densit
spectrale du bruit, de la communication du mobile i, en downlink. Ce rapport est
aussi not p,-.
p, Seuil de qualit requis pour le rapport nergie par bit sur la densit
spectrale du bruit, de la communication /, en downlink.
fj Pour la base j (dfinition uplink), c'est le rapport de la somme des
puissances reues des mobiles l'extrieur de la cellule sur la somme des puissances
reues des mobiles l'intrieur de la cellule.
fou Pour le mobile i, c'est le rapport entre la puissance totale reue des
bases autres que celle laquelle il est rattach sur la puissance totale reue de sa
base (incluant la puissance qui lui est destine).
cp Facteur d'activit, au cas o il est commun tous les usagers.
(p, Variable alatoire binomiale reprsentant l'activit du mobile /'. La
valeur moyenne de cp note (p,-, reprsente le facteur d'activit du mobile i.
gij Gain de parcours, en puissance, entre le mobile i et la base j.
gji Gain ^le parcours, en puissance, entre la base j et le mobile i.
i,k Indices dsignant les mobiles.
j,l Indices dsignant les bases.
IIDL,/ Facteur de charge en downlink du mobile i.
r|UL/ Facteur de charge en uplink la base j.
tluw,/ Facteur de charge en uplink du mobile i la base j.
Lji Facteur de charge du mobile i la base j.
N Nombre de mobiles actifs dans la zone couverte.
Nj Nombre de mobiles actifs dans la base j.
NRdlj Noise Rise du mobile i (tude uplink).
NRj Noise Rise de la base j (tude uplink).
Nfh j Puissance du bruit thermique reu par le mobile i.
NThj Puissance du bruit thermique reu la station de base j.
PLji Attnuation entre le mobile i et la station de base /. En fait, PLU n'est
autre que M gu.
PLMaxj Attnuation maximale pour les mobiles rattachs la base j.
P Puissance totale mise par une base, dans l'hypothse o cette puissance
est la mme pour toutes les bases.
Pi Puissance mise du mobile /'.
Pj Puissance totale mise par la base j.
Pji Puissance mise de la base j destine au mobile i, rattach cette
dernire.
PMax Puissance maximale d'mission.
P\fax.e Puissance maximale d'mission de l'quipement e (mobile ou base).
Prij Puissance utile venant de la base j et reue au mobile i (tude du

downlink).
Prjj Puissance reue la base j venant du mobile i (tude de Fuplink).
R Dbit de donnes avant talement.
Ri Dbit de donnes, avant talement, de l'usager z, dans le sens uplink.
RDLJ Dbit de donnes, avant talement, de l'usager /, dans le sens downlink.
W Dbit numrique (chips) aprs talement. Cette valeur est considre
gale, en premire approximation, la bande de frquence (en Hz) occupe par le
signal tal.
Chapitre 6
Le rseau d'accs UTRAN
Ce chapitre prsente les principaux concepts du rseau d'accs de l'UMTS

appel UTRAN, Universal Terrestrial Radio Access Network, en les illustrant par de
nombreux exemples. Ces concepts sont gnralement des extensions et des
abstractions de mcanismes dj prsents dans le rseau d'accs GSM. La premire
partie prsente l'architecture matrielle de l'UTRAN en comparaison de celle du
GSM. Aprs un rappel sur les principaux protocoles utiliss dans les rseaux, on
s'attache prsenter l'architecture protocolaire de l'UTRAN et on montre comment
elle est instancie sur les diffrentes interfaces lorsqu'on utilise une technologie de
transport ATM et lorsqu'on utilise IP. On donne ensuite les caractristiques des
protocoles impliqus sur la voie radio. Le chapitre se conclut par des exemples de
scnarios permettant de voir comment les diffrents mcanismes s'articulent entre
eux.
6.1. Architecture gnrale
6.1.1. Rappel sur le rseau d'accs de GSM
Le rseau d'accs de GSM est appel BSS, Base Station Subsystem ; il comprend
deux types d'quipements :
Chapitre rdig par Xavier LAGRANGE 1 .

1. L'auteur tient remercier particulirement Saso Stojanovski et Claudiu Mihailescu pour
leur relecture attentive.
- les BTS (Base Transceiver Station) qui sont des metteurs-rcepteurs ayant un
minimum d'intelligence ;
- le BSC (Base Station Controller) qui contrle un ensemble de BTS et permet
une premire concentration des circuits.
La BTS est un ensemble d'metteurs-rcepteurs appels TRX. Elle gre la

transmission radio : modulation, dmodulation, galisation, codage correcteur
d'erreur. Elle gre plus gnralement toute la couche physique : multiplexage
TDMA, saut de frquence lent, chiffrement. Elle ralise galement l'ensemble des
mesures radio ncessaires pour vrifier qu'une communication en cours se droule
correctement. Dans les premires versions de la norme, c'est--dire dans la
philosophie de dpart de GSM, ces mesures ne sont pas exploites par la BTS mais
sont directement transmises au BSC. La BTS gre galement la couche liaison de
donnes pour l'changejde signalisation entre les mobiles et l'infrastructure.
La trisectorisation est employe massivement par les oprateurs : elle consiste

placer sur le mme site trois BTS pourvues chacune d'antennes directionnelles qui
couvrent des secteurs de 120 d'ouverture. Les trois BTS sont placs gnralement
dans une mme armoire et apparaissent donc comme un seul quipement. Trs vite,
l'habitude a t prise par les oprateurs et les constructeurs de parler d'une BTS
trisectorise pour dsigner ce que la norme considre comme trois BTS
diffrentes, mme si elles sont colocalises. Le vocabulaire de la nonne diffre donc
du vocabulaire courant. Ces ambiguts de vocabulaire sont leves avec l'UMTS
(voir paragraphe 6.1.2.3).
Le BSC est l'organe intelligent du BSS. Il a pour fonction principale de grer la

ressource radio : il commande l'allocation des canaux, utilise les mesures effectues
par la BTS pour contrler les puissances d'mission du mobile et/ou de la BTS,
prend la dcision de l'excution d'un handover. De plus, c'est un commutateur qui a
pour fonction de raliser un relayage des circuits vers le MSC. Cela permet
d'installer moins de circuits entre le BSC et le MSC que la somme du nombre de
circuits entre toutes les BTS et le BSC : on a donc un effet de concentration des
circuits.
Les BSC et les BTS sont relis entre eux par des liaisons spcialises, ce qui
constitue l'interface Abis. Les liaisons utilises sont des liaisons MIC, gnralement
de type El (31 voies 64 kbit/s multiplexes temporellement, soit une liaison un
dbit total de 2,048 Mbit/s). Les technologies employes sont des liaisons filaires,
des faisceaux hertziens ou, dans certains cas, des liaisons HDSL (par exemple pour
des couvertures d'aroports o l'on rutilise l'infrastructure prive de paires
torsades).
Le rseau d'accs UTRAN 217
La parole est code le plus souvent en GSM 12,2 kbit/s. Comme le cot des
liaisons entre BTS et BSC est un lment important du cot total d'exploitation du
rseau, il est primordial d'couler le maximum de trafic sur le mme support de
transmission : en gnral, les oprateurs multiplexent quatre sous-voies 16 kbit/s
sur une voie 64 kbit/s, chaque sous-voie pouvant couler une communication
12,2 kbit/s. Le transcodage de la parole au dbit classique de 64 kbit/s se fait avant
le MSC/VLR dans un quipement appel TRAU, Transcoder/Rate Adaptation Unix
(voir figure 6.2).
La liaison sur l'interface Abis est bipoint. La topologie naturelle est l'toile
comme reprsent sur la figure 6.1. Celle-ci est coteuse et peu rsistante aux
pannes. Il est possible d'utiliser une topologie en chane : plusieurs BTS et le BSC
forment une chane reboucle sur elle-mme. Cette topologie est conomique et
rsiste une panne-de liaison. On reste cependant dans une approche circuit : il y a
une correspondance fixe par configuration entre chaque canal radio d'une BTS et
chaque sous-voie 16 kbit/s. Cette dernire est rserve de faon dfinitive, qu'il y
ait une communication ou non.
Figure 6.1. Architecture du rseau d'accs GSM
De plus, les dbits des circuits sont fixes sur les interfaces du BSS : 16 kbit/s sur
l'interface Abis et 64 kbit/s sur l'interface A. En effet, le GSM a t spcifi avec
l'objectif principal d'offrir un service de tlphonie compatible du RNIS (Rseau
numrique intgration de services). Les spcifications manquent de souplesse :
elles n'ont pas t prvues pour tablir un circuit avec un dbit la demande.
Figure 6.2. Circuits dans le rseau d'accs GSM {plan usager)
En conclusion, l'interface Abis de GSM, entre la BTS et le BSC, a les limitations

suivantes :
- approche circuit ne permettant pas de profiter d'ventuels gains de
multiplexage statistique ;
- circuits dbit fixe sur les interfaces du rseau d'accs.
6.1.2. Elments du rseau d'accs UTRAN
Le rseau d'accs de l'UMTS, appel UTRAN (Universal Terrestrial Radio

Access Network), est constitu de stations de base et de contrleurs comme dans
GSM. Les diffrences avec GSM ont pouss un changement de vocabulaire :
- le nud B (node B) est un ensemble d'metteurs-rcepteurs et correspond la
BTS de GSM ;
- le RNC (Radio Network Controller) est le contrleur de ressources radio et
correspond au BSC de GSM.
Figure 6.3. Architecture gnrale du rseau d'accs UTRAN

6.1.2.1. Rseau de transport
Le rseau d'accs UTRAN se distingue du BSS de GSM par l'utilisation d'un

rseau de transport (voir figure 6.3). Ce dernier remplace les liaisons spcialises du
GSM. Dans la premire version des recommandations (Release 99) le rseau de
transport est de type ATM (Asynchonous Transfer Mode). C'est donc un rseau de
type circuit virtuel. A partir de la Release 5, il est possible d'utiliser un rseau IP.
L'intrt d'utiliser un rseau de transport est la grande souplesse que cela peut
apporter :
- dfense contre les pannes de liaisons grce au maillage gnralement prsent
dans toute topologie de rseau ;
- modification possible de la topologie par rorganisation des circuits virtuels ;
- possibilit de relier deux RNC entre eux sans installation de liaisons physiques
supplmentaires ; par exemple, avec un rseau de transport ATM, il suffit d'tablir
un circuit virtuel sur le rseau. Cela permet de dfinir une nouvelle interface
spcifique l'UMTS, l'interface Iur.
Le rseau de transport sert indiffremment transporter les donnes usager

(plan d'usager) et l'ensemble de la signalisation (plan de contrle). Contrairement
au GSM, o une voie 64 kbit/s est configure soit comme liaison de
signalisation, soit comme ensemble de 4 circuits de voix ou donnes (sous-voies
16 kbit/s), le mme rseau de transport est utilis la fois pour le plan d'usager et
le plan de contrle. La diffrenciation entre les deux se fait dans l'architecture en
couches.
Les recommandations ne prcisent pas l'architecture du rseau de transport.

Celui-ci peut tre rduit sa plus simple expression, c'est--dire une liaison
physique ! Par exemple, il est possible de conserver des liaisons physiques entre les
nuds B et les RNC et de n'avoir un rel rseau de transport qu'entre RNC
(utilisation de liaisons de type ATM sur SDSL, Single-line Digital Subscriber Line,
entre les nuds-B et les RNC comme dans la figure 6.4).
Dans la pratique, il n'est pas possible d'utiliser toute la souplesse que pourrait
apporter un rseau de transport en Release 99. En effet, les quipements de
commutation ATM de l'UTRAN ne savent pas tablir des circuits virtuels la
demande (SVC, Switched Virtual Circuit). On utilise des circuits virtuels
permanents (PVC, Permanent Virtual Circuit). Dans la figure 6.5, on reprsente
les circuits virtuels permanents permettant d'effectuer les liaisons au sein du
rseau de transport dans le cas o tous les quipements accdent au mme rseau
de transport.
Figure 6.5. Exemple d'utilisation de circuits virtuels permanents ATM dans UTRAN
6.1.2.2. Interfaces dans l'UMTS
Les interfaces filaires du rseau d'accs sont dsignes par les lettres lu.
L'interface lu est situe entre le RNC et un rseau cur. Avec un rseau cur
circuit, il s'agit de l'interface Iu-Cs, avec un rseau cur paquet, il s'agit de
l'interface lu-Ps. Ce sont respectivement les homologues des interfaces A et Gbde
GSM. L'interface Iub, entre le nud B et le RNC, est l'homologue de l'interface
i
Abis. L'interface Iur entre RNC est spcifique l'UTRAN et sans quivalent dans
GSM. Ces interfaces sont reprsentes la figure 6.6. Notons que les traits entre
quipements ne signifient pas qu'il y a des liaisons physiques directes entre ceux-ci
mais que les quipements peuvent dialoguer entre eux suivant une pile de protocoles
(voir figures 6.29 et 6.30). Dans tout le chapitre, nous utilisons ce type de
reprsentation.
Figure 6.6. Interfaces dans le rseau d'accs UTRAN
6.1.2.3. Le Nud B
Le nud B (node B) assure toutes les fonctions de la couche physique sur la voie
radio : transmission et rception, modulation, dmodulation, talement de spectre,
codage correcteur. Le nud B prend galement en charge le contrle de puissance
rapide du mobile (c'est--dire sur la voie montante) et, dans certaines
configurations, les mcanismes de diversit de rception par slection ou par
combinaison ( m a x i m u m ratio combining).
Comme dans GSM, il est possible d'utiliser la trisectorisation. La norme a repris

le vocabulaire courant et considre qu'il y a dans ce cas un seul nud B qui couvre
plusieurs secteurs.
6.1.2.4. Le RNC
Le RNC est l'quipement qui contrle l'utilisation et l'intgrit des ressources
radio. Du fait de l'utilisation d'un rseau de transport, un nud B pourrait avoir des
liaisons avec plusieurs RNC. Cependant, cela n'est pas prvu par les
recommandations. Un nud B est contrl par un seul RNC. Ce RNC est appel
Controlling RNC. Dans la suite, pour simplifier le vocabulaire, on n'utilisera pas ce
terme : par dfaut, lorsqu'on dcrit des actions effectues par un RNC sur un nud
B, il s'agit toujours du Controlling RNC.
Pour un mobile donn, le RNC effectue les oprations suivantes [25.401] :

- il est en charge de l'tablissement de la connexion RRC (voir
paragraphe 6.6.3) entre le mobile et le RNC. La prsence de cette connexion est
indispensable si le mobile souhaite tablir un appel ou une session de donnes, ou
plus gnralement changer de la signalisation avec le rseau (pour la gestion de la
mobilit par exemple) ;
- il affecte les ressources radio (par exemple le code OVSF utiliser sur la voie
descendante) ;
- il gre le contrle de puissance lent ;
- il gre la configuration ou reconfiguration de l'interface radio et la mobilit du
mobile (handovers) qui ncessitent un change de signalisation avec le mobile ;
- il comprend des fonctions de combinaison et de dcoupage
(<combining/splitting) pour la macrodiversit.
Lorsqu'on considre un mobile particulier en communication et en soft

handover (ou qui a effectu pralablement des handovers), deux RNC ou plus
peuvent tre concerns par la connexion radio. Ces deux RNC ne jouent pas le
mme rle. Le Serving RNC (S-RNC) ou RNC serveur est celui qui effectue la
gestion des connexions radio, le raccordement avec le rseau cur et qui contrle
et excute le handover. Le Drift RNC1 (D-RNC) OU RNC en drivation est le RNC
plac, par rapport la connexion radio, entre le mobile et le RNC serveur. Il
effectue la gestion des ressources physiques de ses cellules (comme tout RNC) et
gre la macrodiversit sous ses nuds B. Lorsqu'une communication ne met en
jeu qu'un seul RNC, celui-ci est alors le RNC serveur. Il n'y a pas de RNC en
drivation. Le RNC serveur est l'quipement avec lequel le mobile a tabli une
connexion RRC. C'est la prsence ou l'absence de la connexion RRC qui dfinit
la notion de RNC serveur pour un mobile. Sans son existence, le mobile est
incapable de communiquer avec le rseau (mode veille UMTS par opposition au
mode connect de l'UMTS).
2. Drift signifie, entre autres, drivation. Par analogie avec l'lectricit o l'on parle de
montage en drivation pour dsigner un montage en srie, on peut parler de RNC plac en
drivation entre le mobile et le RNC.
Le mobile a tabli une communication lorsqu'il tait dans la cellule 1. Le RNC 1 tait Serving
RNC.
Suite un soft handover, la communication passe par le RNC 2 qui a le rle de Drift RNC. Le
RNC 1 reste Serving RNC.
Figure 6.7. RNC serveur et en drivation lors d'un soft handover
Aprs un dplacement du mobile, il est inutile de maintenir la liaison radio via le nud B 1.
les RNC gardent chacun leur rle.
Figure 6.8. RNC serveur et en drivation aprs un soft handover
Dans certains cas, c o m m e par exemple aprs un ou plusieurs handover (voir

figures 6.8 et 6.9), il est possible que les R N C changent de rle pour une
communication donne : un chemin plus court est tabli entre le rseau cur et le
mobile, l'ancien RNC en drivation devient RNC serveur et l'ancien RNC serveur
n'est plus impliqu dans la communication.
alors Serving RNC.
Figure 6.9. Suppression du RNC en drivation {procdure de relocalisation)
6.2. Rappels sur les architectures en couches des rseaux
L'volution des rseaux s'est faite de 1980 2000 de faon un peu anarchique :
plusieurs technologies ont t dveloppes sans grande coordination. Parmi celles-
ci, on peut citer l'ATM reposant sur la commutation de cellules, les rseaux IP et la
signalisation smaphore pour le rseau tlphonique. Ces techniques ne se situent
pas au mme niveau de dtail par rapport au modle de rfrence OSI. Une des
particularits de l'UMTS est de les utiliser toutes. Nous rappelons dans ce
paragraphe les grandes lignes de chaque technique et comment celles-ci peuvent
interoprer.
6.2.1. Signalisation smaphore
Dans le rseau tlphonique, les donnes utilisateurs et la signalisation sont

changes par deux rseaux distincts. En d'autres termes, le plan de contrle et le
plan d'usager sont dissocis ds le niveau physique. L'architecture du rseau
tlphonique est dcrite de faon gnrale dans [LAG 98] et de faon prcise dans
[RIG 98]. Cette partie contient les concepts essentiels de la signalisation smaphore.
6.2.1.1. Dfinition
La signalisation smaphore a t dveloppe dans le cadre des rseaux
tlphoniques utilisant la commutation de circuits. Elle est dfinie comme une
mthode dans laquelle une seule voie, appele canal smaphore, achemine la
signalisation se rapportant une multiplicit de circuits. La signalisation smaphore
peut galement servir changer des messages de gestion et de supervision entre
commutateurs [RUS 02].
Le principal systme de signalisation par canal smaphore est celui dfini par
l'ITU dans la srie de recommandations Q.700. Il est couramment appel SS7
(Signalisation smaphore 7), CCITT n7 (ancien nom de l'ITU) ou CCS7 (Common
Channel Signalling System number 7). Son principal objectif est de dfinir un
standard de signalisation au niveau mondial optimis pour les rseaux numriques,
fiable et volutif pour convenir l'laboration de services futurs [Q.701].
L'ensemble des canaux smaphores d'un rseau tlphonique forme un rseau

smaphore qui utilise le principe de la commutation de messages. Les utilisateurs du
rseau smaphore sont les centraux tlphoniques qui gnrent et interprtent les
messages de signalisation. Dans ce contexte, ils sont appels PS (Points smaphores)
ou SP (Signalling Point). Pour permettre d'changer des messages entre deux
commutateurs tlphoniques qui ne sont pas relis entre eux par un canal
smaphore, on place des commutateurs de messages appels PTS (Points de
transfert smaphore) ou STP (Signalling Transfer Point). Comme tout commutateur
de datagrammes, un PTS stocke les messages de signalisation, analyse leur en-tte
pour effectuer le routage et les retransmet au destinataire ou un autre PTS plus
proche du destinataire.
Dans un rseau tlphonique classique, il y a une sparation claire entre le rseau

de transmission, supportant les communications (voix ou donnes) et bti sur la
commutation de circuits et le rseau de signalisation bti sur la commutation de
messages. Cependant, les deux rseaux peuvent partager les mmes supports
physiques de transmission.
6.2.1.2. Architecture en niveaux

Le rseau smaphore tant un rseau commutation de messages, il est naturel
de reprendre une architecture en couches. Dans le contexte du SS7, on parle plutt
de niveaux mais le concept est le mme.
Le sous-systme de transfert de messages (MTP, Message Transfer Part) offre

un service de transfert fiable des messages de signalisation entre deux points
smaphores d'un mme rseau. Il comprend 3 niveaux qui correspondent aux
3 couches basses du modle OSI : physique, liaison de donnes et rseau. Le

niveau 3 du MTP, appel couramment MTP3, offre un service rseau sans
connexion. Chaque PS est repr par une adresse code sur 14 bits appele code de
point smaphore (PC, Point Code).
Lorsque la signalisation concerne l'tablissement, la gestion ou la libration d'un

circuit tlphonique, elle est dite associe circuit . Dans le cas contraire, la
signalisation est non associe circuit . L'tablissement d'un appel tlphonique
provoque un change de signalisation associe circuit. La consultation d'une base de
donnes est un exemple de signalisation non associe circuit.
6.2.1.3. Signalisation associe circuit
Dans le cas de la signalisation associe circuit, le protocole d'tablissement des

appels tlphoniques est plac directement au-dessus de MTP3. On parle de sous-
systme utilisateurs ou user part. Le protocole le plus rpandu est ISUP [Q.761]. Il
permet une grande varit de services supplmentaires (renvoi d'appel, double
appel,...).
Figure 6.10. Pile de protocoles pour la signalisation associe circuit
6.2.1.4. Signalisation non associe circuit
Le MTP offre un service limit : il permet uniquement l'change de signalisation

au sein d'un mme rseau smaphore et offre seulement un service sans connexion.
Le protocole SCCP, Signalling Connection Control Part, ou sous-systme de
commande des connexions smaphores, est plac au-dessus du MTP dans
l'architecture en niveaux [Q.711 Q.714], Il fournit les moyens d'tablir des
connexions dans un rseau SS7 et permet d'changer des messages de signalisation
non lis un circuit entre rseaux SS7 diffrents. Cela suppose, bien sr, que les
rseaux SS7 soient interconnects entre eux.
Le SCCP possde quatre classes de services dont certaines permettent d'offrir un

service avec connexion non prsent dans le MTP :
- c l a s s e 0, service sans connexion de type datagramme sans garantie de
squencement ;
- c l a s s e 1, service sans connexion de type datagramme avec garantie de
squencement (tous les messages suivent le mme chemin et sont dlivrs par le
rseau dans l'ordre de remise par l'expditeur) ;
- classe 2, service avec connexion sans contrle de flux ;
- classe 3, service avec connexion avec contrle de flux.
Le niveau SCCP fournit l'ensemble des services rseau dfinis par le modle de
rfrence OSI. Au-dessus de SCCP peuvent se trouver de nombreuses entits
utilisatrices. C'est le cas dans l'UMTS.
modle de rfrence OSI niveaux SS7
Figure 6.11. Pile de protocoles pour la signalisation non associe circuit
Le protocole TCAP, Transaction Capabilities Application Part, ou sous-systme

de gestion des transactions [Q.771] est un protocole de couche application utilisant
une structure transactionnelle permettant de fiabiliser les demandes d'oprations
distance (consultation de base de donnes, activation de services distance,
demande d'excution de requte). TCAP gre galement les problmes de versions
logicielles pouvant survenir entre deux applications utilisant ces services. Pour ce
faire, TCAP introduit la notion de dialogue qui correspond un ensemble de
paramtres communs deux applications distantes souhaitant communiquer entre
elles. Les changes TCAP sont structurs en transactions qui elles-mmes
correspondent une succession d'oprations lmentaires de type question-rponse.
La structure transactionnelle permet de s'assurer que les oprations demandes par
un quipement s'effectuent correctement sur l'quipement cible. Le protocole TCAP
utilise le codage ASN.l qui garantit une volutivit et une syntaxe universelle des
donnes. Il correspond typiquement aux fonctionnalits des couches 5 et 6 du

modle OSI.
Au-dessus du protocole TCAP, se trouve le protocole applicatif qui permet de

disposer d'un service spcifique. Le protocole MAP, Mobile Application Part,
permet la gestion d'abonns mobiles dans un rseau GSM ou dans un rseau UMTS.
6.2.2. Architecture en couches d'un rseau A TM
6.2.2.1. Commutation de cellules et ATM
L'ATM (Asynchronous Transfer Mode) est bas sur la commutation de cellules.

Une cellule est un petit paquet de taille fixe (48 octets de donnes et 5 octets d'en-
tte dans le cas prcis de l'ATM) [ROL 02]. L'en-tte de la cellule porte
l'identification de la voie de communication. Sur une liaison ATM, les cellules
correspondant diffrentes voies peuvent tre transmises suivant un squencement
quelconque : les mcanismes de multiplexage et de commutation sont polyvalents,
et indpendants du dbit des voies (multiplexage statistique).
VPI : Virtual Path Identifier VCI : Virtual Circuit Identifier
Figure 6.12. Format gnral d'une cellule ATM
Le mode d'acheminement retenu est l'acheminement par voie logique. Un

identificateur de voie virtuelle (VCI, Virtual Channel Identifier) est plac dans l'en-
tte de la cellule, ainsi qu'un identificateur de conduit virtuel (VPI, Virtual Path
Identifier) qui englobe plusieurs voies virtuelles.
Les circuits virtuels peuvent tre tablis la demande (SVC, Switched Virtual
Circuit) mais ils sont le plus souvent configurs par l'oprateur et sont dits
permanents (PVC, Permanent Virtual Circuit). Dans la pratique, un rseau est
constitu d'un ensemble de brasseurs ATM. L'oprateur dfinit un certain nombre
de circuits virtuels entre les quipements extrmits. Le service rendu s'apparente

donc du relais de trame.
6.2.2.2. Rseau numrique large bande
Dans les annes 80-90, il tait prvu d'utiliser l'ATM pour dployer des rseaux
haut-dbit grand public offrant des services multimdias. Ce type de rseau, appel
RNIS-LB (Rseau numrique intgration de services et large bande) ou B-ISDN
(Broadband Integrated Service Digital Network) [ K O F 96], n'a pas vritablement
vu le jour. Cependant, un certain nombre de concepts et de protocoles ont t
rutiliss, notamment dans le cadre de l'UMTS.
Dans ses objectifs de dpart, le RNIS large bande interconnecte aussi bien des
quipements terminaux que des rseaux privs. Il est constitu de commutateurs de
cellules ou commutateurs ATM. On distingue deux types d'interfaces :
- l e s interfaces internes au rseau de l'oprateur, de type Network to Network
Interface ( N N I ) ;
- les interfaces entre l'quipement terminal ou un commutateur priv et le rseau

de l'oprateur, de type User to Network Interface (UNI).
Figure 6.13. Interfaces dans le RNIS large bande

Dans le RNIS-LB, le modle de rfrence en couches distingue, comme dans la

plupart des rseaux, un plan de contrle (pour la signalisation) et plan d'usager :
- le plan d'usager comprend l'ensemble des mcanismes permettant le transport
des donnes de l'utilisateur final (conversation tlphonique, donnes changes
comme les messages, pages Web,...) ;
- le plan de contrle comprend les mcanismes permettant le transport des
donnes usagers. Par exemple, les protocoles d'appel tlphoniques font partie du
plan de contrle.
Le modle de rfrence du RNIS-LB distingue trois couches [1.321] :

- la couche physique PHY, charge de la transmission, et constitue d'une sous-
couche, dpendante du mdium, charge de l'mission des bits sur le support, et
d'une sous-couche charge de l'adaptation au dbit, du contrle d'erreur de l'en-tte
et de la dlimitation des cellules ;
- la couche ATM, charge de la gnration des champs de l'en-tte de la cellule,
du traitement des identificateurs de voies/conduits virtuels dans le rseau, du
multiplexage/dmultiplexage des cellules suivant un rythme adapt la demande de
l'application ;
- la couche d'adaptation l'ATM ( A A L , ATM Adaptation Layer) qui assure la
liaison avec les couches suprieures.
La couche AAL tablit un lien entre la couche ATM et les couches applicatives.
Elle s'efforce de satisfaire les contraintes imposes par les applications en
compltant les services de la couche ATM. Son implmentation se situe souvent aux
points extrmits (voir figure 6.14.). Notons que les points extrmits peuvent tre
des terminaux mais galement des commutateurs lorsqu'un circuit virtuel est tabli
entre eux avec certaines caractristiques de service.
Figure 6.14. AAL, couche de bout en bout
6.2.2.3. Principaux types d'AAL
Le RNIS large bande intgre des services de type parole ou mulation de circuit
(dbit constant, mode connect, contraintes temps rel), de type images (dbit
constant ou variable cause de la compression, mode connect, contraintes temps

rel) et de type donnes (dbit quelconque, mode connect ou non, pas de
contraintes temporelles strictes).
Chaque type d'application fait appel des entits AAL spcifiques. L'ITU a
dfini trois classes de services AAL numrotes 1, 2 et 5. Dans le cadre de l'UMTS,
seules l'AAL2 et l'AAL5 sont utilises. Les AAL de types 3 et 4, dfinies
initialement, ont t abandonnes.
AAL-1 AAL-2 AAL-5

Relation Oui Non
Caractristiques temporelle
source-
destination
Dbit Constant Variable
Mode de Oui Non
connexion
Remarque plusieurs adapt au
connexions transfert de blocs
dans un CV de donnes de
identifies par taille variable
leCID (par exemple
signalisation)
Utilisation dans l'Utran Non Oui Oui
Figure 6.15. Caractristiques des diffrents AAL
Le service AAL5 permet de transmettre des blocs de donnes de taille variable

(jusqu' 65 535 octets). Il convient aux transmissions de donnes sans forte
contrainte de dlai.
Le service AAL1 convient au trafic dbit constant (tlphonie, vido, liaisons

loues). Il a t spcifi dans les annes 90 dans une optique de communications
tlphoniques codes 64 kbit/s et convient peu aux communications mobiles o,
pour des questions d'conomie, on utilise des codeurs de paroles des dbits
infrieurs ou gaux 12,2 kbit/s. Ces codeurs produisent des chantillons de
244 bits (au plus) toutes les 20 ms, soit des blocs d'au plus 31 octets. Un bloc ne
remplit donc pas entirement une cellule. Pour un utilisateur donn, il n'est pas
possible d'attendre plusieurs blocs avant de les transmettre cause des contraintes
de dlais.
L'AAL2 a t spcifi pour permettre un multiplexage, sur un mme circuit

virtuel, de plusieurs communications. On dfinit une mini-cellule avec un en-tte de
3 octets qui contient un numro de canal (CID, Channel Identifier). Plusieurs mini-
cellules peuvent tre placs dans une mme cellule ATM. La transmission de mini-
cellules avec un mme numro de canal CID forme un microcircuit (le qualificatif
virtuel est sous-entendu). Dans cet ouvrage, on utilise indiffremment le terme de
microcircuit et de connexion AAL2. L'AAL2 est utilis dans l'UTRAN dans le plan
d'usager.
6.2.2.4. Signalisation pour AAL2 dans le RNIS-LB
Dans le cadre du RNIS-LB il faut prvoir la signalisation capable d'tablir, entre

deux extrmits, des services (transmission de voix, de vido). Dans le rseau
tlphonique fixe, on a dvelopp une pile de protocoles pour la signalisation
smaphore : MTP 1, MTP 2 et MTP 3 avec un protocole tlphonique (ISUP). Cette
base a t reprise avec des modifications et des ajouts dans le RNIS-LB.
Le protocole permettant d'tablir les microcircuits AAL2 est spcifi par l'ITU
dans la recommandation Q.2630.1. C'est un protocole qui dfinit l'change de
signalisation. Le protocole de signalisation Q.2630.1 peut s'appuyer sur la pile
suivante sur les interfaces NNI (voir figure 6.16.) :
- AAL5 (ATMAdaptation Layer 5) qui permet le transport de cellules contenant
les segments de messages de signalisation ;
- SSCOP (Service Spcifi Connection Oriented Protocol), dfini dans la
recommandation Q.2110 de l'ITU-T, qui contient les mcanismes d'tablissement et
de libration de connexion et l'change fiable de signalisation (dtection et
correction d'erreurs, contrle d'intgrit) ;
- SSCF-NNI (Service Spcifi Coordination Function for Network to Network
Interface), dfini dans la recommandation Q.2140, qui permet d'adapter les
exigences des couches suprieures en fonction des contraintes spcifiques de
SSCOP (contrle de flux entre couches, reconfiguration de route, procdure de
basculement de canal smaphore,...) ;
- MTP3b (Message Transfer Part 3 broadband), dfini dans la recommandation
Q.2210, qui permet le routage des messages au sein du rseau de transport ;
-Q.2150.1, du nom de la recommandation ITU qui le dfinit, qui permet
l'adaptation du protocole de niveau suprieur MTP3b.
Sur les interfaces UNI, c'est--dire l'accs du rseau ATM, il n'y a pas de
problme de routage : MTP3b est donc inutile. La pile de protocole est lgrement
simplifie, comme indiqu en figure 6.17.
Notons que ces piles de protocole sont contenues dans le plan de contrle
{controlplane) alors qu'AAL2, qui est utilis pour transporter des donnes, est dans
le plan usager.
Figure 6.16. Plan de contrle et plan d'usager pour AAL2 sur une interface NNI
Figure 6.17. Plan de contrle et plan d'usager pour AAL2 sur une interface UNI
Il est peut tre utile, dans un rseau RNIS-LB, d'changer de la signalisation

pure, indpendamment de l'tablissement de circuits virtuels. Dans ce cas, on utilise
le protocole SCCP (Signalling Connection Control Protocol), qui remplit ce rle au-
dessus de MTP dans le rseau tlphonique. Notons que SCCP peut-tre utilis pour
tout type d'information : si SCCP transporte de la signalisation interprte comme
telle par le rseau RNIS-LB, il sera alors dans le plan de contrle (Control Plane) ;
dans le cas contraire, il est dans le plan d'usager (User Plane).
6.2.3. Rseaux IP
6.2.3.1. Rappels sur IP

Le protocole IP (Internet Protocol) permet l'change de paquets en mode
datagramme entre routeurs. Chaque paquet porte l'adresse de l'expditeur et
l'adresse du destinataire. En version IPv4, l'adresse est code sur 32 bits ; pour faire
face, entre autres, au problme de saturation d'adresses, la version IPv6 dfinit un
adressage sur 128 bits.
Un rseau datagramme n'offre gnralement pas une garantie de qualit de

service (possibilit de dsquencement et de pertes de paquets). Lorsque les
quipements extrmits peuvent se satisfaire de la qualit de service du rseau, on
peut utiliser le protocole UDP, User Datagram Protocol, comme protocole de
niveau transport.
Lorsqu'il est ncessaire de garantir une transmission sans perte ni d-

squencement, on utilise gnralement le protocole TCP, Transmission Control
Protocol. C'est un protocole orient connexion qui, par une numrotation des octets
transmis, gre un mcanisme de retransmission des donnes perdues [TOU 03]. Le
fonctionnement de TCP repose sur le constat que, dans les rseaux IP filaires, les
pertes sont dues une saturation mmoire de routeurs intermdiaires et non un
problme de transmission. Le protocole TCP possde un mcanisme sophistiqu de
contrle de congestion entre les quipements qui a pour objet de rduire le flux de
donnes en cas de congestion du rseau. Les mcanismes de retransmission et de
contrle de congestion empchent d'utiliser TCP pour toutes les applications qui ont
de fortes contraintes de dlai. On prfre dans ce cas utiliser UDP, ce qui impose de
tolrer des pertes de donnes.
6.2.3.2. Transmission d'IP sur A TM
De nombreux rseaux IP sont bass sur une infrastructure ATM. Le rseau

dorsal est constitu de brasseurs ATM. Les routeurs IP, munis de cartes de
transmission ATM, sont les utilisateurs du rseau dorsal ATM. En dfinissant des
circuits virtuels permanents ATM entre les routeurs IP, l'oprateur peut constituer
un rseau de routeurs IP avec un haut niveau de maillage, comme si ces routeurs
taient physiquement relis entre eux.
Vus du rseau dorsal ATM, les routeurs IP sont des quipements extrmits
(endpoint). La couche d'adaptation utilise est AAL5. Celle-ci est trs simple et
correspond bien l'optique IP o toutes les fonctions complexes sont repousses
dans les terminaux.
Figu re 6.18. Exemple d'architecture en couches pour IP sur A TM
6.2.3.3. Protocole SCTP
Le protocole TCP est bien adapt pour le transport de flux de donnes n'ayant
pas de contraintes temporelles. Il n'est pas conu pour transfrer des messages de
signalisation sur un rseau IP. TCP souffre du problme de Head Of line
Blocking qui fait qu'en prsence d'une perte de paquet, toute la transmission sur la
connexion en cours est interrompue jusqu' la reprise de cette erreur. Cela est
gnant pour le transport de la signalisation, car une mme connexion TCP peut
vhiculer plusieurs transactions de signalisation. Pour le cas d'appels tlphoniques,
cela signifierait par exemple, que la perte d'un segment TCP bloquerait tous les
tablissements d'appels en cours vhiculs sur la mme connexion. Pour rpondre
ces besoins, l'IETF a spcifi un nouveau protocole dans la RFC 2960 : SCTP,
Stream Control Transmission Protocol. Comme TCP, il assure un transfert de
donnes sans duplication et sans erreurs et il est orient connexion, mais le contrle
d'erreur travaille sur des messages (chunk dans la terminologie SCTP) et non sur des
plages d'octets. Il est possible de transporter plusieurs messages dans une unit de
protocole SCTP. En contexte SCTP, une connexion s'appelle une association. Il est
possible de dfinir plusieurs flux logiques dans une mme association, sans qu'un
problme sur un flux n'affecte les autres flux.
6.2.3.4. Couche M3UA
La couche M3UA (SS7 MTP3-User Adaptation Layer) spcifie au sein de

l'IETF dans la RFC 3332 a pour objet de mimer l'interface (au sens des couches
OSI) prsente par MTP3b [RFC 3332]. Elle permet donc de dvelopper un rseau
de signalisation smaphore sur un rseau de transport IP. Au-dessus de M3UA, on
peut mettre les mmes couches qu'au-dessus de MTP3, par exemple la couche
SCCP.
6.3. Principes gnraux de l'architecture en couches dans UTRAN
6.3.1. Strates d'accs et de non-accs
Dans un rseau fixe, le terminal est gnralement reli de faon permanente un

commutateur ou un routeur par une liaison filaire. Il n'y a pas proprement parler
de rseau d'accs mais un ensemble de liaisons d'accs ; les interfaces sont
spcifies au niveau physique. Les changes se font directement entre le terminal et
le rseau cur (c'est--dire un commutateur ou un routeur). Ces changes peuvent
concerner le plan d'usager ou le plan de contrle.
Dans le cas d'un rseau UMTS, l'ensemble des services offerts l'usager est
fourni par le rseau cur comme pour un rseau fixe. Le rseau d'accs UTRAN
doit donc tre le plus transparent possible. Son rle consiste offrir la possibilit au
terminal de dialoguer avec le rseau cur pour la ralisation de ces services.
Le rseau UTRAN vient se placer entre le terminal et le rseau cur. Les

concepteurs de l'UMTS ont voulu garder les mmes protocoles que dans le cas d'un
rseau fixe et, de plus, spcifier ces protocoles de faon indpendante de la
technologie utilise la fois sur l'interface radio et sur l'interface lu. On spcifie
donc dans l'UMTS :
- les mcanismes permettant d'tablir des dialogues entre le terminal et le rseau
UTRAN. Ces mcanismes sont lis la technologie radio utilise mais permettent
de transporter des messages entre le terminal et l'UTRAN indpendamment de la
technologie radio ;
- les mcanismes permettant d'tablir des dialogues entre le rseau UTRAN et le
rseau cur. Ces mcanismes sont lis la technologie utilise pour le rseau de
transport du rseau cur mais permettent de transporter des messages sur l'interface
lu indpendamment de la technologie ;
- les dialogues entre terminal et rseau cur de faon totalement indpendante
des technologies du rseau d'accs (radio et lu).
Les recommandations parlent de strate d'accs (AS, Access Stratum) dans les
deux premiers cas et de strate de non-accs (NAS, Non-Access Stratum) dans le
dernier cas. Les strates sont reprsentes la figure 6.19. Par exemple, les changes
pour effectuer un handover font partie de la strate d'accs, en revanche
l'tablissement d'un appel tlphonique ou une mise jour de localisation fait partie
de la strate de non-accs.
Source : [25.401]
Figure 6.19. Strates d'accs et de non-accs
Le concept de strate de non-accs permet de spcifier les protocoles

d'tablissement d'appels tlphoniques, d'changes de messages courts, etc.
directement entre le mobile et le rseau cur sans considrer le rseau d'accs
UTRAN. Aucun dialogue NAS n'est donc dcrit dans ce chapitre.
6.3.2. Notion de support de transport (transport bearer)
Les donnes et la signalisation sont changes entre le mobile et le rseau cur

via les diffrentes interfaces de l'UTRAN (lu, Iub, Iur) ; elle transitent travers le
rseau de transport. Sur ce dernier, circulent donc des paquets concernant diffrents
mobiles et diffrents quipements de l'UTRAN. Pour permettre un reprage facile
des donnes lies un contexte particulier (par exemple un mobile donn), les
recommandations introduisent la notion de support de transport ou transport
bearer. Un support de transport est tabli entre deux quipements de l'UTRAN (par
exemple un nud B et un RNC) pour permettre le transfert de messages lis un
contexte.
Si l'on utilise un rseau de transport ATM, un support de transport est un

microcircuit AAL2 (voir figure 6.20) identifi principalement par le CID. On
remarque que, dans ce cas, la notion de support correspond une connexion et que
c'est le protocole Q.2630.1 (appel ALCAP, comme expliqu dans le
paragraphe 6.3.4) qui permet l'tablissement du support. Si l'on utilise un rseau IP,
il n'y a pas de notion de connexion ; le support de transport est alors identifi par les
adresses IP des quipements extrmits du rseau de transport (par exemple un RNC

et un nud B) et par un numro de port UDP (ou un numro de tunnel GTP).
Un support de transport peut tre tabli pour transporter des donnes usagers ou
de la signalisation de niveau suprieur. Le rseau de transport ne se proccupe pas
du type de donnes transportes.
6.3.3. Notion de support d'accs radio (RAB, Radio Access Bearer)
La notion de support (bearer) n'est pas restreinte au rseau de transport mais elle
s'tend sur l'ensemble de l'UTRAN. Sur l'interface radio, le protocole RRC permet
l'tablissement de supports radio (radio bearer) entre le mobile et le RNC. On peut
tablir un support radio pour transmettre de la signalisation {signalling bearer) ou
pour transmettre des donnes usagers. Il faut souligner que les extrmits du support
radio sont le mobile et le RNC serveur mais que le support radio implique aussi le
nud B et ventuellement un RNC en drivation et par consquent les interfaces Iur
et Iub. Le support radio s'appuie donc sur des supports de transport pour chacune de
ces interfaces (par exemple des connexions AAL2).
Sur l'interface lu-Cs, il faut clairement distinguer le transport de la signalisation

et celui des donnes usagers. La signalisation est transporte sur une connexion
SCCP. L'aboutement d'un support radio de signalisation (signalling radio bearer) et
d'une connexion SCCP permet le transfert de la signalisation NAS travers
l'UTRAN de faon transparente. Pour les donnes, on utilise un microcircuit AAL2,
dnomm dans ce contexte lu bearer. L'aboutement d'un support radio et d'un
support lu forme un support d'accs radio RAB (Radio Access Bearer). Un RAB est
donc utilis pour effectuer la transmission des donnes usagers entre le mobile et le
rseau cur circuit ou paquet.
Figure 6.20. Notion de RAB

Contrairement GSM o les dbits sont fixes ( 16 kbit/s et 64 kbit/s), le RAB peut avoir un
dbit paramtrable: 12,2 kbit/s pour un usager qui est en communication tlphonique et
128 kbit/s pour un usager qui fait de la transmission de donnes.
Figure 6.21. Souplesse apporte par la notion de RAB
6.3.4. Les diffrents plans
La prsence d'un rseau de transport complique l'architecture en couches du

rseau d'accs : outre les protocoles d'change des donnes utilisateur et les
protocoles de signalisation, il faut prvoir les mcanismes pour tablir les circuits
virtuels entre nuds B et RNC et entre RNC eux-mmes. Ces trois lments
constituent trois plans diffrents : plan usager, plan de contrle et plan de contrle
du rseau de transport.
Le plan de contrle du rseau de transport (Transport Network Control Plane)

contient l'ensemble des couches permettant d'tablir, maintenir et librer des
connexions entre les quipements du rseau d'accs (nuds B et RNC). La couche
la plus haute porte le nom gnrique d'ALCAP (Access Link Control Application
Part). Dans la pratique, ALCAP est le protocole Q.2630.1 prsent au
paragraphe 6.2.2.4. Au niveau du rseau de transport, il s'agit de signalisation qui
fait donc bien partie d'un plan de contrle (control plane).
Tous les autres changes font partie du plan d'usager pour le rseau de transport
{Transport Network User Plane). Les flux de donnes utilisateurs (voix, vido,
donnes) font partie du plan d'usager sans aucune ambigut. Cependant, le rseau
de transport sert aussi changer de la signalisation UMTS (handover, mise jour
de localisation, tablissement d'appel, service supplmentaire). Ces changes font
donc partie du plan de contrle pour le rseau UTRAN mais appartiennent au plan
d'usager vu du rseau de transport car ce dernier n'interprte pas le contenu de ce
qu'il transporte. Les diffrents plans sont reprsents sur la figure 6.22. Lorsqu'on
parle de plan d'usager et de plan de contrle, il faut bien spcifier quel niveau on
se situe.
Source : [25.401]
Figure 6.22. Diffrents plans sur les interfaces de l'UTRAN
6.4. Pile de protocoles de l'UTRAN avec un rseau de transport ATM
6.4.1. Interface Uu
L'interface Uu entre le mobile et le rseau UTRAN est prsente dans le

chapitre 2. Les grandes lignes sont reprises dans cette partie pour les mettre en
perspective avec les autres interfaces (voir figure 6.23).
La couche physique contient tous les mcanismes de transmission entre le

mobile et le nud B. La couche MAC permet de disposer de canaux de transport de
donnes avec un certain degr de protection contre les erreurs (FEC, Forward Error
Correction). La couche RLC (Radio Link Control) gre les mcanismes de
retransmission sur erreur si ncessaire (ARQ, Automatic Repeat reQuest).
La couche RRC (Radio Resource Control) joue un rle central dans le

fonctionnement de l'interface radio. Elle est un peu le chef d'orchestre de
l'ensemble des couches RLC, MAC et physique tout en ralisant des changes de
messages entre le mobile et l'UTRAN.
Figure 6.23. Structure des protocoles sur l'interface Uu
Localisation des entits

Canaux Canaux de Nud B RNC RNC
logiques transport utiliss Contrleur serveur
canaux DCH Physique Phy/MAC/RLC
logiques DSCH Physique MAC MAC/RLC
ddis HS-DSCH Phy/MAC MAC/RLC
RACH/FACH Physique MAC MAC/RLC
canaux RACH/FACH Physique MAC/RLC
communs
canal PCH Physique MAC/RLC/RRC
paging
voie balise BCH Phy/MAC RRC
/RLC/RRC
L'entit physique dans le RNC permet d'assurer la diversit de rception (macrodiversit)

Les entits au-dessus de la couche RLC (RRC dans le plan contrle, PDCP dans le plan
usager pour le mode paquet) sont toujours localises au mme lieu que RLC sauf pour le
BCH dans certains cas.
Figure 6.24. Localisation des entits suivant les diffrents canaux logiques
Les entits protocolaires ct UTRAN ne sont pas toujours localises dans le

mme quipement suivant les diffrents canaux logiques [25.301]. Le cas le plus
courant est constitu par les services d'change d'information entre un mobile et le
rseau (communication vocale, service Web,...) qui utilisent les canaux logiques
ddis. Dans ce cas, les entits MAC et RLC sont localises dans le RNC serveur.
Une partie de la couche physique est galement prsente dans le RNC pour
permettre la macrodiversit. Lorsque le canal logique ddi est fourni par un canal
commun ou partag, quelques fonctions MAC sont places dans le RNC contrleur,
ou mme dans le Node B (par exemple le MAC-hs dans le cas de HS-DSCH).
Lorsque les informations ne sont pas changes avec un mobile particulier

(canaux logiques ddis), les entits sont places dans le RNC contrleur. Pour la
voie balise, les entits MAC et RLC sont directement dans le nud B (voir tableau
de la figure 6.24).
6.4.2. Interfaces lu
L'interface lu se place entre le rseau d'accs UTRAN et le rseau cur.

Lorsque ce dernier est bas sur la commutation de circuits, on parle d'Iu-Cs
(Circuit-Switched), lorsqu'il est bas sur la commutation par paquets, on parle d'Iu-
Ps (Packet Switched). Les deux interfaces peuvent coexister (voir figure 6.6).
6.4.2.1. Interface lu-Cs

La pile de protocole de l'interface lu-Cs est assez complexe du fait des choix
faits :
-utilisation de microcircuits AAL2 tablis la demande pour transporter les
donnes utilisateurs ;
- utilisation de la signalisation smaphore numro 7 (Signalling System 7) ;
- utilisation d'un rseau de transport ATM.
L'interface lu-Cs ne repose pas, strictement parler, sur la commutation de

circuits. En effet, les donnes utilisateurs sont transportes sur une connexion
AAL2. Cette connexion est ralise sur un circuit virtuel ATM. Le qualificatif Cs
(Circuit switched) sert seulement rappeler l'orientation connexion dans le plan
utilisateur. Pour tablir les connexions AAL2, il est ncessaire d'changer de la
signalisation, fonction assure par le protocole Q.2630.1 vu au paragraphe 6.2.2. Sur
l'interface lu, le protocole ALCAP est donc le Q.2630.1. On peut noter qu'aucun de
ces protocoles n'est spcifique l'UMTS. Ils ont t dfinis dans le cadre des
rseaux ATM.
Dans le plan d'usager du rseau de transport, on retrouve galement une couche

physique et la couche ATM. Pour le transport de la signalisation AS, on rutilise
AAL5, SSCOP, SSCF-NNI, MTP3b. Comme dans GSM, on utilise le mode
connect de SCCP pour permettre l'change de la signalisation de gestion de la
ressource radio entre l'UTRAN et le rseau cur. SCCP est utilis pour certains
dialogues en mode non connect mais il est surtout intressant par le service de
connexion qu'il offre [25.410]. Le protocole applicatif, quivalent du BSSAP de
GSM (Base Sub-System Application Part) s'appelle R A N A P (Radio Access Network
Application Part).
Le protocole RANAP a un double rle : il permet le transport des messages NAS

en transparence de l'UTRAN (voir paragraphe 6.3.1) et il est utilis pour tous les
dialogues entre le RNC et le rseau cur. Grce au protocole RANAP, le rseau
cur peut demander l'UTRAN d'appeler en diffusion un mobile sur les cellules
d'une zone de localisation, il peut galement demander l'tablissement d'un RAB
(voir exemples au paragraphe 6.7.1 et suivants), etc.
Figure 6.25. Structure des protocoles sur l'interface lu-Cs (Source : d'aprs [25.410])
6.4.2.2. Interface lu-Ps
Comme pour l'interface lu-Cs, les changes sur l'interface lu-Ps se font sous la
forme de cellules ATM. On retrouve donc une couche ATM et une couche
physique commune. L'interface lu-Ps se distingue de l'interface lu-Cs par le fait
qu'aucune connexion AAL2 n'est tablie la demande lors d'un dbut de session
ou de communication (on reste cependant dans une approche circuits virtuels
permanents au niveau ATM). Il n'y a donc pas de plan contrle du rseau de
transport.
. Les donnes utilisateurs sont transmises dans des paquets IP (d'o le nom lu-Ps).
Pour la gestion de la mobilit, on utilise le protocole GTP (GPRS Tunneling
Protocol) au-dessus d'UDP/IP car il permet la mise en tunnel. Il s'agit plus
prcisment de GTP-U (GTP User Plane) qui est restreint aux fonctions
d'encapsulation et ne comporte pas toute la signalisation de gestion de la mobilit.
Les couches basses sont de faon classique ATM et AAL5.
La transmission de signalisation UMTS peut se faire suivant deux optiques : soit

on considre un rseau smaphore s'appuyant directement sur le rseau de transport
ATM, soit on considre un rseau IP sur ATM transportant la signalisation
smaphore. Dans le premier cas, on trouve, comme pour lu-Cs, les couches SSCOP,
SSCF-NNI et MTP3-B. Dans le second cas (qui sera peu ou mme pas dvelopp),
on trouve IP, SCTP et M3UA. Quelle que soit l'approche considre, le protocole
SCCP est utilis pour transporter les messages RANAP. Le protocole RANAP a le
mme rle que dans le cas de l'interface lu-Cs.
Figure 6.26. Structure des protocoles sur l'interface lu-Ps (Source : [25.410])
6.4.3. Interface Iub
Les changes entre un nud B et un RNC se font via un rseau de transport. On

retrouve donc la couche ATM sur Y interface Iub. Pour la transmission des donnes
usagers, TAAL2 est utilis. Pour tablir les microcircuits AAL2 entre le nud B et
le RNC, on retrouve le protocole Q.2630.1. Cependant le nud B est vu comme un
utilisateur du rseau de transport : l'interface entre le nud B et le RNC est de type
UNI (User-Network Interface) et non NNI (Network-Network Interface). On
retrouve la pile SSCOP, SSCF-UM et Q.2150.2.
Les donnes changes par le mobile circulent dans des canaux logiques sur
l'interface radio. Elles sont galement changes sur l'interface Iub grce des
protocoles FP (Frame Protocol). Ces protocoles transfrent directement les donnes
dans des trames de longueur variable en rajoutant un en-tte trs simple. On a un
protocole FP par canal de transport susceptible de transporter des donnes usagers
(DCH-FP, RACH-FP, FACH-FP, PCH-FP, DSCH-FP, HS-DSCH-FP, USCH-FP et
CPCH-FP). On peut remarquer que les protocoles FP permettent de transfrer la
fois les donnes usagers, la signalisation AS entre le mobile et le RNC, et la
signalisation NAS. Par ailleurs, le protocole FP permet d'changer des trames de
contrle. Ces trames sont utilises pour la gestion de la synchronisation et le
contrle de flux pour le DSCH et le HS-DSCH.
Les protocoles FP permettent de transporter de faon transparente les PDU MAC (dans la
plupart des cas).
Figure 6.27. Structure des protocoles sur l'interface Iub (Source : d'aprs [25.430])
Le protocole NBAP (Node B Application Part) est utilis pour les dialogues
entre le RNC et le nud B. Il permet les fonctions suivantes :
- gestion des liens radios ;
- remontes des mesures radio effectues par le mobile et par le nud B sur un
canal ddi ;
- commande de contrle de puissance vers le nud B ;
- gestion des canaux de transport commun ;
- remonte des mesures communes (se rfrant la cellule toute entire, par
exemple puissance totale d'mission) ;
- configuration de cellules.
Les trois premiers types de messages concernent un mobile particulier, ils sont
donc lis la fonction de RNC serveur (serving RNC). Les autres messages ont trait
la fonction RNC contrleur (controlling RNC). La signalisation NBAP est
change sans connexion. Elle utilise la pile de protocoles AAL5, SSCOP et
SSCF-UNI.
6.4.4. Interface Iur
L'interface Iur prsente des similarits avec l'interface Iub quant aux piles de
protocoles. Il faut permettre au RNC en drivation (drift RNC) de relayer le
trafic dans le plan usager qui est chang entre le mobile et le RNC serveur. On
utilise donc les protocoles FP au-dessus d'AAL2 dans le plan usager. Pour
tablir les connexions AAL2, les protocoles Q2150.1 et Q2630.1 sont utiliss.
Ils peuvent tre transports soit en considrant une pile base sur IP, avec IP,
SCTP et M3UA, soit une pile base sur le SS7, avec SSCOP, SSCF-NNI,
MTP3b.
Le protocole R N S A P , Radio Network Subsystem Application Part, permet la

gestion du lien radio, des mesures radio sur les canaux ddis et du contrle de
puissance. Cette gestion est lie un mobile particulier. RNSAP est utilis aussi
pour la gestion des canaux de transport communs et pour des procdures globales
non lies un mobile. Le protocole RNSAP utilise la signalisation smaphore. On
retrouve donc SCCP sur une interface de type NNI (et non UNI comme Iub).
Figure 6.28. Structure des protocoles sur l'interface Iur (Source : [25.420])
6.4.5. Synthses des piles de protocoles
La figure 6.29 reprsente les couches mises en uvre dans l'UTRAN pour un
service de type circuit. Cette reprsentation fait abstraction du plan de contrle du
rseau de transport (c'est--dire l'ensemble des entits mises en uvre pour tablir
des connexions AAL2). De plus, on reprsente les entits MAC, RLC et RRC sur le
RNC serveur alors que dans certains cas particuliers (voie balise, diffusions de
messages courts,... ), elles se trouvent sur le nud B ou le RNC en drivation.
Le lecteur peut, titre d'exercice, retrouver les piles de protocoles des

figures 6.25 6.28 en faisant une coupe sur chaque interface (lu, Iu-r, Iu-CS). Cette
figure indique quelques protocoles du niveau NAS pour illustrer leur position par
rapport aux autres protocoles. En toute rigueur, on ne devrait pas les reprsenter car
le but de cet empilement complexe dans l'UTRAN est de permettre le transport de
n'importe quel protocole au niveau NAS.
La figure 6.30 reprsente les couches mises en uvre dans l'UTRAN pour un
service de type paquet. Les mmes conventions que pour le service circuit sont utilises.
Sur fond blanc, sont reprsentes les entits qui traitent la fois le contrle et les donnes utilisateurs (c'est--dire couches basses o on ne
spare pas les plans U et C).
Sur fond gris clair sont reprsentes les entits du plan contrle. Sur fond gris fonc, sont reprsents les entits du plan usager.
Figure 6.29. Synthse des couches de l'UTRAN pour un service C S avec transport ATM (schma simplifi)
6.5. Pile de protocoles de l'UTRAN avec un rseau de transport IP
L'utilisation d'un rseau de transport IP ne modifie pas fondamentalement les

piles de protocole. L'interface Uu est bien sr inchange et l'ensemble de la couche
rseau radio (radio network layer) est conserve sur toutes les interfaces (lu, Iub et
Iur). Du fait qu'IP est sans connexion, le plan de contrle du rseau est vide. La
signalisation UTRAN est transporte par le protocole SCCP comme avec un rseau
de transport ATM mais SCCP s'appuie dans ce cas sur M3UA (et non MTP3b) lui-
mme utilisant SCTP.
Figure 6.31. Protocoles sur l'interface Iu-CS avec un rseau de transport IP
Sur l'interface Iu-CS, les donnes usagers sont transportes grce au protocole
de transport temps rel RTP {Real Time Protocol) [RFC 1889] sur UDP (voir
figure 6.31) accompagn ventuellement du protocole de contrle RTCP (RTP
Control Protocol) [RFC 1889]. La pile de protocole est donc assez diffrente du
cas ATM. La pile de l'Iu-PS est beaucoup plus semblable. On utilise GTP-U au-
dessus d'UDP-IP mais on fait l'conomie de la couche ATM (voir figures 6.31a et
6.26).
Figure 6.31a. Protocoles sur l'interface Iu-PS avec un rseau de transport IP
Figure 6.32. Protocoles sur l'interface Iur avec un rseau de transport IP
Le passage d'IP ATM permet de rduire l'empilement protocolaire sur les

interfaces Iub et Iur. Sur l'Iub, la signalisation NBAP est directement transporte par
SCTP/IP et les trames FP par UDP/IP. Sur l'interface Iur, on utilise SCCP comme
avec un rseau de transport ATM mais au-dessus de M3UA/SCTP pour la
signalisation RNSAP ; les trames FP sont transportes par UDP/IP. On peut
galement noter que le plan de contrle du rseau de transport disparat sur
l'interface Iur (voir figure 6.32). L'ensemble des couches est reprsent aux
figures 6.33 et 6.34.
Sur fond blanc, sont reprsentes les entits qui traitent la fois le contrle et les donnes
utilisateurs (c'est--dire couches basses o on ne spare pas les plans U et C).
Sur fond gris clair sont reprsentes les entits du plan contrle. Sur fond gris fonc, sont
reprsents les entits du plan usager.
Figure 6.33. Synthse des couches de l'UTRANpour un service CS sur transport IP

(schma simplifi)
Figure 6.34. Synthse des couches de l'UTRANpour un service PS sur transport IP

(schma simplifi)
6.6. Prsentations des protocoles sur l'interface radio
6.6.1. Couche MAC
Le rle de la couche MAC est prsent au chapitre 2. Nous rappelons ici

brivement les principales fonctions :
- allocation dynamique des ressources de transport (DCA rapide) ;
- correspondance canaux logiques/canaux de transport ;
.I
- multiplexage des canaux logiques ;

- gestion des priorits des diffrents types de trafic ;
- gestion des canaux de diffusion et de paging ;
- contrle de puissance rapide ;
- ARQ hybride (HARQ) pour la transmission sur HS-DSCH (HSDPA) ;
-remise en squence et assemblage et dsassemblage des PDU des couches
suprieures sur l'HS-DSCH ;
- chiffrement si RLC est en mode transparent.
6.6.2. Couche RLC

Le protocole RLC, Radio Link Control, est un protocole de liaison de donnes.
Il permet la fiabilisation, si ncessaire, de la liaison entre le mobile et l'UTRAN.
Les mmes procdures sont spcifies dans le plan d'usager et le plan de contrle
mais il y a des instances diffrentes dans chaque plan. Suivant la qualit de service
dsire, le protocole peut tre utilis en 3 modes :
- le mode transparent (TrD, Transparent Mode Data) o aucune vrification
n'est effectue ;
- le mode non acquitt (UMD, Unacknowledged Mode Data) o les trames
errones sont filtres mais non retransmises (ces trames sont donc perdues et la perte
est dtecte) ;
- le mode acquitt (AMD, Acknowledged Mode Data) o un mcanisme ARQ
(Automatic Repeat Request) permet la fiabilisation par retransmission des trames
errones ou perdues ; un mcanisme de contrle de flux est galement prsent.
Pour les deux derniers modes, le protocole RLC ralise :

- la segmentation et le rassemblage ;
- la concatnation de donnes de niveau suprieur ;
- le chiffrement (lorsqu'il est activ).
Le RLC est un protocole trs souple qui offre de nombreuses flexibilits dans
le transport des donnes. Le mcanisme le plus simple est de transporter un et un
seul SDU dans un PDU RLC mais il est galement possible de segmenter un
long SDU en plusieurs PDU RLC et de grouper plusieurs SDU courts dans un
mme PDU RLC. L'en-tte des PDU RLC est de longueur variable suivant les
cas.
Figure 6.35. Segmentation et groupage par RLC
6.6.2.1. Types de PDU

La norme fait la distinction entre les PDU de donnes et les PDU de contrles.
Les PDU de donnes transportent un SDU tandis que les PDU de contrle ne
contiennent que des informations lies au protocole RLC.
Dans le mode transparent, il n'y a que des PDU de donnes. De plus, il n'y a
aucun en-tte rajout par l'entit RLC. Un PDU correspond donc exactement un
SDU. Dans les autres modes, l'entit RLC rajoute un en-tte pour former un PDU de
donnes. Celui-ci contient un numro de squence (comparable au N(S) de HDLC)
et un indicateur de longueur du SDU. En cas de groupage, il y a plusieurs champs de
longueur puisque le PDU contient plusieurs SDU. Enfin un bit polling permet une
entit de demander un acquittement explicite de l'entit homologue.
Les principaux PDU de contrle sont les suivants :

- remise zro de toutes les variables internes (numrotation, attente
d'acquittement) ;
- acquittement de la remise zro ;
- acquittement ou non acquittement de donnes.
6.6.2.2. Formats gnral de RLC
Le protocole RLC reprend les principes dsormais classiques des protocoles de

liaisons de donnes [LAG 98] :
- numrotation des PDU pour dtecter les PDU manquant la rception ;
-gestion d'une fentre d'anticipation (possibilit d'mettre plusieurs PDU la

suite sans avoir d'acquittement) ;
- rejet slectif possible (retransmission seulement des blocs de donnes mal
reus) ;
-piggy-backing (possibilit d'envoyer des donnes et d'acquitter dans un mme
bloc transmis).
Le protocole RLC offre en plus certaines fonctionnalits peu rpandues dans les
rseaux :
- modification dynamique de la fentre d'anticipation de l'metteur ;
- forage de la fentre du rcepteur.
L'originalit du RLC rside dans la dfinition trs souple des formats de PDU.
Grce la notion de super-champ et de rcursivit, il est possible d'inclure dans un
PDU de donnes un nombre variable de PDU de contrle. En transmettant un seul
bloc, il est par exemple possible de transmettre un PDU de donnes et un PDU de
contrle qui acquitte des donnes reues et modifie la taille de la fentre
d'anticipation.
6.6.3. Couche RRC
6.6.3.1. Services rendus par RRC
La couche RRC (Radio Resource Control) gre l'allocation de la ressource

radio. Du point de vue change protocolaire, elle regroupe tous les changes de
messages d'allocation de canal, de handover, etc. La couche RRC appartient donc
uniquement au plan de contrle 1 . Elle permet galement de transporter les
messages de signalisation de niveau suprieur, qui sont ncessairement de la
signalisation NAS (Non Access Stratum), en tablissant une connexion, appele
connexion RRC, entre le terminal et l'UTRAN. Du point de vue contrle, chaque
entit RRC a galement une action sur les entits de niveau plus bas au sein des
quipements.
Les principales fonctions de RRC sont :

- gestion des connexions radio ;
- gestion des handovers ;
1. A noter que du point de vue des interfaces Iub et Iur, tous les messages RRC sont
transports comme des donnes utilisateurs et donc dans le plan usager (voir figure 6.30).
RRC est utilis pour transporter des messages courts SMS ; c'est un cas particulier o on
transporte des donnes dans le plan contrle.
- contrle de puissance lent ;

- allocation et rpartition des ressources (DCA lent) ;
- gestion de la qualit de service des supports radios.
6.6.3.2. Connexion RRC

Dans beaucoup de systmes, une connexion tablie entre deux points correspond
une rservation de ressource entre ces deux points. Par exemple en GSM, il y a
connexion lorsqu'un canal ddi est allou en propre au mobile par la station de
base. Pour les applications multimdias conversationnelles, il serait coteux de
rserver une ressource radio pendant toute la dure d'une session alors que, trs
souvent, il n'y a aucun transfert de donnes car l'utilisateur est en train d'tudier les
donnes (texte, image,...) qu'il vient de recevoir. Pour conomiser des ressources,
on cherche donc allouer vritablement de la ressource seulement lorsqu'il y a
transfert : c'est le principe du mode paquet. Cependant, il est ncessaire de
mmoriser un contexte correspondant une session en cours entre deux transferts
pour acclrer les procdures d'allocation de ressource. Par exemple, il est utile de
mmoriser la cellule o se trouve l'abonn car il y a peu de chances qu'il se dplace
entre deux transferts de donnes.
Une connexion RRC comprend donc diffrents tats correspondant diffrents

niveaux de ressource alloue comme indiqu la figure 6.36.
L'tat de veille (idle) correspond un mobile non connect. Aucune ressource

n'est alloue ce mobile. On peut remarquer que sa localisation est connue dans le
rseau cur la zone de localisation prs mais que le mobile n'est pas connu, ni
gr par le rseau UTRAN
Dans l'tat Cell DCH, un canal ddi est allou au mobile. Le rseau UTRAN
sait donc parfaitement dans quelle cellule (ou quelles cellules) se trouve le mobile.
La mobilit du terminal est contrle par le rseau UTRAN en fonction des mesures
effectues par le terminal et le rseau (voir procdure de handover).
Dans l'tat Cell_FACH, aucun canal ddi n'est allou mais le mobile est en
coute du canal de transport commun descendant FACH (Forward Access Channel) et
peut transmettre tout moment sur le canal montant RACH {Random Access
Channel). Les canaux RACH et FACH ne sont utiliss que lorsqu'il faut effectivement
transmettre des donnes. Si le mobile (en fonction des critres radio) se cale sur une
nouvelle cellule, il le signale au rseau. Le rseau, en fonction de la configuration
choisie par l'oprateur, peut demander au mobile de transmettre des mesures et en
consquence peut demander au mobile de se caler sur une autre cellule. Dans l'tat
Cell FACH, la mobilit est donc contrle par le mobile ou par le rseau UTRAN.
Dans l'tat C e l l P C H , le mobile se contente de lire le PCH (Paging Channel) (et

le BCH, Broadcast Channel, pour vrifier que les informations systme ne changent
pas). Il peut ainsi dtecter toute demande de la part du rseau. Le mobile dcide de
faon autonome de la cellule sur laquelle il se positionne en fonction des mesures et
des critres radio (voir chapitre 2). Lors de tout changement de cellule, il indique au
rseau la nouvelle cellule o il se trouve. Le rseau connat donc la cellule o se
trouve le mobile ; s'il cherche joindre le mobile, il envoie en consquence un appel
sur le canal PCH de la cellule concerne.
L'tat URA PCH est similaire l'tat Cell PCH mais le mobile signale un
changement de position seulement lorsqu'il change de zone de localisation
UTRAN (URA, UTRAN Registration Area). Le rseau pour joindre le mobile doit
donc envoyer un appel sur le canal PCH de chaque cellule de la zone de
localisation.
L'activit du mobile dans les diffrents tats RRC est rsume dans le
tableau de la figure 6.37. On peut noter que l'tat de veille et l'tat URA PCH
sont assez proches en terme d'activit du mobile. En effet, l mobile reste
joignable en tat de veille : il doit surveiller le canal de paging PCH pour un
ventuel appel et le canal BCH. Il signale un changement de zone de localisation
(LA, Location Area) par une procdure de mise jour (cela signifie qu'il va
passer, au moins temporairement, en tat Cell FACH ou, moins probablement,
Cell DCH suivant le choix de l'oprateur). Notons que les zones de localisation
sont dfinies au niveau du rseau cur alors que les zones URA sont dfinies au
niveau UTRAN. Il est cependant vraisemblable qu'une URA soit incluse dans
ou gale une LA.
Figure 6.36. Etats RRC

Canal de Canal de Contrle de la Niveau Connaissance

transport transport mobilit d'activit par UTRAN
montant descendant
CellDCH DCH DCH rseau +++ Oui
CellFACH RACH FACH mobile ou rseau ++ Oui
Cell PCH PCH, BCH mobile + Oui
URAPCH PCH, BCH mobile - Oui
Veille (Idle) PCH, BCH mobile - Non
Figure 6.37. Activits du mobile dans les diffrents tats RRC
Dans l'ensemble des tats de type connect (Cell-DCH, Cell-FACH, Cell-PCH

et URA-PCH) le mobile est connu du rseau UTRAN. Un contexte est mmoris
dans le RNC serveur. Pour acclrer les procdures et rendre le rseau d'accs
indpendant du rseau coeur, on alloue au mobile une identit appele RNTI (Radio
Network Temporary Identity). Cette dernire identifie la connexion RRC d'un
mobile donn au sein du rseau UTRAN. Elle n'est pas connue du rseau cur.
Pour permettre de minimiser la taille de l'identit et rsoudre tous les cas de figure
de mobilit, il y a plusieurs RNTI :
- le s-RNTI (Serving RNTI) sur 20 bits identifie la connexion RRC pour le RNC
serveur. Elle est alloue par ce dernier. Tant que le mobile reste sous un nud B
dpendant du mme RNC, le s-RNTI suffit identifier sans ambigut la
connexion ;
- l e u-RNTI (UTRAN RNTI) est compos du s-RNTI sur 20 bits et d'un
identificateur de RNC sur 12 bits. Le RNC indiqu est le RNC serveur et l'identit
est appele s-RNCID (Serving RNC IDentity). Par exemple, lorsqu'un mobile dans
l'tat cell-PCH ou URA-PCH passe dans une cellule dpendant d'un RNC diffrent,
il utilise le u-RNTI ; cela permet au nouveau RNC (qui, dans ce contexte, est un
RNC en drivation) de retrouver le RNC serveur.
En cas de procdure de relocalisation, le u-RNTI est chang. Dans tous les autres
cas, il est constant pendant la dure de la connexion RRC.
6.7. Exemples de procdures de signalisation
Dans ce paragraphe, on prsente quelques exemples de procdures de

signalisation pour montrer la mise en uvre des concepts prsents dans les
paragraphes prcdents. On se place dans le cas d'un rseau de transport ATM. Les
procdures sont similaires avec un rseau de transport IP ; les phases
d'tablissement de microcircuits AAL2 sont gnralises en tablissement de

support de transport transport bearer .
Lorsque les fonctions impliquent le rseau cur (dialogue sur l'interface lu), on
considre en gnral l'interface lu-Cs avec un MSC/VLR. Les procdures sur l'lu-
Ps sont relativement voisines.
6.7.1. Etablissement d'une connexion RRC et son utilisation
Source : figures 8 de 25.931
Figure 6.38. Etablissement d'une connexion RRC
Dans la figure 6.38, on dcrit les principaux messages changs dans l'UTRAN
lors du dbut d'un appel, d'un envoi de message, ou de tout service qui rclame une
connexion RRC.
En fonctionnement normal, des connexions AAL2 (c'est--dire des

microcircuits) sont tablies sur l'interface Iub pour le transport des messages
changs sur les canaux radios de contrle commun. Ce transport se fait grce aux
protocoles FP. Pour tablir une connexion RRC, les protocoles RACH-FP et FACH-
FP sont utiliss au dbut de l'tablissement pour transporter les messages RRC.
Le mobile envoie un message de demande R R C C o n n e c t i o n R e q u e s t sur un

canal montant accs alatoire RACH. Il y prcise son identit (par exemple son
TMSI) et le type de service demand. Ce message est reu par le nud B qui le
retransmet au RNC sur la connexion AAL2 utilise pour le protocole RACH-FP.
Ce RNC va fonctionner en RNC serveur (serving RNC). Il va dcider de la
ressource allouer, en d'autres termes du canal de transport adapt au service. On
suppose dans cet exemple qu'un canal de transport ddi DCH est ncessaire. Le
RNC envoie au nud B un message Radio Link Setup Request prcisant au
RNC le canal de transport utilis (formats de transports, frquence, informations
sur le contrle de puissance). Ce message est chang entre le RNC et le nud B :
il est donc de type NBAP. Le nud B alloue les ressources, active sa rception et
acquitte le message prcdent. Pour permettre le transit des messages changs
entre le mobile et le RNC, il faut tablir une connexion AAL2 entre le nud B et
le RNC ; cela est fait grce au protocole ALCAP. Le nud B tablit une
correspondance entre le canal DCH et la connexion AAL2 : tout message reu sur
le canal physique qui porte le DCH et caractris par un code OVSF particulier
(voir chapitre 1) est transmis via le protocole DCH-FP sur la connexion AAL2 ;
rciproquement, tout message reu sur la connexion AAL2 est envoy vers le
canal DCH. Un change de trames de contrle du protocole DCH-FP est ralis
ensuite pour des questions de synchronisation. Le nud B peut alors activer son
mission. A ce moment, le rseau est prt dialoguer avec le mobile sur le canal
ddi mais il faut indiquer au mobile les caractristiques du canal ddi. Cette
indication est transmise par le RNC sur le canal commun FACH dans le message
RRC RRC_Connection_Setup. Le mobile peut alors transmettre sur le canal ddi
DCH. Tous les messages sont retransmis par le nud B vers le RNC grce la
correspondance canal de transport - support de transport (transport bearer), ce
dernier tant matrialis par la connexion AAL2.
Une connexion RRC permet d'changer des messages AS entre le mobile et le

RNC. Ce n'est qu'une tape dans l'tablissement d'un service. Il est ncessaire
d'changer des messages NAS entre le mobile et le rseau cur, reprsent dans
notre exemple par le MSC/VLR. On tablit pour cela une connexion SCCP entre le
RNC et le MSC/VLR et on fait correspondre cette connexion au canal ddi
prcdemment tabli. Les recommandations parlent de connexion de signalisation
NAS.
L'tablissement et l'utilisation d'une connexion de signalisation sont reprsents

figure 6.39. On note que le type de rseau cur est indiqu dans le message RRC
Initial_Direct_Transfer. Lorsqu'il n'est plus ncessaire d'changer des messages
NAS, la connexion SCCP est libre.
Figure 6.39. Transfert de messages NAS via une connexion RRC
6.7.2. Libration d'une connexion RRC
La figure 6.40 donne un scnario de libration d'une connexion RRC. Celle-ci

est demande par le rseau cur (ventuellement suite un message NAS de
raccroch envoy par l'utilisateur). Le mobile est inform de la fin de la connexion
par un message RRC, il acquitte le message et revient en veille. Les microcircuits
sur les diffrentes interfaces sont librs.
Source : figure 9 de 25.931
Figure 6.40. Libration d'une connexion RRC

6.7.3. Etablissement d'une connexion RRC sur canaux FACH-RACH
Lorsqu'un service consiste changer seulement quelques messages NAS (par

exemple une mise jour de localisation sans authentification), il est coteux
d'tablir un canal ddi. On peut dans ce cas tablir une connexion RRC sur une
paire de canaux RACH et FACH. Le droulement est illustr figure 6.41. Il impose
que des connexions AAL2 soient tablies entre le nud B et le RNC au moment de
la configuration par l'oprateur de la cellule gre par ce nud B et que le nud B
effectue la correspondance canal RACH/FACH-connexion AAL2 (c'est--dire canal
RACH/FACH-transport bearer RACH/FACH). Cela est fait en permanence.
Le choix de la ressource attribuer est fait par le RNC. Le message

d'tablissement de connexion est identique celui du paragraphe 6.7.1 mais en
fonction du service demand, le RNC prend une dcision diffrente : au lieu
d'allouer un DCH, il dcide d'utiliser une paire RACH-FACH. Ces deux canaux
tant des canaux communs, il est ncessaire que toutes les transmissions ultrieures
soient identifies. On utilise pour cela le C-RNTI (Cell Radio Network Temporary
Identifier). Un RNTI est un identificateur d'un mobile connu seulement au niveau
UTRAN par le RNC. La lettre C du C-RNTI spcifie que cet identificateur est
unique pour un mobile donn dans une cellule donne. Le C-RNTI est indiqu dans
le message RRC Connection Setup avec l'identit du terminal pour lui permettre de
faire la correspondance. Tous les messages ultrieurs portent le RNTI. Celui-ci est
plac au niveau MAC.
Figure 6.41. Etablissement d'une connexion RRC sur RACH-FACH
Comme au paragraphe 6.7.1, il est possible d'tablir une connexion de

signalisation NAS. Le scnario est similaire la figure 6.39. Cependant, les
messages sont transmis sur un canal DCCH qui correspond un RACH ou un
FACH associ avec le C-RNTI (et non un DCH).
6.7.4. Etablissement d'un RAB
Le RAB permet d'changer, entre un mobile et le rseau cur, des donnes

usager avec certaines caractristiques de dbit, de dlai, etc. En gnral, des
changes de signalisation ont dj t effectus entre le mobile et le rseau au
moment o on dcide d'tablir un RAB (authentification, signalisation d'appel). De
ce fait, la connexion RRC est dj tablie. Nous nous plaons dans un cas o un
canal de transport ddi est dj tabli (il a servi, entre autres, changer les
messages d'authentification).
Le MSC/VLR demande l'allocation d'un RAB en envoyant un message

RABAssignmentRequest. Par dfinition, un RAB est l'aboutement d'un support
sur l'interface lu entre le RNC et le MSC/VLR et d'un support radio entre le RNC et
le mobile. Le support entre le RNC et le MSC/VLR est tabli en utilisant le
protocole ALCAP. Entre le RNC et le terminal, il s'agit d'utiliser la signalisation
RRC sur la connexion RRC afin d'tablir un nouveau support radio pour ce service.
Cela se fait par une suite d'changes indiqus dans la figure 6.42 qui impliquent le
protocole NBAP et le protocole FP.
Figure 6.42. Etablissement d'un RAB en version synchronise

6.7.5. Libration d'un RAB
Lorsqu'il n'y a plus de donnes utilisateur transmettre, le rseau cur peut

demander la libration du RAB. Cela ne signifie pas ncessairement que la
connexion RRC est libre car il peut tre ncessaire de continuer changer de la
signalisation entre le mobile et le rseau. La norme ne dfinit pas un message
RANAP spcifique de libration mais utilise le mme message que l'allocation avec
des paramtres diffrents (voir figure 6.43).
Figure 6.43. Libration d'un RAB en version synchronise
6.7.6. Gestion de la macrodiversit (soft handover)
Nous tudions dans ce paragraphe, les changes protocolaires au niveau UTRAN

lorsqu'un mobile ayant un RAB tabli avec le RNC 1 par l'intermdiaire du nud
B 1 se dplace vers un nud B (nud B 2) dpendant du RNC 2 (voir figure 6.7.) et
continue son dplacement jusqu' tre hors de porte du nud B 1.
Tout mobile ayant une connexion RRC active avec un canal ddi (tat RRC
Cell DCH) renvoie des mesures vers l'UTRAN. Dans l'tat initial de l'exemple,
les mesures sont transmises vers le RNC 1 via le nud B 1. Le RNC 1 est le RNC
serveur et il analyse les mesures. Le signal reu du nud B 2 devenant par

exemple de plus en plus fort, le RNC dcide de mettre le mobile en
macrodiversit, c'est--dire que deux liaisons radios via les nuds B 1 et B 2
soient tablies simultanment. La macrodiversit implique donc le RNC 2 qui va
tre RNC en drivation {drift RNC). Le RNC serveur (RNC 1) demande au RNC
en drivation d'tablir une liaison radio par un message RNSAP ; il prcise les
caractristiques de la liaison (voir figure 6.44). Les changes NBAP entre le RNC
en drivation et le nud B 2 sont ensuite similaires ceux mis en uvre pour
l'tablissement d'une connexion RRC. Il faut en plus tablir les connexions AAL2
sur les interfaces Iur et lu pour permettre la transmission des donnes usagers sur
les deux chemins de diversit. Lorsque toutes les connexions sont tablies et que
le nud B 2 est actif en mission et en rception, un message RRC
Active Set Update indique au mobile les caractristiques du nouveau canal
physique mettre en uvre. Le message est acquitt par le mobile. Selon toute
vraisemblance, le message d'acquittement est reu par le nud B 1 et par le nud
B 2 et arrive jusqu'au RNC serveur.
Figure 6.44. Ajout d'un liaison radio (soft handover)

A l'issue de la procdure, le mobile est en macrodiversit : le canal de transport

DCH est port par deux liaisons physiques radios. Il reoit les messages des deux
nuds B et sa transmission est reue de ces mmes 2 nuds B.
Si le mobile revient sous la couverture exclusive du nud B 1, le lien radio

via le nud B 2 peut tre supprim (retour l'tat initial). Les changes
protocolaires sont explicits dans la figure 6.45. Ils consistent dsactiver tout ce
qui a t activ dans le scnario prcdent : connexions AAL2 et liaison radio sur
le nud B 2.
Figure 6.45. Suppression d'une liaison radio
Considrons nouveau la situation initiale avec le mobile sous la couverture

exclusive du nud B 1. S'il fait une transition franche d'une cellule l'autre,
l'UTRAN peut tablir la nouvelle liaison radio via le nud B 2 et supprimer
l'ancienne via le nud B 1 dans une mme procdure. Ce scnario est illustr
figure 6.46. Il s'agit bien d ' u n soft handover et non d'un hard handover car
l'mission et la rception du nud B 1 sont dsactivs aprs l'activation du nud
B 2. Pendant un court moment (c'est--dire pendant l'mission du message
ActiveSetUpdateComplete), le mobile se trouve en macrodiversit.
Figure 6.46. Ajout et suppression d'une liaison radio (soft handover)
6.7.7. Procdures de relocalisation
Suite un ou plusieurs handover, il peut arriver qu'aucune liaison radio ne passe

par un nud B dpendant du RNC serveur et que toutes les liaisons passent par des
nuds B dpendant du RNC en drivation. La procdure de relocalisation permet
d'assigner le rle de serveur ce dernier RNC.
Dans l'exemple considr, qui fait suite au scnario du paragraphe prcdent, la

procdure de relocalisation permet d'affecter le rle de serveur au RNC 2 et de
librer le RNC 1 de tout rle concernant le RAB du mobile. Elle permet galement
d'tablir une connexion directe entre le RNC 2 et le rseau cur : elle implique donc
le rseau cur. Nous supposons que les RNC 1 et RNC 2 sont relis au mme
MSC/VLR (voir figures 6.8 et 6.9).
Un scnario de relocalisation est prsent la figure 6.47. Le RNC 1 indique

au MSC/VLR qu'une relocalisation est ncessaire : il prcise l'identit du RNC
cible, c'est--dire celui qui doit devenir RNC serveur (ici le RNC 2), et les
paramtres d'identification de la liaison radio devant tre transports de faon
transparente par le MSC/VLR vers le RNC cible. Le MSC/VLR rserve les
ressources internes pour effectuer la commutation le moment venu. Il envoie

ensuite la demande de relocalisation au RNC 2. Ce dernier tablit une connexion
AAL2 sur l'interface lu ncessaire la constitution d'un nouveau RAB passant
par le mobile, le RNC 2 et le MSC/VLR. Lorsque la connexion est tablie, le
RNC 2 cible l'indique au MSC/VLR. La procdure de relocalisation proprement
dite peut alors tre effectue. Pour que les deux RNC soient bien avertis de
l'activation de la relocalisation, le MSC/VLR envoie un message au RNC 1, qui le
renvoie au RNC 2, qui lui-mme avertit le MSC/VLR (messages RANAP
RelocationCommand, RNSAP RelocationCommit et RANAP
Relocation Detect). A l'issue de cet change, le RNC 2 prend le contrle des
entits protocolaires (MAC, RLC , RRC) et le MSC/VLR commute le trafic
usager vers le RNC 2. La relocalisation est faite avec succs lorsque le RNC 2
envoie le message RANAP RelocationComplete. Il reste alors librer toutes les
ressources lies au RNC 1. On peut noter que cet change ne provoque aucune
modification des ressources radio alloues au mobile. Il peut tre cependant
ncessaire d'allouer un nouveau RNTI au mobile ; pour le reste, la procdure est
totalement transparente pour le mobile.
Figure 6.47. Procdure de relocalisation

6.8. Bibliographie
[25.322] 3rd Gnration Partnership Project, Technical Spcification Group Radio Access
Network; RLC Protocol Spcification , 3G TS 25.322, version 3.1.2.
[25.331] 3rd Gnration Partnership Project, Radio Resource Control (RRC) protocol
spcification , 3G TS 25.331.
[25.401] 3rd Gnration Partnership Project, UTRAN Overall Description, Technical
Spcification Group Radio Access Network, 3G TS 25.401.
[25.410] 3rd Gnration Partnership Project; UTRAN lu Interface: General Aspects and
Principles, Technical Spcification Group Radio Access Network, 3G TS 25.440.
[25.420] 3rd Gnration Partnership Project; UTRAN Iur Interface General Aspects and
[25.430] 3rd Gnration Partnership Project; UTRAN Iub Interface General Aspects and
[1.321] ITU-T Recommendation, B-ISDN protocol reference model and its application, 1.321.
[Q.761] ITU-T Recommendation, Signalling System n 7 - ISDN User Part functional
description, Q.761.
[Q.771] ITU-T Recommendation, Functional description of transaction capabilities, Q.771.
[Q.2110] ITU-T Recommendation, B-ISDN ATM adaptation layer - Service spcifi
connection oriented protocol (SSCOP), Q.2110.
[Q.2150.1] ITU-T Recommendation, Signalling transport converter on MTP3 and MTP3b,
Q.2150.1.
[Q.2210] ITU-T Recommendation, Message transfer part level 3 functions and messages
using the services of ITU-T Recommendation Q.2140, Q.2210.
[Q.2630.1] ITU-T Recommendation, AAL type 2 signalling protocol (Capability Set 1),
Q.2630.1.
[Q.701] ITU-T Recommendation, Functional description of the message transfer part (MTP)
of Signalling System n 7, Q.701.
[Q.711] ITU-T Recommendation, Functional description of the signalling connection control
part, Q.711.
[Q.712] ITU-T Recommendation, Dfinition and function of signalling connection control
part message, Q.712.
[Q.713] ITU-T Recommendation, Signalling connection control part formats and codes,
Q.713.
[Q.714] ITU-T Recommendation, Signalling connection control part procdures, Q.714.
[RFC 1889] IETF RFC 1889 RTP: A Transport Protocol for Real Time Applications,
1996.
[RFC 2960] IETF RFC 2960 Stream Control Transmission Protocol (SCTP) , 2002.
[RFC 3332] IETF RFC 3332 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -
User Adaptation Layer (M3UA) , 2000.
[CIZ 04] CLZAULT G, IPv6, thorie et pratique, 4 e dition, O'Reilly, 2004.
[ K O F 9 6 ] KOFMANN D . , GAGNAIRE M . , Rseaux haut dbit : rseaux ATM, rseaux locaux et
rseaux Internet, Editions InterEditions, 1996.
[ L A G 9 8 ] LAGRANGE X . , S E R E T D . , Introduction aux rseaux, Editions Herms, Paris, 1998,.
Principes de communication numrique, du tlphone au multimdia,

[ R I G 0 1 ] RIGAULT C . ,
Editions Herms, Paris, 1998.
[ROL 02] ROLIN P. (coordinateur), Rseaux ATM, Collection IC2, Herms Science, 2000.
[RUS 02] RUSSEL T., Signaling System #7, Editions McGraw-Hill Professional, 4e dition,
2002.
[SAN 01] SANCHEZ J., THIOUNE M., UMTS : Services, architecture et WCDMA, Collection
Rseaux et tlcommunications, Editions Herms, Paris, 2001.
[TOU 03] TOUTAIN L., Rseaux locaux et Internet, 3e dition revue et augmente, Herms
Science - Lavoisier, 2003.
Chapitre 7
Le cur de rseau UMTS
7.1 Introduction
Ce chapitre situe le cur de rseau UMTS dans une volution historique qui
conduit les curs de rseaux des oprateurs de tlphonie mobile traditionnellement
orients commutation de circuit voluer vers des curs de rseau orients paquets.
Il s'attache en particulier suivre la problmatique de la gestion de la qualit de
service lors des diffrentes volutions des curs de rseaux de tlphonie mobile.
La premire apparition d'un cur de rseau orient paquet dans un rseau de

tlphonie mobile est le fait de l'ETSI qui intgre, dans la phase 2+ du GSM, un
cur de rseau IP pour une transmission plus efficace des donnes en mode
paquet ; c'est le GPRS (General Packet Radio Service). Les motivations qui
conduisent un tel choix sont les mmes que celles qui font le succs de
l'Internet, savoir la capacit de partager la mme infrastructure entre un grand
nombre d'utilisateurs, la souplesse de gestion et le faible cot des quipements
d'interconnexion. En effet, le mode circuit, s'il permet une garantie de service
stricte, est coteux en termes de gestion et manque de souplesse dans le partage
des ressources entre les utilisateurs. Il est certes efficace lorsque le trafic a des
caractristiques relativement constantes mais ne permet pas d'utiliser efficacement
les ressources du rseau dans le cas contraire. De plus il s'accompagne le plus
souvent d'une facturation la dure du fait que les ressources sont occupes dans
Chapitre rdig par Jean-Marie BONNIN.

le rseau ds qu'une connexion est tablie mme lorsqu'elle n'est pas utilise. Or
ce modle de facturation est mal adapt aux trafics trs sporadiques
habituellement observs sur l'Internet.
La standardisation du GPRS, puis des diffrentes versions de l'UMTS, a t

dlgue au 3GPP qui poursuit la migration des curs de rseaux de tlphonie
mobile vers des curs de rseaux tout IP. Dans un premier temps (Release 99), le
cur de rseau paquet est rserv aux trafics de donnes et ne subit que trs peu
d'volution par rapport au rseau cur GPRS. Dans un second temps, il ne devrait
plus subsister qu'un seul cur de rseau IP utilis aussi bien pour les flux de
donnes sans contraintes de qualit de service strictes que pour les flux multimdias
conversationnels qui supposent une qualit plus contrle. Cette migration suppose
donc la mise en place de mcanismes de gestion de la qualit de service labors
dans les curs de rseaux IP.
Dans ce chapitre, nous nous attacherons montrer les volutions qui ont conduit
la Release 99 de l'UMTS. En particulier, nous prsenterons le GPRS en ce qu'il
est une premire tape vers le domaine paquet de l'UMTS. Nous ne nous attarderons
pas sur le GSM, ni sur le domaine circuit de l'UMTS puisqu'il a peu volu dans
cette premire version de l'UMTS. Le lecteur intress se reportera utilement vers
[LAG 00] pour la description du GSM. Nous dcrivons ensuite le fonctionnement du
cur de rseau de l'UMTS et nous terminons en donnant les grandes lignes des
volutions venir dans les releases 4 et 5.
7.2. Cur de rseau en GSM et GPRS
Le cur de rseau commutation de circuit GSM est une volution d'un

rseau de tlphonie intgration de services (RNIS) [SER91]. Il est compos
d'un rseau de commutateurs de circuits permettant de commuter le trafic de
tlphonie. Pour les besoins de la tlphonie mobile, certaines fonctionnalits
proches des mcanismes et des concepts des rseaux intelligents ont t ajoutes.
La gestion de la mobilit des terminaux est intgre la dfinition du GSM. Tout
est donc fait pour assurer le maintien des communications lors d'un changement
de cellule, mme lorsque cela implique des changements dans le cur de rseau
(mise en place d'une bretelle entre l'ancien MSC et le nouveau MSC par
exemple). Le support de ces changements est compliqu par les contraintes
temporelles induites par la principale application du GSM qui est la tlphonie.
Nous verrons que, dans le cas du GPRS, certaines de ces contraintes sont allges,
ce qui permet une gestion plus souple de la mobilit.
Le cur de rseau UMTS 273
7.2.1. Architecture du rseau GSM avant le GPRS
Les concepteurs du GSM se sont attachs employer des solutions prouves

pour le sous-systme rseau. Ainsi, le cur de rseau d'un rseau GSM est compos
de commutateurs tlphoniques auxquels ont t ajoutes les fonctions ncessaires
la gestion de la mobilit (protocole MAP, Mobile Application Part) en suivant des
principes similaires ceux qui sont l'uvre dans les rseaux intelligents.
Figure 7.1. Architecture d'un rseau GSM
Deux fonctions ont t diffrencies pour les commutateurs, il s'agit de la

fonction de MSC et de celle de GMSC. Le commutateur MSC (Mobile services
Switching Centre) prend en charge un certain nombre de cellules par l'intermdiaire
des contrleurs de station de base (BSC, Base Station Controller) du sous-systme
radio. Il s'occupe de la gestion d'une zone et des mobiles qui s'y trouvent grce
une base de donnes locale : le VLR (Visitor Location Register). Le GMSC
(Gateway MSC) est un MSC qui assure une fonction de passerelle. Il s'occupe de
l'interconnexion du rseau GSM (le PLMN) avec un rseau de tlphonie fixe
(PSTN) ou un autre PLMN. C'est lui qui va se charger de la gestion des
communications entrantes. En pratique, on reprsente souvent un seul GMSC
connect tous les MSC du rseau, mais en ralit la fonction de passerelle se
trouve intgre dans tous les MSC. Cela permet de rpartir la charge et de rduire la
longueur des chemins emprunts dans le cur de rseau.
Plusieurs bases de donnes sont essentielles au fonctionnement d'un rseau

GSM. En premier lieu, le HLR {Home Location Register) stocke les informations
sur les abonnements et sur la localisation d'une carte SIM, c'est--dire l'identit du
MSC o se trouve le mobile contenant la carte SIM. D'autres bases de donnes sont
utilises pour grer la scurit :
- le serveur d'authentification AuC (Authentication Center) fournit les clefs
d'authentification et est en gnral associ un HLR ;
- l'EIR (Equipment Identity Register) contient les listes des types de terminaux
autoriss fonctionner dans le rseau (liste blanche) et celle des terminaux interdits
dans le rseau (liste noire).
Les terminaux sont identifis dans l'EIR par une identit unique attribue par le
fabriquant : l'IMEI (International Mobile Equipment Identity). La vrification de
l'IMEI et la consultation de l'EIR ne sont pas imposes par les recommandations.
7.2.1.1. Le transport des donnes
Le transport des donnes est possible en GSM classique. Il utilise pour ce faire
un circuit comme dans le cas d'une connexion par modem travers un rseau de
tlphonie commut (RTC). Toutefois, comme les communications vocales sont
encodes et compresses dans le cas du GSM, il est ncessaire d'utiliser un mode de
fonctionnement particulier qui interdit au rseau d'appliquer les encodeurs
spcialiss pour la voix aux communications orientes donnes.
En effet, ces encodeurs utilisent les spcificits de l'audition humaine pour

rduire le dbit ncessaire la transmission de la voix. Ils suppriment une partie des
informations inaudibles, ce qui a pour effet de rendre une communication encode
puis dcode incomprhensible pour un modem. Il est par consquent ncessaire de
diffrencier le trafic de donnes du trafic voix par une procdure de connexion
spcifique qui sera utilise pour le fax, pour le WAP et pour la connexion un
modem analogique ou un terminal RNIS. Dans ce dernier cas, la communication
peut tre numrique de bout en bout. La norme GSM dfinit plusieurs circuits dans
le sous-systme radio : de 1,2 kbit/s 14,4 kbit/s, mais les oprateurs franais n'ont
dploy que le mode 9,6 kbit/s.
Du point du vue du cur de rseau, les communications orientes donnes sont

traites de la mme manire que les communications voix, c'est--dire que le circuit
de 64 kbit/s est rserv dans le cur de rseau pour toute la dure de la connexion.
Cela justifie la tarification la dure applique par les oprateurs mais rend
l'utilisation de ces services trop onreuse pour une large part des utilisateurs.
7.2.1.2. Gestion de la qualit de service
Dans le rseau cur, il n'y a pas de relle gestion de la qualit de service

puisque des circuits de 64 kbit/s sont rservs pour chaque connexion, qu'il s'agisse
de donnes ou de voix. Un tel circuit est rserv pour chaque connexion mme si le
dbit disponible sur le lien radio n'est que de 9,6 kbit/s. Le contrle d'admission
stricte effectu au moment de l'tablissement d'une communication permet de
rejeter une communication si le rseau ne dispose pas des ressources ncessaires.
La signalisation oriente les flux vers les liens MIC (entre les commutateurs) qui
disposent de ressources libres. Il y a donc une gestion des ressources du rseau
plutt qu'une relle gestion de la qualit de service. Aucun mcanisme de
diffrenciation des flux n'est prvu dans le cur de rseau, except pour les flux qui
supposent un traitement particulier (ou une absence de traitement en l'occurrence),
comme les connexions numriques de bout en bout.
7.2.2. Cur de rseau GPRS : un premier pas vers l'UMTS
Avec la mise en uvre du GPRS dans la phase 2+ du GSM, l'ETSI propose un

cur de rseau compltement diffrent du cur de rseau GSM. Il conserve une
interaction plus ou moins forte avec ce dernier en fonction des choix de l'oprateur
et va jusqu' proposer le remplacement de certains des mcanismes auparavant
grs dans la partie GSM (localisation, SMS) pour en amliorer l'efficacit. Il s'agit
avant tout d'un cur de rseau IP spcialis dans le transport des donnes. Le mode
de facturation est mieux adapt au trafic de donnes car on tient compte de la
quantit de donne transfre et non plus seulement de la dure de la
communication.
7.2.2.1. Architecture du cur de rseau mode paquet
Le cur de rseau GPRS est entirement nouveau, aussi bien en termes de

protocoles que pour les entits impliques. Il utilise par contre les bases de
donnes dfinies pour le GSM, quitte en modifier le contenu comme c'est le cas
pour le HLR. Le rle de ce cur de rseau est de transporter les donnes depuis le
rseau d'accs jusqu'aux rseaux de donnes, dsigns sous le terme gnral de
PDN {Packet Data Networks), ou vers d'autres rseau GPRS. Il a fallu ajouter
un rseau IP classique un certain nombre de fonctions dont la gestion de la
localisation et de la mobilit, ainsi que celle de la facturation. Des passerelles
intgrent les fonctions de scurit (contrle d'accs et filtrage) qui sont
ncessaires ds que l'on connecte un rseau commercial l'Internet. Les

diffrentes entits dfinies mettent en uvre les mcanismes de nommage et
d'adressage propres la technologie IP, la fois pour l'adressage interne et pour
l'adressage externe.
Figure 7.2. Architecture d'un rseau GSM/GPRS
Le GPRS est conu comme un rseau de transport multi-protocoles capable

d'offrir une connexion avec diffrents types de rseau de donnes (X25, IP) ; le
support de PPP (Point to Point Protocol) lui permettant mme de transporter
virtuellement n'importe quel protocole support par PPP. Le protocole du rseau
PDN est dsign par le terme gnrique de PDP (Packet Data Protocol). Le
mcanisme de contexte PDP permet d'tablir une connexion pour chaque rseau
de donnes auquel le mobile se connecte. Un contexte est maintenu pour chaque
connexion dans les quipements du rseau impliqus dans l'acheminement des
donnes depuis et vers le mobile. Il comprend, entre autres informations, la qualit
de service demande, le type de rseau de donnes externe et les informations
ncessaires l'identification des connexions supportant la communication dans le
cur de rseau et dans le rseau d'accs.
7.2.2.1.1. SGSN et GGSN

Les deux nouvelles entits intgres au cur de rseau GPRS sont les GSN
(GPRS Support Node) serveur et passerelle. Les GSN sont des routeurs IP enrichis
de fonctions spcifiques au GPRS et d'interfaces leur permettant de communiquer
avec les autres entits du PLMN. En particulier, le SGSN doit tre capable
d'changer les informations avec le HLR et doit par consquent disposer des
couches protocolaires utilises pour la signalisation dans le cur de rseau circuit du
GSM (SS7).
Le SGSN {Serving GPRS Support Node) est l'quivalent du MSC/VLR. Il gre

un ensemble de zones de routage et s'interconnecte au sous-systme radio par
l'intermdiaire des contrleurs de station de base (BSC). Il est responsable de la
gestion des terminaux GPRS qui se trouvent dans une des zones de routage qu'il
gre et s'occupe de la procdure d'attachement, de l'tablissement d'un contexte
PDP et de la collecte des informations de taxation. C'est aussi cet quipement qui
est en charge de la gestion de la mobilit, du chiffrement et de la compression des
donnes changes avec les terminaux.
Le GGSN (GPRS Service Support Node) est la passerelle entre le rseau GPRS
et un rseau de donnes PDN. Les donnes changes entre un mobile et le PDN
passent par le GGSN.
7.2.2.1.2. Fonctionnement du GPRS

Le principe de fonctionnement du GPRS est le suivant : le mobile s'attache au
rseau GPRS au niveau d'un SGSN (Serving GPRS Support Node) et peut ensuite
activer un contexte PDP. Chacun de ces contextes PDP correspond un rseau de
donnes (PDN) auquel le mobile accde par l'intermdiaire d'une passerelle GGSN
donne (Gateway GPRS Support Node). C'est le SGSN qui gre les diffrents
contextes PDP associs au mobile.
Lorsqu'il souhaite communiquer avec un PDN, le mobile active un contexte en

prcisant le nom logique d'un service : l'APN (Access Point Name). Grce l'APN
le SGSN est en mesure de trouver les donnes d'abonnement correspondant ce
service et le GGSN qui permettra d'atteindre le rseau externe. Un tunnel est ensuite
tabli entre le SGSN et le GGSN pour chaque nouveau contexte ; il transporte la
fois les donnes et la signalisation. Les diffrents tunnels suivent les dplacements
du mobile de SGSN en SGSN.
Contrairement au cas d'un circuit GSM o le MSC serveur d'une

communication reste le mme durant toute la communication (notion de MSC
ancre), le SGSN serveur peut changer alors que le mobile est en communication
paquet. Cela peut mme poser des problmes pour les flux de donnes ayant des
contraintes temporelles fortes, puisque le temps de latence d un changement de
SGSN peut tre nettement plus important qu'un changement de MSC dans le
domaine circuit. En fait, dans le cas du GPRS, l'accent est mis sur la fiabilit du
transfert des donnes plutt que sur le respect des contraintes temporelles.
Lors de l'attachement d'un terminal au rseau GPRS, le SGSN tablit un

contexte de mobilit qui comprend les informations de localisation et
d'authentification concernant le terminal. Ds lors que ce contexte de mobilit est
tabli, le SGSN maintient jour la localisation du mobile en fonction de l'tat dans
lequel il se trouve (IDLE, STANDBY, READY). Lors de cette procdure, le SGSN
rcupre auprs du HLR des informations concernant le terminal et l'abonnement
auquel l'abonn a souscrit. Il conserve ces donnes localement tant qu'il gre le
mobile. Elles permettront d'autoriser ou non l'tablissement d'un contexte PDP,
pralable ncessaire toute communication.
L'activation d'un contexte PDP entrane un dialogue entre le SGSN et le GGSN

et est suivie de l'tablissement d'un contexte dans ces deux entits. La qualit de
service obtenue est ngocie en fonction des disponibilits du rseau et des
paramtres d'abonnement de l'utilisateur.
7.2.2.1.3. Evolution ncessaire du HLR

Le HLR assume en GPRS les mmes fonctions que pour le GSM. Il est donc
impliqu dans les procdures d'attachement au rseau GPRS et de gestion de la
mobilit. Le HLR intervient galement pour les communications GPRS entrantes,
mais cette fonctionnalit est optionnelle et n'est pas mise en uvre par les
oprateurs.
Le service GPRS fait aussi voluer le contenu du HLR. Ce dernier stocke les
informations concernant l'abonnement GPRS et les profils (contexte PDP) auxquels
un abonn a souscrit. Un profil d'abonn pouvant contenir plusieurs contextes PDP,
la quantit d'information maintenue par le HLR est donc sensiblement plus
importante en GPRS qu'en GSM.
De plus, certaines de ces informations sont mises jour chaque changement de

zone de routage. Ces changements sont plus frquents que les changements de zone
de localisation du GSM puisque les zones de routage sont plus petites (une zone de
routage est toujours incluse dans une zone de localisation). Le HLR, qui est un
lment critique de l'architecture GSM/GPRS, doit voluer pour tre capable de
grer le surcrot de charge de travail.
7.2.2.1.4. La gestion de la scurit

Le SGSN est en charge des fonctions de scurit et de contrle d'accs propres
au GPRS. Leur fonctionnement est similaire ce qu'il est dans le GSM bien que les
algorithmes de calcul de cl et de chiffrement soient diffrents. C'est aussi le SGSN
qui s'occupe du chiffrement des donnes transmises vers le mobile.
La scurit des communications IP entrantes est assure par les outils

couramment utiliss dans le monde IP (pare-feu) et par le GGSN.
7.2.2.1.5. Architecture en couches du GPRS

L'introduction de GPRS conduit de nouveaux quipements mais galement une
nouvelle architecture en couches. Le plan usager du GPRS (appel plan de transmission
dans les recommandations) est trs diffrent de celui du GSM. Dans le rseau d'accs,
le mobile est connect au SGSN travers une connexion LLC (Logical Link Control),
ce qui rend le transfert des donnes relativement indpendant du rseau d'accs. Le
transfert des donnes usager se fait grce l'aboutement de deux tunnels : la
connexion SNDCP (Sub Network Dpendent Convergence Protocol) entre le SGSN et
le mobile1 et le tunnel GTP (GPRS Tunnel Protocol) entre le GGSN et le SGSN. Les
deux tunnels sont grs indpendamment, ce qui permet d'avoir une mobilit deux
niveaux et de n'impliquer le cur de rseau que lorsque les dplacements du mobile se
font dans des zones de routage gres par des SGSN diffrents.
Figure 7.3. Architecture GPRS du plan de transmission {plan il)
l. Les recommandations n'utilisent pas le terme de tunnel pour la connexion SNDCP, mais on
peut la considrer comme telle.
Comme pour tout rseau IP, l'oprateur est libre de choisir les technologies de
niveau physique et de liaison pour son cur de rseau IP. Le GGSN est un
quipement IP peine modifi tandis que le SGSN est un quipement spcialis
disposant des interfaces spcifiques du GPRS pour la connexion avec les rseaux
d'accs radio (BSS) et les bases de donnes du GSM.
Entre deux SGSN ou entre un SGSN et un GGSN, c'est l'interface Gn qui est
utilise. Elle comporte le protocole GTP qui permet de transporter les donnes et la
signalisation au-dessus d'IP et d'un protocole de transport. GTP peut fonctionner
au-dessus de deux protocoles de transport diffrents, UDP ou TCP. Le choix du
protocole de niveau transport est fait par GTP au moment de la cration du tunnel et
dpend des contraintes qui psent sur les donnes transporter. Ainsi, les donnes
ayant des contraintes quant l'ordonnancement des paquets et la fiabilit du
transfert seront transportes au-dessus de TCP. Les autres, et en particulier la
signalisation, seront transportes au-dessus de UDP. En pratique GTP dispose de ses
propres mcanismes de resquencement, ce qui rend inutile l'utilisation du transport
TCP qui est d'ailleurs abandonne dans l'UMTS.
Figure7.4. Architecture GPRS du plan de signalisation
Le plan de signalisation est trs proche du plan usager. En effet, dans l'esprit
de l'architecture IP, les mmes protocoles sont utiliss pour transporter les
donnes et la signalisation. Sur la partie rseau d'accs radio, la signalisation lie
la gestion des sessions, la mobilit ou au transport des mini-messages (SMS,
Short Message Service) est transporte directement au-dessus de la connexion
LLC. Dans le cur de rseau, rien ne change car c'est une partie du protocole
GTP qui prend en charge la signalisation ncessaire pour l'tablissement des
tunnels et leur gestion pendant les dplacements du mobile. Les relations avec les
lments du cur de rseau GSM et les bases de donnes utilisent toujours les
protocoles de signalisation du GSM.
7.2.2.2. Gestion de la qualit de service
Lors de la demande d'activation de contexte, le mobile fournit cinq paramtres

dcrivant la qualit de service qu'il souhaite obtenir du rseau :
- le niveau de priorit pour l'accs au service [precedence) ;
- la classe de dlai donnant un ordre de grandeur (delay) ;
- la classe de fiabilit permettant de spcifier les mcanismes de fiabilisation mis
en uvre dans les diffrentes couches (reliability) ;
- le dbit maximal instantan donn en octets par heure {peak throughput) ;
- le dbit moyen donn en octets par heure (mean throughput).
La demande d'activation de contexte comprenant les cinq paramtres de qualit

de service est envoye au SGSN. Ce dernier vrifie, grce aux informations
d'abonnement, si l'abonnement donne accs au service demand. Il vrifie aussi
auprs du sous-systme radio que ce dernier dispose des ressources suffisantes pour
satisfaire la demande.
Une fois le GGSN localis grce au nom de service mentionn dans la demande
d'activation (APN), le SGSN demande l'activation du contexte au GGSN en
tablissant un tunnel GTP. Le GGSN contrle la disponibilit de ressources et
module ventuellement la qualit de service suivant les besoins.
Notons que dans la phase 1 du GPRS, la qualit de service est dfinie une fois
pour toutes lors de l'tablissement d'un contexte. Le mobile doit dsactiver et
ractiver le contexte pour en changer les paramtres. Il est prvu que la qualit de
service soit modifiable dynamiquement dans la phase 2 du GPRS mais comme les
implmentations actuelles n'utilisent que le service pour le mieux (Best Effort),
il est peu probable que cette possibilit soit implmente dans le cadre du GPRS.
Une fois l'adresse IP obtenue et le contexte activ au niveau du GGSN, ce

dernier rpond au SGSN que l'activation du contexte est termine et lui transmet
l'adresse IP et les paramtres de QoS dfinitifs. Le SGSN stocke ces paramtres et
active le contexte avant de les transmettre au mobile. A partir de ce moment, ce
dernier peut mettre et recevoir des paquets IP.
Malgr les mcanismes dfinis au niveau de la procdure d'activation de

contexte et dans le rseau d'accs, il n'y a pas, proprement parler, de gestion de la
qualit de service dans le cur de rseau GPRS. Seule la disponibilit de la
ressource minimale est value pour autoriser ou non l'activation du nouveau
contexte et les paramtres de qualit de service ne sont mme pas tudis par le
GGSN. Il existe des propositions utilisant les mcanismes dfinis par l'IETF pour
grer la qualit de service l'intrieur du cur de rseau. Par exemple, certains
constructeurs proposent d'utiliser MPLS (Multi Protocol Label Switching) et
l'architecture diffrenciation de service pour diffrencier plusieurs qualits de
service dans le cur de rseau IP. Nous verrons un exemple de ce type d'intgration
pour l'UMTS. Dans le cas de l'UMTS, l'architecture intgre dj les briques
ncessaires pour assurer la liaison avec les protocoles sous-jacents, ce qui n'est pas
le cas pour le GPRS.
7.2.2.3. Gestion de la taxation
La gestion de la taxation est d'une importance cruciale pour les oprateurs. Le

GPRS permet de diversifier les critres de taxation en fonction de paramtres aussi
divers que la qualit de service, l'heure de la journe, le service demand et bien sr,
la dure de connexion et le volume des donnes transmises. De plus, il peut tre
envisag de combiner plusieurs de ces critres de taxation avec le cot du service
pour rmunrer les fournisseurs de services l'instar de ce qui se passe pour les
services Minitel et plus rcemment i-mode. Cela entrane, une complexit accrue des
mcanismes de taxation dont les oprateurs ne pourront pas faire l'conomie. En
effet, c'est la souplesse de leur systme de taxation qui leur permettra ou non de
rester inventifs et ractifs sur le march des services.
Les entits du cur de rseau GPRS ont un rle important jouer dans le
systme de taxation puisque ce sont elles qui ont la charge de collecter les
diffrents types de tickets de taxation. Les informations contenues dans ces
tickets doivent permettre aussi bien une taxation la dure qu'une taxation au
volume pour laquelle la collecte des informations est plus complique mettre
uvre. Mais il a aussi t envisag de tenir compte de la localisation du mobile
dans le rseau pour pouvoir adapter les tarifs la concurrence locale. Le
mcanisme de collecte des tickets de taxation s'appuie sur les contextes PDP
tablis dans le SGSN et le GGSN. La souplesse de facturation a un cot puisqu'il
est estim que les tickets de taxation gnrs par des communications GPRS
seront dix fois plus importants que ceux qui sont gnrs par les communications
voix.
7.3. Architecture du cur de rseau en Release 99
La Release 99 de l'UMTS intgre le cur de rseau GPRS dans son architecture,

ce qui permet une volution en douceur des rseaux existants vers la tlphonie
mobile de troisime gnration. En effet, seules quelques adaptations mineures sont
ncessaires au niveau des curs de rseaux paquet et circuit pour grer les rseaux
d'accs UMTS (UTRAN).
L'interconnexion entre le rseau cur et l'UTRAN, bas sur ATM, est dcrite dans
le chapitre 6. Nous nous focalisons sur les modifications apportes au cur de rseau
dont la description plus formelle prpare aux volutions profondes qui conduiront un
rseau cur multi-service unifi dans les versions ultrieures de l'UMTS.
Le rseau cur de la Release 99 de l'UMTS est conu comme un rseau de

transition. D'une part, certaines des possibilits de l'UTRAN (support de communication
haut dbit) ne seront pas supportes dans la premire mouture. D'autre part, le rseau
cur est trs fortement coupl avec les rseaux GSM/GPRS existants pour offrir une
transition douce. Ainsi, une volution minimale des curs de rseaux circuit et paquet
peut permettre de servir indiffremment les rseaux d'accs GSM et UMTS.
Figure 7.5. Architecture d'un rseau UMTS (Release 99)
v
A l'instar du cur de rseau GSM, le cur de rseau UMTS de la Release 99 est

divis en plusieurs parties appeles domaines (voir figure 7.8). Le domaine circuit
{CS domain) est une volution du cur de rseau GSM. Il utilise, comme ce dernier,
les MSC/VLR 2 et le GMSC qui assurent les mmes fonctions qu'en GSM. Le
domaine paquet (PS domain) est, quant lui, une volution du cur de rseau GPRS
mais subit un peu plus de changements, mme si les principes de fonctionnement
restent les mmes. On y retrouve les entits fonctionnelles connues du GPRS
comme le SGSN et le GGSN. Enfin, il existe des quipements utiliss par les deux
domaines qui sont classs part, ce sont les bases de donnes issues du GSM
comme le HLR, l'AuC et l'EIR ainsi qu'une nouvelle base de donnes de
localisation appele GLR (Gateway Location Register) [23.002]. Cette base de
donnes est utilise en cas d'itinrance inter PLMN dans les domaines paquet et
circuit d'un rseau visit. Elle permet d'conomiser les messages de signalisation
impliquant le HLR du rseau d'origine. D'autres entits fonctionnelles sont dfinies
pour grer par exemple les services de localisation gographique (service de type
GPS) et les SMS, mais nous ne traiterons pas de leur fonctionnement ici.
7.3.1. Services offerts par le cur de rseau
Le cur de rseau UMTS R99 est prvu pour tre un cur de rseau de
transition vers un cur de rseau multimdia dans lequel les flux de donnes seront
banaliss. Les diffrences qui seront faites pour la voix ou les donnes porteront
seulement sur les attributs du service demand au rseau. En attendant, cette
banalisation est dj commence dans le rseau d'accs radio qui traite la voix
comme un flux de donnes ayant des contraintes de service particulires, notamment
temporelles. Il n'effectue plus de traitement spcifique sur la partie voix. Ces
traitements sont reports l'entre du domaine circuit du cur de rseau.
Le domaine circuit doit supporter un circuit 64 kbit/s par utilisateur et offrir la

possibilit de dbits moindres. Les services offerts aux utilisateurs sont donc
quivalents ceux dont il pourrait disposer sur un rseau RNIS, c'est--dire, la voix
et les donnes numrique ou analogique. Notons que le service de tlcopie (fax)
n'est plus support en tant que tel, mais un serveur externe permet de le grer
l'extrieur du cur de rseau.
Le domaine paquet doit tre capable de supporter des flux de 2 Mbit/s,

l'utilisateur pouvant demander des flux de moindre dbit. Toutefois, si la phase 1 de
2. Les mmes sigles sont utiliss pour l'UMTS et le GSM-GPRS. Lorsqu'une fonction n'est
prsente que pour un quipement UMTS, nous faisons prcder le sigle du prfixe 3G. Par
exemple, 3G-MSC, 3G-SGSN.
l'UMTS dfinit ces supports hauts dbit (2 Mbit/s) dans le rseau d'accs, ils ne
seront pas obligatoirement supports dans le cur de rseau de la premire release
de l'UMTS.
Etant donn que l'utilisateur demande des services de transport en explicitant des
contraintes de qualit de service, l'oprateur associe un cot diffrent aux
diffrentes qualits de service. Il faut par consquent que le rseau soit capable
d'informer le mcanisme de facturation de la qualit de service perue par
l'utilisateur. Cela entrane invitablement une complexit accrue de l'ensemble de la
chane de facturation. Nous verrons plus loin que l'architecture de gestion de la
qualit de service a d'ailleurs t entirement repense du fait de la ncessit de
supporter des contraintes de qualit de service trs variables [23.002].
Le fonctionnement du cur de rseau UMTS (R99) est lgrement simplifi par

rapport celui du GSM. Un certain nombre des fonctions proches de la technologie
utilise dans le rseau d'accs ont t reportes au niveau du RNC. On peut citer
pour l'exemple : le chiffrement pour le domaine paquet, la dtection des erreurs et la
gestion des retransmissions. Ce dplacement permet aussi de rduire le dlai
d'action de ces mcanismes en rapprochant leur traitement du terminal mobile. Il
permet de rendre le 3G-SGSN plus indpendant du rseau d'accs utilis. En effet,
certaines de ces fonctions taient trs lies aux couches radio.
Le cur de rseau conserve le rle de grer les appels et d'initier les demandes
de connexion pour les appels entrants et sortants. Il se charge de router les appels
dans les domaines circuit et paquet. Il intgre bien sr les outils ncessaires la
gestion des abonns, de la facturation et de la maintenance.
7.3.2. Principaux concepts
7.3.2.1. Notion de support de communication (bearer)
Les spcifications de la Release 99 de l'UMTS dfinissent trs formellement la

notion de support de transmission {bearer). Un support de communication est un
ensemble de ressources tablies dans diffrents lments du rseau pour rpondre
un besoin de communication. Il est dfini entre deux entits et comporte les attributs
de qualit de service fournir. Le plus souvent, des ressources de transmissions lui
sont ddies, mais il peut aussi partager les mmes ressources avec d'autres
supports. La notion de support se retrouve de multiples niveaux. Pour l'utilisateur
final, seul compte le support de transmission de bout en bout (End to End Service)
avec les attributs de qualits de service obtenus. Cela implique, sur la partie UMTS,
un support de transmission UMTS (UMTS Bearer) qui est dfini par l'application en
fonction de ses besoins (c'est--dire des attributs choisis pour le support de

transmission de bout en bout). Le support UMTS est ensuite projet sur le rseau
d'accs radio sous la forme d'un RAB (Radio Access Bearer, voir paragraphe 6.3.3),
ce dernier utilisant lui-mme les services d'une connexion sur l'interface radio Uu
{Radio Bearer) et d'une connexion sur l'Interface lu (lu Bearer). Le RAB est
associ une connexion GTP-U dans le cur de rseau (CN Bearer) pour offrir le
service de bout en bout demand par l'application (UMTS Bearer). La dfinition des
attributs d'un support de transmission UMTS est trs prcise. Il en est de mme de
leur projection dans l'UTRAN sur le Radio Bearer ainsi que des mcanismes de
rservation, de contrle d'accs et de rengociation. Par contre, la projection des
attributs de Y UMTS bearer sur le CN Bearer est laisse la discrtion de l'oprateur
et des quipementiers.
Figure 7.6. Notion de support de communication bearer ou service
7.3.2.2. Notion de strates
La notion de strates est un outil permettant de sparer ce qui dpend de la

technologie du rseau d'accs de ce qui n'en dpend pas. Ainsi, la strate appele AS
(Access Stratum) reprend l'ensemble des fonctions dpendant directement du rseau
d'accs. La NAS (Non Access Stratum), quant elle, utilise les services bien dfinis
de l'AS pour offrir des services de plus haut niveau (voir figure 6.19). De ce fait,
elle comprend les protocoles qui mettent enjeu le terminal et le cur de rseau. Les
communications entre les deux strates se font au niveau du terminal ainsi qu'au
niveau du MSC ou du SGSN. Ce chapitre traite principalement des protocoles de la
NAS, ceux de l'AS tant vus au chapitre 6.
7.3.2.3. Deux domaines de fonctionnement : PS et CS

Deux domaines de fonctionnement ont t clairement dfinis dans le cadre de
l'UMTS : le domaine PS (Packet Switching) et le domaine CS (Services Switching).
Au-del d'un exercice de style, ils sont l'expression d'une volont de formaliser les
diffrents modes de fonctionnement du cur de rseau. Ils permettent d'envisager la
dfinition de nouveaux domaines. D'ailleurs, un autre domaine apparat dj dans la
spcification de l'interface lu : le domaine de diffusion (Cell Broadcast).
Dans les premires releases, un domaine comprend la fois les lments utiles
la signalisation et ceux ddis au transport, mais dans les versions ultrieures de
l'UMTS le rseau de transport sera unifi et seuls les lments de contrle seront
spcifiques un domaine particulier. Nous dcrirons l'volution probable des curs
de rseaux vers un rseau cur IP unifi la fin de ce chapitre.
7.3.3. Entits du domaine circuit
Comme le montre la figure 7.5, le domaine circuit est trs proche d'un rseau
GSM. Il comprend de la mme manire un 3G-MSC et un 3G-GMSC, qui assurent
le contrle et le transport des circuits. Par contre, la fonction de transcodage de la
voix est maintenant assure par le cur de rseau et le TRAU ( Transcoder and Rate
Adaptation Unit) se trouve dans le domaine circuit. Cela permet la fois
d'conomiser les ressources du rseau de transport ATM, entre le RNS et le cur de
rseau, et de banaliser le transport de la voix dans le rseau d'accs qui devient un
flux de donnes comme un autre. En effet, l'interface lu offre le mme ensemble de
services quel que soit le domaine de cur de rseau concern. En d'autres termes,
on traite indiffremment la voix et les donnes dans le rseau d'accs radio
(UTRAN).
La signalisation est toujours assure par le rseau smaphore [RUS 02] qui
interconnecte les points smaphores intgrs aux MSC.
La notation MSC/VLR disparat au profit du 3G-MSC qui intgre une base de

donnes VLR. Cela entrine la situation actuelle puisque, du fait du non-respect des
interfaces normalises l'origine entre le VLR et le MSC, les bases de donnes
VLR sont systmatiquement intgres aux MSC. Nous ne diffrencions donc pas les
fonctions du VLR et du MSC dans ce chapitre.
Figure 7.7. Architecture du plan de contrle du domaine circuit de l'UMTS (Release 99)
7.3.4. Entits du domaine paquet
Le domaine paquet subit un peu plus de changement que le domaine circuit du

fait de la volont de rendre le cur de rseau indpendant du rseau d'accs. Ainsi,
si les 3G-SGSN et 3G-GGSN sont les quivalents des GSN du GPRS, le 3G-SGSN
n'intgre plus les fonctions spcifiques au rseau d'accs et laisse aux RNC le soin
d'assurer les fonctions de gestion des communications comme la dtection d'erreur,
les retransmissions, la compression d'en-tte, etc.
7.3.4.1. Le SGSN
Pour assurer ces diffrentes fonctions, le 3G-SGSN dispose de plusieurs
interfaces obligatoires et d'un certain nombre d'interfaces optionnelles qui seront
utilises ou non par l'oprateur en fonction du degr d'intgration des curs de
rseaux circuit et paquet.
L'interface Iu-PS est quivalente l'interface A du GSM et elle remplace

l'interface Gb du GPRS 2G, elle permet d'interconnecter le SGSN et le sous-
systme radio. Alors que l'interface Iu-CS gre des circuits, l'interface Iu-PS
fonctionne en mode paquet ce qui permet d'attribuer les ressources aux utilisateurs
qui sont en train d'mettre un instant donn. Elle effectue un multiplexage
statistique de plusieurs utilisateurs sur un mme lien.
Contrairement au cas de l'interface Gb, l'interface Iu-PS utilise le protocole

GTP-U au-dessus de IP et de ATM/AAL5 pour prolonger le tunnel GTP du cur de
rseau jusqu'au RNC. De fait, c'est maintenant le RNC qui a en charge le traitement
des paquets IP pour les transformer en lments transportables sur la partie radio.
Notons que si cette interface est aujourd'hui dfinie sur un rseau ATM, les futures
versions pourront aussi utiliser un rseau IP natif (voir sections 6.4 et 6.5).
L'interface Gn dfinie entre les 3G-SGSN et le 3G-GGSN permet le transport

des donnes et de la signalisation grce aux services du protocole d'encapsulation
GTP qui fonctionne au-dessus des protocoles de la famille TCP/IP (plus
particulirement UDP). Elle est aussi utilise entre deux SGSN pour la gestion de la
mobilit inter 3G-SGSN.
L'interface Gr permet au 3G-SGSN d'changer les informations concernant les

profils utilisateur et les informations de scurit avec le HLR. Elle suppose
l'utilisation de l'empilement de protocoles propres au GSM, mais il est possible
d'utiliser une passerelle de signalisation, ce qui permet d'viter l'implantation de ces
protocoles sur un routeur IP presque standard.
7.3.4.2. Le GGSN
Le 3G-GGSN supporte deux types de fonction : les fonctions de gestion de la

mobilit et de suivi des mobiles pour lesquels un contexte est activ et les fonctions
de passerelle IP puisqu'il dispose d'une connexion directe avec un ou plusieurs
rseaux publics de donnes (PDN). Il est, comme le 3G-SGSN, charg de collecter
les informations de taxation.
A travers l'interface Gn qu'il a avec le 3G-SGSN, le 3G-GGSN participe la

mise en place d'un contexte PDP et du tunnel GTP qui l'accompagne, lors de
l'activation d'un contexte. A priori, les seules entits UMTS auxquelles un 3G-
GGSN est connect sont les autres GSN, mais il peut disposer d'une interface
optionnelle vers le HLR. Celle-ci est relativement aise mettre en uvre si une
passerelle de signalisation est utilise. Cette interface est utile lorsque les
communications entrantes vers un mobile sont gres par le cur de rseau. Elle
n'est toutefois pas indispensable, car en son absence le 3G-GGSN passe par un 3G-
SGSN qui relaie la signalisation vers le HLR.
Le protocole d'encapsulation GTP est utilis au-dessus de la pile protocolaire

TCP/IP sur l'interface Gn. Grce cela, le rseau de transport peut tre un rseau IP
compos de routeurs standards auxquels il n'est pas ncessaire d'ajouter de
nouvelles fonctionnalits, les GSN se comportant comme des routeurs frontires du
point de vue du cur de rseau IP.
Figure 7.8. Mise en uvre du service IP3
D'un point du vue logique, le 3G-GGSN supporte les fonctions IP d'un routeur
d'accs, comme le filtrage des communications (Access List), le service de
traduction d'adresse (NAT, Network Address Translator). Il relaie les demandes
d'attribution d'adresse vers un serveur DHCP et les demandes d'authentification
vers un serveur Radius, ce dernier pouvant le cas chant se charger de l'attribution
de l'adresse IP la place du serveur DHCP (Dynamic Host Configuration Protocol).
Notons toutefois que la plupart des oprateurs ont choisi d'utiliser des quipements
IP standards pour assurer les fonctions de filtrage (FireWall) et de traduction
d'adresse. Ainsi, un routeur IP soulage le GGSN de ces fonctions en se plaant entre
le PDN (Internet ou VPN) et le 3G-GGSN (voir figure 7.8). Cet quipement prend
3. Dans cette figure et les suivantes, le RAB est reprsent par un tunnel entre le SGSN et le
MS. En pratique, celui-ci est compos de 2 tunnels abouts : le premier au dessus de GTP-U
entre le 3G-SGSN et le RNC et le deuxime entre le RNC et le mobile.
aussi en charge la terminaison des connexions IP scurise (IPsec [RFC 2401]) en

assurant le chiffrement et le dchiffrement des donnes.
7.3.4.3. La fonction de passerelle entre rseau (BG)
Un cur de rseau paquet tant un cur de rseau IP, il est ncessaire de le

protger du monde extrieur. Pour un fonctionnement intra-PLMN, le rseau n'a
besoin que d'un nombre trs limit d'interfaces avec les rseaux extrieurs ; de plus,
ces interfaces sont protges par le GGSN qui filtre les communications
entrantes et ventuellement les communications sortantes. Par contre, pour permettre
Titinrance inter-oprateur (roaming inter PLMN), le cur de rseau GPRS doit
ncessairement disposer d'une connexion IP avec les autres PLMN travers un
rseau inter PLMN. Une passerelle (BG, Border Gateway) assurant des fonctions de
scurit permet de protger le cur de rseau du monde extrieur, mais elle doit
autoriser les communications en provenance d'oprateurs ayant des accords
d'itinrance. Inversement, elle doit permettre les communications sortantes vers les
GGSN des oprateurs dont le rseau accepte les clients (voir figure 7.31).
7.3.4.4. La gestion des noms et de l'adressage
Le cur de rseau IP doit videmment tre configur pour permettre aux GSN
de communiquer entre eux. Pour cela, le routage IP doit tre en ordre de marche
mme s'il peut fonctionner avec un plan d'adressage priv. Il est toutefois
ncessaire, en cas d'accord d'itinrance, de disposer d'un adressage compatible avec
l'adressage des autres PLMN.
Des technologies IP non spcifiques la tlphonie mobile sont utiles au

fonctionnement du GPRS. Le serveur de nom (DNS, Domain Name Server) permet
par exemple de retrouver l'adresse IP du GGSN partir de l'APN (Access Point
Name) fourni dans la demande d'activation. Ce mme service de nom peut aussi tre
utilis pour retrouver l'identit d'un mobile en fonction de son adresse IP lorsqu'il
bnficie d'une adresse IP statique (ce qui est trs rare actuellement).
7.3.4.5. Autres quipements
Pour viter d'avoir implmenter la pile des protocoles SS7 sur tous les GSN du
cur de rseau GPRS et profiter quand mme des interfaces optionnelles, entre les
GGSN et le HLR par exemple, l'oprateur peut mettre en place une passerelle de
signalisation. Cette passerelle dispose d'une interface IP connecte au cur de
rseau GPRS et d'une interface SS7 connecte au rseau de signalisation SS7 de
l'oprateur. Elle se comporte alors dans ce rseau comme un point de signalisation
smaphore (PS) sur le rseau de signalisation du rseau GSM et traduit les requtes
entre les deux mondes.
La gestion de la facturation fait intervenir une entit appele CGF (Charging

Gateway Function), qui est en relation avec le SGSN et le GGSN (voir
paragraphe 7.2.2.3).
7.3.5. Architecture en couches
7.3.5.1. Architecture du plan usager
Figure 7.9. Architecture du plan usager du domaine paquet l'UMTS (Release 99)
Dans le plan usager comme dans le plan de signalisation, l'architecture

protocolaire de l'UMTS R99 diffre sensiblement de l'architecture GPRS. Le
protocole PDCP remplace le protocole SNDCP du GPRS-2G, mais surtout celui-ci
ne s'occupe plus que de la partie RNC-Mobile. Une connexion entre le mobile et le
GGSN est compose en UMTS de trois tunnels abouts. Le premier tunnel sur la
partie radio utilise PDCP au-dessus de la connexion RLC. Le second tunnel entre le
RNC et le 3G-SGSN ainsi que le troisime entre le 3G-SGSN et le 3G-GGSN
utilisent GTP-U ; le protocole GTP-U est la fois une volution de GTP et un sous-
ensemble, car il concerne seulement les procdures dans le plan usager (GPRS
Tunneling Protocol in the User Plane). Cette sparation de la connexion en trois
parties permet de grer trois niveaux de mobilit, ce qui a pour effet de rduire
l'implication du cur de rseau et la surcharge de signalisation.
Contrairement au GPRS 2G o TCP pouvait tre utilis, seul UDP est utilis
pour transfrer l'information. Il est en effet trs rare d'observer des congestions dans
le cur de rseau et les congestions qui entranent des pertes se limitent au rseau
d'accs radio. Ainsi TCP qui a pour fonction de grer la pnurie n'est plus utile, et
cela d'autant moins que GTP-U permet d'assurer une partie de ses attributions,
comme la fiabilisation et l'ordonnancement des paquets.
Plusieurs entits peuvent exister au-dessus de PDCP (voir figure 7.9). C'est
notamment le cas lorsque diffrents contextes PDP sont activs sur un mme
mobile. Chaque entit accde PDCP via un point d'accs particulier. Le point
d'accs est repr par un NSAPI (Network Service Access Point Identifier). Le
NSAPI est un identificateur local un mobile, cod sur quelques bits.
7.3.5.2. Architecture du plan de contrle
Figure 7.10. Architecture du plan de contrle du domaine paquet de l'UMTS (Release 99)
Dans le plan contrle du cur de rseau (voir figure 7.10), c'est une volution de la
partie signalisation de GTP qui est utilise. Il s'agit de GTP-C qui est restreint la
gestion de la signalisation ( G P R S Tunneling Protocol in the Control Plane). Seules
quelques procdures et le contenu des messages diffrent de la version utilise dans le
cadre du GPRS-2G. Pour la partie situe entre le mobile et le 3G-SGSN il y a deux
connexions bout bout. La connexion RRC permet de transporter les donnes des
protocoles de gestion de la mobilit (GMM), des sessions (SM) et des minimessages

(SMS). Elle est gre par l'UTRAN en fonction des tats RRC (voir paragraphe 6.6.3) et
est unique pour les deux domaines circuit et paquet.. La connexion RANAP est diffrente
pour le domaine paquet (vers le 3G-SGSN) et pour le domaine circuit (3G-MSC). Il y a
donc deux connexions diffrentes si le mobile est attach aux deux domaines.
Mme dans le cas d'un rseau cur intgr, c'est--dire lorsque le mme
quipement assure les fonctions de 3G-MSC et de 3G-SGSN (on parle alors de
UMSC) il y a deux connexions RANAP sur l'interface lu (voir figure 7.11 ).
7.3.6. Entits communes aux deux domaines
L'ensemble des bases de donnes ncessaires la gestion des abonns et la

gestion de la mobilit sont communes aux deux domaines. Elles subissent plus de
changements que les autres lments puisqu'elles rpercutent l'ajout de nouvelles
fonctionnalits comme l'environnement virtuel (VHE, Virtual Home Environment)
et les changements dans la notion de qualit de service.
7.3.6.1. Les bases de donnes
Les mmes services d'information sont utiliss que pour les rseaux de seconde
gnration. Ils maintiennent les informations concernant les abonnements des
utilisateurs et les terminaux et grent la partie scurit. Ils sont utiliss aussi bien par
le domaine paquet que par le domaine circuit de l'UMTS.
Le HLR (Home Location Register) conserve les donnes d'abonnement et les

donnes de routage (le 3G-MSC et le 3G-SGSN qui servent un mobile) ainsi que les
contextes PDP souscrits et actifs. C'est un lment trs critique du rseau puisqu'il
est indispensable lors attachement, des changements de zone de routage et de
localisation ainsi que pour les appels entrants. De plus, il gre un grand nombre
d'informations dynamiques pour la partie GPRS.
7.3.6.2. CAMEL
CAMEL ([23.002], [22.078], [23.078], [Q.1214]) permet de dfinir des services
qui seront disponibles mme si l'utilisateur n'est pas attach son rseau d'origine.
Il est une adaptation aux rseaux mobiles du concept de rseau intelligent normalis
ITU-T et met en uvre des entits dcrites au chapitre 8.
7.3.6.3. Service de localisation
Une passerelle de localisation gographique est intgre au cur de rseau

UMTS ([23.002], [23.171]). Elle est responsable de vrifier les autorisations des
applications externes au PLMN demandant une localisation. Elle dispose d'une

interface avec le HLR pour demander les informations de routage qui lui
permettront de contacter le centre de localisation (SMLC, Serving Mobile Location
Centre) intgr au rseau d'accs dont dpend le mobile. Ce dernier est en charge de
coordonner la tche des entits charges d'effectuer les mesures qui permettront le
calcul de la position du mobile.
7.3.7. Intgration des domaines PS et CS
Pour rduire les cots de dploiement et de fonctionnement, les spcifications

prvoient la possibilit de dployer un quipement appel UMSC (UMTS MSC)
qui reprend les fonctions du 3G-MSC et du 3G-SGSN. Cela permet de rduire le
cot de la signalisation et de maintenance du rseau. L'intgration ne change pas
la logique de fonctionnement des deux domaines puisque l'UMSC possde dans
ce cas deux connexions sur l'interface lu correspondant aux deux domaines paquet
et circuit.
Figure 7.11. UMSC et rseau cur intgr
Dans le cas o les quipements ne sont pas confondus, l'UMTS simplifie

grandement les rgles de gestion des procdures combines par rapport GSM-
GPRS. Ainsi, il n'existe que deux modes de fonctionnement, suivant que
l'interface Gs entre le 3G-MSC et le 3G-SGSN est prsente ou non. Dans la suite,
nous considrerons que l'interface Gs est prsente et nous prsenterons les

procdures de gestion combines.
7.4. Gestion des appels et des sessions
Pour ce qui est du cur de rseau, la gestion des appels est sensiblement la
mme dans la premire version de l'UMTS et dans la dernire version du
GSM/GPRS. Seule la partie de la gestion d'appel concernant l'allocation des
ressources dans le rseau d'accs a beaucoup volu. Il y a toutefois une certaine
harmonisation entre les domaines CS et PS, le fonctionnement des sessions paquets
se rapprochant des appels circuits pour la gestion de l'itinrance.
Comme dans le cas du GSM/GPRS un terminal peut appartenir plusieurs

classes. Un terminal de classe PS/CS est l'quivalent d'un terminal GPRS de
classe A, c'est--dire qu'il est capable de se connecter et de communiquer
simultanment dans les deux domaines paquet et circuit. La classe PS limite le
fonctionnement d'un terminal au domaine PS et la classe CS au domaine CS.
Cela dit, il sera possible d'utiliser en UMTS des services de type tlphonie au-
dessus du domaine paquet. On pourrait ainsi voir apparatre des oprateurs ne
possdant pas de domaine circuit et offrant des services de tlphonie au-dessus
d'IP.
7.4.1. Services IP proposs aux utilisateurs
Un oprateur UMTS peut offrir diffrents types de services de donnes (IPv4,

IPv6 et PPP). L'accs X25 (dfini pour le GPRS) n'est pratiquement pas utilis et
n'a pas t reconduit pour l'UMTS. PPP est une solution intressante, mais n'est pas
encore offerte par les oprateurs. IP est donc le seul service gnralement
disponible.
Il existe deux manires diffrentes d'offrir un service IP, suivant que le GGSN
gre le service de manire transparente ou non. Dans le second cas, il participe la
phase d'tablissement de contexte en dialoguant avec le rseau de donnes cible
(PDN) pour obtenir une adresse IP et vrifier les autorisations dans le rseau visit.
Le GGSN agit dans ce cas au nom du terminal mobile pour obtenir les informations
ncessaires.
Une entreprise peut ainsi disposer d'un lien direct avec le GGSN (une ligne
loue, un lien El, une connexion IPSec, ...) qui permettra ce dernier d'interroger
le serveur RADIUS de l'entreprise plutt que celui de l'oprateur. L'adresse alloue

au mobile appartient alors l'espace d'adressage du VPN de l'entreprise
Figure 7.12. Mise en uvre d'un service IP dans le cas d'un service VPN.
Dans le cas du service transparent, le mobile dispose d'une adresse au sein du

rseau GPRS (voir figure 7.12). Cette adresse peut tre une adresse IP statique (le
rseau la fournit travers le contexte PDP), ou tre fournie par le rseau GPRS.
7.4.1.1. La notion d'APN

En activant un contexte PDP, le terminal demande l'accs un service de
donnes et de fait un rseau externe de donnes (PDN). Il peut y avoir plusieurs
services donnant accs au mme rseau externe de donnes mais avec diffrentes
caractristiques de protection (configuration du pare-feu), d'adressage (adresse
publique ou prive), etc. Chaque service est identifi par un APN (Access Point
Name). Le cas du service de gestion de la mobilit IPv4 en est un exemple :
considrons un terminal qui veut un accs au rseau Internet avec le support de la
mobilit IPv4 ; il lui suffit de prciser seulement l'APN correspondant ce service
pour son oprateur d'origine (HPLMN) dans la demande d'activation de contexte.

Dans les rseaux GPRS actuels, les diffrents APN correspondent gnralement :
- au WAP (l'APN sera par exemple wap.syldavie-telecom.com) ;
- un abonnement pour usage personnel avec une adresse prive et la possibilit
de faire de la messagerie et de la navigation Internet (par exemple gprs.syldavie-
telecom.com) ;
- un abonnement professionnel avec une adresse publique et la possibilit
d'utiliser plus de protocoles (par exemple entreprise.syldavie-telecom.com) ;
- un accs Internet en utilisant la mobilit IPv4 (MobileIPv4).
Le SGSN utilise le service de nom (DNS, Domain Name Service) [RFC 1034,
RFC 1035] pour dterminer l'adresse IP du GGSN correspondant l'APN demand.
Grce ce mcanisme, l'oprateur peut facilement rpartir la charge sur plusieurs
GGSN sans pour autant compliquer la gestion des profils utilisateurs. En effet, il
suffit que le serveur de nom DNS donne l'adresse IP du GGSN le plus proche de la
localisation actuelle du mobile ou celle du GGSN le moins charg un instant
donn.
En pratique il s'agit d'un nom logique utilisant la mme syntaxe que pour les
noms de machine dans l'Internet 4 , savoir des labels spars par des points. Il peut
n'y avoir qu'un seul label et le premier label reprsente en gnral le nom d'un type
de service, il indique au GGSN le type de support que ce dernier doit fournir pour le
contexte. C'est le cas par exemple pour MobileIPv4.
Comme pour les noms machine, un APN peut tre compltement qualifi en
ajoutant l'identifiant de l'oprateur suivant la convention de nommage dfinie dans
les recommandations [23.003] et [23.060)] : MCCXXX.MNCYYY.gprs, o XXX et
YYY sont respectivement le numro du pays et le numro de l'oprateur. Un nom
compltement qualifi est ncessaire pour le roaming international, il peut tre
construit automatiquement par le SGSN partir de l'IMSI du mobile et de l'APN
fourni dans la demande d'activation.
7.4.1.2. L'adressage IP
Dans le cas du service IP, les adresses IP attribues au mobile peuvent tre
statiques ou dynamiques, publiques ou prives. Par statique, on entend
gnralement le fait que le mobile connat son adresse et qu'elle est donc
configure au niveau du terminal par l'usager. Dans le cas du GPRS, l'adresse
4. L'utilisateur n'a pas forcment connaissance du nom complet de l'APN auquel il accde. Il
n'utilise souvent que le nom logique du service. Le SGSN complte le nom fourni lors de la
demande d'activation de contexte en fonction de sa configuration.
peut galement tre configure statiquement au niveau du contexte PDP stock par
le HLR. Elle est alors fournie au mobile lorsqu'il active le contexte. Cela ne
prsume pas du fait que l'adresse soit publique ou prive. En pratique, dans la
plupart des offres actuelles, les adresses sont dynamiquement attribues par
l'oprateur au moment de l'activation du contexte. Elles sont la plupart du temps
prives, sauf dans le cas d'abonnements professionnels dont les utilisateurs ne
peuvent pas se passer d'une adresse publique. Lorsqu'il s'agit de l'accs un VPN
d'entreprise, gnralement rserv aux grands comptes, le choix d'un adressage
priv ou public est laiss la discrtion du VPN, tout comme la gestion de la
scurit.
Dans le cas de l'adressage priv, le service offert n'est pas rellement un

accs Internet, puisqu'il suppose une traduction d'adresse au niveau du GGSN ou
d'une autre passerelle d'entre (figure 7.12). Il est toutefois possible d'offrir
malgr tout un service satisfaisant pour la majorit des utilisations en traduisant
tous les protocoles. Il reste malgr tout impossible d'utiliser certains modes
d'IPSec, les protocoles de visioconfrence ou de tlphonie sur IP, et plus
gnralement les protocoles inconnus de la passerelle. Mais, dans le pire des cas,
cette traduction n'est pas transparente en ce sens qu'elle n'autorise qu'un nombre
trs limit de protocoles : l'usage d'Internet est alors limit la navigation HTTP
et quelques protocoles dtermins par l'oprateur. Cela limite fortement
l'innovation et le dynamisme qui font le succs d'Internet, la mise en place de
tout nouveau protocole supposant une nouvelle configuration des passerelles des
oprateurs.
Les oprateurs avancent plusieurs arguments pour justifier l'utilisation d'un

adressage priv. En premier lieu, la trs faible quantit d'adresses IPv4
disponibles par rapport au nombre d'abonns les place dans l'incapacit
d'attribuer une adresse IPv4 chaque abonn GPRS. La seule solution ce
problme serait le passage IPv6 [CIS 02] qui souffre encore d'un manque
d'applications et de services. En second lieu, l'attribution d'une adresse IP
publique permet au mobile d'tre joignable ds lors que le contexte associ cette
adresse est activ. Si, dans le cas d'un adressage priv, il est ncessaire que le
mobile initie les communications pour recevoir des paquets IP, ce n'est plus le cas
si le mobile dispose d'une adresse publique : n'importe quel quipement connect
sur Internet peut mettre des paquets destination du mobile. Mme si le mobile
ne souhaite pas les recevoir et mme si, en fin de compte, il les rejette, le cot li
la transmission de ses paquets sera imput l'abonnement associ au contexte
PDP actif. Le mobile n'a aucun moyen d'en empcher la transmission. Le
problme est encore plus sensible lorsque l'adressage est public et statique car,
dans ce cas, l'oprateur peut autoriser le rseau lancer la procdure d'activation
de contexte lorsqu'il reoit une communication entrante alors que le contexte

auquel est associe l'adresse IP n'est pas activ. On imagine aisment les
possibilits d'attaques par dni de service qui seraient trs faciles effectuer si
une telle possibilit tait gnralise tous les abonns.
7.4.2. Etats de fonctionnement d'un mobile
Contrairement ce qui se passe dans le cas du GSM/GPRS les diffrents tats de

fonctionnement sont trs proches pour le domaine circuit et pour le domaine paquet.
Ds que le mobile active un service, une connexion est tablie avec le RNC qui le
sert.
7.4.2.1. Domaine circuit
Figure 7.13. Les tats d'un mobile dans le domaine CS
Dans le domaine circuit, la procdure d'attachement joue le mme rle et se fait

de la mme manire que dans le cas du GSM [LAG 00]. Au dmarrage, le mobile
est dans l'tat DETACHED et il n'est pas encore connu du rseau. Une fois le
mobile attach au rseau, ce qui se fait gnralement automatiquement lors de
l'allumage, un contexte de mobilit est cr et le mobile est repr, la zone de

localisation prs, par le 3G-MSC et, au 3G-MSC prs, par le HLR.
Une fois attach au rseau, le mobile peut tre dans deux tats diffrents.
L'tat IDLE indique qu'il est prs initier ou recevoir une communication. Le
mobile gre lui-mme la mobilit ; il slectionne la cellule en utilisant la
procdure de reslection et informe le 3G-MSC de tout changement de zone de
localisation.
Lorsque le mobile est en communication, un circuit est tabli dans le rseau

cur et dans le rseau d'accs. Le mobile passe alors dans l'tat CONNECTED.
C'est le rseau d'accs radio (UTRAN) qui gre la mobilit en utilisant les
mesures effectues par le mobile et transmises au RNC (voir chapitre 6).
7.4.2.2. Domaine paquet
Figure 7.14. Etats P MM d'un mobile maintenus par le SGSN dans le domaine PS
Dans le domaine paquet, les diffrents tats sont PMM-DETACHED, PMM-

IDLE et PMM-CONNECTED. Le premier tat correspond au moment o le mobile
est teint ou n'est pas encore attach au domaine paquet. Le rseau ne maintient
aucune information quant la localisation du mobile. Ce dernier s'attache grce la
procdure GMM-Attach et passe alors dans le mode PMM-IDLE une fois la
procdure termine. Dans cet tat, le rseau suit le mobile la zone de routage prs
et ce dernier doit effectuer les mises jour de zone de routage vers le 3G-SGSN.
Lorsqu'il y a changement de SGSN, la mise jour de localisation implique aussi le
HLR qui suit le mobile au SGSN prs.
L'tat PMM-CONNECTED indique qu'une connexion RRC/RANAP est tablie

entre le mobile et le 3G-SGSN. Dans cet tat, le mobile est suivi par le SGSN au
RNC serveur prs, ce dernier tant charg de suivre le mobile avec un degr de
prcision dpendant de l'tat de la connexion RRC (voir paragraphe 6.6.3). Le
mobile repasse automatiquement l'tat PMM-IDLE lorsque la connexion de
signalisation est rompue, volontairement ou non. En fait, l'UMTS est conu pour
maintenir les contextes PDP indpendamment de la connexion de signalisation. Le
SGSN peut ainsi maintenir les contextes PDP actif sans consommer de ressource sur
l'interface radio lorsque l'tat PMM est IDLE. Dans l'tat PMM-CONNECTED,
c'est le RNC serveur qui gre la mobilit du terminal, ce qui dcharge le cur de
rseau de la gestion de la mobilit ; la manire de grer les handovers dpend de
l'tat RRC.
7.4.3. Attachement aux domaines PS et CS
Le principe de l'attachement comme pralable toute action du mobile est

conserv dans l'UMTS. Il permet au rseau de s'assurer de l'identit du mobile et de
la validit de l'abonnement de l'usager. C'est lors de cette procdure qu'un
oprateur refusera les demandes d'attachement provenant de l'abonn d'un
oprateur avec lequel il n'a pas d'accord d'itinrance. De plus, contrairement au cas
du GSM, le mobile peut lui aussi vrifier que le rseau auquel il tente de s'attacher
est bien celui qu'il prtend tre puisque l'authentification est rciproque (voir
chapitre 10).
7.4.3.1. Procdure d'attachement

La procdure d'attachement se droule de la mme manire dans les domaines
CS et PS. Le mobile s'identifie auprs du rseau avec son IMSI ou une identit
temporaire (TMSI, P-TMSI) qu'il conserve dans la carte USIM.
Dans l'exemple, on suppose que le mobile n'est pas encore attach au rseau
et qu'il ne dispose pas des identits P-TMSI et TMSI. Le mobile demande
simultanment l'attachement IMSI et GPRS aux domaines circuit et paquet. Les
procdures de scurit permettent de vrifier que l'abonnement associ la carte
USIM autorise l'accs au rseau. Le rseau vrifie aussi que le terminal n'est
pas un terminal vol si cette fonction est active par l'oprateur. Si tout se passe
bien, le 3G-SGSN inscrit la nouvelle localisation du mobile dans le HLR. Ce

dernier rpond en donnant le profil de l'abonn, ce qui permet au 3G-SGSN de
maintenir sa propre copie des informations d'abonnement. Lorsque la procdure
de mise jour de la localisation du domaine paquet est termine, le 3G-SGSN
initie la procdure de changement de localisation du domaine circuit qui se
droule de la mme manire. Les deux procdures termines, le 3G-SGSN
signale la fin de la procdure d'attachement au mobile puis transmet
l'acquittement du mobile au 3G-MSC pour que ce dernier puisse clore la
procdure son tour.
Figure 7.15. Procdure d'attachement combin aux domaines circuit et paquet (UMTS)
7.4.3.2. Procdure de dtachement

Le dtachement peut tre initi par le mobile, le SGSN ou le HLR. Lorsqu'il
est dclench par le mobile, il permet ce dernier d'indiquer au rseau qu'il n'a
plus besoin des services du domaine circuit, du domaine paquet ou d'aucun des
deux domaines selon qu'il s'agit d'un dtachement IMSI, GPRS ou combin.
Lorsque c'est le rseau qui le dclenche, il informe le mobile que le service ne
peut plus lui tre rendu (problme de ressources insuffisantes ou de crdit puis).
A la fin de cette procdure, le rseau peut librer les ressources occupes par les
informations concernant ce terminal (stockage du profil dans le SGSN, par
exemple).
Le dtachement peut aussi tre implicite lorsque la connexion avec le mobile est
rompue pendant un certain temps, ce qui vite au rseau de conserver des donnes
inutilement.
Figure 7.16. Procdure de dtachement combin aux domaines circuit et paquet (UMTS)
Dans l'exemple (figure 7.16), la procdure de dtachement est initie par le

mobile qui demande un dtachement combin. Il peut aussi indiquer si cette
demande fait suite l'extinction du terminal ou non. Le 3G-SGSN contacte les
GGSN qui maintiennent des contextes PDP pour ce terminal pour que ceux-ci les
dtruisent. Il prvient ensuite le 3G-MSC du dtachement (flche ).
Dans le cas o le dtachement ne concerne que le GPRS, il est quand mme

ncessaire de prvenir le 3G-MSC (flche (D) pour que celui-ci supprime la
rfrence au 3G-SGSN serveur et qu'il gre les pagings et les changements de
localisation sans passer par ce dernier.
7.4.4. Gestion des appels du domaine CS
Dans le cur de rseau, la procdure d'tablissement d'un appel circuit ne

change pratiquement pas par rapport au GSM. Voir [LAG 00], pour plus de dtails
sur ces procdures.
7.4.4.1. Etablissement d'un appel CS sortant
Le mobile qui souhaite effectuer un appel commence par tablir une connexion
de signalisation travers l'UTRAN vers le 3G-MSC. Ce dernier authentifie le
mobile et met ventuellement en place le chiffrement.
Le mobile peut alors mettre la demande d'tablissement d'appel qui

dclenchera la procdure d'attribution des ressources dans le rseau d'accs. Le
3G-MSC fera suivre la signalisation vers le rseau tlphonique (PSTN) en utilisant
les protocoles de signalisation de ce dernier (ISUP). Le mobile est inform lorsque
le tlphone du destinataire sonne puis lorsque ce dernier dcroche. A la fin de la
conversation, les ressources sont libres dans l'UTRAN (non reprsent).
Figure 7.17. Etablissement d'une connexion dans le domaine circuit (appel sortant)
7.4.4.2. Etablissement d'un appel CS entrant
Lorsque le rseau reoit un appel entrant pour le numro d'un mobile, il doit
d'abord localiser ce dernier. Le GMSC rceptionnant la demande interroge pour cela
le HLR qui est capable de faire la relation entre le mobile et le 3G-MSC qui le gre
au moment de l'appel. Le HLR relaie la demande vers le 3G-MSC et lui demande
un numro gographique de roaming correspondant au mobile (MSRN, Mobile
Station Roaming Number). Le HLR fait ensuite suivre la demande d'tablissement
d'appel vers le 3G-MSC. Ce dernier, s'il ne connat pas forcment la localisation
courante du mobile la cellule prs, connat au moins la zone de localisation dans
laquelle il se trouve. Il peut donc dclencher une procdure de paging pour localiser
le mobile.
Suite la procdure d'tablissement du support RAB qui suit la procdure de

scurit, le mobile rpond qu'il prvient l'utilisateur (sonnerie), puisque ce dernier
dcroche. Ces messages sont relays vers le correspondant dans le rseau
tlphonique (PSTN).
Figure 7.18. Etablissement d'une connexion entrante dans le domaine circuit (appel entrant)
7.4.5. Gestion des sessions du domaine PS
Il n'y a pas vraiment de notion d'appel dans le domaine paquet. Le terminal

ouvre ou ferme des sessions de communications de donnes par l'intermdiaire des
procdures d'activation et de dsactivation de contexte.
7.4.5.1. La notion de contexte PDP
Le rle du contexte PDP est semblable ce qu'il est en GSM/GPRS. Toutefois,

un certain nombre de modifications ont t apportes pour en assouplir l'usage. Un
contexte peut, comme en GSM/GPRS, tre activ et modifi 5 , mais il est aussi
possible d'ajouter un contexte un contexte dj activ pour une mme adresse PDP
et de prserver le contexte lorsque la connexion entre le mobile et le rseau cur
tombe dans l'UTRAN.
Un contexte PDP est activ par le terminal et stock la fois au niveau du

terminal et dans les entits du rseau cur 3G-SGSN et GGSN. De plus, et
contrairement au cas du GPRS 2G, le rseau d'accs conserve un contexte PDP
simplifi comprenant, entre autres choses, la qualit de service ngocie, pour lui
permettre d'tablir ou de rtablir un support de communication radio (RAB)
disposant des ressources ncessaires ce contexte. Il comprend aussi une copie des
numros de squence des messages en cours de transfert qui seront utiliss pour
fiabiliser le transport des donnes lors des changements de RNC serveur
(relocalisation).
Les paramtres contenus dans un contexte PDP UMTS sont diffrents de ce

qu'ils taient en GPRS 2G en ce qui concerne le contenu des profils de qualit de
service (voir paragraphe 7.2.2.2). Un contexte PDP correspond une adresse, dite
adresse PDP. Il s'agit d'une adresse IPv4 ou IPv6, publique ou prive, statique ou
dynamique (voir la discussion sur l'adressage dans la partie GPRS). Un contexte
PDP est valable dans un rseau de donnes externe (PDN) identifi par le nom de
l'APN lors de l'activation de contexte.
Un contexte PDP peut tre inactif, il contient alors les informations lies
l'abonnement souscrit, ou actif lorsque l'abonn a activ un contexte PDP. Chaque
contexte PDP contient les informations suivantes lorsqu'il est inactif :
- type de contexte que l'abonn peut activer (IPv4, IPv6 ou PPP) ;
-adresse du mobile dans le rseau auquel on accde. Ce champ est vide si
l'adresse est alloue dynamiquement lors de la phase d'activation ;
5. Bien que cette possibilit ne soit pas encore implante dans les rseaux GPRS franais.
-adresse de l'APN (Access Point Name), qui permet d'identifier le GGSN

associ ce contexte sous la forme d'un nom logique (voir paragraphe 7.4.1 ) ;
- informations concernant la qualit de service laquelle l'abonn peut
prtendre.
Figure 7.19. Informations maintenues dans les diffrentes entits
A ces informations s'ajoutent d'autres informations inscrites lors de l'activation

d'un contexte :
- adresse dans le rseau externe d'accueil (lorsqu'elle est alloue
dynamiquement) ;
- TEID (Tunnel Endpoint Identifier), identification du tunnel GTP sur la partie
cur de rseau ;
- adresses du SGSN et du GGSN ;
-paramtres de qualit de service effectivement ngocis lors de la phase
d'activation et qui tiennent compte la fois des ressources disponibles dans le
rseau, de la demande formule par l'abonn lors de la phase d'activation du
contexte et des donnes contenues dans le profil inactif.
7.4.5.2. Activation d'un contexte PDP

L'activation d'un contexte PDP est toujours dclenche par le mobile. Toutefois,
dans certains cas (lorsqu'il y a du trafic entrant), le rseau peut en tre l'initiateur en
demandant au mobile d'activer un contexte particulier. L'objectif de la procdure
d'activation est multiple :
- permettre au PLMN de vrifier que le mobile est habilit utiliser ce service
de donnes avec la qualit de service demande ;
- faire connatre le mobile et son adresse PDP au niveau de la passerelle vers le
rseau externe de donnes correspondant l'APN demand (c'est--dire le GGSN) ;
- mettre en place le tunnel GTP-U dans le rseau cur entre le 3G-SGSN et le
GGSN, ainsi que le tunnel GTP-U entre le RNC serveur et le 3G-SGSN, et le tunnel
PDCP entre le RNC et le mobile dans l'UTRAN. Il peut y avoir plusieurs tunnels
abouts dans l'UTRAN lorsqu'il y a un RNC en drivation.
Figure 7.20. Activation d'un contexte PDP
Sur la figure 7.20, l'activation d'un contexte PDP est reprsente. Le mobile doit
tre attach au domaine paquet du PLMN pour pouvoir demander l'activation d'un
contexte. Dans le message de demande d'activation d'un contexte PDP, il indique :
- le type de contexte qu'il demande (PPP, IPv4, IPv6) ;
- l'adresse IP, s'il souhaite imposer une adresse statique ;
- l e nom de l'APN qui rfrence un service (dfini l'intrieur du PLMN
d'origine) ou un rseau de donne (connu et accessible du PLMN d'origine) ;
- le profil de qualit de service qu'il demande pour ce contexte.
Le mobile peut aussi prciser un certain nombre d'options qui seront transmises
de faon transparente au 3G-GGSN par le 3G-SGSN. Elles permettent au 3G-GGSN
de jouer le rle d'un terminal vis--vis du monde extrieur pour des protocoles
indpendants de l'UMTS. Ainsi, des informations d'authentification pourront tre
transmises depuis le terminal vers le serveur d'authentification du rseau externe.
Le 3G-SGSN dispose dj des informations d'abonnement du mobile en

question puisqu'il les a demandes au HLR lors de la procdure d'attachement au
domaine paquet. II vrifie donc que le mobile est autoris utiliser le contexte PDP
demand et que la qualit de service demande est infrieure ou gale la qualit
inscrite dans les informations d'abonnement ; si ce n'est pas le cas, il rduit la
qualit demande avant de la transmettre au 3G-GGSN. En fait, les vrifications
effectues par le 3G-SGSN sont plus complexes puisque le mobile peut laisser tout
ou partie des champs vides. Dans ce cas, le 3G-SGSN tente de trouver un contexte
PDP dans le profil d'abonnement qui soit compatible avec les champs renseigns.
S'il ne le trouve pas, il envoie un message d'chec au mobile. S'il trouve un tel
contexte PDP, il ajoute les informations suivantes la demande d'activation avant
de la transmettre au 3G-GGSN :
- le type de taxation ;
- les informations pour la gestion des services CAMEL ;
- les informations pour la gestion des traces.
Ces informations sont contenues dans le profil d'abonnement. Le 3G-SGSN

prcise aussi si l'APN a t valid par les informations d'abonnement (explicitement
contenu dans un des contextes PDP du profil d'abonnement) ou s'il s'agit d'un
choix explicite du mobile ou du 3G-SGSN. En effet, comme d'autres paramtres,
l'APN n'est pas obligatoire dans la demande d'activation de contexte, mais le
3G-SGSN est oblig d'en dterminer un pour tre capable de faire suivre la
demande d'activation de contexte vers un 3G-GGSN. Le 3G-GGSN utilise ensuite
cette information pour accepter ou refuser la demande d'activation en fonction de sa
configuration.
Lorsque le 3G-GGSN reoit la demande d'activation de contexte, il dtermine

une adresse PDP si aucune adresse n'est contenue dans la demande (par exemple si
le type d'adresse est dynamique). Il cre dans ses tables une correspondance entre
l'adresse PDP et le tunnel GTP-U. 11 rpond ensuite la demande d'activation de
contexte en indiquant l'adresse PDP choisie (la procdure de choix utilise les mmes
outils que dans le cas du GSM-GPRS).
Pour les services IPv4 et IPv6, un cas particulier se produit lorsque l'APN est
configur pour utiliser une adresse dynamique attribue par le rseau externe (PDN),
c'est--dire dans l'hypothse d'un service non transparent. Dans ce cas, le

3G-GGSN rpond favorablement la demande d'activation de contexte et laisse le
mobile effectuer la ngociation avec le PDN. Il surveille cette ngociation et
utilisera une procdure de modification du contexte initie par le 3G-GGSN pour
modifier l'adresse PDP dans le contexte PDP enregistr par le 3G-SGSN et par le
mobile. La procdure est, dans ce cas, dpendante des protocoles utiliss par le
mobile et le rseau externe pour ngocier l'adresse IP utilis. Il faut que le GGSN
soit capable de comprendre les messages changs pour intercepter l'adresse IP
qui sera attribue au mobile. Le paragraphe 7.5.3 et la figure 7.32 prsentent un
fonctionnement similaire pour le cas d'un service Mobile IPv4.
Ds lors qu'il reoit la rponse la demande d'activation de contexte, le

3G-SGSN demande l'UTRAN l'tablissement d'un RAB sur la base du profil de
QoS ngoci renvoy par le 3G-GGSN (voir chapitre 6). Si l'UTRAN revoit la
baisse les prtentions du 3G-SGSN, ce dernier informe le 3G-GGSN de la
modification du contexte PDP. Enfin, le 3G-SGSN envoie au mobile une rponse
favorable la demande d'activation de contexte. Cette rponse contient les
diffrents identifiants ncessaires au mobile pour transmettre des donnes dans le
cadre de ce contexte, le profil de QoS finalement accept par le PLMN, ainsi que
son adresse PDP le cas chant.
A partir de ce moment-l, le mobile est capable d'envoyer des donnes. Le

3G-SGSN est capable de les faire suivre au 3G-GGSN et de collecter les
informations de taxation. Enfin le 3G-GGSN est capable de transmettre des donnes
en provenance et destination du mobile tout en collectant lui aussi les informations
ncessaires la taxation.
7.4.5.3. Traitement d'un paquet IP sortant
Une fois un contexte PDP actif, le mobile peut mettre des paquets IP vers le
PDN (figure7.21). Il dispose pour cela du NSAPI qui permet de multiplexer des
donnes correspondant plusieurs contextes PDP sur la mme liaison PDCP. Le
paquet transite dans l'UTRAN sur un RAB dtermin au moment de l'activation du
contexte. Ce RAB est lui-mme compos de deux parties : une partie radio et une
partie IP (GTP-U).
Lorsque le paquet arrive au niveau du SGSN, celui-ci fait le lien avec un

contexte PDP actif, ce qui lui permet de dterminer l'adresse IP du GGSN et
l'identifiant de tunnel qu'il doit utiliser. Le paquet est encapsul dans un tunnel
GTP-U en utilisant des paquets UDP au-dessus d'IP dans le cur de rseau de
l'oprateur.
c'est--dire dans l'hypothse d'un service non transparent. Dans ce cas, le

3G-GGSN rpond favorablement la demande d'activation de contexte et laisse le
mobile effectuer la ngociation avec le PDN. Il surveille cette ngociation et
utilisera une procdure de modification du contexte initie par le 3G-GGSN pour
modifier l'adresse PDP dans le contexte PDP enregistr par le 3G-SGSN et par le
mobile. La procdure est, dans ce cas, dpendante des protocoles utiliss par le
mobile et le rseau externe pour ngocier l'adresse IP utilis. Il faut que le GGSN
soit capable de comprendre les messages changs pour intercepter l'adresse IP
qui sera attribue au mobile. Le paragraphe 7.5.3 et la figure 7.32 prsentent un
fonctionnement similaire pour le cas d'un service Mobile IPv4.
Ds lors qu'il reoit la rponse la demande d'activation de contexte, le

3G-SGSN demande l'UTRAN l'tablissement d'un RAB sur la base du profil de
QoS ngoci renvoy par le 3G-GGSN (voir chapitre 6). Si l'UTRAN revoit la
baisse les prtentions du 3G-SGSN, ce dernier informe le 3G-GGSN de la
modification du contexte PDP. Enfin, le 3G-SGSN envoie au mobile une rponse
favorable la demande d'activation de contexte. Cette rponse contient les
diffrents identifiants ncessaires au mobile pour transmettre des donnes dans le
cadre de ce contexte, le profil de QoS finalement accept par le PLMN, ainsi que
son adresse PDP le cas chant.
A partir de ce moment-l, le mobile est capable d'envoyer des donnes. Le

3G-SGSN est capable de les faire suivre au 3G-GGSN et de collecter les
informations de taxation. Enfin le 3G-GGSN est capable de transmettre des donnes
en provenance et destination du mobile tout en collectant lui aussi les informations
ncessaires la taxation.
7.4.5.3. Traitement d'un paquet IP sortant

Une fois un contexte PDP actif, le mobile peut mettre des paquets IP vers le
PDN (figure7.21). Il dispose pour cela du NSAPI qui permet de multiplexer des
donnes correspondant plusieurs contextes PDP sur la mme liaison PDCP. Le
paquet transite dans l'UTRAN sur un RAB dtermin au moment de l'activation du
contexte. Ce RAB est lui-mme compos de deux parties : une partie radio et une
partie IP (GTP-U).
Lorsque le paquet arrive au niveau du SGSN, celui-ci fait le lien avec un

contexte PDP actif, ce qui lui permet de dterminer l'adresse IP du GGSN et
l'identifiant de tunnel qu'il doit utiliser. Le paquet est encapsul dans un tunnel
GTP-U en utilisant des paquets UDP au-dessus d'IP dans le cur de rseau de
l'oprateur.
Le GGSN met en relation l'identifiant du tunnel (TEID) avec un contexte PDP et

un numro de service (NSAPI), ce qui est important pour mettre jour les
compteurs de trafic. Il fait ensuite suivre le paquet inchang sur le rseau externe de
donnes. Pour dcouvrir vers quel prochain routeur le paquet doit tre envoy le
GGSN utilise les mcanismes standard d'IP : configuration d'une route par dfaut
statique ou participation aux protocoles de routage.
A aucun moment du transit, les lments du rseau GPRS ne regardent le

contenu du paquet IP pour dcider du chemin que doit emprunter ce dernier. Cela
rend le fonctionnement du service GPRS relativement indpendant du type de
donnes transportes.
Figure 7.21. Traitement d'un paquet sortant dans le cas d'un contexte IPv4 actif
Dans sscet exemple, nous n'avons pas introduit le mcanisme de traduction

d'adresse qui prend place aprs le GGSN. Cela permet de garder l'exemple
relativement simple.
7.4.5.4. Traitement d'un paquet IP entrant

Le cas d'un paquet entrant est similaire au prcdent. Le GGSN reoit un paquet
correspondant une plage d'adresse qu'il annonce en tant que routeur (s'il participe
aux protocoles de routage). Grce l'adresse IP contenue dans le champ adresse
destination du paquet IP, il dtermine le contexte PDP correspondant au mobile.
Ce fonctionnement suppose qu'il existe un contexte PDP actif ayant cette

adresse IP. Cela entrane une autre contrainte : il est ncessaire qu'une adresse IP
identifie de manire univoque un mobile et donc que l'oprateur dispose d'autant
d'adresses qu'il peut y avoir de mobiles ayant un contexte actif simultanment.
Puisque IPv6 n'est pas encore dploy, il est toutefois possible, souvent
indispensable, d'utiliser un adressage priv. Une autre solution consiste utiliser un
service de type Mobile IPv4 (voir paragraphe 7.5.3).
Lorsque le GGSN a identifi le contexte PDP correspondant au mobile, il fait

suivre le paquet dans un tunnel GTP-U vers le 3G-SGSN. Ce dernier dtermine le
RAB et le numro de service (NSAPI) et transmet le paquet au mobile. Au niveau
du mobile, le NSAPI permet de dterminer l'entit protocolaire destinatrice du
message.
Figure 7.22. Traitement d'un paquet IP entrant dans le cas d'un contexte IPv4 actif
7.4.5.5. Activation d'un second contexte PDP sur la mme adresse PDP
Nous venons de voir que l'UMTS intgre les procdures de modifications qui
peuvent tre utilises soit par le mobile, soit par le rseau pour modifier un contexte
PDP alors que celui-ci est actif. Mais l'UMTS permet plus gnralement d'associer
plusieurs contextes PDP actifs, chacun disposant de son propre profil de qualit de
service, une mme adresse IPv4 ou IPv6 d'un mme PDN. L'intrt est de pouvoir
diffrencier les trafics qui doivent bnficier de telle ou telle qualit de service.
Figure 7.23. Activt ion d'un contexte PDP secondaire
Si la procdure d'activation de contexte secondaire ressemble trs fortement la

procdure d'activation de contexte, il y a toutefois une contrainte supplmentaire. Le
mobile qui fait la demande des diffrents contextes PDP sait a priori choisir le
NSAPI correspondant la qualit de service dsire ; si cela pose un problme
d'implmentation au niveau du mobile pour les couches applicatives, c'est l'API
(Application Programming Interface) au niveau du mobile d'offrir les outils
ncessaires. Par contre le 3G-GGSN manque d'un moyen pour orienter le trafic
destination du mobile dans le tunnel GTP-U qui correspond la qualit de service
dsire. Le mobile, qui est le seul pourvoir dterminer quelle qualit de service
doit tre applique un paquet de donnes, doit donner au GGSN un moyen de
diffrencier les paquets. Il dispose pour cela des filtres TFT ( T r a f f i c Flow Template)
[23.060] qui permettent de dcrire des lments de l'en-tte IPv4 ou IPv6 commun
aux paquets devant utiliser ce contexte. Le mobile peut ainsi spcifier huit filtres
(avec un ordre de parcours) qu'il associe des contextes PDP. Il ne peut n'y avoir
qu'un seul contexte PDP sans filtre pour une adresse PDP donne ; ce contexte est
alors considr comme le contexte par dfaut dit contexte primaire. Les filtres tant
parcourus dans l'ordre de prcdence, le premier qui correspond au paquet de
donnes valu dtermine le contexte PDP qui sera utilis pour transmettre le paquet
IP au mobile.
7.4.5.6. Traitement d'un paquet IP entrant lorsqu'il y a plusieurs contextes PDP

pour la mme adresse
Dans l'exemple suivant, le filtre utilis se base sur le numro de port UDP
source du paquet pour dterminer le contexte PDP qui sera utilis pour atteindre le
mobile. Ce numro de port peut par exemple tre utilis par un serveur de flux
vido. Le mobile a donc tabli un contexte PDP spcifique pour recevoir la vido
dans de bonnes conditions.
Lorsqu'un paquet arrive au niveau du GGSN, celui-ci commence par dterminer

tous les contextes PDP qui utilisent la mme adresse IP. S'il en dcouvre plusieurs,
il applique, dans un ordre prdtermin par le mobile, les diffrents filtres jusqu'
trouver un contexte PDP qui corresponde. Si aucun filtre ne correspond, le paquet
utilise le contexte principal, comme prcdemment.
Au niveau du 3G-SGSN, le paquet est dirig vers un RAB correspondant ce

contexte spcifique. Ce RAB dispose sans doute de paramtres de qualit de service
spcifiques qui ont justifi l'tablissement d'un nouveau contexte. Au niveau du
mobile le numro NSAPI permet de diffrencier les diffrents contextes.
Figure 7.24. Traitement d'un paquet IP entrant lorsque plusieurs contexte PDP sont actifs
7.4.5.7. Activation d'un contexte PDP initi par le rseau

Lorsque le GGSN reoit un paquet IP pour une adresse IP qui ne correspond
aucun contexte PDP actif, il peut soit dtruire le paquet, soit essayer de provoquer
l'tablissement d'un contexte si l'oprateur met en uvre ce service.
Dans ce cas, il doit commencer par dterminer quel est le mobile qui correspond
cette adresse IP. Cela suppose, bien entendu, que l'adressage soit statique et que
l'adresse IP soit inscrite dans un contexte PDP contenu dans les donnes
d'abonnement au niveau du HLR. Pour interroger le HLR, le GGSN doit disposer du
numro de tlphone du mobile ou de son identifiant (IMSI). Il peut utiliser
n'importe quel service de nommage pour faire la correspondance entre l'adresse IP
et le numro de tlphone (le DNS par exemple).
Une fois qu'il dispose de cette information, il demande au HLR l'adresse du

3G-SGSN auquel le mobile est attach. Si le mobile n'est pas attach au rseau
GPRS, le paquet est dtruit. Sinon, le GGSN demande au 3G-SGSN de trouver le
mobile (paging non reprsent si ncessaire) et de lui transmettre la demande
d'activation de contexte. La procdure est ensuite similaire la procdure
d'activation de contexte initie par le mobile (figure 7.20).
Figure 7.25. Activation d'un contexte PDP initie par le rseau
7.5. Gestion de l'itinrance
La gestion de la mobilit est diffrente suivant que le terminal a un circuit tabli

ou non. En effet, dans le premier cas, les contraintes temporelles sont fortes et ne
permettent pas de changer de 3G-MSC, tandis que dans le second cas, il est possible
de changer de 3G-MSC et de 3G-SGSN. En fait, il est tout fait probable que la
dcision de changer de 3G-SGSN dpende des contextes PDP actifs et de leurs
attributs de qualit de service.
7.5.1. Gestion de la mobilit
Du point de vue du cur de rseau, il existe trois grands types de mobilit. Une
premire forme de mobilit est de grer les terminaux en mode IDLE et elle se traduit
par l'excution des procdures de mise jour de zone de localisation (domaine CS) ou
de zone de routage (domaine PS). Les deux autres formes de mobilit grent les
mobiles en mode CONNECTED. En fait l'UMTS permet de masquer la plupart des
mouvements d'un terminal au cur de rseau. Le rseau d'accs se charge de les grer
et le mme RNC, appel RNC serveur (SRNC), est le point d'ancrage de la
communication dans l'UTRAN. Toutefois, pour optimiser ses ressources, le rseau
d'accs peut dcider d'une relocalisation qui correspond au fait de changer de
RNC serveur, procdure qui n'est pas transparente au cur de rseau (voir chapitre 6).
D'autre part, dans certaines configurations du rseau d'accs, absence de l'interface
Iur, ou en cas de changement de technologie radio, passage du GSM l'UMTS ou du
mode FDD au mode TDD, ou encore de changement de frquence, le rseau d'accs
est amen dclencher un hard handover qui se rapproche du handover du GSM.
Dans ces deux derniers cas, les entits du cur de rseau et le mobile sont impliqus
dans une mobilit qui peut tre inter ou intra 3G-MSC ou inter et intra 3G-SGSN.
Figure 7.26. Deux types de mobilit pour le rseau cur

7.5.1.1. Mobilit dans le domaine circuit en mode IDLE

La procdure de mise jour de zone de localisation pour le domaine circuit de
l'UMTS est la mme qu'en GSM. Le protocole MM (Mobility Management) est
utilis entre le terminal et le rseau cur tandis que MAP (Mobile Application Part)
est utilis entre les entits du cur de rseau.
7.5.1.2. Mobilit dans le domaine circuit en mode CONNECTED

Dans le cas d'une mobilit intra 3G-MSC, ce dernier n'est impliqu que dans la
mesure o il doit recrer les connexions avec le nouveau RNC (voir chapitre 6).
Dans le cas de la mobilit inter 3G-MSC, la situation est un peu diffrente du fait
que l'ancien 3G-MSC reste le point d'ancrage de la communication pour des
questions de facturation et de contraintes temporelles. Le circuit est donc prolong
dans le cur de rseau entre l'ancien et le nouveau 3G-MSC. Le mcanisme est
semblable celui du GSM (voir [LAG 00]).
Figure 7.27. Mobilit inter 3G-MSC en mode connect
7.5.1.3. Mobilit dans le domaine paquet en mode IDLE

La mise jour de zone de routage est utilise la fois pour le domaine paquet
lorsque le terminal est attach au domaine paquet et pour la procdure combine
lorsque l'interface Gs est prsente entre le 3G-MSC et le 3G-SGSN.
Figure 7.28. Mise jour de zone de routage inter SGSN

lorsque le mobile est en mode PMM-IDLE (voir 23.060)
Elle est dclenche l'initiative du terminal mobile lorsqu'il dtecte un

changement de zone de routage ou intervalle rgulier fix par le rseau. Elle est
identique la procdure employe dans le mode CS, si ce n'est qu'elle peut
impliquer le 3G-GGSN si des contextes PDP sont actifs. Les protocoles utiliss sont
GMM entre le mobile et le 3G-SGSN et GTP entre les GSN-3G. Le protocole MAP
est, quant lui, toujours utilis entre les 3G-SGSN et le HLR.
7.5.1.4 Mobilit dans le domaine paquet en mode PMM-CONNECTED

Comme pour le domaine CS, le 3G-SGSN est peu impliqu dans la mobilit intra
3G-SGSN. Dans le cas o le dplacement du mobile le conduit dans une zone de
routage gre par un autre 3G-SGSN, les actions entreprises impliquent davantage le
cur de rseau puisqu'il faut, outre les deux 3G-SGSN et le HLR, impliquer aussi le
GGSN.
Figure 7.29. mise jour de zone de routage inter SGSN lorsque le mobile est en mode PMM-
CONNECTED
Figure 7.30. Mobilit inter SGSN en mode connect

Lorsqu'il reoit une demande de relocalisation en provenance du rseau

d'accs, le 3G-SGSN cible demande l'ancien 3G-SGSN les informations
concernant le mobile. Celles-ci comprennent la fois des informations sur l'identit
du terminal, l'abonnement et les contextes PDP actifs. Une redirection temporaire
(tunnel GTP) est ensuite effectue entre les deux 3G-SGSN pour ne pas perdre les
donnes qui seraient en transit. Enfin, les extrmits des tunnels GTP correspondant
aux profils actifs sont dplaces de l'ancien 3G-SGSN vers le 3G-SGSN cible grce
la procdure de mise jour de contexte PDP : celle-ci informe du changement les
GGSN possdant des contextes PDP associs au mobile (voir figure 7.29 pour le cas
d'un seul tunnel GTP).
Le mode de gestion de la mobilit impliquant le coeur de rseau (hard handover

et relocalisation) est moins performant que si la gestion se fait entirement au niveau
de l'UTRAN (chapitre 6). Il sera donc vit chaque fois que c'est possible lorsque
les trafics en cours ont des exigences de qualit de service fortes. Toutefois il peut
tre indispensable d'y avoir recours lorsque les deux rseaux d'accs ne sont pas du
mme type.
7.5.2. Gestion de la mobilit inter rseau
Figure 7.31. Mobilit inter PLMN

Le mcanisme de tunnel utilis est pnalisant en termes de charge cause de

l'accumulation d'en-ttes. Mais il permet une gestion de la mobilit trs simplifie.
11 ressemble en cela certains modes de fonctionnement de mobile IP. De plus, il
permet de rester indpendant du protocole transport. Ses avantages apparaissent
clairement dans le cas de l'itinrance inter PLMN. Dans ce cas, et pour peu que les
plans d'adressage des PLMN des deux oprateurs soient compatibles, le tunnel est
simplement ralis entre le SGSN du rseau visit et le GGSN du rseau d'origine
du mobile. Seule la traverse des passerelles (BG) entre les PLMN et le rseau
d'interconnexion des curs de rseau GPRS ncessite une configuration (voir
figure 7.31). Ce mode de fonctionnement ouvre la voie la gestion des changements
de rseau sans rupture de service.
7.5.3. Interaction avec MobileIPv4
Lorsque les premiers terminaux informatiques rellement portables sont apparus

la fin des annes 90, la communaut IP a commenc travailler sur un protocole
permettant de rendre les dplacements des terminaux IP dans la topologie de
l'Internet transparents aux applications. Ce protocole est un mcanisme additionnel
dans le cas d'IPv4 alors qu'il est intgr IPv6. Le cas de la mobilit avec IPv6 ne
sera pas trait ici, dans la mesure o peu de traitements spcifiques sont ncessaires
au sein du rseau UMTS (voir [CIS 02]).
7.5.3.1. Mobile IPv4
Dans le monde IP, l'adresse IP permet de localiser un terminal qui la possde

dans la topologie de l'Internet, elle est donc unique dans l'Internet. Le problme
vient de ce que l'adresse IP sert la fois identifier le terminal et identifier les
connexions de niveau transport (connexion TCP). Chaque changement de
localisation entrane par consquent un changement d'adresse, ce qui a pour effet de
rompre les connexions tablies. Le principe de fonctionnement de Mobile IPv4
[RFC 3344] est de conserver une identit invariable, il s'agit de l'adresse dans le
rseau d'origine appele adresse mre (Home Address).
Un lment particulier dans le rseau d'origine, l'agent mre (Home Agent),

se charge de rediriger les demandes d'ouverture de connexion et les paquets IP
destination du terminal, c'est--dire destination de l'adresse IP correspondant
la position du mobile dans l'Internet. Cette adresse est appele adresse
temporaire (Care Of Address) et n'est attribue au mobile que durant la priode
o celui-ci est prsent dans le sous-rseau IP dont elle dpend. Elle n'est jamais
connue des correspondants du terminal mobile qui utilisent toujours l'adresse
mre. L'agent mre encapsule les paquets IP en provenance des correspondants et

destination du mobile dans un paquet destination de l'adresse temporaire du
terminal.
S:127.103.9.105
D : 100.10.1.30
DATA a
S:100.10.1.1
D: 1 5 0 . 2 5 . 8 9 . 7
S: 1 2 7 . 1 0 3 . 9 . 1 0 5
D: 1 0 0 . 1 0 . 1 . 3 0
DATA |
S:127.103.9.105
D:100.10.1.30 150.25.89/24
DATA
BHjH^HHI
Figure 7.32. Fonctionnement de Mobile IPv4
Le mobile enregistre sa nouvelle localisation auprs de son agent mre chaque

fois qu'il change de sous-rseau IP et donc d'adresse temporaire. Le terminal mobile
peut acqurir cette adresse temporaire en utilisant les mcanismes standards d'IP,
mais il peut aussi utiliser l'adresse fournie par un quipement spcialis du sous-
rseau : l'agent tranger (.Foreign Agent). Cet quipement est souvent le routeur
d'accs ; il gre l'enregistrement des terminaux mobiles, leur attribue une adresse IP
temporaire et dcapsule les paquets en provenance de l'agent mre. L'utilisation de
l'agent tranger est facultative dans Mobile IPv4, mais elle a t retenue pour la
mise en uvre du service Mobile IPv4 dans le cadre de l'UMTS. L'intrt de cette
solution est double :
- d'une part, cette solution permet de limiter la charge de traitement au niveau
des mobiles. En effet, l'encapsulation entre l'agent mre et le mobile est scurise
par IPsec ([RFC 2401]), ce qui induit une charge de calcul importante pour un
terminal mobile ;
- d'autre part dans le cas o le mobile acquiert une adresse IPv4 par ses propres
moyens, celle-ci doit tre publique et il en faut donc une pour chaque terminal
mobile. Dans un contexte de pnurie, le fait de pouvoir utiliser une ou plusieurs

adresses de l'agent tranger pour tous les mobiles est trs intressant.
Figure 7.33. Interaction avec mobile IPv4
7.5.3.2. Le service Mobile IPv4 dans l'UMTS

Lorsque le service Mobile IPv4 est offert un terminal mobile (TE + MT)
[23.121], le rseau UMTS dans son ensemble est considr comme un rseau
d'accs dont le GGSN est le routeur d'accs. Il doit donc assurer les fonctions
d'agent tranger (Foreign Agent) pour le compte des mobiles qui utilisent le service
de mobilit IPv4.
Le service de mobilit IPv4 est alors associ un nouvel APN pour lequel le
terminal mobile demande l'activation d'un contexte PDP. Il n'indique pas d'adresse
IP dans la demande et le GGSN ne lui en fournit pas non plus. L'adresse sera
attribue au mobile par l'intermdiaire des procdures Mobile IPv4. Ainsi le GGSN,
sitt le contexte PDP tabli et la confirmation de l'tablissement du contexte
(Context Response) mise, met dans le plan usager un message IP/ICMP qui
informe le terminal mobile de la prsence d'un agent tranger. Ce message est bien
sr mis en diffusion puisque le terminal ne possde pas encore d'adresse IP. Ce
dernier agit ensuite comme un terminal mobile IPv4 normal et transmet une
demande d'enregistrement qui sera relaye par le GGSN vers l'agent mre du
mobile. Il indique dans la demande d'enregistrement l'adresse de l'agent mre et sa
propre adresse mre (qui est permanente) 6 .
Figure 7.34. Etablissement d'un contexte Mobile IPv4 (voir 23.121)
L'offre d'un service de mobilit IPv4 est ralisable moindres frais par
l'oprateur, elle ne suppose que quelques modification au sein du GGSN et du
terminal informatique utilisant le rseau GPRS. Par contre, elle permet de passer
outre la pnurie d'adresse en laissant le soin d'attribuer une adresse IP permanente
6. Le terminal peut aussi indiquer qu'il ne connat pas l'adresse mre et demander par l-
mme que son agent mre lui en attribue une. Il utilise pour ce faire un identifiant unique qui
lui a t attribu dans le rseau mre (Network Access Identifier) et une extension particulire
de MobilieIPv4 (Mobile Node NA1 extension [RFC 2794]). L'agent mre lui attribue une
adresse et la lui transmet dans la rponse qu'il lui fait. L'agent tranger stocke cette
information avant de transmettre la rponse au terminal. Le GGSN effectue aussi une
modification de contexte PDP initie par le rseau pour modifier l'adresse IP associe au
contexte au niveau du mobile et du SGSN.
au rseau IP d'origine du terminal. Par ce mcanisme, l'oprateur mobile propose

ses clients une relle connectivit IP qui n'entrane pas les problmes associs
la mise en uvre d'un NAT (Network Address Translator). D'autres part, le
service de mobilit IPv4 permet d'assurer une itinrance transparente pour le
mode paquet, mme lorsqu'il n'y a pas d'accord entre deux oprateurs. Lorsqu'il y
a accord, l'itinrance GPRS se fait et cela reste transparent au terminal et son
agent mre ; dans le cas contraire, la mobilit IPv4 est mise en uvre. Ce dernier
mcanisme peut, de la mme manire, tre utilis pour se dplacer sur les autres
rseaux de donnes des oprateurs, par exemple les rseaux sans fil 802.11
(Hotspot).
7.6. Gestion de la qualit de service
La gestion de la qualit de service est compltement diffrente dans les deux

curs de rseaux paquet et circuit. Elle a volu trs fortement dans le rseau
d'accs radio (UTRAN) pour pouvoir accepter plusieurs niveaux de qualit de
service et cette volution s'est rpercute dans le cur de rseau paquet.
Peu de choses ont volu dans le domaine circuit. Il existe toujours les trois
types de services : le service voix, le service donnes transparent et le service
donnes non transparent. Le cur de rseau circuit, quant lui, tablit les circuits
correspondant aux attributs demands par le terminal mobile. Les ressources
occupes par un circuit sont monopolises tout le temps que dure la communication
et sont libres lorsque celle-ci se termine.
Dans le domaine paquet, la situation est diffrente. Les possibilits de dcrire

une qualit de service demande et d'tablir un support de communication
permettant de l'assurer dans l'UTRAN sont bien plus volues et c'est toute une
architecture de gestion de la qualit de service qui a t dfinie. La mise en uvre
des diffrentes qualits de service dans les quipements du rseau cur paquet est
laisse la charge des constructeurs. Ceux-ci sont libres de choisir des solutions
standardises par ailleurs, l'IETF par exemple. Ainsi, certains constructeurs
choisiront de l'implmenter au-dessus d'un transport ATM tandis que d'autres iront
vers un transport MPLS et une architecture DiffServ. Nous dcrirons rapidement
cette solution puisqu'elle est dj propose par plusieurs constructeurs.
7.6.1. Les classes de services dfinies
Les classes de services dfinies pour le GPRS 2G taient trop complexes

utiliser et comprendre pour les utilisateurs. Le parti a donc t pris de
simplifier les classes de service dans l'UMTS. Ainsi, quatre classes ont t
dfinies et classes en fonction de leur sensibilit au dlai et aux pertes.
Chacune de ces classes est principalement ddie un type d'application. Ainsi
les deux premires classes se destinent aux trafics ayant des contraintes de
dlais fortes (pseudo temps rel), comme par exemple les applications
multimdias, tandis que les deux suivantes serviront aux applications standards
(navigateur, courrier lectronique,...) ayant ou non des interactions avec
l'utilisateur.
Classe de trafic Principales caractristiques Exemple

d'application
Conversationnel Prservation de la relation temporelle entre les Voix, VoIP,
paquets vido
Dlais faibles et constants confrences
Streaming Prservation de la relation temporelle entre les Diffusion de
paquets contenu
multimdia
Interactive Prservation du contenu (peu d'erreurs) Navigation
Mode de fonctionnement requte - rponse Internet
Arrire-plan Prservation du contenu (peu d'erreurs) Tlchargement

(Background) Pas de contraintes temporelles (courrier
lectronique)
Tableau 7.1. Les classes de service du domaine paquet de l'UMTS (Release 99)
En plus de la notion de classe de service, l'UMTS dfinit de manire trs prcise

le comportement associ chaque support de communication (bearer) par un jeu
d'attributs. Tous ces attributs sont ngociables au moment de la cration d'un
contexte PDP mais les valeurs maximales sont mentionnes dans les donnes
d'abonnement stockes par le HLR.
De plus, pour chaque type de service support et pour chaque classe de service, un
ensemble d'intervalles dans lesquels les valeurs des attributs doivent tre comprises
est spcifi. Dans le tableau 7.2, on donne les intervalles pour le service support
UMTS qui va du terminal au GGSN sachant que les valeurs des autres supports
seront diffrentes. En effet, le dlai sur le support UMTS (bearer UMTS) se
dcompose en deux parties : le dlai sur le support radio et le dlai sur le support
cur de rseau.
Attributs Conversational Streaming Interactive Background

Dbit maximal < 2 Mbit/s < 2 Mbit/s < 2 Mbit/s < 2 Mbit/s
(- les en-ttes) (- les en-ttes)
Squencement Oui ou non Oui ou non Oui ou non Oui ou non
Taille des SDU < 1 500 < 1 500 < 1 500 < 1 500
Livraison des SDU Oui/Non1- Oui/Non/- Oui/Non/- Oui/Non1-
errones
Taux d'erreur bit rsiduel 5.10 2 10"6 5.10"2 10"6 4.10"3 6.10"8 4.10"3 6.10"8
Taux de SDU errones 2
1 0 10" 5 2
10" 10" 5 3
10" 10" 6
10"3 10"6
Dlai de transfert A partir de A partir de - -
100 ms 250 ms
Dbit garanti < 2 Mbit/s < 2 Mbit/s - -
Priorit de traffic 1,2 et 3

Priorit 1,2 et 3 1,2 et 3 1,2 et 3 1,2 et 3
l'allocation/maintien
Tableau 7.2. Attributs associs aux classes de service

pour le support de communication UMTS
7.6.2. Une architecture complte
Une architecture complte de gestion de la qualit de service a t dfinie pour la

Release 99 de l'UMTS. Cette architecture dfinit les relations entre les diffrents
supports de communication avec la volont de prserver des interfaces claires entre
des domaines de gestion de la qualit de service indpendants. Cela permet de
garantir une interoprabilit entre les fabricants, d'une part, et entre les rseaux,
d'autre part.
7.6.2.1. Les diffrents niveaux de gestion de la QoS

A chaque support de communication (bearer) est associ un ensemble d'attributs
dfinissant le service offert par le support, ce support utilisant lui-mme d'autres
supports de niveau infrieur pour assurer la transmission effective des donnes.
Ainsi (voir figure 7.35), pour offrir un service de bout en bout, il faut composer : un
support local entre le terminal mobile et l'ordinateur (souvent travers une
connexion PPP), un support UMTS et un support externe. Le support UMTS est lui-
mme compos d'un support radio et d'un support cur de rseau.
A ce jour, le support radio est trs bien dfini et les diffrentes fonctions
ncessaires sont compltement spcifies. Ce n'est pas le cas du support cur de
rseau, il est seulement prcis que, pour sa mise en place, les constructeurs et les
oprateurs auront choisir des solutions dfinies en dehors du cadre du 3GPP.
L'oprateur peut par exemple choisir une solution base sur des circuits virtuels
ATM ou utiliser l'architecture de gestion de la qualit de service diffrenciation de
services spcifie par l'IETF sur IP (Diffserv [RFC 2475]). De la mme manire, le
support sur l'interface lu entre le rseau d'accs radio et le rseau cur peut utiliser
une solution base sur ATM ou sur IP. Dans tous les cas, l'interaction entre une
solution base sur ATM et IP se fera en utilisant les classes de service DiffServ.
Pour ce qui est du lien avec le rseau externe, cela dpendra videmment des
possibilits que ce rseau externe offre. Aujourd'hui, seul un service IP pour le
mieux (Best Effort) est universellement disponible.
Figure 7.35. Diffrents niveaux de gestion de la QoS

(en relation avec les supports de communication)
Les attributs des services supports rseau et lu dpendent bien videmment de la

solution de gestion de qualit de service retenue par l'oprateur. De plus, celui-ci
contrle la manire dont les attributs des classes de services UMTS sont mis en
correspondance avec les attributs des services-supports, par exemple avec les
comportements (PHB) de Diffserv.
Pour mettre en uvre cette architecture, plusieurs fonctions sont ncessaires, la

fois dans le plan de contrle et dans le plan usager.
7.6.2.2. Gestion des ressources (dans le plan de contrle)

Dans le plan de contrle, on retrouve chaque niveau les fonctions permettant
d'tablir et de grer les supports de communication. Il est aussi ncessaire d'assurer
la traduction des attributs entre les niveaux et entre les solutions de gestion de la
qualit de service la jonction de deux supports de communication. Les fonctions
permettant d'assurer le contrle d'accs en termes de ressources font le lien avec les
technologies de transport sous-jacente tandis que celles grant les droits d'accs se
chargent de faire la liaison avec les donnes d'abonnement maintenues par le HLR.
Figure 7.36. Gestion de la qualit de service dans le plan de contrle
1.6.2.3. Mise en uvre de la qualit de service {dans le plan usager)

Dans le plan usager, les fonctions s'appliquent aux lments d'information
transmis. Elles permettent de mettre en correspondance un flux de donnes et le
support de communication auquel il sera associ (classification). Par exemple dans
le GGSN, c'est la fonction qui, l'aide du filtre, dtermine quel est le contexte PDP
qui doit tre utilis (voir figure 7.37 (D). Ensuite, le conditionneur de trafic ()
s'assure de la conformit des flux par rapport aux attributs du support de
communication. Ainsi, si un flux en entre est trop important, l'excdent sera dtruit
ou re-marqu avec une priorit moindre. Le marqueur (mapper (D) sert attribuer au
paquet un marquage dans un champ de l'en-tte P, ce marquage correspondant la
qualit de service requise en fonction du support dtermin par la fonction de
classification. Enfin, le gestionnaire de ressources () rpartit les ressources

disponibles entre les diffrents flux concurrents.
Figure 7.37. Gestion de la qualit de service dans le plan usager
7.6.3. Exemple de mise en uvre dans le cur de rseau paquet
Une des solutions de mise en uvre de l'architecture de l'UMTS pour le cur de

rseau est base sur un cur de rseau IP/MPLS et sur l'architecture DiffServ. Ainsi
l'oprateur s'occupe d'un dimensionnement global de son rseau pour les
diffrentes classes de service DiffServ, il n'y a pas proprement parler de
rservation flux par flux. Par contre, il peut y avoir, pour les classes de services
critiques, un contrle d'accs lors de l'tablissement du contexte PDP. Dans ce cas,
le SGSN, aprs avoir vrifi les droits de l'utilisateur, vrifie si la ressource
demande est disponible ou non. Il y a une correspondance statique entre les classes
de trafic UMTS et classes de service DiffServ (voir tableau 7.3).
Classes de trafic UMTS Comportements DiffServ

Conversationnel EF
A flux continus AF11, AF12, AF13
Interactif AF21, AF22, AF23
Arrire plan BE (pour le mieux)
Tableau 7.3. Correspondance entre les classes de service UMTS

et les comportements (PHB) DiffServ
Cette solution est trs souple pour l'oprateur, elle lui permet de choisir
n'importe quelle technologie de niveau 2 et mme de panacher diffrentes
technologies en fonction des caractristiques recherches. MPLS se charge alors de
l'interfonctionnement des diffrents niveaux de liaisons mis en uvre. De plus,
grce MPLS, l'oprateur peut grer finement le trafic dans son rseau et mme
passer une solution de rservation de ressources explicite (flux par flux) pour
certains services critiques.
La correspondance entre les classes de trafic UMTS et les classes de services

DiffServ, ainsi que la politique de marquage des paquets l'intrieur des classes de
service, n'est pas forcment la mme pour tous les services offerts par l'oprateur
(c'est--dire pour tous les APN). Ainsi, un service peut tre ddi au multimdia
(diffusion de flux Mpeg4) et se voir appliquer une politique de marquage des paquets
dpendant directement de la smantique applicative de ceux-ci. En effet, en perdant
prioritairement les trames les moins importantes d'un flux multimdia, il est possible
d'amliorer sensiblement le rendu applicatif de ces flux en cas de congestion.
Routeur frontire Diffserv. Routeur frontire Diffserv.

- traduction vers les classes UMTS - traduction vers un autre domaine IP
- classification - classification
- mise en forme et marquage - mise en forme et marquage
- files d'attente et ordonnancement - files d'attente et ordonnancement
Figure 7.38. Gestion de la qualit de service dans le cur de rseau avec IP/MPLS/DiJfserv
7.7. Evolution vers un cur de rseau tout IP
La premire version de l'UMTS conserve deux domaines bien distincts, comme

dans les rseaux GSM-GPRS. Les oprateurs ne sont pas prts prendre le risque de
dployer une architecture entirement nouvelle pour les services qui les font vivre
comme la voix et les SMS. Il est probable que ces services migreront lentement vers
l'UMTS R99, laissant aux oprateurs le temps d'exprimenter de nouveaux services
dans le domaine paquet.
L'volution de l'UMTS vers les releases 4 et 5 entrane des changements

beaucoup plus profonds. Les spcifications des diffrentes version de TUMTS ne sont
pas toutes compltement figes, et les constructeurs gardent une certaine marge de
manuvre dans le choix des solutions techniques. Ainsi, par exemple, ATM qui est
souvent prsente comme une pierre angulaire de la version 5, ne sera probablement
pas propos par tous les constructeurs puisque d'autres alternatives existent.
Cependant un mouvement de fond se dessine, qui conduit les rseaux UMTS

voluer vers des rseaux de service ouvert bass sur le protocole IPv6 (au moins
pour l'IMS) et sur les protocoles de contrle et de signalisation dfinis l'IETF
(SIP, MEGACO). Cette volution se ressent jusque dans le rseau d'accs o IP sera
utilis comme technologie de transport ; cependant, le rseau d'accs conserve ses
spcificits pour la gestion de la radio et des dplacements des mobiles.
7.7.1. Evolutions de la Release 4

La quatrime version de l'UMTS est une rvision mineure des curs de rseaux
des domaines paquet et circuit. Toutefois, la transition vers le rseau tout IP de la
version 5 passe par cette rvision qui voit la signalisation du domaine circuit passer
au-dessus d'IP.
Figure 7.39. Architecture de l'UMTS {.Release 4)

Le cur de rseau du domaine circuit abandonne partiellement le

fonctionnement en mode circuit pour implmenter une architecture de gestion des
appels compltement diffrentes. Ce rseau est tout IP aussi bien pour le transport
de la signalisation que pour le transport de la voix. Cela permet de faire des
conomies d'chelle et d'utiliser plus efficacement les ressources du rseau cur.
En effet, auparavant il fallait maintenir des circuits de 64 kbit/s dans le cur de
rseau, tandis que dans cette version de l'UMTS, seul l'quipement qui est en
relation avec un rseau de tlphonie (PSTN) aura faire la conversion vers un
circuit 64 kbit/s.
Les fonctions lies la signalisation et celles lies au transport des

communications sont associes des quipements diffrents. Ainsi les serveurs
MSC et GMSC ne s'occupent plus que de la signalisation. Ils sont en relation avec
les passerelles (MGW, Media GateWay) qui traitent les communications. Les
relations entre les deux types d'quipements font l'objet de deux nouvelles
interfaces. On peut aussi remarquer que le protocole RANAP n'est plus transport
sur l'interface Iu-CS mais sur une interface lu (RANAP) qui est ddie au contrle.
Autre point remarquable de cette version, les bases de donnes ne changent pas
ou peu et elles sont toujours accdes travers les mmes interfaces. Le rseau cur
paquet n'volue pratiquement pas, et restera en l'tat dans la version suivante.
7.7.2. Evolutions prvisibles de la Release 5
L'IMS (IP Multimedia Subsystem) est une nouveaut de la version 5 de l'UMTS.

Ce nouveau domaine bas sur les protocoles IPv6 pour le niveau rseau et SIP pour
la signalisation devrait permettre une plus grande ouverture des plates-formes de
service, rduisant ainsi les dlais et les cots associs la mise en place de
nouveaux services. Le principe de l'IMS est de mettre directement en relation les
terminaux mobiles et la plate-forme de service, ce qui explique le recours IPv6 du
fait du peu d'adresses IPv4 disponibles aujourd'hui. Le choix de cette approche
impose par contre l'utilisation de nouveaux terminaux, les nouveaux services n'tant
pas compatibles avec les anciens terminaux. Le domaine circuit sera par ailleurs
conserv un temps pour permettre aux anciens terminaux d'utiliser le rseau.
Cette plate-forme de service devrait permettre une intgration beaucoup plus

facile avec les services disponibles sur l'Internet. Certains constructeurs font dj la
dmonstration de terminaux clients supportant la fois SIP et IPv6 et permettant
d'utiliser des services innovants comme les services de prsence (Instant
Messenging) ou les rseaux coopratifs (P2P, Peer-to-Peer).
Figure 7.40. Architecture de l'UMTS (Release 5)
L'autre volution importante consiste utiliser une architecture de gestion des

appels multimdias (tlphonie dans un premier temps) dfinie l'IETF
(MEGACO). Ainsi, aprs le protocole de transport de niveau rseau, c'est la partie
contrle des appels qui converge. Cette architecture offre une solution de contrle
des appels au-dessus de l'Internet, mais n'est pas dploye aujourd'hui.
Pour la signalisation et pour les donnes, l'interconnexion entre les rseaux

d'accs et les rseaux curs passe par un rseau IP sur ATM, de mme que le
cur de rseau IP. Toutefois, les constructeurs conservent une marge de
manuvre dans le choix de la technologie de transport utilise dans ces rseaux.
La seule contrainte pour le cur de rseau IP est qu'il supporte, d'une manire ou
d'une autre, une gestion de la qualit de service de bout en bout pour le domaine
paquet.
7.8 Conclusion
La Release 9 9 de l'UMTS sera la premire version de l'UMTS dploye.

Elle l'est depuis 2002 au Japon dans une forme un peu particulire et en Europe
depuis 2004. Du point de vue du cur de rseau, elle apporte peu de changement par
rapport la Release 99 du GSM/GPRS. Toutefois, elle initie des changements
importants comme une architecture de gestion de la qualit de service complte qui

ne sera sans doute jamais utilise dans cette version mais qui permet de dployer
progressivement les rseaux curs du domaine paquet qui prendront la relve des
rseaux curs du domaine circuit pour le transport de la signalisation et des appels
voix dans les prochaines versions. Le rseau cur du domaine circuit volue peu et
il s'agit surtout d'un rseau de transition appel disparatre dans un avenir plus ou
moins proche suivant les oprateurs. En effet, les oprateurs disposant d'un rseau
cur circuit fonctionnel et du savoir-faire pour l'administrer n'ont pas de raison
imprieuse de l'abandonner immdiatement.
L'autre point important noter est l'ajout dans cette version du service IPv6,
aussi bien pour le GPRS-2G que pour le GPRS-3G. Cela ne signifie en rien que le
rseau de l'oprateur passe IPv6 tout de suite, mais il faut prparer l'arriv de
l'IMS (qui sera seulement en IPv6) dans les futures versions et pour cela commencer
dployer et exprimenter les services IPv6.
Le 3GPP a envisag une volution trs progressive des curs de rseaux vers
des solutions tout IP plus ouvertes sur les services. Cette volution a dj
commence avec le GPRS de la phase 2+ du GSM. Ce sont d'abord les nouveaux
services dont les services orients donnes qui migrent vers le cur de rseau
paquet.
Le cur de rseau du domaine circuit commence progressivement utiliser les

technologies IP avant de se confondre avec le cur de rseau du domaine paquet.
Les curs de rseau des autres domaines qui apparaissent, comme le domaine IMS,
dmarrent tout de suite en IP et mme en IPv6 pour viter une transition
supplmentaire dans quelques annes.
Les volutions futures ( partir de la version 6) des curs de rseau sont

encore peu stables en 2004 et sujettes beaucoup de dbats. Elles porteront (pour
ce qui est du cur de rseau) sur la manire de grer la mobilit qui pourrait bien
tre MobilelP et sur la possibilit de migrer une partie du rseau d'accs radio
sous IP.
Pour ce qui est de la technologie IP, le choix d'IPv semble acquis terme. Mais
tout n'est pas encore prt et le 3GPP ne peut se contenter de prendre des solutions
toutes prtes qui seraient dfinies par l'IETF. Au contraire, il faudra que les
oprateurs et les constructeurs participent l'effort de standardisation au sein de
l'IETF comme cela a dj commenc.
7.9. Bibliographie
[22.078] 3rd Gnration Partnership Project, Customised Applications for Mobile Network
Enhanced Logic (CAMEL): Service description, Stage 1, TS 22.078-390, Technical
Spcification Group Services and Systems Aspects, 2002.
[23.002] 3rd Gnration Partnership Project, Network architecture, TS 23.002-360 ,
Technical Spcification Group Services and Systems Aspects, 2002.
[23.003] 3rd Gnration Partnership Project, Numbering, addressing and identification, TS
23.003-3e0 , Technical Spcification Group Core Network, 2003.
[23.008] 3rd Gnration Partnership Project, Organization of subscriber data, TS 23.008-

380 , Technical Spcification Group Core Network, 2003.
[23.060] 3rd Gnration Partnership Project, General Packet Radio Service (GPRS): Service
description; stage 2, TS 23.060-3g0 , Technical Spcification Group Services and
Systems Aspects, 2003.
[23.078] 3rd Gnration Partnership Project, Customised Applications for Mobile Network
Enhanced Logic (CAMEL): Service phase 3, Stage 2, TS 23.078-3j0 , Technical
Spcification Group Core Network, 2004.
[23.107] 3rd Gnration Partnership Project, Quality of Service (QoS) concept and
architecture, TS 23.107-390, Technical Spcification Group Services and Systems
Aspects, 2002.
[23.121] 3rd Gnration Partnership Project, Architectural Requirements for Release 1999,
TS 23.121-360 , Technical Spcification Group Services and Systems Aspects, 2002.
[23.171] 3rd Gnration Partnership Project, Functional stage 2 description of location
services in UMTS, TS 23.171-3b0, Technical Spcification Group Services and
Systems Aspects, 2004.
[Q.1214] International Tlcommunication Union, Distributed Functional Plane for
Intelligent Network CS1, ITU-T Q.1214, ITU-T, 1994.
[RFC 1034] MOCKAPETRIS P., Domain Names: concepts and facilities, RFC 1034,
IETF, 1987.
[RFC 1035] MOCKAPETRIS P., Domain Names: Implementation and spcification, RFC 1035,
IETF, 1987.
[RFC 2401] KENT S., ATKINSON R., Security System Architecture for the Internet Protocol,
RFC 2401, IETF, 1998.
[RFC 2475] BLAKE S., BLACK D., CARLSON M., DAVIES E., WANG Z., WEISSW., An
Architecture for Differentiated Services, R F C 2475, IETF, 1998.
[RFC 2794] CALHOUNP., PERKINS C., Mobile IP Network Access Identifier Extension for
IPv4, RFC 2794, IETF, 2000.
[RFC 3344] PERKINS C., IP Mobility Support for IPv4, RFC 3344, IETF, 2002
[BAT 02] BATES R., GPRS: GeneralizedPacket Radio Service, McGraw-Hill, 2002.
[CHE 04] CHEN J.-C., ZHANG T., IP-Based Next-Generation Wireless Networks: Systems,
Architectures and Protocols, Wiley, 2004.
[FAG 02] FAGGIONN., Le GPRS : Du WAP l'UMTS, Dunod, 2002.
[CIS 02] CIZAULTG., IPV6, Thorie et pratique, O'Reilly, 2002.
[LAG 00] LAGRANGE X., GODELWSKI P., TABBANE S., Rseaux GSM, Herms, 2000.
[LES 01] LESCUYERP., UMTS : Les origines, l'architecture, la norme, Dunod, 2001.
[RUS 02] T. RUSSEL, Signaling System #7, McGraw-Hill, 4e dition, 2002.
[SER 91] SERET S., CHAILLEY P., RNIS, description technique, Dunod, 1991.
Chapitre 8
Les architectures de services de l'UMTS
8.1. Historique de l'volution des services dans les rseaux radio-mobiles
8.1.1. Des services supplmentaires CAMEL
Les premiers services mobiles mis disposition sur le rseau GSM (Global Sys-
tem for Mobile Communications) ont t dvelopps suivant la mme mthodologie que
celle mise en uvre pour le RNIS (Rseau numrique intgration-de services). Ils se
rpartissent dans une des trois familles de services suivantes (on qualifiera cette approche
declassique,demmeque les services correspondants, dans la suite de notre expos) :
- les services supports servent transporter le trafic utilisateur entre les terminaux
utiliss dans le cadre d'une communication. Le rseau n'effectue aucun traitement sur
les informations transportes autre que ceux ncessaires au transport de l'information
utilisateur (par exemple transport d'chantillons numriques vocaux sur un circuit t-
lphonique) ;
- les tlservices sont chargs d'effectuer un traitement sur des informations trans-
portes par le rseau afin de les mettre sous une forme comprhensible par l'utilisateur
final (par exemple mise en forme du signal numrique sous forme d'ondes sonores
pour le tlservice de tlphonie, production d'un document papier partir de mes-
sages numriques pour le tlservice de tlcopie...) ;
- les services supplmentaires sont ncessairement associs un tlservice. Ils
sont supposs enrichir un tlservice en apportant de nouvelles possibilits l'utilisa-
teur final (par exemple le service supplmentaire renvoi d'appel peut tre associ au
tlservice de tlphonie).
Chapitre rdig par Philippe MARTIN s.

Cette mthodologie a t reprise en UMTS (Universal Mobile Tlcommunica-

tions System) dans la recommandation 22.105. Nanmoins, les oprateurs mobiles et
les constructeurs ont opt pour d'autres approches lorsque le service mettre en place
sur le rseau devient trop complexe. L'approche classique s'appuie sur un processus de
normalisation trs strict. Elle s'est trs vite avre trop restrictive. Le dveloppement
de nouveaux services, dans un contexte de drgulation du march des tlcommu-
nications, ncessite des temps de dveloppement plus courts et une architecture logi-
cielle plus flexible. L'ajout ou la modification de services classiques exige trs souvent
une mise jour onreuse de fonctions logicielles, situes au niveau des terminaux ou
d'quipements rseaux, comme les fonctions de traitement d'appel des MSC (Mobile
services Switching Center).
Les oprateurs mobiles ont ds lors opt pour l'utilisation de la technique rseau
intelligent, dj largement utilise dans le rseau tlphonique fixe. L'adoption du
RI (Rseau intelligent) ou IN (Intelligent Network) a permis d'enrichir l'offre (comme
les offres d'abonnements par cartes prpayes). Cependant, les services rseau intelli-
gent proposs dans les rseaux mobiles restaient inaccessibles quand l'abonn tait en
itinrance. Les solutions dployes ont d tre adaptes pour fonctionner sur les MSC,
ce qui a donn naissance diverses plates-formes propritaires et donc des problmes
d'interoprabilit. C'est dans ce contexte que l'ETSI (European Tlcommunications
Standards Institute) a dcid d'introduire CAMEL (Customized Applications for Mo-
bile network Enhanced Logic). L'objectif de CAMEL est double :
- dfinir une architecture rseau rendant possible l'utilisation de services mobiles
en dehors du rseau nominal de l'abonn, tout en conservant l'environnement utilisa-
teur lors du dplacement de ce dernier ;
- dfinir des interfaces ouvertes entre les quipements du rseau, y compris lorsque
l'utilisateur est en itinrance (roaming).
CAMEL ne dfinit pas proprement parler de nouveaux services puisqu'il s'ap-

puie sur des protocoles issus du rseau intelligent et adapts pour les rseaux mobiles.
Il permet un utilisateur d'invoquer ses services depuis un rseau visit et donne les
moyens de rsoudre les problmes d'interoprabilit. Les concepts et les protocoles du
rseau intelligent1 sont en grande partie rutiliss et adapts au contexte mobile. L'ap-
port majeur de CAMEL rside dans la dfinition d'une interface de commande nor-
malise entre la plate-forme de service et le MSC. CAMEL fournit aussi les moyens
une plate-forme de service d'un oprateur de piloter distance les commutateurs
d'un autre oprateur (ce qui n'tait pas possible dans les versions rseau intelligent
provenant du rseau fixe).
1. Plus particulirement la version europenne normalise l'ETSI.

Les architectures de services de l'UMTS 341
8.1.2. Evolutions vers VHE et OSA
Le concept de VHE ( Virtual Home Environment) a t dfini pour apporter aux

utilisateurs une interface d'accs aux services souscrits indpendante du rseau. Les
utilisateurs disposent ainsi d'une interface unique pour dclencher leurs services et
pour les personnaliser. L'environnement et les prfrences associes aux services de
l'utilisateur sont conservs lors de l'itinrance.
VHE peut tre vu comme une gnralisation du service apport par CAMEL. CA-
MEL s'appuie sur les services du protocole rseau CAP {CAMEL Application Part).
VHE, au contraire, a pour vocation d'tre indpendant de la technologie rseau sous-
jacente. Il s'appuie sur plusieurs technologies mises en uvre la fois au niveau du
mobile, comme MExE (.Mobile Execution Environment) ou SAT (SIM Application
Toolkit) et au niveau du rseau comme OSA (Open Service Architecture).
La norme OSA a t introduite pour rendre possible cette indpendance au niveau

du rseau cur. OSA est un intermdiaire entre les services et les fonctionnalits r-
seau indispensables la mise en uvre du VHE. Toutes les fonctions rseaux comme
le contrle d'appel, la gestion de la localisation ou encore le contrle de ressources de
tlcommunications spcialises, deviennent accessibles depuis les applications. De
mme, OSA permet des fournisseurs de services tiers de proposer des services sur
l'infrastructure d'un oprateur mobile traditionnel.
8.1.3. Evolutions vers IP
Les versions de l'UMTS postrieures la version R99 (Releases R4, R5, R6 ...)
ont de plus en plus recours aux protocoles de la famille IP (Internet Protocol). Les
normalisateurs ont introduit depuis la release 5 un nouveau domaine du rseau appel
sous-systme IP multimdia. Cette zone est localise dans le rseau cur. Elle est joi-
gnable depuis le rseau d'accs en passant systmatiquement par le domaine paquet.
Le sous-systme IP multimdia contient un ensemble de serveurs applicatifs bass sur
la technologie SIP (Session Initiation Protocol) et destins apporter des services IP
multimdia du mme type que ceux offerts dans le domaine circuit (confrence d'ap-
pels, renvoi d'appels,...), sans toutefois se limiter ceux-ci (services de messagerie
instantane, service de prsence, consultation de botes vocales...).
8.2. Rappels sur les rseaux intelligents
8.2.1. Notion de segment d'appel
Le rseau intelligent est issu du monde de la tlphonie fixe. Il a t conu au dbut

des annes 80 pour faciliter le dveloppement de nouveaux services de tlcommuni-
cations sur une infrastructure tlphonique (numro vert, cartes prpayes...).
Le RI a pour objectif de rendre un commutateur tlphonique (ou ressource de t-

lcommunications) programmable distance dans le but de faciliter le dveloppement
de nouvelles offres de services. Historiquement, les premiers travaux ont port sur la
dfinition de services dclenchs partir d'appels tlphoniques, ou plus prcisment
partir d'un segment d'appel (voir figure 8.1 et paragraphe 8.2.4.4). Dans la suite de
l'expos, on utilise le terme anglais quivalent CS (Call Segment). Ce dernier repr-
sente un automate charg du traitement de la signalisation d'appel sur chaque interface
utilise par la communication de bout en bout. Un appel tlphonique requiert la pr-
sence de deux segments d'appel (un segment d'appel originant et un segment d'appel
terminant) par commutateur travers par le circuit de parole2. Par exemple, une com-
munication entre deux abonns A et B relis un mme commutateur fait intervenir
deux segments d'appel. Si les deux abonns sont raccords chacun un commutateur
et que les deux commutateurs sont directement relis, la communication fait intervenir
quatre segments d'appel (voir figure 8.1).
L'intrt de dcomposer les appels en segments d'appel est de pouvoir dfinir des
services soit au dpart d'un appel tlphonique, soit l'arrive. Il devient alors pos-
sible de sparer la fonction de traitement d'appel, appele CCF (Call Control Func-
tion) dans la terminologie rseau intelligent, et la logique de service appele SCF (Ser-
vice Control Function). Ce dcoupage a permis d'ajouter progressivement d'autres
types de services et d'enrichir les possibilits offertes par le rseau intelligent. Au fur
et mesure des volutions du standard, d'autres interfaces de signalisation ont t
spcifies pour permettre le dploiement de nouveaux services. Les premiers services
rseaux intelligents taient obligatoirement dclenchs depuis un segment d'appel.
Ce n'est plus ncessairement le cas aujourd'hui, notamment avec le support des inter-
actions OCCUUI (Out of Channel Call Unrelated User Interaction) depuis la phase
CS-2.
8.2.2. volution et structure des standards
Le rseau intelligent volue par phase. Chaque phase, appele ensemble de capa-
cits (CS, Capability Set), dfinit un ensemble de services cibles, susceptibles d'tre
offerts l'utilisateur final, ainsi que toutes les fonctions rseaux ncessaires leur
mise en uvre. L'ITU a dfini quatre ensembles de capacits. Le CS-1 a t la pre-
mire srie de recommandations rseau intelligent adopte par l'ITU. Elle est actuelle-
ment largement dploye dans le rseau tlphonique commut. Les services comme
le numro vert ou les cartes prpayes font partie de cette premire srie. Les services
couverts par CS-1 ne peuvent tre activs que pendant les phases non stables de l'appel
- c'est--dire avant que la demande d'appel n'ait t achemine par le commutateur
2. Choix de modlisation adopt par l'ITU (International Tlcommunications Union) et

l'ETSI.
Appel tlphonique entre deux commutateurs et segments d'appels associs
Figure 8.1. Segments d'appels et logique de service RI
appelant vers le commutateur distant. Le standard CS-2, approuv en 1997, tend le

champ d'application de CS-1 en prenant notamment en compte les appels multipar-
tites, les interactions directes entre les utilisateurs et les plates-formes de services en
dehors d'un segment appel existant. Le dclenchement d'un service depuis les phases
stables de l'appel est galement possible comme dans le cas du passage d'un appel
une confrence d'appel via une squence utilisateur DTMF (Dual Tone Multiple
Frequency) ou via l'envoi de messages de signalisation RNIS en provenance du ter-
minal et destination de la plate-forme de service : on parle alors de OCCRUI (Out of
Channel Call Related User Interaction). Le standard CS-3 a t dfini en 1999 pour
introduire les services rseau intelligent dans un environnement ATM (Asynchronous
Transfer Mode). Le standard CS-4 aborde l'utilisation de la technique rseau intelli-
gent dans le cas de services mettant en uvre le rseau tlphonique et l'Internet. Les
ensembles de capacits sont dcrits dans les sries de recommandations Q12nx, o n
identifie le numro d'ensemble de capacit considr et o x correspond un numro
de recommandation (voir tableau 8.2).
Phase Principales caractristiques

CS-1 Dclenchement du service depuis les phases non stables de l'appel.
Utilise uniquement le BCSM (Basic Call State Model).
CS-2 Dclenchement du service possible depuis les phases stables de l'appel.
Support des appels multipartite CPH (Call Party Handling).
Dclenchement de services non lis des appels.
Utilisation du CSCV (Call Segment Connection View) pour la modlisa-
tion d'appels multipartite.
Support des interactions OCCUUI et OCCRUI
CS-3 Support de services rseau intelligent dans un rseau ATM.
Nouveau modle d'appel prenant en compte l'tablissement de
connexions sur un rseau ATM
CS-4 Services rseau intelligent s'appuyant la fois sur le rseau tlphonique
et l'Internet.
Tableau 8.1. Classification des ensembles de capacits du rseau intelligent
Srie de recommandations Q12nx

Suffixe x Description du contenu
0 Structure des recommandations pour le jeu de capacit n
1 Rsume les principales caractristiques du jeu de capacit n
2 Description du plan de services
3 Description du plan fonctionnel global
4 Description du plan fonctionnel rparti
5 Description du plan physique
8 Description du protocole INAP (Intelligent Network Application Part)
9 Guide de l'utilisateur rseau intelligent
Tableau 8.2. Structure des recommandations rseau intelligent
8.2.3. Le modle conceptuel du rseau intelligent
Le rseau intelligent utilise un modle de dveloppement des services de type fonc-

tionnel descendant. Plusieurs tapes interviennent dans l'laboration d'un service. Les
tapes, appeles plans, correspondent diffrents niveaux d'abstraction associs au
processus de dveloppement. Un service rseau intelligent est systmatiquement d-
crit selon les quatre plans suivants : plan de services, plan fonctionnel global, plan
fonctionnel rparti et plan physique. Le plan de services apporte une description tex-
tuelle du comportement des diffrents services apports par un jeu de capacits. Les
normes dfinissent un ensemble de fonctions normalises, appels lments de ser-

vices, dcrivant le comportement des services tels qu'ils doivent tre vus par l'uti-
lisateur. Les lments de services peuvent tre combins pour apporter une offre de
service plus labore.
Dans le plan fonctionnel global, les services sont dcris via un modle de gnie lo-
giciel introduit par l'ITU. Ils sont reprsents par des enchanements de blocs logiciels
lmentaires normaliss appels SIB (Service Indpendant Building Block). Chaque
SIB implmente une fonction offerte par le rseau de l'oprateur et peut tre rutilise
(par exemple SIB BCP (Basic Call Process) pour la fonction de traitement d'appel,
SIB Translate pour la fonction de traduction de numro, ...). A ce niveau d'abstrac-
tion, le concepteur ne se proccupe ni des traitements ncessaires la ralisation des
diffrents SIB ni des protocoles de signalisation et des ressources indispensables la
mise en uvre du service considr. Les services et les lments de services sont d-
composs en SIB dans le plan fonctionnel global.
Le plan fonctionnel rparti dfinit un ensemble de fonctions rseaux lmentaires

utilises lors de l'excution d'un service rseau intelligent. Les fonctions rseaux l-
mentaires sont appeles des entits fonctionnelles et les instances de ces fonctions
sont dsignes par le sigle FEA (Functional Entity Action). Les FEA sont des pro-
cessus applicatifs qui s'excutent sur des quipements rseaux et qui changent des
flux d'information. Les SIB du plan fonctionnel global sont dcomposs en groupe de
FEA.
Le plan physique dcrit la correspondance entre les entits fonctionnelles du plan

fonctionnel rparti et les quipements rseaux. Il prcise galement le type d'infra-
structure qui va tre utilis pour transporter les flux d'information du plan fonctionnel
rparti. La plupart du temps ce sont les services de transport du rseau SS7 qui sont
utiliss.
Dans la suite, nous ne dcrirons que le plan fonctionnel rparti dont la terminologie
est largement reprise dans les recommandations de CAMEL.
8.2.4. Le plan fonctionnel rparti
8.2.4.1. Architecture fonctionnelle du rseau intelligent version CS-1

Le plan fonctionnel rparti introduit une architecture fonctionnelle o est plac un
ensemble de fonctions rseaux ncessaires la ralisation des services rseau intelli-
gent. Les principales entits fonctionnelles sont intimement lies la logique de mise
en uvre du service (voir figure 8.3) :
Figure 8.2. Modle conceptuel du rseau intelligent
- la CCAF (Call Control Agent Function) permet un utilisateur de contacter

la fonction de traitement d'appel. Elle collecte et interprte la signalisation issue du
terminal de l'abonn (DTMF, signalisation Q931 du RNIS) en vue d'initier un appel
tlphonique ;
- la fonction de traitement d'appel CCF permet de contrler les appels tlpho-
niques et les ressources associes un appel ;
- la SSF (Service Switching Function) sert reconnatre les demandes de service
rseau intelligent. Elle est galement l'origine du dclenchement des services RI
et joue le rle d'intermdiaire entre la fonction de traitement d'appel et la logique
de service distante (elle informe la SCF de l'occurrence de certains vnements et
rpercute les ordres de la SCF sur la CCF) ;
- la logique de service SCF contient le code applicatif associ au service propos
et supervise distance la fonction de traitement d'appel lorsque cela est ncessaire.
Certaines entits fonctionnelles sont plus lies des donnes ou des ressources
utilises pour la ralisation du service :
- la SDF (Service Data Function) est une base de donnes contenant des informa-
tions associes aux abonns d'un service RI. La SCF a la possibilit de consulter et de
mettre jour certaines de ces informations ;

- la SRF (Service Resource Function) est une ressource de tlcommunications
spcialise permettant l'utilisateur d'interagir avec le service (par exemple serveur
vocal, convertisseur texte/son...).
D'autres entits sont plus en rapport avec l'administration : la SMF (Service Mana-
gement Function) permet l'oprateur d'administrer ses services RI ; la SMAF (Ser-
vice Management Agent Function) est une interface utilisateur permettant l'oprateur
d'utiliser les services apports par le SMF; la SCEF (Service Cration Environment
Function) est une plate-forme de gnie logiciel permettant de dvelopper et de tester
de nouveaux services RI. Ces entits sont cites pour mmoire et ne sont pas dtailles
dans ce chapitre.
8.2.4.2. Architecture fonctionnelle du rseau intelligent : les ajouts de CS-2

La srie CS-2 ajoute essentiellement les deux entits fonctionnelles SCUAF (Ser-
vice Control User Agent Function) et CUSF (Call Unrelated Service Function), nces-
saires pour dclencher des services rseaux intelligent sans tablir d'appel. Le SCUAF
rcupre la signalisation en provenance des utilisateurs et le CUSF est charge de d-
tecter et de dclencher les demandes de services rseau intelligent.
8.2.4.3. L'interface commutateur plate-forme de service

Le cur du plan fonctionnel rparti repose sur les flux d'information changs
entre les entits fonctionnelles SSF et SCF. Cette liaison fonctionnelle reprsente le
lien existant entre un commutateur tlphonique et une plate-forme de service externe.
Le protocole normalisant les changes sur l'interface SSF-SCF est appel INAP.
Le protocole INAP permet la SCF d'influencer le comportement de la fonction

de traitement d'appel d'un commutateur. La SCF envoie des ordres la SSF, qui les
rpercute sur la fonction de traitement d'appel. La SSF tient galement informe la
SCF de tout vnement important survenant lors de l'excution d'un service (demande
de service, connexion/dconnexion d'un utilisateur, information sur le temps coul
depuis le dbut de la communication...).
La SSF fournit par ailleurs une abstraction des activits de la fonction de traite-
ment d'appel. Cette abstraction dfinit les points d'interactions possibles entre une
plate-forme de service externe et un commutateur. La figure 8.3 prcise la structure
de l'interface SSF-CCF et les flux d'informations qui s'changent entre ces entits.
L'interface SSF-CCF est dcoupe en trois blocs principaux [ITU-T Q1214J[ITU-T
Q1224] :
- la BCM (Basic Call Manager) est en relation directe avec la fonction de traite-
ment d'appel tlphonique. Elle dtecte les vnements susceptibles de dclencher un
service rseau intelligent. Cette entit contrle galement les appels et les connexions
Plate-forme de service
Commutateur tlphonique
Figure 8.3. Interface CCF-SSF-SCF
lies une instance de service rseau intelligent. Les activits du BCM sont modli-
ses par un automate appel BCSM ;
- la IN-SSM (Intelligent Network Switching Manager) est une entit qui interagit
directement avec la SCF. La IN-SSM apporte la SCF un modle abstrait permet-
tant de manipuler la topologie et les proprits d'un segment appel li une instance
de service. Ce modle est troitement li au BCSM introduit prcdemment. La IN-
SSM manipule, sur ordre de la SCF ou de la CCF un ensemble d'objets du modle
reprsentant diverses ressources de tlcommunication impliques dans l'appel. La
IN-SSM n'a rellement t utilis qu' partir de CS-2, notamment pour le contrle
des appels multipartite. Le modle abstrait apport par la IN-SSM n'est standardis
que depuis CS-2, et porte le nom de CV (Connection View). Le protocole INAP CS-2
manipule la topologie d'un appel en agissant sur les objets de ce modle3 et non plus
directement sur les automates BCSM comme en CS-1. Les diffrents tats des objets
de modle CV sont normaliss [ITU-T Q1228] et dsigns par le sigle CSCV ;
- la FIM-CM (Feature Interaction-Call Manager) assure la coexistence entre les
instances de service rseau intelligent et les autres types de services, comme par
exemple les services supplmentaires. Elle gre galement les problmes de compati-
bilit pouvant survenir entre la SSF et la SCF.
8.2.4.4. Le modle CSCV

Le modle CSCV introduit quatre objets qui permettent de manipuler distance,
via le protocole INAP, la topologie et l'tat des segments d'appels associs une
mme instance de service rseau intelligent. Les objets leg (voir 8.2.4.4) sont les
ressources de transmission et de commutation utilises par une communication (par
exemple, une liaison entre deux commutateurs tlphoniques). L'objet CP (Connec-
tion Point) est le point de raccordement de plusieurs legs. Le CS reprsente un segment
d'appel (voir figure 8.1). Il peut tre associ un ou plusieurs legs. Le CSA (Call Seg-
ment Association) est un objet pouvant regrouper un ensemble de segment d'appels
associ une mme instance de service rseau intelligent. Un service de mise en at-
tente utilisera deux CS placs dans le mme CSA. Un CS sera associ l'appel actif
et l'autre CS l'appel en attente.
Les objets legs sont appels demi-appels dans la version franaise de la norme.
L'volution de l'tat des legs est dcrite par l'automate BCSM. Il existe deux types
d'objets legs, les controlling legs (ou demis-appels de commande) et les passive legs
(ou demi-appels passifs). Les controlling legs correspondent aux lignes d'accs ser-
vant raccorder les utilisateurs aux commutateurs tlphoniques et aux liaisons inter
commutateurs. Les passive legs servent raccorder les segments d'appels originant
et terminant situs sur un mme commutateur et associs une mme instance de
service. Les conventions adoptes, comme indiqu en figures 8.4 et 8.5, dans les stan-
dards CS-2, font que les controlling legs sont toujours reprsentes gauche (et nots
c) et les passive legs droite (nots pl, p2...). Les controlling legs transportent la
signalisation en provenance des utilisateurs ou des centraux. Les passive legs trans-
portent des signaux internes permettant d'changer des informations entre deux seg-
ments d'appels associs sur un mme commutateur.
Un objet leg peut tre dans un des quatre tats suivants :

- l'tat Joined (en liaison), indique que l'objet est attach un point de raccorde-
ment (toujours reprsent en traits pleins sur les schmas) ;
3. On parle alors de CPH.

( N
-

leg v
CP
CS l CSA
CS: Call Segment
CSA: Call Segment

Association
Leg (passive)
Leg (controling)
CP: Connection Point
Un exemple de CSA
Figure 8.4. Reprsentation graphique des objets du modle CSCV
- l'tat Shared (en partage), utilis uniquement pour les objets de type controlling
leg, indique que la leg est absente du segment d'appel, mais prsente dans un autre
segment d'appel appartenant au mme CSA ;
- l'tat Pending (en instance) correspond au cas o les ressources modlises par
l'objet leg sont en cours de rservation ;
- l'tat Surrogate (de substitution) indique qu'un objet leg est en relation avec un
lment interne du rseau (par exemple un serveur vocal).
La recommandation Q1228 dfinit douze tats CSCV dcrits en figure 8.5. Ils
permettent de modliser les diffrents tats possibles d'un segment d'appel impliqu
dans un service rseau intelligent. Les tats normaliss sont les suivants :
- Null : cet tat modlise les cas o aucun segment d'appel n'existe et o aucun
demi-appel n'est attach un segment d'appel ;
- Originating Setup : un appel dpart destin tablir une communication entre
deux utilisateurs a t initi. La controlling leg est dans l'tat joined ; la passive leg est
dans l'tat pending et est associe un automate OBCSM (Originating BCSM) ;
- Terminating Setup : un appel arriv destin relier deux utilisateurs est dans sa
phase d'tablissement. La controlling leg est dans l'tat pending. La passive leg est
dans l'tat joined et est associ un automate TBCSM (Terminating BCSM)
Figure 8.5. Les diffrents tats CSCV

- Stable 2-Party : un appel est tabli ou est dans une phase de libration. Il peut
s'agir d'un appel dpart ou arrive. Dans tous les cas, la controlling leg est dans l'tat
joined. La passive leg est galement dans l'tat joined et peut tre raccorde soit
un automate OBCSM soit un automate TBCSM (suivant que le segment d'appel
considr est situ sur le commutateur dpart ou le commutateur arrive) ;
- 1-Party : cet tat correspond un appel avec une seule partie en cours d'tablisse-
ment. La controlling leg est dans l'tat joined et il n'y a pas de passive leg associe au
segment d'appel. L'automate BCSM est donc associ la controlling leg en l'absence
de passive leg ;
- Originating 1 -Party Setup : cet tat reprsente un appel dpart dclench depuis
le rseau par la SCF. L'appel est en cours d'tablissement. La controlling leg se trouve
dans l'tat surrogate. La passive leg se trouve dans l'tat passive avec un automate
BCSM associ. Cet tat correspond typiquement la situation o l'on cherche mettre
en relation un utilisateur avec une ressource de tlcommunication spcialise (serveur
vocales, pont de confrences...) ;
- Terminating 1 -Party Setup : cet tat correspond la situation o un appel arri-
ve n'impliquant qu'une partie, est tabli par le rseau. La controlling leg est dans
l'tat surrogate. La passive leg est dans l'tat joined et elle est associe un automate
TBCSM ;
- Stable 1-Party : cet tat reprsente un appel dpart, n'impliquant qu'un seul utili-
sateur, et tabli par le rseau. La controlling leg est dans l'tat surrogate. La passive leg
est dans l'tat joined. Cette dernire est associe un automate OBCSM ou TBCSM,
suivant que le segment d'appel considr est au niveau du commutateur dpart ou du
commutateur d'arrive, et est place dans un tat stable ou de libration ;
- Forward : cet tat modlise un appel rachemin (l'appel peut tre rachemin
au dpart ou l'arrive. Il peut tre dclench aussi bien depuis une phase d'tablisse-
ment que depuis une phase stable de l'appel). La controlling leg se trouve dans l'tat
surrogate. La passive leg l'origine du renvoi est dans l'tat joined. La passive leg en
relation avec l'utilisateur vers lequel l'appel a t renvoy est dans l'tat Pending ;
- Transfer : cet tat modlise un appel transfr. La controlling leg se trouve dans
l'tat surrogate. Les passive leg sont dans l'tat joined. L'appel existant entre les deux
passive leg est forcment dans un tat stable o est sur le point d'tre libr ;
- On hold : un appel est plac en attente. La controlling leg a plac les parties
distantes en attente et est en relation avec un autre appel. La controlling leg est dans
l'tat shared. Les passives leg sont dans l'tat joined ;
- Stable M-Party : un appel multipartite est tabli ou en phase de libration. Toutes
les legs du segment d'appel sont dans l'tat joined.
8.2.4.5. Le modle d'appel du rseau intelligent BCSM

Le principe de base du rseau intelligent consiste dcouper l'appel en tches
lmentaires. Le modle d'appel du rseau intelligent peut tre ainsi assimil un
Figure 8.6. Modle d'appel du rseau intelligent
automate avec des tats et des transitions (voir figure 8.6). Les tats sont appels des
PIC (Point In Call). Par exemple, lorsqu'on compose un numro sur son tlphone,
l'automate BSCM est dans un PIC particulier de collecte de ce numro. Les PIC sont
associs des vnements d'entre et de sortie indiquant respectivement quand un
appel entre dans un tat ou quand il en sort.
Les points de dtection ou DP (Dtection Point) identifient les phases de l'appel o

l'automate CCF-SSF peut interagir avec la SCF. Moins formellement, cela correspond
au fait que le traitement normal de l'appel s'interrompt et que le commutateur va
se mettre temporairement sous le contrle d'un autre entit (c'est--dire le SCF) ou
l'informer d'un vnement.
Les points de dtection sont systmatiquement prsents entre deux tats de l'appel.
Un DP est dfini par deux critres :
- la manire dont il est activ : un DP peut tre arm soit statiquement, par exemple
par voie d'administration, on parle de Trigger Dtection Point ou TDP (Trigger Dtec-
tion Point), soit dynamiquement par la SCF, on parle alors de Event Dtection Point
ou EDP (Event Dtection Point) ;
- le type de relation SSF-SCF qu'il sous-tend. Si le processus d'appel de base est
stopp par l'activation d'un DP, on parle de DP de type requte et la relation SSF-SCF
est une relation de contrle. La SSF stoppe l'excution de la CCF et se met en attente
d'ordres en provenance de la SCF, c'est notamment le cas quand une nouvelle instance
de service rseau intelligent est dclenche. Dans le cas contraire, le DP est de type
notification et la relation SSF-SCF est une relation de supervision. La SSF permet
SSF-SCF relation de SSF-SCF relation de su-

contrle pervision
DP arm statiquement TDP-R (Trigger Dtection TDP-N (Trigger Dtection

TDP Point Request) Point Notification)
DP arm dynamiquement EDP-R (Event Dtection EDP-N (Event Dtection

EDP Point Request) Point Notification)
Tableau 8.3. Diffrents types de point de dtection
la CCF de continuer ses activits. C'est en particulier le cas quand la SSF informe
la SCF de la dconnexion d'un utilisateur. Les procdures de libration de l'appel se
poursuivent sans attendre une rponse de la SCF.
Le tableau 8.3 reprend les diffrents types de DP suivant leurs modes d'activation
et la nature de la relation existant entre la SCF et la SSF.
Par ailleurs le modle d'appel rseau intelligent introduit galement la notion de

critre de dclenchement. Il s'agit d'une condition pralable au dclenchement d'une
interaction entre la SSF et la SCF 4 .
8.2.4.6. Relation entre BCSM et CSCV

L'association entre BCSM et CSCV va dpendre de l'tat du segment d'appel.
Un BCSM est rattach chaque passive leg d'un segment d'appel (dans le cas o
l'appel est dans un tat stable). En l'absence de passive leg dans un segment d'appel,
un BCSM est rattach une controlling leg du mme segment d'appel (ce BCSM
serait supprim si une passive leg venait tre cre ultrieurement dans ce segment
d'appel).
8.2.4.7. Les services non lis des appels

Le CS-1 ne permettait pas de fournir des services qui ne soient pas lis un ap-
pel tlphonique. En effet, le modle BCSM suppose qu'un appel soit dj tabli ou
en cours d'tablissement pour permettre le dclenchement d'une demande de service
rseau intelligent. La recommandation CS-2 et les recommandations ultrieures per-
mette le dclenchement de services non lis un appel en introduisant un nouvel
4. Par exemple la saisie d'un numro dont le prfixe est 0800 suffit reconnatre et dclencher
une demande de service numro vert.
automate. Les tats de cet automate sont appels des PIA (Point In Association). Par
exemple, si sur l'activation d'un contexte PDP (Packet Data Protocol) on souhaite
appliquer une tarification spciale (carte prpaye par exemple), on va dfinir un auto-
mate modlisant les diffrents tats de l'activation d'un contexte PDP. La plate-forme
de services externe aura connaissance de l'tat du contexte PDP via cet automate,
appel BCUSM (Basic Call Unrelated State Model) dans la terminologie rseau intel-
ligent. Il sera alors possible de faire interagir le SGSN (Serving GPRS Support Node)
avec cette plate-forme de service des fins de tarification et de contrle du volume
de donnes. Chaque tat du nouvel automate correspondra un PIA particulier. Cette
nouvelle fonctionnalit est reprise dans CAMEL.
8.2.5. Exemples de services rseau intelligent
8.2.5.1. Le service du numro vert
Le service numro vert permet un utilisateur de joindre gratuitement un numro

spcial, la facturation de la communication tant la charge de l'appel. Le service
numro vert ne peut tre excut par la fonction de traitement d'appel de base du
rseau tlphonique commut car il met en uvre une tarification inverse. L'exemple
qui suit, dcrit le service numro vert dans le plan fonctionnel rparti (description du
service en squence de flux d'information INAP), en supposant que :
- l'appelant est directement rattach un commutateur capable de dclencher des
demandes de service rseau intelligent ;
- les accs des utilisateurs A et B leur commutateur sont des accs de base RNIS.
Dans ces conditions le droulement du service numro vert, dcrit en figure 8.7,
est le suivant :
1) l'utilisateur A dcroche son poste et compose le numro vert de B (typiquement
en 0800). Un message SETUP est gnr par le poste tlphonique de A ;
2) la fonction de traitement d'appel du commutateur de rattachement de A reoit
le message et, en analysant le prfixe du numro vert de B, dtecte une demande de
service rseau intelligent. Ds lors, la CCF interrompt la procdure d'tablissement
d'appel et gnre un TDP-R (voir tableau 8.3) destination de la SSF ;
3) la SSF envoie un message INAP InitialDP destination de la plate-forme de
service pour demander l'ouverture d'une instance de service numro vert. Ce message
contient, entre autres, le numro vert associ l'appel B et l'identit du service
invoquer ;
4) la SCF reoit le numro vert de B. Ce numro n'tant pas routable, la SCF va
demander par interrogation d'une base de donnes (SDF), le numro de tlphone
E.164 associ5 au numro vert de B (par exemple le +33145817314) ;

5) la SDF retourne le numro E. 164 la SCF. La SCF envoie galement la SSF
un message RequestReportBCSMEvent lui demandant de remonter les vnements
de raccrochage et de dcrochage des utilisateurs en positionnant les EDP notification
0_Disconnect et 0_Answer ;
6) la SCF envoie la SSF un ordre de connexion CONNECT pour reprendre la
procdure d'tablissement d'appel entre A et B. La CCF reprend son droulement
normal et tablit l'appel entre A et B ; on utilise pour cela la signalisation tlphonique
conventionnelle ISUP (ISDN User Part) entre commutateurs et Q931 l'accs ;
7) l'appel dcroche et le commutateur de l'appelant en est inform par la
rception du message ISUP ANM (Answer Message). La CCF remonte alors un
EDP-N la SSF. La SSF informe la SCF du dcrochage via l'envoi d'un message
INAP EventReportBCSM contenant le DP qui vient d'tre lev (0_Answer).
8.2.5.2. Appel en attente

Le service d'appel en attente [Q1229] permet un utilisateur de mettre en attente
son correspondant courant et rend ainsi possible le basculement de la ligne vers un
nouveau correspondant. Ce service met en uvre plus de deux parties et requiert l'uti-
lisation des fonctionnalits du jeu de capacit CS-2 du rseau intelligent. Le modle
CSCV et les interactions avec la plate-forme de services dans les phases stables de
l'appel sont galement ncessaires pour mettre disposition ce type de service.
Nous supposerons, dans le cadre de cet exemple, qu'un appel est dj tabli entre
un utilisateur A et un utilisateur B. Un utilisateur C cherche joindre l'utilisateur A
qui est abonn au service de mise en attente. Le droulement du service est alors le
suivant (dcrit en figure 8.8) :
1) la demande d'appel entrante (en provenance de C) parvient au commutateur
de rattachement de l'abonn A. La SSF dtecte que l'abonn est occup et lve le
DP T_Busy qui va servir dclencher le service. La SSF envoie la SCF un mes-
sage initialDP servant dclencher le service d'appel en attente. Le message initialDP
contient l'identit de l'abonn A et l'tat actuel du nouveau segment d'appel (tat Ter-
minating Setup) venant tout juste d'tre cr dans un CSA. Le CSA est identifi par la
rfrence CSAidl ;
2) la SCF demande la SRF (ici un pont de confrence) de lui attribuer un numro
de tlphone temporaire servant raccorder C et le mettre en attente ; puis la SRF
retourne le numro de tlphone attribu C ;
3) la SCF donne maintenant l'ordre la SSF de raccorder l'abonn C la SRF
pour le mettre en attente. L'tablissement de la connexion entre la SSF et la SRF se
fait via une signalisation de type RNIS (procdure non reprsente sur le schma) ;
5. Plan d'adressage international associ au rseau tlphonique public.

b igure 8.7. Le service numro vert
4) la SCF demande au SSF de raccorder l'utilisateur A au SRF pour pouvoir lui

diffuser une annonce vocale servant l'avertir de l'appel de C. Le raccordement entre
le SSF et le SRF peut se faire galement via une procdure de signalisation de type
RNIS;
5) la SCF positionne les EDP-N T_Disconnect et 0_Disconnect pour tre en me-
sure de dtecter les dconnexions de l'utilisateur C au niveau du commutateur arriv
et au niveau de l'appel transfr vers le SRF ;
6) la SCF demande galement la SSF de diffuser une annonce servant avertir
l'utilisateur de l'appel en attente via le message PlayAnnouncement ;
7) l'issue de cet ensemble de procdures, l'abonn C a un appel transfr sur le
SRF (modlis par l'tat Transfer au niveau du SSF). Les abonns A et B sont tou-
jours en communication (modlis par l'tat Stable 2-party) et A reoit une annonce
l'avertissant de l'appel de C.
8.2.6. CAMEL et les rseaux intelligents
CAMEL reprend des standards rseau intelligent la description des services au

niveau du plan fonctionnel rparti. Les autres plans ne sont pas spcifis. En outre
CAMEL utilise uniquement trois des quatre types de DP existants TDP-R, EDP-R et
EDP-N. Les TDP CAMEL sont arms ds rception des diffrentes marques CAMEL6
au niveau du MSC, du GMSC (Gateway Mobile services Switching Center) ou du
VMSC ( Visited Mobile services Switching Center).
8.3. Prsentation de CAMEL
8.3.1. Diffrentes phases de CAMEL
La standardisation de CAMEL a connu quatre phases. Les deux premires phases

ont t spcifies dans le cadre de la normalisation GSM ; les deux dernires phases
sont dans le cadre du 3GPP et concernent la fois GSM-GPRS et l'UMTS.
8.3.1.1. Phases! et 2
La premire phase de CAMEL, dite CAMEL Phase 1, a t normalise en 1997
pour la phase 2+ (release 96) des normes GSM. Ses fonctionnalits sont trs rduites
par rapport au rseau intelligent du rseau tlphonique. La mise au point de l'inter-
face SSF-SCF dans le cas de l'itinrance a constitu la principale difficult rencontre.
C'est aussi son principal intrt : il est possible, pour l'utilisateur, de garder les mmes
services et la mme faon de les utiliser quand il va l'tranger.
6. Voir paragraphe 8.3.3.

Figure 8.8. Le droulement du service d'appel en attente,

extrait de ITU-T Q1229
CAMEL Phase 2 est venu complter la premire phase en apportant tous les ser-
vices rseaux intelligents pouvant tre utiliss en CS-1. En particulier, les connexions
des ressources vocales ont t rendues possibles. CAMEL Phase 2 a t dfini dans
le cadre des release s 97 et 98 du GSM.
8.3.1.2. Phase 3
Les phases 1 et 2 de CAMEL se cantonnaient aux services tlphoniques. CAMEL
Phase 3, dfinie pour la release 99 du GSM et pour les releases 99 et R4 de l'UMTS,
largit de faon trs importante la porte de CAMEL. Il est possible de dclencher
des services dans le domaine paquet (en UMTS ou en GPRS) mais galement lors
de l'envoi de SMS {Short Message Service) ou d'utilisation d'USSD (Unstructured

Supplementary Service Data).
Le dclenchement des services CAMEL dans le domaine paquet se fait depuis le

SGSN. Cette nouvelle fonctionnalit rend possible l'activation des services de tarifi-
cation de type carte prpaye pour des services de transports de donnes. Les services
CAMEL lis au domaine paquet peuvent tre dclenchs lors de l'activation d'un
contexte PDP ou lors de l'attachement du terminal au rseau.
Les services CAMEL dclenchs lors de l'envoi d'un SMS sont, par exemple,
utiles pour permettre un utilisateur de vrifier par SMS son crdit restant sur une
carte prpaye et pour la confirmation de rception de messages courts.
La fonctionnalit USSD ou service supplmentaire non structur permet l'ouver-

ture de sessions de donnes bas dbit. L'USSD dfinit un protocole permettant un
change de transactions gnriques. Le couplage avec une plate-forme de service CA-
MEL rend possible l'interaction entre un utilisateur et une logique de service CAMEL
et permet donc d'offrir des services en vitant de passer par une ressource de tl-
communications spcialise, par exemple un serveur vocal charg de collecter des
squences DTMF tapes par un utilisateur. Cela constitue un exemple de service RI
dclench en dehors d'un appel. Il s'agit d'un mcanisme OCCUUI selon la termi-
nologie dfinie en CS-2, c'est--dire sans relation avec un appel. Le dclenchement
du service se fait lors de la rception de commandes USSD en provenance du mobile
systmatiquement au niveau du HLR (Home Location Register).
Le dclenchement de services CAMEL depuis une instance de service suppl-

mentaire existante tait possible en phase 2 mais seulement pour un nombre limit
de services supplmentaires. CAMEL phase 3 accrot l'ensemble des services sup-
plmentaires concerns : renvoi d'appel, confrence d'appel, transfert d'appels. Le
dclenchement s'opre systmatiquement depuis le MSC
L'intrt de coupler CAMEL et les USSD ou les services supplmentaires est le

mme que pour les services tlphoniques : l'utilisateur garde les mmes services
quand il va l'tranger; il peut, par exemple, activer le renvoi d'appel hors de son
rseau nominal.
8.3.1.3. Phase 4
La phase 4 de CAMEL est en cours de normalisation (release 5 et ultrieures).
Elle s'inspire fortement du CS-2. Il est possible de dclencher des services depuis les
phases stables d'un appel. Cette fonction permet entre autres de taper des squences de
touches DTMF pour interagir avec une instance de service existante7. CAMEL Phase
7. Notamment pour les services de confrence.

4 permet le routage optimal pour les appels du domaine circuit tablis de mobile mo-
bile. Il supporte galement des appels multipartite et permet de crer un nouvel appel
depuis une instance de service CAMEL ; l'appel cr n'est pas ncessairement li un
appel existant 8 . Cette fonction est utilise pour les services de mise en attente ou de
confrence. Par ailleurs, CAMEL phase 4 permet d'invoquer des services multimdia
bass sur la technologie IP 9 .
8.3.1.4. Mthodologie de spcification

Chaque phase de CAMEL est dveloppe selon une mthodologie en trois tapes 10 .
La premire tape dcrit les services offerts par la nouvelle phase CAMEL. La deuxime
tape traite essentiellement de l'architecture fonctionnelle de CAMEL, des modles
d'appel et des marques CAMEL 11 . La troisime tape spcifie le protocole CAP.
Toute nouvelle phase CAMEL doit supporter tous les services des phases prcdentes.
En consquence nous ne dcrirons pas les phases 1 et 2 mais seulement la phase 3 et
la phase 4 dans la suite de l'expos.
8.3.2. Architecture fonctionnelle
L'architecture fonctionnelle de CAMEL phase 3 reprend les entits fonctionnelles

dfinies dans le rseau intelligent en les dclinant dans le domaine circuit et dans le
domaine paquet du rseau cur de l'UMTS.
La fonction de traitement d'appel gsmCCF (GSM Call Control Function) permet

de contrler les appels et les connexions associes un appel mobile. Elle est typi-
quement situe dans le MSC et jour un rle analogue la CCF du rseau intelligent.
La fonction gsmSSF (GSM Service Switching Function) permet de reconnatre les de-
mandes de service CAMEL, dclenche les services CAMEL et apporte des fonctions
analogues la SSF du rseau intelligent. Elle est galement situe dans le MSC (voir
figure 8.9).
La logique de service CAMEL ou gsmSCF (GSM Service Control Function) inclut

un programme servant piloter distance la fonction de traitement d'appel. Cette
fonction hberge la logique de service CAMEL et joue donc un rle similaire la SCF
du rseau intelligent. La gsmSRF (GSM Service Resource Function) est une ressource
de tlcommunications spcialise permettant l'utilisateur d'interagir avec le service
choisi (par exemple serveur vocal). Cette fonction joue le mme rle que la SRF du
rseau intelligent.
8. Utilisation des capacits CS-2 du rseau intelligent.

9. Ce qui rejoint les objectifs du CS-4 du rseau intelligent.
10. Les tapes sont appeles stage dans la nomenclature UMTS.
11. Voir paragraphe 8.3.3.
RNC i SGSN GGSN
Domaine paquet
i Entits fonctionnelles CAMEL
Figure 8.9. Architecture fonctionnelle de CAMEL
Le domaine paquet comprend l'entit fonctionnelle gprsSSF (GPRS Service Swit-

ching Function). Elle est situe sur le SGSN et permet de dclencher des services
CAMEL depuis le domaine paquet. Elle est l'analogue de la gsmSSF du domaine
circuit.
8.3.3. Les marques CAMEL
Les marques CAMEL ou CSI sont des structures de donnes qui dterminent les
conditions dans lesquelles le service CAMEL peut tre dclench pour un abonn
donn. Elles sont tlcharges depuis la HLR dans le VLR ( Visitor Location Register)
ou le SGSN lors des procdures de mise jour de localisation et d'attachement. Les
marques CAMEL permettent de dterminer si un service CAMEL doit tre dclench
et de retrouver la localisation du serveur applicatif mettant disposition le service
demand. Les principales marques CAMEL sont regroupes dans le tableau 8.4. On
peut constater qu'il y a peu de diffrences entre la phase 3 et la phase 4.
Critre de dclenchement du service CAMEL Lieu de stockage en

CSI
dehors HLR du r-
seau nominal
D-CSI Liste de dix numros personnaliss permettant de
VLR du rseau vi-
dclencher des services CAMEL
sit, GMSC lors d'un
appel entrant
GPRS-CSI Ouverture d'une session GPRS (General Packet
SGSN
Radio Service) ou lors de l'activation d'un nou-
veau contexte PDP
M-CSI Changement de zone de localisation
VLR du rseau visit
O-CSI Appel dpart depuis un MSC du rseau visit, appel
VLR du rseau vi-
entrant parvenu un GMSC, ou appel renvoy au
sit, GMSC
niveau d'un MSC du rseau visit ou d'un GMSC
MO-SMS- envoi d'un message court
VLR du rseau vi-
CSI 12
sit, SGSN
MT-SMS-CSI rception d'un message court
VLR du rseau vi-
(phase 4)
sit, SGSN
SS-CSI Activation d'un service supplmentaire
VLR du rseau visit
T-CSI Appel arrive depuis un GMSC
GMSC
U-CSI Rception au niveau du HLR d'une commande
USSD (marque spcifique un abonn CAMEL)
Tableau 8.4. Quelques exemples de marques CAMEL phase 3 et phase 4

d'aprs 3GPP 22.078 v5.7.0
Une marque CAMEL contient toujours les lments d'informations suivants :

- TDP l'origine du dclenchement du service CAMEL ;
- adresse de la gsmSCF fournissant le service demand ;
- identit du service demand (Service Key dans la terminologie CAMEL) ;
- comportement que doivent adopter les gsmSSF ou gprsSSF si le dialogue CAP
entam avec la gsmSCF venait chouer (Default Call Handling dans la terminolo-
gie CAMEL). Ce paramtre peut prendre les valeurs Release (arrter l'excution du
service) ou Continue (continuer le service) ;
- le paramtre Capability Handling indique la version du protocole CAP qui peut
tre utilise dans le cadre du service demand ;
- les critres de dclenchement du service CAMEL (par exemple prfixe de nu-
mro compos) ;
- l'tat de la marque (active/inactive).
8.4. CAMEL et le domaine circuit
8.4.1. Les automates CAMEL phase 3 du domaine circuit
8.4.1.1. L'automate dpart OBCSM
L'automate dpart ou OBCSM est dcrit en figure 8.10. On y retrouve les phases
classiques de tout appel : collecte du numro compos par l'usager, analyse de ce
numro pour dterminer ensuite le routage et mise en relation. Suivant le formalisme
indiqu dans la figure 8.6, les petits rectangles reprsentent les points de dtection,
c'est--dire tous les endroits o le traitement peut tre suspendu pour faire appel un
service RI ou pour faire une notification.
De faon dtaille, les tats sont les suivants :

- l'tat 0_Null&Authorize, 0_Origination_attempt, 0_Collect_information, cor-
respond un tat neutre : aucun service n'est dclench, le rseau est en train de dter-
miner si un utilisateur a le droit de lancer le service qu'il demande, les donnes saisies
par l'utilisateur sont en cours de collecte de manire dterminer s'il faut dclencher
un service CAMEL ;
- Analyse_information : les informations collectes dans l'tat prcdent sont ana-
lyses pour procder au routage de l'appel ;
- Routing and Alerting : dans cet tat l'appel est rout jusqu' l'appel qui est
inform de l'arrive de l'appel ;
- 0_Active : l'appel est actif et les utilisateurs peuvent parler;
- 0_Exception : une erreur est survenue dans l'une des phases antrieures de l'ap-
pel et l'automate place l'appel dans cet tat avant de le librer.
Les points de dclenchement dfinis pour l'automate OBCSM sont les suivants :
- Collected_Info permet de dclencher un service CAMEL l'issue de la saisie
d'un numro par l'appelant ;
- Analyzed_Info permet de dclencher un service CAMEL lorsque le numro
compos par l'appelant a t traduit par la fonction de traitement d'appel 1 3 ;
- 0_Answer permet de dclencher un service CAMEL ds que le rseau averti
l'appelant (gnralement via un message ISUP de type ANM) que l'appel a dcro-
ch ;
13. La traduction est opre par la fonction de traitement d'appel. Elle dtermine partir d'un
numro de tlphone, un acheminement pour l'appel en cours.
- Route_Select_Failure permet de dclencher un service CAMEL s'il n'est pas

possible de trouver une voie d'acheminement pour l'appel ;
- 0_Busy permet de dclencher un service CAMEL lorsque l'appel est occup ;
- 0_No_Answer permet de dclencher un service CAMEL si l'appel ne rpond
pas l'appel entrant ;
- 0_Routing_and_alerting_failure permet de dclencher un service CAMEL si
l'acheminement de l'appel ou l'alerte de l'appel chouent.
Le lecteur peut constater que les points de dclenchement vont bien au-del de
la simple analyse du numro demand. Cela permet d'envisager d'offrir un grand
nombre de services partir du concept de rseau intelligent.
8.4.1.2. L'automate arrive TBCSM

L'automate arrive TBCSM, dcrit en figure 8.11, passe par les tats suivants :
- T_Null : Le service n'est pas encore dclench ;
- l'tat Terminating_Call_Handling correspond un appel qui arrive; soit le r-
seau est en train de vrifier qu'il est possible de contacter la personne appele ; soit le
terminal de l'appel est alert de l'arrive de l'appel ;
- T_Active : lorsque l'appel dcroche, l'automate passe dans cet tat et l'appel
devient actif ;
- T_Exception : une erreur est survenue dans l'une des phases antrieures de l'ap-
pel. L'appel est plac dans cet tat avant libration.
Les points de dclenchement dfinis pour l'automate TBCSM sont les suivants :
- Terminating_Attempt_Authorized permet de dclencher un service CAMEL
juste aprs que le fonction de traitement ait dtermin que l'appel est autoris rece-
voir l'appel ;
-T_Busy permet de dclencher un service CAMEL si l'appel est occup (par
exemple renvoi d'appel sur occupation) ;
- T_No_Answer permet de dclencher un service CAMEL si l'appel ne rpond
pas l'appel entrant (par exemple renvoi d'appel sur non-rponse) ;
- T_Call_Handling_failure permet de dclencher un service CAMEL dans le cas
o l'tablissement de l'appel arrive choue ;
- T_Answer permet de dclencher un service CAMEL si l'appel rpond l'appel
(il dcroche) ;
- T_active_failure permet de dclencher un service CAMEL si le service en cours
d'excution subit une erreur ;
- T_Disconnect permet de dclencher un service CAMEL l'issue du raccrochage
d'un utilisateur;
O.Disconnect G active failure
Figure 8.10. Automate 0_BCSM CAMEL phase 3, d'aprs 23.078 v3.13.0
- T_Abandon permet de dclencher un service CAMEL dans le cas o l'appel

n'est pas joignable.
8.4.2. Evolution des automates en phase 4
L'automate dpart de CAMEL phase 4, reprsent en figure 8.12, modifie celui

de CAMEL phase 3 en sparant l'tat Routing de l'tat Alerting. Cette distinction est
ncessaire dans le mesure o l'on souhaite dclencher des requtes de service depuis
Figure 8.11. Automate TBCSM CAMEL Phase 3, d'aprs 23.078 v3.13.0
toutes les phases stables de l'appel. En outre, trois nouveaux points de dclenchement
ont t ajouts l'automate dpart CAMEL phase 3 :
- 0_Term_Seize permet de dclencher un service CAMEL lorsque le central de
l'appel a acquitt la demande d'tablissement d'appel et que toutes les ressources
rseau sont rserves entre l'appelant et l'appel ;
- 0_Mid_Call rend possible l'interaction d'un utilisateur avec une plate-forme de
service alors que l'appel est dj tabli ;
- 0_Change_Of_Position sert dclencher un service CAMEL chaque change-
ment de zone de localisation d'un abonn.
L'automate arrive de la phase 4, reprsent en figure 8.13, reprend l'automate

de la phase 3 et scinde l'tat Terminating Call Handling en deux nouveaux tats :
Select_Facility_And_Present_Call et T_Alerting. Cette sparation est ncessaire pour
pouvoir dclencher des services alors que l'appel est dj contact mais qu'il n'a pas
0_Mid_call 0_Change_Of_Position
Figure 8.12. Automate O-BCSM CAMEL phase 4 d'aprs 3GPP 23.078 v5.0.0
T_Mid_Call T_Change_Of_Position
Figure 8.13. Automate TBCSM CAMEL phase 4 d'aprs 3GPP v5.0.0
encore dcroch (phase stable de l'appel). Le point de dclenchement T_Mid_Call a

t ajout pour permettre l'interaction entre un utilisateur et une plate-forme de ser-
vices lorsque l'appel est dj tabli. Le point de dclenchement T_Change_Of_Position
a t, quant lui, introduit pour rendre possible l'activation d'un service CAMEL lors
de tout changement de zone de localisation.
8.5. CAMEL et le domaine paquet
CAMEL phase 3 et phase 4 permettent tous deux l'activation d'un service dans le
domaine paquet. Les automates sont identiques dans les deux cas.
Les tats des automates du domaine paquets sont des PIA car ils servent dclen-
cher des services rseau intelligent indpendamment d'un appel tlphonique. C'est
toujours le cas pour des services CAMEL dclenchs depuis le domaine paquet ou le
rseau GPRS. Les standards CAMEL dfinissent deux situations o un service CA-
MEL peut tre dclench :
- lors de l'attachement d'un terminal au domaine paquet (par exemple, pour v-
rifier qu'un utilisateur prpay dispose encore de suffisamment de crdit pour utiliser
les services du domaine paquet) ;
- lors de l'activation d'un contexte PDP (par exemple pour vrifier qu'un utilisa-
teur prpay dispose de suffisamment de crdit pour utiliser le service demand lors
de l'activation de contexte PDP).
Dans tous les cas, les services CAMEL de type paquet sont dclenchs depuis le
SGSN.
8.5.1. Automate d'attachement-dtachement GPRS
La figure 8.14 dcrit l'automate associ au dclenchement d'un service CAMEL

lors de l'attachement ou du dtachement d'un utilisateur mobile au domaine paquet.
Trois tats sont dfinis dans cet automate :
- l'utilisateur mobile n'est pas attach au domaine paquet du rseau ;
- l'utilisateur mobile est attach au domaine paquet du rseau ;
- la situation d'exception (une erreur est survenue lors de l'attachement ou du
dtachement du mobile) ;
Les points de dclenchements permettent de lancer un service CAMEL lors de l'at-

tachement au domaine paquet (DP Attach request), lors du dtachement du domaine
paquet GPRS (DP Detach) et lors de tout changement de zone de routage impliquant
un changement de SGSN.
8.5.2. Exemple d'activation de service
La figure 8.15 dcrit un exemple de service CAMEL dclench lors de l'attache-

ment d'un utilisateur mobile au domaine paquet. Il s'agit de vrifier qu'un utilisateur
de carte prpaye a suffisamment de crdit pour utiliser les services du domaine pa-
quet. La vrification du montant disponible sur la carte prpaye se droule selon les
tapes suivantes :
1) l'utilisateur dclenche la procdure d'attachement au domaine paquet via les
procdures GMM (GPRS Moblility Management). Cette procdure est initie par l'en-
voi d'un message GMM Attach Request ;
2) nous supposons ce stade que l'utilisateur s'est correctement authentifi auprs
du rseau. La HLR va alors tlcharger le profil de l'abonn dans le SGSN. Ce profil
contient, entre autres, les marques CAMEL associs aux services dclenchables par
l'utilisateur;
Figure 8.14. Automate attach-detach GPRS CAMEL phase 3,

d'aprs 23.078 v3.13.0
3) en analysant les marques, la gprsSSF s'aperoit de la prsence de la marque

GPRS-CSI (GPRS CAMEL Subscription Information) et dclenche l'envoi d'une re-
qut CAP destination de la gsmSCF. Le message CAP Initial DP GPRS contient le
DP ayant dclench l'envoi de cette requte (DP Attach) ;
4) La gsmSCF vrifie si l'utilisateur a suffisamment de crdit et, dans l'affirmative,
envoie la gprsSSF une squence de commandes CAP indiquant une liste d'vne-
ments remonter et l'tat du crdit sur la carte (volume de donnes autoris ou temps
de connexion autoris) ;
8.5.3. Automate de contexte
La figure 8.16 dcrit l'automate associ au dclenchement d'un service CAMEL

lors de l'activation d'un contexte PDP. Cet automate comprend cinq tats :
- Idle : cet tat traduit l'absence de contexte PDP entre le rseau et le mobile ;
- PDP_Context_Setup : dans cet tat, le mobile a sollicit l'tablissement d'un
contexte PDP, mais celui-ci n'est pas encore tabli ;
- PDP_Context_Established : le contexte PDP est tabli entre le mobile et le r-
seau ;
HLK
Mobile SGSN GGSN SCF
Figure 8.15. Vrification du crdit d'une carte prpaye lors de rattachement

du terminal au domaine paquet
- Change_Of_Position_Context : cet tat correspond la situation o le mobile

change de zone de routage et o un nouveau contexte PDP est tabli dans la nouvelle
zone de routage ;
- C_Exception : une erreur s'est produite lors la cration d'un contexte PDP ou
lorsqu'un contexte PDP tait actif ;
Les points de dclenchement permettant d'activer un service CAMEL lors d'une

procdure lie un contexte PDP sont les suivants :
- PDP Context Setup Establishment : permet de dclencher une interaction CAP
ds que l'utilisateur a demand l'activation d'un contexte PDP et avant que le rseau
ne cherche tablir un contexte PDP ;
- PDP Context Setup Ack : permet de dclencher une interaction CAP aprs que
le rseau ait commenc tablir un PDP contexte ;
- Change Of position Context : permet de dclencher une interaction CAP lors
d'un changement de zone routage ;
- PDP Context Disconnection : permet de dclencher une interaction CAP lors de
la dsactivation d'un contexte PDP.
Figure 8.16. Automate de contexte GPRS CAMEL phase 3, d'aprs 23.078

v3.13.0
8.5.4. Exemple de service sur activation d'un contexte
La figure 8.17 donne un exemple de dclenchement de service CAMEL lors de

l'activation d'un contexte PDP. Il s'agit d'un utilisateur accdant un service pr-
pay. Le rseau va pralablement vrifier que l'utilisateur dispose de suffisamment de
crdit avant de lui donner l'accs au rseau. La procdure CAP permettant d'activer
le service de donnes par carte prpaye se droule de la manire suivante :
1) l'activation d'un contexte PDP est dclenche via les procdures SM (Session
Management) et est initie par le message SM Activate PDP Context Request ;
2) l'utilisateur tant dj attach au rseau, le SGSN contient dj la marque
GPRS-CSI et la gprsSSF va dclencher une interaction CAP avec la gsmSCF.
i
3) la gsmSCF envoie un certain nombre d'informations de tarification au SGSN ;

4) un tunnel GTP (GPRS Tuneling Protocol) est tabli entre le SGSN et le GGSN
(Gateway GPRS Support Node) ;
5) La gprsSSF informe la gsmSCF de la fin de l'tablissement du contexte PDP
et du dbut de la session GPRS ( des fins de tarification). La gsmSCF informe la
gprsSSF qu'il a pris acte du dbut de la session ;
6) Le rseau informe le mobile que le PDP contexte est actif. Le mobile peut com-
mencer envoyer des donnes.
8.6. CAMEL et les changes de SMS
8.6.1. CAMEL phase 3 et les envois de SMS
CAMEL phase 3 permet de dclencher des services CAMEL lors de l'envoi de

SMS par un abonn. Le dclenchement du service se fait au niveau du MSC pour le
domaine circuit 14 ou au niveau du SGSN 15 pour le domaine paquet.
L'automate dcrivant les interactions possibles entre l'envoi d'un SMS et un ser-
vice CAMEL est illustr figure en 8.18. Cet automate est commun au SGSN et au
MSC.
Il est possible de dclencher une interaction CAP lorsque l'utilisateur sollicite

l'envoi d'un SMS pour vrifier son crdit (DP SMS_Collected_Info). Une interaction
CAP peut galement tre dclenche une fois que le SMS a t envoy. La dernire
possibilit d'activation de requte CAP correspond au cas o l'envoi de SMS aurait
chou.
L'exemple dcrit en figure 8.19 montre le cas d'un utilisateur disposant d'une carte
prpaye pour les SMS. La procdure CAP permettant de vrifier que l'utilisateur
dispose de suffisamment de crdit pour envoyer son message court se droule de la
manire suivante :
1) l'utilisateur sollicite l'envoi de son message court ;
2) la prsence de la marque SMS-CSI dans le SGSN, tlcharge lors de la proc-
dure d'attachement de l'utilisateur au domaine paquet, permet de dclencher l'envoi
d'un message CAP vers la gsmSCF. Ce message informe la gsmSCF que l'abonn
prpay considr cherche envoyer un mini message ;
3) la gsmSCF vrifie le crdit de l'abonn et autorise l'envoi du message court
en rpondant avec le message Continue SMS. La gsmSCF demande galement la
14. Dans ce cas, c'est la gsmSSF qui dclenche le service.

15. Dans ce cas, c'est la gprsSSF qui dclenche le service.
Mobile SGSN GGSN SCF

Figure 8.17. Activation d'un contexte PDP dans le cadre d'un service de carte
prpaye pour le transport de donnes dans le domaine paquet
gprsSSF de l'informer ds que le message court a t remis au destinataire (demande

de remonte du DP O-SMS-Submitted) ;
4) le SGSN envoie le message vers le centre de messagerie ;
5) un accus de rception est dlivr au SGSN et l'utilisateur final. Le SGSN
remonte le DP O-SMS-Submitted pour informer la gsmSCF que le mini message a t
correctement remis et pour mettre jour le crdit de l'utilisateur.
Figure 8.18. Automate SMS dpart d'aprs 3GPP 23.078 v3.13.0
8.6.2. CAMEL Phase 4 et la rception de SMS
CAMEL phase 4 ajoute par ailleurs la possibilit de dclencher un service lors de

la rception d'un SMS. L'automate dcrivant les points d'interaction possibles entre
la rception d'un SMS et CAMEL sont dcrits par l'automate de la figure 8.20.
8.7. CAMEL phase 4 et le sous-systme IP multimdia
8.7.1. Introduction SIP
Le protocole SIP est un standard de l'IETF (Internet Engeneering Task Force).

Il permet des quipements d'tablir ou de rejoindre des sessions multimdia sur
l'Internet. Une session est une association entre plusieurs terminaux souhaitant com-
muniquer entre eux via un ou plusieurs mdias. Elle peut donc se matrialiser sous des
formes aussi diverses qu'une confrence vido multicast ou encore un appel voix sur
IP. SIP peut tre vu comme un protocole d'tablissement d'appels sur IP. Nanmoins
il ne spcifie ni la nature ni les attributs des mdias associs la session. Ces informa-
tions sont dcrites au moyen de la syntaxe SDP (Session Description Protocol), qui
est encapsule dans les messages SIP. La description et la ngociation des capacits
de chaque terminal est donc faite travers cette syntaxe. SIP a toutefois la possibilit
d'utiliser une autre syntaxe que SDP.
MS SGSN SCF SMS-IWMSC
Figure 8.19. Vrification du crdit d'une carte prpaye lors de l'envoi d'un
SMS par le domaine paquet
SIP est un protocole de type client/serveur, fortement inspir de HTTP (Hyper Text
Transfer Protocol) et de SMTP (Simple Mail Transfer Protocol). Il reprend de HTTP
la syntaxe des commandes et des rponses. Le formats des en-ttes des messages SIP
proviennent en grande partie de SMTP 16 .
Les messages SIP peuvent tre de type requte ou de type rponse. Les premires
requtes SIP 2.0 avoir t dfinies sont les suivantes :
16. En-ttes FROM, TO.

Figure 8.20. Automate SMS arrive d'aprs 3GPP 23.078 v5.0.0
- le message INVITE permet un client d'initier une confrence multimdia ou de

demander son rattachement une confrence multimdia existante. Ce message initie
la ngociation des paramtres associs une session tels que le port TCP (Transmis-
sion Control Protocol) ou UDP (User Datagram Protocol) qui va recevoir les flux
multimdia ou le type de CODEC utilis (via la syntaxe SDP) ;
- le message ACK est envoy pour acquitter le bon droulement d'une transaction
SIP. Ainsi, lorsqu'un client demande tablir une nouvelle session, ce message sert
indiquer la fin de la phase d'tablissement. Dans certaines situations, ce message
peut contenir des lments d'information dcrivant les paramtres des flux multimdia
associs la session ;
- le message OPTIONS permet des serveurs SIP de s'changer des informations
sur les capacits mutuelles des clients qui transitent par eux ;
- le message REGISTER permet client d'informer un serveur SIP (le registrar)
de sa nouvelle localisation ;
- le message CANCEL met fin une transaction SIP ;
- le message BYE est envoy par un client d'autres clients pour les informer
qu'il quitte la session en cours. Dans le cas d'une session point point, ce message
libre la session courante.
Progressivement d'autres types de requtes ont t ajouts au protocole, comme

par exemple les requtes NOTIFY et SUBSCRIBE qui sont utilises pour les services
de prsence. Elles permettent un client de demander tre inform de l'occurrence
de certains vnements (mthode SUBSCRIBE) et au serveur d'informer le client de
l'occurrence des ces vnements (mthode NOTIFY). La prsence ou l'absence d'un
utilisateur appartenant un groupe peut ainsi tre notifi aux autres utilisateurs du
groupe (utiles pour les services s'appuyant sur des listes de prsence, par exemple
messagerie instantane, appels de groupes /dots).
Les rponses SIP 2.0 maintiennent le client inform sur l'tat d'une session en
cours. Elles sont exprimes sous la forme d'un nombre de 100 699, le premier chiffre
indiquant le type de rponse :
- toutes les rponses dont le code commence par 1 informent un client sur l'tat
de sa requte en cours ;
- les rponses de type 2 sont envoyes un client pour l'informer que sa requte a
t convenablement prise en compte ;
- les rponses de type 3 informent le client que l'appel a chang de terminal et
qu'il est ncessaire d'effectuer des oprations supplmentaires pour mener bien la
requte ;
- les rponses de type 4 signalent une erreur dans le traitement d'une requte SIP.
La requte prsente a par exemple une syntaxe incorrecte ;
- les rponses de type 5 informent le client que le serveur SIP demand ne rpond
plus;
- les rponses de type 6 signalent que la requte SIP n'a pu tre traite par aucun
serveur.
Hormis les types de la requte et de la rponse, les messages SIP contiennent ga-
lement un en-tte contenant plusieurs lments d'information prcisant par exemple
la provenance du messages (en-tte FROM), l'identit de la session (en-tte Call ID)
ou encore le destinataire du message SIP (en-tte TO). SIP 2.0 prvoit galement un
emplacement optionnel destin contenir la description d'une session. Les sessions
sont dcrites en utilisant la syntaxe SDP.
8.7.2. SIP et le sous-systme IP multimdia
La release 5 de l'UMTS a introduit la possibilit d'accder des services Internet

multimdia depuis un mobile. L'invocation de ces services se fait via le protocole SIP.
Les serveurs SIP sollicits par le mobile se trouvent regroups dans le sous-systme
IP multimdia. Ils sont accessibles en passant par le domaine paquet du rseau (il est
ncessaire d'tablir au pralable un contexte PDP avec le domaine paquet) et peuvent
galement tre relis l'Internet.
Figure 8.21. Le sous systme IP multimdia
Trois types de serveurs ont t dfinis (voir figure 8.21) :

- Les P-CSCF (Proxy Call Session Control Function) jouent un rle analogue au
VLR du domaine circuit. Le terminal contacte le P-CSCF lors des procdures d'enre-
gistrement et d'tablissement de session. Le P-CSCF redirige toutes les requtes SIP
vers le S-CSCF (Serving Call Session Control Function) (situ dans le rseau d'ori-
gine) ;
- Les I-CSCF (Interrogating Call Session Control Function) ont une fonction si-
milaire au GMSC du domaine circuit. Ils interrogent le HSS (Home Subsriber Server)
du rseau nominal pour retrouver l'emplacement du S-CSCF ;
- Les S-CSCF contrlent le droulement d'une session, mme lorsque l'utilisa-
teur est en roaming. Ils sont galement en charge de dclencher le service associ
la session en contactant la plate-forme logicielle, AS (Application Server) mettant
disposition le service sollicit. La plate-forme de service peut tre contacte via le
protocole SIP, une interface CAMEL ou encore une interface OSA.
D'autres entits fonctionnelles ont t introduites pour assurer le bon fonction-

nement du systme IMS (IP multimdia Subsystem). Le HSS est une gnralisation
de la HLR utilisable dans le domaine circuit, dans le domaine paquet et dans l'IMS.
Des passerelles de transcodage MGW (Media Gateway), non reprsentes sur la fi-
gure 8.21, permettent de grer le passage d'un rseau IP d'autres types de rseau
(par exemple pour joindre un rseau tlphonique). Elle sont pilotes distance par
une entit externe MGCF (Media Gateway Control Function) via le protocole H.248.
D'autres entits comme la MRF {Media Resource Function) mettent dispositon des
services comme la confrence multimdia).
Dans tous les cas, le service IMS et son application associe, sont excuts dans
le rseau nominal. Cela permet l'utilisateur de pouvoir bnficier exactement du
mme service mme cas de dplacement l'tranger (pas de problme de paramtrage,
conservation de l'environnement utilisateur...).
8.7.3. CAMEL phase 4 et le sous-systme IP multimdia
CAMEL phase 4 permet de dclencher un service CAMEL depuis le sous-systme

IP multimdia. L'entit fonctionnelle IM-SSF (IP Multimedia-Service Switching Func-
tion) joue un rle similaire la gsmSSF et la gprsSSF. Elle est plac sur un qui-
pement de l'IMS et permet d'envisager des services prpays qui seraient fournis sur
l'IMS. Elle est relation avec la S-CSCF qui joue un rle analogue la fonction de
traitement d'appel (gsmCCF). Le dclenchement de services CAMEL depuis l'IMS
est dtect par la prsence d'une nouvelle marque CAMEL, IM-CSI (IP Multimedia
Camel Subscription Information), qui est tlcharge depuis le HSS dans la IM-SSF
via la S-CSCF.
8.8. Prsentation d'OSA
8.8.1. Introduction
La norme OSA a t introduite pour faciliter la rutilisation et le dveloppement

de services se basant sur les fonctionnalits d'un rseau radio mobile. OSA s'est beau-
coup inspir de travaux mens dans le cadre du consortium Parlay. L'objectif de Parlay
est de rendre autant que possible le dveloppement des applications indpendant des
rseaux les supportant. Les applications et les couches rseaux sont spares par une
nouvelle couche dite intergicielle 17 . Les applications n'accdent plus directement aux
fonctions offertes par le rseau 18 , mais s'adressent l'intergiciel qui fait office d'in-
termdiaire. Les fonctions rseau sont maintenant invocables par les applications
17. Middleware.
18. Fonctions lies la localisation, ou de contrle d'appels, ou de contrle de ressources de
tlcommunications.
travers des interfaces standardises au niveau de l'intergiciel, appeles API (Applica-

tion Programming Interface).
OSA dfinit donc une architecture qui permet aux oprateurs et aux fournisseurs
de service tiers d'utiliser les fonctions apportes par un rseau au travers d'une API
standardise. Les fonctions ainsi apportes sont dveloppes au sein de serveurs ap-
plicatifs appels SCS (Service Cration Server). Les SCS cachent aux applications la
complexit du rseau radio mobile sous jacent en tablissant la correspondance entre
les services apportes par les API au niveau applicatif et les protocoles de signalisa-
tion (MAP (Mobile Application Part), CAP, ISUP...) utiliss au niveau du rseau. La
figure 8.22 apporte une vue d'ensemble de l'architecture d'OSA. Trois niveaux sont
prsents :
- le premier niveau correspond aux applications qui sont proposes aux utilisateurs
finals. Les applications sont places sur des serveurs et peuvent tre dveloppes dans
n'importe quel langage ;
- le deuxime niveau regroupe les SCS dont les fonctions sont accessibles travers
les API OSA. Un SCS particulier appeler Framework apporte plusieurs mcanismes
de bases pralables l'invocation de tout service :
- services d'authentification servant vrifier qu'une application a bien accs
au rseau considr,
- service de dcouverte permettant une application, une fois l'authentification
russit, d'obtenir une liste des services rseau accessibles depuis les SCS ;
- le troisime niveau regroupe les diverses technologies rseau utilises par les
SCS.
Les services proposs par les diffrents SCS OSA sont spcifis comme un en-
semble d'interfaces contenant les mthodes invocables par les applications. Les inter-
faces se subdivisent en deux familles. La premire famille d'interfaces permet d'acc-
der au SCS framework. La deuxime famille d'interfaces permet d'utiliser les services
rseaux offerts par certains SCS.
8.8.2. Services apports par OSA
La sparation entre la logique de service place dans les applications et les fonc-
tions rseau accessibles depuis les SCS facilite le dveloppement de nouvelles appli-
cations et permet de mettre disposition un mme service sur diffrents rseaux. Bien
que les standards introduisent un certain nombre de services cibles pour illustrer l'uti-
lisation de OSA, il n'entre pas dans le cadre de la norme de standardiser toutes les
offres de services.
API interne OSA
Figure 8.22. Vue d'ensemble de OSA, d'aprs 23.127, page 10
8.8.3. Typologie des interface OSA
8.8.3.1. Interfaces et services associs au S( \SJraniework
Les familles d'interfaces permettant d'accder au serveur Framework sont les sui-
vantes :
l'interface d'authentilication permet aux applications et au SCS Framework de
s'authentifier mutuellement 19 . La phase d'authentifieation est pralable l'utilisation
de tout autre API OSA;
- l'interface d'autorisation permet une application de dterminer l'ensemble des

API qu'elle a le droit d'invoquer;
- F interface de dcouverte permet une application de rcuprer l'ensemble des

fonctions mises disposition par une API :
19. Utilise notamment entre les Fournisseurs de service tiers et les oprateurs.
- l'interface d'activation et de notifications d ' v n e m e n t s permet une applica-

tion de demander au rseau d'tre averti de l'occurrence de certains vnements. Par
exemple, dans le cas du service de filtrage d ' a p p e l s entrants, il s'agit de lancer l'ins-
tance de service en lui passant le numro de l'appelant.
8.8.3.2. Interface associes aux SCS rseau
Les API associes aux SCS rseaux permettent d'invoquer les fonctions suivantes :
- dclenchement d ' u n appel tlphonique depuis le rseau ;
- interaction avec l'utilisateur final pour la saisie d'information ;
- contrle de session de donnes dans le domaine paquet (par exemple, autoriser
un utilisateur tablir un nouveau contexte PDP) ;
- localisation de l'utilisateur;
- tat du terminal de l'utilisateur et notification l'application lorsque le terminal
change d'tat ;
- rcupration des caractristiques du terminal utilisateur.
8.9. Bibliographie
[3GP 99a| 3GPP, Open Service Architecture (OSI) Application Programming Interface (API)
- Part I. Rapport n TS 29.198, 3GPP, 1999.
|3GP99b| 3GPP, Service aspects; the Virtual Home Environment; Stage I. Rapport n TS
22.121. 3GPP, 1999.
13(iP 99c| 3 ( P I \ Service Requirement l'or the Open Services Access (OSA) Stage I. Rapport
n TS 22.127. 3GPP, 1999.
|3CJP 9 9 D | 3GPP, Virtual Home Environment (VHE) / Open Service Access (OSA) ; Stage 2.
Rapport n TS 23.127, 3GPP, 1999.
|3GP 011 3GPP, Service aspects ; Services and Service Capabilities spcification (Release 99),
Rapport nTS 22.105, 3GPP. 2001.
|3GP 02a 1 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) - stage 2
(Release 4), Rapport nTS 23.078, 3GPP, 2002.
|3GP ()2b| 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) - stage 2
|3GP ()2c| 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) - stage 2
|3GP ()2d| 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) ; CAMEL
application Part (CAP) spcification (Release 4), Rapport nTS 29.078, 3GPP, 2002.
|3GP 02e| 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) : CAMEL
application Part (CAP) spcification (Release 5), Rapport nTS 29.078. 3GPP, 2002.
[3GP 02f] 3GPP. Customized Applications for Mobile Enhanced Mogic (CAMEL) ; CAMEL
application Part (CAP) spcification (Release 99), Rapport nTS 29.078, 3GPP, 2002.
f3GP 02gj 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) ; Service
description stage 1 (Release 4), Rapport nTS 22.078 v4.5.0, 3GPP, 2002.
[3GP 02h] 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) ; Service
description stage 1 (Release 99), Rapport nTS 22.078, 3GPP, 2002.
[ITU 99al ITU-T, Description du plan fonctionnel rparti du jeu de capacits CS-2 du rseau
intelligent, Rapport nQ.1224, 1999.
[ITU 99b 1 ITU-T, Guide utilisateur du rseau intelligent. Rapport nQ.1229, ITU-T, 1999.
[ROS 03] ROSENBERG J., SCHULZRINNE H.. CAMARILLO G . , JOHNSTON A . . PETERSON
J., SPARKS R., HANDLEY M., SCHOOLER E., RFC 3261 SIP : Session Initiation Protocol,
Rapport, IETF, 2003.
| S C H 03] SCHULZRINNE H., CASNER S., FREDERICK R., JACOBSON V., RFC 3550 RTP :
A Transport Protocol for Real-Time Applications, Rapport, IETF, 2003.
[STR 011 STRETCH R. M., The OSA API and other related issues . BT Technology Journal,
vol. 1, 2001.
I
Chapitre 9
Terminal mobile
et environnements d'applications
9.1. Introduction
Alors que la tlphonie (voix) et les systmes de messageries (vocales ou texte)

semblent des techniques matrises et standard, la diffrenciation entre oprateurs
repose maintenant sur le prix des forfaits de communication et l'innovation en
matire d'applications. Ces applications visent faciliter la vie de l'utilisateur ou
lui apporter des loisirs. Leur conception est devenue un march florissant dans le
domaine des organiseurs et tlphones mobiles et, dans un premier temps, de
nombreuses socits ont dvelopp leur plate-forme propritaire.
Une part significative des applications est excute en local sur l'quipement de
l'utilisateur. Le march des terminaux mobiles tant trs ouvert, diffrents groupes
de standardisation se penchent vers la dfinition d'environnement d'application
permettant de tlcharger et d'excuter des applications indpendamment du
terminal utilis et du rseau visit. Ces environnements d'excution pour les
applications doivent permettre l'accs aux ressources du terminal, qui sont pour une
part des ressources communes tous les terminaux et pour une autre part des
ressources utilisant les particularits spcifiques un terminal donn. On peut se
demander dans ces conditions comment un standard peut s'imposer.
Chapitre rdig par Paul JOLIVET.

Par ailleurs, la mobilit et l'itinrance (roaming) apportent leurs aspects

spcifiques aux applications, comme par exemple la possibilit de s'excuter dans
les mmes conditions quelle que soit la localisation de l'utilisateur (et le rseau
utilis, l'tranger par exemple) : c'est l'environnement local virtuel (VHE, Virtual
Home Environment). Mieux encore, la localisation de l'utilisateur peut tre utilise
pour offrir un service adapt.
L'objectif de ce chapitre est de faire un tat des lieux du domaine. Les

diffrentes solutions et leurs aspects standard ou propritaire sont abordes, et les
volutions possibles envisages.
9.2. L'quipement utilisateur en 3G
L'UE (User Equipement) est l'quipement qui donne un utilisateur l'accs un

rseau et ses services ; il inclut ncessairement un ME (Mobile Equipement), et
constitue une extension de la Mobile Station du systme GSM. Les termes dcrivant
les diffrents lments du terminal ont volu, passant du GSM la 3G. La
figure 9.1 donne un aperu gnral des lments d'un terminal 3G.
ME : Mobile Equipment, MT : Mobile Termination,

TE : Terminal Equipment, UE : User Equipment
Figure 9.1. Composantes du mobile 3G

Terminal mobile et environnements 389
L'architecture du terminal de 3e gnration prvoit d'emble la possibilit d'une

sparation de fonctionnalits. L'UMTS, de ce point de vue, est une approche trs
conceptuelle, certaines de ses fonctionnalits pouvant tre rparties dans d'autres
machines, par exemple un organiseur ou un PC portable.
Le tlphone mobile correspond au UE (User Equipment), rduit un ME, et

reste la structure la plus commune.
9.2.1. L *quipement mobile (ME)
9.2.1.1. Rpartitions des fonctions dans l'quipement mobile

Au sein du ME, les fonctions sont rparties comme suit :
- le MT (Mobile Terminal) gre l'interface radio ;
- le TE (Terminal Equipement) contient des applications de bout en bout ; dans
le cadre d'un tlphone mobile, c'est l'entit qui accueille les applications.
Le MT contient l'UICC, la carte puce o sont dtenues les donnes de gestion

de la communication (authentifcation de l'utilisateur, etc.). L'UICC dsigne la carte
au sens hardware et plate-forme 1 . C'est donc un concept qui tend celui de carte
SIM (Subscriber Identity Module).
Au sein du 3GPP, un groupe de travail gre la spcification des fonctions du

terminal (TSG-T 2 ). Pour plus de dtails sur la structure des groupes relatifs la
standardisation des terminaux, voir l'annexe en 9.7.
Comme dans les spcifications GSM, un grand degr de libert

d'implmentation est laiss aux fournisseurs de mobiles. La rgle est la suivante :
- l'Interface Homme Machine (accs aux fonctions, menus, icnes, etc.) reste
propritaire car c'est un moyen essentiel de diffrenciation pour les fabricants ; il
reste en dehors du cadre des spcifications ;
- les interfaces sont incluses dans le cadre des spcifications et dfinies pour
garantir l'interoprabilit ; ce sont par exemple les interfaces avec l'UICC pour la
gestion des donnes de l'utilisateur et de la scurit, le rseau radio et les protocoles
associs, certains priphriques locaux (par exemple Bluetooth ou le lien
infrarouge).
1. A noter que, pour des raisons de scurit, il a t dcid au terme de longues discussions au
sein du 3GPP (UE Functionality Split) que l'UICC ne saurait tre spare du MT. Il est
toutefois possible d'utiliser certaines fonctionnalits de l'UICC depuis l'extrieur du MT.
2. Technical Spcification Group-Terminals.
9.2.1.2. OS, Environnements d'applications et machines virtuelles

Des initiatives ont vu le jour pour dfinir le systme d'exploitation (OS,
Operating System). La plus rpandue est Symbian3, plus rcemment celle de
Microsoft avec Smartphone, un sous-ensemble ddi de Pocket PC, ou encore celle
de Palm.
Un OS, c'est bien entendu tout d'abord la gestion interne du mobile :

- priorit des tches, gestion de la mmoire ;
- support de protocoles de communication ;
- bibliothques (API, Application Programming Interface) de manire donner
aux programmeurs l'accs au support de la scurit (algorithmes, etc.), aux
diffrents codecs multimdia (format d'image, de son), aux ressources du terminal,
etc.
- accs aux ressources intgres au mobile.
A la plupart des OS, il faut galement ajouter, la manire du monde du PC, un

ensemble de fonctions et de services intgrs au rang desquels :
- l'invitable navigateur, qu'il soit Internet, WAP ou i-mode ;
- le support des messageries ; ce peut tre des messageries standards de la 3G
dont SMS (Short Message Services), CBS (Cell Broadcast Service) et MMS
(Multimedia Message Services) ou bien des messageries instantanes (MSN
Messenger, ICQ, Yahoo Messenger, etc.).
Les applications peuvent tre dveloppes directement au-dessus des OS volus

comme Symbian (dans ce cas, en C++), mais il existe galement une autre
approche : celle des Execution Environments. Ils sont le plus souvent bass sur le
principe de la machine virtuelle qui permet une approche haut niveau de la
programmation et l'indpendance par rapport au hardware. C'est typiquement
l'approche Java dont le principe de langage dit interprt permet une programmation
simple et portable sur n'importe quel terminal disposant d'une machine virtuelle.
Symbian [31] offre la fois les approches WAP et Internet standard pour la
navigation comme pour l'email. Le dveloppement est propos soit avec C++, soit
avec Java, sous sa forme standard (J2SE) ou mobile (J2ME). Si Symbian a ses
origines dans le domaine des organiseurs, il s'est entirement tourn vers les
applications de communications mobiles et offre tous les outils de dveloppement
adquats (sonneries, crans de petite taille, gestion des appels tlphoniques, etc).
3. A l'origine Symbian tait un dveloppement de PSION, maintenant c'est un consortium

runissant les plus grands fournisseurs de mobiles.
Figure 9.2. Architecture d'un OS de tlphone mobile
Dans le cas de Smartphone, Microsoft [34] adopte une stratgie de synergie avec
ses autres produits pour les PC et Palmtops. Les messageries, navigateurs et
dcodeurs de contenus sont communs ou au moins bass sur les mmes technologies
mais soumis des limitations lies au mobile, comme le dbit (encodage des MP3
limit 128 kbit/s) ou la taille d'affichage l'cran. On peut en tous cas a priori
faire communiquer les environnements facilement, des options de synchronisation
sont prvues. Les protocoles pour le courrier lectronique (email) par exemple sont
rigoureusement ceux utiliss sur un PC (POP3 ou IMAP). Il existe bien entendu des
fonctions spcifiques au monde des tlphones mobile comme par exemple le
support du chargement de sonneries ou les fonctions de contrle d'appel (call
control).
Il faut enfin noter que ces OS standards, issus du monde des organiseurs, sont
plus particulirement utiliss sur les tlphones haut de gamme intgrant des
fonctions d'organiseurs.
On doit diffrencier deux types de ressources au sein d'un mobile : celles qui
sont comprises de fait sur l'ensemble des terminaux mobiles du march et celles qui
font la diffrenciation pour les fournisseurs de mobiles. Le premier type est
constitu par :
- d e s ressources standard, comme l'accs au rseau, mais galement aux
messageries texte ou multimdia (SMS, CBS et MMS) ;
- des ressources classiques, comme la mmoire ou la capacit de traitement.
Parmi les ressources diffrenciantes , on peut citer :

- l'cran (variable en taille et en nombre de couleurs) ;
- l'accs des interfaces locales (Bluetooth, IrDA, etc.) ;
- d e s priphriques intgrs (appareil photo, second lecteur de cartes puce
etc.) ;
- des ressources ddies l'acclration de certains calculs (pour Java ou encore
pour l'affichage de graphiques).
Plus que dans le monde des ordinateurs, les OS de tlphones mobiles doivent
s'adapter et fournir des bibliothques spcialises, modulaires et tlchargeables
pour des terminaux qui ont la fois des fonctions communes mais aussi des
diffrences faire valoir.
9.2.2. La carte puce (UICC) et ses applications
Comme pour le GSM, la carte puce est partie intgrante des spcifications en
3G pour ce qui concerne le ct terminal utilisateur. La carte volue en taille avec
un format supplmentaire plus petit, dit mini UICC [9]. Elle contient plus de
mmoire: de 8 ko au dbut des annes 1990 on passe 256 ko fin 2004. Elle
propose enfin de nouvelles possibilits comme, par exemple, la gestion de plusieurs
applications) (voir figure 9.3).
ID-000
ID-1 Mini UICC
plug-in
Figure 9.3. Formats standards de l'UICC
L'innovation majeure de la 3G rside dans une architecture qui permet le support

de plusieurs applications.
9.2.2.1. L 'architecture d'une UICC

L'UICC est la fois le matriel (carte puce) et la plate-forme logicielle qui y
est intgre. Elle est multi-applicative, en ceci qu'elle permet le stockage de
plusieurs applications, mais galement qu'elle supporte l'excution simultane de
plusieurs de ces applications.
Cela a d'autant plus de sens dans le domaine des tlcommunications que

l'application USIM doit fonctionner en permanence pour assurer la continuit du service.
Par consquent n'importe quelle autre application doit pouvoir tre excute en parallle.
Figure 9.4. Architecture d'une carte puce, les diffrents niveaux d'application
La figure 9.4 reprsente une architecture possible de carte multi-applicative. On

note que SIM et USIM sont des applications part entire, dites de premier niveau.
Il faut noter qu'il existe des applications de deuxime niveau 4 , reposant sur une
application de premier niveau et utilisant leurs ressources. Ces dernires ne sont pas
considres comme des applications vues du systme d'exploitation (en termes
d'adressage). Les spcifications font la diffrence entre ces deux niveaux
d'applications. Les caractristiques de base de l'UICC sont dcrites dans la
spcification technique TS 31.101 [9].
L'ISO 5 [19] dfinit le fonctionnement d'une carte multi-applicative. L'outil

principal d'adressage des applications est un systme de canaux logiques, tablis par
4. Les applets Toolkit, par exemple.

5. Spcifications de la srie ISO-IEC 7816, plus particulirement 7816-4 dans le cas prsent.
le systme d'exploitation pour adresser les commandes qui lui sont destines une
application donne. Ils sont actuellement au nombre de 4 mais doivent tre ports
20 court terme. Ds lors, 20 applications (de premier niveau) pourront tre
excutes en parallle sur la carte.
9.2.2.2. Plusieurs applications sur une UICC

Une application SIM peut tre intgre l'UICC ou, dans un certain cadre,
simule par une USIM. Cela permet :
- des oprateurs 3G n'ayant pas dploy de rseau GSM d'offrir, en accord
avec un oprateur GSM, l'itinrance sur ce systme ;
- aux oprateurs GSM de proposer des cartes compatibles 3G en prvision d'un
futur rseau ou fins d'itinrance dans des rseaux 3G.
Un des besoins identifis pour la 3G est celui pour l'UICC de pouvoir contenir
plusieurs USIM. Il est en ralit restreint par la mention dans les recommandations
qu'une seule USIM ne peut tre active un moment donn. Toutefois, l'UICC a t
conue pour ne pas tre ddie aux tlcommunications mais comme une plate-
forme capable de supporter d'autres applications, comme par exemple, des
applications bancaire, de porte-monnaie lectronique, de transport, etc.
Au sein mme du domaine des tlcommunications, plusieurs applications ont

t dfinies (ou pourraient voir le jour) : l'USIM, bien sr, mais aussi l'ISIM pour
les rseaux IP multimdias et l'EAP pour l'accs aux rseaux Wi-Fi.
L'USIM permet de personnaliser le terminal mobile un utilisateur en apportant

toutes les donnes lies son abonnement et en donnant l'accs aux services
auxquels l'utilisateur a souscrit. Elle dispose de trois fonctions de base :
- les fonctions de scurit (identification de l'utilisateur par prsentation de code
PIN (Personal Identification Number), authentification dans le rseau, gnration de
cls de chiffrement par l'excution d'algorithmes sur la carte) ;
- l a gestion de donnes administratives du rseau (stockage d'identits,
mmorisation de donnes de localisation et d'informations sur l'environnement,
services parmi lesquels le USIM Lock6 ou encore la restriction d'appels sortants) ;
- le stockage de donnes utilisateur comme son annuaire, son profil, etc.
6. USIM Lock (quivalent au SIM Lock du GSM) est le service qui permet au mobile
d'identifier une carte (ou un groupe de cartes) et de ne fonctionner qu'avec elle(s). Ce service
est particulirement utilis par les oprateurs qui subventionnent l'achat des terminaux et ne
souhaitent pas voir ces derniers utiliss sur un rseau concurrent. La fonctionnalit est en fait
supporte par le mobile, la carte ne contenant que des donnes d'identification.
L'ISIM 7 [11] est l'quivalent d'une USIM pour un rseau IP multimdia. ISIM a
t spcifie au 3GPP comme une application indpendante pour le cas de
terminaux ddis uniquement ce type de rseau. Toutefois, les oprateurs de
rseaux mobiles s'opposent actuellement vivement une telle approche qui
permettrait dans le futur des oprateurs offrant uniquement des services IP de
profiter de leur rseau d'accs radio.
L'EAP (Extensible Authentication Protocol) pour UICC [18] (et sa dclinaison

3G : EAP AKA (Authentication Key Agreement) [21] permet un terminal Wi-Fi
d'offrir des services d'authentification renforcs, bass sur les algorithmes 2G ou
3G prsents sur la carte. Cela est particulirement intressant pour des oprateurs
offrant la fois des services de tlphonie et des hotspots 8 .
9.2.2.3. OS, environnements applicatifs et API

Dans le domaine des cartes puces, il n'y a pas de systme d'exploitation
standard. Pour des raisons historiques et d'optimisation, les fournisseurs de cartes
sont responsables de la conception de leur OS. Il faut noter quelques tentatives, par
exemple celle de Microsoft avec Windows for Smart Card qui restent des checs
cuisants, la plupart n'ayant pas mme atteint le niveau de prototypes.
Les environnements d'applications voient pour leur part un dveloppement

important li au succs du SAT (SIM Application Toolkit) [8] dans le systme GSM.
La carte, jusqu'alors esclave du terminal mobile, devient un lment proactif,
capable d'envoyer des commandes pour provoquer des affichages, rcuprer des
informations ou encore changer des donnes au travers du terminal mobile. Cet
environnement fort de son succs est port en troisime gnration sous le nom
d'USAT, USIM Application Toolkit [12]. Il est constitu d'un jeu de 34 commandes
optionnelles. Ces commandes, en conjugaison avec un environnement applicatif,
permettent de construire des applications.
9.2.3. Le rapport de force terminal-carte
On assiste souvent une relation de force surprenante entre partisans de la carte

et ceux du terminal quant au support des applications. Un point important qui joue
en faveur de la carte est le fait de rester proprit de l'oprateur qui en connat a
priori ses caractristiques. Ce n'est pas la cas du terminal mobile, que l'utilisateur
peut changer tout moment.
7. IMS SIM (avec IMS pour IP Multimedia Subsystem).

8. Point d'accs un service 802.11 (Wi-Fi par exemple - 802.1 lb).
Il faut tout de mme reconnatre que si la carte a des avantages propres

indniables (voir tableau 9.1) ses capacits resteront de fait toujours en retrait de
celles du terminal.
Mobile Carte Commentaire

L'volution des processeurs bnficie de la mme faon aux
Process * terminaux et aux cartes. La contrainte de taille des
processeurs carte fait que la carte restera en arrire.
Le mobile gardera toujours une grande avance en termes de
capacit mmoire, ne serait-ce que par sa taille. Pour l'ordre
Capacit * d'ide, un mobile en 2004 a une capacit de l'ordre d'un
mmoire quelques Mo, alors que les cartes UICC les plus importantes
disposent de 64 ko de mmoire disponibles pour les
applications et fichiers de l'utilisateur.
L'utilisateur peut retrouver ses donnes personnelles, son
Portabilit * profil, son abonnement dans n'importe quel terminal 3G en
y insrant sa carte
La carte puce bnficie d'une structure hardware
indpendante et scurise qui permet de raliser des calculs
Scurit *
en local sans que les donnes utilises puissent tre
accessibles de l'extrieur.
Tableau 9.1. Mobiles et cartes, avantages croiss
Il est clair par contre qu'il est intressant de jouer des avantages des deux partis
pour construire les meilleures applications.
9.3. Environnements propritaires - environnements standards
Standardiser un environnement applicatif, c'est permettre le dveloppement

d'applications indpendamment de la plate-forme matrielle sur laquelle elles
seront excutes. La conception d'applications devient plus simple et moins
coteuse.
Toutefois, si les ressources et priphriques de base sont bien les mmes pour la
trs grande majorit des tlphones, il existe des diffrences significatives entre les
diffrentes interfaces homme-machine ; de plus, les ressources spcifiques des
terminaux ne sont pas standards. Certains fournisseurs de mobiles cherchent ainsi
se diffrencier en proposant des appareils qui optimisent l'affichage 3D ou encore
certains types de calculs pour favoriser certaines applications. Comment ds lors
passer un standard ?
Quelques industriels ou groupes de standardisation (eux-mmes gnralement

dans F industrie) travaillent pourtant sur la dfinition de certains aspects parmi
lesquels :
- Open Mobile Alliance (ex-fVAP Forum) [29] protocoles, navigateur et
environnement applicatifs ;
- 3GPP [23]/3GPP2 [24] pour les aspects lis au rseau coeur et radio ;
- GSM Association [26] pour le niveau service et application.
9.3.1. Diffrentes ressources pour diffrentes applications
Chaque mobile dispose d'un ensemble de ressources auxquelles un programmeur

doit pouvoir accder dans la conception d'une application. Ces ressources incluent :
- l'accs aux mdias de communication/services de base, normalement standard
(mme s'il existe des classes pour certains services comme par exemple le GPRS) ;
- l'accs aux priphriques de base dont certaines fonctionnalits peuvent
tre facilement standard contrairement certaines, plus spcifiques : le clavier, et
l'affichage de texte et d'images sont le plus souvent standardisables ; en revanche, la
gestion de graphismes 3D (principalement dans le cas des jeux) est typiquement un
domaine dans lequel il est dlicat de dvelopper un standard ;
- l'accs des fonctions de cryptographie.
9.3.2. Les diffrents environnements
Au moment de l'arrive de la 3G, il existe trois environnements prpondrants 9

au milieu d'implmentations propritaires :
- Java sous plusieurs formes, J2SE {Java 2 Standard Edition) qui correspond
l'dition PC, adapte des mobiles-organiseurs (PDA), J2ME (Java 2 Micro
Edition) qui est une adaptation de J2SE aux terminaux de petite taille, aussi
couramment appele KVM, et enfin Java Card qui est un sous-ensemble de J2SE
adapt la carte puce ;
- WAP avec WAE (Wireless Application Environment) ;
- Symbian, qui offre au-dessus de l'OS un ensemble de librairies pour la
programmation en C++ (dans certains cas en Java), plus particulirement pour les
mobiles dots de fonctions organiseurs (PDA) ; notons que Microsoft a la mme
approche avec Smartphone.
9. Les deux premiers sont d'ailleurs rfrencs dans les spcifications 3GPP.
I
Tous ces environnements offrent une plate-forme d'excution d'applications et

des APIs pour l'accs aux fonctionnalits du mobile. Les dveloppeurs
d'applications peuvent donc concevoir un seul code quel que soit le mobile sur
lequel le programme sera excut. Dans certains cas, ils pourront mme disposer
d'un seul excutable quelle que soit la plate-forme.
9.3.2.1. Java
Si Java est une initiative de Sun Microsystems [37], son dveloppement dans le
domaine des tlcommunications relve en fait de forums ; dans le cas de J2ME,
c'est le Java Community Process [28] ; dans le cas de Java Card, c'est le Java Card
Forum [27]. Les membres de ces forums font des propositions (JSR, Java
Spcification Requests) qui sont examines par un groupe d'experts (Expert Group)
puis proposes en relecture publique avant de devenir un standard.
J2SE
J2ME
Figure 9.5. Java de l'dition standard aux versions mobile et carte
Le principe d'origine est de n'crire une application qu'une seule fois et de

pouvoir l'excuter sur n'importe quelle plate-forme compatible. Le choix technique
de l'interprteur a volu puisque le code est maintenant optimis avant
interprtation sur une machine virtuelle. Il est bon de noter ce sujet que
l'interoprabilit du code source optimis n'est pas toujours garantie, des travaux
sont en cours sur le sujet.
J2ME est bas sur une machine virtuelle qui s'adapte au systme d'exploitation
et a une structure de profil et de configuration :
-profil qui correspond une famille de terminaux aux caractristiques
communes, c'est le MIDP (Mobile Information Device Profile) ;
- configuration qui dfinit une plate-forme minimale en termes de services pour
un profil donn. La configuration adapte au domaine des tlphones mobiles est
CLDC (Connected Limited Device Configuration).
Il faut noter que les implmentations actuelles de J2ME restent incompatibles

entre elles, chaque fournisseur de mobile ayant des extensions propritaires. Il
existes deux tentatives de nivellement, celle, standard, de Java Community Process
avec MIDP 2 et celle, propritaire, de DoCoMo avec DoJa.
Le premier environnement d'applications standard avoir t spcifi pour la

carte fut Java Card, un sous-ensemble de Java dot d'API carte (pour grer les
commandes et vnements spcifiques la carte puce) et d'API spcifiques aux
diffrentes applications, VISA pour les applications bancaires ou SIM pour le
GSM puis UICC/USIM en 3G. Cet environnement permet le dveloppement
d'applets sur des cartes puce. Les applications actuelles sont nombreuses dans le
domaine GSM.
9.3.2.2. Symbian
Symbian donne aux dveloppeurs l'accs des API pour concevoir des
applications (typiquement sur l'architecture dcrite en figure 9.2. Un ensemble
d'API est accessible aussi bien depuis une application dveloppe en C++ (qui
tournera de manire optimise sur le terminal), que sur une machine virtuelle Java,
incluse dans l'architecture. Cette combinaison est certainement un avantage pour les
dveloppeurs qui peuvent selon les besoins choisir une solution ou l'autre.
Le support des protocoles de communication est trs important dans la version 7,

avec :
- la trs grande majorit des protocoles de l'Internet, WAP, USB, mdias locaux
(Bluetooth, IrDA, etc.) ;
- de nombreuses technologies de tlphonie (GSM, GPRS, CDMA2000, etc.).
9.3.2.3. WAE
Le Wireless Application Environment (WAE) s'inscrit dans une volont du WAP
Forumw de crer une architecture standard, base sur les protocoles WAP, sur
laquelle peuvent tre dvelopps des services. La seconde version des spcifications
se rapproche singulirement des standards de l'Internet alors que la premire les
adaptait, sous prtexte de ressources limites dans le cas de la 2G (principalement le
GSM).
WAE est maintenant essentiellement bas sur une srie de ressources qu'il
rfrence :
- XHTML mais aussi pour des raisons historiques WML ;
- SyncML pour la synchronisation (voir paragraphe 9.5.2) ;
- une srie de formats supports comme des formats de contenus (audio, images,
etc.), eCard, eCalendar etc. ;
- WML Script, qui est un sous-ensemble de ECMA Script.
9.3.2.4. Autres environnements

Les environnements applicatifs propritaires tendent disparatre actuellement,
d'autant plus que l'offre de terminaux est trs diversifie. L'absence de standard
condamnerait le monde des fournisseurs de services des dveloppements coteux.
On peut tout de mme mentionner dans le domaine de la carte puce une

tentative de concurrence Java Card. Des difficults dans le processus de
standardisation et une confortable avance de Java Card dans le domaine ont amen
deux concurrents (Multos et Microsoft) se rapprocher pour dcrire une API
commune base sur le langage C : C Bindings for SIM API. La spcification a t
approuve courant 2002 pour la Release 6 des spcifications 3G.
9.3.3. Interfonctionnement des environnements
Il n'est pas exclu que plusieurs environnements coexistent au sein d'un terminal.
Chaque application base sur un environnement peut exploiter ses avantages. Le cas
le plus intressant est celui d'applications rsidant sur l'UICC communiquant avec
des applications rsidant sur le mobile.
Le dveloppement d'applications partages permet de bnficier des avantages

de chaque lment. Dans la plupart des systmes, l'un des lments est considr
10. Dont le nom a chang pour Open Mobile Alliance.

comme matre ; il accde aux autres ressources comme des esclaves, cette relation
tant fige. Toutefois, ces systmes ne sont pas incompatibles entre eux et il n'est
pas exclu, en utilisant tantt l'une, tantt l'autre, d'tablir une communication dans
tous les sens. Plusieurs solutions permettent une application dveloppe dans un
domaine d'interagir avec une application ou des ressources de l'autre domaine.
9.3.3.1. Cas o le mobile a l'initiative

Cette approche (centre sur le mobile) est celle choisie au sein du Java
Community Process dans le cadre de la spcification JSR 177 11 . Il s'agit pour une
application du terminal de pouvoir dclencher l'excution d'une application dans la
carte. Ce type d'accs permet d'envisager l'utilisation d'une application ddie au
paiement qui rsiderait sur la carte depuis une application rsidant dans le mobile
(jeu, achat, loterie, etc.). SIM Alliance [30] a galement travaill sur une application
qui gre sur l'UICC les droits d'excution d'une autre application, base elle sur le
terminal. Cela permet de grer facilement diffrents niveaux d'accs une mme
application (par exemple : dmo, utilisation partielle ou temporaire, utilisation
complte). Le contrle tant fait au sein de la carte, la licence est relative
l'utilisateur, et non au terminal comme d'autres systmes de gestion de droits
oprants.
Le JSR 177 est orient sur les aspects scurit et n'est pas strictement li des
applications Java Card ct carte puce. La spcification dfinit un ensemble d'API
utilisables par des applications dveloppes sur une plate-forme J2ME dans le
mobile.
Figure 9.6. Le mobile garde l'initiative de l'accs des priphriques (dont la carte)
11. Pour plus d'informations sur ces spcifications, visiter le site de SUN Microsystems,
http://jcp.org/en/jsr/detail?id=177
Le mme type d'approche est utilise dans le cadre du WAP Forum pour le
dveloppement de EFI (External Function Interface), donne l'accs des lments
extrieurs au mobile, dont la carte, comme des priphriques. Le mobile gre ces
accs depuis le navigateur ou l'environnement applicatif dfinit par WAP, WAE.
L'EFl se prsente galement comme un ensemble de librairies dcrites en

WMLScript qui permettent de dfinir un ensemble de services qui peuvent tre
tendus de manire propritaire en fonctions des priphriques disponibles.
9.3.3.2. Cas o la carte a l'initiative

La situation inverse trouve aussi des utilisations : la carte puce va dclencher
l'utilisation d'applications situes sur d'autres supports, dans le mobile mme ou par
exemple dans une autre carte puce. Les exemples d'implmentation aujourd'hui
sont bass sur l'accs un second lecteur de carte (pour des mobiles bi-slot). Des
applications de paiement par carte bancaire en France 12 et de rechargement de porte-
monnaie lectronique au Royaume-Uni 13 sont bases sur ce principe.
Figure 9.7. Principe de fonctionnement dans le cas USAT matre
L'application utilise dans ces cas des commandes (U)SAT qui lui permettent de
solliciter des ressources extrieures. C'est le cas de l'application iti-Achat qui repose
sur un schma prsent la figure 9.8.
12. L'exprience iti-Achat de Orange France (Itinris ce moment l).

13. Pilotes mens avec les porte-monnaie Mondex.
Tout d'abord, l'application SAT rsidant sur la SIM est dclenche par
l'arrive d'un message court qui inclut une somme payer O. Elle interagit avec
le mobile pour afficher des messages et demander confirmation du paiement
l'utilisateur Elle dclenche ensuite l'application de paiement sur une carte
bleue insre dans la seconde fente du mobile
L'application de paiement (dbit) de la carte bleue prend alors le relais : elle

reoit la demande de paiement, et effectue une procdure de paiement identique
celle effectue dans un terminal sur point de vente (autorisation par
prsentation de code PIN puis relation avec le serveur carte bancaires) O. Elle
retourne enfin l'application (U)SAT un rsum de l'opration (numro de
transaction, etc.) . L'application (U)SAT affiche enfin le rsultat de
l'opration.
Figure 9.8. Une application de paiement - principe
L'(U)SAT permet d'accder des ressources extrieures la carte, parmi

lesquelles :
- diffrents modules du terminal (cran, clavier, etc.) ;
- d e s supports de communication via le Bearer Independent Protocol, pour
changer des donnes (voir paragraphe 9.5.5.2) ;
- des priphriques extrieurs du type carte supplmentaire.
Une application rsidant sur la carte peut ainsi communiquer et interagir avec
l'extrieur. Nanmoins, il n'existe pas encore de possibilit pour une application
rsidant sur la carte de dclencher une application du mobile.
9.3.4. Les services d'Internet Mobile
L'application maintenant incontournable des tlphones mobiles est l'accs aux

ressources de bases de l'Internet : la navigation et l'email. Deux approches se sont
diffrencies dans l'implmentation de ces ressources :
- c e l l e qui part de l'hypothse que le terminal mobile a peu de ressources de
calcul et un mdium de communication faible ; cette approche suppose donc
l'adaptation des protocoles et des contenus, c'est WAP jusqu' la version 1.2.1 ;
- c e l l e qui donne l'accs la grande partie de l'Internet, soit en offrant un accs
complet (approche des tlphones organiseurs en GSM), soit en offrant en plus des
fonctionnalits lies la tlphonie, c'est i-mode.
La 3e gnration rendant la premire hypothse quasiment caduque, voit la

convergence de WAP vl et de l'i-mode avec WAP v2. A noter que, paralllement,
la plupart des mobiles GSM haut de gamme supportent dj la fois WAP v 1.2.1 et
Internet.
WAP vl.x Internet WAP v2
Figure 9.9. Evolution de l'architecture des protocoles WAP
Exploitant le laps de temps ncessaire aux fournisseurs de mobiles pour

approvisionner le march en produits supportant des navigateurs WAP, des
extensions de F USAT voient galement le jour pour permettre l'accs des
contenus WML sur la base de terminaux non dots de navigateurs.
Le principe repose sur l'utilisation d'une passerelle de traduction du WML vers

un script comprhensible par la carte et d'un systme de navigation par menus.
Cette approche a d'abord t propritaire (Wireless Internet Browser), puis

reprise par un consortium de fournisseurs de cartes puce puis finalement propose
comme un standard 3GPP : /'USATInterpreter [13].
requte requte
Interprtation
contenu
Rponse WML Rponse traduite
Figure 9.10. Principe du mini-navigateur sur une UICC
9.3.5. L 'approche standard des environnements existants
Au sein du 3GPP, une initiative de standardisation d'environnements applicatifs

est mise en route (ds la seconde gnration), c'est MExE [2] (Mobile EXecution
Environment). Cette activit a toutefois t arrte dbut 2002 pour tre en partie
prise en charge par un autre forum : Open Mobile Alliance.
L'objectif de MExE tait d'offrir un environnement standard du point de vue des

services en rfrenant un ensemble d'environnements remplissant ou s'engageant
remplir un ensemble minimal de fonctions et par l'ajout de librairies (API).
Figure 9.11. Principe de l'adaptation des services d'une Classmark

aux besoins dfinis par MExE
MExE dfinissait galement un environnement de service. En revanche, on n'y

trouvait pas de liste minimale de fonctionnalits supportes par le terminal. MExE
tait bas sur un ensemble de fonctionnalits de base parmi lesquelles la possibilit
pour l'utilisateur de contrler l'interface des applications et l'accs aux ressources

de communication, en particulier pour l'accs des ressources factures. MExE
permettait galement pour le fournisseur de service de facturer l'utilisation ou le
chargement d'une application et offrait la possibilit d'accder des ressources de
scurit (certification, authentification, etc.).
Parmi les fonctionnalits additionnelles, on peut noter :

- un systme de ngociation de fonctionnalits (dcouverte des services, etc.) en
dbut et en cours de session ;
- une liste de classes (classmarks) qui permettent lors de la phase de ngociation
d'identifier l'environnement applicatif utilis : WAP, WAE, J2SE, J2ME, Microsoft
CLI galement connu sous le nom ISO CLI ;
- d e s ressources de tlchargement, lesquelles faisaient l'origine partie des
objectifs de MExE mais n'ont jamais t spcifies.
Si l'exprience MExE s'est arrte sans que des implmentations aient vu le

jour, elle a permis d'identifier les briques des packs de service comme m-services ou
Vodafone Live ! .
9.3.6. L 'approche offre de services en packages
Devant le dmarrage laborieux des tlphones WAP, une initiative est prise au
sein de la GSM Association pour dfinir un ensemble de fonctions minimales pour
supporter l'Internet mobile. C'est la notion de m-services 14 . L'approche est la mme
que celle qui avait amen le japonais NTT DoCoMo [35] proposer i-mode. Ce
systme est bas sur la spcification par l'oprateur d'un jeu de fonctionnalits pour
le mobile, d'une partie de son interface homme-machine et du support d'un
navigateur et d'un environnement applicatif, en l'occurrence, DoJa (DoCoMo Java).
L'environnement de m-services comprend :

- u n ensemble de fonctions du mobile (raccourcis clavier, soft keys, taille
minimale de l'cran, etc.) ;
- des protocoles supports par le terminal (principalement des rfrences aux
protocoles WAP et des mark-up languages Internet) ;
- une machine virtuelle pour l'excution d'applications ;
- le tlchargement d'application et de donnes en gnral ;
- des niveaux de scurit.
14. Le groupe de travail consacr au sujet est le MSIG (M-Services Interest Group).
L'initiative n'a donn que peu de rsultats sur le march, encore qu'on peut
considrer que certaines offres multimdia en 2003 sont fortement inspires de cette
approche. Une seconde phase est en cours d'laboration, oriente clairement vers la 3G.
9.4. Virtual Home Environment
Le projet VHE ( Virtual Home Environment) [3 et 4] a vu le jour dans les

spcifications GSM mais aucune implmentation n'en a t faite. Le concept repose
sur la possibilit pour un utilisateur de disposer du mme environnement (renvois,
numros courts, services, langage, etc.) sur son tlphone, qu'il soit dans son rseau
nominal ou en itinrance.
Dans le cadre de VHE est dfini un profil d'utilisateur (comprenant des

prfrences et des paramtres) qui peut tre modifi par accs direct aux donnes
mais galement de faon dynamique en cours d'utilisation d'un service.
Les mcanismes devant supporter le concept de VHE sont au sein du 3GPP :

CAMEL (Customised Applications for Mobile network Enhanced Logic, le rseau
intelligent dans les rseaux mobiles), MExE, OSA (Open Service Access), et USAT
(l'environnement applicatif standard de la carte UICC).
Pour chaque utilisateur, VHE repose sur une combinaison de services, de

prfrences et de configurations (terminal et services).
Le choix d'OSA rside dans le besoin de disposer d'un environnement de

services flexible susceptible de supporter des applications et services non encore
identifis. OSA fournit cette interface extensible et adaptable. Les API sont conues
comme indpendantes des solutions sur le march et des langages de
programmation. Ces API doivent permettre de construire les mmes services
indpendamment de la localisation de l'utilisateur.
OSA est construit autour de trois lments :

- des applications ;
- u n e structure qui comprend l'accs aux services de base que les applications
peuvent utiliser et qui sont construites sur diffrentes technologies (CAMEL, MExE,
USAT) ;
- des serveurs de fonctionnalit de base , chaque fonctionnalit pouvant
exister sur plusieurs serveur, selon les ressources disponibles.
Un ensemble de mcanismes de base entre les applications et la structure mme

d'OSA sont appliqus avant mme que le service ne soit offert l'utilisateur :
authentification, autorisation, dcouverte des fonctions disponibles et accs au
service.
La mise en place d'un rel environnement virtuel est une volont vidente des
oprateurs, d'autant plus que beaucoup d'entre eux ont une politique de groupe.
Toutefois, le concept de VHE a t abouti bien avant OSA et le besoin pressant
favorise l'mergence de solutions propritaires de la part des grands groupes.
9.5. Le tlchargement
Peu d'applications sont destines un usage purement local au mobile, la plupart

existent pour tre connectes soit directement un serveur d'information, soit des
priphriques, par exemple organiseur ou autre tlphone mobile. Par ailleurs, de
nouvelles applications sont disponibles quotidiennement et les applications
existantes ncessitent parfois des mises jour.
La nature mobile de ces terminaux fait du tlchargement d'informations ou

d'applications un complment indispensable un environnement applicatif. Le
besoin a t ressenti relativement tt dans l'histoire du GSM et les solutions
apportes ont t dans un premier temps bases sur des mdias de transmission peu
adapts aux donnes (le SMS en particulier), puis sur des mdias plus efficaces ou
spcialement adapts. La 3G arrive au moment o de nombreux mdias de
transmission sont disponibles, via le rseau ou en local.
9.5.1. Les applications du tlchargement
Le march des organiseurs lectroniques (PDA, Personal Digital Assistant) a

dj provoqu de srieux travaux sur la mise jour d'informations, la requte
d'information ou mme le tlchargement d'applications sur des terminaux mobiles.
Chaque fabricant a mis en place un systme de synchronisation des donnes qui

permet le chargement d'applications. On peut citer pour mmoire HotSync pour le
Palm OS [36] ou ActiveSync pour Microsoft. Dans le cas gnral, les
donnes/applications sont charges partir d'un PC connect via une station (ou un
port Infrarouge) sur lequel on les a au pralable installes. On trouve galement la
possibilit de raliser le chargement au travers d'un PC et d'une connexion Internet
vers un serveur distant.
Par ailleurs, plusieurs fournisseurs de services sont connus dans le domaine des
PDA. Le principe rside dans l'utilisation du procd de synchronisation de
l'organiseur (par exemple HotSync pour les Palm OS) et d'un navigateur
gnralement propritaire. AvantGo [33] est la solution la plus connue sur le march.
Il s'agit de consulter des contenus mis jour localement dans l'organiseur,
opposer un navigateur WAP ou Internet qui va chercher le contenu au fur et
mesure de la navigation. Les services sont typiquement le chargement de nouvelles
(magazines) ou bien de livres lectroniques. De la mme manire, on peut
tlcharger des applications. Une extension de ce systme consiste utiliser l'accs
direct un rseau de tlcommunications et s'affranchir de la liaison de
synchronisation. C'est le cas pour des terminaux dots d'un module GPRS, Wi-Fi
ou Bluetooth.
Au-del de ces applications, les industriels se posent la question du

tlchargement de codecs sur des terminaux disposant des capacits hardware les
supporter. L'intrt serait alors d'offrir l'itinrance vers des rseaux aux protocoles
d'accs diffrents ou de mettre jour les protocoles de communication avec le
rseau.
9.5.2. Synchronisation
La multiplication des terminaux (et de l'information sur les terminaux) force

traiter le problme de la synchronisation. L'utilisateur est typiquement demandeur
d'une synchronisation de ses contacts entre son PC (sur lequel gnralement il reoit
ses emails), son organiseur (qu'il utilise pendant ses dplacements pour consulter
contacts et rendez-vous) et son tlphone.
L'initiative la plus connue dans le domaine de la synchronisation est SyncML.

SyncML est un standard rfrenc par le 3GPP et OMA (Open Mobile Alliance) qui
dfinit un langage et un protocole de synchronisation entre terminaux. SyncML,
bas sur les couches Internet et WAP, est la solution la plus ouverte actuellement.
Ce protocole se prsente comme une couche applicative reposant sur les couches
standard existantes, principalement http.
Il existe galement des solutions propritaires dveloppes par les fournisseurs

d'organiseurs lectroniques, lesquelles ont tendance converger vers la solution
SyncML.
en local distance
Figure 9.12. Les diffrents terminaux et la synchronisation
9.5.3. Fonctionnalits lies au tlchargement d'applications
Un ensemble de fonctionnalits de base doit tre spcifi pour faire du

tlchargement de donnes ou d'applications :
- un accs au serveur et une authentification ventuelle ;
- d e s fonctions de scurit comme le chiffrement/dchiffrement ventuel de
contenu, la certification du contenu ;
- la reconnaissance du contenu et un lien vers une application d'installation ;
- la gestion d'application distance : excution distance d'application,
dclenchement d'applications sur vnement, gestion de versions, compte-rendu
d'installation depuis le serveur, effacement d'applications.
Un point cl de la scurisation des systmes de tlchargement d'applications

reste la certification des applications disponibles. Cette fonctionnalit est cruciale
pour les oprateurs qui souvent garantissent les donnes, mais surtout pourraient
souffrir du piratage des terminaux. Deux approches existent dans le domaine : une
approche centralise autour d'une autorit de certification (souvent associe un
seul serveur chez l'oprateur) et une approche distribue avec diffrentes autorits
de certification, reconnues par l'oprateur.
Figure 9.13. Les schmas de certification d'une application
Le schma centr sur l'oprateur reste celui le plus rencontr en deuxime

gnration. En 3G par contre, il est possible que l'autre schma s'impose,
correspondant une architecture typiquement rencontre sur Internet, l'architecture
de ces rseaux ayant tendance converger vers une unique solution.
Un autre point capital des systmes de tlchargement est la possibilit de grer

les applications distance. Cela permet de mettre jour des applications dj
tlcharges, d'viter de tenter le tlchargement d'une application dj prsente sur
le terminal. Cela permet galement de vrifier la bonne installation d'une
application tlcharge.
9.5.4. Environnements applicatifs et tlchargement
Les environnements applicatifs sont pour la plupart dots d'origine de mcanismes

de tlchargement ou au moins de recommandations sur ces mcanismes.
Java dispose de recommandations sur les fonctionnalits du tlchargement

d'applications. Dans le cadre de l'dition mobile (J2ME), une spcification
(JSR 124), prsente dans MIDP vl, dfinit l'architecture gnrique permettant le
tlchargement. Le tlchargement est d'abord spcifi entre entit Java mais des
extensions (recommended practises) existent pour le cas de plates-formes WAP par
exemple. En ce qui concerne Java Card, le tlchargement d'informations ou
d'applications peut se faire sur deux canaux : le SMS d'un ct et le Bearer
Independent Protocol de l'autre (voir paragraphe 9.5.5).
OMA dveloppe pour sa part un protocole de tlchargement qui a pour objectif

l'indpendance de plate-forme logicielle. Le systme est essentiellement bas sur
http mais ajoute galement quelques fonctionnalits de ngociation sur le format de
contenu et de confirmation de rception et d'installation. Cette spcification couvre
les implmentations Internet et Java.
9.5.5. Supports de communication du rseau 3G
Les tlphones mobiles supportent de plus en plus de moyens de communication

diffrents. Ceux-ci peuvent tre classs en deux catgories, selon qu'ils sont des mdias :
- locaux, change d'information entre deux terminaux proche l'un de l'autre, par
exemple, le lien infrarouge, Bluetooth, etc. ;
-rseau, utilisation d'un rseau de communication pour connecter deux
terminaux distants, par exemple, GPRS, Wi-Fi, etc.
9.5.5.1. Supports de communication

Un grand nombre d'applications visent galement interagir avec des terminaux
locaux, c'est--dire sans utiliser le rseau de l'oprateur. Elles sont bases sur
l'utilisation de supports de communication courte distance avec une porte de
quelques mtres au plus. Les applications vont de la synchronisation de donnes
entre terminaux l'accs des terminaux de point de vente pour le paiement en
boutique ou bien l'accs aux transports.
D'autres applications ont vocation interagir avec un serveur distant, les

informations transitent alors sur le rseau de l'oprateur (ou d'un oprateur ayant
des accords de roaming).
Les principaux systmes sont consigns dans le tableau 9.2. Ces supports de
communication sont utilisables par les applications rsidentes sur le terminal par
l'utilisation d'API spcifiques. Cependant, la multiplicit des implmentations dans
certains cas conduisent choisir des solutions dont les spcifications sont le rsultat
du travail d'un forum ou d'un consortium. Ainsi Bluetooth ou les lecteurs de carte
interne ont un avenir plus probable que la connexion infrarouge. Effectivement, dans
ce dernier cas, si les couches basses sont bien spcifies, les couches applicatives
sont restes propritaires.
Systme Support Dbit Origine Type d'applications

supports de communication en local
Lien vers un PC
Lien vers des priphriques
Bluetooth Radio 720 kbit/s Industrie
divers (camra, photo...)
Lien vers un PDA
Carte sans
Radio 424 kbit/s ISO Transport
contact
Terminal utilis comme un
modem
IrDA Infrarouge 115 kbit/s Industrie Echange d'informations d'un
mobile un autre
Lien vers un PDA
Lien vers un PC
Connexion Jusqu' 12
USB, srie... Industrie... Lien vers des priphriques
physique Mbit/s
divers (camra, photo...)
Priphrique 9,6 115 Lecteur de carte supplmentaire
Contacts ISO ISO
interne kbit/s (bancaire)
supports de communication en rseau

Circuit switched jusqu'
Data 9,6 kbit/s
Jusqu'environ
GPRS 50 kbit/s 3GPP -
Radio Prvu pour supporter tout type

IP Multimedia de transfert de donnes (y
Subsystem (IMS) compris la voix sur IP)
Jusqu'
Wi-Fi 11 Mbit/s
IETF Support Internet
Tableau 9.2. Supports de communication locaux
9.5.5.2. Gestion de l'accs aux supports de communication

Une fonction du terminal est de grer l'accs aux mdias de communication.
Toutefois, l'application n'est pas forcment rsidente dans le terminal lui-mme. Le
terminal est alors utilis la manire d'un modem et de manire plus ou moins
active :
- modem simple avec les applications rsidantes dans un PC ou un
organiseur ncessitant juste l'usage de tlphone pour accder au mdium de
communication ;
- modem actif dans le cas d'applications demandeuses de transfert

d'informations sans pour autant prfrer un moyen de transfert. C'est le cas par
exemple sur la carte puce avec l'utilisation du Bearer Independent Protocol (voir
figure 9.14).
Transfert de donnes
gr par le mobile
Figure 9.14. Transfert de donnes au travers

du mobile restant actif - Bearer Independent Protocol
Le 3GPP considre srieusement le fonctionnement des diffrentes applications

simultanment dans le mobile et les priorits leur accorder. Une utilisation
transparente du tenninal pose le problme du contournement des restrictions
d'abonnement imposes par l'oprateur, le fournisseur de service ou mme le
propritaire du mobile. Les fonctions permettant de gnrer ou de grer des appels
(Call Control) ne sont accessibles que par le terminal mobile (MT), au sens de la
figure 9.1. Par contre, la gestion de l'accs des supports locaux de communication
est moins surveille.
9.6. Conclusion
Les applications offertes sur les mobiles sont l'axe de dveloppement actuel au
moment o l'application tlphonie (au sens de la transmission de la voix) a atteint
sa maturit. Ce sont les applications qui font maintenant la diffrence entre les offres
des oprateurs et qui justifient les ressources accrues en 3G.
De nouveau intervenants entrent dans le march des services et applications.

L'offre en matire de terminaux devient trs fournie, avec les tlphones mobiles,
organiseurs, appareils photo, ordinateurs portables et mme terminaux de
paiement sur point de vente. L'interoprabilit devient un point fondamental pour
permettre le succs d'une application pouvant tre utilise sur diffrents
terminaux, tlcharge ou interagissant avec plusieurs terminaux.

L'interoprabilit vaut tout d'abord pour le code source de l'application, mais
aussi pour les ressources qui lui sont offertes.
Cette interoprabilit se fait par le standard, issu de l'industrie ou bien

d'organismes internationaux de normalisation. Elle passe par la convergence entre
les nombreuses plates-formes propritaires qui ont t dveloppes en seconde
gnration, vers une solution qui pourrait tre proche de celle que l'on utilise sur
l'Internet et qui volue encore. Elle se fait aussi par une politique de tests de
conformit, l'initiative des oprateurs et des fournisseurs de services.
9.7. Annexes
9.7.1. La standardisation ct terminaux
9.7.1.1. Terminaux Mobiles

9.7.1.1.1. 3GPP
Les spcifications des terminaux sont crites et dans le cadre de l'activit du

groupe T (pour Terminais) du 3GPP sur des spcifications de besoins manant du
groupe SA (pour Service Aspects). Pour des raisons de baisse de la charge de
travail et de budget, il est probable qu' l'horizon mi-2005, le travail du groupe
ddi aux terminaux sera dissout et ses activits rparties sur les trois autres
groupes consacrs la 3G, GERAN restant a priori encore indpendant.
Le groupe de travail des terminaux est divis en trois groupes.
Figure 9.15. Sur fond gris fonc, les principaux groupes et sous-groupes lis aux terminaux
9.7.1.1.2. OMA
OMA est la rsultante de la runion de plusieurs forums mineurs autour de
WAP. L'objectif affich est de standardiser un ensemble de briques de base qui
permettront aux oprateurs et aux fournisseurs de services de construire leurs offres.
Figure 9.16. Sur fond gris fonc, les principaux groupes et sous-groupes lis aux terminaux
9.7.1.2. Carte puce et standards

La promotion de la carte multi-applicative dans les domaines
tlcommunications, pour le 3GPP, le 3GPP2, etc. est passe par la rpartition du
travail de spcification entre une partie gnrique (dfinie au sein d'un projet ETSI :
le groupe Smart Card Platform) et des parties spcifiques au 3GPP, dfinies dans le
troisime sous-groupe du groupe Terminal (TSG-T SWG3).
9.7.1.2.1. 3GPP
Au 3GPP un comit est en charge de la spcification technique des applications
bases sur carte puce. Nanmoins, certains groupes orients service ont une forte
interaction avec la carte, en particulier bien sr dans le cas du groupe ddi aux
aspects scurit.
Figure 9.17. Sur fond gris fonc, les principaux groupes et sous-groupes lis l'UICC
Notons que depuis le dbut de la spcification du systme de troisime de

gnration, il a t dcid que les aspects gnriques (c'est--dire pouvant tre
communs d'autres applications bases sur la carte) seraient standardiss en dehors
du 3GPP : au SCP.
9.7.1.2.2. ETSI Project Smart Card Platform
Initialement, l'ide tait de crer un projet de partenaires sur la forme du 3GPP :

- d a n s lequel on aurait rassembl des fournisseurs de solutions (OS, machines
virtuelles, etc.) et des clients (3GPP, 3GPP2 par exemple pour les tlcoms, mais
aussi des partenaires du monde de la finance, de l'identit, etc.) ;
- q u i aurait spcifi tous les lments d'une plate-forme commune de
nombreuses applications carte puce (voir figure 9.18).
Figure 9.18. Domaine de travail du SCP

Si le projet produit rapidement les spcifications d'une plate-forme partir des

spcifications GSM, le partenariat lui ne prend pas, les diffrents protagonistes tant
plus intresss par le principe que par la formalisation du partenariat. Le travail
continue nanmoins, mme si la plate-forme gnrique reste plutt destine aux
tlcommunications.
Le projet SCP est structur en un groupe plnier qui pilote un groupe de

dfinition des besoins et un groupe de spcifications techniques (voir figure 9.19).
Figure 9.19. Structure du Projet SCP
9.7.1.2.3. OMA
Il n'y a pas proprement parler de groupe ddi la carte puce dans OMA.
Certains groupes occasionnellement voquent l'utilisation pour un service ou une
fonction particulire de la carte (le provisioning par exemple). OMA hrite par
contre d'une application carte dfinie par le WAP pour des aspects de scurit : c'est
la WIM ( WAP Identity Module).
9.7.2. Rfrences
Ces rfrences permettent d'aller plus loin dans les sujets voqus dans cet
article.
9.7.2.1. Spcifications - Standards

Les principaux documents de rfrence sont les suivants :
Documents maintenus par le 3GPP

Documents lis au Mobile
[1] TS 23.101 General UMTS Architecture
[2] TS 22 0 5 7 / 2 3 0 5 7 Mobile Station Application Execution Environment
(MExE)
Documents lis VHE
[3] TS 22.121/23.127 Virtual Home Environment
[4] TR 23.957 Virtual Home Environment (VHE) concepts
Documents lis au SIM
Subscriber Identity Module Application Programming

TS 02.19/03.19 Interface (SIM API)
[5]
TS 42.019/43.019
SIM API for Java Card
TS 02.48/03.48
[6] Security Mechanisms for the SIM Application Toolkit
TS 22.018/23.048
TS 11.11 Spcification of the Subscriber Identity Module -
[7]
TS 51.011 Mobile Equipment (SIM - ME) interface
TS 11.14
[8] SIM Application Toolkit (SAT)
TS 51.014
Documents lis au USIM/ISIM
UICC - Terminal Interface; Logical and Physical

[9] TS 31 .101
Characteristics
[10] TS 31 .102 Characteristics of the USIM Application
[H] TS 31 .103 Characteristics of the ISIM Application

[12] TS 31 .111 USIM Application Toolkit (USAT)
[13] TS 31 .112/13/14 USAT Interpreter

[14] TS 31 .130 USIM API
Documents maintenus par le SCP
Documents lis l'UICC
[15] TS 102 221 Smart Cards: UICC Terminal interface; Physical and
logical characteristics
[16] TS 102 223
[17] TS 102 241
[18] TS 102310 EAP support in UICC
Documents lis la carte puce

Documents maintenus par l ISO partir de documents de SDO nationaux (ex : AFNOR)
[ 19] ISO/IEC 7816 (Srie) Smart Card Characteristics ( 15 chapitres distincts)
Documents plus gnraux

Documents maintenus par l IETF
[20] IETF draft EAP-support in smartcards (http://www.ietf.org/internet-
drafts/draft-urien-eap-smartcard-03.txt)
draft-arkko-pppext-eap-aka-11, "EAP AKA Authentication".
[21] IETF draft http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-
ll.txt
draft-haverinen-pppext-eap-sim-12, "EAP SIM
[22] IETF draft Authentication".http://www.ietf.org/internet-drafts/draft-
haverinen-pppext-eap-sim-12.txt
9.7.2.2. Sites Web pour plus d'information

O r g a n i s m e s de standardisation :
[23] 3GPP http://www.3gpp.org/
[24] 3GPP2 http://www.3gpp2.org/
[25] ETSI http://www.etsi.org/
Forums ddis dans le domaine :

[26] GSM Association http://www.gsmworld.com/
pages concernant m-services
http://www.gsmworld.com/technology/services/index.shtml
[27] Java Card Forum http://www.javacardforum.org/
[28] Java Community Process http://www.jcp.org/en/home/index
[29] Open Mobile Alliance http://www.openmobilealliance.org
les spcifications WAP/OMA sont disponibles
http://www.wapforum.org/what/technical.htm
[30] SIM Alliance Alliance de fournisseurs de fournisseurs de cartes puce
http://www.simalliance.org/
[31 ] Symbian Alliance de fournisseurs de mobiles autour d'une solution
dveloppe l'origine pour des organiseurs PSION
http://www.symbian.com/
[32] SyncML Alliance d'industrie dfinissant un standard de synchronisation
entre terminaux : http://www.syncml.org/
Socits mentionnes :
[33] AvantGo http://www.avantgo.com/

[34] Microsoft les documents smartphone sont disponibles sur :
http://www.microsoft.com/mobile/
smartphone/
[35] NTT DoCoMo les documents i-mode sont accessibles partir de :
http://www.nttdocomo.com/home.
html
[36] PalmOne &
Pal Voir les sites web : http://www.palmone.com/
m (socit dveloppant les terminaux)
So et http://www.palmsource.com/
urc (socit dveloppant les logiciels
e
[37] Sun Microsystems les documents Java (et ses diffrentes dclinaisons)
sont disponibles sur
http://java.sun.com/
Chapitre 10
Scurit du systme UMTS
Les spcifications UMTS sont conues bien des gards comme une volution des
spcifications des systmes de deuxime gnration. Dans le cas de la scurit, le
systme GSM a servi de base mais des modifications importantes ont t apportes
pour pallier les faiblesses dcouvertes l'usage des systmes de deuxime gnration.
Par ailleurs, le systme GSM et les systmes de deuxime gnration en gnral

taient centrs sur les services exclusifs de l'oprateur. L'approche service
ouvert de la troisime gnration oblige revoir certains modles de scurit pour
couvrir le partage de certaines applications et l'entre de fournisseurs de services
dans la chane des services.
10.1. Introduction
Les volutions apportes la scurit pour l'UMTS sont bases sur une tude
des risques et des problmes connus lors du dploiement des rseaux de deuxime
gnration [21.133].
10.1.1. Exemples d'attaques sur un rseau mobile
Un rseau tant constitu d'un ensemble d'quipements informatiques, il est

particulirement sensible aux attaques. Dans le cas de l'UMTS, la vulnrabilit est
Chapitre rdig par Paul JOLIVET.

renforce par l'aspect immatriel de l'interface radio. Les diffrents scnarios

d'attaques sont rassembls en plusieurs types, selon que le pirate attaque :
- les communications des utilisateurs ;
- le service lui-mme pour l'utiliser ;
- le service pour l'empcher de fonctionner (dni de service).
La figure 10.1. dcrit les points sensibles dans la chane et les risques associs.
Les techniques de piratage sont, entre autres : l'coute, le remplacement
d'utilisateur, le remplacement de station de base, l'interposition et le craquage de
donnes d'authentification.
Figure 10.1. Exemples d'attaques sur un rseau mobile
Un dernier type d'attaque est celui du dni de service. Le pirate monopolise le

rseau d'accs ou le bloque de faon empcher les abonns d'accder au service.
Un ensemble de mcanismes ont t spcifis pour empcher ou, plus

modestement, rendre plus difficile les diffrents types d'attaques. Cependant, la
scurit n'est pas que l'affaire de protocoles mais aussi d'architecture et de gestion
du rseau, en particulier pour les lments devant tre mis jour ou relis des
rseaux extrieurs.
10.1.2. Mcanismes de scurit
Les services de scurit sont gnralement classifis de la faon suivante

Scurit du systme UMTS 425
- l a confidentialit protge contre l'coute des contenus transmis et contre

l'identification de l'usager ;
- l'authentification permet de s'assurer qu'une station est bien celle qu'elle
prtend tre ;
-l'intgrit assure qu'un message est bien reu tel qu'il a t mis sans
changement ou duplication ;
- la non-rpudiation empche un metteur de nier a posteriori qu'il a transmis
un message effectivement mis ;
- le contrle d'accs est la capacit de limiter l'accs un quipement ;
- la disponibilit doit tre garantie contre des attaques en nombre qui peuvent
provoquer une rduction des performances du rseau.
Dans le cas de l'UMTS, les principaux mcanismes mis en uvre sont les
suivants :
- chiffrement de la signalisation et des donnes utilisateurs sur le canal radio
pour assurer la confidentialit ;
- allocation d'une identit temporaire qui est transmise en mode chiffr pour
assurer la confidentialit des mouvements de l'utilisateur ;
- adjonction d'un champ aux messages de signalisation pour en assurer
l'intgrit ;
- authentification par le rseau du mobile ;
- authentification par le mobile du rseau.
10.2 Principes de la scurit en UMTS
Les changements apports aux spcifications UMTS concernent bien

videmment les algorithmes utiliss qui tiennent compte des volutions existantes.
Par exemple, il est possible d'utiliser des cls de taille plus importante (jusqu'
128 bits). Cependant, les amliorations ne s'arrtent pas l. Elles portent galement
sur les points suivants :
- le renforcement de la scurit au sein mme du rseau cur, alors que les
efforts GSM taient concentrs sur l'interface radio ;
- l'interconnexion de rseaux (mobile/fixe - circuit/paquet - 2G/3G - etc.) ;
- l'intgrit de l'identit des terminaux (IMEI), spcifie au commencement
mme de la conception des spcifications alors qu'elle est intervenue en cours de vie
pour le systme GSM ;
- l'authentification mutuelle pour contrer l'attaque par une station de base pirate.
10.2.1. Les lments matriels lis la scurit
La scurit UMTS [33.102] est base sur le principe de secrets partags et

d'algorithmes symtriques (c'est--dire que c'est le mme mcanisme qui permet
l'authentification de part et d'autre). Il convient donc de protger aux mieux ces
secrets en utilisant les principes suivants :
- les algorithmes utiliss peuvent tre propritaires ou partags pour
l'authentification et la gnration de cls ; dans tous les cas, leur spcification n'est
pas publie ;
- les donnes secrtes sont stockes dans des bases de donne scurises :
l'UICC (carte puce) du ct utilisateur et le centre d'authentification ou AuC
{Authentication Centre) du ct rseau.
Le centre d'authentification est gnralement reprsent (et conu) comme

colocalis avec l'enregistreur de localisation nominal (HLR, Home Location
Register). Il n'en est pas moins totalement indpendant, mme si les deux
quipements communiquent dans le cadre d'une procdure d'inscription ou
d'authentification.
10.2.2. Identit sur le rseau UMTS
L'identit principale de l'utilisateur est l'IMSI, comme dans le GSM.

L'identit est compos de trois champ : le code pays MCC (Mobile Country
Code), le code de l'oprateur MNC (Mobile Network Code) et un code librement
attribu par l'oprateur : le MSIN (.Mobile Subscriber Identity Number). La taille
du MSIN est variable au choix de l'oprateur. La dfinition du champ MNC a t
tendue de 2 3 chiffres pour permettre certains pays (aux Etats-Unis
principalement) de pouvoir disposer d'un plus grand nombre d'identifiants
d'oprateurs (voir figure 10.2). L'IMSI ne dispose pas de marqueur de
dlimitation des donnes ; l'interprtation automatique de l'IMSI peut se rvler
dlicate pour la cxistence entre anciennes cartes GSM d'un ct et les actuelles
SIM (pour lesquelles 3 chiffres sont systmatiquement allous, le dernier tant
fix F s'il n'est pas utilis) et USIM.
Plusieurs mcanismes visent protger l'identit de l'utilisateur UMTS :

-l'utilisation d'une identit temporaire TMSI (Temporary Mobile Subscriber
Identity) attribue par le rseau comme pour le GSM ; cette mesure n'est efficace
que si le taux de rafrachissement de l'identit temporaire est important ;
- l'authentification rpte de l'utilisateur, cette fonction est entirement

paramtrable par l'oprateur 1 ;
- l e chiffrement (sur l'interface radio en particulier) des donnes, y compris
l'identit de l'utilisateur et les mcanismes de vrification de la cohrence de la
localisation.
Longueur MNC
IMSI 3 chiffres
Chaque chiffre est cod en BCD sur 14 octet et occupe une demi-case sur le dessin.
Figure 10.2. Le codage de l'IMSI en GSM et UMTS
10.2.3. Identification de l'utilisateur
La premire mesure de protection est l'identification de l'utilisateur sur son

terminal. Cette identification se prsente de manire standard sous forme de la
prsentation d'un code PIN (Personal Identification Number). Cette opration est
ralise sur la carte puce de la mme manire que dans le systme GSM ou le
systme bancaire. Le principe repose sur l'utilisation d'un code 4 chiffres. Trois
prsentations successives errones du code PIN entranent un blocage de l'USIM.
L'application peut alors tre dbloque grce un code de dblocage 8 chiffres.
Dix prsentations successives d'un code de dblocage erron entranent le blocage
1. On connat le cas dans certains rseaux GSM, d'oprateurs (europens) qui renonaient
aprs son inscription authentifier de nouveau l'utilisateur aux heures de pointe de manire
dcharger le rseau de signalisation de cette tche. Ils ont fait l un compromis entre cot de
fraude et accessibilit au rseau.
dfinitif de l'USIM. Notons qu'il est impossible quiconque d'accder aux fichiers
protgs sur une carte bloque. Notons galement que le mcanisme d'identification
peut tre dsactiv par l'oprateur au moment de la personnalisation de la carte ou
par l'utilisateur tout moment.
Toute application (qu'elle soit base sur la carte, le mobile ou le rseau) peut,
comme l'USIM, disposer de procdures similaires d'identification.
10.2.4. Lignes directrices des algorithmes d'authentification
Comme dans le cas du systme GSM, le 3GPP ne dfinit pas d'algorithme

d'authentification mais le format des donnes d'entre et de sortie de ces
algorithmes [33.105]. Cette procdure tant toujours ralise dans le rseau
nominal de l'utilisateur (mme dans le cas de l'itinrance), le standard n'est pas
ncessaire, il pourrait au contraire constituer une faiblesse du systme.
Donnes Donnes
Fonction Type Nature Commentaire
d'entre en sortie
fO Gnration d'ala RAND
fl Fonction K, SQN, MAC
-
d'authentification du RAND,
rseau AMF
fl* message de
resynchronisation MAC
f2 authentification de K, RAND, RES XRES ou RES
l'utilisateur AMF selon que le calcul
est fait dans l'AuC
ou l'UICC
f3 cl de chiffrement CK
drive
f4 cl de calcul IK
d'intgrit drive
f5 cl anonyme de drivation AK Optionnel
chiffrement drive
f5* message de AK Optionnel
resynchronisation (cas
de la cl anonyme)
Tableau 10.1. Les diffrentes fonctions de base de MILENAGE

Il existe toutefois des lignes directrices proposes par le 3GPP pour le choix
d'algorithmes d'authentification. Les oprateurs sont mme de choisir des
algorithmes dfinis par des groupes comme SAGE2 l'ETSI ou encore de dfinir
des algorithmes propritaires .
La famille d'algorithmes d'authentification UMTS est nomme MILENAGE.

L'algorithme doit pouvoir raliser, en gardant impossible le calcul de la cl partir
du rsultat, les 7 fonctions rassembles dans le tableau 10.1.
Le synoptique complet du fonctionnement d'un algorithme MILENAGE est

repris dans la figure 10.3. Les donnes sont les suivantes :
- OP est un champ oprateur des fonctions de MILENAGE ;
- OP c est une valeur drive de la cl K et fonction de l'oprateur (OP) ;
- les fonctions r sont des rotations ;
- c sont des constantes additionnes ;
- E est un algorithme de Rijndael3 ([DAR 00, DAR 01]).
RAND
fl fl* f5 f2 f3 f4 f5 *
Figure 10.3. Les diffrentes fonctions de MILENAGE Source 3GPP [31.909]
2. Security Algorithm Group of Experts (voir Annexe B).

3. Outre son efficacit, cet algorithme prsente l'avantage d'tre libre de droits.
10.2.5. Authentification en UMTS
L'authentification UMTS consiste en la comparaison du rsultat d'un calcul

effectu sur la carte d'une part et dans le centre d'authentification d'autre part. Cette
fonction (schmatise dans la figure 10.4) est dtaille dans la suite du paragraphe.
UICC Rseau
K
RAND
non prdictible
XRES
RES
Figure 10.4. Principe de l'authentification de l'abonn
Les fonctions d'authentification et la cl secrte K4 sont situes dans la carte

puce (application USIM de la carte UICC) d'une part et dans le centre
d'authentification (AuC, Authentication Centre) d'autre part. D'un ct comme de
l'autre, l'accs est restreint et protg : par exemple, il n'est pas possible d'envoyer
une commande de lecture de la cl K l'USIM. Les spcifications 3GPP
mentionnent, sans les spcifier, les besoins de protection au cours des phases de
transfert de donnes vers la carte et l'AuC. La cl secrte K qui est utilise dans
l'authentification est un ala d'une taille de 128 bit au maximum. Sa gnration
comme son transfert vers la carte et le centre d'authentification (AuC) doivent tre
scuriss.
4. Correspond au Ki du systme GSM.

10.2.5.1. Authentification de l'abonn

L'authentification de l'abonn reprend le mme principe que dans GSM : un
algorithme d'authentification est utilis pour calculer, partir d'un nombre alatoire
RAND et de la cl K, un rsultat. Le calcul est fait par le centre d'authentification et
le rsultat obtenu est nomm XRES (eXpected RESult). Le nombre alatoire est
envoy l'UICC qui calcule de la mme faon un rsultat nomm RES. Si
XRES = RES (cas typique d'un abonn autoris), l'abonn est authentifi. Sinon,
toutes les demandes de services sont rejetes. L'algorithme d'authentification est un
algorithme sens unique : partir de RAND et de la cl K, le calcul du rsultat
est trs facile faire. En revanche, il est trs difficile de dduire la valeur de K
partir de la seule connaissance de RAND, SRES et de l'algorithme. On notera que K
n'est jamais transmise sur le rseau. Un attaquant peut essayer de configurer une
UICC avec une identit IMSI usurpe mais il ne peut connatre la cl K. Sans la
cl K, il n'est pas possible de renvoyer le bon RES une demande d'authentification
et par consquent d'utiliser le rseau.
10.2.5.2. Authentification mutuelle

Le systme GSM utilisait seulement le mcanisme d'authentification du rseau.
Le terminal n'authentifiait jamais le rseau. Une attaque possible tait d'envoyer
plusieurs centaines de milliers de RAND, de noter la valeur RES renvoye par la
carte SIM et d'en dduire la cl secrte. Pour contrer cette attaque, l'UMTS repose
sur l'authentification mutuelle (c'est--dire du mobile par le rseau et du rseau par
le mobile) et sur un mcanisme de compteur.
L'authentification du rseau repose sur les mmes principes que

l'authentification du mobile : le nombre alatoire est le mme (RAND), l'algorithme
est diffrent mais du mme type, le rsultat est appel MAC (Message
Authentication Code). Le champ MAC est rajout au message d'authentification. Il
permet au mobile de s'assurer que ce message vient d'une source digne de
confiance. La carte USIM calcule de son ct, partir du RAND, le code
d'authentification appel XMAC. Si XMAC = MAC, alors elle renvoie la valeur
SRES. Sinon, elle refuse la demande d'authentification.
Pour rduire encore le risque de fausse authentification , on utilise un principe

de compteur. Un numro de squence (SQN, Sequence Number) est gr par le
centre d'authentification. Ce numro est modifi chaque nouvelle authentification
de manire dterministe. Il intervient dans le calcul du MAC. Ce numro pourrait ne
pas tre transmis car la carte USIM et le centre d'authentification connaissent le
contexte (c'est--dire le nombre d'authentifications prcdentes) et peuvent le
dduire. Pour viter les problmes dsynchronisation, la valeur de SQN est
transmise sur la voie radio mais sous forme chiffre, la cl tant calcule partir de
RAND et de K. Si le terminal dtecte que le SQN envoy par le rseau ne
correspond pas au SQN attendu, il indique au rseau un problme de
dsynchronisation.
On utilise galement en UMTS, un paramtre AMF (Authentication

Management Field) qui permet, entre autres, de grer plusieurs algorithmes
d'authentification. L'ensemble MAC, SQN et AMF est regroup sous le terme jeton
d'authentification (AUTN, Authentication Token).
Figure 10.5. Principe de l'authentification mutuelle en UMTS
10.2.6. Intgrit des messages
Une des nouveauts de l'UMTS est l'utilisation de mcanismes de vrification

de l'intgrit des messages. La solution utilise est base sur le calcul de MAC
{Message Authentication Code) appliqu chaque message transmis.
Une vrification de cohrence est galement ralise avec des numros de

squence, de manire viter des fraudes par rptition des messages ou la
rutilisation de matriel de chiffrement prim (les cls en particulier).
La fonction f9 (propose par KASUMI, voir paragraphe 10.2.7) permet de

raliser des calculs de MAC pour s'assurer de l'intgrit des messages de
signalisation changes dans le rseau. Ces messages peuvent par ailleurs tre
chiffres. Elle dispose en donnes d'entre :
- la cl d'intgrit IK (128 bits ou dans le cas d'une taille infrieure, la valeur de
la cl complte de 0) ;
- le message ;
- un compteur li une horloge (COUNT-I) ;
- un ala (FRESH).
MESSAGE MESSAGE
MAC-I XMAC-I
Sender Receiver
UE or RNC UE or RNC
Figure 10.6. Principe de calcul de l'intgrit Source 3GPP [33.102]
La cl d'intgrit IK est calcule partir du nombre alatoire RAND, de la cl

secrte K et de l'algorithme f4.
10.2.7. Chiffrement des donnes
A contrario de l'authentification, le chiffrement/dchiffrement d'informations

doit pouvoir tre ralis hors du rseau nominal pour assurer l'itinrance. Le 3GPP
dfinit donc un algorithme, embarqu dans tous les terminaux. Il est prvu pour
scuriser les donnes changes entre le mobile et le serveur final, au-del mme du
simple lien radio comme le prvoyait le standard GSM. Le cahier des charges pour
l'algorithme est le suivant :
-capable de calculer un MAC pour raliser les contrles d'intgrit des
donnes ;
- pouvoir supporter un dbit de donnes de 2 Mbit/s symtrique ;
- s ' i l envisag d'utiliser des algorithmes secrets (comme pour le GSM), leur
fiabilit ne devra pas tre base sur ce seul secret.
La cl de chiffrement CK est drive de la cl secrte K grce la fonction f3

(voir figure 10.7) de Millenage. Cette opration est ralise pendant la phase
d'authentification. Ct USIM, sous rserve que l'ensemble des calculs soient
possibles, c'est--dire que le rseau et la squence de l'authentification soient
corrects, la valeur est stocke sur l'USIM, accessible pour utilisation, mme si par la
suite l'authentification devait tre rejete par le rseau.
CK
Figure 10.7. Principe de calcul d'une cl de chiffrement
Le groupe 3GPP/ETSI SAGE dfinit par ailleurs dans le rapport technique

TR 33.901 [33.901] la procdure d'approbation d'un nouvel algorithme, qu'il soit
existant ou dfini pour l'UMTS.
L'algorithme retenu est KASUMI . Il est issu de l'algorithme japonais

MISTY5 et permet de raliser les fonctions de chiffrement et de vrification de
l'intgrit des donnes, respectivement f8 et f9. Le synoptique de fonctionnement de
KASUMI est dtaill sur la figure 10.93.
5. Dfini par Mitsubishi, [35.201], [WMI].

Sender Receiver
UE or RNC RNC or UE
Figure 10.8. Principe de calcul des squences de chiffrement

Source 3GPP [33.102]
La fonction f8 permet de chiffrer un flot de donnes. Elle dispose en donnes

d'entre :
- la cl de chiffrement CK 6 (Cyphering Key) sur 128 bits ou, dans le cas d'une
taille infrieure, la valeur de la cl complte de 0 ;
- un compteur li une horloge (COUNT) ;
-l'identit du mdium de transmission, la mme cl pouvant tre utilis sur
diffrent mdias (BEARER) ;
- la direction (DIRECTION) ;
- la longueur du message (LENGTH).
Si le chiffrement est une priorit de la scurit de l'UMTS, la plupart des pays

ont limit rcemment l'usage d'algorithmes pour le chiffrement l'export. Un
accord a t conclu entre 33 pays industriels : l'accord de Wassenaar [WAS].
Selon ses termes, la longueur des cls de chiffrement est limite 56 bits dans le
cas de l'export. Chaque pays peut, dans le cadre national, avoir des dispositions
propres (autorisation ou contrle) concernant l'utilisation de cls de plus grande
taille. Ces dispositions ne concernent pas le calcul de MAC pour le contrle
d'intgrit.
6. Equivalent du Kc dans le systme GSM.

Le systme de chiffrement de l'UMTS doit pouvoir s'adapter toutes les

situations dans le monde. Une certaine flexibilit a donc t introduite pour faciliter
cette adaptation dans la gestion des cls.
10.2.8. Aspects protocolaires
10.2.8.1. Qui n tupi et de scurit

Pour permettre un quipement d'un rseau de raliser l'authentification
mutuelle et d'assurer l'intgrit et le chiffrement, il est ncessaire et suffisant qu'il
dispose des informations suivantes :
- le nombre alatoire RAND choisi par le centre d'authentification ;
- le jeton d'authentification AUTN comprenant le MAC, rsultat du calcul
d'authentification du rseau ;
- le rsultat SRES de l'authentification du mobile ;
- la cl IK servant au mcanisme d'intgrit ;
- la cl de chiffrement CK.
L'ensemble de ces 5 donnes est appel quintuplet de scurit. Le quintuplet est

form par le centre d'authentification de l'oprateur d'un abonn. Il peut tre fourni
tout VLR du rseau, voire un VLR d'un autre rseau. Les fonctions de scurit
peuvent alors tre assures de faon autonome par le VLR sans connatre les cls
propres l'abonn, ni les algorithmes spcifiques l'oprateur de cet abonn.
10.2.8.2. Echange de messages

Les changes protocolaires entre lments du rseau sont reprsents dans la
figure 10.9, l'exemple donn s'insre dans la procdure d'inscription au rseau.
Dans ce cas, la requte est l'initiative du mobile qui cherche s'inscrire. Le VLR
demande des quintuplets au centre d'authentification (suppos intgr dans le HLR
dans la figure). Plusieurs quintuplets peuvent tre transmis dans un mme message.
Une authentification peut galement, de manire optionnelle, tre ralise la

demande du rseau, de manire priodique ou alatoire pour limiter les fraudes. La
figure 10.10 reprsente l'change simple qui caractrise cette re-authentification.
Pendant toute la dure de l'utilisation du rseau, des identits temporaires sont

utilises (TMSI, Temporary Mobile Subscriber Identity) de faon limiter le risque
d'interception de l'identit unique (IMSI). Le TMSI est allou par le rseau (voir
figure 10.11) et il est spcifique au VLR (Visitor Location Register), l'enregistreur
de localisation visiteur7. Un utilisateur change rgulirement de TMSI selon les

paramtres de l'oprateur.
Figure 10.9. Principe de l'authentification UMTS cas de l'inscription du mobile au rseau
Figure 10.10. Rauthentification l'initiative du rseau
7 Notons que le terme peut prter confusion. Un utilisateur est toujours visiteur , c'est--
dire inscrit dans un VLR. Le HLR ou enregistreur de localisation nominal est une base de
donnes centrale de l'oprateur.
Figure 10.11. Principe de l'allocation d'identit temporaire (TMSI)
10.3. Les attaques possibles - Les protections
10.3.1. Parades - Protection
Les mcanismes supplmentaires suivants ont t mis en place pour protger les
messages de signalisation des attaques (coute et/ou interception) :
- authentification (voir 10.2) ;
- vrification de l'intgrit par un calcul de MAC (voir 10.2) ;
- vrification de cohrence sur l'information de localisation ;
- rinitialisation du chiffrement en cours de communication s'il n'est pas utilis
ou si son utilisation a t interrompue ;
- mise en place d'un mcanisme anti-rptition.
La protection contre une interception qui relaye les messages sur l'interface
radio est par contre plus dlicate, comme toute attaque radio. Les donnes et les
identits sont protges par chiffrement dans ce cas.
10.4. UICC et AuC, cl de vote du systme
L'utilisation d'une carte puce permet de scuriser l'accs des donnes

sensibles au premier rang desquelles la cl individuelle K de l'utilisateur.
Le chargement d'applications comme l'accs par diffrentes applications aux

donnes de la carte est dfini par des procdures. Les spcifications 3GPP mettent
en vidence l'importance de la scurit dans la gestion des cls.
Par ailleurs, tout est conu pour rduire la rutilisation des donnes hors de leur
contexte d'origine. L'IMSI par exemple n'est normalement pas utilis comme
identifiant dans le cadre de sessions IP Multimdia ou WLAN.
10.4.1. Scurit et carte puce
La carte puce a trois avantages

- structure scurise et personnalise ;
- proprit de l'oprateur ;
- portabilit de l'information.
Le stockage d'informations dans une carte puce, lment indpendant du

terminal, permet un haut niveau de scurisation. Selon les niveaux d'accs, les
donnes sensibles (comme une cl individuelle) peuvent tre rendues compltement
invisibles de l'extrieur, ne pouvant tre utilises que par un excutable lui-mme
install sur la carte. Depuis l'origine des cartes, le seul piratage connu provient de la
reconstitution de donnes partir du rsultat des calculs de la carte, mais en aucun
cas de la lecture des donnes protges.
Une autre force de la carte puce rside dans sa personnalisation. Alors que les
fournisseurs de terminaux travaillent dans la reproduction en grand nombre de
terminaux identiques, les fournisseurs de cartes font leur mtier de la
personnalisation de chacune de leurs cartes dans un environnement scuris qui a
fait ses preuves pour le domaine bancaire. Chaque carte qui sort de production peut
tre identifie par son numro de srie et comporter un jeu de donnes uniques (cls,
identifiants, etc.) en fonction des vux de l'oprateur.
L'oprateur est particulirement sensible la scurit de ces donnes qui

permettent l'accs au rseau et aux services. A ce titre, il est rassur de disposer de
ces informations sur un support qui lui appartient 8 et dont il matrise compltement
la production.
Pour finir, la carte puce permettra facilement un utilisateur de changer de

terminal et de retrouver sur le nouveau terminal le mme accs au rseau et aux
services, sous rserve bien entendu que le terminal supporte ces services.
8. Dans le domaine des tlcommunications mobiles comme dans le domaine bancaire, la

carte puce reste la proprit de l'metteur et non de son utilisateur.
10.4.2. UICC et USIM
Une volution importante en troisime gnration est la cration d'une plate-

forme commune pour les cartes puce. Cette plate-forme est dfinie sous l'gide de
l'ETSI et peut servir de base toute application. Les bases de cette plate-forme sont
issues de la SIM du systme GSM qui reste la plus rpandue des applications sur
carte puce du march.
Figure 10.12. Architecture d'une UICC
Le 3GPP et le 3GPP2 basent aujourd'hui les applications carte sur cette plate-
forme : SIM et USIM pour le 3GPP, R-UIM pour le 3GPP2. Ces applications sont
indpendantes, mme si dans certains cas (l'annuaire utilisateur - ou Phone Book)
des donnes peuvent tre partages.
D'autres comits ont cr des applications compatibles avec l'UICC, l'instar

du WAP Forum (OMA depuis 2002) avec son application de scurit : la WIM
(WAP Identity Module). Le domaine bancaire tarde encore s'inscrire dans cette
dynamique, mais le problme reste moins technique que politique.
10.4.3. Utilisation de base
La premire utilisation de l'UICC dans le cadre de l'UMTS, c'est l'USIM et

bien entendu la SIM hritage du GSM. Ces applications, avec chacune leur niveau
de scurit spcifique permettent au systme de raliser authentification et
chiffrement.
L'authentification est ralise en local dans la carte avec les donnes fournies par
le rseau (l'ala RAND, voir paragraphe 10.2.5). L'algorithme d'authentification est
excut en local dans l'UICC pour viter un change de cl avec le terminal. Le
rsultat est retourn au rseau (au travers du mobile) pour contrle.
Le chiffrement, par contre, demande des ressources que la carte puce ne peut
encore fournir. Il est donc encore ralis par le terminal, grce des donnes (dont
la cl CK de session) calcules par l'UICC. Les limitations qui empchent de faire le
chiffrement l'intrieur de la carte sont :
- le dbit de l'interface carte-terminal (maximum 400 kbits/s en Release 6) ;
- le duplex l'alternat (pas d'mission et de rception simultane sur
l'interface), jusqu' la Release 6 tout au moins ;
- la capacit de calcul de la carte, encore trop faible pour raliser des encryptions
importantes la vole.
Des applications de streaming au travers de l'UICC sont considres pour les

Release 7 ou 8 (pas avant l'horizon 2006/2007 pour la disponibilit des
spcifications), o des donnes pourraient tre dchiffres au vol sur la carte. Il est
question dans ce cadre d'utiliser de nouveaux protocoles en parallle ceux utiliss
actuellement. L'USB et les protocoles utiliss dans les cartes de mmoire de masse
(de type MMC) sont sur les rangs des candidats possibles.
10.4.4. Scurit et IP Multimedia
Dans le cadre de la scurit du rseau IP Multimedia (IMS, IP Multimedia

Subsystem), plusieurs approches ont t tudies. La rutilisation des applications
SIM et USIM est possible pour l'authentification et la gnration de cls, il est
nanmoins clair que la rutilisation des mmes mcanismes et cls risque de
fragiliser la protection de ces donnes. Un nouveau systme est donc prfr, bas
sur une nouvelle application : ISIM [31.103] (IMS SIM). Cette application est la
pure transposition de l'USIM dans le cadre de IMS : mmes structures, mmes
fonctions, mais des cls et des identifiants ddis.
Outre l'avantage de ne pas utiliser sur plusieurs rseaux les mmes donnes,
l'existence d'une ISIM permet d'imaginer pour le futur des cartes UICC avec cette
seule application pour accder le rseau IMS d'un fournisseur de services qui
n'oprerait que cette technologie.
10.4.5. Scurit et service de diffusion multimdia (MBMS)
Le service multimdia de diffusion ou de multipoint (MBMS, Multimedia

Broadcast/Multicast Service) est dcrit en Rel-6. Son principe repose sur la
diffusion d'information crypte d'lments multimdia ( la manire d'une chane
de tlvision crypte) auxquels les utilisateurs accdent par des services
d'abonnement. La diffusion peut tre gnrale ou concerner un groupe d'utilisateurs
particulier (multipoint). Le besoin en scurit est vident pour la gestion mme de ce
service en accs restreint. L'architecture dcrite repose sur l'utilisation de l'USlM et
de nouvelles donnes.
L'architecture de scurit est bas sur des cls/algorithmes symtriques. Le jeu

de cls comprend :
- MUK ( M B M S User Key), la cl secrte individuelle de l'utilisateur ;
- M R K ( M B M S Request Key) qui permet d'authentifier l'utilisateur demandant
des informations au serveur ;
- MSK ( M B M S Service Key), qui permet d'accder au service, cette cl est
fournie par le serveur et encrypte par MUK ;
- MTK ( M B M S Traffic Key), qui permet de dcrypter les donnes reues dans le
mobile.
Les cls MSK et MTK sont alloues par le fournisseur de services selon le type
d'usage : accs ponctuel ou abonnement long terme au service. L'allocation peut
venir d'une requte de l'utilisateur (figure 10.13) ou d'une allocation par le serveur
(figure 10.14), soit en modepush, soit en provoquant une requte de la part du terminal.
Figure 10.13. Allocation d'une cl de service

l'initiative du terminal (de l'utilisateur)
voir requte
par le terminal
Figure 10.14. Allocation d'une cl de service l'initiative du rseau

(par push ou en provoquant la requte du terminal -pull-)
Selon les implmentations, MUK et MSK peuvent tre stockes sur l'UICC pour
assurer une meilleure scurit d'accs et d'utilisation de ces cls. L'authentification
d'un utilisateur et l'autorisation d'accs un service se fait dans une connexion
point point reposant sur l'authentification par HTTP Digest. La procdure peut tre
initie par le rseau comme par l'utilisateur.
10.4.6. Scurit et appels de groupe ( VGCS)
Le service d'appel de groupe (VGCS, Voice Group Call Service) utilise

galement l'USIM pour ses besoins de scurit. Un fichier de l'USIM permet de
dfinir les identifiants de groupe d'utilisateurs autoriss. Au moment de
l'authentification, l'identifiant est vrifi et la cl VGCS drive partir de cet
identifiant pour obtenir une cl de session ( VGCS Short Term Key).
Les procdures d'authentification VGCS donnent aussi la possibilit de spcifier

l'algorithme utilis pour le chiffrement, opration possible uniquement avec une
USIM, la SIM ne peut tre mis jour dans ce sens.
10.4.7. Scurit et I-WLAN
L'UICC est utilise galement pour l'accs au WLAN dans le cas particulier de
l'interconnexion 3GPP/WLAN (I-WLAN). Il s'agit d'utiliser la scurit UMTS dans
le cadre du protocole standard utilis en WLAN : EAP (Extensible Authentication
Protocol). L'authentification est transporte de manire standard sur les protocoles
Radius ou Diameter jusqu'au serveur AAA (Authentication Authorisation
Accounting). L'authentification est gnralement base sur les principes UMTS,
c'est--dire AKA, mais il est galement possible d'utiliser EAP SIM.
Figure 10.15. Authentification EAP AKA
Pour renforcer la scurit, l'utilisation d'identits temporaires est conseille,

mme si pour des raisons pratiques, il n'est pas exclu d'utiliser l'IMSI comme
identifiant. Une procdure de rauthentification est ajoute et l'UICC peut gnrer
des cls chaque reprise.
10.4.8. Scurit et terminal rparti entre plusieurs priphriques
Dans le cadre de la rpartition des fonctions dans diffrents TE (Terminal

Equipment, voir figure 9.1), le problme de l'authentification prend une nouvelle
dimension. Il devient important qu'un lment distant de l'quipement mobile (au sens
ME, Mobile Equipement) puisse disposer d'lments de scurit contenus ou gnrs
par l'USIM. Il faut donc disposer de procdures pour transmettre du ME vers des TE
distants9 les informations ncessaires leur fonctionnement. Cette transmission peut
se faire sur des mdias locaux parmi lesquels : Bluetooth, WLAN ou IrdA.
Si le besoin de scurit dans cette configuration est tabli, le travail de

spcification dpasse le cadre de la Release 6. Une tude de faisabilit existe
[TR 33.817], elle dcrit les cas d'utilisation et les obstacles principaux la mise en
place de solutions. Le principal frein l'implmentation de ce type d'architecture est
la fragilit du transfert de matriel de scurit au travers de mdias dont le modle
de scurit repose en partie sur la faible distance d'mission.
10.5. Applications et scurit
10.5.1. Interfonctionnement des applications et pare-feu
Les applications spcifies au 3GPP sont conues dans certains cas pour
communiquer entre elles via des procdures ou un protocole dfinis. Dans tous les
autres cas, elles sont protges les unes des autres par des systmes de pare-feu,
gnralement grs par les environnements applicatifs, Java ou Symbian par
exemple.
Dans le cas des autres applications, la scurit repose en particulier sur la

certification de ces applications. Le problme est d'autant plus important que les
applications rsident sur des lments sensibles comme l'UICC. Il revient
l'oprateur (ou au fournisseur de service propritaire de l'application) de certifier les
applications pour viter le tlchargement de virus par exemple.
La gestion de conditions d'accs permet de limiter les attaques. Pour permettre

l'intervention de plusieurs fournisseurs de service sur le terminal et l'UICC, la
notion de domaines de scurit a t dfinie. Il s'agit en fait de crer un espace o
plusieurs intervenants peuvent charger des applications en confiance les uns avec les
autres. Cet espace est muni de diffrents niveaux de conditions d'accs et de droits.
9. Inclus par exemple dans un ordinateur, un organiseur ou tout module qui a la facult de
pouvoir se connecter un mobile et changer des donnes au travers du mobile en question.
L'interaction entre applications est dfinie dans un cadre strict et en exploitant

les protocoles et commandes existants. Des applets Java par exemple peuvent tre
rparties entre le mobile et l'UICC pour exploiter les fonctions de ces lments au
mieux. Dans ce cas particulier, une spcification dveloppe par le Java Community
Process donne les rgles et les limites de l'interaction dans un document : le JSR
177 [JSR 177].
10.5.2. Tlchargement d 'applications
Le principe des domaines de scurit s'applique videmment galement au

tlchargement d'applications. Il est compatible avec les architectures
d'infrastructure cl publique (PKI, Public Key Infrastructure).
Plusieurs questions se posent nanmoins pour la mise en place de tlchargement

d'applications :
- dans le cas de l'ouverture du terminal plusieurs fournisseurs de contenu, la
gestion du premier secret, qui permet d'ouvrir la possibilit d'accs de nouvelles
sources. Ce secret est gnralement gr par le propritaire de la carte, l'oprateur a
priori ;
- la certification des applications pour le chargement sur une plate-forme qui verra
coexister simultanment ces applications, au risque qu'un cheval de Troie soit
introduit. Le propritaire de la carte qui l'utilisateur est susceptible de se plaindre en
cas de problme, est forcment tent de considrer, au-del de l'utilisation de firewall
et autres protections, un processus d'examen des donnes charges sur le terminal ;
- la prsence d'un tiers de confiance (Trusted Third Party) qui pourrait grer la
scurit des changes pour l'oprateur, l'utilisateur et tous les fournisseurs. Si la
fonction existe dj dans le domaine des transactions financires, ce n'est pas encore
le cas pour le chargement d'applications.
Le tlchargement reste un sujet sensible et encore rserv l'usage de

l'oprateur. La coexistence avec des fournisseurs de services est envisage avec
prudence, mme si ct implmentation, les solutions existent. Le sujet remet
priodiquement au centre des dbats deux points cruciaux :
- qui est propritaire de la carte ? Un oprateur est-il prt mettre une USIM sur
une UICC qui ne lui appartient pas, qui plus est si cette UICC est susceptible
d'hberger par ailleurs une USIM d'un autre oprateur ;
- qui est responsable en cas de vol, perte ou fraude partir d'une carte multi-
propritaires ?
10.6. Roaming et scurit
10.6.1. Accs aux donnes de scurit
L'itinrance repose sur des accords entre oprateurs. L'interconnexion des

rseaux pose videmment des problmes de scurit, qui peuvent tre traits comme
toute interconnexion de rseau. Notons tout de mme pour le cas de l'itinrance
que :
- les calculs d'authentification sont toujours raliss dans le rseau nominal d'un
ct et dans le terminal de l'autre. Ils peuvent donc reposer sur des algorithmes
propritaires, seul le format des donnes d'entre et sortie tant standards ;
- le chiffrement est lui uniquement ralis dans le rseau visit. Il repose donc
sur l'utilisation d'algorithmes standards.
Dans ces conditions, les donnes vhicules au travers des rseaux sont (sauf
l'identit de l'utilisateur) des donnes temporaires ce qui rduit considrablement le
risque de piratage sur un rseau visit.
10.6.2. Accs de multiples rseaux

i
Si l'UICC est conu pour supporter plusieurs applications susceptibles de
fonctionner simultanment, le 3GPP spcifie clairement qu'il n'est pas question
d'utiliser simultanment plusieurs SIM ou USIM. L'aspect multiapplicatif de la
carte ne concerne que l'utilisation d'une SIM ou USIM et une ou plusieurs autres
applications comme par exemple l'ISIM ou la WIM.
10.6.3. Algorithmes de conversion, fonctionnalit 2G
Le standard UMTS a prvu la possibilit pour un utilisateur UMTS de

s'authentifier au travers d'un rseau qui ne supporte pas les fonctionnalits 3G. Il
dfinit pour cela trois fonctions de conversion qui permettent de passer du format de
l'authentification par quintuplets 3G celui par triplets 2G. Ces fonctions de
conversion sont les suivantes :
- c l , pour reformater RAND ;
- c2, pour transformer XRES (format 3G) en SRES (format 2G) ;
- c3, pour calculer Kc (format 2G) partir de CK ou IK (cls 3G).
10.6.4. Roaming 2 G/3 G, authentification et chiffrement
Dans le cas du roaming 2G/3G, le niveau de scurit employ est celui autoris
par la carte UICC prsente dans le mobile.
De nombreux oprateurs ont manifest de la rticence accorder la possibilit

des USIM de gnrer du matriel d'authentification 2G par drivation (voir ci-
dessus). La TS 31.102 dcrit la possibilit (optionnelle) pour une USIM de gnrer
du matriel d'authentification 2G de telle manire qu'un mobile s'inscrive dans un
rseau GSM.
Le rseau 3G peut supporter l'authentification 2G, auquel cas le HLR doit

comporter les fonctions de conversion c2 et c3 (qui permet la conversion des cls
d'authentification 3G en 2G) ou le processus 2G complet.
10.7. Interception lgale
L'interception lgale des communications est au croisement des considrations

de scurit et du droit des individus une vie prive. La plupart des pays se sont
dots d'une rglementation dans le domaine. L'approche dans cette section est plus
particulirement tourne sur l'Europe.
10.7.1. Les rsolutions le la Communaut Europenne
La premire rsolution prise sur le sujet par la Communaut Europenne a t

publie en novembre 1996 (96/C 329/01). Cette rsolution reconnat le droit des
Etats intercepter des communications dans le cadre de la scurit nationale ou
d'enqutes particulires.
Les besoins suivants sont mis en vidence par la CE :

- l'accs l'ensemble des donnes transmises ou transmettre depuis ou vers un
abonn ou numro d'identifiant de faon temporaire ou permanente dans le rseau
de tlcommunications, en droutant les appels vers d'autres rseaux ou terminaux,
mme si l'appel traverse plus d'un rseau (par exemple de plusieurs oprateurs) ;
- l ' a c c s l'ensemble des donnes relies l'appel dont la signalisation,
l'identit de l'appel et de l'appelant (mme dans le cas d'appel en chec), toute
information mise, les informations concernant la communication (date, dure,
renvois, etc.), l'information de localisation connue par le rseau, l'information sur
les services et paramtres spcifiques de l'utilisateur ;
- la possibilit de surveillance en temps rel (ou, dans les cas o l'information

n'est pas disponible, en fin d'appel) ;
- une ou plusieurs interfaces pour les systmes de surveillance des services
officiels (dfinies en accord entre les oprateurs d'un pays et les autorits en charge
de l'interception), les donnes et le contenu de l'appel devant tre dlivre en clair si
la communication est crypte.
L'interception doit tre transparente pour l'utilisateur. La fiabilit de

l'interception doit au moins valoir celle du service intercept, dans certains cas, les
autorits en charge de l'interception peuvent dfinir une qualit de service.
L'assistance de l'oprateur peut tre requise pendant l'interception selon les
dispositions de chaque pays. La mise en place d'une interception doit pouvoir tre
ralis dans de courts dlais (en minutes ou heures). Les donnes interceptes
doivent tre scuriss contre toute autre utilisation que celle des autorits en charge.
Enfin, l'ventualit de plusieurs interceptions simultanes ou de plusieurs autorits
en charge de l'interception doit tre considre par les oprateurs.
10.7.2. La mise en place dans les pays, le cas du Royaume-Uni
Le Royaume-Uni a remis jour en 1999 ses dispositions concernant

l'interception. Des propositions ont t publies pour commentaire pour une priode
de plusieurs mois. La plupart des commentaires sont venus des industries des
tlcommunications et de l'Internet.
Le besoin d'interception est reconnu et la mise jour des dispositions est

discute. Les principaux changements concernent :
- la complexit du systme qui peut concerner plusieurs rseaux interconnects ;
- la cohrence avec la politique existante de protection des donnes (en
particulier pour le cas des informations mdicales) ;
- le respect de la Convention Europenne des Droits de l'Homme ;
- la sparation des contenus et des paramtres de chiffrement le cas chant.
S'il y a un accord sur le besoin, le problme est plus de savoir comment doit se
faire la rpartition du cot de l'implmentation. Les conclusions suivantes sont
tires :
- les dfinitions fonctionnelles sont spcifies et rendues indpendantes des
technologies ;
- les demandes ne doivent pas reprsenter un frein au travail ;
- l'expertise doit tre galement dveloppe par les autorits, les oprateurs
n'ayant pas toute la charge de l'interception et de l'analyse.
10.7.3. Interception et standardisation
10.7.3.1. Le groupe ETSI SEC

Au sein de l'ETSI, un groupe de travail est ddi la scurit : SEC (Security). Il
gre et coordonne l'ensemble des aspects lis la standardisation de la scurit pour
l'ETSI. Ce groupe est en charge des aspects techniques et lgaux. Il gnre un
ensemble de documents (ETSI Security Standards Policy) de faon donner
l'ensemble des spcifications ETSI une approche cohrente. Il a produit 7
documents (rfrences [LU] [LI7]). Chacun des groupes de l'ETSI est invit
tenir compte de ces documents. Le groupe SEC est compos de 2 sous-groupes :
SEC ESI ; Electronic Signatures and Infrastructures, et SEC LI, Lawful
Interception. Ce dernier a pour objectifs de :
-prendre en charge les aspects de l'interception lgale pour l'ETSI en prparant
des rapports et spcifications ;
- crer des standards gnriques pour l'interception lgale ;
- tre en relation avec l'ensemble des groupes (internes l'ETSI ou extrieurs)
en charge d'interception lgale et leur offrir le conseil ;
- tablir un plan de travail continu sur le sujet ;
- reporter au groupe ETSI Security pour l'approbation des documents et plan de
travail ;
- donner des recommandations au groupe ETSI Security.
10.7.3.2. Le groupe 3GPP TSG-SA WG3

Au sein du 3GPP, le groupe 3GPP TSG-SA WG3 Security (souvent not
SA3) est en charge des aspects scurit de manire gnrale au sein du 3GPP. Le but
de ce groupe est de fournir au moins le mme niveau de scurit que celui procur
dans le systme GSM en particulier ou dans les systmes de 2e gnration en
gnral.
Ce groupe de travail dispose galement d'un sous-groupe ddi l'interception

lgale des communications. Le principe est de mettre en place les concepts
introduits au niveau de l'ETSI pour l'Europe, mais galement de traiter des cas
particuliers au rseau UMTS, comme par exemple la messagerie multimdia (MMS,
Mobile Multimedia Service) ou encore les appels de groupes (VGCS, Voice Group
Call Service).
10.8. Protection du rseau UMTS
10.8.1. Le rseau nominal
La scurit n'est pas uniquement l'affaire de protocoles et de cls. Il s'agit

galement de scuriser l'accs aux diffrents lments du rseau par le personnel
mme de l'oprateur. Les spcifications 3GPP mentionnent un certain nombre de
rgles. Ces rgles sont supposes tre les bases de fonctionnement. Elles rgissent
l'accs aux sites d'hbergement du matriel et l'accs et la manipulation des
donnes sensibles.
10.8.2. Les lments du rseau- interfaces
Le contrle d'accs aux diffrents lments du rseau est capital pour la

protection des donnes. Les interfaces et les accs distants (pour maintenance ou
mise jour) sont considrs comme des point sensibles.
10.8.2.1. Home Location Rgis ter - HLR

Le HLR est un des lments sensibles du rseau, il est le point de gestion des
donnes qui sont envoyes au systme de facturation. C'est galement l'lment du
rseau o est gr l'accs pour l'utilisateur aux diffrents services de l'oprateur.
L'accs distance cet lment du rseau doit tre particulirement contrl. La

scurit ne saurait tre uniquement base sur le dveloppement d'une interface
propritaire. Cette solution ne saurait d'ailleurs protger les attaques des employs
mmes de l'oprateur. Des propositions sont faites pour que l'accs soit ralis sur
la base de profils d'utilisateur donnant certains droits d'accs. Il est par ailleurs
conseill de limiter le nombre d'accs comme les diffrents protocoles pour ne pas
multiplier les risques d'attaques.
10.8.2.2. Authentication Centre - AuC

Le point le plus sensible dans le rseau est certainement le centre
d'authentification : AuC {Authentication Centre). Les donnes confidentielles
concernant l'abonn (identit, cl et services correspondants) y sont stockes.
L'attaque d'un AuC peut permettre un pirate de cloner des utilisateurs existants ou
d'en introduire de nouveaux.
La premire scurit consiste limiter le nombre de personnes ayant

effectivement accs cet lment.
Il est par ailleurs conseill de physiquement sparer l'AuC des HLR, mme s'il
faut bien constater que les fabricants comme les oprateurs ne sont pas forcment
motivs par l'ide de multiplier les lments dans le rseau. Un compromis peut tre
de sparer les lieux de stockage (disques durs) et de multiplier les systmes pare-
feu dans les HLR-AuC. Notons que la sparation physique HLR-AuC ajoute une
interface, donc un point sensible, entre ces deux lments : un pirate pourrait
effectivement tenter une attaque en multipliant les demandes de quintuplets
d'authentification (voir paragraphe 10.2.5 sur les procdures d'authentification)
pour calculer la cl K d'un utilisateur.
Pour finir, les donnes de l'AuC seront d'autant plus scurises qu'elles seront
cryptes. L'algorithme est laiss au choix de l'oprateur, comme d'ailleurs la taille
des cls de chiffrement (l'lment tant isol, il ne tombe pas sous le coup des textes
de rglementation sur la taille des cls de chiffrement). Dans le cas du chiffrement,
la protection de la cl de chiffrement et de l'algorithme entre bien entendu dans les
mmes considrations de scurit.
10.8.2.3. Mobile Switching Centre - MSC

Le commutateur est un point cl de communication du rseau. Les appels y
transitent comme la signalisation qui leur est associe. Des donnes confidentielles y
sont traites, elles sont pour certaines cryptes. Une attaque sur cet lment du
rseau peut causer la perte ou le vol d'information concernant les utilisateurs du
rseau.
Il est d'usage de restreindre le nombre d'accs aux commutateurs, tant en ce qui

concerne le nombre physique de ces accs que le nombre de personnes ayant les
droits d'accs. Il est d'ailleurs frquent que le lieu mme d'hbergement des
commutateurs soit considr comme une donne sensible et confidentielle.
Dans le cas de la colocalisation de plusieurs commutateurs, il est d'ordinaire

conseill que l'ensemble des accs (interfaces, alimentation, accs logiques, etc.)
soient compltement distincts.
10.8.2.4. Interfaces du rseau

Les points les plus sensibles aux attaques dans un rseau sont les interfaces entre
les diffrents lments de ce rseau. Cela est d'autant plus vrifi que l'interface est
sans fil. Les protocoles comme les implmentations des rseaux sont en gnral
prvus de manire redondante de faon pouvoir remplacer une interface dfaillante
ou suspecte tout moment.
10.8.2.5. Les systmes de facturation et de gestion des utilisateurs

Les systmes de facturation et de gestion des utilisateurs permettent aux
oprateurs de facturer les services consomms par l'utilisateur. Il a t constat que
cette partie du rseau est d'autant plus sensible qu'elle est souvent sous-traite par
l'oprateur ou gre au sein mme de l'oprateur par des personnes extrieures ou
temporairement employes.
Diffrents types d'attaques peuvent tre organiss contre le systme de

facturation ou de gestion des abonns, de manire supprimer tout ou partie de
factures, appliquer des remises ou changer la nature du service factur.
Il revient aux oprateurs de grer la scurit des donnes de facturation. Ce

domaine propritaire reste extrieur aux considrations des standards (3GPP),
toutefois un groupe de travail de l'Association GSM travaille sur le sujet : le BARG
(Billing and Accounting Requirement Group). Il est conseill de ne pas concentrer
l'ensemble des fonctions de gestion du centre de facturation sur les mmes
personnes.
10.8.2.6. L 'interconnexion de rseaux - la maintenance

La gestion des lments du rseau UMTS doit pouvoir tre ralise distance.
Ce type d'opration est souvent ralis partir du rseau informatique de
l'oprateur, ce qui peut aussi reprsenter un risque significatif. La scurit du rseau
UMTS sera d'autant meilleure que celle du rseau de l'oprateur sera importante.
Il faut pourtant galement considrer :

- la sparation, au moins logique, des lments du rseau UMTS : les accs ne
doivent pas tre cumuls sur une machine ou par une personne ; diffrents niveaux
d'accs aux ressources doivent tre prvus ;
- les accs distance doivent tre scuriss contre l'coute et les attaques (le
rseau informatique de l'oprateur peut comporter pour cela des zones isoles,
l'accs est soumis des contrles d'accs systmatiques), les mots de passe doivent
tre stocks dans des zones scurises, rpondre des rgles prcises et tre
conjugus un blocage des ressources en cas de tentatives successives infructueuses
d'accs, un historique dtaill des accs doit tre tenu, des systmes de dconnexion
automatique (en cas de timeout, de coupure lectrique, etc.) ou manuels (fin de
session) sont impratifs, en cas d'accs via un autre rseau un systme de mot de
passe usage unique est le plus sr, la localisation mme des accs physiques est
une information sensible
Une fonction d'administration scurit doit exister pour grer l'ensemble des
donnes relatives aux accs du rseau UMTS. Cette fonction doit pour des raisons
de scurit tre clairement spare de la gestion de rseau UMTS en lui-mme.

L'administrateur doit pouvoir suivre en temps rel l'activit sur les lments du
rseau de chaque utilisateur.
10.9. Conclusion
La scurit du systme UMTS a nettement volu par rapport aux systmes de

deuxime gnration, tout en conservant l'lment cl du GSM qu'est l'utilisation
d'une carte puce pour l'authentification et la gnration de cls. La solidit du
systme est renforce grce aux progrs des technologies et des techniques de
cryptographie. La collaboration entre les pays permet par ailleurs de fixer les rgles
de la scurit et de la vie prive.
Ces volutions importantes ont permis de contrebalancer la fragilit croissante de

systmes dont l'architecture est de plus en plus ouverte, dans lesquels on trouve de
plus en plus d'interfaces qui peuvent tenter les pirates. La multiplication des services
demandeurs de scurit, l'introduction de systmes plus ouverts au sein desquels
l'oprateur n'est plus le seul fournisseur de services et l'interconnexion de rseaux
diffrents sont introduits en troisime gnration de manire scurise.
La quatrime gnration qui s'annonce comme la convergence de multiples

rseaux et le passage des systmes encore plus ouverts, imposera un fort challenge
la scurit.
10.10 Annexe : Rfrences
Note : au sein du 3GPP, les spcifications (TS, Technical Spcifications) sont les
documents normatifs, et les rapports (TR, Technical Report) sont des documents
informatifs, soit qu'il s'agisse d'une explication ou analyse de spcifications ou de
leur consquences, soit qu'il s'agisse d'une tude de faisabilit.
10.10.1. Bibliographie
[DAR 00] DAEMEN J., RIJMEN V., The Block Cipher Rijndael Smart Card Research and
Applications, LNCS 1820, J.-J. Quisquater et B. Schneier (dir.)., Springer-Verlag,
p. 288-296, 2000.
[DAR 01] DAEMEN J., RUMEN V., Rijndael, the advanced encryption standard Dr. Dobb 's
Journal, vol. 26, n 3, p. 137-139, 2001.
10.10.2. Spcifications - Standards
Documents maintenus par le 3GPP
[21.133] TS 21.133 3G Security; Security Threats and Requirements

[31.103] TS 31.103 ISIM Characterstics
[33.102] TS 33.102 3G Security; Security Architecture
3G Security; Cryptographie Algorithms
[33.105] TS 33.105
requirements
Lawful interception:
requi rement
[33.106] TS 33.106/7/8 architecture and functions
interface between core network and law agency
equipment
[33.120] TS 33.120 3G Security; Security Principles and Objectives
[33.203] TS 33.203 Access security for IP-based services
Generic Authentication Architecture (GAA),
Generic bootstrapping architecture
[33.220] TS 33.220/1/2
Support for subscriber certificates
Access to network application
Wireless Local Area Network (WLAN)
[33.234] TS 33.234
interworking security
Security of the Multimedia Broadcast / Multicast
[33.246] TS 33.246
Service
Feasibility Study on (U)SIM Security Reuse by
[33.817] TR 33.817 Peripheral
Devices on Local Interfaces
[33.900] TR 33.900 A Guide to 3rd Gnration Security
[33.901] TR 33.901 Criteria for cryptographie algorithm design process
[33.902] TR 33.902 Formai Analysis of the 3G Authentication Protocol
General Report on the Design, Spcification and
Evaluation of 3GPP Standard
[33.903] TR 33.903
Confidentiality and Integrity
Algorithms
Report on the Design and Evaluation of the M1LENAGE
Algorithm Set;
[33.909] TR 33.909
Deliverable 5: An Example Algorithm for the 3GPP
Authentication and Key Gnration Functions
[33.919] TR 33.919 Generic Authentication Architecture (GAA);
System Description
Spcification of the 3GPP Confidentiality and
Integrity Algorithms:
Document 1 : f8 and f9 spcifications
Document 2: KASUMI algorithm spcification
[35.201] TS 35.201/2/3/4/5/9 implementor's test data
Design test conformance data
MILENAGE spcification
example algorithm set for fl, fl*, f2, f3, f4, 5 and
f5*
Spcification of the 3GPP Confidentiality and
[35.209] TS 35.209
Integrity Algorithms
Lawful Interception requirements for GSM
TS 41.033
[41.033] TS 42.033 Lawful Interception; Stage 1
TS 43.033 Lawful Interception ; Stage 2
Documents maintenus par l'ETSI

Tlcommunications security; Lawful Interception (LI);
[LI1] TS 101 331 Handover interface for the lawful interception of
tlcommunications traffic
Tlcommunications security; Lawful
interception (LI)
[LI2] TS 101 671 Handover interface for the
lawful interception of
[LI3] TR 101 876 Interception (LI);
Description ofGPRS HI3
Interception (LI);
[LI4] TR 101 943 Concepts of Interception in a
Generic Network
Architecture
[LES] TR 101 944 Interception (LI);
Issues on IP Interception
Interception (LI);
[LI6] ES 201 158
Requirements for network
fonctions

Interception (LI);
[LI7] ES 201 671 Handover interface for the
lawful interception of
Autres documents
rjg^ j ^ Ce document gr par le Java Community
Process, voir
J S R 177
http://jcp.org/en/jsr/detail7id
=177
10.10.3. Sites Internet
[W3G] 3GPP http://www.3gpp.org/

http://www.etsi.org/
[WET] http ://portal.etsi.org/Portal_Common/home.as
ETSI
p (accs au pages du groupe
SAGE par exemple)
[WGA] GSM Association http ://www.gsmworld.com/
[WGP] GlobalPlatform http://www.globalplatform.org/
Accs aux informations concernant MISTY
[WMI] Mitsubishi http ://www.mitsubishi.com/
ghp J apan/m isty/index .htm
[WSA] SIM Alliance http://www.simalliance.org
http://www.openmobilealliance.org
les spcifications WAP/OMA sont disponibles
[WOM] Open Mobile Alliance
http://www.wapforum.org/
what/technical.htm
[WAS] Wassenaar arrangement http://www.wassenaar.org/
Glossaire
3G Rseau cellulaire de 3e Gnration

3G-GGSN GGSN spcifique l'UMTS
3GPP 3rd Gnration Partnership Project
3GPP2 3rd Gnration Partnership Project 2
3G-SGSN SGSN spcifique l'UMTS
8PSK 8 Phase Shift Keying
AAL ATM Adaptation Layer

AD Adjunct Adjunct
AES Advanced Encryption Standard
AF Assured Forwarding
AHP Amplificateur Haute Puissance
AI Acquisition Indicator
AICH Acquisition Indicator Channel
AKA Authentication and Key Agreement
ALCAP Access Link Control Application Part
AMD Acknowledged Mode Data (mode du protocole RLC)
ANM Answer Message
AP Access Preamble
AP-AICH Access Preamble Acquisition Indicator Channel
API Access Preamble Indicator
API Application Programming Interface
APN Access Point Name
ARQ Automatic Repeat reQuest
AS Access Stratum (contexte UTRAN)
AS Application Server
ASN.l Abstract Syntax Notation 1
ATM Asynchronous Transfer Mode

AUTN Authentication Token
AWGN Additive White Gaussian Noise
BCH Broadcast Channel
BCM Basic Call Manager
BCP Basic Call Process
BCSM Basic Call State Model
BCUSM Basic Call Unrelated State Model
BDFE Block Dcision Feedback Equaliser
BE Best Effort
BER Bit Error Rate
BGCF Breakout Gateway Control Function
BLE Block Linear Equaliser
BLER Block Error Rate
BMC Broadcast/Multicast Control
BPSK Binary Phase Shift Keying
BSC Base Station Control 1er
BSIC Base Station Identity Code
BTS Base Transceiver Station
CA Channel Assignment
CAI Channel Assignment Indicator
CAMEL Customized Applications for Mobile network Enhanced Logic
CAP CAMEL Application Part
CCAF Call Control Agent Function
CCC CPCH Control Command
CCF Call Control Function
CCPCH Common Control Physical Channel
CCTrCH Coded Composite Transport Channel
CD Collision Dtection
CD/CA-ICH Collision Detection/Channel Assignment Indicator Channel
CDI Collision Dtection Indicator
CDMA Code-Division Multiple Access
CEC Concatenated Extended Complementary
CGF Charging Gateway Function
CHV Card Holder Vrification (appel aussi PIN)
Glossaire 461
CID Channel Identifier

CM Connection Management
CP Connection Point
CPCH Common Packet Channel
CPH Call Party Handling
CPICH Common Pilot Channel
CQI Channel Quality Indicator
CRNC Controlling RNC (Radio Network Controller)
C-RNTI Cell Radio Network Temporary Identity
CS Call Segment (contexte rseaux intelligents)
CS Capability Set (contexte rseaux intelligents et CAMEL)
CS Circuit-Switching (contexte UMTS)
CSA Call Segment Association
CSCV Call Segment Connection View
CSD Circuit Switched Data (transmission)
CSE CAMEL Service Environment
CSI CAMEL Subscription Information
CSICH CPCH Status Indicator Channel
CUSF Call Unrelated Service Function
CV Connection View
CVS Connection View State
DCA Dynamic Channel Allocation
DCH Dedicated Channel
DFT Discrte Fourier Transform
DHCP Dynamic Host Configuration Protocol
DL Downlink
DNS Domain Name Server
DP Dtection Point
DPC Distributed Power Control
DPCCH Dedicated Physical Control Channel
DPCH Dedicated Physical Channel
DPDCH Dedicated Physical Data Channel
DRNC Drift RNC (Radio Network Controller)
DSCH Downlink Shared Channel
DTMF Dual Tone Multiple Frequency
DTX Discontinuous Transmission

DwPTS Downlink Pilot Time Slot
EAP Extensible Authentication Protocol
EDP Event Dtection Point
EDP-N Event Dtection Point Notification
EDP-R Event Dtection Point Request
EF Expedited Forwarding
EFR Enhanced Full Rate
EIR Equipment Identity Register
EP SCP Etsi Project Smart Card Platform
EQM Erreur Quadratique Moyenne
ETSI European Tlcommunications Standards Institute
FACH Forward Access Channel
FBI Feedback Information
FCSS Fast cell site selection
FDD Frequency-Division Duplex
FDMA Frequency-Division Multiple Access
FEA Functional Entity Action
FEC Forward Error Correction
FER Frame Error Rate
FFT Fast Fourier Transform
FIM-CM Feature Interaction-Call Manager
FSW Frame Synchronization Word
GGSN Gateway GPRS Support Node
GMM GPRS Moblility Management
GMSC Gateway Mobile-services Switching Centre
GPRS General Packet Radio Service
GPRS-CSI GPRS CAMEL Subscription Information
gprsSSF GPRS Service Switching Function
GPS Global Positioning System
GSM Global System for Mobile Communications
gsmCCF GSM Call Control Function
gsmSCF GSM Service Control Function
gsmSRF GSM Service Resource Function
gsmSSF GSM Service Switching Function
Glossaire 463
GSN GPRS Support Node

GTP GPRS Tunneling Protocol
GTP-C GTP Control Plane
GTP-U GTP User Plane
HDSL High-bit rate Data Subscriber Line
HLR Home Location Register
HPLMN Home PLMN
HS-DPCCH High Speed Dedicated Physical Control Channel
HS-DSCH High-Speed Downlink Channel
HS-PDSCH High Speed Physical Downlink Shared Channel
HSS Home Subsriber Server
HS-SCCH High Speed Shared Control Channel
HTML HyperText Markup Language
HTTP Hyper Text Transfer Protocol
IAM Interfrence d'Accs Multiple
ICH Indicator Channel
ICMP Internet Control Message Protocol
ICQ Systme de discussion I Seek You
I-CSCF Interrogating Call Session Control Function
IDFT Inverse Discrte Fourier Transform
IES Interfrence entre symboles
IETF Internet Engeneering Task Force
IM-CSI IP Multimedia Camel Subscription Information
IMEI International Mobile Equipement Identity
IMS IP multimdia Subsystem
IM-SSF IP Multimedia-Service Switching Function
IN Intelligent Network
INAP Intelligent Network Application Part
IN-SSM Intelligent Network Switching Manager
IP Intelligent Peripheral (contexte rseaux intelligents)
IP Internet Protocol
IrDA Infrared Data Association
ISDN Integrated Services Digital Network
ISIM Ims SIM
ISUP ISDN User Part
IT Intervalle de temps
ITU International Tlcommunication Union
J2ME Java 2 Mobile Edition
J2SE Java 2 Standard Edition
K Cl de l'utilisateur, correspond au Ki du GSM
KASUMI Algorithme de chiffrement bas sur MISTY ralisant les fonctions
f8 et f9
KVM K (for kilobyte) Virtual Machine (voir J2ME)
LLC Logical Link Control (GPRS)
LS Least Square
M3UA SS7 MTP3-User Adaptation Layer
MAC Mdium Access Control (contexte protocoles)
MAC Message Authentication Code (contexte scurit)
MAP Mobile Application Part
MBMS Multimedia Broadcast / Multicast Service
MCC Mobile Country Code
ME Mobile Equipment
MExE Mobile Execution Environment
MGCF Media Gateway Control Function
MGW Media Gateway
MIC Modulation par impulsions et codage
MM Mobility Management
MMS Mobile Multimedia Service
MMSE Minimum Mean Square Error
MNC Mobile Network Code
MO-SMS-CSI Mobile Originated Short Message Service CAMEL Subscription
Information
MPLS Multi Protocol Label Switching
MRF Media Resource Function
MS Mobile Station (terme GSM)
MSC Mobile services Switching Center
MSIN Mobile Subscriber Identity Number
MSRN Mobile Station Roaming Number
MT Mobile Termination
MTP Message Transfer Part
MTP3b Message Transfer Part 3 broadband
Glossaire 465
MT-SMS-CSI Mobile Terminated Short Message Service CAMEL Subscription

Information
MUI Mobile User Identifier
NAP Network Access Point
NAS Non Access Stratum
NAT Network Address Translator
NBAP Node B (Application Part)
NNI Network to Network Interface
NRT Non Real Time
NRZ Non remis zro
NSAPI Network Service Access Point Identifier
OBCSM Originating BCSM
OCCRUI Out of Channel Call Related User Interaction
OCCUUI Out of Channel Call Unrelated User Interaction
O-CSI Originating CAMEL Subscription Information
OS Operating System
OSA Open System Architecture
OSI Open System Interconnection
OVSF Orthogonal Variable Spreading Factor
P2P Peer-to-Peer
PC Point Code (contexte SS7)
PC Power Control (contexte rseaux cellulaires)
P-CCPCH Primary- Common Control Physical CHannel
PCH Paging Channel
PCPCH Physical Common Packet Channel
P-CSCF Proxy Call Session Control Function
PDA Personal Digital Assistant
PDCP Packet Data Convergence Protocol
PDN Packet Data Network
PDP Packet Data Protocol
PDSCH Physical Downlink Shared Channel
PDU Protocol Data Unit
PG Priode de garde
PIA Point In Association
PIC Point In Call
PICH Page Indicator Channel
PIN Personal Identification Number (appel aussi CHV)

PLMN Public Land Mobile Network
PN Pseudo Noise
PPP Point to Point Protocol
PRACH Physical Random Access Channel
PS Packet Switching (en UMTS)
PS Point smaphore (contexte SS7)
PSC Primary Synchronisation Code
P-TMSI Packet Temporary Mobile Subscriber Identity
PTS Point de transfert smaphore
PVC Permanent Virtual Circuit
QPSK Quadrature (ou Quaternary) Phase Shift Keying
RAB Radio Access Bearer
RACH Random Access Channel
RANAP Radio Access Network Application Part
RI Rseau intelligent
RLC Radio Link Control
RNC Radio Network Contrler
RNIS Rseau numrique intgration de services
RNS Radio Network Sub-system
RNSAP Radio Network Subsystem Application Part
RNTI Radio Network Temporary Identity
RRC Radio Resource Control
RSB Rapport signal bruit
RSI Rapport Signal sur Interference
RT Real Time
RTCP RTP Control Protocol
RTP Real Time Protocol
SAGE Security Algorithm Group of Experts
SAT SIM Application Toolkit
SCCP Signalling Connection Control Part
S-CCPCH Secondary Common Control Physical Channel
SCE Service Cration Environment
SCEF Service Cration Environment Function
SCF Service Control Function
Glossaire 467
SCH Synchronisation Channel

SCP Service Control Point
SCS Service Cration Server
S-CSCF Serving Call Session Control Function
SCTP Stream Control Transmission Protocol
SCUAF Service Control User Agent Function
SDF Service Data Function
SDP Service Data Point
SDP Session Description Protocol
SDSL Single-line Digital Subscriber Line
SDU Service Data Unit
SF Spreading Factor
SFN System Frame Number
SGSN Serving GPRS Support Node
SI Status Indicator
SIB Service Indpendant Building Block
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SIR Signal-to-Interference Ratio
SM Session Management
SMAF Service Management Agent Function
SMF Service Management Function
SMLC Service Mobile Location Centre
SMP Service Management Point
SMS Short Message Service
SMS-CSI Short Message Service CAMEL Subscription Information
SMS-GMSC Short Message Service InterWorking MSC
SMTP Simple Mail Transfer Protocol
SN Service Node
SNDCP Sub-Network Dpendant Convergence Protocol (GPRS)
SP Signalling Point (PS, en franais)
SRF Service Resource Function
S RNC Serving RNC (Radio Network Controller)
SS7 Signalisation smaphore n 7 (Signalling System 7)
ssc Secondary Synchronisation code
SSCF-NNI Service Spcifi Coordination Function for Network to Network

Interface
SSCOP Service Spcifi Connection Oriented Protocol
SSDT Site Selection Diversity TPC
SSF Service Switching Function
SSP Service Switching Point
STP Signalling Transfer Point
STTD Space Time Transmit Diversity
SVC Switched Virtual Circuit
TA Time Alignment
TBCSM Terminating BCSM
TBS Transport Block Set
TCAP Transaction Capabilities Application Part
TCP Transmission Control Protocol
T-CSI Terminating CAMEL Subscription Information
TCTF Target Channel Type Field
TD-CDMA Time Division Synchronous Division Multiple Access
TDD Time-Division Duplex
TDMA Time-Division Multiple Access
TDP Trigger Dtection Point
TDP-N Trigger Dtection Point Notification
TDP-R Trigger Dtection Point Request
TD-SCDMA Time Division-Space Code Division Multiple Access
TEB Taux erreur binaire
TEID Tunnel Endpoint IDentifier
TFCI Transport Format Combination Indicator
TFT Traffic Flow Template
TMSI Temporary Mobile Subscriber Identity
TNUP Transport Network User Plane
TPC Transmit Power Control
TRAU Transcoder/Rate Adaptation Unit
TrD Transparent Mode Data (mode du protocole RLC)
TRX Transceiver
TSTD Time Switched Transmit Diversity
TTI Transmission Time Interval
UDP User Datagram Protocol
Glossaire 469
UE User Equipment
UICC Universal Integrated Circuit Card
UL Uplink
UMD Unacknowledged Mode Data (mode du protocole RLC)
UMTS Universal Mobile Tlcommunications System
UNI User to Network Interface
UpPTS Uplink Pilot Time Slot
U-RNTI UTRAN Radio Network Temporary Identity
USAT Usim Application Toolkit
USIM Universal SIM
USSD Unstructured Supplementary Service Data
UTRA UMTS Terrestrial Radio Access
UTRAN UMTS Terrestrial Radio Access Network
VCI Virtual Channel Identifier
VGCS Voice Group Call Service
VHE Virtual Home Environment
VLR Visitor Location Register
VMSC Visited Mobile services Switching Center
VPI Virtual Path Identifier
W3C World Wide Web Consortium
WAE Wireless Application Environment
WAP Wireless Application Protocol
WCDMA Wideband Code Division Multiple Access
WiFi Wireless Fidelity
WIM WAP Identity Module
WLAN Wireless Local Area Network
WML Wireless Markup Language
XHTML eXtended HTML
ZF Zro Forcing
Index
3G-GGSN, 288-289, 290, 292, 310-

311,314,319 B
3G-SGSN, 284-285, 288-290, 292, BCCH, 79, 80,81,85,87- 89
29-295, 302-304, 307, 309-311, BCH, 76-77, 80, 85, 241, 257-258
313,315-319, 321
BCM, 348
A BCP, 345
BCSM, 344, 348-349, 350-354, 357,
A AL, 230, 231,269
359,
AAL5, 231, 232, 235, 243-244, 246,
BCUSM, 355
289
bearer, 72, 75, 237-238, 259-260,
accs alatoire, 69, 89, 179, 260
262, 285-286
Access Stratum, 236, 255, 286
Bearer Independent Protocol, 403,
AICH, 69, 89, 90 412,414
ALCAP, 237, 239, 242, 260, 263 bearer UMTS, 327
AMC, 97, 98 BG, 291,322
AMR, 75, 76 B-ISDN, 229, 269
AP-AICH, 69 BPSK, 22, 25-26
API, 386, 391, 395, 399, 400, 405, BSC, 216-218, 273,277
407,419
BTS, 107,216-218
APN, 281,297-298, 324,332
burst, 115-122, 145
appel, 62, 68, 142, 188, 222, 226,
231,236, 257, 259,305-306 C
ATM, 215, 219, 220, 228-230, 232,
234, 235, 237, 240, 242-244, 248- CAMEL, 294, 310, 337, 339-341,
251, 258-270, 283, 287, 289, 326, 346, 355, 358-374, 377, 380-381,
329,333,335 407
attachement, 294 canal AWGN, 27, 32, 34, 108
AWGN, 27, 32, 34, 108, 122, 125, canal smaphore, 225, 232
135 CAP, 341, 361, 364, 371-377, 382,
Care Of Address, 322 CS (Call Segment), 347, 349, 350

CCAF, 346 CS (interface Iu-CS), 242, 248
CCCH, 79,81 CS (domaine), 287, 305-306
CCF, 342, 346-349, 353-355, 356- CSA, 349-350, 356
357,359, 361-362,381 CSI, 362, 363,371,374
CCITT n7, voir SS7 CSCV, 344, 349, 3 5 0 , ^ 1 , 354, 356
CCTrCH, 73
CSICH, 69
CD/CA-ICH, 69,454
CTCH, 80,81
CDMA, 19, 39, 42, 44, 48-51, 53, 56,
69, 98, 105-108, 111-113, 121, D
131-132, 141, 150,-151, 153-155,
157-158, 160, 165, 168, 171, 177, DCA, 110, 113, 142-144, 252, 256,
185, 187-190, 192-193, 197, 202, 455
206-207, 209-212 DCCH, 80, 82-83, 85, 262
CELL_DCH, 91 DCH, 75-77, 80-82, 99, 241-258,
CGF, 292 260, 262, 264, 266
chip, 29-30, 34-35, 38-39, 41- 42, 46- dtachement, 303, 304
47,49-50, 86, 113, 118, 123 dtection conjointe, 105, 107, 109,
CID,231-232, 237 111,121, 132, 135, 138-141
classes de services, 227, 231, 326, DiffServ, 326, 329,331-332

329,331-332 DNS, 291,298,316
code d'embrouillage, 48, 56, 64, 67, DP, 353-354, 356-358, 370-372, 374,
69-70, 85, 110, 116, 119 375-378
codes orthogonaux, 109, 111 DPCCH, 58, 62-63, 69, 82, 172-173,
contexte PDP, 97, 276-278, 289, 297, 175-177
299, 307, 309-316, 321, 324-325, DPCH, 58, 61, 63, 77, 81, 173-174,
327,330-331 179,180
contexte (activation), 281-282, 298, DPDCH, 58, 62-64, 76, 82-83, 172-
300-311,314,316 173,175, 177
corrlateur, 34, 36-37, 121, 128 D-RNC, 222
couche ATM, 230, 243, 245, 250 DSCH, 77, 80, 82, 85, 97-98, 101,
couverture, 94, 102, 112, 187, 188- 241,245,253
189, 192, 193, 207, 209-210, 266 DTCH, 80, 82-83
CPICH, 67, 86-88, 96
Critres S et R, 87-89 E
C-RNTI, 80,81,262 EAP, 391,415-416, 444

CS (Capability Set), 342-344, 354- EAP AKA, 395, 420,444
356, 360 EDP, 353-354, 356-358
/
Index 473
EFR, 74 GTP-U, 244, 250, 286, 289, 290,

galiseur, 135, 136 292-293,309,311,313,314
talement de spectre, 19, 21, 27, 29,
H
32-33,35,37-39, 44, 190, 221
Etats PMM, 301 Hadamard, 39-41,43, 134
handover, 53, 55, 91-96, 113, 144,
F 168, 171, 173, 209, 211, 216,
"'222-223, 236, 239, 255-256, 267,
FACH, 62, 76-77, 80-82, 91, 241,
317, 321
245, 256-260, 262
hard handover, 91, 94, 266, 317, 321
facteur d'activit, 192, 197-198,213
HLR, 274-275, 277-278, 284, 289,
facteur d'augmentation de bruit, 194,
291, 294-295, 299, 301-303, 306,
197, 203
310,316,319, 327, 330, 360,362,
facteur d'talement, 29, 31, 33, 39, 363, 371, 372, 380, 383, 426,
46, 53, 60, 62, 64, 67, 69, 82, 98- 436-437, 448,451-452
99, 106, 107, 110-111, 159, 183
Home Agent, 322
facteur de charge, 194-197, 199, 201,
HSDPA, 61. 96-102, 113,253
204, 205-206, 209
HS-DPCCH, 97, 99
FBI, 63, 172
HS-DSCH, 97-99, 101, 241-242, 245,
FCSS, 100-101
253
FEA, 345, 346
HS-PDSCH, 97
format de transport, 53, 64, 70-75,
HSS, 380-381
77, 78
I
G
I-CSCF, 380-381
GGSN, 277-282, 284, 289, 290-292,
296, 298-299, 304, 307-316, 319, IMS, 334, 336, 380-381, 395, 413,
321-322, 324-325, 327, 330, 362, 441
372,374-375,381 IN, 340, 348,353,365
GMM, 371-372 INAP, 344, 347-349, 355, 356-357,
GMSC, 358, 363, 380 359
GLR, 284 IP, 98, 212, 215, 219, 224, 234-235,
237, 244, 246, 250-252, 258, 271-
GPRS, 355, 358, 360, 362-364, 368,
272, 275-277, 279, 280-282, 287,
370-377,381
289-291, 296-299, 309, 311-315,
GSN, 277,288-291,319, 460 322-325, 329, 330-338, 394-395,
GTP, 238, 244, 250, 279, 280-281, 413,439,441,455-456
286, 289-290, 292-293, 308-309, IPv6, 55, 234, 270, 296, 299, 307,
311,319, 321,374-375 309-310, 313-314, 322-334, 336,
GTP-C, 293 338
IS-95, 32, 45-46, 48, 50-51, 92, 153 MGW, 334, 380 V
ISIM, 391,395,415,437, 451 midambule, 114-115, 121-125, 128-
ISUP, 226, 232, 305, 356-357, 359, 129,139-140
365, 382 mode compress, 60, 94, 95, 172-173
lu, 220, 236-238, 242-244, 247, 250- modulations, 20, 25, 57, 116
251, 259, 263, 265, 268-269, 286- MRF, 380
289, 294-295, 329, 334
MSC, 340, 358, 360-363, 374, 381,
Iub, 96, 100, 145, 184, 220, 237-238,
MSRN, 306
245-246, 250-251, 255, 259, 269
MT, 324,384-385,414
Iu-Cs, 220, 238, 242-244, 259
MTP, 225-227, 232, 234-235, 243,
Iu-Ps, 220, 243-244
246, 250, 269
J MTP3b, 232, 235, 243, 246, 250, 269
multicode, 106, 107, 110-111
J2ME, 390, 397-400, 401, 406, 411
multitrajet, 27-29, 36-38, 42, 131-
J2SE, 390, 397, 406
132, 138, 147, 149
Java, 390, 392, 397-401, 406, 4011,
412,419-421,445-446,456 N
Java Card, 397-401, 412, 419, 420 NAS, 236, 237-238, 243, 245, 247,
255, 260-262, 286
L
NAT, 290, 326
leg, 349-350, 352, 354, 359 Near Far Effect, 107
node B, 218, 221
M Noise Rise, 194, 203,213
M3UA, 235, 244, 246, 250-251, 270
Non-Access Stratum, voir NAS
MAC (couche), 53, 55-56, 59, 77-81,
98, 100-101, 105, 240, 241-242, NSAPI, 293,311-315
245, 247, 252, 262, 268
O
MAC (scurit), 428, 431-436, 438
MAP, 228, 273, 318-319, 372, 377, OBCSM, 350, 352, 364,
382 OMA, 409, 412, 416, 418, 420, 440,
ME, 388-389, 419, 445 456
Message Transfer Part, 225, 232, 270 OSA, 341, 380, 382, 383, 384, 385,
403-404
mesures, 55, 67, 78, 82, 85-86, 89,
91-92, 94-95, 96, 101, 110, 143, OVSF, 43-44, 48, 56, 58, 67, 69-70,
145, 172, 176, 179, 216, 246, 110, 113,222, 260
256-257, 264, 295,301
P
MExE, 341,383,405-407,418
MGCF, 380 PCCH, 79-80
Index 475
P-CCPCH, 67-68, 76-77, 85, 114, RACH, 64, 69, 77, 80,-82, 90, 120,
116 145, 150, 241,245,256, 258-260,
PCH, 77, 80, 241, 245, 257-258 262
PCPCH, 69, 175-176 relocalisation, 224, 258, 267, 268,
307,317, 321
P-CSCF, 380-381
rponse impulsionnelle, 28, 121-123,
PDA, 397, 408-409, 423
127,133-134, 146-147, 149
PDN, 275-277, 289-290, 296-297,
rseau de transport, 219, 221, 232,
307,310-311,313
235-240, 242-245, 247, 250-251,
PDP, 97, 276, 277-278, 282, 293- 258, 276, 287, 290
294, 302, 304, 307, 309-311,313-
rseau smaphore, 225-226, 244, 287
316,319, 321,324
RNC, 54, 56, 82, 91-92, 96, 98, 100-
PDSCH, 60-61,77, 173
101, 142, 145-146, 171-172, 218-
PIA,355, 368 224, 237-239, 241-243, 245-258,
PIC, 353, 260, 262-264, 267, 285, 288-290,
PICH, 68, 77 292,300-302, 307, 309,317-318
Pilot, 58, 63, 65, 67 RNSAP, 246, 251,265,268
PIN, 394, 403,427 S
PN, 108-109
SAT, 341, 383, 391, 398, 399, 415
PPP, 276, 296, 307, 309, 328
SCCP, 226-227, 233, 235, 238, 243-
PRACH, 64-65, 77, 89-90, 114-115,
244, 246, 250-251,260
176, 179
SCEF, 347
PS (Packet Scheduling), 97, 101
SCF, 342, 346-349, 352-354, 356,
PS (Point smaphore), 225-226
357-359, 361-364, 371-372, 374,
PS (Interface Iu-PS) 249-252 376-377,380-381
PS (domaine) 284, 287-289, 291, SCH, 65-67, 84-95, 113-114, 116,
295-296, 301-302, 307,317 201,210-211
PTS, 225 SCS, 382-384
PVC, 219, 228 S-CSCF, 380-381
SCTP, 235, 244, 246, 250-251, 270
Q
squence d'apprentissage, 114, 119,
QPSK, 20, 22, 25-26, 29, 32, 57, 98- 122
99,113
SCUAF, 347
quadrature, 19, 22, 24-26, 62, 82, 98 SDF, 347, 356, 357
SDP, 378, 380
R
SF, 60, 63,83,99, 106, 111, 113
RAB, 238-239, 243, 263-264, 267-
268, 286, 290, 306-307, 311,313, SGSN, 277-282, 284, 287-290, 292,
315 294, 298, 301-303, 308-311, 316,
319-322, 325, 331, 355, 360, 362- taxation, 277, 282, 289, 310-311
363, 368, 370, 371-372, 374-377, TBCSM, 352, 356-357, 359, 365,
381
367, 370
SIB, 345-346
TCAP, 227-228
SIM, 274, 389, 393-395, 399-401, TCP, 96, 234-235, 280, 289, 290,
403, 419-420, 426, 431, 440-441, 293,322, 378
443-444, 447
TDD, 53, 84, 94-96, 105-108, 110-
SIP, 333-334, 341, 377, 378, 379, 114, 116-118, 120-122, 129, 130-
380, 385 131, 141-146, 148, 150-151, 154,
slot, 56-58, 60, 62, 65-67, 69, 90, 170, 179-182, 184-185,317
173-176, 178, 181-182
TDP, 353-355, 357-358, 363
SM, 374, 375,
TD-SCDMA, 112, 118
Smartphone, 390-391,397
TE, 324, 384-385, 388, 445
SMF, 347
TEID, 308,312
SMLC, 295
TFT, 314
SMS, 360, 374, 375, 376, 377, 378, TPC, 58-59, 63-64, 117, 170, 172,
SMS-CSI, 363, 375 174-175, 177-178
SMTP, 378 transport bearer, 237, 259, 260, 262
soft handover, 91-93, 100, 168, 171- TRAU, 217, 287
173, 175, 195, 209, 222-223, 264- TRX, 216
267
SRF, 347, 356, 358-359, 361-362 tunnel GTP-U, 309-311, 313, 314
S-RNC, 222
U
SS7, 225-226, 235, 246, 270, 277,
UDP, 234, 238, 250-251, 280, 289,
291
293,311,314,378
SSCF-NNI, 232, 243-244, 246 UE, 54, 78, 81, 87, 101-102, 121,
SSCOP, 232, 243-246, 269 171, 174, 176, 179, 184,388-389
SSF, 346-349, 353-359, 361, 362, UICC, 388-392, 395, 401, 403, 415,
364, 371,374,376,381 426-427,434, 436-437, 442, 444
strate d'accs, 236 UMTS Bearer, 285
strate de non-accs, 236-237 USAT, 402, 407,419
Symbian, 390, 397, 399,420 USIM, 302, 393-395, 399, 419, 426,
symbole, 20-21, 23-26, 29, 32, 37-39, 430, 434,440-441, 443, 446-448
57, 70, 98, 109, 117, 123, 136
USSD, 360, 363
SyncML, 400, 409, 420
V
T VCI, 228
TA, 118
Index 477
VHE, 294, 341, 385, 388, 407-408, W

419
WAE, 397,400, 402, 406
VLR, 362-363, 380-381
Walsh, 39-44, 48, 49, 69
VMSC, 358
WAP, 274, 298, 338, 390, 397, 399-
voie en phase, 19, 22, 24-26, 57, 64, 404, 402, 404, 406, 409, 412, 416,
98 418, 420, 440
voie en quadrature, 19, 22, 24-25, 57, WML, 400, 404
64
VPI, 228
CET OUVRAGE A T COMPOS PAR
HERMS SCIENCE PUBLISHING LTD ET
ACHEV D'IMPRIMER PAR L'IMPRIMERIE
FLOCH M A Y E N N E EN M A R S 2005.
DPT L G A L : M A R S 2 0 0 5 .
N D ' I M P R I M E U R : 6 2 6 4 6 .

Umts PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Umts PDF

Transféré par

Droits d'auteur :

Formats disponibles

Principes et volutions de l'UMTS

sous la direction de Xavier Lagrange

TRAIT I C 2 INFORMATION - C O M M A N D E - COMMUNICATION

Le trait Information, C o m m a n d e , C o m m u n i c a t i o n rpond au besoin

Conu volontairement dans un esprit d'change disciplinaire, le trait IC2

C h a q u e ouvrage prsente aussi bien les aspects f o n d a m e n t a u x

Les savoirs, thories et mthodes rassembls d a n s chaque ouvrage ont

Chapitre 1. Introduction l'talement de spectre 19

Chapitre 2. L'interface radio UTRA-FDD 53

2.9.3. Accs (sur PRACH) 89

Chapitre 3. Le mode UTRA-TDD et ses performances 105

3.5. Allocation dynamique des ressources 141

Chapitre 4. Le contrle de puissance dans l'UMTS 153

Chapitre 5. Couverture d'un rseau cellulaire CDMA 187

5.3. Estimation simple de la capacit d'un rseau cellulaire CDMA 192

Chapitre 6. Le rseau d'accs UTRAN 215

6.1. Architecture gnrale 215

6.6.2. Couche RLC 253

Chapitre 7. Le cur de rseau UMTS 271

7.1 Introduction 271

7.7.2. Evolutions prvisibles de la Release 5 334

Chapitre 8. Les architectures de services de l'UMTS 339

Chapitre 9. Terminal mobile et environnements d'applications 387

Chapitre 10. Scurit du systme UMTS 423

10.3.1. Parades - Protection 438

Introduction l'talement de spectre

L'UMTS (Universal Mobile Tlcommunications Systems) doit permettre une pa-

L'talement de spectre consiste transmettre une information sur un signal occu-

Chapitre rdig par Xavier L A G R A N G E .

-2,5 -2 -1,5 -1 -0,5 0 0,5 1 1,5 2 2,5

1.2. Rappels de communication numrique

1.2.1. Principes des modulations numriques

1.2.1.1. Transmission d 'une suite de symboles

Pour une transmission numrique, on met l'information par groupes d'lments

Figure 1.2. Transmission d'un symbole

1.2.1.2. Ecriture sous forme relle d'un signal modul

m(t) = 9 (t) cos (27rj c t + 2irra/M + <p) [1.21

o <p est la phase l'origine des temps.

La fonction g dsigne une fonction d'nergie finie Eg. La fonction g s'annule

r g(t) = jJTs Si \t\ < Ts/2

prenant <p = 0 et la fonction crneau pour g. Il s'agit de la modulation BPSK (Binary

1.2.1.3. Ecriture sous forme complexe d'un signal modul

8m(t) = (s (;t) ej(^fct+2nm/M+^ [M]

o j dsigne le nombre imaginaire tel que j2 = 1 et dsigne la partie relle

Sm{t) = (ej2/M+i*g (t) ej27rfct) [1.5]

Cette criture en notation complexe fait apparatre que la transposition la fr-

1.2.1.4. Ecriture en phase et en quadrature d'un signal modul

sm(t) = cos (2irm/M + ip) g (t) cos (27rf c t)

sm(t) = cos (mn/2 + TT/4) yJ~/Ts cos ( 2 ? r f c t )

- sin (ra7r/2 + tt/4) YJEG/TS sin (2?vf c t)

1.2.1.5. Energie d'un symbole et d'un bit

fi(t) = xl~g(t) cos (2nfct) [1.7]

h (t) = -xl^-g(t)sm(2<Kfct) [1.8]

En utilisant les formules trigonomtriques :

Les deux signaux / i e t sont donc orthogonaux et d'nergie 1. L'nergie du signal

Posons Es = Eg/2. Le paramtre Es reprsente l'nergie du signal sm (t) utilis

avec, dans le cas d'une modulation de phase M tats :

Le premier signal est appel signal en phase et le deuxime signal en quadrature. Il

avec / (t) = h W " 3h W = y f f g d ( t ) exp (j2tt/ c ^). La fonction / (t) a tou-

EXEMPLE - Dans le cas de la B P S K , on utilise seulement la voie I. Un symbole cor-

Figure 1.3. Modulations BPSK et QPSK

1.2.2. Modle de transmission en bande de base

Dans le modle de transmission considr, la dernire tape l'mission consiste

Srecu(t).PN(t - TQ) = S(t - R0).PN{t - R0).PN{t - r 0 ) [1.35]