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

CodecBitrate (kbps)Packet size(bytes)Description
Narrow band audioAMR NB12.22323 octes/packet
Wide  band audioAMR WB236071 octes/packet
Standard videoH26474variableFrame size176x144, 10 fps
High quality videoH264104VariableFrame size176x144, 15 fps

Tableau 3: Les différents flux pour évaluer la performance de RoHC
4.2.2 Choix de modèle de fautes
Pour évaluer la performance de RoHC on peut simuler les erreurs de lien radio soit par perte de bits(BER) soit par perte de paquets. L’avantage du modèle bit perdu est qu’il peut montrer la robustesse de RoHC avec des erreurs imprévisibles. Nous utilisons le modèle d’aléatoire (Uniform) avec BER de 106 à 103 . En théorie, BER de 103 peut causer 28% paquets perdus (la probabilité d’avoir un bit d’erronés dans 40 octets de l’entêtes:
1 1103 40828 % ). Or, un taux de perte de plus de 10% n’est pas acceptable pour les application multimédia. Nous ne nous intéressons pas à un BER supérieur à 103 .
LTE utilise les mécanismes robustes tels que ARQ à la couche RLC, HARQ à la couche MAC, et FEC/Turbo coding à la couche PHY. Le taux de blocs erronés à la couche supérieur de MAC est de 104 à 103 [37]. La plupart de bits erronés sont corrigés. Il n’y a que des bits erronés en rafale qui engendrent des paquets erronés. Ces paquets sont considérés perdus. En plus, dans le cas de handover de LTE, il y a souvent un taux de perte s’il n’y pas d’interface X2 entre des eNodeBs. Donc le taux de perte est considéré dans le test de performance de RoHC.
En général, la distribution d’erreurs dans le lien radio est le suivant : il y a des segments erronés où tous les paquets successifs sont erronés et des segments corrects où tous les paquets successifs sont correctes. La taille moyenne de segment correct est de 103 , la taille moyenne de segment erroné est de 10 à 100 [38]. On utilise souvent le modèle de Gilbert simple (2 states Markov) et Gilber-Ellibott pour présenter la distribution de fautes. Le modèle de Gilbert simple est préféré car il y a moins de paramètres d’entrée (deux paramètres par rapport à 4 paramètres du modèle Gilber-Ellibott). Nous fixons la taille moyenne de segments corrects à 1000 paquets, et varions la taille moyenne de segments erronés de 10 à 100 paquets, ce qui correspond à un taux de paquets erronés de 103 à 102 .
4.3 Pre-tests
Pre-tests, le nombre maximal de paquets perdus est très haut dans O-mode
Illustration 14: Pre-tests, le nombre maximal de paquets perdus est très haut dans O-mode
JCP-Consult a développé un outil de test qui s’appelle « synthetic tester » pour que les ingénieurs puissent valider le fonctionnement de RoHC. Il permet de générer automatiquement des paquets, les passer vers RoHC, de valider les sorties de test, et donne des statistiques de tests. L’outil gérère ses propes paquets et n’est pas capable de tester des paquets « live » qui sont capturés à partir du réseau. De plus, il est incapable de simuler : erreurs, perte de paquets, délai, et déséquencement dans lien radio.

Number of PacketsRoHC modeProfileBERAverage packet lossBurst packet lossBandwidt h reductionInput file
5830O20.0001500.00154410.349770amr23k01.pcap
5830O20.0002000.55385932230.349705amr23k01.pcap
5830O20.0002500.00377410.349770amr23k01.pcap
5766R20.0005000.34651480.120370hightrate3gp01.pcap
5766R20.0005500.92663952800.077056hightrate3gp01.pcap
5766R20.0006000.11550540.122304hightrate3gp01.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 très 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 évaluations de performance de manière théorique pour comprendre les résultats. Ces résultats ne correspondent pas à la théorie. Les discussions avec les ingénieurs à JCP-Consult ont permis de corriger les bugs dans l’implémentation. A fin de mon stage, les résultats de tests sont raisonnables et observent des résultats à manière théorique.
4.4 Résultats
Dans les résultats suivants, nous choisissons le profil IP/UDP/RTP qui correspond aux applications multimédia telles que celles prévues dans le projet-NextTV4All.
4.4.1 Taux de bande passante économisée
Bande passante économique dans U-mode et BER = 0.0 avec des flux différents
Illustration 15: Bande passante économique dans U-mode et BER = 0.0 avec des flux différents
Le taux de bande passante économisée présente l’efficacité et l’intérêt de RoHC. Le taux de différents flux est disponible dans la figure 15. A gauche, ce sont des résultats de test avec des paquets IPv4, et a droit, ce sont celles du paquets IPv6. Chaque colonne qui a le couleur différent présente un type de flot.
On trouve que dans le même type de flot, l’efficacité de compression de paquets IPv6 est plus élevée par rapport à celle de paquets IPv4. De plus, dans la même version de protocole IP, le plus « payload » est gros, le mois RoHC est intéressant. L’efficacité de RoHC est proportionnelle à la taille des entêtes et inverse proportionnelle à la taille de payload.
Les résultats dans le figure 15 ne prends pas en compte des erreurs dans le lien radio qui causent désynchronisation entre le compresseur et le décompresseur. Dans les figures 16 à 19, nous évaluons l’efficacité de RoHC avec les taux de bits erronés différents (BER). On trouve que si le BER augmente, le taux de bande passante économisée 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 103,5 . Si le taux d’erronés est petite, O-mode économise le plus de bande passante, mais quand le BER est supérieur à 103 , R-mode est le meilleur.
Dans le mode unidirectionnel, le compresseur revient périodiquement aux niveaux inférieurs 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 inférieurs soit il reçoit 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 reçoit plus de paquets NACKs, il est forcé à revenir au niveau inférieur. L’efficacité est donc diminuée.
Quand l’erreur est petite, le mode optimiste est meilleur que le mode fiable parce que la liaison de retour est moins utilisée. Quand l’erreur est assez grand R-mode et O-mode doivent revenir aux niveaux inférieurs plus fréquemment. Mais le contexte de R-mode peut monter au niveau supérieur toute suite après recevoir un ACK, cependant le O-mode doit envoyer L paquets (niveau de confiance) avant de passer au niveau supérieur.
Évaluation de la performance de ROHCv1
4.4.2 Taux de paquets perdus
L’utilisation de RoHC permet de diminuer la taille d’entête, donc, la perte qui est causé par l’entête erroné diminue. Mais dans RoHC, un paquet perdu peut casser la cohérence entre les machines d’états au compresseur et au décompresseur. Nous testons donc la robustesse du mécanisme de re-synchronisation de RoHC.
Les figures de 20 à 23 présentent le taux moyen de perte en fonction de BER. Sur les courbes on remarque que l’utilisation de RoHC peut diminuer la perte de paquets. Le U-mode peut réduire à 50% de perte, et à 80% pour le R-mode. Le R-mode présente son avantage par rapport au U-mode et au O-mode. Dans ce mode d’opération seules les paquets avec un CRC de 7 ou 8 bits peuvent actualiser le contexte et être utilisés comme référence pour les décompressions subséquentes. L’intégrité du contexte est donc mieux protégée[34]. De plus, le compresseur ne passe au niveau supérieur que lorsqu’il reçoit un ACK. La perte du R-mode est donc moins importante par rapport à O-mode.
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

Rechercher
Télécharger ce mémoire en ligne PDF (gratuit)

Laisser un commentaire

Votre adresse courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Scroll to Top