Gateway Design for Data Gathering Sensor Networks

Gateway Design for Data Gathering Sensor Networks

That’sMe

RazvanMusaloiu-E.

AndreasTerzis

Presented by Raluca Musaloiu-E.Johns Hopkins University

Easier to deploy a WSN than years ago.

Tmote Sky

MICAz

Contiki

MANTIS OS

SOS

RETOS

TinyOS

Life Under Your Feet

WSNs for studying the effects of abiotic factors

on soil animals.

http://lifeunderyourfeet.org

http://www.xbow.com

http://www.xbow.com

Koala

System for reliably extracting bulk data from

duty-cycled nodes.

Current solutions for WSN gateways are

not energy efficientand bulky.

Architecture

WSN

WSN

Internet

Back-EndServer

Commands

RequestsData

Stargate

http://www.xbow.com

CPU 400 MHz Intel PXA255

Memory 64 MB SDRAM

32 MB Flash

CF and PCMCIA connectors

51-pin expansion connector

Low power consumption < 500 mA

http://www.xbow.com

http://www.xbow.com

PowerNutCPU Low-power PIC, 32768 Hz

Supply voltage 7-30 V

Power consumption(downstream device shutoff)

180 uA (worst case)

58-100 uA (typical)

http://www.jkmicro.com

http://www.xbow.com

http://www.xbow.com

Boot uplink connectionEstablish the Download

commandsDownload data from the motes

Upload previous data

Sleep

Fig. 2. The gateway’s normal operation cycle.

this state and the PowerNut itself consumes very little energy,this solution is more efficient than putting the gateway todeep-sleep mode. On the other hand, the gateway must gothrough its boot process every time power is restored. Thisboot sequence, including loading the operating system, cantake tens of seconds. Section IV explores the trade-off betweenpowering off the gateway and using its deep-sleep mode.

B. Software Design

Figure 2 depicts the gateway’s cycle of operations. Afterthe power controller restores power and the boot sequencecompletes, the gateway attempts to establish an uplink tothe back-end server. Communication between the gatewayand the back-end server follows a query-response protocol,in which the Stargate polls the back-end server to retrievenew commands and subsequently reports the results of thecommands’ execution. We selected this interaction paradigmbecause it affords the gateway to turn itself off in betweenqueries and allows it to use different IP addresses acrossqueries. This is important because long-haul radios mightreceive different IP addresses over time, for example whenusing DHCP. We choose HTTP as the underlying communica-tion protocol, because it follows the query-response paradigmdescribed above and supports authentication and encryption.

The back-end server transmits two main types of commands:(1) uploading the previous round of measurements downloadedfrom the WSN and (2) downloading the next round of mea-surements from the WSN. Because both operations requiresignificant time, the gateway performs them in parallel tominimize the time it is active. Once the upload operation com-pletes, the gateway disables the uplink interface to minimizeenergy consumption. If the gateway fails to establish a linkto the back-end server, it only performs the local downloadfrom the WSN. Another special situation occurs when thegateway fails to turn itself off, due to a malfunction of thepower controller. In this case, the gateway informs the back-end server of this failure so maintenance can be scheduled.

In addition to the data download operations, the gatewaysupports the following commands:

1) TIME <curtime>The system clock of many gateway platforms, includingthe Stargate, is reset to 00:00:00 01/01/1970 (also knownas the epoch in Unix nomenclature) when the unitis powered down. This command allows the back-endserver to update the gateway’s clock to curtime.

2) SLEEP <seconds>

This command specifies the number of seconds that thegateway should go to sleep at the end of the currentactivity period. The gateway uses this value to set thetime period for deep-sleep or to configure the amountof time the PowerNut power controller will disconnectthe power from the gateway itself.

3) REPORT <count>This command specifies the number of operation cyclesafter which the gateway must connect to the back-endserver to refresh its command file and to return the datait has collected.

4) SEND_LOGThis command is used for debugging and requests thegateway to upload its log file. The log file contains a his-tory of the gateway’s actions, including the connectionsto the back-end server (including failed attempts).

5) UPDATE <file_location> wsn|gwThis command replaces the current binary run-ning on the gateway, or the WSN motes, wherefile_location specifies the new file as an FTP orHTTP URL.

Figure 3 presents a sample gateway log from a simplesession with the back-end server. The first line of the logshows the HTTP GET request for the command file, followedby the server’s response. This is followed by the HTTP POSTquery for uploading a 10 KB file with measurements collectedfrom the network to the back-end server. The session endswith the gateway transitioning to the deep-sleep mode for18,000 seconds, as instructed by the back-end server throughthe command file.

C. WSN Interface

There are two types of interaction between the gatewayand the WSN: downloading data from the network’s motesand reprogramming the motes. We use Koala [25] for thefirst operation, while the second is accomplished by invokingprotocols such as Deluge [6] and Typhoon [21]. In bothcases the communication between the gateway and the motedirectly connected to it follows the standard TinyOS serialcommunication protocol [12].

D. Long Haul Connectivity

We consider two alternatives for providing long haul con-nectivity: Wi-Fi and cellular data radios. The advantage ofusing a Wi-Fi radio is that Wi-Fi networks are available inmany urban areas. On the other hand, cellular data networks,while offering slower data rates at significantly higher cost,

Normal operation cycle

Commands

TIME <curent time>

SLEEP <seconds>

REPORT <count>

SEND_LOG

UPDATE <file_location> wsn|gw

WSN interface

Koala Deluge Typhoon

network programmingdownload data

Long haul connectivity

Evaluation

1

2

3

Deep-sleep versus Power-off mode

Energy efficiency of long haul radios

Lifetime estimation

1

Decision is based on inactivity time.

Deep-sleep versus Power-off mode

0 mA

125 mA

250 mA

375 mA

500 mA

No cards Wi-Fi 3G

247 mA306 mA

123 mA

102 mA

83 mA

42 mA23 mA6 mA

Deep-sleepNetwork downNetwork up

No cards

144 mA

63 mA

No daughter-board With daughter-board

0 mA

75 mA

150 mA

225 mA

300 mA

No cards Wi-Fi 3G DB, no cards

268 mA280 mA

203 mA176 mA

Average current drawn during the booting sequence

Power-off mode is preferred if time > 3.9 min for 3G(5.2 min for Wi-Fi, 16.5 min with no cards).

0

20

40

60

80

100

0 500 1000 1500 2000

Avera

ge C

urr

ent (m

A)

Inactivity Time (s)

A

B C

3G - deep-sleepWi-Fi - deep-sleep

no cards - deep-sleep3G - power-off

Wi-Fi - power-offno cards - power-off

2

Energy efficiency of long haul radios

Measure the time to transfer a file.

0

2

4

6

8

10

12

14

16

18

1M750KB500KB250KB100KB

En

erg

y C

on

su

mp

tio

n (

mA

h)

Wi-Fi - deep-sleep3G - deep-sleepWi-Fi - power-off

3G - power-off

3G

Wi-Fi

1.2 mAh to transfer 1 MB file in deep-sleep with Wi-Fi(16 mAh with 3G).

0 100 200 300 400 500 600 700

0 20 40 60 80 100 120 140 160 180

Cur

rent

(m

A)

Time (s)

A

B CD

E

Fig. 7. Current drawn during the transfer of a 1 MB file using the 3G radioin the power-off configuration.

0 100 200 300 400 500 600 700

0 20 40 60 80 100 120 140 160 180

Cur

rent

(m

A)

Time (s)

A

B C D E

Fig. 8. Current drawn during the transfer of a 1 MB file using the Wi-Firadio in the power-off configuration.

loading, PPP dial-up connection is set in section C, followedin section D by the actual transfer, and a short section E inwhich the connection is terminated. Figure 8 presents the samestages when the Wi-Fi card is used.

C. Lifetime Estimation

We can now estimate the lifetime of a battery-operatedgateway for each of the four configurations (deep-sleep/power-off mode with Wi-Fi/3G radio).

To do so, we consider a WSN of N = 25 motes, each withstorage capacity of M bytes. Each mote generates measure-ments at a rate of B bytes/min. We assume that there are nolatency requirements in delivering the measurements to theback-end server so the only constraint is to offload the databefore the motes overflow their local storage. Therefore, thegateway must retrieve the motes’ measurements after each ofthe motes has collected ! · M , (! ! 1) bytes of data. Forexample, when ! = 0.25, the gateway must collect 256 KBof data from each mote (6.25 MB in total), approximatelyevery 10 days when the data generation rate B = 18 bytes/minand approximately every day if B =180 bytes/min. Table IVprovides a list of all the model’s parameters.

To estimate the gateway’s expected lifetime, we must com-pute its total energy consumption over time. This quantity isthe sum of three factors: (1) the energy consumption while thegateway is sleeping (either in deep-sleep or power-off mode),(2) the consumption when the gateway is actively collectingmote data, and (3) the consumption while the gateway uploadsdata to the back-end server. We estimate each of these threefactors next.

a) Energy consumption in sleep mode: In deep-sleep, thegateway draws constant current of 23 mA with the Wi-Fi cardand almost double the current (42 mA) with the 3G card. Onthe other hand, when the gateway is turned off the only currentdrawn is by the power controller ("180 µA).

b) Energy consumed to retrieve WSN data: Figure 9indicates the amount of time required to reliably download themeasurements from all of the network’s motes, as a functionof the per-mote data that the gateway downloads [25]. Wederive the energy consumption by multiplying the downloadtime by the current drawn by the gateway when the long-haul interfaced is down (102 mA for Wi-Fi and 124 mA for3G). Note that connectivity to the WSN is provided by amote that is directly connected to the gateway and is poweredindependently.

c) Energy consumed to upload data: Finally, as Figure 6indicates, this amount is a linear function of the total amount of

0

5

10

15

20

25

30

35

40

45

50

55

0 50 100 150 200 250 300 350 400 450 500 550

Rad

io-o

n tim

e [m

inut

es]

Data-size [kilobytes]

Fig. 9. Total time the gateway is active downloading data as a function ofthe per-mote download size for a network with 25 nodes. These downloadtimes were reported in [25].

data uploaded to the back-end server. Note that in the power-off configuration this energy includes the cost of booting thegateway (cf. Sec.IV-B).

We combine the three factors to derive the results shown inFigures 10 and 11. These figures show the cumulative energyconsumption as a function of time in deep-sleep and power-offmodes for both long-haul radios, when the gateway downloadsdata every one and every ten days respectively. Based onthese consumption rates, we estimate gateway lifetimes in twoscenarios. First when the gateway is powered by standard AA-cell lithium batteries with a capacity of 3,000 mAh and secondwhen the gateway is powered by special Lithium ThionylChloride batteries with 19,000 mAh of capacity [30]. Table Vpresents the expected gateway lifetimes in both scenarios.

It is evident that considerable energy is consumed in deep-sleep mode, preventing the gateway from completing even asingle cycle of operation with the 3,000 mAh battery, whendata is collected every ten days. On the other hand, whenthe gateway operates in power-off mode and motes generate18 bytes/min, it can last for 293 days with the Wi-Fi radioand 171 days with the 3G radio using a 3,000 mAh battery.Furthermore, the 19,000 mAh battery extends the gateway’slifetime to 5 years and 2.96 years, respectively. Even at thehigher data generation rate of 180 bytes/min, the gatewaycan operate uninterrupted for 137-300 days when the largerbattery is used. These results are very encouraging becausethey indicate that powering data gathering gateways through

0 100 200 300 400 500 600 700

0 20 40 60 80 100 120 140 160 180

Cur

rent

(m

A)

Time (s)

A

B CD

E


0 100 200 300 400 500 600 700

0 20 40 60 80 100 120 140 160 180

Cur

rent

(m

A)

Time (s)

A

B C D E










0

5

10

15

20

25

30

35

40

45

50

55

0 50 100 150 200 250 300 350 400 450 500 550

Rad

io-o

n tim

e [m

inut

es]






3G

Wi-Fi

Energy consumption to transfer 1 MB file in power-off mode.

3

Estimate the life of a battery-operated gateway.

Lifetime estimation

N number of WSN nodes 25

alpha storage threshold 0.25

M mote storage capacity 1 MB

B1 data generation rate 18 bytes/min

B2 data generation rate 180 bytes/min

1.Energy consumed

in sleep-mode.

Deep-sleep 23 mA Wi-Fi

42 mA 3G

Power-off 180 uA

2.Energy consumed

to retrieve WSN data.

0 100 200 300 400 500 600 700

0 20 40 60 80 100 120 140 160 180C

urre

nt (

mA

)Time (s)

A

B CD

E


0 100 200 300 400 500 600 700

0 20 40 60 80 100 120 140 160 180

Cur

rent

(m

A)

Time (s)

A

B C D E










0

5

10

15

20

25

30

35

40

45

50

55

0 50 100 150 200 250 300 350 400 450 500 550

Rad

io-o

n tim

e [m

inut

es]






102 mA Wi-Fi

124 mA 3G

Koala - Ultra-Low Power Data Retrieval in Wireless Sensor NetworksRazvan Musaloiu-E, Chieh-Jan Mike Liang, Andreas Terzis, IPSN ‘08

(interface down)

http://www.xbow.com

http://www.xbow.com

3.Energy consumed

to upload data.

0

2

4

6

8

10

12

14

16

18

1M750KB500KB250KB100KB

Energ

y C

onsum

ption (

mA

h)

Wi-Fi - deep-sleep3G - deep-sleepWi-Fi - power-off

3G - power-off

Use a linear function of the amount of data uploaded.

Estim

ation

0

5000

10000

15000

20000

0 50 100 150 200 250 300

En

erg

y C

on

su

mp

tio

n (

mA

h)

Days

3G - deep-sleepWi-Fi - deep-sleep

3G - power-offWi-Fi - power-off

19,000 mAh

Deep-sleep

Power-off

0 days

75 days

150 days

225 days

300 days

Deep-sleep Power-off

300 days

31 days

137 days

16 days

3GWi-Fi 180 bytes/min

0 days

500 days

1,000 days

1,500 days

2,000 days

Deep-sleep Power-off

1,860 days

34 days

1,071 days

18 days

18 bytes/min

Alternatives

Hardware

RCM4500W RabbitCoreRabbit Semiconductors

Mod2570Nerburner

Wildfire 5282Intec Automation

Verdex XM4Gumstix

Imote2CrossBow

Flashlite 186JK microsystems

Software

VxWorks

Software framework for WSN gateways.

Battery-operated mote gateway.

Investigate software and hardware alternatives.

Acknowledgments

LUYF Crew, Robert Szewczyk National Science Foundation, JHU/APL, Microsoft Research, Moore Foundation, Seaver Institute

Mike

Thanks

Questions

Technology

Gateway Design for Data Gathering Sensor Networks