SRSM and Beyond Local Communications Development

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

Simon Harrison Draft SRSM LCD 0_2_1 15 April 2008
Deleted: 2

Deleted: 10 March

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

Table of Contents
Table of Contents................................................................................................ 2 Figures ................................................................................................................ 3 Document Control ............................................................................................... 4 1.1 Version History ..................................................................................... 4 1.2 Review Group....................................................................................... 5 1.3 Intellectual Property Rights and Copyright.......................................... 5 1.4 Disclaimer............................................................................................. 5 2 Executive Summary and Introduction ......................................................... 6 2.1 Executive Summary ............................................................................. 6 2.2 Purpose ................................................................................................ 6 2.3 Scope ................................................................................................... 6 2.4 Objective .............................................................................................. 6 2.5 Structure of this Document .................................................................. 6 3 Glossary & Conventions.............................................................................. 8 3.1 Document Conventions ....................................................................... 8 3.1.1 Meter Location .............................................................................. 8 3.1.2 Meter and Metering System ......................................................... 8 3.2 Glossary ............................................................................................. 10 4 Local Communications Context ................................................................ 12 4.1 General Context ................................................................................. 12 4.2 Smart Utility Context for Local Communications .............................. 13 4.3 Smarter Display Options Using Local Communications ................... 14 4.4 Smart Home Context ......................................................................... 16 4.5 One Interoperability Size Fits All? ..................................................... 17 4.6 A National Standard........................................................................... 19 4.7 Delivering the Last Mile ..................................................................... 19 4.8 Local Device Classification ................................................................ 20 4.9 Existing Standards ............................................................................. 21 5 Energy Supplier Requirements ................................................................. 22 5.1 Other Factors ..................................................................................... 24 5.2 Potential Additional Requirements .................................................... 27 5.3 Other Requirements........................................................................... 27 5.4 Processes/Activities Required ........................................................... 27 5.5 Security............................................................................................... 28 5.6 Independent Local Networks ............................................................. 29 5.7 Wireless to Wired ............................................................................... 33 5.8 Addressing Protocol........................................................................... 34 5.9 Local Communications Principles ..................................................... 34 6 Solution Options ........................................................................................ 36 6.1 Solution Options Descriptions ........................................................... 37 6.2 Other Solution Options....................................................................... 44 7 Network Protocol Options ......................................................................... 49 8 Frequency Considerations ........................................................................ 50 8.1 Frequency Information ....................................................................... 50 8.2 Licensed or Unlicensed ..................................................................... 52 8.3 Spread Spectrum ............................................................................... 52 8.4 Local Communications Group Field Test .......................................... 52 9 Data Exchange Format Options................................................................ 55 10 Evaluation Options................................................................................. 57 Page 2 of 63 15-Apr-08

Deleted: 7-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

10.1 Data Traffic Models ............................................................................ 57 10.1.1 Data Traffic Activities.................................................................. 57 10.1.2 Data Traffic Usage Profiles ........................................................ 58 10.2 Solution Evaluation Matrix ................................................................. 58 10.2.1 Evaluation Matrix Notes ............................................................. 59 11 Issues ..................................................................................................... 60 12 References............................................................................................. 61 Appendix: Schedule [X] of Operational Framework......................................... 63

Figures
Figure 1: Smart Meter Locations ........................................................................ 8 Figure 2: Smart Metering Systems, Illustration of Flexible Approaches ........... 9 Figure 3: SRSM Operational Framework Scope ............................................. 12 Figure 4: Smart Utility Context ......................................................................... 14 Figure 5: Smart Display Context ...................................................................... 15 Figure 6: Smart Home Context......................................................................... 16 Figure 7: Smart Home Context & Clusters....................................................... 17 Figure 8: End to End Interoperability................................................................ 17 Figure 9: Distinct Local and WAN Interoperability ........................................... 18 Figure 10: Making Interoperability Work .......................................................... 18 Figure 11: Interoperability Illustration Using Water.......................................... 19 Figure 12: Local Communications for the Last Mile ........................................ 20 Figure 13: Simple Collection of Smart Meters and Local Devices .................. 29 Figure 14: Independent Networks .................................................................... 30 Figure 15: Local Communication Signal Range .............................................. 30 Figure 16: Overlapping Wireless Ranges ........................................................ 31 Figure 17: Required Local Comms Range Example ....................................... 32 Figure 18: Mesh Network to Concentrator ....................................................... 32 Figure 19: Interoperability via Web Services Interfaces .................................. 34

Deleted: ¶ Table of Contents 2¶ Figures 3¶ Document Control 4¶ 1.1 Version History 4¶ 1.2 Review Group 5¶ 1.3 Intellectual Property Rights and Copyright 5¶ 1.4 Disclaimer 5¶ 2 Executive Summary and Introduction 6¶ 2.1 Executive Summary 6¶ 2.2 Purpose 6¶ 2.3 Scope 6¶ 2.4 Objective 6¶ 2.5 Structure of this Document 6¶ 3 Glossary & Conventions 8¶ 3.1 Document Conventions 8¶ 3.1.1 Meter Location 8¶ 3.1.2 Meter and Metering System 8¶ 3.2 Glossary 10¶ 4 Local Communications Context 12¶ 4.1 General Context 12¶ 4.2 Smart Utility Context for Local Communications 13¶ 4.3 Smarter Display Options Using Local Communications 14¶ 4.4 Smart Home Context 16¶ 4.5 One Interoperability Size Fits All? 17¶ 4.6 A National Standard 19¶ 4.7 Delivering the Last Mile 19¶ 4.8 Local Device Classification 20¶ 4.9 Existing Standards 21¶ 5 Energy Supplier Requirements 22¶ 5.1 Other Factors 24¶ 5.2 Potential Additional Requirements 27¶ 5.3 Other Requirements 27¶ 5.4 Processes/Activities Required 27¶ 5.5 Security 28¶ 5.6 Independent Local Networks 29¶ 5.7 Wireless to Wired 33¶ 5.8 Addressing Protocol 34¶ 5.9 Local Communications Principles 34¶ ... [1] 6 Solution Options 36 Deleted: ¶ Figure 1: Smart Meter Locations 8¶ Figure 2: Smart Metering Systems, Illustration of Flexible Approaches 9¶ Figure 3: SRSM Operational Framework Scope 12¶ Figure 4: Smart Utility Context 14¶ Figure 5: Smart Display Context 15¶ Figure 6: Smart Home Context 16¶ Figure 7: Smart Home Context & Clusters 17¶ Figure 8: End to End Interoperability 17¶ ... [2] Figure 9: Distinct Local and Deleted: 7-Apr-08

Page 3 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

Document Control
Version 1.1 Version History
Version 0_1 Date 7 February 2008 Author Simon Harrison Description Initial draft Online Version Download View Online 0_2 10 March 2008 Simon Harrison Updated following initial meeting of development group: - restructuring of content - format of document to assist with comment and development - corrections and additions throughout Please note that due to the scale and scope of the change from 0_1 to 0_2, the updates are not change marked. Change marking will be standard practice for all subsequent versions. v0_2 also 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 Interim Release Updated to include information and a number of comments provided prior to 2nd meeting of Local Comms Development Group Download View Online

Formatted: Superscript

This document is a development of Schedule H of the Smart Metering Operational Framework Proposals and Options v1 document – the development history of which is shown below.
Deleted: 7-Apr-08

Page 4 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Version 0.1 Date 17th July 2007 Author Simon Harrison Description

Version 0_2_1

Deleted: 2

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

25 July 2007 6th August 2007 December 2007

th

Alastair Manson Simon Harrison Simon Harrison

1.2 Review Group
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. Details of the participants can be viewed online at: http://tinyurl.com/2cvr3g

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. These materials are made available for you to review and to copy for the purposes of participating in Smart Meter Operational Framework discussions only. All copyright and other notices contained in the original material must be retained on any copy that you make. All other use is prohibited. Unless you are a person participating in the Smart Meter Operational Framework discussions you are not permitted to view or use this document or any information contained in this document in any way whatsoever. 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. It does not present a complete and final framework for the operation of smart metering in Great Britain and the proposals or options presented do not represent all possible solutions. 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.

Deleted: 7-Apr-08

Page 5 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

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 a specimen view of a final schedule proposal for inclusion in the Smart Metering Operational Framework. 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) and draft schedule to the ERA SRSM Steering Group.

2.5 Structure of this Document
The sections of this document are: - Section 1 – Document Control
Deleted: 7-Apr-08

Page 6 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development -

Version 0_2_1

Deleted: 2

Section 2 – Introduction Section 3 – Glossary and Document Conventions Section 4 – Local Communications Context – a plain English explanation of the context for smart metering and local communications Section 5 – Requirements & Considerations – details of energy Supplier requirements, and other relevant requirements affecting Local Communications Section 6 – Solution Options – presentation of options using a standard pro forma Section 7 – Network Protocol Options – information relating to specific addressing requirements Section 8 – Frequency Options – presentation of information relating to wireless frequencies Section 9 – Data Exchange Format Options – information relating to data formatting options Section 10 – Evaluation Options – including a scoring matrix comparing solution options against set criteria. Also includes usage profiles to assist with evaluation. Section 11 – Issues – as identified during the development of this report Section 12 – References – to relevant materials and resources Appendix – Draft specification

Deleted: 7-Apr-08

Page 7 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

3

Glossary & Conventions

3.1 Document Conventions
3.1.1 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 Operational Framework 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.2 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.

Deleted: 7-Apr-08

Page 8 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

Smart Metering Systems – Illustration of Flexible Approaches

+
Software

+ +

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

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

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

Deleted: 7-Apr-08

Page 9 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

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. Electronic interactions including the transmission of data between Metering Systems and Authorised Parties or Metering Systems and Local Devices Energy Retail Association 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. 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 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. 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
Deleted: 7-Apr-08

Authorised Party

BoM

CECED

Data Exchange

ERA Hand Held Unit

IP Interoperability

ISM Local Communications Local Device

Metering System

Page 10 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Term Meter Variant Meaning Functional Specification’.

Version 0_2_1

Deleted: 2

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

Meter Worker

Open Standard

Operational Framework SRSM Project

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.

Deleted: 7-Apr-08

Page 11 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

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

Deleted: 7-Apr-08

Page 12 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

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:

Deleted: 7-Apr-08

Page 13 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

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 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.
Deleted: 7-Apr-08

Page 14 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

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.
Deleted: 7-Apr-08

Page 15 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

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

Deleted: 7-Apr-08

Page 16 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

Figure 7: Smart Home Context & Clusters

It is not a requirement of the Smart Metering Operational Framework for smart meters to act as a (or ‘the’) gateway for all of the devices shown in the clusters. More detail on gateways is shown in section 5 below. 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.

Interoperability 4.5 One Interoperability Size Fits All?
The initial ambition of the SRSM project was to establish an end to end proposal for interoperable smart metering. Under this approach, the same network protocol and data exchange format would be used to communicate between the metering system and a local device as would be used between a metering system and an authorized party. This is shown in the diagram below for a proposed use where the electricity smart meter acts as a WAN Communications host for the gas smart meter.

Figure 8: End to End Interoperability

Following feedback as a result of consulting on the Operational Framework, it has been suggested that this ‘One Size Fits All’ approach for interoperability may not be appropriate. A number of potential local devices would not be
Deleted: 7-Apr-08

Page 17 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

capable of handling an XML file or supporting an IP address, or that the requirements of these standards would increase the cost of the hardware to be used. Similarly, the transfer of information between a meter and a thermostat may not be required to support the same level of data security as would apply to the transmission of energy credit from a supplier to a meter. The diagram below illustrates distinct solutions for Local Communications and WAN Communications in an example where: - an energy supplier (or other party) can receive diagnostic information from heating devices within a property via the electricity meter - an energy supplier could use the smart metering link to send pricing signals or demand management information to heating devices

Figure 9: Distinct Local and WAN Interoperability

However, where the approach is not common from one end of the infrastructure to the other, there may be additional requirements for the smart meter, or the Local Communications hardware, to support the following types of transactions.

Figure 10: Making Interoperability Work

For completeness, the following diagram shows an interaction between a local device, in this case a water meter with Local Communications compatible hardware, and an Authorised Party who is not an energy supplier.

???
Deleted: 7-Apr-08

Page 18 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

Figure 11: Interoperability Illustration Using Water

4.6 A National Standard
Whilst ‘same solution’ 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, in order to ensure that smart metering creates an effective platform for the types of applications presented above, it is believed that a national standard for local communications is required. This would mean that all smart meters 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.

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

Deleted: 7-Apr-08

Page 19 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

Data Transport (internet)

Figure 12: 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.

4.8 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 - an IR motion 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: Page 20 of 63 15-Apr-08

Deleted: 7-Apr-08

SRSM and Beyond – Local Communications Development -

Version 0_2_1

Deleted: 2

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

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.

4.9 Existing Standards
Placeholder to include any candidate standards for consideration – e.g. CECED, GridWise, MultiSpeak etc. These could be published or in development. The SRSM project maintains an online reference table of global interoperability initiatives at: http://tinyurl.com/yta5m8

Deleted: 7-Apr-08

Page 21 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

5

Energy Supplier Requirements

Shown below are the requirements taken from the ERA’s Smart Metering Operational Framework Proposals and Options, as developed since publication of that document in August 2007. These requirements are classified as Mandatory/Highly Desirable/Desirable.
Ref R.1 Requirement The local communications solution(s) will be compliant with relevant legislation and regulations There is a requirement for 2 way communication of data between the Metering System and Local Devices Mandatory/ Desirable Mandatory Notes

R.2

Mandatory

The maximum requirement is for intermittent communication between a Metering System and a Local Device at a configurable interval (every 2 minutes, every hour, on demand etc). A gas meter using low power radio for Local Communications to an electricity meter and onward to a display device on a half-hour interval was still capable of a 10 year battery life. The Local Communications link will also be available as 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

Deleted: 7-Apr-08

Page 22 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Ref Requirement Mandatory/ Desirable Notes

Version 0_2_1

Deleted: 2

communications during a site visit or also for a ‘drive by’ or ‘walk by’ activity. R.3 The local communications solution(s) will require the number of site visits to a Metering System to address issues or failures of the communications solution(s) to be kept to a minimum. Communication to and from a Metering System will be resistant to inappropriate interference by any party including the customer. Highly Desirable

R.4

Mandatory

Inappropriate here, means inadvertent or deliberate actions that would compromise the other requirements. A balance will need to be maintained between the requirement for secure communications with Local Devices, as defined in the access control security policies, and the ability for customers to establish local communications between a Metering System and a Local Device – e.g. should a customer have to call their Supplier to inform them that they have purchased a ‘smart’ Washing Machine and want to be able to show actual consumption costs on their new Local Device?

R.5

The local communications solution(s) shall be resistant to viruses and other malicious software. The local communications solution(s) will not incur any costs for transmission of data between a metering system and a local device The local communications solution(s) will not alter, corrupt or permanently store any data it transports. The local communications solution(s) under reasonable

Mandatory

R.6

Mandatory

Transmission of data to or from a remote party via WAN, to link to a local device, could incur communications costs.

R.7

Mandatory

R.8

Mandatory

Quoted standard applies to electricity metering, but
Deleted: 7-Apr-08

Page 23 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Ref Requirement usage profiles, will not critically affect the power consumption or battery life of a Metering System and will comply with EN 6205361 R.9 Where a gas Metering System forms part of a mesh network for Local or WAN Communications, it will not act as a primary relay point. The local communications solution(s) will place minimum requirements on customers for day to day operation. Highly Desirable Mandatory/ Desirable Notes

Version 0_2_1

Deleted: 2

principles should also apply to gas metering

In order to preserve battery life

R.10

Mandatory

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. Data traffic requirements remain subject to ongoing developments. However, sample models and profiles could be built into this document to assist with evaluating the solution options. Equipment owned or controlled by the customer could develop faults, be replaced or simply switched off.

R.11

The local communications solution(s) will be capable of meeting the data traffic requirements of the Operational Framework.

Mandatory

R.12

Metering System Local Communication will not be reliant upon hardware or equipment under the control of the customer

Mandatory

5.1 Other Factors
A number of factors relating to Local Communications solutions are not explicit within the requirements shown above. These factors are contained within, or derived from, the overall Smart Metering Operational Framework and the principles detailed within that document. These factors are relevant for the evaluation of solution options.
Ref F.1 Factor/Statement Asset life expectation for smart meters Notes Not explicitly stated within the Operational Framework. Current energy Supplier expectations, based upon discussions with meter manufacturers, are for an asset life of 15 years as a minimum, with equivalent battery life (for average usage profiles)
Deleted: 7-Apr-08

Page 24 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Ref F.2 Factor/Statement Power consumption (linked to R.8) In order to reduce the impact of the power consumption of smart meters themselves, either direct consumption of electricity or as causing a requirement for larger, more expensive batteries within gas meters, it is a requirement to ensure that the Local Communications solution is as energy efficient as possible. Power within Gas Meters There have been a number of questions about the possibility of avoiding battery issues within smart gas meters by using wired power. This would allow for consideration of a wider range of solutions for Local (and WAN) communications. A number of gas appliances already include gas and electricity components. Some European smart meter installations use low power (30v) wired connections to link gas, water, heat and electricity meters for communications purposes. There are key regulations and standards relating to gas meters and 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. F.4 Solution longevity The preferred local comms solution will be installed in metering systems with an asset life of at least 10 years, and is likely to be required to operate for much longer. Therefore the solution will need to be capable of remaining viable for an extended service period. Some points to consider in relation to this: - availability of the frequency Notes

Version 0_2_1

Deleted: 2

The design of the protocol stack will have an influence on the power consumption of the meter – particularly if there are no restrictions on the number of attempts to send messages.

F.3

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’.
Deleted: e

Selection of a solution to be used in smart metering could, in effect, guarantee its’ longevity and relevance in the future.

Deleted: 7-Apr-08

Page 25 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Ref Factor/Statement selected - resilience of the encryption standards as technology develops - flexibility to support upgrades, whilst retaining backwards compatibility Solution availability It is absolutely critical that the solution is available for use in line with the expectations for the installation of smart meters. today. Notes

Version 0_2_1

Deleted: 2

F.5

The ‘start date’ for smart metering remains unclear. A number of the solutions presented below are new, or are subject to ongoing development. Availability of silicon and protocols today might not necessarily mean that these are appropriate for use in smart metering. Evaluation of this requirement could be based on availability vs. time to market vs. installed units

F.6

Visiting Smart Meters (linked to R.3)

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.

F.7

Single Universal Solution See 4.6 above

F.8

Linking/Pairing existing and new local devices to a smart metering system to be quick, easy and secure Number of Linked Devices Unlimited/Limit [to be discussed and agreed, alongside the implications of
Deleted: 7-Apr-08

F.9

Page 26 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Ref F.10 F.11 F.12 Factor/Statement Must not cause interference Meter Operator/Worker Interface Ability to provide ‘Last Mile’ coverage for WAN Communications.

Version 0_2_1

Deleted: 2

Notes creating parameters here] Or be interfered with See notes for R.2 and issue I.7

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

5.3 Other Requirements
Placeholder for requirements other than those from ERA members within Smart Metering Operational Framework. Examples could include requirements from network operators, water companies or device manufacturers.
Ref O.1 Requirement Mandatory/ Mandatory/ Desirable Notes

5.4 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. 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
Deleted: 7-Apr-08

Page 27 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development 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

Version 0_2_1

Deleted: 2

5.5 Security
Requirements R.4 and R.5 above relate to the security capabilities of Local Communications solutions. This section of the document illustrates and expands on the requirements for secure Local Communications. 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. 1 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. 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. Requirement R.4 is not explicit in requiring the use of encryption to protect data, but it is an obvious solution to the requirement. The strength of encryption is also not specified as this tends to be a feature that varies by solution option2. It is accepted that no solution can be completely secure and resist all attempts to intercept or interfere. The Smart Metering Operational Framework v1 requires the following security measures for WAN Communications: • Cryptosecurity – e.g. at least 128 bit encryption using Advanced Encryption Standard (AES).

1

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 Access Control is part of the overall smart metering architecture. It covers how access to the meter functionality and data is controlled, and is defined in more detail in the main Operational Framework document. Requirements (and potentially constraints) arising from the selection of a Local Communications solution will be considered as part of the development of proposals for Access Control by the SRSM project.

Deleted: 7-Apr-08

Page 28 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development • • • •

Version 0_2_1

Deleted: 2

Emission security – protecting information emanating from the Metering System from intercept and analysis Physical security – safeguarding communications equipment and materials from access to or observation of by unauthorised persons Traffic flow security – concealing the presence and properties of valid messages on the communications network Transmission security – measures to protect information from interception and exploitation by means other than decryption – e.g. jamming, frequency hopping etc.

Not all of the solution options for Local Communications will support all of these measures. However, they will be evaluated against each other on the basis of these measures.

5.6 Independent Local Networks
Shown below is a simple illustration of typical utility applications for local communications in two neighbouring properties.

Figure 13: 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. 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.
Deleted: 7-Apr-08

Page 29 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

Figure 14: 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.

Figure 15: Local Communication Signal Range
Deleted: 7-Apr-08

Page 30 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

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 16: Overlapping Wireless Ranges

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.

Deleted: 7-Apr-08

Page 31 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

Figure 17: 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.

Figure 18: Mesh Network to Concentrator

Deleted: 7-Apr-08

Page 32 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

Wireless Wired 5.7 Wireless to Wired
[Placeholder to consider opportunity to define a standard covering wired and wireless local communications and any issues that could arise from such a determination: - cost added to metering system - relevance for gas meters - interference from other utilisation of wires] 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 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. The illustration below is taken from a Microsoft presentation on web services and the development of a connected ‘internet of things’, and shows a smart meter as part of the local network, but not necessarily communicating with all of the devices within that network as there is a ‘WSDL/IP’ bridge. Page 33 of 63 15-Apr-08

Deleted: with

Deleted: 7-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

Figure 19: Interoperability via Web Services Interfaces

[Placeholder to explain the interoperable software – including web services] 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.

5.8 Addressing Protocol
[Placeholder to consider the potential requirement for an overarching network addressing protocol, e.g. use of 6LoPan to implement IP addressing within Local Communications networks.]

5.9 Local Communications Principles
From the detail presented above, it is possible to infer a number of key principles that apply to Local Communications for smart metering: • Interoperable – supporting a range of metering products and local device applications • 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. • Use, wherever possible, of open standards and architecture • Same ‘solution’ in all smart meters – establishing a national solution/standard Page 34 of 63 15-Apr-08

Deleted: 7-Apr-08

SRSM and Beyond – Local Communications Development • • • •

Version 0_2_1

Deleted: 2

Energy efficient Secure Future Proof/Future Flexible – supporting innovation at the same time as supporting legacy systems etc

Deleted: 7-Apr-08

Page 35 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

6

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. Sections 7, 8 and 9 cover aspects of the overall solution that are relevant to Local Communications, and which are not necessarily, in and of themselves, options or solutions.

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 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
Deleted: 7-Apr-08

Frequencies: Protocols:

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

Page 36 of 63

15-Apr-08

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

Version 0_2_1

Deleted: 2

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.

Formatted: Heading 2

6.1 Solution Options Descriptions
Solutions are presented in alphabetical order.
Deleted: ¶ Deleted: Solution Deleted: Solution Deleted: Solution ... [3] ... [4] ... [5]

Solution Description:

M Bus

www.mwww.m-bus.com
Deleted: ¶ ¶

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 ie, approx €5 Wireless M-Bus speed at 868MHz Wired M-Bus data transmission speed is very low 5mW 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 Specification3. Wireless M-Bus used for German 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:

Deleted: Wired M-Bus data transmission speed is very low

Deleted: , Deleted: and the Netherlands.

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

Over 80 companies have implement M-Bus in their products. IEC standard since 2001 No, design suitable for “in home” communications Well proven, widely deployed, 868Mhz good transmission frequency 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.

Deleted: http://www.mbus.com/ ¶ Formatted: Default Paragraph Font Formatted: Font: Italic

3

Dutch Smart Meter Requirements v2.1 Final – February 2008 – page 6 of the P2 Companion

Formatted: English (U.K.) Deleted: 7-Apr-08

Standard describes the use of Wired and Wireless M-Bus communications.

Page 37 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Solution Description: Wavenis

Version 0_2_1

Deleted: 2

www.wavenis.com & www.coronis.com

Field Code Changed

Hardware:

Wavenis is a wireless connectivity platform that features Ultra Low Power and Long Range coverage capabilities. Wavenis has been developed by Coronis (creation in 2000) to address the most critical applications where devices are located in hard-to-reach places with strong energy constraints for multi-years operation. Offers today one of the most attractive price-performances ratio. Dedicated to remote operation for both fixed and mobile 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 phenomenom, 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, …) 1,500,000 Wavenis enabled devices deployed worldwide to date 1 – 25mW low power class Wavenis modules offer 1km Line of Sight (LOS) thanks to -113dBm sensitivity (50kHz bandwidth reciever) and 25mW outpout power and -3dBi helicoidal antenna. 2 – 500mW high power class Wavenis modules offer 4km range. These modules are usually intended to range extenders for large scale networks.

Formatted: Indent: Left: 0.13 cm

Cost: Data: Power:

Frequencies: Protocols:

Data Exchange Format: Use in other applications:

Use in other markets: Maturity: Support for ‘Last Mile’:

Deleted: 7-Apr-08

Page 38 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

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 is going to launch (June 2008) the Wavenis Open Standard Alliance (www.wavenisosa.org) which paves the way of the Wavenis standardization to play a major role worldwide in the “Short Range Wireless” markets.

Against: Notes:
Deleted: Solution ... [6]

Note – ZigBee, at the request of group members, is presented in two iterations to acknowledge the different aspects 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 Renesas 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.

Deleted: Ember, ST, TI, Freescale, Deleted: , Jennic Deleted: Circa $5 per end (total BoM) Deleted: ¶ 250 kbit/s at 2.4GHz Deleted: ¶ Examples:¶ - Ember EM250 operates at between 35 and 41 milliAmps without a power amplifier. With a power amplifier it will operate at 100 milliAmps when transmitting. When ‘awake’ but not transmitting power consumption is 7 milliAmps. When ‘asleep’ power consumption is less than µ1A.¶ Deleted: or 2.4GHz

Frequencies: Protocols: Data Exchange Format:

868MHz ZigBee with Smart Energy Profile Specified in the ZigBee Smart Energy Profile which can be added to if required.

Deleted: 7-Apr-08

Page 39 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Use in other applications: Use in other markets: Maturity: Support for ‘Last Mile’: For: Against: Notes: Solution Description: ZigBee @ 2.4GHz www.zigbee.org

Version 0_2_1

Deleted: 2

Total ZigBee node and chipset units – 5 million in 2006, 120 million in 20114 Home automation, telecoms (local)

Smart Energy Profile due for release March 2008, ZigBee Pro Stack available January 2008
Deleted: With relevant power amplification, ZigBee at 2.4 GHz can operate at a range of 1km line of sight in open air, which is reduced markedly when there are things in the way. Deleted: Already in use for Home Automation applications, adopted by North American, Swedish and Australian utilities for smart metering applications and all the major meter manufacturers will have products available by Q2 2008

Open global standard developed by the ZigBee Alliance for low cost low power wireless mesh networking for monitoring and control. Supported by over 225 member companies and with 19 certified vendors of stack/silicon combinations. Based on the IEEE 802.15.4 standard MAC and PHY

Hardware:

Typical ZigBee solutions are either 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

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. - 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. 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
Formatted: Font: Italic Deleted: 7-Apr-08

Data:

Power:

4

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

Page 40 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

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. Frequencies: Protocols: 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: Use in other applications: Use in other markets: Format is defined by the ZigBee specification, in the ZigBee Cluster Library and Application Profiles. Total ZigBee node and chipset units – 5 million in 2006, 120 million in 20115 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.
Deleted: 7-Apr-08

5

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

Page 41 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

- 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. Maturity: 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 10 million ZigBee chips were sold worldwide for inclusion in products in 2007. Support for ‘Last Mile’: ZigBee is well suited to last mile communications because of many features; - Scalability of the mesh network allows for many hundreds or thousands of devices in a single network, communicating across multiple hops from source to destination. - Robust communications is provided through retry mechanisms. - Security can be added, even to the point of having individual application link keys between electricity meters and the concentrator. - A network that makes use of powered devices to provide a mesh while facilitating battery powered end devices is entirely suitable to metering systems for electricity, gas and water. - Excellent bandwidth available at 2.4GHz to provide not only for AMR and configuration data, but also perhaps other data in the future, such as alarms or health monitoring of elderly. - 16 channels at 2.4GHz provide scope for further increased availability of bandwidth as different networks in the same area can occupy different channels. - Excellent range can be achieved within regulations, up to 1Km line of sight has been shown. There are a number of examples of the use of ZigBee in last mile communications for AMR already, the most notable in Europe being the City of Gothenburg project currently being installed for gas and electricity meters in Sweden. A number of meter manufacturers have already implemented AMR systems using ZigBee. For: - Open Global Standard, supported by 225 companies and 19 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

Deleted: 7-Apr-08

Page 42 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

- 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 Against: - 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)

Notes: Solution Description: Z Wave www.zwww.z-wave.com

Standard developed and supplied exclusively by Zensys, although irreversible steps have been taken to establish Z-Wave as an international open standard. Supports a maximum of 237 nodes. Developing Z/IP to support convergence of Z-Wave and TCP/IP

Deleted: .

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:
Deleted: Is a proprietary standard.¶ Questions relating to support for security requirements.

BOM cost of the chip (SoC) without module will be $2-3 depending on the volume, and for the entire module it will be $4-5 Approximate range of 60 feet indoors. 868MHz

Home automation in North America – 220 interoperable products available

Deleted: 7-Apr-08

Page 43 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2 Deleted: [please add any additional tables as required] ¶ Formatted: Heading 2

6.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 options may move from 6.2 to 6.1 and vice versa as discussions within the development group (and iterations of this document) progress.
Solution Description 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

Website

Field Code Changed

Reason for not Is a proprietary solution, also quite new. including in evaluation Solution Description Website Reason for not including in 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 telephony and PC markets. Operates at 2.4GHz, with average power consumption of 5000µA www.bluetooth.com
Formatted: Font: Bold Formatted: Indent: Left: 0 cm

BACnet American developed protocol used mainly for HVAC applications in building automation. www.bacnet.org

Website

Field Code Changed Formatted

Reason for not Although there are a number of standards for Bluetooth, some of including in which may include greater signal propagation and more efficient evaluation power management, Bluetooth is viewed as too power-hungry and not capable of sufficient range to meet the SRSM requiements. Solution Description Website Reason for not including in evaluation www.ekasystems.com EkaNET

Deleted: 7-Apr-08

Page 44 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Solution Description: HomePlug www.homeplug.org

Version 0_2_1

Deleted: 2

Formatted Table

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

Formatted: Bullets and Numbering

Website Reason for not including in evaluation 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.

Solution Description Website

Reason for not Emphasis on wired solutions does not match gas requirements, including in also does not currently support secure communications 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

Formatted: Font: Bold

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.
Deleted: 7-Apr-08

Page 45 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Solution Description OneNet

Version 0_2_1

Deleted: 2

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

Formatted: Bullets and Numbering

Website

Formatted: Bulleted + Level: 1 + Aligned at: 0 cm + Tab after: 0.63 cm + Indent at: 0.63 cm Formatted: Bullets and Numbering

Reason for not New standard, main focus appears to be battery operated devices. including in evaluation Solution Description Website Reason for not including in evaluation Solution Description PhyNet 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. OpenTherm Communications protocol used to control heating applications. Appears to be wired and has been developed in Holland. www.opentherm.eu

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

Deleted: 7-Apr-08

Page 46 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

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. Website Reason for not Very new including in evaluation Solution Description Website Reason for not including in evaluation Solution Description Wibree (Ultra Low Power Bluetooth) Protocol designed to support small devices, gives example of equivalency to watch batteries in power consumption. Operates at 2.4GHz, with a range of 5-10 metres, and a data rate of 1 Mbps. Initial interoperability profiles have been developed for watches, sensors and human interface devices. Website www.wibree.com Reason for not Immature solution, may not provide signal range required by smart including in metering. evaluation Solution Description WiFi Established high power standard, prevalent in many homes. Typically used for broadband internet connections and multimedia delivery. Works at 2.4GHz. www.wi-fi.org
Formatted: Font: Bold Formatted: Font: Bold Formatted: Font: Bold

SimpliciTI TI Website

Website

Reason for not Power consumption is very high, with propagation issues for a including in significant proportion of GB home types. Also concerns over evaluation conflicts and interference with customers’ existing wireless networks. Solution Description Website Reason for not including in evaluation
Deleted: 7-Apr-08

Wireless HART 2.4GHz, Open Standard, MAC addressing www.hartcomm2.org

Formatted: Font: Bold

Page 47 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development EkaNet - www.ekasystems.com

Version 0_2_1

Deleted: 2

Deleted: [should we include: ¶ <#>ANT – 2.4GHz, very low power (10 years on a watch battery), 1 million nodes in operation – but proprietary, www.thisisant.com ¶ <#>SimpliciTI - TI Website¶ Formatted: Bulleted + Level: 1 + Aligned at: 0.63 cm + Tab after: 1.27 cm + Indent at: 1.27 cm Deleted: ¶ Coronis - www.coronis.com Formatted: Default Paragraph Font Deleted: <#>Wibree www.wibree.com¶ <#>Wireless HART – 2.4GHz, Open Standard, MAC addressing www.hartcomm2.org¶ <#>etc ?]¶ Formatted: Bullets and Numbering

Deleted: 7-Apr-08

Page 48 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

7

Network Protocol Options

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.
Protocol Description: Used by/for: For: 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) IPv6

Notes: Protocol Description: Used by/for: For: Against: Notes: Protocol Description: Used by/for: For: Against: Notes: 6lopan IPv4

[please add any additional tables as required]

Deleted: 7-Apr-08

Page 49 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

8

Frequency Considerations

Placeholder to capture and discuss the available licensed and unlicensed wireless frequency options for local communications. 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.

Formatted: Bullets and Numbering

8.1 Frequency Information
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 [need to add range claims and real world results] Efficient power per distance 169MHz Licensed band Paging band, delegated to AMR [need to add range claims and real world results] Efficient power per distance

Deleted: In general, propagation degrades as frequency increases, but specific examples/tests should be included where possible.

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

Can purchase bandwidth from Ofcom. 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)
Deleted: 7-Apr-08

Page 50 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Frequency Description: Used by/for: Signal Propagation: Power requirements: Longevity of frequency allocation: Notes: 433-434MHz 433-434MHz Unlicensed ISM band

Version 0_2_1

Deleted: 2

Well used frequency, typically used for car key fobs. Has been used for heat metering in Europe Good [need to add range claims and real world results] More battery efficient than higher frequency options

Support (by existing chips) for open standards is not evident Security may be an issue (e.g. for financial transactions) 868-870MHz 868-870MHz Unlicensed European ISM band (915MHz in North America) Z-Wave, Wireless M Bus, ZigBee, Wavenis. Minimal usage in other applications. Good [need to add range claims and real world results] Has well defined maximum duty cycles and transmission powers (5mW to 25mW).

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

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.45 2.45GHz Unlicensed worldwide ISM band ZigBee, WiFi, Bluetooth, Microwave Ovens, Home Video repeaters Compromised by building construction [need to add range claims and real world results]

Deleted: R

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

Use of spread spectrum and other techniques to manage 16 available channels No limits on transmit duty cycle
Deleted: 7-Apr-08

[please add any additional tables or information as required] Page 51 of 63 15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

8.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)6. 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.

Formatted: Bullets and Numbering Formatted: Normal

8.3 Spread Spectrum
Placeholder to discuss properties of spread spectrum and channel usage as done, for example, by 2.4GHz devices.

Formatted: Bullets and Numbering

Formatted: Heading 2

8.4 Local Communications Group 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.
6

Formatted: Bullets and Numbering

Formatted: Font: Italic

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

Formatted: English (U.K.) Deleted: 7-Apr-08

Consultants 2007

Page 52 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

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

Formatted: Bullets and Numbering

Formatted: Bullets and Numbering

Formatted: Numbered + Level: 1 + Numbering Style: 1, 2, 3, … + Start at: 1 + Alignment: Left + Aligned at: 0.63 cm + Tab after: 1.27 cm + Indent at: 1.27 cm

Formatted: Numbered + Level: 1 + Numbering Style: 1, 2, 3, … + Start at: 1 + Alignment: Left + Aligned at: 0.63 cm + Tab after: 1.27 cm + Indent at: 1.27 cm Formatted: Centered Formatted: Font: 10 pt Formatted Table Formatted: Centered Formatted: Font: 10 pt Formatted: Centered Formatted Formatted: Font: 10 pt Formatted Formatted: Centered Formatted: Font: 10 pt Formatted: Centered Formatted Formatted Formatted: Centered Formatted Formatted: Centered Formatted Formatted Formatted: Bullets and Numbering Deleted: 7-Apr-08 ... [12] ... [13] ... [11] ... [9] ... [10] ... [8] ... [7]

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. Page 53 of 63 15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

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’ 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://srsmlocalcomms.wetpaint.com/page/UK+Field+Test+for+Frequency+Com parison

Formatted: Bullets and Numbering

Deleted: 7-Apr-08

Page 54 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

9

Data Exchange Format Options

Placeholder to document the potential data exchange format options that could be used for Local Communications. A number of these may be specifically linked to the physical media solution.
Data Exchange Format Description: ANSI

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

Used by/for: For: Against: Notes: Data Exchange Format Description: Used by/for: For: Against: Notes:

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

Obis/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) Parts of the standard are used in MBUS implementations.
Deleted: Data Exchange Format ... [14]

Data Exchange Format Description: Used by/for: For: Against: Notes:

STS

Used in South Africa for two way data exchanges with credit and prepayment smart meters

Link - http://www.sts.org.za/resourcestudio/introductiontothests/
Deleted: 7-Apr-08

Page 55 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

Data Exchange Format Description: Used by/for: For: Against:

XML

Global standard for data exchanges, used in an increasing number of areas 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.

Notes:

[please add any additional tables as required]

Deleted: 7-Apr-08

Page 56 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

10 Evaluation Options
Placeholder for consideration of solution options – includes proposed method for a desktop exercise in 10.2. Could also include real world testing opportunities such as plug fests and results from field trials. Completion of the information within this section will be an iterative process to establish and refine requirements and evaluation criteria concurrently in the context of the available solutions.

10.1 Data Traffic Models
To support the evaluation of combinations of options, some basic modelling of data exchanges will be required. A number of scenarios and profiles should be considered to support a range of Local Communications applications. These could include: - transmission of consumption and tariff information from meter to display device - transmission of 24 hours of interval data from gas/water meter to electricity meter - etc It is not envisaged that large data files will be transmitted, or streamed, using the Local Communications solution. However, the solution should not place an upper limit on the size of data transmissions, other solutions exist for such applications and should be the obvious choice. The development exercise should create a recommendation that provides a platform suitable for the majority of Local Devices and uses, but which does not constrain innovation.

10.1.1 Data Traffic Activities
This section of the document presents a series of sample data traffic activities to assist with assessing the solution options.
Activity Ref Element Register ID Register Reading Notes: DA1 Activity Name Size (bits) 10B 10B Meter Reading (simple) Instances 1 1 Total Size 20B

Typical expectation for a gas meter reading

[Some help to ensure we’re capturing the right information here would be appreciated]
Activity Ref Element DA2 Activity Name Size (bits) Meter Reading (complex) Instances
Deleted: 7-Apr-08

Page 57 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Activity Ref Element Register ID Register Reading Notes: DA2 Activity Name Size (bits) 10B 10B

Version 0_2_1

Deleted: 2

Meter Reading (complex) Instances 6 6 Total Size 120B

Import and export registers for an electricity meter operating with a 3 rate tariff

10.1.2 Data Traffic Usage Profiles
Placeholder to combine activities into sample usage profiles – e.g. daily messages of interval data, weekly use of debit functionality, regular refresh of energy display. This will assist with assessing the suitability of solution options to meet ‘typical’ requirements.
Profile Ref Activity DA2 DA6 DP1 Weekly Etc. Profile Name From Meter Weekly Electricity Reading To Supplier Total Size 120B

Frequency

[Some help to ensure we’re capturing the right information here would be appreciated – the list of process types in 5.4 could be used as a foundation]

10.2 Solution Evaluation Matrix
[The proposal for evaluation shown below is an illustration of a process that could be followed – the group should determine the most appropriate method here, which could include the addition of weighting to criteria or the addressing the concept that ‘highest score=best solution’ is not as straightforward as it appears]. The table below assesses each of the solution options from section 6 against criteria derived from the other sections of this document. Each solution has been assessed by the Local Communications Development Group against criteria agreed by the group. Where relevant, explanations of scores are provided in the supplementary table. Scoring is 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 [Note: includes examples for illustration purposes only]
Deleted: 7-Apr-08

Page 58 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Solution Bluetooth

Version 0_2_1

Deleted: 2

Criteria C.1 C.2 Interoperable Security features of solution (see 5.5 for reference measures) Solution is available today (see factor F.5) Multiple Source Supply Chain Cost of solution Volumes deployed for smart metering Total Score

C.3

5

5

0

0

0

0

10.2.1 Evaluation Matrix Notes
In order to provide a complete record of the evaluation process, any notes and explanatory text are shown in the table below.
Criteria C.3 C.5 Solution Bluetooth KNX Score 5 Notes/Explanation 800 million devices sold in 2007

Z Wave 0

ZigBee

M Bus

KNX

WiFi

Deleted: 7-Apr-08

Page 59 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

11 Issues
The table below provides an ongoing record of issues for consideration and potential actions to resolve.
No I.1 Issue Description Data exchange from local device to remote service provider – e.g. from Local Data format to WAN Data format. Does the format need to be consistent in order for a boiler diagnostic alert to reach the end recipient? Discussed in 4.5 above Issues with meter location/property type – e.g. meters in meter rooms in multioccupant premises. Requirement R.9 needs refining to cover the potential/commercial WAN comms issues where the two fuels are supplied by different companies Future flexibility – how do we account for ZigBee 2.0 or Z-Wave Extra? Smart meter assets will have a useful life in excess of 10 years, and those installed on day one should still be compatible with as many applications as possible throughout their installed life. Definition of a required network topology for Local Communications – is the meter expected to be a node in a network, or the master of a network? Potentially both – a meter should be the master of ‘utility’ processes and networks that are specifically related to smart metering. At the same time, smart meters should also be capable of being part of a wider ‘connected home’ network. Also need to consider what this would mean in relation to the last mile. Use of mesh network topology to securely transmit data. Use of wired/wireless repeaters. Resolution Options

I.2

I.3

I.4

I.5

I.6

Added by Ian Graham of Landis+Gyr
As the UK market allows Customers to change suppliers of Gas/Electricity, and there is confidentiality of data between different suppliers, (and indeed historical suppliers), what requirements are there for data segregation/encryption within the Local Network?

Added by Ian
Assume that an external independent agent (on the LAN) is responsible for ensuring only permissible data is transferred in/out of the LAN/HAN

I.7

Relating to requirement R2 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.

Understand the implications of the requirement by working through some practical examples.

Deleted: 7-Apr-08

Page 60 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
This may be challenging if Local Communications supports a restricted set of functionality with regard to data and commands. I.8

Version 0_2_1

Deleted: 2

From EDF Energy
Metal meter cabinets (mantel units) could adversely impact wireless signals

Formatted: Font: Italic

I.9

From EDF Energy
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

12 References
Shown below are references to relevant materials and resources.
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 View Online

[reference to materials required]

EN 62053-61

Electricity Metering Equipment – Particular Requirements – Part 61 – Power Consumption and Voltage Requirements
Wireless Network Report Detailed report on wireless networks, including a technical comparison of ZigBee and ANT networks Report by Schneider Electric investigating the potential interference issues where ZigBee and WiFi networks coexist – 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

Link to IEC Page for Standard

View Online

ZigBee & WiFi Coexistence Report

View Online

OpenHAN 2008 Home Area Network System Requirements Specification v1 Release

Download Word Document

Deleted: 7-Apr-08

Page 61 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development
Candidate

Version 0_2_1

Deleted: 2

[please add any additional resources as relevant]

Deleted: 7-Apr-08

Page 62 of 63

15-Apr-08

SRSM and Beyond – Local Communications Development

Version 0_2_1

Deleted: 2

Appendix: Schedule [X] of Operational Framework
Placeholder for insertion of final documented standard for local communications, including specific protocols and data exchange formats. This could/should just reference the standards for local communications and potentially the data schema(s).

Deleted: 7-Apr-08

Page 63 of 63

15-Apr-08

Page 3: [1] Deleted

Simon Harrison

4/15/2008 7:01:00 PM

Table of Contents................................................................................................ 2 Figures ................................................................................................................ 3 Document Control ............................................................................................... 4 1.1 Version History..................................................................................... 4 1.2 Review Group ...................................................................................... 5 1.3 Intellectual Property Rights and Copyright.......................................... 5 1.4 Disclaimer............................................................................................. 5 2 Executive Summary and Introduction ......................................................... 6 2.1 Executive Summary ............................................................................. 6 2.2 Purpose ................................................................................................ 6 2.3 Scope ................................................................................................... 6 2.4 Objective .............................................................................................. 6 2.5 Structure of this Document .................................................................. 6 3 Glossary & Conventions.............................................................................. 8 3.1 Document Conventions ....................................................................... 8 3.1.1 Meter Location .............................................................................. 8 3.1.2 Meter and Metering System ......................................................... 8 3.2 Glossary ............................................................................................. 10 4 Local Communications Context ................................................................ 12 4.1 General Context ................................................................................. 12 4.2 Smart Utility Context for Local Communications .............................. 13 4.3 Smarter Display Options Using Local Communications ................... 14 4.4 Smart Home Context ......................................................................... 16 4.5 One Interoperability Size Fits All? ..................................................... 17 4.6 A National Standard........................................................................... 19 4.7 Delivering the Last Mile ..................................................................... 19 4.8 Local Device Classification................................................................ 20 4.9 Existing Standards ............................................................................. 21 5 Energy Supplier Requirements ................................................................. 22 5.1 Other Factors ..................................................................................... 24 5.2 Potential Additional Requirements .................................................... 27 5.3 Other Requirements........................................................................... 27 5.4 Processes/Activities Required........................................................... 27 5.5 Security............................................................................................... 28 5.6 Independent Local Networks ............................................................. 29 5.7 Wireless to Wired ............................................................................... 33 5.8 Addressing Protocol........................................................................... 34 5.9 Local Communications Principles ..................................................... 34 6 Solution Options ........................................................................................ 36 7 Network Protocol Options ......................................................................... 43 8 Frequency Considerations ........................................................................ 44 8.1 Frequency Information ....................................................................... 44 8.2 Spread Spectrum ............................................................................... 45 9 Data Exchange Format Options................................................................ 46 10 Evaluation Options................................................................................. 47

10.1 Data Traffic Models............................................................................ 47 10.1.1 Data Traffic Activities.................................................................. 47 10.1.2 Data Traffic Usage Profiles ........................................................ 48 10.2 Solution Evaluation Matrix ................................................................. 48 10.2.1 Evaluation Matrix Notes ............................................................. 49 11 Issues ..................................................................................................... 50 12 References............................................................................................. 51 Appendix: Schedule [X] of Operational Framework......................................... 52
Page 3: [2] Deleted Simon Harrison 4/15/2008 7:02:00 PM

Figure 1: Smart Meter Locations ........................................................................ 8 Figure 2: Smart Metering Systems, Illustration of Flexible Approaches ........... 9 Figure 3: SRSM Operational Framework Scope ............................................. 12 Figure 4: Smart Utility Context ......................................................................... 14 Figure 5: Smart Display Context ...................................................................... 15 Figure 6: Smart Home Context......................................................................... 16 Figure 7: Smart Home Context & Clusters....................................................... 17 Figure 8: End to End Interoperability................................................................ 17 Figure 9: Distinct Local and WAN Interoperability ........................................... 18 Figure 10: Making Interoperability Work .......................................................... 18 Figure 11: Interoperability Illustration Using Water ......................................... 19 Figure 12: Local Communications for the Last Mile ........................................ 20 Figure 13: Simple Collection of Smart Meters and Local Devices .................. 29 Figure 14: Independent Networks .................................................................... 30 Figure 15: Local Communication Signal Range .............................................. 30 Figure 16: Overlapping Wireless Ranges ........................................................ 31 Figure 17: Required Local Comms Range Example ....................................... 32 Figure 18: Mesh Network to Concentrator ....................................................... 32 Figure 19: Interoperability via Web Services Interfaces .................................. 34
Page 37: [3] Deleted Simon Harrison 4/9/2008 11:57:00 AM

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

Bluetooth

www.bluetooth.com

Low power radio for personal area networks with up to seven nodes Single chip radios available from a wide variety of suppliers. Circa $5 per end 1 MBit/sec High power consumption - 5000µA 2.4GHz

Mobile telephony

Use in other markets: Maturity: Support for ‘Last Mile’: For: Against: Notes:
Page 37: [4] Deleted Simon Harrison 4/15/2008 4:46:00 PM

Several years old

Poor range and propagation Only supports 8 nodes

Solution Description: Hardware: Cost: Data:

HomePlug

www.homeplug.org

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 Circa $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. Wired Solution Open standard

Power: Frequencies: Protocols: Data Exchange Format: Use in other applications: Use in other markets: Maturity: Support for ‘Last Mile’: For: Against: Notes:
Page 37: [5] Deleted Simon Harrison 4/9/2008 12:37:00 PM

Use in homes to network Ethernet devices

Homeplug standard is reasonably mature. Command and Control is a recent development

Reliable communications unaffected by the building fabric. Integration with gas meters not readily available. May be affected by electrical noise on the mains.

Solution Description:

KNX

www.knx.org

Solution developed in Germany, primarily for building automation purposes. Supports wired (twisted pair and power line) and wireless Standard available as EN 50090, EN 13321-1, ISO/IEC 14543

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:
Page 39: [6] Deleted Simon Harrison 4/9/2008 12:02:00 PM

868MHz

Significant deployment in building management and automation – is the standard used at Heathrow’s terminal 5 building.

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

WiFi

www.wiwww.wi-fi.org

Up to and beyond 54mb/s Power consumption is very high compared to other options. 2.4GHz

Many existing solutions – already used in homes for internet connections.

Use in other markets: Maturity: Support for ‘Last Mile’: For: Against: Notes:
Page 53: [7] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Complex network configuration. Does not support mesh networks.

Font: 10 pt
Page 53: [7] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [7] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [7] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [7] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [7] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [7] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [7] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [7] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [7] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [8] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [8] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [8] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [8] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [8] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [8] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [8] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [8] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [8] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [8] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [9] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [9] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [9] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [9] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [9] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [9] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [9] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [9] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [9] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [9] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [10] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [10] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [11] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [11] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [11] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [11] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [11] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [11] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [11] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [11] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [11] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [11] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [12] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [12] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [12] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [12] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [12] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [12] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [12] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [12] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [12] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [12] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [13] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [13] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [13] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [13] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [13] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [13] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [13] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [13] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [13] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [13] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 53: [13] Formatted Simon Harrison 4/15/2008 6:27:00 PM

Font: 10 pt
Page 55: [14] Deleted Simon Harrison 4/15/2008 4:04:00 PM

Data Exchange Format Description: Used by/for: For: Against: Notes:

Obix