Principes Et Évolutions de l'UMTS

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 SOUS
INFORMATION - C O M M A N D E - COMMUNICATION
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 ENST Paris Loutfi
ENST MARTINS
NUAYMI
Bretagne Rennes Sami T A B B A N E Sup'Com Tunis Tunisie
Table des matires
Chapitre 1. Introduction l'talement de spectre

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

X a v i e r LAGRANGE et S a m i TABBANE
53 54 54 54 56 56 56 58 58 58 60 62 62 64 65 65 67 67 68 69 69 69 69 70 70 71 73 74 76 77 79 80 81 82 82 84 84 84 85
2.1. Introduction 2.1.1. Architecture matrielle de l'UMTS 2.1.2. Architecture en couches 2.2. Caractristiques gnrales de la couche physique de l'UTRA-FDD . . 2.2.1. Caractristiques principales de l'UTRA-FDD 2.2.2. Trame de base 2.2.3. Modulation 2.3. Canaux physiques de donnes 2.3.1. Transmission descendante sur canal ddi (DPCH) 2.3.2. Canal physique descendant partag (PDSCH) 2.3.3. Canal de diffusion de donnes (S-CCPCH) 2.3.4. Transmission montante sur canal ddi ? 2.3.5. Canal d'accs PRACH 2.4. Canaux physiques de contrle 2.4.1. Canaux de synchronisation P-SCH et S-SCH 2.4.2. Canal pilote CPICH 2.4.3. Canal de diffusion des informations systme (P-CCPCH) 2.4.4. Canaux d'indication de paging (PICH) 2.4.5. Canal d'acquittement de prambule (AICH) 2.4.6. Autres canaux physiques 2.5. Principes des chanes de transmission 2.5.1. Chane de transmission sur la voie descendante 2.5.2. Chane de transmission sur la voie montante 2.6. Gestion de format de transport 2.6.1. Notion de format de transport 2.6.2. Combinaison de formats de transport 2.6.3. Variation dynamique des combinaisons de format de transport. . 2.6.4. Canaux de transport 2.7. Couche MAC 2.7.1. Fonctions de la couche MAC 2.7.2. Canaux logiques 2.7.3. Format des PDU de niveau MAC 2.7.4. Mode circuit et mode paquet 2.8. Synthse sur les diffrents canaux de l'UMTS et exemples 2.8.1. Exemple de canaux de donnes 2.8.2. Canaux physiques, de transport et logiques 2.9. Procdures radio 2.9.1. Mcanisme de recherche de cellule 2.9.2. Veille sur une cellule
Table des matires
11
2.9.3. Accs (sur PRACH) 2.9.4. Gestion du handover 2.10. Transmission de donnes haut dbit (HSDPA) 2.10.1. Canaux logiques et physiques pour le support du HSDPA . . . . 2.10.2. Codage et modulation adaptatifs (AMC) 2.10.3. Technique HARQ 2.10.4. Fast cell site selection (FCSS) 2.10.5. Squencement des paquets 2.10.6. Contraintes au niveau du nud B et des terminaux 2.11. Conclusion 2.12. Rfrences Chapitre 3. Le mode UTRA-TDD et ses performances Bruno JECHOUX 3.1. Philosophie de l'UMTS-TDD * 3.1.1. Effet proche-loin 3.1.2. Capacits du canal en UTRA-TDD et en UTRA-FDD 3.1.3. Gestion de l'interfrence extra-cellulaire 3.1.4. Facteur d'talement variable et multicode 3.1.5. Limitations du mode TDD 3.2. Introduction la norme : TD-CDMA et TD-SCDMA 3.2.1. Caractristiques d'UTRA-TDD 3,84 Mchips 3.2.2. Canaux physiques 3.2.3. Procdures de la couche physique 3.2.4. Caractristiques d'UTRA-TDD 1,28 Mchips 3.2.5. Procdures spcifiques du 1,28 Mchips TDD 3.3. Estimation de canal multi-utilisateur 3.3.1. Description du problme 3.3.2. Modlisation 3.3.3. Les estimateurs de canaux : estimateur maximum de vraisemblance/filtrage adapt 3.3.4. Choix des midambules 3.3.5. Mise en uvre de l'estimateur de canal maximum de vraisemblance 3.3.6. Performances de l'estimateur de canal maximum de vraisemblance 3.4. Dtection conjointe 3.4.1. Description du problme, modlisation 3.4.2. Critres de rsolution du systme d'quations linaires 3.4.3. Performances de la dtection conjointe 3.4.4. Rduction de la complexit de la dtection conjointe
89 91 96 97 98 100 100 101 101 102 102 105 105 107 108 110 110 111 112 112 114 117 118 120 121 121 122 125 126 128 129 131 132 135 138 139
12
3.5. Allocation dynamique des ressources 3.5.1. Allocation des ressources aux cellules (DCA lente) 3.5.2. Allocation des ressources aux services (DCA rapide) 3.6. Synchronisation du rseau (3,84 Mchips TDD) 3.6.1. Prsynchronisation par le rseau 3.6.2. Synchronisation fine par horloge de rfrence (de type G P S ) . . . 3.6.3. Mcanisme de synchronisation fine 3.7. Annexe : modlisation du canal radio mobile 3.8. Bibliographie Chapitre 4. Le contrle de puissance dans l'UMTS Loutfi NUAYMI 4.1. Introduction 4.2. Prsentation du modle et formalisation du problme 4.2.1. Capacit et contrle de puissance dans un rseau cellulaire CDMA 4.2.2. Classification des mthodes de contrle de puissance proposes . 4.3. Contrle de puissance et autres fonctions de la gestion des ressources radio 4.3.1. Accs et contrle d'admission 4.3.2. Respiration de cellules 4.3.3. Contrle de puissance et soft handover 4.4. Le contrle de puissance dans les systmes 3G 4.5. Contrle de puissance en UTRA-FDD 4.5.1. Principes gnraux 4.5.2. La voie montante ( uplink ) 4.5.3. La voie descendante (downlink) 4.6. Contrle en UTRA-TDD 4.6.1. Rappels sur UTRA-TDD 4.6.2. La voie montante ( uplink ) 4.6.3. La voie descendante {downlink) 4.6.4. Frquences de mise jour du contrle de puissance de la voie descendante de UTRA-TDD 4.7. Contrle de puissance dans la proposition cdma2000 4.8. Imperfection du contrle de puissance 4.9. Bibliographie Chapitre 5. Couverture d'un rseau cellulaire CDMA Loutfi NUAYMI 5.1. Prsentation du problme 5.2. Modle utilis
141 143 143 144 145 145 145 149 150 153 153 154 157 160 165 165 166 168 168 170 170 173 176 179 179 179 181 181 182 183 184 187 187 190
Table des matires
13
5.3. Estimation simple de la capacit d'un rseau cellulaire CDMA 5.4. Dfinitions et relations utiles pour la liaison uplink 5.4.1. Dfinitions 5.4.2. Relations utiles 5.5. Dfinitions et relations utiles pour la liaison downlink 5.5.1. Dfinitions 5.5.2. Relations utiles 5.6. Algorithme de prvision de la couverture d'un rseau CDMA par calcul itratif des charges des cellules 5.7. Dtails supplmentaires sur l'algorithme de calcul des charges 5.7.1. Imperfection du contrle de puissance 5.7.2. Interfrence de canaux adjacents 5.7.3. Sectorisation 5.7.4. Soft handover 5.8. Conclusion et discussion 5.9. Bibliographie * 5.10. Annexe : notations utilises dans ce chapitre Chapitre 6. Le rseau d'accs UTRAN
X a v i e r LAGRANGE
192 193 193 195 202 203 204 207 208 208 209 209 209 210 210 212 215 215 215 218 224 224 228 234 236 236 237 238 239 240 240 242 245 246 247 250 252 252
6.1. Architecture gnrale 6.1.1. Rappel sur le rseau d'accs de GSM 6.1.2. Elments du rseau d'accs UTRAN 6.2. Rappels sur les architectures en couches des rseaux 6.2.1. Signalisation smaphore 6.2.2. Architecture en couches d'un rseau ATM 6.2.3. Rseaux IP 6.3. Principes gnraux de l'architecture en couches dans UTRAN 6.3.1. Strates d'accs et de non-accs 6.3.2. Notion de support de transport (transport bearer) 6.3.3. Notion de support d'accs radio (RAB, Radio Access Bearer) . . 6.3.4. Les diffrents plans 6.4. Pile de protocoles de l'UTRAN avec un rseau de transport ATM . . . 6.4.1. Interface Uu 6.4.2. Interfaces lu 6.4.3. Interface Iub 6.4.4. Interface Iur 6.4.5. Synthses des piles de protocoles 6.5. Pile de protocoles de l'UTRAN avec un rseau de transport IP 6.6. Prsentations des protocoles sur l'interface radio 6.6.1. Couche MAC
14
6.6.2. Couche RLC 6.6.3. Couche RRC 6.7. Exemples de procdures de signalisation 6.7.1. Etablissement d'une connexion RRC et son utilisation 6.7.2. Libration d'une connexion RRC 6.7.3. Etablissement d'une connexion RRC sur canaux FACH-RACH . 6.7.4. Etablissement d'un RAB 6.7.5. Libration d'un RAB 6.7.6. Gestion de la macrodiversit {soft handover) 6.7.7. Procdures de relocalisation 6.8. Bibliographie Chapitre 7. Le cur de rseau UMTS
J e a n - M a r i e BONNIN
253 255 258 259 261 262 263 264 264 267 269 271 271 273 273 275 283 284 285 287 288 292 294 295 296 296 300 302 305 307 316 317 321 322 326 326 328 331 332 333
7.1 Introduction 7.2. Cur de rseau en GSM et GPRS 7.2.1. Architecture du rseau GSM avant le GPRS 7.2.2. Cur de rseau GPRS : un premier pas vers l'UMTS 7.3. Architecture du cur de rseau en Release 99 7.3.1. Services offerts par le cur de rseau 7.3.2. Principaux concepts 7.3.3. Entits du domaine circuit 7.3.4. Entits du domaine paquet 7.3.5. Architecture en couches 7.3.6. Entits communes aux deux domaines 7.3.7. Intgration des domaines PS et CS 7.4. Gestion des appels et des sessions 7.4.1. Services IP proposs aux utilisateurs 7.4.2. Etats de fonctionnement d'un mobile 7.4.3. Attachement aux domaines PS et CS 7.4.4. Gestion des appels du domaine CS 7.4.5. Gestion des sessions du domaine PS 7.5. Gestion de l'itinrance 7.5.1. Gestion de la mobilit 7.5.2. Gestion de la mobilit inter rseau 7.5.3. Interaction avec MobileIPv4 7.6. Gestion de la qualit de service 7.6.1. Les classes de services dfinies 7.6.2. Une architecture complte 7.6.3. Exemple de mise en uvre dans le cur de rseau paquet 7.7. Evolution vers un cur de rseau tout IP 7.7.1. Evolutions de la Release 4
Table des matires
15
7.7.2. Evolutions prvisibles de la Release 5 7.8 Conclusion 7.9. Bibliographie Chapitre 8. Les architectures de services de l'UMTS
P h i l i p p e MARTINS
334 335 337 339 339 339 341 341 341 341 342 344 345 355 358 358 358 361 362 364 364 366 369 370 370 371 373 374 374 376 376 376 379 381 381 381 382 383 384
8.1. Historique de l'volution des services dans les rseaux radio-mobiles . 8.1.1. Des services supplmentaires CAMEL 8.1.2. Evolutions vers VHE et OSA 8.1.3. Evolutions vers IP 8.2. Rappels sur les rseaux intelligents 8.2.1. Notion de segment d'appel 8.2.2. Evolution et structure des standards 8.2.3. Le modle conceptuel du rseau intelligent 8.2.4. Le plan fonctionnel rparti * 8.2.5. Exemples de services rseau intelligent 8.2.6. CAMEL et les rseaux intelligents 8.3. Prsentation de CAMEL 8.3.1. Diffrentes phases de CAMEL 8.3.2. Architecture fonctionnelle 8.3.3. Les marques CAMEL 8.4. CAMEL et le domaine circuit 8.4.1. Les automates CAMEL phase 3 du domaine circuit 8.4.2. Evolution des automates en phase 4 8.5. CAMEL et le domaine paquet 8.5.1. Automate d'attachement-dtachement GPRS 8.5.2. Exemple d'activation de service 8.5.3. Automate de contexte 8.5.4. Exemple de service sur acfivation d'un contexte 8.6. CAMEL et les changes de SMS 8.6.1. CAMEL phase 3 et les envois de SMS 8.6.2. CAMEL Phase 4 et la rception de SMS 8.7. CAMEL phase 4 et le sous-systme IP multimdia 8.7.1. Introduction SIP 8.7.2. SIP et le sous-systme IP multimdia 8.7.3. CAMEL phase 4 et le sous-systme IP multimdia 8.8. Prsentation d'OSA 8.8.1. Introduction 8.8.2. Services apports par OSA 8.8.3. Typologie des interface OSA 8.9. Bibliographie
16
Chapitre 9. Terminal mobile et environnements d'applications Paul JOLIVET 9.1. Introduction 9.2. L'quipement utilisateur en 3G 9.2.1. L'quipement mobile (ME) 9.2.2. La carte puce (UICC) et ses applications 9.2.3. Le rapport de force terminal-carte 9.3. Environnements propritaires - environnements standards 9.3.1. Diffrentes ressources pour diffrentes applications 9.3.2. Les diffrents environnements 9.3.3. Interfonctionnement des environnements 9.3.4. Les services d'Internet Mobile 9.3.5. L'approche standard des environnements existants 9.3.6. L'approche offre de services en packages 9.4. Virtual Home Environment * 9.5. Le tlchargement 9.5.1. Les applications du tlchargement 9.5.2. Synchronisation 9.5.3. Fonctionnalits lies au tlchargement d'applications 9.5.4. Environnements applicatifs et tlchargement 9.5.5. Supports de communication du rseau 3G 9.6. Conclusion 9.7. Annexes 9.7.1. La standardisation ct terminaux 9.7.2. Rfrences
387 387 388 389 392 395 396 397 397 400 404 405 406 407 408 408 409 410 411 412 414 415 415 418
Chapitre 10. Scurit du systme UMTS Paul JOLIVET 10.1.Introduction 10.1.1. Exemples d'attaques sur un rseau mobile 10.1.2. Mcanismes de scurit 10.2 Principes de la scurit en UMTS 10.2.1. Les lments matriels lis la scurit 10.2.2. Identit sur le rseau UMTS 10.2.3. Identification de l'utilisateur 10.2.4. Lignes directrices des algorithmes d'authentification 10.2.5. Authentification en UMTS 10.2.6. Intgrit des messages 10.2.7. Chiffrement des donnes 10.2.8. Aspects protocolaires 10.3. Les attaques possibles - Les protections
423 423 423 424 425 426 426 427 428 430 432 433 436 438
Table des matires
17
10.3.1. Parades - Protection 10.4. UICC et AuC, cl de vote du systme 10.4.1. Scurit et carte puce 10.4.2. UICC et USIM 10.4.3. Utilisation de base 10.4.4. Scurit et IP Multimedia 10.4.5. Scurit et service de diffusion multimdia (MBMS) 10.4.6. Scurit et appels de groupe (VGCS) 10.4.7. Scurit et I-WLAN 10.4.8. Scurit et terminal rparti entre plusieurs priphriques 10.5. Applications et scurit 10.5.1. Interfonctionnement des applications et pare-feu 10.5.2. Tlchargement d'applications 10.6. Roaming et scurit 10.6.1. Accs aux donnes de scurit 10.6.2. Accs de multiples rseaux 10.6.3. Algorithmes de conversion, fonctionnalit 2G 10.6.4. Roaming 2G/3G, authentification et chiffrement 10.7. Interception lgale 10.7.1. Les rsolutions de la Communaut Europenne 10.7.2. La mise en place dans les pays, le cas du Royaume-Uni 10.7.3. Interception et standardisation 10.8. Protection du rseau UMTS 10.8.1. Le rseau nominal 10.8.2. Les lments du rseau - interfaces 10.9. Conclusion 10.10 Annex ^Bibliographie et Rfrences 10.10.1. Bibliographie 10.10.2. Spcifications - Standards 10.10.3. Sites Internet Glossaire Index
438 438 439 440 440 441 442 443 444 445 445 445 446 447 447 447 447 448 448 448 449 450 451 451 451 454 454 454 455 457 459 471
Chapitre 1
Introduction l'talement de spectre
1.1. Introduction L'UMTS (Universal Mobile Tlcommunications Systems) doit permettre une panoplie de services nettement plus large que les systmes de deuxime gnration comme GSM (Global System for Mobile communications) qui se cantonnait la tlphonie 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 occupant 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 objet 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'talement 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 .
20
-2,5 -2
-1,5
-1
-0,5
0,5
1,5
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 sinusodal 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 gnration. 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.
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 (27 rj c t + 2irra/M + <p) o <p est la phase l'origine des temps.
[1.21
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 \ g(t) = 0
Si \t\ < Ts/2 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'espace 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'utiliser 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
22
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 (27 rf 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 frf 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 (27 rf 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 (27 rf 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)
23
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\ :
+oo -t-oo
E= I
ff(t)dt
-oo
/?
"
[1.9]
On a donc : 2 p-t-OO g2{t)s2(27rfct)dt

Joo
E=
[1.10]
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 0. On en dduit E 1. D'autre part, on a : -t-oo 2 p~r fi (t) h (t)dt = -
-oo ^g
g2 ( t) cos (47T fct) dt =
g2(t) cos ( 2 ; T f c t ) sin (2T rf c t) dt

Joo
[1.12]
On peut en dduire, aprs quelques calculs lmentaires :

+oo
-oo
h(t)f2(t)dt
[1.13]
24
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 combinaison 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 complexe 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 toujours 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.
25
EXEMPLE - Dans le cas de la B P S K , on utilise seulement la voie I. Un symbole correspond 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 quadrature. 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.
26
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 en frquence transposition 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 crneau 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
27
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 suivant une gaussienne. Ce signal est appel bruit additif blanc gaussien (AWGN, Additive 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, mobiliers urbains, vhicules, personnes, etc.) provoquent des rflexions, des diffractions
28
et de la diffusion (voir [PAR 00] et [LAG 00]). Un rcepteur reoit un signal composite 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 transforme 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 gnrale :
[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 uniformment 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]
29
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}.
30
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 multiplication 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 On en dduit aisment :
[1.24]
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]
Introduction l'talement de spectre Densit spectrale de puissance
31
-8
-7
-6
-5
-4
-3
-2
-1
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 = (s n \
i n 0
7TfTb/n
ir/
n )
y2 J
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/2 T 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
32
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 longueur 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 frquence 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 frquence 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 donne 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 ' O -j=e 1 Q (t) = f O !2dx. Par exemple, un rapport Eb/N0 de 6 dB conduit un taux t t d'erreur bit de 10 - 3 Soit C la puissance du signal mis. Dans une transmission sans talement, la largueur 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 .
33
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 n En chelle logarithmique, on obtient : (C/N)dB = (Eb/N0)iB - 101ogi 0 n
[1.31]
[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 = - 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]
[..33]
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 retrouver 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]
34
On a donc : [1.36] On note qu'il est ncessaire pour la rception d'estimer la valeur de tq. Cela signifie 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).
35
Figure 1.9. Exemple de rception d'une squence bruite
Pour illustrer le principe de fonctionnement du rcepteur, on considre une transmission 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 :
36
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
37
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 implusionnelle. 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
38
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 talement, 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
39
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 Multiple 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 transmettre par une squence de chips un dbit suprieur Rc = nRb. Cependant, la squence 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]
40
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
41
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'Hadamard. Aprs talement, le signal est bi (kTb) Wi. Le multiplexage des n utilisateurs consiste transmettre globalement : n-l S{kTb) = J2bj(kTb)j j=0 Cela signifie qu'on transmet [1-481
{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
bj (kTb) 3=1
<
Wj,Wi >
[1.49]
42
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.
43
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'orthogonalit. 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 particuliers qui peut tre gnralis sans problme. Considrons un utilisateur 1 transmettant
44
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 squences 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 particulirement important pour garantir cette proprit.
45
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 reboucl 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
46
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 squence 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 squence 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.
47
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 ncessairement 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 squences 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 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.
m
1.5.1.4. Systmes asynchrones Dans l'UMTS, on utilise des squences de Gold obtenues partir de de msequences 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 rptition de 10 ms. Il y a 512 squences diffrentes. Pour diffrencier deux stations de base,
48
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 orthogonaux (Walsh ou OVSF) pour permettre un multiplexage de plusieurs transmissions et de squences PN pour permettre une rutilisation de la mme frquence sur diffrentes 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 squence 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 secondaires (c'est le cas pour l'UMTS). Cela revient affecter un deuxime code d'embrouillage 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.
49
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 provoque, comme sur la voie descendante, un interfrence sur la voie montante.
50
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 dlai 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 pseudoalatoires 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 orthogonalit 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
51
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 Wideband 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, Chichester, GB, 2003. [JAK94] JAKES W. C., Ed., Microwave mobile communications, N.J., 1994.
[LAG00]
IEEE Press, Piscataway,
LAGRANGE X., Ed., Les rseaux radiomobiles,
Collection IC2, Herms, Paris,
2000.
[PAR 00] PARSONS J., The Mobile Radio Propagation Channel, John Wiley and sons, Chichester (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, Wesley, 1995. Addison-
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'UTRAFDD 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.
54
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
56
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.
57
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).
58
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.
59
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 (champ 1 + champ 2 en bits) 0 + 2 0+4 2+6 2 + 8 2+10 2 + 12
TPC (bits) 2 2 2 2 2 2
TFCI (bits) 2
Pilote (bits) 4 4
Total (bits)
Facteur d'talement
Chips pilotes 2 048
Dbit donnes (kbit/s) 3 6 12
0
2
10
512
2 048 2 048 2 048 1 024
8
8 4 4 2 2 8 4 4 40 128 64 32
16
0
2
15
18
21
0
2
20
256
1 024 512 512 1 024 512 512 512 256 256 128 64
2+12
2+14 6 + 22 6 + 26 6 + 28 12 + 48 28+112 56 + 232 120 + 488 248 + 1 000
2 2
2 2 2 4 4
21 24 42 48 51 90 210 432 912 1872
0
2 2
0
8
8 8
8
8 8 8 8
8 8
16 16
80
160
320 640
1 280
8
4
16
Figure 2.6. Schmas de transmission sur la voie descendante (canal ddi)
60
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
61
Donnes 20 40 80 160 320 640 1 280
Etalement 256 128 64 32 16 8 4
Dbit de donnes (kbit/s) 30 60 120 240 480 960 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.
62
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 (beamforming). 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
63
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 Donnes Facteur d'talement SF Dbit des donnes (kbit/s) Bits pilotes TPC
DPCCH sur voie Q (15 kbit/s) TFCI FBI Total Facteur d'talement SF Chips pilotes
10 20 40 80 160 320 640
256 128 64 32 16
15 30
8 7 6
6
2
2 2 2
0 0
2
60
120 240 480 960
0 1 0
2
2 048 1 792 10 256 1 536 1 536 1 280

1 280
5 5
0 2
2
1
2
8
4
Figure 2.12. Schmas de transmission sur le canal physique ddi montant (DPCH)
64
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
65
Donnes Donnes (bits) Facteur d'talement Dbit des donnes (kbit/s) Pilot TFCI Total
Contrle Facteur d'talement Chips pilotes Dbit de contrle (kbit/s)
10 20 40 80
256 128 64 32
15 30 60 120
10
256
2048
15
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^SCH secondaire J
# L^
gb
SCH<tR
CPICH
I
sloto
H j
B
I
! I
B
I
code O V S F
C256.0
r
CPICH Squence de 20 bits 0 avec talement 256 2560 chips complexes
slot 1 trame de 10 ms
slot 14
temPs
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 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.
1
67
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
68
Principes et volutions de l ' U M T S
toujours des donnes de contrle au niveau 3 (messages RRC). C'est ce qui explique la dnomination Control pour ce canal.
SCH
CPICH ' P-CCPCH
pi
sloto
J5
--
a.
r"
H
slot 14
" " code OVSF C256.0 ^ ^ ' " J code OVSF C256 1
temPs
slot 1 trame de 10 ms
P-CCPCH
Squence de 18 bits avec talement 256
4 -
2304 chips complexes
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]).
69
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
70
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.
71
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.
72
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.
73
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 Nombre de blocs de transport
Transport Block Size Transport Block Set Size
variable dynamiquement variable dynamiquement
paramtres dynamiques : ensemble de valeurs dfinis par signalisation RRC
24 16 Dtection d'erreur CRC 12 8 0 taux 1 (pas de codage) Code convolutionnel Correction d'erreur Turbo-code Nombre de trames de 10 ms pour la transmission Valeur du TTI taux 1/2 taux 1/3 taux 1/3 1 trame ( 10 ms) 2 trames (20 ms) 4 trames (40 ms) 8 trames (80 ms) une valeur choisie parmi n possibles par signalisation RRC Paramtres semi-statiques
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).
74
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
75
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 Numro du format de transport 1 2 3 4 5 6 7 8 Taille du bloc de transport 81 65 75 61 58 55 49 42 DCH 2 Numro du format de transport 1 2 3 4 5 6 7 8 Taille du bloc de transport 103 99 84 87 76 63 54 53 paramtres statiques pour DCH 3 CRC Codage TTI 0 taux 1 20 ms DCH 3 Numro du format de transport 1 2 3 Taille du bloc de transport 60 40 0
paramtres statiques pour DCH 1 CRC Codage TTI 8 Convoi. 1/3 20 ms
paramtres statiques pour DCH 2 CRC Codage TTI 0 Convoi. 1/2 20 ms
Figure 2.22. Exemple de formats de transport {pour la voix AMR)
76
Valeur TFCI 1 2 3 4 5 6 7 8
Numro de Format sur DCH 1 1 2 3 4 5 6 7 8
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 ;
77
- 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 BCH Nom Sens 1 Canal physique Remarques Diffusion des informations systme, dbit faible Adresse mobile explicite inclure Systmes d'conomie d'nergie Donnes en mode paquet (ncessite un DCH) Donnes limites (ou signalisation) Dbit variable chaque TTI Adresse MS implicite
Broadcast channel
Primary Common Control Physical Channel

(P-CCPCH)
FACH PCH DSCH
Forward access channel Paging channel Downlink shared channel Random access channel Dedicated channel
i 1 i
Secondary Common Control Phvsical Channel

(S-CCPCH)
Physical Downlink Shared Channel

(PDSCH)
RACH DCH
Physical Random Access Channel (PRACH) Dedicated Physical Channel (DPCH)
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 ;
78
-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.
79
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 ;
80
- 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 FACHRACH. 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
81
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.
<
TCTF Entte MAC UE-ld Type UE-ld C/T MAC SDU MAC SDU
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 ;
82
- 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
83
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 (sur DTCH) canaux logiques Taille d'un bloc de transport TTI CRC Codage Taux de codage voie descendante voie montante DPDCH SF DPDCH SF DTCH 244 20 ms
16
12,2 kbit/s DCCH

100
64 kbit/s DTCH
1280
384 kbit/s DTCH 3840 10 ms

16
DCCH 100 40 ms
12
DCCH
100
40 m s 12 Codage convolutif 1/3
20 ms 16 Turbo Code 1/3 32
40 ms
12
Codage convolutif 1/3
Codage convolutif 1/3
Turbo Code 1/3
Codage convolutif 1/3 8
42 kbit/s
128
210 kbit/s 240 kbit/s 16
912 kbit/s 960 kbit/s 4
60 kbit/s 64
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]
84
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 UTRAFDD. 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).
85
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
86
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.
87
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]).
88
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]).
89
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
90
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
91
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 interfrquences et inter-systme (pour permettre par exemple un handover
92
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
93
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
94
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.
95
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
96
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
97
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 HSDSCH.
98
Fonction Facteur d'talement variable (VSF) Contrle de puissance rapide Codage et modulation adaptative (AMC) ARQ rapide (HARQ) Multi-code Intervalle de transmission Emplacement des fonctions MAC
DSCH Oui (4-256) Oui Non Non Oui 10 ou 20 ms RNC
HS-DSCH Non (16) Non Oui Oui Oui 2 ms 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.
99
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 (15 codes) (1 code) (5 codes)
1
2 3
QPSK QPSK QPSK 16 QAM 16yQAM
%
'/2
3
119 kbit/s 237 kbit/s 356 kbit/s 477 kbit/s 712 kbit/s
/4
0,6 Mbit/s 1,2 Mbit/s 1,8 Mbit/s 2,4 Mbit/s 3,6 Mbit/s
1,8 Mbit/s 3,6 Mbit/s 5,3 Mbit/s 7,2 Mbit/s 10,8 Mbit/s
4
5
Vi
VA
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.
100
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.
101
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.
102
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 [ P R O 0 1 ] PROAKIS J .
S, Rseaux GSM, Herms Science,

ME
2000.
G.,Digital Communications,
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 multiutilisateurs 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.
106
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) ;
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).
108
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 +
(N0+l0)fV
[3.1]
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
109
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 + TVo^ + ^ - l ) ^ = W log 2 1 + N0W + (K-1)
S
Svmb
.[3.4]
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.
110
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.
111
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.
112
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.
113
Paramtres et fonctions Bande passante Modulation Sparation des canaux Trame TDMA Mthode de Duplex Acs multiple IT par trame Type de rcepteur Synchronisation Prcision synchro UL Modes d'antennes Contrle de puissance voie montante (UL) Contrle de puissance voie descendante(DL) Codage canal Entrelacement Estimation de canal Codes d'embrouillage Codes d'talement Allocation de canaux Facteur d'talement (SF) Handover Adaptation dbit UL Adaptation dbit DL Rpartition UL/DL Rseau Ressource physique lmentaire
Valeur/Expression 3,84 Mchips QPSK 16QAM (pour H S D P A 2 ) 5,0 MHz/Porteuse 10ms
Valeur/Expression 1,28 Mchips QPSK (8PSK) 16QAM (pour HSDPA) 1,6 MHz/Porteuse 10ms (divis en 2 sous-trames) TDD TD-CDMA
15 Dtection multi-utilisateur, Rake DL et UL (option) 4 chips
7 (par sous-trame) Dtection multi utilisateur (option), Rake DL et UL 1/8 chip
Diversit de transmission, Rseaux Diversit de transmission d'antennes actives (option) Boucle ouverte (dlai : 667Boucle ferme : 0-200 Hz/sec. 4 669 ps si 2 SCH par trame, Boucle ouverte: (dlai de 200 ps 6 6 7 - 9 3 3 8 ps si 1 SCH) 3575 ps) Boucle ouverte Boucle ferme (de 100 Boucle ferme/200 Hz (maximum) 700 Hz) - Turbo codes PCCC 8 tats, rendement 1/3 - Codes convolutifs rendement 1/3 ou 1/2 longueur de contrainte 9 - sans codage sur 1,2,4 ou 8 trames Midambules (512 ou 256 chips) Midambules (144 chips)
longueur 16, caractristique de la cellule Orthogonaux (OVSF) Dynamique (DCA) 1,2,4, 8,16 Hard handover 1 ou 2 codes (SF = 1 , 2 , 4, 8 ou 16) codes multiples (SF = 1 ou 16) Flexible Flexible ( long terme) Synchronis au niveau trame 1 frquence, 1 code et 1 IT (allous de manire identique dans les 2 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.
114
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.
115
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 976 chips Midambule 512 chips 667 ps Midambule 256 chips 667 ps Symboles de donnes 976 chips PG 96 w Symboles de donnes 1104 chips
Symboles de donnes 1104 chips 4
PG 96
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. Symboles de donnes 976 chips Midambule 512 chips 667 ps Symboles de donnes PG 192 880 chips

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.
116
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.
117
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.
118
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
119
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.
120
A
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 Frquence du contrle de puissance Pas d'ajustement Variable Boucle ferme : 0-200 cycles/sec Boucle ouverte : (dlai de 200ps 3575 ps) 1,2,3 dB (boucle ferme) Downlink Variable Boucle ferme : 0-200 cycles/sec 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.
121
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
122
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
123
Chacun des ûtilisateurs met un midambule de longueur! + W - 1 chips : T

}
L+W-1
k = \ K
[3.7]
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)
"W
,k = \K
[3.8]
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 : W k = \j = \ K
e i
m<k) W+l
*h(k>+n j i
[3.9]
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]
124
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
[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 :
<>
(1) m m
m\ m
m'
m<2) et
m, ( 2 ) m
(2)
G (2)
m (2)
m (2) m (2)
m (2) m (2)
m\
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 :
G = [G(1)
<> <> <> G(2)] = <> <>
m?
2) m, (i .(2)
,(2)
m\ 2) ni
mf m
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)~
mf
e
mf
<
<>
m? m?
m?
mf>
h<" h ?>
2)
n2
"3
n
4.
mf
m\
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
4. la notation X" est l'oprateur transpos conjugu.
[3.16]
126
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 ).
127
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.
128
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 :
129
[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
FFT sur e
Nombre de multiplications complexes

(1/2) x log2(L/2)
Pondration par A
L
(.U2) x log 2 (I/2)
IFFT sur A We
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 multiutilisateur maximum de vraisemblance en fonction du nombre de midambules
130
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.
131
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.
132
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=
e = [ e\>-'> eN.Q>---> eN.Q+ L-1] 7"
si nal
re
symboles mis avant

U
talement
n = [,, '^N.Q^"">nN.Q+L-\\ A = [A..] i = \...N.Q + L-\
blanc gaussien additif 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 =<w si
sinon
k = \...K,n = \...N,w = \...Q + L-\
Q (n-\)+w , k+K.(n-\)
Le scalaire bk est dfini comme un lment du vecteur bk = ck * hk (2^ avec bk,bk,...,bk 12 Q+L-l qui reprsente la rponse impulsionnelle globale du ke
134
Principes et volutions de l'UMTS >
utilisateur,
hk = hk,hk,...,hk 12 L
qui
reprsente
l'estim
de
la
rponse T est
impulsionnelle du ke canal (L chantillons de dure Tc) et ck = ck ,ck ,...,ck 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 c2=[\ -1 1 1-1 -lj -lj (Q chips) ( Q chips).
Les rponses impulsionnelles des canaux sont : h =[ 1 h =[ 1 1/2] 1/4] (L chips) (I chips), 1 ] et d^ = [ 1 -1].
et les donnes transmises par les 2 utilisateurs sont d = [ 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) ( Q+L-l chips)
b2 = [l
5/4 - 3/4 - 5/4 -1/4 ]
135
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] :
A
d = (AH R~lA)~lAH R~le d symboles utiles + (AHR~lA)~lAHR~ln bruit [3.23]
136
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 bruit/?" Rn 11 devient devientCT a 22 I, I, o Oa2 a2 est estla la variance du bruit et I est la matrice identit Les donnes estimes devenant alors : d = (AH A)~XAH e + symboles utiles (AHA)~XAHn bruit [3.24]
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 +
H
R~l)~lAHR~le
A
(I + (RdA R- A)- )-\dzF-BLE WQ estimateur de Wiener H nD - R~ \ A l , D - K -11 1aH n 1l = diag(W0).d + diag(W0).d + (A A + R' )' A R~ n symboles IES et IAM bruif
[3.26]
En cas d'chantillons de bruit et de donnes non corrls (cas usuel), l'estim devient : d = (AHA+G2I)~1 AHe p 27]
137
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 respectivement les puissances de l'IAM, du signal et du bruit. reprsentent
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] Cette expression peut s'crire, en considrant la puissance moyenne <j e du signal reu e : 2
[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.
138
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
140
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 (a tant la variance des lments de n).
2
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.
141
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.
142
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.
143
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.
144
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 intercellule 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.
145
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.
146
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.
147
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
148
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.
149
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)
150
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 , 3GPPTSGR1 #4(99)389 (disponible l'adresse http://www.3gpp.org/). [PET 95] PETERSON R . L . , ZLEMER R.E., Communications, Prentice hall, 1995.
[ P I G 9 9 ] PIGEONNAT Y . I E E E 1999. BORTH
D.E., Introduction to Spread Spectrum : complexity and alternative solutions ,
Joint dtection for
UMTS
151
[ 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.
145 Principes et volutions de l'UMTS >
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, Signalto-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.
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, BitError-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.
Le contrle de puissance dans 1 ' U MTS
161
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
Le contrle de puissance dans 1 ' U MTS
161
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 valeurseuil 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.
164
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 valeurseuil 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.
166
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.
168
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.
170
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 UMTSWCDMA, 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
172
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
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
174
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).
176
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
178
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.
180
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. Lest
Iuplink
SIRinget=Cte-
[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 UTRATDD 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
182
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 UTRATDD 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 cidessus 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.
184
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.
[GIL 9 1 ] GILHOUSEN K . S.
et al., On the capacity of a cellular C D M A system," IEEE Trans. on Vehicular Technology , vol. 40, n 2, 1991. 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. WCDMA for UMTS, deuxime dition, Wiley, 2 0 0 2 .
[HAN
[ H O L 0 2 ] HOLMA H . , TOKSALA A . ,
[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. Technology, vol. 40, n 2, 1991. on Vehicular
[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 .
[VIT 9 4 ] VITERBI A . J., VITERBI A . M . , ZEHAVI E . ,
Other-cell interference in cellular powercontrolled C D M A ; IEEE Trans. on Communications, vol. 4 2 . , n 2 - 4 , 1 9 9 4 . A. J., CDMA Principles of spread spectrum techniques, Addison-Wesley,
1995.
[VIT 9 5 ] VITERBI
[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 systems , IEEE Trans. on Vehicular Technology, vol. 41, n 1, 1992.
[ZAN 9 2 ] ZANDER J.,
[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.
188
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
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
190
([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] :
191
[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 sousparagraphe 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.
192
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
193
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 :
194
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 ~
P
C
[5.3]
Z r.i,k ThJ k=\
+N
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]
195
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 :
196
>
En utilisant le rapport d'interfrence, on en dduit d'aprs [5.6] :
On a donc : [5.7] En pratique, les valeurs de r j ^ peuvent facilement dpasser 0,9. 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
197
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 :
198
[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]
199
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 qualitseuil, 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 :
200
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
201
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
202
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.
203
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
204
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]
205
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 :
206
[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,
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.
207
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.
208
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 ;
209
- 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 X ÛLjjt
NULJ= (l + I p c f j )
i=l;bj=j
[5-30]
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
210
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 CDMA
P., Average external interference in cellular radio systems , IEEE Trans. on Communications, vol. 4 4 , n 1, 1 9 9 6 .
211
[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 Trans. on Vehicular Technology, vol 40, n 2, 1991.
CDMA
[ G I L 9 1 ] GILHOUSEN K .
system, IEEE
[HIL 0 0 ]
Hiltunen K . , D E BERNARDI R . , W C D M A downlink capacity estimation , IEEE Vehicular Technology Confrence 2000 Spring, VTC2000 Spring, 2000. WCDMA for UMTS, Second dition, Wiley,
2002.
[ H O L 0 2 ] HOLMA H . , TOKSALA A . , [JON 0 0 ] JONES P . , OWEN R . ,
model parameters , Technologies, 2 0 0 0 .

[LAI 9 9 ]
Sensitivity of UMTS F D D system capacity and coverage to First International Confrence on 3G Mobile Communication
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. LAIHO J., WACKER A . , Radio network planning process and methods for Annales des Tlcommunications, vol 56, n 5-6, 2 0 0 1 . ^
[LAI 0 1 ]
W C D M A ,
[LAI 0 2 ] LAIHO J., WACKER A . , NOVOSAD T . ,
Radio Network Planning and Optimisation for

CDMA,
UMTS, Wiley,
[LEE91]
2002.
LEE W . C . Y . , Overview of cellular Technology, vol. 40, n 2, 1991.
IEEE Trans.
on
Vehicular
[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. 99b] 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
[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.
212
[ T R A 9 9 ] TRAN-GIA
P., LEIBNITZ K . , Teletraffic Models and Planning in Wireless IP Networks , IEEE Wireless Communications and Networking Confrence, WCNC'99, 1999. 99] VEERAVALLI V . V . , SENDONARIS A., The Coverage-Capacity Tradeoff in Cellular CDMA Systems , IEEE Trans. on Vehicular Technology, vol. 48, n 5, 1999. controlled
C D M A ,
[VEE
[ V I T 9 1 ] VITERBI A . J . , VITERBI A . M . , ZEHAVI E . ,
Other-cell interference in cellular powerIEEE Trans. on Communications, vol. 4 2 , n 2 - 4 , 1 9 9 4 .

CDMA
[ V I T 9 3 ] VITERBI A . M . , VITERBI A . J . ,
Erlang capacity of a power controlled system , IEEE Journal on selected areas in communications, vol. 11, n 6, 1993. A. J . , CDMA Principles of spread spectrum techniques, Addison-Wesley, 1995.
[ V I T 9 5 ] VITERBI
[ W A C 9 9 ] WACKER A . , LAIHO-STEFFENS J . , SIPILA K . , JASBERG M . ,
Static Simulator for 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 bi Nombre total de station de base de la zone considre. 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,-.
213
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, gij gji i,k j,l
IIDL,/
Variable alatoire binomiale reprsentant l'activit du mobile /'. La Gain de parcours, en puissance, entre le mobile i et la base j. Gain ^le parcours, en puissance, entre la base j et le mobile i. Indices dsignant les mobiles. Indices dsignant les bases. Facteur de charge en downlink du mobile i. Facteur de charge en uplink la base j. Facteur de charge en uplink du mobile i la base j. Facteur de charge du mobile i la base j. Nombre de mobiles actifs dans la zone couverte. Nombre de mobiles actifs dans la base j. Noise Rise du mobile i (tude uplink). Noise Rise de la base j (tude uplink). Puissance du bruit thermique reu par le mobile i. Puissance du bruit thermique reu la station de base j. Attnuation entre le mobile i et la station de base /. En fait, PLU n'est Attnuation maximale pour les mobiles rattachs la base j. Puissance totale mise par une base, dans l'hypothse o cette puissance Puissance mise du mobile /'. Puissance totale mise par la base j. Puissance mise de la base j destine au mobile i, rattach cette Puissance maximale d'mission. Puissance maximale d'mission de l'quipement e (mobile ou base).
valeur moyenne de cp note (p,-, reprsente le facteur d'activit du mobile i.
r|UL/ tluw,/ Lji N Nj NRdlj NRj Nfh j NThj PLji PLMaxj P Pi Pj Pji dernire. PMax P\fax.e
autre que M gu.
est la mme pour toutes les bases.
214
Prij Puissance utile venant de la base j et reue au mobile i (tude du downlink). Prjj R Ri
RDLJ
Puissance reue la base j venant du mobile i (tude de Fuplink). Dbit de donnes avant talement. Dbit de donnes, avant talement, de l'usager z, dans le sens uplink. 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.
216
- 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).
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.
218
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
219
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.
220
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
221
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
222
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 (<combining/splitting) pour la macrodiversit. combinaison et de dcoupage
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.
223
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
224
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 cellesci, 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.
225
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
226
Principes et volutions de l 'UMTS >
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 soussystme 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.
227
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
228
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'entte 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'entte 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
229
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
230
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 souscouche, 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
231
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 Caractristiques Relation temporelle sourcedestination Dbit Mode de connexion Remarque Constant Oui plusieurs connexions dans un CV identifies par leCID Non Oui Oui AAL-2 AAL-5 Non
Variable Non adapt au transfert de blocs de donnes de taille variable (par exemple signalisation) Oui
Utilisation dans l'Utran
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.
232
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 minicellules peuvent tre placs dans une mme cellule ATM. La transmission de minicellules 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.
233
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-
234
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 service (possibilit de dsquencement et de pertes de paquets). Lorsque quipements extrmits peuvent se satisfaire de la qualit de service du rseau, peut utiliser le protocole UDP, User Datagram Protocol, comme protocole niveau transport. de les on de
Lorsqu'il est ncessaire de garantir une transmission sans perte ni dsquencement, 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.
235
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.
236
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.
237
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
238
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
239
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.
240
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.
241
Figure 6.23. Structure des protocoles sur l'interface Uu
Localisation des entits Canaux logiques canaux logiques ddis canaux communs canal paging voie balise Canaux de transport utiliss DCH DSCH HS-DSCH RACH/FACH RACH/FACH PCH BCH Nud B Physique Physique Phy/MAC Physique Physique Physique Phy/MAC /RLC/RRC RNC Contrleur MAC MAC MAC/RLC MAC/RLC/RRC RRC RNC serveur Phy/MAC/RLC MAC/RLC MAC/RLC MAC/RLC
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
242
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'IuPs ( 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.
243
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
244
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])
Le rseau d'accs UTRAN 6.4.3. Interface Iub
245
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])
246
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).
247
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) luimme 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 audessus d'UDP-IP mais on fait l'conomie de la couche ATM (voir figures 6.31a et 6.26).
251
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
253
- 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.
254
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 ;
255
-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.
256
- 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.
257
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
258 Principes et volutions de l'UMTS > Canal de transport montant DCH RACH Canal de transport descendant DCH FACH PCH, BCH PCH, BCH PCH, BCH Contrle de la mobilit rseau mobile ou rseau mobile mobile mobile Niveau d'activit +++ ++ +
-
Connaissance par UTRAN Oui Oui Oui Oui Non
CellDCH CellFACH Cell PCH URAPCH Veille (Idle)
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 signalisation pour montrer la mise en paragraphes prcdents. On se place dans procdures sont similaires avec un quelques exemples de procdures de uvre des concepts prsents dans les le cas d'un rseau de transport ATM. Les rseau de transport IP ; les phases
259
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'luPs 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 FACHFP sont utiliss au dbut de l'tablissement pour transporter les messages RRC.
260
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.
261
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
262
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.
Source : figure 9 de 25.931
Figure 6.41. Etablissement d'une connexion RRC sur RACH-FACH
Comme au paragraphe 6.7.1, il signalisation NAS. Le scnario est messages sont transmis sur un canal FACH associ avec le C-RNTI (et non
est possible d'tablir une connexion de similaire la figure 6.39. Cependant, les DCCH qui correspond un RACH ou un un DCH).
263
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.
Source : figure 13 de 25.931 Figure 6.42. Etablissement d'un RAB en version synchronise
264
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).
Source : figure 17 de 25.931
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
265
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.
Source : figure 24 de 25.931 Figure 6.44. Ajout d'un liaison radio (soft handover)
266
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.
Source : figure 25 de 25.931 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.
267
Source : figure 26 de 25.931 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
268
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.
Source : figure 35 de 25.931 Figure 6.47. Procdure de relocalisation
269
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, Spcification Group Radio Access Network, 3G TS 25.401. Technical
[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 Principles, Technical Spcification Group Radio Access Network, 3G TS 25.420. [25.430] 3rd Gnration Partnership Project; UTRAN Iub Interface General Aspects and Principles, Technical Spcification Group Radio Access Network, 3G TS 25.430. [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.
270
[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. Introduction aux rseaux, Editions Herms, Paris,
1998,.
[ L A G 9 8 ] LAGRANGE X . , S E R E T D . , [ R I G 0 1 ] RIGAULT C . ,
Principes de communication numrique, du tlphone au multimdia, Editions Herms, Paris, 1998. 02]
ROLIN
[ROL
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.
272
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 7.2.1. Architecture du rseau GSM avant le GPRS
273
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
274
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.
275
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
276
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.
277
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
278
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.
279
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.
280
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
281
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.
282
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.
283
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)
284
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.
285
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
286
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,
287
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
288
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-
289
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 3GGGSN 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 3GSGSN qui relaie la signalisation vers le HLR.
290
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.
291
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.
292
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 sousensemble, 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.
293
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
294
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
295
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 GSMGPRS. 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,
296
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 audessus 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
297
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
298
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.syldavietelecom.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.
299
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
300
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
301
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, PMMIDLE 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
302
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
303
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
304
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.
305
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
306
Principes et volutions de l 'UMTS >
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)
307
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.
308
-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 dynamiquement) ; le rseau externe d'accueil (lorsqu'elle est alloue
- 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.
309
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.
310
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),
311
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.
311
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.
312
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.
313
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.
314
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
315
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
316
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.
317
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
318
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.
319
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.
320
Figure 7.29. mise jour de zone de routage inter SGSN lorsque le mobile est en mode PMMCONNECTED
Figure 7.30. Mobilit inter SGSN en mode connect
321
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
322
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
323
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 DATA
150.25.89/24 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 sousrseau : 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
324
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
325
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 lmme 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.
326
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
327
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 Conversationnel Principales caractristiques Prservation de la relation temporelle entre les paquets Dlais faibles et constants Prservation de la relation temporelle entre les paquets Prservation du contenu (peu d'erreurs) Mode de fonctionnement requte - rponse Prservation du contenu (peu d'erreurs) Pas de contraintes temporelles Exemple d'application Voix, VoIP, vido confrences Diffusion de contenu multimdia Navigation Internet Tlchargement (courrier lectronique)
Streaming
Interactive
Arrire-plan (Background)
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.
328
Attributs Dbit maximal Squencement Taille des SDU Livraison des SDU errones Taux d'erreur bit rsiduel Taux de SDU errones Dlai de transfert Dbit garanti Priorit de traffic Priorit l'allocation/maintien
Conversational < 2 Mbit/s Oui ou non < 1 500 Oui/Non15.10 2 10"6 1 0 10"
2 5
Streaming
< 2 Mbit/s Oui ou non < 1 500 Oui/Non/5.10"2 10"6 10" 10"
2 5
Interactive < 2 Mbit/s (- les en-ttes) Oui ou non < 1 500 Oui/Non/4.10"3 6.10"8 10" 10"
-
Background < 2 Mbit/s (- les en-ttes) Oui ou non < 1 500 Oui/Non14.10"3 6.10"8 10"3 10"6
-
A partir de 100 ms < 2 Mbit/s 1,2 et 3
A partir de 250 ms < 2 Mbit/s 1,2 et 3
1,2 et 3 1,2 et 3 1,2 et 3
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 luimme 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.
329
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.
330
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
331
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 Conversationnel A flux continus Interactif Arrire plan Comportements DiffServ EF AF11, AF12, AF13 AF21, AF22, AF23 BE (pour le mieux)
Tableau 7.3. Correspondance entre les classes de service UMTS et les comportements (PHB) DiffServ
332
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. - traduction vers les classes UMTS - classification - mise en forme et marquage - files d'attente et ordonnancement
Routeur frontire Diffserv. - traduction vers un autre domaine IP - classification - mise en forme et marquage - 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.
333
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)
334
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).
335
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
336
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.
337
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.008380 , 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 Intelligent Network CS1, ITU-T Q.1214, ITU-T, 1994. [RFC 1034] MOCKAPETRIS P., Domain Names: IETF, 1987. Functional Plane for
concepts and facilities, RFC 1034,
[RFC 1035] MOCKAPETRIS P., Domain Names: Implementation and spcification, RFC 1035, IETF, 1987.
[RFC 2401] KENT S., ATKINSON R., RFC 2401, IETF, 1998.
Security System Architecture for the Internet Protocol,
[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., IPv4, RFC 2794, IETF, 2000. [RFC 3344] PERKINS C.,
Mobile IP Network Access Identifier Extension for
IP Mobility Support for IPv4, RFC 3344, IETF, 2002
[BAT 02] BATES R., GPRS: GeneralizedPacket Radio Service, McGraw-Hill, 2002.
338
[CHE 04] CHEN J.-C., ZHANG T.,
IP-Based Next-Generation Wireless Networks: Systems, Architectures and Protocols, Wiley, 2004. Le GPRS : Du WAP l'UMTS, Dunod, 2002. Thorie et pratique, O'Reilly, 2002. Rseaux GSM, Herms, 2000.
[FAG 02] FAGGIONN.,
[CIS 02] CIZAULTG., IPV6,
[LAG 00] LAGRANGE X., GODELWSKI P., TABBANE S., [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 System 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 tlphonique) ; - les tlservices sont chargs d'effectuer un traitement sur des informations transportes 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 messages 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'utilisateur final (par exemple le service supplmentaire renvoi d'appel peut tre associ au tlservice de tlphonie).
Chapitre rdig par Philippe MARTIN s.
340
Cette mthodologie a t reprise en UMTS (Universal Mobile Tlcommunications 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 tlcommunications, ncessite des temps de dveloppement plus courts et une architecture logicielle 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 intelligent 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 Mobile 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 utilisateur 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'appuie 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'apport majeur de CAMEL rside dans la dfinition d'une interface de commande normalise 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.
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. CAMEL 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 sousjacente. 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 rseau 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 joignable 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'appels, 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 tlcommunications sur une infrastructure tlphonique (numro vert, cartes prpayes...).
342
Le RI a pour objectif de rendre un commutateur tlphonique (ou ressource de tlcommunications) 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 reprsente 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 prsence 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 communication 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 possible de sparer la fonction de traitement d'appel, appele CCF (Call Control Function) dans la terminologie rseau intelligent, et la logique de service appele SCF (Service 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 interactions 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 capacits (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 premire srie de recommandations rseau intelligent adopte par l'ITU. Elle est actuellement 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.
343
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 multipartites, 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 terminal 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 intelligent 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 Q12 nx, o n identifie le numro d'ensemble de capacit considr et o x correspond un numro de recommandation (voir tableau 8.2).
344
Phase CS-1 CS-2
Principales caractristiques Dclenchement du service depuis les phases non stables de l'appel. Utilise uniquement le BCSM (Basic Call State Model). 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 modlisation d'appels multipartite. Support des interactions OCCUUI et OCCRUI Support de services rseau intelligent dans un rseau ATM. Nouveau modle d'appel prenant en compte l'tablissement de connexions sur un rseau ATM Services rseau intelligent s'appuyant la fois sur le rseau tlphonique et l'Internet.
CS-3
CS-4
Tableau 8.1. Classification des ensembles de capacits du rseau intelligent Srie de recommandations Q12 nx Description du contenu Structure des recommandations pour le jeu de capacit n Rsume les principales caractristiques du jeu de capacit n Description du plan de services Description du plan fonctionnel global Description du plan fonctionnel rparti Description du plan physique Description du protocole INAP (Intelligent Network Application Part) Guide de l'utilisateur rseau intelligent Tableau 8.2. Structure des recommandations rseau intelligent
Suffixe x 0 1 2 3 4 5 8 9
8.2.3.
Le modle conceptuel du rseau intelligent
Le rseau intelligent utilise un modle de dveloppement des services de type fonctionnel 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 dcrit selon les quatre plans suivants : plan de services, plan fonctionnel global, plan fonctionnel rparti et plan physique. Le plan de services apporte une description textuelle du comportement des diffrents services apports par un jeu de capacits. Les
Les architectures de services de
l'UMTS
345
normes dfinissent un ensemble de fonctions normalises, appels lments de services, dcrivant le comportement des services tels qu'ils doivent tre vus par l'utilisateur. 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 logiciel 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'abstraction, 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 dcomposs 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 lmentaires sont appeles des entits fonctionnelles et les instances de ces fonctions sont dsignes par le sigle FEA (Functional Entity Action). Les FEA sont des processus 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'infrastructure 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 intelligent. Les principales entits fonctionnelles sont intimement lies la logique de mise en uvre du service (voir figure 8.3) :
346
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 tlphoniques 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 informations associes aux abonns d'un service RI. La SCF a la possibilit de consulter et de
347
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 Management Function) permet l'oprateur d'administrer ses services RI ; la SMAF (Service 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 (Service Control User Agent Function) et CUSF (Call Unrelated Service Function), ncessaires 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 dtecter 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 traitement 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 traitement d'appel tlphonique. Elle dtecte les vnements susceptibles de dclencher un service rseau intelligent. Cette entit contrle galement les appels et les connexions
348
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 modlises 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 permettant 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 INSSM 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
349
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 compatibilit 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 (Connection 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 Segment 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 attente 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 servant 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 standards 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 transportent des signaux internes permettant d'changer des informations entre deux segments 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 raccordement (toujours reprsent en traits pleins sur les schmas) ;
3. On parle alors de CPH.
350
N -
leg
CP v
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)
351
Figure 8.5. Les diffrents tats CSCV
352
- 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'tablissement. 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 arrive 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 utilisateur, 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'tablissement 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
353
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 Dtection 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
354
SSF-SCF contrle DP arm TDP
relation
de SSF-SCF relation de supervision
statiquement TDP-R ( Trigger Dtection TDP-N ( Trigger Dtection Point Request) Point Notification)
DP arm dynamiquement EDP-R ( Event Dtection EDP-N (Event Dtection EDP Point Notification) Point Request) 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 appel 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 permette 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.
355
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 automate 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 intelligent. 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
356
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'utilisation 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 message 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 Terminating 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
358
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 mesure 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 toujours 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'interface 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.
359
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 services 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
360
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 tarification 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'ouverture 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 CAMEL 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 tlcommunications 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 terminologie 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 supplmentaire existante tait possible en phase 2 mais seulement pour un nombre limit de services supplmentaires. CAMEL phase 3 accrot l'ensemble des services supplmentaires 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.
361
4 permet le routage optimal pour les appels du domaine circuit tablis de mobile mobile. 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 typiquement 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 demandes 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.
362
RNC
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 Switching 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.
363
CSI D-CSI
Critre de dclenchement du service CAMEL
Lieu de stockage en dehors HLR du rseau nominal
Liste de dix numros personnaliss permettant de VLR du rseau vidclencher 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 nouveau 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 vientrant parvenu un GMSC, ou appel renvoy au sit, GMSC niveau d'un MSC du rseau visit ou d'un GMSC MO-SMSenvoi d'un message court VLR du rseau viCSI 12 sit, SGSN MT-SMS-CSI rception d'un message court VLR du rseau vi(phase 4) sit, SGSN Activation d'un service supplmentaire SS-CSI 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 terminologie 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 numro compos) ; - l'tat de la marque (active/inactive).
364
8.4. CAMEL et le domaine circuit 8.4.1. 8.4.1.1. Les automates CAMEL phase 3 du domaine circuit 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, correspond un tat neutre : aucun service n'est dclench, le rseau est en train de dterminer 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 analyses 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'appel 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 dcroch ;
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.
Les architectures de services de
l'UMTS
365
- 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 rseau 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'appel. 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 recevoir 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;
366
O.Disconnect
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
367
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 changement 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
368
0_Mid_call
0_Change_Of_Position
Figure 8.12. Automate O-BCSM CAMEL phase 4 d'aprs 3GPP 23.078 v5.0.0
369
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 services 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 dclencher 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
370
rseau GPRS. Les standards CAMEL dfinissent deux situations o un service CAMEL peut tre dclench : - lors de l'attachement d'un terminal au domaine paquet (par exemple, pour vrifier 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 utilisateur 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'attachement 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'attachement 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 paquet. 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'envoi 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;
371
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 requt 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'vnements 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 rseau ;
372
Mobile
SGSN
GGSN
SCF
HLK
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.
373
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 prpay. 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.
374
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 commencer 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 service 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 procdure 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.
375
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.
376
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 communiquer 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 informations 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.
377
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.
378
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 (Transmission 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.
379
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 galement 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.
380
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'enregistrement 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'origine) ; - Les I-CSCF (Interrogating Call Session Control Function) ont une fonction similaire 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'utilisateur 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 fonctionnement du systme IMS (IP multimdia Subsystem). Le HSS est une gnralisation
381
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 figure 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 Function) joue un rle similaire la gsmSSF et la gprsSSF. Elle est plac sur un quipement 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 beaucoup 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'intermdiaire. 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.
382
travers des interfaces standardises au niveau de l'intergiciel, appeles API (Application 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 applicatifs 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 signalisation (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 ensemble d'interfaces contenant les mthodes invocables par les applications. Les interfaces se subdivisent en deux familles. La premire famille d'interfaces permet d'accder 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 fonctions rseau accessibles depuis les SCS facilite le dveloppement de nouvelles applications 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'utilisation de OSA, il n'entre pas dans le cadre de la norme de standardiser toutes les offres de services.
383
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 suivantes : 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.
384
- l'interface d'activation et de notifications d ' v n e m e n t s permet une application 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'instance 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

23.127, 3GPP, 1999.
2.
Rapport n TS
|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 (Release 5), Rapport nTS 23.078, 3GPP, 2002. |3GP ()2c| 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) - stage 2 (Release 99), Rapport nTS 23.078, 3GPP, 2002. |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.
385
[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.
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.
388
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.
390
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.
391
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.
392
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-1
ID-000 plug-in
Mini UICC
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.
393
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.
394
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 plateforme 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.
395
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).
396
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
Process
*
Carte
Commentaire
L'volution des processeurs bnficie de la mme faon aux 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 d'ide, un mobile en 2004 a une capacit de l'ordre d'un 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.
Capacit mmoire
Portabilit
L'utilisateur peut retrouver ses donnes personnelles, son 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 en local sans que les donnes utilises puissent tre accessibles de l'extrieur.
Scurit
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 ?
397
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) environnement applicatifs ; [29] protocoles, navigateur et
- 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.
398
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
399
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.).
400
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.
401
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
402
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 portemonnaie 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.
403
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.
404
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].
405
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
406
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).
407
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.
408
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.
409
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.
410
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.
411
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
412
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
413
ce dernier cas, si les couches basses sont bien spcifies, les couches applicatives sont restes propritaires. Systme Support Dbit Origine Type d'applications
Lien vers un PC
supports de communication en local Bluetooth Carte sans contact Radio

720 kbit/s
Industrie
Lien vers des priphriques divers (camra, photo...) Lien vers un PDA Transport Terminal modem utilis comme un d'un
Radio
424 kbit/s
ISO
IrDA
Infrarouge
115 kbit/s
Industrie
Echange d'informations mobile un autre Lien vers un PDA Lien vers un PC
Connexion physique Priphrique interne Circuit switched Data GPRS IP Multimedia Subsystem (IMS) Wi-Fi
USB, srie... Contacts ISO
Jusqu' 12 Mbit/s 9,6 115 kbit/s
Industrie... ISO
Lien vers des priphriques divers (camra, photo...) Lecteur de carte supplmentaire (bancaire)
supports de communication en rseau

jusqu' 9,6 kbit/s Jusqu'environ 50 kbit/s
3GPP
Radio
Prvu pour supporter tout type de transfert de donnes (y compris la voix sur IP) Jusqu' 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 ;
414
- 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
415
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
416
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.
417
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
418
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]
[2]
TS 23.101
TS 22 0 5 7 / 2 3 0 5 7
General UMTS Architecture

Mobile Station Application Execution Environment (MExE)
419
Documents lis VHE [3] [4] TS 22.121/23.127 TR 23.957

Virtual Home Environment Virtual Home Environment (VHE) concepts
Documents lis au SIM TS 02.19/03.19 TS 42.019/43.019 TS 02.48/03.48 TS 22.018/23.048 TS 11.11 TS 51.011 TS 11.14 TS 51.014
Subscriber Identity Module Application Programming Interface (SIM API) SIM API for Java Card Security Mechanisms for the SIM Application Toolkit Spcification of the Subscriber Identity Module Mobile Equipment (SIM - ME) interface SIM Application Toolkit (SAT)
[5]
[6]
[7]
[8]
Documents lis au USIM/ISIM [9] [10] [H] [12] [13] [14] TS 31 .101 TS 31 .102 TS 31 .103 TS 31 .111 TS 31 .112/13/14 TS 31 .130
UICC - Terminal Interface; Logical and Physical Characteristics Characteristics of the USIM Application Characteristics of the ISIM Application USIM Application Toolkit (USAT) USAT Interpreter USIM API
Documents maintenus par le SCP Documents lis l'UICC [15] [16] [17] [18] TS 102 221 TS 102 223 TS 102 241 TS 102310 EAP support in UICC Smart Cards: UICC Terminal interface; Physical and logical characteristics
420
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/internetdrafts/draft-urien-eap-smartcard-03.txt) draft-arkko-pppext-eap-aka-11, "EAP AKA Authentication". http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-akall.txt draft-haverinen-pppext-eap-sim-12, "EAP SIM Authentication".http://www.ietf.org/internet-drafts/drafthaverinen-pppext-eap-sim-12.txt
[21]
IETF draft
[22]
IETF draft
9.7.2.2. Sites Web pour plus d'information

O r g a n i s m e s de standardisation : [23] [24] [25] 3GPP 3GPP2 ETSI http://www.3gpp.org/ http://www.3gpp2.org/ 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] [28] [29] Java Card Forum Java Community Process Open Mobile Alliance http://www.javacardforum.org/ http://www.jcp.org/en/home/index http://www.openmobilealliance.org les spcifications WAP/OMA sont disponibles http://www.wapforum.org/what/technical.htm Alliance de fournisseurs de fournisseurs de cartes puce http://www.simalliance.org/ Alliance de fournisseurs de mobiles autour d'une solution dveloppe l'origine pour des organiseurs PSION http://www.symbian.com/ Alliance d'industrie dfinissant un standard de synchronisation entre terminaux : http://www.syncml.org/
[30] [31 ]
SIM Alliance Symbian
[32]
SyncML
421
Socits mentionnes : [33] [34] AvantGo Microsoft http://www.avantgo.com/ les documents smartphone sont disponibles sur : http://www.microsoft.com/mobile/ smartphone/ les documents i-mode sont accessibles partir de : http://www.nttdocomo.com/home. html Pal Voir les sites web : http://www.palmone.com/ m (socit dveloppant les terminaux) et http://www.palmsource.com/ So (socit dveloppant les logiciels urc e [37] Sun Microsystems les documents Java (et ses diffrentes dclinaisons) sont disponibles sur http://java.sun.com/
[35]
NTT DoCoMo
[36]
PalmOne &
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.
424
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
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.
426
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 ;
427
- 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
IMSI
MNC
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.
428
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. Fonction fO fl Type Gnration d'ala Fonction d'authentification du rseau message de resynchronisation authentification de l'utilisateur Nature Donnes d'entre K, SQN, RAND, AMF MAC K, RAND, AMF RES XRES ou RES selon que le calcul est fait dans l'AuC ou l'UICC Donnes en sortie RAND MAC Commentaire
fl* f2
f3 f4 f5 f5*
cl de chiffrement drive cl de calcul d'intgrit drive drivation cl anonyme de chiffrement drive message de resynchronisation (cas de la cl anonyme)
CK IK AK AK Optionnel Optionnel
Tableau 10.1. Les diffrentes fonctions de base de MILENAGE
429
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.
430
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 RAND
Rseau
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.
431
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
432
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.
433
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 Sender UE or RNC
XMAC-I Receiver 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
434
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].
435
Sender UE or RNC
Receiver 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.
436
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
437
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.
438
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.
439
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.
440
10.4.2. UICC et USIM Une volution importante en troisime gnration est la cration d'une plateforme 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 plateforme : 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.
441
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.
442
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 mode push, 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)
443
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.
444
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.
445
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.
446
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 multipropritaires ?
447
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).
448
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 cidessus). 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 ;
449
- 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 ;
450
- 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).
451
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.
452
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 parefeu 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.
453
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
454
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 p. 288-296, 2000. [DAR 01] DAEMEN J., RUMEN V., Rijndael, the advanced encryption standard
Smart Card Research and Applications, LNCS 1820, J.-J. Quisquater et B. Schneier (dir.)., Springer-Verlag, Dr. Dobb 's
Journal, vol. 26, n 3, p. 137-139, 2001.
455
10.10.2. Spcifications - Standards Documents maintenus par le 3GPP

[21.133] [31.103] [33.102] [33.105] TS 21.133 TS 31.103 TS 33.102 TS 33.105
3G Security; Security Threats and Requirements
ISIM Characterstics
3G Security; Security Architecture
3G Security; Cryptographie Algorithms 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] [33.203]
TS 33.120 TS 33.203
3G Security; Security Principles and Objectives Access security for IP-based services Generic Authentication Architecture (GAA), Generic bootstrapping architecture Support for subscriber certificates Access to network application Wireless Local Area Network (WLAN) interworking security Security of the Multimedia Broadcast / Multicast Service Feasibility Study on (U)SIM Security Reuse by Peripheral Devices on Local Interfaces A Guide to 3rd Gnration Security Criteria for cryptographie algorithm design process Formai Analysis of the 3G Authentication Protocol General Report on the Design, Spcification and Evaluation of 3GPP Standard Confidentiality and Integrity Algorithms
Report on the Design and Evaluation of the M1LENAGE Algorithm Set; Deliverable 5: An Example Algorithm for the 3GPP
[33.220]
TS 33.220/1/2
[33.234] [33.246]
TS 33.234 TS 33.246
[33.817] [33.900] [33.901] [33.902]
TR 33.817 TR 33.900 TR 33.901 TR 33.902
[33.903]
TR 33.903
[33.909] [33.919]
TR 33.909 TR 33.919
Authentication and Key Gnration Functions Generic Authentication Architecture (GAA);
456
System Description Spcification of the 3GPP Confidentiality and Integrity Algorithms: Document 1 : f8 and f9 spcifications Document 2: KASUMI algorithm spcification 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 Integrity Algorithms Lawful Interception requirements for GSM Lawful Interception; Stage 1 Lawful Interception ; Stage 2
[35.201]
TS 35.201/2/3/4/5/9
[35.209]
TS 35.209 TS 41.033 TS 42.033 TS 43.033
[41.033]
Documents maintenus par l'ETSI

Tlcommunications security; Lawful Interception (LI);
[LI1]
TS 101 331
Handover interface for the lawful interception of tlcommunications traffic
[LI2]
TS 101 671
Tlcommunications security; Lawful interception (LI) Handover interface for the lawful interception of tlcommunications traffic Tlcommunications security; Lawful Interception (LI); Description ofGPRS HI3 Tlcommunications security; Lawful Interception (LI); Concepts of Interception in a Generic Network Architecture Tlcommunications security; Lawful Interception (LI); Issues on IP Interception Tlcommunications security; Lawful Interception (LI); Requirements for network fonctions
[LI3]
TR 101 876
[LI4]
TR 101 943
[LES]
TR 101 944
[LI6]
ES 201 158
457
[LI7]
ES 201 671
Tlcommunications security; Lawful Interception (LI); Handover interface for the lawful interception of tlcommunications traffic
Autres documents
rjg^ j ^
J S R 177
Ce document gr par le Java Community Process, voir http://jcp.org/en/jsr/detail7id =177
10.10.3. Sites Internet [W3G] 3GPP http://www.3gpp.org/ http://www.etsi.org/ [WET] ETSI http ://portal.etsi.org/Portal_Common/home.as p (accs au pages du groupe SAGE par exemple) http ://www.gsmworld.com/ http://www.globalplatform.org/ Accs aux informations concernant MISTY http ://www.mitsubishi.com/ ghp J apan/m isty/index .htm http://www.simalliance.org http://www.openmobilealliance.org les spcifications WAP/OMA sont disponibles http://www.wapforum.org/ what/technical.htm
[WGA] [WGP] [WMI] [WSA]
GSM Association GlobalPlatform Mitsubishi SIM Alliance
[WOM]
Open Mobile Alliance
[WAS]
Wassenaar arrangement http://www.wassenaar.org/
Glossaire
3G 3G-GGSN 3GPP 3GPP2 3G-SGSN 8PSK AAL AD AES AF AHP AI AICH AKA ALCAP AMD ANM AP AP-AICH API API APN ARQ AS AS ASN.l
Rseau cellulaire de 3e Gnration GGSN spcifique l'UMTS 3rd Gnration Partnership Project 3rd Gnration Partnership Project 2 SGSN spcifique l'UMTS 8 Phase Shift Keying ATM Adaptation Layer Adjunct Adjunct Advanced Encryption Standard Assured Forwarding Amplificateur Haute Puissance Acquisition Indicator Acquisition Indicator Channel Authentication and Key Agreement Access Link Control Application Part Acknowledged Mode Data (mode du protocole RLC) Answer Message Access Preamble Access Preamble Acquisition Indicator Channel Access Preamble Indicator Application Programming Interface Access Point Name Automatic Repeat reQuest Access Stratum (contexte UTRAN) Application Server Abstract Syntax Notation 1
460
ATM AUTN AWGN BCH BCM BCP BCSM BCUSM BDFE BE BER BGCF BLE BLER BMC BPSK BSC BSIC BTS CA CAI CAMEL CAP CCAF CCC CCF CCPCH CCTrCH CD CD/CA-ICH CDI CDMA CEC CGF CHV
Asynchronous Transfer Mode Authentication Token Additive White Gaussian Noise Broadcast Channel Basic Call Manager Basic Call Process Basic Call State Model Basic Call Unrelated State Model Block Dcision Feedback Equaliser Best Effort Bit Error Rate Breakout Gateway Control Function Block Linear Equaliser Block Error Rate Broadcast/Multicast Control Binary Phase Shift Keying Base Station Control 1er Base Station Identity Code Base Transceiver Station Channel Assignment Channel Assignment Indicator Customized Applications for Mobile network Enhanced Logic CAMEL Application Part Call Control Agent Function CPCH Control Command Call Control Function Common Control Physical Channel Coded Composite Transport Channel Collision Dtection Collision Detection/Channel Assignment Indicator Channel Collision Dtection Indicator Code-Division Multiple Access Concatenated Extended Complementary Charging Gateway Function Card Holder Vrification (appel aussi PIN)
Glossaire
461
CID CM CP CPCH CPH CPICH CQI CRNC C-RNTI CS CS CS CSA CSCV CSD CSE CSI CSICH CUSF CV CVS DCA DCH DFT DHCP DL DNS DP DPC DPCCH DPCH DPDCH DRNC DSCH DTMF
Channel Identifier Connection Management Connection Point Common Packet Channel Call Party Handling Common Pilot Channel Channel Quality Indicator Controlling RNC (Radio Network Controller) Cell Radio Network Temporary Identity Call Segment (contexte rseaux intelligents) Capability Set (contexte rseaux intelligents et CAMEL) Circuit-Switching (contexte UMTS) Call Segment Association Call Segment Connection View Circuit Switched Data (transmission) CAMEL Service Environment CAMEL Subscription Information CPCH Status Indicator Channel Call Unrelated Service Function Connection View Connection View State Dynamic Channel Allocation Dedicated Channel Discrte Fourier Transform Dynamic Host Configuration Protocol Downlink Domain Name Server Dtection Point Distributed Power Control Dedicated Physical Control Channel Dedicated Physical Channel Dedicated Physical Data Channel Drift RNC (Radio Network Controller) Downlink Shared Channel Dual Tone Multiple Frequency
462
DTX DwPTS EAP EDP EDP-N EDP-R EF EFR EIR EP SCP EQM ETSI FACH FBI FCSS FDD FDMA FEA FEC FER FFT FIM-CM FSW GGSN GMM GMSC GPRS GPRS-CSI gprsSSF GPS GSM gsmCCF gsmSCF gsmSRF gsmSSF
Discontinuous Transmission Downlink Pilot Time Slot Extensible Authentication Protocol Event Dtection Point Event Dtection Point Notification Event Dtection Point Request Expedited Forwarding Enhanced Full Rate Equipment Identity Register Etsi Project Smart Card Platform Erreur Quadratique Moyenne European Tlcommunications Standards Institute Forward Access Channel Feedback Information Fast cell site selection Frequency-Division Duplex Frequency-Division Multiple Access Functional Entity Action Forward Error Correction Frame Error Rate Fast Fourier Transform Feature Interaction-Call Manager Frame Synchronization Word Gateway GPRS Support Node GPRS Moblility Management Gateway Mobile-services Switching Centre General Packet Radio Service GPRS CAMEL Subscription Information GPRS Service Switching Function Global Positioning System Global System for Mobile Communications GSM Call Control Function GSM Service Control Function GSM Service Resource Function GSM Service Switching Function
Glossaire
463
GSN GTP GTP-C GTP-U HDSL HLR HPLMN HS-DPCCH HS-DSCH HS-PDSCH HSS HS-SCCH HTML HTTP IAM ICH ICMP ICQ I-CSCF IDFT IES IETF IM-CSI IMEI IMS IM-SSF IN INAP IN-SSM IP IP IrDA ISDN ISIM ISUP
GPRS Support Node GPRS Tunneling Protocol GTP Control Plane GTP User Plane High-bit rate Data Subscriber Line Home Location Register Home PLMN High Speed Dedicated Physical Control Channel High-Speed Downlink Channel High Speed Physical Downlink Shared Channel Home Subsriber Server High Speed Shared Control Channel HyperText Markup Language Hyper Text Transfer Protocol Interfrence d'Accs Multiple Indicator Channel Internet Control Message Protocol Systme de discussion I Seek You Interrogating Call Session Control Function Inverse Discrte Fourier Transform Interfrence entre symboles Internet Engeneering Task Force IP Multimedia Camel Subscription Information International Mobile Equipement Identity IP multimdia Subsystem IP Multimedia-Service Switching Function Intelligent Network Intelligent Network Application Part Intelligent Network Switching Manager Intelligent Peripheral (contexte rseaux intelligents) Internet Protocol Infrared Data Association Integrated Services Digital Network Ims SIM ISDN User Part
464
IT ITU J2ME J2SE K KASUMI KVM LLC LS M3UA MAC MAC MAP MBMS MCC ME MExE MGCF MGW MIC MM MMS MMSE MNC MO-SMS-CSI MPLS MRF MS MSC MSIN MSRN MT MTP MTP3b
Intervalle de temps International Tlcommunication Union Java 2 Mobile Edition Java 2 Standard Edition Cl de l'utilisateur, correspond au Ki du GSM Algorithme de chiffrement bas sur MISTY ralisant les fonctions f8 et f9 K (for kilobyte) Virtual Machine (voir J2ME) Logical Link Control (GPRS) Least Square SS7 MTP3-User Adaptation Layer Mdium Access Control (contexte protocoles) Message Authentication Code (contexte scurit) Mobile Application Part Multimedia Broadcast / Multicast Service Mobile Country Code Mobile Equipment Mobile Execution Environment Media Gateway Control Function Media Gateway Modulation par impulsions et codage Mobility Management Mobile Multimedia Service Minimum Mean Square Error Mobile Network Code Mobile Originated Short Message Service CAMEL Subscription Information Multi Protocol Label Switching Media Resource Function Mobile Station (terme GSM) Mobile services Switching Center Mobile Subscriber Identity Number Mobile Station Roaming Number Mobile Termination Message Transfer Part Message Transfer Part 3 broadband
Glossaire
465
MT-SMS-CSI MUI NAP NAS NAT NBAP NNI NRT NRZ NSAPI OBCSM OCCRUI OCCUUI O-CSI OS OSA OSI OVSF P2P PC PC P-CCPCH PCH PCPCH P-CSCF PDA PDCP PDN PDP PDSCH PDU PG PIA PIC PICH
Mobile Terminated Short Message Service CAMEL Subscription Information Mobile User Identifier Network Access Point Non Access Stratum Network Address Translator Node B (Application Part) Network to Network Interface Non Real Time Non remis zro Network Service Access Point Identifier Originating BCSM Out of Channel Call Related User Interaction Out of Channel Call Unrelated User Interaction Originating CAMEL Subscription Information Operating System Open System Architecture Open System Interconnection Orthogonal Variable Spreading Factor Peer-to-Peer Point Code (contexte SS7) Power Control (contexte rseaux cellulaires) Primary- Common Control Physical CHannel Paging Channel Physical Common Packet Channel Proxy Call Session Control Function Personal Digital Assistant Packet Data Convergence Protocol Packet Data Network Packet Data Protocol Physical Downlink Shared Channel Protocol Data Unit Priode de garde Point In Association Point In Call Page Indicator Channel
466
PIN PLMN PN PPP PRACH PS PS PSC P-TMSI PTS PVC QPSK RAB RACH RANAP RI RLC RNC RNIS RNS RNSAP RNTI RRC RSB RSI RT RTCP RTP SAGE SAT SCCP S-CCPCH SCE SCEF SCF
Personal Identification Number (appel aussi CHV) Public Land Mobile Network Pseudo Noise Point to Point Protocol Physical Random Access Channel Packet Switching (en UMTS) Point smaphore (contexte SS7) Primary Synchronisation Code Packet Temporary Mobile Subscriber Identity Point de transfert smaphore Permanent Virtual Circuit Quadrature (ou Quaternary) Phase Shift Keying Radio Access Bearer Random Access Channel Radio Access Network Application Part Rseau intelligent Radio Link Control Radio Network Contrler Rseau numrique intgration de services Radio Network Sub-system Radio Network Subsystem Application Part Radio Network Temporary Identity Radio Resource Control Rapport signal bruit Rapport Signal sur Interference Real Time RTP Control Protocol Real Time Protocol Security Algorithm Group of Experts SIM Application Toolkit Signalling Connection Control Part Secondary Common Control Physical Channel Service Cration Environment Service Cration Environment Function Service Control Function
Glossaire
467
SCH SCP SCS S-CSCF SCTP SCUAF SDF SDP SDP SDSL SDU SF SFN SGSN SI SIB SIM SIP SIR SM SMAF SMF SMLC SMP SMS SMS-CSI SMS-GMSC SMTP SN SNDCP SP SRF S RNC SS7
Synchronisation Channel Service Control Point Service Cration Server Serving Call Session Control Function Stream Control Transmission Protocol Service Control User Agent Function Service Data Function Service Data Point Session Description Protocol Single-line Digital Subscriber Line Service Data Unit Spreading Factor System Frame Number Serving GPRS Support Node Status Indicator Service Indpendant Building Block Subscriber Identity Module Session Initiation Protocol Signal-to-Interference Ratio Session Management Service Management Agent Function Service Management Function Service Mobile Location Centre Service Management Point Short Message Service Short Message Service CAMEL Subscription Information Short Message Service InterWorking MSC Simple Mail Transfer Protocol Service Node Sub-Network Dpendant Convergence Protocol (GPRS) Signalling Point (PS, en franais) Service Resource Function Serving RNC (Radio Network Controller) Signalisation smaphore n 7 (Signalling System 7) Secondary Synchronisation code
ssc
468
SSCF-NNI SSCOP SSDT SSF SSP STP STTD SVC TA TBCSM TBS TCAP TCP T-CSI TCTF TD-CDMA TDD TDMA TDP TDP-N TDP-R TD-SCDMA TEB TEID TFCI TFT TMSI TNUP TPC TRAU TrD TRX TSTD TTI UDP
Service Spcifi Coordination Function for Network to Network Interface Service Spcifi Connection Oriented Protocol Site Selection Diversity TPC Service Switching Function Service Switching Point Signalling Transfer Point Space Time Transmit Diversity Switched Virtual Circuit Time Alignment Terminating BCSM Transport Block Set Transaction Capabilities Application Part Transmission Control Protocol Terminating CAMEL Subscription Information Target Channel Type Field Time Division Synchronous Division Multiple Access Time-Division Duplex Time-Division Multiple Access Trigger Dtection Point Trigger Dtection Point Notification Trigger Dtection Point Request Time Division-Space Code Division Multiple Access Taux erreur binaire Tunnel Endpoint IDentifier Transport Format Combination Indicator Traffic Flow Template Temporary Mobile Subscriber Identity Transport Network User Plane Transmit Power Control Transcoder/Rate Adaptation Unit Transparent Mode Data (mode du protocole RLC) Transceiver Time Switched Transmit Diversity Transmission Time Interval User Datagram Protocol
Glossaire
469
UE UICC UL UMD UMTS UNI UpPTS U-RNTI USAT USIM USSD UTRA UTRAN VCI VGCS VHE VLR VMSC VPI W3C WAE WAP WCDMA WiFi WIM WLAN WML XHTML ZF
User Equipment Universal Integrated Circuit Card Uplink Unacknowledged Mode Data (mode du protocole RLC) Universal Mobile Tlcommunications System User to Network Interface Uplink Pilot Time Slot UTRAN Radio Network Temporary Identity Usim Application Toolkit Universal SIM Unstructured Supplementary Service Data UMTS Terrestrial Radio Access UMTS Terrestrial Radio Access Network Virtual Channel Identifier Voice Group Call Service Virtual Home Environment Visitor Location Register Visited Mobile services Switching Center Virtual Path Identifier World Wide Web Consortium Wireless Application Environment Wireless Application Protocol Wideband Code Division Multiple Access Wireless Fidelity WAP Identity Module Wireless Local Area Network Wireless Markup Language eXtended HTML Zro Forcing
Index
3G-GGSN, 288-289, 290, 292, 310311,314,319 3G-SGSN, 284-285, 288-290, 292, 29-295, 302-304, 307, 309-311, 313,315-319, 321 A A AL, 230, 231,269 AAL5, 231, 232, 235, 243-244, 246, 289 accs alatoire, 69, 89, 179, 260 Access Stratum, 236, 255, 286 AICH, 69, 89, 90 ALCAP, 237, 239, 242, 260, 263 AMC, 97, 98 AMR, 75, 76 AP-AICH, 69 API, 386, 391, 395, 399, 400, 405, 407,419 APN, 281 ,297-298, 324,332 appel, 62, 68, 142, 188, 222, 226, 231,236, 257, 259,305-306 ATM, 215, 219, 220, 228-230, 232, 234, 235, 237, 240, 242-244, 248251, 258-270, 283, 287, 289, 326, 329,333,335 attachement, 294 AWGN, 27, 32, 34, 108, 122, 125, 135
B BCCH, 79, 80,81,85,87- 89 BCH, 76-77, 80, 85, 241, 257-258 BCM, 348 BCP, 345 BCSM, 344, 348-349, 350-354, 357, 359, BCUSM, 355 bearer, 72, 75, 237-238, 259-260, 262, 285-286 Bearer Independent Protocol, 403, 412 ,414 bearer UMTS, 327 BG, 291,322 B-ISDN, 229, 269 BPSK, 22, 25-26 BSC, 216-218, 273,277 BTS, 107 ,216 -218 burst, 115-122, 145 C CAMEL, 294, 310, 337, 339-341, 346, 355, 358-374, 377, 380-381, 407 canal AWGN, 27, 32, 34, 108 canal smaphore, 225, 232 CAP, 341, 361, 364, 371-377, 382,
472
Care Of Address, 322 CCAF, 346 CCCH, 79,81 CCF, 342, 346-349, 353-355, 356357,359, 361-362,381 CCITT n7, voir SS7 CCTrCH, 73 CD/CA-ICH, 69,454 CDMA, 19, 39, 42, 44, 48-51, 53, 56, 69, 98, 105-108, 111-113, 121, 131-132, 141, 150,-151, 153-155, 157-158, 160, 165, 168, 171, 177, 185, 187-190, 192-193, 197, 202, 206-207, 209-212 CELL_DCH, 91 CGF, 292 chip, 29-30, 34-35, 38-39, 41- 42, 4647,49-50, 86, 113, 118, 123 CID,231-232, 237 classes de services, 227, 231, 326, 329,331-332 code d'embrouillage, 48, 56, 64, 67, 69-70, 85, 110, 116, 119 codes orthogonaux, 109, 111 contexte PDP, 97, 276-278, 289, 297, 299, 307, 309-316, 321, 324-325, 327,330-331 contexte (activation), 281-282, 298, 300-311,314,316 corrlateur, 34, 36-37, 121, 128 couche ATM, 230, 243, 245, 250 couverture, 94, 102, 112, 187, 188189, 192, 193, 207, 209-210, 266 CPICH, 67, 86-88, 96 Critres S et R, 87-89 C-RNTI, 80 ,81,262 CS (Capability Set), 342-344, 354356, 360
CS (Call Segment), 347, 349, 350 CS (interface Iu-CS), 242, 248 CS (domaine), 287, 305-306 CSA, 349-350, 356 CSI, 362, 363,371,374 CSCV, 344, 349, 3 5 0 , ^ 1 , 354, 356 CSICH, 69 CTCH, 80,81 D DCA, 110, 113, 142-144, 252, 256, 455 DCCH, 80, 82-83, 85, 262 DCH, 75-77, 80-82, 99, 241-258, 260, 262, 264, 266 dtachement, 303, 304 dtection conjointe, 105, 107, 109, 111 ,121, 132, 135, 138-141 DiffServ, 326, 329,331-332 DNS, 291,298,316 DP, 353-354, 356-358, 370-372, 374, 375-378 DPCCH, 58, 62-63, 69, 82, 172-173, 175-177 DPCH, 58, 61, 63, 77, 81, 173-174, 179,180 DPDCH, 58, 62-64, 76, 82-83, 172173,175, 177 D-RNC, 222 DSCH, 77, 80, 82, 85, 97-98, 101, 241,245,253 DTCH, 80, 82-83
E
EAP, 391,415-416, 444 EAP AKA, 395, 420,444 EDP, 353-354, 356-358
Index
473
EFR, 74 galiseur, 135, 136 talement de spectre, 19, 21, 27, 29, 32-33,35,37-39, 44, 190, 221 Etats PMM, 301 F FACH, 62, 76-77, 80-82, 91, 241, 245, 256-260, 262 facteur d'activit, 192, 197-198,213 facteur d'augmentation de bruit, 194, 197, 203 facteur d'talement, 29, 31, 33, 39, 46, 53, 60, 62, 64, 67, 69, 82, 9899, 106, 107, 110-111, 159, 183 facteur de charge, 194-197, 199, 201, 204, 205-206, 209 FBI, 63, 172 FCSS, 100-101 FEA, 345, 346 format de transport, 53, 64, 70-75, 77, 78 G GGSN, 277-282, 284, 289, 290-292, 296, 298-299, 304, 307-316, 319, 321-322, 324-325, 327, 330, 362, 372,374-375,381 GMM, 371-372 GMSC, 358, 363, 380 GLR, 284 GPRS, 355, 358, 360, 362-364, 368, 370-377,381 GSN, 277,288-291,319, 460 GTP, 238, 244, 250, 279, 280-281, 286, 289-290, 292-293, 308-309, 311,319, 321,374-375 GTP-C, 293
GTP-U, 244, 250, 286, 289, 290, 292-293,309,311,313,314 H Hadamard, 39-41,43, 134 handover, 53, 55, 91-96, 113, 144, 168, 171, 173, 209, 211, 216, "'222-223, 236, 239, 255-256, 267, 317, 321 hard handover, 91, 94, 266, 317, 321 HLR, 274-275, 277-278, 284, 289, 291, 294-295, 299, 301-303, 306, 310,316,319, 327, 330, 360,362, 363, 371, 372, 380, 383, 426, 436-437, 448,451-452 Home Agent, 322 HSDPA, 61. 96-102, 113,253 HS-DPCCH, 97, 99 HS-DSCH, 97-99, 101, 241-242, 245, 253 HS-PDSCH, 97 HSS, 380-381 I I-CSCF, 380-381 IMS, 334, 336, 380-381, 395, 413, 441 IN, 340, 348,353,365 INAP, 344, 347-349, 355, 356-357, 359 IP, 98, 212, 215, 219, 224, 234-235, 237, 244, 246, 250-252, 258, 271272, 275-277, 279, 280-282, 287, 289-291, 296-299, 309, 311-315, 322-325, 329, 330-338, 394-395, 413,439,441,455-456 IPv6, 55, 234, 270, 296, 299, 307, 309-310, 313-314, 322-334, 336, 338
474
IS-95, 32, 45-46, 48, 50-51, 92, 153 ISIM, 391 ,395 ,415,437, 451 ISUP, 226, 232, 305, 356-357, 359, 365, 382 lu, 220, 236-238, 242-244, 247, 250251, 259, 263, 265, 268-269, 286289, 294-295, 329, 334 Iub, 96, 100, 145, 184, 220, 237-238, 245-246, 250-251, 255, 259, 269 Iu-Cs, 220, 238, 242-244, 259 Iu-Ps, 220, 243-244 J J2ME, 390, 397-400, 401, 406, 411 J2SE, 390, 397, 406 Java, 390, 392, 397-401, 406, 4011, 412,419-421,445-446,456 Java Card, 397-401, 412, 419, 420 L leg, 349-350, 352, 354, 359 M M3UA, 235, 244, 246, 250-251, 270 MAC (couche), 53, 55-56, 59, 77-81, 98, 100-101, 105, 240, 241-242, 245, 247, 252, 262, 268 MAC (scurit), 428, 431-436, 438 MAP, 228, 273, 318-319, 372, 377, 382 ME, 388-389, 419, 445 Message Transfer Part, 225, 232, 270 mesures, 55, 67, 78, 82, 85-86, 89, 91-92, 94-95, 96, 101, 110, 143, 145, 172, 176, 179, 216, 246, 256-257, 264, 295,301 MExE, 341,383 ,405-407 ,418 MGCF, 380
MGW, 334, 380
midambule, 114-115, 121-125, 128129,139-140 mode compress, 60, 94, 95, 172-173 modulations, 20, 25, 57, 116 MRF, 380 MSC, 340, 358, 360-363, 374, 381, MSRN, 306 MT, 324,384-385,414 MTP, 225-227, 232, 234-235, 243, 246, 250, 269 MTP3b, 232, 235, 243, 246, 250, 269 multicode, 106, 107, 110-111 multitrajet, 27-29, 36-38, 42, 131132, 138, 147, 149
N
NAS, 236, 237-238, 243, 245, 247, 255, 260-262, 286 NAT, 290, 326 Near Far Effect, 107 node B, 218, 221 Noise Rise, 194, 203,213 Non-Access Stratum, voir NAS NSAPI, 293,311-315 O OBCSM, 350, 352, 364, OMA, 409, 412, 416, 418, 420, 440, 456 OSA, 341, 380, 382, 383, 384, 385, 403-404 OVSF, 43-44, 48, 56, 58, 67, 69-70, 110, 113,222, 260 P PCCH, 79-80
Index
475
P-CCPCH, 67-68, 76-77, 85, 114,

116
PCH, 77, 80, 241, 245, 257-258 PCPCH, 69, 175-176 P-CSCF, 380-381 PDA, 397, 408-409, 423 PDN, 275-277, 289-290, 296-297, 307,310-311,313 PDP, 97, 276, 277-278, 282, 293294, 302, 304, 307, 309-311,313316,319, 321,324 PDSCH, 60-61,77, 173 PIA,355, 368 PIC, 353, PICH, 68, 77 Pilot, 58, 63, 65, 67 PIN, 394, 403,427 PN, 108-109 PPP, 276, 296, 307, 309, 328 PRACH, 64-65, 77, 89-90, 114-115, 176, 179 PS (Packet Scheduling), 97, 101 PS (Point smaphore), 225-226 PS (Interface Iu-PS) 249-252 PS (domaine) 284, 287-289, 291, 295-296, 301-302, 307,317 PTS, 225 PVC, 219, 228 Q QPSK, 20, 22, 25-26, 29, 32, 57, 9899,113 quadrature, 19, 22, 24-26, 62, 82, 98 R RAB, 238-239, 243, 263-264, 267268, 286, 290, 306-307, 311,313, 315
RACH, 64, 69, 77, 80,-82, 90, 120, 145, 150, 241,245,256, 258-260, 262 relocalisation, 224, 258, 267, 268, 307,317, 321 rponse impulsionnelle, 28, 121-123, 127,133-134, 146-147, 149 rseau de transport, 219, 221, 232, 235-240, 242-245, 247, 250-251, 258, 276, 287, 290 rseau smaphore, 225-226, 244, 287 RNC, 54, 56, 82, 91-92, 96, 98, 100101, 142, 145-146, 171-172, 218224, 237-239, 241-243, 245-258, 260, 262-264, 267, 285, 288-290, 292,300-302, 307, 309,317-318 RNSAP, 246, 251,265,268 S SAT, 341, 383, 391, 398, 399, 415 SCCP, 226-227, 233, 235, 238, 243244, 246, 250-251,260 SCEF, 347 SCF, 342, 346-349, 352-354, 356, 357-359, 361-364, 371-372, 374, 376-377,380-381 SCH, 65-67, 84-95, 113-114, 116, 201,210-211 SCS, 382-384 S-CSCF, 380-381 SCTP, 235, 244, 246, 250-251, 270 squence d'apprentissage, 114, 119,
122
SCUAF, 347 SDF, 347, 356, 357 SDP, 378, 380 SF, 60, 63,83,99, 106, 111, 113 SGSN, 277-282, 284, 287-290, 292, 294, 298, 301-303, 308-311, 316,
476
319-322, 325, 331, 355, 360, 362363, 368, 370, 371-372, 374-377, 381 SIB, 345-346 SIM, 274, 389, 393-395, 399-401, 403, 419-420, 426, 431, 440-441, 443-444, 447 SIP, 333-334, 341, 377, 378, 379, 380, 385 slot, 56-58, 60, 62, 65-67, 69, 90, 173-176, 178, 181-182 SM, 374, 375, Smartphone, 390-391,397 SMF, 347 SMLC, 295 SMS, 360, 374, 375, 376, 377, 378, SMS-CSI, 363, 375 SMTP, 378 soft handover, 91-93, 100, 168, 171173, 175, 195, 209, 222-223, 264267 SRF, 347, 356, 358-359, 361-362 S-RNC, 222 SS7, 225-226, 235, 246, 270, 277, 291 SSCF-NNI, 232, 243-244, 246 SSCOP, 232, 243-246, 269 SSF, 346-349, 353-359, 361, 362, 364, 371,374,376,381 strate d'accs, 236 strate de non-accs, 236-237 Symbian, 390, 397, 399,420 symbole, 20-21, 23-26, 29, 32, 37-39, 57, 70, 98, 109, 117, 123, 136 SyncML, 400, 409, 420 T TA, 118
taxation, 277, 282, 289, 310-311 TBCSM, 352, 356-357, 359, 365, 367, 370 TCAP, 227-228 TCP, 96, 234-235, 280, 289, 290, 293,322, 378 TDD, 53, 84, 94-96, 105-108, 110114, 116-118, 120-122, 129, 130131, 141-146, 148, 150-151, 154, 170, 179-182, 184-185,317 TDP, 353-355, 357-358, 363 TD-SCDMA, 112, 118 TE, 324, 384-385, 388, 445 TEID, 308,312 TFT, 314 TPC, 58-59, 63-64, 117, 170, 172, 174-175, 177-178 transport bearer, 237, 259, 260, 262 TRAU, 217, 287 TRX, 216 tunnel GTP-U, 309-311, 313, 314 U UDP, 234, 238, 250-251, 280, 289, 293,311,314,378 UE, 54, 78, 81, 87, 101-102, 121, 171, 174, 176, 179, 184,388-389 UICC, 388-392, 395, 401, 403, 415, 426-427,434, 436-437, 442, 444 UMTS Bearer, 285 USAT, 402, 407,419 USIM, 302, 393-395, 399, 419, 426, 430, 434,440-441, 443, 446-448 USSD, 360, 363 V VCI, 228
Index
477
VHE, 294, 341, 385, 388, 407-408, 419 VLR, 362-363, 380-381 VMSC, 358 voie en phase, 19, 22, 24-26, 57, 64, 98 voie en quadrature, 19, 22, 24-25, 57, 64 VPI, 228
W WAE, 397,400, 402, 406 Walsh, 39-44, 48, 49, 69 WAP, 274, 298, 338, 390, 397, 399404, 402, 404, 406, 409, 412, 416, 418, 420, 440 WML, 400, 404
CET
OUVRAGE
COMPOS LTD
PAR ET
HERMS FLOCH
SCIENCE
PUBLISHING
ACHEV D'IMPRIMER PAR L'IMPRIMERIE
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 .

Principes Et Évolutions de l'UMTS

Transféré par

Droits d'auteur :

Formats disponibles

Principes Et Évolutions de l'UMTS

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

Principes Et Évolutions de l'UMTS

Transféré par

Droits d'auteur :

Formats disponibles

Principes et volutions de l'UMTS

Bretagne Rennes Sami T A B B A N E Sup'Com Tunis Tunisie

Table des matires

Chapitre 1. Introduction l'talement de spectre

Principes et volutions de l'UMTS

Chapitre 2. L'interface radio UTRA-FDD

Table des matires

Principes et volutions de l'UMTS

Table des matires

Principes et volutions de l'UMTS

Table des matires

Principes et volutions de l'UMTS

Table des matires

Introduction l'talement de spectre

Chapitre rdig par Xavier L A G R A N G E .

Principes et volutions de l'UMTS

Figure 1.1. Exemple d'un signal modul en QPSK

Introduction l'talement de spectre

Figure 1.2. Transmission d'un symbole

r g(t) = jJTs \ g(t) = 0

Si \t\ < Ts/2 si \t\ > Tl/2

Principes et volutions de l'UMTS

Sm{t) = (ej2/M+i*g (t) ej27rfct)

Introduction l'talement de spectre

On a donc : 2 p-t-OO g2{t)s2(27rfct)dt

En utilisant les formules trigonomtriques :

g2 ( t) cos (47T fct) dt =

g2(t) cos ( 2 ; T f c t ) sin (2T rf c t) dt

On peut en dduire, aprs quelques calculs lmentaires :

Principes et volutions de l'UMTS

avec, dans le cas d'une modulation de phase M tats :

Introduction l'talement de spectre

Figure 1.3. Modulations BPSK et QPSK

Principes et volutions de l'UMTS

Figure 1.4. Modle de transmission en BPSK et modle quivalent en bande de base

Introduction l'talement de spectre

Principes et volutions de l'UMTS

Introduction l'talement de spectre

Principes et volutions de l'UMTS

Figure 1.6. Principe de base de l'talement squence directe

Eb/Tb = Ec/Tc On en dduit aisment :

Introduction l'talement de spectre Densit spectrale de puissance

(y En exprimant cette densit en fonction de Eb, Tb et de n, on obtient :

Principes et volutions de l'UMTS

Introduction l'talement de spectre

C/N = -Eb/N0 n En chelle logarithmique, on obtient : (C/N)dB = (Eb/N0)iB - 101ogi 0 n

Principes et volutions de l'UMTS

Figure 1.8. Principe d'un rcepteur avec un corrlateur

Introduction l'talement de spectre

Figure 1.9. Exemple de rception d'une squence bruite

Principes et volutions de l'UMTS

Densit spectrale de puissance

Figure 1.10. Action du dstalement sur les spectres du signal et du bruit

Introduction l'talement de spectre

Figure 1.11. Principe du rcepteur Rake

Principes et volutions de l'UMTS

Figure 1.12. Intrt de l'talement de spectre pour un canal multirajets

Introduction l'talement de spectre

Principes et volutions de l'UMTS