SRSM Local Communications Development 0 3

SRSM and Beyond
Local Communications Development
Author(s) Simon Harrison

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

9.2.1 Frequency Information ...............................................................59
9.2.2 Licensed or Unlicensed ..............................................................61
9.3 Data Exchange Format Options ........................................................61
10 Evaluation of Solution Options ..............................................................64
10.1 Evaluation Process............................................................................64
10.2 Evaluation Methodologies .................................................................64
10.2.1 Evaluation Weighting .................................................................65
10.2.2 Evaluation Scoring .....................................................................65
10.3 Evaluation Criteria .............................................................................65
Evaluation Scorecard ............................................................................69
10.4...............................................................................................................69
10.4.1 Evaluation Notes ........................................................................72
10.5 Last Mile Evaluation ..........................................................................72
10.5.1 Last Mile Criteria ........................................................................72
10.5.2 Last Mile Evaluation Scorecard .................................................73
10.5.3 Last Mile Evaluation Notes ........................................................73
10.6 Evaluation Results.............................................................................73
10.7 Evaluation Issues Table ....................................................................74
10.8 Evaluation Scenarios.........................................................................74
11 Recommendation ..................................................................................75
12 Issues ....................................................................................................76
13 References ............................................................................................77
Appendix A: Initial Field Test ..........................................................................78
Figures
Figure 1: Smart Meter Locations .....................................................................10
Figure 2: Smart Metering Systems, Illustration of Flexible Approaches ..........11
Figure 3: SRSM Operational Framework Scope .............................................15
Figure 4: Smart Utility Context .........................................................................17
Figure 5: Smart Display Context ......................................................................18
Figure 6: Smart Home Context ........................................................................19
Figure 7: Smart Home Context & Clusters ......................................................20
Figure 8 Different Uses of Local Communications ..........................................21
Figure 9: Local Communications for the Last Mile ..........................................23
Figure 10 Technical WAN Interoperability .......................................................26
Figure 11: Simple Collection of Smart Meters and Local Devices ..................26
Figure 12: Independent Networks....................................................................27
Figure 13: Local Communication Signal Range ..............................................28
Figure 14: Overlapping Wireless Ranges ........................................................28
Figure 15: Required Local Comms Range Example .......................................29
Figure 16: Mesh Network to Concentrator .......................................................30
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 Comms
Development Group
0_3 September Simon Significant update
2008 Harrison following two
meetings of the
Local Comms
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 history of which
is shown below.
Version Date Author Description
0.1 17th July 2007 Simon Harrison Initial draft based upon original consolidated
SRSM Communications Solution Options
document.
0.2 25th July 2007 Alastair Minor update following review
Manson
0.3 6th August 2007 Simon Harrison Update for 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
1.2 Review Group & Website

This document has been developed with the assistance of a group of
interested parties, including energy suppliers, meter manufacturers,
communications experts, interoperability experts and other stakeholders.
The table below lists the organisations and companies who are members of
the group.
Energy Retail Association 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 Freescale
Services
Fujitsu Green Energy Options
Himsley Meter Revenue Services Horstmann
I+P Services Imserv
Ingenium Itron
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 Zigbee Alliance
Full details of the membership of the group, its’ meetings and papers can be
viewed at the public website: http://www.srsmlocalcomms.wetpaint.com
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.
2 Executive Summary and Introduction

2.1 Executive Summary
[Overview and Explanation of the exercise and the scale of the document to
be added when appropriate.]
2.2 Purpose
This document presents the context, requirements, issues and solutions
options for two-way Local Communication for smart Metering Systems.
It also includes an evaluation of solutions options and recommendations for

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

does not constitute a firm or binding decision by the Suppliers participating in
the SRSM project.
Further information on the SRSM project is available from:

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

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

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

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

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

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

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

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

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

• Interval measurement and storage of consumption data
• Support for flexible and configurable energy tariffs
• Interoperable data exchange and protocols
• Remote connection/disconnection1
• Support for prepayment/pay as you go operation (subject to the
footnote above)
• Support for microgeneration
• Provision of consumption information
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.
• Remote configuration of tariffs, meter operations, upgradeable

firmware etc.
3.1.3 Meter Location

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

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

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

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

Throughout this document, references to a smart meter, particularly within
diagrams, should not be interpreted as referring only to smart meters where all
of the functionality is contained within one ‘box’. There is regular use of a
picture of an electricity smart meter to represent smart Metering Systems.
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.
3.2 Glossary
A number of these definitions are necessarily drawn directly from the Smart
Metering Operational Framework, as they apply across the scope of that
document and not just to Local Communications.
Term Meaning
Access Control The method by which the Operational Framework controls
access to smart Metering Systems, smart metering data and
associated devices.
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.
Authorised Parties could include a communications service
provider, a meter operator, a network operator etc.
BoM Bill of Materials – term used by manufacturers to cover a list
of materials and components used to make an assembled
item.
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.
CMOS Complementary Metal Oxide Semiconductor – a type of
microchip
Data Exchange Electronic interactions including the transmission of data
between Metering Systems and Authorised Parties or
Metering Systems and Local Devices
DEST Danish Energy Savings Trust
DLMS Device Language Message Specification – European data
protocol for meter communications
ERA Energy Retail Association
GFSK Gaussian Frequency Shift Keying – a form of modulation
used for radio communications – is used by Bluetooth and Z-
Wave
GMSK Gaussian Minimum Shift Keying – a form of modulation used
for radio communications – is used by GSM
GPIO General Purpose Input/Output
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.
HVAC Heating Ventilation and Air Conditioning
IP Internet Protocol
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
Term Meaning
structured Access Control, is a key interoperability
requirement.
ISM Industrial, Scientific, Medical – term describing unlicensed
international radio frequency bands
Local Communications between a Metering System and Local
Communications Devices within the premises in which the Metering System is
installed.
Local Device A Local Device can be any piece of equipment within
premises that communicates directly with the Metering
System using Local Communications.
MCU Micro Controller Unit
Metering System A single device or meter, or a combination of devices used
to deliver the Lowest Common Denominator as defined in
the Operational Framework Schedule L ‘Smart Meter
Functional Specification’.
Meter Variant Classification of meter type under the Operational
Framework. A ‘Standard’ variant is suitable for installation at
the majority of meter points in Great Britain. Other variants
exist to cover specific supply, circuit or customer issues at a
site.
Examples include Polyphase, Semi-Concealed or 5
Terminal variants.
The full table of Meter Variants can be found in Schedule L
‘Smart Meter Functional Specification’.
Meter Worker A generic Operational Framework term referring to any
person attending a metering point for the purposes of
installation, maintenance, investigation, replacement or
removal of the Metering System.
Includes existing energy industry defined roles of Meter
Operator, Meter Asset Maintainer, Meter Reader, Data
Retriever etc.
OEM Original Equipment Manufacturer
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
Term Meaning
OTP One Time Programmable
POR Power On Reset
PWM Pulse Width Modulation
RAND Reasonable and Non-Discriminatory
SCADA Supervisory Control and Data Acquisition, generally an
industrial control system managed by a computer.
SoC System on Chip
SRSM Project Supplier Requirements of Smart Metering project.
Exercise in 2006-08 undertaken by ERA to develop the
Operational Framework.
Ongoing at the time of developing this document

Supplier Means an energy retail business
WAN (Wide Area Communications between a Metering System and a remote
Network) Authorised Party
Communications
WSDL Web Services Description Language – a language used
within interoperable machine to machine interactions over
networks.
4 Local Communications Context

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

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

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

and other ‘non-energy’ applications are used to illustrate the potential of smart
metering to support a range of known and as yet unknown applications.
However the Local Communications solution must, first and foremost, meet
the energy requirements. Smart meters are not intended to be a fully
functional alternative to other residential gateway or home hub products –
these products tend to be capable of handling voice and multimedia
applications that would add significantly to the cost of utility meters.
The diagram below shows the SRSM project representation of the operational
architecture for smart metering and therefore the scope of the Operational
Framework – this document specifically relates to the ‘Local Comms’ section
on the left hand side of the diagram.
Industry Interfaces
Data Transport
(internet)
Figure 3: SRSM Operational Framework Scope
Please note that ‘clip on’ or similar devices where information is captured via a
pulse counter, optical port, or by use of a sensor around an electricity cable
are not considered smart under the definitions of the Operational Framework
and are not included in this context. However, through the development of a
standard for smart metering local communications, any future ‘standalone’
devices could utilize the frequencies and protocols defined by the Operational
Framework.
4.2 Smart Utility Context for Local

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

protocols are open, or available, introducing flexibility and innovation for
display devices.
Shown below is a representation of the basic utility requirements for Local

Communications for smart metering:
Figure 4: Smart Utility Context
In this example, a water meter is included to illustrate the potential for an

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

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

different display devices, as shown in the illustration below. The original ‘LCD
device in Kitchen’ solution remains, but is supplemented or replaced by
options using personal computers, white goods, cellular telephones etc.
The success of smart metering in raising awareness of energy consumption,

and actually changing customer behaviour, will depend upon making the
information available in a way that is most relevant to individual customers.
Figure 5: Smart Display Context
The step from the illustration of a smart utility context to a smarter display
context is one of interoperability. As long as the energy smart meters all
communicate using the same technology, protocols and a standard data
format, it will be possible for display functionality to be added to a number of
differing delivery devices.
An example could be the use of a USB dongle (and software) for a PC

allowing a customer to access sophisticated energy management information
from their utility meters. Currently this type of solution is being offered to
commercial customers through a wide range of proprietary offerings.
A number of display applications may rely upon a service provider external to

the home – e.g. an energy management website that a customer logs on to, or
a specific TV channel. In these types of application, data from smart meters is
processed and formatted by an external party before being presented back to
the customer. As these types of display services include a remote service
provider, they are not within the scope of the Local Communications work.
If smart meters operated on an interoperable open standard for Local

Communications then this level of energy management could be available to a
much wider range of customers. In this environment, Local Devices can
interoperate independent of the Metering System. For example, the water
meter could prompt the customer to call the water utility using a display
device.
4.4 Smart Home Context

Establishing an interoperable solution for Local Communications, as required
to support customer choice for the display of consumption information, opens
up a range of opportunities for energy related Local Communications.
As shown below, a number of ‘green’ and other applications could be

supported by ‘or interact with’ smart meters. These types of automated home
technologies are now being installed, and could become more prevalent if
they were capable of responding to utility price triggers from smart meters, or
could utilise the WAN communications functionality that smart meters will
introduce to every home.
Figure 6: Smart Home Context
The final context illustration below presents the smart home context for the
smart metering local communications solution(s).
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.
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
5 Associated Topics
This section of the document includes further information to assist with setting
the requirements, solutions and evaluation into a specific GB smart metering
context.
5.1 A National Standard

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

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

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

considered by many customers to be personal and private. Further,
consumption patterns based on interval data could allow third parties to
establish patterns of occupancy, which would very much be viewed as
personal data.
2
The SRSM project is considering the issues surrounding ownership of smart metering data
within a separate workstream, therefore they will not be covered within this document.
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
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 Framework, the following categories of local device

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

classification of local devices, and if so, what are the recommended
classifications and how they can be documented.
It should be noted that a number of the solution options provide for device
classification within their profile regimes.
5.5 Processes/Activities Required

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

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

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

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

prepared by the SRSM project, it shows how gateways and protocols could be
used in a WAN context to deliver standardised interoperability.
Meter with
WAN Hardware
Enterprise
Sta
n
Standard Applications
Pro dard Head End Gateway
t o co
l
Supplier IT Architecture
Figure 10 Technical WAN Interoperability
5.7 Independent & Private Local Networks

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

communications in two neighbouring properties.
Figure 11: Simple Collection of Smart Meters and Local Devices
The house on the left has a gas meter in an external meter cupboard, a water
meter fitted at the boundary point, and has a TV capable of displaying smart
metering information.
The house on the right differs in that there is no water meter, the gas meter is
located at the rear of the house and the preferred display solution is a portable
LCD display, usually kept in the kitchen.
The illustration below shows the required links between devices.
Figure 12: Independent Networks
The topology of the network within premises does not need to be specified, as
these could vary significantly by property type.
However, in order to deliver the necessary signal propagation to link the

electricity meter to the gas meter in the blue house, the range of Local
Communications of the electricity meter could be as shown below.
Figure 13: Local Communication Signal Range
This simple illustration, without allowing for signal drop off as it passes through
walls, shows how all of the devices in the left hand house are within reach of
the electricity meter in the right hand house. It is a requirement for the
information from one customers’ metering not to be visible on their
neighbours’ display.
The illustration below shows how much overlap there will be between signals
for this simple configuration of smart meters and devices. The TV display in
the left hand house is in range of all four energy smart meters.
In reality, the range of the wireless signals is likely to be much greater than
shown.
Figure 14: Overlapping Wireless Ranges

The requirement is for the Local Communications solution to deliver a network

of Local Devices for each property. It is not practical (or possible) to restrict a
wireless signal from each meter to the boundaries of each premises.
Figure 15: Required Local Comms Range Example
Finally, there are circumstances where the wireless signal could be required to
transfer data between properties.
The illustration below shows where communication between meters in

different properties would be a desirable feature for Local Communications. It
is a very simple depiction of meters forming a mesh network to reach a data
concentrator in a substation. Whilst this is effectively the WAN
Communications network, it utilises the Local Communications hardware in
smart meters.
Figure 16: Mesh Network to Concentrator
5.8 Wireless to Wired Options

A standard/solution that includes a wired option for local communications as
well as a wireless option could be beneficial to link to existing and new wired
devices and networks.
A number of appliances and networks will already exist in premises where

smart meters are installed. Each of these systems will be operating using their
own protocols and data formats, and not necessarily interoperating. There
may also be network capable appliances that are not yet part of any network.
Examples could include white goods capable of communicating using CECED
standards, but no wireless hardware.
It is not an ambition for smart meters to directly interact with all of these
systems, as this would introduce complexity and cost into the meters
themselves.
Other ‘smart metering’ implementations do include wired local

communications, typically in Northern Europe. Typically these use the M Bus
protocol over a low voltage (less than 30v) wire within meter rooms for 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.3 above,
there are localised regulations within the UK that appear to rule out this option
for gas metering.
However, it would be beneficial for a number of ‘non-utility’ systems to interact

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

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

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

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

During the activity of the Local Communications Development workstream
work has commenced on delivering a specification combining ZigBee and
Homeplug.
Aimed to deliver a technical solution to practical issues raised by the Victorian

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

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

that can be site or customer specific. There has been little standardisation of
the exact positioning of where the meter is located. Meter location, which is
usually an ‘out of sight, out of mind’ consideration, and could be anywhere
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
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
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
Total 2,301 100
3
Defined as: ‘a flat in a purpose built block less than 6 storeys high. Includes cases where
there is only one flat with independent access in a building which is also used for non-
domestic purposes’. High Rise therefore being blocks over 6 storeys high.
Type of Dwelling – Scottish House Condition Survey 2004/5
Welsh Data:
Detached 264 23
Semi-Detached 387 33
Terrace 405 35
Flats 101 9
Total 1,157 100
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
Total 25,240 100
[Add data for construction type if available?]

[Add data for meter location if available? Interior/Exterior/Meter Cabinet]
6 Principles & Assumptions

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

Based on the context discussions above, and on discussions within the group,
the following assumptions apply to the requirements, solutions and evaluation
presented below:
No 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
No Assumption
A.4 The Local Communications Solution will be utility robust. This means
that for the purposes of delivering utility services to a customer it will
not be reliant upon, or affected by, devices owned by a customer or
other 3rd party
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
must provide for data exchange is for intermittent
between smart meters and local communication between a
devices 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
COM.1 The Local Communications Solution Note that domestic sized
must be able to operate effectively in smart meters could be used
the majority of British domestic in non-domestic premises.
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 device.
In this instance, if the WAN
communications is not available, it will
be possible to exchange information
(meter readings, tariff settings etc.)
through the use of a Meter Worker
device. This failsafe/fallback facility
could include the exchange of
information with Metering Systems
using local communications during a
site visit or also for a ‘drive by’ or ‘walk
by’ activity.
Security
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, example would be where an
and to prevent unauthorised access electricity meter passes data
to/use of Local Device data or to a display device from a
functionality. 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

NET.1 The Local Communications Solution
shall ensure that all Local Devices are
required to join the network to access
meter data and functionality
NET.2 The Local Communications Solution
shall be able to support a minimum of 7
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, customer wants to pair a
shall be simple to operate. new Local Device
CUS.3 The local communications solution(s) For example, beyond
will place minimum requirements on confirming connection or
customers for day to day operation. removal of Local Devices,
the customer will not be
expected to take action to
re-establish communications
following any failure.
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 Local (and WAN)
communications.
A number of gas appliances already include gas and electricity components.
Ref Factor
Some European smart meter installations use low power (30v) wired
connections to link gas, water, heat and electricity meters for
communications purposes.
There are key regulations and standards relating to gas meters and potential
explosive atmospheres (ATEX).
Products are available to introduce two way communications for gas meters
that do not compromise the safety of the meters, or introduce battery life
issues.
The fundamental design of a gas meter as mechanical or electronic will also

be a factor in how much power it consumes.
Whilst possible (see standard below), gas meters that meet the safety
requirements to support electrical connections are viewed as too expensive
for consideration for mass market deployment.
A particular issue for GB gas metering is the extensive use of meter boxes,
which would require modification to meet ATEX requirements.
The Institution of Gas Engineers and Managers (IGEM), at the time of

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

A key benefit of smart meters will be a reduction in the number and therefore
cost of field visits to read and maintain the meter.
However, there is no requirement that smart meters should result in an end
to all visits.
e.g. Customers who use debit functionality extensively (daily or more than
daily) could require replacement batteries within the expected smart meter
asset life. This would apply to above average usage of any functionality that
would reduce battery life.
F.3 Battery Life Considerations
The Local Communications Development Group have discussed at length
the options for ensuring a reasonable balance is struck between battery
life/cost/customer feedback.
It is accepted that a gas meter cannot provide continuous communications
without a large and expensive battery in order to meet the requirement for 10
years plus of operation.
At the same time, the immediacy of feedback to a customer display device
will be critical in assisting customers with managing their energy
consumption.
It is suggested that application software could manage the duty cycle in gas
meters to optimise battery life:
- waking up to transmit/receive information for Xms every minute or 5
minutes
- waking up more frequently when credit levels (in debit mode) are
below a configurable threshold, to ensure that credit purchase
Ref Factor
messages are picked up quickly (or the customer could be prompted
to press a button to receive a ‘refresh’ of balances)
- where the gas supply has been disabled, remain dormant until the
customer pushes a button on the meter to reinstate gas supply (as
required by the SRSM meter specification)
More detailed work is required to establish the preferred minimum position, if
an agreed position is required.
7.3 Potential Additional Requirements

Requirements could also be derived to support the use of Local
Communications hardware to deliver the ‘Last Mile’ link for WAN
Communications.
Specific requirements for the smart metering system may also arise from the
Local Communications solution where a meter may be required to store data
for onward periodic transmission. Examples could include services configured
to transmit gas meter data on a daily basis via the electricity meter, or an
annual boiler diagnostic report.
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, weblinks to relevant materials etc.
Reference Date, Version and Provider of information used to populate the
table
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.
As with existing Bluetooth Personal Area Networks, Bluetooth low

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

the Bluetooth SIG by Q1 2009.
Hardware: There will be standalone and dual mode Bluetooth low energy
chipsets, operating the low energy protocol stack or low energy
and classic stacks.
Standalone will be type installed in small end nodes, such as
watches and sensors.
Cost:
Data:
Power: Listens and transmits for 0.01% of time (compared to 1% listen
cycle for Bluetooth classic)
Advertises – 2ms
Connect request – 1ms
Send application data – 3ms
Frequencies: Operates at 2.4GHz using 40 channels (3 advertising, 37 data).
2 MHz channel spacing
0.5 modulation index GMSK (GFSK)
Protocols:
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
applications: 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.
Maturity: 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:
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.5 prepared in August 2008 by Project Team from online
sources
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:
Use in other M-Bus forms part of the Dutch Smart Meter Specification7.
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
Solution Wavenis www.wavenis-osa.org

& www.coronis.com
Description: Wavenis is a wireless connectivity platform that features Ultra Low
7
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.
Power and Long Range coverage capabilities. Wavenis has been

developed by Coronis (creation in 2000) to address the most
critical applications where devices are located in hard-to-reach
places with strong energy constraints for multi-years operation.
Offers today one of the most attractive price-performances ratio.
Dedicated to remote operation for both fixed and mobile WSNs
(Wireless Sensor Networks).
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 typ (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)
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 - Gaz AMR/AMI (ChinaGas, GasNatural @ Spain, …)
3 – Elec 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 – up to 25mW outpout power class Wavenis modules offer 1km
‘Last Mile’: Line of Sight (LOS) thanks to -113dBm sensitivity (50kHz
bandwidth reciever) with -3dBi helicoidal antenna.
2 – 500mW power class Wavenis modules offer 4km range. These
modules are usually intended to range extenders for large scale
networks.
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 Sprectrum (FHSS) technics combined
with data interleaving and Forward Error Correction (BCH)
mechanisms. Encryption is implemented in option upon customer
request.
3 – With 17 other companies, Coronis launched (June 2008) the
Wavenis Open Standard Alliance (www.wavenis-osa.org) which
paves the way of the Wavenis standardization to play a major role
worldwide in the “Short Range Wireless” markets.
Against:
Notes:
Reference: V1 provided March 2008 by Bev Adams of Elster
V2 provided Sep 2008 by Christophe Dugas of Coronis, an Elster
Group company & Wavenis-OSA
Note – ZigBee, at the request of group members, is presented in two iterations

to acknowledge the different functionality and performance of differing
frequencies
Solution ZigBee @ www.zigbee.org
868MHz
Description: Silicon based protocol operating on the IEEE 802.15.4 standard for
physical layer and medium access control.
Networks can contain 65536 nodes.
Supports two types of devices:

- Full Function Device (FFD), which can co-ordinate or
participate in a network
- Reduced Function Device (RFD), which can only participate
in a network
Supports 128-bit encryption
Hardware: Radio chips available from Atmel
Cost:
Data: Between 20 and 40 kbit/s at 868MHz
(improved by 2006 revision of 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 20118
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
Solution ZigBee @ www.zigbee.org

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.
8
In-Stat Market Research “ZigBee 2007: What it Iz and What it Iz not”
- 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
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 201110
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 communications e.g. Southern California
Edison in the USA, Victoria in Australia, and last mile
communications, e.g. City of Gothenburg
- Home Automation, including lighting control (e.g. Control4),
heating control (e.g. Kalirel), security (e.g. Alertme.com), roller
blinds etc.
- Commercial Building Automation, including lighting and heating
control (e.g. TAC/Schneider, Siemens) and fire and safety.
- Industrial control such as ball valve monitoring/control (Eltav)
- Health monitoring products are in early stages of development.
- Niche markets such as marine electronics (e.g. Raymarine)
Geographically, ZigBee has products all around the world.
Maturity: The ZigBee Alliance was formed in 2002. ZigBee was first
released as a standard in December 2004. Since then there have
been 2 major releases of the standard, one in 2006 and the most
recent, adding ZigBee PRO features in 2007. With a number of
products now certifying for Home Automation, Manufacturer
Specific and Smart Energy, ZigBee 2007 is regarded now as
mature.
A number of vendors of ZigBee silicon have had customers with

products in the market for a number of years with earlier variants of
ZigBee stacks. It is generally accepted that about 7 million
ZigBee/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
10
In-Stat Market Research “ZigBee 2007: What it Iz and What it Iz not”
being the City of Gothenburg project currently being installed for

gas and electricity meters in Sweden. A number of meter
manufacturers have already implemented AMR systems using
ZigBee.
For: - Open Global Standard, supported by 300 companies and 22
stack/silicon solutions
- A new technology that is mature and accepted by the smart
energy community, yet future proof
- Cost-effective technology that will become even more cost
effective in the next 2-3 years
- Suitable for local communications AND last mile communications,
opening up the possibility of a single communications chip in smart
meters covering both!
- Robust, secure, scalable mesh networking
- Good bandwidth availability for a monitoring and control network,
some scope for future use
- A number of working ZigBee Smart Energy products in the
market and arriving into the market in 2008
Against: - Perception of issues with propagation in buildings, however
building construction effects all wireless technologies and can be
shown not to be an issue with ZigBee at 2.4GHz in most situations.
When there are propagation issues these can usually be mitigated
by use of the ZigBee mesh network.
- Perception of interference issues with other 2.4GHz wireless
technologies, in particular 802.11b/g/n. While there is some basis
for concerns they have been satisfactorily addressed by the
standard, and tested in independent studies (ref: “ZigBee / WiFi
Coexistence Report” by Gilles Thonet and Patrick Allard-Jacquin,
Schneider Electric, 29/01/2008)
Notes:
Reference Updated April 2008 – v2 – David Egan & John Cowburn
Updated (minor) August 2008 – David Egan
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 –
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
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
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:
Reference V1 provided April 2008 by Bernd Grohmann of Zensys
V2 provided Aug 2008 by Niels Thybo Johansen of Zensys
8.2 Other Solution Options

The table below lists a number of other candidate solutions for Local
Communications. It gives a short description of the solution, website details
where available, and an explanation of why it is not included in the main
evaluation process.
Solution 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
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 Contol running at speeds of 1-10 kBit/sec
depending on conditions.
The Command and Control standard is probably most suited to
metering due to its low cost.
Used in homes to network Ethernet devices.
Homeplug standard is reasonably mature. Command and Control
is a recent development
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 plantwide. It

focuses on battery-powered field devices with the ability to scale to
large installations and addresses wireless infrastructure, interfaces
to legacy host applications plus security, and network management
requirements in a functionally scalable manner.
Website http://snipurl.com/isa100
Reason for not Still under development
including in
evaluation
Solution KNX
Description Originally developed by Siemens and Merten, primarily aimed at
home and building automation. Well established and promoted
standard based out of Brussels.
Documented by world and European standards – ISO/IEC 14543,
EN50090, EN13321-1
Uses the same upper-layer protocol for different physical layers –
twisted pair, power line, Ethernet and RF at 868MHz.
Communicates data at 16384 bits/sec.
Used the same modulation scheme as Wireless M-Bus in S2 mode.
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
• Targetted at battery powered devices
• Supports secure encrypted comms
• Star and peer to peer topology
• 38 to 230 kbs
• 868 MHz
• Supports 2000 devices in a network
• 3 to 5 year battery life with AAA cell
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.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
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) and
WSN (wireless sensor networks). The Sensinode NanoStack meets
the 6LoWPAN (IPv6 over Low power WPAN) specifications
released in 2007 and offers a scalable and robust architecture for a
wireless mesh network where all nodes cooperate to transport
information almost like the Internet. By using many small radio
modems, a low-power wireless network can cover large
geographical areas using the licence-free frequency band at 2,45
GHz. The self-configuring and self-healing properties of the
6LoWPAN network offer redundancy and low maintenance cost.
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

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
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.
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:
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:
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 european band, unlikely to be revoked, but risk
frequency 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:
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 communications could also restrict the
number of devices within a home that would be capable of communicating
with a meter.
The unlicensed ISM bands do support two way communications, do have

active and growing markets for radio transceivers, and these are the bands
being selected for smart metering and AMI implementations in other markets.
The volumes of silicon chips being sold for these bands make the unit cost
much lower than those for licensed bands ($3 vs. £70)11.
The use of unlicensed bands does come with the risk of interference from
other devices as they establish themselves at particular frequencies. The
2.4GHz band already includes microwave ovens, Bluetooth, Wi-Fi, TV signal
repeaters and more. However, there are a number of techniques in use to
allow devices to co-exist effectively within frequency bands.
9.3 Data Exchange Format Options

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

requirements and the existing format options would be recommended.
Data 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
C12.21 – Update of C12.18 for use with a modem
C12.22 – Interface to data communication networks
11
Technical Architecture for UK Domestic Smart Meter Systems, Alistair Morfey, Cambridge
Consultants 2007
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/Cosem
Format
Description: Definition of standardised metering objects (Electricity, Water,
Heat, and Gas Metering covered)
Used by/for: Commonly used in Electricity metering in Europe, gaining adoption
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.
Against: Use of XML for local communications could place an unacceptably
high overhead on the microcontroller itself. XML support could
easily require more space than is typically available on low power
radio microcontrollers. Implementation is feasible, but at the cost of
adding memory and co-processors and decreasing battery life.
A bespoke GB smart metering XML schema would require

development and ongoing governance.
Notes:
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:
10 Evaluation of Solution Options

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

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

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

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

• Group refined requirements
• Group discussed and agreed high level plan for evaluation criteria and
process
• Updated evaluation criteria issued for review
September 2 2008 Meeting
• Presentations and Q&A sessions for each of the solution options
• Discuss and update evaluation criteria
• Begin completing scorecard, recording any key issues or risks noted
against a solution option
October 2 2008 Meeting
• Complete evaluation criteria, recording any key issues or risks noted
against a solution option
Late October 2008 Meeting
• Finalise and agree recommendation
Desktop + supporting evidence
10.2 Evaluation Methodologies

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

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

Boolean criteria are rated at 5 – YES or 0 – No.
Scored criteria are on a 0 to 5 basis, and scores assigned are objective or

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

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

12
(Must Have/Desirable) (Desirable Method
only: (Boolean,
3 = Very Ranked,
2 = Fairly Scored)
1 = Less)
failure/upgrade failure –
will include MTBF and
power consumption on
meter battery as
considerations
1.4 Development tools to Desirable 1 Scored
support smart metering
and smart energy
market
1.5 Ease of integration into Desirable 2 Scored
metering/home products
– e.g. system on chip,
antenna size
1.6 Scope to accommodate Must Have NA Ranked
specific GB smart
metering requirements
Interoperability
2.1 Status as an Open Must Have NA Ranked
Standard – accessibility,
defined standards,
range of participants,
proven certification
process
2.2 Support for choice of Desirable 2 Scored
data exchange format
2.3 Genuine choice and Desirable 3 Scored
competition between
silicon vendors
2.4 Interoperable chipsets Must Have NA Boolean
2.5 Effort required to update Desirable 2 Ranked
standards to meet
specific GB
requirements (less effort
= higher score)
2.6 No. of nodes supported Desirable 2 Scored
for each HAN,
assuming minimum
capability of 3.
Power
3.1 Consumption/Peak Desirable 3 Scored
Current/Power Failure
Management
3.2 Low Power Routing – Must Have NA Scored
support for battery
powered nodes, but
also for energy smart
metering application
(e.g. data refreshes in
minutes rather than

12
only: (Boolean,
3 = Very Ranked,
2 = Fairly Scored)
1 = Less)
hours/days for end
nodes)
Data Performance
4.1 Transmission speed – Desirable 2 Scored
effective data
throughput in kbps per
channel
4.2 Robustness (retry Desirable 2 Scored
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 Desirable 3 Ranked
or non-amplified)
5.2 Suitability for GB meter Desirable 3 Scored
locations (consider
internal/external,
stone/concrete, metal
meter cabinets, meter
rooms etc.)
5.3 Vulnerability to signal Desirable 2 Scored
interference
5.4 Ability to cope with Desirable 3 Scored
signal interference
5.5 Blocking Immunity in Desirable 2 Scored
transceiver
Security
6.1 Strength/resilience of Desirable 3 Ranked
methods used
6.2 Ability to use Desirable 2 Scored
rolling/successive keys
6.3 Support for Must Have NA Scored
distinguishing
public/private data, and
for keeping
gas/water/electricity
data independently
secure – i.e. supports 3
different suppliers for 3
utilities (and any other
authorised party data
secure)
Future Resistance
7.1 Support for “over the Must Have NA Scored
air” upgrades of ‘smart

12
only: (Boolean,
3 = Very Ranked,
2 = Fairly Scored)
1 = Less)
meter’ nodes – i.e. gas
+ electricity meters & in
home display
7.2 Support for security Desirable 2 Scored
upgrades
7.3 Support for backwards Must Have NA Scored
compatibility
7.4 Longevity of frequency Desirable 3 Scored
7.5 Longevity of solution Must Have NA Scored
technology (minimum
expected smart meter
asset life of 15 years)
Cost Considerations
8.1 Total cost per home – 1 Desirable 2 Ranked
x 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 Scored
Failures/Reliability
Maturity
9.1 Use in equivalent smart Desirable 3 Ranked
metering deployments
9.2 Use in analogous Desirable 2 Scored
applications
9.3 Expectation of ongoing Desirable 1 Scored
required upgrades – i.e.
v2009, v2011 (fewer =
higher score?)
9.4 Capacity in vendors to Must Have NA Ranked
meet smart metering
demands (meters plus
displays and other
devices) – assume 5
year deployment to 25
million homes
9.5 Availability of non- Desirable 2 Scored
metering products that
could be relevant to
smart metering – e.g.
thermostats, display
devices
10.4 Evaluation Scorecard

Ref Criteria Bluetooth M-Bus Wavenis ZigBee ZigBee Z-
Low @ @ Wave
Energy 868MHz 2.4GHz
Key ‘M’ust Have ‘D’esirable X Only the final score (i.e. after weighting has been applied)
Weighting X will be shown in each cell of the table.
‘B’oolean, ‘R’anked,
‘S’cored X
e.g. Sample Criteria D Scores 3 Scores Scores Scores Scores Scores
out of 5: 0 out 4 out of 5 out of 2 out of 1 out
3 3x3= 9 of 5: 5: 5: 5: of 5:
S 0x3= 0 4x3= 12 5x3= 15 2x3= 6 1x3= 3
1.1 Low level of energy D
customer 3
intervention/support S
required to maintain
communications
1.2 Ease of installation – M
i.e.
discovery/configuration 4
at meter
installation S
1.3 Minimise number of
site visits to
address local
communications
issues – i.e. recovery
or remote correction
on failure/upgrade
failure – will include
MTBF and power
consumption on meter
battery as
considerations
1.4 Development tools to
support smart
metering and smart
energy market
1.5 Ease of integration into
metering/home
products – e.g. system
on chip, antenna size
1.6 Scope to
accommodate specific
GB smart metering
requirements
2.1 Status as an Open
Standard –
accessibility, defined
standards, range of
participants, proven
certification process
2.2 Support for choice of
data exchange format

Low @ @ Wave
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
Current/Power Failure
Management
3.2 Low Power Routing –
support for battery
powered nodes, but
also for energy smart
metering application
(e.g. data refreshes in
minutes rather than
hours/days for end
nodes)
4.1 Transmission speed –
effective data
throughput in kbps per
channel
4.2 Robustness (retry
mechanisms,
acknowledgements,
minimised/nil message
loss – i.e. latency and
dropped packets)
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

Low @ @ Wave
transceiver
6.1 Strength/resilience of
methods used
6.2 Ability to use
rolling/successive keys
6.3 Support for
distinguishing
public/private data,
and for keeping
gas/water/electricity
data independently
secure – i.e. supports
3 different suppliers for
3 utilities (and any
other authorised party
data secure)
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 15 years)
8.1 Total cost per home –
1 x electricity meter, 1
x gas meter with
battery, 1 x home
display unit = 3
chipsets + additional
battery cost
8.2 Mean Time Between
Failures/Reliability
9.1 Use in equivalent
smart metering
deployments
9.2 Use in analogous
applications
9.3 Expectation of ongoing
required upgrades –
i.e. v2009, v2011
(fewer = higher
score?)
9.4 Capacity in vendors to
meet smart metering

Low @ @ Wave
demands (meters plus
displays and other
devices) – assume 5
year deployment to 25
million homes
9.5 Availability of non-
metering products that
could be relevant to
smart metering – e.g.
thermostats, display
devices
10.4.1 Evaluation Notes

In order to provide a complete record of the evaluation process, any notes and
explanatory text are shown in the table below.
Ref Solution Score Notes/Explanation
e.g. Solution X 5 800 million devices sold in 2007
10.5 Last Mile Evaluation

Whilst not part of the core considerations and requirements for the Local
Communications Development Group, the potential role that low power radio
technology could play in supporting WAN communications is an important
consideration for the overall smart metering project.
The scoring for these specific criteria does not form part of the overall
evaluation results, but are recorded here to support any ongoing WAN
communications developments.
10.5.1 Last Mile Criteria

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

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
metering deployments
for last mile
connectivity
LM6 Range of ‘upstream’
WAN physical media
supported by data
concentrators
10.5.3 Last Mile Evaluation Notes

Ref Solution Score Notes/Explanation
e.g. Solution X 0 Not currently used for Last Mile WAN activity
10.6 Evaluation Results

Criteria Types Bluetooth M-Bus Wavenis ZigBee ZigBee Z-
Low @ @ Wave
Fit With Requirements
Interoperability
Power
Data Performance
Radio Performance
Security
Future Resistance
Cost
Criteria Types Bluetooth M-Bus Wavenis ZigBee ZigBee Z-

Low @ @ Wave
Maturity
Must Have Criteria
Desirable – 3
Desirable – 2
Desirable – 1
Total Score
10.7 Evaluation Issues Table

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

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

activity – average could constitute WiFi + DECT + 2 Cellular Phones, harsh
could include proximity to a Tetra pad.
Premise Size: 3 Bedroom, 3 Reception, Domestic Semi-Detached House, 100sqm
Level Wall Type Meter Locations Interference
One Brick External, adjacent Average
Two Foil Insulated External, remote Average
Three Internal, adjacent Average
Four High
Five Harsh
11 Recommendation
[Placeholder for recommendation of the group. Will include any relevant notes,
issues or comments as required by the group]
[At the 2nd September meeting it was agreed that the recommendation should
include a clear recommendation for field testing of solutions in typical British
installations. Clarity relating to suggesting the ‘Who’, ‘How’ and ‘When’ for this
testing may be agreed at subsequent meetings]
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
The initial group workshop discussed the
ability of a meter to support the
replication of ‘WAN’ functionality locally,
typically by a meter operator when WAN
communications has failed.
This may be challenging if Local
Communications supports a restricted set
of functionality with regard to data and
commands.
I.2 Data Ownership & Privacy
Use of mesh networks outside premises
could raise data ownership and data
transfer questions – i.e. Supplier X
receives data from Meter A via Meter B,
which is supplied by Supplier Z
I.3 Additional Network Requirement? To be discussed by the Group
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?
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 As requested at first http://tinyurl.com/6ymjgo
studies on meeting of Local Comms
meter data Development Group
collection
WELMEC As stated at first meeting [reference to materials required]
guidelines on of Local Comms
power Development 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 Detailed report on wireless http://tinyurl.com/5jumeu
Network networks, including a
Report technical comparison of
ZigBee and ANT networks
ZigBee & WiFi Report by Schneider http://tinyurl.com/6jucto
Coexistence Electric investigating the
Report potential interference
issues where ZigBee and
WiFi networks co-exist –
used for the discussion of
spread spectrum in 8.2
OpenHAN US specification of the Direct link to download MS Word
2008 Home requirements for document:
Area Network AMI/Smart Grid operations http://snipurl.com/openhan
System using smart meters as a
Requirements gateway to devices within
Specification a home
v1 Release
Candidate
Appendix A: Initial Field Test

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

- four printed circuit boards (two transmitters and two receivers) powered
by battery. Two boards were prepared with 868MHz radio, and two with
2.4GHz radio. In order to make the test as objective as possible the
transmitter output power on all four boards was set to the prescribed
0dBm, and the radio chips were sourced from the same company,
where the chips were manufactured using the same processes.
- Within the time and cost constraints of the project, the boards were as
closely matched as was possible.
- Each board had an LCD display to indicate a numerical interpretation of
the received signal strength.
The test that was performed:
- One board of each pair was set to transmit an encoded data word to its
counterpart. The receiving board would display a quality/signal strength
number if and only if the signal was detected and the word decoded
correctly.
- A perfect signal would display a quality number 255, and the poorest
decoded signal would display 1. Although automatic gain controls
(AGC’s) were employed in both chips, the number was a linear
representation of the size of signal reaching the receiver board.
The test was carried out at the following locations, representing a cross
section of GB housing stock:
1 Stone cottage built in 1860 which was constructed with stone and had
lathe and plaster walls.
2 Semi-detached 1960’s three bedroom with no modifications.
3 Detached Bungalow circa 1950.
4 Detached modern two story house with no modifications.
5 Detached two story house with two story extension added.
6 First floor flat where the meter was in the flat not the basement.
Within each location the electricity meter was identified and the ZigBee
transmitter was switched on and placed beside the meter. The corresponding
receiver was activated and placed at the following locations within the
dwelling:
1 Kitchen window sill.
2 Lounge occasional table.
3 Lounge fireplace mantelpiece.
4 Hallway table.
5 Master bedroom.
The results of the test are set out in the table below. A figure of 255 denotes
full reception, whilst 0 denotes no reception. There is no reference to the
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
Flat
The writers of the test report observed that:

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

1 Given that smart metering must be available to all consumers, only
868MHz could be considered at this time.
2 ZigBee data rates and available channels are less at 868MHz than at
2.4GHz, so it should be established if the available data transfer
capability of 868MHz is acceptable for ‘UK Smart’
3 An analysis of the ‘ZigBee Smart Protocol’ (pro feature set) should be

made to see if it meets the ERA requirements
4 An analysis of the ‘ZigBee Smart Protocol’ should be made to see if it
meets the ERA Wide Area Network (WAN) requirements as a common
protocol for both WAN and LAN. This would vastly simplify and
accelerate smart metering rollout in the UK.
A number of group participants responded to the paper in support of 2.4GHz,

with attendant power amplification to improve range.
The full report, and responses from group members can be viewed online at:
http://snipurl.com/lcdfieldtest

SRSM Local Communications Development 0 3

Uploaded by

Document Information

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 3

Uploaded by

Copyright:

Available Formats

SRSM and Beyond

Local Communications Development

Author(s) Simon Harrison

9.2 Frequency Considerations ................................................................59

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

1.2 Review Group & Website

Energy Retail Association Engage Consulting

1.3 Intellectual Property Rights and Copyright

2 Executive Summary and Introduction

It also includes an evaluation of solutions options and recommendations for

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

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 options discussed could be

3.1.2 Meter Functionality

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

• Remote configuration of tariffs, meter operations, upgradeable

3.1.3 Meter Location

Figure 1: Smart Meter Locations

The ERA Smart Metering Operational Framework documentation specifies

The Operational Framework includes a number of Meter Variants, usually to

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

Ongoing at the time of developing this document

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

Figure 3: SRSM Operational Framework Scope

4.2 Smart Utility Context for Local

These issues could be addressed through specification, i.e. requiring that

Shown below is a representation of the basic utility requirements for Local

Figure 4: Smart Utility Context

In this example, a water meter is included to illustrate the potential for an

4.3 Smarter Display Options Using Local

Smart meters should allow customers to access information using a number of

The success of smart metering in raising awareness of energy consumption,

Figure 5: Smart Display Context

An example could be the use of a USB dongle (and software) for a PC

A number of display applications may rely upon a service provider external to

If smart meters operated on an interoperable open standard for Local

4.4 Smart Home Context

As shown below, a number of ‘green’ and other applications could be

Figure 6: Smart Home Context

Display Device ‘Cluster’ Utility Meters

White Goods/Demand Response ‘Cluster’

Figure 7: Smart Home Context & Clusters

A further suggested use context for Local Communications would be where a

Alongside price and consumption

HAN interactions with non-

3rd Parties Suppliers

All communications, WAN and

5.1 A National Standard