Fault Tolerant Sensor Network for Data Collection. Aslak Johansen, Jan Kjetil Chu,

Transkript

1 Fault Tolerant Sensor Network for Data Collection Aslak Johansen, Jan Kjetil Chu, 15. december 29

2 2 Abstract In this thesis we are going to develop a number of network protocols for WSN (Wireless Sensor Networks). The protocols developed will distinguish themself from the wide selection of WSN protocols out there, by being a point-to-point communication protocol, and not the wellknown collection/dissimination protocol. We are going to emphesize on fault tolerance, and try to come up with a good solution for point-to-point communication in WSN, that addresses some of the problems WSN has when it comes to failure in communication. We will analyse, implement and evaluate these solutions, and will end up with protocols that are proven to be able to communicate over 15 hops at 1% linkquality at each hop. In the evaluation we will investigate, and set, the parameters available in our protocols. They will be evaluated in such a way that the reader will be able to set these parameters to match hi's or her's WSN enviroment. We will end up with to types of protocols, SinglePath/MultiPath, wich used 1/2 paths to communicate over. We will nd out that the SinglePath algorightm is MultiPath superior in most situations, and even in a edge rich network, SinglePath is the better. The problem with SinglePath is that it dosent handle nodes dieing mid-communication. The MultiPath protocol, with its 2 communication paths is able to continue if one path becomes incomplete because of a node that dosent respond.

3 Indhold Indhold 3 Figurer 5 Tabeller 8 1 Introduktion Kontekst Trådløse sensornetværk TinyOS Simulation LoWPAN Brugen af ActiveMessages Mana Fejltolerence Tilgang Helbredsmonitorering Bidrag Denition af 'fejl tolerence' Baggrund Denition af problemet Design af robust system Netværkslag Problematikker Fragmentering Korruption som følge af crosstalk Bekræftelser Gentagen modtagelse af frames Klasser af routningsprotokoller Globale routningsprotokoller Decentraliserede routningsprotokoller Distance-vector routing Counting to Innity Protokoller Protokollen Yeller Protokoller med statiske kommunikationsveje Valg af kommunikationsveje Protokollen MultiPath Ansvar for bekræftelser API

4 4 INDHOLD 4 Implementation Protokollen Yeller Pakkeformat Afsending af en frame Modtagelse af en frame Terminering af udbredelsesbølge Behandling af frames Protokollen MultiPath Pakkeformat Routning Bedømmelse af understier Strukturen af en score Udregning af en score En nodes relationer til naboer En nodes relationer til stier Opbygning af et stisæt Ændring af targetnode Routning Beskeder Bekræftelser Evaluering Valg af støjmodel Linkkvalitet vs. Gain Netværkstopologier Konkretisering af protokoller Delte parametre Parameteren RECV_BUFFER_SIZE Parametre for Yeller Parameteren FORWARD_BUFFER_SIZE Parameteren PACKET_DROP_TIMEOUT Parameteren PACKET_BUFFER_SIZE Parameteren SENDQUEUE_SIZE Parametre for Multipath Parameteren PATH_COUNT Parameteren HELLO_COUNT Parameteren NEIGHBOURID_BUFFER_SIZE Parameteren SEND_SAFE_CONSTANT_TIMEOUT Parameteren MAX_RESEND_COUNT Parameteren PACKET_DROP_TIMEOUT Parameteren FIND_PATH_TIMEOUT Parameteren ROUTE_BUFFER_SIZE Parameteren SEND_QUEUE_SIZE Parameteren SEND_SAFE_QUEUE_SIZE Automatisering af optimering af parametre Resulterende protokoller Eksperimenter Eksperiment 1: Linje topologi Hvordan ser den totale overførselstid ud for hver protokol? Hvornår begynder protokollerne at fejle mht. datatransmission? Hvor mange frames bliver der totalt transmitteret i netværket? Opsummering Eksperiment 2: Tilfældig topologi Hvordan ser den totale overførselstid ud for hver protokol?

5 INDHOLD Hvornår begynder protokollerne at fejle mht. datatransmission? Hvor mange frames bliver der totalt transmitteret i netværket? Opsummering Eksperiment 3: Geogrask topologi Hvordan ser den totale overførselstid ud for hver protokol? Hvornår begynder protokollerne at fejle mht. datatransmission? Hvor mange frames bliver der totalt transmitteret i netværket? Opsummering Eksperiment 4: Hastighedstest Linje topologi Tilfældig topologi Geogrask topologi Opsummering Eksperiment 5: Yeller Opsummering Konklusion Fremtidigt arbejde Litteratur 92

6 6 INDHOLD

7 Figurer 3.1 De grundlæggende protokolkategorier Nodenetværk hvor R ønsker at kommunikere med T Dårligt valg af veje til T Nodenetværk hvor R ønsker at kommunikere med T via multipath protokol Stiliseret model over kommunikationsvejen over et enkelt hop Softwarestak for Yeller Eksempel på indhold af headere ved routing af en pakke med MultiPath Opbygning af et stiset for multipath protokol Kombinering af understier med multipath protokol Forhold mellem linkkvalitet og gain Eksempler på resultater af forskellige topologigeneratorer Throughput i B/s ved forskellig RECV_BUFFER_SIZE og hoptal ved 5% linkkvalitet Sandsynlighed for en pakke går igennem med Yeller, linje-topologi og linkkvalitet 9% Procent overbehandling af frames for hele netværket ved 1% linkkvalitet Eksempel på et opdelt netværk Sandsynligheden for oprettelse af et ikke opdelt netværk ved brug af linje topologi Procentfordeling af brugt tid på afsending af en frame Gennemsnitligt antal gensendinger af en frame inden ACK modtages. SinglePath, linje-topologi, 1% linjekvalitet Maksimale afstand mellem to frames ud fra Hoptal Tid mellem modtagne FIND_PATH pakker hos den søgte node Behov for ROUTE_BUFFER_SIZE Maksimalt brug af SEND_QUEUE målt i antal frames Maksimalt brug af SEND_SAFE_QUEUE målt i antal frames Overførselstid målt i millisekunder Antal frames som er modtaget, set i forhold til det forventede antal Antal frames sendt i hele netværket Gennemsnits overførselstid ved forskellig valens og linkkvaliteter Procentdel modtagne frames ved forskellig valens og linkkvaliteter Gennemsnits antal sendte frames i netværket ved forskellig valens og linkkvaliteter Overførselstiden under geogrask topologi ved forskellige densiteter og datastørrelser Overførselstiden ved geogrask topologi ved forskellige datastørrelser Antal sendte frames i netværket under geogrask topologi ved forskellige densiteter og datastørrelser Antal sendte frames i netværket ved geogrask topologi ved forskellige datastørrelser Hastighed målt i B/s under linje-topologien (Eksperiment 1) Hastighed målt i B/s under den tilfældige topologi (Eksperiment 2) Hastighed målt i B/s under den geograske topologi (Eksperiment 3)

8 8 FIGURER 5.28 Andel af modtagne frames ved brug af Yeller protokollen under tilfældig og geogrask topologi

9 Tabeller 1.1 Features supporteret af forskellige TOSSIM sprog Netværkslag API for protokol Udvalgte linkkvaliteter med matchende gain-værdier Hvor meget koster det at gå fra MultiPath endack til SinglePath endack med 9% linkkvalitet og 999B data

10 1 TABELLER

11 Kapitel 1 Introduktion Dette speciale er skrevet af Jan Kjetil Chu og Aslak Johansen på DIKU (Datalogisk Institut ved Københavns Universitet) 29. Vi er ligeligt ansvarlige for rapportens indhold, og den skrevne kode. Vi lægger ud med at introducere omgivelserne til denne afhandling. Ud fra denne kontekst beskriver vi derefter de problemområder vi har beskæftiget os med. Til sidst præsenterer vi vores bidrag og gennemgår afhandlingens opbygning. 1.1 Kontekst I denne afhandling behandles begrebet reliability indenfor området for trådløse sensornetværk. Herved krydses to emner, hvis overlap traditionelt set ikke har tiltrukket meget opmærksomhed. Vi introducerer derfor emnerne separat Trådløse sensornetværk Et trådløst sensornetværk består af det kommunikationsmedie og -logik der skal til for at en række sensornoder kan løse en specik opgave. Den enkelte sensornode er udstyret med den beregningskræft og radioforbindelse der skal til for at indgå i netværket, samt sensorer for at bidrage til dets nytte. Visionen var at kunne bestrø et interessant område med 'elektronisk støv' og derefter kunne indhente oplysninger fra det. Jo mindre noder desto bedre. Eksempelvis kunne man bestrø et habibat med sensornoder, der har temperatur- og fugtighedssensorer samt en GPS-modtager. Noderne skulle da automatisk kongurere og vedligeholde et netværk, der med jævne intervaller transmitterer måledata tilbage til en basestation for analyse. Med tiden er konceptet blevet populært og anvendelserne har - som det så ofte sker - udvidet sig. I dag bruges udtrykket om praktisk talt enhver 'sky' af sparsommeligt udstyrede indlejrede systemer, der kan forbindes til eksternt udstyr (som f.eks. sensorer). Fælles for disse variationer af sensornoder er, at systemerne har været udsat for en lang række kompromiser: For at holde produktionsomkostninger og størrelse på et minimum, vælger man billige komponenter. Det betyder i praksis stærkt begrænset regnekraft, hukommelsesmængde og kommunikationsmuligheder. For at få strømkilden til at holde længere benytter man endog ofte duty-cycling[9] til at begrænse energikravet fra komponenter som f.eks. radio. De billige komponenter har desuden en tendens til at udvise ikkedeterministisk adfærd som følge af forskellige 11

12 12 KAPITEL 1. INTRODUKTION former for ekstern påvirkning eller blot tilfældigheder. Tilgangen til placeringen af logik for initiel behandling af data kan karakteriseres som værende udspændt af to dominerende og modsatrettede ideologier. Ifølge den ene ideologi har man en basisstation forbundet via en gateway. Basisstationen er ikke underlagt nodernes energikrav, hvorfor noderne sender alle foretagne målinger hertil, ideelt set med duty-cycling. Data behandles således dér hvor ressourcerne er billigst. Ifølge den anden ideologi skal sensornetværket være selvstændigt uden et single-point-of-failure (som f.eks. en basisstation) og forespørgsel bør derfor sendes til netværket der - set som en helhed - er i stand til producere et svar. Praktiske implementationer indeholder selvfølgelig aspekter af begge ideologier. Sensornoderne deployeres som regel så tyndt at det kun er et fåtal af dem, der bender sig indenfor gateway'ens rækkevidde. For at nå én af de resterende noder bruges mellemliggende noder til at route kommunikationen. De enkelte trin i routningskæden kaldes 'hop' og den klasse af protokoller der kan route indenfor sådanne topologier benævnes 'multi-hop' TinyOS TinyOS[5] er et styresystem, der er skrevet til trådløse sensornetværk og lignende anvendelser. Der medfølger derfor en række komponenter for understøttelse af hardware og protokoller, hvis footprint er stærkt begrænset. Systemets Open Source status[4] sørger for en fælles kodebase hvortil adskillige enkeltpersoner og institutioner bidrager. Med denne som medie er det særdeles let at sammenligne resultater, hvilket gør systemet særligt anvendeligt for det videnskabelige samfund. Gennem grænseader kan en komponent påtage sig roller. Rollerne hører til i en hierarkisk arkitektur, hvor det nederste lag udgøres af hardware og hvert yderligere niveau tilføjer abstraktion og/eller logik. Rollerne er valgt således, at de nederste lag modsvarer funktionalitet, der eksisterer i komplicerede men ikke i simple hardwareplatforme. Dette gør brugerne af systemet i stand til at tilpasse det til en bred vifte af både eksisterende og kommende hardwareplatforme. TinyOS består af en samling af komponenter, der dækker de basale servicefunktioner som normalt er implementeret i kerne, systembiblioteker og middleware. Ved at udvælge og forbinde en delmængde af disse komponenter og derefter skrive sine egne applikationsspecikke komponenter kan man skræddersy sit styresystem. På denne måde kan man minimere størrelsen af den resulterende rmware. Den komponentvise opbygning kan også bruges til at implementere fejltolerence i relativt lavtliggende lag uden at påvirke de applikationsspecikke komponenter. Eksekveringsmodellen er todelt, men essentielt eventdreven (hændelsesdreven, da.). En hændelse i hardware (registrering af ekstern påvirkning eller en udløben timer) trigger et interrupt der sendes til et lavtliggende komponent. I komponenten udføres den respektive kode, der kan sende events til andre komponenter. Herved hopper eksekveringstråden til eventhandlere i disse komponenter, der igen kan udsende events. Udover at udsende events kan kode poste (tilføje, da.) tasks til en kø. Tasks udføres ét af gangen i FIFO rækkefølge og kan blive midlertidigt afbrudt af events med mindre interrupts er slået fra Simulation TinyOS[2] applikationer kan kompileres til simulation. TOSSIM er en diskret event simulator. Gennem tossim er det muligt af udføre eksperimenter under kontrollerede og repeterbare forhold. For at simulere, kompilerer man sin applikation til en bestemt platform. Det der i virkeligheden sker er, at de nederste lag i applikationen bliver erstattet med biblioteker fra host-computeren og det hele kompileres så til en binær l. Jo ere lag man erstatter i bunden, desto mere indviklede

13 1.1. KONTEKST 13 Feature C++ Python Hastighed (i forhold til C++) 1x.5x Debugger til simulationskode Inspektion af variable i simulation Inspektion af memoryregioner i simulation Injektion af pakker Tabel 1.1: Features supporteret af forskellige TOSSIM sprog modeller kan man benytte. TOSSIM modellerer interrupts, men ikke ikke cpu-tid. Kode udføres derfor øjeblikkeligt. TOSSIM simulerer netværket på bitniveau. Ved opstart specicerer man hvilke noder der kan høre hvem og ved hvilken dæmpning der skal være på linket mellem dem. Man associerer desuden en støjmodel til de enkelte noder. Et eksperiment konstrueres som et program. Programmet bestemmer antallet af noder, topologi og baggrundsstøj. Simulationen foregår ved at man itererer igennem nogle evenst. Man har mulighed for, på et givent tidspunkt at injecte frames. Dette gøres ved at man først obygger framen med de værdier man er intereseret i og derefter giver simulatoren besked på at en bestemt node skal modtage framen på et bestemt tidspunkt. Debug-beskeder kan printes til separate kanaler. Afhængig af om der er tale om endelig kørsel eller ren debug kan man vælge hvilke kanaler man er intereseret i. Eksperimentet kan skrives i enten C eller Python. Tabel 1.1 viser foredele og ulember ved de to sprog LoWPAN 6LoWPAN[25] er IPv6 over LowPan. LowPan har ofte været brugt i sensornetværk og IPv6 siges at være fremtiden for internettet. Kombinationen gør det muligt at tilgå en vilkårlig node over internettet og har derfor tiltrukket en del interesse. Der ndes aktuelt to implementationer af 6lowpan for TinyOS. Den første [19] mangler lidt features (heriblandt ping-funktionalitet). Den anden er blip[1][16] (Berkeley IP). Blip er på vej ind i TinyOS, men kan aktuelt ikke kompileres. Mens 6lowpan har klare fordele i praksis brug, er der en del ekstraarbejde forbundet med at bygge en fejltolerant protokol på den. Det lader ikke til at let at route frames. Man kunne selvfølgelig route på UDP-niveau, men så mister man en del kontrol Brugen af ActiveMessages ActiveMessages er en highlevel frametype på 38 bytes, hvis abstraktion håndteres i dertil egnede moduler. Håndteringen kaldes for AM protokollen og involverer blandt andet en CRC kode på to bytes. Ifølge de dokumenter vi har fundet skulle en sådan frame kunne lates med 32 bytes[6]. ActiveMessages lader til at være fast inventar i TinyOS 2.1. Det er svært at informationer om hvordan man slipper for denne abstraktion.

14 14 KAPITEL 1. INTRODUKTION Mana Mana (Monitoring remote environments with Autonomous sensor Network-based data Acquisition systems)[3] er et projekt som arbejder med indsamlingen af data fra måleenheder i svære forhold. Mana arbejder tæt sammen med Zackenberg [7] som er en forskningsstation i grøndland hvor man ønsker at indsamle data ude fra felten. Pt. står en mængde Cambell Scientic CR1 ude i felten og indsamler data. Hver dag går en videnskabsmand ud til hver CR1 og kobler sin bærbar på CR1'eren via RS232. Ved hjælp af et program, kaldet LoggerNet, forbinder den bærbar til CR1'eren, og henter den indsamlede data. Dette skal gøres for samtlige CR1'ere. I Mana projektet ønsker at automatisere denne indsamling af data. Man har ønsket at benytte sig af sensornetværk, men de almindelige protokoller til WSN (Wireless Sensor Network) er ikke beregnet til interagere med kun enkelte noder. Enten sender noderne automatisk data ind til en sink, kaldet collection. Eller også sender man kontrolbeskeder ud til samtlige noder, kaldet dissemination. Mana ønsker at kunne forbinde LoggerNet til CR1 via et sensornetværk. Dette kræver dog at der ndes en løsning på hvordan man kan kommunikere direkte med en enkelt node. Her blev vi inddraget i Mana projektet og har på bagrund af dette behov, arbejdet imod en løsning i dette speciale. På grund af de tørre forhold vil der forekomme udladninger af statisk elektricitet i polare egne. Dette vil påvirke elektionik, og sætter meget høje krav det det udstyr som man ønsker at anvende. Det betyder, at der kan forekomme ekstra forstyrelser på radioudstyret, som sætter krav til softwaren Fejltolerence Et fejltolerent system reagerer hensigtsmæssigt når en fejl af en bestemt type opstår. På dette punkt er det danske ordforråd temmelig begrænset; adskillige engelske ord mapper til det danske 'fejl'. En fault er en fejlagtig tilstand i hard- eller software. En error er en fejl (fault), der manifesterer sig i software eller data. failure er hvad der sker når den ydede service (grundet en error) afviger fra det korrekte. Siewiorek og Swarz har en ganske udemærket forklaring af forskellene i [11]. Eksempel: En fault kan blandt andet være forårsaget af støj eller defekt hardware. Den resulterende error kunne da være modtagelse af en besked med bitfejl eller regnefejl. Behandlingen af disse fejlbehæftede data vil sandsynligvis resultere i forkerte resultater ( failure). Det er urealistisk at detekterer faults. Man kunne overvåge udvalgte omstændigheder der kan forårsage faults, f.eks. radiostøj. Ved at have redundante data og software (f.eks. 2 algoritmer hvis resultater skal stemme overens) kan errors detekteres og korrigeres. En failure er resultatet af manglende redundans. RAID-1 er måde at opnå fejltollerance på sit disksystem. Her sættes to diske op som et spejl af hinanden. Når der skrives/læses data bliver dette gjort på begge diske identisk. Hermed har man altid en tro kopi, og kan tåle at den ene af disse diske dør. Disksystemet kan såvel også detektere fejl i data, hvis en læsning ikke stemmer overens mellem de to diske. Hermed er en fault detekteret. Går den disk i stykker, kan systemet afværge en failure ved at arbejde videre på den anden. Den fejlbehæftede disk kan herefter skiftes ud, og disk-arrayet genopbygge sig selv så systemet igen er fejl tollerant (aktiv healing). RAID-5 er en anden måde hvorpå der sikres fejltollerance. Her bruges minimum 3 diske til at levere fejltollerance. Har man N diske vil der blive skrevet data til N-1 diske. Den sidste disk vil indeholde en paritetbit som XOR'et med de andre diske giver et på forhånd kendt resultat. Dermed kan systemet tåle at en disk fejler, da systemet kan regne ud hvilke data der står/burde stå på

15 1.1. KONTEKST 15 disken. Som RAID-1 kan RAID-5 også detektere fejl i systemet da data skal leve op til et regelsæt. Ved RAID-1 skulle det være ens, i RAID-5 kan vi se om data står korrekt via paritetdata. Der kan i begge RAID udgaverne benyttes en hot-spare. Dette er en disk som ikke er en del af disk-systemet, men ligger til rådighed for systemet. Såfremt en disk, tilhørende det kørende system fejler, kan systemet vælge at benytte hot-spare disken. Systemet starter nu med at genopbygge systemet, så der igen tilbydes fejltollerance. Dette sker automatisk såfremt denne hot-spare er sat til systemet. LM Ericssons AXE telefoncentral benytter en tilsvarende teknik til at detektere faults i APZ'en (processoren)[11]. Processeren har en A-side og en B-side, der er ens. Under normal kørsel udfører de præcis den samme kode. Kontrollogik vericerer at de to sider giver ens resultater. Hvis de to sider ikke opfører sig ens, suspenderes den normale operation indtil en self-test har bestemt hvilken side, der er fejlbehæftet. Når den defekte side er lokaliseret lukkes den ned mens den anden side fortsætter hvor arbejdet blev sluppet. På grund af brugen af regionale processorer kan denne test foretages uden at påvirke igangværende trak. DMI[2] har opstillet en stor mængde målestationer, fordelt på hele danmark. Fra disse målestationer indsamles en stadig strøm af meteorologiske data. De indsamlede data betragtes ofte som en helhed. Helhedsbilledet degraderer ikke betydeligt af at der mangler data fra et par målestationer. Så selvom der er failures på enkelte komponenter reagerer det samlede system ved at give et lidt ringere overblik. Denne 'teknik' kaldes gacefull degradation og er i dette tilfælde en del af problemformuleringen. Tolerencen er til dels opnået gennem alternative målinger. Noget der ikke er en mulighed i forhold til Mana projektet. Når uheldet er ude, og et system stopper med at virke, kan man i nogle tilfælde undersøge hvorfor systemet fejlede. Metoden kaldes post mortem analysis og betyder analyse efter døden. Et eksempel er den sorte boks på et y. Hvor man, i tilfælde af f.eks. yulykker, kan nde ud af hvad der var skyld i systemets nedbrud. I dette tilfælde yulykken. Dette kræver dog at systemet er designet til denne form for efteranalyse Tilgang Systemer til håndtering af fejltollerence bearbejder problemer i en række trin. Fault Detection Dét at opdage at der er sket en fejl. Fault Isolation Det at præcisere hvad der er fejlet. Fault Handling Enten Containment, så fejlen ikke påvirker resten af systemet, eller Correction, så fejlen går i sig selv igen. I nogen systemer er nogle af disse trin meget nært beslægtede Helbredsmonitorering Når man opsætter et tådløst sensornetværk ude i felten, fungerer tingene ikke altid som man håber. Der er eksempler på hvordan, der ved opsætning af trådløse sensornetværk, ikke har været kontakt til samtlige noder. Dette er først blevet opdaget en måned senere, hvor man opdagede at af den resterende del, var det kun halvdelen som returnerede resultater fra deres måleinstrumenter[12]. Ved netop ovennævnte situation er det uunværligt at have helbredsmonitorering. En funktion som kan benyttes til at undersøge om ens noder kan kommunikeres med, og om de fungere som de skal.

16 16 KAPITEL 1. INTRODUKTION Man kan dermed under opsætning af sensornetværket, kontrollerer at alle noderne fungerer i stedet for at håbe på det bedste. helbredsmonitoreringen kan gøres simpelt, f.eks. ved at sende en broadcast ud på netværket, der får samtlige noder til at sende statusinformationer tilbage til roden. Hermed kan man se, om en given node er til at komme i kontakt med, og hvad dens status er. Disse statusinformationer kunne såvel også indeholde informationer omkring antallet af hop to roden, sidste måling fra måleinstrument, batteristatus, linkkvaliteten til naboerne osv. Når man sætter sensore op i felten er det utrolig vigtigt at vide om de virker. Det er simpelhen for trist at man en måned senere nder ud af, at nodernes placeringen umuligøre radiokontakt til roden og at man derfor ikke har modtaget målinger som forventet. 1.2 Bidrag Vores bidrag er følgende: En point-to-point protokol, der kan varieres i adfærdsmønster både med hensyn til rumlig og temporal redundans, og med hensyn til hvor der bekræftes. Et udgangspunkt som Mana projektet kan arbejde videre på, med informationer om faldgrupper og gode ideer.

17 Kapitel 2 Denition af 'fejl tolerence' I dette afsnit skriver vi om hvilke betydninger, man kan lægge i begrebet fejltolerence indenfor trådløse sensornetværk. Systemet kan være tolerent overfor én eller ere kategorier af fejl. Mana-projektets særlige problematik matcher ikke specielt godt den klassiske opfattelse af et sensornetværk. Det klassiske sensornetværk består af en større mængde noder, hvis enkeltvise betydning er til at se bort fra. Værdien af netværket bunder i det samlede overblik, der fremkommer når den store mængde noder løbende rapporterer deres aktuelle sensormålinger. Kvaliteten af det resulterende situationsbillede mindskes ikke betydeligt af, at der mangler resultater fra enkelte noder. I nogle tilfælde, hvor målinger foretages med et bestemt interval, frafalder en målings værdi idet øjeblik den efterfølgende måling bliver tilgængelig. Afsendes målingerne som en stadig strøm fra sensorer til en relæstation, accepteres det derfor typisk, at enkelte målinger aldrig når frem. Visionen for løsningen til manaprojektet er, at benytte hard- og software fra trådløse sensornetværk til at forbinde en lille mængde dataloggere, hvis beliggenhed udgør en betragtelig barriere for radiosignaler. På grund af det arktiske klima er det forbundet med relativt store omkostninger at placere en node. Vi begrænser os derfor til udelukkende at se på løsninger, hvor der er netop én node per datalogger. De benyttede dataloggere er ikke klassiske sensorer, der kan aæses elektrisk, men indlejrede systemer, som kommunikeres via en protokol. Brugsmønsteret er derfor, at en udefrakommende agent opretter en forbindelse til en bestemt datalogger, handshaker, og udsteder ordre. Dataloggeren udfører løbende disse ordre og sender ved bestemte ordre data retur. Kommer dele af data ikke frem, behandles de i forkert rækkefølge eller er blot for lang tid om at nå frem - således at der opstår timeout i protokollen - opnås fejlbehæftede resultater. For at løse denne problematik, skal det trådløse netværk derfor kunne sende en pakkestrøm fra en relæstation til en navngiven node. Som navn kunne man bruge adresser. sende en pakkestrøm fra en given node tilbage til relæstationen. I begge tilfælde er det følgende egenskaber for pakkestrømmen nødvendige: Ankomst Pakker der afsendes skal ankomme til den tiltænkte destination. Ordnethed Pakker skal aeveres til applikationslaget i samme rækkefølge som de bliver afsendt. 17

18 18 KAPITEL 2. DEFINITION AF 'FEJL TOLERENCE' Latency Pakker skal nå frem indenfor et rimeligt tidsrum som er øvre begrænset af dataloggerens protokol. 2.1 Baggrund Ser vi på systemet, kan følgende områder rammes af fejl: Sensor En fejl i en sensor vil viderebringes af datalogger. Fejl-detektion kan foretages ved at sammenligne med lignende målinger (og gætte). Datalogger En fejl i dataloggeren kan betyde at kommunikationen til sensoren sker fejlagtigt med korruption af data til følge. Nodens applikation kan sættes til at 'lytte' efter faresignaler, som f.eks. lang svartid, eller foretage et tidligt tjek af måledata før de sendes videre. Link til datalogger En fejl i linket til dataloggeren vil betyde at node og datalogger ikke kommunikerer korrekt. En sådan fejl kan være statisk, periodisk eller sporadisk. Nodens hardware Selve noden er det mest sensornære område, der har mulighed for direkte at påvirke andre sensorer. Hvis en node fejler på en sådan måde, at den begynder at forurene radiorummet med data, kan dette have katastrofale følger for netværket. En sådan adfærd ville dog være rimelig let at detektere. Sværere ville det være, hvis den til dels virkede og kun en gang imellem sendte fejlbehæftede data. Nodens software kan indeholde fejl. Enten vil det skyldes en fejl i den oprindelige kode eller også er fejlen opstået under transmission eller som følge af hukommelsesfejl. Ved at benytte to forskellige algoritmer og sammenligne deres resultater, kan er fejl detekteres. Medie Mediet er radiobølger i luft. For at kunne skelne disse signaler fra baggrundsstøjen, skal de have en markant højere styrke. Når mediet fejler, observeres et forkert signal på modtagerenden. Det betyder at mediet er modtagelig for udefra kommende omgivelser. Et link der er nede i længere tid kan detekteres ved at have et langsomt, men konstant, ow af data i stil med heartbeat. Hvis man kræver bekræftelser, kan en tabt frame detekteres på en manglende bekræftelse. De af ovenstående punkter, der handler om hardware, kan gøres redundante ved duplikering. Hardwaren er følsom overfor statisk elektrisitet og kraftige magnetiske påvirkninger. Dette er hvordan feltet ligger. Vi har ingen chance for at gennemgå hele feltet til en dybde, hvorfra vi kan opnå interessante resultater. Vi har derfor besluttet os for at vælge en mere snæver denition af begrebet 'fejltolerence'. 2.2 Denition af problemet I vores indsnævring koncentrerer vi os udelukkende om radiolinket. Vi ønsker at undersøge mulighederne for at konstruere et transportsystem, der er tolerant overfor transmissionsfejl. Mere præcist interesserer vi os for følgende emner: Hvordan påvirker linkkvalitet overførselshastighed og radioforbrug (antal sendte pakker)? Hvordan påvirker konnektivitet overførselshastighed og radioforbrug?

19 Kapitel 3 Design af robust system I dette kapitel gennemgår vi de overvejelser, der ligger til grund for designet af vores protokoller. Det er disse overvejelser, der ligger bag implementationsvalgene, som er beskrevet i det efterfølgende kapitel. Som udgangspunkt gives en model for netværkslag i afsnit 3.1. Herefter præsenteres en række relevante problematikker i afsnit 3.2. I afsnit 3.3 præsenteres de to hovedklasser af routningsprotokoller, hvorefter valgmulighederne for specikke egenskaber gennemgås i afsnit 3.4. I afsnit 3.5 opstilles en grænseade for, hvordan vores protokoller bør kommunikerer. 3.1 Netværkslag Tabel 3.1 viser - i form af en simpliceret OSI model -, hvordan de routningsprotokoller, der skal udvikles, er placeret i netværkslagene. Det nederste lag er radioen, der kommunikerer på bitniveau. Når den rette mængde bits er transmitteret signaleres datalinklaget. Dette betragter den modtagne sekvens som en datastruktur og foretager et CRC-tjek. Vi benævner dette lag som 'ActiveMessage', fordi frames tilgås gennem et modul af dette navn i TinyOS. I realiteten er ere moduler involveret. Protokollens opgave er, at fragmentere (se afsnit 3.2.1) pakker fra applikationslaget, sætte de underliggende lag til at route frames, der repræsenterer disse fragmenter til destinationsnoden, hvor de samles til en pakke og leveres til applikationslaget. Applikationslaget er klient i forhold til protokollen og kan udformes på utallige måder. 3.2 Problematikker I dette afsnit introducerer vi nogle generelle principper, som har bærende eekt i de følgende protokoller. Medie lag Enhed Lag Implementation Data 4. Applikation FetchApp Packet 3. Netværk Protokol Frame 2. Data Link 'ActiveMessage' Bit 1. Fysisk Tabel 3.1: Netværkslag 19

20 2 KAPITEL 3. DESIGN AF ROBUST SYSTEM Fragmentering En TinyOS ActiveMessage har en maksimal payloadstørrelse på 28 bytes. Det er således ikke muligt at transmittere større datamængder uden at foretage fragmentering. Fra de 29B skal frameheader og eventuelt dataheader fratrækkes. Det er i høj grad op til protokollen om det garanteres, at frames ankommer i samme rækkefølge, som de er afsendt. Er dette ikke tilfældet, må protokollen sortere de modtagne frames, inden resultatet præsenteres for applikationslaget Korruption som følge af crosstalk Når to radioer, der begge er indenfor rækkevidde af en tredje, transmitterer over radioen samtidigt, vil den tredje ikke kunne skelne de to signaler fra hinanden. den vil derfor modtage et kombineret signal. Det kombinerede signal vil højst sandsynligt hverken modsvare det den første, eller det den anden radio udsendte. I et - oftest vellykket - forsøg på at undvige denne situation benytter TinyOS en CSMA[24] protokol. CS står for Carrier Sense og betyder, at en node venter på at mediet 1 bliver frit (ved at vente på en pause på sendefrekvensen) før den begynder at transmittere. MA står for Multiple access og betyder, at multiple noder er forbundet til mediet, hvorfor de både kan sende til og modtage fra det. Man kunne forestille sig en situation hvor noderne N a og N b begge er indenfor rækkevidde af N c, men at de ikke er indenfor rækkevidde af hinanden. I denne situation vil CSMA ikke hjælpe hvis N a ønsker at sende en besked til N c, mens N b er i gang med at transmittere. TOSSIM modellerer denne situation ved at lade N c observere en bitstrøm, der er produceret som en logisk or mellem de to signalers bitstrømme. I det følgende eksempel sender N a og N b hver 2 bytes, med 3 bits forskydning i tid: N a sender N b sender N c modtager Den bitstreng N c modtager er fejlbehæftet og kan, hvis man er uheldig, blive accepteret af radiomodulet. En checksum vil kunne fraltrere hovedparten af disse sammenfald, således at modtagelsen ikke gør direkte skade. Man kan sige, at der er en øvre grænse for hvor meget data, det giver mening at transmittere indenfor en nærhedsgrænse af en node. Overstiges denne grænse, begynder noden at droppe fejlbehæftede frames, med mindre redundans og/eller mere trak til følge Bekræftelser Ved nogle protokoller kan det være nødvendigt at få en garanti for, at den anden side af en kommunikation har modtaget en frame. Den klassiske løsning er, at modtageren sender en speciel ACK pakke tilbage, hver gang en frame er modtaget som en form for kvittering. Den afsendende side gensender de enkelte frames periodisk, indtil de er bekræftet modtaget (via en ACK-pakke). Hvis linkkvaliteten tillader det, vil framen med tiden nå igennem. Den modtagende part kan på denne måde modtage de enkelte frames ere gange og skal derfor tage højde for dette i behandlingen. 1 Mediet er i dette tilfælde luftrummet omkring noden, hvorigennem radiobølgerne transmitteres.