Research and Development 1/^Archief/2009-2010/04/Pilot/Verslag

Uit Werkplaats
Ga naar: navigatie, zoeken

Inleiding

Stel je voor, je ligt te slapen. Plotseling gaat je wekker af, zonder dat jij die de avond te voren hebt gezet. De wekker heeft namelijk in je agenda gekeken, en gezien dat je eerste afspraak om 10.45 in het Huygensgebouw is. Hij heeft bepaald dat de reistijd vanaf je huis 20 minuten is, en weet dat je een uur nodig heb om op te staan. Dus om 9.25 begint je wekker te rinkelen, en gaan meteen de lampen branden en staat de verwarming al hoog. Als je na een uurtje de deur uit gaat, merkt de deur dat je vertrekt, en laat het de lampen en verwarming weten dat ze weer uit mogen.

Ons doel van het Research en Development project is dit scenario waar te maken. Eerst onderzoeken hoe we dit kunnen maken, en daarna willen we een deel echt bouwen.

IPv4 of IPv6?

Waarom IPv6

IPv6 is ontwikkeld omdat IPv4 binnenkort niet genoeg adressen heeft voor alle gebruikers. IPv4-adressen bestaan uit 32 bits. Hierdoor zijn er 2^32 mogelijke IPv4-adressen. Verschillende mensen hebben voorspeld dat deze adressen binnen een paar jaar op zijn. Tijd voor een opvolger dus!

Verschillen

Het eerste verschil is dus de lengte van het adres. IPv6 gebruikt 128 bits (kort genoteerd als /128)adressen. Dit resulteert in 2^128 (ongeveer 3,4e38) adressen.

IPv6 is beter te routen. Omdat er zo veel adressen zijn, kun je een netwerknummerhiërarchie opzetten. Er kunnen afspraken worden gemaakt dat bepaalde netwerksegmenten aan bepaalde continenten worden toegewezen. Hierdoor worden routing tabellen minder ingewikkeld. In een Local Area Network (LAN) delen alle nodes de eerste 64 bits van het IPv6-adres. De laatste 64 bits worden dan gekozen op basis van het MAC-adres van de netwerkkaart van de node. Het is dus niet nodig om IP-adressen uit te delen.

Bij een IPv4 standaard 255.255.255.0 lokaal-subnet zijn er 2^8 adressen mogelijk. In een IPv6 LAN worden de eerste 64 bits bepaald op basis van het netwerk, en heb je dus nog 64 bits over. Hiermee kun je dus nog 2^64 IP-adressen vormen.

De grote hoeveelheid adressen zorgt er ook voor dat Network Address Translation (NAT) in IPv6 niet meer nodig is. NAT is bij IPv4 ingevoerd om te zorgen dat meerdere nodes samen één IPv4 adres gebruiken. Dit bracht wel wat complicaties met zich mee bij peer-to-peer situaties, maar het zorgt ook voor extra veiligheid. Met IPv6 kan deze veiligheid ook creeeren door bepaalde poortnummers dicht te zetten.

Conclusie

Voor het Internet Of Things zijn een paar dingen erg belangrijk. Je wilt alle artefacten in je huis voorzien van een IP-adres. Met IPv4 heb je een limiet van 2^8 adressen. Gezien een huisomgeving meer dan 256 artefacten kan bevatten (denk aan lampen, stopcontacten, schakelaars, electronica), is dat niet genoeg. Met IPv6 zijn er 2^64 mogelijke adressen. Dat zijn er veel meer, dus dat is een voordeel voor IPv6.

Een ander groot voordeel is dat er geen NAT meer nodig is, alles is dus direct te adresseren.

Door de vele voordelen is het ook vrij zeker dat dit de nieuwe standaard gaat worden. Omdat wij voorbereid op de toekomst willen zijn, gaan wij dus voor IPv6.

Bronnen:
http://tools.ietf.org/html/rfc791
http://tools.ietf.org/html/rfc2460
http://en.wikipedia.org/wiki/IPv6
http://en.wikipedia.org/wiki/IPv4
http://en.wikipedia.org/wiki/IPv4_address_exhaustion
http://tweakers.net/nieuws/66497/xs4all-start-grootschalige-ipv6-pilot.html

6LoWPAN

Wat is 6LoWPAN

De locatie van 6LoWPAN in het OSI model. Copyright 6LoWPAN.net

6LoWPAN (IPv6 over Low power Wireless Personal Area Networks) is een protocol, ontworpen door de IETF. Het is een uitbreiding op IPv6, waarvan we eerder hebben besloten het te zullen gebruiken. 6LoWPAN bevindt zich op de netwerklaag, en kan ook invloed hebben op de transportlaag. Op het netwerkniveau regelt 6LoWPAN headercompressie, en op de transportlaag kan het UDP-compressie regelen, hoewel niet gecomprimeerde UDP-packets ook mogelijk zijn.

De 6LoWPAN voegt onder andere de volgende mogelijkheden toe:

  • Header- en UDP-compressie
    • Omdat packets volgens de specificatie slechts 127 bytes mogen zijn (tegenover de 1280 byte in 'standaard IPv6'), is compressie wenselijk.
  • Automatische netwerkconfiguratie door neighbor discovery.
    • In mesh-netwerken kunnen apparaten onderling de beste routing uitkiezen, er is geen centraal punt meer nodig.
  • Ondersteuning voor unicast, multicast en broadcast.
    • 6LoWPAN ondersteund het verzenden van packets een-op-een, een-op-veel en naar-iedereen.

Netwerkvormen

Met behulp van 6LoWPAN kunnen een aantal netwerkvormen worden opgezet:

  • Simple LoWPAN: een aantal LoWPAN apparaten communiceert met een router als centraal punt. Deze zorgt voor verdere communicatie met het internet. Een bericht van een LoWPAN-apparaat kan door een willekeurig aantal andere apparaten doorgestuurd worden voordat het de router bereikt. Op die manier kan een apparaat dat normalitair buiten bereik van het acces point valt, toch met internet communiceren.
  • Extended LoWPAN: extended LoWPAN volgt hetzelfde ideel als Simple LoWPAN, maar er kunnen nu meerdere routers bestaan in een netwerk.
  • Ad-hoc LoWPAN: een aantal LoWPAN apparaten communiceert onderling, maar kan niet met apparaten buiten het netwerk communiceren.

Voor ons project zijn Simple- en Extended LoWPAN interessant. Ad-hoc LoWPAN valt af, apparaten moeten immers op het internet aangesloten worden.

6LoWPAN packets

IPv6 packet vs. 6LoWPAN packet. Copyright 6LoWPAN.net

Packets die verstuurd worden via 6LoWPAN hebben een minder grote overhead. Overhead is het percentage bytes van het packet dat iets anders is dan de payload (het te versturen bericht). Zie afbeelding rechts.

6LoWPAN of wifi

6LoWPAN bevindt zich (hoofdzakelijk) op dezelfde netwerklaag als onder andere wifi. Ten opzichte van wifi heeft het een aantal voor- en nadelen, die we hier zullen bespreken. Op basis van deze diagnose besluiten we vervolgens of 6LoWPAN of wifi het beste bij ons project past.

Voordelen 6LoWPAN t.o.v. wifi:

  • Lager energieverbruik
  • Mesh topologie
  • Compressie

Nadelen 6LoWPAN t.o.v. wifi:

  • Lagere overdrachtssnelheid.
  • Niet compatibel met gangbare netwerkkaarten.
  • Minder 'beproefd concept'.

De bovengenoemde nadelen zijn echter niet van groot belang voor ons product. De lagere overdrachtssnelheid is geen probleem, de hoeveelheid data die we moeten versturen is minimaal, en de header- en UDP-compressie vangt dit probleem deels op. De compatibiliteit met huidige netwerkkaarten is geen groot probleem: de communicatie zal toch via internet verlopen, waardoor bijvoorbeeld een laptop en een koffiezetapparaat toch met elkaar kunnen communiceren.

Hoewel het 6LoWPAN minder 'beproefd' is dan wifi, biedt het voordelen die haast onmisbaar zijn. Het stroomverbruik van wifi zou onacceptabel zijn, vooral voor draadloze apparaten. Daarbij is het voor een 6LoWPAN-netwerk niet noodzakelijk om dicht bij de router te zijn, onderling kunnen apparaten immers ook routing regelen.

Conclusie

6LoWPAN is ontworpen voor low-power apparaten, en biedt dan ook verschillende voordelen voor deze apparaten. Omdat, zoals hierboven besproken, de nadelen voor ons project geen probleem vormen, is een verbinding via 6LoWPAN te prefereren boven een verbinding over wifi. Daarbij maakt het stroomverbruik van wifi een oplossing in wifi praktisch onmogelijk. We kiezen voor ons project dus voor het gebruik van 6LoWPAN.

Bronnen

HAL en Platform

Platform

Om te voorkomen dat het wiel opnieuw uitgevonden moest worden is gezocht naar een Hardware Abstraction Layer (HAL) in de vorm van een OS om onze applicatie op te bouwen en een bestaand hardware platform. Aangezien er gekozen is voor 6LoWpan is er gekeken naar welke hardware platformen ondersteuning bieden voor een IEEE 802.15.4 interface. Hierbij kwam de volgende hardware naar voren:

  • Texas Instruments CC2530: Platform draaiend op een 8051-variant-processor
  • Atmel AVR Raven: Platform draaiend op een AVR-processor

We hebben hierbij gekozen voor het AVR platform omdat hiervoor een opensource-GCC-compiler gratis beschikbaar is.

Het Atmel AVR Raven platform bevat een ATmega1284P processor, uitgerust met 16 KB RAM en 128 KB Flash, die verbonden is met een AT86RF230 IEEE 802.15.4 radio transciever.

HAL

Er is al vrij snel voor gekozen om niet vanaf niet bare-metal te programmeren voor het gekozen platform omdat dit veel tijd in onderzoek naar de hardware zou kosten. Het leek ons beter om dat aan de echte experts over te laten die een OS hebben gebouwt en ons bezig te houden met een applicatie op dat OS. Gezien het feit dat er gekozen is voor de Atmel AVR Raven hardware en bijbehorende GCC-compiler is er gekeken naar Operating Systems die gecompileerd kunnen worden door AVR-GCC en tevens wat betreft RAM en ROM op de Atmel Raven draaien.

  • TinyOS (een OS-gericht op low-power wireless devices)
  • FreeRTOS (een standaard RTOS, niet specialiseert in een bepaalde soort devices)
  • ContikiOS (een OS-gericht op low-power wireless devices en komt met IPv6-compatible stack)

Gekozen is vervolgens voor ContikiOS om de volgende redenen:

  • Komt standaard met een IPv6-compatible stack (dit bezorgt ons het werk om een IPv6-compatible stack te maken of de uIPv6 stack te porten naar FreeRTOS of TinyOS)
  • Is gericht op low-power wireless devices en bied ondersteuning voor energiebesparende functionaliteiten.
  • Bied een goede development omgeving en veel documentatie en voorbeelden.
  • Wordt actief ondersteund door de maker van onze hardware Atmel

Bronnen

AVR-GCC website: http://winavr.sourceforge.net/
Atmel AVR Raven datasheet: http://www.atmel.com/dyn/resources/prod_documents/doc8117.pdf
Atmel ATmega1284P datasheet: http://www.atmel.com/dyn/products/product_card.asp?part_id=4331

Problemen met de hardware

We hadden het plan om eerst vast te stellen dat we de gekozen software (Operating System) werkend zouden krijgen voordat we de hardware gingen bestellen. Dit om de hardware voor ons toch een aanzienlijke uitgave was. Wel hadden we al gekeken wat dit zou gaan kosten en waar het te bestellen was. Toen we daadwerkelijk hadden vastgesteld dat de software zou werken zijn we de hardware gaan bestellen. Nadat we de bestelling de deur uit hadden gedaan kregen we deze echter retour. De fabrikant (Atmel) wilde ons niet tegen de prijs die we verwacht hadden leveren omdat we geen bedrijf zijn waaraan de fabrikant kan verdienen. Hierdoor kregen we de programmer en verzendkosten niet gratis.

Omdat de nieuwe kosten voor ons studenten veel te hoog zijn, zijn we in overleg gegaan. We hadden de optie om een ander onderwerp te kiezen wat relateert was aan ons huidig onderwerp, zo kwamen we bijvoorbeeld op het idee om ons te richten op het plannen van events in de thuisomgeving. Zodat bijvoorbeeld automatisch de koffie is gezet als de wekker gaat. Later kregen we te horen dat er ook nog een mogelijkheid was om door te gaan met het huidig onderwerp omdat de universiteit misschien de hardware wilde sponsoren. Door deze onduidelijkheid in het onderwerp is uit de pilot niet zo veel gekomen als we hadden gewenst: We hadden graag wat meer onderzocht maar zijn hier voortijdig mee gestopt omdat we dachten dat het onderwerp niet maar haalbaar was.

Overgenomen van "https://lab.cs.ru.nl/algemeen/index.php?title=Research_and_Development_1/%5EArchief/2009-2010/04/Pilot/Verslag&oldid=131221"