SRSM Local Communications Development 0 - 4 Marked

SRSM and Beyond
Local Communications Development
Note: Formatted: Font: Monotype Corsiva

V0_4 is an interim draft of the report, prepared in Formatted: Border: Box: (Single solid
advance of the 29th October 08 meeting of the Local line, Auto, 0.5 pt Line width)
Comms group. Formatted: Font: Monotype Corsiva,

Superscript
It contains an amount of draft detail that will be
addressed at that meeting. Formatted: Font: Monotype Corsiva
V0_5 will be published shortly following the meeting

and this will be the version open to public review and
comment prior to submission to the SRSM Steering
Group for approval. Formatted: Font: Monotype Corsiva,
English (United Kingdom)
Author(s) Simon Harrison

Document Draft
Status
Document Ref. SRSM LCD
No.
Document 0_43
Version
Date Issued 27 SeptemOctober 2008
SRSM and Beyond – Local Communications Development Version 0_43
Table of Contents
Table of Contents ...............................................................................................2
Figures .............................................................................................................63
Tables ..............................................................................................................74
Document Control ............................................................................................95
1.1 Version History ..................................................................................95
1.2 Review Group & Website ............................................................... 106
1.3 Intellectual Property Rights and Copyright ..................................... 127
1.4 Disclaimer ....................................................................................... 127
2 Executive Summary and Introduction .................................................... 138
2.1 Executive Summary ....................................................................... 138
2.2 Purpose .......................................................................................... 138
2.3 Scope ............................................................................................. 138
2.4 Objective......................................................................................... 138
2.5 Structure of this Document ............................................................. 138
3 Glossary & Conventions ...................................................................... 1510
3.1 Document Conventions ................................................................ 1510
3.1.1 Market Segments .................................................................. 1510
3.1.2 Meter Functionality ................................................................ 1510
3.1.3 Meter Location ...................................................................... 1611
3.1.4 Meter and Metering System .................................................. 1611
3.2 Glossary ....................................................................................... 1813
4 Local Communications Context ........................................................... 2620
4.1 General Context ........................................................................... 2620
4.2 Smart Utility Context for Local Communications .......................... 2721
4.3 Smarter Display Options Using Local Communications .............. 2822
4.4 Smart Home Context .................................................................... 3024
5 Associated Topics................................................................................ 3327
5.1 A National Standard ..................................................................... 3327
5.2 Security......................................................................................... 3327
5.3 Delivering the Last Mile ................................................................ 3428
5.4 Local Device Classification .......................................................... 3529
5.5 Processes/Activities Required...................................................... 3629
5.6 Types of Data ............................................................................... 3630
5.7 Independent & Private Local Networks ........................................ 3731
5.8 Wireless to Wired Options ............................................................ 4235
5.8.1 Wired/Wireless Protocol Development ................................. 4336
5.9 British Housing Types .................................................................. 4436
5.9.1 Houses By Type .................................................................... 4437
6 Principles & Assumptions .................................................................... 4739
6.1 Local Communications Principles ................................................ 4739
6.2 Local Communications Assumptions ........................................... 4839
7 Requirements ...................................................................................... 4941
7.1 Requirements ............................................................................... 4941
7.2 Requirements Notes..................................................................... 5143
7.3 Potential Additional Requirements ............................................... 5345
8 Solution Options .................................................................................. 5446
8.1 Solution Options Descriptions ...................................................... 5547
8.2 Other Solution Options ................................................................. 6657
Page 2 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
9 Additional Considerations .................................................................... 7162

9.1 Network & Addressing Protocols .................................................. 7162
9.2 Frequency Considerations ........................................................... 7364
9.2.1 Frequency Information .......................................................... 7364
9.2.2 Licensed or Unlicensed ......................................................... 7566
9.3 Data Exchange Format Options ................................................... 7566
10 Evaluation of Solution Options ......................................................... 7869
10.1 Evaluation Process....................................................................... 7869
10.2 Evaluation Methodologies ............................................................ 7969
10.2.1 Evaluation Weighting ............................................................ 7969
10.2.2 Evaluation Assessment ......................................................... 7970
10.3 Evaluation Criteria ........................................................................ 8070
10.4 Evaluation Scorecard ................................................................... 8373
10.4.1 Evaluation Notes ................................................................... 8676
10.5 Evaluation Scenarios................................................................ 124107
11 Recommendations ....................................................................... 125108
11.1 Testing & Evaluating Criteria .................................................... 126109
11.2 Solution Summary Statements ................................................. 130112
11.2.1 Bluetooth low energy......................................................... 130113
11.2.2 Wavenis ............................................................................ 130113
11.2.3 Wireless MBus .................................................................. 131113
11.2.4 ZigBee @ 868MHz ............................................................ 131114
11.2.5 ZigBee @ 2.4GHz ............................................................. 131114
11.2.6 Z Wave .............................................................................. 131114
12 Issues ........................................................................................... 133115
13 References ................................................................................... 135116
Appendix A: Referential Integrity Check ................................................. 136117
Appendix B: Last Mile Evaluation ........................................................... 138119
Last Mile Criteria .............................................................................. 138119
Appendix C: Initial Field Test ................................................................. 139120
Appendix D: ZigBee@2.4GHz Evaluation Introduction .......................... 141122
Preamble – On using ZigBee for UK Smart Metering Local
Communications .............................................................................. 141122
Figures ...............................................................................................................3
Tables ................................................................................................................3
Document Control ..............................................................................................5
1.1 Version History ....................................................................................5
1.2 Review Group & Website ....................................................................6
1.3 Intellectual Property Rights and Copyright ..........................................7
1.4 Disclaimer ............................................................................................7
2 Executive Summary and Introduction .........................................................8
2.1 Executive Summary ............................................................................8
2.2 Purpose ...............................................................................................8
2.3 Scope ..................................................................................................8
2.4 Objective..............................................................................................8
2.5 Structure of this Document ..................................................................8
3 Glossary & Conventions ...........................................................................10
3.1 Document Conventions .....................................................................10
3.1.1 Market Segments .......................................................................10
3.1.2 Meter Functionality .....................................................................10
Page 3 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
3.1.3 Meter Location ...........................................................................11

3.1.4 Meter and Metering System .......................................................11
3.2 Glossary ............................................................................................13
4 Local Communications Context ................................................................16
4.1 General Context ................................................................................16
4.2 Smart Utility Context for Local Communications ...............................17
4.3 Smarter Display Options Using Local Communications ...................18
4.4 Smart Home Context .........................................................................20
5 Associated Topics.....................................................................................23
5.1 A National Standard ..........................................................................23
5.2 Security..............................................................................................23
5.3 Delivering the Last Mile .....................................................................24
5.4 Local Device Classification ...............................................................25
5.5 Processes/Activities Required...........................................................25
5.6 Types of Data ....................................................................................26
5.7 Independent & Private Local Networks .............................................27
5.8 Wireless to Wired Options .................................................................31
5.8.1 Wired/Wireless Protocol Development ......................................32
5.9 British Housing Types .......................................................................32
5.9.1 Houses By Type .........................................................................33
6 Principles & Assumptions .........................................................................35
6.1 Local Communications Principles .....................................................35
6.2 Local Communications Assumptions ................................................35
7 Requirements ...........................................................................................37
7.1 Requirements ....................................................................................37
7.2 Requirements Notes..........................................................................39
7.3 Potential Additional Requirements ....................................................41
8 Solution Options .......................................................................................42
8.1 Solution Options Descriptions ...........................................................43
8.2 Other Solution Options ......................................................................53
9 Additional Considerations .........................................................................58
9.1 Network & Addressing Protocols .......................................................58
9.2 Frequency Considerations ................................................................60
9.2.1 Frequency Information ...............................................................60
9.2.2 Licensed or Unlicensed ..............................................................62
9.3 Data Exchange Format Options ........................................................62
10 Evaluation of Solution Options ..............................................................65
10.1 Evaluation Process............................................................................65
10.2 Evaluation Methodologies .................................................................65
10.2.1 Evaluation Weighting .................................................................65
10.2.2 Evaluation Assessment ..............................................................66
10.3 Evaluation Criteria .............................................................................66
10.4 Evaluation Scorecard ........................................................................69
10.4.1 Evaluation Notes ........................................................................72
10.5 Last Mile Evaluation ....................................................................... 103
10.5.1 Last Mile Criteria ..................................................................... 103
10.5.2 Last Mile Evaluation Scorecard .............................................. 104
10.5.3 Last Mile Evaluation Notes ..................................................... 104
10.6 Evaluation Results.......................................................................... 104
10.7 Evaluation Scenarios...................................................................... 105
11 Recommendation ............................................................................... 106
Page 4 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
12 Issues ................................................................................................. 107

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

8.2 Other Solution Options ......................................................................51
9 Additional Considerations .........................................................................56
9.1 Network & Addressing Protocols .......................................................56
9.2 Frequency Considerations ................................................................58
9.2.1 Frequency Information ...............................................................58
9.2.2 Licensed or Unlicensed ..............................................................60
9.3 Data Exchange Format Options ........................................................60
10 Evaluation of Solution Options ..............................................................63
10.1 Evaluation Process............................................................................63
10.2 Evaluation Methodologies .................................................................63
10.2.1 Evaluation Weighting .................................................................64
10.2.2 Evaluation Scoring .....................................................................64
10.3 Evaluation Criteria .............................................................................64
Evaluation Scorecard ............................................................................68
10.4...............................................................................................................68
10.4.1 Evaluation Notes ........................................................................71
10.5 Last Mile Evaluation ..........................................................................71
10.5.1 Last Mile Criteria ........................................................................71
10.5.2 Last Mile Evaluation Scorecard .................................................72
10.5.3 Last Mile Evaluation Notes ........................................................72
10.6 Evaluation Results.............................................................................72
10.7 Evaluation Issues Table ....................................................................72
10.8 Evaluation Scenarios.........................................................................73
11 Recommendation ..................................................................................74
12 Issues ....................................................................................................75
13 References ............................................................................................76
Appendix A: Initial Field Test ..........................................................................77
Figures
Figure 1: Smart Meter Locations ................................................................ 1611
Figure 2: Smart Metering Systems, Illustration of Flexible Approaches ..... 1712
Figure 3: SRSM Smart Metering Operational Framework Scope .............. 2620
Figure 4: Smart Utility Context .................................................................... 2822
Figure 5: Smart Display Context ................................................................. 2923
Figure 6: Smart Home Context ................................................................... 3024
Figure 7: Smart Home Context & Clusters ................................................. 3125
Figure 8 Different Uses of Local Communications ..................................... 3226
Figure 9: Local Communications for the Last Mile ..................................... 3428
Figure 10 Technical WAN Interoperability .................................................. 3731
Figure 11: Simple Collection of Smart Meters and Local Devices ............. 3831
Figure 12: Independent Networks............................................................... 3932
Figure 13: Local Communication Signal Range ......................................... 4033
Figure 14: Overlapping Wireless Ranges ................................................... 4133
Figure 15: Required Local Communications Range Example.................... 4134
Figure 16: Mesh Network to Concentrator .................................................. 4235
Figure 17 ZigBee & DLMS Illustration .................................................... 142123
Figure 1: Smart Meter Locations .........................................................................
Figure 2: Smart Metering Systems, Illustration of Flexible Approaches ..............
Figure 3: SRSM Operational Framework Scope .............................................16
Page 6 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Figure 4: Smart Utility Context .........................................................................18

Figure 5: Smart Display Context ......................................................................19
Figure 6: Smart Home Context ........................................................................20
Figure 7: Smart Home Context & Clusters ......................................................21
Figure 8 Different Uses of Local Communications ..........................................22
Figure 9: Local Communications for the Last Mile ..........................................24
Figure 10 Technical WAN Interoperability .......................................................27
Figure 11: Simple Collection of Smart Meters and Local Devices ..................27
Figure 12: Independent Networks....................................................................28
Figure 13: Local Communication Signal Range ..............................................29
Figure 14: Overlapping Wireless Ranges ........................................................29
Figure 15: Required Local Comms Range Example .......................................30
Figure 16: Mesh Network to Concentrator .......................................................31
Figure 17 ZigBee & DLMS Illustration .......................................................... 112
Figure 1: Smart Meter Locations .....................................................................10
Figure 2: Smart Metering Systems, Illustration of Flexible Approaches ..........11
Figure 3: SRSM Operational Framework Scope .............................................15
Figure 4: Smart Utility Context .........................................................................17
Figure 5: Smart Display Context ......................................................................18
Figure 6: Smart Home Context ........................................................................19
Figure 7: Smart Home Context & Clusters ......................................................20
Figure 8 Different Uses of Local Communications ..........................................21
Figure 9: Local Communications for the Last Mile ..........................................23
Figure 10 Technical WAN Interoperability .......................................................26
Figure 11: Simple Collection of Smart Meters and Local Devices ..................26
Figure 12: Independent Networks....................................................................27
Figure 13: Local Communication Signal Range ..............................................28
Figure 14: Overlapping Wireless Ranges ........................................................28
Figure 15: Required Local Comms Range Example .......................................29
Figure 16: Mesh Network to Concentrator .......................................................30
Tables
Table 1 Local Communications Group Members ......................................... 117
Table 2 Glossary ......................................................................................... 2519
Table 3 Stock Profile - English House Condition Survey 2005................... 4537
Table 4 Type of Dwelling - Scottish House Condition Survey 2004/5 ........ 4538
Table 5 1998 Welsh House Condition Survey ............................................ 4538
Table 6 'Overall' British Housing Type Volumes ......................................... 4538
Table 7 Local Communications Principles .................................................. 4839
Table 8 Local Communications Assumptions............................................. 4840
Table 9 Local Communications Requirements ........................................... 5143
Table 10 Local Communications Requirements Notes .............................. 5345
Table 11 Solution Options Guide ................................................................ 5547
Table 12 Bluetooth low energy ................................................................... 5648
Table 13 M-Bus ........................................................................................... 5748
Table 14 Wavenis ....................................................................................... 5850
Table 15 ZigBee @ 868MHz ...................................................................... 5951
Table 16 ZigBee @ 2.4GHz ........................................................................ 6354
Table 17 Z-Wave ........................................................................................ 6657
Table 18 Evaluation Criteria ....................................................................... 8373
Page 7 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Table 19 Evaluation Scorecard................................................................... 8676

Table 20 Evaluation Notes ...................................................................... 122107
Table 21 Evaluation Scenario Suggestions ............................................ 124107
Table 22 Evaluation Testing Recommendations .................................... 130112
Table 23 Issues ....................................................................................... 133115
Table 24 References............................................................................... 135116
Table 25 Referential Integrity .................................................................. 138119
Table 26 Last Mile Evaluation Criteria .................................................... 138119
Table 27 Field Test Results .................................................................... 140121
Table 1 Local Communications Group Members ..............................................6
Table 2 Glossary ..............................................................................................15
Table 3 Stock Profile - English House Condition Survey 2005........................33
Table 4 Type of Dwelling - Scottish House Condition Survey 2004/5 .............34
Table 5 1998 Welsh House Condition Survey .................................................34
Table 6 'Overall' British Housing Type Volumes..............................................34
Table 7 Local Communications Principles.......................................................35
Table 8 Local Communications Assumptions..................................................36
Table 9 Local Communications Requirements ................................................39
Table 10 Local Communications Requirements Notes ...................................41
Table 11 Solution Options Guide .....................................................................43
Table 12 Bluetooth low energy ........................................................................44
Table 13 M-Bus ................................................................................................44
Table 14 Wavenis ............................................................................................46
Table 15 ZigBee @ 868MHz ...........................................................................47
Table 16 ZigBee @ 2.4GHz .............................................................................50
Table 17 Z-Wave .............................................................................................53
Table 18 Evaluation Criteria ............................................................................69
Table 19 Evaluation Scorecard ........................................................................72
Table 20 Evaluation Notes ............................................................................ 103
Table 21 Last Mile Evaluation Criteria .......................................................... 103
Table 22 Last Mile Evaluation Scorecard ..................................................... 104
Table 23 Last Mile Evaluation Notes ............................................................ 104
Table 24 Evaluation Scenario Suggestions .................................................. 105
Table 25 Issues ............................................................................................. 107
Table 26 References..................................................................................... 108
Table 27 Field Test Results .......................................................................... 110
Formatted: Normal
Page 8 of 143 27-Oct-0827-Oct-0820-

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

Operational Framework Proposals and Options v1 document, published by the
Energy Retail Association in August 2007 – the development document history
of which is shown below.
Page 9 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Version Date Author Description

th
0.1 17 July 2007 Simon Harrison Initial draft based upon original consolidated
SRSM Communications Solution Options
document.
th
0.2 25 July 2007 Alastair Minor update following review
Manson
0.3 6th August 2007 Simon Harrison Update for Operational FrameworkSmart
Metering Operational Framework publication
0.4 December 2007 Simon Harrison Updated following consultation exercise.
Updated following project workshop
Updated following receipt of related papers from
stakeholders
Document passed to Local Communications Development Group for ongoing development
1.2 Review Group & Website

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

Oct-0830-Sep-08
Orsis PRI UK Ltd

Q’Vedis Radiocrafts
Remote Energy Monitoring Renesas Technology
ScottishPower Scottish & Southern Energy
Sensus Metering Services Sentec
Siemens Energy Services Sustainability First
Society of British Gas Industries Secure Electrans
theowl.com Tridium
Trilliant Networks Utilihub
Zensys ZigbeeZigBee Alliance Formatted: Keep with next
Energy Retail Association Engage Consulting
British Gas EDF Energy
E.ON UK Npower
ScottishPower Scottish & Southern Energy
Alcatel-Lucent Alertme.com
All Island Power Association of Meter Operators
Arm Arqiva
Atmel British Electrotechnical & Allied
Manufacturers Association
BERR BGlobal Metering
Cambridge Consultants Cambridge Silicon Radio
Cason Engineering Coronis
Daintree Networks Data Direct
DEFRA Echelon
Electralink Elster
Ember Ewgeco
Federation of Communication FreescaleFirst Utility
Services
Freescale
Fujitsu Green Energy Options
Himsley Meter Revenue Services Horstmann
I+P Services Imserv
Ingenium Itron
Laird Technologies Acute Technology
Landis+Gyr Low Power Radio Association
Microsoft More Associates
National Grid Ofcom
Ofgem Onzo
Orsis PRI UK Ltd
Q’Vedis Radiocrafts
Remote Energy Monitoring Renesas Technology
Society of British Gas Industries Secure Electrans
Sensus Metering Services Sentec
Siemens Energy Services Sustainability First
theowl.com Tridium
Trilliant Networks Utilihub
Zensys ZigbeeZigBee Alliance Formatted: Keep with next
Table 11 Local Communications Group Members Formatted: Style Caption + Centered
Page 11 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Full details of the membership of the group, its’ meetings and papers can be
viewed at the public website: srsmlocalcomms.wetpaint.com Field Code Changed
1.3 Intellectual Property Rights and Copyright

All rights including copyright in this document or the information contained in it
are owned by the Energy Retail Association and its members. All copyright
and other notices contained in the original material must be retained on any
copy that you make. All other use is prohibited. All other rights of the Energy
Retail Association and its members are reserved.
1.4 Disclaimer
This document presents proposals and options for the operation of smart
metering in Great Britain. We have used reasonable endeavours to ensure the
accuracy of the contents of the document but offer no warranties (express or
implied) in respect of its accuracy or that the proposals or options will work. To
the extent permitted by law, the Energy Retail Association and its members do
not accept liability for any loss which may arise from reliance upon information
contained in this document. This document is presented for information
purposes only and none of the information, proposals and options presented
herein constitutes an offer.
Page 12 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
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
optionssolution options for two-way Local Communication for smart Metering
Systems.
It also includes an evaluation of solutions optionssolution options and

recommendations for further consideration.
Any statement of preference for particular communications solution options

does not constitute a firm or binding decision by the Suppliers participating in
the Supplier Requirements for Smart Metering (SRSM) project.
Further information on the SRSM project is available from:

http://www.energy-retail.org.uk/smartmeters. Field Code Changed
2.3 Scope
The scope of this document is limited to the requirement for two way
communications between smart gas and electricity meters and local devices.
For ease of understanding and application to a familiar domestic context, this

document refers mainly to the ‘Home’ and uses illustrations of houses to
represent locations for meter points. However, the communications solution
options listed here could apply equally to non-domestic premises – i.e. Local
Communications within an office or factory.
This document references, but does not define, the opportunity to use the
Local Communications capability of a smart meter to provide a ‘Last Mile’
option to deliver WAN Communications.
This document does not address the commercial issues arising from
communications requirements.
2.4 Objective
The objective of the Local Communications Development exercise is to fully
document and evaluate the options relating to Local Communications for
smart metering, and if possible to produce a solution recommendation (or
recommendations) to the ERA SRSM Steering Group.
2.5 Structure of this Document

The sections of this document are:
Page 13 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
- Document Definition
o Section 1 – Document Control
o Section 2 – Introduction
o Section 3 – Glossary and Document Conventions
- Local Communications Context
o Section 4 – Local Communications Context – a plain English
explanation of the context for smart metering and local
communicationsLocal Communications
o Section 5 –Associated Topics – information on related topics
considered by the SRSM project or the Local Communications
Development Group
- Requirements
o Section 6 – Principles and Assumptions – established by the Local
Communications Development Group
o Section 7 – Local Communications Requirements
- Solution Options
o Section 8 – Definition of the solution options considered by the
Group using a standard proforma
o Section 9 – Additional Considerations – providing detail on key
solution related topics – frequency, protocols etc.
- Evaluation & Recommendation
o Section 10 – Evaluation Criteria and process completed by the Local
Communications Development Group
o Section 11 – Recommendations – by the Local Communications
Development Group to the SRSM Project Steering Group
- Additional
o Section 12 – Issues – ongoing and unresolved general issues
relating to Local Communications Solutions
o Section 13 – References – links to papers referred to by this report
o Appendixces – Referential Integrity table, Field test undertaken by
group members, Last Mile evaluation, ZigBee @ 2.4GHz additional
information
Page 14 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
3 Glossary & Conventions

3.1 Document Conventions
The ERA SRSM project has been running since September 2006, and has
established a number of practical conventions and assumptions with regard to
smart metering.
The project published Proposals and Options for a Smart Metering

Operational Framework in August 2007 – this document is over 300 pages in
length and presents comprehensive proposals to meet the practicalities of
operating smart metering in a competitive retail environment.
The following subsections give a brief overview of a number of these topics.

For a more complete summary of the Smart Metering Operational Framework,
please visit http://www.energy-retail.org.uk/smartmeters
3.1.1 Market Segments

The Operational FrameworkSmart Metering Operational Framework has been
written to address the requirements of energy Suppliers in the domestic retail
markets. However, it recognises that meters used in homes can actually be
exactly the same as meters used in businesses, and therefore the Operational
FrameworkSmart Metering Operational Framework proposals could apply.
Therefore, within this document, the solutions optionssolution options

discussed could be suitable for use in both domestic and equivalent non-
domestic markets.
3.1.2 Meter Functionality

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

• Interval measurement and storage of consumption data
• Support for flexible and configurable energy tariffs
• Interoperable data exchange and protocols
• Remote connection/disconnection1
• Support for prepayment/pay as you go operation (subject to the
footnote above)
1
For electricity, the inclusion of a switch/breaker/contactor has been agreed for all meters.
The inclusion of similar, valve-based functionality for all gas meters remains subject to cost.
Page 15 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
• Support for microgeneration

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

Throughout, this document refers mainly to the ‘Home’ and uses illustrations
of houses to represent locations for meter points. However, smart meters and
the communications solution options listed here could apply equally to other
domestic and non-domestic premises types.
Figure 1: Smart Meter Locations
The ERA Smart Metering Operational Framework documentation specifies

‘domestic-sized’ metering, and such meters could be installed in any type of
property where energy consumption is within the load/capacity capability of
such meters.
The Operational FrameworkSmart Metering Operational Framework includes

a number of Meter Variants, usually to accommodate specific energy supply
requirements of a metering point – e.g. polyphase electricity supply or a semi
concealed gas meter location (see definition of Meter Variant below).
Local Communications, unless specifically excluded by the Meter Variant

definition in the Operational FrameworkSmart Metering Operational
Framework, is required in all Meter Variants.
It is also the case that the placement and location of meters as shown in
diagrams is illustrative.
3.1.4 Meter and Metering System

Throughout this document, references to a smart meter, particularly within
diagrams, should not be interpreted as referring only to smart meters where all
of the functionality is contained within one ‘box’. There is regular use of a
picture of an electricity smart meter to represent smart Metering Systems.
Page 16 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Smart Metering Systems – Illustration of Flexible Approaches
Software
Smart Metering Metering System Illustration of how fuels could share

Metering System
Systems, with all using a separate (with suitable commercial
using a separate
the functionality, ‘black box’ and arrangements) a single set of black
‘black box’ (or
including external antenna box(es) to deliver functionality
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 by the SRSM project, a smart metering system could comprise a

number of physical devices (external modems, antennas etc.) to deliver the
smart functionality requirements.
The potential variety of physical locations and conditions of metering points

could result in smart metering systems where components are not located
together in the same metering cupboard, or on the same metering board. It
would not be practical to illustrate or explain these potential variations within
this document.
Therefore all general references to smart meters and uses of icons to

represent smart meters in this document should be inferred as meaning the
defined Metering System.
Page 17 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
3.2 Glossary
A number of these definitions are necessarily drawn directly from the Smart
Metering Operational FrameworkOperational Framework, as they apply
across the scope of that document and not just to Local Communications.
Term Meaning
3-DES An enhanced form of Data Encryption Standard, where the
cipher is used three times to increase the protection
provided by the encryption
6LoWPAN IPv6 over Low power Wireless Personal Area Networks.
A developing set of protocols aiming to enable IPv6 packets
of data to be transmitted over IEEE 802.15 networks (e.g.
Bluetooth and ZigBee).
Access Control The method by which the Operational FrameworkSmart
Metering Operational Framework controls access to smart
Metering Systems, smart metering data and associated
devices.
AEC Advanced Energy Control – an application profile of the Z
Wave standard
AES Advanced Encryption Standard
AES-128 Where the Advance Encryption Standard uses 128 bit key
AFH Adaptive Frequency Hopping - a method of transmitting
radio signals by rapidly switching between frequency
channels, used by Bluetooth
AMI Advanced Metering Infrastructure, an approach to smart
metering, generally describing the whole system to include
meters, communications and systems
AMR Automated Meter Reading, the collection and
communication of metering information from meters to
systems. Can be done using handheld (walk by) or drive by
equipment, or be based on a fixed network
AMS Advanced Microsensors – a semiconductor fabricator
API Application programming interface – a piece of software
enabling other applications to make use of existing
operating systems or services
APS Application Support layer – part of the ZigBee protocol stack
ASE Advanced Silicon Etch – a semiconductor fabricator
ASIC Application Specific Integrated Circuit – a chip designed
solely for a particular use
AtEx ATmosphères EXplosibles
The AtEx Directive is two EU directives describing what
equipment and work environment is allowed in an
environment with an explosive atmosphere.
The equipment directive (94/9/EC) is relevant to gas
metering
Authorised Party 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.
Page 18 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Term Meaning
Authorised Parties could include a communications service
provider, a meter operator, a network operator etc.
BACnet A data communications protocol for building automation and
control networks
Balun A component in radio systems linking antennas to other
components
BCH Stands for Bose, Chaudhuri and Hocquenghem.
A BCH code is a multilevel, cyclic, error-correcting, variable
length digital code and can be used in low power
communications as error-correcting codes
Bluetooth A wireless communication standard using low power radio
See detail in section 8.
Body Area Network Describes a network where network devices are worn on (or
implanted in) the body.
BoM Bill of Materials – term used by manufacturers to cover a list
of materials and components used to make an assembled
item.
BPSK Binary Phase Shift Keying
A form of Phase Shift Keying
CBA Commercial Building Automation
CCM A form of cryptographic operations
CECED 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.
CE Product marking to signify conformance with European
Union regulations
CEN European Committee for Standardisation (Comité Européen
de Normalisation)
CENELEC European Committee for Electrotechnical Standardisation
(Comité Européen de Normalisation Electrotechnique)
CEPT European Conference of Postal and Telecommunications
Administrations (Conférence européenne des
administrations des postes et des télécommunications) Formatted: English (United States)
CMOS Complementary Metal Oxide Semiconductor – a type of

microchip
COSEM COmpanion Standard for Energy Metering
The interface model for DLMS
CPU Central processing unit
CRC Cyclic redundancy check - a system of error control for data
transmission
CSMA-CA Carrier sense multiple access with collision avoidance – part
of a class of protocols to control how nodes in a network
communicate
Data Exchange Electronic interactions including the transmission of data
Page 19 of 143 27-Oct-0827-Oct-0820-

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

Oct-0830-Sep-08
Term Meaning
GMSK Gaussian Minimum Shift Keying – a form of modulation used
for radio communications – is used by GSM
GPIO General Purpose Input/Output
GPRS General Packet Radio System – a mobile telephony data
transmission system
GPS Global Positioning System
GSM Global System for Mobile communications – a mobile
telephony standard
HAN Home Area Network, typically a network of connected
devices within the confines of residential premises
Hand Held Unit 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.
HomePlug A brand name for a technology providing communication
using powerline technology within a home
HTOL High temperature operating life – a form of estimating the
operating life of a product
HVAC Heating Ventilation and Air Conditioning
IC Integrated Circuit
IEEE 802.15.4 International standard specifying the physical layer and
medium access control for low rate wireless networks
IP Internet Protocol
IP-TLS IP Transport Layer Security
IPv4 The version of the Internet Protocol most widely used
IPv6 The most recent version of the Internet Protocols, which
accommodates a greatly increased network address space
Interoperability 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.
ISM Industrial, Scientific, Medical – term describing unlicensed
international radio frequency bands
‘Last Mile’ Means, in a smart metering context, the communications
connection to the Metering System itself. This could be via
cellular telephony from a mobile mast, or via electricity
cables for power line carrier.
Generally, the Last Mile has a meter at one end and a
connection to the backhaul/data transport at the other, which
could be in the form of a concentrator or other equipment.
Local Communications between a Metering System and Local
Communications Devices within the premises in which the Metering System is
installed.
Page 21 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Term Meaning
Local Device A Local Device can be any piece of equipment within
premises that communicates directly with the Metering
System using Local Communications.
LOS Line of Sight
MAC Media Address Control layer of OSI model (also known as
the data link layer)
MBus Or Wireless MBus;
A wireless communication standard using low power radio
MCU Or µC;
Micro Controller Unit
Mesh network Is a networking topology where nodes are configured to act
together to provide a greater coverage and increased
redundancy
Meter Asset Provider A role within the energy industry, the exact meaning of
which may differ slightly by fuel and governance context,
generally meaning the organisation which owns and is
responsible for the ongoing provision of the meter and holds
a contract with the energy Supplier for that service
Metering System A single device or meter, or a combination of devices used
to deliver the Lowest Common Denominator as defined in
the Operational FrameworkSmart Metering Operational
Framework Schedule L ‘Smart Meter Functional
Specification’.
Meter Variant Classification of meter type under the Operational
FrameworkSmart Metering Operational Framework. A
‘Standard’ variant is suitable for installation at the majority of
meter points in Great Britain. Other variants exist to cover
specific supply, circuit or customer issues at a site.
Examples include Polyphase, Semi-Concealed or 5
Terminal variants.
The full table of Meter Variants can be found in Schedule L
‘Smart Meter Functional Specification’.
Meter Worker A generic Operational FrameworkSmart Metering
Operational Framework term referring to any person
attending a metering point for the purposes of installation,
maintenance, investigation, replacement or removal of the
Metering System.
Includes existing energy industry defined roles of Meter
Operator, Meter Asset Maintainer, Meter Reader, Data
Retriever etc.
MUC Multi Utility Controller – part of the German Open Metering
System for smart metering
NIST National Institute of Standards and Technology
US measurement standards laboratory
NWK Network Layer of the OSI Model
OBIS Also OBIS-Code
An interface class within the DLSM/COSEM object model
Page 22 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Term Meaning
OEM Original Equipment Manufacturer
OMS Open Metering System
The German smart metering initiative that includes the
definition of the MUC
OQPSK Offset Quadrature Phase Shift Keying
A form of phase shift keying
Open Standard The European Union definition of an open standard (taken
from “European Interoperability Framework for pan-
European 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.
Operational Smart Metering Operational Framework Proposals and
Framework Options
OSI Model Open Systems Interconnection – refers to the OSI Reference
Model, an abstract description for layered communications
and computer network protocol design.
OTP One Time Programmable
PCB Printed circuit board
PDA Personal digital assistant – a handheld computer
PHY Physical Layer of the OSI model
POR Power- On Reset, a technique used to ensure that devices
are in a known state when power is applied
PRI A meter manufacturer based in the UK
PSDU Physical Service Data Unit, a term used in TCP/IP
networking
PSK Phase Shift Keying
A digital modulation scheme with a number of different types
PWM Pulse Width Modulation
RAND Reasonable and Non-Discriminatory
RF Radio Frequency
RSA An algorithm for public key cryptography
RSSI Received signal strength indication – a measurement of the
power present in received radio signal
RX In radio terms means receiving
Page 23 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Term Meaning
SCADA Supervisory Control and Data Acquisition, generally an
industrial control system managed by a computer.
SoC System on Chip
SPI Serial Peripheral Interface Bus – a component in computing
systems that provides data links
SRD Short Range Device
SRSM Project Supplier Requirements of Smart Metering project.
Exercise in 2006-08 undertaken by ERA to develop the
Operational FrameworkSmart Metering Operational
Framework.
Ongoing at the time of developing this document

Smart Metering Smart Metering Operational Framework Proposals and
Operational Options
Framework
Supplier Means an energy retail business
TAHI The Application Home Initiative
TCP/IP Transmission Control Protocol/Internet Protocol
The Internet Protocol Suite – the communications protocols
typically, but not exclusively, used for the internet
TSMC Taiwan Semiconductor Manufacturing Company – a
semiconductor fabricator
TX In radio terms means transmitting
µC Microcontroller unit – see MCU
UART Universal asynchronous receiver/transmitter – a piece of
computer hardware that translates data between parallel
and serial forms
UHF RFID Ultra High Frequency Radio Frequency Identification
RFID systems which operate between 300MHz-3GHz
USB Universal Serial Bus – a standard serial interface used in
computing
WAN (Wide Area Communications between a Metering System and a remote
Network) Authorised Party
Communications
Wavenis A wireless communication standard using low power radio
Wi-Fi Trade name for wireless networking technology based on a
range of IEEE 802.11 standards
WSDL Web Services Description Language – a language used Formatted: Keep with next
within interoperable machine to machine interactions over
networks.
ZigBee A wireless communication standard using low power radio
Z/IP Part of the Z Wave protocols, offering TCP/IP connectivity to
Z Wave devices
Page 24 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Term Meaning
ZSE ZigBee Smart Energy – an application profile of the ZigBee
standard
Z Wave A wireless communication standard using low power radio
Table 22 Glossary Formatted: Style Caption + Centered
Page 25 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
4 Local Communications Context

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

It is a clear requirement of the Smart Metering Operational Framework to
implement Local Communications capability for smart Metering Systems.
Interoperable Local Communications capability will enable customers and

Suppliers to make choices in relation to how energy consumption information
is displayed. It also supports flexibility in the options for delivering smart
Metering Systems solutions and potential ‘smart home’ applications.
Throughout this document applications involving water meters, TV displays

and other ‘non-energy’ applications are used to illustrate the potential of smart
metering to support a range of known and as yet unknown applications.
However the Local Communications solution must, first and foremost, meet
the energy requirements. Smart meters are not intended to be a fully
functional alternative to other residential gateway or home hub products –
these products tend to be capable of handling voice and multimedia
applications that would add significantly to the cost of utility meters.
The diagram below shows the SRSM project representation of the operational
architecture for smart metering and therefore the scope of the Operational
FrameworkSmart Metering Operational Framework – this document
specifically relates to the ‘Local Comms’ section on the left hand side of the
diagram.
Business Processes >>>>>>>>>>>>>>>>>
Access Control
Enterprise
Applications
Meter Information
Settlements
Billing System
CRM Systems
WAN Data Registration
Comms Gateway Demand Response

Provision Function Invoicing
Finance Systems
Fieldwork Systems Payments
Outage Management
Local Device Systems
Local
WAN Comms Industry
Comms
Metering
System <<<<< Authorised Party
Structure of Roles & Systems is flexible
Figure 3: SRSM Operational FrameworkSmart Metering Operational Framework Scope
Page 26 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
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 communicationsLocal 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. The solid red lines indicate the core
energy metering requirement of a display of information from gas and
Page 27 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
electricity information. The dotted blue lines illustrate potential other uses of
the Local Communications solution.:
Figure 4: Smart Utility Context
In this example, a water meter is included to illustrate the potential for an

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

Communications
Building upon the illustration above, it is a requirement of the Operational
FrameworkSmart Metering Operational Framework to support customer and
supplier choice in the display of energy (and potentially water) consumption
information from smart meters.
Smart meters should allow customers to access information using a number of

different display devices, as shown in 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.
Page 28 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
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.
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
Page 29 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
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.
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 communicationsLocal Communications solution(s).
Page 30 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Microgeneration ‘Cluster’
Sensor ‘Cluster’
Display Device ‘Cluster’ Utility Meters
White Goods/Demand Response ‘Cluster’
Figure 7: Smart Home Context & Clusters

It is not a requirement of the SRSM Project for smart meters to act as a (or
‘the’) gateway for all of the devices shown in the clusters.
A further suggested use context for Local Communications would be where a

meter (or collection of meters) forms part of a SCADA network of devices
managed by a remote system.
The opportunity to offer services that utilise the WAN communications link
within a smart meter is a product of establishing an interoperable platform for
Local Communications for smart metering.
The illustration below shows how the Local Communications Solution could be
utilised to deliver a platform to serve both the smart metering activities of
energy Suppliers and the requirements of 3rd parties to access the HAN and
Local Devices.
Page 31 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Alongside price and consumption

information, the utility context
would include detail of smart
Suppliers can also communicate meter events and control of
with Customer HAN devices smart metering functionality
Customer Utility
HAN Devices
HAN Radio
HAN interactions with non-

WAN Comms
utility devices uses same

HAN radio, but is less All remote
critical – restricted to price/ communications with
tariff and consumption smart meters are over the
information from the meter secure WAN connection
3rd Parties Suppliers
All communications, WAN and

HAN are 2-way and encrypted
Figure 8 Different Uses of Local Communications
Page 32 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
5 Associated Topics
This section of the document includes further information to assist with setting
the requirements, solutions and evaluation into a specific GB smart metering
context.
5.1 A National Standard

Due to the fundamental differences between the technologies and systems
that may be used for Local and WAN Communications activities, fully end to
end interoperability across the scope of smart metering might not be
appropriate due to the onerous processing and protocol requirements this
could place on simple local devices.
However, in order to ensure that smart metering creates an effective platform

for the types of applications presented in section 4 above, it is believed that a
national standard for local communicationsLocal Communications is required.
The details of such a standard (approvals, certifications, standardised
markings) remain to be considered and will form part of the recommendation
of this report.
This would mean that all smart Metering Systems would include hardware and
software capable of meeting the local communicationsLocal Communications
standard. This does not necessarily mean the same chip/hardware in every
meter, but would mean conformity in their capability.
It is a clear principle of the Local Communications Development workstream

that it would not be acceptable for non-interoperable Local Communications
solutions to be associated with smart metering – a customer with a range of
‘Smart Energy’ compliant products should be able to transfer these products
reasonably seamlessly when they move home, where the smart metering may
be different.
5.2 Security
Due to the nature of data and functionality that will be accessible via Local
Communications, security is a paramount concern.
Consumption and other data from a smart meter may not initially be
considered as confidential – energy tariffs are publicly available, meter
readings on their own are not personal data or at risk of increasing identity
theft. 2
However, debit balances sent from a meter to a display device could be

considered by many customers to be personal and private. Further,
consumption patterns based on interval data could allow third parties to
2
The SRSM project is considering the issues surrounding ownership of smart metering data
within a separate workstream,workstream; therefore they will not be covered within this
document.
Page 33 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
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.
It is accepted that no solution can be completely secure and resist all attempts
to intercept or interfere, but the Local Communications Solution should be
capable of addressing known security attacks – replay, man-in-the-middle,
delay, spoofing, sequence change and deletion.
The Local Communications Solution should also be future flexible, allowing for
firmware/software upgrades to improve security.
5.3 Delivering the Last Mile

For certain topographies it may be possible for the Local Communications
hardware within smart meters to provide the ‘Last Mile’ physical media for
WAN Communications.
This would typically be for high density and metropolitan areas where the
signal propagation and power consumption restrictions of low power radio
solutions are less of an issue.
The SRSM project has considered the potential to use low power radio to
deliver the last mile, as shown in the diagram below. This also demonstrates a
number of options for backhaul for WAN Communications, which is out of
scope for the Local Communications Development work.
Metering System Options
Substation
Low Power
Radio
PLC High Speed Link
Infrastructure (Copper/Fibre)
Low Power Data Trans-
RF to Elec Low Concentrator former
Power
RF
Type Supplier
Cellular A
Infrastructure
A number of RF
Data Transport
solutions include
the capability to
(internet)
create ‘Mesh’
networks, where a Data
large number of
Concentrator
nodes can be
crossed to reach
the concentrator. Low Power
RF Type
Existing telephony Supplier

network
X
Data
Concentrator
Data concentrators could be installed and managed by a
service provider making use of the existing telephony
network.
The equipment could be housed in telephony street furniture,
or any appropriate location, including potentially within
customer premises in the form of ‘Concentrator Meters’.
Data concentrators could be provided as part of the
infrastructure service, or as a separate contracted function.
Figure 9: Local Communications for the Last Mile
Page 34 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
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.
5.4 Local Device Classification

A topic for potential consideration is the classification of Local Devices. As
smart meters are required to be capable of 2 way communication, and energy
suppliers expect display devices to be similarly capable of 2 way
communication, the Local Communications solution(s) need(s) to
accommodate fully functional ‘nodes’ on a network.
There will be, however, local devices that will only send or receive data.
Examples could include:
- a fridge magnet to display consumption cost information would only
receive data
- a temperature sensor would only send data
These types of devices could be classified, for the purposes of smart metering
Local Communications, as distinct groups. The Local Communications
solution could recognise the classification of local devices in order to
determine the data exchange types, access control details and network
addressing/protocols.
Finally, there may be devices capable of sending and receiving data, but that
would not act as network repeaters in a number of topologies.
In v1 of the Operational FrameworkSmart Metering Operational Framework,

the following categories of local device are proposed:
- Data Device: a device which requires access to smart meter data only
- Communicating Device: a device which requires access to remote party
only
- Fully Functional Device: a device requiring access to the smart meter
data, and remote parties, and that could also operate smart meter
functionality – an example of this could be a diagnostic or
commissioning device to be used by a meter worker
Additionally, it has been suggested that Hand Held Units, as may be used by
Meter Workers, could form a category of their own.
Investigation is needed to understand whether there is a requirement for

classification of local devices, and if so, what are the recommended
classifications and how they can be documented.
It should be noted that a number of the solution options provide for device
classification within their profile regimes.
Page 35 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
5.5 Processes/Activities Required

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

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

processing/activities on the network using their own profiles and protocols.
5.6 Types of Data

From the information presented above, it is possible to infer some general
guidelines on the type of data that will be transferred using the Local
Communications Solution:
- energy consumption data
- energy tariff data
- energy local device
- microgeneration data and commands
- meter functionality commands
- load control commands
- local device data (sensor information, appliance diagnostics etc.)
- local device commands – similar to load control – remote ‘soft’ boots,
resetting clocks etc.
- metering system or local device firmware/software
This information is presented for guidance only – the potential applications of
Local Communications and HAN activities are almost limitless. It remains the
case that the primary requirement is to deliver the data and control facilities for
energy smart metering, and that data exchanges will be comparatively small
and non-critical.
Another issue associated with data will be the end to end format – it is not
anticipated that enterprise applications will use the Local Communications
data format – therefore some system within the network is expected to act as a
Page 36 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
gateway, translating Local Communications data exchanges into format that

can eventually be read by Authorised Party applications.
The illustration below is taken from a consideration of technical interoperability

prepared by the SRSM project, it shows how gateways and protocols could be
used in a WAN context to deliver standardised interoperability.
Figure 10 Technical WAN Interoperability
5.7 Independent & Private Local Networks

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

communicationsLocal Communications in two neighbouring properties.
Page 37 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Figure 11: Simple Collection of Smart Meters and Local Devices
The house on the left has a gas meter in an external meter cupboard, a water
meter fitted at the boundary point, and has a TV capable of displaying smart
metering information.
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.
Page 38 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Figure 12: Independent Networks
The topology of the network within premises does not need to be specified, as
these could vary significantly by property type.
However, in order to deliver the necessary signal propagation to link the

electricity meter to the gas meter in the blue house, the range of Local
Communications of the electricity meter could be as shown in Figure 13
below.
Page 39 of 143 27-Oct-0827-Oct-0820-

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

Oct-0830-Sep-08
Figure 14: 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.
Figure 15: Required Local CommsCommunications 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
Page 41 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Communications network, it utilises the Local Communications hardware in

smart meters.
Figure 16: Mesh Network to Concentrator
5.8 Wireless to Wired Options

A standard/solution that includes a wired option for local communicationsLocal
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.
Page 42 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
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

communicationsLocal Communications, typically in Northern Europe. Typically
these use the M Bus protocol over a low voltage (less than 30v) wire within
meter rooms for multi-unit buildings where the location of the gas, electricity,
water and heat meters makes wired solutions far simpler to implement. As
detailed in F.31 abovein section 7.2 below, there are localised regulations
within the UK that appear to rule out this option for gas metering.
However, it would be beneficial for a number of ‘non-utility’ systems to interact

with smart meters:
• to receive pricing and tariff information
• to respond to load control/demand management instructions
• to display energy related information
• to utilise the WAN connection of the meters to send or receive
information to and from remote parties
Some customers may already own and use equipment theoretically capable of
providing a bridge between wireless and wired communications media, and
which could include the necessary software to make data and services
interoperable between distinct networks and systems. The obvious example is
a home PC, but broadband routers, set top boxes and games consoles
already include most of the technology to provide a link between smart meters
and existing wired and wireless networks.
As previously stated, it is an absolute requirement for smart metering that it

will not be subject to customer equipment and decisions in order to deliver the
utility requirements of intra meter and energy information display processes.
It would not be reasonable to assume that every home would be equipped

with a BT Home Hub, Sky box, Xbox 360 or similar ‘bridge’ capable
equipment, but for those that do then smart meters could form part of the
overall connected home. Energy suppliers could choose to provide ‘bridge’
equipment to customers as part of an overall energy services package.
An alternative approach would be to implement a Local Communications

Solution using a protocol along the lines of 6LowPan, which extends IP
addressing to every node in the network, dispensing with the need for HAN
controllers and specific protocols for the Local Communications. However,
6LowPan remains an immature protocol and is not currently supported by the
solution options considered below.
5.8.1 Wired/Wireless Protocol Development

During the activity of the Local Communications Development workstream
work has commenced on delivering a specification combining ZigBee and
HomeplugHomePlug.
Page 43 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
It is intendedAimed to deliver a technical solution to practical issues raised by

the Victorian AMI initiative in Australia, where electricity meters in meter
rooms are too remote from dwelling units in high rise blocks for low power
radio to operate effectively.
The proposed solution would allow either a wired (electricity mains cable) or
wireless (802.15.4IEEE 802.15.4 radio) physical layer for the ZigbeeZigBee
smart energy profile.
The work is anticipated to deliver specifications in the second half of 2009.
5.9 British Housing Types

One of the key challenges facing any wireless solution will be type of premises
it will be used in. There is a comprehensive range of construction materials
that will all have a direct bearing on the signal propagation properties of a
Local Communications Solution.
The issue is compounded by a variety of physical energy supply conditions

that can be site or customer specific. There has been little standardisation of
the exact positioning of where the meter is located. Meter location, which is
usually an ‘out of sight, out of mind’ consideration, and could be anywhere
within or outside premises (or another premises for multi-occupancy premises
with meter rooms), will introduce a range of challenges for communications
solutions.
Metal meter cabinets (mantel units) could also adversely impact wireless
signals – creating Faraday Cages - a situation that is apparent from ongoing
technology trials by the energy Suppliers.
Although not a core requirement of the SRSM project, it must also be noted
that the installed base of water meters in Britain can also be in a tricky location
for low power radio signals. A significant proportion of water meters are
installed in boundary boxes at the edge of a customer’s land. Similarly the use
of pits for water meters will have an effect on signal propagation.
The figures presented below show that the particular challenges associated
with flats, where the energy consumption could be significantly ‘remote’ from
the energy meter, do not represent a minority concern.
5.9.1 Houses By Type

The ‘types’ of houses are defined differently by the Government housing
condition statistics in England, Scotland and Wales.
English Data:
Dwelling Type 000’s %
Small Terraced House 2,665 12
Medium/Large Terraced 3,634 17
House
Semi-Detached House 5,897 27
Page 44 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Detached House 3,753 17

Bungalow 2,028 9
Converted Flat 716 3
Purpose Built Low Rise 2,783 13
Flat3
Purpose Built High Rise 305 1
Flat
Total 21,781 100 Formatted: Keep with next
Table 33 Stock Profile - English House Condition Survey 2005 Formatted: Style Caption + Centered
Stock Profile – English House Condition Survey 2005
Scottish Data:
Detached 472 20
Semi-Detached 501 22
Terrace 522 23
Tenement 449 20
4-in-a-block 251 11
Tower/Slab 71 3
Flat in conversion 36 2
Table 44 Type of Dwelling - Scottish House Condition Survey 2004/5 Formatted: Style Caption + Centered
Type of Dwelling – Scottish House Condition Survey 2004/5
Welsh Data:
Detached 264 23
Semi-Detached 387 33
Terrace 405 35
Flats 101 9
Table 55 1998 Welsh House Condition Survey Formatted: Style Caption + Centered
Figures taken from 1998 Welsh House Condition Survey
Assuming that flats are the dwelling types that could present signal
propagation issues for wireless solutions, these are highlighted in blue in the
tables above and collated to provide the overall ‘British’ position shown below.

Detached 4,489 18
Semi-Detached 6,785 27
Terrace 7,226 29
Bungalow 2,028 8
Flats 4,712 19
Table 66 'Overall' British Housing Type Volumes Formatted: Style Caption + Centered
[Add data for construction type if available?]
[Add data for meter location if available? Interior/Exterior/Meter Cabinet]
3
Defined as: ‘a flat in a purpose built block less than 6 storeys high. Includes cases where
there is only one flat with independent access in a building which is also used for non-
domestic purposes’. High Rise therefore being blocks over 6 storeys high.
Page 45 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Page 46 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
6 Principles & Assumptions

6.1 Local Communications Principles
From the detail presented above, and from associated smart metering work, it
is possible to infer a number of key principles that apply to Local
Communications for smart metering:
Utility focus – the key requirement remains the communication between smart Formatted: Bullets and Numbering
meters and energy information display devices. Support for other services and
applications will be as a result of developing a practical solution to the utility
requirement.
The utility focus should necessarily result in a low bandwidth platform –
energy consumption and tariff data and control commands do not require high
data throughput rates.
The Home Area Network associated with smart Metering Systems will be
owned by the customer. This allows them to add or remove any Local
Devices. The smart Metering Systems themselves will be responsibility of the
energy Supplier
Interoperable – supporting a range of metering products and local device
applications
Use, wherever possible, of open standards and architecture
The intention is to adopt (and potentially develop) an existing solution rather
than develop a new one. This includes the protocol and data definition.
Same ‘solution’ in all smart meters – establishing a national solution/standard
Energy efficient
The Local Communications solution will be secure, as described in the
requirements below. Additional security measures may be implemented by the
Metering System and the application software. The Local Communications
solution will be secure in the context of providing networked communications
using low power radio and ongoing technological developments.
Future Proof/Future Flexible – supporting innovation at the same time as
supporting legacy systems
No Principle
P.1 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.
P.2 The utility focus should necessarily result in a low bandwidth platform –
energy consumption and tariff data and control commands do not
require high data throughput rates.
P.3 The smart Metering Systems themselves will be responsibility of the
energy Supplier. The Home Area Network associated with smart
Metering Systems will be owned by the customer. This allows them to
add or remove any Local Devices. The smart Metering Systems
themselves will be responsibility of the energy Supplier
P.4 The Local Communications solution will be Iinteroperable – supporting a
range of metering products and local device applications.
P.5 The Local Communications solution will make useUse, wherever
possible, of open standards and architecture.
Page 47 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
No Principle
P.6 The intention is to adopt (and potentially develop) an existing solution
for Local Communications rather than develop a new one. This includes
the protocol and data definition.
P.7 The Same Local Communications baseline ‘solution’solution will be the
same in all smart meters – establishing a national solution/standard.
P.8 The Local Communications solution will be Eenergy efficient.
P.9 The Local Communications solution will be secure, as described in the
requirements below. Additional security measures may be implemented
by the Metering System and the application software. The Local
Communications solution will be secure in the context of providing
networked communications using low power radio (or similar) and
ongoing technological developments in security.
P.10 Future Proof/The Local Communications solution will, as far as
possible, be Ffuture Fflexible – supporting innovation at the same time
as supporting legacy systems.
Table 77 Local Communications Principles Formatted: Style Caption + Centered
6.2 Local Communications Assumptions

Based on the context discussions above, and on discussions within the group,
the following assumptions apply to the requirements, solutions and evaluation
presented below:
No Assumption
A.1 The Local Communications Solution will be compliant with relevant
legislation and regulations
A.2 Smart meter functionality is broadly equivalent to the SRSM Smart
Meter Specification.
A.3 SRSM Smart Meters are expected to have an asset life in excess of 10-
15 years or better.
A.4 The Local Communications Solution will be utility robust. This means Formatted: Keep with next
that for the purposes of delivering utility services to a customer it will
not be reliant upon, or affected by, devices owned by a customer or
other 3rd party.
Table 88 Local Communications Assumptions Formatted: Style Caption + Centered
Page 48 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
7 Requirements
The requirements shown below are the result of iterative development by the
Local Communications Development Group. The starting requirements for the
group were taken from the Supplier requirements published in the ERA Smart
Metering Operational Framework Proposals and Options v1, dated August
2007.
The requirements have been developed with the participation of parties other
than energy retailers – meter manufacturers, network operators, meter
operators and display and device manufacturers are all parties to the Local
Communications Development Group. There are no specific requirements for
any single group, as the Local Communications Solution should meet the
overall requirements of those parties with an interest in the development of
smart metering. Therefore there is no specific requirement to address a
network operators specific use case of load and device control – this should be
addressed by the general requirements below.
7.1 Requirements
The requirements below are grouped by topic
Ref Requirement Notes
General
GEN.1 The Local Communications Solution The maximum requirement is
must provide for data exchange for intermittent communication
between smart meters and local devices between a Metering System
and a Local Device at a
configurable time granularity
that can be measured in
seconds.
GEN.2 The Local Communications Solution
must be interoperable, allowing smart
meters and local devices from a range
of manufacturers to exchange data
using a defined data standard.
In OSI terms, the Local Communications

Solution will be interoperable at the PHY
and MAC levels
shall not critically affect the power
consumption/battery life of a smart
Metering System
shall operate throughout the life of the
installed smart Metering System – it will
be capable of remote upgrade and
those upgrades shall be backwards
compatible
Communication
Page 49 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08

COM.1 The Local Communications Solution Note that domestic sized smart
must be able to operate effectively in the meters could be used in non-
majority of British domestic premises domestic premises.
without the need for additional
equipment Note that there may be
additional equipment for
specific property types
COM.2 The Local Communications Solution
shall have the ability to automatically
adapt to communications interference
through detection and analysis of
environmental conditions (e.g. channel
hopping, channel avoidance, signal to
noise ratio)
COM.3 The Local Communications Solution
shall provide an option to deliver WAN
communication information during a site
visit from a Meter Worker with a suitably
secure deviceHand Held Unit.
In this instance, if the WAN
communications is not available, it will
be possible to exchange information
(meter readings, tariff settings etc.)
through the use of a Hand Held
UnitMeter Worker device. This
failsafe/fallback facility could include the
exchange of information with Metering
Systems using local
communicationsLocal Communications
during a site visit or also for a ‘drive by’
or ‘walk by’ activity.
Security
SEC.1 The Local Communications Solution Includes situations where
must support data security measures to nodes pass data but cannot
prevent unauthorised access to/use of access the content. An
smart metering data or functionality, and example would be where an
to prevent unauthorised access to/use electricity meter passes data
of Local Device data or functionality. to a display device from a gas
meter – the electricity meter
should not be able to access
the content of the gas data
SEC.2 The Local Communications Solution
shall support security measures that
employ cryptographic operations and
cryptographic keys
Data
DAT.1 The Local Communications Solution
shall support a defined data definition
standard or profile
Network
Page 50 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08

NET.1 The Local Communications Solution ‘Joining’ the network should
shall ensure that all Local Devices are involve some process whereby
required to join the network to access permission is granted – either
meter data and functionality by the customer, the energy
Supplier or automatically
through the use of
configurable security settings
NET.2 The Local Communications Solution
shall be able to support a minimum of
7multiple Local Devices within a Home
Area Network
NET.3 The Local Communications Solution Or, Network Time
shall use the clock and timing Synchronisation
information provided by smart Metering
Systems to set the time on the network it
administers
Installation & Maintenance
MOP.1 The Local Communication Solution must
not add significant time to the
installation of smart meters or local
devices for network configuration or
pairing activities
Customer Requirements
CUS.1 The Local Communications Solution
shall not affect or cause interference to
existing customer networks
CUS.2 The Local Communications Solution, For example, where a
where it requires customer activity, shall customer wants to pair a new
be simple to operate. Local Device
CUS.3 The local communicationsLocal For example, beyond Formatted: Keep with next
Communications solution(s) will place confirming connection or
minimum requirements on customers for removal of Local Devices, the
day to day operation. customer will not be expected
to take action to re-establish
communications following any
failure.
Table 99 Local Communications Requirements Formatted: Style Caption + Centered
7.2 Requirements Notes

A number of factors relating to Local Communications Solution requirements
are not explicit within the requirements shown above. These factors are
presented below.
These factors are relevant for the evaluation of solution options.

Ref Factor
F.1 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
Page 51 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Ref Factor
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.
Whilst possible (see standard below), gas meters that meet the safety
requirements to support electrical connections are viewed as too
expensive for consideration for mass market deployment.
A particular issue for GB gas metering is the extensive use of meter

boxes, which would require modification to meet ATEX requirements.
The Institution of Gas Engineers and Managers (IGEM), at the time of

preparing this document, is consulting upon the 3rd Edition of its’
standard entitled ‘Electrical connections and hazardous area
classification for gas metering equipment’.
F.2 Visiting Smart Meters

A key benefit of smart meters will be a reduction in the number and
therefore cost of field visits to read and maintain the meter.
However, there is no requirement that smart meters should result in an
end to all visits.
It is assumed that the Local Communications solution will support ‘Over
the Air’ upgrades that may be required for Local Devices, which could
include the firmware within a gas meter, and not just for the solution
itself.
e.g. Customers who use debit functionality extensively (daily or more
than daily) could require replacement batteries within the expected
smart meter asset life. This would apply to above average usage of any
functionality that would reduce battery life.
F.3 Battery Life Considerations
The Local Communications Development Group havehas discussed at
length the options for ensuring a reasonable balance is struck between
battery life/cost/customer feedback.
It is accepted that a gas meter cannot provide continuous
communications without a large and expensive battery in order to meet
the requirement for 10 years plus of operation.
Page 52 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Ref Factor
At the same time, the immediacy of feedback to a customer display
device will be critical in assisting customers with managing their energy
consumption.
It is suggested that application software could manage the duty cycle in
gas meters to optimise battery life:
- waking up to transmit/receive information for Xms every 5
minutes or 530 minutes (with suitable information about delays
made available to customers)
- customer override option, allowing them to refresh the Formatted: Bullets and Numbering
information display by pushing a button on the meter to ‘wake’ it
up (similar to the debit ‘refresh’ discussed below)
- waking up more frequently when credit levels (in debit mode) are
below a configurable threshold, to ensure that credit purchase
messages are picked up quickly (or the customer could be
prompted to press a button to receive a ‘refresh’ of balances)
- where the gas supply has been disabled, remain dormant until
the customer pushes a button on the meter to reinstate gas
supply (as required by the SRSM meter specification)
More detailed work is required to establish the preferred minimum Formatted: Keep with next
position, if an agreed position is required.
Table 1010 Local Communications Requirements Notes Formatted: Style Caption + Centered
7.3 Potential Additional Requirements

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

Oct-0830-Sep-08
8 Solution Options
This section of the document presents a number of solution options for the
hardware to be included as part of a smart metering system.
It uses a standard template to capture detail relating to each of the options.

This template is presented below with a description of the type of information
to be captured.
A number of solution options support more than one network protocol, or are
offered by vendors at different frequencies. Therefore there is not always a
one to one relationship between the silicon, the frequency, the protocol and
the data set supported.
In order to ensure that all potential considerations and aspects of a solution

are included in this document, details are recorded for all candidate solutions
in the market that it was possible to document.
Solution Name Website

Description: A description of the solution
Hardware: A description of the physical hardware used by the solution –
microcontroller, antenna etc.
Cost: Where available, a general view of the cost of the solution on a per
meter basis
Data: Speed of data transfer, any limits on packet sizes
Power: 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.
Frequencies: Which of the frequencies (if applicable) does the solution support
Protocols: Does the solution support a variety of protocols? Does it use a
proprietary protocol, or place requirements/restrictions on the
protocol?
Data Does the solution support a variety of data formats? Does it use a
Exchange proprietary format, or place requirements/restrictions on the data
Format: format?
Use in other Is the solution used for other purposes, i.e. not for smart metering,
applications: but for building controls, telecare, entertainment etc.
Use in other Has the solution been used in a smart metering context in other
markets: markets? Can include where the solution is being considered by
other smart metering initiatives.
Maturity: Is the solution available today? If not, when will it be available?
Support for Capability of the solution to provide ‘last mile’ coverage for WAN
‘Last Mile’: Communications
For: Points supporting the solution in a smart metering context
Against: Issues associated with the solution in a smart metering context
Notes: Any other notes, weblinksweb links to relevant materials etc.
Reference Date, Version and Provider of information used to populate the Formatted: Keep with next
Page 54 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
table
Table 1111 Solution Options Guide Formatted: Style Caption + Centered
8.1 Solution Options Descriptions

Solutions are presented in alphabetical order.
Solution Bluetooth low energy www.bluetooth.org
Description: Formerly known as Wibree and Bluetooth Ultra Low Power, this
new solution option is primarily aimed at enabling small devices
and sensors to communicate with a hub. The initial applications
being considered include fitness and health, using a watch or
mobile phone to act as a hub of a Body Area Network.
The standard is expected to be finalised and formally adopted by

the Bluetooth SIG by Q2 2009.Formerly known as Wibree and
Bluetooth Ultra Low Power, this new solution option is primarily
aimed at enabling small devices and sensors to communicate with
a hub. The initial applications being considered include fitness and
health, using a watch or mobile phone to act as a hub of a Body
Area Network.
As with existing Bluetooth Personal Area Networks, Bluetooth low

energy will support up to seven nodes in a network, with a typical
signal range of 5 to 10 metres.
The standard is expected to be finalised and formally adopted by

the Bluetooth SIG by Q1 2009.
Hardware: There will be standalone and dual mode Bluetooth low energy
chipsets, operating the low energy protocol stack or low energy
and classic stacks.
Standalone will be type installed in small end nodes, such as
watches and sensors.
Cost: <$1 for single mode chips, $1.50 for dual mode chips
Data: Approximately 200 kb/s
Power: Listens and transmits for 0.01% of time (compared to 1% listen
cycle for Bluetooth classic)
Advertises – 2ms
Connect request – 1ms
Send application data – 3ms
Frequencies: Operates at 2.4GHz using 40 channels (3 advertising, 37 data).
2 MHz channel spacing
0.5 modulation index GMSK (GFSK)
Protocols: Link Layer protocol manages connections and device discovery.
L2CAP is a standard protocol for Bluetooth used as a multiplexor.
Attribute Protocol used to transmit “attribute” values between
devices.
Data Has a single protocol that features 2 profiles for use – a remote
Exchange display profile and a sensor profile
Format:
Use in other ‘Classic’ Bluetooth is ubiquitous in mobile telephony and portable
Page 55 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
applications: computing – over 2.5 billion enabled devices sold. 1 billion devices
a year and growing.‘Classic’ Bluetooth is ubiquitous in mobile
telephony and portable computing – over 2 billion enabled devices
sold.
Use in other As an immature product, there are no uses of Bluetooth low energy
markets: in a smart metering context. Industrial automation using Bluetooth
is a 15 million chip a year market today and growing fast.As an
immature product, there are no uses of Bluetooth low energy in a
smart metering context.
Maturity: Understood to be still under development. Reuses existing
protocol layers that have been proven interoperable and robust for
over 8 years.Understood to be still under development
Support for Due to the relatively short range, it is not anticipated that Bluetooth
‘Last Mile’: low energy be suitable for WAN Last Mile
For: Enables cellular phones to talk with meters, allowing direct billing
and viewing of usage information from portable devices.
Against: No products available today
Notes: ‘Classic’ Bluetooth radios, depending on the silicon provider, may
already be in a position to support ‘Dual Mode’ operations.
However, this will not be the case for all existing Bluetooth chips.
Specifically designed to do point-to-point connections well – does

not support mesh networking.
Reference: V0.65 prepared in August 2008 by Project Team from online Formatted: Keep with next
sourcesby Robin Heydon from Cambridge Silicon Radio
Table 1212 Bluetooth low energy Formatted: Style Caption + Centered
Solution M Bus www.m-bus.com

Description: Solution developed in Germany to support domestic utility
metering. Supports twisted pair and wireless.
Used widely throughout mainland Europe and supported by all
major meter manufacturers.
Standard available as EN 13757
Hardware: Radio chipset, with embedded protocol stack
Cost: Same as other 868Mhz radios i.e., approx €3.5 (for bidirectional
solution)
Data: Wireless M-Bus speed at 868MHz (66kBps/16kBps)
Wired M-Bus data transmission speed is very low (2400/300 Bps)
Power: 5..10mW
Frequencies: 868MHz
Protocols: M-Bus protocol defines all 7 OSI layers
Data OBIS id. These do not fully cover all the electricity meter features
Exchange but these are currently being defined in an ‘open protocol’ working
Format: group in Germany and therefore should be available for the
implementation of smart metering
Use in other Designed specifically for metering applications
applications:
Page 56 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Use in other M-Bus forms part of the Dutch Smart Meter Specification4.
markets: Wireless M-Bus is designed to be used heat, water and gas
metering as well as heat cost allocators.
Proposed usage of wireless M-Bus in Germany and Austria.

Maturity: Over 80 companies have implemented M-Bus in their products.
CEN standard since 2001
Support for No, design suitable for “in home” communications
‘Last Mile’:
For: Well proven, widely deployed, 868Mhz good transmission
frequency, efficient data coding
Against: Issues relating to the interoperability of the standard and elements
from the overall architecture are not yet resolved.
Notes: Pending EN 13757-5 supports the use of repeaters/relays.
Reference: V1 Provided September 2008 by Uwe Pahl of Qvedis Formatted: Keep with next
Table 1313 M-Bus Formatted: Style Caption + Centered
Solution Wavenis www.wavenis-osa.org

& www.coronis.com
Description: Wavenis is a wireless connectivity platform that features Ultra Low
Power and Long Range coverage capabilities. Wavenis has been
developed by Coronis (creation in 2000) to address the most
critical applications where devices are located in hard-to-reach
places with strong energy constraints for multi-years operation.
Offers today one of the most attractive price-performances ratio.
Dedicated to remote operation for both fixed and mobile Wireless
Sensor Networks (Wireless Sensor Networks).
Hardware: 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)
Cost: Down to 5 EUR for fully mounted & tested OEM cards
Data: 19,6kb/sec typical (up to 100kb/sec max)
Power: - Ultra Low Power: 10µA average operating current with 1 sec
Rx/Sby period (Rx duration of 500µs). Very sophisticated
mechanisms have been implemented to save power in this
scanning mode to avoid over-hearing phenomenon, filter false
detections, etc …
- Receiver peak current in “full run mode” is 18mA.
- Transmitter peak current in “full run mode” in 45mA at 25mW.
Frequencies: - 868MHz (EU), 915MHz (US), 433MHz (Asia)
- 50kHz bandwidth channels (fast FHSS over 16 to 50 channels)
4
Dutch Smart Meter Requirements v2.1 Final – February 2008 – page 6 of the P2 Companion
Standard describes the use of Wired and Wireless M-Bus communications.
Page 57 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Protocols: 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.
Data Wavenis is capable to embed any kind of payload data (from 1
Exchange byte to hundreds of bytes per radio frame)
Format:
Use in other Home Automation (lighting control), Industrial Automation (valve
applications: 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)
Use in other 1 - Water AMR/AMI (SAUR, Elster AMCO, VEOLIA, Sensus, …)
markets: 2 - Gasz AMR/AMI (ChinaGas, GasNatural @ Spain, …)
3 – Electricity AMR/AMI (EDMI, …)
4 – Home Automation (Schneider @ Denmark, …)
Maturity: Milestone of 3,000,000 Wavenis enabled devices deployed
worldwide to be reached by end of 2008
Support for 1 – upUp to 25mW outpoutoutput power class Wavenis modules
‘Last Mile’: offer 1km Line of Sight (LOS) thanks to -113dBm sensitivity (50kHz
bandwidth recieverreceiver) with -3dBi helicoidal antenna.
2 – 500mW power class Wavenis modules offer 4km range. These
modules are usually intended to range extenders for large scale
networks.
3 – Wavenis supports Star, Tree and Mesh network topologies.
For: 1- Field proven technology with large scale deployment worldwide
2 - Hi-reliable technology thanks to implementation of fast
Frequency Hopping Spread SprectrumSpectrum (FHSS)
technicques combined with data interleaving and Forward Error
Correction (BCH) mechanisms. Encryption is implemented in
option upon customer request.
3 – With 17 other companies, Coronis launched (June 2008) the
Wavenis Open Standard Alliance (www.wavenis-osa.org) which
paves the way of the Wavenis standardization to play a major role
worldwide in the “Short Range Wireless” markets.
Against:
Notes:
Reference: V1 provided March 2008 by Bev Adams of Elster
V2 provided Sep 2008 by Christophe Dugas of Coronis, an Elster Formatted: Keep with next
Group company & Wavenis-OSA
Table 1414 Wavenis Formatted: Style Caption + Centered
Note – ZigBee, at the request of group members, is presented in two iterations

to acknowledge the different functionality and performance of differing
frequencies
Solution ZigBee @ www.zigbee.org

868MHz
Description: Silicon based protocol operating on the IEEE 802.15.4 standard for
physical layer and medium access control.
Page 58 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
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: Radio chips available from Atmel
Cost:
Data: Between 20 and 40 kbit/s at 868MHz
(improved by 2006 revision of 802.15.4IEEE 802.15.4 to 100 to
250 kbit/s?)
Power: Varies by individual chip – typical average is μ1A.
ZigBee devices come in two flavours for power consumption –

routers and end devices.
Routers are expected to operate continuously to support and drive
the mesh network and therefore require a constant source of
power.
End Devices are battery powered radios that only come to life
when required to transmit or receive information. Usage profiles –
frequency of transmission and the size of those transmissions - will
determine the eventual battery requirements.
Frequencies: 868MHz
Protocols:
Data Specified in the ZigBee Smart Energy Profile which can be added
Exchange to if required.
Format:
Use in other Total ZigBee node and chipset units – 5 million in 2006, 120 million
applications: in 20115
Home automation, telecoms (local)
Use in other
markets:
Maturity: Smart Energy Profile due for release March 2008, ZigBee Pro
Stack available January 2008
Support for
‘Last Mile’:
For:
Against:
Notes:
Reference: Collated by SRSM project team from group activities Formatted: Keep with next
Table 1515 ZigBee @ 868MHz Formatted: Style Caption + Centered
Solution ZigBee @ www.zigbee.org
5
In-Stat Market Research “ZigBee 2007: What it Iz and What it Iz not”
Page 59 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
2.4GHz
Description: Open global standard developed by the ZigBee Alliance for low
cost low power wireless mesh networking for monitoring and
control. Supported by 300 member companies and with 22
certified vendors of stack/silicon combinations. Meter
manufacturers Itron and Cellnet/Hunt are Promoter members.
Based on the IEEE 802.15.4 standard MAC and PHY

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

Jennic and others
Cost: ~$3-$4 for SoC devices in millions of units typical
- ~$5 for SoC devices in low volume (1000-off)
- Typical BOM cost ~$6-$10 depending on volume, antenna etc.
- Modules available <$20 in low volume, <$10 in high volume.
- Prices likely to drop over next 2-3 years due to market maturity,
new technologies and growth.
Data: - Radios transmit at 250kbps, 128-byte (max) packets
- With networking overhead, this typically results in real application
data throughput point to point of up to ~50kbps, which then varies
depending on topology and configuration, e.g. how many hops,
level of security, using retries etc. Worst case usually >10kbps
effective throughput over many hops, with security,
acknowledgements etc.
- Not suitable for high volume data streaming applications such as
voice or video, but reasonably high bandwidth allows for large
networks for e.g. sensing and control.
Power: ZigBee includes mains powered ‘always on’ devices for routing
messages and battery powered ‘end devices’ typically for sensor
and switch type devices.
- Typical SoC devices operate at 20-35mA when in receive or
transmit, with the radio typically accounting for 2/3 of the power
consumption in RX/TX.
- e.g. in TX mode, EM250 operates at 35.5mA at +3dBm, 41mA at
+5dBm
- Typical SoC devices when in deep sleep, operate at <1uA.
Frequencies: 2400MHz – 2483.5MHz (2.4GHz)
Protocols: 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
Page 60 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
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 Format is defined by the ZigBee specification, in the ZigBee
Exchange Cluster Library and Application Profiles.
Format:
Custom protocols / data formats are allowed, but would not be
guaranteed interoperable.
Use in other Total ZigBee node and chipset units – 5 million in 2006, 120 million
applications: in 20116
Home automation, telecoms (local)
Use in other ZigBee has a wide appeal across multiple markets, and is currently
markets: in use in products in;
- Smart Energy, for local communicationsLocal Communications
e.g. Southern California Edison in the USA, Victoria in Australia,
and last mile communications, e.g. City of Gothenburg
- Home Automation, including lighting control (e.g. Control4),
heating control (e.g. Kalirel), security (e.g. Alertme.com), roller
blinds etc.
- Commercial Building Automation, including lighting and heating
control (e.g. TAC/Schneider, Siemens) and fire and safety.
- Industrial control such as ball valve monitoring/control (Eltav))
- Health monitoring products are in early stages of development.
- Niche markets such as marine electronics (e.g. RaymarineRay
marine))
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
6
In-Stat Market Research “ZigBee 2007: What it Iz and What it Iz not”
Page 61 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
products now certifying for Home Automation, Manufacturer

Specific and Smart Energy, ZigBee 2007 is regarded now as
mature.
A number of vendors of ZigBee silicon have had customers with

products in the market for a number of years with earlier variants of
ZigBee stacks. It is generally accepted that about 7 million
ZigBee/802.15.4IEEE 802.15.4 chips were sold worldwide for
inclusion in products in 2007.
Support for ZigBee is well suited to last mile communications because of many
‘Last Mile’: 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 300 companies and 22
stack/silicon solutions
- A new technology that is mature and accepted by the smart
energy community, yet future proof
- Cost-effective technology that will become even more cost
effective in the next 2-3 years
- Suitable for local communicationsLocal Communications AND
last mile communications, opening up the possibility of a single
communications chip in smart meters covering both!
- Robust, secure, scalable mesh networking
- Good bandwidth availability for a monitoring and control network,
some scope for future use
- A number of working ZigBee Smart Energy products in the
market and arriving into the market in 2008
Against: - Perception of issues with propagation in buildings, however
building construction effectsaffects 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
Page 62 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
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:
Reference Updated April 2008 – v2 – David Egan & John Cowburn
Updated (minor) August 2008 – David Egan Formatted: Keep with next
Table 1616 ZigBee @ 2.4GHz Formatted: Style Caption + Centered
Solution Z Wave www.z-wave.com

Description: • Wireless control mesh networking technology
• Used by over 200 large companies with real products in the
market
• Driven by the Z-Wave Alliance – i.e. by the largest industry
alliance in the area of home control open for any company to
join under RAND terms
• Implemented in over 300 interoperable home control products
that are on the market
• Best-in-Class level of interoperability
Between multiple vendor’s products of the same
application
Between multiple applications (e.g. lighting and HVAC)
Between multiple generations of Z-Wave
• These products include the 2 key energy consuming
applications, lighting and HVAC
• Key home control companies (lighting and HVAC) in the UK
have adopted and launched Z-Wave products in the market
• Proven ability to rapidly drive specifications in Z-Wave Alliance -
e.g. typical process for new application class under 4 months (!)
• Fully backward product compatibility
• Strong, reliable certification program in place
• Lowest cost for certification in industry - $750 with test lab cost
• Highly mature, proven technology
• Achieved status as well-accepted de-facto industry standard
Hardware: • Available as low cost, low power system on chip (SoC) solution
• 3rd generation of single chips in high volume production
• 4th generation single chips out in Q4 of 2008
• SoC: RF transceiver, 8051 MCU, memory and rich set of
peripherals
64 kbyte OTP or 32 kbyte Flash – Plus up to 16 kbyte RAM
Up to 30 GPIOs – ADC – Triac controller – PWM output
On chip Full Speed USB 2.0 controller + transceiver (!)
• Enables true single chip product solutions as lowest cost
Cost: • Lowest possible cost, thanks to
FSK technology with low complexity
Compact protocol stack sizes
• From sub $2.00 to $3.00 in high volumes
• New 4th generation SoC to be released Q4 2008 with even more
competitive pricing
• From $3.00 to $4.00 for complete module (full Z-Wave function –
Page 63 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
add this module to any product to make it a full Z-Wave product)

in high volumes
• Modern single chip implementation in either 180nm or 130 nm
CMOS
• Sustainable cost benefit due to much higher complexity of
competitors
Data: • 40 kbit/s data communication rate is ideal compromise of
throughput for control applications, range, and robustness
• Small packet size leads to much higher efficiency and lower
errors than competing technologies
• 100 kbit/s available in 4th generation single chip
Power: • Leader in low power consumption – System on chip with:
20 mA in receive mode (with MCU running)
20 mA in transmit mode (with MCU running; up to +
5dBm)
30-80 μA average power consumption in battery-to-
battery networks
1 μA in sleep mode (with POR, interrupts, and wakeup
timer running)
• Only standard with support of battery-to-battery networks (!)
• No risk of early power source depletion due to WiFi interference
etc.
Frequencies: • Solution is designed from ground up for reliability against
interference
• 868MHz (Europe) – 915 MHz (US) – Other sub-1-GHz (Asia)
• Addition of 2.4 GHz support for regions without permitted sub-
1GHz bands in 4th generation chip. Sub-1GHz remains core
business
• Countries such as Japan and China that today don’t permit the
use of the 1GHz band are starting to open the 1GHz band
because they recognise the value of 1GHz communication as Formatted: English (United Kingdom)
well as the large issues on wireless low power control in the
2.4GHz space
• Only single chip with support of sub-1-GHz and 2.4 GHz in the
market to address geographies that really don’t allow anything
other than 2.4GHz
• Multi-channel operation with concurrent listening on all
channels
• Viable strategy for use of license exempt bands in control
applications
Suitable for long term product deployment and long-term
battery use
Superior robustness against interference
Mitigates the risk of increased support calls and product
returns
Protocols: • Z-Wave protocol is highly mature mesh networking protocol
specifically designed for home control applications
• Z-Wave protocol consists of PHY, MAC, NWK, and Device
class layers
• Z-Wave device class layer defines command classes and
device classes creating interoperable products. The classes are
a result of Z-Wave Alliance working groups.
Data • Very dense packet size leads to much higher efficiency and
Exchange lower errors than competing technologies
Page 64 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Format: • Commands can be extended without braking compatibility (!)

• Z-Wave security is AES-128 based, either as the symmetric key
based Z-WaveSec Plug & Play or as the asymmetric key based
Z-WaveIPTLS
Designed for interoperability also in setup / installation
process
On-chip security support
Use in other • Used in practically all home control applications (lighting
applications: control, HVAC, drapery and shade control, garage door
openers, door locks, security systems, sensors (movement,
door/window, humidity, temperature, smoke, CO, etc.),
gateways
• Used control of AV / CE devices (e.g. in universal remote
control)
Use in other • Focus on home control / Unified Home Control is the major
markets: strength
• Used in smart metering application by Modstroem in Denmark
• Used in sub-metering and Energy Conservation applications by
DEST in Denmark along with many OEM partners
Maturity: • Very high – Clear strength and factor of competitive
differentiation
Used in over 300 products – available for more than six
years
Proven for interoperability and backward compatibility
4th generation system-on-chip solutions and 5th
generation software
Support for • Z-Wave is not recommended by Zensys for last-mile usage
‘Last Mile’: (Zensys strongly believes that other short range radio
technologies are not suited for last mile solutions). However Z-
Wave integrates directly with TCP/IP based WAN technologies
through the Z/IP architecture – converging Z-Wave and IP. Z/IP
allows IP traffic to be transported on Z-Wave and to carry Z-
Wave Commands in UDP packets. This architecture is a great
option for the last mile. Further Zensys has a very strong
bridging capability to other networks. This bridging capability is
currently used by Horstmann and Trilliant to bridge the last mile
technologies.
For: • 2.4GHz interference risk is non-existent
• Lowest cost
• Lowest power consumption
• Full eco-system/cross-segment product portfolio available to
communicate to technically but also to build business
propositions with from a business perspective
• Advanced Energy Control framework builds on top of current
portfolio instead of starting from scratch
• Mesh networking and long range ensures minimum installation
costs and ease of installation
• Well accepted industry standard enables integration with
today’s and future in-home solutions
• Lowest risk for long-term, 10-20 year deployment
Against: • Is portrayed as “proprietary standard”
But program for second source / licensing is in place and
being executed upon
Notes:
Page 65 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Reference V1 provided April 2008 by Bernd Grohmann of Zensys

V2 provided Aug 2008 by Niels Thybo Johansen of Zensys Formatted: Keep with next
Table 1717 Z-Wave Formatted: Style Caption + Centered
8.2 Other Solution Options

The table below lists a number of other candidate solutions for Local
Communications. It gives a short description of the solution, website details
where available, and an explanation of why it is not included in the main
evaluation process.
Solution ANT
Description Very low power – 10 year operation on a watch battery. Operates at
2.4GHz. Has 1 million nodes in operation. 43 member alliance.
Website www.thisisant.com
Reason for not Is a proprietary solution, also quite new.
including in
evaluation
Solution BACnet
Description American developed protocol used mainly for HVAC applications in
building automation.
Website www.bacnet.org
Reason for not Specifically aimed at building control – no apparent smart metering
including in utilisation
evaluation
Solution Bluetooth
Description 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
Website www.bluetooth.com
Reason for not Although there are a number of standards for Bluetooth, some of
including in which may include greater signal propagation and more efficient
evaluation power management, Bluetooth is viewed as too power-hungry and
not capable of sufficient range to meet the SRSM requirements.
Solution EkaNET
Description Proprietary wireless solution, partnered with a number of meter
manufacturers,
Uses IPv6 standards.
Website www.ekasystems.com
Reason for not Appears to be aimed specifically at SCADA deployments, or
including in network based smart grid initiatives – also features WAN gateways
Page 66 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
evaluation and other head-end systems
Solution HomePlug
Description: 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 ContolControl 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.
HomeplugHomePlug standard is reasonably mature. Command
and Control is a recent development
Website www.homeplug.org
Reason for Is a wired solution only – hence not suitable for gas metering.
not including Remains a potential option for electricity metering, or for inclusion
in evaluation in other RF capable components to provide links to Ethernet
devices.
Solution Insteon
Description Established North American home control protocol. Typically used
over wire, but also supports RF.
Website www.insteon.net
Reason for not Emphasis on wired solutions does not match gas requirements,
including in also does not currently support secure communications
evaluation
Solution ISA100.11a
Description Provides a wireless industrial process automation network to
address control, alerting, and monitoring applications
plantwideplant wide. It focuses on battery-powered field devices
with the ability to scale to large installations and addresses wireless
infrastructure, interfaces to legacy host applications plus security,
and network management requirements in a functionally scalable
manner.
Website http://snipurl.com/isa100
Reason for not Still under development
including in
evaluation
Solution KNX
Description Originally developed by Siemens and Merten, primarily aimed at
home and building automation. Well established and promoted
standard based out of Brussels.
Page 67 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
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.
Website www.knx.org
Reason for not Has not been proposed for use in energy metering.
including in Attempts to contact KNX alliance have not resulted in any interest
evaluation in participating.
Solution OneNet
Description 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
• TargettedTargeted at battery powered devices
• Supports secure encrypted commsCommunications
• Star and peer to peer topology
• 38 to 230 kbit/s
• 868 MHz
• Supports 2000 devices in a network
• 3 to 5 year battery life with AAA cell
Website www.one-net.info
Reason for not New standard, main focus appears to be battery operated devices.
including in
evaluation
Solution OpenTherm
Description Communications protocol used to control heating applications.
Appears to be wired and has been developed in Holland.
Website www.opentherm.eu
Reason for not Specific application for heating
including in
evaluation
Solution PhyNet
Description 802.15.4IEEE 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.
Website No website
Reason for not Very New
including in
evaluation
Page 68 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Solution Sensinode
Description 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) (AMI)
and WSN (wireless sensor networks (WSN)). The Sensinode
NanoStack meets the 6LoWPAN (IPv6 over Low power WPAN)
specifications released in 2007 and offers a scalable and robust
architecture for a wireless mesh network where all nodes cooperate
to transport information almost like the Internet. By using many
small radio modems, a low-power wireless network can cover large
geographical areas using the licence-free frequency band at 2,45
GHz. The self-configuring and self-healing properties of the
6LoWPAN network offer redundancy and low maintenance cost.
Website www.sensinode.com
Reason for not Very new
including in
evaluation
Solution SimpliciTI
Description Proprietary network protocol supporting up to 100 nodes in a simple
network – supports only 5 commands, uses very small amounts of
memory and power.
Offered in sub 1Ghz and 2.4GHz silicon
Website TI Website
Reason for not Proprietary solution – targets smaller devices – no specific smart
including in metering implementations
evaluation
Solution WiFi
Description Established high power standard, prevalent in many homes.
Typically used for broadband internet connections and multimedia
delivery.
Works at 2.4GHz.
Website www.wi-fi.org
Reason for not Power consumption is very high, with propagation issues for a
including in significant proportion of GB home types. Also concerns over
evaluation conflicts and interference with customers’ existing wireless
networks.
Low Power WiFi options are emerging, mainly driven by Intel –
GainSpan have a prototype module that will run for 10 years on an
AA cell. The Intel ‘Cliffside’ initiative is also working in this area.
Solution Wireless HART
Page 69 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Description 2.4GHz, Open Standard, MAC addressing, Mesh networking

Website www.hartcomm2.org
Reason for not Aimed specifically at manufacturing processing applications, mainly
including in in North America.
evaluation
Page 70 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
9 Additional Considerations
The Local Communications Development Group, and the wider SRSM project,
has considered a number of topics related to Local Communications.
These include addressing protocols, radio frequencies and data exchange

formats. The information gathered and considered on these topics is
presented for completeness below.
It is acknowledged that a number of the solutions technologies evaluated by

the group are strictly limited in terms of the protocols and frequencies, whilst
others may be flexible in supporting a range of options.
It is not the preference of the group to recommend a requirement for a truly

flexible solution if it is not available on the market currently, or would add
unnecessary cost to the deployment of smart metering. Therefore, if any
solution cannot support IPv6, or operate at 433MHz, this has not counted
against it in the evaluation process.
Placeholder to document the potential protocols that could be used for Local
Communications networks. A number of these may be specifically linked to
the physical media solution.
9.1 Network & Addressing Protocols

Protocol IPv6
Description: An internet layer protocol for packet-switched networks. It offers a
greatly extended address space over the previous IPv4, allowing
for more IP addresses.
IPv6 also features enhanced security provisions
Used by/for: The majority of internet activity now uses IPv4 or IPv6.
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)
Notes:
Protocol 6LowPan
Description: Stands for IPv6 over Low Power Wireless Personal Area
Networks, a protocol designed to send and receive IPv6 packets
over IEEE 802.15 networks.
A number of practical issues relating to packet sizes and
addressing schemes remain to be addressed.
Page 71 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Used by/for: Still being developed

For: Could deliver end to end protocol solution for Suppliers and
Authorised Parties
Against: Protocol is still under development
Notes:
Page 72 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
9.2 Frequency Considerations

The Local Communications Development Group considered the potential
frequencies to be used for low power radio solutions. The details of these
discussions are presented below for completeness.
It is acknowledged that the solutions considered by the group are specifically

tied to a single frequency – it would not be possible, today, to consider the
opportunities to use Wavenis of M-Bus at 2.4GHz.
Therefore the solution recommendation will determine the frequency, rather

than the frequency determining the solution recommendation.
9.2.1 Frequency Information

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

Oct-0830-Sep-08
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)
Frequency 433-434MHz
Description: Unlicensed ISM band
Used by/for: Well used frequency, typically used for car key fobs.
Has been used for heat metering in Europe
Signal Good
Propagation:
Power More battery efficient than higher frequency options
requirements:
Longevity of
frequency
allocation:
Notes: Support (by existing chips) for open standards is not evident
Security may be an issue (e.g. for financial transactions)
Frequency 868-870MHz
Description: Unlicensed European ISM band (915MHz in North America)
Used by/for: Z-Wave, Wireless M Bus, ZigBee, Wavenis.
Minimal usage in other applications.
Signal Good
Propagation:
Power Has well defined maximum duty cycles and transmission powers
requirements: (5mW to 25mW).
Longevity of Unlicensed europeanEuropean band, unlikely to be revoked, but
frequency risk remains
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.
Frequency 2.45GHz
Description: Unlicensed worldwide ISM band
Used by/for: ZigBee, WiFi, Bluetooth, Microwave Ovens, Home Video repeaters
Signal
Propagation:
Power Signal can be amplified to improve propagation
Requirements:
Page 74 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Longevity of Unlicensed global band, unlikely to be revoked, but risk remains

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

An ideal solution for smart metering would be to use a licensed band. This
would guarantee the availability of interference-free bandwidth for many years.
However, the current licensed band for metering in the UK, 184MHz, only
supports one-way communications, operates at a frequency unique to this
country, and has therefore not attracted solution providers in any significant
numbers.
Use of a licensed band for local communicationsLocal 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)7.
The use of unlicensed bands does come with the risk of interference from
other devices as they establish themselves at particular frequencies. The
2.4GHz band already includes microwave ovens, Bluetooth, Wi-Fi, TV signal
repeaters and more. However, there are a number of techniques in use to
allow devices to co-exist effectively within frequency bands.
9.3 Data Exchange Format Options

A number of these may linked to the specific solution, whilst other solutions
may support the use of a range of data exchange formats.
A more detailed review of the convergence between GB smart metering data

requirements and the existing format options would be recommended.
Data ANSI
Exchange
Format
Description: 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
7
Technical Architecture for UK Domestic Smart Meter Systems, Alistair Morfey, Cambridge
Consultants 2007
Page 75 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
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: Most major meter manufacturers supply ANSI C12 compliant
meters to the American market
For: Mature, metering specific standards. Have an existing XML
Schema
Against: Levels of support for gas metering?
Notes:
Data Obis
Exchange DLMS/CosemCOSEM
Format
Description: Definition of standardised metering objects (Electricity, Water, Heat,
and Gas Metering covered)
Used Commonly used in Electricity metering in Europe, gaining adoption
by/for: elsewhere in metering
For: Standardised, EN13757-1 (Communication Systems for meters and
remote reading of meters -Part 1:Data Exchange)
Against: Seen as over-specified and too complex for use within the Local
Communications context
Notes: Parts of the standard are used in MBUS implementations.
Data XML
Exchange
Format
Description: Extensible Markup Language, a general purpose specification for
creating custom markup languages – allowing GB smart metering
to develop a bespoke and flexible data exchange format.
Used by/for: Global standard for data exchanges, used in an increasing number
of applications.
For: Would allow for an exact fit with GB smart metering requirements
and applications, would also remain future flexible to
accommodate market innovation.
XML can be compressed substantially, particularly if a known
schema is available.
Against: Use of XML for local communicationsLocal Communications could
place an unacceptably high overhead on the microcontroller itself.
XML support could easily require more space than is typically
available on low power radio microcontrollers. Implementation is
feasible, but at the cost of adding memory and co-processors and
decreasing battery life.
A bespoke GB smart metering XML schema would require

development and ongoing governance.
Notes:
Page 76 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Data ZigBee Smart

Exchange Energy
Format
Description: Specific ZigBee profile defining device descriptions, standard
interfaces and practices for smart energy applications.
Developed and maintained by the ZigBee Alliance.

Used by/for: Smart metering and AMI activities in other markets
For: Specific solution for smart metering using low power wireless
technology
Against: Has been developed specifically to address Southern California
Edison’s AMI requirements (and is currently being adapted to
include requirements from Victoria in Australia).
Notes:
Page 77 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
10 Evaluation of Solution Options

This section of the document details the evaluation process undertaken by the
Local Communications Development Group.
This evaluation exercise has necessarily been conducted as a desktop

exercise. Wherever empirical evidence has been available, from similar
evaluations or actual deployments, this has been considered.
Throughout the process, it has been noted that the technology receiving the
highest overall scorerating will not necessarily be recommended by the group.
Note: In previous versions of this report, there was content covering data
traffic modelling to assist with understanding the type and scale of data
exchanges expected.
Following discussions within the Development Group, it was concluded that

any data modelling undertaken would be based almost entirely on
assumptions about the types of activities and the file formats, and was
therefore not practical to undertake at this time.
10.1 Evaluation Process

Shown below is the process undertaken to evaluate the solution options:
July 18 2008 Meeting

• Group refined requirements
• Group discussed and agreed high level plan for evaluation criteria and
process
• Updated evaluation criteria issued for review
September 2 2008 Meeting
• Presentations and Q&A sessions for each of the solution options
• Discuss and update evaluation criteria
•Begin completing scorecard, recording any key issues or risks noted against Formatted: Bullets and Numbering
a solution option
October 2 2008 Meeting
• Complete Review evaluation criteria, assess statements regarding each
solution option, agree a ‘traffic light rating’ recording any key gaps, issues
or risks noted against a solution option
Late October 29 2008 Meeting
• Finalise and agree recommendations
Between meetings there has been correspondence between the SRSM

project team and solutions providers to resolve queries and update the
information presented below.
Desktop + supporting evidence
Page 78 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
10.2 Evaluation Methodologies

Each of the criteria shown below are weighted. and scored using a variety of
methods. Due to the range of criteria being considered, no single method
would be appropriate, or in some cases possible.
10.2.1 Evaluation Weighting

Recognising that some criteria are closely linked to core requirements and
principles, whilst others are peripheral, each of the criteria is weighted.
The weighting, which is directly applied toassists the group with prioritising
any gap analysis, is shown in the table below the scoring to give an overall
view, is shown in the scoring table below.
‘Must Have’ criteria carry a weighting of 4, with an additional caveat that any
technology failing to meet Boolean tests for Must Have criteria, or achieving a
low score on a Scored test is listed in the Evaluation Issues table below.
10.2.2 Evaluation AssessmentScoring

Boolean criteria are rated at 5 – YES or 0 – No.All criteria are assessed in
terms of red, yellow, green or blue on a gap analysis/risk assessment basis.
A number of criteria have been assessed as Yellow where the claims of the
solution options remain based on ‘desktop’ evidence only, where the group felt
that evidence from testing would result in a clearer view of performance.
Formatted: English (United Kingdom)

Green No gaps or issues
Formatted Table
Some quantifiable gaps or levels of Formatted: English (United Kingdom)
Yellow
risk
Red Significant gap or risk
Blue No information available
Formatted: Keep with next
10.3 Formatted: Caption
Scored criteria are on a 0 to 5 basis, and scores assigned are objective or

subjective depending on the data available and the type of criteria being
assessed:
0 No support/does not meet requirement
1 Very limited support/meets little of requirement
2 Limited support/meets part of requirement
3 Partial support/ meets most of requirement
4 Supports/meets requirement
5 Fully compliant/exceeds requirement
Ranked criteria are rated from 0 to 5, with 5 being the best performing option
and 0 being the lowest performing option.
Page 79 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
10.410.3 Evaluation Criteria

Ref Criteria Relevance/Importance (Must Weighting Formatted Table
8
Have/Desirable) (Desirable
only:
3 = Very
2 = Fairly
1 = Less)
Fit with Requirements
(not specifically addressed by categories below)
1.1 Low level of energy customer Desirable 3
intervention/support required
to maintain communications
1.2 Ease of installation – i.e. Must Have NA
discovery/configuration at
meter installation
1.3 Minimise number of site visits Desirable 3
to address local
communicationsLocal
Communications issues – i.e.
recovery or remote correction
on failure/upgrade failure –
will include MTBF and power
consumption on meter
battery as considerations
1.4 Development tools to support Desirable 1
smart metering and smart
energy market
1.5 Ease of integration into Desirable 2
metering/home products –
e.g. system on chip, antenna
size9
1.6 Scope/receptiveness to Must Have NA
accommodate specific GB
smart metering requirements
Interoperability
2.1 Status as an Open Standard Must Have NA
– accessibility, defined
standards, range of
participants, proven
certification process
2.2 Support for choice of data Desirable 2
exchange format
2.3 Genuine choice and Desirable 3
competition between silicon
vendors
2.4 Interoperable chipsets Must Have NA
2.5 Effort required to update Desirable 2
standards to meet specific
GB requirements (less effort
8 Must Have criteria carry a weighting of 4

9
It was acknowledged during group discussions that an excellent design would represent a
poor substitute for commercial momentum Formatted: English (United Kingdom)
Page 80 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08

8
only:
3 = Very
2 = Fairly
1 = Less)
= higher score)
2.6 No. of nodes supported for Desirable 2
each HAN, assuming
minimum capability of 3.
Power
3.1 Consumption/Peak Desirable 3
Current/Power Failure
Management
3.2 Low Power Routing – Must Have NA
supportSupport for battery
powered nodes, but also for
energy smart metering
application (e.g. data
refreshes in minutes rather
than hours/days for end
nodes)
Data Performance
4.1 Transmission speed – Desirable 2
effective data throughput in
kbps per channel
4.2 Robustness (retry Desirable 2
mechanisms,
acknowledgements,
minimised/nil message loss –
i.e. latency and dropped
packets)
Radio Performance
(Should the test be
based on Link Budget?)
5.1 Typical range (amplified or Desirable 3
non-amplified)
5.2 Suitability for GB meter Desirable 3
locations (consider
internal/external,
stone/concrete, metal meter
cabinets, meter rooms etc.)
5.3 Vulnerability to signal Desirable 2
interference
5.4 Ability to cope with signal Desirable 3
interference
5.5 Blocking Immunity in Desirable 2
transceiver
Security
6.1 Strength/resilience of Desirable 3
methods used
6.2 Ability to use Desirable 2
rolling/successive keys
6.3 Support for distinguishing Must Have NA
Page 81 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08

8
only:
3 = Very
2 = Fairly
1 = Less)
public/private data, and for
keeping gas/water/electricity
data independently secure –
i.e. supports 3 different
suppliers for 3 utilities (and
any other authorised party
data secure)
Future Resistance
7.1 Support for “over the air” Must Have NA
upgrades of ‘smart meter’
nodes – i.e. gas + electricity
meters & in home display
7.2 Support for security upgrades Desirable 2
7.3 Support for backwards Must Have NA
compatibility
7.4 Longevity of frequency Desirable 3
7.5 Longevity of solution Must Have NA
technology (minimum
expected smart meter asset
life of 10-15 years)
Cost Considerations
8.1 Total cost per home – 1 x Desirable 2
electricity meter, 1 x gas
meter with battery, 1 x home
display unit = 3 chipsets +
additional battery cost
8.2 Mean Time Between Desirable 3
Failures/Reliability
Maturity
9.1 Use in equivalent smart Desirable 3
metering deployments
9.2 Use in analogous Desirable 2
applications
9.3 Expectation of ongoing Desirable 1
required upgrades – i.e.
v2009, v2011 (fewer = higher
score?)
9.4 Capacity in vendors to meet Must Have NA
smart metering demands
(meters plus displays and
other devices) – assume 5
year deployment to 25 million
homes
9.5 Availability of non-metering Desirable 2 Formatted: Keep with next
products that could be
relevant to smart metering –
e.g. thermostats, display
devices
Page 82 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Table 1818 Evaluation Criteria Formatted: Style Caption + Centered
As a result of the evaluation process undertaken by the Local

Communications Development Group, each of the criteria above necessarily
fall into one or more of the following categories:
- those requiring a field test to assess performance Formatted: Font: Bold
- those that can be tested under laboratory conditions Formatted: Bullets and Numbering
- those where there are external dependencies (e.g. GB market model Formatted: Font: Bold
work) to determine the appropriateness of the solutions or the size of Formatted: Font: Bold
the gap to be addresseda panel review process could determine the
level of compliance/risk
- those that are commercialnot possible considerationsto test/evaluate to Formatted: Font: Bold
a certain conclusion Formatted: Font: Not Bold
The assessment of the solutions against the criteria and within these
categories is reflected in the recommendations of this report in section 11
below.
It should also be noted that a number of categories appear to show no

differentiation between solution options, this is to be expected as they have all
been selected for evaluation on the premise that they offer a viable low power
wireless option for smart metering.
10.510.4 Evaluation Scorecard

Ref Criteria Bluetooth M-Bus Wavenis ZigBee ZigBee Z- Formatted Table
Low @ @ Wave
Energy 868MHz 2.4GHz
Weighting
1.1 Low level of energy
customer
intervention/support
required to maintain
communications
1.2 Ease of installation –
i.e.
discovery/configuration
at meter
installation
1.3 Minimise number of site
visits to
address local
communicationsLocal
Communications issues
– i.e. recovery or
remote correction on
failure/upgrade failure –
will include MTBF and
power consumption on
meter battery as
considerations
1.4 Development tools to
Formatted: Font: (Default) Arial, 11
support smart metering pt, English (United Kingdom)
and smart energy
Page 83 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08

Low @ @ Wave
market
1.5 Ease of integration into
metering/home
products – e.g. system
on chip, antenna size
1.6 Scope/receptiveness to
accommodate specific
GB smart metering
requirements
2.1 Status as an Open
Standard –
accessibility, defined
standards, range of
participants, proven
2.2 Support for choice of
data exchange format
2.3 Genuine choice and
competition
between silicon vendors
2.4 Interoperable chipsets
2.5 Effort required to

update standards to
meet specific GB
requirements (less
effort = higher score)
2.6 No. of nodes supported
for each
HAN, assuming
minimum capability of
3.
3.1 Consumption/Peak
Management
3.2 Low Power Routing –
sSupport for battery
powered nodes, but
also for energy smart
metering application
(e.g. data refreshes in
minutes rather than
hours/days for end
nodes)
4.1 Transmission speed –
effective data
throughput in kbps per
channel
4.2 Robustness (retry
mechanisms,
acknowledgements,
Page 84 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08

Low @ @ Wave
minimised/nil message
loss – i.e. latency and
dropped packets)
5.1 Typical range (amplified
or non-amplified)
5.2 Suitability for GB meter
locations (consider
internal/external,
stone/concrete, metal
meter cabinets, meter
rooms etc.)
5.3 Vulnerability to signal
interference
5.4 Ability to cope with
signal interference
5.5 Blocking Immunity in
transceiver
6.1 Strength/resilience of
10
methods used
6.2 Ability to use
rolling/successive keys
6.3 Support for
distinguishing
public/private data, and
for keeping
gas/water/electricity
data independently
secure – i.e. supports 3
different suppliers for 3
utilities (and any other
authorised party data
secure)
7.1 Support for “over the
air” upgrades of ‘smart
meter’ nodes – i.e. gas
+ electricity meters & in
home display
7.2 Support for security
upgrades
7.3 Support for backwards
compatibility
7.4 Longevity of frequency
7.5 Longevity of solution

technology
(minimum expected
smart meter asset life of
10-15 years or better)
10
AES encryption is optional in Wavenis, but it is assumed that it would be enabled by default
for all GB smart metering use Formatted: English (United Kingdom)
Page 85 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08

Low @ @ Wave
8.1 Total cost per home – 1
x electricity meter, 1 x
gas meter with battery,
1 x home display unit =
3 chipsets + additional
battery cost
8.2 Mean Time Between
9.1 Use in equivalent smart
9.2 Use in analogous
applications
9.3 Expectation of ongoing
required upgrades – i.e.
v2009, v2011 (fewer =
higher score?)
9.4 Capacity in vendors to
meet smart metering
demands (meters plus
displays and other
devices) – assume 5
year deployment to 25
million homes 11
9.5 Availability of non-
metering products that
could be relevant to Formatted: Font: Bold
smart metering – e.g. Formatted: Keep with next
thermostats, display
devices
Table 1919 Evaluation Scorecard Formatted: Style Caption + Centered
10.5.110.4.1 Evaluation Notes

In order to provide a complete record of the evaluation process, any notes and
explanatory text are shown in the table below.
Bluetooth low energy: throughout the assessment of the Bluetooth low energy
solution option, it should be noted that at the time of preparing the
assessment, this technology was not available for review. Therefore all ratings
for Bluetooth low energy have been recorded as ‘Unknown’. However, where
relevant, information relating to Bluetooth has been recorded in the notes
table below.
Wavenis ultra-low-power wireless technology: Information was provided by

Coronis based on profiles and application optimisation for existing metering
solutions that use Wavenis.
11
It was noted by the group that any technologies operating as fabless providers may present
a higher risk than Bluetooth or ZigBee @2.4 Formatted: English (United Kingdom)
Page 86 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Wireless M-Bus: the comments and views relating to Wireless M-Bus were not
available for the group discussion on the 2nd October and were provided Formatted: Superscript
subsequently for inclusion in this report – a number of the entries are provided
as scores out of 5 (1 being low compliance, 5 being complete compliance).
However, there were a number of radio experts and meter manufacturers
familiar with the solution, and their input has informed the ratings shown.
ZigBee@868MHz: the information has been provided by Atmel, a

semiconductor manufacturer, and accordingly does not address in any detail
those criteria that relate to matters beyond the provision of the chip itself.
ZigBee@2.4GHz: A comprehensive paper was presented on behalf of ZigBee, Formatted: Default Paragraph Font,
Font: Bold
as can be seen from the notes in the table below. The preamble for this
document, which provides information on implementation options for GB smart
metering, is included as an appendix to this report.
Ref Solution ScoreRating Notes/Explanation Formatted: Font: Not Bold
e.g. Solution 5Green 800 million devices sold in 2007 Formatted: Indent: Left: 0 cm
X Formatted: Indent: Left: -0.06 cm
1.1 Bluetooth Bluetooth requires no customer intervention Formatted Table

low Formatted: Centered
energy Formatted: Font: Not Bold, Font
Wavenis offers specific installation methods for color: Auto
1.1 Wavenis
metering networks, with end-points using self- Formatted: Indent: Left: 0 cm
organizing services for their initial installation and Formatted: Indent: Left: -0.08 cm
configuration within the network, self-healing
Formatted: Font color: Auto
features to repair broken links subsequently. End-
user customers should never have to deal with any Formatted: Indent: Left: -0.06 cm
aspects of wireless meter configuration.Self- Formatted
organizing, self-routing, Over The Air Programming Formatted: Font: (Default) Microsoft
upgrade Sans Serif
1.1 Wireless - RF-Transmission interval is selectable for every Formatted: Bulleted + Level: 1 +
M-Bus meter, thus lifetime and battery size of meter is Aligned at: 0 cm + Tab after: 0.63 cm
selectable + Indent at: 0.63 cm
- For that reason a single coin adapter solution Formatted: Font: Microsoft Sans Serif
integrating e.g. existing Gas meters is possible
Formatted: Font: (Default) Microsoft
- High dynamic range allows connection of
Sans Serif, 11 pt, Font color: Auto
gateway with typically one hop. No additional
Formatted: Left
Installation point in flat is necessary!5
1.1 ZigBee similar to 2.4GHz ZigBee solutions Formatted: Font color: Auto
@ Formatted: Left, Indent: Left: 0 cm

868MHz Formatted Table
1.1 ZigBee Connectivity: Formatted: Indent: Left: 0 cm
@ • Once installed and commissioned in the network, Formatted: Font: (Default) Microsoft
2.4GHz ZigBee devices do not lose connectivity with the Sans Serif
network, even after reset due to battery change Formatted: Font: (Default) Microsoft
or loss of power. Sans Serif, 11 pt
• Information about which devices talk to which Formatted: Indent: Left: 0 cm
other devices is held in non-volatile memory on
Formatted: Font: 11 pt
each device, so this is not dependent on a
Formatted: Body Bullets,
central controller.
Widow/Orphan control, Adjust space
• ZigBee is a self-healing mesh network, where between Latin and Asian text, Adjust
space between Asian text and numbers
Page 87 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
routes are repaired automatically, surrounding Formatted: Indent: Left: 0 cm

‘neighbour’ devices are discovered automatically Formatted: Centered
and Formatted: Font: Not Bold, Font
• Battery powered (end) devices can find new color: Auto
parents if they lose contact. Formatted: Indent: Left: -0.06 cm
Formatted Table
Robust messaging
Formatted: Font: 11 pt, English
• ZigBee messaging is highly robust, with clear (United Kingdom)
channel assessment before sending a packet;
• Retries at a MAC level and
• Further retries if necessary at an APS Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
(Application Support) level, resulting in 12
attempts to send a message in a ~5 second Formatted: Indent: Left: 0 cm
period before a message actually fails. Formatted: Font: 11 pt

Customer Intervention: Widow/Orphan control, Adjust space
between Latin and Asian text, Adjust
• No customer intervention is required typically to space between Asian text and numbers
maintain communications.
• Of course, if a device (e.g. In-Home-Display) is
broken and has to be replaced, then some re- Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
commissioning is required, and this might be
done by the energy customer (depending on Formatted: Indent: Left: 0 cm
procedures) Formatted: Font: 11 pt
• As with any other radio technology, if the user Formatted: Body Bullets,
changes the environment to directly block the Widow/Orphan control, Adjust space
radio signal between two devices and there is no between Latin and Asian text, Adjust
other path, then some user intervention would be
required to clear the blockage, move one of the
devices (e.g. in-home-display) or introduce a
routing device to allow the message to route
around the blockage.
Sans Serif, 11 pt
The best direct evidence of this is from current
installations in UK homes, including companies like Formatted: Font color: Auto
PRI, Alertme, and some of the EDRP trials currently Formatted: Indent: Left: -0.06 cm
underway.
1.1 Z Wave After installation the Self-Healing, Self organizing, Formatted
mesh protocol mechanisms and the optional Formatted: Font: (Default) Microsoft
Wireless firmware upgrade will perform the network Sans Serif, 11 pt
support for the customer.
1.2 Bluetooth Bluetooth requires no configuration of radio at the Formatted: Font: (Default) Microsoft
meter at installation Sans Serif
low
energy
1.2 Wavenis End-points are added to the network at the touch of
a button on a handheld device (which launches a
Service Discovery Protocol process in the end-
point). At the same time, the end-point identifies the
most power-efficient and reliable path to the nearest
gateway. When battery-powered range extenders
are used in a fixed network topology, their GPS
coordinates are added to the network map for
administration purposes.Service Discovery Protocol
Page 88 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
1.2 Wireless Two types of Installation Formatted: Indent: Left: 0 cm

M-Bus Formatted: Centered
- Installation using “press button” method
Formatted: Font: Not Bold, Font
(Gateway listens to all “new” meters) color: Auto
- Installation by scanning RF-Channel and Formatted: Indent: Left: -0.06 cm

comparing with device list provided by AMR- Formatted Table
Back office4 Formatted: Bullets and Numbering
1.2 ZigBee similar to 2.4GHz ZigBee solutions, Formatted: Font: (Default) Microsoft
@ however final system / meter not under control of Sans Serif, 11 pt, Font color: Auto
868MHz Chip providers Formatted: Left
1.2 ZigBee If using the ZigBee Smart Energy application profile, Formatted: Font color: Auto
@ this describes in detail the commissioning process Formatted: Left, Indent: Left: 0 cm
2.4GHz for HAN / Local communications.
Formatted Table
All ZigBee devices have a unique IEEE address Formatted: Indent: Left: 0 cm
called EUI64, sometimes referred to as a MAC Formatted: Font: (Default) Microsoft
address (though in the IT World, MAC addresses are Sans Serif
usually 48 bits, not 64 bits like ZigBee). This globally Formatted: Font: (Default) Microsoft
unique MAC address can be used during installation Sans Serif, 11 pt
to uniquely identify every device. Formatted: Indent: Left: 0 cm
Formatted: Indent: Left: 0 cm
There are several types of discovery, including
device discovery, route discovery and service Sans Serif, 11 pt
discovery, all of which are encapsulated in the
ZigBee standard and which make installation Sans Serif, 11 pt
processes much easier.
Formatted: List Paragraph, No
1.2 Z Wave Standard Z-Wave auto discovery and configuration widow/orphan control, Don't adjust
functionalities allow easy installation. The Advanced space between Latin and Asian text,
Energy Control (AEC) framework using standard IP Don't adjust space between Asian text
and numbers
(Z/IP) remote management allows full control from
utility supplier or installer. Formatted
1.3 Bluetooth Bluetooth self manages the local communications Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
low
energy Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
1.3 Wavenis Self-healing mechanisms are used by end-points in
case of network path problems. A battery energy Formatted: Font: (Default) Microsoft
Sans Serif
consumption counter is used to raise a spontaneous
alert in case of low battery. Over-the-air
programming and remote access (by the network
administrator) obviate the need for any end-
customer intervention.Self-healing, Over The Air
Programming, Battery energy counter daily
transmission, battery-low level spontaneous alert
transmission
1.3 Wireless Self healing? One Electricity- meter and one Gas Formatted: Font: (Default) Microsoft
meter have a link to one Gateway. Sans Serif
M-Bus
A Meter may be remotely assigned to another
gateway, if needed. But reassignment is not made
automatically for security reasons!3 to 4
1.3 ZigBee similar to 2.4GHz ZigBee solutions, Formatted: Font: (Default) Microsoft
however final system / meter not under control of Sans Serif, 11 pt, Font color: Auto
@
868MHz Chip providers Formatted: Left
Page 89 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
1.3 ZigBee Site visits post installation should be unnecessary Formatted Table
@ with ZigBee deployments, except for normal Formatted: Centered
2.4GHz circumstances like device failure or if the user does Formatted: Font: Not Bold, Font
something exceptional to create a problem (see color: Auto
above). Formatted: Indent: Left: 0 cm
Formatted: Indent: Left: -0.06 cm
It should be possible to design battery powered
devices like gas meters to last many years on a Formatted: Font color: Auto
single battery. This will be largely dependent on the Formatted: Left
product design and requirements, e.g. type of Formatted Table
battery, frequency of communications. Formatted: Font: (Default) Microsoft
Sans Serif
Device failures in the field should be minimal.
ZigBee chips are designed on proven technologies
and processes. MTBF and other statistics may differ
Sans Serif
from one chip to another, so difficult to provide
specific statistics given the number of vendors.
Silicon vendors will meet expectations of ERA / UK
local Communications in this regard, and individual
vendors can supply their individual statistics as part
of a competitive tendering process. Formatted: Font: (Default) Microsoft
The 868MHz operation efficiently removes the Sans Serif, 11 pt
1.3 Z Wave
problematic WiFi interference and the associated Formatted: Font: 11 pt
support calls. Formatted: Font: Not Bold
Z-Wave Self-healing automatically repair minor Formatted: Font: (Default) Microsoft
network issues and the optional, wireless firmware Sans Serif, 11 pt
upgrade can repair major issues without site visits.
1.4 Bluetooth Bluetooth development systems available from Formatted: Font: (Default) Microsoft
multiple manufacturers with over 8 years of shipping Sans Serif
low
energy products Formatted: Font: Not Bold
1.4 Wavenis The Wavenis Open Standard Alliance promotes Formatted: Font: 11 pt
multi-sourcing of Wavenis platforms. Product Formatted: Font: Not Bold
Development Kits, testing tools and a complete
developer API are readily available. Several market
leading metering companies have used these tools Formatted: Font: (Default) Microsoft
to deploy hi-volumes of Wavenis water and gas Sans Serif, 11 pt
metering solutions around the world. Electric Formatted: Font: (Default) Microsoft
metering with embedded Wavenis-based solutions Sans Serif
are under development, including for the Formatted: Font: Not Bold
UK.Wavenis Open Standard Alliance promotes Formatted: Font: (Default) Microsoft
multi-sourcing platforms, Product Development Kits Sans Serif
and testing tools Formatted: Font: Not Bold
1.4 Wireless Ready to use RF-Solution from Amber-Wireless and Formatted: Font: (Default) Microsoft
M-Bus Radio craft. Transmitter modules + EVA-Kits from Sans Serif, 11 pt, Font color: Auto
Unitronics, Panasonic, Radiometrix etc. Formatted: Left
Development .Ttools from Chipcon, Analog Devices
and another SRD-Chip Manufacturer.2
similar to 2.4GHz ZigBee solutions, Formatted: Font: (Default) Microsoft
1.4 ZigBee Sans Serif, Not Bold
@ however final system / meter not under control of
Chip providers Formatted: Font: (Default) Microsoft
868MHz Sans Serif, 11 pt, Not Bold
1.4 ZigBee Competition among silicon vendors drives
Formatted: Left
@ innovation, leading to strong development tools to
2.4GHz support ZigBee Smart Energy. For example,
Formatted Table
Page 90 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Ember’s AppBuilder tool will build ZSE compliant Formatted: Indent: Left: 0 cm
applications that can be immediately certified and Formatted: Centered
are ready for integration with the customer Formatted: Font: Not Bold, Font
application. color: Auto
A number of companies have been developing
Formatted Table
products to support smart energy, including for
example, Wavecom, who have a ZigBee virtual-IP Formatted: Indent: Left: 0 cm
implementation in their GSM gateway.
A number of independent commercial module

manufacturers provide cost effective ZigBee
modules using chips from a variety of silicon
manufacturers; e.g. Telegesis (Ember), Digi (Ember,
Freescale), Radiocrafts (TI), Panasonic (Freescale,
Ember), Meshnetics (Atmel), Holley (Ember). Formatted: Font: (Default) Microsoft
Z-Wave Alliance provides comprehensive Sans Serif, 11 pt
1.4 Z Wave
development kits, sample implementation, test and Formatted: Font: 11 pt
certification tools Formatted: Font: Not Bold
1.5 Bluetooth All Bluetooth systems are single chip these days, Formatted: Font: Microsoft Sans Serif,
low and integration sizes are shown by Bluetooth 11 pt, Not Bold
energy headsets such as the Apple headset Formatted: Font: (Default) Microsoft
Sans Serif
1.5 Wavenis Wavenis RF boards (2-chip solutions) are small
enough to be used by customers for door locks, call Formatted: Font: Not Bold
medallions/wristwatches, lightswitcheslight switches, Formatted: Font: Microsoft Sans Serif,
alarms, temperature control units and in-home 11 pt, Not Bold
displays for metering and HAN applications. Even Formatted: Font: (Default) Microsoft
smaller 12-chip solution is due in 2009, with Sans Serif
enhanced power-saving features. Current platform is Formatted: Font: Not Bold
available in different forms, depending on
integrator’s desired time-to-market (from ready-to-
use modules to development platforms).Very small
footprint with small antenna. Cost competitive SoC
solution available early 2009. And 2-chip solution
widely deployed in door locks, lighting control, alarm
systems, temperature control and smart display units
for both metering & HAN
1.5 Wireless Chipcon solution CC1101 4x4mm Formatted: Font: Microsoft Sans Serif,
Semtech SX1211 6x6mm 11 pt, Not Bold
M-Bus
Most applied metering µC MSP430 come next year Formatted: Font: (Default) Microsoft
for the first time with an integrated RF module. The Sans Serif
first available integrated solution to support SRD- Formatted: Font: Not Bold
Radio (very suitable for wireless M-Bus, but not
restricted to it)!
Ready to use RF-Solution from Amber-Wireless and
Radio craft.
Antenna size is the same for all solutions and
depends on Frequency only! Chip antennas Formatted: Font: Microsoft Sans Serif,
available (but not always recommended).2 11 pt, Not Bold
1.5 ZigBee 868 MHz requires larger antennas, Formatted: Font: (Default) Microsoft
@ PHY/MAC/NWK/APS layer similar to 2.4GHz Sans Serif
868MHz implementations Formatted: Font: Not Bold

Page 91 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
1.5 ZigBee There are three main models for ZigBee chips; Formatted: Indent: Left: 0 cm
@ a) System-on-chip (SoC) solutions (e.g. Ember Formatted: Centered

2.4GHz EM250, TI CC2430) which have an integrated Formatted: Font: Not Bold, Font
IEEE 802.15.4 radio and microcontroller, color: Auto
allowing the entire ZigBee stack and application Formatted: Indent: Left: -0.06 cm
to reside on a single chip. These are particularly
Formatted Table
important for small battery powered devices such
as thermostats. Most silicon vendors are Formatted: Font: Microsoft Sans Serif,
11 pt, Not Bold
developing their solutions further down this path,
providing more powerful microcontrollers and in Formatted: Left
some cases more flash and RAM space for Formatted Table
application code to run. This is the solution likely Formatted: Font: (Default) Microsoft
to drive ZigBee costs down in the next few years. Sans Serif, Not Bold
b) Network Coprocessor solutions (e.g. Ember Formatted: Font: (Default) Microsoft
EM260, TI CC2480) are not very common at the Sans Serif, 11 pt, Not Bold
moment among vendors, but nonetheless are Formatted: Indent: Left: 0 cm
proving popular in the smart energy space
Formatted: Bullets and Numbering
because of the ability to connect your favourite
ZigBee chips and software stack to your
preferred microcontroller. For instance, Ember
EM260 has been used in designs with Atmel
AVR, TI MSP430, Renesas H8, Microchip PIC,
STR7 etc. etc. Using this model, the designer
can continue to use the same micro as before in
the application design, just add a little code to
connect the ZigBee Coprocessor. This is not as
cost effective as SoC, but if you already have a
micro in your design (e.g. in a meter), it is a
cheaper and more efficient way to add ZigBee.
c) Dual chip solutions (e.g. Ember EM2420 + Atmel
AVR, Meshnetics Atmel AVR + Atmel radio, TI
CC2520 + MSP430). This is the older model of
operation, which is not quite as efficient as SoC,
but nonetheless preferred by some developers.
A range of antennae is available for ZigBee as for Formatted: Indent: Left: 0 cm

other 2.4GHz radios, some are customised
specifically for IEEE 802.15.4/ZigBee. The most
cost effective can be ceramic antennae, or even
printed antennae.
A range of options for the balun is also available,

including designs with discreet components (most
cost effective), ceramic balun and some vendors are
integrating the balun in the chip.
Power Amplification (PA) designs are also available Formatted: Indent: Left: 0 cm
to boost power up to +10dBm (Europe) or +20dBm
(US), including modular PA designs from e.g. TI and
Skyworks.
A range of competitive ZigBee modules for the same

chipsets and different ZigBee chipsets are available.
These allow the designer to avoid the hardware
Page 92 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
design headache, rather to take a proven, tested and Formatted: Indent: Left: 0 cm
certified design to integrate into the product. Formatted: Centered
1.5 Z Wave Industry smallest communication module (8mm x Formatted: Font: Not Bold, Font
8mm). Industries smallest single die 2.5mm x color: Auto
2.5mm. Formatted: Indent: Left: -0.06 cm
Large set of chip communication options (USB,
Formatted Table
UART, SPI) provides glue less integration into
products Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
1.6 Bluetooth Work could start very quickly to fully accommodate
your requirements. Formatted: Font: 11 pt
low
energy Formatted: Font: Not Bold
Formatted: Font: Microsoft Sans Serif,
1.6 Wavenis Wavenis wireless technology respects European 11 pt, Not Bold
communication standards and thus is fully compliant
for use in the UK. Metering application parameters Sans Serif
(i.e. embedded in end-points), such as scheduling,
Formatted: Font: Not Bold
automatic transmission, alert types, data content,
etc. are completely adjustable to meet current and Formatted: Font: Microsoft Sans Serif,
11 pt, Not Bold
future utility needs. Such changes and optimisations,
typically based on the existing core smart metering Formatted: Font: (Default) Microsoft
Sans Serif
solution are made using the Wavenis development
tools.Wide set of parameters available for water & Formatted: Font: Not Bold
gas smart metering. Flexibility for GB specific smart
energy market
1.6 Wireless Is a released European Standard. But it will be Formatted: Font: Microsoft Sans Serif,
worked on to fit Requirements of Smart metering as 11 pt, Not Bold
M-Bus
discussed in EU! This process has happened in Formatted: Font: Not Bold
Germany and in the Netherlands and could be
applied in GB as well. Cooperation between
countries is welcome and ongoing, and will lead to a
revision of standard!3
1.6 ZigBee no issues expected for HAN usage Formatted: Font: Microsoft Sans Serif,
11 pt, Not Bold
@
868MHz Formatted: Font: Not Bold
The ZigBee Alliance has a Smart Energy Working Formatted: Font: (Default) Microsoft
1.6 ZigBee Sans Serif, 11 pt, Font color: Auto
@ Group, which is open to members of the ZigBee
Alliance (membership is open). It is a relatively easy Formatted: Font: Microsoft Sans Serif,
2.4GHz 11 pt, Not Bold
process to discuss and propose changes to the
Smart Energy profile, OR propose a new profile. It Formatted: Left
probably can be done in 6 months or less, given that Formatted Table
the standard is most likely already 80-90% suitable Formatted: Font: (Default) Microsoft
for GB. Sans Serif, Not Bold
This process is happening right now for the Sans Serif, 11 pt, Not Bold
Australian requirements, which are being Formatted: Indent: Left: 0 cm
incorporated into the current ZSE spec, which was Formatted: Indent: Left: 0 cm
designed primarily by and for US utilities and
metering manufacturers.
The ZigBee Alliance is actively engaging with

European expert groups like the DLMS user
association and ESMIG, to assist with the integration
of European-specific protocols into the ZigBee
standard. In the US, this process is also happening
Page 93 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
to bring HomePlug devices into the ZigBee Smart Formatted: Indent: Left: 0 cm
Energy family. Formatted: Centered
1.6 Z Wave The Z-Wave Advanced Energy Control (AEC) Formatted: Font: Not Bold, Font
framework is targeted to provide remote metering, color: Auto
sub-metering, end-user information displays, Formatted: Indent: Left: -0.06 cm
advanced load control though other Z-wave devices
Formatted Table
and extensive support for prepayment meters.
The AEC framework supports any mix of meters Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
(gas, electricity, water etc)
2.1 Bluetooth Bluetooth is the definition of an open standard, with Formatted: Font: Microsoft Sans Serif,
an open intellectual property policy, and a wide 11 pt, Not Bold
low
energy range or participants from computers / phones / Formatted: Font: (Default) Microsoft
industrial / automation / consumer electronic and Sans Serif
other industries. Spec is available for $0 and can be
delivered in an end product for $0 royalty to
anybody.
2.1 Wavenis The Wavenis Open Standard Alliance (OSA) has Formatted: Font: Microsoft Sans Serif,
been launched, and is now open for membership. 11 pt, Not Bold
Key partners to include design houses, silicon Formatted: Font: (Default) Microsoft
vendors, meter manufacturers, utilities, software Sans Serif
providers, wireless solution providers, and one or
more independent certification bodies.Wavenis
Open Standard Alliance is up and running. Design
house, silicon vendors, meter manufacturers,
utilities, SW companies, wireless solution providers,
independent certification are joining
2.1 Wireless EN13757 is an open CEN -standard covering M-Bus Formatted: Font: Microsoft Sans Serif,
and DLMS and related communications. The British 11 pt, Not Bold
M-Bus
Standardisation Institute is involved in the European Formatted: Font: (Default) Microsoft
standardisation process (and voted in favour of last Sans Serif
adoptions of this standard). Several Companies in
GB are members of Working Group 5 (Radio
communication) to take care of the requirement of
the British market.4
2.1 ZigBee IEEE 802.15.4 / ZigBee are open standards Formatted: Font: Microsoft Sans Serif,
11 pt, Not Bold
@
868MHz Formatted: Font: (Default) Microsoft
Sans Serif
2.1 ZigBee The ZigBee Alliance is responsible for the
@ development and marketing of the ZigBee Sans Serif, 11 pt, Font color: Auto
2.4GHz standards. The Alliance is an open group of
approximately 300 companies which is open to new 11 pt, Not Bold
members, and currently includes silicon vendors,
Formatted: Left
meter manufacturers, electronics companies of
various sorts and customers such as utilities. Formatted Table
- The ZigBee Alliance is guided by a board of Formatted: Font: (Default) Microsoft

directors which consists of Promoter members of Sans Serif
the Alliance, and includes some of the largest Formatted: Indent: Left: 0 cm
silicon manufacturers, meter manufacturers and Formatted: Font: (Default) Microsoft
OEMs. Sans Serif
- The ZigBee Alliance has a small full-time staff, Formatted: Bullets and Numbering
which includes the Chairman, Dr. Bob Heile, who
has been involved with a number of IEEE 802
standards in the past.
Page 94 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
- Most of the work of the ZigBee Alliance is Formatted: Indent: Left: 0 cm

performed by staff from the member companies, Formatted: Centered
in areas where these companies have particular Formatted: Font: Not Bold, Font
interest. The working groups are always happy color: Auto
to accept new members and new member Formatted Table
companies into the discussions.
The ZigBee Specification and ZigBee Application Formatted: Indent: Left: 0 cm

Profiles are all available for download by non-
members from the ZigBee Alliance website.
Non members who wish to use the ZigBee standard Formatted: Indent: Left: 0 cm
for commercial gain must become members of the
ZigBee Alliance before that product is launched,
however if they wish to produce products or stacks
not for commercial gain (e.g. Universities) then they
are free to use the Intellectual Property of the ZigBee
Alliance without becoming members. There is no
royalty or license fee for use of the ZigBee
specifications or chipsets using the ZigBee
specification.
The ZigBee Alliance is a global organisation,

currently supported by 22 ZigBee Compliant
platforms, which customers can choose from, a
number of which are provided by global silicon
vendors such as Ember, ST, Renesas, Freescale, TI
and Microchip. This variety of implementations
across many regions of the World allows for genuine
competition between vendors both globally and
regionally on the basis of price, performance and
architecture. Formatted: Font: (Default) Microsoft
The Z-Wave Alliance was established in spring 2005 Sans Serif, 11 pt
2.1 Z Wave
and is open for any p00articipant. Today it has more Formatted: Font: (Default) Microsoft
than 170 members with more than 300 shipping Sans Serif
products around the world. The Z-Wave Alliance
governs the strict and yet low cost Z-wave
certification programme to ensure full
interoperability.
The convergence between Z-Wave and IP (Z/IP) is a
solid result of this effort.
2.2 Bluetooth Bluetooth supports basic cable replacement such as Formatted: Font: (Default) Microsoft
a serial cable replacement using an industry Sans Serif
low
energy designed protocol, although best use of attribute
protocol would enable best power consumption.
2.2 Wavenis Payload data can be either defined for specific GB Formatted: Font: (Default) Microsoft
market needs or leverage existing Wavenis-based Sans Serif
smart metering profiling (with millions of units
deployed).Payload data can be either defined for
specific GB market or can use the pre-defined set of
data
2.2 Wireless EN13757 is separated in parts describing Formatted: Font: (Default) Microsoft
Communication (wired and wireless communication) Sans Serif
M-Bus
and Application protocols like M-Bus or DLMS. Other
Page 95 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Protocols may also transport via communication Formatted: Indent: Left: 0 cm

modules. To be really interoperable, it is Formatted: Centered
recommended to restrict number of supported Formatted: Font: Not Bold, Font
protocols.4 color: Auto
2.2 ZigBee ZigBee does not restrict data exchange format Formatted: Indent: Left: -0.06 cm
@ Formatted Table
868MHz
Formatted
2.2 ZigBee Like all standards, at a low level there is at least
@ some fixed formatting of packets to ensure Sans Serif
2.4GHz interoperability between different ZigBee radios.
IEEE 802.15.4 specifies certain packet header Sans Serif, 11 pt, Font color: Auto
information that must exist to enable packets to be
received by the correct target node etc. Likewise,
the Networking (NWK) and Application Support Formatted: Left
(APS) layers of the ZigBee stack adds header Formatted Table
information to this protocol to support for example Formatted: Font: (Default) Microsoft
security, mesh routing and end to end Sans Serif
acknowledgements. Above the APS layer, the Formatted: Indent: Left: 0 cm
application is free to implement whatever data
exchange formatting it requires. Sans Serif
The ZigBee standard defines application profiles, Formatted: Indent: Left: 0 cm

which include (but are not exclusively) definitions of
the data exchange format for any given device in a
given application or network. By defining the data
exchange format in this way, interoperability
between devices manufactured by different
companies is enabled, and through certification by
an independent third party, is guaranteed. The
ZigBee Smart Energy (ZSE) profile is one such
application profile which defines the data exchange
format for a number of devices including meters,
gateways, in-home-displays and thermostats. Other
profiles include Home Automation (HA), Commercial
Building Automation (CBA), Telecoms Applications
(TA) and Personal Home Health Care (PHHC).
The use of these application profiles is not Formatted: Indent: Left: 0 cm

compulsory!
In fact, many of the 250 or so ZigBee products on Formatted: Indent: Left: 0 cm

the market today do not use any of the public
application profiles, mainly because there is no
requirement for interoperability with other vendors
because they are sold as part of a “whole system”.
These products can be certified as “Manufacturer
Specific Profiles” however they cannot carry the
ZigBee logo on the product to indicate
interoperability.
So, any private application profile (or data exchange Formatted: Indent: Left: 0 cm
format) can be implemented at an application level
on top of the ZigBee APS layer. In this way, any
private (or new public) data exchange format can be
Page 96 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
accommodated in a ZigBee application. Indeed, if Formatted: Centered

those who create this data exchange format wish to Formatted: Font: Not Bold, Font
do so, this can be published as a public application color: Auto
profile after it has been through the normal process Formatted: Indent: Left: 0 cm
for discussing, approving and testing public profiles. Formatted: Indent: Left: -0.06 cm
Formatted Table
Also, some of the current public application profiles
in ZigBee allow for ‘tunnelling’ of other data
exchange formats. In this way, most of the
application communications might use CBA
messaging for instance, but some of it could use
BACNET messaging. In the case of ZSE it is likely
that there will be a tunnelling mechanism for DLMS. Formatted: Font: (Default) Microsoft
The AEC framework allows a flexible and yet well Sans Serif, 11 pt
2.2 Z Wave
defined command structure between devices. Formatted: Font: (Default) Microsoft
Sans Serif
2.3 Bluetooth There are many silicon vendors shipping Bluetooth
low chips in the hundred’s of millions territory. Sans Serif
energy
2.3 Wavenis Wavenis uses the readily available TI CC1020, Formatted: Font: (Default) Microsoft
which is produced by several foundries (TSMS and Sans Serif
AMS). A second source for the Wavenis transceiver
is in progress (chip now undergoing testing) with
System-on-Chip partner. Other clearly identified
sourcing to come via Wavenis-OSA
members.Possible second source from TI CC1020
2.3 Wireless Chip-Manufacturers are Atmel, Analog Devices, Chip
M-Bus con/TI, Infinion, Melexis, Nordic, Semtech and
others; Technology is used in Home automation,
Automotive industry, Metering and much more.4
2.3 ZigBee other sub-1 GHz IEEE 802.15.4 IC solutions are Formatted: Font: (Default) Microsoft
expected soon on the market Sans Serif
@
2.3 ZigBee As stated already, there are currently 22 separate
@ ZigBee Compliant Platforms. Some of these are
2.4GHz different software stacks using the same silicon, and
some are more academic or regional in nature, and
so are not as competitive globally as some of the Formatted Table
others. There are a number of silicon vendors who Formatted: Font: (Default) Microsoft
have their own software stacks and tools (e.g. Sans Serif
Ember, Freescale, Renesas, TI, Jennic, Microchip Formatted: Indent: Left: 0 cm
etc.), and others who partner with software or Formatted: Font: (Default) Microsoft
module companies to deliver a ZigBee solution (e.g. Sans Serif
ST Micro, Atmel). There are certainly at least 5-7 Formatted: Left
highly competitive, global, ZigBee solutions on the
market today based on different silicon. Formatted: Font: (Default) Microsoft
2.3 Z Wave True Pin compatible 2nd source in 2009 Sans Serif, 11 pt
Sans Serif
2.4 Bluetooth Bluetooth has been interoperable at the chipset level
low for over 8 years. RF testing is compulsory and done Sans Serif
energy using certified equipment. MAC layer testing also
Page 97 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
done using certified equipment using an open testing Formatted: Indent: Left: 0 cm
process.12 Formatted: Centered
2.4 Wavenis Interoperability guaranteed through Wavenis-OSA Formatted: Font: Not Bold, Font
compliance certificatione color: Auto
Regulation of this open standard and neighbouring Formatted: Indent: Left: -0.06 cm
2.4 Wireless
M-Bus standards ensure interoperability of different chip Formatted Table
solutions.5 Formatted: Font: (Default) Microsoft
2.4 ZigBee open standards IEEE 802.15.4 / ZigBee ensure Sans Serif
@ interoperability between different solutions Formatted: Font: (Default) Microsoft
868MHz Sans Serif
2.4 ZigBee As already stated above, there are 22 ZigBee Formatted: Font: (Default) Microsoft
Sans Serif
@ Compliant Platforms and at least 5-7 of these are
2.4GHz genuinely highly competitive on a global scale. ALL Formatted: Font: (Default) Microsoft
compliant platforms go through interoperability
testing to ensure that the ZigBee stacks and radios Formatted: Font: (Default) Microsoft
can interoperate at that level. All ZigBee radios must
first pass IEEE 802.15.4 testing before they do Formatted: Font color: Auto
ZigBee Platform Compliance. Formatted: Left
Formatted Table
At an application level, each product manufacturer
must take the final application through Sans Serif
interoperability testing with an independent test
house before being certified and allowed to use the
ZigBee logo on products. This is nothing to do with Formatted: Font: (Default) Microsoft
Sans Serif
the chipsets per se, but it is essential for
interoperable products. Formatted: Font: (Default) Microsoft
Strong and proven history of backwards Sans Serif, 11 pt
2.4 Z Wave
interoperable chips through the last 6 years: Formatted: Font: (Default) Microsoft
ZW0102, ZW0201, ZW0301 and ZW0401 can all be Sans Serif
used in the same Z-Wave network
2.5 Bluetooth Effort required is to update specifications, guided by Formatted: Font: (Default) Microsoft
experienced members. You must provide feature Sans Serif
low
energy requirements documents, and help review the
specifications.
2.5 Wavenis Current solution is 100% compatible with GB Formatted: Font: (Default) Microsoft
regulations, with customers integrating Wavenis into Sans Serif
upcoming products for the UK. Changes to adapt to
new requirements would typically be made at the
application level, rather than the Wavenis wireless
level itself.Current solution is 100% compatible with
GB regulations
2.5 Wireless EN13757 is a special Standard to handle meter Formatted: Font: (Default) Microsoft
communications only. Regarding new requirements, Sans Serif
M-Bus
an extension of the standard is in discussion now.
The general conditions for Meter management differ
from country to country. Future requirements will be
adopted either in user associations (like e.g. DLMS-
UA) or by a standardisation working group.
Application protocol changes like new OBIS-Code
for a special data point may be introduced in 6 to 12
12
The group evaluation session were not comfortable with the Bluetooth statement as no low
energy chips are currently available Formatted: English (United Kingdom)
Page 98 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
months.4 Formatted: Indent: Left: 0 cm
2.5 ZigBee no need to update standard, IEEE 802.15.4 / ZigBee Formatted: Centered
@ are specified to meet requirements Formatted: Font: Not Bold, Font
868MHz color: Auto
2.5 ZigBee It is hard to say for certain, as the GB requirements Formatted Table
@ are not yet so clear, however it seems that the Formatted: Indent: Left: -0.06 cm
2.4GHz requirements for GB ought not be so different from Formatted: Font: (Default) Microsoft
those for HAN communications in the US and Sans Serif
Australia. I suggest that GB smart metering could Formatted: Font: (Default) Microsoft
decide to adopt 100% the ZigBee Smart Energy Sans Serif, 11 pt, Font color: Auto
profile with a minimum of minor adjustments. Formatted: Font: (Default) Microsoft
There are some requirements that may cause Formatted: Font color: Auto
modifications to the ZSE profile, such as the use of
Formatted: Left
DLMS for some parts of the network, or introduction
of some new messaging protocol. In any case, all Formatted Table
the mechanisms exist to allow for discussion, Formatted: Font: (Default) Microsoft
drafting, completion and testing of such changes Sans Serif
within the structure of the ZigBee Alliance. Formatted: Indent: Left: 0 cm
2.5 Z Wave Very little - The AEC is developed with the GB Formatted: Font: (Default) Microsoft
requirements as part of the foundation. The flexible Sans Serif
framework allows for fast changes if late GB Formatted: Font: (Default) Microsoft
requirement changes should occur. Sans Serif, 11 pt
2.6 Bluetooth Bluetooth low energy does not keep active Formatted: Font: (Default) Microsoft
low connections for very long, therefore the maximum Sans Serif
energy supported nodes is approximately 2 billion. Active Formatted: Font: (Default) Microsoft
connections would be closer to a couple of Sans Serif
thousand.
2.6 Wavenis The number of Wavenis nodes in a complete Formatted: Font: (Default) Microsoft
network is unlimited Unlimited. (6-byte MAC Sans Serif
address). Generally speaking, gateways (i.e. GPRS)
connect from 2,000 - 4,000 meter end-points in
actual deployment situations, which provides optimal
battery life as well as network robustness.Unlimited.
(6-byte MAC address)
2.6 Wireless There is no limitation (Address range is 8 Byte)4 Formatted: Font: (Default) Microsoft
Sans Serif
M-Bus
2.6 ZigBee no of maximum supportable (addressable) Formatted: Font: (Default) Microsoft
IEEE802.15.4 / ZigBee nodes much higher than Sans Serif
@
868MHz minimum requirement Formatted: Font: (Default) Microsoft
2.6 ZigBee ZigBee supports up to 65,000 nodes in a network,
@ however the practical limits of such networks are
2.4GHz usually dictated by traffic and application model. Formatted: Left
Certainly many ZigBee networks exist today with Formatted Table
several hundred nodes per network and thousands Formatted: Font: (Default) Microsoft
of nodes should be easily achievable. Sans Serif
Most home automation vendors consider the
possibility of about 200 nodes in a home, and when Sans Serif
you consider every power outlet, every light and light
switch, every shutter/blind, every closure in a
security application, you can see how it could be
possible to have that number of nodes in a single
Page 99 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
network. ZigBee can easily handle that number, in Formatted: Indent: Left: 0 cm
fact the more nodes in a network the more robust the Formatted: Centered
ZigBee mesh network becomes. Formatted: Font: Not Bold, Font
2.6 Z Wave Z-Wave supports 232 nodes within one Z-wave color: Auto
segment (HomeID). More nodes can easily be Formatted: Indent: Left: -0.06 cm
supported by using segments through the Z/IP
Formatted Table
Gateway.
Bluetooth chips in their 5th or 6th generation are Formatted: Font: (Default) Microsoft
3.1 Bluetooth Sans Serif, 11 pt
low quoting peak instantaneous current draw when
transmitting of approximately 20mA, however duty Formatted: Font: (Default) Microsoft
energy Sans Serif
cycle guarantees can lower this down to 12 mA as
required by button cell batteries. Power failure is not Formatted: Font: (Default) Microsoft
Sans Serif, Not Bold
an issue as connections are as required not
permanent. Formatted: Font: (Default) Microsoft
Sans Serif
3.1 Wavenis - 10µA average operating current with 1s period time
- 18mA full run Rx and 5mW class Tx
- 45mA full run for 25mW class Tx Formatted: Font: (Default) Microsoft
Sans Serif
- 500mA full run for 500mW class Tx
- Low-battery detection and permanent energy Formatted: Font: Not Bold
counter tracking
Every 1s (typical value for metering), Wavenis

devices wake-up from sleep mode (1µA) to Rx RSSI
detection mode. If no energy is detected on the
channel, the Wavenis device goes back to sleep
mode. This only takes about 500µs. If energy is
detected, Wavenis Rx full run is activated to detect
signal coherence. If the signal is incoherent, the
Wavenis device goes back to sleep mode. This only
takes 1. 6ms.
But when talking about power consumption, we also

have to consider the behaviour of the entire network.
This is why several FHSS algorithms have been
implemented to avoid the over-hearing phenomenon
and provide efficient mesh network services.
- A relaxed synchronization beacon is transmitted Formatted: Bullets and Numbering

every 90mn throughout the network to align
clocks and wake-up timings for all devices. A
hopping table is calculated based on a pseudo-
random sequence.
- Periodic receive-standby mode is set to ~1s for

metering. This gives a 1s latency time at worst
for a direct link or 4s at worst in case of 3 relays.
Each device calculates its own pseudo-random
hopping table based on its own MAC address.
- Lastly, transmission implements a fast FHSS Formatted: Bulleted + Level: 1 +

with pseudo-random frequency hops every 2 Aligned at: 0 cm + Indent at: 0.63 cm
bytes
- 10µA average operating current with 1s response
time
- 18mA full run Rx and 5mW Tx
Page 100 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
- 45mA full run for 25mW class Formatted: Indent: Left: 0 cm

- 500mA full run for 500mW class Tx Formatted: Centered
- Low-battery detection and permanent energy Formatted: Font: Not Bold, Font
counter tracking color: Auto
3.1 Wireless ultraUltra low power (e.g. 10 years 1Ah). There is no Formatted: Indent: Left: -0.06 cm
M-Bus requirement other than the application itself sending
Formatted Table
data. Therefore the power consumption will be
controlled by the meter itself. For a battery powered Formatted: Font: (Default) Microsoft
Sans Serif
meter, the battery size is normally restricted by price.
However a long lifetime may be ensured by the Formatted: Font: Not Bold
selection of transmission power and data rate.
Example: A meter sends 2 Telegrams per hour with
a higher power e.g. 12 dBm (using 60 mA) and slow
data rate (S-mode). It needs 0.1Ah for Transmission
power over 10 Years. Another meter using a faster
data rate (T-mode) with 5 dBm (using 30 mA) may
transmit 10 times faster using same energy.
Because there is no synchronisation required, a
Power fail of a mains supplied unit will not affect the
system (excluded time of power fail).ultra low power Formatted: Font: (Default) Microsoft
(e.g. 10 years 1Ah) Sans Serif
3.1 ZigBee Formatted: Font: (Default) Microsoft

Sans Serif
@
868MHz Formatted: Font: Not Bold
3.1 ZigBee Power consumption will differ from different silicon Formatted: Font color: Auto
@ vendors, and this is one area where competition is Formatted: Left
2.4GHz strong. Typically, power consumption is a trade off
Formatted Table
against RF performance, so a chip that uses 25mA
transmitting at 0dBm might not be as desirable as Formatted: Font: (Default) Microsoft
one which uses 35mA transmitting at +3dBm. It is
also necessary to consider whether an external PA Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt, Not Bold
will be used, and in many Smart Energy situations it
would probably be advisable to use a PA to +10dBm.
It is also fair to say that much innovation in the area
of power consumption is under way as part of this
competition between vendors and there is an
expectation that it will improve in the next couple of
years.
There are two main models to look at: routing

devices (which have a constant source of power)
and sleepy end devices (which are battery powered).
Routing devices must have the radio on in receive

mode at all times, in order to be able to receive a
message from another device, either for itself or to
be routed on in the network. Typical power
consumption in receive mode is between 25mA and
35mA today, and I would expect that to go down to
between 15mA and 25mA in the next 3-4 years. In
transmit mode, which occurs rarely compared to
receive mode, devices differ greatly in both power
consumed and transmit power achieved, typically
between about 25mA to transmit at 0dBm to about
Page 101 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
40mA to transmit at +5dBm. Power amplifiers to Formatted: Indent: Left: 0 cm

bring transmit power up to +10dBm could bring total Formatted: Font: Not Bold, Font
power consumption during TX to as much as 100mA, color: Auto
but again this is improving all the time. Formatted: Centered
Sleepy End Devices spend most of the time in a
Formatted Table
sleep mode, either on a timer or waiting for some
external interrupt (a line brought high/low, button
push etc.). While asleep, the best ZigBee devices
can draw as little as 600-700nA, and most will
consume a small number of uA (microAmp). When
awake and transmitting, the figures for transmit
power above will apply, though usually only for a
very small percentage of the total time. Most Sleepy
End Devices have a duty cycle less than 1%, and
many are less than 0.1%.
Most devices have some sort of internal or external

brownout detection and the range of voltages
supported differs from chip to chip, but many can
survive down to about 2.1V.
Reset management will depend on the

implementation of the stack, but the best
implementations allow a node to simply reload
network parameters from non-volatile memory and
re-associate with the network after a power reset. Formatted: Font: (Default) Microsoft
Z-Wave is one of the leaders in low power Sans Serif, 11 pt
3.1 Z Wave
consumption – System on chip with: Formatted: Font: (Default) Microsoft
• 20 mA in receive mode (with MCU running) Sans Serif
• 20 mA in transmit mode (with MCU running; up Formatted: Font: (Default) Microsoft

to + 5dBm)
• Low battery alerts Formatted: Font: 11 pt
3.2 Bluetooth Routing is a profile issue, and while not in the core Formatted
low standard, can be added within the profile as Formatted: Bullets and Numbering
energy required. Concepts of gateways, routers and relay Formatted: Body Bullets,
nodes are in the specification, as are the concepts of Widow/Orphan control, Adjust space
publish and subscribe – the only low power way of between Latin and Asian text, Adjust
getting data from a device. space between Asian text and numbers
3.2 Wavenis Since 2000, Wavenis development has focused on Formatted: Font: Microsoft Sans Serif,
achieving the optimal compromise of ultra-low power 11 pt, Not Bold
consumption and long wireless range. Application Formatted: Font: (Default) Microsoft
level metering solutions for (and by) customers also Sans Serif
play an important role in efficient end-point and Formatted: Font: Not Bold
power management. Programmable data logging Formatted: Font: Microsoft Sans Serif,
and periodic transmission, plus smart sleep cycles, 11 pt, Not Bold
network synchronization and protection against Formatted: Font: (Default) Microsoft
“overhearing” in the wireless network contribute to Sans Serif
optimising performance with respect to loads, Formatted: Font: Not Bold
distance and reliability. All Wavenis nodes in the Formatted: Left
network can act as repeaters for more remote
nodes.Programmable periodic data logging.
Programmable periodic wireless transmission that fit
GB telecom regulations
Page 102 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
3.2 Wireless The Meter data are transmitted periodically. Data Formatted Table
M-Bus may used from every reception unit (e.g. Flat Formatted: Centered
display), which own an encryption key. The Formatted: Font: Not Bold, Font
transmission interval is scalable from minutes to one color: Auto
hour. In the case of radio link extension proprietary Formatted: Indent: Left: 0 cm
network solutions or standardised repeater can be
applied.proprietary network solutions or
standardised repeater Formatted: Font: Microsoft Sans Serif,
11 pt, Not Bold
3.2 ZigBee
@ Sans Serif
868MHz
3.2 ZigBee I believe we discussed this in the forum and decided Formatted: Font: (Default) Microsoft
@ that the requirement was NOT for battery powered Sans Serif
2.4GHz devices to be able to relay messages in a mesh Formatted: Font: Microsoft Sans Serif,
network, rather to allow for some battery powered 11 pt, Not Bold
devices to be part of the network and participate
occasionally, with long battery life (e.g. Gas Meters). Sans Serif
To that end, Sleepy End Devices in ZigBee are a
fully supported part of the specification and are
11 pt, Not Bold
routinely used in applications for light switches,
Formatted Table
thermostats, gas meters, etc. Such devices routinely
achieve 10+ years of battery life, though of course Formatted: Font: (Default) Microsoft
this depends on the application requirements, how
often the device communicates etc. Formatted: Font: (Default) Microsoft
For what it is worth, the ZigBee Alliance currently Formatted: Left

has a working group investigating low power routing
(the ability to run an entire mesh network entirely on
battery powered devices). We expect this to be
added into the spec in the 2010 time frame at the
earliest. However, it should be noted that it is not
possible to achieve the same battery life with a low
power router as it is with a sleepy end device
because of the mechanism required to maintain a
mesh network while also sleeping all devices. I can
expand on this if necessary. Formatted: Font: (Default) Microsoft
• 1 μA in sleep mode (with POR, interrupts, and Sans Serif, 11 pt
3.2 Z Wave
wakeup timer running) Formatted: Font: (Default) Microsoft
Sans Serif
• Only standard with support of battery-to-battery
networks Formatted: Font: 11 pt
• 30-80 μA average power consumption in battery- Formatted
to-battery networks Formatted: Bullets and Numbering
• No risk of early power source depletion due to Formatted: Body Bullets,
WiFi interference Widow/Orphan control, Adjust space
4.1 Bluetooth Bluetooth low energy can support 200 kbps, between Latin and Asian text, Adjust
low although doing that is not power efficient. We can
energy transmit very short packets very quickly at a raw Formatted: Font: (Default) Microsoft
Sans Serif
physical layer rate of 1 Mbps
4.1 Wavenis In smart metering, data throughput itself is not a real Formatted: Font: (Default) Microsoft
issue. It may be when you start adding other home Sans Serif
devices, but high data traffic requirements are at the
opposite end of the spectrum from metering
Page 103 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
solutions, which only transmit packets occasionally Formatted: Indent: Left: 0 cm

(especially for water and gas). With mains power Formatted: Centered
(electric metering) transmission speed can be Formatted: Font: Not Bold, Font
bumped up. Assuming the requirements include long color: Auto
battery life and long range (or robustness over short Formatted: Indent: Left: -0.06 cm
range), then high-throughput is not necessary.
Formatted Table
Typically, Wavenis is used from 4.8 – 38.4 kbps, with
1/3 data redundancy.
Based on 1s periodic time (Rx-Sby), Wavenis offers

1s latency at worst. In case of 3 hops, latency is 4s
max9,6kbps, 19,2kbps standard throughput with 1/3
redundancy
4.1 Wireless 66kbs (T) or 16 kbps (S) Formatted: Font: (Default) Microsoft
Sans Serif
M-Bus
4.1 ZigBee PSDU data rate Sans Serif
@ BPSK 20 kb/s OQPSK 100 kb/s
868MHz Sans Serif
4.1 ZigBee Raw data rate between ZigBee 2.4GHz radios is Formatted: Font: (Default) Microsoft
@ 250kbps. Sans Serif, 11 pt, Font color: Auto
2.4GHz Formatted: Left
Point to point with ZigBee messaging this works out Formatted: Font: Microsoft Sans Serif,
at about 50kbps real data throughput. 11 pt, Not Bold
Formatted: Left
In a ZigBee network with messages travelling
Formatted Table
multiple hops, using security and end to end
acknowledgements I would expect 15-20kbps real Formatted: Font color: Auto
data throughput. Formatted: Font: (Default) Microsoft
Sans Serif
For local communications in the UK, most of the Formatted: Indent: Left: 0 cm
networks will be relatively small, and most Formatted: Font: (Default) Microsoft
communications will be 1-2 hops. In this scenario I Sans Serif
would expect real data throughput in excess of 25-
30kbps. Formatted: Font: (Default) Microsoft
Z-Wave supports a mix of 9.6kbps, 40kbps and Sans Serif, 11 pt
4.1 Z Wave
100kbps communication in the same network. This Formatted: Font: (Default) Microsoft
allows manufacturers to trade longer range for less Sans Serif
throughput as the range decreases significantly as
data rate increases. The effective data rate is up to
60% of the raw data rate due to very low frame
overhead.
4.2 Bluetooth Immediate acknowledge (power optimized), Formatted: Font: (Default) Microsoft
Active frequency hopping, immediate Sans Serif
low
energy retransmission, Formatted: Left
24bit CRC on every packet,
32 bit message integrity check on encrypted
packets.
4.2 Wavenis Wavenis includes mechanisms to successfully Formatted: Font: 11 pt
establish data connection on the first attempt, thus Formatted: Left
protecting battery life while reducing the need for
retries. An alert is raised to the application layer after
3 unsuccessful automatic retries. Packets are
acknowledged, and fast FHSS, data interleaving,
Page 104 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
data scrambling, Forward Error Correction with Formatted: Indent: Left: 0 cm

BCH(BCH (21,31, 31) coding and CSMA-CA make it Formatted: Font: Not Bold, Font
possible to maximize data reliability and drastically color: Auto
reduce channel interference.Fast FHSS, data Formatted: Centered
interleaving, data scrambling, Forward Error Formatted: Indent: Left: -0.06 cm
Correction with BCH(21,31) coding
Formatted Table
Transparent retries, error flags, ACK, CSMA-CA
Latency between 1 to 60 minutes for RF Formatted: Font: 11 pt
4.2 Wireless
M-Bus Formatted: Font: 11 pt
retry mechanisms are well defined by IEEE802.15.4 Formatted: Font: (Default) Microsoft
4.2 ZigBee Sans Serif
@
868MHz Sans Serif, 11 pt, Font color: Auto
4.2 ZigBee At an IEEE 802.15.4 MAC level, there is a clear Formatted: Font color: Auto
@ channel assessment before sending a message, and
Formatted: Left
2.4GHz there is a MAC acknowledgement and retry
mechanism that allows for 4 attempts if the message Formatted Table
does not get through. At an Application Support Formatted: Font: (Default) Microsoft
Sublayer (APS) level, a ZigBee application may use Sans Serif
end-to-end acknowledgements and 3 attempts. In Formatted: Font: (Default) Microsoft
total this means that for any message sent that fails Sans Serif
to get through, the ZigBee stack has tried 12 times to Formatted: Indent: Left: 0 cm
get this through over a period of up to about 4.5
seconds typically. Even with high levels of
interference, this usually means there is no message
loss, with a possible impact on latency (by design).
In most implementations the application will get a

callback to indicate success or failure of the
message, whether using MAC acknowledgements
only, or APS acknowledgements. Typical latency of
a message one hop in a clear ZigBee network is
<10ms (typical is more like 4ms). Timeout
mechanisms allow for up to 50ms per hop before it is
assumed a message has failed. Formatted: Font: (Default) Microsoft
The Z-Wave protocol implements standard collision Sans Serif, 11 pt
4.2 Z Wave
avoidance and random back-off algorithms. Formatted: Font: (Default) Microsoft
Every message is governed both by a node-2-node Sans Serif
acknowledgement and an end-2-end
acknowledgement.
Additionally the routing protocol automatically tries
alternative routes should parts of the network be ‘off-
line’
5.1 Bluetooth 300m typical for good RF design. More in expensive Formatted: Font: (Default) Microsoft
PA’s are used Sans Serif
low
energy
5.1 Wavenis -113dBm sensitivity Formatted: Font: (Default) Microsoft
+14dBm output Sans Serif
Î 127dB link budget
Helicoidal antennas of -3dBi in metering devices. For

small footrprintfootprint casing in HAN devices (such
as a CR2032 battery-powered light switch), a piece
of wire is generally used.
Page 105 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08

Formatted: Centered
In addition, 868MHz band features 9dB less LOS Formatted: Font: Not Bold, Font
attenuation vs. 2.4GHz. Also, 868MHz offers better color: Auto
propagation through walls and flooring materials. Formatted: Indent: Left: 0 cm
- 1mW: 80m indoor (industrial lighting control Formatted: Indent: Left: -0.06 cm
products)
Formatted Table
- 25mW: 30-300m in real world metering scenarios
(underground, home, flat, building, commercial, Formatted
industrial)
- 500mW: few km for large area coverage with cost
effective battery powered range extenders-113dBm
sensitivity
+14dBm output
=> 127dB link budget
Type helicoidal antennas of -3dBi in metering

devices
For critical packaging-housing (CR2032 battery

powered light switch) HAN, piece of wire is generally
used
In addition, 868MHz band features 9dB less LOS

attenuation vs. 2.4GHz
Also, 868MHz shows better propagation through
walls and flooring materials
- 1mW: 80m indoor (industrial lighting control

products)
- 25mW: 30-300m in real world metering scenarios
(underground, home, flat, building, commercial,
industrial)
- 500mW: few km for large area coverage with cost
effective battery powered range extenders
5.1 Wireless Range typically 25 m in Building Formatted: Font: (Default) Microsoft
Sans Serif
M-Bus
-106 dBm sensitivity
+14 dBm output power (non amplified)
=> 120 dBm link budget
To use a small battery a meter typically applies

+8..10 dBm chip output power. This will reduce
current consumption from more than 70mA to less
than 20 mA. Higher pulse current will significantly
increase the price of the battery. Small antennas and
bad installation conditions may reduce power on air
by 3 to 10 dB. However this will cover typically two or
three floor levels (depending on building), assumed
that data rate is slow enough to support a sensitive
receiver.
868 MHz reduces link lost by reflection, has less

Free space attenuation than 2,4GHz (9dB) and less
wall loss
In very critical buildings it may better (cheaper) to
Page 106 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
use a wired or hybrid (wired/wireless) solution. Formatted: Indent: Left: 0 cm

Formatted: Centered
PS: We are talking about indoor communication so I
don’t attach a LOS-calculation!25 m in Building color: Auto
5.1 ZigBee typ. range is factor 2.8 higher than 2.4 GHz, about
@ 4.4 km for OQPSK and further increased for BPSK
modulation, refer to ZigBee 868 MHz presentation Formatted Table
868MHz
5.1 ZigBee This will differ between ZigBee vendors, as it Sans Serif
@ depends on the receive sensitivity of the receiving
2.4GHz radio and the transmit power of the sending radio. Sans Serif
The best ZigBee chips have a receive sensitivity of -
99dBm to -100dBm and a transmit power of +3dBm Sans Serif, 11 pt, Font color: Auto
to +5dBm, which leads to a best-case unamplified
dynamic link budget of about 104dBm. Theoretically
this should deliver about 1Km line of sight in free Formatted: Left
space, however in reality this usually translates to Formatted Table
between 400m-700m. Formatted: Font: (Default) Microsoft
Sans Serif
Amplifying output to +10dBm, which equates to Formatted: Indent: Left: 0 cm
10mW, the limit in Europe, this should increase the
dynamic range to perhaps as much as 110dBm, and Sans Serif
in reality delivers LOS range between 600m to 1Km.
5.1 Z Wave When not amplified Z-Wave chips support up to Sans Serif, 11 pt
100+ dB RF system budget at sub-1GHz (depending Formatted: Font: (Default) Microsoft
on data rate). This translates in to typical 60m-100m Sans Serif
outdoor / 30m-40m indoor. Additional range can be
obtained through the mesh network or through
external amplifiers.
5.2 Bluetooth As long as there is a small gap, Bluetooth will get Formatted: Font: (Default) Microsoft
signals through. This could be a keyhole, or window. Sans Serif
low
energy Multipath is allowed, and encouraged in Bluetooth,
enabling a much more robust link than static or wide
signals.
5.2 Wavenis With a point-to-point range of hundreds of meters Formatted: Font: (Default) Microsoft
(line of sight), Wavenis has proven itself in harsh Sans Serif
environments in large-scale metering networks
deployed and operated by utilities around the world.
This includes both devices with an external RF
module, and those with Wavenis integrated “under
glass”, used in dense urban areas (lots of
apartments) and sprawling rural areas. FHSS
techniques feature more robustness in case of
multipath or signal fading, and FH spread spectrum
ensures recovery of desired signals. Also, the
868MHz band is more efficient in term of
propagation when compared to 2.4GHz. In case of
short range requirements only, this lead to reduced
output power, thus the ability to use smaller
batteries, which leads to even more competitive
pricing.Field proven wireless technology and large
scale metering networks deployed and operated by
utilities in harsh environments. Wavenis platforms
integrated in metallic. Both underglass technology
and external wireless units deployed.
Page 107 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
5.2 Wireless Internal/external installation is a question of the Formatted Table

M-Bus meter housing and of the link budget. Building Formatted: Centered
structure and installation environment generate an Formatted: Font: Not Bold, Font
uncertainty of Link attenuation. This can only be color: Auto
solved by suitable Link budget. Ranking is Formatted: Indent: Left: 0 cm
comparable with Ref. 5.1.Has GB harder Buildings
than other countries in Europe?
868 MHz operation is much more robust compared Formatted: Font: (Default) Microsoft
5.2 ZigBee Sans Serif
@ to 2.4 GHz operation
868MHz Sans Serif
5.2 ZigBee Typical range within UK homes is about 15-20m Formatted: Font: (Default) Microsoft
@ point to point. Sans Serif
2.4GHz Formatted: Font: (Default) Microsoft
When powered nodes are available (like with Sans Serif, 11 pt, Font color: Auto
smartplug-type devices which always have power) Formatted: Font color: Auto
this allows any communication to be routed over
Formatted: Left
multiple hops.
Formatted Table
Anecdotally, Alertme noted that 80% of homes did Formatted: Font: (Default) Microsoft
not require a repeater/router of any sort (all Sans Serif
Communications point to point), with their Formatted: Font: (Default) Microsoft
coordinator node operating unamplified at +5dBm Sans Serif
and their sensor nodes operating unamplified at Formatted: Indent: Left: 0 cm
+3dBm, both types of nodes using a suboptimal
antenna. Formatted: Font: (Default) Microsoft
High RF system budget along with long range due to Sans Serif, 11 pt
5.2 Z Wave
sub-1GHz communication. Strong Mesh extends the Formatted: Font: (Default) Microsoft
range through multiple hops. Sans Serif
Formatted: Left
Successful 2500 trial electricity and gas installations
in UK without ‘location issues’.
5.3 Bluetooth Very low – narrow band signals can push through Formatted: Font: (Default) Microsoft
wide band interferers. A narrow band interferer Sans Serif
low
energy would be frequency hopped around. AFH allows for
characterisation and mapping out bad frequencies.
5.3 Wavenis Very strong robustness against signal interference Formatted: Font: (Default) Microsoft
due to fast FHSS (every 2 bytes), FEC, data Sans Serif
scrambling, data interleaving and automatic retries.
Use of 868MHz means using the very low duty cycle
imposed by ETS300-220. No risk of 2.4GHz
jammers.Very strong robustness against interference Sans Serif
due to fast FHSS (every 2 bytes), FEC, data
scrambling and data interleaving. Sans Serif
5.3 Wireless Radio traffic is regulated in the 868 MHz-Band by
M-Bus CEPT. Due to the small Bandwidth and small duty Sans Serif, 11 pt, Font color: Auto
cycle, the collision rate is low. If a collision happens
telegram can be requested again (Retry).1
handled by modulation scheme DSSS and Formatted: Left
5.3 ZigBee
@ supported by retry mechanisms Formatted Table
Sans Serif
5.3 ZigBee While 2.4GHz is very popular for WiFi (IEEE
802.11.b/g/n), Bluetooth and other communications Formatted: Indent: Left: 0 cm
@
2.4GHz technologies, ZigBee coexists very well even when Formatted: Font: (Default) Microsoft
Sans Serif
Page 108 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
sharing the same channel with those other Formatted: Indent: Left: 0 cm
technologies. The best treatment of this subject Formatted: Centered
available is the report already known to the ERA Formatted: Font: Not Bold, Font
from Schneider Electric, and it concludes that color: Auto
ZigBee survives well even in very adverse (and very Formatted: Indent: Left: -0.06 cm
untypical) conditions.
Formatted Table
Some characteristics will differ from chipset to

chipset, so can be assessed between competitors. Formatted: Font: (Default) Microsoft
Z-Wave uses the well regulated 868MHz 1% duty Sans Serif, 11 pt
5.3 Z Wave
cycle band in Europe. Formatted: Font: (Default) Microsoft
No interference from WiFi and other high power Sans Serif
2.4Ghz ‘jammers’
5.4 Bluetooth AFH is the best solution for this problem. Signal Formatted: Font: (Default) Microsoft
interference in the 2.4 GHz band comes from other Sans Serif
low
energy devices like microwave ovens, street lighting, alarm
systems and wireless communication systems.
Bluetooth can deal with all of these. Bluetooth also
has power control, allowing for robustness against a
rising noise floor.
5.4 Wavenis Transparent recovery of lost packets. Increased Formatted: Font: (Default) Microsoft
probability of TX success on first attempt. This is Sans Serif
also a significant contributor to power savings
contributor.Strong capability to recover lost packets.
Increase the probability of TX success on the fist
attempt. Power savings contributor
5.4 Wireless Consumption data are transmitted periodically. This Formatted: Font: (Default) Microsoft
protects temporary interference in channel. High Sans Serif
M-Bus
transmission power, Modulation index and limited
receiver bandwidth reduces effect of interference. In
case of strong interference data has to be
retransmitted at later time.1
5.4 ZigBee specified by IEEE802.15.4 in view of typical Formatted: Font: (Default) Microsoft
interference scenarios, higher robustness compared Sans Serif
@
868MHz to 2.4 GHz operation Formatted: Font: (Default) Microsoft
5.4 ZigBee Subject to 5.3, IF a ZigBee network suffers from
@ interference, there is a standard mechanism for
2.4GHz moving the network to one of the other 15 IEEE Formatted Table
802.15.4 channels available at 2.4GHz. Formatted: Font: (Default) Microsoft
5.4 Z Wave Advanced Frequency agility on a frame per frame Sans Serif
basis without frame loss. Every Z-Wave node Formatted: Indent: Left: 0 cm
concurrently listens on two channels. The transmitter Formatted: Font: (Default) Microsoft
always selects the optimal channel for each Sans Serif
message based on RSSI and adaptive mechanisms. Formatted: Left
This allows parts of the network to operate
simultaneously at different channels thereby Sans Serif, 11 pt
maximizing the communication success in even
highly congested scenarios. Sans Serif
5.5 Bluetooth We work in a small device next to a 1W transmitter a
low few kHz away. Mobile phones with GSM Sans Serif
energy transmitters. Not a problem.
Operation in 868MHz band with channel bandwidth Formatted: Font: (Default) Microsoft
5.5 Wavenis Sans Serif
Page 109 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
of 50kHz @ 9,6kbps: Formatted: Centered

- Blocking: 75dBc @ 10MHz color: Auto
- ACP (Adjacent Power Rejection): -37dBm @
50kHz (in compliance with ETS300-220) Formatted: Indent: Left: -0.06 cm
Formatted Table
- ACR (Adjacent Channel Rejection) : 16dB @
50kHz & 30dB@ 100kHz (in compliance with
ETS300-220)High immunity thanks to Low IF
architecture. Immune when coexisting with GSM but
also when installed in home power switch board
5.5 Wireless Different Receiver classes are defined in EN13757- Formatted: Font: (Default) Microsoft
4. Class HR requires a blocking rejection of at least Sans Serif
M-Bus
40 dB to the adjacent channel.look for Receiver Formatted: Font: 11 pt
class Formatted: Font: (Default) Microsoft
5.5 ZigBee covered by IEEE802.15.4 specification and further Sans Serif
@ MAC retry mechanisms Formatted: Font: (Default) Microsoft
868MHz Sans Serif
5.5 ZigBee This will differ from chipset to chipset, but all IEEE Formatted: Font: (Default) Microsoft
@ 802.15.4 radios have basic blocking immunity built
2.4GHz in. For example, Ember EM250 has adjacent Formatted: Font color: Auto
channel rejection at -82dB of 35dB and 2nd channel Formatted: Left
rejection of 43dB, with channel rejection for all other Formatted Table
channels at 40dB, along with 802.11g rejection
centred at +12MHz or -13MHz of 40dB. I do not Sans Serif
have figures for other ZigBee chipsets.
5.5 Z Wave All Z-Wave nodes are equipped with a SAW filter –
efficiently shielding for signals outside the band Formatted: Font: (Default) Microsoft
Sans Serif
(such as GSM phones). Additionally the Z-Wave
receivers have a high blocking performance due to Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
narrow band 2FSK/4FSK modulation
6.1 Bluetooth Secure Simple Pairing is the most advanced ad hoc
Sans Serif
low authentication scheme around. Standard in v2.1
energy devices. Uses elliptic curve cryptography, the FIPS
Sans Serif
P192 curve, and peer reviewed security algorithms.
Low energy uses AES 128 with a 32 bit Message Formatted: Left
Authentication Code, using counter mode as

approved by NIST.
6.1 Wavenis Data sent over the air via Wavenis is secured in Formatted: Font: (Default) Microsoft
multiple ways, making it totally impossible for an Sans Serif
unwanted device to simulate a reader or capture
data in an unwanted manner.
Data encryption can be implemented as an option,

using AES-128, DES, 3-DES
More importantly, when requested by the application,

all data exchange between devices in any given
network is highly secured natively using a key
exchange mechanism based on public, private,
network and random keys. The result is exactly like a
rolling key solution. Data is ONLY readable by
products that are designed to be compatible, and
Page 110 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
products from competitors or nearby networks could Formatted: Centered

NEVER interoperate unless by design. Even if data Formatted: Font: Not Bold, Font
were “sniffed”, it would be totally useless (scrambled color: Auto
AND encrypted!). A random key is generated for Formatted: Indent: Left: 0 cm
every exchange, thus establishing the key to be Formatted: Indent: Left: -0.06 cm
used in the next exchange. These random keys can
Formatted Table
only be decrypted by devices using the right
network-wide key. A product must have a compatible
key to be installed into the network, or to read data
from devices in that network. This, plus DES and/or
AES security yields a highly secure
solution.Encryption is optional. AES-128, DES, 3-
DES activation upon request
6.1 Wireless AES128 is defined by OMS for transfer of Data via Formatted: Font: (Default) Microsoft
RF-Link as mandatory.AES128 Sans Serif
M-Bus
6.1 ZigBee AES-128 (e.g. CCM*) as specified by IEEE 802.15.4 Sans Serif
@ for the MAC and ZigBee for the network layer
868MHz Sans Serif
6.1 ZigBee There are a number of layers of security in ZigBee. Formatted: Font: (Default) Microsoft
@ Sans Serif, 11 pt, Font color: Auto
2.4GHz a) First, ZigBee encrypts all packets sent at a Formatted: Font: (Default) Microsoft
network level using AES-128 bit encryption and a Sans Serif, 11 pt, Font color: Auto
128-bit Network Key. This is a very robust Formatted: Font color: Auto
encryption mechanism for this type of
Formatted: Left
networking. This network key is established by
Formatted Table
the trust centre when the network is being
formed, and is rolled over periodically. Formatted: Font: (Default) Microsoft
Sans Serif
b) ZigBee also specifies a Trust Centre Link Key,
which is used to encrypt communications with Formatted: Indent: Left: 0 cm
the trust centre. This is different from the Formatted: Font: (Default) Microsoft
network key. Sans Serif
c) Any two nodes in a ZigBee network may request Formatted: Bullets and Numbering
from the trust centre an APS Link Key, which
they can then use to encrypt packets at an
application level. Using this mechanism, two
nodes can send encrypted data through the
mesh network without intermediate nodes being
able to read the payload.
d) ZigBee Smart Energy application profile specifies
the use of ECC (Elliptical Curve Cryptography) to
establish link keys between devices. This is a
best in class mechanism for establishing keys
and includes the use of digital certificates
assigned to the unique IEEE (MAC) address of
each device in the network.
Items (a) and (b) above would be used in any ZigBee

application. (c) and (d) above could be used by GB
smart metering and would be highly recommended.
ZigBee supports using an alternative key
establishment mechanism as (d) instead of ECC.
I think it is clear that ZigBee provides the most
Page 111 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
secure mechanisms available for wireless mesh Formatted: Indent: Left: 0 cm

networks. Formatted: Centered
6.1 Z Wave Z-Wave provides a two tier security solution both Formatted: Font: Not Bold, Font
based on AES128. color: Auto
The Z-WaveSec provides a plug & play functionality
Formatted Table
with in-band key exchange. This solution can be
used for secure non-personal data exchange. Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
The Z-WaveIPTLS is based on the well known IP Formatted: Font: (Default) Microsoft
Sans Serif
TLS technology (used in all internet payment
systems today). This solution should be used for Formatted: Left
secure personal data exchange
6.2 Bluetooth Every connection generates a new session key. Formatted: Font: (Default) Microsoft
Session Key is derived using inputs from both Sans Serif
low
energy devices. Authentication is done against an
encryption root that is 128 bits long.
6.2 Wavenis Wavenis implements a rolling key mechanism based Formatted: Font: (Default) Microsoft
on network, private and random keys. “Checked” Sans Serif
random keys (to eliminate obvious and “easy keys”)
are issued at each data exchange, and modified to
determine the key for the next exchange. Please see
answer for 6.1.Activation upon request
6.2 Wireless Yes, on requestYes Formatted: Font: (Default) Microsoft
Sans Serif
M-Bus
6.2 ZigBee (symmetric) key establishment, maintenance, and Formatted: Font: (Default) Microsoft
transport are specified by ZigBee network layer, Sans Serif
@
868MHz Key generation may be further controlled by APS Formatted: Font: (Default) Microsoft
layer Sans Serif, 11 pt, Font color: Auto
6.2 ZigBee As stated in 6.1 above, rolling network keys are Formatted: Left
@ supported and used by ZigBee. Formatted: Font color: Auto
2.4GHz Formatted: Left
6.2 Z Wave Key renewal is a part of the Z-WaveIPTLS solution Formatted Table
6.3 Bluetooth As recommended, this should be done at the Sans Serif
low application layer, not at the physical layer. Formatted: Indent: Left: 0 cm
energy Formatted: Font: (Default) Microsoft
With protection for each network installation (via Sans Serif
6.3 Wavenis
specific installation keys), as well as every exchange Formatted: Font: (Default) Microsoft
between devices, data is utterly indistinguishable Sans Serif, 11 pt
without the right keys. Unwanted data is Formatted: Font: (Default) Microsoft
ignored.Unique 6-byte MAC address attribution, Sans Serif
Class of Device, and application key exchanges Formatted: Font: (Default) Microsoft
Sans Serif
6.3 Wireless Every transmission of data via RF is encrypted.
M-Bus
Consumption data are transmitted periodically to the
Gateway (MUC). Access to MUC-Data points needs
special access rights. Other data requested direct to
meter needs Authorisation for the command. For
exchange of Commands, asymmetric ECC should
be applied to sign a command. It is intended also to
sign transmitted consumption values by ECC to
support offline tariffs.Yes, by command
Page 112 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
6.3 ZigBee security architecture supports use of link keys to Formatted: Centered
@ secure individual links, already specified by ZigBee Formatted: Font: Not Bold, Font
868MHz color: Auto
Using 6.1 (c) above in conjunction perhaps with (d), Formatted: Indent: Left: 0 cm
6.3 ZigBee
@ every node in the ZigBee network could be assigned Formatted: Indent: Left: -0.06 cm
2.4GHz a different link key to talk to the devices it needs to Formatted Table
talk to. This link key is not known to other devices in Formatted: Font: (Default) Microsoft
the network and so cannot be used to decrypt data Sans Serif, 11 pt, Font color: Auto
except by the destination node for messages. In Formatted
addition, if full ECC is used, each device would have
its own unique digital certificate which can be used
to further secure the communication and identify the Formatted: Left
device uniquely to its target network. So, separating Formatted Table
3 different suppliers in one home is easy. Formatted: Font: (Default) Microsoft
6.3 Z Wave The Z-Wave AEC allows for any mix of secure and Sans Serif
non-secure communication. This allows for very cost Formatted: Indent: Left: 0 cm
effective implementations. The AEC framework
furthermore uses separate security material (keys Sans Serif
and certificates) for individual utility suppliers (also in
the event that a product is hosting/displays two Sans Serif, 11 pt
different utility supplier data)
7.1 Bluetooth Yes. This will increase the costs, but a lot of devices
low use Flash memory for storing program code with
energy upgrades possible. Note: what security scheme do
you need for this? Bluetooth chips typically use 1024 Formatted: Font: (Default) Microsoft
Sans Serif
bit RSA hashes to ensure the authenticity of the new
code before running. Formatted: Font: Not Bold
7.1 Wavenis Over-the-air upgrades can depend on the finished Formatted: Font: 11 pt
radio board. The upcoming SoC supports high- Formatted: Font: Not Bold
volume (automated) field upgrades.
Maintenance upgrades can be conducted on-site by

a person using a PDA (which switches the end-point
to low-range mode, and increases it to fast
transmission mode (up to 100 kbps) in order to keep
battery consumption to the minimum.
In the SoC, a hardware area is reserved for the boot

loader. The stack handles reception of new firmware,
verifies it, and informs boot loader to replace old
firmware with new.Over The Air Programming
available from both PDA or throughout the fixed
network
7.1 Wireless Software update is critical regarding the approval of Formatted: Font: (Default) Microsoft
meter software. If the communication module runs Sans Serif
M-Bus
on another µC it may be easily possible. But typically Formatted: Font: Not Bold
the metering application and communication runs on
the same stack. It has to be certified that a
SsoftwareW-U update will not affect metrological
softwareSW. However it is intended to support the
change of part of the softwareSW in the meter
together with authority in the next step.
Page 113 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
7.1 ZigBee yes, over air update is supported Formatted: Centered

@ Formatted: Font: Not Bold, Font
868MHz color: Auto
Not all ZigBee vendors support over the air upgrades Formatted: Indent: Left: 0 cm
7.1 ZigBee
@ for firmware on the ZigBee node, but the leading Formatted: Indent: Left: -0.06 cm
2.4GHz vendors all do. In most cases there are options for Formatted Table
upgrading the stack and the application and in many Formatted: Font: 11 pt
cases these bootloads can be done remotely and via
multiple hops.
Note that this usually requires a second program to
run on the ZigBee node, to act as a bootloader. Formatted: Font color: Auto
Some other technologies that run on very small Formatted: Left
microcontrollers do not have enough code space to Formatted Table
have a separate bootloader program included.
7.1 Z Wave Standardized Z-Wave firmware upload is available Sans Serif, Not Bold
7.2 Bluetooth As recommended, the security algorithms should be
low specified at the application level, and therefore this Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
energy would be possible.
7.2 Wavenis Security algorithms usually depend on application
requirements. Security is generally addressed on 3 Sans Serif, Not Bold
levels: PHY + MAC layer (Wavenis combines FHSS,
FEC, data interleaving and scrambling) + 11 pt, Not Bold
authentication mechanisms + data encryption
algorithms. Sans Serif
Most sensitive applications require authentication Formatted: Font: Not Bold

with sophisticated random rolling codes Formatted: Font: Microsoft Sans Serif,
(combination of rolling public & private keys) with 11 pt, Not Bold
encryption coding such as DES, 3-DES or AES, or Formatted: Font: 11 pt
other. Formatted: Font: Not Bold
Both enhanced authentication mechanisms and

encryption algorithms can be upgraded via over the Formatted: Font: Microsoft Sans Serif,
11 pt, Not Bold
air programming services as described in 7.1.yes
See Ref. 7.1 Formatted: Font: (Default) Microsoft
7.2 Wireless Sans Serif
M-Bus
7.2 ZigBee security architecture is specified by ZigBee spec., Formatted: Font: Microsoft Sans Serif,
@ any upgrade is subject to ZigBee specification 11 pt, Not Bold
868MHz Formatted: Font: 11 pt
7.2 ZigBee Some ZigBee devices (such as Ember EM250, TI Formatted: Font: Not Bold
@ CC2430) include a hardware encryption engine, Formatted: Font: (Default) Microsoft
2.4GHz which may or may not be used by the firmware, Sans Serif, 11 pt, Font color: Auto
however in any case, all encryption is done at the Formatted: Font: Microsoft Sans Serif,
network layer or above, so is done in software, so if 11 pt, Not Bold
you wanted to change the encryption mechanism Formatted: Left
you could do so by replacing the application
Formatted Table
firmware.
All other modifications to security in the ZigBee stack
or application could of course be made via an over-
Page 114 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
the-air upgrade. Formatted: Indent: Left: 0 cm
7.2 Z Wave Same as item 7.1 Formatted: Centered

color: Auto
7.3 Bluetooth Bluetooth devices shipped today still work with
devices shipped 8 years ago. Formatted: Indent: Left: -0.06 cm
low
energy13 Formatted Table
7.3 Wavenis The most recent Wavenis devices with enhanced Formatted: Font: (Default) Microsoft
features (synchronized network) are backward Sans Serif, 11 pt
compatible with the 1st generation Wavenis with non- Formatted: Font: (Default) Microsoft
synchronized network shipped in 2000.yes Sans Serif
7.3 Wireless M-Bus is carried since 1997. There are active Formatted: Font: (Default) Microsoft
Sans Serif
M-Bus14 Working groups continuing work on this standard.
RF-Solution was released in 2005. The Open Formatted: Font: (Default) Microsoft
Sans Serif
Metering -WGWorking Group selected S-Mode and
T-Mode only (S1m are excluded). The long preamble Formatted: Not Highlight
sequence of S-Mode allows alternating scanning of Formatted: Font: (Default) Microsoft
both channels in time. For a reception unit, both Sans Serif
Modes should be supported. Formatted: Font: (Default) Microsoft
7.3 ZigBee yes, ensured if required, refer to Sans Serif
@ IEEE802.15.4 and ZigBee by defining appropriate Formatted: Font: (Default) Microsoft

868MHz control bits, e.g. “ZigBee Protocol Version” Sans Serif
Subject to a significant change to something like Formatted: Font: (Default) Microsoft

7.3 ZigBee Sans Serif, 11 pt, Font color: Auto
@ security (per 7.2), and any application level changes
which are totally under the control of the developer, Formatted: Left
2.4GHz
ZigBee ensures backward compatibility in its Formatted: Font: Microsoft Sans Serif,
networking stack and application profiles. 11 pt, Not Bold
Formatted: Left
Sometimes criticism is levelled at ZigBee for not Formatted Table
being backward compatible, and certainly between Formatted: Font color: Auto
ZigBee 2004 and ZigBee 2006 there were some
one-off changes made that broke backward Sans Serif
compatibility. However, this decision was not taken
lightly, and at that time there were no commercial
products that had been certified to ZigBee 2004, so it Formatted: Font: (Default) Microsoft
Sans Serif
was OK to make such changes without impacting
any products in the field.
In general, at the point at which some product is

certified to a particular ZigBee standard or
application profile, all future work on that type of
device or that profile, must be backwards
compatible. Formatted: Font: (Default) Microsoft
All Z-Wave products to date are backward compliant. Sans Serif, 11 pt
7.3 Z Wave
This has been proved through 4 software and ASIC Formatted: Font: (Default) Microsoft
generations. Sans Serif
7.4 Bluetooth 2.4 GHz will be around for a long time. It is of no use Formatted: Font: (Default) Microsoft
for long range communications due to the problems Sans Serif
low
Formatted: Left
13
Whilst the proven principles of the Bluetooth SIG support backwards compatibility, the
introduction of low energy will break this – i.e. existing devices will not interoperate with ‘low
energy only’ devices Formatted: English (United Kingdom)
14
The group expressed concerns that there are compatibility issues within the M-Bus
standard – ‘S’ and ‘T’ types do not interoperate Formatted: English (United Kingdom)
Page 115 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
energy with propagation through water (clouds, mist, fog). Formatted: Indent: Left: 0 cm
Bluetooth is robust against all the interferers within Formatted: Centered
this band, including non-standards based solutions Formatted: Font: Not Bold, Font
like X10 video transmitters color: Auto
7.4 Wavenis Wavenis uses 868 MHz in Europe. Will adapt to Formatted: Indent: Left: -0.06 cm
extension of this band (as being suggested by
Formatted Table
European standardisation bodies) as required
(extension is 863-873MHz)Guaranteed. European Formatted: Font: (Default) Microsoft
Sans Serif
bodies for SRD is going to extend the 868MHz band
7.4 Wireless 868MHz band is carried by many industries, which Formatted: Font: (Default) Microsoft
take care about this Band. Frequency Management Sans Serif
M-Bus
Working group continues maintenance of this
band.868MHz
7.4 ZigBee 868 MHz band dedicated to ISM usage, potential to Formatted: Font: (Default) Microsoft
be expanded Sans Serif, 11 pt, Font color: Auto
@
868MHz
7.4 ZigBee It is difficult to comment on this, as it is always an Formatted: Font color: Auto
@ unknown. However, 2.4GHz has established itself Formatted: Left
2.4GHz with a number of technologies and so should be
Formatted Table
available as an unlicensed band into the future.
Given the support for ZigBee 2.4GHz by silicon Formatted: Font: (Default) Microsoft
Sans Serif
vendors, major electronics manufacturers etc., it
would appear that the frequency is here to stay. If Formatted: Indent: Left: 0 cm
anything, as WiFi moves up to 5GHz, the frequency Formatted: Font: (Default) Microsoft
may prove more popular for wireless sensor Sans Serif
networks over time. Formatted: Font: (Default) Microsoft

The 868MHz band has been adopted by all CEPT Sans Serif, 11 pt
7.4 Z Wave
countries Formatted: Font: (Default) Microsoft
Sans Serif
7.5 Bluetooth Bluetooth has shipped 2.5 billion devices, and is still
low growing its volume. A market that requires this many Sans Serif
energy chips will not disappear overnight. No other
technology will take its place in phones, as the
number of radios in a phone is constrained, and
Bluetooth is already in there.
7.5 Wavenis Latest generation of Wavenis-based battery- Formatted: Font: (Default) Microsoft
operated metering solutions features 20 years Sans Serif
autonomy with legal commitment. Formatted: Font: 11 pt
The Wavenis-OSA creates all the conditions to Formatted: Left
ensure longevity of the technology itself.Latest
generation of Wavenis-based battery-operated
metering solutions features 20 years autonomy with
legal commitment.
The Wavenis-OSA offers all the conditions for
longevity of the technology
7.5 Wireless Single Transceiver applied . (no special chipset Formatted: Font: (Default) Microsoft
required). Technology is available as long as Sans Serif
M-Bus
Frequency band will be available.Single Tranceiver Formatted: Font: (Default) Microsoft
applied. (no special chipset required) Sans Serif
7.5 ZigBee Yes Formatted: Font: (Default) Microsoft

Sans Serif
@
868MHz
Page 116 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
7.5 ZigBee Again, given the support for ZigBee by silicon Formatted: Indent: Left: 0 cm
@ vendors, meter manufacturers and others, it is clear Formatted: Centered
2.4GHz that ZigBee is around for the long haul. The ability to Formatted: Font: Not Bold, Font
upgrade over the air means that it would be possible color: Auto
to add new features to applications and maybe even Formatted: Indent: Left: -0.06 cm
to the stack if necessary, and so keep the devices in
Formatted Table
the field up to date with the latest innovations (if that
was desirable, depends on upgrade strategy). Formatted: Font color: Auto
Formatted: Left
ZigBee offers very strong security, and more Formatted Table
bandwidth than is needed for smart metering, so it Formatted: Font: (Default) Microsoft
can survive future requirements. Sans Serif
Even if ZigBee were to disappear (and that is most
unlikely), or if another more suitable IEEE 802.15.4-
Sans Serif
based technology were to emerge in future years
(also unlikely), all of the ZigBee chipsets are IEEE
802.15.4 compliant, and most can be upgraded over-
the-air, so it would be possible to upgrade from
ZigBee to some other wireless networking stack at
that point. Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
7.5 Z Wave
Sans Serif
8.1 Bluetooth Electricity meter: <$2
low Gas / Water: <$1 Sans Serif
energy Display unit: $0 (it comes for free with mobile
Formatted: Left
phone!!!)
Display Unit: <$2.
Costs of batteries not considered.

8.1 Wavenis It is important to consider the finished solution, not Formatted: Font: (Default) Microsoft
just the chipset price. For example, per unit sales Sans Serif
price for a Wavenis metering end-point: PCB +
CPU/RF/memory, mounted and tested + battery +
antenna + sensor connection : <€10 EUR for 100k
units Formatted: Font: 11 pt
Home display Unit : around €30 euros Formatted: Font: 11 pt
8.1 Wireless RF-Chip 1,40 $ (@10k today)
M-Bus RF-Module 2,00 $ (w/o battery + µC) Sans Serif
Battery (RF-only) 0,5Ah
Battery (Gas meter incl. valve) 2,5 Ah= ca. 3,00 € Sans Serif
(@10k today)e.g. 3xCC1101+2 Ah Lithium (Gas) +
home display (energy) Sans Serif
8.1 ZigBee price competitive to ZigBee 2.4GHz and also other
@ 868 MHz implementations Sans Serif, 11 pt, Font color: Auto
868MHz Formatted: Font color: Auto
8.1 ZigBee This is difficult for a vendor to answer, as the cost to Formatted: Left
@ the utility includes much more than just some ZigBee
Formatted Table
2.4GHz chips, there is a lot of value add by module
manufacturers, meter manufacturers etc. Formatted: Font: (Default) Microsoft
Sans Serif
However if we look only at chip costs, then across Formatted: Indent: Left: 0 cm
the multiple vendors; Formatted: Font: (Default) Microsoft
Sans Serif
Page 117 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08

a) For 1 million of units, ZigBee chipsets today cost Formatted: Centered
typically between about $2.50 and $3.00. Formatted: Font: Not Bold, Font
b) ZigBee modules including PA to +10dBm, with color: Auto
FCC and CE approval, in million unit quantities Formatted Table
can be obtained for between $7-$10.
We expect the chip prices to come down to about
$1.50-$2.00 by 2012, and module prices by then to Formatted: Bullets and Numbering
be <$5. Formatted: Font: (Default) Microsoft
• $2.00-3.00 for SoC in high volumes Sans Serif, 11 pt
8.1 Z Wave
• $3.00-4.00 for complete module in high volumes Formatted: Font: (Default) Microsoft
Sans Serif
• Lowest cost in the market, thanks to
Compact FSK technology Formatted: Font: 11 pt
Compact protocol stack sizes Formatted: Bullets and Numbering
• Modern single chip implementation in either Formatted: Body Bullets,
180nm or 130 nm CMOS Widow/Orphan control, Adjust space
between Latin and Asian text, Adjust
• Sustainable cost benefit due to much higher space between Asian text and numbers
complexity of competitors
8.2 Bluetooth No known failures of Bluetooth devices in the field Formatted: Font: (Default) Microsoft
due to Bluetooth chip recorded in last 8 years. Sans Serif
low
energy
8.2 Wavenis Of the 2.5 million units deployed at this time, only Formatted: Font: (Default) Microsoft
0.02% of finished products have been returned for Sans Serif
post-sales service. No separate figure on chipset
failure is available.0,02 % (2,5Mu deployed)
8.2 Wireless Depending on chip solution. Our experience of Chip Formatted: Font: (Default) Microsoft
error rate is <0,005% per year. Sans Serif
M-Bus
8.2 ZigBee depends on final system solution which is not under Formatted: Font: (Default) Microsoft
control of Chip providers, Radio/MCU IC’s are Sans Serif
@
868MHz proven for MTBF >>10 years Formatted: Font: (Default) Microsoft
8.2 ZigBee This is another metric that needs to be assessed on
@ a vendor by vendor basis, however most ZigBee Sans Serif, 11 pt, Font color: Auto
2.4GHz chipsets should be up to the requirements. Most
chips are on well proven processes and
manufactured in reputable fabrication plants such as Formatted: Left
TSMC in Taiwan, probably use mostly the same Formatted Table
flash and RAM components, so for the most part Formatted: Font: (Default) Microsoft
they will deliver similar levels of reliability. Sans Serif
MTBF and other calculations of this nature are done
using HTOL testing on samples of devices over Sans Serif
1000’s of hours at higher temperatures (usually 125
degrees C) than the devices are normally used, to
simulate longer term usage. Using this technique,
even recently released chipsets can have a very
high calculated MTBF from relatively short test
periods, and the confidence level for that value
increases as more testing is done over time. For
example based on this type of testing,
EM2420/CC2420 has a minimum expected life of 10
years at 58 degrees C. Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
Page 118 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
8.2 Z Wave Chip < 90FIT Formatted: Indent: Left: 0 cm

Formatted: Centered
9.1 Bluetooth Formatted: Font: Not Bold, Font

color: Auto
low
energy Formatted Table
Wavenis was first deployed as a wireless solution for Formatted: Indent: Left: -0.06 cm
9.1 Wavenis
walk-by metering, and has been used in smart Formatted
metering systems (with remote 2-way access, Formatted: Font: (Default) Microsoft
programmable bubble-up, alerts, etc.) for the past Sans Serif
several years in places such as China (China Gas) Formatted: Font: (Default) Microsoft
France (Les Sables d’Olonnes, Paris) Spain, Sans Serif
Slovenia, and North America (CA). Some of these Formatted: Font: (Default) Microsoft
networks also include wireless in-home displays for Sans Serif
consumers.China Gas, Les Sables d’Olonnes Formatted: Font: 11 pt
France, NA - California, Paris, Spain, Slovenia Formatted: Left
9.1 Wireless Applied since 2004 for several million Formatted: Font: (Default) Microsoft
meters.Applied since 2004 Sans Serif
M-Bus
9.1 ZigBee yes, IEEE802.15.4 / ZigBee are developed to be Sans Serif
@ used e.g. in metering applications, application
868MHz profiles are especially designed for meter Sans Serif
applications
9.1 ZigBee ZigBee has been selected for use in smart metering Sans Serif, 11 pt, Font color: Auto
@ deployments in Texas, California, Virginia and
2.4GHz Detroit in the US, Victoria in Australia, and
Gothenburg, Sweden. It has also been used in Formatted: Left
successful trials in Spain, as well as being included Formatted Table
in the recent EDRP trials in the UK by some of the Formatted: Font: (Default) Microsoft
ERA members. Sans Serif
Gothenburg has now got about 60,000 meters live, Formatted: Font: (Default) Microsoft
expecting to complete roll-out to 270,000 meters by Sans Serif
the end of 2008. Other large trials and deployments
in the US have already been documented in this
forum (see my presentation of 2nd Sept).
In the UK, PRI already uses ZigBee in its

prepayment meters. Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
9.1 Z Wave • 2500 home trial in UK.
• Installed in 1000+ smart metering application by
Sans Serif
Modstroem in Denmark.
• Used in sub-metering and Energy Conservation
applications by DEST in Denmark along with Formatted: Bullets and Numbering
many OEM partners Formatted: Body Bullets,
Industrial automation markets are very similar in Widow/Orphan control, Adjust space
9.2 Bluetooth between Latin and Asian text, Adjust
low requirements (environmental / robustness / security / space between Asian text and numbers
energy range)
9.2 Wavenis Over 2 million Wavenis smart metering solutions are Sans Serif
up and running today. Other applications include Formatted: English (United Kingdom)
home Automation (door lock,alarmlock, alarm, Formatted: Normal, Widow/Orphan
lighting, temp control), Industrial Automation, control, Adjust space between Latin
environment, medical, Track & trace (active long and Asian text, Adjust space between
Asian text and numbers
Page 119 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
range UHF RFID) and in-home displays.Home Formatted: Centered

Automation (door lock ,alarm, lighting, temp control), Formatted: Font: Not Bold, Font
Industrial Automation, environment, medical, Track & color: Auto
trace (active long range UHF RFID) Formatted: Indent: Left: 0 cm
9.2 Wireless Same RF-Interface applied in Home automation Formatted: Indent: Left: -0.06 cm
M-Bus (Konnex)Konnex
Formatted Table
9.2 ZigBee yes, IEEE802.15.4 / ZigBee are developed to be Formatted: Font: 11 pt
@ used e.g. in metering applications, application
868MHz profiles are especially designed for meter
applications Formatted: Font: (Default) Microsoft
Sans Serif
9.2 ZigBee ZigBee is used in a wide variety of applications
including some that are very similar to the sort of Formatted: Font: (Default) Microsoft
@ Sans Serif, 11 pt, Font color: Auto
2.4GHz networking needed for smart metering; some
examples of the variety of applications include; Formatted: Font color: Auto
marine safety (see Formatted: Left

http://www.raymarine.co.uk/products/lifetag/), Formatted Table
industrial ball valve control (see www.eltav.com), Formatted: Font: (Default) Microsoft
home security (see www.alertme.com), energy Sans Serif
monitoring / management (see www.plugwise.com), Formatted: Font: (Default) Microsoft
home automation (see www.control4.com), Sans Serif
commercial building automation (see www.tac.com) Formatted: Indent: Left: 0 cm
and fire and safety (see www.byterg.ru).
Formatted: Font color: Blue
Some of these applications are similar to GB smart Formatted: Font color: Blue
metering requirements, but even where they are not, Formatted: Font color: Blue
the sort of networking involved is fairly typical of Formatted: Font color: Blue
networks in UK homes or in AMR/AMM solutions.
9.2 Z Wave Focus on home control / Unified Home Control is a
major strength
9.3 Bluetooth Bluetooth is stable – new specification release in
low 2009 that covers low energy requirements. Sans Serif, 11 pt
energy
9.3 Wavenis New revisions offer a superset of previous versions, Sans Serif
thus providing backward compatibility over time. Formatted: Font: 11 pt
Latest major revision (2008) now being deployed in
Europe.Slight upgrades with backward compatibility Widow/Orphan control, Adjust space
9.3 Wireless Revision next 2 years! Thereafter stable for next 5 between Latin and Asian text, Adjust
yearsRevision now! Thereafter stable for >5 years space between Asian text and numbers
M-Bus
9.3 ZigBee IEEE802.15.4 / ZigBee specification are permanent Sans Serif
@ under control and development, e.g. specific
868MHz application profiles to optimize to customers needs, Sans Serif
refer to ZigBee Alliance
9.3 ZigBee There are no planned upgrades to the ZigBee Sans Serif, 11 pt, Font color: Auto
@ networking standard in the next 2 years, and beyond
Formatted: Left
2.4GHz that, none that GB smart metering would require out
of necessity. Formatted: Font color: Auto
Formatted: Left
The ZigBee Smart Energy Application Profile will be Formatted Table
updated later this year to include feedback from field
deployments in the US and new requirements from Sans Serif
Australia. It is anticipated that GB smart metering
would also have some amendments and would
Formatted ... [1]
Page 120 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
make sure that the ZigBee Smart Energy spec is Formatted: Indent: Left: 0 cm
sufficient for needs before deploying, so therefore no Formatted: Centered
requirement for upgrades for ZigBee specification Formatted: Font: Not Bold, Font
reasons after that, unless the UK specifies them. color: Auto
9.3 Z Wave Very high maturity of chip and protocol Formatted: Indent: Left: -0.06 cm
Used in over 300 products – Available for
Formatted Table
more than six years
Proven for interoperability and backward Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
compatibility
4th generation system-on-chip solutions Formatted: Font: (Default) Microsoft
Sans Serif
and 5th generation software
Bluetooth market is 1 billion a year in 2008. Adding Formatted: Font: 11 pt
9.4 Bluetooth
low another ten’s of millions to this will be easy to Formatted: Bullets and Numbering
energy achieve. Formatted: Body Bullets, Bulleted +
Level: 3 + Aligned at: 0.98 cm + Tab
9.4 Wavenis Multiple chip vendors, multiple providers after: 1.61 cm + Indent at: 1.61 cm,
(manufacturers/integrators) of metering Widow/Orphan control, Adjust space
solutions.Multi-chip vendors, multi-sourcing wireless between Latin and Asian text, Adjust
solutions providers challenged to meet market space between Asian text and numbers
demand. Formatted: Font: (Default) Microsoft

Sans Serif
9.4 Wireless Many manufacturers have basic solution now. They
M-Bus have to adapt new features (e.g. Replace DES by Formatted: Font: (Default) Microsoft
Sans Serif
AES)
9.4 ZigBee final system / meter not under control of Chip Formatted: Font: (Default) Microsoft
providers Sans Serif, 11 pt, Font color: Auto
@
868MHz
9.4 ZigBee Most of the ZigBee vendors are seasoned silicon Formatted: Font color: Auto
@ manufacturers, and already producing chip volumes Formatted: Left
2.4GHz well in excess of those required for the UK smart
Formatted Table
metering rollout. Others are fab-less and use very
large and reputable fabs like TSMC and IBM, where Formatted: Font: (Default) Microsoft
Sans Serif
capacity is certainly not an issue.
It is anticipated that each individual ZigBee vendor Formatted: Font: (Default) Microsoft
would have to satisfy this requirement as part of any Sans Serif
tendering process. Formatted: Font: (Default) Microsoft

Zensys is direct partner with TSMC and ASE Sans Serif, 11 pt
9.4 Z Wave
allowing for very high volumes Formatted: Font: (Default) Microsoft
2nd source silicon in 2009 Sans Serif
9.5 Bluetooth Phones are the remote control – pushing information Formatted: Font: (Default) Microsoft
from meters to phones is essential to get people to Sans Serif
low
energy see their usage on a daily, hourly or instantaneous
basis. Televisions already have Bluetooth in, as do
computers and similar consumer electronic devices.
Anything that has a display will probably also have
Bluetooth, and will want to display this information.
9.5 Wavenis Home display devices, thermostats, lighting control Formatted: Font: (Default) Microsoft
systems already on the market.Home display Sans Serif
devices, thermostats already in use
9.5 Wireless Wireless M-Bus is part of Konnex (Home Formatted: Font: (Default) Microsoft
automation). Sans Serif
M-Bus
Home display, thermostats etc. available in Formatted: Left
Konnex.Same Radio Interface as Konnex (Home Formatted: Font: (Default) Microsoft
automation) Sans Serif
Page 121 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Needs Software adoption! Formatted: Centered
9.5 ZigBee other services (thermostats, displays, controls, etc.) Formatted: Font: Not Bold, Font
@ are simple to integrate into a ZigBee network color: Auto
868MHz Formatted: Indent: Left: 0 cm
9.5 ZigBee Many ZigBee Smart Energy products and ZigBee Formatted: Indent: Left: -0.06 cm
@ (non-SE) products on the market today to satisfy the Formatted Table
2.4GHz requirements of ZigBee deployments in the UK; Formatted: Font: (Default) Microsoft
Sans Serif
Meters: e.g. Itron/Actaris, Elster, Landis+Gyr, PRI, Formatted: Font: (Default) Microsoft
GE/Nuri etc. Sans Serif, 11 pt, Font color: Auto
In-home displays: e.g. PRI, Tendril, Control4, many Formatted: Font: (Default) Microsoft
others coming Sans Serif, 11 pt, Font color: Auto
Thermostats: e.g. Comverge, Computime, Golden Formatted
Power (RiteTemp).
Smartplugs: e.g. Plugwise, Alertme, Tendril, others
coming… Formatted: Left
9.5 Z Wave Very strong - Z-Wave Alliance with more than170 Formatted Table
members and 300 products Formatted: Font: (Default) Microsoft
Sans Serif
Table 2020 Evaluation Notes
Sans Serif
10.6Last Mile Evaluation Formatted: Indent: Left: 0 cm
Whilst not part of the core considerations and requirements for the Local Formatted: Font: (Default) Microsoft
Communications Development Group, the potential role that low power radio Sans Serif, 11 pt
technology could play in supporting WAN communications is an important Formatted: Font: (Default) Microsoft
consideration for the overall smart metering project. Sans Serif
The scoring for these specific criteria does not form part of the overall Formatted: Font: (Default) Microsoft
Sans Serif, 11 pt
evaluation results, but are recorded here to support any ongoing WAN
communications developments. Formatted: Style Caption + Centered
10.6.1Last Mile Criteria Formatted: Bullets and Numbering
Ref Criteria Relevance/Importance Formatted Table

LM1 Support for Last Mile (Y/N/possibly)
Performance
LM2 Nodes per concentrator
LM3 Typical Signal Propagation – average
(urban/suburban/rural)
Cost
LM4 Cost of data concentrator equipment
Maturity
LM5 Use in other smart metering deployments for
last mile connectivity
LM6 Range of ‘upstream’ WAN physical media Formatted: Keep with next
supported by data concentrators
Table 21 Last Mile Evaluation Criteria Formatted: Style Caption + Centered
10.6.2Last Mile Evaluation Scorecard
Ref Criteria Bluetooth M-Bus Wavenis ZigBee ZigBee Z-
Low @ @ Wave
Page 122 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Ref Criteria Bluetooth M-Bus Wavenis ZigBee ZigBee Z-

Low @ @ Wave
LM1 Support for Last Mile
LM2 Nodes per

concentrator
LM3 Typical Signal
Propagation – average
(urban/suburban/rural)
LM4 Cost of data
concentrator
equipment
LM5 Use in other smart
for last mile
connectivity
LM6 Range of ‘upstream’ Formatted: Keep with next
WAN physical media
supported by data
concentrators
Table 22 Last Mile Evaluation Scorecard Formatted: Style Caption + Centered
10.5.3Last Mile Evaluation Notes
Ref Solution Score Notes/Explanation
e.g. Solution X 0 Not currently used for Last Mile WAN activity

Table 23 Last Mile Evaluation Notes Formatted: Style Caption + Centered
10.7Evaluation Results
Criteria Types Bluetooth M-Bus Wavenis ZigBee ZigBee Z-
Low @ @ Wave
Fit With Requirements
Interoperability
Power
Data Performance
Radio Performance
Security
Future Resistance
Cost
Maturity
Page 123 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Must Have Criteria
Desirable – 3
Desirable – 2
Desirable – 1
Total Score
10.8Evaluation Issues Table

The table below shows issues and risks identified during the evaluation
process.
Ref Solution Criteria Issue/Risk
e.g. Solution X 10 No evidence of chipsets from different vendors
working correctly together
10.910.5 Evaluation Scenarios

As part of the Local Communications Development activity, it has been
suggested that further evaluation of the solution technologies could be
undertaken using ‘Use Case Scenarios’ for initial field testing.
Each of the solutions could be tested against a small number of ‘real world’
scenarios for performance when delivering typical smart metering activities:
- smart meter to smart meter data exchange
- smart meter to in home display data exchange
- smart meter to Local Device (e.g. smart thermostat, microgeneration
unit) data exchange
When considering interference, this would be the existing level of wireless

activity – average could constitute WiFi + DECT + 2 Cellular Phones, harsh
could include proximity to a TETRA radioetra pad.
An example of this approach is shown below

Premise Size: 3 Bedroom, 3 Reception, Domestic Semi-Detached House, 100sqm
Level Wall Type Meter Locations Interference
One Brick External, adjacent Average
Two Foil Insulated External, remote Average
Three Internal, adjacent Average
Four High
Five Harsh Formatted: Keep with next
Table 2124 Evaluation Scenario Suggestions Formatted: Style Caption + Centered
Page 124 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
11 Recommendations
[Note: this is an initial draft and it is anticipated that the meeting on the 29th Formatted: Superscript
October will result in a number of updates]
Primarily, it should be noted that all participants in the group and the
preparation of this report have been positive about the contribution the
process has made to their understanding of the subject, requirements and
options. The ERA and the SRSM project team are grateful to all participants
for their contributions and the spirit of co-operation throughout the process.
The solution ‘providers’ within the group certainly understand more about the
particular requirements of potential customers in energy metering and related
devices, and those customers are equally more aware of the options and
opportunities these solutions present.
The process has moved all participants forward to a point where the
requirements and solutions are converging. It is clear from the work of the
group that it is possible for the requirements for Local Communications for
smart metering to be met by technologies available today.
Although necessarily a ‘desktop’ exercise, progress has been made in

identifying and agreeing principles and requirements, potential solutions and
related considerations. This should provide a solid foundation for any
subsequent work in this area, and it is particularly evident that every one of the
solution options, as an interoperable low power radio, could be capable of
delivering a Local Communications standard for smart metering in Britain.
The group recommends that its’ work be continued in a timely manner, under
whatever framework is determined to deliver smart metering, in order to make
use of the wealth of information contained within this report.
Given suitable authority and resources, a solution for Local Communications

should be chosen as soon as can be done with the correct level of confidence.
Participants in the potential smart metering and smart energy markets are
waiting for a definitive answer to support the development of new products.
A great deal of the supporting information required to support the selection of

a solution is contained in this report.
Chief amongst the recommendations would be to continue the evaluation

process by undertaking the test and review process detailed in section 11.1
below. The desktop evaluation exercise has gathered a great deal of valuable
information that should form a solid foundation to refine the evaluation criteria
to allow the key differences between solutions to be identified and assessed.
The process has been successful in creating a network of interested

stakeholders, and has, by being a public exercise, attracted a wider audience,
including international participants. The group would recommend that any
further work be similarly ‘open’ in conducting proceedings, with suitable
Page 125 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
arrangements for ‘blind’ testing and recognising the sensitivities associated

with the suggested panel review process.[Placeholder for recommendation of
the group. Will include any relevant notes, issues or comments as required by
the group]
[At the 2nd September meeting it was agreed that the recommendation should
include a clear recommendation for field testing of solutions in typical British
installations. Clarity relating to suggesting the ‘Who’, ‘How’ and ‘When’ for this
testing may be agreed at subsequent meetings]
It has been evident that more work is required to understand and document
detailed user requirements for Local Communications for smart metering. This
will be a challenging activity, as this is a new area for energy retailers and
meter manufacturers, particularly within an ‘interoperable’ environment as
required for smart metering. This does not need to be a very detailed piece of
work, but clarifying some of the potentially ambiguous areas would be
beneficial:
• Local Communications operating as a proxy/link for WAN Communications Formatted: Body Bullets
activities – for the Last Mile or for a Meter Operator HHU
• Duty cycles for gas meters for display information. Understanding how
often a battery based device is required to transmit data will assist with
understanding the potential battery costs
When commencing this exercise in January 2008, it was envisaged that some
guidance on the market model for smart metering in GB would have been
forthcoming, which could have clarified the possibility of low power radios
being utilised as part of the WAN Communications infrastructure for smart
metering. Throughout, this ‘Last Mile’ potential has therefore been kept slightly
separated from the Local Communications Group activity looking at supporting
interactions within a home, as it could have been rendered redundant under
particular market models.
At the time of preparing this recommendation, the market model discussions

continue. Therefore, the materials that have been prepared for Last Mile
consideration have been moved to an appendix of this document, with a
recommendation that they be considered in the event of a market model
decision that could accommodate the use of a single radio in smart meters to
talk to the home, and to remote parties.
Finally, any subsequent evaluation exercise on this subject needs to

recognise the publication date of this report and the fast pace of development
in this area. The longer this report sits on the shelf, the greater risk that things
could have moved forwards significantly. The solutions themselves, or the
evaluation criteria could change materially, for example the potential to use
Local Communications solutions for Last Mile.
Formatted: Heading 2
11.1 Testing & Evaluating Criteria

The table below shows how the Local Communications Development Group
recommends evaluation and testing of the individual criteria.
Page 126 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Three ‘broad’ types of evaluation are considered:

• Field test; use of the Local Communications solutions in a metering context
in typical metering environments, preferably using actual metering
products. The tests should be designed by experts familiar with both radio
communications issues and metering, and should take the form of ‘real
world’ tests
• Laboratory test; formal scientific testing under laboratory conditions to be
undertaken by an independent body.
• Panel review; a number of criteria are linked to strategic developments,
commercial arrangements and other parameters that cannot be effectively
measured using field or laboratory testing. In these instances it is
recommended that a representative panel be formed from interested
stakeholders who are not necessarily radio communications experts, who
would conduct a series of one-to-one reviews with representatives of the
Local Communications solutions.
In all cases these activities should be undertaken by participants independent

from the solutions being evaluated. The group has discussed the potential to
engage with academic institutions to support the field and laboratory testing.
These tests are not, as shown, intended to be necessarily exclusive – criteria

could be the subject of field testing and a panel review
Wherever relevant, additional information from the group has been added as
footnotes to this table.
Ref Criteria Field Lab Test Panel Not
Test Review tested
1.1 Low level of energy customer Y
intervention/support required to
maintain communications
1.2 Ease of installation – i.e. Y
discovery at meter installation
1.3 Minimise number of site visits to Y Y
address local communications
issues – i.e. recovery or remote
correction on failure/upgrade
failure – will include MTBF and
power consumption on meter
1.4 Development tools to support Y
smart metering and smart energy
market
1.5 Ease of integration into Y
metering/home products – e.g.
system on chip, antenna size
1.6 Scope/receptiveness to Y
accommodate specific GB smart
metering requirements
2.1 Status as an Open Standard – Y
accessibility, defined standards,
range of participants, proven
Page 127 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08

Test Review tested
2.2 Support for choice of data Y
exchange format
2.3 Genuine choice and competition
2.4 Interoperable chipsets Y Y
2.5 Effort required to update Y
standards to meet specific GB
requirements (less effort = higher
score)
2.6 No. of nodes supported for each Y Y
HAN, assuming minimum
capability of 3.
3.1 Consumption/Peak Y Y
Management15
3.2 Support for battery powered Y Y
nodes, but also for energy smart
metering application (e.g. data
refreshes in minutes rather than
hours/days for end nodes)
4.1 Transmission speed – effective Y Y
data throughput in kbps per
channel16
4.2 Robustness (retry mechanisms, Y Y
acknowledgements, minimised/nil
message loss – i.e. latency and
dropped packets)
5.1 Typical range (amplified or non- Y Y
amplified)17
5.2 Suitability for GB meter locations Y Y
(consider internal/external,
stone/concrete, metal meter
cabinets, meter rooms etc.)
5.3 Vulnerability to signal Y Y
interference18
15
Will need to understand the power consumption in sleep mode for lab
testing, or, alternatively - milliwatt for range achieved
16
Notes on testing 4.1:
- faster isn’t necessarily better, throughput/”speed” depends on Formatted: Bullets and Numbering
usage/range
- throughput will vary by network configuration, testing should be
comparative (point to point) using a standard 1kbit package over a fixed
range (30, 50, 100m) Formatted: English (United Kingdom)
17 Formatted: Font: 12 pt
Range will depend on power used/specific chipsets, antenna design etc.
Could test for penetration rather than, or as well as, range? Formatted: Font: 12 pt
Standard tests could include Received Signal Strength Indicator (RSSI), Formatted: English (United Kingdom)
Packet Error Rate (PER) Formatted: Font: 12 pt
18
the ‘interfering’ devices should be defined Formatted: English (United Kingdom)
Page 128 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08

Test Review tested
5.4 Ability to cope with signal Y Y
interference
5.5 Blocking Immunity in Y
transceiver19
6.1 Strength/resilience of methods Y Y
used
6.2 Ability to use rolling/successive Y Y
keys
6.3 Support for distinguishing Y Y Y
public/private data, and for
keeping gas/water/electricity data
independently secure – i.e.
supports 3 different suppliers for
3 utilities (and any other
authorised party data secure)
7.1 Support for “over the air” Y Y
upgrades of ‘smart meter’ nodes
– i.e. gas + electricity meters & in
home display
7.2 Support for security upgrades Y Y
7.3 Support for backwards Y Y
compatibility
7.4 Longevity of frequency Y
7.5 Longevity of solution technology Y
(minimum expected smart meter
asset life of 10-15 years)
8.1 Total cost per home – 1 x Y
electricity meter, 1 x gas meter
with battery, 1 x home display
unit = 3 chipsets + additional
battery cost
8.2 Mean Time Between Y Y
9.1 Use in equivalent smart metering Y
deployments
9.2 Use in analogous applications Y
9.3 Expectation of ongoing required Y
upgrades – i.e. v2009, v2011
(fewer = higher score?)
9.4 Capacity in vendors to meet Y
smart metering demands (meters
plus displays and other devices)
– assume 5 year deployment to
25 million homes
9.5 Availability of non-metering Y
products that could be relevant to
smart metering – e.g.
thermostats, display devices
19
Will be very much silicon vendor specific, lab test/field test should include
increasingly common problem causing equipment, such as RFID readers
Page 129 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Table 22 Evaluation Testing Recommendations Formatted: Style Caption + Centered
Testing 3.1
need to understand the power consumption in sleep mode for lab testing
or milliwatt for range achieved
11.2 Solution Summary Statements

As part of the development of this report and these recommendations, it was
felt that it would be beneficial to provide an independent view from the SRSM
project team on each of the Local Communications solutions under
consideration.
These statements are intended to reflect a general view of each of the

solutions, with particular regard for the current suitability for consideration for
use in the potential GB smart metering market.
In no way do these statements constitute recommendations or statements of

intent by the group or ERA members.
11.2.1 Bluetooth low energy

Bluetooth low energy has been a different consideration for the group from the
other solutions. Bluetooth is obviously a global success and the opportunity to
include smart metering in such an extensive and established eco-system of
interoperable devices is very intriguing.
However, it has appeared that Bluetooth low energy is still some way from
being available to test – Q1 2009 has yet to be confirmed. Further doubts have
been raised by a number of participants in the group as to the actual
performance characteristics and power consumption, and therefore suitability
for consideration for smart metering. These doubts can only be addressed by
testing actual products.
11.2.2 Wavenis
Wavenis is a successful solution for metering already, particularly for the Last
Mile, with a strong evidence base of installed European utility meters. From
the desktop exercise and the group meetings, it looks to be a very technically
accomplished radio solution, offering range and security at low power.
The newly established Wavenis OSA is also a positive move towards open
standards and interoperability, but this is quite a recent development. It is also
the case that Wavenis does not currently have a smart meter specific ‘profile’
similar to ZigBee Smart Energy, preferring to let customers develop specific
applications using the Wavenis radio. This is not a ‘good fit’ with the principles
for GB smart metering, where adoption is preferred to development.
Further, it has not been apparent that there is an established market of

peripheral Local Devices, such as a range of home display units or
thermostats, as you can find with some of the other technologies.
Page 130 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
11.2.3 Wireless MBus

The MBus solution offers a number of key positives;
- it is the preferred solution in a number of large European markets Formatted: Bulleted + Level: 1 +
Aligned at: 0.63 cm + Tab after: 1.27
- it is also closely tied to key European solutions, such as DLMS, KNX cm + Indent at: 1.27 cm
etc.
- it is an international standard, and there are metering and related
products available now from EU meter manufacturers
However, there are a number of points to consider;
- it is not well understood by the majority GB energy participants with an Formatted: Bulleted + Level: 1 +
Aligned at: 0.63 cm + Tab after: 1.27
interest in smart metering cm + Indent at: 1.27 cm
- the interoperability with KNX devices is not clear, as this may prove to
be a significant positive if an existing European market of potential
Local Devices would be available for use in Great Britain
- it is going through a key development cycle, and the objective/potential
outcome of this activity is also unclear
Each of these points can, and should be addressed in order to ensure that
MBus is considered equitably with the other solutions.
11.2.4 ZigBee @ 868MHz
ZigBee @868MHz appears to offer the potential for the ‘best of both worlds’ –
operating at what has generally been perceived to be the quieter and more
‘meter-appropriate’ ISM frequency, whilst also benefitting from the extensive
work of the ZigBee Alliance to develop smart metering products.
However, getting representation for this option has been challenging, and
there does not appear to be support across a number of semi conductor
manufacturers. Whilst products are now starting to appear, these are not
generally tied directly to smart metering, and do not currently offer the ZigBee
Smart Energy profile, which is of key interest to the group.
11.2.5 ZigBee @ 2.4GHz

ZigBee @2.4GHz has been in a strong position throughout – it offers context
specific products, has an established interoperability regime and existing
metering solutions. The ZigBee Alliance is also developing the product in key
areas of interest to smart metering; the work with HomePlug and DLMS are
good examples of strategic activities that can only be viewed as positive.
Adoption by major utilities in North America and Australia is also very

encouraging.
ZigBee @2.4GHz, however, must be successful in field trials and testing, as

challenges relating to range/power consumption and interference at the
2.4GHz frequency continue to be raised. It is also the case that whilst it has
been successful in other territories, there has been no significant adoption for
utility metering in Europe.
11.2.6 Z Wave
The progress by the Z Wave Alliance towards a realistic smart
metering/energy offering, even during the group activities to produce this
report, has been impressive.
Page 131 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
Further, the development of the Active Energy Control profiles, the work on
Z/IP and the solid foundation in home automation are all very positive.
However, concerns remain over a couple of key points. Z Wave is subject to a

single source of silicon and, as yet, there is no large international
implementation of smart metering using Z Wave.
Testing 5.1
range will depend on power used/specific chipsets
antenna design
should test for penetration rather than range?
Testing 4.1
faster isn’t better
depends on usage/range
throughput will vary by network config, testing should be
comparative (point to point) using a standard 1kbit package
over a fixed range (30, 50, 100m)
Testing 5.3
the ‘interfering’ devices should be defined
Testing 5.5
very much silicon vendor specific
lab test/field test should include increasingly common
equipment such as RFID readers
Page 132 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
12 Issues
The table below provides an ongoing record of issues for consideration and
potential actions to resolve.
No Issue Description Resolution Options

I.1 End to End Services Recommend further work in this area
to understand the relationship with
The initial group workshop discussed the Last Mile and the actual requirements
ability of a meter to support the replication
of ‘WAN’ functionality locally, typically by
a meter operator when WAN
communications has failed.
This may be challenging if Local
Communications supports a restricted set
of functionality with regard to data and
commands.
I.2 Data Ownership & Privacy To an extent is contingent upon
Use of mesh networks outside premises Government decisions and
could raise data ownership and data regulatory guidance on data
transfer questions – i.e. Supplier X ownership.
receives data from Meter A via Meter B,
which is supplied by Supplier Z A number of current solutions use
the term ‘tunneling’ to explain how
data is kept private within a mesh.
I.3 Additional Network Requirement? To be discussed by the Group Formatted: Keep with next
Is there a need to define that the smart

meter is expected to be the master of the
HAN network?
In most cases the meter could be
expected to administer the energy
aspects of a network, but could also be a
node to an existing HAN, acting as a
source of data for other nodes.
Also, how do you consider the fact that for
the majority of homes there will be two
smart meters? Which one would be the
master, particularly if the fuels are
provided by different suppliers?
I.4 Potential Wired Solution for Electricity For consideration by any
Only Premises subsequent development activity
A suggestion arising from ongoing
discussions would be how to introduce an
interoperable solution to cover a wired
‘HAN’ where there is no requirement for
wireless from a gas meter. This could limit
some of the applications for nodes within
a network – e.g. any display designed to
be used as a wireless option, but if the
physical medium made use of electrical
wiring within a home, then it also offers
advantages that a wireless solution does
not. Formatted: No underline
Table 2325 Issues Formatted: Style Caption + Centered
Page 134 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
13 References
Shown below are references to relevant materials and resources.
The SRSM project maintains an online reference table of global

interoperability initiatives (OpenHAN, CECED, TAHI etc.) at:
http://snipurl.com/srsmint
Reference Description Link

Itron case studies As requested at first meeting snipurl.com/lcdgitron Field Code Changed
on meter data of Local
collection CommsCommunications
Development Group
WELMEC As stated at first meeting of [reference to materials
guidelines on Local Comms Development required]
power Group.
consumption Defines power consumption
for metrology/
communications.
EN 62053-61 Standard entitled – IEC Page for standard:
Electricity Metering http://tinyurl.com/5n8389
Equipment – Particular
Requirements – Part 61 –
Power Consumption and
Voltage Requirements
Wireless Network Detailed report on wireless http://tinyurl.com/5jumeu
Report networks, including a
technical comparison of
ZigBee and ANT networks
ZigBee & WiFi Report by Schneider Electric snipurl.com/zigbeewifi Field Code Changed
Coexistence investigating the potential
Report interference issues where
ZigBee and WiFi networks co-
exist – used for the discussion
of spread spectrum in 8.2
OpenHAN 2008 US specification of the Direct link to download MS
Home Area requirements for AMI/Smart Word document:
Network System Grid operations using smart snipurl.com/openhan Field Code Changed
Requirements meters as a gateway to
Specification v1 devices within a home
Release
Candidate
Daintree Paper covering a range of snipurl.com/lcdgdaintree Formatted: Keep with next
Networks paper topics relevant to the Local
on Building and Communications
Operating Robust Development Group activities,
and Reliable including; design,
ZigBee Networks interference, security etc.
Table 2426 References Formatted: Style Caption + Centered
Page 135 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Appendix A: Referential Integrity Check

In order to ensure that the evaluation criteria used by the group provides Formatted: Normal
sufficient coverage of the Principles, Assumptions and Requirements, the
table below was created.
It shows which of the Principles, Assumptions and Requirements are

addressed by each of the criteria.
Of the evaluation criteria ‘8.1 – Cost’ and ‘9.4 – Capacity of Silicon Vendors’ do
not have matching references in the Principles, Assumptions and
Requirements, as these are purely commercial considerations.
Of the Principles ‘P.3 – Ownership of the Network’ is not evaluated as this will
not be something the Local Communications Solution can affect. Similarly ‘P.7
– National Standard’ is a product of the process rather than anything an
individual solution can establish.
Of the Assumptions ‘A.1 – Legal’ does not need to be evaluated, ‘A.2 – SRSM
Functionality’ is implied in the requirements and ‘A.4 – Utility Robust’ is
addressed by the requirements and evaluation criteria, but not explicitly.
Of the Requirements ‘NET.3 – Network Time Synchronisation’ is purely

functional, ‘COM.3 – Hand Held as a WAN Proxy’ is an area covered by a
recommendation for further development work to understand the requirement
and ‘CUS.1 – Effect on Customer Networks’ has not been evaluated as part of
this desktop investigation, but is recommended for inclusion in any
subsequent field testing
Ref Criteria Principles Assumpt’s Req’s

1.1 Low level of energy customer CUS.1.2.3
intervention/support required to maintain
communications
1.2 Ease of installation – i.e. discovery at MOP.1
meter installation CUS.3
1.3 Minimise number of site visits to address P.1 GEN.3
local communications issues – i.e. COM.1.3
recovery or remote correction on MOP.1
failure/upgrade failure – will include CUS.2
MTBF and power consumption on meter
1.4 Development tools to support smart P.10 GEN.2
metering and smart energy market
1.5 Ease of integration into metering/home P.10 CUS.2
products – e.g. system on chip, antenna
size
1.6 Scope/receptiveness to accommodate P.1 A.1 GEN.1
specific GB smart metering requirements COM.1
DAT.1
2.1 Status as an Open Standard – P.4.5.6.10 GEN.2
accessibility, defined standards, range of DAT.1
Page 136 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08

participants, proven certification process
2.2 Support for choice of data exchange P.4 GEN.1.2
format DAT.1
2.3 Genuine choice and competition P.4 GEN.2
2.4 Interoperable chipsets P.4 GEN.2
2.5 Effort required to update standards to P.1 GEN.1.2
meet specific GB requirements (less P.4.5.6.10 DAT.1
effort = higher score)
2.6 No. of nodes supported for each HAN, NET.2
assuming minimum capability of 3.
3.1 Consumption/Peak Current/Power P.2.8 GEN.3
Failure Management
3.2 Support for battery powered nodes, but P.1.2.8 GEN.3
also for energy smart metering COM.1
application (e.g. data refreshes in
minutes rather than hours/days for end
nodes)
4.1 Transmission speed – effective data P.2
throughput in kbps per channel
4.2 Robustness (retry mechanisms, P.1
acknowledgements, minimised/nil
message loss – i.e. latency and dropped
packets)
5.1 Typical range (amplified or non- P.2.8 COM.1
amplified)
5.2 Suitability for GB meter locations P.1 COM.1
(consider internal/external, MOP.1
stone/concrete, metal meter cabinets,
meter rooms etc.)
5.3 Vulnerability to signal interference A.4 COM.2
CUS.1
5.4 Ability to cope with signal interference A.4 COM.2
5.5 Blocking Immunity in transceiver COM.2
6.1 Strength/resilience of methods used P.1.9 SEC.1
6.2 Ability to use rolling/successive keys P.9 SEC.1.2
6.3 Support for distinguishing public/private P.9 COM.3
data, and for keeping SEC.1
gas/water/electricity data independently NET.1
secure – i.e. supports 3 different
suppliers for 3 utilities (and any other
authorised party data secure)
7.1 Support for “over the air” upgrades of P.9 GEN.4
‘smart meter’ nodes – i.e. gas +
electricity meters & in home display
7.2 Support for security upgrades P.9.10
7.3 Support for backwards compatibility P.10 GEN.4
7.4 Longevity of frequency A.3
7.5 Longevity of solution technology P.10 A.3
(minimum expected smart meter asset
life of 10-15 years)
8.1 Total cost per home – 1 x electricity
meter, 1 x gas meter with battery, 1 x
Page 137 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08

home display unit = 3 chipsets +
additional battery cost
8.2 Mean Time Between Failures/Reliability MOP.1
9.1 Use in equivalent smart metering P.1.2.4.6 COM.1.3
deployments
9.2 Use in analogous applications P.2.4.6
9.3 Expectation of ongoing required P.6.10
upgrades – i.e. v2009, v2011 (fewer =
higher score?)
9.4 Capacity in vendors to meet smart
metering demands (meters plus displays
and other devices) – assume 5 year
deployment to 25 million homes
9.5 Availability of non-metering products that P.4.6.10 CUS.2
could be relevant to smart metering –
e.g. thermostats, display devices
Table 25 Referential Integrity Formatted: Style Caption + Centered
Appendix B: Last Mile Evaluation

Whilst not part of the core considerations and requirements for the Local
Communications Development Group, the potential role that low power radio
technology could play in supporting WAN communications could be an
important consideration for the overall smart metering project.
This will be contingent upon the outcome of Government discussions on

market models for smart metering, and the work of the group in developing
criteria for this area is recorded in this appendix to support any subsequent
work.
Last Mile Criteria

Ref Criteria Formatted Table
LM1 Support for Last Mile (Y/N/possibly)
Performance
LM2 Nodes per concentrator
LM3 Typical Signal Propagation – average (urban/suburban/rural)
Cost
LM4 Cost of data concentrator equipment
Maturity
LM5 Use in other smart metering deployments for last mile connectivity
LM6 Range of ‘upstream’ WAN physical media supported by data
concentrators
Architecture
LM7 Ability to allow a smart meter to simultaneously be a member of two
separate isolated networks – i.e. the Local Communications network
within a home, and the WAN network to a home.
One network cannot corrupt the other. Security keys and permissions are
separate for the two networks.
Table 26 Last Mile Evaluation Criteria
Formatted: Normal
It has also been suggested that any Last Mile evaluation include field and
laboratory testing. A particular example raised would be to test the ‘house to
Page 138 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
house’ performance to give an indication of the appropriateness of the solution

for different types of neighbourhood.
Appendix CA: Initial Field Test

In March 2008, OnStream, E.On UK and Renesas, all members of the ERA
SRSM Local Communications Development Group, undertook an exercise to
evaluate the signal propagation properties of ZigBee RF solutions at 868MHz
and 2.4GHz.
The test used the following equipment:

- fourFour 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 possiblewas possible.
- Each board had an LCD display to indicate a numerical interpretation of
the received signal strength.
The test that was performed:
- One board of each pair was set to transmit an encoded data word to its
counterpart. The receiving board would display a quality/signal strength
number if and only if the signal was detected and the word decoded
correctly.
- A perfect signal would display a quality number 255, and the poorest
decoded signal would display 1. Although automatic gain controls
(AGC’s) were employed in both chips, the number was a linear
representation of the size of signal reaching the receiver board.
The test was carried out at the following locations, representing a cross
section of GB housing stock:
1 Stone cottage built in 1860 which was constructed with stone and had
lathe and plaster walls.
2 Semi-detached 1960’s three bedroom with no modifications.
3 Detached Bungalow circa 1950.
4 Detached modern two story house with no modifications.
5 Detached two story house with two story extension added.
6 First floor flat where the meter was in the flat not the basement.
Within each location the electricity meter was identified and the ZigBee
transmitter was switched on and placed beside the meter. The corresponding
receiver was activated and placed at the following locations within the
dwelling:
1 Kitchen window sill.
2 Lounge occasional table.
3 Lounge fireplace mantelpiece.
4 Hallway table.
Page 139 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
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 Kitchen Lounge 1 Lounge 2 Hallway Bedroom

2.4 868 2.4 868 2.4 868 2.4 868 2.4 868
Stone 35 125 85 155 70 150 50 140 50 140
Cottage
Semi- 85 110 16 110 80 110 90 200 25 150
Detached
Detached 0 75 40 170 55 115 115 190 35 160
Bungalow
Detached 2 0 20 0 50 0 50 0 30 15 80
Storey
Detached 2 0 45 0 60 0 50 0 60 0 25
Storey with
Extension
First Floor 25 150 35 155 45 115 35 135 35 135 Formatted: Keep with next
Flat
Table 2727 Field Test Results Formatted: Style Caption + Centered
The writers of the test report observed that:

1 As anticipated, the signal penetration of the 868MHz was superior to
the 2.4GHz by a factor of 2.5 on average.
2 Operating in the low power constraints of the ZigBee specification, two
of the six sites failed to receive the 2.4GHz signal with the receiver
placed in a preferred and typical position. Both of these sites had either
a long transmission path or multiple barriers between transmitter and
receiver.
3 All sites demonstrated a signal reduction on 2.4GHz when the
transmission path was blocked by a person. No similar signal reduction
was encountered on the 868MHz.
4 2 further sites failed to receive at 2.4GHz when the signal path was
blocked by a person. Both sites demonstrated a relatively weak signal
response prior to this.
5 In locations where both frequencies were working satisfactorily, the
signals appeared to be unaffected by existing I.S.M. appliances such
as Wi-Fi, Microwave ovens, and video senders, although, in 2
locations.
6 Operation of the video sender did severely disrupt the Wi-Fi Router, in
two locations.
7 In locations where both frequencies were working satisfactorily, the
signals did not affect other I.S.M. appliances such as Wi-Fi or video
senders.
8 It is possible to add a power amp to the 2.4GHz radio and increase its
output power to 10mW. This would increase the range of 2.4GHz radio
to about the same as the 868MHz radio, but would use more energy,
affect battery life, and may cause interference.
The report conclusions were:

Page 140 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
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,report and responses from group members can be viewed
online at:
http://snipurl.com/lcdfieldtest
Appendix D: ZigBee@2.4GHz Evaluation Formatted: Default Paragraph Font
Introduction
Taken from a ZigBee paper submitted to support the group evaluation
process.
Communications
Unlike some alternative options available for local communicationsLocal

Communications in the UK, ZigBee 2.4GHz offers a lot of flexibility in the final
solution. Some technologies are defined only at a radio (MAC & PHY) level,
which means that they require someone to do a lot of work to get effective,
robust, secure and interoperable communications working well. Some
technologies are more than that, but do not go as far as to define the
application level messages and protocols, network formation mechanisms,
key establishment protocols etc. The choice of ZigBee at 2.4GHz would in
fact offer the whole spectrum of options for UK Smart metering and ensure
that any requirements could be implemented successfully;
Option A: Adopt ZigBee Smart Energy as currently defined. Formatted: Font: Bold
ZSE is an application profile that defines the entire application including all
messaging, secure transport of network keys and link keys, network formation
and discovery etc. If the UK, like many US utilities and Victoria in Australia,
was to specify ZSE, in its entirety, as a requirement for their smart metering
local communicationsLocal Communications, this could be easily
communicated and understood as a requirement to manufacturers as there is
Page 141 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
already a certification process in place to ensure that products conform to the

standard and are interoperable.
Option B: Modify ZigBee Smart Energy for UK purposes Formatted: Font: Bold
Inevitably, ZSE has not been developed with the UK market specifically in
mind and the majority of manufacturers, utilities etc. involved in defining the
spec were focussed on requirements for California and Texas, so it is likely
that there are some modifications that the UK would want to the standard. For
example, UK smart metering might decide that the Certicom ECC key
exchange mechanisms are not required and may want an alternative
mechanism included in the spec for use in the UK. The mechanism for
proposing and completing modifications to the standard within the ZigBee
Alliance are well defined and tested, and it should be quite easy once
requirements are known, to make modifications, which might be generic or
specific to the UK market.
Option C: Combine ZigBee Smart Energy with other protocols Formatted: Font: Bold
For instance, some work is beginning to allow DLMS messages to be

transported across ZigBee networks. This has been done in ZigBee before
with BACNET (in building automation market). It is possible to use ZigBee
Smart Energy and some other protocol in different ‘endpoints’ in the same
ZigBee device, so it should be possible to include for example a ZSE simple
meter endpoint as well as a DLMS meter endpoint in a ZigBee meter
application.
Figure 17 ZigBee & DLMS Illustration Formatted: Style Caption + Centered
Option D: Create a totally proprietary profile on top of ZigBee Networking Formatted: Font: Bold
It would be an unusual and unlikely move, but UK smart metering could decide
to define an entirely new application profile which is unique to the UK and
Page 142 of 143 27-Oct-0827-Oct-0820-
Oct-0830-Sep-08
either totally proprietary or proposed as a new public application profile.

Standard ZigBee networking offers all of the discovery, network formation,
routing, message clusters etc. in any case, and any new profile could take
advantage of that. More likely, some proprietary operation could be
implemented in individual products alongside and as well as the ZSE
application profile (on a different endpoint within the device), to provide
innovation and differentiation as well as standardisation and interoperability in
a single product.
Summary Formatted: Font: Bold
So, in summary, ZigBee at 2.4GHz is not just a simple take-it-or-leave-it

option for the ERA and UK smart metering. The standard itself has built in
flexibility allowing standardised applications to run alongside proprietary
applications even in the same device, and the ZigBee Alliance is an open
organisation with open access to membership and open access to the
committees that define and shape the standard and the various application
profiles.
Page 143 of 143 27-Oct-0827-Oct-0820-

Oct-0830-Sep-08
Page 120: [1] Formatted Simon Harrison 22/10/2008 15:28:00
Font: (Default) Microsoft Sans Serif

SRSM Local Communications Development 0 - 4 Marked

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRSM Local Communications Development 0 - 4 Marked

Uploaded by

Copyright:

Available Formats

SRSM and Beyond

Local Communications Development

Note: Formatted: Font: Monotype Corsiva

Comms group. Formatted: Font: Monotype Corsiva,

V0_5 will be published shortly following the meeting

Author(s) Simon Harrison

9 Additional Considerations .................................................................... 7162

3.1.3 Meter Location ...........................................................................11

12 Issues ................................................................................................. 107

8.1 Solution Options Descriptions ...........................................................42

Figure 4: Smart Utility Context .........................................................................18

Table 19 Evaluation Scorecard................................................................... 8676

Page 8 of 143 27-Oct-0827-Oct-0820-

This document is a development of Schedule H of the Smart Metering

Page 9 of 143 27-Oct-0827-Oct-0820-

Version Date Author Description

1.2 Review Group & Website

Page 10 of 143 27-Oct-0827-Oct-0820-

Orsis PRI UK Ltd

Page 11 of 143 27-Oct-0827-Oct-0820-

1.3 Intellectual Property Rights and Copyright

Page 12 of 143 27-Oct-0827-Oct-0820-

2 Executive Summary and Introduction

It also includes an evaluation of solutions optionssolution options and

Any statement of preference for particular communications solution options

Further information on the SRSM project is available from:

For ease of understanding and application to a familiar domestic context, this

2.5 Structure of this Document

Page 14 of 143 27-Oct-0827-Oct-0820-

3 Glossary & Conventions

The project published Proposals and Options for a Smart Metering

The following subsections give a brief overview of a number of these topics.

3.1.1 Market Segments

Therefore, within this document, the solutions optionssolution options

3.1.2 Meter Functionality

• 2 Way Communications – WAN and Local (see below)

• Support for microgeneration

3.1.3 Meter Location

Figure 1: Smart Meter Locations

The ERA Smart Metering Operational Framework documentation specifies

The Operational FrameworkSmart Metering Operational Framework includes

Local Communications, unless specifically excluded by the Meter Variant

3.1.4 Meter and Metering System

Smart Metering Systems – Illustration of Flexible Approaches

Smart Metering Metering System Illustration of how fuels could share

The required functionality could be delivered by components:

As defined by the SRSM project, a smart metering system could comprise a

The potential variety of physical locations and conditions of metering points

Therefore all general references to smart meters and uses of icons to

Page 17 of 143 27-Oct-0827-Oct-0820-

CMOS Complementary Metal Oxide Semiconductor – a type of

Page 19 of 143 27-Oct-0827-Oct-0820-

Page 20 of 143 27-Oct-0827-Oct-0820-

Page 23 of 143 27-Oct-0827-Oct-0820-

Ongoing at the time of developing this document

Page 24 of 143 27-Oct-0827-Oct-0820-

Page 25 of 143 27-Oct-0827-Oct-0820-

4 Local Communications Context

4.1 General Context

Interoperable Local Communications capability will enable customers and

Throughout this document applications involving water meters, TV displays

Business Processes >>>>>>>>>>>>>>>>>