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 matires

Glossaire 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
Remerciements
Je 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.
Rsum
LTE (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.
Abstract
LTE (Long Term Evolution) is the latest evolution of GSM/UMTS/HSPA, the mobile broadband technology standards, toward the fourth generation of cellular wireless known as 4G. The innovations of LTE at the radio interface and the architecture flat and all-IP reduces the access delay and enrich the multimedia services such as the television over IP. Robust Header Compression (RoHC) is a solution of LTE at the radio interface to optimize the throughput of audio/video applications, where packets generally contain a large header in comparison with their payload. The second version of RoHC (RoHCv2) that simplifies the implementation of RoHC and improves the performance in handover is supported by LTE. We analyze the architecture of LTE to integrate RoHC in this system. Our study shows that RoHC takes place at PDCP radio layer, profiles of both RoHCv1 and RoHCv2 are supported. We also studied the support of RoHC by LTE in handover and the services broadcast/multicast. The verification on the implementation of JCP-Consult proves that RoHC is very robust against errors in the radio link, and can reduce the loss rate in handover. It helps reduce about 40% bandwidth of VoIP flow and about 10% bandwidth of video flow. We, however, found RoHC introduces a little jitter to the multimedia flows. Keywords: cellular network, 4G, LTE, UMTS, PDCP, header compression, RoHC, RoHCv2, IPTV.
Glossaire des Abrviations

AAL2 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
Index des illustrations

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])..................................................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 tables

Tableau 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 Introduction
1.1 Contexte
Mon 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 Problmatique
L'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 contributions

L'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 document

La 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'UMTS

2.1 Contexte de l'UMTS 2.1.1 volution de UMTS
UMTS 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'UMTS

a) 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 Iub
NodeB NodeB RNC MSC/VLR HLR GMSC
Iu CS domain
PSDN
Iur
RNC
PS domain
NodeB 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 Iub
NodeB NodeB RNC
Iu
CS-MGW
CS-MGW
CS domain
PSDN
MSC Server GMSC Server
Iur
HSS
PS domain
NodeB 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-plane
RRC RLC MAC PHY UE
Uu
RRC RLC MAC PHY RANAP SCCP ATM or IP Transport PHY UTRAN
Iu
RANAP 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-plane
PDCP RLC MAC PHY UE
Uu
PDCP RLC MAC PHY UTRAN GTU-U ATM or IP Transport PHY
Iu-PS
GTU-U ATM or IP Transport PHY SGSN ATM transport IP transport UDP/IP AAL5/ATM UDP/IP LL
IuPS
Uu
RLC MAC PHY UE RLC MAC PHY ATM or IP Transport PHY UTRAN
Iu-CS
ATM 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 concurrentes

En 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 exigences

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

IMS Rseau coeur P-GW MME S-GW Plan utilisateur S1 Plan contrle GERAN UTRAN HSS
GSM/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 radio

Cette 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 PDCP

La 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 physique

Les 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/LTE

3.1 Description de RoHC
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 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 RoHCv2
Tandis 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/LTE

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

RoHCv2 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 dcompresseur

RoHCv2 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 3GPP

Profile 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 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 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 RoHC

Cette 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 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 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 MBMS

L'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 MBMS
Les 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/Multicast

Dans 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 ROHCv1

4.1 Objectifs
La 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 performance

Gnrateur 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 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 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 Rsultats
Dans 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.
43
Illustration 16: Taux de bande passante conomise VoIP AMR 12,2 kbps
Illustration 17: Taux de bande passante conomise VoIP AMR 23 kbps
Illustration 18: Taux de bande passante conomise Video H264 haute qualit
Illustration 19: Taux de bande passante conomise Vido H264 moyenne qualit
4.4.2 Taux de paquets perdus

L'utilisation de RoHC permet de diminuer la taille d'entte, donc, la perte qui est caus par l'entte erron diminue. Mais dans RoHC, un paquet perdu peut casser la cohrence entre les machines d'tats au compresseur et au dcompresseur. Nous testons donc la robustesse du mcanisme de re-synchronisation de RoHC. Les figures de 20 23 prsentent 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 rduire 50% de perte, et 80% pour le R-mode. Le R-mode prsente son avantage par rapport au U-mode et au O-mode. Dans ce mode dopration seules les paquets avec un CRC de 7 ou 8 bits peuvent actualiser le contexte et tre utiliss comme rfrence pour les dcompressions subsquentes. Lintgrit du contexte est donc mieux protge[34]. De plus, le compresseur ne passe au niveau suprieur que lorsqu'il reoit 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 dsynchronisation cause galement une perte de paquets successifs. Les paquets perdus causent une gigue au niveau applicatif. Nous avons ralis des tests pour valuer la gigue. Les figures de 24 27 prsentent nombre maximal de paquets perdus successifs en fonction du taux de paquets perdus. Quand le taux de perte est petit, le nombre est prs gale celui de la non-utilisation de RoHC. Quand le taux de perte est suprieur de 102,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 dcompresseur doit atteindre le paquet initial envoy priodiquement pour se re-synchroniser avec le compresseur. Dans le mode bidirectionnel, le dcompresseur 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 46
Illustration 23: Taux de paquets perdus Vido H264 moyenne qualit
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 Vido H264 moyenne qualit
4.4.4 Comparaison avec RoHC de Thales et Al.

Nous comparons la performance de RoHC de l'implmentation de JCP-Consult avec celle de l'implmentation de Centre national dtudes spatiales(CNES), Thales Systmes aroports, et Viveris Technologies. Cette implmentation est sous licence de GPL et fut publie au cours de mon stage, en Aot 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 bass 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 infrieure 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 conomise 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 perspectives
Le contexte de ce stage tait le projet de recherche europen NextTV4All, JCPConsult, en coopration avec TELECOM Bretagne. Dans ce stage, nous nous sommes intresss faire un tat de l'art d'intgration de RoHC dans l'architecture de LTE. Premirement, nous avons prsent des innovations, et l'architecture de LTE. On remarque que des volutions dans la technique d'accs OFDMA, MIMO et la simplification d'architecture base sur le protocole IP facilitent des services multimdia comme IPTV. Deuximement, nous avons prsent RoHC dans LTE. RoHC fonctionne au niveau de la sous-couche PDCP, les profils de RoHCv1 et RoHCv2 sont supports. On constate que RoHC peut rduire la perte de paquets pendant le handover. RoHC est support dans les services de broadcast/multicast (MBMS). RoHCv2 amliore la performance dans certains cas tel que le handover. RoHCv2 apporte galement des simplifications d'implmentation. Troisimement, nous avons effectu des tests sur l'implmentation de JCP-Consult de RoHCv1. RoHC est trs robuste contre des erreurs sur le lien radio, et peut rduire 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 vido. Cependant, RoHC introduit un phnomne de gigue au niveau applicatif. Nous avons 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 selon diffrentes distributions : Uniform, Gilbert simple, et Gilbert-Ellibott. Les premiers rsultats de test ont permit aux ingnieurs JCP-Consult de corriger des bugs de type chaotique. Nous avons galement ralis une comparaison de la performance de RoHCv1 de JCP-Consult avec une implmentation comptitive. Cette comparaison a montr qu'il tait encore possible d'optimiser l'implmentation de RoHCv1. Une tude intressante serait la comparaison avec RoHCv2, qui est en cours de dveloppement au sein de l'entreprise JCP-Consult et TELECOM Bretagne. Une autre tude intressante concerne l'impact de RoHC sur la qualit de service (QoS) des rseaux multimdia. En effet, nous avons vu les problmes de gigue gnrs par RoHC, mais d'autres effets sont galement prvoir, 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] Rmi 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/2007 21: 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-ttes intra-couches pour les flux 51
multimdia multicast sur des rseaux sans fils, Thse 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-ttes sur les rseaux bas-dbit, Thse 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 Lindstrm, 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 A
SIGCOMP qui fonctionne entre la couche d'application et la couche de transport peut rduire 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 enttes dans l'architecture du LTE , de projet NextTV4All.
SIGCOMP
Introduction
Le dveloppement des services interactifs comme lIM (Instant Messaging), la prsence et des services multimdia comme la vido confrence ou la TV dans le rseau 3G exige une importante bande passante. A partir de la Release 5 de lUMTS, le protocole SIP (Session Initiation Protocol, RFC IETF 3261) est choisi pour envoyer la signalisation des communications de voix et autres sessions multimdia. Mais SIP est un protocole bas sur le texte (comme http) et il gnre des paquets entre 200 et 1500 octets qui sont envoys plusieurs fois ce qui est inefficace et augmente le dlai pour ltablissement dun appel. Le groupe de travail RoHC lIETF a travaill sur la conception dun mcanisme de compression pour les messages de signalisation SIP et pour rduire la rptition des envois. Le rsultat est SigComp (Signaling Compression) [39][40]. La compression de donnes SigComp [39][40] permet de rduire laugmentation de dbit gnre par la signalisation SIP lors de la cration dune session pour les services tels que IP-TV, VoD, Prsence, IM, etc. dans les rseaux daccs sans fil comme lUMTS ou le LTE. Lutilisation de SigComp permet daugmenter le dbit utile et rduire le dlai dans la transmission de donnes. La compression de SIP rduit lutilisation de ressources radio et permet dallouer un plus grand nombre dutilisateurs. Le groupe de travail RoHC lIETF, charg de dvelopper SigComp, a considr que les terminaux de tlphonie cellulaire nont pas beaucoup de ressource mmoire ni un processeur assez puissante pour traiter des algorithmes trs complexes [40][41]. SigComp doit donc tenir compte du fait que le terminal doit appliquer un grand nombre dalgorithmes dj dploys dans un rseau. SigComp ngocie la quantit de mmoire disponible pour la compression et nutilise quun nombre rduit doprations pour augmenter le temps de traitement.
Architecture de SIGCOMP
SigComp est un mcanisme de compression de donnes 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 compresss comme des donnes). Ces messages SIP ont une taille qui peut atteindre 500kb et ils sont rpts plusieurs fois pour assurer la fiabilit de la session. La Compression et Dcompression SigComp sont faites par les entits paires qui envoient travers des rgulateurs de paquets les messages vers la couche applicative et la couche transport.
53
Illustration 31: Pile protocolaire avec la compression. LArchitecture SigComp a trois lments principaux (cf. figure 32) : Le Compresseur (C), le Dcompresseur (D) et le gestionnaire dtat (State Handler). De plus, le protocole SigComp utilise des rgulateurs de paquets pour envoyer et recevoir les messages. Le compresseur peut utiliser une algorithme connu (Deflate, LZW, etc) ou un algorithme spcifique (EPIC, TCCP, etc). Chaque message est compress indpendamment mais les messages dun flux donn sont compresss avec le mme algorithme. Les algorithmes plus connus feront une meilleure performance puisque le pseudo-code binaire (le pseudo code est le produit dun compilateur pour traduire le code source en langage machine, pour SigComp le pseudo code permet un usage multi-plateformes des logiciels dvelopps qui sont exploitables par la machine virtuelle du dcompresseur) ncessaire pour dcompresser les donnes nest pas envoy au dcompresseur. Les algorithmes de compression de texte peuvent tre bass sur : Un Dictionnaire : LZ, LZ77, TCCB Une Transforme : Huffman, codes arithmtiques, Burrow-Wheeler (BWT), EPIC Un Modle : Prdiction avec une corrlation partielle (PPM) Le choix de lalgorithme reste un paramtre slectionn manuellement pour SigComp. Le compresseur rduit les messages avec lalgorithme choisi et ajoute le pseudo code binaire si ncessaire, le rgulateur de paquets envoie le message compress avec la mise jour du pseudo code binaire pour lalgorithme de dcompression qui sera utilis par la machine virtuelle UDVM (Universal Decompressor Virtual Machine) du dcompresseur. Le compresseur doit sassurer que le dcompresseur a toute linformation ncessaire pour faire la dcompression. Pendant un handover le nouveau dcompresseur doit recevoir linformation ncessaire pour dcompresser les messages. Les messages compresss sont envoys avec une combinaison des instructions dUDVM qui permettent sa dcompression. Le gestionnaire dtats stocke les pseudo codes binaires et les dictionnaires, il peut tre contact par un dcompresseur pour connatre cette information. Sa pleine efficacit est atteinte aprs un nombre de messages compresss, le premier message donne linformation de ltat de lalgorithme 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
incrmenter la performance ou il peut tre envoyer avec le message compress. Le dictionnaire statique est une collection de caractres bien connus qui sont utiliss dans la plupart de messages SIP/SDP.
Application
Application message & Compartment identifier Decompressed message Compartment identifier
Compressor dispatcher
SIGCOMP
State 1 State Handler
Decompressor dispatcher
Compressor 1
Decompressor (UDVM)
Compressor 2
State 2
SIGCOMP message
SIGCOMP message
Transport Layer
Illustration 32: SIGCOMP Architecture Le dcompresseur utilise une machine virtuelle similaire une machine virtuelle Java, elle sappelle UDVM (Universal Decompressor Virtual Machine) et elle est le noyau de SigComp. Les messages SigComp sont la combinaison de donnes compresses avec les instructions dUDVM. UDVM est optimise pour supporter diffrents algorithmes de compression, elle est flexible et travaille avec le pseudo code envoy par le Compresseur. Un avantage de cette solution est linteroprabilit entre diffrentes implmentations. UDVM a un ensemble de 36 instructions (cf. tableau 5) pour manipuler les diffrents algorithmes de compression : Mathmatiques, de Gestion de Mmoire, de Gestion de Programme et de Entre/Sortie (I/O). La taille du pseudo code varie entre 200 et 300 octets. UDVM najoute pas un dlai supplmentaire au traitement des donnes et nutilise pas plus de mmoire que si on dfinissait un seul algorithme de dcompression. UDVM envoie les donnes dcompresses comme un flux de donnes. Le gestionnaire de messages envoie et reoit les messages entre SigComp et la couche applicative.
Instruction DECOMPRESSION FAILURE AND OR NOT LSHIFT RSHIFT ADD Valeur pseudocode 0 1 2 3 4 5 6 Instruction SUBTRACT MULTIPLY DIVIDE REMAINDER SORTASCENDING SORTDESCENDING SHA1 Valeur pseudocode 7 8 9 10 11 12 13
55

Instruction LOAD Valeur pseudocode 14 Instruction

Valeur pseudocode 15
MULTILOAD
56

Instruction PUSH POP COPY COPYLITERAL COPYOFFSET MEMSET JUMP COMPARE CALL RETURN SWITCH Valeur pseudocode 16 17 18 19 20 21 22 23 24 25 26 Instruction CRC

Valeur pseudocode 27 28 29 30 31 32 33 34 35
INPUTBYTES INPUTBITS INPUTHUFFMAN STATEACCESS STATECREATE STATEFREE OUTPUT ENDMESSAGE
Tableau 5: Instructions dUDVM et les valeurs de pseudo code.
UDVM est divis en deux parties : la mmoire et le traitement du pseudo code. Il a deux interfaces pour communiquer dans larchitecture, une avec le rgulateur de paquets pour envoyer/recevoir les donnes compresss/dcompresss, et lautre avec le gestionnaire dtat qui lui permet de demander la cration dun tat et daccder a un tat dj cr. Linformation des acquittements est envoye au gestionnaire dtat si le niveau transport est bidirectionnel. La mmoire dans UDVM (cf.. figure 33) a une taille par dfault de 2kilo-octets. Avec des implmentations [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 ncessaires pour sauvegarder toute linformation. Les premiers 64 octets sont utiliss pour les variables de dcompression comme : la taille de mmoire, les cycles, la version, la longueur de ltat et le paquet dcompresser. Ensuite il utilise 64 octets pour les variables de la compression comme : la localisation des tats, lordre dentre de bits. Aprs le pseudo code UDVM occupe 128 octets qui sont les instructions UDVM, ensuite entre 256 octets pour le(s) dictionnaire(s) qui sont les diffrents pseudo codes des algorithmes de compression et le reste il peut stocker des paquets (figure 33) prcdents ou les dictionnaires dynamiques ou personnaliss. La mmoire entre 64 octets et 512 octets est sauvegarde aprs la dcompression pour amliorer lindice de compression.
57
Illustration 33: La mmoire dUDVM
Format de Message SIGCOMP.

Les messages SigComp doivent indiquer lalgorithme de compression utilis et toute linformation ncessaire pour la dcompression. Cette information peut faire partie du message SigComp ou elle peut tre connue comme dans les tats ditems disponibles dans la mmoire. Les deux types des messages (cf. figure 34) sont diffrencis par le premier octet.
0 7 0 7
len
returned feedback item partial state identifier remaining SIGCOMP message
returned feedback item code_len code_len destination
uploaded UDVM bytecode
remaining SIGCOMP message
Illustration 34: Format of a SIGCOMP message
Les paramtres SigComp

Afin davoir une complte interaction entre les diffrentes implmentations, une srie de paramtres est utilise pour modifier les comportements de la compression quand les capacits des paires sont trs diffrentes : Taille de mmoire de dcompression (Decompression_memory_size) : donne la taille de mmoire disponible pour la dcompression de messages SigComp. Etat de la taille de mmoire (State_memory_size) : Donne le nombre doctets pour la cration dun tat, Zero si la configuration est sans tat. 58
Cycle par bit (Cycles_per_bit) : Le nombre de cycles disponibles pour dcompresser chaque bit dans le message SigComp. Un autre paramtre est utilis par les instructions UDVM. Version de SigComp (SigComp_version) : Indique si seulement la version de base est disponible ou sil y a une mise jour dans limplmentation Les tats des items disponibles localement (Locally Available State Items) : Ltat des items est une information qui est utilis entre deux messages SigComp pour la dcompression ou pour le dictionnaire. Ils sont crs quand un message a t dcompress avec succs.
Performances de SigComp
Telecom Bretagne a test [45] le mcanisme de compression SigComp sur une communication SIP entre deux ordinateurs, pour connatre 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 rduction de taille des messages SIP. Cela signifie quil est possible denvoyer 16 fois plus de messages, do une rduction de la bande passante et une optimisation de son utilisation ainsi quune rduction du dlai pour ltablissement dune session dans la tlphonie 3G.
Algorithmede Compression Pourcentagede Compression Ratio
R=Taillesanscompression
Taillecompresse SimpleLZ77 AdaptiveLZ(compress) LZW LZSS DEFLATE(gzip) 55,2 78,64 70,99 82,47 93,8 2.2321 4,6816 3,4470 5,7045 16,1290
Tableau 6: Ratio de Compression pour les messages SIP [45] La figure 35 montre les diffrents messages SIP compresss par les diffrents algorithmes et la taille qui est obtenue.
59
Illustration 35: Compression SigComp.
60
Annexe B
Support 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 profiles

The 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 0x0000 0x0001 0x0002 0x0003 0x0004 0x0006 0x0101 0x0102 0x0103 0x0104 No compression RTP/UDP/IP UDP/IP ESP/IP IP TCP/IP RTP/UDP/IP UDP/IP ESP/IP IP 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 Usage: Reference
5.5.2 Configuration of header compression

PDCP entities associated with DRBs can be configured by upper layers [3] to use header compression.
5.5.3 Protocol parameters

RFC 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
Mmoire de fin d'tudes Intgration de RoHC dans l'architecture de LTE 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 compression

The 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 decompression

If header compression is configured by upper layers for PDCP entities associated with uplane data the PDCP PDUs are de-compressed by the header compression protocol after performing deciphering as explained in the subclause 5.6. Les procdures de la couche de RRC (3GPP TS 136 331 V8.5.0)
5.3.3 RRC connection establishment

5.3.3.1 General
62

UE

EUTRAN
RRCConnectionRequest
RRCConnectionSetup
RRCConnectionSetupComplete
Figure 5.3.3.1-1: RRC connection establishment, successful

UE EUTRAN
RRCConnectionRequest
RRCConnectionReject
Figure 5.3.3.1-2: RRC connection establishment, network reject The 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 reconfiguration

5.3.5.1 General
UE EUTRAN
RRCConnectionReconfiguration
RRCConnectionReconfigurationComplete
Figure 5.3.5.1-1: RRC connection reconfiguration, successful
63

UE

EUTRAN
RRCConnectionReconfiguration
RRC connection re-establishment
Figure 5.3.5.1-2: RRC connection reconfiguration, failure The 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-establishment

5.3.7.1 General
UE EUTRAN
RRCConnectionReestablishmentRequest RRCConnectionReestablishment
RRCConnectionReestablishmentComplete
Figure 5.3.7.1-1: RRC connection re-establishment, successful

UE EUTRAN
RRCConnectionReestablishmentRequest RRCConnectionReestablishmentReject
Figure 5.3.7.1-2: RRC connection re-establishment, failure The 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 EUTRAN 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
Mmoire de fin d'tudes Intgration de RoHC dans l'architecture de LTE 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 release

5.3.8.1 General
UE EUTRAN
RRCConnectionRelease
Figure 5.3.8.1-1: RRC connection release, successful The 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 message 1> 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 ::= discardTimer } Setup rlc-AM statusReportRequired } Rlc-AM rlc-UM pdcp-SN-Size } Rlc-UM SEQUENCE { ENUMERATED { ms50, ms100, ms150, ms300, ms500, ms750, ms1500, infinity OPTIONAL, SEQUENCE { BOOLEAN OPTIONAL, SEQUENCE { ENUMERATED {len7bits, len12bits} OPTIONAL, -- Cond
-- Cond
-- Cond
65

headerCompression notUsed rohc maxCID profiles profile0x0001 profile0x0002 profile0x0003 profile0x0004 profile0x0006 profile0x0101 profile0x0102 profile0x0103 profile0x0104 }, ... } }, ... } -- ASN1STOP CHOICE { NULL, SEQUENCE { INTEGER (1..16383) SEQUENCE { BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN
DEFAULT 15,
PDCP-Config field descriptions

discardTimer Indicates 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. statusReportRequired Indicates 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-Size Indicates 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]. maxCID Indicates the value of the MAX_CID parameter as specified in TS 36.323 [8]. profiles The 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 LSBs is signalled, only the profile corresponding to the highest value shall be applied. Conditional presence Setup Rlc-AM Rlc-UM Explanation The field is mandatory present in case of radio bearer setup. Otherwise the field is not present. 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. 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 info The 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 Support for lossless SRNS relocation or for lossless DL RLC PDU size change Max PDCP SN window size Need CVLosslessCr iteria CVMulti Type and reference Boolean Enumerated(s Semantics description TRUE means support Maximum PDCP Versio n
66

Information Element/Group name Need Lossless Multi Type and reference n255, sn65535)

Semantics description sequence number window size. The handling of sequence number when the Max PDCP SN window size is 255 is specified in [23]. Whether a PDCP PDU header is existent or not. Versio n
PDCP PDU header Header compression information
MP OP 1 to <maxPDC PAlgoTyp e>
Enumerated (present, absent)
>CHOICE algorithm type >>RFC 2507
MP
>>>F_MAX_PERIOD
MD
Integer (1..65535)
>>>F_MAX_TIME
MD
Integer (1..255)
>>>MAX_HEADER
MD
Integer (60..65535)
>>>TCP_SPACE
MD
Integer (3..255)
>>>NON_TCP_SPACE
MD
Integer (3..65535)
>>>EXPECT_REORDERING
MD
Enumerated (reordering not expected, reordering expected)
Note 1 Header compression according to IETF standard RFC 2507 Largest number of compressed nonTCP headers that may be sent without sending a full header. Default value is 256. Compressed headers may not be sent more than F_MAX_TIME seconds after sending last full header. Default value is 5. The largest header size in octets that may be compressed. Default value is 168. Maximum CID value for TCP connections. Default value is 15. Maximum CID value for non-TCP connections. Default value is 15. Whether the algorithm shall reorder PDCP SDUs or not. Default value is "reordering not expected".
67

Information Element/Group name >>RFC 3095 Need Multi Type and reference

Versio n REL-4
Semantics description Header compression according to IETF standard RFC 3095 >>>Profiles MP 1 to Profiles supported <maxRO by both HCcompressor and Profiles> decompressor in both UE and UTRAN. Profile 0 shall always be supported. >>>>Profile instance MP Integer(1.. 3) 1 = 0x0001, 2 = 0x0002, 3 = 0x0003 (see [52]) >>>Uplink OP Indicates the necessary information elements for Uplink. >>>>Max_CID MD Integer (1.. Highest context ID 16383) number to be used by the UE compressor. Default value is 15. >>>Downlink OP Indicates the necessary information elements for Downlink. >>>>Max_CID MD Integer (1.. Highest context ID 16383) number to be used by the UE decompressor. Default value is 15. >>>>Reverse_Decompression_ MD Integer Determines Depth (0..65535) 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). 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 LosslessCriteria
REL-4
REL-4 REL-4
REL-4
REL-4
REL-4
REL-4
Explanation 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

Lossless

and not needed otherwise. 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 mode

Need MP Multi Type and Reference Enumerated (O-mode, Rmode) Semantics description The UE shall only transit to the signalled mode for operation of RoHC as decribed in [36]. Version REL-5
Information Element/Group name Target Mode
10.3.4.3
PDCP SN info
Need MP Multi Type and Reference Integer(0..65 535) Semantics description The PDCP sequence number, which the sender of the message is expecting next to be received.
Information Element/Group name Receive PDCP sequence number
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 Parameters

4.3.1.1 Supported RoHC profiles This 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 sessions This parameter defines the maximum number of header compression context sessions supported by the UE, excluding context sessions that leave all headers uncompressed. UE-EUTRA-Capability The 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 ::= accessStratumRelease ue-Category pdcp-Parameters phyLayerParameters rf-Parameters measParameters featureGroupIndicators interRAT-Parameters utraFDD utraTDD128 utraTDD384 utraTDD768 geran cdma2000-HRPD cdma2000-1xRTT }, nonCriticalExtension } AccessStratumRelease ::= SEQUENCE { AccessStratumRelease, INTEGER (1..5), PDCP-Parameters, PhyLayerParameters, RF-Parameters, MeasParameters, BIT STRING (SIZE (32)) SEQUENCE { IRAT-ParametersUTRA-FDD IRAT-ParametersUTRA-TDD128 IRAT-ParametersUTRA-TDD384 IRAT-ParametersUTRA-TDD768 IRAT-ParametersGERAN IRAT-ParametersCDMA2000-HRPD IRAT-ParametersCDMA2000-1XRTT SEQUENCE {}
OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL OPTIONAL
ENUMERATED { rel8, spare7, spare6, spare5, spare4, spare3, spare2, spare1, ...} SEQUENCE { SEQUENCE { BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN ENUMERATED { cs2, cs4, cs8, cs12, cs16, cs24, cs32, cs48, cs64, cs128, cs256, cs512, cs1024, cs16384, spare2, spare1} DEFAULT
PDCP-Parameters ::= supportedROHC-Profiles profile0x0001 profile0x0002 profile0x0003 profile0x0004 profile0x0006 profile0x0101 profile0x0102 profile0x0103 profile0x0104 }, maxNumberROHC-ContextSessions
cs16, ... } PhyLayerParameters ::= ue-TxAntennaSelectionSupported ue-SpecificRefSigsSupported } RF-Parameters ::= supportedBandListEUTRA } SupportedBandListEUTRA ::=
SEQUENCE { BOOLEAN, BOOLEAN SEQUENCE { SupportedBandListEUTRA SEQUENCE (SIZE (1..maxBands)) OF SupportedBandEUTRA
70

SupportedBandEUTRA ::= bandEUTRA halfDuplex } MeasParameters ::= bandListEUTRA } BandListEUTRA ::= BandInfoEUTRA ::= interFreqBandList interRAT-BandList } InterFreqBandList ::= InterFreqBandInfo ::= interFreqNeedForGaps } InterRAT-BandList ::= InterRAT-BandInfo ::= interRAT-NeedForGaps } IRAT-ParametersUTRA-FDD ::= supportedBandListUTRA-FDD } SupportedBandListUTRA-FDD ::= SupportedBandUTRA-FDD ::= SEQUENCE { INTEGER (1..64), BOOLEAN SEQUENCE { BandListEUTRA
SEQUENCE (SIZE (1..maxBands)) OF BandInfoEUTRA SEQUENCE { InterFreqBandList, InterRAT-BandList
OPTIONAL
SEQUENCE (SIZE (1..maxBands)) OF InterFreqBandInfo SEQUENCE { BOOLEAN SEQUENCE (SIZE (1..maxBands)) OF InterRAT-BandInfo SEQUENCE { BOOLEAN SEQUENCE { SupportedBandListUTRA-FDD SEQUENCE (SIZE (1..maxBands)) OF SupportedBandUTRA-FDD ENUMERATED { bandI, bandII, bandIII, bandIV, bandV, bandVI, bandVII, bandVIII, bandIX, bandX, bandXI, bandXII, bandXIII, bandXIV, bandXV, bandXVI, ...} SEQUENCE { SupportedBandListUTRA-TDD128 SEQUENCE (SIZE (1..maxBands)) OF SupportedBandUTRA-TDD128 ENUMERATED { a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...} SEQUENCE { SupportedBandListUTRA-TDD384 SEQUENCE (SIZE (1..maxBands)) OF SupportedBandUTRA-TDD384 ENUMERATED { a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...} SEQUENCE { SupportedBandListUTRA-TDD768 SEQUENCE (SIZE (1..maxBands)) OF SupportedBandUTRA-TDD768 ENUMERATED { a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...} SEQUENCE { SupportedBandListGERAN,
IRAT-ParametersUTRA-TDD128 ::= supportedBandListUTRA-TDD128 } SupportedBandListUTRA-TDD128 ::= SupportedBandUTRA-TDD128 ::=
IRAT-ParametersGERAN ::= supportedBandListGERAN
71

interRAT-PS-HO-ToGERAN } SupportedBandListGERAN ::= SupportedBandGERAN ::= BOOLEAN
SEQUENCE (SIZE (1..maxBands)) OF SupportedBandGERAN ENUMERATED { gsm450, gsm480, gsm710, gsm750, gsm810, gsm850, gsm900P, gsm900E, gsm900R, gsm1800, gsm1900, spare5, spare4, spare3, spare2, spare1, ...} SEQUENCE { SupportedBandListHRPD, ENUMERATED {single, dual}, ENUMERATED {single, dual} SEQUENCE (SIZE (1..maxCDMA-BandClass)) OF SEQUENCE { SupportedBandList1XRTT, ENUMERATED {single, dual}, ENUMERATED {single, dual} SEQUENCE (SIZE (1..maxCDMA-BandClass)) OF
IRAT-ParametersCDMA2000-HRPD ::= supportedBandListHRPD tx-ConfigHRPD rx-ConfigHRPD } SupportedBandListHRPD ::= BandclassCDMA2000 IRAT-ParametersCDMA2000-1XRTT ::= supportedBandList1XRTT tx-Config1XRTT rx-Config1XRTT } SupportedBandList1XRTT ::= BandclassCDMA2000 -- ASN1STOP
72

Rapport LTE

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport LTE

Transféré par

Droits d'auteur :

Formats disponibles

NEXTTV4ALL

Mmoire de fin dtudes Master Informatique, option Systmes et Rseaux

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 matires

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

VU DINH Dau Promotion 13, IFI

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

VU DINH Dau Promotion 13, IFI

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

VU DINH Dau Promotion 13, IFI

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

VU DINH Dau Promotion 13, IFI

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

VU DINH Dau Promotion 13, IFI

Glossaire des Abrviations

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

VU DINH Dau Promotion 13, IFI

Index des illustrations

Index des tables

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

VU DINH Dau Promotion 13, IFI

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

VU DINH Dau Promotion 13, IFI

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

VU DINH Dau Promotion 13, IFI

1.3 Intrt personnel pour ce stage

1.4 Objectifs de mes contributions

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

VU DINH Dau Promotion 13, IFI

1.5 Plan du document

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

VU DINH Dau Promotion 13, IFI

2 EPS/LTE volution de l'UMTS

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

VU DINH Dau Promotion 13, IFI

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

VU DINH Dau Promotion 13, IFI

2.1.2 Architecture de l'UMTS

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

VU DINH Dau Promotion 13, IFI

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

VU DINH Dau Promotion 13, IFI

MSC Server GMSC Server

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

ATM transport M3UA MTP3B

IP transport M3UA SCTP IP LL

SCTP SCCF-NNI IP SSCOP

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

VU DINH Dau Promotion 13, IFI

ATM transport IP transport AAL2 ATM RTP UDP/IP LL

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

VU DINH Dau Promotion 13, IFI

2.1.3 Technologies concurrentes

2.2 volution LTE 2.2.1 Contexte et exigences

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

VU DINH Dau Promotion 13, IFI

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

VU DINH Dau Promotion 13, IFI

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

2.2.2 Architecture de LTE

Rseaux PSTN Rseaux IP

Rseaux Non-3GPP Wifi, Wimax