Projet Passerelle sécurisée intelligente pour l'internet des objets

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

DEDICACES

Je dedie ce travail . . .

A ma mereAucune dedicace ne pourra traduire ma profonde affectation et ma grandereconnaissance pour tes interminables sacrifices tant pour mon educationque pour mon bien etre. Tu es pour moi le symbole de la tendresse et dudevouement familial qui m’a toujours rempli d’admiration. Je suis tellementfier d’etre ton fils que je ne peux en mesurer le bonheur. J’espere que tutrouveras dans ce travail le fruit de tes efforts. Que Dieu te protege ett’accorde sante et longue vie.

A mon perePuisse ce travail te temoigner mon amour, ma reconnaissance et monadmiration pour ton devouement, tes qualites humaines et ta culture, quifont de toi un pere exemplaire et qui me serviront de guide dans ma carriereet dans ma vie. C’est grace a tes sacrifices, ta patience, ton encouragementet tes prieres que je suis arrive a franchir cette premiere grande etape de mavie. Que Dieu, le tout puissant, te garde, te procure sante, bonheur et longuevie.

A ma sœurAucune dedicace ne saurait exprimer mon admiration, mon profond amourfraternel et mon immense attachement. Que ce travail soit un temoin demon affection sincere.

Remerciements

Avant tout developpement sur cette experience professionnelle, il apparaıt opportun decommencer ce rapport par des remerciements, a ceux qui ont contribue, de pres ou de loin, ala realisation de ce travail, a ceux qui m’ont beaucoup appris durant cette periode et a ceuxqui ont eu la gentillesse de faire de cette experience un moment tres profitable.

Notamment, j’exprime ma profonde gratitude a monsieur le chef de departement Reseaux,Securite et Multimedia a Telecom Bretagne M.Jean Marie Bonnin de m’avoir accorde le pri-vilege d’acceder 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 mestuteurs a Telecom Bretagne Mr.Alexander Pelov M.Laurent Toutain M.Mathieu Goessenset M.Renzo Navas pour leurs precieuses instructions et pour leur assistance pendant lederoulement de mon projet.

Mes remerciements les plus sinceres s’adressent a mon encadrant a l’INSAT M.SouheibYousfi pour m’avoir guide et oriente tout au long de ce travail.

Qu’il me soit permis egalement de remercier tous les ingenieurs, les techniciens et lesdoctorants a Telecom Bretagne, pour leur soutien precieux et leurs riches conseils.

Je suis particulierement reconnaissant a l’Institut National des Sciences Appliquees et deTechnologie (INSAT) pour m’avoir offert l’opportunite d’acquerir cette experience qui, sansdoute, me sera d’un grand apport dans ma vie professionnelle.

Table des matieres

Liste des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction generale 1

I Cadre du projet 3Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Presentation de la structure d’accueil . . . . . . . . . . . . . . . . . . . . . . 4

1.1 Axes de recherches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Collaboration internationale . . . . . . . . . . . . . . . . . . . . . . . 5

2 Presentation du projet LORA FABIAN . . . . . . . . . . . . . . . . . . . . . 52.1 Equipe du projet LORA FABIAN . . . . . . . . . . . . . . . . . . . . 62.2 Partenaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Contraintes et etat actuel du projet . . . . . . . . . . . . . . . . . . . 6

3 Presentation de la mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1 Les taches principales . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Methode de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Diagramme de Gannt . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Internet des objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2 Approche historique . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.3 Couches protocolaires existantes . . . . . . . . . . . . . . . . . . . . . 114.4 Developpements technologiques dans l’Internet des objets . . . . . . . 124.5 Exemples d’applications . . . . . . . . . . . . . . . . . . . . . . . . . 154.6 Impacts de l’Internet des objets . . . . . . . . . . . . . . . . . . . . . 164.7 Evaluation de performances dans l’Internet des objets . . . . . . . . . 17

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

II Specification des besoins et conception 19Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Specification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 201.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 21

2 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 222.1 Presentation des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 222.2 Description des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 22

3 Diagramme de sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1 Diagramme de sequence fonctionnel . . . . . . . . . . . . . . . . . . . 253.2 Diagramme de sequence applicatif . . . . . . . . . . . . . . . . . . . . 26

4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 Description des classes . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Interoperabilite dans le reseau LORA FABIAN . . . . . . . . . . . . . . . . . 31

5.1 Architecture du reseau LORA FABIAN . . . . . . . . . . . . . . . . . 315.2 Elements du reseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3 Standards utilises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.4 Prolongement des web objets vers les capteurs . . . . . . . . . . . . . 385.5 Format des paquets dans le reseau LORA FABIAN . . . . . . . . . . 425.6 Types de trames circulant dans le reseau . . . . . . . . . . . . . . . . 46

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

III Implementation 49Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 Realisation de la librairie pour la generation du trafic vers la passerelle . . . 50

1.1 Presentation des outils utilises . . . . . . . . . . . . . . . . . . . . . . 501.2 Presentation de la tache . . . . . . . . . . . . . . . . . . . . . . . . . 51

2 Definition, extraction et enregistrement des KPI . . . . . . . . . . . . . . . . 552.1 Presentation des outils utilises . . . . . . . . . . . . . . . . . . . . . . 552.2 Presentation de la tache . . . . . . . . . . . . . . . . . . . . . . . . . 56

3 Analyse de la performance du reseau LoRa . . . . . . . . . . . . . . . . . . . 633.1 Presentation des outils utilises . . . . . . . . . . . . . . . . . . . . . . 633.2 Presentation de la tache . . . . . . . . . . . . . . . . . . . . . . . . . 64

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Conclusion generale 73

Bibliography 74

Table des figures

Figure 1.1: Repartition des taches du projet . . . . . . . . . . . . . . . . 9Figure 1.2: Pile protocolaire pour l’Internet des objets . . . . . . . . . . 11Figure 1.3: Pile protocolaire pour l’ancienne et la nouvelle de ZigBee . . 12Figure 1.4: Evolution du M2M vers l’Internet des objets . . . . . . . . . 13Figure 1.5: Technologies de communication dans l’Internet des objets . . 13

Figure 2.1: Diagramme de cas d’utilisation pour l’administrateur . . . . 23Figure 2.2: Diagramme de cas d’utilisation pour l’utilisateur de la librairie 25Figure 2.3: Diagramme de sequence fonctionnel . . . . . . . . . . . . . . 26Figure 2.4: Diagramme de sequence applicatif . . . . . . . . . . . . . . . 27Figure 2.5: Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . 28Figure 2.6: Architecture generale du reseau LORA FABIAN . . . . . . . 31Figure 2.7: Differents participants dans le projet . . . . . . . . . . . . . . 32Figure 2.8: Capteur Node-F . . . . . . . . . . . . . . . . . . . . . . . . . 33Figure 2.9: Module LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figure 2.10: Antenne LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figure 2.11: Avantage du protocole 802.15.4 . . . . . . . . . . . . . . . . . 37Figure 2.12: Pile protocolaire du capteur vers la passerelle . . . . . . . . . 39Figure 2.13: Liens entre les nœuds dans le reseau . . . . . . . . . . . . . . 40Figure 2.14: Communication CoAP et HTTP dans LORA FABIAN . . . . 40Figure 2.15: Nommage des ressources . . . . . . . . . . . . . . . . . . . . 41Figure 2.16: Signalisation dans le reseau . . . . . . . . . . . . . . . . . . . 42Figure 2.17: Trame MAC generale . . . . . . . . . . . . . . . . . . . . . . 43Figure 2.18: Trame LoRa MAC . . . . . . . . . . . . . . . . . . . . . . . . 43Figure 2.19: Format d’adresse de la passerelle . . . . . . . . . . . . . . . . 44Figure 2.20: Champ de controle . . . . . . . . . . . . . . . . . . . . . . . . 44Figure 2.21: Frame Control pour les trames beacon . . . . . . . . . . . . . 45Figure 2.22: Frame Control pour les trames emises par la Node-G . . . . . 45Figure 2.23: Frame Control pour les trames recues par la Node-G . . . . . 46Figure 2.24: Trame balise LoRa Mac . . . . . . . . . . . . . . . . . . . . . 46Figure 2.25: Trame de signalisation du Node-F vers la Node-G . . . . . . 47Figure 2.26: Trame de donnee du Node-G vers la Node-F . . . . . . . . . 47

Figure 3.1: Diagramme de sequence entre la station LoRa et la Gateway 52Figure 3.2: Composants du JSON dans les paquets . . . . . . . . . . . . 53Figure 3.3: Architecture de la librairie developpee . . . . . . . . . . . . . 53Figure 3.4: Classes developpees pour la configuration de la librairie . . . 54Figure 3.5: Envoi des paquets par la librairie . . . . . . . . . . . . . . . . 54Figure 3.6: Initialisation des services au niveau de la Node-G . . . . . . . 58

Figure 3.7: Demarrage des services au niveau de la Node-G . . . . . . . . 58Figure 3.8: Passerelle en ecoute . . . . . . . . . . . . . . . . . . . . . . . 59Figure 3.9: Verification de la taille des paquets recus . . . . . . . . . . . 59Figure 3.10: Application des regles de filtrage aux paquets a la reception . 60Figure 3.11: Acquittement sur les paquets recus . . . . . . . . . . . . . . . 60Figure 3.12: Enregistrement des KPIs dans la base de donnees . . . . . . . 61Figure 3.13: Donnees enregistrees dans la table ReceivedpacketsStats . . . 61Figure 3.14: Donnees enregistrees dans la table GeneralStats . . . . . . . 62Figure 3.15: Envoi des paquets enregistres a Logstash . . . . . . . . . . . 62Figure 3.16: Envoi des KPIs vers Logstash . . . . . . . . . . . . . . . . . . 62Figure 3.17: Fonctionnement de la pile ELK . . . . . . . . . . . . . . . . 63Figure 3.18: Configuration de l’agent Logstash . . . . . . . . . . . . . . . 65Figure 3.19: Lancement et reception des donnees par Logstash . . . . . . 65Figure 3.20: Demarrage d’Elasticsearch . . . . . . . . . . . . . . . . . . . 66Figure 3.21: Reception des donnees par Elasticsearch . . . . . . . . . . . . 66Figure 3.22: Lancement du serveur HTTP pour Kibana . . . . . . . . . . 67Figure 3.23: Page d’accueil de Kibana . . . . . . . . . . . . . . . . . . . . 67Figure 3.24: Filtrage des logs en fonction du temps d’arrivee . . . . . . . . 68Figure 3.25: KPIs enregistrees dans la base de donnees d’Elasticsearch . . 68Figure 3.26: Courbe de RSSI en fonction du temps . . . . . . . . . . . . . 69Figure 3.27: Histogramme de la taille des paquets en fonction du temps . 69Figure 3.28: Regroupement des paquets selon leur ID/MAC/temps d’envoi 70Figure 3.29: Statistiques avec Kibana . . . . . . . . . . . . . . . . . . . . 70Figure 3.30: Classification des paquets selon leur Code Rate . . . . . . . . 71Figure 3.31: Classification des paquets selon leur Data Rate . . . . . . . . 71Figure 3.32: Exemple d’un tableau de bord choisi sur Kibana . . . . . . . 72

Abreviations

6LoWPAN IPv6 Low Power Wireless Personal Area Networks

AFNIC Association Francaise pour le Nommage de l’Internet en Cooperation

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 Reseaux Securite Multimedia

RSSI Radio Signal Strength Indication

TCP Transmission Control Protocol

UDP User Datagram Protocol

WSN Wireless Sensor Network

Introduction generale

Les reseaux a faible consommation d’energie ont vecu une grande evolution depuis ledebut du XXIeme siecle. De nombreux chercheurs se sont interesses a l’etude de l’effica-cite energetique et ont propose de nouvelles cartes reseaux sans fil a faible consommationd’energie.

Cependant, la consommation energetique d’un nœud mobile ne depend pas seulement desprotocoles des couches physiques et liaison de donnees, mais aussi des protocoles des couchessuperieures. D’autre part, le deploiement de ces reseaux dans le monde reel a affronte d’autresobstacles que la consommation energetique comme les problemes de fiabilite et d’adressage.Une premiere solution a ete proposee en 2003 par ZigBee alliance. La specification ZigBeea complete la norme IEEE 802.15.4 (Institute of Electrical and Electronics Engineers) enlui ajoutant quatre composantes principales : la couche reseau, la couche application, lesperipheriques ZigBee et les objets applicatifs. Toutefois, cette solution n’a pas obtenu ungrand succes vu les problemes d’evolutivite et d’integration avec le grand reseau IP (InternetProtocol) du monde Internet.

En 2005, un nouveau groupe de travail a l’IETF (Internet Engineering Task Force),nomme 6LoWPAN (IPv6 LoW Power wireless Area Networks), a eu l’idee du deploiementd’IPv6 dans les reseaux a faible consommation d’energie pour resoudre le probleme 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’interieur et a l’exterieur du reseausans fil. Ces derniers, appeles aussi objets intelligents, ont change le concept de l’Internetqui ne se limite pas qu’aux reseaux informatiques classiques, mais s’etend a tous les objetsde la vie quotidienne. L’extension de l’Internet a tous les objets du monde reel represente lanotion d’Internet des Objets.

De nos jours, la plupart des objets qui nous entourent ont la vocation d’etre connectes.Etant equipes d’une puce ou d’un capteur, ils se mettent ainsi a produire des donnees. Dansce 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 reseaux de capteurs.

Les reseaux de capteurs sans fil WSN (Wireless Sensor Networks) ont durant la dernieredecennie pris un role sans cesse croissant, et desormais preponderant, dans de nombreusesapplications destinees a mettre en place des environnements dits ”intelligents”.

Pour etre efficaces, notamment dans ces applications, de tels reseaux doivent le plussouvent faire intervenir un ensemble tres heterogene de capteurs, actionneurs, et autres ap-

1

pareils electroniques embarques : ces systemes heterogenes reposent sur l’interoperabilite deces differents elements. La dite interoperabilite necessite de suivre des standards precis etadaptes, mais aussi un certain travail de recherche et des developpements importants pourmettre en synergie ces differents standards de facon optimale.

L’un des objectifs du travail presente dans ce rapport est de mettre a disposition surInternet, de facon simple, efficace et sure, les donnees fournies par ces reseaux de capteursheterogenes, facilitant ainsi le developpement des applications tierces pour le maintien a do-micile (suivi et analyse des activites quotidiennes, de l’evolution de sante, assistance...). Nousavons ainsi ete amenes a faire interoperer plusieurs standards a travers une passerelle, gracea elle, l’acces a des donnees heterogenes est grandement simplifie, que ce soit pour des pro-grammes via des API (Application Programming Interface), ou pour le Web via Internet.

Ce stage, d’une duree de six mois, son but est la mise en place d’une passerelle quipermet de donner l’acces a Internet aux differents objets connectes en ayant recours a l’in-teroperabilite entre les differents protocoles et nouveaux standards internet qui caracterisel’Internet des objets.

Ce rapport presente le travail realise au sein du departement RSM (Reseaux, Securite etMultimedia) a l’Institut Mines-Telecom Bretagne-UEB (Universite europeenne de Bretagne),il s’articule autour de trois chapitres. Le premier chapitre presente le cadre du projet ou nousavons fait une petite ouverture sur le domaine de l’Internet des objets, dans le deuxiemechapitre consiste sur deux parties principales, la premiere repose sur la specifications desbesoins et la conception du projet, la deuxieme partie met en relief l’interoperabilite dans lereseau developpe par Telecom Bretagne, le troisieme chapitre contient la partie realisationet les differents resultats.

2

Chapitre I

Cadre du projet

PlanIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1 Presentation de la structure d’accueil . . . . . . . . . . . . . . . . . . . . 4

1.1 Axes de recherches . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Collaboration internationale . . . . . . . . . . . . . . . . . . . . . 5

2 Presentation 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 Presentation de la mission . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Les taches principales . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Methode de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 Diagramme de Gannt . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Internet des objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2 Approche historique . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.3 Couches protocolaires existantes . . . . . . . . . . . . . . . . . . . 11

4.4 Developpements 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

CHAPITRE I. CADRE DU PROJET

Introduction

Dans ce chapitre, nous nous interessons a mettre notre projet dans son contexte a savoirl’organisme d’accueil Telecom Bretagne et son domaine d’activite.Nous presentons egalement les motivations de notre sujet et la demarche suivie pour sarealisation ainsi que les notions de base necessaires pour comprendre notre contribution dansle projet.

1 Presentation de la structure d’accueil

Telecom Bretagne [1] est une grande ecole d’ingenieur generaliste et un centre de re-cherche international en sciences et technologies de l’information.Creee en 1977, Telecom Bretagne offre, sur ses campus de Brest, Rennes et Toulouse, desformations d’ingenieur et de 3e cycle (masteres, DNM, MSc, doctorat, formation continue).L’ecole accueille plus d’un millier d’eleves, dont 70% d’eleves ingenieurs et 30% d’eleves de3e cycle (dont environ 200 doctorants).

Les enseignants-chercheurs de Telecom Bretagne sont repartis dans 9 departements ou ilsconduisent une recherche de pointe dans tous les secteurs, des technologies de l’informationet de la communication, et de la conception de nouveaux produits a l’etude de nouveauxusages.

La recherche a Telecom Bretagne est coordonnee par la direction scientifique dans le cadre dela politique commune definie par l’Institut Mines-Telecom auquel l’ecole appartient. Elle estcentree sur les STIC (Sciences et Technologies de l’information) dont elle couvre un grandnombre de champs d’application : Sante, Mer, Defense, Finances, Banque, Transport...

Le departement RSM, ou j’ai effectue mon stage, est situe sur le campus de Rennes deTelecom Bretagne. Son domaine d’activite recouvre tous les aspects de l’enseignement, de larecherche et developpements en reseaux, tout particulierement les technologies IP, les reseauxet services de mobiles et la securite des reseaux.

1.1 Axes de recherches

Le departement RSM travaille en partenariat tant avec des centres de recherche qu’avecdes industriels et operateurs de telecommunications francais et europeens.Il poursuit des recherches dans trois axes :

• Gestion de ressources et de mobilite pour les reseaux radios.• Securite des systemes d’information.• Protocoles et architectures des reseaux IP avec un accent particulier sur IPv6.

Le departement RSM est membre du departement D2 de l’IRISA [2] a travers les equipesde recherches suivantes : REOP (Reseaux d’operateurs) et OCIF (Objets communicants pourl’Internet du Futur). Cette derniere focalise ses travaux de recherche sur l’Internet des objets,le domaine dans lequel notre projet se focalise.

4


1.2 Collaboration internationale

Telecom Bretagne a developpe, au niveau regional, national et international, des partena-riats avec de nombreux acteurs de l’enseignement superieur, de la recherche et de l’industrie.Ceci s’est concretise par plusieurs accords avec differents pays :

• Bresil : Le departement RSM, en association avec l’IRISA et l’Universite de ParisVI, collabore avec l’universite federale de Bahia et l’universite federale de Paraiba. Lathematique de la collaboration est celle des grilles de calcul et de l’algorithmique dis-tribuee.

• Coree du Sud : Le projet Easy6 se place dans le cadre du programme d’actionsintegrees franco-coreen STAR. Il est mis en œuvre en Coree par la KOSEF (KoreaScience and Engineering Foundation) pour le compte du MOST (Ministere de la Scienceet de la Technologie). Le projet implique l’INRIA, Telecom Bretagne, France Telecom,6Wind, Korean Telecom et Seoul National University.

• Etats-Unis : Le departement RSM collabore avec l’universite de Columbia (New York)sur des thematiques liees au routage et a la theorie des jeux dans les reseaux. Dans lecadre de cette collaboration, un sejour d’etudes de six mois est en cours.

• Japon : Le projet Nautilus regroupe des entreprises et universites japonaises. Ce consor-tium vise de developper et experimenter de nouvelles technologies et protocoles pourfaire evoluer Internet, principalement IPv6.

2 Presentation du projet LORA FABIAN

LORA FABIAN (Long Range For A Beautiful Internet Advanced Network) [3] est undispositif connecte sans fil et open source elabore par les equipes RSM de Telecom Bretagnequi a pour but de deployer sur Rennes une couverture radio longue portee a travers la borneradio LoRa (Long Range) (Technologie radio offrant des communications bidirectionnelles abas debit dans un rayon de 4 km pour des milliers d’objets en simultane) et en utilisant desprotocoles standards et ouverts.

Il s’agit de creer un reseau d’objets connectes par le developpement d’une passerelle securiseeintelligente qui met en communication ces objets du quotidien equipes de capteurs en leurdonnant acces a Internet. En effet, sur le plan domestique, pas de soucis, la box et le wififont l’affaire. Sur le plan individuel, le smartphone et son reseau (3G, 4G) feront l’affaire,mais quand nous parlons des multiples de donnees, places de parkings disponibles, decibelsemis, comptages des fluides et autres donnees collectees par des capteurs, ces technologiessont limitees.

En plus de la connectivite 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 StandardsInstitute Machine To Machine) pour une meilleure integration dans l’Internet. La passerelleest concue pour supporter des communications de bout en bout entre des applications Web

5


et des reseaux de capteurs sans fils heterogenes deployes dans un habitat intelligent.

Deux types de communication peuvent etre traites par la passerelle :• Communication par interrogation : Un client Web interroge directement les res-

sources d’un capteur sans fil 802.15.4.• Communication spontanee : Les capteurs sans fil envoient, soit periodiquement,

soit en cas d’evenement, leurs donnees a la passerelle. Le client web peut alors recupererla derniere valeur envoyee par le capteur.

2.1 Equipe du projet LORA FABIAN

L’equipe du projet LORA FABIAN appartient au departement RSM et se concentre surles aspects de l’enseignement et de la recherche et developpement en reseaux, tout parti-culierement les technologies IP, les reseaux et services de mobiles et la securite des reseaux.

Lors de mon stage, le travail etait en equipe :• Alexander Pelov [4] : Maıtre de conference et mon tuteur du stage.• Laurent Toutain [5] : Maıtre de conference, porteur du projet LORA FABIAN.• Renzo Navas : Ingenieur de developpement et de recherche.• Mathieu Goessens : Ingenieur de developpement et de recherche.

2.2 Partenaires

Quatre partenaires contribuent au lancement du projet :

• La societe Kerlink [6] : Elle met a disposition du projet des bornes radio LoRa [7]qui permettent de deployer le reseau d’acces Long Range .

• Telecom Bretagne : Elle apporte sa competence en architecture et protocole reseaux,notamment pour tester des applications pour l’Internet des objets et la standardisationvers la 5G.

• La startup Wi6Labs [8] : Elle fournit aux makers souhaitant connecter des objetscommunicants a ce reseau des shields Arduino dedies [9]. Ils seront distribues en opensource avec une interface simple de developpement.

• L’AFNIC [10] : (Association Francaise pour le nommage de l’Internet en Cooperation)etudie une utilisation innovante du DNS pour gerer les objets et leur mobilite .

2.3 Contraintes et etat actuel du projet

Pour atteindre un objectif, il faut que celui-ci soit le plus precis possible. Il faut doncdefinir son projet le mieux possible et decrire avec precision la situation actuelle par rapporta la situation finale que nous souhaitons atteindre.

2.3.1 Contraintes

Chaque nouveau projet passe par un certain nombre de contraintes et surtout, quand ilest concu pour ajouter la valeur et ouvrir les opportunites au niveau du marche. Donc, il estnecessaire d’identifier les contraintes et les clefs de succes du marche :

6


• Sujet recent : Le projet LORA FABIAN est un sujet recent ou il n y a pas de docu-mentation sur Internet concernant l’architecture protocolaire et l’interoperabilite dansle reseau et donc le travail s’inscrit dans un projet d’innovation dans le domaine del’Internet des objets, Telecom Bretagne est la premiere a traiter les principes de fonc-tionnement de LORA FABIAN dans le monde de l’Internet des objets.

• Faible debit : Le projet LORA FABIAN est base sur des transmissions a bas debit,donc nous sommes limites en terme de bande passante et nous devons prevoir dessolutions pour ce probleme pour arriver a faire fonctionner les communications d’unemaniere parfaite.

2.3.2 Etat actuel du projet

Pour le bon fonctionnement du projet, les intervenants acheminent son avancement commesuit :

• Creation d’un draft pour le projet LORA FABIAN decrivant le nouveau type de trans-mission a longue portee, de la technologie radio a faible debit et le mecanisme extensiblepour faire fonctionner ces reseaux a base du protocole CoAP. Les drafts Internet sontdes documents de l’IETF.

• Les nœuds du reseau (Node-F, Node-G, Node-R et Node-S) sont fonctionnels et enphase de test, utilises pour des experimentations et pour des cours en attendant lapublication open source du projet.

• Deploiement a Rennes en production ete 2015 : Il y a eu le deploiement sur le territoirede la ville du Rennes (France) de l’architecture LORA FABIAN.

• Des etudes sur le deploiement du reseau LORA FABIAN sur d’autres regions pour fairedes experimentations sur la mobilite.

• Amelioration des protocoles et de l’implementation.

3 Presentation de la mission

Mon projet de fin d’etudes s’inscrit dans le projet LORA FABIAN, ma mission est decreer un outil pour l’analyse de performance du reseau LoRa implemente au niveau de lapasserelle developpee.

7


3.1 Les taches principales

Pour analyser la performance du reseau, il a fallu suivre les etapes suivantes :

3.1.1 Generation du trafic vers la passerelle

Lorsque les objets connectes (les capteurs) envoient leurs donnees vers le client, les infor-mations passent en premier lieu par l’antenne LoRa (le lien radio) qui redirige les donneesvers la passerelle que nous avons developpe pour les transmettre au client. Pour faire unesimulation de l’envoi des paquets vers la passerelle par l’antenne, nous avons cree des paquetsrespectant le format LORA MAC (format decrit dans le chapitre suivant) a partir d’une li-brairie python et par la suite, nous avons envoye ces paquets vers la passerelle pour qu’elleles traite. La generation du trafic etait au niveau reseau plus precisement au niveau radio(entre les objets connectes et la passerelle).

3.1.2 Definition et enregistrement des KPIs (Key Performance Indicators) :

A la reception des paquets, l’antenne LoRa ajoute certaines informations sur la qualitedu reseau et qui servent comme indicateurs de performances pour le reseau LoRa.Donc, en etudiant le format des paquets au niveau de l’antenne, nous avons choisi ceux quiservent comme indicateurs de performance dans le reseau LORA FABIAN, nous avons faitdes statistique sur le reseau et qui vont nous permettre d’analyser la performance du reseaua titre d’exemple (le nombre des paquets recus, le nombre des paquets envoyes, la taille...).Apres envoi des paquets par la librairie developpee a la passerelle, nous avons fait la receptiondes donnees, ainsi l’extraction des informations utiles pour valoriser la performance du reseau.Par la suite, nous avons enregistre les indicateurs de performance finaux dans une base dedonnees, l’analyse de la performance du reseau LORA FABIAN va se faire a partir de cesparametres.

3.1.3 Analyse de la performance du reseau LoRa :

La troisieme tache dans le stage consiste a preparer a l’administrateur de la passerelledeveloppee un outil qui permettra la collecte des differents indicateurs de performances en-registres en temps reel. Donc, apres l’envoi des paquets par la librairie developpee et leursenregistrement dans la base de donnees au niveau de la passerelle, il reste l’analyse de laperformance du reseau a partir des indicateurs etudies, nous avons eu recours a trois ou-tils complementaires et tres performants, la pile ELK (Elasticsearch, Logstash et Kibana)presentes dans la partie Implementation du rapport et qui permettent la collecte des donneesd’une maniere efficace. L’analyse des indicateurs de performance a partir de ces outils nouspermet de generer des courbes en temps reel sur le trafic au niveau du reseau, la charge dureseau et la maniere avec laquelle le reseau traite les donnees qui conduisent finalement al’analyse de la performance du reseau LoRa.

3.2 Methode de travail

Lors de la reunion de presentation du projet, les objectifs en terme de fonctionnalites et decontraintes du logiciel ont ete clairement definis. Toutefois un certain nombre de technologiesliees au projet etaient nouvelles, notamment le protocole CoAP et la technologie LoRa. Dans

8


cette situation, nous avons choisi d’appliquer la methode du cycle en V comme cycle dedeveloppement logiciel, puisqu’il presente les avantages d’integrer et de planifier la validationau cours du processus de conception, et il permet de pouvoir integrer des points de controletout au long du cycle.

3.3 Diagramme de Gannt

Nous presentons dans la figure 1.1 la repartition des taches du projet par un diagrammede Gannt :

Figure 1.1 – Repartition des taches du projet

Au cours du stage, nous avons rencontre de nouveaux concepts et protocoles qui sont encours d’apparition dans le monde applicatif. Nous avons rencontre differents problemes, atitre d’exemple le fait de ne pas avoir suffisamment de documentations pour nous aider aimplementer notre architecture reseau. L’integration dans l’equipe etait tres rapide grace aubon encadrement et le travail en equipe. Une des difficultes rencontre lors de la phase dudeveloppement est la creation des paquets dans la tache ”Realisation d’une librairie pour lageneration des paquets LORA”, en effet, il a fallu etudier comment les capteurs envoient lesdonnees a la passerelle et sous quelle format, d’ou il a fallu suivre le format et la specificationLORA et tester l’envoi des paquets a la passerelle. Pour verifier que ces paquets sont dansle bon format, nous avons implemente au niveau de la passerelle un outil qui n’accepte queles paquets LORA et rejette tout les autres donnees. Plusieurs conversions sur le format desdonnees etaient faite pour construire les bons paquets.

4 Internet des objets

Dans cette partie du rapport, nous allons presenter le secteur de l’Internet des objets,son evolution ainsi que son impact dans les differents domaines vu que notre sujet porte surles objets connectes communicants, alors dans le cadre du projet, il est necessaire de definirl’Internet des objets et fournir quelques exemples. Nous allons faire aussi une partie technique

9


ou nous allons detailler la communication entre les protocoles et les solutions existantes dansce domaine.

4.1 Definition

L’Internet des objets (Internet of things) est un des secteurs des telecommunications quidevrait voir la plus forte croissance dans les annees a venir. Certaines previsions evoquent50 milliards [11] d’objets connectes a l’horizon des annees 2020. Mais le terme internet desobjets est quelque peu ambigu. Si l’Internet est une technologie qui a fait ses preuves, ellen’est pas completement adaptee a la capillarite des reseaux connectant les objets. Un effortd’adaptation est necessaire pour prendre en compte le nombre tres important d’objets a gerer,qui ont souvent des contraintes energetiques fortes et des capacites de traitement limitees. Ilfaut egalement integrer le fait que les informations auxquelles donnent acces ces objets sontparfois de nature intrusive ou qu’une action sur ceux-ci peut avoir des consequences vitales.

Neanmoins le terme Internet des objets, reflete l’idee de faire remonter des informations dumonde reel (ou de lui transmettre des instructions) vers des (a partir de) systemes informa-tiques en utilisant les technologies les plus generiques possibles et en offrant la plus grandeinteroperabilite afin de mettre en œuvre des services innovants. Elle s’oppose a des approchesproprietaires et fermees, meme s’il faut, de toute facon, les prendre en consideration puisquela duree de vie d’un objet peut etre superieure a une dizaine d’annees, alors que les protocolesutilises dans les reseaux peuvent suivre un cycle d’evolution plus court.

L’aspect de l’Internet des objets consiste a realiser la connectivite Internet avec des solutionstechniques tres basse energie pour fonctionner avec une simple pile, voire uniquement enrecuperant l’energie dans l’environnement. Dans beaucoup de cas, cela se traduira par dessystemes radio a courte portee (quelques dizaines de metres pour les reseaux de capteurs),faible debit et des puissances radio de l’ordre du milliwatt. Une passerelle fait ensuite le lienavec l’Internet.

4.2 Approche historique

La principale force de l’Internet actuel, que nous pouvons appeler Internet des contenus,est d’offrir un ecosysteme coherent et ouvert, facilitant l’interconnexion des equipements etfavorisant la creation et le deploiement de nouveaux services. Un retour sur l’histoire d’Inter-net permet de mieux comprendre pourquoi les protocoles IP se sont imposes face a d’autresprotocoles qui semblaient mieux adaptes a leur environnement. Ce phenomene pourrait sereproduire pour l’Internet des objets.

Les protocoles de la famille IP n’ont jamais ete les meilleurs, compares a des protocolesplus specifiques. Ainsi dans les annees 80, quand IP s’est impose face a d’autres technologiescomme Frame Relay ou ATM (Asynchronous Transfer Mode), nous lui reprochions son prin-cipe de Best Effort face a des approches plus sophistiquees permettant d’offrir des classes deservices ou une plus grande fiabilite de transmissions.

Nous pourrons multiplier les exemples pour la telephonie sur IP ou la television connectee.Les fonctionnalites offertes par IP sont souvent inferieures a celles offertes par des solutions

10


proprietaires ou deployees pour resoudre un probleme specifique. Cependant, IP s’est im-pose, en partie, du fait des progres techniques qui ont apporte une augmentation des vitessesde transmission et ont contribue a l’amelioration de la qualite de service, mais egalementparce qu’il etait preferable d’avoir un protocole unique reduisant les couts des equipements.Ceci a favorise le developpement de circuits dedies facilitant la maintenance et l’administra-tion du reseau. Enfin, le protocole IP a toujours favorise l’interconnexion et permis d’offrirdes services de plus en plus evolues executables sur un grand nombre de types d’equipements.

Contrairement a l’Internet des contenus, ou tous les maillons de la chaıne doivent parler IPv6pour mettre en œuvre ce protocole, l’Internet des objets propose des architectures ou seuleune partie des equipements (les capteurs/actionneurs) sont dotes des capacites d’adressageet d’auto-configuration de la nouvelle version du protocole IP. Des passerelles permettantd’interconnecter facilement avec l’Internet actuel. Nous presenterons dans la suite ces archi-tectures basees sur le concept REST (Representational State Transfer).

4.3 Couches protocolaires existantes

Pour presenter la solution realisee dans le projet, il faut d’abord faire une etude del’existent dans le domaine de l’Internet des objets. Nous pouvons faire une approche pro-tocolaire avec le modele OSI (Open Systems Interconnection) et le protocole ZigBee.

4.3.1 Modele 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 figure1.2 a gauche qui correspond au modele de l’Internet (modele en couche) [12], les premiersa penser a l’Internet des objets ont commence par reutiliser le meme genre du modele pourl’Internet des objets, IP etait au milieu de l’architecture qui etait difficile a changer a causedes problemes pour IPv6, au final, nous avons IP, UDP (User Datagram Protocol) et TCP(Transmission Control Protocol ) tres bien installes ou c’est difficile de les changer.

Les chercheurs ont pense a construire des nouveaux standards sur ces protocoles et avecla difficulte de changer le protocole IP, ils se sont concentres a la couche application et enparticulier le protocole HTTP. Pour l’Internet des objets, au final, l’IETF qui travaille surces protocoles se sont dit que si HTTP avait un role 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


ils ont cree un nouveau protocole CoAP (une version simplifiee de HTTP fonctionnant surUDP) ou il y a beaucoup moins d’entete avec les memes notions d’URL (Uniform ResourceLocator) et la semantique du web donc une version REST a faible cout.

4.3.2 Zigbee

Figure 1.3 – Pile protocolaire pour l’ancienne et la nouvelle de ZigBee

Au debut de l’apparition de ZigBee [13], la technologie est basee sur le principe que toutdoit etre reformule et change, c’est pour ca, ZigBee a change l’architecture entiere du modelede l’Internet des objets OSI. Apres un certain temps, ils sont rendu compte que cette ver-sion 1 est completement deconnecte d’Internet et pour lesquels il fallait des mecanismes detraduction compliques. De ce fait, ils sont repasses sur le modele de l’Internet et donc repristout les memes protocoles de l’Internet.

Par contre, les couches protocolaires cites ont quelques limites, une des limites principales,c’est que nous somme sur des machines qui ont assez peu de capacite et de ressources et laquestion qui se pose que nous pouvons avoir des objets connectes a Internet sans avoir besoinde parcourir toute la couche protocolaire, parce qu’une adresse IPv6 sur 128 bits en sourceet en destinataire et que nous avons par exemple 10 octets par message pose des problemes.

4.4 Developpements technologiques dans l’Internet des objets

Au cœur des evolutions technologiques de nombreux secteurs, les technologies de l’Internetdes objets progressent rapidement.Nous parlerons ici de trois developpements principaux, depuis la couche physique jusqu’auxaspects systemes.

12


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 centreinformatique capable de prendre des decisions, et des reseaux de communication.Une definition generale a permis d’etablir la relation entre le concept d’interconnexion d’ob-jets et celui d’intercommunication de machines. En termes generaux, le M2M est un ensemblede technologies d’information et de la communication, destinees 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 portee des communications humaines et permeta votre entreprise de repondre a des besoins concrets comme la gestion des ressources, l’au-tomatisation de procede...

Les objets connectes peuvent communiquer leurs donnees par 3 types de solutions presentees :une communication courte-portee, un Hub qui est lui-meme connecte a internet ou via unreseau avec une longue portee. La figure 1.5 presente les technologies de communicationpossibles dans l’Internet des objets.

Figure 1.5 – Technologies de communication dans l’Internet des objets

• Communication courte-portee : Faible distance entre l’emetteur et le recepteur, l’echangede donnees se fait par contact physique entre l’emetteur et le recepteur (par exemplegrace a un port ethernet ou a un port USB), par la technologie NFC (Near Field com-munication) ou par RFID (Radio Frequency Identification).

13


• Communication via un hub moyenne portee connecte a Internet : Faible distance entreemetteur et recepteur, l’echange de donnees se fait par contact physique entre l’emetteuret le recepteur (par exemple grace a un port Ethernet ou a un port USB), par la tech-nologie NFC ou par RFID.

• Communication via une solution longue portee : Dans le cas d’objets qui ont besoinde pouvoir communiquer de longue distance, ou de zones difficilement accessibles, lasolution de la communication courte portee et la solution de la communication parHub sont inefficientes. Il est donc dans ce cas necessaire de s’appuyer sur un reseauqui permet une connexion en tout lieu couvert par les antennes. Les objets connectespeuvent s’appuyer sur les reseaux cellulaires couverts par les operateurs de telephonie(2G, 3G, 4G, LTE) pour transmettre leurs donnees mais ils sont concus pour de treshaut debit et consomment en contrepartie beaucoup d’energie. Les objets connectespeuvent egalement s’appuyer sur des reseaux longue portee, qui ont la particularite dese baser sur une transmission basse frequence, basse consommation d’energie mais basdebit. Sigfox, LoRa (par Semtech) et Neul (par Huawei) developpent ces reseaux enadressant specifiquement les objets connectes.

4.4.2 L’amelioration des technologies radio

Pour de nombreux usagers emergents, les technologies radio possedent des avantages im-portants : la reduction des couts et des delais d’installation. Toutefois, l’industrie restaittenaillee entre la necessite de fabriquer des produits utilisables dans le monde entier. Laseule bande libre mondialement etant la bande du 2,4 GHz et la faible performance relativede ces memes bandes de frequence dans les batiments europeens en beton. De plus, le niveautechnologique des normes les plus acceptees, notamment IEEE 802.15.4-2003, etait devenusignificativement inferieur a celui des solutions proprietaires.L’impulsion donnee 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, representent desprogres tres importants. Les deux technologies, a savoir LORA et SIGFOX, repondent al’evolution de ces normes :

• LORA : La solution permet de creer un veritable reseau personnel a faible consomma-tion, ideal pour la gestion des communications avec les objets connectes. La technologieest donc concue pour repondre aux besoins des reseaux radio longue portee et basseconsommation. LoRa est un protocole de communication qui fonctionne avec les mo-dules fabriquees par Semtech. Cette technologie a ete mise au point par l’entreprisegrenobloise Cycleo (rachete par Semtech en 2012). Son role sera de permettre a tous lespetits objets connectes (capteurs de fumee, temperature, d’humidite, de presence, etc...)de communiquer avec un serveur central, par le biais de relais. Certains operateurs l’ontdeja adopte, comme Fastnet en Afrique du Sud (au total 19 operateurs testeraient latechnologie).En 2015, des leaders de l’industrie de l’Internet des objets ont planifie la creation de�l’Alliance LoRa� afin de standardiser les reseaux etendus pour l’Internet des Objets,offrant une connectivite bidirectionnelle et longue distance, de faible consommationenergetique. La mission de l’Alliance LoRa est de normaliser les reseaux LPWAN (LowPower Wide Area Networks) deployes dans le monde entier. La technologie LoRa est

14


consideree aujourd’hui comme une alternative credible au reseau M2M basse frequences.

• Sigfox : Sigfox est une technologie LPWAN qui utilise la bande 868 MHz en Europeet 902 MHz aux Etats Unis mais aussi un operateur qui utilise sa propre technologie.Avec Sigfox, l’objet peut envoyer entre 0 et 140 messages par jour et le payload dechaque message ne peut pas depasser 12 octets, ce qui est amplement suffisant pourles objets qui transmettent une alarme, une localisation, un etat d’environnement(temperature), une mesure de consommation d’energie... Des objets comme des camerassont des types d’objets qui restent destines aux reseaux larges bandes.Il est aussi possible avec Sigfox de transmettre 4 messages de 8 octets de payload achaque objet par jour. Mais, pour que l’objet recoit le message, il doit demander lesdonnees au serveur, il doit donc etre programme pour recevoir des donnees a des ins-tants definis dans sa logique. Cette demande de communication bidirectionnelle cibleles clients qui souhaitent de temps en temps pousser un parametre de configuration versleurs objets. Cette fonctionnalite est implementee comme un ”polling”, ou l’objet restemaitre et peut demander au systeme d’information s’il y a des donnees a telecharger.Exemple : Un thermostat envoie la temperature 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 temperature. Ce fonctionnement permet d’eviterde rester connecte en permanence et permet donc une communication bidirectionnelleen 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 differents et adressent des usages differents. A l’heure de la multiplication des objetsconnectes, de nouveaux usages et besoins emergent (besoin de transmettre de courts mes-sages, sans consommer beaucoup d’energie...).La 5G, annoncee pour les annees 2020, entend regrouper et integrer toutes les technologiesevoquees pour une utilisation plus efficiente des bandes de frequences disponibles. Chacunplace ses pions, avec Sigfox qui leve 100 millions d’euros pour installer son reseau a l’inter-national, avec Semtech qui annonce son partenariat avec Bouygues pour l’acceleration de lamise en place du reseau LoRa, ou avec Neul (rachete par Huawei) qui a fait en fevrier dernierun partenariat avec Vodafone pour integrer sa technologie dans le reseau de l’operateur afinqu’il adresse les besoins des objets connectes.

4.5 Exemples d’applications

Le domaine de l’Internet des objets est tres vaste et differents types d’objets pourrontdevenir connectes, nous citons quelques exemples d’application ci-dessous :

4.5.1 Ville du futur

L’interconnexion et la communication de tous les vehicules routiers (voitures, bus, camion,bicyclettes...) presents dans un perimetre defini, entre eux et avec une infrastructure permet-tra par exemple d’ajuster dynamiquement le fonctionnement des feux aux carrefours pourfluidifier la circulation, d’afficher des informations en temps reel sur l’etat de la circulationet de renvoyer ces donnees sur les vehicules dans la zone.

15


4.5.2 Domotique

Les applications domotiques existent deja depuis relativement une longue date. Il est pos-sible de programmer le chauffage ou la fermeture/ouverture de volets roulants, y compris adistance via des applications sur smartphone ou tablettes.Avec Internet des objets et une application coordinatrice, ces elements du confort thermiquedomestique pourront ”discuter” entre eux et se coordonner pour trouver la meilleure confi-guration pour un confort thermique optimal et une consommation d’energie minimale. Deplus, cet ajustement est dynamique, ce qui autorise une reconfiguration adaptee durant lesjournees 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, interconnectees entreelles, avec leur extensions (moules, outils...) et avec les pieces ou matieres qu’elles traitentpermettra d’auto-optimiser les operations :

• Auto-configuration des machines en fonction des caracteristiques des pieces et/ou desoutils et matieres.

• Ajustement de l’usinage en fonction des caracteristiques des matieres, de l’usure del’outil.

• Demande automatique de maintenance, emises par les machines, les outils ou les mouleseux-memes, en fonction de parametres predefinis.

4.6 Impacts de l’Internet des objets

Comme tout element de transformation numerique de l’entreprise, l’Internet des Objetsamene un certain nombre d’impacts qui sont a la fois techniques, financiers, RH et juridiques,ainsi que de nouveaux risques associes.

4.6.1 Impacts techniques et alignement du systeme d’information

Afin d’integrer les objets connectes dans la gestion du systeme d’information de l’en-treprise, plusieurs problematiques doivent etre correctement appreciees. D’un point de vuetechnique, l’Internet des Objets est par nature heterogene. Par ailleurs, tous les objets nenecessitent pas d’etre connectes en continu sur le reseau.

Pour implementer l’Internet des Objets, il ne suffit donc pas d’avoir les objets, mais encoreil faut pouvoir les connecter, les capteurs les plus petits ne peuvent pas communiquer di-rectement en 3G ou 4G, et necessiteront donc des passerelles, smartphones ou routeurs. Cesequipements devront alors avoir d’une part les interfaces pour discuter avec les objets (dontles protocoles de communication sont tres heterogenes), et d’autre part une interface reseaupour communiquer avec une plateforme de service qui elle-meme s’interferera avec des SImultiples.

Enfin, il est a noter qu’avec l’augmentation exponentielle du nombre d’objets connectes, ilfaudra etre capable de gerer l’acquisition, le stockage et l’analyse de quantites gigantesquesde donnees. Nous nous rapprochons alors des problematiques de Big Data, qui donneront ases donnees issues de l’Internet des Objets toute leur valeur.

16


4.6.2 Impact financier

Sur le plan financier, l’impact est loin d’etre negligeable. Les opportunites en termes denouveaux modeles d’affaires et d’optimisation des couts sont telles que le retour sur inves-tissement de la mise en place d’objets connectes dans l’entreprise est facilement perceptible.Mais un investissement initial important est a prevoir pour s’equiper non seulement en objetsmais aussi dans les systemes et reseaux qui vont les gerer. Le developpement des modeleseconomiques et l’analyse du retour sur investissement seront alors des etudes a realiser enamont des projets lies a l’Internet des Objets.

4.6.3 Impact RH

L’utilisation des objets connectes va necessairement etre tres impactant sur les ressourceshumaines de l’entreprise, sur plusieurs aspects :

• Amelioration de la securite des utilisateurs.• Optimisation du geste metier.• Creation de nouveaux metiers et competences.

Au niveau des conditions de travail, les objets connectes s’attachent aux employes. Ils peuventainsi permettre de localiser la personne, et de suivre un certain nombre de capteur.Par ailleurs, la precision de certains capteurs peut etre mise au service de la formation dupersonnel. Ainsi, par la captation et l’analyse des donnees remontees par des capteurs portespar l’employe, il est possible de travailler sur l’optimisation du geste metier.Enfin, l’arrivee de nouvelles technologies internalisees entraıne necessairement la creation denouveaux metiers et l’integration de nouvelles competences qui permettront de les gerer. Cesnouveaux metiers concernent notamment la creation et l’implementation des objets et desinterfaces, ainsi que la gestion des donnees. Cela concerne aussi les metiers d’ergonomes quivont pouvoir assister a la creation des objets connectes adaptes aux conditions de travail.

4.7 Evaluation de performances dans l’Internet des objets

Mesurer les performances d’un systeme dans l’Internet des objets pose beaucoup deproblemes, du fait que les objets doivent etre testes dans des conditions reelles d’utilisa-tion. Une autre difficulte est due au fait que les systemes dans l’Internet des objets sont laplupart du temps bases sur des capteurs/actionneurs et requierent une interaction plus oumoins forte avec les operateurs humains. Ils peuvent integrer plusieurs technologies et plu-sieurs disciplines, ce qui complexifie considerablement les processus de tests et d’evaluationdes performances de tests a differents degres de realisme, classees selon leur architecture (2-Tiers ou 3-tiers).En fonction de leurs architectures, les environnements d’evaluation peuvent etre classes endeux categories. Pour les architectures 2-tiers, la limite est leur incapacite a prendre en chargela couche reseau. Les architectures 3-tiers prennent en compte la couche reseau pour facili-ter la communication entre les objets et les serveurs de test, en offrant plus de flexibilite etdes gains en performance. Ces solutions de test peuvent integrer un ou plusieurs systemesd’exploitation utilise generalement dans le domaine de l’embarque.

17


Conclusion

Au cours de ce chapitre, nous avons presente le cadre de notre projet, la structure d’accueilTelecom Bretagne ou j’ai effectue mon stage. Par la suite nous avons presente les principalestaches, nous avons introduit la notion de l’Internet des objets, le domaine en pleine explosionou nous avons parle sur l’histoire, les technologies existantes, les developpements et l’impactde l’Internet des objets sur la vie dans le futur. La partie suivante sera consacre pour l’analyseet la specification des besoins ou nous detaillerons aussi la communication et l’interoperabilitedans notre projet LORA FABIAN.

18

Chapitre II

Specification des besoins et conception


1 Specification 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 Presentation des acteurs . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Description des cas d’utilisation . . . . . . . . . . . . . . . . . . . 22

3 Diagramme de sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Diagramme de sequence fonctionnel . . . . . . . . . . . . . . . . . 25

3.2 Diagramme de sequence applicatif . . . . . . . . . . . . . . . . . . 26

4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 Description des classes . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Interoperabilite dans le reseau LORA FABIAN . . . . . . . . . . . . . . . 31

5.1 Architecture du reseau LORA FABIAN . . . . . . . . . . . . . . . 31

5.2 Elements du reseau . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3 Standards utilises . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.4 Prolongement des web objets vers les capteurs . . . . . . . . . . . 38

5.5 Format des paquets dans le reseau LORA FABIAN . . . . . . . . 42

5.6 Types de trames circulant dans le reseau . . . . . . . . . . . . . . 46

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

19

CHAPITRE II. SPECIFICATION DES BESOINS ET CONCEPTION

Introduction

Dans ce chapitre, nous presentons l’ensemble des fonctionnalites que doit satisfaire le mo-dule a developper, ainsi que les differentes contraintes auxquelles il doit se soumettre. Nousrappelons qu’il s’agit pour notre projet d’aboutir a un module qui permet a l’administrateurde la passerelle d’analyser la performance de son reseau a travers des indicateurs de perfor-mance definis.Ce chapitre represente une vision approximative de la finalite du projet qui consiste a com-prendre le contexte du systeme a realiser en recensant a la fois les besoins fonctionnels etles besoins non fonctionnels, par la suite, nous presentons la conception de notre projet avecles differents diagrammes. Dans la deuxieme partie du chapitre, nous allons detailler l’archi-tecture du reseau LORA FABIAN en mettant l’accent sur les differents standards utilises etl’interoperabilite dans le reseau.

1 Specification des besoins

Dans cette section du chapitre, nous nous interessons aux besoins des utilisateurs traitesdans notre projet.

1.1 Les besoins fonctionnels

Les besoins fonctionnels du projet LORA FABIAN sont divers, le projet vise a permettreaux capteurs de se connecter a Internet a travers la passerelle et la technologie radio longueportee LoRa, les besoins fonctionnels du projet en general sont relatifs aux besoins des clientsou l’operateur qui va deployer l’architecture LORA FABIAN.En outre, nous avons choisi pour le moment d’etudier les besoins fonctionnels de la partiequi va nous permettre de definir les indicateurs de performance du reseau.Les besoins fonctionnels du projet sont :

1.1.1 La collecte des indicateurs de performance du reseau :

Il faut collecter tout les indicateurs de performances possibles qui pourront aider a in-terpreter la performance du reseau LORA FABIAN.

1.1.2 La creation d’une librairie pour la generation du trafic vers la passerelle :

Nous devons generer du trafic vers la passerelle a travers une librairie Python, la librairieva creer des paquets et les envoyer vers la passerelle. Dans ce contexte, il faut generer tousles types des paquets qui pourront circuler dans la realite.

1.1.3 Fournir un moyen pour l’analyse de la performance du reseau a l’admi-nistrateur de la passerelle :

Il s’agit de creer un serveur web sur la passerelle qui va servir comme outil d’analyse dela performance du reseau LoRa.

20


Pour arriver a l’objectif, plusieurs sous-besoins etaient necessaires :

• L’enregistrement des indicateurs dans une base de donnees.

• Les tables de la base de donnees doivent se generer automatiquement.

• L’application doit permettre a l’administrateur de la passerelle de diagnostiquer lesproblemes dans le reseau en temps reel : L’outil de l’analyse de performance doit per-mettre a l’administrateur de superviser la qualite de son reseau a partir des indicateursainsi que les statistiques affichees dans l’outil (des courbes, histogrammes...).

• L’application doit afficher les informations relatifs pour chaque capteur dans le reseau.

• L’application doit permettre de faire des regroupements de chaque capteur dans lereseau par son adresses MAC et le nombre de paquets envoyes dans des tableaux.

• L’application doit permettre de faire des courbes sur le debit de transmission de l’an-tenne LoRa.

• L’application doit permettre de faire des histogrammes sur les tailles des paquets en-voyes pour chaque nœud dans le reseau.

• L’application doit permettre a l’administrateur de faire son choix du tableau de bordpersonnel pour l’analyse du reseau.

• L’application doit permettre de faire des statistiques sur le reseau.

1.2 Les besoins non fonctionnels

Il s’agit des besoins qui caracterisent le systeme. Ces besoins peuvent concerner lescontraintes liees a l’implementation (langage de programmation, de systeme d’exploitation...)ou a l’interoperabilite generale. En effet, ces besoins peuvent etre fixer par le client (fonctionsoptionnelles), ou par le developpeur (contraintes d’implementation).Parmi les besoins non fonctionnels de notre application, nous citons :

1.2.1 La performance :

Le systeme doit etre performant en temps de reponse et en terme de consommation deressources.

1.2.2 Interface de l’affichage des analyses :

L’interface du serveur web qui va permettre l’analyse de la performance du reseau doitetre coherente au point de vue l’ergonomie. La qualite de l’ergonomie sera un facteur essentiel,etant donnee l’utilisation intensive qui sera faite de l’application.

21


1.2.3 Interoperabilite dans le reseau :

Il faut garantir l’interoperabilite entre les reseaux intelligents, la necessite d’assurer unniveau eleve de coherence et de surete. Il faut que la difference de normes n’affectent pasl’architecture generale des reseaux intelligents.

1.2.4 Securite des donnees :

Assurer un niveau eleve de protection des donnees et de la vie privee et d’un bon rapportcout/efficacite.

2 Diagrammes de cas d’utilisation

Un cas d’utilisation represente une exigence fonctionnelle du systeme. Dans notre projet,puisque nous avons deux systemes independants, nous allons presenter le diagramme de casd’utilisation pour chaque systeme.

2.1 Presentation des acteurs

Le systeme est base sur deux acteurs principaux :

2.1.1 L’utilisateur de la librairie

Il s’agit de l’utilisateur de la bibliotheque python qui va lui permettre de generer despaquets 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 reseau personnel que ce soit un utilisa-teur normal ou un operateur 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 donnees recues, elle va fournir unoutil pour l’analyse de performance du reseau.

2.2 Description des cas d’utilisation

2.2.1 Objectif

L’objectif de la realisation de la librairie est de generer differents types de trafic et lesenvoyer vers la passerelle qui va faire du traitement pour definir les indicateurs de performancedu reseau et creer un outil d’analyse pour l’administrateur de la passerelle.

2.2.2 Pre-conditions :

• Les paquets generes dans la librairie doivent respecter la specification LORA MAC.

• La passerelle doit rejeter les paquets qui n’appartiennent pas au reseau LORA.

22


2.2.3 Diagramme de cas d’utilisation pour l’administrateur

Le diagramme presente dans la figure 2.1 contient les differents cas d’utilisations quel’administrateur peut effectuer lors de sa connexion sur son tableau de bord :

Figure 2.1 – Diagramme de cas d’utilisation pour l’administrateur

23


• Le cas d’utilisation : Configurer le systeme Pour fournir un outil efficace et performantd’analyse de performance du reseau, nous devons prendre en compte la configurationdu systeme, en effet, chaque administrateur a un choix different d’un autre administra-teur en terme d’interface d’accueil, ainsi, nous donnons le choix a l’administrateur dechoisir son tableau de bord personnel, les graphes qu’il prefere trouver dans l’interfaced’accueil a chaque connexion. Egalement, le systeme doit offrir la possibilite d’importerson fichier de log qui contient les indicateurs de performance exportes avant la derniereutilisation. Le systeme offre aussi la possibilite de configurer la periode de mise a jour del’affichage des logs, par exemple afficher les logs des dernieres 5 minutes ou du dernierjour etc. . .

• Le cas d’utilisation : Consulter les indicateurs de performance du reseau L’administrateurpeut consulter les donnees enregistres dans la base de donnees, les indicateurs de perfor-mance du reseau de la periode choisie, pour faire ca, il doit saisir le critere de recherchepar exemple, le nom de l’indicateur ou il envoie une requete d’affichage de tous lesindicateurs qui depassent une certaine valeur, il peut aussi selectionner un critere derecherche parmi plusieurs suggeres dans le serveur.

• Le cas d’utilisation : Generer des graphes L’administrateur a la possibilite de genererdes graphes (des courbes, des histogrammes, des tableaux) par exemple des courbesde debit en fonction du temps, la puissance de reception de l’antenne en fonction dutemps ou des tableaux qui contiennent la liste des capteurs avec le nombre des paquetsenvoyes. Nous laisse le choix a l’administrateur de choisir la forme du graphe ainsi queles criteres qu’il veut evaluer.

• Le cas d’utilisation : consulter la liste des capteurs dans le reseau La passerelle developpeedonne acces internet aux differents capteurs dans le meme reseau, l’administrateur dela passerelle doit avoir la possibilite de consulter l’ensemble des capteurs connectes a lapasserelle et afficher les informations relatives a chaque nœud dans le reseau. Ainsi, ilpeut afficher la taille des paquets envoyes, le nombre des paquets envoyes pour chaquecapteur, la modulation, la frequence...

• Le cas d’utilisation : Consulter les informations relatives a la station LoRa L’administrateurpeut avoir des informations sur les differents nœuds du reseau en particulier l’antenneLoRa connectee directement a la passerelle, il peut afficher le debit au niveau de lapasserelle dans un temps donne, le facteur signal sur bruit, la puissance de reception,le facteur d’etalement...

24


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 : Generer du trafic selon le protocole LORA Le premier cas d’uti-lisation de la librairie est de generer des paquets selon le protocole LORA en utilisantle protocole REST CoAP, ou nous fournissons aux utilisateurs de la technologie LORAun moyen pour creer des paquets sans utiliser l’antenne LoRa.

• Le cas d’utilisation : Envoyer les trames vers la passerelle Pour completer le premier casd’utilisation et selon le besoin de notre projet, notre librairie fournit egalement la pos-sibilite d’envoyer les paquets generes vers notre passerelle en specifiant l’adresse MACde la Gateway.

3 Diagramme de sequence

Les diagrammes de sequences suivants montreront une vue dynamique sur l’interactionde l’utilisateur avec le systeme. Nous avons choisi de presenter au debut le diagramme desequence fonctionnel du projet, et par la suite detailler ce diagramme a partir d’un diagrammede sequence applicatif.

3.1 Diagramme de sequence fonctionnel

Dans notre systeme, nous avons deux acteurs principaux, la librairie qui genere du traficvers le deuxieme acteur la passerelle. La figure 2.3 montre l’enchainement de principalesactions entre les deux acteurs.La librairie commence par la generation des paquets selon le protocole LORA en suivant laspecification LORA MAC, apres, elle envoie les trames vers la passerelle qui est en ecoute,elle extrait les indicateurs de performances du reseau et elle les envoie vers l’outil d’analysede performance sur la passerelle.

25


Figure 2.3 – Diagramme de sequence fonctionnel

3.2 Diagramme de sequence applicatif

Pour mieux expliquer la sequence d’evenements du systeme, nous allons detailler le dia-gramme de sequence en prenant en consideration tous les interactions entre les intervenants.La figure 2.4 presente le diagramme de sequence applicatif du systeme.Au debut, la librairie commence par generer des paquets selon la technologie radio longueportee LORA, elle envoie par la suite les paquets vers la passerelle qui est en etat d’ecoute.A la reception des paquets, un serveur integre dans la passerelle verifie si les paquets appar-tiennent au reseau LORA ou non, si ce n’est pas le cas, elle rejette les donnees, sinon, ellerepond par un ACK vers la librairie et par la suite elle fait une serie d’actions : Premierement,elle commence par l’extraction des indicateurs de performance depuis les donnees recues, l’en-registrement des KPIs (Key Performance Indicators) dans la base de donnees et apres elleenvoie les donnees enregistrees vers la pile ELK, plus particulierement, le serveur Logstash,il collecte, filtre et envoie les donnees vers le serveur Elasticsearch qui indexe les donneessous format JSON dans une base de donnees NoSQL, pour que l’administrateur puisse fairedes requetes a partir du serveur web Kibana qui accede aux donnees enregistrees dans Elas-ticsearch, il permet de faire des graphes et des statistiques sur les donnees dans la base dedonnees NoSQL.

26


Figure 2.4 – Diagramme de sequence applicatif

27


4 Diagramme de classe

Le diagramme de classes de la figure 2.5 fournit une description bien detaillee des differentesclasses de l’application ainsi que les differentes associations qui les relient.

Figure 2.5 – Diagramme de classe

Le diagramme de classe precedant represente les differents classes et interfaces implementeesau niveau de la passerelle lors du stage. Nous commencons par la reception des paquets dulien radio, l’extraction des indicateurs de performance, leur enregistrement, pour enfin fairela preparation a l’analyse de la performance du reseau a partir des informations enregistreesdans la base de donnees.

28


4.1 Description des classes

Le diagramme de classe represente dans la figure 234 correspond au travail au niveau dela passerelle, l’ensemble des classes implementees au niveau de la passerelle.

4.1.1 Un tunnel :

Sur lequel il y a la reception des donnees envoyees par l’antenne LORA sur le lien radio.Les donnees sont recues sous format ”NodeRpipePacket” et puis ils seront transformes en”RawData” pour des traitements dans les couches applicatifs.

• Au niveau du tunnel, nous avons implemente les classes ”UpstreamTunnel” et ”Downs-treamTunnel” qui heritent de la classe ”AbstractTunnel” et qui assurent successivementl’envoi des reponses ou des requetes vers la station LORA et la reception des paquetssur le lien radio. Il s’agit d’un ensemble de threads qui effectuent la verifications del’appartenance des paquets recus selon la version du protocole utilise, la constructionde l’objet ”NodeRpipePacket” qui sera par la suite utile pour extraire les parametresdu reseau et les caracteristiques des capteurs et de l’antenne LORA.

• Sur le lien Uplink, la classe ”UpstreamTunnel” se charge de recevoir les ”PullAckPa-ckets” envoyes 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 donnees.

4.1.2 La couche MAC 802.15.4 :

Dans cette partie de code, nous extrayons les informations relatives a la couche 802.15.4comme 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 donnees a partir de l’objet ”NodeRpi-pePacket” et affecter ces donnees aux objets capteurs et stations LORA pour separerle traitement dans les couches superieures. Ainsi, nous trouvons le prelevement du pay-load du paquet, la separation de chaque champ a partir de son nombre de bytes detailledans la specification 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 partla generation des statistiques sur le trafic a chaque reception des donnees ainsi que lesindicateurs de performance du reseau, d’une autre part, elle fait la conversion entre lesdeux types de paquets (”NodeRpipePacket” et ”RawData”), RawData pour les couchessuperieures et ”NodeRpipePacket” pour les couches basses, la classe ”PacketFormat-Converter instance par la suite les classes ”GeneralStats” et ”KPI”.

29


4.1.3 Une couche applicative :

Dans laquelle il y a la definition des indicateurs de performance a partir des attributs del’objet ”NodeRpipePacket” et les statistiques sur les donnees recues, par la suite nous en-voyons par UDP les donnees vers les serveurs qui se chargent de fournir les outils necessairespour l’analyse de performance.

• La classe ”NodeRpipePacket” definit les champs des paquets en provenance du lien ra-dio (bytes, adresse, port, informations sur le capteur, nature du message (signalisationou donnee)...).

• Les paquets PushAck sont les acquittements envoyes par la passerelle, donc ils sontcrees au niveau de la passerelle.

• Les paquets PullAck sont les acquittements recus par la passerelle, donc il s’agit desacquittement envoyes par la station LORA.

• Les paquets PullResp sont les trames de donnees envoyees par l’antenne LORA.

• La classe ”KPI” contient les indicateurs de performance specifique au reseau LORA.

• La classe ”GeneralStats” contient des statistiques sur le reseau en fonction des capteursdans le reseau.

30


5 Interoperabilite dans le reseau LORA FABIAN

Le domaine de l’Internet des objets est tres vaste par les fonctionnalites fournies et lavaleur ajoutee dans les differentes pistes. Theoriquement, l’idee est claire et les besoins sontdynamiques, mais en pratique, il faut utiliser des nouveaux standards et protocoles. Danscette partie, nous allons evoquer de l’interoperabilite dans le reseau LORA FABIAN a traversla communication des differents couches protocolaires.

5.1 Architecture du reseau LORA FABIAN

L’architecture du reseau LORA FABIAN [14] est basee sur quatre nœuds (Node-F, Node-R, Node-G, Node-S) et differentes interfaces. Les nœuds sont les elements de base du reseau,ils interagissent ensemble pour repondre aux besoins des clients et assurer l’interconnexiondes objets connectes entre eux a travers une communication bidirectionnelle garantie par lastation LoRa (Long Range) qui represente la Node-R dans le schema.

Figure 2.6 – Architecture generale du reseau LORA FABIAN

Les objets connectes (Nodes-F) sont identifies par leur adresse MAC au niveau de la passe-relle (Node-G), celle-ci, va garantir aux objets connectes la communication entre les objetsconnectes et l’acces a Internet.

Pour repondre ou envoyer une requete les Nodes-F envoient leurs reponses vers les Nodes-G,la requete passe par le lien radio (la station LoRa) qui redirige tout simplement les paquetsvers la passerelle la plus proche qui, apres reception, traite la requete soit par la redirigervers un autre objet connecte, soit vers une autre passerelle, soit vers un serveur web par untunnel securise. La communication est basee sur deux plans, le plan de signalisation et leplan de donnees.age

31


5.2 Elements du reseau

La figure 2.7 montre les differents participants dans le projet LORA FABIAN, Wi6Labsavec ses capteurs arduino qui sont equipes par des modules LoRa, Kerlink qui fournit lesantennes LoRa (les Nodes-R), il y a l’Afnic qui participe par le developpement des servicesDNS et enfin Telecom Bretagne qui fait le developpement du logiciel qui fait la gestion dureseau et met en place l’architecture LORA FABIAN sur la Node-G.

Figure 2.7 – Differents participants dans le projet

5.2.1 Node-F

Il s’agit des objets connectes qui sont generalement des capteurs integres dans des objetset distribues sur l’ensemble de couverture du reseau LoRa. Leur role est principalement cap-ter des informations a partir des objets et les transmettre a d’autres objets ou vers Internet.Generalement, le capteur est en limitation d’energie et en puissance de traitement.

Ces objets peuvent se comporter comme des passerelles pour donner l’acces a d’autres objetsvia differentes technologies d’acces comme par Bluetooth/IEEE 802.15.4, ZigBee/802.15.4...Un module LoRa est ajoute aux microcontrolleurs concernes pour acceder a la technologieLoRa et une bibliotheque open source fournie pour le developpement des programmes selonle besoin de l’utilisateur.

32


Figure 2.8 – Capteur Node-F

Mise au point par la societe Semtech, la technologie LoRa est caracterisee par une excellentesensibilite en reception. Cette technologie permet d’envisager des transmissions radio d’uneportee d’une quinzaine de kilometres et une autonomie de plus de dix ans pour certains typesd’objets connectes. Le premier module LoRa de Microchip, qui est aussi membre fondateurde ”LoRa Alliance” tout recemment creee, exploite les bandes de frequence europeennes 433MHz et 868 MHz. Il combine a la fois des dimensions compactes (17,8 x 26,3 x 3 mm) et 14interfaces d’entrees/sorties GPIO, caracteristiques qui offrent la flexibilite de connecter et decommander un grand nombre de capteurs et d’actuateurs dans un encombrement reduit.

Figure 2.9 – Module LoRa

5.2.2 Node-R

Figure 2.10 – Antenne LoRa

33


La station LoRa (Long Range) est une borne qui s’adresse aux operateurs de service deconnectivite M2M et Internet des objets voulant operer leur reseau en propre.La borne integre la technologie Long Range developpee par Kerlink, ainsi que de la connecti-vite 3G et Ethernet. Grace a un boitier IP67, la station LoRa peut resister a des conditionsd’installations severes (humidite, poussiere, vent...). Elle peut etablir des communicationsbidirectionnelles avec plusieurs milliers d’equipements intelligents (capteurs, compteurs ouobjets connectes) distants de plusieurs kilometres.Les objets connectes peuvent s’appuyer sur les reseaux cellulaires couverts par les operateursde telephonie (2G, 3G, 4G, LTE) pour transmettre leurs donnees mais ils sont concus pourde tres haut debit et consomment en contrepartie beaucoup d’energie.C’est pour ca, nous nous appuyons sur la technologie LoRa basee sur des reseaux longueportee, qui a la particularite de se baser sur une transmission basse frequence, basse consom-mation d’energie mais bas debit.

LoRa comble un vide entre les technologies radio a courte portee (WiFi, Bluetooth, ZigBee..)et celles de reseaux mobiles, a plus longue portee. Fonctionnant avec un debit adaptatifde 0.3 a 50 Kbit/s, elle allie faible consommation d’energie (jusqu’a dix ans d’autonomiepour les produits a batterie) et longue portee (jusqu’a 15 km en champ libre), LoRa disposed’autres atouts : bonne faculte de penetration dans les batiments ou en sous-sol, communica-tion bidirectionnelle et securisee, objets en mobilite, geolocalisation. LoRa fonctionne sur desfrequences entre 863 et 870 MHz. Cette technologie est tres peu gourmande en energie. Les ap-plications d’un tel reseau peuvent concerner les donnees des compteurs d’eau et d’electricite,la gestion de l’eclairage public ou de l’affichage intelligent, la maintenance predictive sur di-vers appareils, des services de localisation, etc...

L’utilisation de la technologie d’etalement du spectre permet la communication avec desdifferents debits sans interference. De cette facon, un ensemble de canaux virtuels est creepour augmenter la capacite de la passerelle.Nous citons ci-dessous les caracteristiques du module LoRa :

• Emetteur/Recepteur LoRa, sensibilite -138 dBm : Transmission longue distance, permet-tant de recevoir les donnees dans toutes les conditions. Un degre eleve de sensibilite estideal pour les deploiements Smart City.

• Technologie radio sans fil embarquee dans le capteur : Une radio integree permet unereponse plus rapide, ideale pour les communications point a point, reduisant ainsi lescouts 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 materielles configurables facilementet gerables via une interface web.

• Bibliotheque de chiffrement disponibles : Les communications sont cryptees entre lesperipheriques. L’authentification est securisee, l’integrite des donnees est maintenueet les informations restent confidentielles.

34


• Deux radios deployables dans chaque dispositif. Les capteurs Libelium peuvent etre utilisesavec un second module radio, tel que la 3G, et peuvent travailler en simultanes.

5.2.3 Node-S

C’est un serveur proxy qui servirait d’intermediaire entre la passerelle et l’Internet. Lapasserelle est connectee au serveur proxy.L’utilisation d’un serveur proxy nous donne la possibilite d’utiliser le cache, la securite, le surfanonyme ainsi que le filtrage, c’est a dire, comme toute les requetes et les reponses passentpar 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 precisement le software developpe pour donner l’acces a In-ternet aux objets connectes. Le trafic recu et envoye par les Nodes-F passe toujours par laNode-G via un tunnel JSON en passant par la station LoRa. La passerelle ecoute sur le port1790 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 ete a l’origine developpee pour assurer l’integration des capteurs sans fildeployes avec des applications Web. Des scenarios de test sont realises dans notre plateformed’experimentation pour valider l’architecture de la passerelle.

Parmi les fonctionnalites de la passerelle, nous pouvons citer :• Ajout/Suppression du MAC Header de la trame.

• Localiser les nœuds dans la region couverte par le reseau LoRa.

• Adapter une vitesse de transmission pour le lien radio.

• Donner des priorites aux transmissions pour optimiser l’occupation du canal.

• Maintenir un plan de signalisation pour enregistrer les Nodes-F, negocier les cles dechiffrement, les adresses MAC.

5.3 Standards utilises

Lors du projet LORA FABIAN, nous avons utilise de nouveaux protocoles et standardsInternet.

5.3.1 CoAP (Constrained Application Protocol)

Les reseaux de capteurs sont des composants qui possedent des ressources contraintes.Ils disposent notamment d’une capacite memoire, d’une puissance, d’une bande passante etd’une reserve energetique tres limitee. Ces nœuds contraints ont besoin d’un protocole a lafois complet et leger pour communiquer. Le nouveau standard Internet Engineer Task ForceIETF Constrainted Application Protocol CoAP [15] a pour objectif d’etendre l’architectureweb aux applications Machine to Machine M2M utilisant des systemes contraints, il s’agitd’un protocole de communication generique optimise pour les architectures contraintes. Ce

35


protocole peut etre defini comme un sous-ensemble de HTTP dont le cout d’utilisation a etereduit.

Les principales caracteristiques du protocole CoAP sont les suivants :• Gestion des methodes : CoAP met a disposition les requetes GET, PUT, POST et

DELETE. Ces methodes vont pouvoir etre utilisees par le client pour acceder auxdonnees.Leur utilisation est similaire a celle de HTTP.

• Une entete concise : L’entete CoAP a ete concu pour etre facile a analyser par desprogrammes tournant sur des petits equipements comme les capteurs. Au lieu du textelisible de HTTP, l’entete de CoAP commence par une partie fixe de quatre octets.

• Les URIs (Uniform Ressource Identifier) : Le protocole supporte les URIs ce quiva permettre de specifier la cible grace a un nom d’hote, un port, un chemin et unparametre de requete.Comme par exemple, la requete coap ://monserveurcoap/.well-known/core ?n=Light qui est une reponse a la demande de l’etat de ressource n.

• Le type de contenu : Le protocole permet de transporter des donnees d’usages differentsen mettant dans l’entete le type de donnees de la charge utile.

• La decouverte de ressources : La decouverte de ressources est un besoin cle dansune architecture web et notamment pour les applications M2M. En effet, cette re-cherche doit etre autonome et ne doit pas avoir besoin d’une interaction humaine.Les serveurs CoAP doivent pouvoir fournir une URI afin que le serveur puisse etredecouvert.La decouverte de ressources pour CoAP consiste a une reponse a la requetecoap ://monserveurcoap/.well-known/core.

5.3.2 UDP

Le protocole UDP permet aux applications d’acceder directement a un service de transmis-sion de datagrammes. En effet, les applications satisfaisant a un modele du type ”interrogation-reponse” peuvent utiliser UDP, plus particulierement dans le contexte de l’Internet des objetsou les chercheurs cherchent a diminuer la consommation de ressources et eviter les protocolesqui envoient beaucoup de messages, dans ce cadre nous avons choisi d’utiliser UDP au lieude TCP pour gagner en terme de vitesse de transmission et eviter les messages de synchro-nisation.Pour les sequencement des messages, il sera assure par le protocole LoRa et par consequentnous gagnons en terme de taille de paquet et de temps de reponse. La reponse peut etreutilisee comme etant un accuse de reception positif a l’interrogation, si une reponse n’estpas recue dans un certain intervalle de temps, l’application envoie simplement une autreinterrogation.

5.3.3 IEEE 802.15.4

Le 802.15.4 est un protocole de communication defini par l’IEEE. Dans notre architecture,il est utilise par les capteurs (Nodes-F) et la station LoRa (Node-R) pour collecter les donnees.

36


Il est destine aux reseaux sans fil de la famille des LPWAN (Low Rate Wireless Personal AreaNetwork) du fait de leur faible consommation, de leur faible portee et du faible debit desdispositifs utilisant ce protocole.Le standard 802.15.4 fonctionne au niveau des couches physiques et liaison de donnees.

• La couche physique : La couche physique (PHY) contient l’emetteur/recepteur radio(RF), avec un mecanisme de controle de bas niveau (controle de la qualite du signal,detection d’energie). Les frequences basses permettent d’avoir une plus grande porteegrace a une plus faible perte de propagation. Les plus grandes provoquent des sortiesplus elevees, une plus faible latence et des cycles de travail plus courts.

• La couche de controle d’acces au support : Le standard 802.15.4 fait la distinction entrela partie de la couche MAC responsable du transfert des donnees, la sous-couche MACcommune MCPS (MAC Common Part Sublayer) et la partie responsable de la gestionde la couche MAC est MLME (MAC Layer Management Entity). La MLME comprendles parametres de configuration et d’etat de la couche MAC, comme l’adresse IEEEsur 64 bits et l’adresse courte du nœud sur 16 bits, le nombre de tentatives d’accesau reseau en cas de collision (en general quatre, mais cinq au maximum), la dureed’attente d’un accuse de reception (en general 54 unites de duree d’un symbole, mais120 au maximum) ou le nombre de renvois d’un paquet reste sans accuse de reception(0–7). Concernant l’association des nœud, pour rejoindre un reseau, un nœud envoieune requete d’association a l’adresse du coordinateur. Cette requete precise le PAN IDque le nœud souhaite rejoindre, ainsi qu’un ensemble d’indicateurs de capacites codessur un octet.

• Avantages IEEE 802.15.4 : Le standard 802.15.4 a ete ratifie par l’IEEE. Elle nenecessite pas de licence specifique. L’avantage majeur du standard 802.15.4 est quela technologie est peu consommatrice en energie. Elle peut, de plus, etre integree a bascout dans les equipements.

Figure 2.11 – Avantage du protocole 802.15.4

37


La difference [16] entre 802.15.4 et la plupart des autres reseaux locaux et person-nels sans fil (WiFi, Bluetooth) se situe au niveau de l’utilisation du medium hertzien ;802.15.4 est optimise pour une faible utilisation du medium partage par tous, parexemple 0,1% du temps. Typiquement, un module 802.15.4 occupera le medium pen-dant quelques millisecondes en emission, attendra eventuellement une reponse ou unacquittement, puis se mettra en veille pendant une longue periode avant l’emissionsuivante, qui aura lieu a un instant predetermine.

5.3.4 La bande ISM (Industrial, Scientific and Medical) 868 MHz

Les bandes ISM sont des bandes de frequences qui peuvent etre utilisees, pour des ap-plications industrielles, scientifiques, medicales, domestiques ou similaire, a l’exception desapplications de radiocommunication, sans demande d’autorisation aupres des autorites.

Depuis 2006, l’ARCEP (Autorite de Regulation des Communications Electroniques et desPostes) autorise l’utilisation en France de la bande 865-868 MHZ. Cette bande encore peuemployee offre certains avantages, en particulier la possibilite d’utiliser une puissance de 500mW au lieu de 10 mW en 433 MHz. La taille de l’antenne en 868 MHz est 2 fois plus pe-tite pour la meme efficacite. Enfin, la bande 868 MHz est partagee uniquement entre desutilisateurs dont les puissances d’emission et les taux d’utilisation sont a priori homogenes,reduisant ainsi les risques de brouillage.

Parmi les avantages de la bande ISM 868 MHz, nous pouvons citer :• Possibilite de changer de canal si brouillage.

• Temps de cycle en transmission non denombrable.

• 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 reseau d’objets web relies d’une maniere asymetriquevia des applications ou des plateformes. Si votre capteur est connecte a une plateforme, illui envoie des donnees, mais n’en recoit quasiment pas d’elle (hormis peut-etre des mises ajour).Alors que dans le reseau LORA FABIAN desormais nous pouvons communiquer avec lesobjets connectes. Nous sommes passes d”un modele d’interconnexion directe des objets entreeux, de reseaux ad hoc d’objets a un modele ou chaque objet est relie a une plateforme web,qui gere ensuite, a son gre les interactions entre les objets. Cela permet certes d’acceder ades plateformes logicielles et materielles suffisamment souples et ouvertes pour contournerles problemes de normes et de standards dans lesquels s’empetrent tous les projets d’inter-connexion des objets.

38


5.4.1 Architecture REST(Representational state transfer)

Figure 2.12 – Pile protocolaire du capteur vers la passerelle

REST est un style d’architecture qui repose sur le protocole HTTP : Nous accedons aune ressource par son URI unique pour proceder a diverses operations.

Nous citons les 5 regles a suivre pour implementer REST :• L’URI comme identifiant des ressources : REST se base sur les URIs afin d’identifier

une ressource.

• Les verbes HTTP/COAP comme identifiant des operations : La seconde regle d’unearchitecture REST est d’utiliser les verbes HTTP/COAP existants plutot que d’inclurel’operation dans l’URI de la ressource. GET (afficher), POST (creer), PUT (mettre ajour), DELETE (supprimer).

• Les reponses HTTP/COAP comme representation des ressources : Il est importantd’avoir a l’esprit que la reponse envoyee n’est pas une ressource, c’est la representationd’une ressource. Ainsi, une ressource peut avoir plusieurs representations dans des for-mats divers : HTML (Hypertext Markup Language), XML (Extensible Markup Lan-guage), CSV (Comma-separated values), JSON (JavaScript Object Notation), etc...

• Les liens comme relation entre ressources : Les liens d’une ressource vers une autre onttous une chose en commun : ils indiquent la presence d’une relation. Il est cependantpossible de la decrire afin d’ameliorer la comprehension du systeme.

• Un parametre comme jeton d’authentification : Chaque requete est envoyee avec unjeton (token) passe en parametre de la requete. Ce jeton temporaire est obtenu en en-voyant une premiere requete d’authentification puis en le combinant avec nos requetes.

39


5.4.2 Les interfaces de communication entre les differents nœuds

Figure 2.13 – Liens entre les nœuds dans le reseau

Sur le premier lien, la Node-F et la Node-R (la radio longue portee LoRa) en question,nous utilisons un tramage standard qui est de l’IEEE 802.15.4. Ensuite, entre le lien radio etla Node-G et selon la specification de l’antenne radio, nous avons un tunnel JSON sur UDP.Dans ce lien, nous avons les donnees brutes pour chaque paquet que nous recevons et quenous envoyons, des informations sur le reseau, la frequence, le facteur d’etalement..

Au niveau de la gateway (Node-G), nous avons une maitrise totale de ces donnees et leurenregistrement dans une base de donnees. Entre la Node-G et la Node-S, nous avons untunnel HTTPS pour envoyer ou recevoir les donnees de/vers l’Internet en passant par leproxy.

5.4.3 Exemple de communication CoAP et HTTP dans LORA FABIAN

Figure 2.14 – Communication CoAP et HTTP dans LORA FABIAN

40


Les donnees sont chiffrees de bout en bout, il existe un canal entre la Node-F et la Node-S,quand il y a des donnees qui arrivent de l’Internet, par exemple GET /temp (une requeteHTTP de l’Internet ou temp est le nom DNS de la ressource dans l’objet), la Node-S vatraduire cette requete HTTP en une requete CoAP qui va etre envoyee vers la Node-F. Doncla requete Get va recuperer la ressource du Node-F, la Node-S va recevoir la reponse qui estpar exemple 25 C par CoAP, elle va traduire la reponse en HTTP et la renvoyer vers Internet.Nous avons deux systemes qui communiquent ensemble CoAP et HTTP, HTTP dans le mondede l’Internet et CoAP a l’interieur du reseau, dans les deux cas REST garde le principe dumessage.

5.4.4 La gestion des ressources dans le reseau LORA FABIAN

• Le nommage :

Figure 2.15 – Nommage des ressources

L’Internet des objets vise a connecter des objets entre eux via les protocoles d’Internet.L’objet represente ici tout ce qui nous entoure (machines, telephones mobiles, ordina-teurs, capteurs). Pour atteindre cet objectif, il est imperatif de pouvoir identifier lesobjets et les enregistrer.Concernant le nommage des objets, nous cherchons enormement a optimiser. Nous met-tons en place un reseau qui est compatible avec la technologie Internet. Dans la partieradio, nous utilisons l’adresse MAC et dans la partie Node-G Internet nous utilisons lenom DNS.

Les Nodes-F envoient leur noms DNS en utilisant l’URI, a partir de ce nom, la Node-G localise le serveur d’authentification Diameter en utilisant les requetes DNS. Pourl’enregistrement avec l’adresse MAC, le nœud repond au Node-G selectionne par unerequete POST. A partir de l’adresse MAC, la Node-G commence une resolution inversepar DNS pour trouver le nom DNS.

41


• La signalisation :

Figure 2.16 – Signalisation dans le reseau

Les mecanismes de signalisation dans le reseau LORA FABIAN est base sur les res-sources. Les ressources sont utilises pour enregistrer les adresses, les parametres radiopar exemple (le spreading factor). Puisque la ressource est un objet, ceci permet ungrand decouplage entre la couche signalisation et la couche physique. La couche signa-lisation traite les ressources ce qui est une representation abstraite du lien radio.

Le principal inconvenient est la taille des ressources. Les URIs augmentent leur tailled’une maniere hierarchique, ceci est incompatible avec l’insuffisance des ressources ra-dio. Les noms dans le lien radio sont designes pour etre le plus court possible pour limi-ter l’utilisation du lien radio. Un autre avantage est de permettre des representationsdifferentes dans les deux terminaux.

Pour illustrer la communication entre la Node-F et la Node-G (le capteur et la gateway),quand un capteur va decouvrir le reseau et pour notifier de son existence, le reseau vaauthentifier l’objet et va lui configurer les parametres radio en utilisant le protocoleCoAP. Nous avons des messages qui sont envoyes de la Node-G vers la Node-F quiva lui creer des ressources et puis la Node-F va egalement repondre et va creer desressources sur la gateway.

5.5 Format des paquets dans le reseau LORA FABIAN

Au cours du projet, il a fallu etudier le format des paquets pour savoir leur contenu et lesdifferents champs de la trame. Dans cette partie du rapport, nous allons presenter en premierlieu le format d’une trame MAC en general et puis nous allons se concentrer sur la trameLoRa MAC qui herite du format 802.15.4e et par la suite nous allons donner des exemplesde trames circulant dans le reseau.

42


5.5.1 Format de la trame Mac en general

La specification de la trame LoRa MAC est basee et compatible avec le format de la trameIEEE 802.15.4e-2012. Autrement, un appareil compatible avec la trame 802.15.4e-2012 peutproprement interpreter les donnees circulant dans le reseau LORA FABIAN.

La figure 2.17 presente le format general de la trame 802.15.4e [17] :

Figure 2.17 – Trame MAC generale

5.5.2 Format de la trame LoRa MAC

La trame LoRa MAC [14] derive de la trame 802.15.4e, son format est presente dans lafigure 2.18 :

Figure 2.18 – Trame LoRa MAC

Ce format est un sous ensemble de la trame MAC 802.15.4e. Le CRC (Cyclic RedundancyCheck) n’est pas presente puisque le but est l’interoperabilite avec d’autres reseaux.

5.5.3 Adresses

Comme indique, les adresses sont derivees des specifications IEEE EUI 64 et IEEE EUI16. La Node-G peut reserver une adresse unique EUI-16 pour chaque zone.La Node-G a une adresse EUI-16 avec un format specifique comme le montre la figure 2.19 :

43


Figure 2.19 – Format d’adresse de la passerelle

• Le bit F/G : Il indique s’il s’agit d’une adresse de la Node-F ou de la Node-G. Dansle premier cas, il prend la valeur 0, dans le second cas il prend 1. Les 7 bits qui suiventsont reserves et fixes a 0.

• Le bit ”sig” : Il est fixe a 1 pour le trafic specifique au plan signalisation et a 0 pourle trafic specifique au plan de donnee.

• Area id : Il represente la zone couverte par la Node-G, cette zone est composee parplusieurs stations LoRa. ”Area id” aide pour detecter la mobilite, les zones couvertesne peuvent pas se chevaucher mais l’unicite n’est pas garantie.

5.5.4 Format du champ Frame Control

Le champ ”frame control” contient des informations [14] definissant le type de la trame,des champs d’adressage et d’autres champs. Le champ ”Frame control” doit etre definitcomme illustre dans la figure 2.20 :

Figure 2.20 – Champ de controle

• Le champ ”Frame type” est fixe a 001, seulement la trame ”data” sera envoye.

• Le bit ”Security Enabled” est fixe a 0. Ce champ doit prendre la valeur 1 si la trameest protegee par la sous-couche MAC.

• Les bits ”Frame Pending” et ”Acknowledgment Request” sont fixes a 0. Nous neprevoyons pas des acquittements.

• Le bit ”PAN ID Compression Field” est fixe a 1. Ce champ indique si la trame seraenvoye sans ou avec le champ ”PAN identifier”. Dans notre cas, la trame LoRa MAC,nous n’envoyons pas le champ ”PAN ID”.

• Le champ ”Sequence number” indique l’identifiant de la sequence dans la trame. Pour

44


une trame de donnee, le champ ”sequence number” peut specifier le ”Datagram se-quence number” qui est utilise pour associer un acquittement a la trame de donnee.

• Pour le bit ”IE list present” est fixe a 0, IE list n’est pas utilise.

• Les nœuds peuvent etre identifie soit par IEEE EUI 64 soit par IEEE EUI 16. Le broad-cast se fait quand il n y a pas de destination.

• Le champ ”Frame Version” prend la valeur 00 ou 01 pour indiquer que la trame estcompatible avec IEEE 802.15.4 (e-2012).

Dans la partie qui suive, nous allons presenter les champs ”Frame Control” de chaquetype de trame circulant dans le reseau LORA FABIAN :

• Frame Control pour les trames beacon :Les Beacons Frame sont des paquets de gestion reseau envoye par la passerelle enBroadcast a intervalles reguliers. Ces beacons indiquent la presence de la passerelledans le reseau. La trame ”beacon” est une trame de donnee sans le champ ”sequencenumber” ou ”destination address” envoye par la Node-G.Le champ ”frame control” dans la trame beacon est comme suit :

Figure 2.21 – Frame Control pour les trames beacon

• Frame Control pour les trames emises par les Nodes-G :Les Nodes-F utilisent les adresses EUI-64, le format du champ ”Frame Control” destrames emises par les Nodes-G est comme suit :

Figure 2.22 – Frame Control pour les trames emises par la Node-G

-Le champ ”Source Addressing Field” prend la valeur 10 car il s’agit d’une adresse dela Node-G qui utilise l’adressage IEEE EUI-16.-Le champ ”Dest.Addressing Field” prend la valeur 11 puisqu’il s’agit de destinationqui utilise la specification IEEE EUI-64.

• Frame control des trames envoyees au Node-G :Les Nodes-F utilisent des adresses EUI-64, donc reciproquement a l’exemple precedant

45


le champ ”Destination Addressing Field” prend la valeur 01 pour indiquer que la des-tination est la Node-G, et puisque les Nodes-F utilisent des adresses EUI-64, le champ”Source Addressing Field” prend la valeur 11.Le format du champ ”frame control” des trames envoyees au Node-G est comme suit :

Figure 2.23 – Frame Control pour les trames recues par la Node-G

5.6 Types de trames circulant dans le reseau

Dans cette partie, nous allons presenter les differents types de trames circulant dans lereseau LoRa, les trames balises de synchronisation ainsi que les trames de donnees. Pourspecifier les adresses dans le projet LORA FABIAN que ce soit pour les capteurs (Nodes-F) ou la passerelle (Node-G), nous aurons recours a la paragraphe adresses ou nous avonsexplique la maniere avec laquelle les adresses sont donnees.

5.6.1 Trame balise du Node-G vers les autres nœuds

L’adresse de la passerelle est sur 16 bits (IEEE EUI-16), le bit Node-F/Node-G prend 1s’il s’agit de l’adresse de la passerelle, sinon pour les Nodes-F il prend 0 :

• Adresse source (Gateway) :-Bit Node-F/Node-G + 7 bits reserves : 1 0000000 = 0x80-Bit de signalisation + 7 bits de la zone : 0 0000001 = 0x01

• Adresse de destination (Broadcast) : Rien

Un apercu sur toute la trame LoRa MAC :

Figure 2.24 – Trame balise LoRa Mac

5.6.2 Trame de signalisation du Node-F vers la Node-G

• Adresse source (Node-F) : 0xABCD 0000 0000 0001Il s’agit d’une adresse de la Node-F, elle utilise l’adressage IEEE EUI-64.

46


• Adresse destination (Node-G) :-Bit Node-F/Node-G + 7 bits reserves : 1 0000000 = 0x80Le permier bit prend la valeur 1 puisqu’il s’agit de l’adresse du Node-G.-Bit de signalisation + Adresse sur 7 bits de la zone : 10000001 = 0x81

Il s’agit d’une trame de signalisation, le bit de signalisation prend la valeur 1.Au final, l’adresse destination sera 0x80 0x81.


Figure 2.25 – Trame de signalisation du Node-F vers la Node-G

5.6.3 Trame data de la Node-G vers les Nodes-F

• Adresse source (Node-G) :-Bit Node-F/Node-G + 7 bits reserves : 1 0000000 = 0x80-Bit de signalisation + Ar. 7 bits addr : 0 0000001Il ne s’agit pas d’une trame de signalisation, le bit signalisation prend la valeur 0.

• Adresse destination (Node-G) : 0xABCD 0000 0000 0001Il s’agit d’une adresse de la Node-G, elle utilise l’adressage IEEE EUI-16.


Figure 2.26 – Trame de donnee du Node-G vers la Node-F

47


Conclusion

Ce chapitre s’articule autour de trois parties. Nous avons commence par la specificationdes besoins ou nous avons detaille les differents besoins de notre projet (fonctionnels et nonfonctionnels). Par la suite, nous avons fait la conception du projet a travers les differents dia-grammes avec leur explications. A la fin de ce chapitre, nous avons presente l’interoperabilitedans le reseau LORA FABIAN, la communication entre les differents protocoles des differentescouches ainsi que les differents standards utilises, nous avons accentue la communication inter-couches a la fin par une presentation des differentes trames qui circulent dans le reseau.

48

Chapitre III

Implementation


1 Realisation de la librairie pour la generation du trafic vers la passerelle . 50

1.1 Presentation des outils utilises . . . . . . . . . . . . . . . . . . . . 50

1.2 Presentation de la tache . . . . . . . . . . . . . . . . . . . . . . . 51

2 Definition, extraction et enregistrement des KPI . . . . . . . . . . . . . . 55



3 Analyse de la performance du reseau LoRa . . . . . . . . . . . . . . . . . 63



Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

49

CHAPITRE III. IMPLEMENTATION

Introduction

Apres avoir traite la partie conceptuelle du projet, nous allons presenter le cadre derealisation du projet a savoir l’environnement materiel et logiciel en premier lieu et les choixtechnologiques afin d’aboutir a l’application dont nous presenterons l’essentiel des interfacesa travers des captures d’ecrans.

1 Realisation de la librairie pour la generation du trafic

vers la passerelle

Pour chaque tache realisee, nous avons eu recours a plusieurs outils materiels et logiciels.Dans la section suivante nous allons presenter l’environnement logiciel utilise pour creer lalibrairie pour la simulation de l’envoi des paquets vers la passerelle.

1.1 Presentation des outils utilises

Une premiere partie sera consacre dans chaque tache realisee aux outils utilises pourla realisation de la tache correspondante. Nous commencons par les outils utilises pour ledeveloppement de la librairie Python.

1.1.1 Debian

Debian est principalement une distribution GNU-Linux, elle a pour principal but defournir un systeme d’exploitation compose uniquement de logiciels libres. La distributioncontient environ 15000 paquets logiciels elabores et maintenus par un millier de developpeurs.

1.1.2 Python

Python est un langage de programmation objet, multi-paradigme et multiplateformes.Il favorise la programmation structuree, fonctionnelle et orientee objet. Il est dote d’un ty-page dynamique fort, d’une gestion automatique de la memoire et d’un systeme de gestiond’exceptions.

1.1.3 Scapy

Scapy est un utilitaire permettant de forger, de recevoir et d’envoyer des paquets ou destrames de donnees sur un reseau pour une multitude de protocoles (IP, TCP, UDP, ARP,SNMP, ICMP, DNS, DHCP, ...) avec precision et rapidite. Nous retrouvons pour cette intro-duction la presentation de cet utilitaire en Python qui permet entre autres de realiser de lacapture de trafic ainsi que du mapping reseau, de l’arp cache poisoning, du VLAN Hoppingou de la reconnaissance passive de systeme d’exploitation.

Parmi les autres fonctionnalites marquantes de Scapy, nous noterons ses capacites a la dis-section de paquets et de trames de donnees ainsi que le decodage de certains protocoles.Pour l’equivalent d’une soixantaine de lignes de code en langage C, le couple compose dePython et Scapy ne necessite que quelques lignes la plupart du temps afin de realiser cesdifferentes operations de manipulation de paquets et de trames de donnees d’ou un gain de

50


temps considerable pour toutes personnes devant effectuer des manipulations de ce type surun reseau.

1.1.4 Openwsn berkeley

OpenWSN [18] est une implementation open-source d’une pile protocolaire basee sur lesstandards de l’Internet des objets, plus particulierement, le nouveau standard IEEE 802.15.4e.L’implementation de la pile protocolaire a travers OpenWSN a principalement de definir lesechanges entre les couches protocolaires dans l’Internet des objets, ainsi fournir une pla-teforme qui aide pour realiser des tests dans le domaine de l’Internet des objets. La pileprotocolaire implementee dans OpenWSN est en train de devenir le standard pour l’Internetdes Objets Industriel.

1.2 Presentation de la tache

Pour faire l’evaluation de la performance du reseau LoRa, il faut analyser les donneesqui circulent entre les nœuds (Node-F, Node-R et Node-G) puisque les informations sur laqualite du reseau sont trouvees dans la partie radio de l’architecture LORA FABIAN. Alors,pour savoir le contenu du lien radio et faire des tests sur les paquets qui sont envoyes parles stations LoRa, nous devons generer du trafic entre les Nodes-F, la Node-R et la Node-Gen envoyant des donnees a la passerelle et par consequent nous pouvons analyser les paquetsen question et extraire les informations necessaires pour l’evaluation de la performance dureseau. Le but de la realisation de la librairie est de generer differents types de trafic pourfaire des tests au niveau de la passerelle et par consequent preparer au client LORA FABIANun moyen qui lui permet d’analyser le trafic au sein de son sous reseau.

Nous devons respecter les normes LoRa lors de la construction des paquets et leur envoi. Pourfaire ca, il a fallu etudier l’architecture protocolaire entre les Nodes-F, Nodes-R et Nodes-Gpour que les paquets soient acceptes par la Node-G qui ne tolere que les paquets LoRa MAC.Les differents champs de la trame LoRa MAC sont definis dans le chapitre precedant ainsique le format de la trame 802.15.4e.La librairie prend le role de la Node-R (l’antenne LoRa) en encapsulant les donnees CoAPdes Nodes-F dans une trame LoRa. Apres la generation des paquets, la librairie envoie lestrames vers la passerelle Java.Donc, sur un systeme Debian et avec le langage de programmation python, nous avons utilisele module Scapy et la bibliotheque openwsn-berkeley pour la generation du trafic CoAP etson envoie par UDP vers la gateway.

1.2.1 Interaction entre Node-R et Node-G

La figure 3.1 presente la sequence d’actions principales entre la station LoRa (Node-R)et la gateway (Node-G) qui represente le lien radio dans l’architecture du reseau LORA FA-BIAN [19].

51


Figure 3.1 – Diagramme de sequence entre la station LoRa et la Gateway

L’antenne LoRa envoie les paquets recus des capteurs en les encapsulant dans des trames detype PUSH DATA dont le format est explique dans la partie precedente. A chaque receptiond’un paquet notre serveur (Node-G) repond par un acquittement PUSH ACK pour confirmerla bonne reception du paquet.Les deux types de paquets (PUSH DATA et PUSH ACK) contiennent la meme valeur duTOKEN pour identifier le meme paquet.

1.2.2 Protocoles de communication entre les nœuds et la passerelle

La communication entre les nœuds et la passerelle se fait dans les deux sens : celui del’Internet vers les objets connectes et l’inverse. Nous nous interessons a la communication surle lien montant (des Nodes-F vers la passerelle) qui utilise le UPSTREAM PROTOCOL. Lepaquet PUSH DATA envoye par la station radio LoRa a le contenu suivant :

• Protocol Version : Valeur sur 1 byte qui indique la version du protocole et qui estfixee a 1 selon le standard LoRa.

• Random Token : Une valeur aleatoire sur 2 bytes qui identifie le paquet.

• Push Data Identifier : Valeur sur 1 byte indique que c’est un paquet de type PUSHDATA, l’identifiant des paquets PUSH DATA sont toujours fixes a 0x00.

• Gateway Unique Identifier : Il s’agit de l’adresse MAC de la station LoRa sur 8bytes.

• Json Object : Ce champ contient des informations et des indicateurs sur la qualite dureseau comme le temps d’envoi du paquet, la frequence, le RSSI (Radio Signal StrengthIndicator)... Le contenu de l’objet JSON est explique dans la paragraphe ci-dessous.

52


La figure 3.2 montre l’explication des champs qui se trouvent dans l’objet JSON [19]

Figure 3.2 – Composants du JSON dans les paquets

A la reception du paquet PUSH DATA, la passerelle (Node-G) acquitte la reception desdonnees par l’envoi d’un paquet PUSH ACK. Son contenu est comme suit :

• Protocol Version : Valeur sur 1 byte qui est egal a 0x01 pour indiquer que le paquetappartient au reseau LoRa.

• Token : Le meme dans le paquet PUSH DATA, pour acquitter le paquet envoye.

• PUSH ACK Identifier : Ce champ indique qu’il s’agit d’un paquet d’acquittement.

1.2.3 Architecture de la librairie developpee

Le figure 3.3 presente l’architecture de la librairie realisee, les differents scripts qui, en-semble, permettent la generation du trafic vers la passerelle :

Figure 3.3 – Architecture de la librairie developpee

53


• Le script auto.py execute tout les scenarios qui existent dans le fichier scenarios.py.

• Le script scenarios.py definit l’ensemble des scenarios a tester, chaque scenario presenteune methode statique run qui envoi les donnees. Par exemple, nous testons l’envoi d’unpaquet d’un nœud deja enregistre dans notre serveur dns, nous testons l’envoi d’unautre paquet normal. A la fin de chaque scenario, nous envoyons le paquet au serveur.

• Le script lib.py contient l’ensemble des classes Node, LoraStation, Utils, CoapDataou chaque classe implemente ses propres methodes. Node contient la generation desdonnees a envoyer ainsi que leur envoi vers la station LoRa, LoraStation contient lareception des donnees ainsi que leur envoi vers le serveur. CoapData et Utils contiennentdes methodes permettent la generation des messages CoAP et des fonctions intermediairesutilisees par Node et LoraStation.

Figure 3.4 – Classes developpees pour la configuration de la librairie

• Le script shell.py permet d’importer les classes necessaires au fonctionnement de lalibrairie pour que l’utilisateur puisse realiser des tests sur la ligne de commande. Cescript permet aussi de sauvegarder toutes les commandes introduites par l’utilisateurdans un fichier separement.

La figure 3.5 montre la creation des paquets, l’instantiation des nœuds et enfin l’envoi despaquets.

Figure 3.5 – Envoi des paquets par la librairie

54


La generation des paquets procede en premiere etape a la transformation de leur contenu enBase 64 pour etre interpretes et decodes a l’arrivee a la passerelle. Apres l’instantiation dela Node-F et de la station LoRa, il y aura l’envoi des paquets a la fin du code.

2 Definition, extraction et enregistrement des KPI

Dans cette partie, nous allons presenter les outils utilises pour la realisation de la tache,ainsi que les differents etapes et captures d’ecrans sur les resultats.


En premier lieu, nous allons presenter les logiciels utilises lors de la definition, extractionet l’enregistrement des indicateurs de performance.

2.1.1 Eclipse

Eclipse est un environnement de developpement informatique destine principalement pourles applications JAVA. Il s’agit d’une plateforme de programmation qui offre plusieurs mo-dules appeles plugins pour faciliter le codage pour les developpeurs ainsi il offre la possibilitede creer son propre plugin. Nous avons fait le choix sur Eclipse puisqu’il contient tout lesoutils necessaires pour le developpement de notre application en plus que son concept permetd’avancer rapidement dans notre projet.

2.1.2 JAVA

JAVA est un langage de programmation tres populaire dans le domaine de developpementinformatique et reseau. Il possede un tres grand nombre de bibliotheques de classes independantesde la plateforme ce qui est le point essentiel de la programmation sur Internet ou plusieursmachines dissemblables sont inter-connectees.

2.1.3 Maven

Maven est essentiellement un outil de gestion et de comprehension de projet largementutilise dans le monde professionnel de developpement en Java. Il permet d’automatiser lagestion des projets Java, il est concu pour supprimer les taches difficiles du processus dudeploiement d’applications. Il permet de mettre en place des standards de developpementsau niveau d’une societe et reduit le temps necessaire pour ecrire et maintenir les scripts dedeploiement d’applications.

La description d’un projet Maven se fait dans un fichier XML situe a la racine du projet :le fichier pom.xml POM pour (Project Object Model). Il contient toutes les informationspermettant de gerer le cycle de vie du projet.Il offre principalement les fonctionnalites suivantes :

• Compilation et deploiement des applications Java (JAR, WAR).

• Gestion des librairies requises par l’application.

55


• Execution des tests unitaires.

• Generation des documentations du projet (site web, pdf, Latex).

• Integration dans differents IDE (Eclipse, JBulder).

2.1.4 JPA

Pour des raisons de performance, le cout d’ouverture et fermeture d’une connexion n’estpas negligeable. L’utilisation du langage SQL rend la couche DAO (Data Access Object) dif-ficilement maintenable.Pour pallier a cette problematique et faciliter l’ecriture de la couche DAO, la communauteJava a donc fait naıtre des Frameworks (ORM object relational mapping), tels que Hibernate,Toplink, EclipseLink. Dans notre cas, nous avons utilise EclipseLink.

Litteralement �Java Persistence API�, il s’agit d’un standard faisant partie integrante de laplate-forme Java EE, une specification qui definit un ensemble de regles permettant la gestionde la correspondance entre des objets Java et une base de donnees, ou autrement formuler lagestion de la persistance.Ce mecanisme qui gere la correspondance entre des objets d’une application et les tablesd’une base de donnees se nomme ORM.

2.1.5 Bases de donnees

Pour l’enregistrement des indicateurs de performance dans la base de donnees, nous avonschoisi de faire une sauvegarde a choix. C’est a dire, le client choisira la base de donnees surlaquelle il veut enregistrer les indicateurs de son reseau, soit une base de donnees MySQL etdans ce cas il doit installer MySQL dans son environnement ou une base de donnees H2 quisera integree dans l’application dans le cas ou le client n’a pas trop de donnees a enregistrer.

• H2 : C’est une base de donnees relationnelle, ultra-legere qui supporte un nombre li-mite d’utilisateurs et une taille mesuree de donnees. H2 permet de stocker les donneespour un petit systeme ou il y aura pas beaucoup de donnees a enregistrer comme parexemple une maison intelligente.

• MySQL : MYSQL est un systeme de Gestion de base de donnees (SGBD) qui a pourrole de gerer l’acces aux bases de donnees. Le serveur de base de donnes MySQL est tresrapide, facile a utiliser et fiable. Il fonctionne sous la plupart des systemes d’exploitation.Ce logiciel a l’avantage d’etre gratuit et hautement adapte au web. L’un des points fortde MySQL est qu’il est un SGBD de type relationnel comme Microsoft SQL Server etOracle, c’est-a-dire qu’il organise les donnees selon des tables comportant des champsa attributs simples et monovalues.


Pour analyser le comportement du reseau LoRa, nous allons definir des indicateurs deperformance qui vont nous permettre de connaitre l’etat du reseau, evaluer et faire des sta-tistiques.

56


Apres etude des informations circulant dans le lien radio entre la Node-F, la Node-R etla Node-G, nous avons constate que plusieurs champs dans les paquets qui circulent entreces nœuds s’averent utiles pour connaitre la qualite du reseau comme ceux a l’interieur duchamp JSON du paquet PUSH DATA envoye par la station LoRa. De plus, nous avons definitd’autres parametres au niveau de la passerelle pour faire des statistiques sur les paquets recusdans le reseau.

2.2.1 Indicateurs relatives a la qualite de service

• RSSI (Radio Signal Strength Indication) : C’est une mesure de la puissance en receptiondu signal radio recue d’une antenne en dBm. Son utilite est de fournir une indicationsur l’intensite du signal recu a partir de la station LoRa.

• Data Rate : C’est le debit de donnees de la station LoRa, la vitesse avec laquelle lesdonnees peuvent etre transmis par exemple ”SF12BW500” qui signifie (spreading fac-tor 12, bandwidth 500).

• Facteur d’etalement (Spreading factor) : Le nombre de chips pour un bit d’information.

• LSNR (LoRa SNR Ratio) : C’est le rapport signal sur bruit de la station LoRa, c’est lerapport de puissance entre le signal d’amplitude maximale par la puissance du bruit.C’est un nombre sans unite qui est d’autant plus grand que le bruit est negligeable.

• Modulation : Identifiant de la modulation ”LORA” ou ”FSK”.

• Taille : Taille du payload du paquet RF en bytes.

• Frequence : Frequence en MHz, frequence de la station LoRa (868.00O).

• Timestamp : Indicateur de temps pour la comparaison du temps d’envoi et de receptiondu paquet.

• CRC Status (Controle de redondance cyclique) : 1 = OK, -1 = erreur, 0 = Pas de CRC.

2.2.2 Indicateurs relatives a la charge du trafic ecoule

• Nombre de paquets recus.

• Nombre de paquets envoyes.

• Taille moyenne des paquets recus en octets.

• Taille moyenne des paquets envoyes en octets.

• Type de paquet : Signalisation ou Data.

• Type de message CoAP, s’il est une requete ou une reponse, s’il est de type CON, NON,

57


ACK ou RST.

Nous devons pouvoir visualiser ces mesures pour les cas suivants :• Tous les nœuds.• Les nœuds authentifies.• Un nœud particulier.

2.2.3 Reception des paquets et extraction des KPIs

Dans un premier temps, la passerelle reste en ecoute des paquets provenant de la stationLoRa.Au debut, il y a initialisation des differents services dans la passerelle.

Figure 3.6 – Initialisation des services au niveau de la Node-G

Par la suite, il y a demarrage des differents services initialises.

Figure 3.7 – Demarrage des services au niveau de la Node-G

58


Apres demarrage des differents services, la passerelle reste en ecoute des paquets envoyes parla station LORA.

Figure 3.8 – Passerelle en ecoute

Tous les services sont initialises et en ecoute (les ressources, CoapConnector, DNS resolver,Beacon Sender, HttpServer, LoraConnector...).La passerelle rejette tout les paquets qui n’appartiennent pas au reseau LoRa, les paquetsqui ont des versions differentes de 0x01. Elle fait un filtrage comme montre la figure 3.9 :

Figure 3.9 – Verification de la taille des paquets recus

Si la taille du paquet ne depasse pas une certaine valeur minimale, la passerelle rejette lespaquets.

59


Des reception des paquets de la part de la Node-R, la passerelle analyse les donnees et verifies’ils respectent la specification LORA MAC, sinon elle les rejette.

Figure 3.10 – Application des regles de filtrage aux paquets a la reception

A chaque paquet PUSH DATA recu, la passerelle acquitte la reception par envoi d’un paquetPUSH ACK a la Node-F correspondante :

Figure 3.11 – Acquittement sur les paquets recus

60


2.2.4 Enregistrement dans la base de donnees

Apres reception des paquets radio sous le format LoRa MAC au niveau de la passerelle,nous avons fait l’analyse des paquets recus en extrayant les indicateurs de performanceset en ajoutant d’autres indicateurs pour enfin les enregistrer dans une base de donnees.L’enregistrement s’est fait d’une maniere dynamique par JPA, et par consequent, si nousdecidons de changer la base de donnees, nous n’aurons pas besoin de changer dans le code.Nous avons alors definit deux tables, une pour les indicateurs de performances provenant dulien radio qui definissent la qualite du reseau, l’autre table est pour les statistiques comme lenombre des paquets recus et emis...

Figure 3.12 – Enregistrement des KPIs dans la base de donnees

D’une maniere dynamique, chaque paquet recu par la passerelle s’enregistre automatiquementdans la base de donnees.

Figure 3.13 – Donnees enregistrees dans la table ReceivedpacketsStats

61


En ce qui concerne les statistiques sur les paquets :

Figure 3.14 – Donnees enregistrees dans la table GeneralStats

2.2.5 Envoi des donnees vers Logstash

Apres chaque reception des donnees en provenance de l’antenne LoRa vers la passerelle ,cette derniere identifie les indicateurs de performances a partir des traitements sur les pa-quets recus et elle les envoi vers Logstash. Le code dans la figure 3.15 exprime l’envoi despaquets par UDP sur le port de Logstash.

Figure 3.15 – Envoi des paquets enregistres a Logstash

La figure 3.16 montre les traces de l’envoi des donnees vers Logstash a partir de la passerelleNode-G.

Figure 3.16 – Envoi des KPIs vers Logstash

62


3 Analyse de la performance du reseau LoRa

Dans la partie analyse de la performance du reseau LoRa, nous avons utilise 3 outilscomplementaires et performants pour l’analyse, la recherche et le stockage des donnees. Eneffet, si nous pouvons mettre en place une recuperation des logs de facon centralisee avecdes outils connus comme syslog, le trio Logstash, Elasticsearch et Kibana est un tres boncandidat pour gerer et trouver efficacement des informations dans les milliers de lignes detraces que peuvent generer les divers services.

Figure 3.17 – Fonctionnement de la pile ELK


Les outils utilises pour la preparation a l’analyse de la performance sont le trio Logstash,Elasticsearch et Kibana. Nous allons presente ces trois outils et exprimer comment nous avonsutilise la pile ELK dans le projet.

3.1.1 Logstash

Logstash est un outil de collecte, analyse et stockage de logs. Il sait gerer plus d’unetrentaine d’evenements. Un evenement peut etre un message syslog, un mail via le protocoleIMAP (Internet Message Access Protocol), un tweet ou encore une commande IRC (InternetRelay Chat)...Il va ensuite analyser ces evenements, et les mettre en forme a l’aide des filtres, il exporte cesdonnees, traitees ou non, sous divers formats : email, sortie standard, fichier texte, alarmeNagios, entree dans la base de donnees d’Elasticsearch. Ainsi, nous pouvons tres bien traiterplusieurs flux de logs differents, appliquer un filtre a chacun pour harmoniser le tout, et lesstocker correctement.

63


Logstash accepte a peu pres tout ce qui peut etre represente sous forme de chaıne de caracteresen entree (texte, nombre, date...).La liste des entrees disponibles est impressionnante et couvre des plugins particuliers pourCollectd, Graphite, websocket, les interruptions SNMP et meme irc...

3.1.2 Elasticsearch

Elasticsearch est un moteur de recherche open source base sur la librairie Apache lucene.A l’aide en particulier d’un systeme distribue de nœuds et de clusters, il permet de stocker,rechercher et analyser de tres gros volumes de donnees dans une base de donnees NoSQL quisupporte le bigdata.Les donnees integrees a Elasticsearch peuvent provenir d’une base relationnelle (par exempleOracle) comme d’une base NoSQL (par exemple MongoDB). Nou pouvons recuperer lesdonnees a l’aide de plusieurs ’rivers’. Une river (ou riviere) est un service associe a Elas-ticsearch permettant de recuperer des donnees en mode PULL depuis une base de donneesexterne.

Parmis les avantages d’Elasticsearch nous pouvons citer :• Les volumes qu’est capable de traiter Elasticsearch en matiere de recherche tout en

restant en temps reel.

• Le systeme de ¡¡facets¿¿ qui permet, sans cout supplementaire, de recuperer tout unensemble de statistiques sur les elements trouves, comme le nombre, la repartition deces elements par rapport a un champ donne...

• Logstash cree un index par jour (mois, annee...) par exemple, ce qui fait que vos re-cherches les plus courantes restent rapides, quelque soit le volume total d’evenementsstockes en base.

• La possibilite d’effectuer toutes les recherches via une API REST donc pas de clientdedie necessaire.

• Les versions futures embarqueront des notions d’alerting basees sur l’analyse de ten-dances et des requetes planifiees.

3.1.3 Kibana

Kibana est un outil de restitution et d’analyse de donnees. Il permet de visualiser etd’agreger sous differents donnees issues de la base d’Elasticsearch stockees par Logstash.Techniquement, Kibana est une application web developpee en Javascript pure et doncdeployable sur un simple serveur HTTP du type Apache HTTP Server.On peut faire notre propre dashboard sur Kibana selon nos besoins et les parametres qu’onveut superviser.


La tache ”Analyse de la performance du reseau LoRa” est basee sur la pile ELK, le trioElasticsearch, Logstash et Kibana.

64


Nous collectons les indicateurs de performance (les KPIs) au niveau de la Node-G et nous lesenvoyons sous format JSON a Logstash par UDP. En effet, Logstash possede un agent qui estconfigure a ecouter les donnees sur le port 4445 et puis les rediriger sur le port 9200 specifiquea Elasticsearch en sortie et par consequent les donnees seront accessibles par Kibana pourafficher des courbes et des statistiques.

3.2.1 Configuration et affichage des resultats

La figure 3.18 montre la configuration de Logstash qui consiste a recevoir les donnees enprovenance de la Node-G par ecoute sur le port 4445 en input (les donnees doivent etre sousformat JSON) et puis rediriger ces donnees vers Elasticsearch en output sur son port 9200qui va enregistrer les logs dans sa base de donnees.

Figure 3.18 – Configuration de l’agent Logstash

Oriente ”document” (au sens NoSQL du terme), toutes les donnees sont stockees sous formede documents JSON structures. Tous les champs sont indexes par defaut, et tous les indexpeuvent etre utilises dans une meme requete, pour retourner les resultats correspondant aune recherche a une vitesse impressionnante.

Nous lancons Logstash sur le port 4445, la figure 3.19 montre la reception des logs a partirde l’agent Logstash depuis la passerelle (Node-G) qui envoi les donnees par UDP.

Figure 3.19 – Lancement et reception des donnees par Logstash

65


Apres configuration d’Elasticsearch, Nous lancons l’agent, comme represente la figure 3.20,l’agent Elasticsearch est en ecoute sur le port 9200, il y a decouverte des clusters dans lereseau au debut du demarrage et lecture des donnees dans la base de donnees et puis l’agentreste en ecoute des messages qui arrivent.

Figure 3.20 – Demarrage d’Elasticsearch

A la reception des donnees, Elasticsearch indique sur la console les changements (les donneesenvoyes par Logstash) :

Figure 3.21 – Reception des donnees par Elasticsearch

Kibana peut acceder a ces donnees et faire des interfaces graphiques en fonction des donnees(KPIs) enregistrees dans la base de donnees d’Elasticsearch.

66


Puisque Kibana est une interface web stockees, pour le demarrer, il suffit de lancer le serveurapache :

Figure 3.22 – Lancement du serveur HTTP pour Kibana

Kibana s’installe tres simplement avec un Apache. Nous pouvons acceder a l’interface webde Kibana via le serveur, ou la page d’accueil est la suivante :

Figure 3.23 – Page d’accueil de Kibana

67


L’interface de Kibana nous permet de filtrer les logs selon le temps de leur arrivees a lapasserelle et donc faire l’analyse sur les logs des dernieres 5 minutes ou la derniere heure,selon notre choix comme le montre la figure 3.24.

Figure 3.24 – Filtrage des logs en fonction du temps d’arrivee

Apres enregistrement des indicateurs de performances dans Elasticsearch, nous accedons al’interface de Kibana pour voir si les donnees existent dans Elasticsearch. Le resultat montreles KPIs enregistres dans la passerelle, chaque ligne presente les indicateurs de performancede chaque paquet recu par la Node-G :

Figure 3.25 – KPIs enregistrees dans la base de donnees d’Elasticsearch

Nous pouvons definir notre propre dashboard ainsi que plusieurs options possibles par exemple(la realisation d’un histogramme, d’un tableau, des courbes...).

68


Parmi les indicateurs de performance definis, nous trouvons le RSSI, la figure 3.26 exprimela courbe du RSSI (Radio Signal Strength Indicator) en fonction du temps :

Figure 3.26 – Courbe de RSSI en fonction du temps

L’histogramme de la figure 3.27 montre l’evolution de la taille des paquets en fonction dutemps.

Figure 3.27 – Histogramme de la taille des paquets en fonction du temps

69


Avec Kibana, nous pouvons aussi faire des regroupements comme le montre la table de lafigure 3.28 qui presente les adresses MAC en fonction des IDs des paquets.

Figure 3.28 – Regroupement des paquets selon leur ID/MAC/temps d’envoi

Egalement, Nous pouvons faire des statistiques avec l’outil Kibana, par exemple afficherla taille moyenne des paquets ou la valeur moyenne du RSSI, comme le montre la figure3.29, ainsi que plusieurs autres operations comme la valeur maximale, la variance, la valeurminimale ou le nombre de paquets avec une telle adresse MAC.

Figure 3.29 – Statistiques avec Kibana

70


Nous pouvons faire aussi une classification des paquets recus par rapport a leur Code Ratecomme le montre 3.30 :

Figure 3.30 – Classification des paquets selon leur Code Rate

Nous pouvons aussi classifier les paquets selon leur Data Rate et dans un autre formatdifferent du precedent :

Figure 3.31 – Classification des paquets selon leur Data Rate

71


Nous pouvons a la fin construire un tableau de bord personnalise contenant tout les infor-mations que nous voulions afficher en temps reel :

Figure 3.32 – Exemple d’un tableau de bord choisi sur Kibana

Conclusion

Au cours de ce chapitre, nous avons presente les differents outils utilises pour la contri-bution au travail effectue. Nous avons choisi de diviser ce chapitre sur trois parties quirepresentent les trois taches principales du projet de fin d’etudes. Nous avons commencepar la definition des indicateurs de performance du reseau, par la suite, nous avons decritla reception de ces indicateurs au niveau de la passerelle. La derniere tache consistait a laconfiguration de la pile ELK pour l’analyse de la performance du reseau.

72

Conclusion generale

Mon projet de fin d’etudes consiste a developper un module d’analyse de la performancedu reseau sur une passerelle securisee intelligente pour l’Internet des objets developpee parTelecom Bretagne dans le cadre du projet LORA FABIAN (Long Range For A BeautifulInternet Advanced Network), la passerelle permet de creer son propre reseau d’objets intelli-gents interconnectes avec Internet grace a l’utilisation des standards innovants du DNS et del’API REST, tout en utilisant des bornes radio qui offrent une connectivite bi-directionnellea longue portee.

Le but de ce travail a consiste principalement a fournir une solution logicielle pour lasurveillance et la gestion de la performance du reseau LORA FABIAN sur la passerelledeveloppee pour l’Internet des objets. Il s’agit de trouver une solution qui fournisse la matierede base aux differentes analyses a mener pour comprendre son application et surveillant letrafic entre les capteurs et la passerelle.

Au cours de ce travail, tout les besoins fonctionnels et non fonctionnels du projet ont eterespectes. En effet, plusieurs taches etaient faite pour aboutir a la solution finale, chaquetache avait ses propres besoins fonctionnels, commencant par la generation du trafic vers lapasserelle sous differents types de requetes, passant par la definition et l’enregistrement desindicateurs de performance du reseau pour conclure avec la solution basee sur la pile ELK(Elasticsearch, Logstash et Kibana) qui fournisse la matiere de base pour faire des analysesavec des courbes et l’utilisation de plusieurs outils et des indicateurs de performance dejadefinis.

L’une des perspectives du projet LORA FABIAN de Telecom Bretagne est de mettre lestechnologies radio longue portee dans les mains de tout le monde par la creation d’un reseaucommunautaire et donner des moyens simples pour utiliser le reseau.

LORA FABIAN est de base une architecture independante de la technologie radio, pour lemoment, nous utilisons la technologie radio LoRa mais si dans le futur des autres technologiesradio deviennent accessible, nous allons pouvoir les integrer. Donc, nous nous basons sur latechnologie de l’Internet, nous sommes independant de la technologie de la couche liaison.

Le projet LORA FABIAN vise a ameliorer les technologies existantes et implementer desnouveaux protocoles specifiques a l’Internet des objets.

Finalement, l’interoperabilite dans le reseau LORA FABIAN est un service a offrir dansle futur ou les objets peuvent echanger de l’information entre eux, au-dela de leurs formatsproprietaires.

73

Bibliographie

[1] Telecom-Bretagne, “http ://courrier.telecom-bretagne.eu/,” consulte le 13/04/2015.

[2] IRISA, “https ://www.irisa.fr/,” consulte le 04/06/2015.

[3] Projet-LORA-FABIAN, “http ://www.labfab.fr/portfolio/lora-fabian/,” consulte le15/02/2015.

[4] A. Pelov, “http ://perso.telecom-bretagne.eu/alexanderpelov/,” consulte le 10/01/2015.

[5] L. Toutain, “http ://perso.telecom-bretagne.eu/laurenttoutain/,” consulte le16/02/2015.

[6] Societe-Kerlink, “http ://www.kerlink.fr/fr/,” consulte le 15/02/2015.

[7] Lora-Station, “http ://kerlink.fr/fr/component/content/category/10-articles-fr/,”consulte le 17/07/2015.

[8] Startup-Wi6LABS, “http ://www.wi6labs.com/site/,” consulte le 15/02/2015.

[9] Module-Arduino-Lora, “http ://www.froggyfactory.com/froggy/,” consulte le02/03/2015.

[10] AFNIC, “https ://www.afnic.fr/,” consulte le 15/02/2015.

[11] L.Toutain, A.Pelov, and Y.Delibie, “Impact des objets sur les protocoles de l’internet,”L’avenir d’Internet, REE N 2/2013.

[12] P.Fitcheux, C.Adjih, J.Verdun, and A.Lefevre, “The open source innovation spring bigdata—iot—cloud—qualite logicielle,” 3 avril 2015, Paris & Palaiseau.

[13] T.Val, E.Campo, and A.BOSSCHE, “https ://github.com/lora-net/loramac-node/,”consulte le 03/08/2015.

[14] Specification-LORA, “https ://www.aruco.com/2015/06/lora-alliance-lorawan-r10/,”consulte le 15/02/2015.

[15] E.Ancilotti, S.Duquennoy, and A.Dunkels, “A low power coap for contiki,” IEEE 8thConference on Mobil Adhoc and Sensor Systems, 2011.

[16] J. T.Adams, “An introduction to ieee std 802.15.4,” Institute of Electrical and ElectronicEngineers, New York, 1 Octobre 2013.

[17] S.Scaglia, “Protocole ieee 802.15.4,” Aout 2012.

[18] T.Watteyne, “https ://github.com/openwsn-berkeley/coap,” consulte le 03/06/2015.

[19] S.Miermont, “https ://github.com/lora-net/packet forwarder/blob/master/protocol.txt,”consulte le 15/05/2015.

[20] M.Chehaider, K.Roussel, and Y.Song, “Interoperabilite des reseaux de capteursheterogenes dans un appartement intelligent,” UbiMob 2013, 5-6 Juin 2013, Nancy,France.

74