IEEE 802.15.4 and ZigBee - polito.it · Bluetooth) • Rely on ZigBee Alliance for marketing and compliance (IEEE 802.11b and WiFi ) • PHY and MAC layers only (upper by ZigBee)

1

Wireless Sensor NetworkCopyright – Tutti i diritti riservati

Dario Rossi, Politecnico di Torino

IEEE 802.15.4 and ZigBee IEEE 802.15.4 and ZigBee 6-8 june 2006

Dario RossiDario RossiPolitecnico di [email protected]

2



Copyright

• Questo insieme di trasparenze (detto nel seguito slides) è protetto dalle leggi sul copyright e dalle disposizioni dei trattati internazionali. Il titolo ed i copyright relativi alle slides (ivi inclusi, ma non limitatamente, ogni immagine, fotografia, animazione, video, audio, musica e testo) sono di proprietà degli autori indicati a pag. 1.

• Le slides possono essere riprodotte ed utilizzate liberamente dagli istituti di ricerca, scolastici ed universitari afferenti al Ministero della Pubblica Istruzione e al Ministero dell’Università e Ricerca Scientifica e Tecnologica, per scopi istituzionali, non a fine di lucro. In tal caso non è richiesta alcuna autorizzazione.

• Ogni altra utilizzazione o riproduzione (ivi incluse, ma non limitatamente, le riproduzioni su supporti magnetici, su reti di calcolatori e stampate) in toto o in parte è vietata, se non esplicitamente autorizzata per iscritto, a priori, da parte degli autori.

• L’informazione contenuta in queste slides è ritenuta essere accurata alla data della pubblicazione. Essa è fornita per scopi meramente didattici e non per essere utilizzata in progetti di impianti, prodotti, reti, ecc. In ogni caso essa è soggetta a cambiamenti senza preavviso. Gli autori non assumono alcuna responsabilità per il contenuto di queste slides (ivi incluse, ma non limitatamente, la correttezza, completezza, applicabilità, aggiornamento dell’informazione).

• In ogni caso non può essere dichiarata conformità all’informazione contenuta in queste slides.

• In ogni caso questa nota di copyright non deve mai essere rimossa e deve essere riportata anche in utilizzi parziali.

3



Outline

Introduction and context• What is IEEE802.15.4• Relationship with ZigBee• Top-down overview

The standards in details• Physical Layer• MAC-Layer• Network-Layer

4



IEEE 802.15.4 + ZigBee Stack

5



IEEE 802.15.4What it is not

• A WLAN• A Bluetooth replacement

(e.g., no isochronous voice)

• Support for multimedia, TCP/IP or other high data rate applications

• A system, network or application set

MCU requirement• 8bit, 4MHz, 32kB ROM, 8

kB RAM

What it is• A WPAN Standard

optimized for low-power low data-rate apps with simple or no QoS needs

• Lower power, lower cost than other WPANs (e.g., Bluetooth)

• Rely on ZigBee Alliance for marketing and compliance (IEEE 802.11b and WiFi )

• PHY and MAC layers only (upper by ZigBee)

6



ZigBee Alliance

What it is not• An open standard-

defining organization • Officially associated

with IEEE• Associated with the

Bluetooth SIG• Specifying the PHY or

MAC layersZigBee Motto

• Wireless Control that Simply WorksTM

What it is• An industry consortium of

more than 150 farms, promoting 802.15.4

• Semiconductor houses, system integrators, app developers and users

• Marketing and compliance certification for 802.15.4

• Network and above (lower layers by IEEE802.15.4)

7



Historical Notes and RoadmapPast and Present•1998: ZigBee-style networks definition begins•2003, May: The IEEE 802.15.4 standard was completed•2003, Aug: Philips Semiconductors left the Alliance•2004, Oct: ZigBee had more than 100 members in 22 countries•2004, Dec: ZigBee specifications were first ratified •2005, Apr: Alliance had grown to more than 150 companies.•2005, Jun: ZigBee Specification 1.0 released •2006: the estimated cost (for very high volumes)

– of the radio for a ZigBee node is about $1.10 to the manufacturer– Bluetooth chips are now sold under $3.

Future•ZigBee is working on version 1.1,

– take advantage of 802.15.4b (still in draft) security improvements – most notably CCM*, that provides greater flexibility

8



Context: IEEE.802.15Harald 802.15 WG

9



IEEE 802.15 - General

Wireless Personal Area Networks (WPANs)• IEEE 802.15.1 – Bluetooth• IEEE 802.15.3 – High data rate WPAN• IEEE 802.15.4 – Low data rate WPAN

WPANs Characteristics• Communication within human space• Short Range, Low Power, Low Cost• Small or very big network sizes• Low or very high data rates

10



(One missing piece)

IEEE 802.15.2• Coexistence between 802.15 and 802.11• Traffic management rules for coexistence

11



IEEE802.15 Taxonomy

Low Rate WPAN (LR-WPAN)Simple, Low cost, Low power Sensor/actuator networksData rates: 20-250 kbps

12



Overview outline

ZigBee • Application and traffic• Security modes• Network topology and devices• Routing techniques

IEEE 802.15.4• Medium access control• Physical layer

ZigBee vs Bluetooth

13



ZigBee: Application

Home/OfficeAutomation

Entertainment and Toys

Monitoring: Environmental,Industrial and Health-care

Security, Location and Asset Tracking

Emergency and DisasterRelief

Networked wireless sensor and actuators

14



ZigBee: Traffic and QoS

Traffic types• Periodic data

– e.g. Sensor data• Intermittent data, generated once a while

– e.g. Light switch traffic• Repetitive low latency data

– e.g. Mouse device traffic

Quality of Service• No explicit QoS support in network nor lower layers• May implement QoS mechanisms at higher layer,

but the burden is entirely left to the application

15



ZigBee: SecurityMAC Layer

• Access control list (ACL)– Ability to select partners

• Data Encription– Symmetric cypher avoid snoop

• Frame Integrity – Use message integrity codes

(MIC) to avoid data modification• Sequential freshness

– Reject replayed frames

Network Layer• Security Service Provider SSP

– Retrieves and apply keys• SSP primitives

– Applying/removing security

Available Security Modes• Encryption at MAC layer

– AES in Counter (CTR) mode• Authentication:

– AES in Cipher Block Chaining (CBC-MAC) mode

• Encryption and Integrity– AES in Counter with CBC-MAC

(CCM) mode

Upper layers• Set up keys and key exchange• Determine the security mode• IEEE802.15.4b and ZigBee 1.1

going toward more flexible security mode (CCM*)

16



ZigBee: Topology

PAN Coordinator•One per network•Possibly backup

Full Function Device (FFD)•Any topology•Coordinator capable•Talks to any other device

Reduced Function Device (RFD)•Limited to be leaf device•Cannot route, coordinate•Talks only to a router•Very simple implementation

17



ZigBee: Routing

• Default routing is distributed and tree-based–Simple devices do not have to maintain extensive tables

or perform route discovery–Paths can be longer than necessary – extra traffic, more

likely to fail• Routers have capability to discover shortcuts

– Maintain routing table of form (destination, next device)– Request/response protocol for shortcut discovery based

on Ad-hoc On Demand Distance Vector (AODV) protocol• Combination of AODV, Motorola’s Cluster-Treealgorithm and Ember Corporations GRAd.

18



IEEE802.15.4: Medium Access ControlMain channel access mechanism

• Carrier Sense Multiple Access with Congestion Avoidance (CSMA/CA)

Beacon-enabled• Slotted acces, synchronization, management• Enables data rate guarantees, low latency

Non Beacon-enabled• Unslotted access

19



IEEE802.15.4: Medium Access ControlFrame types• Beacon• Data• Ack • Command

Transmission modes• Coordinator to device

– CSMA/CA or guaranteed (beacon enabled only)

• Device to coordinator– CSMA/CA or guaranteed (beacon enabled only)

• Device to device– CSMA/CA only

20



IEEE802.15.4: Physical Layer

Radio frequencies• 868 MHz (Europe) and 915 MHz (USA)• 2.4 GHz (Worldwide)

Modulation techniques• O-QPSK with half-sine pulse shaping and

Direct Sequence Spread Spectrum (DSSS)Required functionalities

• Energy Detection (ED)• Clear Channel Assessment (CCA)• Link Quality Indication (LQI)• Channel selection

21



ZigBee vs Bluetooth• Smaller packets over large network• Primarily static• Infrequently used devices• Home automation, sensors, remote controls…• Device batteries rarelyreplaced or charged• Small powered fraction• DSSS, 62.5 Ksymbol/s• PHY rate 250 Kbps• Network join time = 30ms • Sleeping-> active = 15ms

• Larger packets over small network• Ad-hoc networks• File transfer• Screen graphics,pictures, mobile phones,PDAs, etc…• Expects regular charging of devices• Some host powered• FHSS, 1 Msymbol/s• PHY rate 720 Kbps• Network join time = 3s• Sleeping-> active = 2s

22



ZigBee vs Bluetooth

23



Detailed Tutorial Outline

Foreford• IEEE Primitives

Networking on embedded devices• IEEE 802.15.4 PHY

–Transmission techniques, RF chip requirements and hardware features

• IEEE 802.15.4 MAC–Inter-device communication algorithms

and MAC layer management• ZigBee NWK

–Topology discovery, formation, maintenance

24



Foreword

ServicesCapabilities offered to higher layer by building functions over services of the next lower level

PrimitivesDescribe the service information flow

25



IEEE 802.15.4 PHY

26



PHY: Tasks

The PHY is responsible for the following tasks:• Channel frequency selection• Data transmission and reception• Activation and deactivation of the radio transceiver

• ED within the current channel• LQI for received packets• CCA for CSMA-CA

27



PHY: Functional Blocks

The PHY provides two services:

• PHY Data Service–accessed through

the PHY data SAP (PD-SAP)

• PHY ManagementService

–accessed by PHY Layer Management Entity (PLME) SAP (PLME-SAP).

28



PHY: Frequency & Channels

868MHz/915MHz

2.4 GHz

868.3 MHz

Channel 0 Channels 1-10

Channels 11-26

928 MHz902 MHz

5 MHz

2 MHz

2.4 GHz

2.4835 GHz

29



(Comment on 2.4GHz Cohexistence)

30



PHY: Primitives

PHY Data Service• PD-DATA – exchange data packets between MAC and PHY

PHY Management Service• PLME-CCA – clear channel assessment• PLME-ED – energy detection • PLME-GET – retrieve PHY PIB parameters• PLME-SET – set PHY PIB parameters• PLME-TRX-ENABLE – enable/disable transceiver

31



PHY: Service Data Unit

0000 ...0000 11100101

32



PHY: Data Service

MAC PHY PHY

PD-DATA.request( *p,

pLen )

PD-DATA.indication( *p,

pLen, LQI )PD-DATA.

confirm ( status = { TX_OFF,

RX_ON, SUCCESS }

)

33



PHY: Radio State Machine

Call to PLME-SET-TXR-STATE.request (x)Returns PLME-SET-TXR-STATE.confirm(y)

RX_ON

TRX_OFF

BUSY_RX

TX_ON

FORCE_TRX_OFF

BUSY_TX

RX_OFFTX_ON

TX_OFFRX_ON

34



PHY: 2450 MHz Specifications

Bit-to-symbol mapping• Clearly, all the PPDU is processed• 4 bits per symbol (b0 ... b3, b4 ... b7)• LSB processed first (b0 ... b3)

35




...

Symbol-to-chip mapping• 32-chip long pseudo random sequences• Related through cyclic shifts and/or conjugation (inversion of odd-indexed chip value)

36



PHY: 2450 MHz SpecificationsOffset-QPSK Modulation

• Each symbol (i.e., 32-chips sequence) is modulated over the carrier with half-sine pulse shaping

– Even chips on the in-phase (I) carrier– Odd chips on the quadrature (Q) carrier

• Q-phase chips delayed by Tc = 1/ChipRate– Data Rate is 250 kbps– Symbol Rate is 62.5 kBaud (4 bits/symbol)– I+Q ChipRate is 32 times the symbol rate = 2 Mchip/s

37




Pulse shape

MSB

LSB

38



(Comment on Modulation Choice)Comparison with other IEEE wireless PHYs

16-ary modulation: 16 symbols pseudo-orthogonal (in I and Q)

.15.4 .11b .15.1 Binary16ary

Robust modulation to protect from wireless channel errors and compensate lower data rate

39



PHY: 2450 MHz Requirements• Transmit power spectral density (PSD) mask

– 100 kHz resolution – relative to measured maximum in |f-fc|<1MHz

• Required receiver sensitivity below –85 dBm

40



PHY: 868/915 MHz Specifications

41



PHY: General RequirementsReceiver jamming resistance

Turnaround time (TX-RX and RX-TX)• 12 symbols

Minimum/Maximum transmit power• At least –3dBm / According to local regulation

Maximum input level• Greather than –20 dBm (relative to 1 mW)

AlternateAdjacent (signal 3dBm over sensitivity)

42



PHY: General Requirements

E=(δI,δQ)

S=(I,Q)

Error vector magnitude (EVM)•Scalar distance between the received and the ideal phasors

•Residual noise and distorsion after stripping away an ideal version of the signal

Maximum EVM •35% over 1000 Chips

43



PHY: General RequirementsReceiver Energy Detection (ED)

• Intended for use by a network layer (channel selection)• Received power estimate (over an 8 symbols period)• 8 bit integer

– 0x00 => Energy < Sensitivity + 10 dB– Spawn over range of 40 dB– Linear dynamic with 6 dB accuracy

Link Quality Indication (LQI)• Characterization of strength/quality (use out-of-scope)• Implemented by ED, SNR or their combination• 8 bit integer, with at least 8 different values

– minimum (0x00) to maximum (0xFF) quality

44



PHY: General Requirements

Clear Chanel Assessment (CCA)• Channel sensing feature to be used by the MAC layer

• At least one of the three modes:–CCA1: Energy above threshold–CCA2: Carrier sense only (i.e. 802.15.4 signal)–CCA3: CCA1 and CCA2

• Energy threshold – Energy > Sensitivity + 10 dB

• CCA detection time–Equal to 8 symbol period

45



(PHY: Specifications Recap)

46



IEEE 802.15.4 MAC

47



MAC: Tasks

MAC layer handles PHY accessand the following tasks:•Employing the CSMA-CA mechanism for channel access•Providing a reliable link between two peer MAC entities•Generating network beacons if the device is a coordinator•Synchronizing to the beacons if router or end device•Supporting PAN association and disassociation•Handling and maintaining the GTS mechanism•Supporting device security

48



MAC: Functional BlocksThe MAC provides two services:

• MAC Data Service–accessed through the

MAC common part sublayer (MCPS) SAP (MCPS-SAP)

• MAC ManagementService

–accessed by MAC Layer Management Entity (MLME) SAP (PLME-SAP).

Interface that allows the management entity to use the data services

49



MAC: Functions OutlineFunctional description

•Reliable data transmission •Channel access and CSMA/CA•MAC framing in details•Start and maintain a PAN•Conflict detection and resolution•Join and leave a PAN•Indirect transmission •Use and Management of GTS•Synchronization issues

(MAC Primitives listing is too cumbersome)

50



MAC: Reliable Transmission

Ok

DataLoss

AckLoss

51



MAC: Channel Access

Contention Access Period•Nodes willing to transmit contends the medium with CSMA/CA•Nodes may transmit to the coordinator or peer-to-peer•CAP has guaranteed minimum length (except GTS maintenance)

SleepContention Free Period•Nodes granted of the use of Guaranteed Time Slots (GTS, 7 max) may, depending on GTS direction:

•transmit to the coordinator or •receive from the coordinator

BeaconCoordinator sends beacon for synchronization, GTS and network management

52



SD = B * 2SO

BI = B * 2BO

MAC: Channel Access

Tc = 1/2MHz = 0.5 µs Ts = 32Tc = 16 µs B = aBaseSuperframeDuration ( 60 * 16 * Ts = 15.36 ms )BO = macBeaconOrder ( 0 ≤ BO ≤ 14 )BI = B * 2BO ( B ≤ beacon interval ≤ ~252 s)SO = macSuperframeOrder ( 0 ≤ SO ≤ BO ) SD = B * 2SO ( B ≤ superframe duration ≤ BI )

aBaseSlotDurationaNumSuperframeSlots

53



MAC: Channel Access

Non Beacon-enabled PANs• Access by unslotted CSMA/CA

–Data and Command frames• Exceptions to CSMA/CA

–Acknowledgement frames–Short response messages to Command frames

• MAC parameters–BO = macBeaconOrder = 15–SO = macSuperframeOrder = 15

54



MAC: Channel AccessInterframe spacing (IFS)•MAC needs a finite amount of time to process data received by the PHY•These gaps are take into account in the beaconed CSMA/CA

Long Ack

Tack

Long > aMaxSIFSFrameSize = 18 Bytes MPDUaT = aTurnaroundTime = 12 TsTack = [ aT, aT + aUnitBackoffPeriod ] = [ 12, 32 ]LIFS = 40 Ts SIFS = 12 Ts

Short Ack

Tack SIFSLIFS

Long Short

SIFSLIFS

55



MAC: Slotted CSMA/CA

aMaxBE=0

macMinBE=3

Three variablesNB: number of backoffsCW: contention windowBE: backoff exponentImportant infos•Slotted access is clocked onmacBackoffUnitPeriod = 20 Ts•MAC ensures PHY starts TX on the boundary of a Backoff•Backoff period of every device is aligned to PAN beacon•Twice CCA to compensate drift•Backoff freezes across CAPs•Battery life extension: device awake only 6 backoff each CAP

56



MAC: Slotted CSMA/CA

aMaxBE=0

macMinBE=3 aMaxBE=5

macMaxCSMABackoffs=4

Check if whole TX (2*CCA + frame + Tack + ack + IFS) ends before GTS starts;Else freeze until next CAP

57



aMaxBE=5

macMaxCSMABackoffs=4

Two variablesNB: number of backoffsBE: backoff exponentCW: contention window

Important infos•Access is unslotted•Unit of time is however macBackoffUnitPeriod•No superframe boundary check possible,obviously•Backoff periods are not aligned across devices •CCA is performed once

MAC: Unslotted CSMA/CA

58



(Comment)

TinyOS does not fully support IEEE 802.15.4• MICAz and Telos platforms

–Use ChipCon CC2420 radio–Thus, they are 802.15.4-PHY compliant

• Use compliant MAC-frames (but not access)–Thus, can receive 802.15.4 MAC frames as well–MAC layer is called B-MAC

» No superframe support at all–Non-beacon enabled mode is “almost” 802.15.4

» Can be tuned to resemble IEEE 802.15.4 very closely» Btw, many WiFi cards are not 802.11b compliant» Btw, many TCP implementation are not RFC compliant

59



MAC: Framing

General to all framing types• Beacon• Data• Ack• Command

60



MAC: Framing

61



MAC: Framing•Security flag•Frame pending flag

•During CAP if beaconed•Anytime otherwise

•Ack request flag•Intra PAN flag

•Omit PAN fields if set•Specify both PANs if unset

62



MAC: Framing

63



MAC: Framing

Coordinator BeaconmacBSN++

• Init as random value

Data, Ack, CommandmacDSN++ unless

• is Ack, • during CSMA rtx

PAN identifierMay be absent if Intra-PAN May be 0xFFFF for all PANs

Device address May be absent if Coordinator16 or 64 bytes long

• Depending on address type field of FCF

64



MAC: Framing

Payload size•Depends on MHR fields length, MPDU < 128 bytes•May be zero in special cases (coordinator late response to polling in non-beaconed PAN)•Beacons also can carry (up to 75 bytes of) payload, which may be used by upper layer network maintenance

Frame Check Sequence (FCS)•16bit ITU-T polynomial Cyclic Redundancy Check

65



MAC: Beacon Framing

66



MAC: Other Framing

AckDataCommand

67



MAC: Other Framing

68



MAC: Start and Maintain PANsED scan

• Measure peak energy for every channel (possibly < all)– Used by new PAN coordinators to select PHY channels

Channel scan• Allows FFD locate any coordinator transmitting beacon

– Coordinator may choose its new PAN identifier– Device may choose PAN to associate with

• Two modes– Active: send beacon request command and wait for reply– Passive: simply listen to beacons

• Many subtelties and gory details– Listening times, what to do on timeout, how to set addresses

and fields, what to do on reception of other commands, ...

69



MAC: Start and Maintain PANsOrphan Channel Scan

• Used by device that failed– to transmit many data packets (definitively)– to receive many beacons (possibly)

• During orphan scan, all frames exceptRealignment commands are discarded

Simplified message exchange• For every channel

– Device sends to Coordinator an Orphan Notification– Device waits for Coordinator response– Coordinator checks if Device belongs to its PAN

» In which case, sends a Realignment Command» Otherwise, simply ignore the request

– If device receives Realignment command, abort scan

70



MAC: Conflict Detection/ResolutionConflict detection

• Device– Receives beacons with == PANid, but != source address– Sends a Conflict Notification command to PAN Coordinator

• Coordinator– Receives a beacon on its PAN, or a Conflict Notification cmd

Conflict resolution• Coordinator

– Performs Active Channel scan, select PANid (out-of-scope)– Broadcast a Realignment with both old and new PANids

• Device – Updates its PANid on reception of the Realignment command– On loss of the Realignment, will likely perform an Orphan Scan

71



MAC: Join and Leave PANsAssociation

• Device: Scan channels and choses PAN id• Coordinator: If permit association and free room

– Sends Ack, which do NOT imply succesfull association– Device waits for Coordinator reply

• Coordinator: – Replies,using indirect transmission, with failure or success– 0xFFFE special meaning: have to use 64 bit address

Disassociation• Started by

– Coordinator: use indirect transmission– Device: send dissociation command

• Device is considered to be dissociated in any case (even if no Ack is received)

72



MAC: Indirect Transmission• Communication between coordinator

and devices (using CSMA/CA)• Transaction instigated by the device

– Beacon-enabled: Coordinator advertize pending messages in beacon

– Non Beacon-enabled: Devices poll coordinator at application specific rate

• Coordinator gory details– Capable of <2 transaction? Overflow on next – Capable of >7 transaction? Advertizes 7 at most– Transactions are FIFO queued: no QoS support– Transaction expires after 0x01F4 Superframes– Coordinator reply with pending flag set

» if pending data exists or cannot immediately check

73



MAC: Indirect TransmissionMessage sequence

• Coordinator: May advertize pending data in Beacon• Device

– Beacon-enabled: Sends Data Request command (CAP)– Non Beacon-enabled: Polls Coordinator for data

• Coordinator: sends Ack with pending field set – Unless sure that no data is pending for the device

• Device: may receive a frame with a payload– Zero (no data pending after all) or non-zero– Pending flag set in FCS imply more data is pending

Important notes• Indirect transmission is NOT a GTS transmission• If the device had downstream GTS allocated slots,

they shall be used instead of CAP

74



MAC: Use and Management of GTS• Guaranteed Time Slots (GTS)

– Used for comunication involving coordinator– Only used by short address devices tracking beacons– Devices may transmit on both CAP and CFP’s GTS– Direction

» Coordinator -> Device: Device turns RX on (must be able of» Device -> Coordinator: Device turns TX on receiving acks)

• Coordinator GTS Management– Up to 7 GTS managed by the Coordinator only– Coordinator ensures CAP length > minimum CAP length– FIFO and arbitrary length, so no QoS – May take as long as 4 Superframes to setup– Allocated GTS expires soft-state after 4 Superframes– Deallocation may be tricky due to need for GTS defragmentation

75



MAC: Synchronization Issues

Aquiring Synchronization• Synchronization conditions

– Sufficient condition: PAN id == associated PAN id– Necessary condition: PAN id != 0xFFFF

» may be message sent for critical network maintenance

• Timestamping – should be performed at the same symbol for every frame– The actual symbol choice is implementation specific– Should be the same of the outgoing beacon frame

• Beacon may be tracked once or periodically– If too many missed notify higher layer of Sync loss– Must wake up slightly prior to the next expected beacon

frame transmission time

76



ZigBeeNKW

77



ZigBee Specifications

Completes IEEE 802.15.4•From the network (NKW)•To the application (APL)

78



ZigBee: APL

APL hides core ZigBee

functions

NWK totally transparent to the APL

79



Or very complex (many cases) even for simple actions (Disconnect)

Either transparent

ManagementZigBee: NWK

Focus on NWK Routing and Topology

80



NWK: Routing Tasks• Required

– Relay data frames on behalf » of higher layers / or other ZigBee routers

– Participate in route discovery » possibly on behalf of end devices

– Participate in local and end-to-end route repair– Employ the ZigBee path cost metric

• Optional– Maintain routing tables in order to remember

best available routes– Initiate route discovery on behalf

» of higher layers / or other ZigBee routers– Initiate end-to-end or local route repair

81



NWK: Outline

NWK Functions Outline• Distributed Assignment Function • Routing Cost Function • Routing Data Structures• ZigBee Forwarding Engine• Hierarchical Routing• Route Discovery and Maintenance• NWK and MAC

–Beacon scheduling on multi-hop networks–ZigBee information in MAC payload

82



NWK: Distributed Assignment Function• Aim

– Provides finite pool of addresses to every parent– Used in both NWK manage and RFD routing– Controlled by NWK tree depth

• Auxiliary Function Cskip(d)– Lm: maximum tree depth– Cm: maximum number of children– Rm: maximum number of router child per parent– Cskip: size of address sub-block distributed by each

parent at depth d to its router capable child

(corrected since previous formulation)

83



NWK: Distributed Assignment FunctionAddress Assignment• Cskip(d)=0

–Cannot accept children–ZigBee end device

• Cskip(d)>0–Can assign addresses–1st address = 1+Aparent–nth address = n+Aparent+Cskip(d)*Rm

» with 1 ≤ n ≤ (Cm – Rm)

Alternatively• Free to provide own assignment function

84



NWK: Distributed Assignment FunctionPossible issue

• A parent may exhaust its device list while others may still have room

• Device must find another parent, and may not be able to associate

Partial solution • Move tree branches• But tradeoffs with

table-based routing

85



NWK: Routing Cost Function

Cost Function

Possible issue• Is unclear how pl should be measured • Specification vaguely propose to use LQI• However, signal strength and packet loss

are non-trivially related in WSN

0 1 2 3 4 5 6 78

0.25 0.5 0.75 1

C{l}

Pl = Packet delivery(changed since previous formulation)

86



NWK: Routing Data Structures

Three different structures• Routing table

–Set of (Dest,Status,NextHop) touples–Long lived and persistent

• Neighbor table –More complete Routing table (5-15 fields)–Long lived and persistent

• Route discovery table–Similar to AODV routing discovery tables

» Difference is in the use of ZigBee cost function–Soft state uses during path discovery

87



NWK: Forwarding

No

Neighbor Table

MAC Frame •Broadcasted AND•Passed to higher layer

APL Data•Broadcasted only

88



NWK: Forwarding

No

RoutingTable

Route DiscoveryTable

Hierarchical Routing

89



NWK: Hierarchical RoutingDistributed Next Hop Choice A=Router d=depth D=device NH=NextHopNH = ( ) ?

:Test if D is decendant

(corrected since previous formulation)

Basically•If D is descendant

–Knows if macRxOnWhenIdle from neighbor table–May use 802.15.4 Indirect Transmission Feature

•Otherwise route to parent

90



NWK: Route Discovery

91



NWK: Route Discovery

Route Discovery • Ad-hoc and On-demand• Hierarchical for RFD• Route request starts (S,id,C0,T) • Broadcast toward D,

– Request follows forward path and– intermediate nodes Xi sets backward (S,id,Xi-1,ΣCi,T)

• Once reached the destination, its parent or an up-to-date (id ≤ id’) node,

– Route reply (D,id’’,C0,T) starts following the backward path – and setting up the forward (D,id’’,Xj+1, ΣCi,,T),

• Routes of nodes that are not on the reverse path automatically disappear after timeout T

92



NWK: Route Request (RREQ)

93




Valid = (( Prev Hop == Parent ) && ( Originator != Descentant )

) || (( Prev Hop == Child ) && ( Originator == Descentant )

)

94




Since no Routing Capability,uses Hierarchical Routing

Directly reply to the message sender

95



NWK: Route Request (RREQ)Also create reverse Route, destined to RREQ originator, with current sender as next hop

Respond using Reverse Route

96




Broadcast RREQ(jittered transmission; jitter possibly growing with to the link cost)

97



NWK: Route Reply (RREP)

98



NWK: Route Reply (RREP)

HierarchicalRouting

RREP ends, update entry and make it persistent

Reverse Lookup in Route Discovery Table (i.e., for the entry matching the RREQ identifier and source address, and extract the sender address)

99



NWK: Route Maintenance

ZigBee assumes that (but out-of-scope)• App keeps per-link failure counter, possibly time-windowed

• App triggers route-repair when failure > threshold

• App, however, avoid spawning route repair too frequently

–as it may unnecessary flood the net• Removal of dead links left as exercise for the implementer

100



NWK: Route Maintenance

At node X•Node’s Y failure counter exceeds threshold•X starts Route Discovery with Repair field set•X avoids forwarding any packet to Y during repair

At node Y•Y may be aware of failure and start Orphan Scan•If the Orphan Scan fails, Y will try other PANs•If all that fails, user intervention may be needed

101



NWK: Interactions with MACScheduling beacons on multi-hop nets• For distributed choice of non overlapping beacon

intervals, every node must know:– The Beacon time of its neighbors– The Beacon time of its neighbors’ parent

• Intuitively, such knowledge guarantees that every node will not chose a beacon time during which

– Either theit neighbors or the neighbors’ parent are active– Which will finally converge in spreading out beacon times

• How to – It sufficies to include, in the beacon payload, the time

offset from parent beacon – Then, a modification to the MAC layer MLME, is needed to

allow to specify the beacon start time

102



NWK: Interactions with MAC

ZigBee Payload on the MAC Beacon

103



References

LAN-MAN Standards Committee of the IEEE Computer Society, Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal AreaNetworks (LR-WPANs), IEEE Std. 802.15.4-2003

ZigBee Alliance, ZigBee Specification Version 1.0, Document 053474r06, December 2004, Last edited 27th June 2005

Documents

IEEE 802.15.4 and ZigBee - polito.it · Bluetooth) • Rely on ZigBee Alliance for marketing and compliance (IEEE 802.11b and WiFi ) • PHY and MAC layers only (upper by ZigBee)