Développement d’un module pour la définition et la collecte des KPIs pour l’analyse de la performance du réseau sur une passerelle dédiée aux objets connectés

1. Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
  
Université de Carthage
  
Institut National des Sciences
Appliquées et de Technologie
Projet de Fin d’Etudes
Pour l’obtention du
Diplôme National d’Ingénieur
en Sciences Appliquées et en Technologie
Filière : Réseaux Informatique et Télécommunications
Sujet :
Développement d’un module pour la définition et la
collecte des KPIs pour l’analyse de la performance du
réseau sur une passerelle dédiée aux objets connectés
Réalisé par : Mounir BEN ZAIED
Entreprise d’accueil :
Télécom Bretagne
Soutenu le 03/10/15
Responsable à l’entreprise : Alexander PELOV
Responsable à l’INSAT: Souheib YOUSFI
Année Universitaire : 2014/2015

2. DEDICACES
Je d´edie ce travail ...
`A ma m`ere
Aucune d´edicace ne pourra traduire ma profonde affectation et ma grande
reconnaissance pour tes interminables sacrifices tant pour mon ´education
que pour mon bien ˆetre. Tu es pour moi le symbole de la tendresse et du
d´evouement familial qui m’a toujours rempli d’admiration. Je suis tellement
fier d’ˆetre ton fils que je ne peux en mesurer le bonheur. J’esp`ere que tu
trouveras dans ce travail le fruit de tes efforts. Que Dieu te prot`ege et
t’accorde sant´e et longue vie.
`A mon p`ere
Puisse ce travail te t´emoigner mon amour, ma reconnaissance et mon
admiration pour ton d´evouement, tes qualit´es humaines et ta culture, qui
font de toi un p`ere exemplaire et qui me serviront de guide dans ma carri`ere
et dans ma vie. C’est grˆace `a tes sacrifices, ta patience, ton encouragement
et tes pri`eres que je suis arriv´e `a franchir cette premi`ere grande ´etape de ma
vie. Que Dieu, le tout puissant, te garde, te procure sant´e, bonheur et longue
vie.
`A ma sœur
Aucune d´edicace ne saurait exprimer mon admiration, mon profond amour
fraternel et mon immense attachement. Que ce travail soit un t´emoin de
mon affection sinc`ere.

3. Remerciements
Avant tout d´eveloppement sur cette exp´erience professionnelle, il apparaˆıt opportun de
commencer ce rapport par des remerciements, `a ceux qui ont contribu´e, de pr`es ou de loin, `a
la r´ealisation de ce travail, `a ceux qui m’ont beaucoup appris durant cette p´eriode et `a ceux
qui ont eu la gentillesse de faire de cette exp´erience un moment tr`es profitable.
Notamment, j’exprime ma profonde gratitude `a monsieur le chef de d´epartement R´eseaux,
S´ecurit´e et Multim´edia `a T´el´ecom Bretagne M.Jean Marie Bonnin de m’avoir accord´e le pri-
vil`ege d’acc´eder `a cet honorable ´etablissement dans le cadre de ce projet de fin d’´etudes.
Je tiens ´egalement `a exprimer mes sentiments de gratitude et de reconnaissance `a mes
tuteurs `a T´el´ecom Bretagne Mr.Alexander Pelov M.Laurent Toutain M.Mathieu Goessens
et M.Renzo Navas pour leurs pr´ecieuses instructions et pour leur assistance pendant le
d´eroulement de mon projet.
Mes remerciements les plus sinc`eres s’adressent `a mon encadrant `a l’INSAT M.Souheib
Yousfi pour m’avoir guid´e et orient´e tout au long de ce travail.
Qu’il me soit permis ´egalement de remercier tous les ing´enieurs, les techniciens et les
doctorants `a T´el´ecom Bretagne, pour leur soutien pr´ecieux et leurs riches conseils.
Je suis particuli`erement reconnaissant `a l’Institut National des Sciences Appliqu´ees et de
Technologie (INSAT) pour m’avoir offert l’opportunit´e d’acqu´erir cette exp´erience qui, sans
doute, me sera d’un grand apport dans ma vie professionnelle.

4. Table des mati`eres
Liste des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction g´en´erale 1
I Cadre du projet 3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1 Pr´esentation de la structure d’accueil . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Axes de recherches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Collaboration internationale . . . . . . . . . . . . . . . . . . . . . . . 5
2 Pr´esentation du projet LORA FABIAN . . . . . . . . . . . . . . . . . . . . . 5
2.1 ´Equipe du projet LORA FABIAN . . . . . . . . . . . . . . . . . . . . 6
2.2 Partenaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Contraintes et ´etat actuel du projet . . . . . . . . . . . . . . . . . . . 6
3 Pr´esentation de la mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Les tˆaches principales . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 M´ethode de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Diagramme de Gannt . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Internet des objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 D´efinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Approche historique . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Couches protocolaires existantes . . . . . . . . . . . . . . . . . . . . . 11
4.4 D´eveloppements technologiques dans l’Internet des objets . . . . . . . 12
4.5 Exemples d’applications . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6 Impacts de l’Internet des objets . . . . . . . . . . . . . . . . . . . . . 16
4.7 ´Evaluation de performances dans l’Internet des objets . . . . . . . . . 17
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
II Sp´ecification des besoins et conception 19
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1 Sp´ecification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 21
2 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1 Pr´esentation des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Description des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 22
3 Diagramme de s´equence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Diagramme de s´equence fonctionnel . . . . . . . . . . . . . . . . . . . 25
3.2 Diagramme de s´equence applicatif . . . . . . . . . . . . . . . . . . . . 26
4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5. 4.1 Description des classes . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Interop´erabilit´e dans le r´eseau LORA FABIAN . . . . . . . . . . . . . . . . . 31
5.1 Architecture du r´eseau LORA FABIAN . . . . . . . . . . . . . . . . . 31
5.2 ´El´ements du r´eseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Standards utilis´es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Prolongement des web objets vers les capteurs . . . . . . . . . . . . . 38
5.5 Format des paquets dans le r´eseau LORA FABIAN . . . . . . . . . . 42
5.6 Types de trames circulant dans le r´eseau . . . . . . . . . . . . . . . . 46
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
IIIImpl´ementation 49
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
1 R´ealisation de la librairie pour la g´en´eration du trafic vers la passerelle . . . 50
1.1 Pr´esentation des outils utilis´es . . . . . . . . . . . . . . . . . . . . . . 50
1.2 Pr´esentation de la tˆache . . . . . . . . . . . . . . . . . . . . . . . . . 51
2 D´efinition, extraction et enregistrement des KPI . . . . . . . . . . . . . . . . 55
2.1 Pr´esentation des outils utilis´es . . . . . . . . . . . . . . . . . . . . . . 55
2.2 Pr´esentation de la tˆache . . . . . . . . . . . . . . . . . . . . . . . . . 56
3 Analyse de la performance du r´eseau LoRa . . . . . . . . . . . . . . . . . . . 63
3.1 Pr´esentation des outils utilis´es . . . . . . . . . . . . . . . . . . . . . . 63
3.2 Pr´esentation de la tˆache . . . . . . . . . . . . . . . . . . . . . . . . . 64
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Conclusion g´en´erale 73
Bibliography 74

6. Table des figures
Figure 1.1: R´epartition des tˆaches du projet . . . . . . . . . . . . . . . . 9
Figure 1.2: Pile protocolaire pour l’Internet des objets . . . . . . . . . . 11
Figure 1.3: Pile protocolaire pour l’ancienne et la nouvelle de ZigBee . . 12
Figure 1.4: ´Evolution du M2M vers l’Internet des objets . . . . . . . . . 13
Figure 1.5: Technologies de communication dans l’Internet des objets . . 13
Figure 2.1: Diagramme de cas d’utilisation pour l’administrateur . . . . 23
Figure 2.2: Diagramme de cas d’utilisation pour l’utilisateur de la librairie 25
Figure 2.3: Diagramme de s´equence fonctionnel . . . . . . . . . . . . . . 26
Figure 2.4: Diagramme de s´equence applicatif . . . . . . . . . . . . . . . 27
Figure 2.5: Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . 28
Figure 2.6: Architecture g´en´erale du r´eseau LORA FABIAN . . . . . . . 31
Figure 2.7: Diff´erents participants dans le projet . . . . . . . . . . . . . . 32
Figure 2.8: Capteur Node-F . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 2.9: Module LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 2.10: Antenne LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 2.11: Avantage du protocole 802.15.4 . . . . . . . . . . . . . . . . . 37
Figure 2.12: Pile protocolaire du capteur vers la passerelle . . . . . . . . . 39
Figure 2.13: Liens entre les nœuds dans le r´eseau . . . . . . . . . . . . . . 40
Figure 2.14: Communication CoAP et HTTP dans LORA FABIAN . . . . 40
Figure 2.15: Nommage des ressources . . . . . . . . . . . . . . . . . . . . 41
Figure 2.16: Signalisation dans le r´eseau . . . . . . . . . . . . . . . . . . . 42
Figure 2.17: Trame MAC g´en´erale . . . . . . . . . . . . . . . . . . . . . . 43
Figure 2.18: Trame LoRa MAC . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 2.19: Format d’adresse de la passerelle . . . . . . . . . . . . . . . . 44
Figure 2.20: Champ de contrˆole . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 2.21: Frame Control pour les trames beacon . . . . . . . . . . . . . 45
Figure 2.22: Frame Control pour les trames ´emises par la Node-G . . . . . 45
Figure 2.23: Frame Control pour les trames re¸cues par la Node-G . . . . . 46
Figure 2.24: Trame balise LoRa Mac . . . . . . . . . . . . . . . . . . . . . 46
Figure 2.25: Trame de signalisation du Node-F vers la Node-G . . . . . . 47
Figure 2.26: Trame de donn´ee du Node-G vers la Node-F . . . . . . . . . 47
Figure 3.1: Diagramme de s´equence entre la station LoRa et la Gateway 52
Figure 3.2: Composants du JSON dans les paquets . . . . . . . . . . . . 53
Figure 3.3: Architecture de la librairie d´evelopp´ee . . . . . . . . . . . . . 53
Figure 3.4: Classes d´evelopp´ees pour la configuration de la librairie . . . 54
Figure 3.5: Envoi des paquets par la librairie . . . . . . . . . . . . . . . . 54
Figure 3.6: Initialisation des services au niveau de la Node-G . . . . . . . 58

7. Figure 3.7: D´emarrage des services au niveau de la Node-G . . . . . . . . 58
Figure 3.8: Passerelle en ´ecoute . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 3.9: V´erification de la taille des paquets re¸cus . . . . . . . . . . . 59
Figure 3.10: Application des r`egles de filtrage aux paquets `a la r´eception . 60
Figure 3.11: Acquittement sur les paquets re¸cus . . . . . . . . . . . . . . . 60
Figure 3.12: Enregistrement des KPIs dans la base de donn´ees . . . . . . . 61
Figure 3.13: Donn´ees enregistr´ees dans la table ReceivedpacketsStats . . . 61
Figure 3.14: Donn´ees enregistr´ees dans la table GeneralStats . . . . . . . 62
Figure 3.15: Envoi des paquets enregistr´es `a Logstash . . . . . . . . . . . 62
Figure 3.16: Envoi des KPIs vers Logstash . . . . . . . . . . . . . . . . . . 62
Figure 3.17: Fonctionnement de la pile ELK . . . . . . . . . . . . . . . . 63
Figure 3.18: Configuration de l’agent Logstash . . . . . . . . . . . . . . . 65
Figure 3.19: Lancement et r´eception des donn´ees par Logstash . . . . . . 65
Figure 3.20: D´emarrage d’Elasticsearch . . . . . . . . . . . . . . . . . . . 66
Figure 3.21: R´eception des donn´ees par Elasticsearch . . . . . . . . . . . . 66
Figure 3.22: Lancement du serveur HTTP pour Kibana . . . . . . . . . . 67
Figure 3.23: Page d’accueil de Kibana . . . . . . . . . . . . . . . . . . . . 67
Figure 3.24: Filtrage des logs en fonction du temps d’arriv´ee . . . . . . . . 68
Figure 3.25: KPIs enregistr´ees dans la base de donn´ees d’Elasticsearch . . 68
Figure 3.26: Courbe de RSSI en fonction du temps . . . . . . . . . . . . . 69
Figure 3.27: Histogramme de la taille des paquets en fonction du temps . 69
Figure 3.28: Regroupement des paquets selon leur ID/MAC/temps d’envoi 70
Figure 3.29: Statistiques avec Kibana . . . . . . . . . . . . . . . . . . . . 70
Figure 3.30: Classification des paquets selon leur Code Rate . . . . . . . . 71
Figure 3.31: Classification des paquets selon leur Data Rate . . . . . . . . 71
Figure 3.32: Exemple d’un tableau de bord choisi sur Kibana . . . . . . . 72

8. Abr´eviations
6LoWPAN IPv6 Low Power Wireless Personal Area Networks
AFNIC Association Fran¸caise pour le Nommage de l’Internet en Coop´eration
CoAP Constrained Application Protocol
CRC Cyclic Redundancy Check
CSV Comma-separated values
ELK Elasticsearch Logstash Kibana
ETSI European Telecommunications Standards Institute
HTTP Hypertext Transfer Protocol
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IP Internet Protocol
JSON JavaScript Object Notation
KPI Key Performance Indicators
LoRa Long Range
LORA FABIAN Long Range For A Beautiful Internet Advanced Network
LPWAN Low-Power Wide-Area Network
LSNR LoRa Signal-to-Noise Ratio
M2M Machine to Machine
NFC Near Field Communication
REST Representational State Transfer
RFID Radio-Frequency Identification
RSM R´eseaux S´ecurit´e Multim´edia
RSSI Radio Signal Strength Indication
TCP Transmission Control Protocol
UDP User Datagram Protocol
WSN Wireless Sensor Network

9. Introduction g´en´erale
Les r´eseaux `a faible consommation d’´energie ont v´ecu une grande ´evolution depuis le
d´ebut du XXI`eme si`ecle. De nombreux chercheurs se sont int´eress´es `a l’´etude de l’effica-
cit´e ´energ´etique et ont propos´e de nouvelles cartes r´eseaux sans fil `a faible consommation
d’´energie.
Cependant, la consommation ´energ´etique d’un nœud mobile ne d´epend pas seulement des
protocoles des couches physiques et liaison de donn´ees, mais aussi des protocoles des couches
sup´erieures. D’autre part, le d´eploiement de ces r´eseaux dans le monde r´eel a affront´e d’autres
obstacles que la consommation ´energ´etique comme les probl`emes de fiabilit´e et d’adressage.
Une premi`ere solution a ´et´e propos´ee en 2003 par ZigBee alliance. La sp´ecification ZigBee
a compl´et´e la norme IEEE 802.15.4 (Institute of Electrical and Electronics Engineers) en
lui ajoutant quatre composantes principales : la couche r´eseau, la couche application, les
p´eriph´eriques ZigBee et les objets applicatifs. Toutefois, cette solution n’a pas obtenu un
grand succ`es vu les probl`emes d’´evolutivit´e et d’int´egration avec le grand r´eseau IP (Internet
Protocol) du monde Internet.
En 2005, un nouveau groupe de travail `a l’IETF (Internet Engineering Task Force),
nomm´e 6LoWPAN (IPv6 LoW Power wireless Area Networks), a eu l’id´ee du d´eploiement
d’IPv6 dans les r´eseaux `a faible consommation d’´energie pour r´esoudre le probl`eme d’adres-
sage. Avec l’introduction d’IPv6, les nouveaux appareils sont devenus capables de communi-
quer aussi bien entre eux qu’avec tous les appareils IP `a l’int´erieur et `a l’ext´erieur du r´eseau
sans fil. Ces derniers, appel´es aussi objets intelligents, ont chang´e le concept de l’Internet
qui ne se limite pas qu’aux r´eseaux informatiques classiques, mais s’´etend `a tous les objets
de la vie quotidienne. L’extension de l’Internet `a tous les objets du monde r´eel repr´esente la
notion d’Internet des Objets.
De nos jours, la plupart des objets qui nous entourent ont la vocation d’ˆetre connect´es.
´Etant ´equip´es d’une puce ou d’un capteur, ils se mettent ainsi `a produire des donn´ees. Dans
ce contexte de l’Internet des objets, l’innovation est importante et c’est ainsi que de nom-
breuses applications voient le jour. Nous pouvons par exemple citer les r´eseaux de capteurs.
Les r´eseaux de capteurs sans fil WSN (Wireless Sensor Networks) ont durant la derni`ere
d´ecennie pris un rˆole sans cesse croissant, et d´esormais pr´epond´erant, dans de nombreuses
applications destin´ees `a mettre en place des environnements dits ”intelligents”.
Pour ˆetre efficaces, notamment dans ces applications, de tels r´eseaux doivent le plus
souvent faire intervenir un ensemble tr`es h´et´erog`ene de capteurs, actionneurs, et autres ap-
1

10. pareils ´electroniques embarqu´es : ces syst`emes h´et´erog`enes reposent sur l’interop´erabilit´e de
ces diff´erents ´el´ements. La dite interop´erabilit´e n´ecessite de suivre des standards pr´ecis et
adapt´es, mais aussi un certain travail de recherche et des d´eveloppements importants pour
mettre en synergie ces diff´erents standards de fa¸con optimale.
L’un des objectifs du travail pr´esent´e dans ce rapport est de mettre `a disposition sur
Internet, de fa¸con simple, efficace et sˆure, les donn´ees fournies par ces r´eseaux de capteurs
h´et´erog`enes, facilitant ainsi le d´eveloppement des applications tierces pour le maintien `a do-
micile (suivi et analyse des activit´es quotidiennes, de l’´evolution de sant´e, assistance...). Nous
avons ainsi ´et´e amen´es `a faire interop´erer plusieurs standards `a travers une passerelle, grˆace
`a elle, l’acc`es `a des donn´ees h´et´erog`enes est grandement simplifi´e, que ce soit pour des pro-
grammes via des API (Application Programming Interface), ou pour le Web via Internet.
Ce stage, d’une dur´ee de six mois, son but est la mise en place d’une passerelle qui
permet de donner l’acc`es `a Internet aux diff´erents objets connect´es en ayant recours `a l’in-
terop´erabilit´e entre les diff´erents protocoles et nouveaux standards internet qui caract´erise
l’Internet des objets.
Ce rapport pr´esente le travail r´ealis´e au sein du d´epartement RSM (R´eseaux, S´ecurit´e et
Multim´edia) `a l’Institut Mines-T´el´ecom Bretagne-UEB (Universit´e europ´eenne de Bretagne),
il s’articule autour de trois chapitres. Le premier chapitre pr´esente le cadre du projet o`u nous
avons fait une petite ouverture sur le domaine de l’Internet des objets, dans le deuxi`eme
chapitre consiste sur deux parties principales, la premi`ere repose sur la sp´ecifications des
besoins et la conception du projet, la deuxi`eme partie met en relief l’interop´erabilit´e dans le
r´eseau d´evelopp´e par T´el´ecom Bretagne, le troisi`eme chapitre contient la partie r´ealisation
et les diff´erents r´esultats.
2

11. Chapitre I
Cadre du projet
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1 Pr´esentation de la structure d’accueil . . . . . . . . . . . . . . . . . . . . 4
1.1 Axes de recherches . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Collaboration internationale . . . . . . . . . . . . . . . . . . . . . 5
2 Pr´esentation du projet LORA FABIAN . . . . . . . . . . . . . . . . . . . 5
2.1 ´Equipe du projet LORA FABIAN . . . . . . . . . . . . . . . . . . 6
2.2 Partenaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Contraintes et ´etat actuel du projet . . . . . . . . . . . . . . . . . 6
3 Pr´esentation de la mission . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Les tˆaches principales . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 M´ethode de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Diagramme de Gannt . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Internet des objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 D´efinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Approche historique . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Couches protocolaires existantes . . . . . . . . . . . . . . . . . . . 11
4.4 D´eveloppements technologiques dans l’Internet des objets . . . . 12
4.5 Exemples d’applications . . . . . . . . . . . . . . . . . . . . . . . 15
4.6 Impacts de l’Internet des objets . . . . . . . . . . . . . . . . . . . 16
4.7 ´Evaluation de performances dans l’Internet des objets . . . . . . 17
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3

12. CHAPITRE I. CADRE DU PROJET
Introduction
Dans ce chapitre, nous nous int´eressons `a mettre notre projet dans son contexte `a savoir
l’organisme d’accueil T´el´ecom Bretagne et son domaine d’activit´e.
Nous pr´esentons ´egalement les motivations de notre sujet et la d´emarche suivie pour sa
r´ealisation ainsi que les notions de base n´ecessaires pour comprendre notre contribution dans
le projet.
1 Pr´esentation de la structure d’accueil
T´el´ecom Bretagne [1] est une grande ´ecole d’ing´enieur g´en´eraliste et un centre de re-
cherche international en sciences et technologies de l’information.
Cr´e´ee en 1977, T´el´ecom Bretagne offre, sur ses campus de Brest, Rennes et Toulouse, des
formations d’ing´enieur et de 3e cycle (mast`eres, DNM, MSc, doctorat, formation continue).
L’´ecole accueille plus d’un millier d’´el`eves, dont 70% d’´el`eves ing´enieurs et 30% d’´el`eves de
3e cycle (dont environ 200 doctorants).
Les enseignants-chercheurs de T´el´ecom Bretagne sont r´epartis dans 9 d´epartements o`u ils
conduisent une recherche de pointe dans tous les secteurs, des technologies de l’information
et de la communication, et de la conception de nouveaux produits `a l’´etude de nouveaux
usages.
La recherche `a T´el´ecom Bretagne est coordonn´ee par la direction scientifique dans le cadre de
la politique commune d´efinie par l’Institut Mines-T´el´ecom auquel l’´ecole appartient. Elle est
centr´ee sur les STIC (Sciences et Technologies de l’information) dont elle couvre un grand
nombre de champs d’application : Sant´e, Mer, D´efense, Finances, Banque, Transport...
Le d´epartement RSM, o`u j’ai effectu´e mon stage, est situ´e sur le campus de Rennes de
T´el´ecom Bretagne. Son domaine d’activit´e recouvre tous les aspects de l’enseignement, de la
recherche et d´eveloppements en r´eseaux, tout particuli`erement les technologies IP, les r´eseaux
et services de mobiles et la s´ecurit´e des r´eseaux.
1.1 Axes de recherches
Le d´epartement RSM travaille en partenariat tant avec des centres de recherche qu’avec
des industriels et op´erateurs de t´el´ecommunications fran¸cais et europ´eens.
Il poursuit des recherches dans trois axes :
• Gestion de ressources et de mobilit´e pour les r´eseaux radios.
• S´ecurit´e des syst`emes d’information.
• Protocoles et architectures des r´eseaux IP avec un accent particulier sur IPv6.
Le d´epartement RSM est membre du d´epartement D2 de l’IRISA [2] `a travers les ´equipes
de recherches suivantes : REOP (R´eseaux d’op´erateurs) et OCIF (Objets communicants pour
l’Internet du Futur). Cette derni`ere focalise ses travaux de recherche sur l’Internet des objets,
le domaine dans lequel notre projet se focalise.
4

13. CHAPITRE I. CADRE DU PROJET
1.2 Collaboration internationale
T´el´ecom Bretagne a d´evelopp´e, au niveau r´egional, national et international, des partena-
riats avec de nombreux acteurs de l’enseignement sup´erieur, de la recherche et de l’industrie.
Ceci s’est concr´etis´e par plusieurs accords avec diff´erents pays :
• Br´esil : Le d´epartement RSM, en association avec l’IRISA et l’Universit´e de Paris
VI, collabore avec l’universit´e f´ed´erale de Bahia et l’universit´e f´ed´erale de Paraiba. La
th´ematique de la collaboration est celle des grilles de calcul et de l’algorithmique dis-
tribu´ee.
• Cor´ee du Sud : Le projet Easy6 se place dans le cadre du programme d’actions
int´egr´ees franco-cor´een STAR. Il est mis en œuvre en Cor´ee par la KOSEF (Korea
Science and Engineering Foundation) pour le compte du MOST (Minist`ere de la Science
et de la Technologie). Le projet implique l’INRIA, T´el´ecom Bretagne, France Telecom,
6Wind, Korean Telecom et Seoul National University.
• Etats-Unis : Le d´epartement RSM collabore avec l’universit´e de Columbia (New York)
sur des th´ematiques li´ees au routage et `a la th´eorie des jeux dans les r´eseaux. Dans le
cadre de cette collaboration, un s´ejour d’´etudes de six mois est en cours.
• Japon : Le projet Nautilus regroupe des entreprises et universit´es japonaises. Ce consor-
tium vise de d´evelopper et exp´erimenter de nouvelles technologies et protocoles pour
faire ´evoluer Internet, principalement IPv6.
2 Pr´esentation du projet LORA FABIAN
LORA FABIAN (Long Range For A Beautiful Internet Advanced Network) [3] est un
dispositif connect´e sans fil et open source ´elabor´e par les ´equipes RSM de T´el´ecom Bretagne
qui a pour but de d´eployer sur Rennes une couverture radio longue port´ee `a travers la borne
radio LoRa (Long Range) (Technologie radio offrant des communications bidirectionnelles `a
bas d´ebit dans un rayon de 4 km pour des milliers d’objets en simultan´e) et en utilisant des
protocoles standards et ouverts.
Il s’agit de cr´eer un r´eseau d’objets connect´es par le d´eveloppement d’une passerelle s´ecuris´ee
intelligente qui met en communication ces objets du quotidien ´equip´es de capteurs en leur
donnant acc`es `a Internet. En effet, sur le plan domestique, pas de soucis, la box et le wifi
font l’affaire. Sur le plan individuel, le smartphone et son r´eseau (3G, 4G) feront l’affaire,
mais quand nous parlons des multiples de donn´ees, places de parkings disponibles, d´ecibels
´emis, comptages des fluides et autres donn´ees collect´ees par des capteurs, ces technologies
sont limit´ees.
En plus de la connectivit´e offerte, le projet vise `a architecturer les services autour des pro-
tocoles offertes (DNS (Domain Name Service), CoAP (Constrained Application Protocol)
HTTP (Hypertext Transfer Protocol ), ETSI M2M (European Telecommunications Standards
Institute Machine To Machine) pour une meilleure int´egration dans l’Internet. La passerelle
est con¸cue pour supporter des communications de bout en bout entre des applications Web
5

14. CHAPITRE I. CADRE DU PROJET
et des r´eseaux de capteurs sans fils h´et´erog`enes d´eploy´es dans un habitat intelligent.
Deux types de communication peuvent ˆetre trait´es par la passerelle :
• Communication par interrogation : Un client Web interroge directement les res-
sources d’un capteur sans fil 802.15.4.
• Communication spontan´ee : Les capteurs sans fil envoient, soit p´eriodiquement,
soit en cas d’´ev`enement, leurs donn´ees `a la passerelle. Le client web peut alors r´ecup´erer
la derni`ere valeur envoy´ee par le capteur.
2.1 ´Equipe du projet LORA FABIAN
L’´equipe du projet LORA FABIAN appartient au d´epartement RSM et se concentre sur
les aspects de l’enseignement et de la recherche et d´eveloppement en r´eseaux, tout parti-
culi`erement les technologies IP, les r´eseaux et services de mobiles et la s´ecurit´e des r´eseaux.
Lors de mon stage, le travail ´etait en ´equipe :
• Alexander Pelov [4] : Maˆıtre de conf´erence et mon tuteur du stage.
• Laurent Toutain [5] : Maˆıtre de conf´erence, porteur du projet LORA FABIAN.
• Renzo Navas : Ing´enieur de d´eveloppement et de recherche.
• Mathieu Goessens : Ing´enieur de d´eveloppement et de recherche.
2.2 Partenaires
Quatre partenaires contribuent au lancement du projet :
• La soci´et´e Kerlink [6] : Elle met `a disposition du projet des bornes radio LoRa [7]
qui permettent de d´eployer le r´eseau d’acc`es Long Range .
• T´el´ecom Bretagne : Elle apporte sa comp´etence en architecture et protocole r´eseaux,
notamment pour tester des applications pour l’Internet des objets et la standardisation
vers la 5G.
• La startup Wi6Labs [8] : Elle fournit aux makers souhaitant connecter des objets
communicants `a ce r´eseau des shields Arduino d´edi´es [9]. Ils seront distribu´es en open
source avec une interface simple de d´eveloppement.
• L’AFNIC [10] : (Association Fran¸caise pour le nommage de l’Internet en Coop´eration)
´etudie une utilisation innovante du DNS pour g´erer les objets et leur mobilit´e .
2.3 Contraintes et ´etat actuel du projet
Pour atteindre un objectif, il faut que celui-ci soit le plus pr´ecis possible. Il faut donc
d´efinir son projet le mieux possible et d´ecrire avec pr´ecision la situation actuelle par rapport
`a la situation finale que nous souhaitons atteindre.
2.3.1 Contraintes
Chaque nouveau projet passe par un certain nombre de contraintes et surtout, quand il
est con¸cu pour ajouter la valeur et ouvrir les opportunit´es au niveau du march´e. Donc, il est
n´ecessaire d’identifier les contraintes et les clefs de succ`es du march´e :
6

15. CHAPITRE I. CADRE DU PROJET
• Sujet r´ecent : Le projet LORA FABIAN est un sujet r´ecent o`u il n y a pas de docu-
mentation sur Internet concernant l’architecture protocolaire et l’interop´erabilit´e dans
le r´eseau et donc le travail s’inscrit dans un projet d’innovation dans le domaine de
l’Internet des objets, T´el´ecom Bretagne est la premi`ere `a traiter les principes de fonc-
tionnement de LORA FABIAN dans le monde de l’Internet des objets.
• Faible d´ebit : Le projet LORA FABIAN est bas´e sur des transmissions `a bas d´ebit,
donc nous sommes limit´es en terme de bande passante et nous devons pr´evoir des
solutions pour ce probl`eme pour arriver `a faire fonctionner les communications d’une
mani`ere parfaite.
2.3.2 ´Etat actuel du projet
Pour le bon fonctionnement du projet, les intervenants acheminent son avancement comme
suit :
• Cr´eation d’un draft pour le projet LORA FABIAN d´ecrivant le nouveau type de trans-
mission `a longue port´ee, de la technologie radio `a faible d´ebit et le m´ecanisme extensible
pour faire fonctionner ces r´eseaux `a base du protocole CoAP. Les drafts Internet sont
des documents de l’IETF.
• Les nœuds du r´eseau (Node-F, Node-G, Node-R et Node-S) sont fonctionnels et en
phase de test, utilis´es pour des exp´erimentations et pour des cours en attendant la
publication open source du projet.
• D´eploiement `a Rennes en production ´et´e 2015 : Il y a eu le d´eploiement sur le territoire
de la ville du Rennes (France) de l’architecture LORA FABIAN.
• Des ´etudes sur le d´eploiement du r´eseau LORA FABIAN sur d’autres r´egions pour faire
des exp´erimentations sur la mobilit´e.
• Am´elioration des protocoles et de l’impl´ementation.
3 Pr´esentation de la mission
Mon projet de fin d’´etudes s’inscrit dans le projet LORA FABIAN, ma mission est de
cr´eer un outil pour l’analyse de performance du r´eseau LoRa impl´ement´e au niveau de la
passerelle d´evelopp´ee.
7

16. CHAPITRE I. CADRE DU PROJET
3.1 Les tˆaches principales
Pour analyser la performance du r´eseau, il a fallu suivre les ´etapes suivantes :
3.1.1 G´en´eration du trafic vers la passerelle
Lorsque les objets connect´es (les capteurs) envoient leurs donn´ees vers le client, les infor-
mations passent en premier lieu par l’antenne LoRa (le lien radio) qui redirige les donn´ees
vers la passerelle que nous avons d´evelopp´e pour les transmettre au client. Pour faire une
simulation de l’envoi des paquets vers la passerelle par l’antenne, nous avons cr´e´e des paquets
respectant le format LORA MAC (format d´ecrit dans le chapitre suivant) `a partir d’une li-
brairie python et par la suite, nous avons envoy´e ces paquets vers la passerelle pour qu’elle
les traite. La g´en´eration du trafic ´etait au niveau r´eseau plus pr´ecis´ement au niveau radio
(entre les objets connect´es et la passerelle).
3.1.2 D´efinition et enregistrement des KPIs (Key Performance Indicators) :
`A la r´eception des paquets, l’antenne LoRa ajoute certaines informations sur la qualit´e
du r´eseau et qui servent comme indicateurs de performances pour le r´eseau LoRa.
Donc, en ´etudiant le format des paquets au niveau de l’antenne, nous avons choisi ceux qui
servent comme indicateurs de performance dans le r´eseau LORA FABIAN, nous avons fait
des statistique sur le r´eseau et qui vont nous permettre d’analyser la performance du r´eseau
`a titre d’exemple (le nombre des paquets re¸cus, le nombre des paquets envoy´es, la taille...).
Apr`es envoi des paquets par la librairie d´evelopp´ee `a la passerelle, nous avons fait la r´eception
des donn´ees, ainsi l’extraction des informations utiles pour valoriser la performance du r´eseau.
Par la suite, nous avons enregistr´e les indicateurs de performance finaux dans une base de
donn´ees, l’analyse de la performance du r´eseau LORA FABIAN va se faire `a partir de ces
param`etres.
3.1.3 Analyse de la performance du r´eseau LoRa :
La troisi`eme tˆache dans le stage consiste `a pr´eparer `a l’administrateur de la passerelle
d´evelopp´ee un outil qui permettra la collecte des diff´erents indicateurs de performances en-
registr´es en temps r´eel. Donc, apr`es l’envoi des paquets par la librairie d´evelopp´ee et leurs
enregistrement dans la base de donn´ees au niveau de la passerelle, il reste l’analyse de la
performance du r´eseau `a partir des indicateurs ´etudi´es, nous avons eu recours `a trois ou-
tils compl´ementaires et tr`es performants, la pile ELK (Elasticsearch, Logstash et Kibana)
pr´esent´es dans la partie Impl´ementation du rapport et qui permettent la collecte des donn´ees
d’une mani`ere efficace. L’analyse des indicateurs de performance `a partir de ces outils nous
permet de g´en´erer des courbes en temps r´eel sur le trafic au niveau du r´eseau, la charge du
r´eseau et la mani`ere avec laquelle le r´eseau traite les donn´ees qui conduisent finalement `a
l’analyse de la performance du r´eseau LoRa.
3.2 M´ethode de travail
Lors de la r´eunion de pr´esentation du projet, les objectifs en terme de fonctionnalit´es et de
contraintes du logiciel ont ´et´e clairement d´efinis. Toutefois un certain nombre de technologies
li´ees au projet ´etaient nouvelles, notamment le protocole CoAP et la technologie LoRa. Dans
8

17. CHAPITRE I. CADRE DU PROJET
cette situation, nous avons choisi d’appliquer la m´ethode du cycle en V comme cycle de
d´eveloppement logiciel, puisqu’il pr´esente les avantages d’int´egrer et de planifier la validation
au cours du processus de conception, et il permet de pouvoir int´egrer des points de contrˆole
tout au long du cycle.
3.3 Diagramme de Gannt
Nous pr´esentons dans la figure 1.1 la r´epartition des tˆaches du projet par un diagramme
de Gannt :
Figure 1.1 – R´epartition des tˆaches du projet
Au cours du stage, nous avons rencontr´e de nouveaux concepts et protocoles qui sont en
cours d’apparition dans le monde applicatif. Nous avons rencontr´e diff´erents probl`emes, `a
titre d’exemple le fait de ne pas avoir suffisamment de documentations pour nous aider `a
impl´ementer notre architecture r´eseau. L’int´egration dans l’´equipe ´etait tr`es rapide grˆace au
bon encadrement et le travail en ´equipe. Une des difficult´es rencontr´e lors de la phase du
d´eveloppement est la cr´eation des paquets dans la tˆache ”R´ealisation d’une librairie pour la
g´en´eration des paquets LORA”, en effet, il a fallu ´etudier comment les capteurs envoient les
donn´ees `a la passerelle et sous quelle format, d’o`u il a fallu suivre le format et la sp´ecification
LORA et tester l’envoi des paquets `a la passerelle. Pour v´erifier que ces paquets sont dans
le bon format, nous avons impl´ement´e au niveau de la passerelle un outil qui n’accepte que
les paquets LORA et rejette tout les autres donn´ees. Plusieurs conversions sur le format des
donn´ees ´etaient faite pour construire les bons paquets.
4 Internet des objets
Dans cette partie du rapport, nous allons pr´esenter le secteur de l’Internet des objets,
son ´evolution ainsi que son impact dans les diff´erents domaines vu que notre sujet porte sur
les objets connect´es communicants, alors dans le cadre du projet, il est n´ecessaire de d´efinir
l’Internet des objets et fournir quelques exemples. Nous allons faire aussi une partie technique
9

18. CHAPITRE I. CADRE DU PROJET
o`u nous allons d´etailler la communication entre les protocoles et les solutions existantes dans
ce domaine.
4.1 D´efinition
L’Internet des objets (Internet of things) est un des secteurs des t´el´ecommunications qui
devrait voir la plus forte croissance dans les ann´ees `a venir. Certaines pr´evisions ´evoquent
50 milliards [11] d’objets connect´es `a l’horizon des ann´ees 2020. Mais le terme internet des
objets est quelque peu ambigu. Si l’Internet est une technologie qui a fait ses preuves, elle
n’est pas compl`etement adapt´ee `a la capillarit´e des r´eseaux connectant les objets. Un effort
d’adaptation est n´ecessaire pour prendre en compte le nombre tr`es important d’objets `a g´erer,
qui ont souvent des contraintes ´energ´etiques fortes et des capacit´es de traitement limit´ees. Il
faut ´egalement int´egrer le fait que les informations auxquelles donnent acc`es ces objets sont
parfois de nature intrusive ou qu’une action sur ceux-ci peut avoir des cons´equences vitales.
N´eanmoins le terme Internet des objets, refl`ete l’id´ee de faire remonter des informations du
monde r´eel (ou de lui transmettre des instructions) vers des (`a partir de) syst`emes informa-
tiques en utilisant les technologies les plus g´en´eriques possibles et en offrant la plus grande
interop´erabilit´e afin de mettre en œuvre des services innovants. Elle s’oppose `a des approches
propri´etaires et ferm´ees, mˆeme s’il faut, de toute fa¸con, les prendre en consid´eration puisque
la dur´ee de vie d’un objet peut ˆetre sup´erieure `a une dizaine d’ann´ees, alors que les protocoles
utilis´es dans les r´eseaux peuvent suivre un cycle d’´evolution plus court.
L’aspect de l’Internet des objets consiste `a r´ealiser la connectivit´e Internet avec des solutions
techniques tr`es basse ´energie pour fonctionner avec une simple pile, voire uniquement en
r´ecup´erant l’´energie dans l’environnement. Dans beaucoup de cas, cela se traduira par des
syst`emes radio `a courte port´ee (quelques dizaines de m`etres pour les r´eseaux de capteurs),
faible d´ebit et des puissances radio de l’ordre du milliwatt. Une passerelle fait ensuite le lien
avec l’Internet.
4.2 Approche historique
La principale force de l’Internet actuel, que nous pouvons appeler Internet des contenus,
est d’offrir un ´ecosyst`eme coh´erent et ouvert, facilitant l’interconnexion des ´equipements et
favorisant la cr´eation et le d´eploiement de nouveaux services. Un retour sur l’histoire d’Inter-
net permet de mieux comprendre pourquoi les protocoles IP se sont impos´es face `a d’autres
protocoles qui semblaient mieux adapt´es `a leur environnement. Ce ph´enom`ene pourrait se
reproduire pour l’Internet des objets.
Les protocoles de la famille IP n’ont jamais ´et´e les meilleurs, compar´es `a des protocoles
plus sp´ecifiques. Ainsi dans les ann´ees 80, quand IP s’est impos´e face `a d’autres technologies
comme Frame Relay ou ATM (Asynchronous Transfer Mode), nous lui reprochions son prin-
cipe de Best Effort face `a des approches plus sophistiqu´ees permettant d’offrir des classes de
services ou une plus grande fiabilit´e de transmissions.
Nous pourrons multiplier les exemples pour la t´el´ephonie sur IP ou la t´el´evision connect´ee.
Les fonctionnalit´es offertes par IP sont souvent inf´erieures `a celles offertes par des solutions
10

19. CHAPITRE I. CADRE DU PROJET
propri´etaires ou d´eploy´ees pour r´esoudre un probl`eme sp´ecifique. Cependant, IP s’est im-
pos´e, en partie, du fait des progr`es techniques qui ont apport´e une augmentation des vitesses
de transmission et ont contribu´e `a l’am´elioration de la qualit´e de service, mais ´egalement
parce qu’il ´etait pr´ef´erable d’avoir un protocole unique r´eduisant les coˆuts des ´equipements.
Ceci a favoris´e le d´eveloppement de circuits d´edi´es facilitant la maintenance et l’administra-
tion du r´eseau. Enfin, le protocole IP a toujours favoris´e l’interconnexion et permis d’offrir
des services de plus en plus ´evolu´es ex´ecutables sur un grand nombre de types d’´equipements.
Contrairement `a l’Internet des contenus, o`u tous les maillons de la chaˆıne doivent parler IPv6
pour mettre en œuvre ce protocole, l’Internet des objets propose des architectures o`u seule
une partie des ´equipements (les capteurs/actionneurs) sont dot´es des capacit´es d’adressage
et d’auto-configuration de la nouvelle version du protocole IP. Des passerelles permettant
d’interconnecter facilement avec l’Internet actuel. Nous pr´esenterons dans la suite ces archi-
tectures bas´ees sur le concept REST (Representational State Transfer).
4.3 Couches protocolaires existantes
Pour pr´esenter la solution r´ealis´ee dans le projet, il faut d’abord faire une ´etude de
l’existent dans le domaine de l’Internet des objets. Nous pouvons faire une approche pro-
tocolaire avec le mod`ele OSI (Open Systems Interconnection) et le protocole ZigBee.
4.3.1 Mod`ele OSI
Figure 1.2 – Pile protocolaire pour l’Internet des objets
Une des couches protocolaires qui existent pour l’Internet des objets est celle dans la figure
1.2 `a gauche qui correspond au mod`ele de l’Internet (mod`ele en couche) [12], les premiers
`a penser `a l’Internet des objets ont commenc´e par r´eutiliser le mˆeme genre du mod`ele pour
l’Internet des objets, IP ´etait au milieu de l’architecture qui ´etait difficile `a changer `a cause
des probl`emes pour IPv6, au final, nous avons IP, UDP (User Datagram Protocol) et TCP
(Transmission Control Protocol ) tr`es bien install´es o`u c’est difficile de les changer.
Les chercheurs ont pens´e `a construire des nouveaux standards sur ces protocoles et avec
la difficult´e de changer le protocole IP, ils se sont concentr´es `a la couche application et en
particulier le protocole HTTP. Pour l’Internet des objets, au final, l’IETF qui travaille sur
ces protocoles se sont dit que si HTTP avait un rˆole central dans l’Internet d’aujourd’hui,
ce qu’il fallait chercher `a adapter ce n’est pas uniquement IP, c’´etait aussi HTTP et donc
11

20. CHAPITRE I. CADRE DU PROJET
ils ont cr´e´e un nouveau protocole CoAP (une version simplifi´ee de HTTP fonctionnant sur
UDP) ou il y a beaucoup moins d’entˆete avec les mˆemes notions d’URL (Uniform Resource
Locator) et la s´emantique du web donc une version REST `a faible coˆut.
4.3.2 Zigbee
Figure 1.3 – Pile protocolaire pour l’ancienne et la nouvelle de ZigBee
Au d´ebut de l’apparition de ZigBee [13], la technologie est bas´ee sur le principe que tout
doit ˆetre reformul´e et chang´e, c’est pour ¸ca, ZigBee a chang´e l’architecture enti`ere du mod`ele
de l’Internet des objets OSI. Apr`es un certain temps, ils sont rendu compte que cette ver-
sion 1 est compl`etement d´econnect´e d’Internet et pour lesquels il fallait des m´ecanismes de
traduction compliqu´es. De ce fait, ils sont repass´es sur le mod`ele de l’Internet et donc repris
tout les mˆemes protocoles de l’Internet.
Par contre, les couches protocolaires cit´es ont quelques limites, une des limites principales,
c’est que nous somme sur des machines qui ont assez peu de capacit´e et de ressources et la
question qui se pose que nous pouvons avoir des objets connect´es `a Internet sans avoir besoin
de parcourir toute la couche protocolaire, parce qu’une adresse IPv6 sur 128 bits en source
et en destinataire et que nous avons par exemple 10 octets par message pose des probl`emes.
4.4 D´eveloppements technologiques dans l’Internet des objets
Au cœur des ´evolutions technologiques de nombreux secteurs, les technologies de l’Internet
des objets progressent rapidement.
Nous parlerons ici de trois d´eveloppements principaux, depuis la couche physique jusqu’aux
aspects syst`emes.
12

21. CHAPITRE I. CADRE DU PROJET
4.4.1 L’´evolution du M2M vers l’Internet des objets
Figure 1.4 – ´Evolution du M2M vers l’Internet des objets
La notion de M2M est la convergence de trois familles : des objets intelligents, un centre
informatique capable de prendre des d´ecisions, et des r´eseaux de communication.
Une d´efinition g´en´erale a permis d’´etablir la relation entre le concept d’interconnexion d’ob-
jets et celui d’intercommunication de machines. En termes g´en´eraux, le M2M est un ensemble
de technologies d’information et de la communication, destin´ees principalement `a faciliter l’in-
terconnexion et l’intercommunication des objets, sans avoir besoin de l’intervention humaine.
L’interaction entre les machines surpasse la port´ee des communications humaines et permet
`a votre entreprise de r´epondre `a des besoins concrets comme la gestion des ressources, l’au-
tomatisation de proc´ed´e...
Les objets connect´es peuvent communiquer leurs donn´ees par 3 types de solutions pr´esent´ees :
une communication courte-port´ee, un Hub qui est lui-mˆeme connect´e `a internet ou via un
r´eseau avec une longue port´ee. La figure 1.5 pr´esente les technologies de communication
possibles dans l’Internet des objets.
Figure 1.5 – Technologies de communication dans l’Internet des objets
• Communication courte-port´ee : Faible distance entre l’´emetteur et le r´ecepteur, l’´echange
de donn´ees se fait par contact physique entre l’´emetteur et le r´ecepteur (par exemple
grˆace `a un port ethernet ou `a un port USB), par la technologie NFC (Near Field com-
munication) ou par RFID (Radio Frequency Identification).
13

22. CHAPITRE I. CADRE DU PROJET
• Communication via un hub moyenne port´ee connect´e `a Internet : Faible distance entre
´emetteur et r´ecepteur, l’´echange de donn´ees se fait par contact physique entre l’´emetteur
et le r´ecepteur (par exemple grˆace `a un port Ethernet ou `a un port USB), par la tech-
nologie NFC ou par RFID.
• Communication via une solution longue port´ee : Dans le cas d’objets qui ont besoin
de pouvoir communiquer de longue distance, ou de zones difficilement accessibles, la
solution de la communication courte port´ee et la solution de la communication par
Hub sont inefficientes. Il est donc dans ce cas n´ecessaire de s’appuyer sur un r´eseau
qui permet une connexion en tout lieu couvert par les antennes. Les objets connect´es
peuvent s’appuyer sur les r´eseaux cellulaires couverts par les op´erateurs de t´el´ephonie
(2G, 3G, 4G, LTE) pour transmettre leurs donn´ees mais ils sont con¸cus pour de tr`es
haut d´ebit et consomment en contrepartie beaucoup d’´energie. Les objets connect´es
peuvent ´egalement s’appuyer sur des r´eseaux longue port´ee, qui ont la particularit´e de
se baser sur une transmission basse fr´equence, basse consommation d’´energie mais bas
d´ebit. Sigfox, LoRa (par Semtech) et Neul (par Huawei) d´eveloppent ces r´eseaux en
adressant sp´ecifiquement les objets connect´es.
4.4.2 L’am´elioration des technologies radio
Pour de nombreux usagers ´emergents, les technologies radio poss`edent des avantages im-
portants : la r´eduction des coˆuts et des d´elais d’installation. Toutefois, l’industrie restait
tenaill´ee entre la n´ecessit´e de fabriquer des produits utilisables dans le monde entier. La
seule bande libre mondialement ´etant la bande du 2,4 GHz et la faible performance relative
de ces mˆemes bandes de fr´equence dans les bˆatiments europ´eens en b´eton. De plus, le niveau
technologique des normes les plus accept´ees, notamment IEEE 802.15.4-2003, ´etait devenu
significativement inf´erieur `a celui des solutions propri´etaires.
L’impulsion donn´ee par la recherche de meilleures solutions pour le Smart grid aux ´Etats-
Unis a ouvert de nouvelles perspectives. Les normes 802.15.4g et 802.15.4e, repr´esentent des
progr`es tr`es importants. Les deux technologies, `a savoir LORA et SIGFOX, r´epondent `a
l’´evolution de ces normes :
• LORA : La solution permet de cr´eer un v´eritable r´eseau personnel `a faible consomma-
tion, id´eal pour la gestion des communications avec les objets connect´es. La technologie
est donc con¸cue pour r´epondre aux besoins des r´eseaux radio longue port´ee et basse
consommation. LoRa est un protocole de communication qui fonctionne avec les mo-
dules fabriqu´ees par Semtech. Cette technologie a ´et´e mise au point par l’entreprise
grenobloise Cycleo (rachet´e par Semtech en 2012). Son rˆole sera de permettre `a tous les
petits objets connect´es (capteurs de fum´ee, temp´erature, d’humidit´e, de pr´esence, etc...)
de communiquer avec un serveur central, par le biais de relais. Certains op´erateurs l’ont
d´ej`a adopt´e, comme Fastnet en Afrique du Sud (au total 19 op´erateurs testeraient la
technologie).
En 2015, des leaders de l’industrie de l’Internet des objets ont planifi´e la cr´eation de
l’Alliance LoRa afin de standardiser les r´eseaux ´etendus pour l’Internet des Objets,
offrant une connectivit´e bidirectionnelle et longue distance, de faible consommation
´energ´etique. La mission de l’Alliance LoRa est de normaliser les r´eseaux LPWAN (Low
Power Wide Area Networks) d´eploy´es dans le monde entier. La technologie LoRa est
14

23. CHAPITRE I. CADRE DU PROJET
consid´er´ee aujourd’hui comme une alternative cr´edible au r´eseau M2M basse fr´equences.
• Sigfox : Sigfox est une technologie LPWAN qui utilise la bande 868 MHz en Europe
et 902 MHz aux ´Etats Unis mais aussi un op´erateur qui utilise sa propre technologie.
Avec Sigfox, l’objet peut envoyer entre 0 et 140 messages par jour et le payload de
chaque message ne peut pas d´epasser 12 octets, ce qui est amplement suffisant pour
les objets qui transmettent une alarme, une localisation, un ´etat d’environnement
(temp´erature), une mesure de consommation d’´energie... Des objets comme des cam´eras
sont des types d’objets qui restent destin´es aux r´eseaux larges bandes.
Il est aussi possible avec Sigfox de transmettre 4 messages de 8 octets de payload `a
chaque objet par jour. Mais, pour que l’objet re¸coit le message, il doit demander les
donn´ees au serveur, il doit donc ˆetre programm´e pour recevoir des donn´ees `a des ins-
tants d´efinis dans sa logique. Cette demande de communication bidirectionnelle cible
les clients qui souhaitent de temps en temps pousser un param`etre de configuration vers
leurs objets. Cette fonctionnalit´e est impl´ement´ee comme un ”polling”, o`u l’objet reste
maitre et peut demander au syst`eme d’information s’il y a des donn´ees `a t´el´echarger.
Exemple : Un thermostat envoie la temp´erature toutes les 30 minutes. Suite `a l’envoi,
il reste `a l’´ecoute pendant quelques secondes, afin d’ˆetre capable de recevoir une ins-
truction pour augmenter ou baisser la temp´erature. Ce fonctionnement permet d’´eviter
de rester connect´e en permanence et permet donc une communication bidirectionnelle
en restant basse consommation.
4.4.3 Vers une standardisation 5G
Les technologies et processus de communication de l’Internet des objets utilisent des stan-
dards diff´erents et adressent des usages diff´erents. A l’heure de la multiplication des objets
connect´es, de nouveaux usages et besoins ´emergent (besoin de transmettre de courts mes-
sages, sans consommer beaucoup d’´energie...).
La 5G, annonc´ee pour les ann´ees 2020, entend regrouper et int´egrer toutes les technologies
´evoqu´ees pour une utilisation plus efficiente des bandes de fr´equences disponibles. Chacun
place ses pions, avec Sigfox qui l`eve 100 millions d’euros pour installer son r´eseau `a l’inter-
national, avec Semtech qui annonce son partenariat avec Bouygues pour l’acc´el´eration de la
mise en place du r´eseau LoRa, ou avec Neul (rachet´e par Huawei) qui a fait en f´evrier dernier
un partenariat avec Vodafone pour int´egrer sa technologie dans le r´eseau de l’op´erateur afin
qu’il adresse les besoins des objets connect´es.
4.5 Exemples d’applications
Le domaine de l’Internet des objets est tr`es vaste et diff´erents types d’objets pourront
devenir connect´es, nous citons quelques exemples d’application ci-dessous :
4.5.1 Ville du futur
L’interconnexion et la communication de tous les v´ehicules routiers (voitures, bus, camion,
bicyclettes...) pr´esents dans un p´erim`etre d´efini, entre eux et avec une infrastructure permet-
tra par exemple d’ajuster dynamiquement le fonctionnement des feux aux carrefours pour
fluidifier la circulation, d’afficher des informations en temps r´eel sur l’´etat de la circulation
et de renvoyer ces donn´ees sur les v´ehicules dans la zone.
15

24. CHAPITRE I. CADRE DU PROJET
4.5.2 Domotique
Les applications domotiques existent d´ej`a depuis relativement une longue date. Il est pos-
sible de programmer le chauffage ou la fermeture/ouverture de volets roulants, y compris `a
distance via des applications sur smartphone ou tablettes.
Avec Internet des objets et une application coordinatrice, ces ´el´ements du confort thermique
domestique pourront ”discuter” entre eux et se coordonner pour trouver la meilleure confi-
guration pour un confort thermique optimal et une consommation d’´energie minimale. De
plus, cet ajustement est dynamique, ce qui autorise une reconfiguration adapt´ee durant les
journ´ees d’hiver durant lesquelles le soleil se montre par intermittence, par exemple.
4.5.3 Usine du futur
En industrie, dans les usines du futur les machines communicantes, interconnect´ees entre
elles, avec leur extensions (moules, outils...) et avec les pi`eces ou mati`eres qu’elles traitent
permettra d’auto-optimiser les op´erations :
• Auto-configuration des machines en fonction des caract´eristiques des pi`eces et/ou des
outils et mati`eres.
• Ajustement de l’usinage en fonction des caract´eristiques des mati`eres, de l’usure de
l’outil.
• Demande automatique de maintenance, ´emises par les machines, les outils ou les moules
eux-mˆemes, en fonction de param`etres pr´ed´efinis.
4.6 Impacts de l’Internet des objets
Comme tout ´el´ement de transformation num´erique de l’entreprise, l’Internet des Objets
am`ene un certain nombre d’impacts qui sont `a la fois techniques, financiers, RH et juridiques,
ainsi que de nouveaux risques associ´es.
4.6.1 Impacts techniques et alignement du syst`eme d’information
Afin d’int´egrer les objets connect´es dans la gestion du syst`eme d’information de l’en-
treprise, plusieurs probl´ematiques doivent ˆetre correctement appr´eci´ees. D’un point de vue
technique, l’Internet des Objets est par nature h´et´erog`ene. Par ailleurs, tous les objets ne
n´ecessitent pas d’ˆetre connect´es en continu sur le r´eseau.
Pour impl´ementer l’Internet des Objets, il ne suffit donc pas d’avoir les objets, mais encore
il faut pouvoir les connecter, les capteurs les plus petits ne peuvent pas communiquer di-
rectement en 3G ou 4G, et n´ecessiteront donc des passerelles, smartphones ou routeurs. Ces
´equipements devront alors avoir d’une part les interfaces pour discuter avec les objets (dont
les protocoles de communication sont tr`es h´et´erog`enes), et d’autre part une interface r´eseau
pour communiquer avec une plateforme de service qui elle-mˆeme s’interf`erera avec des SI
multiples.
Enfin, il est `a noter qu’avec l’augmentation exponentielle du nombre d’objets connect´es, il
faudra ˆetre capable de g´erer l’acquisition, le stockage et l’analyse de quantit´es gigantesques
de donn´ees. Nous nous rapprochons alors des probl´ematiques de Big Data, qui donneront `a
ses donn´ees issues de l’Internet des Objets toute leur valeur.
16

25. CHAPITRE I. CADRE DU PROJET
4.6.2 Impact financier
Sur le plan financier, l’impact est loin d’ˆetre n´egligeable. Les opportunit´es en termes de
nouveaux mod`eles d’affaires et d’optimisation des coˆuts sont telles que le retour sur inves-
tissement de la mise en place d’objets connect´es dans l’entreprise est facilement perceptible.
Mais un investissement initial important est `a pr´evoir pour s’´equiper non seulement en objets
mais aussi dans les syst`emes et r´eseaux qui vont les g´erer. Le d´eveloppement des mod`eles
´economiques et l’analyse du retour sur investissement seront alors des ´etudes `a r´ealiser en
amont des projets li´es `a l’Internet des Objets.
4.6.3 Impact RH
L’utilisation des objets connect´es va n´ecessairement ˆetre tr`es impactant sur les ressources
humaines de l’entreprise, sur plusieurs aspects :
• Am´elioration de la s´ecurit´e des utilisateurs.
• Optimisation du geste m´etier.
• Cr´eation de nouveaux m´etiers et comp´etences.
Au niveau des conditions de travail, les objets connect´es s’attachent aux employ´es. Ils peuvent
ainsi permettre de localiser la personne, et de suivre un certain nombre de capteur.
Par ailleurs, la pr´ecision de certains capteurs peut ˆetre mise au service de la formation du
personnel. Ainsi, par la captation et l’analyse des donn´ees remont´ees par des capteurs port´es
par l’employ´e, il est possible de travailler sur l’optimisation du geste m´etier.
Enfin, l’arriv´ee de nouvelles technologies internalis´ees entraˆıne n´ecessairement la cr´eation de
nouveaux m´etiers et l’int´egration de nouvelles comp´etences qui permettront de les g´erer. Ces
nouveaux m´etiers concernent notamment la cr´eation et l’impl´ementation des objets et des
interfaces, ainsi que la gestion des donn´ees. Cela concerne aussi les m´etiers d’ergonomes qui
vont pouvoir assister `a la cr´eation des objets connect´es adapt´es aux conditions de travail.
4.7 ´Evaluation de performances dans l’Internet des objets
Mesurer les performances d’un syst`eme dans l’Internet des objets pose beaucoup de
probl`emes, du fait que les objets doivent ˆetre test´es dans des conditions r´eelles d’utilisa-
tion. Une autre difficult´e est due au fait que les syst`emes dans l’Internet des objets sont la
plupart du temps bas´es sur des capteurs/actionneurs et requi`erent une interaction plus ou
moins forte avec les op´erateurs humains. Ils peuvent int´egrer plusieurs technologies et plu-
sieurs disciplines, ce qui complexifie consid´erablement les processus de tests et d’´evaluation
des performances de tests `a diff´erents degr´es de r´ealisme, class´ees selon leur architecture (2-
Tiers ou 3-tiers).
En fonction de leurs architectures, les environnements d’´evaluation peuvent ˆetre class´es en
deux cat´egories. Pour les architectures 2-tiers, la limite est leur incapacit´e `a prendre en charge
la couche r´eseau. Les architectures 3-tiers prennent en compte la couche r´eseau pour facili-
ter la communication entre les objets et les serveurs de test, en offrant plus de flexibilit´e et
des gains en performance. Ces solutions de test peuvent int´egrer un ou plusieurs syst`emes
d’exploitation utilis´e g´en´eralement dans le domaine de l’embarqu´e.
17

26. CHAPITRE I. CADRE DU PROJET
Conclusion
Au cours de ce chapitre, nous avons pr´esent´e le cadre de notre projet, la structure d’accueil
T´el´ecom Bretagne o`u j’ai effectu´e mon stage. Par la suite nous avons pr´esent´e les principales
tˆaches, nous avons introduit la notion de l’Internet des objets, le domaine en pleine explosion
o`u nous avons parl´e sur l’histoire, les technologies existantes, les d´eveloppements et l’impact
de l’Internet des objets sur la vie dans le futur. La partie suivante sera consacr´e pour l’analyse
et la sp´ecification des besoins o`u nous d´etaillerons aussi la communication et l’interop´erabilit´e
dans notre projet LORA FABIAN.
18

27. Chapitre II
Sp´ecification des besoins et conception
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1 Sp´ecification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 20
1.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . 21
2 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . 22
2.1 Pr´esentation des acteurs . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Description des cas d’utilisation . . . . . . . . . . . . . . . . . . . 22
3 Diagramme de s´equence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Diagramme de s´equence fonctionnel . . . . . . . . . . . . . . . . . 25
3.2 Diagramme de s´equence applicatif . . . . . . . . . . . . . . . . . . 26
4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Description des classes . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Interop´erabilit´e dans le r´eseau LORA FABIAN . . . . . . . . . . . . . . . 31
5.1 Architecture du r´eseau LORA FABIAN . . . . . . . . . . . . . . . 31
5.2 ´El´ements du r´eseau . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Standards utilis´es . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Prolongement des web objets vers les capteurs . . . . . . . . . . . 38
5.5 Format des paquets dans le r´eseau LORA FABIAN . . . . . . . . 42
5.6 Types de trames circulant dans le r´eseau . . . . . . . . . . . . . . 46
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
19

28. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
Introduction
Dans ce chapitre, nous pr´esentons l’ensemble des fonctionnalit´es que doit satisfaire le mo-
dule `a d´evelopper, ainsi que les diff´erentes contraintes auxquelles il doit se soumettre. Nous
rappelons qu’il s’agit pour notre projet d’aboutir `a un module qui permet `a l’administrateur
de la passerelle d’analyser la performance de son r´eseau `a travers des indicateurs de perfor-
mance d´efinis.
Ce chapitre repr´esente une vision approximative de la finalit´e du projet qui consiste `a com-
prendre le contexte du syst`eme `a r´ealiser en recensant `a la fois les besoins fonctionnels et
les besoins non fonctionnels, par la suite, nous pr´esentons la conception de notre projet avec
les diff´erents diagrammes. Dans la deuxi`eme partie du chapitre, nous allons d´etailler l’archi-
tecture du r´eseau LORA FABIAN en mettant l’accent sur les diff´erents standards utilis´es et
l’interop´erabilit´e dans le r´eseau.
1 Sp´ecification des besoins
Dans cette section du chapitre, nous nous int´eressons aux besoins des utilisateurs trait´es
dans notre projet.
1.1 Les besoins fonctionnels
Les besoins fonctionnels du projet LORA FABIAN sont divers, le projet vise `a permettre
aux capteurs de se connecter `a Internet `a travers la passerelle et la technologie radio longue
port´ee LoRa, les besoins fonctionnels du projet en g´en´eral sont relatifs aux besoins des clients
ou l’op´erateur qui va d´eployer l’architecture LORA FABIAN.
En outre, nous avons choisi pour le moment d’´etudier les besoins fonctionnels de la partie
qui va nous permettre de d´efinir les indicateurs de performance du r´eseau.
Les besoins fonctionnels du projet sont :
1.1.1 La collecte des indicateurs de performance du r´eseau :
Il faut collecter tout les indicateurs de performances possibles qui pourront aider `a in-
terpr´eter la performance du r´eseau LORA FABIAN.
1.1.2 La cr´eation d’une librairie pour la g´en´eration du trafic vers la passerelle :
Nous devons g´en´erer du trafic vers la passerelle `a travers une librairie Python, la librairie
va cr´eer des paquets et les envoyer vers la passerelle. Dans ce contexte, il faut g´en´erer tous
les types des paquets qui pourront circuler dans la r´ealit´e.
1.1.3 Fournir un moyen pour l’analyse de la performance du r´eseau `a l’admi-
nistrateur de la passerelle :
Il s’agit de cr´eer un serveur web sur la passerelle qui va servir comme outil d’analyse de
la performance du r´eseau LoRa.
20

29. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
Pour arriver `a l’objectif, plusieurs sous-besoins ´etaient n´ecessaires :
• L’enregistrement des indicateurs dans une base de donn´ees.
• Les tables de la base de donn´ees doivent se g´en´erer automatiquement.
• L’application doit permettre `a l’administrateur de la passerelle de diagnostiquer les
probl`emes dans le r´eseau en temps r´eel : L’outil de l’analyse de performance doit per-
mettre `a l’administrateur de superviser la qualit´e de son r´eseau `a partir des indicateurs
ainsi que les statistiques affich´ees dans l’outil (des courbes, histogrammes...).
• L’application doit afficher les informations relatifs pour chaque capteur dans le r´eseau.
• L’application doit permettre de faire des regroupements de chaque capteur dans le
r´eseau par son adresses MAC et le nombre de paquets envoy´es dans des tableaux.
• L’application doit permettre de faire des courbes sur le d´ebit de transmission de l’an-
tenne LoRa.
• L’application doit permettre de faire des histogrammes sur les tailles des paquets en-
voy´es pour chaque nœud dans le r´eseau.
• L’application doit permettre `a l’administrateur de faire son choix du tableau de bord
personnel pour l’analyse du r´eseau.
• L’application doit permettre de faire des statistiques sur le r´eseau.
1.2 Les besoins non fonctionnels
Il s’agit des besoins qui caract´erisent le syst`eme. Ces besoins peuvent concerner les
contraintes li´ees `a l’impl´ementation (langage de programmation, de syst`eme d’exploitation...)
ou `a l’interop´erabilit´e g´en´erale. En effet, ces besoins peuvent ˆetre fixer par le client (fonctions
optionnelles), ou par le d´eveloppeur (contraintes d’impl´ementation).
Parmi les besoins non fonctionnels de notre application, nous citons :
1.2.1 La performance :
Le syst`eme doit ˆetre performant en temps de r´eponse et en terme de consommation de
ressources.
1.2.2 Interface de l’affichage des analyses :
L’interface du serveur web qui va permettre l’analyse de la performance du r´eseau doit
ˆetre coh´erente au point de vue l’ergonomie. La qualit´e de l’ergonomie sera un facteur essentiel,
´etant donn´ee l’utilisation intensive qui sera faite de l’application.
21

30. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
1.2.3 Interop´erabilit´e dans le r´eseau :
Il faut garantir l’interop´erabilit´e entre les r´eseaux intelligents, la n´ecessit´e d’assurer un
niveau ´elev´e de coh´erence et de sˆuret´e. Il faut que la diff´erence de normes n’affectent pas
l’architecture g´en´erale des r´eseaux intelligents.
1.2.4 S´ecurit´e des donn´ees :
Assurer un niveau ´elev´e de protection des donn´ees et de la vie priv´ee et d’un bon rapport
coˆut/efficacit´e.
2 Diagrammes de cas d’utilisation
Un cas d’utilisation repr´esente une exigence fonctionnelle du syst`eme. Dans notre projet,
puisque nous avons deux syst`emes ind´ependants, nous allons pr´esenter le diagramme de cas
d’utilisation pour chaque syst`eme.
2.1 Pr´esentation des acteurs
Le syst`eme est bas´e sur deux acteurs principaux :
2.1.1 L’utilisateur de la librairie
Il s’agit de l’utilisateur de la biblioth`eque python qui va lui permettre de g´en´erer des
paquets selon la technologie radio LORA et les envoyer vers la passerelle.
2.1.2 L’administrateur de la passerelle
Il s’agit de l’administrateur qui va superviser son r´eseau personnel que ce soit un utilisa-
teur normal ou un op´erateur `a partir d’un ensemble de serveurs qui tourne sur une machine
(la passerelle) en ´ecoute des paquets de la station LORA, la passerelle va permettre `a l’ad-
ministrateur d’extraire les indicateurs de performance des donn´ees re¸cues, elle va fournir un
outil pour l’analyse de performance du r´eseau.
2.2 Description des cas d’utilisation
2.2.1 Objectif
L’objectif de la r´ealisation de la librairie est de g´en´erer diff´erents types de trafic et les
envoyer vers la passerelle qui va faire du traitement pour d´efinir les indicateurs de performance
du r´eseau et cr´eer un outil d’analyse pour l’administrateur de la passerelle.
2.2.2 Pr´e-conditions :
• Les paquets g´en´er´es dans la librairie doivent respecter la sp´ecification LORA MAC.
• La passerelle doit rejeter les paquets qui n’appartiennent pas au r´eseau LORA.
22

31. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
2.2.3 Diagramme de cas d’utilisation pour l’administrateur
Le diagramme pr´esent´e dans la figure 2.1 contient les diff´erents cas d’utilisations que
l’administrateur peut effectuer lors de sa connexion sur son tableau de bord :
Figure 2.1 – Diagramme de cas d’utilisation pour l’administrateur
23

32. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
• Le cas d’utilisation : Configurer le syst`eme Pour fournir un outil efficace et performant
d’analyse de performance du r´eseau, nous devons prendre en compte la configuration
du syst`eme, en effet, chaque administrateur a un choix diff´erent d’un autre administra-
teur en terme d’interface d’accueil, ainsi, nous donnons le choix `a l’administrateur de
choisir son tableau de bord personnel, les graphes qu’il pr´ef`ere trouver dans l’interface
d’accueil `a chaque connexion. ´Egalement, le syst`eme doit offrir la possibilit´e d’importer
son fichier de log qui contient les indicateurs de performance export´es avant la derni`ere
utilisation. Le syst`eme offre aussi la possibilit´e de configurer la p´eriode de mise `a jour de
l’affichage des logs, par exemple afficher les logs des derni`eres 5 minutes ou du dernier
jour etc. . .
• Le cas d’utilisation : Consulter les indicateurs de performance du r´eseau L’administrateur
peut consulter les donn´ees enregistr´es dans la base de donn´ees, les indicateurs de perfor-
mance du r´eseau de la p´eriode choisie, pour faire ¸ca, il doit saisir le crit`ere de recherche
par exemple, le nom de l’indicateur ou il envoie une requˆete d’affichage de tous les
indicateurs qui d´epassent une certaine valeur, il peut aussi s´electionner un crit`ere de
recherche parmi plusieurs sugg´er´es dans le serveur.
• Le cas d’utilisation : G´en´erer des graphes L’administrateur a la possibilit´e de g´en´erer
des graphes (des courbes, des histogrammes, des tableaux) par exemple des courbes
de d´ebit en fonction du temps, la puissance de r´eception de l’antenne en fonction du
temps ou des tableaux qui contiennent la liste des capteurs avec le nombre des paquets
envoy´es. Nous laisse le choix `a l’administrateur de choisir la forme du graphe ainsi que
les crit`eres qu’il veut ´evaluer.
• Le cas d’utilisation : consulter la liste des capteurs dans le r´eseau La passerelle d´evelopp´ee
donne acc`es internet aux diff´erents capteurs dans le mˆeme r´eseau, l’administrateur de
la passerelle doit avoir la possibilit´e de consulter l’ensemble des capteurs connect´es `a la
passerelle et afficher les informations relatives `a chaque nœud dans le r´eseau. Ainsi, il
peut afficher la taille des paquets envoy´es, le nombre des paquets envoy´es pour chaque
capteur, la modulation, la fr´equence...
• Le cas d’utilisation : Consulter les informations relatives `a la station LoRa L’administrateur
peut avoir des informations sur les diff´erents nœuds du r´eseau en particulier l’antenne
LoRa connect´ee directement `a la passerelle, il peut afficher le d´ebit au niveau de la
passerelle dans un temps donn´e, le facteur signal sur bruit, la puissance de r´eception,
le facteur d’´etalement...
24

33. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
2.2.4 Diagramme de cas d’utilisation de l’utilisateur de la librairie :
Figure 2.2 – Diagramme de cas d’utilisation pour l’utilisateur de la librairie
• Le cas d’utilisation : G´en´erer du trafic selon le protocole LORA Le premier cas d’uti-
lisation de la librairie est de g´en´erer des paquets selon le protocole LORA en utilisant
le protocole REST CoAP, o`u nous fournissons aux utilisateurs de la technologie LORA
un moyen pour cr´eer des paquets sans utiliser l’antenne LoRa.
• Le cas d’utilisation : Envoyer les trames vers la passerelle Pour compl´eter le premier cas
d’utilisation et selon le besoin de notre projet, notre librairie fournit ´egalement la pos-
sibilit´e d’envoyer les paquets g´en´er´es vers notre passerelle en sp´ecifiant l’adresse MAC
de la Gateway.
3 Diagramme de s´equence
Les diagrammes de s´equences suivants montreront une vue dynamique sur l’interaction
de l’utilisateur avec le syst`eme. Nous avons choisi de pr´esenter au d´ebut le diagramme de
s´equence fonctionnel du projet, et par la suite d´etailler ce diagramme `a partir d’un diagramme
de s´equence applicatif.
3.1 Diagramme de s´equence fonctionnel
Dans notre syst`eme, nous avons deux acteurs principaux, la librairie qui g´en`ere du trafic
vers le deuxi`eme acteur la passerelle. La figure 2.3 montre l’enchainement de principales
actions entre les deux acteurs.
La librairie commence par la g´en´eration des paquets selon le protocole LORA en suivant la
sp´ecification LORA MAC, apr`es, elle envoie les trames vers la passerelle qui est en ´ecoute,
elle extrait les indicateurs de performances du r´eseau et elle les envoie vers l’outil d’analyse
de performance sur la passerelle.
25

34. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
Figure 2.3 – Diagramme de s´equence fonctionnel
3.2 Diagramme de s´equence applicatif
Pour mieux expliquer la s´equence d’´ev`enements du syst`eme, nous allons d´etailler le dia-
gramme de s´equence en prenant en consid´eration tous les interactions entre les intervenants.
La figure 2.4 pr´esente le diagramme de s´equence applicatif du syst`eme.
Au d´ebut, la librairie commence par g´en´erer des paquets selon la technologie radio longue
port´ee LORA, elle envoie par la suite les paquets vers la passerelle qui est en ´etat d’´ecoute.
A la r´eception des paquets, un serveur int´egr´e dans la passerelle v´erifie si les paquets appar-
tiennent au r´eseau LORA ou non, si ce n’est pas le cas, elle rejette les donn´ees, sinon, elle
r´epond par un ACK vers la librairie et par la suite elle fait une s´erie d’actions : Premi`erement,
elle commence par l’extraction des indicateurs de performance depuis les donn´ees re¸cues, l’en-
registrement des KPIs (Key Performance Indicators) dans la base de donn´ees et apr`es elle
envoie les donn´ees enregistr´ees vers la pile ELK, plus particuli`erement, le serveur Logstash,
il collecte, filtre et envoie les donn´ees vers le serveur Elasticsearch qui indexe les donn´ees
sous format JSON dans une base de donn´ees NoSQL, pour que l’administrateur puisse faire
des requˆetes `a partir du serveur web Kibana qui acc`ede aux donn´ees enregistr´ees dans Elas-
ticsearch, il permet de faire des graphes et des statistiques sur les donn´ees dans la base de
donn´ees NoSQL.
26

35. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
Figure 2.4 – Diagramme de s´equence applicatif
27

36. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
4 Diagramme de classe
Le diagramme de classes de la figure 2.5 fournit une description bien d´etaill´ee des diff´erentes
classes de l’application ainsi que les diff´erentes associations qui les relient.
Figure 2.5 – Diagramme de classe
Le diagramme de classe pr´ec´edant repr´esente les diff´erents classes et interfaces impl´ement´ees
au niveau de la passerelle lors du stage. Nous commen¸cons par la r´eception des paquets du
lien radio, l’extraction des indicateurs de performance, leur enregistrement, pour enfin faire
la pr´eparation `a l’analyse de la performance du r´eseau `a partir des informations enregistr´ees
dans la base de donn´ees.
28

37. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
4.1 Description des classes
Le diagramme de classe repr´esent´e dans la figure 234 correspond au travail au niveau de
la passerelle, l’ensemble des classes impl´ement´ees au niveau de la passerelle.
4.1.1 Un tunnel :
Sur lequel il y a la r´eception des donn´ees envoy´ees par l’antenne LORA sur le lien radio.
Les donn´ees sont re¸cues sous format ”NodeRpipePacket” et puis ils seront transform´es en
”RawData” pour des traitements dans les couches applicatifs.
• Au niveau du tunnel, nous avons impl´ement´e les classes ”UpstreamTunnel” et ”Downs-
treamTunnel” qui h´eritent de la classe ”AbstractTunnel” et qui assurent successivement
l’envoi des r´eponses ou des requˆetes vers la station LORA et la r´eception des paquets
sur le lien radio. Il s’agit d’un ensemble de threads qui effectuent la v´erifications de
l’appartenance des paquets re¸cus selon la version du protocole utilis´e, la construction
de l’objet ”NodeRpipePacket” qui sera par la suite utile pour extraire les param`etres
du r´eseau et les caract´eristiques des capteurs et de l’antenne LORA.
• Sur le lien Uplink, la classe ”UpstreamTunnel” se charge de recevoir les ”PullAckPa-
ckets” envoy´es par l’antenne, il s’agit des messages de signalisation.
Sur le lien Downlink, la classe ”DownstreamTunnel” se charge d’envoyer les ”PullResp-
Packets” et ”PushAckPackets”, il s’agit des messages de signalisation et de donn´ees.
4.1.2 La couche MAC 802.15.4 :
Dans cette partie de code, nous extrayons les informations relatives `a la couche 802.15.4
comme l’adresse MAC et les informations relatives `a l’antenne LORA comme le Pan ID,
l’adresse de la station...
• Le package MAC 802.15.4 permet d’extraire les donn´ees `a partir de l’objet ”NodeRpi-
pePacket” et affecter ces donn´ees aux objets capteurs et stations LORA pour s´eparer
le traitement dans les couches sup´erieures. Ainsi, nous trouvons le pr´el`evement du pay-
load du paquet, la s´eparation de chaque champ `a partir de son nombre de bytes d´etaill´e
dans la sp´ecification LORA MAC.
• Un paquet au niveau de la passerelle peut ˆetre soit de type ”PushAckPacket”, ”Pull-
RespPacket”, ”PullAckPacket”.
• La classe ”PacketFormatConverter” utilise ”NodeRpipePacket” pour faire d’une part
la g´en´eration des statistiques sur le trafic `a chaque r´eception des donn´ees ainsi que les
indicateurs de performance du r´eseau, d’une autre part, elle fait la conversion entre les
deux types de paquets (”NodeRpipePacket” et ”RawData”), RawData pour les couches
sup´erieures et ”NodeRpipePacket” pour les couches basses, la classe ”PacketFormat-
Converter instance par la suite les classes ”GeneralStats” et ”KPI”.
29

38. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
4.1.3 Une couche applicative :
Dans laquelle il y a la d´efinition des indicateurs de performance `a partir des attributs de
l’objet ”NodeRpipePacket” et les statistiques sur les donn´ees re¸cues, par la suite nous en-
voyons par UDP les donn´ees vers les serveurs qui se chargent de fournir les outils n´ecessaires
pour l’analyse de performance.
• La classe ”NodeRpipePacket” d´efinit les champs des paquets en provenance du lien ra-
dio (bytes, adresse, port, informations sur le capteur, nature du message (signalisation
ou donn´ee)...).
• Les paquets PushAck sont les acquittements envoy´es par la passerelle, donc ils sont
cr´ees au niveau de la passerelle.
• Les paquets PullAck sont les acquittements re¸cus par la passerelle, donc il s’agit des
acquittement envoy´es par la station LORA.
• Les paquets PullResp sont les trames de donn´ees envoy´ees par l’antenne LORA.
• La classe ”KPI” contient les indicateurs de performance sp´ecifique au r´eseau LORA.
• La classe ”GeneralStats” contient des statistiques sur le r´eseau en fonction des capteurs
dans le r´eseau.
30

39. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
5 Interop´erabilit´e dans le r´eseau LORA FABIAN
Le domaine de l’Internet des objets est tr`es vaste par les fonctionnalit´es fournies et la
valeur ajout´ee dans les diff´erentes pistes. Th´eoriquement, l’id´ee est claire et les besoins sont
dynamiques, mais en pratique, il faut utiliser des nouveaux standards et protocoles. Dans
cette partie, nous allons ´evoquer de l’interop´erabilit´e dans le r´eseau LORA FABIAN `a travers
la communication des diff´erents couches protocolaires.
5.1 Architecture du r´eseau LORA FABIAN
L’architecture du r´eseau LORA FABIAN [14] est bas´ee sur quatre nœuds (Node-F, Node-
R, Node-G, Node-S) et diff´erentes interfaces. Les nœuds sont les ´el´ements de base du r´eseau,
ils interagissent ensemble pour r´epondre aux besoins des clients et assurer l’interconnexion
des objets connect´es entre eux `a travers une communication bidirectionnelle garantie par la
station LoRa (Long Range) qui repr´esente la Node-R dans le sch´ema.
Figure 2.6 – Architecture g´en´erale du r´eseau LORA FABIAN
Les objets connect´es (Nodes-F) sont identifi´es par leur adresse MAC au niveau de la passe-
relle (Node-G), celle-ci, va garantir aux objets connect´es la communication entre les objets
connect´es et l’acc`es `a Internet.
Pour r´epondre ou envoyer une requˆete les Nodes-F envoient leurs r´eponses vers les Nodes-G,
la requˆete passe par le lien radio (la station LoRa) qui redirige tout simplement les paquets
vers la passerelle la plus proche qui, apr`es r´eception, traite la requˆete soit par la rediriger
vers un autre objet connect´e, soit vers une autre passerelle, soit vers un serveur web par un
tunnel s´ecuris´e. La communication est bas´ee sur deux plans, le plan de signalisation et le
plan de donn´ees.
age
31

40. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
5.2 ´El´ements du r´eseau
La figure 2.7 montre les diff´erents participants dans le projet LORA FABIAN, Wi6Labs
avec ses capteurs arduino qui sont ´equip´es par des modules LoRa, Kerlink qui fournit les
antennes LoRa (les Nodes-R), il y a l’Afnic qui participe par le d´eveloppement des services
DNS et enfin T´el´ecom Bretagne qui fait le d´eveloppement du logiciel qui fait la gestion du
r´eseau et met en place l’architecture LORA FABIAN sur la Node-G.
Figure 2.7 – Diff´erents participants dans le projet
5.2.1 Node-F
Il s’agit des objets connect´es qui sont g´en´eralement des capteurs int´egr´es dans des objets
et distribu´es sur l’ensemble de couverture du r´eseau LoRa. Leur rˆole est principalement cap-
ter des informations `a partir des objets et les transmettre `a d’autres objets ou vers Internet.
G´en´eralement, le capteur est en limitation d’´energie et en puissance de traitement.
Ces objets peuvent se comporter comme des passerelles pour donner l’acc`es `a d’autres objets
via diff´erentes technologies d’acc`es comme par Bluetooth/IEEE 802.15.4, ZigBee/802.15.4...
Un module LoRa est ajout´e aux microcontrolleurs concern´es pour acc´eder `a la technologie
LoRa et une biblioth`eque open source fournie pour le d´eveloppement des programmes selon
le besoin de l’utilisateur.
32

41. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
Figure 2.8 – Capteur Node-F
Mise au point par la soci´et´e Semtech, la technologie LoRa est caract´eris´ee par une excellente
sensibilit´e en r´eception. Cette technologie permet d’envisager des transmissions radio d’une
port´ee d’une quinzaine de kilom`etres et une autonomie de plus de dix ans pour certains types
d’objets connect´es. Le premier module LoRa de Microchip, qui est aussi membre fondateur
de ”LoRa Alliance” tout r´ecemment cr´e´ee, exploite les bandes de fr´equence europ´eennes 433
MHz et 868 MHz. Il combine `a la fois des dimensions compactes (17,8 x 26,3 x 3 mm) et 14
interfaces d’entr´ees/sorties GPIO, caract´eristiques qui offrent la flexibilit´e de connecter et de
commander un grand nombre de capteurs et d’actuateurs dans un encombrement r´eduit.
Figure 2.9 – Module LoRa
5.2.2 Node-R
Figure 2.10 – Antenne LoRa
33

42. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
La station LoRa (Long Range) est une borne qui s’adresse aux op´erateurs de service de
connectivit´e M2M et Internet des objets voulant op´erer leur r´eseau en propre.
La borne int`egre la technologie Long Range d´evelopp´ee par Kerlink, ainsi que de la connecti-
vit´e 3G et Ethernet. Grˆace `a un boitier IP67, la station LoRa peut r´esister `a des conditions
d’installations s´ev`eres (humidit´e, poussi`ere, vent...). Elle peut ´etablir des communications
bidirectionnelles avec plusieurs milliers d’´equipements intelligents (capteurs, compteurs ou
objets connect´es) distants de plusieurs kilom`etres.
Les objets connect´es peuvent s’appuyer sur les r´eseaux cellulaires couverts par les op´erateurs
de t´el´ephonie (2G, 3G, 4G, LTE) pour transmettre leurs donn´ees mais ils sont con¸cus pour
de tr`es haut d´ebit et consomment en contrepartie beaucoup d’´energie.
C’est pour ¸ca, nous nous appuyons sur la technologie LoRa bas´ee sur des r´eseaux longue
port´ee, qui a la particularit´e de se baser sur une transmission basse fr´equence, basse consom-
mation d’´energie mais bas d´ebit.
LoRa comble un vide entre les technologies radio `a courte port´ee (WiFi, Bluetooth, ZigBee..)
et celles de r´eseaux mobiles, `a plus longue port´ee. Fonctionnant avec un d´ebit adaptatif
de 0.3 `a 50 Kbit/s, elle allie faible consommation d’´energie (jusqu’`a dix ans d’autonomie
pour les produits `a batterie) et longue port´ee (jusqu’`a 15 km en champ libre), LoRa dispose
d’autres atouts : bonne facult´e de p´en´etration dans les bˆatiments ou en sous-sol, communica-
tion bidirectionnelle et s´ecuris´ee, objets en mobilit´e, g´eolocalisation. LoRa fonctionne sur des
fr´equences entre 863 et 870 MHz. Cette technologie est tr`es peu gourmande en ´energie. Les ap-
plications d’un tel r´eseau peuvent concerner les donn´ees des compteurs d’eau et d’´electricit´e,
la gestion de l’´eclairage public ou de l’affichage intelligent, la maintenance pr´edictive sur di-
vers appareils, des services de localisation, etc...
L’utilisation de la technologie d’´etalement du spectre permet la communication avec des
diff´erents d´ebits sans interf´erence. De cette fa¸con, un ensemble de canaux virtuels est cr´ee
pour augmenter la capacit´e de la passerelle.
Nous citons ci-dessous les caract´eristiques du module LoRa :
• ´Emetteur/R´ecepteur LoRa, sensibilit´e -138 dBm : Transmission longue distance, permet-
tant de recevoir les donn´ees dans toutes les conditions. Un degr´e ´elev´e de sensibilit´e est
id´eal pour les d´eploiements Smart City.
• Technologie radio sans fil embarqu´ee dans le capteur : Une radio int´egr´ee permet une
r´eponse plus rapide, id´eale pour les communications point `a point, r´eduisant ainsi les
couts d’infrastructure.
• Logiciels de gestion des modules arduino : Open source API fourni et deux modes de tra-
vail possibles : 868 MHz et 915 MHz. Plateformes mat´erielles configurables facilement
et g´erables via une interface web.
• Biblioth`eque de chiffrement disponibles : Les communications sont crypt´ees entre les
p´eriph´eriques. L’authentification est s´ecuris´ee, l’int´egrit´e des donn´ees est maintenue
et les informations restent confidentielles.
34

43. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
• Deux radios d´eployables dans chaque dispositif. Les capteurs Libelium peuvent ˆetre utilis´es
avec un second module radio, tel que la 3G, et peuvent travailler en simultan´es.
5.2.3 Node-S
C’est un serveur proxy qui servirait d’interm´ediaire entre la passerelle et l’Internet. La
passerelle est connect´ee au serveur proxy.
L’utilisation d’un serveur proxy nous donne la possibilit´e d’utiliser le cache, la s´ecurit´e, le surf
anonyme ainsi que le filtrage, c’est `a dire, comme toute les requˆetes et les r´eponses passent
par le proxy, il est possible de filtrer ce que nous autorisons `a sortir ou `a entrer.
5.2.4 Node-G
Il s’agit de la passerelle plus pr´ecis´ement le software d´evelopp´e pour donner l’acc`es `a In-
ternet aux objets connect´es. Le trafic re¸cu et envoy´e par les Nodes-F passe toujours par la
Node-G via un tunnel JSON en passant par la station LoRa. La passerelle ´ecoute sur le port
1790 avec le ”Upstream UDP Protocol” pour le trafic ascendant et sur le port 1792 avec le
”Downstream UDP Protocol” pour le trafic descendant.
La passerelle a ´et´e `a l’origine d´evelopp´ee pour assurer l’int´egration des capteurs sans fil
d´eploy´es avec des applications Web. Des sc´enarios de test sont r´ealis´es dans notre plateforme
d’exp´erimentation pour valider l’architecture de la passerelle.
Parmi les fonctionnalit´es de la passerelle, nous pouvons citer :
• Ajout/Suppression du MAC Header de la trame.
• Localiser les nœuds dans la r´egion couverte par le r´eseau LoRa.
• Adapter une vitesse de transmission pour le lien radio.
• Donner des priorit´es aux transmissions pour optimiser l’occupation du canal.
• Maintenir un plan de signalisation pour enregistrer les Nodes-F, n´egocier les cl´es de
chiffrement, les adresses MAC.
5.3 Standards utilis´es
Lors du projet LORA FABIAN, nous avons utilis´e de nouveaux protocoles et standards
Internet.
5.3.1 CoAP (Constrained Application Protocol)
Les r´eseaux de capteurs sont des composants qui poss`edent des ressources contraintes.
Ils disposent notamment d’une capacit´e m´emoire, d’une puissance, d’une bande passante et
d’une r´eserve ´energ´etique tr`es limit´ee. Ces nœuds contraints ont besoin d’un protocole `a la
fois complet et l´eger pour communiquer. Le nouveau standard Internet Engineer Task Force
IETF Constrainted Application Protocol CoAP [15] `a pour objectif d’´etendre l’architecture
web aux applications Machine to Machine M2M utilisant des syst`emes contraints, il s’agit
d’un protocole de communication g´en´erique optimis´e pour les architectures contraintes. Ce
35

44. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
protocole peut ˆetre d´efini comme un sous-ensemble de HTTP dont le coˆut d’utilisation a ´et´e
r´eduit.
Les principales caract´eristiques du protocole CoAP sont les suivants :
• Gestion des m´ethodes : CoAP met `a disposition les requˆetes GET, PUT, POST et
DELETE. Ces m´ethodes vont pouvoir ˆetre utilis´ees par le client pour acc´eder aux
donn´ees.Leur utilisation est similaire `a celle de HTTP.
• Une entˆete concise : L’entˆete CoAP a ´et´e con¸cu pour ˆetre facile `a analyser par des
programmes tournant sur des petits ´equipements comme les capteurs. Au lieu du texte
lisible de HTTP, l’entˆete de CoAP commence par une partie fixe de quatre octets.
• Les URIs (Uniform Ressource Identifier) : Le protocole supporte les URIs ce qui
va permettre de sp´ecifier la cible grˆace `a un nom d’hˆote, un port, un chemin et un
param`etre de requˆete.Comme par exemple, la requˆete coap ://monserveurcoap/.well-
known/core ?n=Light qui est une r´eponse `a la demande de l’´etat de ressource n.
• Le type de contenu : Le protocole permet de transporter des donn´ees d’usages diff´erents
en mettant dans l’entˆete le type de donn´ees de la charge utile.
• La d´ecouverte de ressources : La d´ecouverte de ressources est un besoin cl´e dans
une architecture web et notamment pour les applications M2M. En effet, cette re-
cherche doit ˆetre autonome et ne doit pas avoir besoin d’une int´eraction humaine.
Les serveurs CoAP doivent pouvoir fournir une URI afin que le serveur puisse ˆetre
d´ecouvert.La decouverte de ressources pour CoAP consiste `a une r´eponse `a la requˆete
coap ://monserveurcoap/.well-known/core.
5.3.2 UDP
Le protocole UDP permet aux applications d’acc´eder directement `a un service de transmis-
sion de datagrammes. En effet, les applications satisfaisant `a un mod`ele du type ”interrogation-
r´eponse” peuvent utiliser UDP, plus particuli`erement dans le contexte de l’Internet des objets
o`u les chercheurs cherchent `a diminuer la consommation de ressources et ´eviter les protocoles
qui envoient beaucoup de messages, dans ce cadre nous avons choisi d’utiliser UDP au lieu
de TCP pour gagner en terme de vitesse de transmission et ´eviter les messages de synchro-
nisation.
Pour les sequencement des messages, il sera assur´e par le protocole LoRa et par cons´equent
nous gagnons en terme de taille de paquet et de temps de r´eponse. La r´eponse peut ˆetre
utilis´ee comme ´etant un accus´e de r´eception positif `a l’interrogation, si une r´eponse n’est
pas re¸cue dans un certain intervalle de temps, l’application envoie simplement une autre
interrogation.
5.3.3 IEEE 802.15.4
Le 802.15.4 est un protocole de communication d´efini par l’IEEE. Dans notre architecture,
il est utilis´e par les capteurs (Nodes-F) et la station LoRa (Node-R) pour collecter les donn´ees.
36

45. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
Il est destin´e aux r´eseaux sans fil de la famille des LPWAN (Low Rate Wireless Personal Area
Network) du fait de leur faible consommation, de leur faible port´ee et du faible d´ebit des
dispositifs utilisant ce protocole.
Le standard 802.15.4 fonctionne au niveau des couches physiques et liaison de donn´ees.
• La couche physique : La couche physique (PHY) contient l’´emetteur/r´ecepteur radio
(RF), avec un m´ecanisme de contrˆole de bas niveau (contrˆole de la qualit´e du signal,
d´etection d’´energie). Les fr´equences basses permettent d’avoir une plus grande port´ee
grˆace `a une plus faible perte de propagation. Les plus grandes provoquent des sorties
plus ´elev´ees, une plus faible latence et des cycles de travail plus courts.
• La couche de contrˆole d’acc`es au support : Le standard 802.15.4 fait la distinction entre
la partie de la couche MAC responsable du transfert des donn´ees, la sous-couche MAC
commune MCPS (MAC Common Part Sublayer) et la partie responsable de la gestion
de la couche MAC est MLME (MAC Layer Management Entity). La MLME comprend
les param`etres de configuration et d’´etat de la couche MAC, comme l’adresse IEEE
sur 64 bits et l’adresse courte du nœud sur 16 bits, le nombre de tentatives d’acc`es
au r´eseau en cas de collision (en g´en´eral quatre, mais cinq au maximum), la dur´ee
d’attente d’un accus´e de r´eception (en g´en´eral 54 unit´es de dur´ee d’un symbole, mais
120 au maximum) ou le nombre de renvois d’un paquet rest´e sans accus´e de r´eception
(0–7). Concernant l’association des nœud, pour rejoindre un r´eseau, un nœud envoie
une requˆete d’association `a l’adresse du coordinateur. Cette requˆete pr´ecise le PAN ID
que le nœud souhaite rejoindre, ainsi qu’un ensemble d’indicateurs de capacit´es cod´es
sur un octet.
• Avantages IEEE 802.15.4 : Le standard 802.15.4 a ´et´e ratifi´e par l’IEEE. Elle ne
n´ecessite pas de licence sp´ecifique. L’avantage majeur du standard 802.15.4 est que
la technologie est peu consommatrice en ´energie. Elle peut, de plus, ˆetre int´egr´ee `a bas
coˆut dans les ´equipements.
Figure 2.11 – Avantage du protocole 802.15.4
37

46. CHAPITRE II. SP´ECIFICATION DES BESOINS ET CONCEPTION
La diff´erence [16] entre 802.15.4 et la plupart des autres r´eseaux locaux et person-
nels sans fil (WiFi, Bluetooth) se situe au niveau de l’utilisation du m´edium hertzien ;
802.15.4 est optimis´e pour une faible utilisation du m´edium partag´e par tous, par
exemple 0,1% du temps. Typiquement, un module 802.15.4 occupera le m´edium pen-
dant quelques millisecondes en ´emission, attendra ´eventuellement une r´eponse ou un
acquittement, puis se mettra en veille pendant une longue p´eriode avant l’´emission
suivante, qui aura lieu `a un instant pr´ed´etermin´e.
5.3.4 La bande ISM (Industrial, Scientific and Medical) 868 MHz
Les bandes ISM sont des bandes de fr´equences qui peuvent ˆetre utilis´ees, pour des ap-
plications industrielles, scientifiques, m´edicales, domestiques ou similaire, `a l’exception des
applications de radiocommunication, sans demande d’autorisation aupr`es des autorit´es.
Depuis 2006, l’ARCEP (Autorit´e de R´egulation des Communications Electroniques et des
Postes) autorise l’utilisation en France de la bande 865-868 MHZ. Cette bande encore peu
employ´ee offre certains avantages, en particulier la possibilit´e d’utiliser une puissance de 500
mW au lieu de 10 mW en 433 MHz. La taille de l’antenne en 868 MHz est 2 fois plus pe-
tite pour la mˆeme efficacit´e. Enfin, la bande 868 MHz est partag´ee uniquement entre des
utilisateurs dont les puissances d’´emission et les taux d’utilisation sont a priori homog`enes,
r´eduisant ainsi les risques de brouillage.
Parmi les avantages de la bande ISM 868 MHz, nous pouvons citer :
• Possibilit´e de changer de canal si brouillage.
• Temps de cycle en transmission non d´enombrable.
• Tension d’alimentation : 3,3V.
• Alimentation secteur + batterie (limitation de la consommation).
5.4 Prolongement des web objets vers les capteurs
L’Internet des objets est devenu un r´eseau d’objets web reli´es d’une mani`ere asym´etrique
via des applications ou des plateformes. Si votre capteur est connect´e `a une plateforme, il
lui envoie des donn´ees, mais n’en re¸coit quasiment pas d’elle (hormis peut-ˆetre des mises `a
jour).
Alors que dans le r´eseau LORA FABIAN d´esormais nous pouvons communiquer avec les
objets connect´es. Nous sommes pass´es d”un mod`ele d’interconnexion directe des objets entre
eux, de r´eseaux ad hoc d’objets `a un mod`ele o`u chaque objet est reli´e `a une plateforme web,
qui g`ere ensuite, `a son gr´e les interactions entre les objets. Cela permet certes d’acc´eder `a
des plateformes logicielles et mat´erielles suffisamment souples et ouvertes pour contourner
les probl`emes de normes et de standards dans lesquels s’empˆetrent tous les projets d’inter-
connexion des objets.
38