Sedan Zigbee-specifikationen publicerades den 13 juni så har fler än 6000 företag och systemintegratörer laddat ned dokumentet. Marknadsanalysföretaget Harbor Research skrev nyligen att Zigbee-nät kommer att "förändra ditt liv både privat och professionellt mer än vad någon annan datorbaserad teknologi gjort sedan pc:n"

Men trots att specifikationen nu blivit ratificerad i version 1.0 så är inte protokollet sådant att man kan ta det och lätt applicera på vilken produkt som helst. I sin enklaste form ger protokollet en interoperabilitet mellan produkter som uppfyller kraven i standarden. När man ser på de mer djupgående frågor man sedan måste ställa sig angående sin tillämpning, arkitekturen av systemet och sin plattform så är de lika många och stora som de potentiella ZigBee-applikationerna själva.

Exempel på sådana frågor är vilken nätverkstopologi man skall använda, interoperabilitetskrav, säkerhetsnivåer, skillnader mellan olika plattformar samt utvecklingsmiljö. Vilken effekt kräver applikationen? Hur många noder behövs för att täcka en area? Vilken dataöverföringshastighet kommer nätet att behöva?, Vilka är kostnadskraven? och Hur skalbart måste nätverket vara?

Zigbee-standarden erbjuder nätverks-, säkerhets- och applikationssupport ovanpå IEEE 802.15.4 medielagret (Medium Access Control, MAC) och det fysiska lagret (PHY) i den trådlösa standarden. En rad olika teknologier används för att skapa ett skalbart, självorganiserande och självhelande nätverk som kan styra många olika datatrafiktyper.

Zigbee är i första hand tänkt för styrning och övervakning av fastigheter och hem, industristyrning och andra övervaknings. och styrningsapplikationer där låg strömförbrukning, hög tillgänglighet, lång batterilivslängd och lägsta möjliga pris är av högsta vikt.

Även om Zigbee oftast ses som en teknologi synonym med trådlösa nät med "mesh"-arkitektur så stödjer standarden även ett antal andra topologier såsom stjärnnät, trädstruktur eller hybrider däremellan.

Om tillförlitlighet är av vikt så är "mesh"-arkitekturen att föredra då den erbjuder bäst skydd mot varianser i signalstyrka på grund av interferens eller multipla signaler. Genom att placera sändare och mottagare tätt tillsammans så minskar man effekterna av dessa orsaker. De redundanta vägarna i ett "mesh"-nätverk ger alternativa datavägar. Dessutom ökar säkerheten genom att ingen nod är oumbärlig för nätets existens.

Vissa tillämpningar kan behöva Zigbee-routrar som agerar relästation för att öka på räckvidden i systemet så att noder även långt ifrån varandra kan utbyta information. Dessutom kan installationen bygga på batteridrivna noder som behöver en stor del "sovtid" för att spara kraft. Ta som exempel ett system för att övervaka jordbruksodlingar. Där kanske ett klusternätverk passar bäst, då det kan aggregera multipla undernät till att täcka stora ytor och långa avstånd där datatrafik med låg överföringshastighet tar sig längs grenarna och väcker de batteridrivna routrarna endast då behov att överföra data mellan undernäten uppstår. I nät med korta avståndskrav kan det å andra sidan vara bättre med ett stjärnnätverk där den "overhead" som genereras i ett "mesh"-nätverk inte är önskvärd.

Trots att Zigbee är en öppen standard så ger den OEM-tillverkaren en stor portion frihet i hur mycket av implementationen som skall vara öppen för tredjepart. Som noterat så specificerar standarden bara nätverks-, säkerhets- och applikationsgränssnittslagren. Utvecklare kan därför välja att antingen licensiera hela Zigbee-stacken, som då kan innehålla profildefintioner för olika produkter, eller bara licensiera nätverkslagret för den mest grundläggande nätverksinteroperabiliteten.

På applikationsnivå måste utvecklarna bestämma huruvida de vill använda en publik applikationsprofil eller om de vill implementera sin egen privata profil. Zigbee v1.0 har färdiga enkla publika profiler klara för styrning av lampor och ljussystem, och runt hörnet väntar profiler för system för värme och luftkonditionering, industriella sensorer och andra sensorer. Det är fritt fram för alla företag att utveckla produkter som stödjer de publika profilerna. Exempelvis kan ett företag som tillverkar ballaster till lysrörslampor genom att använda den publika profilen för ljusstyrning samexistera och interagera med tredjepartstillverkade lysknappar som använder samma profil. Utvecklare kan lätt lägga till sina egna funktioner för att anpassa de publika profilerna. Zigbee är uppbyggt genom att använda applikationsobjekt som kommunicerar med andra produkter genom att utbyta profilobjekt och tillhörande attribut.

Vissa OEM-tillverkare väljer helt proprietära lösningar på applikationsnivå, antingen för att man vill skapa en helt stängd miljö, eller för att man vill skapa ett stängt ekosystem av tredjepartstillverkare. Zigbee definierar ett abstrakt gränssnitt medan plattformstillverkare och tillhandahåller gränssnitt för applikationsprogrammering (API) som definierar regler för hur applikationen integrerar in mot Zigbee-stacken.

Hur datatrafiken transporteras är också en viktig fråga att ställa sig för utvecklaren, eftersom ZigBee inte definierar något transportlager för att exempelvis ge återkoppling på om meddelandet kommer fram till mottagaren. Därför måste man som utvecklare bestämma sig för huruvida man vill bygga transportmekanismen själv eller använda ett Zigbee-chips med en inbyggd transportmekanism. Exempelvis har Embers Zigbee-stack en inbyggd funktion för att hantera transportmekanismen och man kan lätt bygga sina applikationer ovanpå denna för att få ett system med ett fullt fungerande transportlager.

De flesta Zigbee-applikationer kräver att någon slags säkerhetsrutin byggs in i produkten. Lyckligtvis har Zigbee en standardiserad verktygslåda för säkerhetsspecifikationer och mjukvara. Den bygger på en AES 128-bitars algoritm och innehåller säkerhetsbitarna från 802.15.4. Zigbees stackprofiler definierar säkerheten för MAC-, nätverks- och applikationslagren. Säkerhetsrutinerna inkluderar metoder för nyckelgenerering och transport samt enhetshantering.

Om utvecklaren väljer att använda en publik Zigbee-profil så är säkerhetsfrågan redan definerad däri. Dessutom är det troligt att man, även om man bestämmer sig för att utveckla sin egen privata profil, bygger säkerheten på någon av de fördefinierade säkerhetsfunktionera som finns i Zigbee-stackens fördefinierade profiler.

Som utvecklare måste man även se var man vill ha säkerhetsrutiner, på MAC-nivå, i nätverket eller på applikationsnivå. Om det är applikationsnivån som kräver den största säkerheten så skall man självklart lägga störst vikt på just där. Säkerhet på den nivån använder en unik sessionsnyckel som endast kan autentiseras och dekrypteras av en annan enhet med samma nyckel. Förfaringssättet skyddar både mot interna och externa attacker, men kräver mer minne för implementationen.

Säkerhet på MAC- och nätverksnivå fungerar i stort sett likadant, genom att säkerställa transmissioner över ett hopp. MAC-lagret förhandlar om tillgång till den delade resursen av bandbredd och kontrollerar transmissioner på ett hopp mellan sina grannar. Zigbee-alliansen har lagt till en säkerhetsfunktion på nätverksnivå som tar hand om funktionalitet som inte tas om hand på MAC-nivå. Båda dessa lager av säkerhet använder en global nyckel som alla Zigbee-enheter i nätverket delar på. MAC- och nätverkslagrens säkerhetsfunktioner är till för applikationer som behöver skydd mot attacker mot infrastrukturen i systemet.

ZigBee-säkerheten introducerar även ett koncept som kallas "Trust Center", en funktion som ger möjlighet att tillåta enheter att ansluta till nätverket, distribuera nycklar och ge möjligheten att kontrollera säkerheten hela vägen mellan två enheter. För utvecklaren finns här två olika säkerhetsnivåer: Residential (hemma) eller Commercial (kommersiell). Den första är enkel och inte skalbar med växande nät medan den andra skapar och underhåller säkerhetsnycklar samt är skalbar men detta kostar en hel del minnesutrymme vilket man alltså måste tänka på.

Zigbee erbjuder ett standardiserat nätverk och en ramstruktur för applikationsutveckling som utvecklaren kan bygga sin produkt på utan att behöva tänka på hur radiobiten fungerar, något som många känner sig osäkra inför. Men den standardiserade ramstrukturen ger i sig inte någon garanti för en enkel produktutveckling. På marknaden finns i dag en uppsjö av tillverkare av komponenter för att bygga en ZigBee-produkt, allt från rf-kretsar, mikrostyrkretsar, och protokollstackar till utvecklingsverktyg. Som utvecklare måste man alltså välja huruvida man vill bygga sin Zigbee-lösning på lösa komponenter från olika leverantörer eller hitta en som har en totallösning med en integrerad hård och mjukvara. Den som inte är väl bevandrad i den här världen väljer nog oftast det senare.

En av de första frågorna man ställs inför är på chips- och mjukvarunivån där den största utmaningen kommer sig av komplexiteten och inkompatibiliteten mellan mjuk- och hårdvaror från olika leverantörer. Problem som uppkommer under utvecklingsfasen kommer sällan från bara ett lager av stacken. Exempelvis kan ett mjukvarufel i MAC-lagret på en prototyp sällan hittas och rättas till av tillverkaren av nätverkslagret. Alltså är det av största vikt för utvecklaren att se på hur de olika delarna arbetar tillsammans i den lösning man väljer.

En Zigbee-produkt består av en rf-tranciever, en mikrostyrkrets eller signalprocessor för applikationen och en Zigbee-stack. Tills alldeles nyligen har de flesta tillverkarna haft lösningar med flera chips, alltså rf-delen för sig och mikrostyrkretsen eller DSP:n för sig, och mjukvarustack från ytterligare en källa. I dag ser man en ny trend i starkt integrerade lösningar med enkretslösningar och mjukvara från samma tillverkare. Lösningen med flera chips lockar ofta med en låg initialkostnad för utveckling, men har visat sig vara en svårare och i slutänden till och med dyrare väg än att välja den mer integrerade.

En nackdel med en helt integrerad lösning kan vara att man som utvecklare redan beslutat sig för en mikrostyrkrets som man vill jobba vidare med. Ember har tagit detta i beaktande och utvecklat inte bara en helt integrerad lösning med allt på ett chip, EM250, utan även en lösning som baserar sig på Embers egna rf-chips EM260 och en mikrostyrkrets från en tredjepartsleverantör.

Kretsstorlek och strömförbrukning är andra faktorer som hänsyn måste tas till. Tillverkare av luftkonditionering eller andra stora system har kanske inte några problem med utrymme och strömförbrukning, medan detta är en viktig faktor i handhållna, batteridrivna applikationer och sensorapplikationer. Embers EM250 är exempelvis inte större än en skjortknapp, 7 x 7 mm och har väldigt låg strömförbrukning för att ge produktutvecklare en priseffektiv lösning med avseende på storlek, strömförbrukning och integration av funktioner som tidigare inte varit möjliga i trådlösa sammanhang.

Val av verktyg kan också avgöra hur lyckat projektet blir. Man måste som utvecklare tänka på vidden av funktionalitet som finns i verktygen för den plattform man valt. Tillhandahåller leverantören ett utvecklingssytem som innehåller flera noder, nätverksmjukvara, mjukvaruverktyg, träning, teknisk support och analysverktyg? Är verktygen samlade i en utvecklingsmiljö med universellt gränssnitt eller är verktygen fristående? Finns verktyg för analys av dataflöden via radio samt nedladdning av ny mjukvara via radio? Finns en sniffer för pakettestning?

Zigbee-standardiseringen har öppnat upp nya intressanta marknader för trådlösa sensorer och styrapplikationer inom hem och fastighetsautomation, industriell styrning och miljöstyrning, medicinska tillämpningar och till och med leksaker. Wall Street säger i en konservativ bedömning att marknaden för Zigbee kommer överstiga 8 miljarder dollar under de kommande åren. Men Zigbees standardisering löser inte alla problem - standarden är framtagen för att ge produktutvecklare en möjlighet att utveckla lösningar av olika slag, även applikationer som är stängda för utomstående. Bördan ligger på utvecklaren av Zigbee-applikationen att välja hur lösningen skall implementeras.