Professional Documents
Culture Documents
Utilisation de la compression des enttes dans les rseaux cellulaires de type 4G (LTE/SAE)
Ralis par : VU DINH Dau Sous la direction de : Loutfi NUAYMI TELECOM Bretagne Xavier LE BOURDON JCP-Consult Promotion 13, IFI
4.4.1 Taux de bande passante conomise......................................................................43 4.4.2 Taux de paquets perdus..........................................................................................46 4.4.3 Nombre maximal de paquets perdus successifs......................................................46 4.4.4 Comparaison avec RoHC de Thales et Al..............................................................49 5 Conclusion et perspectives.....................................................................................................51 Bibliographie.............................................................................................................................52 Annexe A..................................................................................................................................54 Annexe B...................................................................................................................................61
Remerciements
Je tiens tout dabord remercier Loutfi NUYAMI qui a suivi mon travail thorique concernant l'architecture des rseaux cellulaires, et la recherche dans la grande quantit de documents de 3GPP. Il m'a donn galement des conseils sur la mthodologie de recherche. Je souhaite galement remercier Xavier LE BOURDON. Il a t la fois mon ami qui m'a aid l'adaptation la vie en France et mon superviseur qui m'a donn des conseils sur le travail pratique concernant les tests de performance de RoHC. Je voudrais aussi remercier Ana Carolina MINABURO qui a slectionn ma candidature de stage, et donn frquemment des commentaires forts utiles sur mon travail. Je voudrais remercier Eric Poilvet qui m'a donn des conseils sur l'architecture de UMTS. Je voudrais remercier Michel BADET qui a travaill en coopration avec moi pour localiser et corriger des anomalies de performance de RoHCv1. Je voudrais galement remercier Thomas Lefort qui m'a aid sur la partie concernant RoHCv2. Je tiens remercier Jean-Marie BONNIN et Stphane ROLLAND qui m'ont donn des conseils sur le plan de travail. Je voudrais remercier Jean-Charles Point qui a financ pour mon stage, et donn un environnement professionnel favorable mon travail. Enfin, je voudrais remercier mon professeur l'Institut de la Francophonie d'Informatique (IFI) qui n'ont donn des cours de rseaux afin d'avoir les connaissances de base pour raliser ce stage.
Rsum
LTE (Long Term Evolution) est la dernire volution d'une srie de technologies cellulaires sans-fil GSM/UMTS/HSPA, en comptition pour tre la norme de la quatrime gnration de rseau mobile (4G). Les innovations au niveau de l'interface radio et de l'architecture plate et tout-IP permettent de rduire le dlai d'accs et d'enrichir des services multimdia comme les services de tlvision sur IP haut dbit. La compression d'enttes RoHC (Robust Header Compression) est une technologie prsente dans LTE l'interface radio o la bande passante est limite et coteuse. RoHC permet de rduire la taille des paquets IP des applications multimdia dans lesquels la taille de payload est souvent petite par rapport la taille d'entte. La deuxime version de RoHC (RoHCv2) simplifie l'implmentation de RoHC et amliore la performance dans le cas de handover. Elle est prise en compte dans l'architecture de LTE. Dans ce document, nous analysons l'architecture de LTE afin de connatre l'intgration de RoHC dans ce systme. Nos tudes montrent que RoHC prend place au niveau de la souscouche PDCP, et que les profils de RoHCv1 et de RoHCv2 sont prvus. Nous tudions galement le support de RoHC par LTE dans le cas de handover et dans les services de broadcast/multicast. Le deuxime axe de travail fut une campagne de tests sur l'implmentation de JCP-Consult. Elle montre que RoHC est trs robuste contre des erreurs sur le lien radio, et peut rduire le taux de perte de paquets dans le cas de handover. RoHC permet d'conomiser environ 40% de bande passante pour les applications audio et environ 10% de bande passante pour les applications vido. Cependant, RoHC introduit un phnomne de gigue au niveau applicatif. Mots cls : rseau cellulaire, 4G, LTE, UMTS, PDCP, compression des enttes RoHC, RoHCv2, IPTV.
Abstract
LTE (Long Term Evolution) is the latest evolution of GSM/UMTS/HSPA, the mobile broadband technology standards, toward the fourth generation of cellular wireless known as 4G. The innovations of LTE at the radio interface and the architecture flat and all-IP reduces the access delay and enrich the multimedia services such as the television over IP. Robust Header Compression (RoHC) is a solution of LTE at the radio interface to optimize the throughput of audio/video applications, where packets generally contain a large header in comparison with their payload. The second version of RoHC (RoHCv2) that simplifies the implementation of RoHC and improves the performance in handover is supported by LTE. We analyze the architecture of LTE to integrate RoHC in this system. Our study shows that RoHC takes place at PDCP radio layer, profiles of both RoHCv1 and RoHCv2 are supported. We also studied the support of RoHC by LTE in handover and the services broadcast/multicast. The verification on the implementation of JCP-Consult proves that RoHC is very robust against errors in the radio link, and can reduce the loss rate in handover. It helps reduce about 40% bandwidth of VoIP flow and about 10% bandwidth of video flow. We, however, found RoHC introduces a little jitter to the multimedia flows. Keywords: cellular network, 4G, LTE, UMTS, PDCP, header compression, RoHC, RoHCv2, IPTV.
Tableau 4: Des anomalies de performance de RoHC de JCP-Consult.....................................42 Tableau 5: Instructions dUDVM et les valeurs de pseudo code..............................................57 Tableau 6: Ratio de Compression pour les messages SIP [45].................................................59
1 Introduction
1.1 Contexte
Mon stage de fin d'tudes sest droul sur une priode de 6 mois JCP-Consult, en coopration avec TELECOM Bretagne, dans le carde du projet NextTV4All du 16 Mars au 15 Septembre 2009. Le projet NextTV4All (Next TV for all: tlvision venir pour tous) est un projet du Ple Images & Rseaux, et sinscrit dans le thme tlvision sur IP bas sur IMS dans un environnement de convergence fixe-mobile. Le projet prend en compte les interactions entre les services audiovisuels interpersonnels et conversationnels et les services de IPTV[annexe du projet]. Les partenaires du projet sont: Alcatel Lucent, Devoteam, France Tlcom, IRISA/Universit de Rennes 1, JCP Consult, Le Tlgramme, Neotilus, NEXCOM Systems, TELECOM Bretagne, Thomson Grass Valley, Thomson R&D France, Thomson Telecom. JCP-Consult est une PME, situe Cesson-Svign, dans la priphrie de la ville de Rennes, dont le domaine d'activit se prsente selon les deux axes suivants : Expertise, standardisation et montage de projets de Recherche et Dveloppement, Le dveloppement de piles de protocole rseaux, notamment les protocoles de notamment concernant les projets de recherches europens ; compression des enttes RoHC. Dans le projet NextTV4all, JCP-Consult participe l'tude de la qualit de service inter-couches , c'est--dire la corrlation entre mtadonnes associes au contenu, signalisation, rservation de ressource et couche MAC. Cette entreprise participe galement l'tude des protocoles RoHCv1 et RoHCv2 au sein des architectures du projet (IMS, LTE). Enfin, elle implmente une pile RoHCv2 afin d'tudier les qualits et les dfauts de ce protocole. TELECOM Bretagne est une Grande cole d'ingnieur gnraliste et un centre de recherche international dans les sciences et technologies de l'information. Le dpartement de recherche RSM (Rseau, Scurit et Multimdia) de TELECOM Bretagne Rennes est actif 9
dans lenseignement et la recherche sur les rseaux et en particulier sur la qualit de service et les nouvelles architectures. Le dpartement est actuellement impliqu dans plusieurs projets portant entre autres sur la QoS et les NGN (Next Generation Network), est membre du rseau dexcellence EuroFGI et participe la standardisation de lInternet lIETF. Dans le projet, une des contributions de TELECOM Bretagne est de raliser des tudes sur la standardisation de RoHCv2. Mon stage fut encadr en partenariat avec ces deux entreprises : Loutfi Nuyami, matre de confrences de TELECOM Bretagne, a suivi le travail Xavier Le Bourdon, ingnieur de recherche de JCP-Consult, a suivi le travail thorique concernant des normes de 3GPP, en particulier, l'architecture de LTE. pratique concernant les tests de la performance de RoHC.
1.2 Problmatique
L'volution des technologies pour rseaux mobiles (2G, HSPDA) et maintenant LTE offrent des dbits de plus en plus importants atteignant jusqu' 100Mbps. Ces dbits permettent alors l'accs aux services multimdia sur tlphone mobile. Au-del des technologies de transport, LTE est bas sur un architecture plate et tout-IP . Cette volution simplifie l'intgration avec l'architecture IMS qui permet l'inter-fonctionnement entre tous types de rseaux (fixe, mobile, sans fil). La taille des paquets dans les flux multimdias associs la voix ou la vido est petite (20 60 octets); l'encapsulation RTP/UDP/IP utilise reprsente donc une part importante du paquet (40 octets pour IPv4 et 60 octet pour IPv6), la compression d'en-tte RoHC (RObust Header Compression, dfini dans le RFC3095 de l'IETF) permet donc une augmentation trs importante de la capacit du rseau dans le cas de flux multimdias interactifs. De plus RoHC a t adopt dans la release 5 de l'UMTS. La premire version, RoHCv1 (RFC 3095), est dores et dj incluse dans les systmes de tlphonie en cours de dploiement. Une seconde version de RoHCv2 (RFC 5225) est actuellement en phase de conception. Elle prend en compte des dsquencements de paquets entre compresseur et dcompresseur, par exemple pour compresser les tunnels IP dans le cadre de la mobilit. Elle apportent galement des simplifications pour RoHCv1. 3GPP a prvu dintgrer cette version dans les futures architectures LTE. Le projet NextTV4All a pour objectif de prparer les futurs services multimdia des 10
rseaux IMS[1], partir de l'analyse et du dveloppement des diffrents services unitaires et des quipements. Le projet se terminera alors par une phase d'intgration des quipements et des services dvelopps, permettant de vrifier la validit des choix techniques. Une des contributions de JCP-Consult est d'tudier et d'intgrer la compression des enttes dans les rseaux. Les tudes visent rpondre deux questions : Comment intgrer RoHC dans l'architecture de LTE ? Quel sera impact de RoHC sur les services de LTE tels que des applications
audiovisuelles, et vice-versa celui du rseau tels que la mobilit et la diffusion broadcast/multicast sur la performance de RoHC ?
J'ai dvelopp un simulateur de fautes au niveau du lien radio, et un outil d'valuation de la performance de RoHC. Le simulateur est capable de simuler des bits errons, et des pertes de paquets. Les fautes peuvent tre gnres selon les diffrents distributions de Uniform, Gilbert simple (ou 2-states Markov), et Gilbert-Ellibott. Le simulateur permet dans la suite de simuler l'autre caractristique telle que le problme de dlai et dsquencement du lien radio. L'outil de test permet d'valuer la performance de RoHC partir des paquets live qui sont capturs du rseau. Lors de mes tests de la performance de RoHCv1, j'ai trouv des anomalies par rapport des valuations de performance de manire thorique. Les discussions avec les ingnieurs JCP-Consult ont permis de corriger des bugs dans l'implmentation. A la fin de mon stage, les rsultats de tests sont raisonnables et correspondent aux attentes thoriques. De plus, j'ai compar la performance de RoHCv1 de JCP-Consult avec une autre implmentation afin d'amliorer implmentation de JCP-Consult l'avenir. Tout cela permet de refaire des tests avec l'implmentation de RoHCv2 qui est en train d'tre dveloppe.
12
techniques comme HSDPA telles que HARQ, mais des canaux radio partags sont remplacs par des dedicated channels . La combinaison de HSDPA et HSUPA s'appelle HSPA. De plus, les services de MBMS permettent de diffuser de contenu en mode broadcast et multicast. Cette diffusion est utilise souvent par des applications telles que la tlvision mobile.[4]
Illustration 1: Le dbit des volutions diffrentes de l'UMTS (le bleu prsente le dbit en thorie, le vert prsente le dbit que l'on espre, source : [5]) La release 7 est termine en juillet 2007. Cette version apporte des amliorations sous le nom de HSPA+ pour HSPA. En thorie, HSPA+ permet au dbit descendant d'atteindre 42.2 Mbps, au dbit montant d'atteindre 11.5 Mbps. Le troisime choix pour l'interface radio
14
de type TDD a le dbit chip de 7,68 Mcps. La technique de CPC (Continuous Packet Connectivity , Connectivit permanente pour les utilisateurs des services paquets) est utilise pour diminuer l'interfrence cause par des canaux dedicated physical control lorsqu'il ny a aucun utilisateur sur ces canaux. Cela permet au terminal de steindre aprs une priode d'inactivit de ces canaux, donc de diminuer sa consommation d'nergie.[6] La release 8 est en cours dachvement. Cette version apporte des volutions significatives d'UMTS sous le nom de LTE. La comparaison des volutions de l'UMTS est disponible dans la figure 1. La release 8 est termine avec des exigences de haute priorit et des caractristiques essentielles. La release 9 dveloppe les caractristiques manquantes. La release 10 se concentre sur LTE-Advanced.
L'architecture gnrale du rseau UMTS se compose d'un rseau d'accs et d'un rseau cur (figure 2). Le rseau d'accs (UTRAN) regroupe des fonctions permettant de transmettre des informations (trafic de donnes et trafic de signalisation) de l'utilisateur vers le rseau cur. Il se compose des NodeB et des RNC (Radio Network Control) qui correspondent respectivement la BTS et au BSC dans l'architecture GSM. Le RNC sert la gestion de ressources radio, et du soft handover par exemple. Il contrle un ou plusieurs NodeB via l'interface Iub. Un NodeB peut servir une ou plusieurs cellules. Le NodeB s'occupe de la transmission et de la rception du signal radio, de la modulation/dmodulation, du codage de canal, l'adaptation du dbit de transmission, largissement/des-largissement, et du contrle de la puissance dmission, et de la synchronisation.[7] Le rseau cur regroupe des fonctions permettant l'acheminement des donnes d'utilisateur vers la destination correspondante, la gestion d'appel, de la mobilit, de lauthentification, de la scurit des changes et de la taxation. Dans le rle d'acheminement, le rseau cur se compose de serveurs et de passerelles qui se divisent entre deux domaines principaux: le domaine CS (domaine de commutation de circuits) et le domaine PS (domaine de commutation de paquets). L'autre domaine est le domaine de broadcast (BC) afin de
15
transmettre des messages de broadcast. Le domaine de CS comprend le MSC, VLR et GSMC servant communiquer avec les rseaux de tlphonie donc PSTN, et PLMN. Le domaine PS comprend le SGSN et le GGSN servant communiquer avec les rseaux tels que Internet. En communiquant avec les bases de donnes partages telles que HLR, EIR, AuC, les composants ralisent galement les fonctions de gestion des utilisateurs, de la taxation, et de la scurit. Le rseau cur n'est pas obligatoire relie l'UTRAN, mais supporte aussi d'autres technologies d'accs radio telles que HIPERLAN 2, IEEE 802.11, et SRAN (Satellite Radio Access Network). Rel 99 Uu Iub
NodeB NodeB RNC MSC/VLR HLR GMSC
Iu CS domain
PSDN
Iur
RNC
PS domain
NodeB SGSN GGSN Internet
Rseau d'accs
Rseau coeur
Illustration 2: Architecture de l'UMTS (release 99) Depuis la release 4, le MSC/VLR se divise entre le serveur de MSC et CS-MGW. Le GSMC se divise galement entre le serveur de GSMC et CS-MGW. Cette division a pour but dans le domaine CS de sparer le plan de contrle et d'utilisateur. Cela permet l'oprateur d'largir la taille et d'optimiser la topologie du systme. Dans release 5 (cf. figure 3)[8], le HSS (Home Subscriber Server) remplace le HLR et AuC, et le sous-systme IMS (IP Multimedia Subsystem) est ajout. LIMS est une architecture overlay servant tablir, modifier et contrler des sessions tablies avec les rseaux IP afin de mieux supporter des applications IP telles que : partage de audio/vido, video streaming , VoIP, .... LIMS utilise le domaine PS pour transmettre des messages de signalisation et des donnes multimdia. Il est indpendant du domaine CS, mme sils partagent quelques composants tels que HSS. Le protocole SIP (Session Initiated Protocol) est le protocole principal de signalisation IMS. LIMS se compose des entits fonctionnelles 16
principales CSCF(Call Session Control Function) (P/I/S/E-CSCF), AS, MRF, PCRF et diffrents SBC. L'architecture de rfrence et les fonctions d'entits IMS sont prsentes dans TS 23.228 [9]. Rel 5 Uu Iub
NodeB NodeB RNC
Iu
CS-MGW
CS-MGW
CS domain
PSDN
Iur
HSS
PS domain
NodeB RNC SGSN GGSN
IMS
Internet
Le modle protocolaire de l'UMTS se compose dun ensemble de divisions verticales et horizontales. La division horizontale spare l'interface en plusieurs des couches. La division verticale comprend le plan de contrle et d'utilisateur. Le plan d'utilisateur transmet des donnes d'utilisateur. Le plan de contrle transmet des messages de signalisation (source principale [10]).
C-plane
RRC RLC MAC PHY UE
Uu
RRC RLC MAC PHY RANAP SCCP ATM or IP Transport PHY UTRAN
Iu
RANAP SCCP ATM or IP Transport PHY CN
AAL5/ATM
Ilustration 4: L'architecture protocolaire de l'UMTS dans le plan de contrle (domaine de PS, release 5) Dans le plan de contrle l'interface Iu (cf. figure 4), le protocole RANAP (Radio Access Network Application Part) regroupe des fonctions ncessaires pour connecter le rseau d'accs avec le rseau cur telles que : paging, allocation de ressources, gestion de la 17
mobilit, .... la signalisation du protocole RANAP est transmise via la couche de transport via ATM ou IP. La couche de transport de type ATM est base sur AAL5 (ATM Adaptation Layer 5) qui est un protocole simple et efficace de la famille des AAL. La couche de transport de type IP est base sur le protocole SCTP/IP. Dans le plan d'utilisateur du domaine PS (cf. figure 5), les donnes sont transmises par un tunnel GTP. Le tunnel GTP est transmis via le protocole UDP/IP. A l'interface radio, 3GPP ajoute la sous-couche PDCP afin de compresser des enttes, de chiffrer les paquets et de transmettre des paquets sans accuss de rception vers le nouveau SRNC pendant un processus de re-allocation de SRNC. Dans le domaine CS, des donnes d'utilisateur sont transmises directement via l'AAL2 ou protocole RTP/UDP/IP l'interface Iu. L'AAL2 donne des connexions qui assurent le dlai minimale et permettent de transmettre au dbit variable. AAL2 et RTP supportent des donnes multimdia [7].
U-plane
PDCP RLC MAC PHY UE
Uu
PDCP RLC MAC PHY UTRAN GTU-U ATM or IP Transport PHY
Iu-PS
GTU-U ATM or IP Transport PHY SGSN ATM transport IP transport UDP/IP AAL5/ATM UDP/IP LL
IuPS
Uu
RLC MAC PHY UE RLC MAC PHY ATM or IP Transport PHY UTRAN
Iu-CS
ATM or IP Transport PHY SGSN
Iu-CS
Illustration 5: L'architecture protocolaire de l'UMTS dans le plan d'utilisateur (release 5) Dans le release 99, la couche de transport via ATM (AAL2/AAL5) est un choix rpandu et la couche de transport via IP est un choix optionnel. Mais depuis release 5, les deux ont la mme priorit. Le protocole SCCP (Signalling Connection Control Part) est choisi pour supporter ces deux couches de transport. En gnral, dans le rseau SS7, SCCP utilise le protocole MTP3 ( Message Transfer Part Layer 3) afin de faire le routage. Les protocole M3UA et SCTP permettent au protocole SCCP de passer dans domaine de IP.
18
19
streaming (VoIP, IPTV), rseaux sociaux (Facebook, MySpace) dans le domaine filaire... gnre de grandes quantits de donnes. Par ailleurs, un large nombre dquipements qui permet daccder aux services sont disponibles aux utilisateurs tels que : ordinateur portable, PDA, smartphone, "notebook enabled modem" ... Lutilisateur a donc besoin dutiliser ces services avec la mme exprience sur le domaine sans-fil, en particulier sur les rseaux cellulaires qui permettent lutilisateur dtre connect accder n'importe quand, n'importe o. Ces donnes vont produire un dbit lev sur ces rseaux qui, jusqu'alors, s'intressent principalement au service de voix, pas aux services de donnes. Les services de donnes sont diffrents des services de voix par: le dbit trs variable, la QoS diffrente pour chaque utilisateur/service, l'utilisation frquente de connexion IP. Les quipements ont donc tendance utiliser des connexions natives IP sans traduction et filtrage pour supporter efficacement ces services. Lvolution du cur des rseaux tlphonies arrive une architecture tout IP qui supporte plus efficacement les connexions IP et un rseau entirement par commutation des paquets facilite les mcanismes de QoS et lutilisation plus efficace des ressources. En gnral, LTE a pour but d'offrir un haut dbit dans le sens montant et descendant, de rduire le dlai d'accs, d'utiliser une bande passante de manire flexible, et d'interfonctionner avec les rseaux existants (3GPP et non-3GPP). Cela permet l'oprateur de fournir des services tels que VoIP, vido-confrence, jeux vido en ligne, IPTV, et l'autre service des donnes interactifs. Les caractristiques principales de LTE sont (source principale [12]) : Amlioration de linterface radio afin daugmenter le dbit montant/descendant, et la capacit, ainsi que la performance en bordure de cellule. LTE utilise lOFDMA pour le sens descendant et SC-FDMA pour le sens montant, en combinaison avec de nouvelles technologies dantenne telles que MIMO et beaming form . Il est prvu d'obtenir un dbit descendant de 100 Mbps; et un dbit montant maximal de 50 Mbps sur une bande passante de 20MHz. Mais en thorie, le dbit descendant peut atteindre 326.4Mbps with 4x4 MIMO, et le dbit montant peut atteindre 86.4 Mbps sur la bande passante de 20 MHz [13]. Une cellule peut supporter au moins 200 dutilisateurs la bande de 5MHz, et 400 d'utilisateurs la bande plus large que 5MHz [14]. Rduction du dlai d'accs : le dlai d'aller-retour est infrieur moins de 10ms et d'initialisation est infrieur 100 ms afin de supporter des services interactifs et temps rel. 20
infrieur que 15km/h. LTE supporte la vitesse de 120 350 km/h (voire 500 km/h, selon la bande utilise) Flexibilit du spectre radio : LTE peut-tre dploy dans des bandes allant de 1,25 MHz 20 Mhz, et la bande apparie et non apparie de la 3G. Cela permet l'oprateur de dployer LTE sur la bande existante, de ne pas demander le permis de nouvelle bande. LTE supporte FDD et TDD. Architecture tout IP , il y a une partie significative du travail de 3GPP pour convertir l'architecture rseau du cur vers une architecture tout IP qui est envisage pour simplifier l'inter-fonctionnement avec les rseaux filaires et les rseaux sans fils non-3GPP. Architecture simplifie permet d'amliorer l'extensibilit du rseaux. Compatibilit avec les rseaux 3G existants. Il faut que LTE supporte le handover
avec les rseaux existants tels que UMTS/HSPA et GSM/GPRS/EDGE. De plus, il faut supporter le handover inter-domaines entre sessions de commutation de paquets et de circuits.
eNodeB
X2
La figure 6 prsente l'architecture gnrale d'un rseau LTE qui se compose d'un rseau d'accs et d'un rseau cur et d'autres blocs qui permettent aux rseaux LTE de se connecter avec les rseaux 3GPP existants, les rseaux IP, rseaux tlphoniques commuts (PSTN) et les rseaux non 3GPP tels que WiFi, Wimax. Le tlphone portable dual mode fournit l'accs au rseau LTE et aussi aux rseaux 3GPP existants. En comparaison avec l'architecture de UMTS et GSM, le rseau LTE a moins de nuds afin de rduire le dlai et d'augmenter la performance du systme [14].
2.2.2.1 Noeuds principaux
L'architecture de rseau cur est base sur le protocole TCP/IP. Cela permet de simplifier l'interfonctionnement avec les rseaux fixes et non-3GPP. En comparaison avec le cur GPRS du rseau UMTS, le rseau cur a moins de nuds, mais chaque nud s'occupe de plus fonctions. Il y a trois nuds principaux : MME au plan contrle, S-GW et P-GW au plan utilisateur. (source principale [15]) S-GW (Serving Gateway) achemine des paquets de l'eNodeB vers le rseau cur et vice-versa. Il est comme une ancre locale qui sert pour la mobilit inter-eNodeBs et vers les rseaux 3GPP (interconnexions de LTE avec les autres 3GPP). Les paquets transmis intereNodeBs (et inter-rseaux 3GPP) sont en transit via cette ancre. P-GW (Packet Data Network Gateway) fournit des connexions entre rseau LTE et d'autres rseaux IP, PSTN, non-3GPP. L'allocation dadresse IP pour l'UE, filtrage des paquets pour chaque utilisateur (Policy Enforcement Point), et le support de la tarification d'une session sont des autres fonctions du P-GW. P-GW peut se connecter avec les rseaux PSTN et rseaux IP grce lIMS, une architecture overlay par rapport au LTE, servant tablir, modifier et contrler des sessions. MME (Mobility Management Entity) se compose des fonctions principales dans le plan de contrle. Il sert grer des sessions : signalisation, et ngociation des qualits de service, fournir des procdures de scurit telles que : initiation, et ngociation de chiffrement/protection d'intgrit, et mettre jour la position de l'UE. HSS (Home Subscriber Server) est une base de donnes qui remplace le rle de HLR et AuC qui taient dj introduits dans les rseaux 2G et 3G. Le standard ne prcise pas l'architecture physique de rseau du cur. On peut sparer MME S-GW afin diminuer les interfrences entre la signalisation du plan de contrle et flux 22
de donnes levs du plan utilisateur. On peut sparer P-GW avec MME et S-GW afin d'isoler les paquets internes (du rseau cur) avec des paquets externes (des autres rseaux IP). L'isolation facilite les oprations de scurit. Le rseau d'accs est rduit dans l'eNodeB qui joue le rle du NodeB et du RNC (Radio Network Control) dans les rseaux UMTS. Cela permet de rduire le dlai d'accs et de simplifier la fonction d'opration et de maintenance du rseau [14].
Illustration 7: La diffrence entre eNodeB (LTE) et NodeB (HSPA) au plan utilisateur [15] Dans le rle du NodeB, l'eNodeB s'occupe de : la modulation/dmodulation, le codage/ dcodage des informations transmises sur l'interface radio. Dans le rle du RNC, l'eNodeB s'occupe : du contrle de ressources, du contrle de la mobilit, de la compression des enttes IP, et du chiffrement des donnes (voir 3GPPP TS 36.300, chapitre 4.1) L'architecture traditionnelle de l'UMTS rserve la complexit et les nombreux calculs au RNC, et permet ainsi au NodeB de rester simple. Le RNC gre donc de nombreux (mme des centaines [15]) de NodeBs et se coordonne avec les autres RNC pour contrler la macrodiversit (afin de rduire l'interfrence dans le rseau UTRAN base sur la couche physique 23
de CDMA). Les eNodeB peuvent se connecter directement avec le rseau cur pour rpartir le travail de RNC par l'interface S1. De plus, le mcanisme de retransmission qui est entirement implment dans l'eNodeB diminue le dlai. En effet, l'UMTS/HSDPA spare physiquement la retransmission entre NodeB (mcanisme de HARQ) et RNC (mcanisme de ARQ). La sparation conduit l'utilisation de deux tampons dans le NodeB et dans le RNC, ce qui augmente le dlai d'attente. Par d'ailleurs, le changement de NodeB cause la perte de paquets dans le tampon de ce NodeB. La retransmission par la couche TCP du RNC (troisime couche) cote donc plus cher. Les eNodeB peuvent se connecter par l'interface X2 pour transmettre des paquets aux tampons, la couche infrieure (deuxime couche), la retransmission cote donc moins cher.
2.2.2.2 Architecture protocolaire
Comme le modle d'interface dUMTS, le modle de LTE se compose d'un ensemble de couches verticales et horizontales. Les couches horizontales sont bases sur le modle OSI. Les couches verticales divisent l'interface entre le plan de contrle et le plan utilisateur. La division verticale correspond la faon de sparer les flux de donnes. Les donnes du plan de contrle sont transmises avec des contraints de scurit, de fiabilit plus importantes. Celles du plan utilisateur sont transmises par des protocoles plus simple.
a) Plan de contrle
Le plan de contrle transmet des messages de signalisation telles que la signalisation de gestion de ressource radio, de gestion de mobilit, des services NAS (Non Access Stratum), des autres procdures entre mobile et rseau cur.
UE NAS RRC PDCP RLC MAC PHY RRC PDCP RLC MAC PHY eNB MME NAS
Illustration 8: Plan contrle en couches [16] La pile protocolaire l'interface radio est presque la mme que celle du plan utilisateur. Mais les paquets du plan contrle sont transmis avec la priorit suprieure et une protection 24
radio suprieure grce la couche MAC qui transmet des canaux logiques vers les canaux de transport correspondants.
b) Plan utilisateur
Le plan utilisateur regroupe l'ensemble des donnes d'usager et des signalisations au niveau application. La figure 9 prsente l'architecture protocolaire du plan utilisateur. La couche d'application n'est prsente qu lUE et quau serveur d'application bas sur le protocole IP. Les donnes du plan utilisateur sont transparentes pour le cur de rseaux.
App IP PDCP RLC MAC PHY UE PDCP RLC MAC PHY eNodeB S-GW P-GW Serveur d'application GTP-U UDP GTP-U Tunnel IP GTP-U UDP App IP
Illustration 9: Plan utilisateur Les donnes sont transmises par un tunnel GTP-U. GTP-U est une partie du protocole GTP, l'autre partie est GTP-C lie au plan contrle. Autre la fonction d'tablir une connexion de bout en bout entre le mobile et le serveur d'application, le protocole GTP s'occupe d'acheminer les paquets vers l'eNodeB correspondant pendant un dplacement de l'utilisateur. Le protocole GTP est transmis via UDP/IP. La pile du protocole GTP/UDP/IP ajoute donc 36 octets d'entte (20 octets dIPv4, 8 octets dUDP, et 8 octets de GTP).
des informations de la configuration des Radio Bearers qui contient des paramtres de la couche infrieure telles que la configuration pour la compression des enttes de la couche PDCP[Annexe : PDCP Info]. La fonction principale de la deuxime couche est de donner un transport fiable entre deux quipements du rseau. A ct de MAC et RLC, deux sous-couches de la couche de liaison traditionnelles, 3GPP ajoute une sous-couche PDCP (cf. figure 10).
Radio Bearers ROHC PDCP Security Security Security Security ROHC ROHC ROHC
RLC
...
...
CCCH BCCH
PCCH
MAC
Multiplexing UE 1
Multiplexing UE n
HARQ
Illustration 10: La deuxime couche de l'interface radio au sens descendant [16] La sous-couche MAC regroupe des fonctions qui rsolvent des problmes spcifiques lis la couche physique pour assurer le couplage entre la couche de liaison et la couche physique, telles que : multiplexage des canaux logiques vers canaux de transport correspondants (selon la pr-configuration), ordonnancement selon la priorit ( priority handling ), et correction d'erreurs sur le mcanisme de HARQ qui est hrite de 3G HSDPA. La sous-couche RLC regroupe des fonctions indpendantes de la couche physique, telles que : remise en ordre des paquets, dtection de perte, et demande de retransmission (Auto Repeat Request). Il y a trois modes de fonctionnement: TM (Transparent Mode), UM (Unacknowledged Mode), et AM (Acknowledged Mode). RLC n'ajoute rien au paquet original dans le mode TM. La couche peut dtecter des pertes et remettre en ordre des paquets dans le mode UM. Enfin, dans le mode dAM, l'entit RLC peut demander l'autre bout de retransmettre le paquet. 26
Illustration 11: La fonction de la couche PDCP [17] Dans le cas de handover, et dans le sens montant, l'entit PDCP va rtablir la compression des enttes (recrer la contexte de RoHC), ensuite tous les paquets qui ne sont pas acquittes par la couche infrieure sont retransmises jusqu' ce que tout le tampon de HARQ soit vide. Dans le sens descendant, l'eNodeB va transmettre tous les paquets qui ne sont pas acquitts par la couche infrieure vers le nouveau eNodeB par l'interface X2, ensuite rtablir la compression des enttes. S'il n'y a pas d'interface X2 entre deux eNodeB, la couche suprieure va s'occuper de retransmettre les paquets. Le protocole RTP/UDP n'a pas de 27
mcanisme de retransmission et ne peut donc pas rattraper les pertes ventuelles dans les services VoIP et IPTV [18].
3.2 RoHCv2
Tandis que RoHCv1 est spcifi principalement par la RFC 3095, RoHCv2 est dfini par trois documents : La RFC 4995 dcrit le framework commun v1 et v2 pour la plus grande part. La RFC 4997 dfinit RoHC-FN, une notation formelle pour dfinir des profils La RFC 5225 dfinit les profils RoHCv2 proprement dits, dcrits en grande partie
fields) ; seul le format IR peut changer le profil associ un contexte. En revanche, elle utilise un format co_repair qui transmet tous les champs dynamiques, protgs par un CRC 7 bits, en cas de besoin (contexte dcompresseur abm). La segmentation RoHC est incompatible avec les formats v2 lorsque RoHC ne peut garantir une transmission sans rordonnancement entre compresseur et dcompresseur. Cela est d au fait que le protocole de segmentation n'utilise pas de numro de squence, mais un simple bit pour distinguer le dernier segment. Un point commun important avec RoHCv1 : RoHCv2 compte sur les couches basses pour donner la longueur des paquets compresss, et ne transmet donc pas dans ces paquets la taille de la charge utile.
N.B. IP s'entend v4 ou v6 ; les deux versions peuvent tre utilises dans un mme entte. Les bits de poids fort en 0x01 permettent de distinguer les profils v2 des profils v1 (0x00). Pour chaque profil, RoHCv2 sait compresser les protocoles suivants en tant qu'extensions IP : ip_dest_opt (IPv6 Destination Option) ip_hop_opt (IPv6 Hop-by-hop Option) ip_rout_opt (IPv6 Routing Header) gre (Generic Routing Encapsulation) mine (Minimal Encapsulation within IP) ah (IP Authentication Header)
31
Tableau 1: Les profils supports par LTE [17] Historiquement, dans release 99, la couche de PDCP ne supporte que IP compression header . ROHCv1 est support partir de release 4. Les tests de la performance de RoHC sont ajoutes dans release 5. Dans release 6, l'utilisation de RoHC dans les services MBMS 32
Mmoire de fin d'tudes Intgration de RoHC dans l'architecture de LTE est prise en compte, mais n'est pas obligatoire.
Dans release 8, PDCP nutilise que RoHC pour compresser/dcompresser des enttes pour les paquets au plan utilisateur. Les profils supports se composent des profils dfinis dans ROHCv1 et ROHCv2 (cf. tableau 1). Lutilisation de la compression des enttes peut tre configure par la couche suprieure. RRC contient des informations pour la configuration de PDCP (voir 3.5). Les paramtres obligatoires de la configuration sont dfinis par RFC 4995. Mais il y a des paramtres qui ne sont pas utiliss par PDCP de cette release.
Paramtre MAX_CID Obligatoire Oui Description Le nombre maximal de CID (Contexte Identifier) est utilis. Il faut rserver au moins un contexte pour les flux non-compresss. Cest--dire, il faut que MAX_CID < Maximum Number of RoHC Context Sessions Elle est dduite du paramtre MAX_CID par la rgle : If MAX_CID > 15 then LARGE_CIDS = TRUE else LARGE_CIDS = FALSE. Les profils sont utiliss par lUE. Les profils autoriss sont disponibles dans le tableau 1. Le canal de feedback Lutilisation de segmentation
LARGE_CIDS
Oui
supportes par l'UE (annexe UE-EUTRA-Capability). Pour plus de dtails, on peut consulter le chapitre 5.6.3 de [24]. Le message de UECapacityInformation contient les autres informations de la capacit radio que l'UE supportent. Aprs la rception de l'UE, l'eNodeB va transmettre ce message MME. Le MME sauvegarde les informations jusqu' ce que l'UE lance la procdure d'attacher ou de dtacher le rseau (chapitre 5.11.2 de [25]). Le MME va transmettre les informations au nouveau eNodeB pendant le handover, afin de rduire l'overhead, car la taille de message UECapacityInformation peut atteindre 510 octets.
RRCConnectionRequest RRCConnectionSetup RRCConnectionComplete Authentification and others NAS Procedures RRCConnectionReconfugation (PCDP-config) RoHC configured RRCConnectionReconfigurationCompete User data transmission (IP packets) RRCConnectionRelease
Illustration 12: Procdure pour configurer et dclencher RoHC dans l'interface radio Premirement, la connexion de signalisation SRB qui sert transmettre des messages RRC entre UE et E-UTRAN est tablie par la procdure de RRC Connextion 34
Etablisement . Cette procdure est dclenche par la couche suprieure de l'UE, lorsque l'UE veut rpondre un appel de paging, faire un appel, ou transmettre des messages de NAS (qui sont piggybacked dans les messages de RRC). L'UE envoie un message de RRCConnectionRequest vers eNodeB. La connexion SRB est tablie lorsque l'UE reoit un message de RRCConnectionSetup d'eNodeB. L'entit PDCP sera tablie, en observant la configuration courante de scurit. Ici, il n'y a pas de compression. Ensuite, tous les messages d'authentification et de NAS transmis sont protgs (intgrit/chiffrement) par PDCP. Si l'E-TRAN est surcharg, il peut refuser la requte de l'UE par le message RRCConnectionReject qui contient le temps d'attente. Deuximement, ce sont la procdure d'authentification et d'autres procdures de NAS qui ne sont pas prcises dans le cas de ce document. Troisimement, la procdure de re-configuration sera lance afin de contrler le handover, de transmettre des messages NAS d'eNodeB vers l'UE, ou d'tablir/modifier la connexion de donnes DRB au plan d'utilisateur. Pour le dernier but, le message de RRCConnectionReconfiguration contient des informations pour configurer la sous-couche PDCP, PDCP-config (qui s'appelle PDCP-info dans la release prcdante de release 8, annexe PDCP-info ). En consquence, l'instance de RoHC est tablie. Tous les enttes de paquets IP au plan d'utilisateur sont compresss par RoHC. L'UE rpond l'E-UTRAN par le message de RRCConnectionReconfigurationComplete ". PDCP-config se compose des paramtres qui dfinissent l'utilisation/non-utilisation de RoHC, le nombre maximal de contexte utilis (MAX_CID), les profils supports. Si les deux profils supports ont en commun les 8 bits de pois faible, celui dont la valeur est la plus leve est slectionn. RoHCv2 est donc privilgi par rapport RoHCv1. De plus, dans les releases prcdentes de la releases 8, la configuration de PDCP regroupe d'autre paramtre telle que la Target Mode , qui dcide le mode de RoHC (annexe PDCP-info ). Si l'UE ne peut pas appliquer une partie de la configuration dans le message de RRCConnectionReconfiguration , il lancera la procdure de re-tablissement. Il envoie un message de RCC Connection Reestablisement qui indique le refus par la configuration, ou par le handover, mais n'indique pas des paramtres qui causent ce refus. L'ide principale est de rduire la complexit d'eNodeB. L'entit PDCP est r-tablie selon la configuration prcdente. Enfin, le message de RRCConnectionRelease va supprimer toutes les connexions de 35
SRB et de DRB tablies si l'UE est inactif pendant longtemps ou passe un autre eNodeB. L'entit de PDCP, et l'instance de RoHC sera alors libre.
-- ASN1START PDCP-Config ::= discardTimer } Setup rlc-AM statusReportRequired } Rlc-AM rlc-UM pdcp-SN-Size } Rlc-UM headerCompression notUsed rohc maxCID profiles profile0x0001 profile0x0002 profile0x0003 profile0x0004 profile0x0006 profile0x0101 profile0x0102 profile0x0103 profile0x0104 }, ... } }, ... } SEQUENCE { ENUMERATED { ms50, ms100, ms150, ms300, ms500, ms750, ms1500, infinity OPTIONAL, SEQUENCE { BOOLEAN
-- Cond
OPTIONAL,
-- Cond
SEQUENCE { ENUMERATED {len7bits, len12bits} OPTIONAL, CHOICE { NULL, SEQUENCE { INTEGER (1..16383) SEQUENCE { BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN
-- Cond
DEFAULT 15,
de continuer fonctionner avec le contexte actuelle, de ne pas envoyer des packets IR pour construire un nouveau contexte, et rduire la perte casse par l'interruption de contexte. On peut donc conomiser la bande passante de 1.9% quand la frquence de handover est haute, et de 0.5 quand la frquence de handover est base [R2-072045]. Le transfert de contexte est donc supporte par UMTS. Mais, LTE ne supporte pas le transfert. Pour implmentation de transfert de contexte, il faut modifier l'interface X2 pour grer les informations de contexte, et modifier significativement le protocole RoHC. Cependant, l'ide principale de LTE est de mettre moins complexit. De plus, si le transfert de contexte est support, l'implmentation de diffrentes fournisseurs de RoHC peut ne pas traiter le mme lors qu'il y a le problme de dconsquence ou la perte de paquets.
3.7.1 MBMS
Les services MBMS (Multimedia Broadcast/Multicast Service) permettent aux oprateurs 3G de fournir plus efficacement les applications mdia en concurrence avec DVBH. Ils diminuent le dbit dans rseaux coeur et utilisent efficacement des ressources radio au rseau daccs. Ils ont deux modes de fonctionnement : mode broadcast et multicast. Ces deux modes utilisent une transmission unidirectionnelle [27]. Le mode broadcast permet de diffuser des donnes mdia dun nud (un oprateur) vers multiples nuds (multiples utilisateurs) dans la zone de services. Dans le mode multicast, le rseau n'envoie des donnes qu'aux cellules o il y a des abonnes (un groupe). Le mode multicast ressemble au mode broadcast, cela prs qu'il propose des mcanismes dabonnement (subscripstion) et rejoindre/disjoindre du groupe [28]. Le mode multicast de 3GPP est diffrent du multicast IP dIETF. Il prend en compte lutilisation efficace des ressources radio. Cependant, il peut tre compatible avec le multicast IP. Depuis le release 7, 3GPP apporte une nouvelle notion de SFN (Single Frequency Network). SFN permet aux transmissions de plusieurs cellules d'tre synchronises pour
37
transmettre un mme contenu. Le protocole SYNC et un serveur de MBMS-GW (e-MBMS Gateway) sont utiliss pour diffuser le mme contenu vers les eNodeBs. Une entit de MCE (MBMS Coordination Entity) coordonne les allocations de ressources radio aux couches RLC/MAC de ces eNodeBs. Dans la suite, 3GPP a dcid de complter l'architecture de MBMS dans release 9 [29].
38
comparateur Nombre de paquets errons Nombre de paquets perdus Taille des enttes compresss
Compresseur RoHC
Dcompresseur RoHC
Illustration 13: Modle d'valuation de performance de RoHC Le modle d'valuation de performance se compose des blocs principaux suivants: gnrateur des paquets IP, compresseur/dcompresseur RoHC, comparateur et modle de fautes. Nous utilisons VLC player pour gnrer des paquets multimdia en flux selon le protocole RTP. Ensuite, nous les passons au compresseur RoHC. Des fautes sont ajoutes aux paquets compresss afin de simuler des fautes dans le lien radio. La simulation donne un rapport statistique sur le nombre de paquets errons, sur le nombre de paquets perdus, et sur la taille d'enttes compresss. Nous valuons avec des flux audio et vido diffrentes, selon le tableau 3.
39
Mmoire de fin d'tudes Intgration de RoHC dans l'architecture de LTE Codec Narrow band audio Wide band audio Standard video High quality video AMR NB AMR WB H264 H264 Bitrate (kbps) 12.2 23 74 104 Packet size (bytes) 23 60 variable Variable
VU DINH Dau Promotion 13, IFI Description 23 octes/packet 71 octes/packet Frame size 176x144, 10 fps Frame size 176x144, 15 fps
4.3 Pre-tests
Illustration 14: Pre-tests, le nombre maximal de paquets perdus est trs haut dans O-mode JCP-Consult a dvelopp un outil de test qui s'appelle synthetic tester pour que les ingnieurs puissent valider le fonctionnement de RoHC. Il permet de gnrer automatiquement des paquets, les passer vers RoHC, de valider les sorties de test, et donne des statistiques de tests. L'outil grre ses propes paquets et n'est pas capable de tester des paquets live qui sont capturs partir du rseau. De plus, il est incapable de simuler : erreurs, perte de paquets, dlai, et dsquencement dans lien radio. Number of RoHC Profile BER Packets mode 5830 O 5830 O 5830 O 5766 R 5766 R 5766 R 2 0.000150 2 0.000200 2 0.000250 2 0.000500 2 0.000550 2 0.000600 Bandwidt Average Burst packet h packet loss loss reduction 0.001544 1 0.349770 0.553859 3223 0.349705 0.003774 1 0.349770 0.346514 8 0.120370 0.926639 5280 0.077056 0.115505 4 0.122304 Input file amr23k01.pcap amr23k01.pcap amr23k01.pcap hightrate3gp01.pcap hightrate3gp01.pcap hightrate3gp01.pcap
Tableau 4: Des anomalies de performance de RoHC de JCP-Consult Lors des premiers tests j'ai remarqu des anomalies, et une performance est moyenne mauvaise. Le nombre de paquet perdus successivement en mode optimiste est trs haut jusqu' 700 paquets successifs, figure 14, c'est dire en pire cas l'application doit attendre 700*20ms=14s pour recevoir le paquet suivant. J'ai tudi le fonctionnement de RoHC et des
41
valuations de performance de manire thorique pour comprendre les rsultats. Ces rsultats ne correspondent pas la thorie. Les discussions avec les ingnieurs JCP-Consult ont permis de corriger les bugs dans l'implmentation. A fin de mon stage, les rsultats de tests sont raisonnables et observent des rsultats manire thorique.
4.4 Rsultats
Dans les rsultats suivants, nous choisissons le profil IP/UDP/RTP qui correspond aux applications multimdia telles que celles prvues dans le projet-NextTV4All.
Illustration 15: Bande passante conomique dans U-mode et BER = 0.0 avec des flux diffrents Le taux de bande passante conomise prsente l'efficacit et l'intrt de RoHC. Le taux de diffrents flux est disponible dans la figure 15. A gauche, ce sont des rsultats de test avec des paquets IPv4, et a droit, ce sont celles du paquets IPv6. Chaque colonne qui a le couleur diffrent prsente un type de flot. On trouve que dans le mme type de flot, l'efficacit de compression de paquets IPv6 est plus leve par rapport celle de paquets IPv4. De plus, dans la mme version de protocole IP, le plus payload est gros, le mois RoHC est intressant. L'efficacit de RoHC
42
est proportionnelle la taille des enttes et inverse proportionnelle la taille de payload. Les rsultats dans le figure 15 ne prends pas en compte des erreurs dans le lien radio qui causent dsynchronisation entre le compresseur et le dcompresseur. Dans les figures 16 19, nous valuons l'efficacit de RoHC avec les taux de bits errons diffrents (BER). On trouve que si le BER augmente, le taux de bande passante conomise diminue. Le niveau de diminution est moins de 1%. Le RoHC bidirectionnel (O-mode et R-mode) est plus efficace par rapport RoHC unidirectionnel lors que le BER est moins de 103,5 . Si le taux d'errons est petite, O-mode conomise le plus de bande passante, mais quand le BER est suprieur 103 , R-mode est le meilleur. Dans le mode unidirectionnel, le compresseur revient priodiquement aux niveaux infrieurs o il doit envoyer des paquets plus grands. De plus, il n'a pas de feedback, le niveau de compression est donc constante. Cependant, dans le mode bidirectionnel, il ne revient que aux niveaux infrieurs soit il reoit des NACKs. La performance du mode bidirectionnel est meilleure que celle du mode unidirectionnel, lors que le BER est petite. Si le BER augmente, le compresseur reoit plus de paquets NACKs, il est forc revenir au niveau infrieur. L'efficacit est donc diminue. Quand lerreur est petite, le mode optimiste est meilleur que le mode fiable parce que la liaison de retour est moins utilise. Quand l'erreur est assez grand R-mode et O-mode doivent revenir aux niveaux infrieurs plus frquemment. Mais le contexte de R-mode peut monter au niveau suprieur toute suite aprs recevoir un ACK, cependant le O-mode doit envoyer L paquets (niveau de confiance) avant de passer au niveau suprieur.
43
Illustration 16: Taux de bande passante conomise VoIP AMR 12,2 kbps
Illustration 18: Taux de bande passante conomise Video H264 haute qualit
Illustration 19: Taux de bande passante conomise Vido H264 moyenne qualit
45
Illustration 24: Nombre maximal de paquets perdus successifs VoIP AMR 12,2 kbps
Illustration 25: Nombre maximal de paquets perdus successifs VoIP AMR 23 kbps
Illustration 26: Nombre maximal de paquets perdus successifs Video H264 haute qualit
Illustration 27: Nombre maximal de paquets perdus successifs Vido H264 moyenne qualit
48
5 Conclusion et perspectives
Le contexte de ce stage tait le projet de recherche europen NextTV4All, JCPConsult, en coopration avec TELECOM Bretagne. Dans ce stage, nous nous sommes intresss faire un tat de l'art d'intgration de RoHC dans l'architecture de LTE. Premirement, nous avons prsent des innovations, et l'architecture de LTE. On remarque que des volutions dans la technique d'accs OFDMA, MIMO et la simplification d'architecture base sur le protocole IP facilitent des services multimdia comme IPTV. Deuximement, nous avons prsent RoHC dans LTE. RoHC fonctionne au niveau de la sous-couche PDCP, les profils de RoHCv1 et RoHCv2 sont supports. On constate que RoHC peut rduire la perte de paquets pendant le handover. RoHC est support dans les services de broadcast/multicast (MBMS). RoHCv2 amliore la performance dans certains cas tel que le handover. RoHCv2 apporte galement des simplifications d'implmentation. Troisimement, nous avons effectu des tests sur l'implmentation de JCP-Consult de RoHCv1. RoHC est trs robuste contre des erreurs sur le lien radio, et peut rduire le taux de perte de paquets. RoHC permet d'conomiser environ 40% de bande passante pour les applications audio et environ 10% de bande passante pour les applications vido. Cependant, RoHC introduit un phnomne de gigue au niveau applicatif. Nous avons dvelopp un simulateur de fautes au niveau du lien radio, et un outil d'valuation de la performance de RoHC. Le simulateur est capable de simuler des bits errons, et des pertes de paquets selon diffrentes distributions : Uniform, Gilbert simple, et Gilbert-Ellibott. Les premiers rsultats de test ont permit aux ingnieurs JCP-Consult de corriger des bugs de type chaotique. Nous avons galement ralis une comparaison de la performance de RoHCv1 de JCP-Consult avec une implmentation comptitive. Cette comparaison a montr qu'il tait encore possible d'optimiser l'implmentation de RoHCv1. Une tude intressante serait la comparaison avec RoHCv2, qui est en cours de dveloppement au sein de l'entreprise JCP-Consult et TELECOM Bretagne. Une autre tude intressante concerne l'impact de RoHC sur la qualit de service (QoS) des rseaux multimdia. En effet, nous avons vu les problmes de gigue gnrs par RoHC, mais d'autres effets sont galement prvoir, comme l'attente de synchronisation de RoHC. Je compte d'ailleurs rester en contact avec JCP-Consult et TELECOM Bretagne pour participer ces tudes. 50
Bibliographie
[1] Rmi HOUDAILLE, "Annexe technique du projet NextTV4All", v2.3, 05/2008 [2] 3GPP, "Overview of 3GPP Release 4", v1.1.0, 2004 [3] 3GPP, "Overview of 3GPP Release 5", 09/2003 [4] 3GPP, "Overview of 3GPP Release 6", v.TSG #33, 09/2006 [5] 3G Americas, "EDGE, HSPA and LTE broadband innovation", 09/2008 [6] 3GPP, "Overview of 3GPP Release 7", V0.9.5, 04/2009 [7] IEC, "UMTS Protocols et Protocol testing", 2003 [8] 3GPP TS 23.002, "UMTS; Network architecture ", v5.6.0, 12/2002 [9] 3GPP TS 23.228, " IP Multimedia Subsystem (IMS); Stage 2", v8.8.0, 03/2009 [10] 3GPP TS 29.414, " UMTS; Core network Nb nata transport and transport signalling", v5.1.0, 12/2006 [11] 3G Americas, "Mobile Broadband Evolution : 3GPP release 8 and beyond HSPA+, SAE/LTE and LTE-Advanced", 02/2009 [12] 3GPP, "Overview of 3GPP Release 8", 04/2009 [13] 3GPP TSG RAN WG1 Meeting #49 R1-072580, "LS on LTE performance verification work ", 05/2007 [14] Qualcomm, "3GPP Evolution LTE", 02/2008 [15] P. Lescuyer, T. Lucidarme,, "Evoled Packet System: The LTE and SAE evolution of 3G UMTS", John Wiley &Son, 2008 [16] 3GPP TS 36.300, "LTE Overall description stage 2", v8.8.0, 04/2009 [17] 3GPP TS 36.323, "Packet Data Convergence Protocol (PDCP) specification", v8.5.0, 04/2009 [18] H. Holma, A. Toskala, "LTE for UMTS: OFDMA and SC-FDMA Based Radio Access", John Wiley &Son, 2009 [19] IEC, "OFDM for Mobile Data Communications", 12/2008 [20] Ericsson , "Long Term Evolution (LTE): an introduction", 10/2007 21: Ericsson, 3GPP TSG-RAN WG2 Meeting #59 R2-073223, Support for RoHC Profiles in LTE PDCP, 08/2007 [22] 3GPP TS 36.306, "User Equipment (UE) radio access capabilities", v8.3.0, 04/2009 [23] Qualcomm Europe, 3GPP TSG-RAN WG2 #60bis R2-080326, "RoHC rate capability",, 02/2008 [24] 3GPP TS 36.331, "Radio Resource Control (RRC); Protocol specification", v8.5.0, 04/2009 [25] 3GPP TS 23.401, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access ", v8.6.0, 06/2009 [26] Henttonen T.,Aschan K., Puttonen J., Kolehmainen N., Kela P., Moisio M., Ojala J., "Performance of VoIP with Mobility in UTRA Long Term Evolution", Vehicular Technology Conference, IEEE VTC Spring, 2008 [27] 3GPP TS 25.346, "Introduction of the Multimedia Broadcast/Multicast Service (MBMS) in the Radio Access Network (RAN); Stage 2", v8.3.0, 04/2009 [28] 3GPP TS 23.246, "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description", v8.3.0, 03/2009 [29] 3GPP TSG SA WG2 Meeting #71 S2-091686 , "Removal of eMBMS Architecture Principles from Rel-8", 02/2009 [30] MARTINEZ FERNANDEZ E.G., Compression des en-ttes intra-couches pour les flux 51
multimdia multicast sur des rseaux sans fils, Thse de doctorat, ENST Telecom Bretagne, 12/2007 [31] Nokia, Siemens Networks, 3GPP TSG-RAN WG2#57bis R2-071248 , "Header Compression in MBMS for E-UTRAN", 03/2007 [32] Alain Couvreur, Louis-Marie Le Ny, Ana Minaburo, Gerardo Rubino, Bruno Sericola and Laurent Toutain , "Performance analysis of an Header Compression Protocol: The RoHC unidirectionnel mode", Springer Telecommunication Systems, 2006 [33] B. Wang, H.P. Schwefel, K.C. Chua, R.Kutka and C.Schmidt, "On Implementation and Improvement of Robust Header Compression in UMTS, IEEE Personal, Indoor and Mobile Radio Communications", 2002 [34] Minaburo A., Compression des en-ttes sur les rseaux bas-dbit, Thse de doctorat, , 2003 [35] EL HENI Neila, BADARD Benoit, DIASCORN Vincent, NUAYMI Loutfi, "Performance of RAB mapping and ROHC for the support of VoIP over UMTS", PIMRC'07, Athens, Greece, 2007 [36] NUAYMI Loutfi, BOUIDA Nabil, LAHBIL Nabil, GODLEWSKI Philippe, "Headers overhead estimation, header suppression and header compression of WiMAX", 3rd IEEE international conference on wireless and mobile computing, networking and communications, 8-10 october, New York, USA, 2007 [37] Anna Larmo, Magnus Lindstrm, Michael Meyer, Ghyslain Pelletier, Johan Torsner,and Henning Wiemann, "The LTE Link-Layer Design", Ericsson Research, 2009 [38] W. Karner, P. Svoboda, and M. Rupp, "A UMTS DL DCH Error Model Based on Measurements in Live Networks ", Proc. 12th Int. Conf. Telecomm. (ICT), Capetown, South Africa, 05/2005 [39] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., Rosenberg, J., "Signaling Compression (SigComp)", 02/2003 [40] Price, R., Rosenberg, J., Bormann, C., Hannu, H., Liu, Z., "Universal Decompression Virtual Machine (UDVM)", working progress draft-ietf-rohc-sigcomp-udvm-00.txt, 02/2002 [41] Hannu, H., "Signaling Compression (SigComp) Requirements and Assumptions", 02/2003 [42] M. West, et.al. , "IP Header and Signaling Compression for 3G Systems", IEEE 3rd. International Conference in 3G Mobile Communication Technologies, 05/2005 [43] H. Jin, et.Al., "Using SigComp to Compress SIP/SDP Messages ", IEEE International Conference on Communications, ICC 2005, 05/2005 [44] M. Nordberg, et.al., "Improving SigComp performance through Extended Operations", IEEE 58th Vehicular Technology Conference, 10/2003 [45] Rawat, P., et. Al., "Signaling Compression Mechanism analysis and deployment", Algotel, 2006
52
Annexe A
SIGCOMP qui fonctionne entre la couche d'application et la couche de transport peut rduire jusqu' 93.8% de taille des messages SIP. SIGCOMP est contribu par Ana Carolina MINABURO, TELECOM Bretagne, dans l'tat de l'art de l'utilisation des enttes dans l'architecture du LTE , de projet NextTV4All.
SIGCOMP
Introduction
Le dveloppement des services interactifs comme lIM (Instant Messaging), la prsence et des services multimdia comme la vido confrence ou la TV dans le rseau 3G exige une importante bande passante. A partir de la Release 5 de lUMTS, le protocole SIP (Session Initiation Protocol, RFC IETF 3261) est choisi pour envoyer la signalisation des communications de voix et autres sessions multimdia. Mais SIP est un protocole bas sur le texte (comme http) et il gnre des paquets entre 200 et 1500 octets qui sont envoys plusieurs fois ce qui est inefficace et augmente le dlai pour ltablissement dun appel. Le groupe de travail RoHC lIETF a travaill sur la conception dun mcanisme de compression pour les messages de signalisation SIP et pour rduire la rptition des envois. Le rsultat est SigComp (Signaling Compression) [39][40]. La compression de donnes SigComp [39][40] permet de rduire laugmentation de dbit gnre par la signalisation SIP lors de la cration dune session pour les services tels que IP-TV, VoD, Prsence, IM, etc. dans les rseaux daccs sans fil comme lUMTS ou le LTE. Lutilisation de SigComp permet daugmenter le dbit utile et rduire le dlai dans la transmission de donnes. La compression de SIP rduit lutilisation de ressources radio et permet dallouer un plus grand nombre dutilisateurs. Le groupe de travail RoHC lIETF, charg de dvelopper SigComp, a considr que les terminaux de tlphonie cellulaire nont pas beaucoup de ressource mmoire ni un processeur assez puissante pour traiter des algorithmes trs complexes [40][41]. SigComp doit donc tenir compte du fait que le terminal doit appliquer un grand nombre dalgorithmes dj dploys dans un rseau. SigComp ngocie la quantit de mmoire disponible pour la compression et nutilise quun nombre rduit doprations pour augmenter le temps de traitement.
Architecture de SIGCOMP
SigComp est un mcanisme de compression de donnes qui travaille entre la couche applicative et la couche transport (cf.. figure 31), pour compresser les messages de signalisation SIP (qui sont de messages texte donc sont compresss comme des donnes). Ces messages SIP ont une taille qui peut atteindre 500kb et ils sont rpts plusieurs fois pour assurer la fiabilit de la session. La Compression et Dcompression SigComp sont faites par les entits paires qui envoient travers des rgulateurs de paquets les messages vers la couche applicative et la couche transport.
53
Illustration 31: Pile protocolaire avec la compression. LArchitecture SigComp a trois lments principaux (cf. figure 32) : Le Compresseur (C), le Dcompresseur (D) et le gestionnaire dtat (State Handler). De plus, le protocole SigComp utilise des rgulateurs de paquets pour envoyer et recevoir les messages. Le compresseur peut utiliser une algorithme connu (Deflate, LZW, etc) ou un algorithme spcifique (EPIC, TCCP, etc). Chaque message est compress indpendamment mais les messages dun flux donn sont compresss avec le mme algorithme. Les algorithmes plus connus feront une meilleure performance puisque le pseudo-code binaire (le pseudo code est le produit dun compilateur pour traduire le code source en langage machine, pour SigComp le pseudo code permet un usage multi-plateformes des logiciels dvelopps qui sont exploitables par la machine virtuelle du dcompresseur) ncessaire pour dcompresser les donnes nest pas envoy au dcompresseur. Les algorithmes de compression de texte peuvent tre bass sur : Un Dictionnaire : LZ, LZ77, TCCB Une Transforme : Huffman, codes arithmtiques, Burrow-Wheeler (BWT), EPIC Un Modle : Prdiction avec une corrlation partielle (PPM) Le choix de lalgorithme reste un paramtre slectionn manuellement pour SigComp. Le compresseur rduit les messages avec lalgorithme choisi et ajoute le pseudo code binaire si ncessaire, le rgulateur de paquets envoie le message compress avec la mise jour du pseudo code binaire pour lalgorithme de dcompression qui sera utilis par la machine virtuelle UDVM (Universal Decompressor Virtual Machine) du dcompresseur. Le compresseur doit sassurer que le dcompresseur a toute linformation ncessaire pour faire la dcompression. Pendant un handover le nouveau dcompresseur doit recevoir linformation ncessaire pour dcompresser les messages. Les messages compresss sont envoys avec une combinaison des instructions dUDVM qui permettent sa dcompression. Le gestionnaire dtats stocke les pseudo codes binaires et les dictionnaires, il peut tre contact par un dcompresseur pour connatre cette information. Sa pleine efficacit est atteinte aprs un nombre de messages compresss, le premier message donne linformation de ltat de lalgorithme utilis. Le dictionnaire peut tre : Statique, Dynamique ou personnalis. Si le dictionnaire est Statique, il peut tre charg hors ligne dans le gestionnaire pour 54
incrmenter la performance ou il peut tre envoyer avec le message compress. Le dictionnaire statique est une collection de caractres bien connus qui sont utiliss dans la plupart de messages SIP/SDP.
Application
Application message & Compartment identifier Decompressed message Compartment identifier
Compressor dispatcher
SIGCOMP
State 1 State Handler
Decompressor dispatcher
Compressor 1
Decompressor (UDVM)
Compressor 2
State 2
SIGCOMP message
SIGCOMP message
Transport Layer
Illustration 32: SIGCOMP Architecture Le dcompresseur utilise une machine virtuelle similaire une machine virtuelle Java, elle sappelle UDVM (Universal Decompressor Virtual Machine) et elle est le noyau de SigComp. Les messages SigComp sont la combinaison de donnes compresses avec les instructions dUDVM. UDVM est optimise pour supporter diffrents algorithmes de compression, elle est flexible et travaille avec le pseudo code envoy par le Compresseur. Un avantage de cette solution est linteroprabilit entre diffrentes implmentations. UDVM a un ensemble de 36 instructions (cf. tableau 5) pour manipuler les diffrents algorithmes de compression : Mathmatiques, de Gestion de Mmoire, de Gestion de Programme et de Entre/Sortie (I/O). La taille du pseudo code varie entre 200 et 300 octets. UDVM najoute pas un dlai supplmentaire au traitement des donnes et nutilise pas plus de mmoire que si on dfinissait un seul algorithme de dcompression. UDVM envoie les donnes dcompresses comme un flux de donnes. Le gestionnaire de messages envoie et reoit les messages entre SigComp et la couche applicative.
Instruction DECOMPRESSION FAILURE AND OR NOT LSHIFT RSHIFT ADD Valeur pseudocode 0 1 2 3 4 5 6 Instruction SUBTRACT MULTIPLY DIVIDE REMAINDER SORTASCENDING SORTDESCENDING SHA1 Valeur pseudocode 7 8 9 10 11 12 13
55
MULTILOAD
56
UDVM est divis en deux parties : la mmoire et le traitement du pseudo code. Il a deux interfaces pour communiquer dans larchitecture, une avec le rgulateur de paquets pour envoyer/recevoir les donnes compresss/dcompresss, et lautre avec le gestionnaire dtat qui lui permet de demander la cration dun tat et daccder a un tat dj cr. Linformation des acquittements est envoye au gestionnaire dtat si le niveau transport est bidirectionnel. La mmoire dans UDVM (cf.. figure 33) a une taille par dfault de 2kilo-octets. Avec des implmentations [42][43][44] on remarque que pour un usage minimaliste, 1kilo- octet est possible pour des algorithmes connus tandis que pour avoir une performance optimale entre 4 8 k octets sont ncessaires pour sauvegarder toute linformation. Les premiers 64 octets sont utiliss pour les variables de dcompression comme : la taille de mmoire, les cycles, la version, la longueur de ltat et le paquet dcompresser. Ensuite il utilise 64 octets pour les variables de la compression comme : la localisation des tats, lordre dentre de bits. Aprs le pseudo code UDVM occupe 128 octets qui sont les instructions UDVM, ensuite entre 256 octets pour le(s) dictionnaire(s) qui sont les diffrents pseudo codes des algorithmes de compression et le reste il peut stocker des paquets (figure 33) prcdents ou les dictionnaires dynamiques ou personnaliss. La mmoire entre 64 octets et 512 octets est sauvegarde aprs la dcompression pour amliorer lindice de compression.
57
len
Cycle par bit (Cycles_per_bit) : Le nombre de cycles disponibles pour dcompresser chaque bit dans le message SigComp. Un autre paramtre est utilis par les instructions UDVM. Version de SigComp (SigComp_version) : Indique si seulement la version de base est disponible ou sil y a une mise jour dans limplmentation Les tats des items disponibles localement (Locally Available State Items) : Ltat des items est une information qui est utilis entre deux messages SigComp pour la dcompression ou pour le dictionnaire. Ils sont crs quand un message a t dcompress avec succs.
Performances de SigComp
Telecom Bretagne a test [45] le mcanisme de compression SigComp sur une communication SIP entre deux ordinateurs, pour connatre le ratio de compression des messages SIP avec les algorithmes plus connus comme : LZ77, LZW, LZSS ou Deflate (cf. tableau 6) et on a trouv que la compression SIGCOMP peut donner jusqu 93,8% de rduction de taille des messages SIP. Cela signifie quil est possible denvoyer 16 fois plus de messages, do une rduction de la bande passante et une optimisation de son utilisation ainsi quune rduction du dlai pour ltablissement dune session dans la tlphonie 3G.
Algorithmede Compression Pourcentagede Compression Ratio
R=Taillesanscompression
Taillecompresse SimpleLZ77 AdaptiveLZ(compress) LZW LZSS DEFLATE(gzip) 55,2 78,64 70,99 82,47 93,8 2.2321 4,6816 3,4470 5,7045 16,1290
Tableau 6: Ratio de Compression pour les messages SIP [45] La figure 35 montre les diffrents messages SIP compresss par les diffrents algorithmes et la taille qui est obtenue.
59
60
Annexe B
Support de RoHC dans la couche de PDCP(3GPP TS 36.323 version 8.5.0)
5.5
Mmoire de fin d'tudes Intgration de RoHC dans l'architecture de LTE M: Mandatory and configured by upper layers.
The usage and definition of the parameters shall be as specified below. MAX_CID (M): This is the maximum CID value that can be used. One CID value shall always be reserved for uncompressed flows. The parameter MAX_CID is configured by upper layers (maxCID [3]). LARGE_CIDS: This value is not configured by upper layers, but rather it is inferred from the configured value of MAX_CID according to the following rule: If MAX_CID > 15 then LARGE_CIDS = TRUE else LARGE_CIDS = FALSE. PROFILES (M): Profiles are used to define which profiles are allowed to be used by the UE. The list of supported profiles is described in section 5.5.1. The parameter PROFILES is configured by upper layers (profiles [3]). FEEDBACK_FOR (N/A): This is a reference to the channel in the opposite direction between two compression endpoints and indicates to what channel any feedback sent refers to. Feedback received on one RoHC channel for this PDCP shall always refer to the RoHC channel in the opposite direction for this same PDCP. MRRU (N/A): RoHC segmentation is not used.
62
RRCConnectionRequest
RRCConnectionSetup
RRCConnectionSetupComplete
RRCConnectionRequest
RRCConnectionReject
Figure 5.3.3.1-2: RRC connection establishment, network reject The purpose of this procedure is to establish an RRC connection. RRC connection establishment involves SRB1 establishment. The procedure is also used to transfer the initial NAS dedicated information/ message from the UE to E-UTRAN. E-UTRAN applies the procedure as follows: to establish SRB1 only.
RRCConnectionReconfiguration
RRCConnectionReconfigurationComplete
63
RRCConnectionReconfiguration
Figure 5.3.5.1-2: RRC connection reconfiguration, failure The purpose of this procedure is to modify an RRC connection, e.g. to establish/ modify/ release RBs, to perform handover, to setup/ modify/ release measurements. As part of the procedure, NAS dedicated information may be transferred from E-UTRAN to the UE.
RRCConnectionReestablishmentRequest RRCConnectionReestablishment
RRCConnectionReestablishmentComplete
RRCConnectionReestablishmentRequest RRCConnectionReestablishmentReject
Figure 5.3.7.1-2: RRC connection re-establishment, failure The purpose of this procedure is to re-establish the RRC connection, which involves the resumption of SRB1 operation and the re-activation of security. A UE in RRC_CONNECTED, for which security has been activated, may initiate the procedure in order to continue the RRC connection. The connection re-establishment succeeds only if the concerned cell is prepared i.e. has a valid UE context. In case EUTRAN accepts the re-establishment, SRB1 operation resumes while the operation of other radio bearers remains suspended. If AS security has not been activated, the UE does not 64
Mmoire de fin d'tudes Intgration de RoHC dans l'architecture de LTE initiate the procedure but instead moves to RRC_IDLE directly. E-UTRAN applies the procedure as follows: to reconfigure SRB1 and to resume data transfer only for this RB; to re-activate AS security without changing algorithms.
RRCConnectionRelease
Figure 5.3.8.1-1: RRC connection release, successful The purpose of this procedure is to release the RRC connection, which includes the release of the established radio bearers as well as all radio resources. .... 5.3.7.4 Actions related to transmission of RRCConnectionReestablishmentRequest message 1> set the reestablishmentCause as follows: 2> if the re-establishment procedure was initiated due to reconfiguration failure as specified in 5.3.5.5 (the UE is unable to comply with the reconfiguration): 3> set the reestablishmentCause to the value reconfigurationFailure; 2> else if the re-establishment procedure was initiated due to handover failure as specified in 5.3.5.6 (intra-LTE handover failure) or 5.4.3.5 (inter-RAT mobility from EUTRA failure): 3> set the reestablishmentCause to the value handoverFailure; 2> else: 3> set the reestablishmentCause to the value otherFailure; PDCP-config (3GPP TS 136 331 V8.5.0) The IE PDCP-Config is used to set the configurable PDCP parameters for data radio bearers. PDCP-Config information element
-- ASN1START PDCP-Config ::= discardTimer } Setup rlc-AM statusReportRequired } Rlc-AM rlc-UM pdcp-SN-Size } Rlc-UM SEQUENCE { ENUMERATED { ms50, ms100, ms150, ms300, ms500, ms750, ms1500, infinity OPTIONAL, SEQUENCE { BOOLEAN OPTIONAL, SEQUENCE { ENUMERATED {len7bits, len12bits} OPTIONAL, -- Cond
-- Cond
-- Cond
65
DEFAULT 15,
PDCP-info (3GPP TS 25.331) 10.3.4.2 PDCP info The purpose of the PDCP info IE is to indicate which algorithms shall be established and to configure the parameters of each of the algorithms.
Information Element/Group name Support for lossless SRNS relocation or for lossless DL RLC PDU size change Max PDCP SN window size Need CVLosslessCr iteria CVMulti Type and reference Boolean Enumerated(s Semantics description TRUE means support Maximum PDCP Versio n
66
MP
>>>F_MAX_PERIOD
MD
Integer (1..65535)
>>>F_MAX_TIME
MD
Integer (1..255)
>>>MAX_HEADER
MD
Integer (60..65535)
>>>TCP_SPACE
MD
Integer (3..255)
>>>NON_TCP_SPACE
MD
Integer (3..65535)
>>>EXPECT_REORDERING
MD
Note 1 Header compression according to IETF standard RFC 2507 Largest number of compressed nonTCP headers that may be sent without sending a full header. Default value is 256. Compressed headers may not be sent more than F_MAX_TIME seconds after sending last full header. Default value is 5. The largest header size in octets that may be compressed. Default value is 168. Maximum CID value for TCP connections. Default value is 15. Maximum CID value for non-TCP connections. Default value is 15. Whether the algorithm shall reorder PDCP SDUs or not. Default value is "reordering not expected".
67
Semantics description Header compression according to IETF standard RFC 3095 >>>Profiles MP 1 to Profiles supported <maxRO by both HCcompressor and Profiles> decompressor in both UE and UTRAN. Profile 0 shall always be supported. >>>>Profile instance MP Integer(1.. 3) 1 = 0x0001, 2 = 0x0002, 3 = 0x0003 (see [52]) >>>Uplink OP Indicates the necessary information elements for Uplink. >>>>Max_CID MD Integer (1.. Highest context ID 16383) number to be used by the UE compressor. Default value is 15. >>>Downlink OP Indicates the necessary information elements for Downlink. >>>>Max_CID MD Integer (1.. Highest context ID 16383) number to be used by the UE decompressor. Default value is 15. >>>>Reverse_Decompression_ MD Integer Determines Depth (0..65535) whether reverse decompression should be used or not and the maximum number of packets that can be reverse decompressed by the UE decompressor. Default value is 0 (reverse decompression shall not be used). Note 1: If several occurrences of the same algorithm type are included in the same IE 'header compression information', the UE behaviour is unspecified. Condition LosslessCriteria
REL-4
REL-4 REL-4
REL-4
REL-4
REL-4
REL-4
Explanation This IE is mandatory present if the IE "RLC mode" is "Acknowledged", the IE "In-sequence delivery " is TRUE and the IE "SDU Discard Mode" is "No discard"
68
10.3.4.2a
10.3.4.3
PDCP SN info
Need MP Multi Type and Reference Integer(0..65 535) Semantics description The PDCP sequence number, which the sender of the message is expecting next to be received.
1> set the PROFILES parameter, used by inband RoHC profile negotiation, for this PDCP entity for both UL and DL equal to the list of RoHC profiles received in the IE "PDCP info". A UE complying to this version of the protocol shall support RoHC profiles 0x0000 (RoHC uncompressed), 0x0001 (RoHC RTP), 0x0002 (RoHC UDP) and 0x0003 (RoHC ESP) (see [52]). Support de RoHC dans l'UE (3GPP TS 36.306 V8.3.0)
A UE that supports one or more of the listed RoHC profiles shall support RoHC profile 0x0000 RoHC uncompressed (RFC 4995). 'IMS capable UEs supporting voice' shall support RoHC profiles 0x0000, 0x0001, 0x0002,
69
0x0004. 4.3.1.2 Maximum number of RoHC context sessions This parameter defines the maximum number of header compression context sessions supported by the UE, excluding context sessions that leave all headers uncompressed. UE-EUTRA-Capability The IE UE-EUTRA-Capability is used to convey the E-UTRA UE Radio Access Capability Parameters, see TS 36.306 [5], to the network. The IE UE-EUTRA-Capability is transferred in E-UTRA or in another RAT. UE-EUTRA-Capability information element
-- ASN1START UE-EUTRA-Capability ::= accessStratumRelease ue-Category pdcp-Parameters phyLayerParameters rf-Parameters measParameters featureGroupIndicators interRAT-Parameters utraFDD utraTDD128 utraTDD384 utraTDD768 geran cdma2000-HRPD cdma2000-1xRTT }, nonCriticalExtension } AccessStratumRelease ::= SEQUENCE { AccessStratumRelease, INTEGER (1..5), PDCP-Parameters, PhyLayerParameters, RF-Parameters, MeasParameters, BIT STRING (SIZE (32)) SEQUENCE { IRAT-ParametersUTRA-FDD IRAT-ParametersUTRA-TDD128 IRAT-ParametersUTRA-TDD384 IRAT-ParametersUTRA-TDD768 IRAT-ParametersGERAN IRAT-ParametersCDMA2000-HRPD IRAT-ParametersCDMA2000-1XRTT SEQUENCE {}
ENUMERATED { rel8, spare7, spare6, spare5, spare4, spare3, spare2, spare1, ...} SEQUENCE { SEQUENCE { BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN ENUMERATED { cs2, cs4, cs8, cs12, cs16, cs24, cs32, cs48, cs64, cs128, cs256, cs512, cs1024, cs16384, spare2, spare1} DEFAULT
PDCP-Parameters ::= supportedROHC-Profiles profile0x0001 profile0x0002 profile0x0003 profile0x0004 profile0x0006 profile0x0101 profile0x0102 profile0x0103 profile0x0104 }, maxNumberROHC-ContextSessions
cs16, ... } PhyLayerParameters ::= ue-TxAntennaSelectionSupported ue-SpecificRefSigsSupported } RF-Parameters ::= supportedBandListEUTRA } SupportedBandListEUTRA ::=
70
OPTIONAL
SEQUENCE (SIZE (1..maxBands)) OF InterFreqBandInfo SEQUENCE { BOOLEAN SEQUENCE (SIZE (1..maxBands)) OF InterRAT-BandInfo SEQUENCE { BOOLEAN SEQUENCE { SupportedBandListUTRA-FDD SEQUENCE (SIZE (1..maxBands)) OF SupportedBandUTRA-FDD ENUMERATED { bandI, bandII, bandIII, bandIV, bandV, bandVI, bandVII, bandVIII, bandIX, bandX, bandXI, bandXII, bandXIII, bandXIV, bandXV, bandXVI, ...} SEQUENCE { SupportedBandListUTRA-TDD128 SEQUENCE (SIZE (1..maxBands)) OF SupportedBandUTRA-TDD128 ENUMERATED { a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...} SEQUENCE { SupportedBandListUTRA-TDD384 SEQUENCE (SIZE (1..maxBands)) OF SupportedBandUTRA-TDD384 ENUMERATED { a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...} SEQUENCE { SupportedBandListUTRA-TDD768 SEQUENCE (SIZE (1..maxBands)) OF SupportedBandUTRA-TDD768 ENUMERATED { a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...} SEQUENCE { SupportedBandListGERAN,
71
SEQUENCE (SIZE (1..maxBands)) OF SupportedBandGERAN ENUMERATED { gsm450, gsm480, gsm710, gsm750, gsm810, gsm850, gsm900P, gsm900E, gsm900R, gsm1800, gsm1900, spare5, spare4, spare3, spare2, spare1, ...} SEQUENCE { SupportedBandListHRPD, ENUMERATED {single, dual}, ENUMERATED {single, dual} SEQUENCE (SIZE (1..maxCDMA-BandClass)) OF SEQUENCE { SupportedBandList1XRTT, ENUMERATED {single, dual}, ENUMERATED {single, dual} SEQUENCE (SIZE (1..maxCDMA-BandClass)) OF
IRAT-ParametersCDMA2000-HRPD ::= supportedBandListHRPD tx-ConfigHRPD rx-ConfigHRPD } SupportedBandListHRPD ::= BandclassCDMA2000 IRAT-ParametersCDMA2000-1XRTT ::= supportedBandList1XRTT tx-Config1XRTT rx-Config1XRTT } SupportedBandList1XRTT ::= BandclassCDMA2000 -- ASN1STOP
72