Mémoire de fin d’études Master Informatique, option...

NEXTTV4ALL

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 :

VU DINH Dau Promotion 13, IFI

Sous la direction de :

Loutfi NUAYMI TELECOM Bretagne

Xavier LE BOURDON JCP-Consult

CESSON-SÉVIGNÉ, FRANCESeptember, 2009

Mémoire de fin d'études VU DINH DauIntégration de RoHC dans l'architecture de LTE Promotion 13, IFI

Table des matièresGlossaire des Abréviations..........................................................................................................71 Introduction..............................................................................................................................9

1.1 Contexte............................................................................................................................91.2 Problématique.................................................................................................................101.3 Intérêt personnel pour ce stage.......................................................................................111.4 Objectifs de mes contributions.......................................................................................111.5 Plan du document...........................................................................................................12

2 EPS/LTE évolution de l'UMTS..............................................................................................132.1 Contexte de l'UMTS.......................................................................................................13

2.1.1 Évolution de UMTS................................................................................................132.1.2 Architecture de l'UMTS..........................................................................................15

a) Architecture générale de l'UMTS......................................................................15b) Architecture protocolaire de l'UMTS................................................................17

2.1.3 Technologies concurrentes ....................................................................................192.2 Évolution LTE................................................................................................................20

2.2.1 Contexte et exigences.............................................................................................202.2.2 Architecture de LTE...............................................................................................22

2.2.2.1 Noeuds principaux..........................................................................................232.2.2.2 Architecture protocolaire ...............................................................................25

a) Plan de contrôle..................................................................................................25b) Plan utilisateur...................................................................................................26

2.2.3 Interface radio.........................................................................................................262.2.4 La sous-couche PDCP............................................................................................272.2.5 Couche physique ....................................................................................................29

3 RoHC dans UMTS/LTE.........................................................................................................303.1 Description de RoHC.....................................................................................................303.2 RoHCv2..........................................................................................................................31

3.2.1 Motivation de proposition de RoHCv2 dans PDCP/LTE.......................................313.2.2 Améliorations et autres différences de RoHCv2 avec RoHCv1.............................313.2.3 Les profils de RoHCv2...........................................................................................323.2.4 Compresseur et décompresseur..............................................................................33

3.3 Recommandation de RoHC dans 3GPP.........................................................................333.4 Support de RoHC au terminal........................................................................................343.5 Procédure de déclenchement de RoHC..........................................................................353.6 RoHC et handover..........................................................................................................373.7 RoHC et MBMS.............................................................................................................38

3.7.1 MBMS....................................................................................................................383.7.2 RoHC et Broatcast/Multicast .................................................................................39

4 Évaluation de la performance de ROHCv1............................................................................404.1 Objectifs.........................................................................................................................404.2 Scénarios........................................................................................................................40

4.2.1 Modèle d'évaluation de performance......................................................................404.2.2 Choix de modèle de fautes......................................................................................41

4.3 Pre-tests..........................................................................................................................424.4 Résultats.........................................................................................................................43

2


4.4.1 Taux de bande passante économisée......................................................................434.4.2 Taux de paquets perdus..........................................................................................464.4.3 Nombre maximal de paquets perdus successifs......................................................464.4.4 Comparaison avec RoHC de Thales et Al..............................................................49

5 Conclusion et perspectives.....................................................................................................51Bibliographie.............................................................................................................................52Annexe A..................................................................................................................................54Annexe B...................................................................................................................................61

3


RemerciementsJe 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.

4


Résumé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 où la bande passante est limitée et coû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 sous-

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.

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

RoHCv2, IPTV.

5


AbstractLTE (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.

6


Glossaire des AbréviationsAAL2 ATM Adaptation Layer 2AAL5 ATM Adaptation Layer 5AS Access SpectrumAuC Authentication Centre

BM-SCBroadcast Multicast Service Centre

BSC Base Station ControllerBTS Base Transceiver StationCDMA Code Division Multiple AccessCS Circuit SwitchedCSCF Call Session Control FunctionCSCF Call Session Control FunctionE-CSCF Emergency CSCF

EDGEEnhanced Data rates for Global Evolution

EPS Evolved Packet SystemEV-DO Evolution Data OptimizedFDD Frequency Division DuplexFEC Forward Error CorrectionGPRS General Packet Radio Service

GSMGlobal System for Mobile communication

GTP GPRS Tunnelling ProtocolHLR Home Location Register

HSDPAHigh Speed Downlink Packet Access

HSPA High Speed Packet AccessHSS Home Subscriber ServerHSS Home Subscriber Server

HSUPAHigh Speed Uplink Packet Access

I-CSCF Interrogating CSCFIM Instant MessagingIMS IP Multimedia SubsystemIPTV Internet Protocol TelevisionISI Inter Symbol InterferenceLTE Long Term EvolutionM3UA MTP3 User Adaptation LayerMAC Medium Access Control

MBMSMultimedia Broadcast/Multicast Service

MIMO Multiple Input Multiple OutputMME Mobility Management Entity

MRF Multimedia Resource FunctionMTP3 Message Transfer Part Layer 3

MTP3BMessage Transfer Part level 3 broadband

NAS Non Access Spectrum

NGMNNext Generation Mobile Networks Alliance

OFDMAOrthogonal Frequency Division Multiple Access

P-CSCF Proxy CSCFP-GW Packet Data Network GatewayPAPR Peak-to-Average Power Ratio

PCRFPolicy Control and Charging Rules Function

PDCPPacket Data Convergence Protocol

PS Packet Switched

PSTNPublic Switched Telephone Network

RANAPRadio Access Network Application Part

RLC Radio Layer ControlRNC Radio Network ControlRoHC Robust Header CompressionRRC Radio Ressource ControlS-GW Serving GatewaySAE System Architecture Evolution

SC-FDMA Single Carrier - Frequency Division Multiple Access

SCCPSignalling Connection Control Part

SFN Single Frequency NetworkSIGCOMP Signaling CompressionSIP Session Initiation ProtocolSRAN Satellite Radio Access NetworkTDD Time Division Duplex

UDVMUniversal Decompressor Virtual Machine

UE User EquipmentUMB Ultra Mobile Broadband

UMTSUniversal Mobile Telecommunications System

7


Index des illustrationsIllustration 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])..................................................14Illustration 2: Architecture de l'UMTS (release 99)..................................................................16Illustration 3: Architecture de l'UMTS (release 5)....................................................................17Ilustration 4: L'architecture protocolaire de l'UMTS dans le plan de contrôle (domaine de PS, release 5)...................................................................................................................................17Illustration 5: L'architecture protocolaire de l'UMTS dans le plan d'utilisateur (release 5).....19llustration 6: L'architecture générale du réseau LTE................................................................22Illustration 7: La différence entre eNodeB (LTE) et NodeB (HSPA) au plan utilisateur [15]. 24Illustration 8: Plan contrôle en couches [16]............................................................................25Illustration 9: Plan utilisateur...................................................................................................26Illustration 10: La deuxième couche de l'interface radio au sens descendant [16]...................27Illustration 11: La fonction de la couche PDCP [17]................................................................28Illustration 12: Procédure pour configurer et déclencher RoHC dans l'interface radio............35Illustration 13: Modèle d'évaluation de performance de RoHC...............................................40Illustration 14: Pre-tests, le nombre maximal de paquets perdus est très haut dans O-mode...42Illustration 15: Bande passante économique dans U-mode et BER = 0.0 avec des flux différents...................................................................................................................................43Illustration 16: Taux de bande passante économisée VoIP AMR 12,2 kbps............................45Illustration 17: Taux de bande passante économisée VoIP AMR 23 kbps...............................45Illustration 18: Taux de bande passante économisée Video H264 haute qualité......................45Illustration 19: Taux de bande passante économisée Vidéo H264 moyenne qualité................45Illustration 20: Taux de paquets perdus VoIP AMR 12,2 kbps................................................47Illustration 21:Taux de paquets perdus VoIP AMR 23 kbps....................................................47Illustration 22: Taux de paquets perdus Video H264 haute qualité..........................................47Illustration 23: Taux de paquets perdus Vidéo H264 moyenne qualité....................................47Illustration 24: Nombre maximal de paquets perdus successifs VoIP AMR 12,2 kbps...........48Illustration 25: Nombre maximal de paquets perdus successifs VoIP AMR 23 kbps..............48Illustration 26: Nombre maximal de paquets perdus successifs Video H264 haute qualité.....48Illustration 27: Nombre maximal de paquets perdus successifs Vidéo H264 moyenne qualité...................................................................................................................................................48Illustration 28: Taux de bande passante économisée VoIP 12,2kbps.......................................50Illustration 29: Taux de paquets perdus VoIP 12,2kbps...........................................................50Illustration 30: Nombre maximal de paquets perdus successifs VoIP 12,2kbps......................50Illustration 31: Pile protocolaire avec la compression..............................................................55Illustration 32: SIGCOMP Architecture ..................................................................................56Illustration 33: La mémoire d’UDVM.....................................................................................58Illustration 34: Format of a SIGCOMP message......................................................................58Illustration 35: Compression SigComp.....................................................................................60

Index des tablesTableau 1: Les profils supportés par LTE [17].........................................................................33Tableau 2: Les paramètres sont définis par la couche supérieure de PDCP[17]......................34Tableau 3: Les différents flux pour évaluer la performance de RoHC.....................................41

8


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

9


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

10


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

11


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.

1.5 Plan du document

La suite de ce rapport est organisée de la façon suivante. Le deuxième chapitre présente la

série d'évolutions de technologies de 3GPP, des innovations, des caractéristiques principales

de LTE afin d'indiquer ses interactions avec des services dont IPTV. Cette partie se concentre

sur l'architecture de LTE qui permet de localiser la place RoHC dans la partie suivante. Le

troisième chapitre 3 présente le protocole RoHC et les supports de RoHC dans LTE, la

recommandation RoHCv2 et ses caractéristiques. Tous les aspects de RoHC envisagés par

3GPP release 8 sont étudiés tels que les paramètres de configuration, les profils, le processus

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.

12


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

13


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

14


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

15


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

16

NodeB

RNC

NodeB

NodeB

RNC

MSC/VLR

SGSN

GMSC

GGSN

HLR

PSDN

Internet

Réseau d'accès Réseau coeur

IuUu

Iub

Iur

PS domain

CS domain

Rel 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

17

NodeB

RNC

NodeB

NodeB

RNC

MSC Server

SGSN

GMSC Server

GGSN

HSS

PSDN

Internet

Réseau d'accès Réseau coeur

IuUuIub

Iur

PS domain

CS domain

Rel 5

CS-MGW CS-MGW

IMS

RLC

MAC

PHY

RRC RANAP

SSCOP

AAL5/ATMPHY

UE UTRAN CN

IP

UuIu

SCCP SCCF-NNI

MTP3B M3UA

SCTP

LL

RLC

MAC

PHY

RRC

RLC

MAC

PHY

RRC

RLC

MAC

PHY

RRC

ATM or IPTransport

RANAP

PHY

SCCP

ATM or IPTransport

ATM transport 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.

18

RLC

MAC

PHY

PDCP

RLC

MAC

PHY

PDCP

UDP/IP

AAL5/ATM

PHY

UE UTRAN SGSN

Uu Iu-PS

GTU-U

RLC

MAC

PHY

RLC

MAC

PHY

AAL2

ATM

UE UTRAN SGSN

Uu Iu-CS

UDP/IP

PHY

GTU-U

LL

UDP/IP

LLPHY

U-plane

ATM or IPTransport

ATM or IPTransport

RTP

Iu-CS



Iu-PS

PHY

ATM or IPTransport

ATM or IPTransport


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 inter-

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 où 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.

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

19


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

où. 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.

20


Mobilité : la performance de LTE est optimisée dans le cas où 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.

2.2.2 Architecture de LTE

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

21

Réseau d'accès

eNodeB eNodeBX2

Réseau coeur

P-GW

S-GW

MME

Plan contrôlePlan utilisateur

S1

IMS

Réseaux IP

Réseaux PSTN

Réseaux Non-3GPPWifi, Wimax

Téléphone portable'dual mode'

GERAN UTRAN

HSSGSM/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

22


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

23


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) coû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 coû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

24

eNB

PHY

UE

PHY

MAC

RLC

MAC

MME

RLC

NAS NAS

RRC RRC

PDCP PDCP


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 utilisateurLes 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).

2.2.3 Interface radio

Cette interface fournit des connexions entre UEs et eNodeB. La pile protocolaire est

donc spécifique par rapport aux autres interfaces car liée aux liens sans fils.

Elle se compose de trois couches : la première couche (physique), la deuxième couche

qui ressemble de la couche de liaison du modèle OSI, et la troisième couche (RRC).

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

25

UE

PDCPPDCP

RLC

MAC

PHY

IP

App

eNodeB

PDCPPDCP

RLC

MAC

PHY

GTP-U

UDP

S-GW P-GW

GTP-U

UDP

IP

GTP-U Tunnel

Serveurd'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.

26

Segm.ARQ etc

Multiplexing UE1

Segm.ARQ etc

...

HARQ

Multiplexing UEn

HARQ

BCCH PCCH

Scheduling / Priority Handling

Logical Channels

Transport Channels

MAC

RLC Segm.ARQ etc

Segm.ARQ etc

PDCPROHC ROHC ROHC ROHC

Radio Bearers

Security Security Security Security

...CCCH


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

27


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 où il y a un large nombre d'utilisateurs mobiles

(haut ratio de SNR et assez de diffusion « rich scattering ») [14]).

28


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.

29


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

30


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 en-

tête. Les bits de poids fort en 0x01 permettent de distinguer les profils v2 des profils v1

(0x00).

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)

31


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

Profile Identifier

Usage Reference RoHC version

0x0000 No compression RFC 4995 Commun à v1 et v2

0x0001 RTP/UDP/IP RFC 3095, RFC 4815 v1

0x0002 UDP/IP RFC 3095, RFC 4815 v1

0x0003 ESP/IP RFC 3095, RFC 4815 v1

0x0004 IP RFC 3843, RFC 4815 v1

0x0006 TCP/IP RFC 4996 v1

0x0101 RTP/UDP/IP RFC 5225 v2

0x0102 UDP/IP RFC 5225 v2

0x0103 ESP/IP RFC 5225 v2

0x0104 IP RFC 5225 v2

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

32


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.

Paramètre Obligatoire Description

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

33


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 radioPremiè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

34

UE eNodeB Serveur d'IP

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

35


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

} OPTIONAL, -- Cond Setup

rlc-AM SEQUENCE {statusReportRequired BOOLEAN

} OPTIONAL, -- Cond Rlc-AM

rlc-UM SEQUENCE {pdcp-SN-Size ENUMERATED {len7bits, len12bits}

} OPTIONAL, -- Cond Rlc-UM

headerCompression CHOICE {notUsed NULL,rohc SEQUENCE {

maxCID INTEGER (1..16383) DEFAULT 15,profiles SEQUENCE {

profile0x0001 BOOLEAN,profile0x0002 BOOLEAN,profile0x0003 BOOLEAN,profile0x0004 BOOLEAN,profile0x0006 BOOLEAN,profile0x0101 BOOLEAN,profile0x0102 BOOLEAN,profile0x0103 BOOLEAN,profile0x0104 BOOLEAN

},...

}},...

}

Texte 1: PDCP-Config information element [24]

3.6 RoHC et handover

Selon les études dans de la couche PDCP (cf. 2.4.1), on remarque LTE utilise « hard

handover ». Il y une court interruption de services quand le réseaux exécute le handover. S'il y

a pas l'interface X2 entre l'eNodeB de source et de destination. Le handover cause un taux de

perte de paquets.

L'utilisation de RoHC causse une perte de la capacité de très peu d'importance, en

comparaison avec l'effet de la mobilité. A la vitesse de 120 km/h, la mobilité causse 63% de

perte, et le « typical RoHC » causse 3% de perte. Cependant, n'utilisant pas de RoHC cause

une perte de 66% à la vitesse de 30 km/h[26].

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

36


de continuer fonctionner avec le contexte actuelle, de ne pas envoyer des packets IR pour

construire un nouveau contexte, et réduire la perte cassée par l'interruption de contexte. On

peut donc économiser la bande passante de 1.9% quand la fréquence de handover est haute, et

de 0.5 quand la fréquence de handover est base [R2-072045]. Le transfert de contexte est donc

supportée par UMTS. Mais, LTE ne supporte pas le transfert. Pour implémentation de

transfert de contexte, il faut modifier l'interface X2 pour gérer les informations de contexte, et

modifier significativement le protocole RoHC. Cependant, l'idée principale de LTE est de

mettre moins complexité. De plus, si le transfert de contexte est supporté, l'implémentation de

différentes fournisseurs de RoHC peut ne pas traiter le même lors qu'il y a le problème de

déconséquence ou la perte de paquets.

3.7 RoHC et MBMS

L'avantage de Broadcast/Multicast par rapport à l'unicast est que les données sont

transmises une fois sur un lien pour plusieurs destinataires. Cet avantage est plus important

sur l'interface radio quand nous avons un large nombre d'utilisateurs. Il ne bloque pas cette

interface pour de multiples transmissions des mêmes données.

3.7.1 MBMS

Les services MBMS (Multimedia Broadcast/Multicast Service) permettent aux

opérateurs 3G de fournir plus efficacement les applications média en concurrence avec DVB-

H. Ils diminuent le débit dans réseaux coeur et utilisent efficacement des ressources radio au

réseau d’accès. Ils ont deux modes de fonctionnement : mode broadcast et multicast. Ces deux

modes utilisent une transmission unidirectionnelle [27].

Le mode broadcast permet de diffuser des données média d’un nœud (un opérateur)

vers multiples nœuds (multiples utilisateurs) dans la zone de services. Dans le mode multicast,

le réseau n'envoie des données qu'aux cellules où il y a des abonnées (un groupe). Le mode

multicast ressemble au mode broadcast, à cela près qu'il propose des mécanismes

d’abonnement (subscripstion) et rejoindre/disjoindre du groupe [28]. Le mode multicast de

3GPP est différent du multicast IP d’IETF. Il prend en compte l’utilisation efficace des

ressources radio. Cependant, il peut être compatible avec le multicast IP.

Depuis le release 7, 3GPP apporte une nouvelle notion de SFN (Single Frequency

Network). SFN permet aux transmissions de plusieurs cellules d'être synchronisées pour

37


transmettre un même contenu. Le protocole SYNC et un serveur de MBMS-GW (e-MBMS

Gateway) sont utilisés pour diffuser le même contenu vers les eNodeBs. Une entité de MCE

(MBMS Coordination Entity) coordonne les allocations de ressources radio aux couches

RLC/MAC de ces eNodeBs. Dans la suite, 3GPP a décidé de compléter l'architecture de

MBMS dans release 9 [29].

3.7.2 RoHC et Broatcast/Multicast

Dans les releases précédentes, la compression des entêtes est réalisée soit au RNC, soit

BM-SC, et soit aux les deux (la compression au RNC remplace la compression a BM-SC). A

la couche PDCP, RoHCv1 (RFC 3095) U-mode est utilisé [28].

La performance de RoHC est meilleur si le canal de feedback est utilisé. Mais le service

de MBMS diffuse le contenu de point aux multiple utilisateurs, c'est difficile ou impossible de

traiter tous les feedback [30]. Le taux d'erreur de lien radio est plus élevé. La perte de

feedback pousse le compresseur à passer à un bas niveau de compression, même au niveau de

non-compression. De plus, lorsqu'il y a un utilisateur disjoint le groupe de multicast, le RoHC

doit passer à l'état IR. Les paquets d'envoyer aux d'autres utilisateurs ne sont pas compressés.

Cela diminue donc notablement l'efficacité de RoHC.

Selon la release 9, BM-SC supporte la compression des entêtes dans le mode broadcast.

C'est une solution plus simple. Mais il y a une duplication de RoHC dans le réseaux du coeur

(une au BM-SC, et l'autre à l'eNodeB). L'autre solution qui ne met que la compression à la

couche PDCP de l'eNodeB est plus complequée, car la difficulté de synchronisation de

contenu. L'implémentation de RoHC de fournisseurs différents n'est pas identique, et ne traite

pas la même façon dans le cas de perte, et de déséquencement de paquets [31].

38


4 Évaluation de la performance de ROHCv1

4.1 Objectifs

La performance de RoHC est évaluée de manière théorique par plusieurs travaux:[32],

[33], [34], [35], et [36]. Dans cette partie, nous nous intéressons à la performance de RoHC en

utilisant l'implémentation de JCP-Consult afin de trouver le taux de bande passante

économisée, et d'évaluer la robustesse de RoHC.

4.2 Scénarios

4.2.1 Modèle d'évaluation de performance

Illustration 13: Modèle d'évaluation de performance de RoHCLe modèle d'évaluation de performance se compose des blocs principaux suivants:

générateur des paquets IP, compresseur/décompresseur RoHC, comparateur et modèle de

fautes. Nous utilisons « VLC player » pour générer des paquets multimédia en flux selon le

protocole RTP. Ensuite, nous les passons au compresseur RoHC. Des fautes sont ajoutées aux

paquets compressés afin de simuler des fautes dans le lien radio. La simulation donne un

rapport statistique sur le nombre de paquets erronés, sur le nombre de paquets perdus, et sur

la taille d'entêtes compressés.

Nous évaluons avec des flux audio et vidéo différentes, selon le tableau 3.

39

comparateur

Modèle des fautes

Transmission des paquets compressés

Générateur de paquets IP

Paquets décompressés

Nombre de paquets erronés

Nombre de paquets perdus

Compresseur RoHC

Taille des entêtes compressés Décompresseur

RoHC


Codec Bitrate (kbps)Packet size (bytes)

Description

Narrow band audio AMR NB 12.2 23 23 octes/packet

Wide band audio AMR WB 23 60 71 octes/packet

Standard video H264 74 variableFrame size 176x144, 10 fps

High quality video H264 104 VariableFrame size 176x144, 15 fps

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

4.2.2 Choix de modèle de fautes

Pour évaluer la performance de RoHC on peut simuler les erreurs de lien radio soit par

perte de bits(BER) soit par perte de paquets. L'avantage du modèle bit perdu est qu'il peut

montrer la robustesse de RoHC avec des erreurs imprévisibles. Nous utilisons le modèle

d'aléatoire (Uniform) avec BER de 10−6 à10−3 . En théorie, BER de 10−3 peut causer 28%

paquets perdus (la probabilité d'avoir un bit d'erronés dans 40 octets de l'entêtes:

1−1−10−3

40∗8=28% ). Or, un taux de perte de plus de 10% n'est pas acceptable pour les

application multimédia. Nous ne nous intéressons pas à un BER supérieur à 10−3 .

LTE utilise les mécanismes robustes tels que ARQ à la couche RLC, HARQ à la couche

MAC, et FEC/Turbo coding à la couche PHY. Le taux de blocs erronés à la couche supérieur

de MAC est de 10−4 à 10−3 [37]. La plupart de bits erronés sont corrigés. Il n'y a que des bits

erronés en rafale qui engendrent des paquets erronés. Ces paquets sont considérés perdus. En

plus, dans le cas de handover de LTE, il y a souvent un taux de perte s'il n'y pas d'interface X2

entre des eNodeBs. Donc le taux de perte est considéré dans le test de performance de RoHC.

En général, la distribution d'erreurs dans le lien radio est le suivant : il y a des segments

erronés où tous les paquets successifs sont erronés et des segments corrects où tous les

paquets successifs sont correctes. La taille moyenne de segment correct est de 103 , la taille

moyenne de segment erroné est de 10 à 100 [38]. On utilise souvent le modèle de Gilbert

simple (2 states Markov) et Gilber-Ellibott pour présenter la distribution de fautes. Le modèle

de Gilbert simple est préféré car il y a moins de paramètres d'entrée (deux paramètres par

rapport à 4 paramètres du modèle Gilber-Ellibott). Nous fixons la taille moyenne de segments

corrects à 1000 paquets, et varions la taille moyenne de segments erronés de 10 à 100 paquets,

ce qui correspond à un taux de paquets erronés de 10−3 à10−2 .

40


4.3 Pre-tests

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

JCP-Consult a développé un outil de test qui s'appelle « synthetic tester » pour que les

ingénieurs puissent valider le fonctionnement de RoHC. Il permet de générer

automatiquement des paquets, les passer vers RoHC, de valider les sorties de test, et donne

des statistiques de tests. L'outil gérère ses propes paquets et n'est pas capable de tester des

paquets « live » qui sont capturés à partir du réseau. De plus, il est incapable de simuler :

erreurs, perte de paquets, délai, et déséquencement dans lien radio.

Number of Packets

RoHC mode

Profile BERAverage packet loss

Burst packet loss

Bandwidth reduction

Input file

5830 O 2 0.000150 0.001544 1 0.349770 amr23k01.pcap

5830 O 2 0.000200 0.553859 3223 0.349705 amr23k01.pcap

5830 O 2 0.000250 0.003774 1 0.349770 amr23k01.pcap

5766 R 2 0.000500 0.346514 8 0.120370 hightrate3gp01.pcap



Tableau 4: Des anomalies de performance de RoHC de JCP-Consult

Lors des premiers tests j'ai remarqué des anomalies, et une performance est moyenne

mauvaise. Le nombre de paquet perdus successivement en mode optimiste est très haut

jusqu'à 700 paquets successifs, figure 14, c'est à dire en pire cas l'application doit attendre

700*20ms=14s pour recevoir le paquet suivant. J'ai étudié le fonctionnement de RoHC et des

41


évaluations de performance de manière théorique pour comprendre les résultats. Ces résultats

ne correspondent pas à la théorie. Les discussions avec les ingénieurs à JCP-Consult ont

permis de corriger les bugs dans l'implémentation. A fin de mon stage, les résultats de tests

sont raisonnables et observent des résultats à manière théorique.

4.4 Résultats

Dans les résultats suivants, nous choisissons le profil IP/UDP/RTP qui correspond aux

applications multimédia telles que celles prévues dans le projet-NextTV4All.

4.4.1 Taux de bande passante économisée

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

Le taux de bande passante économisée présente l'efficacité et l'intérêt de RoHC. Le taux

de différents flux est disponible dans la figure 15. A gauche, ce sont des résultats de test avec

des paquets IPv4, et a droit, ce sont celles du paquets IPv6. Chaque colonne qui a le couleur

différent présente un type de flot.

On trouve que dans le même type de flot, l'efficacité de compression de paquets IPv6

est plus élevée par rapport à celle de paquets IPv4. De plus, dans la même version de

protocole IP, le plus « payload » est gros, le mois RoHC est intéressant. L'efficacité de RoHC

42


est proportionnelle à la taille des entêtes et inverse proportionnelle à la taille de payload.

Les résultats dans le figure 15 ne prends pas en compte des erreurs dans le lien radio qui

causent désynchronisation entre le compresseur et le décompresseur. Dans les figures 16 à 19,

nous évaluons l'efficacité de RoHC avec les taux de bits erronés différents (BER). On trouve

que si le BER augmente, le taux de bande passante économisée diminue. Le niveau de

diminution est moins de 1%. Le RoHC bidirectionnel (O-mode et R-mode) est plus efficace

par rapport à RoHC unidirectionnel lors que le BER est moins de 10−3,5 . Si le taux d'erronés

est petite, O-mode économise le plus de bande passante, mais quand le BER est supérieur à

10−3 , R-mode est le meilleur.

Dans le mode unidirectionnel, le compresseur revient périodiquement aux niveaux

inférieurs où il doit envoyer des paquets plus grands. De plus, il n'a pas de feedback, le

niveau de compression est donc constante. Cependant, dans le mode bidirectionnel, il ne

revient que aux niveaux inférieurs soit il reçoit des NACKs. La performance du mode

bidirectionnel est meilleure que celle du mode unidirectionnel, lors que le BER est petite.

Si le BER augmente, le compresseur reçoit plus de paquets NACKs, il est forcé à

revenir au niveau inférieur. L'efficacité est donc diminuée.

Quand l’erreur est petite, le mode optimiste est meilleur que le mode fiable parce que la

liaison de retour est moins utilisée. Quand l'erreur est assez grand R-mode et O-mode doivent

revenir aux niveaux inférieurs plus fréquemment. Mais le contexte de R-mode peut monter au

niveau supérieur toute suite après recevoir un ACK, cependant le O-mode doit envoyer L

paquets (niveau de confiance) avant de passer au niveau supérieur.

43

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

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

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

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


4.4.2 Taux de paquets perdus

L'utilisation de RoHC permet de diminuer la taille d'entête, donc, la perte qui est causé

par l'entête erroné diminue. Mais dans RoHC, un paquet perdu peut casser la cohérence entre

les machines d'états au compresseur et au décompresseur. Nous testons donc la robustesse du

mécanisme de re-synchronisation de RoHC.

Les figures de 20 à 23 présentent le taux moyen de perte en fonction de BER. Sur les

courbes on remarque que l'utilisation de RoHC peut diminuer la perte de paquets. Le U-mode

peut réduire à 50% de perte, et à 80% pour le R-mode. Le R-mode présente son avantage par

rapport au U-mode et au O-mode. Dans ce mode d’opération seules les paquets avec un CRC

de 7 ou 8 bits peuvent actualiser le contexte et être utilisés comme référence pour les

décompressions subséquentes. L’intégrité du contexte est donc mieux protégée[34]. De plus,

le compresseur ne passe au niveau supérieur que lorsqu'il reçoit un ACK. La perte du R-mode

est donc moins importante par rapport à O-mode.

4.4.3 Nombre maximal de paquets perdus successifs

La désynchronisation cause également une perte de paquets successifs. Les paquets

perdus causent une gigue au niveau applicatif. Nous avons réalisé des tests pour évaluer la

gigue.

Les figures de 24 à 27 présentent nombre maximal de paquets perdus successifs en

fonction du taux de paquets perdus. Quand le taux de perte est petit, le nombre est près égale à

celui de la non-utilisation de RoHC. Quand le taux de perte est supérieur de 10−2,3=0.005 .

On trouve que le RoHC augmente un peu ce nombre, en particulier, le U-mode.

Le mode unidirectionnel n'a pas de feedback. Le décompresseur doit atteindre le paquet

initial envoyé périodiquement pour se re-synchroniser avec le compresseur. Dans le mode

bidirectionnel, le décompresseur peut envoyer le NACK pour forcer le compresseur à envoyer

un paquet qui a plus d'informations (IR-Dynamic ou IR paquet) pour se re-synchroniser.

45

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

Illustration 22: Taux de paquets perdus Video H264 haute qualité Illustration 23: Taux de paquets perdus Vidéo H264 moyenne qualité

46

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

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

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

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


4.4.4 Comparaison avec RoHC de Thales et Al.

Nous comparons la performance de RoHC de l'implémentation de JCP-Consult avec

celle de l'implémentation de Centre national d’études spatiales(CNES), Thales Systèmes

aéroportés, et Viveris Technologies. Cette implémentation est sous licence de GPL et fut

publiée au cours de mon stage, en Août 2009. A l'heure actuelle, le RoHC libre ne peut

compresser des paquets qu'en profil IP/UDP, dans le mode unidirectionnel ou optimiste. Nos

tests sont donc basés sur le profil IP/UDP.

Sur les courbes de la figure 28, on remarque que la compression du RoHC libre est

plus efficace. La perte moyenne de paquet du mode optimiste de JCP-Consult est meilleure,

figure 29, mais celle du mode unidirectionnel est inférieure par rapport celles de RoHC libre.

Le niveau de paquets perdu successifs de JCP-Consult est meilleur, figure 30, par rapport à

celui de RoHC libre.

48

Illustration 28: Taux de bande passante économisée VoIP 12,2kbps Illustration 29: Taux de paquets perdus VoIP 12,2kbps

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


5 Conclusion et perspectivesLe contexte de ce stage était le projet de recherche européen NextTV4All, à JCP-

Consult, en coopération avec TELECOM Bretagne. Dans ce stage, nous nous sommes

intéressés à faire un état de l'art d'intégration de RoHC dans l'architecture de LTE.

Premièrement, nous avons présenté des innovations, et l'architecture de LTE. On

remarque que des évolutions dans la technique d'accès OFDMA, MIMO et la simplification

d'architecture basée sur le protocole IP facilitent des services multimédia comme IPTV.

Deuxièmement, nous avons présenté RoHC dans LTE. RoHC fonctionne au niveau de

la sous-couche PDCP, les profils de RoHCv1 et RoHCv2 sont supportés. On constate que

RoHC peut réduire la perte de paquets pendant le handover. RoHC est supporté dans les

services de broadcast/multicast (MBMS). RoHCv2 améliore la performance dans certains cas

tel que le handover. RoHCv2 apporte également des simplifications d'implémentation.

Troisièmement, nous avons effectué des tests sur l'implémentation de JCP-Consult de

RoHCv1. RoHC est très robuste contre des erreurs sur le lien radio, et peut réduire le taux de

perte de paquets. 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.

Nous avons 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 selon différentes distributions : Uniform, Gilbert simple, et

Gilbert-Ellibott. Les premiers résultats de test ont permit aux ingénieurs à JCP-Consult de

corriger des bugs de type chaotique. Nous avons également réalisé une comparaison de la

performance de RoHCv1 de JCP-Consult avec une implémentation compétitive. Cette

comparaison a montré qu'il était encore possible d'optimiser l'implémentation de RoHCv1.

Une étude intéressante serait la comparaison avec RoHCv2, qui est en cours de

développement au sein de l'entreprise JCP-Consult et TELECOM Bretagne. Une autre étude

intéressante concerne l'impact de RoHC sur la qualité de service (QoS) des réseaux

multimédia. En effet, nous avons vu les problèmes de gigue générés par RoHC, mais d'autres

effets sont également à prévoir, comme l'attente de synchronisation de RoHC. Je compte

d'ailleurs rester en contact avec JCP-Consult et TELECOM Bretagne pour participer à ces

études.

50


Bibliographie[1] Rémi HOUDAILLE, "Annexe technique du projet NextTV4All", v2.3, 05/2008[2] 3GPP, "Overview of 3GPP Release 4", v1.1.0, 2004[3] 3GPP, "Overview of 3GPP Release 5", 09/2003[4] 3GPP, "Overview of 3GPP Release 6", v.TSG #33, 09/2006[5] 3G Americas, "EDGE, HSPA and LTE broadband innovation", 09/2008[6] 3GPP, "Overview of 3GPP Release 7", V0.9.5, 04/2009[7] IEC, "UMTS Protocols et Protocol testing", 2003[8] 3GPP TS 23.002, "UMTS; Network architecture ", v5.6.0, 12/2002[9] 3GPP TS 23.228, " IP Multimedia Subsystem (IMS); Stage 2", v8.8.0, 03/2009[10] 3GPP TS 29.414, " UMTS; Core network Nb nata transport and transport signalling", v5.1.0, 12/2006[11] 3G Americas, "Mobile Broadband Evolution : 3GPP release 8 and beyond HSPA+, SAE/LTE and LTE-Advanced", 02/2009[12] 3GPP, "Overview of 3GPP Release 8", 04/2009[13] 3GPP TSG RAN WG1 Meeting #49 R1-072580, "LS on LTE performance verification work ", 05/2007[14] Qualcomm, "3GPP Evolution LTE", 02/2008[15] P. Lescuyer, T. Lucidarme,, "Evoled Packet System: The LTE and SAE evolution of 3G UMTS", John Wiley &Son, 2008[16] 3GPP TS 36.300, "LTE Overall description stage 2", v8.8.0, 04/2009[17] 3GPP TS 36.323, "Packet Data Convergence Protocol (PDCP) specification", v8.5.0, 04/2009[18] H. Holma, A. Toskala, "LTE for UMTS: OFDMA and SC-FDMA Based Radio Access", John Wiley &Son, 2009[19] IEC, "OFDM for Mobile Data Communications", 12/2008[20] Ericsson , "Long Term Evolution (LTE): an introduction", 10/200721: Ericsson, 3GPP TSG-RAN WG2 Meeting #59 R2-073223, Support for RoHC Profiles in LTE PDCP, 08/2007[22] 3GPP TS 36.306, "User Equipment (UE) radio access capabilities", v8.3.0, 04/2009[23] Qualcomm Europe, 3GPP TSG-RAN WG2 #60bis R2-080326, "RoHC rate capability",, 02/2008[24] 3GPP TS 36.331, "Radio Resource Control (RRC); Protocol specification", v8.5.0, 04/2009[25] 3GPP TS 23.401, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access ", v8.6.0, 06/2009[26] Henttonen T.,Aschan K., Puttonen J., Kolehmainen N., Kela P., Moisio M., Ojala J., "Performance of VoIP with Mobility in UTRA Long Term Evolution", Vehicular Technology Conference, IEEE VTC Spring, 2008[27] 3GPP TS 25.346, "Introduction of the Multimedia Broadcast/Multicast Service (MBMS) in the Radio Access Network (RAN); Stage 2", v8.3.0, 04/2009[28] 3GPP TS 23.246, "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description", v8.3.0, 03/2009[29] 3GPP TSG SA WG2 Meeting #71 S2-091686 , "Removal of eMBMS Architecture Principles from Rel-8", 02/2009[30] MARTINEZ FERNANDEZ E.G., Compression des en-têtes intra-couches pour les flux

51


multimédia multicast sur des réseaux sans fils, Thèse de doctorat, ENST Telecom Bretagne, 12/2007[31] Nokia, Siemens Networks, 3GPP TSG-RAN WG2#57bis R2-071248 , "Header Compression in MBMS for E-UTRAN", 03/2007[32] Alain Couvreur, Louis-Marie Le Ny, Ana Minaburo, Gerardo Rubino, Bruno Sericola and Laurent Toutain , "Performance analysis of an Header Compression Protocol: The RoHC unidirectionnel mode", Springer Telecommunication Systems, 2006[33] B. Wang, H.P. Schwefel, K.C. Chua, R.Kutka and C.Schmidt, "On Implementation and Improvement of Robust Header Compression in UMTS, IEEE Personal, Indoor and Mobile Radio Communications", 2002[34] Minaburo A., Compression des en-têtes sur les réseaux bas-débit, Thèse de doctorat, , 2003[35] EL HENI Neila, BADARD Benoit, DIASCORN Vincent, NUAYMI Loutfi, "Performance of RAB mapping and ROHC for the support of VoIP over UMTS", PIMRC'07, Athens, Greece, 2007[36] NUAYMI Loutfi, BOUIDA Nabil, LAHBIL Nabil, GODLEWSKI Philippe, "Headers overhead estimation, header suppression and header compression of WiMAX", 3rd IEEE international conference on wireless and mobile computing, networking and communications, 8-10 october, New York, USA, 2007[37] Anna Larmo, Magnus Lindström, Michael Meyer, Ghyslain Pelletier, Johan Torsner,and Henning Wiemann, "The LTE Link-Layer Design", Ericsson Research, 2009[38] W. Karner, P. Svoboda, and M. Rupp, "A UMTS DL DCH Error Model Based on Measurements in Live Networks ", Proc. 12th Int. Conf. Telecomm. (ICT), Capetown, South Africa, 05/2005[39] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., Rosenberg, J., "Signaling Compression (SigComp)", 02/2003[40] Price, R., Rosenberg, J., Bormann, C., Hannu, H., Liu, Z., "Universal Decompression Virtual Machine (UDVM)", working progress draft-ietf-rohc-sigcomp-udvm-00.txt, 02/2002[41] Hannu, H., "Signaling Compression (SigComp) Requirements and Assumptions", 02/2003[42] M. West, et.al. , "IP Header and Signaling Compression for 3G Systems", IEEE 3rd. International Conference in 3G Mobile Communication Technologies, 05/2005[43] H. Jin, et.Al., "Using SigComp to Compress SIP/SDP Messages ", IEEE International Conference on Communications, ICC 2005, 05/2005[44] M. Nordberg, et.al., "Improving SigComp performance through Extended Operations", IEEE 58th Vehicular Technology Conference, 10/2003[45] Rawat, P., et. Al., "Signaling Compression Mechanism analysis and deployment", Algotel, 2006

52


Annexe ASIGCOMP qui fonctionne entre la couche d'application et la couche de transport peut

réduire jusqu'à 93.8% de taille des messages SIP. SIGCOMP est contribué par Ana Carolina

MINABURO, TELECOM Bretagne, dans « l'état de l'art de l'utilisation des entêtes dans

l'architecture du LTE », de projet NextTV4All.

SIGCOMPIntroduction

Le développement des services interactifs comme l’IM (Instant Messaging), la présence et des services multimédia comme la vidéo conférence ou la TV dans le réseau 3G exige une importante bande passante. A partir de la Release 5 de l’UMTS, le protocole SIP (Session Initiation Protocol, RFC IETF 3261) est choisi pour envoyer la signalisation des communications de voix et autres sessions multimédia. Mais SIP est un protocole basé sur le texte (comme http) et il génère des paquets entre 200 et 1500 octets qui sont envoyés plusieurs fois ce qui est inefficace et augmente le délai pour l’établissement d’un appel. Le groupe de travail RoHC à l’IETF a travaillé sur la conception d’un mécanisme de compression pour les messages de signalisation SIP et pour réduire la répétition des envois. Le résultat est SigComp (Signaling Compression) [39][40].

La compression de données SigComp [39][40] permet de réduire l’augmentation de débit générée par la signalisation SIP lors de la création d’une session pour les services tels que IP-TV, VoD, Présence, IM, etc. dans les réseaux d’accès sans fil comme l’UMTS ou le LTE. L’utilisation de SigComp permet d’augmenter le débit utile et réduire le délai dans la transmission de données. La compression de SIP réduit l’utilisation de ressources radio et permet d’allouer un plus grand nombre d’utilisateurs.

Le groupe de travail RoHC à l’IETF, chargé de développer SigComp, a considéré que les terminaux de téléphonie cellulaire n’ont pas beaucoup de ressource mémoire ni un processeur assez puissante pour traiter des algorithmes très complexes [40][41]. SigComp doit donc tenir compte du fait que le terminal doit appliquer un grand nombre d’algorithmes déjà déployés dans un réseau. SigComp négocie la quantité de mémoire disponible pour la compression et n’utilise qu’un nombre réduit d’opérations pour augmenter le temps de traitement. Architecture de SIGCOMP

SigComp est un mécanisme de compression de données qui travaille entre la couche applicative et la couche transport (cf.. figure 31), pour compresser les messages de signalisation SIP (qui sont de messages texte donc sont compressés comme des données). Ces messages SIP ont une taille qui peut atteindre 500kb et ils sont répétés plusieurs fois pour assurer la fiabilité de la session. La Compression et Décompression SigComp sont faites par les entités paires qui envoient à travers des régulateurs de paquets les messages vers la couche applicative et la couche transport.

53


Illustration 31: Pile protocolaire avec la compression.

L’Architecture SigComp a trois éléments principaux (cf. figure 32) : Le Compresseur (C), le Décompresseur (D) et le gestionnaire d’état (State Handler). De plus, le protocole SigComp utilise des régulateurs de paquets pour envoyer et recevoir les messages.

Le compresseur peut utiliser une algorithme connu (Deflate, LZW, etc) ou un algorithme spécifique (EPIC, TCCP, etc). Chaque message est compressé indépendamment mais les messages d’un flux donné sont compressés avec le même algorithme. Les algorithmes plus connus feront une meilleure performance puisque le pseudo-code binaire (le pseudo code est le produit d’un compilateur pour traduire le code source en langage machine, pour SigComp le pseudo code permet un usage multi-plateformes des logiciels développés qui sont exploitables par la machine virtuelle du décompresseur) nécessaire pour décompresser les données n’est pas envoyé au décompresseur. Les algorithmes de compression de texte peuvent être basés sur :

•Un Dictionnaire : LZ, LZ77, TCCB•Une Transformée : Huffman, codes arithmétiques, Burrow-Wheeler (BWT), EPIC•Un Modèle : Prédiction avec une corrélation partielle (PPM) Le choix de l’algorithme reste un paramètre sélectionné manuellement pour SigComp.

Le compresseur réduit les messages avec l’algorithme choisi et ajoute le pseudo code binaire si nécessaire, le régulateur de paquets envoie le message compressé avec la mise à jour du pseudo code binaire pour l’algorithme de décompression qui sera utilisé par la machine virtuelle UDVM (Universal Decompressor Virtual Machine) du décompresseur. Le compresseur doit s’assurer que le décompresseur a toute l’information nécessaire pour faire la décompression. Pendant un handover le nouveau décompresseur doit recevoir l’information nécessaire pour décompresser les messages. Les messages compressés sont envoyés avec une combinaison des instructions d’UDVM qui permettent sa décompression.

Le gestionnaire d’états stocke les pseudo codes binaires et les dictionnaires, il peut être contacté par un décompresseur pour connaître cette information. Sa pleine efficacité est atteinte après un nombre de messages compressés, le premier message donne l’information de l’état de l’algorithme utilisé. Le dictionnaire peut être : Statique, Dynamique ou personnalisé. Si le dictionnaire est Statique, il peut être chargé hors ligne dans le gestionnaire pour

54


incrémenter la performance ou il peut être envoyer avec le message compressé. Le dictionnaire statique est une collection de caractères bien connus qui sont utilisés dans la plupart de messages SIP/SDP.

Illustration 32: SIGCOMP Architecture

Le décompresseur utilise une machine virtuelle similaire à une machine virtuelle Java, elle s’appelle UDVM (Universal Decompressor Virtual Machine) et elle est le noyau de SigComp. Les messages SigComp sont la combinaison de données compressées avec les instructions d’UDVM. UDVM est optimisée pour supporter différents algorithmes de compression, elle est flexible et travaille avec le pseudo code envoyé par le Compresseur. Un avantage de cette solution est l’interopérabilité entre différentes implémentations.

UDVM a un ensemble de 36 instructions (cf. tableau 5) pour manipuler les différents algorithmes de compression : Mathématiques, de Gestion de Mémoire, de Gestion de Programme et de Entrée/Sortie (I/O). La taille du pseudo code varie entre 200 et 300 octets. UDVM n’ajoute pas un délai supplémentaire au traitement des données et n’utilise pas plus de mémoire que si on définissait un seul algorithme de décompression. UDVM envoie les données décompressées comme un flux de données. Le gestionnaire de messages envoie et reçoit les messages entre SigComp et la couche applicative.

Instruction Valeur pseudo code

DECOMPRESSIONFAILURE 0

AND 1

OR 2

NOT 3

LSHIFT 4

RSHIFT 5

ADD 6


SUBTRACT 7

MULTIPLY 8

DIVIDE 9

REMAINDER 10

SORTASCENDING 11

SORTDESCENDING 12

SHA1 13

55

Application

Transport Layer

Application message &Compartment identifier

Decompressedmessage

Compartment identifier

Compressor dispatcher Decompressor dispatcher

Compressor 1

Compressor 2

State 1

State 2

Decompressor (UDVM)

SIGCOMP message SIGCOMP message

SIGCOMP

State Handler

Application

Transport Layer

Application message &Compartment identifier

Decompressedmessage

Compartment identifier

Compressor dispatcher Decompressor dispatcher

Compressor 1

Compressor 2

State 1

State 2

Decompressor (UDVM)

SIGCOMP message SIGCOMP message

SIGCOMP

State Handler



LOAD 14


MULTILOAD 15

56



PUSH 16

POP 17

COPY 18

COPYLITERAL 19

COPYOFFSET 20

MEMSET 21

JUMP 22

COMPARE 23

CALL 24

RETURN 25

SWITCH 26


CRC 27

INPUTBYTES 28

INPUTBITS 29

INPUTHUFFMAN 30

STATEACCESS 31

STATECREATE 32

STATEFREE 33

OUTPUT 34

ENDMESSAGE 35

Tableau 5: Instructions d’UDVM et les valeurs de pseudo code.

UDVM est divisé en deux parties : la mémoire et le traitement du pseudo code. Il a deux interfaces pour communiquer dans l’architecture, une avec le régulateur de paquets pour envoyer/recevoir les données compressés/décompressés, et l’autre avec le gestionnaire d’état qui lui permet de demander la création d’un état et d’accéder a un état déjà créé. L’information des acquittements est envoyée au gestionnaire d’état si le niveau transport est bidirectionnel.

La mémoire dans UDVM (cf.. figure 33) a une taille par dfault de 2kilo-octets. Avec des implémentations [42][43][44] on remarque que pour un usage minimaliste, 1kilo- octet est possible pour des algorithmes connus tandis que pour avoir une performance optimale entre 4 à 8 k octets sont nécessaires pour sauvegarder toute l’information. Les premiers 64 octets sont utilisés pour les variables de décompression comme : la taille de mémoire, les cycles, la version, la longueur de l’état et le paquet à décompresser. Ensuite il utilise 64 octets pour les variables de la compression comme : la localisation des états, l’ordre d’entrée de bits. Après le pseudo code UDVM occupe 128 octets qui sont les instructions UDVM, ensuite entre 256 octets pour le(s) dictionnaire(s) qui sont les différents pseudo codes des algorithmes de compression et le reste il peut stocker des paquets (figure 33) précédents ou les dictionnaires dynamiques ou personnalisés. La mémoire entre 64 octets et 512 octets est sauvegardée après la décompression pour améliorer l’indice de compression.

57


Illustration 33: La mémoire d’UDVM

Format de Message SIGCOMP.Les messages SigComp doivent indiquer l’algorithme de compression utilisé et toute

l’information nécessaire pour la décompression. Cette information peut faire partie du message SigComp ou elle peut être connue comme dans les états d’items disponibles dans la mémoire.

Les deux types des messages (cf. figure 34) sont différenciés par le premier octet.

Illustration 34: Format of a SIGCOMP message

Les paramètres SigCompAfin d’avoir une complète interaction entre les différentes implémentations, une série

de paramètres est utilisée pour modifier les comportements de la compression quand les capacités des paires sont très différentes :

•Taille de mémoire de décompression (Decompression_memory_size) : donne la taille de mémoire disponible pour la décompression de messages SigComp.

•Etat de la taille de mémoire (State_memory_size) : Donne le nombre d’octets pour la création d’un état, Zero si la configuration est sans état.

58

0 7

1 1 1 1 1 T len

returned feedback item

partial state identifier

remaining SIGCOMP message

0 7

1 1 1 1 1 T 0


code_len

code_len destination

uploaded UDVM bytecode


0 7

1 1 1 1 1 T len


partial state identifier


0 7

1 1 1 1 1 T 0


code_len

code_len destination

uploaded UDVM bytecode



•Cycle par bit (Cycles_per_bit) : Le nombre de cycles disponibles pour décompresser chaque bit dans le message SigComp. Un autre paramètre est utilisé par les instructions UDVM.

•Version de SigComp (SigComp_version) : Indique si seulement la version de base est disponible ou s’il y a une mise à jour dans l’implémentation

•Les états des items disponibles localement (Locally Available State Items) : L’état des items est une information qui est utilisé entre deux messages SigComp pour la décompression ou pour le dictionnaire. Ils sont créés quand un message a été décompressé avec succès.Performances de SigComp

Telecom Bretagne a testé [45] le mécanisme de compression SigComp sur une communication SIP entre deux ordinateurs, pour connaître le ratio de compression des messages SIP avec les algorithmes plus connus comme : LZ77, LZW, LZSS ou Deflate (cf. tableau 6) et on a trouvé que la compression SIGCOMP peut donner jusqu’à 93,8% de réduction de taille des messages SIP. Cela signifie qu’il est possible d’envoyer 16 fois plus de messages, d’où une réduction de la bande passante et une optimisation de son utilisation ainsi qu’une réduction du délai pour l’établissement d’une session dans la téléphonie 3G.

Algorithme de Compression

Pourcentage de Compression

Ratio

R= Taille sans compression

Taille compressée

Simple LZ77 55,2 2.2321

Adaptive LZ (compress) 78,64 4,6816

LZW 70,99 3,4470

LZSS 82,47 5,7045

DEFLATE (gzip) 93,8 16,1290

Tableau 6: Ratio de Compression pour les messages SIP [45]

La figure 35 montre les différents messages SIP compressés par les différents algorithmes et la taille qui est obtenue.

59


Illustration 35: Compression SigComp.

60


Annexe BSupport de RoHC dans la couche de PDCP(3GPP TS 36.323 version 8.5.0)

5.5 Header Compression and Decompression

5.5.1 Supported header compression protocols and profilesThe header compression protocol is based on the Robust Header Compression (RoHC) framework [7]. There are multiple header compression algorithms, called profiles, defined for the RoHC framework. Each profile is specific to the particular network layer, transport layer or upper layer protocol combination e.g. TCP/IP and RTP/UDP/IP.The detailed definition of the RoHC channel is specified as part of the RoHC framework in RFC 4995 [7]. This includes how to multiplex different flows (header compressed or not) over the RoHC channel, as well as how to associate a specific IP flow with a specific context state during initialization of the compression algorithm for that flow.The implementation of the functionality of the RoHC framework and of the functionality of the supported header compression profiles is not covered in this specification.In this version of the specification the support of the following profiles is described:

Table 5.5.1.1: Supported header compression protocols and profiles

Profile

Identifier

Usage: Reference

0x0000 No compression RFC 4995

0x0001 RTP/UDP/IP RFC 3095, RFC 4815

0x0002 UDP/IP RFC 3095, RFC 4815

0x0003 ESP/IP RFC 3095, RFC 4815

0x0004 IP RFC 3843, RFC 4815

0x0006 TCP/IP RFC 4996

0x0101 RTP/UDP/IP RFC 5225

0x0102 UDP/IP RFC 5225

0x0103 ESP/IP RFC 5225

0x0104 IP RFC 5225

5.5.2 Configuration of header compressionPDCP entities associated with DRBs can be configured by upper layers [3] to use header compression.5.5.3 Protocol parametersRFC 4995 has configuration parameters that are mandatory and that must be configured by upper layers between compressor and decompressor peers [7]; these parameters define the RoHC channel. The RoHC channel is a unidirectional channel, i.e. there is one channel for the downlink, and one for the uplink. There is thus one set of parameters for each channel, and the same values shall be used for both channels belonging to the same PDCP.These parameters are categorized in two different groups, as defined below:

61


- M: Mandatory and configured by upper layers.

- N/A: Not used in this specification.

The usage and definition of the parameters shall be as specified below.- MAX_CID (M): This is the maximum CID value that can be used. One CID value shall always be reserved for uncompressed flows. The parameter MAX_CID is configured by upper layers (maxCID [3]).

- LARGE_CIDS: This value is not configured by upper layers, but rather it is inferred from the configured value of MAX_CID according to the following rule:

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

- PROFILES (M): Profiles are used to define which profiles are allowed to be used by the UE. The list of supported profiles is described in section 5.5.1. The parameter PROFILES is configured by upper layers (profiles [3]).

- FEEDBACK_FOR (N/A): This is a reference to the channel in the opposite direction between two compression endpoints and indicates to what channel any feedback sent refers to. Feedback received on one RoHC channel for this PDCP shall always refer to the RoHC channel in the opposite direction for this same PDCP.

- MRRU (N/A): RoHC segmentation is not used.

5.5.4 Header compressionThe header compression protocol generates two types of output packets:- compressed packets, each associated with one PDCP SDU

- standalone packets not associated with a PDCP SDU, i.e. interspersed RoHC feedback packets

A compressed packet is associated with the same PDCP SN and COUNT value as the related PDCP SDU.Interspersed RoHC feedback packets are not associated with a PDCP SDU. They are not associated with a PDCP SN and are not ciphered.5.5.5 Header decompressionIf header compression is configured by upper layers for PDCP entities associated with u-plane data the PDCP PDUs are de-compressed by the header compression protocol after performing deciphering as explained in the subclause 5.6.

Les procédures de la couche de RRC (3GPP TS 136 331 V8.5.0)

5.3.3 RRC connection establishment5.3.3.1 General

62


RRCConnectionSetup


UE EUTRAN

RRCConnectionSetupComplete

Figure 5.3.3.1-1: RRC connection establishment, successful

RRCConnectionReject


UE EUTRAN

Figure 5.3.3.1-2: RRC connection establishment, network rejectThe purpose of this procedure is to establish an RRC connection. RRC connection establishment involves SRB1 establishment. The procedure is also used to transfer the initial NAS dedicated information/ message from the UE to E-UTRAN.E-UTRAN applies the procedure as follows:– to establish SRB1 only.

5.3.5 RRC connection reconfiguration5.3.5.1 General

RRCConnectionReconfigurationComplete

RRCConnectionReconfiguration

UE EUTRAN

Figure 5.3.5.1-1: RRC connection reconfiguration, successful

63


RRC connection re-establishment

RRCConnectionReconfiguration

UE EUTRAN

Figure 5.3.5.1-2: RRC connection reconfiguration, failureThe purpose of this procedure is to modify an RRC connection, e.g. to establish/ modify/ release RBs, to perform handover, to setup/ modify/ release measurements. As part of the procedure, NAS dedicated information may be transferred from E-UTRAN to the UE.5.3.7 RRC connection re-establishment5.3.7.1 General

RRCConnectionReestablishmentRequest

UE EUTRAN

RRCConnectionReestablishment

RRCConnectionReestablishmentComplete

Figure 5.3.7.1-1: RRC connection re-establishment, successful

RRCConnectionReestablishmentRequest

UE EUTRAN

RRCConnectionReestablishmentReject

Figure 5.3.7.1-2: RRC connection re-establishment, failureThe purpose of this procedure is to re-establish the RRC connection, which involves the resumption of SRB1 operation and the re-activation of security.A UE in RRC_CONNECTED, for which security has been activated, may initiate the procedure in order to continue the RRC connection. The connection re-establishment succeeds only if the concerned cell is prepared i.e. has a valid UE context. In case E-UTRAN accepts the re-establishment, SRB1 operation resumes while the operation of other radio bearers remains suspended. If AS security has not been activated, the UE does not

64


initiate the procedure but instead moves to RRC_IDLE directly.E-UTRAN applies the procedure as follows:- to reconfigure SRB1 and to resume data transfer only for this RB;

– to re-activate AS security without changing algorithms.

5.3.8 RRC connection release5.3.8.1 General

RRCConnectionRelease

UE EUTRAN

Figure 5.3.8.1-1: RRC connection release, successfulThe purpose of this procedure is to release the RRC connection, which includes the release of the established radio bearers as well as all radio resources.....5.3.7.4 Actions related to transmission of RRCConnectionReestablishmentRequest message1> set the reestablishmentCause as follows:

2> if the re-establishment procedure was initiated due to reconfiguration failure as specified in 5.3.5.5 (the UE is unable to comply with the reconfiguration):

3>set the reestablishmentCause to the value ‘reconfigurationFailure’;

2>else if the re-establishment procedure was initiated due to handover failure as specified in 5.3.5.6 (intra-LTE handover failure) or 5.4.3.5 (inter-RAT mobility from EUTRA failure):

3>set the reestablishmentCause to the value ‘handoverFailure’;

2>else:

3>set the reestablishmentCause to the value ‘otherFailure’;

PDCP-config (3GPP TS 136 331 V8.5.0)The IE PDCP-Config is used to set the configurable PDCP parameters for data radio bearers.

PDCP-Config information element

-- ASN1START

PDCP-Config ::= SEQUENCE {discardTimer ENUMERATED {

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

} OPTIONAL, -- Cond Setup

rlc-AM SEQUENCE {statusReportRequired BOOLEAN

} OPTIONAL, -- Cond Rlc-AM

rlc-UM SEQUENCE {pdcp-SN-Size ENUMERATED {len7bits, len12bits}

} OPTIONAL, -- Cond Rlc-UM

65


headerCompression CHOICE {notUsed NULL,rohc SEQUENCE {

maxCID INTEGER (1..16383) DEFAULT 15,profiles SEQUENCE {


},...

}},...

}

-- ASN1STOP

PDCP-Config field descriptionsdiscardTimerIndicates the discard timer value specified in TS 36.323 [8]. Value in milliseconds. Value ms50 means 50 ms, ms100 means 100 ms and so on.statusReportRequiredIndicates whether or not the UE shall send a PDCP Status Report upon re-establishment of the PDCP entity as specified in TS 36.323 [8].pdcp-SN-SizeIndicates the PDCP Sequence Number length in bits. Value len7bits means that the 7-bit PDCP SN format is used and len12bits means that the 12-bit PDCP SN format is used, as specified in TS 36.323 [8].maxCIDIndicates the value of the MAX_CID parameter as specified in TS 36.323 [8].profilesThe profiles used by both compressor and decompressor in both UE and E-UTRAN. The field indicates which of the RoHC profiles specified in TS 36.323 [8] are supported, i.e. value 'true' indicates that the profile is supported. Profile 0x0000 shall always be supported when the use of RoHC is configured. If support of two RoHC profile identifiers with the same 8 LSB’s is signalled, only the profile corresponding to the highest value shall be applied.

Conditional presence ExplanationSetup The field is mandatory present in case of radio bearer setup. Otherwise the field is not

present.Rlc-AM The field is mandatory present upon setup of a PDCP entity for a radio bearer configured

with RLC AM. The field is optional, need ON, in case of reconfiguration of a PDCP entity at handover for a radio bearer configured with RLC AM. Otherwise the field is not present.

Rlc-UM The field is mandatory present upon setup of a PDCP entity for a radio bearer configured with RLC UM. Otherwise the field is not present.

PDCP-info (3GPP TS 25.331)10.3.4.2 PDCP infoThe purpose of the PDCP info IE is to indicate which algorithms shall be established and to configure the parameters of each of the algorithms.

Information Element/Group name

Need Multi Type and reference

Semantics description

Version

Support for lossless SRNS relocation or for lossless DL RLC PDU size change

CV-LosslessCriteria

Boolean TRUE means support

Max PDCP SN window size CV- Enumerated(s Maximum PDCP

66





Version

Lossless n255, sn65535)

sequence number window size. The handling of sequence number when the Max PDCP SN window size is 255 is specified in [23].

PDCP PDU header MP Enumerated (present, absent)

Whether a PDCP PDU header is existent or not.

Header compression information OP 1 to <maxPDCPAlgoType>

>CHOICE algorithm type MP Note 1>>RFC 2507 Header

compression according to IETF standard RFC 2507

>>>F_MAX_PERIOD MD Integer (1..65535)

Largest number of compressed non-TCP headers that may be sent without sending a full header. Default value is 256.

>>>F_MAX_TIME MD Integer (1..255)

Compressed headers may not be sent more than F_MAX_TIME seconds after sending last full header. Default value is 5.

>>>MAX_HEADER MD Integer (60..65535)

The largest header size in octets that may be compressed. Default value is 168.

>>>TCP_SPACE MD Integer (3..255)

Maximum CID value for TCP connections. Default value is 15.

>>>NON_TCP_SPACE MD Integer (3..65535)

Maximum CID value for non-TCP connections. Default value is 15.

>>>EXPECT_REORDERING MD Enumerated (reordering not expected, reordering expected)

Whether the algorithm shall reorder PDCP SDUs or not. Default value is "reordering not expected".

67





Version

>>RFC 3095 Header compression according to IETF standard RFC 3095

REL-4

>>>Profiles MP 1 to <maxROHC- Profiles>

Profiles supported by both compressor and decompressor in both UE and UTRAN. Profile 0 shall always be supported.

REL-4

>>>>Profile instance MP Integer(1.. 3) 1 = 0x0001, 2 = 0x0002, 3 = 0x0003 (see [52])

REL-4

>>>Uplink OP Indicates the necessary information elements for Uplink.

REL-4

>>>>Max_CID MD Integer (1.. 16383)

Highest context ID number to be used by the UE compressor.Default value is 15.

REL-4

>>>Downlink OP Indicates the necessary information elements for Downlink.

REL-4

>>>>Max_CID MD Integer (1.. 16383)

Highest context ID number to be used by the UE decompressor.Default value is 15.

REL-4

>>>>Reverse_Decompression_Depth

MD Integer (0..65535)

Determines whether reverse decompression should be used or not and the maximum number of packets that can be reverse decompressed by the UE decompressor. Default value is 0 (reverse decompression shall not be used).

REL-4

Note 1: If several occurrences of the same algorithm type are included in the same IE 'header compression information', the UE behaviour is unspecified.

Condition ExplanationLosslessCriteria This IE is mandatory present if the IE "RLC mode" is

"Acknowledged", the IE "In-sequence delivery " is TRUE and the IE "SDU Discard Mode" is "No discard"

68


and not needed otherwise.Lossless This IE is mandatory present if the IE "Support for

lossless SRNS relocation or for lossless RLC PDU size change" Is TRUE, otherwise it is not needed.

10.3.4.2a PDCP RoHC target modeInformation Element/Group

nameNeed Multi Type and

ReferenceSemantics description

Version

Target Mode MP Enumerated (O-mode, R-mode)

The UE shall only transit to the signalled mode for operation of RoHC as decribed in [36].

REL-5

10.3.4.3 PDCP SN infoInformation Element/Group

nameNeed Multi Type and

ReferenceSemantics description

Receive PDCP sequence number

MP Integer(0..65535)

The PDCP sequence number, which the sender of the message is expecting next to be received.

1> set the PROFILES parameter, used by inband RoHC profile negotiation, for this PDCP entity for both UL and DL equal to the list of RoHC profiles received in the IE "PDCP info". A UE complying to this version of the protocol shall support RoHC profiles 0x0000 (RoHC uncompressed), 0x0001 (RoHC RTP), 0x0002 (RoHC UDP) and 0x0003 (RoHC ESP) (see [52]).

Support de RoHC dans l'UE (3GPP TS 36.306 V8.3.0)

4.3.1 PDCP Parameters4.3.1.1 Supported RoHC profilesThis parameter defines which RoHC profiles from the list below are supported by the UE. - 0x0000 RoHC uncompressed (RFC 4995)

- 0x0001 RoHC RTP (RFC 3095, RFC 4815)

- 0x0002 RoHC UDP (RFC 3095, RFC 4815)

- 0x0003 RoHC ESP (RFC 3095, RFC 4815)

- 0x0004 RoHC IP (RFC 3843, RFC 4815)

- 0x0006 RoHC TCP (RFC 4996)

- 0x0101 ROHCv2 RTP (RFC 5225)

- 0x0102 ROHCv2 UDP (RFC 5225)

- 0x0103 ROHCv2 ESP (RFC 5225)

- 0x0104 ROHCv2 IP (RFC 5225)

A UE that supports one or more of the listed RoHC profiles shall support RoHC profile 0x0000 RoHC uncompressed (RFC 4995).'IMS capable UEs supporting voice' shall support RoHC profiles 0x0000, 0x0001, 0x0002,

69


0x0004.4.3.1.2 Maximum number of RoHC context sessionsThis parameter defines the maximum number of header compression context sessions supported by the UE, excluding context sessions that leave all headers uncompressed.

UE-EUTRA-CapabilityThe IE UE-EUTRA-Capability is used to convey the E-UTRA UE Radio Access Capability Parameters, see TS 36.306 [5], to the network. The IE UE-EUTRA-Capability is transferred in E-UTRA or in another RAT.UE-EUTRA-Capability information element-- ASN1START

UE-EUTRA-Capability ::= SEQUENCE {accessStratumRelease AccessStratumRelease,ue-Category INTEGER (1..5),pdcp-Parameters PDCP-Parameters,phyLayerParameters PhyLayerParameters,rf-Parameters RF-Parameters,measParameters MeasParameters,featureGroupIndicators BIT STRING (SIZE (32)) OPTIONAL,interRAT-Parameters SEQUENCE {

utraFDD IRAT-ParametersUTRA-FDD OPTIONAL,utraTDD128 IRAT-ParametersUTRA-TDD128 OPTIONAL,utraTDD384 IRAT-ParametersUTRA-TDD384 OPTIONAL,utraTDD768 IRAT-ParametersUTRA-TDD768 OPTIONAL,geran IRAT-ParametersGERAN OPTIONAL,cdma2000-HRPD IRAT-ParametersCDMA2000-HRPD OPTIONAL,cdma2000-1xRTT IRAT-ParametersCDMA2000-1XRTT OPTIONAL

},nonCriticalExtension SEQUENCE {} OPTIONAL

}

AccessStratumRelease ::= ENUMERATED {rel8, spare7, spare6, spare5, spare4, spare3,spare2, spare1, ...}

PDCP-Parameters ::= SEQUENCE {supportedROHC-Profiles SEQUENCE {


},maxNumberROHC-ContextSessions ENUMERATED {

cs2, cs4, cs8, cs12, cs16, cs24, cs32,cs48, cs64, cs128, cs256, cs512, cs1024,cs16384, spare2, spare1} DEFAULT

cs16,...

}

PhyLayerParameters ::= SEQUENCE {ue-TxAntennaSelectionSupported BOOLEAN,ue-SpecificRefSigsSupported BOOLEAN

}

RF-Parameters ::= SEQUENCE {supportedBandListEUTRA SupportedBandListEUTRA

}

SupportedBandListEUTRA ::= SEQUENCE (SIZE (1..maxBands)) OF SupportedBandEUTRA

70


SupportedBandEUTRA ::= SEQUENCE {bandEUTRA INTEGER (1..64),halfDuplex BOOLEAN

}

MeasParameters ::= SEQUENCE {bandListEUTRA BandListEUTRA

}

BandListEUTRA ::= SEQUENCE (SIZE (1..maxBands)) OF BandInfoEUTRA

BandInfoEUTRA ::= SEQUENCE {interFreqBandList InterFreqBandList,interRAT-BandList InterRAT-BandList OPTIONAL

}

InterFreqBandList ::= SEQUENCE (SIZE (1..maxBands)) OF InterFreqBandInfo

InterFreqBandInfo ::= SEQUENCE {interFreqNeedForGaps BOOLEAN

}

InterRAT-BandList ::= SEQUENCE (SIZE (1..maxBands)) OF InterRAT-BandInfo

InterRAT-BandInfo ::= SEQUENCE {interRAT-NeedForGaps BOOLEAN

}

IRAT-ParametersUTRA-FDD ::= SEQUENCE {supportedBandListUTRA-FDD SupportedBandListUTRA-FDD

}

SupportedBandListUTRA-FDD ::= SEQUENCE (SIZE (1..maxBands)) OF SupportedBandUTRA-FDD

SupportedBandUTRA-FDD ::= ENUMERATED {bandI, bandII, bandIII, bandIV, bandV, bandVI,bandVII, bandVIII, bandIX, bandX, bandXI,bandXII, bandXIII, bandXIV, bandXV, bandXVI, ...}

IRAT-ParametersUTRA-TDD128 ::= SEQUENCE {supportedBandListUTRA-TDD128 SupportedBandListUTRA-TDD128

}

SupportedBandListUTRA-TDD128 ::= SEQUENCE (SIZE (1..maxBands)) OF SupportedBandUTRA-TDD128

SupportedBandUTRA-TDD128 ::= ENUMERATED {a, b, c, d, e, f, g, h, i, j, k, l, m, n,o, p, ...}


}




}



IRAT-ParametersGERAN ::= SEQUENCE {supportedBandListGERAN SupportedBandListGERAN,

71


interRAT-PS-HO-ToGERAN BOOLEAN}

SupportedBandListGERAN ::= SEQUENCE (SIZE (1..maxBands)) OF SupportedBandGERAN

SupportedBandGERAN ::= ENUMERATED {gsm450, gsm480, gsm710, gsm750, gsm810, gsm850,gsm900P, gsm900E, gsm900R, gsm1800, gsm1900,spare5, spare4, spare3, spare2, spare1, ...}

IRAT-ParametersCDMA2000-HRPD ::= SEQUENCE {supportedBandListHRPD SupportedBandListHRPD,tx-ConfigHRPD ENUMERATED {single, dual},rx-ConfigHRPD ENUMERATED {single, dual}

}

SupportedBandListHRPD ::= SEQUENCE (SIZE (1..maxCDMA-BandClass)) OF BandclassCDMA2000

IRAT-ParametersCDMA2000-1XRTT ::= SEQUENCE {supportedBandList1XRTT SupportedBandList1XRTT,tx-Config1XRTT ENUMERATED {single, dual},rx-Config1XRTT ENUMERATED {single, dual}

}

SupportedBandList1XRTT ::= SEQUENCE (SIZE (1..maxCDMA-BandClass)) OF BandclassCDMA2000

-- ASN1STOP

72

Mémoire de fin d’études Master Informatique, option...

Documents

Transcript of Mémoire de fin d’études Master Informatique, option...