Streaming

UNIVERSIT D'VRY-VAL-D'ESSONNE
Laboratoire de Rseaux et Systmes Multimdia
THSE
Pour obtenir le grade de
Docteur de lUniversit d'vry-Val-dEssonne
Spcialit : Informatique
Prsente et devrait tre soutenue publiquement Le 25 Mars 2009
Optimisation des applications de streaming peer to peer pour des rseaux ad hoc mobiles
Par
Mehdi NAFA
Jury Directeur Rapporteurs Examinateurs M. Nazim AGOULMINE M Francine KRIEF
me
Professeur l'Universit d'vry-Val-d'Essonne Professeur l'ENSEIRB Professeur l'Universit d'Ottawa Professeur Tlcom SudParis Charg de recherche l'INRIA Sophia Maitre de confrences lUniversit d'Amiens
M. Ahmed KARMOUCH M. Djamel BELAID M. Chadi BARAKAT M

me
Brigitte KERVELLA
Ddicace
Je ddie cet humble travail, A celle qui ma toujours soutenu, supportant mes sauts dhumeur et mon stress, inconditionnellement prsente auprs de moi, toi ma Ouafa, A celui que jappelle mon ptit bonheur qui changer ma dernire anne de thse ainsi que ma vie en une vritable allgresse, oui toi mon petit Nazim. A ma chre maman, qui a toujours t l pour moi, ma toujours soutenu, compris et fait tout ce quil faut pour me faciliter la vie, merci maman, A mon adorable papa, sans qui je ne serai jamais arriv l, cet homme qui a toujours su tre prsent pour moi, tout moment et en toutes circonstances, faisant ainsi tout les sacrifices, soucieux toujours de me propulser vers le meilleur, un trs grand merci papa, A mon frre avec qui japprends toujours de la vie, des acquis que je naurais jamais su avoir sans toi, merci Dhikrane, A vous mes amis, vous qui ensoleillez ma vie, et avec qui jai ce trs grand plaisir de partager des instants de bonheur continu, et en particulier : Billy, Sana, Loops, Yacine, Abdoul, Makdoudi, Malek, Mounir, Rahim, Nadir, Jeddi, Teicire. A vous mes camarades de parcours les prcieux amis du LRSM : Elyes, Gondi, Hajer, Alaa, Nada, Halim, Ismail, Hui, Dang et Toan.
Encore merci du fond du cur,
Mehdi
Remerciement
Ce travail de thse naurait jamais aboutit sans laide, les encouragements et limplication de certaines personnes qui jexprime travers ces quelques phrases modestes toute ma gratitude, en particulier : Je suis trs reconnaissant envers Monsieur Ahmed KARMOUCH, Professeur lUniversit dOttawa (Canada) ainsi que Madame Francine KRIEF Professeure lENSERB (France) pour mavoir fait lhonneur de juger ma thse et de rapporter mon travail je vous remercie pour toute lattention porte durant cette valuation. Je remercie chaleureusement Monsieur Djamel BELAID, Professeur Tlcom SudParis (France), Monsieur Chadi BARAKAT, Charg de recherche l'INRIA Sophia (France), Madame Brigitte KERVELLA, Maitre de confrences lUniversit d'Amiens (France). Davoir accepter dtre parmi les membres de jury de ma thse et davoir examiner mes travaux. Toute ma gratitude va mon Professeur, Monsieur Nazim AGOULMINE, Professeur lUniversit dEvry Val dEssonne (France) pour mavoir accueilli dans son laboratoire de recherche LRSM (Laboratoire de Rseaux et Systmes Multimedia) et de mavoir permis deffectuer cette thse dans de bonne conditions. Je le remercie aussi pour mavoir donn toute ces ides, ainsi que pour toutes les riches runions de travail, sans quoi je ne serai jamais arriv bout de cette thse, je ne vous remercierai jamais assez pour mavoir fait profiter de votre exprience et de mavoir tmoign tant de bienveillance. Je remercie O. Bensaada et K. Nafaa pour avoir bien voulu faire une relecture critique de ce manuscrit
iii
Abstract
Video content production has reached, nowadays, a big volume of traffic over the internet. Emerging social and professional networks (i.e. Facebook) and video portals (i.e. Youtube) acted as veritable accelerators for this phenomenon. In addition to IPTV and VoD applications, personal video sharing is also in the run. Our initial concern in this thesis was infrastructure wireless networks. We were focusing on how to provide a seamless mobile multimedia streaming service during horizontal handovers over cellular WLAN networks. This includes the proposal of a prediction based buffering scheme to cope with the video service disruption during the blackout periods. The work ended with a comparison between simulated and real test-bed implemented results. After file sharing and IP telephony, p2p streaming applications are getting a great concern from both academia and industry. The main goal of this technology is to allow nodes to cooperate and exchange contents among themselves. A lot of p2p streaming applications are currently used, over the Internet, for both video on demand and real-time streaming services like IPTV such as PPStream, UUSee, SopCas, TVants and Joost. At the same time we are seeing the development of new type of infrastructure-less communications using different types of devices PDA, telephones, computers, etc called Mobile Ad Hoc Networks. With this communication technology, networks can be created spontaneously at any place (home, office, street, bus, etc.). In a second phase our aim was to show how these MANET and P2P technologies can stimulate the emergence of new types of experience sharing in the society. We can easily imagine a scenario where mobile users build their own swarm, without resorting to the infrastructure, to exchange videos among them with no cost. Relying on their built-in wireless communication interfaces, they form a spontaneous network based on their preferences and including their friend, colleagues, etc. The two last contribution chapters are targeting the modeling and simulation of a mobile p2p streaming solution for MANETs. Relying on a mobility model based on the social communities we have shown the feasibility of P2P streaming over MANETs.
Rsum
De nos jours, La de production de contenu vido gnre un grand volume de trafic sur Internet. Une panoplie de rseaux sociaux mergent (tels que Facebook) et de portails vido communautaires (tels que Youtube) ont agi comme de vritables acclrateurs de ce phnomne. En plus des applications IPTV et de VoD, le partage de vidos personnelles est galement dans la course. Notre premire proccupation dans cette thse est la mobilit dans les rseaux sans fil dits infrastructure. Nous nous sommes concentrs sur la faon de fournir un service de streaming multimdia sans coupures lors des transferts horizontaux dun mobile traversant des rseaux WLAN cellulaires. Cela comprend la proposition d'un systme de mise en cache (buffering) fond sur la prdiction du handover afin de faire face l'interruption du service vido au cours de la priode de la perte de connexion par le terminal. Le travail s'est termin par une comparaison entre des rsultats obtenus par simulation dun cot et ceux mesurs sur un banc d'essai rel. Aprs le partage de fichiers et la tlphonie IP, les applications de streaming p2p reoivent un grand intrt la fois acadmique et industriel. L'objectif principal de cette technologie est de permettre aux nuds de cooprer et d'changer les contenus entre eux. Un grand nombre dapplications de streaming p2p sont actuellement utilises, sur Internet, la fois pour la vido la demande et en temps rel comme les services de tlvision IP, tels que PPStream, UUSee, SopCas, TvAnts et Joost. En mme temps, nous assistons au dveloppement dun nouveau modle de communication sans infrastructures prsentes dans diffrents types de dispositifs mobile (tels que les PDA, tlphones, ordinateurs portable, etc) appele Mobile Ad Hoc Networks. Avec cette technologie de communication, les rseaux peuvent tre crs spontanment n'importe quel endroit (domicile, bureau, rue, bus, etc.) Dans une deuxime phase, notre objectif tait de montrer comment ces technologies P2P MANET et peuvent stimuler l'mergence de nouvelles formes de partage d'exprience dans la socit. Nous pouvons facilement imaginer un scnario o les mobiles des utilisateurs construire leur propre essaim, sans recourir l'infrastructure, l'change de vidos entre eux sans frais. S'appuyant sur leurs interfaces de communications sans fils, ils forment un rseau spontan en fonction de leurs prfrences et y compris leurs amis, leurs collgues, etc. Les deux derniers chapitres de contribution portent sur la modlisation et la simulation d'une solution de streaming p2p pour MANETs. S'appuyant sur un modle de mobilit bas sur des communauts sociales, nous avons pu dmontrer la faisabilit du streaming P2P sur MANETs.
vii
Liste des tableaux

Tableau 1 Comparaison entre topologies Mesh et Tree .............................................................. 23 Tableau 2 MANETs vs.P2P: Diffrences .................................................................................... 35 Tableau 3 MANETs vs.P2P:Similitudes ..................................................................................... 37 Tableau 4 autres paramtres du modle ........................................................................................ 85 Tableau 5. Statistiques sur les nuds ............................................................................................ 90 Tableau 6 Paramtres de simulation ..........................................................................................100
ix
Liste des figures

Figure 1: Rseau P2P de 1re gnration (index central) ................................................................ 10 Figure 2: Rseau P2P de 2me gnration (inondation de requte) ................................................. 11 Figure 3: Table de hachage distribue (DHT) ............................................................................... 12 Figure 4: Le super peering.............................................................................................................. 13 Figure 5: Parts des clients (BitTorrent, Kazaa, eMule et Gnutella) sur le trafic P2P file sharing [6] ....................................................................................................................................................... 18 Figure 6: topologies Mesh vs. Tree................................................................................................. 23 Figure 7: Push vs. Pull................................................................................................................... 26 Figure 8: Classification des familles de protocoles ad hoc .............................................................. 27 Figure 9:Algorithme de prdiction du Tbho................................................................................... 52 Figure 10: Prdiction du Tbho et volution du buffer ................................................................... 57 Figure 11: Schma du banc dessai................................................................................................. 58 Figure 12:Schma du buffering ....................................................................................................... 59 Figure 13 Composantes logicielles de SM Stream .......................................................................... 61 Figure 14 Evolution des RSS reus ................................................................................................ 62 Figure 15: Tbho prdit et volution du buffer ............................................................................... 63 Figure 16 Couches du modle ........................................................................................................ 70 Figure 17 : Comparaison des rsultats des quations matresse et de taux [109] ........................... 73 Figure 18: Un exemple de rseau social [121] ................................................................................. 75 Figure 19: Exemple d'une Matrice d'affinit reprsentant un rseau social. .................................. 76 Figure 20:Exemple de matrice dadjacence reprsentant le rseau social. ...................................... 76 Figure 21: Exemple d'une communaut mobile [121]. .................................................................... 77 Figure 22: Distribution des degrs entrant et sortant. ................................................................... 86 Figure 23: Evaluations du dlai (cas fixe). ..................................................................................... 87 Figure 24: Evaluations du dlai (cas mobile sans considration de loverhead). ............................ 89
xi
xii
Table des figures
Figure 25: Distribution du dlai (cas mobile avec considration de loverhead) .............................90 Figure 26: Vue d'ensemble de MadTorStream. ...............................................................................98 Figure 27: Vue en couches de MadTorStream. ...............................................................................98 Figure 28: La stratgie Closest Deadline First. ...............................................................................99 Figure 29: Rsultats avec Closest Deadline First. ......................................................................... 101 Figure 30: Rsultats avec Rarest First.......................................................................................... 101
Liste des algorithmes

Algorithme 1: Collecte dinformation sur les rseaux avoisinants .................................................. 59 Algorithme 2 : prdiction des Tbho et Tbmo ..................................................................................... 60 Algorithme 3 : mise en cache ......................................................................................................... 60 Algorithme 4: excution du handover ............................................................................................ 61 Algorithme 5: modification de lalgorithme principal de Groover .................................................. 84
xiii
Table des matires

Ddicace ............................................................................................................................................ i Remerciement ................................................................................................................................. iii Abstract ........................................................................................................................................... v Rsum........................................................................................................................................... vii Liste des tableaux ........................................................................................................................... ix Liste des figures............................................................................................................................... xi Liste des algorithmes..................................................................................................................... xiii Table des matires ......................................................................................................................... xv Chapitre 1. 1.1. 1.2. 1.3. 1.4. 1.5. Introduction ............................................................................................................. 1
Streaming peer to peer .......................................................................................................... 1 Mobile ad hoc networks ........................................................................................................ 2 Contexte & Motivations........................................................................................................ 3 Contributions de la thse ...................................................................................................... 4 Structure du document ......................................................................................................... 5 Etat de lart ............................................................................................................. 7
Chapitre 2. 2.1.
Le streaming vido ................................................................................................................ 7 2.1.1. Transport de flux sur le rseau ................................................................................... 8 2.1.2. Sur la couche applicative ............................................................................................ 8 2.1.2.1. Mesure de la performance ....................................................................... 9 2.1.3. Utilisation du 802.11 pour le streaming ...................................................................... 9
2.2.
Les applications p2p ............................................................................................................ 10 2.2.1. Lindexation et la recherche ...................................................................................... 10 2.2.1.1. Approche centralise .............................................................................10 2.2.1.2. dcentralise (distribue) .......................................................................11 a. b. Tables de hachages distribues DHT: ............................................................... 11 Hybride .............................................................................................................. 12
xv
xvi
Table des matires
2.2.2. Application de partage de contenu ............................................................................ 13 2.2.2.1. Partage de fichier (File sharing) ............................................................ 13 a. b. c. d. e. Gnutella .............................................................................................................. 14 FastTrack ........................................................................................................... 15 eDonkey .............................................................................................................. 16 BitTorrent .......................................................................................................... 16 Statistiques ......................................................................................................... 17
2.2.2.2. Voix sur IP ......................................................................................... 18 2.2.2.3. Streaming audio et vido ....................................................................... 19 a. b. Pplive ................................................................................................................. 20 Joost ................................................................................................................... 21
2.2.2.4. Les deux topologies du streaming P2P .................................................... 22 a. b. c. Topologie mesh ................................................................................................... 22 Topologie Arbre.................................................................................................. 22 Comparaison ....................................................................................................... 23
2.2.2.5. Stratgies de slection de bloc et de nuds .............................................. 24 a. b. La slection de pairs ........................................................................................... 24 La slection de bloc ............................................................................................ 25
2.2.2.6. Technique de transfer des blocs .............................................................. 25 a. b. c. 2.3. Le mode push ..................................................................................................... 25 Le mode Pull ...................................................................................................... 26 Le mode hybride ................................................................................................. 26
Les rseaux ad hoc mobiles .................................................................................................. 27 2.3.1. Classification des protocoles de routage..................................................................... 27 2.3.1.1. Protocoles proactifs .............................................................................. 27 a. OLSR (Optimized Link-State Routing) .............................................................. 28
2.3.1.2. Ractif ................................................................................................ 28 a. AODV (Ad Hoc On-demand Distance Vector) .................................................. 28
xvii
2.3.1.3. Hybride ................................................................................................29 a. ZRP (Zone Routing Protocol) ........................................................................... 29
2.3.2. Modles de mobilit .................................................................................................. 30 2.3.2.1. Modles synthtiques .............................................................................30 a. b. Modles bass sur la marche alatoire ............................................................... 30 Le Random Way-point ...................................................................................... 31
2.3.3. Group Mobility Model .............................................................................................. 31 2.3.4. Community based mobilty model ............................................................................. 32 2.4. P2P sur MANETs quelle motivation ? ............................................................................... 32 2.4.1. Diffrences ................................................................................................................ 33 2.4.2. Similitudes ................................................................................................................ 35 2.4.3. Synergie entre les systmes P2P et MANET ............................................................ 37 2.4.4. P2P MANETS .......................................................................................................... 38 2.4.5. Approches de conception du P2P MANET .............................................................. 39 2.4.5.1. Stratifie et non structure. ....................................................................39 2.4.5.2. Intgre et non structure. .....................................................................39 2.4.5.3. Stratifie et structure. ..........................................................................40 2.4.5.4. Intgre et structure.............................................................................40 2.5. Mobile P2P Streaming ........................................................................................................ 40 SM Stream: Diffusion multimdia dans les rseaux disruptifs ............................... 43
Chapitre 3. 3.1. 3.2.
Rsum................................................................................................................................ 43 Introduction ........................................................................................................................ 43 3.2.1. Contexte ................................................................................................................... 43 3.2.2. Problmatique ........................................................................................................... 44
3.3. 3.4. 3.5. 3.6.
Introduction la mobilit dans linfrastructure sans fil: ..................................................... 44 Travaux relatifs................................................................................................................... 45 La mise en cache (buffering) ............................................................................................... 47 La prdiction du handover .................................................................................................. 48 3.6.1. Handover horizontal dans WLAN............................................................................. 49
xviii
Table des matires
3.6.2. Prsentation du filtre grey GM(1,1) .......................................................................... 50 3.6.3. Prdiction du temps avant handover......................................................................... 51 3.6.4. Prdiction du temps avant l'abandon de la cellule .................................................... 54 3.7. Evaluations .......................................................................................................................... 55 3.7.1. Simulations ................................................................................................................ 55 3.7.2. Rsultats et Discussions............................................................................................. 56 3.7.3. Exprimentation ........................................................................................................ 57 3.7.3.1. Description du banc dessai ................................................................... 57 3.7.3.2. Algorithmes raliss dans VLC .............................................................. 58 3.7.3.3. Rsultats ............................................................................................. 61 3.8. Conclusion ........................................................................................................................... 63 MADP2PStream: Modle de streaming peer to peer sur rseaux ad hoc mobiles.. 65
Chapitre 4. 4.1.
Introduction ......................................................................................................................... 65 4.1.1. Objectif de cette contribution .................................................................................... 66
4.2. 4.3.
Travaux existants ................................................................................................................ 67 Modlisation du p2p streaming bas sur le modle de Carra et al. ...................................... 68 4.3.1. Principes de base ....................................................................................................... 68 4.3.2. Analyse des applications streaming fondes sur le mesh............................................ 69 4.3.3. Comportement du systme cibl ................................................................................ 71 4.3.3.1. Le streaming........................................................................................ 71 4.3.3.2. Arrive, dpart & mise jour ................................................................ 72 4.3.4. Modle mathmatique ............................................................................................... 72
4.4.
Modlisation de la mobilit par Musolesi et al..................................................................... 74 4.4.1. Matrice d'affinit (affinity) ........................................................................................ 75 4.4.2. Modle social de la communaut ............................................................................... 76
4.5.
Prise en compte de loverhead dans le calcul des dlais ....................................................... 79 4.5.1. Cas de protocole ractif ............................................................................................. 80 4.5.2. Cas de protocole proactif ........................................................................................... 81
4.6.
Reprsentation de la mobilit dans le graphe de streaming p2p .......................................... 82
xix
4.7.
Evaluations ......................................................................................................................... 84 4.7.1. Groover: solveur d'quations diffrentielles............................................................... 84 4.7.2. Application du modle MADP2PStream .................................................................. 84 4.7.3. Analyse du degr ...................................................................................................... 85 4.7.4. Analyse du dlai ....................................................................................................... 86 4.7.5. Analyse de la qualit................................................................................................. 90
4.8.
Discussion et conclusions..................................................................................................... 91 : MadTorStream - un protocole pour le streaming p2p mobile .............................. 93
Chapitre 5. 5.1.
Introduction ........................................................................................................................ 93 5.1.1. Persistance et rplication pour palier la mobilit ................................................... 94 5.1.2. Mobilit augmente la diversit .................................................................................. 94
5.2.
Travail effectu ................................................................................................................... 94 5.2.1. Travaux relatifs ........................................................................................................ 95 5.2.2. Manet modles de routage et de la mobilit ............................................................. 96 5.2.3. Mobile peer-to-peer streaming .................................................................................. 96 5.2.4. Difference entre file sharing et streaming p2p........................................................... 96
5.3.
Vue d'ensemble de MadTorStream ..................................................................................... 97 5.3.1. Manet modles de routage et de la mobilit ............................................................. 98 5.3.2. Au niveau peer-to-peer (couche de partage vido) .................................................... 99 5.3.3. Application du Modle de mobilit ........................................................................... 99
5.4. 5.5. 5.6.
Simulations......................................................................................................................... 100 Discussion des rsultats ...................................................................................................... 100 Conclusions ........................................................................................................................ 102 Conclusions et perspectives ................................................................................... 103
Chapitre 6. 6.1. 6.2.
Synthse du travail ralis ................................................................................................. 103 Rsum des contributions .................................................................................................. 104 6.2.1. Streaming sans coupure en mobilit sur WLAN SM Stream ............................ 104 6.2.2. Modle de streaming p2p sur MANET MADP2PStream ................................. 104 6.2.3. Streaming bittorrent sur MANET MadTorStream .......................................... 105
xx
Table des matires
6.3.
Perspectives ....................................................................................................................... 105 6.3.1. Adaptation de paquets vido pour handover ........................................................... 106 6.3.2. Mcanisme de rplication pour streaming P2P sur MANET ................................... 106 6.3.3. Clustering bas sur la session de lecture .................................................................. 107 6.3.4. Localisation P2P smantique de contenu vido (DHT, MPEG-7 et Ontologies) ... 107
Rfrences ..................................................................................................................................... 109 Annexe A. ..................................................................................................................................... 123 A.1. Liste des publications......................................................................................................... 123 A.1.1. Articles de recherche................................................................................................ 123 A.1.2. Rapports de projet ................................................................................................... 124 A.2. A.3. A.4. Index .................................................................................................................................. 125 Glossaire ............................................................................................................................ 127 Media Streaming dans VLC ............................................................................................... 129
Chapitre 1. Introduction
Les rseaux de tlcommunications ont, en cette dernire dcennie, connu une remarquable croissance. Lusage des nouvelles technologies mobiles tend simposer en acteur quotidien de lactivit socio conomique et culturelle des socits. Lenvoi de messages et de photographies, laccs l'information, les jeux et le partage de fichiers sont des applications qui font aujourdhui partie intgrante des appareils mobiles. Ce comportement humain consacre la rupture de la dpendance la localisation gographique dalors assurant une concordance lors de la mobilit, avec lomni-disponibilit de l'information. Plusieurs phnomnes fascinants caractrisent l'volution actuelle dInternet, notamment avec lavnement du multimdia, tant sur le plan professionnel que celui du loisir. Sans aucun doute YouTube, FaceBook, mais aussi, la diffusion de chanes tlvises sur internet sont les parfaits exemples de cette mutation.
1.1. Streaming peer to peer

D'un autre cot, les internautes se sont retourns vers une nouvelle structure distribue ddie au partage des informations connue sous le nom des systmes P2P (peer to peer ou pair pair); un rseau o les entits communiquent directement et indpendamment de toute autorit centrale pour assurer leurs interactions. La popularit d'une telle technologie rvle la tendance manifeste dInternet vers un systme rparti qui supporte plus que de simples applications client/serveur. Cette distribution du contrle et des objets constitue la pierre angulaire des rseaux pair--pair. En gnral, cette dcentralisation seffectue de manire ce que les pairs soient fortement autonomes et indpendants les uns des autres. Lavantage de cette approche rside dans sa capacit de passer lchelle: Un bon rseau pair pair peut facilement atteindre une taille de quelques millions de pairs, qui peuvent parfaitement le rejoindre ou le quitter, tout moment, sans dtriorer srieusement la qualit globale du service. Depuis leur apparition, les protocoles P2P connaissent un succs commercial considrable ainsi quun grand intrt acadmique. Ces applications P2P utilisent actuellement des protocoles de
Chapitre 1 Introduction
plus en plus complexes avec des comportements qui suscitent, depuis leur mergence, lintrt des chercheurs et des industriels. Dans les activits de recherches sur des systmes P2P, les problmatiques et les aspects les plus abords sont manifestement ceux lis la dcouverte de ressources, la dynamique, la gestion des contenus, le routage ainsi que l'amlioration de la qualit du service. Ces tudes se basent sur l'optimisation et la thorie des graphes afin de construire des topologies robustes qui garantissent le passage lchelle et des proprits de tolrance aux pannes. Lindexation par l'utilisation des tables de hachage distribues a en outre, rvolutionn les environnements P2P impliquant ainsi un accs rapide linformation avec un routage efficace dans le rseau. Ces techniques continuent tre dveloppes et connaissent, de ce fait, une extension vers les rseaux ad hoc mobiles. Un aspect crucial de l'optimisation des rseaux pair pair grande chelle, est la gestion de l'interaction inter-pairs et de la distribution du contrle, dans un environnement o les pairs arrivent et partent tout moment. ; Cest une proprit de la conception o la distribution des donnes et des contrles a lieu d'une manire automatise, ne ncessitant aucune gestion centralise. Ceci donne en effet naissance la conception de systmes auto organiss. Les rseaux P2P taient, tout au dpart, domins par les applications de messagerie instantane et de partage de fichiers ; plus tard, c'est au tour de la Voix sur IP (VoIP) et aux grilles de calcul (Grid Computing). Depuis peu, la tlvision a rejoint le pair pair : les systmes de IPTV (TlVision sur IP) ont migr d'un schma client /serveur vers une architecture distribue, tirant profit de l'agrgation des ressources respectives de chaque nud qui forme le rseau (t.q. Puissance de calcul, stockage et bande passante) pour partager des flux vidos travers des communauts coopratives. Diffrentes solutions P2P peuvent tre distingues pour la distribution de vido, avec diffrents fournisseurs et utilisateurs. Actuellement, les dveloppements de diffrentes solutions de streaming peer to peer ont vu le jour, engendrant un ensemble de clients propritaires, que ce soit pour la Vido la demande (VoD) ou en directe (live streaming), des projets de IPTV ambitieux pour la diffusion de TV internationales en directe travers le monde en combinant du P2P et du client/serveur.
1.2. Mobile ad hoc networks

Dans les communications classiques, dites dinfrastructure, des appareils mobiles utilisent la communication radio un saut pour accder une station de base qui le connecte directement l'infrastructure. contrario, les communications ad hoc nexigent aucune infrastructure pour communiquer. Les nuds ad hoc mobiles fonctionnent, la fois, comme htes, serveurs et relais. Ils communiquent entre eux directement, par des liaisons un seul ou plusieurs sauts ils ne sont pas porte.
Comme ces nuds sont mobiles, la cration du routage est affecte par la perte et la cration de liens. La topologie du rseau peut donc changer rapidement et de faon imprvisible. Les MANETs (Mobile Ad-hoc NETworks) sont utiles dans de nombreux environnements (catastrophe naturelle, communication en combat, rseau de capteurs) et n'ont nul besoin d'infrastructure. Les communications dans les rgions plus petites peuvent tre mise en place grce aux MANETs.
1.3. Contexte & Motivations

Aujourdhui on peut constater les facteurs suivants qui affectent de manire importante les rseaux : multimdia, mobilit. Le trafic vido est class parmi les applications les plus consommatrices en bande passante sur internet. Ce trafic qui a mme dtrn le partage de fichier, dans le classement des application les plus gourmandes, avec l'apparition de diffrent moyens libres de production et de publication de contenus audiovisuels sur internet utilisant des serveurs ddis leur stockage. Ce phnomne de production individuelle et massive de vidos a gnr de gros volumes de donnes qui posent alors un problme aux FAI (Fournisseur d'accs Internet) notamment par sa consommation dmesure de la bande passante. Ce qui n'a cess de samplifier avec l'apparition du phnomne peer to peer streaming sur la toile. Malgr les avances dans les domaines des mthodes de compression numrique, le volume croissant des vidos mises en ligne, par les internautes, ne cesse de proccuper les oprateurs. La consommation d'nergie est une autre caractristique contraignante dans les rseaux et plus particulirement pour les appareils mobiles. En effet, le fait que ces derniers comptent sur leurs batteries pour s'alimenter en puissance, les rend plus vulnrables que leurs homologues fixes, qui eux ont une source d'nergies permanente. Ce qui fait que le rseau doit prendre cet handicap en considration, pour viter que les terminaux fragiles npuisent compltement leurs batteries cause du routage et de la persistance des informations. Aujourdhui de plus en plus de terminaux sont utiliss de manire mobile, les tlphones deviennent de vrais ordinateurs connects lInternet, les ordinateurs portables jadis fonctionnant en autonome sont maintenant quasiment connects Internet tout le temps grce aux cls 3G. Les capacits bornes, de la mmoire et de la puissance de calcul, des dispositifs mobiles les contraignent supporter une qualit d'encodage vido (BitRate) limite. Ceci est prendre en compte dans la conception d'applications destines un dploiement sur des rseaux ad hoc mobiles. Depuis leurs apparitions, les quipements mobiles ne cessent de s'amliorer. Ils reoivent de plus en plus de puissance de calcul avec des processeurs qui sont quivalant ceux des premiers ordinateurs de bureau, leurs permettant ainsi une certaine puissance d'excution tel que le dcodage vido entre autres.
Dans ce travail de thse nous nous sommes intresss au support de la QoS des applications multimdia durant la mobilit. Nous avons voulu traiter, dune part, la diffusion de service vido dans les rseaux sans fils infrastructure ou dans les rseaux ad hoc mobiles. Les problmes principaux qui apparaissent sont le dlai, la gigue ainsi que la qualit de l'exprience. Lapproche P2P apport une nouvelle manire dassurer la QoS sur le filaire. Nous avons dcid de la porter sur les rseaux ad hoc pour faire du streaming. Aprs les avoir vu migrer le streaming vido des rseaux filaires vers le sans fil, nous restons trs convaincus qu'il y un rel besoin de porter ces applications peer to peer sur les MANETs, pour les raisons suivantes: (a) La couche routage des MANETs est parfois inapproprie quand il s'agit de fournir les services demands par des applications mobiles sophistiques (gourmandes en bande passante et puissance de calcul), et; (b) la nature imprvisible du canal radio ainsi que la mobilit des utilisateurs posent des problmes majeurs au routage, ncessitant ainsi l'intervention d'une couche suprieure. La stratgie employe de nos jour, est celle de garder une certaine simplicit dans la dfinition des protocoles de transport et de routage MANET, et au besoin; de les complter en utilisant des foncions au niveau applicatif via des overlays ou des rseaux pair pair.
1.4. Contributions de la thse

Cette thse est consacre l'tude de l'impact de la mobilit dans les rseaux sans fils avec et sans infrastructure. Il sagit dabord, danalyser dans ce contexte ce phnomne dans les rseaux infrastructure, ensuite, de dvelopper cette approche aux rseaux sans infrastructure. Dans le cadre de deux projets de recherches europens 1 , 2 , nous avons pu proposer et valider, en collaboration avec notre quipe, des solutions pour les deux cas de figure. Dans le premier travail, nous nous sommes intresss au maintien de la QoS de lapplication multimdia des utilisateurs mobiles connects au rseau infrastructure WLAN (Wireless Local Area Network). Lors de ses dplacements le terminal de lusager se connecte diffrents points daccs alors que lutilisateur continu recevoir le service. Notre contribution consist proposer SM Stream: un mcanisme de mise en cache (buffering) dynamique, guide par la prdiction du handover, pour palier la coupure du flux vido (streaming) lors d'un handover horizontal entre des cellules Wifi. Dans le second cas, ltude porte sur la diffusion vido sur des rseaux ad hoc mobiles. Tout particulirement, les diffrents problmes quengendre la dynamique gnre par la mobilit. En
SUMO (Service Ubiquity in Mobile and Wireless Realm) est un projet collaboratif du programme Europen ITEA. 2 ExpeShare (Experience sharing in mobile peer communities) est un projet collaboratif du programme Europen ITEA.
1
plus de perturbations causes par les dparts/arrives des nuds dans les rseaux peer to peer classiques (fixe). Ces mfaits peuvent se rpercuter directement sur la qualit du service peer to peer en gnral et la qualit de l'exprience perue par l'utilisateur dans le cas du streaming vido. C'est dans cette optique que nous avons propos deux solution appeles MADP2PStream et MadTorStream. Respectivement, un model analytique et une plate-forme de diffuser vido sur les rseaux ad hoc mobiles. Le model se base sur une proposition de graphe pour le peer to peer streaming dont la dynamique est accentue par une contrainte supplmentaire, celle des tats des liens sans fils. Nous employons un modle de mobilit bas sur les comportements sociaux. Ce modle sera par la suite, valid par simulation dans des conditions de fonctionnement relles des rseaux, en prenant en compte diffrents paramtres, et en utilisant NS-2, dans deux scnarios: le premier avec un protocole de routage proactif et le second avec un protocole de routage ractif.
1.5. Structure du document

La suite de ce manuscrit est structure en six chapitres, aprs ce chapitre 1 introductif: Le Chapitre 2: tat de l'art, introduit les diffrents concepts et dfinitions en rapport avec lobjet de cette thse et en rappelle les principaux rsultats de travaux de recherches y affrents effectus dans le domaine des rseaux mobiles. Ainsi, sont prsentes les diffrentes avances dans le domaine : le streaming vido, les rseaux sans fils porteurs pour les MANETs et les systmes peer to peer streaming tout en dressant un tat des lieux qui se veut le plus exhaustif possible de tout ce qui se pratique dans cet art. Le Chapitre 3: SM Stream - Streaming Multimdia en Mobilit sans coupure est consacr ltude et ralisation du systme de prdiction et dexcution du Hand Over horizontal, tout en assurant la continuit du service vido lors de la mobilit entre des cellules WiFi (Wireless LAN). Cette tape porte sur la prsentation de l'algorithme retenu pour estimer le temps avant ce HandOver, les dtails de son implmentation ainsi que celle du mcanisme de mise en cache adaptatif pour palier aux coupures durant le changement de cellule. Le chapitre 4 : MADP2PStream - un modle pour le streaming p2p mobile sintresse la modlisation des rseaux peer to peer streaming sur internet. Sur la base de l'tude des proprits de la mobilit, nous proposons une extension de ce modle pour supporter une mobilit communautaire, base sur les rseaux sociaux. Et ce afin de dmontrer la faisabilit de la solution de streaming peer to peer, sur les rseaux ad hoc mobile. Des valuations analytiques seront exposes dans la deuxime partie de ce chapitre.
Dans le Chapitre 5 : MadTorStream - un protocole pour le streaming p2p mobile, nous tudions tout dabord les proprits ncessaires un protocole de streaming P2P pour quil fonctionne sur un rseau MANET. Nous proposons ltude d'un protocole de partage de fichier existant pour envisager le streaming sur un rseau MANET. Nous traitons un scnario sur un protocole de routage proactif. Le mme modle de mobilit sera utilis: communitiy based mobility model. Le but tant l'valuation de la qualit du streaming peer to peer dans diffrentes variations de la vitesse des nuds. Le Chapitre 6 est un rcapitulatif de toutes nos contributions, apportes prcdemment, ainsi quune analyse de l'exprience tire de nos travaux de recherches. Enfin, une discussion sur les perspectives de nos travaux futures clturera cette thse.
Chapitre 2. Etat de lart
Dans ce chapitre nous introduisons diffrentes notions de base que nous avons tudi pour le besoin de cette thse : le streaming vido sur rseaux sans fils, les applications peer to peer, les MANETs et enfin la synergie entres ces trois axes. Ceci nous permettra surtout de nous positionner par rapport ces divers aspects faisant intervenir plusieurs domaines desquels nous nous sommes inspirs pour mener bien nos travaux.
2.1. Le streaming vido

Le streaming est le processus de rception et d'affichage de l'information pendant que celle-ci est envoye par un fournisseur. Les flux transmis et affichs sont du type multimdia (vido, audio ou les deux). D'autres types de mdias (photos, livres lectroniques, applications, etc) n'ont pas besoin de cette mthode de transfert, car n'ayant aucune contrainte de squentialit, ils sont tlchargs entirement avant d'tre traits, excuts ou affichs. Les motivations pour faire du streaming sont multiples: Les flux audio et vido sont gnralement volumineux, ce qui suppose un dlai important de transmission. Cette latence peut ne pas tre acceptable pour l'utilisateur. De plus, l'objet doit tre stock dans le disque de lquipement rcepteur, qui peut parfois tre un problme cause de la taille. Par ailleurs, les flux multimdia ne sont pas souvent lus dans leur totalit. Les usagers visionnent gnralement le dbut d'une vido ou dune chanson pour en connatre le contenu avant de larrter, puis l'arrter au milieu. Dans cette situation il est inutile de tlcharger tout le fichier audio ou vido et ainsi de gaspiller la bande passante du rseau. Les vnements dits en direct, audio ou vido, crs et transmis en temps rel, doivent tre transmis au fur et mesure de leurs productions. Dans ce cas, il est impossible d'enregistrer pralablement le contenu transmettre. Le streaming est considr comme un dfi technologique, de part ses contraintes temps rel: une sorte de synchronisation (horodatage) des donnes doit tre fournie par la source de l'information et correctement traite la rception afin d'afficher les donnes (vido ou audio) de faon adquate. Le flux vido empruntent videmment aujourdhui le moyen de transmission le plus
Chapitre 2 Etat de lart
conomique,
quest le rseau Internet. Ce streaming peut tre envoy de deux manires
diffrentes: unicast ou multicast. L'unicast implique l'envoi d'un flux vido sparment chaque destinataire, alors qu'en multicast, le mme flux est envoy dans le rseau, et est dupliqu proportionnellement au nombre d'utilisateurs.
2.1.1.
Transport de flux sur le rseau
De nombreux protocoles de transfert et de mthodes dites d'encapsulation, ont t proposs pour le streaming: les canaux DVB (Digital Video Broadcast) utilisent le MPEG-TS (Motion Pictures Expert Group Transport Stream), alors que la diffusion de mdias sur Internet passe souvent par RTP (Real-time Transport Protocol), avec l'utilisation supplmentaire de RTCP (Real-time Transport Control Protocol), et RTSP (Real-Time Streaming Protocol). Il existe galement d'autres moyens d'envoyer des informations en mode streaming: directement sur UDP (User Datagram Protocol), qui propose un contrle physique du rseau disponible; et sur HTTP (HyperText Transfert Protocol) via TCP (Transfer Control Protocol) permettant de traverser les pare-feux du rseau et d'exploiter l'utilisation commune et l'implmentation du protocole HTTP. RTSP est utilis en extension de HTTP pour supporter le dplacement fluide dans le flux pendant sa lecture. Malgr les propositions multiples de protocoles applicatifs, ddis au streaming, la majorit des applications utilisent toujours TCP ou UDP, ceci peut sexpliquer par le fait que la couche transport est implmente au niveau des systmes dexploitation qui se sont limits, dans le pass, aux protocoles TCP et UDP. Donc, dans le cadre de notre tude, nous utiliseront ces protocoles largement dploys actuellement sur les rseaux sans fils 802.11 [1] de l'IEEE.
2.1.2.
Sur la couche applicative
Jusqu' prsent, les applications et les protocoles de niveau applicatif se contentaient dexploiter les services qui sont disponibles au niveau des couches infrieures. tant donn que les conditions de transmission sont dynamiques (dbit, taux de perte, latence, gigue), les applications multimdia subissent les variations de ces conditions avec des ractions limites, leur niveau, en utilisant des mcanismes de QoS prsents prcdemment. De nouvelles interactions, entre la couche application et les couches rseaux, permettront ces mcanismes dtre plus dynamiques et plus adaptatifs pour une configuration adquate suivant ltat instantan du rseau. De plus, les applications multimdia doivent tre informes des mcanismes QoS dploys dans le rseau pour assurer une certaine qualit des informations importantes, par exemple une correspondance entre la couche de base dans le codage hirarchique et les classes de service prioritaires au niveau IP et au niveau MAC.
2.1.2.1.
Mesure de la performance
Dans le streaming multimdia en gnral, quelques paramtres interviennent dans la mesure de la qualit de ce service savoir: Le dbit, est la bande passante disponible de bout en bout sur le rseau. Le taux de perte BER (Bit Error Rate), est la proportion de paquets perdus, lors de leurs transmissions, sur le nombre total des paquets constituant la vido. La latence ou dlai de transmission, reprsente le temps ncessaire pour traverser le rseau de bout-en-bout, de lmetteur jusquau rcepteur. Quant la gigue, c'est la variation de la latence dacheminement de bout-en-bout des paquets vido sur le rseau. Une mtrique supplmentaire vient s'ajouter aux paramtres prcdents est celle de la qualit perue par les utilisateurs (QoE: Quality of Experience).
2.1.3.
Utilisation du 802.11 pour le streaming
Dans toute cette thse, les travaux que nous prsenteront portent sur le streaming sur 802.11. Le WLAN sera utilis dans les cas infrastructure et MANETs. Notre choix peut tre justifi par le fait que ce standard de rseau sans fil soit le plus rpandu et surtout le plus polyvalent quant aux applications qu'il peut avoir. L'utilisation de liaisons sans fil pour le streaming vido sur Internet devient de plus en plus courante aujourd'hui. Cette combinaison ramne l'exigence des applications multimdia temps rel (intolrantes aux ruptures), la nature trs imparfaite - et capricieuse - des liaisons radio. Un grand effort est ncessaire pour joindre ces deux mondes, tels que le dlai, la gigue, la perte pour que les exigences des applications multimdias puissent tre satisfaites par l'instabilit et le manque de fiabilit des liens radio. Les liens sans fil constituent des goulots d'tranglement pour un certain nombre de raisons. Tout d'abord, la communication sur un canal sans fil nest tout simplement pas en mesure d'atteindre la mme qualit (dbit, taux d'erreur, etc), assure par son homologue filaire, ce qui rduit la qualit du contenu multimdia livr. Deuximement, dans un environnement mobile, les conditions du canal peuvent changer rapidement en raison de la variation de la distance entre les stations (la mobilit des utilisateurs), l'vanouissement de Rayleigh, et les interfrences. Alors que l'application multimdia doit livrer son contenu en temps rel, elle est trs sensible la gigue dans le transfert des paquets engendre par les retransmissions des protocoles de transport. Troisimement, le streaming multimdia peut se faire sur un support tel 802.11 et interfrer avec les autres utilisateurs qui sont, par exemple, entrain de partager des fichiers.
10
2.2. Les applications p2p

Depuis leur apparition, les rseaux peer to peer, pair pair ou p2p n'ont cess de faire parler d'eux. Ce modle de communication est pass par des diffrentes amliorations pour arriver aux applications que lon connait aujourdhui (BitTorrent, Kazaa, Skype, Joost). Dans ce chapitre nous retracerons les diffrents changements en citant surtout les travaux de recherche effectus dans ce domaine.
2.2.1.
Lindexation et la recherche
Considr comme prcurseur, le dveloppement de la recherche p2p connu trois grandes phases, motiv chaque fois par un manque de performance dans ces protocoles de localisation de contenu. Sans trop s'attarder, nous citons les principales caractristiques de cette volution.
2.2.1.1.
Approche centralise
Appele aussi index central, ce systme est bas sur un serveur central qui joue le rle dannuaire qui rpertorie tous les pairs qui proposent du contenu. Les autres pairs du systme consultent lannuaire, comme un index, pour rcuprer les coordonnes (adresse IP) de leurs futurs voisins. Napster [5] constitue l'exemple type dapproche centralise Soulignons toute fois, que cette approche nest pas considre comme totalement distribue du fait de la prsence du serveur central dadresses, sans lequel le rseau ne pourrait fonctionner. Nanmoins, les fichiers sont directement changs par les pairs.
Figure 1: Rseau P2P de 1re gnration (index central)
11
2.2.1.2.
dcentralise (distribue)
Chaque pair indexe ses propre fichiers il ny a donc plus ncessit dun serveur central. La demande dun fichier transite de proche en proche dans tout le rseau, rendant ainsi le systme plus robuste. Cependant, la recherche est plus difficile, car elle exige un nombre de messages, proportionnel au nombre de nuds du rseau. Cette approche a t introduite et applique par le systme Gnutella [2].
Figure 2: Rseau P2P de 2me gnration (inondation de requte)
Contrairement aux applications de premire gnration, cette architecture est un vritable rseau P2P, puisquelle peut se passer totalement de l'entit centrale. Mais cette deuxime gnration sest vite teinte; car le rseau tait, du point de vu bande passante, plus ou moins htrogne car, constitu la fois d'ordinateurs connects haut dbit et d'autres connects par modem, les premiers simposaient donc avec leur vitesse de connexion ce qui ralentissait manifestement l'ensemble du rseau ; gnrant ainsi, une inertie globale du systme.
a.
Tables de hachages distribues DHT:
Le principe de ces tables de hachage repose sur lutilisation dune fonction de hachage pour faire correspondre chaque nom de fichier son empreinte; cest en fait une sorte de rsum crypt du fichier, sous forme d'une chane de bits (une succession de 0 et de 1) de longueur fixe (souvent 128 ou 160 bits). Ce nombre devient l'identifiant du fichier. Les nuds en charge d'une empreinte sont ceux dont l'identifiant est le plus proche.
12
Cette technique permet loptimisation de larchitecture prcdente, ce qui assurerait la ralisation des recherches par un nombre de messages en croissance logarithmique par rapport au nombre de pairs. Le rseau OVERNET [3] est un rseau prcurseur en matire de DHT [4].
Figure 3: Table de hachage distribue (DHT)
Dans cette approche, grce la structuration des connaissances, les nuds en charge de l'empreinte sont retrouvs en routant la requte de proche en proche en un nombre d'tapes logarithmique [4] par rapport au nombre de nuds. La recherche est donc beaucoup plus efficace: une dizaine d'changes de messages au lieu de quelques centaines voire quelques milliers si la donne cherche n'est pas rplique. Pour annoncer le partage d'un fichier, la source doit contacter le nud en charge de l'empreinte du fichier pour lui indiquer son adresse IP. Un pair qui recherche ce fichier n'aura qu' contacter ce mme nud pour retrouver l'adresse IP du pair (ou des pairs) le partageant.
b.
Hybride
Il sagit dun compromis entre les deux gnrations prcdentes. En effet, une distinction est apporte aux pairs sur deux niveaux : des pairs haut dbit et des pairs connexion classique.
13
Figure 4: Le super peering
Les ordinateurs connexion classique se connectent ceux de haut dbit, des superpeers qui indexent les donnes et qui agissent en tant que serveur distribu. Ces supernuds agissent entre eux comme les pairs de la deuxime gnration, le transfert de messages entre eux est plus rapide vu quils ont des connexions haut dbit. La connexion directe entre pairs ne se fait quune fois ladresse recherche est obtenue.
2.2.2.
Application de partage de contenu
Nous prsentons diffrents types d'applications p2p pour le partage de contenus. Nous en traiterions celles qui ont eu un grand dveloppement que ce soit pour l'change de fichier, la voix sur IP ou le multimdia streaming ; sans pour autant omettre de rappeler qu'il y eut un grand intrt scientifique quant l'tude de ces programmes. Ceci nous oriente sur les investigations entreprendre et leurs corollaires : la comprhension, lanalyse et surtout linterprtation des rsultats de nos recherches, car ce que nous tudierons plus tard, n'est qu'une adaptation des notions utilises dans ces applicatifs. Ce qui nous orientera, petit petit, vers nos propositions de streaming pour MANET.
2.2.2.1.
Partage de fichier (File sharing)
Depuis l'apparition de Napster [5], bon nombre d'applications de file-sharing on vu le jour travers le monde. Avec des diffrentes philosophies et modes opratoires. Parmi les plus populaires nous verrons: Gnutella, Fasttrack, eDonkey et BitTorrent.
14
a.
Gnutella
Gnutella [2], Ce protocole a t imagin en 2000 par Tom Pepper et Justin Frankel, des programmeurs pour la socit NullSoft. Diffus peu de temps sur Internet, il put tre adopt par plusieurs programmeurs et sur diffrentes plateformes [6]. Lide de ce protocole vient du fait que les rseaux qui existaient (i.e.Napster) lpoque, taient vulnrables; et nassuraient pas une libert totale cause des serveurs centraux, souvent espionns. Gnutella est l'un des rseaux dits purement p2p car il nutilise pas de serveur central, avec un contrle totalement distribu. Parmi les logiciels exploitant ce rseau: MLDonkey, Bearshare, Shareaza. Dans la premire version de Gnutella (0.4), un pair est connect un ensemble de voisins, quil interroge en leur envoyant un message de recherche. Ses voisins le renvoient leurs voisins, et ainsi de suite. Un TTL (Time To Live), reprsentant le nombre de retransmissions, est associ cette requte. Quand sa valeur sannule, le message correspondant nest plus retransmis ; Cependant, les pairs qui possdent le fichier recherch, rpondent par un message (contenant le nom de ce fichier et leurs adresse IP) qui parcours le chemin inverse jusquau pair qui lanc cette requte. Ce mcanisme, connu sous le nom d'inondation (flooding), est coteux en bande passante, et les recherche sont plus lentes quen centralis et augmente exponentiellement avec le nombre de peers [7][8]. Cette limite inciter les dveloppeurs proposer la notion dultrapeers ; celle-ci a t incluse dans la version 0.6 de Gnutella avec le client LimeWire en 2001. Dans le rseau Gnutella [6], Les pairs sont classs en deux catgories : Les ultrapeers sont choisis parmi les nuds les plus stables du rseau, du point de vu connectivit. Et les feuilles (leafs), raccords trois ultrapeers sachant que chacun des ces ultrapeers peut se connecter jusqu 45 nuds et 30 autres ultrapeers. Les ultrapeers indexent les fichiers de leurs voisins et se chargent de rpondre aux requtes sur tout cet index. Ces messages sont reus par les ultrapeers ne sont retransmis qu leurs homologues ; cela constitue une protection (shield) aux clients feuille, et prserve la performance des connects bas dbit. GUESS (Gnutella UDP Extension for Scalable Searches) est un mcanisme grce auquel les clients feuille contrlent le nombre d'ultrapeers interroger et donc rduisent leur bande passante. En fonction de la grande (resp. petite) popularit de la ressource recherche le client peut diminuer (resp. augmenter) le nombre dultrapeers interroger. Avec le mcanisme par inondation, le nombre d'ultrapeers interrog est incontrlable. GUESS propose alors, de laisser l'initiateur de la recherche le soin d'interroger successivement un ensemble d'ultrapeers, jusqu' ce qu'il obtienne un nombre de rsultats satisfaisants. Lorsquun nouveau client arrive sur le rseau il ne possde aucune information sur les pairs. Afin dviter ce problme, un script appel bootsrap, est install sur les serveurs web, et permet au
15
client Gnutella de rcuprer une liste des pairs qui se connecter. Ce script est accessible via une URL via le protocole HTTP, et possde deux types de requtes : GET : Rcupre une liste dadresse IP des nuds Gnutella et dURLs dautres serveurs GwebCache. UPDATE : Informe le GWebCache quun nouveau ultrapeer ou serveur GWebCache est prsent sur le rseau. La liste du serveur GWebCache est de taille limite, il ny insert que les dernires adresses reues, pour garantir leurs disponibilits et augmenter la chance quelles soient encore accessibles la prochaine re-connexion.
b.
FastTrack
Ce protocole, utilis par trois clients populaires: Kazaa, Grokster et iMesh, a t introduit en Mars 2001 par Nokklas Zenstrm, Janus Friis et Jaan Talinn. FastTrack [9] est un protocole P2P de seconde gnration, utilisant la notion de superpeers. Si un peer assez puissant (CPU, Dbit) se connecte au rseau il est promu supernud, et agit comme un serveur temporaire dindex pour les autres clients. Pour pourvoir se connecter au rseau, chaque nud contacte les supernuds, stocks dans une liste dans le logiciel utilis. Ds quil obtient une adresse dun supernud actif il lui demande la liste code dadresse dautres supernuds actifs, quil utilisera lors de ses prochaines reconnections. Le client choisi alors lun des supernuds comme son ascendant , et lui envoie la liste des fichiers quil dsire partager afin qu'ils y soient indexs. Il lui envoie galement des requtes sur des fichiers quil veut obtenir. Le supernud communique avec d'autres supernuds afin de satisfaire ces requtes. Une fois la rponse trouve elle remonte jusquau client concern, celui-ci se relie directement au pair pour tlcharger le fichier en HTTP. Pour permettre les tlchargements de sources multiples, FastTrack utilise l'algorithme de brouillage UUHash. Cet algorithme permet la vrification de fichiers volumineux en peu de temps, mme sur des ordinateurs lents, mais il ne peut pas dtecter une corruption massive d'un contenu [10]. Ce qui a encourag plus dun utilisateur diffuser des fichiers corrompus sur le rseau. Le protocole FastTrack utilise un cryptage qui na pas t document par ses crateurs. De plus, les premiers clients taient propritaires. Cependant, les donnes dinitialisation pour les algorithmes de cryptage sont envoyes en clair et sans cl publique ; ainsi son analyse a t relativement facile. En 2003, des programmeurs open-source ont russi dissquer la partie du protocole traitant la communication client-supernud, mais celle qui parle de transmission supernud-supernud demeure en grande partie inconnue.
16
c.
eDonkey
Lanc en Septembre 2000 par Meta-Machine Inc,. Le rseau eDonkey fait partie des rseaux p2p hybride tels que Napster [11] et est compose de clients et de serveurs. Un serveur eDonkey joue le rle d'un hub de communication et d'un serveur d'indexes qui distribue les adresses des autres serveurs aux clients qui le sollicitent. Les clients, eux, tlchargent et partagent les fichiers. tant un protocole ouvert, eDdonkey possde une douzaine de versions de ses clients et serveurs dont le client le plus populaire tait eDonkey2000. Cependant, depuis 2005, eMule, un logiciel gratuit bas sur le client eDonkey t publi en Mars 2002 par Hendrik Breikreuz et est devenu le plus populaire de clients. Dans ses premiers jours, eDonkey comptait sur des serveurs d'utilisateurs volontaires pour garantir le bon fonctionnement de son rseau. Nanmoins, ce petit cluster tait souvent surcharg et vulnrable aux attaques. Pour rsoudre le problme de surcharge des serveurs et de passage l'chelle, la DHT Kademlia [3] a t intgre aux deux clients, Les rseaux eMule et eDonkey2000 sont ainsi appels respectivement Kad et Overnet.
d.
BitTorrent
BitTorrent [12], conu par Bram Cohen en 2002, est un protocole ouvert crit initialement en python, mais disponible aujourd'hui dans diffrents langages de programmations. Pour partager des fichiers avec BitTorrent, il faut tout d'abord crer un Torrent; un fichier de mta informations qui dcrit le contenu partager. Ce mta-fichier porte des renseignements sur: le tracker (superviseur du partage), et les hashes (identifiant crypt) des blocs du fichier chang. Le protocole spcifie la faon dont ce fichier est distribu. En fait, le torrent est publi via le web (site, forums, lieux de recherche spcifiques...). Pour obtenir un fichier, le client BitTorrent doit commencer par introduire le fichier torrent correspondant. Il contacte alors le tracker, qui peut tre unique ou distribu (cas de la version trackerless). Ce nud obtient alors une liste de pairs partageant le mme fichier. tout moment, bas sur un mcanisme d'incitation appel tit-for-tat, BitTorrent donne des blocks de son fichier aux voisins qui lui ont en le plus offert dans le pass. Puis, il en slectionne un au hasard pour assurer ce qu'il appelle optimistic unchoking. Un client BitTorrent tlcharge le bloc le plus rare du voisinage. Cette stratgie, Local Rarest First, augmente la probabilit de la distribution des nouveaux blocks et donc une utilisation efficace du dbit montant de chaque nud. Un certain nombre de caractristiques uniques ont permis BitTorrent, un dernier venu dans le partage de fichiers P2P, de devenir un utilitaire de partage de fichiers trs populaire. Tout d'abord, BitTorrent lui-mme n'offre aucun mcanisme de recherche pour trouver les fichiers partags, il se dgage ainsi de l'accusation de violation de droit d'auteur. Deuximement, son
17
mcanisme de partage de contenu Tit-for-Tat, bien que simple, est remarquablement efficace et encourage les utilisateurs de BitTorrent, contribuer leurs ressources. Ce qui le rend, par consquent, moins vulnrable au problme de free-riding qui affecte les autres applications de partage de fichiers P2P. En troisime lieu, grce l'enregistrement des haches des blocs dans le torrent, BitTorrent permet d'viter la pollution [10] qui menace les applications de partage de fichiers. Quatrimement, le fait de diviser le fichier en plusieurs blocs, et grce une stratgie privilgiant le tlchargement les blocs les plus rares en premier, permet d'optimiser l'utilisation de la bande passante des pairs et de parvenir une efficacit leve. Effectivement, BitTorrent est considr comme la premire application P2P de partage de fichiers largement dploye [6], offrant une telle efficacit et robustesse. BitTorrent a gnr beaucoup d'enthousiasme quant la distribution de fichiers P2P dans les universits et l'industrie. Bon nombre de projets de logiciels libres, par exemple, OpenOffice.org, SUSE et Ubuntu, utilise BitTorrent pour diffuser leur codes source et binaires compils. World of Warcraft, un jeu de rle en ligne, utilise BitTorrent pour distribuer ses patches. Warner Brothers Entertainment prvoit de distribuer des films et missions de tlvision sur Internet via BitTorrent. Un certain nombre de confrences ont aussi distribu leurs enregistrements vido par le biais de BitTorrent.
e.
Statistiques
D'aprs CacheLogic [6], BitTorrent, eDonkey, FastTrack et Gnutella sont les clients de partage de fichiers en p2p les plus populaires aujourd'hui. Dans la figure 5 nous montrons les parts de trafic dans diffrents pays pour ces quatre utilitaires d'changes p2p. Gnralement, BitTorrent et eDonkey sont de loin les plus populaires, le rseau FastTrack vient bien aprs en troisime position pour laisser la quatrime et dernire place Gnutella. Ce classement reste diffrent d'un pays l'autre. Par exemple, en Core du Sud eDonkey dtrne BitTorrent, alors que c'est l'inverse Singapour. Ils sont presque ex aequo aux tats Unis et en Chine.
18
Figure 5: Parts des clients (BitTorrent, Kazaa, eMule et Gnutella) sur le trafic P2P file sharing [6]
2.2.2.2.
Voix sur IP
Skype [13] est le client p2p VoIP le plus populaire. Il a t dvelopp par les crateurs de Kazaa. Skype permet ses utilisateurs de passer des appels et envoyer des messages texte d'autres utilisateurs. En terme de fonctionnalit, il est trs similaire aux applications de messagerie instantane MSN et Yahoo, comme l'appel voix, messagerie instantane, les confrences audio et les listes d'amis. Toutefois, les protocoles et les techniques qu'il emploie sont trs diffrents. Skype peut fonctionner de faon transparente dans presque tout type de NAT et pare-feu, et avec une meilleure qualit de la voix que les autres clients VoIP. Il crypte ses appels de bout en bout, et stocke les informations de ses membres de faon dcentralise. Il existe deux types de nud dans le rseau Skype, des nuds ordinaires et des supernuds (SN). Le nud ordinaire est un client Skype, qui effectue des appels et envoie des messages texte. Tout nud avec une adresse IP publique, ayant suffisamment de CPU, mmoire et bande passante du rseau est un super nud potentiel. Une fois authentifi via le serveur de connexion de Skype, un nud se connecte un supernud. Le serveur de connexion est une entit dans le rseau de Skype grant les noms d'utilisateurs et leurs mots de passe. Ce serveur assure que les noms de connexion de Skype sont uniques dans l'ensemble de l'espace de nom Skype. Outre le serveur de connexion, il y a les serveurs SkypeOut et SkypeIn [2] qui fournissent, respectivement les ponts de PC-PSTN et de PSTN-PC. Ceux l n'interviennent pas dans les appels PC PC. Ainsi, nous pouvons dire que le serveur de connexion est le seul lment central dans le rseau P2P Skype. Les informations des utilisateurs, en ligne et hors ligne, sont stockes et propages de faon dcentralise. Chaque nud de Skype utilise une variante de STUN [14], un protocole qui dtermine les types des NAT et pares-feu derrire lesquels il se trouve le nud.
19
Le rseau de Skype est un Overlay. Par consquent, chaque client Skype (SC) a besoin de construire et d'actualiser une table de nuds accessibles. Dans Skype, ce tableau est appel host cache (HC) et contient l'adresse IP et le numro de port des supernuds. Skype met en place une structure P2P de troisime gnration ou Global Index3, garantissant de trouver un utilisateur si ce dernier s'est connect au rseau au cours des 72 dernires heures. Skype utilise une technique de recherche d'utilisateurs, combinant hachage et inondations priodiques limites, pour obtenir des informations sur les utilisateurs en ligne. Pour les recherches infructueuses Skype lance une requte au serveur de connexion.
2.2.2.3.
Streaming audio et vido
Les informations publies par CacheLogic [6] montrent galement que la taille moyenne d'un fichier partag en P2P est en constante augmentation, et la majorit du volume du trafic P2P est gnre par des objets avec une taille moyenne de plus de 1 GB. Cela suggre que le partage de fichiers P2P volue fortement vers le partage de vido/musique. Jusqu' ce que nous entrons dans l're du streaming P2P, un mode de transfert beaucoup plus favorable pour les fichiers multimdia volumineux. Inspir du principe de partage de fichier, cette technologie consiste en un ensemble de clients qui cooprent pour s'changer du contenu vido entre eux. En dautres termes, un nud est entrain de lire une vido pendant qu'il retransmet les paquets dj reus ses voisins dans l'overlay. Par rapport au partage de fichiers, une contrainte additionnelle vient s'ajouter, celle de la date limite avant laquelle ces paquets doivent arriver dans le buffer du client. Actuellement, plus d'une douzaine de socits travaillent activement dans ce domaine. Certaines entreprises (Abacast4, PPLive5, PPStream6, UUSee7, Roxbeam8, Mysee9, etc). Logiciel P2P orients vers la vido en streaming, parfois appel Internet TV), recre un flux localement et le lit ensuite via Windows Media Player, Real Player, VLC ou d'autres lecteurs multimdias. Les clients P2P actuels sont: PPLive, PPstream, TvAnts10, SopCast11, et Joost12. Certains d'entre eux, comme TvAnts, fond sur la technologie BitTorrent, permettent de regarder
3 4 5 6 7 8 9 10 11 12
Global Index (GI): http://www.skype.com/skype_p2pexplained.html Abacast Online, URL: http://www.abacast.com/ PPLive.com, URL: http://www.pplive.com/ PPStream, URL: http://www.ppstream.com/ UUSee, URL: http://www.uusee.com/ Roxbeam media network, URL: http://www.roxbeam.com/ Mysee, URL: http://www.mysee.com/ TVAnts, URL:www.tvants.com Sopcast, URL: www.sopcast.com Joost. URL: www.joost.com
20
les mdias (chanes TV). Joost est un client hybride conjuguant multicast et p2p pour le streaming des chanes tlvise du monde entier. Dans ce qui suit nous dtaillerons le fonctionnement de deux clients p2p streaming, les plus utiliss. Puis nous rappellerons les notions relatives au fondement du p2p streaming.
a.
Pplive
En utilisant PPLive, sans doute l'un des clients de streaming P2P les plus populaires de nos jours. Vers la fin 2005, PPLive enregistre 20 millions de connects, et 1 million de tlspectateurs par jour. Il supporte plus de 200.000 utilisateurs avec un dbit entre 400 et 800 kbps pour le Festival du printemps 2006 lors du Gala du Nouvel An chinois le 28 Janvier 2006. En 2007, le nombre d'utilisateurs simultans pour une session PPLive s'est lev 1,5 million [15]. Ceci correspond un dbit global (par agrgation) avoisinant les 600 Gbit / s, 540TB transfrs en 2 heures d'vnement. Au cours duquel, le serveur PPLive n'a fournit 10 Mbps de bande passante (0,0017% du dbit global). D'aprs une analyse prliminaire en [16], PPLive fonctionne comme suit. Lorsque le client PPLive est lanc, il rcupre d'un serveur de chane les mtainformations de toutes les chanes. Actuellement, PPLive offre environ 300-400 chanes, avec tous des tlspectateurs regardant la mme chane et sont peu prs au mme point du flux. Le client PPLive prsente une liste de chanes l'utilisateur, qui choisit une chane regarder. Aprs la slection, le clients PPLive contacte le tracker de ce canal, et rcupre une liste des pairs auxquels il se connecte, et commence changer des donnes. Pour se faire, le flux multimdia est dcoup en morceaux dune seconde chacun. Le pair PPLive change une carte de disponibilit des blocks dans sa fentre de lecture, qui est de l'ordre de quelques minutes, et prend la dcision sur les morceaux rcuprer et/ou envoyer grce un algorithme propritaire. Les morceaux reus sont stocks dans le buffer du client PPlive, et sont achemin via un pipe Http vers Windows Mdia player ou Real player, selon le type du fichier source. Dans l'analyse de [15], nous apprenons que l'actuelle plate-forme PPLive provoque un gel de lecture d'environ minute, avec une frquentes de 4 incidents en 7 minutes. L'exprience de PPLive dmontre que le streaming vido grande chelle peut tre ralis. Mais il y a encore de l'amlioration faire, pour augmenter son efficacit et sa robustesse. PPLive encourt galement un long retard de lecture. Aussi, son dmarrage, PPLive peut entraner un retard d'environ 20s 30s pour les chanes populaire, et qui atteint les 2 minutes pour un canal impopulaire, certains pairs peuvent regarder des images avec quelques minutes de dcalage par rapport d'autres.
21
b.
Joost
Joost est l'un des premiers clients de streaming p2p commerciaux. Il peut fournir de la tlvision de haute qualit, la demande. Nous avons tent de dcouvrir [17] les divers aspects de fonctionnement de ce protocole en tudiant le comportement de ses nuds, et en analysant le trafic rseau et les logiciels libres utiliss dans ce client. Sans surprise, nous avons dcouvert que Skype et Joost ont certains mcanismes et techniques p2p en commun. Ceci nous permis de: (i), dduire l'architecture globale de Joost et certains de ses composants cls en se basant sur une tude mticuleuse de son trafic rseau, (ii) approfondir nos connaissance quant au droulement du streaming et le comportement des pairs, (iii) valuer sa performance et son utilisation de la bande passante. Bien que Joost soit une technologie peer-to-peer de distribution vido, il s'appuie fortement sur quelques serveurs centraliss pour fournir les contenus vido. Nous pensons que le caractre centralis de Joost est le principal facteur influant sur son niveau de considration de la localit et son faible ratio d'quit. Du point de vue du rseau, Joost consomme environ 700 kbps en download et 120 kbps en upload, quelle que soit la capacit totale du rseau. C'est en supposant que la capacit du rseau en amont, est de plus de 1Mbps. Joost utilise le port 33333 pour envoyer des donnes vido partir de sa baie de serveurs (une aux US et une en Europe). Pour rduire considrablement la quantit de donnes dans le rseau, il faut bloquer le port 33333. Joost repose principalement sur ses serveurs ddis de contenu en tant que nuds source afin de distribuer la vido. Les technologies P2P sont utilises pour l'assister, assurant ainsi la distribution de vido et le passage l'chelle. Dans Joost, les supernuds sont seulement utiliss pour contrler le trafic, ils ne relayent jamais les contenus vido. Les principaux flux sont envoys partir des Joost Seeders. Tout le trafic est crypt afin de partager du contenu vido scuris contre le piratage. Les pairs mettent en cache le contenu reu et le retransmettent quand cela est ncessaire. Aidant, ainsi, les autres pairs a recouvrir les blocs perdus suite une congestion. Joost n'utilise pas les ressources des pairs de manire efficace, en particulier lorsque des nuds de grande capacit sont disponibles. En d'autres termes, Joost pourrait tre lgrement plus demandeur en termes de dbits montants, vis--vis des pairs grandes capacits. En effet, dans des moments de grandes affluences des nuds, le protocole pourrait envisager l'utilisation de ces aptitudes pour rcuprer, la vole, la liste des chanes, actuellement tlcharge depuis le serveur, ce qui permet de dcharger le serveur. Joost fournit actuellement chaque client avec la mme qualit de la vido. Ceci provoque une utilisation inefficace des ressources dans la mesure o certains clients sont incapables de supporter une telle qualit de la vido. Au final, nous pensons
22
que des techniques d'adaptation en couches de la vido, conjugus certaines stratgies d'incitation, devrait tre introduits dans Joost.
2.2.2.4.
Les deux topologies du streaming P2P
Deux modles rgissent le streaming p2p, que ce soit pour la vido la demande ou le streaming. Ces topologies sont le Mesh-Based, un rseau maill et le Tree-Based, un arbre de diffusion applicatif.
a.
Topologie mesh
Provenant de la recherche sur les protocoles pidmiques, l'approche fonde sur le maillage (dans ce qui suit nous utiliseront mesh) repose sur l'change priodique d'information sur l'tat des nuds, ce qui conduit une diffusion de l'information tous les nuds. BitTorrent, protocole de partage de fichiers, est celui qui a vulgaris l'utilisation du mesh [12]. En effet, ce protocole construit un mesh non structur pour changer des fichiers de donnes. Le fichier est divis en blocs, changs par les nuds dans un mode pull (voir dfinition dans 2.2.2.6-b) jusqu' ce que les nuds puissent reconstituer le fichier original. Pour le streaming vido sur le mesh, la topologie est construite alatoirement: chaque nouveau nud se connecte une liste de voisins, obtenus au hasard, avec qui, il commence directement changer des blocs de la vido. Ces paquets circulent dans le rseau d'une manire alatoire qui dpend de l'algorithme de slection de nuds et de blocs.
b.
Topologie Arbre
Dans cette approche de distribution de contenu, les nuds s'organisent en une sorte d'arbre multicast applicatif (ALM Application-Layer Multicast). ESM [18], Scattercast [19] et Overcast [20]. Sont des travaux qui emploient ce type d'arbre, o la racine est la source du stream, les autres nuds cooprent dans la re-transmission des pices de la vido dj reues. Dans ces systmes, comme CoopNet [21], SplitStream [22], MutualCast [23] et FastReplica [24], le nud source cre l'arbre, et les nuds qui arrivent deviennent ses descendants directs, et ainsi de suite. En fonction de son temps d'arriv le pair s'attache le plus profondment dans l'arbre. Une livraison en cascade de la vido entre les nuds de l'arbre, sens unique des parents vers les enfants. En d'autres termes, cela consiste en une procdure de rplication engage par la racine, qui maintient overlay, jusqu'au dernier nud feuille de l'arbre. Chaque nud de l'arbre retransmet autant de copies du bloc reu que d'enfant il possde. Cette approche n'est pas volutive car en arrivant, un nud s'attache un seul parent et un certain nombre fixe de fils. Aussi, dans le cas du dpart d'un nud, la maintenance sera trs complexe causant une rupture dans la distribution de la vido tous ses descendants.
23
c.
Comparaison
Pour avoir une ide sur le fonctionnement des deux topologies, dans le tableau suivant, nous prsentons une comparaison entre les mesh et les arbres.
Figure 6: topologies Mesh vs. Tree.

Aspects Source auto-organisation Topologies Arbre Un seul nud offre la vido A l'arrive il s'attache en bas de l'arbre, en profondeur Difficile maintenir, aprs le dpart Maintenance d'un parent, tous ses descendants deviennent orphelins. Dynamique La stabilit du systme est dtriore par la dynamique des nuds. Mesh Plusieurs nuds contribuent A l'arrive le nud obtient une liste de nuds avec qui il va cooprer Messages hello (ping) suffisent chaque nud pour maintenir ses voisins. Pas d'effets sur la topologie grce aux connexions alatoires renouveles chaque dpart/arrive Bonne coopration du dbit montant Utilisation optimale de la bande passante Pas de contribution de dbit montant des nuds feuilles et descendant. Surtout que chaque nud envoie/reoit /de plusieurs voisins la fois. La topologie des arbres ne rsiste pas Mobilit au dpart des nuds mme s'il est active autre part. Pendent son dplacement le nud prvient ses voisins et obtient une nouvelle liste ds qu'il arrive sa destination.
Tableau 1 Comparaison entre topologies Mesh et Tree
24
De ce tableau comparatif il apparat clairement que la topologie mesh est beaucoup plus robuste que celle base sur les arbres. Dans la structure d'arbre, un nud ne reoit que de son parent direct. Donc, lorsque celui-ci tombe en panne, se dplace ou quitte tout simplement les feuilles, tous le sous-arbre (compos par l'ensemble de descendants du nud en question) ne parvient pas obtenir le flux jusqu' ce que l'arbre soit reconstruit. Dans les rseaux streaming sur mesh, la vido est obtenue partir de plusieurs voisins, et dans ce cas, si l'un d'entre eux choue, d'autres continueront fournir le stream, encore faut-il qu'au moins une copie de chaque bloc existe. De ce fait, nous concluons que le systme orient mesh demeure le meilleur candidat. Nanmoins, un problme que rencontrent les structures en mesh, en gnral est celui de ne pas compter sur une structure rseau prdfinie et sont donc, plus difficiles tudier que les topologies arbre. Or, dans [25], les auteurs montrent que, mme dans les mesh, des motifs d'arbres de diffusion apparaissent dynamiquement dans loverlay. Ces modes de diffusion peuvent alors tre tudis de la mme manire que les structures bases sur les arbres. La contribution de ce travail est de construire une topologie de streaming p2p sur MANETs. Compte tenu des similitudes entre ces derniers, la structure mesh est donc plus adapte dans ce scnario. Par ailleurs, il a t prouv que la rduction des hauteurs d'arbres de diffusion dans un mesh de streaming rduit considrablement le retard subit par la mise en cache de la vido [25] ce qui motive davantage le choix de cette topologie.
2.2.2.5.
Stratgies de slection de bloc et de nuds
Que ce soit en mode push ou pull, le nud doit dcider d'une stratgie de slection de bloc, c'est-dire, quel bloc demander/offrir, et de/ qui le bloc est reu/donn. Nous appelons cela la slection de pairs et la slection de blocs. D'un protocole p2p un autre, que ce soit pour le streaming ou le file sharing, les nuds utilisent diffrentes stratgies pour slectionner des nuds et envoyer ou demander des blocs. Chaque stratgie possde ses avantages et inconvnients. Ce qui nous intresse est de savoir quels sont les changements faire, sur la stratgie d'change de blocs, quand nous passons du file-sharing au streaming. Ceci sera tudi en dtail dans notre contribution dans le paragraphe 5.2.4.
a.
La slection de pairs
Dans cette slection un pair choisit le nud qui il va donner des blocs. Pour le mode pull, le rcepteur choisit gnralement les pairs metteurs en fonction de leurs capacits d'envoi. Par exemple, PeerStreaming [25] choisit des pairs qui offrent un moindre dlai entre le moment de la demande et celui de la rponse. Pour le mode push, l'expditeur peut slectionner ses destinataires sur la base de leurs quits ou performances. Par exemple, BitTorrent utilise une stratgie
25
rcompensant l'quit, qui est le tit-for-tat. Le nud BitTorrent donne aux voisins qui lui ont donn le meilleur upload. Cela empche le free riding, et encourage les pairs contribuer. Une stratgie alternative repose sur la mesure de la performance. Par exemple, DISCOVR [26] alloue plus de bande passante l'envoi aux pairs qui ont pratiquement fini de remplir leur buffer. Cette stratgie de slection permet aux nuds avec des ressources importantes d'pauler les pairs avec peu de ressources, et amliore ainsi la qualit de service dans l'ensemble du systme.
b.
La slection de bloc
Cette stratgie choisit un bloc sur une liste de blocs disponibles chez un voisin. Quelques schmas de slection bloc [27]: (a) Sequential: Slectionne le premier bloc disponible; (b) Rarest: Choisie le bloc le plus rare dans le voisinage local du pair. Il n'existe aucune mthode pour dpartager les blocs avec la mme raret. BitTorrent utilise cette stratgie de slection de blocs. (c) Random: Slectionne un bloc au hasard; d) Random rarest: Choisi le bloc le plus rare dans le voisinage local du pair. Si plusieurs blocs sont de mme raret, un bloc est slectionn au hasard. Les rsultats de BitTorrent et BulletPrime [27] montrent que la stratgie de slection random rarest est la meilleure en termes d'efficacit, la slection random et rarest succdent de prs, tandis que la stratgie de slection squentielle vient en dernire position pour ce qui est du file sharing. En fonction du sens de la circulation des blocs, ceux l peuvent tre soit demands, offert ou les deux. Les trois modes de diffusion sont utiliss dans le P2P.
2.2.2.6.
Technique de transfer des blocs a. Le mode push
Dans le mode push (aussi appel le mode sender-driven), l'expditeur est l'initiative, et envoie le bloc dj reu aux voisins choisis auparavant. Nous notons que le mode push dans un arbre est assez diffrent de celui du mesh. Le premier n'a pas besoin de consulter les rcepteurs pour la validit du bloc, ce qui permet de raliser un plus faible retard d'acheminement. Nous observons galement que, dans les distributions orientes mesh ou hybride (paragraphe suivant) sont plus efficaces en utilisation des dbits montants du rseau P2P. Parce que dans les deux cas, l'expditeur est l'initiateur, il peut facilement faire en sorte que son dbit sortant disponible soit pleinement utilis. DISCOVR [26], une plate-forme P2P combinant partage de fichiers et streaming multimdia, utilise un mesh en mode push. Le pair collecte les informations relatives la disponibilit des blocs chez ses voisins, et propose un ensemble de blocs qu'il souhaite leur envoyer. la rception de cette liste, le voisin rejette certaines propositions de blocs s'ils sont dj proposs ou en cours de tlchargement, et confirme pour le reste. Le transfert de blocs est alors initi par l'expditeur aprs avoir reu la confirmation de la liste. Avalanche [28], un outil de
26
partage de fichiers P2P utilisant le network coding (mcanisme mlangeant les blocs lors de leur tilisant livraison), est aussi un protocole push dans une topologie mesh. Dans lequel, l'expditeur propose d'abord au rcepteur le vecteur du code du bloc transmis. Le rcepteur vrifie si ce vecteur contient de nouvelles informations, et l'accepte ou le rejette. L'expditeur et lui envoie alors le bloc cod aprs sa confirmation.
b.
Le mode Pull
Dans le mode pull (aussi appel ax ax-rcepteur 'receiver-driven'), le rcepteur est l'in driven'), l'initiative de prendre le bloc qu'il veut de son voisin. Ce mode est plus avantageux par rapport au maintien de la qualit de service (QoS) pour le rcepteur. Parce que celui ci peut choisir les blocs recevoir, il ) celui-ci a donc un meilleur contrle du processus de livraison, et peu facilement assurer la livraison temps d'un bloc ceci est essentielle dans le multimdia streaming P2P. Par exemple, BitTorrent . fonctionne selon un modle pull. Un nud change avec ses voisins des informations, sur les blocs change qu'il dtient, et dcide quel bloc rcuprer par i ceux disponibles dans son voisinage. parmi
c.
Le mode hybride
Dans un mode hybride, o la fois, le rcepteur et l'metteur peuvent prendre l'initiative de ngocier le transfert de blocs. Les rseaux P2P bass sur les arbres adoptent gnralement un ier mode push, dans lequel les pairs poussent simplement les blocs reus vers les pairs qui se trouvent , en aval. Dans les mesh P2P le choix du mode de transfert est plus souple, les nuds peuvent soit mode utiliser le pull, le push ou bien combiner les deux. , GridMedia [29], une des premires plateformes P2P streaming, adopte ce mode hybride de push, , pull sur une topologie oriente mesh. Les blocs y sont classs en deux catgories: des blocs pull et des blocs push. Lorsqu'il rejoint le rseau, l nud utilise le pull pour obtenir les premiers blocs, le puis utilise le mode push pour envoyer les blocs ses voisins afin de rduire les dlais. se
Figure 7: Push vs. Pull.
27
2.3. Les rseaux ad hoc mobiles

Un rseau ad-hoc mobile est un rseau cr par une runion spontane de mobiles capables de communiquer grce leurs interfaces sans fils, sans aucune infrastructure ni configuration pralable. Les nuds d'un tel rseau cooprent pour la gestion du rseau. Un MANET (Mobile Adhoc NETwork), se caractrise par sa mthode de dcouverte de nuds, son algorithme de routage, et le modle de mobilit rgissant le mouvement des mobiles.
2.3.1.
Classification des protocoles de routage
Depuis leurs apparitions, les MANETs ont t trs tudis surtout les aspects : routage, dcouverte et maintenance des nuds mobiles. Une multitude de protocoles de routage a t propose dans la foule. Ces derniers sont classs en trois grandes familles: (a) les proactifs (b) les ractifs, et (c) les hybrides (Figure 8). Ne pouvant pas tous les citer, dans ce qui suit, nous allons prsenter en dtail un protocole de routage pour chacune des familles prcdemment cites.
Figure 8: Classification des familles de protocoles ad hoc
2.3.1.1.
Protocoles proactifs
Dans ce type de routage, chaque nud construit une table de routage par la dcouverte d'autres nuds dans tout le rseau, une opration coteuse pour le rseau a haute dynamique, parmi ces protocoles OLSR et DSDV.
28
a.
OLSR (Optimized Link-State Routing)
Un des protocoles ractifs les plus utilis dans la communaut, OLSR [30] est propos par des chercheurs de l'INRIA et fait l'objet de travaux de standardisation depuis 2003 au sein de la IETF dans le groupe MANET. C'est un protocole proactif bas sur une approche modifie, dont la version originale ou chaque nud propage des informations sur l'tat des liens tous les nuds du rseau. L'altration apporte par OLSR consiste rduire l'overhead en ne diffusant cette information que par quelques nuds du rseau. Dans ce protocole proactif, chaque nud transmet sa liste de voisins en mettant priodiquement une sorte de beacon. De cette manire chaque nud est au courant des nuds qui circulent dans son voisinage 2 sauts. Il utilise un algorithme de slection de relais multi-points MPR (MultiPoint Relay). L'ensemble des relais d'un nud N donn est construit partir de l'ensemble minimal des voisins un saut de N. De telle sorte que chaque voisin deux sauts de N ait au moins un mme MPR. Chaque nud dans OLSR choisi indpendamment ses relais multi-points. La seule connaissance dont il a besoin est celle relative ses voisins deux sauts. Quand un nud diffuse un message, tous ses voisins le reoivent. Les MPR n'ayant pas reu ce message auparavant le rediffusent. Donc, l'overhead caus par l'inondation diminue considrablement dans OLSR. Le nud diffuse priodiquement l'information sur l'tat des liens avec leurs MPRs dans le rseau. La priodicit de l'envoi de ces messages est sujette la dtection du changement de l'ensemble des MPRs. Dans ce cas prcis, la priode prend alors sa valeur minimale. Dans le cas contraire cette valeur augmente jusqu' ce qu'elle atteigne la valeur de l'intervalle de rafraichissement (refresh interval). Chaque nud reoit, en plus, une information sur la topologie du rseau et construit alors sa table de routage grce au message d'tat de lien. Ce routage utilis dans OLSR n'inclus que les MPR comme nud intermdiaire entre deux nuds donns. Plusieurs implmentations prtes dployer existent ainsi quun bon nombre de travaux de tests de performance de OLSR et de son support de la QoS.
2.3.1.2.
Ractif
Cette approche propose de ne construire une route vers la destination que si un nud a besoin de communiquer. Ceci permet de rsister la mobilit mais gnre une surcharge supplmentaire (overhead) dans le rseau chaque tentative de communication.
a.
AODV (Ad Hoc On-demand Distance Vector)
Dans la famille des routages ractifs, le protocole AODV [31] est l'un des plus clbres. Dans cette approche, quand un nud source S a des donnes envoyer au nud destination D, mais ne possde pas tout le cheminement vers celle-ci, il doit lancer une Route REQuest (RREQ). Ce
29
paquet est alors inond travers le rseau. Chaque nud recevant une RREQ, la fait suivre ses voisins, s'il ne l'a pas dj fait au moins une fois, ou s'il n'est pas le nud destination de ce message, et sous la condition que le compteur Time to Live (TTL) ne soit pas zro. Le paquet RREQ comporte l'identifiant de la source (SrcID), l'identifiant de la destination (DestID), numro de squence de la source (SrcSeqNum), numro de squence de la destination (DesSeqNum), l'identification de la diffusion (BcastID), et le TTL. Le DesSeqNum indique la fracheur du chemin accept par la source. Lorsqu'un nud reoit un paquet RREQ, et s'il en est le destinataire ou connat un chemin valide jusqu'au destinataire, il renvoie la source du message une rponse Route REPly (RREP). Sinon, il retransmet le RREQ ses voisins. Le nud intermdiaire est en mesure de dterminer si un cheminement est valide ou non, en comparant son propre numro de squence avec le DesSeqNum dans le RREQ. Un nud intermdiaire est en mesure de savoir si le RREQ est dj trait ou non, en comparant le BcastID au SrcID. Lors de la retransmission du RREQ, chaque nud intermdiaire y injecte l'adresse du nud le prcdant et son BcastID. Un timer est utilis pour supprimer cette entre dans le cas o un RREP paquet n'est pas reue avant sa date d'expiration. Lors de la rception d'un paquet RREP, un nud intermdiaire mmorise aussi des informations sur le nud partir duquel ce paquet est reu. Ce nud tant le saut suivant lors de la transmission des donnes au nud destination qui a initi le RREP.
2.3.1.3.
Hybride
Il rsulte d'une combinaison des avantages des deux familles prcdentes, ce qui offre un bon compromis entre persistance de la route et surcharge du rseau. En gnral, les propositions hybrides exploitent la hirarchisation du rseau en utilisant des protocoles ractifs et proactifs et sont alors intgrs diffrents niveaux de la hirarchie.
a.
ZRP (Zone Routing Protocol)
Ce protocole, propos par Haas et al. [32] en 2002, combine les deux approches vues prcdemment, proactive et ractive, pour en tirer le maximum d'avantages et combler ainsi les dsavantages de chacune par les points forts de l'autre. Il consiste en la division du rseau, en fonction de la distance entre les nuds, en plusieurs parties appeles zones de routage. ZRP utilise deux approches proactive (IARP) pour le routage dans la mme zone (intera-zone routing protocol) et ractive (IERP) entre les zones (inter-zone routing protocol). L'IARP maintien une information sur l'tat de lien des nuds une distance d. Dans le cas ou le nud source et la destination sont dan la mme zone, la route est alors disponible immdiatement. La plupart des protocoles proactifs existants pourraient tre utiliss en tant que IARP dans ZRP. Lorsque la
30
source et la destination appartiennent deux zones diffrentes, l'IERP effectue une dcouverte de route de la mme manire que c'est dans les protocoles ractifs, sauf qu'elle passe par les nuds priphriques.
2.3.2.
Modles de mobilit
Largement utiliss dans la mesure de performance des rseaux ad hoc mobiles en particulier et sans fils en gnral, les modles de mobilit sont souvent utiliss pour simuler et valuer la performance des algorithmes et des protocoles dans les rseaux ad hoc mobiles. La dfinition raliste du modle de mobilit est l'un des aspects les plus critiques et difficiles de la simulation d'applications et de systmes conus pour les environnements mobiles. Essentiellement, Il existe deux types de schmas de mobilit: ceux bass sur les traces et les synthtiques [33]. Les traces sont obtenues au moyen de mesures de dploiements des systmes et sont gnralement constitus des traces de la connectivit ou des informations localises, alors que les modles synthtiques sont des modles mathmatiques, tels que des systmes d'quations, qui essaient de capturer le mouvement des mobiles. Un survol des modles de mobilits proposs pour MANET peut tre consult dans [33], [34]. Ces modles varient en fonction de leur complexit, leur structure de corrlation ainsi que des restrictions sur les mouvements. Cependant, aucun d'eux n'est assez dtaill pour s'adapter toutes les situations. Actuellement, les donnes qui existent sont des captures de traces de circulation des personnes, issues des traces GPS et Bluetooth (c'est--dire, contenant les identifiants Bluetooth des mobiles se trouvant dans la porte d'un appareil). Par exemple, les chercheurs des Laboratoires de recherche d'Intel et de l'universit de Cambridge, ont distribu des quipements Bluetooth des personnes, afin de recueillir des donnes sur les mouvements humains et d'en extraire les caractristiques des modles de leurs mouvements dans le rseau. Des exprimentations ont t menes en premier lieu par des tudiants et des chercheurs de Cambridge [35] et, ensuite, par des participants de INFOCOM 2005 [36]. Exemples de projets similaires sont le Wireless Topology Discovery UCSD [38] et le Campus-Wide Wi-Fi Traffic men au Dartmouth College [39].
2.3.2.1.
Modles synthtiques a. Modles bass sur la marche alatoire
Le Random Walk est un modle de mobilit simple [40][41], aussi appel le Brownian motion [40], il est largement utilis comme modle pour reprsenter les mouvements purement alatoire des entits d'un systme dans les diffrentes disciplines de la physique la mtorologie. Toutefois, il
31
ne peut tre considr comme un modle pour simuler des environnements sans fil, car les mouvements humains ne prsentent pas de continuit dans les changements de direction qui caractrisent ce modle de mobilit. Dans [42][43], les auteurs prsentent Random Trip, une gnralisation des Random Walk et Random Way-Point. Les auteurs introduisent une technique qui drive l'tat initial des la simulation d'un rgime stationnaire (une mthode qui est gnralement appele simulation parfaite) sur la base du Palm Calculus [44] afin de rsoudre le problme de stationnarittemporelle. Cette mthode de simulation du Random Way-Point a t propose par Navidi et Camp dans [45].
b.
Le Random Way-point
Dans ce modle, un nud mobile se dplace de sa position actuelle vers une nouvelle destination choisie au hasard dans l'espace de simulation, avec une vitesse alatoire distribue uniformment entre deux vitesses, minimale et maximale [Vmin, Vmax]. Le Random Way-Point inclus le temps de pause lors d'un changement de vitesse et de direction. Ds qu'un nud mobile arrive sa nouvelle destination, il se met en pause pour une priode de temps (temps de pause) avant de reprendre son mouvement. Les proprits analytiques du Random Way-Point ont t traites dans plusieurs travaux du point de vue de la distribution stationnaire des nuds [46][47], leurs distributions spatiales [48] et de l'volution de la rpartition des nuds par le biais d'quations aux drives partielles [49].
2.3.3.
Group Mobility Model
Nous avons vu que ces modles sont utiliss pour reprsenter les mouvements des nuds mobiles seuls, cependant, dans certaines situations, le comportement des htes mobiles se dplaant ensemble, tels que des pelotons de soldats, un groupe d'lves ou des collgues en confrence doivent tre pris en compte lors de la modlisation de la mobilit. Pour ces raisons, les modles de mobilit de groupe ont t proposs, comme le Reference Group mobility model [50], le modle Reference Velocity Group [51] et le modle de mobilit Structured Group [52]. Ces modles sont bass sur une srie d'quations qui relient les mouvements d'un nud la position d'un sousensemble des autres nuds du rseau. Ces modles sont utiles pour reproduire les scnarios caractriss par la prsence de groupes d'individus, cependant, les mouvements gnr ne refltent pas ceux observs dans la ralit, dans lesquels les groupes de se dplacer de faon alatoire dans l'espace de la simulation. Les mcanismes d'appartenance sont galement figs, un nud unique ne peut pas rejoindre d'autres groupes durant la simulation. Rcemment, Piorkowski et Alii ont propos un modle synthtique
32
appel Heterogeneous Random Walk [53], qui est capable de reproduire la prsence de clusters observs dans les traces relle. L'objectif de ce modle est de disposer d'un modle mathmatique permettant d'tudier et d'expliquer l'mergence de rseaux en clusters.
2.3.4.
Community based mobilty model
Dans [54][55], Musolesi et al. dcrivent un nouveau modle de mobilit bas sur la thorie des rseaux sociaux. Issue de la combinaison des modles synthtiques bass sur les groupes, des traces relles et des rseaux sociaux. Partant du constat que les appareils mobile sont transports par des humains, leurs mouvements sont donc fortement affects par leurs relations. Ce modle de mobilit permet des collections d'htes de se regrouper selon les relations sociales entre leurs possesseurs. Ce regroupement est ensuite reflt sur un espace topographique; avec des mouvements influencs par la force des liens sociaux, et pouvant aussi changer dans le temps. Compar des traces relles, ce modle de mobilit affiche une trs bonne approximation du mouvement humain.
2.4. P2P sur MANETs quelle motivation ?

Aprs avoir dfini les applications peer to peer et les rseaux MANET, dans ce paragraphe nous regardons dans quel possibilit nous pourront combiner ces deux paradigmes pour palier au problme de la mobilit dans les applications peer to peer. Initialement pose lors du sminaire de Dagstuhl [56], cette problmatique connat un dveloppement sur diffrents plan. Elle consiste tudier les possibilits de tirer le plus grand profit en combinant les technologies p2p aux rseaux ad hoc mobiles. Parmi ces applications, le transfert efficace de donnes nous intresse plus particulirement dans cette thse. Comme nous l'avions vu, un MANET est une collection de nuds mobiles qui s'auto-organisent en un rseau sans fil sans recourir une infrastructure prexistante. Dans un MANET, les applications suivent gnralement un modle gal--gal plutt que client-serveur. Un MANET est souvent construit pour une application spcifique, c'est un rseau orient application. Pour ces raisons, le comportement d'un rseau ad hoc est souvent qualifi de peer-to-peer (P2P). Ce n'est cependant pas tout fait compatible avec le sens gnral de P2P dans un contexte plus large, celui de lInternet. Dans l'infrastructure fixe (i.e. Internet), un rseau P2P est essentiellement un rseau overlay (sur la couche application) motiv par la ncessit d'avoir des fonctions spcifiques qui ne sont, parfois, pas possibles (ou non rentables) raliser dans les couches infrieures (couche IP). Ces fonctions doivent tre effectues par soit par l'application soit par un protocole d'inter-couche middleware. Des exemples classiques de ces solutions ddies Internet sont les overlays temps rel multicast
33
(qui permettent de surmonter le manque des routeurs pour soutenir le multicast IP), les systmes P2P non structurs tels que Gnutella, BitTorrent, et KaZaa, et ; structurs tels que Pastry [57], Chord [58], ou CAN [59]. Ces derniers sont gnralement implments comme des rseaux contenu adressable et assurent une certaine efficacit quant au routage des donnes, qui est par ailleurs, pas possible sur la couche IP. D'un autre cot, MANETs sont bass sur une architecture de rseau qui est tout fait diffrente de celle dfinie pour l'Internet filaire. En fait, une architecture typique MANET nous rappelle les architectures introduites dans les annes 80 pour inter-connecter des rseaux locaux, avec un routage au niveau 2 bas sur les adresses MAC (Medium Access Control). ce niveau, le routage MANET est non-hirarchique et est prsent donc, plusieurs couches sous-jacentes l'application P2P. Cela implique que, dans un MANET le concept P2P doit tre intgr au-dessus de la couche 2.
2.4.1.
Diffrences
La plus importante diffrence entre un rseau MANET et le P2P est leur raison d'exister. Alors qu'un MANET est cr pour inter-connecter des terminaux des fins de communications (axes utilisateur). Ce qui motive la cration d'un rseau P2P est diffrent. En raison de la grande capacit d'un rseau P2P, l'objectif principal de la plupart de ses utilisateurs est de rechercher et partager des donnes dans le rseau sans avoir ncessairement envie de communiquer avec d'autres utilisateurs. Dans les rseaux P2P, l'change des donnes se fait via un lien direct partir d'un pair l'autre. Les pairs intermdiaires sont juste utiliss pour configurer une connexion entre ces deux et ne sont ni ncessaires ni voulu dans la transmission des donnes. Dans un rseau ad hoc l'action des nuds intermdiaire est essentielle. Ceux-l participent activement dans la dcouverte d'itinraire, ainsi que l'tablissement de la connexion. Par consquent, les connexions dans MANET sont indirects, alors que le P2P celles-ci sont directes. Aussi, Il faut noter, que le lien direct d'une connexion P2P est beaucoup plus facile maintenir qu'un lien indirect multi sauts dans un rseau ad hoc. De plus, dans le cas de mobilit des nuds intermdiaires, le nombre de r-tablissement de routes augmente considrablement. Une autre distinction entre ces deux rseaux se trouve dans leur structure. Une couche virtuelle est cre pour connecter les ordinateurs d'un rseau P2P. Le sparant ainsi, du rseau physique. De ce fait, des ordinateurs qui sont des milliers de kilomtres les uns des autres peuvent tre voisins sur la couche P2P. En revanche, la position physique des nuds dans un MANET peuvent tre estimes approximativement, cause de la densit de leur distribution dans une surface donne. ct de cela, la structure physique d'un rseau ad hoc reflte directement sa topologie logique.
34
Il existe aussi des diffrences dans l'utilisation des algorithmes de routage entre les rseaux P2P et de MANET. Plusieurs publications [60][61] montrent que la dynamique de routage ad hoc systme ne fonctionne que dans les petit MANETs, avec moins de 100 nuds. Avec un plus grand nombre de nuds, les mises jour doivent tre envoyes plus frquemment. Ce qui fait que le rseau soit proccup plus par la signalisation que par le trafic de donnes. part le problme du passage l'chelle, les algorithmes de routage proactifs sont ralisables dans les rseaux ad hoc, alors qu'ils ne fonctionnent pas du tout dans un rseau P2P. En effet, la charge gnre par l'utilisation, dans de grands rseaux P2P, d'un routage bas sur l'algorithme de Bellman-Ford [62], est trop leve. L'utilisation d'un tel algorithme de routage dynamique dans un rseau P2P, impliquerait, la transmission des listes d'adresses de tous les pairs vers tous les autres pairs, qui ne manquera pas d'chouer. Comme mentionn prcdemment, l'algorithme de routage P2P est excut uniquement lors d'une requte de recherche, donc il peut tre dclar comme un algorithme de routage ractif. En dpit de l'utilisation d'algorithmes de routage ractifs similaires dans les deux rseaux, l'excution est diffrente. Dans un rseau ad hoc de la recherche se termine, c'est--dire le message de requte n'est plus retransmis, lorsque son destinataire est trouv, ou si l'un des nuds intermdiaire connat un itinraire vers cette destination. En revanche, cette requte ne s'arrte pas dans un rseau P2P, mme si ce nud qui possde le contenu fichier recherch est localis. La requte est toujours retransmise et ne s'arrte lorsque le champ TTL est gal zro. La fiabilit des canaux dans la structure physique diffre entre rseaux P2P et MANET. Si liens cbls sont de trs haute fiabilit, des liens sans fil souffrent toujours de changements imprvisibles, ce qui provoque de nombreuses erreurs. Par consquent, le taux d'erreur d'une liaison sans fil est d'une plus grande ampleur. Ainsi, la cration d'une nouvelle route sur plusieurs sauts s'annonce tre plus facile dans un rseau P2P. La position, fixe pour un nud P2P, ou mobile pour nud ad hoc mobile galement, influe sur la disponibilit des ressources (bande passante, batterie, mmoire et puissance de calcul). Si un terminal P2P a des ressources presque illimites, un nud ad hoc celles-ci sont trs limites. En rsum, malgr les diffrences sparant les rseaux ad hoc sans fil et peer-to-peer, (rsumes dans le tableau 2), nous verrons par la suite, qu'il se trouve que ces deux l possdent beaucoup de similitudes, ce qui est dcrit dans le paragraphe suivant.
35
Diffrences
Peer-to-Peer
MANET
Raison de cration
Recherche et partage de ressources inter-connexion de terminaux pour sur Internet tablir une connexion
Connexion entre les Filaire et directe sur la couche Sans fil impliquant plusieurs nuds nuds Fiabilit connexions Structure Sur-couche virtuelle indpendante de La couche logique correspond a la la couche physique Taille physique Routage requtes Mobilit des nuds Fixe Mobile des S'arrte quand sont TTL est nul S'arrte si la destination est trouve du rseau Peut couvrir le monde structure physique Les nuds sont densment distribus application des Haute, grce aux liens filaires intermdiaires Faible, due aux liens radio
Disponibilit ressources
des Pratiquement illimite
Trs limit
Tableau 2 MANETs vs.P2P: Diffrences
2.4.2.
Similitudes
Peer-to-Peer et MANET, se basent sur le concept d'auto-organisation. Dans la plupart des cas, l'exception des protocoles P2P hybrides [63], aucune entit centrale, de gestion et de coordination du rseau n'existe. Le rseau est cr, ds que les nuds y participant, dcident de se connecter. Ainsi, le rseau change en permanence de topologie, parce que le comportement des nuds altre frquemment les connexions existantes. Ce changement frquent de la topologie est un autre aspect commun des deux rseaux. Dans les MANETs, cela est caus par la mobilit des nuds. Ainsi, les connexions dj tablies avec d'autres nuds se perdent, quand le terminal mobile sort du champ de transmission de ses voisins. Ds lors, les nouveaux liens doivent tre tablis avec de nouveaux voisins pour maintenir la connectivit.
36
Dans les rseaux P2P, la mobilit n'est pas un challenge, mais les frquents des arrivs/dparts des nuds sont problmatiques. La dure moyenne de session est estime aujourdhui 2 heures par jour, en moyenne [64]. De plus, la dynamique de l'affectation des adresses IP par les serveurs et les traducteurs d'adresses causent d'autres problmes, comme l'incapacit de retrouver un nud par une adresse IP stable. Ainsi, il est presque impossible de runir en un court laps de temps toutes les informations sur l'ensemble du rseau, en raison de la dynamique de changements. Une autre question cruciale qui se pose concernant l'auto-organisation, est ce que les inondations sont ncessaires dans tout les niveaux. Comme les deux rseaux sont bass sur une topologie en constante volution, les lments du rseau doivent tre rgulirement sonds, pour vrifier la disponibilit des liens et des nuds. Cela n'est possible que par la diffusion de messages, en labsence dun gestionnaire centralis. Un autre problme qui se produit dans les deux rseaux, est le mcanisme de bootstrap, cest dire la manire dont un nouveau participant peut se connecter aux rseaux P2P ou MANET. Il est ncessaire, que tout nouveau nud trouve des pairs actifs du rseau. En se connectant l'un d'eux, le nouveau nud devient son tour un membre actif. Pour trouver des membres actifs du rseau, une sorte de passerelle est utilise, comme une balise la disposition des nouveaux participants, qui sadressent aussi les membres actifs pour tre trouvs. Ainsi, tout nouveau nud doit connatre, au moins, l'adresse de ce portail, pour tre en mesure de se connecter sur le rseau ad hoc. Dans un rseau P2P, ladresse IP de cette passerelle est prconfigure. Dans MANET, le portail consiste en une bande de frquences, qui constitue le canal de signalisation des nuds ad hoc. C'est sur ce canal que les le nouveau terminal doit annoncer sa prsence, pour devenir un membre actif du rseau. Il n'est pas facile, pour les rseaux MANET et P2P, d'assurer des fonctionnalits de gestion de rseau, comme l'autorisation, l'authentification et la traabilit (AAA), ou mme la qualit de service. En particulier, les deux notions d'autorisation et d'authentification constituent le fondement de la confiance dans un environnement non fiable, surtout quand il n'existe pas d'autorit centrale. Concernant la scurit, aucune approche de scurit, comme par exemple IPSEC [65], ne peut tre utilise telle quelle dans les couches basses. En effet, dans ce type de rseau, les donnes utiles et de signalisation doivent transiter, mme en partie, travers d'autres nuds du rseau. Ainsi, une scurit de bout en bout ne peut tre assure par des tunnels IPSEC, mais seulement par des techniques de cryptage mis en uvre sur les couches suprieures. Comme mentionn prcdemment, la qualit de service est galement une question importante rsoudre dans n'importe quel rseau ad hoc ou p2p. tant donn que les connexions sont inities et gres par des pairs, aucune garantie n'est assure. Ainsi les applications critiques, en termes de latence et de bande passante, comme le streaming vido sur MANET ou P2P, connaissent cette
37
difficult, en plus des contraintes physiques de ces rseaux. Un aperu des similarits est donn dans le tableau 3.
Similitudes Routage de base
Peer-to-Peer Diffusion virtuelle et inondations
MANET Diffusion et inondations physiques Plate et changeant frquemment. Faible Saut par saut via liens radio, limits par leur porte Via portail (Canal broadcast)
Topologie
Plate et changeant frquemment.
Fiabilit des nuds Connexion
Faible Saut par saut via des liaisons filaires, porte illimite
Accs au rseau Passage l'chelle
Via portail (Un nud phare)
Limite par le trafic de contrle Limite par l'overhead caus par le routage
Gestion du rseau
QoS et AAA difficiles car pas d'entit centrale de contrle
QoS et AAA difficiles car pas d'entit centrale de contrle Pas de scurit en couches basses implmente jusqu'alors
Scurit
Pas de scurit (IPSEC) utilisable au niveau rseau
Tableau 3 MANETs vs.P2P:Similitudes
Afin de combiner les forces des deux approches, et pour palier leurs limitations, nous allons voir, dans ce qui suit, comment une synergie entre les deux rseaux peut tre ralise.
2.4.3.
Synergie entre les systmes P2P et MANET
Les caractristiques communes partages par les overlays p2p et MANETs montre aussi que ces deux rseaux sont confronts au mme dfi fondamental, celui de fournir des connexions dans un environnement compltement dcentralis. Ainsi, il existe une synergie entre les deux en termes
38
d'objectifs et de principes conceptuel de leurs protocoles de routage, qui doivent faire face des topologies dynamiques en raison des changements causs par les arrives, les dparts ou de la mobilit des nuds. Par consquent, une direction de recherche prometteuse que nous avons poursuivie, pour les rseaux du futur, est celle de la synergie entre les overlays p2p et les protocoles de routage MANET pour concevoir de nouveaux protocoles plus fiables en intgrant des informations issues des deux niveaux Il existe dans la littrature [66] deux manire des dployer des systmes p2p sur MANET, la premire consiste intgrer les protocoles rseau et applicatif en une seule application; la seconde approche fait communiquer les protocoles de diffrentes couches entre eux. Ces deux approches sont dtailles dans ce qui suit.
2.4.4.
P2P MANETS
La motivation pour proposer des abstractions P2P dans les MANETs, vient du fait que ces deux rseaux partagent de nombreuses caractristiques essentielles, telles que la dcentralisation, qui fait des applications P2P, dveloppes pour Internet, des candidats potentiels au dploiement sur MANET. Par exemple, les applications de partage de fichiers P2P, telles que Gnutella, sont conues avec une philosophie dite serverless (littralement, sans serveur), ce qui les rend potentiellement bien adaptes un environnement sans infrastructure comme les MANETs. Les applications P2P structures, dveloppes pour Internet, ont le rle de fournir un substrat pour la construction d'une varit volutive et robuste de programmes distribus destins Internet. Tels que les systmes de stockage distribu [67][68], de multicast applicatif [69][70][71][72][73] et de recherche textuelle [74]. Une abstraction DHT, implmente par ces overlays structurs, rsout de nombreuses questions difficiles, y compris la tolrance aux pannes, la localisation d'objets, le passage l'chelle, la disponibilit, de l'quilibrage de charge, et le dploiement incrmentale. La motivation de soutenir l'abstraction DHT dans MANETs est semblable son homologue sur Internet. En raison de sa performance en termes de nombreuses proprits communes aux applications distribues, une abstraction DHT, si elle est dploye dans MANETs, pourrait galement lever de nombreux verrous lors de la construction d'applications rparties mobiles. Par exemple, des applications telles que le partage de fichiers et la dcouverte de ressources pourraient bnficier des techniques d'indexation/de recherche fournies par DHT.
39
2.4.5.
Approches de conception du P2P MANET
Les diffrentes approches de conception d'application de peer-to-peer pour MANETs sont classes en fonction de la nature de l'overlay P2P, pouvant tre structure ou non structure. De plus, tant donn que les nuds MANET jouent le rle d'htes et de routeurs en mme temps, ils sont effectivement impliqus dans le soutien des abstractions de la couche P2P. Ces abstractions peuvent tre implmentes, soit sur la couche rseau ou sur la couche application. Si un protocole P2P est ralis sur un protocole de routage MANETs, la conception est dite en couches ou stratifie. Si un protocole P2P est intgr un protocole de routage MANET sur la couche rseau, cette approche est alors dite intgre. Ces deux approches sont dtailles dans les sections suivantes.
2.4.5.1.
Stratifie et non structure.
Cette conception permet de superposer des protocoles P2P non structurs existants ( la Gnutella) au-dessus d'un protocole de routage MANET. Cette conception est similaire l'approche Internet, qui place un protocole P2P au dessus de la couche transport.. Les travaux Oliveira al. [75] tudient l'excution d'une application P2P non structures dans un MANET. Plus prcisment, les auteurs valuent la performance relative des trois protocoles de routage DSR, AODV et DSDV pour le support d'une application P2P non structure. Les rsultats observs montrent que les performances des protocoles sont mauvaises, et que le taux des paquets transfrs est plus faible. Ceci peut tre expliqu par le fait que Gnutella, tournant sur la couche application, va contacter des voisins sur le mme niveau pour rsoudre une requte. Ces voisins vont faire suivre cette demande si le TTL est non nul. Cependant, en raison de la mobilit des nuds, ces voisins ne tenant pas compte de la topologie physique du rseau ad hoc, peuvent avoir besoin de communications multi-sauts pour tre atteindre la destination. En consquence, chaque saut ralis par Gnutella sur la couche application peut entraner une dcouverte de routes par inondations, laquelle est coteuse au niveau du protocole de routage multi-sauts.
2.4.5.2.
Intgre et non structure.
Dans cette approche, l'algorithme d'un protocole P2P non structur est intgr aux fonctions d'un protocole de routage MANET pour des interfaces P2P soutenir non structures. Le travail de Klemm et al. [76] propose, dans ce sens, l'intgration d'une application P2P non structure, la Gnutella, dans la couche rseau. Le systme dvelopp, appel ORION, intgre les processus de requte P2P avec celui effectu par le protocole de routage AODV (voir 2.3.1.2.a).
40
Cette proposition souffre d'un problme de passage l'chelle, car une augmentation de la taille du rseau provoque une grande surcharge de contrle dans le rseau. cause de linondation double effectue sur les deux niveaux du systme.
2.4.5.3.
Stratifie et structure.
Celle-ci consiste en un protocole P2P structur tels que Pastry, CAN, Chord, ou Tapestry fonctionnant comme une application au-dessus d'un protocole de routage MANET. Crossroad [77] est un exemple de cette approche, dans laquelle une DHT consciente de la topologie (topology-aware), base sur Pastry, est superpose sur le protocole de routage AODV, et OLSR avec une altration minime de ces-derniers. Nanmoins nous pouvons constater que ce type de proposition rend difficile l'exploitation de certaines opportunits d'optimisation, en matire d'interaction entre la DHT et les protocoles de routage multi-sauts sous-jacents.
2.4.5.4.
Intgre et structure.
Cette mthode propose d'intgrer un protocole P2P structur avec les mthodes du protocole de routage MANET afin fournir une abstraction de la table de hachage distribue. Dans [78] Das et al. ont propos Ekta, une approche intgrant les fonctions du protocole DHT Pastry, dans le protocole de routage multi-sauts DSR. L'ide cl de cette intgration est de placer une DHT Pastry (oprant sur un espace de noms logique), sur le protocole de routage MANETs (agissant sur un espace de noms physique), par l'intermdiaire d'un mapping entre les identifiants des nuds mobiles et de leurs adresses IP. De cette faon, la structure de routage d'une DHT et celle d'un protocole de routage multi-hop, sont intgrs afin d'exploiter pleinement les interactions entre les deux protocoles de routage et optimiser la performance du systme rsultat.
2.5. Mobile P2P Streaming

Le streaming multimdia doit respecter certaine rgles pour arriver bon port. Le dlai de transmission, la variation de ce dlai et les taux de perte constitue les mtriques majeures surveiller. Dans les rseaux sans fils, WLAN en particulier, la fluctuation du signal radio doit tre prise en considration lors de la conception d'application wireless streaming en gnral et mobiles en particulier. Il est clair qu'il y a un nombre important de verrous lever pour arriver mettre en place un streaming de qualit sur les rseaux sans fils. Que ce soit en infrastructure ou en Ad Hoc il faut tenir compte non seulement des caractristique du flux mettre, mais aussi, certaines conditions de transmission. Notre approche est dite applicative, car nous souhaitons palier ces problmes en proposant des nouveaux mcanismes au niveau applicatif sans toucher la couche rseau.
41
Enfin, nous pensons que le futur des applications multimdia, pour dispositif nomades, les sortira de leur passivit. Les systmes de streaming communiqueront leurs besoins en qualit de service, pour sadapter aux conditions de la transmission. Cette adaptation doit tre dynamique et totalement abstraite lutilisateur. En gnral, la plupart des applications qui impliquent la totalit (ou une grande partie) des nuds dans un MANET, tels que la diffusion, sont susceptibles d'tre plus efficace si elles sont construites directement au-dessus de la couche physique au lieu d'tre places sur un substrat P2P structur. Ceci pour la simple raison que l'efficacit de celui-ci souffre des nombreuses inondations causes par la dcouverte des routes, alors que chacune de ces inondations peut dj atteindre l'ensemble (ou un grand nombre) des nuds dans le MANET.
Chapitre 3. SM Stream: Diffusion multimdia dans les rseaux disruptifs
3.1. Rsum
Dans ce chapitre nous nous sommes intresss au maintien des sessions multimdia dans la mobilit. Parmi les challenges du streaming vido en mobilit sur les rseaux sans fil, nous abordons, dans cette contribution, la problmatique du maintien la QoS des sessions multimdia lors de la mobilit des utilisateurs. Dans des applications de streaming vido, le buffering cot terminal est une technique bien connue pour palier au problme de pnurie du contenu dans le buffer du client. Toutefois, en raison de la mmoire limite du terminal et de l'imperfection du canal sans fil, le contenu multimdia dans le buffer, qui peut subir des fluctuations importantes et ne peut suffire couvrir les priodes de blocage. Pour palier ce problme, nous proposons une nouvelle mthode de buffering contrle par le terminal qui sappuie sur la prdiction du handover afin de supporter un service de streaming de haute qualit et sans coupure transparente aux utilisateurs mobiles. Ces optimisations sont faites au niveau applicatif sans aucune intervention sur l'infrastructure de l'oprateur.
3.2. Introduction
3.2.1. Contexte
Le projet SUMO s'intresse la continuit du service, l'adaptation et la protection du contenu numrique approprie quel que soit le lieu et/ou le fournisseur de service. Le projet tudie galement de nouveaux services de mobilit sur une infrastructure de technologies d'accs sans fil htrognes (multi-technologies) avec mobilit totale entre ces accs, ce qu'on dsigne communment par le modle de communication vertical et transparent. Notre intervention dans ce projet t de fournir un mcanisme de buffering rgi par une prdiction du temps restant avant la dconnexion d'un point d'accs. Cette approche permet d'assurer un service de streaming de qualit des terminaux mobiles se dplaant entre diffrentes cellules sans fil (WiFi).
43
44
Chapitre 3 SM Stream: Diffusion multimdia dans les rseaux disruptifs
3.2.2.
Problmatique
Lorsque un nud mobile se dplace entre les cellules WLAN, la qualit des diffrents signaux, reu des point d'accs avoisinant sa trajectoire, fluctuent. Le niveau signal reu de l'AP (Access Point) actuel auquel le nud est connect commence diminuer et terminal doit essay de trouver un nouveau point d'accs adquat. Cette opration se fait en deux phases: La slection du rseau ou Network Selection qui consiste en le choix du prochain point d'accs (Access point ou AP) auquel ce mme nud va s'associer parmi un certain nombre dAP visibles. Le handover est le temps pendant lequel un terminal mobile sassocie avec lAP slectionn. Connaitre linstant exact du passage dun AP lautre est une information importante Dans ce travail, nous proposons un moyen de prdire ce handover; et ce, en se basant sur la puissance du signal reue (Received Signal Strength RSS) par l'interface sans fil du terminal mobile sur un certain historique, afin de savoir combien de temps reste-t-il avant de quitt cette cellule pour une autre. Tout ce travail est motiv par la volont de maintenir la session multimdia de l'utilisateur durant sa mobilit.
3.3. Introduction la mobilit dans linfrastructure sans fil:

Aujourdhui nous voyons une omniprsence des accs sans fils. Nanmoins, la mobilit lie au nomadisme des terminaux IP, notamment en WiFi pose un problme important pour la garantie de la qualit de service. Les utilisateurs soucieux de la qualit perue et les oprateurs inquiets pour la prennit de leurs services cooprent pour palier aux ventuelles coupures dans un service tel que la voix sur IP ou le streaming vido. Lobjectif de cette contribution, est faire de la diffusion sans coupure de flux vido vers un appareil mobile entre diffrents accs sans fils, connu plutt sous le nom handover. Un vnement pendant lequel les dispositifs nomades change de point de connexion. Ils sont alors obligs de puiser dans leurs ressources locales pour viter la coupure du flux vido. En effet, lorsque un nud se dplace, il est amen changer plusieurs cellules sans fils (i.e , WiMax, UMTS), cest ce qui est communment appel handover. Lors de cet vnement, il arrive que le nud mobile perde compltement la connexion avec le fournisseur du service. En pratique, cette perte de connexion dans le cas de cellules qui se chevauchent ne dure en moyenne que quelque seconde (de 2 6 secondes pour le WiFi). C'est--dire, le temps pour le terminal de se rassocier au nouveau point daccs et remette en place les diffrents niveaux de connexion Les applications streaming vido sappuient gnralement sur le buffer cot client, qui permet de stocker temporairement une partie du flux. Ce buffer est gnralement cr dans la
45
Random Access Memory (RAM) plutt que dans le disque dur ( cause de la lenteur d'accs et de recherche de donne [80][81]). Dans ce qui suit, le terme "mmoire" sera dnomm RAM. La bonne qualit de service homogne cot terminal exige le maintien d'une bonne taille de buffer avec le contenu des mdias pour assurer la continuit du playout en amortissant la gigue et les dlais de transmission. Sans ce buffer, l'utilisateur subirait de nombreux arrts dans la visualisation. Afin de faciliter la lecture en streaming, certains suggrent une configuration d'une taille maximale pour le buffer. Le problme, est que plus le buffer est grand, moins de mmoire vive est disponible pour d'autres tches. Par consquent, lutilisation efficace de cette RAM devrait tre soigneusement prise en compte, dans la gestion du buffer de l'application streaming. Lors des premires implmentations des buffers, la taille de celui-ci affectait le dlai de dmarrage du streaming (typiquement de l'ordre 5 secondes). Plusieurs amliorations ont t propos depuis, telles que advanced fast start, qui vise rduire ce dlai [82]. L'ide principale tant d'afficher le peu de contenu dj reu, et en mme temps, les donnes sont tlcharges avec un rythme acclr, allant plus vite que la vitesse d'encodage de la vido, jusqu' ce que le tampon soit rempli. La rduction du temps de buffering agit d'une manire bnfique sur la qualit de l'exprience perue par l'utilisateur. Un autre problme bien connu dans le streaming vido dans l'infrastructure sans fil, est la fluctuation des ressources rseau qui induit pertes de paquets, retards, et blocage du service. Outre les variations de la qualit du canal sans fil, l'interruption au cours du processus du handover est galement l'une des sources importantes de la discontinuit lors de la mobilit. Cette dernire problmatique reste ouverte aujourdhui et sa rsolution constitue le principal objectif de ce chapitre. Par la suite, nous allons prsenter un mcanisme de buffering bas sur la prdiction du temps avant handover, pour l'ajustement de la mise en cache de la vido. L'ide principale est de recevoir les donnes avec un dbit acclr lorsque cela est possible, pour remplir le buffer. Puis, utiliser ce buffer lors des priodes de mauvaise rception durant le handover. Nanmoins, pour ne pas utiliser dune manire permanente un buffer de taille importante, lobjectif est de tenter de remplir compltement le buffer, uniquement le cas dun handover imminent.
3.4. Travaux relatifs

Dans un environnement compatible avec Mobile IP (MIP), plusieurs amliorations ont t proposes, ayant pour objectif de rduire la dure du handover ainsi que le taux de perte de paquets que gnre le handover MIP tel que fast MIP [83], hierarchical MIP [84] ou le smooth handover scheme [85].
46
En effet, cette perte de paquets est due au passage du terminal par des zones de chevauchement de petites cellules sans fil; ou encore, la latence du handover qui peut durer jusqu' quelques secondes. Des techniques de pr-buffering ont dj t employes pour surmonter la pnurie possible des buffers du terminal. Cependant, un choix imprcis ou conservateur des paramtres du buffer peuvent engendrer soit une perte de paquet durant le handover, ou bien un gaspillage de la mmoire du terminal. Une prdiction prcise de linstant du handover peut permettre la dtermination de la quantit ncessaire de donnes pr-bufferiser ainsi que l'instant appropri de dclenchement de ce dernier. En d'autres termes, un mcanisme de prdiction du handover peut ainsi, permettre un buffering adaptatif et un streaming sans couture (seamless). L'estimation de la bande passante disponible est un domaine de recherche actif. Gnralement, cette estimation est base sur l'utilisation des techniques de sondage, c'est--dire, en observant le comportement d'un paquet chang entre le serveur et le client. Le dbit de bout en bout disponible correspond celui de la liaison radio, car cette liaison agit en gnral comme un goulot d'tranglement pour la transmission de donnes. Si le serveur est coopratif dans l'estimation la bande passante disponible, les techniques telles que Pathload [86] ou Pathchirp [87] peuvent tre utilises. En fait, Pathload et Pathchirp utilisent le temps de dispersion chez le client recevant les paquets de sonde via le goulot d'tranglement de la liaison radio pour dduire la bande passante disponible. Dans le cas ou le serveur n'est pas coopratif, la technique Spruce [89], qui consiste forcer le serveur envoyer les paquets de sonde au client peut tre envisage. Ces techniques donnent des rsultats satisfaisants. Nous supposons donc que cette information est disponible via une de ces mthodes et nous concentrons notre attention sur l'aspect prdiction de linstant de handover. Dans [90][91], des modles Gauss-Markov ou Markov cachs ont t appliqus des donnes historiques et rcentes afin de prdire la localisation et la vitesse d'un nud mobile. Ces informations sont alors combines la connaissance des cartes de dploiement du rseau d'accs pour dduire l'imminence des handovers. En outre, la prdiction de handover base sur le chemin a fait l'objet d'un draft et les habitudes de mouvement des utilisateurs ont t prsentes dans [92]. Cependant, ces solutions ne sont pas ralistes, du fait que les comportements d'utilisateurs mobiles aussi bien que les topologies des rseaux sans fils changent de faon irrgulire. Elles ne devraient pas tre employes pour la prdiction de handover. Une autre solution plus pragmatique de prdiction du handover, se base sur le Received Signal Strength (RSS). La quantit de temps avant la perte de connexion se calcule en utilisant une prdiction linaire partir de deux valeurs moyennes conscutives du RSS [93] cette prdiction s'est avre imprcise car les valeurs en question fluctuent cause des effets du fast fading et des zones d'ombre en log normal. Une approche alternative consiste appliquer le modle Grey de
47
premier ordre (The first-order Grey Model (GM)), pour mitiger le bruit dans les valeurs du RSS et prdire ainsi, les valeurs futures du RSS, ce qui facilite la prdiction du handover [94][95]. Rcemment, le GM permis de calculer les rgions de probabilits (faible, moyenne et forte) pour un buffering adaptatif, afin d'viter la coupure du streaming pendant le handover dans les rseaux WLAN [96]. Toutefois, ce systme de buffering ne tient pas en compte ni du dbit courant du flux vido, ni de la disponibilit du rseau; et encore moins de la latence du handover. Cette solution ne montre pas comment le terminal peut accomplir un buffering lui permettant surmonter les interruptions pendant les handovers. Certes, elle nous informe de la ncessit d'avoir un buffer, mais ne nous dit pas quelle quantit de donnes doit tre mise en cache en avance. En ralit, dans cette proposition, la gestion du buffer n'est pas vraiment adaptative car elle propose seulement trois tailles pour trois niveaux de probabilit de handover. Par ailleurs, l'estimation de la latence et les pertes de paquets a galement t exploite pour calculer la taille de buffer ncessaire dans les tudes prsentes dans [97][98]. Toutefois, ces solutions ne permettent pas didentifier l'instant o le buffering devrait tre dclench et exigent une coopration entre le client et le serveur de streaming. Contrairement aux solutions existantes, notre objectif est de dterminer non seulement linstant o le buffering doit dmarrer mais galement le nombre de connexions ouvrir pour remplir le buffer compltement avant la dconnexion due au handover. Le buffer plein permettra de fournir les donnes ncessaires au maintien de la session. Nous supposons que (i) le serveur est capable de supporter des connexions simultanes (ii) le client est capable de dire quelles parties du flux il souhaite tlcharger.
3.5. La mise en cache (buffering)

La solution que nous proposons ambitionne de ne raliser aucune modification l'infrastructure rseau ou la procdure de handover. Nous supposons que le buffer du terminal est dj calibr, une taille approprie, qui permet d'viter les fluctuations du rseau et de bien apprhender les handovers. Cette taille peut tre fixe, mais le contenu lui est variable. Pour permettre une alimentation continue du lecteur multimdia cot client, nous mettons en place un mcanisme qui adapte la quantit du contenu dans le buffer en fonction de la situation du terminal. La gestion du buffer est ralise par le terminal mobile, indpendamment du le serveur de streaming. Aucune modification n'est requise sur le serveur, ce qui rend notre approche intressante. Lorsque le protocole UDP est utilis pour transporter les flux multimdia, le dbit moyen de tlchargement Rmax doit tre, au moins, gale au dbit de lecture Rr (c'est--dire, la vitesse d'encodage du flux) dans les conditions normales du rseau. Pour que le buffer puisse se remplir un rythme acclr, le client peut alors rgler sa vitesse de connexion si le serveur supporte la
48
Chapitre 3 SM Stream: Diffusion multimdia dans les rseaux disruptifs /
ngociation des dbits. Sinon, le client ouvre n= passante disponible).
connexions supplmentaire de dbit Rr
pour remplir le buffer dans les temps (R tant l'augmentation du dbit limite par la bande
Par la suite, nous supposons que le serveur communique avec le client un dbit Rr stable pour chaque connexion UDP. Ceci pourrait gnrer sur la laccs wifi une charge supplmentaire qui pourrait dtriorer le dbit global. Rgle 1: Si la vido dans le buffer est infrieure un certain seuil b[t]bmin, ouvrir une , o bmax est la taille maximale du buffer, est la vitesse du flux de la
connexion UDP pour remplir le buffer pendant
b[t] est la quantit de vido dans le buffer l'instant t et R
connexion supplmentaires. Gnralement, il est gal la vitesse de codage, c'est--dire, R = Rr. En fait, ce dbit de la connexion supplmentaire est limit par le maximum de la bande passante disponible sur le lien radio Rmax, qui est (Rr+RRmax). Le seuil bmin peut tre dfini comme la quantit minimum de vido ncessaire laffichage de la vido. Cette valeur peut tre fixe 2 - 3 secondes de lecture vido. Cette condition peut se raliser lors d'une excution du handover ou une fluctuation des paramtres du rseau sans fil. Rgle 2: Si la bande passante disponible est leve (par exemple Rmax> 2Rr) et le buffer n'est pas plein, ouvrir une connexion UDP supplmentaire pour remplir le buffer. Rgle 3: Si le handover prvu est imminent et le buffer n'est pas plein, dclencher le buffering. C'est le but principal de ce travail pour viter une interruption du streaming lors du handover. Les dtails relatifs aux diffrents scnarios de handover sont prsents plus loin. Pour grer efficacement le buffering avant le handover, le terminal mobile devrait prdire les paramtres tels que le temps restant avant le handover et le temps restant avant de quitter la cellule actuelle. Ensuite, cette information sera couple avec les valeurs de la dure du handover et de la bande passante disponible sur le lien radio afin de prendre la dcision sur le buffering. La dure du handover est dfinie par la latence dans le cas d'un handover horizontal, en utilisant la mme interface radio. Elle dpend aussi de la technologie d'accs (WLAN). Elle correspond au dlai pour l'tablissement de la connexion vers un nouveau point d'accs et la mise jour de ladresse IP avec MIP. L'estimation de la dure a t tudie dans [99]. Par souci de simplicit, une valeur prdfinie de cette dure par technologie d'accs est utilise. Pour le rseau WLAN, elle t fixe 5 secondes.
3.6. La prdiction du handover

La dtection du handover joue un rle primordial dans le mcanisme de buffering que nous avons propos prcdemment. Celle-ci consiste en la prdiction de deux mtriques : le temps restant
49
avant que ce handover se produise et le temps restant avant que le terminal ne quitte la cellule la quelle il est actuellement attach. Pour cela, nous utilisons le modle de Grey du premier ordre GM(1,1). En effet, la prdiction avec ce filtre tablit un modle passant des valeurs historiques et prsentes (rsultant des mesures du RSS) vers les futures. Nous avons choisi un tel filtre parce qu'il est efficace et nest pas gourmand en calcul (donc facilement implmentable sur des quipements mobiles).
3.6.1.
Handover horizontal dans WLAN
Le handover horizontal entre deux points d'accs WLAN en utilisant une seule interface radio est difficile raliser de faon transparente. Rappelons que la priode de dconnexion dans ce cas correspond la latence du handover, Tbo = Tbho. Pour raliser un streaming sans coupure dans un tel contexte, nous proposons le systme de buffering suivant: Etape 1. Calcul du temps avant le handover: Lorsque le terminal reoit un bon RSS d'un AP avoisinant, le temps restant avant handover Tbho est prvue pour chaque nouvelle paire de APs compose de l'AP auquel le nud mobile est actuellement attach et l'AP avoisinant. Les dtails relatifs la prdiction sont prsents dans la section suivante. Etape 2. Calcul du temps d'avance ncessaire: Tad est le temps d'avance ncessaire pour remplir le buffer si le nud mobile ouvre une connexion supplmentaire, linstant , avec un dbit R calcul comme suit: Tad [] = Tcon + min(bmax,Rr/Tbo)-b[])/R (3.1)
Tcon est le temps ncessaire pour tablir une connexion UDP supplmentaires et b[] est la quantit de donnes dj prsente dans le buffer l'instant . L'augmentation du dbit dpend fortement de la bande passante disponible, c'est--dire, R = min (Rmax[] - Rr, Rr) o Rmax[] est le dbit maximum disponible l'instant . Il convient de noter que le temps d'avance Tad ne changera pas chaque chantillon de mesure en raison de la fluctuation de la bande passante disponible sur une grande chelle de temps. Aussi, si bmax<Rr.Tbo, le terminal peut allouer plus de mmoire pour le buffer multimdia (posons bmax=Rr.Tbo). Cela permet d'viter les pauses dans la lecture pendant le handover. Etape 3. Condition de dclenchement buffering: Le temps d'avance Tad est une contrainte dans la dcision de buffering. D'une part, pour mener bien le buffering de la quantit de vido requise, cette opration doit tre dclenche sous la condition suivante Tbho[m]>=Tad[m]. D'autre part, le buffering ne doit pas tre dclench trop tt, car l'utilisateur peut changer de direction et le handover pourrait ne pas se produire. Si le
50
terminal maintient son cap (c'est--dire, sa direction et sa vitesse), Tbho [m] tombe en dessous Tad+T (o T est la priode de mesure), et la prochaine valeur Tbho[m+1] est, sans doute, infrieure ou gale Tad. priori, la condition de dclenchement satisfait l'quation Tbho[m]Tad+T. Pour viter une surestimation de la prdiction du handover, nous suggrons d'ajouter une marge d'hystrsis la limite suprieure de sa condition de dclenchement. Le choix de est bas sur l'intervalle de confiance sur la fiabilit de la prdiction de l'instant du handover (c'est--dire, celles prdites lorsque le terminal se rapproche du linstant du handover). Le buffering est alors dclench l'instant m si: Tbho[m]Tad[m]+T+ (3.2)
La connexion supplmentaire perdurera jusqu' ce que le buffer soit rempli ou jusqu' ce que le handover se produise. On notera que, si Tbho[m]<Tad[m], une ouverture de connexion supplmentaire ne suffira pas pour remplir le buffer temps. Dans ce cas, nous aurons besoin du mcanisme de recouvrement dcrit ci-aprs. Etape 4. Buffering de recouvrement: Durant le buffering, le terminal peut connatre une forte baisse de l'estimation des valeurs du temps avant le handover (correspondant aux instants j > m). Ceci peut tre d un changement brutal de la vitesse de l'utilisateur mobile. Par consquent, lors du buffering, nous veillons ce que la condition suivante soit vrifie: min{bmax,Rr.Tbo}b[j]>R.Tbho[j] (3.3)
Si (3.3) es vraie, cela signifie que la dure du buffer est suprieure Tbho. Si Tbho[j]> Tcon (c'est--dire, le temps restant avant le handover est assez grand pour ouvrir une nouvelle connexion), initier des connexions UDP supplmentaires une vitesse R'. La valeur de R' est calcule comme suit: , (3.4)
En d'autres termes, le nombre de nouvelles connexions UDP supplmentaires (n' = |R'/Rr| pour compenser un changement brusque de la valeur Tbho lors du buffering. Donc, le nombre total de connexions supplmentaires devient (1+n').
3.6.2.
Prsentation du filtre grey GM(1,1)
La spcificit du filtre Grey c'est qu'il construit une quation diffrentielle ordinaire du premier ordre partir d'une squence de valeur de RSS mesures. Etant donn un ensemble de valeurs de RSS d'un AP avoisinant le terminal X(0)={X(0)[1];X(0)[2];;X(0)[n]} o X(0)[i] est la valeur discrte du
51
RSS un temps i , la squence gnratrice accumule X(1) = {X(1)[1];X(1)[2];;X(1)[n]} est donne par X(1)[k] = comme [100]: (dX(1)[k]/dk)+aX(1)[k] = b (3.5)
ki=1
X(0)[i]. Le modle Grey diffrentiel ordinaire du premier ordre est formul
o [a, b] sont les paramtres dterminer. En utilisant la mthode des moindres carrs des erreurs, [a b]T = (BTB)-1 BTYn o 0.5 X 0.5 X 0.5 X 0 1 2 X X X 1 2 3 1 1 1
0.5 X
n
T
et Yn = [X(0)[2], X(0)[3];;X(0)[n]] Ensuite, les valeurs filtres et prdites du RSS 1 1 1

(0)
[k] sont donnes par: 1 (3.6)
3.6.3.
Prdiction du temps avant handover
Le temps avant handover est un indicateur cl pour le buffering adaptatif afin dviter les coupures du au handover horizontal. La dcision du handover horizontal entre deux AP WLAN est prise sur la base des valeurs RSS. Pendent la communication avec la cellule initiale, le terminal mesure la fois le RSS et le potentiel offert par celle-ci et les cellules voisines. Le handover sera donc dclench si .
et
tant
les RSS filtrs des cellules
actuelles et voisines respectivement. h est une marge d'hystrsis permettant d'viter un effet ping-pong du handover. Aprs le dclenchement du handover, la communication peut tre interrompue. Si l'instant du handover (ou le temps restant avant celui-ci) peut tre prdit, le mcanisme de buffering peut tre maintenu efficacement pour assurer un streaming sans coupure. Lorsque le terminal mobile reoit le bon signal partir d'un nud d'accs voisins, il emploie le filtre GM(1,1) afin de prdire les futures RSS des points d'accs actuels et voisins. Notons par Ps[i] et Pn[i], les RSS provenant des points d'accs actuel et voisins (i<m ou m est l'indice de la dernire mesure du RSS). Tant que le handover ne se produit pas, calculer et , les valeurs RSS prdites de Ps et Pn. Pour prdire le future instant de handover k > m tel que
. Par consquent, l'instant de dclenchement du handover est donn par:
52
Tbho = (k m)Tmeas
(3.7)
Tel que Tmeas est la priode de la mesure du RSS. Dans le cas des rseaux WLAN, par exemple, Tmeas est gale la valeur de la priode l'mission millisecondes. La prcision de la prdiction du handover dpend du nombre d'chantillons de RSS (P[m - N], P[m - N + 1], . . ., P[m]) correspondant aux entres du filtre GM (1,1). Gnralement, la squence de valeur de taille N est assez petite, car seulement deux paramtres doivent tre identifis dans (3.5). Toutefois, en raison de la fluctuation du RSS plus cette squence est grande, plus les valeurs RSS prdites Comme les valeurs prdites l'instant m, la prcision de sont rgulires. [k] (k> m) sont calcules partir de valeurs mesures jusqu' [k], d'o la prcision du Tbho, est une fonction dcroissante de (k - m). du beacon qui est, par dfaut, de 100
Les valeurs prdites Tbho sont obtenus avec l'hypothse que les futurs RSS suivent l'volution de l'ajustement de courbe (3.7). En d'autres termes, la direction et de la vitesse du nud mobile, sont supposes tre inchanges entre l'instant (m - N) et l'instant k. Par consquent, nous ne pouvons pas prdire le temps avant handover trop en avance.
Figure 9:Algorithme de prdiction du Tbho
Il serait intressant d'avoir une ide approximative de l'ordre de grandeur du temps
avant
handover. Selon (3.2), le handover doit tre prdit au moins avec Tad secondes d'avance. Si lon remplace l'augmentation du dbit par R= Rr dans (3.1), nous obtenons Tad = Tcon + Tbho. Le temps d'tablissement de la connexion Tcon est donc gal plusieurs Round-Trip Time (RTT) pour l'change de messages de contrle entre le client et le serveur. Ainsi, l'ordre de grandeur de Tcon est de l'ordre de plusieurs centaines de millisecondes. La dure du handover Tbo entre deux points d'accs WLAN peut atteindre quelques secondes. Par consquent, dans notre systme de prdiction, il est ncessaire de prvoir l'instant du handover de quelques secondes en avance pour tre en mesure d'excuter le mcanisme de buffering. Comme voqu prcdemment, la prcision de la prdiction du handover dpend de la rgularit des RSS mesurs. Un changement brutal de trajectoire ou de vitesse de l'utilisateur peut provoquer des erreurs de prdiction du RSS. Normalement, l'effet d'une erreur de prdiction en raison d'un changement de mouvement s'estompe compltement au bout de N mesures. Nanmoins, il serait intressant pour nous d'attnuer cette erreur plus rapidement. Pour cela, nous
53
suggrons d'utiliser un mcanisme de dtection des changements de direction/vitesse l'intrieur du systme de prdiction du handover. Cette mthode est illustre dans la figure. Le principe de base de ce mcanisme est de dtecter le plus tt possible un changement de mouvement (direction et / de vitesse) afin d'ajuster les entres du filtre GM (1,1). Par la suite, nous montrons qu'un changement mineur de vitesse n'a pas beaucoup d'incidence sur les rsultats de la prdiction. Un changement de direction et/ou de la vitesse n'implique pas une altration brutale dans l'volution du RSS. En effet, cette dernire est fonction de la distance entre l'utilisateur mobile et la station de base qui ne peut pas changer brusquement. Par consquent, nous ne pouvons pas dtecter immdiatement un tel changement. Il est galement difficile d'utiliser les RSS afin de dtecter un tel changement parce que la squence de RSS ne contient pas de composante dterministe explicite. Cela explique pourquoi nous utilisons la dtection de changement aprs l'application du filtre GM (1,1) plutt que juste aprs la mesure des RSS. Le mcanisme de dtection de changement observe le comportement de l'instant du handover prdit yt = k. Une brusque variation de yt implique un changement dans le rythme du mouvement de l'utilisateur. L'algorithme de dtection des changements squentiels est celui de la somme cumule (CUSUM) propos par Page dans [107]. Nous utilisons le filtre CUSUM Recursive Least Square (RLS), qui combine des filtres adaptatifs avec le test CUSUM comme dtecteur de changement, pour prvenir les changements dans la squence d'yt. L'algorithme CUSUM RLS est dcrit comme suit: g1t = max(g1t-1 + - ,0) g2t = max(g2t-1 - - ,0) y 1 y (3.8) (3.9) (3.10) (3.11)
Par la formule (3.8), on obtient l'estimation RLS o est considr comme un facteur d'oubli. Une grande valeur de ce facteur d'oubli ( = 0,9) est choisie de manire volontaire pour donner plus de poids pour la dernire valeur calcule. Dans (3.10), t est l'erreur de prdiction utilise comme distance pour dtecter un changement. Le test statistique g1t (resp. g2t), par addition d'entres t, avec l'ide de dclencher une sorte d'alarme lorsque la somme dpasse un certain seuil h. Si est une squence de bruit blanc (pas de changement), le test statistique s'loigne et se comporte telle une marche alatoire. La soustraction d'une petite dviation et une remise zro (une fois gt devient ngatif) sont utiliss pour prvenir des fausses alarmes et viter une longue attente, aprs la dtection d'un changement. Sachant qu'un changement peut entraner une augmentation ou une diminution de l'instant du handover yt, nous utilisons deux tests parallles g1t et g2t pour dtecter l'augmentation ou la diminution de la valeur moyenne. Quand un
54
changement est dtect l'instant ka = t (c'est--dire, g1t>h ou g2t>h), il faut rinitialiser g1t = 0, g2t = 0 et = yt.
Les deux paramtres conceptuels du test CUSUM sont la dviation et le seuil h. Selon [138], la dviation est gnralement fixe la moiti du changement attendu =0.5|Ka-Ka-1| quant au seuil h, il dpend des caractristiques de la squence du signal et est souvent dtermin par apprentissage l'aide d'un ensemble de donnes [139]. Dans la littrature, diffrentes mthodes pour le choix de h bases sur la probabilit de fausses alertes et le dlai appropri pour la dtection d'un changement (le dlai de dtection des changements) ont t proposes dans [101][102]. Cependant, la formulation est asymptotique et pratique. Les rsultats de l'algorithme de dtection de changement sont l'instant du handover ([x] reste difficile appliquer dans la
dsigne le plus proche entier de x) et l'instant de changement ka. Par consquent, nous obtenons Tbho = (k-m)T. Au dbut de la prdiction, ka est mis 0. Une fois qu'un changement est dtect, une nouvelle valeur est mise jour et report dans la squence d'entres RSS. Si aucun changement n'est dtect, le filtre GM (1,1) utilise les N derniers RSS en entre. Sinon, seules les dernires valeurs RSS associes un nouveau mouvement seront utilises plutt que toutes les N dernires valeurs RSS. Une fois le changement dtect l'instant ka, celui-ci s'est probablement produit l'instant (ka-M) o M est le dlai de dtection de changement. En gnral, M est infrieur la moiti de la taille de la squence de donnes d'entre (M <= N / 2). Le choix de la taille d'entre N est un compromis faire entre la rgularit de la prdiction et le dlai dans la dtection de changements. Si N est grand, la dtection du changement est trop lente mais un systme stable. Mais si on choisi, une petite valeur de N alors les fluctuations du Tbho peuvent tre importantes. Comme la force du signal radio est spatialement corrle [103], il est prfrable d'utiliser une squence de RSS mesur au sein d'une corrlation de la distance. En milieu urbain, une corrlation de distance de 20m est largement adopte [104]. Par consquent, les valeurs de M et N sont dtermines partir de l'intervalle de mesure ainsi que la vitesse du terminal.
3.6.4.
Prdiction du temps avant l'abandon de la cellule
Contrairement la prdiction de la Tbho, la prdiction de Tbmo est uniquement base sur le RSS du point d'accs actuel Ps [i]. L'ide principale est de prvoir l'instant o l'utilisateur quitte la limite (c'est--dire, Ps [l] < limite). C'est le seuil de la force du signal au-dessous duquel communication ne peut plus tre maintenue. cellule actuelle (ci-aprs le l'instant d'abandon de la cellule). cet instant, [l] est infrieur la
55
Le schma de prdiction du Tbmo est illustr dans la figure 24. Le systme de prvision utilise les squences de donnes disponibles Ps ([m-N], P [m-N +1],. . . , P [m]). De mme que pour la prdiction du Tbho dcrite ci-dessus, afin d'attnuer les effets dus aux changements de mouvement, nous utilisons un filtre CUSUM RLS pour dtecter le changement de mouvement et lisser la valeur du temps avant l'abandon de la cellule. Le mcanisme de dtection de changement contrle en permanence l'volution de l'instant prdit yt = l. Si un changement est dtect l'instant ka, l'entre du filtre GM(1,1) sera mise jour en consquence. Les choix de la taille de la squence de donnes N ainsi que les paramtres conceptuels du CUSUM (h,) sont identiques ceux utiliss dans la prdiction du Tbho. L'instant d'abandon de cellule prdit = [ ] ( de l'instant d'abandon de cellule prdit yt) est utilis pour calculer Tbmo: (3.12) o m est l'instant de la dernire mesure et Tmeas est la dure entre deux chantillons conscutifs RSS dans le systme de prdiction. tant la valeur filtre
3.7. Evaluations
3.7.1. Simulations
L'objectif de ce paragraphe est de valider l'efficacit du systme de prdiction du handover propos, selon diffrents scnarios de mouvement de l'utilisateur. Nous avons simul le mouvement d'un utilisateur entre deux WLAN AP avoisinant sa trajectoire. Dans les simulations, les valeurs du RSS une distance d de l'AP sont obtenues en utilisant le modle COST-231 [105] : Pr[dB] = K1-K2.log(d)+X (3.13)
o K1 dpend de la transmission et la rception des gains d'antenne, la hauteur de l'antenne, la frquence centrale et de la longueur d'onde du signal, et K2 reprsente le facteur de l'affaiblissement de propagation. X tant la moyenne indpendante et identiquement distribue du processus alatoire Gaussien modlisant l'vanouissement d'une zone d'ombre (shadow fading). Dans le cas du handover sur WLAN, des utilisateurs mobiles pitons ont une vitesse maximale de 2 m/s, dans un intervalle de mesure de 100 ms, nous posons N=100 (c'est--dire, les valeurs du RSS mesures sur une distance de corrlation de 20m). Aprs avoir examin les diffrents scnarios de changements de directions, nous choisissons = 15 et h = 2000 comme paramtres pour la dtection des changements. Pour se faire, un changement interviendrait toujours aprs un dlai maximum de 40 chantillons. Comme rsultats, nous avons mis M = 40 pour l'ensemble des simulations.
56
Dans la premire simulation, l'utilisateur se dplace de l'AP1 vers l'AP2 sans changement de direction et de vitesse. L'volution du RSS depuis les deux APs et le Tbho prdit selon Ah = 0, sont reprsents dans la Figure 10. Nous pouvons constater que la prdiction de rsultat est plus fluctuante lorsque l'utilisateur est loin de la zone de handover et concide avec des valeurs relles lorsque celui-ci s'y rapproche. Le rsultat montre que la mthode propose, peut prdire l'instant du handover plus de 10s d'avance. Nous ritrons cette simulation de nombreuses fois et observons les fluctuations de Tbho 10 et 5 secondes avant le handover. L'intervalle de confiance [106] de Tbho est calcul comme suit: P(|Tbho - Tbho|<= tn;/2.m/S = 1 - tel que n = S1 (3.14)
(3.14) o S est le nombre de simulations, Tbho est la moyenne Tbho sur S simulations et m est son cart-type. Dans l'quation ci-dessus, (1 - ) est l'intervalle de confiance et tn;
/2.
; est le
pourcentage de distribution de Student tels que P (|tn| tn;/2.) = . Cela signifie que nous sommes sr (1-) 100% que les prdictions de temps avant handover varie entre Tlower = (Tbho tn,/2.m/S) et Tupper = (Tbho+tn;/2.m/S)). Selon nos rsultats de simulations, avec le niveau de confiance de 90%, l'intervalle de confiance de Tbho 10s et 5s avant le handover, sur 100 simulations est de (10,570,33)s et (5,240,19)s respectivement. Les rsultats confirment la fiabilit de nos Tbho prdit et la surestimation de la tendance des valeurs prdites par rapport aux valeurs relles. Ce dernier est d la nature du filtre GM(1,1) a t bien connu dans la littrature. Nanmoins, ces rsultats montrent la ncessit d'ajouter un hystrsis, la condition du dclenchement du buffering (3.2), pour viter les fluctuations imprvues et la surestimation. Dans ce cas, un autour de 0.4 s devrait tre adquat. En supposant que Tbho = 2s, Rr = 500Ko/s, Tcon = 0.1 s et = 0:4 s et la taille du buffer du terminal dans des conditions normales du rseau est maintenu autour de 600ko, en appliquant le schma de buffering propos, l'volution du buffer est illustre dans le bas de la Figure 10. Nous pouvons voir clairement que le handover s'est ralis d'une manire transparente pour lapplication (sans coupure dans le playout) en amliorant, ainsi, la qualit d'exprience peru par l'utilisateur finale.
3.7.2.
Rsultats et Discussions
Nous comparons notre approche deux autres: une sans mcanisme de dtection de changement dans le mouvement et un autre qui suppose que la dtection d'un changement est immdiate. Cependant, nous noterons que dans la ralit une dtection immdiate est impossible. Les rsultats de prdiction du temps avant handover utilisant les trois programmes le montrent bien dans la Figure 10. Nous pouvons observer que le schma de prdiction que nous proposons donne un meilleur rsultat par rapport ceux obtenus par les deux autres. D'une part, si la dtection du changement n'est pas utilise, l'erreur du Tbho prdit est importante et ne peut tre rduite
57
qu'aprs N tapes. D'autre part, si un changement est dtect immdiatement, les valeurs Tbho prdites immdiatement aprs le changement est fluctuent beaucoup en raison de la petite taille des entres RSS utilises dans le filtre GM (1,1). Les rsultats dmontrent la rationalit et l'efficacit de notre systme de prdiction du handover. L aussi, on peut constater partir de la Figure 10 (bas) que la taille du buffer ne fait qu'augmenter en prvision d'un handover intempestif, et n'atteint jamais une valeur nulle.
(a) sans dtection du changement
(b) avec dtection du changement
Figure 10: Prdiction du Tbho et volution du buffer
3.7.3.
Exprimentation
Dans cette phase, nous nous sommes intresss la mthode exprimentale afin de valider les rsultats analytiques et simuls.
3.7.3.1.
Description du banc dessai
Notre banc dessai est compos de trois points d'accs WLAN AP1, AP2 et AP3 dans une zone plate sans obstacles comme illustre dans la Figure 11, La distance entre lAP1 et AP2 est d'environ 50 mtres. Un MN (laptop) et dplac entre AP1 et AP2 avec une vitesse d'environ 1,5 m/s (piton). Une session de streaming multimdia partir d'un serveur directement reli ces APs via un rseau filaire. Les signaux de toutes les APs sont mesurs toutes les 100 millisecondes. Nous avons intgr l'algorithme de prdiction bas sur le filtre GM(1,1) dans un logiciel utilitaire de collecte d'information sans fil afin de prdire le temps restant avant le handover Tbho.
58
Figure 11: Schma du banc dessai
Le client et le serveur utilisent le logiciel VideoLAN13 pour le streaming sur UDP. Le mcanisme de buffering a t intgr directement dans VLC. Le code a t modifi pour ouvrir automatiquement des sessions parallles avec le serveur pour acclrer le remplissage des buffers lorsque ncessaire. Les dtails des algorithmes se trouvent dans le paragraphe suivant. Le serveur reste inchang. Par ailleurs, et afin de surveiller la bande passante disponible de bout en bout entre le client le serveur de streaming, nous utilisons loutil Stab qui est un utilitaire de mesure bas sur la technique Pathchirp.
3.7.3.2.
Algorithmes raliss dans VLC
Le remplissage se fait grce la cration de plusieurs buffers associs chacun un connexion. Plusieurs connexions en parallles peuvent tre dclenches pour la lecture du flux en cours. Comme expliqu ci-dessus, chaque buffer peut stocker une squence future du flux multimdia (Figure 12). Mis bout bout ces buffers vont contenir la totalit de la squence ncessaire en local pour un playout durant la dconnexion du handover. Le nombre de buffers ainsi que leurs tailles seront fixs en fonction du bit rate de la vido, la taille de la vido restante, le temps devanant le handover ainsi que sa dure.
13
The VideLan Client http://www.vidolan.org
59
Figure 12:Schma du buffering
Aprs avoir tudi de prs larchitecture logicielle de lapplication VLC, nous avons effectu les changements ncessaires pour mettre en place ces mcanismes et assurer une lecture sans coupure de la vido mme lorsque la connexion physique est coupe. Les points qui suivent dtaillent les algorithmes utiliss dans le but de la ralisation de notre exprimentation. Etape 1. Estimation du Tbho: Lalgorithme 1, mesure chaque 100 ms les RSSs reu des APs qui se trouvent proximit. En effet, nous avons adapt la mthode de recensement des rseaux IWLIST faisant partie des outils linux Wireless Tools. Que nous avons intgr notre client de prdiction et dexcution du handover.
Algorithme 1: Collecte dinformation sur les rseaux avoisinants
for each beacon_period do for each APi do

APij=1..20 = Get_RSSvalue(APi) if APi==Max(BestAPi,APi)and(ActualAPAP) then BestAP=APi
end for end for if (ActualAPj=1..20 Threshold) then predict_Tbho(ActualAP,BestAp) else trigger_handover(BestAP, Tbho,Tbmo)
Etape 2. Les valeurs mesures sont ensuite enregistres sur un historique de 2 secondes (quivalent 20 valeurs). Chaque seconde, lalgorithme 2 prdit les valeurs des temps avant handover et temps avant de quitter la cellule actuelle, en appliquant le filtre
60
Grey et renvoie la dcision de faire un handover si la valeur du RSS de lAP actuel atteint un certain seuil est atteint.
Algorithme 2 : prdiction des Tbho et Tbmo
for each k,l do if (ActualAPk + ho_threshold > BestAPk) and (ActualAPl > border_treshold) then Tbho = k, Tbmo = l return Tbho,Tbmo end for
Etape 3. Mcanisme de mise en cache est dcrit dans lalgorithme 3, celui-ci prend en compte les temps Tbho, Tbmo, le bit rate de la vido et la connexion disponible pour ouvrir un nombre prcis de connexions (suivant la relation ) pour alimenter les buffers correspondant. Ce remplissage se fait bien videmment partir de positions futures dans la vido.
Algorithme 3 : mise en cache
n_connections = bandwidth-stream_rate/stream_rate open_rtsp(n_connections,n_buffers) while Tbho0 and not_connected do for each icon <= n_connections do get_rtsp_packets(posicon,buffericon)
end for
Tbho- -
end while
Lexcution du handover (Algorithme 4) commence lorsque le mobile est la frontire de la cellule actuelle. Cest ce moment prcis ou sont lances deux mthodes, la slection du nouvel AP et le rtablissement de la connexion avec mobile IP, avec le filtrage du flux MPEG2-TS la reprise du streaming via le nouvel AP, une tape de calibrage des trames TS qui encapsulent les flux MPEG2 est ncessaires. Elle permet de juxtaposer les flux venant des buffers avec celui que le client reoit une fois la connexion au rseau est rtablie.
61
Algorithme 4: excution du handover
if new_ap_selected then for each icon and (buffericon empty_buffer) do

play_from_buffer(buffericon) buffericon = empty_buffer
end for
associate(BestAp) retrieve_mobile_ip(new_address) rtsp_get(server_ip,last_buffer_pos) calibrate_stream(buffermax-icon, playback_buffer) gather_info(ActualAP,BestAp)
end if
La figure suivante rsume lessentiel des composantes logicielles intervenant dans notre proposition exprimentale.
Figure 13 Composantes logicielles de SM Stream
3.7.3.3.
Rsultats
En s'loignant de l'AP1, les valeurs mesures des RSS des trois AP sont prsentes dans la fFigure 14. Aprs avoir recueilli 20 chantillons RSS mesurs partir de lAP1 et lAP2, le systme de prdiction de handover est l pour estimer le Tbho. Ces valeurs sont galement dcrites sur la Figure 15. Ce rsultat est obtenu dans le cas d'un h = 0. La figure montre clairement que la diffrence entre les Tbho rel et Tbho prdit est trs faible. Ceci confirme la faisabilit et, une fois de plus, l'efficacit de la mthode de prdiction propose.
62
Figure 14 Evolution des RSS reus
Ensuite, nous valuons la performance du mcanisme de buffering. Premirement, nous provoquons plusieurs handovers entre AP1 et AP2 et nous collectons suffisamment d'information sur le dlai du handover. Notons que le dlai maximum de handover peut atteindre 8 secondes. Cette valeur est ensuite mise dans le schma de buffering. En outre, la bande passante disponible est rgulirement contrle par Stab et le dlai de connexion Tcon est fix 2 RTT. Dans un mode de fonctionnement normal, le client stocke environ 2 secondes de la vido dans le buffer. Dans notre exprience, la tche de buffering dcide d'ouvrir une seconde connexion la t=19s et le handover se produit t=22. L'volution de la taille du buffer est prsente dans la Figure 15. Notons que la taille de la vido est ici exprime en terme de son temps de lecture pas en octets. Nous constatons que la taille du buffer n'est jamais nulle, mme au cours de la priode du handover. Et donc aucune interruption dans la visualisation na lieu. Aussi, la taille du buffer n'est jamais trop grande. Celle-ci augmente uniquement lors de la prparation du handover. Elle implique l'efficacit de l'utilisation de la mmoire. Ce rsultat exprimental confirme la faisabilit de notre solution pour le streaming multimdia pour les utilisateurs mobiles travers les rseaux sans fils.
63
Figure 15: Tbho prdit et volution du buffer
3.8. Conclusion
Dans ce chapitre nous avons adress le streaming de la vido en mobilit dans un rseau sans fils multi-cellules. Plus prcisment, nous rsolvons les problmes lis l'impact dfavorable de la mobilit d'un terminal, entre diffrents points d'accs sans fil, sur la qualit du streaming vido. Ce travail a permis de proposer un mcanisme de buffering ractif bas sur la prdiction du temps avant le handover. Grce une implmentation relle de ce mcanisme de buffering associ une anticipation du handover, nous avons pu, ainsi, valider des modles thoriques proposs pour l'optimisation du buffering.
Chapitre 4. MADP2PStream: Modle de streaming peer to peer sur rseaux ad hoc mobiles
4.1. Introduction
Un concepteur doit valuer, en plus de l'intgrit, un certain nombre d'indicateurs de performance d'un protocole. Il existe essentiellement trois outils disponibles pour raliser une telle valuation: la modlisation analytique, la simulation et le prototypage. Mme si l'implmentation et l'essai direct ( l'aide de simulation ou d'un prototype) semblent tre la faon la plus simple pour valuer les rseaux P2P, il n'est pas toujours ais de suivre cette approche. Les simulations ou Les mesures directes sur des prototypes prsentent des problmes de passage l'chelle. En effet, celles-ci sont gnralement ralises dans des systmes de petite taille qui ne refltent pas forcment le comportement du systme large chelle. Les rseaux P2P reprsentent en effet l'oppos de cette situation: la taille typique d'une communaut P2P commence partir de milliers d'utilisateurs (pour la diffusion) des millions d'utilisateurs (pour le partage de fichiers). Ds lors, se pose le problme de la simulation de rseaux dune telle taille. Si, d'une part, les outils analytiques ne prsentent pas ce problme de passage l'chelle, ils ne permettent en gnral de modliser quun comportement simplifi du systme. En effet, construire un modle analytique complet dun systme complexe comme les rseaux P2P est une tche difficile voire impossible: car celui-ci doit reprsenter toutes les caractristiques essentielles du systme tudi tout en supposant que le comportement de certains lments du systme ont un faible impact sur sa performance globale. Le challenge de la modlisation est effectivement de trouver un outil d'analyse qui soit capable prendre en compte ces simplifications sans compromettre la fidlit de la modlisation du comportement global du systme. Comme nous lavons soulign, le streaming vido en p2p a t propos comme solution au dploiement coteux de serveurs vido tirant parti des ressources de chacun des pairs. Cette utilisation des ressources de chaque paire permet d'quilibrer la charge induite par le transfert de contenus vido entre les diffrents pairs. Lutilisation de cette mme technique initialement dveloppe pour les rseaux infrastructure vers les rseaux ad hoc mobiles introduit de nombreuses
65
66
Chapitre 4 MADP2PStream: Modle de streaming peer to peer sur rseaux ad hoc mobiles
difficults telles que la la les problmes de connectivit et , la monopolisation de la puissance de calcul, la mmoire vive ainsi que la capacit de stockage des paires par les tches en rapport avec le rseau p2p. Tous ces aspects doivent tre tudis pour proposer ou valider de nouvelles solutions de streaming sur des rseaux ad hoc. Dans ce chapitre, nous proposons un nouveau modle analytique appel MADP2PStream (Mobile AD hoc Peer TO Peer STREAMing) dont le but est de modliser de manire adquate le service peer to peer streaming sur MANET. La contribution principale est l'introduction de la mobilit dans un modle de streaming peer to peer existant afin de pouvoir identifier les paramtres essentiels prendre en compte pour dvelopper des protocoles de streaming p2p qui soient efficaces sur des rseaux ad hoc mobiles. Il sagit en effet de cerner, grce ce modle, les perturbations qui peuvent survenir dans le systme en raison de la dynamique additionnelle engendre par la mobilit des nuds.
4.1.1.
Objectif de cette contribution
Le rcent succs des applications de streaming p2p dpasse celui des protocoles traditionnels, les protocoles clients/serveurs ou multicast. Les architectures bases sur les arbres applicatifs proposes auparavant, cohabitent maintenant avec des structures mailles plus rsistantes la variation des dbits dans les environnements sans fils et la dynamique des nuds mobiles. Lutilisation de la technologie p2p dans les environnements MANET est tape naturelle de ce dveloppement. Nanmoins, la migration des applications p2p streaming d'un environnement fixe vers les rseaux MANET ne se fait pas sans problmes et ncessite de lever un ensemble de verrous. Dans ce chapitre nous proposons un modle qui permet, lors du port du streaming p2p classique (fixe) sur MANET, de capturer les paramtres essentiels qui affectent le systme; c'est-dire le comportement du systme lorsque les paires sont mobiles. Ces mtriques sont principalement relies la qualit du streaming; c'est--dire dune part les dlais de la distribution des lments du stream aux diffrents nuds et dautre part la connectivit d'un nud. En effet, dans le cas dune forte mobilit, la connectivit dun nud peut avoir un impact important sur les pertes des paquets et donc sur la qualit du stream. Afin de prendre en compte ces diffrents aspects, cette contribution vise concevoir un modle, qui se veut le plus exhaustif, pour reprsenter le comportement du streaming p2P multimdia sur les rseaux ad hoc mobiles. Nous prenons en compte trois aspects importants que sont: (i) les technique de streaming p2p prsents dans le modle de Carra et al et introduit dans la section 4.3 (ii) Le modle de mobilit bas sur les communauts sociales, propos par Musolesi et al., et dcrit dans le point 4.4 ; et enfin, (iii) la prise en compte de l'overhead des protocoles de routage proposs par Vinnot et al. est dtailles dans la section 4.5.
67
Une fois construit, ce modle est valu numriquement (en section 4.7), grce aux modification de Groover14, un solveur numrique propos par Carra et al., dans lequel nous avons intgr une fonction de gnration de matrice de connectivit base sur les interactions sociales des nuds mobiles. Dans le calcul du dlai nous avons aussi soustrait des dbits offerts par chaque nud, l'overhead provoqu par les messages de maintenance des protocoles de routage. Ce modle et son valuation permettent de mieux comprendre fonctionnement du streaming p2p sur des ad hoc mobiles.
4.2. Travaux existants

Plusieurs travaux en rapport avec cette problmatique existent. Carra et al. dans [108][109] proposent un modle analytique complet qui rgit les protocoles de distribution de contenus rsolu par la mthode Monte-Carlo. Le modle intgre un ensemble d'quations diffrentielles qui dterminent les mtriques les plus importantes du streaming; telles que les dlais de tlchargement et le nombre de sauts qui sparent le nud rcepteur de la source. Plusieurs architectures de distribution bases sur les arbres et les mailles (dite mesh) ont t modlises et rsolues numriquement dans [110][111]. Ce modle a lavantage de bien tre adapt des scnarios prsentant un trs grand nombre de nuds. Il permet de quantifier avec prcision les diffrences entre ces deux architectures de distribution de contenu. Dans cette contribution, notre intrt est porte plus particulirement sur les topologies mesh, car elles sont plus efficaces que celles base darbres. Cette proposition nous semble plus pertinente pour supporter la mobilit dans le modle du streaming p2p sur MANET et serait donc intressant dobserver alors son impact sur la qualit du streaming. Biskupski et al. [112] ont tudi la topologie en mesh pour le streaming p2p. Ayant assimil une topologie mesh plusieurs arbres applicatifs de diffusion, les auteurs soulignent les proprits des arbres de diffusion qui apparaissent dans ce mesh. Ils recensent les diffrentes caractristiques pour enfin les comparer aux arbres diffusion optimale. Les auteurs montrent ainsi que les arbres qui mergent sont de hauteur sous-optimale et dsquilibrs, ce qui se traduit par une augmentation du retard de la mise en cache dans ce type de systme p2p et en particulier dans des environnements htrognes. Cependant, pour palier ce problme, ils proposent un algorithme d'optimisation permet d'adapter la topologie du mesh afin de raccourcir la hauteur des arbres de diffusion et rduire ainsi les dlais du buffering. Nanmoins, dans le cas de mobilit, comme nous lavons soulign, la topologie mesh reste la structure la plus optimale pour supporter la dynamique des nuds mobiles.
14
Stochastic graph process solver, disponible en ligne sur http://dit.unitn.it/networking/groover-main.html
68
Dans [112], les auteurs prsentent une tude analytique quantitative des caractristiques d'un modle de streaming hybride. Sur cette base, ils drivent une quation qui dcrit l'volution de la capacit du systme de streaming d'un seul fichier. Ils tendent ensuite ltude un scnario de streaming de fichiers multiples. Ils montrent aussi comment un tel systme peut rpartir de manire optimale la bande passante du serveur entre les diffrents fichiers existant. Le dpart ou la panne imprvisible des pairs tant un facteur critique qui affecte les performances d'un systme P2P, les auteurs proposent alors la notion de dure de vie des pairs pour modliser lchec daccs un pair (gnre par une distribution exponentielle) et introduisent une quation initiale d'volution de la capacit du systme. Dans notre contribution, en plus de la dynamique gnre par les dparts des nuds, nous nous intressons galement celle provoque par leur mobilit. En ralit, la notion de dure de vie change sensiblement dans le cas de nuds mobiles car ils peuvent toujours tre prsents dans le rseau mais pas dans le mme voisinage. La modlisation du streaming p2p sur MANET a fait lobjet de trs peu de travaux. Nanmoins, un travail intressant dans ce domaine a fait lobjet de notre attention et est prsent dans la section suivante, cest celui de Carra et al. Ce modle
4.3. Modlisation du p2p streaming bas sur le modle de Carra et
al.
Les Processus de Graphe Stochastique avec Contraintes (CSGP : Constrained Stochastic Graph Processes), prsents dans [115], sont connus pour leur puissance danalyse des systmes p2p de distribution de contenu. En effet, ils permettent dtudier dautres contraintes que le temps de tlchargement qui nest plus suffisant quon il sagit dapplications de streaming dans lesquels le dlai, reprsent par la distance en nombre de sauts entre la source du stream et la destination, est une mtrique essentielle Carra et al, ont en effet utilis les CSGP pour construire un modle analytique du streaming p2p. Ce modle nous a inspir pour construire notre propre modle. Le modle de Carra et all capture, en effet, parfaitement les lments cl dune application de streaming, savoir le nombre des liens actifs, et les dlais de lecture la rception de la vido, ainsi que la probabilit de ne pas recevoir la vido cause de la dynamique du rseau.
4.3.1.
Principes de base
Le modle considre le systme un instant t, chaque nud deux types de relations: des parents (ou des enfants) et des voisins. Pour les parents, un identifiant de la bande changes est associ diffrents identifiants sont slectionns selon ltat de la bande, qui peut tre actif ou en veille.
69
Une bande tant une proportion dun flux multimdia et plusieurs bandes sont ncessaires pour reconstruire un stream. Soit k et k, respectivement, les identifiants actifs et en veille dune bande k. est l'identifiant qui indique que deux nuds sont voisines dans loverlay. Le graphe reprsentant les rseaux de distribution peut donc tre dcrit par la matrice de connectivit S, o chaque lment sij dcrit la relation entre les nuds i et j: nchangent pas de bandesk si les nuds i et j sont voisins, et i est un parent actif de j avec une k si les nuds i et j sont voisins et i est un parent en veille de j avec une bande j k tant donn que chaque parent peut envoyer une seule bande chaque enfant, sij peut prendre seulement les valeurs dfinies ci-dessus. En plus de la matrice dadjacence, chaque nud a un dbit sortant qui peut tre reprsent, pour un dbit par bande connu, par le nombre maximum d'enfants qu'un parent actif peut supporter. Les transitions d'tat sont dtermines par les vnements tels larrive, le dpart, et la mise jour. Nous supposons que les taux dapparition de ces vnements sont distribus exponentiellement avec respectivement les paramtres , et up. Pour chaque vnement, il est possible de calculer les probabilits de transition d'un tat S un tat S' dfinit par une nouvelle matrice de connectivit. Chaque vnement correspond une srie d'oprations. Par consquent, la transition correspondante n'est pas simple et de plus d'un lment dans la matrice de connectivit pourrait changer. Contrairement aux diffrents modles analytiques proposs et prsents dans la littrature lesquels ne permettent danalyser que des graphes statiques[113], le modle de Carra et al bas sur les graphes stochastiques permet de raliser les mme analyses dans des graphes. Ce formalisme mathmatique est utilis pour tudier les problmes fondamentaux de performance des systmes de streaming peer to peer. Le niveau dabstraction quil offre a lavantage de capturer les comportements des nuds dans diffrentes conditions de rseau en gardant une complexit limite. Le modle de Carra et al est trs important dans la ralisation de notre objectif de modlisation du streaming p2p sur MANET par sa prise en compte de la dynamique du rseau, c'est--dire lvolution du graphe dans le temps.
4.3.2.
Analyse des applications streaming fondes sur le mesh
F Dans ce modle de carra et all, le rseau p2p est reprsent par un graphe dont les sommets sont les nuds et les arrtes refltent leurs relations rciproques. Quand un utilisateur commence partager de la vido, il reoit et retransmet les paquets vido, il utilise un sous ensemble de ses connexions actives (sortantes et entrantes). Le nombre de parents actifs constitue une mtrique
70
qui mesure la qualit de rception de la vido. Notre objectif est danalyser les caractristiques de ce graphe de distribution et plus particulirement le sous graphe, construit par lapplication de streaming exploit par les nuds mobiles, comme illustre dans la Figure 16.
Figure 16 Couches du modle
En gnral, le graphe du streaming p2p varie dans le temps. A tout moment, des nuds et des liens sont amens ragir processus stochastique aux ou disparaitre. Cette volution peut alors tre perue comme un proprits markoviennes, parce qu un instant t+t, le graphe
dpend troitement de son tat prcdent, soit linstant t ; ainsi que de tous les vnements qui surviennent durant t, tels que larriv, le dpart ou, dans notre cas, la mobilit des nuds. Le modle sapplique nimporte quelle application de streaming p2p, car il en capture les caractristiques de base, communes tous les protocoles de type hybride tels que prsents dans [136][137], o le rseau mesh est construit par la superposition de plusieurs arbres. Considrons alors une application de streaming p2p qui construit un rseau overlay. Le contenu est distribu en utilisant diffrentes bandes. Une bande tant une proportion dun flux multimdia. En rsum, et partir de la comparaison dans le paragraphe 2.2.2.4.c, il apparait vident que les topologies mesh sont les plus adquates pour le support de la mobilit, car les arbres sont trs difficiles maintenir en cas de mobilit et de dynamique forte dans les arbres. Nous avons donc adopt dans notre tude une topologie de type mesh, ce qui rejoint galement les principes mme du peer to peer streaming.
71
4.3.3.
4.3.3.1.
Comportement du systme cibl

Le streaming
Le contenu est distribu en utilisant R diffrentes bandes. Chaque bande contient une partie du flux (code en utilisant une techniques telle que le MDC : Multiple Description Coding [119]). Un nud a besoin de R'<R, sur les R bandes qui composent le flux, pour parvenir reconstituer le stream avec une bonne qualit, tandis que le reste, c'est--dire les R - R' bandes, contiennent des informations redondantes qui servent, par des mcanismes de correction derreurs (tels que le FEC : Forward Error Correction [121]), corriger les ventuelles pertes de paquets vido. Dans le cas de topologies fixe, l'volution du rseau est soumise deux principaux vnements que sont : larrive et le dpart des nuds. Nous supposons que les arrives et les dparts sont distribus exponentiellement avec des taux respectifs (t) et (t). La dpendance du modle du temps, rend le model plus souple et permet de dcrire divers modes d'arrive, comme le flash crowd (arrives massives), phnomne trs connu dans la communaut p2p. Le modle dfinit la dure de la vido par tstr et le nombre moyen de nuds rcepteurs par N. Une fraction des nuds rejoint le rseau t=0, et il y a un dlai de temps pendant lequel (t) reste suprieur (t) et cela jusqu' ce que l'tat stationnaire soit atteint. Le cas dun rseau ad hoc mobile, lessentiel de notre contribution, sera explicit dans la section 4.6. Le taux de dpart (t) correspond linverse de la moyenne du temps pass par un nud dans le systme (temps de sjour). A ltat stationnaire, les dparts et les arrives de nuds se compensent. Durant un intervalle de temps T, le rapport entre le nombre total de dparts et le nombre moyen de nuds actifs dfinit la dynamique du systme. Par exemple, si ce paramtre est gal 1, cela veut dire quau cours de lintervalle T le nombre de nuds ayant quitt le rseau est gal la moyenne des nuds du systme, en dautres termes, il y a un changement stochastique complet des nuds durant cette priode. Les nuds sont rpartis en diffrentes classes en fonction de leur bande passante. Chaque classe j a des dbits montant bu(j) et descendant bd(j), qui peuvent tre symtriques, asymtriques ou corrls, par exemple, bdi+bui constant, comme dans un cas o le medium d'accs est partag(cas des rseaux sans fils). Les bandes passantes sont des variables alatoires dcrites par une fonction de densit de probabilit connue. Nous supposons que tous les nuds ont un dbit de tlchargement au moins gal la vitesse de la vido est gale rstr. Ds lors, chaque bande peut tre tlcharge une vitesse gale rstr/R'. Nous supposons que le serveur est capable denvoyer toutes les bandes R, c'est--dire, quil a une bande passante suprieure R.rstr/R'. Par ailleurs, chaque nud a une contrainte, sur les nombres
72
maximum kmax et minimum kmin de tlchargements, qui limitent la possibilit de degrs sortants du nud. Parmi ses B voisins, un nud choisit ses parents, c'est--dire, ceux auprs desquels il obtient la vido. Seuls R parents sont actifs la fois tandis que les autres restent en veille, dans la mesure o ils ne seront utiliss en backup dans le cas de la dfaillance dun ou plusieurs parents actifs.
4.3.3.2.
Arrive, dpart & mise jour
A la cration de rseau, les nuds construisent un arbre de diffusion par bande. Le nombre de nuds dans chaque arbre dpend des caractristiques de la diffusion, par exemple, les dbits de sortie des nuds parents, qui limitent le nombre de fils quils peuvent avoir. Chacun des nuds collabore avec plusieurs arbres de diffusion la fois. Quand un nouveau nud arrive, il choisit au hasard un premier nud de contact, grce auquel il construit sa liste de voisins. Afin daugmenter son degr de connexion, un nud choisit priodiquement de nouveaux liens parmi ses voisins avec une frquence up. Lorsquun nud quitte le rseau p2p, toutes ses connexions entrantes et sortantes sont annules. Ceci met des nuds dans un tat orphelin lesquels vont tenter de trouver un nouveau nud parent dans leur voisinage. Si le parent disparu sest mis au pralablement en veille, le nud ne ragit pas (il perd tout simplement un parent de secoure). Si le parent disparu tait actif, le nud tente alors de solliciter dabord lun de ses parents de secoure, c'est--dire, quil va dabord essayer de tlcharger le stream partir du parent en veille si celui-ci dispose dun dbit disponible. Si le nud n'a pas de parents de secoure, il perd temporairement la rception du stream et donc de la qualit pendant toute la priode de recherche dun nouveau parent.
4.3.4.
Modle mathmatique
L'analyse du graphe peut tre ralise travers l'tude des proprits de distributions de degr et de dlai. Etant donn un processus Markovien, le comportement temporel peut tre dcrit en utilisant une quation diffrentielle de type Chapman-Kolmogorov, connue sous le nom dEquation Maitresse (EM) [115]. Pour un nud s, la variation de la probabilit de trouver la valeur ( tant le degr de connexion ou le dlai) au temps t, peut sexprimer par :
,
t p , t (4.1)
o w(t) est le taux de transition de la valeur la valeur au moment t. Les taux de transition sont troitement lis aux politiques du protocole de streaming. La formulation gnrale de lEM doit tre spcifique notre problme, c'est--dire, le modle doit dfinir toutes les transitions possibles. LEM dtermine l'volution dans le temps du systme stochastique pour chaque nud s.
73
Il est galement intressant d'avoir des reprsentations de la valeur moyenne (degr k ou dlai l). Le modle de Carra prvoit des quations dites de taux (Rate Equations : RE): t t p , t 4.2
Celles-ci dcrivent la moyenne des quantits et expriment le comportement dterministe du systme: en fait, les REs sont un ensemble d'quations diffrentielles qui dcrivent l'volution temporelle de la moyenne des proprits du systme. La Figure 17 montre la relation entre les rsultats de lEM et le rsultat de la RE pour une variable alatoire donne par exemple, la connectivit (degr) et le dlai (nombre de sauts) dun nud. Lquation maitresse donne un aperu clair du systme, car elle caractrise ses proprits dans le temps. Tandis que, lquation de taux donne une valeur moyenne qui est quivalente l'approximation du systme.
Figure 17 : Comparaison des rsultats des quations matresse et de taux [109]
A partir de ces quation Carra et al. dduisent celles reprsentant les caractristiques principales du graphe de distribution du streaming : savoir la distribution de probabilits du degr et du dlai. Ds lors, partir de ces formules, lanalyse du graphe peut tre envisage. La distribution du degr de connexion ps(k,t) est la probabilit que le nud s ait k connexions linstant t. En ayant la distribution du degr de chaque nud dans le graphe, nous pouvons dduire degr total de connexion du rseau : , 1 , 4.3
N (t) tant le nombre de nuds attachs au rseau un instant t. Nous pouvons facilement distinguer entre les degrs sortant et entrant en dfinissant une quation pour chaque type de connexion.
74
La distribution du dlai reprsente la distance entre le nud source du flux et le nud de destination selon lalgorithme du plus court chemin. Soit ps(l, t) la probabilit que le nud s soit sauts de la source un instant t. La distribution globale du dlai est drive de la mme manire que la formule prcdente et peut sexprimer comme suit: , , (4.4)
Lapproche propose par Carra et al. Permet de fournir la solution de lEM, et donc, la caractrisation complte du systme. Lorsque la complexit du graphe augmente les ressources ncessaires pour le rsoudre deviennent couteuses, pour cela les auteurs proposent de se concentrer sur les RE afin d'obtenir une analyse de la valeur moyenne. Ainsi, leur mthode offre une grande souplesse qui nous permet de dcider du niveau de dtail souhait dans lanalyse de notre systme. Pour de plus amples informations quant la description dtaille de ce modle, le lecteur peut se rfrer aux travaux de Carra et al prsents dans [108][109]. Dans la section 4.6, nous mettons en uvre cette reprsentation analytique pour finir ltude que nous menons sur les streaming p2p sur MANET.
4.4. Modlisation de la mobilit par Musolesi et al.

Le modle de mobilit est trs important dans ltude des rseaux. Ce domaine a connu un intrt croissant ses dernires annes pour essayer de comprendre comment la mobilit impact sur les performances du rseau. Parmi les modles de mobilit que nous avons prsents dans la section 2.3.2, nous utiliseront le modle de mobilit bas sur la notion de communaut issu de la thorie des rseaux sociaux [121]. Un des principaux points forts de ce modle est le rseau social, qui relie les utilisateurs mobiles entre eux afin de gnrer synthtiquement des structures de rseau ralistes. Ce modle permet une collection dhtes dtre regroups d'une manire reprsentative des relations sociales entre les individus ou les affinits quils entretiennent. Ce regroupement est alors seulement reflt sur un espace topologique, avec une topographie biaise par la force des liens sociaux. Les mouvements des nuds sont galement rgis par les relations entre eux. Le modle permet dfinir diffrents types de relations sur une priode de temps dfinie (journe, semaine, etc.). Il serait intressant, par exemple, de pouvoir dcrire des relations professionnelles (cd sur le lieu de travail pendant les heures de travail, les jours de semaine) avec un poids plus important que les relations familiales ou amicales (cd les soirs et week-ends). Ce modle a t valu au moyen de traces relles de mobilit fournies par le Laboratoire de recherche Intel dans [128], o les auteurs montrent que le modle fournit une bonne approximation
75
de mouvements rels vis vis de plusieurs paramtres fondamentaux, telles que la rpartition de la dure des contacts et des temps d'inter-contacts. En particulier, les donnes montrent qu'une loi de puissance approximative rgit une grande gamme des temps d'inter-contacts contrairement aux dures de contacts qui suivent la mme loi mais sur un ventail plus limit de valeurs. Ces caractristiques statistiques sont galement trs similaires celles observes par les chercheurs de l'universit de Californie San Diego et du Dartmouth College [129]. Un exemple de rseau social est reprsent dans la Figure 18. Le rseau social est reprsent par graphes pondr ou chaque lien dfinit le degr daffinit entre deux individus.
Figure 18: Un exemple de rseau social [121]
Nous allons maintenant, partir de ce graphe social, dcrire plus en dtails les aspects essentiels du modle de mobilit bas sur la communaut.
4.4.1.
Matrice d'affinit (affinity)
Dans le graphe social, chaque nud reprsente une personne. Le poids, associs chaque lien du rseau, sont utiliss pour modliser la force des interactions entre les individus (affinit). Nous supposons que ces poids, qui sont exprims en tant que mesure de l'affinit des liens sociaux, peuvent aussi tre vus comme une mesure de la probabilit de co-localisation gographique. Nous modlisons le degr d'affinit sociale entre deux personnes par une variable dont les valeurs sont comprises dans l'intervalle [0, 1]. 0 indique que affinit est quasi absente ; alors que 1 indique une affinit sociale absolue. Diffrents rseaux sociaux peuvent tre valables pour les diffrents moments de la journe ou de la semaine. Ainsi, le rseau prsent dans la Figure 18 peut tre reprsent par une matrice symtrique Aff de 10 10 illustre sur la Figure 19. Les lignes et colonnes correspondent des noms de nuds. Dans ce qui suit, cette matrice sera appele matrice d'affinit. L'lment gnrique Aff(i,j) qui reprsente l'affinit entre deux individus i et j , sera appel indicateur d'affinit. Les valeurs diagonale reprsentent les relations de l'individu avec lui-mme et sont, par convention, 1..
76
Figure 19: Exemple d'une Matrice d'affinit reprsentant un rseau social.
La dfinition de cette matrice d'affinit est une tape cl de ce modle. Il s'agit clairement d'un modle simplifi de relations humaines. La dfinition de ces poids est un domaine de recherche part entire en sociologie [128]. La matrice d'affinit est galement utilise pour gnrer la matrice dadjacence ou de connectivit. En partant de la matrice Aff, nous gnrons une matrice C des donne en entre Ci,j
,
si et
seulement si Affi,j est suprieure un certain seuil. La connectivit gnre par la matrice d'affinit, est illusre sur la Figure 20. L'ide cardinale, est davoir un seuil daffinit au-dessus duquel deux personnes sont considres tre en relation.
Figure 20:Exemple de matrice dadjacence reprsentant le rseau social.
4.4.2.
Modle social de la communaut
La matrice d'affinit, et par consquent, la matrice de connectivit, peuvent tre obtenues, soit partir de donnes disponibles (par exemple, une enqute sociologique), ou bien, en utilisant des modles mathmatiques reproduisant des caractristiques particulires des rseaux sociaux rels. Le community based mobility model utilise par dfaut le modle social Caveman [122] pour la gnration de rseaux sociaux ralistes, base sur la notion de clustering et une faible longueur moyenne du chemin (diamtre du graphe). Cependant, il s'agit d'un aspect personnalisable, c'est dire, si le type de scnario tester est clair, une matrice dfinie par l'utilisateur peut aussi tre utilise. Le scnario de simulation est tabli par la transposition des groupes d'htes sur certaines zones de l'espace gographique. Aprs la dfinition du graphe social dcrit ci-dessus, les groupes, un
77
ensemble de nuds fortement connects dans le graphe, doivent tre isols. Les auteurs utilisent l'algorithme propos dans [127] pour dtecter la prsence de structures de communauts dans les rseaux sociaux reprsents par des matrices, telles que la matrice de connectivit dfinie prcdemment. Cet algorithme est bas sur le calcul de ce que l'on appelle betweenness d'une arte. Celle-ci donne une mesure de la centralit des nuds .
Figure 21: Exemple d'une communaut mobile [121].
Afin d'illustrer ce processus, nous devons maintenant examiner le rseau social dans la Figure 18. Trois communauts sont dtects: C1 = (A, B, C), C2 = (D, E, F, G) et C3 = (H, I, L). Maintenant que les communauts sont identifies compte tenu de la matrice, celles-ci doivent tre associes leurs positions. Une fois les communauts identifies, chacune d'elles est associe de manire alatoire une position gographique donne sur une grille (c'est--dire, une case). Nous utilisons le symbole Sp, q pour noter une case de coordonnes p,q. Le nombre de lignes et de colonnes sont des entres du modle de mobilit. En revenant l'exemple, nous pouvons voir comment ces groupes peuvent tre placs sur une grille de 3x4 (la dimension de la grille est configurable par l'utilisateur et agit sur la densit des nuds dans chaque case). Les trois communauts C1, C2, C3 sont places respectivement dans la grille dans les cases Sa, 2, Sc,2, Sb,4. Chaque nud d'une communaut est plac dans des positions choisies au hasard l'intrieur de la case attribue.
78
Comme dcrit dans le paragraphe prcdent, un mobile est d'abord plac dans une certaine position dans la grille. Puis, afin de dicter son mouvement, un objectif lui est assign. Plus formellement, nous disons que tout mobile m est associ une case Sp,q si la ralisation de son objectif peut se faire l'intrieur de cette case. Notons que le nud m n'est pas toujours ncessairement plac l'intrieur de la case Sp, q, en dpit de cette association (voir ci-dessous). L'objectif d'un nud est simplement un point reprsentant sa destination finale (mme principe que celui du modle Random Way-Point), sauf que la slection de l'objectif n'est pas alatoire. Quand elle est initialement tablie, la destination de chaque mobile est choisie au hasard l'intrieur du carr associ sa communaut (c'est--dire, les premiers objectifs de tous les membres de la communaut C1 seront choisis l'intrieur de la case Sa, 2 Quand un objectif est atteint, un nouvel objectif est choisi de la manire suivante: Un certain nombre d'htes (zro ou plus) sont associs chaque carr Sp,q un instant t. Pour un nud donn, chaque carr exerce une certaine attractivit sociale. Celle-ci reprsente une mesure de son importance en termes de relation sociale pour les nuds mobiles. L'importance sociale est calcule en valuant la force des relations avec les htes qui se dirigent vers cette mme case (c'est--dire, avec ceux qui ont pour objectif actuel cette case particulire). Plus formellement, tant donn CSp, q (c'est--dire, l'ensemble des htes associe la case Sp,q), SAp,qi sui dfinit l'attractivit sociale de cette case pour le mobile peut tre calcul de la manire suivante :
,
,
4.5
O w reprsente le nombre de mobiles associs la case Sp,q. Ici, lattractivit sociale de la case situe la position (p, q) pour un hte i est dfinie par la somme des indicateurs d'affinit que reprsentent ses relations avec les autres htes situs dans cette mme case, normalis par le nombre total d'htes associs cette case. Si w=0 (c'est--dire, la case est vide), la valeur du SAp, qi devient nulle. Le modle de mobilit choisi propose deux mcanismes de slection du prochain objectif ; le premier, dterministe, bas sur la slection de la case de plus forte attractivit ; et le deuxime, probabiliste, bas sur une probabilit de slection d'un but dans un carr proportionnellement son attractivit. Dans la premire approche, les objectifs sont choisis uniquement l'intrieur des carrs associs la communaut, tandis que dans la seconde, les mobiles peuvent galement choisir, au hasard, leurs objectifs dans d'autres endroits de lespace de simulation, avec une certaine probabilit.
79
Plus prcisment, le deuxime mcanisme permet une slection des destinations non pas uniquement sur la base des relations sociales pour ajouter plus de ralisme au modle. Grce ce mcanisme, le nouvel objectif est choisi, au hasard, l'intrieur du carr caractris par la plus forte attractivit sociale; cela peut tre l'intrieur de la mme case ou dans une autre. De nouveaux objectifs sont choisis l'intrieur de la mme zone lorsque le rseau social, en entre, se compose de communauts faiblement connectes. Dans ce cas, les htes associs diffrentes communauts ont, en moyenne, de faibles relations entre eux. D'autre part, quand un mobile a de solides relations avec les deux groupes, il peut tre attir par une autre case. Dun point de vue thorie des graphes, cela signifie que l'hte est situ entre deux (ou plusieurs) clusters de nuds dans le rseau social. Une solution alternative choisit le prochain objectif selon l'attractivit de chaque zone de lespace. C'est--dire, le modle attribue une probabilit P(s = Sp,qi), de slectionner la case Sp, qi dfinie comme suit:
,
, ,
(4.6)
o d>1 est une valeur alatoire qui assure que la probabilit de choisir une destination dans un carr soit toujours non nulle. Le paramtre d peut tre utilis pour augmenter le caractre alatoire du modle lors de la slection du nouvel objectif. Ceci peut tre utilis pour augmenter le ralisme du scnario de gnration, car, dans des situations relles, les humains se dplacent galement vers des zones o il ny a personne pour des raisons non lies leur environnement social.
4.5. Prise en compte de loverhead dans le calcul des dlais

Les es travaux de Vinnot et al. [128] valuent, d'une manire substantielle, le dbit consomm par la circulation des messages de contrle gnrs par les protocoles de routage, ractifs et proactifs. En effet, le modle qu'ils proposent permet de prdire l'overhead en considrant la mobilit et le type de routage. Il prend en compte diffrents paramtres du rseau tels que la densit des nuds , le taux de mobilit . Les paramtres utilis pour modliser le trafic rseau sont: le nombre de nuds mobiles N, la dure de vie moyenne d'un lien Tvie, sachant que Tvie = 1/ est le taux de perte de liens). En ce qui concerne le modle de mobilit, la longueur moyenne d'un chemin L, dpend principalement de la topologie du rseau. Les auteurs supposent que et L restent constants dans un rseau toujours connect. Selon le type de protocoles de routages ad hoc, ractif ou proactif, certains paramtres viennent complter le modle.
80
4.5.1.
Cas de protocole ractif
Kj Les paramtres suivants sont utiliss pour modliser un protocole ractif: le nombre moyen de routes cres par nud (Route Request), et le nombre de routes actives par nud. Une route active correspond un chemin par lequel la source envoie des paquets en continue vers une destination. Les protocoles ractifs peuvent inclure des messages hello pour prvenir la perte de lien (Cf. 2.3.1.1). Si c'est le cas, hr dnote leur frquence et Hr leur taille. Nous devons aussi considrer des mtriques spcifiques au protocole [128]: le nombre moyen d'mission de Route Request (peut aussi inclure les nombre de Route Reply de la destination) Br, ainsi que le facteur d'optimisation de la requte de route, qui dpend des paramtres du rseau et du trafic (or=Br/N). Pour un protocole d'inondation pure, si nous considrons le Route Reply, nous obtenons or = 1 + R/N, R tant le nombre des messages de rponse. La surcharge gnre par l'envoi de messages hello est donc hr.N paquets par seconde consommant ainsi un dbit de hr..Hr .N. Dans le cas d'un rseau ad hoc fixe, un protocole de routage ractif produit des requtes de route chaque seconde. Ceci va gnrer .or.N paquets de contrle dans le rseau; Donc la surcharge totale provoque par le protocole de routage est: . . . . . . . 4.7 4.8
si RQr dsigne la taille d'un paquet de requte, donc cet overhead occupe une bande passante de: .
Sachant que la mobilit dans un MANET est considre comme une succession de perte et de cration de lien. La perte de lien est la reprsentation la plus significative de la raction du protocole de routage la mobilit des nuds, car il doit ragir rapidement cette perte surtout quand le lien fait partie d'une liaison active. Toutefois, quand une perte de lien est dtecte, le protocole gnre une nouvelle requte de route afin de rparer toutes les routes qui passent par ce lien. Sil y a .N routes actives, il y aurait alors
.N.L liens actifs. Quand un lien est perdu, soit la source, soit le nud qui dtecte cette perte,
initie une demande de dcouverte de route pour chacune des destinations atteintes via ce lien. Dans le cas ou ce n'est pas la source qui agit, un gain est rajout au paramtre or , ce qui porte la surcharge totale de
. .
.
.
. . .
4.9
Paquets, correspondant un dbit consomm de: . . . . 4.10
81
4.5.2.
Cas de protocole proactif
Les protocoles proactifs (prsents dans 2.3.1.1) utilisent principalement une mission rgulire de messages de contrle ; ils ne gnrent donc aucune surcharge lors de la cration de route. Les paramtres qui interviennent dans ce type de protocoles sont : la frquence hp dmission des messages hello pour dcouvrir pralablement la topologie locale. Ces mobiles diffusent aussi, avec une frquence tp, un autre type de paquets pour avoir une connaissance globale de la topologie (au del du leurs voisinages). Ils dfinissent aussi Anp, le prochain saut actif (the active next hop); qui correspond au nombre moyen de liens actifs par nud, utilis pour connatre quel type de changement de topologie peut enclencher un contrle de trafic additionnel. Sachant que les protocoles proactifs peuvent profiter de leur connaissance de la topologie pour optimiser la diffusion, un facteur d'optimisation op= Bp/N est alors dfini, Bp tant le nombre d'missions ncessaires pour faire une diffusion topologique (Topology Broadcast). Un protocole proactif produit hp.N messages hello en une seconde pour tout le rseau. Et tp.N messages de contrle de topologie par seconde, produisant op.tp.N paquets. La surcharge dans un rseau ad hoc fixe est alors: . L'utilisation de la bande passante est de . . . . . 4.12 . . 4.11
O TP est la taille d'un paquet de contrle de topologie. Pour valuer la surcharge supplmentaire gnre en raction la mobilit des nuds, celle-ci est similaire au cas du routage ractif. Le nud qui dtecte la rupture de lien met un paquet de contrle de topologie supplmentaire. En moyenne, un nud peut faire partie de N routes actives, et diffrentes routes peuvent avoir un lien sortant commun. Cependant, la probabilit que le prochain saut pour ces routes soit le mme est, certainement, plus grande que la probabilit quils aient la mme destination. Avec l'introduction du nombre moyen de liens actifs ANp par nud, la surcharge totale dans le cas mobile est gale :
. .
.
. .
. .
4.13 4.14
La bande passante consomme est elle de:
82
Dans notre modlisation du streaming p2p sur MANET, nous nous intressons au cas mobile. Donc, nous reflterons la surcharge provoque dans chaque nud sur la distribution du dlai et cela en dduisant du dbit offert par chaque nud la valeur de la bande passante consomme par les messages de contrle. Dans ce qui suit, nous expliquons comment prendre en compte cette surcharge et la transformer en dlai supplmentaire pour l'intgrer enfin dans le modle MADP2PStream. Les distributions de probabilits de degr et de dlai sur les nuds en raction la mobilit sont fortement influences par la dynamique causes par le mouvement des nuds. Pour tudier cette mobilit dans le modle du streaming p2p, nous prenons en compte deux aspects: l'interaction sociale des utilisateurs reprsente par la matrice d'affinit et la perte des liens sans fils reprsente soit par les nouvelles routes gnres par le protocole de routage. Cette tude est ralise dans la section suivante.
4.6. Reprsentation de la mobilit dans le graphe de streaming p2p

Lobjectif de cette partie est dfinir un nouveau modle qui intgre toutes les contributions prsentes prcdemment et qui permettre de modliser le streaming p2p dans un rseau MANET. Lapproche consiste tendre le modle du streaming p2p de Carra et al., pour prendre en compte la mobilit des nuds dans un rseau MANET. Pour cela, on utilise le modle de mobilit introduit par Musolesi et al. Augment des proposition de Vinnot et al., pour prendre en compte loverhead des protocoles de routage. En effet, la mobilit dans MANETs peut tre vue comme une srie de ruptures et de crations de liens. En dautres termes, un nud qui se dplace perd les liens avec ses voisins de dpart et cre dautres connexions dans la zone darrive. Cest de cette faon que nous reprsentons, dans MADP2PStream, le modle de mobilit de la communaut social sur la base de la matrice daffinit Aff. Maintenant, nous allons extraire de modle de mobilit, les paramtres qui nous intressent et les traduire dans le modle de streaming p2p afin de prendre en compte le mouvement des nuds. Si nous reprenons le graphe du modle de streaming p2p et ses deux quations principales (4.3) et (4.4) auxquelles nous rajoutons la notion daffinit entre les nuds dans le temps, cela nous donne deux nouvelles formules reprsentant la distribution totale du degr , , .
,
(4.15)
ps(k,t)
La probabilit pour un nud s davoir k connexions actives et donc k voisins
83
Affs,v N(t)
Laffinit entre un nud s et ses v voisins Nombre de nuds dans le rseau linstant t
La mme approche est utilise pour le dlai, ce qui nous donne
, .
(4.16)
ps(l,t) La probabilit pour un nud s de recevoir le flux avec un dlai l Affs,prnt Laffinit deux deux des nuds constituant le chemin entre un nud s et le parent prnt qui fourni une bande strp N(t) Nombre de nuds dans le rseau linstant t
Dun autre cot, et concernant le routage, lorsque la rupture d'un lien est dtecte, le protocole de routage MANET, quil soit ractif ou proactif, va gnrer un nouvel itinraire afin de rparer le lien bris. Cette opration de maintenance consomme une partie de la bande passante des nuds mobiles, cause des messages de maintien de la topologie (Cf. 4.5). Ceci nous donne des dlais plus importants pour l'acheminement des paquets vido. , , .
,
. 1
4.17
Pour un routage ractif ayant comme paramtres :
or
L RQr bui
le taux de mobilit facteur d'optimisation de la requte de route densit de trafic Longueur moyenne dune route taille d'un paquet de requte de route dbit montant par nud
et la formule suivante pour un routage proactif , Avec :

, .
,
. 1
(4.18)
op
le taux de mobilit facteur d'optimisation de la requte de route
84
ANp Tp bui
nombre moyen de liens actifs taille de message de contrle de topologie dbit montant par nud
4.7. Evaluations
4.7.1. Groover: solveur d'quations diffrentielles
Le solveur de processus de graphe stochastique (GROOVER) est un outil d'intgration bas sur la mthode de Monte Carlo. Il explore l'espace d'tat d'une chane de Markov dont les tats sont reprsents par des graphes: chaque graphe contient les nuds qui ont t atteints par le contenu ainsi que les liens utiliss pour sa diffusion. Il a t dvelopp l'Universit de Trento et son objectif est d'analyser les systmes de distribution de contenu. Ce solveur supporte les deux topologies mesh et arbre. Nous avons repris le code de Groover, dans lequel nous avons intgr l'volution dynamique de la connectivit reprsente par la matrice du modle de mobilit de Musolesi et la contrainte sur l'overhead calcule par la formule de Vinnot. Le systme prend en compte dune part la taille du paquet de maintenance du protocole de routage MANET et dautre part les dbits offerts par chaque nud pour dduire les dlais dacheminement. Lalgorithme suivant reprend lessentiel de cette adaptation :
Algorithme 5: modification de lalgorithme principal de Groover
for each Time_Sim do ApplyCommunity(Adj,Aff) for each Adjij do ComputeDelay(Adjij,Overhead) ComputeDegree(Adjij) ComputeQuality(Adjij) end for end for
4.7.2.
Application du modle MADP2PStream
Dans cette exprimentation, nous utilisons une configuration de N = 100 nuds. La distribution de la bande passante en entre est compose de trois catgories: des nuds lents, des moyens et des rapides avec un dbit symtrique respectivement gal rstr, 2rstr et 5rstr avec des probabilits gales 0.2, 0.4 et 0.4. Le taux de flux est divis en R' bandes et la source en gnre R. Les rsultats sont obtenus pour R = 4 et R '= 3.
85
Le temps de l'observation du temps, gale Tstr. Nous considrons un schma d'arrive des nuds, avec un nombre initial gal 0.5N, respectivement, les autres nuds arrivent dans les 0.2 Tstr. La moyenne des temps de sjour est fixe 2 Tstr. Chaque nud peut avoir jusqu' 30 voisins dans le graphe. Ce nombre reste variable selon la dynamique des nuds. Les flux vido est dcompos en plusieurs morceaux, de lordre de quelques paquets vido, et nous fixons la taille du bloc Sb, de telle sorte que Sb/rstr = 1 unit (c'est--dire un bloc par unit temporelle). Un nud devient ligible pour le tlchargement du contenu, aprs un dlai gal la dure du tlchargement d'un seul morceau. Ainsi, le retard peut tre considr comme le retard relatif partir du nud source. Tstr est alors fix une longueur de 1000 Sb/rstr= 1000 units. Mis part les proprits degr et dlai, nous considrons galement la qualit du rseau. Au dpart dun parent, le nud orphelin active l'un de ses parents en veille. Si ce pre possde suffisamment de bande passante pour laider, il ne verra aucune interruption de service. Si aucun parent n'est en mesure d'aider, le nud en question recherche un nouveau parent, avec une ventuelle interruption de service. Suivant ces rgles nous mesurons alors la qualit de lexprience par nud, c'est--dire le pourcentage de nuds qui ont russi trouver un parent de secours.
nombre ditrations nombre maximum de voisins nombre min. de fils nombre max. de fils nombre de bandes nombre de bandes ncessaires nombre de nuds nombre de nuds actif au dpart priode darrive massive dure sjour moyenne dure d'une vido taux de mobilit 400 30 1 15 4 3 1000 500 0.2 5000 1000 0.5
Tableau 4 autres paramtres du modle
4.7.3.
Analyse du degr
En analysant lvolution du degr de connectivit, nous vrifions si la subdivision en bandes amliore le processus de distribution ou pas. D'une part, un nombre plus important plus de bandes implique un taux par bande plus faible et donc la perte d'une seule bande doit avoir un impact faible sur la qualit dexprience du nud. D'autre part, chaque nud doit maintenir plus de connexions actives ce qui augmente la probabilit que l'un de ces liens se rompe.
86
Figure 22: Distribution des degrs entrant et sortant.
Nous allons analyser la moyenne temporelle du degr en regardant les rsultats de l'quation de taux (Figure 22 (b)) obtenus par lquation (4.3). Une valeur stable est atteinte au bout de quelques units de temps: cela signifie que la structure, mme en prsence de mobilit est en mesure de maintenir un niveau lev de qualit du streaming La Figure 22 indique la distribution du degr entrant l'instant t=Tstr, calcule avec l'quation. (4.3). Dans ce cas, nous avons le nombre initial de nuds gal 0.1N et le temps moyen de sjour Tstr. Quand R' tend vers R, la distribution atteint son maximum, cela signifie que tous les nuds du rseau sont en mesure de recevoir la totalit des bandes, car le degr reste toujours suprieur ou gal R'. Avec R'= 4, chaque nuds va avoir exactement 4 parents: cela signifie que, dans le cas o un pre disparat, la qualit perue par le nud, peut tre temporairement affecte.
4.7.4.
Analyse du dlai
Le dlai, exprim en units de temps, reprsente le nombre de sauts sparant un mobile de la source du stream. Grace aux Complementary Cumulative Distribution Function (CCDF, dfinie comme le complment 1 de la Fonction Cumulative de Rpartition) afin d'tudier la traine de cette distribution, nous considrons R'= 4.
87
(a) Distribution des probabilits
(b) CDF du delai t=Tstr
(c) CDDF t=Tstr Figure 23: Evaluations du dlai (cas fixe).
88
Chapitre 4 MADP2PStream Modle de streaming peer to peer sur rseaux ad hoc mobiles MADP2PStream:
La Figure 23 prsente les distributions des dlais dans le cas fixe, nous observant un dlai de le diffusion moyen de 100 avec une probabilit de 90%. Ce dlai avoisin les 200 avec une probabilit avoisine Les figures ci-dessous, illustrent l'impact de la mobilit sur le dlai (formule 4.16) Celle-ci a un 4.16). effet secondaire: tant donn que chaque nud a besoin de tous ses liens actif afin de lire actifs correctement le flux, lintroduction de la mobilit donne des valeurs plus leves de la probabilit des dlais, puisque ce maximum dpend troitement de la dynamique du rseau rseau.
(a) Distribution des probabilits
(b) CDF du dlai t=Tstr
89
(c) CDDF t=Tstr Figure 24: Evaluations du dlai (cas mobile sans considration de loverhead).
Avec la considration de loverhead, selon les formules 4.17 et 4.18 nous recalculons la nouvelle distribution des probabilits de dlai. Nous remarquons (dans la Figure 25) que la distribution moyenne du dlai augmente compar au rsultat de la figure 24.
(a) cas proactif
90
(b) cas ractif
Figure 25: Distribution du dlai (cas mobile avec considration de loverhead)
4.7.5.
Analyse de la qualit
Ltude de lvolution du degr et du dlai nest pas en mesure de capter tous les aspects lis la qualit des flux reus par un nud mobile i. Dans le Tableau 5 nous rcapitulons des rsultats complmentaires obtenus partir de la solution de lEM. La valeur de la dynamique est calcule selon la frquence des arrives:
Tableau 5. Statistiques sur les nuds
paramtre nombre moyen darrives nombre moyen de dpart nombre moyen d'erreur pourcent. moyen de dpart pourcent. moyen d'erreur nombre moyen de nuds actifs arrives rates moyenne d'orphelin pourcent. moyen recouv. rapide pourcent. moyen recouv. Aprs recherche pourcent. moyen erreur Cas fixe 1173.481000 1824.136000 28.700000 15.5452 0.2446 910.345000 0.000000 370.366000 88.2595 11.6802 0.0603 Cas mobile 1136.915000 550.127500 431.305000 48.4256 37.9739 586.787500 0.000000 646.840000 00.0525 58.7468 41.2007
Sur toute la dure de vie du nud, il y a une probabilit non nulle que l'ensemble des parents dun nud i le quittent sans quil soit en mesure den trouver d'autres. Cette situation provoque une erreur dans le nud i et laisse le systme dans un tat instable. La probabilit d'avoir tout instant t, p (0, t) un degr sortant nul, en intgrant sur le temps t, nous pouvons
91
calculer la probabilit qu'un nud quitte avec un message d'erreur. Ce rsultat est indiqu dans la ligne pourcentage derreur du tableau 5 pour diffrentes cas de figure.
4.8. Discussion et conclusions

Dans ce chapitre, nous avons propos MadP2PStrem : un modle analytique, qui se veut le plus exhaustif possible, pour reprsenter et donc mieux apprhender le streaming peer to peer dans les rseaux ad hoc mobiles. Cette tude consist regrouper les diffrents aspects intervenant dans cette modlisation, savoir en premier, le modle du streaming peer to peer pour rseau fixe que nous avons tendu par un modle de mobilit bas sur les interaction sociales des nuds et enfin la prise en compte du dbit consomm par les messages de contrle des protocoles de routage MANET dans deux case le proactif et le ractif appliqus dans un scnario ddi la mobilit pitonne dans le but de partager des expriences vido en communaut. Quant il s'agit dune mobilit restreinte dans un espace de simulation limit et dense en matire de nuds, les protocoles de routage les plus adquats restent les proactifs. Toutefois, dans des cas plus clairsem, la solution ractive reste la plus approprie. Les rsultats de l'tude de ces modles nous incite aller plus loin, pour proposer une preuve de concept, par la simulation et le prototypage. Ceci fait lobjet du chapitre suivant. Il reste nanmoins plusieurs amliorations faire en ce qui concerne MADP2PStream, car dans un scnario de mobilit importante, les dlais de rception de la vido deviennent trs importants car loverhead consomme plus de dbits sortant des parents. Mais dans un cas de mobilit pitonne nous pensons que cette proposition est facilement implmentable.
Chapitre 5. : MadTorStream - un protocole pour le
streaming p2p mobile
5.1. Introduction
La production de contenu vido engendre, de nos jours, un grand volume de trafic sur Internet. Les rseaux sociaux et professionnels mergeant (ex. Facbook, LinkedIn...) et les portails vido agissent comme un vritable acclrateur de ce phnomne. En plus des applications IPTV et de la vido la demande VoD, le partage de vidos personnelles est galement dans la course. Aprs le partage de fichiers et la tlphonie sur IP, les applications de streaming peer-to-peer suscite un grand intrt, autant chez les acadmiques que chez les industriels. L'objectif principal de cette technologie est de faire cooprer des nuds en vue de rpartir la charge entre eux leur permettant ainsi, d'envoyer et de recevoir des parties du contenu partag. Un grand nombre d'applications de streaming peer-to-peer sont actuellement utilises sur Internet, tant pour la vido la demande et en temps rel tels que des services IPTV. On peut citer Joost, Pplive, SopCast, UUSee. Les utilisateurs sont aussi fascins par les nouvelles technologies de tlcommunication. En particulier, les quipements nomades, devenues indispensable dans leur quotidien. Un ensemble d'interfaces de communication (WiFi, BlueTooth, GPS...) est dsormais intgr dans des appareils mobiles comme les tlphones, PDA, lecteurs multimdia. Le rseau ad hoc mobile (MANET) est une application de ces technologies sans fil qui ne ncessitent pas d'infrastructure. Partant du fait que les applications multimdia sont de plus en plus prsentes dans la vie nomade, nous pouvons facilement imaginer un scnario o les utilisateurs mobiles construisent leur propre rseau, spontanment, sans recourir l'infrastructure, dans le but d'changer des vidos entre eux. Juste en s'appuyant sur les interfaces sans-fil incorpores dans leurs mobiles. Comme ces appareils sont limites en termes de mmoire, ils ne peuvent pas stocker l'ensemble des flux vido, et seraient, sans doute, amens ne garder qu'une partie de celui-ci. Autrement, les performances de leurs mmoires diminuent.
93
94
Chapitre 5 : MadTorStream - un protocole pour le streaming p2p mobile
Considr comme trop semblable aux topologies peer-to-peer, par un comportement similaire: les arrives et dparts de nuds, les rseaux ad hoc mobiles sont construits dans la plupart du temps par des appareils nomades avec un protocole spcifique (proactif, ractif ou hybride) pour router les donnes entre eux. Indpendamment du protocole de routage, les nuds mobiles ont besoin d'une certaine quantit de mmoire de traitement comme un buffer pour faire face aux problmes de rupture du flux vido en raison de leur motion.
5.1.1.
Persistance et rplication pour palier la mobilit
Le dveloppement du trafic peer to peer sur Internet commenc par l'change de fichiers musicaux. Le streaming vido prend lui aussi un part plus importante. La mobilit est aussi de plus en plus prsente dans le quotidien des utilisateurs souciant de partager des contenus souvent issu de leurs crations (photo et vido prise spontanment. Le peer to peer reprsente une solution pertinente au problme du cot du dploiement de serveur ddi, offrant une rpartition de la charge sur les nuds participant dans ce partage en utilisant leurs ressources respectives. Quand on porte le streaming peer to peer sur les rseaux ad hoc mobiles, nous devons faire face quelques problmes relatifs la puissance de calcul limite (i.e dcodage), la limite de la mmoire ainsi que la capacit de stockage. Dans ce chapitre nous allons proposer une technique de clustering pour les MANETs permettant le streaming peer to peer. Cette proposition vise allger de la discontinuit (disruption) caus au churn additionnel engendr par la mobilit des nuds.
5.1.2.
Mobilit augmente la diversit
Dans notre proposition, compare BitTorrent, il existe une diversit des blocs entre les localits (voisinages) visites par le nud mobile. En dautres termes, les blocs disponibles un moment sont diffrents d'un nud l'autre dans lesquels ce nud sjourne. Nous nous appuyons sur cette hypothse pour modifier le protocole BitTorrent (surtout sa stratgie de slection de bloc voir paragraphe prcdent)
5.2. Travail effectu

Notre objectif, dans le prsent travail, est de proposer MadTorStream : une combinaison de p2p streaming, base sur BitTorrent avec MANETs. Afin de permettre le partage de vidos dans une communaut mobile. Nous prenons en compte les contraintes lies aux canaux sans fil, les protocoles de routage sous-jacent ainsi que la mobilit protocoles rseau. Ce travail est propos dans le cadre du projet europen ITEA ExpeShare. Un projet collaboratif europen de recherche dans lequel participe note laboratoire. En effet ExpeShare vise raliser un
95
partage dexpriences sur les communauts mobiles via des technologies de partage de contenu adapt sur des rseaux sans fils, avec ou sans infrastructure. Dans notre tude nous traiterions du cas sans infrastructure. Le reste de ce chapitre est organis comme suit: dans la section suivante 5.2.1, nous positionnons
notre approche par rapport d'autres tentatives. La section 5.3.2 prsente les points d'action pour permettre le mobile p2p streaming. Dans la section 5.3, nous donnons une vue d'ensemble de MadTorStream. L'valuation de la performance vient en section 5.4. Et enfin, la section 5.6 conclut la contribution.
5.2.1.
Travaux relatifs
Le streaming peer-to-peer et les MANETs sont des domaines de recherche bien tudis. A notre connaissance, aucune tude ne propose des mcanismes de streaming p2p pour les rseaux mobiles ad hoc. De nombreuses applications p2p ont t proposes pour MANETs, telles le partage de fichiers [129]-[135], la recherche et l'indexation de contenu[133][134], la tlphonie p2p [135]. Rcemment, une proposition de partage de fichiers pour MANETs, base sur BitTorrent, a t prsente dans [129], tandis que les tudes [130]-[132] n'ont pas dpass l'tape de recherche de contenu. Les applications peer-to-peer de streaming vido sur Internet ont connu une croissance exponentielle au cours des deux dernires annes. Les utilisateurs partagent, et mme produisent, de plus en plus de contenu sur le Web l'aide de plates-formes novatrices comme Joost, l'un des nombreux clients p2p streaming sur Internet. Aprs recherche, le partage de fichiers et la VoIP de recherche se concentre dsormais sur les applications de vido streaming peer-to-peer qui sont de plus en plus tudi, des tudes de mesure comme [112][116][136] tentent d'apprcier, le plus profondment possible, les diffrentes caractristiques de ces systmes. Plusieurs modles analytiques sont proposs pour capturer les paramtres essentiels des applications de distribution de contenu vido sur Internet. Parmi ces travaux, une srie de proposition d'adaptation de BitTorrent pour le streaming a t donne dans [138][139]. Dans lesquelles les auteurs ont propos de changer la stratgie de slection de blocs. Ces mmes tudes montrent quun voisinage de 15-20 pairs est suffisant, pour atteindre un streaming de qualit. Il ya une dualit entre diffrence la capacit du nud source, ncessaire pour garantir un certain dbit un nombre d'utilisateurs, et le nombre de pices disponibles au partage. .
96
5.2.2.
Manet modles de routage et de la mobilit
Depuis l'apparition du MANETs o de nombreux modles de mobilit proposes par la communaut. Entre autres, Le Boudec et al. ont propos le Random Walk [41] ils ont aussi montr sa performance, comme voqu dans le paragraphe 4.2 notre intrt est plus dans un modle de mobilit sociale qui est plus reprsentatif de notre scnario de communaut mobile. Aprs une longue recherche dans la littrature concernant les modles de mobilit MANETs, en comparant les avantages et les inconvnients de chacun. Dans ce travail nous utilisons le modle de mobilit fonde sur le rseau social de la thorie, propose par Musolesi et al. dans [121]. En utilisant des proprits de rseaux sociaux, ce modle se base sur l'observation suivante: dans un MANET, le mouvement du dispositif portable est bas sur les dcisions de l'utilisateur et son comportement social. Pour considrer ce type de comportement, le modle prend en compte le rseau social qui relie ces personnes. En d'autres termes, les mouvements des groupes ainsi que des nuds sont rgis par leurs relations sociales. Le fonctionnement de ce model est dtaill dans la section 4.4. Ce modle de mobilit permet des collections d'htes de se regrouper selon les relations sociales entre leurs possesseurs. Ce regroupement est ensuite reflt sur un espace topographique, avec des mouvements influencs par la force des liens sociaux, et pouvant aussi changer dans le temps. Cela correspond bien notre scnario tudi, li la communication de groupe dans une zone d'exposition, o des utilisateurs partagent leur exprience en utilisant le streaming peer-to-peer. Ce travail est propos dans le cadre du projet europen ITEA ExpeShare.
5.2.3.
Mobile peer-to-peer streaming
De la littrature il y a peu de travaux qui traitent le streaming sur MANETs, et encore moins, le streaming peer-to-peer dans ces rseaux sans infrastructure. Dans cette tude, nous avons pour but d'aller d'un pas en avant pour comprendre cette problmatique, une poque, o la vie nomade, combine aux rseaux sociaux et aux applications multimdia sont la page.
5.2.4.
Difference entre file sharing et streaming p2p
Le dfi du streaming P2P est de fournir un dbit soutenu tous les participants du rseau. Alors que dans le partage de fichiers P2P le contenu peut tre distribu en best effort, dans le streaming vido, une bande passante insuffisante conduit une mauvaise qualit de service, telles que le dcrochage ou le gel, ce qui est trs ennuyeux pour les utilisateurs mobiles.
97
Contrairement aux protocoles de partage de fichiers, et dans un souci de supporter une diffusion base sur les topologies mailles (Mesh Based), le nud cible lit la vido avec un certain dcalage compar la source. Les pices de la vido sont reues et reconstruites dans un buffer d'affichage (display buffer). Chacun des nuds maintient une fentre glissante qui reflte ce buffer en notifiant, ses voisins, chaque pice dj reue et marquant celle qui lui manque. Cette fentre se dfile avec la vitesse de lecture de la vido (BitRate). Le dbut du buffer pointe sur le bloc actuellement en lecture. Les blocs manquant leur date d'affichage sont ignors ce qui cause une dgradation dans la qualit perue de la vido. Toutes les tudes cites auparavant se sont concentres sur la file sharing utilisant la prsence des blocs en tant que mtrique principale pour mesurer la performance. Cependant, quand il s'agit de diffusion vido, l'tude de ce paramtre devient alors insuffisante, car les blocs doivent, en plus, tre prsents temps. Autrement, l'utilisateur percevra des mfais sur la qualit de la vido (discontinuit, perte de qualit, problmes...).
5.3. Vue d'ensemble de MadTorStream

Dans ce paragraphe, nous prsentons les diffrentes composantes de l'architecture propose. Nous commenons par le rseau sous-jacent dans une approche bottom-up jusqu' la couche application. La cintique du systme propos se dcrit comme suit: Imaginons le cas d'une confrence en se droulant dans un espace donn. O des participants, de diffrents organisations et centres d'intrt, vont se retrouver pour une certaine priode. Ces utilisateurs sont quips de tlphones mobiles avec WiFi intgr. Quand un participant entre dans la zone d'exposition, il rejoint la communaut (un rseau ad hoc spontan cr cet effet). Il aura un profil, une prsence ainsi qu'une liste d'objets (vido ou autre) qu'il veut mettre en partage avec d'autres participants. Notre intrt est de raliser l'change de vido, essentiellement l'adaptation d'un algorithme classique de partage de fichiers (qui est la stratgie rarest first de BitTorrent). Ceci consiste choisir non pas le bloc le plus rare mais celui avec lestampille d'affichage la plus imminente. La phase de recherche du contenu vido ne sera pas traite dans cette thse. Celle-ci, peut se faire grce des mcanismes distribus (tel que des DHT ou des Trackers Distribus). Nous supposons donc, que la vido est dj localise, nous nous concentrons seulement sur les aspects streaming. Le nud demandeur obtient une liste de voisins partageant le mme flux vido. Parmi lesquels, un systme de slection de pairs permettra d'lire les pairs (demandant des blocs de la vido) qui il va donner des bouts de cette vido. Nous gardons la mme stratgie de slection de pairs que celle employe par le protocole BitTorrent [12] et modifie dans BitHoc, plus de dtail quant cet algorithme sont disponibles dans [129].
98
Notre principale modification, apporte au protocole BitHoc, porte sur la politique de slection de BitHoc, blocs. Nous avons pris en compte les recommandations donne dans [138] et [139] pour changer donnes l'ordre dans lequel les morceaux de la vido sont choisis en utilisant la politique du Closest Deadline First. La mobilit des pairs est rgie par le modle de mobilit. Les paramtres comme la vitesse, temps de pause sont donns dans la section suivante suivante.
Figure 26 Vue d'ensemble de MadTorStream. 26:
Figure 27 Vue en couches de MadTorStream. 27:
5.3.1.
Manet modles de routage et de la mobilit
Le protocole de routage sera le mme utilis dans BitHoc savoir DSDV [140] (Dynamic BitHoc, Destination-Sequenced Distance-Vector Routing) est utilis dans ce cas, nous avons rajout une Vector extension par rapport la mobilit du nud. Nous sommes passs du cas fixe au mo mobile, sur la base du modle de mobilit dfinie dans les paragraphes suivants.
99
Selon DSDV, chaque nud mobile maintient une table de routage, qui est exploite par le BitHoc tracker BitTorrent. Les voisins sont grs en fonction de leur proximit du pair (en nombre de sauts).
5.3.2.
Au niveau peer-to-peer (couche de partage vido)
Sur la couche p2p, une adaptation du protocole de partage de fichiers sur MANETs, BitHoc, tenant compte des changements proposs.
Figure 28: La stratgie Closest Deadline First.
A ses voisins, un nud mobile va demander les morceaux de vido avec la date la plus proche (pice n 10 dans le cas de la Figure 28 ). Comme dans BitTorrent [12], chaque pair mobile satisfait les demandes de ses voisins dans l'ordre de mrite (il donne un bloc au voisin qui m'a fourni avec le meilleur upload dans le pass).
5.3.3.
Application du Modle de mobilit
Comme nous l'avions vu dans la section 4.4, le community based mobility modle consiste appliquer une matrice d'affinit sociale sur la base des relations entre les participants d'un meeting. Dans de tels vnements des personnes se dplacent gnralement en groupes. Ces groupes sont forms selon les affinits sociales reprsentes dans une matrice d'affinit compose par les probabilits que deux utilisateurs mobiles se parlent les uns aux autres quand ils sont l'un dans la porte de l'autre. Et lorsque cette probabilit suprieure un seuil donn. Suivant ce modle, nous avons gnr les traces correspondant notre scnario de meeting. Dans ce qui suit, nous dtaillons les paramtres considrs dans nos simulations.
100
5.4. Simulations
Les simulations ont t menes en utilisant NS-215 (Network-Simulator2), avec une adaptation du protocole streaming p2p bas sur BitHoc pour NS-2 propose dans [129]. Nous avons modifi la stratgie de slection des pices pour supporter le streaming. Nous lanons cette simulation avec les paramtres rsums dans le tableau II. Dans ce scnario, nous ne considrons pas les dparts et les arrives, seule la mobilit nous intresse. La dynamique cause par les dpart/arrive sera aborde l'avenir. Afin de considrer la mobilit des nuds, nous avons gnr un les traces du mouvement des pairs mobiles en utilisant l'outil propos dans [55]. Il s'agit d'un gnrateur de mobilit crit en C++ et disponible en ligne16. Cette trace est ensuite injecte dans le simulateur MadTorStream, changeant le comportement des nuds de fixe mobile avec un certain nombre de paramtres (voir Tableau 6). Paramtre S MANET MAC area node_range data_rate max_num P2P piece_num piece_size upload_history Dfinition Vitesse Modle de la couche MAC Surface de simulation Porte du nud transmission Dbit du nud up/dl Nombre de nuds mobiles Nombre de blocs Taille dun bloc Valeur 0 - 2 m/s 802.11b 600x600 m 70 m 1Mbps/1Mbps 30 100 100 kb 15-20
num_neighbors Nombre voisins par nud

Tableau 6 Paramtres de simulation
Priode de slection des voisins 60
5.5. Discussion des rsultats

Afin d'apprcier l'efficacit du systme propos ci-dessus, nous mesurons le taux de succs de la lecture. La distribution dans le temps de la prsence des blocs sur les nuds pour voir l'effet de la modification de la stratgie de slection des pices (Closest Deadline First) pour le streaming sur la qualit du perues par le nud.
NS: The Network Simulator, http://www.isi.edu/nsnam/ns/. M. Musolesi and C. Mascolo. A Social Network Founded Mobility Models for Ad Hoc Network Research, http://www.cs.ucl.ac.uk/research/mobile/mobilitymodels/
15 16
101
(a)distribution temporelle des blocs sur les nuds
(b)Taux de succs de lecture par nud
Figure 29: Rsultats avec Closest Deadline First.
(a)distribution temporelle des blocs sur les nuds
(b)Taux de succs de lecture par nud
Figure 30: Rsultats avec Rarest First.
Les rsultats de cette distribution sont reprsents dans les Figure 29 pour la politique Closest Deadline First et Figure 30 pour l'originale de BitTorrent, Rarest First. Nous observons que le temps entre le premier et le dernier morceau est lgrement rduit avec notre stratgie. Cependant, nous observons une squentialit dans les deux stratgies Rarest First et Closest Deadline First. Cela est d au fait que tous les pairs sont arrivs en mme temps et ont demand les mmes blocs dans le mme ordre, ce qui est problmatique par rapport au rarest first.
102
Le principal intrt de faire cette tude est de voir si le streaming est de qualit acceptable pour chacun des pairs. Pour ce faire, nous utilisons une mesure dj introduite par WF Poon et al. dans [140]: la probabilit de succs de la lecture, qui est dfinie comme la proportion des blocs demands, que le nud a russi afficher, de l'ensemble de la vido. Dans les Figure 29 (b) et Figure 30 (b), nous montrons la distribution, par nud, du taux de succs de la lecture. Ce gain est trs prometteur pour les nuds mobiles qui se dplacent une vitesse entre 0 et 2 m/s. Cela correspond bien notre scnario de mobilit pitonne.
5.6. Conclusions
Cette partie de notre contribution, s'est axe sur la question du streaming sur MANETs en utilisant une adaptation de BitHoc, un BitTorrent pour Ad Hoc, que nous avons value dans des simulations NS-2, tenant compte des contraintes lies aux canaux sans fil, les protocoles de routage MANET sachant que l'application streaming p2p est totalement indpendante du rseau sous-jacent. Nous avons la conviction que la proposition d'un tel systme de streaming vido sur MANETs est un domaine de recherche important explorer. Nous avons prsent une architecture de p2p streaming ad hoc pour les communauts mobiles. Sur la base d'un modle de mobilit sociale, nous avons montr que, par rapport au partage de fichiers, l'amlioration qui doit tre apporte lors de la conception d'applications de streaming sur MANETs, la BitTorrent, est presque la mme que dans les scnarios fixes: La stratgie de slection de blocs vido doit tenir compte de leurs dates limites de prsentation, sans quoi, la performance du systme s'croule. Nous avons mis en vidence, dans cette tude, l'importance de la squentialit dans le renforcement de la diversit des blocs prsents dans la fentre glissante, offrant ainsi, plus de persistance pour un streaming de qualit. Les rsultats de cette tude montrent la faisabilit du streaming mobile base sur BitTorrent utilisant un protocole de routage proactif. Suivant un modle de mobilit fond sur le comportement d'une communaut sociale, nous avons pu prouver par simulation que le streaming p2p peut tre envisag sur les MANETs. Les investigations restent ouvertes quant au choix du protocole de routage et des modles de mobilit suivant le scnario dans lequel de telle architecture seront dploy. Pour cela une prochaine tape consiste compar deux scnarios de mobilit Le premier, en mobilit rduite avec un protocole proactif OLSR, le second en haute mobilit avec le protocole ractif AODV. Pour voir la concordance des rsultats avec ceux obtenu dans la modlisation avec MADP2PStream.
Chapitre 6. Conclusions et perspectives
Nous pensons que la combinaison du partage de vido et des communauts sociales mobile qui semble embrasser un formidable dveloppement dcollera bientt. Offrant ainsi, aux utilisateurs nomades, une large autonomie et une grande libert de partage de leurs contenus, sans pour autant avoir recourir l'infrastructure souvent trs coteuse (tels que gprs/3G). En effet cette libert devient possible grce des rseaux spontans forms par des appareils mobiles. Le principal objectif poursuivi vis dans cette contribution est dclairer les zones dombres couvrant des domaines, divers et complmentaires, impliqus dans laboutissement des futures applications multimdia mobiles. En effet, la proposition de nouveaux protocoles de streaming multimdia sur rseaux MANET est le fruit de la convergence de mcanismes sur les couches rseau et applicatif. Des compromis sont alors proposs pour tirer profit des avantages respectifs des deux niveaux, en palliant des problmes tels que la dynamique des nuds mobiles. Dans cette conclusion, sont rappeles les principales fonctionnalits des systmes de streaming en mobilit qui sont proposs dans ce travail de thse. Aussi y sont SM Stream, MADP2PStream et MadTorStream, synthtiss les apports de en rapport aux contraintes poses par la
mobilit, au streaming. Enfin, quelques perspectives pertinentes sont avances pour lamlioration de nos propositions, prsentes, elles expriment manifestement dans le domaine en gnral, des axes de recherche potentiels.
6.1. Synthse du travail ralis

Durant ces trois dernires annes, notre recherche a permis daborder toutes les notions relatives au streaming multimdia sur les rseaux sans fil. Nous avons alors tent de comprendre les diffrents aspects lis cette problmatique, notamment dans le cas de mobilit. Cest cette tape que nous nous sommes intresss aux processus et mcanismes de prdiction du handover dans le but de raliser un service de streaming sans coupure dans la mobilit. Nous avons pu relever que, dans la pratique, la majorit des contraintes que nous pensions avoir bien tudies, par des formules mathmatiques ou par des simulations, savrrent incompltes eu gard lhostilit des conditions relles dans lesquels nos mesures ont t effectues.
103
104
Chapitre 6 Conclusions et perspectives
Nous avons pu, par la suite tudier le streaming dans des rseaux ad hoc mobiles, lalliance de ces deux domaines existait dj, mais pour des applications moins exigeantes, en terme de ponctualit, que les streaming multimdia. Pour relever ce dfit, nous avons commenc par lanalyse de plusieurs modles relatifs aux diffrentes facettes de notre proposition. Une fois les choix faits, nous avons propos un modle en ramenant tous ces aspects la mme chelle : celle de la qualit du streaming mobile. Suite cela, nous avons propos une architecture
6.2. Rsum des contributions

6.2.1. Streaming sans coupure en mobilit sur WLAN SM Stream
Dans notre premire contribution, nous avons propos SM Stream un systme de mise en cache adaptative, guide par la prdiction du handover. Lors de la mobilit dun terminal, ce systme vise assurer un service de streaming vido sans coupures, seamless. Cette proposition permet de prdire le temps restant avant handover, grce un filtre mathmatique capable de prdire quel instant les valeurs de force du signal tombent en dessous dun certain seuil. Il ordonne alors au terminal de prvoir une dconnexion dans les secondes qui suivent. Cette prvision consiste tlcharger, en ouvrant des connexions multiples, la quantit de vido ncessaire pour couvrir la priode de dconnexion, lors du passage entre les deux cellules sans fil. Aprs avoir valid cette proposition par simulation, nous avons implment SM Stream dans un lecteur multimdia populaire. Cette ralisation a consist en la modification du schma classique de mise en cache de la vido, en ouvrant plusieurs connexions en parallle, avant le handover, et de faire les calculs ncessaires, via un module de prdiction bas sur le filtre Grey, pour ne pas avoir dinterruption de la vido au moment opportun, c'est--dire lors du handover entre les cellules sans fils. Cette tude nous a principalement permis de raliser quel point les bancs dessai rels restent le meilleur moyen dvaluation de ce type de propositions. Nanmoins, les rsultats obtenus se sont rvls trs satisfaisants.
6.2.2.
Modle de streaming p2p sur MANET MADP2PStream
Les protocoles peer to peer ont rvolutionn le partage de linformation sur internet. Ils fonctionnent sur des principes de rciprocit et de rcompense, incitant les nuds donner le meilleur de leurs ressources. Le streaming vido a adopt ce dissmination des paquets vido entre les utilisateurs. Les MANETs sont des rseaux spontans auto-organiss, dans lesquels des nuds mobiles communiquent via des liens sans fils, sans recourir au soutien de linfrastructure. Ces mobiles sont paradigme distribu pour la
105
caractriss par une porte limite et changent donc sur des chemins multi sauts, chacun assurant le rle de relai pour ses voisins. La mobilit est linconvnient majeur des ces rseaux. En effet, le mouvement des nuds gnre des pertes de liens menant une dgradation du service partag. Nous avons cherch proposer un modle mathmatique afin dtudier la raction des protocoles de streaming vido en P2P la mobilit des nuds dun rseau ad hoc mobile. MADP2PStream sinspire dun modle de rfrence pour le streaming P2P, dans lequel nous avons introduit deux notions primordiales des rseaux MANET : dune part la mobilit, reprsente par un modle synthtique mais assez raliste, bas sur les rseaux sociaux et dune autre part, un modle, reprsentant la surconsommation supplmentaire des dbits provoqus par cette nomadisme des nuds. Les rsultats exposs et comments dans le Chapitre 4 , sont trs prometteurs ; ce qui de fait a renforc notre conviction, quant la faisabilit des futures applications vido, sur les dispositifs nomades. Par le biais dun rseau spontan coopratif, bas sur des paradigmes de MANET et des principes de streaming P2P, les nuds mobiles changeront des contenus vido sans avoir recours linfrastructure.
6.2.3.
Streaming bittorrent sur MANET MadTorStream
Le dernier volet de cette thse, consacr la validation de simulation de MadTorStream , porte principalement sur une proposition adaptant un protocole de partage de fichiers sur MANET, la BitTorrent, pour le streaming vido. Nous avons repris des indications parues dans plusieurs travaux de recherche, relatives aux tapes de cette transformation de BitTorrent, pour la diffusion vido. Les rsultats ont t valids sur un des plus grands simulateurs de rseaux NS-2 avec un scnario ddi aux communauts mobiles et en appliquant un modle de mobilit bas sur les interactions sociales des utilisateurs. Nous avons galement pris en considration un protocole de routage proactif, avec un modle raliste de la couche physique, implment dans le simulateur. La simulation nous a essentiellement permis de comparer et de dcider de la stratgie de slection de bloc adopter afin den avoir le moins possible, qui ratent leur heure daffichage, tout en comptant bien sur la diversit suplmentaire apporte par le mouvement des nuds.
6.3. Perspectives
Lanalyse rtrospective montre clairement que, dans ce domaine du streaming multimdia en mobilit et sans infrastructure, de nombreuses difficults devront tre surmontes ; de ce fait, de multiple voies sont explorer tant sur le plan applicatif que sur le rseau. Dans ce qui suit nous donnons une liste, non exhaustive, de points qui restent lucider.
106
Dans le futur, nous proposerons des amliorations du modle MADP2PStream en introduisant des techniques de clustering sur le MANET ainsi que des mcanismes de rplication de paquets vido, visant rduire la consommation en bande passante des nuds. Actuellement, la mise en uvre dune application de streaming BitTorrent sur MANET, est en cours dans notre laboratoire, sur la base de larchitecture dfinie dans le Chapitre 5. Ce qui nous permettra d'approfondir ltude des contraintes lies aux proprits du canal physique ainsi que leur impact sur la qualit de l'exprience acquise par l'utilisateur.
6.3.1.
Adaptation de paquets vido pour handover
Dans un souci d'optimisation de l'excution de streaming durant les handovers, il serait intressant de voir comment pourrions-nous jouer sur la vitesse d'encodage de la vido pour rduire la taille des paquets afin d'en bufferiser plus, en moins de temps. (Ce qui permet de se passer de lusage des mcanismes dadaptation classique, qui changent le format dencodage, pour adapter le flux dans sa totalit, aux conditions du rseau actuel.) En dautres termes, au lieu dutiliser les mcanismes dadaptation classique qui changent le format dencodage pour adapter le flux, dans sa totalit, aux conditions du rseau actuel. Ce que nous prconisons dans lavenir, a serait, non pas, de faire une adaptation de toute la vido, mais de ltablir au fur et mesure que les conditions du rseau samliorent. Ce mcanisme ncessite des serveurs de streaming coopratifs, dans le cas o il serait ralis sur la couche application.
6.3.2.
Mcanisme de rplication pour streaming P2P sur MANET
Les mcanismes de rplication, surtout connus dans les rseaux peer to peer, peuvent apporter une amlioration majeure lorsqu'elles s'appliquent des rseaux mobiles ad hoc, en particulier pour les applications critiques comme la vido en streaming. Dans cette section, nous prsentons un nouveau systme de rplication de paquets vido pour viter leurs pertes, qui provoqueraient une mauvaise exprience de l'utilisateur. Nous donnons une preuve de concept sur la base d'un dbut de simulation de la solution propose. Nous parlons de rplication, parce que c'est un principe fondamental dans le partage de contenu p2p. Celle ci propose, par des mcanismes, de dupliquer avec des paramtres bien prcis, les morceaux de la vido, pour palier au risque de perte en cas de dpart de sa source initiale. Il existe deux types de rplication. La premire, instinctive, est faite par redondance classique, c'est dire que chaque nud offre plusieurs copies du mme bloc ses voisins selon un schma donn. Puis il y a une autre technique, plus labore, qui consiste rajouter des blocs de redondance l'information utile. Ces blocs de donnes permettent de reconstruire lenvoi initial en utilisant des algorithmes dj bien prouvs dans des applications client/serveur existantes.
107
Pour les rseaux ad hoc mobile, il existe une dualit dans le principe de rplication, car il y a un compromis faire, soit par une stratgie de redondance, qui va encombrer le canal radio, ou bien alourdir l'application mobile, en lui intgrant des codes correcteurs pour extraire l'information partir du jeux de blocs reus.
6.3.3.
Clustering bas sur la session de lecture

pouvant survenir cause de la dynamique
Nous proposons un schma de regroupement, sur la base de session vido pour le streaming p2p mobiles. Cette approche rduit les perturbations supplmentaire cause par les nuds en mouvement. Depuis l'mergence de rseaux pairs pair, de nombreux travaux ont t mens dans le domaine du clustering. En proposant des moyens de division du contrle distribu dans les rseaux fixes ou mobiles, la combinaison de cette philosophie avec la construction d'arbres multicast applicatifs est mme dallger la charge sur l'ensemble du MANET. Nous proposons, que chaque mobile maintienne un buffer pour obtenir une partie de la vido avant de la lire, Ce qui lui permettrait, non seulement de recueillir suffisamment de paquets vido pour quil ny ait pas de coupure, mais galement dutiliser moins de mmoire puisque seule une partie de la vido, et non plus la totalit est dsormais stocke dans le mobile.. Pour cela, nous construisons un cluster sur chacune des sous sessions de lecture, dans laquelle tous les nuds regardant la mme partie dune vido se regroupent pour former un arbre de multicast applicatif. Lorsquun nouveau nud mobile se connecte au rseau, il rejoint le cluster correspondant la premire sous-session. Et ainsi de suite jusqu la fin de la lecture. Ce principe a dj t appliqu dans des protocoles streaming p2p sur Internet tel que Joost, mais il na jamais t envisag pour les rseaux ad hoc mobiles ; alors quil prsente des avantages potentiels.
6.3.4.
Localisation P2P smantique de contenu vido (DHT, MPEG7 et Ontologies)
Lune des problmatiques qui nous ont toujours proccup, est lajout de la smantique dans la recherche du contenu vido. En combinant cela aux techniques peer to peer telle les DHT, nous sommes convaincus de pouvoir faire de la recherche distribue de scnes vido directement en utilisant des mots cls. Ceci vitera lutilisateur de devoir tlcharger toute la vido pour lire que la seule squence qui lintresse. Un schma dindexation bas sur les ontologies faciliterait certainement lenrichissement smantique des vidos. En se basant sur des propositions existantes dallier les ontologies au DHT, nous en ferons lapplication sur le peer to peer streaming, notamment avec lavnement des nouvelles technologies de compression vido, qui incluraient des mcanismes de marquage de limage. et axe nous semble porteur de perspectives ouvrant un vaste
108
champ ddi lapprofondissement de la recherche dans le domaine des technologies des communications virtuelles et notamment la contribution jeter les jalons des investigations dans la comprhension des systmes de communication mobiles de demain telle est notre recommandation la plus souhaitable en guise de conclusion de notre thse plutt ddie contributive cet exaltant domaine de la cyberntique. Cette thse prsente l'amlioration faisable sur les diffrents aspects du streaming mobile. Cette investigation nous avance dun pas en avant vers la comprhension des systmes de communication mobiles de demain.
Rfrences
[1]. [2].
The IEEE 802.11 Standards, see http://grouper.ieee.org/groups/802/11/ Ripeanu M Peer-to-peer architecture case study: Gnutella network. Internet2 workshop: collaborative computing in higher education: peer-to-peer and beyond. Tempe, Arizona, January 3031 2002
[3].
Maymounkov P, Mazires D, Kademlia: a peer-to-peer information system based on the XOR metric. In: 1st international workshop on peer-to-peer systems (IPTPS 2002). Cambridge, MA, Mar (2002)
[4].
[5].
B. Wiley. Distributed Hash Tables, Part I. Linux Journal- October 2003. S Saroiu, KP Gummadi, SD Gribble, Measuring and analyzing the characteristics of Napster and Gnutella hosts, - Multimedia Systems, 2003 - Springer
[6].
Ferguson D, Trends and statistics in peer-to-peer. Workshop on technical and legal aspects of peer-to-peer television. Amsterdam, Netherlands, Mar. 17, 2006
[7].
Llie D, Gnutella network traffic measurements and Characteristics. Licentiate Dissertation Series No. 2006:05, ISBN: 91-7295-084-6, April 2006
[8].
Ritter
J.
Why
Gnutella
cant
scale.
No,
really.
URL:
http://www.darkridge.com/~jpr5/doc/gnutella.html [9]. A. Wierzbicki, N. Leibowitz, M. Ripeanu and R. Wozniak. Cache Replacement Policies Revisited: The Case of P2P Traffic. 4th GP2P Workshop, Chicago, IL, April, 2004. [10]. Liang J, Kumar R, Xi Y, Ross KW, Pollution in P2P file sharing systems. Proc. of INFOCOM 2005. 24th Annual Joint Conference of the IEEE Computer and Communications Societies, 1317 March, Miami, FL 2005
109
110
Rfrences
[11].
Hofeld T, Leibnitz K, Pries R, Tutschku K, Tran-Gia P, Pawlikowski K (2004) Information diffusion in eDonkey file sharing networks. University of Wrzburg, Research Report No. 341, Sept
[12].
Bram Cohen. Incentives Build Robustness in BitTorrent. Workshop on Economics of Peerto-Peer Systems, 2003
[13].
Guha S, Daswani N, Jain R, 2006 An experimental study of the Skype peer-to-peer VoIP system. In: Proceedings of the IPTPS06. Santa Barbara, CA, Feb 2006
[14].
J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy. STUN: simple traversal of user datagram protocol (UDP) through network address translators (NATs). RFC 3489, IETF, Mar. 2003.
[15].
Huang G, PPLive a practical P2P live system with huge amount of users. keynote speech at P2PTV workshop, Kyoto, Japan 2007
[16].
Hei X, Liang C, Liang J, Liu Y, Ross KW, Insights into PPLive: a measurement study of a large-scale P2P IPTV system. In: Workshop on Internet Protocol TV (IPTV) services over World Wide Web in conjunction with WWW2006, Edinburgh, Scotland, May 2006
[17].
M. Nafaa and N.Agoulmine, "Analysing Joost peer to peer IPTV protocol ", 11th IFIP/IEEE International Symposium on Integrated Network Management (IM 2009), 2009.
[18].
Chu Y, Rao SG, Seshan S, Zhang H, A case for end system multicast. IEEE Journal on Selected Areas in Communication (JSAC), Special Issue on Networking Support for Multicast, 2002
[19].
Chawathe Y, Scattercast: an architecture for internet broadcast distribution as an infrastructure service. PhD thesis, University of California, Berkeley, August 2000
[20].
Jannotti J, Gifford DK, Johnson KL, Kaashoek MF, OToole Jr. JW, Overcast: reliable multicasting with an overlay network. In Proc. of the Fourth Symposium on Operating System Design and Implementation (OSDI), October 2000
[21].
Padmanabhan VN, Wang HJ, Chou PA, Sripanidkulchai K, Distributing streaming media content using cooperative networking. ACM NOSSDAV, Miami Beach, FL, USA, May 2002
111
[22].
Castro M, Druschel P, Kermarrec A-M, Nandi A, Rowstron A, Singh A (2003) SplitStream: high-bandwidth multicast in a cooperative environment. SOSP03, Lake Bolton, New York, October 2003
[23].
Li J, Chou PA, Zhang C, Mutualcast: an efficient mechanism for content distribution in a P2P network. Proc. Acm Sigcomm Asia Workshop. Beijing, China, Apr. 1012 2005
[24].
Cherkasova L, Lee J, FastReplica: efficient large file distribution within content delivery networks. In: Proc. of the 4-th USENIX Symposium on Internet Technologies and Systems. Seattle, Washington, March 2628 2003
[25].
Li J, Cui Y, PeerStreaming: design and implementation of an on-demand distributed streaming system. To be published in ACM Multimedia Systems Journal 2007
[26].
Huang C, Li J DISCOVR: distributed collaborative vido recorder. International Conference on Multimedia & Expo (ICME2006), Toronto, Canada, Jul. 912 2006
[27].
Kostic D, Braud R, Killian C, Vandekieft E, Anderson JW, Snoeren AC, Vahdat A, Maintaining high-bandwidth under dynamic network conditions. Proceedings of 2005 USENIX Annual Technical Conference (USENIX 2005). April 2005
[28].
Gkantsidis C, Rodriguez P Network Coding for Large Scale Content Distribution. Proc. of INFOCOM 2005. 24th Annual Joint Conference of the IEEE Computer and Communications Societies, Miami, FL, 1317 March 2005
[29].
Zhang M, Luo JG, Zhao L, Yang SQ, A peer-to-peer network for live media streaming using a push-pull approach. Proc. ACM Multimedia 2005, Singapore, pp 287290, Sept 2005
[30].
P. Jacquet T. Clausen. RFC 3626: Optimized Link State Routing Protocol (OLSR), Oct 2003.
[31].
C. E. Perkins, E. M. Belding-Royer, and S. Das, Ad hoc on demand distance vector (AODV) routing, Internet Engineering Task Force, RFC 3561, July 2003. [Online]. Available: http://rfc.net/rfc3561.txt
[32].
Haas, Z.J. and Pearlman, M.R., "The Zone Routing Protocol: A Hybrid Framework for Routing in Ad Hoc Networks," in Ad Hoc Networks, edited by C.E. Perkins, AddisonWesley, 2000.
112
Rfrences
[33].
T. Camp, J. Boleng, and V. Davies. A survey of mobility models for ad hoc network research. Wireless Communication and Mobile Computing Special Issue on Mobile Ad Hoc Networking: Research, Trends and Applications, 2(5):483502, 2002.
[34].
F. Bai and A. Helmy, A Survey of Mobility Modeling and Analysis in Wireless Adhoc Networks, Book Chapter, Wireless Ad Hoc and Sensor Networks. Kluwer Academic Publishers, June 2004.
[35].
A. Chaintreau, P. Hui, J. Crowcroft, C. Diot, R. Gass, and J. Scott. Pocket Switched Networks: Real-world mobility and its consequences for opportunistic forwarding. Technical Report UCAM-CL-TR-617, University of Cambridge, Computer Laboratory, February 2005.
[36].
P. Hui, A. Chaintreau, J. Scott, R. Gass, J. Crowcroft, and C. Diot. Pockets Switched Networks and Human Mobility in Conference Environments. In Proceedings of ACM SIGCOMM05 Workshops, pages 244251, August 2005.
[37].
A. Jardosh, E. M. Belding-Royer, K. C. Almeroth, and S. Suri. Real world Environment Models for Mobile Ad hoc Networks. IEEE Journal on Special Areas in Communications Special Issue on Wireless Ad hoc Networks, 23(3), March 2005.
[38].
M. McNett and G. M. Voelker. Access and Mobility of Wireless PDA User. Mobile Computing Communications Review, 9(2):4055, April 2005.
[39].
T. Henderson, D. Kotz, and I. Abyzov. The changing usage of a mature campus-wide wireless network. In Proceedings of MobiCom04, pages 187201, New York, NY, USA, 2004. ACM Press.
[40].
A. Einstein. Investigations on the Theory of the Brownian Movement. Dover Publications, 1956.
[41].
J.-Y. Le Boudec and M. Vojnovic. Perfect simulation and stationarity of a class of mobility models. In Proceedings of IEEE INFOCOM05, pages 7279, March 2005.
[42].
J.-Y. Le Boudec and M. Vojnovic. The random trip model: stability, stationary regime, and perfect simulation. IEEE/ACM Transactions on Networking, 14(6):11531166, 2006.
[43].
P. Nain, D. Towsley, B. Liu, and Z. Liu. Properties of random direction models. In Proceedings of INFOCOM05, March 2005.
[44].
J.-Y. Le Boudec. Understanding the simulation of mobility models with Palm calculus. Performance Evaluation, 64(2):126147, 2007.
113
[45].
W. Navidi and T. Camp. Stationary distributions for the random waypoint mobility model. IEEE Transactions on Mobile Computing, 3(1):99108, 2004.
[46].
C. Bettstetter, H. Hartenstein, and X. Perez-Costa. Stochastic properties of the random waypoint mobility model. Wireless Networks (Special Issue on Modeling and Analysis of Mobile Networks), 10(5):555567, 2004.
[47].
C. Bettstetter, G. Resta, and P. Santi. The Node Distribution of the Random Waypoint Mobility Model for Wireless Ad Hoc Networks. IEEE Transactions on Mobile Computing, 2(3):257269, 2003.
[48].
G. Resta and P. Santi. An analysis of the node spatial distribution of the random waypoint mobility model for ad hoc networks. In Proceedings of POMC02, pages 4450, New York, NY, USA, 2002. ACM.
[49].
M. Garetto and E. Leonardi. Analysis of random mobility models with PDEs. In Proceedings of MobiHoc06, pages 7384, New York, NY, USA, 2006. ACM.
[50].
X. Hong, M. Gerla, G. Pei, and C.-C. Chiang. A group mobility model for ad hoc networks. In Proceedings of the 2nd International Workshop on Modeling Analysis and Simulation of Wireless and Mobile Systems (MSWiM99), pages 5360, 1999.
[51].
K. Wang and B. Li. Group mobility and partition prediction in wireless ad-hoc networks. Proceedings of ICC02, 2:10171021, 2002.
[52].
K. Blakely and B. Lowekamp. A structured group mobility model for the simulation of mobile ad hoc networks. In Proceedings of MobiWac04, pages 111118, New York, NY, USA, 2004. ACM.
[53].
M. Piorkowski, N. Sarafijanovic-Djukic, and M. Grossglauser. On Clustering Phenomenon in Partitioned Mobile Networks. In Proceedings of First ACM SIGMOBILE International Workshop on Mobility Models for Networking Research (MobilityModels08), Hong Kong S. A. R., China, May 2008.
[54].
M. Musolesi and C. Mascolo. A community based mobility model for ad hoc network research. In Proceedings of the 2nd ACM/SIGMOBILE International Workshop on Multihop Ad Hoc Networks: from theory to reality (REALMAN06). ACM Press, May 2006.
[55].
M. Musolesi and C. Mascolo. Designing mobility models based on social network theory. ACM SIGMOBILE Mobile Computing and Communication Review, 11(3), July 2007.
114
Rfrences
[56].
M. Gerla, C. Lindemann, and A. Rowstron. P2P MANETs - new research issues. In Dagstuhl Seminar Proceedings, number 05152, Dagstuhl, Germany, Apr. 2005.
[57].
A. Rowstron and P. Druschel, Pastry: Scalable, Decentralized Object Location, and Routing for Large-Scale Peer-to-Peer Systems, Proc. IFIP/ACM Int. Conf. on Distributed Systems Platforms, LNCS 2218, Heidelberg Germany, Springer 2001.
[58].
I. Stoica, R. Morris, D. Karger, F. Kaashoek, and H. Balakrishnan, Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications, Proc. Int. Conf. on Applications, Technologies, Architectures, and Protocols for Computer Communication (ACM SIGCOMM), San Diego, CA, 2001.
[59].
S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker, A Scalable ContentAddressable Network, Proc. Int. Conf. on Applications, Technologies, Architectures, and Protocols for Computer Communication (ACM SIGCOMM), San Diego, CA., 2001.
[60].
P.Johansson et al. Scenario Based Performance Analysis of Routing Protocols for Mobile Ad-hoc Networks, Mobicom 99, 1999 Seatle, USA
[61].
J. Broch et al., A Performance Comaprison of Multi-Hop Wireless Ad hoc Network Routing Protocols, MobiCom 98, 1998, Dallas, USA
[62]. [63].
O. Bertsekas, R. Gallager, Data Networks, 2nd Edition, Prentice Hall Inc., 1992 R. Schollmeier. A definition of Peer-to-Peer Networking towards a Delimitation against Classical Client-Server Concepts. Proceedings of WATM-Eunice 2001. pp. 131-138. 2001.
[64].
S. Saroiu, P. K. Gummadi, S. D. Gribble. A Measurement Study of Peer-to-Peer File Sharing Systems Technical Report UW-CSE-01-06-02. July 2001
[65].
R. Atkinson, S. Kent. Security Architecture for the Internet Protocol. RFC2401. November 1998
[66].
Y. C. Hu, S. M. Das, and H. Pucha. Exploiting the synergy between peer-to-peer and mobile ad hoc networks. In Proc. of HotOS-IX, May 2003.
[67].
F. Dabek, M.F. Kaashoek, D. Karger, R.Morris, and I. Stoica.Wide-area cooperative storage with CFS. In Proc. of ACM SOSP, October 2001.
[68].
A. Rowstron and P. Druschel. PAST: a large-scale, persistent peer-to-peer storage utility. In Proc. of ACM SOSP, October 2001.
115
[69].
M. Castro, P. Druschel, A.-M. Kermarrec, A. Nandi, A. Rowstron, and A. Singh. Splitstream: highbandwidth multicast in a cooperative environment. In Proc. of ACM SOSP, October 2003.
[70].
M. Castro, P. Druschel, A.-M. Kermarrec, and A. Rowstron. Scribe: a large-scale and decentralized application-level multicast infrastructure. IEEE Journal on Selected Areas in Communication (JSAC), 20(8), October 2002.
[71].
S. Ratnasamy, M. Handley, R. Karp, and S. Shenker. Application-level multicast using contentaddressable networks. In Proc. of the Third International Workshop on Networked Group Communication, November 2001.
[72].
R. Zhang and Y.C. Hu. Borg: a hybrid protocol for scalable application-levelmulticast in peer-to-peer systems. In Proc. of NOSSDAV, June 2003.
[73].
S.Q. Zhuang,B.Y. Zhao, A.D. Joseph, R.H.Katz, and J.Kubiatowicz. Bayeux: an architecture for scalable and fault-tolerant wide-area data dissemination. In Proc. of NOSSDAV, June 2001.
[74].
C. Tang, Z. Xu, and S. Dwarkadas. Peer-to-peer information retrieval using self-organizing semantic overlay networks. In Proc. of ACM SIGCOMM, August 2004.
[75].
L.B. Oliveira, I.G. Siqueira, and A.A. Loureiro. Evaluation of ad-hoc routing protocols under a peer-to-peer application. In Proc. of IEEE WCNC, March 2003.
[76].
A. Klemm, C. Lindemann, and O. Waldhorst. A special-purpose peer-to-peer file sharing system for mobile ad hoc networks. In Proc. of IEEE VTC, October 2003.
[77].
F. Delmastro. "From Pastry to CrossROAD: CROSS-layer Ring Overlay for AD hoc networks". In Proc. of PerCom, March 2005.
[78].
S.M. Das, H. Pucha, and Y.C. Hu. Ekta: an efficient peer-to-peer substrate for distributed applications in mobile ad hoc networks. Technical Report TR-ECE-04-04, Purdue University, January 2004.
[79].
Q-T Vuong-Nguyen, obility Management in 4G Wireless Heterogeneous Networks ,Thse de doctorat, University of Evry Val dEssonne, Evry, July 2007
[80].
Y. Birk and Y. Wiener, A bucket-interleaving multiplexer for efficient near-on-demand streaming to resource-constrained clients, in Proc. of IEEE International Conference on Multimedia and Expo ICME'02, vol. 1, 2002.
116
Rfrences
[81].
L. Cai and Y. Lu, Energy management using buffer memory for streaming data,in IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 24, no. 2, pp. 141-152, 2005.
[82].
A. Ferreira, "Optimizing Microsoft Windows Media Services 9 Series", Technical Brief, Microsoft Windows Digital Media Division, March, 2005.
[83]. [84].
R. Koodli, Fast handovers for Mobile IPv6, IETF RFC 0468, 2005. H. Soliman, C. Castelluccia, K. E. Malki, and L. Bellier, Hierarchical mobile IPv6 mobility management (HMIPv6), IETF RFC 4140, 2005.
[85].
C. Blondia, N. Van den Wijngaert, G. Willems, and O. Casals, Performance Analysis of Optimized Smooth Handoff in Mobile IP, in Proc. of 5th ACM Int. Workshop on Modeling analysis and simulation of wireless and mobile systems, Atlanta, USA, 2002.
[86].
M. Jain and C. Dovrolis, "Pathload: A measurement tool for end-to-end available bandwidth", in Proc. of Passive and Active Measurements Workshop, 2002.
[87].
V. Ribeiro, R. Riedi, R. Baraniuk, J. Navratil, and L. Cottrell, "pathChirp: Efficient Available Bandwidth Estimation for Network Paths", in Proc. of Passive and Active Measurement Workshop, 2003.
[88].
C. Dovrolis, P. Ramanathan, and D. Moore, "What do packet dispersion techniques measure?" in Proc. of IEEE INFOCOM, vol. 2, 2001.
[89].
J. Strauss, D. Katabi, and F. Kaashoek, "A measurement study of available bandwidth estimation tools", in Proc. of the 2003 ACM SIGCOMM conference on Internet measurement, USA, 2003, pp. 39-44.
[90].
B.
Liang
and
Z.
Haas,
Predictive
Distance-Based
Mobility
Management
for
Multidimensional PCS Network, IEEE/ACM Transactions on Networking, vol. 11, no. 5, 2003. [91]. J. Francois, G. Leduc, and S. Martin, Learning movement patterns in mobile networks: a generic method, in Proc. of European Wireless, 2004, pp. 128134. [92]. H. Karimi and X. Liu, A Predictive Location Model for Locationbased Services, in Proc. of ACM Int. Workshop Advances in Geographic Information Systems (GIS), 2003.
117
[93].
H. Ebersnan and O. Tonguz, Handoff Ordering using Signal Prediction Priority Queuing in Personal Communications Systems, in IEEE Trans. Veh. Technology, vol. 48, no. 1, 1999, pp. 2035.
[94].
S. Sheu and C. Wu, Using Grey Prediction Theory to Reduce Handoff Overhead in Cellular Communication Systems, in Proc. of IEEE Int. Symp. Personal, Indoor and Mobile Radio Communications, 2000.
[95].
S. Rezaei and B. Khalaj, Grey Prediction Based Handoff Algorithm, Transactions on Engineering, Computing and Technology, vol. 2, 2004.
[96].
P. Bellavista, A. Corradi, and C. Giannelli, Adaptive Buffering based on Handoff Prediction for Wireless Internet Continuous Services, in Proc. of Int. Conf. on High Performance Computing and Communications (HPCC05), 2005.
[97].
D. Lee, C. Lee, and J. Kim, Seamless media streaming over mobile IP-enabled wireless LAN, in Proc. of IEEE Consumer Communications and Networking Conference (CCNC), 2005, pp. 116121.
[98].
D. Lee, J. Kim, and P. Sinha, Handoff-aware Adaptive Media Streaming in Mobile IP Networks, in Proc. of Int. Conf. on Communications, France, 2004.
[99].
D. Lee, C. Lee, and J. Kim, "Seamless media streaming over mobile IP-enabled wireless LAN", in Proc. of IEEE Consumer Communications and Networking Conference (CCNC), 2005, pp. 116-121.
[100]. [101].
J. Deng, "Introduction to grey theory", The Journal of Grey System, vol. 1, no. 1. M. Khalil, J. El Falou, W. Duchne, and D. Hewson, "Automatic threshold determination for a local approach of change detection in long term signal recordings," EURASIP journal on Advances in Signal Processing, 2007.
[102].
M. Basseville and I. Nikoforov, Detection of Abrupt changes: Theory and Application. Prentice Hall, NJ, 1993.
[103].
M. Gudmundson, "Correlation model for shadow fading in mobile radio systems," IEEE Electronics Letters, vol. 27, pp. 21452146, Nov. 1991.
[104].
ETSI, "Selection procedure for the choice of radio transmission technologies of the UMTS," Tech. Rep. TR 101.112 v3.2.0, April 1998.
118
Rfrences
[105].
J. Doble, Introduction to radio propagation for fixed and mobile communications. Artech House, Boston, 1996.
[106].
E. J. Kempf, Goals for Network-Based Localized Mobility Management (NETLMM), IETF RFC 4831,April 2007.
[107].
F. Gustafsson, Adaptive Filtering and Change Detection. Wiley New York, 2000. Carra, Damiano;Lo Cigno, Renato;Biersack, Ernst W, Graph based analysis of mesh overlay streaming systems, IEEE Journal of selected areas in communications Vol. 25 N 9 p.1667-1677, December 2007
[108].
[109].
Carra, Damiano;Lo Cigno, Renato;Biersack, Ernst W, Graph based modeling of P2P streaming systems, Networking 2007, 6th IFIP international conference on Networking, May 14 -18, 2007, Atlanta, USA
[110].
Carra, Damiano;Lo Cigno, Renato;Biersack, Ernst W, Fast stochastic exploration of P2P file distribution architectures, Globecom 2006, November 27, December 1st 2006, San Francisco, USA
[111].
Carra, Damiano;Lo Cigno, Renato;Biersack, Ernst W, Content delivery in overlay networks: a stochastic graph processes perspective, GLOBECOM 2006, November 27th December 1st, 2006, San Francisco, USA
[112].
B Biskupski, M Schiely, P Felber, R Meier, Tree-Based Analysis of Mesh Overlays for Peer-to-Peer Streaming, Lecture Notes in Computer Science, Springer, 2008.
[113].
Y. C. Tu, J. Sun, M. Hefeeda, and S. Prabhakar, An Analytical Study of Peer-to-Peer Media Streaming Systems, ACM TOMCCAP, 1(4), 2005.
[114].
S. Nikoletseas, J. Reif, P. Spirakis, and M. Young, Stochastic Graphs Have Short Memory: Fully Dynamic Connectivity in Poly-Log Expected Time, Proc. 22nd Intl Colloquium Automata, Languages, and Programming (ICALP 95), pp. 159-170, 1995.
[115].
S. N. Dorogovtsev, and J. F. F. Mendes, Evolution of Networks: From Biological Nets to the Internet and WWW, Oxford University Press, Oxford, January 2003.
[116].
N. Magharei, R. Rejaie, PRIME: Peer-to-Peer Receiver-drIven MEsh-based Streaming, in Proc. IEEE INFOCOM 2007, Anchorage, Alaska, May 2007.
[117].
Y. Sung, M. Bishop, and S. Rao, Enabling Contribution Awareness in an Overlay Broadcasting System, in Proc. SIGCOMM 2006, Sept. 2006.
119
[118].
X. Zhang, J. Liu, B. Li, and T. S. P. Yum, DONet/CoolStreaming: A Data-driven Overlay Network for Live Media Streaming, in Proc. IEEE INFOCOM 2005, Miami, Mar. 2005.
[119].
V. K. Goyal, Multiple Description Coding: Compression Meets the Network, in IEEE Signal Processing Magazine, pp. 7493, Sept. 2001.
[120].
Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[121].
M. Musolesi and C. Mascolo. A community based mobility model for ad hoc network research. In Proceedings of the 2nd ACM/SIGMOBILE International Workshop on Multihop Ad Hoc Networks: from theory to reality (REALMAN06). ACM Press, May 2006.
[122].
D. J. Watts. Small Worlds The Dynamics of Networks between Order and Randomness. Princeton Studies on Complexity. Princeton University Press, 1999.
[123].
J.Scott, R. Gass, J. Crowcroft, P. Hui, C. Diot, and A. Chaintreau. CRAWDAD data set cambridge/haggle (v. 2006-01-31). Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/haggle, Jan. 2006.
[124].
A. Chaintreau, P. Hui, J. Crowcroft, C. Diot, R. Gass, and J. Scott. Pocket Switched Networks: Real-world mobility and its consequences for opportunistic forwarding. Technical Report UCAM-CL-TR-617, University of Cambridge, Computer Laboratory, February 2005.
[125].
J. Scott. Social Networks Analysis: A Handbook. Sage Publications, London, United Kingdom, second edition, 2000.
[126].
S. Wasserman, K. Faust, and D. Iacobucci. Social Network Analysis: Methods and Applications (Structural Analysis in the Social Sciences). Cambridge University Press, November 1994.
[127].
M. E. J. Newman and M. Girvan. Finding and evaluating community structure in networks. Physical Review E, 69, February 2004.
[128].
L. Viennot, P. Jacquet, T. H. Clausen, "Analyzing control traffic overhead versus mobility and data traffic activity in mobile Ad-Hoc network protocols," presented at ACM Wireless Networks journal (Winet), 2004.
120
Rfrences
[129].
M.K.Sbai , C.Barakat, J.Choi, A.Al Hamra, T.Turletti, "Adapting BitTorrent to wireless ad hoc networks" In proc. of the 7th International conference on ad hoc networks and wireless 2008 (AD-HOC NOW), Sophia Antipolis, France, September 2008.
[130].
A.Klemm, C.Lindermann, O.Waldhorst. A special-purpose peer-to-peer file sharing system for mobile ad hoc networks. In Proc. of IEEE VTC, Oct 2003.
[131].
G. Ding, B. Bhargava, Peer-to-Peer File-Sharing over Mobile Ad hoc Networks. In Proc. of the 2nd IEEE PERCOM-W, Orlando, FL, USA, 2004.
[132].
S. Rajagopalan, C-C. Shen, A cross-Layer Decentralized BitTorrent for Mobile Ad hoc Networks. In Proc. of ACM/IEEE MOBIQUITOUS, San Jose, CA, USA, 2006
[133].
S.M. Das, H.Pucha, Y.C. Hu. Ekta: an efficient peer-to-peer substrate for distributed applications in mobile ad hoc networks. Technical Report TR-ECE-04-04, Purdue University, Jan 2004.
[134].
T. Zahn and J. Schiller. "MADPastry: A DHT Substrate for Practicably Sized MANETs". In Proc. Of ASWN, June 2005.
[135].
Mani, M., Nguyen, A., Crespi, N., "SCOPE- Service Classified Overlay for P2P Environment, a service platform for P2P services over Ad-hoc Networks (demo)", IEEE MASS 2008, Atlanta, September 2008.
[136].
Magharei, N., Rejaie, R., Guo, Y.: Mesh or multiple-tree: A comparative study of live p2p streaming approaches. In: Proceedings of 26th IEEE International Conference on Computer Communication (INFOCOM), May 2007, 14241432.
[137].
Kumar, R., Liu, Y., Ross, K.: Stochastic fluid theory for p2p streaming systems. In: Proceedings of 26th IEEE International Conference on Computer Communication (INFOCOM), May 2007, 919927.
[138].
A. Vlavianos, M. Iliofotou, and M. Faloutsos, BiToS: Enhancing Bit-Torrent for supporting streaming applications, in IEEE Global Internet, Apr. 2006.
[139].
S. Tewari and L. Kleinrock, Analytical model for bittorrent-based live vido streaming, In proc. IEEE NIME Workshop, 2007.
[140].
C.Perkins, P.Bhagwat, Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers in ACM SIGCOMM94.
121
[141].
W. Poon, J. Lee, D. Chiu: Comparison of Data Replication Strategies for Peer-to-Peer Video Streaming. 5th International Conference on Information, Communications, and Signal Processing, Bangkok, Thailand, Dec. 2005.
Annexe A.
A.1. Liste des publications
A.1.1. Articles de recherche
1. M. Nafa and N. Agoulmine, "MadP2PStream: Mobile Peer-to-peer Streaming over MANETs: Model and Optimizations", soumis Springer Peer-to-Peer Networking and Applications PPNA (journal) 2. M. Nafa and N. Agoulmine, " MadTorStream: On P2P streaming over mobile communities", soumis 1st IEEE International Workshop on Community driven Mobile Multimedia (CMM2009). (full paper) 3. V.K. Gondi, M. Nafa and N. Agoulmine, "Network Assisted Network Selection procedure For Heterogeneous Wireless and Cellular Networks", 4th IFIP/IEEE International Workshop on Broadband Convergence Networks (BcN 2009) (full paper) 4. M. Nafa and N. Agoulmine, "Analysing Joost peer to peer IPTV protocol ", 11th IFIP/IEEE International Symposium on Integrated Network Management (IM 2009), 2009. (poster) 5. M. Nafa and N. Agoulmine, "Handover Prediction-based Seamless Media Streaming for Wireless Packet Networks", The Fifth International Conference on Autonomic and Autonomous Systems, ICAS 2009 (Demo Session) 6. M.Nafa, V.K.Gondi and N.Agoulmine, "Multimedia Streaming in IPTV over 802.16 Experiments: Tesbed Measurements", First International Workshop on Wireless Broadband Access for Communities and Rural Developing Regions, 10 pages, Karlstad University Press, 2008. (full paper) 7. M. Nafa, N. Agoulmine, and Y. Ghamri-Doudane, "Topological zone/peer naming in Mobile P2P Networks", 13th Annual Workshop of HP OpenView University Association, Nice, France, Mai 21 - 24, 2006. (poster)
123
124
Annexe A
A.1.2.
Rapports de projet
1. M. Nafa et al., "D1.1: State of the art analysis", Technical Deliverable Report D1.1, project ITEA WellCom, 2008. 2. M. Nafa et al., "D3.1: State of the art analysis for P2P Systems", Technical Deliverable Report D3.1, project ITEA ExpeShare, 2008. 3. M. Nafa et al., "D3.2: P2P ExpeShare Network Services Architecture (P2PNSA) and API specification ", Technical Deliverable Report D3.2, project ITEA ExpeShare, 2008. 4. M. Nafa et al., "D1.2: SUMO system requirements and basic functional architecture", Technical Deliverable Report D1.2, project ITEA SUMO, 2007. 5. .M. Nafa et al., "D2.3: Network selection, Mobility and security management", Technical Report D2.3, project ITEA SUMO, 2007. 6. M. Nafa et al., "D5.1 Demonstrator description & integration plan", Technical Deliverable Report D5.1, project ITEA SUMO, 2007.
125
A.2. Index
AAA, 37, 38 affinit, xi, xviii, 75, 76, 78, 82, 83, 99 ALM, 22 AODV, xvi, 29, 40, 103, 113 AP, 44, 49, 50, 51, 55, 59, 60, 61 bandes, 69, 70, 71, 72, 85, 86, 87 BER, 9 BitHoc, 97, 98, 99, 100, 102 BitRate, 3, 97 BitTorrent, xi, xvi, 10, 13, 16, 17, 18, 19, 22, 25, 26, 33, 94, 95, 97, 99, 102, 107, 108, 112, 121 Bluetooth, 31 buffering, 4, 43, 45, 46, 47, 48, 49, 50, 51, 52, 56, 58, 59, 62, 63, 67 CAN, 33, 40 Chord, 33, 40, 116 churn Voir dynamique client/serveur, 1, 108 Closest Deadline First, xii, 98, 99, 101, 102 Community based mobilty, xvii, 32 Crossroad, 40 CSGP, 68 CUSUM, 53, 54, 55 DHT, xi, xx, 11, 12, 16, 39, 40, 41, 97, 109, 122 DSDV, 28, 40, 98, 99, 122 DVB, 8 eDonkey, xvi, 13, 16, 17, 111 EM, 72, 73, 74, 91 eMule, xi, 16, 18 ExpeShare, 4, 94, 96, 124 FaceBook, 1 FAI, 3 fast MIP, 45 FastTrack, xvi, 15, 17 FEC, 71, 120 filtre Grey Voir GM flash crowd, 71 Gauss-Markov, 46 GM, xvii, 47, 49, 50, 51, 52, 53, 54, 55, 56, 57 GPS, 31, 93 Groover, xiii, xix, 67, 84 handover, xiii, xvii, xviii, xx, 4, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 59, 60, 61, 62, 63, 105, 106, 108 Heterogeneous Random Walk, 32 hierarchical MIP, 45 HTTP, 8, 15 IARP, 30 IEEE, 8, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123 IERP, 30 IETF, 28, 112, 117, 118, 119 INRIA, 1, 28 inter-couche, 33 IP, xvi, 2, 8, 10, 12, 13, 14, 15, 18, 19, 33, 36, 37, 41, 44, 45, 48, 60, 93, 118, 119 IPSEC, 37, 38 IPTV, 2, 93 ITEA, 4, 94, 96, 124 Joost, xvi, 10, 19, 21, 93, 95, 109, 112, 123 Kademlia, 16, 111 Kazaa, xi, 10, 15, 18 MAC, 8, 33, 100 MADP2PStream, 5, 65, 66, 82, 85, 92, 103, 105, 106, 107, 108 MadTorStream, 5, 6, 93, 94, 95, 97, 98, 100, 105, 107 MANET, 3, 6, 13, 27, 28, 31, 33, 34, 35, 36, 37, 38, 39, 40, 41, 66, 67, 68, 69, 74, 80, 82, 83, 84, 92, 93, 96, 100, 102, 105, 106, 107, 108, 109 MANETs, 4, 5, 7, 9, 24, 27, 33, 34, 36, 38, 39, 41, 82, 94, 95, 96, 99, 102, 106, Voir MANET Markov cachs, 46 Markovien, 72 MDC, 71 Mesh, ix, xi, 22, 23, 24, 97, 120, 122 middleware, 33
126
Annexe A
mobilit, xvii, xviii, xix, 1, 3, 4, 5, 6, 9, 29, 30, 31, 32, 33, 34, 36, 38, 40, 43, 44, 63, 66, 67, 68, 70, 74, 75, 77, 78, 79, 80, 82, 83, 84, 86, 87, 89, 92, 94, 96, 98, 100, 102, 105, 106, 107 Monte-Carlo, 67 MPEG-TS, 8 MPR, 28, 29 Napster, 10, 13, 14, 16, 111 NAT, 18 Network Selection, 44, 123 NS-2, 5, 100, 102, 107 OLSR, xvi, 28, 29, 40, 103, 113 ORION, 40 overhead, xi, xviii, 28, 29, 38, 66, 67, 79, 82, 84, 90, 91, 92, 121 P2P, 1, 2, 4, 6, 10, 11, 15, 16, 17, 18, 19, 21, 22, 25, 26, 33, 34, 35, 36, 37, 38, 39, 41, 65, 68, 96, 100, 107, 108, 109 Pastry, 33, 40, 41, 115, 117 Pathchirp, 46, 58 Pathload, 46, 118 PPLive,, 19, 20 proactif, xviii, 5, 6, 28, 80, 81, 83, 84, 91, 94, 102, 107 pull, 22, 24, 26, 113 push, xvi, 24, 25, 26, 113 QoE, 9 QoS, 4, 8, 26, 29, 38, 43 RAM, 45 Random Trip, 31 Random Walk, 31, 96 Random Way-Point, 31, 32, 78 RE, 73, 74 ractif, xviii, 5, 34, 63, 80, 81, 83, 91, 92, 103 Reference Group, 32 Reference Velocity Group, 32 RLS, 53, 55 RREP, 29, 30
27, 45, 81, 99,
80, 20, 40,
92,
94,
RREQ, 29 RSS, xi, 44, 46, 49, 50, 51, 52, 53, 54, 55, 56, 57, 60, 61, 62 RTCP, 8 RTP, 8 RTSP, 8 sans couture Voir seamless seamless, 46, 106 Skype, 10, 18, 19, 21, 112 SM Stream, xi, xvii, xix, 4, 5, 43, 61, 105, 106 smooth handover scheme, 45 Spruce, 46 streaming, 2, 3, 4, 5, 6, 7, 8, 9, 13, 19, 20, 21, 22, 24, 25, 26, 37, 41, 43, 44, 45, 46, 47, 48, 49, 51, 57, 58, 60, 62, 63, 65, 66, 67, 68, 69, 70, 71, 73, 74, 82, 83, 87, 92, 93, 94, 95, 96, 97, 100, 101, 102, 105, 106, 107, 108, 109, 110, 113, 122 Structured Group, 32 SUMO, 4, 43, 124 TCP, 8 tracker, 16, 20, 99 Tree, ix, xi, 22, 23, 24, 120 TTL, 14, 29, 35, 36, 40 UDP, 8, 14, 47, 48, 49, 50, 58, 112 UMTS, 44, 119 VLC, xviii, 19, 58, 59 VoD, 2, 93 VoIP, 2, 18, 95 Wifi, 4 WiFi, 5, 43, 44, 93, 97 WiMax, 44 WLAN, 4, 9, 41, 44, 47, 48, 49, 51, 52, 55, 57, 106 YouTube, 1 ZRP, xvii, 30
A.3. Glossaire
AAA ALM AODV AP BER CAN CUSUM DHT DVB FAI MIP GM GPS HTTP IARP IEEE IERP IETF INRIA IP IPSEC IPTV MAC MADP2PStream MadTorStream MANET MPEG-TS MPR NAT NS-2 OLSR P2P QoE QoS RAM RREP RREQ RSS RTCP Authentication Autorisation Accounting Application-Layer Multicast Advanced On-demand Distance Vecto routing Access Point Bit Error Rate Content Addressable Network CUmulative SUM Distributed Hash Tables Digital Vido Broadcasting Fournisseur dAccs Internet Mobile Internet Protocol Grey Model Global Positionning System HyperText Transfert Protocol IntrA-zone Routing Protocol International Electric Electronic Engineers IntEr-zone Routing Protocol Internet Engineering Task Force Institut National de Recherche en Informatique et Automatique Internet Protocol Internet Protocol SECured Internet Protocol TeleVision Medium Access Control Mobile ad hoc Peer To Peer Streaming Mobile ad hoc Torrent Streaming Mobile Ad hoc NETwork Moving Pictures Express Group Transport Stream MultiPoint Relay Network Address Translator Network Simulator 2 Optimized LinkState Routing protocol Peer to Peer Quality of Experience Quality of Service Random Acces Memory Route REPly Route REQuest Received Signal Strength Real Time Control Protocol
127
128
Annexe A
RTP RTSP SM Stream SUMO TCP TTL UDP UMTS VLC VoD VoIP WiFi WiMax WLAN ZRP
Real Time Protocol Real Time Streaming Protocol Seamless Mobile Multimedia Streaming Service Ubiquity in Mobile and Wireless Realm Transmission Control Protocol Time To Live User Datagram Protocol Universal Mobile Telecommunications System VideoLan Client Vido on Demand Voice over Internet Protocol Wireless Fidelity Worldwide Inter-operability for Microwave Access Wireless Local Area Network Zone Routing Protocol
A.4. Media Streaming dans VLC
129

Streaming

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Streaming

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIT D'VRY-VAL-D'ESSONNE

Laboratoire de Rseaux et Systmes Multimdia

Docteur de lUniversit d'vry-Val-dEssonne

Prsente et devrait tre soutenue publiquement Le 25 Mars 2009

M. Ahmed KARMOUCH M. Djamel BELAID M. Chadi BARAKAT M

Encore merci du fond du cur,

Liste des tableaux

Liste des figures

Table des figures

Liste des algorithmes

Table des matires

Table des matires

2.3.1.3. Hybride ................................................................................................29 a. ZRP (Zone Routing Protocol) ........................................................................... 29

Chapitre 3. 3.1. 3.2.

3.3. 3.4. 3.5. 3.6.

Table des matires

Introduction ......................................................................................................................... 65 4.1.1. Objectif de cette contribution .................................................................................... 66

Reprsentation de la mobilit dans le graphe de streaming p2p .......................................... 82

Discussion et conclusions..................................................................................................... 91 : MadTorStream - un protocole pour le streaming p2p mobile .............................. 93

5.4. 5.5. 5.6.

Chapitre 6. 6.1. 6.2.

Table des matires

1.1. Streaming peer to peer

1.2. Mobile ad hoc networks

1.3. Contexte & Motivations

1.4. Contributions de la thse

1.5. Structure du document

Chapitre 2. Etat de lart

2.1. Le streaming vido

Chapitre 2 Etat de lart

quest le rseau Internet. Ce streaming peut tre envoy de deux manires

Transport de flux sur le rseau

Sur la couche applicative

Utilisation du 802.11 pour le streaming

Chapitre 2 Etat de lart

2.2. Les applications p2p

Figure 1: Rseau P2P de 1re gnration (index central)

Figure 2: Rseau P2P de 2me gnration (inondation de requte)

Tables de hachages distribues DHT:

Chapitre 2 Etat de lart

Figure 3: Table de hachage distribue (DHT)

Figure 4: Le super peering

Application de partage de contenu

Partage de fichier (File sharing)

Chapitre 2 Etat de lart

Chapitre 2 Etat de lart

Chapitre 2 Etat de lart

Streaming audio et vido

Chapitre 2 Etat de lart

Chapitre 2 Etat de lart

Les deux topologies du streaming P2P

Figure 6: topologies Mesh vs. Tree.

Tableau 1 Comparaison entre topologies Mesh et Tree

Chapitre 2 Etat de lart

Stratgies de slection de bloc et de nuds

Technique de transfer des blocs a. Le mode push

Chapitre 2 Etat de lart

Figure 7: Push vs. Pull.

2.3. Les rseaux ad hoc mobiles

Classification des protocoles de routage

Figure 8: Classification des familles de protocoles ad hoc

Chapitre 2 Etat de lart

OLSR (Optimized Link-State Routing)

AODV (Ad Hoc On-demand Distance Vector)