Le multicast fiable est certainement la solution la plus efficace pour<br />la distribution de contenu a un très grand nombre (potentiellement des<br />millions) de récepteurs. Dans cette perspective les protocoles ALC et<br />FLUTE, standardisés à l'IETF (RMT WG), ont été adoptés dans 3GPP/MBMS<br />et dans le DVB-H IP-Datacast dans les contextes des réseaux<br />cellulaires 3G.<br /><br />Ce travail se concentre sur le multicast fiable et a comme requis<br />principal le passage à l'échelle massif en terme de nombre de client.<br />Ce travail se base sur les solutions proposées a l'IETF RMT WG. Ces<br />protocoles de multicast fiable sont construit autour de plusieurs<br />briques de base que nous avons étudié en détail:<br /><br />- La brique Forward Error Correction (FEC) :<br /><br /> Nous examinons la classe de codes grands blocs<br /> Low Density Parity Check (LDPC). Nous concevons des dérivées<br /> de ces codes, et les analysons en détail. Nous en concluons que les<br /> codes LDPC et leur implémentation ont des performances très<br /> prometteuses, surtout si ils sont utilisées avec des fichiers de taille<br /> importante.<br /><br />- La brique contrôle de congestion :<br /><br /> Nous examinons le comportement dans la phase de démarrage de<br /> trois protocoles de contrôle de congestion RLC, FLID-SL, WEBRC.<br /> Nous démontrons que la phase de démarrage a un grand impact sur<br /> les performances de téléchargement.<br /><br /><br />Cette thèse a aussi plusieurs contributions au niveau applicatif:<br /><br />- Extensions de FLUTE :<br /><br /> Nous proposons un mécanisme permettant d'agréger plusieurs<br /> fichiers dans le protocole FLUTE. Ceci améliore les performance de<br /> transmission.<br /><br />- Streaming vidéo :<br /><br /> Nous proposons SVSoA, une solution de streaming basé sur ALC.<br /> Cette approche bénéficie de tout les avantages de ALC en terme de<br /> passage à l'échelle, contrôle de congestion et corrections d'erreurs

Le multicast fiable est certainement la solution la plus efficace pour la distribution de contenu via un<br />tres grand nombre (potentiellement des millions) de recepteurs. Dans cette perspective les protocoles<br />ALC et FLUTE, standardises via l'IETF (RMT WG), ont ete adoptes dans 3GPP/MBMS et dans le<br />DVB-H IP-Datacast dans les contextes des reseaux cellulaires 3G.<br />Ce travail se concentre sur le multicast fiable et a comme requis principal le passage l'echelle massif<br />en terme de nombre de clients. Cette these se base sur les solutions proposees via l'IETF RMT WG.<br />Ces protocoles de multicast fiable sont construit autour de plusieurs briques de base que nous avons<br />etudie en detail:<br />* La brique Forward Error Correction (FEC) :<br />Nous examinons la classe de codes grands blocs Low Density Parity Check (LDPC). Nous concevons<br />des derivees de ces codes, et les analysons en detail. Nous en concluons que les codes<br />LDPC et leur implementation ont des performances tres prometteuses, surtout si ils sont utilisees<br />avec des fichiers de taille importante.<br />* La brique controle de congestion :<br />Nous examinons le comportement dans la phase de demarrage de trois protocoles de controle de<br />congestion RLC, FLID-SL, WEBRC. Nous demontrons que la phase de demarrage a un grand<br />impact sur les performances de telechargement.<br />Cette these a aussi plusieurs contributions au niveau applicatif:<br />* Extensions de FLUTE :<br />Nous proposons un mecanisme permettant d'agreger plusieurs fichiers dans le protocole FLUTE.<br />Ceci ameliore les performance de transmission.<br />* Streaming video :<br />Nous proposons SVSoA, une solution de streaming base sur ALC. Cette approche beneficie de<br />tout les avantages de ALC en terme de passage a l'echelle, controle de congestion et corrections<br />d'erreurs.<br /><br />Mots cles : Multicast fiable, FLUTE, ALC, codes correcteur d'erreurs, Forward Error Correction<br />(FEC), Low Density Parity Check (LDPC) Codes, diffusion de contenu

Le transport multicast est une solution efficace pour envoyer le même contenu à plusieurs récepteurs en même temps. Ce mode est principalement utilisé pour fournir des flux multimédia en temps réel. Cependant, le multicast classique de l'IEEE 802.11 n'utilise aucun mécanisme d'acquittement. Ainsi, l'échec de réception implique la perte définitive du paquet. Cela limite la fiabilité du transport multicast et impact la qualité des applications vidéo. Pour résoudre ce problème, 802.11v et 802.11aa sont définis récemment. Le premier amendement propose Direct Multicast Service (DMS). D'autre part, le 802.11aa introduit GroupCast with Retries (GCR). GCR définit deux nouvelles politiques de retransmission : Block Ack (BACK) et Unsolicited Retry (UR).Dans cette thèse, nous évaluons et comparons les performances de 802.11v/aa. Nos résultats montrent que tous les nouveaux protocoles multicast génèrent un overhead de transmission important. En outre, DMS a une scalabilité très limitée, et GCR-BACK n'est pas approprié pour des grands groupes multicast. D'autre part, nous montrons que DMS et GCR-BACK génèrent des latences de transmission importantes lorsque le nombre de récepteurs augmente. Par ailleurs, nous étudions les facteurs de pertes dans les réseaux sans fil. Nous montrons que l'indisponibilité du récepteur peut être la cause principale des pertes importantes et de leur nature en rafales. En particulier, nos résultats montrent que la surcharge du processeur peut provoquer un taux de perte de 100%, et que le pourcentage de livraison peut être limité à 35% lorsque la carte 802.11 est en mode d'économie d'énergie.Pour éviter les collisions et améliorer la fiabilité du transport multicast, nous définissons le mécanisme Busy Symbol (BS). Nos résultats montrent que BS évite les collisions et assure un taux de succès de transmission très important. Afin d'améliorer davantage la fiabilité du trafic multicast, nous définissons un nouveau protocole multicast, appelé Block Negative Acknowledgement (BNAK). Ce protocole opère comme suit. L'AP envoi un bloc de paquets suivi par un Block NAK Request (BNR). Le BNR permet aux membres de détecter les données manquantes et d'envoyer une demande de retransmission, c.à.d. un Block NAK Response (BNAK). Un BNAK est transmis en utilisant la procédure classique d'accès au canal afin d'éviter toute collision avec d'autres paquets. En plus, cette demande est acquittée. Sous l'hypothèse que 1) le récepteur est situé dans la zone de couverture du débit de transmission utilisé, 2) les collisions sont évitées et 3) le terminal a la bonne configuration, très peu de demandes de retransmission sont envoyées, et la bande passante est préservée. Nos résultats montrent que BNAK a une très grande scalabilité et génère des délais très limités. En outre, nous définissons un algorithme d'adaptation de débit pour BNAK. Nous montrons que le bon débit de transmission est sélectionné moyennant un overhead très réduit de moins de 1%. En plus, la conception de notre protocole supporte la diffusion scalable de lavvidéo. Cette caractéristique vise à résoudre la problématique de la fluctuation de la bande passante, et à prendre en considération l'hétérogénéité des récepteurs dans un réseau sans fil.

Le transport multicast est une solution efficace pour envoyer le même contenu à plusieurs récepteurs en même temps. Ce mode est principalement utilisé pour fournir des flux multimédia en temps réel. Cependant, le multicast classique de l’IEEE 802.11 n'utilise aucun mécanisme d’acquittement. Ainsi, l’échec de réception implique la perte définitive du paquet. Cela limite la fiabilité du transport multicast et impact la qualité des applications vidéo. Pour résoudre ce problème, 802.11v et 802.11aa sont définis récemment. Le premier amendement propose Direct Multicast Service (DMS). D'autre part, le 802.11aa introduit GroupCast with Retries (GCR). GCR définit deux nouvelles politiques de retransmission : Block Ack (BACK) et Unsolicited Retry (UR).Dans cette thèse, nous évaluons et comparons les performances de 802.11v/aa. Nos résultats montrent que tous les nouveaux protocoles multicast génèrent un overhead de transmission important. En outre, DMS a une scalabilité très limitée, et GCR-BACK n'est pas approprié pour des grands groupes multicast. D’autre part, nous montrons que DMS et GCR-BACK génèrent des latences de transmission importantes lorsque le nombre de récepteurs augmente. Par ailleurs, nous étudions les facteurs de pertes dans les réseaux sans fil. Nous montrons que l'indisponibilité du récepteur peut être la cause principale des pertes importantes et de leur nature en rafales. En particulier, nos résultats montrent que la surcharge du processeur peut provoquer un taux de perte de 100%, et que le pourcentage de livraison peut être limité à 35% lorsque la carte 802.11 est en mode d’économie d'énergie.Pour éviter les collisions et améliorer la fiabilité du transport multicast, nous définissons le mécanisme Busy Symbol (BS). Nos résultats montrent que BS évite les collisions et assure un taux de succès de transmission très important. Afin d'améliorer davantage la fiabilité du trafic multicast, nous définissons un nouveau protocole multicast, appelé Block Negative Acknowledgement (BNAK). Ce protocole opère comme suit. L’AP envoi un bloc de paquets suivi par un Block NAK Request (BNR). Le BNR permet aux membres de détecter les données manquantes et d’envoyer une demande de retransmission, c.à.d. un Block NAK Response (BNAK). Un BNAK est transmis en utilisant la procédure classique d’accès au canal afin d'éviter toute collision avec d'autres paquets. En plus, cette demande est acquittée. Sous l'hypothèse que 1) le récepteur est situé dans la zone de couverture du débit de transmission utilisé, 2) les collisions sont évitées et 3) le terminal a la bonne configuration, très peu de demandes de retransmission sont envoyées, et la bande passante est préservée. Nos résultats montrent que BNAK a une très grande scalabilité et génère des délais très limités. En outre, nous définissons un algorithme d'adaptation de débit pour BNAK. Nous montrons que le bon débit de transmission est sélectionné moyennant un overhead très réduit de moins de 1%. En plus, la conception de notre protocole supporte la diffusion scalable de lavvidéo. Cette caractéristique vise à résoudre la problématique de la fluctuation de la bande passante, et à prendre en considération l'hétérogénéité des récepteurs dans un réseau sans fil. / The multicast transport is an efficient solution to deliver the same content to many receivers at the same time. This mode is mainly used to deliver real-time video streams. However, the conventional multicast transmissions of IEEE 802.11 do not use any feedback policy. Therefore missing packets are definitely lost. This limits the reliability of the multicast transport and impacts the quality of the video applications. To resolve this issue, the IEEE 802.11v/aa amendments have been defined recently. The former proposes the Direct Multicast Service (DMS). On the other hand, 802.11aa introduces Groupcast with Retries (GCR) service. GCR defines two retry policies: Block Ack (BACK) and Unsolicited Retry (UR).In this thesis we evaluate and compare the performance of 802.11v/aa. Our simulation results show that all the defined policies incur an important overhead. Besides, DMS has a very limited scalability, and GCR-BACK is not appropriate for large multicast groups. We show that both DMS and GCR-BACK incur important transmission latencies when the number of the multicast receivers increases. Furthermore, we investigate the loss factors in wireless networks. We show that the device unavailability may be the principal cause of the important packet losses and their bursty nature. Particularly, our results show that the CPU overload may incur a loss rate of 100%, and that the delivery ratio may be limited to 35% when the device is in the power save mode.To avoid the collisions and to enhance the reliability of the multicast transmissions, we define the Busy Symbol (BS) mechanism. Our results show that BS prevents all the collisions and ensures a very high delivery ratio for the multicast packets. To further enhance the reliability of this traffic, we define the Block Negative Acknowledgement (BNAK) retry policy. Using our protocol, the AP transmits a block of multicast packets followed by a Block NAK Request (BNR). Upon reception of a BNR, a multicast member generates a Block NAK Response (BNAK) only if it missed some packets. A BNAK is transmitted after channel contention in order to avoid any eventual collision with other feedbacks, and is acknowledged. Under the assumption that 1) the receiver is located within the coverage area of the used data rate, 2) the collisions are avoided and 3) the terminal has the required configuration, few feedbacks are generated and the bandwidth is saved. Our results show that BNAK has a very high scalability and incurs very low delays. Furthermore, we define a rate adaptation scheme for BNAK. We show that the appropriate rate is selected on the expense of a very limited overhead of less than 1%. Besides, the conception of our protocol is defined to support the scalable video streaming. This capability intends to resolve the bandwidth fluctuation issue and to consider the device heterogeneity of the group members.