A Wireless Mesh Communication Protocolfor Smart-metering

Daniel GeelenEindhoven University of Technology

Netherlands

Gert van Kempen &Frans van Hoogstraten

SmartDutch

Netherlands

prof.dr. Antonio LiottaEindhoven University of Technology

Netherlands

Abstract—Worldwide there has been increasinginterest over the past few years for so-called “SmartMeters”, in academia, governments and in industry.Such smart-metering systems need a way to commu-nicate the collected data reliably and cost efficientlyto the back-office for analysis. Several competingtechnologies exist and are in use world-wide. Mesh-networks have been the winning technology in theUSA and Australia for the past two years, and aregaining interest in Europe at the moment due to itsreduced costs and increased reliability. In this paperwe present and evaluate a real-life implementationof a new routing protocol for use in smart-meteringmesh-network grids. The routing protocol we presentis designed with both technological constraints andlegislative requirements as posed by the applicationarea in mind. Our evaluation of the protocol is basedon real-world experience and data collected fromreal-world devices, in combination with simulationstudies of the protocol. Our evaluation shows that theprotocol is a robust, reliable solution for communicat-ing collected data in difficult scenarios, showing greatresilience against both bit-errors and node-failures.

I. INTRODUCTION

In this paper we present (section III, IV) and

evaluate (section V, VI) a new wireless mesh

protocol for use in residential smart-metering appli-

cations. This protocol has been under development

by a Dutch company and has already been success-

fully deployed in case-study installations commis-

sioned by three out of the four largest Dutch grid

operators. In these case-study installations the pro-

tocol appeared to work very well, reaching close to

100% delivery rates. Our simulations confirm these

results and show that the protocol can be expected

to maintain these high delivery rates up-to bit-error

rates as high as 10−4. We use data collected from

these case-studies to analyse the performance of

the protocol, as well as to aid in verification and

validation of our simulations. Because the protocol

is targeted for deployment in households across

the European Union it is subject to European law

(section II). This combined with the constraints

dictated by the available hardware platform make it

challenging to design an efficient, reliable protocol.

We present the protocol in section III.

Smart-metering refers to the next-generation of

(mostly) electricity meters which need not be re-

stricted to measuring only electricity usage; these

can be combined with gas, water, and heat-meters.

Smart-meters can be differentiated from other mod-

ern metering techniques such as automated meter

reading (AMR) and automatic meter management

(AMM) by the amount of control smart-metering

gives over the monitored devices [1]. Smart-meters

are able to manage connected devices with short

feedback and response times, and offer several

advantages over the traditional metering-devices

that until now have been in use for both utility com-

panies and consumers alike [2]. Because it is pos-

sible for suppliers to interact quickly with smart-

meters, it is possible to offer greater tariff variety

and flexibility in pricing. Smart-meters can also

be remotely administered, making it is easier for

consumers to change suppliers. This in turn leads

to increased competition among suppliers. Con-

sumers also gain more accurate meter reading (and

hence billing). However these same features benefit

suppliers as well. In the same way consumers

find it easier to change suppliers, on the supplier

side the process also becomes more streamlined

and less involved. Metering-device (de)activation

and maintenance can be handled remotely, cutting

down on costs.

Radio Frequency (RF) communications present a

reliable, cost-effective technology for use in smart-

metering networks. Other possible approaches such

as power-line communications (PLC), GPRS and

GSM based access-points or the use of Telephone

(land) lines and (coaxial) cabling suffer limitations

on reliability, bandwidth and costs [1], [3], [4].

A mesh-type network is the natural topology for

a RF-communications based smart-metering net-

work. Solutions exist based on standards such as

IEEE 802.15.4 [5] or ZigBee [6], as well as many

Workshop on Computing, Networking and Communications

978-1-4673-0009-4/12/$26.00 ©2012 IEEE 343

proprietary solutions. Routing-protocols used in

smart-metering solutions range from very simple

ALOHA-like approaches like [7], through the clas-

sical mesh routing protocols [8] as used in ZigBee

or IP-based networks such as 6LoWPAN [9], to

intricately complex solutions such as [10], which

details a project similar to the work presented in

this paper. The system described in [9] has also

been successfully field tested, and uses a TDMA

protocol with polling initiated by the central node

to query metering nodes. It relies on highly precise

time synchronisation between nodes, to be imple-

mented in a customised physical layer, to achieve

collaborative transmission [11], [12]. Although the

protocol described in this paper also requires time

synchronisation, it can use timers with regular

accuracy. Further it is designed to operate within

more strict constraints with respect to bandwidth

use, transmission times and hardware restrictions,

using readily available components.

II. CONSTRAINTS AND REQUIREMENTS

In terms of regulatory constraints the protocol

must take the intended deployment area into con-

sideration. In Europe there are efforts underway to

standardise smart-metering interfaces on the com-

munity level (Mandate CEN/CENELEC M/441), as

well as on the national level (such as the Dutch

NTA-8130 directive or the DSMR (Dutch Smart

Meter Requirements) document [13]) The general

objective of these efforts is to develop standards to

enable interoperability of utility meters. Not only

should the protocol adhere to these interoperability

guidelines, but because the metering-platform and

its proposed protocol will employ wireless mesh-

networking technology restrictions on the use of

radio frequencies have to be taken into consider-

ation also. On the technological level limitations

are imposed by what is possible on a given hard-

ware platform. For the case-studies the hardware

platform used was a ‘Nordic RF 905’. This RF

transmitter chip can transmit in one of 433MHz,

868MHz or 915MHz bands. Due to regulations

and concerns of the development team about the

reliability of the 433MHz band the 868MHz band

was used. On the legislative level1 restrictions may

be placed on the use of certain frequency bands

in terms of Effective Radiating Power (ERP), the

amount of bandwidth used, and the amount of

time a device is allowed to actively transmit (the

active duty cycle). Concretely this means that for

1In the European Union there are regulations which affectall union members. The ECO Frequency Information Systemdatabase (http://www.efis.dk/) provides a reference.

the chosen 868MHz band that the protocol has

to ensure that none of the participating metering-

devices exceeds a 1% duty cycle, at a maximum

ERP of 25mW. The protocol should enable two-

way communication with the utility’s back-office in

order to facilitate the reporting of energy, gas, water

and reverse-energy readings from the different me-

ters to the utility’s back-office, as well as sending

various notifications to the meters. The protocol

should be self-configuring as much as possible,

and should not require expert knowledge to setup.

Minimal preparations for each device (for example

setting an identifier for each device) should be

performed by the fabricator.

III. PROTOCOL DESCRIPTION

In the protocol we distinguish two types of

nodes, metering nodes and concentrator nodes.

Metering nodes are nodes which are attached to

a gas, water, heat, or electrical meter. These nodes

take measurements and can be considered to be

the network’s source-nodes. Concentrator nodes are

nodes which are connected to an Internet connec-

tion, for example through a GPRS up-link. Concen-

trator nodes collect the measurements for transmis-

sion to the back-office, and can be considered as

the sink-nodes in the network. Nodes are organised

in this manner since typically each metering node

only needs to report a small amount of information

to the back-office. By having a single concentrator

node there is only one shared Internet connection

required for a large set of nodes. In this way it

is possible to cut costs compared to the traditional

approach where each node has its own GPRS link.

The protocol tries to keep as much intelligence

in the source-nodes as possible. This means that

there is no polling of the nodes done by the concen-

trator, in contrast to for example [10]. Instead the

metering-nodes themselves initiate communication

on certain pre-set times, and communication takes

only a small amount of time. That is to say each

node has its own communication slot. When nodes

are installed no special attention is paid to any

relation between their node-id and their physical

positioning. This means that even in the event that

two nodes lose time synchronisation, it is unlikely

that their communications will interfere, since they

are likely to be in different areas of the network.

The protocol uses a proprietary packet format

which is optimised for use in meshed communi-

cations among a limited number of nodes, each

of which requires only a small amount of data

to be delivered. Each packet is exactly 32 bytes

long, regardless of whether or not those bytes are

344

actually fully utilised2. The protocol imposes a

15 byte overhead, leaving 17 bytes free for data

communications. Besides source and destination

IDs the header offers, among others, distinction

of packet-type, space for a list of intermediate-

nodes (the packet’s route), and a set of boolean-

flags indicating which of these intermediate nodes

have already forwarded the packet. In comparison,

a raw 802.15.4 header is at least 9 bytes3, but

at that size does not offer distinction of packet

type, hop limitation, or routing information. When

6LoWPAN is used this increases the size of the

header to 16 bytes [9]. Although offering routing

capabilities, the complexity of 6LoWPAN is much

greater, and putting more strain on both imple-

menters and hardware.

Nodes do not keep a routing table in the tra-

ditional sense, but they do cache previously es-

tablished communication-routes. The protocol op-

erates by first inspecting a node’s route-cache to

determine if the route knows a route to the desti-

nation node. If a route is found in the cache the

node will attempt to communicate via this route,

otherwise the node will attempt to communicate

directly. If this fails the node initiates a search-

phase in which it attempts to locate the destination

node at increasing hop distances. Upon receiving

an acknowledgement to its search the node caches

the discovered route and uses this for future com-

munications.

The protocol defines just a few packet-types;

two types of communication packet and one search

packet. Each of packet-type has a corresponding

acknowledgement packet. Figure 1 shows how each

packet type is handled by the nodes. The first

type of communication packet is used when there

is no need to use meshing for communication.

This is called direct communication. In the di-

rect communication mode a node will attempt to

communicate with its intended destination simply

by sending a direct communication packet with

the proper destination ID set, and waiting up-to

250ms for an acknowledgement. When a node

cannot communicate directly with its target node

(e.g. it is out-of-range, or the sending node fails

to receive a timely acknowledgement), meshed

communication is used. The route which is used for

the meshed communication is discovered through a

controlled flooding search. The search is initiated

2This is due to a limitation of the RF-receiver, which requiresthat packet lengths are known before reception in order toperform on-chip CRC verification.

3http://lia.deis.unibo.it/research/WANDA/architecture/amipv6.html#ipv6

by broadcasting a query message containing the

ID of the target node, as well as a limit on the

number of retransmissions onto the network. Any

node which receives the broadcast (and is not the

destination node) verifies that

• it did not initiate the search itself,

• it has not forwarded this search before (this

can be determined by inspecting the packet’s

route-list)

• propagating the search does not cause the

search to exceed the specified hop-limit,

• it is not already in the process of forwarding

another packet,

If all conditions hold the node records its ID in

the first free position in the packet’s route-list, and

selects a random delay between 0 and 56ms (in

8ms increments) and waits this amount of time

before re-broadcasting the search. By including a

small random delay between forwarded messages

the protocol avoids excessive collisions among

nodes attempting to forward search packets. When

the search packet is received by the destination

node, it waits a little over 63msבretransmission-

limit’ before sending an acknowledgement packet.

Because the retransmission-limit for each packet

is set at most 5, this amount of time is sufficient

to ensure that all other nodes have finished their

retransmissions of the search-packet.

Sending the acknowledgement to the search

back to the initiating node happens using meshed-

communication in the same way as the normal

mesh-packet type is meshed over the network.

Upon receiving a packet a node checks whether

it should forward this packet or not. A packet is

eligible for forwarding if it has the correct type

(e.g. an acknowledgement to a search or a mesh-

type packet) and has not yet been forwarded by

this node. Additionally only one packet may be

forwarded at a time. The packet is then prepared for

forwarding by flipping the flag-bit corresponding to

the node’s ID in the packet’s route. The packet is

then retransmitted after a short, random delay (this

delay is calculated in the same way as the delay

used during the search-phase). In this way meshing

a packet in this protocol is a very simple operation

requiring only a few simple checks and a single

bit-flip before the packet is ready for forwarding.

The protocol thus offers a highly efficient mech-

anism for forwarding packets, but does not specif-

ically keep track of the durations of transmissions.

It relies on keeping messages as short as possible

and traffic as low as possible to avoid exceeding the

1% duty cycle limit. Although this approach the-

345

receivepacket

destinationreached?

is DIR?

is DIR?

is SCH?

is SCH?

is MESH?

is MESH?

processpacket

wait

processpacket

wait

discardpacket

forwardpacket

wait

processpacket

processpacket

wait

sendacknowl-edgement

processpacket

yes

no

yes

no

yes

no

yes

no

yes

no

yes

no

yes

no

Figure 1: Decision process upon receiving a packet.

oretically allows for individual devices to violate

the stated requirements, we will show in section V

that even under heavy load the protocol operates

well within the 1% duty cycle limit.

IV. SIMULATION IMPLEMENTATION

For the purpose of evaluating the performance of

the protocol we have created an implementation of

the protocol in the OMNeT++4 network-simulator.

This implementation is based on the existing Cimplementation which runs on the real nodes in

the case study.

For our implementation we make use of the

MiXiM5 framework, which provides radio wave

propagation models, interference estimation, MAC

protocols and more. Instead of only using MiXiMlike a traditional library, providing ready-made

functionality, we have also used several of MiXiM’s

‘simple’ models as a base for the implementation

of our own models. For example we have ex-

tended MiXiM’s SimplePathlossModel with our

own obstacle model. Although an obstacle model

4http://omnetpp.org/5http://mixim.sourceforge.net/

is advertised in [14], it is at present not yet avail-

able in MiXiM. In our obstacle model arbitrarily

shaped and rotated obstacles can be placed in the

simulation. The signal’s attenuation is based both

on the signal passing through the walls (exterior)

of the obstacle, and on the distance the signal

travels through the obstacle. Our obstacle model

is similar in capabilities to the obstacle model

currently being developed6 for MiXiM but differs on

the implementation level, offering more flexibility

in defining the shape of obstacles.

Using a packet-sniffer operational data was ex-

tracted from the case-study installation, and used to

verify the accuracy of the simulation in two ways.

Firstly we created a tool to visualise both the output

of the simulation, as well as the data from the

case-study. Figure 2 is generated using data of a

simulation run, and shows various routes as used

by nodes in the network. Metering nodes are shown

as circles, the trapezium represents a concentrator

node. The thickness of the arrows indicates the

amount of traffic between nodes. As can be seen the

network is more or less split into a set of commu-

nicating nodes above and below the concentrator

node. This output looks very similar to the same

visualisation generated using data from the case-

study installation. The cause of this is a strip of

trees and shrubs present in between these nodes,

blocking the wireless signal. The main reason for

developing our obstacle model is to simulate the

signal attenuation caused by this foliage.

Secondly we have created a similarity index

for comparing the routes used by node in the

real-world versus those generated by the simula-

tion. We have based our approach on Levenshtein-

distance, but have modified it such that it takes

into consideration that routes are generally short,

irregular and use nearby nodes. This modification

was necessary because using an approach based

purely on string edit distance neglects the fact

that nodes are more likely to transmit packets to

nodes which are geographically closer. A detailed

explanation of the algorithm is omitted here due

to space limitations, but we give pseudo-code of

the algorithm used to compare two routes (lists of

nodes) A, B in listing 1. Here function δ(ν1,ν2)gives the distance between two nodes ν1 and ν2.

Using our similarity index we are able to show

that the simulated nodes are discovering and using

routes which are relatively similar (with respect to

the random nature of the protocol) to those used

6http://www7.informatik.uni-erlangen.de/∼sommer/omnet/obstacles/

346

by the real-life nodes.

|[ var A,B : P → ν ; δ ∈ ν×ν→ R ;

i, j,a,b ∈ N ; s,score, la, lb ∈ R

| score := 0

la, lb = length(A), length(B)

if la > 3 ∧ lb > 3 →i := 0

do i < 7 →s := ∞j := 0

do j < 7 →a := �i · (la÷7)+(1÷ (2 · la))�b := �i · (lb÷7)+(1÷ (2 · lb))�if b > 0 ∧ b < lb →

s := s ↓ δ(A[a],B[b−1])2 ↓δ(A[a],B[b]) ↓δ(A[a],B[b+1])2

fij := j+1

odscore := score + si := i+1

odfireturn score

]|Listing 1: Algorithm to calculate a similarity index

for two paths A, B.

V. EXPERIMENTAL RESULTS

Through our simulation we are able to collect

many statistics for each experiment, ranging from

the per-node active duty cycle, through the number

of successfully delivered packets, to the distances

packets travel through the network. We first present

some of the results for an experiment where we

have investigated the performance of the protocol

under a variety of bit-error rates. In our simulations

we assume that the hardware is reliable and any

bit-errors are due to effects in the transmission

medium (e.g. interference, packet collisions, etc.).

Recall that the hardware performs a CRC-check

on all received packets and that all packets are of

equal length. Therefor this also tests the protocol’s

ability to cope with packet-losses, because a spe-

cific bit-error rate directly equates to an expected

packet-loss rate. We also take a brief look at

the reliability of the protocol when faced with a

reduced operating capacity in terms of the number

of available nodes. In this experiment we varied

the number of nodes that remain in operation, both

themselves attempting to use the mesh-network for

communication as well as operating as intermediate

nodes in the network.

Figure 3 shows that the protocol’s ability to

deliver measurements to the concentrator node

is largely unaffected by bit-error rate. Only at

high bit-error rates the packet loss rate starts to

negatively affect the protocols ability to reliably

deliver packets. However even at a bit-error rate of

10−4 the protocol still delivers more than 99.5%

of measurements to the concentrator. Here it can

also be seen that even though a node may itself

believe to have failed to deliver the measurement

due to not receiving an acknowledgement, even

at very high bit-error rates of 5.5 ·10−4 (expected

packet loss rate > 15.8%), still more than 90% of

all measurements are delivered at the concentrator.

Figure 4 shows three measures for the length

of the routes. Firstly it shows the average hop-to-

hop transmission distance and the average distance

covered by a route. These are measured in meters

(left axis). Secondly it shows the average number

of hops a route uses (right axis). Similarly to

Figure 3, Figure 4 shows that routes are fairly

unaffected by changes in the bit-error rate. Again

only at very high bit-error rates a change in the

length of routes can be observed.

Figure 5 shows the average duty cycles for both

the concentrator node and for the metering nodes.

The concentrator node has to handle relatively large

amounts of traffic, because every other node will

be communicating with it to report measurements.

The figure shows that the protocol operates well

under the imposed 1% duty cycle imposed by

regulations, even at high bit-error rates where many

re-transmissions may be needed in order to de-

liver the measurement to the concentrator node. It

can be seen that at the breaking point (compare

Figure 3) the upward trend for the concentrator

node’s duty cycle is broken. This is because at

this point the channel state is so bad that commu-

nication becomes effectively impossible for nodes

which require more than a few hops to reach the

concentrator node, thus alleviating stress on the

concentrator node.

The second experiment, where we varied the

number of nodes that remain in operation to simu-

late nodes failing over time, shows that the protocol

is also able to handle large losses in operating ca-

pacity well. For this experiment we have assumed

a bit-error rate of 3.3 · 10−05, the bit-error rate

at which, as the previous experiment showed, the

protocol starts to become affected by packet losses.

Figure 6 shows that at 50% capacity, i.e. only half

347

of the nodes remain available for meshing, we are

still able to deliver over 95% of the measurements.

Since by the previous experiment we know that

at the given bit-error rate the protocol is able to

deliver close to 100% of the measurements, we

can infer that for this particular scenario, even

if half of the nodes have failed, there is still a

very high chance that 95% of the remaining nodes

will be unaffected. The large variance is caused

by the fact that if too many nodes around the

concentrator node fail, the network becomes dis-

connected from the concentrator node, and none of

the nodes can deliver its measurements. Estimating

the probability with which the network disconnects

is hard, and would require more simulation runs to

be performed.

VI. CONCLUSIONS AND FUTURE WORK

We have described various requirements

to which smart-metering protocols targeting

a widespread deployment should take into

consideration. We have touched on legislative,

technological and economic considerations which

affect a protocol’s design. We have presented a

new proposed protocol for use in smart-metering

applications, designed to operate under the given

constraints. We have simulated the protocol under

a variety of circumstances representing possible

real-world situations and show that the protocol

is a robust, reliable solution for communicating

collected data even when faced with high bit-

error rates or failure of many nodes in the

network. Bit-error rates have little effect on the

protocol’s reliability or communication latency.

The protocol is robust against node failure, and

ensures that working nodes route around failed

nodes effectively even at relatively high node

failure rates. We show that the protocol stays well

below the stated 1% duty cycle limit imposed

by European law, even at peak retransmission

rates. This leaves room for sending more frequent

updates or adding new features.

Future work includes performing further experi-

ments to assess the protocol’s capacity. This could

be tested by increasing the number measurements

to be delivered, or reducing some of the delays

involved in transmissions. Also it would be inter-

esting to see how the protocol deals with other

topologies. The current scenario consists of a re-

creation of a real-world sub-urban neighbourhood.

Other scenarios could be high-rise constructions

or sparsely populated areas, representing different

challenges each. Results on some of these experi-

ments are presented in [15].

REFERENCES

[1] G. Deconinck, “An evaluation of two-way communicationmeans for advanced metering in Flanders (Belgium),”2008 IEEE Instrumentation and MeasurementTechnology Conference, pp. 900–905, May 2008.[Online]. Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4547164

[2] J. Vasconcelos, “Survey of regulatory and technologicaldevelopments concerning smart metering in the EuropeanUnion electricity market,” 2008. [Online]. Available:http://cadmus.eui.eu/handle/1814/9267

[3] R. Olsen, “Technical considerations for broadbandpowerline (BPL) communication,” in EMC ZurichSymposium, 2005, pp. 1–6. [Online]. Available: http://preview.pserc.wisc.edu/documents/publications/papers/2005 general publications/olsen bpl paper feb2005.pdf

[4] S. Keemink and B. Roos, “Security analysisof Dutch smart metering systems,” Universityof Amsterdam, Amsterdam, 2007. [Online]. Avail-able: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.159.6314&amp;rep=rep1&amp;type=pdf

[5] IEEE Communication Society, “802.15.4 IEEE standardfor Information Technology-Part 15.4: Wireless MediumAccess Control (MAC) and Physical Layer Specificationsfor Low Rate Wireless Personal Area Networks (LR-WPANS),” 2003.

[6] Z. B. Alliance, “Zigbee specification,” ZigBee document053474r06, version, vol. 1, 2005.

[7] B. Lichtensteiger, B. Bjelajac, and C. Mu&#776;ller, “RFMesh Systems for Smart Metering: System Architectureand Performance,” Smart Grid, pp. 379–384, 2010.[Online]. Available: http://ieeexplore.ieee.org/xpls/absall.jsp?arnumber=5622071

[8] A. Liotta and G. Exarchakos, Networks for PervasiveServices: Six Recipes to Upgrade the Internet. Springer,2011, vol. 92.

[9] J. Hui and D. Culler, “Extending IP to low-power, wirelesspersonal area networks,” IEEE Internet Computing, pp.37–45, 2008. [Online]. Available: http://www.computer.org/portal/web/csdl/doi/10.1109/MIC.2008.79

[10] L. Hardy and M. Gafen, “A new highly-synchronizedwireless mesh network model in use by the ElectricCompany to switch to automatic meter reading:Case study,” 2008 5th International Conferenceon Networked Sensing Systems, pp. 31–34, Jun.2008. [Online]. Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4610892

[11] A. Krohn, M. Beigl, C. Decker, and T. Riedel,“Syncob: Collaborative Time Synchronization in WirelessSensor Networks,” 2007 Fourth International Conferenceon Networked Sensing Systems, pp. 283–290, Jun.2007. [Online]. Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4297432

[12] M. Ringwald and K. Romer, “BitMAC: a deterministic,collision-free, and robust MAC protocol for sensornetworks,” Proceeedings of the Second EuropeanWorkshop on Wireless Sensor Networks, 2005., vol. 00,pp. 57–69, 2005. [Online]. Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1461999

[13] KEMA Consulting, “Smart Meter Requirements - DutchSmart Meter specfication and tender dossier,” 2008.

[14] D. Willkomm, S. Valentin, and T. Parker, “SimulatingWireless and Mobile Networks in OMNeT++ TheMiXiM Vision,” Proceedings of the First InternationalICST Conference on Simulation Tools and Techniques forCommunications, Networks and Systems, 2008. [Online].Available: http://eudl.eu/?id=3031

[15] D. Geelen, “Analysis and performance assessment of arouting protocol for deployment in a (meshed) smart-metering network,” 2011.

348

Figure 2: Routes generated by the simulation. 0

20

40

60

80

100

120

1e-09 1e-08 1e-07 1e-06 1e-05 0.0001 0.001

Succ

ess

rate

(per

cent

age)

Bit error rate (P[bit-error])

Measurements deliveredMeasurements acknowledged

99

99.2

99.4

99.6

99.8

100

1e-05 0.0001

Figure 3: Delivery rates.

0

20

40

60

80

100

1e-09 1e-08 1e-07 1e-06 1e-05 0.0001 0.001 0

1

2

3

4

5

Dis

tanc

e (m

eter

s)

Nr

of n

odes

(cou

nt)

Bit error rate (P[bit-error])

Nr. of hopsPath length

Transmission distance

Figure 4: Distance measures.

0

0.02

0.04

0.06

0.08

0.1

1e-09 1e-08 1e-07 1e-06 1e-05 0.0001 0.001

Dut

ycyc

le (p

erce

ntag

e)

Bit error rate (P[bit-error])

ConcentratorOther nodes

Figure 5: Duty cycles.

0

20

40

60

80

100

120

10 20 30 40 50 60 70 80 90 100

Succ

ess

rate

(per

cent

age)

Nr. of active nodes (percentage)

Energy measurementsReverse-energy measurements

Gas measurementsWater measurements

90

92

94

96

98

100

50 55 60 65 70

Figure 6: Delivery rates of different measurements.

0

20

40

60

80

100

10 20 30 40 50 60 70 80 90 100 0

1

2

3

4

5

Dis

tanc

e (m

eter

s)

Nr

of n

odes

(cou

nt)

Nr. of active nodes (percentage)

Nr. of hopsPath length

Transmission distance

Figure 7: Distance measures.

349