Comparaison de ROHCv1 de JCP-Consult avec RoHC de Thales et Al

4.4.3 Nombre maximal de paquets perdus successifs
La désynchronisation cause également une perte de paquets successifs. Les paquets perdus causent une gigue au niveau applicatif. Nous avons réalisé des tests pour évaluer la gigue.
Les figures de 24 à 27 présentent nombre maximal de paquets perdus successifs en fonction du taux de paquets perdus. Quand le taux de perte est petit, le nombre est près égale à celui de la non-utilisation de RoHC. Quand le taux de perte est supérieur de 102,3 0.005 . On trouve que le RoHC augmente un peu ce nombre, en particulier, le U-mode.
Le mode unidirectionnel n’a pas de feedback. Le décompresseur doit atteindre le paquet initial envoyé périodiquement pour se re-synchroniser avec le compresseur. Dans le mode bidirectionnel, le décompresseur peut envoyer le NACK pour forcer le compresseur à envoyer un paquet qui a plus d’informations (IR-Dynamic ou IR paquet) pour se re-synchroniser.

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

5 Conclusion et perspectives
Le contexte de ce stage était le projet de recherche européen NextTV4All, à JCP- Consult, en coopération avec TELECOM Bretagne. Dans ce stage, nous nous sommes intéressés à faire un état de l’art d’intégration de RoHC dans l’architecture de LTE.
Premièrement, nous avons présenté des innovations, et l’architecture de LTE. On remarque que des évolutions dans la technique d’accès OFDMA, MIMO et la simplification d’architecture basée sur le protocole IP facilitent des services multimédia comme IPTV.
Deuxièmement, nous avons présenté RoHC dans LTE. RoHC fonctionne au niveau de la sous-couche PDCP, les profils de RoHCv1 et RoHCv2 sont supportés. On constate que RoHC peut réduire la perte de paquets pendant le handover. RoHC est supporté dans les services de broadcast/multicast (MBMS). RoHCv2 améliore la performance dans certains cas tel que le handover. RoHCv2 apporte également des simplifications d’implémentation.
Troisièmement, nous avons effectué des tests sur l’implémentation de JCP-Consult de RoHCv1. RoHC est très robuste contre des erreurs sur le lien radio, et peut réduire 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 vidéo. Cependant, RoHC introduit un phénomène de gigue au niveau applicatif.
Nous avons développé 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 erronés, et des pertes de paquets selon différentes distributions : Uniform, Gilbert simple, et Gilbert-Ellibott. Les premiers résultats de test ont permit aux ingénieurs à JCP-Consult de corriger des bugs de type chaotique. Nous avons également réalisé une comparaison de la performance de RoHCv1 de JCP-Consult avec une implémentation compétitive. Cette comparaison a montré qu’il était encore possible d’optimiser l’implémentation de RoHCv1. Une étude intéressante serait la comparaison avec RoHCv2, qui est en cours de développement au sein de l’entreprise JCP-Consult et TELECOM Bretagne. Une autre étude intéressante concerne l’impact de RoHC sur la qualité de service (QoS) des réseaux multimédia. En effet, nous avons vu les problèmes de gigue générés par RoHC, mais d’autres effets sont également à prévoir, comme l’attente de synchronisation de RoHC. Je compte d’ailleurs rester en contact avec JCP-Consult et TELECOM Bretagne pour participer à ces études.
Lire le mémoire complet ==> (Utilisation de la compression des entêtes dans les réseaux cellulaires de type 4G)
Institut de la Francophonie pour l’Informatique – NEXTTV4ALL
Mémoire de fin d’études – Intégration de RoHC dans l’architecture de LTE
Master Informatique, option Systèmes et Réseaux
Table des matières  :
Glossaire des Abréviations 7
1 Introduction 9
1.1 Contexte 9
1.2 Problématique 10
1.3 Intérêt personnel pour ce stage 11
1.4 Objectifs de mes contributions 11
1.5 Plan du document 12
2 EPS/LTE évolution de l’UMTS 13
2.1 Contexte de l’UMTS 13
2.1.1 Évolution de UMTS 13
2.1.2 Architecture de l’UMTS 15
a) Architecture générale de l’UMTS 15
b) Architecture protocolaire de l’UMTS 17
2.1.3 Technologies concurrentes 19
2.2 Évolution LTE 20
2.2.1 Contexte et exigences 20
2.2.2 Architecture de LTE 22
2.2.2.1 Noeuds principaux 23
2.2.2.2 Architecture protocolaire 25
a) Plan de contrôle 25
b) Plan utilisateur 26
2.2.3 Interface radio 26
2.2.4 La sous-couche PDCP 27
2.2.5 Couche physique 29
3 RoHC dans UMTS/LTE 30
3.1 Description de RoHC 30
3.2 RoHCv2 31
3.2.1 Motivation de proposition de RoHCv2 dans PDCP/LTE 31
3.2.2 Améliorations et autres différences de RoHCv2 avec RoHCv1 31
3.2.3 Les profils de RoHCv2 32
3.2.4 Compresseur et décompresseur 33
3.3 Recommandation de RoHC dans 3GPP 33
3.4 Support de RoHC au terminal 34
3.5 Procédure de déclenchement de RoHC 35
3.6 RoHC et handover 37
3.7 RoHC et MBMS 38
3.7.1 MBMS 38
3.7.2 RoHC et Broatcast/Multicast 39
4 Évaluation de la performance de ROHCv1 40
4.1 Objectifs 40
4.2 Scénarios 40
4.2.1 Modèle d’évaluation de performance 40
4.2.2 Choix de modèle de fautes 41
4.3 Pre-tests 42
4.4 Résultats 43
4.4.1 Taux de bande passante économisée 43
4.4.2 Taux de paquets perdus 46
4.4.3 Nombre maximal de paquets perdus successifs 46
4.4.4 Comparaison avec RoHC de Thales et Al 49
5 Conclusion et perspectives