2. La transmission video dans les réseaux IEEE
802.11
La deuxième partie de ce chapitre est consacrée
à l'étude de la transmission vidéo dans les réseaux
IEEE 802.11. Nous commençons par la présentation du protocole RTP
puis nous décrivons le protocole RTCP. Ensuite, nous présenterons
l'état de l'art de la transmission multipoint dans les réseaux
IEEE 802.11.
2.1. Les protocoles temps réels
Les applications temps réel sont soumises à des
contraintes de temps strictes qui rendent impossible l'utilisation de
Transport Control Protocol (TCP). Le protocole Real-time Transport
Protocol [Schulzrinne, et al., 03] (RTP) essaye de palier aux
inconvénients des protocoles TCP et User Datagram Protocol
(UDP). En effet, les mécanismes du protocole TCP, tels que la
fiabilité par acquittement et retransmission des paquets manquants, le
contrôle de flux par la fenêtre de congestion (slow start), sont
incompatibles avec les applications temps réel. En plus les paquets UDP
se trouvent dépourvus de certaines informations comme le numéro
de séquence.
2.1.1. Le protocole Real-time Transport Protocole (RTP)
Le protocole RTP [Schulzrinne, et al., 03] assure une
numérotation et un horodatage des paquets en encapsulant les
données dans une nouvelle entête.
Il repose lui-même sur le protocole UDP, qui ne renvoie
pas les trames perdues en cours de route, afin de privilégier
l'enchaînement du son et des images, plutôt que
l'intégrité des données. La qualité peut en
souffrir si la liaison est mauvaise, mais c'est un mal nécessaire
à la diffusion en direct. Dans le cadre même de notre projet, deux
possibilités se présentent. La première consiste à
envoyer simultanément un flux de données vers chacun des clients.
L'autre solution est le multipoint qui se caractérise par la diffusion
d'un flux unique vers un groupe multipoint, dont les clients lisent
simultanément les mêmes informations. Dans l'objectif d'avoir une
optimisation de la consommation de la bande passante, il est
préférable d'utiliser une diffusion en multipoint. Le protocole
RTP va ainsi pouvoir assurer les fonctionnalités suivantes :
· reconstituer la base de temps des flux temps
réel,
· détecter les pertes de paquets et en informer la
source.
Mais le protocole RTP ne permet pas de réserver les
ressources dans le réseau, d'assurer une fiabilité et de garantir
le délai de livraison.
2.1.2. Le protocole Real-time Transport Controle Protocole
(RTCP)
Le protocole RTP est complété par le protocole
RTCP qui transmet périodiquement des paquets de contrôle à
tous les participants d'une session. Il adopte le même mécanisme
de transmission que le protocole RTP.
2.1.2.1. Les fonctions de RTCP
Selon [Mélin, 01] et [Perkins, 03], le protocole RTCP
remplit trois fonctions principales plus une optionnelle. Il retourne les
statistiques feedback sur la qualité de réception des
données transmises dans les paquets RTP. Ces informations temps
réel peuvent
être exploitées par la source pour adapter le
type de codage au niveau des ressources disponibles. RTCP transporte un
identificateur unique de la source RTP, appelé Nom Permanent
Canonical NAME (CNAME) car l'identifiant SSRC peut changer et ne
permet pas, à lui tout seul, d'identifier une source. Les destinataires
peuvent avoir besoin du nom permanent, CNAME, pour associer plusieurs flux de
données d'un même participant dans un ensemble de sessions RTP,
par exemple pour une synchronisation audio-vidéo.
De plus, la réception des feedbacks et la
connaissance du CNAME supposent que tous les participants envoient des paquets
RTCP régulièrement. Ces informations servent à ajuster le
débit de sortie et à l'adapter de manière à
accommoder toutes les personnes désirant se joindre à
l'évènement.
Enfin, la quatrième fonction qui est optionnelle,
consiste à transmettre des informations permettant une régulation
minimale des membres. RTCP assure l'identification des participants à
une conférence en jouant le rôle d'un canal de liaison entre des
participants fluctuants, et a priori non identifiés.
2.1.2.2. Les paquets RTCP
Plusieurs types de paquets sont définis, de
manière à transporter une grande variété
d'informations de contrôle (voir annexe A):
· Rapport d'émetteur (SR) : ce
paquet regroupe un ensemble de statistiques de transmission et de
réception en provenance des participants qui sont des émetteurs
actifs.
· Rapport de récepteur (RR) : c'est
un paquet regroupant un ensemble de statistiques en provenance de participants
qui sont des récepteurs.
· Description de source (SDES) : les
paquets de description de source comprennent plusieurs éléments,
dont le CNAME. Ils établissent une véritable carte de visite de
la source.
· BYE : c'est un paquet qui indique le
départ d'un participant de la session.
· APP: c'est un paquet qui permet
d'ajouter des fonctions spécifiques à l'application.
Chaque paquet RTCP commence par une partie fixe, semblable
à celle du paquet de données RTP, suivie par des
éléments structurés, de taille variable, selon le type du
paquet, mais qui se concluent toujours par une terminaison de 32 bits.
Plusieurs paquets RTCP peuvent être concaténés, sans
adjonction de séparateurs, pour former un paquet RTCP composite.
Ces paquets RTCP doivent respecter et tenir compte d'un
certain nombre de paramètres essentiels pour assurer le bon
déroulement de la session RTP. Parmi ces paramètres :
- La fréquence de transmission des paquets RTCP : lors
d'une conférence de plusieurs centaines de membres, les flux RTP sont
par nature autolimitatifs car une ou deux personnes seulement parlent en
même temps. En revanche, le flot de contrôle ne s'autolimite pas,
bien au contraire. Si les rapports de réception de chaque participant
sont toujours envoyés selon la même périodicité, le
trafic de contrôle va croître de façon linéaire avec
le nombre de participants. Il convient donc de limiter cette fréquence
en réduisant le trafic de contrôle à une
fraction minime et connue de la bande passante. A cet effet,
il est suggéré de n'allouer à RTCP que 5% au plus de la
bande passante globale de la session.
- La mise à jour du nombre de participants : Le calcul
de l'intervalle entre les rapports RTCP dépend d'une estimation du
nombre de sites participant à la session. Les nouveaux membres sont
ajoutés dès leur détection, dans une base indexée
par l'identificateur SSRC ou CSRC de leurs en-têtes RTP. Un membre peut
être supprimé de la liste quand le paquet RTCP BYE, avec
l'identifiant correspondant, est reçu.
- Allocation de bande passante pour la description de source
SDES : Plusieurs types de description de sources (SDES) sont prévus, en
plus des mentions obligatoires contenues dans le nom permanent CNAME, tels que
NAME (nom de la personne) et EMAIL (adresse email). Les descriptions de sources
SDES permettent également de définir des types de paquets RTCP
spécifiques à une application. Les applications doivent prendre
des précautions, en allouant de la bande passante de contrôle
à ces informations additionnelles. Elles peuvent ralentir la vitesse
d'émission des rapports de réception et des CNAME, diminuant
ainsi les performances du protocole. Il est recommandé de limiter
à 20% la part de la bande passante de contrôle consacrée au
transport des informations complémentaires SDES.
| 
