DSpace at VNU: Utilisation de la compression des entêtes dans les réseaux cellulaires de type 4G (LTE SAE) vu dinh dau

DSpace at VNU: Utilisation de la compression des entêtes dans les réseaux cellulaires de type 4G (LTE SAE) vu dinh dau t...

NEXTTV4ALL Mémoire de fin d’études Master Informatique, option Systèmes et Réseaux Utilisation de la compression des entêtes dans les réseaux cellulaires de type 4G (LTE/SAE) Réalisé par : VU DINH Dau Promotion 13, IFI Loutfi NUAYMI TELECOM Bretagne Sous la direction de : Xavier LE BOURDON JCP-Consult 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 Introduction 1.1 Contexte 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 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 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 É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 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 Conclusion et perspectives 51 Bibliographie 52 Annexe A 54 Annexe B 61 Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13, IFI Remerciements Je tiens tout d’abord remercier Loutfi NUYAMI qui a suivi mon travail théorique concernant l'architecture des réseaux cellulaires, et la recherche dans la grande quantité de documents de 3GPP Il m'a donné également des conseils sur la méthodologie de recherche Je souhaite également remercier Xavier LE BOURDON Il a été la fois mon ami qui m'a aidé l'adaptation la vie en France et mon superviseur qui m'a donné des conseils sur le travail pratique concernant les tests de performance de RoHC Je voudrais aussi remercier Ana Carolina MINABURO qui a sélectionné ma candidature de stage, et donné fréquemment des commentaires forts utiles sur mon travail Je voudrais remercier Eric Poilvet qui m'a donné des conseils sur l'architecture de UMTS Je voudrais remercier Michel BADET qui a travaillé en coopération avec moi pour localiser et corriger des anomalies de performance de RoHCv1 Je voudrais également remercier Thomas Lefort qui m'a aidé sur la partie concernant RoHCv2 Je tiens remercier Jean-Marie BONNIN et Stéphane ROLLAND qui m'ont donné des conseils sur le plan de travail Je voudrais remercier Jean-Charles Point qui a financé pour mon stage, et donné un environnement professionnel favorable mon travail Enfin, je voudrais remercier mon professeur l'Institut de la Francophonie d'Informatique (IFI) qui n'ont donné des cours de réseaux afin d'avoir les connaissances de base pour réaliser ce stage Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13, IFI Résumé LTE (Long Term Evolution) est la dernière évolution d'une série de technologies cellulaires sans-fil GSM/UMTS/HSPA, en compétition pour être la norme de la quatrième génération de réseau mobile (4G) Les innovations au niveau de l'interface radio et de l'architecture « plate et tout-IP » permettent de réduire le délai d'accès et d'enrichir des services multimédia comme les services de télévision sur IP haut débit La compression d'entêtes RoHC (Robust Header Compression) est une technologie présente dans LTE l'interface radio où la bande passante est limitée et coûteuse RoHC permet de réduire la taille des paquets IP des applications multimédia dans lesquels la taille de payload est souvent petite par rapport la taille d'entête La deuxième version de RoHC (RoHCv2) simplifie l'implémentation de RoHC et améliore la performance dans le cas de handover Elle est prise en compte dans l'architecture de LTE Dans ce document, nous analysons l'architecture de LTE afin de conntre l'intégration de RoHC dans ce système Nos études montrent que RoHC prend place au niveau de la souscouche PDCP, et que les profils de RoHCv1 et de RoHCv2 sont prévus Nous étudions également le support de RoHC par LTE dans le cas de handover et dans les services de broadcast/multicast Le deuxième axe de travail fut une campagne de tests sur l'implémentation de JCP-Consult Elle montre que RoHC est très robuste contre des erreurs sur le lien radio, et peut réduire le taux de perte de paquets dans le cas de handover RoHC permet d'économiser environ 40% de bande passante pour les applications audio et environ 10% de bande passante pour les applications vidéo Cependant, RoHC introduit un phénomène de gigue au niveau applicatif Mots clés : réseau cellulaire, 4G, LTE, UMTS, PDCP, compression des entêtes RoHC, RoHCv2, IPTV Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13, IFI 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 Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13, 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 ATM Adaptation Layer 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 Message Transfer Part level MTP3B broadband NAS Non Access Spectrum Next Generation Mobile NGMN Networks Alliance Orthogonal Frequency Division OFDMA Multiple Access P-CSCF Proxy CSCF P-GW Packet Data Network Gateway PAPR Peak-to-Average Power Ratio Policy Control and Charging PCRF Rules Function Packet Data Convergence PDCP Protocol PS Packet Switched Public Switched Telephone PSTN Network Radio Access Network RANAP Application Part RLC Radio Layer Control RNC Radio Network Control RoHC Robust Header Compression RRC Radio Ressource Control S-GW Serving Gateway SAE System Architecture Evolution Single Carrier - Frequency SC-FDMA Division Multiple Access Signalling Connection Control SCCP Part SFN Single Frequency Network SIGCOMP Signaling Compression SIP Session Initiation Protocol SRAN Satellite Radio Access Network TDD Time Division Duplex Universal Decompressor Virtual UDVM Machine UE User Equipment UMB Ultra Mobile Broadband Universal Mobile UMTS Telecommunications System Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13, 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, le vert présente le débit que l'on espère, source : [5]) 14 Illustration 2: Architecture de l'UMTS (release 99) 16 Illustration 3: Architecture de l'UMTS (release 5) 17 Ilustration 4: L'architecture protocolaire de l'UMTS dans le plan de contrôle (domaine de PS, release 5) 17 Illustration 5: L'architecture protocolaire de l'UMTS dans le plan d'utilisateur (release 5) 19 llustration 6: L'architecture générale du réseau LTE 22 Illustration 7: La différence entre eNodeB (LTE) et NodeB (HSPA) au plan utilisateur [15] 24 Illustration 8: Plan contrôle en couches [16] 25 Illustration 9: Plan utilisateur 26 Illustration 10: La deuxième couche de l'interface radio au sens descendant [16] 27 Illustration 11: La fonction de la couche PDCP [17] 28 Illustration 12: Procédure pour configurer et déclencher RoHC dans l'interface radio 35 Illustration 13: Modèle d'évaluation de performance de RoHC .40 Illustration 14: Pre-tests, le nombre maximal de paquets perdus est très haut dans O-mode 42 Illustration 15: Bande passante économique dans U-mode et BER = 0.0 avec des flux différents 43 Illustration 16: Taux de bande passante économisée VoIP AMR 12,2 kbps 45 Illustration 17: Taux de bande passante économisée VoIP AMR 23 kbps .45 Illustration 18: Taux de bande passante économisée Video H264 haute qualité 45 Illustration 19: Taux de bande passante économisée Vidéo H264 moyenne qualité 45 Illustration 20: Taux de paquets perdus VoIP AMR 12,2 kbps 47 Illustration 21:Taux de paquets perdus VoIP AMR 23 kbps 47 Illustration 22: Taux de paquets perdus Video H264 haute qualité 47 Illustration 23: Taux de paquets perdus Vidéo H264 moyenne qualité 47 Illustration 24: Nombre maximal de paquets perdus successifs VoIP AMR 12,2 kbps 48 Illustration 25: Nombre maximal de paquets perdus successifs VoIP AMR 23 kbps 48 Illustration 26: Nombre maximal de paquets perdus successifs Video H264 haute qualité 48 Illustration 27: Nombre maximal de paquets perdus successifs Vidéo H264 moyenne qualité 48 Illustration 28: Taux de bande passante économisée VoIP 12,2kbps .50 Illustration 29: Taux de paquets perdus VoIP 12,2kbps 50 Illustration 30: Nombre maximal de paquets perdus successifs VoIP 12,2kbps 50 Illustration 31: Pile protocolaire avec la compression 55 Illustration 32: SIGCOMP Architecture 56 Illustration 33: La mémoire d’UDVM 58 Illustration 34: Format of a SIGCOMP message 58 Illustration 35: Compression SigComp 60 Index des tables Tableau 1: Les profils supportés par LTE [17] .33 Tableau 2: Les paramètres sont définis par la couche supérieure de PDCP[17] 34 Tableau 3: Les différents flux pour évaluer la performance de RoHC 41 Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13, IFI Tableau 4: Des anomalies de performance de RoHC de JCP-Consult 42 Tableau 5: Instructions d’UDVM et les valeurs de pseudo code 57 Tableau 6: Ratio de Compression pour les messages SIP [45] .59 Introduction 1.1 Contexte Mon stage de fin d'études s’est déroulé sur une période de mois JCP-Consult, en coopération avec TELECOM Bretagne, dans le carde du projet NextTV4All du 16 Mars au 15 Septembre 2009 Le projet NextTV4All (Next TV for all: télévision venir pour tous) est un projet du Pơle Images & Réseaux, et s’inscrit dans le thème « télévision sur IP basé sur IMS » dans un environnement de convergence fixe-mobile Le projet prend en compte les interactions entre les services audiovisuels interpersonnels et conversationnels et les services de IPTV[annexe du projet] Les partenaires du projet sont: Alcatel Lucent, Devoteam, France Télécom, IRISA/Université de Rennes 1, JCP Consult, Le Télégramme, Neotilus, NEXCOM Systems, TELECOM Bretagne, Thomson Grass Valley, Thomson R&D France, Thomson Telecom JCP-Consult est une PME, située Cesson-Sévigné, dans la périphérie de la ville de Rennes, dont le domaine d'activité se présente selon les deux axes suivants :  Expertise, standardisation et montage de projets de Recherche et Développement, notamment concernant les projets de recherches européens ;  Le développement de piles de protocole réseaux, notamment les protocoles de compression des entêtes RoHC Dans le projet NextTV4all, JCP-Consult participe l'étude de la qualité de service « inter-couches », c'est-à-dire la corrélation entre métadonnées associées au contenu, signalisation, réservation de ressource et couche MAC Cette entreprise participe également l'étude des protocoles RoHCv1 et RoHCv2 au sein des architectures du projet (IMS, LTE) Enfin, elle implémente une pile RoHCv2 afin d'étudier les qualités et les défauts de ce protocole TELECOM Bretagne est une Grande École d'ingénieur généraliste et un centre de recherche international dans les sciences et technologies de l'information Le département de recherche RSM (Réseau, Sécurité et Multimédia) de TELECOM Bretagne Rennes est actif Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13, IFI dans l’enseignement et la recherche sur les réseaux et en particulier sur la qualité de service et les nouvelles architectures Le département est actuellement impliqué dans plusieurs projets portant entre autres sur la QoS et les NGN (Next Generation Network), est membre du réseau d’excellence EuroFGI et participe la standardisation de l’Internet l’IETF Dans le projet, une des contributions de TELECOM Bretagne est de réaliser des études sur la standardisation de RoHCv2 Mon stage fut encadré en partenariat avec ces deux entreprises :  Loutfi Nuyami, mtre de conférences de TELECOM Bretagne, a suivi le travail théorique concernant des normes de 3GPP, en particulier, l'architecture de LTE  Xavier Le Bourdon, ingénieur de recherche de JCP-Consult, a suivi le travail pratique concernant les tests de la performance de RoHC 1.2 Problématique L'évolution des technologies pour réseaux mobiles (2G, HSPDA) et maintenant LTE offrent des débits de plus en plus importants atteignant jusqu'à 100Mbps Ces débits permettent alors l'accès aux services multimédia sur téléphone mobile Au-delà des technologies de transport, LTE est basé sur un architecture « plate et tout-IP » Cette évolution simplifie l'intégration avec l'architecture IMS qui permet l'inter-fonctionnement entre tous types de réseaux (fixe, mobile, sans fil) La taille des paquets dans les flux multimédias associés la voix ou la vidéo est petite (20 60 octets); l'encapsulation RTP/UDP/IP utilisée représente donc une part importante du paquet (40 octets pour IPv4 et 60 octet pour IPv6), la compression d'en-tête RoHC (RObust Header Compression, défini dans le RFC3095 de l'IETF) permet donc une augmentation très importante de la capacité du réseau dans le cas de flux multimédias interactifs De plus RoHC a été adopté dans la release de l'UMTS La première version, RoHCv1 (RFC 3095), est d’ores et déjà incluse dans les systèmes de téléphonie en cours de déploiement Une seconde version de RoHCv2 (RFC 5225) est actuellement en phase de conception Elle prend en compte des déséquencements de paquets entre compresseur et décompresseur, par exemple pour compresser les tunnels IP dans le cadre de la mobilité Elle apportent également des simplifications pour RoHCv1 3GPP a prévu d’intégrer cette version dans les futures architectures LTE Le projet NextTV4All a pour objectif de préparer les futurs services multimédia des 10 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 Les messages SigComp doivent indiquer l’algorithme de compression utilisé et toute l’information nécessaire pour la décompression Cette information peut faire partie du message SigComp ou elle peut être connue comme dans les états d’items disponibles dans la mémoire Les deux types des messages (cf figure 34) sont différenciés par le premier octet 0                  1 1 T 0                  len 1 1 T returned feedback item returned feedback item partial state identifier code_len remaining SIGCOMP message 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, une série de paramètres est utilisée pour modifier les comportements de la compression quand les capacités des paires sont très différentes : •Taille de mémoire de décompression (Decompression_memory_size) : donne la taille de mémoire disponible pour la décompression de messages SigComp •Etat de la taille de mémoire (State_memory_size) : Donne le nombre d’octets pour la création d’un état, Zero si la configuration est sans état 58 Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13, IFI •Cycle par bit (Cycles_per_bit) : Le nombre de cycles disponibles pour décompresser chaque bit dans le message SigComp Un autre paramètre est utilisé par les instructions UDVM •Version de SigComp (SigComp_version) : Indique si seulement la version de base est disponible ou s’il y a une mise jour dans l’implémentation •Les états des items disponibles localement (Locally Available State Items) : L’état des items est une information qui est utilisé entre deux messages SigComp pour la décompression ou pour le dictionnaire Ils sont créés quand un message a été décompressé avec succès Performances de SigComp Telecom Bretagne a testé [45] le mécanisme de compression SigComp sur une communication SIP entre deux ordinateurs, pour conntre le ratio de compression des messages SIP avec les algorithmes plus connus comme : LZ77, LZW, LZSS ou Deflate (cf tableau 6) et on a trouvé que la compression SIGCOMP peut donner jusqu’à 93,8% de réduction de taille des messages SIP Cela signifie qu’il est possible d’envoyer 16 fois plus de messages, d’où une réduction de la bande passante et une optimisation de son utilisation ainsi qu’une réduction du délai pour l’établissement d’une session dans la téléphonie 3G Algorithme de  Compression Pourcentage de  Compression Ratio R= Taille sans compression Taille compressée Simple LZ77 55,2 2.2321 Adaptive LZ (compress) 78,64 4,6816 LZW 70,99 3,4470 LZSS 82,47 5,7045 DEFLATE (gzip) 93,8 16,1290 Tableau 6: Ratio de Compression pour les messages SIP [45] La figure 35 montre les différents messages SIP compressés par les différents algorithmes et la taille qui est obtenue 59 Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE Illustration 35: Compression SigComp 60 VU DINH Dau Promotion 13, IFI Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13, IFI Annexe B Support de RoHC dans la couche de PDCP(3GPP TS 36.323 version 8.5.0) 5.5 Header Compression and Decompression 5.5.1 Supported header compression protocols and profiles The header compression protocol is based on the Robust Header Compression (RoHC) framework [7] There are multiple header compression algorithms, called profiles, defined for the RoHC framework Each profile is specific to the particular network layer, transport layer or upper layer protocol combination e.g TCP/IP and RTP/UDP/IP The detailed definition of the RoHC channel is specified as part of the RoHC framework in RFC 4995 [7] This includes how to multiplex different flows (header compressed or not) over the RoHC channel, as well as how to associate a specific IP flow with a specific context state during initialization of the compression algorithm for that flow The implementation of the functionality of the RoHC framework and of the functionality of the supported header compression profiles is not covered in this specification In this version of the specification the support of the following profiles is described: Table 5.5.1.1: Supported header compression protocols and profiles Profile Usage: Reference Identifier 0x0000 No compression RFC 4995 0x0001 RTP/UDP/IP RFC 3095, RFC 4815 0x0002 UDP/IP RFC 3095, RFC 4815 0x0003 ESP/IP RFC 3095, RFC 4815 0x0004 IP RFC 3843, RFC 4815 0x0006 TCP/IP RFC 4996 0x0101 RTP/UDP/IP RFC 5225 0x0102 UDP/IP RFC 5225 0x0103 ESP/IP RFC 5225 0x0104 IP RFC 5225 5.5.2 Configuration of header compression PDCP entities associated with DRBs can be configured by upper layers [3] to use header compression 5.5.3 Protocol parameters RFC 4995 has configuration parameters that are mandatory and that must be configured by upper layers between compressor and decompressor peers [7]; these parameters define the RoHC channel The RoHC channel is a unidirectional channel, i.e there is one channel for the downlink, and one for the uplink There is thus one set of parameters for each channel, and the same values shall be used for both channels belonging to the same PDCP These parameters are categorized in two different groups, as defined below: 61 Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE - M: - N/A: Not used in this specification VU DINH Dau Promotion 13, IFI 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 5.5.4 Header compression The header compression protocol generates two types of output packets: compressed packets, each associated with one PDCP SDU standalone packets not associated with a PDCP SDU, i.e interspersed RoHC feedback packets A compressed packet is associated with the same PDCP SN and COUNT value as the related PDCP SDU Interspersed RoHC feedback packets are not associated with a PDCP SDU They are not associated with a PDCP SN and are not ciphered 5.5.5 Header decompression If header compression is configured by upper layers for PDCP entities associated with uplane data the PDCP PDUs are de-compressed by the header compression protocol after performing deciphering as explained in the subclause 5.6 Les procédures de la couche de RRC (3GPP TS 136 331 V8.5.0) 5.3.3 RRC connection establishment 5.3.3.1 General 62 Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE UE VU DINH Dau Promotion 13, IFI EUTRAN RRCConnectionRequest RRCConnectionSetup RRCConnectionSetupComplete Figure 5.3.3.1-1: RRC connection establishment, successful UE EUTRAN RRCConnectionRequest RRCConnectionReject Figure 5.3.3.1-2: RRC connection establishment, network reject The purpose of this procedure is to establish an RRC connection RRC connection establishment involves SRB1 establishment The procedure is also used to transfer the initial NAS dedicated information/ message from the UE to E-UTRAN E-UTRAN applies the procedure as follows: – to establish SRB1 only 5.3.5 RRC connection reconfiguration 5.3.5.1 General UE EUTRAN RRCConnectionReconfiguration RRCConnectionReconfigurationComplete Figure 5.3.5.1-1: RRC connection reconfiguration, successful 63 Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE UE VU DINH Dau Promotion 13, IFI EUTRAN RRCConnectionReconfiguration RRC connection re-establishment Figure 5.3.5.1-2: RRC connection reconfiguration, failure The purpose of this procedure is to modify an RRC connection, e.g to establish/ modify/ release RBs, to perform handover, to setup/ modify/ release measurements As part of the procedure, NAS dedicated information may be transferred from E-UTRAN to the UE 5.3.7 RRC connection re-establishment 5.3.7.1 General UE EUTRAN RRCConnectionReestablishmentRequest RRCConnectionReestablishment RRCConnectionReestablishmentComplete Figure 5.3.7.1-1: RRC connection re-establishment, successful UE EUTRAN RRCConnectionReestablishmentRequest RRCConnectionReestablishmentReject Figure 5.3.7.1-2: RRC connection re-establishment, failure The purpose of this procedure is to re-establish the RRC connection, which involves the resumption of SRB1 operation and the re-activation of security A UE in RRC_CONNECTED, for which security has been activated, may initiate the procedure in order to continue the RRC connection The connection re-establishment succeeds only if the concerned cell is prepared i.e has a valid UE context In case EUTRAN accepts the re-establishment, SRB1 operation resumes while the operation of other radio bearers remains suspended If AS security has not been activated, the UE does not 64 Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13, IFI initiate the procedure but instead moves to RRC_IDLE directly E-UTRAN applies the procedure as follows: to reconfigure SRB1 and to resume data transfer only for this RB; – to re-activate AS security without changing algorithms 5.3.8 RRC connection release 5.3.8.1 General UE EUTRAN RRCConnectionRelease Figure 5.3.8.1-1: RRC connection release, successful The purpose of this procedure is to release the RRC connection, which includes the release of the established radio bearers as well as all radio resources 5.3.7.4 Actions related to transmission of RRCConnectionReestablishmentRequest message 1> set the reestablishmentCause as follows: 2> if the re-establishment procedure was initiated due to reconfiguration failure as specified in 5.3.5.5 (the UE is unable to comply with the reconfiguration): 3> set the reestablishmentCause to the value ‘reconfigurationFailure’; 2> else if the re-establishment procedure was initiated due to handover failure as specified in 5.3.5.6 (intra-LTE handover failure) or 5.4.3.5 (inter-RAT mobility from EUTRA failure): 3> set the reestablishmentCause to the value ‘handoverFailure’; 2> else: 3> set the reestablishmentCause to the value ‘otherFailure’; PDCP-config (3GPP TS 136 331 V8.5.0) The IE PDCP-Config is used to set the configurable PDCP parameters for data radio bearers PDCP-Config information element ASN1START PDCP-Config ::= discardTimer } Setup rlc-AM statusReportRequired } Rlc-AM rlc-UM pdcp-SN-Size } Rlc-UM SEQUENCE { ENUMERATED { ms50, ms100, ms150, ms300, ms500, ms750, ms1500, infinity OPTIONAL, Cond SEQUENCE { BOOLEAN OPTIONAL, SEQUENCE { ENUMERATED {len7bits, len12bits} OPTIONAL, 65 Cond Cond 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 }, } }, VU DINH Dau Promotion 13, IFI CHOICE { NULL, SEQUENCE { INTEGER (1 16383) SEQUENCE { BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN DEFAULT 15, } ASN1STOP PDCP-Config field descriptions discardTimer Indicates the discard timer value specified in TS 36.323 [8] Value in milliseconds Value ms50 means 50 ms, ms100 means 100 ms and so on statusReportRequired Indicates whether or not the UE shall send a PDCP Status Report upon re-establishment of the PDCP entity as specified in TS 36.323 [8] pdcp-SN-Size Indicates the PDCP Sequence Number length in bits Value len7bits means that the 7-bit PDCP SN format is used and len12bits means that the 12-bit PDCP SN format is used, as specified in TS 36.323 [8] maxCID Indicates the value of the MAX_CID parameter as specified in TS 36.323 [8] profiles The profiles used by both compressor and decompressor in both UE and E-UTRAN The field indicates which of the RoHC profiles specified in TS 36.323 [8] are supported, i.e value 'true' indicates that the profile is supported Profile 0x0000 shall always be supported when the use of RoHC is configured If support of two RoHC profile identifiers with the same LSB’s is signalled, only the profile corresponding to the highest value shall be applied Conditional presence Setup Rlc-AM Rlc-UM Explanation The field is mandatory present in case of radio bearer setup Otherwise the field is not present The field is mandatory present upon setup of a PDCP entity for a radio bearer configured with RLC AM The field is optional, need ON, in case of reconfiguration of a PDCP entity at handover for a radio bearer configured with RLC AM Otherwise the field is not present The field is mandatory present upon setup of a PDCP entity for a radio bearer configured with RLC UM Otherwise the field is not present PDCP-info (3GPP TS 25.331) 10.3.4.2 PDCP info The purpose of the PDCP info IE is to indicate which algorithms shall be established and to configure the parameters of each of the algorithms Information Element/Group name Support for lossless SRNS relocation or for lossless DL RLC PDU size change Max PDCP SN window size Need Multi CVLosslessCr iteria CV- 66 Type and reference Boolean Semantics description TRUE means support Enumerated(s Maximum PDCP Versio n Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE Information Element/Group name Need VU DINH Dau Promotion 13, IFI Multi Lossless Type and reference n255, sn65535) PDCP PDU header MP Enumerated (present, absent) Header compression information OP >CHOICE algorithm type >>RFC 2507 MP >>>F_MAX_PERIOD MD Integer (1 65535) >>>F_MAX_TIME MD Integer (1 255) >>>MAX_HEADER MD Integer (60 65535) >>>TCP_SPACE MD Integer (3 255) >>>NON_TCP_SPACE MD Integer (3 65535) >>>EXPECT_REORDERING MD Enumerated (reordering not expected, reordering expected) Semantics description sequence number window size The handling of sequence number when the Max PDCP SN window size is 255 is specified in [23] Whether a PDCP PDU header is existent or not to 67 Note 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 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" Versio n Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE Information Element/Group name >>RFC 3095 Need VU DINH Dau Promotion 13, IFI Multi Semantics description Header compression according to IETF standard RFC 3095 >>>Profiles MP to Profiles supported decompressor in both UE and UTRAN Profile shall always be supported >>>>Profile instance MP Integer(1 3) = 0x0001, = 0x0002, = 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 (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 Type and reference Versio n REL-4 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" LosslessCriteria 68 Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13, IFI and not needed otherwise This IE is mandatory present if the IE "Support for lossless SRNS relocation or for lossless RLC PDU size change" Is TRUE, otherwise it is not needed Lossless 10.3.4.2a PDCP RoHC target mode Information Element/Group name Target Mode 10.3.4.3 Need Multi MP Type and Reference Enumerated (O-mode, Rmode) Semantics description The UE shall only transit to the signalled mode for operation of RoHC as decribed in [36] Version REL-5 PDCP SN info Information Element/Group name Receive PDCP sequence number Need Multi MP 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) 4.3.1 PDCP Parameters 4.3.1.1 Supported RoHC profiles This parameter defines which RoHC profiles from the list below are supported by the UE 0x0000 RoHC uncompressed (RFC 4995) - 0x0001 RoHC RTP (RFC 3095, RFC 4815) - 0x0002 RoHC UDP (RFC 3095, RFC 4815) - 0x0003 RoHC ESP (RFC 3095, RFC 4815) - 0x0004 RoHC IP (RFC 3843, RFC 4815) - 0x0006 RoHC TCP (RFC 4996) - 0x0101 ROHCv2 RTP (RFC 5225) - 0x0102 ROHCv2 UDP (RFC 5225) - 0x0103 ROHCv2 ESP (RFC 5225) - 0x0104 ROHCv2 IP (RFC 5225) A UE that supports one or more of the listed RoHC profiles shall support RoHC profile 0x0000 RoHC uncompressed (RFC 4995) 'IMS capable UEs supporting voice' shall support RoHC profiles 0x0000, 0x0001, 0x0002, 69 Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13, IFI 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 } 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 AccessStratumRelease ::= ENUMERATED { rel8, spare7, spare6, spare5, spare4, spare3, spare2, spare1, } PDCP-Parameters ::= supportedROHC-Profiles profile0x0001 profile0x0002 profile0x0003 profile0x0004 profile0x0006 profile0x0101 profile0x0102 profile0x0103 profile0x0104 }, maxNumberROHC-ContextSessions SEQUENCE { SEQUENCE { BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN, BOOLEAN cs16, } SEQUENCE {} OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL OPTIONAL ENUMERATED { cs2, cs4, cs8, cs12, cs16, cs24, cs32, cs48, cs64, cs128, cs256, cs512, cs1024, cs16384, spare2, spare1} DEFAULT PhyLayerParameters ::= ue-TxAntennaSelectionSupported ue-SpecificRefSigsSupported } SEQUENCE { BOOLEAN, BOOLEAN RF-Parameters ::= supportedBandListEUTRA } SEQUENCE { SupportedBandListEUTRA SupportedBandListEUTRA ::= SEQUENCE (SIZE (1 maxBands)) OF SupportedBandEUTRA 70 Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE VU DINH Dau Promotion 13, IFI SupportedBandEUTRA ::= bandEUTRA halfDuplex } SEQUENCE { INTEGER (1 64), BOOLEAN MeasParameters ::= bandListEUTRA } SEQUENCE { BandListEUTRA BandListEUTRA ::= SEQUENCE (SIZE (1 maxBands)) OF BandInfoEUTRA BandInfoEUTRA ::= interFreqBandList interRAT-BandList } SEQUENCE { InterFreqBandList, InterRAT-BandList InterFreqBandList ::= SEQUENCE (SIZE (1 maxBands)) OF InterFreqBandInfo InterFreqBandInfo ::= interFreqNeedForGaps } SEQUENCE { BOOLEAN InterRAT-BandList ::= SEQUENCE (SIZE (1 maxBands)) OF InterRAT-BandInfo InterRAT-BandInfo ::= interRAT-NeedForGaps } SEQUENCE { BOOLEAN IRAT-ParametersUTRA-FDD ::= supportedBandListUTRA-FDD } SEQUENCE { SupportedBandListUTRA-FDD SupportedBandListUTRA-FDD ::= SEQUENCE (SIZE (1 maxBands)) OF SupportedBandUTRA-FDD SupportedBandUTRA-FDD ::= ENUMERATED { bandI, bandII, bandIII, bandIV, bandV, bandVI, bandVII, bandVIII, bandIX, bandX, bandXI, bandXII, bandXIII, bandXIV, bandXV, bandXVI, } IRAT-ParametersUTRA-TDD128 ::= supportedBandListUTRA-TDD128 } SEQUENCE { SupportedBandListUTRA-TDD128 SupportedBandListUTRA-TDD128 ::= SEQUENCE (SIZE (1 maxBands)) OF SupportedBandUTRA-TDD128 SupportedBandUTRA-TDD128 ::= ENUMERATED { a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, } IRAT-ParametersUTRA-TDD384 ::= supportedBandListUTRA-TDD384 } SEQUENCE { SupportedBandListUTRA-TDD384 SupportedBandListUTRA-TDD384 ::= SEQUENCE (SIZE (1 maxBands)) OF SupportedBandUTRA-TDD384 SupportedBandUTRA-TDD384 ::= ENUMERATED { a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, } IRAT-ParametersUTRA-TDD768 ::= supportedBandListUTRA-TDD768 } SEQUENCE { SupportedBandListUTRA-TDD768 SupportedBandListUTRA-TDD768 ::= SEQUENCE (SIZE (1 maxBands)) OF SupportedBandUTRA-TDD768 SupportedBandUTRA-TDD768 ::= ENUMERATED { a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, } IRAT-ParametersGERAN ::= supportedBandListGERAN SEQUENCE { SupportedBandListGERAN, 71 OPTIONAL Mémoire de fin d'études Intégration de RoHC dans l'architecture de LTE interRAT-PS-HO-ToGERAN VU DINH Dau Promotion 13, IFI BOOLEAN } SupportedBandListGERAN ::= SEQUENCE (SIZE (1 maxBands)) OF SupportedBandGERAN SupportedBandGERAN ::= ENUMERATED { gsm450, gsm480, gsm710, gsm750, gsm810, gsm850, gsm900P, gsm900E, gsm900R, gsm1800, gsm1900, spare5, spare4, spare3, spare2, spare1, } IRAT-ParametersCDMA2000-HRPD ::= supportedBandListHRPD tx-ConfigHRPD rx-ConfigHRPD } SEQUENCE { SupportedBandListHRPD, ENUMERATED {single, dual}, ENUMERATED {single, dual} SupportedBandListHRPD ::= BandclassCDMA2000 SEQUENCE (SIZE (1 maxCDMA-BandClass)) OF IRAT-ParametersCDMA2000-1XRTT ::= supportedBandList1XRTT tx-Config1XRTT rx-Config1XRTT } SEQUENCE { SupportedBandList1XRTT, ENUMERATED {single, dual}, ENUMERATED {single, dual} SupportedBandList1XRTT ::= BandclassCDMA2000 SEQUENCE (SIZE (1 maxCDMA-BandClass)) OF ASN1STOP 72 ... l'architecture de LTE VU DINH Dau Promotion 13, 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. .. déployé dans des bandes allant de 1,25 MHz 20 Mhz, et la bande appariée et non appariée de la 3G Cela permet l'opérateur de déployer LTE sur la bande existante, de ne pas demander le permis de nouvelle... cellules Le NodeB s'occupe de la transmission et de la réception du signal radio, de la modulation/démodulation, du codage de canal, l'adaptation du débit de transmission, élargissement /des- élargissement,