ENSC427:COMMUNICATIONNETWORKS

ZIGBEEMESHNETWORKSIMULATIONUSINGOPNETANDSTUDYOFROUTINGSELECTION

Spring2009

FINALPROJECT

SamLeungWilGomezJungJunKim

http://www.sfu.ca/~mingl/mingl@sfu.ca

wgomez@sfu.cajkimd@sfu.ca

ABSTRACTZigBee,formallyknownasIEEE802.15.4‐2006standard,isbecomingapopularwaytocreatewirelesspersonalareanetwork(WPAN)duetoitslowpowerconsumptionandscalability.ZigBeead‐hocmeshnetworksaredesignedtosupportalargenumberofnodes(>64,000)withdynamicroutingincaseofanodefailure.ThisprojectwillsimulateandexploretheperformanceofZigBeeWPAN’sundervariousconditionsusingOPNET.

ii

TABLEOFCONTENTSABSTRACT ............................................................................................................................. iTABLEOFCONTENTS........................................................................................................... iiLISTOFFIGURES .................................................................................................................iiiLISTOFTABLES ...................................................................................................................iiiACRONYMSANDABBREVIATIONS ..................................................................................... iv1 Introduction ................................................................................................................ 1

1.1 ProjectScope...................................................................................................... 12 ZigBeeOverview.......................................................................................................... 2

2.1 ZigBeeSpecifications ......................................................................................... 22.2 ZigBeeLayers...................................................................................................... 2

2.2.1 ApplicationLayer................................................................................... 32.2.2 NetworkLayer ....................................................................................... 32.2.4 MediumAccessControlSub‐Layer ....................................................... 32.2.5 PhysicalLayer ........................................................................................ 4

2.3 NetworkTopologies........................................................................................... 42.3.1 StarTopology......................................................................................... 52.3.2 TreeTopology........................................................................................ 52.3.3 MeshTopology ...................................................................................... 6

3 ZigBeeSimulationUsingOPNET.................................................................................. 63.1 TrafficwithSingleRouter .................................................................................. 63.2 VerificationofZigBee’sSelf‐HealingMechanismuponRouterFailure ......... 103.3 TrafficStabilityinPresenceofMovingEnd‐Devices–CBR ............................ 153.4 AssessingNetworkPerformancewithStationaryEnd‐Devices–VBR .......... 173.5 TestingtheZigBeeOPNETModelLimits–AddingAdditionalEndDevices .. 20

4 DISCUSSIONSANDCONCLUSION .............................................................................. 234.1 OPNETZigBeeModelLimitations.................................................................... 234.2 WhatWeLearned ............................................................................................ 23

5 REFERENCES .............................................................................................................. 24

iii

LISTOFFIGURESFigure1–OverviewofZigBeeLayers[7] ............................................................ 2Figure2‐LegendforZigBeeDevices .................................................................. 5Figure 3 – Star Topology [6]............................................................................... 5Figure 4 – Tree Topology [6].............................................................................. 5Figure 5 – Mesh Topology [6] ............................................................................ 6Figure6‐SingleRouterAvailableScenario ........................................................ 7Figure7–Trafficfromenddevicestodestinationcoordinator ......................... 8Figure8–Trafficsentandreceivedbythetworouters..................................... 8Figure9‐EndtoEnddelayfromenddevicestocoordinator(AsIs) ................. 9Figure10–EndtoEnddelayfromenddevicestocoordinator(Average)......... 9Figure11–Trafficpathpriorrouterfailure ...................................................... 10Figure12‐Trafficpathafterrouterfailure....................................................... 11Figure13–TrafficSentbyenddevicesandreceivedbyrouters ..................... 12Figure14–Trafficfromrouterstocoordinator(overlaidview)....................... 13Figure15–Trafficfromrouterstocoordinator(stackedview) ....................... 13Figure16–EndtoEnddelayfromenddevicestocoordinator(AsIs)............. 14Figure17–EndtoEnddelayfromenddevicestocoordinator(Average)....... 14Figure18‐TrafficandTrajectoryPath.............................................................. 15Figure19‐TrafficSentFromEndDevices&RouterstoCoordinator .............. 16Figure20‐TrafficSentFromEndDevices&RouterstoCoordinator .............. 16Figure21–End‐to‐enddelayshowingpacketdroparound5minutesimulated

time(AsIs)................................................................................................. 16Figure22–Samelayoutasscenario3.1usingvariablepacketrate ................ 17Figure23–Trafficsentbyenddevicestodestinationcoordinatorwithroute

traffic ......................................................................................................... 18Figure24–TrafficSentFromEndDevicestoCoordinator............................... 19Figure25–EndtoEnddelayfromEndDevicestoCoordinator(AsIs) ............ 19Figure26–EndtoEnddelayfromEndDevicestoCoordinator(TimeAverage)

................................................................................................................... 20Figure27–Caseoftworoutersandthreeenddevices ................................... 20Figure28–Trafficsentbytheenddevicesandreceivedbythecoordinator . 21Figure29–Caseofsinglerouterandthreeenddevices.................................. 21Figure30–Trafficfromthreeenddevicesdroppedenroute ......................... 22

LISTOFTABLESTable1–GeneralZigBeeSpecifications ............................................................. 2Table2:FrequencyBandsusedin802.15.4[1] ................................................... 4

iv

ACRONYMSANDABBREVIATIONSACL AccessControlListAES AdvancedEncryptionStandardCBR ConstantBitRateCSMA/CA CarrierSenseMultipleAccess/CollisionAvoidanceETE End‐to‐EndHVAC Heating,VentilationandAirConditioningIEEE InstituteofElectricalandElectronicsEngineersISM Industrial,ScientificandMedicalLR‐WPAN LowRate–WirelessPersonalAreaNetworkMAC MediumAccessControlPAN PersonalAreaNetworkPER PacketErrorRateVBR VariableBitRateZDO ZigBeeDeviceObject

1

1 Introduction

UseofWirelessPersonalAreaNetworks(WPAN)hassteadilygrowninrecentyears.Itspopularitycomesfromtheconvenienceofusingwirelesssignalsinopenareassuchasofficespaceorhomeratherthanhavingtolayoutwires.Removingtheconstraintsoflengthandtroublesomephysicalinstallationofwires,wirelesssolutionsprovidemuchmorediversityandpotentiallyreducedcost.

ZigBee(IEEE802.15.4‐2006standard)isacategoryintheIEEE802family,alongwithsomeofthewell‐knownprotocolssuchasWi‐Fi,Bluetoothwhichusesthe2.4GHzindustrial,andscientificandmedical(ISM)radioband.ZigBeealsoutilizes868MHzand915MHzindifferentpartsoftheworldaccordingtolocalstandards[1].UnlikeWi‐FiandBluetooth,ZigBeewasdevelopedforlow‐rateWPAN(LR‐WPAN)whichfeaturelongbatterylifebyhavinglowdaterates.

TheZigBeeprotocolwasdesignedtoprovidestatic,dynamic,ormeshnetworktopologiessupportingupto65,000nodesacrosslargeareasforindustrialuse.Inordertohandlefaultscausedbyvariousenvironmentaleffects,theZigBeeprotocolprovidesaself‐healingabilityforthenetworktodetectandrecoverfromnetworkorcommunicationlinkfaultswithouthumanintervention[1].ThisisdonethroughcertainfeaturesoftheZigBeeprotocolsuchasclearchannelassessment,retriesandacknowledgments,andcollisionavoidance.

1.1 ProjectScopeTheprimarygoalofthisprojectistobetterunderstandtheuseofOPNETsimulationtoolaswellastostudytheprotocolofinterest,ZigBee.InordertoachievethesegoalsthisprojectwillprovideabriefoverviewofwhatZigBeeprotocolcontains,andsimulateseveralsimpleZigBeeWPANnetworkswhilealteringcertainparametersusingOPNET.

2

2 ZigBeeOverview2.1 ZigBeeSpecifications

ZigBee802.15.4TransmissionRange(meters) 1–100BatteryLife(days) 100–1,000NetworkSize(#ofnodes) >64,000Throughput(kb/s) 20‐250

Table1–GeneralZigBeeSpecifications

2.2 ZigBeeLayersZigBeeconsistsoffourlayers.Thetoptwo(ApplicationandNetwork)layersspecificationsareprovidedbytheZigBeeAlliancetoprovidemanufacturingstandards.Thebottomtwo(MediumAccessControlandPhysical)layersspecificationsareprovidedbytheIEEE802.15.4‐2006standardtoensurecoexistencewithoutinterferencewithotherwirelessprotocolssuchasWi‐Fi.

Figure1–OverviewofZigBeeLayers[7]

3

2.2.1 ApplicationLayerApplicationsrunningontheZigBeenetworkarecontainedhere.Forexample,applicationstomonitortemperature,humidity,oranyotherdesirableatmosphericparameterscanbeplacedonthislayerforagriculturaluse.Thisisthelayerthatmakesthedeviceusefultotheuser.Asinglenodecanrunmorethanoneapplication.Applicationsarereferencedwithanumberrangingfrom1‐240.Meaningthereisamaximumof240applicationsonaZigBeedevice.Applicationnumber0isreservedforauniqueapplicationthatexistsonallZigBeedevices.Anotherapplicationnumber,255,isalsoreserved.Thisnumberisusedtobroadcastamessagetoallapplicationsonanode.2.2.1.1 ZigBeeDeviceObject(ZDO)AspecialapplicationisoneveryZigBeedevice,andthisistheZigBeeDeviceObject,orZDO.ThisapplicationprovideskeyfunctionssuchasdefiningthetypeofZigBeedevice(enddevice,router,andcoordinator)aparticularnodeis,initializingthenetwork,andtoalsoparticipateinforminganetwork.2.2.2 NetworkLayerAfeatureofZigBeesuchastheself‐healingmechanismisacquiredthroughthislayer.AsFigure1shows,thislayerprovidesnetworkmanagement,routingmanagement,networkmessagebroker,andnetworksecuritymanagement.ThislayerisdefinedbytheZigBeeAlliance,whichisanassociationofcompaniesunitedtoworkforabetterZigBeestandard.2.2.3 SecurityPlaneThesecurityplanespansacrossboththenetworklayerandtheapplicationlayer.Itishere,thatsecuritymeasuressuchasAES‐basedencryptionisimplemented.Anothersecurityfeatureismessagetimeouts,whichaddsaframecounterontoeachframe.Usingthisframecounter,thedevicecandeterminetheageofthemessageitreceives,anddetectthepossibilitythatanoldmessagewasrecordedandisplayedbacktothedevice(replayattack).2.2.4 MediumAccessControlSub‐LayerThislayerextractedfromtheIEEE802.15.4standardprovidesservicestothenetworklayerabove,whichispartoftheZigBeestacklevel.TheMAClayerisresponsiblefortheaddressingofdatatodetermineeitherwheretheframeisgoing,orcomingfrom.ItisalsothislayerthatprovidesmultipleaccesscontrolsuchasCSMA/CAallowingforreliabletransferofdata.Beaconingisanotherfeatureimplementedthroughthislayer.Finally,theMACsub‐layercanbeexploitedbyhigherlayerstoachievesecurecommunication(bymeasuressuchasanACL).

4

2.2.5 PhysicalLayerThephysicallayerisprovidedbytheIEEE802.15.4standard.ThisstandardmanagesthephysicaltransmissionofradiowavesindifferentunlicensedfrequencybandsaroundtheworldtoprovidecommunicationbetweendeviceswithinaWPAN.Thebandsarespecifiedinthetablebelow,pairingitwiththeareathatthebandisusedin.

FrequencyRange(MHz) NumbersofChannelsAvailable Regionused868‐868.6 1 Europe902‐928 10 NorthAmerica2400‐2483.5 16 Worldwide

Table2:FrequencyBandsusedin802.15.4[1]

Thislayerallowsforchannelselectiontoavoidradiointerference,aswellasdataexchangewiththelayerabove(MACsub‐layer)toprovideitwithservice.2.3 NetworkTopologiesZigBeenetworkscancontainamixtureofthreepotentialcomponents.ThesecomponentsareaZigBeecoordinator,aZigBeerouter,andaZigBeeenddevice.Differenttypesofnodeswillhavedifferentroleswithinthenetworklayer,butallvarioustypescanhavethesameapplications.ZigBeecoordinator–ForeveryZigBeenetwork,therecanbeonlyonecoordinator.Thisnodeisresponsibleforinitializingthenetwork,selectingtheappropriatechannel,andpermittingotherdevicestoconnecttoitsnetwork.ItcanalsoberesponsibleforroutingtrafficinaZigBeenetwork.Inastartopology,thecoordinatorisatthecenterofthestar,andalltrafficfromanyenddevicemusttraveltothisnode.Itisstillpossibleforenddevicestotalktoanotherenddevice,butthemessagemustberoutedthroughthecoordinator.Inatreetopology,thecoordinatorisatthetopofthetree,andinameshnetwork,itistherootnodeofthemesh.AZigBeecoordinatorcanalsotakepartinprovidingsecurityservices.ZigBeeRouter–Arouterisabletopassonmessagesinanetwork,andisalsoabletohavechildnodesconnecttoit,whetheritbeanotherrouter,oranenddevice.Routerfunctionsareonlyusedinatreeormeshtopology,becauseinastartopology,alltrafficisroutedthroughthecenternode,whichisthecoordinator.Routerscantakeplaceofenddevices,buttheroutingfunctionswouldbeuselessinsuchcases.Ifthenetworksupportsbeaconing,thenaroutercansleepwheninactive,periodicallywakinguptonotifythenetworkofitspresence.

5

ZigBeeEndDevice–ThepowersavingfeaturesofaZigBeenetworkcanbemainlycreditedtotheenddevices.Becausethesenodesarenotusedforroutingtraffic,theycanbesleepingforthemajorityofthetime,expandingbatterylifeofsuchdevices.Thesenodescarryjustenoughfunctiontotalktoparentnodes,whichcanbeeitherarouteroracoordinator.Anenddevicedoesnothavetheabilitytohaveothernodesconnecttoitsnetworkthroughtheenddevice,asitmustbeconnectedtothenetworkthrougheitherarouter,ordirectlytothecoordinator.Inthefollowingsections,wegointodetailaboutthethreedifferenttypesoftopologypossibleforaZigBeenetwork.Thelegendtoalltopologyfiguresareshownbelow,andeachtypeofdeviceisgivenacolorcodeforeasyviewing.

Figure2‐LegendforZigBeeDevices

2.3.1 StarTopologyInthissimpletopology,acoordinatorissurroundedbyagroupofeitherenddevicesorrouters.Eventhoughroutersareconnectedtothecoordinator,theirmessagerelayingfunctionsarenotused.Thistypeoftopologyisattractivebecauseofitssimplicity,butatthesametimepresentssomekeydisadvantages.Intheeventthatthecoordinatorstopsfunctioning,theentirenetworkisfunctionlessbecausealltrafficmusttravelthroughthecenterofthestar.Forthesamereason,thecoordinatorcouldeasilybeabottlenecktotrafficwithinthenetwork,especiallysinceaZigBeenetworkcanhavemorethan60000nodes.2.3.2 TreeTopologyInatreenetwork,acoordinatorinitializesthenetwork,andisthetop(root)ofthetree.Thecoordinatorcannowhaveeitherroutersorenddevicesconnectedtoit.Foreveryrouterconnected,morechildnodescanconnecttotherouter.Childnodescannotconnecttoanenddevicebecauseitdoesnothavetheabilitytorelaymessages.Thistopologyallowsfordifferentlevelsofnodes,withthecoordinatorbeingatthehighestlevel.Formessagestobepassedtoothernodesinthesamenetwork,thesourcenodemustpassthemessagetoitsparent,which

Figure 3 – Star Topology [6]

Figure 4 – Tree Topology [6]

6

isthenodehigherupbyonelevelofthesourcenode,andthemessageiscontinuallyrelayedhigherupinthetreeuntilitcanbepassedbackdowntothedestinationnode.Becausethenumberofpotentialpathsamessagecantakeisonlyone,thistypeoftopologyisnotthemostreliabletopology.Ifarouterfails,thenallofthatrouter’schildrenarecutofffromcommunicatingwiththerestofthenetwork.

2.3.3 MeshTopologyAmeshtopologyisthemostflexibletopologyofthethree.Flexibilityispresentbecauseamessagecantakemultiplepathsfromsourcetodestination.Ifaparticularrouterfails,thenZigBee’sselfhealingmechanism(akaroutediscovery)willallowthenetworktosearchforanalternatepathforthemessagetotake.Inourproject,oneofthescenariosistoinvestigatethisfeaturebyremovingarouterfromthenetworkduringoperation,

andseeingtheenddevicesfindanalternatepathtocommunicatewiththecoordinator.

3 ZigBeeSimulationUsingOPNETTheZigBeelibraryforOPNETisnewtoOPNETv14.0.Unfortunately,theZigBeemodelisincompleteandlackssomefunctionsofZigBee(willbediscussedintheDiscussionsandConclusionsection).ZigBeeperformsroutediscoverytodeterminetheoptimalpathformessagestotaketoitsdestination.ThissectionwilldiscusstheresultsofvariouscasessimulatedonOPNET;Steadycasewithsinglerouter,routerfailureleadingtoself‐healing,stabilityinthepresenceofmovingenddevices,caseofvariablebitratetransmitted,andsomelimitationsobservedpossiblyduetoanincompleteZigBeelibrarymodel.3.1 TrafficwithSingleRouterThisscenarioisageneralandsimplecasetoobservethebehaviourofaZigBeenetworkinOPNET.Here,wehaveacoordinatoronthefarright,withasinglerouterinthemiddle(routerinthefigurethat’scircled,hasasmallredcrossinthemiddlesignifyingthattherouterisdisabled,leavingROUTER_1theonlyfunctionalrouterinthescenario),andapairofenddevices.Theenddeviceswillbesendingdatawithaconstantbitratetothecoordinatorbyfirstsendingtotherouter,andthenallowingtheroutertorelaythemessagetothedestination.

Figure 5 – Mesh Topology [6]

7

Figure6‐SingleRouterAvailableScenario

Figure7belowshowsthetrafficbeingsentbythetwoenddevicesandreceivedbythedestinationcoordinator.Thebottomredline(overlappingwithgreen)isthetrafficbeingsentbytheenddevices,wherethebluelineshowsthetrafficbeingreceivedbythedestinationcoordinator.Itcanbeseenthatsteadystreamoftrafficissentwithoutdisruption.Smallspikesinatthebeginningofthesimulationareindicationsofmanagementandcontroltrafficsentandreceivedtodeterminethepresenceofdevicesaswellastheoptimalroute.

8

Figure7–Trafficfromenddevicestodestinationcoordinator

Figure8(below)showsthetrafficbeingreceivedandsent(routed)bythetworouters.Thedisabledrouterdoesnotreceiveorsendanytrafficasexpected.Theamountoftrafficbeingroutedisequivalenttothetrafficreceivedbythecoordinatorasseeninthepreviousfigure.

Figure8–Trafficsentandreceivedbythetworouters

9

Nexttwofiguresshowtheend‐to‐end(ETE)delayoftrafficfromtheenddevices.TheaveragedelayshowsconsistencyintheamountofETEdelay.ItshowsthatEND_DEVICE_0(blueline)initiallyconnectswiththerouter,showingmuchlessdelaycomparedtoEND_DEVICE_1(redline)asitisusingupthechannelresource.ItisworthnotingtheaverageETEdelayis0.016sto0.017s.

Figure9‐EndtoEnddelayfromenddevicestocoordinator(AsIs)

Figure10–EndtoEnddelayfromenddevicestocoordinator(Average)

Theresultsfromthisgeneralscenarioserveasagoodstartingpointforcomparisonforthefollowingscenarioswhereslightlymoreinterestingcaseswillbeobserved.Also,itwillhelpunderstandthevariationintheresultsintheprecedingscenarios.

10

3.2 VerificationofZigBee’sSelf‐HealingMechanismuponRouterFailureOnemethodofsimulatingafailureintherouteristomodifythecodetoaddinafailurecondition.However,thiswasdeemedtobebeyondscopeofthisproject1andanalternativemethodwasused.Thealternatemethodwastoprovideatrajectorytotheroutertomoveitoutofrangetotriggerself‐healing.Thiscanbeanalogoustoacaseofrouterbeingblownawayintheagriculturalapplicationduetoextremewinds.TwokeyfeaturesrequiredforthiscasescenariosaretheACKenableandunderstandingtherangecapabilityofZigBee.Placingtheenddevicestooclosetothedestinationcoordinatorwillresultintrafficbeingsentdirectly,ratherthanthroughtherouter,preventingobservationsfortheself‐healingfeature.AlsotheACKenablewasrequiredfortheenddevicestorecognizethatthefailureintherouterhasoccurred,nolongerreceivingandroutingtraffic,inordertotriggerroutediscovery.Figure11belowillustratesthetrafficpathfromenddevicestothecoordinatorpriortothefailure,whereFigure12illustratesthetrafficpathafterthefailureinthebottomrouter,triggeringtheself‐healingtofindanalternatepathtothedestination.

Figure11–Trafficpathpriorrouterfailure

1 OPNET did not disclose all the information for given library. Only the MAC layer Function Block and Header Block were provided (as well as packet formats and generic dra_power model). Rest of the code/implementation was hidden from view possibly due to work in progress.

11

Figure12‐Trafficpathafterrouterfailure

Figures13to17belowshowsthestatisticscollectedtoobservethebehaviourofself‐healing.Thefailureintherouteroccursatthefiveminutemarkofsimulatedtime.Figure13showsthetrafficsentbythetwoenddevices(bluelineoverlappingwithred)andtrafficreceivedbythetworouters.Thegreenlineshowsasharpdropatfiveminutesduetoitbeingmovedoutofrangeoftheenddevicesandstopsreceivingtraffic.Thelightbluelinealongthetopisthestationaryrouter.Itshowsthatrouterisreceivingtrafficfromallneighbouringdevicesinitially.ThisisduetothelackofabeaconingfeatureofZigBeeinthismodel,wherenon‐activedevicesareabletogointosleepmode,occasionallywakinguptonotifyitspresencetothenetwork.Despitetheheavytrafficreceivedbythestationaryrouter,itdoesnottransmit(routethetraffic)tothedestinationcoordinatorasitwillbedescribedinthefigure14and15.Thesharpspikenearthefiveminutetimeissimilartothespikeobservednearthestartofsimulation.Thisisinpartduetothemanagementandcontroltraffictransmittedbythedevicestoperformroutediscovery.Thespikeatthefiveminuteiscausedbytheself‐healingfeatureofZigBee,itsimplyrecognizesabsenceoftheoriginalpathandperformsroutediscoveryonceagaintofindthenextoptimalpathtoitsdestination.Itcanbeseenthatstationaryrouterpicksuptheenddevicetrafficandcontinuestoroutethetraffictothedestination.

12

Figure13–TrafficSentbyenddevicesandreceivedbyrouters

Figures14and15showthetrafficbetweenthetworoutersandthecoordinator(destination).Thebluelineshowsthetrafficreceivedbythecoordinatorwhiletheredandgreenshowsthetrafficsentbytherouters(tothecoordinator).Inthefirstfiveminutes,itcanbeseenthatstationaryrouterdoesnotsend(route)anytrafficdespitereceivinglargeamounts(seeninfigure8lightblueline).Thecoordinatorcontinuouslyreceivesthetrafficwithoneinstanceofagapatthefiveminutesimulatedtime.Thisiswhentheself‐healingroutediscoveryoccurs.Themobilerouterattemptstofinditsplaceinthenetwork(redspike).Oncetheinitialrouterfails,thestationaryrouterpicksupthetrafficandroutesittothedestination.

13

Figure14–Trafficfromrouterstocoordinator(overlaidview)

Figure15–Trafficfromrouterstocoordinator(stackedview)

Figures16and17showstheend‐to‐end(ETE)delayseenfromtheenddevicestothecoordinator.Thisisameasureoftimefromgeneratingtheapplicationpackettothetimereceivedbythedestination.Figure16showsthe“asis”ETEwherethesmallgapatthefiveminutesimulatedtimeshowspacketsdroppedwhiletherouterfailureoccurred.However,theaverageETEdelayisconstantthroughoutasseeninFigure17demonstratingtheconsistencymaintainedinnetworktrafficdespitearouterfailure.

14

Figure16–EndtoEnddelayfromenddevicestocoordinator(AsIs)

Figure17–EndtoEnddelayfromenddevicestocoordinator(Average)

TheresultsindicatethattheoverallperformanceofZigBee’sself‐healingdoesquitewell.Thetrafficgeneratedfromenddevicesweresuccessfullyreceivedbythedestinationcoordinatorasidefromsmallgapofsimulatedtimewindowshowingpacketsdropped.Also,theaverageETEdelayisverysimilartothatofsimplesinglerouterscenariofrombefore.

15

3.3 TrafficStabilityinPresenceofMovingEnd‐Devices–CBRBecauseZigBeenetworkscanbeusedasasensornetworkinsuchenvironmentsashospitals,andagricultural(livestock)environments,itisimportantforZigBeetoperformwellevenwhenenddevicesarenotstationary.Inthisscenario,wesetanenddeviceonapaththattravelsindifferentdirectionsinrangeof~300to~3000meters.Intheory,thefactthattheenddeviceismovingshouldnotmakeadifferenceintheamountoftrafficthattheroutersuccessfullyreceivesevenifitleavesthePANmomentarilyandthencomesbackinrange.Belowisafigureshowinghowthesimulationwasconfiguredincludingthetrajectorypathforthemobileenddevice.

Figure18‐TrafficandTrajectoryPath

Themobileenddevicemovesaroundthenetworkinacounter‐clockwisemotionwithinthenetwork.After4minutesand22secondsthemobilenodemovesoutofrangetemporarily,andthenitre‐entersthenetwork.

16

Thetwofiguresbelowshowthetrafficreceivedbythecoordinator,andthetrafficsentbytherouterandenddevices.

Lookingatthegraphsabovewetakenoteonsomeinterestingthings.Atabout1m30sthecoordinatortrafficincreasesby644bits/secondbecausethemobilenodecomesinrangeandsendstraffictoboththerouterandcoordinator.Nextat4:22therouterandcoordinatordataratesdecreaseby644bits/secondbecauseEnd_Device_2isoutofrange.Thenatabout5:04End_Device_2comesbackinrangeincreasingtherouterandcoordinatortrafficby644bits/second.Belowinfigure21theendtoendtrafficisshownforeachoftheenddevices.

Figure21–End‐to‐enddelayshowingpacketdroparound5minutesimulatedtime(AsIs)

Figure19‐TrafficSentFromEndDevices&Routersto

Coordinator

Figure20‐TrafficSentFromEndDevices&RouterstoCoordinator

17

Noticethatbetween4:22–5:04,theendtoenddelayisundefinedforEND_DEVICE_2becausethepacketsarebeingdroppedwhenit’soutofrange.FromtheseresultsweseethatZigbee’sperformanceisnotaffectedbyhavingmobiledevises.Thenetworkisabletoreleaseadeviceandletitre‐enterthenetworkwithoutanyslips.3.4 AssessingNetworkPerformancewithStationaryEnd‐Devices–VBRIntheeventthatthetrafficbeingsentisnotconstant,itisimportantforthenetworktostillbeabletoperceiveallinformationbeingsent.Inthisscenario,weconfiguretheenddevicestosenddataatavariablebitrate(VBR)insteadofaconstantbitrateusedintheotherscenarios.Theparametertobecomparedistheend‐to‐end(ETE)delay,andwewillcomparethisscenario’sdelaywithourfirstscenario’sdelay,whichisasimple2enddevice,1router,1coordinatornetworkwithconstantbitratetransfer.Thetopologyofthenetworkcanbeseeninfigurebelow.

Figure22–Samelayoutasscenario3.1usingvariablepacketrate

Inthefigurebelow,weseetheaveragetrafficbeingsentoverthenetwork.Asexpected,thetrafficbeingsentbythepairofenddevicesissuccessfullyreceivedbytherouter,whichisthensuccessfullyforwardedtothecoordinator.Thediscrepancyinthebeginningofthegraphbetweentherouter(lightblue)andthecoordinator(blue)canbeaccountedforbythesecondrouter(yellow),whichwaslefton,buthadnoenddevicesattachedtoit.Theinitialspikeofdataisduetothenetworksetup(routediscovery).Thesecondrouter(yellow)flatlinesbecausenodataisbeingrelayedbytherouter,andtherouteritselfisnotsendinganydataeither.

18

Figure23–Trafficsentbyenddevicestodestinationcoordinatorwithroutetraffic

Thegraphbelowshowsthatthedatabeingsentfromtheenddevicesareindeednotaconstantrate,butavariablebitrate.Thedatareceivedbythecoordinator(blue)theadditionofthedatabeingsentbythetwoenddevices(redandgreen).Forthissimulation,wedecidedtosenddatawithvariablepacketsizesvaryingfrom500‐1524bytes,ataconstantpacketrateof1packetforevery2seconds.

19

Figure24–TrafficSentFromEndDevicestoCoordinator

Eventhoughtheabovescreenshotsprovethesuccessofpacketsarrivingattheirdestination,itisimportantthatthedataarrivespromptly,orelsethedatacouldbeuselessbythetimeitarrivesatthedestination.Forthisreason,wemustchecktheend‐to‐enddelayofthepacketsbeingsent.Below,aretwographs,thatshowan“asis”andaverageend‐to‐enddelay.Becauseofthevaryingsizeofpacketsbeingsent,thedelayisnotaconstant,andinfigurexweseethevaryingdelay,whichcanbeaccountedforbythepacketsizes.Onfigure25,wecanseetheaveragedelayforthepacketsbeingsent.Theinitialspikecanbeattributedtothesetupofthenetwork.Afterapproximately3minutes,weseetheETEdelaycalmtoasteadystateofapproximately16milliseconds.

Figure25–EndtoEnddelayfromEndDevicestoCoordinator(AsIs)

20

Figure26–EndtoEnddelayfromEndDevicestoCoordinator(TimeAverage)

TheseresultsshowthatsendingdatawithaVBRdoesnotdecreasetheperformanceofaZigBeenetwork.Thelatencyofthenetworkisstillsteadyevenatthepresenceofvaryingpacketsizes.3.5 TestingtheZigBeeOPNETModelLimits–AddingAdditionalEndDevicesDuringoursimulationsofvariousscenarios,wenoticedthattheZigBeemodelinOPNEThassomelimitationsandunfinishedfeatures.Oneoftheselimitationsisconnectingonlyuptotwoenddevicesperrouter.WeknowfromtheZigBeespecificationsthataZigBeenetworkcanhavemorethan64000nodes,soforthisscenario,wesimplytriedtoconnect3enddevicestoasinglerouter,andseeiftheroutercanhandletheincomingtraffic.Figure27belowshowsthetrafficpathinthecaseoftworouterswiththreeenddevices.Alltheenddevicesmanagetoconnecttoaroutertosendtraffictothedestinationcoordinator.

Figure27–Caseoftworoutersandthreeenddevices

21

Thegraphbelowshowsthetrafficbeingreceivedbythecoordinator(blue)andthetrafficbeingsentbythethreeenddevices(redoverlapswithgreenandlightblue).Thisgraphindicatesthatthecoordinatorhassufficientbandwidthinthechanneltoreceivetheleveloftrafficcomingfromthreeenddevices.

Figure28–Trafficsentbytheenddevicesandreceivedbythecoordinator

Nextfigureshowsthetrafficpathwhenthebottomrouterisdisabled.ItcanbeseenthatEND_DEVICE_1(middleenddevice)failstoestablishatrafficpathtotherouter.ThisisaresultoflackingtheslottedCSMA/CAwithbeaconingfeaturealongwithGuaranteedTimeSlot.Oncetwooftheenddevicesconnecttoarouter,itsharestheconnection(duringintermittingtrafficsendtimes)butdoesnotallowforthethirdenddevicetojoin.Also,therouterisnotcapableofassigningthetime‐slottoscheduleinthethirdenddevice.

Figure29–Caseofsinglerouterandthreeenddevices

22

Theresultindicatesthattheenddeviceinthemiddle(END_DEVICE_1)wasunabletodeliveranyofthepacketsastheywerealldroppedenroute(redline)whiletheothertwoenddevices(blueoverlapwithgreen)experiencednodroppedpackets.

Figure30–Trafficfromthreeenddevicesdroppedenroute

23

4 DISCUSSIONSANDCONCLUSION4.1 OPNETZigBeeModelLimitationsThroughthisproject,wehavelearnedsomeofthelimitationsabouttheZigBeemodelinOPNET.ThemostnoticeablelimitationoftheZigBeemodelistheincompleteimplementationofthebeaconing2capability(“Note:BeaconEnabledmodeisnotcurrentlysupported.Thisattributeisaplaceholder”).Alsolacking,issupportforslottedCSMA/CAmodeandcontention–freeoperationmode.Thisseemedtopreventthedevicesfromhaving“fair”useoftheresourcebyschedulingtheenddevicestogainaccesstothechannel.OneofthedifficultiesattheearlystagesofthisprojectwasthelackofmentionintherangecapabilityofZigBee.SincetheOPNETZigBeemodelwasincompleteweexpectedanearlierversionofZigBeewithspecifiedrangeof~100meters.However,theOPNETZigBeemodelwascapableofhandlingrangesbeyond1200metersatdefaultsettingsfortransmissionpowerandreceptionpower.Thisinitiallycausedtheenddevicestoskipovertheroutersandcommunicatedirectlywiththecoordinators(showingnovariationintheresultsfor3.2).4.2 WhatWeLearnedThroughthisprojectweweregiventheopportunitytolearnnotjustanyprotocolandOPNETbutatechnologyofinterest.SwitchingovertoZigBeefromBluetoothpartwayduetolimitedavailabilityofaBluetoothlibraryfromOPNETrequiredsomecatchingup,possiblylimitingouropportunitytodoalittlemore,butthisprovideduswithanopportunitytolearnalotaboutZigBee,agrowingtechnology,intermsofgeneralapplicationandtechnicalaspects.Throughsimplifiedscenarioswithanassortmentofvariations,wewereabletobetterunderstandtheresultsinreasonabletimecomparedtohavingcomplexscenariosandresults,thenhavingtospendalotoftheprojecttimetryingtomakesenseofthings.WealsolearnedthevariousfunctionalitiesandmodelsOPNETiscapableof,despitetheZigBeemodelbeingonlyasmallportionofOPNET,aswellassomeofthelimitationsinusingOPNET.WeexperiencedabitofdisappointmentwiththeincompleteZigBeemodellibraryandhiddenimplementationoflayers(excepttheMAClayer).

2 Beacon enabled network allows for much longer battery life by allowing the device to go to sleep periodically only to wake to notify the network of its presence when not in use

24

5 REFERENCES[1]IEEEStandardforInformationtechnology‐Telecommunicationsandinformationexchangebetweensystems‐Localandmetropolitanareanetworks‐SpecificrequirementsPart15.4:WirelessMediumAccessControl(MAC)andPhysicalLayer(PHY)SpecificationsforLow‐RateWirelessPersonalAreaNetworks(WPANs),IEEEStandard802.15.4,2006.[Online].Available:http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1700009&isnumber=35824[2]N.Liang,P.Chen,T.Sun,G.Yang,L.Chen,andM.Gerla,“ImpactofNodeHeterogeneityinZigBeeMeshNetworkRouting,”inIEEEInt.Conf.Systems,ManandCybernetics,vol.1,Taipei,Taiwan,2006,pp.187‐191.[Online].Available:http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4273827&isnumber=4273788[3]J.Sun,Z.Wang,H.Wang,andX.Zhang,“ResearchonRoutingProtocolsBasedonZigBeeNetwork,”inThridInt.Conf.,IntelligentInformationHidingandMultimediaSignalProcessing,vol.1,Kaohsiung,Taiwan,2007,pp.639‐642.[Online].Available:http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4457629&isnumber=4457471[4]X.Xu,D.Yuan,andJ.Wan,“AnEnhancedRoutingProtocolforZigBee/IEEE802.15.4WirelessNetworks,”inSecondInt.Conf.,FutureGenerationCommunicationandNetworking,Hainan,China,2008,pp.294‐298.[Online].Available:http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4734107&isnumber=4734039[5]DigiInternational,“ZigBeeWirelessStandard,”DigiMakingWirelessM2MEasy.[Online].Available:http://www.digi.com/technology/rf‐articles/wireless‐ZigBee.jsp.[Accessed:2009‐02‐28].[6]Jennic,“WelcometoJennic’sZigBeee‐learingCourse,”2007.[Online].Available:http://www.jennic.com/elearning/zigbee/files/content_frame.htm[7]Mesh‐MatrixInc.,“WhatisZigBee,”2007.[Online].Available:http://mesh‐matrix.com/en/technology/tech_zigbee.aspx[8]P.Jurčík,A.Koubâa,M.Alves,E.Tovar,andZ.Hanzálek3,“ASimulationModelfortheIEEE802.15.4Protocol:Delay/ThroughputEvaluationoftheGTSMechanism,”[Online].Available:http://dce.felk.cvut.cz/hanzalek/publications/Hanzalek07g.pdf