P. 1
LTE_FR

LTE_FR

|Views: 178|Likes:
Publié parNabil Chiguer

More info:

Published by: Nabil Chiguer on Apr 09, 2012
Droits d'auteur :Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

08/02/2013

pdf

text

original

NEXTTV4ALL

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

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

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

CESSON-SÉVIGNÉ, FRANCE September, 2009

Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE

VU DINH Dau Promotion 13, IFI

Table des matières
Glossaire des Abréviations..........................................................................................................7 1 Introduction..............................................................................................................................9 1.1 Contexte............................................................................................................................9 1.2 Problématique.................................................................................................................10 1.3 Intérêt personnel pour ce stage.......................................................................................11 1.4 Objectifs de mes contributions.......................................................................................11 1.5 Plan du document...........................................................................................................12 2 EPS/LTE évolution de l'UMTS..............................................................................................13 2.1 Contexte de l'UMTS.......................................................................................................13 2.1.1 Évolution de UMTS................................................................................................13 2.1.2 Architecture de l'UMTS..........................................................................................15 a) Architecture générale de l'UMTS......................................................................15 b) Architecture protocolaire de l'UMTS................................................................17 2.1.3 Technologies concurrentes ....................................................................................19 2.2 Évolution LTE................................................................................................................20 2.2.1 Contexte et exigences.............................................................................................20 2.2.2 Architecture de LTE...............................................................................................22 2.2.2.1 Noeuds principaux..........................................................................................23 2.2.2.2 Architecture protocolaire ...............................................................................25 a) Plan de contrôle..................................................................................................25 b) Plan utilisateur...................................................................................................26 2.2.3 Interface radio.........................................................................................................26 2.2.4 La sous-couche PDCP............................................................................................27 2.2.5 Couche physique ....................................................................................................29 3 RoHC dans UMTS/LTE.........................................................................................................30 3.1 Description de RoHC.....................................................................................................30 3.2 RoHCv2..........................................................................................................................31 3.2.1 Motivation de proposition de RoHCv2 dans PDCP/LTE.......................................31 3.2.2 Améliorations et autres différences de RoHCv2 avec RoHCv1.............................31 3.2.3 Les profils de RoHCv2...........................................................................................32 3.2.4 Compresseur et décompresseur..............................................................................33 3.3 Recommandation de RoHC dans 3GPP.........................................................................33 3.4 Support de RoHC au terminal........................................................................................34 3.5 Procédure de déclenchement de RoHC..........................................................................35 3.6 RoHC et handover..........................................................................................................37 3.7 RoHC et MBMS.............................................................................................................38 3.7.1 MBMS....................................................................................................................38 3.7.2 RoHC et Broatcast/Multicast .................................................................................39 4 Évaluation de la performance de ROHCv1............................................................................40 4.1 Objectifs.........................................................................................................................40 4.2 Scénarios........................................................................................................................40 4.2.1 Modèle d'évaluation de performance......................................................................40 4.2.2 Choix de modèle de fautes......................................................................................41 4.3 Pre-tests..........................................................................................................................42 4.4 Résultats.........................................................................................................................43 2

Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE

VU DINH Dau Promotion 13, IFI

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

3

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 souhaite également remercier Xavier LE BOURDON. Je voudrais aussi remercier Ana Carolina MINABURO qui a sélectionné ma candidature de stage. 4 . IFI Remerciements Je tiens tout d’abord à remercier Loutfi NUYAMI qui a suivi mon travail théorique concernant l'architecture des réseaux cellulaires. Je tiens à remercier Jean-Marie BONNIN et Stéphane ROLLAND qui m'ont donné des conseils sur le plan de travail.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. Je voudrais remercier Eric Poilvet qui m'a donné des conseils sur l'architecture de UMTS. Je voudrais remercier Michel BADET qui a travaillé en coopération avec moi pour localiser et corriger des anomalies de performance de RoHCv1. Il m'a donné également des conseils sur la méthodologie de recherche. je voudrais remercier mon professeur à l'Institut de la Francophonie d'Informatique (IFI) qui n'ont donné des cours de réseaux afin d'avoir les connaissances de base pour réaliser ce stage. Je voudrais remercier Jean-Charles Point qui a financé pour mon stage. Je voudrais également remercier Thomas Lefort qui m'a aidé sur la partie concernant RoHCv2. et donné fréquemment des commentaires forts utiles sur mon travail. et la recherche dans la grande quantité de documents de 3GPP. Enfin. et donné un environnement professionnel favorable à mon travail.

PDCP. RoHC permet de réduire la taille des paquets IP des applications multimédia dans lesquels la taille de payload est souvent petite par rapport à la taille d'entête. IPTV. RoHC introduit un phénomène de gigue au niveau applicatif. RoHCv2. Elle montre que RoHC est très robuste contre des erreurs sur le lien radio. Nos études montrent que RoHC prend place au niveau de la souscouche PDCP. UMTS. RoHC permet d'économiser environ 40% de bande passante pour les applications audio et environ 10% de bande passante pour les applications vidéo. Dans ce document. IFI Résumé LTE (Long Term Evolution) est la dernière évolution d'une série de technologies cellulaires sans-fil GSM/UMTS/HSPA. La compression d'entêtes RoHC (Robust Header Compression) est une technologie présente dans LTE à l'interface radio où la bande passante est limitée et coûteuse. 4G. LTE. et peut réduire le taux de perte de paquets dans le cas de handover. Elle est prise en compte dans l'architecture de LTE. en compétition pour être la norme de la quatrième génération de réseau mobile (4G). et que les profils de RoHCv1 et de RoHCv2 sont prévus.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. Les innovations au niveau de l'interface radio et de l'architecture « plate et tout-IP » permettent de réduire le délai d'accès et d'enrichir des services multimédia comme les services de télévision sur IP à haut débit. La deuxième version de RoHC (RoHCv2) simplifie l'implémentation de RoHC et améliore la performance dans le cas de handover. 5 . Mots clés : réseau cellulaire. nous analysons l'architecture de LTE afin de connaître l'intégration de RoHC dans ce système. Nous étudions également le support de RoHC par LTE dans le cas de handover et dans les services de broadcast/multicast. Cependant. compression des entêtes RoHC. Le deuxième axe de travail fut une campagne de tests sur l'implémentation de JCP-Consult.

found RoHC introduces a little jitter to the multimedia flows. and can reduce the loss rate in handover. LTE. toward the fourth generation of cellular wireless known as 4G. Robust Header Compression (RoHC) is a solution of LTE at the radio interface to optimize the throughput of audio/video applications. We. Our study shows that RoHC takes place at PDCP radio layer. the mobile broadband technology standards. profiles of both RoHCv1 and RoHCv2 are supported.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. 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. where packets generally contain a large header in comparison with their payload. We analyze the architecture of LTE to integrate RoHC in this system. We also studied the support of RoHC by LTE in handover and the services broadcast/multicast. 6 . however. UMTS. IPTV. IFI Abstract LTE (Long Term Evolution) is the latest evolution of GSM/UMTS/HSPA. The verification on the implementation of JCP-Consult proves that RoHC is very robust against errors in the radio link. 4G. It helps reduce about 40% bandwidth of VoIP flow and about 10% bandwidth of video flow. RoHCv2. Keywords: cellular network. RoHC. The second version of RoHC (RoHCv2) that simplifies the implementation of RoHC and improves the performance in handover is supported by LTE. PDCP. header compression.

IFI Glossaire des Abréviations 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 .Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13.Frequency SC-FDMA Division Multiple Access Signalling Connection Control SCCP Part SFN Single Frequency Network SIGCOMP Signaling Compression SIP Session Initiation Protocol SRAN Satellite Radio Access Network TDD Time Division Duplex Universal Decompressor Virtual UDVM Machine UE User Equipment UMB Ultra Mobile Broadband Universal Mobile UMTS Telecommunications System 7 .

........................43 Illustration 16: Taux de bande passante économisée VoIP AMR 12...................................................47 Illustration 22: Taux de paquets perdus Video H264 haute qualité.......... IFI Index des illustrations Illustration 1: Le débit des évolutions différentes de l'UMTS (le bleu présente le débit en théorie..........50 Illustration 29: Taux de paquets perdus VoIP 12..........................................41 8 .....................................................................................40 Illustration 14: Pre-tests............................................17 Ilustration 4: L'architecture protocolaire de l'UMTS dans le plan de contrôle (domaine de PS.....................................................................................33 Tableau 2: Les paramètres sont définis par la couche supérieure de PDCP[17]................. source : [5]).......................58 Illustration 34: Format of a SIGCOMP message............45 Illustration 19: Taux de bande passante économisée Vidéo H264 moyenne qualité.....................................27 Illustration 11: La fonction de la couche PDCP [17]...............................................................................................................................2 kbps...........................28 Illustration 12: Procédure pour configurer et déclencher RoHC dans l'interface radio.............48 Illustration 28: Taux de bande passante économisée VoIP 12............................... release 5).............................. 24 Illustration 8: Plan contrôle en couches [16]...................50 Illustration 31: Pile protocolaire avec la compression......................................................................................60 Index des tables Tableau 1: Les profils supportés par LTE [17]................................19 llustration 6: L'architecture générale du réseau LTE...........47 Illustration 24: Nombre maximal de paquets perdus successifs VoIP AMR 12................................45 Illustration 17: Taux de bande passante économisée VoIP AMR 23 kbps.....................................................48 Illustration 26: Nombre maximal de paquets perdus successifs Video H264 haute qualité....................................Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13..........47 Illustration 23: Taux de paquets perdus Vidéo H264 moyenne qualité.................................17 Illustration 5: L'architecture protocolaire de l'UMTS dans le plan d'utilisateur (release 5)....................16 Illustration 3: Architecture de l'UMTS (release 5)..........................................................................................................................48 Illustration 27: Nombre maximal de paquets perdus successifs Vidéo H264 moyenne qualité .....................2kbps.........56 Illustration 33: La mémoire d’UDVM.............................................................22 Illustration 7: La différence entre eNodeB (LTE) et NodeB (HSPA) au plan utilisateur [15]..............2 kbps...2kbps.....................................................................................................45 Illustration 18: Taux de bande passante économisée Video H264 haute qualité.... le nombre maximal de paquets perdus est très haut dans O-mode................................35 Illustration 13: Modèle d'évaluation de performance de RoHC.........................................................................48 Illustration 25: Nombre maximal de paquets perdus successifs VoIP AMR 23 kbps...34 Tableau 3: Les différents flux pour évaluer la performance de RoHC.........................................47 Illustration 21:Taux de paquets perdus VoIP AMR 23 kbps........................................................................42 Illustration 15: Bande passante économique dans U-mode et BER = 0..................................................................50 Illustration 30: Nombre maximal de paquets perdus successifs VoIP 12.......14 Illustration 2: Architecture de l'UMTS (release 99)..........26 Illustration 10: La deuxième couche de l'interface radio au sens descendant [16]........................................................................................................................................................25 Illustration 9: Plan utilisateur....2kbps........................2 kbps..... le vert présente le débit que l'on espère..............0 avec des flux différents................58 Illustration 35: Compression SigComp.............................45 Illustration 20: Taux de paquets perdus VoIP AMR 12.................................55 Illustration 32: SIGCOMP Architecture .....................

. Devoteam..57 Tableau 6: Ratio de Compression pour les messages SIP [45]... Dans le projet NextTV4all. notamment les protocoles de notamment concernant les projets de recherches européens .. c'est-à-dire la corrélation entre métadonnées associées au contenu....... et s’inscrit dans le thème « télévision sur IP basé sur IMS » dans un environnement de convergence fixe-mobile...... Le Télégramme....59 1 Introduction 1..... LTE).... JCP-Consult participe à l'étude de la qualité de service « inter-couches ».....42 Tableau 5: Instructions d’UDVM et les valeurs de pseudo code.. Neotilus..... France Télécom.... dont le domaine d'activité se présente selon les deux axes suivants :  Expertise.. Les partenaires du projet sont: Alcatel Lucent............... Le département de recherche RSM (Réseau.. JCP-Consult est une PME.... Thomson Telecom.. standardisation et montage de projets de Recherche et Développement... JCP Consult...... IRISA/Université de Rennes 1......Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. située à Cesson-Sévigné. Le projet prend en compte les interactions entre les services audiovisuels interpersonnels et conversationnels et les services de IPTV[annexe du projet].. elle implémente une pile RoHCv2 afin d'étudier les qualités et les défauts de ce protocole...... réservation de ressource et couche MAC..... TELECOM Bretagne........ NEXCOM Systems.. Cette entreprise participe également à l'étude des protocoles RoHCv1 et RoHCv2 au sein des architectures du projet (IMS.. Le projet NextTV4All (Next TV for all: télévision à venir pour tous) est un projet du Pôle Images & Réseaux. Enfin....... Sécurité et Multimédia) de TELECOM Bretagne à Rennes est actif 9 ... en coopération avec TELECOM Bretagne..... dans la périphérie de la ville de Rennes.. Le développement de piles de protocole réseaux.............. Thomson Grass Valley...  compression des entêtes RoHC.. TELECOM Bretagne est une Grande École d'ingénieur généraliste et un centre de recherche international dans les sciences et technologies de l'information... Thomson R&D France. IFI Tableau 4: Des anomalies de performance de RoHC de JCP-Consult.1 Contexte Mon stage de fin d'études s’est déroulé sur une période de 6 mois à JCP-Consult... dans le carde du projet NextTV4All du 16 Mars au 15 Septembre 2009. signalisation........

HSPDA) et maintenant LTE offrent des débits de plus en plus importants atteignant jusqu'à 100Mbps. Elle apportent également des simplifications pour RoHCv1. Le projet NextTV4All a pour objectif de préparer les futurs services multimédia des 10 . Le département est actuellement impliqué dans plusieurs projets portant entre autres sur la QoS et les NGN (Next Generation Network). ingénieur de recherche de JCP-Consult. IFI dans l’enseignement et la recherche sur les réseaux et en particulier sur la qualité de service et les nouvelles architectures. maître de conférences de TELECOM Bretagne.2 Problématique L'évolution des technologies pour réseaux mobiles (2G. une des contributions de TELECOM Bretagne est de réaliser des études sur la standardisation de RoHCv2. LTE est basé sur un architecture « plate et tout-IP ».Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. est d’ores et déjà incluse dans les systèmes de téléphonie en cours de déploiement. 3GPP a prévu d’intégrer cette version dans les futures architectures LTE. par exemple pour compresser les tunnels IP dans le cadre de la mobilité. en particulier. est membre du réseau d’excellence EuroFGI et participe à la standardisation de l’Internet à l’IETF. Elle prend en compte des déséquencements de paquets entre compresseur et décompresseur. sans fil).  pratique concernant les tests de la performance de RoHC. a suivi le travail théorique concernant des normes de 3GPP. Cette évolution simplifie l'intégration avec l'architecture IMS qui permet l'inter-fonctionnement entre tous types de réseaux (fixe. Ces débits permettent alors l'accès aux services multimédia sur téléphone mobile. Au-delà des technologies de transport. 1. La première version. De plus RoHC a été adopté dans la release 5 de l'UMTS. la compression d'en-tête RoHC (RObust Header Compression. défini dans le RFC3095 de l'IETF) permet donc une augmentation très importante de la capacité du réseau dans le cas de flux multimédias interactifs. RoHCv1 (RFC 3095). Une seconde version de RoHCv2 (RFC 5225) est actuellement en phase de conception. La taille des paquets dans les flux multimédias associés à la voix ou à la vidéo est petite (20 à 60 octets). Dans le projet. l'architecture de LTE. l'encapsulation RTP/UDP/IP utilisée représente donc une part importante du paquet (40 octets pour IPv4 et 60 octet pour IPv6). mobile. Mon stage fut encadré en partenariat avec ces deux entreprises :  Loutfi Nuyami. a suivi le travail Xavier Le Bourdon.

5G.4 Objectifs de mes contributions L'objectif principal de mon stage était de contribuer à l'état de l'art d'intégration de RoHC dans l'architecture de LTE. la recherche prend en compte la performance de RoHC dans le cas de handover et broadcast/multicast. Une des contributions de JCP-Consult est d'étudier et d'intégrer la compression des entêtes dans les réseaux. une expérience dans un entreprise de Recherche & Développement comme JCP-Consult fut très formateur. IFI réseaux IMS[1]. et vice-versa celui du réseau tels que la mobilité et la diffusion broadcast/multicast sur la performance de RoHC ? 1. Cependant. 1. les réseaux mobiles actuels au Vietnam sont considérés à la génération 2. et avec une évolution proche prévue vers 3G. et de vérifier le choix de technologique. les paramètres et procédures définis dans la norme 3GPP.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. donc. C'est une base de travail pour JCP-Consult dans le cadre du projet NextTV4All. Mes contributions sont donc :  Dans le cadre du projet NextTV4All Mon travail fut de contribuer à un état de l'art d'intégration de RoHC dans l'architecture de LTE qui étudie complètement des aspects de RoHC dans les réseaux LTE. De plus.  Je souhaite devenir un ingénieur de recherche. permettant de vérifier la validité des choix techniques. Des études de documents indiquent l'endroit de la compression/décompression. De plus. d'envisager les impacts de RoHC avec la qualité de services. Le projet se terminera alors par une phase d'intégration des équipements et des services développés.  En interne pour l'entreprise JCP-Consult 11 . Les études visent à répondre à deux questions :   Comment intégrer RoHC dans l'architecture de LTE ? Quel sera impact de RoHC sur les services de LTE tels que des applications audiovisuelles. Cela permet d'implémenter RoHC. un candidat à la future 4G. 3GPP se composent la grande quantité de documents avec des évolutions continuelles sont la terre fertile pour faire des recherches et des développements. les profils supportés. à partir de l'analyse et du développement des différents services unitaires et des équipements.3 Intérêt personnel pour ce stage  LTE est la dernière évolution dans une série de technologies de GSM/UMTS/HSPA dominantes.

des caractéristiques principales de LTE afin d'indiquer ses interactions avec des services dont IPTV. la recommandation RoHCv2 et ses caractéristiques. une solution d'optimisation de transmission au niveau d'application par SIGCOMP est étudiée. Les tests de performance sont réalisés à partir de l'implémentation de JCP-Consult. Tous les aspects de RoHC envisagés par 3GPP release 8 sont étudiés tels que les paramètres de configuration. les profils. Tout cela permet de refaire des tests avec l'implémentation de RoHCv2 qui est en train d'être développée. Le simulateur permet dans la suite de simuler l'autre caractéristique telle que le problème de délai et déséquencement du lien radio.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. et un outil d'évaluation de la performance de RoHC. 12 . Les fautes peuvent être générées selon les différents distributions de Uniform. et la recommandation de RoHC dans le cas de handover et dans les services de broadcast/multicast. Le quatrième chapitre présente les résultats d'évaluation de performance de RoHC et les impacts sur la qualité de services. Les discussions avec les ingénieurs à JCP-Consult ont permis de corriger des bugs dans l'implémentation.5 Plan du document La suite de ce rapport est organisée de la façon suivante. le processus de déclenchement. Le troisième chapitre 3 présente le protocole RoHC et les supports de RoHC dans LTE. IFI J'ai développé un simulateur de fautes au niveau du lien radio. j'ai comparé la performance de RoHCv1 de JCP-Consult avec une autre implémentation afin d'améliorer implémentation de JCP-Consult à l'avenir. Le deuxième chapitre présente la série d'évolutions de technologies de 3GPP. des innovations. et des pertes de paquets. De plus. j'ai trouvé des anomalies par rapport des évaluations de performance de manière théorique. A la fin de mon stage. Cette partie se concentre sur l'architecture de LTE qui permet de localiser la place RoHC dans la partie suivante. 1. Enfin. et Gilbert-Ellibott. L'outil de test permet d'évaluer la performance de RoHC à partir des paquets « live » qui sont capturés du réseau. Lors de mes tests de la performance de RoHCv1. les résultats de tests sont raisonnables et correspondent aux attentes théoriques. Le simulateur est capable de simuler des bits erronés. Gilbert simple (ou 2-states Markov).

de 2 Mbps. « video streaming ». release 99. à 14. en théorie à 5. De plus. VoIP. en théorie.1 Contexte de l'UMTS 2. .. Le réseau du cœur se base sur le réseau de transport du GSM et GPRS.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13.. Le débit maximal dans le sens descendant est. Cette version inclut deux évolutions dans le réseau UMTS : le support d’IP au niveau du réseau coeur et HSDPA. Les interfaces radio des deux réseaux d'accès sont supportées par l'ATM. Cette interface utilise un débit « chip » inférieur (1. le MSC se divise entre le serveur de MSC pour assurer le contrôle d'appel. En conséquence. est publiée mi-1999. Le mécanisme de HSDPA se base sur le canal radio qui est partagé entre tous les utilisateurs dans le sens descendant.[3] La release 6 est terminée en mars 2005. La release 4 de l'UMTS est terminée en mars 2001. Le GSMC se divise également entre le serveur de GSMC et CS-MGW. Cette version apporte le mécanisme de HSUPA afin d'accroître le débit montant maximal. Le HSUPA utilise des 13 . Le protocole IP est considéré afin de remplacer l'ATM dans la couche de transport. Cette version ajoute la deuxième interface radio de type TDD.1. en théorie. et dans le sens montant est de 768 kbps. la nouvelle architecture IMS (IP Multimedia Subsystem) apporte une évolution importante dans le réseau cœur afin de mieux supporter des applications IP telles que : partage audio/vidéo.84 Mcps) afin de s’adapter à la bande inférieure (donc 6MHz) que la bande traditionnelle de TDD. et CS-MGW pour assurer la transmission. Cette version utilise une nouvelle interface radio qui se base sur CDMA (l'accès multiple à répartition en codes). sur l'évaluation en temps réel du canal radio.[2] La release 5 est terminée en mars 2002. TD-SCDMA. Il y a deux types de réseau d'accès : FDD et TDD (TD-CDMA).76 Mbps. et sur la retransmission rapide (HARQ) afin d'augmenter le débit descendant. IFI 2 EPS/LTE évolution de l'UMTS 2.1 Évolution de UMTS UMTS comporte des évolutions qui sont définies par les releases suivantes : La première. La release 4 apporte une évolution importante dans le réseau cœur qui sépare la signalisation de la transmission (« call and bearer separation »). Et le SIP (Session Initiated Protocol) est le protocole principal d'IMS afin de contrôler les sessions établies. et apporte des évolutions significatives.28 Mcps) par rapport au TD-CDMA (3.4 Mbps.

IFI techniques comme HSDPA telles que HARQ. au débit montant d'atteindre 11. Cette version apporte des améliorations sous le nom de HSPA+ pour HSPA.[4] Illustration 1: Le débit des évolutions différentes de l'UMTS (le bleu présente le débit en théorie. La combinaison de HSDPA et HSUPA s'appelle HSPA. mais des canaux radio partagés sont remplacés par des « dedicated channels ».2 Mbps. source : [5]) La release 7 est terminée en juillet 2007. De plus. les services de MBMS permettent de diffuser de contenu en mode broadcast et multicast. HSPA+ permet au débit descendant d'atteindre 42. Cette diffusion est utilisée souvent par des applications telles que la télévision mobile. le vert présente le débit que l'on espère.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. Le troisième choix pour l'interface radio 14 . En théorie.5 Mbps.

l'adaptation du débit de transmission.1. et du contrôle de la puissance d’émission. de l’authentification. 2. Le RNC sert à la gestion de ressources radio.68 Mcps. Cette version apporte des évolutions significatives d'UMTS sous le nom de LTE. L'autre domaine est le domaine de broadcast (BC) afin de 15 . Il se compose des NodeB et des RNC (Radio Network Control) qui correspondent respectivement à la BTS et au BSC dans l'architecture GSM. élargissement/des-élargissement. le réseau cœur se compose de serveurs et de passerelles qui se divisent entre deux domaines principaux: le domaine CS (domaine de commutation de circuits) et le domaine PS (domaine de commutation de paquets). de la sécurité des échanges et de la taxation.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. La release 9 développe les caractéristiques manquantes. Un NodeB peut servir une ou plusieurs cellules. La comparaison des évolutions de l'UMTS est disponible dans la figure 1. Cela permet au terminal de s’éteindre après une période d'inactivité de ces canaux. du codage de canal.[7] Le réseau cœur regroupe des fonctions permettant l'acheminement des données d'utilisateur vers la destination correspondante. Dans le rôle d'acheminement. La technique de CPC (Continuous Packet Connectivity . de la modulation/démodulation. IFI de type TDD a le débit chip de 7. La release 8 est terminée avec des exigences de haute priorité et des caractéristiques essentielles. donc de diminuer sa consommation d'énergie. et du « soft handover » par exemple. et de la synchronisation. Le réseau d'accès (UTRAN) regroupe des fonctions permettant de transmettre des informations (trafic de données et trafic de signalisation) de l'utilisateur vers le réseau cœur. la gestion d'appel. La release 10 se concentre sur LTE-Advanced.2 Architecture de l'UMTS a) Architecture générale de l'UMTS L'architecture générale du réseau UMTS se compose d'un réseau d'accès et d'un réseau cœur (figure 2). Connectivité permanente pour les utilisateurs des services paquets) est utilisée pour diminuer l'interférence causée par des canaux «dedicated physical control » lorsqu'il n’y a aucun utilisateur sur ces canaux. Il contrôle un ou plusieurs NodeB via l'interface Iub. Le NodeB s'occupe de la transmission et de la réception du signal radio.[6] La release 8 est en cours d’achèvement. de la mobilité.

Le GSMC se divise également entre le serveur de GSMC et CS-MGW. Dans release 5 (cf. et SRAN (Satellite Radio Access Network). VLR et GSMC servant à communiquer avec les réseaux de téléphonie donc PSTN.. . modifier et contrôler des sessions établies avec les réseaux IP afin de mieux supporter des applications IP telles que : partage de audio/vidéo. Rel 99 Uu Iub NodeB NodeB RNC MSC/VLR HLR GMSC Iu CS domain PSDN Iur RNC PS domain NodeB SGSN GGSN Internet Réseau d'accès Réseau coeur Illustration 2: Architecture de l'UMTS (release 99) Depuis la release 4. IFI transmettre des messages de broadcast.11.. le MSC/VLR se divise entre le serveur de MSC et CS-MGW. mais supporte aussi d'autres technologies d'accès radio telles que HIPERLAN 2. le HSS (Home Subscriber Server) remplace le HLR et AuC. Le réseau cœur n'est pas obligatoire reliée à l'UTRAN. et PLMN. Cette division a pour but dans le domaine CS de séparer le plan de contrôle et d'utilisateur. de la taxation. figure 3)[8]. les composants réalisent également les fonctions de gestion des utilisateurs. Cela permet à l'opérateur d'élargir la taille et d'optimiser la topologie du système. et le sous-système IMS (IP Multimedia Subsystem) est ajouté. AuC. Le domaine PS comprend le SGSN et le GGSN servant à communiquer avec les réseaux tels que Internet. et de la sécurité. Le domaine de CS comprend le MSC.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. même s’ils partagent quelques composants tels que HSS. L’IMS est une architecture « overlay » servant à établir. IEEE 802. L’IMS se compose des entités fonctionnelles 16 . Le protocole SIP (Session Initiated Protocol) est le protocole principal de signalisation IMS. VoIP. L’IMS utilise le domaine PS pour transmettre des messages de signalisation et des données multimédia.. « video streaming ». Il est indépendant du domaine CS. EIR. En communiquant avec les bases de données partagées telles que HLR.

La division horizontale sépare l'interface en plusieurs des couches. Le plan d'utilisateur transmet des données d'utilisateur. 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 Réseau d'accès Réseau coeur Illustration 3: Architecture de l'UMTS (release 5) b) Architecture protocolaire de l'UMTS Le modèle protocolaire de l'UMTS se compose d’un ensemble de divisions verticales et horizontales. le protocole RANAP (Radio Access Network Application Part) regroupe des fonctions nécessaires pour connecter le réseau d'accès avec le réseau cœur telles que : paging. AS. 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 contrôle (domaine de PS. La division verticale comprend le plan de contrôle et d'utilisateur. L'architecture de référence et les fonctions d'entités IMS sont présentées dans TS 23. IFI principales CSCF(Call Session Control Function) (P/I/S/E-CSCF). Le plan de contrôle transmet des messages de signalisation (source principale [10]). allocation de ressources.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13.228 [9]. MRF. release 5) Dans le plan de contrôle à l'interface Iu (cf. PCRF et différents SBC. figure 4). gestion de la 17 .

SCCP utilise le protocole MTP3 ( Message Transfer Part Layer 3) afin de faire le routage. AAL2 et RTP supportent des données multimédia [7]. des données d'utilisateur sont transmises directement via l'AAL2 ou protocole RTP/UDP/IP à l'interface Iu. A l'interface radio. Dans le plan d'utilisateur du domaine PS (cf. La couche de transport de type IP est basée sur le protocole SCTP/IP. Mais depuis release 5. 18 . la couche de transport via ATM (AAL2/AAL5) est un choix répandu et la couche de transport via IP est un choix optionnel.. 3GPP ajoute la sous-couche PDCP afin de compresser des entêtes. . dans le réseau SS7. Dans le domaine CS. IFI mobilité. La couche de transport de type ATM est basée sur AAL5 (ATM Adaptation Layer 5) qui est un protocole simple et efficace de la famille des AAL. la signalisation du protocole RANAP est transmise via la couche de transport via ATM ou IP. En général. figure 5).. Le protocole SCCP (Signalling Connection Control Part) est choisi pour supporter ces deux couches de transport. de chiffrer les paquets et de transmettre des paquets sans accusés de réception vers le nouveau SRNC pendant un processus de re-allocation de SRNC. les données sont transmises par un tunnel GTP. L'AAL2 donne des connexions qui assurent le délai minimale et permettent de transmettre au débit variable.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13.. les deux ont la même priorité. 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. Les protocole M3UA et SCTP permettent au protocole SCCP de passer dans domaine de IP. Le tunnel GTP est transmis via le protocole UDP/IP.

Cependant. Il existe d'autres alternatives telles que IEEE 802. Mais. pas déployée globalement et peu d'opérateurs proclament officiellement son support à WiMax. LTE est la dernière évolution de cette série. GSM/UMTS/HSPA est une série de technologies dominantes[5] avec des évolutions continuelles. la norme a ajouté le support du multicast. Flickr). En théorie. un successeur de CDMA-2000. Au troisième trimestre 2008. media 19 . Le nombre d'abonnements à la famille CDMA2000 est faible par rapport à la famille GSM/UMTS. Depuis 2005.2 Évolution LTE 2.3 Technologies concurrentes En Juin 2008. aucun opérateur ne qui proclame officiellement son support à EV-DO RevB et UMB.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. 1xEV-DO. MIMO. 2.2. et Metro Wi-Fi. la performance de WiMax est compétitive avec le HSPA+/LTE. WiMax comporte de nombreuses évolutions. la performance de WiMax est diminuée dans une zone urbaine où se trouve un large nombre d'utilisateurs. a été déployé. avec les mêmes innovations à l'accès radio telles que OFDMA. EV-DO peut gagner une même efficacité spectrale[11]. En 2004. WiMax est testée dans un nombre limité de zones. Elle se base sur la norme IEEE 802. IFI 2. elle supporte le handover interBTs.1. en voie pour être la référence 4G. NGMN (Next Generation Mobile Networks Alliance) a choisi LTE comme une technologie qui peut répondre à elle-seule aux exigences des réseaux mobiles de la prochaine génération [11].20 qui ressemble à l'UMB. De plus. IEEE 802. et inter-opérateurs.5Mbps et UMB qui se base sur OFDMA. 3GPP2 a introduit EV-DO RevB dont le débit sur une bande passant de 20MHz atteint 73. Aujourd'hui. Cette technologie est ajoutée à l’IMT-2000 (technologie de 3 G).16 qui peut être déployée sur un spectre libre(5MHz). WiMax est considéré comme une technologie qui peut potentiellement remplacer la technologie cellulaire dans les réseaux sans fil dans les zones étendues. cependant la technologie 3G fournit déjà de l'accès sur une zone plus vaste. La difficulté d'utilisation pour l'ensemble du service de voix des données limite le déploiement d’EV-DO.20 ne gagne pas beaucoup d'intérêt auprès des opérateurs.1 Contexte et exigences Le développement rapide des services de partage audio/vidéo (Youtube. Metro Wi-Fi peut-être une technologie complémentaire qui fournit de l'accès à large bande en centre ville. En comparaison avec HSPA.

un large nombre d’équipements qui permet d’accéder aux services sont disponibles aux utilisateurs tels que : ordinateur portable.4 Mbps sur la bande passante de 20 MHz [13]. Les services de données sont différents des services de voix par: le débit très variable. jusqu'alors. le débit descendant peut atteindre 326. 20 . LTE utilise l’OFDMA pour le sens descendant et SC-FDMA pour le sens montant. "notebook enabled modem" . L’utilisateur a donc besoin d’utiliser ces services avec la même expérience sur le domaine sans-fil. en particulier sur les réseaux cellulaires qui permettent à l’utilisateur d’être connecté accéder n'importe quand. En général. PDA.. pas aux services de données. LTE a pour but d'offrir un haut débit dans le sens montant et descendant..4Mbps with 4x4 MIMO. et le débit montant peut atteindre 86. de réduire le délai d'accès. en combinaison avec de nouvelles technologies d’antenne telles que MIMO et « beaming form ». et l'autre service des données interactifs. Par ailleurs. IPTV..Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. Une cellule peut supporter au moins 200 d’utilisateurs à la bande de 5MHz. smartphone. MySpace) dans le domaine filaire. et un débit montant maximal de 50 Mbps sur une bande passante de 20MHz. réseaux sociaux (Facebook. vidéo-conférence. IFI streaming (VoIP. Les équipements ont donc tendance à utiliser des connexions natives IP sans traduction et filtrage pour supporter efficacement ces services. IPTV).. l'utilisation fréquente de connexion IP. ainsi que la performance en bordure de cellule. Mais en théorie. et d'interfonctionner avec les réseaux existants (3GPP et non-3GPP). Il est prévu d'obtenir un débit descendant de 100 Mbps. s'intéressent principalement au service de voix. Ces données vont produire un débit élevé sur ces réseaux qui. jeux vidéo en ligne.  Réduction du délai d'accès : le délai d'aller-retour est inférieur à moins de 10ms et d'initialisation est inférieur à 100 ms afin de supporter des services interactifs et temps réel. la QoS différente pour chaque utilisateur/service. Les caractéristiques principales de LTE sont (source principale [12]) :  Amélioration de l’interface radio afin d’augmenter le débit montant/descendant. et 400 d'utilisateurs à la bande plus large que 5MHz [14]. Cela permet à l'opérateur de fournir des services tels que VoIP. L’évolution du cœur des réseaux téléphonies arrive à une architecture “tout IP” qui supporte plus efficacement les connexions IP et un réseau entièrement par commutation des paquets facilite les mécanismes de QoS et l’utilisation plus efficace des ressources. génère de grandes quantités de données. et la capacité. d'utiliser une bande passante de manière flexible. n'importe où.

IFI Mobilité : la performance de LTE est optimisée dans le cas où la vitesse est inférieur à que 15km/h.2. 2. selon la bande utilisée)  Flexibilité du spectre radio : LTE peut-être déployé dans des bandes allant de 1. De plus. de ne pas demander le permis de nouvelle bande. LTE supporte FDD et TDD. Il faut que LTE supporte le handover avec les réseaux existants tels que UMTS/HSPA et GSM/GPRS/EDGE. Cela permet à l'opérateur de déployer LTE sur la bande existante. LTE supporte la vitesse de 120 à 350 km/h (voire 500 km/h.25 MHz à 20 Mhz.  Architecture « tout IP ».2 Architecture de LTE IMS Réseau coeur P-GW MME S-GW Plan utilisateur S1 Plan contrôle GERAN UTRAN HSS GSM/UMTS réseau coeur Réseaux PSTN Réseaux IP Réseaux Non-3GPP Wifi. et la bande appariée et non appariée de la 3G. Compatibilité avec les réseaux 3G existants. il y a une partie significative du travail de 3GPP pour convertir l'architecture réseau du cœur vers une architecture tout IP qui est envisagée pour simplifier l'inter-fonctionnement avec les réseaux filaires et les réseaux sans fils non-3GPP.   Architecture simplifiée permet d'améliorer l'extensibilité du réseaux.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE  VU DINH Dau Promotion 13. Wimax eNodeB X2 eNodeB Réseau d'accès Téléphone portable 'dual mode' llustration 6: L'architecture générale du réseau LTE 21 . il faut supporter le handover inter-domaines entre sessions de commutation de paquets et de circuits.

2. Les paquets transmis intereNodeBs (et inter-réseaux 3GPP) sont en transit via cette ancre. Wimax. On peut séparer MME S-GW afin diminuer les interférences entre la signalisation du plan de contrôle et flux 22 . HSS (Home Subscriber Server) est une base de données qui remplace le rôle de HLR et AuC qui étaient déjà introduits dans les réseaux 2G et 3G. et négociation de chiffrement/protection d'intégrité. filtrage des paquets pour chaque utilisateur (Policy Enforcement Point). Le standard ne précise pas l'architecture physique de réseau du cœur. PSTN. MME (Mobility Management Entity) se compose des fonctions principales dans le plan de contrôle. réseaux téléphoniques commutés (PSTN) et les réseaux non 3GPP tels que WiFi. non-3GPP. Il y a trois nœuds principaux : MME au plan contrôle. le réseau LTE a moins de nœuds afin de réduire le délai et d'augmenter la performance du système [14]. le réseau cœur a moins de nœuds. servant à établir.1 Noeuds principaux L'architecture de réseau cœur est basée sur le protocole TCP/IP. (source principale [15]) S-GW (Serving Gateway) achemine des paquets de l'eNodeB vers le réseau cœur et vice-versa.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. et à mettre à jour la position de l'UE. 2. L'allocation d’adresse IP pour l'UE. En comparaison avec le cœur GPRS du réseau UMTS. Cela permet de simplifier l'interfonctionnement avec les réseaux fixes et non-3GPP. une architecture « overlay » par rapport au LTE. et le support de la tarification d'une session sont des autres fonctions du P-GW. Le téléphone portable « dual mode » fournit l'accès au réseau LTE et aussi aux réseaux 3GPP existants. Il sert à gérer des sessions : signalisation. P-GW (Packet Data Network Gateway) fournit des connexions entre réseau LTE et d'autres réseaux IP. mais chaque nœud s'occupe de plus fonctions. P-GW peut se connecter avec les réseaux PSTN et réseaux IP grâce à l’IMS. Il est comme une ancre locale qui sert pour la mobilité inter-eNodeBs et vers les réseaux 3GPP (interconnexions de LTE avec les autres 3GPP). IFI La figure 6 présente l'architecture générale d'un réseau LTE qui se compose d'un réseau d'accès et d'un réseau cœur et d'autres blocs qui permettent aux réseaux LTE de se connecter avec les réseaux 3GPP existants. les réseaux IP.2. et négociation des qualités de service. à fournir des procédures de sécurité telles que : initiation. En comparaison avec l'architecture de UMTS et GSM. S-GW et P-GW au plan utilisateur. modifier et contrôler des sessions.

Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE

VU DINH Dau Promotion 13, IFI

de données élevés du plan utilisateur. On peut séparer P-GW avec MME et S-GW afin d'isoler les paquets internes (du réseau cœur) avec des paquets externes (des autres réseaux IP). L'isolation facilite les opérations de sécurité. Le réseau d'accès est réduit dans l'eNodeB qui joue le rôle du NodeB et du RNC (Radio Network Control) dans les réseaux UMTS. Cela permet de réduire le délai d'accès et de simplifier la fonction d'opération et de maintenance du réseau [14].

Illustration 7: La différence entre eNodeB (LTE) et NodeB (HSPA) au plan utilisateur [15] Dans le rôle du NodeB, l'eNodeB s'occupe de : la modulation/démodulation, le codage/ décodage des informations transmises sur l'interface radio. Dans le rôle du RNC, l'eNodeB s'occupe : du contrôle de ressources, du contrôle de la mobilité, de la compression des entêtes IP, et du chiffrement des données (voir 3GPPP TS 36.300, chapitre 4.1) L'architecture traditionnelle de l'UMTS réserve la complexité et les nombreux calculs au RNC, et permet ainsi au NodeB de rester simple. Le RNC gère donc de nombreux (même des centaines [15]) de NodeBs et se coordonne avec les autres RNC pour contrôler la macrodiversité (afin de réduire l'interférence dans le réseau UTRAN basée sur la couche physique 23

Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE

VU DINH Dau Promotion 13, IFI

de CDMA). Les eNodeB peuvent se connecter directement avec le réseau cœur pour répartir le travail de RNC par l'interface S1. De plus, le mécanisme de retransmission qui est entièrement implémenté dans l'eNodeB diminue le délai. En effet, l'UMTS/HSDPA sépare physiquement la retransmission entre NodeB (mécanisme de HARQ) et RNC (mécanisme de ARQ). La séparation conduit à l'utilisation de deux tampons dans le NodeB et dans le RNC, ce qui augmente le délai d'attente. Par d'ailleurs, le changement de NodeB cause la perte de paquets dans le tampon de ce NodeB. La retransmission par la couche TCP du RNC (troisième couche) coûte donc plus cher. Les eNodeB peuvent se connecter par l'interface X2 pour transmettre des paquets aux tampons, à la couche inférieure (deuxième couche), la retransmission coûte donc moins cher.
2.2.2.2 Architecture protocolaire

Comme le modèle d'interface d’UMTS, le modèle de LTE se compose d'un ensemble de couches verticales et horizontales. Les couches horizontales sont basées sur le modèle OSI. Les couches verticales divisent l'interface entre le plan de contrôle et le plan utilisateur. La division verticale correspond à la façon de séparer les flux de données. Les données du plan de contrôle sont transmises avec des contraints de sécurité, de fiabilité plus importantes. Celles du plan utilisateur sont transmises par des protocoles plus simple.
a) Plan de contrôle

Le plan de contrôle transmet des messages de signalisation telles que la signalisation de gestion de ressource radio, de gestion de mobilité, des services NAS (Non Access Stratum), des autres procédures entre mobile et réseau cœur.
UE NAS RRC PDCP RLC MAC PHY RRC PDCP RLC MAC PHY eNB MME NAS

Illustration 8: Plan contrôle en couches [16] La pile protocolaire à l'interface radio est presque la même que celle du plan utilisateur. Mais les paquets du plan contrôle sont transmis avec la priorité supérieure et une protection 24

Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE

VU DINH Dau Promotion 13, IFI

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

Le plan utilisateur regroupe l'ensemble des données d'usager et des signalisations au niveau application. La figure 9 présente l'architecture protocolaire du plan utilisateur. La couche d'application n'est présente qu’à l’UE et qu’au serveur d'application basé sur le protocole IP. Les données du plan utilisateur sont transparentes pour le cœur de réseaux.
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 données sont transmises par un tunnel GTP-U. GTP-U est une partie du protocole GTP, l'autre partie est GTP-C liée au plan contrôle. Autre la fonction d'établir une connexion de bout en bout entre le mobile et le serveur d'application, le protocole GTP s'occupe d'acheminer les paquets vers l'eNodeB correspondant pendant un déplacement de l'utilisateur. Le protocole GTP est transmis via UDP/IP. La pile du protocole GTP/UDP/IP ajoute donc 36 octets d'entête (20 octets d’IPv4, 8 octets d’UDP, et 8 octets de GTP).

2.2.3 Interface radio
Cette interface fournit des connexions entre UEs et eNodeB. La pile protocolaire est donc spécifique par rapport aux autres interfaces car liée aux liens sans fils. Elle se compose de trois couches : la première couche (physique), la deuxième couche qui ressemble de la couche de liaison du modèle OSI, et la troisième couche (RRC). La fonction principale de RRC est la gestion de la signalisation établie entre UE et eNodeBs. La couche RRC supporte les fonctions de : transfert de la signalisation du NAS, allocation et libération de ressources radio, diffusion de l’information du système, paging, handover, transfert du contexte utilisateur entre eNodeB pendant le handover, mesure et gestion d’énergie. RRC (RRC Connection Reconfiguration Messages/procedures) se compose 25

et correction d'erreurs sur le mécanisme de HARQ qui est héritée de 3G HSDPA. La fonction principale de la deuxième couche est de donner un transport fiable entre deux équipements du réseau. ARQ etc . et demande de retransmission (Auto Repeat Request). détection de perte. 26 . dans le mode d’AM. l'entité RLC peut demander à l'autre bout de retransmettre le paquet. IFI des informations de la configuration des Radio Bearers qui contient des paramètres de la couche inférieure telles que la configuration pour la compression des entêtes de la couche PDCP[Annexe : PDCP Info]. Il y a trois modes de fonctionnement: TM (Transparent Mode). figure 10). ordonnancement selon la priorité (« priority handling »). ARQ etc . Enfin...Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. deux sous-couches de la couche de liaison traditionnelles.. Segm. ARQ etc CCCH BCCH PCCH Scheduling / Priority Handling MAC Multiplexing UE 1 Multiplexing UE n HARQ Transport Channels HARQ Illustration 10: La deuxième couche de l'interface radio au sens descendant [16] La sous-couche MAC regroupe des fonctions qui résolvent des problèmes spécifiques liés à la couche physique pour assurer le couplage entre la couche de liaison et la couche physique. UM (Unacknowledged Mode). Radio Bearers ROHC PDCP Security Security Security Security ROHC ROHC ROHC RLC Segm. ARQ etc Logical Channels Segm.. La couche peut détecter des pertes et remettre en ordre des paquets dans le mode UM. telles que : multiplexage des canaux logiques vers canaux de transport correspondants (selon la pré-configuration). Segm. La sous-couche RLC regroupe des fonctions indépendantes de la couche physique. RLC n'ajoute rien au paquet original dans le mode TM. A côté de MAC et RLC. 3GPP ajoute une sous-couche PDCP (cf. telles que : remise en ordre des paquets. et AM (Acknowledged Mode).

Chaque entité est rattachée à une entité de la couche supérieure (Data Radio Bearer). Illustration 11: La fonction de la couche PDCP [17] Dans le cas de handover. Le protocole RTP/UDP n'a pas de 27 . ensuite tous les paquets qui ne sont pas acquittées par la couche inférieure sont retransmises jusqu'à ce que tout le tampon de HARQ soit vide.2. Garantir de l'intégrité des messages de signalisation du plan de contrôle. la couche supérieure va s'occuper de retransmettre les paquets. et dans le sens montant. La figure ci-dessous représente les fonctions d’une entité PDCP (source principale [17]) :       Utiliser RoHC pour compresser/décompresser des entêtes de paquets. l'eNodeB va transmettre tous les paquets qui ne sont pas acquittés par la couche inférieure vers le nouveau eNodeB par l'interface X2.4 La sous-couche PDCP La sous-couche PDCP se compose des entités PDCP. Mettre en ordre des paquets de la couche RLC. S'il n'y a pas d'interface X2 entre deux eNodeB. l'entité PDCP va rétablir la compression des entêtes (recréer la contexte de RoHC).Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. IFI 2. Ajouter/enlever un entête PDCP Ne pas traiter les messages de signalisation de contrôle broadcast et de paging. et une ou deux entités de la couche RLC. Dans le sens descendant. ensuite rétablir la compression des entêtes. Chiffrement et déchiffrement des messages de signalisation du plan utilisateur.

est inférieur à celui de l’OFDMA. 28 . MIMO fonctionne mieux dans une région urbaine où il y a un large nombre d'utilisateurs mobiles (haut ratio de SNR et assez de diffusion « rich scattering ») [14]). OFDMA est une combinaison de technique de modulation et de technique d'accès multiple. plus le prix et la consommation d’énergie du terminal augmentent [20]. Dans le sens montant.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13.5 Couche physique Les deux techniques qui apportent des évolutions de LTE dans le réseau d'accès sont OFDMA et MIMO. QAM-64. OFDMA répartit la bande passante en N multiples sous-porteuses orthogonales qui sont partagées par de plusieurs utilisateurs. OFDM a la même efficacité spectrale mais fonctionne mieux que la bande passante supérieure à 10MHz. MIMO est une technologie antenne avancée. En comparaison avec 1x1 antenne. MIMO est également une technique de diversité spatiale qui augmente la capacité du système et le débit d'utilisateur sans énergie de transmission et ni de bande passante supplémentaires. En comparaison avec les techniques d'antennes traditionnelles qui améliorent la qualité d'un canal. Chaque sous-porteuse est modulée indépendamment en utilisant des modulations numériques : QPSK.2. cela permet à la couche supérieure (MAC) de planifier plus flexiblement l'utilisation des ressources [19]. mais il a été choisi car son taux de PAPR « Peak-to-Average Power Ratio ». L'affectation nombre de sous-porteuses pour un utilisateur est dynamique. 2. 2x2 MIMO peut augmenter 80% de débit[5]. qui permet de multiples transmissions en parallèle (canaux orthogonaux) par l'utilisation de plusieurs antennes au niveau du récepteur et de l'émetteur. QAM-16. OFDMA réduit le problème d'ISI (Inter Symbol Interference) qui est causé par des trajets multiples et enlève l'utilisation de l'égalisation. le récepteur les retrouve en appliquant des IFFT. Plus ce taux est haut. L'augmentation de la qualité est proportionnel au nombre d'antennes. IFI mécanisme de retransmission et ne peut donc pas rattraper les pertes éventuelles dans les services VoIP et IPTV [18]. En comparaison avec CDMA. OFDMA est bien adapté aux services broadcast/multicast car OFDM permet au mobile de combiner le signal de multiples émetteurs. le mécanisme de SC-FDMA est basé sur le même principe qu’OFDMA.

1. mais permet de s’adapter aux caractéristiques du lien et au flux de données. calculé avant la compression. Ceci a conduit à des nouveaux travaux au sein de l'IETF qui ont débouché sur une nouvelle version du protocole RoHC (RoHCv2) qui se différencie de la précédente version du protocole RoHC (ROHCv2). mais aussi de la redondance entre plusieurs en-têtes consécutifs. l'encapsulation RTP/UDP/IP utilisée représente donc une part importante du paquet (40 octets pour IPv4 et 60 octet pour IPv6). Elle se différencie de la précédente pour les formats de paquets qui sont utilisés. 2 et 3[17]. 29 . entre autres : la décision du passage dans le décompresseur pour travailler dans le mode optimiste ou fiable. Ainsi l'information qui ne change pas est envoyée au début de la session ou à un faible rythme. La norme RoHC a laissé ouverts de nombreux choix de mise en œuvre. en particulier pour le protocole IPv6. puisque l’information transmise est susceptible d’être modifié suite à des erreurs de transmission. d'IPv6 et de la 3G a permis de relever quelques incohérences dans les documents.1 Description de RoHC La taille des paquets dans les flux multimédias associés à la voix ou la vidéo est petite (20 à 60 octets). les valeurs des différents paramètres qui sont utilisés pour la compression. De plus RoHC a été adopté dans la release 4 de l'UMTS. L’élément clé est le CRC. pour les autres champs.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. Le principe de RoHC est d’envoyer l’information minimale pour que le décompresseur puisse reformer l’en-tête. Le mécanisme pour la compression des en-têtes RoHC intègre des fonctionnalités de robustesse permettent de supporter des réseaux bruités. L'étude approfondie des spécifications de RoHC. la compression d'en-tête RoHC (RObust Header Compression. Le principe à la base de la compression des en-têtes est la réduction de la redondance de l'information contenue dans un en-tête. IFI 3 RoHC dans UMTS/LTE 3. défini dans le RFC3095 de l'IETF) permet donc une augmentation très importante de la capacité du réseau dans le cas de flux multimédias interactifs. Offrant une grande flexibilité dans le mécanisme à travers les différents profils et modes d’opération. La norme 3GPP pour RoHC (TS25. Il donne au décompresseur une information sur la validité de l’information qu’il possède. un mécanisme de prédiction ou de dépendance permet de réduire encore l'information transmise. L’architecture du mécanisme de Compression RoHC est complexe.323) rend obligatoire les profils 0.

RoHCv2 est défini par trois documents :   La RFC 4995 décrit le framework commun à v1 et v2 pour la plus grande part.2 RoHCv2 Tandis que RoHCv1 est spécifié principalement par la RFC 3095.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13.2 Améliorations et autres différences de RoHCv2 avec RoHCv1 Les formats de compression v2 sont au moins aussi performants. Sa logique opérationnelle est plus simple et plus homogène que celle de RoHCv1. IFI 3. Dans la même condition de fonction.  RoHCv2 n'utilise pas de format IR-DYN (Initialization & Refresh / Dynamic 30 . le flux compressé sera affecté à un nouveau contexte. Le mécanisme utilisé permet en outre une meilleure tolérance au déséquencement avant le compresseur. une notation formelle pour définir des profils La RFC 5225 définit les profils RoHCv2 proprement dits.2.2. l'efficacité. Le profil de TCP/IP qui est déjà supporté par RoHC à la couche PDCP apportent des améliorations et des simplifications pour RFC 3095.  à l'aide de RoHC-FN. La RFC 4997 définit RoHC-FN. 3. Cela permet à la couche PDCP de mettre en ordre paquets dans le cas de handover inter-eNodeB. La proposition est basée sur trois axes principaux: la robustesse.  RoHCv2 traite les extensions IP comme les autres protocoles compressés. le RoHCv2 a la même efficacité de compression. De plus. 3. RoHCv2 supporte le déséquencement de paquets entre compresseur et décompresseur qui n'est pas supporté pas RoHCv1. que les formats v1. décrits en grande partie RoHC et les méthodes de compression associées. comparé à RoHCv1 :  RoHCv2. tant en termes de taux de compression que de robustesse. et la facilité d'implémentation. Les simplifications sont utilisées pour développer le RoHCv2.  RoHCv2 utilise les mêmes formats de compression dans ses deux modes de fonctionnement : unidirectionnel et bidirectionnel. Cela implique que si la liste des extensions change. supporte le déséquencement de paquets entre compresseur et décompresseur.1 Motivation de proposition de RoHCv2 dans PDCP/LTE RoHCv2 est proposée par Ericsson[21]. au lieu d'utiliser une liste compressée.

Les bits de poids fort en 0x01 permettent de distinguer les profils v2 des profils v1 (0x00). En revanche. protégés par un CRC 7 bits. les deux versions peuvent être utilisées dans un même entête.B.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. et ne transmet donc pas dans ces paquets la taille de la charge utile.  La segmentation RoHC est incompatible avec les formats v2 lorsque RoHC ne peut garantir une transmission sans réordonnancement entre compresseur et décompresseur. en cas de besoin (contexte décompresseur abîmé). seul le format IR peut changer le profil associé à un contexte. Pour chaque profil. IP s'entend v4 ou v6 . 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 . IFI fields) .2. Un point commun important avec RoHCv1 : RoHCv2 compte sur les couches basses pour donner la longueur des paquets compressés. Cela est dû au fait que le protocole de segmentation n'utilise pas de numéro de séquence. 3.3 Les profils de RoHCv2 RoHCv2 définit (RFC 5225) les profils suivants :       0x0101 rtp (IP / UDP / RTP) 0x0102 udp (IP / UDP / non RTP) 0x0103 esp (IP / ESP) 0x0104 ip (IP / autre) 0x0107 udplite_rtp (IP / UDPlite / RTP) (n'est pas utilisée dans LTE) 0x0108 udplite (IP / UDPlite / non RTP) (n'est pas utilisée dans LTE) N. mais un simple bit pour distinguer le dernier segment. elle utilise un format co_repair qui transmet tous les champs dynamiques.

Dans release 6. 3. s'il existe un lien dans cette direction.4 Compresseur et décompresseur RoHCv2 utilise deux modes de fonctionnement :  unidirectionnel : les compresseur envoie les paquets avec une approche optimiste. RFC 4815 RFC 3095. RFC 4815 RFC 3095. ROHCv1 est supporté à partir de release 4.  bidirectionnel : le décompresseur peut. Les tests de la performance de RoHC sont ajoutées dans release 5. taux de déséquencement) en visant un compromis robustesse / efficacité. 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 supportés par LTE [17] Historiquement. Pour que cette approche fonctionne bien. Une fois que le compresseur reçoit du feedback pour un contexte donné. dans release 99. IFI 3. la couche de PDCP ne supporte que « IP compression header ». envoyer du feedback au compresseur. il faut ajuster le facteur de répétition aux caractéristiques du lien (taux d'erreurs bit. il passe définitivement en mode bidirectionnel pour ce contexte. RFC 4815 RFC 3843. Le trafic de feedback est constitué en majeure partie d'acquittements positifs et négatifs ainsi que d'options diverses.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. La synchronisation se fait par un numéro de séquence interne à RoHC (Master Sequence Number). Le feedback guide ainsi le compresseur en indiquant les formats compressés que le décompresseur est capable de traiter. Cela consiste à répéter chaque changement de champ transmis en espérant que le décompresseur recevra au moins un des changements.2.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. l'utilisation de RoHC dans les services MBMS 32 .

4 Support de RoHC au terminal Les UE qui supportent RoHC doivent supporter le profil non-compression.306 V8. VU DINH Dau Promotion 13. L’utilisation de la compression des entêtes peut être configurée par la couche supérieure. 0x0000.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE est prise en compte. mais n'est pas obligatoire. Les profils sont utilisés par l’UE. l'eNodeB envoie le message RRC de « UECapabilityEnquiry » qui force l'UE à transmette le message de « UECapacityInformation » qui contient les profils 33 . Le support de RoHC pour UE noncapable de IMS est optionnel [23].0)). Les profils autorisés sont disponibles dans le tableau 1. RRC contient des informations pour la configuration de PDCP (voir 3. PDCP n’utilise que RoHC pour compresser/décompresser des entêtes pour les paquets au plan utilisateur. ou par la réception du message de « Initial Context Setup Request » de MME.5). Les paramètres obligatoires de la configuration sont définis par RFC 4995. 0x0004. Il sauvegarde les informations afin d'établir les connexions radio avec l'UE. Le canal de « feedback » L’utilisation de segmentation LARGE_CIDS Oui PROFILES FEEDBACK_FOR MRRU Oui Non utilise Non utilise Tableau 2: Les paramètres sont définis par la couche supérieure de PDCP[17] 3. L'eNodeB peut recevoir des profils de RoHC que l'UE supportent par l'interrogation de l'UE.3. Paramètre MAX_CID Obligatoire Oui Description Le nombre maximal de CID (Contexte Identifier) est utilisé. IFI Dans release 8. il faut supporter les profile suivants de RoHC 0x0000. il faut que MAX_CID < « Maximum Number of RoHC Context Sessions » Elle est déduite du paramètre MAX_CID par la règle : If MAX_CID > 15 then LARGE_CIDS = TRUE else LARGE_CIDS = FALSE. Il faut réserver au moins un contexte pour les flux non-compressés. Pour interroger l'UE. Mais il y a des paramètres qui ne sont pas utilisés par PDCP de cette release. C’est-à-dire.[22] (annexe Support de RoHC dans l'UE (3GPP TS 36. tableau 1). C'est-à-dire les profils de ROHCv1 ont la priorité sur ceux de RoHCv2. 0x0002. Pour les UE qui sont capables de supporter le service de voix via IMS ('IMS capable UEs supporting voice'). Les profils supportés se composent des profils définis dans ROHCv1 et ROHCv2 (cf. 0x0001.

6. Pour plus de détails. IFI supportées par l'UE (annexe UE-EUTRA-Capability). la connexion de signalisation SRB qui sert à transmettre des messages RRC entre UE et E-UTRAN est établie par la procédure de « RRC Connextion 34 . Réseau 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: Procédure pour configurer et déclencher RoHC dans l'interface radio Premièrement.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. car la taille de message « UECapacityInformation » peut atteindre 510 octets. En résumé. Le MME va transmettre les informations au nouveau eNodeB pendant le handover. RoHC sera déactivé après la suppression des connexions DRB. afin de réduire l'overhead.5 Procédure de déclenchement de RoHC Cette partie décrit des étapes pour établir un service au plan de contrôle.2 de [25]). 3. Ci-dessous. le RoHC est déclenché dans la procédure d'établissement de connexion de données DRB (Data Radio Bearer). Après la réception de l'UE.3 de [24]. dans lesquels le déclenchement de RoHC est montré (source principale [24]).11. Le message de « UECapacityInformation » contient les autres informations de la capacité radio que l'UE supportent. Le MME sauvegarde les informations jusqu'à ce que l'UE lance la procédure d'attacher ou de détacher le réseau (chapitre 5. les étapes sont développées en détails. l'eNodeB va transmettre ce message à MME. Cette procédure est réalisé après l'établissement de connexion de signalisation SRB (Signalling Radio Bearer) et la procédure d'authentification. on peut consulter le chapitre 5.

Si les deux profils supportés ont en commun les 8 bits de pois faible. ou transmettre des messages de NAS (qui sont « piggybacked » dans les messages de RRC). mais n'indique pas des paramètres qui causent ce refus. Ensuite. L'UE envoie un message de « RRCConnectionRequest » vers eNodeB. Deuxièmement. le message de « RRCConnectionRelease » va supprimer toutes les connexions de 35 . la configuration de PDCP regroupe d'autre paramètre telle que la « Target Mode ». il lancera la procédure de re-établissement. la procédure de re-configuration sera lancée afin de contrôler le handover. L'idée principale est de réduire la complexité d'eNodeB. RoHCv2 est donc privilégié par rapport à RoHCv1. Il envoie un message de « RCC Connection Reestablisement » qui indique le refus par la configuration. de transmettre des messages NAS d'eNodeB vers l'UE. tous les messages d'authentification et de NAS transmis sont protégés (intégrité/chiffrement) par PDCP. Si l'UE ne peut pas appliquer une partie de la configuration dans le message de « RRCConnectionReconfiguration ». dans les releases précédentes de la releases 8. Ici. le nombre maximal de contexte utilisé (MAX_CID). L'entité PDCP est ré-établie selon la configuration précédente. Troisièmement. PDCP-config se compose des paramètres qui définissent l'utilisation/non-utilisation de RoHC. ce sont la procédure d'authentification et d'autres procédures de NAS qui ne sont pas précisées dans le cas de ce document. il n'y a pas de compression. Pour le dernier but. faire un appel. En conséquence. les profils supportés. De plus. L'entité PDCP sera établie.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. l'instance de RoHC est établie. il peut refuser la requête de l'UE par le message « RRCConnectionReject » qui contient le temps d'attente. L'UE répond à l'E-UTRAN par le message de « RRCConnectionReconfigurationComplete ". annexe PDCP-info ). IFI Etablisement ». ou par le handover. en observant la configuration courante de sécurité. qui décide le mode de RoHC (annexe PDCP-info ). La connexion SRB est établie lorsque l'UE reçoit un message de « RRCConnectionSetup » d'eNodeB. PDCP-config (qui s'appelle PDCP-info dans la release précédante de release 8. ou d'établir/modifier la connexion de données DRB au plan d'utilisateur. lorsque l'UE veut répondre un appel de paging. Cette procédure est déclenchée par la couche supérieure de l'UE. Enfin. Tous les entêtes de paquets IP au plan d'utilisateur sont compressés par RoHC. le message de « RRCConnectionReconfiguration » contient des informations pour configurer la sous-couche PDCP. celui dont la valeur est la plus élevée est sélectionné. Si l'E-TRAN est surchargé.

4. Il y une court interruption de services quand le réseaux exécute le handover.Cond SEQUENCE { ENUMERATED {len7bits. ms750. L'utilisation de RoHC causse une perte de la capacité de très peu d'importance. ms500. BOOLEAN.16383) SEQUENCE { BOOLEAN.. BOOLEAN. la mobilité causse 63% de perte. .. BOOLEAN. ms300. BOOLEAN -. 2. A la vitesse de 120 km/h. Cependant. Le handover cause un taux de perte de paquets. BOOLEAN.. et l'instance de RoHC sera alors libérée.Cond DEFAULT 15. S'il y a pas l'interface X2 entre l'eNodeB de source et de destination. SEQUENCE { BOOLEAN -. IFI SRB et de DRB établies si l'UE est inactif pendant longtemps ou passe à un autre eNodeB. Cela permet RoHC 36 . CHOICE { NULL. et le « typical RoHC » causse 3% de perte. ms100. ms150. BOOLEAN. Texte 1: PDCP-Config information element [24] 3. 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.Cond OPTIONAL. A destination.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. en comparaison avec l'effet de la mobilité. SEQUENCE { INTEGER (1. len12bits} OPTIONAL. L'entité de PDCP. -. le RoHC va re-construire le contexte.1). .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 }. BOOLEAN. } SEQUENCE { ENUMERATED { ms50. BOOLEAN. Le transfert de contexte de RoHC est un mécanisme de transmettre le contexte de RoHC de source à destination. infinity OPTIONAL..6 RoHC et handover Selon les études dans de la couche PDCP (cf. } }. -. on remarque LTE utilise « hard handover ».. ms1500.

il peut être compatible avec le multicast IP. SFN permet aux transmissions de plusieurs cellules d'être synchronisées pour 37 . Cet avantage est plus important sur l'interface radio quand nous avons un large nombre d'utilisateurs. Ces deux modes utilisent une transmission unidirectionnelle [27]. Mais. Ils diminuent le débit dans réseaux coeur et utilisent efficacement des ressources radio au réseau d’accès.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. Pour implémentation de transfert de contexte. 3.9% quand la fréquence de handover est haute. si le transfert de contexte est supporté.7.7 RoHC et MBMS L'avantage de Broadcast/Multicast par rapport à l'unicast est que les données sont transmises une fois sur un lien pour plusieurs destinataires. l'idée principale de LTE est de mettre moins complexité. Le mode multicast de 3GPP est différent du multicast IP d’IETF. Ils ont deux modes de fonctionnement : mode broadcast et multicast. Cependant. Depuis le release 7. et réduire la perte cassée par l'interruption de contexte. Cependant. Il ne bloque pas cette interface pour de multiples transmissions des mêmes données.1 MBMS Les services MBMS (Multimedia Broadcast/Multicast Service) permettent aux opérateurs 3G de fournir plus efficacement les applications média en concurrence avec DVBH. Le transfert de contexte est donc supportée par UMTS. On peut donc économiser la bande passante de 1. de ne pas envoyer des packets IR pour construire un nouveau contexte.5 quand la fréquence de handover est base [R2-072045]. Il prend en compte l’utilisation efficace des ressources radio. Le mode broadcast permet de diffuser des données média d’un nœud (un opérateur) vers multiples nœuds (multiples utilisateurs) dans la zone de services. 3. et modifier significativement le protocole RoHC. Le mode multicast ressemble au mode broadcast. De plus. il faut modifier l'interface X2 pour gérer les informations de contexte. à cela près qu'il propose des mécanismes d’abonnement (subscripstion) et rejoindre/disjoindre du groupe [28]. IFI de continuer fonctionner avec le contexte actuelle. l'implémentation de différentes fournisseurs de RoHC peut ne pas traiter le même lors qu'il y a le problème de déconséquence ou la perte de paquets. 3GPP apporte une nouvelle notion de SFN (Single Frequency Network). et de 0. LTE ne supporte pas le transfert. Dans le mode multicast. le réseau n'envoie des données qu'aux cellules où il y a des abonnées (un groupe).

lorsqu'il y a un utilisateur disjoint le groupe de multicast. 3GPP a décidé de compléter l'architecture de MBMS dans release 9 [29]. L'implémentation de RoHC de fournisseurs différents n'est pas identique. A la couche PDCP. Une entité de MCE (MBMS Coordination Entity) coordonne les allocations de ressources radio aux couches RLC/MAC de ces eNodeBs. Selon la release 9. la compression des entêtes est réalisée soit au RNC. RoHCv1 (RFC 3095) U-mode est utilisé [28]. La perte de feedback pousse le compresseur à passer à un bas niveau de compression. Le protocole SYNC et un serveur de MBMS-GW (e-MBMS Gateway) sont utilisés pour diffuser le même contenu vers les eNodeBs. BM-SC supporte la compression des entêtes dans le mode broadcast. Mais il y a une duplication de RoHC dans le réseaux du coeur (une au BM-SC. 38 . De plus.2 RoHC et Broatcast/Multicast Dans les releases précédentes. et l'autre à l'eNodeB). Le taux d'erreur de lien radio est plus élevé. c'est difficile ou impossible de traiter tous les feedback [30]. Mais le service de MBMS diffuse le contenu de point aux multiple utilisateurs. et soit aux les deux (la compression au RNC remplace la compression a BM-SC). car la difficulté de synchronisation de contenu. et de déséquencement de paquets [31]. C'est une solution plus simple. Cela diminue donc notablement l'efficacité de RoHC. Dans la suite. le RoHC doit passer à l'état IR. Les paquets d'envoyer aux d'autres utilisateurs ne sont pas compressés. L'autre solution qui ne met que la compression à la couche PDCP de l'eNodeB est plus complequée.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. soit BM-SC. IFI transmettre un même contenu.7. même au niveau de non-compression. 3. et ne traite pas la même façon dans le cas de perte. La performance de RoHC est meilleur si le canal de feedback est utilisé.

nous nous intéressons à la performance de RoHC en utilisant l'implémentation de JCP-Consult afin de trouver le taux de bande passante économisée. nous les passons au compresseur RoHC.2 Scénarios 4. [34]. selon le tableau 3.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. Dans cette partie. 39 . et [36]. et d'évaluer la robustesse de RoHC. [33]. comparateur et modèle de fautes. La simulation donne un rapport statistique sur le nombre de paquets erronés.1 Objectifs La performance de RoHC est évaluée de manière théorique par plusieurs travaux:[32]. Nous évaluons avec des flux audio et vidéo différentes.1 Modèle d'évaluation de performance Générateur de paquets IP Paquets décompressés comparateur Nombre de paquets erronés Nombre de paquets perdus Taille des entêtes compressés Compresseur RoHC Décompresseur RoHC Modèle des fautes Transmission des paquets compressés Illustration 13: Modèle d'évaluation de performance de RoHC Le modèle d'évaluation de performance se compose des blocs principaux suivants: générateur des paquets IP. sur le nombre de paquets perdus. Ensuite.2. Des fautes sont ajoutées aux paquets compressés afin de simuler des fautes dans le lien radio. 4. et sur la taille d'entêtes compressés. compresseur/décompresseur RoHC. IFI 4 Évaluation de la performance de ROHCv1 4. [35]. Nous utilisons « VLC player » pour générer des paquets multimédia en flux selon le protocole RTP.

il y a souvent un taux de perte s'il n'y pas d'interface X2 entre des eNodeBs.2 23 74 104 Packet size (bytes) 23 60 variable Variable VU DINH Dau Promotion 13. Le modèle de Gilbert simple est préféré car il y a moins de paramètres d'entrée (deux paramètres par rapport à 4 paramètres du modèle Gilber-Ellibott). Nous ne nous intéressons pas à un BER supérieur à 10−3 . Ces paquets sont considérés perdus.2 Choix de modèle de fautes Pour évaluer la performance de RoHC on peut simuler les erreurs de lien radio soit par perte de bits(BER) soit par perte de paquets. un taux de perte de plus de 10% n'est pas acceptable pour les application multimédia. La taille moyenne de segment correct est de 103 . dans le cas de handover de LTE. ce qui correspond à un taux de paquets erronés de 10−3 à 10−2 . En plus. En général. la taille moyenne de segment erroné est de 10 à 100 [38]. BER de 10−3 peut causer 28% paquets perdus (la probabilité d'avoir un bit d'erronés dans 40 octets de l'entêtes: 1−1−10−3 40∗8=28 % ).Mémoire de fin d'études Intégration 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. et varions la taille moyenne de segments erronés de 10 à 100 paquets. HARQ à la couche MAC. LTE utilise les mécanismes robustes tels que ARQ à la couche RLC. L'avantage du modèle bit perdu est qu'il peut montrer la robustesse de RoHC avec des erreurs imprévisibles. Le taux de blocs erronés à la couche supérieur de MAC est de 10−4 à 10−3 [37]. Donc le taux de perte est considéré dans le test de performance de RoHC. 40 . Or. 10 fps Frame size 176x144. On utilise souvent le modèle de Gilbert simple (2 states Markov) et Gilber-Ellibott pour présenter la distribution de fautes.2. La plupart de bits erronés sont corrigés. Nous utilisons le modèle d'aléatoire (Uniform) avec BER de 10−6 à 10−3 . En théorie. Nous fixons la taille moyenne de segments corrects à 1000 paquets. IFI Description 23 octes/packet 71 octes/packet Frame size 176x144. 15 fps Tableau 3: Les différents flux pour évaluer la performance de RoHC 4. la distribution d'erreurs dans le lien radio est le suivant : il y a des segments erronés où tous les paquets successifs sont erronés et des segments corrects où tous les paquets successifs sont correctes. Il n'y a que des bits erronés en rafale qui engendrent des paquets erronés. et FEC/Turbo coding à la couche PHY.

349705 0.349770 0. Le nombre de paquet perdus successivement en mode optimiste est très haut jusqu'à 700 paquets successifs.pcap hightrate3gp01.pcap amr23k01.000550 2 0. figure 14.122304 Input file amr23k01. délai.115505 4 0.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13.3 Pre-tests Illustration 14: Pre-tests. De plus.000250 2 0. et donne des statistiques de tests.553859 3223 0. J'ai étudié le fonctionnement de RoHC et des 41 . les passer vers RoHC.077056 0. Il permet de générer automatiquement des paquets. IFI 4.926639 5280 0.pcap amr23k01. le nombre maximal de paquets perdus est très haut dans O-mode JCP-Consult a développé un outil de test qui s'appelle « synthetic tester » pour que les ingénieurs puissent valider le fonctionnement de RoHC.120370 0.pcap Tableau 4: Des anomalies de performance de RoHC de JCP-Consult Lors des premiers tests j'ai remarqué des anomalies. de valider les sorties de test. perte de paquets. il est incapable de simuler : erreurs. c'est à dire en pire cas l'application doit attendre 700*20ms=14s pour recevoir le paquet suivant.pcap hightrate3gp01. et une performance est moyenne mauvaise.000150 2 0. L'outil gérère ses propes paquets et n'est pas capable de tester des paquets « live » qui sont capturés à partir du réseau.000500 2 0. et déséquencement dans lien radio.000200 2 0.346514 8 0.001544 1 0.003774 1 0. Number of RoHC Profile BER Packets mode 5830 O 5830 O 5830 O 5766 R 5766 R 5766 R 2 0.349770 0.000600 Bandwidt Average Burst packet h packet loss loss reduction 0.pcap hightrate3gp01.

et a droit.0 avec des flux différents Le taux de bande passante économisée présente l'efficacité et l'intérêt de RoHC. Chaque colonne qui a le couleur différent présente un type de flot.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. A fin de mon stage.4. On trouve que dans le même type de flot. les résultats de tests sont raisonnables et observent des résultats à manière théorique. 4. dans la même version de protocole IP. ce sont celles du paquets IPv6. le mois RoHC est intéressant. le plus « payload » est gros. A gauche. L'efficacité de RoHC 42 . nous choisissons le profil IP/UDP/RTP qui correspond aux applications multimédia telles que celles prévues dans le projet-NextTV4All. l'efficacité de compression de paquets IPv6 est plus élevée par rapport à celle de paquets IPv4. Le taux de différents flux est disponible dans la figure 15. IFI évaluations de performance de manière théorique pour comprendre les résultats. Les discussions avec les ingénieurs à JCP-Consult ont permis de corriger les bugs dans l'implémentation. 4.1 Taux de bande passante économisée Illustration 15: Bande passante économique dans U-mode et BER = 0.4 Résultats Dans les résultats suivants. Ces résultats ne correspondent pas à la théorie. ce sont des résultats de test avec des paquets IPv4. De plus.

Dans les figures 16 à 19. le taux de bande passante économisée diminue. lors que le BER est petite. Si le BER augmente. Les résultats dans le figure 15 ne prends pas en compte des erreurs dans le lien radio qui causent désynchronisation entre le compresseur et le décompresseur. 43 . le niveau de compression est donc constante. le mode optimiste est meilleur que le mode fiable parce que la liaison de retour est moins utilisée. Quand l'erreur est assez grand R-mode et O-mode doivent revenir aux niveaux inférieurs plus fréquemment. Le niveau de diminution est moins de 1%. Cependant. cependant le O-mode doit envoyer L paquets (niveau de confiance) avant de passer au niveau supérieur. La performance du mode bidirectionnel est meilleure que celle du mode unidirectionnel. nous évaluons l'efficacité de RoHC avec les taux de bits erronés différents (BER). Le RoHC bidirectionnel (O-mode et R-mode) est plus efficace par rapport à RoHC unidirectionnel lors que le BER est moins de 10−3.5 . il ne revient que aux niveaux inférieurs soit il reçoit des NACKs. le compresseur revient périodiquement aux niveaux inférieurs où il doit envoyer des paquets plus grands. Dans le mode unidirectionnel. O-mode économise le plus de bande passante.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. mais quand le BER est supérieur à 10−3 . dans le mode bidirectionnel. R-mode est le meilleur. Si le taux d'erronés est petite. le compresseur reçoit plus de paquets NACKs. Quand l’erreur est petite. IFI est proportionnelle à la taille des entêtes et inverse proportionnelle à la taille de payload. il est forcé à revenir au niveau inférieur. On trouve que si le BER augmente. il n'a pas de feedback. L'efficacité est donc diminuée. De plus. Mais le contexte de R-mode peut monter au niveau supérieur toute suite après recevoir un ACK.

Illustration 16: Taux de bande passante économisée VoIP AMR 12.2 kbps Illustration 17: Taux de bande passante économisée VoIP AMR 23 kbps Illustration 18: Taux de bande passante économisée Video H264 haute qualité Illustration 19: Taux de bande passante économisée Vidéo H264 moyenne qualité .

Le décompresseur doit atteindre le paquet initial envoyé périodiquement pour se re-synchroniser avec le compresseur. Quand le taux de perte est supérieur de 10−2. IFI 4. Nous avons réalisé des tests pour évaluer la gigue. Dans le mode bidirectionnel. un paquet perdu peut casser la cohérence entre les machines d'états au compresseur et au décompresseur. et à 80% pour le R-mode. le nombre est près égale à celui de la non-utilisation de RoHC. Les paquets perdus causent une gigue au niveau applicatif.3=0. Le R-mode présente son avantage par rapport au U-mode et au O-mode. La perte du R-mode est donc moins importante par rapport à O-mode.2 Taux de paquets perdus L'utilisation de RoHC permet de diminuer la taille d'entête. la perte qui est causé par l'entête erroné diminue.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13.005 . On trouve que le RoHC augmente un peu ce nombre. le compresseur ne passe au niveau supérieur que lorsqu'il reçoit un ACK. De plus. le décompresseur peut envoyer le NACK pour forcer le compresseur à envoyer un paquet qui a plus d'informations (IR-Dynamic ou IR paquet) pour se re-synchroniser. donc. en particulier. Dans ce mode d’opération seules les paquets avec un CRC de 7 ou 8 bits peuvent actualiser le contexte et être utilisés comme référence pour les décompressions subséquentes. Sur les courbes on remarque que l'utilisation de RoHC peut diminuer la perte de paquets. Les figures de 20 à 23 présentent le taux moyen de perte en fonction de BER. Mais dans RoHC.4. Le U-mode peut réduire à 50% de perte. Quand le taux de perte est petit. le U-mode. 45 . L’intégrité du contexte est donc mieux protégée[34]. 4.3 Nombre maximal de paquets perdus successifs La désynchronisation cause également une perte de paquets successifs. Le mode unidirectionnel n'a pas de feedback. Les figures de 24 à 27 présentent nombre maximal de paquets perdus successifs en fonction du taux de paquets perdus. Nous testons donc la robustesse du mécanisme de re-synchronisation de RoHC.4.

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 Vidéo H264 moyenne qualité .

2 kbps Illustration 25: Nombre maximal de paquets perdus successifs VoIP AMR 23 kbps Illustration 26: Nombre maximal de paquets perdus successifs Video H264 haute qualité Illustration 27: Nombre maximal de paquets perdus successifs Vidéo H264 moyenne qualité .Illustration 24: Nombre maximal de paquets perdus successifs VoIP AMR 12.

par rapport à celui de RoHC libre. Cette implémentation est sous licence de GPL et fut publiée au cours de mon stage. on remarque que la compression du RoHC libre est plus efficace. le RoHC libre ne peut compresser des paquets qu'en profil IP/UDP.4 Comparaison avec RoHC de Thales et Al. Thales Systèmes aéroportés. en Août 2009. figure 30. La perte moyenne de paquet du mode optimiste de JCP-Consult est meilleure. Nos tests sont donc basés sur le profil IP/UDP. dans le mode unidirectionnel ou optimiste. mais celle du mode unidirectionnel est inférieure par rapport celles de RoHC libre.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. A l'heure actuelle. IFI 4. Sur les courbes de la figure 28. 48 . Nous comparons la performance de RoHC de l'implémentation de JCP-Consult avec celle de l'implémentation de Centre national d’études spatiales(CNES). figure 29. Le niveau de paquets perdu successifs de JCP-Consult est meilleur. et Viveris Technologies.4.

2kbps Illustration 29: Taux de paquets perdus VoIP 12.2kbps Illustration 30: Nombre maximal de paquets perdus successifs VoIP 12.Illustration 28: Taux de bande passante économisée VoIP 12.2kbps .

nous avons présenté des innovations. à JCPConsult. En effet. Dans ce stage. Troisièmement. IFI 5 Conclusion et perspectives Le contexte de ce stage était le projet de recherche européen NextTV4All. nous avons présenté RoHC dans LTE. Une autre étude intéressante concerne l'impact de RoHC sur la qualité de service (QoS) des réseaux multimédia. 50 . RoHCv2 améliore la performance dans certains cas tel que le handover. On constate que RoHC peut réduire la perte de paquets pendant le handover. Le simulateur est capable de simuler des bits erronés. comme l'attente de synchronisation de RoHC. les profils de RoHCv1 et RoHCv2 sont supportés. et des pertes de paquets selon différentes distributions : Uniform. et Gilbert-Ellibott. nous avons effectué des tests sur l'implémentation de JCP-Consult de RoHCv1. en coopération avec TELECOM Bretagne. Deuxièmement.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. Premièrement. et un outil d'évaluation de la performance de RoHC. Cette comparaison a montré qu'il était encore possible d'optimiser l'implémentation de RoHCv1. MIMO et la simplification d'architecture basée sur le protocole IP facilitent des services multimédia comme IPTV. nous avons vu les problèmes de gigue générés par RoHC. On remarque que des évolutions dans la technique d'accès OFDMA. Les premiers résultats de test ont permit aux ingénieurs à JCP-Consult de corriger des bugs de type chaotique. Nous avons également réalisé une comparaison de la performance de RoHCv1 de JCP-Consult avec une implémentation compétitive. et peut réduire le taux de perte de paquets. Nous avons développé un simulateur de fautes au niveau du lien radio. RoHCv2 apporte également des simplifications d'implémentation. RoHC est très robuste contre des erreurs sur le lien radio. Je compte d'ailleurs rester en contact avec JCP-Consult et TELECOM Bretagne pour participer à ces études. Gilbert simple. RoHC introduit un phénomène de gigue au niveau applicatif. Une étude intéressante serait la comparaison avec RoHCv2. RoHC est supporté dans les services de broadcast/multicast (MBMS). mais d'autres effets sont également à prévoir. qui est en cours de développement au sein de l'entreprise JCP-Consult et TELECOM Bretagne. RoHC permet d'économiser environ 40% de bande passante pour les applications audio et environ 10% de bande passante pour les applications vidéo. et l'architecture de LTE. RoHC fonctionne au niveau de la sous-couche PDCP. Cependant. nous nous sommes intéressés à faire un état de l'art d'intégration de RoHC dans l'architecture de LTE.

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

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

Le groupe de travail RoHC à l’IETF a travaillé sur la conception d’un mécanisme de compression pour les messages de signalisation SIP et pour réduire la répétition des envois. Le résultat est SigComp (Signaling Compression) [39][40]. de projet NextTV4All. chargé de développer SigComp. 53 . dans les réseaux d’accès sans fil comme l’UMTS ou le LTE. IM. pour compresser les messages de signalisation SIP (qui sont de messages texte donc sont compressés comme des données). SIGCOMP est contribué par Ana Carolina MINABURO. la présence et des services multimédia comme la vidéo conférence ou la TV dans le réseau 3G exige une importante bande passante. L’utilisation de SigComp permet d’augmenter le débit utile et réduire le délai dans la transmission de données.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. Architecture de SIGCOMP SigComp est un mécanisme de compression de données qui travaille entre la couche applicative et la couche transport (cf. TELECOM Bretagne. le protocole SIP (Session Initiation Protocol. VoD. dans « l'état de l'art de l'utilisation des entêtes dans l'architecture du LTE ».. A partir de la Release 5 de l’UMTS. La compression de données SigComp [39][40] permet de réduire l’augmentation de débit générée par la signalisation SIP lors de la création d’une session pour les services tels que IP-TV. RFC IETF 3261) est choisi pour envoyer la signalisation des communications de voix et autres sessions multimédia. Présence. SIGCOMP Introduction Le développement des services interactifs comme l’IM (Instant Messaging). La compression de SIP réduit l’utilisation de ressources radio et permet d’allouer un plus grand nombre d’utilisateurs. IFI Annexe A SIGCOMP qui fonctionne entre la couche d'application et la couche de transport peut réduire jusqu'à 93. La Compression et Décompression SigComp sont faites par les entités paires qui envoient à travers des régulateurs de paquets les messages vers la couche applicative et la couche transport. Le groupe de travail RoHC à l’IETF.8% de taille des messages SIP. figure 31). Mais SIP est un protocole basé sur le texte (comme http) et il génère des paquets entre 200 et 1500 octets qui sont envoyés plusieurs fois ce qui est inefficace et augmente le délai pour l’établissement d’un appel. Ces messages SIP ont une taille qui peut atteindre 500kb et ils sont répétés plusieurs fois pour assurer la fiabilité de la session. SigComp doit donc tenir compte du fait que le terminal doit appliquer un grand nombre d’algorithmes déjà déployés dans un réseau. a considéré que les terminaux de téléphonie cellulaire n’ont pas beaucoup de ressource mémoire ni un processeur assez puissante pour traiter des algorithmes très complexes [40][41]. etc. SigComp négocie la quantité de mémoire disponible pour la compression et n’utilise qu’un nombre réduit d’opérations pour augmenter le temps de traitement.

Le compresseur doit s’assurer que le décompresseur a toute l’information nécessaire pour faire la décompression. le protocole SigComp utilise des régulateurs de paquets pour envoyer et recevoir les messages. Les algorithmes de compression de texte peuvent être basés sur : •Un Dictionnaire : LZ. LZW.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. Le gestionnaire d’états stocke les pseudo codes binaires et les dictionnaires. Le compresseur peut utiliser une algorithme connu (Deflate. Si le dictionnaire est Statique. L’Architecture SigComp a trois éléments principaux (cf. le régulateur de paquets envoie le message compressé avec la mise à jour du pseudo code binaire pour l’algorithme de décompression qui sera utilisé par la machine virtuelle UDVM (Universal Decompressor Virtual Machine) du décompresseur. il peut être contacté par un décompresseur pour connaître cette information. De plus. Le compresseur réduit les messages avec l’algorithme choisi et ajoute le pseudo code binaire si nécessaire. il peut être chargé hors ligne dans le gestionnaire pour 54 . Pendant un handover le nouveau décompresseur doit recevoir l’information nécessaire pour décompresser les messages. pour SigComp le pseudo code permet un usage multi-plateformes des logiciels développés qui sont exploitables par la machine virtuelle du décompresseur) nécessaire pour décompresser les données n’est pas envoyé au décompresseur. Burrow-Wheeler (BWT). TCCP. Dynamique ou personnalisé. Les algorithmes plus connus feront une meilleure performance puisque le pseudo-code binaire (le pseudo code est le produit d’un compilateur pour traduire le code source en langage machine. TCCB •Une Transformée : Huffman. EPIC •Un Modèle : Prédiction avec une corrélation partielle (PPM) Le choix de l’algorithme reste un paramètre sélectionné manuellement pour SigComp. codes arithmétiques. figure 32) : Le Compresseur (C). etc) ou un algorithme spécifique (EPIC. le premier message donne l’information de l’état de l’algorithme utilisé. IFI Illustration 31: Pile protocolaire avec la compression. Chaque message est compressé indépendamment mais les messages d’un flux donné sont compressés avec le même algorithme. Sa pleine efficacité est atteinte après un nombre de messages compressés. etc). Les messages compressés sont envoyés avec une combinaison des instructions d’UDVM qui permettent sa décompression. le Décompresseur (D) et le gestionnaire d’état (State Handler). Le dictionnaire peut être : Statique. LZ77.

Le gestionnaire de messages envoie et reçoit les messages entre SigComp et la couche applicative. elle est flexible et travaille avec le pseudo code envoyé par le Compresseur. Le dictionnaire statique est une collection de caractères bien connus qui sont utilisés dans la plupart de messages SIP/SDP. UDVM n’ajoute pas un délai supplémentaire au traitement des données et n’utilise pas plus de mémoire que si on définissait un seul algorithme de décompression. Instruction DECOMPRESSION­ FAILURE      AND                        OR                         NOT                        LSHIFT                     RSHIFT                     ADD                        Valeur  pseudo code 0 1 2 3 4 5 6 Instruction SUBTRACT                   MULTIPLY                   DIVIDE                     REMAINDER                  SORT­ASCENDING  SORT­DESCENDING  SHA­1                      Valeur  pseudo code 7 8 9 10 11 12 13 55 . de Gestion de Mémoire. IFI incrémenter la performance ou il peut être envoyer avec le message compressé. elle s’appelle UDVM (Universal Decompressor Virtual Machine) et elle est le noyau de SigComp. La taille du pseudo code varie entre 200 et 300 octets. Les messages SigComp sont la combinaison de données compressées avec les instructions d’UDVM. 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 décompresseur utilise une machine virtuelle similaire à une machine virtuelle Java. Un avantage de cette solution est l’interopérabilité entre différentes implémentations. UDVM est optimisée pour supporter différents algorithmes de compression. UDVM envoie les données décompressées comme un flux de données.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. de Gestion de Programme et de Entrée/Sortie (I/O). tableau 5) pour manipuler les différents algorithmes de compression : Mathématiques. UDVM a un ensemble de 36 instructions (cf.

IFI Valeur  pseudo code 15 MULTILOAD                  56 .Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE Instruction LOAD                       Valeur  pseudo code 14 Instruction VU DINH Dau Promotion 13.

figure 33) a une taille par dfault de 2kilo-octets. et l’autre avec le gestionnaire d’état qui lui permet de demander la création d’un état et d’accéder a un état déjà créé. Les premiers 64 octets sont utilisés pour les variables de décompression comme : la taille de mémoire. 57 . ensuite entre 256 octets pour le(s) dictionnaire(s) qui sont les différents pseudo codes des algorithmes de compression et le reste il peut stocker des paquets (figure 33) précédents ou les dictionnaires dynamiques ou personnalisés.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE Instruction PUSH                       POP                        COPY                       COPY­LITERAL               COPY­OFFSET                MEMSET                     JUMP                       COMPARE                    CALL                       RETURN                     SWITCH                     Valeur  pseudo code 16 17 18 19 20 21 22 23 24 25 26 Instruction CRC                        VU DINH Dau Promotion 13. l’ordre d’entrée de bits. Ensuite il utilise 64 octets pour les variables de la compression comme : la localisation des états. 1kilo. une avec le régulateur de paquets pour envoyer/recevoir les données compressés/décompressés. Avec des implémentations [42][43][44] on remarque que pour un usage minimaliste. la version. La mémoire entre 64 octets et 512 octets est sauvegardée après la décompression pour améliorer l’indice de compression. UDVM est divisé en deux parties : la mémoire et le traitement du pseudo code.. IFI Valeur  pseudo code 27 28 29 30 31 32 33 34 35 INPUT­BYTES                INPUT­BITS                 INPUT­HUFFMAN  STATE­ACCESS               STATE­CREATE               STATE­FREE                 OUTPUT                     END­MESSAGE                Tableau 5: Instructions d’UDVM et les valeurs de pseudo code.octet est possible pour des algorithmes connus tandis que pour avoir une performance optimale entre 4 à 8 k octets sont nécessaires pour sauvegarder toute l’information. les cycles. Il a deux interfaces pour communiquer dans l’architecture. Après le pseudo code UDVM occupe 128 octets qui sont les instructions UDVM. la longueur de l’état et le paquet à décompresser. La mémoire dans UDVM (cf. L’information des acquittements est envoyée au gestionnaire d’état si le niveau transport est bidirectionnel.

une série de paramètres est utilisée pour modifier les comportements de la compression quand les capacités des paires sont très différentes : •Taille de mémoire de décompression (Decompression_memory_size) : donne la taille de mémoire disponible pour la décompression de messages SigComp. •Etat de la taille de mémoire (State_memory_size) : Donne le nombre d’octets pour la création d’un état. 0                  7 0                  7 1 1 1 1 1 T len 1 1 1 1 1 T 0 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 paramètres SigComp Afin d’avoir une complète interaction entre les différentes implémentations. figure 34) sont différenciés par le premier octet. Les deux types des messages (cf. Les messages SigComp doivent indiquer l’algorithme de compression utilisé et toute l’information nécessaire pour la décompression. 58 . Cette information peut faire partie du message SigComp ou elle peut être connue comme dans les états d’items disponibles dans la mémoire.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. IFI Illustration 33: La mémoire d’UDVM Format de Message SIGCOMP. Zero si la configuration est sans état.

Algorithme de  Compression Pourcentage de  Compression Ratio R= Taille sans compression Taille compressée Simple LZ77 Adaptive LZ (compress) LZW LZSS DEFLATE (gzip) 55.6816 3. IFI •Cycle par bit (Cycles_per_bit) : Le nombre de cycles disponibles pour décompresser chaque bit dans le message SigComp.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13.1290 Tableau 6: Ratio de Compression pour les messages SIP [45] La figure 35 montre les différents messages SIP compressés par les différents algorithmes et la taille qui est obtenue.8% de réduction de taille des messages SIP. Un autre paramètre est utilisé par les instructions UDVM. Performances de SigComp Telecom Bretagne a testé [45] le mécanisme de compression SigComp sur une communication SIP entre deux ordinateurs.8 2. Cela signifie qu’il est possible d’envoyer 16 fois plus de messages. pour connaître le ratio de compression des messages SIP avec les algorithmes plus connus comme : LZ77.47 93. LZW. •Version de SigComp (SigComp_version) : Indique si seulement la version de base est disponible ou s’il y a une mise à jour dans l’implémentation •Les états des items disponibles localement (Locally Available State Items) : L’état des items est une information qui est utilisé entre deux messages SigComp pour la décompression ou pour le dictionnaire.7045 16. d’où une réduction de la bande passante et une optimisation de son utilisation ainsi qu’une réduction du délai pour l’établissement d’une session dans la téléphonie 3G. 59 .99 82.4470 5.64 70.2 78. tableau 6) et on a trouvé que la compression SIGCOMP peut donner jusqu’à 93. Ils sont créés quand un message a été décompressé avec succès.2321 4. LZSS ou Deflate (cf.

60 . IFI Illustration 35: Compression SigComp.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13.

There is thus one set of parameters for each channel.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. RFC 4815 RFC 3095.5. 5. In this version of the specification the support of the following profiles is described: Table 5. and one for the uplink.323 version 8. i. The detailed definition of the RoHC channel is specified as part of the RoHC framework in RFC 4995 [7]. defined for the RoHC framework.0) 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]. This includes how to multiplex different flows (header compressed or not) over the RoHC channel.2 Configuration of header compression PDCP entities associated with DRBs can be configured by upper layers [3] to use header compression. these parameters define the RoHC channel.5. as defined below: 61 .5. there is one channel for the downlink.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. Each profile is specific to the particular network layer.5. These parameters are categorized in two different groups. as well as how to associate a specific IP flow with a specific context state during initialization of the compression algorithm for that flow.1.e. transport layer or upper layer protocol combination e. TCP/IP and RTP/UDP/IP. The RoHC channel is a unidirectional channel. RFC 4815 RFC 4996 RFC 5225 RFC 5225 RFC 5225 RFC 5225 Usage: Reference 5. RFC 4815 RFC 3843.1 Supported header compression protocols and profiles The header compression protocol is based on the Robust Header Compression (RoHC) framework [7]. and the same values shall be used for both channels belonging to the same PDCP.5. 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.g. There are multiple header compression algorithms. RFC 4815 RFC 3095.5 Header Compression and Decompression 5. IFI Annexe B Support de RoHC dans la couche de PDCP(3GPP TS 36. called profiles.

MRRU (N/A): RoHC segmentation is not used. i. VU DINH Dau Promotion 13.e.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE M: Mandatory and configured by upper layers. 5.3. The parameter MAX_CID is configured by upper layers (maxCID [3]).3 RRC connection establishment 5. The usage and definition of the parameters shall be as specified below. each associated with one PDCP SDU standalone packets not associated with a PDCP SDU. 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. The list of supported profiles is described in section 5.5. MAX_CID (M): This is the maximum CID value that can be used.1.5. 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. The parameter PROFILES is configured by upper layers (profiles [3]). Interspersed RoHC feedback packets are not associated with a PDCP SDU.4 Header compression The header compression protocol generates two types of output packets: compressed packets.3. Les procédures de la couche de RRC (3GPP TS 136 331 V8. PROFILES (M): Profiles are used to define which profiles are allowed to be used by the UE.3.5. One CID value shall always be reserved for uncompressed flows. Feedback received on one RoHC channel for this PDCP shall always refer to the RoHC channel in the opposite direction for this same PDCP.1 General 62 .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.0) 5. 5. IFI N/A: Not used in this specification. LARGE_CIDS: This value is not configured by upper layers. interspersed RoHC feedback packets A compressed packet is associated with the same PDCP SN and COUNT value as the related PDCP SDU.6.5. They are not associated with a PDCP SN and are not ciphered.

3.3.5. successful 63 .3.5.3.3.1-1: RRC connection establishment. successful UE EUTRAN RRCConnectionRequest RRCConnectionReject Figure 5.3.1-1: RRC connection reconfiguration.1-2: RRC connection establishment. E-UTRAN applies the procedure as follows: – to establish SRB1 only. network reject The purpose of this procedure is to establish an RRC connection.3. RRC connection establishment involves SRB1 establishment.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE UE VU DINH Dau Promotion 13. The procedure is also used to transfer the initial NAS dedicated information/ message from the UE to E-UTRAN.1 General UE EUTRAN RRCConnectionReconfiguration RRCConnectionReconfigurationComplete Figure 5.5 RRC connection reconfiguration 5. 5. IFI EUTRAN RRCConnectionRequest RRCConnectionSetup RRCConnectionSetupComplete Figure 5.

e.g. A UE in RRC_CONNECTED. successful UE EUTRAN RRCConnectionReestablishmentRequest RRCConnectionReestablishmentReject Figure 5. As part of the procedure. If AS security has not been activated. The connection re-establishment succeeds only if the concerned cell is prepared i. the UE does not 64 .3.7. for which security has been activated.1-1: RRC connection re-establishment. In case EUTRAN accepts the re-establishment.1 General UE EUTRAN RRCConnectionReestablishmentRequest RRCConnectionReestablishment RRCConnectionReestablishmentComplete Figure 5. to setup/ modify/ release measurements. to establish/ modify/ release RBs. failure The purpose of this procedure is to modify an RRC connection. which involves the resumption of SRB1 operation and the re-activation of security.7 RRC connection re-establishment 5.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE UE VU DINH Dau Promotion 13.3. 5. SRB1 operation resumes while the operation of other radio bearers remains suspended.3. may initiate the procedure in order to continue the RRC connection.1-2: RRC connection reconfiguration.3. failure The purpose of this procedure is to re-establish the RRC connection.5.7. has a valid UE context. to perform handover.1-2: RRC connection re-establishment. IFI EUTRAN RRCConnectionReconfiguration RRC connection re-establishment Figure 5. e.3.7. NAS dedicated information may be transferred from E-UTRAN to the UE.

8. ms1500. SEQUENCE { BOOLEAN OPTIONAL. ms100.3.Cond 65 . 5.1-1: RRC connection release.5. E-UTRAN applies the procedure as follows: to reconfigure SRB1 and to resume data transfer only for this RB. infinity OPTIONAL.3.ASN1START PDCP-Config ::= discardTimer } Setup rlc-AM statusReportRequired } Rlc-AM rlc-UM pdcp-SN-Size } Rlc-UM SEQUENCE { ENUMERATED { ms50.3.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.8 RRC connection release 5. IFI 5. SEQUENCE { ENUMERATED {len7bits.Cond -..3.5.5. len12bits} OPTIONAL.3.. PDCP-config (3GPP TS 136 331 V8. PDCP-Config information element -.. successful The purpose of this procedure is to release the RRC connection.Cond -. -.3. VU DINH Dau Promotion 13. which includes the release of the established radio bearers as well as all radio resources.3. ms500. ms750.8.5 (inter-RAT mobility from EUTRA failure): 3> set the reestablishmentCause to the value ‘handoverFailure’.1 General UE EUTRAN RRCConnectionRelease Figure 5. – to re-activate AS security without changing algorithms.6 (intra-LTE handover failure) or 5. .4. 2> else: 3> set the reestablishmentCause to the value ‘otherFailure’. 2> else if the re-establishment procedure was initiated due to handover failure as specified in 5.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE initiate the procedure but instead moves to RRC_IDLE directly.7. ms300.5 (the UE is unable to comply with the reconfiguration): 3> set the reestablishmentCause to the value ‘reconfigurationFailure’.0) The IE PDCP-Config is used to set the configurable PDCP parameters for data radio bearers. ms150.

Profile 0x0000 shall always be supported when the use of RoHC is configured. Value in milliseconds. Otherwise the field is not present. 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 . Otherwise the field is not present. BOOLEAN.3. value 'true' indicates that the profile is supported. 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. Value len7bits means that the 7-bit PDCP SN format is used and len12bits means that the 12-bit PDCP SN format is used. need ON.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE headerCompression notUsed rohc maxCID profiles profile0x0001 profile0x0002 profile0x0003 profile0x0004 profile0x0006 profile0x0101 profile0x0102 profile0x0103 profile0x0104 }.4. ms100 means 100 ms and so on..323 [8]. BOOLEAN.323 [8].. .e. The field is mandatory present upon setup of a PDCP entity for a radio bearer configured with RLC UM.. as specified in TS 36.ASN1STOP CHOICE { NULL. i. PDCP-Config field descriptions discardTimer Indicates the discard timer value specified in TS 36.323 [8] are supported. . } -. The field indicates which of the RoHC profiles specified in TS 36.323 [8]. in case of reconfiguration of a PDCP entity at handover for a radio bearer configured with RLC AM. 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. } }. BOOLEAN. Otherwise the field is not present. SEQUENCE { INTEGER (1.331) 10. pdcp-SN-Size Indicates the PDCP Sequence Number length in bits. maxCID Indicates the value of the MAX_CID parameter as specified in TS 36.323 [8]. BOOLEAN. The field is mandatory present upon setup of a PDCP entity for a radio bearer configured with RLC AM. BOOLEAN. PDCP-info (3GPP TS 25.16383) SEQUENCE { BOOLEAN. profiles The profiles used by both compressor and decompressor in both UE and E-UTRAN. The field is optional. IFI DEFAULT 15. BOOLEAN VU DINH Dau Promotion 13.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.. If support of two RoHC profile identifiers with the same 8 LSB’s is signalled. BOOLEAN. Value ms50 means 50 ms. BOOLEAN..

The largest header size in octets that may be compressed..65535) >>>F_MAX_TIME MD Integer (1. Default value is "reordering not expected". Maximum CID value for TCP connections. Default value is 15. absent) >CHOICE algorithm type >>RFC 2507 MP >>>F_MAX_PERIOD MD Integer (1.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE Information Element/Group name Need Lossless Multi Type and reference n255.65535) >>>TCP_SPACE MD Integer (3.. 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.. The handling of sequence number when the Max PDCP SN window size is 255 is specified in [23].255) >>>MAX_HEADER MD Integer (60. Maximum CID value for non-TCP connections. sn65535) VU DINH Dau Promotion 13.255) >>>NON_TCP_SPACE MD Integer (3.65535) >>>EXPECT_REORDERING MD Enumerated (reordering not expected.. 67 . Default value is 168. IFI Semantics description sequence number window size. Default value is 15. Whether the algorithm shall reorder PDCP SDUs or not. Default value is 5. Compressed headers may not be sent more than F_MAX_TIME seconds after sending last full header. Default value is 256. 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 15.65535) whether reverse decompression should be used or not and the maximum number of packets that can be reverse decompressed by the UE decompressor. 3) 1 = 0x0001. Highest context ID 16383) number to be used by the UE decompressor. the IE "In-sequence delivery " is TRUE and the IE "SDU Discard Mode" is "No discard" 68 . >>>>Max_CID MD Integer (1.. Default value is 0 (reverse decompression shall not be used). 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".. Profile 0 shall always be supported. >>>Downlink OP Indicates the necessary information elements for Downlink. >>>>Reverse_Decompression_ MD Integer Determines Depth (0. Default value is 15. the UE behaviour is unspecified. IFI 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. Note 1: If several occurrences of the same algorithm type are included in the same IE 'header compression information'. 3 = 0x0003 (see [52]) >>>Uplink OP Indicates the necessary information elements for Uplink.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE Information Element/Group name >>RFC 3095 Need Multi Type and reference VU DINH Dau Promotion 13. 2 = 0x0002.. >>>>Profile instance MP Integer(1. Highest context ID 16383) number to be used by the UE compressor. >>>>Max_CID MD Integer (1..

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). which the sender of the message is expecting next to be received.3. 0x0002 (RoHC UDP) and 0x0003 (RoHC ESP) (see [52]).0) 4. used by inband RoHC profile negotiation.65 535) Semantics description The PDCP sequence number. 0x0002. IFI and not needed otherwise. for this PDCP entity for both UL and DL equal to the list of RoHC profiles received in the IE "PDCP info". Information Element/Group name Receive PDCP sequence number 1> set the PROFILES parameter.. 0x0000 RoHC uncompressed (RFC 4995) 0x0001 RoHC RTP (RFC 3095.3. 10.2a PDCP RoHC target mode Need MP Multi Type and Reference Enumerated (O-mode.1 Supported RoHC profiles This parameter defines which RoHC profiles from the list below are supported by the UE. otherwise it is not needed. 0x0001.4. This IE is mandatory present if the IE "Support for lossless SRNS relocation or for lossless RLC PDU size change" Is TRUE. RFC 4815) 0x0002 RoHC UDP (RFC 3095.4.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE Lossless VU DINH Dau Promotion 13. Version REL-5 Information Element/Group name Target Mode 10.3. RFC 4815) 0x0004 RoHC IP (RFC 3843.1. 69 .3 PDCP SN info Need MP Multi Type and Reference Integer(0.1 PDCP Parameters 4. 0x0001 (RoHC RTP). RFC 4815) 0x0003 RoHC ESP (RFC 3095. Support de RoHC dans l'UE (3GPP TS 36. Rmode) Semantics description The UE shall only transit to the signalled mode for operation of RoHC as decribed in [36].306 V8.3. A UE complying to this version of the protocol shall support RoHC profiles 0x0000 (RoHC uncompressed). 'IMS capable UEs supporting voice' shall support RoHC profiles 0x0000.3.

INTEGER (1. to the network. . excluding context sessions that leave all headers uncompressed.1. 4. cs256. RF-Parameters. BOOLEAN. spare2. IFI 0x0004. PhyLayerParameters. nonCriticalExtension } AccessStratumRelease ::= SEQUENCE { AccessStratumRelease.. BOOLEAN.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13. spare5.306 [5].3... UE-EUTRA-Capability The IE UE-EUTRA-Capability is used to convey the E-UTRA UE Radio Access Capability Parameters. BOOLEAN. cs512.2 Maximum number of RoHC context sessions This parameter defines the maximum number of header compression context sessions supported by the UE. OPTIONAL. OPTIONAL.. spare2. spare1. BOOLEAN.5). BOOLEAN ENUMERATED { cs2. BOOLEAN.} SEQUENCE { SEQUENCE { BOOLEAN. OPTIONAL. cs128. The IE UE-EUTRA-Capability is transferred in E-UTRA or in another RAT. cs4. cs1024. cs16384. cs12. OPTIONAL. PDCP-Parameters. BOOLEAN. spare3. cs32. cs8. maxNumberROHC-ContextSessions cs16. cs24.maxBands)) OF SupportedBandEUTRA 70 . spare4. OPTIONAL OPTIONAL ENUMERATED { rel8. UE-EUTRA-Capability information element -. cs64.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 }. spare6. OPTIONAL.. BOOLEAN. 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.. see TS 36. MeasParameters. spare7. BOOLEAN SEQUENCE { SupportedBandListEUTRA SEQUENCE (SIZE (1. . cs48. } PhyLayerParameters ::= ue-TxAntennaSelectionSupported ue-SpecificRefSigsSupported } RF-Parameters ::= supportedBandListEUTRA } SupportedBandListEUTRA ::= SEQUENCE { BOOLEAN. cs16. spare1} DEFAULT PDCP-Parameters ::= supportedROHC-Profiles profile0x0001 profile0x0002 profile0x0003 profile0x0004 profile0x0006 profile0x0101 profile0x0102 profile0x0103 profile0x0104 }.

l. bandVI. b. . e.. bandIV. f. p.. n. j. b.maxBands)) OF SupportedBandUTRA-TDD384 ENUMERATED { a. h. i. bandXI. bandVII. i. c. BOOLEAN SEQUENCE { BandListEUTRA VU DINH Dau Promotion 13.maxBands)) OF InterFreqBandInfo SEQUENCE { BOOLEAN SEQUENCE (SIZE (1. h. e. f.} SEQUENCE { SupportedBandListUTRA-TDD128 SEQUENCE (SIZE (1. bandXIII. o. g. bandX. k.. bandIX. n. m. g. bandXII. bandXV. e. IFI SEQUENCE (SIZE (1. j.maxBands)) OF SupportedBandUTRA-TDD768 ENUMERATED { a. k. j. bandXIV.} SEQUENCE { SupportedBandListGERAN. m.. bandVIII... c.. p. o. d. InterRAT-BandList OPTIONAL SEQUENCE (SIZE (1.. bandIII. . l.. h. d..} SEQUENCE { SupportedBandListUTRA-TDD384 SEQUENCE (SIZE (1.. f.64).. p. b.} SEQUENCE { SupportedBandListUTRA-TDD768 SEQUENCE (SIZE (1.maxBands)) OF SupportedBandUTRA-FDD ENUMERATED { bandI. k.maxBands)) OF InterRAT-BandInfo SEQUENCE { BOOLEAN SEQUENCE { SupportedBandListUTRA-FDD SEQUENCE (SIZE (1. . d. o. . bandII. bandXVI. IRAT-ParametersUTRA-TDD128 ::= supportedBandListUTRA-TDD128 } SupportedBandListUTRA-TDD128 ::= SupportedBandUTRA-TDD128 ::= IRAT-ParametersUTRA-TDD384 ::= supportedBandListUTRA-TDD384 } SupportedBandListUTRA-TDD384 ::= SupportedBandUTRA-TDD384 ::= IRAT-ParametersUTRA-TDD768 ::= supportedBandListUTRA-TDD768 } SupportedBandListUTRA-TDD768 ::= SupportedBandUTRA-TDD768 ::= IRAT-ParametersGERAN ::= supportedBandListGERAN 71 . i.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE 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. bandV.maxBands)) OF SupportedBandUTRA-TDD128 ENUMERATED { a. l. n. g. c...maxBands)) OF BandInfoEUTRA SEQUENCE { InterFreqBandList... m.

. gsm900E. gsm1900. .ASN1STOP 72 . IFI SEQUENCE (SIZE (1. ENUMERATED {single. spare5. ENUMERATED {single.} SEQUENCE { SupportedBandListHRPD. gsm480. spare3. ENUMERATED {single.maxBands)) OF SupportedBandGERAN ENUMERATED { gsm450.maxCDMA-BandClass)) OF SEQUENCE { SupportedBandList1XRTT.. gsm1800. gsm900P. gsm900R.. dual} SEQUENCE (SIZE (1. spare1.Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE interRAT-PS-HO-ToGERAN } SupportedBandListGERAN ::= SupportedBandGERAN ::= BOOLEAN VU DINH Dau Promotion 13. dual}. dual}. gsm810. gsm750. gsm710. 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 -.. ENUMERATED {single. spare2. gsm850. spare4..

You're Reading a Free Preview

Télécharger
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->