DSpace at VNU: Utilisation de la compression des entêtes dans les réseaux cellulaires de type 4G (LTE SAE) vu dinh dau

DSpace at VNU: Utilisation de la compression des entêtes dans les réseaux cellulaires de type 4G (LTE SAE) vu dinh dau t...

Mémoire de fin d’études Master Informatique, option Systèmes et Réseaux

Utilisation de la compression des entêtes dans les réseaux cellulaires de type 4G (LTE/SAE)

Réalisé par :

Sous la direction de :

Xavier LE BOURDON JCP-Consult

Table des matières

Glossaire des Abréviations 7

1 Introduction 9

1.1 Contexte 9

1.2 Problématique 10

1.3 Intérêt personnel pour ce stage 11

1.4 Objectifs de mes contributions 11

1.5 Plan du document 12

2 EPS/LTE évolution de l'UMTS 13

2.1 Contexte de l'UMTS 13

2.1.1 Évolution de UMTS 13

2.1.2 Architecture de l'UMTS 15

a) Architecture générale de l'UMTS 15

b) Architecture protocolaire de l'UMTS 17

2.1.3 Technologies concurrentes 19

2.2 Évolution LTE 20

2.2.1 Contexte et exigences 20

2.2.2 Architecture de LTE 22

2.2.2.1 Noeuds principaux 23

2.2.2.2 Architecture protocolaire 25

a) Plan de contrôle 25

b) Plan utilisateur 26

2.2.3 Interface radio 26

2.2.4 La sous-couche PDCP 27

2.2.5 Couche physique 29

3 RoHC dans UMTS/LTE 30

3.1 Description de RoHC 30

3.2 RoHCv2 31

3.2.1 Motivation de proposition de RoHCv2 dans PDCP/LTE 31

3.2.2 Améliorations et autres différences de RoHCv2 avec RoHCv1 31

3.2.3 Les profils de RoHCv2 32

3.2.4 Compresseur et décompresseur 33

3.3 Recommandation de RoHC dans 3GPP 33

3.4 Support de RoHC au terminal 34

3.5 Procédure de déclenchement de RoHC 35

3.6 RoHC et handover 37

3.7 RoHC et MBMS 38

3.7.1 MBMS 38

3.7.2 RoHC et Broatcast/Multicast 39

4 Évaluation de la performance de ROHCv1 40

4.1 Objectifs 40

4.2 Scénarios 40

4.2.1 Modèle d'évaluation de performance 40

4.2.2 Choix de modèle de fautes 41

4.3 Pre-tests 42

4.4 Résultats 43

4.4.1 Taux de bande passante économisée 43

4.4.2 Taux de paquets perdus 46

4.4.3 Nombre maximal de paquets perdus successifs 46

4.4.4 Comparaison avec RoHC de Thales et Al 49

5 Conclusion et perspectives 51

Bibliographie 52

Annexe A 54

Annexe B 61

Je tiens tout d’abord à remercier Loutfi NUYAMI qui a suivi mon travail théorique concernant l'architecture des réseaux cellulaires, et la recherche dans la grande quantité de documents de 3GPP Il m'a donné également des conseils sur la méthodologie de recherche

Je souhaite également remercier Xavier LE BOURDON Il a été à la fois mon ami qui m'a aidé à l'adaptation à la vie en France et mon superviseur qui m'a donné des conseils sur le travail pratique concernant les tests de performance de RoHC

Je voudrais aussi remercier Ana Carolina MINABURO qui a sélectionné ma candidature de stage, et donné fréquemment des commentaires forts utiles sur mon travail

Je voudrais remercier Eric Poilvet qui m'a donné des conseils sur l'architecture de UMTS

Je voudrais remercier Michel BADET qui a travaillé en coopération avec moi pour localiser et corriger des anomalies de performance de RoHCv1 Je voudrais également remercier Thomas Lefort qui m'a aidé sur la partie concernant RoHCv2

Je tiens à remercier Jean-Marie BONNIN et Stéphane ROLLAND qui m'ont donné des conseils sur le plan de travail

Je voudrais remercier Jean-Charles Point qui a financé pour mon stage, et donné un environnement professionnel favorable à mon travail

Enfin, je voudrais remercier mon professeur à l'Institut de la Francophonie d'Informatique (IFI) qui n'ont donné des cours de réseaux afin d'avoir les connaissances de base pour réaliser ce stage

LTE (Long Term Evolution) est la dernière évolution d'une série de technologies cellulaires sans-fil GSM/UMTS/HSPA, en compétition pour être la norme de la quatrième génération de réseau mobile (4G) Les innovations au niveau de l'interface radio et de l'architecture « plate et tout-IP » permettent de réduire le délai d'accès et d'enrichir des services multimédia comme les services de télévision sur IP à haut débit La compression d'entêtes RoHC (Robust Header Compression) est une technologie présente dans LTE à l'interface radio ó la bande passante est limitée et cỏteuse RoHC permet de réduire la taille des paquets IP des applications multimédia dans lesquels la taille de payload est souvent petite par rapport à la taille d'entête La deuxième version de RoHC (RoHCv2) simplifie l'implémentation de RoHC et améliore la performance dans le cas de handover Elle est prise

en compte dans l'architecture de LTE

Dans ce document, nous analysons l'architecture de LTE afin de connaỵtre l'intégration

de RoHC dans ce système Nos études montrent que RoHC prend place au niveau de la couche PDCP, et que les profils de RoHCv1 et de RoHCv2 sont prévus Nous étudions également le support de RoHC par LTE dans le cas de handover et dans les services de broadcast/multicast Le deuxième axe de travail fut une campagne de tests sur l'implémentation de JCP-Consult Elle montre que RoHC est très robuste contre des erreurs sur le lien radio, et peut réduire le taux de perte de paquets dans le cas de handover RoHC permet d'économiser environ 40% de bande passante pour les applications audio et environ 10% de bande passante pour les applications vidéo Cependant, RoHC introduit un phénomène de gigue au niveau applicatif

sous-Mots clés : réseau cellulaire, 4G, LTE, UMTS, PDCP, compression des entêtes RoHC,

RoHCv2, IPTV

LTE (Long Term Evolution) is the latest evolution of GSM/UMTS/HSPA, the mobile broadband technology standards, toward the fourth generation of cellular wireless known as 4G The innovations of LTE at the radio interface and the architecture “flat and all-IP” reduces the access delay and enrich the multimedia services such as the television over IP Robust Header Compression (RoHC) is a solution of LTE at the radio interface to optimize the throughput of audio/video applications, where packets generally contain a large header in comparison with their payload The second version of RoHC (RoHCv2) that simplifies the implementation of RoHC and improves the performance in handover is supported by LTE

We analyze the architecture of LTE to integrate RoHC in this system Our study shows that RoHC takes place at PDCP radio layer, profiles of both RoHCv1 and RoHCv2 are supported We also studied the support of RoHC by LTE in handover and the services broadcast/multicast The verification on the implementation of JCP-Consult proves that RoHC is very robust against errors in the radio link, and can reduce the loss rate in handover

It helps reduce about 40% bandwidth of VoIP flow and about 10% bandwidth of video flow

We, however, found RoHC introduces a little jitter to the multimedia flows

Keywords: cellular network, 4G, LTE, UMTS, PDCP, header compression, RoHC, RoHCv2, IPTV

Glossaire des Abréviations

AAL2 ATM Adaptation Layer 2

AAL5 ATM Adaptation Layer 5

AuC Authentication Centre

BM-SC Broadcast Multicast Service

Centre

BSC Base Station Controller

BTS Base Transceiver Station

CDMA Code Division Multiple Access

CSCF Call Session Control Function

CSCF Call Session Control Function

E-CSCF Emergency CSCF

EDGE Enhanced Data rates for Global Evolution

EPS Evolved Packet System

EV-DO Evolution Data Optimized

FDD Frequency Division Duplex

FEC Forward Error Correction

GPRS General Packet Radio Service

GSM Global System for Mobile communication

GTP GPRS Tunnelling Protocol

HLR Home Location Register

HSDPA High Speed Downlink Packet

Access

HSPA High Speed Packet Access

HSS Home Subscriber Server

HSS Home Subscriber Server

HSUPA High Speed Uplink Packet Access

I-CSCF Interrogating CSCF

IMS IP Multimedia Subsystem

IPTV Internet Protocol Television

ISI Inter Symbol Interference

M3UA MTP3 User Adaptation Layer

MBMS Multimedia Broadcast/Multicast Service

MIMO Multiple Input Multiple Output

MME Mobility Management Entity

MRF Multimedia Resource Function

MTP3 Message Transfer Part Layer 3

MTP3B Message Transfer Part level 3 broadband

NGMN Next Generation Mobile Networks AllianceOFDMA Orthogonal Frequency Division Multiple AccessP-CSCF Proxy CSCF

P-GW Packet Data Network Gateway

PAPR Peak-to-Average Power Ratio

PCRF Policy Control and Charging Rules FunctionPDCP Packet Data Convergence

Protocol

PSTN Public Switched Telephone NetworkRANAP RadioApplication Part Access Network RLC Radio Layer Control

RNC Radio Network Control

RoHC Robust Header Compression

RRC Radio Ressource Control

SAE System Architecture Evolution

SC-FDMA Single Carrier - Frequency Division Multiple AccessSCCP Signalling Connection Control PartSFN Single Frequency Network

SIGCOMP Signaling Compression SIP Session Initiation Protocol

SRAN Satellite Radio Access Network

UDVM Universal Decompressor Virtual Machine

UMB Ultra Mobile Broadband

UMTS Universal Mobile Telecommunications System

Index des illustrations

Illustration 1: Le débit des évolutions différentes de l'UMTS (le bleu présente le débit en

théorie, le vert présente le débit que l'on espère, source : [5]) 14

Illustration 2: Architecture de l'UMTS (release 99) 16

Illustration 3: Architecture de l'UMTS (release 5) 17

Ilustration 4: L'architecture protocolaire de l'UMTS dans le plan de contrôle (domaine de PS, release 5) 17

Illustration 5: L'architecture protocolaire de l'UMTS dans le plan d'utilisateur (release 5) 19

llustration 6: L'architecture générale du réseau LTE 22

Illustration 7: La différence entre eNodeB (LTE) et NodeB (HSPA) au plan utilisateur [15] 24 Illustration 8: Plan contrôle en couches [16] 25

Illustration 9: Plan utilisateur 26

Illustration 10: La deuxième couche de l'interface radio au sens descendant [16] 27

Illustration 11: La fonction de la couche PDCP [17] 28

Illustration 12: Procédure pour configurer et déclencher RoHC dans l'interface radio 35

Illustration 13: Modèle d'évaluation de performance de RoHC 40

Illustration 14: Pre-tests, le nombre maximal de paquets perdus est très haut dans O-mode 42

Illustration 15: Bande passante économique dans U-mode et BER = 0.0 avec des flux différents 43

Illustration 16: Taux de bande passante économisée VoIP AMR 12,2 kbps 45

Illustration 17: Taux de bande passante économisée VoIP AMR 23 kbps 45

Illustration 18: Taux de bande passante économisée Video H264 haute qualité 45

Illustration 19: Taux de bande passante économisée Vidéo H264 moyenne qualité 45

Illustration 20: Taux de paquets perdus VoIP AMR 12,2 kbps 47

Illustration 21:Taux de paquets perdus VoIP AMR 23 kbps 47

Illustration 22: Taux de paquets perdus Video H264 haute qualité 47

Illustration 23: Taux de paquets perdus Vidéo H264 moyenne qualité 47

Illustration 24: Nombre maximal de paquets perdus successifs VoIP AMR 12,2 kbps 48

Illustration 25: Nombre maximal de paquets perdus successifs VoIP AMR 23 kbps 48

Illustration 26: Nombre maximal de paquets perdus successifs Video H264 haute qualité 48

Illustration 27: Nombre maximal de paquets perdus successifs Vidéo H264 moyenne qualité .48

Illustration 28: Taux de bande passante économisée VoIP 12,2kbps 50

Illustration 29: Taux de paquets perdus VoIP 12,2kbps 50

Illustration 30: Nombre maximal de paquets perdus successifs VoIP 12,2kbps 50

Illustration 31: Pile protocolaire avec la compression 55

Illustration 32: SIGCOMP Architecture 56

Illustration 33: La mémoire d’UDVM 58

Illustration 34: Format of a SIGCOMP message 58

Illustration 35: Compression SigComp 60

Index des tables Tableau 1: Les profils supportés par LTE [17] 33

Tableau 2: Les paramètres sont définis par la couche supérieure de PDCP[17] 34

Tableau 3: Les différents flux pour évaluer la performance de RoHC 41

Tableau 4: Des anomalies de performance de RoHC de JCP-Consult 42Tableau 5: Instructions d’UDVM et les valeurs de pseudo code 57Tableau 6: Ratio de Compression pour les messages SIP [45] 59

1 Introduction

1.1 Contexte

Mon stage de fin d'études s’est déroulé sur une période de 6 mois à JCP-Consult, en coopération avec TELECOM Bretagne, dans le carde du projet NextTV4All du 16 Mars au 15 Septembre 2009

Le projet NextTV4All (Next TV for all: télévision à venir pour tous) est un projet du Pôle Images & Réseaux, et s’inscrit dans le thème « télévision sur IP basé sur IMS » dans un environnement de convergence fixe-mobile Le projet prend en compte les interactions entre les services audiovisuels interpersonnels et conversationnels et les services de IPTV[annexe

du projet]

Les partenaires du projet sont: Alcatel Lucent, Devoteam, France Télécom, IRISA/Université de Rennes 1, JCP Consult, Le Télégramme, Neotilus, NEXCOM Systems, TELECOM Bretagne, Thomson Grass Valley, Thomson R&D France, Thomson Telecom JCP-Consult est une PME, située à Cesson-Sévigné, dans la périphérie de la ville de Rennes, dont le domaine d'activité se présente selon les deux axes suivants :

 Expertise, standardisation et montage de projets de Recherche et Développement, notamment concernant les projets de recherches européens ;

 Le développement de piles de protocole réseaux, notamment les protocoles de compression des entêtes RoHC

Dans le projet NextTV4all, JCP-Consult participe à l'étude de la qualité de service

« inter-couches », c'est-à-dire la corrélation entre métadonnées associées au contenu, signalisation, réservation de ressource et couche MAC Cette entreprise participe également à l'étude des protocoles RoHCv1 et RoHCv2 au sein des architectures du projet (IMS, LTE) Enfin, elle implémente une pile RoHCv2 afin d'étudier les qualités et les défauts de ce protocole

TELECOM Bretagne est une Grande École d'ingénieur généraliste et un centre de recherche international dans les sciences et technologies de l'information Le département de recherche RSM (Réseau, Sécurité et Multimédia) de TELECOM Bretagne à Rennes est actif

dans l’enseignement et la recherche sur les réseaux et en particulier sur la qualité de service et les nouvelles architectures

Le département est actuellement impliqué dans plusieurs projets portant entre autres sur

la QoS et les NGN (Next Generation Network), est membre du réseau d’excellence EuroFGI

et participe à la standardisation de l’Internet à l’IETF Dans le projet, une des contributions de TELECOM Bretagne est de réaliser des études sur la standardisation de RoHCv2

Mon stage fut encadré en partenariat avec ces deux entreprises :

 Loutfi Nuyami, maître de conférences de TELECOM Bretagne, a suivi le travail théorique concernant des normes de 3GPP, en particulier, l'architecture de LTE

 Xavier Le Bourdon, ingénieur de recherche de JCP-Consult, a suivi le travail pratique concernant les tests de la performance de RoHC

1.2 Problématique

L'évolution des technologies pour réseaux mobiles (2G, HSPDA) et maintenant LTE offrent des débits de plus en plus importants atteignant jusqu'à 100Mbps Ces débits permettent alors l'accès aux services multimédia sur téléphone mobile Au-delà des technologies de transport, LTE est basé sur un architecture « plate et tout-IP » Cette évolution simplifie l'intégration avec l'architecture IMS qui permet l'inter-fonctionnement entre tous types de réseaux (fixe, mobile, sans fil)

La taille des paquets dans les flux multimédias associés à la voix ou à la vidéo est petite (20 à 60 octets); l'encapsulation RTP/UDP/IP utilisée représente donc une part importante du paquet (40 octets pour IPv4 et 60 octet pour IPv6), la compression d'en-tête RoHC (RObust Header Compression, défini dans le RFC3095 de l'IETF) permet donc une augmentation très importante de la capacité du réseau dans le cas de flux multimédias interactifs De plus RoHC

a été adopté dans la release 5 de l'UMTS

La première version, RoHCv1 (RFC 3095), est d’ores et déjà incluse dans les systèmes

de téléphonie en cours de déploiement Une seconde version de RoHCv2 (RFC 5225) est actuellement en phase de conception Elle prend en compte des déséquencements de paquets entre compresseur et décompresseur, par exemple pour compresser les tunnels IP dans le cadre de la mobilité Elle apportent également des simplifications pour RoHCv1 3GPP a prévu d’intégrer cette version dans les futures architectures LTE

Le projet NextTV4All a pour objectif de préparer les futurs services multimédia des

réseaux IMS[1], à partir de l'analyse et du développement des différents services unitaires et des équipements Le projet se terminera alors par une phase d'intégration des équipements et des services développés, permettant de vérifier la validité des choix techniques Une des contributions de JCP-Consult est d'étudier et d'intégrer la compression des entêtes dans les réseaux Les études visent à répondre à deux questions :

 Comment intégrer RoHC dans l'architecture de LTE ?

 Quel sera impact de RoHC sur les services de LTE tels que des applications audiovisuelles, et vice-versa celui du réseau tels que la mobilité et la diffusion broadcast/multicast sur la performance de RoHC ?

1.3 Intérêt personnel pour ce stage

 LTE est la dernière évolution dans une série de technologies de GSM/UMTS/HSPA dominantes, un candidat à la future 4G Cependant, les réseaux mobiles actuels au Vietnam sont considérés à la génération 2,5G, et avec une évolution proche prévue vers 3G De plus, 3GPP se composent la grande quantité de documents avec des évolutions continuelles sont la terre fertile pour faire des recherches et des développements

 Je souhaite devenir un ingénieur de recherche, donc, une expérience dans un entreprise de Recherche & Développement comme JCP-Consult fut très formateur

1.4 Objectifs de mes contributions

L'objectif principal de mon stage était de contribuer à l'état de l'art d'intégration de RoHC dans l'architecture de LTE C'est une base de travail pour JCP-Consult dans le cadre du projet NextTV4All Mes contributions sont donc :

 Dans le cadre du projet NextTV4All

Mon travail fut de contribuer à un état de l'art d'intégration de RoHC dans l'architecture

de LTE qui étudie complètement des aspects de RoHC dans les réseaux LTE Des études de documents indiquent l'endroit de la compression/décompression, les profils supportés, les paramètres et procédures définis dans la norme 3GPP De plus, la recherche prend en compte

la performance de RoHC dans le cas de handover et broadcast/multicast Cela permet d'implémenter RoHC, d'envisager les impacts de RoHC avec la qualité de services, et de vérifier le choix de technologique

 En interne pour l'entreprise JCP-Consult

J'ai développé un simulateur de fautes au niveau du lien radio, et un outil d'évaluation

de la performance de RoHC Le simulateur est capable de simuler des bits erronés, et des pertes de paquets Les fautes peuvent être générées selon les différents distributions de Uniform, Gilbert simple (ou 2-states Markov), et Gilbert-Ellibott Le simulateur permet dans

la suite de simuler l'autre caractéristique telle que le problème de délai et déséquencement du lien radio L'outil de test permet d'évaluer la performance de RoHC à partir des paquets

« live » qui sont capturés du réseau

Lors de mes tests de la performance de RoHCv1, j'ai trouvé des anomalies par rapport des évaluations de performance de manière théorique Les discussions avec les ingénieurs à JCP-Consult ont permis de corriger des bugs dans l'implémentation A la fin de mon stage, les résultats de tests sont raisonnables et correspondent aux attentes théoriques De plus, j'ai comparé la performance de RoHCv1 de JCP-Consult avec une autre implémentation afin d'améliorer implémentation de JCP-Consult à l'avenir Tout cela permet de refaire des tests avec l'implémentation de RoHCv2 qui est en train d'être développée

de déclenchement, et la recommandation de RoHC dans le cas de handover et dans les services de broadcast/multicast Le quatrième chapitre présente les résultats d'évaluation de performance de RoHC et les impacts sur la qualité de services Les tests de performance sont réalisés à partir de l'implémentation de JCP-Consult Enfin, une solution d'optimisation de transmission au niveau d'application par SIGCOMP est étudiée

2 EPS/LTE évolution de l'UMTS

2.1 Contexte de l'UMTS

2.1.1 Évolution de UMTS

UMTS comporte des évolutions qui sont définies par les releases suivantes :

La première, release 99, est publiée mi-1999 Cette version utilise une nouvelle

interface radio qui se base sur CDMA (l'accès multiple à répartition en codes) Il y a deux types de réseau d'accès : FDD et TDD (TD-CDMA) Les interfaces radio des deux réseaux d'accès sont supportées par l'ATM Le débit maximal dans le sens descendant est, en théorie,

de 2 Mbps, et dans le sens montant est de 768 kbps Le réseau du cœur se base sur le réseau

de transport du GSM et GPRS

La release 4 de l'UMTS est terminée en mars 2001 Cette version ajoute la deuxième

interface radio de type TDD, TD-SCDMA Cette interface utilise un débit « chip » inférieur (1,28 Mcps) par rapport au TD-CDMA (3,84 Mcps) afin de s’adapter à la bande inférieure (donc 6MHz) que la bande traditionnelle de TDD La release 4 apporte une évolution importante dans le réseau cœur qui sépare la signalisation de la transmission (« call and bearer separation ») En conséquence, le MSC se divise entre le serveur de MSC pour assurer le contrôle d'appel, et CS-MGW pour assurer la transmission Le GSMC se divise également entre le serveur de GSMC et CS-MGW.[2]

La release 5 est terminée en mars 2002, et apporte des évolutions significatives Cette

version inclut deux évolutions dans le réseau UMTS : le support d’IP au niveau du réseau coeur et HSDPA Le protocole IP est considéré afin de remplacer l'ATM dans la couche de transport Le mécanisme de HSDPA se base sur le canal radio qui est partagé entre tous les utilisateurs dans le sens descendant, sur l'évaluation en temps réel du canal radio, et sur la retransmission rapide (HARQ) afin d'augmenter le débit descendant, en théorie, à 14,4 Mbps

De plus, la nouvelle architecture IMS (IP Multimedia Subsystem) apporte une évolution importante dans le réseau cœur afin de mieux supporter des applications IP telles que : partage audio/vidéo, « video streaming », VoIP, Et le SIP (Session Initiated Protocol) est le protocole principal d'IMS afin de contrôler les sessions établies.[3]

La release 6 est terminée en mars 2005 Cette version apporte le mécanisme de HSUPA

afin d'accroître le débit montant maximal, en théorie à 5.76 Mbps Le HSUPA utilise des

techniques comme HSDPA telles que HARQ, mais des canaux radio partagés sont remplacés par des « dedicated channels » La combinaison de HSDPA et HSUPA s'appelle HSPA De plus, les services de MBMS permettent de diffuser de contenu en mode broadcast et multicast Cette diffusion est utilisée souvent par des applications telles que la télévision mobile.[4]

Illustration 1: Le débit des évolutions différentes de l'UMTS (le bleu présente le débit en

théorie, le vert présente le débit que l'on espère, source : [5])

La release 7 est terminée en juillet 2007 Cette version apporte des améliorations sous

le nom de HSPA+ pour HSPA En théorie, HSPA+ permet au débit descendant d'atteindre 42.2 Mbps, au débit montant d'atteindre 11.5 Mbps Le troisième choix pour l'interface radio

de type TDD a le débit chip de 7,68 Mcps La technique de CPC (Continuous Packet Connectivity , Connectivité permanente pour les utilisateurs des services paquets) est utilisée pour diminuer l'interférence causée par des canaux «dedicated physical control » lorsqu'il n’y

a aucun utilisateur sur ces canaux Cela permet au terminal de s’éteindre après une période d'inactivité de ces canaux, donc de diminuer sa consommation d'énergie.[6]

La release 8 est en cours d’achèvement Cette version apporte des évolutions

significatives d'UMTS sous le nom de LTE La comparaison des évolutions de l'UMTS est disponible dans la figure 1

La release 8 est terminée avec des exigences de haute priorité et des caractéristiques

essentielles La release 9 développe les caractéristiques manquantes La release 10 se

concentre sur LTE-Advanced

2.1.2 Architecture de l'UMTS

a) Architecture générale de l'UMTS

L'architecture générale du réseau UMTS se compose d'un réseau d'accès et d'un réseau cœur (figure 2)

Le réseau d'accès (UTRAN) regroupe des fonctions permettant de transmettre des informations (trafic de données et trafic de signalisation) de l'utilisateur vers le réseau cœur Il

se compose des NodeB et des RNC (Radio Network Control) qui correspondent

respectivement à la BTS et au BSC dans l'architecture GSM Le RNC sert à la gestion de ressources radio, et du « soft handover » par exemple Il contrôle un ou plusieurs NodeB via l'interface Iub Un NodeB peut servir une ou plusieurs cellules Le NodeB s'occupe de la transmission et de la réception du signal radio, de la modulation/démodulation, du codage de canal, l'adaptation du débit de transmission, élargissement/des-élargissement, et du contrôle

de la puissance d’émission, et de la synchronisation.[7]

Le réseau cœur regroupe des fonctions permettant l'acheminement des données d'utilisateur vers la destination correspondante, la gestion d'appel, de la mobilité, de l’authentification, de la sécurité des échanges et de la taxation Dans le rôle d'acheminement,

le réseau cœur se compose de serveurs et de passerelles qui se divisent entre deux domaines principaux: le domaine CS (domaine de commutation de circuits) et le domaine PS (domaine

de commutation de paquets) L'autre domaine est le domaine de broadcast (BC) afin de

transmettre des messages de broadcast Le domaine de CS comprend le MSC, VLR et GSMC servant à communiquer avec les réseaux de téléphonie donc PSTN, et PLMN Le domaine PS comprend le SGSN et le GGSN servant à communiquer avec les réseaux tels que Internet En communiquant avec les bases de données partagées telles que HLR, EIR, AuC, les composants réalisent également les fonctions de gestion des utilisateurs, de la taxation, et de

la sécurité

Le réseau cœur n'est pas obligatoire reliée à l'UTRAN, mais supporte aussi d'autres

technologies d'accès radio telles que HIPERLAN 2, IEEE 802.11, et SRAN (Satellite Radio

Access Network).

Illustration 2: Architecture de l'UMTS (release 99)

Depuis la release 4, le MSC/VLR se divise entre le serveur de MSC et CS-MGW Le GSMC se divise également entre le serveur de GSMC et CS-MGW Cette division a pour but dans le domaine CS de séparer le plan de contrôle et d'utilisateur Cela permet à l'opérateur d'élargir la taille et d'optimiser la topologie du système

Dans release 5 (cf figure 3)[8], le HSS (Home Subscriber Server) remplace le HLR et AuC, et le sous-système IMS (IP Multimedia Subsystem) est ajouté L’IMS est une architecture « overlay » servant à établir, modifier et contrôler des sessions établies avec les réseaux IP afin de mieux supporter des applications IP telles que : partage de audio/vidéo,

« video streaming », VoIP, L’IMS utilise le domaine PS pour transmettre des messages de signalisation et des données multimédia Il est indépendant du domaine CS, même s’ils partagent quelques composants tels que HSS Le protocole SIP (Session Initiated Protocol) est

le protocole principal de signalisation IMS L’IMS se compose des entités fonctionnelles

PSDN

Internet

IuUu

Iub

Iur

PS domain

CS domainRel 99

principales CSCF(Call Session Control Function) (P/I/S/E-CSCF), AS, MRF, PCRF et différents SBC L'architecture de référence et les fonctions d'entités IMS sont présentées dans

TS 23.228 [9]

Illustration 3: Architecture de l'UMTS (release 5)

b) Architecture protocolaire de l'UMTS

Le modèle protocolaire de l'UMTS se compose d’un ensemble de divisions verticales et horizontales La division horizontale sépare l'interface en plusieurs des couches La division verticale comprend le plan de contrôle et d'utilisateur Le plan d'utilisateur transmet des données d'utilisateur Le plan de contrôle transmet des messages de signalisation (source principale [10])

Ilustration 4: L'architecture protocolaire de l'UMTS dans le plan de contrôle (domaine de PS,

release 5)

Dans le plan de contrôle à l'interface Iu (cf figure 4), le protocole RANAP (Radio Access Network Application Part) regroupe des fonctions nécessaires pour connecter le réseau d'accès avec le réseau cœur telles que : paging, allocation de ressources, gestion de la

PSDN

Internet

IuUu

RRC RLC MAC PHY

RRC

ATM or IP Transport

RANAP

PHY

SCCP ATM or IP Transport

C-plane

IP M3UA SCTP

mobilité, la signalisation du protocole RANAP est transmise via la couche de transport via ATM ou IP La couche de transport de type ATM est basée sur AAL5 (ATM Adaptation Layer 5) qui est un protocole simple et efficace de la famille des AAL La couche de transport

de type IP est basée sur le protocole SCTP/IP

Dans le plan d'utilisateur du domaine PS (cf figure 5), les données sont transmises par

un tunnel GTP Le tunnel GTP est transmis via le protocole UDP/IP A l'interface radio, 3GPP ajoute la sous-couche PDCP afin de compresser des entêtes, de chiffrer les paquets et de transmettre des paquets sans accusés de réception vers le nouveau SRNC pendant un processus de re-allocation de SRNC Dans le domaine CS, des données d'utilisateur sont transmises directement via l'AAL2 ou protocole RTP/UDP/IP à l'interface Iu L'AAL2 donne des connexions qui assurent le délai minimale et permettent de transmettre au débit variable AAL2 et RTP supportent des données multimédia [7]

Illustration 5: L'architecture protocolaire de l'UMTS dans le plan d'utilisateur (release 5)

Dans le release 99, la couche de transport via ATM (AAL2/AAL5) est un choix répandu et la couche de transport via IP est un choix optionnel Mais depuis release 5, les deux ont la même priorité Le protocole SCCP (Signalling Connection Control Part) est choisi pour supporter ces deux couches de transport En général, dans le réseau SS7, SCCP utilise le protocole MTP3 ( Message Transfer Part Layer 3) afin de faire le routage Les protocole M3UA et SCTP permettent au protocole SCCP de passer dans domaine de IP

PDCP

UDP/IP AAL5/ATM PHY

GTU-U

LL

UDP/IP LL PHY

ATM transport IP transport

ATM transport IP transport

Iu-PS

PHY

ATM or IP Transport ATM or IP

Transport

2.1.3 Technologies concurrentes

En Juin 2008, 1xEV-DO, un successeur de CDMA-2000, a été déployé En

comparaison avec HSPA, EV-DO peut gagner une même efficacité spectrale[11] La difficulté d'utilisation pour l'ensemble du service de voix des données limite le déploiement d’EV-DO 3GPP2 a introduit EV-DO RevB dont le débit sur une bande passant de 20MHz

atteint 73,5Mbps et UMB qui se base sur OFDMA Cependant, aucun opérateur ne qui

proclame officiellement son support à EV-DO RevB et UMB Le nombre d'abonnements à la famille CDMA2000 est faible par rapport à la famille GSM/UMTS

WiMax est considéré comme une technologie qui peut potentiellement remplacer la

technologie cellulaire dans les réseaux sans fil dans les zones étendues Cette technologie est ajoutée à l’IMT-2000 (technologie de 3 G) Elle se base sur la norme IEEE 802.16 qui peut être déployée sur un spectre libre(5MHz) WiMax comporte de nombreuses évolutions En

2004, la norme a ajouté le support du multicast Depuis 2005, elle supporte le handover BTs, et inter-opérateurs En théorie, la performance de WiMax est compétitive avec le HSPA+/LTE, avec les mêmes innovations à l'accès radio telles que OFDMA, MIMO Mais, la performance de WiMax est diminuée dans une zone urbaine ó se trouve un large nombre d'utilisateurs De plus, WiMax est testée dans un nombre limité de zones, pas déployée globalement et peu d'opérateurs proclament officiellement son support à WiMax

inter-Il existe d'autres alternatives telles que IEEE 802.20 qui ressemble à l'UMB, et Metro

Wi-Fi IEEE 802.20 ne gagne pas beaucoup d'intérêt auprès des opérateurs Metro Wi-Fi

peut-être une technologie complémentaire qui fournit de l'accès à large bande en centre ville, cependant la technologie 3G fournit déjà de l'accès sur une zone plus vaste

Aujourd'hui, GSM/UMTS/HSPA est une série de technologies dominantes[5] avec des évolutions continuelles LTE est la dernière évolution de cette série, en voie pour être la référence 4G Au troisième trimestre 2008, NGMN (Next Generation Mobile Networks Alliance) a choisi LTE comme une technologie qui peut répondre à elle-seule aux exigences des réseaux mobiles de la prochaine génération [11]

2.2 Évolution LTE

2.2.1 Contexte et exigences

Le développement rapide des services de partage audio/vidéo (Youtube, Flickr), media

streaming (VoIP, IPTV), réseaux sociaux (Facebook, MySpace) dans le domaine filaire génère de grandes quantités de données Par ailleurs, un large nombre d’équipements qui permet d’accéder aux services sont disponibles aux utilisateurs tels que : ordinateur portable, PDA, smartphone, "notebook enabled modem" L’utilisateur a donc besoin d’utiliser ces services avec la même expérience sur le domaine sans-fil, en particulier sur les réseaux cellulaires qui permettent à l’utilisateur d’être connecté accéder n'importe quand, n'importe

ó Ces données vont produire un débit élevé sur ces réseaux qui, jusqu'alors, s'intéressent principalement au service de voix, pas aux services de données

Les services de données sont différents des services de voix par: le débit très variable,

la QoS différente pour chaque utilisateur/service, l'utilisation fréquente de connexion IP Les équipements ont donc tendance à utiliser des connexions natives IP sans traduction et filtrage pour supporter efficacement ces services L’évolution du cœur des réseaux téléphonies arrive

à une architecture “tout IP” qui supporte plus efficacement les connexions IP et un réseau entièrement par commutation des paquets facilite les mécanismes de QoS et l’utilisation plus efficace des ressources

En général, LTE a pour but d'offrir un haut débit dans le sens montant et descendant, de réduire le délai d'accès, d'utiliser une bande passante de manière flexible, et d'inter-fonctionner avec les réseaux existants (3GPP et non-3GPP) Cela permet à l'opérateur de fournir des services tels que VoIP, vidéo-conférence, jeux vidéo en ligne, IPTV, et l'autre service des données interactifs

Les caractéristiques principales de LTE sont (source principale [12]) :

 Amélioration de l’interface radio afin d’augmenter le débit montant/descendant, et

la capacité, ainsi que la performance en bordure de cellule LTE utilise l’OFDMA pour le sens descendant et SC-FDMA pour le sens montant, en combinaison avec de nouvelles technologies d’antenne telles que MIMO et « beaming form » Il est prévu d'obtenir un débit descendant de 100 Mbps; et un débit montant maximal de 50 Mbps sur une bande passante de 20MHz Mais en théorie, le débit descendant peut atteindre 326.4Mbps with 4x4 MIMO, et le débit montant peut atteindre 86.4 Mbps sur la bande passante de 20 MHz [13] Une cellule peut supporter au moins 200 d’utilisateurs à la bande de 5MHz, et 400 d'utilisateurs à la bande plus large que 5MHz [14]

 Réduction du délai d'accès : le délai d'aller-retour est inférieur à moins de 10ms et d'initialisation est inférieur à 100 ms afin de supporter des services interactifs et temps réel

 Mobilité : la performance de LTE est optimisée dans le cas ó la vitesse est inférieur à que 15km/h LTE supporte la vitesse de 120 à 350 km/h (voire 500 km/h, selon la bande utilisée)

 Flexibilité du spectre radio : LTE peut-être déployé dans des bandes allant de 1,25 MHz à 20 Mhz, et la bande appariée et non appariée de la 3G Cela permet à l'opérateur de déployer LTE sur la bande existante, de ne pas demander le permis de nouvelle bande LTE supporte FDD et TDD

 Architecture « tout IP », il y a une partie significative du travail de 3GPP pour convertir l'architecture réseau du cœur vers une architecture tout IP qui est envisagée pour simplifier l'inter-fonctionnement avec les réseaux filaires et les réseaux sans fils non-3GPP

 Architecture simplifiée permet d'améliorer l'extensibilité du réseaux

 Compatibilité avec les réseaux 3G existants Il faut que LTE supporte le handover avec les réseaux existants tels que UMTS/HSPA et GSM/GPRS/EDGE De plus, il faut supporter le handover inter-domaines entre sessions de commutation de paquets et de circuits

S-GW

MME

Plan contrơle Plan utilisateur

S1

IMS

Réseaux IP Réseaux PSTN

Réseaux

Non-3GPP

Wifi, Wimax

Téléphone portable 'dual mode'

HSS GSM/UMTS réseau coeur

La figure 6 présente l'architecture générale d'un réseau LTE qui se compose d'un réseau d'accès et d'un réseau cœur et d'autres blocs qui permettent aux réseaux LTE de se connecter avec les réseaux 3GPP existants, les réseaux IP, réseaux téléphoniques commutés (PSTN) et les réseaux non 3GPP tels que WiFi, Wimax Le téléphone portable « dual mode » fournit l'accès au réseau LTE et aussi aux réseaux 3GPP existants.

En comparaison avec l'architecture de UMTS et GSM, le réseau LTE a moins de nœuds afin de réduire le délai et d'augmenter la performance du système [14]

2.2.2.1 Noeuds principaux

L'architecture de réseau cœur est basée sur le protocole TCP/IP Cela permet de simplifier l'interfonctionnement avec les réseaux fixes et non-3GPP En comparaison avec le cœur GPRS du réseau UMTS, le réseau cœur a moins de nœuds, mais chaque nœud s'occupe

de plus fonctions Il y a trois nœuds principaux : MME au plan contrôle, S-GW et P-GW au plan utilisateur (source principale [15])

S-GW (Serving Gateway) achemine des paquets de l'eNodeB vers le réseau cœur et

vice-versa Il est comme une ancre locale qui sert pour la mobilité inter-eNodeBs et vers les réseaux 3GPP (interconnexions de LTE avec les autres 3GPP) Les paquets transmis inter-eNodeBs (et inter-réseaux 3GPP) sont en transit via cette ancre

P-GW (Packet Data Network Gateway) fournit des connexions entre réseau LTE et

d'autres réseaux IP, PSTN, non-3GPP L'allocation d’adresse IP pour l'UE, filtrage des paquets pour chaque utilisateur (Policy Enforcement Point), et le support de la tarification d'une session sont des autres fonctions du P-GW P-GW peut se connecter avec les réseaux PSTN et réseaux IP grâce à l’IMS, une architecture « overlay » par rapport au LTE, servant à établir, modifier et contrôler des sessions

MME (Mobility Management Entity) se compose des fonctions principales dans le plan

de contrôle Il sert à gérer des sessions : signalisation, et négociation des qualités de service, à fournir des procédures de sécurité telles que : initiation, et négociation de chiffrement/protection d'intégrité, et à mettre à jour la position de l'UE

HSS (Home Subscriber Server) est une base de données qui remplace le rôle de HLR et

AuC qui étaient déjà introduits dans les réseaux 2G et 3G

Le standard ne précise pas l'architecture physique de réseau du cœur On peut séparer MME S-GW afin diminuer les interférences entre la signalisation du plan de contrôle et flux

de données élevés du plan utilisateur On peut séparer P-GW avec MME et S-GW afin d'isoler les paquets internes (du réseau cœur) avec des paquets externes (des autres réseaux IP) L'isolation facilite les opérations de sécurité.

Le réseau d'accès est réduit dans l'eNodeB qui joue le rôle du NodeB et du RNC (Radio Network Control) dans les réseaux UMTS Cela permet de réduire le délai d'accès et de simplifier la fonction d'opération et de maintenance du réseau [14]

Illustration 7: La différence entre eNodeB (LTE) et NodeB (HSPA) au plan utilisateur

[15]

Dans le rôle du NodeB, l'eNodeB s'occupe de : la modulation/démodulation, le codage/décodage des informations transmises sur l'interface radio Dans le rôle du RNC, l'eNodeB s'occupe : du contrôle de ressources, du contrôle de la mobilité, de la compression des entêtes

IP, et du chiffrement des données (voir 3GPPP TS 36.300, chapitre 4.1)

L'architecture traditionnelle de l'UMTS réserve la complexité et les nombreux calculs

au RNC, et permet ainsi au NodeB de rester simple Le RNC gère donc de nombreux (même des centaines [15]) de NodeBs et se coordonne avec les autres RNC pour contrôler la macro-diversité (afin de réduire l'interférence dans le réseau UTRAN basée sur la couche physique

de CDMA) Les eNodeB peuvent se connecter directement avec le réseau cœur pour répartir

le travail de RNC par l'interface S1

De plus, le mécanisme de retransmission qui est entièrement implémenté dans l'eNodeB diminue le délai En effet, l'UMTS/HSDPA sépare physiquement la retransmission entre NodeB (mécanisme de HARQ) et RNC (mécanisme de ARQ) La séparation conduit à l'utilisation de deux tampons dans le NodeB et dans le RNC, ce qui augmente le délai d'attente Par d'ailleurs, le changement de NodeB cause la perte de paquets dans le tampon de

ce NodeB La retransmission par la couche TCP du RNC (troisième couche) cỏte donc plus cher Les eNodeB peuvent se connecter par l'interface X2 pour transmettre des paquets aux tampons, à la couche inférieure (deuxième couche), la retransmission cỏte donc moins cher

2.2.2.2 Architecture protocolaire

Comme le modèle d'interface d’UMTS, le modèle de LTE se compose d'un ensemble de couches verticales et horizontales Les couches horizontales sont basées sur le modèle OSI Les couches verticales divisent l'interface entre le plan de contrơle et le plan utilisateur La division verticale correspond à la façon de séparer les flux de données Les données du plan

de contrơle sont transmises avec des contraints de sécurité, de fiabilité plus importantes Celles du plan utilisateur sont transmises par des protocoles plus simple

a) Plan de contrơle

Le plan de contrơle transmet des messages de signalisation telles que la signalisation de gestion de ressource radio, de gestion de mobilité, des services NAS (Non Access Stratum), des autres procédures entre mobile et réseau cœur

Illustration 8: Plan contrơle en couches [16]

La pile protocolaire à l'interface radio est presque la même que celle du plan utilisateur Mais les paquets du plan contrơle sont transmis avec la priorité supérieure et une protection

eNB

PHY

UE

PHY MAC

radio supérieure grâce à la couche MAC qui transmet des canaux logiques vers les canaux de transport correspondants.

b) Plan utilisateur

Le plan utilisateur regroupe l'ensemble des données d'usager et des signalisations au niveau application La figure 9 présente l'architecture protocolaire du plan utilisateur La couche d'application n'est présente qu’à l’UE et qu’au serveur d'application basé sur le protocole IP Les données du plan utilisateur sont transparentes pour le cœur de réseaux

Illustration 9: Plan utilisateur

Les données sont transmises par un tunnel GTP-U GTP-U est une partie du protocole GTP, l'autre partie est GTP-C liée au plan contrôle Autre la fonction d'établir une connexion

de bout en bout entre le mobile et le serveur d'application, le protocole GTP s'occupe d'acheminer les paquets vers l'eNodeB correspondant pendant un déplacement de l'utilisateur

Le protocole GTP est transmis via UDP/IP La pile du protocole GTP/UDP/IP ajoute donc 36 octets d'entête (20 octets d’IPv4, 8 octets d’UDP, et 8 octets de GTP)

La fonction principale de RRC est la gestion de la signalisation établie entre UE et

eNodeBs La couche RRC supporte les fonctions de : transfert de la signalisation du NAS, allocation et libération de ressources radio, diffusion de l’information du système, paging, handover, transfert du contexte utilisateur entre eNodeB pendant le handover, mesure et gestion d’énergie RRC (RRC Connection Reconfiguration Messages/procedures) se compose

GTP-U UDP

GTP-U UDP

IP GTP-U Tunnel

Serveur d'application IP App

des informations de la configuration des Radio Bearers qui contient des paramètres de la couche inférieure telles que la configuration pour la compression des entêtes de la couche PDCP[Annexe : PDCP Info].

La fonction principale de la deuxième couche est de donner un transport fiable entre deux équipements du réseau A côté de MAC et RLC, deux sous-couches de la couche de liaison traditionnelles, 3GPP ajoute une sous-couche PDCP (cf figure 10)

Illustration 10: La deuxième couche de l'interface radio au sens descendant [16]

La sous-couche MAC regroupe des fonctions qui résolvent des problèmes spécifiques

liés à la couche physique pour assurer le couplage entre la couche de liaison et la couche physique, telles que : multiplexage des canaux logiques vers canaux de transport correspondants (selon la pré-configuration), ordonnancement selon la priorité (« priority handling »), et correction d'erreurs sur le mécanisme de HARQ qui est héritée de 3G HSDPA

La sous-couche RLC regroupe des fonctions indépendantes de la couche physique,

telles que : remise en ordre des paquets, détection de perte, et demande de retransmission (Auto Repeat Request) Il y a trois modes de fonctionnement: TM (Transparent Mode), UM (Unacknowledged Mode), et AM (Acknowledged Mode) RLC n'ajoute rien au paquet original dans le mode TM La couche peut détecter des pertes et remettre en ordre des paquets dans le mode UM Enfin, dans le mode d’AM, l'entité RLC peut demander à l'autre bout de retransmettre le paquet

2.2.4 La sous-couche PDCP

La sous-couche PDCP se compose des entités PDCP Chaque entité est rattachée à une

entité de la couche supérieure (Data Radio Bearer), et une ou deux entités de la couche RLC

La figure ci-dessous représente les fonctions d’une entité PDCP (source principale [17]) :

 Utiliser RoHC pour compresser/décompresser des entêtes de paquets

 Mettre en ordre des paquets de la couche RLC

 Garantir de l'intégrité des messages de signalisation du plan de contrôle

 Chiffrement et déchiffrement des messages de signalisation du plan utilisateur

 Ajouter/enlever un entête PDCP

 Ne pas traiter les messages de signalisation de contrôle broadcast et de paging

Illustration 11: La fonction de la couche PDCP [17]

Dans le cas de handover, et dans le sens montant, l'entité PDCP va rétablir la compression des entêtes (recréer la contexte de RoHC), ensuite tous les paquets qui ne sont pas acquittées par la couche inférieure sont retransmises jusqu'à ce que tout le tampon de HARQ soit vide Dans le sens descendant, l'eNodeB va transmettre tous les paquets qui ne sont pas acquittés par la couche inférieure vers le nouveau eNodeB par l'interface X2, ensuite rétablir la compression des entêtes S'il n'y a pas d'interface X2 entre deux eNodeB, la couche supérieure va s'occuper de retransmettre les paquets Le protocole RTP/UDP n'a pas de

mécanisme de retransmission et ne peut donc pas rattraper les pertes éventuelles dans les services VoIP et IPTV [18].

2.2.5 Couche physique

Les deux techniques qui apportent des évolutions de LTE dans le réseau d'accès sont OFDMA et MIMO

OFDMA est une combinaison de technique de modulation et de technique d'accès

multiple OFDMA répartit la bande passante en N multiples sous-porteuses orthogonales qui sont partagées par de plusieurs utilisateurs Chaque sous-porteuse est modulée indépendamment en utilisant des modulations numériques : QPSK, QAM-16, QAM-64 le récepteur les retrouve en appliquant des IFFT

OFDMA réduit le problème d'ISI (Inter Symbol Interference) qui est causé par des trajets multiples et enlève l'utilisation de l'égalisation En comparaison avec CDMA, OFDM a

la même efficacité spectrale mais fonctionne mieux que la bande passante supérieure à 10MHz L'affectation nombre de sous-porteuses pour un utilisateur est dynamique, cela permet à la couche supérieure (MAC) de planifier plus flexiblement l'utilisation des ressources [19] OFDMA est bien adapté aux services broadcast/multicast car OFDM permet

au mobile de combiner le signal de multiples émetteurs

Dans le sens montant, le mécanisme de SC-FDMA est basé sur le même principe

qu’OFDMA, mais il a été choisi car son taux de PAPR « Peak-to-Average Power Ratio », est inférieur à celui de l’OFDMA Plus ce taux est haut, plus le prix et la consommation d’énergie

du terminal augmentent [20]

En comparaison avec les techniques d'antennes traditionnelles qui améliorent la qualité d'un canal, MIMO est une technologie antenne avancée, qui permet de multiples transmissions en parallèle (canaux orthogonaux) par l'utilisation de plusieurs antennes au niveau du récepteur et de l'émetteur

L'augmentation de la qualité est proportionnel au nombre d'antennes MIMO est également une technique de diversité spatiale qui augmente la capacité du système et le débit d'utilisateur sans énergie de transmission et ni de bande passante supplémentaires En comparaison avec 1x1 antenne, 2x2 MIMO peut augmenter 80% de débit[5] MIMO fonctionne mieux dans une région urbaine ó il y a un large nombre d'utilisateurs mobiles (haut ratio de SNR et assez de diffusion « rich scattering ») [14])

3 RoHC dans UMTS/LTE

3.1 Description de RoHC

La taille des paquets dans les flux multimédias associés à la voix ou la vidéo est petite (20 à 60 octets); l'encapsulation RTP/UDP/IP utilisée représente donc une part importante du paquet (40 octets pour IPv4 et 60 octet pour IPv6), la compression d'en-tête RoHC (RObust Header Compression, défini dans le RFC3095 de l'IETF) permet donc une augmentation très importante de la capacité du réseau dans le cas de flux multimédias interactifs De plus RoHC

a été adopté dans la release 4 de l'UMTS

Le mécanisme pour la compression des en-têtes RoHC intègre des fonctionnalités de robustesse permettent de supporter des réseaux bruités L’architecture du mécanisme de Compression RoHC est complexe, mais permet de s’adapter aux caractéristiques du lien et au flux de données Offrant une grande flexibilité dans le mécanisme à travers les différents profils et modes d’opération La norme 3GPP pour RoHC (TS25.323) rend obligatoire les profils 0, 1, 2 et 3[17]

Le principe à la base de la compression des en-têtes est la réduction de la redondance de l'information contenue dans un en-tête, mais aussi de la redondance entre plusieurs en-têtes consécutifs Ainsi l'information qui ne change pas est envoyée au début de la session ou à un faible rythme; pour les autres champs, un mécanisme de prédiction ou de dépendance permet

de réduire encore l'information transmise Le principe de RoHC est d’envoyer l’information minimale pour que le décompresseur puisse reformer l’en-tête L’élément clé est le CRC, calculé avant la compression Il donne au décompresseur une information sur la validité de l’information qu’il possède, puisque l’information transmise est susceptible d’être modifié suite à des erreurs de transmission

La norme RoHC a laissé ouverts de nombreux choix de mise en œuvre, entre autres : la décision du passage dans le décompresseur pour travailler dans le mode optimiste ou fiable, les valeurs des différents paramètres qui sont utilisés pour la compression

L'étude approfondie des spécifications de RoHC, d'IPv6 et de la 3G a permis de relever quelques incohérences dans les documents, en particulier pour le protocole IPv6 Ceci a conduit à des nouveaux travaux au sein de l'IETF qui ont débouché sur une nouvelle version

du protocole RoHC (RoHCv2) qui se différencie de la précédente version du protocole RoHC (ROHCv2) Elle se différencie de la précédente pour les formats de paquets qui sont utilisés

3.2 RoHCv2

Tandis que RoHCv1 est spécifié principalement par la RFC 3095, RoHCv2 est défini par trois documents :

 La RFC 4995 décrit le framework commun à v1 et v2 pour la plus grande part

 La RFC 4997 définit RoHC-FN, une notation formelle pour définir des profils RoHC et les méthodes de compression associées

 La RFC 5225 définit les profils RoHCv2 proprement dits, décrits en grande partie

à l'aide de RoHC-FN

3.2.1 Motivation de proposition de RoHCv2 dans PDCP/LTE

RoHCv2 est proposée par Ericsson[21] La proposition est basée sur trois axes principaux: la robustesse, l'efficacité, et la facilité d'implémentation Dans la même condition

de fonction, le RoHCv2 a la même efficacité de compression RoHCv2 supporte le déséquencement de paquets entre compresseur et décompresseur qui n'est pas supporté pas RoHCv1 Cela permet à la couche PDCP de mettre en ordre paquets dans le cas de handover inter-eNodeB Le profil de TCP/IP qui est déjà supporté par RoHC à la couche PDCP apportent des améliorations et des simplifications pour RFC 3095 Les simplifications sont utilisées pour développer le RoHCv2

3.2.2 Améliorations et autres différences de RoHCv2 avec RoHCv1

Les formats de compression v2 sont au moins aussi performants, tant en termes de taux

de compression que de robustesse, que les formats v1 De plus, comparé à RoHCv1 :

 RoHCv2, supporte le déséquencement de paquets entre compresseur et décompresseur Le mécanisme utilisé permet en outre une meilleure tolérance au déséquencement avant le compresseur

 RoHCv2 utilise les mêmes formats de compression dans ses deux modes de fonctionnement : unidirectionnel et bidirectionnel Sa logique opérationnelle est plus simple et plus homogène que celle de RoHCv1

 RoHCv2 traite les extensions IP comme les autres protocoles compressés, au lieu d'utiliser une liste compressée Cela implique que si la liste des extensions change, le flux compressé sera affecté à un nouveau contexte

 RoHCv2 n'utilise pas de format IR-DYN (Initialization & Refresh / Dynamic

fields) ; seul le format IR peut changer le profil associé à un contexte En revanche, elle utilise

un format co_repair qui transmet tous les champs dynamiques, protégés par un CRC 7 bits, en cas de besoin (contexte décompresseur abîmé)

 La segmentation RoHC est incompatible avec les formats v2 lorsque RoHC ne peut garantir une transmission sans réordonnancement entre compresseur et décompresseur Cela est dû au fait que le protocole de segmentation n'utilise pas de numéro de séquence, mais

un simple bit pour distinguer le dernier segment

Un point commun important avec RoHCv1 : RoHCv2 compte sur les couches basses pour donner la longueur des paquets compressés, et ne transmet donc pas dans ces paquets la taille de la charge utile

3.2.3 Les profils de RoHCv2

RoHCv2 définit (RFC 5225) les profils suivants :

 0x0101 rtp (IP / UDP / RTP)

 0x0102 udp (IP / UDP / non RTP)

 0x0103 esp (IP / ESP)

 0x0104 ip (IP / autre)

 0x0107 udplite_rtp (IP / UDPlite / RTP) (n'est pas utilisée dans LTE)

 0x0108 udplite (IP / UDPlite / non RTP) (n'est pas utilisée dans LTE)

N.B IP s'entend v4 ou v6 ; les deux versions peuvent être utilisées dans un même tête Les bits de poids fort en 0x01 permettent de distinguer les profils v2 des profils v1 (0x00)

en-Pour chaque profil, RoHCv2 sait compresser les protocoles suivants en tant qu'extensions IP :

 ip_dest_opt (IPv6 Destination Option)

 ip_hop_opt (IPv6 Hop-by-hop Option)

 ip_rout_opt (IPv6 Routing Header)

 gre (Generic Routing Encapsulation)

 mine (Minimal Encapsulation within IP)

 ah (IP Authentication Header)

3.2.4 Compresseur et décompresseur

RoHCv2 utilise deux modes de fonctionnement :

 unidirectionnel : les compresseur envoie les paquets avec une approche optimiste Cela consiste à répéter chaque changement de champ transmis en espérant que le décompresseur recevra au moins un des changements Pour que cette approche fonctionne bien, il faut ajuster le facteur de répétition aux caractéristiques du lien (taux d'erreurs bit, taux

de déséquencement) en visant un compromis robustesse / efficacité

 bidirectionnel : le décompresseur peut, s'il existe un lien dans cette direction, envoyer du feedback au compresseur Une fois que le compresseur reçoit du feedback pour un contexte donné, il passe définitivement en mode bidirectionnel pour ce contexte Le trafic de feedback est constitué en majeure partie d'acquittements positifs et négatifs ainsi que d'options diverses Le feedback guide ainsi le compresseur en indiquant les formats compressés que le décompresseur est capable de traiter La synchronisation se fait par un numéro de séquence interne à RoHC (Master Sequence Number)

3.3 Recommandation de RoHC dans 3GPP

Tableau 1: Les profils supportés par LTE [17]

Historiquement, dans release 99, la couche de PDCP ne supporte que « IP compression header » ROHCv1 est supporté à partir de release 4 Les tests de la performance de RoHC sont ajoutées dans release 5 Dans release 6, l'utilisation de RoHC dans les services MBMS

est prise en compte, mais n'est pas obligatoire

Dans release 8, PDCP n’utilise que RoHC pour compresser/décompresser des entêtes pour les paquets au plan utilisateur Les profils supportés se composent des profils définis dans ROHCv1 et ROHCv2 (cf tableau 1)

L’utilisation de la compression des entêtes peut être configurée par la couche supérieure RRC contient des informations pour la configuration de PDCP (voir 3.5)

Les paramètres obligatoires de la configuration sont définis par RFC 4995 Mais il y a des paramètres qui ne sont pas utilisés par PDCP de cette release

MAX_CID Oui Le nombre maximal de CID (Contexte Identifier) est

utilisé Il faut réserver au moins un contexte pour les flux non-compressés C’est-à-dire, il faut que

MAX_CID < « Maximum Number of RoHC Context Sessions »

LARGE_CIDS Oui Elle est déduite du paramètre MAX_CID par la règle :

If MAX_CID > 15 then LARGE_CIDS = TRUE else LARGE_CIDS = FALSE.

PROFILES Oui Les profils sont utilisés par l’UE Les profils autorisés

sont disponibles dans le tableau 1.

FEEDBACK_FOR Non utilise Le canal de « feedback »

MRRU Non utilise L’utilisation de segmentation

Tableau 2: Les paramètres sont définis par la couche supérieure de PDCP[17]

3.4 Support de RoHC au terminal

Les UE qui supportent RoHC doivent supporter le profil non-compression, 0x0000 Pour les UE qui sont capables de supporter le service de voix via IMS ('IMS capable UEs supporting voice'), il faut supporter les profile suivants de RoHC 0x0000, 0x0001, 0x0002, 0x0004.[22] (annexe Support de RoHC dans l'UE (3GPP TS 36.306 V8.3.0)) C'est-à-dire les profils de ROHCv1 ont la priorité sur ceux de RoHCv2 Le support de RoHC pour UE non-capable de IMS est optionnel [23]

L'eNodeB peut recevoir des profils de RoHC que l'UE supportent par l'interrogation de l'UE, ou par la réception du message de « Initial Context Setup Request » de MME Il sauvegarde les informations afin d'établir les connexions radio avec l'UE

Pour interroger l'UE, l'eNodeB envoie le message RRC de « UECapabilityEnquiry » qui force l'UE à transmette le message de « UECapacityInformation » qui contient les profils

supportées par l'UE (annexe UE-EUTRA-Capability) Pour plus de détails, on peut consulter

le chapitre 5.6.3 de [24]

Le message de « UECapacityInformation » contient les autres informations de la capacité radio que l'UE supportent Après la réception de l'UE, l'eNodeB va transmettre ce message à MME Le MME sauvegarde les informations jusqu'à ce que l'UE lance la procédure d'attacher ou de détacher le réseau (chapitre 5.11.2 de [25]) Le MME va transmettre les informations au nouveau eNodeB pendant le handover, afin de réduire l'overhead, car la taille de message « UECapacityInformation » peut atteindre 510 octets

3.5 Procédure de déclenchement de RoHC

Cette partie décrit des étapes pour établir un service au plan de contrôle, dans lesquels le déclenchement de RoHC est montré (source principale [24]) En résumé, le RoHC est déclenché dans la procédure d'établissement de connexion de données DRB (Data Radio Bearer) Cette procédure est réalisé après l'établissement de connexion de signalisation SRB (Signalling Radio Bearer) et la procédure d'authentification RoHC sera déactivé après la suppression des connexions DRB Ci-dessous, les étapes sont développées en détails

Illustration 12: Procédure pour configurer et déclencher RoHC dans l'interface radio

Premièrement, la connexion de signalisation SRB qui sert à transmettre des messages RRC entre UE et E-UTRAN est établie par la procédure de « RRC Connextion

Réseau coeur

RRCConnectionRequest RRCConnectionSetup RRCConnectionComplete

Authentification and others NAS Procedures

RRCConnectionReconfugation (PCDP-config) RRCConnectionReconfigurationCompete

RoHC configured

RRCConnectionRelease

User data transmission (IP packets)

Etablisement » Cette procédure est déclenchée par la couche supérieure de l'UE, lorsque l'UE veut répondre un appel de paging, faire un appel, ou transmettre des messages de NAS (qui sont « piggybacked » dans les messages de RRC) L'UE envoie un message de

« RRCConnectionRequest » vers eNodeB La connexion SRB est établie lorsque l'UE reçoit

un message de « RRCConnectionSetup » d'eNodeB L'entité PDCP sera établie, en observant

la configuration courante de sécurité Ici, il n'y a pas de compression Ensuite, tous les messages d'authentification et de NAS transmis sont protégés (intégrité/chiffrement) par PDCP Si l'E-TRAN est surchargé, il peut refuser la requête de l'UE par le message

« RRCConnectionReject » qui contient le temps d'attente.

Deuxièmement, ce sont la procédure d'authentification et d'autres procédures de NAS qui ne sont pas précisées dans le cas de ce document

Troisièmement, la procédure de re-configuration sera lancée afin de contrôler le handover, de transmettre des messages NAS d'eNodeB vers l'UE, ou d'établir/modifier la connexion de données DRB au plan d'utilisateur Pour le dernier but, le message de

« RRCConnectionReconfiguration » contient des informations pour configurer la sous-couche

PDCP, PDCP-config (qui s'appelle PDCP-info dans la release précédante de release 8, annexe PDCP-info ) En conséquence, l'instance de RoHC est établie Tous les entêtes de paquets IP

au plan d'utilisateur sont compressés par RoHC L'UE répond à l'E-UTRAN par le message de

« RRCConnectionReconfigurationComplete ".

PDCP-config se compose des paramètres qui définissent l'utilisation/non-utilisation de RoHC, le nombre maximal de contexte utilisé (MAX_CID), les profils supportés Si les deux profils supportés ont en commun les 8 bits de pois faible, celui dont la valeur est la plus élevée est sélectionné RoHCv2 est donc privilégié par rapport à RoHCv1 De plus, dans les releases précédentes de la releases 8, la configuration de PDCP regroupe d'autre paramètre telle que la « Target Mode », qui décide le mode de RoHC (annexe PDCP-info )

Si l'UE ne peut pas appliquer une partie de la configuration dans le message de

« RRCConnectionReconfiguration », il lancera la procédure de re-établissement Il envoie un

message de « RCC Connection Reestablisement » qui indique le refus par la configuration, ou par le handover, mais n'indique pas des paramètres qui causent ce refus L'idée principale est

de réduire la complexité d'eNodeB L'entité PDCP est ré-établie selon la configuration précédente

Enfin, le message de « RRCConnectionRelease » va supprimer toutes les connexions de

SRB et de DRB établies si l'UE est inactif pendant longtemps ou passe à un autre eNodeB L'entité de PDCP, et l'instance de RoHC sera alors libérée.

ASN1START

PDCP-Config ::= SEQUENCE {

discardTimer ENUMERATED {

ms50, ms100, ms150, ms300, ms500, ms750, ms1500, infinity

Discussions: Transfert (relocation) de contexte de RoHC dans le cas de handover Le transfert de contexte de RoHC est un mécanisme de transmettre le contexte de RoHC de source à destination A destination, le RoHC va re-construire le contexte Cela permet RoHC