Projet 60 : E-Bike, le vélo communicant

Transcription

1 Luca ALESSI Diana CIURARU HENDRIK Hamed KY Omar ZAMANI Projet 60 : E-Bike, le vélo communicant Rapport technique Version du 22/06/2012 Destiné à : Partenaire extérieur (Odysseus Aventures) : Hélène MULVET Simon LEBAYON Samuel TIERCELIN Encadrants techniques : Nicolas MONTAVONT Joël TRUBUIL

2 Sommaire 1. LE PROJET E-BIKE CONTEXTE : L'ODYSSEE CELTIQUE FINALITE : UNE COUVERTURE WEB IMMERSIVE DE L'ODYSSEE CELTIQUE OBJECTIF TECHNIQUE : UN DISPOSITIF DE STREAMING VIDEO EMBARQUE SUR VELO PROBLEMATIQUES TECHNIQUES DU PROJET CAPTURE VIDEO DES TRAJETS INDIVIDUELS DES VELOS LA RETRANSMISSION EN TEMPS-REEL LA CONNECTIVITE DANS UN MILIEU FORESTIER LA CONNECTIVITE DANS UN CONTEXTE DE MOBILITE ARCHITECTURE TECHNIQUE DU SYSTEME DESCRIPTION DES ARCHITECTURES ENVISAGEES Architecture générale Architecture sans routeur mobile Architecture avec routeur mobile ETUDE DES ARCHITECTURES ENVISAGEES Etude de l'architecture sans routeur mobile Etude de l'architecture avec routeur mobile ARCHITECTURE RETENUE DEVELOPPEMENT DEVELOPPEMENT DES APPLICATIONS DE STREAMING Choix des technologies de développement Logique opérationnelle des applications Développement de l'application Android de streaming Développement de l application côté serveur Développement du client web de streaming DEVELOPPEMENT DU ROUTEUR MOBILE Description matérielle du routeur Installation et mise à jour du système Configuration des scripts La gestion de la mobilité Finalisation et déploiement du routeur MAQUETTE DE TEST DESCRIPTION DE LA MAQUETTE SCENARIO DE TEST RESULTATS/OBSERVATIONS CONCLUSION Télécom Bretagne 1

3 ANNEXE 1 - BILAN DE GESTION A1.1. DIAGRAMME WBS A1.2. DIAGRAMME GANTT A1.3. GESTION DES RISQUES A1.4. GESTION DU BUDGET A1.5. DIFFICULTES RENCONTREES ANNEXE 2 - CONFIGURATION DU ROUTEUR MOBILE A2.1. CONFIGURATION DE LA MACHINE HOTE A Configuration du serveur dhcp A Configuration du serveur nfs A Configuration du firewall pour nat dynamique A2.2. FICHIER DE CONFIGURATION «EBIKE-INSTALLING.PL» A2.3. FICHIER DE CONFIGURATION «EBIKE-NETWORKING.PL» ANNEXE 3 EQUIPEMENTS DIVERS A3.1. SUPPORT DE FIXATION DU SMARTPHONE A3.2. BATTERIE D ALIMENTATION EXTERNE DU SMARTPHONE ET DU ROUTEUR BIBLIOGRAPHIE Télécom Bretagne 2

4 INTRODUCTION Odysseus Aventures est une association dont l une des ambitions est d exploiter le potentiel offert par les nouvelles technologies d information et de communication pour promouvoir l esprit de collaboration. Elle organise chaque année un raid aventure à travers la forêt de Brocéliande baptisé l Odyssée Celtique. Il s agit d une compétition culturelle et sportive pendant laquelle les candidats présents sur le terrain doivent faire équipe avec des participants distants afin de venir à bout des énigmes et des défis qui leur sont soumis. Ceci est rendu possible grâce à une plateforme web permettant aux internautes de suivre l événement en direct et d interagir avec les équipes participantes. En vue d enrichir l expérience qu elle procure aux participants distants, les organisateurs envisagent de retransmettre en direct sur cette plateforme et en vue subjective les épreuves cyclistes de la compétition. Ils nous ont alors confié la conception et la réalisation d un système de streaming embarqué capable de filmer et diffuser sur Internet le parcours de chaque vélo afin qu on puisse le visualiser depuis n importe quel ordinateur connecté à internet et disposant d un navigateur web. Le présent document présente l approche que nous avons adoptée pour concevoir ce système, les choix que nous avons effectués, le travail de développement réalisé ainsi que les résultats obtenus. Télécom Bretagne 3

5 1. LE PROJET E-BIKE 1.1 CONTEXTE : L'ODYSSEE CELTIQUE L'Odyssée Celtique est une compétition culturelle et sportive organisée par l'association Odysseus Aventures. Elle réunit chaque année des centaines d'étudiants à travers la France, dans le but de leur faire découvrir de manière ludique les richesses de la Bretagne et de les sensibiliser à ses enjeux. Cette compétition prend la forme d'un raid aventure au cours duquel les participants, répartis en plusieurs équipes représentant leurs écoles respectives, parcourent la forêt de Brocéliande en essayant de relever divers défis sportifs et intellectuels. Figure 1 : Photo de l édition 2006 de L Odyssée Celtique Ne perdant pas de vue son objectif, qui est de promouvoir l'esprit de collaboration autour du patrimoine breton en s'appuyant notamment sur les technologies numériques, l'association a mis en place une plateforme multimédia accessible via Internet et permettant non seulement de suivre l'événement en direct, mais aussi de prendre part à l'aventure, en venant en aide aux participants présents sur le terrain dans la résolution des énigmes qui leur sont soumises. Chaque année, les organisateurs cherchent à améliorer cette plateforme pour qu'elle puisse offrir l'expérience la plus immersive possible aux participants distants. Ceci donne vie à des projets innovants dont la réalisation est confiée à des étudiants de la région. 1.2 FINALITE : UNE COUVERTURE WEB IMMERSIVE DE L'ODYSSEE CELTIQUE Dans le but d'accroître la popularité de l'odyssée Celtique et d'améliorer l'expérience vécue par les participants distants, les organisateurs souhaitent dynamiser la couverture web de l'événement. Pour cela, ils envisagent de retransmettre la compétition en direct sur Internet, en se focalisant dans un premier temps sur les épreuves cyclistes. Cette couverture vidéo doit être exhaustive et dynamique : à un moment donné, l'internaute doit pouvoir suivre la progression du candidat de son choix parmi tous les candidats participants à l'aventure. En outre, le parcours à vélo des participants doit être retransmis en vue subjective pour une immersion totale. Avant de procéder à la mise en place de ce dispositif ambitieux, les organisateurs voudraient qu'une étude de faisabilité aboutissant au développement d'un système pilote soit réalisée. Télécom Bretagne 4

6 1.3 OBJECTIF TECHNIQUE : UN DISPOSITIF DE STREAMING VIDEO EMBARQUE SUR VELO L'objectif technique du projet est de concevoir un système de streaming capable de diffuser en direct sur Internet des flux vidéo issus de terminaux en mobilité. En l'occurrence, il s'agit de diffuser le contenu vidéo filmé par des smartphones embarqués sur les vélos des participants de l'odyssée Celtique. Ce contenu doit pouvoir être visualisé en temps-réel sur une interface web accessible depuis n'importe quel terminal connecté à internet et disposant d'un navigateur web. Le projet exige également de mettre au point un prototype fonctionnel du système. Celui-ci doit démontrer la possibilité d utiliser le système pour retransmettre le parcours à vélo d une équipe qui serait composée de deux participants. Pour ce faire, notre partenaire extérieur a mis à notre disposition, notamment grâce à son partenariat avec Orange, les moyens techniques suivants : - Deux smartphones sous Android : Un Samsung Galaxy S2 et un Motorola ATRIX. - Deux cartes SIM avec accès internet 3G. - Une clé 3G Huawei e398 - Un espace d'hébergement de type serveur sur Gandi. Nos encadrants techniques nous ont de leur côté fourni les équipements suivants : - Deux smartphones Samsung Galaxy S. - Un routeur mobile ALIX 2d2 - Une carte Flash Kingston 8 GB. Télécom Bretagne 5

7 2. PROBLEMATIQUES TECHNIQUES DU PROJET A partir du besoin exprimé par le partenaire extérieur et en considérant le contexte particulier du projet, nous avons identifié les principales problématiques techniques qui lui sont associées. 2.1 CAPTURE VIDEO DES TRAJETS INDIVIDUELS DES VELOS Pour pouvoir retransmettre les parcours à vélo des participants de l'odyssée Celtique, il faut évidemment que ces parcours soient filmés. Les organisateurs souhaitent qu'on puisse suivre le trajet individuel de chaque participant. Par conséquent, il faudra autant de dispositifs de capture vidéo que de participants. Le partenaire extérieur préconise à ce niveau l'utilisation de smartphones sous Android. Afin que le trajet soit retransmis en vue subjective, ces smartphones doivent être embarqués sur les vélos de sorte à ce que l'objectif de leurs caméras reste constamment orienté vers le sens de la marche. A cet effet, des supports de fixation sur vélo existent. Nous avons opté pour un support permettant de fixer le smartphone sur le guidon du vélo [1]. L'acquisition vidéo, qui sera accompagnée d'une émission du flux, est une opération très consommatrice en énergie. Pour garantir l'autonomie énergétique des smartphones pendant toute la durée du parcours, il faut prévoir une source d'alimentation autre que les batteries des téléphones. Les solutions possibles consistent à utiliser une dynamo ou bien une batterie externe. La solution à base de dynamo a l'avantage d'être écologique, cependant elle n'est pas très fiable car ce n'est pas une source d'énergie régulière. Nous avons donc décidé d'utiliser des batteries externes [2]. Une fois branché au smartphone, la batterie externe sera sa source d'énergie par défaut jusqu'à son épuisement. Ensuite la batterie interne du smartphone prendra le relai. Pour récapituler, l'acquisition vidéo des trajets individuels des participants fera appel à : - Un smartphone embarqué sur chaque vélo à l aide d un support de fixation sur guidon. - Une batterie externe pour chaque smartphone boostant son autonomie énergétique. 2.2 LA RETRANSMISSION EN TEMPS-REEL Le contenu vidéo filmé par les smartphones embarqués doit être retransmis instantanément sur le web. Pour ce faire, il faut qu'il soit récupéré, diffusé et lu sous la forme d'un flux continu au fur et à mesure qu'il est capturé. Ce mode de transmission de données multimédia s'appelle le streaming. Il s'oppose au téléchargement dans la mesure où il ne nécessite pas que le destinataire des données les charge intégralement sur le disque de sa machine avant de pouvoir les visionner. En effet, en streaming les données sont lues à la volée depuis une mémoire tampon et en sont supprimés après lecture. Les étapes clés de la diffusion d'un contenu vidéo en streaming sont [3] : - Acquisition : Le contenu vidéo capturé par l'équipement de prise de vue est récupéré sous forme de flux. - Encodage : Le flux est compressé à l'aide d'un codeur et mis dans un certain format. Il faut veiller à ce que le format d'encodage choisi puisse être décodé par le destinataire. - Emission : Après compression, le flux est découpé en paquets qui sont envoyés vers un serveur de streaming. - Diffusion : Le serveur de streaming achemine le flux vers les clients désirant le recevoir. - Lecture : les clients réceptionnent le flux, le décodent et le visualisent à l'aide d'un lecteur multimédia. Le schéma[4] de la figure 2 illustre l'architecture les mettant en œuvre. Télécom Bretagne 6

8 Source vidéo Données vidéo brutes Acquisition Encodage Emission Flux vidéo Flux vidéo Réseau IP Flux vidéo Serveur de streaming Terminal de visualisation équipé d un lecteur multimédia Figure 2 : Architecture de mise en œuvre d un dispositif de streaming de contenu temps-réel 2.3 LA CONNECTIVITE DANS UN MILIEU FORESTIER Dans un milieu forestier comme celui où se déroulera l'odyssée celtique, les seules interfaces réseau envisageables sont les interfaces sans-fil Wifi et 3G. Si la connectivité 3G peut-être à priori considérée comme disponible en tout point de la forêt du fait de sa large couverture, il n en est pas de même pour le Wifi dont la portée est bien plus limitée. De plus, la densité des points d'accès Wifi implantés en forêt de Brocéliande est très faible d'après le partenaire extérieur. Par conséquent le système devra privilégier la connectivité offerte par la 3G tout en prévoyant des mécanismes permettant aux terminaux mobiles de basculer vers le Wifi si un point d'accès est situé à proximité, le débit offert par cette interface étant plus élevé. 2.4 LA CONNECTIVITE DANS UN CONTEXTE DE MOBILITE En procédant au basculement évoqué ci-dessus, le terminal concerné changera de réseau. De manière générale, un terminal change de réseau quand son point d'ancrage au réseau IP change. Il est alors rattaché à un nouveau sous-réseau et obtient une nouvelle adresse IP. Ce phénomène est assez probable en situation de mobilité et peut mettre fin à un transfert de données, notamment dans le cas d'un streaming vidéo depuis un terminal mobile vers un serveur de streaming. Ce dernier voit en effet arriver, après que le terminal mobile ait changé d'adresse, des paquets avec une adresse auquel aucun contexte n'est associé et les rejette en conséquence. Il faut dans ce cas que le terminal mobile se reconnecte au serveur pour s'y créer un nouveau contexte associé à sa nouvelle adresse. Pour faire face à cette problématique de changement de réseau, des protocoles de gestion de mobilité ont été mis au point. Il s'agit de MobileIPv6 et NEMO (pour Network Mobility) [5]. Le premier gère la mobilité de nœuds mobiles individuels alors que le second s'attaque à la mobilité d'un réseau itinérant constitué d'un routeur auquel sont rattachés plusieurs nœuds. Dans les deux cas, le principe de fonctionnement reste le même. A un instant donné, l'équipement mobile possède deux adresses : - Une adresse permanente qui concorde avec l'adresse qu'il avait dans le sous-réseau où il se trouvait initialement aussi appelé réseau-mère. - Une adresse courante qui correspond à son adresse dans le sous-réseau auquel il est rattaché à l'instant considéré. Dans le réseau-mère, un équipement nommé agent-mère mémorise dans une table la correspondance entre les deux adresses. C'est par lui que transite les paquets échangés entre l'équipement mobile et l'un de ses correspondants. Si on reprend le scénario d'un terminal mobile diffusant un flux vers un serveur de streaming, l'agent-mère traitera ces paquets en remplaçant leur adresse source, qui est l'adresse courante du terminal mobile, par l'adresse permanente de celui-ci. Le changement d'adresse sera ainsi complètement transparent pour le serveur et la connexion sera maintenue. Télécom Bretagne 7

9 3. ARCHITECTURE TECHNIQUE DU SYSTEME Après avoir analysé les différentes problématiques techniques du projet et défini les solutions permettant d'y répondre, nous avons élaboré à partir de ces solutions l'architecture du système 3.1 DESCRIPTION DES ARCHITECTURES ENVISAGEES Nous avons identifié deux architectures possibles se différenciant par la façon de connecter les smartphones embarqués au réseau internet. Avant d'aborder les spécificités de chacune des deux architectures, nous présentons l'architecture générale qui leur est commune Architecture générale Le schéma de la figure 3 présente l'architecture permettant de retransmettre le parcours à vélo d'une seule équipe. Nous ne perdons pas en généralité car augmenter le nombre d'équipes ne change pas l'infrastructure du système. Nous émettons l'hypothèse que les participants d'une équipe restent groupés. Elle est justifiée d'après les organisateurs de l'odyssée Celtique. HA Figure 3 : Architecture générale du système Télécom Bretagne 8

10 Composants de l'architecture L architecture générale du système est constituée des éléments suivants : Le réseau mobile : Il est constitué des smartphones embarqués sur les vélos grâce à des supports de fixation et alimentés par des batteries externes. Selon l'architecture, ce réseau peut inclure ou non un routeur mobile. Une application de streaming est installée sur chaque smartphone. Elle récupère le flux vidéo capturé par la caméra du téléphone, l'encode et l'émet vers le serveur de streaming. Point d'accès wifi Il fait référence à l'un des points d'accès Wifi présents sur la forêt de Brocéliande. Quand il est à portée du réseau mobile, celui-ci le choisit comme point d'ancrage au réseau IP. Base station router Il désigne une des stations de base 3G du réseau Orange qui font aussi office de routeurs. Il correspond au point d'ancrage courant du réseau mobile à Internet quand il n'est pas à portée d'un point d'accès Wifi. Il est susceptible de changer et céder la place à une autre station de base 3G ou à un point d'accès Wifi compte tenu du l'itinérance du réseau mobile. Serveur web/serveur de streaming Le serveur de streaming intègre une application côté serveur qui récupère les flux issus du réseau mobile et les achemine vers les clients qui désirent les recevoir. Le serveur web quant à lui héberge le site internet sur lequel l'utilisateur final pourra visualiser les flux vidéo disponibles. Il est doté d'une base de données qui enregistre les informations d'authentification et les identifiants des flux en cours de transmission. Les deux serveurs communiquent avec une base de données. L'application côté serveur y stocke les informations d'authentification et les identifiants des flux diffusés. Le serveur web s'y connecte pour récupérer et afficher sur le site la liste des identifiants des flux disponibles. HA : Home agent (agent mère) C'est l'élément fondamental d'une architecture implémentant l'un des protocoles de gestion de mobilité MobileIPv6 et NEMO. Comme expliqué précédemment, son rôle est de tenir à jour une table faisant correspondre une adresse permanente de l'entité mobile (selon l'architecture, l'entité désigne soit chaque smartphone pris à part ou le routeur mobile) à son adresse courante. C'est par le Home Agent que transitent les paquets envoyés par cette entité au serveur de streaming. Il les décapsule et les ré-encapsule dans des paquets ayant comme adresse source l'adresse permanente de l'entité mobile. Le changement d'adresse est alors imperceptible par le serveur. Terminal de l'utilisateur final Il dispose d'un navigateur web permettant de se rendre sur le site hébergé sur le site web afin de consulter les flux disponibles et choisir le flux désiré. Le navigateur intègre un lecteur multimédia capable de réceptionner, décoder et lire ce flux. Télécom Bretagne 9

11 Protocoles utilisés Nous nous intéressons ici aux principaux protocoles de niveau applicatifs utilisés entre les différentes entités de la couche logicielle du système. HTTP Protocole de niveau application structurant la communication entre un serveur web et ses clients. Il s'appuie sur le protocole de transport TCP qui garantit une transmission fiable de bout en bout. RTP / RTMP RTP est utilisé pour le transfert de données multimédia en temps-réel. Il repose sur le protocole de transport UDP. UDP n'est pas un protocole de transport fiable : il n'y a pas de garantie de séquencement des paquets et ceux qui sont perdus ne sont pas retransmis. La perte de paquets, du moment qu elle reste sporadique, n est pas problématique quand il s agit de transmettre des données multimédia (la perte d'un échantillon vidéo n'est pas très gênante en pratique). On ne peut pas dire la même chose du déséquencement car l ordre dans lequel sont lus les échantillons est très important. Par conséquent, RTP met en œuvre des champs permettant de remettre les paquets dans l ordre et indiquant la position chronologique de chaque échantillon. RTMP est la variante propriétaire de RTP mise au point par Adobe (anciennement Macromedia). Il a la particularité d'utiliser TCP comme protocole de transport. Navigateur web HTTP Serveur web Lecteur multimédia RTP ou RTMP Application de streaming côté serveur RTP ou RTMP Application Android de streaming Figure 4 : Protocoles utilisés entre les différents composants de la couche logicielle Scénario de transmission de flux 1 Les applications de streaming installées sur les smartphones du réseau mobile se connectent au serveur de streaming et lui envoient les flux vidéo via le réseau Internet. L'interface réseau utilisée est la 3G par défaut ou le Wifi si un point d'accès est à portée du réseau mobile. 2 L'utilisateur final se connecte au serveur web à l'aide de son navigateur et sélectionne via une interface web le flux qu'il désire visualiser. L'identifiant du flux est alors passé en paramètre au lecteur de streaming intégré à cette interface. 3 Le lecteur multimédia intégré au navigateur de l utilisateur final se connecte à l'application côté serveur déployée au niveau du serveur de streaming. Il lui communique l'identifiant du flux en question et demande qu'il lui soit transmis. 4 - Le serveur de streaming achemine le flux demandé vers le lecteur de streaming. Télécom Bretagne 10

12 3.1.2 Architecture sans routeur mobile Dans cette architecture, on n'est plus en présence d'un ensemble de nœuds mobiles que d'un réseau mobile. Les smartphones n'appartiennent pas forcément au même sous-réseau. Chacun dispose de sa propre connexion 3G et gère sa connectivité de manière autonome en choisissant indépendamment des autres son point d'ancrage au réseau IP. Chaque smartphone gère lui-même son itinérance en implémentant un protocole de gestion de mobilité et met en œuvre des mécanismes lui permettant de basculer entre les interfaces Wifi et 3G Architecture avec routeur mobile Les paquets émis par les smartphones sont relayés par un routeur mobile. Celui-ci possède trois interfaces réseau : - Une interface Wifi faisant office de point d accès pour les smartphones et définissant un sousréseau auquel ils sont rattachés. - Une interface 3G lui permettant de se raccorder au réseau Internet via un base station router du réseau Orange. - Une deuxième interface Wifi lui permettant de se raccorder à Internet en se connectant au réseau Wifi défini par un point d'accès. Pour sortir vers le réseau Internet, les flux issus des smartphones arrivent sur la première interface Wifi puis sont redirigés vers l une des deux autres interfaces. Les mécanismes de gestion de mobilité et de basculement entre Wifi et 3G sont implémentés au niveau du routeur uniquement et sont entièrement transparents pour les smartphones. 3.2 ETUDE DES ARCHITECTURES ENVISAGEES La différence fondamentale entre les deux architectures envisagées se situe au niveau de la structure du réseau mobile. Cette différence n'a pas d'impact sur le fonctionnement du système au niveau applicatif. Elle a néanmoins une répercussion sur certains aspects de connectivité. Nous avons donc mené une étude pour savoir comment s'implémentent, pour chacune des deux architectures, les mécanismes permettant de gérer la mobilité et le changement d'interface réseau Etude de l'architecture sans routeur mobile Dans cette architecture, le basculement entre interfaces réseau est géré au niveau des smartphones qui disposent chacun d'une interface Wifi et d'une interface 3G. A ce propos, la politique par défaut adoptée par le système d'exploitation Android est de ne maintenir qu'une seule interface active à la fois. Pour pouvoir effectuer un basculement fluide d'une interface à une autre, il faudrait faire en sorte que les deux interfaces demeurent actives simultanément. A cet effet, les recherches que nous avons menées indiquent qu'il faut apporter des modifications au code source du système d'exploitation Android et plus particulièrement au module ConnectivityService [6]. Pour cela, il faut d'abord procéder à une sauvegarde des données du téléphone en les transférant vers un autre terminal, puis à un rooting du système d'exploitation, manipulation permettant de débrider le téléphone en déverrouillant toutes ses fonctionnalités mais annulant systématiquement la garantie du fabricant. Ensuite, on en vient aux modifications proprement dites. A ce niveau deux solutions existent : Télécom Bretagne 11

13 - La première opère au niveau de la méthode handlemessage de la classe Myhandler interne à la classe ConnectivityService. Elle consiste à l'empêcher de désactiver l'interface 3G quand une connexion Wifi est détectée. Une fois testée, nous constatons que cette solution provoque de manière aléatoire un arrêt brutal du système d'exploitation au démarrage du téléphone ou à l'activation de l'interface Wifi. Nous en déduisons qu'elle n'est pas stable. - La seconde consiste à inhiber les appels à la méthode teardown de la classe ConnectivityService, méthode responsable de la désactivation d'interfaces réseau. Si elle a le mérite de ne pas un arrêt brutal du système, cette solution ne permet de garder les deux interfaces actives que pendant un certain temps, au bout duquel l'une des deux est désactivée, probablement par un autre module que nous n'avons pas pu identifier. Aucune des deux solutions n'est donc viable sur le long terme. Elles peuvent toutefois servir de base pour mettre au point une solution plus efficace et plus stable moyennant une étude plus approfondie du système d'exploitation Android et notamment des modules qui sont utilisés pour la gestion de la connectivité Etude de l'architecture avec routeur mobile L étude de cette architecture s est faite avec l hypothèse que le routeur mobile utilisé est un routeur Linux. En effet c est un routeur de ce type qui allait nous être fourni par nos encadrants techniques. S il est possible sous Linux de configurer plusieurs interfaces réseau, le système d exploitation n autorise pas l existence simultanée de plusieurs routes par défaut vers le réseau IP à moins que celles-ci possèdent des métriques différentes. Or la route par défaut d une interface est souvent configurée automatiquement par un programme démon (un client DHCP la plupart des cas) qui lui associe la métrique la plus faible. Ainsi une fois qu une route par défaut a été configurée pour une interface, le client DHCP ne peut pas faire de même pour les autres. Par ailleurs, quand une interface précédemment configurée devient inactive, les paramètres associés à cette interface ne sont pas révoqués par le système d exploitation. En particulier si la route par défaut du système était associée à cette interface, celui-ci perd l accès à Internet car aucune nouvelle route par défaut ne peut être configurée du moment que l ancienne, qui est désormais indisponible, est toujours pris en compte. Pour pouvoir donc gérer l existence de plusieurs interfaces, il faut les hiérarchiser en définissant des métriques différentes pour les routes par défaut qui leur sont associées. Dans notre cas, les interfaces sont au nombre de deux et le Wifi est prioritaire sur la 3G. Quand le routeur détectera un point d accès Wifi, son interface Wifi deviendra active et le client DHCP réussira à lui associer une route par défaut car celle-ci aura une métrique différente de celle associée à la 3G. Cette métrique sera de plus inférieure compte-tenu de la hiérarchie prédéfinie et c est alors cette interface qui sera privilégiée par le système. En vue de mettre en œuvre ces mécanismes, il faut des outils permettant de détecter les événements liés à une modification de la configuration réseau du système (activation/désactivation d une interface) pour ensuite invoquer une instance du client DHCP qui effectuera les opérations appropriées. Sous Linux, ceci peut se faire à l aide de l outil netplug et de scripts [7]. Par ailleurs, en ce qui concerne la gestion de la mobilité sous Linux, elle se fait via la mise en œuvre du protocole NEMO dont le principe a été précédemment décrit. Ceci passe par l installation de certains packages et par une recompilation du noyau [8]. Télécom Bretagne 12

14 3.3 ARCHITECTURE RETENUE Après avoir étudié les deux architectures et analysé leurs caractéristiques, nous les avons comparés suivant plusieurs critères afin de déterminer laquelle des deux sera retenue pour le développement du système. Débit Dans le cas de l'architecture avec routeur mobile, les smartphones devront partager le débit d'une seule et même connexion 3G tandis qu'avec l'architecture sans routeur, chaque téléphone disposera de sa propre connexion 3G et pourra transmettre le flux à un débit plus élevé. Coût L'architecture sans routeur mobile nécessite un abonnement 3G par smartphone, là où il n'en faut qu'un seul pour l'architecture avec routeur mobile. Celle-ci requiert cependant un équipement supplémentaire (le routeur) mais son coût sera mieux amorti que celui des abonnements 3G. Performance énergétique Pour pouvoir basculer de manière fluide entre les interfaces Wifi et 3G, nous avons vu qu'il faut garder les deux interfaces actives simultanément ce qui est très consommateur en énergie. Dans le cas de l'architecture sans routeur mobile, l'autonomie des smartphones s'en verrait lourdement impactée étant donné que ces terminaux doivent en plus assurer la fonction de capture vidéo. L'architecture avec routeur mobile, si elle rajoute au bilan énergétique la consommation de celui-ci, est plus intéressante du fait que seul le routeur devra avoir plusieurs interfaces réseau actives en même temps et qu'il ne réalise pas d'autres fonctions aussi gourmande en énergie que la capture vidéo. Complexité de mise en œuvre La gestion simultanée des interfaces réseau Wifi et 3G n'est pas une fonction native du système d'exploitation Android. A défaut de trouver des solutions existantes permettant de l'implémenter qui soient stables et efficaces, sa mise en œuvre nécessite d'étudier le fonctionnement des différents modules du système d'exploitation impliqués dans la gestion de la connectivité et d'identifier les bonnes modifications à leur apporter. L'implémentation sur un routeur Linux n'est pas immédiate non plus, mais requiert des méthodes moins brutales, dans le sens où il n'est pas question de modifier des modules existants mais plutôt d'élaborer des scripts permettant de les faire communiquer pour réaliser les fonctions souhaités. Par ailleurs, si on peut trouver sur Internet de la documentation et des tutoriaux autour de la mise en œuvre des protocoles de gestion de mobilité sur Linux, il n'y a par contre quasiment aucun retour d'expérience sur leur implémentation sur Android. Aspects pratiques L'architecture avec routeur mobile contraindra les participants à s'encombrer d'un matériel supplémentaire. De son côté, l'architecture sans routeur requiert de rooter les smartphones de tous les participants au risque de compromettre leur garantie. Si l'architecture sans routeur offre un débit plus élevé, sa mise en œuvre s'accompagne d'un coût et d'une consommation énergétique plus élevés. Cette mise en œuvre s'avère par ailleurs plus complexe que celle de l'architecture avec routeur mobile ce qui est très contraignant compte tenu des délais à respecter. Aussi avons décidé de mettre en œuvre l'architecture avec routeur mobile. Télécom Bretagne 13

15 4. DEVELOPPEMENT 4.1 DEVELOPPEMENT DES APPLICATIONS DE STREAMING Pour mettre en œuvre l architecture de streaming au niveau logiciel, nous avons développé une application de streaming sur Android, une application de streaming côté serveur et un client web de streaming Choix des technologies de développement Pour chacun des composants logiciels mentionnés ci-dessus, nous devions choisir une technologie de développement appropriée. L'interopérabilité qui existe entre les trois composants exige que ces technologies soient interopérables également. De ce fait, le choix d'une technologie de développement pour l'un d'eux détermine dans une large mesure celles qui serviront à développer les deux autres. Par conséquent, ce choix doit concerner le composant dont le développement est le plus contraignant. Dans notre cas, il s'agit de l'application Android. Nous avons donc mené des recherches pour recenser les différentes approches permettant de développer une application de streaming sur Android et nous avons identifié deux approches possibles : - Développer l'application de streaming en code Android natif, en s'appuyant sur les solutions open-source existantes [9] [10] développées suivant la même approche. - Développer l'application à l'aide d'un langage non natif, disposant d'apis de streaming vidéo puissantes et simples d'utilisation, et pouvant s'exécuter sur Android grâce à un environnement d'exécution multiplateformes. En l'occurrence, il s'agit du langage ActionScript (Flash) et de l'environnement d'exécution Adobe AIR. Le tableau 1 résume les avantages et les inconvénients des deux approches : Développement en Android natif Avantages - Solution 100% open-source. - Approche bas niveau : plus de contrôle et capacité d'optimisation. Inconvénients - Complexité de mise en œuvre : implémentation bas niveau des protocoles et des canaux de communication. - Solutions existantes inexploitables en l état : le terminal fonctionne en tant que serveur et doit donc posséder une adresse publique. Développement à l'aide de Flash et Adobe AIR - Simplicité de mise en œuvre grâce à des APIs haut niveau. - Utilisation d'outils propriétaires. - Besoin d'installer un module - Portabilité (sur ios par exemple) supplémentaire pour pouvoir lancer l'application (Adobe AIR) Tab 1 : Comparaison des approches de développement de l application de streaming Android A l'issue de ce comparatif, nous avons opté pour la solution s'appuyant sur Flash et Adobe AIR. En effet sa simplicité de mise en œuvre allait nous permettre de gagner du temps et d'avoir ainsi plus de chances de respecter les délais. C'était aussi la solution offrant le plus de garantie de réussite au vu des premiers tests que nous avions effectués et qui s'étaient avérés satisfaisants. Télécom Bretagne 14

16 Par conséquent, les choix technologiques suivants ont été faits pour l'application côté serveur et le client de streaming : - L'application côté serveur sera déployée sur un serveur Flash. Notre choix s'est porté sur Red5 [11], un serveur Flash open-source et gratuit, dont les applications sont écrites en Java. - Le client de streaming sera un client Flash et le lecteur multimédia sera un lecteur Flash intégré au navigateur sous forme de plugin (module complémentaire) Logique opérationnelle des applications Pour guider la conception, nous avons émis des hypothèses sur la façon avec laquelle les différents utilisateurs interagiront avec les applications et nous en avons dérivé des règles de fonctionnement : - Chaque flux dispose d un identifiant, en l occurrence un nom, qui permet de le désigner.de manière univoque. C est primordial pour permettre au client de streaming de sélectionner le bon flux. Afin que cet identifiant soit unique, il n est pas choisi par l utilisateur de l application Android mais généré par l application côté serveur. - Un internaute pourra visualiser les flux d une seule équipe à la fois. De ce fait, il faut pouvoir distinguer les flux des différentes équipes. A cet effet, un flux émis par chaque membre d une équipe se voit associé le nom de l équipe. - Les participants doivent s authentifier pour pouvoir utiliser l application Android. Cela permet d une part d éviter une surcharge et un déni de service du serveur étant donné que l application sera disponible gratuitement sur l Android Market et donc utilisable par n importe qui. D autre part, ça offre la possibilité d associer le flux émis par le participant à son équipe. Pour cela, l identifiant utilisé pour l authentification de tous les membres d une même équipe est le même et correspond au nom de celle-ci. Les informations d authentification seront fournies aux équipes par les organisateurs de l Odyssée Celtique Pour gérer les informations introduites par ces règles de fonctionnement, une base de données très simple a été mise en place. Elle est constituée de deux tables organisées comme indiqué sur le schéma logique de la figure 5: Equipes - idequipe - nomequipe - motdepasse - logo Streams - idstream - nomstream - idequipe - idconnexion Figure 5 : Schéma logique de la base de données Développement de l'application Android de streaming Outils de développement Le développement de l application Android de Streaming fait appel aux outils suivants : Action Script 3 : ActionScript est un langage de programmation orienté objet dont la syntaxe de sa dernière version, la 3.0, est très proche de celle du langage Java. Il permet de créer des applications sous forme d exécutables au format SWF pouvant être exécutées à l aide du lecteur Flash Player. Ces applications sont capables de se connecter à une application déployée au niveau d un serveur Flash, échanger des données avec celle-ci et même invoquer ses méthodes. Télécom Bretagne 15

17 FlashDevelop : FlashDevelop est un éditeur et compilateur permettant d écrire et compiler des programmes ActionScript (entre autres) au format SWF. Il s agit d une alternative gratuite et open-source à Adobe Flash Professional. En y greffant le kit de développement pour Adobe AIR, il permet de déployer des applications Android écrites en Action Script. Structure de l'application L'application comporte cinq classes : - Trois classes LoginView, PrefView et PublishView représentant les trois vues possibles de l'interface graphique. - Une classe Config non instantiable où sont stockés les paramètres de réglage. - Une classe principale Main s'exécutant au lancement de l application. Elle implémente les méthodes métiers et gère les différentes vues de l interface graphique. Ces classes sont organisées selon le diagramme de classes de la figure 6 : Config Utilise PrefView 1 Utilise Main 1 Observe 1 1 LoginView 1 1 PublishView Figure 6 : Diagramme de classes de l application Android Les classes PrefView, LoginView et PublishView Ces classes implémentent les trois vues de l interface graphique : - LoginView implémente la vue d authentification. - PrefView implémente la vue de réglages permettant de spécifier l adresse IP du serveur de streaming, le numéro de port, le nom de l application côté serveur, la résolution et la qualité du flux vidéo émis, la bande passante disponible et l état du son (activé/désactivé). - PublishView implémente la vue affichant ce qui est capturé par la caméra et permettant de démarrer ou arrêter la publication du flux. Leurs attributs sont principalement des instances de classes représentant des composants graphiques comme des boutons, des champs de saisie etc. La classe PublishView possède un attribut instance de la classe Video. Il s agit d un conteneur destiné à accueillir le flux issu de la caméra. Elles implémentent des méthodes particulières faisant office d observateurs internes. Elles détectent les actions de l utilisateur sur l interface et agissent en conséquence en invoquant des méthodes de la classe Main ou de la classe Config. Télécom Bretagne 16

18 Le schéma ci-dessous donne un aperçu des différentes vues et illustre la logique de navigation : Réglages IP du serveur N du port Identifiant : Mot de passe : Connexion Réglages Nom de l appli côté serveur Résolution Hauteur Largeur Qualité Bande passante Son : Appliquer Start Réglages Stop Télécom Bretagne 17

19 La classe Config La classe Config ne possède pas de constructeur et ne contient que des attributs et des méthodes statiques. Ces attributs servent à stocker différents paramètres de configuration comme l adresse IP du serveur de streaming, le nom de l application côté serveur, la résolution du flux vidéo publié etc Ces réglages déterminent les paramètres de plusieurs méthodes de la classe Main. Ils sont chargés au lancement de l application à partir d un fichier XML. L utilisateur peut les modifier via le menu de configuration implémenté au niveau de la classe PrefView. Les observateurs internes de cette classe détectent les changements opérés par l utilisateur et appellent les mutateurs (méthodes permettant de changer la valeur des attributs) de la classe Config afin qu ils soient pris en compte. La classe Main La classe Main implémente la logique métier de l'application. Pour cela, elle s'appuie sur des classes API de la librairie Flash dont elle possède des instances en tant qu'attributs : - Camera : sa méthode statique getcamera renvoie une instance représentant le flux capturé par la caméra du smartphone. Si aucun paramètre n est passé à cette méthode, c est la caméra située au dos du téléphone qui est sélectionnée. - Microphone : à l image de la classe Camera, sa méthode getmicrophone permet de récupérer le flux audio capturé par le microphone du smartphone. - NetConnection : une instance de cette classe permet grâce à la méthode connect d établir une connexion avec une application côté serveur déployée sur un serveur Flash. Cette méthode prend comme argument obligatoire l URL de l application côté serveur et autant d arguments optionnels qu il n en faut. Dans notre cas, on passe en paramètre les informations d authentification en plus de l URL. - NetStream : Un objet NetStream représente un agrégat de flux destinés à être publiés ou reçus via une instance de NetConnection ayant effectivement établi une connexion avec le serveur. Celle instance est passée en argument au constructeur de NetStream au moment de la création de l objet. Il est possible d attacher plusieurs flux à un objet NetStream en faisant appel à la méthode attach. En l occurrence, on lui attache les instances de Camera et Microphone évoquées précédemment. Une fois la connexion avec le serveur établie, càd après que la méthode connect de l objet NetConnection ait été invoqué et qu un événement Cet agrégat de flux est ensuite diffusé vers le serveur en invoquant la méthode publish. Elle prend en paramètre le nom du flux et le mode de publication. Ce dernier indique si on souhaite que le flux soit enregistré au niveau du serveur ou non. La classe Main gère également les différentes vues de l interface graphique. Elle a dans sa liste d attributs une instance de chacune d entre elles. La méthode addchild permet d ajouter ces instances au conteneur graphique de l application. La transition entre les vues fait appel à la classe Tweener. Celle-ci possède une méthode addtween qui prend en paramètre une vue et le niveau de transparence alpha souhaité. On choisit alors un niveau 0 pour les vues qu on veut mettre en arrièreplan et un niveau 1 pour la vue qu on veut faire apparaître au premier plan. Pour prendre en charge les évènements liés à une action de l utilisateur ou à l état de la connexion avec les serveurs, des méthodes faisant office d observateurs et réagissant en conséquence sont implémentées et rattachées aux entités provoquant ces événements. A titre d exemple une méthode connecthandler observe l état du bouton «Connexion». Quand l utilisateur appuie dessus, la méthode startconnection est appelée. Celle-ci fait appel à la méthode connect de l objet NetConnection auquel a été rattaché un observateur netconnectionhandler. Si l authentification et la connexion réussissent, ce dernier capte un message «Success» puis en conséquence invoque la méthode addtween pour basculer de l interface d authentification vers l interface affichant la caméra. Enfin, la classe Main contient aussi deux méthodes pouvant être invoquées à distance par le serveur de streaming. Il s agit des méthodes setstreamname et errorloginhandler. La première permet de spécifier le nom du flux à passer en paramètre à la fonction publish de NetStatus. La deuxième est appelée pour notifier l échec de l authentification. Télécom Bretagne 18

20 4.1.4 Développement de l application côté serveur Outils de développement Les outils employés pour développer l application côté serveur sont : Java : Nous avons utilisé la version 1.6 du JDK (kit de développement). La version 1.7 présentait des problèmes d instabilité avec le serveur Red5. Eclipse : Le choix d Eclipse comme environnement de développement s est fait naturellement car c est celui que nous maitrisons le plus et que nous avons l habitude d utiliser. Ant : Pour pouvoir déployer une application sur Red5, il faut compiler le projet Eclipse associé sous la forme d un fichier.war et le placer au niveau du répertoire des applications du serveur. Ant est un outil permettant d effectuer cette opération. Structure de l'application La structure de l application côté serveur est assez simple. Elle est composée d une seule classe Application qui hérite et étend la classe ApplicationAdapter. Celle-ci appartient au package de Red5 et sert de base au développement de toutes ses applications. Elle contient en effet des méthodes implémentant les fonctionnalités de base d une application côté serveur à savoir la prise en charge des connexions entrantes et la manipulation des flux. Ces méthodes peuvent être étendues pour obtenir le comportement souhaité. Pour le développement de notre application, nous avons réutilisé et étendu les méthodes de base appconnect et appdisconnect. Nous avons également défini d autres méthodes que sont login, insertstream et deletestream. appconnect : Cette méthode prend en charge les connexions arrivant sur l application. Elle est invoquée à chaque fois qu un client Flash fait appel à la méthode connect de NetConnection en indiquant comme URL celle de cette application. Elle récupère via ses arguments un objet de type IConnection encapsulant les données relatives à la connexion entrante comme l IP du client ainsi que l ensemble des paramètres optionnels passés en argument à la méthode connect de NetConnection. En ce qui nous concerne, il s agit des informations d authentification saisies par l utilisateur de l application Android. La méthode login est alors appelée et prend ces informations en paramètres. Si elles sont invalides, elle retourne un booléen égal à False et la connexion est rejetée via un appel à la méthode rejectclient héritée de ApplicationAdapter. Si les informations sont valides, login retourne True et le client est notifié de la réussite de l authentification et appelle de son côté la méthode publish de NetStream pour démarrer la publication du flux. On invoque alors la méthode insertstream qui ajoute une nouvelle entrée dans la table Stream correspondant à ce flux. En guise de nom de flux, on prend la valeur retournée par la méthode currenttimemillis qui renvoie le nombre de millisecondes écoulées entre le 1 er Janvier 1970 minuit et l instant auquel cette méthode a été invoquée. Ceci garantit l unicité du nom attribué au flux car l appel à la méthode appconnect est bloquant. A l aide de la méthode invoke de l objet IConnection évoqué précédemment, on invoque la méthode setstreamname du côté de l application Android en lui passant en paramètre le nom choisi pour le flux. Ce nom est utilisé par la méthode publish de NetStream pour démarrer la publication du flux. L appel à cette méthode invoque du côté du serveur la méthode startpublishing qui amorce la diffusion du flux vers les clients Flash demandant de le recevoir. Télécom Bretagne 19

21 appdisconnect : Cette méthode est appelée quand l application Android est quittée. Elle invoque la méthode deletestream pour supprimer de la table Stream de la base donnée l entrée associée au flux qui était diffusé. login : Elle prend en argument un identifiant et un mot de passe. Elle utilise une instance de la classe Connection du package java.sql pour se connecter à la base de données. Elle exécute ensuite une requête SQL via la méthode executequery d une instance de la classe Statement appartenant également au package java.sql. Cette requête de type SELECT récupère la liste des entrées de la table Equipes dont les champs nomequipe et motdepasse coïncident avec les paramètres passés en argument à la méthode login. Si la liste des résultats est vide, Cette méthode est appelée quand l application Android est quittée. Celle-ci retourne un booléen False si la liste est vide et True sinon. insertstream : Elle utilise les mêmes méthodes et classes que login pour se connecter à la base de données et exécuter une requête permettant d insérer une entrée dans la table Streams. Les paramètres qui lui sont passés en argument servent à remplir les champs de cette entrée. deletestream : Elle se connecte à la base de données et exécute une requête SQL de type DELETE pour supprimer l entrée de la table Streams dont le champ idconnection est égal à l ID de l objet IConnection qui lui est passé en argument Développement du client web de streaming Outils de développement Les principaux outils utilisés pour développés le client web de streaming sont : PHP/HTML pour le site web ActionScript3 et FlashDevelop pour le client Flash de streaming. Structure de l'application Le client web de streaming est constitué du site web et du client Flash. Le site web comporte deux pages : - Une page d accueil sur laquelle est affichée la liste des équipes participantes et le nombre de flux actuellement diffusés par chaque équipe. - Une page permettant de visualiser l ensemble des flux diffusés par une équipe donnée. Elle intègre autant de client Flash que de flux. L équipe en question est celle choisie sur la page d accueil en cliquant sur le bouton «voir les flux» situé en face de son logo. Télécom Bretagne 20

22 Page d accueil Page de visualisation des flux Figure 7 : Interfaces du site web Développement du client Flash Le client Flash reprend la logique de fonctionnement, au niveau métier, de l application Android de Streaming. Son code contient une seule classe, la classe principale Main. L unique vue de l interface graphique est implémentée au niveau de cette classe. Elle est constituée d un conteneur instance de la classe Video. Un objet de type NetConnection permet au client de se connecter à l application côté serveur via la méthode connect. Une instance de NetStream permet quant à elle de récupérer le flux à travers l invocation de la méthode play qui prend en argument le nom du flux. Celui-ci est passé en paramètre depuis le code PHP et récupéré dans une variable. Enfin, le flux reçu est affiché sur l interface du client en attachant, par le biais de la méthode attach, l objet de type NetStream au conteneur instance de la classe Video. Développement du site web Page d accueil : Ebike.php Le code PHP contenu dans la page permet de se connecter à la base de données afin de récupérer : - la liste des équipes et leurs logos depuis la table Equipes. - Le nombre de flux diffusés par chaque équipe depuis la table Streams. Ces données sont ensuite affichées à l aide d un code HTML. Pour chaque équipe, un bouton estampillé «Voir les flux» permet de se rendre à la page de visualisation des flux Live.php. Il pointe vers son URL dans laquelle est passé en paramètre l id de l équipe. Page de visualisation : Live.php Le code PHP de cette page récupère d abord à l aide de la fonction GET l id de l équipe dans une variable. Ensuite il se connecte à la base de données et récupère depuis la table Streams les entrées dont le champ idequipe coïncide avec l id récupéré dans l URL. Pour chacune de ces entrées, le code HTML intègre un client Flash à la page auquel il passe en paramètre le nom du flux associé à cette entrée. Télécom Bretagne 21

23 4.2 DEVELOPPEMENT DU ROUTEUR MOBILE Description matérielle du routeur Le routeur mobile que nous avons à notre disposition pour le développement est une carte PC Engines Alix [12]. Les cartes Alix sont des cartes système optimisées pour le routage multi-interface et pour applications de sécurité des réseaux. Le modèle que nous avons utilisé est Alix.2d2 qui a les spécifications techniques suivantes : CPU DRAM Stockage Power 500 MHz AMD Geode LX Mb DDR DRAM Compact Flash socket DC jack : min 7V max 20V Connectivité 2 ports Ethernet 10/100 I/O Dimension Port serial DB9 2 ports USB x mm A cette configuration classique, il a fallu ajouter deux cartes Wireless PCI Express pour pouvoir utiliser la carte et la configurer comme routeur Wireless. Nous avons aussi ajouté une carte mémoire flash de 8Gb afin de pouvoir y installer un système Linux. Pour la configuration de la carte, nous avons utilisé un cable serial DB9. Figure 8 : Vues de face et de dos de la carte ALIX 2d2 Il faut noter que la carte Alix qu on a reçu de notre encadrant technique n était pas entièrement fonctionnelle. En effet, une interface USB et une interface Ethernet n étaient pas fonctionnelles. Mais cela ne nous a pas empêché de déployer la solution. Par ailleurs, pour la connexion 3G, nous avons utilisé un Modem Huawei E398 4G LTE USB équipé avec une carte SIM Orange. La clé USB a les caractéristiques suivantes : supports les technologies : LTE / HSPA+ / EDGE / GPRS une interface USB standard vitesse de Downlink : jusqu à 100 Mbps vitesse de Uplink : jusqu à 50 Mbps Télécom Bretagne 22

24 4.2.2 Installation et mise à jour du système Une fois le routeur mobile acquis, il a fallu y installer un système d exploitation stable et à jour, avant de programmer le moindre code de configuration. Pour choisir ce système d exploitation, nous avons considéré plusieurs critères : licence, coût, facilité d utilisation, grand public ect Ainsi, au vu de tous ces critères notre choix s est porté sur la distribution Ubuntu du système Linux. L installation de ce système n a pas été de toute simplicité, car la carte Alix dispose d une procédure de démarrage plutôt particulière. En effet, d après sa documentation, le seul périphérique amorçable est la carte flash installée. Dans notre cas, cette carte flash a non seulement été reçue en retard mais elle était dépourvue de secteur d amorçage. Il a donc fallu activer le support du PXE (en reconfigurant de BIOS de la carte Alix), afin de procéder à une installation par PXE. Cela consiste en un démarrage à travers le réseau pour téléchargeant une image disque amorçable. Techniquement, pour faire cela, nous nous sommes servi d une machine hôte sur laquelle nous avons installé un serveur DHCP et un serveur NFS, puis nous avons connecté cette machine hôte à la carte Alix par un câble RJ45 créant ainsi un réseau Ethernet point à point. La machine hôte est configurée avec une adresse IP statique / Le serveur DHCP installé est «dhcp-server3» et il a été configuré de sorte à attribuer une adresse IP dynamiquement dans la plage Voir configuration dans Annexe A Le serveur NFS installé est «nfs-kernel-server». Il a été configuré de sorte à fournir une image Ubuntu téléchargée préalablement. Voir configuration dans Annexe A Une fois les serveurs DHCP et NFS installés, il suffit de démarrer la carte Alix sur le réseau, et l image Ubuntu sera automatiquement téléchargée et chargée en mémoire. La procédure d installation débutera alors. Il suffira de suivre cette procédure pour installer le système sur la mémoire Flash de la carte Alix. Une fois le système installé, il faut effectuer les mises à jour. Pour ce faire, on utilise la machine hôte pour donner un accès internet à la carte Alix. En effet, cela se fait en mettant en place un NAT dynamique sur la machine hôte avec Iptables. Voir Annexe La carte Alix se retrouve alors avec un accès internet, et il suffira de lancer les commandes «apt-get update» et «apt-get upgrade» pour mettre à jour le système de base Configuration des scripts Une fois le système installé et prêt à l utilisation, on passe à l étape suivante, c est-à-dire la configuration proprement dite du routeur mobile. Pour cela, nous avons codé deux scripts de configuration en langage PERL. Il s agit des scripts : ebike-installing.pl et ebike-networking.pl. Les codes sources de ces scripts sont disponibles dans l Annexe A2.2 et A2.3. Le premier script est destiné à être exécuté une seule fois sur un nouveau routeur mobile à déployer. Il est chargé de télécharger, installer et configurer les paquets nécessaires à la gestion des interfaces réseau du routeur mobile. Il guide l utilisateur à remplir tous les fichiers de configurations nécessaires. Avant de lancer ce script de configuration, il faut d abord renseigner quelques paramètres comme le nom du réseau wifi interne à créer, les noms des interfaces Ethernet, wifi et 3G+ ect Une fois ces paramètres fournis, et après avoir installé l interpréteur Perl, il suffira de démarrer le script par la commande «./ebike-installing.pl». Le deuxième script «ebike-networking.pl» est destiné à être exécuté à chaque redémarrage du routeur mobile. Il est chargé d initialiser les interfaces réseaux (Ethernet, Wifi et 3g), d initialiser le pare-feu du routeur mobile, d établir les connexions entre les réseaux wifi et le réseau 3G ect Tout comme le premier, ce script est aussi paramétrable. Ces deux scripts permettent ainsi la configuration automatique du routeur à travers quatre principales étapes détaillées ci-dessous : Télécom Bretagne 23

25 La configuration du réseau wifi interne Il s agit du réseau wifi auquel seront connectés les smartphones pour accéder à internet. Ce réseau wifi est créé en mode Point d accès. Il utilise l interface wlan0 du routeur mobile. La création et la configuration de ce réseau wifi a été effectuée avec l outil hostapd. La configuration de l interface wifi externe Il s agit de l interface wifi qui est chargée de rechercher, identifier des réseaux wifi disponibles sur l itinérance du cycliste, et de connecter le routeur mobile a un éventuel réseau wifi trouvé. Il utilise l interface wlan1 du routeur mobile. La configuration de cette interface est gérée par network-manager et wpa-supplicant. La configuration de l interface 3G+ Il s agit d une interface virtuelle ppp0 qui a été automatiquement créé par le script de configuration «ebike-networking.pl».cette interface est liée à la clé 3G+ fournie par Orange. Elle établit ainsi une liaison Point-to-point vers le gestionnaire d accès à internet d Orange. La configuration de cette interface est principalement gérée par wicd. La configuration du firewall Cette partie consiste à établir les règles du pare-feu afin de garantir la sécurité du routeur mobile et aussi de garantir l inter connectivité entre les réseaux Wifi, 3G et Ethernet. Nous avons utilisé pour cela l outil Iptables La gestion de la mobilité Sur toute son itinérance, le routeur mobile sera amené à rencontrer plusieurs réseaux différents, et à choisir un d eux pour son accès internet. Il doit donc implémenter des fonctions permettant de gérer la mobilité entre les différents réseaux rencontrés. Pour cela, il doit implémenter d une part un mécanisme de basculement automatique entre l interface wifi et l interface 3G+, et d autre part un mécanisme de basculement transparent entre réseaux. Ces deux mécanismes doivent être gérés mutuellement. Nous utilisons l utilitaire «netplug» pour gérer la détection et le basculement entre interfaces au «bas niveau» et NEMO pour gérer la mobilité entre les différents réseaux au «haut niveau». L installation et la configuration de «netplug» ont été sans difficulté majeure, car il suffit d installer le paquet correspondant et de renseigner les noms des interfaces concernés par le basculement automatique dans le fichier de configuration /etc/netplug/netplugd.conf Par contre, l installation de NEMO est plus complexe. En effet, un système natif Ubuntu ne prend pas en charge le protocole NEMO. Il a donc fallu recompiler le noyau natif generic, afin d inclure le support de NEMO dans le noyau. Cette étape a été menée avec plusieurs difficultés par manque de documentation sur ce sujet, et surtout pour des problèmes de compatibilités entre le noyau linux utilisé et les noyaux qui faisaient l objet de cette recompilation. Une fois cette étape achevée, nous étions déjà à la fin du projet et le manque de temps ne nous a pas permis de déployer une solution complète de mobilité avec prise en charge du protocole NEMO Finalisation et déploiement du routeur Afin de faciliter le déploiement du routeur mobile nous avons regroupé toutes les commandes de configurations pour en faire deux scripts codés en langage PERL : ebike-installing.pl (qui permet d installer la configuration du routeur mobile) et ebike-networking.pl (qui permet de démarrer les fonctions de connectivité et de routage du routeur mobile). Le deuxième script est configuré pour être lancée automatiquement à chaque démarrage du routeur mobile. Ainsi, dès la mise sous tension, le routeur s auto configure et est prêt à fonctionner en 3 minutes environs. Télécom Bretagne 24

26 5. MAQUETTE DE TEST 5.1 DESCRIPTION DE LA MAQUETTE La maquette met en œuvre l architecture avec routeur mobile dans le cas où l équipe est composée de deux participants. Elle est constituée des éléments suivants : - 2 vélos. - 2 smartphones embarqués sur les vélos à l aide d un support de fixation sur guidon. - Un routeur mobile ALIX embarqué sur l un des vélos. - 2 batteries externes. Une alimentant l un des smartphones et l autre alimentant le routeur. branchées aux smartphones. - Une clé 3G branchée et configurée sur le routeur. - Un espace d hébergement Gandi de type serveur sur lequel est hébergé le site web et au niveau duquel est déployé le serveur de streaming Red5. - Un PC connecté à Internet et doté du navigateur Mozilla Firefox avec le plugin Flash installé SCENARIO DE TEST Le test prend place sur le campus brestois de Télécom Bretagne. Il consiste à effectuer un parcours à travers le campus avec les deux vélos et à visualiser en même temps si les flux sont bien reçus au niveau du site web et comment ils évoluent. Les vélos prennent leur départ depuis le bâtiment I12. L un des membres du groupe habite en effet dans ce bâtiment et dispose d un spot Wifi dans sa chambre. La publication des flux est lancée sur les deux smartphones. Tant que les vélos sont à portée du spot Wifi, le routeur privilégie cette interface-là. Quand les vélos s éloignent, on vérifie si le basculement du Wifi vers la 3G s effectue comme prévu en regardant s il y a coupure à un moment donné ou non, et s il y en a comme dure-telle. On observe ensuite l évolution du flux reçu via la 3G. Etant donné que les dimensions du parcours sont de l ordre de quelques centaines de mètres et que la portée de la 3G est de l ordre de quelques kilomètres, on ne s attend pas à ce qu un changement de réseau se produise. Les vélos font par la suite le chemin inverse et on vérifie si un basculement vers le Wifi a lieu comme on pourrait s y attendre lorsqu ils s approchent du point de départ. 5.3 RESULTATS/OBSERVATIONS Le scénario de test tel qu il est décrit ci-dessus n a pas pu être mis en œuvre. En effet nous nous sommes heurtés à un problème : nous ne pouvions pas embarquer le routeur mobile à bord du vélo. Il fallait un adaptateur spécial de type 3.5 mm femelle vers 5.5 mm male pour pouvoir lui brancher la batterie externe. Nous avons par conséquent élaboré un scénario alternatif. Nous avons branché le routeur sur secteur dans la chambre où se trouvait le spot Wifi et nous avons effectué le test dans la zone de couverture Wifi du routeur. Le routeur était aussi branché à un PC afin de surveiller l évolution de sa connectivité. Pour stimuler le basculement du Wifi vers la 3G, nous débranchions le spot Wifi. On observait alors effectivement sur le PC relié au routeur qu un basculement s est produit par contre cela mettait fin à la transmission du flux. L explication la plus plausible est l implémentation pas suffisamment fonctionnelle du protocole NEMO. Nous avons ensuite fait des tests sans routeur mobile en utilisant directement la connexion 3G des smartphones. Le but était de valider le fonctionnement du dispositif de streaming et d observer la qualité du flux reçu. Si on pouvait effectivement visualiser en temps-réel ce que filmaient les smartphones, globalement on constatait que le flux était peu fluide. Nous nous sommes aperçu par la suite qu au niveau des réglages de l application Android la bande passante était considérée comme infinie. Par conséquent l application transmettait à la meilleure qualité possible sans tenir compte de la valeur entrée pour ce paramètre. En indiquant une valeur finie pour la bande passante de l ordre d une centaine de Kbits/s (ordre de grandeur du débit montant de la 3G [13]), nous avons pu constater une amélioration de la fluidité au détriment de la qualité. On n obtenait pas cependant une fluidité exemplaire. Télécom Bretagne 25

27 6. CONCLUSION Au terme de ce projet, nous avons développé un système qui transforme un vélo anodin en un objet communicant permettant de suivre en temps-réel et en images ses moindres déplacements. La fonctionnalité de gestion de la mobilité, qui aurait contribué à en faire un objet communicant de façon plus autonome, n a pas pu être implémentée de manière entièrement opérationnelle. La documentation contenue dans ce rapport fournit cependant des pistes concrètes pour le faire. Globalement, le travail réalisé constitue une base solide sur laquelle notre partenaire extérieure pourra s appuyer pour déployer son dispositif de retransmission web de l Odyssée Celtique. Les perspectives d amélioration pour le projet E-Bike sont multiples. Ainsi, si on se place dans le contexte de l Odyssée Celtique, il serait intéressant de superposer au contenu vidéo retransmis des données issues de capteurs et renseignant sur la vitesse du participant, son rythme cardiaque, le classement de son équipe, son objectif courant etc. tout ceci dans l optique de rendre le vélo encore plus communicant. Télécom Bretagne 26

28 Annexes ANNEXE 1 - BILAN DE GESTION A1.1. DIAGRAMME WBS Télécom Bretagne 27