1. APISENSE®
Une plate-forme répartie pour la conception, le déploiement et
l’exécution de campagnes de collecte de données sur des
terminaux intelligents
Nicolas Haderer
Soutenance de thèse
5 Novembre 2014
Rapporteurs : Chantal Taconet, TELECOM SudParis
Ernesto Exposito, INSA Toulouse
Examinateurs : Stéphane Frénot, INSA Lyon
Luigi Lancieri, Université Lille I
Directeur de thèse : Lionel Seinturier, Université Lille I
Romain Rouvoy, Université Lille I
1

2. Les données : Le nouveau pétrole de demain
2
700
milliards
minutes/mois
2,9
millions
mails/seconde
24
pétaoctets
traitées/jour
426
achats/seconde
20
heures/minute
50 millions
tweets/jour
2013
• 1,1 exaoctets de données
2019
• 5,6 milliards de smartphones
• 12 exaoctets de données
4,5 millions / jour
(source : ericsson,2013)

3. Les smartphones : Une plate-forme de collecte idéale
3Contexte (2/4)
Interaction
Mouvement
Magasin d’applications
Des millions d’utilisateurs à la portée de tous !
Point d’intérêts
Mode de transport

4. Mobile crowdsensing (MCS)
4Contexte (3/4)
• MCS fait référence à l’ensemble des applications qui
impliquent des citoyens ordinaires, munis de leurs terminaux
intelligents, afin de collecter et de partager des données dans
le but de mesurer des phénomènes d’un intérêt commun
[Ganti11] Mobile crowdsensing : Current state and future challenges. Communications Magazine, IEEE. 2011
• De nombreuses perspectives de recherche
– Étude de la mobilité urbaine
– Surveillance de l'environnement (pollution/sonore)
– Surveillance épidémiologique
– Étude des comportements socioculturels

5. Classification des applications
• La collecte peut prendre différentes formes
– Participative : l’utilisateur détermine (où , quand, comment) une donnée
est collectée
– Opportuniste : l’application collecte les données automatiquement
5
Individuelle Communautaire
• Et elle peut s’effectuer à plusieurs échelles
Contexte (4/4)

6. Problématiques
• Applications monolithiques
6Problématiques (1/2)

7. Problématiques
• Le développement d’une application de collecte reste difficile
7
Vie privéeÉnergie Incitation
Développement
(client + serveur)
Diffusion
Exploitation
Persistence
Propagation
Exécution
???
Problématiques (2/2)

8. Plan
8
1. Contexte
2. Problématiques
3. État de l’art
4. Contributions
5. Validation
6. Conclusion et perspectives

9. Développement des applications de collecte
• Approches génératives [Funf]
• Approches déclaratives [MyExperience, Medusa]
• Approches scriptées [Pogo]
9Etat de l’art (1/5)
• Mais
– Expressivité souvent limitée (opportuniste ou participative)
[Medusa]: Medusa: A programming framework for crowd-sensing applications, Ra et al., MobiSys, 2012
[Pogo]: Pogo, a middleware for mobile phone sensing, Brouwers et al., Middleware, 2012
[MyExperience]: MyExperience: a system for in situ tracing and capturing of user feedback on mobile phones, Froehlich et al., MobiSys, 2007
[Funf]: Social fMRI: Investigating and shaping social mechanisms in the real world, Aharony et al., Pervasive and Mobile Computing, 2011

10. Diffusion des applications de collecte
• Approches dites ‘pull-based’ [Anonysense, Medusa]
– Améliore la protection de la vie privée
– Temps de propagation lent
10Etat de l’art (2/5)
[PRISM]: PRISM : platform for remote sensing using smart-phones, Das et al., MobiSys, 2010
[Anonysense]: Anonysense : A system for anonymous opportunistic sensing, Shin et al., Pervasive and Mobile Computing, 2011
• Approches dites ‘push-based’[PRISM, Pogo]
– Temps de propagation rapide
– Grande consommation énergétique
– Risques liés à la vie privée

11. Acceptation des applications
• Protection de la vie privée
– Mécanisme de contrôle d’accès [PRISM, Pogo]
– Utilisation d’un identifiant anonyme [Medusa]
– K-anonimity [Anonysense]
11Etat de l’art (3/5)
• Conservation des ressources énergétiques
– Algorithme adaptatif [Carreras13]
• Modèle de récompense
– Récompense financière [Medusa]
[Carreras13] Matador : Mobile task detector for context-aware crowd-sensing campaigns. PERCOM. 2013

12. Limites des architectures proposées
12Etat de l’art (4/5)
• Les architectures proposées manquent de flexibilité
– L’infrastructure est imposée (base de données, ressources)
– Problème du passage à l’échelle du système
– Problème légal et de sécurité

13. Récapitulatif
13Etat de l’art (5/5)
Funf MyExperience Medusa Anonysense PRISM Pogo APISENSE
Coût de
développement
Généralité
Acceptation
Hétérogénéité
Passage à
l’échelle
Flexibilité
+ + + + + – – +
– – – – – + + –
– – – – + + + + +
– – + + + – – – + +
NA – – + – + –
NA – – – – – – – – – –
++
++
++
++
++
++

14. Plan
14
1. Contexte
2. Problématiques
3. État de l’art
4. Contributions
5. Validation
6. Conclusion et perspectives

15. Vue d’ensemble des contributions
15Contributions (1/4)
Nœud central
administrateur
participants
Nœud de
collecte
déploie
Nœud de
collecte
1. Configuration d’une architecture dédiée 2. Interface de programmation de haut niveau
crée une collecte
publie
une tâche de collecte
3. Environnement d’exécution et de déploiement
déploie une tâche
de collecte
données collectées
envoie les
données collectées
4. Coordination des tâches de collecte

16. Configuration d’une architecture dédiée
• Objectifs
– Favoriser la réutilisation et l’extension du système
– Gérer la variabilité des campagnes de collecte
16Contributions (1/4)
Environnement de
développement
Modèle
de recrutement
Anonymisation
Modèle de récompense
Indexation des données
Traitement, Visualisation,
Exposition

17. Bibliothèque de composant logicielle SCA
(Service Component Architecture)
17Contributions (1/4)
Data
Processing
Database
Data
Handler
Collector
GeoIndex
HTTPS
REST
[MacKenzie06] Reference model for service-oriented architecture 1.0. OASIS Standard. 2006

18. Modèle de variabilité d’une campagne de collecte
18Contributions (1/4)
Data Campaign
Development Recruitment Service
CodeEditor
Form Individual
Community
Online
Processing
Collector
Statistic
Incentive
Privacy
DateIndex UserIndex
Badge
Ranking Perturbation
MixZone
GeoIndex
Export
Query Visualisation
XML
CSV
JSON
Map Chart
[Pohl05] Software product line engineering : foundations, principles, and techniques. Springer. 2005

19. Processus de génération d’une architecture SCA
19Contributions (1/4)
Nœud de collecte
4. Assemblage
• 4 étapes
3. Instantiation
1. Selection2. Validation

20. Vue d’ensemble des contributions
20Contributions (2/4)
Nœud central
administrateur
participants
Nœud de
collecte
déploie
Nœud de
collecte
1. Configuration d’une infrastructure dédiée 2. Interface de programmation de haut niveau
crée une collecte
publie une
tâche de collecte
3. Environnement d’exécution et de déploiement
déploie une tâche
de collecte
données collectées
envoie les
données collectées
4. Coordination des tâches de collecte

21. 2. Interface de programmation de haut niveau
21Contributions (2/4)
• Objectifs
– Généralité
– Accessibilité
– Portabilité
• Approche
– Modèle de programmation de haut niveau
– Interface de programmation basée sur JavaScript

22. Concept du modèle de programmation
22Contributions (2/4)
Location
User
Interaction
Device
State
Save Track
Media
Capture
Survey Notify
Facade
ActionEvent listener
onLocationChange
onBatteryStateChange
onNetworkStateChange
onPhoneCall
publish event
act
Battery
State
subscribe

23. Interface de programmation APISENSE (1/3)
• Collecte opportuniste de données
23Contributions (2/4)
$location.onLocationChange(function(event){
$trace.add({
lat : event.latitude,
lng : event.longitude,
signal : $telephony.signalStrength()
});
});
Écoute des évènements de position
Façades
Collecte d’une donnée

24. Interface de programmation APISENSE (2/3)
• Collecte participative de données
24Contributions (2/4)
$phone.onCallFinish(function(){
var survey = $survey.create();
survey.close(‘Qualité ?’,
[‘Mauvaise’,’Moyenne’,’Bonne’]);
$survey.publish();
});

25. Interface de programmation APISENSE (3/3)
• Retour utilisateur
25Contributions (2/4)
var chartLib = require("lib-chart.js");
var chart = chartLib.area();
$ui.publish(chart);
$telephony.onSignalStrengthChanged(function(event){
chart.add({ x : event.time, y : event.level });
});

26. Vue d’ensemble des contributions
26Contributions (3/4)
Nœud central
administrateur
participants
Nœud de
collecte
déploie
Nœud de
collecte
1. Configuration d’une infrastructure dédiée 2. Interface de programmation de haut niveau
crée une collecte
publie une
tâche de collecte
3. Environnement d’exécution et de déploiement
déploie une tâche
de collecte
données collectées
envoie les
données collectées
4. Coordination des tâches de collecte

27. 3. Environnement de déploiement et d’exécution
27Contributions (3/4)
Serveur central
Nœud de
collecte
Propriétés
1. Personnel (nom, âge)
2. Capteurs (GPS, caméra)
3. Disponibilité (zone, période)
Propriétés
1. Globale (nom, description…)
2. Recrutement (capteurs, ville…)
3. Contexte (zone, période)
Temporelle Capteurs Géographique
inscription
du participant
Inscription
d’une tâche
notifie la tâche
de collecte
collecte les données
Règles de confidentialité
010011010101010101010101000110110101010010110

28. Vue d’ensemble des contributions
28Contributions (4/4)
Serveur central
administrateur
participants
Nœud de
collecte
déploie
Nœud de
collecte
1. Configuration d’une infrastructure dédiée 2. Interface de programmation de haut niveau
crée une collecte
publie une
tâche de collecte
3. Environnement d’exécution et de déploiement
déploie une tâche
de collecte
données collectées
envoie les
données collectées
4. Coordination des tâches de collecte

29. 4. Coordination des tâches de collecte
• Objectifs
– Equilibrer les charges énergétiques entre les dispositifs mobiles
– Diminuer la quantité de données dupliquer remontée sur le serveur
29Contributions (4/4)

30. Extension du modèle de programmation
30Contributions (4/4)
accept(function( ) {
if ($network.connectionType() == ‘Mobile’)
return {battery : $battery.level()};
};
ranking(function(users){
return users.sort(‘battery’);
};
sense(function( ) { … } )sense
recruit
coverage
geoCoverage(
[[50.614291,3.13282],[50.604159,3.15239]],
‘500 m’);
timeCoverage("30 min","1 H");
duplicate(1);

31. Processus de coordination : 4 étapes
31Contributions (4/4) 31
Vs0,0 Vs1,0 Vs2,0
Vs0,1 Vs1,1 Vs2,1
1. Génération des capteurs virtuels [Chowdhury10]
geoCoverage
[Chowdhury10] A survey of network virtualization. Computer Networks. 2010

32. Processus de coordination : 4 étapes
32Contributions (4/4) 32
Vs0,0 Vs1,0 Vs2,0
Vs0,1 Vs1,1 Vs2,1
1. Génération des capteurs virtuels
2. Connexion
[Chowdhury10] A survey of network virtualization. Computer Networks. 2010

33. Processus de coordination : 4 étapes
33Contributions (4/4) 33
Vs0,0 Vs1,0 Vs2,0
Vs0,1 Vs1,1 Vs2,1
1. Génération des capteurs virtuels
2. Connexion
3. Assignation
93 %
58 %
timeCoverage
accept
[Chowdhury10] A survey of network virtualization. Computer Networks. 2010

34. Processus de coordination : 4 étapes
34Contributions (4/4) 34
Vs0,0 Vs1,0 Vs2,0
Vs0,1 Vs1,1 Vs2,1
1. Génération des capteurs virtuels
2. Connexion
3. Assignation
duplicate
sense
4. Exécution
[Chowdhury10] A survey of network virtualization. Computer Networks. 2010
ranking

35. Plan
35
1. Contexte
2. Problématiques
3. État de l’art
4. Contributions
5. Validation
6. Conclusion et perspectives

36. Validation
1. Validation de l’expressivité de l’interface de programmation
2. Évaluation du modèle de coordination
3. Cas réel d’utilisation entre science informatique et sociale
36Evaluation

37. Implémentation de 6 campagnes
37Evaluation (1/3)
Nom Caractéristique LoC
WiFi-Bluetooth Scanner
Opportuniste
Collecte périodique
4
Citoyen journaliste
Participative
Questionnaire
10
Qualité Réseau Opportuniste/Participative 27
Exploiter des capteurs
externes
Réutilisation
Communications avec un robot
Lego MindStorms NXT
22
Inférence contextuelle Traitements complexes 30

38. Comparaison de l’expressivité et du nombre de lignes de code
38Evaluation (1/3)
W/B-Scanner
opportuniste
Citoyen Journaliste
participative
Mode de collecte
APISENSE 4 9
Participative
Opportuniste
Anonysense 5 X Opportuniste
Pogo 4 X Opportuniste
MyExperience X 27 Participative
Medusa X 45 Participative
PRISM ?? 330
Participative
Opportuniste

39. Évaluation du modèle de coordination
39Evaluation (2/3)
• Objectifs
– Quantité de données propagées
– Couverture des données
– Energie utilisée
• Traces réelles de mobilité
– 10 000 taxis dans la région de Pékin
• 3 approches
– Individuelle : pas de coordination (témoin)
– Coll(500) : objectif de couverture de 500 mètres
– Coll(1000) : objectif de couverture de 1000 mètres

40. Résultat : Quantité de données propagées
40Evaluation (2/3)
Diminution de 50–80% de la quantité de données propagées
Comparaison de la quantité de données collectées
en fonction du nombre de dispositifs
80%
50%

41. Résultat : Couverture géographique
La perte de la couverture obtenue ne varie pas au delà des 2%
41Evaluation (2/3)
Comparaison de la couverture géographique selon
différentes périodes de la journée
2%

42. 82 %
Résultat : Gain énergétique
42Evaluation (2/3)
Jusqu’à 82 % de gain énergétique
[Lin10] Energy-accuracy trade-off for continuous mobile device location. MobiSys. 2010
[Balasubramanian09] Energy consumption in mobile phones : A measurement study and implications for network applications.
Internet measurement conference. 2009
Comparaison des moyennes de la consommation énergétique

43. PRACTIC
(PRAtiques CulTurelles et usages de l’Informatique Connectée)
43Evaluation (3/3)
• Objectifs
– Comprendre l’usage des technologies numériques connectées en
matière d’habitudes et de routines de consommations culturelles et
médiatiques
– Apport des méthodes numériques dans les sciences humaines
• Équipe pluridisciplinaire
– Sciences humaines et de l’information
– Sciences informatique

44. Développement de l’étude
44Evaluation (3/3)
Collecte opportuniste des données
● Activation de l’écran utilisateur
● Performance réseau
● Appel / SMS
● Application
● Batterie
● Statistiques des dispositifs mobiles
Collecte participative ( ~130 Q)
● Démographie
● Rythmes de vie
● Équipements
● Pratiques culturelles
● Vie privée
Récompense / Retour utilisateur

45. Statistiques de déploiement
88 utilisateurs du 10 mars au 21 avril 2014
45Evaluation
45 modèles de smartphones
36 cas d’étude valides
7 % de code spécifique

46. Conclusion
46
• APISENSE®
– Architecture répartie scalabilité, vie privée
– Ligne de produits logiciel +SCA flexibilité, généralité
– API de haut niveau coût développement , hétérogénéité
– Environnement d’exécution mobile vie privée, énergie
– Coordination des tâches de collecte scalabilité, énergie

47. Perspectives
47
• À court / moyen terme
– Support pour les plateformes iOS, Windows phone
– Amélioration de la sécurité
– Implémentations et évaluations de modèles : vie privée, incitation
• À long terme
– Abstraire davantage le modèle de programmation
– Qualité de service
– Comment utiliser le mobile crowd sensing pour des systèmes critiques ?

48. Publications
48
Dynamic Deployment of Sensing Experiments in the Wild Using
Smartphones. Nicolas Haderer, Romain Rouvoy and Lionel Seinturier.
In 13th International IFIP 16 Conference on Distributed Applications
and Interoperable Systems (DAIS), pages 43-56.
A Federated Multi-Cloud PaaS Infrastructure.
Fawaz Paraiso, Nicolas Haderer, Phi- lippe Merle, Romain Rouvoy,
Lionel Seinturier. In 5th IEEE International Confe- rence on Cloud
Computing (2012), pages 392-399.
A Cloud-based Infrastructure for Crowdsourcing Data from Mobile
Devices. Nicolas Haderer, Fawaz Paraiso, Christophe Ribeiro, Philippe
Merle, Romain Rouvoy, Lionel Seinturier Wenjun Wu. Cloud-based
Software Crowdsourcing, Springer, 2014 (To appear)
A preliminary investigation of user incentives to leverage
crowdsensing activities. Nicolas Haderer, Romain Rouvoy and Lionel
Seinturier. 2nd International IEEE PerCom Workshop on Hot Topics in
Pervasive Computing (PerHot) (2013), pp. 199-204.
Towards Multi-Cloud Configurations Using Feature Models and
Ontologies. Clément Quinton, Nicolas Haderer, Romain Rouvoy and
Laurence Duchien. In Proceedings of the 1st International Workshop
on Multi-Cloud Applications and Federated Clouds, Multi-Cloud’13.
Prague, Czech Republic, 22 April 2013, pp. 21-26.
Vulgarisation scientifique
Chapitre de livre Conférence
Worshop
APISENSE : Crowd-Sensing Made Easy. Nicolas Haderer, Romain
Rouvoy, Chris- tophe Ribeiro, Lionel Seinturier. ERCIM News, ERCIM,
2013, Special theme : Mobile Computing, 93, pp. 28-29.
Le capteur, c’est vous! Nicolas Haderer, Christophe Ribeiro, Romain
Rouvoy, Simon Charneau, Vassili Rivron, Alan Ouakrat, Sonia Ben
Mokhtar, Lionel Seinturier L’Usine Nouvelle, L’Usine Nouvelle, 2013,
3353, pp. 74-75
Campagne de collecte de données et vie privée. Nicolas Haderer,
Miguel Nuñez Del Prado Cortez, Romain Rouvoy, Marc-Olivier Killijian
and Matthieu Roy. 3ème Journées du GDR CNRS GPL (2012), pp. 253-
254.