A ZigBee based Advanced Meter Infrastructure

Abstract—The electric grid needs to provide utilities with abetter control over power demand, while making customersaware of their energy consumption profiles. Advanced MeterInfrastructure (AMI) aims to solve this problem.

This paper proposes a ZigBee solution to AMI and presents thehardware and software developed to implement it. The proposedAMI system is supported by a ZigBee mesh network, whereenergy meters are the nodes. A unique concentrator enables thecommunication between the meters and, over ethernet, the utility.It aggregates all meters messages and deals with utility’s requests.

A developed hardware module connects to an energy meter bya RS-232 interface, enabling it to communicate through ZigBee.Developed software supports the hardware and the meteringinfrastructure. The nodes software enables each energy metersensor node to autonomously report periodic energy measure-ments, handling the meters communication protocol, and torespond to request commands. The concentrators code managesa local database with all the network messages. A web interfacewas also developed.

I. INTRODUCTION

Wireless technologies for short and medium range commu-nications already cover many applications, such as consumerelectronics, building control, industrial process control, homeautomation and wireless sensor network (WSN). ZigBee playsa significant role among these technologies.

In the last years, ZigBee and 802.15.4 have proved theycan achieve good results for low bit rate applications, in thesame way WI-FI did for high bit rate wireless local areanetworks (LANs). ZigBee is a specification that extends thephysical (PHY) and medium access (MAC) layers defined bythe IEEE 802.15.4 protocol, providing network features like,hierarchical/stochastic addressing, route discovery, forwarding,authentication and encryption.

There has been a fast growth of ZigBee as a de factostandard for WSN. Large reliable deployments, using ZigBee,are now in place implementing ad-hoc WSN, such as, AMIin Goteborg [1], room locks in Mandalay Bay Hotels [2] andthe equipment tracking at Tri-City Medical Center [3].

Advanced Meter Infrastructure (AMI) and Automatic Me-ter Reading (AMR) are examples of applications for IEEE802.15.4 and ZigBee WSN. AMI refers to a metering systemthat records and reports customer consumption, hourly or eventmore frequently in a day. It allows customers to make real-timechoices about power utilisation and for utilities to be able tomitigate demand load during peak times [4], [5]. AMI encom-passes several different components, meters, communicationtechnology, AMR systems and data warehouses, creating atwo-way network between smart meters and utility businesssystems.

ZigBee Alliance specified in 2008 the Smart Energy (SE)profile to help the implementation of AMI over a ZigBee

WSN. The SE profile offers utilities a specification forimplementing HAN communications, providing support formetering, demand response and load control, text messages,device sample and security. Consumers can manage theirenergy consumption wisely, using automation and near real-time information, with the ability to choose interoperableproducts from a diverse range of manufacturers. In Marchof 2009, the ZigBee Alliance stated the SE profile wouldincorporate global IT standards from the Internet EngineeringTask Force (IETF), to provide applications with native IPsupport. As of March of 2010, the ZigBee Alliance announceda collaboration with the Wi-Fi Alliance, initially, to developthe version 2.0 of the SE profile. The profile’s draft (Aprilof 2010) points to the usage of 6LoWPAN. A compressionmechanism enables the use of IPv6 in IEEE 802.15.4 basednetworks.

Smart metering with embedded WSNs represents an emerg-ing market and is the starting point for the work described inthis paper. The paper proposes an architecture and describesthe hardware and software developed for an AMI systemfor a building or a neighbourhood, using a Zigbee meshnetwork. Each node in the ZigBee WSN, with meteringcapabilities, is an embedded system capable of autonomouslyand independently report measurement values. Each node canalso respond to received commands. Reported measurements,from all nodes, are aggregated by a network concentrator thatmakes them available over ethernet.

Other solutions for AMI/AMR have been reported. In [6]many of the expected capabilities of an AMI system, are pre-sented. Their proposal uses a dedicated router infrastructure formessage handling to which the energy sensors then connect.They also, employ a load balancing scheme, by simultane-ously using more than one channel to send data, because,in their solution, any costumer interaction must go throughthe network concentrator. In our solution, such interaction canbe provided, directly by the sensor node, freeing the networkfrom unnecessary traffic. We also consider redundant to usea dedicated router infrastructure. Our network infrastructureis made of only sensor nodes, with router capabilities, whichlowers its cost.

The structure of this paper is as follows. Section II intro-duces the architecture of the proposed AMI system, its com-ponents and the communication network. Section III describeshardware and software implementation details, as well as, theirarchitecture and design. Then, in Section IV, the prototypeand tests are discussed. Finally, the paper is concluded inSection V.

Fig. 1. Advanced Meter Infrastructure (AMI) based on a ZigBee mesh network.

II. SYSTEM ARCHITECTURE

The proposed architecture addresses a building or neigh-bourhood, creating a ZigBee WSN in which the energy metersare the network nodes. The communication between, eachnode and the utility management centre, over a wide areanetwork (WAN), is assured by a special node, the concentrator.The concentrator has data aggregation capabilities. As so,energy meters do not require a direct connection to the utilitymanagement centre, which represents a lower cost solution.Any kind of protocol can be used for communication withinthe WAN. As other works, we can use Ethernet [8], GSM orGPRS [9] [10].

Due to the fact that some energy meters are not in the smallrange area of the concentrator, all have forwarding capabilitiesto enable message routing. It can also happen that the meternodes can not cover the building or neighbourhood. In suchcase, auxiliary nodes, that do not have metering capabilities,can be used to extend the network to the necessary coverage.

Figure 1 presents, the proposed AMI architecture and themost important components. Each energy meter ZigBee nodeis able to autonomously and independently report measure-ment values, according to a pre-defined parameterization, andto respond to external requests. Energy meter sensor nodesdo not require great computational power. However, memorycan be an important issue, depending on the specifications ofthe time interval to maintain measured values. Additionally,nodes need to be energy autonomous to permit to identify thesource of a possible blackout. Under normal conditions, theyare powered by the electric grid.

The concentrator requires significantly higher resources. Itbundles together the collected data, either from meters orauxiliary nodes, to be sent to the utility. It also processesmessages sent by the utility to the nodes, such as, softwareupdates, test commands and configuration commands. Asthe concentrator has gateway functionality, it can implementaccess control permissions, where different information isexposed to different types of users. Although, access controlcan also be accomplished at the other WSN nodes.

III. IMPLEMENTATION

In our implementation, we developed a beaconless meshnetwork that forwards packets, according to ad hoc on-demanddistance vector (AODV) or tree routing if AODV fails [12].The on demand nature of AODV enables the discovery of anew message path if the previous found path changes due toa node failure.

In fact, ZigBee permits the formation of beaconless meshor beacon-based tree networks, besides the star topology [13].Using beacons, that are synchronisation frames sent peri-odically, network devices can save power by sleeping forsome time periods. As in an AMI system nodes are normallypowered by the electric grid, we focused on having a self-healing reliable network in detriment of power consumptionreduction. Additionally, a tree network, relies on a staticdistributed hierarchical addressing scheme to route messages.So, if used, any failing node in the network would disconnectall nodes beneath him, rendering the branch useless.

The concentrator is the coordinator of the ZigBee network.Actually, any ZigBee network must have a coordinator thatchooses the least noisy channel (from the available ones), setsthe network ID and defines other key network parameters.As the coordinator address is always zero (0x0000), codefor discovering it can be omitted from the sensor nodes,simplifying their code. All other WSN nodes (figure 1) arerouters.

Fig. 2. The energy meter sensor node.

For prototyping purposes, energy meter sensor nodes arecommercially available digital energy meters connected byRS-232 to a ZigBee module (figure 2). The concentrator isintended to be an embedded system with a WAN interface.However, in the validation prototype, it is a PC with anethernet card and a ZigBee interface(figure 3).

Fig. 3. The concentrator.

A. Hardware

We decided to develop a module instead of using a com-mercial one. Figure 4 presents the module. As we use ZigBeefor different applications with different interfaces we wantedto have a base layout design that we can control and modify.We looked for the ICs available on the market. We decidedbetween Jennic and Texas Instruments (TI) solutions. TheJennic solution is more powerful, but requires an externalflash. However, the choice for the TI CC2430 chip wasmainly due to prior team knowledge about this platform andits development software. The module, besides the ZigBeesystem on a chip (SoC), includes a RS-232/TTL converterand a voltage regulator. The module allows for two types ofantennas: a printed circuit board (PCB) inverted F antenna(IFA) and an antenna connected through an external connector.

When designing the PCB, we carefully addressed signalintegrity for digital circuits, such as loop inductance, crosstalkand power distribution network (PDN) issues. For the RF part,the balun that serves both antennas was implemented with afew components and a transmission line trace, as suggestedby TI [14]. A 4-layer PCB was used, with the inner layersfor ground and power distribution and the outer for signalrouting and component placing. To reduce loop inductanceand crosstalk, we avoided discontinuities on the planes. Also,for crosstalk reduction, all empty routing space was filledwith copper, and connected to the ground plane. Componentswere arranged according to their functionality to help crosstalkmitigation between unrelated signals. For components, wechosen the smallest package to ensure low equivalent seriesinductance (ESL).

PDN bypass capacitors, near the ICs power pins, are usedto connect them to ground plane. Traces were kept as smallas possible and chamfering corners are used, to avoid trans-mission line reflections.

Fig. 4. The developed ZigBee Module.

B. Software

Figure 5 presents the software architecture. As illustratedon the figure, the major components are:

- the sensor that reports information and responds torequests;

- the concentrator that requests, aggregates and provides,over ethernet, information about all network nodes;

- the web interface, provides access and control to nodesin a user friendly manner.

Fig. 5. The Software Architecture.

Every network node, coordinator included, hosts the Zig-Bee stack. Several Z-Stack compile options need to be de-fined/optimised. These options include the network ID, thefrequency channel, the device logical type (coordinator, routeror end device), the number of children a device may have,the use or not of encryption, several retry, timeout and delayvalues, etc.

Each sensor node also runs an event driven applicationto handle configuration messages, to respond to requests(measurement and status), and to send measurement values,according to pre-defined periodicity. To communicate with theenergy meter, the node implements what is required accordingto the IEC 62056-21 Mode C protocol [15], but not the entireprotocol.

The software running in the ZigBee module of the concen-trator implements the gateway functionality and the coordina-tor functionality. To implement the gateway functionality, the

coordinator translates data between the ZigBee network and acustom serial protocol, over RS-232. In order to reduce the useof broadcast messages, to avoid network congestion, the coor-dinator is also responsible by sending messages as broadcastor unicast, depending on the command type. ZigBee modulesare programmed using the IAR Embedded Workbench v7.30band coded in C programming language.

The remaining functionality of the concentrator, such as,storage and access to the information, about timestamps,measurement values and status, is C# code running in theprototypes PC. An interface to local data access was alsodeveloped in C#.

Finally, a web interface mainly coded in JavaScript, permitsto demonstrate the system potential. The interface runs ona PC with the Apache web server, simulating the utility’smanagement centre.

IV. TESTS AND RESULTS

The ZigBee module has been produced and tested. After,we installed a prototype to test AMI system functionality.

A. ZigBee ModuleWe sent the Gerber and Echelon files to a manufacturer and

received the PCBs. We applied the solder paste, using a stencilsheet, and manually placed the components. Reflow solderingwas used to fix them.

After some electrical tests to ensure the absence of shortcircuits in-between layers and chips pins, and to confirm thepower levels throughout the board, we developed a softwareapplication to verify its functionality.

Antennas emissions were verified using a Rohde & SchwarzFS300 spectrum analyzer. Due the difficulty in measuringthe PCB antenna emissions we used the external antennaconnector for the tests. However, conclusions are valid forboth antenna types, since they use exactly the same balun.

We verified the central frequency and emissions for allchannels. Figure 6 shows channel 16 emitting at 2,430GHz.The obtained value of 2,429596GHz, deviates 400Hz fromthe 2,430GHz, where IEEE 802.15.4 maximum permittedtolerance is only 100Hz. Figure 7 presents the same emissionover a 1.5GHz frequency range. Chips emissions occur in thecorrect frequency band. Further RF tuning is require to complywith the standard defined tolerance.

Fig. 6. Module emission at 2430MHz.

Fig. 7. Module emission at 2430MHz over a 1.5GHz frequency range.

B. AMI System

We tested the system functionality by setting-up a simplenetwork with 4 nodes, distributed on a buildings floor, aspresented in figure 8. The network includes two 2 energymeter sensor nodes, an auxiliary node and the concentrator.The auxiliary node, situated in a corridor, assures the datafrom energy meter 1 arrives to the concentrator. The prototypevalidates the network functionality, the message routing, thepossibility to extend the coverage with auxiliary nodes, andthe adequacy of ZigBee for AMI systems.

Fig. 8. Prototype network structure with nodes location.

The following tests were accomplished, in the prototype(figure 8):

1) Activation of concentrator and energy meter 1 node. Nonetwork association occurred, due to lack of range.

2) Introduction of auxiliary node. Measurements from en-ergy meter 1 arrived at the concentrator.

3) Activation of energy meter 2 forcing it to associate withenergy meter 1. Energy meter 2 measurements arrivedat the concentrator.

4) Sent measurement request to all nodes (broadcast).5) Sent measurement request to a specific energy meter

(unicast).

6) Confirmed periodicity of energy meters autonomouslysent data.

The first three validate the network, and the last three itsfunctionality. To send and display replies to sent commandsthe web interface (figure 9) is used. The return values fromcommands are validated by the energy meters display.

Fig. 9. Web Interface.

Each meters information appears in a different column, sothere are 2 in our prototype. At the top of each column themeters serial number identifies them. The four following linesshow the last four measurement or commands replies fromthe meter. The time-stamp appears between square brackets.Parenthesis enclose the parameter value whose code, is thenot enclosed preceding number. Two drop-down menus al-low to choose the type of parameter to request and specifyits destination module. A broadcast destination can also beselected. The send button executes the request. Finally, therescan button forces a meter recount by sending an identifyrequest broadcast.

We can conclude that the ethernet functionality works andcan give access to concentrators locally stored data. Also per-mitting the remote control of energy meters, either individuallyof as a whole.

V. CONCLUSION

This paper proposed an architecture for an Advanced MeterInfrastructure (AMI), describes the implementation of therequired hardware, and presents the design and implementationof a software architecture for it. We successfully build asmall low power ZigBee module that fits inside the energymeters casing, and connects to it via the RS-232 interface. Thesoftware architecture permits bi-directional communicationbetween the meters and the utility. Additionally one can accessmetering data from a web page.

ZigBee is a good solution for an AMI system. Installationcosts can be reduced by using the energy meter sensor nodeswith routing capabilities, and a sole concentrator to aggregatethe network measurements and status. Because buildings tendto have a power backbone that vertically crosses all the floors,the energy meters are not scattered inside a building but ratherorganized according to that infrastructure. The WSN can alsobenefit from this organization.

Further coverage related tests should be made in orderto take full advantage of the unique organization of energy

meters inside a building. As to analyze the advantages anddisadvantages of using a ZigBee RF signal booster, as analternative to the auxiliary nodes.

ACKNOWLEDGMENT

The authors would like to thank...

REFERENCES

[1] Thomas Arnewid, AMI in the city of Goteborg, Metering International,pp 76 - 79, Issue 4, 2007.

[2] ZigBee Success Stories. Available, in March of 2010, from: http://www.zigbee.org/imwp/download.asp?ContentID=15272

[3] ZigBee Sucess Stories. Available, in March of 2010, from: http://www.zigbee.org/imwp/download.asp?ContentID=15796

[4] AMR/AMI Infrastructure, DIGI White paper. Available from: http://www.m2mpremier.com/uploadFiles/wp amrami.pdf.

[5] The Role of Load Research in Automated Meter Infrastructure/MeterData, AEIC, September 2008. Available from: http://www.aeic.org/loadresearch/AMI MDMWhitePaperFinal2.pdf.

[6] Hoi Yan Tung, Kim Fung Tsang, Ka Lun Lam, ZigBee sensor network forAdvanced Metering infrastructure. International Conference on ConsumerElectronics, Digest of Technical Papers, 2010, pp. 95 - 96.

[7] Kraig Mitzner, Complete PCB Design Using OrCad Capture and Layout,Elsevier, 2007.

[8] Liting Cao, Wei Jiang, Zhaoli Zhang, Automatic Meter Reading SystemBased on Wireless Mesh Networks and SOPC Technology. Second In-ternational Conference on Intelligent Networks and Intelligent Systems,2009 , pp. 142 - 145.

[9] Primicanta, A.H., Nayan, M.Y., Awan, M., Hybrid Automatic MeterReading System. Computer Technology and Development InternationalConference, 2009. Vol.2, pp. 264 - 267.

[10] Fei Ding, Guangming Song, Jianqing Li, Aiguo Song, A ZigBee BasedMesh Network for Home Control System. Education Technology andTraining and International Workshop on Geoscience and Remote Sensing,2008. Vol.1, pp. 774 - 748.

[11] Texas Instruments, Z-Stack - ZigBee Protocol Stack version 1.4.3.Available from: http://focus.ti.com/docs/toolsw/folders/print/z-stack.html

[12] Texas Instruments, Z-Stack Developer’s Guide version 1.1. 2007, p. 13.[13] ZigBee Alliance, ZigBee Specification. 2008, p. 31.[14] Audun Andersen, DN0007 - 2.4GHz Inverted F Antenna. Texas Instru-

ments, 2008.[15] IEC TC 13. EN 62056-21, Electricity metering - Data exchange for

meter reading, tariff and load control - Part21:Direct local data exchange.CENELEC, Brussels, 2002

[16] Proposta de Arquitectura, Technical Report, Project Arquitectura deComunicaes do INOVGRID, 2008.