SRSM and Beyond Local Communications Development

Author(s) Document Status Document Ref. No. Document Version Date Issued

Simon Harrison Draft SRSM LCD 0_5 5 November 2008

SRSM and Beyond – Local Communications Development

Version 0_5

Table of Contents
Table of Contents ...............................................................................................2 Figures ...............................................................................................................3 Tables ................................................................................................................4 Document Control ..............................................................................................5 1.1 Version History ....................................................................................5 1.2 Review Group & Website ....................................................................6 1.3 Intellectual Property Rights and Copyright ..........................................7 1.4 Disclaimer ............................................................................................7 2 Executive Summary and Introduction .........................................................8 2.1 Executive Summary ............................................................................8 2.2 Purpose ...............................................................................................8 2.3 Scope ..................................................................................................9 2.4 Objective..............................................................................................9 2.5 Structure of this Document ..................................................................9 3 Glossary & Conventions ...........................................................................11 3.1 Document Conventions .....................................................................11 3.1.1 Market Segments .......................................................................11 3.1.2 Meter Functionality .....................................................................11 3.1.3 Meter Location ...........................................................................12 3.1.4 Meter and Metering System .......................................................12 3.2 Glossary ............................................................................................14 4 Local Communications Context ................................................................21 4.1 General Context ................................................................................21 4.2 Smart Utility Context for Local Communications ...............................22 4.3 Smarter Display Options Using Local Communications ...................23 4.4 Smart Home Context .........................................................................25 5 Associated Topics.....................................................................................28 5.1 A National Standard ..........................................................................28 5.2 Security..............................................................................................28 5.3 Delivering the Last Mile .....................................................................29 5.4 Local Device Classification ...............................................................30 5.5 Processes/Activities Required...........................................................30 5.6 Types of Data ....................................................................................31 5.7 Independent & Private Local Networks .............................................32 5.8 Distinguising Local Communications from the HAN .........................36 5.9 Wireless to Wired Options .................................................................38 5.9.1 Wired/Wireless Protocol Development ......................................39 5.10 British Housing Types .......................................................................39 5.10.1 Houses By Type .........................................................................40 5.11 Support for Third Party Applications .................................................41 6 Principles & Assumptions .........................................................................43 6.1 Local Communications Principles .....................................................43 6.2 Local Communications Assumptions ................................................43 7 Requirements ...........................................................................................45 7.1 Requirements ....................................................................................45 7.2 Requirements Notes..........................................................................47 7.3 Potential Additional Requirements ....................................................49 8 Solution Options .......................................................................................50 8.1 Solution Options Descriptions ...........................................................51 Page 2 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

8.2 Other Solution Options ......................................................................61 Additional Considerations .........................................................................66 9.1 Network & Addressing Protocols .......................................................66 9.2 Frequency Considerations ................................................................68 9.2.1 Frequency Information ...............................................................68 9.2.2 Licensed or Unlicensed ..............................................................70 9.3 Data Exchange Format Options ........................................................70 10 Evaluation of Solution Options ..............................................................73 10.1 Evaluation Process............................................................................73 10.2 Evaluation Methodologies .................................................................73 10.2.1 Evaluation Weighting .................................................................73 10.2.2 Evaluation Assessment ..............................................................74 10.3 Evaluation Criteria .............................................................................74 10.4 Evaluation Scorecard ........................................................................77 10.4.1 Evaluation Notes ........................................................................81 10.5 Evaluation Scenarios...................................................................... 116 11 Conclusions & Recommendations ..................................................... 118 11.1 Conclusions .................................................................................... 118 11.2 Recommendations ......................................................................... 118 11.3 Testing & Evaluating Criteria .......................................................... 120 11.4 Solution Summary Statements ....................................................... 123 11.4.1 Bluetooth low energy............................................................... 124 11.4.2 Wavenis .................................................................................. 124 11.4.3 Wireless MBus ........................................................................ 124 11.4.4 ZigBee @ 868MHz .................................................................. 125 11.4.5 ZigBee @ 2.4GHz ................................................................... 125 11.4.6 Z Wave .................................................................................... 125 12 Issues ................................................................................................. 127 13 References ......................................................................................... 128 Appendix A: Referential Integrity Check ....................................................... 130 Appendix B: Last Mile Evaluation ................................................................. 132 Last Mile Criteria .................................................................................... 132 Appendix C: Initial Field Test ....................................................................... 133 Test Report ................................................................................................ 133 Responses to the Report........................................................................... 135 Online Reference ...................................................................................... 136 Appendix D: ZigBee@2.4GHz Evaluation Introduction ................................ 137 Preamble – On using ZigBee for UK Smart Metering Local Communications .................................................................................... 137 Appendix E: Bluetooth Information on Profiles, Certification and Interoperability .............................................................................................. 139 9

Figures
Figure 1: Smart Meter Locations .....................................................................12 Figure 2: Smart Metering Systems, Illustration of Flexible Approaches ..........13 Figure 3: SRSM Smart Metering Operational Framework Scope ...................21 Figure 4: Smart Utility Context .........................................................................23 Figure 5: Smart Display Context ......................................................................24 Figure 6: Smart Home Context ........................................................................25 Figure 7: Smart Home Context & Clusters ......................................................26 Figure 8 Different Uses of Local Communications ..........................................27 Page 3 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Figure 9: Local Communications for the Last Mile ..........................................29 Figure 10 Technical WAN Interoperability .......................................................32 Figure 11: Simple Collection of Smart Meters and Local Devices ..................32 Figure 12: Independent Networks....................................................................33 Figure 13: Local Communication Signal Range ..............................................34 Figure 14: Overlapping Wireless Ranges ........................................................34 Figure 15: Required Local Communications Range Example.........................35 Figure 16: Mesh Network to Concentrator .......................................................36 Figure 17 Possible Logical Networks...............................................................37 Figure 18 OpenHAN Interfaces .......................................................................37 Figure 19 ZigBee & DLMS Illustration .......................................................... 138

Tables
Table 1 Local Communications Group Members ..............................................7 Table 2 Glossary ..............................................................................................20 Table 3 Stock Profile - English House Condition Survey 2005........................40 Table 4 Type of Dwelling - Scottish House Condition Survey 2004/5 .............40 Table 5 1998 Welsh House Condition Survey .................................................40 Table 6 'Overall' British Housing Type Volumes ..............................................41 Table 7 Local Communications Principles.......................................................43 Table 8 Local Communications Assumptions..................................................44 Table 9 Local Communications Requirements ................................................47 Table 10 Local Communications Requirements Notes ...................................49 Table 11 Solution Options Guide .....................................................................51 Table 12 Bluetooth low energy ........................................................................52 Table 13 M-Bus ................................................................................................52 Table 14 Wavenis ............................................................................................54 Table 15 ZigBee @ 868MHz ...........................................................................55 Table 16 ZigBee @ 2.4GHz .............................................................................58 Table 17 Z-Wave .............................................................................................61 Table 18 Evaluation Criteria ............................................................................77 Table 19 Evaluation Scorecard........................................................................80 Table 20 Evaluation Notes ............................................................................ 116 Table 21 Evaluation Scenario Suggestions .................................................. 117 Table 22 Evaluation Testing Recommendations .......................................... 123 Table 23 Issues ............................................................................................. 127 Table 24 References..................................................................................... 129 Table 25 Referential Integrity........................................................................ 132 Table 26 Last Mile Evaluation Criteria .......................................................... 132 Table 27 Field Test Results .......................................................................... 134

Page 4 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Document Control
1.1 Version History
Version 0_1 0_2 Date 7 February 2008 10 March 2008 Author Simon Harrison Simon Harrison Description Initial draft Updated following initial meeting of development group: Includes changes made to the online version of the document by John Cowburn of PRI, and materials provided off line by Dave Baker of Microsoft and Brian Back of LPRA 0_2_1 15 April 2008 Simon Harrison Updated to include information and a number of comments provided prior to 2nd meeting of Local Communications Development Group Significant update following two meetings of the Local Communications Development Group Interim draft prepared for meeting #6 of the group Updated following review & evaluation meeting of Local Communications Development Group Updated following final meeting of Local Communications Development Group snipurl.com/lcdgv21 Online Version snipurl.com/lcdgv1 snipurl.com/lcdgv2

0_3

September 2008

Simon Harrison

snipurl.com/lcdgv3

0_4

27 October 2008

Simon Harrison

snipurl.com/lcdgv4

0_5

5 November 2008

Simon Harrison

This document is a development of Schedule H of the Smart Metering Operational Framework Proposals and Options v1 document, published by the Page 5 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Energy Retail Association in August 2007 – the document history of which is shown below.
Version 0.1 Date 17th July 2007 Author Simon Harrison Description Initial draft based upon original consolidated SRSM Communications Solution Options document. Minor update following review Update for Smart Metering Operational Framework publication Updated following consultation exercise. Updated following project workshop Updated following receipt of related papers from stakeholders

0.2 0.3 0.4

25th July 2007 6th August 2007 December 2007

Alastair Manson Simon Harrison Simon Harrison

Document passed to Local Communications Development Group for ongoing development

1.2 Review Group & Website
This document has been developed with the assistance of a group of interested parties, including energy suppliers, meter manufacturers, communications experts, interoperability experts and other stakeholders. Table 1 below lists the organisations and companies who are members of the group. Alcatel-Lucent All Island Power Arm Atmel BERR British Gas Cambridge Consultants Cason Engineering Daintree Networks DEFRA E.ON UK Electralink Ember Energy Retail Association Federation of Communication Services Freescale Fujitsu Himsley Meter Revenue Services I+P Services Ingenium Laird Technologies Landis+Gyr Microsoft National Grid Alertme.com Association of Meter Operators Arqiva British Electrotechnical & Allied Manufacturers Association BGlobal Metering EDF Energy Cambridge Silicon Radio Coronis Data Direct Echelon Npower Elster Ewgeco Engage Consulting Freescale First Utility Green Energy Options Horstmann Imserv Itron Acute Technology Low Power Radio Association More Associates Ofcom 5-Nov-08

Page 6 of 140

SRSM and Beyond – Local Communications Development Ofgem Orsis Q’Vedis Remote Energy Monitoring ScottishPower Sensus Metering Services Siemens Energy Services Society of British Gas Industries theowl.com Trilliant Networks Zensys ZigBee Alliance

Version 0_5

Table 1 Local Communications Group Members

Onzo PRI UK Ltd Radiocrafts Renesas Technology Scottish & Southern Energy Sentec Sustainability First Secure Electrans Tridium Utilihub ZigBee Acute Technology

Full details of the membership of the group, its’ meetings and papers can be viewed at the public website: srsmlocalcomms.wetpaint.com

1.3 Intellectual Property Rights and Copyright
All rights including copyright in this document or the information contained in it are owned by the Energy Retail Association and its members. All copyright and other notices contained in the original material must be retained on any copy that you make. All other use is prohibited. All other rights of the Energy Retail Association and its members are reserved.

1.4 Disclaimer
This document presents proposals and options for the operation of smart metering in Great Britain. We have used reasonable endeavours to ensure the accuracy of the contents of the document but offer no warranties (express or implied) in respect of its accuracy or that the proposals or options will work. To the extent permitted by law, the Energy Retail Association and its members do not accept liability for any loss which may arise from reliance upon information contained in this document. This document is presented for information purposes only and none of the information, proposals and options presented herein constitutes an offer.

Page 7 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

2

Executive Summary and Introduction

2.1 Executive Summary
The Local Communications Development Group has considered and agreed the principles, requirements, a number of solution options and recommendations for the communications between gas and electricity smart Metering Systems and other devices within a home. This document presents in detail; • the specific smart metering context for Great Britain • a number of related topics as considered by the group • a set of agreed principles and requirements • detailed overviews of six potential solution technologies • a desktop evaluation of those technologies The report concludes; • that a low power wireless solution is appropriate for most metering installations • that there are a number of existing and available technologies that could meet and exceed the smart metering requirements • that the exercise has benefitted from being conducted in the public arena, attracting input and support from a range of experts and stakeholders • that participants in the exercise are much more informed about the requirements, opportunities and options for smart metering Local Communications It recommends; • that further work be undertaken to address areas of ambiguity and complexity in requirements • that there are gaps in the approaches of all of the solution options that will need to be understood and addressed in order to fully deliver the smart metering requirements • that the evaluation process be completed using a combination of field and laboratory testing and a panel review process • that work continue in a timely fashion, as this is an area where global activity in smart metering and other activities is developing the technologies very quickly

2.2 Purpose
This document presents the context, requirements, issues and solution options for two-way Local Communication for smart Metering Systems. It also includes an evaluation of solution options and recommendations for further consideration. Any statement of preference for particular communications solution options does not constitute a firm or binding decision by the Suppliers participating in the Supplier Requirements for Smart Metering (SRSM) project. Page 8 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Further information on the SRSM project is available from: http://www.energy-retail.org.uk/smartmeters.

2.3 Scope
The scope of this document is limited to the requirement for two way communications between smart gas and electricity meters and local devices. For ease of understanding and application to a familiar domestic context, this document refers mainly to the ‘Home’ and uses illustrations of houses to represent locations for meter points. However, the communications solution options listed here could apply equally to non-domestic premises – i.e. Local Communications within an office or factory. This document references, but does not define, the opportunity to use the Local Communications capability of a smart meter to provide a ‘Last Mile’ option to deliver WAN Communications. This document does not address the commercial issues arising from communications requirements.

2.4 Objective
The objective of the Local Communications Development exercise is to fully document and evaluate the options relating to Local Communications for smart metering, and if possible to produce a solution recommendation (or recommendations) to the ERA SRSM Steering Group.

2.5 Structure of this Document
The sections of this document are: - Document Definition o Section 1 – Document Control o Section 2 – Introduction o Section 3 – Glossary and Document Conventions - Local Communications Context o Section 4 – Local Communications Context – a plain English explanation of the context for smart metering and Local Communications o Section 5 –Associated Topics – information on related topics considered by the SRSM project or the Local Communications Development Group - Requirements o Section 6 – Principles and Assumptions – established by the Local Communications Development Group o Section 7 – Local Communications Requirements - Solution Options o Section 8 – Definition of the solution options considered by the Group using a standard proforma o Section 9 – Additional Considerations – providing detail on key solution related topics – frequency, protocols etc. - Evaluation & Recommendation Page 9 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

-

o Section 10 – Evaluation Criteria and process completed by the Local Communications Development Group o Section 11 – Recommendations – by the Local Communications Development Group to the SRSM Project Steering Group Additional o Section 12 – Issues – ongoing and unresolved general issues relating to Local Communications Solutions o Section 13 – References – links to papers referred to by this report o Appendices – Referential Integrity table, Field test undertaken by group members, Last Mile evaluation, ZigBee @ 2.4GHz additional information

Page 10 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

3

Glossary & Conventions

3.1 Document Conventions
The ERA SRSM project has been running since September 2006, and has established a number of practical conventions and assumptions with regard to smart metering. The project published ‘Proposals and Options for a Smart Metering Operational Framework’ in August 2007 – this document is over 300 pages in length and presents comprehensive proposals to meet the practicalities of operating smart metering in a competitive retail environment. The following subsections give a brief overview of a number of these topics. For a more complete summary of the Smart Metering Operational Framework, please visit http://www.energy-retail.org.uk/smartmeters

3.1.1 Market Segments
The Smart Metering Operational Framework has been written to address the requirements of energy Suppliers in the domestic retail markets. However, it recognises that meters used in homes can actually be exactly the same as meters used in businesses, and therefore the Smart Metering Operational Framework proposals could apply. Therefore, within this document, the solution options discussed could be suitable for use in both domestic and equivalent non-domestic markets.

3.1.2 Meter Functionality
The degree of ‘smartness’ of a smart meter is something that distinguishes most of the metering products available today, or that are being installed as part of smart metering projects overseas. The SRSM project has agreed, and discussed with meter manufacturers and the wider energy stakeholders, a set of functional requirements for gas and electricity smart meters. These requirements do not represent final proposals and are presented here to give context to the Local Communications discussions. • • • • • • • •
1

2 Way Communications – WAN and Local (see below) Interval measurement and storage of consumption data Support for flexible and configurable energy tariffs Interoperable data exchange and protocols Remote connection/disconnection1 Support for prepayment/pay as you go operation (subject to the footnote above) Support for microgeneration Provision of consumption information

For electricity, the inclusion of a switch/breaker/contactor has been agreed for all meters. The inclusion of similar, valve-based functionality for all gas meters remains subject to cost.

Page 11 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development •

Version 0_5

Remote configuration of tariffs, meter operations, upgradeable firmware etc. Please note that ‘clip on’ or similar devices where information is captured via a pulse counter, optical port, or by use of a sensor around an electricity cable are not considered smart under the definitions of the Smart Metering Operational Framework and are not included in this context. However, through the development of a standard for smart metering Local Communications, any future ‘standalone’ devices could utilize the frequencies and protocols defined by the Smart Metering Operational Framework.

3.1.3 Meter Location
Throughout, this document refers mainly to the ‘Home’ and uses illustrations of houses to represent locations for meter points. However, smart meters and the communications solution options listed here could apply equally to other domestic and non-domestic premises types.

Figure 1: Smart Meter Locations

The ERA Smart Metering Operational Framework documentation specifies ‘domestic-sized’ metering, and such meters could be installed in any type of property where energy consumption is within the load/capacity capability of such meters. The Smart Metering Operational Framework includes a number of Meter Variants, usually to accommodate specific energy supply requirements of a metering point – e.g. polyphase electricity supply or a semi concealed gas meter location (see definition of Meter Variant below). Local Communications, unless specifically excluded by the Meter Variant definition in the Smart Metering Operational Framework, is required in all Meter Variants. It is also the case that the placement and location of meters as shown in diagrams is illustrative.

3.1.4 Meter and Metering System
Throughout this document, references to a smart meter, particularly within diagrams, should not be interpreted as referring only to smart meters where all of the functionality is contained within one ‘box’. There is regular use of a picture of an electricity smart meter to represent smart Metering Systems.

Page 12 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Smart Metering Systems – Illustration of Flexible Approaches

Software

Smart Metering Metering System Metering System Systems, with all using a separate using a separate the functionality, ‘black box’ and ‘black box’ (or including external antenna boxes) to deliver communications to deliver functionality “under the glass” functionality

Illustration of how fuels could share (with suitable commercial arrangements) a single set of black box(es) to deliver functionality

In all cases, the metrology functions must be delivered by a regulated measuring instrument. The required functionality could be delivered by components: - within the meter casing; - through the use of one or more new hardware components (in conjunction with new meters or retrofitted to existing); or - external hardware components shared between fuels. Generally, no component of the smart Metering System will be reliant upon equipment owned by the customer (e.g. broadband router), or services under the control of the customer (e.g. telephony provider). There may be individual circumstances where use of the customers equipment is unavoidable (customer chooses to own the meter, or particularly within a non-domestic context where additional energy supply contractual terms can be applied).

Figure 2: Smart Metering Systems, Illustration of Flexible Approaches

As defined by the SRSM project, a smart metering system could comprise a number of physical devices (external modems, antennas etc.) to deliver the smart functionality requirements. The potential variety of physical locations and conditions of metering points could result in smart metering systems where components are not located together in the same metering cupboard, or on the same metering board. It would not be practical to illustrate or explain these potential variations within this document. Therefore all general references to smart meters and uses of icons to represent smart meters in this document should be inferred as meaning the defined Metering System.

Page 13 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

3.2 Glossary
A number of these definitions are necessarily drawn directly from the Smart Metering Operational Framework, as they apply across the scope of that document and not just to Local Communications.
Term 3-DES Meaning An enhanced form of Data Encryption Standard, where the cipher is used three times to increase the protection provided by the encryption IPv6 over Low power Wireless Personal Area Networks. A developing set of protocols aiming to enable IPv6 packets of data to be transmitted over IEEE 802.15 networks (e.g. Bluetooth and ZigBee). The method by which the Smart Metering Operational Framework controls access to smart Metering Systems, smart metering data and associated devices. Also known as Ethernet Active Line Access A communications model based upon high speed broadband to gateway equipment in the home. More detail is available at : www.ofcom.org.uk/telecoms/discussnga/eala/ Advanced Energy Control – an application profile of the Z Wave standard Advanced Encryption Standard Where the Advance Encryption Standard uses 128 bit key Adaptive Frequency Hopping - a method of transmitting radio signals by rapidly switching between frequency channels, used by Bluetooth Advanced Metering Infrastructure, an approach to smart metering, generally describing the whole system to include meters, communications and systems Automated Meter Reading, the collection and communication of metering information from meters to systems. Can be done using handheld (walk by) or drive by equipment, or be based on a fixed network Advanced Microsensors – a semiconductor fabricator Application programming interface – a piece of software enabling other applications to make use of existing operating systems or services Application Support layer – part of the ZigBee protocol stack Advanced Silicon Etch – a semiconductor fabricator Application Specific Integrated Circuit – a chip designed solely for a particular use

6LoWPAN

Access Control

Active Line Access

AEC AES AES-128 AFH

AMI

AMR

AMS API

APS ASE ASIC AtEx

ATmosphères EXplosibles
The AtEx Directive is two EU directives describing what equipment and work environment is allowed in an environment with an explosive atmosphere. The equipment directive (94/9/EC) is relevant to gas metering

Page 14 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Term Authorised Party Meaning

Version 0_5

Means the Supplier or another person authorised by configuration of the Access Control security policies in the Metering System to interrogate or configure the Metering System. Authorised Parties could include a communications service provider, a meter operator, a network operator etc. A data communications protocol for building automation and control networks A component in radio systems linking antennas to other components Stands for Bose, Chaudhuri and Hocquenghem. A BCH code is a multilevel, cyclic, error-correcting, variable length digital code and can be used in low power communications as error-correcting codes A wireless communication standard using low power radio See detail in section 8. Describes a network where network devices are worn on (or implanted in) the body. Bill of Materials – term used by manufacturers to cover a list of materials and components used to make an assembled item. Binary Phase Shift Keying A form of Phase Shift Keying Commercial Building Automation A form of cryptographic operations European Committee of Domestic Equipment Manufacturers – representing white goods and appliance manufacturers. Have developed AIS (Application Interface Standard), currently in the process of obtaining CENELEC standards approval. Product marking to signify conformance with European Union regulations European Committee for Standardisation (Comité Européen de Normalisation) European Committee for Electrotechnical Standardisation (Comité Européen de Normalisation Electrotechnique) European Conference of Postal and Telecommunications Administrations (Conférence européenne des administrations des postes et des télécommunications) Complementary Metal Oxide Semiconductor – a type of microchip COmpanion Standard for Energy Metering The interface model for DLMS Central processing unit Cyclic redundancy check - a system of error control for data transmission Carrier sense multiple access with collision avoidance – part

BACnet Balun BCH

Bluetooth Body Area Network BoM

BPSK CBA CCM CECED

CE CEN CENELEC CEPT

CMOS COSEM CPU CRC CSMA-CA

Page 15 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Term

Version 0_5

Meaning of a class of protocols to control how nodes in a network communicate Electronic interactions including the transmission of data between Metering Systems and Authorised Parties or Metering Systems and Local Devices Data Encryption Standard, using 56 bit keys Danish Energy Savings Trust Device Language Message Specification – European data protocol for meter communications Direct Sequence Spread Spectrum - a method of transmitting radio signals by rapidly switching between frequency channels Elliptic curve cryptography – an approach to public key cryptography Energy Retail Association – trade association representing the major domestic energy suppliers in Great Britain European Smart Metering Industry Group – an association of companies with an interest in European smart metering ESTI standard covering electromagnetic compatibility and radio spectrum matters European Telecommunications Standards Institute European Union Evaluation Kit – a software/hardware development tool Federal Communications Commission, US regulator of the radio spectrum and other communications Forward Error Correction – a system of error control for data transmission Frequency Hopping Spread Spectrum – a method of transmitting radio signals by rapidly switching between frequency channels Federal Information Processing Standards US Federal Standards for non-military applications. Includes the P192 curve which is used in elliptical cryptography Failures in time – a metric associated with reliability and testing Frequency Shift Keying – a frequency modulation scheme 2FSK and 4FSK are different forms of Frequency Shift Keying Generally means a node on a WAN/HAN network that facilitates connection between the two networks. A smart meter may be a Gateway between enterprise applications connected to the WAN and Local Devices connected to a HAN. There are other Gateways that may be in a home that will provide the same type of activity – e.g. BT HomeHub, Sky Digital Box etc. Gaussian Frequency Shift Keying – a form of modulation used for radio communications – is used by Bluetooth and Z-

Data Exchange

DES DEST DLMS DSSS

ECC ERA ESMIG ETS 300-220 ETSI EU EVA Kit FCC FEC FHSS

FIPS

FIT FSK

Gateway

GFSK

Page 16 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Term GMSK GPIO GPRS GPS GSM HAN Hand Held Unit Meaning Wave

Version 0_5

Gaussian Minimum Shift Keying – a form of modulation used for radio communications – is used by GSM General Purpose Input/Output General Packet Radio System – a mobile telephony data transmission system Global Positioning System Global System for Mobile communications – a mobile telephony standard Home Area Network, typically a network of connected devices within the confines of residential premises A mobile device, usually used by a Meter Worker, capable of interaction with a Metering System using Local (or WAN) Communications. Could also include devices that interact with a Metering System using a dedicated optical port. A brand name for a technology providing communication using powerline technology within a home High temperature operating life – a form of estimating the operating life of a product Heating Ventilation and Air Conditioning Integrated Circuit International standard specifying the physical layer and medium access control for low rate wireless networks Internet Protocol IP Transport Layer Security The version of the Internet Protocol most widely used The most recent version of the Internet Protocols, which accommodates a greatly increased network address space To allow a smart Metering System to be used within market rules by the registered Supplier, its nominated agents and parties selected by the customer without necessitating a change of Metering System. Security of the smart Metering System infrastructure, with structured Access Control, is a key interoperability requirement. Industrial, Scientific, Medical – term describing unlicensed international radio frequency bands Means, in a smart metering context, the communications connection to the Metering System itself. This could be via cellular telephony from a mobile mast, or via electricity cables for power line carrier. Generally, the Last Mile has a meter at one end and a connection to the backhaul/data transport at the other, which could be in the form of a concentrator or other equipment. Communications between a Metering System and Local Devices within the premises in which the Metering System is

HomePlug HTOL HVAC IC IEEE 802.15.4 IP IP-TLS IPv4 IPv6 Interoperability

ISM ‘Last Mile’

Local Communications

Page 17 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Term Local Device Meaning installed.

Version 0_5

A Local Device can be any piece of equipment within premises that communicates directly with the Metering System using Local Communications. Line of Sight Media Address Control layer of OSI model (also known as the data link layer) Or Wireless MBus; A wireless communication standard using low power radio See detail in section 8. Or µC; Micro Controller Unit Is a networking topology where nodes are configured to act together to provide a greater coverage and increased redundancy A role within the energy industry, the exact meaning of which may differ slightly by fuel and governance context, generally meaning the organisation which owns and is responsible for the ongoing provision of the meter and holds a contract with the energy Supplier for that service A single device or meter, or a combination of devices used to deliver the Lowest Common Denominator as defined in the Smart Metering Operational Framework Schedule L ‘Smart Meter Functional Specification’. Classification of meter type under the Smart Metering Operational Framework. A ‘Standard’ variant is suitable for installation at the majority of meter points in Great Britain. Other variants exist to cover specific supply, circuit or customer issues at a site. Examples include Polyphase, Semi-Concealed or 5 Terminal variants. The full table of Meter Variants can be found in the SRSM document ‘Smart Meter Functional Specification’. A generic Smart Metering Operational Framework term referring to any person attending a metering point for the purposes of installation, maintenance, investigation, replacement or removal of the Metering System. Includes existing energy industry defined roles of Meter Operator, Meter Asset Maintainer, Meter Reader, Data Retriever etc. Multi Utility Controller – part of the German Open Metering System for smart metering National Institute of Standards and Technology US measurement standards laboratory Network Layer of the OSI Model Also OBIS-Code An interface class within the DLSM/COSEM object model Original Equipment Manufacturer

LOS MAC MBus

MCU Mesh network

Meter Asset Provider

Metering System

Meter Variant

Meter Worker

MUC NIST NWK OBIS OEM

Page 18 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Term OMS Meaning

Version 0_5

Open Metering System The German smart metering initiative that includes the definition of the MUC Offset Quadrature Phase Shift Keying A form of phase shift keying The European Union definition of an open standard (taken from “European Interoperability Framework for panEuropean eGovernment Services”) is: • The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.). • The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee. • The intellectual property - i.e. patents possibly present of (parts of) the standard is made irrevocably available on a royalty-free basis. There are no constraints on the re-use of the standard. Open Systems Interconnection – refers to the OSI Reference Model, an abstract description for layered communications and computer network protocol design. One Time Programmable Printed circuit board Personal digital assistant – a handheld computer Physical Layer of the OSI model Power-On Reset, a technique used to ensure that devices are in a known state when power is applied A meter manufacturer based in the UK Physical Service Data Unit, a term used in TCP/IP networking Phase Shift Keying A digital modulation scheme with a number of different types Pulse Width Modulation Reasonable and Non-Discriminatory Radio Frequency An algorithm for public key cryptography Received signal strength indication – a measurement of the power present in received radio signal In radio terms means receiving Supervisory Control and Data Acquisition, generally an industrial control system managed by a computer. System on Chip Serial Peripheral Interface Bus – a component in computing

OQPSK Open Standard

OSI Model

OTP PCB PDA PHY POR PRI PSDU PSK PWM RAND RF RSA RSSI RX SCADA SoC SPI

Page 19 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Term SRD SRSM Project Meaning systems that provides data links Short Range Device

Version 0_5

Supplier Requirements of Smart Metering project. Exercise in 2006-08 undertaken by ERA to develop the Smart Metering Operational Framework. Ongoing at the time of developing this document

Smart Metering Operational Framework Supplier TAHI TCP/IP

Smart Metering Operational Framework Proposals and Options Means an energy retail business The Application Home Initiative Transmission Control Protocol/Internet Protocol The Internet Protocol Suite – the communications protocols typically, but not exclusively, used for the internet Taiwan Semiconductor Manufacturing Company – a semiconductor fabricator In radio terms means transmitting Microcontroller unit – see MCU Universal asynchronous receiver/transmitter – a piece of computer hardware that translates data between parallel and serial forms Ultra High Frequency Radio Frequency Identification RFID systems which operate between 300MHz-3GHz Universal Serial Bus – a standard serial interface used in computing Communications between a Metering System and a remote Authorised Party A wireless communication standard using low power radio See detail in section 8. Trade name for wireless networking technology based on a range of IEEE 802.11 standards Web Services Description Language – a language used within interoperable machine to machine interactions over networks. A wireless communication standard using low power radio See detail in section 8. Part of the Z Wave protocols, offering TCP/IP connectivity to Z Wave devices ZigBee Smart Energy – an application profile of the ZigBee standard A wireless communication standard using low power radio See detail in section 8. Table 2 Glossary

TSMC TX µC UART

UHF RFID USB WAN (Wide Area Network) Communications Wavenis Wi-Fi WSDL

ZigBee Z/IP ZSE Z Wave

Page 20 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

4

Local Communications Context

This section of the document presents an overview of the Local Communications Development work and a number of topics and issues for consideration.

4.1 General Context
It is a clear requirement of the Smart Metering Operational Framework to implement Local Communications capability for smart Metering Systems. Interoperable Local Communications capability will enable customers and Suppliers to make choices in relation to how energy consumption information is displayed. It also supports flexibility in the options for delivering smart Metering Systems solutions and potential ‘smart home’ applications. Throughout this document applications involving water meters, TV displays and other ‘non-energy’ applications are used to illustrate the potential of smart metering to support a range of known and as yet unknown applications. However the Local Communications solution must, first and foremost, meet the energy requirements. Smart meters are not intended to be a fully functional alternative to other residential gateway or ‘home hub’ products – these products tend to be capable of handling voice and multimedia applications that would add significantly to the cost of utility meters. Figure 3 below shows the SRSM project representation of the operational architecture for smart metering and therefore the scope of the Smart Metering Operational Framework – this document specifically relates to the ‘Local Comms’ section on the left hand side of the diagram.

Industry Interfaces

Figure 3: SRSM Smart Metering Operational Framework Scope

Data Transport (internet)

Page 21 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

4.2 Smart Utility Context for Local Communications
The general perception of Local Communications for smart metering is between a smart electricity meter and a display device. This has been the typical approach in other smart metering initiatives, usually on a proprietary basis, where the meter manufacturer provides the display device alongside the meter for electricity only. The manufacturer decides upon the communications medium, the protocols and data formats used. This ‘one size fits all’ solution means that all customers get the same solution that works straight out of the box, usually an LCD device that is portable or fixed in a more accessible location than the meter itself. However, having such a ‘closed loop’ offering for the display of consumption information raises a number of issues: • Restricting the opportunities for Suppliers to differentiate display products in a competitive retail market. • Variances in the quality and functionality of offerings from meter manufacturers. • Customers cannot choose how energy consumption information is displayed to them. • Innovation in display device technology would be controlled by meter manufacturers or Meter Asset Providers. • There could be limited support for future demand management and demand response requirements. Access to the information from the smart meter is under the control of the proprietary solution from the meter manufacturer. • In order to provide a ‘total utility’ solution, the display device must communicate successfully with the gas and water meters – further compounding the potential single source/proprietary solution issue. These issues could be addressed through specification, i.e. requiring that protocols are open, or available, introducing flexibility and innovation for display devices. Shown in Figure 4 below is a representation of the basic utility requirements for Local Communications for smart metering. The solid red lines indicate the core energy metering requirement of a display of information from gas and electricity information. The dotted blue lines illustrate potential other uses of the Local Communications solution.

Page 22 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Figure 4: Smart Utility Context

In this example, a water meter is included to illustrate the potential for an extended network, however water metering does not form part of the Smart Metering Operational Framework at present and is included purely to illustrate how a utility context could operate. As shown, the gas, electricity and water meters can communicate with a display device. Further, the gas and water meters may use the same communications medium to interact with the electricity meter, which could act as a ‘hub’ for WAN communications for all utilities.

4.3 Smarter Display Options Using Local Communications
Building upon Figure 4, it is a requirement of the Smart Metering Operational Framework to support customer and supplier choice in the display of energy (and potentially water) consumption information from smart meters. Smart meters should allow customers to access information using a number of different display devices, as shown in Figure 5 below. The original ‘LCD device in Kitchen’ solution remains, but is supplemented or replaced by options using personal computers, white goods, cellular telephones etc. The success of smart metering in raising awareness of energy consumption, and actually changing customer behaviour, will depend upon making the information available in a way that is most relevant to individual customers. Page 23 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Figure 5: Smart Display Context

The step from the illustration of a smart utility context to a smarter display context is one of interoperability. As long as the energy smart meters all communicate using the same technology, protocols and a standard data format, it will be possible for display functionality to be added to a number of differing delivery devices. An example could be the use of a USB dongle (and software) for a PC allowing a customer to access sophisticated energy management information from their utility meters. Currently this type of solution is being offered to commercial customers through a wide range of proprietary offerings. A number of display applications may rely upon a service provider external to the home – e.g. an energy management website that a customer logs on to, or a specific TV channel. In these types of application, data from smart meters is processed and formatted by an external party before being presented back to the customer. As these types of display services include a remote service provider, they are not within the scope of the Local Communications work. If smart meters operated on an interoperable open standard for Local Communications then this level of energy management could be available to a much wider range of customers. In this environment, Local Devices can interoperate independent of the Metering System. For example, the water meter could prompt the customer to call the water utility using a display device. Page 24 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

4.4 Smart Home Context
Establishing an interoperable solution for Local Communications, as required to support customer choice for the display of consumption information, opens up a range of opportunities for energy related Local Communications. As shown in Figure 6, a number of ‘green’ and other applications could be supported by ‘or interact with’ smart meters. These types of automated home technologies are now being installed, and could become more prevalent if they were capable of responding to utility price triggers from smart meters, or could utilise the WAN communications functionality that smart meters will introduce to every home.

Figure 6: Smart Home Context

Figure 7 below presents the smart home context for the smart metering Local Communications solution(s).

Page 25 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Microgeneration ‘Cluster’

Version 0_5

Sensor ‘Cluster’

Display Device ‘Cluster’

Utility Meters

White Goods/Demand Response ‘Cluster’

It is not a requirement of the SRSM Project for smart meters to act as a (or ‘the’) gateway for all of the devices shown in the clusters. A further suggested use context for Local Communications would be where a meter (or collection of meters) forms part of a SCADA network of devices managed by a remote system. The opportunity to offer services that utilise the WAN communications link within a smart meter is a product of establishing an interoperable platform for Local Communications for smart metering. Figure 8 shows how the Local Communications Solution could be utilised to deliver a platform to serve both the smart metering activities of energy Suppliers and the requirements of 3rd parties to access the HAN and Local Devices.

Figure 7: Smart Home Context & Clusters

Page 26 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Customer HAN

Suppliers can also communicate with Customer HAN devices

Alongside price and consumption information, the utility context would include detail of smart meter events and control of smart metering functionality

Utility Devices

HAN Radio

WAN Comms

HAN interactions with nonutility devices uses same HAN radio, but is less critical – restricted to price/ tariff and consumption information from the meter

All remote communications with smart meters are over the secure WAN connection

3rd Parties All communications, WAN and HAN are 2-way and encrypted

Suppliers

Figure 8 Different Uses of Local Communications

Page 27 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

5

Associated Topics

This section of the document includes further information to assist with setting the requirements, solutions and evaluation into a specific GB smart metering context.

5.1 A National Standard
Due to the fundamental differences between the technologies and systems that may be used for Local and WAN Communications activities, fully end to end interoperability across the scope of smart metering might not be appropriate due to the onerous processing and protocol requirements this could place on simple local devices. However, in order to ensure that smart metering creates an effective platform for the types of applications presented in section 4 above, it is believed that a national standard for Local Communications is required. The details of such a standard (approvals, certifications, standardised markings) remain to be considered and will form part of the recommendation of this report. This would mean that all smart Metering Systems would include hardware and software capable of meeting the Local Communications standard. This does not necessarily mean the same chip/hardware in every meter, but would mean conformity in their capability. It is a clear principle of the Local Communications Development workstream that it would not be acceptable for non-interoperable Local Communications solutions to be associated with smart metering – a customer with a range of ‘Smart Energy’ compliant products should be able to transfer these products reasonably seamlessly when they move home, where the smart metering may be different.

5.2 Security
Due to the nature of data and functionality that will be accessible via Local Communications, security is a paramount concern. Consumption and other data from a smart meter may not initially be considered as confidential – energy tariffs are publicly available, meter readings on their own are not personal data or at risk of increasing identity theft. 2 However, debit balances sent from a meter to a display device could be considered by many customers to be personal and private. Further, consumption patterns based on interval data could allow third parties to establish patterns of occupancy, which would very much be viewed as personal data.

The SRSM project is considering the issues surrounding ownership of smart metering data within a separate workstream; therefore they will not be covered within this document.

2

Page 28 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Added to this the ability to operate metering functionality using Local Communications, e.g. a meter worker configuring a meter at installation, increases the risk of misuse or fraud by customers or third parties. It is accepted that no solution can be completely secure and resist all attempts to intercept or interfere, but the Local Communications Solution should be capable of addressing known security attacks – replay, man-in-the-middle, delay, spoofing, sequence change and deletion. The Local Communications Solution should also be future flexible, allowing for firmware/software upgrades to improve security.

5.3 Delivering the Last Mile
For certain topographies it may be possible for the Local Communications hardware within smart meters to provide the ‘Last Mile’ physical media for WAN Communications. This would typically be for high density and metropolitan areas where the signal propagation and power consumption restrictions of low power radio solutions are less of an issue. The SRSM project has considered the potential to use low power radio to deliver the last mile, as shown in the diagram below. This also demonstrates a number of options for backhaul for WAN Communications, which is out of scope for the Local Communications Development work.
Metering System Options Substation
Low Power Radio

Low Power RF to Elec

PLC Infrastructure

High Speed Link (Copper/Fibre)

Low Power RF Type

Data TransConcentrator former Supplier A

Cellular Infrastructure

A number of RF solutions include the capability to create ‘Mesh’ networks, where a large number of nodes can be crossed to reach the concentrator.

Data Transport (internet)

Data Concentrator Low Power RF Type
Existing telephony network

Data Concentrator

Supplier X

Data concentrators could be installed and managed by a service provider making use of the existing telephony network. The equipment could be housed in telephony street furniture, or any appropriate location, including potentially within customer premises in the form of ‘Concentrator Meters’. Data concentrators could be provided as part of the infrastructure service, or as a separate contracted function.

Figure 9: Local Communications for the Last Mile

There is no assumption that there is necessarily the same hardware within a meter for Local Communications and WAN Communications – theoretically two low power radio chips could be used, possibly at different frequencies. An example would be a meter that uses a ZigBee chip at 868MHz for Local Communications and a WiFi chip at 2.4GHz for WAN Communications. Page 29 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

5.4 Local Device Classification
A topic for potential consideration is the classification of Local Devices. As smart meters are required to be capable of 2 way communication, and energy suppliers expect display devices to be similarly capable of 2 way communication, the Local Communications solution(s) need(s) to accommodate fully functional ‘nodes’ on a network. There will be, however, local devices that will only send or receive data. Examples could include: - a fridge magnet to display consumption cost information would only receive data - a temperature sensor would only send data These types of devices could be classified, for the purposes of smart metering Local Communications, as distinct groups. The Local Communications solution could recognise the classification of local devices in order to determine the data exchange types, access control details and network addressing/protocols. Finally, there may be devices capable of sending and receiving data, but that would not act as network repeaters in a number of topologies. In v1 of the Smart Metering Operational Framework, the following categories of local device are proposed: - Data Device: a device which requires access to smart meter data only - Communicating Device: a device which requires access to remote party only - Fully Functional Device: a device requiring access to the smart meter data, and remote parties, and that could also operate smart meter functionality – an example of this could be a diagnostic or commissioning device to be used by a meter worker Additionally, it has been suggested that Hand Held Units, as may be used by Meter Workers, could form a category of their own. Investigation is needed to understand whether there is a requirement for classification of local devices, and if so, what are the recommended classifications and how they can be documented. It should be noted that a number of the solution options provide for device classification within their profile regimes.

5.5 Processes/Activities Required
In order to document and evaluate the potential Local Communication solutions, understanding how those solutions will be used is important. This will also assist with understanding the controls and commands that will be required within the metering system to authorize/manage which local devices can undertake which activities.

Page 30 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Within the Smart Metering Operational Framework, the SRSM project listed a number of processes/activities that could be expected from a local device (bearing in mind that all smart meters are themselves local devices): - establish pairing/join network - remove pairing/leave network - receive data from smart meter (passive local device) - access data from smart meter (active local device) - update data on smart meter - operate smart meter functionality - send data to remote party via smart meter - receive data from remote party via smart meter - send data to local device via smart meter - receive data from local device via smart meter - send data to local device directly - receive data from local device directly Again, a number of the solutions under consideration address the processing/activities on the network using their own profiles and protocols.

5.6 Types of Data
From the information presented above, it is possible to infer some general guidelines on the type of data that will be transferred using the Local Communications Solution: - energy consumption data - energy tariff data - energy local device - microgeneration data and commands - meter functionality commands - load control commands - local device data (sensor information, appliance diagnostics etc.) - local device commands – similar to load control – remote ‘soft’ boots, resetting clocks etc. - metering system or local device firmware/software This information is presented for guidance only – the potential applications of Local Communications and HAN activities are almost limitless. It remains the case that the primary requirement is to deliver the data and control facilities for energy smart metering, and that data exchanges will be comparatively small and non-critical. Another issue associated with data will be the end to end format – it is not anticipated that enterprise applications will use the Local Communications data format – therefore some system within the network is expected to act as a gateway, translating Local Communications data exchanges into format that can eventually be read by Authorised Party applications. The illustration below is taken from a consideration of technical interoperability prepared by the SRSM project, it shows how gateways and protocols could be used in a WAN context to deliver standardised interoperability.

Page 31 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Meter with WAN Hardware

Version 0_5

Sta n Pro dard t o co l

Standard Head End

Gateway

Enterprise Applications

Supplier IT Architecture

Figure 10 Technical WAN Interoperability

5.7 Independent & Private Local Networks
A large proportion of British domestic premises are in areas of dense population, with many homes being very close, if not connected, to each other. Where low power radio technologies are powerful enough to reach all parts of a home, they must essentially be powerful enough to reach neighbouring premises. This section of the document explores this subject in more detail. Shown below is a simple illustration of typical utility applications for Local Communications in two neighbouring properties.

Figure 11: Simple Collection of Smart Meters and Local Devices

The house on the left has a gas meter in an external meter cupboard, a water meter fitted at the boundary point, and has a TV capable of displaying smart metering information.

Page 32 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

The house on the right differs in that there is no water meter, the gas meter is located at the rear of the house and the preferred display solution is a portable LCD display, usually kept in the kitchen. The illustration below shows the required links between devices.

Figure 12: Independent Networks

The topology of the network within premises does not need to be specified, as these could vary significantly by property type. However, in order to deliver the necessary signal propagation to link the electricity meter to the gas meter in the blue house, the range of Local Communications of the electricity meter could be as shown in Figure 13 below.

Page 33 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Figure 13: Local Communication Signal Range

This simple illustration, without allowing for signal drop off as it passes through walls, shows how all of the devices in the left hand house are within reach of the electricity meter in the right hand house. It is a requirement for the information from one customer’s metering not to be visible on their neighbour’s display. The illustration below shows how much overlap there will be between signals for this simple configuration of smart meters and devices. The TV display in the left hand house is in range of all four energy smart meters. In reality, the range of the wireless signals is likely to be much greater than shown.

Figure 14: Overlapping Wireless Ranges

Page 34 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

The requirement is for the Local Communications solution to deliver a network of Local Devices for each property. It is not practical (or possible) to restrict a wireless signal from each meter to the boundaries of each premises.

Figure 15: Required Local Communications Range Example

Finally, there are circumstances where the wireless signal could be required to transfer data between properties. The illustration below shows where communication between meters in different properties would be a desirable feature for Local Communications. It is a very simple depiction of meters forming a mesh network to reach a data concentrator in a substation. Whilst this is effectively the WAN Communications network, it utilises the Local Communications hardware in smart meters.

Page 35 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Figure 16: Mesh Network to Concentrator

5.8 Distinguising Local Communications from the HAN
An issue discussed by the group, and reflected in the principles P.3 and issue I.3, relates to the ‘ownership’ and control of the network created or joined by smart Metering Systems. From a network architecture perspective, there are a number of options as to how to ensure that energy utility operations (e.g. between meters, or to microgeneration devices) are under the control of the relevant Authorised Party, whilst maintaining the flexibility to allow customers to add their own Local Devices. For example, there may be the following ‘Logical’ networks in a home: • Electricity smart meter to display and other devices included in electricity supply contract from energy retailer A • Gas smart meter to same (or different) display and other devices included in gas supply contract from energy retailer A or B • Customers’ own HAN, potentially including the display(s) and the meters • Any other services that make use of the electricity smart meter as a gateway – for example a water meter The electricity smart meter could be expected to be a part of all of these networks in one role or other, as shown in the figure below.

Page 36 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Gas Supplier Electricity Supplier Water Utility

Version 0_5

Meter Worker WA TER ‘ Ne t w o r k ’
AN Pr o

W

xy

ELECTRI CI TY ‘ NETWO RK’

Cu s t o m e r HA N
Customer

Figure 17 Possible Logical Networks

All of these distinct ‘Logical’ networks may have different conditions for security, key management and for joining. This is not an uncommon situation in networking, and there are a range of approaches to managing it, however, until the specific requirements are clearer (electricity meters may not end up being gateways), understanding which approach to managing it remains unclear. An example of an approach used in a smart electricity metering context can be seen in the OpenHAN requirements from the United States. In this instance, the ‘Utility’ operations are on a secured interface and any HAN activity is restricted to price and ‘event’ information on a public broadcast channel, as illustrated below.

Figure 18 OpenHAN Interfaces

Page 37 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

This approach would not comply with the GB requirements for 2 way Local Communications, in that the public broadcast channel is one way only. A further consideration would be the use of the Local Communications solution for the Last Mile, which could add another network to the requirements. A paper on this subject has been written by a group member and is included in the references section below.

5.9 Wireless to Wired Options
A standard/solution that includes a wired option for Local Communications as well as a wireless option could be beneficial to link to existing and new wired devices and networks. A number of appliances and networks will already exist in premises where smart meters are installed. Each of these systems will be operating using their own protocols and data formats, and not necessarily interoperating. There may also be network capable appliances that are not yet part of any network. Examples could include white goods capable of communicating using CECED standards, but no wireless hardware. It is not an ambition for smart meters to directly interact with all of these systems, as this would introduce complexity and cost into the meters themselves. Other ‘smart metering’ implementations do include wired Local Communications, typically in Northern Europe. Typically these use the M Bus protocol over a low voltage (less than 30v) wire within meter rooms for multiunit buildings where the location of the gas, electricity, water and heat meters makes wired solutions far simpler to implement. As detailed in F.1 in section 7.2 below, there are localised regulations within the UK that appear to rule out this option for gas metering. However, it would be beneficial for a number of ‘non-utility’ systems to interact with smart meters: • to receive pricing and tariff information • to respond to load control/demand management instructions • to display energy related information • to utilise the WAN connection of the meters to send or receive information to and from remote parties Some customers may already own and use equipment theoretically capable of providing a bridge between wireless and wired communications media, and which could include the necessary software to make data and services interoperable between distinct networks and systems. The obvious example is a home PC, but broadband routers, set top boxes and games consoles already include most of the technology to provide a link between smart meters and existing wired and wireless networks. As previously stated, it is an absolute requirement for smart metering that it will not be subject to customer equipment and decisions in order to deliver the utility requirements of intra meter and energy information display processes. Page 38 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

It would not be reasonable to assume that every home would be equipped with a BT Home Hub, Sky box, Xbox 360 or similar ‘bridge’ capable equipment, but for those that do then smart meters could form part of the overall connected home. Energy suppliers could choose to provide ‘bridge’ equipment to customers as part of an overall energy services package. An alternative approach would be to implement a Local Communications Solution using a protocol along the lines of 6LowPan, which extends IP addressing to every node in the network, dispensing with the need for HAN controllers and specific protocols for the Local Communications. However, 6LowPan remains an immature protocol and is not currently supported by the solution options considered below.

5.9.1 Wired/Wireless Protocol Development
During the activity of the Local Communications Development workstream work has commenced on delivering a specification combining ZigBee and HomePlug. It is intended to deliver a technical solution to practical issues raised by the Victorian AMI initiative in Australia, where electricity meters in meter rooms are too remote from dwelling units in high rise blocks for low power radio to operate effectively. The proposed solution would allow either a wired (electricity mains cable) or wireless (IEEE 802.15.4 radio) physical layer for the ZigBee smart energy profile. The work is anticipated to deliver specifications in the second half of 2009.

5.10 British Housing Types
One of the key challenges facing any wireless solution will be type of premises it will be used in. There is a comprehensive range of construction materials that will all have a direct bearing on the signal propagation properties of a Local Communications Solution. The issue is compounded by a variety of physical energy supply conditions that can be site or customer specific. There has been little standardisation of the exact positioning of where the meter is located. Meter location, which is usually an ‘out of sight, out of mind’ consideration, and could be anywhere within or outside premises (or another premises for multi-occupancy premises with meter rooms), will introduce a range of challenges for communications solutions. Metal meter cabinets could also adversely impact wireless signals – creating Faraday Cages - a situation that is apparent from ongoing technology trials by the energy Suppliers. Although not a core requirement of the SRSM project, it must also be noted that the installed base of water meters in Britain can also be in a tricky location for low power radio signals. A significant proportion of water meters are Page 39 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

installed in boundary boxes at the edge of a customer’s land. Similarly the use of pits for water meters will have an effect on signal propagation. The figures presented below show that the particular challenges associated with flats, where the energy consumption could be significantly ‘remote’ from the energy meter, do not represent a minority concern.

5.10.1 Houses By Type
The ‘types’ of houses are defined differently by the Government housing condition statistics in England, Scotland and Wales. English Data: Dwelling Type Small Terraced House Medium/Large Terraced House Semi-Detached House Detached House Bungalow Converted Flat Purpose Built Low Rise Flat3 Purpose Built High Rise Flat Total Scottish Data: Dwelling Type Detached Semi-Detached Terrace Tenement 4-in-a-block Tower/Slab Flat in conversion Total Welsh Data: Dwelling Type Detached Semi-Detached Terrace Flats Total 000’s 2,665 3,634 5,897 3,753 2,028 716 2,783 305 21,781 % 12 17 27 17 9 3 13 1 100

Table 3 Stock Profile - English House Condition Survey 2005

Table 4 Type of Dwelling - Scottish House Condition Survey 2004/5

000’s 472 501 522 449 251 71 36 2,301

% 20 22 23 20 11 3 2 100

Table 5 1998 Welsh House Condition Survey

000’s 264 387 405 101 1,157

% 23 33 35 9 100

3

Defined as: ‘a flat in a purpose built block less than 6 storeys high. Includes cases where there is only one flat with independent access in a building which is also used for nondomestic purposes’. High Rise therefore being blocks over 6 storeys high.

Page 40 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Assuming that flats are the dwelling types that could present signal propagation issues for wireless solutions, these are highlighted in blue in the tables above and collated to provide the overall ‘British’ position shown below. Dwelling Type Detached Semi-Detached Terrace Bungalow Flats Total 000’s 4,489 6,785 7,226 2,028 4,712 25,240 % 18 27 29 8 19 100

Table 6 'Overall' British Housing Type Volumes

5.11 Support for Third Party Applications
As discussed in a number of sections of this document, there is potential for the smart metering infrastructure to be utilised for a range of applications with similar communications requirements. Suggested examples of services that require similar low bandwidth, secure communications include boiler and appliance diagnostics, water metering and telecare/healthcare. Devices for these services could be designed to form part of the network supported by smart meters, using the same communications technologies and protocols. Water metering is an obvious consideration, potentially offering a fixed network using the ubiquity of electricity metering as a gateway – it is seen by some as cheaper and greener than building a new fixed network for water metering, or continuing to invest in ‘walk-by’ and ‘drive-by’ AMR solutions. However, it would be difficult to select and develop a technical solution that addressed the requirements of a range of as yet unknown third party services – water meters in particular present signal range and propagation challenges. It has been the view of the ERA members that developing a platform that works well for smart metering would allow third parties to consider it as an option for their services once it has been established. Equally, principle P.1 applies – the focus for energy smart metering remains the successful implementation of gas and electricity smart metering. It is obvious that the smart metering communications infrastructure could be attractive to other parties, and the technologies discussed in this report would support their requirements. Commercial arrangements relating to fair usage and payment for bandwidth could be negotiated on a bilateral or multilateral basis, or form part of a defined additional service required by an energy Supplier’s licence – this could be considered by any detailed work on smart metering by the Government. At the same time, other communications gateway options for homes are being considered – e.g. Active Line Access – that may be more suitable or attractive to third party solutions.

Page 41 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

This area, whilst offering tremendous opportunities, is also possibly extremely complicated.

Page 42 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

6

Principles & Assumptions

6.1 Local Communications Principles
From the detail presented above, and from associated smart metering work, it is possible to infer a number of key principles that apply to Local Communications for smart metering:
No P.1 Principle Utility focus – the key requirement remains the communication between smart meters and energy information display/control devices. Support for other services and applications will be as a result of developing a practical solution to the utility requirement. The utility focus should necessarily result in a low bandwidth platform – energy consumption and tariff data and control commands do not require high data throughput rates. The smart Metering Systems themselves will be responsibility of the energy Supplier. The Home Area Network may be owned by the customer. This allows them to add or remove any Local Devices. The Local Communications solution will be interoperable – supporting a range of metering products and local device applications. The Local Communications solution will make use, wherever practical, of open standards and architecture. The intention is to adopt (and potentially develop) an existing solution for Local Communications rather than develop a new one. This includes the protocol and data definition. The Local Communications baseline solution will be the same in all energy smart meters – establishing a national specification. The Local Communications solution will be energy efficient. The Local Communications solution will be secure, as described in the requirements below. Additional security measures may be implemented by the Metering System and the application software. The Local Communications solution will be secure in the context of providing networked communications using low power radio (or similar) and ongoing technological developments in security. The Local Communications solution shall, as far as possible, be future flexible – supporting innovation at the same time as supporting legacy systems. Table 7 Local Communications Principles

P.2

P.3

P.4 P.5 P.6

P.7 P.8 P.9

P.10

6.2 Local Communications Assumptions
Based on the context discussions above, and on discussions within the group, the following assumptions apply to the requirements, solutions and evaluation presented below:
No A.1 Assumption The Local Communications Solution will be compliant with relevant legislation and regulations

Page 43 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
No A.2 A.3 A.4 Assumption

Version 0_5

Smart meter functionality is broadly equivalent to the SRSM Smart Meter Specification.4 SRSM Smart Meters are expected to have an asset life of 10-15 years or better. Smart metering will be ‘utility robust’. This means that for the purposes of delivering utility services to a customer it will not be reliant upon, or affected by, devices owned by a customer or other 3rd party. Table 8 Local Communications Assumptions

4

This should be consistent with the latest agreed version of the SRSM specification, at the time of concluding this report this is v1.1 of the Smart Meter Specification.

Page 44 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

7

Requirements

The requirements shown below are the result of iterative development by the Local Communications Development Group. The starting requirements for the group were taken from the Supplier requirements published in the ERA Smart Metering Operational Framework Proposals and Options v1, dated August 2007. The requirements have been developed with the participation of parties other than energy retailers – meter manufacturers, network operators, meter operators and display and device manufacturers are all parties to the Local Communications Development Group. There are no specific requirements for any single group, as the Local Communications Solution should meet the overall requirements of those parties with an interest in the development of smart metering. Therefore there is no specific requirement to address a network operators specific use case of load and device control – this should be addressed by the general requirements below.

7.1 Requirements
The requirements below are grouped by topic
Ref GEN.1 Requirement General The Local Communications Solution must provide for data exchange between smart meters and local devices The maximum requirement is for intermittent communication between a Metering System and a Local Device at a configurable time granularity that can be measured in seconds. Notes

GEN.2

The Local Communications Solution must be interoperable, allowing smart meters and local devices from a range of manufacturers to exchange data using a defined data standard. The Local Communications Solution shall not critically affect the power consumption/battery life of a smart Metering System The Local Communications Solution shall operate throughout the life of the installed smart Metering System – it will be capable of remote upgrade and those upgrades shall be backwards compatible Communication The Local Communications Solution must be able to operate effectively in the majority of British domestic premises without the need for additional equipment Note that domestic sized smart meters could be used in nondomestic premises. Note that there may be

GEN.3

GEN.4

COM.1

Page 45 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Requirement

Version 0_5

Notes additional equipment for specific property types

COM.2

The Local Communications Solution shall have the ability to automatically adapt to communications interference through detection and analysis of environmental conditions (e.g. channel hopping, channel avoidance, signal to noise ratio) The Local Communications Solution shall provide an option to deliver WAN communication information during a site visit from a Meter Worker with a suitably secure Hand Held Unit. In this instance, if the WAN communications is not available, it will be possible to exchange information (meter readings, tariff settings etc.) through the use of a Hand Held Unit. This failsafe/fallback facility could include the exchange of information with Metering Systems using Local Communications during a site visit or also for a ‘drive by’ or ‘walk by’ activity. Security The Local Communications Solution must support data security measures to prevent unauthorised access to/use of smart metering data or functionality, and to prevent unauthorised access to/use of Local Device data or functionality. Includes situations where nodes pass data but cannot access the content. An example would be where an electricity meter passes data to a display device from a gas meter – the electricity meter should not be able to access the content of the gas data

COM.3

SEC.1

SEC.2

The Local Communications Solution shall support security measures that employ cryptographic operations and cryptographic keys Data The Local Communications Solution shall support a defined data definition standard or profile Network The Local Communications Solution shall ensure that all Local Devices are required to join the network to access meter data and functionality ‘Joining’ the network should involve some process whereby permission is granted – either by the customer, the energy Supplier or automatically through the use of configurable security settings

DAT.1

NET.1

NET.2

The Local Communications Solution

Page 46 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Requirement shall be able to support multiple Local Devices within a Home Area Network The Local Communications Solution shall use the clock and timing information provided by smart Metering Systems to set the time on the network it administers Installation & Maintenance MOP.1 The Local Communication Solution must not add significant time to the installation of smart meters or local devices for network configuration or pairing activities Customer Requirements CUS.1 The Local Communications Solution shall not affect or cause interference to existing customer networks The Local Communications Solution, where it requires customer activity, shall be simple to operate. The Local Communications solution(s) will place minimal requirements on customers for day to day operation. Notes

Version 0_5

NET.3

Or, Network Time Synchronisation

CUS.2

For example, where a customer wants to pair a new Local Device

CUS.3

For example, beyond confirming connection or removal of Local Devices, the customer will not be expected to take action to re-establish communications following any failure. Table 9 Local Communications Requirements

7.2 Requirements Notes
A number of factors relating to Local Communications Solution requirements are not explicit within the requirements shown above. These factors are presented below. These factors are relevant for the evaluation of solution options.
Ref F.1 Factor Power within Gas Meters There have been a number of questions about the possibility of avoiding battery issues within smart gas meters by using wired power. This would allow for consideration of a wider range of solutions for Local (and WAN) communications. A number of gas appliances already include gas and electricity components. Some European smart meter installations use low power (30v) wired connections to link gas, water, heat and electricity meters for communications purposes. There are key regulations and standards relating to gas meters and

Page 47 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Factor potential explosive atmospheres (ATEX).

Version 0_5

Products are available to introduce two way communications for gas meters that do not compromise the safety of the meters, or introduce battery life issues. The fundamental design of a gas meter as mechanical or electronic will also be a factor in how much power it consumes. Whilst possible (see standard below), gas meters that meet the safety requirements to support electrical connections are viewed as too expensive for consideration for mass market deployment. A particular issue for GB gas metering is the extensive use of meter boxes, which would require modification to meet ATEX requirements. The Institution of Gas Engineers and Managers, at the time of preparing this document, is consulting upon the 3rd Edition of its’ standard entitled ‘Electrical connections and hazardous area classification for gas metering equipment’. F.2 Visiting Smart Meters A key benefit of smart meters will be a reduction in the number and therefore cost of field visits to read and maintain the meter. However, there is no requirement that smart meters should result in an end to all visits. It is assumed that the Local Communications solution will support ‘Over the Air’ upgrades that may be required for Local Devices, which could include the firmware within a gas meter, and not just for the solution itself. e.g. Customers who use debit functionality extensively (daily or more than daily) could require replacement batteries within the expected smart meter asset life. This would apply to above average usage of any functionality that would reduce battery life. Battery Life Considerations The Local Communications Development Group has discussed at length the options for ensuring a reasonable balance is struck between battery life/cost/customer feedback. It is accepted that a gas meter cannot provide continuous communications without a large and expensive battery in order to meet the requirement for 10 years plus of operation. At the same time, the immediacy of feedback to a customer display device will be critical in assisting customers with managing their energy consumption. It is suggested that application software could manage the duty cycle in gas meters to optimise battery life: - waking up to transmit/receive information for Xms every 5 minutes or 30 minutes (with suitable information about delays made available to customers) - customer override option, allowing them to refresh the information display by pushing a button on the meter to ‘wake’ it up (similar to the debit ‘refresh’ discussed below)

F.3

Page 48 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref

Version 0_5

Factor - waking up more frequently when credit levels (in debit mode) are below a configurable threshold, to ensure that credit purchase messages are picked up quickly (or the customer could be prompted to press a button to receive a ‘refresh’ of balances) - where the gas supply has been disabled, remain dormant until the customer pushes a button on the meter to reinstate gas supply (as required by the SRSM meter specification)
Table 10 Local Communications Requirements Notes

7.3 Potential Additional Requirements
Requirements could also be derived to support the use of Local Communications hardware to deliver the ‘Last Mile’ link for WAN Communications. Specific requirements for the smart metering system may also arise from the Local Communications solution where a meter may be required to store data for onward periodic transmission. Examples could include services configured to transmit gas meter data on a daily basis via the electricity meter, or an annual boiler diagnostic report.

Page 49 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

8

Solution Options

This section of the document presents a number of solution options for the hardware to be included as part of a smart metering system. It uses a standard template to capture detail relating to each of the options. This template is presented below with a description of the type of information to be captured. A number of solution options support more than one network protocol, or are offered by vendors at different frequencies. Therefore there is not always a one to one relationship between the silicon, the frequency, the protocol and the data set supported. In order to ensure that all potential considerations and aspects of a solution are included in this document, details are recorded for all candidate solutions in the market that it was possible to document.
Solution Description: Hardware: Cost: Data: Power: Name Website

A description of the solution A description of the physical hardware used by the solution – microcontroller, antenna etc. Where available, a general view of the cost of the solution on a per meter basis Speed of data transfer, any limits on packet sizes Points relevant to the power usage of the solution when it is operating or dormant, and how this may effect the power consumption of the meter or local devices. Which of the frequencies (if applicable) does the solution support Does the solution support a variety of protocols? Does it use a proprietary protocol, or place requirements/restrictions on the protocol? Does the solution support a variety of data formats? Does it use a proprietary format, or place requirements/restrictions on the data format? Is the solution used for other purposes, i.e. not for smart metering, but for building controls, telecare, entertainment etc. Has the solution been used in a smart metering context in other markets? Can include where the solution is being considered by other smart metering initiatives. Is the solution available today? If not, when will it be available? Capability of the solution to provide ‘last mile’ coverage for WAN Communications Points supporting the solution in a smart metering context Issues associated with the solution in a smart metering context Any other notes, web links to relevant materials etc. Date, Version and Provider of information used to populate the table

Frequencies: Protocols:

Data Exchange Format: Use in other applications: Use in other markets: Maturity: Support for ‘Last Mile’: For: Against: Notes: Reference

Page 50 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Table 11 Solution Options Guide

Version 0_5

8.1 Solution Options Descriptions
Solutions are presented in alphabetical order.
Solution Description: Bluetooth low energy www.bluetooth.org Formerly known as Wibree and Bluetooth Ultra Low Power, this new solution option is primarily aimed at enabling small devices and sensors to communicate with a hub. The initial applications being considered include fitness and health, using a watch or mobile phone to act as a hub of a Body Area Network. The standard is expected to be finalised and formally adopted by the Bluetooth SIG by Q2 2009. Hardware: There will be standalone and dual mode Bluetooth low energy chipsets, operating the low energy protocol stack or low energy and classic stacks. Standalone will be type installed in small end nodes, such as watches and sensors. <$1 for single mode chips, $1.50 for dual mode chips Approximately 200 kb/s Listens and transmits for 0.01% of time (compared to 1% listen cycle for Bluetooth classic) Advertises – 2ms Connect request – 1ms Send application data – 3ms Operates at 2.4GHz using 40 channels (3 advertising, 37 data). 2 MHz channel spacing 0.5 modulation index GMSK (GFSK) Link Layer protocol manages connections and device discovery. L2CAP is a standard protocol for Bluetooth used as a multiplexor. Attribute Protocol used to transmit “attribute” values between devices. Has a single protocol that features 2 profiles for use – a remote display profile and a sensor profile ‘Classic’ Bluetooth is ubiquitous in mobile telephony and portable computing – over 2.5 billion enabled devices sold. 1 billion devices a year and growing. As an immature product, there are no uses of Bluetooth low energy in a smart metering context. Industrial automation using Bluetooth is a 15 million chip a year market today and growing fast. Understood to be still under development. Reuses existing protocol layers that have been proven interoperable and robust for over 8 years. Due to the relatively short range, it is not anticipated that Bluetooth low energy be suitable for WAN Last Mile Enables cellular phones to talk with meters, allowing direct billing and viewing of usage information from portable devices. No products available today

Cost: Data: Power:

Frequencies:

Protocols:

Data Exchange Format: Use in other applications: Use in other markets: Maturity:

Support for ‘Last Mile’: For: Against:

Page 51 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Notes:

Version 0_5

‘Classic’ Bluetooth radios, depending on the silicon provider, may already be in a position to support ‘Dual Mode’ operations. However, this will not be the case for all existing Bluetooth chips. Specifically designed to do point-to-point connections well – does not support mesh networking.

Reference:

V0.6 by Robin Heydon from Cambridge Silicon Radio Table 12 Bluetooth low energy M Bus www.m-bus.com

Solution Description:

Solution developed in Germany to support domestic utility metering. Supports twisted pair and wireless. Used widely throughout mainland Europe and supported by all major meter manufacturers. Standard available as EN 13757 Radio chipset, with embedded protocol stack Same as other 868Mhz radios i.e., approx €3.5 (for bidirectional solution) Wireless M-Bus speed at 868MHz (66kBps/16kBps) Wired M-Bus data transmission speed is very low (2400/300 Bps) 5..10mW 868MHz M-Bus protocol defines all 7 OSI layers OBIS id. These do not fully cover all the electricity meter features but these are currently being defined in an ‘open protocol’ working group in Germany and therefore should be available for the implementation of smart metering Designed specifically for metering applications M-Bus forms part of the Dutch Smart Meter Specification5. Wireless M-Bus is designed to be used heat, water and gas metering as well as heat cost allocators. Proposed usage of wireless M-Bus in Germany and Austria.

Hardware: Cost: Data: Power: Frequencies: Protocols: Data Exchange Format: Use in other applications: Use in other markets:

Maturity: Support for ‘Last Mile’: For: Against: Notes: Reference:

Over 80 companies have implemented M-Bus in their products. CEN standard since 2001 No, design suitable for “in home” communications Well proven, widely deployed, 868Mhz good transmission frequency, efficient data coding Issues relating to the interoperability of the standard and elements from the overall architecture are not yet resolved. Pending EN 13757-5 supports the use of repeaters/relays. V1 Provided September 2008 by Uwe Pahl of Qvedis Table 13 M-Bus

5

Dutch Smart Meter Requirements v2.1 Final – February 2008 – page 6 of the P2 Companion Standard describes the use of Wired and Wireless M-Bus communications.

Page 52 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development Solution
Description:

Version 0_5

Wavenis

www.wavenis-osa.org & www.coronis.com

Hardware:

Wavenis is a wireless connectivity platform that features Ultra Low Power and Long Range coverage capabilities. Wavenis has been developed by Coronis (creation in 2000) to address the most critical applications where devices are located in hard-to-reach places with strong energy constraints for multi-years operation. Offers today one of the most attractive price-performances ratio. Dedicated to remote operation for both fixed and mobile Wireless Sensor Networks. 1 - OEM cards, OEM platforms and ready-for-branding modules (battery powered end points, autonomous range extenders, IP or GPRS gateways, remote monitoring software). Technology core is based on the Wavenis RF transceiver (second source CC1020 from TI) and separated MCU (MSP340 from TI) 2 - Next generation platform of Wavenis (Q1 2009) will be based on a very innovative Wavenis System On Chip (enhanced ultra low power Wavenis RF transceiver + ultra low power 32-bit MCU + memory + drivers) Down to 5 EUR for fully mounted & tested OEM cards 19,6kb/sec typical (up to 100kb/sec max) - Ultra Low Power: 10µA average operating current with 1 sec Rx/Sby period (Rx duration of 500µs). Very sophisticated mechanisms have been implemented to save power in this scanning mode to avoid over-hearing phenomenon, filter false detections, etc … - Receiver peak current in “full run mode” is 18mA. - Transmitter peak current in “full run mode” in 45mA at 25mW. - 868MHz (EU), 915MHz (US), 433MHz (Asia) - 50kHz bandwidth channels (fast FHSS over 16 to 50 channels) Because Wavenis is a wireless connectivity platform only, Wavenis API can handle most of proprietary or standard application protocols (KNX, io-homecontrol, Z-Wave, …). Wavenis OEM cards can also support M-Bus specifications. Wavenis is capable to embed any kind of payload data (from 1 byte to hundreds of bytes per radio frame) Home Automation (lighting control), Industrial Automation (valve monitoring, tank level control, vibration sensor, temperature sensor, digital sensors, …), Alarm & Security (home access control, home alarm systems), Medical (panic button, automatic fall detection) UHF RFID (container and people identification & tracking, temperature tracking) 1 - Water AMR/AMI (SAUR, Elster AMCO, VEOLIA, Sensus, …) 2 - Gas AMR/AMI (ChinaGas, GasNatural @ Spain, …) 3 – Electricity AMR/AMI (EDMI, …) 4 – Home Automation (Schneider @ Denmark, …) Milestone of 3,000,000 Wavenis enabled devices deployed worldwide to be reached by end of 2008 1 – Up to 25mW output power class Wavenis modules offer 1km Line of Sight (LOS) thanks to -113dBm sensitivity (50kHz bandwidth receiver) with -3dBi helicoidal antenna.

Cost: Data: Power:

Frequencies: Protocols:

Data Exchange Format: Use in other applications:

Use in other markets:

Maturity: Support for ‘Last Mile’:

Page 53 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

For:

2 – 500mW power class Wavenis modules offer 4km range. These modules are usually intended to range extenders for large scale networks. 3 – Wavenis supports Star, Tree and Mesh network topologies. 1- Field proven technology with large scale deployment worldwide 2 - Hi-reliable technology thanks to implementation of fast Frequency Hopping Spread Spectrum (FHSS) techniques combined with data interleaving and Forward Error Correction (BCH) mechanisms. Encryption is implemented in option upon customer request. 3 – With 17 other companies, Coronis launched (June 2008) the Wavenis Open Standard Alliance (www.wavenis-osa.org) which paves the way of the Wavenis standardization to play a major role worldwide in the “Short Range Wireless” markets.

Against: Notes: Reference: V1 provided March 2008 by Bev Adams of Elster V2 provided Sep 2008 by Christophe Dugas of Coronis, an Elster Group company & Wavenis-OSA Table 14 Wavenis

Note – ZigBee, at the request of group members, is presented in two iterations to acknowledge the different functionality and performance of differing frequencies
Solution Description: ZigBee @ 868MHz www.zigbee.org

Silicon based protocol operating on the IEEE 802.15.4 standard for physical layer and medium access control. Networks can contain 65536 nodes. Supports two types of devices: - Full Function Device (FFD), which can co-ordinate or participate in a network - Reduced Function Device (RFD), which can only participate in a network Supports 128-bit encryption

Hardware: Cost: Data: Power:

Radio chips available from Atmel Between 20 and 40 kbit/s at 868MHz (improved by 2006 revision of IEEE 802.15.4 to 100 to 250 kbit/s) Varies by individual chip – typical average is μ1A. ZigBee devices come in two flavours for power consumption – routers and end devices. Routers are expected to operate continuously to support and drive the mesh network and therefore require a constant source of power. End Devices are battery powered radios that only come to life when required to transmit or receive information. Usage profiles –

Page 54 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

frequency of transmission and the size of those transmissions - will determine the eventual battery requirements. Frequencies: Protocols: Data Exchange Format: Use in other applications: Use in other markets: Maturity: Support for ‘Last Mile’: For: Against: Notes: Reference: Collated by SRSM project team from group activities Table 15 ZigBee @ 868MHz ZigBee @ 2.4GHz www.zigbee.org Smart Energy Profile due for release March 2008, ZigBee Pro Stack available January 2008 Specified in the ZigBee Smart Energy Profile which can be added to if required. Total ZigBee node and chipset units – 5 million in 2006, 120 million in 20116 Home automation, telecoms (local) 868MHz

Solution Description:

Open global standard developed by the ZigBee Alliance for low cost low power wireless mesh networking for monitoring and control. Supported by 300 member companies and with 22 certified vendors of stack/silicon combinations. Meter manufacturers Itron and Cellnet/Hunt are Promoter members. Based on the IEEE 802.15.4 standard MAC and PHY

Hardware:

Typical ZigBee solutions are one of three types; - System on chip (SoC) single chip solutions with radio and microcontroller running ZigBee stack and application - Network coprocessor solution with SoC running the networking stack and the application running on a host microcontroller - Dual-chip solutions (older) with an RF transceiver and a separate microcontroller running the stack and application. Radio chips available from Ember, ST, TI, Freescale, Renesas, Jennic and others

Cost:

~$3-$4 for SoC devices in millions of units typical - ~$5 for SoC devices in low volume (1000-off) - Typical BOM cost ~$6-$10 depending on volume, antenna etc. - Modules available <$20 in low volume, <$10 in high volume. - Prices likely to drop over next 2-3 years due to market maturity, new technologies and growth. - Radios transmit at 250kbps, 128-byte (max) packets - With networking overhead, this typically results in real application

Data:
6

In-Stat Market Research “ZigBee 2007: What it Iz and What it Iz not”

Page 55 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

data throughput point to point of up to ~50kbps, which then varies depending on topology and configuration, e.g. how many hops, level of security, using retries etc. Worst case usually >10kbps effective throughput over many hops, with security, acknowledgements etc. - Not suitable for high volume data streaming applications such as voice or video, but reasonably high bandwidth allows for large networks for e.g. sensing and control. Power: ZigBee includes mains powered ‘always on’ devices for routing messages and battery powered ‘end devices’ typically for sensor and switch type devices. - Typical SoC devices operate at 20-35mA when in receive or transmit, with the radio typically accounting for 2/3 of the power consumption in RX/TX. - e.g. in TX mode, EM250 operates at 35.5mA at +3dBm, 41mA at +5dBm - Typical SoC devices when in deep sleep, operate at <1uA. 2400MHz – 2483.5MHz (2.4GHz) The ZigBee standard describes in detail the over the air protocol used, however there are a number of layers to consider when looking at ZigBee protocols; 1. MAC layer – uses standard IEEE 802.15.4 messaging for point to point communications in the mesh network 2. Network Layer (NWK) – ZigBee adds headers for networking in a multi-hop network (end to end device addressing etc.) and security 3. Application Support Sublayer (APS) – Provides mechanisms for managing end to end messaging across multiple hops in a mesh network e.g. addressing endpoints in a device, triggering route discovery, managing end to end retries 4. ZigBee Cluster Library (ZCL) - ZigBee defines a library of interoperable message types called ‘clusters’ that cover a variety of device types. This library can be added to when creating support for new applications. 5. Application Profile – As ZigBee is targeted at a number of different markets and application types, it is appropriate to have an application profile definition which defines how each device and application will behave, which clusters (messages) are in use and how. Any given device may have multiple endpoints defined, each of which can support a different application profile, defined device and set of clusters. At present there are 4 Application Profiles completed in the standard; Home Automation, Commercial Building Automation, Smart Energy and Telecommunications Applications. Products may be certified to an application profile through independent test houses NTS and TUV. Non-interoperable products may also be certified as “Manufacturer Specific”, which means that they coexist with other ZigBee networks but do not interoperate. New application profiles are being defined continuously. For example there is currently considerable effort ongoing in task groups and member companies to standardise the use of IP in a ZigBee network. Data Exchange Format: Format is defined by the ZigBee specification, in the ZigBee Cluster Library and Application Profiles.

Frequencies: Protocols:

Page 56 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Custom protocols / data formats are allowed, but would not be guaranteed interoperable. Use in other applications: Use in other markets: Total ZigBee node and chipset units – 5 million in 2006, 120 million in 20117 Home automation, telecoms (local) ZigBee has a wide appeal across multiple markets, and is currently in use in products in; - Smart Energy, for Local Communications e.g. Southern California Edison in the USA, Victoria in Australia, and last mile communications, e.g. City of Gothenburg - Home Automation, including lighting control (e.g. Control4), heating control (e.g. Kalirel), security (e.g. Alertme.com), roller blinds etc. - Commercial Building Automation, including lighting and heating control (e.g. TAC/Schneider, Siemens) and fire and safety. - Industrial control such as ball valve monitoring/control (Eltav) - Health monitoring products are in early stages of development. - Niche markets such as marine electronics (e.g. Ray marine) Geographically, ZigBee has products all around the world. The ZigBee Alliance was formed in 2002. ZigBee was first released as a standard in December 2004. Since then there have been 2 major releases of the standard, one in 2006 and the most recent, adding ZigBee PRO features in 2007. With a number of products now certifying for Home Automation, Manufacturer Specific and Smart Energy, ZigBee 2007 is regarded now as mature. A number of vendors of ZigBee silicon have had customers with products in the market for a number of years with earlier variants of ZigBee stacks. It is generally accepted that about 7 million ZigBee/IEEE 802.15.4 chips were sold worldwide for inclusion in products in 2007. Support for ‘Last Mile’: ZigBee is well suited to last mile communications because of many features; - Scalability of the mesh network allows for many hundreds or thousands of devices in a single network, communicating across multiple hops from source to destination. - Robust communications is provided through retry mechanisms. - Security can be added, even to the point of having individual application link keys between electricity meters and the concentrator. - A network that makes use of powered devices to provide a mesh while facilitating battery powered end devices is entirely suitable to metering systems for electricity, gas and water. - Excellent bandwidth available at 2.4GHz to provide not only for AMR and configuration data, but also perhaps other data in the future, such as alarms or health monitoring of elderly. - 16 channels at 2.4GHz provide scope for further increased availability of bandwidth as different networks in the same area can occupy different channels. - Excellent range can be achieved within regulations, up to 1Km line of sight has been shown.

Maturity:

7

In-Stat Market Research “ZigBee 2007: What it Iz and What it Iz not”

Page 57 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

There are a number of examples of the use of ZigBee in last mile communications for AMR already, the most notable in Europe being the City of Gothenburg project currently being installed for gas and electricity meters in Sweden. A number of meter manufacturers have already implemented AMR systems using ZigBee. For: - Open Global Standard, supported by 300 companies and 22 stack/silicon solutions - A new technology that is mature and accepted by the smart energy community, yet future proof - Cost-effective technology that will become even more cost effective in the next 2-3 years - Suitable for Local Communications AND last mile communications, opening up the possibility of a single communications chip in smart meters covering both! - Robust, secure, scalable mesh networking - Good bandwidth availability for a monitoring and control network, some scope for future use - A number of working ZigBee Smart Energy products in the market and arriving into the market in 2008 - Perception of issues with propagation in buildings, however building construction affects all wireless technologies and can be shown not to be an issue with ZigBee at 2.4GHz in most situations. When there are propagation issues these can usually be mitigated by use of the ZigBee mesh network. - Perception of interference issues with other 2.4GHz wireless technologies, in particular 802.11b/g/n. While there is some basis for concerns they have been satisfactorily addressed by the standard, and tested in independent studies (ref: “ZigBee / WiFi Coexistence Report” by Gilles Thonet and Patrick Allard-Jacquin, Schneider Electric, 29/01/2008) Updated April 2008 – v2 – David Egan & John Cowburn Updated (minor) August 2008 – David Egan Table 16 ZigBee @ 2.4GHz Z Wave www.z-wave.com • Wireless control mesh networking technology • Used by over 200 large companies with real products in the market • Driven by the Z-Wave Alliance – i.e. by the largest industry alliance in the area of home control open for any company to join under RAND terms • Implemented in over 300 interoperable home control products that are on the market • Best-in-Class level of interoperability Between multiple vendor’s products of the same application Between multiple applications (e.g. lighting and HVAC) Between multiple generations of Z-Wave • These products include the 2 key energy consuming applications, lighting and HVAC • Key home control companies (lighting and HVAC) in the UK have adopted and launched Z-Wave products in the market

Against:

Notes: Reference

Solution Description:

Page 58 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
• • • • • • • • • •

Version 0_5

Hardware:

Cost:

• • • • • • •

Data:

• • • •

Power:

• • Frequencies: • • • •

Proven ability to rapidly drive specifications in Z-Wave Alliance e.g. typical process for new application class under 4 months (!) Fully backward product compatibility Strong, reliable certification program in place Lowest cost for certification in industry - $750 with test lab cost Highly mature, proven technology Achieved status as well-accepted de-facto industry standard Available as low cost, low power system on chip (SoC) solution 3rd generation of single chips in high volume production 4th generation single chips out in Q4 of 2008 SoC: RF transceiver, 8051 MCU, memory and rich set of peripherals 64 kbyte OTP or 32 kbyte Flash – Plus up to 16 kbyte RAM Up to 30 GPIOs – ADC – Triac controller – PWM output On chip Full Speed USB 2.0 controller + transceiver (!) Enables true single chip product solutions as lowest cost Lowest possible cost, thanks to FSK technology with low complexity Compact protocol stack sizes From sub $2.00 to $3.00 in high volumes New 4th generation SoC to be released Q4 2008 with even more competitive pricing From $3.00 to $4.00 for complete module (full Z-Wave function – add this module to any product to make it a full Z-Wave product) in high volumes Modern single chip implementation in either 180nm or 130 nm CMOS Sustainable cost benefit due to much higher complexity of competitors 40 kbit/s data communication rate is ideal compromise of throughput for control applications, range, and robustness Small packet size leads to much higher efficiency and lower errors than competing technologies 100 kbit/s available in 4th generation single chip Leader in low power consumption – System on chip with: 20 mA in receive mode (with MCU running) 20 mA in transmit mode (with MCU running; up to + 5dBm) 30-80 μA average power consumption in battery-tobattery networks 1 μA in sleep mode (with POR, interrupts, and wakeup timer running) Only standard with support of battery-to-battery networks (!) No risk of early power source depletion due to WiFi interference etc. Solution is designed from ground up for reliability against interference 868MHz (Europe) – 915 MHz (US) – Other sub-1-GHz (Asia) Addition of 2.4 GHz support for regions without permitted sub1GHz bands in 4th generation chip. Sub-1GHz remains core business Countries such as Japan and China that today don’t permit the use of the 1GHz band are starting to open the 1GHz band because they recognise the value of 1GHz communication as

Page 59 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

• • •

Protocols:

• • •

Data Exchange Format:

• • •

Use in other applications:

• Use in other markets: • • • •

Maturity:

Support for ‘Last Mile’:

well as the large issues on wireless low power control in the 2.4GHz space Only single chip with support of sub-1-GHz and 2.4 GHz in the market to address geographies that really don’t allow anything other than 2.4GHz Multi-channel operation with concurrent listening on all channels Viable strategy for use of license exempt bands in control applications Suitable for long term product deployment and long-term battery use Superior robustness against interference Mitigates the risk of increased support calls and product returns Z-Wave protocol is highly mature mesh networking protocol specifically designed for home control applications Z-Wave protocol consists of PHY, MAC, NWK, and Device class layers Z-Wave device class layer defines command classes and device classes creating interoperable products. The classes are a result of Z-Wave Alliance working groups. Very dense packet size leads to much higher efficiency and lower errors than competing technologies Commands can be extended without braking compatibility (!) Z-Wave security is AES-128 based, either as the symmetric key based Z-WaveSec Plug & Play or as the asymmetric key based Z-WaveIPTLS Designed for interoperability also in setup / installation process On-chip security support Used in practically all home control applications (lighting control, HVAC, drapery and shade control, garage door openers, door locks, security systems, sensors (movement, door/window, humidity, temperature, smoke, CO, etc.), gateways Used control of AV / CE devices (e.g. in universal remote control) Focus on home control / Unified Home Control is the major strength Used in smart metering application by Modstroem in Denmark Used in sub-metering and Energy Conservation applications by DEST in Denmark along with many OEM partners Very high – Clear strength and factor of competitive differentiation Used in over 300 products – available for more than six years Proven for interoperability and backward compatibility 4th generation system-on-chip solutions and 5th generation software Z-Wave is not recommended by Zensys for last-mile usage (Zensys strongly believes that other short range radio technologies are not suited for last mile solutions). However ZWave integrates directly with TCP/IP based WAN technologies through the Z/IP architecture – converging Z-Wave and IP. Z/IP allows IP traffic to be transported on Z-Wave and to carry Z-

Page 60 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

For:

• • • • • • • • •

Against: Notes: Reference

Wave Commands in UDP packets. This architecture is a great option for the last mile. Further Zensys has a very strong bridging capability to other networks. This bridging capability is currently used by Horstmann and Trilliant to bridge the last mile technologies. 2.4GHz interference risk is non-existent Lowest cost Lowest power consumption Full eco-system/cross-segment product portfolio available to communicate to technically but also to build business propositions with from a business perspective Advanced Energy Control framework builds on top of current portfolio instead of starting from scratch Mesh networking and long range ensures minimum installation costs and ease of installation Well accepted industry standard enables integration with today’s and future in-home solutions Lowest risk for long-term, 10-20 year deployment Is portrayed as “proprietary standard” But program for second source / licensing is in place and being executed upon

V1 provided April 2008 by Bernd Grohmann of Zensys V2 provided Aug 2008 by Niels Thybo Johansen of Zensys Table 17 Z-Wave

8.2 Other Solution Options
This section of the document lists a number of other candidate solutions for Local Communications. It gives a short description of the solution, website details where available, and an explanation of why it is not included in the main evaluation process.
Solution Description Website ANT Very low power – 10 year operation on a watch battery. Operates at 2.4GHz. Has 1 million nodes in operation. 43 member alliance. www.thisisant.com

Reason for not Is a proprietary solution, also quite new. including in evaluation Solution Description Website BACnet American developed protocol used mainly for HVAC applications in building automation. www.bacnet.org

Reason for not Specifically aimed at building control – no apparent smart metering utilisation including in evaluation Solution Bluetooth

Page 61 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Description

Version 0_5

Low power radio for personal area networks with up to seven nodes. Single chip radios are available from a wide variety of suppliers, at approx $5 per end, with hundreds of millions of units sold per annum. Very well established standard, particularly in the mobile telephony and PC markets. Operates at 2.4GHz, with average power consumption of 5000μA www.bluetooth.com

Website

Reason for not Although there are a number of standards for Bluetooth, some of including in which may include greater signal propagation and more efficient evaluation power management, Bluetooth is viewed as too power-hungry and not capable of sufficient range to meet the SRSM requirements. Solution Description EkaNET Proprietary wireless solution, partnered with a number of meter manufacturers, Uses IPv6 standards. www.ekasystems.com

Website

Reason for not Appears to be aimed specifically at SCADA deployments, or network based smart grid initiatives – also features WAN gateways including in and other head-end systems evaluation Solution Description: HomePlug An open standard for powerline communications developed by a consortium of companies. Command and Control is available from Renesas, or Ytran chipset plus line coupling devices. Cost of approx $8 per end. Three standards exist depending upon the application: - AV High speed - Home Plug V1 for ethernet over mains applications - Command and Control running at speeds of 1-10 kBit/sec depending on conditions. The Command and Control standard is probably most suited to metering due to its low cost. Used in homes to network Ethernet devices. HomePlug standard is reasonably mature. Command and Control is a recent development www.homeplug.org Is a wired solution only – hence not suitable for gas metering. Remains a potential option for electricity metering, or for inclusion in other RF capable components to provide links to Ethernet devices. Insteon Established North American home control protocol. Typically used over wire, but also supports RF. www.insteon.net

Website Reason for not including in evaluation

Solution Description Website

Reason for not Emphasis on wired solutions does not match gas requirements, including in

Page 62 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
evaluation Solution Description

Version 0_5

also does not currently support secure communications ISA100.11a Provides a wireless industrial process automation network to address control, alerting, and monitoring applications plant wide. It focuses on battery-powered field devices with the ability to scale to large installations and addresses wireless infrastructure, interfaces to legacy host applications plus security, and network management requirements in a functionally scalable manner. http://snipurl.com/isa100

Website

Reason for not Still under development including in evaluation Solution Description KNX Originally developed by Siemens and Merten, primarily aimed at home and building automation. Well established and promoted standard based out of Brussels. Documented by world and European standards – ISO/IEC 14543, EN50090, EN13321-1 Uses the same upper-layer protocol for different physical layers – twisted pair, power line, Ethernet and RF at 868MHz. Communicates data at 16384 bits/sec. Used the same modulation scheme as Wireless M-Bus in S2 mode. www.knx.org

Website

Reason for not Has not been proposed for use in energy metering. including in Attempts to contact KNX alliance have not resulted in any interest evaluation in participating. Solution Description OneNet Open Source low power wireless standard - partners include Renesas, Freescale and Texas Instruments. Features include: • Low power wireless with 1000 foot range and 25 channels • Claims to be very low cost - $2 in high volume • Targeted at battery powered devices • Supports secure encrypted Communications • Star and peer to peer topology • 38 to 230 kbit/s • 868 MHz • Supports 2000 devices in a network • 3 to 5 year battery life with AAA cell www.one-net.info

Website

Reason for not New standard, main focus appears to be battery operated devices. including in evaluation Solution OpenTherm

Page 63 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Description Website

Version 0_5

Communications protocol used to control heating applications. Appears to be wired and has been developed in Holland. www.opentherm.eu

Reason for not Specific application for heating including in evaluation Solution Description PhyNet IEEE 802.15.4 solution that uses IP. Looks to be a competitor to ZigBee, although it also looks more expensive and more suited to industrial application for sensor management, rather than in a metering/home context. No website

Website

Reason for not Very New including in evaluation Solution Description Sensinode The IEEE 802.15.4 compliant radio modules from Radiocrafts combined with the 6LoWPAN compliant NanoStack from Sensinode offers integrators super compressed IPv6 over low power radios in a compact module solution. The use of end-to-end open source IP technology over a proven radio platform provides an excellent and scalable solution for IP-based monitoring and control systems like advanced metering infrastructure (AMI) and wireless sensor networks (WSN). The Sensinode NanoStack meets the 6LoWPAN (IPv6 over Low power WPAN) specifications released in 2007 and offers a scalable and robust architecture for a wireless mesh network where all nodes cooperate to transport information almost like the Internet. By using many small radio modems, a low-power wireless network can cover large geographical areas using the licence-free frequency band at 2,45 GHz. The self-configuring and self-healing properties of the 6LoWPAN network offer redundancy and low maintenance cost. www.sensinode.com

Website

Reason for not Very new including in evaluation Solution Description SimpliciTI Proprietary network protocol supporting up to 100 nodes in a simple network – supports only 5 commands, uses very small amounts of memory and power. Offered in sub 1Ghz and 2.4GHz silicon TI Website

Website

Reason for not Proprietary solution – targets smaller devices – no specific smart metering implementations including in evaluation

Page 64 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Solution Description WiFi

Version 0_5

Established high power standard, prevalent in many homes. Typically used for broadband internet connections and multimedia delivery. Works at 2.4GHz. www.wi-fi.org

Website

Reason for not Power consumption is very high, with propagation issues for a including in significant proportion of GB home types. Also concerns over evaluation conflicts and interference with customers’ existing wireless networks. Low Power WiFi options are emerging, mainly driven by Intel – GainSpan have a prototype module that will run for 10 years on an AA cell. The Intel ‘Cliffside’ initiative is also working in this area. Solution Description Website Wireless HART 2.4GHz, Open Standard, MAC addressing, Mesh networking www.hartcomm2.org

Reason for not Aimed specifically at manufacturing processing applications, mainly in North America. including in evaluation

There are many other emerging technologies in this area that have not been included in this section. Examples include EnOcean, Ozmo, Cliffside from Intel etc.

Page 65 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

9

Additional Considerations

The Local Communications Development Group, and the wider SRSM project, has considered a number of topics related to Local Communications. These include addressing protocols, radio frequencies and data exchange formats. The information gathered and considered on these topics is presented for completeness below. It is acknowledged that a number of the solutions technologies evaluated by the group are strictly limited in terms of the protocols and frequencies, whilst others may be flexible in supporting a range of options. It is not the preference of the group to recommend a requirement for a truly flexible solution if it is not available on the market currently, or would add unnecessary cost to the deployment of smart metering. Therefore, if any solution cannot support IPv6, or operate at 433MHz, this has not counted against it in the evaluation process. Placeholder to document the potential protocols that could be used for Local Communications networks. A number of these may be specifically linked to the physical media solution.

9.1 Network & Addressing Protocols
Protocol Description: IPv6 An internet layer protocol for packet-switched networks. It offers a greatly extended address space over the previous IPv4, allowing for more IP addresses. IPv6 also features enhanced security provisions The majority of internet activity now uses IPv4 or IPv6. IPv6 is likely to be the preferred protocol for WAN Communications. Potential to use a simple version of IP – STM. Against: Headers and Footers for IP add significantly to the data packet size. It would take in excess of 50 ZigBee packets to transmit one IP packet (and this would result in 50 acks)

Used by/for: For:

Notes: Protocol Description: 6LowPan Stands for IPv6 over Low Power Wireless Personal Area Networks, a protocol designed to send and receive IPv6 packets over IEEE 802.15 networks. A number of practical issues relating to packet sizes and addressing schemes remain to be addressed. Still being developed

Used by/for:

Page 66 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
For: Against: Notes:

Version 0_5

Could deliver end to end protocol solution for Suppliers and Authorised Parties Protocol is still under development

Page 67 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

9.2 Frequency Considerations
The Local Communications Development Group considered the potential frequencies to be used for low power radio solutions. The details of these discussions are presented below for completeness. It is acknowledged that the solutions considered by the group are specifically tied to a single frequency – it would not be possible, today, to consider the opportunities to use Wavenis of M-Bus at 2.4GHz. Therefore the solution recommendation will determine the frequency, rather than the frequency determining the solution recommendation.

9.2.1 Frequency Information
General principles with regard to frequency bands: • Higher frequency means shorter wavelength • Antenna length is proportional to wavelength – higher frequencies use shorter antenna • At a given power output, transmission distance is normally further for large wavelengths (lower frequencies) than for shorter wavelengths (higher frequencies) • Higher frequencies are normally allocated a larger bandwidth, enabling the transmission of data at higher rates.
Frequency Description: Used by/for: Signal Propagation: Power requirements: Longevity of frequency allocation: Notes: No chipsets currently available for 2-way communications – it is used for 1-way communication only 184MHz Licensed band Efficient power per distance 169MHz Licensed band Paging band, delegated to AMR

Frequency Description: Used by/for: Signal Propagation: Power requirements: Longevity of frequency allocation: Notes:

Efficient power per distance

Can purchase bandwidth from Ofcom.

Page 68 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Currently only using this band for 1-way push communications (e.g. water AMR), therefore would not meet 2-way communications requirements with existing products (new chip sets would need to be developed) Frequency Description: Used by/for: Signal Propagation: Power requirements: Longevity of frequency allocation: Notes: Support (by existing chips) for open standards is not evident Security may be an issue (e.g. for financial transactions) 868-870MHz Unlicensed European ISM band (915MHz in North America) Z-Wave, Wireless M Bus, ZigBee, Wavenis. Minimal usage in other applications. Good Has well defined maximum duty cycles and transmission powers (5mW to 25mW). Unlicensed European band, unlikely to be revoked, but risk remains Supports 3 channels. Current GB regulations prevent use of frequency for communications outside of a property – i.e. could not form a mesh of smart meters in a street to connect to a data concentrator. Transmit duty cycle limited to 1%, or works on ‘listen before transmit’ basis. Less attractive to higher bandwidth applications. 2.45GHz Unlicensed worldwide ISM band ZigBee, WiFi, Bluetooth, Microwave Ovens, Home Video repeaters 433-434MHz Unlicensed ISM band Well used frequency, typically used for car key fobs. Has been used for heat metering in Europe Good More battery efficient than higher frequency options

Frequency Description: Used by/for: Signal Propagation: Power requirements: Longevity of frequency allocation: Notes:

Frequency Description: Used by/for: Signal Propagation: Power Requirements: Longevity of frequency allocation:

Signal can be amplified to improve propagation Unlicensed global band, unlikely to be revoked, but risk remains

Page 69 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Notes:

Version 0_5

No limits on transmit duty cycle. Issues have been reported when attempting to use 2.4GHz for water metering applications as this frequency has particular problems with the resonating frequency of water.

9.2.2 Licensed or Unlicensed
An ideal solution for smart metering would be to use a licensed band. This would guarantee the availability of interference-free bandwidth for many years. However, the current licensed band for metering in the UK, 184MHz, only supports one-way communications, operates at a frequency unique to this country, and has therefore not attracted solution providers in any significant numbers. Use of a licensed band for Local Communications could also restrict the number of devices within a home that would be capable of communicating with a meter. The unlicensed ISM bands do support two way communications, do have active and growing markets for radio transceivers, and these are the bands being selected for smart metering and AMI implementations in other markets. The volumes of silicon chips being sold for these bands make the unit cost much lower than those for licensed bands ($3 vs. £70)8. The use of unlicensed bands does come with the risk of interference from other devices as they establish themselves at particular frequencies. The 2.4GHz band already includes microwave ovens, Bluetooth, Wi-Fi, TV signal repeaters and more. However, there are a number of techniques in use to allow devices to co-exist effectively within frequency bands.

9.3 Data Exchange Format Options
A number of these may linked to the specific solution, whilst other solutions may support the use of a range of data exchange formats. A more detailed review of the convergence between GB smart metering data requirements and the existing format options would be recommended.
Data Exchange Format Description: ANSI

ANSI C12 is the collective prefix for a number of North American electricity metering standards: C12.18 – Protocol for 2 way communications using an optical port C12.19 – Data tables for use with C12.18 C12.21 – Update of C12.18 for use with a modem C12.22 – Interface to data communication networks Work has been done to map C12.19 to an XML Schema

8

Consultants 2007

Technical Architecture for UK Domestic Smart Meter Systems, Alistair Morfey, Cambridge

Page 70 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Used by/for: For: Against: Notes: Data Exchange Format Description: Used by/for: For: Against: Notes: Data Exchange Format Description: Obis DLMS/COSEM

Version 0_5

Most major meter manufacturers supply ANSI C12 compliant meters to the American market Mature, metering specific standards. Have an existing XML Schema Levels of support for gas metering?

Definition of standardised metering objects (Electricity, Water, Heat, and Gas Metering covered) Commonly used in Electricity metering in Europe, gaining adoption elsewhere in metering Standardised, EN13757-1 (Communication Systems for meters and remote reading of meters -Part 1:Data Exchange) Seen as over-specified and too complex for use within the Local Communications context Parts of the standard are used in MBUS implementations. XML

Extensible Markup Language, a general purpose specification for creating custom markup languages – allowing GB smart metering to develop a bespoke and flexible data exchange format. Global standard for data exchanges, used in an increasing number of applications. Would allow for an exact fit with GB smart metering requirements and applications, would also remain future flexible to accommodate market innovation. XML can be compressed substantially, particularly if a known schema is available. Use of XML for Local Communications could place an unacceptably high overhead on the microcontroller itself. XML support could easily require more space than is typically available on low power radio microcontrollers. Implementation is feasible, but at the cost of adding memory and co-processors and decreasing battery life. A bespoke GB smart metering XML schema would require development and ongoing governance.

Used by/for: For:

Against:

Notes: Data Exchange Format Description: ZigBee Smart Energy Specific ZigBee profile defining device descriptions, standard interfaces and practices for smart energy applications.

Page 71 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Developed and maintained by the ZigBee Alliance. Used by/for: For: Against: Smart metering and AMI activities in other markets Specific solution for smart metering using low power wireless technology Has been developed specifically to address Southern California Edison’s AMI requirements (and is currently being adapted to include requirements from Victoria in Australia).

Notes:

Page 72 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

10 Evaluation of Solution Options
This section of the document details the evaluation process undertaken by the Local Communications Development Group. This evaluation exercise has necessarily been conducted as a desktop exercise. Wherever empirical evidence has been available, from similar evaluations or actual deployments, this has been considered. Throughout the process, it has been noted that the technology receiving the highest rating will not necessarily be recommended by the group. Note: In previous versions of this report, there was content covering data traffic modelling to assist with understanding the type and scale of data exchanges expected. Following discussions within the Development Group, it was concluded that any data modelling undertaken would be based almost entirely on assumptions about the types of activities and the file formats, and was therefore not practical to undertake at this time.

10.1 Evaluation Process
Shown below is the process undertaken to evaluate the solution options: July 18 2008 Meeting • Group refined requirements • Group discussed and agreed high level plan for evaluation criteria and process • Updated evaluation criteria issued for review September 2 2008 Meeting • Presentations and Q&A sessions for each of the solution options • Discuss and update evaluation criteria October 2 2008 Meeting • Review evaluation criteria, assess statements regarding each solution option, agree a ‘traffic light rating’ recording any key gaps, issues or risks noted against a solution option October 29 2008 Meeting • Finalise and agree recommendations Between meetings there has been correspondence between the SRSM project team and solutions providers to resolve queries and update the information presented below.

10.2 Evaluation Methodologies
Each of the criteria shown below are weighted.

10.2.1 Evaluation Weighting
Recognising that some criteria are closely linked to core requirements and principles, whilst others are peripheral, each of the criteria is weighted. Page 73 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

The weighting, which assists the group with prioritising any gap analysis, is shown in Table 18 below. ‘Must Have’ criteria carry a weighting of 4.

10.2.2 Evaluation Assessment
All criteria are assessed in terms of red, yellow, green or blue on a gap analysis/risk assessment basis. A number of criteria have been assessed as Yellow where the claims of the solution options remain based on ‘desktop’ evidence only, where the group felt that evidence from testing would result in a clearer view of performance. Green Yellow Red Blue No gaps or issues Some quantifiable gaps or levels of risk Significant gap or risk No information available

10.3 Evaluation Criteria
Ref Criteria Relevance/Importance (Must Have/Desirable) Weighting 9 (Desirable only: 3 = Very 2 = Fairly 1 = Less) 3 NA 3

Fit with Requirements (not specifically addressed by categories below) 1.1 Low level of energy customer Desirable intervention/support required to maintain communications 1.2 Ease of installation – i.e. Must Have discovery at meter installation Desirable 1.3 Minimise number of site visits to address Local Communications issues – i.e. recovery or remote correction on failure/upgrade failure – will include MTBF and power consumption on meter battery as considerations 1.4 Development tools to support Desirable smart metering and smart energy market 1.5 Ease of integration into Desirable metering/home products –

1 2

9 Must Have criteria carry a weighting of 4

Page 74 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Criteria Relevance/Importance (Must Have/Desirable)

Version 0_5
Weighting 9 (Desirable only: 3 = Very 2 = Fairly 1 = Less) NA

e.g. system on chip, antenna size10 1.6 Scope/receptiveness to accommodate specific GB smart metering requirements Interoperability 2.1 Status as an Open Standard – accessibility, defined standards, range of participants, proven certification process 2.2 Support for choice of data exchange format 2.3 Genuine choice and competition between silicon vendors 2.4 Interoperable chipsets 2.5 Effort required to update standards to meet specific GB requirements (less effort = higher score) 2.6 No. of nodes supported for each HAN, assuming minimum capability of 3. Power 3.1 Consumption/Peak Current/Power Failure Management 3.2 Support for battery powered nodes, but also for energy smart metering application (e.g. data refreshes in minutes rather than hours/days for end nodes) Data Performance 4.1 Transmission speed – effective data throughput in kbps per channel 4.2 Robustness (retry mechanisms, acknowledgements, minimised/nil message loss – i.e. latency and dropped packets) Radio Performance 5.1 Typical range (amplified or
10

Must Have

Must Have

NA

Desirable Desirable Must Have Desirable

2 3 NA 2

Desirable

2

Desirable Must Have

3 NA

Desirable Desirable

2 2

Desirable

3

It was acknowledged during group discussions that an excellent design would represent a poor substitute for commercial momentum

Page 75 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Criteria Relevance/Importance (Must Have/Desirable)

Version 0_5
Weighting 9 (Desirable only: 3 = Very 2 = Fairly 1 = Less) 3

non-amplified) Suitability for GB meter locations (consider internal/external, stone/concrete, metal meter cabinets, meter rooms etc.) 5.3 Vulnerability to signal interference 5.4 Ability to cope with signal interference 5.5 Blocking Immunity in transceiver Security 6.1 Strength/resilience of methods used 6.2 Ability to use rolling/successive keys 6.3 Support for distinguishing public/private data, and for keeping gas/water/electricity data independently secure – i.e. supports 3 different suppliers for 3 utilities (and any other authorised party data secure) Future Resistance 7.1 Support for “over the air” upgrades of ‘smart meter’ nodes – i.e. gas + electricity meters & in home display 7.2 Support for security upgrades 7.3 Support for backwards compatibility 7.4 Longevity of frequency 7.5 Longevity of solution technology (minimum expected smart meter asset life of 10-15 years) Cost Considerations 8.1 Total cost per home – 1 x electricity meter, 1 x gas meter with battery, 1 x home display unit = 3 chipsets + additional battery cost 8.2 Mean Time Between Failures/Reliability Maturity 9.1 Use in equivalent smart metering deployments 5.2

Desirable

Desirable Desirable Desirable Desirable Desirable Must Have

2 3 2 3 2 NA

Must Have

NA

Desirable Must Have Desirable Must Have

2 NA 3 NA

Desirable

2

Desirable Desirable

3 3

Page 76 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Criteria Relevance/Importance (Must Have/Desirable)

Version 0_5
Weighting 9 (Desirable only: 3 = Very 2 = Fairly 1 = Less) 2 1

9.2 9.3

9.4

9.5

Use in analogous Desirable applications Expectation of ongoing Desirable required upgrades – i.e. v2009, v2011 (fewer = higher score?) Must Have Capacity in vendors to meet smart metering demands (meters plus displays and other devices) – assume 5 year deployment to 25 million homes Desirable Availability of non-metering products that could be relevant to smart metering – e.g. thermostats, display devices Table 18 Evaluation Criteria

NA

2

As a result of the evaluation process undertaken by the Local Communications Development Group, each of the criteria above necessarily fall into one or more of the following categories: - those requiring a field test to assess performance - those that can be tested under laboratory conditions - those where a panel review process could determine the level of compliance/risk - those that are not possible to test/evaluate to a certain conclusion The assessment of the solutions against the criteria and within these categories is reflected in the recommendations of this report in section 11 below. It should also be noted that a number of categories appear to show no differentiation between solution options, this is to be expected as they have all been selected for evaluation on the premise that they offer a viable low power wireless option for smart metering.

10.4 Evaluation Scorecard
Ref Criteria 1.1 Low level of energy customer intervention/support required to maintain communications Bluetooth Low Energy M-Bus Wavenis ZigBee @ 868MHz ZigBee Z@ Wave 2.4GHz

Page 77 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Criteria 1.2 Ease of installation – i.e. discovery at meter installation Minimise number of site visits to address Local Communications issues – i.e. recovery or remote correction on failure/upgrade failure – will include MTBF and power consumption on meter battery as considerations Development tools to support smart metering and smart energy market Ease of integration into metering/home products – e.g. system on chip, antenna size Scope/receptiveness to accommodate specific GB smart metering requirements Status as an Open Standard – accessibility, defined standards, range of participants, proven certification process Support for choice of data exchange format Genuine choice and competition between silicon vendors Interoperable chipsets Effort required to update standards to meet specific GB requirements (less effort = higher score) No. of nodes supported for each HAN, assuming minimum capability of 3. Bluetooth Low Energy M-Bus Wavenis

Version 0_5
ZigBee @ 868MHz ZigBee Z@ Wave 2.4GHz

1.3

1.4

1.5

1.6

2.1

2.2 2.3

2.4 2.5

2.6

Page 78 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Criteria 3.1 3.2 Consumption/Peak Current/Power Failure Management Support for battery powered nodes, but also for energy smart metering application (e.g. data refreshes in minutes rather than hours/days for end nodes) Transmission speed – effective data throughput in kbps per channel Robustness (retry mechanisms, acknowledgements, minimised/nil message loss – i.e. latency and dropped packets) Typical range (amplified or nonamplified) Suitability for GB meter locations (consider internal/external, stone/concrete, metal meter cabinets, meter rooms etc.) Vulnerability to signal interference Ability to cope with signal interference Blocking Immunity in transceiver Strength/resilience of methods used Ability to use rolling/successive keys Support for distinguishing public/private data, and for keeping gas/water/electricity data independently secure – i.e. supports 3 different suppliers for 3 utilities (and any other Bluetooth Low Energy M-Bus Wavenis

Version 0_5
ZigBee @ 868MHz ZigBee Z@ Wave 2.4GHz

4.1

4.2

5.1 5.2

5.3 5.4 5.5 6.1 6.2 6.3

11

11

AES encryption is optional in Wavenis, but it is assumed that it would be enabled by default for all GB smart metering use

Page 79 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Criteria authorised party data secure) Support for “over the air” upgrades of ‘smart meter’ nodes – i.e. gas + electricity meters & in home display Support for security upgrades Support for backwards compatibility Longevity of frequency Longevity of solution technology (minimum smart meter asset life 10-15 years or better) Total cost per home – 1 x electricity meter, 1 x gas meter with battery, 1 x home display unit = 3 chipsets + additional battery cost Mean Time Between Failures/Reliability Use in equivalent smart metering deployments Use in analogous applications Expectation of ongoing required upgrades – i.e. v2009, v2011 (fewer = higher score?) Capacity in vendors to meet smart metering demands (meters plus displays and other devices) – assume 5 year deployment to 25 million homes12 Availability of nonmetering products that could be relevant to smart metering – e.g. thermostats, display devices Table 19 Evaluation Scorecard Bluetooth Low Energy M-Bus Wavenis

Version 0_5
ZigBee @ 868MHz ZigBee Z@ Wave 2.4GHz

7.1

7.2 7.3 7.4 7.5

8.1

8.2 9.1 9.2 9.3

9.4

9.5

It was noted by the group that any technologies operating as fabless providers may present a higher risk than Bluetooth or ZigBee @2.4

12

Page 80 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

10.4.1 Evaluation Notes
In order to provide a complete record of the evaluation process, any notes and explanatory text are shown in Table 20 below. Bluetooth low energy: throughout the assessment of the Bluetooth low energy solution option, it should be noted that at the time of preparing the assessment, this technology was not available for review. Therefore all ratings for Bluetooth low energy have been recorded as ‘Unknown’. The evaluation notes assume the exclusive use of Bluetooth Low Energy for the solution. Standard Bluetooth may be used to provide additional functionality for some of the applications that move beyond the immediate requirements, but is not included in these notes. Wavenis ultra-low-power wireless technology: Information was provided by Coronis based on profiles and application optimisation for existing metering solutions that use Wavenis. Wireless M-Bus: the comments and views relating to Wireless M-Bus were not available for the group evaluation discussion on the 2nd October and were provided subsequently for inclusion in this report. Concerns have been expressed by members of the group about the interoperability of M-Bus, where some metering implementations are utilising the S2 or T2 as required by the individual markets. There are also concerns relating to the capability of M-Bus to provide coverage for all GB homes, given that there is no current provision in the standard for repeaters. ZigBee@868MHz: the information has been provided by Atmel, a semiconductor manufacturer, and accordingly does not address in any detail those criteria that relate to matters beyond the provision of the chip itself. In a number of areas the ZigBee at 2.4GHz and 868MHz are not rated at the same level, even though the underlying technology is common. It was felt by the group that whilst there should theoretically be no difference, without certified products it would not be appropriate to rate ZigBee at 868MHz as highly as technologies that do have certified products available. ZigBee@2.4GHz: A comprehensive paper was presented on behalf of ZigBee, as can be seen from the notes in Table 20. The preamble for this document, which provides information on implementation options for GB smart metering, is included as an appendix to this report.
Ref 1.1 Solution Bluetooth low energy Wavenis Rating Notes/Explanation

e.g. Solution X

Green

800 million devices sold in 2007
Once installed, Bluetooth requires no customer intervention to maintain the communications link. This is controlled by the baseband behaviour and is automatically restored after power cycles or link failure. Wavenis offers specific installation methods for metering networks, with end-points using selforganizing services for their initial installation and configuration within the network, self-healing features to repair broken links subsequently. End-user customers should never have to deal with any aspects

1.1

Page 81 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 1.1 Solution Wireless M-Bus Rating

Version 0_5

1.1 1.1

ZigBee @ 868MHz ZigBee @ 2.4GHz

Notes/Explanation of wireless meter configuration. - RF-Transmission interval is selectable for every meter, thus lifetime and battery size of meter is selectable - For that reason a single coin adapter solution integrating e.g. existing Gas meters is possible - High dynamic range allows connection of gateway with typically one hop. No additional Installation point in flat is necessary! similar to 2.4GHz ZigBee solutions Connectivity: • Once installed and commissioned in the network, ZigBee devices do not lose connectivity with the network, even after reset due to battery change or loss of power. • Information about which devices talk to which other devices is held in non-volatile memory on each device, so this is not dependent on a central controller. • ZigBee is a self-healing mesh network, where routes are repaired automatically, surrounding ‘neighbour’ devices are discovered automatically and • Battery powered (end) devices can find new parents if they lose contact. Robust messaging • ZigBee messaging is highly robust, with clear channel assessment before sending a packet; • Retries at a MAC level and • Further retries if necessary at an APS (Application Support) level, resulting in 12 attempts to send a message in a ~5 second period before a message actually fails. Customer Intervention: • No customer intervention is required typically to maintain communications. • Of course, if a device (e.g. In-Home-Display) is broken and has to be replaced, then some recommissioning is required, and this might be done by the energy customer (depending on procedures) • As with any other radio technology, if the user changes the environment to directly block the radio signal between two devices and there is no other path, then some user intervention would be required to clear the blockage, move one of the devices (e.g. in-home-display) or introduce a routing device to allow the message to route around the blockage. The best direct evidence of this is from current installations in UK homes, including companies like

Page 82 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

1.1

Z Wave

1.2

Bluetooth low energy

1.2

Wavenis

1.2

Wireless M-Bus

Notes/Explanation PRI, Alertme, and some of the EDRP trials currently underway. After installation the Self-Healing, Self organizing, mesh protocol mechanisms and the optional Wireless firmware upgrade will perform the network support for the customer. Bluetooth has over ten years of experience of mass market consumer installed products, having shipped over 2.5 billion devices. The most recent version of the standard targeted additional improvements with the Secure Simple Pairing specification. This is used as the basis for Bluetooth Low Energy. End-points are added to the network at the touch of a button on a handheld device (which launches a Service Discovery Protocol process in the end-point). At the same time, the end-point identifies the most powerefficient and reliable path to the nearest gateway. When battery-powered range extenders are used in a fixed network topology, their GPS coordinates are added to the network map for administration purposes. Two types of Installation Installation using “press button” method (Gateway listens to all “new” meters)

1.2 1.2

ZigBee @ 868MHz ZigBee @ 2.4GHz

Installation by scanning RF-Channel and comparing with device list provided by AMR-Back office similar to 2.4GHz ZigBee solutions, however final system / meter not under control of Chip providers If using the ZigBee Smart Energy application profile, this describes in detail the commissioning process for HAN / Local communications. All ZigBee devices have a unique IEEE address called EUI64, sometimes referred to as a MAC address (though in the IT World, MAC addresses are usually 48 bits, not 64 bits like ZigBee). This globally unique MAC address can be used during installation to uniquely identify every device. There are several types of discovery, including device discovery, route discovery and service discovery, all of which are encapsulated in the ZigBee standard and which make installation processes much easier. Standard Z-Wave auto discovery and configuration functionalities allow easy installation. The Advanced Energy Control (AEC) framework using standard IP (Z/IP) remote management allows full control from utility supplier or installer. Bluetooth Low Energy self manages the local communications. It is optimised for low power consumption, minimising the frequency of battery replacement in unpowered meters or displays.

1.2

Z Wave

1.3

Bluetooth low energy

Page 83 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 1.3 Solution Wavenis Rating

Version 0_5

1.3

Wireless M-Bus

Notes/Explanation Self-healing mechanisms are used by end-points in case of network path problems. A battery energy consumption counter is used to raise a spontaneous alert in case of low battery. Over-the-air programming and remote access (by the network administrator) obviate the need for any end-customer intervention. Self healing? One Electricity meter and one Gas meter have a link to one Gateway. A Meter may be remotely assigned to another gateway, if needed. But reassignment is not made automatically for security reasons! similar to 2.4GHz ZigBee solutions, however final system / meter not under control of Chip providers Site visits post installation should be unnecessary with ZigBee deployments, except for normal circumstances like device failure or if the user does something exceptional to create a problem (see above). It should be possible to design battery powered devices like gas meters to last many years on a single battery. This will be largely dependent on the product design and requirements, e.g. type of battery, frequency of communications. Device failures in the field should be minimal. ZigBee chips are designed on proven technologies and processes. MTBF and other statistics may differ from one chip to another, so difficult to provide specific statistics given the number of vendors. Silicon vendors will meet expectations of ERA / UK local Communications in this regard, and individual vendors can supply their individual statistics as part of a competitive tendering process. The 868MHz operation efficiently removes the problematic WiFi interference and the associated support calls. Z-Wave Self-healing automatically repair minor network issues and the optional, wireless firmware upgrade can repair major issues without site visits. Bluetooth development systems are available from multiple manufacturers with over 8 years of shipping products. Testing tools, including production RF test gear are available from multiple vendors. Multiple vendors supply pre-approved and certified Bluetooth modules and have announced their intention to extend this to Bluetooth Low energy modules. The Wavenis Open Standard Alliance promotes multisourcing of Wavenis platforms. Product Development Kits, testing tools and a complete developer API are readily available. Several market leading metering companies have used these tools to deploy hi-volumes of Wavenis water and gas metering solutions around

1.3 1.3

ZigBee @ 868MHz ZigBee @ 2.4GHz

1.3

Z Wave

1.4

Bluetooth low energy

1.4

Wavenis

Page 84 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

1.4

Wireless M-Bus

1.4 1.4

ZigBee @ 868MHz ZigBee @ 2.4GHz

Notes/Explanation the world. Electric metering with embedded Wavenisbased solutions are under development, including for the UK. Ready to use RF-Solution from Amber-Wireless and Radio craft. Transmitter modules + EVA-Kits from Unitronics, Panasonic, Radiometrix etc. Development tools from Chipcon, Analog Devices and another SRDChip Manufacturer. Development kits should be similar to 2.4GHz ZigBee solutions, however there do not appear to be a range of kits available at this point in time. Competition among silicon vendors drives innovation, leading to strong development tools to support ZigBee Smart Energy. For example, Ember’s AppBuilder tool will build ZSE compliant applications that can be immediately certified and are ready for integration with the customer application. A number of companies have been developing products to support smart energy, including for example, Wavecom, who have a ZigBee virtual-IP implementation in their GSM gateway. A number of independent commercial module manufacturers provide cost effective ZigBee modules using chips from a variety of silicon manufacturers; e.g. Telegesis (Ember), Digi (Ember, Freescale), Radiocrafts (TI), Panasonic (Freescale, Ember), Meshnetics (Atmel), Holley (Ember). Z-Wave Alliance provides comprehensive development kits, sample implementation, test and certification tools All Bluetooth systems are single chip these days, and integration sizes are shown by Bluetooth headsets such as the Apple headset. A typical module size is 12mm x 22mm x 2mm, which includes an application processor, protocol stacks and drivers, radio and antenna. These are available with development tools which allow rapid integration. Modules are available with power outputs ranging from 0dBm to +20dBm, giving open field ranges up to 1km. A number of module manufacturers provide precertified modules, removing the need for RF certification and production RF testing. Wavenis RF boards (2-chip solutions) are small enough to be used by customers for door locks, call medallions/wristwatches, light switches, alarms, temperature control units and in-home displays for metering and HAN applications. Even smaller 12-chip solution is due in 2009, with enhanced power-saving features. Current platform is available in different forms, depending on integrator’s desired time-to-market (from ready-to-use modules to development platforms).

1.4 1.5

Z Wave Bluetooth low energy

1.5

Wavenis

Page 85 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 1.5 Solution Wireless M-Bus Rating

Version 0_5

1.5 1.5

ZigBee @ 868MHz ZigBee @ 2.4GHz

Notes/Explanation Chipcon solution CC1101 4x4mm Semtech SX1211 6x6mm Most applied metering µC MSP430 come next year for the first time with an integrated RF module. The first available integrated solution to support SRD-Radio (very suitable for wireless M-Bus, but not restricted to it)! Ready to use RF-Solution from Amber-Wireless and Radio craft. Antenna size is the same for all solutions and depends on Frequency only! Chip antennas available (but not always recommended). 868 MHz requires larger antennas, PHY/MAC/NWK/APS layer similar to 2.4GHz implementations There are three main models for ZigBee chips; a) System-on-chip (SoC) solutions (e.g. Ember EM250, TI CC2430) which have an integrated IEEE 802.15.4 radio and microcontroller, allowing the entire ZigBee stack and application to reside on a single chip. These are particularly important for small battery powered devices such as thermostats. Most silicon vendors are developing their solutions further down this path, providing more powerful microcontrollers and in some cases more flash and RAM space for application code to run. This is the solution likely to drive ZigBee costs down in the next few years. b) Network Coprocessor solutions (e.g. Ember EM260, TI CC2480) are not very common at the moment among vendors, but nonetheless are proving popular in the smart energy space because of the ability to connect your favourite ZigBee chips and software stack to your preferred microcontroller. For instance, Ember EM260 has been used in designs with Atmel AVR, TI MSP430, Renesas H8, Microchip PIC, STR7 etc. etc. Using this model, the designer can continue to use the same micro as before in the application design, just add a little code to connect the ZigBee Coprocessor. This is not as cost effective as SoC, but if you already have a micro in your design (e.g. in a meter), it is a cheaper and more efficient way to add ZigBee. c) Dual chip solutions (e.g. Ember EM2420 + Atmel AVR, Meshnetics Atmel AVR + Atmel radio, TI CC2520 + MSP430). This is the older model of operation, which is not quite as efficient as SoC, but nonetheless preferred by some developers. A range of antennae is available for ZigBee as for other 2.4GHz radios, some are customised specifically for IEEE 802.15.4/ZigBee. The most cost effective can be ceramic antennae, or even printed antennae.

Page 86 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

Notes/Explanation A range of options for the balun is also available, including designs with discreet components (most cost effective), ceramic balun and some vendors are integrating the balun in the chip. Power Amplification (PA) designs are also available to boost power up to +10dBm (Europe) or +20dBm (US), including modular PA designs from e.g. TI and Skyworks. A range of competitive ZigBee modules for the same chipsets and different ZigBee chipsets are available. These allow the designer to avoid the hardware design headache, rather to take a proven, tested and certified design to integrate into the product. Industry smallest communication module (8mm x 8mm). Industries smallest single die 2.5mm x 2.5mm. Large set of chip communication options (USB, UART, SPI) provides glue less integration into products Work could start very quickly to fully accommodate your requirements. Bluetooth Low Energy has a profile structure that allows custom profiles to be developed rapidly, either as public profiles, which are certified by the Bluetooth SIG, or as private profiles, which would be certified by a manufacturer or national body. The bulk of companies involved in Bluetooth Low Energy profile development are based in the UK and Scandinavia and are already involved in automation and measurement industries. This concentration of expertise and interest means that any new Low Energy profile work is likely to be done very quickly. A private profile could be developed and tested in a matter of weeks. Profiles for any wireless standard are only effective if combined with a certification program, which must be taken into account. This is explained more fully in appendix E. Wavenis wireless technology respects European communication standards and thus is fully compliant for use in the UK. Metering application parameters (i.e. embedded in end-points), such as scheduling, automatic transmission, alert types, data content, etc. are completely adjustable to meet current and future utility needs. Such changes and optimisations, typically based on the existing core smart metering solution are made using the Wavenis development tools. Is a released European Standard. But it will be worked on to fit Requirements of Smart metering as discussed in EU! This process has happened in Germany and in the Netherlands and could be applied in GB as well. Cooperation between countries is welcome and ongoing, and will lead to a revision of standard!

1.5

Z Wave

1.6

Bluetooth low energy

1.6

Wavenis

1.6

Wireless M-Bus

Page 87 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 1.6 1.6 Solution ZigBee @ 868MHz ZigBee @ 2.4GHz Rating Notes/Explanation no issues expected for HAN usage

Version 0_5

The ZigBee Alliance has a Smart Energy Working Group, which is open to members of the ZigBee Alliance (membership is open). It is a relatively easy process to discuss and propose changes to the Smart Energy profile, OR propose a new profile. It probably can be done in 6 months or less, given that the standard is most likely already 80-90% suitable for GB. This process is happening right now for the Australian requirements, which are being incorporated into the current ZSE spec, which was designed primarily by and for US utilities and metering manufacturers. The ZigBee Alliance is actively engaging with European expert groups like the DLMS user association and ESMIG, to assist with the integration of Europeanspecific protocols into the ZigBee standard. In the US, this process is also happening to bring HomePlug devices into the ZigBee Smart Energy family. The Z-Wave Advanced Energy Control (AEC) framework is targeted to provide remote metering, submetering, end-user information displays, advanced load control though other Z-wave devices and extensive support for prepayment meters. The AEC framework supports any mix of meters (gas, electricity, water etc) Bluetooth is the definition of an open standard, with an open IPR policy, and a wide range or participants from computers / phones / industrial / automation / consumer electronic and other industries. Bluetooth’s specification and certification process has been adopted as the example of best practice by many other standards. Unlike other standards, such as ZigBee and 6loPAN, which rely on external specifications (IEEE 802.15.4) which do not have a certification process, the Bluetooth standard takes a holistic approach, owning all parts of the specification. This has been one of the prime reasons that Bluetooth has achieved interoperability within the difficult consumer space. Bluetooth has the longest established certification process for any of the relevant short range wireless technologies. It has now certified over 11,500 different products, compared with a few hundred for the other proposed standards. Bluetooth Low Energy will use the same certification process. Multiple test houses have been certified to test and qualify Bluetooth products. The Bluetooth SIG also develops and provides testing tools of certification of

1.6

Z Wave

2.1

Bluetooth low energy

Page 88 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating Notes/Explanation public profiles

Version 0_5

2.1

Wavenis

2.1

Wireless M-Bus

2.1

ZigBee @ 868MHz ZigBee @ 2.4GHz

2.1

Spec is available for $0 and can be delivered in an end product for $0 royalty to anybody. The Wavenis Open Standard Alliance (OSA) has been launched, and is now open for membership. Key partners to include design houses, silicon vendors, meter manufacturers, utilities, software providers, wireless solution providers, and one or more independent certification bodies. EN13757 is an open CEN -standard covering M-Bus and DLMS and related communications. The British Standardisation Institute is involved in the European standardisation process (and voted in favour of last adoptions of this standard). Several Companies in GB are members of Working Group 5 (Radio communication) to take care of the requirement of the British market. IEEE 802.15.4 / ZigBee are open standards. However, the lack of certified products, or indeed a certification process, do not support a high rating – this should change as certified products emerge. The ZigBee Alliance is responsible for the development and marketing of the ZigBee standards. The Alliance is an open group of approximately 300 companies which is open to new members, and currently includes silicon vendors, meter manufacturers, electronics companies of various sorts and customers such as utilities. - The ZigBee Alliance is guided by a board of directors which consists of Promoter members of the Alliance, and includes some of the largest silicon manufacturers, meter manufacturers and OEMs. - The ZigBee Alliance has a small full-time staff, which includes the Chairman, Dr. Bob Heile, who has been involved with a number of IEEE 802 standards in the past. - Most of the work of the ZigBee Alliance is performed by staff from the member companies, in areas where these companies have particular interest. The working groups are always happy to accept new members and new member companies into the discussions. The ZigBee Specification and ZigBee Application Profiles are all available for download by non-members from the ZigBee Alliance website. Non members who wish to use the ZigBee standard for commercial gain must become members of the ZigBee Alliance before that product is launched, however if they wish to produce products or stacks not for commercial gain (e.g. Universities) then they are free to use the Intellectual Property of the ZigBee Alliance without becoming members. There is no royalty or

Page 89 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

Notes/Explanation license fee for use of the ZigBee specifications or chipsets using the ZigBee specification. The ZigBee Alliance is a global organisation, currently supported by 22 ZigBee Compliant platforms, which customers can choose from, a number of which are provided by global silicon vendors such as Ember, ST, Renesas, Freescale, TI and Microchip. This variety of implementations across many regions of the World allows for genuine competition between vendors both globally and regionally on the basis of price, performance and architecture. The Z-Wave Alliance was established in spring 2005 and is open for any p00articipant. Today it has more than 170 members with more than 300 shipping products around the world. The Z-Wave Alliance governs the strict and yet low cost Z-wave certification programme to ensure full interoperability. The convergence between Z-Wave and IP (Z/IP) is a solid result of this effort. Bluetooth Low Energy provides the ability for secure, reliable transmission of data between devices using protocols that are optimised for minimal power consumption. The use of an attribute protocol gives immense flexibility in the way in which data can be represented and exchanged. It also provides the basis for simple profile development to enable a specific data format if an existing profile does not cover the requirements. Payload data can be either defined for specific GB market needs or leverage existing Wavenis-based smart metering profiling (with millions of units deployed). EN13757 is separated in parts describing Communication (wired and wireless communication) and Application protocols like M-Bus or DLMS. Other Protocols may also transport via communication modules. To be really interoperable, it is recommended to restrict number of supported protocols. Products are emerging to support ZigBee Pro at 868MHz, but not yet for ZigBee Smart Energy Like all standards, at a low level there is at least some fixed formatting of packets to ensure interoperability between different ZigBee radios. IEEE 802.15.4 specifies certain packet header information that must exist to enable packets to be received by the correct target node etc. Likewise, the Networking (NWK) and Application Support (APS) layers of the ZigBee stack adds header information to this protocol to support for example security, mesh routing and end to end acknowledgements. Above the APS layer, the application is free to implement whatever data exchange formatting it requires.

2.1

Z Wave

2.2

Bluetooth low energy

2.2

Wavenis

2.2

Wireless M-Bus

2.2 2.2

ZigBee @ 868MHz ZigBee @ 2.4GHz

Page 90 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

Notes/Explanation The ZigBee standard defines application profiles, which include (but are not exclusively) definitions of the data exchange format for any given device in a given application or network. By defining the data exchange format in this way, interoperability between devices manufactured by different companies is enabled, and through certification by an independent third party, is guaranteed. The ZigBee Smart Energy (ZSE) profile is one such application profile which defines the data exchange format for a number of devices including meters, gateways, in-home-displays and thermostats. Other profiles include Home Automation (HA), Commercial Building Automation (CBA), Telecoms Applications (TA) and Personal Home Health Care (PHHC). The use of these application profiles is not compulsory! In fact, many of the 250 or so ZigBee products on the market today do not use any of the public application profiles, mainly because there is no requirement for interoperability with other vendors because they are sold as part of a “whole system”. These products can be certified as “Manufacturer Specific Profiles” however they cannot carry the ZigBee logo on the product to indicate interoperability. So, any private application profile (or data exchange format) can be implemented at an application level on top of the ZigBee APS layer. In this way, any private (or new public) data exchange format can be accommodated in a ZigBee application. Indeed, if those who create this data exchange format wish to do so, this can be published as a public application profile after it has been through the normal process for discussing, approving and testing public profiles. Also, some of the current public application profiles in ZigBee allow for ‘tunnelling’ of other data exchange formats. In this way, most of the application communications might use CBA messaging for instance, but some of it could use BACNET messaging. In the case of ZSE it is likely that there will be a tunnelling mechanism for DLMS. The AEC framework allows a flexible and yet well defined command structure between devices. There are many silicon vendors shipping Bluetooth chips in the hundred’s of millions territory. Because low energy is being mandated by the mobile phone and PC industry, most of these vendors have already announced Bluetooth low energy chipsets. In addition, traditional low power, proprietary radio silicon vendors have also announced that provide Bluetooth

2.2 2.3

Z Wave Bluetooth low energy

Page 91 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating Notes/Explanation low energy silicon.

Version 0_5

2.3

Wavenis

2.3

Wireless M-Bus ZigBee @ 868MHz

2.3

2.3

ZigBee @ 2.4GHz

2.3 2.4

Z Wave Bluetooth low energy

The predicted market for Bluetooth low energy compliant chipsets is in excess of 2 billion in 2011, which will ensure a healthy range of silicon suppliers. Wavenis uses the readily available TI CC1020, which is produced by several foundries (TSMS and AMS). A second source for the Wavenis transceiver is in progress (chip now undergoing testing) with Systemon-Chip partner. Other clearly identified sourcing to come via Wavenis-OSA members. Chip-Manufacturers are Atmel, Analog Devices, Chip con/TI, Infinion, Melexis, Nordic, Semtech and others; Technology is used in Home automation, Automotive industry, Metering and much more. It is believed that silicon can be provided by Atmel and Renesas, and that there are a number of software companies offering products using these chips. Other silicon companies are expected to enter this space. As stated already, there are currently 22 separate ZigBee Compliant Platforms. Some of these are different software stacks using the same silicon, and some are more academic or regional in nature, and so are not as competitive globally as some of the others. There are a number of silicon vendors who have their own software stacks and tools (e.g. Ember, Freescale, Renesas, TI, Jennic, Microchip etc.), and others who partner with software or module companies to deliver a ZigBee solution (e.g. ST Micro, Atmel). There are certainly at least 5-7 highly competitive, global, ZigBee solutions on the market today based on different silicon. True Pin compatible 2nd source in 2009 Bluetooth is expected to work out of the box and interoperability is the first requirement in developing the specification and certification process. Bluetooth does not allow the shipment of chipsets unless they have been proven to be interoperable with at least two other chips – this is true for standard and low energy Bluetooth. This means that the requirement of interoperable chipsets is met. Bluetooth is the only organisation that has an enforcement policy that will take legal action to remove non-compliant products from the market. Interoperability guaranteed through Wavenis-OSA compliance certification Regulation of this open standard and neighbouring standards ensure interoperability of different chip solutions. At present, without certified ZigBee Alliance products, it may not be possible to guarantee that all chips and chipsets are interoperable. Proprietary products are

2.4 2.4 2.4

Wavenis Wireless M-Bus ZigBee @ 868MHz

Page 92 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

2.4

ZigBee @ 2.4GHz

Notes/Explanation available, but it is not clear if these have been tested for interoperability. As already stated above, there are 22 ZigBee Compliant Platforms and at least 5-7 of these are genuinely highly competitive on a global scale. ALL compliant platforms go through interoperability testing to ensure that the ZigBee stacks and radios can interoperate at that level. All ZigBee radios must first pass IEEE 802.15.4 testing before they do ZigBee Platform Compliance. At an application level, each product manufacturer must take the final application through interoperability testing with an independent test house before being certified and allowed to use the ZigBee logo on products. This is nothing to do with the chipsets per se, but it is essential for interoperable products. Strong and proven history of backwards interoperable chips through the last 6 years: ZW0102, ZW0201, ZW0301 and ZW0401 can all be used in the same ZWave network Effort required is to update specifications, guided by experienced members. You must provide feature requirements documents, and help review the specifications. As mentioned in 1.6 above, the companies most actively involved in the low energy profiles are located in the UK and Scandinavia and are keen to support this market requirement. Current solution is 100% compatible with GB regulations, with customers integrating Wavenis into upcoming products for the UK. Changes to adapt to new requirements would typically be made at the application level, rather than the Wavenis wireless level itself. EN13757 is a special Standard to handle meter communications only. Regarding new requirements, an extension of the standard is in discussion now. The general conditions for Meter management differ from country to country. Future requirements will be adopted either in user associations (like e.g. DLMS-UA) or by a standardisation working group. Application protocol changes like new OBIS-Code for a special data point may be introduced in 6 to 12 months. Work may be required, as for 2.4GHz to update the ZigBee Smart Energy profile to bring it in line with GB requirements. No products are currently available, and new products would require certification by the ZigBee Alliance. It is hard to say for certain, as the GB requirements are not yet so clear, however it seems that the requirements for GB ought not be so different from those for HAN communications in the US and Australia. I suggest that GB smart metering could decide to adopt

2.4

Z Wave

2.5

Bluetooth low energy

2.5

Wavenis

2.5

Wireless M-Bus

2.5

ZigBee @ 868MHz

2.5

ZigBee @ 2.4GHz

Page 93 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

Notes/Explanation 100% the ZigBee Smart Energy profile with a minimum of minor adjustments. There are some requirements that may cause modifications to the ZSE profile, such as the use of DLMS for some parts of the network, or introduction of some new messaging protocol. In any case, all the mechanisms exist to allow for discussion, drafting, completion and testing of such changes within the structure of the ZigBee Alliance. Very little - The AEC is developed with the GB requirements as part of the foundation. The flexible framework allows for fast changes if late GB requirement changes should occur. Bluetooth low energy does not keep active connections for very long. Its addressing scheme, therefore has a maximum theoretical capacity in excess of 2 billion maximum supported nodes is approximately 2 billion. Practical active connections would be closer to a couple of thousand. The number of Wavenis nodes in a complete network is unlimited. (6-byte MAC address). Generally speaking, gateways (i.e. GPRS) connect from 2,000 - 4,000 meter end-points in actual deployment situations, which provides optimal battery life as well as network robustness. There is no limitation (Address range is 8 Byte) no of maximum supportable (addressable) IEEE802.15.4 / ZigBee nodes much higher than minimum requirement ZigBee supports up to 65,000 nodes in a network, however the practical limits of such networks are usually dictated by traffic and application model. Certainly many ZigBee networks exist today with several hundred nodes per network and thousands of nodes should be easily achievable. Most home automation vendors consider the possibility of about 200 nodes in a home, and when you consider every power outlet, every light and light switch, every shutter/blind, every closure in a security application, you can see how it could be possible to have that number of nodes in a single network. ZigBee can easily handle that number, in fact the more nodes in a network the more robust the ZigBee mesh network becomes. Z-Wave supports 232 nodes within one Z-wave segment (HomeID). More nodes can easily be supported by using segments through the Z/IP Gateway. Power consumption of radio chips correlates strongly with the maturity of the silicon. As volumes drive new chip designs, smaller process geometries and design experience result in progressively more efficient

2.5

Z Wave

2.6

Bluetooth low energy

2.6

Wavenis

2.6 2.6 2.6

Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz

2.6

Z Wave

3.1

Bluetooth low energy

Page 94 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

Notes/Explanation transmitters and receivers. This is true for any wireless standard. Bluetooth chips are now in their 5th or 6th generation and achieving peak instantaneous current draw when transmitting of approximately 20mA. , however duty cycle improvements, which are being copied in the low energy standard can lower this down to 12 mA as required by button cell batteries. Power failure is not an issue as connections are as required not permanent. The Bluetooth low energy standard is targeted at battery powered consumer applications. Hence it includes a battery check capability, where the chipset can report the battery status, allowing this to be notified and replaced prior to failure. Overall consumption depends on the duty cycle. Bluetooth low energy is designed for ultra low power. A typical low energy implementation of a battery powered unit with a 0dBm transmit power, that talks to the infrastructure connection once every 30 minutes and updates a remote display every 2 minutes would work for - 10µA average operating current with 1s period time - 18mA full run Rx and 5mW class Tx - 45mA full run for 25mW class Tx - 500mA full run for 500mW class Tx - Low-battery detection and permanent energy counter tracking Every 1s (typical value for metering), Wavenis devices wake-up from sleep mode (1µA) to Rx RSSI detection mode. If no energy is detected on the channel, the Wavenis device goes back to sleep mode. This only takes about 500µs. If energy is detected, Wavenis Rx full run is activated to detect signal coherence. If the signal is incoherent, the Wavenis device goes back to sleep mode. This only takes 1. 6ms. But when talking about power consumption, we also have to consider the behaviour of the entire network. This is why several FHSS algorithms have been implemented to avoid the over-hearing phenomenon and provide efficient mesh network services. A relaxed synchronization beacon is transmitted every 90mn throughout the network to align clocks and wake-up timings for all devices. A hopping table is calculated based on a pseudo-random sequence. Periodic receive-standby mode is set to ~1s for metering. This gives a 1s latency time at worst for a direct link or 4s at worst in case of 3 relays. Each device calculates its own pseudo-random hopping

3.1

Wavenis

-

Page 95 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

Notes/Explanation table based on its own MAC address. Lastly, transmission implements a fast FHSS with pseudo-random frequency hops every 2 bytes

3.1

Wireless M-Bus

Ultra low power (e.g. 10 years 1Ah). There is no requirement other than the application itself sending data. Therefore the power consumption will be controlled by the meter itself. For a battery powered meter, the battery size is normally restricted by price. However a long lifetime may be ensured by the selection of transmission power and data rate. Example: A meter sends 2 Telegrams per hour with a higher power e.g. 12 dBm (using 60 mA) and slow data rate (S-mode). It needs 0.1Ah for Transmission power over 10 Years. Another meter using a faster data rate (T-mode) with 5 dBm (using 30 mA) may transmit 10 times faster using same energy. Because there is no synchronisation required, a Power fail of a mains supplied unit will not affect the system (excluded time of power fail).

3.1 3.1

ZigBee @ 868MHz ZigBee @ 2.4GHz Power consumption will differ from different silicon vendors, and this is one area where competition is strong. Typically, power consumption is a trade off against RF performance, so a chip that uses 25mA transmitting at 0dBm might not be as desirable as one which uses 35mA transmitting at +3dBm. It is also necessary to consider whether an external PA will be used, and in many Smart Energy situations it would probably be advisable to use a PA to +10dBm. It is also fair to say that much innovation in the area of power consumption is under way as part of this competition between vendors and there is an expectation that it will improve in the next couple of years. There are two main models to look at: routing devices (which have a constant source of power) and sleepy end devices (which are battery powered). Routing devices must have the radio on in receive mode at all times, in order to be able to receive a message from another device, either for itself or to be routed on in the network. Typical power consumption in receive mode is between 25mA and 35mA today, and I would expect that to go down to between 15mA and 25mA in the next 3-4 years. In transmit mode, which occurs rarely compared to receive mode, devices differ greatly in both power consumed and transmit power achieved, typically between about 25mA to transmit at 0dBm to about 40mA to transmit at +5dBm. Power amplifiers to bring transmit power up to +10dBm could bring total power consumption during TX to as

Page 96 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

Notes/Explanation much as 100mA, but again this is improving all the time. Sleepy End Devices spend most of the time in a sleep mode, either on a timer or waiting for some external interrupt (a line brought high/low, button push etc.). While asleep, the best ZigBee devices can draw as little as 600-700nA, and most will consume a small number of uA (microAmp). When awake and transmitting, the figures for transmit power above will apply, though usually only for a very small percentage of the total time. Most Sleepy End Devices have a duty cycle less than 1%, and many are less than 0.1%. Most devices have some sort of internal or external brownout detection and the range of voltages supported differs from chip to chip, but many can survive down to about 2.1V. Reset management will depend on the implementation of the stack, but the best implementations allow a node to simply reload network parameters from non-volatile memory and re-associate with the network after a power reset. Z-Wave is one of the leaders in low power consumption – System on chip with: • 20 mA in receive mode (with MCU running) • 20 mA in transmit mode (with MCU running; up to + 5dBm) • Low battery alerts Supports battery powered nodes and powered nodes, as the standard is optimised for low duty cycle regardless of power source. The standard supports gateway functionality, where a node (normally powered) can transparently transmit data from another node to a remote server or application. The optimised low power allows for frequent refresh of data to and from battery powered nodes. See the example in section 3.1. Since 2000, Wavenis development has focused on achieving the optimal compromise of ultra-low power consumption and long wireless range. Application level metering solutions for (and by) customers also play an important role in efficient end-point and power management. Programmable data logging and periodic transmission, plus smart sleep cycles, network synchronization and protection against “overhearing” in the wireless network contribute to optimising performance with respect to loads, distance and reliability. All Wavenis nodes in the network can act as repeaters for more remote nodes.

3.1

Z Wave

3.2

Bluetooth low energy

3.2

Wavenis

Page 97 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 3.2 Solution Wireless M-Bus Rating

Version 0_5

Notes/Explanation The Meter data are transmitted periodically. Data may used from every reception unit (e.g. Flat display), which own an encryption key. The transmission interval is scalable from minutes to one hour. In the case of radio link extension proprietary network solutions or standardised repeater can be applied.

3.2 3.2

ZigBee @ 868MHz ZigBee @ 2.4GHz I believe we discussed this in the forum and decided that the requirement was NOT for battery powered devices to be able to relay messages in a mesh network, rather to allow for some battery powered devices to be part of the network and participate occasionally, with long battery life (e.g. Gas Meters). To that end, Sleepy End Devices in ZigBee are a fully supported part of the specification and are routinely used in applications for light switches, thermostats, gas meters, etc. Such devices routinely achieve 10+ years of battery life, though of course this depends on the application requirements, how often the device communicates etc. For what it is worth, the ZigBee Alliance currently has a working group investigating low power routing (the ability to run an entire mesh network entirely on battery powered devices). We expect this to be added into the spec in the 2010 time frame at the earliest. However, it should be noted that it is not possible to achieve the same battery life with a low power router as it is with a sleepy end device because of the mechanism required to maintain a mesh network while also sleeping all devices. I can expand on this if necessary. • 1 μA in sleep mode (with POR, interrupts, and wakeup timer running) • Only standard with support of battery-to-battery networks • 30-80 μA average power consumption in battery-tobattery networks • No risk of early power source depletion due to WiFi interference Raw symbol data rate is 1Mbps. Short data packets can be transmitted robustly in a few milliseconds. Maximum sustained data rate is 200kbps, but sustained data transmission for any wireless product is not commensurate with battery powered nodes. In smart metering, data throughput itself is not a real issue. It may be when you start adding other home devices, but high data traffic requirements are at the opposite end of the spectrum from metering solutions, which only transmit packets occasionally (especially for water and gas). With mains power (electric metering) transmission speed can be bumped up. Assuming the

3.2

Z Wave

4.1

Bluetooth low energy

4.1

Wavenis

Page 98 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

Notes/Explanation requirements include long battery life and long range (or robustness over short range), then high-throughput is not necessary. Typically, Wavenis is used from 4.8 – 38.4 kbps, with 1/3 data redundancy. Based on 1s periodic time (Rx-Sby), Wavenis offers 1s latency at worst. In case of 3 hops, latency is 4s max 66kbs (T) or 16 kbps (S) PSDU data rate BPSK 20 kb/s OQPSK 100 kb/s Raw data rate between ZigBee 2.4GHz radios is 250kbps. Point to point with ZigBee messaging this works out at about 50kbps real data throughput. In a ZigBee network with messages travelling multiple hops, using security and end to end acknowledgements I would expect 15-20kbps real data throughput. For local communications in the UK, most of the networks will be relatively small, and most communications will be 1-2 hops. In this scenario I would expect real data throughput in excess of 2530kbps. Z-Wave supports a mix of 9.6kbps, 40kbps and 100kbps communication in the same network. This allows manufacturers to trade longer range for less throughput as the range decreases significantly as data rate increases. The effective data rate is up to 60% of the raw data rate due to very low frame overhead. Bluetooth low energy uses a number of mechanisms to ensure reliable data transfer, low latency and robustness to interference. It should be noted that these are separate issues that require separate answers. Reliable data transmission is provided by a 24bit CRC on every packet and 32 bit message integrity check on encrypted packets. Low latency is guaranteed by power optimised immediate retransmission and configurable retry and reconnection schemes. Robustness to interference is provided by the mandatory use of active frequency hopping. Wavenis includes mechanisms to successfully establish data connection on the first attempt, thus protecting battery life while reducing the need for retries. An alert is raised to the application layer after 3 unsuccessful automatic retries. Packets are acknowledged, and fast FHSS, data interleaving, data scrambling, Forward Error Correction with BCH (21, 31)

4.1 4.1 4.1

Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz

4.1

Z Wave

4.2

Bluetooth low energy

4.2

Wavenis

Page 99 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

4.2 4.2 4.2

Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz

Notes/Explanation coding and CSMA-CA make it possible to maximize data reliability and drastically reduce channel interference. Latency between 1 to 60 minutes for RF retry mechanisms are well defined by IEEE802.15.4 At an IEEE 802.15.4 MAC level, there is a clear channel assessment before sending a message, and there is a MAC acknowledgement and retry mechanism that allows for 4 attempts if the message does not get through. At an Application Support Sublayer (APS) level, a ZigBee application may use end-to-end acknowledgements and 3 attempts. In total this means that for any message sent that fails to get through, the ZigBee stack has tried 12 times to get this through over a period of up to about 4.5 seconds typically. Even with high levels of interference, this usually means there is no message loss, with a possible impact on latency (by design). In most implementations the application will get a callback to indicate success or failure of the message, whether using MAC acknowledgements only, or APS acknowledgements. Typical latency of a message one hop in a clear ZigBee network is <10ms (typical is more like 4ms). Timeout mechanisms allow for up to 50ms per hop before it is assumed a message has failed. The Z-Wave protocol implements standard collision avoidance and random back-off algorithms. Every message is governed both by a node-2-node acknowledgement and an end-2-end acknowledgement. Additionally the routing protocol automatically tries alternative routes should parts of the network be ‘offline’ 0dBm transmitter modules typically attain 300m open field range for good RF design. Adding a PA to increase power to around +18dBm and adding a LNA increases range to around 1km, but adds cost. Both values are essentially omnidirectional range. Better range can be obtained with directional antennae, but this adds complexity to the installation process. -113dBm sensitivity +14dBm output 127dB link budget Helicoidal antennas of -3dBi in metering devices. For small footprint casing in HAN devices (such as a CR2032 battery-powered light switch), a piece of wire is generally used.

4.2

Z Wave

5.1

Bluetooth low energy

5.1

Wavenis

Page 100 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

5.1

Wireless M-Bus

Notes/Explanation In addition, 868MHz band features 9dB less LOS attenuation vs. 2.4GHz. Also, 868MHz offers better propagation through walls and flooring materials. - 1mW: 80m indoor (industrial lighting control products) - 25mW: 30-300m in real world metering scenarios (underground, home, flat, building, commercial, industrial) - 500mW: few km for large area coverage with cost effective battery powered range extenders Range typically 25 m in Building -106 dBm sensitivity +14 dBm output power (non amplified) => 120 dBm link budget To use a small battery a meter typically applies +8..10 dBm chip output power. This will reduce current consumption from more than 70mA to less than 20 mA. Higher pulse current will significantly increase the price of the battery. Small antennas and bad installation conditions may reduce power on air by 3 to 10 dB. However this will cover typically two or three floor levels (depending on building), assumed that data rate is slow enough to support a sensitive receiver. 868 MHz reduces link lost by reflection, has less Free space attenuation than 2,4GHz (9dB) and less wall loss In very critical buildings it may better (cheaper) to use a wired or hybrid (wired/wireless) solution. PS: We are talking about indoor communication so I don’t attach a LOS-calculation! typ. range is factor 2.8 higher than 2.4 GHz, about 4.4 km for OQPSK and further increased for BPSK modulation, refer to ZigBee 868 MHz presentation This will differ between ZigBee vendors, as it depends on the receive sensitivity of the receiving radio and the transmit power of the sending radio. The best ZigBee chips have a receive sensitivity of -99dBm to -100dBm and a transmit power of +3dBm to +5dBm, which leads to a best-case unamplified dynamic link budget of about 104dBm. Theoretically this should deliver about 1Km line of sight in free space, however in reality this usually translates to between 400m-700m. Amplifying output to +10dBm, which equates to 10mW, the limit in Europe, this should increase the dynamic range to perhaps as much as 110dBm, and in reality delivers LOS range between 600m to 1Km. When not amplified Z-Wave chips support up to 100+ dB RF system budget at sub-1GHz (depending on data rate). This translates in to typical 60m-100m outdoor / 30m-40m indoor. Additional range can be obtained through the mesh network or through external amplifiers.

5.1 5.1

ZigBee @ 868MHz ZigBee @ 2.4GHz

5.1

Z Wave

Page 101 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 5.2 Solution Bluetooth low energy Rating

Version 0_5

Notes/Explanation Bluetooth low energy at 2.4GHz is no different to any other 2.4GHz radio. Actual range must be determined by field trials. The shorter wavelength of 2.4GHz compared with 868MHz gives it a small advantage where the antenna is housed within a meter enclosure, as the radio signal will propagate through smaller gaps or non-metallic areas of the housing. Ultimately range of a radio embedded within a meter is determined by the mounting and position relative to the meter casing. With a point-to-point range of hundreds of meters (line of sight), Wavenis has proven itself in harsh environments in large-scale metering networks deployed and operated by utilities around the world. This includes both devices with an external RF module, and those with Wavenis integrated “under glass”, used in dense urban areas (lots of apartments) and sprawling rural areas. FHSS techniques feature more robustness in case of multipath or signal fading, and FH spread spectrum ensures recovery of desired signals. Also, the 868MHz band is more efficient in term of propagation when compared to 2.4GHz. In case of short range requirements only, this lead to reduced output power, thus the ability to use smaller batteries, which leads to even more competitive pricing. Internal/external installation is a question of the meter housing and of the link budget. Building structure and installation environment generate an uncertainty of Link attenuation. This can only be solved by suitable Link budget. Ranking is comparable with Ref. 5.1. 868 MHz operation is much more robust compared to 2.4 GHz operation Typical range within UK homes is about 15-20m point to point. When powered nodes are available (like with smartplug-type devices which always have power) this allows any communication to be routed over multiple hops. Anecdotally, Alertme noted that 80% of homes did not require a repeater/router of any sort (all Communications point to point), with their coordinator node operating unamplified at +5dBm and their sensor nodes operating unamplified at +3dBm, both types of nodes using a suboptimal antenna. High RF system budget along with long range due to sub-1GHz communication. Strong Mesh extends the range through multiple hops. Successful 2500 trial electricity and gas installations in UK without ‘location issues’.

5.2

Wavenis

5.2

Wireless M-Bus

5.2 5.2

ZigBee @ 868MHz ZigBee @ 2.4GHz

5.2

Z Wave

Page 102 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 5.3 Solution Bluetooth low energy Rating

Version 0_5

Notes/Explanation Extremely good. Bluetooth low energy is a narrow band hopper which is efficient at pushing through wide band interferers. A narrow band interferer would be frequency hopped around. Adaptive Frequency Hopping allows for characterisation and mapping out of bad frequencies, so that the radio can dynamically adapt to a changing wireless environment. This helps to maintain performance as new wireless interferers are brought into the home during the life of the meter. The Bluetooth low energy radio is the most recent radio design in the field of short range wireless. It has been designed by RF experts from the mobile phone industry who have taken especial care to ensure that it works within the mobile phone environment, where it is collocated with other powerful sources of RF. Very strong robustness against signal interference due to fast FHSS (every 2 bytes), FEC, data scrambling, data interleaving and automatic retries. Use of 868MHz means using the very low duty cycle imposed by ETS300-220. No risk of 2.4GHz jammers. Radio traffic is regulated in the 868 MHz-Band by CEPT. Due to the small Bandwidth and small duty cycle, the collision rate is low. If a collision happens telegram can be requested again (Retry). handled by modulation scheme DSSS and supported by retry mechanisms While 2.4GHz is very popular for WiFi (IEEE 802.11.b/g/n), Bluetooth and other communications technologies, ZigBee coexists very well even when sharing the same channel with those other technologies. The best treatment of this subject available is the report already known to the ERA from Schneider Electric, and it concludes that ZigBee survives well even in very adverse (and very untypical) conditions. Some characteristics will differ from chipset to chipset, so can be assessed between competitors. Z-Wave uses the well regulated 868MHz 1% duty cycle band in Europe. No interference from WiFi and other high power 2.4Ghz ‘jammers’ AFH is the best solution for providing blocking immunity. Signal interference in the 2.4 GHz band comes from other devices like microwave ovens, street lighting, alarm systems and wireless communication systems. Bluetooth low energy can deal with all of these. Bluetooth low energy allows power control, providing robustness against a rising noise floor.

5.3

Wavenis

5.3

Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz

5.3 5.3

5.3

Z Wave

5.4

Bluetooth low energy

Page 103 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 5.4 5.4 Solution Wavenis Wireless M-Bus Rating

Version 0_5

5.4

ZigBee @ 868MHz

5.4

ZigBee @ 2.4GHz Z Wave

5.4

5.5

Bluetooth low energy Wavenis

Notes/Explanation Transparent recovery of lost packets. Increased probability of TX success on first attempt. This is also a significant contributor to power savings contributor. Consumption data are transmitted periodically. This protects temporary interference in channel. High transmission power, Modulation index and limited receiver bandwidth reduces effect of interference. In case of strong interference data has to be retransmitted at later time. The group felt that there could be issues with permanent or constant interference. Specified by IEEE802.15.4 in view of typical interference scenarios, higher robustness compared to 2.4 GHz operation. The group felt that there could be issues with permanent or constant interference. Subject to 5.3, IF a ZigBee network suffers from interference, there is a standard mechanism for moving the network to one of the other 15 IEEE 802.15.4 channels available at 2.4GHz. Advanced Frequency agility on a frame per frame basis without frame loss. Every Z-Wave node concurrently listens on two channels. The transmitter always selects the optimal channel for each message based on RSSI and adaptive mechanisms. This allows parts of the network to operate simultaneously at different channels thereby maximizing the communication success in even highly congested scenarios. We work in a small device next to a 1W transmitter a few kHz away. Mobile phones with GSM transmitters. Not a problem. Operation in 868MHz band with channel bandwidth of 50kHz @ 9,6kbps: - Blocking: 75dBc @ 10MHz - ACP (Adjacent Power Rejection): -37dBm @ 50kHz (in compliance with ETS300-220) - ACR (Adjacent Channel Rejection) : 16dB @ 50kHz & 30dB@ 100kHz (in compliance with ETS300-220)

5.5

5.5 5.5 5.5

Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz

Different Receiver classes are defined in EN13757-4. Class HR requires a blocking rejection of at least 40 dB to the adjacent channel. covered by IEEE802.15.4 specification and further MAC retry mechanisms This will differ from chipset to chipset, but all IEEE 802.15.4 radios have basic blocking immunity built in. For example, Ember EM250 has adjacent channel rejection at -82dB of 35dB and 2nd channel rejection of 43dB, with channel rejection for all other channels at 40dB, along with 802.11g rejection centred at +12MHz or -13MHz of 40dB. I do not have figures for other ZigBee chipsets.

Page 104 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 5.5 Solution Z Wave Rating

Version 0_5

6.1

Bluetooth low energy

Notes/Explanation All Z-Wave nodes are equipped with a SAW filter – efficiently shielding for signals outside the band (such as GSM phones). Additionally the Z-Wave receivers have a high blocking performance due to narrow band 2FSK/4FSK modulation Bluetooth low energy uses AES 128 with a 32 bit Message Authentication Code, using the counter mode technique as approved by NIST. It also incorporates the concept of private addresses, hence supporting more of the elements necessary for full FIPS compliance than any short range wireless standard. Data sent over the air via Wavenis is secured in multiple ways, making it totally impossible for an unwanted device to simulate a reader or capture data in an unwanted manner. Data encryption can be implemented as an option, using AES-128, DES, 3-DES More importantly, when requested by the application, all data exchange between devices in any given network is highly secured natively using a key exchange mechanism based on public, private, network and random keys. The result is exactly like a rolling key solution. Data is ONLY readable by products that are designed to be compatible, and products from competitors or nearby networks could NEVER interoperate unless by design. Even if data were “sniffed”, it would be totally useless (scrambled AND encrypted!). A random key is generated for every exchange, thus establishing the key to be used in the next exchange. These random keys can only be decrypted by devices using the right network-wide key. A product must have a compatible key to be installed into the network, or to read data from devices in that network. This, plus DES and/or AES security yields a highly secure solution. AES128 is defined by OMS for transfer of Data via RFLink as mandatory.

6.1

Wavenis

6.1 6.1 6.1

Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz
14

AES-128 (e.g. CCM*) as specified by IEEE 802.15.4 for the MAC and ZigBee for the network layer There are a number of layers of security in ZigBee. a) First, ZigBee encrypts all packets sent at a network level using AES-128 bit encryption and a 128-bit Network Key. This is a very robust encryption mechanism for this type of networking. This network key is established by the trust centre when the network is being formed, and is rolled over periodically.

ZigBee @ 868MHz should, in theory, have the same security foundations as 2.4GHz. However, it was felt by the group that these were as yet untested, hence the lower rating for 6.1 & 6.2

14

Page 105 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

Notes/Explanation b) ZigBee also specifies a Trust Centre Link Key, which is used to encrypt communications with the trust centre. This is different from the network key. c) Any two nodes in a ZigBee network may request from the trust centre an APS Link Key, which they can then use to encrypt packets at an application level. Using this mechanism, two nodes can send encrypted data through the mesh network without intermediate nodes being able to read the payload. d) ZigBee Smart Energy application profile specifies the use of ECC (Elliptical Curve Cryptography) to establish link keys between devices. This is a best in class mechanism for establishing keys and includes the use of digital certificates assigned to the unique IEEE (MAC) address of each device in the network. Items (a) and (b) above would be used in any ZigBee application. (c) and (d) above could be used by GB smart metering and would be highly recommended. ZigBee supports using an alternative key establishment mechanism as (d) instead of ECC. I think it is clear that ZigBee provides the most secure mechanisms available for wireless mesh networks. Z-Wave provides a two tier security solution both based on AES128. The Z-WaveSec provides a plug & play functionality with in-band key exchange. This solution can be used for secure non-personal data exchange. The Z-WaveIPTLS is based on the well known IP TLS technology (used in all internet payment systems today). This solution should be used for secure personal data exchange Every connection generates a new session key. Session Key is derived using inputs from both devices. Authentication is done against an encryption root that is 128 bits long. Wavenis implements a rolling key mechanism based on network, private and random keys. “Checked” random keys (to eliminate obvious and “easy keys”) are issued at each data exchange, and modified to determine the key for the next exchange. Please see answer for 6.1. Yes, on request (symmetric) key establishment, maintenance, and transport are specified by ZigBee network layer, Key generation may be further controlled by APS layer As stated in 6.1 above, rolling network keys are supported and used by ZigBee. Key renewal is a part of the Z-WaveIPTLS solution

6.1

Z Wave

6.2

Bluetooth low energy Wavenis

6.2

6.2 6.2 6.2 6.2

Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz Z Wave

Page 106 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 6.3 Solution Bluetooth low energy Rating

Version 0_5

Notes/Explanation As recommended, this should be done at the application layer, not at the physical layer. The gateway functionality of Bluetooth allows multiple remote meter nodes to connect and send data to a remote application via the primary node without that primary node having access to the data. This feature may be of particular interest where different meters are reporting to different utilities, as the data can be securely partitioned. This feature can be controlled by the remote application, allowing utility transfers to be remotely controlled. With protection for each network installation (via specific installation keys), as well as every exchange between devices, data is utterly indistinguishable without the right keys. Unwanted data is ignored. Every transmission of data via RF is encrypted. Consumption data are transmitted periodically to the Gateway (MUC). Access to MUC-Data points needs special access rights. Other data requested direct to meter needs Authorisation for the command. For exchange of Commands, asymmetric ECC should be applied to sign a command. It is intended also to sign transmitted consumption values by ECC to support offline tariffs. security architecture supports use of link keys to secure individual links, already specified by ZigBee Using 6.1 (c) above in conjunction perhaps with (d), every node in the ZigBee network could be assigned a different link key to talk to the devices it needs to talk to. This link key is not known to other devices in the network and so cannot be used to decrypt data except by the destination node for messages. In addition, if full ECC is used, each device would have its own unique digital certificate which can be used to further secure the communication and identify the device uniquely to its target network. So, separating 3 different suppliers in one home is easy. The Z-Wave AEC allows for any mix of secure and nonsecure communication. This allows for very cost effective implementations. The AEC framework furthermore uses separate security material (keys and certificates) for individual utility suppliers (also in the event that a product is hosting/displays two different utility supplier data) Yes. This is commonly used in existing Bluetooth applications. It is an implementation feature and not a part of the core standard – this is true of all of the standards being considered. For robust OTA operation, all wireless standards require sufficient flash memory for the full download to be stored no that it can be verified before the previous image is overwritten. This will increase the cost for

6.3

Wavenis

6.3

Wireless M-Bus

6.3 6.3

ZigBee @ 868MHz ZigBee @ 2.4GHz

6.3

Z Wave

7.1

Bluetooth low energy

Page 107 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

Notes/Explanation most wireless standards. It also requires that the silicon chosen supports the protocol stack in flash and not in ROM. It is important that security is considered within the context of OTA to ensure that the download is validated Bluetooth chips typically use 1024 bit RSA hashes to ensure the authenticity of the new code before running. Over-the-air upgrades can depend on the finished radio board. The upcoming SoC supports high-volume (automated) field upgrades. Maintenance upgrades can be conducted on-site by a person using a PDA (which switches the end-point to low-range mode, and increases it to fast transmission mode (up to 100 kbps) in order to keep battery consumption to the minimum. In the SoC, a hardware area is reserved for the boot loader. The stack handles reception of new firmware, verifies it, and informs boot loader to replace old firmware with new. Software update is critical regarding the approval of meter software. If the communication module runs on another µC it may be easily possible. But typically the metering application and communication runs on the same stack. It has to be certified that a software update will not affect metrological software. However it is intended to support the change of part of the software in the meter together with authority in the next step. yes, over air update is supported Not all ZigBee vendors support over the air upgrades for firmware on the ZigBee node, but the leading vendors all do. In most cases there are options for upgrading the stack and the application and in many cases these bootloads can be done remotely and via multiple hops. Note that this usually requires a second program to run on the ZigBee node, to act as a bootloader. Some other technologies that run on very small microcontrollers do not have enough code space to have a separate bootloader program included. Standardized Z-Wave firmware upload is available This depends on the security level. Core security is defined by the Bluetooth standard. As long as upgrades do not require additional hardware they can be upgraded. Application specific the security algorithms should be specified at the application level, and therefore this would be possible as part of a normal upgrade process.

7.1

Wavenis

7.1

Wireless M-Bus

7.1 7.1

ZigBee @ 868MHz ZigBee @ 2.4GHz

7.1 7.2

Z Wave Bluetooth low energy

Page 108 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 7.2 Solution Wavenis Rating

Version 0_5

Notes/Explanation Security algorithms usually depend on application requirements. Security is generally addressed on 3 levels: PHY + MAC layer (Wavenis combines FHSS, FEC, data interleaving and scrambling) + authentication mechanisms + data encryption algorithms. Most sensitive applications require authentication with sophisticated random rolling codes (combination of rolling public & private keys) with encryption coding such as DES, 3-DES or AES, or other. Both enhanced authentication mechanisms and encryption algorithms can be upgraded via over the air programming services as described in 7.1. See Ref. 7.1 security architecture is specified by ZigBee spec., any upgrade is subject to ZigBee specification Some ZigBee devices (such as Ember EM250, TI CC2430) include a hardware encryption engine, which may or may not be used by the firmware, however in any case, all encryption is done at the network layer or above, so is done in software, so if you wanted to change the encryption mechanism you could do so by replacing the application firmware. All other modifications to security in the ZigBee stack or application could of course be made via an over-the-air upgrade. Same as item 7.1 Bluetooth devices shipped today still work with devices shipped 8 years ago. Backwards compatibility is a key requirement that is tested before any specification can be released. The same philosophy is being applied to low energy. The most recent Wavenis devices with enhanced features (synchronized network) are backward compatible with the 1st generation Wavenis with nonsynchronized network shipped in 2000. M-Bus is carried since 1997. There are active Working groups continuing work on this standard. RF-Solution was released in 2005. The Open Metering Working Group selected S-Mode and T-Mode only (S1m are excluded). The long preamble sequence of S-Mode allows alternating scanning of both channels in time. For a reception unit, both Modes should be supported.

7.2 7.2 7.2

Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz

7.2 7.3

Z Wave Bluetooth low energy15 Wavenis

7.3

7.3

Wireless M-Bus16

Whilst the proven principles of the Bluetooth SIG support backwards compatibility, the introduction of low energy will break this – i.e. existing devices will not interoperate with ‘low energy only’ devices 16 The group expressed concerns that there are compatibility issues within the M-Bus standard – ‘S’ and ‘T’ types do not interoperate

15

Page 109 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 7.3 7.3 Solution ZigBee @ 868MHz ZigBee @ 2.4GHz Rating

Version 0_5

Notes/Explanation yes, ensured if required, refer to IEEE802.15.4 and ZigBee by defining appropriate control bits, e.g. “ZigBee Protocol Version” Subject to a significant change to something like security (per 7.2), and any application level changes which are totally under the control of the developer, ZigBee ensures backward compatibility in its networking stack and application profiles. Sometimes criticism is levelled at ZigBee for not being backward compatible, and certainly between ZigBee 2004 and ZigBee 2006 there were some one-off changes made that broke backward compatibility. However, this decision was not taken lightly, and at that time there were no commercial products that had been certified to ZigBee 2004, so it was OK to make such changes without impacting any products in the field. In general, at the point at which some product is certified to a particular ZigBee standard or application profile, all future work on that type of device or that profile, must be backwards compatible. All Z-Wave products to date are backward compliant. This has been proved through 4 software and ASIC generations. There is sufficient deployment of 2.4 GHz products, that it is unlikely that there will be any short or medium terms changes to its availability. Once the SRSM specification is complete, representation should be made to OFCOM to ensure that it is preserved for the lifetime of smart energy meters. Bluetooth is robust against all the interferers within this band, including non-standards based solutions like X10 video transmitters Wavenis uses 868 MHz in Europe. Will adapt to extension of this band (as being suggested by European standardisation bodies) as required (extension is 863-873MHz) 868MHz band is carried by many industries, which take care about this Band. Frequency Management Working group continues maintenance of this band. 868 MHz band dedicated to ISM usage, potential to be expanded It is difficult to comment on this, as it is always an unknown. However, 2.4GHz has established itself with a number of technologies and so should be available as an unlicensed band into the future. Given the support for ZigBee 2.4GHz by silicon vendors, major electronics manufacturers etc., it would appear that the frequency is here to stay. If anything, as WiFi moves up to 5GHz, the frequency may prove more popular for wireless sensor networks over time.

7.3 7.4

Z Wave Bluetooth low energy

7.4

Wavenis

7.4 7.4 7.4

Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz

Page 110 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 7.4 7.5 Solution Z Wave Bluetooth low energy Rating

Version 0_5

Notes/Explanation The 868MHz band has been adopted by all CEPT countries Bluetooth has shipped 2.5 billion devices, and is still growing its volume. A market that requires this many chips will not disappear overnight. No other technology will take its place in phones, as the number of radios in a phone is constrained, and Bluetooth is already in there. The first generation of Bluetooth silicon chips have not shown field failure in 8 years of operation. They have been qualified for and are in use in automotive and medical applications which require a minimum of 7 years operation and MTBF in excess of 30 years. Latest generation of Wavenis-based battery-operated metering solutions features 20 years autonomy with legal commitment. The Wavenis-OSA creates all the conditions to ensure longevity of the technology itself. Single Transceiver applied (no special chipset required). Technology is available as long as Frequency band will be available. Yes Again, given the support for ZigBee by silicon vendors, meter manufacturers and others, it is clear that ZigBee is around for the long haul. The ability to upgrade over the air means that it would be possible to add new features to applications and maybe even to the stack if necessary, and so keep the devices in the field up to date with the latest innovations (if that was desirable, depends on upgrade strategy). ZigBee offers very strong security, and more bandwidth than is needed for smart metering, so it can survive future requirements. Even if ZigBee were to disappear (and that is most unlikely), or if another more suitable IEEE 802.15.4based technology were to emerge in future years (also unlikely), all of the ZigBee chipsets are IEEE 802.15.4 compliant, and most can be upgraded over-the-air, so it would be possible to upgrade from ZigBee to some other wireless networking stack at that point.

7.5

Wavenis

7.5 7.5 7.5

Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz

7.5 8.1

Z Wave Bluetooth low energy Bluetooth low energy is designed for mass market, cost sensitive applications. Silicon costs for 100k volumes are expected to be at the following levels for 2010, falling in future years Electricity meter: <$2 Gas / Water: <$2 Display unit: $0 (it comes for free with mobile phone !!!)

Page 111 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating Notes/Explanation Display Unit: <$2.

Version 0_5

Additional costs are an antenna, a few passive components and a battery. Pre-approved modules containing all of the required components and functionality should be available for less than $10 at 1 million pieces. It is important to consider the finished solution, not just the chipset price. For example, per unit sales price for a Wavenis metering end-point: PCB + CPU/RF/memory, mounted and tested + battery + antenna + sensor connection : <€10 for 100k units Home display Unit : around €30 RF-Chip 1,40 $ (@10k today) RF-Module 2,00 $ (w/o battery + µC) Battery (RF-only) 0,5Ah Battery (Gas meter incl. valve) 2,5 Ah= ca. 3,00 € (@10k today) price competitive to ZigBee 2.4GHz and also other 868 MHz implementations This is difficult for a vendor to answer, as the cost to the utility includes much more than just some ZigBee chips, there is a lot of value add by module manufacturers, meter manufacturers etc. However if we look only at chip costs, then across the multiple vendors; a) For 1 million of units, ZigBee chipsets today cost typically between about $2.50 and $3.00. b) ZigBee modules including PA to +10dBm, with FCC and CE approval, in million unit quantities can be obtained for between $7-$10. We expect the chip prices to come down to about $1.50-$2.00 by 2012, and module prices by then to be <$5. • $2.00-3.00 for SoC in high volumes • $3.00-4.00 for complete module in high volumes • Lowest cost in the market, thanks to Compact FSK technology Compact protocol stack sizes • Modern single chip implementation in either 180nm or 130 nm CMOS • Sustainable cost benefit due to much higher complexity of competitors No known failures of Bluetooth devices in the field due to Bluetooth chip recorded in last 8 years. Of the 2.5 million units deployed at this time, only 0.02% of finished products have been returned for postsales service. No separate figure on chipset failure is available.

8.1

Wavenis

8.1

Wireless M-Bus

8.1 8.1

ZigBee @ 868MHz ZigBee @ 2.4GHz

8.1

Z Wave

8.2

Bluetooth low energy Wavenis

8.2

Page 112 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 8.2 8.2 8.2 Solution Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz Rating

Version 0_5

Notes/Explanation Depending on chip solution. Our experience of Chip error rate is <0,005% per year. depends on final system solution which is not under control of Chip providers, Radio/MCU IC’s are proven for MTBF >>10 years This is another metric that needs to be assessed on a vendor by vendor basis, however most ZigBee chipsets should be up to the requirements. Most chips are on well proven processes and manufactured in reputable fabrication plants such as TSMC in Taiwan, probably use mostly the same flash and RAM components, so for the most part they will deliver similar levels of reliability. MTBF and other calculations of this nature are done using HTOL testing on samples of devices over 1000’s of hours at higher temperatures (usually 125 degrees C) than the devices are normally used, to simulate longer term usage. Using this technique, even recently released chipsets can have a very high calculated MTBF from relatively short test periods, and the confidence level for that value increases as more testing is done over time. For example based on this type of testing, EM2420/CC2420 has a minimum expected life of 10 years at 58 degrees C. Chip < 90FIT None currently with low energy. Commercial Products expected in 2009. Wavenis was first deployed as a wireless solution for walk-by metering, and has been used in smart metering systems (with remote 2-way access, programmable bubble-up, alerts, etc.) for the past several years in places such as China (China Gas) France (Les Sables d’Olonnes, Paris) Spain, Slovenia, and North America (CA). Some of these networks also include wireless inhome displays for consumers. Applied since 2004 for several million meters. There are some small scale trials using ZigBee@868MHz in metering – an example would be its’ use in a smart gas meter trial in Spain. ZigBee has been selected for use in smart metering deployments in Texas, California, Virginia and Detroit in the US, Victoria in Australia, and Gothenburg, Sweden. It has also been used in successful trials in Spain, as well as being included in the recent EDRP trials in the UK by some of the ERA members. Gothenburg has now got about 60,000 meters live, expecting to complete roll-out to 270,000 meters by the end of 2008. Other large trials and deployments in the US have already been documented in this forum (see

8.2 9.1

Z Wave Bluetooth low energy Wavenis

9.1

9.1 9.1 9.1

Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz

Page 113 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating Notes/Explanation my presentation of 2nd Sept).

Version 0_5

9.1

Z Wave

9.2

Bluetooth low energy Wavenis

In the UK, PRI already uses ZigBee in its prepayment meters. • 2500 home trial in UK. • Installed in 1000+ smart metering application by Modstroem in Denmark. • Used in sub-metering and Energy Conservation applications by DEST in Denmark along with many OEM partners None currently with low energy. Commercial Products expected in 2009. Over 2 million Wavenis smart metering solutions are up and running today. Other applications include home Automation (door lock, alarm, lighting, temp control), Industrial Automation, environment, medical, Track & trace (active long range UHF RFID) and in-home displays. Same RF-Interface applied in Home automation (Konnex) yes, IEEE802.15.4 / ZigBee are developed to be used e.g. in metering applications, application profiles are especially designed for meter applications ZigBee is used in a wide variety of applications including some that are very similar to the sort of networking needed for smart metering; some examples of the variety of applications include; marine safety (see http://www.raymarine.co.uk/products/lifetag/), industrial ball valve control (see www.eltav.com), home security (see www.alertme.com), energy monitoring / management (see www.plugwise.com), home automation (see www.control4.com), commercial building automation (see www.tac.com) and fire and safety (see www.byterg.ru). Some of these applications are similar to GB smart metering requirements, but even where they are not, the sort of networking involved is fairly typical of networks in UK homes or in AMR/AMM solutions. Focus on home control / Unified Home Control is a major strength Bluetooth has only released three version of the standard in the last seven years, all of which are backwardly compatible. The Bluetooth low energy release will be the first version of this new standard, but care is being taken to ensure that it will be compatible with all future releases. New features to the core standard are only made after substantive review of their necessity, the commitment of the market and a guarantee of backwards compatibility.

9.2

9.2 9.2 9.2

Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz

9.2 9.3

Z Wave Bluetooth low energy

Page 114 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 9.3 9.3 9.3 Solution Wavenis Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz Rating

Version 0_5

Notes/Explanation New revisions offer a superset of previous versions, thus providing backward compatibility over time. Latest major revision (2008) now being deployed in Europe. Revision next 2 years! Thereafter stable for next 5 years IEEE802.15.4 / ZigBee specification are permanent under control and development, e.g. specific application profiles to optimize to customers needs, refer to ZigBee Alliance There are no planned upgrades to the ZigBee networking standard in the next 2 years, and beyond that, none that GB smart metering would require out of necessity. The ZigBee Smart Energy Application Profile will be updated later this year to include feedback from field deployments in the US and new requirements from Australia. It is anticipated that GB smart metering would also have some amendments and would make sure that the ZigBee Smart Energy spec is sufficient for needs before deploying, so therefore no requirement for upgrades for ZigBee specification reasons after that, unless the UK specifies them. Very high maturity of chip and protocol Used in over 300 products – Available for more than six years Proven for interoperability and backward compatibility 4th generation system-on-chip solutions and 5th generation software Bluetooth silicon vendors currently ship in excess of 1 billion chips per year. There is no issue in supporting the requirements of the meter market. Module vendors manufacture several hundred million modules per year, so extensive production capacity and production line RF test equipment is already available and scalable. Bluetooth cannot comment on the capacity of meter vendors to meet this demand. Multiple chip vendors, multiple providers (manufacturers/integrators) of metering solutions. Many manufacturers have basic solution now. They have to adapt new features (e.g. Replace DES by AES) final system / meter not under control of Chip providers Most of the ZigBee vendors are seasoned silicon manufacturers, and already producing chip volumes well in excess of those required for the UK smart metering rollout. Others are fab-less and use very large and reputable fabs like TSMC and IBM, where capacity is certainly not an issue.

9.3

9.3

Z Wave

9.4

Bluetooth low energy

9.4 9.4 9.4 9.4

Wavenis Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz

Page 115 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Solution Rating

Version 0_5

9.4 9.5

Z Wave Bluetooth low energy

Notes/Explanation It is anticipated that each individual ZigBee vendor would have to satisfy this requirement as part of any tendering process. Zensys is direct partner with TSMC and ASE allowing for very high volumes 2nd source silicon in 2009 Phones are the most interesting opportunity to interact with smart meters by acting as remote controls – pushing information from meters to phones. They could become a powerful tool in providing a compelling application to get people to see their usage on a daily, hourly or instantaneous basis. Television sets, set top boxes and remote controls are participating in driving the development of the low energy standard, so these provide additional options for user interaction. Low energy Bluetooth will also be incorporated in computers and similar consumer electronic devices, all of which can play a part in controlling and displaying the status of the smart energy home. Home display devices, thermostats, lighting control systems already on the market. Wireless M-Bus is part of Konnex (Home automation). Home display, thermostats etc. available in Konnex. A number of meter and smart home products are available, however these have not been certified by the ZigBee Alliance. Many ZigBee Smart Energy products and ZigBee (nonSE) products on the market today to satisfy the requirements of ZigBee deployments in the UK; Meters: e.g. Itron/Actaris, Elster, Landis+Gyr, PRI, GE/Nuri etc. In-home displays: e.g. PRI, Tendril, Control4, many others coming Thermostats: e.g. Comverge, Computime, Golden Power (RiteTemp). Smartplugs: e.g. Plugwise, Alertme, Tendril, others coming… Very strong - Z-Wave Alliance with more than170 members and 300 products Table 20 Evaluation Notes

9.5 9.5 9.5 9.5

Wavenis Wireless M-Bus ZigBee @ 868MHz ZigBee @ 2.4GHz

9.5

Z Wave

10.5 Evaluation Scenarios
As part of the Local Communications Development activity, it has been suggested that further evaluation of the solution technologies could be undertaken using ‘Use Case Scenarios’ for initial field testing. Each of the solutions could be tested against a small number of ‘real world’ scenarios for performance when delivering typical smart metering activities: - smart meter to smart meter data exchange Page 116 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development -

Version 0_5

smart meter to in home display data exchange smart meter to Local Device (e.g. smart thermostat, microgeneration unit) data exchange

When considering interference, this would be the existing level of wireless activity – average could constitute WiFi + DECT + 2 Cellular Phones, harsh could include proximity to a TETRA radio pad. An example of this approach is shown below
Premise Size: 3 Bedroom, 3 Reception, Domestic Semi-Detached House, 100sqm Level One Two Three Four Five
Table 21 Evaluation Scenario Suggestions

Wall Type Brick Foil Insulated

Meter Locations External, adjacent External, remote Internal, adjacent

Interference Average Average Average High Harsh

Page 117 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

11 Conclusions & Recommendations
11.1 Conclusions
Primarily, it should be noted that all participants in the group and the preparation of this report have been positive about the contribution the process has made to their understanding of the subject, the requirements and the options. The ERA and the SRSM project team are grateful to all participants for their contributions and the spirit of co-operation throughout the process. The solution ‘providers’ within the group certainly understand more about the particular requirements of potential customers in energy metering and related devices, and those customers are equally more aware of the options and opportunities these solutions present. The process has moved all participants forward to a point where the requirements and solutions are converging. It is clear from the work of the group that it is possible for the requirements for Local Communications for smart metering to be met by technologies available today. Although necessarily a ‘desktop’ exercise, progress has been made in identifying and agreeing principles and requirements, potential solutions and related considerations. This should provide a solid foundation for any subsequent work in this area, and it is particularly evident that every one of the solution options, as an interoperable low power radio, could be capable of delivering a Local Communications standard for smart metering in Britain.

11.2 Recommendations
The group recommends that its’ work be continued in a timely manner, under whatever framework is determined to deliver smart metering, in order to make use of the wealth of information contained within this report. Given suitable authority and resources, a solution for Local Communications should be chosen as soon as can be done with the correct level of confidence. Participants in the potential smart metering and smart energy markets are waiting for a definitive answer to support the development of new products that would incorporate the appropriate silicon in meters and other devices. A great deal of the supporting information required to support the selection of a solution is contained in this report. Chief amongst the recommendations would be to continue the evaluation process by undertaking the test and review process detailed in section 11.3 below. The desktop evaluation exercise has gathered a great deal of valuable information that should form a solid foundation to refine the evaluation criteria to allow the key differences between solutions to be identified and assessed.

Page 118 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

The process has been successful in creating a network of interested stakeholders, and has, by being a public exercise, attracted a wider audience, including international participants. The group would recommend that any further work be similarly ‘open’ in conducting proceedings, with suitable arrangements for ‘blind’ testing and recognising the sensitivities associated with the suggested panel review process. It has been evident that more work is required to understand and document detailed user requirements for Local Communications for smart metering. This will be a challenging activity, as this is a new area for energy retailers and meter manufacturers, particularly within an ‘interoperable’ environment as required for smart metering. This does not need to be a very detailed piece of work, but clarifying some of the potentially ambiguous areas would be beneficial: • Detailed assessment of how energy retailers anticipate utilising the Local Communications solutions to support new energy services propositions, and how these might differ from the accepted and understood paradigms of consumption information display and tariff signals • Local Communications operating as a proxy/link for WAN Communications activities – for the Last Mile or for a Meter Operator HHU • Distinguishing between utility or energy usage of Local Communications and the HAN, particularly how this would relate to control and security within these networks • Duty cycles for gas meters for display information. Understanding how often a battery based device is required to transmit data will assist with understanding the potential battery costs When commencing this exercise in January 2008, it was envisaged that some guidance on the market model for smart metering in GB would have been forthcoming, which could have clarified the possibility of low power radios being utilised as part of the WAN Communications infrastructure for smart metering. Throughout, this ‘Last Mile’ potential has therefore been kept slightly separated from the Local Communications Group activity looking at supporting interactions within a home, as it could have been rendered redundant under particular market models. At the time of preparing these recommendations, the market model discussions continue. Therefore, the materials that have been prepared for Last Mile consideration have been moved to an appendix of this document, with a recommendation that they be considered in the event of a market model decision that could accommodate the use of a single radio in smart meters to talk to the home, and to remote parties. Finally, any subsequent evaluation exercise on this subject needs to recognise the publication date of this report and the fast pace of development in this area. Technologies are emerging and developing that could be considered as potential solutions, a prime example given at the group is 6LoPan. The longer this report sits on the shelf, the greater risk that things could have moved forwards significantly. The solutions themselves, or the evaluation Page 119 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

criteria could change materially, for example the potential to use Local Communications solutions for Last Mile.

11.3 Testing & Evaluating Criteria
Table 22 shows how the Local Communications Development Group recommends evaluation and testing of the individual criteria. Three ‘broad’ types of evaluation are considered: • Field test; use of the Local Communications solutions in a metering context in typical metering environments, preferably using actual metering products. The tests should be designed by experts familiar with both radio communications issues and metering, and should take the form of ‘real world’ tests. • Laboratory test; formal scientific testing under laboratory conditions to be undertaken by an independent body, including methods such as analysis and simulation. • Panel review; a number of criteria are linked to strategic developments, commercial arrangements and other parameters that cannot be effectively measured using field or laboratory testing. In these instances it is recommended that a representative panel be formed from interested stakeholders who are not necessarily radio communications experts, who would conduct a series of one-to-one reviews with representatives of the Local Communications solutions. In all cases these activities should be undertaken by participants independent from the solutions being evaluated. The group has discussed the potential to engage with academic institutions to support the field and laboratory testing. Following the evaluation discussion within the group it was felt that additional evaluation criteria should be added to the set for any subsequent activity. These are highlighted in the table below. As can be seen from the issues with the small test conducted by members of the group (appendix C), any field test needs to be meticulously planned and is an exercise not to be underestimated. It was noted by the group that several smart metering initiatives have conducted similar evaluative and comparative testing of low power radio technologies, and where possible their findings should be included and/or referenced in any GB specific report. These tests are not, as shown, intended to be necessarily exclusive – criteria could be the subject of field testing and a panel review. Wherever relevant, additional information from the group has been added as footnotes to this table.
Ref Criteria 1.1 Low level of energy customer intervention/support required to Field Test Y Lab Test Panel Review Not tested

Page 120 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Criteria 1.2 1.3 maintain communications Ease of installation – i.e. discovery at meter installation Minimise number of site visits to address local communications issues – i.e. recovery or remote correction on failure/upgrade failure – will include MTBF and power consumption on meter battery as considerations Development tools to support smart metering and smart energy market Ease of integration into metering/home products – e.g. system on chip, antenna size Scope/receptiveness to accommodate specific GB smart metering requirements Status as an Open Standard – accessibility, defined standards, range of participants, proven certification process Support for choice of data exchange format Genuine choice and competition between silicon vendors Interoperable chipsets Effort required to update standards to meet specific GB requirements (less effort = higher score) No. of nodes supported for each HAN, assuming minimum capability of 3. Consumption/Peak Current/Power Failure Management17 Support for battery powered nodes, but also for energy smart metering application (e.g. data refreshes in minutes rather than hours/days for end nodes) Transmission speed – effective data throughput in kbps per channel18 Field Test Y Y Lab Test

Version 0_5
Panel Review Not tested

Y

1.4 1.5 1.6 2.1

Y Y Y Y

2.2 2.3 2.4 2.5

Y

Y

Y Y

2.6 3.1 3.2

Y Y Y Y Y

Y

4.1

Y

Y

17

Will need to understand the power consumption in sleep mode for lab testing, or, alternatively - milliwatt for range achieved Notes on testing 4.1: - faster isn’t necessarily better, throughput/”speed” depends on usage/range Page 121 of 140 5-Nov-08

18

SRSM and Beyond – Local Communications Development
Ref Criteria 4.2 Robustness (retry mechanisms, acknowledgements, minimised/nil message loss – i.e. latency and dropped packets) Typical range (amplified or nonamplified)19 Suitability for GB meter locations (consider internal/external, stone/concrete, metal meter cabinets, meter rooms etc.) Vulnerability to signal interference20 Ability to cope with signal interference Blocking Immunity in transceiver21 *NEW* ‘Good Neighbour’ test – the solution should not materially affect other networks Strength/resilience of methods used Ability to use rolling/successive keys Support for distinguishing public/private data, and for keeping gas/water/electricity data independently secure – i.e. supports 3 different suppliers for 3 utilities (and any other authorised party data secure) Support for “over the air” upgrades of ‘smart meter’ nodes – i.e. gas + electricity meters & in home display Support for security upgrades Support for backwards compatibility Longevity of frequency Longevity of solution technology (minimum expected smart meter Field Test Y Lab Test Y

Version 0_5
Panel Review Not tested

5.1 5.2

Y Y

Y Y

5.3 5.4 5.5 5.6 6.1 6.2 6.3

Y Y

Y Y Y

Y

Y Y Y Y Y Y

Y

Y

7.1

Y

Y

7.2 7.3 7.4 7.5

Y Y

Y Y Y Y

-

throughput will vary by network configuration, testing should be comparative (point to point) using a standard 1kbit package over a fixed range (30, 50, 100m)

Range will depend on power used/specific chipsets, antenna design etc. Could test for penetration rather than, or as well as, range? Standard tests could include Received Signal Strength Indicator (RSSI), Packet Error Rate (PER) 20 the ‘interfering’ devices should be defined 21 Will be very much silicon vendor specific, lab test/field test should include increasingly common problem causing equipment, such as RFID readers Page 122 of 140 5-Nov-08

19

SRSM and Beyond – Local Communications Development
Ref Criteria 8.1 Field Test Lab Test

Version 0_5
Panel Review Y Not tested

8.2 9.1 9.2 9.3 9.4

9.5

A criterion which has been suggested for inclusion, but which may be contingent upon the definition of the user requirements, relates to separating different applications. “6.4 – Architecture to separate applications and data” A reference is available in section 13 below which covers this particular area, and whilst the reference is ZigBee specific, it was acknowledged by the group as being applicable to all of the solutions being considered.

asset life of 10-15 years) Total cost per home – 1 x electricity meter, 1 x gas meter with battery, 1 x home display unit = 3 chipsets + additional battery cost Mean Time Between Y Failures/Reliability Use in equivalent smart metering deployments Use in analogous applications Expectation of ongoing required upgrades – i.e. v2009, v2011 (fewer = higher score?) Capacity in vendors to meet smart metering demands (meters plus displays and other devices) – assume 5 year deployment to 25 million homes Availability of non-metering products that could be relevant to smart metering – e.g. thermostats, display devices Table 22 Evaluation Testing Recommendations

Y Y Y Y Y

Y

11.4 Solution Summary Statements
As part of the development of this report and these recommendations, it was felt that it would be beneficial to provide an independent view from the SRSM project team on each of the Local Communications solutions under consideration. These statements are intended to reflect a general view of each of the solutions, with particular regard for the current suitability for consideration for use in the potential GB smart metering market and where improvements are required to meet key technical requirements. In no way do these statements constitute recommendations or statements of intent by the group or ERA members, they are intended to provide an independent snap-shot of the current position.

Page 123 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

11.4.1 Bluetooth low energy
Bluetooth low energy has been a different consideration for the group from the other solutions. Bluetooth is obviously a global success and the opportunity to include smart metering in such an extensive and established eco-system of interoperable devices is very intriguing. However, it has appeared that Bluetooth low energy is still some way from being available to test – Q1 2009 has yet to be confirmed. Further doubts have been raised by a number of participants in the group as to the actual performance characteristics and power consumption, and therefore suitability for consideration for smart metering. These doubts can only be addressed by testing actual products. Given this status the current assessment of Bluetooth low energy has been generically classified as “No Information Available”.

11.4.2 Wavenis
Wavenis is a successful solution for metering already, particularly for the Last Mile, with a strong evidence base of installed European utility meters. From the desktop exercise and the group meetings, it looks to be a very technically accomplished radio solution, offering range and security at low power. The newly established Wavenis OSA is also a positive move towards open standards and interoperability, but this is quite a recent development. It is also the case that Wavenis does not currently have a smart meter specific ‘profile’ similar to ZigBee Smart Energy, preferring to let customers develop specific applications using the Wavenis radio. This is not a ‘good fit’ with the principles for GB smart metering, where adoption of an end-to-end solution is preferred to development. Further, it has not been apparent that there is an established market of peripheral Local Devices, such as a range of home display units or thermostats, as you can find with some of the other technologies.

11.4.3 Wireless MBus
The MBus solution offers a number of key positives; - it is the preferred solution in a number of large European markets - it is also closely tied to key European solutions, such as DLMS, KNX etc. - it is an international standard, and there are metering and related products available now from EU meter manufacturers However, there are a number of points to consider; - it is not well understood by the majority of GB energy participants with an interest in smart metering - the interoperability with KNX devices is not clear, as this may prove to be a significant positive if an existing European market of potential Local Devices would be available for use in Great Britain - there are a number of different and incompatible standards at varying stages of development which complicates the assessment of its applicability for an interoperable 2 way Local Communications interface - it is going through a key development cycle, and the objective/potential outcome of this activity is also unclear Page 124 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Each of these points can, and should be addressed in order to ensure that MBus is considered equitably with the other solutions.

11.4.4 ZigBee @ 868MHz
ZigBee @868MHz appears to offer the potential for the ‘best of both worlds’ – operating at what has generally been perceived to be the quieter and more ‘meter-appropriate’ ISM frequency, whilst also benefitting from the extensive work of the ZigBee Alliance to develop smart metering products. However, getting representation for this option has been challenging, and there does not appear to be support across a number of semi conductor manufacturers. Whilst products are now starting to appear, these are not generally tied directly to smart metering, and do not currently offer the ZigBee Smart Energy profile, which is of key interest to the group. The key shortfall of this option is lack of certified products available. Certification by the ZigBee Alliance requires 3 products from different providers to be available – at current we are only aware of one being available for ZigBee at 868MHz.

11.4.5 ZigBee @ 2.4GHz
ZigBee @2.4GHz has been in a strong position throughout – it offers context specific products, has an established interoperability regime and existing metering solutions. The ZigBee Alliance is also developing the product in key areas of interest to smart metering; the work with the HomePlug Alliance and DLMS are good examples of strategic activities that can only be viewed as positive. Adoption by major utilities in North America and Australia is also very encouraging. ZigBee @2.4GHz, however, must be successful in field trials and testing, as challenges relating to range/power consumption and interference at the 2.4GHz frequency continue to be raised. It is also the case that whilst it has been successful in other territories, there has been no significant adoption for utility metering in Europe.

11.4.6 Z Wave
The progress by the Z Wave Alliance towards a realistic smart metering/energy offering, even during the group activities to produce this report, has been impressive. Further, the development of the Advanced Energy Control profiles, the work on Z/IP and the solid foundation in home automation are all very positive. However, concerns remain over a couple of fundamental requirements: - Z Wave is currently subject to a single source of silicon (although there is evidence of progress in this area) - It remains unclear how ‘open’ the specification is and what the royalty and licence implications are Page 125 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development -

Version 0_5

there is no large international implementation of smart metering using Z Wave.

Page 126 of 140

5-Nov-08

12 Issues
Table 23 provides an ongoing record of issues for consideration and potential actions to resolve.
No I.1 Issue Description End to End Services The initial group workshop discussed the ability of a meter to support the replication of ‘WAN’ functionality locally, typically by a meter operator when WAN communications has failed. This may be challenging if Local Communications supports a restricted set of functionality with regard to data and commands. Data Ownership & Privacy Use of mesh networks outside premises could raise data ownership and data transfer questions – i.e. Supplier X receives data from Meter A via Meter B, which is supplied by Supplier Z Additional Network Requirement? Is there a need to define that the smart meter is expected to be the master of the HAN network? In most cases the meter could be expected to administer the energy aspects of a network, but could also be a node to an existing HAN, acting as a source of data for other nodes. There may not need to be a master – if the networks operate on a peer-to-peer basis. Resolution Options Recommend further work in this area to understand the relationship with Last Mile and the actual requirements

I.2

To an extent is contingent upon Government decisions and regulatory guidance on data ownership. A number of current solutions use the term ‘tunneling’ to explain how data is kept private within a mesh. For consideration by any subsequent development activity. It would be sensible to establish how many logical radio networks (‘utility’, ‘HAN’, ‘Gas’, ‘Water’) a meter may be part of. This can only be done after requirements are clarified.

I.3

I.4

For consideration by any Potential Wired Solution for Electricity subsequent development activity Only Premises A suggestion arising from ongoing discussions would be how to introduce an interoperable solution to cover a wired ‘HAN’ where there is no requirement for wireless from a gas meter. This could limit some of the applications for nodes within a network – e.g. any display designed to be used as a wireless option, but if the physical medium made use of electrical wiring within a home, then it also offers advantages that a wireless solution does not. Table 23 Issues

SRSM and Beyond – Local Communications Development

Version 0_5

13 References
Shown below are references to relevant materials and resources. The SRSM project maintains an online reference table of global interoperability initiatives (OpenHAN, CECED, TAHI etc.) at: http://snipurl.com/srsmint
Reference Itron case studies on meter data collection EN 62053-61 Description As requested at first meeting of Local Communications Development Group Standard entitled – Link snipurl.com/lcdgitron

Electricity Metering Equipment – Particular Requirements – Part 61 – Power Consumption and Voltage Requirements
Wireless Network Report Detailed report on wireless networks, including a technical comparison of ZigBee and ANT networks Report by Schneider Electric investigating the potential interference issues where ZigBee and WiFi networks coexist US specification of the requirements for AMI/Smart Grid operations using smart meters as a gateway to devices within a home

IEC Page for standard: http://tinyurl.com/5n8389

http://tinyurl.com/5jumeu

ZigBee & WiFi Coexistence Report

snipurl.com/zigbeewifi

OpenHAN 2008 Home Area Network System Requirements Specification v1 Release Candidate Daintree Networks paper on Building and Operating Robust and Reliable ZigBee Networks Recommended Practices Guide for Securing ZigBee Wireless Networks in Process Control System Environments

Direct link to download MS Word document: snipurl.com/openhan

Paper covering a range of topics relevant to the Local Communications Development Group activities, including; design, interference, security etc. April 2007 paper by Ken Masica for the US Department of Homeland Security. Relates to the matters covered in Prinicple P.3, Issue I.3 and section 5.8 It should be noted that the issues discussed in the paper

snipurl.com/lcdgdaintree

snipurl.com/zigbeehomeland

Page 128 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
would apply to all of the technology options considered by this report and not just ZigBee Potential UK Smart Meter Network Paper by group member Alistair Morfey of Cambridge Consultants, looking at the possible implications and architecture for using a Local Communications radio for Local and WAN Last Mile Table 24 References

Version 0_5

snipurl.com/lcdgmorfey

Page 129 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Appendix A: Referential Integrity Check
In order to ensure that the evaluation criteria used by the group provides sufficient coverage of the Principles, Assumptions and Requirements, Table 25 was created. It shows which of the Principles, Assumptions and Requirements are addressed by each of the criteria. Of the evaluation criteria ‘8.1 – Cost’ and ‘9.4 – Capacity of Silicon Vendors’ do not have matching references in the Principles, Assumptions and Requirements, as these are purely commercial considerations. Of the Principles ‘P.3 – Ownership of the Network’ is not evaluated as this will not be something the Local Communications Solution can affect. Similarly ‘P.7 – National Standard’ is a product of the process rather than anything an individual solution can establish. Of the Assumptions ‘A.1 – Legal’ does not need to be evaluated, ‘A.2 – SRSM Functionality’ is implied in the requirements and ‘A.4 – Utility Robust’ is addressed by the requirements and evaluation criteria, but not explicitly. Of the Requirements ‘NET.3 – Network Time Synchronisation’ is purely functional, ‘COM.3 – Hand Held as a WAN Proxy’ is an area covered by a recommendation for further development work to understand the requirement and ‘CUS.1 – Effect on Customer Networks’ has not been evaluated as part of this desktop investigation, but is recommended for inclusion in any subsequent field testing and is recorded as new criteria reference 5.6.
Ref 1.1 1.2 1.3 Criteria Low level of energy customer intervention/support required to maintain communications Ease of installation – i.e. discovery at meter installation Minimise number of site visits to address local communications issues – i.e. recovery or remote correction on failure/upgrade failure – will include MTBF and power consumption on meter battery as considerations Development tools to support smart metering and smart energy market Ease of integration into metering/home products – e.g. system on chip, antenna size Scope/receptiveness to accommodate specific GB smart metering requirements Status as an Open Standard – accessibility, defined standards, range of participants, proven certification process Principles Assumpt’s Req’s CUS.1.2.3 MOP.1 CUS.3 GEN.3 COM.1.3 MOP.1 CUS.2 GEN.2 CUS.2 A.1 GEN.1 COM.1 DAT.1 GEN.2 DAT.1

P.1

1.4 1.5 1.6 2.1

P.10 P.10 P.1 P.4.5.6.10

Page 130 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref 2.2 2.3 2.4 2.5 2.6 3.1 3.2 Criteria Support for choice of data exchange format Genuine choice and competition between silicon vendors Interoperable chipsets Effort required to update standards to meet specific GB requirements (less effort = higher score) No. of nodes supported for each HAN, assuming minimum capability of 3. Consumption/Peak Current/Power Failure Management Support for battery powered nodes, but also for energy smart metering application (e.g. data refreshes in minutes rather than hours/days for end nodes) Transmission speed – effective data throughput in kbps per channel Robustness (retry mechanisms, acknowledgements, minimised/nil message loss – i.e. latency and dropped packets) Typical range (amplified or nonamplified) Suitability for GB meter locations (consider internal/external, stone/concrete, metal meter cabinets, meter rooms etc.) Vulnerability to signal interference Ability to cope with signal interference Blocking Immunity in transceiver *NEW* ‘Good Neighbour’ test – the solution should not materially affect other networks Strength/resilience of methods used Ability to use rolling/successive keys Support for distinguishing public/private data, and for keeping gas/water/electricity data independently secure – i.e. supports 3 different suppliers for 3 utilities (and any other authorised party data secure) Support for “over the air” upgrades of ‘smart meter’ nodes – i.e. gas + electricity meters & in home display Support for security upgrades Support for backwards compatibility Longevity of frequency Longevity of solution technology (minimum expected smart meter asset life of 10-15 years) Total cost per home – 1 x electricity Principles P.4 P.4 P.4 P.1 P.4.5.6.10

Version 0_5
Req’s GEN.1.2 DAT.1 GEN.2 GEN.2 GEN.1.2 DAT.1 NET.2

Assumpt’s

P.2.8 P.1.2.8

GEN.3 GEN.3 COM.1

4.1 4.2

P.2 P.1

5.1 5.2

P.2.8 P.1

COM.1 COM.1 MOP.1 A.4 A.4 COM.2 CUS.1 COM.2 COM.2 CUS.1 SEC.1 SEC.1.2 COM.3 SEC.1 NET.1

5.3 5.4 5.5 5.6 6.1 6.2 6.3

P.1.9 P.9 P.9

7.1 7.2 7.3 7.4 7.5 8.1

P.9 P.9.10 P.10 P.10 A.3 A.3

GEN.4

GEN.4

Page 131 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development
Ref Criteria Principles meter, 1 x gas meter with battery, 1 x home display unit = 3 chipsets + additional battery cost Mean Time Between Failures/Reliability Use in equivalent smart metering P.1.2.4.6 deployments Use in analogous applications P.2.4.6 Expectation of ongoing required P.6.10 upgrades – i.e. v2009, v2011 (fewer = higher score?) Capacity in vendors to meet smart metering demands (meters plus displays and other devices) – assume 5 year deployment to 25 million homes Availability of non-metering products that P.4.6.10 could be relevant to smart metering – e.g. thermostats, display devices Table 25 Referential Integrity

Version 0_5
Req’s

Assumpt’s

8.2 9.1 9.2 9.3 9.4

MOP.1 COM.1.3

9.5

CUS.2

Appendix B: Last Mile Evaluation
Whilst not part of the core considerations and requirements for the Local Communications Development Group, the potential role that low power radio technology could play in supporting WAN communications could be an important consideration for the overall smart metering project. This will be contingent upon the outcome of Government discussions on market models for smart metering, and the work of the group in developing criteria for this area is recorded in this appendix to support any subsequent work.

Last Mile Criteria
Ref LM1 LM2 LM3 LM4 LM5 LM6 LM7 Criteria Support for Last Mile (Y/N/possibly) Performance Nodes per concentrator Typical Signal Propagation – average (urban/suburban/rural) Cost Cost of data concentrator equipment Maturity Use in other smart metering deployments for last mile connectivity Range of ‘upstream’ WAN physical media supported by data concentrators Architecture Ability to allow a smart meter to simultaneously be a member of two separate isolated networks – i.e. the Local Communications network within a home, and the WAN network to a home. One network cannot corrupt the other. Security keys and permissions are separate for the two networks. Table 26 Last Mile Evaluation Criteria

It has also been suggested that any Last Mile evaluation be included in any field and laboratory testing for the Local Communications solution, but only Page 132 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

where practical for cost and time concerns. A particular example raised would be to test the ‘house to house’ performance to give an indication of the appropriateness of the solution for different types of neighbourhood.

Appendix C: Initial Field Test
In March 2008, OnStream, E.On UK and Renesas, all members of the ERA SRSM Local Communications Development Group, undertook an exercise to evaluate the signal propagation properties of ZigBee RF solutions at 868MHz and 2.4GHz. An extract from the report covering the exercise is presented below. Subsequent to the publication of this information, the conclusions were extensively challenged by members of the group. Chief among the concerns was the use of a 2.4GHz radio with no power amplification or protocol stack. These issues were acknowledged and accepted by the participants in the test. Full detail of the responses from group members to the published test are presented below the extract from the report.

Test Report
The test used the following equipment: - Four printed circuit boards (two transmitters and two receivers) powered by battery. Two boards were prepared with 868MHz radio, and two with 2.4GHz radio. In order to make the test as objective as possible the transmitter output power on all four boards was set to the prescribed 0dBm, and the radio chips were sourced from the same company, where the chips were manufactured using the same processes. - Within the time and cost constraints of the project, the boards were as closely matched as was possible. - Each board had an LCD display to indicate a numerical interpretation of the received signal strength. The test that was performed: - One board of each pair was set to transmit an encoded data word to its counterpart. The receiving board would display a quality/signal strength number if and only if the signal was detected and the word decoded correctly. - A perfect signal would display a quality number 255, and the poorest decoded signal would display 1. Although automatic gain controls (AGC’s) were employed in both chips, the number was a linear representation of the size of signal reaching the receiver board. The test was carried out at the following locations, representing a cross section of GB housing stock: 1 Stone cottage built in 1860 which was constructed with stone and had lathe and plaster walls. 2 Semi-detached 1960’s three bedroom with no modifications. 3 Detached Bungalow circa 1950. 4 Detached modern two story house with no modifications. Page 133 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

5 Detached two story house with two story extension added. 6 First floor flat where the meter was in the flat not the basement. Within each location the electricity meter was identified and the ZigBee transmitter was switched on and placed beside the meter. The corresponding receiver was activated and placed at the following locations within the dwelling: 1 Kitchen window sill. 2 Lounge occasional table. 3 Lounge fireplace mantelpiece. 4 Hallway table. 5 Master bedroom. The results of the test are set out in Table 27. A figure of 255 denotes full reception, whilst 0 denotes no reception. There is no reference to the distances or barriers to hinder the signal, as this test aimed to measure relative performance for the two frequencies.
Location Stone Cottage SemiDetached Detached Bungalow Detached 2 Storey Detached 2 Storey with Extension First Floor Flat Kitchen 2.4 868 35 125 85 0 0 0 25 110 75 20 45 150 Lounge 1 2.4 868 85 155 16 40 0 0 35 110 170 50 60 155 Lounge 2 2.4 868 70 150 80 55 0 0 45 110 115 50 50 115 Hallway 2.4 868 50 140 90 115 0 0 35 200 190 30 60 135 Bedroom 2.4 868 50 140 25 35 15 0 35 150 160 80 25 135

Table 27 Field Test Results

The writers of the test report observed that: 1 As anticipated, the signal penetration of the 868MHz was superior to the 2.4GHz by a factor of 2.5 on average. 2 Operating in the low power constraints of the ZigBee specification, two of the six sites failed to receive the 2.4GHz signal with the receiver placed in a preferred and typical position. Both of these sites had either a long transmission path or multiple barriers between transmitter and receiver. 3 All sites demonstrated a signal reduction on 2.4GHz when the transmission path was blocked by a person. No similar signal reduction was encountered on the 868MHz. 4 2 further sites failed to receive at 2.4GHz when the signal path was blocked by a person. Both sites demonstrated a relatively weak signal response prior to this. 5 In locations where both frequencies were working satisfactorily, the signals appeared to be unaffected by existing I.S.M. appliances such as Wi-Fi, Microwave ovens, and video senders, although, in 2 locations. Page 134 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

6 Operation of the video sender did severely disrupt the Wi-Fi Router, in two locations. 7 In locations where both frequencies were working satisfactorily, the signals did not affect other I.S.M. appliances such as Wi-Fi or video senders. 8 It is possible to add a power amp to the 2.4GHz radio and increase its output power to 10mW. This would increase the range of 2.4GHz radio to about the same as the 868MHz radio, but would use more energy, affect battery life, and may cause interference. The report conclusions were: 1 Given that smart metering must be available to all consumers, only 868MHz could be considered at this time. 2 ZigBee data rates and available channels are less at 868MHz than at 2.4GHz, so it should be established if the available data transfer capability of 868MHz is acceptable for ‘UK Smart’ 3 An analysis of the ‘ZigBee Smart Protocol’ (pro feature set) should be made to see if it meets the ERA requirements 4 An analysis of the ‘ZigBee Smart Protocol’ should be made to see if it meets the ERA Wide Area Network (WAN) requirements as a common protocol for both WAN and LAN. This would vastly simplify and accelerate smart metering rollout in the UK.

Responses to the Report
Ember responded to the publication of the report by providing the following statements: “I welcome the sort of testing carried out by Eric and Kevin, however I have serious concerns about the assumptions made for these tests, the actual tests carried out, some of the observations and the conclusions with regard to the suitability of 2.4GHz ZigBee. In particular, it could be argued that the choice of transmit power and possibly the choice of silicon (or at least the lack of variety of silicon tested) was flawed. It could also be argued that the assumptions about the effect of increased transmit power on battery life for 2.4GHz devices was flawed. I strongly recommend that when conducting such tests, companies should; • Select carefully the ZigBee modules or chips to be tested, ensuring that they are the current state of the art, in particular with respect to transmit power and receive sensitivity. This can be ascertained by looking at the data sheet for the various chips available. • Make use of the available transmit power on the chosen device. A number of ZigBee/802.15.4 2.4GHz radios today can transmit to +4dBm or +5dBm without external PA, and have receive sensitivity to -98dBm or lower. Remember that the most important factor is the link budget; that is the combination of transmit power and receive sensitivity. For instance, an extra 3dBm in transmit power combined with an extra 3dBm receive Page 135 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

• •

sensitivity is roughly equivalent to double the range in free space when two devices talk to one another. Even when using a good performing ZigBee radio, the implementation of the PCB design is important, and small flaws can cause huge loss of range. Be sure that you are testing the receipt of messages and not just radio performance. ZigBee has a number of layers in the stack, each one trying to get a message through, and a typical ZigBee message is actually retried 12 times at various layers before the application is told that a message has failed. A better test of performance is to send X messages with Y interpacket delay and count how many were received. Finally, while it is understood that point to point RF performance is important because the smart metering system cannot make any assumptions about available routing or relaying devices in the home, it should be considered that ultimately ZigBee is designed for robust mesh networking and any blind spots in a home can be covered by the use of routers, which could come in the form of plug through energy meters/controllers or powered in-home displays even in the short term.”

PRI also posted a response to the report: “…A few points to beware of: 1. The tests don't appear to have made use of the ZigBee stack with its error correction and re-try features. It is dangerous to simply take RF strength in isolation since the stack enhances the performance of the data reliability greatly. 2. The 2.4GHz signal can be boosted to +5dBm without a power amp and up to +17dBm (in the UK) if necessary. The rules for 868 transmissions make amplification difficult due to the fact the side lobes must remain below an absolute limit (rather than a percentage of the fundamental as in the USA 915MHz band). 3. The bandwidth of 2.4GHz ZigBee allows an on-air bit rate of 250kB/sec compared with 10kB/sec for 868. For battery powered applications it is the energy usage that's important, so it’s not only the current consumed but also the time. Both 868 and 2.4GHz radio devices take much the same current when active, but the 2.4GHz radio will only be active for 1/25th of the time for a 868 (roughly), therefore the energy taken for a given transmission will be much less. 4. The bandwidth restrictions imposed by an 868 system will make running the Smart Energy Profile with its ZigBee Pro stack very slow. All applications to date are running on 2.4GHz solutions from three of the major silicon vendors.”

Online Reference
The full text of the report and responses from group members can be viewed online at: http://snipurl.com/lcdfieldtest

Page 136 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Appendix D: ZigBee@2.4GHz Evaluation Introduction
Taken from a ZigBee paper submitted to support the group evaluation process.

Preamble – On using ZigBee for UK Smart Metering Local Communications
Unlike some alternative options available for Local Communications in the UK, ZigBee 2.4GHz offers a lot of flexibility in the final solution. Some technologies are defined only at a radio (MAC & PHY) level, which means that they require someone to do a lot of work to get effective, robust, secure and interoperable communications working well. Some technologies are more than that, but do not go as far as to define the application level messages and protocols, network formation mechanisms, key establishment protocols etc. The choice of ZigBee at 2.4GHz would in fact offer the whole spectrum of options for UK Smart metering and ensure that any requirements could be implemented successfully; Option A: Adopt ZigBee Smart Energy as currently defined. ZSE is an application profile that defines the entire application including all messaging, secure transport of network keys and link keys, network formation and discovery etc. If the UK, like many US utilities and Victoria in Australia, was to specify ZSE, in its entirety, as a requirement for their smart metering Local Communications, this could be easily communicated and understood as a requirement to manufacturers as there is already a certification process in place to ensure that products conform to the standard and are interoperable. Option B: Modify ZigBee Smart Energy for UK purposes Inevitably, ZSE has not been developed with the UK market specifically in mind and the majority of manufacturers, utilities etc. involved in defining the spec were focussed on requirements for California and Texas, so it is likely that there are some modifications that the UK would want to the standard. For example, UK smart metering might decide that the Certicom ECC key exchange mechanisms are not required and may want an alternative mechanism included in the spec for use in the UK. The mechanism for proposing and completing modifications to the standard within the ZigBee Alliance are well defined and tested, and it should be quite easy once requirements are known, to make modifications, which might be generic or specific to the UK market. Option C: Combine ZigBee Smart Energy with other protocols For instance, some work is beginning to allow DLMS messages to be transported across ZigBee networks. This has been done in ZigBee before with BACNET (in building automation market). It is possible to use ZigBee Smart Energy and some other protocol in different ‘endpoints’ in the same Page 137 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

ZigBee device, so it should be possible to include for example a ZSE simple meter endpoint as well as a DLMS meter endpoint in a ZigBee meter application.

Figure 19 ZigBee & DLMS Illustration

Option D: Create a totally proprietary profile on top of ZigBee Networking It would be an unusual and unlikely move, but UK smart metering could decide to define an entirely new application profile which is unique to the UK and either totally proprietary or proposed as a new public application profile. Standard ZigBee networking offers all of the discovery, network formation, routing, message clusters etc. in any case, and any new profile could take advantage of that. More likely, some proprietary operation could be implemented in individual products alongside and as well as the ZSE application profile (on a different endpoint within the device), to provide innovation and differentiation as well as standardisation and interoperability in a single product. Summary So, in summary, ZigBee at 2.4GHz is not just a simple take-it-or-leave-it option for the ERA and UK smart metering. The standard itself has built in flexibility allowing standardised applications to run alongside proprietary applications even in the same device, and the ZigBee Alliance is an open organisation with open access to membership and open access to the committees that define and shape the standard and the various application profiles.

Page 138 of 140

5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

Appendix E: Bluetooth Information on Profiles, Certification and Interoperability
The information below was provided by Bluetooth representatives alongside the evaluation notes detail. One of the requirements asks about the ease of adapting or reusing existing profiles or specifications. It’s easy to answer this question from a purely academic viewpoint of the amount of hours of work needed to make the change, but that misses the point that profiles are intimately tied in with certification programs and ultimately with the level of interoperability. It’s useful to explain this dependence as it is not clear in the majority of responses and may affect some of the decisions that are made. Profiles first made a major appearance as part of the DECT standard to try and solve the problem that although every vendor used the same specification for their DECT handsets none of them were interoperable. The reason is that DECT, like most other wireless specifications, defines the physical hardware of the radio and the protocol stack that sits on top of it, but does not define the application that determines how devices connect to each other. That is typically left to the manufacturer, who put pressure on standards bodies to omit this level of detail, as the manufacturers often believe that the user interface is where they differentiate themselves from competing products. To take an analogy, you can think of the specification as defining the human body. However, without a defined language, which might be vocal or signing, two different humans are only capable of limited communication. As DECT vendors discovered, this lack of interoperability inhibited the market growth. As a result they defined their Generic Access Profile, which gave detailed instructions as to how a handset would log in to a base station. They also wrote test specifications and instituted a testing regime that allowed manufacturers to certify the fact that their product conformed to the profile. As a result the market prospered. Bluetooth took the concept further, with multiple application oriented profiles, each of which dictated how a specific application would operate using the Bluetooth wireless link. They also encouraged different application developers to produce a range of profiles, such that Bluetooth vendors can ship interoperable products as diverse as stereo headsets, blood pressure meters and GPS receivers, confident that they will work with a device certified for the matching half of the profile. ZigBee has in turn adopted the same approach. There is a Faustian pact to this. The promise of interoperability from a profile is only valid if there is a watertight certification process in place that ensures that every product is tested to meet the requirements, along with legal measures that will be taken to prevent or remove any non-compliant product. Typically developing the test regime and certification process can be as demanding as writing the profile, if not more so. Hence standards bodies are loath to initiate or accept too many different profiles. Page 139 of 140 5-Nov-08

SRSM and Beyond – Local Communications Development

Version 0_5

As a result we have the concept of public or standards led profiles, which are part of the published standard and enforced by the standards group, as well as private profiles which are developed by groups of manufacturers for their own use, where they manage the testing and certification process. For a major usage case, the public profile is the preferable route. However, because standards bodies are open, any profile development working group will be open to all interested parties. This means that the profile may end up more complex than some members would wish. As its adoption also relies on all members coming to consensus, the process can become extremely extended. Public profiles are rarely completed in less than nine months and can take years. But as they are “owned” by the standard, the full resources and experience of the standards group will be used in developing the test regime, certification and enforcement programs, which are likely to be very robust. The alternative is the private profile, which can be defined and built on existing profiles in a relatively short timescale. However, companies developing private profiles must be aware of the overhead of writing test regimes and setting up certification processes. These are a major task, the scale of which is frequently underestimated. Standards groups have specialists who have years of experience in doing this. Private profile developers rarely do. But without them in place, the profile only delivers a limited part of its promise. Bluetooth low energy has tried to learn from its experience. Current Bluetooth profiles include a lot of complexity about the control of the application, largely because this is not elegantly handled lower down in the stack. With low energy, more granularity of control and data transfer has been added to the underlying protocols, meaning that the higher layer profiles or data dictionaries that define device interaction are much simpler. As a result it is hoped that many of these can be written in a few months, with certification processes in place within six months. Having said which, the differences between public and private profiles still apply.

Page 140 of 140

5-Nov-08