Etude du trafic sur Internet et transmission audio temps réel

Etude du trafic sur Internet et transmission audio temps réel
Phuong Hoang Nguyen1,2, Pascal Sicard1
Laboratoire LSR-IMAG 1
Université Joseph Fourier
Domaine Universitaire
681 Rue de la Passerelle
BP 72, 38402 SAINT MARTIN
D'HERES CEDEX, France
Laboratoire Objets Communicants et
Faisabilité de système 2
FTR&D/DIH/OCF
France Telecom R&D-Grenoble,
28 Chemin du Vieux Chêne
BP 98 38243 MEYLAN Cedex, France
[email protected], [email protected]
Résumé :
Nous nous intéressons au développement d’une application de transmission de
l’audio haute qualité temps-réel sur Internet. Le problème de ce type d’application et
de nombreuses applications multimédia à l’heure actuelle est le manque de garanties
de qualités de services (QoS) du réseau Internet. Le but de cette étude est de mettre en
place des mécanismes de contrôle des QoS au niveau de l’application afin d’obtenir
une qualité sonore « au mieux » malgré l’état du réseau variable. Pour cela, dans une
première partie nous donnons les résultats de mesures effectuées dans Internet sur
différents types de liaison afin d’établir les caractéristiques actuelles des QoS
d’Internet (pertes, délais et gigue). Cela nous permet ensuite de proposer une méthode
générale d’adaptation de l’application qui contrôle et réagit de façon pertinente aux
changements de chacun de ces paramètres afin de garantir une bonne qualité de rendu
sonore à l’utilisateur. Pour finir, nous montrons l’intérêt de ces travaux dans un
contexte plus moderne de réseau hétérogène pouvons comporter des parties
garantissant ou non certaines QoS.
Mots clés : Mesures de qualité de service (QoS), Internet, codage audio,
transmission audio, protocole temps réel, application multimédia
1. Introduction
Aujourd’hui, la transmission du multimédia sur Internet est devenue une réalité
grâce à la croissance des technologies audiovisuelles et des réseaux d’ordinateurs. De
nouvelles applications comme la téléphonie, la vidéo conférence, le télé-enseignement
ou la messagerie unifiée pour envoyer indifféremment des messages voix,
électroniques ou télécopie via l'Internet sont apparues.
Les protocoles utilisés dans Internet ont été conçus au départ pour ne fournir
qu’un service « best-effort » en termes de qualités de services (débit, gigue, délais de
transport, taux de pertes). Les applications multimédias peuvent demander des
contraintes temps réels et ainsi des qualités de services (QoS) plus strictes (délai,
gigue et pertes). Malgré des travaux importants dans l’amélioration de la gestion des
QoS dans Internet autour de la différentiation et l’intégration de services (Diffserv et
Intserv) leurs mises en pratique sont loin d’être généralisées. Il reste donc pour
l’instant aux applications à s’adapter au mieux aux qualités de services variables du
réseau. Des protocoles comme RTP/RTCP (Real Time Transfert Protocol / Real Time
Control Protocol) ont été normalisés et sont aujourd’hui utilisés pour cela.
1
Cet article aborde les résultats obtenus dans le cadre du développement
d’applications de transmission de l’audio sur Internet. Le but de ce travail est
d'améliorer la qualité des systèmes interactifs comme la téléphonie et aussi d'aider les
concepteurs des systèmes multimédia en leur offrant une couche intermédiaire de
développement. Pour évaluer les QoS actuelles dans Internet, nous avons effectué une
série de mesures réelles pour un ensemble de connexions représentatives. Au vue des
résultats de ces mesures, nous proposons des algorithmes de contrôle permettant à une
application de transmission audio temps réel de s’adapter au mieux au réseau.
La suite de ce document s’organise comme suit :
• Section 2 : Rappels sur le codage numérique de l’audio et les algorithmes de
compression existants
•
Section 3 : Etat de l’art sur les mécanismes de contrôle et d’adaptation des
QoS
•
Section 4 : Résultats de mesures de QoS (délais, gigue, pertes, durée des
pertes, corrélation de différents paramètres)
•
Section 5 : Proposition d’une méthode d’adaptation de l’application aux
QoS variables
•
Conclusions et perspectives
2. Codage numérique de l’audio et algorithmes de compression
Les algorithmes de compression audio actuels sont divisés en deux catégories :
codage différentiel et codage par synthèse. Même si la technique de compression de
ces deux types est tout à fait différente, l’une se base sur la quantification des
échantillons (PCM, ADPCM, ADM…) l’autre sur la modélisation du système de
production vocal humaine (LPC, CELP, GSM…), ils sont relativement simples, et
peuvent fournir de la compression audio de fidélité moyenne. De plus, ces derniers
fonctionnent parfaitement sur la voix, mais il est important de penser à des sources
audio de différents types. Pour cette raison, le codage en sous-bande SBC (Sub-Band
Coding) a été créé.
Le codage MPEG Audio est l’exemple le plus connu de SBC. Les créateurs de
MPEG Audio se sont intéressés à deux facteurs de l’oreille humaine : la non-linéarité
et l’adaptivité. La non-linéarité repose sur le fait que tous les sons ne sont pas perçus
par l’oreille humaine; les fréquences trop basses ou trop élevées ne sont pas prises en
compte. On peut donc supprimer ces fréquences " inutiles " en les filtrant, réduisant
ainsi considérablement la taille d’un fichier audio. L’adaptivité, quant à elle, est basée
sur le fait qu’un son trop fort peut en cacher un autre. Ces sons " masqués " sont aussi
supprimés puisque inaudibles par l’oreille humaine. Ces deux facteurs combinés, on
obtient une réduction importante et variable de la taille d’un fichier audio.
3. Mécanismes de contrôle des QoS
Le service offert par l'Internet, même s'il n'est apparemment pas idéal pour les
applications multimédia, est de toute façon le seul service disponible à l'heure
actuelle. Il s'agit donc de minimiser l'impact négatif des caractéristiques de ce service
sur la qualité des données multimédia reçues. Ceci est fait en pratique par l'utilisation
de mécanismes de contrôle. Trois caractéristiques du réseau ont un impact important
sur la qualité des transmissions, à savoir le délai de transport, la bande passante
2
disponible, et les pertes. A chacune de ces caractéristiques peut être associé un
mécanisme de contrôle.
Les mécanismes de contrôle de délai
Le délai possède une caractéristique fixe qui est le temps de propagation du
signal sur les différents tronçons du réseau et une partie variable : le temps de
traversée des routeurs intermédiaires. Il est impossible sans garantie de qualité de
services de limiter le délai qui sera mis par des paquets pour traverser les routeurs. Il
faut pour cela intervenir directement sur les routeurs (réservations de ressources,
politiques d’ordonnancement …). Du point de vue des applications, le délai du réseau
est donc incontrôlable [Kotas98].
Par contre, il est possible de contrôler les variations de délai (voir la figure 1.2)
en ajoutant un tampon mémoire à chaque destination. Un paquet arrivant à la
destination est mis en attente provisoire dans le tampon, ce qui lui permet d'attendre
les paquets suivants en retard, afin qu'ils soient rejoués de façon synchrone pour
corriger la gigue introduit par le réseau. Mais il est important de régler la taille de
mémoire tampon au plus juste afin de ne pas trop augmenter le délai de restitution.
Les mécanismes de contrôle de débit
Ils cherchent à faire en sorte que le débit de la source soit égal à la bande
passante disponible dans le réseau.
Figure 1.2. Variation du délai (gigue) par paquet
Cet ajustement est effectué pour l’audio en contrôlant soit le nombre de trames
par seconde (lié à la fréquence d’échantillonnage), soit l’algorithme de compression
de l’audio ; la qualité auditive du son transmis est donc variable mais peu rester
correcte. Ceci permet une variation contrôlée de la qualité de l’audio transmise en
fonction de la bande passante disponible dans le réseau à chaque instant. On peut
mettre en place un mécanisme basé sur une boucle de contre-réaction suivant la gigue
et les pertes des paquets observées [Busse96]. En effet, la bande passante disponible
est fortement corrélée avec ces deux paramètres. En fait, ce genre d’idée n'est pas
nouvelle, elle est par exemple utilisé dans TCP qui modifie son débit en fonction des
pertes dans le réseau pour contrôler les congestions [Dabbous00].
Les pertes des paquets
Les réseaux IP ne garantissent pas la livraison des paquets. La perte de paquets
est inévitable. Les congestions aux nœuds du réseau sont considérées comme leurs
causes principales.
3
Il existe actuellement plusieurs travaux relatifs aux mécanismes de protection
contre les pertes des paquets. Nous pouvons distinguer deux méthodes : protection
basée sur l’émetteur et réparation basée sur le récepteur.
Protection basée sur l’émetteur
Cette méthode peut être divisée en deux classes : retransmission active et chaîne
de codage passif [Perkins98] (figure 1.4.)
En raison des conditions rigoureuses sur le délai pour les applications
interactives, des protocoles fiables de transport basés sur des retransmissions tels que
TCP ne peuvent pas être utilisés.
Dans la transmission audio, on utilise souvent la réparation passive qui est basée
sur deux techniques principales : chaîne de codage FEC (Forward Errors Correction )
et d’entrelacement (interleaving-based scheme).
Les mécanismes FEC protègent n paquets par l’ajout d’une unité de redondance.
Les redondances construites peuvent être dépendantes ou non du codage du média.
Dans la protection FEC indépendante au média, les unités de redondances sont
calculées (par parité ou autre algèbre) à partir de n paquets et permettent de
reconstruire à l’arrivée un paquet perdu. Dans le cas dépendant cela peut consister à
ajouter une version du paquet n-1 dans le paquet n, obtenue en codant l’unité média
(i.e. audio dans notre cas) de paquet n-1 avec un codeur à plus bas débit [Bolot99].
Protection de l’Emetteur
Passive
Active
Retransmission
Entrelacement
Indépendant du
média
FEC
Basée sur le
média
Figure 1.4. Taxonomie des mécanismes de protection basés sur l’émetteur
Dans les cas où le délai n’est pas primordial et que chaque paquet peut contenir
plusieurs trames, l’entrelacement de trames successives dans les paquets est très
efficace pour réduire des effets de pertes sur la qualité sonore [Perkin98] (figure 1 .5).
Flux original
Flux entrelacé
Paquet perdu
Reconstruction
Figure 1.5. Protection par l’entrelacement
Récemment, un mécanisme d’entrelacement, basé sur les échantillons, est
construit en utilisant l’interpolation de la valeur moyenne pour la transmission de la
voix [Wah00]. Les échantillons sont divisés en deux groupes : numéro pair et impair.
4
Chaque groupe est ensuite envoyé dans des paquets distincts afin que le récepteur
puisse reconstruire efficacement les paquets perdus. La reconstruction est basée sur un
calcul de « valeur moyenne » (de deux échantillons adjacents à celui perdu) et un
filtre adaptatif qui effectue l’apprentissage de la reconstruction.
Réparation côté récepteur
Pour la réparation côté récepteur, l'utilisation de la répétition de paquets et de la
substitution du côté du récepteur peut également améliorer la qualité sonore perçue en
présence de perte de paquets. Les stratégies sont présentées dans la figure 1.7.
Réparation du Récepteur
Interpolation
Insertion
Raccord
Substitution
par Silence
Interpolation de
l’état
Répétition
Substitution par une
forme d’onde
Régénération
Substitution avec
du bruit blanc
Réparation basée sur modèle
Balance d’échelle
temporelle
Figure 1.7. Taxonomie des mécanismes de protection basés sur récepteur.
Parmi les mécanismes présentés, la substitution de bruit est recommandée, car
son implémentation est également simple. La répétition de paquets est efficace pourvu
que la taille des paquets soit petite, et le taux de perte de paquets soit bas. la similitude
à court terme des formes d'onde de la parole permet à la répétition de fournir une
qualité sonore améliorée comparée à la substitution de silence.
La qualité subjective de la répétition peut être améliorée en évanouissant
graduellement les unités répétées. [Perkins 98]
Pour palier aux pertes en rafales pour lesquelles la substitution est peu efficace
des techniques d’interpolation ou de régénération, comme la substitution avec une
forme d’onde, ont été développées [Perkins 98]. Elles sont plus complexes et très
coûteuse. Nous verrons dans la suite que les pertes en rafales sont aujourd’hui très
occasionnelles dans Internet.
Combinaison des contrôles
Ces techniques de reconstruction sont utilisées conjointement pour un meilleur
résultat. Par exemple, nous pouvons reconstruire les paquets perdus en utilisant
d'abord la redondance, puis la duplication si aucune information redondante n'est
disponible, et finalement le silence si le nombre maximum des duplications a été
atteint [FreePhone]. On ne doit pas oublier que l’utilisation de ces techniques de
reconstruction augmente le délai de bout en bout.
Une meilleure compréhension de la perte des paquets et du délai dans Internet
est essentielle pour la conception de mécanismes de contrôle efficaces appliqués à la
transmission multimédia ou précisément à l’audio de haute-qualité.
4. Métrologie et environnement
Dans nos expérimentations, nous voulons avoir une vue plus précise de la perte
des paquets, du délai et de sa variation (la gigue), ainsi que de leurs relations.
5
Les caractéristiques importantes de la perte des paquets sont le taux de perte et
la durée des pertes consécutives. Une autre mesure intéressante est la relation entre la
perte et le taux d'émission de la source.
La mise en œuvre des méthodes d’estimation dites passives qui consistent à
observer et analyser les paquets reçus sur un système terminal étant délicate, nos
estimations sont basées sur les mesures de types actives. Elles consistent à injecter du
trafic dans le réseau de manière contrôlée et à analyser les paquets retournés (ping,
traceroute, pathchar, treno) en utilisant soit un module d'attente, soit un service écho
au serveur mesuré.
D'autre part, il existe deux types de mesures: unidirectionnelles (à la
destination) ou bidirectionnelles (après un aller-retour). Les mesures
unidirectionnelles (plus réalistes) sont difficiles à effectuer à cause du décalage
d’horloge (skew) entre les sites du réseau. Nous utilisons donc des mécanismes de
mesures bidirectionnelles, en considérant que la longueur du chemin est doublée. En
effet, le module miroir serveur utilisé est simplement une boucle fermée, et nous
pouvons considérer la destination comme un routeur. Le temps de traitement dans ce
serveur a été mesuré, il est constant et de l’ordre de 20 microsecondes (négligeable).
Le service Ping dans l’Internet est l’outil le plus utilisé pour mesurer le temps
d’aller-retour RTT (round trip time). Certains routeurs éliminent en priorité les
paquets ICMP par rapport aux paquets UDP ou TCP en cas de congestion.
Nous avons donc développé un outil de mesure basé sur le protocole UDP. A
destination il assure un service d’écho qui renvoit immédiatement à la source les
paquets reçus. A la source un module envoie des paquets de sonde et attend leurs
retours ; les critères de QoS comme le taux de pertes, le délai, la gigue, l’histogramme
du délai, la durée des pertes… sont enregistrés dans des fichiers textuels.
Modèle expérimental
Nous voulons effectuer nos mesures sur des connexions représentatives des
différents cas potentiels réalistes. Pour cela nous avons effectué ces mesures entre des
sites locaux (i.e. du campus de Grenoble : 2 routeurs), entre des sites nationaux
(IMAG/Grenoble-ENST/Bretagne : 11 routeurs) et sur une ligne transcontinentale
(IMAG/Grenoble-MIT/Etats-Unis : 23 routeurs).
ENST
MIT
LSR
11
23
LANAI
(LSR)
2
IMAG
(isis)
Figure 1.8. Configuration des expérimentations
Comme l’intervalle minimum possible (contrainte système) entre des paquets
consécutifs est de 10ms, nous ferons les sondes avec des taux d’envoi de 100
paquets/s à 1 paquet/s.
Les trames audio que nous voulons transmettre sont de tailles variables. Une
trame MP3 de 48 kHz de fréquence d’échantillonnage donne 7680 bits/trame =
6
960 octets, nous devons donc effectuer aussi des mesures avec des paquets
de taille importante (900 à 1500 octets).
Gigue
Nous voulons mesurer la variation du délai (gigue définit par l’IETF dans le
protocole RTCP[rfc1889]) ainsi que sa dispersion (définit par l’université de
Standford [SLAC99]).
La gigue IETF du paquet i (notée Ji) est estimée par la méthode rapide de la
variance[Jacobson88]. C’est une fonction lissée de la différence du délais des deux
paquets consécutifs i et i-1 (noté |Dij|).
Ji = Ji-1 + (|Di-1,i|-Ji-1)/16 = 15/16*Ji-1 + 1/16*|Di-1,i| (1)
Par ailleurs, l’Université de Stanford utilise l’écart inter-quartile (paramètre de
dispersion) dans la probabilité pour estimer la gigue. Ici, la gigue est comprise comme
la différence du délai maximal et minimal, ou la différence du temps entre les arrivés
des paquets.
J = Q3 - Q1
(2)
Le premier quartile est la valeur du caractère, telle que pour p = 25% des
effectifs, la valeur du caractère soit inférieure (et donc 75% supérieure). Les quartiles
(Q3 , Q2et Q1) sont en conséquence les valeurs obtenues avec p égale 25, 50 ou 75.
L’InterQuartile (IQR) est calculé par la soustraction de Q3 et Q1.
Ainsi la dispersion est obtenue comme la différence entre la troisième et le
premier quartile de l’ensemble des échantillons. Ce calcul permet d’éliminer les pics
dans les sondes.
Pour les réseaux locaux, le délai est très faible (la plupart du temps inférieur à 2
ms) et assez stable (il ne dépasse jamais 4 ms) (voir la figure 1.9.).
ms
Figure 1.9. Le délai sur une connexion locale Lanai-Isis et sa variation IETF.
Pour les connexions moyennes et longues distances, le délai n’est plus
négligeable : IMAG-ENST de 29 à 50ms et IMAG-MIT de 140 à 250ms. La gigue est
importante, surtout pour la connexion transcontinentale IMAG-MIT. Ces variations
sont présentées dans la figure 2.0. La gigue est mesurée à l’aide de sondes de 2000 à
10000 paquets envoyés à intervalle régulier sur une demi-journée.
Les pics apparaissant sur la courbe IQR sont dus à une variation importante et
durable (paliers) du délai. Un changement par paliers n’influence pas beaucoup la
gigue IETF.
La dispersion du délai (IQR) donne une vue plus précise de l’état de congestion
du réseau. La gigue IETF permet seulement d’avoir une variation instantanée du délai.
7
Figure 2.0. Gigue de la connexion IMAG-MIT
Pertes des paquets
Dans ces mesures, nous considérons les paquets perdus après 10 secondes
d’attente.
Nous avons observé les pertes parmi 10 000 paquets de taille 1472 octets
envoyés avec un intervalle de 10ms (minimum possible) pendant vingt et une heures
sur la connexion locale du campus (avec le serveur isis). Le taux de pertes sur ces
paquets est inférieur à 0,06%. Ce taux de perte est négligeable par rapport à la QoS
nécessaire pour de l’audio. Ces pertes auront très peu d’impact sur la qualité sonore.
Pour la connexion IMAG-ENST (figure 2.1) la mesure est effectuée à l’aide de
sonde (2000 paquets de 1472 octets toutes les 10ms) espacées de 10 minutes pendant
8 heures. Le taux de pertes est toujours inférieur à 0,5%. La connexion à travers
RENATER est donc aujourd’hui de bonne qualité.
Figure 2.1. Taux de pertes sur la connexion IMAG-ENST
Il en est autrement sur les connexions transcontinentales critiques où la bande
passante n’est pas assez grande en comparaison des demandes.
Nous avons envoyé des sondes (2000 paquets de 700 octets toutes les 30ms)
pendant une journée (figure 2.7) . Le taux est très variable et peut atteindre plus de
10%. Le taux de perte et donc la congestion maximale du réseau se produit à 21 h
(heure française) qui correspond à 15h au Etats-Unis.
Figure 2.3. Taux de pertes sur la connexion IMAG-MIT
8
Corrélation entre gigue et pertes
Il serait intéressant pour estimer et même prédire l’état du réseau de trouver une
corrélation entre gigue et perte de paquets. Si l’on pouvait anticiper l’apparition ou la
disparition d’une congestion, cela nous permettrait de mettre en place des mécanismes
de contrôle performant.
La figure 2.4. donne la variation et la dispersion du délai, et les pertes sur une
journée. On observe une corrélation importante entre la gigue IQR et le taux de pertes
mais malheureusement, nous avons trouvé (en accord avec les résultats de
[Mukherjee94] [Garcia96]) qu’il est difficile de prédire une congestion (et donc des
pertes futures) à partir de la gigue.
Figure 2.4. Une forte corrélation entre gigue IETF – gigue IQR – pertes.
Durée des pertes
Un autre critère important pour les mécanismes de protection est la durée des
pertes sur le réseau. Le choix d’un mécanisme de protection des pertes va influencer
fortement le taux de redondances et le délai ajouté.
Dans cette expérimentation, les deux connexions IMAG-ENST et IMAG-MIT
sont étudiées.
IMAG-ENST: Durée de pertes du 18 mai 2001
100,00%
93,99%
80,00%
%
60,00%
40,00%
20,00%
5,69%
0,31%
0,00%
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
durée
Figure 2.5. Durée de perte sur la connexion IMAG-ENST.
L’histogramme de la figure 2.5. montre une statistique des pertes pendant une
journée (le 18 mai). Nous remarquons que la plupart des pertes observées sur la
connexion IMAG-ENST (>90%), ont une durée de 1 à 2 paquets consécutifs. Les
pertes de durée de plus de 3 paquets se sont rarement produites. Nous pouvons
expliquer cela par l’apparition de congestions faibles (routeurs rarement saturés), mais
surtout par les mécanismes mis en place aujourd’hui dans les routeurs (gestion
intelligentes des files d’attente (RED-Random Early Detection)). La protection contre
les congestions est basée sur la suppression anticipée et aléatoire de paquets quand les
files d’attente approche de la saturation pour influencer la politique de gestion de
9
congestion utilisée dans TCP. Il est à noter que dans leurs études Sue B. Moon et
al.[Moon98] ont noté que la plupart des flux de données dans Internet sont des flux
TCP et ont mise en évidence le taux important de pertes isolées.
Sur la connexion IMAG-MIT (figure 2.6), nous avons constaté une plus grande
variation des durées des pertes. Les pertes isolées se produisent toute fois la plupart
du temps (83% des cas). Des pertes de durée supérieure à 2 ne se produisent que dans
5% des cas. Ces observations peuvent aussi s’expliquer par les mécanismes
intelligents de gestion de congestion dans les routeurs. Les cas plus importants sont du
à des états de congestions exceptionnels, l’utilisation de flux non TCP ou des
évènements particuliers sur le réseau.
Par exemple, nous avons noté des pertes de durée exceptionnelle (plus de 20
paquets) à une heure fixe pendant la nuit, cela a été remarquée aussi dans
[Owezaski01]. Nous pouvons supposé que cela correspond au moment de changement
de configuration de routeurs internationaux.
Durée de pertes IMAG-MIT 18 mai 2001
90,00%
83,85%
80,00%
70,00%
%
60,00%
50,00%
40,00%
30,00%
12,64%
0,14%
0,07%
0,02%
0,01%
0,11%
0,03%
0,51%
0,09%
0,01%
0,02%
0,10%
0,02%
2,25%
0,06%
0,02%
0,06%
0,00%
20,00%
10,00%
0,00%
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19
durée
Figure 2.6. Durée de perte sur la connexion IMAG-MIT
Corrélation entre la taille des paquets et le taux de perte
Nous avons mesuré le taux de pertes pour des tailles de paquets différentes avec
même cadence d’émission (i.e. par conséquent, le débit augmente).
Cela peut nous montrer l’intérêt et l’effet d’ajout de redondances pour des
mécanismes de protection de pertes.
La figure 2.8 donne le taux de pertes pour deux séries de sondes (envoyés en parallèle
entre l’IMAG et l’ENST de Bretagne) de paquets de tailles différentes : 1270 octets et
160 octets.
Nous observons que le taux de pertes pour les gros paquets est la plupart du
temps le double par rapport à celui des petits paquets.
Il peut donc être inefficace et même mauvais d’augmenter la taille des paquets
en rajoutant de la redondance pour palier à des pertes de paquets.
Figure 2.8. Relation avec taille de paquet (débit) sur la connexion IMAG-Bretagne.
10
Figure 2.9. Relation avec taille de paquet (débit) sur la connexion IMAG-MIT.
Dans le cas de la connexion IMAG-MIT (figure 2.9) le taux de pertes des gros
paquets est toujours plus grand (en moyenne 5% de pertes supplémentaire). La
différence reste significative dans des cas de congestion faible (taux de pertes de
moins de 10%).
5. Mécanismes de contrôles et prototypage
Dans notre approche de mécanismes de contrôles et d’adaptation, nous voulons
développer un mécanisme dynamique basé sur la qualité de la voix en l’associant à
l’état des qualités de services du réseau. Le mécanisme de contrôle proposé est une
intégration de différents contrôles de transmission dynamique [Busse95], de
réparation des pertes[Garcia 96][Bolot99] et de l’estimation de la qualité sonore
requise. La fonction de ce mécanisme est montrée par les modules dans la figure 3.1.
statistiques
Analyses des
critères de QoS
Estimation de
l’état du réseau
Mode de
Décision de la transmission
stratégie
Figure 3.1. Mécanisme de contrôle dynamique.
Chaque fois que nous recevons des statistiques sur les pertes et la gigue (i.e.
RTCP RR), un module d'analyses va filtrer (par filtre passe-bas) et analyser les
paramètres reçus, celles-ci vont servir à estimer l’état actuel du réseau. Nous
appliquons les définitions d’état proposées par [Busse95] dont les seuils d’estimation
sont libre, chargé, congestionné. Enfin, la décision de stratégies de transmission
aboutissant à la meilleure qualité auditive possible est effectuée.
Les seuils d’estimation de l’état du réseau sont basés sur les résultats obtenus
dans les mesures précédentes(figure 3.2). L’état Idéal est obtenu dans le contexte du
réseau du campus avec le taux de pertes inférieur à 0,1%, l'état Libre associé avec le
seuil de pertes inférieur à 1%. L’état Chargé du réseau est défini par le taux de pertes
inférieur à 4% [Busse96] et le dernier état, état Encombré, est définit par le seuil du
taux de pertes de 4%.
Un autre facteur dans la classification de l’état du réseau est la bande passante.
Nous avons décidé d’utiliser la bande passante maximale (estimée par l’algorithme
Packet Pair basé sur la mesure de la durée d’inter-arrivées de sondes de deux paquets
envoyés consécutivement [Lai00][Carter96]) comme le deuxième facteur pour
identifier le réseau. En outre, quand la bande passante maximale est inférieure à la
demande de transmission nous devrons changer les états, par exemple si la bande
passante est insuffisante nous pouvons combiner l'état Libre et l'état Idéal.
11
Pertes(%)
Etat
Réaction
100% - 0
Encombré Réduire qualité
Statistiques
filtrées
se
sc
sl
Chargé
Garder qualité
Libre
Augmenter
avec protection
Augmenter
Idéal
0% - ~
Figure 3.2. Classification de l’état du réseau.
Enfin, la décision de stratégies de transmission aboutissant à la meilleure
combinaison des codages et ainsi à la meilleure qualité auditive possible dans le table
de combinaison des codages (table 3.1).
Au vu des résultats obtenus sur la durée des pertes (~90% des pertes ont une
durée inférieure à 3 quelque soit le type de liaison), nous proposons l’utilisation d’un
mécanisme simple de protection comme un FEC dépendant du média de facteur 2 (on
ajoute un codage redondant).
Codeur principal Codeur de redondance
Bande
passante
LPC
LPC(1)
LPC(2)
LPC(3)
LPC(4)
28 kb/s
GSM
GSM(1) LPC(2)
LPC(3)
LPC(4)
43,4 kb/s
ADPCM4
GSM(1) GSM(2) GSM(3)
71,9 kb/s
ADPCM6
GSM(1)
61,3 kb/s
MP3 (128 kb/s)
MP3 (32 kb/s)(1)
160 kb/s
MP3 (128 kb/s)
MP3 (32 kb/s)(1) MP3 (32 kb/s)(2)
192 kb/s
Tableau 3.1. Combinaisons de codeur principal et de redondances
Ici, la qualité sonore des codages est estimée de manière subjective MOS (Most
Opinion Score) dont les scores subjectifs sont mesurés usuellement sur cinq niveaux :
5 excellent, 4 bon, 3 moyen, 2 pauvre, 1 mauvais (voir table 3.2.).
Pour une redondance basée sur n codages et un taux de pertes L, la qualité
sonore reçue peut être donnée par [Chin98]:
Qreçu = (1-L)*P + L1*(1-L)*R1 + L2*(1-L)*R2 +…+ Ln*(1-L)*Rn
(3)
Où P est la qualité sonore du codage audio principale, Ri est la qualité de ième
codage redondant.
Codage
PCM
ADPCM
LD -CELP
MP3 32kb/s
GSM
CELP
LPC -10 e
MOS
4,3
4,1
4,0
3,7
3,47
3,2
2,3
Table 3.2. MOS pour quelques codages audio
Nous avons développé un prototype d’application de téléphonie permettant de
transmettre si possible un flux audio de haute qualité codé avec le MPEG Audio
(MP3). L’architecture de cette application est présentée dans la figure 3.3. L’audio
fournie par une source sera traité par les modules de la partie Serveur. Les
échantillons obtenus passés au test de détection du silence sont codés avec un ou des
12
codages désignés par les stratégies de transmission. Ces données sont assemblées et
paquétisées puis envoyées vers le récepteur. Suivant l’état du réseau le calcul et
l’ajout de redondance sont effectués.
Côté client, les paquets audio reçus seront désassemblés et attendent dans une
file (mémoire tampon) de taille variable gérée par un algorithme de contrôle de la
gigue dynamique. Le module de décompression va décoder les données principales et
redondantes grâce aux champs de contrôle dans l’en-tête des paquets. Si une ou des
pertes ne peuvent pas être reconstruites dans la partie Réparation grâce aux
redondances, elles seront substituées par la répétition ou le silence dans la phase de
Reconstruction. Après cette phase, les morceaux de données audio seront mis en ordre
dans une mémoire tampon avant d’être restitués.
Source Audio
Serveur
Audio
Client
Restitution
Capture audio
Reconstruction
Détection du
silence
Réparation FEC
Contrôle de
stratégie
Compression
MPEG & FEC
Decompression
Tampon
Contrôle du
débit
Packetisation
Collecteur
Internet
Dépacketisation
RTCP RR
Figure 3.3. Architecture de l’application
Conclusion et Perspectives
Les mesures effectuées, nous ont permis de conclure sur les qualités de services
actuelles d’Internet. Nous avons ainsi pu mettre en évidence des paramètres important
pour le développement d’application multimédia comme le taux et la durée des pertes,
la corrélation pertes/gigue, la corrélation taille des paquets / pertes. Cela nous permet
de déterminer différents états potentiel du réseau grâce à un nombre limité de
statistiques collectées. Ces mesures montrent aussi la nécessité de la reconnaissance
dynamique de l’état du réseau afin de pouvoir assurer la qualité de services
d’application temps réel.
Pour mettre ces idées en pratique, nous avons donc proposé une architecture
d’une application de téléphonie. Cette dernière se compose de l’analyse des
statistiques, de la classification de l’état du réseau et de la décision des stratégies qui
est basée sur des algorithmes d’adaptation et des combinaisons de codage audio
principaux et redondants basé sur la qualité audio perçue.
Face à la transformation de l'Internet, notamment la bande passante du cœur du
réseau, et les caractéristiques temps réel des trafics multimédia sur IP, les notions de
la QoS garanties par le réseau sont en train de changer. Cependant, le réseau reste
encore très hétérogène. Même si la qualité du noyau est gérée avec les politiques de
13
garantie de QoS comme Diffserv, la QoS des sous-réseaux périphériques restent
toujours variables. Nous devrons appliquer ces idées d'adaptation au QoS suivant les
tronçons du réseau utilisés et la forme des machines sources et destination.
Dans un cadre plus général de développement d’application multimédia, nous
voulons mettre en place une infrastructure logiciel répartie basée objet. L'idée est de
construire des objets d'adaptation (OA) ou "adaptateurs" qui s'occupent des gestions
de transmission entre les terminaux mais aussi de l'adaptation des flux aux différents
types de réseaux intermédiaires et de terminaux. Nos études se basent sur un réseau
dorsal VTHD (Vraiment Très Haut Débit), les adaptateurs sont utilisés dans les
serveurs intermédiaires comme des proxies programmables, qui fonctionnent sur la
couche 4 (Transport) ou plus. Ils peuvent par exemple changer la direction les flux
vidéo reçus vers un serveur adjacent choisi.
14
Bibliographie
[Bolot97]
Jean-Chrysostome Bolot & Andrés Vega-Garcia, The case for FEC based error
control for packet audio in the Internet, ACM Multimedia Systems.
[Busse96]
Ingo Busse, Bernd Deffner, Henning Schulzrinne, Dynamic QoS Control of
Multimedia Applications based on RTP, Computer Communications, Jan. 1996.
[Bolot 99]
Jean-Chrysostome Bolot, S. Fosse-Parisis, D. Towsley. Adaptive FEC-Based error
control for Internet Telephony. Proc. Infocom'99, New York, NY, mars 1999.
[Carter96]
Robert L. Carter, Mark E. Crowella, Measuring Bottleneck Link Speed in PacketSwitched Networks, Computer Science Departement, Boston University. 1996.
K.V.Chin, S.C.Hui, S.Foo, Enhancing the quality of Internet voice communication
for Internet telephony, School of Applied Science, Nanyang Technological
University, 1998.
Walid Dabbous, Applications multimédia sur l'Internet, INRIA Sophia Antipolis,
ERCIM. 1998.
IP Audio Freaks, FreePhone, http://www.inria.fr/rodeo/fphone/
[Chin98]
[Dabbous]
[FreePhone]
[Garcia 96]
Andrés VERGA GARCIAS. Mécanisme de contrôle pour la transmission de l’audio
sur l’Internet. Mémoire de thèse. l’Université de Nice-Sophia Antipolis Ecole
doctorale SPI. 1996.
[Jacobson 88]
Van Jacobson, Michael J.Karels, Congestion Avoidance and Control, Nonembre,
SIGCOMM, 1988.
[Kotas98]
T.J.Kotas, M.S.Borella, I. Sidhu, G.M.Schuster, J.Grabiec, and J.Mahler, Real-time
voice overs packet-switched networks, IEEE Network, vol.12, pp.18-27, JanuaryFebruary, 1998.
[Lai 00]
Kevin Lai and Mary Baker, Measuring Link Bandwidths Using a Deterministic
Model of Packet Delay, Proceedings of the ACM SIGCOMM 2000 Conference,
Stockholm, Sweden, August 2000.
[Moon98]
S. B. Moon, J. Kurose, P. Skelly and D. Towsley, Correlation of Packet Delay and
Loss in the Internet, University of Massachusetts, March, 1998.
[Mukherjee94]
A. Mukherjee, On the dynamics and significance of low frequency components of
Internet load, Journal of Internetworking: Research and Experience, vol. 5, no. 4, pp.
163-205, Dec. 1994.
[Owezaski01]
Supratik Bhattacharyya, Christophe Diot, Chuck Fraleigh, Bryan Lyles, Sue Moon,
Philippe Owezarski, Dina Papagiannaki, Nina Taft, Patrick Thiran, Internet Trafic
Analysis : Montoring the Sprint IP backbone, Sprint ATL, 2001.
[Perkins98]
Colin Perkins, Orion Hodson, Vicky Hardman, A survey of packet-loss recovery
technique for streaming audio, University College London, August 1998.
[rfc793]
[rfc1889]
Postel, J., Transmission Control Protocol, IETF,1981.
H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for
Real-Time Applications, IETF 1996.
[SLAC99]
SLAC - Stanford Linear Accelerator Center, "Comparaison of various ping Jitter ",
Stanford University, 3-1999.
[Wah00]
Benjamin W. Wah, Xiao Su and Dong Lin, A Survey of Error-Concealment Schemes
for Real-Time Audio and Video Transmissions over the Internet, Proc. IEEE
International Symposium on Multimedia Software Engineering, Dec. 2000.
15