Rendus des étudiants

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
Sommaire
1.
LE PROJET E-BIKE.......................................................................................... 4
1.1
CONTEXTE : L'ODYSSEE CELTIQUE.................................................................................................. 4
1.2
FINALITE : UNE COUVERTURE WEB IMMERSIVE DE L'ODYSSEE CELTIQUE ........................................... 4
1.3
OBJECTIF TECHNIQUE : UN DISPOSITIF DE STREAMING VIDEO EMBARQUE SUR VELO ........................... 5
2.
PROBLEMATIQUES TECHNIQUES DU PROJET ........................................... 6
2.1
CAPTURE VIDEO DES TRAJETS INDIVIDUELS DES VELOS .................................................................... 6
2.2
LA RETRANSMISSION EN TEMPS-REEL .............................................................................................. 6
2.3
LA CONNECTIVITE DANS UN MILIEU FORESTIER ................................................................................. 7
2.4
LA CONNECTIVITE DANS UN CONTEXTE DE MOBILITE ......................................................................... 7
3.
ARCHITECTURE TECHNIQUE DU SYSTEME ................................................ 8
3.1
DESCRIPTION DES ARCHITECTURES ENVISAGEES.............................................................................. 8
3.1.1
Architecture générale ............................................................................................................ 8
3.1.2
Architecture sans routeur mobile......................................................................................... 11
3.1.3
Architecture avec routeur mobile......................................................................................... 11
3.2
ETUDE DES ARCHITECTURES ENVISAGEES ...................................................................................... 11
3.2.1
Etude de l'architecture sans routeur mobile ........................................................................ 11
3.2.2
Etude de l'architecture avec routeur mobile ........................................................................ 12
3.3
ARCHITECTURE RETENUE .............................................................................................................. 13
4.
DEVELOPPEMENT......................................................................................... 14
4.1
DEVELOPPEMENT DES APPLICATIONS DE STREAMING ..................................................................... 14
4.1.1
Choix des technologies de développement ........................................................................ 14
4.1.2
Logique opérationnelle des applications ............................................................................. 15
4.1.3
Développement de l'application Android de streaming ....................................................... 15
4.1.4
Développement de l’application côté serveur ..................................................................... 19
4.1.5
Développement du client web de streaming ....................................................................... 20
4.2
DEVELOPPEMENT DU ROUTEUR MOBILE ......................................................................................... 22
4.2.1
Description matérielle du routeur ........................................................................................ 22
4.2.2
Installation et mise à jour du système ................................................................................. 23
4.2.3
Configuration des scripts ..................................................................................................... 23
4.2.4
La gestion de la mobilité ...................................................................................................... 24
4.2.5
Finalisation et déploiement du routeur ................................................................................ 24
5.
MAQUETTE DE TEST .................................................................................... 25
5.1
DESCRIPTION DE LA MAQUETTE ..................................................................................................... 25
5.2
SCENARIO DE TEST ....................................................................................................................... 25
5.3
RESULTATS/OBSERVATIONS ......................................................................................................... 25
6.
CONCLUSION ................................................................................................ 26
Télécom Bretagne
1
ANNEXE 1 - BILAN DE GESTION .......................................................................... 27
A1.1. DIAGRAMME WBS ........................................................................................................................ 27
A1.2. DIAGRAMME GANTT .................................................................................................................... 28
A1.3. GESTION DES RISQUES .................................................................................................................. 29
A1.4. GESTION DU BUDGET .................................................................................................................... 29
A1.5. DIFFICULTES RENCONTREES.......................................................................................................... 29
ANNEXE 2 - CONFIGURATION DU ROUTEUR MOBILE....................................... 31
A2.1. CONFIGURATION DE LA MACHINE HOTE .......................................................................................... 31
A2.1.1.
Configuration du serveur dhcp......................................................................................... 31
A2.1.2.
Configuration du serveur nfs ............................................................................................ 31
A2.1.3.
Configuration du firewall pour nat dynamique ................................................................. 31
A2.2. FICHIER DE CONFIGURATION « EBIKE-INSTALLING.PL » ................................................................... 32
A2.3. FICHIER DE CONFIGURATION « EBIKE-NETWORKING.PL » ................................................................ 34
ANNEXE 3 – EQUIPEMENTS DIVERS ................................................................... 36
A3.1. SUPPORT DE FIXATION DU SMARTPHONE ........................................................................................ 36
A3.2. BATTERIE D’ALIMENTATION EXTERNE DU SMARTPHONE ET DU ROUTEUR.......................................... 36
BIBLIOGRAPHIE ..................................................................................................... 37
Télécom Bretagne
2
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
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
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
PROBLEMATIQUES TECHNIQUES DU PROJET
2.
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
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
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.
3.1.1
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
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
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.
HTTP
Serveur web
Navigateur 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
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.
3.1.3
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.
3.2.1
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
-
-
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é.
3.2.2
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
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
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.
4.1.1
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 :
Avantages
Développement en
Android natif
Inconvénients
- Solution 100% open-source.
- Approche bas niveau : plus de
contrôle
et
capacité
d'optimisation.
- 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.
- Simplicité de mise en œuvre
grâce à des APIs haut niveau.
- Portabilité (sur iOS par exemple)
- Utilisation d'outils propriétaires.
Développement à l'aide
- Besoin d'installer un module
de Flash et Adobe AIR
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
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).
4.1.2
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
Streams
- idEquipe
- idStream
- nomEquipe
- nomStream
- motDePasse
- idEquipe
- logo
- idConnexion
Figure 5 : Schéma logique de la base de données
4.1.3
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

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 :
Utilise
Config
PrefView
1
Utilise
1
Observe
Main
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
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
:
Nom de l’appli côté serveur
Mot de passe
:
Résolution
Hauteur
Connexion
Largeur
Qualité
Réglages
Bande passante
Son :
Appliquer
Start
Réglages
Stop
Télécom Bretagne
17
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
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
er
qui renvoie le nombre de millisecondes écoulées entre le 1 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
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.
4.1.5
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
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
4.2
DEVELOPPEMENT DU ROUTEUR MOBILE
4.2.1
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
500 MHz AMD Geode LX800
DRAM
256 Mb DDR DRAM
Stockage
Compact Flash socket
Power
DC jack : min 7V – max 20V
Connectivité
2 ports Ethernet 10/100
I/O
Port serial DB9
2 ports USB 2.0
Dimension
152.4 x 152.4 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
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 11.04 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 192.168.10.5/255.255.255.0.
Le serveur DHCP installé est « dhcp-server3 » et il a été configuré de sorte à attribuer une adresse IP
dynamiquement dans la plage 192.168.10.6 - 192.168.10.10. Voir configuration dans Annexe A2.1.1.
Le serveur NFS installé est « nfs-kernel-server ». Il a été configuré de sorte à fournir une image
Ubuntu 11.04 téléchargée préalablement. Voir configuration dans Annexe A2.1.2.
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 11.04 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 Annexe2.1.3.
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.
4.2.3
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
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.
4.2.4
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 3.0.0-19-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.
4.2.5
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
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é.
-
5.2
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
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
Annexes
ANNEXE 1 - BILAN DE GESTION
A1.1.
DIAGRAMME WBS
Télécom Bretagne
27
A1.2.
DIAGRAMME GANTT
Télécom Bretagne
28
A1.3.
GESTION DES RISQUES
Date d'id S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 S14 S15 S16 S17
Risques
Non-respect des délais
Pas de prototype fonctionnel pour le test (lors du 11 et 12 mai)
16/02/12
Insuffisance du budget
-Frais de déplacement à Lorient pour 5 personnes
16/02/12
Insuffisance du budget
-Achat de matériel (au cas où ils ne sont pas livrés par le client)
16/02/12
Indisponibilité de la documentation technique sur la mobilité en Ipv6, la
configuration des routeurs mobiles ou le développement sous Android
16/02/12
Refus d'Orange de fournir des équipements nécessaires au développement
(routeurs mobiles, smartphones Samsung)
01/03/12
Indisponibilité des partenaires extérieurs pour fournir les équipements ou les
informations nécessaires
16/02/12
Liaison sans-fil défaillante en milieu forestier : forêt de Brocéliande
16/02/12
Retard de livraison des équipements à commander :
Support de fixation du smartphone
Chargeur de la batterie par la dynamo
24/03/12
Incompatibilité de l’adaptateur du chargeur par dynamo au Samsung Galaxy S
24/03/12
Absence de dynamo sur les vélos fournis par le client pour le test
24/03/12
Retard de livraison des routeurs/smartphones : A priori fournis par Orange
16/02/12
Légende :
1:Point dur
2:Critique
3:Mineure
4:Soldé
Deux risques subsistent à la fin du projet :
- Le risque lié à la disponibilité de la documentation autour de l’implémentation de MobileIPv6
et NEMO. En effet, bien que la documentation que nous avons trouvé soit de qualité, elle ne
nous a pas permis de réaliser une mise en œuvre entièrement fonctionnelle du protocole et
nous n’avons pas réussi à en trouver d’autres.
- Le risque lié à la défaillance de la transmission en forêt de Brocéliande. Il traduit la zone
d’incertitude résultant du fait que nous n’ayons pas pu faire des tests là-bas pour confirmer ou
infirmer l’hypothèse.
A1.4.
GESTION DU BUDGET
Sur les 500 € alloué au projet, 190,72 € ont été dépensés et ce pour l’achat du matériel suivant :
-
2 supports de fixation Herbert Richter + frais de port
-
Une batterie externe Novodio PureWatt Ultra 11000 mAh
Une batterie externe Novodio PureWatt 5500 mAh
Frais de port
Télécom Bretagne
29
64,6 €
126,12 €
A1.5.
DIFFICULTES RENCONTREES
Problèmes d’organisation
Au début du projet, le groupe a dû faire face à quelques soucis d’organisation qui ont été
préjudiciables à son efficacité.
D’une part, comme les rôles de responsables venaient d’être attribués, il a fallu un certain temps
avant que chaque membre ait pu assimiler et s’approprier pleinement son rôle ce qui a engendré une
période de flottement pendant laquelle tout le monde s’occupait de tout. Ce problème s’est manifesté
aussi du côté des tâches techniques du fait que le responsable de gestion de projet ne définissait pas
clairement à la fin des réunions ce qui devait être fait par chaque membre avant la réunion d’après.
Ainsi il arrivait que les réunions de mise au point servent plutôt à effectuer le travail qui aurait dû être
fait depuis la dernière réunion mais qui ne l’a pas été car un responsable n’a pas été clairement
nommé.
A certains moments, le fonctionnement du groupe n’a pas fait preuve de suffisamment de
parallélisme. Cela s’est produit à l’approche de certaines échéances face auxquelles le groupe a
décidé de mobiliser tout son effectif à la réalisation des livrables attendus pour cette échéance aux
dépens d’autres tâches qui étaient par conséquent mises en suspens.
Faible réactivité du partenaire extérieur
Durant la première moitié du projet, le partenaire extérieur n’a pas été suffisamment réactif à nos
sollicitations, notamment quand il s’agissait d’obtenir certaines informations utiles pour le
dimensionnement du système ou pour avoir son avis sur certains livrables comme le plan de
management. Mais ce qui a été le plus pénalisant c’est de ne pas avoir eu assez tôt un retour sur la
mise en place d’un partenariat avec Orange afin de nous fournir les équipements dont on avait besoin.
Ceci nous a en effet placés dans une situation où on ne savait pas s’il fallait attendre la réponse du
partenaire extérieur ou procéder à la commande des équipements quitte à alléger considérablement
notre budget.
Disponibilité tardive des équipements
L’arrivée tardive de certains équipements comme le routeur mobile et les cartes ne nous a pas laissé
le temps suffisant pour réaliser une implémentation entièrement opérationnelle de certaines
fonctionnalités du système telles que la gestion de la mobilité.
Télécom Bretagne
30
ANNEXE 2 - CONFIGURATION DU ROUTEUR MOBILE
A2.1.
CONFIGURATION DE LA MACHINE HOTE
A2.1.1.
CONFIGURATION DU SERVEUR DHCP
subnet 192.168.10.0 netmask 255.255.255.0 {
range 192.168.10.6 192.168.10.10;
option routers 192.168.1.5;
option domain-name-servers 192.44.75.10;
default-lease-time 600;
max-lease-time 7200;
}
host alix {
hardware ethernet 00:0D:B9:1B:EE:D8; #alix
fixed-address 192.168.1.6;
next-server 192.168.1.5;
filename "ubuntu/oneiric/i386/pxelinux.0";
}
A2.1.2.
CONFIGURATION DU SERVEUR NFS
/var/lib/tftpboot/DebianNFS
192.168.1.0/255.255.255.0(async,no_root_squash,no_subtree_check,ro)
/var/lib/tftpboot/UbuntuNFS/ubuntu
192.168.1.0/255.255.255.0(async,no_root_squash,no_subtree_check,rw)
/var/lib/tftpboot/IMedia601NFS
192.168.1.0/255.255.255.0(async,no_root_squash,no_subtree_check,ro)
A2.1.3.
CONFIGURATION DU FIREWALL POUR NAT DYNAMIQUE
Echo 1 > /proc/sys/net/ipv4/ip_forward
Iptables –t nat –F
Iptables –t nat –A POSTROUTING –s 192.168.0.0/16 –o wlan0 –j MASQUERADE
Télécom Bretagne
31
A2.2.
FICHIER DE CONFIGURATION « EBIKE-INSTALLING.PL »
#!/usr/bin/perl -w
use strict;
# Interface lan
my($ilan)="eth0";
my($ilandhcp)="true";
my($ilanip)="192.168.1.10/24";
my($ilangw)="192.168.1.5";
# Interfaces wifi
my($iwireext)="wlan0";
my($intwifiname)="ebike-router-1";
my($iwireint)="wlan0";
# Interface 3G
my($i3g)="wlan2";
# Installation du wifi interne
my $chan=int(rand(13)+1);
system("apt-get autoremove --purge hostapd");
system("apt-get install hostapd");
system("sudo echo 'interface=$iwireint' > /etc/hostapd/hostapd.conf");
system("sudo echo 'driver=nl80211' >> /etc/hostapd/hostapd.conf");
system("sudo echo 'ssid=$intwifiname' >> /etc/hostapd/hostapd.conf");
system("sudo echo 'hw_mode=g' >> /etc/hostapd/hostapd.conf");
system("sudo echo 'channel=$chan' >> /etc/hostapd/hostapd.conf");
system("sudo echo 'beacon_int=100' >> /etc/hostapd/hostapd.conf");
system("sudo echo 'dtim_period=2' >> /etc/hostapd/hostapd.conf");
system("sudo echo 'max_num_sta=255' >> /etc/hostapd/hostapd.conf");
system("sudo echo 'rts_threshold=2347' >> /etc/hostapd/hostapd.conf");
system("sudo echo 'fragm_threshold=2346' >> /etc/hostapd/hostapd.conf");
system("sudo vim /etc/hostapd/hostapd.conf");
# Installation du dhcp et du dns
system("apt-get autoremove --purge dhcp3-server");
system("sudo apt-get install dhcp3-server");
system("sudo echo '# subnet 192.168.10.0 netmask 255.255.255.0 {' >> /etc/dhcp/dhcpd.conf");
system("sudo echo '# range 192.168.10.2 192.168.10.254;' >> /etc/dhcp/dhcpd.conf");
system("sudo echo '# option routers 192.168.10.1;' >> /etc/dhcp/dhcpd.conf");
system("sudo echo '# option domain-name-servers 192.168.10.1;' >> /etc/dhcp/dhcpd.conf");
system("sudo echo '# }' >> /etc/dhcp/dhcpd.conf");
system("sudo vim /etc/dhcp/dhcpd.conf");
system("sudo echo '# INTERFACES=\"wlan0\"' >> /etc/default/isc-dhcp-server");
system("sudo vim /etc/default/isc-dhcp-server");
Télécom Bretagne
32
system("apt-get autoremove --purge bind9");
system("sudo apt-get install bind9");
system("sudo echo '// forwarders {' >> /etc/bind/named.conf.options");
system("sudo echo '// 192.44.75.10;' >> /etc/bind/named.conf.options");
system("sudo echo '// }' >> /etc/bind/named.conf.options");
system("sudo vim /etc/bind/named.conf.options");
Télécom Bretagne
33
A2.3.
FICHIER DE CONFIGURATION « EBIKE-NETWORKING.PL »
#!/usr/bin/perl -w
use strict;
# Interface lan
my($ilan)="eth0";
my($ilandhcp)="true";
my($ilanip)="192.168.1.10/24";
my($ilangw)="192.168.1.5";
# Interfaces wifi
my($iwireext)="wlan0";
my($intwifiname)="ebike-router-1";
my($iwireint)="wlan0";
# Interface 3G
my($i3g)="wlan2";
# Commandes
my($cmdifconfig)="/sbin/ifconfig";
my($cmdiwconfig)="/sbin/iwconfig";
my($cmdiptables)="/sbin/iptables";
my($cmddhclient)="/sbin/dhclient";
my($cmdip)="/sbin/ip";
my($cmdroute)="/sbin/route";
# Configuration de l'interface lan
if ($ilandhcp eq "true")
{
system("sudo $cmddhclient $ilan");
$ilanip=get_interface_ip($ilan);
my($tmp)=get_default_gw();
if ($tmp eq "")
{
system("sudo $cmdroute add default gw $ilangw");
$ilangw=$tmp;
}
}
else
{
system("sudo $cmdifconfig $ilan $ilanip up");
$ilanip=get_interface_ip($ilan);
my($tmp)=get_default_gw();
if ($tmp eq "")
{
system("sudo $cmdroute add default gw $ilangw");
$ilangw=$tmp;
}
}
# Configuration du wifi interne
system("sudo nohup hostapd /etc/hostapd/hostapd.conf &");
system("sudo $cmdifconfig $iwireint 192.168.10.1 netmask 255.255.255.0");
system("sudo /etc/init.d/isc-dhcp-server restart");
system("sudo /etc/init.d/bind9 restart");
# Configuration du forwading du wifi int vers le réseau lan
Télécom Bretagne
34
system("echo 1 >/proc/sys/net/ipv4/ip_forward");
#initialisation des chaines INPUT, FORWARD et OUTPUT
system("$cmdiptables -F");
system("$cmdiptables -X");
system("$cmdiptables -P INPUT DROP");
system("$cmdiptables -P FORWARD DROP");
system("$cmdiptables -P OUTPUT ACCEPT");
system("$cmdiptables -A INPUT -i lo -j ACCEPT");
system("$cmdiptables -A OUTPUT -o lo -j ACCEPT");
system("$cmdiptables -N MAregle");
system("$cmdiptables -A MAregle -m state --state NEW -i! $ilan -j ACCEPT");
system("$cmdiptables -A MAregle -m state --state ESTABLISHED,RELATED -j ACCEPT");
system("$cmdiptables -A INPUT -j MAregle");
system("$cmdiptables -A FORWARD -j MAregle");
#initialisation de la chaine NAT
system("$cmdiptables -t nat -F");
system("$cmdiptables -t nat -X");
system("$cmdiptables -t nat -P PREROUTING ACCEPT");
system("$cmdiptables -t nat -P POSTROUTING ACCEPT");
system("$cmdiptables -t nat -P OUTPUT ACCEPT");
#initialisation de la chaine MANGLE
system("$cmdiptables -t mangle -F");
system("$cmdiptables -t mangle -X");
system("$cmdiptables -t mangle -P PREROUTING ACCEPT");
system("$cmdiptables -t mangle -P OUTPUT ACCEPT");
#NAT de tout ce qui arrive vers l'interface ilan
system("$cmdiptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o $ilan -j MASQUERADE");
# Get the ip adress of an interface given in parameter
sub get_interface_ip
{
my $ip="0.0.0.0/0";
($ip) = `sudo $cmdip -f inet -o addr show $_[0]` =~ /inet\s*(\S*)\s*scope/;
return $ip;
}
# Get the default gateway
sub get_default_gw
{
my $ip="0.0.0.0/0";
($ip) = `sudo $cmdroute -n` =~ /\n0.0.0.0\s*(\S*)\s*/;
return $ip;
}
Télécom Bretagne
35
ANNEXE 3 - EQUIPEMENTS DIVERS
A3.1.
SUPPORT DE FIXATION DU SMARTPHONE
A3.2.
BATTERIE D’ALIMENTATION EXTERNE DU SMARTPHONE ET DU
ROUTEUR
Télécom Bretagne
36
Bibliographie
Support de fixation sur guidon retenu :
[1] http://www.holdersandmounts.co.uk/herbert-richter-universal-gooseneck-bike-mount-with-phonesecure-1629.html
[2] Batteries externes utilisées :
http://www.crazyphonic.com/fr/product/15610/novodio-purewatt-5000-blanche-batterie-externe-5000mah-ipodiphone.html
http://www.crazyphonic.com/fr/product/20816/novodio-purewatt-ultra-batterie-externe-11-000-mahpour-appareils-mobiles.html
La technologie de streaming (principes et protocoles) :
[3] http://www.rap.prd.fr/pdf/technologie_streaming.pdf
[4]
https://publications.theseus.fi/bitstream/handle/10024/7775/Yassine_Bechqito_HIGH_DEFINITION_VI
DEO_STREAMING_USING_H.264_VIDEO_COMPRESSION.pdf?sequence=1
La gestion de la mobilité en IPv6 :
[5] http://livre.g6.asso.fr/index.php/La_gestion_de_la_mobilit%C3%A9_IPv6
La gestion d’interfaces réseau multiples sur Android :
[6] http://mobisocial.stanford.edu/news/2011/03/let-wifi-and-3g-connection-work-together-by-hackingconnectivityservice-java/
La gestion d’interfaces réseau multiples sur Linux :
[7] http://natisbad.org/dyn-net/index.html
Installation de NEMO sur Linux :
[8] http://www.umip.org/docs/umip-install.html
Les applications de streaming open-source existantes sur Android :
[9] http://code.google.com/p/ipcamera-for-android/
[10]http://code.google.com/p/spydroid-ipcamera/
Le projet Red5 :
[11] http://www.red5.org/
Les cartes ALIX de PC Engines :
[12] http://pcengines.ch/alix.htm
Les débits de la 3G en France :
[13] http://www.reseaux-telecoms.net/actualites/lire-les-vrais-debits-des-trois-reseaux-3g-en-france22329.html
Télécom Bretagne
37
Télécom Bretagne
38