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

Uit Werkplaats
Ga naar: navigatie, zoeken
Bagjoke.jpg

Research and Development 1

Patrick van Bommel
Sjaak Smetsers


 © comments




Pilot

In fase 1 en fase 2 proberen we een koffiezetapparaat aan het internet te koppelen. In de pilot gaan we uitzoeken op welke manier we dit het beste kunnen realiseren. We kijken hierbij onder andere naar:

  • Gebruiken we IPv4 of IPv6?
  • IPv6 mogelijkheden als 6LowPAN: is dit te prefereren boven wifi?
  • Gebruiken we een bestaand systeem, zoals Tiny OS of Contiki OS, en zo ja: welke?

In de pilot zullen we beargumenteren welke keuzes we gemaakt hebben. In fase 1 kunnen we vervolgens onderzoeken of dit de juiste keuzes waren.

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 Inernet Of Things zijn twee dingen noodzakelijk: Alle artefacten moeten een IP-adres kunnen krijgen, en alle artefacten moeten direct te adresseren zijn.

Met IPv4 gebruik je standaard een 24 bits subnet. Hierdoor blijven er slechts 8 bits over, waarmee je slechts 256 adressen kunt maken. Gezien een huisomgeving meer dan 256 artefacten kan bevatten (denk aan lampen, stopcontacten, schakelaars, electronica), is dat niet genoeg. Met IPv6 zijn er in een subnet nog 2^64 mogelijke adressen. Dat zijn er veel meer, en dat is dus de eerste reden waarom wij voor IPv6 kiezen.

Door de grote hoeveelheid mogelijke IPv6 adressen, is Network Adress Translation in tegenstelling tot bij IPv4 niet meer nodig. Dit betekent dat alle artefacten direct te adresseren zijn. Dit is ook en reden voor ons om voor IPv6 te kiezen.

Door de vele voordelen is het ook vrij zeker dat dit de nieuwe standaard gaat worden. Als we IPv6 gebruiken zijn we dus voorbereid op de toekomst, en dat is een mooi voordeel.

We gebruiken dus 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. We kiezen voor ons project dus voor het gebruik van 6LoWPAN.

Bronnen

OS en platform

Platform

Om te voorkomen dat we het wiel totaal opnieuw moeten uitvinden zijn we opzoek gegaan naar een framework/OS om onze applicatie op te bouwen en een hardware platform. Aangezien er gekozen is voor IEEE 802.15.4, is er gekeken naar welke hardware platforms aanwezig zijn die de 802.15.4 standaard ondersteunen. Hierbij kwamen de volgende developmentboards 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 beschikbaar is wat de ontwikkelingskosten naar beneden brengt.

OS

We hebben er 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. Daarom is besloten om op zoek te gaan naar een abstractielaag in vorm van een OS of Hardware Abstraction Layer. Hierbij kwamen een aantal oplossingen naar voren:

  • 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 dus energie zuinig.
  • Bied een goede development omgeving en veel documentatie en voorbeelden.

Begroting

Atmel Raven Development Kit: DigiKey 102.96 USD
Atmel JTAG ICE mk II programmer: Digikey 310.96 USD (misschien al aanwezig op de universiteit?)
Koffiezet apparaat: 30 EUR