6LoWPAN

6LoWPAN je zkratka pro IPv6 Low power Wireless Personal Area Networks nebo IPv6 LoW Power wireless Area Networks .

Je to také název pracovní skupiny IETF . Skupina 6LoWPAN definovala mechanismy zapouzdření a komprese záhlaví umožňující odesílání nebo přijímání paketů IPv6 prostřednictvím komunikačního protokolu IEEE 802.15.4 . Protokoly IPv4 a IPv6 jsou účinné pro doručování dat do místních sítí , metropolitních sítí a rozsáhlých sítí , jako je internet . Je však obtížné je implementovat do síťových senzorů a jiných omezených systémů, zejména kvůli velké velikosti hlaviček. 6LoWPAN by měl umožnit IPv6 integrovat tento omezený počítačový hardware a sítě, které je propojují.

Základní specifikace vyvinutá skupinou 6LoWPAN je známá ve formě dvou hlavních RFC  :

  1. Hlavním dokumentem pro toto vydání je RFC 4919 .
  2. Samotná specifikace je předmětem RFC 4944 .

Popis technologie

LoWPAN je tvořen sadou zařízení s několika zdroji ( CPU , paměť, baterie) připojenými k síti s omezenou rychlostí (až 250 kbit / s). Tyto sítě se skládají z velkého počtu prvků.

Ve standardu 802.15.4 je maximální velikost PSDU ( datová jednotka služby fyzické vrstvy ) 127 bajtů. S 25 bajty podvrstvy MAC (bez zabezpečení) to má za následek 102 bajtů na úrovni odkazu. Přidáním zabezpečení vrstvy datového spojení ( AES -CCM-128) zbývá na úrovni IP k dispozici pouze 81 bajtů. Musíte také vzít v úvahu přetížení v důsledku záhlaví IPv6 (40 bajtů), jakýchkoli záhlaví rozšíření, UDP (8 bajtů) nebo TCP (20 bajtů). Nakonec jsou užitečná data nízká (33 bajtů na UDP a 21 na TCP, viz obrázek níže) a neumožňují soulad se specifikacemi IPv6, které ukládají minimální MTU 1280 bajtů.

Aby bylo možné přizpůsobit podporu standardu 802.15.4, musí zařízení fragmentovat paket IPv6 do více rámců 802.15.4 a vzdálené zařízení musí znovu sestavit všechny přijaté rámce 802.15.4, aby se obnovil původní paket IPv6. Tyto úkoly spotřebovávají prostředky (paměť a CPU ) a generují latenci (ukládání do vyrovnávací paměti, čas vytvoření / ověření záhlaví).

Problémy spojené s LoWPAN jsou:

Fragmentace a opětovné sestavení omezení velikosti paketů uložená protokoly IPv6 a 802.15.4 představují problém nadměrné fragmentace / opětovného sestavení. Komprese záhlaví IPv6 se současnou hlavičkou IPv6 (40 bajtů) se užitečné zatížení sníží. Komprese záhlaví IPv6 je proto nutností pro optimalizaci datových přenosů v síti 6LoWPAN. Směrování Sítě LoWPAN se skládají z mnoha uzlů. Jsou organizovány v „síťové“ (multi-hop) nebo hvězdné topologii. Musí být zaveden směrovací protokol na podporu těchto sítí. Musí také splňovat omezení samotných uzlů (nízká CPU a paměť) i omezení 802.15.4 (nízká rychlost a malé pakety). Zařízení 802.15.4 jsou díky své velikosti snadno přenosná. Je proto třeba zohlednit mobilitu. Automatická konfigurace IP Doporučuje se bezstavový typ automatické konfigurace adresy IPv6 (SLAAC, RFC  4862), protože snižuje namáhání zařízení. To vyžaduje generování identifikátoru rozhraní typu EUI-64 nebo 16bitového krátkého typu na zařízeních. Dohled a správa sítě dohled / správa nad sítí 6LoWPAN je zásadním prvkem. SNMP ( RFC  3410) je již široce používán v sítích IP a má tu výhodu, že má velké množství stávajících nástrojů. Vzhledem k omezením stanoveným normou 802.15.4 a charakteristikám zařízení zbývá určit vhodnost protokolu SNMPv3 pro 6LoWPAN. Omezení pro „vysoké“ aplikace Vzhledem k vlastnostem LoWPAN nemusí být aplikace náročné na zdroje nutně vhodné. Může proto být nutné přizpůsobit aplikace omezením LoWPAN (prostředky zařízení, propustnost a zmenšená velikost paketu na 802.15.4). Bezpečnostní za účelem kontroly integrity dat přenášených přes síť 6LoWPAN by mělo být kromě úrovně poskytované IEEE 802.15.4 (prostřednictvím AES ) implementováno zabezpečení přenosu dat na úrovni IP .

Fragmentace a opětovné sestavení

Adaptační vrstva 6LoWPAN je umístěna mezi síťovou vrstvou a linkovou vrstvou modelu OSI . Přijímá pakety IPv6 o velikosti 1 280 bytů ze síťové vrstvy a odesílá je na ekvivalent na vzdáleném zařízení v rámcích 802.15.4. Protože tyto rámce mají pouze 81 bytů volných ( viz Popis technologie ), musí adaptační vrstva fragmentovat pakety IPv6 před jejich odesláním a opětovným sestavením na recepci.

Každému fragmentu předchází záhlaví fragmentace o velikosti 4 nebo 5 bajtů. Tato hlavička obsahuje následující informace:

Pokud dojde ke ztrátě pouze jednoho fragmentu, paket IP nelze rekonstruovat. Problém tohoto mechanismu fragmentace spočívá v tom, že poté bude nutné znovu vydat všechny fragmenty.

K překonání tohoto problému byl navržen mechanismus pro získání fragmentů. Zavádí novou hlavičku fragmentace a především mechanismus potvrzení fragmentu. Potvrzení umožňuje odesílateli znovu vyslat pouze fragmenty, které nebyly přijaty (nepotvrzeny).

Komprese záhlaví

V RFC 4944 definuje IPv6 komprese záhlaví mechanismus LoWPAN: LOWPAN_HC1. Integruje také kompresi záhlaví UDP na 4 bajtech, ale neumožňuje kompresi kontrolního součtu . Kromě toho omezuje rozsah portů UDP od 61616 do 61631 za účelem komprese této hodnoty na 4 bity.

Tuto kompresi záhlaví IPv6 lze použít pouze k propojení místních adres. K překonání tohoto problému byl zveřejněn koncept IETF LOWPAN_HC1g. LOWPAN_HC1g platí pro globální adresy pro vícesměrovou komunikaci IP. Tyto dva kompresní mechanismy (LOWPAN_HC1 a LOWPAN_HC1g) se vzájemně doplňují. Je proto nutné provést obojí.

Dnes navrhuje skupina 6LoWPAN používat LOWPAN_IPHC. Umožňuje nahradit LOWPAN_HC1 a LOWPAN_HC1g. Bajty IPHC jsou výsledkem komprese záhlaví IPv6. Integrují hlavně informace o kvalitě služeb ( DSCP a ECN ), další záhlaví, počet přeskoků a komprimované adresy zdroje / cíle.

U LOWPAN_IPHC závisí rychlost komprese na typu komunikace:

Níže uvedený příklad ukazuje zvýšení užitečného zatížení v porovnání s původní problém (viz 1 st  obrázek). Toto užitečné zatížení je v ideálním případě 70 až 75 bajtů. Ve skutečnosti, pokud přidáme informace o fragmentaci, jak je uvedeno v předchozím odstavci, v tomto případě se sníží na 65-70 bajtů.

Bajt Dispatch má stejnou funkci jako EtherType , používá se k určení typu paketu nad 802.15.4.

Tabulka 1: Některé příklady možných hodnot pro odesílací bajt.
Hodnota význam

01000001

nekomprimovaný paket IPv6

01010000

Vysílat LoWPAN

11000xxx

první fragment

11100xxx

fragment

11110CPP

Záhlaví UDP

LOWPAN_NHC je navrženo pro kompresi transportní vrstvy. Kromě toho, aby se zabránilo přetížení používání portů UDP a především aby se zkontrolovala integrita zpráv, se doporučuje přidružit přenosy na těchto portech s TLS ( Transport Layer Security ) ( RFC 5246 ). Komprese kontrolního součtu je nyní možná, ale je povolena pouze v případě, že horní vrstva používá tunelování (například: IPsec Encapsulating Security Payload tunelový režim ( RFC 4303 ).

Je však zadán pouze UDP. Byly proto předloženy další návrhy ke kompresi TCP a ICMP. Je proto nutné určit kompresi každé nové hlavičky. K překonání tohoto problému se zrodila 6LoWPAN_GHC. Cílem tohoto nového návrhu je komprimovat jakýkoli typ záhlaví.

Směrování

Schéma směrování 6LoWPAN lze implementovat dvěma různými způsoby: mesh-under a route-over .

Mesh-under spočívá v implementaci směrování na úrovni adaptační vrstvy (která probíhá mezi linkovou vrstvou a síťovou vrstvou modelu OSI ), zatímco route-over provádí tuto implementaci na úrovni síťové vrstvy (viz směrovací diagram 6LoWPAN). Při směrování se paket IPv6 rekonstituuje na každém prostředním zařízení, aby bylo možné provést rozhodnutí o směrování. Naopak v mřížce pod je rozhodnutí o směrování prováděno na úrovni 6LoWPAN, a proto pouze s fragmenty paketu IPv6. V tomto případě je paket IPv6 rekonstituován pouze na cílovém zařízení. Proto:

Byly navrženy vylepšené verze sítě mesh-under a route-over:

Zpočátku komunita 6LoWPAN vyvinula několik směrovacích protokolů, například LOAD, DYMO-LOW, HI-LOW.

Dnes jsou pro velká nasazení legitimní pouze dva protokoly:

Problémy se směrováním pro takové sítě jsou definovány v:

RPL je směrovací protokol IPv6 na dálku, který vytváří DAG ( Directed Acyclic Graph ) (viz diagram DAG). Je implementován na trase .

LBR znamená Low Power and Lossy Network Border Router . LBR, úrovně 1, je zdrojem směrovaného acyklického grafu, který je konstruován výše uvedeným protokolem RPL. LBR a všechna zařízení na vyšší úrovni tvoří DODAG (z anglického Destination-Oriented Directed Acyclic Graph , „destination-oriented acyclic graph“). LBR odesílá informační zprávu DIO ( informační objekt DODAG , " informační objekt DODAG ") ve vícesměrovém vysílání . Když zařízení obdrží novou verzi DIO, vypočítá zejména svou hodnost (ve vztahu k té, kterou právě přijalo) a šíří své DIO. Při pohledu ze zařízení mohou všechna zařízení s nižším hodnocením tvrdit, že jsou rodiči. Optimální trasy („rodiče“) v rámci DAG jsou získány z metrik a omezení.

LBR pravidelně vydává DIO k aktualizaci DAG. Když se zařízení připojí k síti nebo ztratí odkaz na svého „rodiče“, může počkat na další DIO (od minuty do hodiny) nebo požádat o odeslání DIO pomocí výzvy DIS (z anglického DODAG Information Solicitation , „ DODAG Information Solicitation “). DIO zprávy se odesílají pomocí algoritmu Trickle. Tento algoritmus definuje hlavně dvě věci:

V roce 2010 ukázaly testy implementace RPL na operačním systému Contiki, že toto řešení bylo ekonomické z hlediska paměti, energie a že takto vytvořené sítě bezdrátových senzorů mohly s touto implementací fungovat několik let. Pokud je spotřeba paměti klíčovým kritériem, je třeba poznamenat, že tato implementace spotřebovala 8% dostupné paměti s náhodným přístupem, aby byla zajištěna implementace RPL v prostředí složeném z 10 sousedů. Množství paměti jen pro čtení pro ukládání programu bylo také považováno za nezanedbatelné.

RFC 4861 označuje mechanismus ND (v angličtině Neighbor Discovery , „soused Discovery“) pro automatickou konfiguraci IPv6 adresy na zařízení. Tento mechanismus indukuje intenzivní používání vícesměrových zpráv , nelze jej použít jako v sítích 6LoWPAN.

Z tohoto pozorování zveřejnila pracovní skupina IETF 6LoWPAN návrh optimalizace ND za účelem odlehčení procesu autokonfigurace, ať už je LoWPAN směrován v mřížce pod nebo v směrování trasy.

Vzhledem k tomu, že zařízení 6LoWPAN nejčastěji „spí“, bylo vyvinuto zvláštní úsilí k omezení zpráv RS ( zkratka pro Router Solicitation , „router solicitation“) odesílaných ve vícesměrovém vysílání. Tato optimalizace se provádí pomocí zpráv RS pouze k vyhledání platných výchozích směrovačů během inicializace zařízení nebo od okamžiku, kdy je výchozí směrovač považován za nedosažitelný. Jedním ze způsobů, jak omezit vícesměrové vysílání, je mimo jiné nespuštění DAD (zkratka pro detekci duplicitních adres ) při použití EUI64.

Za správu předpony adresy IPv6 odpovídá LBR (zkratka pro Low power and lossy network Border Router ).

Výchozí směrovače spravují tabulku NCE (zkratka pro Entry Cache Entry , „položka tabulky cache s výpisem sousedů“), kde jsou uvedeny všechny adresy sítě 6LoWPAN. Pokud se během obtěžování adresa nenachází v mezipaměti, považuje se za platnou a je uložena s hodnotou „doživotní“. V NCE jsou uloženy tři typy adres:

Výchozí nastavení, přizpůsobené obdobím „spánku“ zařízení LoWPAN, umožňuje udržovat jejich platné adresy mezi dvěma „probuzeními“. Tato metoda umožňuje nepenalizovat zařízení z hlediska spotřeby energie a vyhne se restartování autokonfigurace při každém probuzení.

Tyto prvky jsou implementovány v Nové ND : tato zpráva obsahuje ARO (pro možnost registrace anglické adresy ), ARO umožňuje LBR správně udržovat své NCE, protože je vydáváno pravidelně zařízením, které přenáší životnost jeho adresy na LBR.

V případě sítě směrované v trase přes LR (z anglického Low power and lossy network Router , „network router, of low power and with loss“) a LBR exchange ABRO (z anglického Autoritativní Border Router Option , „ volba autorizovaného hraničního směrovače “), tyto zprávy typu RA nesou předpony adres, kontextové informace a adresu LBR. Kromě toho se víceskokové výměny DAD mezi LR a LBR provádějí na dvou nových zprávách ICMPv6, DAR (zkratka pro Duplicate Address Request ) a DAC (zkratka pro Duplicate Address). Potvrzení , „potvrzení dvojité adresy“).

V roce 2009 byl proveden bezstavový experiment s autokonfigurací pomocí adres LoWPAN o délce 16 bitů: konstrukce adresy na začátku zařízení byla provedena na třech distančních vektorech v chmelu směrem ke třem referenčním „koordinátorovým“ zařízením (zelená, modrá a Červená) a náhodné hodnoty. Analogie byla převzata s definicemi barev: tři vektory vzdálenosti k odkazům Zelená, Modrá a Červená.

v ledna 2011, stavový návrh automatické konfigurace vedl k vývoji LISAA (zkratka pro Lightweight IPv6 Stateful Address Autoconfiguration „light and dynamic IPv6 address autoconfiguration“).

LBR pracuje v režimu proxy a má skupinu 16bitových adres k distribuci v LoWPAN. Tato skupina je rozdělena do bloků, které jsou samy rozděleny do dílčích bloků. Tyto členění vytvářejí hierarchické rozdělení bloků adres, které se řídí topologií LR. Experiment s LISAA ukázal nízkou latenci v automatické konfiguraci a nízkou režii záhlaví. Na druhou stranu byla pomalá reakce zaznamenána při pohybu zařízení.

Implementace technologie RFID v rámci senzorů tvořících součást sítě 6LowPAN by umožnila snížit spotřebu elektrické energie těchto senzorů, a to díky zjednodušení fáze jejich zjišťování a registrace v síti 6LowPAN.

Mobilita

Pokud se zařízení pohybuje v rámci LoWPAN (intra LoWPAN mobility) a neztratí připojení s CFD ( Coordinator-Function Device ), není to nutné. Tuto mobilitu není nutné spravovat, protože směrovací protokol to může podporovat.

Na druhou stranu, když se zařízení přesune z jednoho LoWPAN do druhého (interní mobilita LoWPAN), je nutné tento typ mobility konkrétně spravovat. K tomu je navrženo několik scénářů:

Ke správě případů, kdy se pohybují všechna zařízení LoWPAN ( síťová mobilita ), je nutné implementovat protokol NEMO ( RFC 3963 ) v 6LoWPAN.

Dohled a správa sítě

Dohled nad sítí LoWPAN je zajištěn z aplikačního serveru ( NMS ) umístěného v doméně IPv6. Požadavky protokolu SNMP ( Simple Network Management Protocol) odeslané monitorovacím serverem na různá zařízení nejsou přizpůsobeny omezením LoWPAN: mají příliš velké velikosti balíčků a je jich příliš mnoho.

6LoWPAN-SNMP

Návrh 6LoWPAN-SNMP byl vypracován na základě probíhajících prací na IETF. Skládá se z použití proxy (ze serveru proxy), které přenáší pakety IPv6 přicházející z Internetu do sítě LoWPAN komprimací požadavků SNMP a jejich odesláním ve vysílání nebo vícesměrovém vysílání ( metoda BroadcastGetRequest ) k omezení obsazení šířky pásma  : opakující se požadavek společný pro několik zařízení LoWPAN je odeslán pouze jednou proxy místo toho, aby bylo úspěšných několik jednotlivých požadavků ( unicast ), které by nakonec ucpaly LoWPAN.

Aby se omezilo zatížení zařízení, navrhuje se použít předponu pro OID ( zkratka pro Object Identifier ) namísto jejich úplné stromové struktury. Například jeden bajt se používá k definování ekvivalentu 255 stromů OID odpovídajících 255 podnikovým MIB .

Architektura dohledu

Byly definovány dvě architektury umožňující správu sítě LoWPAN, jedna provozní a druhá informační. Jsou seskupeny pod termínem LNMP (zkratka pro LoWPAN Network Management Protocol , „LoWPAN network management protocol“).

Provozní architektura je definována na třech úrovních:

Koncové zařízení Zařízení FFD ( plně funkční zařízení ) nebo RFD (zařízení se sníženou funkcí) připojená v kapiláře za koordinátorem. Koordinátor Zařízení schopné spravovat funkce směrování 6LoWPAN. Brána Koordinátor vybavení pro PAN (PAN Coordinator), rozhraní s IPV6. Analyzuje požadavky SNMP z aplikace NMS (Network Management System). Spravuje, zda má nebo nemá být požadavek odeslán do LoWPAN. Například pokud má hodnota požadovaná v požadavku SNMP konstantní hodnotu v LoWPAN, odešle výsledek přímo do NMS, aniž by předala zprávu cílovému zařízení; jinak přenese požadavek na určené zařízení a v případě potřeby jej fragmentuje ve formátu 6LoWPAN.

Informační architektura je založena na PIB (PAN Information Base) již určeném pro úrovně PHY a MAC 802.15.4 , poté je založena na návrhu IETF MIB pro tři domény (viz strom LNMP MIB):

Pokud jde o správu protokolu Mv IPv6 ( RFC 4293 ), definuje přizpůsobení „ povinných  “ tabulek  spravovanému LoWPAN:

Ipv6IpForwarding konstantní a hodnoty 2 ( notForwarding ), zařízení se nepovažují za směrovače. Ipv6IpDefaultHopLimit lze považovat za konstantu v závislosti na architektuře spravovaného LoWPAN. IpAddressPrefix spravováno na LNMP Gateway.

Pro OID tabulky ipv6Interface je v současné době extrémně vzácné, že zařízení má více než jedno rozhraní, tyto OID se stanou irelevantní a další tabulky jako ipAddressTable a ipNetToPhysicalTable jsou považovány za volitelné.

Správa sítě

Na základě b6LoWPAN (Berkeley6LoWPAN Implementation, nyní nazývaného BLIP) byl vyvinut agent 6LoWPAN-SNMP. Skládá se ze 4 komponent:

zpráva dispečera Odesílání a příjem zpráv 6LoWPAN-SNMP, kontrola verze SNMP pro zprávu procesoru . procesor zpráv Zpracování zprávy podle verze SNMP. zpráva respondenta Generování paketu SNMP odeslaného zpět na server NMS spravuje časový limit umožňující simulovat postupné reakce různých zařízení v případě návratu po metodě Broadcast PeriodicGetRequest . Složka MIB Implementace MIB v zařízení.

Byl navržen tak, aby omezil počet zpráv, jejich velikost a tím i zatížení zařízení.

U všech experimentů se správou SNMP LoWPAN se ukázalo, že použití Gateway / Proxy umožnilo správně propojit domény IPv6 a LoWPAN, překlad SNMP IPV6 na vstupu nebo výstupu do 6LoWPAN umožňuje dohled nad sítí do hloubky. Na druhou stranu musí být zařízením povolena průměrná doba odezvy 100 až 150  ms, než je bude možné považovat za Time Out . Důvodem jsou komprese, překlady a fragmentace prováděné za účelem přizpůsobení SNMP na 6LoWPAN.

Omezení pro „vysoké“ aplikace

Od roku 2005 se navrhuje používání Webservices jako aplikace pro sítě LoWPAN. V roce 2008 se ukázalo proveditelnost protokolu SOAP v LoWPANech. Jiné aplikace IP mohou fungovat na 6LoWPAN, jako je SNMP (viz odstavec výše) nebo RTP . V roce 2009 pak vyhodnocení výkonu mezi REST a SOAP na LoWPAN prokázalo účinnost REST ve srovnání s SOAP a že použití jazyka JSON ( RFC 4627 ) může být výhodné, protože XML je pro LoWPAN příliš podrobné. Téhož roku chtěl SENSEI (projekt založený na XML M2M middleware ) věnovat své úsilí a práci vývoji aplikací na 6LoWPAN.

v července 2009IETF definuje problémy pro aplikace v sítích 6LoWPAN níže:

  • Zařízení LoWPAN mají často několik kB paměti RAM a velikost kódu je omezena na 48 kB až 128 kB. Na úrovni aplikace je 50-60 bajtů užitečného zatížení kódu. Jejich generování a interpretace vyžadují příliš mnoho zdrojů pro 8bitové a 16bitové procesory (dominantní v síťových zařízeních LoWPAN);
  • použití UDP v LoWPAN je časté, protože TCP je mnohem složitější implementovat kvůli limitům určitých systémů a ztrátě paketů na LoWPAN;
  • Využití UDP a velikost paketů přenášených přes LoWPAN ukazují, že hovorné protokoly, jako je HTTP, nejsou žádoucí. Ale použití určitých webových konceptů, jako jsou URI ( zkratka pro Uniform Resource Identifier ), MIME ( zkratka pro Multipurpose Internet Mail Extensions , „víceúčelová rozšíření pro internetovou poštu“), proxy atd. jsou žádoucí. Na takové architektuře může být proveditelné shrnutí protokolu HTTP samostatně nebo s využitím XML a služeb SNMP;
  • Na EDGE router zařízení se zvyšují výkon Proxy  (en) (ve francouzštině „proxy server se zlepšeným výkonem“, známý také pod zkratkou PEP) ( RFC 3135 ), by mohly být zavedeny s cílem zlepšit spojení mezi Internetem a LoWPANs konverzí protokolů (například HTTP / TCP na straně Internetu a CoAP na straně LoWPAN). Přidružení systému mezipaměti k těmto stejným zařízením by umožnilo omezit doby odezvy, snížit provoz na LoWPAN a proto optimalizovat prostředky zařízení;
  • za účelem zjednodušení uvedení do provozu ( provoz plug-and-play a bootstrapping ) bude pravděpodobně použit protokol zjišťování služeb, jako je SLP ( zkratka pro Service Location Protocol ), optimalizovaný pro LoWPAN. Mělo by být implementováno zjišťování služeb pro zařízení, která většinu času spí ( zjišťování služby ).

Kromě toho musí aplikace umožňovat propojení s dalšími standardy, jako jsou: ZigBee, DPWS , M2M , XML , EXI atd. a zajištění bezpečnosti a mobility.

v března 2010, IETF zahájila novou pracovní skupinu nazvanou CORE ( Constrained RESTful Environments ). Cílem této pracovní skupiny je rozšířit architekturu webu na LoWPAN. Tato pracovní skupina začala definovat protokol WebService pro LoWPAN nazvaný COAP ( Constrained Application Protocol ).

COAP je protokol RESTful s následujícími hlavními charakteristikami:

  • architektura klient / server;
  • REST architektura;
  • přes UDP;
  • asynchronní transakční model;
  • podpora URI a MIME;
  • jednoduchá a malá hlavička (méně než 10 bajtů);
  • nastavení systému proxy a systému „cache“;
  • používá pro zabezpečení DTLS ( RFC 4347 ).

COAP definuje 4 typy transakčních zpráv. Jsou přenášeny v režimu peer-to-peer a každá transakce je identifikována pomocí ID transakce (TID):

  • Potvrditelné (CON): Po přijetí zprávy CON je vrácena zpětná zpráva typu ACK nebo RST. Zpráva CON má vždy buď požadavek, nebo odpověď a nesmí být prázdná;
  • Nepotvrzitelné (NCN): používají se pro zprávy, které nevyžadují ACK / RST (například zprávy, které se pravidelně opakují kvůli požadavkům aplikace). Zpráva NCN vždy nese požadavek nebo odpověď a nesmí být prázdná;
  • Potvrzení (ACK): Zpráva ACK musí odrážet zprávu CON bez označení úspěchu nebo neúspěchu požadavku a musí být zodpovězena nebo musí být prázdná;
  • Reset (RST): Zpráva RST musí odrážet zprávu CON a indikuje příjemci, že požadavek nebyl pochopen a musí být prázdný.

Definuje čtyři typy zpráv metod. Jsou podobné protokolu HTTP. Každý zdroj je identifikován svým identifikátorem URI:

  • GET: Načte informace ze zdroje identifikovaného URI;
  • POST: Vytvořte nový zdroj podle požadavku URI;
  • PUT: Aktualizuje prostředek identifikovaný URI;
  • DELETE: Odstraní prostředek identifikovaný identifikátorem URI.

Zprávy CoAP mají pevnou čtyřbajtovou hlavičku, případně následovanou možnostmi Type-length-value  (en) (francouzsky „Type-length-value“, známá pod zkratkou TLV):

  • Ver (2 bity): udává číslo verze CoAP (aktuálně 1);
  • T (2 bity): označuje typ zprávy (CON = 00, NCN = 01, ACK = 10 a RST = 11);
  • OC (4 bity): označuje počet možností za záhlaví, pokud 0 znamená, že neexistují žádné možnosti, a proto po záhlaví je užitečné zatížení;
  • Kód (1 bajt): Označuje, zda je zpráva požadavek (hodnota od 1 do 31), odpověď (hodnota od 64 do 191) nebo prázdná (0);
Příklad použití kódového bajtu.
v případě požadavku případ reakce
Kód hodnoty Metoda HTTP Kód hodnoty Stavová odpověď HTTP
1 DOSTAT 65 201 - Vytvořeno
2 POŠTA 66 202 - smazáno
3 DÁT 68 204-změněno
4 VYMAZAT 69 205-Šťastný
131 403 Přístup odepřen
  • ID zprávy nebo TID (2 bajty): identifikátor zprávy používaný ke správě korespondence zpráv a odpovědí CON (ACK nebo RST) a také k detekci duplikací.

COAP URL je typu: „  coap://serveur[:port]/ressources “.

Formát webového odkazu prostředku CORE je rozšířením formátu záhlaví odkazu HTTP RFC 5988 . Každý odkaz nese cíl prostředku LoWPAN, kterého chceme dosáhnout (například teplota na čidle). Tento cíl je URI, jak je definováno v RFC 3986 . Objev zdrojů, jejich atributů a jejich vztahů v LoWPAN pomocí CORE jsou definovány takto:

  • Rozšíření formátu záhlaví HTTP Link pro CORE:
    • atribut „rt“: přidruží řetězec znaků ke konkrétnímu zdroji (například teplotě);
    • atribut „if“: přidruží řetězec znaků k rozhraní sdružujícímu několik zdrojů (například prostředí, které by se rovnalo teplotě + vlhkosti +…);
    • atribut „ct“: označuje typ média (příklad ct = 41 odpovídá XML, 47 až EXI, 50 JSON…);
    • atribut „sz“: označuje velikost zdroje v bajtech.
  • Specifické rozhraní  /.well-known/core specifikované v RFC 5785 umožňuje objevování zdrojů v JÁDROCH.
  • Možnost zadávání požadavků filtrováním požadovaných zdrojů (například aby bylo možné dosáhnout atributu „rt“ s hodnotou teploty :) GET /.well-known/core?rt=temperature.

Stav zdroje na senzoru (server COAP) se může v průběhu času měnit (například vývoj teploty). Abychom udrželi krok s tímto vývojem, poskytuje IETF pro COAP jednoduché rozšíření, které klientům dává příležitost takové změny pozorovat.

Protože COAP je založen na přenosu datagramu 6LoWPAN, omezuje to maximální velikost informací o prostředcích, které lze přenést bez fragmentace. Aby bylo možné odesílat data větší než je možné užitečné zatížení, byl implementován mechanismus fragmentace dat s názvem „blokově“. Je založen na volitelném poli záhlaví CoAP.

Kromě toho se studují další oblasti zlepšování CoAP:

  • u mechanismů zjišťování serverů COAP probíhají různé cesty, některé sofistikované nebo jiné, jejichž implementace je velmi jednoduchá.
  • použití Compress-IPFIX, derivátu protokolu IPFIX ( RFC 5101 ), je možné minimalizovat přenos aplikačních dat v sítích 6LoWPAN;
  • vytvoření systému kontroly přetížení;
  • osvědčené postupy pro korespondenci HTTP-CoAP;
  • vývoj systému seskupování komunikací CoAP (například pro měření teploty všech senzorů v 1. patře budovy 1: "  coap://all.etage1.bat1/rt=temperature "). Tento systém využívá vysílací mechanismus Multicast MLD ( RFC 3810 ), podporovaný směrovacím protokolem RPL. Distribuce stromu vícesměrového vysílání může být interní v LoWPAN nebo prostřednictvím Internetu. V druhém případě je zásadní nastavení proxy ( RFC 4605 ).
  • použití CoAP pro automatizaci a řízení budov (BAC );
  • zdokonalení jazyků WebServices pro CoAP.
  • nastavení adresářové služby prostředků k usnadnění zjišťování služeb na zařízení 6LoWPAN, zjišťování služby DNS.

Bezpečnostní

Zabezpečení 6LoWPAN musí umožňovat zaručení důvěrnosti dat, jakož i jejich integrity a dostupnosti sítě. Byly zdůrazněny různé možnosti útoků na sítě 6LoWPAN, které jsou rozděleny do dvou kategorií:

  • Externí útoky: pasivní vnější útok: například poslech s úmyslem objevit citlivé informace. (otázka důvěrnosti) aktivní vnější útok: příklad, dělá odmítnutí služby prostřednictvím rušení radiového signálu v pořadí paralyzovat sítě (dostupnost problém)
  • Interní útoky: příklad: infiltrace do LoWPAN za účelem shromažďování nebo šíření informací pro škodlivé účely (problémy s integritou, důvěrností a dostupností)

Aby byla komunikace na 6LoWPAN co nejbezpečnější, musí být zabezpečení implementováno v různých vrstvách zásobníku protokolu.

  • Na vrstvě MAC  : k zabezpečení vrstvy propojení je třeba použít algoritmus AES .
  • Na síťové vrstvě  : použití protokolu IPsec je možné, ale šifrování spotřebovává mnoho zdrojů a nelze použít metodu výměny klíčů IKEv2 ( RFC 5996 ). Předpokladem je správa šifrovacího klíče využívající minimální užitečné zatížení a také omezení zpráv vyměňovaných mezi uzly. Pro sítě 6LoWPAN bylo implementováno rozšíření protokolu SEND ( RFC 3971 ) ( zkratka pro SEcure Neighbor Discovery Protocol ) pro zabezpečení mechanismu zjišťování sousedů, nazývané LSEND (z anglického Lightweight Secure Neighbor Discovery Protocol , „Lightweight SEND“).
  • Na aplikační vrstvě  : například jedním z řešení je nastavení zabezpečení pomocí SSL .

Byly předloženy různé návrhy k optimalizaci zabezpečení 6LoWPAN, například:

  • použití možností „ Časové razítko “ a „Nonce“ záhlaví IPv6 k ochraně sítí 6LoWPAN proti útokům fragmentace IP  (in) (ve francouzštině: „útoky na fragmentované pakety IP“)
  • komprese záhlaví IPsec pro optimalizaci užitečného zatížení.
  • implementace middlewaru umožňující analýzu bezpečnostních rizik v 6LoWPAN.
  • optimalizace šifrování.

Historie 6LoWPAN

Technologický vývoj 90. let (miniaturizace elektroniky, nasazení nových bezdrátových sítí a palubních systémů) umožnil vznik nových aplikací pro sítě senzorů a akčních členů. S příchodem bezdrátových technologií byla první použitá řešení zcela proprietární (např. Z-WAVE nebo EnOcean). Se standardem IEEE 802.15.4 (rádiové použití bezdrátových senzorů) se objevily nové proprietární standardy (např. ZigBee , Wireless-HART atd.).

Během prvních úvah o propojení bezdrátových senzorů v síti se 6LoWPAN zrodil z jednoduchého nápadu: „proč znovu objevit protokol, když již máme IP? ".

2001 Geoff Mulligan navrhuje použití IP přes 802.15.4 pro zařízení typu senzoru. Přestože po obdržení nepříznivou odezvu od několika skupin, jako je ZigBee, jiní, jako je Internet 0  (en) z MIT je centrum pro Bity a atomů  (en) nebo ROHC (z angličtiny robustní Compression Header) pracovní skupina , ‚komprese Robustní záhlaví‘ ) IETF . 2005
  • Mezinárodní telekomunikační unie (ITU) zveřejňuje téma o internetu věcí, na které se dnes odkazuje.
  • IETF vytvoří skupinu 6LoWPAN konkrétně pracovat na téma implementace IP v bezdrátových senzorových sítí.
2007
  • Maher Chebbo, člen „Evropské technologické platformy Smart Grid“, naznačuje, že  elektrické „  inteligentní sítě “ integrující „inteligentní objekty“, které umožňují řídit a optimalizovat spotřebu elektřiny, jsou strategické.
  • USA zahajují program na podporu rozvoje inteligentních sítí pro modernizaci systému přenosu a distribuce elektřiny za účelem zachování spolehlivé a zabezpečené elektrické infrastruktury.
březen První implementace 6LoWPAN na TinyOS vychází z implementace „Arch Rock Compagnie: Primer Pack / IP“. duben První implementace 6LoWPAN na TinyOS je k dispozici na implementaci „Sensinode Compagnie: NanoStack v0.9.4“. srpen Skupina 6LoWPAN publikuje RFC 4919, aby zajistila interoperabilitu síťové vrstvy. září RFC 4944 je vytvořen na základě RFC4919 . To by mělo umožnit přímé připojení zařízení LoWPAN k internetu přes IPv6 a nahradit proprietární komunikační protokoly, jako je ZigBee, který byl vyvinut po skončení projektu Smart Dust. 2008
  • První testy ukazují, že zařízení sítě 6LoWPAN využívající UIP (micro IP) stack (také známé jako vIPv6) mohlo splňovat požadavky 1. fáze IPv6 Ready . Implementace zásobníku ųIPv6 spotřebovává velmi málo zdrojů (méně než 12 kB ROM a méně než 2 kB RAM ). Téhož roku společnost Arch Rock uvedla na trh komerční produkt IPv6 / 6LoWPAN, který splňuje požadavky fáze 2 IPv6 Ready (zlatá). Čtyřtýdenní experiment ve skutečném prostředí navíc ukazuje, že použití sítí 6LoWPAN je realistické (rychlost doručování zpráv 99,98% a průměrná rychlost latence na hop <62 ms).
  • Americká národní zpravodajská rada (NIC) naznačuje, že internet věcí (IoT) je jednou z rušivých technologií, která bude strukturovat trendy do roku 2025.
červenec IETF zahajuje pracovní skupinu ROLL. září Aliance IPSO ( IP pro inteligentní objekty) , které předsedá Geoff Mulligan, je vytvořena za účelem podpory používání IP v inteligentních objektech. Inteligentní objekty jsou malé objekty typu switch, detektor se běžněji nazývá senzory. 2009
  • Testy ukazují interoperabilitu určitých implementací 6LoWPAN (Berkeley IP, Arch Rock, SICSlowpan, Sensinode a Hitachi) s „open source“ ( TinyOS a Contiki ) a proprietárními (Sensinode a Hitachi) operačními systémy.
  • Vydání knihy 6LoWPAN: The Wireless Embedded Internet od Zach Shelby a Carsten Bormann, jedné ze dvou referenčních knih o 6LoWPAN
říjen Do rozvoje inteligentních sítí oznamuje prezident Obama investici ve výši 3,4 miliardy USD. 2010
  • 12měsíční experiment v různých prostředích ukazuje, že implementace sítí 6LoWPAN je životaschopná (rychlost doručování zpráv> 99,9% a průměrná rychlost latence na hop <125 ms).
  • Vydání knihy Propojení inteligentních objektů s IP: Další internet od Jean-Philippe Vasseura a Adama Dunkelsa, jedné ze dvou referenčních knih o 6LoWPAN.
leden Studie ukazuje významné ekonomické vyhlídky v IoT. březen
  • IETF zahajuje novou pracovní skupinu CORE.
  • Zpráva naznačuje, že lepší správa srdečního selhání prostřednictvím senzorových systémů na dálku monitorujících hmotnost, krevní tlak, frekvenci a srdeční frekvenci by ve Spojených státech mohla snížit zdravotní náklady (hospitalizace a léčba) o miliardu dolarů ročně. Podobně by používání internetu věcí v dopravě mohlo snížit počet dopravních nehod a ušetřit tak zhruba 100 miliard dolarů ročně.
září Společnost Cisco získává společnost Arch Roch (jeden z lídrů v oblasti BAC aplikací pro WSN), která posiluje strategickou alianci dříve podepsanou mezi společnostmi Cisco a Itron (specialista na měřiče inteligentních sítí). 2011 leden
  • Nová pracovní skupina IETF, LWIG (pro Light-Weight Implementation Guidance ) je vytvořena s cílem optimalizovat zásobník 6loWPAN (menší využití paměti, spotřeba energie a složitost) pro lepší výkon zařízení 6LoWPAN. Aktuálně v této pracovní skupině najdeme:
  • průvodce pro implementaci 6LoWPAN API
  • studie o problémech propojení 6LoWPAN se sítěmi IPv4 a některých řešeních.

6 Řešení LoWPAN

Možná použití

Nejprve byla definována možná použití sítí 6LoWPAN červen 2007. Sítě 6LoWPAN jsou určeny k nasazení v následujících oblastech:

Průmysl ( průmyslové monitorování ) Příklad, detekce vadných dílů na pracovní lince za účelem přijetí nezbytných opatření (výměna) nebo měření okolního vzduchu pro prevenci rizik v chemických továrnách nebo jiných. Budovy, budovy atd. ( Strukturální monitorování ) Příklady, které umožňují „inteligentní“ správu budov za účelem úspory spotřeby energie, měřením teploty, kontrolou, zda svítí světla v prázdných kancelářích, a v případě potřeby provedením opatření: snížení teploty, vypnutí světel atd. Nebo sledování stav stavebních konstrukcí, jako jsou přehrady, mosty atd. domov ( Připojený domov ) Například umožnění nastavení domácí automatizace nebo řešení vzdáleného lékařského monitorování. zdraví ( zdravotnictví ) Například umožnění lékaři sledovat a sledovat zdravotní stav (hladinu cukru (cukrovka), puls atd.) Svých pacientů přímo na terminálu (PC, Smartphone atd.). doprava ( telematika vozidel ) Například schopnost sledovat trajektorii automobilu na silnicích a pokud je zjištěna nebezpečná trajektorie, být schopen vrátit auto zpět na správnou stopu. Zemědělství ( monitorování zemědělství ) Příklad: měření různých parametrů prostředí v plodinách v reálném čase (teplota, vlhkost, tlak, pH , ...) za účelem přijímání rozhodnutí, jako je vodní hospodářství a používání pesticidů.

Pro každé z těchto použití jsou nabízeny základní funkce (mobilita, velikost sítě, úroveň zabezpečení atd.) A síťové architektury 6LoWPAN.

Tato použití jsou „pro veřejnost“, 6LoWPAN lze nasadit také pro „soukromá“ použití, například pro vojenské účely. Je také možná integrace 6LoWPAN do společností využívajících informační systémy založené na architekturách orientovaných na služby.

Stávající řešení

V současné době jsou nasazena různá řešení využívající 6LoWPAN, můžeme zmínit:

  • Sensinode, Arch Rock, PicosNet, ZigBee SE2, Indrion, Linky d'ERDF, WattECO, PACHUBE, Sport-Tracker, Google Powermeter ...

Stejně jako hardware kompatibilní s 6LoWPAN:

Ovladač RAM EEPROM Blikat Výrobce

WiSMote

MSP430x5 CC2520

16 tis

nc

256 tis

Arago Systems

MICAz

Atmel ATmega128L

nc

4k

128 tis

Samostříl

TELOSB

TI MSP430

10 tis

16 tis

48 tis

Samostříl

JN5139

32bitový procesor RISC

96 tis

192 tis

externí

Jennic

RC2xxx

Vysoký výkon 8051 v jednom cyklu

8k

4k

32–256 tis

Radiocrafts

WPC-IP

MSP430F5

16 tis

nc

256 tis

Watteco

NanoStack

TI CC1110

4-8k

32–64 tis

32 tis

Sensinoda

Tmote Sky

TI MSP430

10 tis

nc

48 tis

Moteiv ⇒ Sentilla

eSPOT

ARM 926ej-S

1 mil

nc

8 mil

Sun SPOT

PN2420

Atmega128L / MSP430

4k

nc

128 tis

PicosNet

K dispozici jsou také OS, API a nástroje 6LoWPAN:

Tabulka 12: Dostupnost 6LoWPAN.
Opensource OS Majitel OS Mobilní OS API (jazyk) Nástroje

RIOT

NanoStack 2.0

Windows CE

COAPy (Python)

Wireshark

FreeRTOS

Sensinoda

Android

jCoAPy (Java)

Měď: Rozšíření Firefox

TinyOS

ZigBee SE2

Symbian

opencoap (C)

Contiki

libcoap (C)

Navíc je 6LoWPAN zohledněn v několika výzkumných projektech:

  • HOBNET, SENSEI, EUREKA ...

Několik implementací 6LoWPAN vyvolalo problémy. Mezi nimi můžeme poznamenat:

  • problémy s rušením na frekvenci 2,4 GHz  (ne) mají za následek zvýšení ztráty paketů a RTT .
  • zvýšená ztráta paketů a RTT, když je velikost užitečného zatížení příliš velká.
  • implementace vysokého časového limitu paketů (> 500 ms) nezbytného k omezení ztráty paketů.
  • Nadměrné používání SNMPv3 způsobuje vysoké využití ROM, totéž platí pro nastavení ověřování SNMP, které také zvyšuje latenci.

Původně byl 6LoWPAN navržen pro použití v sítích 802.15.4 . Od roku 2010 se 6LoWPAN začal používat na jiných médiích (např. Elektrické vedení , RFID a Bluetooth ), a proto se stal jádrem „ internetu věcí “. Veškerá práce IETF ve stavu „návrhu“ je funkční, ale ještě není formálně standardizována. Jsou (v roce 2010) v neustálém vývoji, aby optimalizovali používání 6LoWPAN.

Poznámky a odkazy

Poznámky

  1. Ve francouzštině, osobní bezdrátové sítě s nízkou spotřebou .
  2. Ve francouzštině, bezdrátové sítě s nízkou spotřebou .
  3. Definice čítačů nebo parametrů načtených a / nebo upravených prostřednictvím protokolu SNMP, specifické pro výrobce
  4. Ve francouzštině byla překročena doba odezvy .
  5. Ve francouzštině inteligentní síť .
  6. Ve francouzštině inteligentní objekt .

Reference

  1. G. Mulligan 2007 , Úvod
  2. RFC 4919, 2007 , strana 1
  3. RFC 4944, 2007 , strana 1
  4. IEEE Std 802.15.4-2006 , strana 13
  5. Z. Shelby et al. 2009 , úvod
  6. JP. Vasseur et al. 2010 , úvod
  7. IEEE Std 802.15.4-2006 , strana 45
  8. IEEE Std 802.15.4-2006 , strana 159
  9. IEEE Std 802.15.4-2003 , strana 172
  10. RFC 2460 , strana 4
  11. RFC 768 , strana 1
  12. RFC 2460 , strana 24
  13. RFC 4919, 2007 strana 4-9
  14. (in) Request for Comments n °  4862 .
  15. RFC 4919 , strana 8
  16. (in) Request for Comments n °  3410 .
  17. RFC 4919, 2007 , strana 8
  18. RFC4944 , strana 5
  19. RFC4944 , strany 11-12
  20. P. Thubert et al. 2010 , strana 3
  21. P. Thubert a kol. , 2010
  22. A. Ludovici a kol. 2009 , strana 4
  23. J. Hui a kol. 2007
  24. A. Ludovici a kol. 2009 , strana 5
  25. J. Hui et al. 2011
  26. J. Hui a kol., 2011 , strana 6
  27. J. Hui a kol., 2011 , strana 14
  28. J. Hui a kol., 2011 , strana 17
  29. RFC5246 , 2008
  30. RFC4303 , 2005
  31. J. Hui et al. 2011 , strana 16
  32. A. Ayadi a kol., 2010
  33. C. O'Flynn 2010
  34. C. Bormann 2011 , strana 3
  35. C. Bormann 2011
  36. E. Kim a kol.2011
  37. A. Chowdhury a kol. 2009 , strana 5
  38. A. Ludovici a kol. 2011, strany 5-7
  39. K. Kim a kol. 2007 (a)
  40. K. Kim a kol. 2007 (b)
  41. K. Kim a kol.2007 (c)
  42. RPL , 2011
  43. Routing Přes nízkou spotřebou energie a sítí ztrátový (Active WG)
  44. RFC5548 , 2009
  45. RFC5673 , 2009
  46. RFC5826 , 2010
  47. RFC5867 , 2010
  48. JP. Vasseur a kol.2011
  49. RFC6206 , 2011
  50. N. Tsiftes et al. 2010 , strana 2
  51. Z. Shelby a kol., 2010 , s.  1
  52. Z. Shelby et al. 2010 , strana 11
  53. Z. Shelby et al. 2010 , strana 12
  54. . Shelby et al. 2010 , strana 14
  55. Z. Shelby et al. 2010 , strana 15
  56. C. Bormann 2011 , s.  27
  57. H. Shin a kol. 2009 , s.  4
  58. H. Shin a kol. 2009 , s.  1
  59. E. Talipov a kol.2011 , s.  184
  60. E. Talipov a kol.2011 , s.  188
  61. E. Talipov a kol.2011 , s.  194-195
  62. Silva a kol. 2009 , s.  49
  63. M-K. Shin et al. 2007 , strany 6-7
  64. RFC 3775 , 2004
  65. R. Silva a kol. 2009
  66. RFC 5213 , 2008
  67. MK. Shin et al. 2009
  68. RFC 3963 , 2005
  69. JH. Kimet Al. 2008
  70. G. Bag a kol., 2008
  71. Z. Zinonos a kol.2010
  72. M. Ha a kol.2010
  73. Md. Motaharul Islam et al. 2011
  74. C. Haksoo a kol. 2009 , s.  305
  75. M. Hamid a kol., 2010 , s.  1-29
  76. C. Haksoo a kol. 2009 , s.  306
  77. C. Haksoo a kol. 2009 , s.  308
  78. C. Haksoo a kol. 2009 , s.  307
  79. M. Hamid et al. 2008 , s.  419
  80. M. Hamid a kol. 2008 , s.  417
  81. IEEE802.15.4
  82. S. Daniel a kol. 2009 , s.  8
  83. M. Hamid et al. 2008 , s.  421
  84. b6LoWPAN - BLIP
  85. C. Haksoo a kol. 2009 , s.  309
  86. M. Hamid a kol. 2008 , s.  422
  87. M. Hamid a kol. 2008 , s.  423
  88. T. Luckenbach et al. 2005
  89. NB Priyantha et al. 2008
  90. RFC 4627, 2007 , strana 1.
  91. D. Yazar a kol. 2009
  92. L. Schor a kol., 2009
  93. oficiálních stránkách projektu Sensei
  94. R. Gold a kol. 2009
  95. C. Bormann a kol. 2009
  96. RFC 3135, 2001 , strana 1.
  97. D. Bimschas et al., 2010 , strana 8
  98. IETF, 2010 , strany 1
  99. Z. Shelby et al. 2011 (a)
  100. RFC 4347, 2006
  101. RFC 5988, 2010 , strana 1.
  102. RFC 3986, 2005 , strana 1.
  103. Z. Shelby 2011
  104. RFC 5785, 2010 , strana 1.
  105. Z. Shelby et al. 2011 (b)
  106. Z. Shelby et al. 2011 (c)
  107. A. Brandt 2011
  108. C. Bormann 2011
  109. C. Schmitt et al. 2010 , strana 390
  110. L. Braun a kol., 2011
  111. RFC 5101, 2008
  112. L. Eggert, 2011 , strana 1
  113. A. Castellani 2011
  114. RFC3810, 2004 , strana 1
  115. RFC4605, 2006 , strana 1
  116. A. Rahman, 2011
  117. P. Van der Stok et al. 2011
  118. G. Moritz, 2010
  119. G. Moritz 2011
  120. S. Cheshire a kol., 2011
  121. S. Park et al. 2011
  122. RFC 5996, 2010 , strana 1
  123. RFC 3971, 2005 , strana 1
  124. Sarikaya a kol., 2011
  125. H. Kim 2008 , strana 796
  126. S. Raza a kol., 2011
  127. AA El Kalam a kol., 2010
  128. J. Ayuso et al. 2010
  129. Oficiální webové stránky Z-WAVE
  130. oficiální web EnOcean
  131. oficiální stránky ZigBee
  132. oficiální web Wireless-HART
  133. oficiální web Mezinárodní telekomunikační unie
  134. ITU , 2005
  135. oficiální web evropského projektu: smart grid
  136. M. Chebbo, 2007
  137. oficiálních stránkách amerického vládního projektu: smart grid
  138. Vláda USA, 2007
  139. H. Labiod a kol., 2003
  140. S. Farahani 2008
  141. B. Warneke et al. 2001
  142. oficiální web podporující protokol IPv6
  143. M. Durvy et al. 2008 , strana 421
  144. U. Sarwar a kol. 2010 , strana 889.
  145. Jonathan W Hui a kol., 2008
  146. oficiální web Národní zpravodajské rady
  147. NIC , 2008
  148. KD Korte et al. 2009
  149. John Carey, 2009
  150. Jonathan W Hui et al., 2010 , strana 1865-1878
  151. Elgar Fleisch, 2010
  152. M. Chui a kol., 2010
  153. Oficiální web společnosti Cisco
  154. Cisco: Oznámení o koupi Arch Rock
  155. oficiální web Itron
  156. Cisco: Cisco: Oznámení aliance Itron
  157. Pokyny pro implementaci lehké váhy (aktivní WG)
  158. C. Williams 2011
  159. Z. Cao 2011
  160. E. Kim a kol.2007
  161. E. Kim et al. 2011
  162. H. Song a kol.2011
  163. R. Glombitza et al. 2009 , strana 25
  164. Oficiální web Sensinode
  165. Arch Rock oficiální webové stránky
  166. oficiální web Picosnet
  167. oficiální web Irion
  168. Stiskněte Sagemcom, Linky , specifikace Linky a oficiální web ERDF Linky
  169. Oficiální web společnosti Watteco
  170. oficiální web Pachube
  171. Sports-tracker
  172. Powermeter
  173. „  Datový list WiSMote  “ ( ArchivWikiwixArchive.isGoogle • Co dělat? ) A oficiální web Arago Systems
  174. Datový list MICAz a oficiální web kuše
  175. Datasheet TELOSB a oficiální web kuše
  176. JN5139 na oficiálním webu Jennic
  177. Moduly 6LoWPAN na oficiálním webu Radiocrafts
  178. WPC-IP na oficiálním webu Watteco
  179. NanoStack 2.0 na oficiálním webu Sensinode
  180. „  Datový list Tmote Sky  “ ( ArchivWikiwixArchive.isGoogle • Co dělat? ) A oficiální web Sentilla
  181. Datový list Sun SPOT na oficiálním webu SunSPOT
  182. „  PN2420  “ ( ArchivWikiwixArchive.isGoogle • Co dělat? ) Na oficiálních stránkách PicosNet
  183. oficiální web projektu Hobnet
  184. oficiální web projektu Eureka
  185. Z. Suryady et al., 2011 , strana 171
  186. CJ M. Liang et al. 2010 , strana 309
  187. B. Cody-Kenny a kol. 2009 , strana 25
  188. J. Schonwalder a kol.2011 , strana 1
  189. C. Chauvenet et al. 2010
  190. R. Silva et al. 2009 , strana 44
  191. B. Patil a kol., 2011 , strana 1
  192. C. Bormann a kol., 2010

Bibliografie

Knihy a články

  • (en) Geoff Mulligan , „  The 6LoWPAN architecture  “ , Sborník ze 4. workshopu o integrovaných síťových senzorech ,2007, str.  78-82 ( DOI  http://doi.acm.org/10.1145/1278972.1278992 , číst online )
  • (en) Standard IEEE pro informační technologie - Místní a metropolitní sítě - Specifické požadavky -: Část 15.4: Specifikace bezdrátového středního přístupu (MAC) a fyzické vrstvy (PHY) pro bezdrátové bezdrátové osobní sítě (WPAN) , IEEE Std 802.15.4-2006 (revize IEEE Std 802.15.4-2003),7. září 2006, 320  s. ( číst online ) Odkaz DOI
  • (en) Zach Shelby a Carsten Bormann , 6LoWPAN: The Wireless Embedded Internet , Chichester, John Wiley & Sons ,2009, 244  s. , vázaná kniha ( ISBN  978-0-470-74799-5 , LCCN  2009026837 , online prezentace )
  • (en) Jean-Philippe Vasseur a Adam Dunkels , Propojování inteligentních objektů s IP: The Next Internet , Burlington, Elsevier Science & Technology,2010( ISBN  978-0-12-375165-2 , LCCN  2010001206 , online prezentace )
  • (en) Standard IEEE pro informační technologie - telekomunikace a výměna informací mezi systémy: Místní a metropolitní sítě Specifické požadavky: Část 15.4: Specifikace bezdrátového středního přístupu (MAC) a fyzické vrstvy (PHY) pro bezdrátové bezdrátové osobní sítě s nízkou frekvencí ( LR-WPAN) , IEEE Std 802.15.4-2003,2003, 670  str. ( číst online ) Odkaz DOI
  • (en) Houda Labiod , Hossam Afifi a Costantino Santis , Wi-Fi, Bluetooth, Zigbee and WiMax , Dordrecht, Springer Nizozemsko,2003, 11 th  ed. ( ISBN  978-1-4020-5396-2 , číst online )
  • (en) Shahin Farahani , ZigBee Wireless Networks and Transceivers , Amsterdam, Newnes,2008, kapsa ( ISBN  978-0-7506-8393-7 , LCCN  2009275319 , číst online )
  • (en) Brett Warneke , Matt Last , Brian Liebowitz a Kristofer Pister , „  Smart Dust: Communicating with a Cubic-Millimeter Computer  “ , Počítač ,2001, str.  44-51 ( DOI  /10.1109/2.895117 , číst online )
  • (en) National Intelligence Council , The Internet of things: F , NIC,2008, str.  1-19 Celý text
  • (en) International Telecommunication Union , Internet of Things summary , ITU,2005 Celý text
  • (en) Alessandro Ludovici , Anna Calveras , Marisa Catalan , Carles Gómez a Josep Paradells , „  Implementation and Evaluation of the Enhanced Header Compression (IPHC) for 6LoWPAN  “ , The Internet of the Future 15th Open European Summer School and Workshop IFIP TC6.6 , EUNICE 2009 , roč.  5733,2001, str.  168-177 ( DOI  10.1007 / 978-3-642-03700-9_18 , číst online )
  • (en) Aminul Haque Chowdhury , Muhammad Ikram , Hyon-Soo Cha , Hassen Redwan , SM Saif Shams , Ki-Hyung Kim a Seung-Wha Yoo , „  Route-over vs mesh-under routing in 6LoWPAN  “ , Proceedings of the 2009 International Konference o bezdrátové komunikaci a mobilních počítačích: bezdrátové připojení k světu ,2009, str.  1208-1212 ( DOI  10.1145 / 1582379.1582643 , číst online )
  • (en) Alessandro Ludovici , Anna Calveras a Jordi Casademont , „  Forwarding Techniques for IP Fragmented Packets in a Real 6LoWPAN Network  “ , Sensors ,2011, str.  992-1008 ( DOI  10.3390 / s110100992 , číst online )
  • (en) Nicolas Tsiftes , Joakim Eriksson a Adam Dunkels , „  Low-Power Wireless IPv6 Routing with ContikiRPL  “ , sborník z 9. mezinárodní konference ACM / IEEE o zpracování informací v senzorových sítích ,2010, str.  406-407 ( DOI  10.1145 / 1791212.1791277 , číst online )
  • (en) Myung-Ki Shin a Hyoung-Jun Kim , „  Podpora mobility L3 v rozsáhlých sítích senzorů založených na IP (6LoWPAN)  “ , Advanced Communication Technology, 2009. ICACT 2009. 11. mezinárodní konference dne , sv.  02,2009, str.  941-945 ( číst online )
  • (en) Jin Ho Kim , Choong Seon Hong a Taeshik Shon , „  Lehký protokol NEMO na podporu 6LoWPAN  “ , ETRI Journal , sv.  30,listopadu 2009, str.  787-792 ( DOI  10.1109 / ICCIT.2008.290 , číst online )
  • (en) Gargi Bag , Mukhtar Hamid , SM Saif Shams , Ki Hyung Kim a Seung-wha Yoo , „  Inter-PAN Mobility Support for 6LoWPAN  “ , Konvergence a hybridní informační technologie, 2008. ICCIT '08. Třetí mezinárodní konference dne , sv.  1,října 2008, str.  685-695 ( DOI  10.1109 / ICCIT.2008.290 , číst online )
  • (en) Zinon Zinonos et Vasos Vassiliou , „  Podpora intermobility v kontrolovaných sítích 6LoWPAN  “ , GLOBECOM Workshopy (GC Wkshps), 2010 IEEE ,prosince 2010, str.  1718-1723 ( DOI  10.1109 / GLOCOMW.2010.5700235 , číst online )
  • (en) Minkeun Ha , Daeyoung Kim , Seong Hoon Kim a Sungmin Hong , „  Inter-MARIO: Rychlý a bezproblémový protokol mobility na podporu předávání mezi jednotlivými účastníky v 6LoWPAN  “ , GLOBECOM 2010, 2010 IEEE Global Telecommunications Conference ,prosince 2010, str.  1-6 ( DOI  10.1109 / GLOCOM.2010.5683658 , číst online )
  • (en) Md. Motaharul Islam a Eui-Nam Huh , „  ISensor Proxy Mobile IPv6 (SPMIPv6) - nové schéma pro IP-WSN podporující mobilitu  “ , Sensors ,2011, str.  1865-1887 ( DOI  10.3390 / s110201865 , číst online )
  • (en) Heecheol Song , Sang Hyuk Lee , Soobin Lee a Hwang Soo Lee , „  Síťová architektura taktických bezdrátových senzorů založená na 6LoWPAN pro scénáře vzdáleného náhodného nasazení ve velkém měřítku  “ , Vojenská komunikační konference, 2009. MILCOM 2009. IEEE ,října 2009, str.  1-7 ( DOI  10.1109 / MILCOM.2009.5379823 , číst online )
  • (en) Kevin Dominik Korte , Iyad Tumar a Jurgen Schonwalder , „  Hodnocení IPv6 přes implementace bezdrátových osobních sítí s nízkým výkonem  “ , Local Computer Networks, 2009. LCN 2009. IEEE 34. konference o ,října 2009, str.  881-888 ( DOI  10.1109 / LCN.2009.5355015 , číst online )
  • (en) Thomas Luckenbach , Peter Gober a Stefan Arbanowski , „  TinyREST - protokol pro integraci senzorových sítí do internetu  “ , Proc. REALWSN ,2005( číst online )
  • (in) Nissanka B. Priyantha , Aman Kansal Michel Goraczko a Feng Zhao , "  Tiny webových služeb: návrh a realizace sítí, interoperabilní a evolvable čidel  " , SENSYS '08 Proceedings of the 6. ACM konference je vestavěné síťové senzor systémy ,2008, str.  43-48 ( číst online )
  • (en) Dogan Yazar a Adam Dunkels , „  Efektivní integrace aplikací v sítích senzorů založených na IP  “ , BuildSys '09 Proceedings of the First ACM Workshop on Embedded Sensing Systems for Energy-Efficiency in Buildings ,2009, str.  43-48 ( ISBN  978-1-60558-824-7 , DOI  /10.1145/1810279.1810289 , číst online )
  • (en) Corinna Schmitt , Lothar Braun , Thomas Kothmayr a Georg Carle , „  Shromažďování dat senzorů pomocí komprimovaného protokolu IPFIX  “ , sborník IPSN '10 z 9. mezinárodní konference ACM / IEEE o zpracování informací v senzorových sítích ,2010, str.  390-391 ( ISBN  978-1-60558-988-6 , DOI  http://doi.acm.org/10.1145/1791212.1791269 , číst online )
  • (en) Choi Haksoo , Nakyoung Kim a Hojung Cha , „  6LoWPAN-SNMP: Simple Network Management Protocol for 6LoWPAN  “ , 11. mezinárodní konference IEEE o vysoce výkonných počítačích a komunikacích ,2009, str.  305-313 ( ISBN  978-076953738-2 , DOI  10.1109 / HPCC.2009.49 , číst online )
  • (en) Mukhtar Hamid , Kang-Myo Kim , Ahmad Chaudhry Shafique , Akbar Ali Hammad , Ki-Hyung Kim a Seung-Wha Yoo , „  LNMP-Management Architecture for IPv6 based low-power Wireless Personal Area Networks (6LoWPAN)  “ , NOMS 2008 - Sympozium pro provoz a správu sítí IEEE / IFIP: Všudypřítomná správa pro všudypřítomné sítě a služby ,2008, str.  417-424 ( ISBN  978-142442066-7 , DOI  10.1109 / NOMS.2008.4575163 , číst online )
  • (en) Mathilde Durvy , Julien Abeillé , Patrick Wetterwald , Colin O'Flynn , Blake Leverett , Eric Gnoske , Michael Vidales , Geoff Mulligan , Nicolas Tsiftes , Niclas Finne a Adam Dunkels , „  Vytváření senzorových sítí IPv6  “ , SenSys '08 Proceedings 6. konference ACM o vestavěných síťových senzorových systémech ,2008, str.  421-422 ( ISBN  978-1-59593-990-6 , DOI  http://doi.acm.org/10.1145/1460412.1460483 , číst online )
  • (en) Chauvenet , Tourancheau a Genon-Catalot , „  802.15.4, řešení MAC vrstvy pro PLC  “ , Počítačové systémy a aplikace (AICCSA), Mezinárodní konference IEEE / ACS 2010 ,Květen 2010, str.  1-8 ( ISBN  978-1-4244-7716-6 , DOI  /10.1109/AICCSA.2010.5586997 , číst online )
  • (en) Ricardo Silva , Valderi RQ Leithardt , Jorge Sa Silva , Claudio Geyer , Joel Rodrigues a Fernando Boavida , „  Srovnání přístupů k objevování uzlů a služeb v bezdrátových senzorových sítích 6lowPAN  “ , Q2SWinet '09 Proceedings of the 5th ACM symposium on QoS a zabezpečení pro bezdrátové a mobilní sítě ,2009, str.  44-49 ( ISBN  978-1-60558-619-9 , DOI  /10.1145/1641944.1641954 , číst online )
  • (en) Nils Glombitza , Dennis Pfisterer a Stefan Fischer , „  Integrace bezdrátových senzorových sítí do podnikových procesů založených na webových službách  “ , MidSens '09 Proceedings of the 4th International Workshop on Middleware Tools, Services and Run-Time Support for Sensor Networks ,2009, str.  25-30 ( ISBN  978-1-60558-851-3 , DOI  /10.1145/1658192.1658197 , číst online )
  • (en) Usman Sarwar , Gopinath Sinniah Rao , Zeldi Suryady a Reza Khoshdelniat , „  Srovnávací studie o dostupných platformách IPv6 pro bezdrátovou senzorovou síť  “ , waset.ac.nz ,2010, str.  889-892 ( číst online )
  • (en) Daniel Bimschas , Horst Hellbrück , Richard Mietz , Dennis Pfisterer , Kay Römer a Torsten Teubler , „  Middleware pro inteligentní brány připojující sensornety k internetu  “ , MidSens '10 Proceedings of the 5th International Workshop on Middleware Tools, Services and Run- Časová podpora pro senzorové sítě ,2010, str.  8 -14 ( ISBN  978-1-4503-0454-2 , DOI  /10.1145/1890784.1890787 , číst on-line )
  • (en) Lars Schor , Philipp Sommer a Roger Wattenhofer , „  Směrem k síťové architektuře bezdrátových senzorů s nulovou konfigurací pro inteligentní budovy  “ , BuildSys '09 Proceedings of the First ACM Workshop on Embedded Sensing Systems for Energy-Efficiency in Buildings ,2009, str.  31-36 ( ISBN  978-1-60558-824-7 , DOI  /10.1145/1810279.1810287 , číst online )
  • (en) HyunGon Kim , „  Ochrana proti útokům fragmentace paketů na adaptační vrstvě 6LoWPAN  “ , Konvergence a hybridní informační technologie, 2008. ICHIT '08. Mezinárodní konference ,Srpna 2008, str.  796-801 ( ISBN  978-0-7695-3328-5 , DOI  /10.1109/ICHIT.2008.261 , číst online )
  • (en) Shahid Raza , Thiemo Voigt a Utz Roedig , „  6LoWPAN Extension for IPsec  “ , konference nebo workshop (příspěvek) ,března 2011, str.  1-3 ( číst online )
  • (en) Anas Abou El Kalam , Andrea Atzeni , Stefan Lindskog , Daniele Mazzocchi , Claudio Pastrone , Khalid Salih , Maurizio A. Spirito a Olivier Terzo , „  Směrem k formálnímu rámci pro hodnocení zabezpečení bezdrátových senzorových sítí  “ , Den šíření NEWCOM ++ ,2010( číst online )
  • (en) Jesus Ayuso , Leandro Marin , Antonio J. Jara a Antonio F. Gomez Skarmeta , „  Optimalizace kryptografie veřejného klíče (RSA a ECC) pro 16bitová zařízení založená na 6LoWPAN  “ , 1. mezinárodní seminář o bezpečnosti internetu věc ,2010( číst online [ archiv24. září 2011] )
  • (en) Brendan Cody-Kenny , David Guerin , Desmond Ennis , Ricardo Simon Carbajo , Meriel Huggard a Ciaran Mc Goldrick , „  Hodnocení výkonu protokolu 6LoWPAN na motivech MICAz a TelosB  “ , PM2HW2N '09 Proceedings of the 4th ACM workshop on Performance monitorování a měření heterogenních bezdrátových a kabelových sítí ,Únor 2009, str.  25-30 ( ISBN  978-1-60558-621-2 , DOI  /10.1145/1641913.1641917 , číst online )
  • (en) Jurgen Schonwalder , Tina Tsou a Behcet Sarikaya , „  Profily protokolu pro omezená zařízení  “, www.iab.org ,února 2011, str.  1-5 ( číst online )
  • (en) Z. Suryady , MHM Shaharil , KA Bakar , R Khoshdelniat , GR Sinniah a U. Sarwar , „  Hodnocení výkonu přesného zemědělství založeného na 6LoWPAN  “ , Informační sítě (ICOIN), Mezinárodní konference 2011 ,března 2011, str.  171-176 ( ISBN  978-1-61284-661-3 , ISSN  1976-7684 , DOI  /10.1109/ICOIN.2011.5723173 , číst online )
  • (en) Chieh-Jan Mike Liang , Nissanka Bodhi Priyantha , Jie Liu a Andreas Terzis , „  Přežít wi-fi zásah do nízký výkon ZigBee sítí  “ , SENSYS '10 Proceedings of the 8th ACM konference o vestavěných síťových systémů Sensor ,2010, str.  309-322 ( ISBN  978-1-4503-0344-6 , DOI  /10.1145/1869983.1870014 , číst online )
  • (en) Hyojeong Shin , Elmurod Talipov a Hojung Cha , „  Automatická konfigurace IPv6 bezstavové adresy pro 6LoWPAN pomocí barevných koordinátorů  “ , Sborník mezinárodní konference IEEE 2009 o pervazivní práci na počítači a komunikaci ,2009, str.  1-9 ( DOI  10.1109 / PERCOM.2009.4912770 , číst online )
  • (en) Elmurod Talipov , Hyojeong Shin , Seungjae Han a Hojung Cha , „  Lehká stavová automatická konfigurace adresy pro 6LoWPAN  “ , Wirel. Netw. , sv.  17,ledna 2011, str.  183-197 ( ISSN  1022-0038 , DOI  10.1007 / s11276-010-0272-0 , číst online )
  • (en) Jonathan W. Hui a David E. Culler , „  IPv6 v bezdrátových sítích s nízkou spotřebou energie  “ , sborník IEEE ,2010, str.  1865-1878 ( DOI  10.1109 / JPROC.2010.2065791 , číst online )
  • en) „  XIII zákona o energetické nezávislosti a bezpečnosti z roku 2007  “ , smartgrid.gov ,2007( číst online )
  • (en) M Chebbo , „  EU SmartGrids Framework“ Electricity Networks of the future 2020 and beyond “  “ , General Meeting Society Power Engineering, 2007. IEEE ,Červenec 2007( DOI  /10.1109/PES.2007.386294 , číst online )
  • (en) Carsten Bormann , JP Vasseur a Zack Shelby , „  The Internet of Things  “ , IETF Journal, svazek 6, vydání 2 ,listopadu 2010( číst online [ archiv5. června 2011] )
  • (en) Jonathan W. Hui a David E. Culler , „  IP is Dead, Long Live IP for Wireless Sensor Networks  “ , SenSys '08 Proceedings of the 6th ACM conference on Embedded network sensor systems ,2008( DOI  /10.1145/1460412.1460415 , číst online )
  • (en) John Carey , „  Obamův plán Smart-Grid Game  “ , businessweek ,října 2009( číst online )
  • (en) Elgar Fleisch , „  Co je to internet věcí? Ekonomická perspektiva  “ , www.autoidlabs.org ,ledna 2010( číst online )
  • (en) Michael Chui , Markus Löffler a Roger Roberts , „  Internet věcí  “ , McKinsey Quarterly ,března 2010( číst online )
  • (en) Carsten Bormann , „  Začínáme s IPv6 v bezdrátových„ osobních oblastech “s nízkou spotřebou energie (6LoWPAN)  “ , Výukový program pro propojení inteligentních objektů s internetem Praha ,26. března 2011, str.  27 ( číst online )

Práce RFC a IETF

externí odkazy