Les RCSFs de part leur vaste champ d'applications, subissent de nombreuses contraintes
telles quel'énergie, lesressources matérielles etla communication. Lesbesoins motivéspar ces
contraintestrouventdesréponses,maisaucunen'estgénérique.Chaqueméthodedéveloppéeest
bien souventorientée vers une application ouunecontraintespéci que dansun environnement
tout aussi spéci que. Il n'y a pas à ce jour une réponse générique à toutes les contraintes. La
problématiquedel'administrationdeRCSFresteentièretantlesujetestvaste.Répondreàtous
lesbesoins desnoeuds, en termesde gestion,demande de développerde nombreux mécanismes
pour gérer l'énergie, les ressources matérielles et les communications. De ce point de vue, les
méthodes développées aux couches inférieures participeront nécessairement à la préservation
de ces ressources. Par contre, pour adapter le noeud aux contraintes qu'il subit une solution
d'administration est obligatoire.
Sans administration, il est di cile de déployer des RCSFs sur des applications vastes ou
à risques. Les solutions présentées proposent de nombreux mécanismes répondant à quelques
contraintes mais aucune ne gère la totalité des contraintes. Les solutions d'administration ne
permettentpasencoreàcejourdeproduireuneréponsegénériqueàlaproblématiquedesuper-
vision des OICs. Les solutions basées sur le protocole SNMP ne proposent qu'une adaptation
de l'agentpour pouvoirl'embarquersur lesnoeuds. Ladiversité des informationsadministrées
est alors faible en se cantonnant à la problématique de la gestion de la mobilité des noeuds
et de la stabilité des liens. Une approche centralisée a été évoquée mais le faible degré d'évo-
lution réduit son utilisation sur les réseaux agri-environnementaux par exemple. Par ailleurs,
les autres approches basées sur une couche logicielle intermédiaire, middleware, proposent des
mécanismes intéressants pour l'administrationcomme la programmation modulaire ou le sys-
tèmede miseàjour.Cependant,ces méthodes demandentl'ajoutde traitementssur lesnoeuds
et donc l'augmentation des performances des noeuds pour obtenir la même application que
sans cette technique. Les commandes seront interprétées à la réception par cette interface in-
termédiaire avant d'exécuter les actions qui leur sont associées. En n, il existe des méthodes
spéci quesàunecontraintecommelagestiond'énergie.Ces méthodessontbien souventliéesà
unearchitecturematérielleetlogiciellelesrendantdi cileàmettreenoeuvredansun contexte
diérent.Néanmoins,lestechniquesutiliséespourlimiterl'utilisationdesnoeudsetpourpréser-
ver l'énergieconstituent des atouts intéressants qu'une solution d'administration doit prendre
en compte.
En parallèle à la supervision du réseau, des méthodes complémentaires doivent être mises
enplacepourtraiterlespointsassociésàladiusiondes donnéesdansleréseau.L'organisation
du réseau est alors un point clépour faciliterles échanges mais aussi pour limiter l'impactde
la diusion des messages sur les noeuds. La piste retenue par tous est la clusterisation hié-
rarchique a n d'atteindre n'importe quel noeud du réseau sans faire appelaux noeuds inutiles
pourladiusion.Cettetechniquededécoupageestprésenteauniveauduroutagemaisaussiau
niveau de l'administration.Pourcette dernière,ledécoupageduréseauconsisteàdé nirlerôle
des noeuds a n de répartir les fonctions d'administration. Les deux découpages peuvent alors
obligatoirementd'unpointde vue 'routage'.Ladiusiondes données sefaitdoncàpartir d'un
protocole de routage adapté auxcontraintes du réseau.Qu'il soitproactif, réactif, ouhybride,
leur rôle reste la découverte de la route optimaleentre une source et une destination. L'admi-
nistrationsebase sur ces méthodes pour diuser ces messages etrequêtes. Lacompressiondes
données d'administration devientalors intéressantepour limiterleséchanges notammentpour
la mise àjour àdistance des noeuds.
Parailleurs,pourl'ensembledeces solutionsd'administration,lesparamètressontcollectés
à la demande, c'est-à-dire qu'il y aura un message diusé par paramètre souhaité. L'aspect
intrusifde cessolutionsin uenceralefonctionnementdu noeud, sonautonomieetses échanges
dansleréseau.Unelimitationdesaccèsauxdonnéesdoitêtreenvisagéeàtraversdestechniques
dedéductionetdeconnaissancesducontexte. Parexemple,certainesinformationscommel'état
d'un capteur peuvent être déduites des données qu'ilenvoie.
En dé nitive,lessolutionsd'administration ne permettentpas encoreà ce jourde produire
une réponse génériqueàlaproblématiquede gestion des RCSFs.Même si de nombreuses idées
sont très innovantes, aucune ne peut être migrée ou utilisée directement sur n'importe quelle
plateformematérielledans n'importe quel environnement. La problématique énergétique a été
priseencomptedanslessolutionsd'administrationprésentéesàtravers uncontrôledesdonnées
diusées, du temps de fonctionnement des noeuds ou de leurs organisations. Cependant, les
solutions produites ne parviennent pas à répondre àl'ensemble des caractéristiquesd'un outil
de management. C'est pourquoi, le chapitre suivant présentera une méthode d'administration
appelée LiveNCM qui tente de répondre à toutes ces caractéristiques tout en étant la moins
intrusive possible eten adoptantcertaines idées vues ici.
Une nouvelle approche de l'administration
Le chapitre précédent présentait diérentes solutions d'administration existantes pour les
RCSFs.Certainesorentdesfonctionnalitésintéressantes permettantune meilleuregestiondes
ressources ouune meilleuremodularité,mais aucune ne correspond entièrementaux demandes
d'administrationdes RCSFs.Ilest donc apparunécessaire de développerune nouvellesolution
de supervision de réseau d'OICs a n de traiter plus e cacement les contraintes actuelles des
RCSFs. En complément, nous choisirons d'introduire des restrictions supplémentaires, a n de
limiter lesvolumes de données échangées ausein des réseaux pour minimiserl'impactde l'ad-
ministration sur lasource énergétique et sur l'application.
Ce chapitreest consacré à laprésentation de l'architecture d'administrationLiveNode Non
invasive Context-aware and Modular management (LiveNCM) et de son implémentation au
sein d'un RCSF. Les contraintes générales d'un noeud seront directement prises en compte
au cours du développement a n fournir une solution adaptée aux problèmes liés à chaque
noeud.LadimensiongénériquedeLiveNCMimposerad'eectuerdeschoixlogicielscertesmoins
performantsmaispermettant de faciliterson utilisationpour leséchangesd'informationsentre
les noeuds etl'utilisateur tout en optimisant saportabilité.
3.1 LiveNCM : LiveNode Non invasive Context-aware and
Modular management
Le domaine des RCSFs, comme nous avons pu le constater dans le chapitre précédent,
contient encore de nombreuses problématiques non résolues. Les solutions existantes d'admi-
nistrationdeRCSFproposentunemultituded'idéesintéressantesorantunebonnemodularité
des applications embarquées ainsi qu'une meilleure gestion des ressources. Si une architecture
modulaireest utile pour lamise à jourdes applications oudes progicielsdes noeuds, la charge
engendréepourtraiteretmettreenoeuvrelesnouvellesversionspeutdevenirlourde.Demême,
les solutions optimisant les ressources s'appuient souvent sur des systèmes d'exploitation spé-
ces diérents points, l'adaptation de l'une des méthodes présentées dans le chapitre précédent
demande un travail importantd'adaptation aussi bien au niveau de son développement qu'au
niveau de sonenvironnementde travail.Deplus,de nouvelles contraintes devrontêtre ajoutées
et porteront sur le volume des données échangées ainsi que sur la réactivité des noeuds. Au
nal, une nouvelle méthode d'administration est nécessaire pour intégrertous ces points en se
basant sur lesdiérentsavantages des solutionsexistantes.
En se basant sur ce constatet sur les diérents critères cités à la section 2.1.1, la solution
LiveNCM a pu voir le jour. L'objectif de cette technique est bien sûr de faciliter l'accès aux
données par l'utilisateur en rendant les échanges totalement transparents pour celui-ci et le
moinsintrusifpossiblepourleréseau.Pourlimiterl'impactdel'administrationsurl'application
et plus généralement sur le réseau, LiveNCM est conçu pour permettre une réduction des
échanges concernant la collecte des données administratives. Cela passe par l'intégration du
concept de diagnostic indirect et des techniques d'estimation et de compression. Le principe
est de déduiredes informationsd'étaten fonction des diérentsmessages échangés.Si dansles
méthodes présentées précédemment, l'autonomie des noeuds était déjà un élément important
à prendre en compte, ici, on associe ces méthodes à un nouveau modèle d'administration qui
permettra d'ampli er leurs gains énergétiques. Chaque messagetransitant devient un message
d'administration dans lequel il est toujours possible de déduire des informations sur l'état de
l'émetteur.
Avec une diusion importanteet de nombreux outils d'administration, ilsemblealors inté-
ressant de s'appuyersur leprotocoleSNMP, présentécommeleprotocoled'administrationdes
réseaux laires,a n de centraliseret d'organiserleséchanges avec lesRCSFs.Malgré des mes-
sages de tailleconséquente (100 à 200 octets), ce protocole a atteintune notoriété importante
danslesréseaux lairescequien faitl'acteurmajeurdessolutionsd'administration.Deplus,de
nombreux outils ontvu lejour, etmaintenant ontrouvetrès facilementdans tous leslangages
de programmationdes fonctionnalités SNMP.Pour cesraisons, LiveNCM achoisi d'adapterce
protocole pour avoir une interface connue et reconnue entre les noeuds etl'utilisateur. La liai-
son entre ce protocole et les noeuds nécessitera l'utilisationd'une interface de communication
transférant les données d'un acteur à un autre. Cette interface a pour objectifs de permettre
un accès facile aux noeuds et d'intégrer quelques fonctionnalités périodiques d'administration
comme la synchronisation. En externalisant cette partie, il est alors possible de déporter sur
des sites diérents l'agentet la passerelle. Par ailleurs,le protocole SNMP s'appuie sur le mé-
canisme UDP/IP pour envoyer les requêtes ce qui permet d'y avoir accès via n'importe quel
réseau local laire du type Local Area Network (LAN) (réseau informatique local) ou Wide
Area Network (WAN) (réseau informatique étendu). La passerelle de communication pourra
donc tirer pro t de ceci pour communiquer avec l'agent.Les échanges dans cette architecture
se baseront sur un protocole de communication autre que SNMP pour prendre en compte les
contraintes de communication dans les RCSFs ainsi que la contrainte de taille des messages.
Celui-ci pourra reprendre des caractéristiques des existants comme 6LoWPAN, notamment
pour la formalisationdes données, et utiliserdiérentsprotocolesde routagepour transmettre
lesrequêtes. Par ailleurs,a n de rendre génériquecette solutiond'administration etsurtoutle
traitements. On peut penser alors à l'utiliser à tout niveau de la communication, que ce soit
pour l'administrationou pour les collectesde données.
D'un point de vue global, la solution LiveNCM propose une nouvelle structure d'adminis-
tration basée sur un seul agent SNMP adapté centralisant les remontées d'informations des
noeuds via une passerelle de communication dédiée et indépendante. La Figure 3.1 présente
une première vision de l'architecture recherchée par laquelle l'utilisateur dialoguera avec les
noeuds.
Figure 3.1 Architecture d'administration souhaitée par LiveNCM
L'extension de l'agent SNMP, présent sur la machine centralisant les informations, se fera
sousformed'unsous-agentquiintégreral'ensembledesnouvellesdonnéesàsuperviseretrépon-
dra aussi bien auxrequêtesde l'utilisateur qu'àcelles des noeuds. Lesdiérents élémentsde la
solutionreprennentunepartiedescaractéristiquesdesméthodesexistantestoutenintroduisant
de nouvelles contraintes sur leséchanges etsurl'administration.L'utilisateurpourramettreen
oeuvre n'importequeloutild'administrationSNMPdisponiblepourmanageràdistance unen-
semblede RCSFsconstitués de plusieursnoeuds interfaçantplusieurscapteurs. Ladynamique
de ces réseaux implique alors d'avoirune solutiond'administration réactiveet adaptable pour
prendre en compte le moindre changement de chaque élément. Cela se traduit donc par une
nouvellecontraintesur laréalisationdu sous-agentSNMP quidevra permettre, àtout instant,
des modi cationsde lastructurede données utilisée.Ce mémoireprésente alorsl'ensembledes
étapesdu développement de la solutiond'administration LiveNCM etplus particulièrementla
partiededialogueaveclesnoeuds.Noustravailleronsalorssurlesous-agentSNMP,lapasserelle
decommunication,l'agentembarquésurlesnoeudsainsiquesurleprotocoledecommunication
utilisé. La section suivante présentera, en détails, ces diérents éléments en s'attardant sur la
réponseapportéeaux nouvellescontraintes dedynamisme, de volume de donnéeséchangées, et
de réactivité.