rapport lte

NEXTTV4ALL

Mmoire de fin dtudes Master Informatique, option Systmes et Rseaux

Utilisation de la compression des enttes dans les rseaux cellulaires de type 4G (LTE/SAE)

Ralis par : VU DINH Dau Sous la direction de : Loutfi NUAYMI TELECOM Bretagne Xavier LE BOURDON JCP-Consult Promotion 13, IFI

CESSON-SVIGN, FRANCE September, 2009

Mmoire de fin d'tudes Intgration de RoHC dans l'architecture de LTE

VU DINH Dau Promotion 13, IFI

Table des matiresGlossaire des Abrviations..........................................................................................................7 1 Introduction..............................................................................................................................9 1.1 Contexte............................................................................................................................9 1.2 Problmatique.................................................................................................................10 1.3 Intrt personnel pour ce stage.......................................................................................11 1.4 Objectifs de mes contributions.......................................................................................11 1.5 Plan du document...........................................................................................................12 2 EPS/LTE volution de l'UMTS..............................................................................................13 2.1 Contexte de l'UMTS.......................................................................................................13 2.1.1 volution de UMTS................................................................................................13 2.1.2 Architecture de l'UMTS..........................................................................................15 a) Architecture gnrale de l'UMTS......................................................................15 b) Architecture protocolaire de l'UMTS................................................................17 2.1.3 Technologies concurrentes ....................................................................................19 2.2 volution LTE................................................................................................................20 2.2.1 Contexte et exigences.............................................................................................20 2.2.2 Architecture de LTE...............................................................................................22 2.2.2.1 Noeuds principaux..........................................................................................23 2.2.2.2 Architecture protocolaire ...............................................................................25 a) Plan de contrle..................................................................................................25 b) Plan utilisateur...................................................................................................26 2.2.3 Interface radio.........................................................................................................26 2.2.4 La sous-couche PDCP............................................................................................27 2.2.5 Couche physique ....................................................................................................29 3 RoHC dans UMTS/LTE.........................................................................................................30 3.1 Description de RoHC.....................................................................................................30 3.2 RoHCv2..........................................................................................................................31 3.2.1 Motivation de proposition de RoHCv2 dans PDCP/LTE.......................................31 3.2.2 Amliorations et autres diffrences de RoHCv2 avec RoHCv1.............................31 3.2.3 Les profils de RoHCv2...........................................................................................32 3.2.4 Compresseur et dcompresseur..............................................................................33 3.3 Recommandation de RoHC dans 3GPP.........................................................................33 3.4 Support de RoHC au terminal........................................................................................34 3.5 Procdure de dclenchement de RoHC..........................................................................35 3.6 RoHC et handover..........................................................................................................37 3.7 RoHC et MBMS.............................................................................................................38 3.7.1 MBMS....................................................................................................................38 3.7.2 RoHC et Broatcast/Multicast .................................................................................39 4 valuation de la performance de ROHCv1............................................................................40 4.1 Objectifs.........................................................................................................................40 4.2 Scnarios........................................................................................................................40 4.2.1 Modle d'valuation de performance......................................................................40 4.2.2 Choix de modle de fautes......................................................................................41 4.3 Pre-tests..........................................................................................................................42 4.4 Rsultats.........................................................................................................................43 2



4.4.1 Taux de bande passante conomise......................................................................43 4.4.2 Taux de paquets perdus..........................................................................................46 4.4.3 Nombre maximal de paquets perdus successifs......................................................46 4.4.4 Comparaison avec RoHC de Thales et Al..............................................................49 5 Conclusion et perspectives.....................................................................................................51 Bibliographie.............................................................................................................................52 Annexe A..................................................................................................................................54 Annexe B...................................................................................................................................61

3



RemerciementsJe tiens tout dabord remercier Loutfi NUYAMI qui a suivi mon travail thorique concernant l'architecture des rseaux cellulaires, et la recherche dans la grande quantit de documents de 3GPP. Il m'a donn galement des conseils sur la mthodologie 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 slectionn ma candidature de stage, et donn frquemment 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 coopration 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 Stphane 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 rseaux afin d'avoir les connaissances de base pour raliser ce stage.

4



RsumLTE (Long Term Evolution) est la dernire volution d'une srie de technologies cellulaires sans-fil GSM/UMTS/HSPA, en comptition pour tre la norme de la quatrime gnration de rseau mobile (4G). Les innovations au niveau de l'interface radio et de l'architecture plate et tout-IP permettent de rduire le dlai d'accs et d'enrichir des services multimdia comme les services de tlvision sur IP haut dbit. La compression d'enttes RoHC (Robust Header Compression) est une technologie prsente dans LTE l'interface radio o la bande passante est limite et coteuse. RoHC permet de rduire la taille des paquets IP des applications multimdia dans lesquels la taille de payload est souvent petite par rapport la taille d'entte. La deuxime version de RoHC (RoHCv2) simplifie l'implmentation de RoHC et amliore 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 connatre l'intgration de RoHC dans ce systme. Nos tudes montrent que RoHC prend place au niveau de la souscouche PDCP, et que les profils de RoHCv1 et de RoHCv2 sont prvus. Nous tudions galement le support de RoHC par LTE dans le cas de handover et dans les services de broadcast/multicast. Le deuxime axe de travail fut une campagne de tests sur l'implmentation de JCP-Consult. Elle montre que RoHC est trs robuste contre des erreurs sur le lien radio, et peut rduire 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 vido. Cependant, RoHC introduit un phnomne de gigue au niveau applicatif. Mots cls : rseau cellulaire, 4G, LTE, UMTS, PDCP, compression des enttes 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 AbrviationsAAL2 AAL5 AS AuC BM-SC BSC BTS CDMA CS CSCF CSCF E-CSCF EDGE EPS EV-DO FDD FEC GPRS GSM GTP HLR HSDPA HSPA HSS HSS HSUPA I-CSCF IM IMS IPTV ISI LTE M3UA MAC MBMS MIMO MME ATM Adaptation Layer 2 ATM Adaptation Layer 5 Access Spectrum Authentication Centre Broadcast Multicast Service Centre Base Station Controller Base Transceiver Station Code Division Multiple Access Circuit Switched Call Session Control Function Call Session Control Function Emergency CSCF Enhanced Data rates for Global Evolution Evolved Packet System Evolution Data Optimized Frequency Division Duplex Forward Error Correction General Packet Radio Service Global System for Mobile communication GPRS Tunnelling Protocol Home Location Register High Speed Downlink Packet Access High Speed Packet Access Home Subscriber Server Home Subscriber Server High Speed Uplink Packet Access Interrogating CSCF Instant Messaging IP Multimedia Subsystem Internet Protocol Television Inter Symbol Interference Long Term Evolution MTP3 User Adaptation Layer Medium Access Control Multimedia Broadcast/Multicast Service Multiple Input Multiple Output Mobility Management Entity MRF MTP3 Multimedia Resource Function Message Transfer Part Layer 3 Message Transfer Part level 3 MTP3B broadband NAS Non Access Spectrum Next Generation Mobile NGMN Networks Alliance Orthogonal Frequency Division OFDMA Multiple Access P-CSCF Proxy CSCF P-GW Packet Data Network Gateway PAPR Peak-to-Average Power Ratio Policy Control and Charging PCRF Rules Function Packet Data Convergence PDCP Protocol PS Packet Switched Public Switched Telephone PSTN Network Radio Access Network RANAP Application Part RLC Radio Layer Control RNC Radio Network Control RoHC Robust Header Compression RRC Radio Ressource Control S-GW Serving Gateway SAE System Architecture Evolution Single Carrier - Frequency SC-FDMA Division Multiple Access Signalling Connection Control SCCP Part SFN Single Frequency Network SIGCOMP Signaling Compression SIP Session Initiation Protocol SRAN Satellite Radio Access Network TDD Time Division Duplex Universal Decompressor Virtual UDVM Machine UE User Equipment UMB Ultra Mobile Broadband Universal Mobile UMTS Telecommunications System

7



Index des illustrationsIllustration 1: Le dbit des volutions diffrentes de l'UMTS (le bleu prsente le dbit en thorie, le vert prsente le dbit que l'on espre, source : [5])..................................................14 Illustration 2: Architecture de l'UMTS (release 99)..................................................................16 Illustration 3: Architecture de l'UMTS (release 5)....................................................................17 Ilustration 4: L'architecture protocolaire de l'UMTS dans le plan de contrle (domaine de PS, release 5)...................................................................................................................................17 Illustration 5: L'architecture protocolaire de l'UMTS dans le plan d'utilisateur (release 5).....19 llustration 6: L'architecture gnrale du rseau LTE................................................................22 Illustration 7: La diffrence entre eNodeB (LTE) et NodeB (HSPA) au plan utilisateur [15]. 24 Illustration 8: Plan contrle en couches [16]............................................................................25 Illustration 9: Plan utilisateur...................................................................................................26 Illustration 10: La deuxime couche de l'interface radio au sens descendant [16]...................27 Illustration 11: La fonction de la couche PDCP [17]................................................................28 Illustration 12: Procdure pour configurer et dclencher RoHC dans l'interface radio............35 Illustration 13: Modle d'valuation de performance de RoHC...............................................40 Illustration 14: Pre-tests, le nombre maximal de paquets perdus est trs haut dans O-mode...42 Illustration 15: Bande passante conomique dans U-mode et BER = 0.0 avec des flux diffrents...................................................................................................................................43 Illustration 16: Taux de bande passante conomise VoIP AMR 12,2 kbps............................45 Illustration 17: Taux de bande passante conomise VoIP AMR 23 kbps...............................45 Illustration 18: Taux de bande passante conomise Video H264 haute qualit......................45 Illustration 19: Taux de bande passante conomise Vido H264 moyenne qualit................45 Illustration 20: Taux de paquets perdus VoIP AMR 12,2 kbps................................................47 Illustration 21:Taux de paquets perdus VoIP AMR 23 kbps....................................................47 Illustration 22: Taux de paquets perdus Video H264 haute qualit..........................................47 Illustration 23: Taux de paquets perdus Vido H264 moyenne qualit....................................47 Illustration 24: Nombre maximal de paquets perdus successifs VoIP AMR 12,2 kbps...........48 Illustration 25: Nombre maximal de paquets perdus successifs VoIP AMR 23 kbps..............48 Illustration 26: Nombre maximal de paquets perdus successifs Video H264 haute qualit.....48 Illustration 27: Nombre maximal de paquets perdus successifs Vido H264 moyenne qualit ...................................................................................................................................................48 Illustration 28: Taux de bande passante conomise VoIP 12,2kbps.......................................50 Illustration 29: Taux de paquets perdus VoIP 12,2kbps...........................................................50 Illustration 30: Nombre maximal de paquets perdus successifs VoIP 12,2kbps......................50 Illustration 31: Pile protocolaire avec la compression..............................................................55 Illustration 32: SIGCOMP Architecture ..................................................................................56 Illustration 33: La mmoire dUDVM.....................................................................................58 Illustration 34: Format of a SIGCOMP message......................................................................58 Illustration 35: Compression SigComp.....................................................................................60

Index des tablesTableau 1: Les profils supports par LTE [17].........................................................................33 Tableau 2: Les paramtres sont dfinis par la couche suprieure de PDCP[17]......................34 Tableau 3: Les diffrents flux pour valuer la performance de RoHC.....................................41 8



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

1 Introduction1.1 ContexteMon stage de fin d'tudes sest droul sur une priode de 6 mois JCP-Consult, en coopration avec TELECOM Bretagne, dans le carde du projet NextTV4All du 16 Mars au 15 Septembre 2009. Le projet NextTV4All (Next TV for all: tlvision venir pour tous) est un projet du Ple Images & Rseaux, et sinscrit dans le thme tlvision 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 Tlcom, IRISA/Universit de Rennes 1, JCP Consult, Le Tlgramme, Neotilus, NEXCOM Systems, TELECOM Bretagne, Thomson Grass Valley, Thomson R&D France, Thomson Telecom. JCP-Consult est une PME, situe Cesson-Svign, dans la priphrie de la ville de Rennes, dont le domaine d'activit se prsente selon les deux axes suivants : Expertise, standardisation et montage de projets de Recherche et Dveloppement, Le dveloppement de piles de protocole rseaux, notamment les protocoles de notamment concernant les projets de recherches europens ; compression des enttes RoHC. Dans le projet NextTV4all, JCP-Consult participe l'tude de la qualit de service inter-couches , c'est--dire la corrlation entre mtadonnes associes au contenu, signalisation, rservation 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 implmente une pile RoHCv2 afin d'tudier les qualits et les dfauts de ce protocole. TELECOM Bretagne est une Grande cole d'ingnieur gnraliste et un centre de recherche international dans les sciences et technologies de l'information. Le dpartement de recherche RSM (Rseau, Scurit et Multimdia) de TELECOM Bretagne Rennes est actif 9



dans lenseignement et la recherche sur les rseaux et en particulier sur la qualit de service et les nouvelles architectures. Le dpartement est actuellement impliqu dans plusieurs projets portant entre autres sur la QoS et les NGN (Next Generation Network), est membre du rseau dexcellence EuroFGI et participe la standardisation de lInternet lIETF. Dans le projet, une des contributions de TELECOM Bretagne est de raliser des tudes sur la standardisation de RoHCv2. Mon stage fut encadr en partenariat avec ces deux entreprises : Loutfi Nuyami, matre de confrences de TELECOM Bretagne, a suivi le travail Xavier Le Bourdon, ingnieur de recherche de JCP-Consult, a suivi le travail thorique concernant des normes de 3GPP, en particulier, l'architecture de LTE. pratique concernant les tests de la performance de RoHC.

1.2 ProblmatiqueL'volution des technologies pour rseaux mobiles (2G, HSPDA) et maintenant LTE offrent des dbits de plus en plus importants atteignant jusqu' 100Mbps. Ces dbits permettent alors l'accs aux services multimdia sur tlphone mobile. Au-del des technologies de transport, LTE est bas sur un architecture plate et tout-IP . Cette volution simplifie l'intgration avec l'architecture IMS qui permet l'inter-fonctionnement entre tous types de rseaux (fixe, mobile, sans fil). La taille des paquets dans les flux multimdias associs la voix ou la vido est petite (20 60 octets); l'encapsulation RTP/UDP/IP utilise reprsente donc une part importante du paquet (40 octets pour IPv4 et 60 octet pour IPv6), la compression d'en-tte RoHC (RObust Header Compression, dfini dans le RFC3095 de l'IETF) permet donc une augmentation trs importante de la capacit du rseau dans le cas de flux multimdias interactifs. De plus RoHC a t adopt dans la release 5 de l'UMTS. La premire version, RoHCv1 (RFC 3095), est dores et dj incluse dans les systmes de tlphonie en cours de dploiement. Une seconde version de RoHCv2 (RFC 5225) est actuellement en phase de conception. Elle prend en compte des dsquencements de paquets entre compresseur et dcompresseur, par exemple pour compresser les tunnels IP dans le cadre de la mobilit. Elle apportent galement des simplifications pour RoHCv1. 3GPP a prvu dintgrer cette version dans les futures architectures LTE. Le projet NextTV4All a pour objectif de prparer les futurs services multimdia des 10



rseaux IMS[1], partir de l'analyse et du dveloppement des diffrents services unitaires et des quipements. Le projet se terminera alors par une phase d'intgration des quipements et des services dvelopps, permettant de vrifier la validit des choix techniques. Une des contributions de JCP-Consult est d'tudier et d'intgrer la compression des enttes dans les rseaux. Les tudes visent rpondre deux questions : Comment intgrer 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 rseau tels que la mobilit et la diffusion broadcast/multicast sur la performance de RoHC ?

1.3 Intrt personnel pour ce stage LTE est la dernire volution dans une srie de technologies de GSM/UMTS/HSPA dominantes, un candidat la future 4G. Cependant, les rseaux mobiles actuels au Vietnam sont considrs la gnration 2,5G, et avec une volution proche prvue 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 dveloppements. Je souhaite devenir un ingnieur de recherche, donc, une exprience dans un entreprise de Recherche & Dveloppement comme JCP-Consult fut trs formateur.

1.4 Objectifs de mes contributionsL'objectif principal de mon stage tait de contribuer l'tat de l'art d'intgration 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'intgration de RoHC dans l'architecture de LTE qui tudie compltement des aspects de RoHC dans les rseaux LTE. Des tudes de documents indiquent l'endroit de la compression/dcompression, les profils supports, les paramtres et procdures dfinis 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'implmenter RoHC, d'envisager les impacts de RoHC avec la qualit de services, et de vrifier le choix de technologique. En interne pour l'entreprise JCP-Consult 11



J'ai dvelopp 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 errons, et des pertes de paquets. Les fautes peuvent tre gnres selon les diffrents distributions de Uniform, Gilbert simple (ou 2-states Markov), et Gilbert-Ellibott. Le simulateur permet dans la suite de simuler l'autre caractristique telle que le problme de dlai et dsquencement du lien radio. L'outil de test permet d'valuer la performance de RoHC partir des paquets live qui sont capturs du rseau. Lors de mes tests de la performance de RoHCv1, j'ai trouv des anomalies par rapport des valuations de performance de manire thorique. Les discussions avec les ingnieurs JCP-Consult ont permis de corriger des bugs dans l'implmentation. A la fin de mon stage, les rsultats de tests sont raisonnables et correspondent aux attentes thoriques. De plus, j'ai compar la performance de RoHCv1 de JCP-Consult avec une autre implmentation afin d'amliorer implmentation de JCP-Consult l'avenir. Tout cela permet de refaire des tests avec l'implmentation de RoHCv2 qui est en train d'tre dveloppe.

1.5 Plan du documentLa suite de ce rapport est organise de la faon suivante. Le deuxime chapitre prsente la srie d'volutions de technologies de 3GPP, des innovations, des caractristiques 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 troisime chapitre 3 prsente le protocole RoHC et les supports de RoHC dans LTE, la recommandation RoHCv2 et ses caractristiques. Tous les aspects de RoHC envisags par 3GPP release 8 sont tudis tels que les paramtres de configuration, les profils, le processus de dclenchement, et la recommandation de RoHC dans le cas de handover et dans les services de broadcast/multicast. Le quatrime chapitre prsente les rsultats d'valuation de performance de RoHC et les impacts sur la qualit de services. Les tests de performance sont raliss partir de l'implmentation de JCP-Consult. Enfin, une solution d'optimisation de transmission au niveau d'application par SIGCOMP est tudie.

12



2 EPS/LTE volution de l'UMTS2.1 Contexte de l'UMTS 2.1.1 volution de UMTSUMTS comporte des volutions qui sont dfinies par les releases suivantes : La premire, release 99, est publie mi-1999. Cette version utilise une nouvelle interface radio qui se base sur CDMA (l'accs multiple rpartition en codes). Il y a deux types de rseau d'accs : FDD et TDD (TD-CDMA). Les interfaces radio des deux rseaux d'accs sont supportes par l'ATM. Le dbit maximal dans le sens descendant est, en thorie, de 2 Mbps, et dans le sens montant est de 768 kbps. Le rseau du cur se base sur le rseau de transport du GSM et GPRS. La release 4 de l'UMTS est termine en mars 2001. Cette version ajoute la deuxime interface radio de type TDD, TD-SCDMA. Cette interface utilise un dbit chip infrieur (1,28 Mcps) par rapport au TD-CDMA (3,84 Mcps) afin de sadapter la bande infrieure (donc 6MHz) que la bande traditionnelle de TDD. La release 4 apporte une volution importante dans le rseau cur qui spare la signalisation de la transmission ( call and bearer separation ). En consquence, le MSC se divise entre le serveur de MSC pour assurer le contrle 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 termine en mars 2002, et apporte des volutions significatives. Cette version inclut deux volutions dans le rseau UMTS : le support dIP au niveau du rseau coeur et HSDPA. Le protocole IP est considr afin de remplacer l'ATM dans la couche de transport. Le mcanisme de HSDPA se base sur le canal radio qui est partag entre tous les utilisateurs dans le sens descendant, sur l'valuation en temps rel du canal radio, et sur la retransmission rapide (HARQ) afin d'augmenter le dbit descendant, en thorie, 14,4 Mbps. De plus, la nouvelle architecture IMS (IP Multimedia Subsystem) apporte une volution importante dans le rseau cur afin de mieux supporter des applications IP telles que : partage audio/vido, video streaming , VoIP, ... Et le SIP (Session Initiated Protocol) est le protocole principal d'IMS afin de contrler les sessions tablies.[3] La release 6 est termine en mars 2005. Cette version apporte le mcanisme de HSUPA afin d'accrotre le dbit montant maximal, en thorie 5.76 Mbps. Le HSUPA utilise des 13



techniques comme HSDPA telles que HARQ, mais des canaux radio partags sont remplacs 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 utilise souvent par des applications telles que la tlvision mobile.[4]

Illustration 1: Le dbit des volutions diffrentes de l'UMTS (le bleu prsente le dbit en thorie, le vert prsente le dbit que l'on espre, source : [5]) La release 7 est termine en juillet 2007. Cette version apporte des amliorations sous le nom de HSPA+ pour HSPA. En thorie, HSPA+ permet au dbit descendant d'atteindre 42.2 Mbps, au dbit montant d'atteindre 11.5 Mbps. Le troisime choix pour l'interface radio

14



de type TDD a le dbit chip de 7,68 Mcps. La technique de CPC (Continuous Packet Connectivity , Connectivit permanente pour les utilisateurs des services paquets) est utilise pour diminuer l'interfrence cause par des canaux dedicated physical control lorsqu'il ny a aucun utilisateur sur ces canaux. Cela permet au terminal de steindre aprs une priode d'inactivit de ces canaux, donc de diminuer sa consommation d'nergie.[6] La release 8 est en cours dachvement. 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 termine avec des exigences de haute priorit et des caractristiques essentielles. La release 9 dveloppe les caractristiques manquantes. La release 10 se concentre sur LTE-Advanced.

2.1.2 Architecture de l'UMTSa) Architecture gnrale de l'UMTS

L'architecture gnrale du rseau UMTS se compose d'un rseau d'accs et d'un rseau cur (figure 2). Le rseau d'accs (UTRAN) regroupe des fonctions permettant de transmettre des informations (trafic de donnes et trafic de signalisation) de l'utilisateur vers le rseau cur. 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 contrle 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 rception du signal radio, de la modulation/dmodulation, du codage de canal, l'adaptation du dbit de transmission, largissement/des-largissement, et du contrle de la puissance dmission, et de la synchronisation.[7] Le rseau cur regroupe des fonctions permettant l'acheminement des donnes d'utilisateur vers la destination correspondante, la gestion d'appel, de la mobilit, de lauthentification, de la scurit des changes et de la taxation. Dans le rle d'acheminement, le rseau cur 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 rseaux de tlphonie donc PSTN, et PLMN. Le domaine PS comprend le SGSN et le GGSN servant communiquer avec les rseaux tels que Internet. En communiquant avec les bases de donnes partages telles que HLR, EIR, AuC, les composants ralisent galement les fonctions de gestion des utilisateurs, de la taxation, et de la scurit. Le rseau cur n'est pas obligatoire relie l'UTRAN, mais supporte aussi d'autres technologies d'accs radio telles que HIPERLAN 2, IEEE 802.11, et SRAN (Satellite Radio Access Network). Rel 99 Uu IubNodeB NodeB RNC MSC/VLR HLR GMSC

Iu CS domainPSDN

IurRNC

PS domainNodeB SGSN GGSN Internet

Rseau d'accs

Rseau coeur

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 sparer le plan de contrle et d'utilisateur. Cela permet l'oprateur d'largir la taille et d'optimiser la topologie du systme. Dans release 5 (cf. figure 3)[8], le HSS (Home Subscriber Server) remplace le HLR et AuC, et le sous-systme IMS (IP Multimedia Subsystem) est ajout. LIMS est une architecture overlay servant tablir, modifier et contrler des sessions tablies avec les rseaux IP afin de mieux supporter des applications IP telles que : partage de audio/vido, video streaming , VoIP, .... LIMS utilise le domaine PS pour transmettre des messages de signalisation et des donnes multimdia. Il est indpendant du domaine CS, mme sils partagent quelques composants tels que HSS. Le protocole SIP (Session Initiated Protocol) est le protocole principal de signalisation IMS. LIMS se compose des entits fonctionnelles 16



principales CSCF(Call Session Control Function) (P/I/S/E-CSCF), AS, MRF, PCRF et diffrents SBC. L'architecture de rfrence et les fonctions d'entits IMS sont prsentes dans TS 23.228 [9]. Rel 5 Uu IubNodeB NodeB RNC

Iu

CS-MGW

CS-MGW

CS domainPSDN

MSC Server GMSC Server

Iur

HSS

PS domainNodeB RNC SGSN GGSN

IMS

Internet

Rseau d'accs Rseau coeur Illustration 3: Architecture de l'UMTS (release 5)b) Architecture protocolaire de l'UMTS

Le modle protocolaire de l'UMTS se compose dun ensemble de divisions verticales et horizontales. La division horizontale spare l'interface en plusieurs des couches. La division verticale comprend le plan de contrle et d'utilisateur. Le plan d'utilisateur transmet des donnes d'utilisateur. Le plan de contrle transmet des messages de signalisation (source principale [10]).

C-planeRRC RLC MAC PHY UE

UuRRC RLC MAC PHY RANAP SCCP ATM or IP Transport PHY UTRAN

IuRANAP SCCP ATM or IP Transport PHY CN

ATM transport M3UA MTP3B

IP transport M3UA SCTP IP LL

SCTP SCCF-NNI IP SSCOP

AAL5/ATM

Ilustration 4: L'architecture protocolaire de l'UMTS dans le plan de contrle (domaine de PS, release 5) Dans le plan de contrle l'interface Iu (cf. figure 4), le protocole RANAP (Radio Access Network Application Part) regroupe des fonctions ncessaires pour connecter le rseau d'accs avec le rseau cur telles que : paging, allocation de ressources, gestion de la 17



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 base 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 base sur le protocole SCTP/IP. Dans le plan d'utilisateur du domaine PS (cf. figure 5), les donnes 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 enttes, de chiffrer les paquets et de transmettre des paquets sans accuss de rception vers le nouveau SRNC pendant un processus de re-allocation de SRNC. Dans le domaine CS, des donnes d'utilisateur sont transmises directement via l'AAL2 ou protocole RTP/UDP/IP l'interface Iu. L'AAL2 donne des connexions qui assurent le dlai minimale et permettent de transmettre au dbit variable. AAL2 et RTP supportent des donnes multimdia [7].

U-planePDCP RLC MAC PHY UE

UuPDCP RLC MAC PHY UTRAN GTU-U ATM or IP Transport PHY

Iu-PSGTU-U ATM or IP Transport PHY SGSN ATM transport IP transport UDP/IP AAL5/ATM UDP/IP LL

IuPS

UuRLC MAC PHY UE RLC MAC PHY ATM or IP Transport PHY UTRAN

Iu-CSATM or IP Transport PHY SGSN

ATM transport IP transport AAL2 ATM RTP UDP/IP LL

Iu-CS

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 rpandu et la couche de transport via IP est un choix optionnel. Mais depuis release 5, les deux ont la mme priorit. Le protocole SCCP (Signalling Connection Control Part) est choisi pour supporter ces deux couches de transport. En gnral, dans le rseau 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



2.1.3 Technologies concurrentesEn Juin 2008, 1xEV-DO, un successeur de CDMA-2000, a t dploy. En comparaison avec HSPA, EV-DO peut gagner une mme efficacit spectrale[11]. La difficult d'utilisation pour l'ensemble du service de voix des donnes limite le dploiement dEV-DO. 3GPP2 a introduit EV-DO RevB dont le dbit sur une bande passant de 20MHz atteint 73,5Mbps et UMB qui se base sur OFDMA. Cependant, aucun oprateur 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 considr comme une technologie qui peut potentiellement remplacer la technologie cellulaire dans les rseaux sans fil dans les zones tendues. Cette technologie est ajoute lIMT-2000 (technologie de 3 G). Elle se base sur la norme IEEE 802.16 qui peut tre dploye 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 interBTs, et inter-oprateurs. En thorie, la performance de WiMax est comptitive avec le HSPA+/LTE, avec les mmes innovations l'accs radio telles que OFDMA, MIMO. Mais, la performance de WiMax est diminue dans une zone urbaine o se trouve un large nombre d'utilisateurs. De plus, WiMax est teste dans un nombre limit de zones, pas dploye globalement et peu d'oprateurs 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'intrt auprs des oprateurs. Metro Wi-Fi peut-tre une technologie complmentaire qui fournit de l'accs large bande en centre ville, cependant la technologie 3G fournit dj de l'accs sur une zone plus vaste. Aujourd'hui, GSM/UMTS/HSPA est une srie de technologies dominantes[5] avec des volutions continuelles. LTE est la dernire volution de cette srie, en voie pour tre la rfrence 4G. Au troisime trimestre 2008, NGMN (Next Generation Mobile Networks Alliance) a choisi LTE comme une technologie qui peut rpondre elle-seule aux exigences des rseaux mobiles de la prochaine gnration [11].

2.2 volution LTE 2.2.1 Contexte et exigencesLe dveloppement rapide des services de partage audio/vido (Youtube, Flickr), media

19



streaming (VoIP, IPTV), rseaux sociaux (Facebook, MySpace) dans le domaine filaire... gnre de grandes quantits de donnes. Par ailleurs, un large nombre dquipements qui permet daccder aux services sont disponibles aux utilisateurs tels que : ordinateur portable, PDA, smartphone, "notebook enabled modem" ... Lutilisateur a donc besoin dutiliser ces services avec la mme exprience sur le domaine sans-fil, en particulier sur les rseaux cellulaires qui permettent lutilisateur dtre connect accder n'importe quand, n'importe o. Ces donnes vont produire un dbit lev sur ces rseaux qui, jusqu'alors, s'intressent principalement au service de voix, pas aux services de donnes. Les services de donnes sont diffrents des services de voix par: le dbit trs variable, la QoS diffrente pour chaque utilisateur/service, l'utilisation frquente de connexion IP. Les quipements ont donc tendance utiliser des connexions natives IP sans traduction et filtrage pour supporter efficacement ces services. Lvolution du cur des rseaux tlphonies arrive une architecture tout IP qui supporte plus efficacement les connexions IP et un rseau entirement par commutation des paquets facilite les mcanismes de QoS et lutilisation plus efficace des ressources. En gnral, LTE a pour but d'offrir un haut dbit dans le sens montant et descendant, de rduire le dlai d'accs, d'utiliser une bande passante de manire flexible, et d'interfonctionner avec les rseaux existants (3GPP et non-3GPP). Cela permet l'oprateur de fournir des services tels que VoIP, vido-confrence, jeux vido en ligne, IPTV, et l'autre service des donnes interactifs. Les caractristiques principales de LTE sont (source principale [12]) : Amlioration de linterface radio afin daugmenter le dbit montant/descendant, et la capacit, ainsi que la performance en bordure de cellule. LTE utilise lOFDMA pour le sens descendant et SC-FDMA pour le sens montant, en combinaison avec de nouvelles technologies dantenne telles que MIMO et beaming form . Il est prvu d'obtenir un dbit descendant de 100 Mbps; et un dbit montant maximal de 50 Mbps sur une bande passante de 20MHz. Mais en thorie, le dbit descendant peut atteindre 326.4Mbps with 4x4 MIMO, et le dbit montant peut atteindre 86.4 Mbps sur la bande passante de 20 MHz [13]. Une cellule peut supporter au moins 200 dutilisateurs la bande de 5MHz, et 400 d'utilisateurs la bande plus large que 5MHz [14]. Rduction du dlai d'accs : le dlai d'aller-retour est infrieur moins de 10ms et d'initialisation est infrieur 100 ms afin de supporter des services interactifs et temps rel. 20



Mobilit : la performance de LTE est optimise dans le cas o la vitesse est

infrieur que 15km/h. LTE supporte la vitesse de 120 350 km/h (voire 500 km/h, selon la bande utilise) Flexibilit du spectre radio : LTE peut-tre dploy dans des bandes allant de 1,25 MHz 20 Mhz, et la bande apparie et non apparie de la 3G. Cela permet l'oprateur de dployer 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 rseau du cur vers une architecture tout IP qui est envisage pour simplifier l'inter-fonctionnement avec les rseaux filaires et les rseaux sans fils non-3GPP. Architecture simplifie permet d'amliorer l'extensibilit du rseaux. Compatibilit avec les rseaux 3G existants. Il faut que LTE supporte le handover

avec les rseaux 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 LTEIMS Rseau coeur P-GW MME S-GW Plan utilisateur S1 Plan contrle GERAN UTRAN HSSGSM/UMTS rseau coeur

Rseaux PSTN Rseaux IP

Rseaux Non-3GPP Wifi, Wimax

eNodeB

X2

eNodeB Rseau d'accs

Tlphone portable 'dual mode'

llustration 6: L'architecture gnrale du rseau LTE 21



La figure 6 prsente l'architecture gnrale d'un rseau LTE qui se compose d'un rseau d'accs et d'un rseau cur et d'autres blocs qui permettent aux rseaux LTE de se connecter avec les rseaux 3GPP existants, les rseaux IP, rseaux tlphoniques commuts (PSTN) et les rseaux non 3GPP tels que WiFi, Wimax. Le tlphone portable dual mode fournit l'accs au rseau LTE et aussi aux rseaux 3GPP existants. En comparaison avec l'architecture de UMTS et GSM, le rseau LTE a moins de nuds afin de rduire le dlai et d'augmenter la performance du systme [14].2.2.2.1 Noeuds principaux

L'architecture de rseau cur est base sur le protocole TCP/IP. Cela permet de simplifier l'interfonctionnement avec les rseaux fixes et non-3GPP. En comparaison avec le cur GPRS du rseau UMTS, le rseau cur a moins de nuds, mais chaque nud s'occupe de plus fonctions. Il y a trois nuds principaux : MME au plan contrle, S-GW et P-GW au plan utilisateur. (source principale [15]) S-GW (Serving Gateway) achemine des paquets de l'eNodeB vers le rseau cur et vice-versa. Il est comme une ancre locale qui sert pour la mobilit inter-eNodeBs et vers les rseaux 3GPP (interconnexions de LTE avec les autres 3GPP). Les paquets transmis intereNodeBs (et inter-rseaux 3GPP) sont en transit via cette ancre. P-GW (Packet Data Network Gateway) fournit des connexions entre rseau LTE et d'autres rseaux IP, PSTN, non-3GPP. L'allocation dadresse 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 rseaux PSTN et rseaux IP grce lIMS, une architecture overlay par rapport au LTE, servant tablir, modifier et contrler des sessions. MME (Mobility Management Entity) se compose des fonctions principales dans le plan de contrle. Il sert grer des sessions : signalisation, et ngociation des qualits de service, fournir des procdures de scurit telles que : initiation, et ngociation de chiffrement/protection d'intgrit, et mettre jour la position de l'UE. HSS (Home Subscriber Server) est une base de donnes qui remplace le rle de HLR et AuC qui taient dj introduits dans les rseaux 2G et 3G. Le standard ne prcise pas l'architecture physique de rseau du cur. On peut sparer MME S-GW afin diminuer les interfrences entre la signalisation du plan de contrle et flux 22



de donnes levs du plan utilisateur. On peut sparer P-GW avec MME et S-GW afin d'isoler les paquets internes (du rseau cur) avec des paquets externes (des autres rseaux IP). L'isolation facilite les oprations de scurit. Le rseau d'accs est rduit dans l'eNodeB qui joue le rle du NodeB et du RNC (Radio Network Control) dans les rseaux UMTS. Cela permet de rduire le dlai d'accs et de simplifier la fonction d'opration et de maintenance du rseau [14].

Illustration 7: La diffrence entre eNodeB (LTE) et NodeB (HSPA) au plan utilisateur [15] Dans le rle du NodeB, l'eNodeB s'occupe de : la modulation/dmodulation, le codage/ dcodage des informations transmises sur l'interface radio. Dans le rle du RNC, l'eNodeB s'occupe : du contrle de ressources, du contrle de la mobilit, de la compression des enttes IP, et du chiffrement des donnes (voir 3GPPP TS 36.300, chapitre 4.1) L'architecture traditionnelle de l'UMTS rserve la complexit et les nombreux calculs au RNC, et permet ainsi au NodeB de rester simple. Le RNC gre donc de nombreux (mme des centaines [15]) de NodeBs et se coordonne avec les autres RNC pour contrler la macrodiversit (afin de rduire l'interfrence dans le rseau UTRAN base sur la couche physique 23



de CDMA). Les eNodeB peuvent se connecter directement avec le rseau cur pour rpartir le travail de RNC par l'interface S1. De plus, le mcanisme de retransmission qui est entirement implment dans l'eNodeB diminue le dlai. En effet, l'UMTS/HSDPA spare physiquement la retransmission entre NodeB (mcanisme de HARQ) et RNC (mcanisme de ARQ). La sparation conduit l'utilisation de deux tampons dans le NodeB et dans le RNC, ce qui augmente le dlai 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 (troisime couche) cote donc plus cher. Les eNodeB peuvent se connecter par l'interface X2 pour transmettre des paquets aux tampons, la couche infrieure (deuxime couche), la retransmission cote donc moins cher.2.2.2.2 Architecture protocolaire

Comme le modle d'interface dUMTS, le modle de LTE se compose d'un ensemble de couches verticales et horizontales. Les couches horizontales sont bases sur le modle OSI. Les couches verticales divisent l'interface entre le plan de contrle et le plan utilisateur. La division verticale correspond la faon de sparer les flux de donnes. Les donnes du plan de contrle sont transmises avec des contraints de scurit, de fiabilit plus importantes. Celles du plan utilisateur sont transmises par des protocoles plus simple.a) Plan de contrle

Le plan de contrle 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 procdures entre mobile et rseau cur.UE NAS RRC PDCP RLC MAC PHY RRC PDCP RLC MAC PHY eNB MME NAS

Illustration 8: Plan contrle en couches [16] La pile protocolaire l'interface radio est presque la mme que celle du plan utilisateur. Mais les paquets du plan contrle sont transmis avec la priorit suprieure et une protection 24



radio suprieure grce la couche MAC qui transmet des canaux logiques vers les canaux de transport correspondants.b) Plan utilisateur

Le plan utilisateur regroupe l'ensemble des donnes d'usager et des signalisations au niveau application. La figure 9 prsente l'architecture protocolaire du plan utilisateur. La couche d'application n'est prsente qu lUE et quau serveur d'application bas sur le protocole IP. Les donnes du plan utilisateur sont transparentes pour le cur de rseaux.App IP PDCP RLC MAC PHY UE PDCP RLC MAC PHY eNodeB S-GW P-GW Serveur d'application GTP-U UDP GTP-U Tunnel IP GTP-U UDP App IP

Illustration 9: Plan utilisateur Les donnes sont transmises par un tunnel GTP-U. GTP-U est une partie du protocole GTP, l'autre partie est GTP-C lie au plan contrle. 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 dplacement de l'utilisateur. Le protocole GTP est transmis via UDP/IP. La pile du protocole GTP/UDP/IP ajoute donc 36 octets d'entte (20 octets dIPv4, 8 octets dUDP, et 8 octets de GTP).

2.2.3 Interface radioCette interface fournit des connexions entre UEs et eNodeB. La pile protocolaire est donc spcifique par rapport aux autres interfaces car lie aux liens sans fils. Elle se compose de trois couches : la premire couche (physique), la deuxime couche qui ressemble de la couche de liaison du modle OSI, et la troisime 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 libration de ressources radio, diffusion de linformation du systme, paging, handover, transfert du contexte utilisateur entre eNodeB pendant le handover, mesure et gestion dnergie. RRC (RRC Connection Reconfiguration Messages/procedures) se compose 25



des informations de la configuration des Radio Bearers qui contient des paramtres de la couche infrieure telles que la configuration pour la compression des enttes de la couche PDCP[Annexe : PDCP Info]. La fonction principale de la deuxime couche est de donner un transport fiable entre deux quipements du rseau. A ct de MAC et RLC, deux sous-couches de la couche de liaison traditionnelles, 3GPP ajoute une sous-couche PDCP (cf. figure 10).Radio Bearers ROHC PDCP Security Security Security Security ROHC ROHC ROHC

RLC

Segm. ARQ etc

...

Segm. ARQ etc Logical Channels

Segm. ARQ etc

...

Segm. ARQ etc

CCCH BCCH

PCCH

Scheduling / Priority Handling

MAC

Multiplexing UE 1

Multiplexing UE n

HARQ Transport Channels

HARQ

Illustration 10: La deuxime couche de l'interface radio au sens descendant [16] La sous-couche MAC regroupe des fonctions qui rsolvent des problmes spcifiques lis 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 mcanisme de HARQ qui est hrite de 3G HSDPA. La sous-couche RLC regroupe des fonctions indpendantes de la couche physique, telles que : remise en ordre des paquets, dtection 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 dtecter des pertes et remettre en ordre des paquets dans le mode UM. Enfin, dans le mode dAM, l'entit RLC peut demander l'autre bout de retransmettre le paquet. 26



2.2.4 La sous-couche PDCPLa sous-couche PDCP se compose des entits PDCP. Chaque entit est rattache une entit de la couche suprieure (Data Radio Bearer), et une ou deux entits de la couche RLC. La figure ci-dessous reprsente les fonctions dune entit PDCP (source principale [17]) : Utiliser RoHC pour compresser/dcompresser des enttes de paquets. Mettre en ordre des paquets de la couche RLC. Garantir de l'intgrit des messages de signalisation du plan de contrle. Chiffrement et dchiffrement des messages de signalisation du plan utilisateur. Ajouter/enlever un entte PDCP Ne pas traiter les messages de signalisation de contrle 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 rtablir la compression des enttes (recrer la contexte de RoHC), ensuite tous les paquets qui ne sont pas acquittes par la couche infrieure 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 acquitts par la couche infrieure vers le nouveau eNodeB par l'interface X2, ensuite rtablir la compression des enttes. S'il n'y a pas d'interface X2 entre deux eNodeB, la couche suprieure va s'occuper de retransmettre les paquets. Le protocole RTP/UDP n'a pas de 27



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

2.2.5 Couche physiqueLes deux techniques qui apportent des volutions de LTE dans le rseau d'accs sont OFDMA et MIMO. OFDMA est une combinaison de technique de modulation et de technique d'accs multiple. OFDMA rpartit la bande passante en N multiples sous-porteuses orthogonales qui sont partages par de plusieurs utilisateurs. Chaque sous-porteuse est module indpendamment en utilisant des modulations numriques : QPSK, QAM-16, QAM-64. le rcepteur les retrouve en appliquant des IFFT. OFDMA rduit le problme d'ISI (Inter Symbol Interference) qui est caus par des trajets multiples et enlve l'utilisation de l'galisation. En comparaison avec CDMA, OFDM a la mme efficacit spectrale mais fonctionne mieux que la bande passante suprieure 10MHz. L'affectation nombre de sous-porteuses pour un utilisateur est dynamique, cela permet la couche suprieure (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 mcanisme de SC-FDMA est bas sur le mme principe quOFDMA, mais il a t choisi car son taux de PAPR Peak-to-Average Power Ratio , est infrieur celui de lOFDMA. Plus ce taux est haut, plus le prix et la consommation dnergie du terminal augmentent [20]. En comparaison avec les techniques d'antennes traditionnelles qui amliorent la qualit d'un canal, MIMO est une technologie antenne avance, qui permet de multiples transmissions en parallle (canaux orthogonaux) par l'utilisation de plusieurs antennes au niveau du rcepteur 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 systme et le dbit d'utilisateur sans nergie de transmission et ni de bande passante supplmentaires. En comparaison avec 1x1 antenne, 2x2 MIMO peut augmenter 80% de dbit[5]. MIMO fonctionne mieux dans une rgion 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/LTE3.1 Description de RoHCLa taille des paquets dans les flux multimdias associs la voix ou la vido est petite (20 60 octets); l'encapsulation RTP/UDP/IP utilise reprsente donc une part importante du paquet (40 octets pour IPv4 et 60 octet pour IPv6), la compression d'en-tte RoHC (RObust Header Compression, dfini dans le RFC3095 de l'IETF) permet donc une augmentation trs importante de la capacit du rseau dans le cas de flux multimdias interactifs. De plus RoHC a t adopt dans la release 4 de l'UMTS. Le mcanisme pour la compression des en-ttes RoHC intgre des fonctionnalits de robustesse permettent de supporter des rseaux bruits. Larchitecture du mcanisme de Compression RoHC est complexe, mais permet de sadapter aux caractristiques du lien et au flux de donnes. Offrant une grande flexibilit dans le mcanisme travers les diffrents profils et modes dopration. 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-ttes est la rduction de la redondance de l'information contenue dans un en-tte, mais aussi de la redondance entre plusieurs en-ttes conscutifs. Ainsi l'information qui ne change pas est envoye au dbut de la session ou un faible rythme; pour les autres champs, un mcanisme de prdiction ou de dpendance permet de rduire encore l'information transmise. Le principe de RoHC est denvoyer linformation minimale pour que le dcompresseur puisse reformer len-tte. Llment cl est le CRC, calcul avant la compression. Il donne au dcompresseur une information sur la validit de linformation quil possde, puisque linformation transmise est susceptible dtre modifi suite des erreurs de transmission. La norme RoHC a laiss ouverts de nombreux choix de mise en uvre, entre autres : la dcision du passage dans le dcompresseur pour travailler dans le mode optimiste ou fiable, les valeurs des diffrents paramtres qui sont utiliss pour la compression. L'tude approfondie des spcifications de RoHC, d'IPv6 et de la 3G a permis de relever quelques incohrences dans les documents, en particulier pour le protocole IPv6. Ceci a conduit des nouveaux travaux au sein de l'IETF qui ont dbouch sur une nouvelle version du protocole RoHC (RoHCv2) qui se diffrencie de la prcdente version du protocole RoHC (ROHCv2). Elle se diffrencie de la prcdente pour les formats de paquets qui sont utiliss. 29



3.2 RoHCv2Tandis que RoHCv1 est spcifi principalement par la RFC 3095, RoHCv2 est dfini par trois documents : La RFC 4995 dcrit le framework commun v1 et v2 pour la plus grande part. La RFC 4997 dfinit RoHC-FN, une notation formelle pour dfinir des profils La RFC 5225 dfinit les profils RoHCv2 proprement dits, dcrits en grande partie

RoHC et les mthodes de compression associes. l'aide de RoHC-FN.

3.2.1 Motivation de proposition de RoHCv2 dans PDCP/LTERoHCv2 est propose par Ericsson[21]. La proposition est base sur trois axes principaux: la robustesse, l'efficacit, et la facilit d'implmentation. Dans la mme condition de fonction, le RoHCv2 a la mme efficacit de compression. RoHCv2 supporte le dsquencement de paquets entre compresseur et dcompresseur 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 dj support par RoHC la couche PDCP apportent des amliorations et des simplifications pour RFC 3095. Les simplifications sont utilises pour dvelopper le RoHCv2.

3.2.2 Amliorations et autres diffrences de RoHCv2 avec RoHCv1Les 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 dsquencement de paquets entre compresseur et dcompresseur. Le mcanisme utilis permet en outre une meilleure tolrance au dsquencement avant le compresseur. RoHCv2 utilise les mmes formats de compression dans ses deux modes de fonctionnement : unidirectionnel et bidirectionnel. Sa logique oprationnelle est plus simple et plus homogne que celle de RoHCv1. RoHCv2 traite les extensions IP comme les autres protocoles compresss, au lieu d'utiliser une liste compresse. 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, protgs par un CRC 7 bits, en cas de besoin (contexte dcompresseur abm). La segmentation RoHC est incompatible avec les formats v2 lorsque RoHC ne peut garantir une transmission sans rordonnancement entre compresseur et dcompresseur. Cela est d au fait que le protocole de segmentation n'utilise pas de numro de squence, 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 compresss, et ne transmet donc pas dans ces paquets la taille de la charge utile.

3.2.3 Les profils de RoHCv2RoHCv2 dfinit (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 utilise dans LTE) 0x0108 udplite (IP / UDPlite / non RTP) (n'est pas utilise dans LTE)

N.B. IP s'entend v4 ou v6 ; les deux versions peuvent tre utilises dans un mme entte. 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 dcompresseurRoHCv2 utilise deux modes de fonctionnement : unidirectionnel : les compresseur envoie les paquets avec une approche optimiste. Cela consiste rpter chaque changement de champ transmis en esprant que le dcompresseur recevra au moins un des changements. Pour que cette approche fonctionne bien, il faut ajuster le facteur de rptition aux caractristiques du lien (taux d'erreurs bit, taux de dsquencement) en visant un compromis robustesse / efficacit. bidirectionnel : le dcompresseur peut, s'il existe un lien dans cette direction, envoyer du feedback au compresseur. Une fois que le compresseur reoit du feedback pour un contexte donn, il passe dfinitivement en mode bidirectionnel pour ce contexte. Le trafic de feedback est constitu en majeure partie d'acquittements positifs et ngatifs ainsi que d'options diverses. Le feedback guide ainsi le compresseur en indiquant les formats compresss que le dcompresseur est capable de traiter. La synchronisation se fait par un numro de squence interne RoHC (Master Sequence Number).

3.3 Recommandation de RoHC dans 3GPPProfile Identifier 0x0000 0x0001 0x0002 0x0003 0x0004 0x0006 0x0101 0x0102 0x0103 0x0104 Usage No compression RTP/UDP/IP UDP/IP ESP/IP IP TCP/IP RTP/UDP/IP UDP/IP ESP/IP IP Reference RFC 4995 RFC 3095, RFC 4815 RFC 3095, RFC 4815 RFC 3095, RFC 4815 RFC 3843, RFC 4815 RFC 4996 RFC 5225 RFC 5225 RFC 5225 RFC 5225 RoHC version Commun v1 et v2 v1 v1 v1 v1 v1 v2 v2 v2 v2

Tableau 1: Les profils supports 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 ajoutes dans release 5. Dans release 6, l'utilisation de RoHC dans les services MBMS 32

Mmoire de fin d'tudes Intgration de RoHC dans l'architecture de LTE est prise en compte, mais n'est pas obligatoire.


Dans release 8, PDCP nutilise que RoHC pour compresser/dcompresser des enttes pour les paquets au plan utilisateur. Les profils supports se composent des profils dfinis dans ROHCv1 et ROHCv2 (cf. tableau 1). Lutilisation de la compression des enttes peut tre configure par la couche suprieure. RRC contient des informations pour la configuration de PDCP (voir 3.5). Les paramtres obligatoires de la configuration sont dfinis par RFC 4995. Mais il y a des paramtres qui ne sont pas utiliss par PDCP de cette release.Paramtre MAX_CID Obligatoire Oui Description Le nombre maximal de CID (Contexte Identifier) est utilis. Il faut rserver au moins un contexte pour les flux non-compresss. Cest--dire, il faut que MAX_CID < Maximum Number of RoHC Context Sessions Elle est dduite du paramtre MAX_CID par la rgle : If MAX_CID > 15 then LARGE_CIDS = TRUE else LARGE_CIDS = FALSE. Les profils sont utiliss par lUE. Les profils autoriss sont disponibles dans le tableau 1. Le canal de feedback Lutilisation de segmentation

LARGE_CIDS

Oui

PROFILES FEEDBACK_FOR MRRU

Oui Non utilise Non utilise

Tableau 2: Les paramtres sont dfinis par la couche suprieure de PDCP[17]

3.4 Support de RoHC au terminalLes 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 noncapable 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 rception 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



supportes par l'UE (annexe UE-EUTRA-Capability). Pour plus de dtails, 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. Aprs la rception de l'UE, l'eNodeB va transmettre ce message MME. Le MME sauvegarde les informations jusqu' ce que l'UE lance la procdure d'attacher ou de dtacher le rseau (chapitre 5.11.2 de [25]). Le MME va transmettre les informations au nouveau eNodeB pendant le handover, afin de rduire l'overhead, car la taille de message UECapacityInformation peut atteindre 510 octets.

3.5 Procdure de dclenchement de RoHCCette partie dcrit des tapes pour tablir un service au plan de contrle, dans lesquels le dclenchement de RoHC est montr (source principale [24]). En rsum, le RoHC est dclench dans la procdure d'tablissement de connexion de donnes DRB (Data Radio Bearer). Cette procdure est ralis aprs l'tablissement de connexion de signalisation SRB (Signalling Radio Bearer) et la procdure d'authentification. RoHC sera dactiv aprs la suppression des connexions DRB. Ci-dessous, les tapes sont dveloppes en dtails.Rseau coeur UE eNodeB Serveur d'IP

RRCConnectionRequest RRCConnectionSetup RRCConnectionComplete Authentification and others NAS Procedures RRCConnectionReconfugation (PCDP-config) RoHC configured RRCConnectionReconfigurationCompete User data transmission (IP packets) RRCConnectionRelease

Illustration 12: Procdure pour configurer et dclencher RoHC dans l'interface radio Premirement, la connexion de signalisation SRB qui sert transmettre des messages RRC entre UE et E-UTRAN est tablie par la procdure de RRC Connextion 34



Etablisement . Cette procdure est dclenche par la couche suprieure de l'UE, lorsque l'UE veut rpondre 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 reoit un message de RRCConnectionSetup d'eNodeB. L'entit PDCP sera tablie, en observant la configuration courante de scurit. Ici, il n'y a pas de compression. Ensuite, tous les messages d'authentification et de NAS transmis sont protgs (intgrit/chiffrement) par PDCP. Si l'E-TRAN est surcharg, il peut refuser la requte de l'UE par le message RRCConnectionReject qui contient le temps d'attente. Deuximement, ce sont la procdure d'authentification et d'autres procdures de NAS qui ne sont pas prcises dans le cas de ce document. Troisimement, la procdure de re-configuration sera lance afin de contrler le handover, de transmettre des messages NAS d'eNodeB vers l'UE, ou d'tablir/modifier la connexion de donnes 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 prcdante de release 8, annexe PDCP-info ). En consquence, l'instance de RoHC est tablie. Tous les enttes de paquets IP au plan d'utilisateur sont compresss par RoHC. L'UE rpond l'E-UTRAN par le message de RRCConnectionReconfigurationComplete ". PDCP-config se compose des paramtres qui dfinissent l'utilisation/non-utilisation de RoHC, le nombre maximal de contexte utilis (MAX_CID), les profils supports. Si les deux profils supports ont en commun les 8 bits de pois faible, celui dont la valeur est la plus leve est slectionn. RoHCv2 est donc privilgi par rapport RoHCv1. De plus, dans les releases prcdentes de la releases 8, la configuration de PDCP regroupe d'autre paramtre telle que la Target Mode , qui dcide 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 procdure 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 paramtres qui causent ce refus. L'ide principale est de rduire la complexit d'eNodeB. L'entit PDCP est r-tablie selon la configuration prcdente. 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 libre.-- ASN1START PDCP-Config ::= discardTimer } Setup rlc-AM statusReportRequired } Rlc-AM rlc-UM pdcp-SN-Size } Rlc-UM headerCompression notUsed rohc maxCID profiles profile0x0001 profile0x0002 profile0x0003 profile0x0004 profile0x0006 profile0x0101 profile0x0102 profile0x0103 profile0x0104 }, ... } }, ... } SEQUENCE { ENUMERATED { ms50, ms100, ms150, ms300, ms500, ms750, ms1500, infinity OPTIONAL, SEQUENCE { BOOLEAN

-- Cond

OPTIONAL,

-- Cond

SEQUENCE { ENUMERATED {len7bits, len12bits} OPTIONAL, CHOICE { NULL, SEQUENCE { INTEGER (1..16383) SEQUENCE { BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN

-- Cond

DEFAULT 15,

Texte 1: PDCP-Config information element [24]

3.6 RoHC et handoverSelon 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 rseaux excute 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 trs 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 mcanisme 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 rduire la perte casse par l'interruption de contexte. On peut donc conomiser la bande passante de 1.9% quand la frquence de handover est haute, et de 0.5 quand la frquence de handover est base [R2-072045]. Le transfert de contexte est donc supporte par UMTS. Mais, LTE ne supporte pas le transfert. Pour implmentation de transfert de contexte, il faut modifier l'interface X2 pour grer les informations de contexte, et modifier significativement le protocole RoHC. Cependant, l'ide principale de LTE est de mettre moins complexit. De plus, si le transfert de contexte est support, l'implmentation de diffrentes fournisseurs de RoHC peut ne pas traiter le mme lors qu'il y a le problme de dconsquence ou la perte de paquets.

3.7 RoHC et MBMSL'avantage de Broadcast/Multicast par rapport l'unicast est que les donnes 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 mmes donnes.

3.7.1 MBMSLes services MBMS (Multimedia Broadcast/Multicast Service) permettent aux oprateurs 3G de fournir plus efficacement les applications mdia en concurrence avec DVBH. Ils diminuent le dbit dans rseaux coeur et utilisent efficacement des ressources radio au rseau daccs. 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 donnes mdia dun nud (un oprateur) vers multiples nuds (multiples utilisateurs) dans la zone de services. Dans le mode multicast, le rseau n'envoie des donnes qu'aux cellules o il y a des abonnes (un groupe). Le mode multicast ressemble au mode broadcast, cela prs qu'il propose des mcanismes dabonnement (subscripstion) et rejoindre/disjoindre du groupe [28]. Le mode multicast de 3GPP est diffrent du multicast IP dIETF. Il prend en compte lutilisation 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 synchronises pour

37



transmettre un mme contenu. Le protocole SYNC et un serveur de MBMS-GW (e-MBMS Gateway) sont utiliss pour diffuser le mme 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 dcid de complter l'architecture de MBMS dans release 9 [29].

3.7.2 RoHC et Broatcast/MulticastDans les releases prcdentes, la compression des enttes est ralise 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, mme 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 compresss. Cela diminue donc notablement l'efficacit de RoHC. Selon la release 9, BM-SC supporte la compression des enttes dans le mode broadcast. C'est une solution plus simple. Mais il y a une duplication de RoHC dans le rseaux 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 compleque, car la difficult de synchronisation de contenu. L'implmentation de RoHC de fournisseurs diffrents n'est pas identique, et ne traite pas la mme faon dans le cas de perte, et de dsquencement de paquets [31].

38



4 valuation de la performance de ROHCv14.1 ObjectifsLa performance de RoHC est value de manire thorique par plusieurs travaux:[32], [33], [34], [35], et [36]. Dans cette partie, nous nous intressons la performance de RoHC en utilisant l'implmentation de JCP-Consult afin de trouver le taux de bande passante conomise, et d'valuer la robustesse de RoHC.

4.2 Scnarios 4.2.1 Modle d'valuation de performanceGnrateur de paquets IP Paquets dcompresss

comparateur Nombre de paquets errons Nombre de paquets perdus Taille des enttes compresss

Compresseur RoHC

Dcompresseur RoHC

Modle des fautes Transmission des paquets compresss

Illustration 13: Modle d'valuation de performance de RoHC Le modle d'valuation de performance se compose des blocs principaux suivants: gnrateur des paquets IP, compresseur/dcompresseur RoHC, comparateur et modle de fautes. Nous utilisons VLC player pour gnrer des paquets multimdia en flux selon le protocole RTP. Ensuite, nous les passons au compresseur RoHC. Des fautes sont ajoutes aux paquets compresss afin de simuler des fautes dans le lien radio. La simulation donne un rapport statistique sur le nombre de paquets errons, sur le nombre de paquets perdus, et sur la taille d'enttes compresss. Nous valuons avec des flux audio et vido diffrentes, selon le tableau 3.

39

Mmoire de fin d'tudes Intgration de RoHC dans l'architecture de LTE Codec Narrow band audio Wide band audio Standard video High quality video AMR NB AMR WB H264 H264 Bitrate (kbps) 12.2 23 74 104 Packet size (bytes) 23 60 variable Variable

VU DINH Dau Promotion 13, IFI Description 23 octes/packet 71 octes/packet Frame size 176x144, 10 fps Frame size 176x144, 15 fps

Tableau 3: Les diffrents flux pour valuer la performance de RoHC

4.2.2 Choix de modle de fautesPour 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 modle bit perdu est qu'il peut montrer la robustesse de RoHC avec des erreurs imprvisibles. Nous utilisons le modle d'alatoire (Uniform) avec BER de 106 103 . En thorie, BER de 103 peut causer 28% paquets perdus (la probabilit d'avoir un bit d'errons dans 40 octets de l'enttes: 11103 408=28 % ). Or, un taux de perte de plus de 10% n'est pas acceptable pour les application multimdia. Nous ne nous intressons pas un BER suprieur 103 . LTE utilise les mcanismes robustes tels que ARQ la couche RLC, HARQ la couche MAC, et FEC/Turbo coding la couche PHY. Le taux de blocs errons la couche suprieur de MAC est de 104 103 [37]. La plupart de bits errons sont corrigs. Il n'y a que des bits errons en rafale qui engendrent des paquets errons. Ces paquets sont considrs 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 considr dans le test de performance de RoHC. En gnral, la distribution d'erreurs dans le lien radio est le suivant : il y a des segments errons o tous les paquets successifs sont errons 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 modle de Gilbert simple (2 states Markov) et Gilber-Ellibott pour prsenter la distribution de fautes. Le modle de Gilbert simple est prfr car il y a moins de paramtres d'entre (deux paramtres par rapport 4 paramtres du modle Gilber-Ellibott). Nous fixons la taille moyenne de segments corrects 1000 paquets, et varions la taille moyenne de segments errons de 10 100 paquets, ce qui correspond un taux de paquets errons de 103 102 . 40



4.3 Pre-tests

Illustration 14: Pre-tests, le nombre maximal de paquets perdus est trs haut dans O-mode JCP-Consult a dvelopp un outil de test qui s'appelle synthetic tester pour que les ingnieurs puissent valider le fonctionnement de RoHC. Il permet de gnrer automatiquement des paquets, les passer vers RoHC, de valider les sorties de test, et donne des statistiques de tests. L'outil grre ses propes paquets et n'est pas capable de tester des paquets live qui sont capturs partir du rseau. De plus, il est incapable de simuler : erreurs, perte de paquets, dlai, et dsquencement dans lien radio. Number of RoHC Profile BER Packets mode 5830 O 5830 O 5830 O 5766 R 5766 R 5766 R 2 0.000150 2 0.000200 2 0.000250 2 0.000500 2 0.000550 2 0.000600 Bandwidt Average Burst packet h packet loss loss reduction 0.001544 1 0.349770 0.553859 3223 0.349705 0.003774 1 0.349770 0.346514 8 0.120370 0.926639 5280 0.077056 0.115505 4 0.122304 Input file amr23k01.pcap amr23k01.pcap amr23k01.pcap hightrate3gp01.pcap hightrate3gp01.pcap 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 trs 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 manire thorique pour comprendre les rsultats. Ces rsultats ne correspondent pas la thorie. Les discussions avec les ingnieurs JCP-Consult ont permis de corriger les bugs dans l'implmentation. A fin de mon stage, les rsultats de tests sont raisonnables et observent des rsultats manire thorique.

4.4 RsultatsDans les rsultats suivants, nous choisissons le profil IP/UDP/RTP qui correspond aux applications multimdia telles que celles prvues dans le projet-NextTV4All.

4.4.1 Taux de bande passante conomise

Illustration 15: Bande passante conomique dans U-mode et BER = 0.0 avec des flux diffrents Le taux de bande passante conomise prsente l'efficacit et l'intrt de RoHC. Le taux de diffrents flux est disponible dans la figure 15. A gauche, ce sont des rsultats de test avec des paquets IPv4, et a droit, ce sont celles du paquets IPv6. Chaque colonne qui a le couleur diffrent prsente un type de flot. On trouve que dans le mme type de flot, l'efficacit de compression de paquets IPv6 est plus leve par rapport celle de paquets IPv4. De plus, dans la mme version de protocole IP, le plus payload est gros, le mois RoHC est intressant. L'efficacit de RoHC

42



est proportionnelle la taille des enttes et inverse proportionnelle la taille de payload. Les rsultats dans le figure 15 ne prends pas en compte des erreurs dans le lien radio qui causent dsynchronisation entre le compresseur et le dcompresseur. Dans les figures 16 19, nous valuons l'efficacit de RoHC avec les taux de bits errons diffrents (BER). On trouve que si le BER augmente, le taux de bande passante conomise 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 103,5 . Si le taux d'errons est petite, O-mode conomise le plus de bande passante, mais quand le BER est suprieur 103 , R-mode est le meilleur. Dans le mode unidirectionnel, le compresseur revient priodiquement aux niveaux infrieurs 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 infrieurs soit il reoit 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 reoit plus de paquets NACKs, il est forc revenir au niveau infrieur. L'efficacit est donc diminue. Quand lerreur est petite, le mode optimiste est meilleur que le mode fiable parce que la liaison de retour est moins utilise. Quand l'erreur est assez grand R-mode et O-mode doivent revenir aux niveaux infrieurs plus frquemment. Mais le contexte de R-mode peut monter au niveau suprieur toute suite aprs recevoir un ACK, cependant le O-mode doit envoyer L paquets (niveau de confiance) avant de passer au niveau suprieur.

rapport lte

Documents