16
Wireless Control That Simply Works Strategies for user-deployed networks European ZigBee Developers' Conference, Munich, June 30th - July 1st 2009 Amyas Phillips [email protected] 1 Target audience: developers of consumer ZigBee apps Structure: home environment - characterise links - typical user-land problems -strategies for helping user deal with them Wireless control that simply works .. most of the time.. wireless deployments are never completely predictable .. skilled installers adapt eac deployment to its circumstances .. mass market products do need to simply work .. when they don't, they need to be simply fixable

Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

  • Upload
    aewp2

  • View
    1.103

  • Download
    2

Embed Size (px)

DESCRIPTION

Amyas Phillips, chief design engineer at Cleantech 100 company Alertme.com, talks about his experiences making a ZigBee consumer product highly usable.

Citation preview

Page 1: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Wireless Control That Simply Works

Strategies for user-deployed

networks

European ZigBee Developers' Conference, Munich, June 30th - July 1st 2009

Amyas [email protected]

1

● Target audience: developers of consumer ZigBee apps● Structure: home environment - characterise links - typical user-land problems -strategies for helping user deal with them● Wireless control that simply works .. most of the time.. wireless deployments are never completely predictable .. skilled installers adapt each deployment to its circumstances .. mass market products do need to simply work .. when they don't, they need to be simply fixable

Page 2: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Home..ZigBee @ Home

2

● Home applications: Philips / Schneider HOMES ... Smart Energy .. Alertme..

Page 3: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Home..is where the wireless network is

The Home

other ZigBee environments

3

● What's special about the home?● most innocuous..● least controlled == most challenging● where will users put your nodes? ... primary vs secondary functions● prone to change

Page 4: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Install time:learning through play• What Users Want

– miracles?– safety

• Commissioning– learn about network

membership, joining• Placing

– painless site survey: range testing

– learn about range– keep link margin in

reserve?

Dual-Band AntennaConsiderations3Com offers wireless APs and bridges thatoperate in both 2.4 GHz (802.11b/g) and 5GHz (802.11a) radio spectra. Dual-bandantennas allow you to design wirelesscoverage for both 2.4 and 5 GHz applications.Radio waves perform differently in thesedifferent frequency ranges, however, so thereare a number of things to keep in mind whendesigning your dual-band wireless network.

Power Dissipation: Due to the physics ofradio wave power dissipation, 5 GHz signalsof equal power output only travel approxi-mately half the distance of 2.4 GHz signals.This difference can be compensated for tosome degree by increasing the gain of the 5GHz antenna element. Keep in mind thatincreasing the gain means that the coveragepattern will narrow. Study the antennacoverage patterns and installationrequirements carefully to ensure that you areproviding adequate coverage in the requiredfrequencies.

Absorption and Penetration: Radio wavesin 2.4 GHz are absorbed differently thanwaves in 5GHz. Some materials absorb2.4GHz more than 5 GHz waves and viceversa. For example, 2.4 GHz waves areabsorbed very efficiently by water; in fact, amicrowave oven functions by exciting watermolecules with 2.4 GHz radio waves. Table 1shows the attenuation properties of commonbuilding materials.

As you can see from the table, nearly allbuilding materials attenuate RF signalssubstantially, which is why a wireless LANperforms best with line-of-site transmissions.A closed room or secluded area will not becovered adequately unless a transmitter isplaced in that area.

Site Surveys: Because of the different powerdissipation and absorption characteristics ofradio waves at 2.4 and 5 GHz, it is importantto measure the coverage of your network inactual operating conditions. For example, ifyou are designing a wireless LANdeployment in an office building, you shouldperform the site survey after the cubicles andoffice furniture are installed. If you aredesigning a wireless LAN deployment in awarehouse or industrial application, youshould perform the site survey during actualoperating conditions. This will help you todesign a network that provides the desiredcoverage when there are large reflectingobjects like vehicles or assembly equipmentthat would not be accounted for otherwise.

Antenna Cables: The coax cable used totransmit and receive RF signals is animportant component of your WLAN orwireless bridge network. Note that the longerthe coax cable between the access point orbridge and the antenna system, the greaterthe signal loss, and the weaker thetransmitting or receiving signal. Optimally,WLAN antenna cables should be less than 10feet long. If longer cable lengths arenecessary, use antenna cables labeled "lowloss" or "ultra-low loss," such as the 3Comultra low loss cables, to maximize theperformance of your antennas.

6 3COM® WIRELESS ANTENNAS GUIDE

Table 1: Attenuation Properties of Common Building Materials

BUILDING MATERIAL 5GHZ 2.4GHZATTENUATION (dBi) ATTENUATION (dBi)

Solid Wood Door 1.75" 10 6

Hollow Wood Door 1.75" 7 4

Interior Office Door w/Window 1.75"/0.5" 6 4

Steel Fire/Exit Door 1.75" 25 13

Steel Fire/Exit Door 2.5" 32 19

Steel Rollup Door 1.5" 19 11

Brick 3.5" 10 6

Concrete Wall 18" 30 18

Cubical Wall (Fabric) 2.25" 30 18

Exterior Concrete Wall 27" 45 53

Glass Divider 0.5" 8 12

Interior Hollow Wall 4" 3 5

Interior Hollow Wall 6" 4 9

Interior Solid Wall 5" 16 14

Marble 2" 10 6

Bullet-Proof Glass 1" 20 10

Exterior Double Pane Coated Glass 1" 20 13

Exterior Single Pane Window 0.5" 6 7

Interior Office Window 1" 6 3

Safety Glass-Wire 0.25" 2 3

Safety Glass-Wire 1.0" 18 13

(c) 3-Com

4

● opportunities at install-time ● mastering the product = educating the user● PUT USER IN CONTROL● range testing (typical range) = site survey ... set expectations● aim to keep ‘safe’ link margin?

Page 5: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Maintenance:keeping out of users' way• Wireless is just a means to an end• Don’t bother users with it!• Spot problems before they do

– heartbeats / lifesigns– network monitoring costs battery life

• Fix problems automatically• Tell the user what to do

– give them exact instructions– otherwise, give them enough information

5

● INSTALL MODE == MAINTENANCE MODE ... users are familiar with it● RELIABILITY is key to users’ perceptions: need link monitoring● heartbeats vs. energy vs. latency of problem detection and auto-healing● you will need a maintenance mode, if only to provide responsive feedback to users on network status .. without this they have a hard time understanding / fixing● simply increasing the lifesign frequency to 6-20x/minute can be very effective .. can’t contact sleeping ZEDs so may need to have users wait a short time

Page 6: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Maintenance:real-life links

!"#$%#&'()&%(*+,-).#&'(/,$#)0$,()&%(/10"2.(3#'!,,(4,.51-62(

7&(,)89(8)2,:(2.)86(;,&%1-2()-,("&$#6,$<(.1(+-1;#%,()&<.9#&'(=1-,(.9)&()(2#=+$,(>?(1-(4,.51-6(@)&)',-(#=+$,=,&.).#1&(.9).()$$152(%,;,$1+,-2(.1("2,()&%(,A+,-#=,&.(5#.9(.9,2,(B,)."-,2(1&(.9,(0,&89C.1+D(>9,(.)26(1B(%,B#&#&'(.9,(,A)8.(;)-#)&.(B1-()(+)-.#8"$)-()++$#8).#1&(5#$$(B)$$(1&(.9,(291"$%,-2(1B(.9,()++$#8).#1&(%,;,$1+,-D(>9,(.)26(1B(5-#.#&'(.9,(-,$,;)&.()++$#8).#1&2(=)<(B)$$(.9,-,()2(5,$$:()$.91"'9(.9,-,()-,(&15(E-%C+)-.<(=#%%$,5)-,(%,;,$1+,-2(591()-,(2.,++#&'(#&(.1(+-1;#%,(.9,2,(8)+)0#$#.#,2D(

>9,(=)#&(+1#&.(9,-,(#2(.9).(.9,()++$#8).#1&(%,;,$1+,-(9)2(891#8,2(.1(=)6,(01.9(5#.9(-,2+,8.(.1(2.)86(1+,-).#1&()&%(.9,(1+,-).#1&(1B(1.9,-(2<2.,=(81=+1&,&.2(.9).(-,B$,8.(.9,(8)+)0#$#.#,2(1B(.9,(2<2.,=()2()(591$,:(.9,(+)-.#8"$)-2(1B(.9,(%,+$1<=,&.:(.9,()++$#8).#1&(+-1B#$,:()&%(.9,(8)+)0#$#.#,2(1B(.9,(;)-#1"2("2,-2(1B(.9,(2<2.,=D(

F9).(B1$$152(#2(-1"'9$<(%#;#%,%(#&.1(.51(2,8.#1&2(81;,-#&'()++$#8).#1&()&%(&,.51-6(%,2#'&(81&2#%,-).#1&2()&%(1+,-).#1&)$(81&2#%,-).#1&2(-,2+,8.#;,$<D(

G,2#'&(81&2#%,-).#1&2(((7&(%,8#%#&'(915()&()++$#8).#1&(#2('1#&'(.1(=)6,("2,(1B(3#'!,,:(#.(#2(51-.9(81&2#%,-#&':(B#-2.(1B()$$:(59).(.9,(&,.51-6(#2(,A+,8.,%(.1($116($#6,D(7&(,=0,%%,%(&,.51-62:(%,;#8,($18).#1&2()-,(1B.,&(B#A,%(0<(.9,#-()++$#8).#1&(B"&8.#1&D(H#'9.#&'()&%(IJK?(%,;#8,2(#&()(91=,(1-(1BB#8,:(B1-(,A)=+$,:(=)<(0,(21=,59).(=10#$,(0".()-,(=12.(1B.,&(B#A,%(B1-(-,)21&2(.9).(9);,(&1.9#&'(.1(%1(5#.9(.9,#-()0#$#.<(.1(B1-=()(-,$#)0$,(&,.51-6D(G,2#'&,-2(291"$%(81&2#%,-(.9,(,A+,8.,%($)<1".(#&(.,-=2(1B(.9,(,A+,8.,%(%#2.)&8,2(0,.5,,&(-)%#12()&%(.9,(,A+,8.,%(%,&2#.<(1B(.9,(&,.51-6(+-1%"8,%D(7B(.9,(&,.51-6(#2(,A+,8.,%(.1(81&.)#&(=10#$,(%,;#8,2:(.9,2,(291"$%(0,(81&2#%,-,%(8)-,B"$$<()2(5,$$D(

/)&',()&%(/,$#)0#$#.<(

L1-()&<($)<1".(1B(%,;#8,2(5#.9()('#;,&(-)&',:(1&,(51"$%(&)."-)$$<(,A+,8.(21=,(%,;#8,2(.1(0,()0$,(.1(81=="&#8).,(=1-,(8$,)-$<()&%(-,$#)0$<(.9)&(1.9,-2D(G#''#&'(#&()(0#.(=1-,(%,,+$<:(915,;,-:(#.(=)6,2(2,&2,(.1()26(59).(.9,(,BB,8.(1B()&<(+)-.#8"$)-()--)&',=,&.(5#$$(9);,(1&(&,.51-6(+,-B1-=)&8,D(K(&"=0,-(1B(+)+,-2(#&8$"%#&'(MG,(?1".1:(K'")<1:(?9)=0,-2:(N(@1--#2:(OPPEQ(%18"=,&.(.9).:(B1-()&()--)&',=,&.(

59,-,(2,+)-).#1&2()-,(5,$$(%#2.-#0".,%(5#.9(-,2+,8.(.1(.9,(-).,%(/L(-)&',(1B(.9,(%,;#8,:(.9,(+,-B1-=)&8,(8)&(0,(%#)'-)==,%(-1"'9$<()2(#&(L#'"-,(OD(

(

L#'"-,(O(C(R89,=).#8(J#,5(1B(H#&6(S")$#.<(

7&(.9,(B#'"-,:($#&62(B1-()(9<+1.9,.#8)$(&,.51-6()-,()--)&',%(B-1=($,B.(.1(-#'9.(0<(#&8-,)2#&'(+)86,.(%,$#;,-<(-).,()8-122(.9,($#&6D(L1-()('#;,&(+)#-(1B(%,;#8,2:(2)<(MK:(!Q:(.9,(.1+($#&,(29152(.9,(-,$#)0#$#.<(B1-(.-)&2=#22#1&(B-1=(K(.1(!()&%(.9,(01..1=($#&,(29152(.9,(-,$#)0#$#.<(B1-(.-)&2=#22#1&(0)86(B-1=(!(.1(KD(T)89(+)#-(#2()22"=,%(.1()++,)-(1&$<(1&8,D((

F9).(G,?1".1()&%(1.9,-2(9);,(102,-;,%(#2(.9).()($)-',(&"=0,-(1B($#&62(#&()&<('#;,&(&,.51-6(."-&(1".(.1(0,()2<==,.-#8)$(#&(&)."-,()&%(.9).(.9,2,()2<==,.-#8)$($#&62(2915(1.9,-(0)%(0,9);#1-2(2"89()2(#&.,-=#..,&8<:(=1=,&.)-<(B)%#&'()&%(21(1&D(H116#&'().(.9,('-)+9:(#.(#2(,)2<(.1(2,,(.9).(,;,&($#&62(.9).()++,)-(U"#.,('11%(#&(1&,(%#-,8.#1&(=)<(0,("&-,$#)0$,(1-()$=12.("2,$,22(#&(.9,(1.9,-D(7.(9)2()$21(0,,&(102,-;,%(.9).:(.1(.9,(,A.,&.(.9).(.9,2,(,BB,8.2(81--,$).,(5#.9(%#2.)&8,:(.9,<(0,81=,(&1.#8,)0$,(5,$$(291-.(1B(.9,(-).,%(V#%,)$W(-)&',(1B(.9,(-)%#1D(

7&()%%#.#1&:(59).(5,(=)<(8)$$(.9,(-,$#)0$,(-)&',(1B()(%,;#8,(5#$$(%,+,&%(&1.(X"2.(1&(.9,(+,-B1-=)&8,(1B(.9,(-)%#1(0".()$21(1&(.9,(9)-%5)-,(%,2#'&Y#&8$"%#&'(+)86)'#&':()&.,&&)(%,2#'&()&%(Z?C01)-%($)<1".Y)2(5,$$()2(1&(.9,(=).,-#)$2(#&(.9,(2"--1"&%#&'(,&;#-1&=,&.D(

>9,($,221&(9,-,(#2(.1(.)6,(.9,(-).,%(-)&',(B1-()(+)-.#8"$)-(-)%#1(1&$<()2()(2.)-.#&'(+1#&.(B1-()&(,A+$1-).#1&(1B(59).(.9,(+,-B1-=)&8,(5#$$(0,(#&(.9,(,A+,8.,%(%,+$1<=,&.(,&;#-1&=,&.(1B(.9,(B#&)$:(+-1%"8.#1&(%,;#8,:()&%(.1(%,2#'&(.9,(591$,()++$#8).#1&()-1"&%(-,)$#2.#8(,A+,8.).#1&2(B1-(.9,(-,$#)0$,(-)&',D(@,29(&,.51-62(%,+,&%(1&(9);#&'()(="$.#+$#8#.<(1B("2)0$,($#&62(0,.5,,&(%,;#8,2()&%(#B(.9#2($#&6(%#;,-2#.<(#2(&1.();)#$)0$,:(#.(5#$$(0,(%#BB#8"$.(.1(%,$#;,-()(-10"2.(&,.51-6D(

G)#&.-,,(4,.51-62:(OPP[( ( ( O(

00.20.40.60.8

1

Del

iver

y R

ate

18

13 22

19 23

13

14

23

17

26 21

10 14

21

27

20 14

26

14

19 21

28 13

11

21

12

13

6

17

25

20

11

21

6 19

2614

6

14

12 25

28 22

27

13

12

14

20 11

26

22

21

22

12 27

17

19

13

19

17

21

13 21

17

20

1319

18

22

6

14

25

23

1712

26

13

28

6

26

23

11

13

1022

28

19

11 14

10 17

12 6

28

27

13

11

25

23

10

17

6

23

20 21

20

23

6 22

1710

26

14

28 20

26 23

28

17

10

17

28

23

26 22

1327

11 23

19

13

25

23

12

27

18 22

14

22

25 20

17

27

25 14

13

27

21

21

25 21

11

10

6 26

28 17

13

12

10 14

17

10

28

12

28

18

25

12

6

20

28

18

11

20

12

20

6

20

10 21

18

Figure 5: Delivery rates for each link pair in the indoor network (8-Feb-13:30-50-byte). The y values of the two ends of each line

indicate the delivery rate in each direction; the numeric labels indicate the sending node for that delivery rate. Links with zero

delivery rate in both directions are omitted. 91 links are shown.

00.20.40.60.8

1

Del

iver

y R

ate

16

7 32

7 30

32

31

32

29

32

31

8

16

8

30

716

32 30

31

29

7

16

31

16

29 29

31 31

7 32

8

Figure 7: Delivery rates on each link pair for the outdoor

rooftop network (6-Mar-18:30-50-byte), as in Figure 5. 16 links

are shown.

We conducted a set of experiments with the indoor testbed using

50-byte UDP packets (8-Feb-13:30-50-byte). Each node transmit-

ted 1024 packets per second for 300 seconds. Figure 5 shows the

results for each link pair, excluding link pairs which were not able

to communicate at all. About 30% of the link pairs shown are com-

pletely unusable, although they might deliver a few routing packets.

The best 40% of link pairs deliver about 90% or more of their pack-

ets; these are the links we would like to use in routes. The delivery

rates of the remaining links are spread out. Other experiments on

different days, at different times, and with different parameters con-

firm that in general the links in the network exhibit a wide range of

delivery rates.

Link pairs that are very good in one direction tend to be good in

both directions, and pairs that are very bad in one direction tend to

be bad in both directions. However, at least 30% of the link pairs

shown have asymmetric delivery rates, defined as a difference of

more than 20% between the rates in each direction.

Figure 7 summarizes an identical set of experiments carried out on

our rooftop network (6-Mar-18:30-50-byte). Like the indoor net-

work, the rooftop network has widely varying delivery rates, with

noticeable asymmetry. Experiments over several days exhibited

similar distributions of delivery rates. The wide variation in de-

livery rates for both networks suggests that routing protocols may

often choose links that are high enough quality to pass routing pro-

tocol packets, but which still have substantial loss rates.

3.2 Link Variation over Time

One way to determine link quality is to measure it by counting the

number of packets received over a period of time. However, the ac-

curacy of this approach is sensitive to length of time over which the

delivery rate is measured. For example, Figure 8 shows the second-

by-second delivery rates for two links (8-Feb-13:30-50-byte). The

0

0.2

0.4

0.6

0.8

1

50 100 150 200 250 300

Link from 18 to 19

0

0.2

0.4

0.6

0.8

1

50 100 150 200 250 300

Del

iver

y R

ate

Time (seconds)

Link from 21 to 20

Figure 8: Example per-second variation in link delivery rates

(8-Feb-13:30-50-byte). Each point is the delivery rate over one

second. The delivery rate of the link from 18 to 19 fluctuates

quickly, while the link from 21 to 20 is comparatively stable.

graphs show that while delivery rates are generally stable, they can

sometimes change very quickly. Averaging may work well on the

link from node 21 to 20, but it is likely to hide much of the detailed

behavior of the link from node 18 to 19.

Figure 9 summarizes variation in loss rate over time for all links.

For each link, we calculated the mean and standard deviation of

the 1- and 10-second loss rates over the whole experiment. The

graph shows the cumulative distribution of these standard devia-

tions, normalized by the respective means. We use loss rates rather

than delivery rates for this analysis to emphasize the changes in

the delivery rate on links with low loss, since very lossy links are

useless for data traffic regardless of their variation.

Results for 1- and 10-second windows show that quite a few links

vary greatly on these times scales. For example, half of the links

had standard deviations in their 1-second loss rates that exceeded

half of the mean 1-second loss rate. This suggests that wireless

routing protocols should use agile predictors of link loss rates.

Study of the Impact of WLAN Interference on IEEE 802.15.4 BANs 9

802.1

5.4

channel

16

21

11

26

802.1

5.4

channel

16

21

11

26

802.1

5.4

channel

19:05h 19:15h 19:25h19:00h 19:10h 19:20h 19:30h

16

21

11

26

100

50

0

0

20

40

60

3

2

1

TxPower !42 dBm

TxPower !25 dBm

faile

d tra

ns!

mis

sio

ns (

%)

faile

d tra

ns!

mis

sio

ns (

%)

TxPower !10 dBm

faile

d tra

ns!

mis

sio

ns (

%)

Fig. 5: Failed 802.15.4 transmissions while walking along an urban shopping street. Forevery 802.15.4 channel the transmissions are averaged over a window of 100 trans-missions (26 s), and packets are sent with three di!erent transmission power levels:!10 dBm (top), !25 dBm (middle) or !42 dBm (bottom), alternating every sweep.

urban streets using the same setup as described previously. A single measurementtypically lasted around 30 minutes. As a case study in this section we report onone such measurement in detail, in the next Sect. 5 we present an evaluation ofthe empirical traces from all measurements.

The measurement described in the rest of this section was made at a centralurban shopping street. Buildings were located on either side of the roughly 30 mwide street, which was moderately frequented by cars and other pedestrians ona weekday evening at 7 p.m. The test person took a 30 minute walk outdoorsalong the pavement passing by shops, co!ee bars and o"ces as well as otherpedestrians. The walk was one-way and close to straight-line at even walkingspeed (stopping only at red tra"c lights).

4.1 Transmission Failures

Fig. 5 shows failed 802.15.4 transmissions averaged over 100 transmissions perchannel (about 26 s) sorted by transmission power.

The losses for !10 dBm transmission power (top) are negligible, even at!25 dBm (middle) we never see more than 60 % loss within a window of 26 son any channel. At !42 dBm (bottom) transmissions failed more frequently andsome channels were temporarily completely blocked. The figure suggests thatlosses were not completely random. Instead they showed some correlation intime and frequency, sometimes lasting for a few tens of seconds up to multipleminutes and spanning over multiple consecutive 802.15.4 channels.

Fig. 6 shows a 2 minute excerpt of the bottom Fig. 5 at around 19:03 h. In thisfigure transmissions are averaged over a window of 10 transmissions (2.6 s) as inthe baseline measurement shown in Fig. 3. When comparing these two figureswe find that in Fig. 6 the pattern at around 19:03 h to 19:04 h on channels 13closely resembles the 802.11b “footprint” in Fig. 3, which suggests that theselosses might have been caused by 802.11 tra"c.

De Couto et al

(c) Daintree Networks

Rondinone et al

6

● these are MEASUREMENTS of link quality● asymmetry ... momentary fading & intermittency● 99.99% reliability = 2 lifesigns/month (2-min intervals, 15s avg outage)

Page 7: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Maintenance:measuring link quality

7

● really PREDICTING link quality● these plots: 802.15.4 .. free space .. 100 packets over 2s .. illustrate LQI vs RSSI .. digital vs analogue● LQI in theory is mostly 100% until link is very marginal ..<80% is not usable .. in practice many links are found in this regime● NOT derived from one another

Page 8: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Maintenance:RSSI vs. LQI vs. PER

LQI RSSI PERDiscriminates near-threshold links

Monitor link margin measure actual link reliability

platform-dependent cross-platform cross-platformStandard support in ZigBee (neighbour table)

support is stack dependent, requires some app-layer code

support mostly in application layer

Variable means slow (or costly) - need many packets to average, but best predictor of link performance

Stable means fast - one packet is sufficient for link estimation

Costly / slow - need many packets, need to detect missed packets imposes costly lifesigns

0-255 ~ -90 to +5 dBm P(fail) = 0-1

8

● we chose LQI when we started..● how to incorporate missed packets in to LQI averaging? - set link LQI to 0 is best for responsiveness● none of these measures account for end-to-end performance or availability of alternate routes● monitoring PER means choosing a sensible monitoring period: i.e. since last battery change, maintenance mode, add/subtract, device missing/reappeared

Page 9: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Maintenance:islanding

9

● probably the most pernicious problem● users WILL do this - they put things where they think they’ll be useful● often takes end devices with it: hard to explain/debug! ● ->send routers in to ‘warning flash mode’ when islanded● ->don’t let ZEDs join islands

Page 10: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Maintenance:interferers

802.11b 802.11n (40MHz)802.11n

TV sender 2x 802.11b, 3x 802.15.410

● typically very intermittent, affects latency rather than reliability● avoid automatically with appropriate channel selection strategy● ->tell users what channel they are on● users prone to blaming interference .. be wary of letting them set the channel .. it may cause more trouble than it saves!

Page 11: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Maintenance:single-path

! !11

● human body can absorb single path quite effectively● not uncommon in sparse networks● hard to predict .. also intermittent

Page 12: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Maintenance:what's wrong and how can I fix it?

12

Showing network status: how to do it?here show %, used to have signal bars, I prefer traffic lightshere we see maintenance mode (1-at-a-time identify, 6s poll)responsive feedback, same as install modehow much information is enough? plots of LQI?

Page 13: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Maintenance:network maps

13

● expose the mesh .. users tend to assume a star otherwise .. especially if your application has a hub or gateway of some kind .. recipe for confusion● can’t show islands .. possibly ‘last seen’?● map shows link strengths BUT hard/costly to keep up-to-date● typically need a map for outside-in OTA upgrades anyway● gives some idea of network density● www.graphviz.org

Page 14: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Conclusion:cover the essentials

Hide the complexity, but....be open about how it works

ZigBee is sophisticated but complex

Give users rapid feedback

Let users play

Hand over control to your usersOtherwise you’re still responsible - helping is better than apologising!

14

● heterogeneity of radio nodes, mesh networking & flexible security model ● designing for users: ability to use vs ease of use● ‘play’ == rapid feedback and confidence that things will not breakSetting expectations● too little info can be as bad as too much● when things go wrong you will get the blame, unless you have helped your customer take control

Page 15: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

Questions?

Amyas [email protected]

www.alertme.com

[email protected]

Enquires: +44 (0) 845 200 2871Reception: +44 (0) 1223 361 555

Alertme.com Ltd27-28 Bridge StreetCambridgeCB2 1UJ

15

Page 16: Making ZigBee Usable for Consumer Applications - Amyas Phillips EZDC09

References• D. S. J. De Couto, D. Aguayo, B. A. Chambers, and R. Morris; Performance of Multihop Wireless Networks: Shortest Path is Not Enough (2002); Proceedings of the First Workshop on Hot Topics in Networking (HotNets-I), Princeton, New Jersey, October 2002; http://pdos.csail.mit.edu/papers/grid:hotnets02/paper.pdf

•ZigBee and Wireless Radio Frequency Coexistence (2007), ZigBee Alliance; http://www.zigbee.org/LearnMore/WhitePapers/tabid/257/Default.aspx

• Building and Operating Robust and Reliable ZigBee Networks (2008), Daintree Networks whitepaper; http://www.daintree.net/resources/whitepapers.php

• K. Srinivasan and P. Levis; RSSI is Under Appreciated (2006); Proc. of EMNET 2006; http://www.eecs.harvard.edu/emnets/papers/levisEmnets06.pdf

• M. Rondinone, J. Ansari, J. Riihijärvi, and P. Mähönen; Designing a Reliable and Stable Link Quality Metric for Wireless Sensor Networks (2008); Proc. of Workshop on Real-World Wireless Sensor Networks (REALWSN), Glasgow, UK, April, 2008

16