Utilisation de la compression des entêtes dans les réseaux cellulaires de type 4G

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

Continuer la lecture

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

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.

Continuer la lecture

3.5 Procédure de déclenchement de RoHC
Cette partie décrit des étapes pour établir un service au plan de contrôle, dans lesquels le déclenchement de RoHC est montré (source principale [24]). En résumé, le RoHC est déclenché dans la procédure d’établissement de connexion de données DRB (Data Radio Bearer). Cette procédure est réalisé après l’établissement de connexion de signalisation SRB (Signalling Radio Bearer) et la procédure d’authentification. RoHC sera déactivé après la suppression des connexions DRB. Ci-dessous, les étapes sont développées en détails.

Illustration 12: Procédure pour configurer et déclencher RoHC dans l’interface radio
Premièrement, la connexion de signalisation SRB qui sert à transmettre des messages RRC entre UE et E-UTRAN est établie par la procédure de « RRC Connextion Etablisement ». Cette procédure est déclenchée par la couche supérieure de l’UE, lorsque l’UE veut répondre 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 reçoit un message de « RRCConnectionSetup » d’eNodeB. L’entité PDCP sera établie, en observant la configuration courante de sécurité. Ici, il n’y a pas de compression. Ensuite, tous les messages d’authentification et de NAS transmis sont protégés (intégrité/chiffrement) par PDCP. Si l’E-TRAN est surchargé, il peut

Continuer la lecture

2.2 Évolution LTE

2.2.1 Contexte et exigences

Le développement rapide des services de partage audio/vidéo (Youtube, Flickr), media streaming (VoIP, IPTV), réseaux sociaux (Facebook, MySpace) dans le domaine filaire… génère de grandes quantités de données. Par ailleurs, un large nombre d’équipements qui permet d’accéder aux services sont disponibles aux utilisateurs tels que : ordinateur portable, PDA, smartphone, « notebook enabled modem » …

L’utilisateur a donc besoin d’utiliser ces services avec la même expérience sur le domaine sans-fil, en particulier sur les réseaux cellulaires qui permettent à l’utilisateur d’être connecté accéder n’importe quand, n’importe où. Ces données vont produire un débit élevé sur ces réseaux qui, jusqu’alors, s’intéressent principalement au service de voix, pas aux services de données.

Les services de données sont différents des services de voix par: le débit très variable, la QoS différente pour chaque utilisateur/service, l’utilisation fréquente de connexion IP. Les équipements ont donc tendance à utiliser des connexions natives IP sans traduction et filtrage pour supporter efficacement ces services.

L’évolution du cœur des réseaux téléphonies arrive à une architecture “tout IP” qui supporte plus efficacement les connexions IP et un réseau entièrement par commutation des paquets facilite les mécanismes de QoS et l’utilisation plus efficace des ressources.

En général, LTE a pour but d’offrir un haut débit dans le sens montant et descendant, de

Continuer la lecture

2 EPS/LTE évolution de l’UMTS

2.1 Contexte de l’UMTS

2.1.1 Évolution de UMTS

UMTS comporte des évolutions qui sont définies par les releases suivantes :
La première, release 99, est publiée mi-1999. Cette version utilise une nouvelle interface radio qui se base sur CDMA (l’accès multiple à répartition en codes). Il y a deux types de réseau d’accès : FDD et TDD (TD-CDMA). Les interfaces radio des deux réseaux d’accès sont supportées par l’ATM. Le débit maximal dans le sens descendant est, en théorie, de 2 Mbps, et dans le sens montant est de 768 kbps. Le réseau du cœur se base sur le réseau de transport du GSM et GPRS.
La release 4 de l’UMTS est terminée en mars 2001. Cette version ajoute la deuxième interface radio de type TDD, TD-SCDMA. Cette interface utilise un débit « chip » inférieur (1,28 Mcps) par rapport au TD-CDMA (3,84 Mcps) afin de s’adapter à la bande inférieure (donc 6MHz) que la bande traditionnelle de TDD. La release 4 apporte une évolution importante dans le réseau cœur qui sépare la signalisation de la transmission (« call and bearer separation »). En conséquence, le MSC se divise entre le serveur de MSC pour assurer le contrôle d’appel, et CS-MGW pour assurer la transmission. Le GSMC se divise également entre le serveur de GSMC et CS-MGW.[2]
La release 5 est terminée en mars 2002, et apporte des évolutions significatives. Cette version inclut deux évolutions dans le réseau UMTS : le support d’IP au niveau du réseau coeur et HSDPA. Le protocole IP est considéré afin

Continuer la lecture