SRSM Local Communications Development 0 1

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

Document Initial Draft
Status
Document Ref. SRSM LCD
No.
Document 0_1
Version
Date Issued February 2008
SRSM and Beyond – Local Communications Development Version 0_1
Table of Contents
Table of Contents.............................................................................................2
Document Control ............................................................................................3
Version History .............................................................................................3
Intellectual Property Rights and Copyright ...................................................3
Disclaimer ....................................................................................................3
Introduction ......................................................................................................5
Purpose ....................................................................................................5
Scope .......................................................................................................5
Objective...................................................................................................5
Glossary of Terms, Definitions and Abbreviations ...........................................6
Local Communications Context .......................................................................8
General Context........................................................................................8
Smart Utility Context for Local Communications .......................................8
Smarter Display Options Using Local Communications..........................10
Smart Home Context ..............................................................................11
One Interoperability Size Fits All?...........................................................13
A National Standard................................................................................14
Delivering the Last Mile...........................................................................14
Local Device Classification .....................................................................15
Existing Standards..................................................................................16
Energy Supplier Requirements ......................................................................17
Potential Additional Requirements..........................................................19
Other Requirements ...............................................................................20
Processes/Activities Required ................................................................20
Wired and/or Wireless?..................................................................................20
Frequency Options.........................................................................................21
Spread Spectrum....................................................................................22
Physical Media Solution Options....................................................................23
Network Protocol Options ..............................................................................28
Data Exchange Format Options.....................................................................29
Evaluation Options.........................................................................................30
Data Traffic Models ....................................................................................30
Issues ............................................................................................................31
Appendix: Schedule H of Operational Framework .........................................32
Page 2 of 32 7-Feb-08
Document Control
Version History
Version Date Author Description
0_1 February 2008 Simon Initial draft
Harrison
This document is a development of Schedule H of the Smart Metering

Operational Framework Proposals and Options document – the development
history of which is shown below.
Version Date Author Description
th
0.1 17 July 2007 Simon Initial draft based upon original
Harrison consolidated SRSM Communications
Solution Options document.
0.2 25th July 2007 Alastair Minor update following review
Manson
0.3 6th August 2007 Simon Update for Operational Framework
Harrison publication
0.4 December Simon Updated following consultation
2007 Harrison exercise.
Updated following project workshop
Updated following receipt of related
papers from stakeholders
Intellectual Property Rights and Copyright

All rights including copyright in this document or the information contained in it
are owned by the Energy Retail Association and its members. These materials
are made available for you to review and to copy for the purposes of
participating in Smart Meter Operational Framework discussions only. All
copyright and other notices contained in the original material must be retained
on any copy that you make. All other use is prohibited.
Unless you are a person participating in the Smart Meter Operational
Framework discussions you are not permitted to view or use this document or
any information contained in this document in any way whatsoever.
All other rights of the Energy Retail Association and its members are reserved.
Disclaimer
This document presents proposals and options for the operation of smart
metering in Great Britain. It does not present a complete and final framework
for the operation of smart metering in Great Britain and the proposals or
options presented do not represent all possible solutions. We have used
reasonable endeavours to ensure the accuracy of the contents of the
document but offer no warranties (express or implied) in respect of its
accuracy or that the proposals or options will work. To the extent permitted by
law, the Energy Retail Association and its members do not accept liability for
any loss which may arise from reliance upon information contained in this
document. This document is presented for information purposes only and
none of the information, proposals and options presented herein constitutes
an offer.
Introduction
Purpose
This document presents the context, requirements, issues and solutions
options for two-way Local Communication for smart Metering Systems.
It also includes a specimen view of a final Operational Framework schedule.
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
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

schedule 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.
Objective
The objective of the Local Communications Development exercise is to
document and evaluate the options relating to Local Communications for
smart metering, and if possible to produce a solution recommendation (or
recommendations) and draft schedule to the ERA SRSM Steering Group.
Glossary of Terms, Definitions and

Abbreviations
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.
CDU A general term used to refer to display devices that present
(Consumer Display consumption (and other) information.
Unit)
Data Exchange Electronic interactions including the transmission of data
between Metering Systems and Authorised Parties or
Metering Systems and Local Devices
ERA Energy Retail Association
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.
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 a change of
Metering System.
Security of the smart Metering System infrastructure, with
structured Access Control, is a key interoperability
requirement.
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.
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 an installed Metering System 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.
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
SRSM Project Supplier Requirements of Smart Metering project.
Exercise in 2006-08 undertaken by ERA to develop the
Operational Framework
Supplier Means an energy retail business
WAN (Wide Area Communications between a Metering System and a remote
Network) Authorised Party
Communications
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.
General Context
It is a clear requirement of the Operational Framework to implement Local
Communications capability for smart Metering Systems.
Interoperable Local Communications capability will enable customers and

Suppliers to make choices in relation to how energy consumption information
is displayed. It also supports flexibility in the options for delivering smart
Metering Systems solutions and potential ‘smart home’ applications.
The diagram below shows 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)
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.
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 typically been done in other initiatives on a proprietary basis, where
the meter manufacturer provides the display device alongside the meter. 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:
• A variety of offerings from meter manufacturers, unless all meters are
sourced from a single supplier, can lead to inconsistency in the quality,
range and accuracy of information presented and the experience of
customers.
• Customers cannot choose how energy consumption information is
displayed to them.
• Innovation in display device technology would be controlled by meter
manufacturers.
• 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 when purchasing

meters, 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:
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.
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.
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
schema, 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. 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.
Smart
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. A great deal of 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.
The final context illustration below presents the smart home context for the
smart metering local communications solution(s).
One Interoperability Size Fits All?

The initial ambition of the SRSM project was to establish an end to end
proposal for interoperable smart metering. Under this approach, the same
network protocol and data exchange format would be used to communicate
between the metering system and a local device as would be used between a
metering system and an authorized party. This is shown in the diagram below
for a proposed use where the electricity smart meter acts as a WAN
Communications host for the gas smart meter.
Following feedback as a result of consulting on the Operational Framework, it

has been suggested that this ‘One Size Fits All’ approach for interoperability
may not be technically feasible. A number of potential local devices would not
be capable of handling an XML file or supporting an IP address, or that the
requirements of these standards would increase the cost of the hardware to
be used. Similarly, the transfer of information between a meter and a
thermostat may not be required to support the same level of data security as
would apply to the transmission of energy credit from a supplier to a meter.
The diagram below illustrates distinct solutions for Local Communications and
WAN Communications in an example where:
- an energy supplier (or any other party) can receive diagnostic
information from heating devices within a property via the electricity
meter
- an energy supplier could use the smart metering link to send pricing
signals or demand management information to heating devices
However, where the approach is not common from one end of the
infrastructure to the other, there may be additional requirements for the smart
meter, or the Local Communications hardware, to support the following types

of transactions.
???
For completeness, the following diagram shows an interaction between a local
device, in this case a water meter with Local Communications compatible
hardware, and an Authorised Party who is not an energy supplier.
A National Standard
Whilst ‘same solution’ interoperability across the scope of smart metering
might not be appropriate due to the onerous requirements this could place on
simple local devices, in order to ensure that smart metering creates an
effective platform for the types of applications presented above, it is believed
that a national standard for local communications is required.
This would mean that all smart meters would include hardware capable of
meeting the local communications standard. This does not necessarily mean
the same chip/hardware in every meter.
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.
Data Transport
(internet)
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.
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 to accommodate
fully functional ‘nodes’ on a network.
There will be, however, local devices that will only send or receive data.
Examples could include:
- a fridge magnet to display consumption cost information would only
receive data
- an IR motion sensor would only send data
These types of devices could be classified, for the purposes of smart metering
Local Communications, as distinct groups. The Local Communications
solution could recognize 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
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.
Existing Standards
Placeholder to include any candidate standards for consideration – e.g.
CECED, GridWise, MultiSpeak etc. These could be published or in
development.
The SRSM project maintains an online reference table of global

interoperability initiatives at: http://tinyurl.com/yta5m8
http://tinyurl.com/yta5m8
Energy Supplier Requirements

Shown below are the requirements taken from the ERA’s Smart Metering
Operational Framework Proposals and Options, as developed since
publication of that document in August 2007.
These requirements are classified as Mandatory/Highly Desirable/Desirable
Ref Requirement Mandatory/ Notes

Desirable
R.1 The local communications Mandatory [Potential to include a
solution(s) will be compliant with list?]
relevant legislation and
regulations
R.2 There is a requirement for 2 way Mandatory The maximum
communication of data between requirement is for
the Metering System and Local intermittent
Devices communication between
a Metering System and a
Local Device at a
configurable interval
(every 2 minutes, every
hour, on demand etc). A
gas meter using low
power radio for Local
Communications to an
electricity meter and
onward to a display
device on a half-hour
interval was still capable
of a 10 year battery life.
The Local
Communications link will
also be available as an
option to deliver WAN
communication
information during a site
visit from a Meter Worker
with a suitably secure
device. In this instance, if
the WAN
communications is not
available, it will be
possible to exchange
information (meter
readings, tariff settings
etc.) through the use of a
Meter Worker device.
This failsafe/fallback
facility could include the
exchange of information
with Metering Systems
using local

Desirable
communications during a
site visit or also for a
‘drive by’ or ‘walk by’
activity.
R.3 The local communications Highly
solution(s) will require the Desirable
number of site visits to a Metering
System to address issues or
failures of the communications
solution(s) to be kept to a
minimum.
R.4 Communication to and from a Mandatory Inappropriate here,
Metering System will be resistant means inadvertent or
to inappropriate interference by deliberate actions that
any party including the customer. would compromise the
other requirements. A
balance will need to be
maintained between the
requirement for secure
communications with
Local Devices, as defined
in the access control
security policies, and the
ability for customers to
establish local
communications between
a Metering System and a
Local Device – e.g.
should a customer have
to call their Supplier to
inform them that they
have purchased a ‘smart’
Washing Machine and
want to be able to show
actual consumption costs
on their new Local
Device?
R.5 The local communications Mandatory
solution(s) shall be resistant to
viruses and other malicious
software.
R.6 The local communications Mandatory Transmission of data to
solution(s) will not incur any costs or from a remote party via
for transmission of data between WAN, to link to a local
a metering system and a local device, could incur
device communications costs.
solution(s) will not alter, corrupt
or permanently store any data it
transports.
solution(s) under reasonable

Desirable
usage profiles, will not critically
affect the power consumption or
battery life of a Metering System
and will comply with EN 62053-
61
R.9 Where a gas Metering System Highly
forms part of a mesh network for Desirable
Local or WAN Communications, it
will not act as the primary relay
point, in order to preserve battery
life.
R.10 The local communications Mandatory For example, beyond
solution(s) will place minimum confirming connection or
requirements on customers for removal of Local
day to day operation. Devices, the customer
will not be expected to
take action to re-establish
communications
following any failure.
R.11 The local communications Mandatory Data traffic requirements
solution(s) will be capable of remain subject to
meeting the data traffic ongoing developments.
requirements of the Operational However, sample models
Framework. and profiles could be built
into this document to
assist with evaluating the
solution options.
R.12 Communications between Mandatory Equipment owned or
Metering Systems and Local controlled by the
Devices will not be reliant upon customer could develop
hardware or equipment under the faults, be replaced or
control of the customer – i.e. the simply switched off.
Metering System should be self-
sufficient for Local
Communications.
Potential Additional Requirements

The following could be added as explicit requirements:
- single universal solution
- linking/pairing devices to be quick, easy and secure
- unlimited/limit to the number of linked devices
- must not cause interference
- provides solution for meter operator/worker interface
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.
Other Requirements
Placeholder for requirements of parties other than energy suppliers.

Desirable
O.1
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
Wired and/or Wireless?

Wireless?
Placeholder to consider opportunity to define a standard covering wired and
wireless local communications and any issues that could arise from such a
determination:
- cost added to metering system
- relevance for gas meters
- interference from other utilization of wires
Could also include recommendations for linking smart metering Local

Communications to existing wired (and wireless) networks – e.g. a HomePlug-
type bridge.
Frequency Options
Placeholder to capture and discuss the available licensed and unlicensed
wireless frequency options for local communications.
Will include information relating to signal propagation, power consumption,

spread spectrum, legal issues etc.
Frequency 184MHz
Description: Licensed band
Used by/for:
Signal [need to add range claims and real world results]
Propagation:
Power
requirements:
Notes:
Frequency 433MHz
Description: Unlicensed band
Used by/for: Well used frequency, typically used for car key fobs
Has been used for heat metering in Europe
Signal Good
Propagation: [need to add range claims and real world results]
Power
requirements:
Notes:
Frequency 868MHz
Used by/for: Z-Wave, M Bus, ZigBee.
Minimal usage in other applications
Signal Good
Power
requirements:
Notes: Single channel only
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.4GHz
Used by/for: ZigBee, WiFi, Bluetooth, Microwave Ovens, Home Video repeaters
Signal Compromised by building construction

Power
requirements:
Notes: Use of spread spectrum to manage 16 available channels
No limits on transmit duty cycle
[please add any additional tables as required]
Spread Spectrum
Placeholder to discuss properties of spread spectrum and channel usage as
done, for example, by 2.4GHz devices.
Physical Media 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.
Solution Name
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.
Solutions are presented in alphabetical order.
Solution Bluetooth
Description:
Hardware:
Cost:
Data:
Power: High power consumption
Frequencies: 2.4GHz
Protocols:
Data
Exchange
Format:
Use in other
applications:
Use in other
markets:
Maturity:
Support for
‘Last Mile’:
For:
Against: Poor range and propagation
Notes:
Solution HomePlug
Description:
Hardware:
Cost:
Data: Variety of transmission rates – 14MBps, 85MBps etc. actual
throughput is lower
Power:
Frequencies: Wired Solution
Protocols:
Data
Exchange
Format:
Use in other
applications:
Use in other
markets:
Maturity:
Support for
‘Last Mile’:
For:
Against: Integration with gas meters not readily available
Notes:
Solution
Solution KNX
Description: Solution developed in Germany, primarily for building automation
purposes.
Supports wired (twisted pair and power line) and wireless
Standard available as EN 50090, EN 13321-1, ISO/IEC 14543

Hardware:
Cost:
Data:
Power:
Frequencies: 868MHz
Protocols:
Data
Exchange
Format:
Use in other Significant deployment in building management and automation –
applications: is the standard used at Heathrow’s terminal 5 building.
Use in other
markets:
Maturity:
Support for
‘Last Mile’:
For:
Against:
Notes: http://www.knx.org/
Solution M Bus
Description: Solution developed in Germany to support domestic utility
metering.
Supports twisted pair and wireless.
Standard available as EN 13757

Hardware:
Cost:
Data: Wired M-Bus data transmission speed is very low
Power:
Frequencies: 868MHz
Protocols:
Data
Exchange
Format:
Use in other
applications:
Use in other Wireless M-Bus used for German heat cost allocators.
markets:
Proposed usage of wireless M-Bus in Germany, Austria and the
Netherlands.
Maturity:
Support for
‘Last Mile’:
For:
Against: Issues relating to the interoperability of the standard and elements

from the overall architecture are not yet resolved.
Notes: http://www.m-bus.com/
Pending EN 13757-5 supports the use of repeaters/relays.
Solution WiFi
Description:
Hardware:
Cost:
Data:
Power: Power consumption is high
Frequencies: 2.4GHz
Protocols:
Data
Exchange
Format:
Use in other Many existing solutions – already used in homes for internet
applications: connections.
Use in other
markets:
Maturity:
Support for
‘Last Mile’:
For:
Against: Complex network configuration.
Does not support mesh networks.
Notes:
Solution ZigBee
Description:
Hardware:
Cost:
Data:
Power: Varies by individual chip.
Examples:
- Ember EM250 operates at between 35 and 41 milliAmps without
a power amplifier. With a power amplifier it will operate at 100
milliAmps when transmitting. When ‘awake’ but not transmitting
power consumption is 7 milliAmps. When ‘asleep’ power
consumption is less than 1 microAmp.
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 or 2.4GHz
Protocols:
Data
Exchange
Format:
Use in other
applications:
Use in other
markets:
Maturity:
Support for With relevant power amplification, ZigBee at 2.4 GHz can operate
‘Last Mile’: at a range of 1km line of sight in open air, which is reduced
markedly when there are things in the way.
For:
Against:
Notes:
Solution Z Wave
Description: Standard developed and supplied exclusively by Zensys.
Hardware:
Cost:
Data:
Power:
Frequencies: 868MHz
Protocols:
Data
Exchange
Format:
Use in other
applications:
Use in other
markets:
Maturity:
Support for
‘Last Mile’:
For:
Against: Is a proprietary standard.
Questions relating to support for security requirements.
Notes:
[please add any additional tables as required] [should we include SimpliciTI,
EkaNet, Coronius etc ?]
Network Protocol Options

Placeholder to document the potential protocols that could be used for Local
Communications networks. A number of these may be specifically linked to
the physical media solution.
Protocol IP (vX)
Description:
Used by/for:
For: IP (potentially v6) 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
Protocol Etc
Description:
Used by/for:
For:
Against:
Notes:
Data Exchange Format Options

Placeholder to document the potential data exchange format options that
could be used for Local Communications. A number of these may be
specifically linked to the physical media solution.
Data Obix
Exchange
Format
Description:
Used by/for:
For:
Against:
Notes:
Data XML
Exchange
Format
Description:
Used by/for: Global standard for data exchanges, used in an increasing number
of areas
For:
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.
Notes:
Evaluation Options
Placeholder for consideration of solution options. Will need to include a
compatibility matrix covering requirements, protocols and data exchange.
Could also include real world testing opportunities such as plug fests and
results from field trials.
Data Traffic Models

To support the evaluation of combinations of options, some basic modeling of
data exchanges will be required.
A number of scenarios should be considered to support a range of Local

Communications applications. These could include:
- transmission of consumption and tariff information from meter to display
device
- transmission of 24 hours of interval data from gas/water meter to
electricity meter
- etc
It is not envisaged that large data files will be transmitted, or streamed, using
the Local Communications solution. However, the solution should not place an
upper limit on the size of data transmissions, other solutions exist for such
applications and should be the obvious choice. The development exercise
should create a recommendation that provides a platform suitable for the
majority of Local Devices and uses, but which does not constrain innovation.
Issues
The table below provides an ongoing record of issues for consideration and
potential actions to resolve.
No Issue Description Resolution Options

I.1 Data exchange from local device to
remote service provider – e.g. from Local
Data format to WAN Data format. Does
the format need to be consistent in order
for a boiler diagnostic alert to reach the
end recipient?
I.2 Issues with meter location/property type – Use of mesh network topology to
e.g. meters in meter rooms in multi- securely transmit data.
occupant premises. Use of wired/wireless repeaters.
I.3 Requirement R.9 needs refining to cover
the potential/commercial WAN comms
issues where the two fuels are supplied
by different companies
I.4 Future flexibility – how do we account for
ZigBee 2.0 or Z-Wave Extra? Smart
meter assets will have a useful life in
excess of 10 years, and those installed on
day one should still be compatible with as
many applications as possible throughout
their installed life.
Appendix: Schedule H of Operational

Framework
Placeholder for insertion of final documented standard for local
communications, including specific protocols and data exchange formats.

SRSM Local Communications Development 0 1

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 1

Uploaded by

Copyright:

Available Formats

SRSM and Beyond

Local Communications Development

Author(s) Simon Harrison

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

Intellectual Property Rights and Copyright

It also includes a specimen view of a final Operational Framework schedule.

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

Glossary of Terms, Definitions and

The full table of Meter Variants can be found in Schedule L

Local Communications Context

Interoperable Local Communications capability will enable customers and

Smart Utility Context for Local Communications

These issues could be addressed through specification when purchasing

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

Smarter Display Options Using Local Communications

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

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

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

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

One Interoperability Size Fits All?

Following feedback as a result of consulting on the Operational Framework, it

meter, or the Local Communications hardware, to support the following types

Delivering the Last Mile

Local Device Classification

In v1 of the Operational Framework, the following categories of local device

Investigation is needed to understand whether there is a requirement for

The SRSM project maintains an online reference table of global

Energy Supplier Requirements

These requirements are classified as Mandatory/Highly Desirable/Desirable

Ref Requirement Mandatory/ Notes

Ref Requirement Mandatory/ Notes

Ref Requirement Mandatory/ Notes

Potential Additional Requirements

Requirements could also be derived to support the use of Local

Ref Requirement Mandatory/ Notes

Within the Operational Framework, the SRSM project listed a number of

Wired and/or Wireless?

Could also include recommendations for linking smart metering Local

Will include information relating to signal propagation, power consumption,

Propagation: [need to add range claims and real world results]

Physical Media Solution Options

It uses a standard template to capture detail relating to each of the options.

Solutions are presented in alphabetical order.

Supports wired (twisted pair and power line) and wireless

Standard available as EN 50090, EN 13321-1, ISO/IEC 14543

Supports twisted pair and wireless.

Standard available as EN 13757

Against: Issues relating to the interoperability of the standard and elements

ZigBee devices come in two flavours for power consumption –

Network Protocol Options

Potential to use a simple version of IP – STM.

Data Exchange Format Options

Data Traffic Models

A number of scenarios should be considered to support a range of Local

No Issue Description Resolution Options

Appendix: Schedule H of Operational

You might also like