Principes et évolutions de l'UMTS

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

fait partie de la série RÉSEAUX ET TÉLÉCOMS dirigée par Guy Pujolle

T R A I T É I C 2 INFORMATION - C O M M A N D E - C O M M U N I C A T I O N

SOUS la d i rec t ion sc ient i f ique de Be rna rd Dubuisson

Le traité Information, Commande, Communicat ion répond au besoin de disposer d'un ensemble complet des connaissances t fet méthodes nécessaires à la maîtrise des systèmes technologiques.

Conçu volontairement dans un esprit d'échange disciplinaire, le traité IC2 est l'état de l'art dans les domaines suivants retenus par le comité scientifique :

Réseaux et télécoms Traitement du signal et de l ' image Informatique et systèmes d ' information Systèmes automatisés et product ique Managément et gestion des STICS Cognition et trai tement de l ' information

Chaque ouvrage présente aussi bien les aspects fondamentaux qu'expérimentaux. Une classification des différents articles contenus dans chacun, une bibliographie et un index détaillé orientent le lecteur vers ses points d'intérêt immédiats : celui-ci dispose ainsi d 'un guide pour ses réflexions ou pour ses choix.

Les savoirs, théories et méthodes rassemblés dans chaque ouvrage ont été choisis pour leur pertinence dans l 'avancée des connaissances ou pour la qualité des résultats obtenus dans le cas d 'expérimentations réelles.

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 JOLIVET

LG Electronics Paris

Xavier LAGRANGE

ENST Bretagne Rennes

Philippe M A R T I N S

ENST Paris

Loutfi NUAYMI

E N S T Bretagne Rennes

Sami TABBANE

Sup'Com Tunis Tunisie

Table des matières

Chapitre 1. Introduction à l'étalement de spectre 19 Xavier LAGRANGE

1.1. Introduction 19 1.2. Rappels de communication numérique 20

1.2.1. Principes des modulations numériques 20 1.2.2. Modèle de transmission en bande de base 26 1.2.3. Action du canal de transmission 27

1.3. Etalement à séquence directe 29 1.3.1. Bits et chips 29 1.3.2. Bilan énergétique 30 1.3.3. Gain d'étalement 32 1.3.4. Récepteur en bande de base 33 1.3.5. Principes du récepteur Rake 36 1.3.6. Intérêt de l'étalement de spectre pour combattre les multitrajets . 37

1.4. Principe du multiplexage par des codes orthogonaux 39 1.4.1. Matrices d'Hadamard et codes de Walsh 39 1.4.2. Multiplexage par les codes 41 1.4.3. Codes OVSF 43

1.5. Utilisation du CDMA en radiomobile 44 1.5.1. Différenciation des stations de base 44 1.5.2. Principe de transmission sur la voie descendante 48 1.5.3. Principe de réception sur la voie descendante 49 1.5.4. Principe de transmission sur la voie montante 49

1.6. Bibliographie 51

10 Principes et évolutions de l 'UMTS

Chapitre 2. L'interface radio UTRA-FDD 53 Xavie r LAGRANGE et Sami TABBANE

2.1. Introduction 54 2.1.1. Architecture matérielle de l'UMTS 54 2.1.2. Architecture en couches 54

2.2. Caractéristiques générales de la couche physique de l'UTRA-FDD . . 56 2.2.1. Caractéristiques principales de l'UTRA-FDD 56 2.2.2. Trame de base 56 2.2.3. Modulation 58

2.3. Canaux physiques de données 58 2.3.1. Transmission descendante sur canal dédié (DPCH) 58 2.3.2. Canal physique descendant partagé (PDSCH) 60 2.3.3. Canal de diffusion de données (S-CCPCH) 62 2.3.4. Transmission montante sur canal dédié ? 62 2.3.5. Canal d'accès PRACH 64

2.4. Canaux physiques de contrôle 65 2.4.1. Canaux de synchronisation P-SCH et S-SCH 65 2.4.2. Canal pilote CPICH 67 2.4.3. Canal de diffusion des informations système (P-CCPCH) 67 2.4.4. Canaux d'indication depaging (PICH) 68 2.4.5. Canal d'acquittement de préambule (AICH) 69 2.4.6. Autres canaux physiques 69

2.5. Principes des chaînes de transmission 69 2.5.1. Chaîne de transmission sur la voie descendante 69 2.5.2. Chaîne de transmission sur la voie montante 70

2.6. Gestion de format de transport 70 2.6.1. Notion de format de transport 71 2.6.2. Combinaison de formats de transport 73 2.6.3. Variation dynamique des combinaisons de format de transport. . 74 2.6.4. Canaux de transport 76

2.7. Couche MAC 2.7.1. Fonctions de la couche MAC 77 2.7.2. Canaux logiques 79 2.7.3. Format des PDU de niveau MAC 80 2.7.4. Mode circuit et mode paquet 81

2.8. Synthèse sur les différents canaux de l'UMTS et exemples 82 2.8.1. Exemple de canaux de données 82 2.8.2. Canaux physiques, de transport et logiques 84

2.9. Procédures radio 84 2.9.1. Mécanisme de recherche de cellule 84 2.9.2. Veille sur une cellule 85

Table des matières 11

2.9.3. Accès (sur PRACH) 89 2.9.4. Gestion du handover 91

2.10. Transmission de données à haut débit (HSDPA) 96 2.10.1. Canaux logiques et physiques pour le support du HSDPA . . . . 97 2.10.2. Codage et modulation adaptatifs (AMC) 98 2.10.3. Technique HARQ 100 2.10.4. Fast cell site selection (FCSS) 100 2.10.5. Séquencement des paquets 101 2.10.6. Contraintes au niveau du nœud B et des terminaux 101

2.11. Conclusion 102 2.12. Références 102

Chapitre 3. Le mode UTRA-TDD et ses performances 105 Bruno JECHOUX

3.1. Philosophie de l'UMTS-TDD * 105 3.1.1. Effet proche-loin 107 3.1.2. Capacités du canal en UTRA-TDD et en UTRA-FDD 108 3.1.3. Gestion de l'interférence extra-cellulaire 110 3.1.4. Facteur d'étalement variable et multicode 110 3.1.5. Limitations du mode TDD 111

3.2. Introduction à la norme : TD-CDMA et TD-SCDMA 112 3.2.1. Caractéristiques d'UTRA-TDD à 3,84 Mchips 112 3.2.2. Canaux physiques 114 3.2.3. Procédures de la couche physique 117 3.2.4. Caractéristiques d'UTRA-TDD à 1,28 Mchips 118 3.2.5. Procédures spécifiques du 1,28 Mchips TDD 120

3.3. Estimation de canal multi-utilisateur 121 3.3.1. Description du problème 121 3.3.2. Modélisation 122 3.3.3. Les estimateurs de canaux : estimateur à maximum de vraisemblance/filtrage adapté 125 3.3.4. Choix des midambules 126 3.3.5. Mise en œuvre de l'estimateur de canal à maximum de vraisemblance 128 3.3.6. Performances de l'estimateur de canal à maximum de vraisemblance 129

3.4. Détection conjointe 131 3.4.1. Description du problème, modélisation 132 3.4.2. Critères de résolution du système d'équations linéaires 135 3.4.3. Performances de la détection conjointe 138 3.4.4. Réduction de la complexité de la détection conjointe 139


3.5. Allocation dynamique des ressources 141 3.5.1. Allocation des ressources aux cellules (DCA lente) 143 3.5.2. Allocation des ressources aux services (DCA rapide) 143

3.6. Synchronisation du réseau (3,84 Mchips TDD) 144 3.6.1. Présynchronisation par le réseau 145 3.6.2. Synchronisation fine par horloge de référence (de type G P S ) . . . 145 3.6.3. Mécanisme de synchronisation fine 145

3.7. Annexe : modélisation du canal radio mobile 149 3.8. Bibliographie 150

Chapitre 4. Le contrôle de puissance dans l'UMTS 153 Loutfi NUAYMI

4.1. Introduction 153 4.2. Présentation du modèle et formalisation du problème 154

4.2.1. Capacité et contrôle de puissance dans un réseau cellulaire CDMA 157 4.2.2. Classification des méthodes de contrôle de puissance proposées . 160

4.3. Contrôle de puissance et autres fonctions de la gestion des ressources radio 165

4.3.1. Accès et contrôle d'admission 165 4.3.2. Respiration de cellules 166 4.3.3. Contrôle de puissance et soft handover 168

4.4. Le contrôle de puissance dans les systèmes 3G 168 4.5. Contrôle de puissance en UTRA-FDD 170

4.5.1. Principes généraux 170 4.5.2. La voie montante (uplink) 173 4.5.3. La voie descendante (downlink) 176

4.6. Contrôle en UTRA-TDD 179 4.6.1. Rappels sur UTRA-TDD 179 4.6.2. La voie montante (uplink) 179 4.6.3. La voie descendante {downlink) 181 4.6.4. Fréquences de mise à jour du contrôle de puissance de la voie descendante de UTRA-TDD 181

4.7. Contrôle de puissance dans la proposition cdma2000 182 4.8. Imperfection du contrôle de puissance 183 4.9. Bibliographie 184

Chapitre 5. Couverture d'un réseau cellulaire CDMA 187 Loutfi NUAYMI

5.1. Présentation du problème 187 5.2. Modèle utilisé 190


5.3. Estimation simple de la capacité d'un réseau cellulaire CDMA 192 5.4. Définitions et relations utiles pour la liaison uplink 193

5.4.1. Définitions 193 5.4.2. Relations utiles 195

5.5. Définitions et relations utiles pour la liaison downlink 202 5.5.1. Définitions 203 5.5.2. Relations utiles 204

5.6. Algorithme de prévision de la couverture d'un réseau CDMA par calcul itératif des charges des cellules 207 5.7. Détails supplémentaires sur l'algorithme de calcul des charges 208

5.7.1. Imperfection du contrôle de puissance 208 5.7.2. Interférence de canaux adjacents 209 5.7.3. Sectorisation 209 5.7.4. Soft handover 209

5.8. Conclusion et discussion 210 5.9. Bibliographie * 210 5.10. Annexe : notations utilisées dans ce chapitre 212

Chapitre 6. Le réseau d'accès UTRAN 215 Xavier LAGRANGE

6.1. Architecture générale 215 6.1.1. Rappel sur le réseau d'accès de GSM 215 6.1.2. Eléments du réseau d'accès UTRAN 218

6.2. Rappels sur les architectures en couches des réseaux 224 6.2.1. Signalisation sémaphore 224 6.2.2. Architecture en couches d'un réseau ATM 228 6.2.3. Réseaux IP 234

6.3. Principes généraux de l'architecture en couches dans UTRAN 236 6.3.1. Strates d'accès et de non-accès 236 6.3.2. Notion de support de transport (transport bearer) 237 6.3.3. Notion de support d'accès radio (RAB, Radio Access Bearer) . . 238 6.3.4. Les différents plans 239

6.4. Pile de protocoles de l'UTRAN avec un réseau de transport ATM . . . 240 6.4.1. Interface Uu 240 6.4.2. Interfaces lu 242 6.4.3. Interface Iub 245 6.4.4. Interface Iur 246 6.4.5. Synthèses des piles de protocoles 247

6.5. Pile de protocoles de l'UTRAN avec un réseau de transport IP 250 6.6. Présentations des protocoles sur l'interface radio 252

6.6.1. Couche MAC 252


6.6.2. Couche RLC 253 6.6.3. Couche RRC 255

6.7. Exemples de procédures de signalisation 258 6.7.1. Etablissement d'une connexion RRC et son utilisation 259 6.7.2. Libération d'une connexion RRC 261 6.7.3. Etablissement d'une connexion RRC sur canaux FACH-RACH . 262 6.7.4. Etablissement d'un RAB 263 6.7.5. Libération d'un RAB 264 6.7.6. Gestion de la macrodiversité {soft handover) 264 6.7.7. Procédures de relocalisation 267


Chapitre 7. Le cœur de réseau UMTS 271 Jean -Mar i e BONNIN

7.1 Introduction 271 7.2. Cœur de réseau en GSM et GPRS 273

7.2.1. Architecture du réseau GSM avant le GPRS 273 7.2.2. Cœur de réseau GPRS : un premier pas vers l'UMTS 275

7.3. Architecture du cœur de réseau en Release 99 283 7.3.1. Services offerts par le cœur de réseau 284 7.3.2. Principaux concepts 285 7.3.3. Entités du domaine circuit 287 7.3.4. Entités du domaine paquet 288 7.3.5. Architecture en couches 292 7.3.6. Entités communes aux deux domaines 294 7.3.7. Intégration des domaines PS et CS 295

7.4. Gestion des appels et des sessions 296 7.4.1. Services IP proposés aux utilisateurs 296 7.4.2. Etats de fonctionnement d'un mobile 300 7.4.3. Attachement aux domaines PS et CS 302 7.4.4. Gestion des appels du domaine CS 305 7.4.5. Gestion des sessions du domaine PS 307

7.5. Gestion de l'itinérance 316 7.5.1. Gestion de la mobilité 317 7.5.2. Gestion de la mobilité inter réseau 321 7.5.3. Interaction avec MobileIPv4 322

7.6. Gestion de la qualité de service 326 7.6.1. Les classes de services définies 326 7.6.2. Une architecture complète 328 7.6.3. Exemple de mise en œuvre dans le cœur de réseau paquet 331

7.7. Evolution vers un cœur de réseau tout IP 332 7.7.1. Evolutions de la Release 4 333


7.7.2. Evolutions prévisibles de la Release 5 334 7.8 Conclusion 335 7.9. Bibliographie 337

Chapitre 8. Les architectures de services de l'UMTS 339 Phi l ippe MARTINS

8.1. Historique de l'évolution des services dans les réseaux radio-mobiles . 339 8.1.1. Des services supplémentaires à CAMEL 339 8.1.2. Evolutions vers VHE et OSA 341 8.1.3. Evolutions vers IP 341

8.2. Rappels sur les réseaux intelligents 341 8.2.1. Notion de segment d'appel 341 8.2.2. Evolution et structure des standards 342 8.2.3. Le modèle conceptuel du réseau intelligent 344 8.2.4. Le plan fonctionnel réparti * 345 8.2.5. Exemples de services réseau intelligent 355 8.2.6. CAMEL et les réseaux intelligents 358

8.3. Présentation de CAMEL 358 8.3.1. Différentes phases de CAMEL 358 8.3.2. Architecture fonctionnelle 361 8.3.3. Les marques CAMEL 362

8.4. CAMEL et le domaine circuit 364 8.4.1. Les automates CAMEL phase 3 du domaine circuit 364 8.4.2. Evolution des automates en phase 4 366

8.5. CAMEL et le domaine paquet 369 8.5.1. Automate d'attachement-détachement GPRS 370 8.5.2. Exemple d'activation de service 370 8.5.3. Automate de contexte 371 8.5.4. Exemple de service sur acfivation d'un contexte 373

8.6. CAMEL et les échanges de SMS 374 8.6.1. CAMEL phase 3 et les envois de SMS 374 8.6.2. CAMEL Phase 4 et la réception de SMS 376

8.7. CAMEL phase 4 et le sous-système IP multimédia 376 8.7.1. Introduction à SIP 376 8.7.2. SIP et le sous-système IP multimédia 379 8.7.3. CAMEL phase 4 et le sous-système IP multimédia 381

8.8. Présentation d'OSA 381 8.8.1. Introduction 381 8.8.2. Services apportés par OSA 382 8.8.3. Typologie des interface OSA 383


a


Chapitre 9. Terminal mobile et environnements d'applications 387 Paul JOLIVET

9.1. Introduction 387 9.2. L'équipement utilisateur en 3G 388

9.2.1. L'équipement mobile (ME) 389 9.2.2. La carte à puce (UICC) et ses applications 392 9.2.3. Le rapport de force terminal-carte 395

9.3. Environnements propriétaires - environnements standards 396 9.3.1. Différentes ressources pour différentes applications 397 9.3.2. Les différents environnements 397 9.3.3. Interfonctionnement des environnements 400 9.3.4. Les services d'Internet Mobile 404 9.3.5. L'approche standard des environnements existants 405 9.3.6. L'approche offre de services en packages 406

9.4. Virtual Home Environment * 407 9.5. Le téléchargement 408

9.5.1. Les applications du téléchargement 408 9.5.2. Synchronisation 409 9.5.3. Fonctionnalités liées au téléchargement d'applications 410 9.5.4. Environnements applicatifs et téléchargement 411 9.5.5. Supports de communication du réseau 3G 412

9.6. Conclusion 414 9.7. Annexes 415

9.7.1. La standardisation côté terminaux 415 9.7.2. Références 418

Chapitre 10. Sécurité du système UMTS 423 Paul JOLIVET

10.1.Introduction 423 10.1.1. Exemples d'attaques sur un réseau mobile 423 10.1.2. Mécanismes de sécurité 424

10.2 Principes de la sécurité en UMTS 425 10.2.1. Les éléments matériels liés à la sécurité 426 10.2.2. Identité sur le réseau UMTS 426 10.2.3. Identification de l'utilisateur 427 10.2.4. Lignes directrices des algorithmes d'authentification 428 10.2.5. Authentification en UMTS 430 10.2.6. Intégrité des messages 432 10.2.7. Chiffrement des données 433 10.2.8. Aspects protocolaires 436

10.3. Les attaques possibles - Les protections 438

1


10.3.1. Parades - Protection 438 10.4. UICC et AuC, clé de voûte du système 438

10.4.1. Sécurité et carte à puce 439 10.4.2. UICC et USIM 440 10.4.3. Utilisation « de base » 440 10.4.4. Sécurité et IP Multimedia 441 10.4.5. Sécurité et service de diffusion multimédia (MBMS) 442 10.4.6. Sécurité et appels de groupe (VGCS) 443 10.4.7. Sécurité et I-WLAN 444 10.4.8. Sécurité et terminal réparti entre plusieurs périphériques 445

10.5. Applications et sécurité 445 10.5.1. Interfonctionnement des applications et pare-feu 445 10.5.2. Téléchargement d'applications 446

10.6. Roaming et sécurité 447 10.6.1. Accès aux données de sécurité 447 10.6.2. Accès à de multiples réseaux 447 10.6.3. Algorithmes de conversion, fonctionnalité 2G 447 10.6.4. Roaming 2G/3G, authentification et chiffrement 448

10.7. Interception légale 448 10.7.1. Les résolutions de la Communauté Européenne 448 10.7.2. La mise en place dans les pays, le cas du Royaume-Uni 449 10.7.3. Interception et standardisation 450

10.8. Protection du réseau UMTS 451 10.8.1. Le réseau nominal 451 10.8.2. Les éléments du réseau - interfaces 451

10.9. Conclusion 454 10.10 Annexé ^Bibliographie et Références 454

10.10.1. Bibliographie 454 10.10.2. Spécifications - Standards 455 10.10.3. Sites Internet 457

Glossaire 459

Index 471

Chapitre 1

Introduction à l'étalement de spectre

1.1. Introduction

L'UMTS (Universal Mobile Télécommunications Systems) doit permettre une pa-noplie de services nettement plus large que les systèmes de deuxième génération comme GSM (Global System for Mobile communications) qui se cantonnait à la té-léphonie et aux messages courts (SMS, Short Message Service). A terme, l'ensemble du réseau UMTS (accès, réseau cœur) doit évoluer dans le sens de la convergence téléphonie-données vers un réseau tout IP. Dans une première phase (correspondant à la release 99), la différence majeure avec le GSM vient de l'interface radio. Celle-ci repose sur l'étalement de spectre à séquence directe.

L'étalement de spectre consiste à transmettre une information sur un signal occu-pant un spectre nettement plus grand que le minimum nécessaire. Cette technique a été d'abord utilisée dans les systèmes militaires à des fins de discrétion et parce qu'elle offre une bonne résistance aux brouillages hostiles. Depuis le milieu des années 90, elle est utilisée dans certains systèmes radiomobiles cellulaires. Ce chapitre a pour ob-jet d'en donner les principes généraux. Il commence par un rappel de communication numérique sur les notions de voie en phase et de voie en quadrature et une présentation de la notion très importante d'énergie d'un bit. Il aborde ensuite le principe d'étale-ment à séquence directe et décrit le principe général de fonctionnement d'un récepteur. 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 à séquence directe et du CDMA dans les systèmes cellulaires.

Chapitre rédigé par Xavier L A G R A N G E .

20 Principes et évolutions de l'UMTS

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

Figure 1.1. Exemple d'un signal modulé en QPSK

1.2. Rappels de communication numérique

1.2.1. Principes des modulations numériques

1.2.1.1. Transmission d 'une suite de symboles

Pour transmettre une information d'un point à un autre, on utilise un signal sinu-soïdal à haute fréquence (dans le contexte radiomobile de 2 MHz à 2 GHz) dont on modifie l'amplitude, la phase ou la fréquence [BAU 02]. Nous nous restreignons aux modulations de phase, utilisées dans les systèmes radiomobiles de troisième généra-tion.

Pour une transmission numérique, on émet l'information par groupes d'éléments binaires appelés symboles. Pendant la durée d'un symbole Ts, la grandeur modifiée (dans ce chapitre, la phase) reste constante. On peut donc considérer la transmission d'un symbole unique. Cela permet de raisonner sur des signaux à énergie finie. La transmission de la suite d'éléments binaires est analysée en considérant une répétition de l'émission d'un symbole avec un décalage d'un nombre entier de période Ts. Soit S (t) un signal modulé transportant une suite de symboles, le signal S (t) s'écrit sous la forme :

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.

[1 1]

Introduction à l'étalement de spectre 21

Figure 1.2. Transmission d'un symbole

1.2.1.2. Ecriture sous forme réelle d'un signal modulé

Considérons une modulation où M états de phases sont utilisés et où M est une puissance de 2. On groupe log2 (M) bits en 1 symbole pour obtenir un symbole m parmi les M symboles possibles (m = O...Af — 1). Nous obtenons la première forme d'écriture du signal sm{t) : *

«m(t) = 9 (t) cos (27rjct + 2irra/M + <p) [1.21

où <p est la phase à l'origine des temps.

La fonction g désigne une fonction d'énergie finie Eg. La fonction g s'annule donc nécessairement en —oo et +oo. Un exemple simple de fonction g est la fonction « créneau » :

r g(t) = jËJTs Si \t\ < Ts/2 \ g(t) = 0 si \t\ > Tl/2 1

L'énergie d'un signal g{t) est définie par E = f*^ g2 (t) dt. On en déduit pour

la fonction g(t) considérée : E = J^Xs/2 Eg/Tsdt soit E = Eg.

Nous considérons dans ce chapitre que la fonction g(t) est la fonction créneau. Cette fonction a pour principal inconvénient d'avoir un spectre étalé sur tout l'es-pace des fréquences. Or, dans un système de transmission, on utilise une bande de fréquence limitée, c'est-à-dire qu'on filtre le signal émis. Il est donc préférable d'uti-liser une fonction g(t) dont le spectre est limité. Pour ce faire, on filtre le signal avant l'émission. Cette étape est appelée « mise en forme » ou puise shaping.

EXEMPLE - Considérons une modulation à 2 états (M = 2). Les valeurs possibles de m sont 0 et 1. On a sm(t) = sjEg/Ts cos (2TT/C£ + rrnr) pour t G }~Ts/2, Ts/2[ en


prenant <p = 0 et la fonction créneau pour g. Il s'agit de la modulation BPSK (Binary Phase Shift Keying).

EXEMPLE - Considérons une modulation à 4 états (M = 4). Les valeurs possibles de m vont de 0 à 3. On a sm(t) = y/Eg/Ts cos (27rfct 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 sm(£) sous une autre forme :

8m(t) = » (s (;t) ej(^fct+2nm/M+^ [M]

où j désigne le nombre imaginaire tel que j2 = — 1 et désigne la partie réelle d'un nombre complexe. En modifiant légèrement la présentation, nous obtenons la deuxième forme d'écriture du signal sm(t) :

Sm{t) = » (ej2™/M+i*g (t) ej27rfct) [1.5]

Cette écriture en notation complexe fait apparaître que la transposition à la fré-quence fc peut être vue comme une simple multiplication par le signal f qui ne dépend pas de l'information transmise.

1.2.1.4. Ecriture en phase et en quadrature d'un signal modulé

En repassant en notation réelle, on obtient la troisième forme d'écriture du signal :

sm(t) = cos (2irm/M + ip) g (t) cos (27rf c t )

- sin {2-Km/M + <p) g ( t ) sin (2?r f c t ) [ 1.6]

Sous cette forme, le signal s (t) s'exprime comme une combinaison linéraire de deux sinusoïdes en quadrature de phase. On appelle le premier terme la voie en phase et le deuxième la voie en quadature.

EXEMPLE - En BPSK, on peut écrire sm(t) = ±y/Eg/Ts cos (27rf c t ) (on a + ou -suivant la valeur du bit m). On note que la voie en quadrature est toujours nulle.

EXEMPLE.- En QPSK, on peut écrire le signal sous la forme :

sm(t) = cos (mn/2 + TT/4) yJË~/Ts cos (2?r f c t )

- sin (ra7r/2 + tt/4) YJEG/TS sin (2?vf c t )


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

Définissons 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 diffèrent que par la phase. Ils ont donc même énergie. Calculons l'énergie pour f\ :

»+oo E= I f f ( t ) d t " [1.9]

/

-t-oo

/? « -oo

On a donc :

2 p-t-OO E=— g2{t)œs2(27rfct)dt [1.10]

J—oo

En utilisant les formules trigonométriques :

+ f ° ° 92(t)œs(47Tfct)d?j [1.11]

La fonction g (t) a, par définition, une énergie Eg, donc f*™ g2 (t) = Eg. En pratique, la fonction g2 ( t ) est une fonction paire, donc g2 ( t ) cos (47T fct) dt = 0. On en déduit E — 1. D'autre part, on a :

/

-t-oo 2 p~r°°

fi (t) h (t)dt = -— g2(t) cos (2 ;Tf c t ) sin (2Trfc t) dt [1.12] -oo ^ g J—oo

On peut en déduire, après quelques calculs élémentaires :

/

+oo

h(t)f2(t)dt = o -oo

[1.13]


Les deux signaux / ie t sont donc orthogonaux et d'énergie 1. L'énergie du signal sm (t) se calcule comme pour /i (t). On obtient :

[1.14]

Posons Es = Eg/2. Le paramètre Es représente l'énergie du signal sm (t) utilisé pour transmettre un symbole. Par extension, on considère qu'il représente l'énergie d'un symbole.

Nous obtenons la quatrième forme d'écriture du signal sm(t) comme une combi-naison linéaire de deux signaux sinusoïdaux orthogonaux d'énergie 1 affectés 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 deuxième signal en quadrature. Il est possible de considérer deux voies de transmission : la voie en phase appelée voie I, qui transporte a m , et la voie en quadrature appelée voie Q, qui transporte bm.

Il est commode d'écrire la paire ( a m , 6 m ) sous la forme d'un seul nombre com-plexe am -(- jbm. En passant en écriture complexe, on obtient la cinquième et dernière forme d'écriture du signal sm (t) :

[1.18]

avec / (t) = h W " 3h W = y f f g d ( t ) exp (j2tt/c^). La fonction / (t) a tou-jours une énergie égale à 1, quelle que soit la fonction g (t) choisie. On peut donc considérer que l'énergie du signal est seulement « transportée » par am et bm.


EXEMPLE - Dans le cas de la B P S K , on utilise seulement la voie I . Un symbole cor-respond à un bit. Les valeurs possibles de am sont donc { — y/Êb, +y/Ëb} , où Eb désigne l'énergie d'un bit (égale ici à l'énergie d'un symbole).

EXEMPLE - Dans le cas de la Q P S K , on utilise à la fois la voie en phase et en qua-drature. On a am = y/Ës cos (m7r/2 + 7T/4) et bm = y/Es {mn/2 4- 7T/4) . Les valeurs possibles de am et de bm sont donc j — y/Es/2, +y/Es/2^. Deux bits sont groupés en 1 symbole. L'énergie d'un bit est la moitié de celle d'un symbole : Eb = Es/2. On peut donc réécrire les valeurs possibles de am et bm comme { - +>/£&}. Les modulations Q P S K et B P S K sont donc très 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 chaîne d'émission d'un signal modulé numériquement peut être vue comme suit (voir partie de droite de la figure 2.18) : un flux d'éléments 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) différente de la fonction créneau). La dernière étape consiste à transposer le signal en fréquence par simple multiplication par la fonction complexe exp(j27r/c£).

1.2.1.6. Conclusion

Un signal numérique peut être considéré comme une suite de symboles complexes, chaque symbole possédant une certaine énergie. L'axe des réels correspond à la voie en phase et l'axe des imaginaires à la voie en quadrature. En modulation BPSK, on transmet des éléments 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 éléments binaires. Un symbole complexe transporte donc 2 bits.


1.2.2. Modèle de transmission en bande de base

Dans le modèle de transmission considéré, la dernière étape à l'émission consiste à opérer la transposition de fréquence. De façon réciproque en réception, on fait une transposition en fréquence pour repasser en bande de base par une multiplication par exp(— j2irfct). Dans le reste du chapitre, nous raisonnons sur un modèle en bande de base sans prendre en compte la transposition en fréquence, comme indiqué à la figure 1.4. Pour une justification précise mais longue qu'un tel modèle ne modifie pas les résultats présentés, on peut consulter [PRO 01].

transposit ion transposit ion en fréquence en fréquence

Figure 1.4. Modèle de transmission en BPSK et modèle équivalent en bande de base

On suppose également dans ce chapitre que la fonction g{t) est une fonction cré-neau simple et que la modulation utilisée 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 considérant deux transmissions en parallèle sur les 2 voies en quadrature et en phase. Pour la BPSK. la durée d'un symbole est la même que la durée d'un bit :TB = TS. Pour un flux binaire émis à débit 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 créneau 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


référençant le ke bit à émettre (et non un indice donnant la valeur utilisée 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 présentons le modèle 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 après 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 réduire considérablement la puissance du signal reçu. Dans tous les récepteurs, un amplificateur permet de disposer d'un signal de puissance voisine de celle du signal émis. Pour simplifier les écritures et sans perte de généralités, on considère que le ou les amplificateurs rétablissent le même niveau d'énergie que celui du signal émis : en d'autres termes, on ne tient pas compte de l'affaiblissement.

Dans une première étape, on néglige les distorsions et on considère que le brouillage revient à ajouter au signal transmis un signal aléatoire dont le niveau est distribué sui-vant une gaussienne. Ce signal est appelé bruit additif blanc gaussien (AWGN, Ad-ditive White Gaussian Noise). Il a une énergie infinie mais une puissance finie. Sa densité spectrale de bruit est constante de valeur Nq/2, quelle que soit la fréquence considérée. Sur une bande W ramenée en bande de base, la densité spectrale est NO.

Dans un système radiomobile, le bruit gaussien correspond non seulement au bruit propre du récepteur (bruit thermique) mais également à l'ensemble des interférences, notamment l'interférence co-canal due à la réutilisation de la même fréquence sur plusieurs cellules.

Le signal reçu s'écrit donc :

R(t) = S(t) + n(t) [1.20]

Un tel modèle de canal est appelé canal AWGN. Notons qu'à l'émission il y a un ensemble discret de signaux possibles. A la réception, le bruit a pour effet de faire passer les valeurs dans un espace continu.

1.2.3.2. Canal à multitrajets

Dans les réseaux radiomobiles, le récepteur est rarement en visibilité directe de l'émetteur. Les obstacles dans un milieu urbain ou rural (immeubles, végétation, mo-biliers urbains, véhicules, personnes, etc.) provoquent des réflexions, des diffractions


et de la diffusion (voir [PAR 00] et [LAG 00]). Un récepteur reçoit un signal com-posite comprenant divers échos d'un même signal émis. Chaque signal suit un trajet particulier et il arrive donc avec un décalage par rapport aux autres. La propagation est dite à multitrajets.

On caractérise un canal de propagation par sa réponse implusionnelle, c'est-à-dire l'évolution du signal reçu si on émet une impulsion. La réponse impulsionnelle dépend étroitement de l'environnement particulier dans lequel on se place mais on peut identifier des caractéristiques communes suivant le type d'environnement (urbain, rural, montagneux). On définit ainsi des canaux standards avec des valeurs de retard fixes mais un affaiblissement et une phase aléatoires.

Un canal multitrajet est équivalent à un filtre : la réponse impulsionnelle du canal est la réponse impulsionnelle du filtre. La fonction de transfert du filtre est la trans-formée de Fourier de la réponse implusionnelle. On définit la barçde de cohérence du canal comme la plage de fréquences à l'intérieur de laquelle le canal présente un gain quasi-constant et une phase linéaire. A l'intérieur de la bande de cohérence, le canal peut être considéré comme plat.

La fonction de transfert d'un canal à multitrajets peut s'écrire de façon très géné-rale :

où T désigne le retard évoluant au cours du temps t et où S est la fonction de Dirac. Les paramètres T{(t) représentent les retards des différents trajets; les coefficients complexes a(t) donnent la phase et l'amplitude de chaque trajet.

Un modèle couramment utilisé consiste à supposer que la variation au cours du temps des différents paramètres est lente par rapport au débit de transmission. On considère donc que ces paramètres sont constants au cours d'une transmission d'un bloc d'information mais peuvent varier d'une transmission à l'autre. Plus précisément, on suppose que les r* sont fixes et ne dépendent que de l'environnement (urbain dense, rural, montagneux, etc.) et que les coefficients Ci sont aléatoires : la phase est uni-formément distribuée et l'amplitude suit une loi de Rayleigh [JAK 94]. Les modèles précisent la valeur moyenne de l'amplitude. Un des modèles proposés dans [SMG 98] est présenté à la figure 1.5. On peut écrire, pour une transmission :

[1.21]

[1.22]

Introduction à l 'étalement de spectre 29

où Ai est une variable aléatoire de Rayleigh dont la moyenne est donnée par le modèle et fa est une variable aléatoire uniformément distribuée entre 0 et 2tt.

Puissance moyenne

1.3. Etalement à séquence directe

1.3.1. Bits et chips

Considérons une suite de données transmise en bande de base à un débit Rb (R pour Rate). L'étalement de spectre consiste à multiplier la suite de données par une séquence prédéfinie PN(t) valant +1 ou —1 et variant à un rythme Rc = nRb. Nous constatons que l'étalement revient à augmenter artificiellement le débit d'un facteur n. Le paramètre n est appelé facteur d'étalement. Pour simplifier, nous utiliserons dans ce chapitre un exemple avec n = 8 ; dans la pratique, le paramètre n est généralement une puissance de 2 largement supérieure à 10, typiquement 64, 128, 256 ou 512. Après multiplication, le Signal varie donc à un rythme bien supérieur au débit symbole. La partie élémentaire de la séquence s'appelle un chip.

Soit S(t) la suite de données à émettre. Le signal en bande de base après é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'opération 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 considère une énergie égale à 1.

Le chapitre considère une séquence PN(t) à valeurs réelles mais il est possible de considérer une séquence PN(t) complexe. Avec une modulation QPSK, la séquence PN(t) prend ses valeurs parmi {1, j, — 1, — j}.


Figure 1.6. Principe de base de l'étalement à séquence directe

1.3.2. Bilan énergétique

La suite de données étant émise à un débit Rb, la durée d'un bit est Tb = l/Rb- Le débit en chips par seconde du signal étalé est Rc = nRb. La durée d'un chip est donc Tc = Tb/n.

Soit Ec l'énergie d'un chip. Comme la séquence PN(t) vaut +1 ou —1, la mul-tiplication par PN(t) ne change pas la puissance du signal. La puissance du signal d'origine est égale à la puissance du signal étalé. On peut donc écrire :

Eb/Tb = Ec/Tc [1.24]

On en déduit aisément :

Eb = nEc [1.25]

L'équation 1.25 montre que l'énergie d'un bit est répartie sur l'ensemble des chips.

1.3.2.1. Spectre du signal étalé

Considérons la suite des données transmises par l'émetteur. Pour un observateur extérieur, cette suite apparaît comme aléatoire. La densité spectrale de puissance de S(t) est donc celle d'un signal aléatoire NRZ. Elle est donnée par (voir [GLA 96]) :

f sin(7r/Tb)Y [1.26]


Densité spectrale de puissance

-8 -7 -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8

fréquence (en multiples de MTb)

Figure 1.7. Comparaison des spectres du signal en bande de base et du signal étalé

Si on choisit une séquence d'étalement qui ressemble à un séquence aléatoire, le signal après étalement apparaît comme un signal aléatoire mais à un rythme Rc. La densité spectrale (j>c{f) du signal après étalement est :

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

M n = - ( s i n 0 i r / n ) y 2 H.28] n \ 7TfTb/n J

Les deux densités spectrales sont représentées dans la figure 1.7. L'étalement a pour effet de multiplier la largeur du spectre d'un facteur n. Le paramètre n mérite donc bien son nom de facteur d'étalement. La figure 1.7 donne le spectre pour une fonction g{t) créneau. Dans la pratique, on utilise une fonction qui donne un spectre plus reserré : la majorité de l'énergie est concentrée dans la bande W = l/Tc (c'est-à-dire entre - 1 / 2 T c et 4-1/2Tc). Cependant, le rapport entre le spectre du signal avant étalement et après étalement reste toujours n.

Notons que pour bénéficier d'un réel étalement du spectre, la séquence utilisée doit être pseudoaléatoire, d'où la notation PN (Pseudo Noise). Par exemple, on ne peut


faire un étalement avec une séquence périodique telle q u e + 1 + 1 + 1 + 1 —1—1 —1 — 1. Toute séquence pseudoaléatoire est nécessairement périodique mais sa période est longue (voir paragraphe 1.5.1.1). Dans le système américain IS-95, on utilise par exemple une séquence de longueur 215 soit 32 768 et un étalement de 64. La lon-gueur de la séquence est bien plus longue que le paramètre n.

Notons qu'il existe d'autres techniques d'étalement de spectre que celle décrite dans ce paragraphe, la principale étant le saut de fréquence. Si on fait varier la fré-quence porteuse sur laquelle on transmet le signal, on a également un étalement de spectre. Si la variation est plus lente que le débit symbole, on parle de saut de fré-quence lent ou Slow Frequency Hopping. Si la variation est plus rapide ou du même ordre, on parle de Fast Frequency Hopping.

1.3.3. Gain d'étalement

Nous considérons une transmission d'un signal QPSK ou BSPK sur un canal AWGN (voir paragraphe 1.2.3.1), c'est-à-dire ajoutant un bruit gaussien au signal transmis. La probabilité d'erreur sur un bit (lorsqu'on utilise un filtre adapté), est don-née par la formule suivante, que nous admettons [PRO 01 ] :

où EB désigne l'énergie d'un bit, Nq la densité spectrale de puissance du bruit et 'OO 1 t

Q (t) = f t°° -j=e !2dx. Par exemple, un rapport Eb/N0 de 6 dB conduit à un taux

d'erreur bit de 10 -3

Soit C la puissance du signal émis. Dans une transmission sans étalement, la lar-gueur de bande du signal est W = L/TB (en considérant la bande de Nyquist). La puissance du signal est donc C = EB/TB. Si, à la réception, 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 10 - 3 .


Nous admettons également que la formule 1.29 est inchangée par l'étalement de spectre. La puissance du signal reste la même mais la largeur de bande est augmentée Wc = 1/TC. On a donc C/N = (Eb/Tb)/(N0WC). On peut donc établir :

C/N = -Eb/N0 [1.31] n

En échelle logarithmique, on obtient :

(C/N)dB = (Eb/N0)iB - 101ogi0 n [1.32]

Considérons un système avec un facteur d'étalement n = 128. Pour avoir un taux d'erreur bit de 10 - 3 , il est toujours nécessaire d'avoir un Eb/N0 de 6 dB mais celui-ci est obtenu par avec un signal sur bruit de 6 — 101og10(128) = —13 dB. Or -13 dB correspond à un rapport 200 en puissance. Cela signifie qu'on tolère une puissance de bruit égale à 200 fois la puissance du signal ! Grâce à l'étalement, on peut avoir un faible taux d'erreur, même lorsque le signal étalé reçu est complètement « noyé » dans le bruit. En conséquence, on appelle le paramètre n le gain d'étalement.

On peut exprimer la formule 1.31 sous une autre forme en fonction de la bande W (égale à 1/TC) et du débit utilisateur Rb (égal à l/Tb). On obtient :

W C E k / N 0 = - - [..33]

1.3.4. Récepteur en bande de base

1.3.4.1. Récepteur simple sur un canal parfait

Considérons une transmission sans aucun bruit, ni aucune interférence. Le canal a pour seul effet de retarder le signal d'une durée TQ. Soit Srecu le signal reçu. On a Srecu(t) = Setale {t ~ TQ), SOit :

Srecu M = S(t - r0).PN{t - T0) [1 .34]

On vérifie aisément que pour tout t, PN(t).PN*(t) = 1, où PN(t) désigne le conjugé du complexe PN*(t) (si l'étalement est réel, PN*(t) = PN(t)). Pour re-trouver le signal d'origine, il faut donc multiplier le signal reçu par PN*(t - TQ). En effet:

Srecu(t).PN*(t - TQ) = S(t - R0).PN{t - R0).PN*{t - r 0) [1.35]


On a donc :

[1.36]

On note qu'il est nécessaire pour la réception d'estimer la valeur de tq. Cela si-gnifie qu'il y a une synchronisation à faire en réception. 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 système si simple car il n'y a pas de critère de décision pour déterminer le bit émis à l'origine. Pour permettre une détection simple, on va utiliser un intégrateur.

1.3.4.2. Récepteur simple sur un canal avec bruit additif

On considère maintenant un canal qui introduit un bruit gaussien (canal AWGN présenté au paragraphe 1.2.3.1). Le signal reçu s'écrit donc par rapport au signal émis :

[ 1 . 3 7 ]

où n(t) est représente le bruit aléatoire gaussien.

On rajoute au récepteur simple présenté au paragraphe 1.3.4.1, un intégrateur qui agit sur une durée bit T^. Cela a pour effet de réaliser une corrélation entre le signal reçu et la séquence PN(t) décalé de r0 :

[1.38]

Figure 1.8. Principe d'un récepteur avec un corrélateur

Le schéma bloc d'un récepteur simple est présenté dans la figure 1.8. A la sortie du corrélateur , on échantillonne le signal toutes les durées bits La détection consiste à regarder le signe du signal reçu. On peut également mettre une détection à seuil : pour considérer qu'on a un bit 0 ou un bit 1, il faut que le niveau soit en valeur absolue supérieur à un seuil donné. Dans le cas contraire, on est dans le cas d'un effacement (on sait qu'un bit est reçu mais sa valeur est considérée comme inconnue).


Figure 1.9. Exemple de réception d'une séquence bruitée

Pour illustrer le principe de fonctionnement du récepteur, on considère une trans-mission de quelques bits (0, 0 ,1 ,0) dans le modèle en bande de base comme indiqué à la figure 1.9 et on suppose que le bruit est constant pendant une durée chip. Il peut conduire à modifier le signe du chip reçu et introduire une erreur. Considérons le 3e bit émis. Si on faisait une réception indépendante de chaque chip, on aurait une erreur sur les trois premiers chips et sur le septième à la réception car le bruit est suffisamment important pour changer le signe du signal. Grâce à l'intégration sur l'ensemble des chips constituant le bit, la réception du bit est correcte. Nous voyons de manière plus intuitive l'intérêt de l'étalement de spectre, présenté au paragraphe 1.3.3. Cet effet peut s'exprimer mathématiquement en combinant les équations 1.23, 1.37 et 1.38 :

On en déduit :


soit :

[1.41]

A la sortie du corrélateur, le bit est affecté d'un certain bruit représenté par le terme de droite de l'équation 1.41. Le bruit et la séquence PN(t) sont décorrélés. Par conséquent, le terme de droite est proche de 0. Avec une analyse plus poussée basée sur l'énergie, on peut ainsi justifier que l'équation 1.29 reste valide pour un signal étalé. Le corrélateur a pour effet de « désétaler » le signal alors qu'il ne « désétalé » pas le bruit comme on le voit à la figure 1.10. Notons que le fonctionnement du récepteur suppose qu'on est capable d'estimer la valeur du délai de propagation r0 .

Densité spectrale de puissance

Figure 1.10. Action du désétalement sur les spectres du signal et du bruit

1.3.5. Principes du récepteur Rake

Dans un canal à multitrajets, un récepteur avec un simple filtre adapté ne peut suffire. On reçoit plusieurs échos décalés dans le temps du même signal : par rapport au trajet principal, les échos vont engendrer de l'interférence, ce qui va augmenter


le risque d'erreur. On utilise dans ce cas un récepteur à rateau ou récepteur Rake. Le fonctionnement d'un tel récepteur suppose qu'on est capable d'estimer la réponse impulsionnelle du canal, c'est-à-dire de connaître les paramètres fa et Ai de l'équation 1.22.

Un récepteur rake est composé d'une batterie de corrélateurs, chaque corrélateur étant accordé sur un trajet comme illustré à la figure 1.11. La corrélation est faite entre le signal reçu et la séquence d'étalement affectée d'un retard particulier. Pour une bonne réception, le retard utilisé doit correspondre au retard provoqué par un des trajets du canal. Chaque corrélateur correspond à une branche du rateau. Dans l'idéal, 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 particulière fa et d'un affaiblissement Ai. On recombine les sorties des différents corrélateurs après intégration 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 perçoit bien qu'il faut pondérer par un coefficient d'autant plus fort une branche que le trajet correspondant est reçu fortement (c'est-à-dire que Ai est fort).

Figure 1.11. Principe du récepteur Rake

1.3.6. Intérêt 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 réponse impulsionnelle du canal est la réponse impulsionnelle du filtre. La fonction de transfert du filtre est la transformée de Fourier de la réponse implusion-nelle. On définit la bande de cohérence du canal comme la plage de fréquences à l'intérieur de laquelle le canal présente un gain quasi constant et une phase linéaire. A l'intérieur de la bande de cohérence, le canal peut être considéré comme plat.

Considérons un signal de durée symbole Ts et un canal de bande de cohérence Bc. La bande de fréquence occupée par le signal peut être assimilée à W = 1 /Ts. Nous considérons l'exemple suivant : une transmission à 10 kbit/s, soit Ts — 0,1 ms et


W — 10kHz, et une bande de cohérence égale à 100 kHz. Si on transmet directement le signal, alors la bande de cohérence est supérieure à la bande du signal : le canal peut être considéré comme plat. Si les phases des différents trajets composant le canal se combinent bien, l'amplitude du signal reçu est importante. Sinon, l'amplitude peut être faible : c'est le phénomène bien connu d'évanouissement. L'évanouissement peut atteindre 40 dB. La réception est donc très sensible aux multitrajets.

Figure 1.12. Intérêt de l'étalement de spectre pour un canal à multirajets

Considérons le même exemple mais avec un système à étalement d'un facteur 128. La bande du signal après étalement est donc égale à 1,28 MHz et elle est supérieure à la bande de cohérence. Il n'y a donc pas de phénomène d'évanouissement mais seulement un filtrage du signal (voir figure 1.12). Avec un traitement approprié, il est plus facile de récupérer le signal. L'étalement de spectre réduit fortement la probabilité des évanouissements mais ne les empêche pas complètement : il est reste possible que, sur une large plage de fréquences, le canal affaiblisse fortement le signal.

On étudie maintenant les phénomènes au niveau temporel en supposant qu'il n'y a que 2 trajets sur le canal. Pour fixer les idées, on prend ro = 0 et t\ = 2^s. Sans étalement, la durée d'un symbole dans l'exemple considéré est de 0,1 ms : elle est grande devant les retards et il n'y a donc pas d'interférence intersymbole. Avec étale-ment, la durée d'un chip vaut Tc = 100/128, soit 0,78 jus. Si un bit est émis à t = 0, le premier chip est reçu à t = 0 suivant le trajet principal et à t = 2/xs par le second trajet. Or à t = 2ps, le récepteur est en train de recevoir le troisième chip. Avec un récepteur Rake à 2 branches, on peut isoler les deux trajets : une branche est accordée sur le trajet principal, l'autre sur le trajet retardé de t\. Notons qu'il n'est pas possible d'isoler deux trajets qui diffèrent de moins d'une durée chip Tc (c'est-à-dire que l'on ne peut rien faire si t\ < Tc). En conclusion, l'étalement provoque de l'interférence


intersymbole (ici un symbole est un chip) mais il est facile, grâce au récepteur Rake, de s'en affranchir.

1.4. Principe du multiplexage par des codes orthogonaux

Le multiplexage a pour principe de transmettre plusieurs signaux en parallèle sans que l'un n'interfère avec l'autre. Les techniques de multiplexage les plus anciennes sont le FDMA (Frequency Division Multiple Access) et le TDMA (Time Division Mul-tiple Access). Dans ce paragraphe, nous présentons le CDMA (Code Division Multiple Access). Nous avons pris le parti de différencier le CDMA de l'étalement de spectre bien que les systèmes cellulaires désignés sous le vocable CDMA utilisent ces deux techniques. Dans cette présentation, nous ne faisons pas de considération sur l'énergie et considérons le flux de données comme une suite de bits transmis à un débit Nous reprenons la convention du paragraphe 1.3 : valeur +1 pour un bit à 0 et -1 pour un bit à 1.

Comme dans l'étalement de spectre, on multiplie, en CDMA, la valeur à trans-mettre par une séquence de chips à un débit supérieur Rc = nRb. Cependant, la sé-quence a des caractéristiques différentes. La longueur de la séquence est toujours égale au facteur d'étalement n. Le multiplexage des différents flux s'effectue en choissant des séquences ayant de bonnes propriétés d'orthogonalité. Ce sont les séquences de Walsh engendrées à partir des matrices d'Hadamard [GLI 03].

1.4.1. Matrices d'Hadamard et codes de Walsh

1.4.1.1. Construction et propriétés des matrices d'Hadtnard

Les matrices d'Hadamard Hn sont construites récursivement à partir d'une matrice de dimension un H\ = (+1) et de la relation de récurrence :

Les dimensions des matrices d'Hadamard sont des puissances de 2. On vérifie de façon très simple deux propriétés :

[1.42]

[1-43]

[1.44]


où In est la matrice identité de dimension n et l'exposant T désigne la transposée d'une matrice. La première propriété signifie que la matrice est symétrique et que la nième ligne et la nième colonne sont identiques. La deuxième propriété 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 symétrie de la matrice, on a la même propriété pour deux lignes / et V.

Une ligne de la matrice d'Hadamard est appelée un code de Walsh. D'après les remarques précédentes, les n codes de Walsh sont orthogonaux entre eux. On peut faire les remarques supplémentaires suivantes :

- chaque ligne contient autant de + que de —, sauf la première ligne qui ne contient que des + ;

- l'orthogonalité entre deux codes différents n'est généralement pas conservée si on décale un code par rapport à l'autre, elle est cependant conservé entre la première ligne et les autres lignes quel que soit le décalage ;

- l'orthogonalité est conservée si on affecte des poids différents à chaque code ; - si on multiplie chaque ligne de la matrice par la même séquence quelconque, les

propriétés d'orthogonalité des lignes entre elles sont conservées.

1.4.1.2. Exemples de codes de Walsh de longueur 8

On calcule facilement H2 :

[1.451

Après deux récurrences, on obtient :

On constate bien sur cet exemple que la première ligne n'est composée que de +1 et les autres lignes d'autant de -1 que de +1. Considérons l'avant-dernière ligne w6

de la matrice Hg, la dernière ligne w-j et la dernière ligne décalée circulairement d'un


chip vers la droite wtj. On calcule aisément 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 vérifier aisément que tous les produits scalaires de deux codes différents sont également nuls. On vérifie de façon similaire que < gwQ,g'wi >= 0 pour toute valeur de g et g' : la propriété d'orthogonalité reste vraie quels que soient les poids affectés à chaque code. Cela signifie qu'on peut affecter des puissances différentes aux codes sans perdre l'orthogonalité. En revanche, on calcule < we,wfj >= +4. Ces deux codes ne sont pas orthogonaux. Cela signifie qu'on ne peut tolérer aucune désynchronisation entre les codes si on veut garder l'orthogonalité.

»

1.4.2. Multiplexage par les codes

1.4.2.1. Principe du multiplexage

En considérant une matrice d'Hadamard de dimension 71, on dispose de n codes orthogonaux entre eux. Il est possible de transmettre n flux simultanément. Soit un utilisateur i qui produit un flux binaire bi (kTb) où k est un indice croissant avec le temps. L'utilisateur i se voit affecter un code Wi où Wi est une ligne de la matrice d'Ha-damard. Après étalement, le signal est bi (kTb) Wi. Le multiplexage des n utilisateurs consiste à transmettre globalement :

n - l S{kTb) = J2bj(kTb)™j [1-481

j=0

Cela signifie qu'on transmet {kTb) Wj,0 pendant le premier temps-chip puis bj (kTb) Wjt 1 pendant le deuxième et ainsi de suite, en désignant par Wjj la l-ème partie du code de walsh j.

1.4.2.2. Principe du démultiplexage

A la réception, pour extraire la donnée transmise par l'utilisateur i, il suffit de faire le produit scalaire du signal reçu et de la séquence Wi (voir figure 1.13). En effet on a :

n < S (kTb), Wi >= ̂ bj (kTb) < Wj,Wi >

3=1 [1.49]


Les différents codes sont orthogonaux entre eux (< Wj,Wi >= 0 pour i ^ j) et on a < Wi, Wi >= n, on en déduit :

< S (kTb), Wi >= nbi (kTb) 11.50]

On peut donc facilement récupérer le bit bi (kTb).

Figure 1.13. Multiplexage et démultiplexage en CDMA

Dans un système radiomobile, les multitrajets dont les retards sont supérieurs à une durée chip, vont créer des échos. Comme l'orthogonalité des séquences n'est pas conservée par un décalage, cela va entraîner de l'interférence. En revanche, on peut remplacer la somme de l'équation 1.48 par une somme pondérée (avec des facteurs différents pour les différents utilisateurs) sans aucunement perturber la réception.

flux mult iplexé

Figure 1.14. Exemple de multiplexage de deux flux en CDMA

1.4.2.3. Exemple de multiplexage en CDMA

On considère des séquences de Walsh de longueur 8 et deux flux auxquels sont affectés 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 démultiplexage pour le flux 6 redonne bien un bit +1. Le produit scalaire du flux multiplexé par wj donne + 0 - 2 - 0 — 2 — 0- 2 + 0- 2 = - 8 , ce qui redonne bien un bit -1.


1.4.3. Codes OVSF

Il est possible d'obtenir les mêmes séquences que celles de Walsh mais dans un ordre différent. Soit Cn la matrice des codes et C^n.i la i + Ie ligne de cette matrice. La récurence est donnée par :

1.51]

avec Ci = (Ci,o) = 1.

On peut présenter l'ensemble des codes ainsi générés sous la forme d'un arbre comme le montre la figure 1.15. Chaque code Cn,i a deux fils, C2n,2i et C2n,2i+i> qui correspondent respectivement à l'enchaînement (-l-Cî, +Cn>i) et (+Cn , i , — Cn,i). A titre d'exercice, le lecteur peut vérifier qu'on retrouve les codes de Walsh construits avec les matrices d'Hadamard. On le perçoit intuitvement à partir des similarités sur les récurrences de construction. Par exemple Cs,i = w 4.

Figure 1.15. Arbre des codes OVSF (d'après 25.213)

La présentation des codes orthogonaux sous la forme C2n,i permet de combiner de façon simple des codes de longueur différente tout en gardant des propriétés d'ortho-gonalité. En d'autre termes, elle permet de transmettre plusieurs flux d'information à des débits différents en gardant l'orthogonalité. Nous l'expliquons sur un cas particu-liers qui peut être généralisé sans problème. Considérons un utilisateur 1 transmettant


à un débit D avec le code C2n,i et un utilisateur 2 transmettant à un débit double avec le code Cn>i. Notons que, pour ce dernier, le code est plus court. Considérons le temps bit de l'utilisateur 1. Il transmet un bit 61, soit la séquence biC^n,!- Pendant le même temps l'utilisateur 2 transmet deux bits 62 et b'2. Après étalement, on a ^CVu suivi de

Soit le produit scalaire des deux sé-quences transmises pendant un temps-bit du premier utilisateur. Par construction, C2n, 1 équivaut à Cn>0 suivi de —Cn,o- On a donc :

[1-52]

On en déduit : *

[1.53]

Les séquences Cn$ et Cn , i étant orthogonales, on obtient PS = 0.

De façon générale, 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 débit D avec les codes Cs,o à Cg,3 et un flux à un débit 4D avec le code C2,i- La possiblité de moduler les débits explique la dénomination OVSF (Orthogonal Variable Spreading Factor) donnée aux codes de Walsh présentés de cette façon.

1.5. Utilisation du CDMA en radiomobile

Un système 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 différentes stations de base puissent transmettre sans se perturber l'une l'autre. Pour y parvenir, les systèmes cellulaires dits CDMA combinent le CDMA avec des codes orthogonaux et l'étalement de spectre avec des séquence pseudoaléatoires.

1.5.1. Différenciation des stations de base

Considérons d'abord la voie descendante en supposant, temporairement, que chaque station de base n'émet que vers un mobile. Le mobile reçoit un signal utile de sa station de base et des interférences des stations de base voisine. Pour permettre au récepteur de fonctionner correctement, il est nécessaire que l'ensemble des interférences ait une caractéristique proche d'un bruit Gaussien. Le choix de la séquence PN(t) est parti-culièrement important pour garantir cette propriété.


1.5.1.1. Utilisation des m-sequences

Les systèmes tels qu'IS-95 utilisent des séquences PN, appelées m-sequences. Une telle séquence peut être engendrée à partir d'un polynôme binaire p{x) primitif sur GF(2) (GF, Gallois Field) et d'un registre à décalage comportant m bascules rebou-clé linéairement (c'est-à-dire avec des portes « ou exclusif guillemotright) [GAR 00]. On engendre alors une séquence binaire de longueur n = 2m — 1. Un exemple est donné à la figure 1.16 avec le polynôme p(x) = x3 + x + 1. La séquence obtenue est 1110100. Cette séquence est périodique ; on peut prendre de manière équivalente n'importe quelle permutation de la séquence, par exemple 0100111 (ou n'importe quelle permutation de la séquence inverse 0010111). En raisonnant sur des niveaux + et —, on obtient H 1- H .

Figure 1.16. Génération d'une séquence PNde longueur 8

Les séquences PN ont de bonnes propriétés d'autocorrélation (voir figure 1.17). Si l'on considère une séquence périodique, l'autocorrélation peut s'écrire pour toute valeur de k (entier relatif) :

1.54]

Le lecteur peut vérifier à titre d'exercice que l'autocorrélation 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. Autocorrélation (périodique) d'une séquence PN

Les séquences PN sont de longueur n — 2m — 1. Il est en général plus commode d'avoir une séquence d'une longueur puissance de 2. On insère un bit supplémentaire


dans la séquence pour cela. Par exemple, on ajoute un + à la séquence H H , ce qui permet d'avoir autant de + que de —. Les propriétés d'autocorrélation sont légèrement modifiées mais le pic de corrélation reste visible (voir figure 1.18).

Figure 1.18. Autocorrélation d'une séquence obtenue à partir d'une m-séquence

1.5.1.2. Systèmes cellulaires synchrones

Dans un système basé sur une utilisation des m-sequences, on utilise la même sé-quence pour toutes les stations de base. Si deux stations de base transmettent avec la même séquence affectée d'une même phase, il est impossible à la réception de séparer les deux émissions (on néglige les délais de propagation). Pour permettre dans tous les cas de différencier deux stations de base, on affecte à chaque station la même sé-quence mais avec un décalage particulier. Cela nécessite que toutes les stations de base soient synchronisées. On a alors un système synchrone. Entre un mobile et différentes stations de base, les délais de propagation ne sont pas identiques. Il faut donc que le décalage soit suffisamment important pour rester présent à la réception du mobile.

Dans le système IS-95, la séquence a une période de 215 (ce qui correspond à une durée de 26,67 ms). Le débit des données encodées est de 19,2 kbit/s. Le facteur d'étalement est de 64, ce qui donne un débit chip de 1,228 Mchip/s. Une référence temporelle est fournie par des récepteurs GPS (Global Positionning System). A chaque station de base, l'opérateur affecte un décalage en multiple de 64 chips. Il y a donc 512 valeurs de décalage possible. Un décalage de 64 chips correspond à 52pts, soit une distance de 15 km. Un mobile dont la différence de distance par rapport à deux stations de base est de quelques kilomètres n'a donc aucun risque de confondre les deux stations de base.

L'impératif de synchronisation des stations de base en IS-95 a été perçu comme rédhibitoire pour son adoption par les européens dans le cadre de l'UMTS. Notons que cela rend le réseau tributaire d'un réseau de satellites maîtrisé par un pays non européen.


Figure 1.19. Corrélation et autocorrélation de deux séquences de Gold de longueur 32

1.5.1.3. Utilisation des séquences de Gold

Si l'on considère deux émetteurs utilisant chacun une séquence d'étalement propre et transmettant chacun un signal sur le même canal radio, il faut pouvoir isoler chaque signal à la réception. Cela nécessite d'avoir une corrélation faible entre les séquences. Lorsqu'on fait l'intercorrélation de deux séquences PN différentes, il n'y a pas né-cessairement de bonnes propriétés d'intercorrélation. Cependant il est possible de construire des séquences ayant une faible intercorrélation à partir des séquences PN. Ce sont les séquences de Gold [Gol 68]. Elles sont engendrées à partir de deux sé-quences PN (voir [DIN 98] et [SAN 04] pour le principe de construction).

A partir de 2 séquences PN de longueur n = 2m — 1, il est possible de construire 2m +1 séquences de Gold de longueur n. En dehors du pic obtenu lorsqu'on compare la séquence à elle-même sans décalage, la fonction de corrélation est bornée en valeur absolue par 2 m2 +1 pour m impair et 2 + 1 pour m pair. La corrélation entre deux séquences différentes est contenue dans la même borne. Par exemple, pour m = 8, on obtient des séquences de Gold de longueur 256 dont la corrélation varie entre -33 et +33. Pour une séquence de longueur 32, les bornes sont -9 et +9, comme on le constate sur la figure 1.19.

1.5.1.4. Systèmes asynchrones

Dans l'UMTS, on utilise des séquences de Gold obtenues à partir de de m-sequences de longueur 225 — 1. La longueur de la séquence est donc de 33 millions de chips. On n'utilise qu'un extrait de 38 400 chips, ce qui donne une période de répéti-tion de 10 ms. Il y a 512 séquences différentes. Pour différencier deux stations de base,


l'opérateur affecte à chaque station de base une séquence. Grâce aux propriétés des séquences d'intercorrélation de Gold, il n'y a pas besoin de synchronisation entre les stations de base. L'interférence créée par les stations de bases voisines à la réception d'un mobile est assimilable à un bruit gaussien [TAN 04]. On peut donc bénéficier du gain d'étalement. Il est possible d'utiliser la même fréquence sur l'ensemble des stations de base d'un réseau.

Figure 1.20. Exemple d'affectation de séquences de Gold aux stations de base

1.5.2. Principe de transmission sur la voie descendante

La transmission sur la voie descendante combine l'utilisation de codes orthogo-naux (Walsh ou OVSF) pour permettre un multiplexage de plusieurs transmissions et de séquences PN pour permettre une réutilisation de la même fréquence sur diffé-rentes cellules. Le principe de transmission est illustrée à la figure 1.21. On applique à chaque canal (c'est-à-dire à chaque transmissions vers un mobile particulier) une sé-quence de Walsh et une amplification particulière (gain gi). Les différents canaux sont additionnés et on applique à l'ensemble le code d'embrouillage spécifique à la station de base. Ce schéma général simplifié s'applique tant à IS-95 et au CDMA-2000 qu'à l'UMTS. La séquence pseudoaléatoire appliquée à 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 simultanément, il est possible d'allouer des codes dits se-condaires (c'est le cas pour l'UMTS). Cela revient à affecter un deuxième code d'em-brouillage à la station de base. L'interférence intracellulaire est alors importante car il n'y a pas orthogonalité entre les codes primaires et les codes secondaires.

Notons que si l'on considère un canal particulier, on peut voir l'émission comme faite en une seule étape : une multiplication par une séquence PN(t)Wi(t) où Wi(t) est la i-ème séquence de Walsh répétée périodiquement.


Figure 1.21. Principe de transmission sur la voie descendante d'un système radiomobile CDMA

Figure 1.22. Combinaison des codes orthogonaux et des codes de Gold sur la voie descendante

1.5.3. Principe de réception sur la voie descendante

Le récepteur dans le mobile est de type Rake. Pour décoder le canal i, le mobile peut appliquer le schéma de la figure 1.11 en remplaçant PN*(t) par PN*(t)Wi(t).

Le fonctionnement du récepteur Rake nécessite d'estimer les différents trajets du canal de propagation. Cette estimation se fait sur une suite de chips prédéfinis qui ne transportent pas d'information. Cette suite peut être contenue dans chaque bloc de données émis par la station de base vers le mobile (voir chapitre 2). On parle alors de séquence pilote. On peut également utiliser un canal entier, appelé canal pilote [VIT 95]. La solution retenue généralement est d'utiliser le code de Walsh 1, vu sa forme particulière. La station de base ne transmet aucune donnée 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 système cellulaire CDMA, les différents mobiles transmettent sur la même fréquence, qu'ils soient dans la même cellule ou dans une cellule différente. Cela pro-voque, comme sur la voie descendante, un interférence sur la voie montante.


Les mobiles d'une même cellule sont à des distances différentes de la station de base. Si on utilisait des codes orthogonaux pour différencier les mobiles, il faudrait une synchronisation extrêmement précise pour compenser à la durée chip après le dé-lai de propagation et faire en sorte que les signaux à la réception restent orthogonaux. Cela n'est pas possible dans la pratique. On utilise par conséquent des séquences pseu-doaléatoires pour différencier les mobiles entre eux. Dans la plupart des cas (exception faite de l'UMTS TDD), la séquence pseudoaléatoire est propre au mobile et elle ne dépend pas de la station de base à laquelle il est rattaché. Il n'y a donc jamais ortho-gonalité entre deux signaux transmis par des mobiles différents, qu'ils soient dans la même cellule ou dans des cellules différentes. Le principe de transmission est indiqué dans la figure 1.23. Pour que la réception se passe correctement à la station de base, il est nécessaire que les différents mobiles soient reçus avec un puissance voisine (voir chapitre 4). Le contrôle de puissance est vital sur la voie montante.

Dans le système IS-95, la séquence PN est une m-séquence de longueur 242 — 1. Elle dure environ 41 jours ; la phase est spécifique à chaque mobile et calculée à partir de l'identité du mobile. Dans l'UMTS, on utilise des séquences de Gold ou des séquences appelées S(2).

Figure 1.24. Utilisation de séquences propres au mobile sur la voie montante

Notons que l'émission du mobile n'est pas liée à une cellule particulière. Cette caractéristique facilite le soft-handover (voir définition au chapitre 6) car deux stations

Figure 1.23. Principe de transmission sur la voie montante d'un système radiomobile CDMA


de base peuvent être en réception du signal émis par le mobile. L'inconvénient est qu'il est nécessaire que la station de base connaisse la séquence utilisée par le mobile pour le recevoir. Il y en a un très grand nombre possible et la station de base ne peut pas la découvrir toute seule. Tout échange est donc précédé d ' un accès aléatoire qui comprend la transmission de la séquence utilisée par le mobile à la station de base. Cet échange se fait en utilisant une séquence donnée parmi un nombre restreint de séquences possibles.

1.6. Bibliographie

[BAU 0 2 ] BAUDOIN G . , Radiocommunications numériques . 1 , Principes, modélisation et simulation, Dunod, Paris, 2 0 0 2 .

[DIN 98] DINAN E., JABBARI B., « Spreading Codes for Direct Sequence CDMA and Wide-band CDMA Cellular Network », IEEE Communications Magazine, vol. 36, n°9, 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.

[ G L A 96] GLAVIEUX A . , JOINDOT M., Communications numériques : introduction, Masson, Paris, 1996.

[GLI 03] GLISIC S. G., Adaptive WCDMA : theory andpractice, John Wiley and sons, Chi-chester, GB, 2003.

[JAK94] JAKES W. C., Ed., Microwave mobile communications, IEEE Press, Piscataway, N.J., 1994.

[ L A G 0 0 ] LAGRANGE X., Ed., Les réseaux radiomobiles, Collection IC2, Hermès, Paris, 2000.

[PAR 00] PARSONS J., The Mobile Radio Propagation Channel, John Wiley and sons, Chi-chester (GB), 2nd édition, 2000.

[PRO 01] PROAKIS J. G., Digital Communications, Me Graw Hill, 2001.

[SAN 04] S A N C H E Z J . , T H I O U N E M . , UMTS, Hermès Science, Paris, 2e éd. rev. et augm. édition, 2004.

[SMG 98] SMG2 E., Selection procédures for the choice of radio transmission technologies of the universal mobile télécommunications system (UMTS 30.03), Rapport n°ETSI TR 101 112 v.3.2.0, ETSI, Avril 1998 1998.

[TAN 04] TANNER R., WOODARD J., Eds., WCDMA : requirementsandpraticaldesign, John Wiley and sons, Chichester, GB, 2004.

[VIT 95] VLTERBL A., CDMA. Principles of Spread Spectrum Communication, Addison-Wesley, 1995.

Chapitre 2

L'interface radio UTRA-FDD

L'UMTS possède deux modes de transmission sur la voie radio. En mode FDD (Frequency Division Duplex), on sépare la voie montante de la voie descendante en utilisant deux fréquences différentes. Par opposition, le mode TDD (Time Division Duplex) consiste à transmettre les deux voies sur la même fréquence mais à des instants différents. Les recommandations du 3GPP proposent les deux modes FDD et TDD et désignent l'interface radio par le sigle UTRA, Universal Terres trial Radio Access. Le mode UTRA-FDD est caractérisé 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 présentons les mécanismes de l'interface radio d'UTRA-FDD sans aborder les échanges protocolaires qui sont présentés dans le chapitre 6. Après une rapide présentation de l'architecture générale de l'UMTS et de l'architecture en couches de l'interface radio, nous présentons la couche physique et les différents canaux physiques. Nous détaillons ensuite les concepts de format de transport et de canaux de transport. Ensuite nous abordons les fonctions de la couche MAC (Médium Access Control) et les mécanismes radio (sélection, handover). Ceux-ci font partie de la couche RRC (Radio Resource Control) (voir chapitre 6) mais sont également fortement liés aux aspects physiques. Le chapitre se conclut par une présentation d'HSDPA (High Speed Data Packet Access) qui est une évolution importante permettant d'augmenter les débits offerts.

Chapitre rédigé par Xavier LAGRANGE et Sami TABBANE.


2.1. Introduction

2.1.1. Architecture matérielle de l'UMTS

Comme pour GSM, on fait la différence entre le réseau d'accès de l'UMTS appelé UTRAN, Universal Terres trial Radio Access Network, et le réseau cœur (Core Network). Le réseau cœur est composé de l'ensemble des commutateurs, des bases de données et des routeurs qui permettent le transport de l'information et la gestion de l'utilisateur sur l'ensemble d'un territoire.

Le réseau d'accès UTRAN est composé des stations de base déployées sur le territoire. Les recommandations utilisent le terme de nœud B (Node B). Plusieurs nœuds B sont reliés à un RNC {Radio Network Controller) (voir figure 2.1). Le rôle du RNC est de gérer la ressource radio et donc de contrôler les nœuds B. Les fonctions du Nœud B et du RNC sont présentées en détail dans le chapitre 6. Le mobile est appelé UE, User Equipement.

Réseau Coeur

Figure 2.1. Place de l'UTRAN dans le réseau UMTS

2.1.2. Architecture en couches

L'architecture des couches basses sur l'interface radio est illustrée sur la figure 2.1. La couche 1 traite du niveau physique (codage canal, entrelacement, étalement, modulation). Différents niveaux de protections sont disponibles et définissent différents canaux de transport. La couche 2 est découpée en plusieurs sous-couches :

UTRAN

L ' interface radio UTRA-FDD 55

- la couche MAC, Médium Access Control, permet le multiplexage de plusieurs flux sur un même canal de transport, ces différents flux peuvent concerner le même utilisateur ou différents utilisateurs selon les cas ;

- la couche RLC, Radio Link Control, permet de fiabiliser, si nécessaire, la liaison grâce à un protocole de liaison de données ;

- la couche BMC, Broadcast/Multicast Control permet de diffuser des messages à plusieurs mobiles ;

- la couche PDCP, Packet Data Convergence Protocol, permet de supporter différents protocoles réseau (IPv4, IPv6, autres) et offre également un service de compression d'en-tête.

La gestion des ressources radio est assurée par la couche RRC, Radio Resource Control, de niveau 3. Cette couche contient des mécanismes protocolaires entre le mobile et le réseau d'accès (envoi d'un message d'allocation de canal, échange de messages de handover, transmission de mesures). Elle contient également des mécanismes internes liés au contrôle des couches inférieures. Par exemple, les messages RRC déterminent un ensemble de codages correcteurs possibles qui sont appliqués par la couche physique. Comme on le constate sur la figure 2.2, la majorité des couches en dessous de RRC peuvent être contrôlées.

[source 25.301]

Figure 2.2. Architecture en couches sur l'interface radio


Données et signalisations sont transportées de façon similaire par la couche physique. La séparation entre plan usager et plan contrôle se fait au niveau MAC. Différentes entités RLC transportent les données et la signalisation. La couche RRC appartient au plan contrôle. Les couches BMC et PDCP au plan usager.

La pile de protocole est définie entre le mobile et l'UTRAN. En général, l'entité de niveau physique est située dans le nœud B et les entités de niveau supérieur sont situées dans le RNC mais il y a des exceptions pour la couche MAC (voir paragraphe 2.10).

2.2. Caractéristiques générales de la couche physique de FUTRA-FDD

2.2.1. Caractéristiques 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 séparés par les codes OVSF qui sont orthogonaux entre eux. Un code d'embrouillage est appliqué aux émissions de la station de base pour la différencier de ses voisines. Sur la voie montante, la séparation se fait grâce à un code pseudo aléatoire propre à chaque mobile.

Les bandes de fréquences prévues 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 découpées en blocs de 5 MHz, chaque bloc pouvant accueillir une porteuse. Si toute la bande prévue est disponible on dispose de 2 x 60 MHz soit 12 porteuses duplex. On estime à 4 le nombre typique d'opérateurs par pays, chaque opérateur 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 organisée à partir d'une trame temporelle de 10 ms, structurée 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 différence d'un système TDMA où on occupe un seul slot de la trame). Le slot sert à définir la granularité du contrôle de puissance : au sein d'un slot, la puissance est constante mais entre deux slots successifs, il peut y avoir variation de la puissance transmise.


Figure 2.3. Trame de base en UTRA-FDD

Chaque trame est numérotée de 0 à 4 095. Ce numéro est appelé SFN, System Frame Number. Il est incrémenté de 1 à chaque nouvelle trame de 10 ms avec une numérotation modulo 4 096. Le numéro SFN permet de définir de façon précise des structures sur plusieurs trames. Par exemple, lorsqu'un bloc de données est étalé sur 4 trames, le bloc commence systématiquement lorsque SFN modulo 4 vaut 0.

L'accès aléatoire en UTRA-FDD possède 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 durée double du slot élémentaire, soit 1 333,33 (as. Cette durée permet de s'assurer qu'il n'y a pas collision entre deux émissions sur des slots différents quels que soient les délais de propagation entre les mobiles et la station de base (voir paragraphe 2.9.3).

Figure 2.4. Slots d'accès 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 considérer 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 à considérer qu'on transmet dans le plan complexe et qu'un symbole correspond à un nombre complexe parmi les 4 suivants : V2/2(-l-y) et V2/2( l-y) .


Le débit 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 données

Dans cette partie, nous présentons les principaux canaux utilisés pour transporter des données des couches supérieures. Nous appelons un tel canal « canal physique de données » bien que cette dénomination ne soit pas systématiquement reprise par les spécifications. Bien sûr, les données transportées au niveau physique peuvent correspondre à de la signalisation au niveau supérieur. La caractéristique de ces canaux est qu'ils transportent des éléments binaires non interprétés par la couche physique.

2.3.1. Transmission descendante sur canal dédié (DPCH)

Nous présentons dans ce paragraphe l'organisation de la transmission de la station de base vers le mobile (voie descendante) en mode dédié, 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 débit en chips complexes est donc de 2 560/(10/15) kchip/s soit 3,84 Mchip/s. Ces 2 560 chips sont organisés en 4 parties différentes :

- u n champ TFCI (Transport Format Combination Indicator) donne, parmi un ensemble de schémas de codage et d'entrelacement prédéfinis, le schéma 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 séquence prédéfinie qui permet au mobile de sonder le canal de transmission ;

- les données sont séparées en deux champs, le premier champ étant plus court que le second.

Les champs pilote, TFCI et TPC sont nécessaires pour permettre le contrôle physique de la liaison. Ils forment le DPCCH, Dedicated Physical Control Channel. Les champs de données forment le DPDCH, Dedicated Physical Data Channel.


L'appellation « de données » est faite dans le contexte de la couche physique. En vocabulaire OSI, les 2 champs de données constituent un SDU (Service Data Unit) et par conséquent un segment de PDU (Protocol Data Unit) de niveau MAC, ce dernier pouvant contenir aussi bien des données utilisateurs que de la signalisation.

Source : d'après [25.211]

Figure 2.5. Principes de transmission sur la voie descendante (canal dédié)

Données TPC TFCI Pilote Total Facteur Chips Débit (champ 1 + champ 2 (bits) (bits) (bits) (bits) d'étalement pilotes données

en bits) (kbit/s) 0 + 2 2 2 4

10 512 2 048 3

0 + 4 2 0 4 10 512 2 048 6 2 + 6 2 2 8

20 256

2 048 12 2 + 8 2 0 8

20 256

2 048 15 2 + 1 0 2 2 4

20 256 1 024 18

2 + 12 2 0 4 20 256 1 024 21

2+12 2 2 2 20 256

512 21 2 + 1 4 2 0 2

20 256

512 24 6 + 22 2 2 8

40 128 1 024 42

6 + 26 2 2 4 40 128 512 48 6 + 28 2 0 4

40 128 512 51

12 + 48 4 8 8 80 64 512 90 28+112 4 8 8 160 32 256 210 56 + 232 8 8 16 320 16 256 432

120 + 488 8 8 16 640 8 128 912 248 + 1 000 8 8 16 1 280 4 64 1872

Figure 2.6. Schémas de transmission sur la voie descendante (canal dédié)


Les spécifications précisent 16 formats possibles de transmission suivant le facteur d'étalement utilisé, la taille du champ pilote et la présence ou non du champ TFCI. Il existe, de plus, un mode compressé que nous ne présentons pas par souci de simplification. Les principaux formats sont présentés dans la figure 2.6 ainsi que les débits bruts de données. Quel que soit le facteur d'étalement utilisé (SF, Spreading Factor), un slot correspond toujours à 2 560 chips complexes mais la quantité de données transportées 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 débit 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 dédiés contiennent une quantité non négligeable de bits de contrôle : pour une transmission à 21 kbit/s, il y a 6 bits de contrôle pour 14 bits de données, soit 43 %. Les recommandations définissent un canal sur la voie descendante qui ne contient que des bits de données et permet d'atteindre des débits plus élevés qu'un canal dédié pour un même facteur d'étalement. Il s'agit du PDSCH, Physical Downlink Shared Channel (voir figure 2.7). Le terme « partagé » (shared) fait référence au fait qu'il peut contenir sur des trames successives des données destinées à différents mobiles. Le destinataire des données est indiqué dans les informations de couches supérieures. Le débit brut maximal qu'on peut atteindre est de 1 920 kbit/s (voir figure 2.8).

Figure 2.7. Structure du PDSCH


Données Etalement Débit de données (kbit/s)

20 256 30 40 128 60 80 64 120 160 32 240 320 16 480 640 8 960

1 280 4 1 920

Figure 2.8. Schémas de transmission sur le PDSCH

Le canal PDSCH a été conçu pour permettre un mode paquet sur la voie radio1. Il est toujours utilisé conjointement avec un canal physique dédié car il est nécessaire de contrôler 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 dédié lui-même. Un exemple d'utilisation est montré en figure 2.9. Trois utilisateurs consultent, par exemple, un serveur. Pour chacun, un circuit bas-débit supporté par le DPCH est établi pour la signalisation, ce circuit consomme peu de ressources. Lorsque des données sont transmises vers un utilisateur, on utilise le PDSCH qui dispose d'un débit élevé et nécessite donc un faible étalement. Le principe général est de transmettre à un instant donné vers un utilisateur le plus rapidement possible en utilisant la totalité du PDSCH (première transmission dans le dessin) mais rien n'empêche de diviser le PDSCH en code entre plusieurs utilisateurs (deuxième transmission sur le dessin).

temps

Figure 2.9. Principe d'utilisation du PDSCH

1. Le canal PDSCH n'est pas utilisé dans les réseaux opérationnels en 2004. Il est cependant présenté dans cet ouvrage car les mêmes principes sont repris pour HSDPA.


2.3.3. Canal de diffusion de données (S-CCPCH)

Lorsque le réseau a besoin de diffuser des données à plusieurs mobiles, il peut utiliser le canal de contrôle commun secondaire (S-CCPCH, Secondary Common Control Physical Channel). Ce canal est improprement appelé canal physique de contrôle. 11 n'a aucune action de contrôle au niveau physique mais il est utilisé pour transporter des données fournies par les couches supérieures : appel en diffusion des mobiles (paging), diffusion de données à un ensemble de mobiles ou à un mobile particulier (voir canal de transport FACH). La notion de « contrôle » se rapporte donc au niveau supérieur 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 présence du TFCI permet d'utiliser dynamiquement plusieurs formats de transport. Dans le cas où le réseau transmet des données à un seul mobile et où la position du mobile est connue approximativement, il est possible de transmettre le signal en direction du seul mobile concerné (beam-forming). Le mobile doit alors disposer de bits pilotes pour faire correctement le sondage du canal (analyse des multitrajets et ajustement du récepteur en râteau).

Le facteur d'étalement du S-CCPCH peut varier de 4 à 256. Suivant la présence ou non des champs TFCI et des bits pilotes, la taille des données encodées varie de 10 bits à 1 272. Les débits correspondants vont de 15 kbit/s à 1 908 kbit/s au niveau physique. Ce débit inclut donc les données après codage correcteur et il correspond typiquement à un débit utile de 7 à 600 kbit/s environ.

Figure 2.10. Format du canal S-CCPCH

2.3.4. Transmission montante sur canal dédié

La transmission sur la voie montante est différente de celle de la voie descendante. On définit les canaux physiques de données DPDCH et de contrôle DPCCH respectivement à partir des voies en phase et en quadrature. Sur chaque voie, 2 560 chips réels sont transmis pendant un slot. Le facteur d'étalement pour le


canal de contrôle est toujours égal à 256, ce qui donne 10 bits de contrôle physique. La répartition des bits diffère 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 schémas de codage et d'entrelacement prédéfinis, le schéma utilisé ;

- un champ TPC (Transmit Power Control) contient une commande pour contrôler la puissance de la voie descendante ;

- un champ FBI (Feed Back Indicator) donne une indication sur la puissance de transmission et permet de réaliser la boucle fermée de contrôle de puissance de la voie descendante ;

- un champ Pilot contient une séquence prédéfinie qui permet à la station de base de sonder le canal de transmission.

Figure 2.11. Principes de transmission sur la voie montante (canal dédié)

DPDCH sur voie I

Données Facteur d'étalement

SF

Débit des données (kbit/s)

10 256 15 20 128 30 40 64 60 80 32 120 160 16 240 320 8 480 640 4 960

DPCCH sur voie Q (15 kbit/s)

Bits pilotes

TPC TFCI FBI Total Facteur d'étalement

SF

Chips pilotes

8 2 0 0 2 048 7 2 0 1 1 792 6 2 2 0 10 256 1 536 6 2 0 2 1 536 5 2 2 1 1 280 5 1 2 2 1 280

Figure 2.12. Schémas de transmission sur le canal physique dédié montant (DPCH)


Le facteur d'étalement sur le canal de données DPDCH peut varier de 256 à 4, ce qui permet d'envisager des débits bruts de 15 à 960 kbit/s. Il est possible (voir section 2.5.2) de disposer de plusieurs DPDCH et d'augmenter encore les débits.

2.3.5. Canal d'accès PRACH

Le canal d'accès (PRACH, Physical Random Access Channel) permet au mobile d'émettre des messages sans utiliser le code d'embrouillage qui lui est propre. En conséquence, un message peut être envoyé par le mobile à tout moment mais l'émission peut entrer en collision avec d'autres transmissions du même type. Le mécanisme d'accès est décrit dans le paragraphe 2.9.3.

La structure du canal PRACH est indiquée à la figure 2.13. Elle est proche de celle du canal de données sur la voie montante. Les données sont transmises sur la voie en phase et le contrôle sur la voie en quadrature. Le contrôle 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 utilisés sur le PRACH. Les débits correspondants sont donnés dans le tableau de la figure 2.14 pour permettre de comparer le poids du contrôle par rapport aux données. Parler de débit 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'arrête 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 (télémesures, ...).

Source : 25.211

Figure 2.13. Structure du canal PRACH


Données Contrôle

Données (bits)

Facteur d'étalement

Débit des données (kbit/s)

Pilot TFCI Total Facteur d'étalement

Chips pilotes

Débit de contrôle (kbit/s)

10 256 15 8 2 10 256 2048 15 20 128 30

8 2 10 256 2048 15

40 64 60

8 2 10 256 2048 15

80 32 120

8 2 10 256 2048 15

Figure 2.14. Schémas de transmission sur le canal PRACH

2.4. Canaux physiques de contrôle

Dans cette partie, nous présentons les principaux canaux utilisés par les mobiles pour contrôler certains paramètres 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 désignés comme canaux de contrôle par la norme. En général, ils ne transportent pas de données relatives aux couches supérieures.

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 réseau d'accès UTRAN de type FDD émet régulièrement un code prédéfini. Celui-ci permet au mobile de se synchroniser et, par là-même, de vérifier qu'il est bien à l'écoute d'un réseau UMTS. L'émission régulière de ce code prédéfini constitue le canal primaire de synchronisation (P-SCH, Primary Synchronization Channel).

Le code utilisé est une suite de 256 chips basée sur une séquence généralisée de Golay [25.213]. Elle a de bonnes propriétés d'auto-corrélation. Quand un mobile est sous tension, il examine les fréquences de la bande UMTS et fait une corrélation entre la suite de chips reçue sur cette fréquence et le code du P-SCH (principe du filtre adapté). En détectant les pics de corrélation, le mobile détecte 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 corrélation peuvent correspondre à l'émission d'une même station de base. Le mobile n'est pas capable de différencier ce cas de deux émissions de stations de base différentes avec une synchronisation très proche.


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 déterminer le début de la trame de 10 ms et différencier 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 même code à chaque slot. On a une séquence de 15 codes successifs (Ç/'°, C/'1,... C/14) où i est un indice définissant une séquence parmi 64 séquences différentes [25.213] ; par conséquent la période de répétition de chaque séquence correspond à une trame de 10 ms. Les séquences (CJ'°, Cs''\... Cs

lM) possèdent de bonnes propriétés d'autocorrélation et d'intercorrélation. Pour chaque séquence, toute permutation ne redonne pas la même séquence, ni aucune autre. Par exemple, (C/7 , C/'8,... C/14, C/0 , . . . C/6) est différent de (C/°, C/'1,... C/'14) pour tout y, y compris j = i.

Après avoir établi la synchronisation slot, le mobile recherche la séquence (C,' 0, C/1 , . . . C/'14) parmi les 64 séquences possibles. Une fois qu'il l'a trouvée, il identifie le début de la trame (voir figure 2.15). L'opérateur affecte des séquences différentes à des stations de base qui peuvent interférer : le canal de synchronisation secondaire est donc caractéristique d'une station de base dans une zone géographique donnée. L'opérateur peut réutiliser le même code sur deux stations de base si celles-ci sont suffisamment éloignées.

256 chips complexes « •

SCH primaire J ^ - ™ # g b SCH secondaire — J L ^

S C H < t R H B B code OVSF CPICH I — j I ! I I C256.0

s lo to slot 1 slot 14 t e m P s

t rame de 10 ms r

CPICH Séquence de 20 bits à 0 avec étalement 256

2560 chips complexes « •


2.4.2. Canal pilote CPICH

Le canal pilote commun à la cellule (CPICH, Common Pilot Channel) a pour objet de permettre au mobile de déterminer le code d'embrouillage utilisé par la station de base et fournit un signal continu autorisant des mesures d'énergie pour déterminer, 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 séquence de chips transmise correspond donc toujours au code d'embrouillage.

Lorsque le mobile est synchronisé grâce à l'écoute des SCH, il ne connaît pas le code d'embrouillage mais seulement le groupe auquel appartient cette séquence. En effet, la recommandation définit une correspondance entre un groupe de 8 codes d'embrouillage et la séquence utilisée sur le canal SCH secondaire (il y a en effet 512 codes d'embrouillage soit 64 x 8 pour 64 séquences de S-SCH). Le mobile peut essayer successivement les 8 possibilités pour déterminer la séquence réellement utilisée.

2.4.3. Canal de diffusion des informations système (P-CCPCH)

Le canal de contrôle commun primaire (P-CCPCH, Primary Common Control Physical Channel) permet de diffuser les informations système utiles pour que le mobile puisse se mettre en veille sur le réseau. Ce canal est diffusé sur l'ensemble de la cellule.

La structure du P-CCPCH est complémentaire 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 véritablement actif que lorsque les canaux de synchronisation sont inactifs. Il contient donc 2560-256 = 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 préalable 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 indiquée.

Contrairement aux autres canaux présentés dans cette partie, le P-CCPCH transporte des données des couches supérieures. Cependant ces données sont


toujours des données de contrôle au niveau 3 (messages RRC). C'est ce qui explique la dénomination Control pour ce canal.

Figure 2.16. Structure du canal P-CCPCH

2.4.4. Canaux d'indication de paging (PICH)

Un mobile en veille doit constamment écouter le réseau pour détecter un éventuel appel en diffusion [paging). Si les cellules sont de grande capacité et les zones de paging étendues, l'opérateur doit configurer un canal S-CCPCH à débit assez important car un grand nombre d'appels en diffusion doit être écoulé. Les mobiles consomment une énergie non négligeable pour décoder tous les messages d'appel alors qu'une infime proportion les concerne.

Pour réduire 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 réseau transmet régulièrement un indicateur de paging pour chaque groupe. Si l'indicateur est inactif, le mobile n'a pas besoin de décoder les messages d'appels : aucun mobile de son groupe n'est appelé et il peut s'abstenir de décoder le canal S-CCPCH. Si l'indicateur est actif, un message d'appel peut lui être envoyé, il doit alors décoder 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 à répétition est utilisé pour réduire le taux d'erreur. Le taux de codage peut varier de 1/16 à 1/2 suivant la configuration du réseau. Cela permet de transmettre de 18 à 144 indications de paging. On peut définir un cycle sur plusieurs trames de 10 ms et constituer ainsi un nombre bien supérieur de groupes de paging (voir [25.211]).

SCH pi J 5 a . H C P I C H ' - -— r" I " " code OVSF C256.0 P - C C P C H ^ ^ ' " J » code OVSF C256 1

s l o t o slot 1 slot 14 t e m P s

trame de 10 ms

P-CCPCH Séquence de 18 bits avec étalement 256

2304 chips complexes 4 - •


2.4.5. Canal d'acquittement de préambule (AICH)

Lors de l'accès aléatoire (voir section 2.9.3), le mobile émet un préambule parmi 16 préambules possibles dans un slot d'accès. Grâce au canal AICH, Acquisition Indicator Channel, le réseau peut indiquer les préambules qui ont été correctement reçus. On peut voir le canal AICH comme étant composé de 16 canaux transportant chacun un bit d'indication d'acquisition par préambule possible dans un slot d'accès. Ces 16 canaux sont multiplexés 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'opérateur. La longueur en chips est donc de 32 x 256=4 096 chips. Le slot d'accès est de 5 120 chips. Il y a donc 1 024 chips non utilisés et utilisables dans le futur.

2.4.6. Autres canaux physiques

Les recommandations spécifient d'autres canaux physiques que ceux présentés dans ce chapitre. Le PCPCH, Physical Common Packet Channel, est un canal qui permet de disposer d'un accès aléatoire plus performant. Le terminal émet un préambule comme pour le RACH, ce préambule est acquitté mais il y a une phase supplémentaire de détection de collision. Cela permet une transmission plus longue et contrôlée 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 contrôle de puissance.

2.5. Principes des chaînes de transmission

2.5.1. Chaîne de transmission sur la voie descendante

Sur la voie descendante, la station de base transmet plusieurs flux en parallèle à différents mobiles sur un support physique unique. Le principe de transmission est présenté dans la figure 2.17. Chaque flux de la couche physique à un débit D est découpé en deux flux par un convertisseur série/parallèle (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 débit D de telle sorte que le débit en sortie est toujours de 3,84 Mchips complexes par seconde. Les différents canaux sont ensuite amplifiés en fonction de l'algorithme de contrôle de puissance. Après sommation, on applique le code d'embrouillage propre à la station. Enfin, on


passe dans l'étage de modulation. Pour les canaux de synchronisation dont la structure est particulière, 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 défini 512 codes de brouillage utilisables organisés en 64 groupes de 8 codes.

Le symbole j désigne 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. Chaîne de transmission sur la voie montante

Sur la voie montante, les émissions des différents mobiles s'additionnent sur le canal de propagation radio. La figure 2.18 présente la chaîne de transmission pour un mobile. Il y a toujours un seul canal de contrôle. Il est possible de multiplexer plusieurs canaux physiques de données pour un même mobile en utilisant des codes OVSF différents (et qui sont orthogonaux). Il n'est pas sûr que cette possibilité prévue par la norme soit vraiment utilisée.

2.6. Gestion de format de transport

La couche physique gère également le codage correcteur d'erreur. Pour permettre une grande souplesse dans le choix du type de codage, les recommandations introduisent la notion de format de transport.


Figure 2.18. Multiplexage et modulation sur la voie montante pour le canal dédié

2.6.1. Notion de format de transport

Dans les communications radiomobiles, le canal de transmission est très fluctuant. Il n'est pas possible de définir un codage correcteur unique et applicable à toutes les situations. Dans l'UMTS, on définit un grand nombre de schémas de codage. Il n'y a pas de schéma de codage imposé pour un service donné. C'est à l'opérateur de choisir le codage plus adapté à un service donné dans des conditions données. Cependant, les recommandations spécifient un principe général de codage avec un large choix possible à l'intérieur de ce cadre général [25.212].

Le codage porte systématiquement sur des blocs de données appelés blocs de transport (transport block). Un bloc est éventuellement protégé par un code détecteur d'erreur de type CRC (Cyclic Redundancy Check) ; le bloc protégé 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 poinçonné ou bien étendu par répétition de certains bits pour se conformer à une taille imposée par la couche physique (nombre de bits de données disponibles sur le canal physique). Cette opération est appelée adaptation de débit ou rate matching. La transmission du bloc encodé peut se faire sur une durée supérieure à une trame de 10 ms. Le TTI, Transmission Time Jnterval, est le paramètre définissant l'étalement d'un bloc encodé. Ce paramètre peut valoir 1, 2, 4 ou 8 trames de 10 ms. Le bloc encodé est donc segmenté suivant la valeur du TTI. Un deuxième entrelacement peut être effectué avant la répartition des bits sur les champs de données des canaux physiques.


Il est possible de transporter plusieurs blocs de transport dans un même TTI. Dans ce cas, le canal de transport accepte un ensemble de blocs de transport, appelé Transport Block Set.

Les recommandations proposent une boîte à outils de codage. Le choix d'un outil dans cette boîte forme ce qu'on appelle un « format de transport ». Les paramètres d'un format de transport sont listés 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 définition d'un format de transport. Dans ce cas, l'ensemble des blocs de transport est réduit à un seul bloc.

Lorsqu'un support radio (radio bearer) est établi, le format de transport est précisé dans le message d'allocation RRC : longueur du CRC, type de correction d'erreur, valeur du TTI. Ces paramètres sont valables pour toutes les transmissions.

Figure 2.19. Principe général du codage dans l'UMTS


Il est cependant possible, par un échange de messages RRC, de les modifier : les recommandations parlent de paramètres 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 précisé dans les messages RRC d'établissement ou de modification. A chaque transmission, le champ TFCI permet au récepteur de retrouver les valeurs utilisées.

Taille du bloc de transport

Transport Block Size

variable dynamiquement paramètres dynamiques :

Nombre de blocs de transport

Transport Block Set Size

variable dynamiquement ensemble de valeurs définis par

signalisation RRC 24 16

Détection CRC 12 Paramètres

semi-statiques d'erreur 8 Paramètres

semi-statiques 0

Paramètres semi-statiques

taux 1 (pas de codage) une valeur

choisie parmi n possibles

par signalisation RRC

Code convolutionnel

taux 1/2 une valeur choisie parmi

n possibles par signalisation

RRC

Correction d'erreur

taux 1/3

une valeur choisie parmi


RRC Turbo-code taux 1/3

une valeur choisie parmi


RRC

Nombre de 1 trame ( 10 ms) trames de 10 ms Valeur du TTI 2 trames (20 ms)

pour la 4 trames (40 ms) transmission 8 trames (80 ms)

Figure 2.20. Paramètres d'un format de transport

2.6.2. Combinaison de formats de transport

Les recommandations spécifient un large éventail de schémas de codage. Dans certains cas, les éléments binaires d'un bloc de données à transmettre n'ont pas tous la même sensibilité aux erreurs. En particuliers pour la parole, la qualité perceptible à la restitution dépend plus de la réception correcte de certains bits que d'autres (en simplifiant à l'extrême, les bits de poids forts sont plus importants que les bits de poids faible). Il est donc intéressant de combiner les formats de transport et de permettre, pour un flux venant d'une seule source, de coder différentes parties de ce flux de manière différente. On obtient le concept canal de transport composite ou CCTrCH (Coded Composite Transport Channel).


Dans l'exemple représenté, on considère qu'il n'y a qu'un bloc de transport par ensemble de bloc de transports et que tous les différents canaux de transport ont le même TTI pour simplifier la représentation.

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 uniformément les 244 bits, on les différencie 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 protège 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 protège pas les bits de classe C. On a ainsi 3 canaux de transport différents mais qui sont utilisés simultanément. Les 3 canaux ont le même 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 multiplexés. Sur chaque canal de transport, il y a possibilité de faire varier les paramètres dynamiques (tailles de blocs de transport et nombre de blocs). Soient n et


p respectivement le nombre de canaux de transport et le nombre de valeurs de paramètres dynamiques. En considérant que tous les canaux ont le même TTI, il y a p" combinaisons possibles. Pour éviter une signalisation trop gourmande, seul un nombre restreint de combinaisons est autorisé. Ces combinaisons sont indiquées lors de rétablissement du support radio (radio bearer) et numérotées. Le TFCI, Transport Format Combination Indicator, permet d'indiquer la combinaison utilisée parmi celles autorisées.

Si l'on considère les canaux de transport définis pour le codeur AMR. On a un canal composite formé de 3 canaux en parallèle (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 autorisées (voir tableau de la figure 2.23).

DCH 1

Numéro du format de transport

Taille du bloc de

transport

1 81

2 65

3 75

4 61

5 58

6 55

7 49

8 42

DCH 2


Taille du bloc de

transport

1 103

2 99

3 84

4 87

5 76

6 63

7 54

8 53

DCH 3


Taille du bloc de

transport

1 60

2 40

3 0

paramètres statiques pour DCH 1

CRC 8

Codage Convoi. 1/3

TTI 20 ms


CRC 0

Codage Convoi. 1/2

TTI 20 ms


CRC 0

Codage taux 1

TTI 20 ms

Figure 2.22. Exemple de formats de transport {pour la voix AMR)


Valeur TFCI Numéro de Format Numéro de Format Numéro de Format sur DCH 1 sur DCH 2 sur DCH 3

1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 3 5 5 5 3 6 6 6 3 7 7 7 3 8 8 8 3

Figure 2.23. Exemple de combinaisons de formats de transport et de définition de TFCI (pour la voix AMR)

2.6.4. Canaux de transport

Les canaux physiques sont définis comme pouvant transporter des données sans aucune protection. Les canaux de transport permettent le transport de données avec un certain degré de protection contre les erreurs. Plus généralement un canal de transport est lié à la manière dont les données sont transmises : diffusées sur toute la cellule, transmises à un utilisateur particulier, transmises en association avec un mécanisme d'économie d'énergie, etc.

Les recommandations définissent deux types de canaux de transport : les canaux de transport dédiés qui sont affectés à 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 dédié : le DCH (Dedicated Channel). Un DCH utilise nécessairement un DPDCH (Dedicated Physical Data Channel) mais on peut multiplexer dynamiquement plusieurs DCH sur un même DPDCH grâce à 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 à débit fixe et relativement faible utilisant le P-CCPCH (Primary Common Control Physical Channel) ;

- le canal FACH (Forward Access Channel) est un canal descendant diffusé sur toute la cellule en utilisant le canal physique S-CCPCH (Secondary Common Control Physical Channel ;


- le canal PCH (Paging Channel) est un canal descendant utilisant le S-CCPCH comme le FACH mais il est associé au mécanisme d'économie d'énergie disponible grâce 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 synthétise les différents canaux de transport.

Canal Nom Sens Canal physique Remarques BCH Broadcast channel 1 Primary Common Control

Physical Channel (P-CCPCH)

Diffusion des informations système,

débit faible FACH Forward access

channel i Secondary

Common Control Phvsical Channel

(S-CCPCH)

Adresse mobile explicite à inclure

PCH Paging channel 1

Secondary Common

Control Phvsical Channel (S-CCPCH)

Systèmes d'économie d'énergie

DSCH Downlink shared channel

i Physical Downlink Shared Channel

(PDSCH)

Données en mode paquet (nécessite un

DCH) RACH Random access

channel î Physical Random Access

Channel (PRACH) Données limitées (ou

signalisation) DCH Dedicated channel u Dedicated Physical

Channel (DPCH) Débit variable à

chaque TTI Adresse MS implicite

Figure 2.24. Canaux de transport et correspondance avec les canaux physiques

2.7. Couche MAC

2.7.1. Fonctions de la couche MAC

La couche MAC (Médium Access Control) offre des procédures de contrôle d'accès des services de données à la couche physique par l'intermédiaire des canaux de transport. La couche MAC multiplexe les canaux logiques sur les canaux physiques et inversement, grâce à une table de correspondance. La couche MAC doit également négocier les paramètres de QoS en gérant les contentions entre les demandes de services en établissant des priorités entre les accès. Les fonctions principales de la couche MAC sont les suivantes :

- sélection du format de transport correspondant à chaque canal de transport en fonction du débit instantané et des indications de la couche RRC ;


-gestion des priorités entre flux de données pour chaque mobile. Lors de la sélection entre plusieurs formats de transport, la couche MAC détermine les priorités entre flux de données véhiculés sur les canaux de transport correspondants. Ces priorités sont par exemple basées 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 réalisée en sélectionnant le format de transport pour lequel les données à priorité la plus élevée sont transportées sur les canaux physiques à haut débit ;

-gestion dynamique des priorités entre usagers afin d'utiliser les ressources spectrales efficacement pour le transfert de données sporadiques. La couche MAC gère les priorités sur des canaux de transport communs et partagés. Pour les canaux dédiés, 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 démultiplexage des PDU en provenance ou émis vers les

couches supérieures vers ou en provenance de la couche physique sur les canaux de transport communs ainsi que sur les canaux de transport dédiés. La couche MAC supporte le multiplexage des canaux de transport communs, fonction que la couche physique ne supporte pas. Cette fonction est activée quand plusieurs services de couches supérieures (par exemple RLC) utilisent sur le même canal de transport. L'indicateur correspondant est inclut dans l'information de contrôle MAC ;

- commutation dynamique de canal de transport. La couche MAC commute les flux de données entre les canaux de transport communs et dédiés sur la base des indications de la couche RRC ;

- chiffrement : cette fonction est réalisée par la couche MAC pour le mode RLC transparent ;

- supervision du volume de trafic. La couche MAC est chargée de mesurer le volume de trafic transporté sur les canaux logiques et de reporter ces mesures à la couche RRC. Grâce à cette information, la couche RRC sélectionne les canaux de transport associés à chaque flux de données.

La figure 2.25 indique les relations entre la couche MAC et la couche RRC pour assurer les fonctions et échanges précisés plus haut. En particulier, grâce à ces échanges, la couche MAC assure la gestion de la ressource radio sur le court terme en fonction des indications générales de la couche RRC telles que le choix du format de transport parmi les formats de transport possibles et ce, en fonction des données de la source, de la charge de la cellule.


Figure 2.25. Relations entre couches MAC, RRC et physique.

2.7.2. Canaux logiques

L'entité de niveau supérieur au niveau MAC (c'est-à-dire RLC) accède à cette dernière par l'intermédiaire de canaux logiques. Les canaux logiques correspondent aux différents types d'information véhiculés. On fait donc la différence à ce niveau entre le contrôle (dans le plan C) et les données usager (dans le plan U).

Les canaux logiques peuvent être dédiés, c'est-à-dire que les données sont échangés entre le réseau et un mobile particulier, ou bien communes. Dans ce cas, tout mobile de la cellule peut, soit lire les données, soit en envoyer vers le réseau.

Les canaux logiques de contrôles sont les suivants :

- le canal BCCH (Broadcast Control Channel) est utilisé pour diffuser les informations de contrôle et particulièrement le paramétrage de la cellule et du réseau (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 contrôle entre un mobile et le réseau avant l'établissement d'un canal logique dédié ;


- le canal DCCH (Dedicated Control Channel) sert à échanger les informations de contrôles sur les connexions actives, il est utilisé pour l'échange de la signalisation de niveau supérieure (RRC, MM, CC,...).

Les canaux logiques de données sont les suivants : - le canal DTCH (Dedicated Trajfic Channel) permet l'échange des données

usagers (voix, données, images, visiophonie,...) entre un mobile et le réseau ; - le canal CTCH (Common Trajfic Channel) est un canal descendant qui permet

au réseau de diffuser des données. Il peut s'agir par exemple d'informations routières, météorologiques, 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 paraître artificielle. En revanche, elle a un intérêt évident dans le cas des canaux dédiés en termes de gestion de ressources. En effet un canal DTCH peut être supporté soit par un canal de transport DCH, soit par un canal DSCH, soit par un couple FACH-RACH. Dans le premier cas (utilisation du DCH), cela signifie qu'on fonctionne en mode circuit : une ressource est allouée pendant toute la connexion et toutes les données 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 réservé spécifiquement à un mobile : on retrouve donc le mode paquet où la ressource n'est utilisée que lorsqu'il y a transmission effective de données. Plusieurs mobiles sont susceptibles d'écouter le FACH et il faut que seul le mobile auquel l'information est destinée en tienne compte. Il est nécessaire d'indiquer un identifiant du mobile dans les données transmises (dans le PDU MAC). Plutôt que d'utiliser l'identité complète 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 ambiguïté 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-tête optionnel et une unité de donnée de service (MAC SDU, MAC Service Data Unit) de tailles variables. Le contenu et la taille de l'en-tête MAC dépend du type de canal logique. Dans certains cas, aucun paramètre


de l'en-tête MAC n'est nécessaire, c'est le cas pour un canal logique dédié transporté par un canal de transport dédié DCH (exemple du paragraphe 2.8.1). La taille des MAC SDU dépend quant à elle de la taille de la RLC-PDU, qui est définie pendant la procédure d'initialisation de la liaison.

Entête MAC MAC SDU < •

TCTF UE-ld Type UE-ld C/T 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 dédié ;

- UE-ld : lorsqu'on utilise un canal de transport commun comme support d'un canal logique dédié, le champ UE-ld permet d'identifier le mobile concerné par le MAC-PDU (destinataire ou expéditeur). 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 : détermine si l'UE-Id est un U-RNTI ou un C-RNTI ; - Champ C/T : identifie le canal logique quand plusieurs canaux logiques sont

transportés sur le même canal de transport. Il est également utilisé pour identifier le type de canal logique sur les canaux de transport dédiés et sur les canaux FACH et RACH quand ils sont utilisés pour la transmission de données usager. La taille du champ C/T est fixée à 4 bits pour les canaux de transport communs et dédiés.

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 différentes variantes. Le mode circuit consiste, de façon classique, à allouer un canal physique dédié DPCH pendant toute la durée d'une communication vocale ou d'une session de données.

Le mode paquet peut être réalisé de diverses façons :

- l e réseau alloue un canal physique dédié au mobile seulement lorsqu'il doit transmettre ou recevoir des données, cela n'est envisageable que si les données sont relativement longues car le mécanisme d'allocation est relativement lourd ;


- le réseau alloue un canal physique dédié bas débit pendant toute la durée de la session pour contrôler la session et utilise le canal dédié DSCH pour transmettre les données au mobile, ce mécanisme est intéressant si les transmissions descendantes sont plus importantes que les transmissions montantes ;

- le réseau utilise le FACH pour les transmissions descendantes et le mobile utilise le RACH pour les transmissions montantes, les débits sont limités sur ces canaux et ce mode est adapté aux transmissions sporadiques de données courtes.

Chaque solution peut être modulée. Dans la plupart des applications, les protocoles de niveau supérieur entraînent l'échange de blocs avec un certain délai entre les blocs. On peut donc moduler la première solution avec une temporisation qui maintient le canal physique dédié pendant un certain délai d'inactivité après une transmission. Cette grande souplesse de l'UMTS a comme contrepartie une complexité pour paramétrer le fonctionnement.

La caractéristique commune à une session en mode paquet et une communication en mode circuit est que le mobile est connu du réseau UTRAN. Une connexion RRC est maintenue entre le mobile et le RNC (voir paragraphe 6.6.3).

2.8. Synthèse sur les différents canaux de l 'UMTS et exemples

2.8.1. Exemple de canaux de données

Les nombreux paramètres définissant les canaux de transport permettent d'envisager sur l'interface radio une grande variété de débits. Dans le tableau 2.27, on présente 3 exemples de débits possibles (12,2 ; 64 et 384 kbit/s) et les principaux paramètres associés. Le mode utilisé est de type circuit. Les données utilisateur sont transportées par le canal logique DTCH ; la signalisation associée pour maintenir la liaison radio (transmission de mesures par exemple) est transportée sur un DCCH dont le débit 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 données (DPDCH). Pour chaque débit utilisateur, on donne le débit de données 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 débit 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 différents du fait d'une organisation différente de la voie montante et descendante. Le facteur d'étalement est inférieur sur la voie montante car le canal DPCCH prend entièrement la voie en en quadrature (c'est-à-dire que l'on occupe 50 % du canal


physique). Sur la voie descendante, les champs de contrôle occupent nettement moins que 50 % du total disponible.

Type de service (sur DTCH)

12,2 kbit/s 64 kbit/s 384 kbit/s

canaux logiques DTCH DCCH DTCH DCCH DTCH DCCH Taille d'un bloc de

transport 244 100 1280 100 3840 100

TTI 20 ms 40 m s 20 ms 40 ms 10 ms 40 ms CRC 16 12 16 12 16 12

Codage Codage convolutif

Codage convolutif

Turbo Code

Codage convolutif

Turbo Code

Codage convolutif

Taux de codage 1/3 1/3 1/3 1/3 1/3 1/3

voie descendante

DPDCH 42 kbit/s 210 kbit/s 912 kbit/s voie descendante SF 128 32 8

voie montante

DPDCH 60 kbit/s 240 kbit/s 960 kbit/s voie montante SF 64 16 4

Figure 2.27. Principaux paramètres radios pour différents types de service

Figure 2.28. Organisation du transport pour un circuit à 64 kbit/s sur la voie descendante, source [25.101]


Figure 2.29. Organisation du transport pour un circuit à 64 kbit/s sur la voie montante, source [25.101]

2.8.2. Canaux physiques, de transport et logiques

La figure 2.30 donne une vue synthétique des principaux canaux en UTRA-FDD. Mis à par quelques différences mineures (voir chapitre 3), le tableau s'applique également pour UTRA-TDD.

Du point de vue de l'architecture en couches, la différenciation entre plan usager et plan de contrôle ne se fait qu'au niveau des canaux logiques : les canaux de données (plan usager) sont représentés sur fond grisé.

2.9. Procédures radio

2.9.1. Mécanisme de recherche de cellule

La procédure de recherche de cellule a lieu lorsque le mobile est à l'état inactif. Le mobile recherche le code de synchronisation primaire identique pour toutes les cellules sur le P-SCH (voir paragraphe 2.4.1.1). Il recherche ensuite le pic le plus important sur le canal SCH secondaire (S-SCH).


Remarque : il n'est pas interdit d'utiliser le DSCH pour transporter du contrôle (DCCH) mais ce n'est pas une utilisation probable.

Figure 2.30. Synthèse sur les canaux physiques, de transport et logiques

Quand le code de synchronisation secondaire est détecté, le mobile recherche les codes d'embrouillage que la station de base utilise parmi les 8 codes du groupe défini par le code de synchronisation secondaire (voir figure 2.31). Dès qu'il connaît le code d'embrouillage, il est capable de décoder tous les canaux. Il peut notamment décoder la voie balise, qui est le canal logique BCCH transporté dans le BCH physiquement transmis sur le P-CCPCH. Il peut donc connaître la configuration de la cellule et du réseau.

2.9.2. Veille sur une cellule

2.9.2.1. Grandeurs mesurées par le mobile

Chaque terminal mesure plusieurs indicateurs pour évaluer le niveau de réception et la qualité du signal reçu. Les recommandations proposent une panoplie de mesures possibles et laissent le choix à l'opérateur et au constructeur d'utiliser seulement celles qu'ils considèrent comme les plus pertinentes.

Les mesures possibles sont définies dans les spécifications [25.215]. Les mesures de puissance reçue permettent, lorsqu'on connaît la puissance d'émission, d'estimer l'atténuation entre la station de base et le mobile et par conséquent d'estimer la distance entre les deux. La mesure du Ec/NO permet d'estimer le niveau d'interférence et par conséquent de prévoir la qualité de la liaison. Ces mesures se font généralement sur le canal pilote car c'est une référence stable. Le taux d'erreur


bit permet de mesurer a posteriori la qualité d'une liaison établie et cette mesure se fait donc sur un canal de transport. Les recommandations proposent également d'utiliser les mesures de différences de temps entre des trames venant de 2 stations de base différentes pour accélérer des mécanismes de synchronisation.

Figure 2.31. Fonctionnement général 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

reçu 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 reçue sur une porteuse UTRA ; - le GSM carrier RSSI {Received Signal Strength Indicator on a GSM Carrier)

qui donne le niveau total de puissance reçue sur une porteuse GSM.


On notera qu'un terminal connaît sa classe de puissance et la puissance qu'il utilise en émission. Ce dernier paramètre (UE TX Power) n'est pas vraiment une mesure mais il est considéré comme tel par les recommandations.

2.9.2.2. Critères S et R pour la sélection/resélection

Un terminal en veille doit rester à l'écoute du canal de paging pour détecter les appels éventuels. Il doit se positionner sur la station de base qu'il reçoit avec la meilleure qualité et doit vérifier que cette dernière peut lui fournir une qualité de service suffisante. La norme définit plusieurs critères qui permettent au mobile de sélectionner la station de base sur laquelle il se positionne :

- le critère S (pour Selection) permet de vérifier que la station de base est correctement reçue ;

- le critère R (pour Rankirig) permet de classer les stations de base et de choisir la « meilleure » station de base parmi les stations de base vérifiant S.

Le critère S est en fait un critère double. Il est vérifié si deux variables sont positives [25.304] :

Srxlevl > 0 et SqUal > 0

Le critère Srxtevi permet de vérifier que le bilan de liaison est correct, c'est-à-dire que l'atténuation n'est pas trop importante pour permettre une réception correcte du mobile (voie descendante) et de la station de base (voie montante). Il s'exprime comme suit, avec toutes les grandeurs exprimés en échelle logarithmique (dBm pour les puissances, dB pour les atténuations) :

Srxlevl — Qrxlevmeas ~ Qrxlevmin ~ Pcompensation

Dans cette formule, Qrxievmeas désigne le niveau de signal reçu sur le canal pilote (CPICH RSCP), Qrxievmin désigne le niveau minimal exigé par l'opérateur et diffusé sur le canal BCCH, PCOmpemation désigne le déficit éventuel de puissance du terminal défini comme P compensation = msix(Pcenuie - P mobile, 0) où Pceiiuie est le niveau standard de puissance indiquée sur le BCCH et Pmobiie est la puissance maximale du terminal. La différence Qrxlevmeas ~ Qrxlevmin indique la marge en réception. Si le terminal est moins puissant de P compensation dB que la puissance à utiliser dans la cellule, il faut que la marge soit supérieure de cette valeur pour assurer un bon bilan de la liaison montante. Cela suppose bien évidemment que l'opérateur a bien équilibré sa liaison à la station de base (voir [LAG 00] et [TAB 02]). La formulation du Srx/evi est identique au critère Cl de GSM (voir le paragraphe 10.1.4 de [LGT 00]).


Le critère Squai permet d'exprimer des exigences de qualité. Il est défini comme suit (toutes les grandeurs sont en dB) :

S rxlevl — Qqualmeas ~~ Qqualmin

Dans cette formule, Qquaimeas désigne 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 critère permet d'éviter à un mobile de se caler sur une station de base dont le niveau de signal serait bon mais qui serait très fortement interférée et en conséquence incapable d'offrir une qualité de service satisfaisante. Ce critère n'a pas vraiment d'équivalent dans GSM (on vérifie seulement que le taux d'erreur n'est pas trop important sur la voie balise).

En général, pour un mobile donné, plusieurs cellules vérifient le critère S. Le mobile utilise le critère R pour les classer et choisit la cellule qui a le plus fort R. Le mobile étant a priori calé sur une cellule courante désignée par l'indice s, le critère R s'écrit pour cette cellule :

R.s Qmeas.s Qhyst.s

La variable Qmeas,s désigne soit le niveau de signal sur le canal pilote (CPICH RSCP), soit la mesure du Ec/NO sur ce même canal (CPICH Ec/NO) selon les indications données sur le BCCH. Le paramètre Qhyst,s, diffusé sur le BCCH, permet de favoriser la cellule courante et évite des resélections trop fréquentes ; il crée donc un phénomène d'hystérésis.

Pour une cellule voisine d'indice n, le critère R est défini comme suit :

R„ = Qm - Qoffsets n - TEMP_OFFSETn. W{PENALTY_TIMEn - Tn)

où W est la fonction créneau 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 détectée avec un niveau suffisant. La variable mesurée Qmeas est définie comme pour la cellule courante. Le paramètre QoffsetSi„ permet de favoriser ou de pénaliser une cellule voisine par rapport à la cellule courante (par exemple on défavorise une cellule voisine si elle fait partie d'une zone de localisation différente). La valeur TEMP_OFFSETn permet de défavoriser une nouvelle cellule pendant les premiers instants où celle-ci est détectée. Cela permet d'éviter qu'un mobile à forte vitesse ne vienne se positionner sur une micro-cellule. Ce mécanisme adapté aux réseaux hiérarchiques qui combinent micro et macro-cellules est également présent dans GSM (voir explications détaillées dans le paragraphe 10.1.4.2 de [LGT 00]).


Lorsque le mobile est très 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 déterminer le critère R. En effet, ces mécanismes sont consommateurs d'énergie. Pour minimiser la consommation des terminaux, les recommandations prévoient 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. Accès (sur PRACH)

Lorsque les mobiles sont en veille, ils accèdent au réseau par l'intermédiaire du canal d'accès aléatoire 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 même temps. Ces mobiles peuvent être à des distances différentes de la station de base. S'ils transmettent à la même puissance, le plus proche est reçu par la station de base avec une puissance très importante et brouille toutes les autres transmissions. II est donc nécessaire de trouver un mécanisme pour rendre égales au maximum les probabilités de succès. De plus, la transmission se fait à la même fréquence que les autres transmissions de la cellule, telles que les canaux dédiés. Il faut éviter d'utiliser une puissance trop importante pour l'accès aléatoire qui brouillerait l'ensemble des transmissions des autres mobiles.

L'accès aléatoire repose sur les principes suivants : -choix d'un préambule court parmi 16 possibles, ce qui permet éventuellement

à la station de base de détecter correctement des préambules différents émis simultanément ;

-transmission initiale du préambule à faible puissance pour minimiser l'interférence sur les transmissions des autres mobiles de la cellule (interférence intracellulaire) ;

-répétition du préambule avec une augmentation progressive de la puissance jusqu'à la détection par la station de base ;

-transmission du message avec la puissance optimale sur une durée de 1 ou 2 trames de 10 ms.

Le terminal choisit aléatoirement un préambule parmi les 16 possibles (voir paragraphe 2.3.2). A partir des mesures faites et de la boucle ouverte de contrôle de puissance, il détermine une puissance initiale pour le préambule. Il transmet celui-ci puis écoute sur la voie descendante le canal AICH, Acquisition Indicator. Il regarde si son préambule a été correctement reçu ou non. Si ce n'est pas le cas, le mobile retransmet le préambule en augmentant à chaque fois sa puissance d'émission


jusqu'à ce que la station de base indique qu'elle reçoit le préambule. Lorsque c'est le cas, le mobile transmet alors le message d'accès en utilisant le PRACH. Suivant le code d'étalement utilisé et la durée de transmission, celui-ci peut faire de 9 à 150 octets utiles.

Le canal AICH est présent sur tous les slots mais il n'est représenté que pendant les slots d'accès que le mobile écoute. Le rectangle grisé pour l'AICH représente une indication positive de réception du préambule.

Figure 2.32. Principe général de transmission sur le RACH

Les différents préambules disponibles permettent de minimiser les risques de collisions [25.213]. Si deux mobiles accèdent simultanément au PRACH mais avec des préambules différents et s'ils sont reçus par la station de base avec des puissances voisines, cette dernière pourra différencier les demandes d'accès et les détecter correctement. Grâce à la définition de slots, l'accès est de type Aloha synchronisé (Slotted Aloha) dont l'efficacité est supérieure à l'Aloha simple. Le principe de slots d'accès permettent également de définir différentes classes de mobiles : certains mobiles se voient autorisés plus de slots d'accès que d'autres et deviennent ainsi prioritaires.

Le lecteur peut remarquer que le préambule est plus court que le slot d'accès : 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 conséquent les délais de propagation sont variables. L'intervalle de garde permet d'éviter une collision entre deux transmissions normalement sur des slots différents (voir figure 2.33). Un intervalle de garde de 266,67 ps permet d'envisager des portées maximales de


40 km sans collision. Le mécanisme peut fonctionner pour des distances supérieures mais l'efficacité est notablement réduite car on se rapproche alors de l'Aloha simple.

slot d'accès 1333,33 us 266,67 (as

0km±

Préambule Mobile 2

Figure 2.33. Impact du délai de propagation dans l'accès aléatoire

2.9.4. Gestion du handover

Deux types de handovers sont définis dans la norme 3GPP [25.922] : le hard handover [25.303] et le soft handover. Par définition, un soft handover comprend une phase où le mobile est connecté à deux stations de base simultanément ou plus ; cette phase est appelée « 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 même porteuse. Le hard handover comprend une phase, éventuellement très 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 système, par exemple GSM.

La décision de transfert d'un mobile d'une cellule à l'autre est prise par le réseau ; le handover n'existe donc que dans l'état RRC CELLDCH où un canal dédié est alloué au mobile et éventuellement dans l'état CELL FACH où le mobile qui travaille en mode paquet peut se mettre sous le contrôle du réseau (voir chapitre 6). Dans tous les autres cas, c'est le processus de sélection/resélection de cellule géré par le mobile qui rentre en œuvre (voir paragraphe 2.6.2).

Dans ce chapitre, nous nous focalisons sur les aspects du handover liés à la couche physique. L'exécution du handover est présentée dans le chapitre 6.

2.9.4.1. Processus de mesures

C'est le RNC qui contrôle le processus de mesures. Il définit les mesures que le mobile doit faire, notamment s'il est nécessaire de faire des mesures inter-fréquences et inter-système (pour permettre par exemple un handover

_


UTRAN->GSM). La principale quantité mesurée est le rapport Ec/NO sur les canaux pilotes des cellules courantes et des cellules voisines.

Le nœud 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. Remontée des mesures

Le mobile effectue les mesures et les remonte vers le réseau. La remontée des mesures peut être périodique comme en GSM mais avec une période paramétrable de 250 ms à 64 secondes. Il est cependant possible de définir une remontée des mesures conditionnée par un critère de déclenchement : on parle de remontée sur événement. Les recommandations proposent un grand nombre d'événements : 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. Déclenchement du handover

Le RNC décide du handover sur la base des mesures du terminal. La réalisation du mécanisme de macrodiversité nécessite la gestion deux ensembles de cellules qui sont gérés au niveau du mobile [25.331 ] :

- j e u des cellules actives ou active set : cellules impliquées dans une situation de soft handover (toutes les cellules de cet ensemble sont connectées 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 déclenchement du handover

Les recommandations 3GPP proposent un algorithme de handover [25.922]. Le principe des premiers algorithmes de soft-handover développés pour IS-95 consistait à intégrer dans les cellules actives toute cellule dont le pilote était reçu au-dessus d'un certain seuil. Si le seuil est haut, les communications sont coupées pour les mobiles en bordure de cellules ou à l'intérieur d'un bâtiment car aucune cellule ne peut rentrer dans Y active set. Si le seuil est bas, les mobiles qui reçoivent plusieurs stations de base avec un fort niveau (car ils sont par exemple en extérieur) sont connectés à de multiples stations de base. La conséquence est qu'il y a une forte proportion de mobiles en soft-handover.

Le principe de l'algorithme proposé par le 3GPP réside dans la définition de seuils variables : l'ajout d'un pilote se fait par comparaison au meilleur pilote du jeu


courant, le retrait d'un pilote se fait par comparaison au pire ou au meilleur pilote. Un jeu comporte un nombre maximal de pilotes possibles.

Les paramètres de l'algorithme proposé sont :

- valeur de seuil et des différents hystérésis ; - nombre maximal de pilotes actifs ; - constante de temps avant de modifier le jeu des pilotes actifs.

L'algorithme s'énonce comme suit pour une fréquence et pendant au moins AT :

- si EJÏ0 (pilote candidat) > EJI0 (meilleur pilote du jeu) - Seuil + Hystérésisl 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 - Hystérésisl 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) + Hystérésis 1C et le jeu est plein, alors on sort le pilote le pire et on intègre le meilleur candidat.

La figure 2.34 représente un exemple de déroulement de handover avec 3 cellules et indique les cellules présentes dans Y active set.

Figure 2.34. Exemple de déroulement d'un soft handover [25.922]

2.9.4.5. Autres cas de handover

Pour assurer une continuité de service, il est nécessaire de permettre le transfert des mobiles d'un réseau UMTS vers des zones UMTS utilisant d'autres bandes de


fréquences, une autre norme (TDD) ou encore vers d'autres systèmes à couverture plus étendue tels que le GSM. Ainsi les spécifications UMTS définissent le hard handover qui peut se produire lorsque le mobile doit changer de cellule en changeant :

- de fréquence (FDD inter-frequency hard handover) ; - de mode (FDD-TDD handover ou TDD-FDD handover) ; - de système (3G - 2G handover ou 2G - 3G handover).

Ces différents mécanismes définis pour assurer la continuité du service entre différents systèmes radio ou modes d'accès radio permettent ainsi de prendre en compte les scénarios de couverture suivants :

- couverture limitée dans une couverture étendue fournie par d'autres systèmes radio différents ou de modes d'accès radio différents ;

-opération de sélection à la frontière géographique du système, en cas de couverture UTRAN étendue d'un côté et d'une couverture étendue d'un autre système de l'autre côté ;

-zones de couvertures géographiques colocalisées UTRAN et d'un autre système radio.

Nous présentons dans ce paragraphe les principes sur lesquels sont basés ces différents types de handover.

2.9.4.5.1. Mode compressé

Afin de permettre le transfert entre cellules utilisant des bandes de fréquences UMTS différentes, le mode compressé a été défini (voir figure 2.35). Il permet au terminal de réaliser des mesures sur les autres porteuses tout en communicant sur les porteuses UTRA-FDD et inversement. Le mode compressé permet de créer des intervalles de temps libres pendant la communication de sorte que le mobile puisse réaliser ses mesures sur les porteuses des réseaux candidats au handover. Pour maintenir le débit de transmission constant au niveau de l'utilisateur, le débit binaire doit être augmenté juste avant et juste après l'intervalle de temps tel que la voix mais pas dans le cas de la navigation Web par exemple, où la transmission sera retardée pour libérer un intervalle de temps. Suite à une commande du réseau, le terminal doit mesurer les cellules d'autres fréquences du système FDD ou TDD ou d'autres technologies d'accès radio supportées par le terminal (par exemple GSM). Pour permettre au terminal de réaliser ces mesures, le réseau demande au mobile d'entrer en mode compressé. Les fonctionnalités du terminal indiquent sa capacité à réaliser des mesures sur d'autres cellules utilisant d'autres fréquences et d'autres systèmes.


Débit 2* R

Débit R

w <e

Trame radio Intervalle de temps libéré pour les mesures sur des fréquences différentes

Figure 2.35. Principe du mode compressé

2.9.4.5.2. Handover inter-fréquence

Le handover inter-fréquence se produit quand le mobile passe d'une zone couverte par des cellule de même norme mais utilisant des fréquences différentes (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'accès radio différents (RAM, Radio Access Mode). Dans le cas où le mobile se trouve dans une zone couverte par un réseau UMTS fonctionnant en mode TDD, et à condition que le mobile soit bi-mode (FDD-TDD), il pourra, à la demande du réseau, réaliser des mesures de niveau de puissance sur les cellules TDD. Ainsi, grâce aux mesures de puissance des bursts émis sur le canal TDD CCPCH (deux fois par trame TDD de 10 ms), l'UTRAN pourra décider de la cellule cible et du moment du handover.

2.9.4.5.4 Handover inter-système

Le handover inter-système se produit entre deux cellules de technologies d'accès radio différentes (RAT, Radio Access Technology). Le cas le plus fréquent envisagé est le handover entre UTRA-FDD et GSM/EDGE. Dans ce cas, le mobile pourra, sur demande du réseau, réaliser des mesures sur les canaux communs GSM (et en particulier les canaux FCCH, Frequency Correction Control Channel, et SCH, Synchronisation Channel) pendant les périodes libérées par activation du mode compressé. Ce sont les couches hautes (réseau 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 paramètres à utiliser pour réaliser ces mesures. Le mobile doit dans ce cas réaliser des mesures de façon à remonter ses


rapports de mesures toutes les 480 ms dans le cas du GSM (ces rapports comportent les identités des cellules BSIC par exemple).

Dans le cas d'un handover de GSM vers l'UMTS, les paramètres suivants sont mesurés : 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 reçue RXLEV_NCELL(/7) pour chaque voie balise GSM n figurant dans la liste monitoring set.

UTRA-FDD et GSM étant des technologies très différentes, il est difficile de comparer les résultats de mesures obtenues sur chaque type de système. Pour contourner ce problème, les résultats de mesures sont comparés séparément à des seuils relatifs à chaque technologies. Ainsi, des critères séparés sont définis pour chaque système et des paramètres supplémentaires (tels que des offsets) ajustables par l'opérateur sont définis pour permettre un contrôle de sélection entre les cellules UTRA-FDD et GSM. Il faut également inclure les résultats de mesures réalisées sur les porteuses d'un système dans les messages d'un système différent (mesures sur les porteuses GSM remontées sur des messages UMTS par exemple).

2.10. Transmission de données à haut débit (HSDPA)

Dans les premières spécifications fonctionnelles de l'UMTS (établies dans les années 90-95), il était prévu d'offrir un débit de 2 Mbit/s à un usager. Dans la pratique, le débit le plus élevé est 384 bit/s. Avec un débit de transmission de 3,84 Mchip/s, offrir 2 Mbit/s à un utilisateur nécessite de dédier toutes les ressources à ce dernier et empêche, en pratique, tout autre transmission. Pour lever cette limitation de la première phase d'UTRA-TDD, une nouvelle technique de transmission appelée HSDPA (High Speed Downlink Packet Access) a été spécifiée à partir de la Release 5. Elle est basée sur l'utilisation d'une modulation plus sophistiquée permettant d'augmenter le débit de transmission.

Pour augmenter le débit au niveau applicatif, il ne faut pas se contenter d'augmenter le débit sur l'interface radio mais il faut également réduire le délai de transmission. Beaucoup d'applications utilisent en effet le protocole TCP (Transmission Control Protocol). Celui-ci dispose d'un mécanisme complexe de fenêtre d'anticipation qui a pour effet de réduire le débit lorsque les délais sont importants. Les mécanismes de retransmission RLC sont localisés dans le RNC (voir chapitre 6) dans l'architecture de base de l'UMTS. Les blocs de données et d'acquittement doivent donc « traverser » l'interface radio et l'interface Iub, ce qui


occasionne un délai supplémentaire. La philosophie d'HSDPA est donc de transférer plusieurs fonctions du RNC vers le nœud B. Plus précisément, on a les principales évolutions suivantes :

-nouveau canal descendant HS-DSCH (High-Speed Downlink Channel) haut débit ;

- gestion par le nœud B d'un codage et d'une modulation adaptatifs (.Adaptive Modulation and Coding, AMC) sans contrôle de puissance ;

- gestion du séquencement des paquets (packet scheduling, PS) par le nœud B ; - technique de retransmission de type ARQ hybride.

Les caractéristiques détaillées de chacune de ces modifications sont introduites ci-après.

2.10.1. Canaux logiques et physiques pour le support du HSDPA

HSPDA introduit une évolution du DSCH [5, 6] avec la définition 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 connectés au nœud 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 nœud B pour la gestion de la technique AMC.

Outre le canal HS-DSCH utilisé pour le transport haut débit 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 fixés par le réseau.

Le tableau de la figure 2.36 reprend les principales différences entre les canaux DSCH et HS-DSCH. Nous précisons dans la suite de ce paragraphe le fonctionnement des différents mécanismes sur lesquels se base le support HS-DSCH.


Fonction DSCH HS-DSCH Facteur d'étalement variable (VSF) Oui (4-256) Non (16)

Contrôle de puissance rapide Oui Non Codage et modulation adaptative (AMC) Non Oui

ARQ rapide (HARQ) Non Oui Multi-code Oui Oui

Intervalle de transmission 10 ou 20 ms 2 ms Emplacement des fonctions MAC RNC Nœud B

Figure 2.36. Principales caractéristiques 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é désactivées dans le HS-DSCH : facteur d'étalement variable et contrôle de puissance rapide. Elles ont été remplacées par un codage et une modulation adaptative (AMC). Bien que conduisant à une efficacité spectrale plus faible, la désactivation du contrôle de puissance permet de s'affranchir des en-têtes liées à ce mécanisme mais nécessite une adaptation aux conditions de propagation (ce qui est fait grâce au codage et à la modulation adaptative). Ainsi, quand les conditions de propagation sont favorables, les débits atteints peuvent être très élevés. D'autre part, la technique AMC permet à l'UE de déterminer la meilleure modulation et le meilleur schéma de codage dans des conditions de propagation données, et ce afin de maximiser le débit de transmission. L'adaptation se fait à chaque TTI (Transmit Time Interval). Pour améliorer la rapidité d'adaptation de lien et l'efficacité de l'AMC, la durée d'entrelacement de 10 ou 20 ms a été réduite à 2 ms. De plus, si on gardait un TTI de 10 ms, un débit de 2 Mbit/s conduirait à un bloc de transport de 2 500 octets qui est une taille supérieure à un paquet IP typique ; il faudrait alors attendre plusieurs paquets pour remplir un bloc et on augmenterait ainsi le délai de transmission moyen d'un paquet IP.

Pour atteindre ces hauts débits, le HSDPA introduit la modulation 16QAM, qui s'ajoute au schéma 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 négatifs (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 dénomination 16QAM. Cela permet de transmettre 4 bits par symbole au lieu de 2 en QPSK.


Figure 2.37. Constellation de la modulation 16 QAM

La combinaison de la modulation 16QAM et d'un taux de codage % permet de cette façon d'obtenir des débits pics de 712 kbit/s par code (avec un facteur d'étalement SF = 16). Une meilleure robustesse est obtenue avec le schéma de modulation QPSK et un taux de codage VA (au lieu de %) mais le débit chute alors à 119 kbit/s par code. Cinq types de combinaison du codage et de la modulation (appelées TFRC, Transport Format and Resource Combination) sont définis pour le canal HS-DSCH. Dans de bonnes conditions de propagation radio, un utilisateur peut recevoir jusqu'à 15 codes en parallèle, ce qui permet d'atteindre des débits maximaux de 10,8 Mbit/s, débit maximal supporté en HSDPA (voir figure 2.38).

TFRC Modulation Taux de codage Débit binaire Débit binaire Débit binaire (1 code) (5 codes) (15 codes)

1 QPSK % 119 kbit/s 0,6 Mbit/s 1,8 Mbit/s 2 QPSK '/2 237 kbit/s 1,2 Mbit/s 3,6 Mbit/s 3 QPSK 3/4 356 kbit/s 1,8 Mbit/s 5,3 Mbit/s 4 16 QAM Vi 477 kbit/s 2,4 Mbit/s 7,2 Mbit/s 5 16yQAM VA 712 kbit/s 3,6 Mbit/s 10,8 Mbit/s

Figure 2.38. Exemple de combinaison de formats de transport et de ressources correspondant aux débits maximum au niveau 1

La mise en œuvre de l'AMC est la suivante : le nœud B supervise la qualité du lien radio descendant en mesurant la puissance émise sur le lien DCH associé descendant. Le mobile transmet régulièrement des indicateurs de qualité (CQ1) sur le canal montant HS-DPCCH. Le CQI contient le TFRC et le numéro de multi-code que peut supporter le mobile.


2.10.3. Technique HARQ

UHybrid ARQ (HARQ) mise en œuvre permet de minimiser la quantité d'information retransmise grâce aux deux techniques suivantes combinées à l'ARQ : le chase combining (CC) et Y incrémental redundancy (IR).

Dans la technique CC, lorsque l'UE reçoit un paquet contenant des erreurs, elle le garde en mémoire et demande au nœud B de le retransmettre. Dans le cas où le paquet retransmis contient également des erreurs, les deux paquets sont combinés en les pondérant par le rapport signal à bruit avant décodage.

Avec la technique IR, le paquet retransmis utilisera un codage plus robuste que le paquet précédent afin d'augmenter la probabilité de bonne réception. Ainsi, lors de la retransmission, seule une partie de l'information est renvoyée de façon à compléter les informations déjà reçues par combinaison (CC).

La méthode d'ARQ de base utilisée dans HARQ est de type Stop-and-Wait. Pour réduire les délais d'attente des acquittements, N processus Stop-and-Wait en parallèle peuvent être activés, permettant ainsi aux différents processus de transmettre dans des TTI différents. La valeur de N peut être au maximum de 8. En pratique, le délai entre la première émission et la première retransmission devrait être de l'ordre de 8 à 12 ms. Le contrôle du mécanisme d'ARQ est géré par la couche MAC. Ainsi, le stockage des blocs non acquittés et l'organisation de la transmission des retransmissions suivantes n'impliquent pas le RNC. La signalisation Iub est évitée et le délai 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 mécanisme 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 nœud B, le BLER sera de 10 à 20 % à la première émission.

2.10.4. Fast cell site selection (FCSS)

Quand le mobile se déplace dans le réseau, il établit Y active set pour la gestion du soft handover. Dans le mécanisme FCSS, le mobile utilise Y active set et sélectionne la cellule pour laquelle les conditions de propagation sont les meilleures. Grâce à ce processus, des débits plus importants peuvent être atteints par utilisation du meilleur nœud B à chaque transmission.


2.10.5. Séquencement des paquets

En HSDPA, le nœud B est chargé de deux nouvelles fonctionnalités : le packet scheduling (PS), ou séquencement des paquets permettant de réduire les délais 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 nœud B séquence les paquets à transmettre vers les usagers sur le HS-DSCH. Ainsi, deux utilisateurs peuvent être multiplexés en temps et/ou en code pour utiliser de façon plus efficace les ressources disponibles (les UE doivent être capables de gérer plusieurs classes). Avant de transmettre les données sur le HS-DSCH, le nœud 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 contrôle du processus ARQ. Il est transmis deux slots avant le HS-DSCH.

2.10.6. Contraintes au niveau du nœud B et des terminaux

Sans HSDPA, les nœuds B sont gérées par le RNC qui assure le séquencement, les paramètres de codage et la retransmission vers les mobiles. Pour le support du HSDPA, ces paramètres doivent être déterminés instantanément en fonction des conditions de transmission radio (évaluées par les mesures remontées par les mobiles). Ainsi, pour que les décisions d'adaptation indiquées plus haut soient réalisées rapidement, il est impératif que ces processus soient exécutés au niveau des nodes B et non des RNC. Les fonctions RLC et MAC sont toujours réalisées par le RNC pour les services non-HSDPA. De la même façon, les handovers doivent être assurés par le RNC pour gérer la perte de données ainsi que la fonction FCSS.

L'introduction du HSDPA nécessite l'introduction de nouveaux types de terminaux. Cinq principaux paramètres sont utilisés pour définir les fonctionnalités de la couche physique du terminal :

-nombre maximal de multi-codes HS-DSCH que le terminal peut recevoir simultanément. Au moins 5 multi-codes doivent pouvoir être supportés pour un fonctionnement multi-code efficace ;

- intervalle inter-TTI minimal (distance entre le début du TTI et le début 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 reçus dans un seul TTI ;

- capacité du terminal à supporter la modulation 16QAM.


2.11. Conclusion

Avant d 'at teindre sa pôle capacity, un système W C D M A peut être limité soit par manque de puissance, soit par manque de codes. L 'un des avantages majeurs du HSDPA est son compromis entre puissance et code pour s 'adapter à l 'état de la cellule. Face au déploiement d 'al ternatives aux réseaux U M T S avec le Wi-Fi, HSDPA permet à l ' U M T S d 'o f f r i r des débits similaires avec une meilleure couverture géographique ainsi qu 'un niveau de sécurité plus important.

2.12. Références

[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 Spécification; 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 Spécification Group Radio Access Network; Physical layer procédure (FDD) », Release 5, 2002.

[25.215] 3GPP TS 25. 215, « Physical layer; Measurements (FDD) ».

[25.303] 3GPP TS 25.303, « Interlayer procédures in Connected Mode »

[25.304] 3GPP TS 25.304, « UE Procédures in Idle Mode and Procédures for Cell Reselection in Connected Mode ».

[25.308] 3GPP TS 25.308, « Technical Spécification; High Speed Downlink Packet Access (HSPDA), Overall Description; Stage 2 ».

[25.321] 3GPP TS 25.321, «Technical Spécification; Physical Channels and Mapping of Transport Channels onto Physical Channels (FDD) ».

[25.331] 3GPP TS 25.331, « Technical Spécification, RRC Protocol Spécification ».

[25.855] 3G TS 25.855, « Technical Spécification; High Speed Downlink Packet Access: Overall UTRAN Description ».

[25.922] 3GPP TR 25.922, «Technical Spécification; Radio Resource Management Stratégies ».

[LAG 00] LAGRANGE X (coordinateur), Les réseaux radiomobiles, collection IC2, Hermès Science, 2000.

L' interface radio UTRA-FDD 103

[ L G T 0 0 ] LAGRANGE X , GODLEWSKI P , TABBANE S, Réseaux GSM, Hermès Science, 2 0 0 0 .

[ P R O 0 1 ] PROAKIS J . G.,Digital Communications, M E Graw Hill, 2 0 0 1 .

[TAB 02] Sami Tabbane, Ingénierie des réseaux cellulaires, Hermès 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 déployé et le plus répandu. Cependant le mode UTRA-TDD (Universal Terres trial Radio Access with Time Division Duplex), de par la spécificité du duplexage, est considéré avec intérêt. Dans ce chapitre, nous décrivons les principes fondamentaux de l'UTRA-TDD et justifions sur un plan théorique l'avantage qu'il procure en termes de capacité. Nous introduisons les principaux éléments de la couche physique et étudions en détail les techniques spécifiques au mode TDD que sont l'estimation de canal multi-utilisateurs et la détection conjointe. Sont également abordées les spécificités du mode TDD quant à l'allocation de ressources et à la synchronisation du réseau.

Les couches supérieures étant communes à l'UTRA-TDD et à l'UTRA-FDD, elles ne sont pas traitées dans ce chapitre et on peut se référer 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 même bande de fréquence entre les ressources de la voie montante (Uplink) et celles de la voie descendante (.Downlink) et associent à l'accès multiple en partage de code (CDMA, Code Division Multiple Access) une composante de partage en temps (TDMA, Time Division Multiple Access).

Chapitre rédigé par Bruno JECHOUX.


Chaque porteuse est partagée en un nombre fixe d'intervalles de temps (IT) ou Time Slots qui sont répartis, symétriquement ou non, de manière flexible, entre voie montante et voie descendante. Plusieurs transmissions sont possibles simultanément sur le même intervalle de temps grâce au CDMA : les codes d'étalement utilisés 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 fréquence donnée.

Figure 3.1. Accès multiple en TDD et FDD

On peut noter les particularités suivantes pour le mode TDD de l'UMTS :

- le facteur d'étalement (SF, Spreading Factor) est limité à 16 ;

- ju squ ' à 16 codes peuvent simultanément être utilisés dans un même IT par un ou plusieurs utilisateurs (dans un cas favorable en terme d'interférence, en réalité moins, jusqu'à 10 ou 12) ;

- les codes de scrambling sont caractéristiques de la cellule et ont une longueur 16 ; - la trame radio a une durée de 10 ms ; - e n voie descendante, l'obtention des hauts débits est faite par empilage de

codes (multicode avec SF = 16) ;

Le mode UTRA-TDD et ses performances 107

- en voie montante, elle se fait par une combinaison de multicode et de facteur d'étalement variable (2 codes par utilisateur au maximum et des facteurs d'étalement variant entre 1 et 16).

Ces caractéristiques peuvent se justifier par l'étude des problèmes classiques des communications cellulaires en CDMA que sont l'effet Proche-Loin (Near Far Effect) et l'interférence extra cellulaire ([PET 95]).

3.1.1. Effet proche-loin

L'effet proche-loin se produit en voie montante lorsque les signaux de différents mobiles sont reçus simultanément au niveau de la station de base. Les mobiles pouvant se trouver à des distances différentes de la BTS, les puissances reçues sont alors différentes. Dans le cas où les signaux ne sont pas strictement orthogonaux, le signal le plus fort peut dégrader 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 différents signaux d'une même cellule sont synchronisés et orthogonaux. Le canal de propagation radio à trajet multiples et les imperfections de synchronisation brisent cette orthogonalité qui n'existe donc plus à la réception, mais l'emploi d'un récepteur à détection conjointe (algorithme de détection multi-utilisateur linéaire) permet de la restaurer1. Par conséquent l'interférence proche-loin est fortement

1. La complexité de mise en œuvre de la détection conjointe impose d'utiliser des codes courts (limités par conséquent à 16).


réduite de telle manière que les puissances reçues pour les différents liens peuvent être très différentes sans conséquences notables.

En FDD, où les codes sont longs et non orthogonaux (voie montante) l'interférence proche loin est combattue par un contrôle de puissance rapide qui permet à la station de base de recevoir la même puissance pour chacun des liens, indépendamment de la distance de propagation. L'interférence est alors minimisée et identique pour chacun des liens.

3.1.2. Capacités du canal en UTRA-TDD et en UTRA-FDD

Il est possible en utilisant la formule de Shannon [SHA 48] de comparer les capacités du canal d'un système UTRA-TDD et d'un système UTRA-FDD. On considère un système CDMA avec K utilisateurs en voie montante transmettant un signal dans une bande de fréquence de largeur W où la densité spectrale de bruit AWGN est N0/2 et la densité d'interférence 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 système utilisant des codes d'étalement orthogonaux (cas UMTS-TDD), l'interférence est annulée et la capacité de l'utilisateur devient :

W log, 1 + N0fVj

[3.2]

qui est égale à la capacité théorique du cas mono utilisateur. Cependant dans un système réel, l'orthogonalité restaurée des codes à la réception est imparfaite et il reste une interférence résiduelle ( l - a ) / 0 , où a est la portion d'interférence supprimée, comprise entre 0 et 1.

C = W\ og, 1 + ( A r 0 + ( l - a ) / 0 ) r

[3.3]

On considère maintenant la voie montante d'un système UMTS FDD. Les codes d'étalement PN {Pseudo Noise) ne sont pas orthogonaux et un contrôle de puissance est mis en œuvre : les signaux des différents utilisateurs sont reçus avec la même


puissance moyenne S (correspondant à une puissance moyenne par symbole Ssymb étalée sur L chips) à la station de base. La capacité d'un utilisateur est :

C = W log2 1 + TVo^ + ^ - l ) ^

= W log2

Ssymb

1 +

N0W + (K-1) SSvmb

.[3.4]

L'utilisation de codes longs permet de réduire l'interférence jusqu'à faire tendre asymptotiquement la capacité vers :

C = W\ og2 1 + NQW

[3.5]

lorsque l'interférence devient négligeable devant la puissance de bruit (c'est-à-dire quand (K- 1 )/L « NQW/SSymb).

Les équations [3.2] et [3.5] sont les mêmes, ce qui semble montrer que les capacités des systèmes qui emploient des codes orthogonaux et de ceux basés sur les codes pseudo-aléatoires sont équivalentes. Cependant, dans un système réel, la longueur L des codes d'étalement est limitée et le nombre K de mobiles en communication est grand, on ne se trouve donc en général pas dans le cas où l'interférence est négligeable. De plus, le contrôle de puissance ne peut égaliser parfaitement les puissances reçues des différents utilisateurs, ce qui contribue également à dégrader la capacité.

Ces considérations de capacité supposent implicitement que les interférences sont gaussiennes, il s'agit d'une approximation beaucoup plus proche de la réalité dans le cas de codes PN longs que de codes orthogonaux courts.

L'utilisation soit de codes orthogonaux courts couplés avec un récepteur à détection conjointe, soit de codes pseudo aléatoires longs avec un contrôle de puissance parfait et un récepteur mono utilisateur permet en théorie d'atteindre la capacité du canal mono utilisateur.

Cependant, dans la réalité, la capacité obtenue par ces 2 approches est limitée respectivement par la restauration imparfaite de l'orthogonalité des codes et par l'interférence résiduelle (dépendant du nombres de communications parallèles) couplée aux imperfections du contrôle de puissance.


3.1.3. Gestion de r interférence extra-cellulaire

L'interférence extra-cellulaire est plus forte aux limites de la cellule. En effet quand un mobile est proche de la frontière de la cellule, il reçoit une interférence forte des signaux venant des cellules voisines, et lui-même interfère fortement avec celles-ci (que ce soit avec les stations de base ou avec les mobiles).

Figure 3.3. Interférences extra-cellulaire en bordure de cellule

En TDD, cette interférence est combattue par l'utilisation d'un code d'embrouillage caractéristique de la cellule et par un mécanisme 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 mécanisme d'allocation de canal doit être rapide (Fast DCA) ; il est basé sur des mesures d'interférence sur chaque IT, permettant ensuite de décider des réallocations des signaux fortement interférés dans d'autres IT moins interférés.

3.1.4. Facteur dyétalement variable et multicode

En TDD, deux techniques sont a priori disponibles pour l'obtention de débits importants, le multicode et la variation du facteur d'étalement (codes OVSF). L'utilisation de facteurs d'étalement variables augmente la complexité du récepteur par rapport au multicode qui impose par contre des contraintes supérieures sur les amplificateurs de puissances utilisés pour la transmission.


En effet dans le cas d'une transmission en multicode, le signal a une forte dynamique avec un rapport puissance crête/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 linéaires de l'AHP produisent des intermodulations entre les différents codes qui constituent des interférences supplémentaires dans le système causant une augmentation du TEB.

Pour limiter ces interférences, il faut forcer l'AHP à fonctionner en zone linéaire en augmentant la marge (back-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 très pénalisant pour l'autonomie des batteries de mobiles.

Pour tenir compte à la fois des contraintes de complexité du récepteur et de linéarité 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. Pénurie de codes orthogonaux

La longueur maximale des codes d'étalement et de scrambling est limitée à 16 chips pour permettre la détection 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 système TDD, ce qui est évidemment insuffisant pour supporter le nombre de communications simultanées d'un système commercial. Cette limitation est dépassée par l'introduction d'une composante TDMA sous la forme d'une séparation supplémentaire des utilisateurs sur 15 ou 7 intervalles de temps, le système devenant TD-CDMA, et par l'utilisation de codes de scrambling dédiés à chaque station de base.

3.1.5.2. Interférence voie montante/voie descendante

Le TDD étant basé sur un duplex temporel, les signaux voie montante et voie descendante utilisent la même bande de fréquence et peuvent donc interférer.


Le problème apparaît quand 2 mobiles proches ne sont pas dans le même état, le puissant signal émis par celui qui est en voie montante masque alors le faible signal reçu 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'interférence voie montante/voie descendante peut être limitée par une gestion adaptée de l'allocation des ressources dans les différentes cellules ou évitée, au prix d'une perte de flexibilité du système, en adoptant une répartition des périodes voie montante/voie descendante commune à toutes les cellules.

Figure 3.4. Interférences 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 diffèrent par un certain nombre de caractéristiques de leurs couches physiques ([25.221] à [25.225]).

3.2.1. Caractéristiques d'UTRA-TDD à 3,84 Mchips

Les principales caractéristiques de l'UTRA-TDD sont données dans la deuxième colonne du tableau 3.1.


Paramètres et fonctions Valeur/Expression Valeur/Expression

Bande passante 3,84 Mchips 1,28 Mchips

Modulation QPSK

16QAM (pour HSDPA 2 ) QPSK (8PSK) 16QAM (pour HSDPA)

Séparation des canaux 5,0 MHz/Porteuse 1,6 MHz/Porteuse

Trame TDMA 10ms 10ms (divisé en 2 sous-trames)

Méthode de Duplex TDD

Acès multiple TD-CDMA

IT par trame 15 7 (par sous-trame)

Type de récepteur Détection multi-utilisateur, Rake

Détection multi utilisateur (option), Rake

Synchronisation DL et UL (option) DL et UL

Précision synchro UL ± 4 chips 1/8 chip

Modes d'antennes Diversité de transmission Diversité de transmission, Réseaux d'antennes actives (option)

Contrôle de puissance voie montante (UL)

Boucle ouverte (délai : 667-4 669 ps si 2 SCH par trame, 6 6 7 - 9 3 3 8 ps si 1 SCH)

Boucle fermée : 0-200 Hz/sec. Boucle ouverte: (délai de 200 ps à 3575 ps)

Contrôle de puissance voie descendante(DL)

Boucle fermée (de 100 à 700 Hz)

Boucle ouverte Boucle fermée/200 Hz (maximum)

Codage canal - Turbo codes PCCC 8 états, rendement 1/3 - Codes convolutifs rendement 1/3 ou 1/2 longueur de contrainte 9 - sans codage

Entrelacement sur 1,2,4 ou 8 trames

Estimation de canal Midambules (512 ou 256 chips) Midambules (144 chips)

Codes d'embrouillage longueur 16, caractéristique de la cellule

Codes d'étalement Orthogonaux (OVSF)

Allocation de canaux Dynamique (DCA)

Facteur d'étalement (SF) 1 , 2 , 4 , 8 , 1 6

Handover Hard handover

Adaptation débit UL 1 ou 2 codes (SF = 1 , 2 , 4, 8 ou 16)

Adaptation débit DL codes multiples (SF = 1 ou 16)

Répartition UL/DL Flexible Flexible (à long terme)

Réseau Synchronisé au niveau trame

Ressource physique élémentaire

1 fréquence, 1 code et 1 IT (alloués de manière identique dans les 2 sous-trames pour le mode 1,28 Mchips)

Tableau 3.1. Résumé 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 procédure d'adaptation de la modulation (QPSK ou 16QAM) et du rendement de codage en fonction des conditions de canal.


3.2.2. Canaux physiques

3.2.2.1. Structure de trame

L'interface UTRA-TDD est basée sur une trame de 10 ms, subdivisée 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 réseaux et de balise (P-CCPCH, Primary-Common Control Physical CHannel). De même, au minimum 1 IT par trame doit être alloué à la voie montante pour supporter le canal d'accès aléatoire (PRACH, Physical Random Access Channel).

10 ms

Figure 3.5. Structure de la trame

Les IT sont utilisés pour la transmission de bursts formés de 2 blocs de données encadrant une séquence d'apprentissage (midambule) utilisée pour l'estimation de canal, suivi d'une période de garde (PG) destinée à éviter les interférences entre IT consécutifs.

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'accès multiple. Les midambules 1, 2 et 3 sont des versions décalées cycliquement d'une même séquence de base.


Plusieurs bursts peuvent être transmis dans un même IT, les blocs de données des différents bursts sont alors différenciés par leurs codes d'étalements différents. Suivant les besoins, chaque burst peut contenir un midambule propre3 (typiquement en voie montante où il y a autant de canaux radio à estimer que d'utilisateurs) ou ils peuvent partager le même 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 systématiquement constitués d'un midambule encadré de symboles de données. Il existe 2 types de burst pour le trafic (figure 3.7) suivant la longueur du midambule.

Symboles de données 976 chips

Midambule 512 chips


PG 96

667 ps w


Midambule 256 chips


PG 96

4 667 ps

— •

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 débit de données inférieur au burst de type 2.

Symboles de données Midambule Symboles de données PG 976 chips 512 chips 880 chips 192

4 667 ps

— •

Figure 3.8. Structure du burst PRACH

Le burst PRACH, utilisé uniquement en voie montante pour l'accès aléatoire est identique au burst de type 1 mais avec une période de garde doublée pour tenir compte de la synchronisation imparfaite (voie descendante uniquement) du mobile au moment de son émission.

3. C'est-à-dire une version décalée selon un décalage qui lui est propre du même code de base du midambule.


3.2.2.3. Canal de synchronisation SCH

Le canal de synchronisation est composé de 4 codes de longueur 256 chips émis simultanément avec un retard T0ffSet> choisi parmi 32 valeurs possibles, par rapport au début de l'IT de manière à éviter les phénomènes 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 modulés en phase par rapport au PSC. Le SCH est toujours émis dans le même IT que le canal de diffusion P-CCPCH et peut être transmis 1 ou 2 fois par trame selon la configuration du réseau. Le SCH est transmis avec une longueur d'entrelacement de 2 trames.

Figure 3.9. Structure du burst de synchronisation

La détermination des SSC et de leurs modulations indique le code de groupe (icode group), la position de la trame courante dans la période d'entrelacement et le ou les emplacements du P-CCPCH dans la trame. Le code de groupe définit le jeu de paramètres de la cellule avec une incertitude de 1 parmi 4. Il reste ensuite à déterminer le jeu de paramètres de la cellule parmi les 4 possibles, c'est-à-dire à trouver, par corrélation 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 mêmes principes sont utilisés (synchronisation en 2 phases et indication de codes spécifiques à la cellule sur un canal secondaire) mais avec une implémentation différente.

La cellule utilise deux jeux de paramètres alternés de trame en trame pour moyenner l'interférence inter cellules.

i


3.2.3. Procédures de la couche physique

3.2.3.1. Contrôle de puissance

Le contrôle de puissance a pour but de limiter le niveau d'interférence dans le système. Il est utilisé à la fois en voie montante et en voie descendante mais de façon différente.

En voie descendante, la puissance est pilotée par le mobile : lors de la transmission du premier burst en voie descendante, la puissance de transmission de la station de base est définie par le réseau. Elle est ensuite contrôlée en boucle fermée : à la réception d'un burst en voie descendante, le mobile mesure la puissance reçue et transmet en voie montante une commande d'ajustement de puissance (TPC, Transmit Power Control). Le symbole TPC est transmis au début du deuxième bloc de données du burst (vol de ressource données). Cette commande est ensuite prise en compte par le réseau pour les transmissions suivantes. Le pas d'ajustement de puissance, fixé par le réseau est de ± 1, 2 ou 3 dB (voir chapitre 4).

La fréquence du contrôle de puissance dépend donc de l'allocation des IT ; elle est au minimum de 100 Hz.

En voie montante, le contrôle de puissance fonctionne en boucle ouverte, en exploitant la réciprocité des canaux voie montante et voie descendante caractéristique du mode TDD. Le mobile mesure la puissance reçue sur la voie balise dont la puissance de transmission est diffusée par le réseau, et en déduit la perte de propagation qu'il utilise alors pour calculer sa puissance de transmission uplink selon la formule suivante :

[3.6]

où LPCCPCH désigne la mesure de la perte de propagation sur la voie balise, L0 la valeur moyenne à long terme de cette mesure, IBTS la puissance des interférences au niveau du récepteur de la station de base, a un paramètre de pondération qui représente le niveau de confiance sur la mesure de perte de propagation (par exemple en fonction du retard entre le IT balise le plus récent et l'IT montant), RSBCIBLE le rapport signal/bruit cible fixé par le réseau et C un offset constant fixé par le réseau. Toutes les unités sont exprimés en échelle logarithmique (dBm pour IBTS et dB pour les autres grandeurs) sauf le coefficient a.

Le délai entre mesure et commande est compris entre 1 et 7 IT ou 1 et 14 IT suivant la configuration de la voie balise.


3.2.3.2. Timing Advance

La période de garde en fin de burst de longueur 96 chips permet l'absence d'interférence entre IT consécutifs dans des cellules de rayon inférieur ou égal à 3,75 km. Pour des cellules plus grandes, une fonction d'alignement temporel (TA, Timing Advance) peut être activée de manière à aligner temporellement les bursts au niveau du récepteur de la station de base. Quand cette fonction est activée, l'UTRAN mesure en permanence l'instant de réception 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 près.

3.2.4. Caractéristiques 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 deuxième option de l'UMTS-TDD. Il est conçu pour pouvoir supporter les fonctions de formation de faisceaux rapide (beamforming), le contrôle de puissance en boucle fermée et la synchronisation en voie montante avec une précision inférieure à un chip. Les caractéristiques sont indiquées dans la dernière 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 divisée 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 systématiquement utilisé en voie descendante (TsO en figure 3.10) et le


second en voie montante. Dans chaque trame, il y a 2 transitions voie montante/voie descendante dont la première située entre TsO et Tsl contient les pilotes SYNC-DL et SYNC-UL et la période de garde nécessaires à 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 données, sur lequel sont appliqués un code d'étalement et un code d'embrouillement, qui encadrent une séquence d'apprentissage non étalée, non embrouillée utilisée pour estimer le canal, le tout suivi d'une période de garde de 16 chips.

Le burst DwPTS est émis par le Node B. Il est composé d'une période de garde (PG) de 32 bits et d'une séquence pilote SYNC-DL fixe, non brouillée. Pour couvrir les besoins de tout le système, 32 séquences SYNC-DL différentes sont prévues. Lors de la procédure de synchronisation en voie descendante, un mobile détecte la séquence SYNC-DL transmise dans la cellule et en déduit la position du canal balise (synchronisation trame) et le code de groupe de la cellule. Ce code de groupe permet d'identifier tous les paramètres de la cellules (code d'embrouillage et séquence d'apprentissage dédiés, organisation des canaux communs...).

Figure 3.12. Structure du burst DwPTS

Le burst UpPTS est composé d'une séquence fixe SYNC-UL longue de 128 chips, non brouillée, suivi de 32 chips de période de garde. Il y a 256 séquences SYNC-UL différentes pour permettre la synchronisation en voie montante des mobiles dans tout le système selon la procédure décrite dans le paragraphe suivant.


A •

S YNC-UL( 128chips) PG(32chips)

Figure 3.13. Structure du burst UpPTS

3.2.5. Procédures spécifiques du 1,28 Mchips TDD

Du fait de sa conception permettant le support de la synchronisation en voie montante, le contrôle de puissance rapide en boucle fermée de la voie montante et la formation rapide de faisceaux, la couche physique du mode 1,28 Mchips TDD comprend plusieurs procédures qui soit n'existent pas dans le 3,84 Mchips TDD, soit y sont différentes :

3.2.5.1. Contrôle de puissance

Contrairement à celui du 3,84 Mchips TDD, le contrôle de puissance du 1,28 Mchips TDD peut fonctionner en boucle fermée également en voie montante.

Uplink Downlink

Fréquence du contrôle de puissance

Variable Boucle fermée : 0-200 cycles/sec Boucle ouverte : (délai de 200ps à 3575 ps)

Variable Boucle fermée : 0-200 cycles/sec

Pas d'ajustement 1,2,3 dB (boucle fermée) 1,2,3 dB (boucle fermée)

Tableau 3.2. Caractéristiques du contrôle 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 reçus du réseau (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 réalisée pendant la procédure d'accès aléatoire (RACH) préalable à toute communication. La première transmission du mobile vers le Node B est faite dans un IT UpPTS de manière à minimiser l'interférence dans les IT de trafic. L'instant d'émission est choisi en fonction de la puissance des signaux reçus en voie descendante.


Après la détection de la séquence S Y N C U L dans la fenêtre de recherche, le Node B évalue les instants d'arrivée et retourne dans un délai 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 réalisée en utilisant le midambule de chaque burst de la voie montante. En effet, les midambules des différents UE transmettant dans le même IT étant différents, le Node B peut estimer les instants d'arrivée respectifs des différents UE en évaluant la réponse 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 caractéristiques 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 instantanément l'ensemble de ses faisceaux à la répartition de la charge dans la cellule.

Quand la fonction « formation de faisceaux » est activée, le Node B utilise les données reçues des UE en voie montante pour estimer leurs positions et former ensuite des faisceaux dirigés vers ceux-ci pendant la transmission en voie descendante.

3.3. Estimation de canal multi-utilisateur

3.3.1. Description du problème

Dans un système « classique » FDMA ou TDMA, les différents utilisateurs sont séparés en temps ou en fréquence et l'estimation de canal est généralement réalisée indépendamment pour chacun d'eux grâce à l'émission périodique de séquences d'apprentissage exploitées par un simple corrélateur. Dans le cas de l'UMTS TDD basé sur une structure TD-CDMA, les séquences d'apprentissage des différents utilisateurs à l'intérieur d'un IT sont transmises simultanément et interfèrent entre elles, ce qui rend obsolète l'estimation mono-utilisateur classique. De plus, la connaissance des estimés de canal vu par les autres utilisateurs d'un IT est requise pour appliquer les techniques de détection de données multi-utilisateur telles que la détection conjointe.

Il est donc nécessaire de mettre en œuvre une technique d'estimation de canal multi-utilisateur dont l'objectif est de réduire l'interférence à la réception entre les différentes séquences d'apprentissage et de permettre l'estimation simultanée des


canaux des différents utilisateurs. Cela nécessite un choix judicieux des séquences d'apprentissage couplé à la mise en œuvre d'algorithmes de réduction d'interférence.

Fréquence

Burst (transmis dans un IT)

Figure 3.14. Structure d'un burst UMTS-TDD

3.3.2. Modélisation

Considérons un intervalle de temps où K utilisateurs sont actifs simultanément en voie montante et émettent donc chacun un burst contenant une séquence d'apprentissage ou midambule. La figure 3.15 représente le modèle à temps discret dans lequel le midambule m(A) de chaque utilisateur k est convoluée avec la réponse impulsionnelle de son canal radio spécifique h*, tous les signaux étant ensuite sommés avant d'être altérés de manière identique par le bruit thermique AWGN et les interférences extra-cellulaires.

Figure 3.15. Modèle à temps discret de la communication


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 réponse impulsionnelle de son canal respectif de longueur maximale W chips.

h(k) 2 "W ,k = \àK [3.8]

Seuls L chips sont effectivement utilisés 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 éléments de mu> sont affecté par de l'interférence inter symbole provenant des données du bloc précédant le midambule convoluées par la réponse impulsionnelle du canal de longueur W chips (L doit donc être choisi aussi grand que possible pour garantir un gain de compression suffisant à la réception). Les signaux des différents utilisateurs, s'additionnent avant que ne viennent s'ajouter le bruit et l'interférence extra-cellulaire. On peut donc écrire le signal reçu comme :

K W e = £ £ m<k) *h(k>+n

i k = \ j = \ W + l j i [3.9]

où Hj représente le bruit et l'interférence extra-cellulaire de variance a2 . Cette équation peut s'écrire de manière condensée 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 réponses impulsionnelles de canal de taille U = KW (U étant le nombre de coefficients inconnus à déterminer par la station de base) obtenu en concaténant les

(k) K réponses impulsionnelles de canal h de longueur Mchips :

(i)r , (2 )7 ' (K)T [3.11]


et G est la matrice [L*UJ des codes :

G = [G(1) G(2) ... G (K)]

construite à partir des sous-matrices de taille [LxW\ :

[3.12]

[3.13]

Ces sous-matrices sont elles même construites à partir des éléments du i (k)

midambule du « ème utilisateur m de la manière suivante :

g\j = mw\i-j > P°ur i = ] à L et J =1 à w • [3.14]

Seuls L chips sont effectivement utilisés par la station de base pour estimer les canaux, bien que l'utilisateur émette un midambule m ( A ) de longueur L+W-1 chips. La formule [3.10] est un système de L équations à U inconnues pour lequel au moins une solution exacte existe si U = KW est inférieur ou égal à L.

Exemple : Soit un système avec K = 2 utilisateurs transmettant dans 2 canaux différents de

réponses impulsionnelles o .0) ,h<2) = .(2) .(2) de

longueur W = 2 chips. Ces réponses 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 conséquent 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 génèrent les sous-matrices : , (2 )

«(1)

<> m\

m m

m m'

m\

et G (2) _

m<2)

m

m

m

(2)

(2)

(2)

m

m (2)

m

m

(2)

(2)

Le 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 125

Ces sous-matrices sont ensuite concaténées pour former la matrice code :

G = [G(1) G(2)] =

<> m? m i

<> <> m\ 2 ) ni

<> m f m

<> mf m.

, (2 )

. ( 2 )

, ( 2 )

, ( 2 )

qui est une matrice carrée puisque L-U .

La formule [3.10] forme alors un système de 4 équations linéaires à 4 inconnues qui s'écrit :

e\ m<2) m\ 2 )~ V

mf mf <> m? h<" +

n2

< m? mf> h ?> +

"3 e4. mf m? m\ 2 ) nA

Chaque élément du vecteur e contient la contribution de chaque midambule convolué par son canal respectif et augmentée du bruit AWGN.

3.3.3. Les estimateurs de canaux : estimateur à maximum de vraisemblance / filtrage adapté

L'estimation \iest à maximum de vraisemblance du vecteur h des réponses impulsionnelles de canal est donnée par l'équation [3.15]4 :

HEST = M e avec M = (GH R"1 G} ' GH R"1 . [3.15]

Dans le cas habituel où le bruit nest blanc, la matrice de covariance Rn du vecteur de bruit n est particulièrement sympathique car elle est de la forme diag (a2 ). 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) ' GH e [3.16]

4. la notation X" est l'opérateur transposé conjugué.


qui est l'estimateur au sens des moindre carrés (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 carrée.

L'estimateur ainsi décrit réalise donc successivement un banc de filtres adaptés, suivi de la suppression des interférences 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 vérifie que la totalité des interférences entre midambules a été supprimée :

êst,ML = h + ( o " g ) ' G " n [3.18]

Le prix à payer pour obtenir la suppression de ces interférences et donc l'estimation à maximum de vraisemblance est la dégradation du RSB pour chaque élément de hc,s7 en comparaison du RSB qui serait obtenu en sortie d'un simple filtrage adapté :

h « , M F = G H e = G " G h + G " n [3.19]

L'équation [3.19] montre que la dégradation induite du RSB dépend 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 présentant les meilleures propriétés d'intercorrélation est inenvisageable. En effet, il a sélections de midambules possibles. Des contraintes supplémentaires sont imposées pour permettre des réductions de la complexité des calculs, ce qui a pour effet de réduire le nombre de midambules possibles. Les différents midambules sont des versions décalées cycliquement d'une même séquence de base de longueur L + U- 1, ce qui limite à 2L+U~] le nombre de possibilités. De plus, la séquence de base des midambules est choisie périodique de période 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 carrées (M = G -1).


Figure 3.16. Dérivation de différents midambules à partir d'un même code périodique de base

Exemple : Pour K = 2 utilisateurs et 2 canaux de réponse impulsionnelle de longueur

W= 2 chips, le nombre total de coefficients de canal inconnus est U = KW = 4 et L = 4. La séquence de base des midambules m est alors de longueur L + U- 1 = 7 et périodique de période L = U.

Les midambules des utilisateurs 1 et 2 ont une longueur totale de L + W -1 = 5 chips.

L


et génèrent les sous-matrices G ^ e t G(2) concaténées 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 manières : par corrélateur cyclique ou bien par FFT (.Fast Fourier Transform).

3.3.5.1. Mise en œuvre par corrélateur cyclique

Les matrices G et G"1 étant circulantes à droite, la détermination de h est une simple corrélation circulaire de e avec une colonne de M (qui peut être précalculée), réalisable par un corrélateur cyclique. Cette mise en œuvre est intéressante 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é réduite par FFT

Une propriété 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 (Discrète Fourier Transform) et IDFT (la matrice DFT est notée W).

En effet, en notant vecteur mj la première colonne de G complètement déterminée par les L éléments différents de la séquence de base des midambules :


[3.20]

On peut avantageusement employer des transformées de Fourier rapides pour faire les DFT et IDFT avec une complexité réduite. De plus, les midambules des utilisateurs sont connus, ce qui permet de précalculer les valeurs de A à partir des éléments du midambule et de les stocker.

La complexité des transformées de Fourier rapides mises en œuvre dépend de L : le tableau 3.3 donne la complexité générale 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 recalculée 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 réalisée avantageusement au moyen de :

- une FFT de longueur L sur e ;

- une pondération du résultat par les coefficients diagonaux de A ;

- une FFT inverse de longueur L sur le résultat des opérations précédentes.

Opération Nombre de multiplications complexes

FFT sur e (1/2) x log2(L/2)

Pondération par A L

IFFT sur A We (.U2) x log2(I/2)

Total L x (1 + log2(L/2))

Tableau 3.3. Nombre de multiplications complexes dans l'estimation à maximum de vraisemblance par FFT-Radix 2 quand que L est une puissance de 2

3.3.6. Performances de l'estimateur de canal à maximum de vraisemblance

Les figures 3.17 et 18 illustrent les performances de l'estimateur de canal multi-utilisateur à maximum de vraisemblance en fonction du nombre de midambules


transmis simultanément, pour le cas du 3,84 Mchips TDD avec des midambules de 512 chips.

La figure 3.17 détaille l'impact de la présence simultanée de midambules interférents transmis à forte puissance relative (+10 dB) sur l'estimation du canal d'un utilisateur. Elle montre une dégradation significative (supérieure à 2 dB) pour les forts RSB avec un seul interféreur, et une très forte dégradation sur toute la gamme de RSB considérés lorsque le nombre d'interféreurs est supérieur à 2. Cela illustre la nécessité du contrôle 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 interférents à +10 dB

La figure 3.18 montre la dégradation de l'estimation de canal en fonction du nombre d'interféreurs (de puissance identique). Cette dégradation 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 simultanément.


Figure 3.18. Erreur quadratique moyenne de l'estimation de canal5 en fonction du nombre de midambules interférents à 0 dB

3.4. Détection conjointe

Bien que le mode TDD de l'UMTS soit synchrone et utilise des codes d'étalement orthogonaux, cette orthogonalité est brisée par la transmission dans le canal radio multitrajet sélectif en fréquence et le système subit à la réception à la fois de l'interférence entre symboles d'un même utilisateur (1ES) et de l'interférence d'accès multiple entre symboles d'utilisateurs différents (IAM). L'efficacité du récepteur conventionnel mono-utilisateur est limitée dans cet environnement car il traite l'interférence d'accès multiple comme une augmentation du bruit blanc gaussien. Du fait de l'extension des techniques CDMA, de nouvelles approches ont été explorées, qui utilisent la connaissance a priori des codes d'étalement et des estimés de canal des autres utilisateurs pour réduire le niveau d'interférence d'accès multiple. Les fondements théoriques du récepteur multi-utilisateur optimal ont été décrits par Verdu [VER 89] mais la puissance de calcul requise pour le mettre en œuvre est prohibitive ; des techniques sous-optimales ont donc été développées,

Canal 3GPP-Case 3 ( 0dB@ 0ns, -3dB@ 260ns, -6dB@ 521 ns, -9dB@ 781ns) 120 km/h

5. Voir annexe 3.7 pour la description détaillée du modèle de canal.


parmi lesquelles les techniques linéaires qui ont été regroupées sous le vocable de détection conjointe.

L'objectif de la détection conjointe est, en se basant sur la connaissance des différents codes d'étalement utilisés et des estimés de canal associés, de détecter simultanément les données de chacun des utilisateurs présents dans un IT tout en minimisant pour chacun d'entre eux l'interférence provenant des autre utilisateurs.

3.4.1. Description du problème, modélisation

Supposons un système CDMA synchrone dans lequel K utilisateurs transmettent simultanément N symboles chacun en utilisant K codes d'étalement orthogonaux de longueur Q chips, transmis à travers K canaux multitrajet différents (dont les réponses impulsionnelles s'étalent sur au plus L chips) sur une même bande de

fréquence avec Bc = — . Tc

Figure 3.19. Modèle à temps discret d'une transmission CDMA synchrone en voie montante

Le problème peut être modélisé sous la forme d'une équation matricielle ([KLE 94] et [PIG 99]) dont on extraira l'estimé des données transmises au moyen d'un critère donné (LS, MMSE). Le signal reçu peut être exprimé sous la forme :

e = A . d + n [3.21]

Le m o d e U T R A - T D D e t ses p e r f o r m a n c e s 133

ou :

d = ] symboles émis avant étalement

e = [ e\>-'> eN.Q>---> eN.Q+L-1] 7" s iê n a l r eÇ U

n = [«,,•• '^N.Q^"">nN.Q+L-\\ blanc gaussien additif

A = [A..] i = \...N.Q + L-\ Qt j = \...N.K matrice système

Figure 3.20. Détail de la matrice système

Les éléments de A sont construits de la façon suivante :

\bk si k = \...K,n = \...N,w = \...Q + L-\ A = < w Q (n-\)+w , k+K.(n-\) 0 sinon

Le scalaire bk est défini comme un élément du vecteur bk = ck * hk (2^ avec

bk,bk,...,bk 12 Q+L-l qui représente la réponse impulsionnelle globale du ke

134 Principes et évolutions de l'UMTS >

utilisateur, hk = hk,hk,...,hk

12 L

T qui représente l'estimé de la réponse

impulsionnelle du ke canal (L échantillons de durée Tc) et ck = ck ,ck ,...,ck

1 2 Q

T est

le ke code d'étalement (Q bits espacés de Tc). Le paramètre k varie de 1 à K.

Chaque bloc de K colonnes de A contient les vecteurs bk qui sont les réponses impulsionnelles globales des k utilisateurs, c'est-à-dire pour chacun d'eux la convolution de la réponse impulsionnelle de son canal par son code d'étalement.

Exemple : Considérons le cas où 2 utilisateurs transmettent chacun 2 symboles de données en

utilisant des codes de Hadamard de 4 chips à travers 2 canaux différents de longueur 3 chips (les signaux considérés sont réels et le bruit est négligé par soucis de clarté).

Les codes d'étalement utilisés sont par exemple respectivement :

c=[ 1 -1 1 - l j (Q chips)

c 2 = [ \ 1 - 1 - l j ( Q chips).

Les réponses impulsionnelles des canaux sont :

h = [ 1 1/2] (L chips)

h =[ 1 1/4] (I chips),

et les données transmises par les 2 utilisateurs sont d = [ 1 1 ] et d^ = [ 1 -1] .

Après étalement et transmission dans les canaux radio, le signal reçu est donc :

e = [2 3/4 -1/4 -7/4 -3/4 -7/4 5/4 3/4 - I/4J Au niveau du récepteur, les codes et les canaux étant supposés parfaitement estimés,

ils sont utilisés pour construire la matrice système. Les réponses impulsionnelles globales des 2 utilisateurs sur leurs canaux radio respectifs sont calculées :

^=[1 -1/2 1/2 -1/2 -1/2J (Q+L-l chips)

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


puis intégrées dans la matrice système de dimension ( N K ) x (N Q + L - 1) :

3.4.2. Critères de résolution du système d'équations linéaires

Le principe de la détection conjointe est de résoudre l'équation linéaire [3.21], c'est-à-dire de déterminer un estimé d des données transmises d en fonction du signal reçu e, de la matrice système A et de la connaissance éventuelle des propriétés statistiques du bruit AWGN n. Cela peut être fait selon plusieurs critères sous-optimaux décrits dans [KLE 94]. Les plus usuels sont les algorithmes Zéro Forcing Block Linear Equalizer (ZF-BLE) ou égaliseur linéaire en bloc par forçage à zéro et le Minimum Mean Square Error Block Linear Equalizer (MMSE-BLE) ou égaliseur linéaire en bloc à erreur quadratique moyenne minimale.

3.4.2.1. Egaliseur linéaire en bloc par forçage à zéro

L'égaliseur linéaire en bloc par forçage à zéro 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 donnés (P(e/A,d)). Rn est la matrice de covariance du vecteur de bruit n, ce qui mène à [HAY 96] et [KLE 94] :

A

d = (AH R~lA)~lAH R~le

d + (AHR~lA)~lAHR~ln [3.23] symboles utiles bruit

136 Principes et évolutions de l 'UMTS >

Cet égaliseur est appelé forçage à zéro car il élimine totalement l'interférence entre symbole (IES) et l'interférence d'accès multiple (IAM), sans tenir compte du niveau du bruit (l'estimé contient la donnée elle-même plus un terme de bruit).

Si les échantillons de bruit sont décorrélés (cas usuel), la matrice de corrélation bruit/?"1 devient a2I, où a2 est la

Les données estimées devenant alors : du bruit Rn

1 devient CT2 I, OÙ a2 est la variance du bruit et I est la matrice identité

d = (AH A)~XAH e

+ (AHA)~XAHn [3.24]

symboles utiles bruit

Cet algorithme est très efficace si le niveau de bruit est faible car le deuxième terme est alors faible devant le premier.

3.4.2.2. Egaliseur linéaire en bloc à erreur quadratique moyenne minimale

L'égaliseur linéaire en bloc à erreur quadratique moyenne minimale minimise :

E({d-d)H (d-d)) [3.25]

c'est-à-dire l'erreur commise sur l'estimée elle-même, ce qui mène à [HAY 96] et [KLE 94] :

d = (AHR~lA + R~l)~lAHR~le A

= (I + (RdAHR-lA)- l)-\dzF-BLE WQ estimateur de Wiener [3.26]

H D - \ A , D - K - 1 aH 1 = diag(W0).d + diag(W0).d + (An R~lA + R'1)'1 An R~ln

symboles IES et IAM bruif

En cas d'échantillons de bruit et de données non corrélés (cas usuel), l'estimé devient :

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


Cet algorithme présente une meilleure immunité au bruit que l'algorithme par forçage à zéro car il pondère la suppression d'interférence 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 généralité sous la forme :

[3.28]

où les termes représentent respectivement les puissances de l'IAM, du signal et du bruit.

Lorsque le niveau de bruit est petit par rapport au niveau d'IAM, l'équation [3.28] se simplifie en :

[3.29]

qui est similaire à l'estimé obtenu par l'algorithme de forçage à zéro.

En revanche, quand la puissance de l'IAM est petite devant le bruit (c'est-à-dire quand l'équation [3.28] se simplifie en :

[3.30]

2 Cette expression peut s'écrire, en considérant la puissance moyenne <je

du signal reçu e :

[3.31]

qui est similaire, à un coefficient près, à une estimation par filtrage adapté.

On constate donc que si le niveau de bruit est grand devant le niveau d'interférence d'accès multiple, l'algorithme se comporte de façon similaire à un banc de filtres adaptés alors qu'il se comporte comme un algorithme de forçage à zéro si l'IAM est grande devant le bruit.

Des égaliseurs à contre-réaction (DFE, Décision Feedback Equalizers) nommés MMSE-BDFE et ZF-BDFE ont également été dérivés à partir de la même base théorique.


Exemple (suite et fin) : Considérons la résolution du système linéaire décrit précédemment selon le

critère ZF-BLE pour lequel les données sont estimées selon l'équation :

De A, on obtient facilement :

3.4.3. Performances de la détection conjointe

La figure 3.21 illustre les performances de la détection conjointe en voie descendante (simulation effectuée avec l'algorithme ZF-BLE) dans un canal multitrajet en fonction du nombre de codes présents. Le modèle de canal utilisé dans la simulation est indiqué en annexe.


Figure 3.21. Performance de la détection conjointe en voie descendante en fonction du nombre de codes transmis simultanément

(<contrôle de puissance parfait/estimation de canal par midambule)

Les performances de la détection conjointe décroissent avec le nombre de codes transmis simultanément, particulièrement pour les faibles TEB. Dans la pratique, cela implique que le nombre maximum théorique de codes transmis simultanément (16) ne sera pratiquement jamais atteint et que le système sera en général limité par l'interférence à un maximum de 10 à 12 codes par IT.

La figure 3.22 présente les performances de la détection conjointe en voie montante qui sont moindres qu'en voie descendante. Cela est dû au fait que le niveau d'interférence est plus important en voie montante car le canal radio vu par chacun des utilisateurs lui est spécifique.

3.4.4. Réduction de la complexité de la détection conjointe

Le principe de la détection conjointe présenté précédemment est de résoudre l'équation matricielle e = Ad + n (c'est-à-dire d'estimer d en connaissant e et a) en

Voie descendante / Canal Case 3 ( 0dB@ 0ns, -3dB@ 260ns, -6dB@ 521 ns, -9dB@ 781ns) 120km/h


fonction d'un critère prédéfini dont les plus répandus sont le zéro forcing (ZF), qui annule l'interférence ou l'erreur quadratique moyenne minimum (MMSE). Ces critères mènent aux solutions suivantes :

d = (Â H A; _ 1 A H e pour le ZF et d = (Au A + <J2\)~] A H e pour le MMSE (a2 étant la variance des éléments de n).

La résolution de cette équation nécessite de calculer A à partir de l'estimation de canal et des séquences d'étalement, de réaliser le produit AH e, de réaliser le produit A" A et enfin de résoudre un système linéaire de matrice AH A ou AH A + ct2 I de taille (N.K x N.K). Ces opérations à réaliser sur des matrices de cette taille sont extrêmement coûteuses en puissance de calcul. Une réduction de la complexité est donc particulièrement intéressante.

Figure 3.22. Performance de la détection conjointe en voie montante(

en fonction du nombre de codes transmis simultanément (icontrôle de puissance parfait/Estimation de canal par midambule)

6. Voir annexe pour la description détaillée du modèle de canal.


3.4.4.1. Optimisation

Une première réduction de complexité est obtenue en tenant compte des caractéristiques des matrices A, AH et AH A (identiquement AH A + a2I) qui contiennent de nombreux coefficients nuls dont la position est connue en fonction des caractéristiques de la transmission et qui peuvent donc ne pas être traités.

D'autre part, la matrice AH A (et identiquement AH A + CJ2I) est hermitienne semi-définie positive, ce qui permet d'employer la décomposition de Cholesky pour résoudre le système linéaire associé avec une complexité de l'ordre de (NK)3/6 au lieu de (NK)3/3 si on utilise une méthode de résolution plus générale (par exemple la méthode du pivot).

3.4.4.2. Décomposition de Cholesky approchée

Cependant, la quantité de calcul reste très importante et peut encore être drastiquement réduite en utilisant, par exemple, une décomposition de Cholesky approchée : en effet une autre propriété des matrices AH A et AH A + a2I est qu'elles sont de type bloc Toeplitz et ne contiennent que P + 1 sous-matrices non nulles différentes de taille [K, K/, P étant la partie entière de ((Q + L - 1 )/Q).

La décomposition de Cholesky d'une matrice de ce type converge en ligne de blocs ([PIG 99] et [RIS 73]) : le résultat de la décomposition de Cholesky est ici constitué de N lignes de P + 1 blocs non nuls de taille [K, K]. On peut donc appliquer cette propriété 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 détection conjointe. La complexité de la décomposition est ainsi réduite proportionnellement à (N/N0)2 .

La réduction de complexité apportée par ces algorithmes permet d'implanter la détection conjointe sur DSP [NOG 04].

3.5. Allocation dynamique des ressources

Comme dans tous les réseaux CDMA, la gestion de la ressource radio est très importante. En UTRA-FDD, elle est principalement faite par le contrôle de puissance. En UTRA-TDD, le contrôle de puissance garde son importance mais il faut également développer des algorithmes d'allocation de ressources radio.


Les types d'interférence présents en UMTS-TDD sont : - les interférences de la voie montante vers la voie descendante, sous la forme

d'interférences de mobile à mobile ; - les interférences de la voie descendante vers la voie montante, sous la forme

d'interférences de station de base à station de base ; - les interférences internes à la voie montante ou à la voie descendante, de

mobile à station de base et inversement.

Les interférences voie montante/voie descendante et voie descendante/voie montante se produisent lorsque les stations de base ne sont pas synchronisées ou lorsque des asymétries différentes sont utilisées 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 réseau et l'utilisation de la même asymétrie dans les cellules adjacentes.

Le respect de cette dernière 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 règle ([HOL 00] et [JEO 00]).

Les interférences voie montante/voie montante ou voie descendante/voie descendante ne peuvent quant à elles être traitées que par l'allocation dynamique de canaux (DCA, Dynamic Channel Allocation) ([25.922], [ARG 99], [HAA 00]) qui alloue les ressources physiques élémentaires (combinaison de 1 code, 1 IT et 1 fréquence) aux différents services en fonction de critères de qualité préétablis de manière à optimiser les performances du système en termes de probabilité de blocage, de capacité système, et de qualité des appels.

La DCA englobe plusieurs mécanismes : le contrôle d'admission des appels qui définit quand un appel est accepté ou refusé par le système, la stratégie d'allocation de ressource qui définit quelle ressource est allouée à un appel lorsqu'il a été accepté et l'algorithme de groupage des ressources qui décide quand déclencher une réallocation de ressources en cours d'appel.

Pour ce faire, la DCA est scindée en 2 parties : la DCA lente contrôlée par le RNC {Radio Network Controller) qui alloue des sous-ensembles de ressources aux cellules et la DCA rapide, située au niveau de chaque station de base, qui alloue les ressources aux services dans les cellules à l'intérieur des sous-ensembles préalablement alloués par la DCA lente.


3.5.1. Allocation des ressources aux cellules (DCA lente)

Dans un système UMTS TDD, il n'y pas de planification de fréquences : une même fréquence porteuse peut être utilisée dans des cellules adjacentes mais les IT (slots) sont partagés entre cellules.

Les IT de la trame TDD sont utilisables aussi bien en voie montante qu'en voie descendante (à l'exception de ceux réservés à la synchronisation ou à la signalisation commune). L'allocation des ressources en voie montante et voie descendante adapte donc le système aux variations dans le temps de l'asymétrie du trafic.

L'allocation des IT aux cellules (en voie montante comme en voie descendante) est réactualisée périodiquement à faible rythme (DCA lente) de façon que des cellules interférant fortement utilisent des IT différents (voir figure 3.23). Cependant les ressources allouées à des cellules adjacentes peuvent tout de même se chevaucher en fonction du niveau d'interférence entre les cellules.

Pendant les périodes libres entre la réception et la transmission des bursts successifs, les mobiles peuvent fournir au réseau des mesures (affaiblissement de parcours sur un sous-ensemble de cellules, interférence dans les IT différents de celui en cours d'utilisation, BER du lien en cours, puissance de transmission du mobile dans le lien courant). Ces informations cumulées 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 allouées et libérées en fonction d'une liste de préférence dérivée de la DCA lente et les différents débits de service sont supportés par agrégation de ressources élémentaires. Cela peut se faire dans le domaine des codes (codes multiples dans un même IT = multi code), dans le domaine temporel (IT multiples dans une même 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 caractéristiques du canal.

Pour les services temps réels (RT), les canaux sont alloués pour la durée totale du service et l'allocation ne peut être modifiée que si une procédure de réallocation est mise en œuvre.


Pour les services non temps réel (NRT), les canaux sont alloués seulement pour la durée de transmission d'un paquet selon la procédure du « best effort » (les besoins en ressources non satisfaits sont placés en liste d'attente, le nombre de ressources allouées à un service dépend des disponibilités et des autres requêtes traitées simultanément).

La procédure de réallocation (handover intracellulaire) peut être déclenchée pour s'adapter aux variations des conditions d'interférence, pour limiter la fragmentation des codes alloués sur trop de IT (libération des IT les moins chargés puis réallocation de canaux) et permettre ainsi de servir des services haut débit RT ou encore pour conserver la séparation spatiale des différents utilisateurs d'un même IT quand des antennes actives sont utilisées.

Figure 3.23. Exemple de partage des IT entre cellules (DCA lente)

3.6. Synchronisation du réseau (3,84 Mchips TDD)

Du fait de sa structure de séparation duplex en temps, une synchronisation inter-cellule est nécessaire pour exploiter pleinement la capacité du système (en particulier éviter les interférences de mobile à mobile). La précision de synchronisation requise est de l'ordre de 3 ps pour l'UTRA TDD.


3.6.1. Présynchronisation par le réseau

La structure du réseau avec les stations de base (ou Node B) d'un RNS contrôlé par un même RNC permet d'obtenir une synchronisation grossière 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 délais imposés par la transmission sur les interfaces Iub et Iur, la précision atteinte est de l'ordre de 5 trames (50 ms), le niveau de précision supérieur requis de 3 ps doit alors être atteint par un mécanisme de synchronisation fine.

3.6.2. Synchronisation fine par horloge de référence {de type GPS)

La façon la plus directe de synchroniser finement le réseau UMTS-TDD est d'utiliser une référence de temps externe, par exemple le temps GPS dans chaque station de base. Malheureusement, cela peut devenir peu pratique ou impossible dans certains scénarios de déploiement tel qu'un déploiement indoor où une antenne extérieure est requise pour chaque récepteur GPS.

3.6.3. Mécanisme de synchronisation fine

Un mécanisme additionnel de synchronisation a été conçu pour éviter l'utilisation de récepteurs GPS. Il est basé sur des transmissions périodiques de séquences de synchronisation spécifiques couplées à des mesures de temps de trajet.

Ce mécanisme de synchronisation des stations de base permet de synchroniser les stations de base TDD d'un même RNS (Radio Network Sub-system) c'est-à-dire contrôlées par un même RNC (Radio Network Controller). Ce mécanisme nécessite qu'au moins une des stations de base ait accès à une horloge de référence sur laquelle les autres stations vont venir se synchroniser.

Typiquement, les Node B d'un RNS sont informés par le réseau des instants de transmission ou d'écoute des bursts de synchronisation interstation de base dans des IT de voie montante pour l'accès (uplink RACH) réservés à cet effet. Un Node B qui reçoit 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 séquence de synchronisation toutes les 10 à 15 secondes et recevoir des séquences de synchronisation des cellules voisines toutes les secondes. A partir des écarts de synchronisation mesurés et de l'horloge de référence, le RNC peut dériver les corrections d'horloge pour les Node B qu'il contrôle. La procédure peut être divisée en 2 phases, la synchronisation initiale et la phase de maintient de la synchronisation.


3.6.3.1. Synchronisation initiale

Au démarrage du réseau, quand il n'y a pas de trafic, les cellules d'un RNS doivent toutes être synchronisées. Toutes les cellules transmettent successivement la même séquence de synchronisation. En mesurant les transmissions des cellules environnantes, chaque cellule peut déterminer son retard relatif et le reporter ainsi que le rapport signal sur interférence (RSI) à la réception des séquences de synchronisation détectées au RNC qui les utilise pour ajuster les horloges de chaque cellule et atteindre la précision de synchronisation requise. Les Node B étant grossièrement présynchronisés par leur RNC, la séquence de synchronisation de cellule est reçue 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 réseau supporte du trafic utilisateur, le mécanisme est conçu de manière à ne pas générer d'interférences avec le trafic existant. Les différentes cellules d'un RNS utilisent la même séquence de synchronisation de base mais sont différenciées par l'application de décalages de la séquence différents. Le RNC décide quelles sont les cellules qui doivent transmettre et lesquelles doivent écouter et leur communique respectivement tous les paramètres de transmission, à savoir l'instant de transmission, la puissance de transmission, le code de base, le décalage à appliquer et les paramètres de réception (code de base et décalages de code à mesurer dans un IT donné). La dérive d'horloge maximale à corriger est de quelques ps. De plus un décalage supplémentaire 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. Séquences de synchronisation des Nodes B

Les séquences de base utilisées sont des séquences somplémentaires étendues concaténées (séquences CEC) décrites dans [JEC 01]. Les séquences CEC choisies pour l'UMTS TDD sont construites à partir de paires de codes complémentaires de Golay, dont la somme des fonctions d'autocorrélation est un Dirac [GOL61], périodiquement étendues de 128 bits puis concaténées.

Exploitée avec un récepteur adéquat ([BUD91], [JEC 01]), la séquence CEC permet d'obtenir une fenêtre d'analyse de largeur 128 bits qui ne présente aucun pic secondaire et dont le pic principal est un Dirac. La taille de cette fenêtre est suffisante pour satisfaire les contraintes de délai de propagation maximum et d'étalement de la réponse impulsionnelle du canal.


Figure 3.24. Construction d'une séquence CEC à partir d'une paire (s(n), g(n)) de séquences complémentaires

Le récepteur adapté (figure 3.25) corrèle dans un premier temps les 1 152 premiers bits du signal reçu avec une réplique locale de s(n), les 128 premiers bits parmi les 1 152 bits correspondant à s(n) étant supprimés. La corrélation avec g(n) est ensuite réalisée de la même manière sur les 1 152 derniers bits reçus. En supprimant les 128 premiers bits, toute intercorrélation indésirable entre s(n) etg(«) due à un canal multitrajet dont la longueur de la réponse impulsionnelle est inférieure à 128 bits est évitée. Finalement, la somme des autocorrélations est obtenue après addition des résultats obtenus lors des 2 premières étapes. Pour faire fonctionner ce récepteur, il est nécessaire d'être dans un état présynchronisé avec une précision minimale de ± 64 bits, ce qui est le cas puisque ce récepteur n'est utilisé que dans la phase de maintien de la synchronisation. La synchronisation initiale est effectuée par simple corrélation sur une séquence unique.

Figure 3.25. Récepteur pour séquences CEC


De plus, une famille de 8 séquence décalées, en fait constituées à partir de versions décalées cycliquement (par pas de 128) d'une même paire de séquences complémentaires peut être construite à partir de chaque paire complémentaire. Du fait des propriétés de complémentarité des codes de base, les séquences de cette famille sont orthogonales entre elles pour tout retard inférieur à ± 64 bits et sont traitées simultanément par le même récepteur (caractérisé par les séquences s(n) et g(n) quel que soit le décalage cyclique qu'elles aient subies). Les huit décalages possibles par séquence CEC de base permettent d'assurer l'interopérabilité entre les Node B dans une zone de déploiement TDD.

Une somme d'autocorrélation typique, obtenue pour le cas ou 3 séquences CEC différentes issues de la même paire de séquences complémentaires (de décalages 0, 256 et 512 bits) sont transmises simultanément est représentée sur la figure 3.26.

Figure 3.26. Somme d'autocorrélation pour 3 séquences CEC orthogonales (décalages 0, 256 et 512 bits) transmises simultanément

Dans le cas où l'utilisation simultanée de séquences CEC décalées n'est pas possible, notamment lors de la phase de synchronisation initiale et dans le cas de plusieurs réseaux d'opérateurs différents opérant dans une même zone géographique, des codes de synchronisation différents peuvent également être dérivés de 8 paires de codes complémentaires de Golay différentes choisies pour leurs propriétés de inter corrélation.


3.7. Annexe : modélisation du canal radio mobile

Le canal radio mobile UMTS est typiquement un canal multitrajet dispersif et sélectif en fréquence (voir paragraphe 1.2.3.2). Il est modélisé par une somme de trajets retardés dont les délais et les puissances moyennes caractérisent le contexte géographique (environnement urbain ou rural) et dont les variations d'amplitudes complexes caractérisent la mobilité. Chacun de ces trajets résulte lui-même d'une somme de microtrajets présentant des délais quasi identiques et des atténuations complexes aléatoirement distribuées selon une loi gaussienne bornée en fréquence par le spectre Doppler. Cette loi gaussienne est centrée s'il n'y a pas de microtrajet direct. Il en résulte que le module de chacun des trajets obéit dans le temps à une distribution de Rayleigh (en l'absence de microtrajet direct) ou de Rice avec un temps de cohérence dépendant de la mobilité (fréquence Doppler).

La réponse impulsionnelle du canal est donc exprimée comme une somme pondérée d'impulsions de Dirac de poids complexes hk{t) variant dans le temps.

Dans ce chapitre, les simulations ont été réalisées sur le canal Case 3. Il s'agit d'un canal de test défini par le 3GPP [25.105] et correspondant à un canal multitrajet à réponse impulsionnelle courte et à forte mobilité (vitesse de déplacement jusqu'à 120 km/h).

Tous les trajets ont un spectre Doppler classique

Tableau 3.4. Paramètres du canal 3GPP-Case 3 ( Vitesse = 120 km/h)


3.8. Bibliographie

[25.922] 3GPP TR 25.922, « Radio resource management stratégies ».

[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 procédures (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 Sériés», 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 Considérations 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 . , . JEONG D.G, « Comparison of Time Slot Allocation Stratégies 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 détection in code division multiple access mobile radio systems », IEEE 1994.

[MOT 99] Motorola, « Complexity of Multiple channel estimations at the SU », 3GPP-TSGR1 #4(99)389 (disponible à l'adresse http://www.3gpp.org/).

[PET 95] PETERSON R . L . , ZLEMER R.E., BORTH D.E., Introduction to Spread Spectrum Communications, Prentice hall, 1995.

[ P I G 9 9 ] PIGEONNAT Y . « Joint détection for U M T S : complexity and alternative solutions », I E E E 1 9 9 9 .

http://www.3gpp.org/



[ R I S 7 3 ] RISSANEN J . « Algorithms for Triangular Décomposition 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 ] NOGUET D . , BOUYOUD J .P . , ZAGHDOUDI L . , VARREAU D . , JECHOUX B . , LE CORRE

P., LAGRANGE X . , NASREDDINE J . , « A hardware testbed for U M T S - T D D joint détection baseband receivers », I S S S T A , 2 0 0 4 .

[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 Détection », IEEE 1994

[ V E R 89] VERDU S. « Computational Complexity of Optimum Multiuser Détection » Algorithmica, vol. 4, p. 303-312, 1989.

Chapitre 4

Le contrôle de puissance dans l'UMTS

4.1. Introduction

La technique d'accès multiple CDMA (Code Division Multiple Access) est utilisée depuis les années cinquante dans des réseaux militaires. Les avantages visés étaient principalement la confidentialité accrue et la résistance 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 élevée.

Au début des années quatre-vingt-dix, l'idée de l'utilisation du CDMA pour les réseaux sans fil civils [GIL91], [LEE 91] commença à s'imposer avec comme nouvel avantage prévu l'augmentation de l'efficacité de l'utilisation du spectre par rapport aux techniques basées sur le multiplexage temporel TDMA ou F/TDMA, accès multiple utilisé dans GSM. Le premier réseau cellulaire CDMA, appelé IS-95, a été déployé aux Etats-Unis vers le milieu des années quatre-vingt-dix.

Les réseaux cellulaires adoptés comme systèmes dits de troisième génération (3G) ont pour technique d'accès multiple le CDMA. Dans ce chapitre, nous commençons par introduire le contrôle de puissance d'un réseau cellulaire CDMA de façon générale. Des éléments de calcul de capacité sont donnés en vue de justifier l'aspect indispensable du contrôle de puissance dans ce type de réseau. Les

Chapitre rédigé par Loutfi NUAYMI.


méthodes générales de contrôle de puissance ainsi que le lien entre ce dernier et d'autres procédures de gestion des ressources radio sont considérées.

Dans la suite, nous décrivons le contrôle de puissance particulier au système UMTS-WCDMA, dans ses deux variantes : UTRA-TDD et UTRA-FDD ainsi que cdma2000. Les spécifications des groupes de normalisation 3GPP (3rd Génération Partnership Project, www.3gpp.org) pour WCDMA et 3GPP2 (3rd Génération Partnership Project 2, www.3gpp2.org) pour cdma2000 sont utilisées pour les présentations des contrôles de puissance proposés dans le réseau UMTS.

4.2. Présentation du modèle et formalisation du problème

Dans un réseau du type F/TDMA comme GSM, une planification soignée de la répartition des fréquences porteuses doit être effectuée. Cette planification doit être régulièrement remise à jour en fonction des évolutions du réseau. Cela n'est pas le cas dans un réseau cellulaire CDMA où toutes les communications utilisent la même bande de fréquence, la séparation se faisant à partir des codes au niveau du récepteur. De nouveaux problèmes, par rapport aux réseaux F/TDMA, apparaissent.

Une communication donnée subit deux types d'interférences : 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 théorie d'avoir deux communications utilisant la même fréquence à un instant donné dans la même cellule. D'où l'intérêt du contrôle de puissance et, plus généralement, d'une gestion efficace des ressources radio dans un réseau cellulaire CDMA. C'est à ce prix que les réseaux CDMA peuvent avoir une capacité plus grande que celle d'un réseau basé sur le TDMA.

Dans ce chapitre, nous considérons le modèle suivant. La qualité de la réception est représentée 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 reçu (SIR, Signal-to-Interference Ratio) est une grandeur physique plus accessible. En effet, le récepteur peut estimer la puissance du signal utile reçu et celle du bruit en vue de déduire le SIR. Le rapport EJNoest lié au SIR par la relation suivante :

[4.1]

http://www.3gpp.org

http://www.3gpp2.org

Le contrôle de puissance dans 1 ' U MTS 161

où R est le débit binaire de données du signal numérique en bit/s et W la bande de fréquence, en Hz, occupée après étalement du signal.

Comme toutes les communications utilisent la même bande de fréquence, une communication donnée subira des interférences 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 interférences dans un réseau cellulaire CDMA (cas de la voie montante)

La valeur de EJNQ correspondant au seuil de qualité requis, appelée valeur-seuil dans la suite, dépend des paramètres de la transmission (type de modulation, de codage), de ceux du canal radio (multitrajets, retards, variations du canal) et de ceux


du récepteur (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 reçue, notée C, sur le bruit total reçu, noté N. Le bruit reçu est la somme de l'interférence notée / et du bruit intrinsèque de réception, dit bruit thermique, noté N0. Le SIR reçu s'écrit alors :

Si nous exprimons / comme la somme de l'interférence intracellulaire ou interne à la cellule, notee Imt et celle intercellulaire ou externe à la cellule, notée , nous pouvons écrire :

[4.1a]

Dans le cas où les signaux d'une même cellule sont orthogonaux, l'interférence interne à la cellule est multipliée 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 remplacée par la formule suivante :

[4.1b]

Les signaux de la voie descendante (downlink, de la base vers les mobiles) subissent le même trajet entre une base et un mobile donnés. Cela permet de préserver, jusqu'à un certain degré, l'orthogonalité entre les canaux d'une même base. Le facteur a de la relation [4.1b] sera donc non négligeable. Par suite, le rapport Eb/N0 calculé avec la relation [4.1], où le SIR est calculé avec la relation [4.1a] sera inférieur à sa valeur réelle. 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 différents. Il n'y a pas d'orthogonalité et la relation [4.1a] est réaliste. On cherche plutôt à avoir une faible corrélation en remplacement de l'orthogonalité entre les différents canaux.

L'interférence intracellulaire et intercellulaire est la limite la plus importante au nombre de communications simultanées. Il en résulte que, pour les deux sens de la


communication, un contrôle de puissance efficace est nécessaire pour augmenter la capacité du réseau.

4.2.1. Capacité et contrôle de puissance dans un réseau cellulaire CDMA

Pour les réseaux où le débit de données est le même dans les voies montante et descendante, dits à débits symétriques, la voie montante est la plus contraignante en ce qui concerne la capacité [VIT 95]. Cela est dû au problème dit de l'effet proche-lointain (near-far effect), illustré dans la figure 4.2 et décrit dans la suite. Au cas où tous les mobiles émettent avec la même puissance, c'est-à-dire en l'absence de contrôle de puissance, un mobile proche de la frontière de la cellule est reçu 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 contrôle de puissance doit aussi tenir compte des interférences venant des autres cellules.

A partir de la valeur-seuil de EJNQ et du contrôle de puissance appliqué, la capacité du réseau, représentée par le nombre maximal de communications simultanées, peut être estimée. Dans la suite, une estimation simple de la capacité pour un contrôle de puissance idéal est proposée [VIT 95]. Elle est faite dans le cas de la voie montante.

Une politique idéale de contrôle de puissance consiste à choisir les puissances d'émission des mobiles de sorte que ces derniers soient reçus avec la même puissance sur leur base de correspondance, c'est-à-dire celle qui les relie à la partie fixe du réseau mobile. Dans [NUA 01], il est démontré que ce contrôle de puissance est optimal, suivant un certain critère basé sur la qualité de communication.

Pour le calcul suivant, nous considérons, dans une première étape, une cellule isolée. Nous notons la puissance reçue par la base à partir d'un mobile 7i0. Nous considérons que cette puissance reçue est la même pour tous les mobiles sur leur base correspondante. L'interférence I reçue par la base d'une cellule où K communications simultanées ont lieu est alors donnée par :

[4.2]

Les relations [4.1] et [4.2] ainsi que l'hypothèse simplificatrice que toutes les communications ont le même débit de données R permettent de déduire la valeur maximale de K en fonction de la qualité de communication requise :


[4.3]

où la valeur-seuil de EJNQ est notée (EtJNçùr et où l'interférence des mobiles des cellules voisines n'est pas prise en compte.

Un des atouts majeurs des systèmes 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 systèmes F/TDMA où le nombre d'interférants proches est plus faible et le calcul de l'augmentation de capacité est plus complexe.

Au cas où tous les mobiles émettent avec la même puissance (absence de contrôle de puissance), un mobile proche de la frontière de la cellule est reçu 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 résulte introduit un deuxième facteur de gain, noté GA. Pour une antenne trisectorielle, GA

devrait être égal à 3 en valeur réelle. [LEE 91] estime que des pertes de ldB, équivalentes à un coefficient de 0,8, font passer cette valeur à 2,4 en valeur réelle. Enfin, si on suppose que K est assez élevé par rapport à 1, la relation [4.3] devient :

Considérons maintenant un réseau à plusieurs cellules. L'interférence due aux cellules voisines est prise en compte par un facteur/ représentant le rapport de cette interférence, souvent appelée other-cell interference, sur l'interférence interne à la cellule. Ce paramètre dépend du modèle de canal radio considéré. Des calculs de / sont proposés dans [COR 98] et [VIT 94]. Un ordre de grandeur de/pour les canaux usuels est 0,6.

On réécrit alors la relation [4.2] :

La relation [4.4] permet ensuite d'avoir une estimation de la capacité d'une cellule :

Application numérique : 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 contrôle de puissance idéal, le facteur d'étalement (W/R) peut être pris comme valeur maximale du nombre de communications simultanées dans une cellule.

[4.4]

[4.5]

[4.6]

L


Nous notons à ce stade que ce calcul ne tient pas compte des imperfections inévitables du contrôle de puissance (voir paragraphe 4.8), ni d'autre phénomènes importants comme les variations aléatoires dans un réseau cellulaire, les canaux de contrôle, etc. Cependant, [4.6] permet d'avoir une idée du nombre maximal de mobiles dans une cellule de réseau CDMA.

En l'absence du contrôle de puissance, tous les mobiles émettent à la même puissance. Dans ce cas, les simulations permettent de vérifier que la capacité du réseau est beaucoup plus petite.

Pour les réseaux cellulaires CDMA à débits symétriques, la voie descendante est moins contraignante au niveau capacité que la voie montante. La capacité de la voie descendante a été moins étudiée jusqu'à présent. Un exemple de ce type de calcul est proposé dans [LEE 91]. Dans les réseaux où les données transmises auront une part importante (par exemple Internet), la voie descendante aura un débit moyen supérieur à 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 méthodes de contrôle de puissance proposées

Plusieurs classifications sont proposées pour le contrôle de puissance des réseaux mobiles.

4.2.2.1. Contrôle de puissance utilisant la puissance ou la qualité reçue

On distingue d'une part les contrôles de puissance basés sur le niveau de puissance reçue (RxLev ou Rx) et d'autre part ceux basés sur la qualité reçue (RxQual). La qualité de réception correspond au taux d'erreur binaire (BER, Bit-Error-Rate ). Dans les systèmes numériques, le BER de réception est directement lié au rapport signal sur bruit reçu ou SIR (voir plus haut). L'estimation de RxQual passe donc souvent par celle du SIR reçu.

Comme l'objectif premier est de garantir une certaine qualité de communication, les contrôles de puissance basés sur le RxQual auront de meilleures performances que ceux basés sur le RxLev. En contrepartie, l'estimation de la qualité reçue peut être entachée d'erreur. Il peut en résulter une dégradation du contrôle de puissance.


4.2.2.2. Contrôle de puissance distribué ou centralisé

Une autre distinction peut être faite entre le contrôle de puissance distribué et celui centralisé. Dans un contrôle de puissance distribué, la mise à jour de la puissance émise dans chaque lien est décidée par un élément donné, généralement le récepteur de ce lien. A l'opposé, un organe central, effectuant un contrôle de puissance centralisé, dispose des informations nécessaires sur tout le réseau et pourra assigner les puissances émises à tous les émetteurs concernés. Un tel organe central ayant des informations sur tous les canaux radio ne peut pas exister en pratique. Le contrôle de puissance centralisé ne peut avoir qu'un intérêt théorique, par exemple pour estimer la performance optimale, pour un critère donné, d'un réseau mobile.

La distinction entre ces deux concepts peut être retrouvée dans deux articles de Zander, considérés actuellement comme des classiques du sujet en raison du nombre de publications postérieures qui y font référence et qui en ont utilisé le modèle matriciel. Dans [ZAN 92], l'auteur propose un contrôle de puissance centralisé et il montre qu'il a des performances proches d'un contrôle de puissance optimal, le critère étant la minimisation du taux de coupure du réseau. Zander propose dans la suite un contrôle 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 général d'un contrôle de puissance distribué basé sur la qualité reçue est illustré dans la figure 4.3.

Le récepteur estime le rapport signal sur bruit (RSB) reçu, noté, y,. Cette valeur est transmise au récepteur qui l'utilise pour déduire la puissance à émettre.

Figure 4.3. Schéma de principe du contrôle de puissance basé sur le niveau de qualité reçue.


4.2.2.3. Boucles de contrôle de puissance

En vue de mettre en œuvre un contrôle de puissance distribué, une boucle de contrôle est souvent utilisée. Les considérations classiques des boucles de contrôle, également appelées boucles d'asservissement, sont alors applicables. Il est alors possible de considérer une boucle ouverte, c'est-à-dire sans retour d'information, ou une boucle fermée.

Dans une boucle ouverte (voir figure 4.4), l'hypothèse que le gain du canal radio est le même dans les deux sens est nécessaire. En effet, si le mobile doit être reçu 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, notée P„„ est alors donnée 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 donnée par la relation suivante :

où Pb est la puissance émise à la base, connue par le mobile, et Prb est la puissance reçue par le mobile et mesurée par ce dernier. L'hypothèse Gbm = G,„b permet de calculer la puissance d'émission du mobile en fonction de termes connus ou mesurés :

Malheureusement, le gain de liaison est rarement le même dans les deux sens de communication car la fréquence ou le temps ne sont pas identiques. Une autre explication de la différence est la présence des trajets multiples. En conséquence, la boucle ouverte est seulement utilisée lors de l'accès initial (voir la suite de ce chapitre). Le reste du temps, une boucle fermée ou, autrement dit, un retour d'information est indispensable.

Le retour d'information peut être analogique (par exemple, valeur du gain Gmb) ou numérique (un ou plusieurs bits donnant une information sur le gain du canal ou


un ordre direct pour la puissance émise), ce qui donne une boucle de contrôle analogique ou numérique. Les systèmes 3G utilisent des boucles fermées numériques uniquement.

Dans le but d'être reçu avec une puissance donnée à la station de base, le mobile estime le gain du canal radio entre la base et lui, noté Gf,m, et considère que le gain est le même dans l'autre sens.

Les paramètres classiques des boucles d'asservissement doivent alors être mis au point, à savoir : période 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 paramètres de l'asservissement sont choisis en fonction de l'environnement du système mobile considéré : caractéristiques du canal radio, type de données transmises, etc.

Un contrôle de puissance simple, parfois appelé Bang-Bang, consiste à transmettre un bit d'information, éventuellement répété 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 fixée à l'avance, suivant que la qualité reçue est inférieure ou supérieure à un seuil requis. En pratique, la valeur fixe de la variation est de l'ordre de 1 dB (voir paragraphe 4.5).

Mobile

Figure 4.4. Contrôle de puissance en boucle ouverte


V*. ' Boucle interne (inner loop)

Boucle externe (external loop)

Figure 4.5. Principe général du contrôle de puissance par boucle externe et boucle interne

Nous montrons dans [NUA 01] que si les paramètres du contrôle de puissance à un bit d'information (période de mise à jour, pas de puissance, protection contre les erreurs de transmission) sont correctement sélectionnés, ce dernier peut avoir des résultats proches du DPC rappelé au début de ce paragraphe et par suite avoir des performances proches de celles considérées optimales.

Il peut être avantageux d'utiliser une double boucle de contrôle de puissance. Cela est le cas dans les systèmes de réseaux cellulaires de troisième génération. Le schéma de principe des boucles de contrôle de puissance de ces réseaux est représenté dans la figure 4.5.

La boucle interne est celle décrite précédemment. Son but est d'asservir le rapport signal sur bruit SIR reçu à une valeur-seuil fixée (SIRTarget)- Cette valeur-seuil est fonction du taux d'erreur binaire BER qui doit être réalisé. La relation entre SIR et BER est fonction des caractéristiques de modulation, de codage et aussi du canal radio (nombre de trajets multiples, etc). Or les communications dans un réseau cellulaire utilisent des canaux radio différents. La boucle de contrôle externe calcule la valeur seuil au lieu de prendre la même valeur pour toutes les communications, ce qui reviendrait à prendre la valeur la plus pessimiste. Cela permet de diminuer les interférences dans un réseau et par suite permet d'avoir une plus grande capacité.

M


Boucle externe (external loop)

Figure 4.5. Principe général du contrôle de puissance par boucle externe et boucle interne

Nous montrons dans [NUA 01] que si les paramètres du contrôle de puissance à un bit d'information (période de mise à jour, pas de puissance, protection contre les erreurs de transmission) sont correctement sélectionnés, ce dernier peut avoir des résultats proches du DPC rappelé au début de ce paragraphe et par suite avoir des performances proches de celles considérées optimales.

Il peut être avantageux d'utiliser une double boucle de contrôle de puissance. Cela est le cas dans les systèmes de réseaux cellulaires de troisième génération. Le schéma de principe des boucles de contrôle de puissance de ces réseaux est représenté dans la figure 4.5.

La boucle interne est celle décrite précédemment. Son but est d'asservir le rapport signal sur bruit SIR reçu à une valeur-seuil fixée (SIRTarget). Cette valeur-seuil est fonction du taux d'erreur binaire BER qui doit être réalisé. La relation entre SIR et BER est fonction des caractéristiques de modulation, de codage et aussi du canal radio (nombre de trajets multiples, etc). Or les communications dans un réseau cellulaire utilisent des canaux radio différents. La boucle de contrôle externe calcule la valeur seuil au lieu de prendre la même valeur pour toutes les communications, ce qui reviendrait à prendre la valeur la plus pessimiste. Cela permet de diminuer les interférences dans un réseau 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 imbriquées, la boucle interne doit être bien plus rapide que la boucle externe. Comme ordre de grandeur, le temps de montée de la boucle interne doit être de l'ordre de dix fois plus petit que celui de la boucle externe. On pourra vérifier que cette hypothèse est vérifiée dans les systèmes 3G dans la suite de ce chapitre. La boucle interne est d'ailleurs souvent appelée contrôle de puissance rapide {fast power control).

4.3. Contrôle de puissance et autres fonctions de la gestion des ressources radio

Dans un réseau mobile, la procédure de contrôle de puissance ne peut être dissociée des autres procédures de gestion de ressources radio. Cela est d'autant plus vrai dans les réseaux mobiles à accès multiple CDMA, où la capacité est souvent limitée uniquement par l'interférence et non par le nombre de canaux disponibles comme dans le cas de GSM. La gestion de ressources radio dans un réseau cellulaire est illustrée dans la figure 4.6.

4.3.1 .Accès et contrôle d'admission

Le contrôle d'admission est intimement lié au contrôle de puissance. En effet, la décision sur l'admission doit respecter les contraintes suivantes :

- u n mobile dont l'admission aboutirait à un réseau impossible à contrôler en puissance doit être refusé. Un réseau est dit impossible à contrôler en puissance lorsqu'il n'existe pas de répartition de puissances émises telle que tous les objectifs de qualité sont atteints. Si ce mobile était accepté, il faudrait alors, pour diminuer l'interférence globale, interrompre une communication, éventuellement différente de celle du nouvel arrivant ;

- un mobile dont l'admission aboutirait à un réseau qu'il est toujours possible de contrôler en puissance ne doit pas être refusé.

On peut remarquer que l'interruption d'une communication en cours est plus gênante que le refus de communication du point de vue des usagers.

Plusieurs algorithmes de contrôle d'admission sont proposés pour les réseaux CDMA. Ils sont rappelés dans [NUA 00], où ils sont répartis sur trois groupes : ceux basés sur le niveau d'interférence, ceux basés sur l'estimation du nombre maximal de communications simultanées et ceux basés sur la prévision de la possibilité de réalisation du contrôle d'admission après éventuelle admission du ou des nouveaux venus.


Pour un mobile qui souhaite commencer une communication, un contrôle de puissance doit être défini pour la période 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 réseau mobile

Dans le cadre du contrôle d'admission, le débit de données doit être sélectionné. Dans le cas où le réseau ne peut assurer le débit de données souhaité, un débit plus faible sera choisi. Il faut éventuellement vérifier que ce débit imposé n'est pas inférieur au débit minimal du mobile ou du service considéré. Un débit plus bas permet d'avoir un objectif de SIR plus faible, voir relation [4.4].

4.3.2. Respiration de cellules

Une façon 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 reçu par ce dernier. En prenant la station de base avec le meilleur signal pilote et si on suppose que cette dernière est la plus proche d'un mobile donné, nous obtenons alors des cellules symétriques, de formes hexagonales, suivant le modèle classique des réseaux cellulaires [LAG 00].

Cependant, en pratique, la station de base ayant le signal pilote le mieux reçu par un mobile donné n'est pas nécessairement la plus proche en raison des obstacles qui


peuvent exister entre un mobile et les stations de base. Les cellules auront donc des formes aléatoires tout en restant proches du modèle hexagonal.

Une façon plus efficace de choisir la station de base pour chaque mobile consiste à le faire suivant des critères autres que celui du signal reçu. Il est plus efficace de choisir la station de base de correspondance de chacun des mobiles actifs de façon à avoir une meilleure capacité globale, à chaque instant. On peut remarquer que, si ce principe est appliqué, un mobile se trouvant à une position géographique donnée peut appartenir à une cellule qui n'a pas le meilleur signal dans sa position. Autrement dit, les cellules changent de surface de manière à s'adapter à la charge de trafic du réseau.

Dans deux articles [HAN 95] et [YAT 95], publiés indépendamment et en même temps, l'association du choix de la station de base à la gestion des ressources radio est proposée pour augmenter la capacité d'un réseau mobile. En raison de la variation dynamique de la surface des cellules qui en résulte, l'appellation de respiration de cellules (cell breathing) a été proposée pour ce concept d'optimisation du choix de la station de base de correspondance [HAN 95]1.

En vue d'illustrer le principe de la respiration de cellules, nous considérons 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

Figure 4.7. Utilité de la respiration de cellules

1. Le terme respiration de cellules dans les réseaux de communications cellulaires a d'autres compréhensions possibles.


la cellule de droite est beaucoup plus chargée que celle de gauche, si le mobile qui est dans la première tout en étant proche de la frontière est rattaché à la cellule de gauche, le niveau global d'interférence baisse. Une baisse de l'interférence globale est équivalente à une augmentation de la capacité dans un réseau cellulaire CDMA.

Dans le cadre de la respiration de cellules, la sélection de station de base est associée au contrôle de puissance. En résumé, l'algorithme DPC déjà introduit dans ce chapitre est généralisé de façon à choisir, à chaque itération, la station de base qui minimise la puissance émise calculée par la version initiale du DPC en plus de cette puissance à émettre.

4.3.3. Contrôle 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 : amélioration de la qualité de communication des mobiles frontaliers, diminution de la probabilité de coupure lors d'un handover, etc. Il représente un des intérêts majeurs du CDMA. Dans certaines configurations, le soft handover peut être un état stable si le mobile reste dans une zone frontalière.

Dans la voie montante, la procédure de contrôle de puissance d'un mobile peut envoyer deux ordres contradictoires de deux stations de base différentes. 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 indépendamment. Dans ce cas, le mobile applique l'ordre qui aboutit à une puissance de transmission minimale. Cela permet de ne pas augmenter inutilement l'interférence globale tout en garantissant la qualité de communication requise, puisqu'au moins l'une des stations de base a son ordre exécuté.

4.4. Le contrôle de puissance dans les systèmes 3G

Le contrôle de puissance du système cellulaire de deuxième génération GSM, qui est un système F/TDMA, est moins complexe que celui des systèmes 3G, qui sont du type CDMA. Le contrôle de puissance de GSM est décrit dans [LAG 00]. Dans la partie restante de ce chapitre, nous donnons des éléments sur le contrôle de puissance des systèmes UTRA-FDD et cdma2000. Ces deux réseaux CDMA ont chacun un contrôle de puissance respectant les principes généraux rappelés dans la première partie de ce chapitre. Au niveau de ce chapitre le contrôle de puissance du système WCDMA est décrit plus longuement que celui de cdma2000. Pour des


détails spécifiques sur un contrôle de puissance donné, le lecteur est invité à se reporter aux spécifications référencées dans ce chapitre.

Erreur de trame? 0: augmenter SIRT de Kc6 dB N: baisser SIR, de ô dB

Figure 4.8. Contrôle de puissance des systèmes 3G

Le principe général commun du contrôle de puissance de ces systèmes est représenté dans la figure 4.8. Un contrôle de puissance combinant deux boucles fermées est utilisé en même temps qu'un contrôle à boucle ouverte. Ce dernier est souvent réservé à l'accès initial, où il n'y a pas de retour. Dans la figure 4.8, deux exemples particuliers de contrôle de puissance sont utilisés :

- boucle interne de contrôle de puissance ; - boucle externe de contrôle de puissance.

La boucle interne, servant à l'asservissement du SIR, est pratiquement toujours une boucle à un bit d'information. Nous avons aussi représenté 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 paramètre Kc. Le lecteur peut vérifier que, en régime permanent, la valeur réalisée de FER s'exprime de façon simple en fonction de Kc :

quelle que soit la valeur de ô choisie.


4.5. Contrôle de puissance en UTRA-FDD

4.5.1. Principes généraux

L'UTRA (UMTS Terrestrial Radio Access), le système d'accès radio de UMTS-WCDMA, détaillé dans les spécifications 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 différents [HOL 02].

Le contrôle de puissance de UTRA-FDD est décrit dans la spécification TS 25.214 du consortium 3GPP [25214]. Certains détails supplémentaires sur la mise en œuvre peuvent être trouvés dans la TS 25.211. D'autres spécifications contiennent des détails supplémentaires sur le contrôle de puissance de UTRA-FDD.

4.5.1.1 Boucle interne de contrôle de puissance

La trame des canaux physiques dédiés de la voie descendante (« trame radio downlink ») du UTRA-FDD est représentée dans la figure 4.9. Une trame est formée de 15 TS {Time Slots, intervalles de temps). La durée d'une trame est 10 ms. Chacun des TS contient une information binaire appelée TPC (Transmission Power Control) et réalisant le contrôle de puissance de la boucle interne de la figure 4.8. Cela correspond à un débit de contrôle 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 contrôle de puissance peut être répété une fois dans les trames de la voie montante (voir figure 4.9, NTPC = 1 ou 2). Le lecteur attentif sait à présent que cette information binaire transmise sur la voie montante représente les informations du contrôle de puissance de la voie descendante. A son tour, le bit de contrôle de puissance transmis sur la voie descendante peut être répété 1, 3 ou 7 fois (.NTPC = 2, 4 ou 8).

La boucle interne de contrôle de puissance se trouve dans le nœud B pour le contrôle de puissance de la voie montante. Le nœud B (station de base) décide, à partir de la qualité reçue 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 utilisées (voir ci-dessous). Nous avons étudié les conséquences de l'utilisation d'un pas de contrôle de puissance adaptatif dans [NUA 02]. La variation dynamique de ce pas, en accord


avec la vitesse de convergence du contrôle, 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 dédiés de la voie descendante (« trame radio downlink ») du UTRA-FDD {figure extraite de TS 25.211)

Le contrôle de puissance rapide est prévu pour les canaux de données (voies montante et descendante) ainsi que certains canaux de contrôle.

4.5.1.2. Boucle externe de contrôle de puissance

La boucle externe détermine de façon dynamique l'objectif de qualité à réaliser (le SIRTarget) pour la boucle interne de contrôle de puissance (voir figure 4.8). Ce contrôle est réalisé dans le S RNC (Serving RNC) pour le contrôle de puissance de la voie montante. Pour la voie descendante, c'est aussi le SRNC qui détermine l'objectif de qualité en se basant sur le rapport de qualité remonté par le UE [CAS 02]).

4.5.1.3. Contrôle de puissance et soft handover

Dans l'état de soft handover, une station mobile est en liaison avec deux stations de base (nœud B ou Node B) pour sa communication en voie descendante, en voie montante ou pour les deux voies. Le problème du contrôle de puissance durant l'état de soft handover est différent 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 reçu par deux ou plusieurs stations différentes. Il est donc possible, à un instant donné, que toutes ces stations n'envoient pas le même ordre de contrôle de puissance (+1 ou -1). Dans ce cas, il est évident qu'au moins un nœud B


demande au mobile de décrémenter sa puissance d'émission ; le mobile baisse alors sa puissance du pas de contrôle de puissance prévu. Si les commandes sont unanimes, l'ordre commun est appliqué. Les spécifications de l'UMTS proposent des règles plus fines que celles ci-dessus dans le cas où les commandes de contrôle de puissance ne sont pas considérées fiables [25.214].

Pour la voie descendante d'un mobile en soft handover, la station mobile reçoit les signaux émis par deux ou plusieurs stations différentes. Si les stations de base concernées mettent à jour la puissance prévue pour cette station mobile de façon indépendante, il existe un risque que les différentes puissances d'émission augmentent ou diminuent de façon incontrôlée. Ce phénomène est appelé power drifting [HOL 02]. Ce risque est augmenté avec les erreurs de transmission des ordres de contrôle de puissance. Il est évité grâce à la centralisation des ordres de contrôle de puissance, c'est-à-dire les ordres du mobiles, dans un RNC.

4.5.1.4. Contrôle de puissance et mode de transmission compressé

Le système UMTS a prévu la possibilité de mesurer les signaux de systèmes différents (par exemple, GSM) opérant sur des fréquences différentes de celle de l'UMTS. Ces mesures peuvent être faites pendant des trous de transmission de données prévus 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 appliquées pour le contrôle de puissance de manière à rétablir l'objectif de SIR après les trous de transmission. En effet, durant ces trous de transmission, le contrôle de puissance perd son utilité ainsi que son efficacité. [25.214] propose une nouvelle valeur à l'objectif de SIR utilisé dans l'algorithme de contrôle de puissance, SIRcm target> SIR target en mode compressé. La valeur de SIRcm target est supérieure à SIRT, utilisée en mode normal. Elle est fonction des paramètres du mode compressé. Il est également possible de prendre un pas de variation de la puissance émise supérieur à celle utilisée en mode normal.

4.5.1.5. Contrôle de puissance et mode de sélection 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 utilisées pour le SSDT sont transmises dans le champ FBI du canal de contrôle de la voie montante DPCCH. Quand le mode SSDT est appliqué, seul le nœud B ayant le meilleur signal au mobile considéré (appelé primary cell) envoie son canal de données (DPDCH) et son canal de contrôle (DPCCH). Les autres

I


nœuds B de Y active set émettent uniquement leur canal de contrôle. C'est au mobile de préciser à l'UTRAN quel est le nœud B de Y active set qu'il reçoit le mieux. Un des avantages possibles du soft handover, la sélection du meilleur site (site selection) est donc réalisée par le mobile. L'UTRAN peut aussi utiliser les informations remontées dans le cadre du SSDT pour le contrôle de puissance du canal de transmission partagé PDSCH [25.214].

La station mobile générera les commandes de contrôle de puissance en voie montante en se basant sur le signal reçu de la primary cell, la seule cellule dans Y active set qui envoie un canal de données.

En ce qui concerne le contrôle de puissance de la voie descendante lorsque le SSDT est appliqué, les procédures du mode normal sont utilisées pour la primary cell ainsi que les autres cellules. Comme prévu dans le SSDT, la transmission est désactivée dans ces dernières durant les instants réservés au canal de données.

4.5.2. La voie montante (uplink)

Le contrôle de puissance le plus important est celui qui concerne le canal DPCH, constitué des canaux DPDCH et DPCCH. Ce dernier représente la majorité des signaux UMTS émis. Le contrôle de puissance du canal de contrôle (DPCCH) ainsi que le canal de données associé (DPDCH), lorsque ce dernier existe, se font conjointement. Dans le cas de la voie montante, le DPDCH peut être désactivé durant le mode compressé ou lors d'un transmission discontinue (DTX).

4.5.2.1. Contrôle de puissance en boucle fermée (ou contrôle de puissance rapide)

L'objectif du contrôle de puissance en boucle ouverte est donc de réaliser à chaque instant l'objectif de SIR, noté SIRT (voir figure 4.8). Dans la suite, nous considérons un mobile en communication avec un nœud B. Le cas où le mobile est en lien avec deux ou plusieurs nœud B (soft handover) a déjà été décrit au début de ce paragraphe.

Un rapport de puissance est défini entre DPDCH et DPCCH. Il est codé sur 4 bits et a donc 16 valeurs possibles. Ce rapport (transmit power offset) est sélectionné par le réseau et, éventuellement, changé par ce dernier. Une fois ce facteur connu, la mise à jour de la puissance émise du DPCCH aura une conséquence directe sur celle du DPDCH.

Le débit des ordres de contrôle 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


nœud B estime le SIR reçu du DPCH et génère cette information de contrôle de puissance qui sera transmise dans le champ TPC de la voie descendante. La valeur du bit généré est la suivante :

- s i SIRESR> SIRT, le bit d'information du champ TPC (ordre de contrôle de puissance) est égal à 0 ;

- s i SIResl<SIRT, le bit d'information du champ TPC (ordre de contrôle de puissance) est égal à 1.

La spécification TS 25.214 (Release 5, mars 2003) ne précise pas quelle est la valeur si SIRest = SIRT.

Suivant la valeur de TPCcmd, la puissance d'émission de l'UE est incrémentée (TPCcmd = 1), diminuée (TPC cmd = - 1) ou inchangée pour chaque time slot de durée 10/15 ms.

Figure 4.10. Principe général des algorithmes de contrôle de puissance de la voie montante de l'UMTS

La station mobile (UE) reçoit les informations TPC et doit en déduire 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 décision peut être faite suivant l'un des deux algorithmes proposés par le système UMTS. Un paramètre sélectionné par les couches plus hautes, PC A (Power Control Algorithm), indique l'algorithme à choisir : algorithme 1 ou algorithme 2. Le principe de cette décision est illustré dans la figure 4.10.

Dans l'algorithme 1, la puissance d'émission est augmentée ou diminuée à chaque time slot. Le paramètre 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 incrémentée ou diminuée une seule fois dans chaque séquence de cinq slots. Une trame UTRA-FDD est découpée en trois séries de cinq slots dans le cadre de l'algorithme 2. Ainsi, TPC_cmd (voir figure 4.10) prend la valeur 0 pour 4 slots consécutifs et pourra prendre la valeur -1 ou +1 au maximum trois fois sur une trame donnée. Sur le cinquième slot de la séquence, TPC_cmd est déterminée selon les règles suivantes :

- si les 5 informations TPC de la séquence sont égales à 1, alors TPC_cmd = 1 ; - si les 5 informations TPC de la séquence 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 déduite suivant les règles données au début 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 considérer, ce qui n'est pas entièrement 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 généralement, à 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 sélectionnée par l'UTRAN pour l'algorithme 1. Les valeurs possibles, pour UTRA-FDD, sont 1 et 2 dB [25.331].

Le contrôle de puissance de la voie montante ne doit pas aboutir à une puissance d'émission inférieure à un minimum autorisé ou supérieure à un maximum autorisé. Ces valeurs sont données 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 données par les spécifications.

Notons qu'un contrôle de puissance en boucle fermée est défini pour le canal PCPCH [25.214], en plus de ceux des canaux dédiés des voies montante et descendante (DPCCH et DPDCH).


4.5.2.2. Contrôle de puissance en boucle fermée externe (ou contrôle de puissance lent)

Le contrôle 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 à réaliser, le SIRT, à la boucle interne située dans le nœud B.

Le contrôle de puissance en boucle fermée externe est un protocole de niveau 3 (RRC, Radio Resource Control). La spécification TS 25.214 précise que l'objectif de SIR est donné par les couches supérieures. Ces derniers appliquent la boucle externe de puissance mentionnée ci-dessus. Cet objectif de SIR peut être mis à jour toutes les 10 ms [25.302], c'est-à-dire avec une fréquence maximale de 100 Hz. Un exemple de boucle externe de puissance est indiqué dans la figure 4.8.

4.5.2.3. Contrôle de puissance en boucle ouverte

Le contrôle de puissance en boucle ouverte est utilisé pour l'accès initial de la station mobile (UE). Ce contrôle se base sur les mesures faites par l'UE ainsi que les informations diffusées par le système.

Les canaux physiques utilisables en voie montante PRACH et PCPCH sont les canaux utilisés pour l'accès aléatoire des mobiles. Pour utiliser le PRACH, un mobile choisira aléatoirement un slot du PRACH et une puissance initiale donnée par l'UTRAN. Le mobile essaiera à nouveau avec une puissance incrémentée à chaque fois tant qu'il n'a pas reçu une indication confirmant son accès. La puissance est incrémentée par un coefficient imposé par la couche RRC, le power ramp step.

La puissance d'émission initiale DPCCH en voie montante est sélectionnée par les couches supérieures [25.214], Il s'agit donc, en quelque sorte, d'un contrôle de puissance supplémentaire, en boucle ouverte, donnant la première puissance d'émission du mobile avant d'appliquer le contrôle de puissance en boucle fermée. Certains détails supplémentaires sur le contrôle de puissance en boucle ouverte peuvent être trouvés dans [25.101].

4.5.3. La voie descendante (downlink)

La figure 4.11 montre l'interférence entre les liaisons de la voie descendante. On peut dire que l'objectif du contrôle de puissance de la voie descendante sera de répartir les puissances de sorte que les mobiles qui sont aux frontières des cellules ne soient pas trop pénalisés.


Dans la voie descendante, l'orthogonalité est préservée 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 réception. Cependant, elle permet à la voie descendante d'avoir des conditions plus favorables que la voie montante. Les seuils de SIR à réaliser seront globalement plus faibles.

Le contrôle de puissance de la voie descendante de l'UTRA-FDD reprend les mêmes principes que celui de la voie montante (voir plus haut). Certaines variantes interviennent pour tenir compte des différences entre la voie descendante et la voie montante. Dans ce sous-paragraphe, nous donnons quelques aspects propres au contrôle de puissance de la voie descendante de l'UTRA-FDD, en particulier lorsqu'il s'agit de paramètres ou procédés différents de ceux du contrôle de puissance de la voie montante de l'UTRA-FDD décrit dans le sous-paragraphe précédent.


Le rapport entre la puissance d'émission du canal dédié de contrôle (DPCCH) et celle du canal dédié de données (DPDCH) est déterminé par l'UTRAN. Dans la voie descendante, ces deux canaux sont multiplexés 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 paramètres POl, P02 et P03 (en dB) respectivement [25.214]. Ces rapports peuvent varier avec le temps.

Figure 4.11. Interférences dans le cas de la voie descendante d'un réseau cellulaire CDMA


Le mode DPC MODE= 0 est équivalent à l'algorithme 1 du contrôle de puissance de la voie montante, c'est-à-dire que l'information TPC (0 ou 1) est appliquée pour la puissance émise en voie descendante, lors de chaque slot. Cette puissance est alors augmentée ou diminuée du pas de variation de puissance.

Avec le mode DPC MODE = 1, la puissance d'émission est changée une fois tous les 3 times slots (3xl0/15ms) . En effet, la station mobile, voyant que DPC MODE est à 1, répète l'information de TPC (0 ou 1) sur trois slots consécutifs.

Comme pour la voie montante, le récepteur, c'est-à-dire la station mobile, estime le SIR reçu. Il compare ensuite cette valeur estimée au SIR seuil (SIRT) pour déduire l'information de TPC à envoyer dans chaque slot (voir paragraphe 4.5.1).

Un équilibrage de puissance {power balancing) est prévu. Lorsque le pas de variation de puissance est ajouté ou soustrait, un autre terme est ajouté à la nouvelle puissance d'émission. La procédure de calcul du terme correspondant au power balancing est donnée 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'incrémentation de la puissance d'un pas fixe peut être inhibé et la puissance d'émission en voie descendante est alors inchangée sur le slot. Cette inhibition a lieu quand l'historique des variations de puissance sur une fenêtre donnée dépasse une limite donnée.

Pour finir avec la boucle fermée interne de contrôle de puissance de la voie descendante, il est prévu dans le système 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 contrôle de puissance autres que les deux proposés ci-dessus. Comme pour la voie montante, le contrôle de puissance de la voie descendante ne doit pas aboutir, pour un nœud B donné, à une puissance d'émission inférieure à un minimum autorisé ou supérieure à un maximum autorisé.


Comme pour la voie montante, un contrôle de puissance en boucle externe (outer loop power control, voir figure 4.8) est appliqué. Il est situé dans le mobile mais le réseau, c'est-à-dire le SRNC, peut changer des paramètres. Ce contrôle de puissance va fournir l'objectif de SIR à réaliser, le SIRT, à la boucle interne située dans le nœud B. Ce contrôle de puissance est un protocole de niveau 3 (RRC, Radio Resource Control).


4.5.3.3. Contrôle de puissance en boucle ouverte

Le contrôle de puissance en boucle ouverte sur la voie descendante est utilisé pour déterminer la puissance d'émission initiale des canaux dédiés en fonction des mesures remontées par le UE. Comme pour la voie montante, il s'agit donc en quelque sorte de donner la première puissance d'émission du mobile avant d'appliquer le contrôle de puissance en boucle fermée.

4.6. Contrôle en UTRA-TDD

4.6.1. Rappels sur UTRA-TDD

Le mode UTRA-TDD (Time-Division Duplexing) considère le cas où les deux voies de communication (montante et descendante) utilisent chacune tout le spectre alloué, à des intervalles de temps différents (voir chapitre 3). Cela laisse la possibilité d'avoir une répartition non symétrique de la bande de fréquence, ce qui peut représenter une utilisation plus efficace de cette dernière dans le cas des transmissions de données. Dans la trame de 15 slots sur 10 ms de UTRA-TDD, n slots seront utilisés pour la voie descendante et 15 - n pour la voie montante.

Le contrôle de puissance de UTRA-TDD est décrit dans la spécification TS 25.224 du consortium 3GPP [25.224]. Certains détails supplémentaires sur la mise en œuvre peuvent être trouvées dans la TS 25.221. Des paramètres relatifs aux contrôles de puissance et situés au niveau des émetteurs et des récepteurs, comme les valeurs minimales et maximales des puissances, le pas de variation des puissances émises,..., peuvent être trouvés dans [25.102].

Les canaux physiques dédiés (DPCH) ainsi que le canal à accès aléatoire (PRACH) sont obligatoirement contrôlés en puissance [HOL 02].

4.6.2. La voie montante (uplink)

Un contrôle de puissance en boucle ouverte est prévu [25.224]. La puissance d'émission de la base est diffusée par cette dernière. Le mobile peut alors estimer l'atténuation due à la liaison radio (path loss) de la voie descendante (voir section 4.2 et en particulier la figure 4.4). Cette valeur est supposée égale à celle de la voie montante. Nous la notons Lest.


Chaque mobile calcule et met à jour sa puissance d'émission en fonction du gain de liaison estimé.

Figure 4.12. Contrôle de puissance en boucle ouverte de la voie montante de UTRA-TDD

Ensuite, le mobile détermine 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'interférence reçue par la base (également diffusée par cette dernière), notée upnnk

[25.31]. La puissance d'émission est alors déduite à partir de la relation donnant le SIR reçu par la station de base de correspondance du mobile (puissances en valeurs réelles) :

Pe uplink. SIRinget=Cte- Lest

Iuplink [4.7]

où cette puissance est calculée de façon à avoir le SIR reçu égal à SIRtarget. La constante permet d'inclure une marge, de tenir compte du codage, du détecteur utilisé, etc.

Le principe du contrôle 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 dédié DPCH en voie montante est la suivante (tirée 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 durée de Lesh avec un coefficient de pondération 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 considérée bonne. Il peut être changé de façon dynamique par les couches supérieures. Le contrôle de puissance de la voie montante de UTRA-TDD est étudié dans [KUR 01], où l'importance du choix de SIRtarget ou, autrement dit, l'efficacité de la boucle externe de contrôle de puissance assurée par les couches supérieures, est soulignée.


La trame contient n (avec « = 1 1 , dans cet exemple) slots de transmission en voie descendante (slots downlink) et, par conséquence, 15 - n (donc 4, dans l'exemple) slots de transmission en voie montante (slots uplink). On voit que, pour l'exemple considéré, la fréquence de mise à jour du contrôle 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 contrôle de puissance [25.221] car le contrôle de puissance en voie montante se fait en boucle ouverte.

Figure 4.13. Trame UTRA-TDD et contrôle de puissance

4.6.3. La voie descendante (downlink)

Le même contrôle de puissance que pour UTRA-FDD est appliqué pour la voie descendante : association de boucle externe et de boucle interne de contrôle 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 sélectionnée par les couches supérieures [25.224].

4.6.4. Fréquences de mise à jour du contrôle de puissance de la voie descendante de UTRA-TDD

En vue de préserver la synchronisation et l'efficacité du contrôle de puissance, le système UTRA-TDD [25.221] impose un minimum de un slot de transmission en


voie montante par trame et un maximum de 13, ce qui est équivalent à un maximum de 14 slots et un minimum de deux slots pour la voie descendante par trame.

On a donc un débit minimal des commandes de contrôle de puissance transmises en voie montante et donc utilisées pour le contrôle de puissance de la voie descendante de 100 Hz (un slot par trame). La figure 4.13 montre une trame UTRA-TDD où la fréquence de mise à jour est de 400 Hz.

Le débit maximal de commandes de contrôle 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 contrôle de puissance ne sont donc plus utilisées. En effet, le lecteur pourra vérifier 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 contrôle de puissance par slot, on peut déduire que le débit des commandes de contrôle de puissance est entre 100 et 700 Hz pour la voie descendante de UTRA-TDD.

4.7. Contrôle de puissance dans la proposition cdma2000

Le principe de base du contrôle de puissance est le même pour cdma2000 et UTRA-FDD. Une boucle fermée est mise en œuvre pour les deux voies de communication : montante et descendante [CHU 00].

La durée d'une trame est de 20 ms pour les canaux de données dans le système cdma2000 [3GPP2]. Dans une trame, 16 groupes de contrôle de puissance (PCG, Power Control Group) sont prévus, chacun de ces groupes contenant 1 bit de contrôle de puissance. Ainsi, la fréquence des bits de contrôle de puissance est de 800 bit/s. Ceci est un débit nominal car une partie de la trame peut ne pas être transmise, ce qui aboutirait à une fréquence de bits de contrôle de puissance inférieure à 800 bit/s. Cette valeur de mise à jour du contrôle de puissance (800 bit/s) est du même ordre de grandeur que celle du système UTRA-FDD et le contrôle de puissance des deux systèmes est qualifié de rapide. Le pas de mise à jour des puissance émises dans cdma2000 est entre 0,25 et 1 dB.

Dans le système cdma2000, le contrôle de puissance en boucle fermée de la voie montante est associé à un contrôle de puissance en boucle ouverte. Le principe général est le suivant : si la puissance d'un signal pilote de la base, reçu en voie descendante, donc venant de la station de base, dépasse un certain seuil, la puissance en voie montante est modifiée en fonction de ce résultat.


4.8. Imperfection du contrôle de puissance

Mis en application, le contrôle de puissance présente plusieurs imperfections par rapport au concept théorique.

Les différentes boucles fermées de contrôle se basent sur le rapport signal sur bruit SIR reçu. L'estimation de ce dernier ne peut être totalement précise. Cette erreur d'estimation, si elle est trop importante, peut dégrader la boucle fermée d'asservissement de la puissance émise. La boucle ouverte de contrôle, quant à elle, se base sur l'estimation du gain du canal. Cette estimation présentera également une certaine erreur.

Les bits de commandes de contrôle de puissance, par exemple, un bit d'information toutes les 0,67 ms pour le système UTRA-FDD, peuvent subir des erreurs de transmission. Par exemple, un bit 0 transmis (« baissez la puissance de transmission de 1 dB ») et mal reçu, c'est-à-dire décodé comme étant 1 (« augmentez la puissance de transmission de 1 dB ») aboutira à l'effet inverse de celui escompté. Pour prévenir à ce genre de situation, le bit de contrôle de puissance peut être répété (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 contrôle de puissance.

Les autres problèmes classiques des boucles de contrôle numérique sont également à prendre en compte. Les puissances d'émission (terminaux ou stations de base) ont une plage limitée. A titre d'exemple, la puissance d'émission d'un terminal UMTS de Classe 3 [25.101] est limitée entre 24 dBm (0,25 W) et -50 dBm (10"8 W). Les commandes de contrôle de puissance (voir figure 4.5) ne seront pas appliquées instantanément. L'émission d'une commande et son application sont séparées au minimum par le délai aller-retour (round trip delay), correspondant à la transmission de la commande de contrôle de puissance et à l'émission des informations contrôlées en puissance. En toute rigueur, un élément retardateur devrait être inclus dans le schéma du contrôle de la figure 4.5.

Les commandes de contrôle de puissance deviennent inadaptées si le mobile se déplace trop rapidement. Cependant, les contrôles de puissance des systèmes 3G sont assez rapides pour des vitesses « raisonnables » de déplacement de mobiles. Il est bien entendu que les sources d'erreurs du contrôle de puissance données ci-dessus ne constituent pas une liste exhaustive.

Des marges ajoutées au seuil requis de qualité, une observation permanente du réseau mobile en vue de faire rapidement les mises au point nécessaires font que ces imperfections ne dégradent pas trop les résultats théoriques attendus du le contrôle de puissance.


4.9. Bibliographie

Les spécifications 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 », Télécommunications Industry Association, 2002.

[25.101] 3G TS 25.101 v4.0.0 (2001-03), « U E Radio Transmission and Reception (FDD) (Release 4) », 3rd Génération Partnership Project; Technical Spécification 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 Génération Partnership Project; Technical Spécification Group Radio Access Networks, 2001.

[25.214] 3G TS 25.214 v5.4.0 (2003-03), «Physical layer procédures (FDD) (Release 5)», 3rd Génération Partnership Project; Technical Spécification 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 Génération Partnership Project; Technical Spécification Group Radio Access Networks, 2003.

[25.224] 3G TS 25.224 v5.4.0 (2003-03), « Physical layer procédures (TDD) (Release 5) », 3rd Génération Partnership Project; Technical Spécification 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 Génération Partnership Project; Technical Spécification Group Radio Access Networks, 2001.

[25.331] 3G TS 25.331 v5.4.0 (2003-03), «Radio Resource Control (RRC); Protocol spécification (Release 5)», 3rd Génération Partnership Project; Technical Spécification Group Radio Access Networks, 2003.

[25.401] 3G TS 25.401 v4.0.0 (2001-03), « UTRAN Overall Description (Release 4) », 3rd Génération Partnership Project; Technical Spécification Group Radio Access Networks, 2001.

[25.433] 3G TS 25.433 v4.5.0 (2002-06), « UTRAN Iub Interface NBAP Signalling (Release 4) », 3rd Génération Partnership Project; Technical Spécification Group Radio Access Networks, 2002.

[ C A S 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 Conférence 2000 Fall, VTC2000F, 2000.

ftp://ftp.3gpp.org

http://www.3gpp2.org


[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 91] 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.

[HAN 95] HANLY S. V . , « An algorithm for combined cell-site selection and power control to maximize cellular spread spectrum capacity », IEEE Journal on selected areas in communications, vol. 13, n° 7, 1995.

[HOL 02] HOLMA H. , TOKSALA A . , WCDMA for UMTS, deuxième édition, Wiley, 2 0 0 2 .

[KUR01] KURJENNIEMI J. et al., «Convergence of UTRA TDD Uplink Power Control », IEEE Vehicular Technology Conférence 2001 Spring, VTC 2001 Spring, 2001.

[LAG 00] LAGRANGE X. , GODLEWSKI P., TABBANE S., Réseaux GSM, 5ème Ed. Hermès, 2000.

[LEE91] LEE W.C.Y., «Overview of cellular CDMA», IEEE Trans. on Vehicular Technology, vol. 40, n° 2, 1991.

[NUA 00 ] NUAYMI L. , GODLEWSKJP., MIHAILESCU C., « Call Admission Control Algorithm for Cellular CDMA Systems Based on Best Achievable Performance », IEEE Vehicular Technology Conférence 2000 Spring, VTC2000 Spring, 2 0 0 0 .

[NUA 01] NUAYMI L., Contributions sur les algorithmes de contrôle de puissance équilibrés dans les réseaux cellulaires, Rapport de thèse de l'Ecole Nationale Supérieure des Télécommunications (ENST), Paris, 2001.

[NUA 02 ] NUAYMI L. , LAGRANGE X . , GODLEWSKI PU., « A Power Control Algorithm for 3 G

WCDMA System », European Wireless 2002, 2 0 0 2 .

[VIT 94] VITERBI A . J . , VITERBI A . M . , ZEHAVI E. , « Other-cell interference in cellular power-controlled C D M A »; IEEE Trans. on Communications, vol. 4 2 . , n° 2 - 4 , 1994 .

[VIT 95] VITERBI A. J . , CDMA Principles of spread spectrum techniques, Addison-Wesley, 1995.

[YAT 95] YATES R . D. , HUANG C . - Y . , « Integrated power control and base station assignment », IEEE Trans. on Vehicular Technology, vol. 44, n° 3, Aug. 1995.

[ZAN 92] ZANDER J. , « Performance of optimum transmitter power control in cellular radio systems », IEEE Trans. on Vehicular Technology, vol. 41, n° 1, 1992.

[ZAN 92a] ZANDER J., « Distributed Cochannel Interference Control in cellular radio systems »,IEEE Trans. on Vehicular Technology, vol 41, n° 3, 1992.

Chapitre 5

Couverture d'un réseau cellulaire CDMA

5.1. Présentation du problème

Dans les réseaux UMTS, basés sur le mode d'accès multiple CDMA (Code Division Multiple Access) [VIT 95], la couverture est une notion complexe pour les raisons suivantes :

-el le dépend des interférences engendrées par l'ensemble des autres émetteurs, c'est-à-dire les autres stations de base ou les autres mobiles. Cette interférence dépend donc de la charge du réseau, cette charge étant variable avec le temps (« le réseau vit ») ;

- elle doit prendre en compte les algorithmes d'allocations de ressources radio, en particulier celui de contrôle de puissance ;

- elle dépend des débits de données dont dispose chacun des utilisateurs car les rapports signal sur interférence à atteindre sont d'autant plus élevés que le débit requis est élevé.

La couverture doit être calculée pour les deux voies : montante (uplink) et descendante {downlink). Cette estimation de couverture d'un réseau cellulaire CDMA est plus complexe que dans le cas d'un système F/TDMA comme GSM [MOU 00].

Chapitre rédigé par Loutfi NUAYMI.


En pratique, l'estimation de la probabilité de couverture d'un réseau cellulaire CDMA est faite pour une charge de réseau donnée, ou des données statistiques sur la charge, et des puissances maximales de station de base fixées. Le calcul exact de couverture doit prendre en compte l'ensemble des éléments précédents (interférences, contrôle de puissance, puissances maximales des transmetteurs) et il devient rapidement très complexe. En pratique, la couverture est déterminée à l'aide de modèles et d'approximations. Certains outils proposés, la validité des approximations et des résultats sont l'objet de ce chapitre.

Une présentation synoptique du problème est proposée dans la figure 5.1. Les principaux paramètres sont :

- les positions des stations de base (base stations ou BS) ; - les données ou cartes de trafic, exprimées en Erlang (charge moyenne, durée

moyenne d'un appel, etc.) ; - les données dites radio, incluant les différents paramètres techniques des

émetteurs ainsi que les détails des transmissions et les algorithmes d'allocation de ressources radio.

Une autre donnée fondamentale est le type de service : unique (téléphonie) ou plusieurs services (téléphonie, données, vidéo, Internet, etc).

L'estimation de la qualité est souvent faite à travers le rapport signal à bruit et interférences (SIR, Signal-to-Interference Ratio) reçu. Pour cette estimation, on a donc besoin des conditions et des modèles de propagation donnant la relation entre puissances émises et puissances reçues (gain de liaison) ainsi que des facteurs d'orthogonalité.

Les résultats 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 représentée par la probabilité qu'un point soit couvert. Ces calculs (et les tracés résultants) sont faits pour une répartition de trafic et une charge offerte données. Deux définitions peuvent être utilisées 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 supérieur à un certain seuil. Notons que, selon cette définition, un point couvert n'est pas sûr de pouvoir établir une communication. Cela est le cas si l'interférence est très proche d'un seuil correspondant à la saturation de la cellule, avant le début de la communication du mobile considéré ;

- couverture en disponibilité de communication : en chaque point de la zone, on cherche à calculer la probabilité que le SIR d'une communication établie entre un

Couverture d'un réseau cellulaire CDMA 189

mobile présent en ce point et sa base soit supérieure au SIR seuil, correspondant au seuil de qualité.

Figure 5.1. Position du problème du calcul de la couverture

Plusieurs méthodes sont proposées pour l'estimation de la couverture d'un réseau CDMA. Dans ce chapitre, nous nous proposons de décrire une méthode de simulation statique qui consiste à calculer les charges des cellules de façon itérative. Ce chapitre reprend principalement les travaux de Laiho, Walker et Novosad


([LAI 01, LAI 02] et les complète par des développements théoriques simples qui ont pour objet de mettre en évidence les principaux phénomènes physiques.

Le reste du chapitre est réparti de la façon suivante : la section 5.2 décrit le modèle utilisé et introduit quelques définitions. La section 5.3 passe en revue les premières méthodes proposées pour l'estimation simple (et par suite très approximative) de la capacité d'un réseau cellulaire CDMA. La section 5.4 (respectivement 5.5) présente les relations utiles pour l'étude du sens uplink (respectivement downlink). L'algorithme de calcul itératif des charges des cellules est présenté dans la section 5.6. Certains détails supplémentaires sur cet algorithme sont donnés dans la section 5.7, avant de conclure dans la section 5.8.

5.2. Modèle utilisé

Une représentation d'un réseau cellulaire CDMA et de l'interférence qui y existe est donnée dans la figure 5.2. Les notations utilisées sont regroupées à la fin du chapitre.

Dans le cadre d'un accès multiple CDMA, tous les signaux subissent un étalement de spectre. Soit R le débit de données avant étalement de spectre au cas où il est commun à toutes les communications. Ce débit est noté Rj pour l'usager i, lorsque les débits sont différents. Le débit numérique après étalement (débit des chips) est noté W. Ce dernier est considéré égal à la bande de fréquence (en Hz) occupée 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 considéré est la somme de l'interférence due aux autres communications et du bruit thermique de réception.

Pour la liaison descendante (downlink), l'égalité devient une inégalité dans la relation [5.1] :


[5.2]

en raison de l'orthogonalité entre les communications des mobiles d'une même cellule. La relation ci-dessus redevient une égalité si le facteur d'orthogonalité est pris en compte dans le calcul du SIR des liaisons downlink (voir sous-paragraphe 5.5.2). Dans tous les cas, le fait de remplacer l'inégalité de [5.2] par une égalité revient à considérer une hypothèse (éventuellement) pessimiste.

Figure 5.2. Etude de la liaison montante (uplink) : une communication donnée (en traits continus) reçue sur sa base de rattachement subit l'interférence

due à d'autres communications intracellulaires et inter-cellulaires.


5.3. Estimation simple de la capacité d'un réseau cellulaire CDMA

Le problème de l'estimation de la capacité d'un réseau cellulaire CDMA a suscité une attention particulière dès le début des années 90, époque où le CDMA, mode d'accès réservé jusque-là aux militaires depuis ses premières applications dans les années 50, a été pressenti pour les réseaux de téléphonie mobile civils ([GIL 91, LEE 91]).

Les premières études cherchaient à estimer le nombre maximal de communications simultanées ayant le même débit de données (téléphonie). Le rapport énergie sur bit sur la densité spectrale du bruit correspondant au seuil de qualité (Eh/N0)T est un paramètre 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 utilisés, l'environnement radio, etc.

Pour le sens uplink, nous notons fi le rapport de l'interférence externe sur celle interne pour une station de base j (voir équation 5.6). Ce facteur est calculé dans [VIT 91]. Dans un réseau cellulaire de type hexagonal, sa valeur moyenne estimée 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 (idéalement égal au nombre de secteurs par cellule) et (Eb/N0)T le seuil (threshold) souhaité pour le rapport énergie sur bit sur la densité spectrale du bruit (supposé être le même pour tous les mobiles, dans ce chapitre), dans le sens uplink.

Les méthodes ci-dessus permettent une première estimation, très approximative, de la capacité d'un réseau cellulaire CDMA. Des méthodes plus fines sont proposées dans le but de calculer la couverture du réseau. Entre autres, des calculs de couverture plus précis, basés sur le rapport des interférences, ont été proposés. Ces calculs font intervenir les probabilités et les statistiques d'interférences (pour les notions de Erlang capacity et de télétrafic, voir [COR 98, VIT 93]).

La méthode dite du type Monte-Carlo consiste à faire un calcul de couverture pour une configuration précise sur des tirages aléatoires et à répéter le calcul sur un grand nombre de configurations. Les moyennes des résultats obtenus donnent alors


la couverture exprimée en probabilité de réalisation d'un SIR donné, par exemple. La méthode Monte-Carlo exige un nombre relativement élevé de calculs et, par suite, des temps de simulation relativement longs, si on souhaite avoir des résultats stables (voir, par exemple, [JON 00]).

Une possibilité intéressante serait de trouver des méthodes plus sophistiquées que la méthode Monte-Carlo nécessitant des temps de simulation plus courts que cette dernière tout en ayant des résultats plus ou moins précis (c'est-à-dire proches de ceux de la méthode Monte-Carlo).

Dans la suite de ce chapitre, nous décrivons un algorithme qui consiste à calculer de manière itérative la charge de chaque cellule dans un réseau cellulaire CDMA pour ensuite en déduire la couverture de ce réseau.

5.4. Définitions et relations utiles pour la liaison uplink

L'algorithme de prévision de la couverture d'un réseau CDMA par calcul itératif des charges des cellules est proposé pour la première fois dans [WAC 99]. Il est aussi décrit dans [HOL 02] et [LAI 99]. Une synthèse est proposée dans le chapitre 3 de [LAI 02].

Dans un réseau cellulaire CDMA, la charge d'une cellule, l'augmentation du bruit dans cette dernière, les puissances émises et les interférences moyennes externes à chaque cellule sont liées. La connaissance de ces interférences (ou, de manière équivalente, de leurs coefficients) permet de déduire la couverture à partir de ces moyennes. Dans la suite, ces relations sont détaillées et l'algorithme décrit.

5.4.1. Définitions

5.4.1.1. Couverture

Plusieurs définitions peuvent être utilisées. Dans la suite et sauf mention du contraire, un point de la zone de service est couvert à un instant / si le SIR reçu en ce point est supérieur 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 reçu

Le SIR reçu est donné par la relation suivante :


où N est le nombre total de mobiles actifs dans la zone couverte. Dans le cas particulier du downlink, des coefficients d'orthogonalité, idéalement égaux à zéro, peuvent être appliqués aux puissances des communications ayant lieu dans la même cellule (voir section 5.5).

5.4.1.3. Facteur de charge d'un usager en une cellule donnée

Pour une base donnée j et pour un usager /, le facteur de charge {user load factor) est défini comme le rapport de la puissance venant du mobile i sur la puissance totale reçue à la station de base j considérée :

R.J,I n ULj,i ~

ZPr.i,k+NThJ k=\

C

[5.3]

5.4.1.4. Facteur de charge d'une cellule

Il est intéressant de considérer 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 défini comme le rapport de la puissance totale reçue par cette dernière (y compris celle venant des usagers en dehors de la cellule) sur le bruit thermique qu'elle reçoit. Ainsi la puissance totale reçue peut être représentée comme une augmentation du bruit thermique reçu en l'absence de toute communication :

[5.5]


On peut vérifier que le NR représente le rapport de la somme (puissance utile pour une communication donnée + interférence des autres usagers + bruit thermique) sur le bruit thennique.

5.4.1.6. Rapport d'interférences fi de la base j

Le rapport d'interférences fi correspond au rapport entre l'interférence externe et l'interférence interne à la réception de la station de base j. Il s'agit donc la somme des puissances reçues depuis les mobiles des zones de service voisines sur la somme des puissances reçues des mobiles de la zone de service étudiée. Ce rapport est donné par l'expression suivante :

[5.6]

où bj désigne la station de base avec laquelle correspond le mobile /'. Des calculs de valeurs moyennes de ce coefficient sont proposés dans [VIT 91 ] ainsi que dans [COR 98] et [CHE 96], Nous avons déjà 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 géographique incluant tous les points de trafic pris en charge par la station étudiée. Elle comprend la zone dans laquelle la station est meilleur serveur (champ reçu diminué de la marge d'interférence) 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'après la définition [5.4], le facteur de charge d'une cellule peut être réécrit :

soit, par définition du facteur de charge individuel :


En utilisant le rapport d'interférence, on en déduit d'après [5.6] :

On a donc :

[5.7] En pratique, les valeurs de r j ^ peuvent facilement dépasser 0,9. Pour une cellule donnée, l'augmentation de bruit est directement liée au facteur

de charge. Pour établir la relation liant les deux quantités, il suffit de réécrire l'expression donnant Af/ên [5.5] comme suit :

On voit apparaître dans le dénominateur la définition du facteur de charge pour une cellule (en utilisant [5.3] et [5.4]) :

[5.8]

Cette expression fait apparaître que le facteur de charge doit toujours être inférieur strictement à 1 pour être dans les conditions de fonctionnement du système. Le cas où le facteur de charge est égal à 1 correspond à la capacité pôle, c'est-à-dire la capacité maximale qu'on ne peut ni dépasser, ni même atteindre. En effet, lorsque


le facteur de charge d'une cellule tend vers 1, son facteur d'augmentation de bruit tend vers l'infini.

5.4.2.2. Relation entre facteur de charge et rapport signal sur bruit (SIR) reçu :

Il est possible d'exprimer le rapport signal sur bruit (SIR) en fonction du facteur de charge de façon très simple. Sur la voie montante, le SIR reçu pour le mobile i correspondant avec la base j est noté y, et est donné par la relation suivante :

[5.9]

On peut réécrire cette définition en la modifiant très légèrement :

[5.10]

On peut donc exprimer y, à partir du facteur de charge :

ou inversement :

[5.11]

Le SIR reçu y, étant souvent petit par rapport à 1 dans le cas d'un réseau CDMA, la relation [5.14] peut être approximée par :

[5.12]

5.4.2.3. Relation entre le facteur de charge et le nombre de mobiles pour une base donnée

Dans le cas où tous les usagers ont le même débit de données R et le même facteur d'activité (p, la relation suivante entre le facteur de charge et le nombre de mobiles pour une base donnée peut être établie :


[5.13]

Dans [5.13], nous supposons que l'objectif de qualité (Eb/N0)rest le même pour toutes les communications. Comme hypothèse supplémentaire, nous considérons que cet objectif est exactement atteint (hypothèse de contrôle de puissance parfait). En effet, les relations [5.12] et [5.1] permettent d'écrire, pour une communication i donnée :

[5.14]

Nous introduisons à ce stade la variable aléatoire binomiale (p„ représentant l'activité de la communication /'. Nous pouvons alors écrire :

[5.15]

La variable (p, est supposée être de type Bernouilli dans [VEE 99]. Nous n'avons pas besoin de ce résultat au niveau de ce chapitre.

Ecrivons l'espérance des deux côtés de l'équation précédente :

[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 contrôle de puissance parfait) sont les mêmes pour tous les mobiles.

La sommation de l'équation précédente sur tous les mobiles de la cellule j donne : é' -

[5.17]


Si nous considérons que le nombre de mobiles actifs est assez élevé par cellule pour pouvoir considérer la somme de gauche constante, nous pouvons faire Y approximation consistant à supprimer l'espérance :

[5.18]

Il suffit alors de multiplier par (1 +fj) dans les deux côtés de l'équation précédente et d'utiliser la relation [5.7] pour achever de démontrer la relation [5.13].

Dans le cas général d'un réseau où les mobiles transmettent à des débits éventuellement différents et ont des facteurs d'activité éventuellement différents, 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'interférence de la cellule et des rapport de qualité-seuil, des débits 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é pôle.

Application numérique : Considérons un réseau cellulaire où toutes les communications ont le même type

de service, par exemple la communication vocale, et où les valeurs numériques 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 considérons que le facteur Jj a une valeur fixe égale à 0,65 et que la bande de fréquence West égale à 4 MHz.

En utilisant «frelations [5.8] et [5.13], nous établissons facilement la relation suivante entre le nombre Nj de mobiles dans la cellule /, et l'augmentation du bruit NRj dans cette cellule :


Cette relation est tracée dans la figure 5.3. La valeur 97 est la capacité pôle d'une cellule dans cette application.

5.4.2.4. Relations entre la puissance émise d'un mobile et le NR

Considérons un mobile i rattaché à la base j et reçu 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]

Idéalement (c'est-à-dire en ca^de contrôle de puissance parfait), la qualité de communication doit être égale au seuil requis, d'où :

[5.21]

Paramètres numériques :

Figure 5.3. Augmentation du bruit (NR) en fonction du nombre de mobiles de la cellule


La puissance transmise peut être écrite sous forme de fonction du facteur de charge de la base de rattachement.

Soit pi la puissance émise par le mobile /'. La puissance reçue s'exprime en fonction du gain de parcours entre le mobile i et sa station de base. Réciproquement, on peut écrire :

En utilisant [5.8], [5.21] et [5.21a], des manipulations simples permettent d'exprimer la puissance d'émission nécessaire au mobile, dans l'hypothèse d'un contrôle de puissance parfait (l'expression est utilisée dans [SCH 01]) :

L'expression [5.22] peut être simplifiée. En effet, si le nombre de mobiles est grand, on peut faire l'approximation suivante sur [5.21] :

[5.21a]

On peut alorSâblir :

[5.22a]

ou, de manière 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 interférence, la puissance à émettre est proportionnelle au bruit thermique. En présence d'interférence (charge sur le réseau), la puissance est


multipliée par le facteur NRy La capacité pôle est donc la capacité qui serait obtenue si les mobiles avaient une puissance infinie.

Dans le paragraphe suivant, nous donnons les éléments d'une étude similaire pour la liaison downlink.

5.5. Définitions et relations utiles pour la liaison downlink

L'étude du sens downlink a longtemps été négligée. En effet, il est moins simple à aborder que le sens uplink (voir ci-dessous) et Viterbi avait déclaré que pour les réseaux à débits symétriques, ce qui est notamment le cas de la téléphonie, le sens uplink est le sens le plus contraignant au niveau limitation de la capacité ([VIT 95]).

\

Cependant les réseaux CDMA seront amenés à court terme à transmettre des données, en grande partie. Les débits de données, pour lesquels le sens downlink aura souvent un débit moyen bien plus élevé que le uplink (par exemple consultation Internet), pourraient bientôt faire du sens downlink le sens le plus contraignant. D'où l'intérêt 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) présente des différences par rapport à la liaison montante, en particulier :

- les communications d'une même cellule se partagent la puissance limitée de la station de base ;

- l'interférence intracellulaire est reçue sur le même canal que le signal utile, c'est-à-dire celui destiné au mobile considéré. Cette interférence est nulle dans le cas (utopique) où l'orthogonalité est parfaitement conservée ;

- le coefficient de l'interférence externe (voir relation [5.6]) n'est plus le même pour les communications d'une même cellule. Par exemple, il sera plus élevé pour les mobiles proches de la frontière de la cellule.

Ces considérations introduisent des variations dans l'étude du downlink par rapport au uplink.


Si l'orthogonalité est parfaitement conservée (cas utopique), il n'y a pas d'interférence entre les communications d'une même cellule. Les mobiles situés en bordure de cellule sont particulièrement défavorisés. La puissance qui leur est transmise doit être plus élevée que celle des mobiles plus proches de leur base.

Figure 5.4. Etude de la liaison descendante (downlink)

5.5.1. Définitions

5.5.1.1. Noise Rise d'une base

Le facteur d 'augmentat ion de bruit sur la voie montante se définit pour une base donnée. Il s 'agit de l 'augmentation relative de la puissance totale émise par la base entre le cas réel et le cas utopique où il n ' y aucune interférence entre les différentes


communications downlink, y compris entre deux communications base-mobile de deux cellules différentes.

5.5.1.2. Facteur de charge d'une cellule (loadfactor)

Le facteur de charge se définit de façon moins claire que sur la voie montante. L'idée est de trouver une expression pour le facteur de charge qui garde la même relation avec le NR que dans le cas du uplink. Pour calculer le facteur de charge, on se base sur l'hypothèse suivante :

« Toutes les stations de base émettent avec la même puissance P »

Cette hypothèse peut être considérée valable si les stations de base sont disposées sur une grille régulière, si la distribution du trafic est uniforme et si les conditions de propagation sont les mêmes sur la zone couverte. On peut aussi considérer qu'aux heures de pointe (pour lesquelles un réseau est dimensionné), les stations de base émettent à leur puissance maximale, la même pour toutes.

5.5.2. Relations utiles

Le SIR reçu 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 reçoit une puissance (1 - a,)/y comme interférence. Autrement dit, a, serait égal à 1 si l'orthogonalité était parfaitement conservée.

Comme on suppose que toutes les stations de base émettent à la puissance P, on peut écrire :

[5.24]


En cas de contrôle 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 /' rattachés à la cellule j, on obtient :

[5.26]

[5.26a]

L'expression [5.26a] peut être vue comme le produit du numérateur et de l'inverse du dénominateur. On peut vérifier que le numérateur correspond à la puissance totale émise par une base dans le cas où il n'y aucune interférence entre les différentes communications downlink (y compris entre deux communications base-mobile de deux cellules différentes). L'inverse du dénominateur correspond à un facteur correctif dû à la présence des interférences. On peut donc, par analogie avec l'équation 5.22, définir le facteur de charge r|DLj sur la voie descendante en posant :

i

Si on introduit les facteurs d'activité, on peut établir :


[5.27]

avec :

fDL,i= Z f - [5.28]

où nous pouvons vérifier, toujours dans le cadre de l'hypothèse de stations de base à pleine puissance, que ce rapport représente, pour le mobile i, le rapport entre la puissance totale reçue des bases autres que celle à laquelle il est rattaché sur la puissance totale reçue de sa base (incluant la puissance qui lui est destinée). Le paramètr-e fou représente donc bien le rapport d'interférences du mobile i.

Comme pour la voie montante nous pouvons écrire :

N: n — ^ DL.i P/<P, M

W [5.28a].

où de manière é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 défini, 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é pôle de cette dernière, en downlink.

Dans le cadre de ce modèle, des méthodes sont proposées dans [HIL 00] pour estimer la capacité du sens downlink d'un réseau CDMA, en particulier pour UTRA-FDD.


5.6. Algorithme de prévision de la couverture d'un réseau CDMA par calcul itératif des charges des cellules

L'algorithme de prévision de la couverture d'un réseau CDMA par calcul itératif des charges des cellules est proposé dans [WAC 99]. Il est décrit 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 décrit (étude uplink). NR(n) est le NR d'une base donnée pour l'itération n.


La première phase correspond à l'initialisation. En fonction des données de trafic et de charge offerte, une répartition des mobiles est effectuée. Les gains de liaison sont calculés entre les stations de base et les positions de mobiles et stockés dans une base de données.

La deuxième phase correspond à la partie itérative. A partir des valeurs initiales des augmentations de bruit des stations de base, le calcul itératif fait converger ces valeurs vers leur valeurs estimées, tout en déterminant quels sont les mobiles en état de coupure (outage), c'est-à-dire qui ne seront pas couverts.

Les résultats obtenus sont traités et affichés dans la troisième phase. Les résultats de gains de liaison maximaux permettent, à partir du modèle de calcul de gain de liaison, de déduire les distances maximales et donc les couvertures des différentes stations de base.

Une étude de cas détaillée, faite à l'aide de cet algorithme, peut être trouvée dans le chapitre 8 de [HOL 02].

L'organigramme de la figure 5.5 représente les itérations du sens uplink. Lors de l'application de l'algorithme, les itérations de la deuxième phase doivent être appliquées pour les deux sens de communication (uplink et downlink). Les équations du paragraphe 5.5 de ce chapitre sont alors utilisées. Le détail de la partie downlink de cet algorithme est proposé dans [SIP 00]. Après convergence, les résultats des deux sens sont traités dans la troisième phase.

5.7. Détails supplémentaires sur l'algorithme de calcul des charges

5.7.1. Imperfection du contrôle de puissance

Dans la réalité, le contrôle de puissance n'est pas parfait à cause des raisons suivantes ([SIP 99a]) :

- les puissances transmises ne sont pas mises à jour de façon continue, elles le sont dans le cadre d'une boucle fermée échantillonnée (voir système WCDMA) ;

- le pas de mise à jour des puissances est compris dans une certaine marge et il est souvent constant ;

- il existe un délai non nul entre la mesure du SIR reçu (utilisé pour la décision de mise à jour) et la mise à jour de la puissance. Cette dernière mesure n'est pas totalement précise ;

- des erreurs peuvent avoir lieu lors de la transmission des ordres de mise à jour des puissances ;


- les puissances transmises sont limitées dans une certaine marge (valeur minimale et valeur maximale).

Des études théoriques et des simulations montrent que ces imperfections peuvent être prises en compte par l'introduction d'un facteur correspondant à l'imperfection du contrôle de puissance dans la relation [5.7] qui devient :

N NULJ= (l + I p c f j ) X ÛLjjt [5-30]

i=l;bj=j

où Ipc est ce facteur. La valeur de IPC dépend du modèle adopté pour le canal radio. Ces valeurs vont de 1,05 à 1,6 suivant le canal considéré ([SIP 99a]).

j

5.7.2. Interférence de canaux adjacents

Il est possible que plusieurs porteuses CDMA coexistent, ces porteuses appartenant à un même opérateur ou à plusieurs opérateurs. Si deux ou plusieurs porteuses CDMA coexistent, un calcul d'interférence de canaux adjacents doit être effectué. Un terme représentant l'interférence des canaux adjacents est inclus dans les formules de calcul de SIR (uplink et downlink). Ce terme est fonction des effets des filtres appliqués à chacune des porteuses autres que celle considérée.

5.7.3. Sectorisation

Comme dans l'estimation simple de la section 5.3 de ce chapitre, il est possible, dans l'algorithme décrit 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 effectués de manière analogue à ce qui a été présenté 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 réseaux cellulaires CDMA par rapport aux réseaux F/TDMA. L'intérêt principal du soft handover est l'introduction de la diversité de transmission. L'algorithme décrit 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 contrôle de puissance (équivalents à des


baisses de seuil de rapport de qualité reçue) dus au soft handover dans WCDMA, pour le uplink, sont évalués en simulation dans [SIP 99b].

5.8. Conclusion et discussion

Dans ce chapitre, nous présentons le problème de l'étude de la couverture d'un réseau cellulaire CDMA. Les formules et les relations nécessaires pour ce genre d'étude sont détaillées. En particulier, nous décrivons un simulateur statique publié dans plusieurs papiers de recherche.

Plusieurs extensions de ce genre d'étude peuvent être envisagées, certaines de ces extensions ayant déjà fait l'objet de travaux de recherche. Un point particulier des réseaux 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 réseau cellulaire CDMA ([NUA 01]). Le choix simple (et donc non optimal) revient à sélectionner la base ayant le signal pilote le plus fort (parfois appelée best server) pour chaque mobile. Cette méthode est celle utilisée pour l'algorithme décrit 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 utilisées pour des calculs de probabilité basés sur les formules détaillées dans ce chapitre. Les résultats des calculs sont des courbes de probabilités de couverture pour une carte donnée. Dans le même cadre, la couverture et, plus généralement, l'étude des performances d'un réseau sans fil CDMA transmettant des données est faite dans [TRA 99L

Nous rappelons enfin que toutes ces méthodes dites statiques peuvent être validées par les simulations de type Monte-Carlo qui doivent donner des résultats proches de la pratique au prix de durées de simulation relativement longues et parfois prohibitives. La validation finale est, bien entendu, celle des expérimentations sur le terrain quand le déploiement à grande échelle des réseaux cellulaires CDMA sera en place.

5.9. Bibliographie

[ C A S 01] CASTRO J. P., The UMTS Network and Radio Access Technology, Wiley, 2001.

[ C H E 9 6 ] CHEBARO T . , GODLEWSKI P., « Average external interference in cellular radio C D M A systems », IEEE Trans. on Communications, vol. 4 4 , n° 1, 1 9 9 6 .


[ C O R 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.

[ G I L 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.

[HIL 0 0 ] Hiltunen K . , DE BERNARDI R. , « W C D M A downlink capacity estimation », IEEE Vehicular Technology Conférence 2000 Spring, VTC2000 Spring, 2000.

[HOL 0 2 ] HOLMA H. , TOKSALA A . , WCDMA for UMTS, Second édition, Wiley, 2 0 0 2 .

[JON 0 0 ] JONES P. , OWEN R . , « Sensitivity of UMTS F D D system capacity and coverage to model parameters », First International Conférence on 3G Mobile Communication Technologies, 2 0 0 0 .

[LAI 9 9 ] LAIHO-STEFFENS J . , WACKER A . , SIPILA K . , HEISKA K. , « The impact of the subscriber profile on W C D M A radio network performance », IEEE Vehicular Technology Conférence J 999 F ail, VTC-99F, 1999.

[LAI 0 1 ] LAIHO J. , WACKER A . , «Radio network planning process and methods for W C D M A », Annales des Télécommunications, vol 56, n° 5-6, 2 0 0 1 . ^

[LAI 02 ] LAIHO J. , WACKER A . , NOVOSAD T . , Radio Network Planning and Optimisation for UMTS, Wiley, 2 0 0 2 .

[LEE91] LEE W . C . Y . , «Overview of cellular C D M A » , IEEE Trans. on Vehicular Technology, vol. 40, n° 2, 1991.

[MOU 00] MOUROT C., « Evolution de l'ingénierie des réseaux radiomobiles », Les réseaux radiomobiles, ouvrage coordonné par X. Lagrange, Collection IC2, Hermès, 2000.

[NUA 01] NUAYMI L. , Contributions sur les algorithmes de contrôle de puissance équilibrés dans les réseaux cellulaires, PhD Report, Ecole Nationale Supérieure des Télécommunications (ENST), Paris, 2001.

[SCH 01] SCHRÔDER B. et al., «An analytical approach for determining coverage probabilities in large U M T S networks », IEEE Vehicular Technology Conférence 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 Conférence 1999 Spring, VTC '99S, 1999.

[SIP 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 Conférence 1999 Spring, VTC99S, 1999.

[SIP 00] SIPILA K . , HONKASALO Z.-C., LAIHO-STEFFENS J. , WACKER A., « Estimation of Capacity and Required Transmission Power of WCDMA Downlink Based on a Downlink Pôle Equation », IEEE Vehicular Technology Conférence 2000 Spring, VTC2000 Spring, 2000.


[ T R A 9 9 ] TRAN-GIA P., LEIBNITZ K . , « Teletraffic Models and Planning in Wireless IP Networks », IEEE Wireless Communications and Networking Conférence, WCNC'99, 1999.

[ V E E 99] VEERAVALLI V . V . , SENDONARIS A., « The Coverage-Capacity Tradeoff in Cellular CDMA Systems », IEEE Trans. on Vehicular Technology, vol. 48, n° 5, 1999.

[ V I T 9 1 ] VITERBI A . J . , VITERBI A . M . , ZEHAVI E . , « Other-cell interference in cellular power-controlled C D M A », IEEE Trans. on Communications, vol. 4 2 , n° 2 - 4 , 1 9 9 4 .

[ V I T 9 3 ] VITERBI A . M . , VITERBI A . J . , « Erlang capacity of a power controlled C D M A

system », IEEE Journal on selected areas in communications, vol. 11, n° 6, 1993.

[ V I T 9 5 ] VITERBI A. J . , CDMA Principles of spread spectrum techniques, Addison-Wesley, 1995.

[ 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 Conférence 1999 Spring)VTC'99S, 1999.

5.10. Annexe : notations utilisées dans ce chapitre

Note : en règle générale et sauf mention du contraire, les grandeurs valables en uplink et en downlink (comme par exemple le rapport signal sur bruit ou SIR) ont le suffixe DL en downlink et aucun suffixe relatif au uplink en uplink.

a, Coefficient d'orthogonalité du mobile i (utilisé uniquement pour le downlink). B Nombre total de station de base de la zone considérée. bi Base avec laquelle correspond le mobile i. y,- Rapport signal sur bruit (SIR) reçu en uplink du mobile i correspondant avec la base j.

y DU Rapport signal sur bruit (SIR) reçu 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é reçue. Le bruit considéré inclut l'interférence due aux autres communications et le bruit thermique de réception. (Eh/N0)ij Seuil de qualité requis pour le rapport énergie par bit sur la densité spectrale du bruit, de la communication i, en uplink. (EB/N0)DLI Rapport énergie par bit sur la densité spectrale du bruit, de la communication /, en downlink. (EB/N0)DLJJ Seuil de qualité requis pour le rapport énergie par bit sur la densité spectrale du bruit, de la communication du mobile i, en downlink. Ce rapport est aussi noté p,-.


p, Seuil de qualité requis pour le rapport énergie par bit sur la densité spectrale du bruit, de la communication /, en downlink. fj Pour la base j (définition uplink), c'est le rapport de la somme des puissances reçues des mobiles à l'extérieur de la cellule sur la somme des puissances reçues des mobiles à l'intérieur de la cellule.

fou Pour le mobile i, c'est le rapport entre la puissance totale reçue des bases autres que celle à laquelle il est rattaché sur la puissance totale reçue de sa base (incluant la puissance qui lui est destinée). cp Facteur d'activité, au cas où il est commun à tous les usagers. (p, Variable aléatoire binomiale représentant l'activité du mobile /'. La

valeur moyenne de cp„ notée (p,-, représente le facteur d'activité du mobile i. gij Gain de parcours, en puissance, entre le mobile i et la base j. gji Gain l̂e parcours, en puissance, entre la base j et le mobile i. i,k Indices désignant les mobiles. j,l Indices désignant les bases. IIDL,/ Facteur de charge en downlink du mobile i.

r|ULî/ Facteur de charge en uplink à la base j. tluw,/ Facteur de charge en uplink du mobile i à la base j. Lji Facteur de charge du mobile i à la base j. N Nombre de mobiles actifs dans la zone couverte. Nj Nombre de mobiles actifs dans la base j. NRdlj Noise Rise du mobile i (étude uplink). NRj Noise Rise de la base j (étude uplink). Nfh j Puissance du bruit thermique reçu par le mobile i. NThj Puissance du bruit thermique reçu à la station de base j. PLji Atténuation entre le mobile i et la station de base /. En fait, PLU n'est autre que M gu. PLMaxj Atténuation maximale pour les mobiles rattachés à la base j. P Puissance totale émise par une base, dans l'hypothèse où cette puissance est la même pour toutes les bases. Pi Puissance émise du mobile /'. Pj Puissance totale émise par la base j. Pji Puissance émise de la base j destinée au mobile i, rattaché à cette dernière. PMax Puissance maximale d'émission.

P\fax.e Puissance maximale d'émission de l'équipement e (mobile ou base).


Prij Puissance utile venant de la base j et reçue au mobile i (étude du downlink). Prjj Puissance reçue à la base j venant du mobile i (étude de Fuplink). R Débit de données avant étalement. Ri Débit de données, avant étalement, de l'usager z, dans le sens uplink.

RDLJ Débit de données, avant étalement, de l'usager /, dans le sens downlink. W Débit numérique (chips) après étalement. Cette valeur est considérée égale, en première approximation, à la bande de fréquence (en Hz) occupée par le signal étalé.

Chapitre 6

Le réseau d'accès UTRAN

Ce chapitre présente les principaux concepts du réseau d'accès de l'UMTS appelé UTRAN, Universal Terrestrial Radio Access Network, en les illustrant par de nombreux exemples. Ces concepts sont généralement des extensions et des abstractions de mécanismes déjà présents dans le réseau d'accès GSM. La première partie présente l'architecture matérielle de l'UTRAN en comparaison de celle du GSM. Après un rappel sur les principaux protocoles utilisés dans les réseaux, on s'attache à présenter l'architecture protocolaire de l'UTRAN et on montre comment elle est instanciée sur les différentes interfaces lorsqu'on utilise une technologie de transport ATM et lorsqu'on utilise IP. On donne ensuite les caractéristiques des protocoles impliqués sur la voie radio. Le chapitre se conclut par des exemples de scénarios permettant de voir comment les différents mécanismes s'articulent entre eux.

6.1. Architecture générale

6.1.1. Rappel sur le réseau d'accès de GSM

Le réseau d'accès de GSM est appelé BSS, Base Station Subsystem ; il comprend deux types d'équipements :

Chapitre rédigé par Xavier LAGRANGE1 .

1. L'auteur tient à remercier particulièrement Saso Stojanovski et Claudiu Mihailescu pour leur relecture attentive.


- les BTS (Base Transceiver Station) qui sont des émetteurs-récepteurs ayant un minimum d'intelligence ;

- le BSC (Base Station Controller) qui contrôle un ensemble de BTS et permet une première concentration des circuits.

La BTS est un ensemble d'émetteurs-récepteurs appelés TRX. Elle gère la transmission radio : modulation, démodulation, égalisation, codage correcteur d'erreur. Elle gère plus généralement toute la couche physique : multiplexage TDMA, saut de fréquence lent, chiffrement. Elle réalise également l'ensemble des mesures radio nécessaires pour vérifier qu'une communication en cours se déroule correctement. Dans les premières versions de la norme, c'est-à-dire dans la philosophie de départ de GSM, ces mesures ne sont pas exploitées par la BTS mais sont directement transmises au BSC. La BTS gère également la couche liaison de données pour l'échangejde signalisation entre les mobiles et l'infrastructure.

La trisectorisation est employée massivement par les opérateurs : elle consiste à placer sur le même site trois BTS pourvues chacune d'antennes directionnelles qui couvrent des secteurs de 120° d'ouverture. Les trois BTS sont placés généralement dans une même armoire et apparaissent donc comme un seul équipement. Très vite, l'habitude a été prise par les opérateurs et les constructeurs de parler d'une « BTS trisectorisée » pour désigner ce que la norme considère comme trois BTS différentes, même si elles sont colocalisées. Le vocabulaire de la nonne diffère donc du vocabulaire courant. Ces ambiguïtés de vocabulaire sont levées avec l'UMTS (voir paragraphe 6.1.2.3).

Le BSC est l'organe intelligent du BSS. Il a pour fonction principale de gérer la ressource radio : il commande l'allocation des canaux, utilise les mesures effectuées par la BTS pour contrôler les puissances d'émission du mobile et/ou de la BTS, prend la décision de l'exécution d'un handover. De plus, c'est un commutateur qui a pour fonction de réaliser 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 reliés entre eux par des liaisons spécialisées, ce qui constitue l'interface Abis. Les liaisons utilisées sont des liaisons MIC, généralement de type El (31 voies à 64 kbit/s multiplexées temporellement, soit une liaison à un débit total de 2,048 Mbit/s). Les technologies employées sont des liaisons filaires, des faisceaux hertziens ou, dans certains cas, des liaisons HDSL (par exemple pour des couvertures d'aéroports où l'on réutilise l'infrastructure privée de paires torsadées).

Le réseau d'accès UTRAN 217

La parole est codée le plus souvent en GSM à 12,2 kbit/s. Comme le coût des liaisons entre BTS et BSC est un élément important du coût total d'exploitation du réseau, il est primordial d'écouler le maximum de trafic sur le même support de transmission : en général, les opérateurs 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 débit 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 représenté sur la figure 6.1. Celle-ci est coûteuse et peu résistante aux pannes. Il est possible d'utiliser une topologie en chaîne : plusieurs BTS et le BSC forment une chaîne rebouclée sur elle-même. Cette topologie est économique et résiste à une panne-de liaison. On reste cependant dans une approche circuit : il y a une correspondance fixée par configuration entre chaque canal radio d'une BTS et chaque sous-voie à 16 kbit/s. Cette dernière est réservée de façon définitive, qu'il y ait une communication ou non.

Figure 6.1. Architecture du réseau d'accès GSM

De plus, les débits 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é spécifié avec l'objectif principal d'offrir un service de téléphonie compatible du RNIS (Réseau numérique à intégration de services). Les spécifications manquent de souplesse : elles n'ont pas été prévues pour établir un circuit avec un débit à la demande.


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 à débit fixe sur les interfaces du réseau d'accès.

6.1.2. Eléments du réseau d'accès UTRAN

Le réseau d'accès de l'UMTS, appelé UTRAN (Universal Terrestrial Radio Access Network), est constitué de stations de base et de contrôleurs comme dans GSM. Les différences avec GSM ont poussé à un changement de vocabulaire :

- le nœud B (node B) est un ensemble d'émetteurs-récepteurs et correspond à la BTS de GSM ;

- le RNC (Radio Network Controller) est le contrôleur de ressources radio et correspond au BSC de GSM.

Figure 6.3. Architecture générale du réseau d'accès UTRAN

Figure 6.2. Circuits dans le réseau d'accès GSM {plan usager)


6.1.2.1. Réseau de transport

Le réseau d'accès UTRAN se distingue du BSS de GSM par l'utilisation d'un réseau de transport (voir figure 6.3). Ce dernier remplace les liaisons spécialisées du GSM. Dans la première version des recommandations (Release 99) le réseau de transport est de type ATM (Asynchonous Transfer Mode). C'est donc un réseau de type circuit virtuel. A partir de la Release 5, il est possible d'utiliser un réseau IP. L'intérêt d'utiliser un réseau de transport est la grande souplesse que cela peut apporter :

- défense contre les pannes de liaisons grâce au maillage généralement présent dans toute topologie de réseau ;

- modification possible de la topologie par réorganisation des circuits virtuels ; - possibilité de relier deux RNC entre eux sans installation de liaisons physiques

supplémentaires ; par exemple, avec un réseau de transport ATM, il suffit d'établir un circuit virtuel sur le réseau. Cela permet de définir une nouvelle interface spécifique à l'UMTS, l'interface Iur.

Le réseau de transport sert indifféremment à transporter les données usager (plan d'usager) et l'ensemble de la signalisation (plan de contrôle). Contrairement au GSM, où une voie à 64 kbit/s est configurée soit comme liaison de signalisation, soit comme ensemble de 4 circuits de voix ou données (sous-voies à 16 kbit/s), le même réseau de transport est utilisé à la fois pour le plan d'usager et le plan de contrôle. La différenciation entre les deux se fait dans l'architecture en couches.

Les recommandations ne précisent pas l'architecture du réseau de transport. Celui-ci peut être réduit à sa plus simple expression, c'est-à-dire une liaison physique ! Par exemple, il est possible de conserver des liaisons physiques entre les nœuds B et les RNC et de n'avoir un réel réseau de transport qu'entre RNC (utilisation de liaisons de type ATM sur SDSL, Single-line Digital Subscriber Line, entre les nœuds-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 réseau 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 représente les circuits virtuels permanents permettant d'effectuer les liaisons au sein du réseau de transport dans le cas où tous les équipements accèdent au même réseau de transport.


Figure 6.5. Exemple d'utilisation de circuits virtuels permanents ATM dans UTRAN

6.1.2.2. Interfaces dans l'UMTS

Les interfaces filaires du réseau d'accès sont désignées par les lettres lu. L'interface lu est située entre le RNC et un réseau cœur. Avec un réseau cœur circuit, il s'agit de l'interface Iu-Cs, avec un réseau cœur 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 nœud B et le RNC, est l'homologue de l'interface

i


Abis. L'interface Iur entre RNC est spécifique à l'UTRAN et sans équivalent dans GSM. Ces interfaces sont représentées à 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 représentation.

Figure 6.6. Interfaces dans le réseau d'accès UTRAN

6.1.2.3. Le Nœud B

Le nœud B (node B) assure toutes les fonctions de la couche physique sur la voie radio : transmission et réception, modulation, démodulation, étalement de spectre, codage correcteur. Le nœud B prend également en charge le contrôle de puissance rapide du mobile (c'est-à-dire sur la voie montante) et, dans certaines configurations, les mécanismes de diversité de réception par sélection ou par combinaison (maximum ratio combining).

Comme dans GSM, il est possible d'utiliser la trisectorisation. La norme a repris le vocabulaire courant et considère qu'il y a dans ce cas un seul nœud B qui couvre plusieurs secteurs.

6.1.2.4. Le RNC

Le RNC est l'équipement qui contrôle l'utilisation et l'intégrité des ressources radio. Du fait de l'utilisation d'un réseau de transport, un nœud B pourrait avoir des


liaisons avec plusieurs RNC. Cependant, cela n'est pas prévu par les recommandations. Un nœud B est contrôlé par un seul RNC. Ce RNC est appelé Controlling RNC. Dans la suite, pour simplifier le vocabulaire, on n'utilisera pas ce terme : par défaut, lorsqu'on décrit des actions effectuées par un RNC sur un nœud B, il s'agit toujours du Controlling RNC.

Pour un mobile donné, le RNC effectue les opérations 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 présence de cette connexion est indispensable si le mobile souhaite établir un appel ou une session de données, ou plus généralement échanger de la signalisation avec le réseau (pour la gestion de la mobilité par exemple) ;

- il affecte les ressources radio (par exemple le code OVSF à utiliser sur la voie descendante) ;

- il gère le contrôle de puissance lent ; - il gère la configuration ou reconfiguration de l'interface radio et la mobilité du

mobile (handovers) qui nécessitent un échange de signalisation avec le mobile ; - il comprend des fonctions de combinaison et de découpage

(<combining/splitting) pour la macrodiversité.

Lorsqu'on considère un mobile particulier en communication et en soft handover (ou qui a effectué préalablement des handovers), deux RNC ou plus peuvent être concernés par la connexion radio. Ces deux RNC ne jouent pas le même rôle. Le Serving RNC (S-RNC) ou RNC serveur est celui qui effectue la gestion des connexions radio, le raccordement avec le réseau cœur et qui contrôle et exécute le handover. Le Drift RNC1 (D-RNC) OU RNC en dérivation 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 gère la macrodiversité sous ses nœuds 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 dérivation. Le RNC serveur est l'équipement avec lequel le mobile a établi une connexion RRC. C'est la présence ou l'absence de la connexion RRC qui définit la notion de RNC serveur pour un mobile. Sans son existence, le mobile est incapable de communiquer avec le réseau (mode veille UMTS par opposition au mode connecté de l'UMTS).

2. Drift signifie, entre autres, dérivation. Par analogie avec l'électricité où l'on parle de montage en dérivation pour désigner un montage en série, on peut parler de RNC placé en dérivation entre le mobile et le RNC.


Le mobile a établi une communication lorsqu'il était dans la cellule 1. Le RNC 1 était Serving RNC. Suite à un soft handover, la communication passe par le RNC 2 qui a le rôle de Drift RNC. Le RNC 1 reste Serving RNC.

Figure 6.7. RNC serveur et en dérivation lors d'un soft handover

Après un déplacement du mobile, il est inutile de maintenir la liaison radio via le nœud B 1. les RNC gardent chacun leur rôle.

Figure 6.8. RNC serveur et en dérivation après un soft handover

Dans certains cas, comme par exemple après un ou plusieurs handover (voir figures 6.8 et 6.9), il est possible que les R N C changent de rôle pour une


communication donnée : un chemin plus court est établi entre le réseau cœur et le mobile, l'ancien RNC en dérivation 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 dérivation {procédure de relocalisation)

6.2. Rappels sur les architectures en couches des réseaux

L'évolution des réseaux s'est faite de 1980 à 2000 de façon un peu anarchique : plusieurs technologies ont été développées sans grande coordination. Parmi celles-ci, on peut citer l'ATM reposant sur la commutation de cellules, les réseaux IP et la signalisation sémaphore pour le réseau téléphonique. Ces techniques ne se situent pas au même niveau de détail par rapport au modèle de référence OSI. Une des particularités de l'UMTS est de les utiliser toutes. Nous rappelons dans ce paragraphe les grandes lignes de chaque technique et comment celles-ci peuvent interopérer.

6.2.1. Signalisation sémaphore

Dans le réseau téléphonique, les données utilisateurs et la signalisation sont échangées par deux réseaux distincts. En d'autres termes, le plan de contrôle et le plan d'usager sont dissociés dès le niveau physique. L'architecture du réseau téléphonique est décrite de façon générale dans [LAG 98] et de façon précise dans [RIG 98]. Cette partie contient les concepts essentiels de la signalisation sémaphore.


6.2.1.1. Définition

La signalisation sémaphore a été développée dans le cadre des réseaux téléphoniques utilisant la commutation de circuits. Elle est définie comme une méthode dans laquelle une seule voie, appelée canal sémaphore, achemine la signalisation se rapportant à une multiplicité de circuits. La signalisation sémaphore peut également servir à échanger des messages de gestion et de supervision entre commutateurs [RUS 02].

Le principal système de signalisation par canal sémaphore est celui défini par l'ITU dans la série de recommandations Q.700. Il est couramment appelé SS7 (Signalisation sémaphore 7), CCITT n°7 (ancien nom de l'ITU) ou CCS7 (Common Channel Signalling System number 7). Son principal objectif est de définir un standard de signalisation au niveau mondial optimisé pour les réseaux numériques, fiable et évolutif pour convenir à l'élaboration de services futurs [Q.701].

L'ensemble des canaux sémaphores d'un réseau téléphonique forme un réseau sémaphore qui utilise le principe de la commutation de messages. Les utilisateurs du réseau sémaphore sont les centraux téléphoniques qui génèrent et interprètent les messages de signalisation. Dans ce contexte, ils sont appelés PS (Points sémaphores) ou SP (Signalling Point). Pour permettre d'échanger des messages entre deux commutateurs téléphoniques qui ne sont pas reliés entre eux par un canal sémaphore, on place des commutateurs de messages appelés PTS (Points de transfert sémaphore) ou STP (Signalling Transfer Point). Comme tout commutateur de datagrammes, un PTS stocke les messages de signalisation, analyse leur en-tête pour effectuer le routage et les retransmet au destinataire ou à un autre PTS plus proche du destinataire.

Dans un réseau téléphonique classique, il y a une séparation claire entre le réseau de transmission, supportant les communications (voix ou données) et bâti sur la commutation de circuits et le réseau de signalisation bâti sur la commutation de messages. Cependant, les deux réseaux peuvent partager les mêmes supports physiques de transmission.

6.2.1.2. Architecture en niveaux

Le réseau sémaphore étant un réseau à commutation de messages, il est naturel de reprendre une architecture en couches. Dans le contexte du SS7, on parle plutôt de niveaux mais le concept est le même.

Le sous-système de transfert de messages (MTP, Message Transfer Part) offre un service de transfert fiable des messages de signalisation entre deux points sémaphores d'un même réseau. Il comprend 3 niveaux qui correspondent aux


3 couches basses du modèle OSI : physique, liaison de données et réseau. Le niveau 3 du MTP, appelé couramment MTP3, offre un service réseau sans connexion. Chaque PS est repéré par une adresse codée sur 14 bits appelée code de point sémaphore (PC, Point Code).

Lorsque la signalisation concerne l'établissement, la gestion ou la libération d'un circuit téléphonique, elle est dite « associée circuit ». Dans le cas contraire, la signalisation est « non associée circuit ». L'établissement d'un appel téléphonique provoque un échange de signalisation associée circuit. La consultation d'une base de données est un exemple de signalisation non associée circuit.

6.2.1.3. Signalisation associée circuit

Dans le cas de la signalisation associée circuit, le protocole d'établissement des appels téléphoniques est placé directement au-dessus de MTP3. On parle de sous-système utilisateurs ou user part. Le protocole le plus répandu est ISUP [Q.761]. Il permet une grande variété de services supplémentaires (renvoi d'appel, double appel,...).

Figure 6.10. Pile de protocoles pour la signalisation associée circuit

6.2.1.4. Signalisation non associée circuit

Le MTP offre un service limité : il permet uniquement l'échange de signalisation au sein d'un même réseau sémaphore et offre seulement un service sans connexion. Le protocole SCCP, Signalling Connection Control Part, ou sous-système de commande des connexions sémaphores, 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 réseau SS7 et permet d'échanger des messages de signalisation non liés à un circuit entre réseaux SS7 différents. Cela suppose, bien sûr, que les réseaux SS7 soient interconnectés entre eux.


Le SCCP possède quatre classes de services dont certaines permettent d'offrir un service avec connexion non présent dans le MTP :

-c lasse 0, service sans connexion de type datagramme sans garantie de séquencement ;

-c lasse 1, service sans connexion de type datagramme avec garantie de séquencement (tous les messages suivent le même chemin et sont délivrés par le réseau dans l'ordre de remise par l'expéditeur) ;

- classe 2, service avec connexion sans contrôle de flux ; - classe 3, service avec connexion avec contrôle de flux.

Le niveau SCCP fournit l'ensemble des services réseau définis par le modèle de référence OSI. Au-dessus de SCCP peuvent se trouver de nombreuses entités utilisatrices. C'est le cas dans l'UMTS.

modèle de référence OSI

Figure 6.11. Pile de protocoles pour la signalisation non associée circuit

Le protocole TCAP, Transaction Capabilities Application Part, ou sous-système de gestion des transactions [Q.771] est un protocole de couche application utilisant une structure transactionnelle permettant de fiabiliser les demandes d'opérations à distance (consultation de base de données, activation de services à distance, demande d'exécution de requête). TCAP gère également les problèmes 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 paramètres communs à deux applications distantes souhaitant communiquer entre elles. Les échanges TCAP sont structurés en transactions qui elles-mêmes correspondent à une succession d'opérations élémentaires de type question-réponse. La structure transactionnelle permet de s'assurer que les opérations demandées 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

niveaux SS7


données. Il correspond typiquement aux fonctionnalités des couches 5 et 6 du modèle OSI.

Au-dessus du protocole TCAP, se trouve le protocole applicatif qui permet de disposer d'un service spécifique. Le protocole MAP, Mobile Application Part, permet la gestion d'abonnés mobiles dans un réseau GSM ou dans un réseau UMTS.

6.2.2. Architecture en couches d'un réseau 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 données et 5 octets d'en-tête dans le cas précis de l'ATM) [ROL 02]. L'en-tête de la cellule porte l'identification de la voie de communication. Sur une liaison ATM, les cellules correspondant à différentes voies peuvent être transmises suivant un séquencement quelconque : les mécanismes de multiplexage et de commutation sont polyvalents, et indépendants du débit des voies (multiplexage statistique).

VPI : Virtual Path Identifier VCI : Virtual Circuit Identifier

Figure 6.12. Format général d'une cellule ATM

Le mode d'acheminement retenu est l'acheminement par voie logique. Un identificateur de voie virtuelle (VCI, Virtual Channel Identifier) est placé dans l'en-tête 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 configurés par l'opérateur et sont dits permanents (PVC, Permanent Virtual Circuit). Dans la pratique, un réseau est constitué d'un ensemble de brasseurs ATM. L'opérateur définit un certain nombre


de circuits virtuels entre les équipements extrémités. Le service rendu s'apparente donc à du relais de trame.

6.2.2.2. Réseau numérique large bande

Dans les années 80-90, il était prévu d'utiliser l'ATM pour déployer des réseaux haut-débit grand public offrant des services multimédias. Ce type de réseau, appelé RNIS-LB (Réseau numérique à intégration de services et à large bande) ou B-ISDN (Broadband Integrated Service Digital Network) [KOF 96], n ' a pas véritablement vu le jour. Cependant, un certain nombre de concepts et de protocoles ont été réutilisés, notamment dans le cadre de l'UMTS.

Dans ses objectifs de départ, le RNIS large bande interconnecte aussi bien des équipements terminaux que des réseaux privés. Il est constitué de commutateurs de cellules ou commutateurs ATM. On distingue deux types d'interfaces :

- l e s interfaces internes au réseau de l'opérateur, de type Network to Network Interface (NNI) ;

- les interfaces entre l'équipement terminal ou un commutateur privé et le réseau de l'opérateur, de type User to Network Interface (UNI).

Figure 6.13. Interfaces dans le RNIS large bande


Dans le RNIS-LB, le modèle de référence en couches distingue, comme dans la plupart des réseaux, un plan de contrôle (pour la signalisation) et plan d'usager :

- le plan d'usager comprend l'ensemble des mécanismes permettant le transport des données de l'utilisateur final (conversation téléphonique, données échangées comme les messages, pages Web,...) ;

- le plan de contrôle comprend les mécanismes permettant le transport des données usagers. Par exemple, les protocoles d'appel téléphoniques font partie du plan de contrôle.

Le modèle de référence du RNIS-LB distingue trois couches [1.321] : - la couche physique PHY, chargée de la transmission, et constituée d'une sous-

couche, dépendante du médium, chargée de l'émission des bits sur le support, et d'une sous-couche chargée de l'adaptation au débit, du contrôle d'erreur de l'en-tête et de la délimitation des cellules ;

- la couche ATM, chargée de la génération des champs de l'en-tête de la cellule, du traitement des identificateurs de voies/conduits virtuels dans le réseau, du multiplexage/démultiplexage des cellules suivant un rythme adapté à la demande de l'application ;

- la couche d'adaptation à l'ATM (AAL, ATM Adaptation Layer) qui assure la liaison avec les couches supérieures.

La couche AAL établit un lien entre la couche ATM et les couches applicatives. Elle s'efforce de satisfaire les contraintes imposées par les applications en complétant les services de la couche ATM. Son implémentation se situe souvent aux points extrémités (voir figure 6.14.). Notons que les points extrémités peuvent être des terminaux mais également des commutateurs lorsqu'un circuit virtuel est établi entre eux avec certaines caractéristiques de service.

Figure 6.14. AAL, couche de bout en bout

6.2.2.3. Principaux types d'AAL

Le RNIS large bande intègre des services de type parole ou émulation de circuit (débit constant, mode connecté, contraintes temps réel), de type images (débit


constant ou variable à cause de la compression, mode connecté, contraintes temps réel) et de type données (débit quelconque, mode connecté ou non, pas de contraintes temporelles strictes).

Chaque type d'application fait appel à des entités AAL spécifiques. L'ITU a défini trois classes de services AAL numérotées 1, 2 et 5. Dans le cadre de l'UMTS, seules l'AAL2 et l'AAL5 sont utilisées. Les AAL de types 3 et 4, définies initialement, ont été abandonnées.

AAL-1 AAL-2 AAL-5

Caractéristiques Relation

temporelle source-

destination

Oui Non Caractéristiques

Débit Constant Variable

Caractéristiques

Mode de connexion

Oui Non

Remarque plusieurs connexions dans un CV

identifiées par leCID

adapté au transfert de blocs

de données de taille variable (par exemple signalisation)

Utilisation dans l'Utran Non Oui Oui

Figure 6.15. Caractéristiques des différents AAL

Le service AAL5 permet de transmettre des blocs de données de taille variable (jusqu'à 65 535 octets). Il convient aux transmissions de données sans forte contrainte de délai.

Le service AAL1 convient au trafic à débit constant (téléphonie, vidéo, liaisons louées). Il a été spécifié dans les années 90 dans une optique de communications téléphoniques codées à 64 kbit/s et convient peu aux communications mobiles où, pour des questions d'économie, on utilise des codeurs de paroles à des débits inférieurs 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 entièrement une cellule. Pour un utilisateur donné, il n'est pas possible d'attendre plusieurs blocs avant de les transmettre à cause des contraintes de délais.


L'AAL2 a été spécifié pour permettre un multiplexage, sur un même circuit virtuel, de plusieurs communications. On définit une mini-cellule avec un en-tête de 3 octets qui contient un numéro de canal (CID, Channel Identifier). Plusieurs mini-cellules peuvent être placés dans une même cellule ATM. La transmission de mini-cellules avec un même numéro de canal CID forme un microcircuit (le qualificatif virtuel est sous-entendu). Dans cet ouvrage, on utilise indifféremment 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 prévoir la signalisation capable d'établir, entre deux extrémités, des services (transmission de voix, de vidéo). Dans le réseau téléphonique fixe, on a développé une pile de protocoles pour la signalisation sémaphore : MTP 1, MTP 2 et MTP 3 avec un protocole téléphonique (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 spécifié par l'ITU dans la recommandation Q.2630.1. C'est un protocole qui définit 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 Spécifié Connection Oriented Protocol), défini dans la recommandation Q.2110 de l'ITU-T, qui contient les mécanismes d'établissement et de libération de connexion et l'échange fiable de signalisation (détection et correction d'erreurs, contrôle d'intégrité) ;

- SSCF-NNI (Service Spécifié Coordination Function for Network to Network Interface), défini dans la recommandation Q.2140, qui permet d'adapter les exigences des couches supérieures en fonction des contraintes spécifiques de SSCOP (contrôle de flux entre couches, reconfiguration de route, procédure de basculement de canal sémaphore,...) ;

- MTP3b (Message Transfer Part 3 broadband), défini dans la recommandation Q.2210, qui permet le routage des messages au sein du réseau de transport ;

-Q.2150.1, du nom de la recommandation ITU qui le définit, qui permet l'adaptation du protocole de niveau supérieur à MTP3b.

Sur les interfaces UNI, c'est-à-dire à l'accès du réseau ATM, il n'y a pas de problème de routage : MTP3b est donc inutile. La pile de protocole est légèrement simplifiée, comme indiqué en figure 6.17.


Notons que ces piles de protocole sont contenues dans le plan de contrôle {controlplane) alors qu'AAL2, qui est utilisé pour transporter des données, est dans le plan usager.

Figure 6.17. Plan de contrôle et plan d'usager pour AAL2 sur une interface UNI

Il est peut être utile, dans un réseau RNIS-LB, d'échanger de la signalisation pure, indépendamment de l'établissement de circuits virtuels. Dans ce cas, on utilise le protocole SCCP (Signalling Connection Control Protocol), qui remplit ce rôle au-

Figure 6.16. Plan de contrôle et plan d'usager pour AAL2 sur une interface NNI


dessus de MTP dans le réseau téléphonique. Notons que SCCP peut-être utilisé pour tout type d'information : si SCCP transporte de la signalisation interprétée comme telle par le réseau RNIS-LB, il sera alors dans le plan de contrôle (Control Plane) ; dans le cas contraire, il est dans le plan d'usager (User Plane).

6.2.3. Réseaux 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'expéditeur et l'adresse du destinataire. En version IPv4, l'adresse est codée sur 32 bits ; pour faire face, entre autres, au problème de saturation d'adresses, la version IPv6 définit un adressage sur 128 bits.

Un réseau datagramme n'offre généralement pas une garantie de qualité de service (possibilité de déséquencement et de pertes de paquets). Lorsque les équipements extrémités peuvent se satisfaire de la qualité de service du réseau, on peut utiliser le protocole UDP, User Datagram Protocol, comme protocole de niveau transport.

Lorsqu'il est nécessaire de garantir une transmission sans perte ni dé-séquencement, on utilise généralement le protocole TCP, Transmission Control Protocol. C'est un protocole orienté connexion qui, par une numérotation des octets transmis, gère un mécanisme de retransmission des données perdues [TOU 03]. Le fonctionnement de TCP repose sur le constat que, dans les réseaux IP filaires, les pertes sont dues à une saturation mémoire de routeurs intermédiaires et non à un problème de transmission. Le protocole TCP possède un mécanisme sophistiqué de contrôle de congestion entre les équipements qui a pour objet de réduire le flux de données en cas de congestion du réseau. Les mécanismes de retransmission et de contrôle de congestion empêchent d'utiliser TCP pour toutes les applications qui ont de fortes contraintes de délai. On préfère dans ce cas utiliser UDP, ce qui impose de tolérer des pertes de données.

6.2.3.2. Transmission d'IP sur A TM

De nombreux réseaux IP sont basés sur une infrastructure ATM. Le réseau dorsal est constitué de brasseurs ATM. Les routeurs IP, munis de cartes de transmission ATM, sont les utilisateurs du réseau dorsal ATM. En définissant des circuits virtuels permanents ATM entre les routeurs IP, l'opérateur peut constituer un réseau de routeurs IP avec un haut niveau de maillage, comme si ces routeurs étaient physiquement reliés entre eux.


Vus du réseau dorsal ATM, les routeurs IP sont des équipements extrémités (endpoint). La couche d'adaptation utilisée est AAL5. Celle-ci est très simple et correspond bien à l'optique IP où toutes les fonctions complexes sont repoussées 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 données n'ayant pas de contraintes temporelles. Il n'est pas conçu pour transférer des messages de signalisation sur un réseau IP. TCP souffre du problème de « Head Of line Blocking » qui fait qu'en présence d'une perte de paquet, toute la transmission sur la connexion en cours est interrompue jusqu'à la reprise de cette erreur. Cela est gênant pour le transport de la signalisation, car une même connexion TCP peut véhiculer plusieurs transactions de signalisation. Pour le cas d'appels téléphoniques, cela signifierait par exemple, que la perte d'un segment TCP bloquerait tous les établissements d'appels en cours véhiculés sur la même connexion. Pour répondre à ces besoins, l'IETF a spécifié un nouveau protocole dans la RFC 2960 : SCTP, Stream Control Transmission Protocol. C o m m e TCP, il assure un transfert de données sans duplication et sans erreurs et il est orienté connexion, mais le contrôle 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 définir plusieurs flux logiques dans une même association, sans qu'un problème sur un flux n'affecte les autres flux.

6.2.3.4. Couche M3UA

La couche M3UA (SS7 MTP3-User Adaptation Layer) spécifiée au sein de l'IETF dans la RFC 3332 a pour objet de mimer l'interface (au sens des couches OSI) présentée par MTP3b [RFC 3332]. Elle permet donc de développer un réseau de signalisation sémaphore sur un réseau de transport IP. Au-dessus de M3UA, on peut mettre les mêmes couches qu'au-dessus de MTP3, par exemple la couche SCCP.


6.3. Principes généraux de l'architecture en couches dans UTRAN

6.3.1. Strates d'accès et de non-accès

Dans un réseau fixe, le terminal est généralement relié de façon permanente à un commutateur ou à un routeur par une liaison filaire. Il n'y a pas à proprement parler de réseau d'accès mais un ensemble de liaisons d'accès ; les interfaces sont spécifiées au niveau physique. Les échanges se font directement entre le terminal et le réseau cœur (c'est-à-dire un commutateur ou un routeur). Ces échanges peuvent concerner le plan d'usager ou le plan de contrôle.

Dans le cas d'un réseau UMTS, l'ensemble des services offerts à l'usager est fourni par le réseau cœur comme pour un réseau fixe. Le réseau d'accès UTRAN doit donc être le plus transparent possible. Son rôle consiste à offrir la possibilité au terminal de dialoguer avec le réseau cœur pour la réalisation de ces services.

Le réseau UTRAN vient se placer entre le terminal et le réseau cœur. Les concepteurs de l'UMTS ont voulu garder les mêmes protocoles que dans le cas d'un réseau fixe et, de plus, spécifier ces protocoles de façon indépendante de la technologie utilisée à la fois sur l'interface radio et sur l'interface lu. On spécifie donc dans l'UMTS :

- les mécanismes permettant d'établir des dialogues entre le terminal et le réseau UTRAN. Ces mécanismes sont liés à la technologie radio utilisée mais permettent de transporter des messages entre le terminal et l'UTRAN indépendamment de la technologie radio ;

- les mécanismes permettant d'établir des dialogues entre le réseau UTRAN et le réseau cœur. Ces mécanismes sont liés à la technologie utilisée pour le réseau de transport du réseau cœur mais permettent de transporter des messages sur l'interface lu indépendamment de la technologie ;

- les dialogues entre terminal et réseau cœur de façon totalement indépendante des technologies du réseau d'accès (radio et lu).

Les recommandations parlent de « strate d'accès » (AS, Access Stratum) dans les deux premiers cas et de « strate de non-accès » (NAS, Non-Access Stratum) dans le dernier cas. Les strates sont représentées à la figure 6.19. Par exemple, les échanges pour effectuer un handover font partie de la strate d'accès, en revanche l'établissement d'un appel téléphonique ou une mise à jour de localisation fait partie de la strate de non-accès.


Source : [25.401]

Figure 6.19. Strates d'accès et de non-accès

Le concept de strate de non-accès permet de spécifier les protocoles d'établissement d'appels téléphoniques, d'échanges de messages courts, etc. directement entre le mobile et le réseau cœur sans considérer le réseau d'accès UTRAN. Aucun dialogue NAS n'est donc décrit dans ce chapitre.

6.3.2. Notion de support de transport (transport bearer)

Les données et la signalisation sont échangées entre le mobile et le réseau cœur via les différentes interfaces de l'UTRAN (lu, Iub, Iur) ; elle transitent à travers le réseau de transport. Sur ce dernier, circulent donc des paquets concernant différents mobiles et différents équipements de l'UTRAN. Pour permettre un repérage facile des données liées à 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 nœud B et un RNC) pour permettre le transfert de messages liés à un contexte.

Si l'on utilise un réseau 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 réseau IP, il n'y a pas de notion de connexion ; le support de transport est alors identifié par les


adresses IP des équipements extrémités du réseau de transport (par exemple un RNC et un nœud B) et par un numéro de port UDP (ou un numéro de tunnel GTP).

Un support de transport peut être établi pour transporter des données usagers ou de la signalisation de niveau supérieur. Le réseau de transport ne se préoccupe pas du type de données transportées.

6.3.3. Notion de support d'accès radio (RAB, Radio Access Bearer)

La notion de support (bearer) n'est pas restreinte au réseau 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 données usagers. Il faut souligner que les extrémités du support radio sont le mobile et le RNC serveur mais que le support radio implique aussi le nœud B et éventuellement un RNC en dérivation et par conséquent 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 données usagers. La signalisation est transportée 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 façon transparente. Pour les données, on utilise un microcircuit AAL2, dénommé dans ce contexte lu bearer. L'aboutement d'un support radio et d'un support lu forme un support d'accès radio RAB (Radio Access Bearer). Un RAB est donc utilisé pour effectuer la transmission des données usagers entre le mobile et le réseau cœur circuit ou paquet.

Figure 6.20. Notion de RAB


Contrairement à GSM où les débits sont fixes ( 16 kbit/s et 64 kbit/s), le RAB peut avoir un débit paramétrable: 12,2 kbit/s pour un usager qui est en communication téléphonique et 128 kbit/s pour un usager qui fait de la transmission de données.

Figure 6.21. Souplesse apportée par la notion de RAB

6.3.4. Les différents plans

La présence d'un réseau de transport complique l'architecture en couches du réseau d'accès : outre les protocoles d'échange des données utilisateur et les protocoles de signalisation, il faut prévoir les mécanismes pour établir les circuits virtuels entre nœuds B et RNC et entre RNC eux-mêmes. Ces trois éléments constituent trois plans différents : plan usager, plan de contrôle et plan de contrôle du réseau de transport.

Le plan de contrôle du réseau de transport (Transport Network Control Plane) contient l'ensemble des couches permettant d'établir, maintenir et libérer des connexions entre les équipements du réseau d'accès (nœuds B et RNC). La couche la plus haute porte le nom générique d'ALCAP (Access Link Control Application Part). Dans la pratique, ALCAP est le protocole Q.2630.1 présenté au paragraphe 6.2.2.4. Au niveau du réseau de transport, il s'agit de signalisation qui fait donc bien partie d'un plan de contrôle (control plane).

Tous les autres échanges font partie du plan d'usager pour le réseau de transport {Transport Network User Plane). Les flux de données utilisateurs (voix, vidéo, données) font partie du plan d'usager sans aucune ambiguïté. Cependant, le réseau de transport sert aussi à échanger de la signalisation UMTS (handover, mise à jour de localisation, établissement d'appel, service supplémentaire). Ces échanges font donc partie du plan de contrôle pour le réseau UTRAN mais appartiennent au plan d'usager vu du réseau de transport car ce dernier n'interprète pas le contenu de ce qu'il transporte. Les différents plans sont représentés sur la figure 6.22. Lorsqu'on parle de plan d'usager et de plan de contrôle, il faut bien spécifier à quel niveau on se situe.


Source : [25.401]

Figure 6.22. Différents plans sur les interfaces de l'UTRAN

6.4. Pile de protocoles de l'UTRAN avec un réseau de transport ATM

6.4.1. Interface Uu

L'interface Uu entre le mobile et le réseau UTRAN est présentée 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 mécanismes de transmission entre le mobile et le nœud B. La couche MAC permet de disposer de canaux de transport de données avec un certain degré de protection contre les erreurs (FEC, Forward Error Correction). La couche RLC (Radio Link Control) gère les mécanismes de retransmission sur erreur si nécessaire (ARQ, Automatic Repeat reQuest).

La couche RRC (Radio Resource Control) joue un rôle 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 réalisant des échanges de messages entre le mobile et l'UTRAN.


Figure 6.23. Structure des protocoles sur l'interface Uu

Localisation des entités

Canaux logiques

Canaux de transport utilisés

Nœud B RNC Contrôleur

RNC serveur

canaux logiques

DCH Physique Phy/MAC/RLC canaux logiques DSCH Physique MAC MAC/RLC dédiés HS-DSCH Phy/MAC MAC/RLC

RACH/FACH Physique MAC MAC/RLC canaux

communs RACH/FACH Physique MAC/RLC

canal paging

PCH Physique MAC/RLC/RRC

voie balise BCH Phy/MAC /RLC/RRC

RRC

L'entité physique dans le RNC permet d'assurer la diversité de réception (macrodiversité) Les entités au-dessus de la couche RLC (RRC dans le plan contrôle, PDCP dans le plan usager pour le mode paquet) sont toujours localisées au même lieu que RLC sauf pour le BCH dans certains cas.

Figure 6.24. Localisation des entités suivant les différents canaux logiques


Les entités protocolaires côté UTRAN ne sont pas toujours localisées dans le même équipement suivant les différents canaux logiques [25.301]. Le cas le plus courant est constitué par les services d'échange d'information entre un mobile et le réseau (communication vocale, service Web,...) qui utilisent les canaux logiques dédiés. Dans ce cas, les entités MAC et RLC sont localisées dans le RNC serveur. Une partie de la couche physique est également présente dans le RNC pour permettre la macrodiversité. Lorsque le canal logique dédié est fourni par un canal commun ou partagé, quelques fonctions MAC sont placées dans le RNC contrôleur, ou même dans le Node B (par exemple le MAC-hs dans le cas de HS-DSCH).

Lorsque les informations ne sont pas échangées avec un mobile particulier (canaux logiques dédiés), les entités sont placées dans le RNC contrôleur. Pour la voie balise, les entités MAC et RLC sont directement dans le nœud B (voir tableau de la figure 6.24).

6.4.2. Interfaces lu

L'interface lu se place entre le réseau d'accès UTRAN et le réseau cœur. Lorsque ce dernier est basé sur la commutation de circuits, on parle d'Iu-Cs (Circuit-Switched), lorsqu'il est basé sur la commutation par paquets, on parle d'Iu-Ps (Packet Switched). Les deux interfaces peuvent coexister (voir figure 6.6).

6.4.2.1. Interface lu-Cs

La pile de protocole de l'interface lu-Cs est assez complexe du fait des choix faits :

-utilisation de microcircuits AAL2 établis à la demande pour transporter les données utilisateurs ;

- utilisation de la signalisation sémaphore numéro 7 (Signalling System 7) ;

- utilisation d'un réseau de transport ATM.

L'interface lu-Cs ne repose pas, à strictement parler, sur la commutation de circuits. En effet, les données utilisateurs sont transportées sur une connexion AAL2. Cette connexion est réalisée 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 nécessaire d'échanger de la signalisation, fonction assurée 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 spécifique à l'UMTS. Ils ont été définis dans le cadre des réseaux ATM.


Dans le plan d'usager du réseau de transport, on retrouve également une couche physique et la couche ATM. Pour le transport de la signalisation AS, on réutilise 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 réseau cœur. SCCP est utilisé pour certains dialogues en mode non connecté mais il est surtout intéressant 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 rôle : 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 réseau cœur. Grâce au protocole RANAP, le réseau cœur 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'après [25.410])

6.4.2.2. Interface lu-Ps

Comme pour l'interface lu-Cs, les échanges sur l'interface lu-Ps se font sous la forme de cellules ATM. On retrouve donc une couche ATM et une couche physique commune. L'interface lu-Ps se distingue de l'interface lu-Cs par le fait


qu'aucune connexion AAL2 n'est établie à la demande lors d'un début 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 contrôle du réseau de transport.

. Les données 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 précisément 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 façon classique ATM et AAL5.

La transmission de signalisation UMTS peut se faire suivant deux optiques : soit on considère un réseau sémaphore s'appuyant directement sur le réseau de transport ATM, soit on considère un réseau IP sur ATM transportant la signalisation sémaphore. 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 même pas développé), on trouve IP, SCTP et M3UA. Quelle que soit l'approche considérée, le protocole SCCP est utilisé pour transporter les messages RANAP. Le protocole RANAP a le même rôle que dans le cas de l'interface lu-Cs.

Figure 6.26. Structure des protocoles sur l'interface lu-Ps (Source : [25.410])


6.4.3. Interface Iub

Les échanges entre un nœud B et un RNC se font via un réseau de transport. On retrouve donc la couche ATM sur Y interface Iub. Pour la transmission des données usagers, TAAL2 est utilisé. Pour établir les microcircuits AAL2 entre le nœud B et le RNC, on retrouve le protocole Q.2630.1. Cependant le nœud B est vu comme un utilisateur du réseau de transport : l'interface entre le nœud 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 données échangées par le mobile circulent dans des canaux logiques sur l'interface radio. Elles sont également échangées sur l'interface Iub grâce à des protocoles FP (Frame Protocol). Ces protocoles transfèrent directement les données dans des trames de longueur variable en rajoutant un en-tête très simple. On a un protocole FP par canal de transport susceptible de transporter des données 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 transférer à la fois les données 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 contrôle. Ces trames sont utilisées pour la gestion de la synchronisation et le contrôle de flux pour le DSCH et le HS-DSCH.

Les protocoles FP permettent de transporter de façon transparente les PDU MAC (dans la plupart des cas).

Figure 6.27. Structure des protocoles sur l'interface Iub (Source : d'après [25.430])


Le protocole NBAP (Node B Application Part) est utilisé pour les dialogues entre le RNC et le nœud B. Il permet les fonctions suivantes :

- gestion des liens radios ;

- remontées des mesures radio effectuées par le mobile et par le nœud B sur un canal dédié ;

- commande de contrôle de puissance vers le nœud B ;

- gestion des canaux de transport commun ;

- remontée des mesures communes (se référant à la cellule toute entière, par exemple puissance totale d'émission) ;

- configuration de cellules.

Les trois premiers types de messages concernent un mobile particulier, ils sont donc liés à la fonction de RNC serveur (serving RNC). Les autres messages ont trait à la fonction RNC contrôleur (controlling RNC). La signalisation NBAP est échangée sans connexion. Elle utilise la pile de protocoles AAL5, SSCOP et SSCF-UNI.

6.4.4. Interface Iur

L'interface Iur présente des similarités avec l'interface Iub quant aux piles de protocoles. Il faut permettre au RNC en dérivation (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 utilisés. Ils peuvent être transportés soit en considérant une pile basée sur IP, avec IP, SCTP et M3UA, soit une pile basée sur le SS7, avec SSCOP, SSCF-NNI, MTP3b.

Le protocole RNSAP, Radio Network Subsystem Application Part, permet la gestion du lien radio, des mesures radio sur les canaux dédiés et du contrôle de puissance. Cette gestion est liée à un mobile particulier. RNSAP est utilisé aussi pour la gestion des canaux de transport communs et pour des procédures globales non liées à un mobile. Le protocole RNSAP utilise la signalisation sémaphore. On retrouve donc SCCP sur une interface de type NNI (et non UNI comme Iub).


Figure 6.28. Structure des protocoles sur l'interface Iur (Source : [25.420])

6.4.5. Synthèses des piles de protocoles

La figure 6.29 représente les couches mises en œuvre dans l'UTRAN pour un service de type circuit. Cette représentation fait abstraction du plan de contrôle du réseau de transport (c'est-à-dire l'ensemble des entités mises en œuvre pour établir des connexions AAL2). De plus, on représente les entités 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 nœud B ou le RNC en dérivation.

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 représenter 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 représente les couches mises en œuvre dans l'UTRAN pour un service de type paquet. Les mêmes conventions que pour le service circuit sont utilisées.

Sur fond blanc, sont représentées les entités qui traitent à la fois le contrôle et les données utilisateurs (c'est-à-dire couches basses où on ne sépare pas les plans U et C). Sur fond gris clair sont représentées les entités du plan contrôle. Sur fond gris foncé, sont représentés les entités du plan usager.

Figure 6.29. Synthèse des couches de l'UTRAN pour un service C S avec transport ATM (schéma simplifié)


6.5. Pile de protocoles de l 'UTRAN avec un réseau de transport IP

L'utilisation d'un réseau de transport IP ne modifie pas fondamentalement les piles de protocole. L'interface Uu est bien sûr inchangée et l'ensemble de la couche réseau radio (radio network layer) est conservée sur toutes les interfaces (lu, Iub et Iur). Du fait qu'IP est sans connexion, le plan de contrôle du réseau est vide. La signalisation UTRAN est transportée par le protocole SCCP comme avec un réseau de transport ATM mais SCCP s'appuie dans ce cas sur M3UA (et non MTP3b) lui-même utilisant SCTP.

Figure 6.31. Protocoles sur l'interface Iu-CS avec un réseau de transport IP

Sur l'interface Iu-CS, les données usagers sont transportées grâce au protocole de transport temps réel RTP {Real Time Protocol) [RFC 1889] sur UDP (voir figure 6.31) accompagné éventuellement du protocole de contrôle RTCP (RTP Control Protocol) [RFC 1889]. La pile de protocole est donc assez différente du cas ATM. La pile de l'Iu-PS est beaucoup plus semblable. On utilise GTP-U au-dessus d'UDP-IP mais on fait l'économie de la couche ATM (voir figures 6.31a et 6.26).


Figure 6.31a. Protocoles sur l'interface Iu-PS avec un réseau de transport IP

Figure 6.32. Protocoles sur l'interface Iur avec un réseau de transport IP

Le passage d'IP à ATM permet de réduire l'empilement protocolaire sur les interfaces Iub et Iur. Sur l'Iub, la signalisation NBAP est directement transportée par SCTP/IP et les trames FP par UDP/IP. Sur l'interface Iur, on utilise SCCP comme avec un réseau de transport ATM mais au-dessus de M3UA/SCTP pour la signalisation RNSAP ; les trames FP sont transportées par UDP/IP. On peut également noter que le plan de contrôle du réseau de transport disparaît sur l'interface Iur (voir figure 6.32). L'ensemble des couches est représenté aux figures 6.33 et 6.34.


Sur fond blanc, sont représentées les entités qui traitent à la fois le contrôle et les données utilisateurs (c'est-à-dire couches basses où on ne sépare pas les plans U et C). Sur fond gris clair sont représentées les entités du plan contrôle. Sur fond gris foncé, sont représentés les entités du plan usager.

Figure 6.33. Synthèse des couches de l'UTRANpour un service CS sur transport IP (schéma simplifié)

Figure 6.34. Synthèse des couches de l'UTRANpour un service PS sur transport IP (schéma simplifié)

6.6. Présentations des protocoles sur l'interface radio

6.6.1. Couche MAC

Le rôle de la couche MAC est présenté au chapitre 2. Nous rappelons ici brièvement les principales fonctions :

- allocation dynamique des ressources de transport (DCA rapide) ;

- correspondance canaux logiques/canaux de transport ;

. I


- multiplexage des canaux logiques ; - gestion des priorités des différents types de trafic ; - gestion des canaux de diffusion et de paging ; - contrôle de puissance rapide ; - ARQ hybride (HARQ) pour la transmission sur HS-DSCH (HSDPA) ; -remise en séquence et assemblage et désassemblage des PDU des couches

supérieures 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 données. Il permet la fiabilisation, si nécessaire, de la liaison entre le mobile et l'UTRAN. Les mêmes procédures sont spécifiées dans le plan d'usager et le plan de contrôle mais il y a des instances différentes dans chaque plan. Suivant la qualité de service désirée, le protocole peut être utilisé en 3 modes :

- le mode transparent (TrD, Transparent Mode Data) où aucune vérification n'est effectuée ;

- le mode non acquitté (UMD, Unacknowledged Mode Data) où les trames erronées sont filtrées mais non retransmises (ces trames sont donc perdues et la perte est détectée) ;

- le mode acquitté (AMD, Acknowledged Mode Data) où un mécanisme ARQ (Automatic Repeat Request) permet la fiabilisation par retransmission des trames erronées ou perdues ; un mécanisme de contrôle de flux est également présent.

Pour les deux derniers modes, le protocole RLC réalise : - la segmentation et le réassemblage ; - la concaténation de données de niveau supérieur ; - le chiffrement (lorsqu'il est activé).

Le RLC est un protocole très souple qui offre de nombreuses flexibilités dans le transport des données. Le mécanisme 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 même PDU RLC. L'en-tête des PDU RLC est de longueur variable suivant les cas.


Figure 6.35. Segmentation et groupage par RLC

6.6.2.1. Types de PDU

La norme fait la distinction entre les PDU de données et les PDU de contrôles. Les PDU de données transportent un SDU tandis que les PDU de contrôle ne contiennent que des informations liées au protocole RLC.

Dans le mode transparent, il n'y a que des PDU de données. De plus, il n'y a aucun en-tête rajouté par l'entité RLC. Un PDU correspond donc exactement à un SDU. Dans les autres modes, l'entité RLC rajoute un en-tête pour former un PDU de données. Celui-ci contient un numéro de séquence (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 contrôle sont les suivants : - remise à zéro de toutes les variables internes (numérotation, attente

d'acquittement) ; - acquittement de la remise à zéro ; - acquittement ou non acquittement de données.

6.6.2.2. Formats général de RLC

Le protocole RLC reprend les principes désormais classiques des protocoles de liaisons de données [LAG 98] :

- numérotation des PDU pour détecter les PDU manquant à la réception ;


-gestion d'une fenêtre d'anticipation (possibilité d'émettre plusieurs PDU à la suite sans avoir d'acquittement) ;

- rejet sélectif possible (retransmission seulement des blocs de données mal reçus) ;

-piggy-backing (possibilité d'envoyer des données et d'acquitter dans un même bloc transmis).

Le protocole RLC offre en plus certaines fonctionnalités peu répandues dans les réseaux :

- modification dynamique de la fenêtre d'anticipation de l'émetteur ;

- forçage de la fenêtre du récepteur.

L'originalité du RLC réside dans la définition très souple des formats de PDU. Grâce à la notion de super-champ et de récursivité, il est possible d'inclure dans un PDU de données un nombre variable de PDU de contrôle. En transmettant un seul bloc, il est par exemple possible de transmettre un PDU de données et un PDU de contrôle qui acquitte des données reçues et modifie la taille de la fenêtre d'anticipation.

6.6.3. Couche RRC

6.6.3.1. Services rendus par RRC

La couche RRC (Radio Resource Control) gère 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 contrôle1. Elle permet également de transporter les messages de signalisation de niveau supérieur, qui sont nécessairement de la signalisation NAS (Non Access Stratum), en établissant une connexion, appelée connexion RRC, entre le terminal et l'UTRAN. Du point de vue contrôle, chaque entité RRC a également une action sur les entités 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 transportés comme des données 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 données dans le plan contrôle.


- contrôle de puissance lent ; - allocation et répartition des ressources (DCA lent) ; - gestion de la qualité de service des supports radios.

6.6.3.2. Connexion RRC

Dans beaucoup de systèmes, une connexion établie entre deux points correspond à une réservation de ressource entre ces deux points. Par exemple en GSM, il y a connexion lorsqu'un canal dédié est alloué en propre au mobile par la station de base. Pour les applications multimédias conversationnelles, il serait coûteux de réserver une ressource radio pendant toute la durée d'une session alors que, très souvent, il n'y a aucun transfert de données car l'utilisateur est en train d'étudier les données (texte, image,...) qu'il vient de recevoir. Pour économiser des ressources, on cherche donc à allouer véritablement de la ressource seulement lorsqu'il y a transfert : c'est le principe du mode paquet. Cependant, il est nécessaire de mémoriser un contexte correspondant à une session en cours entre deux transferts pour accélérer les procédures d'allocation de ressource. Par exemple, il est utile de mémoriser la cellule où se trouve l'abonné car il y a peu de chances qu'il se déplace entre deux transferts de données.

Une connexion RRC comprend donc différents états correspondant à différents niveaux de ressource allouée comme indiqué à la figure 6.36.

L'état de veille (idle) correspond à un mobile non connecté. Aucune ressource n'est allouée à ce mobile. On peut remarquer que sa localisation est connue dans le réseau cœur à la zone de localisation près mais que le mobile n'est pas connu, ni géré par le réseau UTRAN

Dans l'état Cell DCH, un canal dédié est alloué au mobile. Le réseau UTRAN sait donc parfaitement dans quelle cellule (ou quelles cellules) se trouve le mobile. La mobilité du terminal est contrôlée par le réseau UTRAN en fonction des mesures effectuées par le terminal et le réseau (voir procédure de handover).

Dans l'état Cell_FACH, aucun canal dédié 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 utilisés que lorsqu'il faut effectivement transmettre des données. Si le mobile (en fonction des critères radio) se cale sur une nouvelle cellule, il le signale au réseau. Le réseau, en fonction de la configuration choisie par l'opérateur, peut demander au mobile de transmettre des mesures et en conséquence peut demander au mobile de se caler sur une autre cellule. Dans l'état Cell FACH, la mobilité est donc contrôlée par le mobile ou par le réseau UTRAN.


Dans l'état Cel lPCH, le mobile se contente de lire le PCH (Paging Channel) (et le BCH, Broadcast Channel, pour vérifier que les informations système ne changent pas). Il peut ainsi détecter toute demande de la part du réseau. Le mobile décide de façon autonome de la cellule sur laquelle il se positionne en fonction des mesures et des critères radio (voir chapitre 2). Lors de tout changement de cellule, il indique au réseau la nouvelle cellule où il se trouve. Le réseau connaît donc la cellule où se trouve le mobile ; s'il cherche à joindre le mobile, il envoie en conséquence un appel sur le canal PCH de la cellule concernée.

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 réseau 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 différents états RRC est résumée 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 procédure 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'opérateur). Notons que les zones de localisation sont définies au niveau du réseau cœur alors que les zones URA sont définies au niveau UTRAN. Il est cependant vraisemblable qu'une URA soit incluse dans ou égale à une LA.

Figure 6.36. Etats RRC


Canal de transport montant

Canal de transport

descendant

Contrôle de la mobilité

Niveau d'activité

Connaissance par UTRAN

CellDCH DCH DCH réseau +++ Oui CellFACH RACH FACH mobile ou réseau ++ Oui Cell PCH PCH, BCH mobile + Oui URAPCH PCH, BCH mobile - Oui Veille (Idle) PCH, BCH mobile - Non

Figure 6.37. Activités du mobile dans les différents états RRC

Dans l'ensemble des états de type connecté (Cell-DCH, Cell-FACH, Cell-PCH et URA-PCH) le mobile est connu du réseau UTRAN. Un contexte est mémorisé dans le RNC serveur. Pour accélérer les procédures et rendre le réseau d'accès indépendant du réseau coeur, on alloue au mobile une identité appelée RNTI (Radio Network Temporary Identity). Cette dernière identifie la connexion RRC d'un mobile donné au sein du réseau UTRAN. Elle n'est pas connue du réseau cœur. Pour permettre de minimiser la taille de l'identité et résoudre 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 allouée par ce dernier. Tant que le mobile reste sous un nœud B dépendant du même RNC, le s-RNTI suffit à identifier sans ambiguïté 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 appelée s-RNCID (Serving RNC IDentity). Par exemple, lorsqu'un mobile dans l'état cell-PCH ou URA-PCH passe dans une cellule dépendant d'un RNC différent, il utilise le u-RNTI ; cela permet au nouveau RNC (qui, dans ce contexte, est un RNC en dérivation) de retrouver le RNC serveur.

En cas de procédure de relocalisation, le u-RNTI est changé. Dans tous les autres cas, il est constant pendant la durée de la connexion RRC.

6.7. Exemples de procédures de signalisation

Dans ce paragraphe, on présente quelques exemples de procédures de signalisation pour montrer la mise en œuvre des concepts présentés dans les paragraphes précédents. On se place dans le cas d'un réseau de transport ATM. Les procédures sont similaires avec un réseau de transport IP ; les phases


d'établissement de microcircuits AAL2 sont généralisées en établissement de support de transport « transport bearer ».

Lorsque les fonctions impliquent le réseau cœur (dialogue sur l'interface lu), on considère en général l'interface lu-Cs avec un MSC/VLR. Les procédures sur l'lu-Ps sont relativement voisines.

6.7.1. Etablissement d'une connexion RRC et son utilisation

Source : figures 8 de 25.931

Figure 6.38. Etablissement d'une connexion RRC

Dans la figure 6.38, on décrit les principaux messages échangés dans l'UTRAN lors du début d'un appel, d'un envoi de message, ou de tout service qui réclame 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 échangés sur les canaux radios de contrôle commun. Ce transport se fait grâce aux protocoles FP. Pour établir une connexion RRC, les protocoles RACH-FP et FACH-FP sont utilisés au début de l'établissement pour transporter les messages RRC.


Le mobile envoie un message de demande RRCConnect ionRequest sur un canal montant à accès aléatoire RACH. Il y précise son identité (par exemple son TMSI) et le type de service demandé. Ce message est reçu par le nœud B qui le retransmet au RNC sur la connexion AAL2 utilisée pour le protocole RACH-FP. Ce RNC va fonctionner en RNC serveur (serving RNC). Il va décider 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 dédié DCH est nécessaire. Le RNC envoie au nœud B un message Radio Link Setup Request précisant au RNC le canal de transport utilisé (formats de transports, fréquence, informations sur le contrôle de puissance). Ce message est échangé entre le RNC et le nœud B : il est donc de type NBAP. Le nœud B alloue les ressources, active sa réception et acquitte le message précédent. Pour permettre le transit des messages échangés entre le mobile et le RNC, il faut établir une connexion AAL2 entre le nœud B et le RNC ; cela est fait grâce au protocole ALCAP. Le nœud B établit une correspondance entre le canal DCH et la connexion AAL2 : tout message reçu sur le canal physique qui porte le DCH et caractérisé par un code OVSF particulier (voir chapitre 1) est transmis via le protocole DCH-FP sur la connexion AAL2 ; réciproquement, tout message reçu sur la connexion AAL2 est envoyé vers le canal DCH. Un échange de trames de contrôle du protocole DCH-FP est réalisé ensuite pour des questions de synchronisation. Le nœud B peut alors activer son émission. A ce moment, le réseau est prêt à dialoguer avec le mobile sur le canal dédié mais il faut indiquer au mobile les caractéristiques du canal dédié. 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 dédié DCH. Tous les messages sont retransmis par le nœud B vers le RNC grâce à la correspondance canal de transport - support de transport (transport bearer), ce dernier étant matérialisé 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 nécessaire d'échanger des messages NAS entre le mobile et le réseau cœur, représenté 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 dédié précédemment établi. Les recommandations parlent de connexion de signalisation NAS.

L'établissement et l'utilisation d'une connexion de signalisation sont représentés figure 6.39. On note que le type de réseau cœur est indiqué dans le message RRC Initial_Direct_Transfer. Lorsqu'il n'est plus nécessaire d'échanger des messages NAS, la connexion SCCP est libérée.


Figure 6.39. Transfert de messages NAS via une connexion RRC

6.7.2. Libération d'une connexion RRC

La figure 6.40 donne un scénario de libération d'une connexion RRC. Celle-ci est demandée par le réseau cœur (é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 différentes interfaces sont libérés.

Source : figure 9 de 25.931

Figure 6.40. Libération d'une connexion RRC


6.7.3. Etablissement d'une connexion RRC sur canaux FACH-RACH

Lorsqu'un service consiste à échanger seulement quelques messages NAS (par exemple une mise à jour de localisation sans authentification), il est coûteux d'établir un canal dédié. On peut dans ce cas établir une connexion RRC sur une paire de canaux RACH et FACH. Le déroulement est illustré figure 6.41. Il impose que des connexions AAL2 soient établies entre le nœud B et le RNC au moment de la configuration par l'opérateur de la cellule gérée par ce nœud B et que le nœud 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 décision différente : au lieu d'allouer un DCH, il décide d'utiliser une paire RACH-FACH. Ces deux canaux étant des canaux communs, il est nécessaire que toutes les transmissions ultérieures soient identifiées. 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 spécifie que cet identificateur est unique pour un mobile donné dans une cellule donnée. 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 ultérieurs portent le RNTI. Celui-ci est placé au niveau MAC.


Figure 6.41. Etablissement d'une connexion RRC sur RACH-FACH

Comme au paragraphe 6.7.1, il est possible d'établir une connexion de signalisation NAS. Le scénario est similaire à la figure 6.39. Cependant, les messages sont transmis sur un canal DCCH qui correspond à un RACH ou un FACH associé avec le C-RNTI (et non à un DCH).


6.7.4. Etablissement d'un RAB

Le RAB permet d'échanger, entre un mobile et le réseau cœur, des données usager avec certaines caractéristiques de débit, de délai, etc. En général, des échanges de signalisation ont déjà été effectués entre le mobile et le réseau au moment où on décide d'établir un RAB (authentification, signalisation d'appel). De ce fait, la connexion RRC est déjà établie. Nous nous plaçons dans un cas où un canal de transport dédié est déjà é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 définition, 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 indiqués dans la figure 6.42 qui impliquent le protocole NBAP et le protocole FP.


Figure 6.42. Etablissement d'un RAB en version synchronisée


6.7.5. Libération d'un RAB

Lorsqu'il n'y a plus de données utilisateur à transmettre, le réseau cœur peut demander la libération du RAB. Cela ne signifie pas nécessairement que la connexion RRC est libérée car il peut être nécessaire de continuer à échanger de la signalisation entre le mobile et le réseau. La norme ne définit pas un message RANAP spécifique de libération mais utilise le même message que l'allocation avec des paramètres différents (voir figure 6.43).


Figure 6.43. Libération d'un RAB en version synchronisée

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'intermédiaire du nœud B 1 se déplace vers un nœud B (nœud B 2) dépendant du RNC 2 (voir figure 6.7.) et continue son déplacement jusqu'à être hors de portée du nœud B 1.

Tout mobile ayant une connexion RRC activée avec un canal dédié (é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 nœud B 1. Le RNC 1 est le RNC


serveur et il analyse les mesures. Le signal reçu du nœud B 2 devenant par exemple de plus en plus fort, le RNC décide de mettre le mobile en macrodiversité, c'est-à-dire que deux liaisons radios via les nœuds B 1 et B 2 soient établies simultanément. La macrodiversité implique donc le RNC 2 qui va être RNC en dérivation {drift RNC). Le RNC serveur (RNC 1) demande au RNC en dérivation d'établir une liaison radio par un message RNSAP ; il précise les caractéristiques de la liaison (voir figure 6.44). Les échanges NBAP entre le RNC en dérivation et le nœud 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 données usagers sur les deux chemins de diversité. Lorsque toutes les connexions sont établies et que le nœud B 2 est actif en émission et en réception, un message RRC Active Set Update indique au mobile les caractéristiques du nouveau canal physique à mettre en œuvre. Le message est acquitté par le mobile. Selon toute vraisemblance, le message d'acquittement est reçu par le nœud B 1 et par le nœud B 2 et arrive jusqu'au RNC serveur.


Figure 6.44. Ajout d'un liaison radio (soft handover)


A l'issue de la procédure, le mobile est en macrodiversité : le canal de transport DCH est porté par deux liaisons physiques radios. Il reçoit les messages des deux nœuds B et sa transmission est reçue de ces mêmes 2 nœuds B.

Si le mobile revient sous la couverture exclusive du nœud B 1, le lien radio via le nœud B 2 peut être supprimé (retour à l'état initial). Les échanges protocolaires sont explicités dans la figure 6.45. Ils consistent à désactiver tout ce qui a été activé dans le scénario précédent : connexions AAL2 et liaison radio sur le nœud B 2.


Figure 6.45. Suppression d'une liaison radio

Considérons à nouveau la situation initiale avec le mobile sous la couverture exclusive du nœud B 1. S'il fait une transition franche d'une cellule à l'autre, l'UTRAN peut établir la nouvelle liaison radio via le nœud B 2 et supprimer l'ancienne via le nœud B 1 dans une même procédure. Ce scénario est illustré figure 6.46. Il s 'agit bien d 'un soft handover et non d 'un hard handover car l'émission et la réception du nœud B 1 sont désactivés après l'activation du nœud B 2. Pendant un court moment (c'est-à-dire pendant l'émission du message Act iveSetUpdateComplete) , le mobile se trouve en macrodiversité.



Figure 6.46. Ajout et suppression d'une liaison radio (soft handover)

6.7.7. Procédures de relocalisation

Suite à un ou plusieurs handover, il peut arriver qu'aucune liaison radio ne passe par un nœud B dépendant du RNC serveur et que toutes les liaisons passent par des nœuds B dépendant du RNC en dérivation. La procédure de relocalisation permet d'assigner le rôle de serveur à ce dernier RNC.

Dans l'exemple considéré, qui fait suite au scénario du paragraphe précédent, la procédure de relocalisation permet d'affecter le rôle de serveur au RNC 2 et de libérer le RNC 1 de tout rôle concernant le RAB du mobile. Elle permet également d'établir une connexion directe entre le RNC 2 et le réseau cœur : elle implique donc le réseau cœur. Nous supposons que les RNC 1 et RNC 2 sont reliés au même MSC/VLR (voir figures 6.8 et 6.9).

Un scénario de relocalisation est présenté à la figure 6.47. Le RNC 1 indique au MSC/VLR qu'une relocalisation est nécessaire : il précise l'identité du RNC cible, c'est-à-dire celui qui doit devenir RNC serveur (ici le RNC 2), et les paramètres d'identification de la liaison radio devant être transportés de façon transparente par le MSC/VLR vers le RNC cible. Le MSC/VLR réserve les


ressources internes pour effectuer la commutation le moment venu. Il envoie ensuite la demande de relocalisation au RNC 2. Ce dernier établit une connexion AAL2 sur l'interface lu nécessaire à 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 procédure de relocalisation proprement dite peut alors être effectuée. 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-même avertit le MSC/VLR (messages RANAP RelocationCommand, RNSAP RelocationCommit et RANAP Relocation Detect). A l'issue de cet échange, le RNC 2 prend le contrôle des entités protocolaires (MAC, RLC , RRC) et le MSC/VLR commute le trafic usager vers le RNC 2. La relocalisation est faite avec succès lorsque le RNC 2 envoie le message RANAP RelocationComplete. Il reste alors à libérer toutes les ressources liées au RNC 1. On peut noter que cet échange ne provoque aucune modification des ressources radio allouées au mobile. Il peut être cependant nécessaire d'allouer un nouveau RNTI au mobile ; pour le reste, la procédure est totalement transparente pour le mobile.


Figure 6.47. Procédure de relocalisation


6.8. Bibl iographie

[25.322] 3rd Génération Partnership Project, « Technical Spécification Group Radio Access Network; RLC Protocol Spécification », 3G TS 25.322, version 3.1.2.

[25.331] 3rd Génération Partnership Project, «Radio Resource Control (RRC) protocol spécification », 3G TS 25.331.

[25.401] 3rd Génération Partnership Project, UTRAN Overall Description, Technical Spécification Group Radio Access Network, 3G TS 25.401.

[25.410] 3rd Génération Partnership Project; UTRAN lu Interface: General Aspects and Principles, Technical Spécification Group Radio Access Network, 3G TS 25.440.

[25.420] 3rd Génération Partnership Project; UTRAN Iur Interface General Aspects and Principles, Technical Spécification Group Radio Access Network, 3G TS 25.420.

[25.430] 3rd Génération Partnership Project; UTRAN Iub Interface General Aspects and Principles, Technical Spécification 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 spécifié 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, Définition 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 procédures, Q.714.

[RFC 1889] IETF RFC 1889 « RTP: A Transport Protocol for Real Time Applications», 1996.


[RFC 2 9 6 0 ] IETF RFC 2 9 6 0 « Stream Control Transmission Protocol (SCTP) », 2 0 0 2 .

[RFC 3332] IETF RFC 3332 « Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -User Adaptation Layer (M3UA) », 2000.

[CIZ 04] CLZAULT G, IPv6, théorie et pratique, 4e édition, O'Reilly, 2004.

[ K O F 9 6 ] KOFMANN D. , GAGNAIRE M . , Réseaux haut débit : réseaux ATM, réseaux locaux et réseaux Internet, Editions InterEditions, 1996.

[ L A G 9 8 ] LAGRANGE X . , S E R E T D . , Introduction aux réseaux, Editions Hermès, Paris, 1998,.

[ R I G 0 1 ] RIGAULT C . , Principes de communication numérique, du téléphone au multimédia, Editions Hermès, Paris, 1998.

[ R O L 02] ROLIN P. (coordinateur), Réseaux ATM, Collection IC2, Hermès 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 Réseaux et télécommunications, Editions Hermès, Paris, 2001.

[TOU 03] TOUTAIN L., Réseaux locaux et Internet, 3e édition revue et augmentée, Hermès Science - Lavoisier, 2003.

Chapitre 7

Le cœur de réseau UMTS

7.1 Introduction

Ce chapitre situe le cœur de réseau UMTS dans une évolution historique qui conduit les cœurs de réseaux des opérateurs de téléphonie mobile traditionnellement orientés commutation de circuit à évoluer vers des cœurs de réseau orientés paquets. Il s'attache en particulier à suivre la problématique de la gestion de la qualité de service lors des différentes évolutions des cœurs de réseaux de téléphonie mobile.

La première apparition d'un cœur de réseau orienté paquet dans un réseau de téléphonie mobile est le fait de l'ETSI qui intègre, dans la phase 2+ du GSM, un cœur de réseau IP pour une transmission plus efficace des données en mode paquet ; c'est le GPRS (General Packet Radio Service). Les motivations qui conduisent à un tel choix sont les mêmes que celles qui font le succès de l'Internet, à savoir la capacité de partager la même infrastructure entre un grand nombre d'utilisateurs, la souplesse de gestion et le faible coût des équipements d'interconnexion. En effet, le mode circuit, s'il permet une garantie de service stricte, est coûteux 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 caractéristiques relativement constantes mais ne permet pas d'utiliser efficacement les ressources du réseau dans le cas contraire. De plus il s'accompagne le plus souvent d'une facturation à la durée du fait que les ressources sont occupées dans

Chapitre rédigé par Jean-Marie BONNIN.


le réseau dès qu'une connexion est établie même lorsqu'elle n'est pas utilisée. Or ce modèle de facturation est mal adapté aux trafics très sporadiques habituellement observés sur l'Internet.

La standardisation du GPRS, puis des différentes versions de l'UMTS, a été déléguée au 3GPP qui poursuit la migration des cœurs de réseaux de téléphonie mobile vers des cœurs de réseaux tout IP. Dans un premier temps (Release 99), le cœur de réseau paquet est réservé aux trafics de données et ne subit que très peu d'évolution par rapport au réseau cœur GPRS. Dans un second temps, il ne devrait plus subsister qu'un seul cœur de réseau IP utilisé aussi bien pour les flux de données sans contraintes de qualité de service strictes que pour les flux multimédias conversationnels qui supposent une qualité plus contrôlée. Cette migration suppose donc la mise en place de mécanismes de gestion de la qualité de service élaborés dans les cœurs de réseaux IP.

Dans ce chapitre, nous nous attacherons à montrer les évolutions qui ont conduit à la Release 99 de l'UMTS. En particulier, nous présenterons le GPRS en ce qu'il est une première é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 première version de l'UMTS. Le lecteur intéressé se reportera utilement vers [LAG 00] pour la description du GSM. Nous décrivons ensuite le fonctionnement du cœur de réseau de l'UMTS et nous terminons en donnant les grandes lignes des évolutions à venir dans les releases 4 et 5.

7.2. Cœur de réseau en GSM et GPRS

Le cœur de réseau à commutation de circuit GSM est une évolution d'un réseau de téléphonie à intégration de services (RNIS) [SER91]. Il est composé d'un réseau de commutateurs de circuits permettant de commuter le trafic de téléphonie. Pour les besoins de la téléphonie mobile, certaines fonctionnalités proches des mécanismes et des concepts des réseaux intelligents ont été ajoutées. La gestion de la mobilité des terminaux est intégrée à la définition du GSM. Tout est donc fait pour assurer le maintien des communications lors d'un changement de cellule, même lorsque cela implique des changements dans le cœur de réseau (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 téléphonie. Nous verrons que, dans le cas du GPRS, certaines de ces contraintes sont allégées, ce qui permet une gestion plus souple de la mobilité.

Le cœur de réseau UMTS 273

7.2.1. Architecture du réseau GSM avant le GPRS

Les concepteurs du GSM se sont attachés à employer des solutions éprouvées pour le sous-système réseau. Ainsi, le cœur de réseau d'un réseau GSM est composé de commutateurs téléphoniques auxquels ont été ajoutées les fonctions nécessaires à la gestion de la mobilité (protocole MAP, Mobile Application Part) en suivant des principes similaires à ceux qui sont à l'œuvre dans les réseaux intelligents.

Figure 7.1. Architecture d'un réseau GSM

Deux fonctions ont été différenciées 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'intermédiaire des contrôleurs de station de base (BSC, Base Station Controller) du sous-système radio. Il s'occupe de la gestion d'une zone et des mobiles qui s'y trouvent grâce à une base de données 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 réseau GSM (le PLMN) avec un réseau de téléphonie fixe (PSTN) ou un autre PLMN. C'est lui qui va se charger de la gestion des communications entrantes. En pratique, on représente souvent un seul GMSC connecté à tous les MSC du réseau, mais en réalité la fonction de passerelle se


trouve intégrée dans tous les MSC. Cela permet de répartir la charge et de réduire la longueur des chemins empruntés dans le cœur de réseau.

Plusieurs bases de données sont essentielles au fonctionnement d'un réseau 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 données sont utilisées pour gérer la sécurité :

- le serveur d'authentification AuC (Authentication Center) fournit les clefs d'authentification et est en général associé à un HLR ;

- l'EIR (Equipment Identity Register) contient les listes des types de terminaux autorisés à fonctionner dans le réseau (liste blanche) et celle des terminaux interdits dans le réseau (liste noire).

Les terminaux sont identifiés dans l'EIR par une identité unique attribuée par le fabriquant : l ' IMEI (International Mobile Equipment Identity). La vérification de l'IMEI et la consultation de l'EIR ne sont pas imposées par les recommandations.

7.2.1.1. Le transport des données

Le transport des données est possible en GSM classique. Il utilise pour ce faire un circuit comme dans le cas d'une connexion par modem à travers un réseau de téléphonie commuté (RTC). Toutefois, comme les communications vocales sont encodées et compressées dans le cas du GSM, il est nécessaire d'utiliser un mode de fonctionnement particulier qui interdit au réseau d'appliquer les encodeurs spécialisés pour la voix aux communications orientées données.

En effet, ces encodeurs utilisent les spécificités de l'audition humaine pour réduire le débit nécessaire à la transmission de la voix. Ils suppriment une partie des informations inaudibles, ce qui a pour effet de rendre une communication encodée puis décodée incompréhensible pour un modem. Il est par conséquent nécessaire de différencier le trafic de données du trafic voix par une procédure de connexion spécifique qui sera utilisée 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 numérique de bout en bout. La norme GSM définit plusieurs circuits dans le sous-système radio : de 1,2 kbit/s à 14,4 kbit/s, mais les opérateurs français n'ont déployé que le mode à 9,6 kbit/s.

Du point du vue du cœur de réseau, les communications orientées données sont traitées de la même manière que les communications voix, c'est-à-dire que le circuit de 64 kbit/s est réservé dans le cœur de réseau pour toute la durée de la connexion.


Cela justifie la tarification à la durée appliquée par les opérateurs mais rend l'utilisation de ces services trop onéreuse pour une large part des utilisateurs.

7.2.1.2. Gestion de la qualité de service

Dans le réseau cœur, il n'y a pas de réelle gestion de la qualité de service puisque des circuits de 64 kbit/s sont réservés pour chaque connexion, qu'il s'agisse de données ou de voix. Un tel circuit est réservé pour chaque connexion même si le débit disponible sur le lien radio n'est que de 9,6 kbit/s. Le contrôle d'admission stricte effectué au moment de l'établissement d'une communication permet de rejeter une communication si le réseau ne dispose pas des ressources nécessaires.

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 réseau plutôt qu'une réelle gestion de la qualité de service. Aucun mécanisme de différenciation des flux n'est prévu dans le cœur de réseau, excepté pour les flux qui supposent un traitement particulier (ou une absence de traitement en l'occurrence), comme les connexions numériques de bout en bout.

7.2.2. Cœur de réseau GPRS : un premier pas vers l'UMTS

Avec la mise en œuvre du GPRS dans la phase 2+ du GSM, l'ETSI propose un cœur de réseau complètement différent du cœur de réseau GSM. Il conserve une interaction plus ou moins forte avec ce dernier en fonction des choix de l'opérateur et va jusqu'à proposer le remplacement de certains des mécanismes auparavant gérés dans la partie GSM (localisation, SMS) pour en améliorer l'efficacité. Il s'agit avant tout d'un cœur de réseau IP spécialisé dans le transport des données. Le mode de facturation est mieux adapté au trafic de données car on tient compte de la quantité de donnée transférée et non plus seulement de la durée de la communication.

7.2.2.1. Architecture du cœur de réseau mode paquet

Le cœur de réseau GPRS est entièrement nouveau, aussi bien en termes de protocoles que pour les entités impliquées. Il utilise par contre les bases de données définies pour le GSM, quitte à en modifier le contenu comme c'est le cas pour le HLR. Le rôle de ce cœur de réseau est de transporter les données depuis le réseau d'accès jusqu'aux réseaux de données, désignés sous le terme général de PDN {Packet Data Networks), ou vers d'autres réseau GPRS. Il a fallu ajouter à un réseau 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 intègrent les fonctions de sécurité (contrôle d'accès et filtrage) qui sont


nécessaires dès que l'on connecte un réseau commercial à l'Internet. Les différentes entités définies mettent en œuvre les mécanismes 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 réseau GSM/GPRS

Le GPRS est conçu comme un réseau de transport multi-protocoles capable d'offrir une connexion avec différents types de réseau de données (X25, IP) ; le support de PPP (Point to Point Protocol) lui permettant même de transporter virtuellement n'importe quel protocole supporté par PPP. Le protocole du réseau PDN est désigné par le terme générique de PDP (Packet Data Protocol). Le mécanisme de « contexte PDP » permet d'établir une connexion pour chaque réseau de données auquel le mobile se connecte. Un contexte est maintenu pour chaque connexion dans les équipements du réseau impliqués dans l'acheminement des données depuis et vers le mobile. Il comprend, entre autres informations, la qualité de service demandée, le type de réseau de données externe et les informations nécessaires à l'identification des connexions supportant la communication dans le cœur de réseau et dans le réseau d'accès.


7.2.2.1.1. SGSN et GGSN

Les deux nouvelles entités intégrées au cœur de réseau GPRS sont les GSN (GPRS Support Node) serveur et passerelle. Les GSN sont des routeurs IP enrichis de fonctions spécifiques au GPRS et d'interfaces leur permettant de communiquer avec les autres entités du PLMN. En particulier, le SGSN doit être capable d'échanger les informations avec le HLR et doit par conséquent disposer des couches protocolaires utilisées pour la signalisation dans le cœur de réseau circuit du GSM (SS7).

Le SGSN {Serving GPRS Support Node) est l'équivalent du MSC/VLR. Il gère un ensemble de zones de routage et s'interconnecte au sous-système radio par l'intermédiaire des contrôleurs 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 gère et s'occupe de la procédure 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 données échangées avec les terminaux.

Le GGSN (GPRS Service Support Node) est la passerelle entre le réseau GPRS et un réseau de données PDN. Les données échangées 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 réseau GPRS au niveau d'un SGSN (Serving GPRS Support Node) et peut ensuite activer un contexte PDP. Chacun de ces contextes PDP correspond à un réseau de données (PDN) auquel le mobile accède par l'intermédiaire d'une passerelle GGSN donnée (Gateway GPRS Support Node). C'est le SGSN qui gère les différents contextes PDP associés au mobile.

Lorsqu'il souhaite communiquer avec un PDN, le mobile active un contexte en précisant le nom logique d'un service : l'APN (Access Point Name). Grâce à l'APN le SGSN est en mesure de trouver les données d'abonnement correspondant à ce service et le GGSN qui permettra d'atteindre le réseau externe. Un tunnel est ensuite établi entre le SGSN et le GGSN pour chaque nouveau contexte ; il transporte à la fois les données et la signalisation. Les différents tunnels suivent les déplacements du mobile de SGSN en SGSN.

Contrairement au cas d'un circuit GSM où le MSC serveur d'une communication reste le même durant toute la communication (notion de MSC ancre), le SGSN serveur peut changer alors que le mobile est en communication


paquet. Cela peut même poser des problèmes pour les flux de données 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 données plutôt que sur le respect des contraintes temporelles.

Lors de l'attachement d'un terminal au réseau GPRS, le SGSN établit un contexte de mobilité qui comprend les informations de localisation et d'authentification concernant le terminal. Dès 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 procédure, le SGSN récupère auprès du HLR des informations concernant le terminal et l'abonnement auquel l'abonné a souscrit. Il conserve ces données localement tant qu'il gère le mobile. Elles permettront d'autoriser ou non l'établissement d'un contexte PDP, préalable nécessaire à toute communication.

L'activation d'un contexte PDP entraîne un dialogue entre le SGSN et le GGSN et est suivie de l'établissement d'un contexte dans ces deux entités. La qualité de service obtenue est négociée en fonction des disponibilités du réseau et des paramètres d'abonnement de l'utilisateur.

7.2.2.1.3. Evolution nécessaire du HLR

Le HLR assume en GPRS les mêmes fonctions que pour le GSM. Il est donc impliqué dans les procédures d'attachement au réseau 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 opérateurs.

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 fréquents 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 élément critique de l'architecture GSM/GPRS, doit évoluer pour être capable de gérer le surcroît de charge de travail.


7.2.2.1.4. La gestion de la sécurité

Le SGSN est en charge des fonctions de sécurité et de contrôle d'accès 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 différents. C'est aussi le SGSN qui s'occupe du chiffrement des données transmises vers le mobile.

La sécurité des communications IP entrantes est assurée par les outils couramment utilisés 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 très différent de celui du GSM. Dans le réseau d'accès, le mobile est connecté au SGSN à travers une connexion LLC (Logical Link Control), ce qui rend le transfert des données relativement indépendant du réseau d'accès. Le transfert des données usager se fait grâce à l'aboutement de deux « tunnels » : la connexion SNDCP (Sub Network Dépendent 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 gérés indépendamment, ce qui permet d'avoir une mobilité à deux niveaux et de n'impliquer le cœur de réseau que lorsque les déplacements du mobile se font dans des zones de routage gérées par des SGSN différents.

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 considérer comme telle.


Comme pour tout réseau IP, l'opérateur est libre de choisir les technologies de niveau physique et de liaison pour son cœur de réseau IP. Le GGSN est un équipement IP à peine modifié tandis que le SGSN est un équipement spécialisé disposant des interfaces spécifiques du GPRS pour la connexion avec les réseaux d'accès radio (BSS) et les bases de données du GSM.

Entre deux SGSN ou entre un SGSN et un GGSN, c'est l'interface Gn qui est utilisée. Elle comporte le protocole GTP qui permet de transporter les données et la signalisation au-dessus d'IP et d'un protocole de transport. GTP peut fonctionner au-dessus de deux protocoles de transport différents, UDP ou TCP. Le choix du protocole de niveau transport est fait par GTP au moment de la création du tunnel et dépend des contraintes qui pèsent sur les données à transporter. Ainsi, les données ayant des contraintes quant à l'ordonnancement des paquets et à la fiabilité du transfert seront transportées au-dessus de TCP. Les autres, et en particulier la signalisation, seront transportées au-dessus de UDP. En pratique GTP dispose de ses propres mécanismes de reséquencement, ce qui rend inutile l'utilisation du transport TCP qui est d'ailleurs abandonnée dans l'UMTS.

Figure7.4. Architecture GPRS du plan de signalisation

Le plan de signalisation est très proche du plan usager. En effet, dans l'esprit de l'architecture IP, les mêmes protocoles sont utilisés pour transporter les données et la signalisation. Sur la partie réseau d'accès radio, la signalisation liée à la gestion des sessions, à la mobilité ou au transport des mini-messages (SMS, Short Message Service) est transportée directement au-dessus de la connexion


LLC. Dans le cœur de réseau, rien ne change car c'est une partie du protocole GTP qui prend en charge la signalisation nécessaire pour l'établissement des tunnels et leur gestion pendant les déplacements du mobile. Les relations avec les éléments du cœur de réseau GSM et les bases de données 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 paramètres décrivant la qualité de service qu'il souhaite obtenir du réseau :

- le niveau de priorité pour l'accès au service [precedence) ; - la classe de délai donnant un ordre de grandeur (delay) ; - la classe de fiabilité permettant de spécifier les mécanismes de fiabilisation mis

en œuvre dans les différentes couches (reliability) ; - le débit maximal instantané donné en octets par heure {peak throughput) ; - le débit moyen donné en octets par heure (mean throughput).

La demande d'activation de contexte comprenant les cinq paramètres de qualité de service est envoyée au SGSN. Ce dernier vérifie, grâce aux informations d'abonnement, si l'abonnement donne accès au service demandé. Il vérifie aussi auprès du sous-système radio que ce dernier dispose des ressources suffisantes pour satisfaire la demande.

Une fois le GGSN localisé grâce 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 contrôle 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 définie une fois pour toutes lors de l'établissement d'un contexte. Le mobile doit désactiver et réactiver le contexte pour en changer les paramètres. Il est prévu que la qualité de service soit modifiable dynamiquement dans la phase 2 du GPRS mais comme les implémentations actuelles n'utilisent que le service « pour le mieux » (Best Effort), il est peu probable que cette possibilité soit implémentée dans le cadre du GPRS.

Une fois l'adresse IP obtenue et le contexte activé au niveau du GGSN, ce dernier répond au SGSN que l'activation du contexte est terminée et lui transmet l'adresse IP et les paramètres de QoS définitifs. Le SGSN stocke ces paramètres et active le contexte avant de les transmettre au mobile. A partir de ce moment, ce dernier peut émettre et recevoir des paquets IP.


Malgré les mécanismes définis au niveau de la procédure d'activation de contexte et dans le réseau d'accès, il n'y a pas, à proprement parler, de gestion de la qualité de service dans le cœur de réseau GPRS. Seule la disponibilité de la ressource minimale est évaluée pour autoriser ou non l'activation du nouveau contexte et les paramètres de qualité de service ne sont même pas étudiés par le GGSN. Il existe des propositions utilisant les mécanismes définis par l'IETF pour gérer la qualité de service à l'intérieur du cœur de réseau. Par exemple, certains constructeurs proposent d'utiliser MPLS (Multi Protocol Label Switching) et l'architecture à différenciation de service pour différencier plusieurs qualités de service dans le cœur de réseau IP. Nous verrons un exemple de ce type d'intégration pour l'UMTS. Dans le cas de l'UMTS, l'architecture intègre déjà les briques nécessaires 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 opérateurs. Le GPRS permet de diversifier les critères de taxation en fonction de paramètres aussi divers que la qualité de service, l'heure de la journée, le service demandé et bien sûr, la durée de connexion et le volume des données transmises. De plus, il peut être envisagé de combiner plusieurs de ces critères de taxation avec le coût du service pour rémunérer les fournisseurs de services à l'instar de ce qui se passe pour les services Minitel et plus récemment i-mode. Cela entraîne, une complexité accrue des mécanismes de taxation dont les opérateurs ne pourront pas faire l'économie. En effet, c'est la souplesse de leur système de taxation qui leur permettra ou non de rester inventifs et réactifs sur le marché des services.

Les entités du cœur de réseau GPRS ont un rôle important à jouer dans le système de taxation puisque ce sont elles qui ont la charge de collecter les différents types de tickets de taxation. Les informations contenues dans ces tickets doivent permettre aussi bien une taxation à la durée qu'une taxation au volume pour laquelle la collecte des informations est plus compliquée à mettre œuvre. Mais il a aussi été envisagé de tenir compte de la localisation du mobile dans le réseau pour pouvoir adapter les tarifs à la concurrence locale. Le mécanisme 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 coût puisqu'il est estimé que les tickets de taxation générés par des communications GPRS seront dix fois plus importants que ceux qui sont générés par les communications voix.


7.3. Architecture du cœur de réseau en Release 99

La Release 99 de l'UMTS intègre le cœur de réseau GPRS dans son architecture, ce qui permet une évolution en douceur des réseaux existants vers la téléphonie mobile de troisième génération. En effet, seules quelques adaptations mineures sont nécessaires au niveau des cœurs de réseaux paquet et circuit pour gérer les réseaux d'accès UMTS (UTRAN).

L'interconnexion entre le réseau cœur et l'UTRAN, basé sur ATM, est décrite dans le chapitre 6. Nous nous focalisons sur les modifications apportées au cœur de réseau dont la description plus formelle prépare aux évolutions profondes qui conduiront à un réseau cœur multi-service unifié dans les versions ultérieures de l'UMTS.

Le réseau cœur de la Release 99 de l'UMTS est conçu comme un réseau de transition. D'une part, certaines des possibilités de l'UTRAN (support de communication haut débit) ne seront pas supportées dans la première mouture. D'autre part, le réseau cœur est très fortement couplé avec les réseaux GSM/GPRS existants pour offrir une transition douce. Ainsi, une évolution minimale des cœurs de réseaux circuit et paquet peut permettre de servir indifféremment les réseaux d'accès GSM et UMTS.

Figure 7.5. Architecture d'un réseau UMTS (Release 99)

v


A l'instar du cœur de réseau GSM, le cœur de réseau UMTS de la Release 99 est divisé en plusieurs parties appelées domaines (voir figure 7.8). Le domaine circuit {CS domain) est une évolution du cœur de réseau GSM. Il utilise, comme ce dernier, les MSC/VLR2 et le GMSC qui assurent les mêmes fonctions qu'en GSM. Le domaine paquet (PS domain) est, quant à lui, une évolution du cœur de réseau GPRS mais subit un peu plus de changements, même si les principes de fonctionnement restent les mêmes. On y retrouve les entités fonctionnelles connues du GPRS comme le SGSN et le GGSN. Enfin, il existe des équipements utilisés par les deux domaines qui sont classés à part, ce sont les bases de données issues du GSM comme le HLR, l'AuC et l'EIR ainsi qu'une nouvelle base de données de localisation appelée GLR (Gateway Location Register) [23.002]. Cette base de données est utilisée en cas d'itinérance inter PLMN dans les domaines paquet et circuit d'un réseau visité. Elle permet d'économiser les messages de signalisation impliquant le HLR du réseau d'origine. D'autres entités fonctionnelles sont définies pour gérer par exemple les services de localisation géographique (service de type GPS) et les SMS, mais nous ne traiterons pas de leur fonctionnement ici.

7.3.1. Services offerts par le cœur de réseau

Le cœur de réseau UMTS R99 est prévu pour être un cœur de réseau de transition vers un cœur de réseau multimédia dans lequel les flux de données seront banalisés. Les différences qui seront faites pour la voix ou les données porteront seulement sur les attributs du service demandé au réseau. En attendant, cette banalisation est déjà commencée dans le réseau d'accès radio qui traite la voix comme un flux de données ayant des contraintes de service particulières, notamment temporelles. Il n'effectue plus de traitement spécifique sur la partie voix. Ces traitements sont reportés à l'entrée du domaine circuit du cœur de réseau.

Le domaine circuit doit supporter un circuit à 64 kbit/s par utilisateur et offrir la possibilité de débits moindres. Les services offerts aux utilisateurs sont donc équivalents à ceux dont il pourrait disposer sur un réseau RNIS, c'est-à-dire, la voix et les données numérique ou analogique. Notons que le service de télécopie (fax) n'est plus supporté en tant que tel, mais un serveur externe permet de le gérer à l'extérieur du cœur de réseau.

Le domaine paquet doit être capable de supporter des flux de 2 Mbit/s, l'utilisateur pouvant demander des flux de moindre débit. Toutefois, si la phase 1 de

2. Les mêmes sigles sont utilisés pour l'UMTS et le GSM-GPRS. Lorsqu'une fonction n'est présente que pour un équipement UMTS, nous faisons précéder le sigle du préfixe 3G. Par exemple, 3G-MSC, 3G-SGSN.


l'UMTS définit ces supports hauts débit (2 Mbit/s) dans le réseau d'accès, ils ne seront pas obligatoirement supportés dans le cœur de réseau de la première release de l'UMTS.

Etant donné que l'utilisateur demande des services de transport en explicitant des contraintes de qualité de service, l'opérateur associe un coût différent aux différentes qualités de service. Il faut par conséquent que le réseau soit capable d'informer le mécanisme de facturation de la qualité de service perçue par l'utilisateur. Cela entraîne inévitablement une complexité accrue de l'ensemble de la chaîne de facturation. Nous verrons plus loin que l'architecture de gestion de la qualité de service a d'ailleurs été entièrement repensée du fait de la nécessité de supporter des contraintes de qualité de service très variables [23.002].

Le fonctionnement du cœur de réseau UMTS (R99) est légèrement simplifié par rapport à celui du GSM. Un certain nombre des fonctions proches de la technologie utilisée dans le réseau d'accès ont été reportées au niveau du RNC. On peut citer pour l'exemple : le chiffrement pour le domaine paquet, la détection des erreurs et la gestion des retransmissions. Ce déplacement permet aussi de réduire le délai d'action de ces mécanismes en rapprochant leur traitement du terminal mobile. Il permet de rendre le 3G-SGSN plus indépendant du réseau d'accès utilisé. En effet, certaines de ces fonctions étaient très liées aux couches radio.

Le cœur de réseau conserve le rôle de gérer 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 intègre bien sûr les outils nécessaires à la gestion des abonnés, de la facturation et de la maintenance.

7.3.2. Principaux concepts

7.3.2.1. Notion de support de communication (bearer)

Les spécifications de la Release 99 de l'UMTS définissent très formellement la notion de support de transmission {bearer). Un support de communication est un ensemble de ressources établies dans différents éléments du réseau pour répondre à un besoin de communication. Il est défini entre deux entités et comporte les attributs de qualité de service à fournir. Le plus souvent, des ressources de transmissions lui sont dédiées, mais il peut aussi partager les mêmes 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 qualités de service obtenus. Cela implique, sur la partie UMTS, un support de transmission UMTS (UMTS Bearer) qui est défini par l'application en


fonction de ses besoins (c'est-à-dire des attributs choisis pour le support de transmission de bout en bout). Le support UMTS est ensuite projeté sur le réseau d'accès radio sous la forme d'un RAB (Radio Access Bearer, voir paragraphe 6.3.3), ce dernier utilisant lui-même 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 cœur de réseau (CN Bearer) pour offrir le service de bout en bout demandé par l'application (UMTS Bearer). La définition des attributs d'un support de transmission UMTS est très précise. Il en est de même de leur projection dans l'UTRAN sur le Radio Bearer ainsi que des mécanismes de réservation, de contrôle d'accès et de renégociation. Par contre, la projection des attributs de Y UMTS bearer sur le CN Bearer est laissée à la discrétion de l'opérateur 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 séparer ce qui dépend de la technologie du réseau d'accès de ce qui n'en dépend pas. Ainsi, la strate appelée AS (Access Stratum) reprend l'ensemble des fonctions dépendant directement du réseau d'accès. La NAS (Non Access Stratum), quant à elle, utilise les services bien définis de l'AS pour offrir des services de plus haut niveau (voir figure 6.19). De ce fait,


elle comprend les protocoles qui mettent enjeu le terminal et le cœur de réseau. 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 définis 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 différents modes de fonctionnement du cœur de réseau. Ils permettent d'envisager la définition de nouveaux domaines. D'ailleurs, un autre domaine apparaît déjà dans la spécification de l'interface lu : le domaine de diffusion (Cell Broadcast).

Dans les premières releases, un domaine comprend à la fois les éléments utiles à la signalisation et ceux dédiés au transport, mais dans les versions ultérieures de l'UMTS le réseau de transport sera unifié et seuls les éléments de contrôle seront spécifiques à un domaine particulier. Nous décrirons l'évolution probable des cœurs de réseaux vers un réseau cœur IP unifié à la fin de ce chapitre.

7.3.3. Entités du domaine circuit

Comme le montre la figure 7.5, le domaine circuit est très proche d'un réseau GSM. Il comprend de la même manière un 3G-MSC et un 3G-GMSC, qui assurent le contrôle et le transport des circuits. Par contre, la fonction de transcodage de la voix est maintenant assurée par le cœur de réseau et le TRAU ( Transcoder and Rate Adaptation Unit) se trouve dans le domaine circuit. Cela permet à la fois d'économiser les ressources du réseau de transport ATM, entre le RNS et le cœur de réseau, et de banaliser le transport de la voix dans le réseau d'accès qui devient un flux de données comme un autre. En effet, l'interface lu offre le même ensemble de services quel que soit le domaine de cœur de réseau concerné. En d'autres termes, on traite indifféremment la voix et les données dans le réseau d'accès radio (UTRAN).

La signalisation est toujours assurée par le réseau sémaphore [RUS 02] qui interconnecte les points sémaphores intégrés aux MSC.

La notation MSC/VLR disparaît au profit du 3G-MSC qui intègre une base de données VLR. Cela entérine la situation actuelle puisque, du fait du non-respect des interfaces normalisées à l'origine entre le VLR et le MSC, les bases de données


VLR sont systématiquement intégrées aux MSC. Nous ne différencions donc pas les fonctions du VLR et du MSC dans ce chapitre.

Figure 7.7. Architecture du plan de contrôle du domaine circuit de l'UMTS (Release 99)

7.3.4. Entités du domaine paquet

Le domaine paquet subit un peu plus de changement que le domaine circuit du fait de la volonté de rendre le cœur de réseau indépendant du réseau d'accès. Ainsi, si les 3G-SGSN et 3G-GGSN sont les équivalents des GSN du GPRS, le 3G-SGSN n'intègre plus les fonctions spécifiques au réseau d'accès et laisse aux RNC le soin d'assurer les fonctions de gestion des communications comme la détection d'erreur, les retransmissions, la compression d'en-tête, etc.

7.3.4.1. Le SGSN

Pour assurer ces différentes fonctions, le 3G-SGSN dispose de plusieurs interfaces obligatoires et d'un certain nombre d'interfaces optionnelles qui seront utilisées ou non par l'opérateur en fonction du degré d'intégration des cœurs de réseaux 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-


système radio. Alors que l'interface Iu-CS gère 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 même 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 cœur de réseau jusqu'au RNC. De fait, c'est maintenant le RNC qui a en charge le traitement des paquets IP pour les transformer en éléments transportables sur la partie radio. Notons que si cette interface est aujourd'hui définie sur un réseau ATM, les futures versions pourront aussi utiliser un réseau IP natif (voir sections 6.4 et 6.5).

L'interface Gn définie entre les 3G-SGSN et le 3G-GGSN permet le transport des données et de la signalisation grâce aux services du protocole d'encapsulation GTP qui fonctionne au-dessus des protocoles de la famille TCP/IP (plus particulièrement UDP). Elle est aussi utilisée 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 sécurité 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 réseaux publics de données (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 entités UMTS auxquelles un 3G-GGSN est connecté sont les autres GSN, mais il peut disposer d'une interface optionnelle vers le HLR. Celle-ci est relativement aisée à mettre en œuvre si une passerelle de signalisation est utilisée. Cette interface est utile lorsque les communications entrantes vers un mobile sont gérées par le cœur de réseau. Elle n'est toutefois pas indispensable, car en son absence le 3G-GGSN passe par un 3G-SGSN qui relaie la signalisation vers le HLR.


Le protocole d'encapsulation GTP est utilisé au-dessus de la pile protocolaire TCP/IP sur l'interface Gn. Grâce à cela, le réseau de transport peut être un réseau IP composé de routeurs standards auxquels il n'est pas nécessaire d'ajouter de nouvelles fonctionnalités, les GSN se comportant comme des routeurs frontières du point de vue du cœur de réseau 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'accès, 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 échéant se charger de l'attribution de l'adresse IP à la place du serveur DHCP (Dynamic Host Configuration Protocol). Notons toutefois que la plupart des opérateurs 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 plaçant 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 représenté par un tunnel entre le SGSN et le MS. En pratique, celui-ci est composé de 2 tunnels aboutés : le premier au dessus de GTP-U entre le 3G-SGSN et le RNC et le deuxième entre le RNC et le mobile.


aussi en charge la terminaison des connexions IP sécurisée (IPsec [RFC 2401]) en assurant le chiffrement et le déchiffrement des données.

7.3.4.3. La fonction de passerelle entre réseau (BG)

Un cœur de réseau paquet étant un cœur de réseau IP, il est nécessaire de le protéger du monde extérieur. Pour un fonctionnement intra-PLMN, le réseau n'a besoin que d'un nombre très limité d'interfaces avec les réseaux extérieurs ; de plus, ces interfaces sont « protégées » par le GGSN qui filtre les communications entrantes et éventuellement les communications sortantes. Par contre, pour permettre Titinérance inter-opérateur (roaming inter PLMN), le cœur de réseau GPRS doit nécessairement disposer d'une connexion IP avec les autres PLMN à travers un réseau inter PLMN. Une passerelle (BG, Border Gateway) assurant des fonctions de sécurité permet de protéger le cœur de réseau du monde extérieur, mais elle doit autoriser les communications en provenance d'opérateurs ayant des accords d'itinérance. Inversement, elle doit permettre les communications sortantes vers les GGSN des opérateurs dont le réseau accepte les clients (voir figure 7.31).

7.3.4.4. La gestion des noms et de l'adressage

Le cœur de réseau IP doit évidemment être configuré pour permettre aux GSN de communiquer entre eux. Pour cela, le routage IP doit être en ordre de marche même s'il peut fonctionner avec un plan d'adressage privé. Il est toutefois nécessaire, en cas d'accord d'itinérance, de disposer d'un adressage compatible avec l'adressage des autres PLMN.

Des technologies IP non spécifiques à la téléphonie 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 même service de nom peut aussi être utilisé pour retrouver l'identité d'un mobile en fonction de son adresse IP lorsqu'il bénéficie d'une adresse IP statique (ce qui est très rare actuellement).

7.3.4.5. Autres équipements

Pour éviter d'avoir à implémenter la pile des protocoles SS7 sur tous les GSN du cœur de réseau GPRS et profiter quand même des interfaces optionnelles, entre les GGSN et le HLR par exemple, l'opérateur peut mettre en place une passerelle de signalisation. Cette passerelle dispose d'une interface IP connectée au cœur de réseau GPRS et d'une interface SS7 connectée au réseau de signalisation SS7 de l'opérateur. Elle se comporte alors dans ce réseau comme un point de signalisation sémaphore (PS) sur le réseau de signalisation du réseau GSM et traduit les requêtes entre les deux mondes.


La gestion de la facturation fait intervenir une entité appelée 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 diffère 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 composée en UMTS de trois « tunnels » aboutés. 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 troisième entre le 3G-SGSN et le 3G-GGSN utilisent GTP-U ; le protocole GTP-U est à la fois une évolution de GTP et un sous-ensemble, car il concerne seulement les procédures dans le plan usager (GPRS Tunneling Protocol in the User Plane). Cette séparation de la connexion en trois parties permet de gérer trois niveaux de mobilité, ce qui a pour effet de réduire l'implication du cœur de réseau et la surcharge de signalisation.


Contrairement au GPRS 2G où TCP pouvait être utilisé, seul UDP est utilisé pour transférer l'information. Il est en effet très rare d'observer des congestions dans le cœur de réseau et les congestions qui entraînent des pertes se limitent au réseau d'accès radio. Ainsi TCP qui a pour fonction de gérer la pénurie 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 entités peuvent exister au-dessus de PDCP (voir figure 7.9). C'est notamment le cas lorsque différents contextes PDP sont activés sur un même mobile. Chaque entité accède à PDCP via un point d'accès particulier. Le point d'accès est repéré 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 contrôle

Figure 7.10. Architecture du plan de contrôle du domaine paquet de l'UMTS (Release 99)

Dans le plan contrôle du cœur de réseau (voir figure 7.10), c'est une évolution de la partie signalisation de GTP qui est utilisée. Il s'agit de GTP-C qui est restreint à la gestion de la signalisation (GPRS Tunneling Protocol in the Control Plane). Seules quelques procédures et le contenu des messages diffèrent de la version utilisée dans le cadre du GPRS-2G. Pour la partie située entre le mobile et le 3G-SGSN il y a deux connexions bout à bout. La connexion RRC permet de transporter les données des


protocoles de gestion de la mobilité (GMM), des sessions (SM) et des minimessages (SMS). Elle est gérée 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 différente pour le domaine paquet (vers le 3G-SGSN) et pour le domaine circuit (3G-MSC). Il y a donc deux connexions différentes si le mobile est attaché aux deux domaines.

Même dans le cas d'un réseau cœur intégré, c'est-à-dire lorsque le même é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. Entités communes aux deux domaines

L'ensemble des bases de données nécessaires à la gestion des abonnés et à la gestion de la mobilité sont communes aux deux domaines. Elles subissent plus de changements que les autres éléments puisqu'elles répercutent l'ajout de nouvelles fonctionnalités 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 données

Les mêmes services d'information sont utilisés que pour les réseaux de seconde génération. Ils maintiennent les informations concernant les abonnements des utilisateurs et les terminaux et gèrent la partie sécurité. Ils sont utilisés aussi bien par le domaine paquet que par le domaine circuit de l'UMTS.

Le HLR (Home Location Register) conserve les données d'abonnement et les données de routage (le 3G-MSC et le 3G-SGSN qui servent un mobile) ainsi que les contextes PDP souscrits et actifs. C'est un élément très critique du réseau puisqu'il est indispensable lors attachement, des changements de zone de routage et de localisation ainsi que pour les appels entrants. De plus, il gère 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 définir des services qui seront disponibles même si l'utilisateur n'est pas attaché à son réseau d'origine. Il est une adaptation aux réseaux mobiles du concept de réseau intelligent normalisé à ITU-T et met en œuvre des entités décrites au chapitre 8.

7.3.6.3. Service de localisation

Une passerelle de localisation géographique est intégrée au cœur de réseau UMTS ([23.002], [23.171]). Elle est responsable de vérifier les autorisations des


applications externes au PLMN demandant une localisation. Elle dispose d'une interface avec le HLR pour demander les informations de routage qui lui permettront de contacter le centre de localisation (SMLC, Serving Mobile Location Centre) intégré au réseau d'accès dont dépend le mobile. Ce dernier est en charge de coordonner la tâche des entités chargées d'effectuer les mesures qui permettront le calcul de la position du mobile.

7.3.7. Intégration des domaines PS et CS

Pour réduire les coûts de déploiement et de fonctionnement, les spécifications prévoient la possibilité de déployer un équipement appelé UMSC (UMTS MSC) qui reprend les fonctions du 3G-MSC et du 3G-SGSN. Cela permet de réduire le coût de la signalisation et de maintenance du réseau. L'intégration ne change pas la logique de fonctionnement des deux domaines puisque l'UMSC possède dans ce cas deux connexions sur l'interface lu correspondant aux deux domaines paquet et circuit.

Figure 7.11. UMSC et réseau cœur intégré

Dans le cas où les équipements ne sont pas confondus, l'UMTS simplifie grandement les règles de gestion des procédures combinées par rapport à GSM-GPRS. Ainsi, il n'existe que deux modes de fonctionnement, suivant que l'interface Gs entre le 3G-MSC et le 3G-SGSN est présente ou non. Dans la suite,


nous considérerons que l'interface Gs est présente et nous présenterons les procédures de gestion combinées.

7.4. Gestion des appels et des sessions

Pour ce qui est du cœur de réseau, la gestion des appels est sensiblement la même dans la première version de l'UMTS et dans la dernière version du GSM/GPRS. Seule la partie de la gestion d'appel concernant l'allocation des ressources dans le réseau d'accès 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'itinérance.

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 simultanément 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 téléphonie au-dessus du domaine paquet. On pourrait ainsi voir apparaître des opérateurs ne possédant pas de domaine circuit et offrant des services de téléphonie au-dessus d'IP.

7.4.1. Services IP proposés aux utilisateurs

Un opérateur UMTS peut offrir différents types de services de données (IPv4, IPv6 et PPP). L'accès X25 (défini pour le GPRS) n'est pratiquement pas utilisé et n'a pas été reconduit pour l'UMTS. PPP est une solution intéressante, mais n'est pas encore offerte par les opérateurs. IP est donc le seul service généralement disponible.

Il existe deux manières différentes d'offrir un service IP, suivant que le GGSN gère le service de manière transparente ou non. Dans le second cas, il participe à la phase d'établissement de contexte en dialoguant avec le réseau de données cible (PDN) pour obtenir une adresse IP et vérifier les autorisations dans le réseau visité. Le GGSN agit dans ce cas au nom du terminal mobile pour obtenir les informations nécessaires.

Une entreprise peut ainsi disposer d'un lien direct avec le GGSN (une ligne louée, un lien El , une connexion IPSec, ...) qui permettra à ce dernier d'interroger


le serveur RADIUS de l'entreprise plutôt que celui de l'opérateur. L'adresse allouée 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 réseau GPRS (voir figure 7.12). Cette adresse peut être une adresse IP statique (le réseau la fournit à travers le contexte PDP), ou être fournie par le réseau GPRS.

7.4.1.1. La notion d'APN

En activant un contexte PDP, le terminal demande l'accès à un service de données et de fait à un réseau externe de données (PDN). Il peut y avoir plusieurs services donnant accès au même réseau externe de données mais avec différentes caractéristiques de protection (configuration du pare-feu), d'adressage (adresse publique ou privée), 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 : considérons un terminal qui veut un accès au réseau Internet avec le support de la mobilité IPv4 ; il lui suffit de préciser seulement l'APN correspondant à ce service


pour son opérateur d'origine (HPLMN) dans la demande d'activation de contexte. Dans les réseaux GPRS actuels, les différents APN correspondent généralement :

- au WAP (l'APN sera par exemple wap.syldavie-telecom.com) ; - à un abonnement pour usage personnel avec une adresse privée et la possibilité

de faire de la messagerie et de la navigation Internet (par exemple gprs.syldavie-telecom.com) ;

- à un abonnement professionnel avec une adresse publique et la possibilité d'utiliser plus de protocoles (par exemple entreprise.syldavie-telecom.com) ;

- à un accès à Internet en utilisant la mobilité IPv4 (MobileIPv4).

Le SGSN utilise le service de nom (DNS, Domain Name Service) [RFC 1034, RFC 1035] pour déterminer l'adresse IP du GGSN correspondant à l'APN demandé. Grâce à ce mécanisme, l'opérateur peut facilement répartir 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 même syntaxe que pour les noms de machine dans l'Internet4, à savoir des labels séparés par des points. Il peut n'y avoir qu'un seul label et le premier label représente en général 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 complètement qualifié en ajoutant l'identifiant de l'opérateur suivant la convention de nommage définie dans les recommandations [23.003] et [23.060)] : MCCXXX.MNCYYY.gprs, où XXX et YYY sont respectivement le numéro du pays et le numéro de l'opérateur. Un nom complètement qualifié est nécessaire 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 attribuées au mobile peuvent être statiques ou dynamiques, publiques ou privées. Par statique, on entend généralement le fait que le mobile connaît son adresse et qu'elle est donc configurée au niveau du terminal par l'usager. Dans le cas du GPRS, l'adresse

4. L'utilisateur n'a pas forcément connaissance du nom complet de l'APN auquel il accède. Il n'utilise souvent que le nom logique du service. Le SGSN complète le nom fourni lors de la demande d'activation de contexte en fonction de sa configuration.


peut également être configurée statiquement au niveau du contexte PDP stocké par le HLR. Elle est alors fournie au mobile lorsqu'il active le contexte. Cela ne présume pas du fait que l'adresse soit publique ou privée. En pratique, dans la plupart des offres actuelles, les adresses sont dynamiquement attribuées par l'opérateur au moment de l'activation du contexte. Elles sont la plupart du temps privées, 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'accès à un VPN d'entreprise, généralement réservé aux grands comptes, le choix d'un adressage privé ou public est laissé à la discrétion du VPN, tout comme la gestion de la sécurité.

Dans le cas de l'adressage privé, le service offert n'est pas réellement un accès Internet, puisqu'il suppose une traduction d'adresse au niveau du GGSN ou d'une autre passerelle d'entrée (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 visioconférence ou de téléphonie sur IP, et plus généralement 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 très limité de protocoles : l'usage d'Internet est alors limité à la navigation HTTP et à quelques protocoles déterminés par l'opérateur. Cela limite fortement l'innovation et le dynamisme qui font le succès d'Internet, la mise en place de tout nouveau protocole supposant une nouvelle configuration des passerelles des opérateurs.

Les opérateurs avancent plusieurs arguments pour justifier l'utilisation d'un adressage privé. En premier lieu, la très faible quantité d'adresses IPv4 disponibles par rapport au nombre d'abonnés les place dans l'incapacité d'attribuer une adresse IPv4 à chaque abonné GPRS. La seule solution à ce problème 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 dès lors que le contexte associé à cette adresse est activé. Si, dans le cas d'un adressage privé, il est nécessaire 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. Même si le mobile ne souhaite pas les recevoir et même si, en fin de compte, il les rejette, le coût lié à la transmission de ses paquets sera imputé à l'abonnement associé au contexte PDP actif. Le mobile n'a aucun moyen d'en empêcher la transmission. Le problème est encore plus sensible lorsque l'adressage est public et statique car, dans ce cas, l'opérateur peut autoriser le réseau à lancer la procédure d'activation


de contexte lorsqu'il reçoit une communication entrante alors que le contexte auquel est associée l'adresse IP n'est pas activé. On imagine aisément les possibilités d'attaques par déni de service qui seraient très faciles à effectuer si une telle possibilité était généralisée à tous les abonnés.

7.4.2. Etats de fonctionnement d'un mobile

Contrairement à ce qui se passe dans le cas du GSM/GPRS les différents états de fonctionnement sont très proches pour le domaine circuit et pour le domaine paquet. Dès 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 procédure d'attachement joue le même rôle et se fait de la même manière que dans le cas du GSM [LAG 00]. Au démarrage, le mobile est dans l'état DETACHED et il n'est pas encore connu du réseau. Une fois le mobile attaché au réseau, ce qui se fait généralement automatiquement lors de


l'allumage, un contexte de mobilité est créé et le mobile est repéré, à la zone de localisation près, par le 3G-MSC et, au 3G-MSC près, par le HLR.

Une fois attaché au réseau, le mobile peut être dans deux états différents. L'état IDLE indique qu'il est près à initier ou à recevoir une communication. Le mobile gère lui-même la mobilité ; il sélectionne la cellule en utilisant la procédure de resélection et informe le 3G-MSC de tout changement de zone de localisation.

Lorsque le mobile est en communication, un circuit est établi dans le réseau cœur et dans le réseau d'accès. Le mobile passe alors dans l'état CONNECTED. C'est le réseau d'accès radio (UTRAN) qui gère la mobilité en utilisant les mesures effectuées 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 différents états sont PMM-DETACHED, PMM-IDLE et PMM-CONNECTED. Le premier état correspond au moment où le mobile est éteint ou n'est pas encore attaché au domaine paquet. Le réseau ne maintient aucune information quant à la localisation du mobile. Ce dernier s'attache grâce à la procédure GMM-Attach et passe alors dans le mode PMM-IDLE une fois la


procédure terminée. Dans cet état, le réseau suit le mobile à la zone de routage près 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 près.

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 près, ce dernier étant chargé de suivre le mobile avec un degré de précision dépendant 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 conçu pour maintenir les contextes PDP indépendamment 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 gère la mobilité du terminal, ce qui décharge le cœur de réseau de la gestion de la mobilité ; la manière de gérer les handovers dépend de l'état RRC.

7.4.3. Attachement aux domaines PS et CS

Le principe de l'attachement comme préalable à toute action du mobile est conservé dans l'UMTS. Il permet au réseau de s'assurer de l'identité du mobile et de la validité de l'abonnement de l'usager. C'est lors de cette procédure qu'un opérateur refusera les demandes d'attachement provenant de l'abonné d'un opérateur avec lequel il n'a pas d'accord d'itinérance. De plus, contrairement au cas du GSM, le mobile peut lui aussi vérifier que le réseau auquel il tente de s'attacher est bien celui qu'il prétend être puisque l'authentification est réciproque (voir chapitre 10).

7.4.3.1. Procédure d'attachement

La procédure d'attachement se déroule de la même manière dans les domaines CS et PS. Le mobile s'identifie auprès du réseau 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 réseau et qu'il ne dispose pas des identités P-TMSI et TMSI. Le mobile demande simultanément l'attachement IMSI et GPRS aux domaines circuit et paquet. Les procédures de sécurité permettent de vérifier que l'abonnement associé à la carte USIM autorise l'accès au réseau. Le réseau vérifie aussi que le terminal n'est pas un terminal volé si cette fonction est activée par l'opérateur. Si tout se passe


bien, le 3G-SGSN inscrit la nouvelle localisation du mobile dans le HLR. Ce dernier répond en donnant le profil de l'abonné, ce qui permet au 3G-SGSN de maintenir sa propre copie des informations d'abonnement. Lorsque la procédure de mise à jour de la localisation du domaine paquet est terminée, le 3G-SGSN initie la procédure de changement de localisation du domaine circuit qui se déroule de la même manière. Les deux procédures terminées, le 3G-SGSN signale la fin de la procédure d'attachement au mobile puis transmet l'acquittement du mobile au 3G-MSC pour que ce dernier puisse clore la procédure à son tour.

Figure 7.15. Procédure d'attachement combiné aux domaines circuit et paquet (UMTS)

7.4.3.2. Procédure de détachement

Le détachement peut être initié par le mobile, le SGSN ou le HLR. Lorsqu'il est déclenché par le mobile, il permet à ce dernier d'indiquer au réseau qu'il n'a plus besoin des services du domaine circuit, du domaine paquet ou d'aucun des


deux domaines selon qu'il s'agit d'un détachement IMSI, GPRS ou combiné. Lorsque c'est le réseau qui le déclenche, il informe le mobile que le service ne peut plus lui être rendu (problème de ressources insuffisantes ou de crédit épuisé). A la fin de cette procédure, le réseau peut libérer les ressources occupées par les informations concernant ce terminal (stockage du profil dans le SGSN, par exemple).

Le détachement peut aussi être implicite lorsque la connexion avec le mobile est rompue pendant un certain temps, ce qui évite au réseau de conserver des données inutilement.

Figure 7.16. Procédure de détachement combiné aux domaines circuit et paquet (UMTS)

Dans l'exemple (figure 7.16), la procédure de détachement est initiée par le mobile qui demande un détachement 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 détruisent. Il prévient ensuite le 3G-MSC du détachement (flèche ©).

Dans le cas où le détachement ne concerne que le GPRS, il est quand même nécessaire de prévenir le 3G-MSC (flèche (D) pour que celui-ci supprime la référence au 3G-SGSN serveur et qu'il gère les pagings et les changements de localisation sans passer par ce dernier.


7.4.4. Gestion des appels du domaine CS

Dans le cœur de réseau, la procédure d'établissement d'un appel circuit ne change pratiquement pas par rapport au GSM. Voir [LAG 00], pour plus de détails sur ces procédures.

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 déclenchera la procédure d'attribution des ressources dans le réseau d'accès. Le 3G-MSC fera suivre la signalisation vers le réseau téléphonique (PSTN) en utilisant les protocoles de signalisation de ce dernier (ISUP). Le mobile est informé lorsque le téléphone du destinataire sonne puis lorsque ce dernier décroche. A la fin de la conversation, les ressources sont libérées dans l'UTRAN (non représenté).

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 réseau reçoit un appel entrant pour le numéro d'un mobile, il doit d'abord localiser ce dernier. Le GMSC réceptionnant la demande interroge pour cela


le HLR qui est capable de faire la relation entre le mobile et le 3G-MSC qui le gère au moment de l'appel. Le HLR relaie la demande vers le 3G-MSC et lui demande un numéro géographique 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 connaît pas forcément la localisation courante du mobile à la cellule près, connaît au moins la zone de localisation dans laquelle il se trouve. Il peut donc déclencher une procédure de paging pour localiser le mobile.

Suite à la procédure d'établissement du support RAB qui suit la procédure de sécurité, le mobile répond qu'il prévient l'utilisateur (sonnerie), puisque ce dernier décroche. Ces messages sont relayés vers le correspondant dans le réseau téléphonique (PSTN).

Figure 7.18. Etablissement d'une connexion entrante dans le domaine circuit (appel entrant)


7.4.5. Gestion des sessions du domaine PS

Il n'y a pas vraiment de notion d'appel dans le domaine paquet. Le terminal ouvre ou ferme des sessions de communications de données par l'intermédiaire des procédures d'activation et de désactivation de contexte.

7.4.5.1. La notion de contexte PDP

Le rôle du contexte PDP est semblable à ce qu'il est en GSM/GPRS. Toutefois, un certain nombre de modifications ont été apportées 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 déjà activé pour une même adresse PDP et de préserver le contexte lorsque la connexion entre le mobile et le réseau cœur tombe dans l'UTRAN.

Un contexte PDP est activé par le terminal et stocké à la fois au niveau du terminal et dans les entités du réseau cœur 3G-SGSN et GGSN. De plus, et contrairement au cas du GPRS 2G, le réseau d'accès conserve un contexte PDP simplifié comprenant, entre autres choses, la qualité de service négociée, pour lui permettre d'établir ou de rétablir un support de communication radio (RAB) disposant des ressources nécessaires à ce contexte. Il comprend aussi une copie des numéros de séquence des messages en cours de transfert qui seront utilisés pour fiabiliser le transport des données lors des changements de RNC serveur (relocalisation).

Les paramètres contenus dans un contexte PDP UMTS sont différents 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 privée, statique ou dynamique (voir la discussion sur l'adressage dans la partie GPRS). Un contexte PDP est valable dans un réseau de données 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 liées à 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 réseau auquel on accède. Ce champ est vide si

l'adresse est allouée dynamiquement lors de la phase d'activation ;

5. Bien que cette possibilité ne soit pas encore implantée dans les réseaux GPRS français.


-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 prétendre.

Figure 7.19. Informations maintenues dans les différentes entités

A ces informations s'ajoutent d'autres informations inscrites lors de l'activation d'un contexte :

- adresse dans le réseau externe d'accueil (lorsqu'elle est allouée dynamiquement) ;

- TEID (Tunnel Endpoint Identifier), identification du tunnel GTP sur la partie cœur de réseau ;

- adresses du SGSN et du GGSN ;

-paramètres de qualité de service effectivement négociés lors de la phase d'activation et qui tiennent compte à la fois des ressources disponibles dans le réseau, de la demande formulée par l'abonné lors de la phase d'activation du contexte et des données contenues dans le profil inactif.


7.4.5.2. Activation d'un contexte PDP

L'activation d'un contexte PDP est toujours déclenchée par le mobile. Toutefois, dans certains cas (lorsqu'il y a du trafic entrant), le réseau peut en être l'initiateur en demandant au mobile d'activer un contexte particulier. L'objectif de la procédure d'activation est multiple :

- permettre au PLMN de vérifier que le mobile est habilité à utiliser ce service de données avec la qualité de service demandée ;

- faire connaître le mobile et son adresse PDP au niveau de la passerelle vers le réseau externe de données correspondant à l'APN demandé (c'est-à-dire le GGSN) ;

- mettre en place le tunnel GTP-U dans le réseau cœur 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 aboutés dans l'UTRAN lorsqu'il y a un RNC en dérivation.

Figure 7.20. Activation d'un contexte PDP

Sur la figure 7.20, l'activation d'un contexte PDP est représentée. 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 référence un service (défini à l'intérieur du PLMN d'origine) ou un réseau de donnée (connu et accessible du PLMN d'origine) ;

- le profil de qualité de service qu'il demande pour ce contexte.


Le mobile peut aussi préciser un certain nombre d'options qui seront transmises de façon transparente au 3G-GGSN par le 3G-SGSN. Elles permettent au 3G-GGSN de jouer le rôle d'un terminal vis-à-vis du monde extérieur pour des protocoles indépendants de l'UMTS. Ainsi, des informations d'authentification pourront être transmises depuis le terminal vers le serveur d'authentification du réseau externe.

Le 3G-SGSN dispose déjà des informations d'abonnement du mobile en question puisqu'il les a demandées au HLR lors de la procédure d'attachement au domaine paquet. II vérifie donc que le mobile est autorisé à utiliser le contexte PDP demandé et que la qualité de service demandée est inférieure ou égale à la qualité inscrite dans les informations d'abonnement ; si ce n'est pas le cas, il réduit la qualité demandée avant de la transmettre au 3G-GGSN. En fait, les vérifications effectuées 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 renseignés. 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 précise 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 paramètres, l'APN n'est pas obligatoire dans la demande d'activation de contexte, mais le 3G-SGSN est obligé d'en déterminer 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 reçoit la demande d'activation de contexte, il détermine une adresse PDP si aucune adresse n'est contenue dans la demande (par exemple si le type d'adresse est dynamique). Il crée dans ses tables une correspondance entre l'adresse PDP et le tunnel GTP-U. 11 répond ensuite à la demande d'activation de contexte en indiquant l'adresse PDP choisie (la procédure de choix utilise les mêmes 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 attribuée par le réseau externe (PDN),


c'est-à-dire dans l'hypothèse d'un service non transparent. Dans ce cas, le 3G-GGSN répond favorablement à la demande d'activation de contexte et laisse le mobile effectuer la négociation avec le PDN. Il surveille cette négociation et utilisera une procédure de modification du contexte initiée par le 3G-GGSN pour modifier l'adresse PDP dans le contexte PDP enregistré par le 3G-SGSN et par le mobile. La procédure est, dans ce cas, dépendante des protocoles utilisés par le mobile et le réseau externe pour négocier l'adresse IP utilisé. Il faut que le GGSN soit capable de comprendre les messages échangés pour « intercepter » l'adresse IP qui sera attribuée au mobile. Le paragraphe 7.5.3 et la figure 7.32 présentent un fonctionnement similaire pour le cas d'un service Mobile IPv4.

Dès lors qu'il reçoit la réponse à la demande d'activation de contexte, le 3G-SGSN demande à l'UTRAN l'établissement d'un RAB sur la base du profil de QoS négocié renvoyé par le 3G-GGSN (voir chapitre 6). Si l'UTRAN revoit à la baisse les prétentions du 3G-SGSN, ce dernier informe le 3G-GGSN de la modification du contexte PDP. Enfin, le 3G-SGSN envoie au mobile une réponse favorable à la demande d'activation de contexte. Cette réponse contient les différents identifiants nécessaires au mobile pour transmettre des données dans le cadre de ce contexte, le profil de QoS finalement accepté par le PLMN, ainsi que son adresse PDP le cas échéant.

A partir de ce moment-là, le mobile est capable d'envoyer des données. 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 données en provenance et à destination du mobile tout en collectant lui aussi les informations nécessaires à 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 données correspondant à plusieurs contextes PDP sur la même liaison PDCP. Le paquet transite dans l'UTRAN sur un RAB déterminé au moment de l'activation du contexte. Ce RAB est lui-même 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 déterminer 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 cœur de réseau de l'opérateur.


c'est-à-dire dans l'hypothèse d'un service non transparent. Dans ce cas, le 3G-GGSN répond favorablement à la demande d'activation de contexte et laisse le mobile effectuer la négociation avec le PDN. Il surveille cette négociation et utilisera une procédure de modification du contexte initiée par le 3G-GGSN pour modifier l'adresse PDP dans le contexte PDP enregistré par le 3G-SGSN et par le mobile. La procédure est, dans ce cas, dépendante des protocoles utilisés par le mobile et le réseau externe pour négocier l'adresse IP utilisé. Il faut que le GGSN soit capable de comprendre les messages échangés pour « intercepter » l'adresse IP qui sera attribuée au mobile. Le paragraphe 7.5.3 et la figure 7.32 présentent un fonctionnement similaire pour le cas d'un service Mobile IPv4.

Dès lors qu'il reçoit la réponse à la demande d'activation de contexte, le 3G-SGSN demande à l'UTRAN l'établissement d'un RAB sur la base du profil de QoS négocié renvoyé par le 3G-GGSN (voir chapitre 6). Si l'UTRAN revoit à la baisse les prétentions du 3G-SGSN, ce dernier informe le 3G-GGSN de la modification du contexte PDP. Enfin, le 3G-SGSN envoie au mobile une réponse favorable à la demande d'activation de contexte. Cette réponse contient les différents identifiants nécessaires au mobile pour transmettre des données dans le cadre de ce contexte, le profil de QoS finalement accepté par le PLMN, ainsi que son adresse PDP le cas échéant.

A partir de ce moment-là, le mobile est capable d'envoyer des données. 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 données en provenance et à destination du mobile tout en collectant lui aussi les informations nécessaires à 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 données correspondant à plusieurs contextes PDP sur la même liaison PDCP. Le paquet transite dans l'UTRAN sur un RAB déterminé au moment de l'activation du contexte. Ce RAB est lui-même 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 déterminer 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 cœur de réseau de l'opérateur.


Le GGSN met en relation l'identifiant du tunnel (TEID) avec un contexte PDP et un numéro de service (NSAPI), ce qui est important pour mettre à jour les compteurs de trafic. Il fait ensuite suivre le paquet inchangé sur le réseau externe de données. Pour découvrir vers quel prochain routeur le paquet doit être envoyé le GGSN utilise les mécanismes standard d'IP : configuration d'une route par défaut statique ou participation aux protocoles de routage.

A aucun moment du transit, les éléments du réseau GPRS ne regardent le contenu du paquet IP pour décider du chemin que doit emprunter ce dernier. Cela rend le fonctionnement du service GPRS relativement indépendant du type de données transportées.

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 mécanisme de traduction d'adresse qui prend place après 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 précédent. Le GGSN reçoit un paquet correspondant à une plage d'adresse qu'il annonce en tant que routeur (s'il participe aux protocoles de routage). Grâce à l'adresse IP contenue dans le champ « adresse destination » du paquet IP, il détermine le contexte PDP correspondant au mobile.


Ce fonctionnement suppose qu'il existe un contexte PDP actif ayant cette adresse IP. Cela entraîne une autre contrainte : il est nécessaire qu'une adresse IP identifie de manière univoque un mobile et donc que l'opérateur dispose d'autant d'adresses qu'il peut y avoir de mobiles ayant un contexte actif simultanément. Puisque IPv6 n'est pas encore déployé, 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 détermine le RAB et le numéro de service (NSAPI) et transmet le paquet au mobile. Au niveau du mobile, le NSAPI permet de déterminer 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 même adresse PDP

Nous venons de voir que l'UMTS intègre les procédures de modifications qui peuvent être utilisées soit par le mobile, soit par le réseau pour modifier un contexte PDP alors que celui-ci est actif. Mais l'UMTS permet plus généralement d'associer plusieurs contextes PDP actifs, chacun disposant de son propre profil de qualité de service, à une même adresse IPv4 ou IPv6 d'un même PDN. L'intérêt est de pouvoir différencier les trafics qui doivent bénéficier de telle ou telle qualité de service.


Figure 7.23. Activât ion d'un contexte PDP secondaire

Si la procédure d'activation de contexte secondaire ressemble très fortement à la procédure d'activation de contexte, il y a toutefois une contrainte supplémentaire. Le mobile qui fait la demande des différents contextes PDP sait a priori choisir le NSAPI correspondant à la qualité de service désirée ; si cela pose un problème d'implémentation au niveau du mobile pour les couches applicatives, c'est à l'API (Application Programming Interface) au niveau du mobile d'offrir les outils nécessaires. 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 désirée. Le mobile, qui est le seul à pourvoir déterminer quelle qualité de service doit être appliquée à un paquet de données, doit donner au GGSN un moyen de différencier les paquets. Il dispose pour cela des filtres TFT (Tra f f i c Flow Template) [23.060] qui permettent de décrire des éléments de l'en-tête IPv4 ou IPv6 commun aux paquets devant utiliser ce contexte. Le mobile peut ainsi spécifier 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 donnée ; ce contexte est alors considéré comme le contexte par défaut dit contexte primaire. Les filtres étant parcourus dans l'ordre de précédence, le premier qui correspond au paquet de données évalué détermine 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 même adresse

Dans l'exemple suivant, le filtre utilisé se base sur le numéro de port UDP source du paquet pour déterminer le contexte PDP qui sera utilisé pour atteindre le mobile. Ce numéro de port peut par exemple être utilisé par un serveur de flux


vidéo. Le mobile a donc établi un contexte PDP spécifique pour recevoir la vidéo dans de bonnes conditions.

Lorsqu'un paquet arrive au niveau du GGSN, celui-ci commence par déterminer tous les contextes PDP qui utilisent la même adresse IP. S'il en découvre plusieurs, il applique, dans un ordre prédéterminé par le mobile, les différents filtres jusqu'à trouver un contexte PDP qui corresponde. Si aucun filtre ne correspond, le paquet utilise le contexte principal, comme précédemment.

Au niveau du 3G-SGSN, le paquet est dirigé vers un RAB correspondant à ce contexte spécifique. Ce RAB dispose sans doute de paramètres de qualité de service spécifiques qui ont justifié l'établissement d'un nouveau contexte. Au niveau du mobile le numéro NSAPI permet de différencier les différents 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 réseau

Lorsque le GGSN reçoit un paquet IP pour une adresse IP qui ne correspond à aucun contexte PDP actif, il peut soit détruire le paquet, soit essayer de provoquer l'établissement d'un contexte si l'opérateur met en œuvre ce service.

Dans ce cas, il doit commencer par déterminer quel est le mobile qui correspond à cette adresse IP. Cela suppose, bien entendu, que l'adressage soit statique et que


l'adresse IP soit inscrite dans un contexte PDP contenu dans les données d'abonnement au niveau du HLR. Pour interroger le HLR, le GGSN doit disposer du numéro de téléphone 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 numéro de téléphone (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 réseau GPRS, le paquet est détruit. Sinon, le GGSN demande au 3G-SGSN de trouver le mobile (paging non représenté si nécessaire) et de lui transmettre la demande d'activation de contexte. La procédure est ensuite similaire à la procédure d'activation de contexte initiée par le mobile (figure 7.20).

Figure 7.25. Activation d'un contexte PDP initiée par le réseau

7.5. Gestion de l'itinérance

La gestion de la mobilité est différente 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 décision de changer de 3G-SGSN dépende des contextes PDP actifs et de leurs attributs de qualité de service.


7.5.1. Gestion de la mobilité

Du point de vue du cœur de réseau, il existe trois grands types de mobilité. Une première forme de mobilité est de gérer les terminaux en mode IDLE et elle se traduit par l'exécution des procédures de mise à jour de zone de localisation (domaine CS) ou de zone de routage (domaine PS). Les deux autres formes de mobilité gèrent les mobiles en mode CONNECTED. En fait l'UMTS permet de masquer la plupart des mouvements d'un terminal au cœur de réseau. Le réseau d'accès se charge de les gérer et le même RNC, appelé RNC serveur (SRNC), est le point d'ancrage de la communication dans l'UTRAN. Toutefois, pour optimiser ses ressources, le réseau d'accès peut décider d'une « relocalisation » qui correspond au fait de changer de RNC serveur, procédure qui n'est pas transparente au cœur de réseau (voir chapitre 6). D'autre part, dans certaines configurations du réseau d'accès, 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 fréquence, le réseau d'accès est amené à déclencher un « hard handover » qui se rapproche du handover du GSM. Dans ces deux derniers cas, les entités du cœur de réseau et le mobile sont impliqués 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 réseau cœur


7.5.1.1. Mobilité dans le domaine circuit en mode IDLE

La procédure de mise à jour de zone de localisation pour le domaine circuit de l'UMTS est la même qu'en GSM. Le protocole MM (Mobility Management) est utilisé entre le terminal et le réseau cœur tandis que MAP (Mobile Application Part) est utilisé entre les entités du cœur de réseau.

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 recréer les connexions avec le nouveau RNC (voir chapitre 6). Dans le cas de la mobilité inter 3G-MSC, la situation est un peu différente 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 cœur de réseau entre l'ancien et le nouveau 3G-MSC. Le mécanisme 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 utilisée à la fois pour le domaine paquet lorsque le terminal est attaché au domaine paquet et pour la procédure combinée lorsque l'interface Gs est présente entre le 3G-MSC et le 3G-SGSN.


Figure 7.28. Mise à jour de zone de routage inter SGSN lorsque le mobile est en mode PMM-IDLE (voir 23.060)

Elle est déclenchée à l'initiative du terminal mobile lorsqu'il détecte un changement de zone de routage ou à intervalle régulier fixé par le réseau. Elle est identique à la procédure employée dans le mode CS, si ce n'est qu'elle peut impliquer le 3G-GGSN si des contextes PDP sont actifs. Les protocoles utilisés 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 déplacement du mobile le conduit dans une zone de routage gérée par un autre 3G-SGSN, les actions entreprises impliquent davantage le cœur de réseau puisqu'il faut, outre les deux 3G-SGSN et le HLR, impliquer aussi le GGSN.


Figure 7.29. mise à jour de zone de routage inter SGSN lorsque le mobile est en mode PMM-CONNECTED

Figure 7.30. Mobilité inter SGSN en mode connecté


Lorsqu'il reçoit une demande de « relocalisation » en provenance du réseau d'accès, 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 effectuée entre les deux 3G-SGSN pour ne pas perdre les données qui seraient en transit. Enfin, les extrémités des tunnels GTP correspondant aux profils actifs sont déplacées de l'ancien 3G-SGSN vers le 3G-SGSN cible grâce à la procédure de mise à jour de contexte PDP : celle-ci informe du changement les GGSN possédant des contextes PDP associés 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 réseau (hard handover et relocalisation) est moins performant que si la gestion se fait entièrement 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 réseaux d'accès ne sont pas du même type.

7.5.2. Gestion de la mobilité inter réseau

Figure 7.31. Mobilité inter PLMN


Le mécanisme de tunnel utilisé est pénalisant en termes de charge à cause de l'accumulation d'en-têtes. Mais il permet une gestion de la mobilité très simplifiée. 11 ressemble en cela à certains modes de fonctionnement de mobile IP. De plus, il permet de rester indépendant du protocole transporté. Ses avantages apparaissent clairement dans le cas de l'itinérance inter PLMN. Dans ce cas, et pour peu que les plans d'adressage des PLMN des deux opérateurs soient compatibles, le tunnel est simplement réalisé entre le SGSN du réseau visité et le GGSN du réseau d'origine du mobile. Seule la traversée des passerelles (BG) entre les PLMN et le réseau d'interconnexion des cœurs de réseau GPRS nécessite une configuration (voir figure 7.31). Ce mode de fonctionnement ouvre la voie à la gestion des changements de réseau sans rupture de service.

7.5.3. Interaction avec MobileIPv4

Lorsque les premiers terminaux informatiques réellement portables sont apparus à la fin des années 90, la communauté IP a commencé à travailler sur un protocole permettant de rendre les déplacements des terminaux IP dans la topologie de l'Internet transparents aux applications. Ce protocole est un mécanisme additionnel dans le cas d'IPv4 alors qu'il est intégré à IPv6. Le cas de la mobilité avec IPv6 ne sera pas traité ici, dans la mesure où peu de traitements spécifiques sont nécessaires au sein du réseau UMTS (voir [CIS 02]).

7.5.3.1. Mobile IPv4

Dans le monde IP, l'adresse IP permet de localiser un terminal qui la possède dans la topologie de l'Internet, elle est donc unique dans l'Internet. Le problème 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 entraîne par conséquent 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 réseau d'origine appelée adresse mère (Home Address).

Un élément particulier dans le réseau d'origine, l'agent mère (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 appelée adresse temporaire (Care Of Address) et n'est attribuée au mobile que durant la période où celui-ci est présent dans le sous-réseau IP dont elle dépend. Elle n'est jamais connue des correspondants du terminal mobile qui utilisent toujours l'adresse


mère. L'agent mère encapsule les paquets IP en provenance des correspondants et à destination du mobile dans un paquet à destination de l'adresse temporaire du terminal.

S : 1 2 7 . 1 0 3 . 9 . 1 0 5 D : 1 0 0 . 1 0 . 1 . 3 0

DATA a

.

S : 1 0 0 . 1 0 . 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 : 1 2 7 . 1 0 3 . 9 . 1 0 5 D : 1 0 0 . 1 0 . 1 . 3 0

DATA 150.25.89/24 BHjH^HHI

Figure 7.32. Fonctionnement de Mobile IPv4

Le mobile enregistre sa nouvelle localisation auprès de son agent mère à chaque fois qu'il change de sous-réseau IP et donc d'adresse temporaire. Le terminal mobile peut acquérir cette adresse temporaire en utilisant les mécanismes standards d'IP, mais il peut aussi utiliser l'adresse fournie par un équipement spécialisé du sous-réseau : l'agent étranger (.Foreign Agent). Cet équipement est souvent le routeur d'accès ; il gère l'enregistrement des terminaux mobiles, leur attribue une adresse IP temporaire et décapsule les paquets en provenance de l'agent mère. 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'intérêt 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 mère et le mobile est sécurisée par IPsec ([RFC 2401]), ce qui induit une charge de calcul importante pour un terminal mobile ;

- d'autre part dans le cas où le mobile acquiert une adresse IPv4 par ses propres moyens, celle-ci doit être publique et il en faut donc une pour chaque terminal


mobile. Dans un contexte de pénurie, le fait de pouvoir utiliser une ou plusieurs adresses de l'agent étranger pour tous les mobiles est très intéressant.

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 réseau UMTS dans son ensemble est considéré comme un réseau d'accès dont le GGSN est le routeur d'accès. 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 attribuée au mobile par l'intermédiaire des procédures Mobile IPv4. Ainsi le GGSN, sitôt 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 présence d'un agent étranger. Ce message est bien sûr émis en diffusion puisque le terminal ne possède pas encore d'adresse IP. Ce dernier agit ensuite comme un terminal mobile IPv4 normal et transmet une

Figure 7.33. Interaction avec mobile IPv4


demande d'enregistrement qui sera relayée par le GGSN vers l'agent mère du mobile. Il indique dans la demande d'enregistrement l'adresse de l'agent mère et sa propre adresse mère (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 réalisable à moindres frais par l'opérateur, elle ne suppose que quelques modification au sein du GGSN et du terminal informatique utilisant le réseau GPRS. Par contre, elle permet de passer outre la pénurie d'adresse en laissant le soin d'attribuer une adresse IP permanente

6. Le terminal peut aussi indiquer qu'il ne connaît pas l'adresse mère et demander par là-même que son agent mère lui en attribue une. Il utilise pour ce faire un identifiant unique qui lui a été attribué dans le réseau mère (Network Access Identifier) et une extension particulière de MobilieIPv4 (Mobile Node NA1 extension [RFC 2794]). L'agent mère lui attribue une adresse et la lui transmet dans la réponse qu'il lui fait. L'agent étranger stocke cette information avant de transmettre la réponse au terminal. Le GGSN effectue aussi une modification de contexte PDP initiée par le réseau pour modifier l'adresse IP associée au contexte au niveau du mobile et du SGSN.


au réseau IP d'origine du terminal. Par ce mécanisme, l'opérateur mobile propose à ses clients une réelle connectivité IP qui n'entraîne pas les problèmes associés à la mise en œuvre d'un NAT (Network Address Translator). D'autres part, le service de mobilité IPv4 permet d'assurer une itinérance transparente pour le mode paquet, même lorsqu'il n 'y a pas d'accord entre deux opérateurs. Lorsqu'il y a accord, l'itinérance GPRS se fait et cela reste transparent au terminal et à son agent mère ; dans le cas contraire, la mobilité IPv4 est mise en œuvre. Ce dernier mécanisme peut, de la même manière, être utilisé pour se déplacer sur les autres réseaux de données des opérateurs, par exemple les réseaux sans fil 802.11 (Hotspot).

7.6. Gestion de la qualité de service

La gestion de la qualité de service est complètement différente dans les deux cœurs de réseaux paquet et circuit. Elle a évolué très fortement dans le réseau d'accès radio (UTRAN) pour pouvoir accepter plusieurs niveaux de qualité de service et cette évolution s'est répercutée dans le cœur de réseau paquet.

Peu de choses ont évolué dans le domaine circuit. Il existe toujours les trois types de services : le service voix, le service données transparent et le service données non transparent. Le cœur de réseau circuit, quant à lui, établit les circuits correspondant aux attributs demandés par le terminal mobile. Les ressources occupées par un circuit sont monopolisées tout le temps que dure la communication et sont libérées lorsque celle-ci se termine.

Dans le domaine paquet, la situation est différente. Les possibilités de décrire une qualité de service demandée et d'établir un support de communication permettant de l'assurer dans l'UTRAN sont bien plus évoluées et c'est toute une architecture de gestion de la qualité de service qui a été définie. La mise en œuvre des différentes qualités de service dans les équipements du réseau cœur paquet est laissée à la charge des constructeurs. Ceux-ci sont libres de choisir des solutions standardisées par ailleurs, à l'IETF par exemple. Ainsi, certains constructeurs choisiront de l'implémenter au-dessus d'un transport ATM tandis que d'autres iront vers un transport MPLS et une architecture DiffServ. Nous décrirons rapidement cette solution puisqu'elle est déjà proposée par plusieurs constructeurs.

7.6.1. Les classes de services définies

Les classes de services définies pour le GPRS 2G étaient trop complexes à utiliser et à comprendre pour les utilisateurs. Le parti a donc été pris de


simplifier les classes de service dans l 'UMTS. Ainsi, quatre classes ont été définies et classées en fonction de leur sensibilité au délai et aux pertes. Chacune de ces classes est principalement dédiée à un type d'application. Ainsi les deux premières classes se destinent aux trafics ayant des contraintes de délais fortes (pseudo temps réel), comme par exemple les applications multimédias, tandis que les deux suivantes serviront aux applications standards (navigateur, courrier électronique,...) ayant ou non des interactions avec l'utilisateur.

Classe de trafic Principales caractéristiques Exemple d'application

Conversationnel Préservation de la relation temporelle entre les paquets

Délais faibles et constants

Voix, VoIP, vidéo

conférences

Streaming Préservation de la relation temporelle entre les paquets

Diffusion de contenu

multimédia Interactive Préservation du contenu (peu d'erreurs)

Mode de fonctionnement requête - réponse Navigation

Internet

Arrière-plan (Background)

Préservation du contenu (peu d'erreurs) Pas de contraintes temporelles

Téléchargement (courrier

électronique)

Tableau 7.1. Les classes de service du domaine paquet de l'UMTS (Release 99)

En plus de la notion de classe de service, l'UMTS définit de manière très précise le comportement associé à chaque support de communication (bearer) par un jeu d'attributs. Tous ces attributs sont négociables au moment de la création d'un contexte PDP mais les valeurs maximales sont mentionnées dans les données d'abonnement stockées 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 spécifié. 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 différentes. En effet, le délai sur le support UMTS (bearer UMTS) se décompose en deux parties : le délai sur le support radio et le délai sur le support cœur de réseau.


Attributs Conversational Streaming Interactive Background Débit maximal < 2 Mbit/s < 2 Mbit/s < 2 Mbit/s

(- les en-têtes) < 2 Mbit/s

(- les en-têtes) Séquencement Oui ou non Oui ou non Oui ou non Oui ou non Taille des SDU < 1 500 < 1 500 < 1 500 < 1 500

Livraison des SDU erronées

Oui/Non1- Oui/Non/- Oui/Non/- Oui/Non1-

Taux d'erreur bit résiduel 5.10 2 à 10"6 5.10"2 à 10"6 4.10"3 à 6.10"8 4.10"3 à 6.10"8

Taux de SDU erronées 1 0 2 à 10"5 10"2 à 10"5 10"3 à 10"6 10"3 à 10"6

Délai de transfert A partir de 100 ms

A partir de 250 ms

- -

Débit garanti < 2 Mbit/s < 2 Mbit/s - -

Priorité de traffic 1,2 et 3 Priorité à

l'allocation/maintien 1,2 et 3 1,2 et 3 1,2 et 3 1,2 et 3

Tableau 7.2. Attributs associés aux classes de service pour le support de communication UMTS

7.6.2. Une architecture complète

Une architecture complète de gestion de la qualité de service a été définie pour la Release 99 de l'UMTS. Cette architecture définit les relations entre les différents supports de communication avec la volonté de préserver des interfaces claires entre des domaines de gestion de la qualité de service indépendants. Cela permet de garantir une interopérabilité entre les fabricants, d'une part, et entre les réseaux, d'autre part.

7.6.2.1. Les différents niveaux de gestion de la QoS

A chaque support de communication (bearer) est associé un ensemble d'attributs définissant le service offert par le support, ce support utilisant lui-même d'autres supports de niveau inférieur pour assurer la transmission effective des données. Ainsi (voir figure 7.35), pour offrir un service de bout en bout, il faut composer : un support local entre le terminal mobile et l'ordinateur (souvent à travers une connexion PPP), un support UMTS et un support externe. Le support UMTS est lui-même composé d'un support radio et d'un support cœur de réseau.

A ce jour, le support radio est très bien défini et les différentes fonctions nécessaires sont complètement spécifiées. Ce n'est pas le cas du support cœur de réseau, il est seulement précisé que, pour sa mise en place, les constructeurs et les opérateurs auront à choisir des solutions définies en dehors du cadre du 3GPP.


L'opérateur peut par exemple choisir une solution basée sur des circuits virtuels ATM ou utiliser l'architecture de gestion de la qualité de service à différenciation de services spécifiée par l'IETF sur IP (Diffserv [RFC 2475]). De la même manière, le support sur l'interface lu entre le réseau d'accès radio et le réseau cœur peut utiliser une solution basée sur ATM ou sur IP. Dans tous les cas, l'interaction entre une solution basée sur ATM et IP se fera en utilisant les classes de service DiffServ. Pour ce qui est du lien avec le réseau externe, cela dépendra évidemment des possibilités que ce réseau externe offre. Aujourd'hui, seul un service IP pour le mieux (Best Effort) est universellement disponible.

Figure 7.35. Différents niveaux de gestion de la QoS (en relation avec les supports de communication)

Les attributs des services supports réseau et lu dépendent bien évidemment de la solution de gestion de qualité de service retenue par l'opérateur. De plus, celui-ci contrôle la manière 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 nécessaires, à la fois dans le plan de contrôle et dans le plan usager.


7.6.2.2. Gestion des ressources (dans le plan de contrôle)

Dans le plan de contrôle, on retrouve à chaque niveau les fonctions permettant d'établir et de gérer les supports de communication. Il est aussi nécessaire 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 contrôle d'accès en termes de ressources font le lien avec les technologies de transport sous-jacente tandis que celles gérant les droits d'accès se chargent de faire la liaison avec les données d'abonnement maintenues par le HLR.

Figure 7.36. Gestion de la qualité de service dans le plan de contrôle

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 éléments d'information transmis. Elles permettent de mettre en correspondance un flux de données et le support de communication auquel il sera associé (classification). Par exemple dans le GGSN, c'est la fonction qui, à l'aide du filtre, détermine 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 entrée est trop important, l'excédent sera détruit ou re-marqué avec une priorité moindre. Le marqueur (mapper (D) sert à attribuer au paquet un marquage dans un champ de l'en-tête ÏP, ce marquage correspondant à la qualité de service requise en fonction du support déterminé par la fonction de


classification. Enfin, le gestionnaire de ressources (©) répartit les ressources disponibles entre les différents 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 cœur de réseau paquet

Une des solutions de mise en œuvre de l'architecture de l'UMTS pour le cœur de réseau est basée sur un cœur de réseau IP/MPLS et sur l'architecture DiffServ. Ainsi l'opérateur s'occupe d'un dimensionnement global de son réseau pour les différentes classes de service DiffServ, il n'y a pas à proprement parler de réservation flux par flux. Par contre, il peut y avoir, pour les classes de services critiques, un contrôle d'accès lors de l'établissement du contexte PDP. Dans ce cas, le SGSN, après avoir vérifié les droits de l'utilisateur, vérifie si la ressource demandée est disponible ou non. Il y a une correspondance statique entre les classes de trafic UMTS et classes de service DiffServ (voir tableau 7.3).

Classes de trafic UMTS Comportements DiffServ Conversationnel EF A flux continus AF11, AF12, AF13

Interactif AF21, AF22, AF23 Arrière plan BE (pour le mieux)

Tableau 7.3. Correspondance entre les classes de service UMTS et les comportements (PHB) DiffServ


Cette solution est très souple pour l'opérateur, elle lui permet de choisir n'importe quelle technologie de niveau 2 et même de panacher différentes technologies en fonction des caractéristiques recherchées. MPLS se charge alors de l'interfonctionnement des différents niveaux de liaisons mis en œuvre. De plus, grâce à MPLS, l'opérateur peut gérer finement le trafic dans son réseau et même passer à une solution de réservation 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'intérieur des classes de service, n'est pas forcément la même pour tous les services offerts par l'opérateur (c'est-à-dire pour tous les APN). Ainsi, un service peut être dédié au multimédia (diffusion de flux Mpeg4) et se voir appliquer une politique de marquage des paquets dépendant directement de la sémantique applicative de ceux-ci. En effet, en perdant prioritairement les trames les moins importantes d'un flux multimédia, il est possible d'améliorer sensiblement le rendu applicatif de ces flux en cas de congestion.

Routeur frontière Diffserv. - traduction vers les classes UMTS - classification - mise en forme et marquage - files d'attente et ordonnancement

Routeur frontière 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 cœur de réseau avec IP/MPLS/DiJfserv

7.7. Evolution vers un cœur de réseau tout IP

La première version de l'UMTS conserve deux domaines bien distincts, comme dans les réseaux GSM-GPRS. Les opérateurs ne sont pas prêts à prendre le risque de déployer une architecture entièrement 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 opérateurs le temps d'expérimenter de nouveaux services dans le domaine paquet.


L'évolution de l'UMTS vers les releases 4 et 5 entraîne des changements beaucoup plus profonds. Les spécifications des différentes version de TUMTS ne sont pas toutes complètement figées, et les constructeurs gardent une certaine marge de manœuvre dans le choix des solutions techniques. Ainsi, par exemple, ATM qui est souvent présentée 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 réseaux UMTS à évoluer vers des réseaux de service ouvert basés sur le protocole IPv6 (au moins pour l'IMS) et sur les protocoles de contrôle et de signalisation définis à l'IETF (SIP, MEGACO). Cette évolution se ressent jusque dans le réseau d'accès où IP sera utilisé comme technologie de transport ; cependant, le réseau d'accès conserve ses spécificités pour la gestion de la radio et des déplacements des mobiles.

7.7.1. Evolutions de la Release 4

La quatrième version de l'UMTS est une révision mineure des cœurs de réseaux des domaines paquet et circuit. Toutefois, la transition vers le réseau tout IP de la version 5 passe par cette révision qui voit la signalisation du domaine circuit passer au-dessus d'IP.

Figure 7.39. Architecture de l'UMTS {.Release 4)


Le cœur de réseau du domaine circuit abandonne partiellement le fonctionnement en mode circuit pour implémenter une architecture de gestion des appels complètement différentes. Ce réseau 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 réseau cœur. En effet, auparavant il fallait maintenir des circuits de 64 kbit/s dans le cœur de réseau, tandis que dans cette version de l'UMTS, seul l'équipement qui est en relation avec un réseau de téléphonie (PSTN) aura à faire la conversion vers un circuit à 64 kbit/s.

Les fonctions liées à la signalisation et celles liées au transport des communications sont associées à des équipements différents. 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 dédiée au contrôle.

Autre point remarquable de cette version, les bases de données ne changent pas ou peu et elles sont toujours accédées à travers les mêmes interfaces. Le réseau cœur paquet n'évolue pratiquement pas, et restera en l'état dans la version suivante.

7.7.2. Evolutions prévisibles 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 réseau et SIP pour la signalisation devrait permettre une plus grande ouverture des plates-formes de service, réduisant ainsi les délais et les coûts associés à 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 réseau.

Cette plate-forme de service devrait permettre une intégration beaucoup plus facile avec les services disponibles sur l'Internet. Certains constructeurs font déjà la démonstration de terminaux clients supportant à la fois SIP et IPv6 et permettant d'utiliser des services innovants comme les services de présence (Instant Messenging) ou les réseaux coopératifs (P2P, Peer-to-Peer).


Figure 7.40. Architecture de l'UMTS (Release 5)

L'autre évolution importante consiste à utiliser une architecture de gestion des appels multimédias (téléphonie dans un premier temps) définie à l'IETF (MEGACO). Ainsi, après le protocole de transport de niveau réseau, c'est la partie contrôle des appels qui converge. Cette architecture offre une solution de contrôle des appels au-dessus de l'Internet, mais n'est pas déployée aujourd'hui.

Pour la signalisation et pour les données, l'interconnexion entre les réseaux d'accès et les réseaux cœurs passe par un réseau IP sur ATM, de même que le cœur de réseau IP. Toutefois, les constructeurs conservent une marge de manœuvre dans le choix de la technologie de transport utilisée dans ces réseaux. La seule contrainte pour le cœur de réseau IP est qu'il supporte, d'une manière ou d'une autre, une gestion de la qualité de service de bout en bout pour le domaine paquet.

7.8 Conclusion

La «Release 99» de l'UMTS sera la première version de l'UMTS déployée. Elle l'est depuis 2002 au Japon dans une forme un peu particulière et en Europe depuis 2004. Du point de vue du cœur de réseau, elle apporte peu de changement par rapport à la Release 99 du GSM/GPRS. Toutefois, elle initie des changements


importants comme une architecture de gestion de la qualité de service complète qui ne sera sans doute jamais utilisée dans cette version mais qui permet de déployer progressivement les réseaux cœurs du domaine paquet qui prendront la relève des réseaux cœurs du domaine circuit pour le transport de la signalisation et des appels voix dans les prochaines versions. Le réseau cœur du domaine circuit évolue peu et il s'agit surtout d'un réseau de transition appelé à disparaître dans un avenir plus ou moins proche suivant les opérateurs. En effet, les opérateurs disposant d'un réseau cœur circuit fonctionnel et du savoir-faire pour l'administrer n'ont pas de raison impérieuse de l'abandonner immédiatement.

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 réseau de l'opérateur passe à IPv6 tout de suite, mais il faut préparer l'arrivé de l'IMS (qui sera seulement en IPv6) dans les futures versions et pour cela commencer à déployer et à expérimenter les services IPv6.

Le 3GPP a envisagé une évolution très progressive des cœurs de réseaux vers des solutions tout IP plus ouvertes sur les services. Cette évolution a déjà commencée avec le GPRS de la phase 2+ du GSM. Ce sont d'abord les nouveaux services dont les services orientés données qui migrent vers le cœur de réseau paquet.

Le cœur de réseau du domaine circuit commence progressivement à utiliser les technologies IP avant de se confondre avec le cœur de réseau du domaine paquet. Les cœurs de réseau des autres domaines qui apparaissent, comme le domaine IMS, démarrent tout de suite en IP et même en IPv6 pour éviter une transition supplémentaire dans quelques années.

Les évolutions futures (à partir de la version 6) des cœurs de réseau sont encore peu stables en 2004 et sujettes à beaucoup de débats. Elles porteront (pour ce qui est du cœur de réseau) sur la manière de gérer la mobilité qui pourrait bien être MobilelP et sur la possibilité de migrer une partie du réseau d'accès radio sous IP.

Pour ce qui est de la technologie IP, le choix d'IPvô semble acquis à terme. Mais tout n'est pas encore prêt et le 3GPP ne peut se contenter de prendre des solutions toutes prêtes qui seraient définies par l'IETF. Au contraire, il faudra que les opérateurs et les constructeurs participent à l'effort de standardisation au sein de l'IETF comme cela a déjà commencé.


7.9. Bibliographie

[22.078] 3rd Génération Partnership Project, « Customised Applications for Mobile Network Enhanced Logic (CAMEL): Service description, Stage 1, TS 22.078-390», Technical Spécification Group Services and Systems Aspects, 2002.

[23.002] 3rd Génération Partnership Project, « Network architecture, TS 23.002-360 », Technical Spécification Group Services and Systems Aspects, 2002.

[23.003] 3rd Génération Partnership Project, «Numbering, addressing and identification, TS 23.003-3e0 », Technical Spécification Group Core Network, 2003.

[23.008] 3rd Génération Partnership Project, « Organization of subscriber data, TS 23.008-380 », Technical Spécification Group Core Network, 2003.

[23.060] 3rd Génération Partnership Project, « General Packet Radio Service (GPRS): Service description; stage 2, TS 23.060-3g0 », Technical Spécification Group Services and Systems Aspects, 2003.

[23.078] 3rd Génération Partnership Project, « Customised Applications for Mobile Network Enhanced Logic (CAMEL): Service phase 3, Stage 2, TS 23.078-3j0 », Technical Spécification Group Core Network, 2004.

[23.107] 3rd Génération Partnership Project, « Quality of Service (QoS) concept and architecture, TS 23.107-390», Technical Spécification Group Services and Systems Aspects, 2002.

[23.121] 3rd Génération Partnership Project, « Architectural Requirements for Release 1999, TS 23.121-360 », Technical Spécification Group Services and Systems Aspects, 2002.

[23.171] 3rd Génération Partnership Project, « Functional stage 2 description of location services in UMTS, TS 23.171-3b0», Technical Spécification Group Services and Systems Aspects, 2004.

[Q.1214] International Télécommunication Union, Distributed Functional Plane for Intelligent Network CS1, ITU-T Q.1214, ITU-T, 1994.

[RFC 1034] MOCKAPETRIS P., Domain Names: concepts and facilities, RFC 1034, IETF, 1987.

[RFC 1035] MOCKAPETRIS P., Domain Names: Implementation and spécification, RFC 1035, IETF, 1987.

[RFC 2401] KENT S., ATKINSON R., Security System Architecture for the Internet Protocol, RFC 2401, IETF, 1998.

[RFC 2475] BLAKE S., BLACK D., CARLSON M., DAVIES E., WANG Z., WEISSW., An Architecture for Differentiated Services, RFC 2475, IETF, 1998.

[RFC 2794] CALHOUNP., PERKINS C., Mobile IP Network Access Identifier Extension for IPv4, RFC 2794, IETF, 2000.

[RFC 3344] PERKINS C., IP Mobility Support for IPv4, RFC 3344, IETF, 2002

[BAT 02] BATES R., GPRS: GeneralizedPacket Radio Service, McGraw-Hill, 2002.


[CHE 04] CHEN J.-C., ZHANG T., IP-Based Next-Generation Wireless Networks: Systems, Architectures and Protocols, Wiley, 2004.

[FAG 02] FAGGIONN., Le GPRS : Du WAP à l'UMTS, Dunod, 2002.

[CIS 02] CIZAULTG., IPV6, Théorie et pratique, O'Reilly, 2002.

[LAG 00] LAGRANGE X., GODELWSKI P., TABBANE S., Réseaux GSM, Hermès, 2000.

[LES 01] LESCUYERP., UMTS : Les origines, l'architecture, la norme, Dunod, 2001.

[RUS 02] T. RUSSEL, Signaling System #7, McGraw-Hill, 4e édition, 2002.

[SER 91] SERET S., CHAILLEY P., RNIS, description technique, Dunod, 1991.

Les

Chapitre 8

architectures de services de l'UMTS

8.1. Historique de l'évolution des services dans les réseaux radio-mobiles

8.1.1. Des services supplémentaires à CAMEL

Les premiers services mobiles mis à disposition sur le réseau GSM (Global Sys-tem for Mobile Communications) ont été développés suivant la même méthodologie que celle mise en œuvre pour le RNIS (Réseau numérique à intégration-de services). Ils se répartissent dans une des trois familles de services suivantes (on qualifiera cette approche declassique,demêmeque les services correspondants, dans la suite de notre exposé) :

- les services supports servent à transporter le trafic utilisateur entre les terminaux utilisés dans le cadre d'une communication. Le réseau n'effectue aucun traitement sur les informations transportées autre que ceux nécessaires au transport de l'information utilisateur (par exemple transport d'échantillons numériques vocaux sur un circuit té-léphonique) ;

- les téléservices sont chargés d'effectuer un traitement sur des informations trans-portées par le réseau afin de les mettre sous une forme compréhensible par l'utilisateur final (par exemple mise en forme du signal numérique sous forme d'ondes sonores pour le téléservice de téléphonie, production d'un document papier à partir de mes-sages numériques pour le téléservice de télécopie...) ;

- les services supplémentaires sont nécessairement associés à un téléservice. Ils sont supposés enrichir un téléservice en apportant de nouvelles possibilités à l'utilisa-teur final (par exemple le service supplémentaire renvoi d'appel peut être associé au téléservice de téléphonie).

Chapitre rédigé par Philippe MARTIN s.


Cette méthodologie a été reprise en UMTS (Universal Mobile Télécommunica-tions System) dans la recommandation 22.105. Néanmoins, les opérateurs mobiles et les constructeurs ont opté pour d'autres approches lorsque le service à mettre en place sur le réseau devient trop complexe. L'approche classique s'appuie sur un processus de normalisation très strict. Elle s'est très vite avérée trop restrictive. Le développement de nouveaux services, dans un contexte de dérégulation du marché des télécommu-nications, nécessite des temps de développement plus courts et une architecture logi-cielle plus flexible. L'ajout ou la modification de services classiques exige très souvent une mise à jour onéreuse de fonctions logicielles, situées au niveau des terminaux ou d'équipements réseaux, comme les fonctions de traitement d'appel des MSC (Mobile services Switching Center).

Les opérateurs mobiles ont dès lors opté pour l'utilisation de la technique réseau intelligent, déjà largement utilisée dans le réseau téléphonique fixe. L'adoption du RI (Réseau intelligent) ou IN (Intelligent Network) a permis d'enrichir l'offre (comme les offres d'abonnements par cartes prépayées). Cependant, les services réseau intelli-gent proposés dans les réseaux mobiles restaient inaccessibles quand l'abonné était en itinérance. Les solutions déployées ont dû être adaptées pour fonctionner sur les MSC, ce qui a donné naissance à diverses plates-formes propriétaires et donc à des problèmes d'interopérabilité. C'est dans ce contexte que l'ETSI (European Télécommunications Standards Institute) a décidé d'introduire CAMEL (Customized Applications for Mo-bile network Enhanced Logic). L'objectif de CAMEL est double :

- définir une architecture réseau rendant possible l'utilisation de services mobiles en dehors du réseau nominal de l'abonné, tout en conservant l'environnement utilisa-teur lors du déplacement de ce dernier ;

- définir des interfaces ouvertes entre les équipements du réseau, y compris lorsque l'utilisateur est en itinérance (roaming).

CAMEL ne définit pas à proprement parler de nouveaux services puisqu'il s'ap-puie sur des protocoles issus du réseau intelligent et adaptés pour les réseaux mobiles. Il permet à un utilisateur d'invoquer ses services depuis un réseau visité et donne les moyens de résoudre les problèmes d'interopérabilité. Les concepts et les protocoles du réseau intelligent1 sont en grande partie réutilisés et adaptés au contexte mobile. L'ap-port majeur de CAMEL réside dans la définition d'une interface de commande nor-malisée entre la plate-forme de service et le MSC. CAMEL fournit aussi les moyens à une plate-forme de service d'un opérateur de piloter à distance les commutateurs d'un autre opérateur (ce qui n'était pas possible dans les versions réseau intelligent provenant du réseau fixe).

1. Plus particulièrement la version européenne normalisée à l'ETSI.

Les architectures de services de l 'UMTS 341

8.1.2. Evolutions vers VHE et OSA

Le concept de VHE ( Virtual Home Environment) a été défini pour apporter aux utilisateurs une interface d'accès aux services souscrits indépendante du réseau. Les utilisateurs disposent ainsi d'une interface unique pour déclencher leurs services et pour les personnaliser. L'environnement et les préférences associées aux services de l'utilisateur sont conservés lors de l'itinérance.

VHE peut être vu comme une généralisation du service apporté par CAMEL. CA-MEL s'appuie sur les services du protocole réseau CAP {CAMEL Application Part). VHE, au contraire, a pour vocation d'être indépendant de la technologie réseau sous-jacente. Il s'appuie sur plusieurs technologies mises en œuvre à la fois au niveau du mobile, comme MExE (.Mobile Execution Environment) ou SAT (SIM Application Toolkit) et au niveau du réseau comme OSA (Open Service Architecture).

La norme OSA a été introduite pour rendre possible cette indépendance au niveau du réseau cœur. OSA est un intermédiaire entre les services et les fonctionnalités ré-seau indispensables à la mise en œuvre du VHE. Toutes les fonctions réseaux comme le contrôle d'appel, la gestion de la localisation ou encore le contrôle de ressources de télécommunications spécialisées, deviennent accessibles depuis les applications. De même, OSA permet à des fournisseurs de services tiers de proposer des services sur l'infrastructure d'un opérateur mobile traditionnel.

8.1.3. Evolutions vers IP

Les versions de l'UMTS postérieures à 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 réseau appelé sous-système IP multimédia. Cette zone est localisée dans le réseau cœur. Elle est joi-gnable depuis le réseau d'accès en passant systématiquement par le domaine paquet. Le sous-système IP multimédia contient un ensemble de serveurs applicatifs basés sur la technologie SIP (Session Initiation Protocol) et destinés à apporter des services IP multimédia du même type que ceux offerts dans le domaine circuit (conférence d'ap-pels, renvoi d'appels,...), sans toutefois se limiter à ceux-ci (services de messagerie instantanée, service de présence, consultation de boîtes vocales...).

8.2. Rappels sur les réseaux intelligents

8.2.1. Notion de segment d'appel

Le réseau intelligent est issu du monde de la téléphonie fixe. Il a été conçu au début des années 80 pour faciliter le développement de nouveaux services de télécommuni-cations sur une infrastructure téléphonique (numéro vert, cartes prépayées...).


Le RI a pour objectif de rendre un commutateur téléphonique (ou ressource de té-lécommunications) programmable à distance dans le but de faciliter le développement de nouvelles offres de services. Historiquement, les premiers travaux ont porté sur la définition de services déclenchés à partir d'appels téléphoniques, ou plus précisément à partir d'un segment d'appel (voir figure 8.1 et paragraphe 8.2.4.4). Dans la suite de l'exposé, on utilise le terme anglais équivalent CS (Call Segment). Ce dernier repré-sente un automate chargé du traitement de la signalisation d'appel sur chaque interface utilisée par la communication de bout en bout. Un appel téléphonique requiert la pré-sence de deux segments d'appel (un segment d'appel originant et un segment d'appel terminant) par commutateur traversé par le circuit de parole2. Par exemple, une com-munication entre deux abonnés A et B reliés à un même commutateur fait intervenir deux segments d'appel. Si les deux abonnés sont raccordés chacun à un commutateur et que les deux commutateurs sont directement reliés, la communication fait intervenir quatre segments d'appel (voir figure 8.1).

L'intérêt de décomposer les appels en segments d'appel est de pouvoir définir des services soit au départ d'un appel téléphonique, soit à l'arrivée. Il devient alors pos-sible de séparer la fonction de traitement d'appel, appelée CCF (Call Control Func-tion) dans la terminologie réseau intelligent, et la logique de service appelée SCF (Ser-vice Control Function). Ce découpage a permis d'ajouter progressivement d'autres types de services et d'enrichir les possibilités offertes par le réseau intelligent. Au fur et à mesure des évolutions du standard, d'autres interfaces de signalisation ont été spécifiées pour permettre le déploiement de nouveaux services. Les premiers services réseaux intelligents étaient obligatoirement déclenchés depuis un segment d'appel. Ce n'est plus nécessairement le cas aujourd'hui, notamment avec le support des inter-actions OCCUUI (Out of Channel Call Unrelated User Interaction) depuis la phase CS-2.

8.2.2. Évolution et structure des standards

Le réseau intelligent évolue par phase. Chaque phase, appelée ensemble de capa-cités (CS, Capability Set), définit un ensemble de services cibles, susceptibles d'être offerts à l'utilisateur final, ainsi que toutes les fonctions réseaux nécessaires à leur mise en œuvre. L'ITU a défini quatre ensembles de capacités. Le CS-1 a été la pre-mière série de recommandations réseau intelligent adoptée par l'ITU. Elle est actuelle-ment largement déployée dans le réseau téléphonique commuté. Les services comme le numéro vert ou les cartes prépayées font partie de cette première série. Les services couverts par CS-1 ne peuvent être activés que pendant les phases non stables de l'appel - c'est-à-dire avant que la demande d'appel n'ait été acheminée par le commutateur

2. Choix de modélisation adopté par l'ITU (International Télécommunications Union) et l'ETSI.


Appel téléphonique entre deux commutateurs et segments d 'appels associés

Figure 8.1. Segments d'appels et logique de service RI

appelant vers le commutateur distant. Le standard CS-2, approuvé en 1997, étend le champ d'application de CS-1 en prenant notamment en compte les appels multipar-tites, les interactions directes entre les utilisateurs et les plates-formes de services en dehors d'un segment appel existant. Le déclenchement d'un service depuis les phases stables de l'appel est également possible comme dans le cas du passage d'un appel à une conférence d'appel via une séquence utilisateur DTMF (Dual Tone Multiple Frequency) ou via l'envoi de messages de signalisation RNIS en provenance du ter-minal et à destination de la plate-forme de service : on parle alors de OCCRUI (Out of Channel Call Related User Interaction). Le standard CS-3 a été défini en 1999 pour introduire les services réseau intelligent dans un environnement ATM (Asynchronous Transfer Mode). Le standard CS-4 aborde l'utilisation de la technique réseau intelli-gent dans le cas de services mettant en œuvre le réseau téléphonique et l'Internet. Les ensembles de capacités sont décrits dans les séries de recommandations Q12nx, où n identifie le numéro d'ensemble de capacité considéré et où x correspond à un numéro de recommandation (voir tableau 8.2).


Phase Principales caractéristiques CS-1 Déclenchement du service depuis les phases non stables de l'appel.

Utilise uniquement le BCSM (Basic Call State Model). CS-2 Déclenchement du service possible depuis les phases stables de l'appel.

Support des appels multipartite CPH (Call Party Handling). Déclenchement de services non liés à des appels. Utilisation du CSCV (Call Segment Connection View) pour la modélisa-tion d'appels multipartite. Support des interactions OCCUUI et OCCRUI

CS-3 Support de services réseau intelligent dans un réseau ATM. Nouveau modèle d'appel prenant en compte l'établissement de connexions sur un réseau ATM

CS-4 Services réseau intelligent s'appuyant à la fois sur le réseau téléphonique et l'Internet.

Tableau 8.1. Classification des ensembles de capacités du réseau intelligent

Série de recommandations Q12nx Suffixe x Description du contenu

0 Structure des recommandations pour le jeu de capacité n 1 Résume les principales caractéristiques du jeu de capacité n 2 Description du plan de services 3 Description du plan fonctionnel global 4 Description du plan fonctionnel réparti 5 Description du plan physique 8 Description du protocole INAP (Intelligent Network Application Part) 9 Guide de l'utilisateur réseau intelligent

Tableau 8.2. Structure des recommandations réseau intelligent

8.2.3. Le modèle conceptuel du réseau intelligent

Le réseau intelligent utilise un modèle de développement des services de type fonc-tionnel descendant. Plusieurs étapes interviennent dans l'élaboration d'un service. Les étapes, appelées plans, correspondent à différents niveaux d'abstraction associés au processus de développement. Un service réseau intelligent est systématiquement dé-crit selon les quatre plans suivants : plan de services, plan fonctionnel global, plan fonctionnel réparti et plan physique. Le plan de services apporte une description tex-tuelle du comportement des différents services apportés par un jeu de capacités. Les

Les architectures de services de l'UMTS 345

normes définissent un ensemble de fonctions normalisées, appelés éléments de ser-vices, décrivant le comportement des services tels qu'ils doivent être vus par l'uti-lisateur. Les éléments de services peuvent être combinés pour apporter une offre de service plus élaborée.

Dans le plan fonctionnel global, les services sont décris via un modèle de génie lo-giciel introduit par l'ITU. Ils sont représentés par des enchaînements de blocs logiciels élémentaires normalisés appelés SIB (Service Indépendant Building Block). Chaque SIB implémente une fonction offerte par le réseau de l'opérateur et peut être réutilisée (par exemple SIB BCP (Basic Call Process) pour la fonction de traitement d'appel, SIB Translate pour la fonction de traduction de numéro, ...). A ce niveau d'abstrac-tion, le concepteur ne se préoccupe ni des traitements nécessaires à la réalisation des différents SIB ni des protocoles de signalisation et des ressources indispensables à la mise en œuvre du service considéré. Les services et les éléments de services sont dé-composés en SIB dans le plan fonctionnel global.

Le plan fonctionnel réparti définit un ensemble de fonctions réseaux élémentaires utilisées lors de l'exécution d'un service réseau intelligent. Les fonctions réseaux élé-mentaires sont appelées des entités fonctionnelles et les instances de ces fonctions sont désignées par le sigle FEA (Functional Entity Action). Les FEA sont des pro-cessus applicatifs qui s'exécutent sur des équipements réseaux et qui échangent des flux d'information. Les SIB du plan fonctionnel global sont décomposés en groupe de FEA.

Le plan physique décrit la correspondance entre les entités fonctionnelles du plan fonctionnel réparti et les équipements réseaux. Il précise également le type d'infra-structure qui va être utilisé pour transporter les flux d'information du plan fonctionnel réparti. La plupart du temps ce sont les services de transport du réseau SS7 qui sont utilisés.

Dans la suite, nous ne décrirons que le plan fonctionnel réparti dont la terminologie est largement reprise dans les recommandations de CAMEL.

8.2.4. Le plan fonctionnel réparti

8.2.4.1. Architecture fonctionnelle du réseau intelligent version CS-1

Le plan fonctionnel réparti introduit une architecture fonctionnelle où est placé un ensemble de fonctions réseaux nécessaires à la réalisation des services réseau intelli-gent. Les principales entités fonctionnelles sont intimement liées à la logique de mise en œuvre du service (voir figure 8.3) :


Figure 8.2. Modèle conceptuel du réseau intelligent

- la CCAF (Call Control Agent Function) permet à un utilisateur de contacter la fonction de traitement d'appel. Elle collecte et interprète la signalisation issue du terminal de l'abonné (DTMF, signalisation Q931 du RNIS) en vue d'initier un appel téléphonique ;

- la fonction de traitement d'appel CCF permet de contrôler les appels télépho-niques et les ressources associées à un appel ;

- la SSF (Service Switching Function) sert à reconnaître les demandes de service réseau intelligent. Elle est également à l'origine du déclenchement des services RI et joue le rôle d'intermédiaire entre la fonction de traitement d'appel et la logique de service distante (elle informe la SCF de l'occurrence de certains événements et répercute 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 nécessaire.

Certaines entités fonctionnelles sont plus liées à des données ou des ressources utilisées pour la réalisation du service :

- la SDF (Service Data Function) est une base de données contenant des informa-tions associées aux abonnés d'un service RI. La SCF a la possibilité de consulter et de


mettre à jour certaines de ces informations ; - la SRF (Service Resource Function) est une ressource de télécommunications

spécialisée permettant à l'utilisateur d'interagir avec le service (par exemple serveur vocal, convertisseur texte/son...).

D'autres entités sont plus en rapport avec l'administration : la SMF (Service Mana-gement Function) permet à l'opérateur d'administrer ses services RI ; la SMAF (Ser-vice Management Agent Function) est une interface utilisateur permettant à l'opérateur d'utiliser les services apportés par le SMF; la SCEF (Service Création Environment Function) est une plate-forme de génie logiciel permettant de développer et de tester de nouveaux services RI. Ces entités sont citées pour mémoire et ne sont pas détaillées dans ce chapitre.

8.2.4.2. Architecture fonctionnelle du réseau intelligent : les ajouts de CS-2

La série CS-2 ajoute essentiellement les deux entités fonctionnelles SCUAF (Ser-vice Control User Agent Function) et CUSF (Call Unrelated Service Function), néces-saires pour déclencher des services réseaux intelligent sans établir d'appel. Le SCUAF récupère la signalisation en provenance des utilisateurs et le CUSF est chargée de dé-tecter et de déclencher les demandes de services réseau intelligent.

8.2.4.3. L'interface commutateur plate-forme de service

Le cœur du plan fonctionnel réparti repose sur les flux d'information échangés entre les entités fonctionnelles SSF et SCF. Cette liaison fonctionnelle représente le lien existant entre un commutateur téléphonique 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 répercute sur la fonction de traitement d'appel. La SSF tient également informée la SCF de tout événement important survenant lors de l'exécution d'un service (demande de service, connexion/déconnexion d'un utilisateur, information sur le temps écoulé depuis le début de la communication...).

La SSF fournit par ailleurs une abstraction des activités de la fonction de traite-ment d'appel. Cette abstraction définit les points d'interactions possibles entre une plate-forme de service externe et un commutateur. La figure 8.3 précise la structure de l'interface SSF-CCF et les flux d'informations qui s'échangent entre ces entités. L'interface SSF-CCF est découpée en trois blocs principaux [ITU-T Q1214J[ITU-T Q1224] :

- la BCM (Basic Call Manager) est en relation directe avec la fonction de traite-ment d'appel téléphonique. Elle détecte les événements susceptibles de déclencher un service réseau intelligent. Cette entité contrôle également les appels et les connexions


Plate-forme de service

Commutateur téléphonique

Figure 8.3. Interface CCF-SSF-SCF

liées à une instance de service réseau intelligent. Les activités du BCM sont modéli-sées 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 modèle abstrait permet-tant de manipuler la topologie et les propriétés d'un segment appel lié à une instance de service. Ce modèle est étroitement lié au BCSM introduit précédemment. La IN-SSM manipule, sur ordre de la SCF ou de la CCF un ensemble d'objets du modèle représentant diverses ressources de télécommunication impliquées dans l'appel. La IN-SSM n'a réellement été utilisé qu'à partir de CS-2, notamment pour le contrôle


des appels multipartite. Le modèle 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 modèle3 et non plus directement sur les automates BCSM comme en CS-1. Les différents états des objets de modèle CV sont normalisés [ITU-T Q1228] et désignés par le sigle CSCV ;

- la FIM-CM (Feature Interaction-Call Manager) assure la coexistence entre les instances de service réseau intelligent et les autres types de services, comme par exemple les services supplémentaires. Elle gère également les problèmes de compati-bilité pouvant survenir entre la SSF et la SCF.

8.2.4.4. Le modèle CSCV

Le modèle CSCV introduit quatre objets qui permettent de manipuler à distance, via le protocole INAP, la topologie et l'état des segments d'appels associés à une même instance de service réseau intelligent. Les objets leg (voir 8.2.4.4) sont les ressources de transmission et de commutation utilisées par une communication (par exemple, une liaison entre deux commutateurs téléphoniques). L'objet CP (Connec-tion Point) est le point de raccordement de plusieurs legs. Le CS représente un segment d'appel (voir figure 8.1). Il peut être associé à un ou plusieurs legs. Le CSA (Call Seg-ment Association) est un objet pouvant regrouper un ensemble de segment d'appels associé à une même instance de service réseau intelligent. Un service de mise en at-tente utilisera deux CS placés dans le même CSA. Un CS sera associé à l'appel actif et l'autre CS à l'appel en attente.

Les objets legs sont appelés demi-appels dans la version française de la norme. L'évolution de l'état des legs est décrite 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'accès ser-vant à raccorder les utilisateurs aux commutateurs téléphoniques et aux liaisons inter commutateurs. Les passive legs servent à raccorder les segments d'appels originant et terminant situés sur un même commutateur et associés à une même instance de service. Les conventions adoptées, comme indiqué en figures 8.4 et 8.5, dans les stan-dards CS-2, font que les controlling legs sont toujours représentées à gauche (et notés c) et les passive legs à droite (notés pl , p2...). Les controlling legs transportent la signalisation en provenance des utilisateurs ou des centraux. Les passive legs trans-portent des signaux internes permettant d'échanger des informations entre deux seg-ments d'appels associés sur un même commutateur.

Un objet leg peut être dans un des quatre états suivants : - l'état Joined (en liaison), indique que l'objet est attaché à un point de raccorde-

ment (toujours représenté en traits pleins sur les schémas) ;

3. On parle alors de CPH.

350 Pr incipes e t évolu t ions de l ' U M T S

( -N

—ï ° • leg v ë CP CS l CSA

CS: Call Segment

CSA: Call Segment Association

Leg (passive)

Leg (controling)

CP: Connection Point

Un exemple de CSA

Figure 8.4. Représentation graphique des objets du modèle 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 présente dans un autre segment d'appel appartenant au même CSA ;

- l'état Pending (en instance) correspond au cas où les ressources modélisées par l'objet leg sont en cours de réservation ;

- l'état Surrogate (de substitution) indique qu'un objet leg est en relation avec un élément interne du réseau (par exemple un serveur vocal).

La recommandation Q1228 définit douze états CSCV décrits en figure 8.5. Ils permettent de modéliser les différents états possibles d'un segment d'appel impliqué dans un service réseau intelligent. Les états normalisés sont les suivants :

- Null : cet état modélise 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 départ 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 associée à un automate OBCSM (Originating BCSM) ;

- Terminating Setup : un appel arrivé destiné à relier deux utilisateurs est dans sa phase d'établissement. La controlling leg est dans l'état pending. La passive leg est dans l'état joined et est associé à un automate TBCSM (Terminating BCSM)


Figure 8.5. Les différents états CSCV


- Stable 2-Party : un appel est établi ou est dans une phase de libération. Il peut s'agir d'un appel départ ou arrivée. Dans tous les cas, la controlling leg est dans l'état joined. La passive leg est également dans l'état joined et peut être raccordée soit à un automate OBCSM soit à un automate TBCSM (suivant que le segment d'appel considéré est situé sur le commutateur départ ou le commutateur arrivée) ;

- 1-Party : cet état correspond à un appel avec une seule partie en cours d'établisse-ment. La controlling leg est dans l'état joined et il n'y a pas de passive leg associée 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 représente un appel départ déclenché depuis le réseau 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 télécommunication spécialisée (serveur vocales, pont de conférences...) ;

- Terminating 1 -Party Setup : cet état correspond à la situation où un appel arri-vée n'impliquant qu'une partie, est établi par le réseau. La controlling leg est dans l'état surrogate. La passive leg est dans l'état joined et elle est associée à un automate TBCSM ;

- Stable 1-Party : cet état représente un appel départ, n'impliquant qu'un seul utili-sateur, et établi par le réseau. La controlling leg est dans l'état surrogate. La passive leg est dans l'état joined. Cette dernière est associée à un automate OBCSM ou TBCSM, suivant que le segment d'appel considéré est au niveau du commutateur départ ou du commutateur d'arrivée, et est placée dans un état stable ou de libération ;

- Forward : cet état modélise un appel réacheminé (l'appel peut être réacheminé au départ ou l'arrivée. Il peut être déclenché aussi bien depuis une phase d'établisse-ment que depuis une phase stable de l'appel). La controlling leg se trouve dans l'état surrogate. La passive leg à l'origine du renvoi est dans l'état joined. La passive leg en relation avec l'utilisateur vers lequel l'appel a été renvoyé est dans l'état Pending ;

- Transfer : cet état modélise un appel transféré. 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 forcément dans un état stable où est sur le point d'être libéré ;

- 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 libération. Toutes les legs du segment d'appel sont dans l'état joined.

8.2.4.5. Le modèle d'appel du réseau intelligent BCSM

Le principe de base du réseau intelligent consiste à découper l'appel en tâches élémentaires. Le modèle d'appel du réseau intelligent peut être ainsi assimilé à un


Figure 8.6. Modèle d'appel du réseau intelligent

automate avec des états et des transitions (voir figure 8.6). Les états sont appelés des PIC (Point In Call). Par exemple, lorsqu'on compose un numéro sur son téléphone, l'automate BSCM est dans un PIC particulier de collecte de ce numéro. Les PIC sont associés à des événements d'entrée et de sortie indiquant respectivement quand un appel entre dans un état ou quand il en sort.

Les points de détection ou DP (Détection 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 contrôle d'un autre entité (c'est-à-dire le SCF) ou l'informer d'un événement.

Les points de détection sont systématiquement présents entre deux états de l'appel. Un DP est défini par deux critères :

- la manière dont il est activé : un DP peut être armé soit statiquement, par exemple par voie d'administration, on parle de Trigger Détection Point ou TDP (Trigger Détec-tion Point), soit dynamiquement par la SCF, on parle alors de Event Détection Point ou EDP (Event Détection 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 requête et la relation SSF-SCF est une relation de contrôle. La SSF stoppe l'exécution 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 réseau intelligent est déclenchée. Dans le cas contraire, le DP est de type notification et la relation SSF-SCF est une relation de supervision. La SSF permet à


SSF-SCF relation de contrôle

SSF-SCF relation de su-pervision

DP armé statiquement TDP

TDP-R (Trigger Détection Point Request)

TDP-N (Trigger Détection Point Notification)

DP armé dynamiquement EDP

EDP-R (Event Détection Point Request)

EDP-N (Event Détection Point Notification)

Tableau 8.3. Différents types de point de détection

la CCF de continuer ses activités. C'est en particulier le cas quand la SSF informe la SCF de la déconnexion d'un utilisateur. Les procédures de libération de l'appel se poursuivent sans attendre une réponse de la SCF.

Le tableau 8.3 reprend les différents types de DP suivant leurs modes d'activation et la nature de la relation existant entre la SCF et la SSF.

Par ailleurs le modèle d'appel réseau intelligent introduit également la notion de critère de déclenchement. Il s'agit d'une condition préalable au déclenchement d'une interaction entre la SSF et la SCF4.

8.2.4.6. Relation entre BCSM et CSCV

L'association entre BCSM et CSCV va dépendre 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 même segment d'appel (ce BCSM serait supprimé si une passive leg venait à être créée ultérieurement dans ce segment d'appel).

8.2.4.7. Les services non liés à des appels

Le CS-1 ne permettait pas de fournir des services qui ne soient pas liés à un ap-pel téléphonique. En effet, le modèle BCSM suppose qu'un appel soit déjà établi ou en cours d'établissement pour permettre le déclenchement d'une demande de service réseau intelligent. La recommandation CS-2 et les recommandations ultérieures per-mette le déclenchement de services non liés à un appel en introduisant un nouvel

4. Par exemple la saisie d'un numéro dont le préfixe est 0800 suffit à reconnaître et déclencher une demande de service numéro vert.


automate. Les états de cet automate sont appelés des PIA (Point In Association). Par exemple, si sur l'activation d'un contexte PDP (Packet Data Protocol) on souhaite appliquer une tarification spéciale (carte prépayée par exemple), on va définir un auto-mate modélisant les différents é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 réseau intel-ligent. Il sera alors possible de faire interagir le SGSN (Serving GPRS Support Node) avec cette plate-forme de service à des fins de tarification et de contrôle du volume de données. Chaque état du nouvel automate correspondra à un PIA particulier. Cette nouvelle fonctionnalité est reprise dans CAMEL.

8.2.5. Exemples de services réseau intelligent

8.2.5.1. Le service du numéro vert

Le service numéro vert permet à un utilisateur de joindre gratuitement un numéro spécial, la facturation de la communication étant à la charge de l'appelé. Le service numéro vert ne peut être exécuté par la fonction de traitement d'appel de base du réseau téléphonique commuté car il met en œuvre une tarification inversée. L'exemple qui suit, décrit le service numéro vert dans le plan fonctionnel réparti (description du service en séquence de flux d'information INAP), en supposant que :

- l'appelant est directement rattaché à un commutateur capable de déclencher des demandes de service réseau intelligent ;

- les accès des utilisateurs A et B à leur commutateur sont des accès de base RNIS.

Dans ces conditions le déroulement du service numéro vert, décrit en figure 8.7, est le suivant :

1) l'utilisateur A décroche son poste et compose le numéro vert de B (typiquement en 0800). Un message SETUP est généré par le poste téléphonique de A ;

2) la fonction de traitement d'appel du commutateur de rattachement de A reçoit le message et, en analysant le préfixe du numéro vert de B, détecte une demande de service réseau intelligent. Dès lors, la CCF interrompt la procédure d'établissement d'appel et génère 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 numéro vert. Ce message contient, entre autres, le numéro vert associé à l'appelé B et l'identité du service à invoquer ;

4) la SCF reçoit le numéro vert de B. Ce numéro n'étant pas routable, la SCF va demander par interrogation d'une base de données (SDF), le numéro de téléphone


E.164 associé5 au numéro vert de B (par exemple le +33145817314) ; 5) la SDF retourne le numéro E. 164 à la SCF. La SCF envoie également à la SSF

un message RequestReportBCSMEvent lui demandant de remonter les événements de raccrochage et de décrochage 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 procédure d'établissement d'appel entre A et B. La CCF reprend son déroulement normal et établit l'appel entre A et B ; on utilise pour cela la signalisation téléphonique conventionnelle ISUP (ISDN User Part) entre commutateurs et Q931 à l'accès ;

7) l'appelé décroche et le commutateur de l'appelant en est informé par la réception du message ISUP ANM (Answer Message). La CCF remonte alors un EDP-N à la SSF. La SSF informe la SCF du décrochage via l'envoi d'un message INAP EventReportBCSM contenant le DP qui vient d'être levé (0_Answer).

8.2.5.2. Appel en attente

Le service d'appel en attente [Q1229] permet à un utilisateur de mettre en attente son correspondant courant et rend ainsi possible le basculement de la ligne vers un nouveau correspondant. Ce service met en œuvre plus de deux parties et requiert l'uti-lisation des fonctionnalités du jeu de capacité CS-2 du réseau intelligent. Le modèle CSCV et les interactions avec la plate-forme de services dans les phases stables de l'appel sont également nécessaires pour mettre à disposition ce type de service.

Nous supposerons, dans le cadre de cet exemple, qu'un appel est déjà é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 déroulement du service est alors le suivant (décrit 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 détecte que l'abonné est occupé et lève le DP T_Busy qui va servir à déclencher le service. La SSF envoie à la SCF un mes-sage initialDP servant à déclencher le service d'appel en attente. Le message initialDP contient l'identité de l'abonné A et l'état actuel du nouveau segment d'appel (état Ter-minating Setup) venant tout juste d'être créé dans un CSA. Le CSA est identifié par la référence CSAidl ;

2) la SCF demande à la SRF (ici un pont de conférence) de lui attribuer un numéro de téléphone temporaire servant à raccorder C et à le mettre en attente ; puis la SRF retourne le numéro de téléphone 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 (procédure non représentée sur le schéma) ;

5. Plan d'adressage international associé au réseau téléphonique public.

b igure 8.7. Le service numéro vert


4) la SCF demande au SSF de raccorder l'utilisateur A au SRF pour pouvoir lui diffuser une annonce vocale servant à l'avertir de l'appel de C. Le raccordement entre le SSF et le SRF peut se faire également via une procédure de signalisation de type RNIS;

5) la SCF positionne les EDP-N T_Disconnect et 0_Disconnect pour être en me-sure de détecter les déconnexions de l'utilisateur C au niveau du commutateur arrivé et au niveau de l'appel transféré 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 procédures, l'abonné C a un appel transféré sur le SRF (modélisé par l'état Transfer au niveau du SSF). Les abonnés A et B sont tou-jours en communication (modélisé par l'état Stable 2-party) et A reçoit une annonce l'avertissant de l'appel de C.

8.2.6. CAMEL et les réseaux intelligents

CAMEL reprend des standards réseau intelligent la description des services au niveau du plan fonctionnel réparti. Les autres plans ne sont pas spécifiés. En outre CAMEL utilise uniquement trois des quatre types de DP existants TDP-R, EDP-R et EDP-N. Les TDP CAMEL sont armés dès réception des différentes marques CAMEL6

au niveau du MSC, du GMSC (Gateway Mobile services Switching Center) ou du VMSC ( Visited Mobile services Switching Center).

8.3. Présentation de CAMEL

8.3.1. Différentes phases de CAMEL

La standardisation de CAMEL a connu quatre phases. Les deux premières phases ont été spécifiées dans le cadre de la normalisation GSM ; les deux dernières phases sont dans le cadre du 3GPP et concernent à la fois GSM-GPRS et l'UMTS.

8.3.1.1. Phases! et 2

La première phase de CAMEL, dite CAMEL Phase 1, a été normalisée en 1997 pour la phase 2+ (release 96) des normes GSM. Ses fonctionnalités sont très réduites par rapport au réseau intelligent du réseau téléphonique. La mise au point de l'inter-face SSF-SCF dans le cas de l'itinérance a constitué la principale difficulté rencontrée. C'est aussi son principal intérêt : il est possible, pour l'utilisateur, de garder les mêmes services et la même façon de les utiliser quand il va à l'étranger.

6. Voir paragraphe 8.3.3.


Figure 8.8. Le déroulement du service d'appel en attente, extrait de ITU-T Q1229

CAMEL Phase 2 est venu compléter la première phase en apportant tous les ser-vices réseaux intelligents pouvant être utilisés en CS-1. En particulier, les connexions à des ressources vocales ont été rendues possibles. CAMEL Phase 2 a été défini 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 téléphoniques. CAMEL Phase 3, définie pour la release 99 du GSM et pour les releases 99 et R4 de l'UMTS, élargit de façon très importante la portée de CAMEL. Il est possible de déclencher des services dans le domaine paquet (en UMTS ou en GPRS) mais également lors


de l'envoi de SMS {Short Message Service) ou d'utilisation d'USSD (Unstructured Supplementary Service Data).

Le déclenchement des services CAMEL dans le domaine paquet se fait depuis le SGSN. Cette nouvelle fonctionnalité rend possible l'activation des services de tarifi-cation de type carte prépayée pour des services de transports de données. Les services CAMEL liés au domaine paquet peuvent être déclenchés lors de l'activation d'un contexte PDP ou lors de l'attachement du terminal au réseau.

Les services CAMEL déclenchés lors de l'envoi d'un SMS sont, par exemple, utiles pour permettre à un utilisateur de vérifier par SMS son crédit restant sur une carte prépayée et pour la confirmation de réception de messages courts.

La fonctionnalité USSD ou service supplémentaire non structuré permet l'ouver-ture de sessions de données à bas débit. L'USSD définit un protocole permettant un échange de transactions génériques. Le couplage avec une plate-forme de service CA-MEL rend possible l'interaction entre un utilisateur et une logique de service CAMEL et permet donc d'offrir des services en évitant de passer par une ressource de télé-communications spécialisée, par exemple un serveur vocal chargé de collecter des séquences DTMF tapées par un utilisateur. Cela constitue un exemple de service RI déclenché en dehors d'un appel. Il s'agit d'un mécanisme OCCUUI selon la termi-nologie définie en CS-2, c'est-à-dire sans relation avec un appel. Le déclenchement du service se fait lors de la réception de commandes USSD en provenance du mobile systématiquement au niveau du HLR (Home Location Register).

Le déclenchement de services CAMEL depuis une instance de service supplé-mentaire existante était possible en phase 2 mais seulement pour un nombre limité de services supplémentaires. CAMEL phase 3 accroît l'ensemble des services sup-plémentaires concernés : renvoi d'appel, conférence d'appel, transfert d'appels. Le déclenchement s'opère systématiquement depuis le MSC

L'intérêt de coupler CAMEL et les USSD ou les services supplémentaires est le même que pour les services téléphoniques : l'utilisateur garde les mêmes services quand il va à l'étranger; il peut, par exemple, activer le renvoi d'appel hors de son réseau nominal.

8.3.1.3. Phase 4 La phase 4 de CAMEL est en cours de normalisation (release 5 et ultérieures).

Elle s'inspire fortement du CS-2. Il est possible de déclencher des services depuis les phases stables d'un appel. Cette fonction permet entre autres de taper des séquences de touches DTMF pour interagir avec une instance de service existante7. CAMEL Phase

7. Notamment pour les services de conférence.


4 permet le routage optimal pour les appels du domaine circuit établis de mobile à mo-bile. Il supporte également des appels multipartite et permet de créer un nouvel appel depuis une instance de service CAMEL ; l'appel créé n'est pas nécessairement lié à un appel existant8. Cette fonction est utilisée pour les services de mise en attente ou de conférence. Par ailleurs, CAMEL phase 4 permet d'invoquer des services multimédia basés sur la technologie IP9.

8.3.1.4. Méthodologie de spécification

Chaque phase de CAMEL est développée selon une méthodologie en trois étapes10. La première étape décrit les services offerts par la nouvelle phase CAMEL. La deuxième étape traite essentiellement de l'architecture fonctionnelle de CAMEL, des modèles d'appel et des marques CAMEL11. La troisième étape spécifie le protocole CAP. Toute nouvelle phase CAMEL doit supporter tous les services des phases précédentes. En conséquence nous ne décrirons 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 entités fonctionnelles définies dans le réseau intelligent en les déclinant dans le domaine circuit et dans le domaine paquet du réseau cœur de l'UMTS.

La fonction de traitement d'appel gsmCCF (GSM Call Control Function) permet de contrôler les appels et les connexions associées à un appel mobile. Elle est typi-quement située dans le MSC et jour un rôle analogue à la CCF du réseau intelligent. La fonction gsmSSF (GSM Service Switching Function) permet de reconnaître les de-mandes de service CAMEL, déclenche les services CAMEL et apporte des fonctions analogues à la SSF du réseau intelligent. Elle est également située 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 héberge la logique de service CAMEL et joue donc un rôle similaire à la SCF du réseau intelligent. La gsmSRF (GSM Service Resource Function) est une ressource de télécommunications spécialisée permettant à l'utilisateur d'interagir avec le service choisi (par exemple serveur vocal). Cette fonction joue le même rôle que la SRF du réseau intelligent.

8. Utilisation des capacités CS-2 du réseau intelligent. 9. Ce qui rejoint les objectifs du CS-4 du réseau intelligent. 10. Les étapes sont appelées stage dans la nomenclature UMTS. 11. Voir paragraphe 8.3.3.


RNC i SGSN GGSN

Domaine paquet

i Entités fonctionnelles CAMEL

Figure 8.9. Architecture fonctionnelle de CAMEL

Le domaine paquet comprend l'entité fonctionnelle gprsSSF (GPRS Service Swit-ching Function). Elle est située sur le SGSN et permet de déclencher 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 données qui déterminent les conditions dans lesquelles le service CAMEL peut être déclenché pour un abonné donné. Elles sont téléchargées depuis la HLR dans le VLR ( Visitor Location Register) ou le SGSN lors des procédures de mise à jour de localisation et d'attachement. Les marques CAMEL permettent de déterminer si un service CAMEL doit être déclenché et de retrouver la localisation du serveur applicatif mettant à disposition le service demandé. Les principales marques CAMEL sont regroupées dans le tableau 8.4. On peut constater qu'il y a peu de différences entre la phase 3 et la phase 4.


CSI Critère de déclenchement du service CAMEL Lieu de stockage en

dehors HLR du ré-seau nominal

D-CSI Liste de dix numéros personnalisés permettant de déclencher des services CAMEL VLR du réseau vi-

sité, GMSC lors d'un appel entrant

GPRS-CSI Ouverture d'une session GPRS (General Packet Radio Service) ou lors de l'activation d'un nou-veau contexte PDP

SGSN

M-CSI Changement de zone de localisation VLR du réseau visité

O-CSI Appel départ depuis un MSC du réseau visité, appel entrant parvenu à un GMSC, ou appel renvoyé au niveau d'un MSC du réseau visité ou d'un GMSC

VLR du réseau vi-sité, GMSC

MO-SMS-CSI12

envoi d'un message court VLR du réseau vi-sité, SGSN

MT-SMS-CSI (phase 4)

réception d'un message court VLR du réseau vi-sité, SGSN

SS-CSI Activation d'un service supplémentaire VLR du réseau visité

T-CSI Appel arrivée depuis un GMSC GMSC

U-CSI Réception au niveau du HLR d'une commande USSD (marque spécifique à un abonné CAMEL)

Tableau 8.4. Quelques exemples de marques CAMEL phase 3 et phase 4 d'après 3GPP 22.078 v5.7.0

Une marque CAMEL contient toujours les éléments d'informations suivants : - TDP à l'origine du déclenchement du service CAMEL ; - adresse de la gsmSCF fournissant le service demandé ; - identité du service demandé (Service Key dans la terminologie CAMEL) ; - comportement que doivent adopter les gsmSSF ou gprsSSF si le dialogue CAP

entamé avec la gsmSCF venait à échouer (Default Call Handling dans la terminolo-gie CAMEL). Ce paramètre peut prendre les valeurs Release (arrêter l'exécution du service) ou Continue (continuer le service) ;

- le paramètre Capability Handling indique la version du protocole CAP qui peut être utilisée dans le cadre du service demandé ;

- les critères de déclenchement du service CAMEL (par exemple préfixe de nu-méro composé) ;

- l'état de la marque (active/inactive).


8.4. CAMEL et le domaine circuit

8.4.1. Les automates CAMEL phase 3 du domaine circuit

8.4.1.1. L'automate départ OBCSM

L'automate départ ou OBCSM est décrit en figure 8.10. On y retrouve les phases classiques de tout appel : collecte du numéro composé par l'usager, analyse de ce numéro pour déterminer ensuite le routage et mise en relation. Suivant le formalisme indiqué dans la figure 8.6, les petits rectangles représentent les points de détection, c'est-à-dire tous les endroits où le traitement peut être suspendu pour faire appel à un service RI ou pour faire une notification.

De façon détaillée, les états sont les suivants : - l'état 0_Null&Authorize, 0_Origination_attempt, 0_Collect_information, cor-

respond à un état neutre : aucun service n'est déclenché, le réseau est en train de déter-miner si un utilisateur a le droit de lancer le service qu'il demande, les données saisies par l'utilisateur sont en cours de collecte de manière à déterminer s'il faut déclencher un service CAMEL ;

- Analyse_information : les informations collectées dans l'état précédent sont ana-lysées pour procéder au routage de l'appel ;

- Routing and Alerting : dans cet état l'appel est routé jusqu'à l'appelé qui est informé de l'arrivée 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 antérieures de l'ap-

pel et l'automate place l'appel dans cet état avant de le libérer.

Les points de déclenchement définis pour l'automate OBCSM sont les suivants : - Collected_Info permet de déclencher un service CAMEL à l'issue de la saisie

d'un numéro par l'appelant ; - Analyzed_Info permet de déclencher un service CAMEL lorsque le numéro

composé par l'appelant a été traduit par la fonction de traitement d 'appel1 3 ; - 0_Answer permet de déclencher un service CAMEL dès que le réseau averti

l'appelant (généralement via un message ISUP de type ANM) que l'appelé a décro-ché ;

13. La traduction est opérée par la fonction de traitement d'appel. Elle détermine à partir d'un numéro de téléphone, un acheminement pour l'appel en cours.


- Route_Select_Failure permet de déclencher un service CAMEL s'il n'est pas possible de trouver une voie d'acheminement pour l'appel ;

- 0_Busy permet de déclencher un service CAMEL lorsque l'appelé est occupé ; - 0_No_Answer permet de déclencher un service CAMEL si l'appelé ne répond

pas à l'appel entrant ; - 0_Routing_and_alerting_failure permet de déclencher un service CAMEL si

l'acheminement de l'appel ou l'alerte de l'appelé échouent.

Le lecteur peut constater que les points de déclenchement vont bien au-delà de la simple analyse du numéro demandé. Cela permet d'envisager d'offrir un grand nombre de services à partir du concept de réseau intelligent.

8.4.1.2. L'automate arrivée TBCSM

L'automate arrivée TBCSM, décrit en figure 8.11, passe par les états suivants : - T_Null : Le service n'est pas encore déclenché ; - l'état Terminating_Call_Handling correspond à un appel qui arrive; soit le ré-

seau est en train de vérifier qu'il est possible de contacter la personne appelée ; soit le terminal de l'appelé est alerté de l'arrivée de l'appel ;

- T_Active : lorsque l'appelé décroche, l'automate passe dans cet état et l'appel devient actif ;

- T_Exception : une erreur est survenue dans l'une des phases antérieures de l'ap-pel. L'appel est placé dans cet état avant libération.

Les points de déclenchement définis pour l'automate TBCSM sont les suivants : - Terminating_Attempt_Authorized permet de déclencher un service CAMEL

juste après que le fonction de traitement ait déterminé que l'appelé est autorisé à rece-voir l'appel ;

-T_Busy permet de déclencher un service CAMEL si l'appelé est occupé (par exemple renvoi d'appel sur occupation) ;

- T_No_Answer permet de déclencher un service CAMEL si l'appelé ne répond pas à l'appel entrant (par exemple renvoi d'appel sur non-réponse) ;

- T_Call_Handling_failure permet de déclencher un service CAMEL dans le cas où l'établissement de l'appel arrivée échoue ;

- T_Answer permet de déclencher un service CAMEL si l'appelé répond à l'appel (il décroche) ;

- T_active_failure permet de déclencher un service CAMEL si le service en cours d'exécution subit une erreur ;

- T_Disconnect permet de déclencher un service CAMEL à l'issue du raccrochage d'un utilisateur;


O.Disconnect G a c t i v e f a i l u r e

Figure 8.10. Automate 0_BCSM CAMEL phase 3, d'après 23.078 v3.13.0

- T_Abandon permet de déclencher un service CAMEL dans le cas où l'appelé n'est pas joignable.

8.4.2. Evolution des automates en phase 4

L'automate départ de CAMEL phase 4, représenté en figure 8.12, modifie celui de CAMEL phase 3 en séparant l'état Routing de l'état Alerting. Cette distinction est nécessaire dans le mesure où l'on souhaite déclencher des requêtes de service depuis


Figure 8.11. Automate TBCSM CAMEL Phase 3, d'après 23.078 v3.13.0

toutes les phases stables de l'appel. En outre, trois nouveaux points de déclenchement ont été ajoutés à l'automate départ CAMEL phase 3 :

- 0_Term_Seize permet de déclencher un service CAMEL lorsque le central de l'appelé a acquitté la demande d'établissement d'appel et que toutes les ressources réseau sont réservées 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 déjà établi ;

- 0_Change_Of_Position sert à déclencher un service CAMEL à chaque change-ment de zone de localisation d'un abonné.

L'automate arrivée de la phase 4, représenté 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 séparation est nécessaire pour pouvoir déclencher des services alors que l'appelé est déjà contacté mais qu'il n'a pas


0_Mid_call 0_Change_Of_Position

Figure 8.12. Automate O-BCSM CAMEL phase 4 d'après 3GPP 23.078 v5.0.0


T_Mid_Call T_Change_Of_Position

Figure 8.13. Automate TBCSM CAMEL phase 4 d'après 3GPP v5.0.0

encore décroché (phase stable de l'appel). Le point de déclenchement T_Mid_Call a été ajouté pour permettre l'interaction entre un utilisateur et une plate-forme de ser-vices lorsque l'appel est déjà établi. Le point de déclenchement 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 à déclen-cher des services réseau intelligent indépendamment d'un appel téléphonique. C'est toujours le cas pour des services CAMEL déclenchés depuis le domaine paquet ou le


réseau GPRS. Les standards CAMEL définissent deux situations où un service CA-MEL peut être déclenché :

- lors de l'attachement d'un terminal au domaine paquet (par exemple, pour vé-rifier qu'un utilisateur prépayé dispose encore de suffisamment de crédit pour utiliser les services du domaine paquet) ;

- lors de l'activation d'un contexte PDP (par exemple pour vérifier qu'un utilisa-teur prépayé dispose de suffisamment de crédit pour utiliser le service demandé lors de l'activation de contexte PDP).

Dans tous les cas, les services CAMEL de type paquet sont déclenchés depuis le SGSN.

8.5.1. Automate d'attachement-détachement GPRS

La figure 8.14 décrit l'automate associé au déclenchement d'un service CAMEL lors de l'attachement ou du détachement d'un utilisateur mobile au domaine paquet. Trois états sont définis dans cet automate :

- l'utilisateur mobile n'est pas attaché au domaine paquet du réseau ; - l'utilisateur mobile est attaché au domaine paquet du réseau ; - la situation d'exception (une erreur est survenue lors de l'attachement ou du

détachement du mobile) ;

Les points de déclenchements permettent de lancer un service CAMEL lors de l'at-tachement au domaine paquet (DP Attach request), lors du détachement 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 décrit un exemple de service CAMEL déclenché lors de l'attache-ment d'un utilisateur mobile au domaine paquet. Il s'agit de vérifier qu'un utilisateur de carte prépayée a suffisamment de crédit pour utiliser les services du domaine pa-quet. La vérification du montant disponible sur la carte prépayée se déroule selon les étapes suivantes :

1) l'utilisateur déclenche la procédure d'attachement au domaine paquet via les procédures GMM (GPRS Moblility Management). Cette procédure est initiée par l'en-voi d'un message GMM Attach Request ;

2) nous supposons à ce stade que l'utilisateur s'est correctement authentifié auprès du réseau. La HLR va alors télécharger le profil de l'abonné dans le SGSN. Ce profil contient, entre autres, les marques CAMEL associés aux services déclenchables par l'utilisateur;


Figure 8.14. Automate attach-detach GPRS CAMEL phase 3, d'après 23.078 v3.13.0

3) en analysant les marques, la gprsSSF s'aperçoit de la présence de la marque GPRS-CSI (GPRS CAMEL Subscription Information) et déclenche l'envoi d'une re-quêté CAP à destination de la gsmSCF. Le message CAP Initial DP GPRS contient le DP ayant déclenché l'envoi de cette requête (DP Attach) ;

4) La gsmSCF vérifie si l'utilisateur a suffisamment de crédit et, dans l'affirmative, envoie à la gprsSSF une séquence de commandes CAP indiquant une liste d'événe-ments à remonter et l'état du crédit sur la carte (volume de données autorisé ou temps de connexion autorisé) ;

8.5.3. Automate de contexte

La figure 8.16 décrit l'automate associé au déclenchement 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 réseau et le mobile ; - PDP_Context_Setup : dans cet état, le mobile a sollicité l'établissement d'un

contexte PDP, mais celui-ci n'est pas encore établi ; - PDP_Context_Established : le contexte PDP est établi entre le mobile et le ré-

seau ;


Mobile SGSN GGSN SCF H L K

Figure 8.15. Vérification du crédit d'une carte prépayée 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 création d'un contexte PDP ou lorsqu'un contexte PDP était actif ;

Les points de déclenchement permettant d'activer un service CAMEL lors d'une procédure liée à un contexte PDP sont les suivants :

- PDP Context Setup Establishment : permet de déclencher une interaction CAP dès que l'utilisateur a demandé l'activation d'un contexte PDP et avant que le réseau ne cherche à établir un contexte PDP ;

- PDP Context Setup Ack : permet de déclencher une interaction CAP après que le réseau ait commencé à établir un PDP contexte ;

- Change Of position Context : permet de déclencher une interaction CAP lors d'un changement de zone routage ;

- PDP Context Disconnection : permet de déclencher une interaction CAP lors de la désactivation d'un contexte PDP.


Figure 8.16. Automate de contexte GPRS CAMEL phase 3, d'après 23.078 v3.13.0

8.5.4. Exemple de service sur activation d'un contexte

La figure 8.17 donne un exemple de déclenchement de service CAMEL lors de l'activation d'un contexte PDP. Il s'agit d'un utilisateur accédant à un service pré-payé. Le réseau va préalablement vérifier que l'utilisateur dispose de suffisamment de crédit avant de lui donner l'accès au réseau. La procédure CAP permettant d'activer le service de données par carte prépayée se déroule de la manière suivante :

1) l'activation d'un contexte PDP est déclenchée via les procédures SM (Session Management) et est initiée par le message SM Activate PDP Context Request ;

2) l'utilisateur étant déjà attaché au réseau, le SGSN contient déjà la marque GPRS-CSI et la gprsSSF va déclencher une interaction CAP avec la gsmSCF.

i


3) la gsmSCF envoie un certain nombre d'informations de tarification au SGSN ; 4) un tunnel GTP (GPRS Tuneling Protocol) est établi entre le SGSN et le GGSN

(Gateway GPRS Support Node) ; 5) La gprsSSF informe la gsmSCF de la fin de l'établissement du contexte PDP

et du début de la session GPRS (à des fins de tarification). La gsmSCF informe la gprsSSF qu'il a pris acte du début de la session ;

6) Le réseau informe le mobile que le PDP contexte est actif. Le mobile peut com-mencer à envoyer des données.

8.6. CAMEL et les échanges de SMS

8.6.1. CAMEL phase 3 et les envois de SMS

CAMEL phase 3 permet de déclencher des services CAMEL lors de l'envoi de SMS par un abonné. Le déclenchement du service se fait au niveau du MSC pour le domaine circuit14 ou au niveau du SGSN15 pour le domaine paquet.

L'automate décrivant les interactions possibles entre l'envoi d'un SMS et un ser-vice CAMEL est illustré figure en 8.18. Cet automate est commun au SGSN et au MSC.

Il est possible de déclencher une interaction CAP lorsque l'utilisateur sollicite l'envoi d'un SMS pour vérifier son crédit (DP SMS_Collected_Info). Une interaction CAP peut également être déclenchée une fois que le SMS a été envoyé. La dernière possibilité d'activation de requête CAP correspond au cas où l'envoi de SMS aurait échoué.

L'exemple décrit en figure 8.19 montre le cas d'un utilisateur disposant d'une carte prépayée pour les SMS. La procédure CAP permettant de vérifier que l'utilisateur dispose de suffisamment de crédit pour envoyer son message court se déroule de la manière suivante :

1) l'utilisateur sollicite l'envoi de son message court ; 2) la présence de la marque SMS-CSI dans le SGSN, téléchargée lors de la procé-

dure d'attachement de l'utilisateur au domaine paquet, permet de déclencher l'envoi d'un message CAP vers la gsmSCF. Ce message informe la gsmSCF que l'abonné prépayé considéré cherche à envoyer un mini message ;

3) la gsmSCF vérifie le crédit de l'abonné et autorise l'envoi du message court en répondant avec le message Continue SMS. La gsmSCF demande également à la

14. Dans ce cas, c'est la gsmSSF qui déclenche le service. 15. Dans ce cas, c'est la gprsSSF qui déclenche le service.


Mobile SGSN GGSN SCF

Figure 8.17. Activation d'un contexte PDP dans le cadre d'un service de carte prépayée pour le transport de données dans le domaine paquet

gprsSSF de l'informer dès que le message court a été remis au destinataire (demande de remontée du DP O-SMS-Submitted) ;

4) le SGSN envoie le message vers le centre de messagerie ;

5) un accusé de réception est délivré 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 crédit de l'utilisateur.


Figure 8.18. Automate SMS départ d'après 3GPP 23.078 v3.13.0

8.6.2. CAMEL Phase 4 et la réception de SMS

CAMEL phase 4 ajoute par ailleurs la possibilité de déclencher un service lors de la réception d'un SMS. L'automate décrivant les points d'interaction possibles entre la réception d'un SMS et CAMEL sont décrits par l'automate de la figure 8.20.

8.7. CAMEL phase 4 et le sous-système IP multimédia

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 multimédia sur l'Internet. Une session est une association entre plusieurs terminaux souhaitant com-muniquer entre eux via un ou plusieurs médias. Elle peut donc se matérialiser sous des formes aussi diverses qu'une conférence vidéo multicast ou encore un appel voix sur IP. SIP peut être vu comme un protocole d'établissement d'appels sur IP. Néanmoins il ne spécifie ni la nature ni les attributs des médias associés à la session. Ces informa-tions sont décrites au moyen de la syntaxe SDP (Session Description Protocol), qui est encapsulée dans les messages SIP. La description et la négociation des capacités de chaque terminal est donc faite à travers cette syntaxe. SIP a toutefois la possibilité d'utiliser une autre syntaxe que SDP.


MS SGSN SCF SMS-IWMSC

Figure 8.19. Vérification du crédit d'une carte prépayée 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 réponses. Le formats des en-têtes des messages SIP proviennent en grande partie de SMTP16.

Les messages SIP peuvent être de type requête ou de type réponse. Les premières requêtes SIP 2.0 à avoir été définies sont les suivantes :

16. En-têtes FROM, TO.


Figure 8.20. Automate SMS arrivée d'après 3GPP 23.078 v5.0.0

- le message INVITE permet à un client d'initier une conférence multimédia ou de demander son rattachement à une conférence multimédia existante. Ce message initie la négociation des paramètres associés à une session tels que le port TCP (Transmis-sion Control Protocol) ou UDP (User Datagram Protocol) qui va recevoir les flux multimédia ou le type de CODEC utilisé (via la syntaxe SDP) ;

- le message ACK est envoyé pour acquitter le bon déroulement 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 éléments d'information décrivant les paramètres des flux multimédia associés à la session ;

- le message OPTIONS permet à des serveurs SIP de s'échanger des informations sur les capacités 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 libère la session courante.


Progressivement d'autres types de requêtes ont été ajoutés au protocole, comme par exemple les requêtes NOTIFY et SUBSCRIBE qui sont utilisées pour les services de présence. Elles permettent à un client de demander à être informé de l'occurrence de certains événements (méthode SUBSCRIBE) et au serveur d'informer le client de l'occurrence des ces événements (méthode NOTIFY). La présence 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 présence, par exemple messagerie instantanée, appels de groupes /dots).

Les réponses SIP 2.0 maintiennent le client informé sur l'état d'une session en cours. Elles sont exprimées sous la forme d'un nombre de 100 à 699, le premier chiffre indiquant le type de réponse :

- toutes les réponses dont le code commence par 1 informent un client sur l'état de sa requête en cours ;

- les réponses de type 2 sont envoyées à un client pour l'informer que sa requête a été convenablement prise en compte ;

- les réponses de type 3 informent le client que l'appelé a changé de terminal et qu'il est nécessaire d'effectuer des opérations supplémentaires pour mener à bien la requête ;

- les réponses de type 4 signalent une erreur dans le traitement d'une requête SIP. La requête présentée a par exemple une syntaxe incorrecte ;

- les réponses de type 5 informent le client que le serveur SIP demandé ne répond plus;

- les réponses de type 6 signalent que la requête SIP n'a pu être traitée par aucun serveur.

Hormis les types de la requête et de la réponse, les messages SIP contiennent éga-lement un en-tête contenant plusieurs éléments d'information précisant par exemple la provenance du messages (en-tête FROM), l'identité de la session (en-tête Call ID) ou encore le destinataire du message SIP (en-tête TO). SIP 2.0 prévoit également un emplacement optionnel destiné à contenir la description d'une session. Les sessions sont décrites en utilisant la syntaxe SDP.

8.7.2. SIP et le sous-système IP multimédia

La release 5 de l'UMTS a introduit la possibilité d'accéder à des services Internet multimédia depuis un mobile. L'invocation de ces services se fait via le protocole SIP. Les serveurs SIP sollicités par le mobile se trouvent regroupés dans le sous-système IP multimédia. Ils sont accessibles en passant par le domaine paquet du réseau (il est nécessaire d'établir au préalable un contexte PDP avec le domaine paquet) et peuvent également être reliés à l'Internet.


Figure 8.21. Le sous système IP multimédia

Trois types de serveurs ont été définis (voir figure 8.21) : - Les P-CSCF (Proxy Call Session Control Function) jouent un rôle analogue au

VLR du domaine circuit. Le terminal contacte le P-CSCF lors des procédures d'enre-gistrement et d'établissement de session. Le P-CSCF redirige toutes les requêtes SIP vers le S-CSCF (Serving Call Session Control Function) (situé dans le réseau d'ori-gine) ;

- Les I-CSCF (Interrogating Call Session Control Function) ont une fonction si-milaire au GMSC du domaine circuit. Ils interrogent le HSS (Home Subsriber Server) du réseau nominal pour retrouver l'emplacement du S-CSCF ;

- Les S-CSCF contrôlent le déroulement d'une session, même lorsque l'utilisa-teur est en roaming. Ils sont également en charge de déclencher 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 contactée via le protocole SIP, une interface CAMEL ou encore une interface OSA.

D'autres entités fonctionnelles ont été introduites pour assurer le bon fonction-nement du système IMS (IP multimédia Subsystem). Le HSS est une généralisation


de la HLR utilisable dans le domaine circuit, dans le domaine paquet et dans l'IMS. Des passerelles de transcodage MGW (Media Gateway), non représentées sur la fi-gure 8.21, permettent de gérer le passage d'un réseau IP à d'autres types de réseau (par exemple pour joindre un réseau téléphonique). Elle sont pilotées à distance par une entité externe MGCF (Media Gateway Control Function) via le protocole H.248. D'autres entités comme la MRF {Media Resource Function) mettent à dispositon des services comme la conférence multimédia).

Dans tous les cas, le service IMS et son application associée, sont exécutés dans le réseau nominal. Cela permet à l'utilisateur de pouvoir bénéficier exactement du même service même cas de déplacement à l'étranger (pas de problème de paramétrage, conservation de l'environnement utilisateur...).

8.7.3. CAMEL phase 4 et le sous-système IP multimédia

CAMEL phase 4 permet de déclencher un service CAMEL depuis le sous-système IP multimédia. L'entité fonctionnelle IM-SSF (IP Multimedia-Service Switching Func-tion) joue un rôle similaire à la gsmSSF et à la gprsSSF. Elle est placé sur un équi-pement de l'IMS et permet d'envisager des services prépayés qui seraient fournis sur l'IMS. Elle est relation avec la S-CSCF qui joue un rôle analogue à la fonction de traitement d'appel (gsmCCF). Le déclenchement de services CAMEL depuis l'IMS est détecté par la présence d'une nouvelle marque CAMEL, IM-CSI (IP Multimedia Camel Subscription Information), qui est téléchargée depuis le HSS dans la IM-SSF via la S-CSCF.

8.8. Présentation d'OSA

8.8.1. Introduction

La norme OSA a été introduite pour faciliter la réutilisation et le développement de services se basant sur les fonctionnalités d'un réseau radio mobile. OSA s'est beau-coup inspiré de travaux menés dans le cadre du consortium Parlay. L'objectif de Parlay est de rendre autant que possible le développement des applications indépendant des réseaux les supportant. Les applications et les couches réseaux sont séparées par une nouvelle couche dite intergicielle17. Les applications n'accèdent plus directement aux fonctions offertes par le réseau18, mais s'adressent à l'intergiciel qui fait office d'in-termédiaire. Les fonctions réseau sont maintenant invocables par les applications à

17. Middleware. 18. Fonctions liées à la localisation, ou de contrôle d'appels, ou de contrôle de ressources de télécommunications.


travers des interfaces standardisées au niveau de l'intergiciel, appelées API (Applica-tion Programming Interface).

OSA définit donc une architecture qui permet aux opérateurs et aux fournisseurs de service tiers d'utiliser les fonctions apportées par un réseau au travers d'une API standardisée. Les fonctions ainsi apportées sont développées au sein de serveurs ap-plicatifs appelés SCS (Service Création Server). Les SCS cachent aux applications la complexité du réseau radio mobile sous jacent en établissant la correspondance entre les services apportées par les API au niveau applicatif et les protocoles de signalisa-tion (MAP (Mobile Application Part), CAP, ISUP...) utilisés au niveau du réseau. La figure 8.22 apporte une vue d'ensemble de l'architecture d'OSA. Trois niveaux sont présents :

- le premier niveau correspond aux applications qui sont proposées aux utilisateurs finals. Les applications sont placées sur des serveurs et peuvent être développées dans n'importe quel langage ;

- le deuxième niveau regroupe les SCS dont les fonctions sont accessibles à travers les API OSA. Un SCS particulier appeler Framework apporte plusieurs mécanismes de bases préalables à l'invocation de tout service :

- services d'authentification servant à vérifier qu'une application a bien accès au réseau considéré,

- service de découverte permettant à une application, une fois l'authentification réussit, d'obtenir une liste des services réseau accessibles depuis les SCS ;

- le troisième niveau regroupe les diverses technologies réseau utilisées par les SCS.

Les services proposés par les différents SCS OSA sont spécifiés comme un en-semble d'interfaces contenant les méthodes invocables par les applications. Les inter-faces se subdivisent en deux familles. La première famille d'interfaces permet d'accé-der au SCS framework. La deuxième famille d'interfaces permet d'utiliser les services réseaux offerts par certains SCS.

8.8.2. Services apportés par OSA

La séparation entre la logique de service placée dans les applications et les fonc-tions réseau accessibles depuis les SCS facilite le développement de nouvelles appli-cations et permet de mettre à disposition un même service sur différents réseaux. Bien que les standards introduisent un certain nombre de services cibles pour illustrer l'uti-lisation de OSA, il n'entre pas dans le cadre de la norme de standardiser toutes les offres de services.


API interne OSA

Figure 8.22. Vue d'ensemble de OSA, d'après 23.127, page 10

8.8.3. Typologie des interface OSA

8.8.3.1. Interfaces et services associés au S( \SJraniework

Les familles d'interfaces permettant d'accéder au serveur Framework sont les sui-vantes :

l'interface d'authentilication permet aux applications et au SCS Framework de s'authentifier mutuellement19. La phase d'authentifieation est préalable à l'utilisation de tout autre API OSA;

- l'interface d'autorisation permet à une application de déterminer l'ensemble des API qu'elle a le droit d'invoquer;

- F interface de découverte permet à une application de récupérer l'ensemble des fonctions mises à disposition par une API :

19. Utilisée notamment entre les Fournisseurs de service tiers et les opérateurs.


- l ' interface d'activation et de notifications d 'événements permet à une applica-tion de demander au réseau d 'ê t re averti de l 'occurrence de certains événements. Par exemple, dans le cas du service de filtrage d 'appels entrants, il s 'agit de lancer l'ins-tance de service en lui passant le numéro de l 'appelant.

8.8.3.2. Interface associées aux SCS réseau

Les API associées aux SCS réseaux permettent d ' invoquer les fonctions suivantes :

- déclenchement d 'un appel téléphonique depuis le réseau ;

- interaction avec l 'utilisateur final pour la saisie d ' information ;

- contrôle de session de données dans le domaine paquet (par exemple, autoriser un utilisateur à établir un nouveau contexte PDP) ;

- localisation de l 'ut i l isateur;

- état du terminal de l 'utilisateur et notification à l 'application lorsque le terminal change d'état ;

- récupération des caractéristiques 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( îPI \ Service Requirement l'or the Open Services Access (OSA) Stage I. Rapport n TS 22.127. 3GPP, 1999.

| 3CJP 9 9 D | 3 G P P , Virtual Home Environment (VHE) / Open Service Access (OSA) ; Stage 2.

Rapport n TS 2 3 . 1 2 7 , 3 G P P , 1999 .

|3GP 011 3GPP, Service aspects ; Services and Service Capabilities spécification (Release 99), Rapport n°TS 22.105, 3GPP. 2001.

|3GP 02a 1 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) - stage 2 (Release 4), Rapport n°TS 23.078, 3GPP, 2002.

|3GP ()2b| 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) - stage 2 (Release 5), Rapport n°TS 23.078, 3GPP, 2002.

|3GP ()2c| 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) - stage 2 (Release 99), Rapport n°TS 23.078, 3GPP, 2002.

|3GP ()2d| 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) ; CAMEL application Part (CAP) spécification (Release 4), Rapport n°TS 29.078, 3GPP, 2002.

|3GP 02e| 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) : CAMEL application Part (CAP) spécification (Release 5), Rapport n°TS 29.078. 3GPP, 2002.


[3GP 02f] 3GPP. Customized Applications for Mobile Enhanced Mogic (CAMEL) ; CAMEL application Part (CAP) spécification (Release 99), Rapport n°TS 29.078, 3GPP, 2002.

f3GP 02gj 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) ; Service description stage 1 (Release 4), Rapport n°TS 22.078 v4.5.0, 3GPP, 2002.

[3GP 02h] 3GPP, Customized Applications for Mobile Enhanced Mogic (CAMEL) ; Service description stage 1 (Release 99), Rapport n°TS 22.078, 3GPP, 2002.

[ITU 99al ITU-T, Description du plan fonctionnel réparti du jeu de capacités CS-2 du réseau intelligent, Rapport n°Q.1224, 1999.

[ITU 99b 1 ITU-T, Guide utilisateur du réseau intelligent. Rapport n°Q.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.

|SCH 03] SCHULZRINNE H., CASNER S., FREDERICK R., JACOBSON V., RFC 3550 RTP : A Transport Protocol for Real-Time Applications, Rapport, IETF, 2003.

[STR 011 STRETCH R. M., « The OSA API and other related issues ». BT Technology Journal, vol. 1, 2001.

I

Chapitre 9

Terminal mobile et environnements d'applications

9.1. Introduction

Alors que la téléphonie (voix) et les systèmes de messageries (vocales ou texte) semblent des techniques maîtrisées et standard, la différenciation entre opérateurs repose maintenant sur le prix des forfaits de communication et l'innovation en matière 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 téléphones mobiles et, dans un premier temps, de nombreuses sociétés ont développé leur plate-forme propriétaire.

Une part significative des applications est exécutée en local sur l'équipement de l'utilisateur. Le marché des terminaux mobiles étant très ouvert, différents groupes de standardisation se penchent vers la définition d'environnement d'application permettant de télécharger et d'exécuter des applications indépendamment du terminal utilisé et du réseau visité. Ces environnements d'exécution pour les applications doivent permettre l'accès aux ressources du terminal, qui sont pour une part des ressources communes à tous les terminaux et pour une autre part des ressources utilisant les particularités spécifiques à un terminal donné. On peut se demander dans ces conditions comment un standard peut s'imposer.

Chapitre rédigé par Paul JOLIVET.


Par ailleurs, la mobilité et l'itinérance (roaming) apportent leurs aspects spécifiques aux applications, comme par exemple la possibilité de s'exécuter dans les mêmes conditions quelle que soit la localisation de l'utilisateur (et le réseau utilisé, à l'étranger par exemple) : c'est l'environnement local virtuel (VHE, Virtual Home Environment). Mieux encore, la localisation de l'utilisateur peut être utilisée pour offrir un service adapté.

L'objectif de ce chapitre est de faire un état des lieux du domaine. Les différentes solutions et leurs aspects standard ou propriétaire sont abordées, et les évolutions possibles envisagées.

9.2. L'équipement utilisateur en 3G

L'UE (User Equipement) est l'équipement qui donne à un utilisateur l'accès à un réseau et ses services ; il inclut nécessairement un ME (Mobile Equipement), et constitue une extension de la Mobile Station du système GSM. Les termes décrivant les différents éléments du terminal ont évolué, passant du GSM à la 3G. La figure 9.1 donne un aperçu général des éléments 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 génération prévoit d'emblée la possibilité d'une séparation de fonctionnalités. L'UMTS, de ce point de vue, est une approche très conceptuelle, certaines de ses fonctionnalités pouvant être réparties dans d'autres machines, par exemple un organiseur ou un PC portable.

Le téléphone mobile correspond au UE (User Equipment), réduit à un ME, et reste la structure la plus commune.

9.2.1. L *équipement mobile (ME)

9.2.1.1. Répartitions des fonctions dans l'équipement mobile

Au sein du ME, les fonctions sont réparties comme suit :

- le MT (Mobile Terminal) gère l'interface radio ; - le TE (Terminal Equipement) contient des applications de bout en bout ; dans

le cadre d'un téléphone mobile, c'est l'entité qui accueille les applications.

Le MT contient l'UICC, la carte à puce où sont détenues les données de gestion de la communication (authentifîcation de l'utilisateur, etc.). L'UICC désigne la carte au sens hardware et plate-forme1. C'est donc un concept qui étend celui de carte SIM (Subscriber Identity Module).

Au sein du 3GPP, un groupe de travail gère la spécification des fonctions du terminal (TSG-T2). Pour plus de détails sur la structure des groupes relatifs à la standardisation des terminaux, voir l'annexe en 9.7.

Comme dans les spécifications GSM, un grand degré de liberté d'implémentation est laissé aux fournisseurs de mobiles. La règle est la suivante :

- l'Interface Homme Machine (accès aux fonctions, menus, icônes, etc.) reste propriétaire car c'est un moyen essentiel de différenciation pour les fabricants ; il reste en dehors du cadre des spécifications ;

- les interfaces sont incluses dans le cadre des spécifications et définies pour garantir l'interopérabilité ; ce sont par exemple les interfaces avec l'UICC pour la gestion des données de l'utilisateur et de la sécurité, le réseau radio et les protocoles associés, certains périphériques locaux (par exemple Bluetooth ou le lien infrarouge).

1. A noter que, pour des raisons de sécurité, il a été décidé au terme de longues discussions au sein du 3GPP (UE Functionality Split) que l'UICC ne saurait être séparée du MT. Il est toutefois possible d'utiliser certaines fonctionnalités de l'UICC depuis l'extérieur du MT.

2. Technical Spécification Group-Terminals.


9.2.1.2. OS, Environnements d'applications et machines virtuelles

Des initiatives ont vu le jour pour définir le système d'exploitation (OS, Operating System). La plus répandue est Symbian3, plus récemment celle de Microsoft avec Smartphone, un sous-ensemble dédié de Pocket PC, ou encore celle de Palm.

Un OS, c'est bien entendu tout d'abord la gestion interne du mobile : - priorité des tâches, gestion de la mémoire ; - support de protocoles de communication ; - bibliothèques (API, Application Programming Interface) de manière à donner

aux programmeurs l'accès au support de la sécurité (algorithmes, etc.), aux différents codecs multimédia (format d'image, de son), aux ressources du terminal, etc.

- accès aux ressources intégrées au mobile.

A la plupart des OS, il faut également ajouter, à la manière du monde du PC, un ensemble de fonctions et de services intégrés au rang desquels :

- l'inévitable 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 instantanées (MSN Messenger, ICQ, Yahoo Messenger, etc.).

Les applications peuvent être développées directement au-dessus des OS évolués comme Symbian (dans ce cas, en C++), mais il existe également une autre approche : celle des Execution Environments. Ils sont le plus souvent basés sur le principe de la machine virtuelle qui permet une approche haut niveau de la programmation et l'indépendance par rapport au hardware. C'est typiquement l'approche Java dont le principe de langage dit interprété 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 développement 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 entièrement tourné vers les applications de communications mobiles et offre tous les outils de développement adéquats (sonneries, écrans de petite taille, gestion des appels téléphoniques, etc).

3. A l'origine Symbian était un développement de PSION, maintenant c'est un consortium réunissant les plus grands fournisseurs de mobiles.


Figure 9.2. Architecture d'un OS de téléphone mobile

Dans le cas de Smartphone, Microsoft [34] adopte une stratégie de synergie avec ses autres produits pour les PC et Palmtops. Les messageries, navigateurs et décodeurs de contenus sont communs ou au moins basés sur les mêmes technologies mais soumis à des limitations liées au mobile, comme le débit (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 prévues. Les protocoles pour le courrier électronique (email) par exemple sont rigoureusement ceux utilisés sur un PC (POP3 ou IMAP). Il existe bien entendu des fonctions spécifiques au monde des téléphones mobile comme par exemple le support du chargement de sonneries ou les fonctions de contrôle d'appel (call control).

Il faut enfin noter que ces OS standards, issus du monde des organiseurs, sont plus particulièrement utilisés sur les téléphones haut de gamme intégrant des fonctions d'organiseurs.

On doit différencier 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 différenciation pour les fournisseurs de mobiles. Le premier type est constitué par :

- d e s ressources standard, comme l'accès au réseau, mais également aux messageries texte ou multimédia (SMS, CBS et MMS) ;

- des ressources classiques, comme la mémoire ou la capacité de traitement.


Parmi les ressources « différenciantes », on peut citer :

- l'écran (variable en taille et en nombre de couleurs) ;

- l'accès à des interfaces locales (Bluetooth, IrDA, etc.) ; - d e s périphériques intégrés (appareil photo, second lecteur de cartes à puce

etc.) ; - des ressources dédiées à l'accélération de certains calculs (pour Java ou encore

pour l'affichage de graphiques).

Plus que dans le monde des ordinateurs, les OS de téléphones mobiles doivent s'adapter et fournir des bibliothèques spécialisées, modulaires et téléchargeables pour des terminaux qui ont à la fois des fonctions communes mais aussi des différences à faire valoir.

9.2.2. La carte à puce (UICC) et ses applications

Comme pour le GSM, la carte à puce est partie intégrante des spécifications en 3G pour ce qui concerne le côté terminal utilisateur. La carte évolue en taille avec un format supplémentaire plus petit, dit mini UICC [9]. Elle contient plus de mémoire: de 8 ko au début des années 1990 on passe à 256 ko fin 2004. Elle propose enfin de nouvelles possibilités comme, par exemple, la gestion de plusieurs applications) (voir figure 9.3).

ID-1 ID-000 Mini UICC « plug-in »

Figure 9.3. Formats standards de l'UICC

L'innovation majeure de la 3G réside dans une architecture qui permet le support de plusieurs applications.


9.2.2.1. L 'architecture d'une UICC

L'UICC est à la fois le matériel (carte à puce) et la plate-forme logicielle qui y est intégrée. Elle est multi-applicative, en ceci qu'elle permet le stockage de plusieurs applications, mais également qu'elle supporte l'exécution simultanée de plusieurs de ces applications.

Cela a d'autant plus de sens dans le domaine des télécommunications que l'application USIM doit fonctionner en permanence pour assurer la continuité du service. Par conséquent n'importe quelle autre application doit pouvoir être exécutée en parallèle.

Figure 9.4. Architecture d'une carte à puce, les différents niveaux d'application

La figure 9.4 représente une architecture possible de carte multi-applicative. On note que SIM et USIM sont des applications à part entière, dites de premier niveau. Il faut noter qu'il existe des applications de deuxième niveau4, reposant sur une application de premier niveau et utilisant leurs ressources. Ces dernières ne sont pas considérées comme des applications vues du système d'exploitation (en termes d'adressage). Les spécifications font la différence entre ces deux niveaux d'applications. Les caractéristiques de base de l'UICC sont décrites dans la spécification technique TS 31.101 [9].

L'ISO5 [19] définit le fonctionnement d'une carte multi-applicative. L'outil principal d'adressage des applications est un système de canaux logiques, établis par

4. Les applets Toolkit, par exemple.

5. Spécifications de la série ISO-IEC 7816, plus particulièrement 7816-4 dans le cas présent.


le système d'exploitation pour adresser les commandes qui lui sont destinées à une application donnée. Ils sont actuellement au nombre de 4 mais doivent être portés à 20 à court terme. Dès lors, 20 applications (de premier niveau) pourront être exécutées en parallèle sur la carte.

9.2.2.2. Plusieurs applications sur une UICC

Une application SIM peut être intégrée à l'UICC ou, dans un certain cadre, simulée par une USIM. Cela permet :

-à des opérateurs 3G n'ayant pas déployé de réseau GSM d'offrir, en accord avec un opérateur GSM, l'itinérance sur ce système ;

- aux opérateurs GSM de proposer des cartes compatibles 3G en prévision d'un futur réseau ou à fins d'itinérance dans des réseaux 3G.

Un des besoins identifiés pour la 3G est celui pour l'UICC de pouvoir contenir plusieurs USIM. Il est en réalité restreint par la mention dans les recommandations qu'une seule USIM ne peut être active à un moment donné. Toutefois, l'UICC a été conçue pour ne pas être dédiée aux télécommunications mais comme une plate-forme capable de supporter d'autres applications, comme par exemple, des applications bancaire, de porte-monnaie électronique, de transport, etc.

Au sein même du domaine des télécommunications, plusieurs applications ont été définies (ou pourraient voir le jour) : l'USIM, bien sûr, mais aussi l'ISIM pour les réseaux IP multimédias et l'EAP pour l'accès aux réseaux Wi-Fi.

L'USIM permet de personnaliser le terminal mobile à un utilisateur en apportant toutes les données liées à son abonnement et en donnant l'accès aux services auxquels l'utilisateur a souscrit. Elle dispose de trois fonctions de base :

- les fonctions de sécurité (identification de l'utilisateur par présentation de code PIN (Personal Identification Number), authentification dans le réseau, génération de clés de chiffrement par l'exécution d'algorithmes sur la carte) ;

- l a gestion de données administratives du réseau (stockage d'identités, mémorisation de données de localisation et d'informations sur l'environnement, services parmi lesquels le USIM Lock6 ou encore la restriction d'appels sortants) ;

- le stockage de données 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 particulièrement utilisé par les opérateurs qui subventionnent l'achat des terminaux et ne souhaitent pas voir ces derniers utilisés sur un réseau concurrent. La fonctionnalité est en fait supportée par le mobile, la carte ne contenant que des données d'identification.


L'ISIM7 [11] est l'équivalent d'une USIM pour un réseau IP multimédia. ISIM a été spécifiée au 3GPP comme une application indépendante pour le cas de terminaux dédiés uniquement à ce type de réseau. Toutefois, les opérateurs de réseaux mobiles s'opposent actuellement vivement à une telle approche qui permettrait dans le futur à des opérateurs offrant uniquement des services IP de profiter de leur réseau d'accès radio.

L'EAP (Extensible Authentication Protocol) pour UICC [18] (et sa déclinaison 3G : EAP AKA (Authentication Key Agreement) [21] permet à un terminal Wi-Fi d'offrir des services d'authentification renforcés, basés sur les algorithmes 2G ou 3G présents sur la carte. Cela est particulièrement intéressant pour des opérateurs offrant à la fois des services de téléphonie et des hotspots8.

9.2.2.3. OS, environnements applicatifs et API

Dans le domaine des cartes à puces, il n'y a pas de système 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 même atteint le niveau de prototypes.

Les environnements d'applications voient pour leur part un développement important lié au succès du SAT (SIM Application Toolkit) [8] dans le système GSM. La carte, jusqu'alors esclave du terminal mobile, devient un élément proactif, capable d'envoyer des commandes pour provoquer des affichages, récupérer des informations ou encore échanger des données au travers du terminal mobile. Cet environnement fort de son succès est porté en troisième génération 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 propriété de l'opérateur qui en connaît a priori ses caractéristiques. 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'accès à un service 802.11 (Wi-Fi par exemple - 802.1 lb).


Il faut tout de même reconnaître que si la carte a des avantages propres indéniables (voir tableau 9.1) ses capacités resteront de fait toujours en retrait de celles du terminal.

Mobile Carte Commentaire

Process * L'évolution des processeurs bénéficie de la même façon aux terminaux et aux cartes. La contrainte de taille des processeurs carte fait que la carte restera en arrière.

Capacité mémoire

*

Le mobile gardera toujours une grande avance en termes de capacité mémoire, ne serait-ce que par sa taille. Pour l'ordre d'idée, 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 mémoire disponibles pour les applications et fichiers de l'utilisateur.

Portabilité * L'utilisateur peut retrouver ses données personnelles, son profil, son abonnement dans n'importe quel terminal 3G en y insérant sa carte

Sécurité *

La carte à puce bénéficie d'une structure hardware indépendante et sécurisée qui permet de réaliser des calculs en local sans que les données utilisées puissent être accessibles de l'extérieur.

Tableau 9.1. Mobiles et cartes, avantages croisés

Il est clair par contre qu'il est intéressant de jouer des avantages des deux partis pour construire les meilleures applications.

9.3. Environnements propriétaires - environnements standards

Standardiser un environnement applicatif, c'est permettre le développement d'applications indépendamment de la plate-forme matérielle sur laquelle elles seront exécutées. La conception d'applications devient plus simple et moins coûteuse.

Toutefois, si les ressources et périphériques de base sont bien les mêmes pour la très grande majorité des téléphones, il existe des différences significatives entre les différentes interfaces homme-machine ; de plus, les ressources spécifiques des terminaux ne sont pas standards. Certains fournisseurs de mobiles cherchent ainsi à se différencier en proposant des appareils qui optimisent l'affichage 3D ou encore certains types de calculs pour favoriser certaines applications. Comment dès lors passer à un standard ?


Quelques industriels ou groupes de standardisation (eux-mêmes généralement dans F industrie) travaillent pourtant sur la définition de certains aspects parmi lesquels :

- Open Mobile Alliance (ex-fVAP Forum) [29] protocoles, navigateur et environnement applicatifs ;

- 3GPP [23]/3GPP2 [24] pour les aspects liés au réseau coeur et radio ; - GSM Association [26] pour le niveau service et application.

9.3.1. Différentes ressources pour différentes applications

Chaque mobile dispose d'un ensemble de ressources auxquelles un programmeur doit pouvoir accéder dans la conception d'une application. Ces ressources incluent :

- l'accès aux médias de communication/services de base, normalement standard (même s'il existe des classes pour certains services comme par exemple le GPRS) ;

- l'accès aux périphériques « de base » dont certaines fonctionnalités peuvent être facilement standard contrairement à certaines, plus spécifiques : 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 délicat de développer un standard ;

- l'accès à des fonctions de cryptographie.

9.3.2. Les différents environnements

Au moment de l'arrivée de la 3G, il existe trois environnements prépondérants9

au milieu d'implémentations propriétaires :

- Java sous plusieurs formes, J2SE {Java 2 Standard Edition) qui correspond à l'édition PC, adaptée à des mobiles-organiseurs (PDA), J2ME (Java 2 Micro Edition) qui est une adaptation de J2SE aux terminaux de petite taille, aussi couramment appelée 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 particulièrement pour les mobiles dotés de fonctions organiseurs (PDA) ; notons que Microsoft a la même approche avec Smartphone.

9. Les deux premiers sont d'ailleurs référencés dans les spécifications 3GPP.

I


Tous ces environnements offrent une plate-forme d'exécution d'applications et des APIs pour l'accès aux fonctionnalités du mobile. Les développeurs d'applications peuvent donc concevoir un seul code quel que soit le mobile sur lequel le programme sera exécuté. Dans certains cas, ils pourront même disposer d'un seul exécutable quelle que soit la plate-forme.

9.3.2.1. Java

Si Java est une initiative de Sun Microsystems [37], son développement dans le domaine des télécommunications relève 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 Spécification Requests) qui sont examinées par un groupe d'experts (Expert Group) puis proposées en relecture publique avant de devenir un standard.

Le principe d'origine est de n'écrire une application qu'une seule fois et de pouvoir l'exécuter sur n'importe quelle plate-forme compatible. Le choix technique de l'interpréteur a évolué puisque le code est maintenant optimisé avant

J2SE

J2ME

Figure 9.5. Java de l'édition standard aux versions mobile et carte


interprétation sur une machine virtuelle. Il est bon de noter à ce sujet que l'interopérabilité 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 système d'exploitation et a une structure de profil et de configuration :

-profil qui correspond à une famille de terminaux aux caractéristiques communes, c'est le MIDP (Mobile Information Device Profile) ;

- configuration qui définit une plate-forme minimale en termes de services pour un profil donné. La configuration adaptée au domaine des téléphones mobiles est CLDC (Connected Limited Device Configuration).

Il faut noter que les implémentations actuelles de J2ME restent incompatibles entre elles, chaque fournisseur de mobile ayant des extensions propriétaires. Il existes deux tentatives de nivellement, celle, standard, de Java Community Process avec MIDP 2 et celle, propriétaire, de DoCoMo avec DoJa.

Le premier environnement d'applications standard à avoir été spécifié pour la carte fut Java Card, un sous-ensemble de Java doté d'API carte (pour gérer les commandes et événements spécifiques à la carte à puce) et d'API spécifiques aux différentes applications, VISA pour les applications bancaires ou SIM pour le GSM puis UICC/USIM en 3G. Cet environnement permet le développement d'applets sur des cartes à puce. Les applications actuelles sont nombreuses dans le domaine GSM.

9.3.2.2. Symbian

Symbian donne aux développeurs l'accès à des API pour concevoir des applications (typiquement sur l'architecture décrite en figure 9.2. Un ensemble d'API est accessible aussi bien depuis une application développée en C++ (qui tournera de manière optimisée sur le terminal), que sur une machine virtuelle Java, incluse dans l'architecture. Cette combinaison est certainement un avantage pour les développeurs qui peuvent selon les besoins choisir une solution ou l'autre.

Le support des protocoles de communication est très important dans la version 7, avec :

- la très grande majorité des protocoles de l'Internet, WAP, USB, médias locaux (Bluetooth, IrDA, etc.) ;

- de nombreuses technologies de téléphonie (GSM, GPRS, CDMA2000, etc.).


9.3.2.3. WAE

Le Wireless Application Environment (WAE) s'inscrit dans une volonté du WAP Forumw de créer une architecture standard, basée sur les protocoles WAP, sur laquelle peuvent être développés des services. La seconde version des spécifications se rapproche singulièrement des standards de l'Internet alors que la première les adaptait, sous prétexte de ressources limitées dans le cas de la 2G (principalement le GSM).

WAE est maintenant essentiellement basé sur une série de ressources qu'il référence :

- XHTML mais aussi pour des raisons historiques WML ; - SyncML pour la synchronisation (voir paragraphe 9.5.2) ; - une série de formats supportés 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 propriétaires tendent à disparaître actuellement, d'autant plus que l'offre de terminaux est très diversifiée. L'absence de standard condamnerait le monde des fournisseurs de services à des développements coûteux.

On peut tout de même mentionner dans le domaine de la carte à puce une tentative de concurrence à Java Card. Des difficultés 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 décrire une API commune basée sur le langage C : C Bindings for SIM API. La spécification a été approuvée courant 2002 pour la Release 6 des spécifications 3G.

9.3.3. Interfonctionnement des environnements

Il n'est pas exclu que plusieurs environnements coexistent au sein d'un terminal. Chaque application basée sur un environnement peut exploiter ses avantages. Le cas le plus intéressant est celui d'applications résidant sur l'UICC communiquant avec des applications résidant sur le mobile.

Le développement d'applications partagées permet de bénéficier des avantages de chaque élément. Dans la plupart des systèmes, l'un des éléments est considéré

10. Dont le nom a changé pour Open Mobile Alliance.


comme maître ; il accède aux autres ressources comme à des esclaves, cette relation étant figée. Toutefois, ces systèmes ne sont pas incompatibles entre eux et il n'est pas exclu, en utilisant tantôt l'une, tantôt l'autre, d'établir une communication dans tous les sens. Plusieurs solutions permettent à une application développée 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 (centrée sur le mobile) est celle choisie au sein du Java Community Process dans le cadre de la spécification JSR 17711. Il s'agit pour une application du terminal de pouvoir déclencher l'exécution d'une application dans la carte. Ce type d'accès permet d'envisager l'utilisation d'une application dédiée au paiement qui résiderait sur la carte depuis une application résidant dans le mobile (jeu, achat, loterie, etc.). SIM Alliance [30] a également travaillé sur une application qui gère sur l'UICC les droits d'exécution d'une autre application, basée elle sur le terminal. Cela permet de gérer facilement différents niveaux d'accès à une même application (par exemple : démo, utilisation partielle ou temporaire, utilisation complète). Le contrôle étant fait au sein de la carte, la licence est relative à l'utilisateur, et non au terminal comme d'autres systèmes de gestion de droits opérants.

Le JSR 177 est orienté sur les aspects sécurité et n'est pas strictement lié à des applications Java Card côté carte à puce. La spécification définit un ensemble d'API utilisables par des applications développées sur une plate-forme J2ME dans le mobile.

Figure 9.6. Le mobile garde l'initiative de l'accès à des périphériques (dont la carte)

11. Pour plus d'informations sur ces spécifications, visiter le site de SUN Microsystems, http://jcp.org/en/jsr/detail?id=177

http://jcp.org/en/jsr/detail?id=177


Le même type d'approche est utilisée dans le cadre du WAP Forum pour le développement de EFI (External Function Interface), donne l'accès à des éléments « extérieurs » au mobile, dont la carte, comme à des périphériques. Le mobile gère ces accès depuis le navigateur ou l'environnement applicatif définit par WAP, WAE.

L'EFl se présente également comme un ensemble de librairies décrites en WMLScript qui permettent de définir un ensemble de services qui peuvent être étendus de manière propriétaire en fonctions des périphériques disponibles.

9.3.3.2. Cas où la carte a l'initiative

La situation inverse trouve aussi des utilisations : la carte à puce va déclencher l'utilisation d'applications situées sur d'autres supports, dans le mobile même ou par exemple dans une autre carte à puce. Les exemples d'implémentation aujourd'hui sont basés sur l'accès à un second lecteur de carte (pour des mobiles bi-slot). Des applications de paiement par carte bancaire en France12 et de rechargement de porte-monnaie électronique au Royaume-Uni13 sont basées sur ce principe.

Figure 9.7. Principe de fonctionnement dans le cas USAT maître

L'application utilise dans ces cas des commandes (U)SAT qui lui permettent de solliciter des ressources extérieures. C'est le cas de l'application iti-Achat qui repose sur un schéma présenté à la figure 9.8.

12. L'expérience iti-Achat de Orange France (Itinéris à ce moment là). 13. Pilotes menés avec les porte-monnaie Mondex.


Tout d'abord, l'application SAT résidant sur la SIM est déclenchée par l'arrivée 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 déclenche ensuite l'application de paiement sur une carte bleue insérée dans la seconde fente du mobile ©

L'application de paiement (débit) de la carte bleue prend alors le relais : elle reçoit la demande de paiement, et effectue une procédure de paiement identique à celle effectuée dans un terminal sur point de vente (autorisation par présentation de code PIN puis relation avec le serveur carte bancaires) O. Elle retourne enfin à l'application (U)SAT un résumé de l'opération (numéro de transaction, etc.) ©. L'application (U)SAT affiche enfin le résultat de l'opération.

Figure 9.8. Une application de paiement - principe

L'(U)SAT permet d'accéder à des ressources extérieures à la carte, parmi lesquelles :

- différents modules du terminal (écran, clavier, etc.) ;

- d e s supports de communication via le Bearer Independent Protocol, pour échanger des données (voir paragraphe 9.5.5.2) ;

- des périphériques extérieurs du type carte supplémentaire.

Une application résidant sur la carte peut ainsi communiquer et interagir avec l'extérieur. Néanmoins, il n'existe pas encore de possibilité pour une application résidant sur la carte de déclencher une application du mobile.


9.3.4. Les services d'Internet Mobile

L'application maintenant incontournable des téléphones mobiles est l'accès aux ressources de bases de l'Internet : la navigation et l'email. Deux approches se sont différenciées dans l'implémentation de ces ressources :

-ce l le qui part de l'hypothèse que le terminal mobile a peu de ressources de calcul et un médium de communication faible ; cette approche suppose donc l'adaptation des protocoles et des contenus, c'est WAP jusqu'à la version 1.2.1 ;

- ce l l e qui donne l'accès à la grande partie de l'Internet, soit en offrant un accès complet (approche des téléphones organiseurs en GSM), soit en offrant en plus des fonctionnalités liées à la téléphonie, c'est i-mode.

La 3e génération rendant la première hypothèse quasiment caduque, voit la convergence de WAP vl et de l'i-mode avec WAP v2. A noter que, parallèlement, la plupart des mobiles GSM haut de gamme supportent déjà à 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 nécessaire 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'accès à des contenus WML sur la base de terminaux non dotés de navigateurs.

Le principe repose sur l'utilisation d'une passerelle de traduction du WML vers un script compréhensible par la carte et d'un système de navigation par menus.

Cette approche a d'abord été propriétaire (Wireless Internet Browser), puis reprise par un consortium de fournisseurs de cartes à puce puis finalement proposée comme un standard 3GPP : / 'USATInterpreter [13].


requête requête

Interprétation contenu

Réponse WML Réponse 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 (dès la seconde génération), c'est MExE [2] (Mobile EXecution Environment). Cette activité a toutefois été arrêtée début 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 référençant un ensemble d'environnements remplissant ou s'engageant à remplir un ensemble minimal de fonctions et par l'ajout de librairies (API).

MExE définissait également un environnement de service. En revanche, on n'y trouvait pas de liste minimale de fonctionnalités supportées par le terminal. MExE était basé sur un ensemble de fonctionnalités de base parmi lesquelles la possibilité

Figure 9.11. Principe de l'adaptation des services d'une Classmark aux besoins définis par MExE


pour l'utilisateur de contrôler l'interface des applications et l'accès aux ressources de communication, en particulier pour l'accès à des ressources facturées. MExE permettait également pour le fournisseur de service de facturer l'utilisation ou le chargement d'une application et offrait la possibilité d'accéder à des ressources de sécurité (certification, authentification, etc.).

Parmi les fonctionnalités additionnelles, on peut noter :

- un système de négociation de fonctionnalités (découverte des services, etc.) en début et en cours de session ;

- une liste de classes (classmarks) qui permettent lors de la phase de négociation d'identifier l'environnement applicatif utilisé : WAP, WAE, J2SE, J2ME, Microsoft CLI également connu sous le nom ISO CLI ;

- d e s ressources de téléchargement, lesquelles faisaient à l'origine partie des objectifs de MExE mais n'ont jamais été spécifiées.

Si l'expérience MExE s'est arrêtée sans que des implémentations 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 démarrage laborieux des téléphones WAP, une initiative est prise au sein de la GSM Association pour définir un ensemble de fonctions minimales pour supporter l'Internet mobile. C'est la notion de m-services14. L'approche est la même que celle qui avait amené le japonais NTT DoCoMo [35] à proposer i-mode. Ce système est basé sur la spécification par l'opérateur d'un jeu de fonctionnalités 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 supportés par le terminal (principalement des références aux protocoles WAP et à des mark-up languages Internet) ;

- une machine virtuelle pour l'exécution d'applications ; - le téléchargement d'application et de données en général ; - des niveaux de sécurité.

14. Le groupe de travail consacré au sujet est le MSIG (M-Services Interest Group).


L'initiative n'a donné que peu de résultats sur le marché, encore qu'on peut considérer que certaines offres multimédia en 2003 sont fortement inspirées de cette approche. Une seconde phase est en cours d'élaboration, orientée clairement vers la 3G.

9.4. Virtual Home Environment

Le projet VHE ( Virtual Home Environment) [3 et 4] a vu le jour dans les spécifications GSM mais aucune implémentation n'en a été faite. Le concept repose sur la possibilité pour un utilisateur de disposer du même environnement (renvois, numéros courts, services, langage, etc.) sur son téléphone, qu'il soit dans son réseau nominal ou en itinérance.

Dans le cadre de VHE est défini un profil d'utilisateur (comprenant des préférences et des paramètres) qui peut être modifié par accès direct aux données mais également de façon dynamique en cours d'utilisation d'un service.

Les mécanismes devant supporter le concept de VHE sont au sein du 3GPP : CAMEL (Customised Applications for Mobile network Enhanced Logic, le réseau intelligent dans les réseaux 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 préférences et de configurations (terminal et services).

Le choix d'OSA réside dans le besoin de disposer d'un environnement de services flexible susceptible de supporter des applications et services non encore identifiés. OSA fournit cette interface extensible et adaptable. Les API sont conçues comme indépendantes des solutions sur le marché et des langages de programmation. Ces API doivent permettre de construire les mêmes services indépendamment de la localisation de l'utilisateur.

OSA est construit autour de trois éléments : - des applications ; - u n e structure qui comprend l'accès aux services de base que les applications

peuvent utiliser et qui sont construites sur différentes technologies (CAMEL, MExE, USAT) ;

- des « serveurs de fonctionnalité de base », chaque fonctionnalité pouvant exister sur plusieurs serveur, selon les ressources disponibles.


Un ensemble de mécanismes de base entre les applications et la structure même d'OSA sont appliqués avant même que le service ne soit offert à l'utilisateur : authentification, autorisation, découverte des fonctions disponibles et accès au service.

La mise en place d'un réel environnement virtuel est une volonté évidente des opérateurs, 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 propriétaires de la part des grands groupes.

9.5. Le téléchargement

Peu d'applications sont destinées à un usage purement local au mobile, la plupart existent pour être connectées soit directement à un serveur d'information, soit à des périphériques, par exemple organiseur ou autre téléphone mobile. Par ailleurs, de nouvelles applications sont disponibles quotidiennement et les applications existantes nécessitent parfois des mises à jour.

La nature mobile de ces terminaux fait du téléchargement d'informations ou d'applications un complément indispensable à un environnement applicatif. Le besoin a été ressenti relativement tôt dans l'histoire du GSM et les solutions apportées ont été dans un premier temps basées sur des médias de transmission peu adaptés aux données (le SMS en particulier), puis sur des médias plus efficaces ou spécialement adaptés. La 3G arrive au moment où de nombreux médias de transmission sont disponibles, via le réseau ou en local.

9.5.1. Les applications du téléchargement

Le marché des organiseurs électroniques (PDA, Personal Digital Assistant) a déjà provoqué de sérieux travaux sur la mise à jour d'informations, la requête d'information ou même le téléchargement d'applications sur des terminaux mobiles.

Chaque fabricant a mis en place un système de synchronisation des données qui permet le chargement d'applications. On peut citer pour mémoire HotSync pour le Palm OS [36] ou ActiveSync pour Microsoft. Dans le cas général, les données/applications sont chargées à partir d'un PC connecté via une station (ou un port Infrarouge) sur lequel on les a au préalable installées. On trouve également la possibilité de réaliser le chargement au travers d'un PC et d'une connexion Internet vers un serveur distant.


Par ailleurs, plusieurs fournisseurs de services sont connus dans le domaine des PDA. Le principe réside dans l'utilisation du procédé de synchronisation de l'organiseur (par exemple HotSync pour les Palm OS) et d'un navigateur généralement propriétaire. 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 même manière, on peut télécharger des applications. Une extension de ce système consiste à utiliser l'accès direct à un réseau de télécommunications et à s'affranchir de la liaison de synchronisation. C'est le cas pour des terminaux dotés d'un module GPRS, Wi-Fi ou Bluetooth.

Au-delà de ces applications, les industriels se posent la question du téléchargement de codecs sur des terminaux disposant des capacités hardware à les supporter. L'intérêt serait alors d'offrir l'itinérance vers des réseaux aux protocoles d'accès différents ou de mettre à jour les protocoles de communication avec le réseau.

9.5.2. Synchronisation

La multiplication des terminaux (et de l'information sur les terminaux) force à traiter le problème de la synchronisation. L'utilisateur est typiquement demandeur d'une synchronisation de ses contacts entre son PC (sur lequel généralement il reçoit ses emails), son organiseur (qu'il utilise pendant ses déplacements pour consulter contacts et rendez-vous) et son téléphone.

L'initiative la plus connue dans le domaine de la synchronisation est SyncML. SyncML est un standard référencé par le 3GPP et OMA (Open Mobile Alliance) qui définit 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 présente comme une couche applicative reposant sur les couches standard existantes, principalement http.

Il existe également des solutions propriétaires développées par les fournisseurs d'organiseurs électroniques, lesquelles ont tendance à converger vers la solution SyncML.


en local à distance

Figure 9.12. Les différents terminaux et la synchronisation

9.5.3. Fonctionnalités liées au téléchargement d'applications

Un ensemble de fonctionnalités de base doit être spécifié pour faire du téléchargement de données ou d'applications :

- un accès au serveur et une authentification éventuelle ; - d e s fonctions de sécurité comme le chiffrement/déchiffrement éventuel de

contenu, la certification du contenu ; - la reconnaissance du contenu et un lien vers une application d'installation ; - la gestion d'application à distance : exécution à distance d'application,

déclenchement d'applications sur événement, gestion de versions, compte-rendu d'installation depuis le serveur, effacement d'applications.

Un point clé de la sécurisation des systèmes de téléchargement d'applications reste la certification des applications disponibles. Cette fonctionnalité est cruciale pour les opérateurs qui souvent garantissent les données, mais surtout pourraient souffrir du piratage des terminaux. Deux approches existent dans le domaine : une approche centralisée autour d'une autorité de certification (souvent associée à un seul serveur chez l'opérateur) et une approche distribuée avec différentes autorités de certification, reconnues par l'opérateur.


Figure 9.13. Les schémas de certification d'une application

Le schéma centré sur l'opérateur reste celui le plus rencontré en deuxième génération. En 3G par contre, il est possible que l'autre schéma s'impose, correspondant à une architecture typiquement rencontrée sur Internet, l'architecture de ces réseaux ayant tendance à converger vers une unique solution.

Un autre point capital des systèmes de téléchargement est la possibilité de gérer les applications à distance. Cela permet de mettre à jour des applications déjà téléchargées, d'éviter de tenter le téléchargement d'une application déjà présente sur le terminal. Cela permet également de vérifier la bonne installation d'une application téléchargée.

9.5.4. Environnements applicatifs et téléchargement

Les environnements applicatifs sont pour la plupart dotés d'origine de mécanismes de téléchargement ou au moins de recommandations sur ces mécanismes.

Java dispose de recommandations sur les fonctionnalités du téléchargement d'applications. Dans le cadre de l'édition mobile (J2ME), une spécification (JSR 124), présente dans MIDP vl , définit l'architecture générique permettant le


téléchargement. Le téléchargement est d'abord spécifié 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 téléchargement d'informations ou d'applications peut se faire sur deux canaux : le SMS d'un côté et le Bearer Independent Protocol de l'autre (voir paragraphe 9.5.5).

OMA développe pour sa part un protocole de téléchargement qui a pour objectif l'indépendance de plate-forme logicielle. Le système est essentiellement basé sur http mais ajoute également quelques fonctionnalités de négociation sur le format de contenu et de confirmation de réception et d'installation. Cette spécification couvre les implémentations Internet et Java.

9.5.5. Supports de communication du réseau 3G

Les téléphones mobiles supportent de plus en plus de moyens de communication différents. Ceux-ci peuvent être classés en deux catégories, selon qu'ils sont des médias :

- locaux, échange d'information entre deux terminaux proche l'un de l'autre, par exemple, le lien infrarouge, Bluetooth, etc. ;

- réseau, utilisation d'un réseau 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 réseau de l'opérateur. Elles sont basées sur l'utilisation de supports de communication à courte distance avec une portée de quelques mètres au plus. Les applications vont de la synchronisation de données entre terminaux à l'accès à des terminaux de point de vente pour le paiement en boutique ou bien l'accès aux transports.

D'autres applications ont vocation à interagir avec un serveur distant, les informations transitent alors sur le réseau de l'opérateur (ou d'un opérateur ayant des accords de roaming).

Les principaux systèmes sont consignés dans le tableau 9.2. Ces supports de communication sont utilisables par les applications résidentes sur le terminal par l'utilisation d'API spécifiques. Cependant, la multiplicité des implémentations dans certains cas conduisent à choisir des solutions dont les spécifications sont le résultat du travail d'un forum ou d'un consortium. Ainsi Bluetooth ou les lecteurs de carte interne ont un avenir plus probable que la connexion infrarouge. Effectivement, dans


ce dernier cas, si les couches basses sont bien spécifiées, les couches applicatives sont restées propriétaires.

Système Support Débit Origine Type d'applications

supports de communication en local

Bluetooth Radio 720 kbit/s Industrie

Lien vers un PC Lien vers des périphériques divers (caméra, photo...) Lien vers un PDA

Carte sans contact Radio 424 kbit/s ISO Transport

I rDA Infrarouge 115 kbit/s Industrie

Terminal utilisé comme un modem Echange d'informations d'un mobile à un autre Lien vers un PDA

Connexion physique USB, série... Jusqu'à 12

Mbit/s Industrie... Lien vers un PC Lien vers des périphériques divers (caméra, photo.. .)

Périphérique interne Contacts ISO 9,6 à 115

kbit/s ISO Lecteur de carte supplémentaire (bancaire)

supports de communication en réseau Circuit switched

Data jusqu'à

9,6 kbit/s

3GPP GPRS Jusqu'environ 50 kbit/s 3GPP -

IP Multimedia Subsystem (IMS)

Radio 3GPP

Prévu pour supporter tout type de transfert de données (y compris la voix sur IP)

Wi-Fi Jusqu'à 11 Mbit/s IETF Support Internet

Tableau 9.2. Supports de communication locaux

9.5.5.2. Gestion de l'accès aux supports de communication

Une fonction du terminal est de gérer l'accès aux médias de communication. Toutefois, l'application n'est pas forcément résidente dans le terminal lui-même. Le terminal est alors utilisé à la manière d'un modem et de manière plus ou moins active :

- « modem simple » avec les applications résidantes dans un PC ou un organiseur nécessitant juste l'usage de téléphone pour accéder au médium de communication ;

•


- « modem actif » dans le cas d'applications demandeuses de transfert d'informations sans pour autant préférer 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).

Le 3GPP considère sérieusement le fonctionnement des différentes applications simultanément dans le mobile et les priorités à leur accorder. Une utilisation transparente du tenninal pose le problème du contournement des restrictions d'abonnement imposées par l'opérateur, le fournisseur de service ou même le propriétaire du mobile. Les fonctions permettant de générer ou de gérer 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'accès à des supports locaux de communication est moins surveillée.

9.6. Conclusion

Les applications offertes sur les mobiles sont l'axe de développement actuel au moment où l'application téléphonie (au sens de la transmission de la voix) a atteint sa maturité. Ce sont les applications qui font maintenant la différence entre les offres des opérateurs et qui justifient les ressources accrues en 3G.

De nouveau intervenants entrent dans le marché des services et applications. L'offre en matière de terminaux devient très fournie, avec les téléphones mobiles, organiseurs, appareils photo, ordinateurs portables et même terminaux de paiement sur point de vente. L'interopérabilité devient un point fondamental pour permettre le succès d'une application pouvant être utilisée sur différents

Transfert de données géré par le mobile

Figure 9.14. Transfert de données au travers du mobile restant actif - Bearer Independent Protocol


terminaux, téléchargée ou interagissant avec plusieurs terminaux. L'interopérabilité vaut tout d'abord pour le code source de l'application, mais aussi pour les ressources qui lui sont offertes.

Cette interopérabilité 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 propriétaires qui ont été développées en seconde génération, 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 opérateurs et des fournisseurs de services.

9.7. Annexes

9.7.1. La standardisation côté terminaux

9.7.1.1. Terminaux Mobiles

9.7.1.1.1. 3GPP

Les spécifications des terminaux sont écrites et dans le cadre de l'activité du groupe T (pour Terminais) du 3GPP sur des spécifications 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 dédié aux terminaux sera dissout et ses activités réparties sur les trois autres groupes consacrés à la 3G, GERAN restant a priori encore indépendant.

Le groupe de travail des terminaux est divisé en trois groupes.

Figure 9.15. Sur fond gris foncé, les principaux groupes et sous-groupes liés aux terminaux


9.7.1.1.2. OMA

OMA est la résultante de la réunion de plusieurs forums mineurs autour de WAP. L'objectif affiché est de standardiser un ensemble de briques de base qui permettront aux opérateurs et aux fournisseurs de services de construire leurs offres.

Figure 9.16. Sur fond gris foncé, les principaux groupes et sous-groupes liés aux terminaux

9.7.1.2. Carte à puce et standards

La promotion de la carte multi-applicative dans les domaines télécommunications, pour le 3GPP, le 3GPP2, etc. est passée par la répartition du travail de spécification entre une partie générique (définie au sein d'un projet ETSI : le groupe Smart Card Platform) et des parties spécifiques au 3GPP, définies dans le troisième sous-groupe du groupe Terminal (TSG-T SWG3).

9.7.1.2.1. 3GPP

Au 3GPP un comité est en charge de la spécification technique des applications basées sur carte à puce. Néanmoins, certains groupes orientés service ont une forte interaction avec la carte, en particulier bien sûr dans le cas du groupe dédié aux aspects sécurité.


Figure 9.17. Sur fond gris foncé, les principaux groupes et sous-groupes liés à l'UICC

Notons que depuis le début de la spécification du système de troisième de génération, il a été décidé que les aspects génériques (c'est-à-dire pouvant être communs à d'autres applications basées sur la carte) seraient standardisés en dehors du 3GPP : au SCP.

9.7.1.2.2. ETSI Project Smart Card Platform

Initialement, l'idée était de créer 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 télécoms, mais aussi des partenaires du monde de la finance, de l'identité, etc.) ;

- q u i aurait spécifié tous les éléments d'une plate-forme commune à de nombreuses applications carte à puce (voir figure 9.18).

Figure 9.18. Domaine de travail du SCP


Si le projet produit rapidement les spécifications d'une plate-forme à partir des spécifications GSM, le partenariat lui ne prend pas, les différents protagonistes étant plus intéressés par le principe que par la formalisation du partenariat. Le travail continue néanmoins, même si la plate-forme générique reste plutôt destinée aux télécommunications.

Le projet SCP est structuré en un groupe plénier qui pilote un groupe de définition des besoins et un groupe de spécifications 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 dédié à la carte à puce dans OMA. Certains groupes occasionnellement évoquent l'utilisation pour un service ou une fonction particulière de la carte (le provisioning par exemple). OMA hérite par contre d'une application carte définie par le WAP pour des aspects de sécurité : c'est la WIM ( WAP Identity Module).

9.7.2. Références

Ces références permettent d'aller plus loin dans les sujets évoqués dans cet article.

9.7.2.1. Spécifications - Standards

Les principaux documents de référence sont les suivants :

Documents maintenus par le 3GPP

Documents liés au Mobile

[ 1 ] TS 23.101 General UMTS Architecture

[2 ] TS 22 057 /23 057 Mobile Station Application Execution Environment (MExE)


Documents liés à VHE

[3] TS 22.121/23.127

[4] TR 23.957

Virtual Home Environment

Virtual Home Environment (VHE) concepts

Documents liés au SIM

[5]

[ 6 ]

[7]

[ 8 ]

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

Spécification of the Subscriber Identity Module -Mobile Equipment (SIM - ME) interface

SIM Application Toolkit (SAT)

Documents liés au USIM/ISIM

[9] TS 31 .101 UICC - Terminal Interface; Logical and Physical

Characteristics

[10] TS 31 .102 Characteristics of the USIM Application

[ H ] TS 31 .103 Characteristics of the ISIM Application

[12] TS 31 .111 USIM Application Toolkit (USAT)

[13] TS 31 .112/13/14 USAT Interpreter

[14] TS 31 .130 USIM API

Documents maintenus par le SCP

Documents liés à l'UICC

[15] TS 102 221 Smart Cards: UICC Terminal interface; Physical and

logical characteristics

[16] TS 102 223

[17] TS 102 241

[18] TS 102310 EAP support in UICC


Documents liés à la carte à puce Documents maintenus par l ISO à partir de documents de SDO nationaux (ex : AFNOR)

[ 19] ISO/IEC 7816 (Série) Smart Card Characteristics ( 15 chapitres distincts)

Documents plus généraux Documents maintenus par l IETF

[20] IETF draft EAP-support in smartcards (http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-03.txt)

draft-arkko-pppext-eap-aka-11, "EAP AKA Authentication". [21] IETF draft http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-

ll.txt draft-haverinen-pppext-eap-sim-12, "EAP SIM

[22] IETF draft Authentication".http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-12.txt

9.7.2.2. Sites Web pour plus d'information Organismes de standardisation :

[23] 3GPP http://www.3gpp.org/

[24] 3GPP2 http://www.3gpp2.org/

[25] ETSI http://www.etsi.org/

Forums dédiés dans le domaine :

[26] GSM Association http://www.gsmworld.com/

pages concernant m-services

http://www.gsmworld.com/technology/services/index.shtml

[27] Java Card Forum http://www.javacardforum.org/

[28] Java Community Process http://www.jcp.org/en/home/index

[29] Open Mobile Alliance http://www.openmobilealliance.org les spécifications WAP/OMA sont disponibles à

http://www.wapforum.org/what/technical.htm

[30] SIM Alliance Alliance de fournisseurs de fournisseurs de cartes à puce http://www.simalliance.org/

[31 ] Symbian Alliance de fournisseurs de mobiles autour d'une solution développée à l'origine pour des organiseurs PSION http://www.symbian.com/

[32] SyncML Alliance d'industrie définissant un standard de synchronisation entre terminaux : http://www.syncml.org/

http://www.ietf.org/internet-

http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-

http://www.ietf.org/internet-drafts/draft-


http://www.3gpp2.org/

http://www.etsi.org/

http://www.gsmworld.com/

http://www.gsmworld.com/technology/services/index.shtml

http://www.javacardforum.org/

http://www.jcp.org/en/home/index

http://www.openmobilealliance.org

http://www.wapforum.org/what/technical.htm

http://www.simalliance.org/

http://www.symbian.com/

http://www.syncml.org/


Sociétés mentionnées :

[33] AvantGo [34] Microsoft

[35] NTT DoCoMo

[36] PalmOne & Pal m So urc e

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

Voir les sites web : http://www.palmone.com/ (société développant les terminaux) et http://www.palmsource.com/ (société développant les logiciels

[37] Sun Microsystems les documents Java (et ses différentes déclinaisons) sont disponibles sur http://java.sun.com/

http://www.avantgo.com/

http://www.microsoft.com/mobile/

http://www.nttdocomo.com/home

http://www.palmone.com/

http://www.palmsource.com/

http://java.sun.com/

Chapitre 10

Sécurité du système UMTS

Les spécifications UMTS sont conçues à bien des égards comme une évolution des spécifications des systèmes de deuxième génération. Dans le cas de la sécurité, le système GSM a servi de base mais des modifications importantes ont été apportées pour pallier les faiblesses découvertes à l'usage des systèmes de deuxième génération.

Par ailleurs, le système GSM et les systèmes de deuxième génération en général étaient centrés sur les services exclusifs de l'opérateur. L'approche « service ouvert » de la troisième génération oblige à revoir certains modèles de sécurité pour couvrir le partage de certaines applications et l'entrée de « fournisseurs de services » dans la chaîne des services.

10.1. Introduction

Les évolutions apportées à la sécurité pour l'UMTS sont basées sur une étude des risques et des problèmes connus lors du déploiement des réseaux de deuxième génération [21.133].

10.1.1. Exemples d'attaques sur un réseau mobile

Un réseau étant constitué d'un ensemble d'équipements informatiques, il est particulièrement sensible aux attaques. Dans le cas de l'UMTS, la vulnérabilité est

Chapitre rédigé par Paul JOLIVET.


renforcée par l'aspect immatériel de l'interface radio. Les différents scénarios d'attaques sont rassemblés en plusieurs types, selon que le pirate attaque :

- les communications des utilisateurs ; - le service lui-même pour l'utiliser ;

- le service pour l'empêcher de fonctionner (déni de service).

La figure 10.1. décrit les points sensibles dans la chaîne et les risques associés. 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 données d'authentification.

Figure 10.1. Exemples d'attaques sur un réseau mobile

Un dernier type d'attaque est celui du déni de service. Le pirate monopolise le réseau d'accès ou le bloque de façon à empêcher les abonnés d'accéder au service.

Un ensemble de mécanismes ont été spécifiés pour empêcher ou, plus modestement, rendre plus difficile les différents types d'attaques. Cependant, la sécurité n'est pas que l'affaire de protocoles mais aussi d'architecture et de gestion du réseau, en particulier pour les éléments devant être mis à jour ou reliés à des réseaux extérieurs.

10.1.2. Mécanismes de sécurité

Les services de sécurité sont généralement classifiés de la façon suivante

Sécurité du système UMTS 425

- l a confidentialité protège 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 prétend être ;

-l ' intégrité assure qu'un message est bien reçu tel qu'il a été émis sans changement ou duplication ;

- la non-répudiation empêche un émetteur de nier a posteriori qu'il a transmis un message effectivement émis ;

- le contrôle d'accès est la capacité de limiter l'accès à un équipement ;

- la disponibilité doit être garantie contre des attaques en nombre qui peuvent provoquer une réduction des performances du réseau.

Dans le cas de l'UMTS, les principaux mécanismes mis en œuvre sont les suivants :

- chiffrement de la signalisation et des données 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'intégrité ;

- authentification par le réseau du mobile ; - authentification par le mobile du réseau.

10.2 Principes de la sécurité en UMTS

Les changements apportés aux spécifications UMTS concernent bien évidemment les algorithmes utilisés qui tiennent compte des évolutions existantes. Par exemple, il est possible d'utiliser des clés de taille plus importante (jusqu'à 128 bits). Cependant, les améliorations ne s'arrêtent pas là. Elles portent également sur les points suivants :

- le renforcement de la sécurité au sein même du réseau cœur, alors que les efforts GSM étaient concentrés sur l'interface radio ;

- l'interconnexion de réseaux (mobile/fixe - circuit/paquet - 2G/3G - etc.) ; - l'intégrité de l'identité des terminaux (IMEI), spécifiée au commencement

même de la conception des spécifications alors qu'elle est intervenue en cours de vie pour le système GSM ;

- l'authentification mutuelle pour contrer l'attaque par une station de base pirate.

•


10.2.1. Les éléments matériels liés à la sécurité

La sécurité UMTS [33.102] est basée sur le principe de secrets partagés et d'algorithmes symétriques (c'est-à-dire que c'est le même mécanisme qui permet l'authentification de part et d'autre). Il convient donc de protéger aux mieux ces secrets en utilisant les principes suivants :

- les algorithmes utilisés peuvent être propriétaires ou partagés pour l'authentification et la génération de clés ; dans tous les cas, leur spécification n'est pas publiée ;

- les données secrètes sont stockées dans des bases de donnée sécurisées : l'UICC (carte à puce) du côté utilisateur et le centre d'authentification ou AuC {Authentication Centre) du côté réseau.

Le centre d'authentification est généralement représenté (et conçu) comme colocalisé avec l'enregistreur de localisation nominal (HLR, Home Location Register). Il n'en est pas moins totalement indépendant, même si les deux équipements communiquent dans le cadre d'une procédure d'inscription ou d'authentification.

10.2.2. Identité sur le réseau 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'opérateur MNC (Mobile Network Code) et un code librement attribué par l'opérateur : le MSIN (.Mobile Subscriber Identity Number). La taille du MSIN est variable au choix de l'opérateur. La définition 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'opérateurs (voir figure 10.2). L'IMSI ne dispose pas de marqueur de délimitation des données ; l'interprétation automatique de l'IMSI peut se révéler délicate pour la cœxistence entre anciennes cartes GSM d'un côté et les actuelles SIM (pour lesquelles 3 chiffres sont systématiquement alloués, le dernier étant fixé à « F » s'il n'est pas utilisé) et USIM.

Plusieurs mécanismes visent à protéger l'identité de l'utilisateur UMTS :

-l 'utilisation d'une identité temporaire TMSI (Temporary Mobile Subscriber Identity) attribuée par le réseau comme pour le GSM ; cette mesure n'est efficace que si le taux de rafraîchissement de l'identité temporaire est important ;


- l'authentification répétée de l'utilisateur, cette fonction est entièrement paramétrable par l'opérateur1 ;

- l e chiffrement (sur l'interface radio en particulier) des données, y compris l'identité de l'utilisateur et les mécanismes de vérification de la cohérence de la localisation.

Longueur IMSI

M N C 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 première mesure de protection est l'identification de l'utilisateur sur son terminal. Cette identification se présente de manière standard sous forme de la présentation d'un code PIN (Personal Identification Number). Cette opération est réalisée sur la carte à puce de la même manière que dans le système GSM ou le système bancaire. Le principe repose sur l'utilisation d'un code à 4 chiffres. Trois présentations successives erronées du code PIN entraînent un blocage de l'USIM. L'application peut alors être débloquée grâce à un code de déblocage à 8 chiffres. Dix présentations successives d'un code de déblocage erroné entraînent le blocage

1. On connaît le cas dans certains réseaux GSM, d'opérateurs (européens) qui renonçaient après son inscription à authentifier de nouveau l'utilisateur aux heures de pointe de manière à décharger le réseau de signalisation de cette tâche. Ils ont fait là un compromis entre coût de fraude et accessibilité au réseau.


définitif de l'USIM. Notons qu'il est impossible à quiconque d'accéder aux fichiers protégés sur une carte bloquée. Notons également que le mécanisme d'identification peut être désactivé par l'opérateur au moment de la personnalisation de la carte ou par l'utilisateur à tout moment.

Toute application (qu'elle soit basée sur la carte, le mobile ou le réseau) peut, comme l'USIM, disposer de procédures similaires d'identification.

10.2.4. Lignes directrices des algorithmes d'authentification

Comme dans le cas du système GSM, le 3GPP ne définit pas d'algorithme d'authentification mais le format des données d'entrée et de sortie de ces algorithmes [33.105]. Cette procédure étant toujours réalisée dans le réseau nominal de l'utilisateur (même dans le cas de l'itinérance), le standard n'est pas nécessaire, il pourrait au contraire constituer une faiblesse du système.

Fonction Type Nature Données d'entrée

Données en sortie Commentaire

fO Génération d'aléa RAND fl Fonction

d'authentification du réseau

K, SQN, RAND, AMF

MAC -

fl* message de resynchronisation MAC

f2 authentification de l'utilisateur

K, RAND, AMF

RES XRES ou RES selon que le calcul est fait dans l'AuC

ou l'UICC f3 clé de chiffrement

dérivée CK

f4 clé de calcul d'intégrité dérivée

IK

f5 clé anonyme de chiffrement dérivée

dérivation AK Optionnel

f5* message de resynchronisation (cas

de la clé anonyme)

AK Optionnel

Tableau 10.1. Les différentes fonctions de base de MILENAGE


Il existe toutefois des lignes directrices proposées par le 3GPP pour le choix d'algorithmes d'authentification. Les opérateurs sont à même de choisir des algorithmes définis par des groupes comme SAGE2 à l'ETSI ou encore de définir des algorithmes « propriétaires ».

La famille d'algorithmes d'authentification UMTS est nommée MILENAGE. L'algorithme doit pouvoir réaliser, en gardant impossible le calcul de la clé à partir du résultat, les 7 fonctions rassemblées dans le tableau 10.1.

Le synoptique complet du fonctionnement d'un algorithme MILENAGE est repris dans la figure 10.3. Les données sont les suivantes :

- OP est un champ opérateur des fonctions de MILENAGE ;

- OPc est une valeur dérivée de la clé K et fonction de l'opérateur (OP) ;

- les fonctions r sont des rotations ;

- c sont des constantes additionnées ;

- E est un algorithme de Rijndael3 ([DAR 00, DAR 01]).

RAND

fl f l * f5 f2 f3 f4 f5 *

Figure 10.3. Les différentes fonctions de MILENAGE Source 3GPP [31.909]

2. Security Algorithm Group of Experts (voir Annexe B). 3. Outre son efficacité, cet algorithme présente l'avantage d'être libre de droits.


10.2.5. Authentification en UMTS

L'authentification UMTS consiste en la comparaison du résultat d'un calcul effectué sur la carte d'une part et dans le centre d'authentification d'autre part. Cette fonction (schématisée dans la figure 10.4) est détaillée dans la suite du paragraphe.

UICC Réseau

RAND non prédictible

K

XRES

K

RES

Figure 10.4. Principe de l'authentification de l'abonné

Les fonctions d'authentification et la clé secrète K4 sont situées 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 côté comme de l'autre, l'accès est restreint et protégé : par exemple, il n'est pas possible d'envoyer une commande de lecture de la clé K à l'USIM. Les spécifications 3GPP mentionnent, sans les spécifier, les besoins de protection au cours des phases de transfert de données vers la carte et l'AuC. La clé secrète K qui est utilisée dans l'authentification est un aléa d'une taille de 128 bit au maximum. Sa génération comme son transfert vers la carte et le centre d'authentification (AuC) doivent être sécurisés.

4. Correspond au Ki du système GSM.


10.2.5.1. Authentification de l'abonné

L'authentification de l'abonné reprend le même principe que dans GSM : un algorithme d'authentification est utilisé pour calculer, à partir d'un nombre aléatoire RAND et de la clé K, un résultat. Le calcul est fait par le centre d'authentification et le résultat obtenu est nommé XRES (eXpected RESult). Le nombre aléatoire est envoyé à l'UICC qui calcule de la même façon un résultat nommé RES. Si XRES = RES (cas typique d'un abonné autorisé), l'abonné est authentifié. Sinon, toutes les demandes de services sont rejetées. L'algorithme d'authentification est un algorithme « à sens unique » : à partir de RAND et de la clé K, le calcul du résultat est très facile à faire. En revanche, il est très difficile de déduire 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 réseau. Un attaquant peut essayer de configurer une UICC avec une identité IMSI usurpée mais il ne peut connaître la clé K. Sans la clé K, il n'est pas possible de renvoyer le bon RES à une demande d'authentification et par conséquent d'utiliser le réseau.

10.2.5.2. Authentification mutuelle

Le système GSM utilisait seulement le mécanisme d'authentification du réseau. Le terminal n'authentifiait jamais le réseau. Une attaque possible était d'envoyer plusieurs centaines de milliers de RAND, de noter la valeur RES renvoyée par la carte SIM et d'en déduire la clé secrète. Pour contrer cette attaque, l'UMTS repose sur l'authentification mutuelle (c'est-à-dire du mobile par le réseau et du réseau par le mobile) et sur un mécanisme de compteur.

L'authentification du réseau repose sur les mêmes principes que l'authentification du mobile : le nombre aléatoire est le même (RAND), l'algorithme est différent mais du même type, le résultat 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 côté, à 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 réduire encore le risque de « fausse authentification », on utilise un principe de compteur. Un numéro de séquence (SQN, Sequence Number) est géré par le centre d'authentification. Ce numéro est modifié à chaque nouvelle authentification de manière déterministe. Il intervient dans le calcul du MAC. Ce numéro pourrait ne pas être transmis car la carte USIM et le centre d'authentification connaissent le contexte (c'est-à-dire le nombre d'authentifications précédentes) et peuvent le déduire. Pour éviter les problèmes désynchronisation, la valeur de SQN est


transmise sur la voie radio mais sous forme chiffrée, la clé étant calculée à partir de RAND et de K. Si le terminal détecte que le SQN envoyé par le réseau ne correspond pas au SQN attendu, il indique au réseau un problème de désynchronisation.

On utilise également en UMTS, un paramètre AMF (Authentication Management Field) qui permet, entre autres, de gérer 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. Intégrité des messages

Une des nouveautés de l'UMTS est l'utilisation de mécanismes de vérification de l'intégrité des messages. La solution utilisée est basée sur le calcul de MAC {Message Authentication Code) appliqué à chaque message transmis.


Une vérification de cohérence est également réalisée avec des numéros de séquence, de manière à éviter des fraudes par répétition des messages ou la réutilisation de matériel de chiffrement périmé (les clés en particulier).

La fonction f9 (proposée par KASUMI, voir paragraphe 10.2.7) permet de réaliser des calculs de MAC pour s'assurer de l'intégrité des messages de signalisation échangées dans le réseau. Ces messages peuvent par ailleurs être chiffrées. Elle dispose en données d'entrée :

- la clé d'intégrité IK (128 bits ou dans le cas d'une taille inférieure, la valeur de la clé complétée de 0) ;

- le message ;

- un compteur lié à une horloge (COUNT-I) ;

- un aléa (FRESH).

MESSAGE

MAC-I

Sender UE or RNC

MESSAGE

XMAC-I

Receiver UE or RNC

Figure 10.6. Principe de calcul de l'intégrité Source 3GPP [33.102]

La clé d'intégrité IK est calculée à partir du nombre aléatoire RAND, de la clé secrète K et de l'algorithme f4.

10.2.7. Chiffrement des données

A contrario de l'authentification, le chiffrement/déchiffrement d'informations doit pouvoir être réalisé hors du réseau nominal pour assurer l'itinérance. Le 3GPP définit donc un algorithme, embarqué dans tous les terminaux. Il est prévu pour sécuriser les données échangées entre le mobile et le serveur final, au-delà même du


simple lien radio comme le prévoyait le standard GSM. Le cahier des charges pour l'algorithme est le suivant :

-capable de calculer un MAC pour réaliser les contrôles d'intégrité des données ;

- pouvoir supporter un débit de données de 2 Mbit/s symétrique ;

- s ' i l envisagé d'utiliser des algorithmes secrets (comme pour le GSM), leur fiabilité ne devra pas être basée sur ce seul secret.

La clé de chiffrement CK est dérivée de la clé secrète K grâce à la fonction f3 (voir figure 10.7) de Millenage. Cette opération est réalisée pendant la phase d'authentification. Côté USIM, sous réserve que l'ensemble des calculs soient possibles, c'est-à-dire que le réseau et la séquence de l'authentification soient corrects, la valeur est stockée sur l'USIM, accessible pour utilisation, même si par la suite l'authentification devait être rejetée par le réseau.

CK

Figure 10.7. Principe de calcul d'une clé de chiffrement

Le groupe 3GPP/ETSI SAGE définit par ailleurs dans le rapport technique TR 33.901 [33.901] la procédure d'approbation d'un nouvel algorithme, qu'il soit existant ou défini pour l'UMTS.

L'algorithme retenu est « KASUMI ». Il est issu de l'algorithme japonais « MISTY5 » et permet de réaliser les fonctions de chiffrement et de vérification de l'intégrité des données, respectivement f8 et f9. Le synoptique de fonctionnement de KASUMI est détaillé sur la figure 10.93.

5. Défini par Mitsubishi, [35.201], [WMI].


Sender UE or RNC

Receiver RNC or UE

Figure 10.8. Principe de calcul des séquences de chiffrement Source 3GPP [33.102]

La fonction f8 permet de chiffrer un flot de données. Elle dispose en données d'entrée :

- la clé de chiffrement CK6 (Cyphering Key) sur 128 bits ou, dans le cas d'une taille inférieure, la valeur de la clé complétée de 0 ;

- un compteur lié à une horloge (COUNT) ; -l 'identité du médium de transmission, la même clé pouvant être utilisé sur

différent médias (BEARER) ; - la direction (DIRECTION) ; - la longueur du message (LENGTH).

Si le chiffrement est une priorité de la sécurité de l'UMTS, la plupart des pays ont limité récemment 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 clés de chiffrement est limitée à 56 bits dans le cas de l'export. Chaque pays peut, dans le cadre national, avoir des dispositions propres (autorisation ou contrôle) concernant l'utilisation de clés de plus grande taille. Ces dispositions ne concernent pas le calcul de MAC pour le contrôle d'intégrité.

6. Equivalent du Kc dans le système GSM.


Le système 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 clés.

10.2.8. Aspects protocolaires

10.2.8.1. Qui n tupi et de sécurité

Pour permettre à un équipement d'un réseau de réaliser l'authentification mutuelle et d'assurer l'intégrité et le chiffrement, il est nécessaire et suffisant qu'il dispose des informations suivantes :

- le nombre aléatoire RAND choisi par le centre d'authentification ; - le jeton d'authentification AUTN comprenant le MAC, résultat du calcul

d'authentification du réseau ; - le résultat SRES de l'authentification du mobile ; - la clé IK servant au mécanisme d'intégrité ; - la clé de chiffrement CK.

L'ensemble de ces 5 données est appelé quintuplet de sécurité. Le quintuplet est formé par le centre d'authentification de l'opérateur d'un abonné. Il peut être fourni à tout VLR du réseau, voire à un VLR d'un autre réseau. Les fonctions de sécurité peuvent alors être assurées de façon autonome par le VLR sans connaître les clés propres à l'abonné, ni les algorithmes spécifiques à l'opérateur de cet abonné.

10.2.8.2. Echange de messages

Les échanges protocolaires entre éléments du réseau sont représentés dans la figure 10.9, l'exemple donné s'insère dans la procédure d'inscription au réseau. Dans ce cas, la requête est à l'initiative du mobile qui cherche à s'inscrire. Le VLR demande des quintuplets au centre d'authentification (supposé intégré dans le HLR dans la figure). Plusieurs quintuplets peuvent être transmis dans un même message.

Une authentification peut également, de manière optionnelle, être réalisée à la demande du réseau, de manière périodique ou aléatoire pour limiter les fraudes. La figure 10.10 représente l'échange simple qui caractérise cette re-authentification.

Pendant toute la durée de l'utilisation du réseau, des identités temporaires sont utilisées (TMSI, Temporary Mobile Subscriber Identity) de façon à limiter le risque d'interception de l'identité unique (IMSI). Le TMSI est alloué par le réseau (voir figure 10.11) et il est spécifique au VLR (Visitor Location Register), l'enregistreur


de localisation visiteur7. Un utilisateur change régulièrement de TMSI selon les paramètres de l'opérateur.

Figure 10.9. Principe de l'authentification UMTS cas de l'inscription du mobile au réseau

Figure 10.10. Réauthentification à l'initiative du réseau

7 Notons que le terme peut prêter à confusion. Un utilisateur est toujours « visiteur », c'est-à-dire inscrit dans un VLR. Le HLR ou enregistreur de localisation nominal est une base de données centrale de l'opérateur.


Figure 10.11. Principe de l'allocation d'identité temporaire (TMSI)

10.3. Les attaques possibles - Les protections

10.3.1. Parades - Protection

Les mécanismes supplémentaires suivants ont été mis en place pour protéger les messages de signalisation des attaques (écoute et/ou interception) :

- authentification (voir 10.2) ; - vérification de l'intégrité par un calcul de MAC (voir 10.2) ; - vérification de cohérence sur l'information de localisation ; - réinitialisation du chiffrement en cours de communication s'il n'est pas utilisé

ou si son utilisation a été interrompue ; - mise en place d'un mécanisme anti-répétition.

La protection contre une interception qui relaye les messages sur l'interface radio est par contre plus délicate, comme toute attaque radio. Les données et les identités sont protégées par chiffrement dans ce cas.

10.4. UICC et AuC, clé de voûte du système

L'utilisation d'une carte à puce permet de sécuriser l'accès à des données sensibles au premier rang desquelles la clé individuelle K de l'utilisateur.

Le chargement d'applications comme l'accès par différentes applications aux données de la carte est défini par des procédures. Les spécifications 3GPP mettent en évidence l'importance de la sécurité dans la gestion des clés.


Par ailleurs, tout est conçu pour réduire la réutilisation des données hors de leur contexte d'origine. L'IMSI par exemple n'est normalement pas utilisé comme identifiant dans le cadre de sessions IP Multimédia ou WLAN.

10.4.1. Sécurité et carte à puce

La carte à puce a trois avantages

- structure sécurisée et personnalisée ;

- propriété de l'opérateur ;

- portabilité de l'information.

Le stockage d'informations dans une carte à puce, élément indépendant du terminal, permet un haut niveau de sécurisation. Selon les niveaux d'accès, les données sensibles (comme une clé individuelle) peuvent être rendues complètement invisibles de l'extérieur, ne pouvant être utilisées que par un exécutable lui-même installé sur la carte. Depuis l'origine des cartes, le seul piratage connu provient de la reconstitution de données à partir du résultat des calculs de la carte, mais en aucun cas de la lecture des données protégées.

Une autre force de la carte à puce réside 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 métier de la personnalisation de chacune de leurs cartes dans un environnement sécurisé qui a fait ses preuves pour le domaine bancaire. Chaque carte qui sort de production peut être identifiée par son numéro de série et comporter un jeu de données uniques (clés, identifiants, etc.) en fonction des vœux de l'opérateur.

L'opérateur est particulièrement sensible à la sécurité de ces données qui permettent l'accès au réseau et aux services. A ce titre, il est rassuré de disposer de ces informations sur un support qui lui appartient8 et dont il maîtrise complètement la production.

Pour finir, la carte à puce permettra facilement à un utilisateur de changer de terminal et de retrouver sur le nouveau terminal le même accès au réseau et aux services, sous réserve bien entendu que le terminal supporte ces services.

8. Dans le domaine des télécommunications mobiles comme dans le domaine bancaire, la carte à puce reste la propriété de l'émetteur et non de son utilisateur.


10.4.2. UICC et USIM

Une évolution importante en troisième génération est la création d'une plate-forme commune pour les cartes à puce. Cette plate-forme est définie 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 système GSM qui reste la plus répandue des applications sur carte à puce du marché.

Figure 10.12. Architecture d'une UICC

Le 3GPP et le 3GPP2 basent aujourd'hui les applications carte sur cette plate-forme : SIM et USIM pour le 3GPP, R-UIM pour le 3GPP2. Ces applications sont indépendantes, même si dans certains cas (l'annuaire utilisateur - ou Phone Book) des données peuvent être partagées.

D'autres comités ont créé des applications compatibles avec l'UICC, à l'instar du WAP Forum (OMA depuis 2002) avec son application de sécurité : la WIM (WAP Identity Module). Le domaine bancaire tarde encore à s'inscrire dans cette dynamique, mais le problème reste moins technique que politique.

10.4.3. Utilisation « de base »

La première utilisation de l'UICC dans le cadre de l'UMTS, c'est l'USIM et bien entendu la SIM héritage du GSM. Ces applications, avec chacune leur niveau de sécurité spécifique permettent au système de réaliser authentification et chiffrement.


L'authentification est réalisée en local dans la carte avec les données fournies par le réseau (l'aléa RAND, voir paragraphe 10.2.5). L'algorithme d'authentification est exécuté en local dans l'UICC pour éviter un échange de clé avec le terminal. Le résultat est retourné au réseau (au travers du mobile) pour contrôle.

Le chiffrement, par contre, demande des ressources que la carte à puce ne peut encore fournir. Il est donc encore réalisé par le terminal, grâce à des données (dont la clé CK de session) calculées par l'UICC. Les limitations qui empêchent de faire le chiffrement à l'intérieur de la carte sont :

- le débit de l'interface carte-terminal (maximum 400 kbits/s en Release 6) ; - le duplex à l'alternat (pas d'émission et de réception simultanée sur

l'interface), jusqu'à la Release 6 tout au moins ; - la capacité de calcul de la carte, encore trop faible pour réaliser des encryptions

importantes à la volée.

Des applications de streaming au travers de l'UICC sont considérées pour les Release 7 ou 8 (pas avant l'horizon 2006/2007 pour la disponibilité des spécifications), où des données pourraient être déchiffrées au vol sur la carte. Il est question dans ce cadre d'utiliser de nouveaux protocoles en parallèle à ceux utilisés actuellement. L'USB et les protocoles utilisés dans les cartes de mémoire de masse (de type MMC) sont sur les rangs des candidats possibles.

10.4.4. Sécurité et IP Multimedia

Dans le cadre de la sécurité du réseau IP Multimedia (IMS, IP Multimedia Subsystem), plusieurs approches ont été étudiées. La réutilisation des applications SIM et USIM est possible pour l'authentification et la génération de clés, il est néanmoins clair que la réutilisation des mêmes mécanismes et clés risque de fragiliser la protection de ces données. Un nouveau système est donc préféré, basé sur une nouvelle application : ISIM [31.103] (IMS SIM). Cette application est la pure transposition de l'USIM dans le cadre de IMS : mêmes structures, mêmes fonctions, mais des clés et des identifiants dédiés.

Outre l'avantage de ne pas utiliser sur plusieurs réseaux les mêmes données, l'existence d'une ISIM permet d'imaginer pour le futur des cartes UICC avec cette seule application pour accéder le réseau IMS d'un fournisseur de services qui n'opérerait que cette technologie.


10.4.5. Sécurité et service de diffusion multimédia (MBMS)

Le service multimédia de diffusion ou de multipoint (MBMS, Multimedia Broadcast/Multicast Service) est décrit en Rel-6. Son principe repose sur la diffusion d'information cryptée d'éléments multimédia (à la manière d'une chaîne de télévision cryptée) auxquels les utilisateurs accèdent par des services d'abonnement. La diffusion peut être générale ou concerner un groupe d'utilisateurs particulier (multipoint). Le besoin en sécurité est évident pour la gestion même de ce service en accès restreint. L'architecture décrite repose sur l'utilisation de l'USlM et de nouvelles données.

L'architecture de sécurité est basé sur des clés/algorithmes symétriques. Le jeu de clés comprend :

- MUK (MBMS User Key), la clé secrète individuelle de l'utilisateur ;

- M R K (MBMS Request Key) qui permet d'authentifier l'utilisateur demandant des informations au serveur ;

- MSK (MBMS Service Key), qui permet d'accéder au service, cette clé est fournie par le serveur et encryptée par MUK ;

- MTK (MBMS Traffic Key), qui permet de décrypter les données reçues dans le mobile.

Les clés MSK et MTK sont allouées par le fournisseur de services selon le type d'usage : accès ponctuel ou abonnement à long terme au service. L'allocation peut venir d'une requête de l'utilisateur (figure 10.13) ou d'une allocation par le serveur (figure 10.14), soit en modepush, soit en provoquant une requête de la part du terminal.

Figure 10.13. Allocation d'une clé de service à l'initiative du terminal (de l'utilisateur)


voir requête par le terminal

Figure 10.14. Allocation d'une clé de service à l'initiative du réseau (par push ou en provoquant la requête du terminal -pull-)

Selon les implémentations, MUK et MSK peuvent être stockées sur l'UICC pour assurer une meilleure sécurité d'accès et d'utilisation de ces clés. L'authentification d'un utilisateur et l'autorisation d'accès à un service se fait dans une connexion point à point reposant sur l'authentification par HTTP Digest. La procédure peut être initiée par le réseau comme par l'utilisateur.

10.4.6. Sécurité et appels de groupe ( VGCS)

Le service d'appel de groupe (VGCS, Voice Group Call Service) utilise également l'USIM pour ses besoins de sécurité. Un fichier de l'USIM permet de définir les identifiants de groupe d'utilisateurs autorisés. Au moment de l'authentification, l'identifiant est vérifié et la clé VGCS dérivée à partir de cet identifiant pour obtenir une clé de session ( VGCS Short Term Key).

Les procédures d'authentification VGCS donnent aussi la possibilité de spécifier l'algorithme utilisé pour le chiffrement, opération possible uniquement avec une USIM, la SIM ne peut être mis à jour dans ce sens.


10.4.7. Sécurité et I-WLAN

L'UICC est utilisée également pour l'accès au WLAN dans le cas particulier de l'interconnexion 3GPP/WLAN (I-WLAN). Il s'agit d'utiliser la sécurité UMTS dans le cadre du protocole standard utilisé en WLAN : EAP (Extensible Authentication Protocol). L'authentification est transportée de manière standard sur les protocoles Radius ou Diameter jusqu'au serveur AAA (Authentication Authorisation Accounting). L'authentification est généralement basée 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 sécurité, l'utilisation d'identités temporaires est conseillée, même si pour des raisons pratiques, il n'est pas exclu d'utiliser l'IMSI comme identifiant. Une procédure de réauthentification est ajoutée et l'UICC peut générer des clés à chaque reprise.


10.4.8. Sécurité et terminal réparti entre plusieurs périphériques

Dans le cadre de la répartition des fonctions dans différents TE (Terminal Equipment, voir figure 9.1), le problème de l'authentification prend une nouvelle dimension. Il devient important qu'un élément distant de l'équipement mobile (au sens ME, Mobile Equipement) puisse disposer d'éléments de sécurité contenus ou générés par l'USIM. Il faut donc disposer de procédures pour transmettre du ME vers des TE distants9 les informations nécessaires à leur fonctionnement. Cette transmission peut se faire sur des médias locaux parmi lesquels : Bluetooth, WLAN ou IrdA.

Si le besoin de sécurité dans cette configuration est établi, le travail de spécification dépasse le cadre de la Release 6. Une étude de faisabilité existe [TR 33.817], elle décrit les cas d'utilisation et les obstacles principaux à la mise en place de solutions. Le principal frein à l'implémentation de ce type d'architecture est la fragilité du transfert de matériel de sécurité au travers de médias dont le modèle de sécurité repose en partie sur la faible distance d'émission.

10.5. Applications et sécurité

10.5.1. Interfonctionnement des applications et pare-feu

Les applications spécifiées au 3GPP sont conçues dans certains cas pour communiquer entre elles via des procédures ou un protocole définis. Dans tous les autres cas, elles sont protégées les unes des autres par des systèmes de pare-feu, généralement gérés par les environnements applicatifs, Java ou Symbian par exemple.

Dans le cas des autres applications, la sécurité repose en particulier sur la certification de ces applications. Le problème est d'autant plus important que les applications résident sur des éléments sensibles comme l'UICC. Il revient à l'opérateur (ou au fournisseur de service propriétaire de l'application) de certifier les applications pour éviter le téléchargement de virus par exemple.

La gestion de conditions d'accès 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 sécurité a été définie. Il s'agit en fait de créer un espace où plusieurs intervenants peuvent charger des applications en confiance les uns avec les autres. Cet espace est muni de différents niveaux de conditions d'accès 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 données au travers du mobile en question.


L'interaction entre applications est définie dans un cadre strict et en exploitant les protocoles et commandes existants. Des applets Java par exemple peuvent être réparties entre le mobile et l'UICC pour exploiter les fonctions de ces éléments au mieux. Dans ce cas particulier, une spécification développée par le Java Community Process donne les règles et les limites de l'interaction dans un document : le JSR 177 [JSR 177].

10.5.2. Téléchargement d 'applications

Le principe des domaines de sécurité s'applique évidemment également au téléchargement d'applications. Il est compatible avec les architectures d'infrastructure à clé publique (PKI, Public Key Infrastructure).

Plusieurs questions se posent néanmoins pour la mise en place de téléchargement 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'accès à de nouvelles sources. Ce secret est généralement géré par le propriétaire de la carte, l'opérateur a priori ;

- la certification des applications pour le chargement sur une plate-forme qui verra coexister simultanément ces applications, au risque qu'un cheval de Troie soit introduit. Le propriétaire de la carte à qui l'utilisateur est susceptible de se plaindre en cas de problème, est forcément tenté de considérer, au-delà de l'utilisation de firewall et autres protections, un processus d'examen des données chargées sur le terminal ;

- la présence d'un tiers de confiance (Trusted Third Party) qui pourrait gérer la sécurité des échanges pour l'opérateur, l'utilisateur et tous les fournisseurs. Si la fonction existe déjà dans le domaine des transactions financières, ce n'est pas encore le cas pour le chargement d'applications.

Le téléchargement reste un sujet sensible et encore réservé à l'usage de l'opérateur. La coexistence avec des fournisseurs de services est envisagée avec prudence, même si côté implémentation, les solutions existent. Le sujet remet périodiquement au centre des débats deux points cruciaux :

- qui est propriétaire de la carte ? Un opérateur est-il prêt à mettre une USIM sur une UICC qui ne lui appartient pas, qui plus est si cette UICC est susceptible d'héberger par ailleurs une USIM d'un autre opérateur ;

- qui est responsable en cas de vol, perte ou fraude à partir d'une carte multi-propriétaires ?


10.6. Roaming et sécurité

10.6.1. Accès aux données de sécurité

L'itinérance repose sur des accords entre opérateurs. L'interconnexion des réseaux pose évidemment des problèmes de sécurité, qui peuvent être traités comme toute interconnexion de réseau. Notons tout de même pour le cas de l'itinérance que :

- les calculs d'authentification sont toujours réalisés dans le réseau nominal d'un côté et dans le terminal de l'autre. Ils peuvent donc reposer sur des algorithmes propriétaires, seul le format des données d'entrée et sortie étant standards ;

- le chiffrement est lui uniquement réalisé dans le réseau visité. Il repose donc sur l'utilisation d'algorithmes standards.

Dans ces conditions, les données véhiculées au travers des réseaux sont (sauf l'identité de l'utilisateur) des données temporaires ce qui réduit considérablement le risque de piratage sur un réseau visité.

10.6.2. Accès à de multiples réseaux i

Si l'UICC est conçu pour supporter plusieurs applications susceptibles de fonctionner simultanément, le 3GPP spécifie clairement qu'il n'est pas question d'utiliser simultanément 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 prévu la possibilité pour un utilisateur UMTS de s'authentifier au travers d'un réseau qui ne supporte pas les fonctionnalités 3G. Il définit 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 (clés 3G).


10.6.4. Roaming 2 G/3 G, authentification et chiffrement

Dans le cas du roaming 2G/3G, le niveau de sécurité employé est celui autorisé par la carte UICC présente dans le mobile.

De nombreux opérateurs ont manifesté de la réticence à accorder la possibilité à des USIM de générer du matériel d'authentification 2G par dérivation (voir ci-dessus). La TS 31.102 décrit la possibilité (optionnelle) pour une USIM de générer du matériel d'authentification 2G de telle manière qu'un mobile s'inscrive dans un réseau GSM.

Le réseau 3G peut supporter l'authentification 2G, auquel cas le HLR doit comporter les fonctions de conversion c2 et c3 (qui permet la conversion des clés d'authentification 3G en 2G) ou le processus 2G complet.

10.7. Interception légale

L'interception légale des communications est au croisement des considérations de sécurité et du droit des individus à une vie privée. La plupart des pays se sont dotés d'une réglementation dans le domaine. L'approche dans cette section est plus particulièrement tournée sur l'Europe.

10.7.1. Les résolutions île la Communauté Européenne

La première résolution prise sur le sujet par la Communauté Européenne a été publiée en novembre 1996 (96/C 329/01). Cette résolution reconnaît le droit des Etats à intercepter des communications dans le cadre de la sécurité nationale ou d'enquêtes particulières.

Les besoins suivants sont mis en évidence par la CE :

- l'accès à l'ensemble des données transmises ou à transmettre depuis ou vers un abonné ou numéro d'identifiant de façon temporaire ou permanente dans le réseau de télécommunications, en déroutant les appels vers d'autres réseaux ou terminaux, même si l'appel traverse plus d'un réseau (par exemple de plusieurs opérateurs) ;

- l ' accès à l'ensemble des données reliées à l'appel dont la signalisation, l'identité de l'appelé et de l'appelant (même dans le cas d'appel en échec), toute information émise, les informations concernant la communication (date, durée, renvois, etc.), l'information de localisation connue par le réseau, l'information sur les services et paramètres spécifiques de l'utilisateur ;


- la possibilité de surveillance en temps réel (ou, dans les cas où l'information n'est pas disponible, en fin d'appel) ;

- une ou plusieurs interfaces pour les systèmes de surveillance des services officiels (définies en accord entre les opérateurs d'un pays et les autorités en charge de l'interception), les données et le contenu de l'appel devant être délivrée en clair si la communication est cryptée.

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 autorités en charge de l'interception peuvent définir une qualité de service. L'assistance de l'opérateur peut être requise pendant l'interception selon les dispositions de chaque pays. La mise en place d'une interception doit pouvoir être réalisé dans de courts délais (en minutes ou heures). Les données interceptées doivent être sécurisés contre toute autre utilisation que celle des autorités en charge. Enfin, l'éventualité de plusieurs interceptions simultanées ou de plusieurs autorités en charge de l'interception doit être considérée par les opérateurs.

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é publiées pour commentaire pour une période de plusieurs mois. La plupart des commentaires sont venus des industries des télécommunications et de l'Internet.

Le besoin d'interception est reconnu et la mise à jour des dispositions est discutée. Les principaux changements concernent :

- la complexité du système qui peut concerner plusieurs réseaux interconnectés ; - la cohérence avec la politique existante de protection des données (en

particulier pour le cas des informations médicales) ;

- le respect de la Convention Européenne des Droits de l'Homme ; - la séparation des contenus et des paramètres de chiffrement le cas échéant.

S'il y a un accord sur le besoin, le problème est plus de savoir comment doit se faire la répartition du coût de l'implémentation. Les conclusions suivantes sont tirées :

- les définitions fonctionnelles sont spécifiées et rendues indépendantes des technologies ;

- les demandes ne doivent pas représenter un frein au travail ;


- l'expertise doit être également développée par les autorités, les opérateurs 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 dédié à la sécurité : SEC (Security). Il gère et coordonne l'ensemble des aspects liés à la standardisation de la sécurité pour l'ETSI. Ce groupe est en charge des aspects techniques et légaux. Il génère un ensemble de documents (ETSI Security Standards Policy) de façon à donner à l'ensemble des spécifications ETSI une approche cohérente. Il a produit 7 documents (références [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 légale pour l'ETSI en préparant des rapports et spécifications ;

- créer des standards génériques pour l'interception légale ; - être en relation avec l'ensemble des groupes (internes à l'ETSI ou extérieurs)

en charge d'interception légale 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 sécurité de manière générale au sein du 3GPP. Le but de ce groupe est de fournir au moins le même niveau de sécurité que celui procuré dans le système GSM en particulier ou dans les systèmes de 2e génération en général.

Ce groupe de travail dispose également d'un sous-groupe dédié à l'interception légale 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 réseau UMTS, comme par exemple la messagerie multimédia (MMS, Mobile Multimedia Service) ou encore les appels de groupes (VGCS, Voice Group Call Service).


10.8. Protection du réseau UMTS

10.8.1. Le réseau nominal

La sécurité n'est pas uniquement l'affaire de protocoles et de clés. Il s'agit également de sécuriser l'accès aux différents éléments du réseau par le personnel même de l'opérateur. Les spécifications 3GPP mentionnent un certain nombre de règles. Ces règles sont supposées être les bases de fonctionnement. Elles régissent l'accès aux sites d'hébergement du matériel et l'accès et la manipulation des données sensibles.

10.8.2. Les éléments du réseau- interfaces

Le contrôle d'accès aux différents éléments du réseau est capital pour la protection des données. Les interfaces et les accès distants (pour maintenance ou mise à jour) sont considérés comme des point sensibles.

10.8.2.1. Home Location Régis ter - HLR

Le HLR est un des éléments sensibles du réseau, il est le point de gestion des données qui sont envoyées au système de facturation. C'est également l'élément du réseau où est géré l'accès pour l'utilisateur aux différents services de l'opérateur.

L'accès à distance à cet élément du réseau doit être particulièrement contrôlé. La sécurité ne saurait être uniquement basée sur le développement d'une interface propriétaire. Cette solution ne saurait d'ailleurs protéger les attaques des employés mêmes de l'opérateur. Des propositions sont faites pour que l'accès soit réalisé sur la base de profils d'utilisateur donnant certains droits d'accès. Il est par ailleurs conseillé de limiter le nombre d'accès comme les différents protocoles pour ne pas multiplier les risques d'attaques.

10.8.2.2. Authentication Centre - AuC

Le point le plus sensible dans le réseau est certainement le centre d'authentification : AuC {Authentication Centre). Les données confidentielles concernant l'abonné (identité, clé et services correspondants) y sont stockées. L'attaque d'un AuC peut permettre à un pirate de cloner des utilisateurs existants ou d'en introduire de nouveaux.

La première sécurité consiste à limiter le nombre de personnes ayant effectivement accès à cet élément.


Il est par ailleurs conseillé de physiquement séparer l'AuC des HLR, même s'il faut bien constater que les fabricants comme les opérateurs ne sont pas forcément motivés par l'idée de multiplier les éléments dans le réseau. Un compromis peut être de séparer les lieux de stockage (disques durs) et de multiplier les systèmes « pare-feu » dans les HLR-AuC. Notons que la séparation physique HLR-AuC ajoute une interface, donc un point sensible, entre ces deux éléments : un pirate pourrait effectivement tenter une attaque en multipliant les demandes de quintuplets d'authentification (voir paragraphe 10.2.5 sur les procédures d'authentification) pour calculer la clé K d'un utilisateur.

Pour finir, les données de l'AuC seront d'autant plus sécurisées qu'elles seront cryptées. L'algorithme est laissé au choix de l'opérateur, comme d'ailleurs la taille des clés de chiffrement (l'élément étant isolé, il ne tombe pas sous le coup des textes de réglementation sur la taille des clés de chiffrement). Dans le cas du chiffrement, la protection de la clé de chiffrement et de l'algorithme entre bien entendu dans les mêmes considérations de sécurité.

10.8.2.3. Mobile Switching Centre - MSC

Le commutateur est un point clé de communication du réseau. Les appels y transitent comme la signalisation qui leur est associée. Des données confidentielles y sont traitées, elles sont pour certaines cryptées. Une attaque sur cet élément du réseau peut causer la perte ou le vol d'information concernant les utilisateurs du réseau.

Il est d'usage de restreindre le nombre d'accès aux commutateurs, tant en ce qui concerne le nombre physique de ces accès que le nombre de personnes ayant les droits d'accès. Il est d'ailleurs fréquent que le lieu même d'hébergement des commutateurs soit considéré comme une donnée sensible et confidentielle.

Dans le cas de la colocalisation de plusieurs commutateurs, il est d'ordinaire conseillé que l'ensemble des accès (interfaces, alimentation, accès logiques, etc.) soient complètement distincts.

10.8.2.4. Interfaces du réseau

Les points les plus sensibles aux attaques dans un réseau sont les interfaces entre les différents éléments de ce réseau. Cela est d'autant plus vérifié que l'interface est sans fil. Les protocoles comme les implémentations des réseaux sont en général prévus de manière redondante de façon à pouvoir remplacer une interface défaillante ou suspecte à tout moment.


10.8.2.5. Les systèmes de facturation et de gestion des utilisateurs

Les systèmes de facturation et de gestion des utilisateurs permettent aux opérateurs de facturer les services consommés par l'utilisateur. Il a été constaté que cette partie du réseau est d'autant plus sensible qu'elle est souvent sous-traitée par l'opérateur ou gérée au sein même de l'opérateur par des personnes extérieures ou temporairement employées.

Différents types d'attaques peuvent être organisés contre le système de facturation ou de gestion des abonnés, de manière à supprimer tout ou partie de factures, appliquer des remises ou changer la nature du service facturé.

Il revient aux opérateurs de gérer la sécurité des données de facturation. Ce domaine propriétaire reste extérieur aux considérations 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 mêmes personnes.

10.8.2.6. L 'interconnexion de réseaux - la maintenance

La gestion des éléments du réseau UMTS doit pouvoir être réalisée à distance. Ce type d'opération est souvent réalisé à partir du réseau informatique de l'opérateur, ce qui peut aussi représenter un risque significatif. La sécurité du réseau UMTS sera d'autant meilleure que celle du réseau de l'opérateur sera importante.

Il faut pourtant également considérer : - la séparation, au moins logique, des éléments du réseau UMTS : les accès ne

doivent pas être cumulés sur une machine ou par une personne ; différents niveaux d'accès aux ressources doivent être prévus ;

- les accès à distance doivent être sécurisés contre l'écoute et les attaques (le réseau informatique de l'opérateur peut comporter pour cela des « zones » isolées, l'accès est soumis à des contrôles d'accès systématiques), les mots de passe doivent être stockés dans des zones sécurisées, répondre à des règles précises et être conjugués à un blocage des ressources en cas de tentatives successives infructueuses d'accès, un historique détaillé des accès doit être tenu, des systèmes de déconnexion automatique (en cas de timeout, de coupure électrique, etc.) ou manuels (fin de session) sont impératifs, en cas d'accès via un autre réseau un système de mot de passe à usage unique est le plus sûr, la localisation même des accès physiques est une information sensible

Une fonction d'administration sécurité doit exister pour gérer l'ensemble des données relatives aux accès du réseau UMTS. Cette fonction doit pour des raisons


de sécurité être clairement séparée de la gestion de réseau UMTS en lui-même. L'administrateur doit pouvoir suivre en temps réel l'activité sur les éléments du réseau de chaque utilisateur.

10.9. Conclusion

La sécurité du système UMTS a nettement évolué par rapport aux systèmes de deuxième génération, tout en conservant l'élément clé du GSM qu'est l'utilisation d'une carte à puce pour l'authentification et la génération de clés. La solidité du système est renforcée grâce aux progrès des technologies et des techniques de cryptographie. La collaboration entre les pays permet par ailleurs de fixer les règles de la sécurité et de la vie privée.

Ces évolutions importantes ont permis de contrebalancer la fragilité croissante de systèmes 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 sécurité, l'introduction de systèmes plus ouverts au sein desquels l'opérateur n'est plus le seul fournisseur de services et l'interconnexion de réseaux différents sont introduits en troisième génération de manière sécurisée.

La quatrième génération qui s'annonce comme la convergence de multiples réseaux et le passage à des systèmes encore plus ouverts, imposera un fort challenge à la sécurité.

10.10 Annexe : Références

Note : au sein du 3GPP, les spécifications (TS, Technical Spécifications) 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 spécifications ou de leur conséquences, soit qu'il s'agisse d'une étude de faisabilité.

10.10.1. Bibliographie

[DAR 00] DAEMEN J., RIJMEN V., « The Block Cipher Rijndael » Smart Card Research and Applications, LNCS 1820, J.-J. Quisquater et B. Schneier (dir.)., Springer-Verlag, p. 288-296, 2000.

[DAR 01] DAEMEN J., RUMEN V., « Rijndael, the advanced encryption standard » Dr. Dobb 's Journal, vol. 26, n° 3, p. 137-139, 2001.


10.10.2. Spécifications - Standards

Documents maintenus par le 3GPP

[21.133] TS 21.133

[31.103] TS 31.103

[33.102] TS 33.102

[33.105] TS 33.105

[33.106] TS 33.106/7/8

[33.120] TS 33.120

[33.203] TS 33.203

[33.220] TS 33.220/1/2

[33.234] TS 33.234

[33.246] TS 33.246

[33.817] TR 33.817

[33.900] TR 33.900

[33.901] TR 33.901

[33.902] TR 33.902

[33.903] TR 33.903

[33.909] TR 33.909

[33.919] TR 33.919

3G Security; Security Threats and Requirements

ISIM Characterstics 3G Security; Security Architecture

3G Security; Cryptographie Algorithms requirements

Lawful interception: requi rement architecture and functions interface between core network and law agency

equipment 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 Génération Security Criteria for cryptographie algorithm design process Formai Analysis of the 3G Authentication Protocol General Report on the Design, Spécification 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 Authentication and Key Génération Functions Generic Authentication Architecture (GAA);


[35.201] TS 35.201/2/3/4/5/9

[35.209] TS 35.209

TS 41.033 [41.033] TS 42.033

TS 43.033

Documents maintenus par l'ETSI

[LI1] TS 101 331

[LI2] TS 101 671

[LI3]

[LI4]

[LES]

[LI6]

TR 101 876

TR 101 943

TR 101 944

ES 201 158

System Description Spécification of the 3GPP Confidentiality and

Integrity Algorithms: Document 1 : f8 and f9 spécifications Document 2: KASUMI algorithm spécification implementor's test data Design test conformance data MILENAGE spécification example algorithm set for f l , fl*, f2, f3, f4, £5 and

f5* Spécification of the 3GPP Confidentiality and

Integrity Algorithms Lawful Interception requirements for GSM Lawful Interception; Stage 1 Lawful Interception ; Stage 2

Télécommunications security; Lawful Interception (LI); Handover interface for the lawful interception of télécommunications traffic

Télécommunications security; Lawful interception (LI) Handover interface for the lawful interception of télécommunications traffic

Télécommunications security; Lawful Interception (LI); Description ofGPRS HI3

Télécommunications security; Lawful Interception (LI); Concepts of Interception in a Generic Network Architecture

Télécommunications security; Lawful Interception (LI); Issues on IP Interception

Télécommunications security; Lawful Interception (LI); Requirements for network fonctions


Télécommunications security; Lawful Interception (LI);

[LI7] ES 201 671 Handover interface for the lawful interception of télécommunications traffic

Autres documents

r j g^ j ^ Ce document géré par le Java Community Process, voir

J S R 1 7 7 http://jcp.org/en/jsr/detail7id =177

10.10.3. Sites Internet

[W3G]

[WET]

[WGA]

[WGP]

[WMI]

[WSA]

[WOM]

[WAS]

3GPP

ETSI

GSM Association

GlobalPlatform

Mitsubishi

SIM Alliance

Open Mobile Alliance

Wassenaar arrangement

http://www.3gpp.org/ http://www.etsi.org/ http ://portal.etsi.org/Portal_Common/home.as

p (accès au pages du groupe SAGE par exemple)

http ://www.gsmworld.com/

http://www.globalplatform.org/ Accès aux informations concernant MISTY

http ://www.mitsubishi.com/ ghp J apan/m isty/index .htm

http://www.simalliance.org

http://www.openmobilealliance.org les spécifications WAP/OMA sont disponibles

à http://www.wapforum.org/ what/technical.htm

http://www.wassenaar.org/

http://jcp.org/en/jsr/detail7id


http://www.etsi.org/

http://www.gsmworld.com/

http://www.globalplatform.org/

http://www.mitsubishi.com/

http://www.simalliance.org

http://www.openmobilealliance.org

http://www.wapforum.org/

http://www.wassenaar.org/

Glossaire

3G Réseau cellulaire de 3e Génération 3G-GGSN GGSN spécifique à l'UMTS 3GPP 3rd Génération Partnership Project 3GPP2 3rd Génération Partnership Project 2 3G-SGSN SGSN spécifique à l'UMTS 8PSK 8 Phase Shift Keying

AAL ATM Adaptation Layer AD Adjunct Adjunct AES Advanced Encryption Standard AF Assured Forwarding AHP Amplificateur Haute Puissance AI Acquisition Indicator AICH Acquisition Indicator Channel AKA Authentication and Key Agreement ALCAP Access Link Control Application Part AMD Acknowledged Mode Data (mode du protocole RLC) ANM Answer Message AP Access Preamble AP-AICH Access Preamble Acquisition Indicator Channel API Access Preamble Indicator API Application Programming Interface APN Access Point Name ARQ Automatic Repeat reQuest AS Access Stratum (contexte UTRAN) AS Application Server ASN.l Abstract Syntax Notation 1


ATM Asynchronous Transfer Mode AUTN Authentication Token AWGN Additive White Gaussian Noise BCH Broadcast Channel BCM Basic Call Manager BCP Basic Call Process BCSM Basic Call State Model BCUSM Basic Call Unrelated State Model BDFE Block Décision Feedback Equaliser BE Best Effort BER Bit Error Rate BGCF Breakout Gateway Control Function BLE Block Linear Equaliser BLER Block Error Rate BMC Broadcast/Multicast Control BPSK Binary Phase Shift Keying BSC Base Station Control 1er BSIC Base Station Identity Code BTS Base Transceiver Station CA Channel Assignment CAI Channel Assignment Indicator CAMEL Customized Applications for Mobile network Enhanced Logic CAP CAMEL Application Part CCAF Call Control Agent Function CCC CPCH Control Command CCF Call Control Function CCPCH Common Control Physical Channel CCTrCH Coded Composite Transport Channel CD Collision Détection CD/CA-ICH Collision Detection/Channel Assignment Indicator Channel CDI Collision Détection Indicator CDMA Code-Division Multiple Access CEC Concatenated Extended Complementary CGF Charging Gateway Function CHV Card Holder Vérification (appelé aussi PIN)

Glossaire 461

CID Channel Identifier CM Connection Management CP Connection Point CPCH Common Packet Channel CPH Call Party Handling CPICH Common Pilot Channel CQI Channel Quality Indicator CRNC Controlling RNC (Radio Network Controller) C-RNTI Cell Radio Network Temporary Identity CS Call Segment (contexte réseaux intelligents) CS Capability Set (contexte réseaux intelligents et CAMEL) CS Circuit-Switching (contexte UMTS) CSA Call Segment Association CSCV Call Segment Connection View CSD Circuit Switched Data (transmission) CSE CAMEL Service Environment CSI CAMEL Subscription Information CSICH CPCH Status Indicator Channel CUSF Call Unrelated Service Function CV Connection View CVS Connection View State DCA Dynamic Channel Allocation DCH Dedicated Channel DFT Discrète Fourier Transform DHCP Dynamic Host Configuration Protocol DL Downlink DNS Domain Name Server DP Détection Point DPC Distributed Power Control DPCCH Dedicated Physical Control Channel DPCH Dedicated Physical Channel DPDCH Dedicated Physical Data Channel DRNC Drift RNC (Radio Network Controller) DSCH Downlink Shared Channel DTMF Dual Tone Multiple Frequency


DTX Discontinuous Transmission DwPTS Downlink Pilot Time Slot EAP Extensible Authentication Protocol EDP Event Détection Point EDP-N Event Détection Point Notification EDP-R Event Détection Point Request EF Expedited Forwarding EFR Enhanced Full Rate EIR Equipment Identity Register EP SCP Etsi Project Smart Card Platform EQM Erreur Quadratique Moyenne ETSI European Télécommunications Standards Institute FACH Forward Access Channel FBI Feedback Information FCSS Fast cell site selection FDD Frequency-Division Duplex FDMA Frequency-Division Multiple Access FEA Functional Entity Action FEC Forward Error Correction FER Frame Error Rate FFT Fast Fourier Transform FIM-CM Feature Interaction-Call Manager FSW Frame Synchronization Word GGSN Gateway GPRS Support Node GMM GPRS Moblility Management GMSC Gateway Mobile-services Switching Centre GPRS General Packet Radio Service GPRS-CSI GPRS CAMEL Subscription Information gprsSSF GPRS Service Switching Function GPS Global Positioning System GSM Global System for Mobile Communications gsmCCF GSM Call Control Function gsmSCF GSM Service Control Function gsmSRF GSM Service Resource Function gsmSSF GSM Service Switching Function

Glossaire 463

GSN GPRS Support Node GTP GPRS Tunneling Protocol GTP-C GTP Control Plane GTP-U GTP User Plane HDSL High-bit rate Data Subscriber Line HLR Home Location Register HPLMN Home PLMN HS-DPCCH High Speed Dedicated Physical Control Channel HS-DSCH High-Speed Downlink Channel HS-PDSCH High Speed Physical Downlink Shared Channel HSS Home Subsriber Server HS-SCCH High Speed Shared Control Channel HTML HyperText Markup Language HTTP Hyper Text Transfer Protocol IAM Interférence d'Accès Multiple ICH Indicator Channel ICMP Internet Control Message Protocol ICQ Système de discussion « I Seek You » I-CSCF Interrogating Call Session Control Function IDFT Inverse Discrète Fourier Transform IES Interférence entre symboles IETF Internet Engeneering Task Force IM-CSI IP Multimedia Camel Subscription Information IMEI International Mobile Equipement Identity IMS IP multimédia Subsystem IM-SSF IP Multimedia-Service Switching Function IN Intelligent Network INAP Intelligent Network Application Part IN-SSM Intelligent Network Switching Manager IP Intelligent Peripheral (contexte réseaux intelligents) IP Internet Protocol IrDA Infrared Data Association ISDN Integrated Services Digital Network ISIM Ims SIM ISUP ISDN User Part


IT Intervalle de temps ITU International Télécommunication Union J2ME Java 2 Mobile Edition J2SE Java 2 Standard Edition K Clé de l'utilisateur, correspond au Ki du GSM KASUMI Algorithme de chiffrement basé sur MISTY réalisant les fonctions

f8 et f9 KVM K (for kilobyte) Virtual Machine (voir J2ME) LLC Logical Link Control (GPRS) LS Least Square M3UA SS7 MTP3-User Adaptation Layer MAC Médium Access Control (contexte protocoles) MAC Message Authentication Code (contexte sécurité) MAP Mobile Application Part MBMS Multimedia Broadcast / Multicast Service MCC Mobile Country Code ME Mobile Equipment MExE Mobile Execution Environment MGCF Media Gateway Control Function MGW Media Gateway MIC Modulation par impulsions et codage MM Mobility Management MMS Mobile Multimedia Service MMSE Minimum Mean Square Error MNC Mobile Network Code MO-SMS-CSI Mobile Originated Short Message Service CAMEL Subscription

Information MPLS Multi Protocol Label Switching MRF Media Resource Function MS Mobile Station (terme GSM) MSC Mobile services Switching Center MSIN Mobile Subscriber Identity Number MSRN Mobile Station Roaming Number MT Mobile Termination MTP Message Transfer Part MTP3b Message Transfer Part 3 broadband

Glossaire 465

MT-SMS-CSI Mobile Terminated Short Message Service CAMEL Subscription Information

MUI Mobile User Identifier NAP Network Access Point NAS Non Access Stratum NAT Network Address Translator NBAP Node B (Application Part) NNI Network to Network Interface NRT Non Real Time NRZ Non remis à zéro NSAPI Network Service Access Point Identifier OBCSM Originating BCSM OCCRUI Out of Channel Call Related User Interaction OCCUUI Out of Channel Call Unrelated User Interaction O-CSI Originating CAMEL Subscription Information OS Operating System OSA Open System Architecture OSI Open System Interconnection OVSF Orthogonal Variable Spreading Factor P2P Peer-to-Peer PC Point Code (contexte SS7) PC Power Control (contexte réseaux cellulaires) P-CCPCH Primary- Common Control Physical CHannel PCH Paging Channel PCPCH Physical Common Packet Channel P-CSCF Proxy Call Session Control Function PDA Personal Digital Assistant PDCP Packet Data Convergence Protocol PDN Packet Data Network PDP Packet Data Protocol PDSCH Physical Downlink Shared Channel PDU Protocol Data Unit PG Période de garde PIA Point In Association PIC Point In Call PICH Page Indicator Channel


PIN Personal Identification Number (appelé aussi CHV) PLMN Public Land Mobile Network PN Pseudo Noise PPP Point to Point Protocol PRACH Physical Random Access Channel PS Packet Switching (en UMTS) PS Point sémaphore (contexte SS7) PSC Primary Synchronisation Code P-TMSI Packet Temporary Mobile Subscriber Identity PTS Point de transfert sémaphore PVC Permanent Virtual Circuit QPSK Quadrature (ou Quaternary) Phase Shift Keying RAB Radio Access Bearer RACH Random Access Channel RANAP Radio Access Network Application Part RI Réseau intelligent RLC Radio Link Control RNC Radio Network Contrôler RNIS Réseau numérique à intégration de services RNS Radio Network Sub-system RNSAP Radio Network Subsystem Application Part RNTI Radio Network Temporary Identity RRC Radio Resource Control RSB Rapport signal à bruit RSI Rapport Signal sur Interference RT Real Time RTCP RTP Control Protocol RTP Real Time Protocol SAGE Security Algorithm Group of Experts SAT SIM Application Toolkit SCCP Signalling Connection Control Part S-CCPCH Secondary Common Control Physical Channel SCE Service Création Environment SCEF Service Création Environment Function SCF Service Control Function

Glossaire 467

SCH Synchronisation Channel SCP Service Control Point SCS Service Création Server S-CSCF Serving Call Session Control Function SCTP Stream Control Transmission Protocol SCUAF Service Control User Agent Function SDF Service Data Function SDP Service Data Point SDP Session Description Protocol SDSL Single-line Digital Subscriber Line SDU Service Data Unit SF Spreading Factor SFN System Frame Number SGSN Serving GPRS Support Node SI Status Indicator SIB Service Indépendant Building Block SIM Subscriber Identity Module SIP Session Initiation Protocol SIR Signal-to-Interference Ratio SM Session Management SMAF Service Management Agent Function SMF Service Management Function SMLC Service Mobile Location Centre SMP Service Management Point SMS Short Message Service SMS-CSI Short Message Service CAMEL Subscription Information SMS-GMSC Short Message Service InterWorking MSC SMTP Simple Mail Transfer Protocol SN Service Node SNDCP Sub-Network Dépendant Convergence Protocol (GPRS) SP Signalling Point (PS, en français) SRF Service Resource Function S RNC Serving RNC (Radio Network Controller) SS7 Signalisation sémaphore n° 7 (Signalling System 7) ssc Secondary Synchronisation code


SSCF-NNI Service Spécifié Coordination Function for Network to Network Interface

SSCOP Service Spécifié Connection Oriented Protocol SSDT Site Selection Diversity TPC SSF Service Switching Function SSP Service Switching Point STP Signalling Transfer Point STTD Space Time Transmit Diversity SVC Switched Virtual Circuit TA Time Alignment • TBCSM Terminating BCSM TBS Transport Block Set TCAP Transaction Capabilities Application Part TCP Transmission Control Protocol T-CSI Terminating CAMEL Subscription Information TCTF Target Channel Type Field TD-CDMA Time Division Synchronous Division Multiple Access TDD Time-Division Duplex TDMA Time-Division Multiple Access TDP Trigger Détection Point TDP-N Trigger Détection Point Notification TDP-R Trigger Détection Point Request TD-SCDMA Time Division-Space Code Division Multiple Access TEB Taux erreur binaire TEID Tunnel Endpoint IDentifier TFCI Transport Format Combination Indicator TFT Traffic Flow Template TMSI Temporary Mobile Subscriber Identity TNUP Transport Network User Plane TPC Transmit Power Control TRAU Transcoder/Rate Adaptation Unit TrD Transparent Mode Data (mode du protocole RLC) TRX Transceiver TSTD Time Switched Transmit Diversity TTI Transmission Time Interval UDP User Datagram Protocol

Glossaire 469

UE User Equipment UICC Universal Integrated Circuit Card UL Uplink UMD Unacknowledged Mode Data (mode du protocole RLC) UMTS Universal Mobile Télécommunications System UNI User to Network Interface UpPTS Uplink Pilot Time Slot U-RNTI UTRAN Radio Network Temporary Identity USAT Usim Application Toolkit USIM Universal SIM USSD Unstructured Supplementary Service Data UTRA UMTS Terrestrial Radio Access UTRAN UMTS Terrestrial Radio Access Network VCI Virtual Channel Identifier VGCS Voice Group Call Service VHE Virtual Home Environment VLR Visitor Location Register VMSC Visited Mobile services Switching Center VPI Virtual Path Identifier W3C World Wide Web Consortium WAE Wireless Application Environment WAP Wireless Application Protocol WCDMA Wideband Code Division Multiple Access WiFi Wireless Fidelity WIM WAP Identity Module WLAN Wireless Local Area Network WML Wireless Markup Language XHTML eXtended HTML ZF Zéro Forcing

Index

3G-GGSN, 288-289, 290, 292, 310-311,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 accès aléatoire, 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, 248-251, 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 sémaphore, 225, 232 CAP, 341, 361, 364, 371-377, 382,


Care Of Address, 322 CCAF, 346 CCCH, 79,81 CCF, 342, 346-349, 353-355, 356-

357,359, 361-362,381 CCITT n°7, 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, 46-

47,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

corrélateur, 34, 36-37, 121, 128 couche ATM, 230, 243, 245, 250 couverture, 94, 102, 112, 187, 188-

189, 192, 193, 207, 209-210, 266 CPICH, 67, 86-88, 96 Critères S et R, 87-89 C-RNTI, 80 ,81,262 CS (Capability Set), 342-344, 354-

356, 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 détachement, 303, 304 détection 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, 172-

173,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, 98-99, 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, 271-272, 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


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, 250-

251, 259, 263, 265, 268-269, 286-289, 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 (sécurité), 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 V midambule, 114-115, 121-125, 128-

129,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, 131-

132, 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, 293-

294, 302, 304, 307, 309-311,313-316,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 sémaphore), 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, 98-99,113

quadrature, 19, 22, 24-26, 62, 82, 98

R RAB, 238-239, 243, 263-264, 267-

268, 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

réponse impulsionnelle, 28, 121-123, 127,133-134, 146-147, 149

réseau de transport, 219, 221, 232, 235-240, 242-245, 247, 250-251, 258, 276, 287, 290

réseau sémaphore, 225-226, 244, 287 RNC, 54, 56, 82, 91-92, 96, 98, 100-

101, 142, 145-146, 171-172, 218-224, 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, 243-

244, 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 séquence 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,


319-322, 325, 331, 355, 360, 362-363, 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, 171-

173, 175, 195, 209, 222-223, 264-267

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'accès, 236 strate de non-accès, 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, 110-

114, 116-118, 120-122, 129, 130-131, 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, 399-

404, 402, 404, 406, 409, 412, 416, 418, 420, 440

WML, 400, 404

CET OUVRAGE A ÉTÉ COMPOSÉ PAR HERMÈS SCIENCE PUBLISHING LTD ET ACHEVÉ D'IMPRIMER PAR L'IMPRIMERIE FLOCH À M A Y E N N E EN M A R S 2 0 0 5 .

DÉPÔT LÉGAL : MARS 2005. N° D'IMPRIMEUR : 62646.