SRSM and Beyond Local Communications Development

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

Simon Harrison Draft SRSM LCD 0_3 September 2008

SRSM and Beyond – Local Communications Development

Version 0_3

Table of Contents
Table of Contents ...............................................................................................2 Figures ...............................................................................................................3 Document Control ..............................................................................................4 1.1 Version History ....................................................................................4 1.2 Review Group & Website ....................................................................5 1.3 Intellectual Property Rights and Copyright ..........................................6 1.4 Disclaimer ............................................................................................6 2 Executive Summary and Introduction .........................................................7 2.1 Executive Summary ............................................................................7 2.2 Purpose ...............................................................................................7 2.3 Scope ..................................................................................................7 2.4 Objective..............................................................................................7 2.5 Structure of this Document ..................................................................7 3 Glossary & Conventions .............................................................................9 3.1 Document Conventions .......................................................................9 3.1.1 Market Segments .........................................................................9 3.1.2 Meter Functionality .......................................................................9 3.1.3 Meter Location ...........................................................................10 3.1.4 Meter and Metering System .......................................................10 3.2 Glossary ............................................................................................12 4 Local Communications Context ................................................................15 4.1 General Context ................................................................................15 4.2 Smart Utility Context for Local Communications ...............................16 4.3 Smarter Display Options Using Local Communications ...................17 4.4 Smart Home Context .........................................................................19 5 Associated Topics.....................................................................................22 5.1 A National Standard ..........................................................................22 5.2 Security..............................................................................................22 5.3 Delivering the Last Mile .....................................................................23 5.4 Local Device Classification ...............................................................24 5.5 Processes/Activities Required...........................................................24 5.6 Types of Data ....................................................................................25 5.7 Independent & Private Local Networks .............................................26 5.8 Wireless to Wired Options .................................................................30 5.8.1 Wired/Wireless Protocol Development ......................................31 5.9 British Housing Types .......................................................................31 5.9.1 Houses By Type .........................................................................32 6 Principles & Assumptions .........................................................................34 6.1 Local Communications Principles .....................................................34 6.2 Local Communications Assumptions ................................................34 7 Requirements ...........................................................................................36 7.1 Requirements ....................................................................................36 7.2 Requirements Notes..........................................................................38 Potential Additional Requirements ....................................................40 7.3 8 Solution Options .......................................................................................41 8.1 Solution Options Descriptions ...........................................................42 8.2 Other Solution Options ......................................................................52 9 Additional Considerations .........................................................................57 9.1 Network & Addressing Protocols .......................................................57 Page 2 of 80 3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

9.2 Frequency Considerations ................................................................59 9.2.1 Frequency Information ...............................................................59 9.2.2 Licensed or Unlicensed ..............................................................61 9.3 Data Exchange Format Options ........................................................61 10 Evaluation of Solution Options ..............................................................64 10.1 Evaluation Process............................................................................64 10.2 Evaluation Methodologies .................................................................64 10.2.1 Evaluation Weighting .................................................................65 10.2.2 Evaluation Scoring .....................................................................65 10.3 Evaluation Criteria .............................................................................65 Evaluation Scorecard ............................................................................69 10.4...............................................................................................................69 10.4.1 Evaluation Notes ........................................................................72 10.5 Last Mile Evaluation ..........................................................................72 10.5.1 Last Mile Criteria ........................................................................72 10.5.2 Last Mile Evaluation Scorecard .................................................73 10.5.3 Last Mile Evaluation Notes ........................................................73 10.6 Evaluation Results.............................................................................73 10.7 Evaluation Issues Table ....................................................................74 10.8 Evaluation Scenarios.........................................................................74 11 Recommendation ..................................................................................75 12 Issues ....................................................................................................76 13 References ............................................................................................77 Appendix A: Initial Field Test ..........................................................................78

Figures
Figure 1: Smart Meter Locations .....................................................................10 Figure 2: Smart Metering Systems, Illustration of Flexible Approaches ..........11 Figure 3: SRSM Operational Framework Scope .............................................15 Figure 4: Smart Utility Context .........................................................................17 Figure 5: Smart Display Context ......................................................................18 Figure 6: Smart Home Context ........................................................................19 Figure 7: Smart Home Context & Clusters ......................................................20 Figure 8 Different Uses of Local Communications ..........................................21 Figure 9: Local Communications for the Last Mile ..........................................23 Figure 10 Technical WAN Interoperability .......................................................26 Figure 11: Simple Collection of Smart Meters and Local Devices ..................26 Figure 12: Independent Networks....................................................................27 Figure 13: Local Communication Signal Range ..............................................28 Figure 14: Overlapping Wireless Ranges ........................................................28 Figure 15: Required Local Comms Range Example .......................................29 Figure 16: Mesh Network to Concentrator .......................................................30

Page 3 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 Comms Development Group Significant update following two meetings of the Local Comms Development Group snipurl.com/lcdgv21 Online Version snipurl.com/lcdgv1 snipurl.com/lcdgv2

0_3

September 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 Energy Retail Association in August 2007 – the development 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 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

Page 4 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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. The table below lists the organisations and companies who are members of the group. Energy Retail Association British Gas E.ON UK ScottishPower Alcatel-Lucent All Island Power Arm Atmel BERR Cambridge Consultants Cason Engineering Daintree Networks DEFRA Electralink Ember Federation of Communication Services Fujitsu Himsley Meter Revenue Services I+P Services Ingenium Landis+Gyr Microsoft National Grid Ofgem Orsis Q’Vedis Remote Energy Monitoring Society of British Gas Industries Sensus Metering Services Siemens Energy Services theowl.com Trilliant Networks Zensys Engage Consulting EDF Energy Npower Scottish & Southern Energy Alertme.com Association of Meter Operators Arqiva British Electrotechnical & Allied Manufacturers Association BGlobal Metering Cambridge Silicon Radio Coronis Data Direct Echelon Elster Ewgeco Freescale Green Energy Options Horstmann Imserv Itron Low Power Radio Association More Associates Ofcom Onzo PRI UK Ltd Radiocrafts Renesas Technology Secure Electrans Sentec Sustainability First Tridium Utilihub Zigbee Alliance

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

Page 5 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 6 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

2

Executive Summary and Introduction

2.1 Executive Summary
[Overview and Explanation of the exercise and the scale of the document to be added when appropriate.]

2.2 Purpose
This document presents the context, requirements, issues and solutions options for two-way Local Communication for smart Metering Systems. It also includes an evaluation of solutions 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 SRSM project. Further information on the SRSM project is available from: www.energy-retail.org/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 Page 7 of 80 3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

-

-

-

-

-

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 o Section 10 – Evaluation Criteria and process completed by the Local Communications Development Group o Section 11 – Recommendation – 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 Appendix – Field test undertaken by group members

Page 8 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 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 Operational Framework proposals could apply. Therefore, within this document, the solutions 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 WAN 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 9 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development •

Version 0_3

Remote configuration of tariffs, meter operations, upgradeable firmware etc.

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 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 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 10 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 11 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 Access Control Meaning The method by which the Operational Framework controls access to smart Metering Systems, smart metering data and associated devices. 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. Bill of Materials – term used by manufacturers to cover a list of materials and components used to make an assembled item. 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. Complementary Metal Oxide Semiconductor – a type of microchip Electronic interactions including the transmission of data between Metering Systems and Authorised Parties or Metering Systems and Local Devices Danish Energy Savings Trust Device Language Message Specification – European data protocol for meter communications Energy Retail Association Gaussian Frequency Shift Keying – a form of modulation used for radio communications – is used by Bluetooth and ZWave Gaussian Minimum Shift Keying – a form of modulation used for radio communications – is used by GSM General Purpose Input/Output 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. Heating Ventilation and Air Conditioning Internet Protocol 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

Authorised Party

BoM

CECED

CMOS Data Exchange

DEST DLMS ERA GFSK

GMSK GPIO Hand Held Unit

HVAC IP Interoperability

Page 12 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Term

Version 0_3

Meaning structured Access Control, is a key interoperability requirement. Industrial, Scientific, Medical – term describing unlicensed international radio frequency bands Communications between a Metering System and Local Devices within the premises in which the Metering System is installed. A Local Device can be any piece of equipment within premises that communicates directly with the Metering System using Local Communications. Micro Controller Unit A single device or meter, or a combination of devices used to deliver the Lowest Common Denominator as defined in the Operational Framework Schedule L ‘Smart Meter Functional Specification’. Classification of meter type under the 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 Schedule L ‘Smart Meter Functional Specification’. A generic 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. Original Equipment Manufacturer 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. Smart Metering Operational Framework Proposals and Options

ISM Local Communications Local Device

MCU Metering System

Meter Variant

Meter Worker

OEM Open Standard

Operational Framework

Page 13 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Term OTP POR PWM RAND SCADA SoC SRSM Project Meaning One Time Programmable Power On Reset Pulse Width Modulation Reasonable and Non-Discriminatory

Version 0_3

Supervisory Control and Data Acquisition, generally an industrial control system managed by a computer. System on Chip Supplier Requirements of Smart Metering project. Exercise in 2006-08 undertaken by ERA to develop the Operational Framework. Ongoing at the time of developing this document

Supplier WAN (Wide Area Network) Communications WSDL

Means an energy retail business Communications between a Metering System and a remote Authorised Party Web Services Description Language – a language used within interoperable machine to machine interactions over networks.

Page 14 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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. The diagram below shows the SRSM project representation of the operational architecture for smart metering and therefore the scope of the Operational Framework – this document specifically relates to the ‘Local Comms’ section on the left hand side of the diagram.

Industry Interfaces

Figure 3: SRSM Operational Framework Scope

Data Transport (internet)

Page 15 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 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 Operational Framework.

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 below is a representation of the basic utility requirements for Local Communications for smart metering:

Page 16 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 the illustration above, it is a requirement of the 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 the illustration 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 17 of 80 3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 18 of 80 3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 below, 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

The final context illustration below presents the smart home context for the smart metering local communications solution(s).

Page 19 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Microgeneration ‘Cluster’

Version 0_3

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. The illustration below 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 20 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 21 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 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 22 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 23 of 80 3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 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 24 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

Within the 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 25 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Meter with WAN Hardware

Version 0_3

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 26 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 below.

Page 27 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 customers’ metering not to be visible on their neighbours’ 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 28 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 Comms 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 29 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

Figure 16: Mesh Network to Concentrator

5.8 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.3 above, 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 Page 30 of 80 3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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. 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.8.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. Aimed 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 (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.9 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 Page 31 of 80 3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 (mantel units) 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 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.9.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
3

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

Stock Profile – English House Condition Survey 2005

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

% 20 22 23 20 11 3 2 100

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 32 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

Type of Dwelling – Scottish House Condition Survey 2004/5

Welsh Data: Dwelling Type Detached Semi-Detached Terrace Flats Total

Figures taken from 1998 Welsh House Condition Survey

000’s 264 387 405 101 1,157

% 23 33 35 9 100

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

[Add data for construction type if available?] [Add data for meter location if available? Interior/Exterior/Meter Cabinet]

Page 33 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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: • Utility focus – the key requirement remains the communication between smart meters and energy information display 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 Home Area Network associated with smart Metering Systems will be owned by the customer. This allows them to add or remove any Local Devices. The smart Metering Systems themselves will be responsibility of the energy Supplier • Interoperable – supporting a range of metering products and local device applications • Use, wherever possible, of open standards and architecture • The intention is to adopt (and potentially develop) an existing solution rather than develop a new one. This includes the protocol and data definition. • Same ‘solution’ in all smart meters – establishing a national solution/standard • 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 and ongoing technological developments. • Future Proof/Future Flexible – supporting innovation at the same time as supporting legacy systems

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 A.2 A.3 Assumption The Local Communications Solution will be compliant with relevant legislation and regulations Smart meter functionality is broadly equivalent to the SRSM Smart Meter Specification SRSM Smart Meters are expected to have an asset life in excess of 1015 years

Page 34 of 80

3-Sep-08

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

Version 0_3

The Local Communications Solution 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

Page 35 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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. In OSI terms, the Local Communications Solution will be interoperable at the PHY and MAC levels

GEN.3

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

GEN.4

Page 36 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Ref COM.1 Requirement Communication The Local Communications Solution must be able to operate effectively in the majority of British domestic premises without the need for additional equipment Notes

Version 0_3

Note that domestic sized smart meters could be used in non-domestic premises. Note that there may be 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 device. 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 Meter Worker device. 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

DAT.1

Page 37 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Ref NET.1 Requirement The Local Communications Solution shall ensure that all Local Devices are required to join the network to access meter data and functionality The Local Communications Solution shall be able to support a minimum of 7 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 minimum requirements on customers for day to day operation. Notes

Version 0_3

NET.2

NET.3

Or, Network Time Synchronisation

CUS.2

For example, where a customer wants to pair a new Local Device 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.

CUS.3

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.

Page 38 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Ref Factor

Version 0_3

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 potential explosive atmospheres (ATEX). 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 (IGEM), 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. 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 have 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 minute or 5 minutes - waking up more frequently when credit levels (in debit mode) are below a configurable threshold, to ensure that credit purchase

F.3

Page 39 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Ref Factor

Version 0_3

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) More detailed work is required to establish the preferred minimum position, if an agreed position is required.

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 40 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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, weblinks 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 41 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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. As with existing Bluetooth Personal Area Networks, Bluetooth low energy will support up to seven nodes in a network, with a typical signal range of 5 to 10 metres. The standard is expected to be finalised and formally adopted by the Bluetooth SIG by Q1 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.

Cost: Data: Power: 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) 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 billion enabled devices sold. As an immature product, there are no uses of Bluetooth low energy in a smart metering context. Understood to be still under development Due to the relatively short range, it is not anticipated that Bluetooth low energy be suitable for WAN Last Mile No products available today ‘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.

Frequencies:

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

Page 42 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

Specifically designed to do point-to-point connections well – does not support mesh networking. Reference: V0.5 prepared in August 2008 by Project Team from online sources 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 Specification7. 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

Solution
Description:
7

Wavenis

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

Wavenis is a wireless connectivity platform that features Ultra Low

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 43 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

Hardware:

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 WSNs (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 typ (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 - Gaz AMR/AMI (ChinaGas, GasNatural @ Spain, …) 3 – Elec 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 outpout power class Wavenis modules offer 1km Line of Sight (LOS) thanks to -113dBm sensitivity (50kHz bandwidth reciever) with -3dBi helicoidal antenna. 2 – 500mW power class Wavenis modules offer 4km range. These modules are usually intended to range extenders for large scale networks.

Cost: Data: Power:

Frequencies: Protocols:

Data Exchange Format: Use in other applications:

Use in other markets:

Maturity: Support for ‘Last Mile’:

Page 44 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

For:

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 Sprectrum (FHSS) technics 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

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 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 – frequency of transmission and the size of those transmissions - will determine the eventual battery requirements.

Frequencies: Protocols:

868MHz

Page 45 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Data Exchange Format: Use in other applications: Use in other markets: Maturity: Support for ‘Last Mile’: For: Against: Notes: Reference: Solution Description:

Version 0_3

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 20118 Home automation, telecoms (local)

Smart Energy Profile due for release March 2008, ZigBee Pro Stack available January 2008

Collated by SRSM project team from group activities ZigBee @ 2.4GHz www.zigbee.org

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 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.

Data:

8

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

Page 46 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

- 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. Custom protocols / data formats are allowed, but would not be guaranteed interoperable.

Frequencies: Protocols:

Page 47 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Use in other applications: Use in other markets:

Version 0_3

Total ZigBee node and chipset units – 5 million in 2006, 120 million in 201110 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. Raymarine) 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/802.15.4 chips were sold worldwide for inclusion in products in 2007.

Maturity:

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. There are a number of examples of the use of ZigBee in last mile communications for AMR already, the most notable in Europe

10

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

Page 48 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 effects 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 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 • 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

Against:

Notes: Reference

Solution Description:

Page 49 of 80

3-Sep-08

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

Version 0_3

Hardware:

Cost:

• • • • • • •

Data:

• • • •

Power:

• • Frequencies: • • • •

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 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

Page 50 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

• •

Protocols:

• • •

Data Exchange Format:

• • •

Use in other applications:

• Use in other markets: • • • •

Maturity:

Support for ‘Last Mile’:

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 ZWave 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

Page 51 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

For:

• • • • • • • • •

Against: Notes: Reference

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

8.2 Other Solution Options
The table below 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 including in utilisation evaluation Solution Description Bluetooth 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

Page 52 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

telephony and PC markets. Operates at 2.4GHz, with average power consumption of 5000μA Website www.bluetooth.com Reason for not Although there are a number of standards for Bluetooth, some of which may include greater signal propagation and more efficient including in 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 Contol 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, also does not currently support secure communications including in evaluation Solution Description ISA100.11a Provides a wireless industrial process automation network to

Page 53 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

address control, alerting, and monitoring applications plantwide. 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. Website http://snipurl.com/isa100 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 • Targetted at battery powered devices • Supports secure encrypted comms • Star and peer to peer topology • 38 to 230 kbs • 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 Description Website OpenTherm Communications protocol used to control heating applications. Appears to be wired and has been developed in Holland. www.opentherm.eu

Page 54 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Reason for not Specific application for heating including in evaluation Solution Description PhyNet

Version 0_3

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 AMI (advanced metering infrastructure) and WSN (wireless sensor networks). 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 including in metering implementations evaluation

Solution Description

WiFi Established high power standard, prevalent in many homes. Typically used for broadband internet connections and multimedia

Page 55 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
delivery. Works at 2.4GHz. Website www.wi-fi.org

Version 0_3

Reason for not Power consumption is very high, with propagation issues for a significant proportion of GB home types. Also concerns over including in conflicts and interference with customers’ existing wireless evaluation 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

Page 56 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 57 of 80

3-Sep-08

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

Version 0_3

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

Page 58 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 59 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 60 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Notes:

Version 0_3

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)11. 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

11

Consultants 2007

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

Page 61 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

Work has been done to map C12.19 to an XML Schema Used by/for: For: Against: Notes: Data Exchange Format Description: Used by/for: For: Against: Notes: Obis DLMS/Cosem 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. 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?

Data Exchange Format Description:

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. 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 62 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 63 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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 overall score 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 • Begin completing scorecard, recording any key issues or risks noted against a solution option October 2 2008 Meeting • Complete evaluation criteria, recording any key issues or risks noted against a solution option Late October 2008 Meeting • Finalise and agree recommendation Desktop + supporting evidence

10.2 Evaluation Methodologies
Each of the criteria shown below are weighted and scored using a variety of methods. Due to the range of criteria being considered, no single method would be appropriate, or in some cases possible. Page 64 of 80 3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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. The weighting, which is directly applied to the scoring to give an overall view, is shown in the scoring table below. ‘Must Have’ criteria carry a weighting of 4, with an additional caveat that any technology failing to meet Boolean tests for Must Have criteria, or achieving a low score on a Scored test is listed in the Evaluation Issues table below

10.2.2 Evaluation Scoring
Boolean criteria are rated at 5 – YES or 0 – No. Scored criteria are on a 0 to 5 basis, and scores assigned are objective or subjective depending on the data available and the type of criteria being assessed: 0 No support/does not meet requirement 1 Very limited support/meets little of requirement 2 Limited support/meets part of requirement 3 Partial support/ meets most of requirement 4 Supports/meets requirement 5 Fully compliant/exceeds requirement Ranked criteria are rated from 0 to 5, with 5 being the best performing option and 0 being the lowest performing option.

10.3 Evaluation Criteria
Ref Criteria Weighting Assessment 12 (Desirable Method only: (Boolean, 3 = Very Ranked, 2 = Fairly Scored) 1 = Less) Fit with Requirements (not specifically addressed by categories below) Desirable 3 Scored 1.1 Low level of energy customer intervention/support required to maintain communications Must Have NA Scored 1.2 Ease of installation – i.e. discovery/configuration at meter installation Desirable 3 Scored 1.3 Minimise number of site visits to address local communications issues – i.e. recovery or remote correction on
12 Must Have criteria carry a weighting of 4

Relevance/Importance (Must Have/Desirable)

Page 65 of 80

3-Sep-08

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

Version 0_3
Assessment Method (Boolean, Ranked, Scored)

Weighting 12 (Desirable only: 3 = Very 2 = Fairly 1 = Less)

failure/upgrade failure – will include MTBF and power consumption on meter battery as considerations 1.4 Development tools to support smart metering and smart energy market 1.5 Ease of integration into metering/home products – e.g. system on chip, antenna size 1.6 Scope 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 Low Power Routing – support for battery powered nodes, but also for energy smart metering application (e.g. data refreshes in minutes rather than

Desirable

1

Scored

Desirable

2

Scored

Must Have

NA

Ranked

Must Have

NA

Ranked

Desirable Desirable Must Have Desirable

2 3 NA 2

Scored Scored Boolean Ranked

Desirable

2

Scored

Desirable Must Have

3 NA

Scored Scored

Page 66 of 80

3-Sep-08

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

Version 0_3
Assessment Method (Boolean, Ranked, Scored)

Weighting 12 (Desirable only: 3 = Very 2 = Fairly 1 = Less)

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 (Should the test be based on Link Budget?) 5.1 Typical range (amplified or non-amplified) 5.2 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

Desirable

2

Scored

Desirable

2

Scored

Desirable Desirable

3 3

Ranked Scored

Desirable Desirable Desirable Desirable Desirable Must Have

2 3 2 3 2 NA

Scored Scored Scored Ranked Scored Scored

Must Have

NA

Scored

Page 67 of 80

3-Sep-08

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

Version 0_3
Assessment Method (Boolean, Ranked, Scored)

Weighting 12 (Desirable only: 3 = Very 2 = Fairly 1 = Less)

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 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 9.2 Use in analogous applications 9.3 Expectation of ongoing required upgrades – i.e. v2009, v2011 (fewer = higher score?) 9.4 Capacity in vendors to meet smart metering demands (meters plus displays and other devices) – assume 5 year deployment to 25 million homes 9.5 Availability of nonmetering products that could be relevant to smart metering – e.g. thermostats, display devices

Desirable Must Have Desirable Must Have

2 NA 3 NA

Scored Scored Scored Scored

Desirable

2

Ranked

Desirable Desirable Desirable Desirable

3 3 2 1

Scored Ranked Scored Scored

Must Have

NA

Ranked

Desirable

2

Scored

Page 68 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

10.4 Evaluation Scorecard
Ref Criteria Key ‘M’ust Have ‘D’esirable Weighting ‘B’oolean, ‘R’anked, ‘S’cored Sample Criteria Bluetooth M-Bus Wavenis ZigBee ZigBee ZLow @ @ Wave Energy 868MHz 2.4GHz Only the final score (i.e. after weighting has been applied) will be shown in each cell of the table.

X X X D 3 S D 3

e.g.

Scores 3 out of 5: 3x3= 9

Scores 0 out of 5: 0x3= 0

Scores 4 out of 5: 4x3= 12

Scores 5 out of 5: 5x3= 15

Scores 2 out of 5: 2x3= 6

Scores 1 out of 5: 1x3= 3

1.1

1.2

1.3

1.4

1.5

1.6

2.1

2.2

Low level of energy customer intervention/support S required to maintain communications Ease of installation – M i.e. discovery/configuration 4 at meter S 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 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

Page 69 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Ref 2.3 Criteria 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 Low Power Routing – 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 Bluetooth Low Energy M-Bus Wavenis

Version 0_3
ZigBee ZigBee @ @ 868MHz 2.4GHz ZWave

2.4 2.5

2.6

3.1 3.2

4.1

4.2

5.1 5.2

5.3 5.4 5.5

Page 70 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Ref Criteria 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 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 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 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 Bluetooth Low Energy M-Bus Wavenis

Version 0_3
ZigBee ZigBee @ @ 868MHz 2.4GHz ZWave

6.1 6.2 6.3

7.1

7.2 7.3 7.4 7.5

8.1

8.2 9.1 9.2 9.3

9.4

Page 71 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Ref Criteria demands (meters plus displays and other devices) – assume 5 year deployment to 25 million homes Availability of nonmetering products that could be relevant to smart metering – e.g. thermostats, display devices Bluetooth Low Energy M-Bus Wavenis

Version 0_3
ZigBee ZigBee @ @ 868MHz 2.4GHz ZWave

9.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 the table below.
Ref Solution Score Notes/Explanation

e.g.

Solution X

5

800 million devices sold in 2007

10.5 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 is an important consideration for the overall smart metering project. The scoring for these specific criteria does not form part of the overall evaluation results, but are recorded here to support any ongoing WAN communications developments.

10.5.1 Last Mile Criteria
Ref Criteria Relevance/Importance Assessment Method LM1 Support for Last Mile (Y/N/possibly) Performance LM2 Nodes per concentrator LM3 Typical Signal Propagation – average (urban/suburban/rural) Cost LM4 Cost of data concentrator equipment Maturity LM5 Use in other smart metering deployments for last mile connectivity LM6 Range of ‘upstream’ WAN physical media supported by data concentrators

Page 72 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

10.5.2 Last Mile Evaluation Scorecard
Ref Criteria Bluetooth Low Energy M-Bus Wavenis ZigBee ZigBee @ @ 868MHz 2.4GHz ZWave

LM1 Support for Last Mile

LM2 Nodes per concentrator LM3 Typical Signal Propagation – average (urban/suburban/rural) LM4 Cost of data concentrator equipment LM5 Use in other smart metering deployments for last mile connectivity LM6 Range of ‘upstream’ WAN physical media supported by data concentrators

10.5.3 Last Mile Evaluation Notes
Ref Solution Score Notes/Explanation

e.g.

Solution X

0

Not currently used for Last Mile WAN activity

10.6 Evaluation Results
Criteria Types Fit With Requirements Interoperability Power Data Performance Radio Performance Security Future Resistance Cost Bluetooth Low Energy M-Bus Wavenis ZigBee ZigBee @ @ 868MHz 2.4GHz ZWave

Page 73 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development
Criteria Types Maturity Must Have Criteria Desirable – 3 Desirable – 2 Desirable – 1 Total Score Bluetooth Low Energy M-Bus Wavenis

Version 0_3
ZWave

ZigBee ZigBee @ @ 868MHz 2.4GHz

10.7 Evaluation Issues Table
The table below shows issues and risks identified during the evaluation process.
Ref Solution Criteria Issue/Risk

e.g.

Solution X

10

No evidence of chipsets from different vendors working correctly together

10.8 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 - 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 pad.
Premise Size: 3 Bedroom, 3 Reception, Domestic Semi-Detached House, 100sqm Level One Two Three Four Five Wall Type Brick Foil Insulated Meter Locations External, adjacent External, remote Internal, adjacent Interference Average Average Average High Harsh

Page 74 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

11 Recommendation
[Placeholder for recommendation of the group. Will include any relevant notes, issues or comments as required by the group] [At the 2nd September meeting it was agreed that the recommendation should include a clear recommendation for field testing of solutions in typical British installations. Clarity relating to suggesting the ‘Who’, ‘How’ and ‘When’ for this testing may be agreed at subsequent meetings]

Page 75 of 80

3-Sep-08

12 Issues
The table below 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. Also, how do you consider the fact that for the majority of homes there will be two smart meters? Which one would be the master, particularly if the fuels are provided by different suppliers? To be discussed by the Group Resolution Options

I.2

I.3

SRSM and Beyond – Local Communications Development

Version 0_3

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 WELMEC guidelines on power consumption Description As requested at first meeting of Local Comms Development Group As stated at first meeting of Local Comms Development Group. Defines power consumption for metrology/ communications. Standard entitled – Link http://tinyurl.com/6ymjgo

[reference to materials required]

EN 62053-61

Electricity Metering Equipment – Particular Requirements – Part 61 – Power Consumption and Voltage Requirements
Wireless Network Report ZigBee & WiFi Coexistence 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 co-exist – used for the discussion of spread spectrum in 8.2 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

http://tinyurl.com/6jucto

OpenHAN 2008 Home Area Network System Requirements Specification v1 Release Candidate

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

Page 77 of 80

3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

Appendix A: 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. 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. 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 the table below. A figure of 255 denotes full reception, whilst 0 denotes no reception. There is no reference to the Page 78 of 80 3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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

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. 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’ Page 79 of 80 3-Sep-08

SRSM and Beyond – Local Communications Development

Version 0_3

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. A number of group participants responded to the paper in support of 2.4GHz, with attendant power amplification to improve range. The full report, and responses from group members can be viewed online at: http://snipurl.com/lcdfieldtest

Page 80 of 80

3-Sep-08

Sign up to vote on this title
UsefulNot useful