Projets de spécialité Information et Communications : Différence entre versions

De Ensiwiki
Aller à : navigation, rechercher
Ligne 4 : Ligne 4 :
  
 
Vous êtes sur la page des  [[Projets de spécialité - 2A|projets de spécialité]] « Information et Communications ».
 
Vous êtes sur la page des  [[Projets de spécialité - 2A|projets de spécialité]] « Information et Communications ».
 +
 +
== Présentation ==
 +
 +
Cette thématique à pour objectif de vous offrir des projets mêlant traitement de l'information et communications pour aborder des sujets comme les réseaux de '''capteurs''', les équipements '''mobiles''', les communications '''sans fil''', la '''simulation''' de grands systèmes, parmi d'autres suivant les propositions.
 +
 +
Nous disposons de matériel, notamment des nœuds capteurs '''TI eZ430''' (entre autres), des '''Raspberry Pi''', des '''BeagleBoard-xM''', et des '''Arduino Due''', qui peuvent vous inspirer des sujets peut-être.
  
 
== Sujets 2016 ==
 
== Sujets 2016 ==

Version du 26 avril 2016 à 01:25

AttentionCette page est maintenue par les enseignants et utilisée par les élèves de la matière concernée. Vos contributions sont les bienvenues, mais merci d'en discuter avant de faire des modifications non triviales de la page, pour être sûr de ne pas perturber le déroulement du cours.

CDROM.png  Projets de spécialité  Mycomputer.png  Deuxième Année  CDROM.png  Informatique 

Vous êtes sur la page des projets de spécialité « Information et Communications ».

Présentation

Cette thématique à pour objectif de vous offrir des projets mêlant traitement de l'information et communications pour aborder des sujets comme les réseaux de capteurs, les équipements mobiles, les communications sans fil, la simulation de grands systèmes, parmi d'autres suivant les propositions.

Nous disposons de matériel, notamment des nœuds capteurs TI eZ430 (entre autres), des Raspberry Pi, des BeagleBoard-xM, et des Arduino Due, qui peuvent vous inspirer des sujets peut-être.

Sujets 2016

Backend local pour réseau LoRa

Contact : Martin Heusse

L'objectif de ce projet de spécialité est la mise en œuvre d'un backend local de collecte de trafic généré par un réseau LoRa. Par défaut, le trafic LoRa est remonté vers des serveurs "cloud" qui met ensuite les données à disposition des utilisateurs. Or, pour faire des mesures de qualité de communication et de bas niveau, il est plus satisfaisant de traiter directement les paquets en local.

Le code des gateways LoRa est disponible libre, ce qui permet de diriger le trafic en sortie de gateway vers le serveur voulu. Ensuite, le but du projet est de proposer des traitement simples et modulaire des informations remontées pour en extraire tout type de métrique.

Le travail comprendra également la réalisation du code nécessaire sur les "devices" LoRa pour générer le trafic voulu.

Matériel mis à disposition : 1 gateway LoRa, quelques LoRamotes IMST.

Références

Positionnement de capteurs dans la plate-forme WalT

Contacts : Martin Heusse, Pierre Brunisholz, Etienne Dublé

La plateforme d'expérimentation WalT permet de déployer et récupérer les sorties de capteurs sans fils. Cette plateforme est légère, peu onéreuse et facilement reproductible. Elle permet de déployer à la demande du code sur des capteurs, analyser les traces et représenter les échanges dans une interface graphique basée sur Cooja.

Travail à réaliser

L'objectif est de récupérer les positions relatives des nœuds, soit par l'analyse de la puissance du signal reçu lors d'échanges entre les capteurs, soit en utilisant directement la radio embarquée par la carte de supervision (Rasberry Pi) pour extraire une information similaire. À partir de ces sorties, on peut déterminer des position relatives qui pourront être utilisées dans l'interface de visualisation.

Le travail inclura la manipulation des applications embarquées par les capteurs pour remonter les bonnes informations, générer un trafic intéressant et aboutir finalement à une bonne illustration du fonctionnement d'un réseau multi-saut.

Optimisation de qemu pour la plate-forme WalT

Contacts : Etienne Dublé

Le logiciel qemu est capable d'émuler un système complet (full system emulation) ou simplement une architecture de CPU (user mode emulation). Ce dernier type d'émulation permet de faire tourner un programme compilé pour un CPU donné sur une machine doté d'une architecture différente. La plateforme d'expérimentation WalT utilise cette technique pour virtualiser un système d'exploitation de carte Raspberry Pi (architecture ARM) sur un serveur classique (x86), dans un conteneur docker.

Travail à réaliser

Pour chaque binaire ARM à lancer, une nouvelle instance de l'émulateur qemu est lancée, ce qui paraît loin de l'optimal en matière de performance. En effet, afin d'exécuter le binaire ARM, qemu doit traduire les instructions ARM en instructions x86 à la volée. Le résultat de cette traduction est perdu quand l'exécution se termine. Si on relance le même binaire ARM, la même traduction doit être effectuée de nouveau. L'objectif du travail est de ré-architecturer le logiciel qemu et d'étudier le gain en performance apporté. Par exemple, qemu pourrait sauvegarder (sur disque ou dans une mémoire partagée), pour chaque binaire lancé, le code binaire traduit associé, de manière à pouvoir le réutiliser au prochain lancement de ce même binaire.

Ajouter SCTP à IPMT

Contact : Franck Rousseau

IPMT est une boite à outils pour la mesure de performances sur les réseaux IP. Actuellement, seuls TCP et UDP sont supportés. Ce sujet à pour objectif d'ajouter le support du protocole SCTP à IPMT, et d'évaluer les performances obtenues dans certains scénarios typiques. SCTP est un protocole déjà ancien standardisé dans le RFC 4960, et le RFC 3758 pour son extension de fiabilité partielle.

Bien que resté longtemps confiné au domaine des télécoms, SCTP gagne aujourd'hui en popularité grace à son adoption dans le cadre du standard WebRTC (au W3C), où il sert au transport de données point à point, via les WebRTC data channels (au W3C, le draft IETF).

On pourra essayer de reproduire des expérimentations telles que celles décrites dans le document SCTP performance test - MP3 audio over RTP. Si le temps et/ou le nombre d'étudiants le permettent, on pourra envisager la même chose pour MPTCP défini dans le RFC 6824 et DCCP standardisé par le RFC 4340.