ENSC 427: COMMUNICATION NETWORKS ZIGBEE MESH NETWORK...
Transcript of ENSC 427: COMMUNICATION NETWORKS ZIGBEE MESH NETWORK...
ENSC427:COMMUNICATIONNETWORKS
ZIGBEEMESHNETWORKSIMULATIONUSINGOPNETANDSTUDYOFROUTINGSELECTION
Spring2009
FINALPROJECT
SamLeungWilGomezJungJunKim
http://www.sfu.ca/~mingl/[email protected]
[email protected]@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