GRADE DE DOCTEUR DE L'UNIVERSITÉ DE FRANCHE-COMTÉ Spécialité : Automatique et Informatique

N d'ordre 1050 THÈSE présentée à L'U.F.R. DES SCIENCES ET TECHNIQUES DE L'UNIVERSITÉ DE FRANCHE-COMTÉ pour obtenir le GRADE DE DOCTEUR DE L'UNIVERSITÉ DE FRANCHE-COMTÉ Spécialité : Automatique et Informatique par Conception d'une plate-forme d'adaptation globale : application au télédiagnostic médical Fabien RENARD Soutenue le 8 décembre 2004 devant la Commission d'examen : Rapporteurs Isabelle DEMEURE Professeur à l'ecole Nationale Supérieure des Télécommunications Pascal LORENZ Professeur à l'université de Haute Alsace Directeurs Hervé GUYENNET Professeur à l'université de Franche-Comté Jean-Christophe LAPAYRE Professeur à l'université de Franche-Comté Examinateur François SPIES Professeur à l'université de Franche-Comté

A la mémoire de Tafsir.

Remerciements Je remercie Isabelle Demeure et Pascal Lorenz d'avoir bien voulu accepter de rapporter cette thèse. Je les remercie également de leur participation au jury. Je remercie François Spies qui me fait l'honneur d'être membre de mon jury. Je tiens tout particulièrement à remercier conjointement Hervé Guyennet et Jean-Christophe Lapayre pour leur encadrement. Je les remercie pour leur disponibilité et leurs bons conseils. Ils m'ont permis de bien cerner les aspects du monde de la recherche universitaire. Je remercie également Jacques Julliand, directeur du laboratoire, pour tout le travail administratif qu'il a dû eectuer pour moi durant ces années. Un grand merci à tous les membres du LIFC avec qui j'ai eu l'occasion de travailler, en particulier Eric. Merci aux thésards avec qui j'ai partagé le bureau et de bons moments : Fabien, Julien et plus particulièrement David, Samir, Tafsir, Yohann. Merci à Ewa.

6

Table des matières Introduction 23 Objectifs................................... 24 Contributions de la thèse......................... 24 Plan du mémoire de thèse......................... 26 1 État de l'art sur l'adaptabilité 27 1.1 Introduction.............................. 27 1.2 Présentation de l'adaptabilité.................... 28 1.3 Problèmes liés à l'hétérogénéité................... 28 1.3.1 Adaptation au réseau..................... 29 1.3.2 Adaptation aux terminaux.................. 30 1.3.3 Adaptation à l'utilisateur.................. 31 1.3.4 Conclusion.......................... 32 1.4 Les mécanismes de l'adaptation................... 33 1.4.1 Transcodage des données.................. 34 1.4.2 Adaptation favorisée..................... 40 1.4.3 Contenu adaptatif...................... 40 1.4.4 Changement de protocole.................. 42 1.4.5 Mixer les ux de données.................. 44 1.4.6 Conclusion.......................... 44

8 TABLE DES MATIÈRES 1.5 L'adaptation au niveau du système................. 45 1.5.1 La conguration du système................. 45 1.5.2 Détection des changements (supervision).......... 46 1.5.3 Prise de décisions....................... 47 1.5.4 Application des décisions.................. 48 1.5.5 Conclusion.......................... 48 1.6 Critères d'adaptation......................... 49 1.6.1 Sens de l'adaptation..................... 49 1.6.2 Localisation de l'adaptation................. 50 1.6.3 Conclusion.......................... 52 1.7 Les plates-formes d'adaptation à base de proxies......... 52 1.7.1 Proxy............................. 53 1.7.2 Les architectures incluant un proxy............. 53 1.7.3 Les architectures incluant plusieurs proxies........ 54 1.8 Discussion et motivation pour dénir une nouvelle plate-forme.. 59 1.8.1 Adaptation globale...................... 60 1.8.2 Le choix des proxies..................... 61 1.8.3 Choix d'une fédération de proxies d'adaptation au lieu de réseaux actifs......................... 62 1.8.4 Choix d'une fédération de proxies d'adaptation au lieu d'une grille de calcul..................... 63 1.8.5 Apport de la plate-forme Appat par rapport aux platesformes existantes....................... 63 1.8.6 Conclusion.......................... 64 2 Présentation de la plate-forme d'adaptation Appat 65 2.1 Introduction.............................. 65 2.2 Architecture de la plate-forme Appat................ 66

TABLE DES MATIÈRES 9 2.3 L'annuaire distribué......................... 67 2.3.1 Instance d'annuaire...................... 68 2.3.2 Informations partagées par l'annuaire........... 68 2.3.3 Fonctionnement de l'annuaire distribué........... 69 2.4 Les Proxies d'adaptation....................... 75 2.4.1 Les composants d'un proxy d'adaptation.......... 75 2.4.2 Formalisation des informations concernant les PAs.... 80 2.5 Gestion par les PAs de l'annuaire distribué............. 85 2.5.1 L'insertion d'un PA à la plate-forme............ 85 2.5.2 Suppression d'un PA de la plate-forme........... 86 2.6 Les sites................................ 87 2.6.1 Formalisation des informations concernant les sites.... 88 2.6.2 Caractéristiques statiques d'un site............. 88 2.6.3 Caractéristiques dynamiques d'un site........... 90 2.6.4 Paramètres utilisateurs.................... 90 2.6.5 Gestion des sites....................... 92 2.7 Transmissions............................. 96 2.7.1 Formalisation des informations concernant les transmissions 98 2.8 Conclusion............................... 100 3 Prise en charge de l'adaptation par Appat 103 3.1 Introduction.............................. 103 3.2 Principes de la prise en charge d'une adaptation réalisée globalement.................................. 104 3.2.1 Appat et la distribution des tâches............. 105 3.2.2 Types de transmissions.................... 107 3.3 Requête................................ 108 3.3.1 Transparence aux applications et sensibilité aux utilisateurs109

10 TABLE DES MATIÈRES 3.4 Conguration............................. 110 3.4.1 Recherche d'une transmission................ 113 3.4.2 Caractéristiques des sites.................. 113 3.4.3 Estimation de l'adaptation................. 115 3.4.4 Conguration locale de la transmission........... 116 3.4.5 Distribution de l'adaptation................. 116 3.4.6 Conguration globale de la transmission.......... 117 3.4.7 Conservation des paramètres pour les transmissions de données discrètes....................... 119 3.4.8 Politiques d'adaptation................... 119 3.4.9 Gestion de prols....................... 120 3.5 Démarrage de la transmission et adaptation............ 122 3.6 Les composants de la partie adaptation............... 124 3.6.1 Gestionnaire d'adaptation.................. 125 3.6.2 Processus d'adaptation.................... 125 3.6.3 Evolution de la transmission................. 128 3.6.4 Modication d'une transmission de données continues.. 131 3.6.5 Arrêt d'une transmission de données continues...... 133 3.7 Exemples de prise en charge de diérentes transmissions..... 133 3.7.1 Premier exemple....................... 133 3.7.2 Second exemple........................ 136 3.8 Conclusion............................... 142 4 Tests et performances 143 4.1 Premier scénario application de visioconférence multi-parties.. 144 4.1.1 Architecture de tests..................... 145 4.1.2 Conguration des sessions du premier scénario, avec et sans Appat.......................... 147

TABLE DES MATIÈRES 11 4.1.3 Comparaison des fréquences de rafraîchissement des images148 4.1.4 Comparaison des débits des transmissions......... 152 4.1.5 Apport de la plate-forme Appat............... 155 4.1.6 Etude des délais induits par l'adaptation.......... 156 4.1.7 Scénario 1 - conclusion.................... 163 4.2 Second scénario Interactions client-serveur web......... 163 4.2.1 Transmission de données discrètes............. 163 4.2.2 Conclusion - deuxième scénario............... 180 4.3 Conclusion du chapitre........................ 180 5 Application à la télémédecine 181 5.1 Présentation de TeNeCi....................... 181 5.1.1 Les objectifs.......................... 182 5.1.2 Urgences neurologiques (UN) données de neuroimagerie et de neurophysiologie.................... 182 5.2 Plate-forme TeNeCi......................... 184 5.2.1 Communication texte, audio et vidéo............ 185 5.2.2 Diagnostic d'images et de ux vidéo............ 185 5.2.3 Adaptabilité dans TeNeCi.................. 187 5.2.4 Les services.......................... 187 5.2.5 Interface utilisateur...................... 190 5.2.6 Protocoles réseau....................... 191 5.2.7 Sécurité et condentialité.................. 192 5.3 Intégration d'appat à TeNeCi.................... 192 5.3.1 Plug-in Appat......................... 193 5.3.2 Interactions entre TeNeCi et Appat............. 195 5.3.3 Contraintes.......................... 196 5.3.4 Adaptation des données échangées dans TeNeCi...... 196

12 TABLE DES MATIÈRES 5.4 Conclusion............................... 198 Conclusions et perspectives 199 Perspectives de développement...................... 200 Perspectives de recherche......................... 203

Table des gures 1.1 Diérents types de terminaux actuels................ 30 1.2 Classication des caractéristiques à prendre en compte lors de l'adaptation de données....................... 33 1.3 Changement de média - Audio Texte.............. 34 1.4 Changement de média - Vidéo Image xe............ 34 1.5 Changement de format - HTML Texte brut.......... 35 1.6 Filtre utilisé lors d'un transcodage................. 35 1.7 Modication des caractéristiques d'une image........... 36 1.8 Adaptation du débit autorisée par le transcodage......... 37 1.9 Exemple de réduction de la dénition d'un ux vidéo....... 38 1.10 Exemple de réduction de la fréquence de rafraîchissement d'un ux vidéo............................... 39 1.11 Exemple de mécanisme de réduction d'erreurs........... 39 1.12 Exemple de ux vidéo encodé hiérarchiquement.......... 41 1.13 Exemple d'ensemble de variations d'un ux audio/vidéo dans MPEG-7................................ 41 1.14 Adaptation d'articles Numériques (DIA).............. 42 1.15 Exemple de changement de protocole................ 43 1.16 Exemple de tunneling........................ 43 1.17 Exemple d'agrégation de ux vidéos................ 44 1.18 Exemple de transmission de données avec RTP/RTCP...... 47

14 TABLE DES FIGURES 1.19 Ranement d'une image IRM.................... 50 1.20 Adaptation sur le site récepteur................... 50 1.21 Adaptation sur le site émetteur................... 51 1.22 Adaptation sur un proxy....................... 52 1.23 Architecture RAPP.......................... 55 1.24 Détail d'un serveur de plate-forme (MWS)............. 57 1.25 Exemple de topologie avec ubiqos................. 58 1.26 Exemple d'adaptation globale réalisée avec la plate-forme Appat 62 2.1 Plate-forme Appat.......................... 65 2.2 Architecture de la plate-forme Appat................ 66 2.3 L'annuaire distribué dans Appat.................. 67 2.4 Exemple d'instance d'annuaire................... 68 2.5 Insertion d'une instance de l'annuaire distribuée.......... 69 2.6 Mise à jour des informations partagées............... 70 2.7 Changement de serveur....................... 71 2.8 Modication en cours de changement de serveur.......... 72 2.9 Panne - Acquittement attendu et non reçu............. 72 2.10 Panne du serveur........................... 73 2.11 Réattribution des PAs en cas de panne............... 74 2.12 La position des proxies dans Appat................. 75 2.13 Les composants du PA........................ 75 2.14 Les diérents protocoles de communication disponibles sur un PA 76 2.15 Etablissement d'une requête..................... 77 2.16 Diagramme d'interaction....................... 78 2.17 Informations sur un PA....................... 80 2.18 Exemple d'informations statiques d'un PA............. 82

TABLE DES FIGURES 15 2.19 Exemple d'informations dynamiques d'un PA........... 82 2.20 Composition d'un PA actif...................... 83 2.21 Exemple d'informations dynamiques d'un PAA.......... 84 2.22 Insertion directe d'un PA...................... 85 2.23 Insertion via un PA.......................... 86 2.24 Suppression d'un PA......................... 87 2.25 Les sites dans Appat......................... 87 2.26 Composition d'un site........................ 88 2.27 Exemple de caractéristiques statiques d'un site.......... 89 2.28 Exemple de caractéristiques statiques et dynamiques d'un site.. 90 2.29 Exemple de paramètres utilisateur................. 91 2.30 Connexions des clients à leur PAI.................. 92 2.31 Insertion d'un client avec changement de PAI........... 93 2.32 Insertion d'un PA et changement de PAI.............. 94 2.33 Panne d'un PA............................ 95 2.34 Les transmissions dans Appat.................... 96 2.35 Adaptation par plusieurs PAs.................... 96 2.36 Transmission vers plusieurs récepteurs............... 97 2.37 Mixage de ux provenant de plusieurs émetteurs......... 97 2.38 Composition d'une transmission................... 98 2.39 Exemple d'informations concernant une transmission....... 99 2.40 Exemple de paramètres utilisateur................. 100 3.1 Exemple d'adaptation globale de deux ux de données continus. 104 3.2 Exemple de distribution verticale et horizontale.......... 105 3.3 Exemple de distribution croisée................... 106 3.4 Deux types de requête........................ 109

16 TABLE DES FIGURES 3.5 Adaptation transparente des données................ 109 3.6 Code source de la méthode conguretransmission de la classe moteurdecision............................ 111 3.7 Suite du code source de la méthode conguretransmission.... 112 3.8 Récupération des caractéristiques.................. 113 3.9 Exemple de représentation d'une MIB............... 115 3.10 Recherche de PAs pour distribuer l'adaptation........... 117 3.11 Le moteur de décision et les critères impliqués lors d'une conguration................................ 118 3.12 Exemple de prols vidéo issus de nos tests avec les PDAs.... 122 3.13 Démarrage d'une transmission.................... 123 3.14 Interactions au niveau du gestionnaire d'adaptation : exemple avec un seul processus d'adaptation................. 124 3.15 Initialisation d'un décodeur..................... 126 3.16 Initialisation d'un encodeur..................... 126 3.17 Filtrage de données discrètes ou continues............. 127 3.18 Transcodage de ux continus.................... 127 3.19 Mixage de ux continus....................... 128 3.20 Supervision avec SNMP....................... 129 3.21 Exemple de reconguration d'une transmission.......... 132 3.22 Etapes du premier exemple..................... 134 3.23 Diagramme d'interactions du premier exemple........... 136 3.24 Etapes du second exemple...................... 137 3.25 Etapes du second exemple (suite).................. 138 3.26 Diagramme d'interactions du second exemple........... 139 3.27 Détails des informations concernant la transmission et ses soustransmissions............................. 140 3.28 Informations de la transmission de le seconde prise en charge.. 141

TABLE DES FIGURES 17 4.1 Architecture pour le premier scénario................ 145 4.2 Démarrage et arrêt des transmissions de la session de visioconférence.................................. 147 4.3 Architecture de la première session (sans la plate-forme Appat). 147 4.4 Architecture de la deuxième session (avec la plate-forme Appat). 148 4.5 Fréquences de rafraîchissement des ux de la première session, sans la plate-forme Appat...................... 149 4.6 Fréquences de rafraîchissement des ux de la seconde session, avec la plate-forme Appat......................... 149 4.7 Tendance des courbes des fréquences de rafraîchissement, sans Appat................................. 151 4.8 Tendance des courbes des fréquences de rafraîchissement, avec Appat................................. 151 4.9 Débits des transmissions inférieurs à 488 Kb, sans la plate-forme Appat................................. 153 4.10 Débits des transmissions, avec la plate-forme Appat........ 153 4.11 Tendance des courbes des débits des transmissions, sans Appat. 154 4.12 Tendance des courbes des débits des transmissions, avec Appat. 154 4.13 Architecture pour le troisième scénario............... 157 4.14 Découpage de la transmission en sous-transmissions........ 158 4.15 Personnalisation du contenu..................... 158 4.16 Délais moyens de démarrage..................... 159 4.17 Délais moyens des images...................... 161 4.18 Flux vidéo (CIF) ayant subi 6 adaptations............. 162 4.19 Redimensionnement (gauche) et recadrage (droite) à la taille de l'écran du terminal.......................... 164 4.20 Architecture de test pour la première phase............ 165 4.21 Mesures eectuées pour le premier cas............... 167 4.22 Mesures eectuées pour le second cas................ 167

18 TABLE DES FIGURES 4.23 Redimensionnement au PC et au PDA - débit LAN........ 168 4.24 Redimensionnement au PDA - débit GPRS............ 169 4.25 Recadrages sans PA (transmission du haut) et avec le PA (transmission du bas)............................ 170 4.26 Résultats des recadrages pour le PDA............... 171 4.27 Architecture de test Le PAI n'est pas chargé........... 173 4.28 Architecture de test Le PAI est chargé.............. 173 4.29 Architecture de test Le PAI est chargé. Utilisation d'un deuxième PA................................... 174 4.30 Délais de traitement sur le client................. 174 4.31 Délais de traitement sur le PAI.................. 175 4.32 Architecture de test diérents coûts de communication..... 177 4.33 Délais de traitement sur le client................. 178 4.34 Délais de traitement sur le PAI.................. 178 4.35 Délais de traitement sur le PA eectuant l'adaptation...... 179 5.1 Navigateur Dicom........................... 186 5.2 Visualiseur Dicom........................... 186 5.3 Exemple de lésion diagnostiquée................... 186 5.4 Architecture de la plate-forme TeNeCi............... 188 5.5 La plate-forme TeNeCi en cours d'utilisation............ 189 5.6 Utilisation de TeNeCi par un médecin "mobile".......... 190 5.7 Maquette de l'interface de la plate-forme TeNeCi......... 191 5.8 Exemple de code montrant l'utilisation du plug-in Appat..... 193 5.9 Exemple de fenêtre d'options pour le plug-in Appat dans TeNeCi 194 5.10 Interaction entre TeNeCi et Appat................. 195 5.11 Exemple de topologie de TeNeCi incluant Appat......... 196

TABLE DES FIGURES 19 5.12 Exemple d'adaptation d'images. Version PC à gauche et version PDA à droite............................. 197 5.13 Exemple d'adaptation de ux vidéo. Version PC à gauche et version PDA à droite.......................... 197 5.14 Exemple de topologie actuelle de la plate-forme.......... 200 5.15 Annuaire et groupes......................... 201 5.16 Groupement des caractéristiques.................. 202

20 TABLE DES FIGURES

Liste des tableaux 4.1 Tableau des formats et préférences des participants récepteurs.. 146 4.2 Tableau des moyennes concernant les transmissions des deux sessions.................................. 155 4.3 Tableau des moyennes de la charge CPU des machines concernées par les transmissions, entre la 5ème minute et la 10ème...... 156 4.4 Tableau des délais moyens de démarrage d'une transmission et d'acheminement des images, pour un PA.............. 162

22 LISTE DES TABLEAUX

Introduction Depuis le début des années 2000, de nombreux objets communicants sont apparus dans notre entourage. Cela a permis le développement d'une nouvelle variété d'applications particulièrement dédiées aux environnements pervasifs 1. Ces applications, qui peuvent changer notre vie de tous les jours, doivent accéder aux informations depuis n'importe où, à n'importe quel moment. Ceci a entraîné un accroissement important de l'hétérogénéité des réseaux et des terminaux et nous a conduit à trouver une solution pour permettre une communication ecace. Cette solution, appelée adaptabilité, consiste à harmoniser les données avec leur environnement. L'adaptabilité est devenue une caractéristique majeure dans les applications distribuées actuelles. Cette technique représente en eet une approche indispensable pour permettre aux utilisateurs d'exploiter les informations qu'ils s'échangent ou qu'ils téléchargent de façon optimale. La localisation de l'adaptation dans tous les cas et quel que soit les terminaux et les réseaux utilisés représente un autre aspect important de cette technique. Dans le cadre de nos travaux [Gar01] et plus généralement dans le domaine des télé-applications, les données traitées sont des données non locales. Dans ce cadre, utiliser un ensemble d'intermédiaires, assimilés au concept de proxy, pour réaliser l'adaptation pendant la transmission nous semble être la démarche la plus appropriée. 1 Pervasif Du latin "pervadere" = aller de toute part. En anglais, cet adjectif synonyme d'ubiquitous signie partout. Depuis quelques années, il est repris en français, via l'anglais avec son sens latin.

24 Introduction Objectifs Le rapprochement de l'adaptabilité et des applications distribuées nous a conduit à introduire le concept d'adaptation globale. Il s'agit d'adapter les données en tenant compte de l'ensemble des paramètres impliqués par la multiplicité des utilisateurs. Cela étend la notion de sensibilité au contexte puisque la transmission de données entre plusieurs entités (utilisateurs par exemple) est prise en compte. Le principal but de cette thèse est de concevoir une plate-forme capable de réaliser l'adaptation de données globalement. Nous avons baptisé cette plateforme Appat (Adaptation Proxies PlATform). Elle inclut les mécanismes liés à la réalisation de l'adaptation de manière dynamique, distribuée et globale. Dans un souci constant d'intégration, Appat fonctionne comme un bus d'échange de données : les utilisateurs d'applications utilisant la plate-forme font abstraction de tout le fonctionnement de celle-ci, ils sont simplement connectés à Appat et lui soumettent leurs requêtes d'échange de données. Contributions de la thèse A travers le concept général d'adaptabilité et de ses divers aspects, nous avons développé les points suivants. Identication des besoins d'adapter les données transmises Le concept d'hétérogénéité est omniprésent. Il concerne les réseaux, terminaux et applications actuelles et nous a conduit à examiner ce domaine en détail. Cela nous a permis de conforter notre approche basée sur l'adaptabilité. De plus, les aspects liés à l'utilisateur s'étant développés ces dernières années, nous les avons également pris en compte dans notre analyse. Cela nous permet de dresser les besoins et les contraintes de l'adaptation de données, que nous répartissons selon 3 niveaux : les réseaux, les terminaux, les utilisateurs. Analyse de l'existant L'adaptabilité implique de nombreux paramètres qu'il est nécessaire de consi-

Introduction 25 dérer. Parmi ceux-ci, nous trouvons l'ensemble des mécanismes d'adaptation, le sens de l'adaptation et enn la localisation de l'adaptation. Ce dernier point est essentiel pour la conception de notre plate-forme car la réalisation de l'adaptation ne doit pas être coûteuse du point de vue des clients. Pour cela, nous choisissons d'utiliser la distribution de cette tâche. Ce qui nous conduit à analyser et à discuter les plates-formes d'adaptation existantes, dont le principe s'apparente à notre approche. Dénition de l'adaptation globale L'adaptation globale représente un concept innovant, qui consiste à adapter les données en fonction de divers paramètres, impliqués par la multiplicité des utilisateurs et de leurs échanges. Nous la dénissons en détails en exposant ses avantages et en délimitant le cadre de sa réalisation. Nous exposons également nos motivations à concevoir une plate-forme d'adaptation. Conception de la plate-forme Appat La plate-forme d'adaptation Appat prend en charge la réalisation de l'adaptation de données transmises. Nous présentons et dénissons les acteurs impliqués dans ce schéma. Nous formalisons également les informations sur lesquelles se base Appat pour eectuer les congurations des transmissions prises en charge. Le fonctionnement d'appat ainsi que les mécanismes de gestion de la plate-forme et de réalisation de l'adaptation sont également présentés. Réalisation de tests et évaluation Des tests, regroupés dans deux scénarios, permettent de valider notre approche et en particulier la réalisation de l'adaptation globale. Le premier scénario concerne une application de visioconférence multi-parties : ce type d'application est courant dans les télé-applications, notamment les applications collaboratives. Le deuxième scénario traite d'interactions client-serveur web, ce qui permet de valider l'intégration d'appat aux applications existantes. Les tests eectués permettent également d'évaluer l'apport de l'adaptation réalisée dynamiquement et de façon distribuée ainsi que les coûts engendrés par l'adaptation. Intégration de la plate-forme à TeNeCi Une plate-forme de télé-neurologie appelée TeNeCi est actuellement en cours

26 Introduction de conception dans le cadre d'un projet Interreg III 2, sur lequel collabore notre équipe. Nous validons l'apport d'appat en l'intégrant à cette plate-forme. L'adaptation des données échangées par les participants lors des sessions de télédiagnostic est prise en charge par Appat. Plan du mémoire de thèse Le premier chapitre est consacré à un état de l'art sur l'adaptabilité. Nous commençons par identier les problèmes liés à l'hétérogénéité des réseaux, des terminaux et des paramètres des utilisateurs. Nous examinons également les mécanismes d'adaptation et les critères liés à l'adaptabilité. Nous présentons les plates-formes basées sur des Proxies d'adaptation (PAs), avant d'exposer nos motivations pour la conception d'une nouvelle plate-forme. Dans le chapitre 2, nous présentons la plate-forme baptisée Appat. Après avoir exposé son architecture, nous dénissons les acteurs impliqués : l'annuaire distribué utilisé pour partager les informations au sein de la plate-forme, les PAs, les sites et enn les transmissions. La formalisation des informations concernant ces acteurs est également eectuée dans ce chapitre. Le chapitre 3 décrit la prise en charge de l'adaptation par Appat. Nous étudions ainsi les étapes de la prise en charge d'une transmission, depuis la requête, jusqu'à son arrêt, en passant par la conguration, la distribution de l'adaptation et le démarrage de la transmission. Une étude des composants de la partie adaptation des PAs est réalisée. Des exemples de prise en charge de diérents types de transmissions terminent ce chapitre. Dans le chapitre 4, nous montrons la faisabilité de la réalisation de l'adaptation globale, nous évaluons l'apport de l'adaptation dynamique et distribuée ainsi que les coûts de l'intégration d'appat sur les délais de transmission. Pour cela, des tests basés sur deux types de scénario d'utilisation réalistes sont eectués. Le chapitre 5 détaille l'intégration d'appat à la plate-forme de télé-neurologie TeNeCi, projet Interreg III présenté dans ce chapitre. Nous terminons cette thèse par une conclusion, en rappelant les principales contributions et en présentant nos perspectives. 2 Interreg III est l'initiative communautaire du Fonds européen de développement régional (FEDER) en faveur de la coopération entre régions de l'union européenne pour la période 2000-2006

CHAPITRE1 État de l'art sur l'adaptabilité 1.1 Introduction Internet et le monde des télécommunications ont connu une telle expansion qu'ils ont engendré un développement rapide d'un très grand nombre de réseaux, de terminaux et d'applications hétérogènes. Cette diversité et cette hétérogénéité sont visibles en termes de caractéristiques. Eric Tanter et al. [Tan01] parlent d'ubiquitous computing, pour dénir ce monde électronique hétérogène et Kimmo Raatikainen et al. [Raa99] de anytime-anywhere-anyhow. Les nouvelles applications fonctionnent aujourd'hui sur des PC multimédias, des PC portables, des PDA voire des téléphones portables, qui bénécient de caractéristiques très diérentes (ressources, écran, mode d'interaction, connexions...). Il en va de même pour les réseaux avec Fast-Ethernet, WI-FI, GPRS..., qui bénécient aussi de caractéristiques diérentes (bande passante, taux d'erreur, gigue...). Cependant outre leur complexité, cette diversité de réseaux et de terminaux représente un immense intérêt dans les domaines applicatifs où la collaboration des individus rend le travail plus ecace. On peut par exemple citer tout ce qui concerne la télémédecine où des spécialistes éloignés donnent leur diagnostic en fonction de données complexes qui leur sont transmises dans des délais très courts (cf. chapitre 5). Il est donc nécessaire de trouver des solutions pour assurer une compatibilité entre les diérents composants du système an que les données soient exploitables par les utilisateurs et qu'ainsi la communication ou la transmission d'informations puisse avoir lieu de façon optimale. Nous proposons l'adaptation des données, en tenant compte des caractéristiques des terminaux et du réseau, mais également des préférences des utilisateurs. Ainsi une grande image peut être achée sur un PDA dans de bonnes conditions et un ux vidéo peut être dégradé pour respecter un délai acceptable. Une diculté supplémentaire réside

28 CHAPITRE 1. ÉTAT DE L'ART SUR L'ADAPTABILITÉ dans le dynamisme du système. La bande passante peut évoluer, de même que la charge du processeur, la complexité de l'image, le nombre d'utilisateurs... L'état de l'art que nous présentons dans cette thèse a pour but de présenter l'adaptabilité, avec ses besoins, ses contraintes, ses critères et ses mécanismes. La première section aborde les besoins qui conduisent à la nécessité d'adapter. Ensuite, nous étudions les mécanismes permettant l'adaptation et ses critères. Enn nous présentons des applications d'adaptation existantes, notamment des plates-formes à base d'un ou plusieurs proxies. 1.2 Présentation de l'adaptabilité On peut dénir l'adaptabilité comme la capacité d'harmoniser l'application avec son environnement [Riv00]. Nous étendons cette dénition aux données échangées, puisque les données doivent elles aussi être adaptées à leur environnement. C'est ce point que nous allons développer dans ce mémoire. Les données sont soit échangées entre les participants d'une session de collaboration (point à point ou point à multipoints, mode push), soit des données provenant d'un serveur (schéma plus classique, mode pull). Dans tous ces cas, il s'agit indiéremment de données discrètes (texte, images, objets de tableaux blancs...) ou de données continues (audio, vidéo) provenant d'un émetteur et transmises à un ou plusieurs récepteurs. Suivant les réseaux et les terminaux de réception, les données devront être adaptées pour permettre un traitement ecace. 1.3 Problèmes liés à l'hétérogénéité Dernièrement, les réseaux, les terminaux, les applications ainsi que les besoins des utilisateurs se sont diversiés et ont entraîné une hétérogénéité importante. Il est aujourd'hui nécessaire de prendre en compte ces critères lors des échanges de données, an que tous les utilisateurs naux puissent les exploiter. Dans cette partie, nous déterminons trois niveaux à prendre en compte dans l'adaptabilité qui sont le réseau, les terminaux et les utilisateurs.

1.3 Problèmes liés à l'hétérogénéité 29 1.3.1 Adaptation au réseau Parmi les diérents types de réseaux existants, les caractéristiques qui diffèrent sont les suivantes : bande passante, topologie, délai, gigue, taux d'erreurs. Comme pour les terminaux, de nouveaux supports réseau ne cessent d'apparaître et viennent compléter l'existant. Actuellement, les utilisateurs, nomades ou non, utilisent leurs applications via des réseaux Ethernet haut débit, des réseaux sans l du type WI-FI (802.11b), Bluetooth ou encore des connexions téléphoniques, ISDN, ADSL, infrarouge, satellite, GPRS, GSM et bientôt UMTS. La connaissance du type de réseau utilisé ne permet pas forcément d'obtenir les informations sur toutes les caractéristiques mentionnées ci-dessus. Premièrement, parce que la plupart du temps, elles ne sont que théoriques, et deuxièmement, les ressources réseau peuvent être partagées. De plus, tous ces réseaux étant interconnectés, les utilisateurs peuvent dans une communication utiliser plusieurs types de réseau et non un seul [Yar00a]. Les ux de données peuvent traverser des réseaux aux caractéristiques spéci- ques sur lesquels les protocoles classiques utilisés ne sont pas ecaces, comme par exemple les réseaux sans l. En eet, dans le cas de réseaux sans-l de type Wi ou téléphonie 2.5G (GPRS) et 3G (UMTS et FOMA), les bandes passantes sont partagées entre tous les utilisateurs du point d'accès, ce qui implique un grande uctuation des ressources réseaux disponibles par utilisateur. Caractéristiques subissant des variations Il est nécessaire d'adapter les ux de données aux conditions du réseau. En eet, un nombre important de caractéristiques des réseaux sont sujettes à des variations : le débit, le délai, la gigue, le taux d'erreurs par exemple. Ces caractéristiques varient en fonction de l'utilisation globale des utilisateurs qui partagent les ressources réseau [Nob00]. Car dans la plupart des réseaux, la réservation de ressources est impossible (non garantir la bande passante est un principe de base d'ip). De plus, même en bénéciant d'un contrôle sur les ressources réseau et proposer ainsi une qualité de service (QoS), la bande passante garantie peut être modiée volontairement, après négociation par exemple. Ce qui implique dans ce cas aussi une adaptation. En outre, garantir un certain niveau de QoS pour un ou tous les ux de données de l'application nécessite le contrôle des éléments réseau traversés par ces ux, ce qui est actuellement impossible sur les réseaux

30 CHAPITRE 1. ÉTAT DE L'ART SUR L'ADAPTABILITÉ IP. Enn, certains réseaux, comme les réseaux sans l sont sensibles aux conditions environnantes et aux conditions d'utilisation. La distance entre l'utilisateur et une borne de connexion peut varier au cours d'un déplacement par exemple, entraînant une baisse de signal, une augmentation des pertes et donc une augmentation du taux d'erreurs et une diminution du débit. 1.3.2 Adaptation aux terminaux Il existe une telle hétérogénéité dans les terminaux actuels, que leurs caractéristiques ne permettent pas à une application de s'exécuter de manière similaire sur chacun d'eux. Au sein des plates-formes coopératives actuelles, nous trouvons aussi bien des ordinateurs de bureau que des assistants personnels (Fig. 1.1). An que l'application s'exécute correctement sur chaque type de terminal et que les données transmises soient exploitables, il est nécessaire de tenir compte des caractéristiques du terminal. Elles peuvent être matérielles comme la taille de l'écran, le mode d'interaction (clavier, souris, stylet...). Ainsi, une application ne peut s'exécuter de la même manière sur un PC multimédia que sur un PDA par exemple : la taille de l'écran étant diérente et le clavier virtuel sur le PDA, il est nécessaire d'adapter l'interface utilisateur à ce terminal. Lorsque les données transmises vers ce terminal ne correspondent pas à ses caractéristiques (par exemple, un ux vidéo nécessitant un traitement trop lourd ou un ux vidéo dont la dénition dépasse la taille de l'écran), elles doivent être adaptées, ou la transmission ne peut pas avoir lieu. Fig. 1.1 Diérents types de terminaux actuels D'autre part, le terminal a des caractéristiques qui sont aussi logicielles comme les applications, les codecs, les classes... Par exemple, un ux vidéo

1.3 Problèmes liés à l'hétérogénéité 31 transmis vers un terminal ne bénéciant pas du codec approprié ne pourra pas être lu. Une adaptation du ux sera nécessaire pour que la transmission ait lieu. Caractéristiques subissant des variations Il est nécessaire de prendre en compte la charge des terminaux (CPU, mémoire). Notamment lorsqu'il s'agit de transmissions de ux multimédias qui sont gourmandes en ressources. En eet, l'utilisateur peut disposer de plusieurs transmissions vidéo ou audio, en tant qu'émetteur ou en tant que récepteur. De plus, au cours d'une session de travail collaboratif, il peut démarrer de nouvelles transmissions ou en terminer certaines. Ceci entraînant soit une libération de ressources, soit au contraire un besoin en ressources à satisfaire pour eectuer la transmission. En outre, les systèmes d'exploitation actuels étant multitâches, il ne faut pas oublier que d'autres applications sont en cours d'exécution, chacune ayant une consommation des ressources qui peut aussi être variable [Nob97]. De plus, l'utilisateur peut démarrer ou arrêter des applications, ce qui fait varier la charge de son terminal. De façon plus rare, d'autres caractéristiques liées au terminal peuvent aussi subir des variations, comme la présence de périphériques d'entrées/sorties multimédia qui peuvent être ajoutées au terminal ou au contraire retirées pendant la session de travail. De la même manière, le mode d'achage peut être variable si un écran optionnel est branché ou débranché, comme le mode d'interaction peut l'être si l'on branche ou débranche un clavier, une souris ou un autre périphérique. Concernant les caractéristiques logicielles, la disponibilité de code nécessaire ne varie généralement pas. S'il y a une variation, cela provient des applications (importation de codecs, plug-ins...) et c'est principalement pour importer du code plutôt que d'en désinstaller. 1.3.3 Adaptation à l'utilisateur Si les contraintes liées aux matériels utilisés (terminaux et réseaux) nous obligeant à adapter sont des contraintes techniques, il existe aussi une contrainte à prendre en compte qui est l'utilisateur [Zha00, Gar99]. En eet, c'est celui-ci

32 CHAPITRE 1. ÉTAT DE L'ART SUR L'ADAPTABILITÉ qui exploitera les données et il est donc important de prendre en compte ses besoins et ses préférences [Fou02]. Par exemple, un PDA disposant d'un écran ayant une résolution de 240 320 ne permet pas, à priori, l'achage d'une image de grande taille (par exemple 1024 768). Il existe dans ce cas plusieurs types d'adaptation comme la réduction de la taille de l'image, ou l'achage d'une partie seulement de l'image et c'est donc à l'utilisateur d'intervenir dans ce choix. Caractéristiques subissant des variations Les préférences et les besoins des utilisateurs varient au cours de la session de travail collaboratif [Lit00a]. Un utilisateur peut par exemple démarrer de nouvelles transmissions audio ou vidéo, ou en arrêter. Il peut aussi changer les paramètres des transmissions (taille des images, nombre de couleurs, uidité, qualité du son...). En ce qui concerne le reste de la session de travail collaboratif, il peut vouloir travailler sur une partie d'un document plutôt que l'ensemble, ou encore modier les paramètres des outils ou de l'application, ce qui peut avoir un impact sur l'ensemble de la session. La prise en compte de ces changements doit être envisagée car l'application doit constituer un outil favorisant collaboration entre participants et la production d'un résultat. Mobilité Les équipements proposés aujourd'hui favorisent la mobilité et le nomadisme des utilisateurs [CAM00]. Aussi, la connectivité des utilisateurs peut varier entre forte connectivité, faible connectivité et périodes de déconnection, plus ou moins longues [Lit00a]. La mobilité des utilisateurs est donc une caractéristique à prendre en compte dans l'adaptation [Ban02]. Cependant, nous ne tiendrons pas compte de la mobilité des utilisateurs dans la version actuelle d'appat. 1.3.4 Conclusion Suite à cet état de l'art qui met en évidence trois niveaux dans l'adaptabilité, nous proposons dans la gure 1.2 une classication des caractéristiques à prendre en compte lors de l'adaptation de données.

1.4 Les mécanismes de l'adaptation 33 Utilisateur Terminal Réseau Préférences Rôle Priorité Compétences Ressources E/S Logiciel Type Bande passante Taux d'erreurs Gigue Langue Mécanismes d'adapt. CPU Mémoire Ecran Mode d'interaction Son Applications Codecs Librairies/classes Fig. 1.2 Classication des caractéristiques à prendre en compte lors de l'adaptation de données Aux trois niveaux (réseau, terminal, utilisateur), nous avons vu qu'il existait des caractéristiques qui peuvent être sujettes à des variations durant le temps d'exécution de l'application (en italique sur la gure), et qu'il est donc nécessaire d'adapter dynamiquement [BHA98]. La section suivante présente les mécanismes d'adaptation à mettre en oeuvre pour adapter les données. 1.4 Les mécanismes de l'adaptation Adapter des données pour en permettre une exploitation optimale sur le terminal récepteur implique l'utilisation de techniques d'adaptation et par conséquent la modication de ces données. Ceci est réalisé à la volée et le choix de mettre en place ces mécanismes est important et dépend à chaque fois des niveaux que nous avons déterminés plus haut : caractéristiques et charge du réseau, caractéristiques et charge des terminaux et paramètres des utilisateurs. Nous étudions dans cette partie les mécanismes d'adaptation concernant la modication des données (transcodage), le mixage de plusieurs ux de données ainsi que les solutions favorisant l'adaptation.

34 CHAPITRE 1. ÉTAT DE L'ART SUR L'ADAPTABILITÉ 1.4.1 Transcodage des données Le transcodage [Ami95] est un procédé très utilisé dans le cadre de l'adaptation. Il existe deux techniques de transcodage. Une première technique consiste à changer le média des données [Zha00, Pha02]. Cette technique est eectuée par un transcodeur qui extrait le contenu sémantique des données qu'il reçoit et produit de nouvelles données avec le même contenu sémantique sous une autre forme [Fox98]. "J'utilise un algorithme de reconnaissance vocale" Fig. 1.3 Changement de média - Audio Texte L'exemple présenté dans la gure 1.3 consiste à transformer un ux audio en une succession de messages de type texte. Ceci est réalisé grâce à un algorithme de reconnaissance vocale [Rab93]. Cette technique est nécessaire lorsque le terminal ne peut pas lire le ux audio, soit parce qu'il ne bénécie pas des ressources nécessaires, soit parce qu'il ne bénécie pas d'application de lecture de ux audio par exemple. Fig. 1.4 Changement de média - Vidéo Image xe Un autre exemple de changement de média est présenté dans la gure 1.4. Il s'agit de n'émettre qu'une image xe plutôt qu'un ux vidéo. Les raisons de ce changement de média sont les mêmes que celles citées ci-dessus. Une deuxième technique de transcodage consiste à changer le format des données [Mah02, Kal02]. Ceci permet de conserver le contenu d'un média identique en utilisant un format plus approprié. Pour chaque type de média, il existe

1.4 Les mécanismes de l'adaptation 35 un nombre important de formats diérents, mais tous ne conviennent pas à la transmission en question ni au terminal récepteur ou à l'utilisateur. CAliF Multimedia - Index Sommaire Plateforme Services Applications Publications LIFC IUP GMI [calif-anim.gif] Laboratoire Informatique de l'universite de Franche-Comte 16, route de Gray 25030 BESANCON CEDEX FRANCE Voice : +33 3.81.66.64.56 (or 57) Fax : +33 3.81.66.64.50 Equipe Systemes Distribues Axe Travail cooperatif Guyennet [atsign.gif] lifc.univ-fcomte.fr Garcia [atsign.gif] lifc.univ-fcomte.fr Lapayre [atsign.gif] lifc.univ-fcomte.fr Tréhel [atsign.gif] lifc.univ-fcomte.fr Renard [atsign.gif] lifc.univ-fcomte.fr Fig. 1.5 Changement de format - HTML Texte brut La gure 1.5 présente un exemple de changement de format. Un texte brut est produit à partir d'une page html (la syntaxe html est omise). Le média est identique mais le format est modié. Dans cet exemple, il s'agit de données discrètes, en l'occurrence un document texte, mais cela concerne également tout type de données. Le changement de format peut être nécessaire lorsque le récepteur ne bénécie pas des ressources, de l'application ou des codecs requis. Ces deux techniques impliquent un coût lors de leur réalisation mais permettent de diminuer fortement la quantité de données traitées par le récepteur. Cela entraîne d'une part une simplication de traitement et d'autre part un allégement de la charge du réseau sous-jacent ainsi que celle du récepteur, comme nous le constaterons dans le chapitre 4. Modications des caractéristiques des données Le transcodage permet aussi de modier les caractéristiques mêmes des données [Zha00, Fox98, BHA98, Pha02]. En eet, une fois les données décodées, il est possible d'appliquer un ltre d'adaptation avant de les réencoder an de les modier (Fig. 1.6). La modication concerne les caractéristiques qui sont spéciques aux données. Par exemple, cela peut être une résolution, un taux de compression, un nombre de couleurs ou une fréquence de rafraîchissement s'il s'agit d'une vidéo [Lei03]. données originales Décodeur Filtre Encodeur données adaptées Fig. 1.6 Filtre utilisé lors d'un transcodage

36 CHAPITRE 1. ÉTAT DE L'ART SUR L'ADAPTABILITÉ L'avantage de cette solution est que les données peuvent conserver un format identique à celui d'origine, ce qui est un atout pour une adaptation transparente. Cependant, cette solution implique la nécessité de connaître le format des données utilisées et de savoir comment modier les caractéristiques. Comme pour le transcodage, modier les caractéristiques des données permet de réduire la quantité des données, an de simplier leur traitement et diminuer la charge requise, au niveau du réseau et au niveau du terminal récepteur. 320 x 240 256 couleurs 76 Ko 160 x 120 16 niveaux de gris 9,4 Ko Fig. 1.7 Modication des caractéristiques d'une image La gure 1.7 présente un exemple de modication des caractéristiques d'une image. Cette dernière subit deux modications : une réduction de sa dénition et une réduction du nombre de couleurs. La taille de l'image est ainsi réduite de 76 Ko à 9,4 Ko. Transcodage vidéo Les ux vidéo impliquent un traitement plus complexe que des médias discrets, et une quantité de données à traiter plus importante que des ux audio. Ces particularités ont conduit à plusieurs techniques de transcodage vidéo, sur lesquelles s'appuient diérentes architectures proposées dans la littérature [Ami95, Sei98, BHA98, Lei03, Tus03]. La technique la plus directe est appelée Cascaded Pixel Domain Transcoder (CPDT) [You00]. Un encodeur standard est associé à un décodeur standard. Cette architecture est exible car la vidéo compressée est d'abord décodée en pixels bruts, permettant ainsi des traitements additionnels.

1.4 Les mécanismes de l'adaptation 37 L'autre extrême est une architecture appelée Open-Loop Transcoder (OLT) [Sun95]. Le ux vidéo en entrée est d'abord décodé partiellement, jusqu'au niveau des blocs DCT (groupes de coecients liés aux points d'une image subissant une transformation DCT (Discrete Cosine Transform)). Le débit peut alors être aisément ajusté en éliminant les coecients des hautes fréquences ou en requantiant tous les coecients avec un plus large niveau de quantication. Cependant, cette solution entraîne des erreurs, lorsque les images de référence ne correspondent pas, entre l'encodeur et le décodeur. Une solution hybride consiste à requantier les coecients DCT (mais en conservant les erreurs de requantication dans un tampon) et à les repasser au mécanisme de quantication de façon à les corriger. Un transcodage eectué uniquement au niveau de la DCT est un DCT-Domain Transcoding (DDT) [Ass98]. Applications des techniques de transcodage vidéo Dans cette partie, nous détaillons les applications et ltres autorisés par le transcodage. Adaptation du débit L'adaptation du débit est l'application la plus importante issue du transcodage. L'idée d'adapter le débit d'un ux vidéo a été initiée par les applications transmettant des ux vidéo pré-encodés sur des réseaux hétérogènes. La réduction du débit d'un ux est nécessaire lorsque la transmission de celui-ci engage un client connecté à un réseau aux capacités réduites, en matière de bande passante. données à transmettre Encodeur Réseau Décodeur données reçues Statistiques Fig. 1.8 Adaptation du débit autorisée par le transcodage Dans certaines applications, comme la vidéo à la demande par exemple, où le ux est pré-encodé pour une transmission ultérieure, les caractéristiques

38 CHAPITRE 1. ÉTAT DE L'ART SUR L'ADAPTABILITÉ du réseau qui sera utilisé ne sont pas connues. Avec le transcodage, le débit des vidéos pré-encodées peut être adapté dynamiquement selon la quantité de bande passante disponible et les variations qui peuvent survenir [Wal97] (Fig. 1.8). Dans la plupart des cas, une vidéo encodée avec un haut débit et des qualités visuelles satisfaisantes est convertie en une vidéo avec un bas débit et des qualités visuelles dégradées [Sei98]. Conversion de la dénition de l'image La réduction de la dénition d'une vidéo est importante puisque les terminaux de poche les plus récents sont caractérisés par des écrans de taille limitée. En insérant un ltre de réduction de la résolution au transcodeur, la dénition de la vidéo transmise peut être réduite [Kwo04] (Fig. 1.9). Pour réaliser cette opération, les vecteurs de mouvement (motion vectors) de la vidéo ne peuvent pas être réutilisés directement, mais doivent être regénérés et réduits. Basés sur les nouveaux vecteurs de mouvement, les résidus de prédiction sont recalculés et compressés. Fig. 1.9 Exemple de réduction de la dénition d'un ux vidéo Conversion de la fréquence de rafraîchissement Pour transcoder un ux vidéo vers un réseau à bas débit, comme un réseau sans l, on utilise un ratio de transcodage important. Ce type de ratio peut rendre la qualité du ux vidéo inacceptable lorsque le ux vidéo est transcodé avec la même fréquence. Convertir la fréquence de rafraîchissement, ou supprimer des images, est souvent un moyen ecace de réduire le débit, tout en permettant une allocation plus importante aux images restantes. Cette opération entraîne le maintien d'une qualité satisfaisante. De plus, convertir la fréquence