SRSM Local Communications Development 0 2 1 - Change Marked

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

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

10.1.1 Data Traffic Activities.................................................................. 57
Deleted: ¶
10.1.2 Data Traffic Usage Profiles ........................................................ 58 Table of Contents 2¶
10.2 Solution Evaluation Matrix ................................................................. 58 Figures 3¶
Document Control 4¶
10.2.1 Evaluation Matrix Notes ............................................................. 59 1.1 Version History 4¶
11 Issues ..................................................................................................... 60 1.2 Review Group 5¶
1.3 Intellectual Property Rights
12 References............................................................................................. 61 and Copyright 5¶
Appendix: Schedule [X] of Operational Framework......................................... 63 1.4 Disclaimer 5¶
2 Executive Summary and
Introduction 6¶
Figures 2.1 Executive Summary 6¶

2.2 Purpose 6¶
2.3 Scope 6¶
Figure 1: Smart Meter Locations ........................................................................ 8 2.4 Objective 6¶
2.5 Structure of this
Figure 2: Smart Metering Systems, Illustration of Flexible Approaches ........... 9 Document 6¶
Figure 3: SRSM Operational Framework Scope ............................................. 12 3 Glossary & Conventions 8¶
Figure 4: Smart Utility Context ......................................................................... 14 3.1 Document Conventions 8¶
3.1.1 Meter Location 8¶
Figure 5: Smart Display Context ...................................................................... 15 3.1.2 Meter and Metering
Figure 6: Smart Home Context......................................................................... 16 System 8¶
3.2 Glossary 10¶
Figure 7: Smart Home Context & Clusters....................................................... 17 4 Local Communications
Figure 8: End to End Interoperability................................................................ 17 Context 12¶
4.1 General Context 12¶
Figure 9: Distinct Local and WAN Interoperability ........................................... 18 4.2 Smart Utility Context for
Figure 10: Making Interoperability Work .......................................................... 18 Local Communications 13¶
4.3 Smarter Display Options
Figure 11: Interoperability Illustration Using Water.......................................... 19 Using Local
Figure 12: Local Communications for the Last Mile ........................................ 20 Communications 14¶
4.4 Smart Home Context 16¶
Figure 13: Simple Collection of Smart Meters and Local Devices .................. 29 4.5 One Interoperability Size
Figure 14: Independent Networks .................................................................... 30 Fits All? 17¶
4.6 A National Standard 19¶
Figure 15: Local Communication Signal Range .............................................. 30 4.7 Delivering the Last
Figure 16: Overlapping Wireless Ranges ........................................................ 31 Mile 19¶
4.8 Local Device
Figure 17: Required Local Comms Range Example ....................................... 32 Classification 20¶
Figure 18: Mesh Network to Concentrator ....................................................... 32 4.9 Existing Standards 21¶
5 Energy Supplier
Figure 19: Interoperability via Web Services Interfaces .................................. 34 Requirements 22¶
5.1 Other Factors 24¶
5.2 Potential Additional
Requirements 27¶
5.3 Other Requirements 27¶
5.4 Processes/Activities
Required 27¶
5.5 Security 28¶
5.6 Independent Local
Networks 29¶
5.7 Wireless to Wired 33¶
5.8 Addressing Protocol 34¶
5.9 Local Communications
Principles 34¶ ... [1]
6 Solution Options 36
Deleted: ¶
Figure 1: Smart Meter
Locations 8¶
Figure 2: Smart Metering
Systems, Illustration of Flexible
Approaches 9¶
Figure 3: SRSM Operational
Framework Scope 12¶
Figure 4: Smart Utility
Context 14¶
Figure 5: Smart Display
Context 15¶
Figure 6: Smart Home
Context 16¶
Figure 7: Smart Home Context
& Clusters 17¶
Figure 8: End to End
Interoperability 17¶ ... [2]
Figure 9: Distinct Local and
Deleted: 7-Apr-08
Document Control
1.1 Version
Version History
Version Date Author Description Online
Version
0_1 7 February Simon Initial draft Download
2008 Harrison
View
Online
0_2 10 March Simon Updated following initial Download
2008 Harrison meeting of development
group: View
- restructuring of Online
content
- format of document to
assist with comment
and development
- corrections and
additions throughout
Please note that due to

the scale and scope of the
change from 0_1 to 0_2,
the updates are not
change marked.
Change marking will be

standard practice for all
subsequent versions.
v0_2 also includes

changes made to the
online version of the
document by John
Cowburn of PRI, and
materials provided off line
by Dave Baker of
Microsoft and Brian Back
of LPRA
0_2_1 15 April 2008 Simon Interim Release -
Harrison Updated to include
information and a number
of comments provided
prior to 2nd meeting of Formatted: Superscript
Local Comms
Development Group
This document is a development of Schedule H of the Smart Metering

Operational Framework Proposals and Options v1 document – the
development history of which is shown below.
Deleted: 7-Apr-08
Version Date Author Description

0.1 17th July 2007 Simon Harrison Initial draft based upon original consolidated
SRSM Communications Solution Options
document.
th
0.2 25 July 2007 Alastair Minor update following review
Manson
0.3 6th August 2007 Simon Harrison Update for Operational 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

This document has been developed with the assistance of a group of
interested parties, including energy suppliers, meter manufacturers,
communications experts, interoperability experts and other stakeholders.
Details of the participants can be viewed online at: http://tinyurl.com/2cvr3g
1.3 Intellectual Property Rights and Copyright

All rights including copyright in this document or the information contained in it
are owned by the Energy Retail Association and its members. These materials
are made available for you to review and to copy for the purposes of
participating in Smart Meter Operational Framework discussions only. All
copyright and other notices contained in the original material must be retained
on any copy that you make. All other use is prohibited.
Unless you are a person participating in the Smart Meter Operational

Framework discussions you are not permitted to view or use this document or
any information contained in this document in any way whatsoever.
All other rights of the Energy Retail Association and its members are reserved.
1.4 Disclaimer
This document presents proposals and options for the operation of smart
metering in Great Britain. It does not present a complete and final framework
for the operation of smart metering in Great Britain and the proposals or
options presented do not represent all possible solutions. We have used
reasonable endeavours to ensure the accuracy of the contents of the
document but offer no warranties (express or implied) in respect of its
accuracy or that the proposals or options will work. To the extent permitted by
law, the Energy Retail Association and its members do not accept liability for
any loss which may arise from reliance upon information contained in this
document. This document is presented for information purposes only and
none of the information, proposals and options presented herein constitutes
an offer.
Deleted: 7-Apr-08
2 Executive Summary and Introduction

2.1 Executive Summary
[Overview and Explanation of the exercise and the scale of the document to
be added when appropriate.]
2.2 Purpose
This document presents the context, requirements, issues and solutions
options for two-way Local Communication for smart Metering Systems.
It also includes a specimen view of a final schedule proposal for inclusion in

the Smart Metering Operational Framework.
Any statement of preference for particular communications solution options

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

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

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

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

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

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

accommodate specific energy supply requirements of a metering point – e.g.
polyphase electricity supply or a semi concealed gas meter location (see
definition of Meter Variant below). Local Communications, unless specifically
excluded by the Meter Variant definition in the Operational Framework, is
required in all Meter Variants.
It is also the case that the placement and location of meters as shown in
diagrams is illustrative.
3.1.2 Meter and Metering System

Throughout this document, references to a smart meter, particularly within
diagrams, should not be interpreted as referring only to smart meters where all
of the functionality is contained within one ‘box’. There is regular use of a
picture of an electricity smart meter to represent smart Metering Systems.
Deleted: 7-Apr-08
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 below, a smart metering system could comprise a number of

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

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

represent smart meters in this document should be inferred as meaning the
defined Metering System.
Deleted: 7-Apr-08
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.
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.
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
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.
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
Deleted: 7-Apr-08
Page 10 of 63 15-Apr-08
Term Meaning
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.
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.
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.
Deleted: 7-Apr-08
Page 11 of 63 15-Apr-08
4 Local Communications Context

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

It is a clear requirement of the 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
Deleted: 7-Apr-08
Page 12 of 63 15-Apr-08
Please note that ‘clip on’ or similar devices where information is captured via a
pulse counter, optical port, or by use of a sensor around an electricity cable
are not considered smart under the definitions of the Operational Framework
and are not included in this context. However, through the development of a
standard for smart metering local communications, any future ‘standalone’
devices could utilize the frequencies and protocols defined by the Operational
Framework.
4.2 Smart Utility Context for Local

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

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

Communications for smart metering:
Deleted: 7-Apr-08
Page 13 of 63 15-Apr-08
Figure 4: Smart Utility Context
In this example, a water meter is included to illustrate the potential for an

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

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

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

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

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

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

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

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

supported by ‘or interact with’ smart meters. These types of automated home
technologies are now being installed, and could become more prevalent if
they were capable of responding to utility price triggers from smart meters, or
could utilise the WAN communications functionality that smart meters will
introduce to every home.
Figure 6: Smart Home Context
The final context illustration below presents the smart home context for the
smart metering local communications solution(s).
Deleted: 7-Apr-08
Page 16 of 63 15-Apr-08
Figure 7: Smart Home Context & Clusters

It is not a requirement of the Smart Metering Operational Framework for smart
meters to act as a (or ‘the’) gateway for all of the devices shown in the
clusters. More detail on gateways is shown in section 5 below.
The opportunity to offer services that utilise the WAN communications link
within a smart meter is a product of establishing an interoperable platform for
Local Communications for smart metering.
4.5 One Interoperability

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

has been suggested that this ‘One Size Fits All’ approach for interoperability
may not be appropriate. A number of potential local devices would not be
Deleted: 7-Apr-08
Page 17 of 63 15-Apr-08
capable of handling an XML file or supporting an IP address, or that the

requirements of these standards would increase the cost of the hardware to
be used. Similarly, the transfer of information between a meter and a
thermostat may not be required to support the same level of data security as
would apply to the transmission of energy credit from a supplier to a meter.
The diagram below illustrates distinct solutions for Local Communications and
WAN Communications in an example where:
- an energy supplier (or other party) can receive diagnostic information
from heating devices within a property via the electricity meter
- an energy supplier could use the smart metering link to send pricing
signals or demand management information to heating devices
Figure 9: Distinct Local and WAN Interoperability
However, where the approach is not common from one end of the
infrastructure to the other, there may be additional requirements for the smart
meter, or the Local Communications hardware, to support the following types
of transactions.
???
Figure 10: Making Interoperability Work

For completeness, the following diagram shows an interaction between a local
device, in this case a water meter with Local Communications compatible
hardware, and an Authorised Party who is not an energy supplier.
Deleted: 7-Apr-08
Page 18 of 63 15-Apr-08
Figure 11: Interoperability Illustration Using Water
4.6 A National Standard

Whilst ‘same solution’ interoperability across the scope of smart metering
might not be appropriate due to the onerous processing and protocol
requirements this could place on simple local devices, in order to ensure that
smart metering creates an effective platform for the types of applications
presented above, it is believed that a national standard for local
communications is required.
This would mean that all smart meters would include hardware capable of
meeting the local communications standard. This does not necessarily mean
the same chip/hardware in every meter, but would mean conformity in their
capability.
4.7 Delivering the Last Mile

For certain topographies it may be possible for the Local Communications
hardware within smart meters to provide the ‘Last Mile’ physical media for
WAN Communications.
This would typically be for high density and metropolitan areas where the
signal propagation and power consumption restrictions of low power radio
solutions are less of an issue.
The SRSM project has considered the potential to use low power radio to
deliver the last mile, as shown in the diagram below. This also demonstrates a
number of options for backhaul for WAN Communications, which is out of
scope for the Local Communications Development work.
Deleted: 7-Apr-08
Page 19 of 63 15-Apr-08
Data Transport
(internet)
Figure 12: Local Communications for the Last Mile
There is no assumption that there is necessarily the same hardware within a

meter for Local Communications and WAN Communications – theoretically two
low power radio chips could be used, possibly at different frequencies. An
example would be a meter that uses a ZigBee chip at 868MHz for Local
Communications and a WiFi chip at 2.4GHz for WAN Communications.
4.8 Local Device Classification

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

are proposed:
Deleted: 7-Apr-08
Page 20 of 63 15-Apr-08
- Data Device: a device which requires access to smart meter data only
- Communicating Device: a device which requires access to remote party
only
- Fully Functional Device: a device requiring access to the smart meter
data, and remote parties, and that could also operate smart meter
functionality – an example of this could be a diagnostic or
commissioning device to be used by a meter worker
Investigation is needed to understand whether there is a requirement for

classification of local devices, and if so, what are the recommended
classifications and how they can be documented.
4.9 Existing Standards

Placeholder to include any candidate standards for consideration – e.g.
CECED, GridWise, MultiSpeak etc. These could be published or in
development.
The SRSM project maintains an online reference table of global

interoperability initiatives at: http://tinyurl.com/yta5m8
Deleted: 7-Apr-08
Page 21 of 63 15-Apr-08
5 Energy Supplier Requirements

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

Desirable
R.1 The local communications Mandatory
solution(s) will be compliant with
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 Deleted: 7-Apr-08
Page 22 of 63 15-Apr-08

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?
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.
R.8 The local communications Mandatory Quoted standard applies
solution(s) under reasonable to electricity metering, but
Deleted: 7-Apr-08
Page 23 of 63 15-Apr-08

Desirable
usage profiles, will not critically principles should also
affect the power consumption or apply to gas metering
battery life of a Metering System
and will comply with EN 62053-
61
R.9 Where a gas Metering System Highly In order to preserve
forms part of a mesh network for Desirable battery life
Local or WAN Communications, it
will not act as a primary relay
point.
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 Metering System Local Mandatory Equipment owned or
Communication will not be reliant controlled by the
upon hardware or equipment customer could develop
under the control of the customer faults, be replaced or
simply switched off.
5.1 Other Factors

A number of factors relating to Local Communications solutions are not
explicit within the requirements shown above. These factors are contained
within, or derived from, the overall Smart Metering Operational Framework
and the principles detailed within that document.
These factors are relevant for the evaluation of solution options.

Ref Factor/Statement Notes
F.1 Asset life expectation for smart meters Not explicitly stated within the
Operational Framework.
Current energy Supplier
expectations, based upon
discussions with meter
manufacturers, are for an asset
life of 15 years as a minimum,
with equivalent battery life (for
average usage profiles)
Deleted: 7-Apr-08
Page 24 of 63 15-Apr-08

F.2 Power consumption (linked to R.8) The design of the protocol stack
In order to reduce the impact of the will have an influence on the
power consumption of smart meters power consumption of the
themselves, either direct consumption of meter – particularly if there are
electricity or as causing a requirement for no restrictions on the number of
larger, more expensive batteries within attempts to send messages.
gas meters, it is a requirement to ensure
that the Local Communications solution is
as energy efficient as possible.
F.3 Power within Gas Meters Whilst possible (see standard
There have been a number of questions below), gas meters that meet
about the possibility of avoiding battery the safety requirements to
issues within smart gas meters by using support electrical connections
wired power. This would allow for are viewed as too expensive for
consideration of a wider range of consideration for mass market
solutions for Local (and WAN) deployment.
communications.
A particular issue for GB gas
A number of gas appliances already metering is the extensive use of
include gas and electricity components. meter boxes, which would
require modification to meet
ATEX requirements.
Some European smart meter installations
use low power (30v) wired connections to
link gas, water, heat and electricity The Institution of Gas Deleted: e
meters for communications purposes. Engineers and Managers
(IGEM), at the time of preparing
this document, is consulting
There are key regulations and standards
upon the 3rd Edition of its’
relating to gas meters and potential
standard entitled ‘Electrical
explosive atmospheres (ATEX).
connections and hazardous
area classification for gas
Products are available to introduce two metering equipment’.
way communications for gas meters that
do not compromise the safety of the
meters, or introduce battery life issues.
The fundamental design of a gas meter

as mechanical or electronic will also be a
factor in how much power it consumes.
F.4 Solution longevity Selection of a solution to be

The preferred local comms solution will used in smart metering could, in
be installed in metering systems with an effect, guarantee its’ longevity
asset life of at least 10 years, and is likely and relevance in the future.
to be required to operate for much longer.
Therefore the solution will need to be

capable of remaining viable for an
extended service period.
Some points to consider in relation to
this:
- availability of the frequency
Deleted: 7-Apr-08
Page 25 of 63 15-Apr-08

selected
- resilience of the encryption
standards as technology develops
- flexibility to support upgrades,
whilst retaining backwards
compatibility
F.5 Solution availability The ‘start date’ for smart
It is absolutely critical that the solution is metering remains unclear.
available for use in line with the
expectations for the installation of smart A number of the solutions
meters. today. presented below are new, or
are subject to ongoing
development.
Availability of silicon and

protocols today might not
necessarily mean that these are
appropriate for use in smart
metering.
Evaluation of this requirement

could be based on availability
vs. time to market vs. installed
units
F.6 Visiting Smart Meters (linked to R.3) A key benefit of smart meters
will be a reduction in the
number and therefore cost of
field visits to read and maintain
the meter.
However, there is no
requirement that smart meters
should result in an end to all
visits.
e.g. Customers who use debit
functionality extensively (daily
or more than daily) could
require replacement batteries
within the expected smart meter
asset life. This would apply to
above average usage of any
functionality that would reduce
battery life.
F.7 Single Universal Solution
See 4.6 above

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

creating parameters here]
F.10 Must not cause interference Or be interfered with
F.11 Meter Operator/Worker Interface See notes for R.2 and issue I.7
F.12 Ability to provide ‘Last Mile’ coverage for
WAN Communications.
5.2 Potential Additional Requirements

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

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

Mandatory/ Notes
Desirable
O.1
5.4 Processes/Activities Required

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

processes/activities that could be expected from a local device (bearing in
mind that all smart meters are themselves local devices):
- establish pairing/join network
- remove pairing/leave network
- receive data from smart meter (passive local device)
- access data from smart meter (active local device)
- update data on smart meter
- operate smart meter functionality
Deleted: 7-Apr-08
Page 27 of 63 15-Apr-08
- 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
5.5 Security
Requirements R.4 and R.5 above relate to the security capabilities of Local
Communications solutions. This section of the document illustrates and
expands on the requirements for secure Local Communications.
Due to the nature of data and functionality that will be accessible via Local
Communications, security is a paramount concern.
Consumption and other data from a smart meter may not initially be
considered as confidential – energy tariffs are publicly available, meter
readings on their own are not personal data or at risk of increasing identity
theft. 1
However, debit balances sent from a meter to a display device could be

considered by many customers to be personal and private. Further,
consumption patterns based on interval data could allow third parties to
establish patterns of occupancy, which would very much be viewed as
personal data.
Added to this the ability to operate metering functionality using Local

Communications, e.g. a meter worker configuring a meter at installation,
increases the risk of misuse or fraud by customers or third parties.
Requirement R.4 is not explicit in requiring the use of encryption to protect

data, but it is an obvious solution to the requirement. The strength of
encryption is also not specified as this tends to be a feature that varies by
solution option2.
It is accepted that no solution can be completely secure and resist all attempts
to intercept or interfere.
The Smart Metering Operational Framework v1 requires the following security

measures for WAN Communications:
• Cryptosecurity – e.g. at least 128 bit encryption using Advanced

Encryption Standard (AES).
1
The SRSM project is considering the issues surrounding ownership of smart metering data
within a separate workstream, therefore they will not be covered within this document.
2
Access Control is part of the overall smart metering architecture. It covers how access to the
meter functionality and data is controlled, and is defined in more detail in the main Operational
Framework document. Requirements (and potentially constraints) arising from the selection of
a Local Communications solution will be considered as part of the development of proposals
for Access Control by the SRSM project. Deleted: 7-Apr-08
Page 28 of 63 15-Apr-08
• Emission security – protecting information emanating from the Metering

System from intercept and analysis
• Physical security – safeguarding communications equipment and
materials from access to or observation of by unauthorised persons
• Traffic flow security – concealing the presence and properties of valid
messages on the communications network
• Transmission security – measures to protect information from
interception and exploitation by means other than decryption – e.g.
jamming, frequency hopping etc.
Not all of the solution options for Local Communications will support all of
these measures. However, they will be evaluated against each other on the
basis of these measures.
5.6 Independent Local Networks

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

electricity meter to the gas meter in the blue house, the range of Local
Communications of the electricity meter could be as shown below.
Figure 15: Local Communication Signal Range

Deleted: 7-Apr-08
Page 30 of 63 15-Apr-08
This simple illustration, without allowing for signal drop off as it passes through
walls, shows how all of the devices in the left hand house are within reach of
the electricity meter in the right hand house. It is a requirement for the
information from one customers’ metering not to be visible on their
neighbours’ display.
The illustration below shows how much overlap there will be between signals
for this simple configuration of smart meters and devices. The TV display in
the left hand house is in range of all four energy smart meters.
In reality, the range of the wireless signals is likely to be much greater than
shown.
Figure 16: Overlapping Wireless Ranges
The requirement is for the Local Communications solution to deliver a network

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

different properties would be a desirable feature for Local Communications. It
is a very simple depiction of meters forming a mesh network to reach a data
concentrator in a substation. Whilst this is effectively the WAN
Communications network, it utilises the Local Communications hardware in
smart meters.
Figure 18: Mesh Network to Concentrator
Deleted: 7-Apr-08
Page 32 of 63 15-Apr-08
5.7 Wireless
Wireless to Wired
Wired
[Placeholder to consider opportunity to define a standard covering wired and
wireless local communications and any issues that could arise from such a
determination:
- cost added to metering system
- relevance for gas meters
- interference from other utilisation of wires]
A standard/solution that includes a wired option for local communications as

well as a wireless option could be beneficial to link to existing and new wired
devices and networks.
A number of appliances and networks will already exist in premises where

smart meters are installed. Each of these systems will be operating using their
own protocols and data formats, and not necessarily interoperating. There
may also be network capable appliances that are not yet part of any network.
Examples could include white goods capable of communicating using CECED Deleted: with
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.
The illustration below is taken from a Microsoft presentation on web services

and the development of a connected ‘internet of things’, and shows a smart
meter as part of the local network, but not necessarily communicating with all
of the devices within that network as there is a ‘WSDL/IP’ bridge.
Deleted: 7-Apr-08
Page 33 of 63 15-Apr-08
Figure 19: Interoperability via Web Services Interfaces

[Placeholder to explain the interoperable software – including web services]
As previously stated, it is an absolute requirement for smart metering that it

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

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

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

From the detail presented above, it is possible to infer a number of key
principles that apply to Local Communications for smart metering:
• Interoperable – supporting a range of metering products and local
device applications
• Utility focus – the key requirement remains the communication between
smart meters and energy information display devices. Support for other
services and applications will be as a result of developing a practical
solution to the utility requirement.
• Use, wherever possible, of open standards and architecture
• Same ‘solution’ in all smart meters – establishing a national
solution/standard
Deleted: 7-Apr-08
Page 34 of 63 15-Apr-08
• Energy efficient
• Secure
• Future Proof/Future Flexible – supporting innovation at the same time
as supporting legacy systems
• etc
Deleted: 7-Apr-08
Page 35 of 63 15-Apr-08
6 Solution Options
This section of the document presents a number of solution options for the
hardware to be included as part of a smart metering system.
It uses a standard template to capture detail relating to each of the options.

This template is presented below with a description of the type of information
to be captured.
Sections 7, 8 and 9 cover aspects of the overall solution that are relevant to
Local Communications, and which are not necessarily, in and of themselves,
options or solutions.
A number of solution options support more than one network protocol, or are
offered by vendors at different frequencies. Therefore there is not always a
one to one relationship between the silicon, the frequency, the protocol and
the data set supported.
In order to ensure that all potential considerations and aspects of a solution

are included in this document, details are recorded for all candidate solutions
in the market that it was possible to document.
Solution 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
Deleted: 7-Apr-08
Page 36 of 63 15-Apr-08
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.
Formatted: Heading 2
6.1 Solution Options Descriptions

Solutions are presented in alphabetical order. Deleted: ¶
Deleted: Solution ... [3]
Solution M Bus www.m-
www.m-bus.com
Description: Solution developed in Germany to support domestic utility
metering. Supports twisted pair and wireless. Deleted: ¶
¶
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 ie, approx €5
Data: Wireless M-Bus speed at 868MHz
Wired M-Bus data transmission speed is very low Deleted: Wired M-Bus data
transmission speed is very low
Power: 5mW
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 Specification3.
markets: Wireless M-Bus used for German heat cost allocators.
Proposed usage of wireless M-Bus in Germany and Austria. Deleted: ,
Maturity: Over 80 companies have implement M-Bus in their products. Deleted: and the Netherlands.
IEC standard since 2001
Support for No, design suitable for “in home” communications
‘Last Mile’:
For: Well proven, widely deployed, 868Mhz good transmission
frequency
Against: Issues relating to the interoperability of the standard and elements
from the overall architecture are not yet resolved. Deleted: http://www.m-
bus.com/ ¶
Notes: Pending EN 13757-5 supports the use of repeaters/relays.
Formatted: Default Paragraph
Font
Formatted: Font: Italic
3 Formatted: English (U.K.)
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. Deleted: 7-Apr-08
Page 37 of 63 15-Apr-08
Solution Wavenis www.wavenis.com & www.coronis.com Field Code Changed
Description: Wavenis is a wireless connectivity platform that features Ultra Low

Power and Long Range coverage capabilities. Wavenis has been
developed by Coronis (creation in 2000) to address the most
critical applications where devices are located in hard-to-reach
places with strong energy constraints for multi-years operation.
Offers today one of the most attractive price-performances ratio.
Dedicated to remote operation for both fixed and mobile WSNs
(Wireless Sensor Networks).
Hardware: 1 - OEM cards, OEM platforms and ready-for-branding modules Formatted: Indent: Left: 0.13
(battery powered end points, autonomous range extenders, IP or cm
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 phenomenom, filter false
detections, etc …
- Receiver peak current in “full run mode” is 18mA.
- Transmitter peak current in “full run mode” in 45mA at 25mW.
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, …)
Maturity: 1,500,000 Wavenis enabled devices deployed worldwide to date
Support for 1 – 25mW low power class Wavenis modules offer 1km Line of
‘Last Mile’: Sight (LOS) thanks to -113dBm sensitivity (50kHz bandwidth
reciever) and 25mW outpout power and -3dBi helicoidal antenna.
2 – 500mW high power class Wavenis modules offer 4km range.
These modules are usually intended to range extenders for large
scale networks.
Deleted: 7-Apr-08
Page 38 of 63 15-Apr-08
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 is going to launch (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:
Note – ZigBee, at the request of group members, is presented in two iterations
to acknowledge the different aspects 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 Renesas Deleted: Ember, ST, TI,
Freescale,
Cost: Deleted: , Jennic
Data: Between 20 and 40 kbit/s at 868MHz (improved by 2006 revision Deleted: Circa $5 per end
of 802.15.4 to 100 to 250 kbit/s?) (total BoM)
Deleted: ¶
Power: Varies by individual chip – typical average is µ1A. 250 kbit/s at 2.4GHz
Deleted: ¶
ZigBee devices come in two flavours for power consumption – Examples:¶
- Ember EM250 operates at
routers and end devices. between 35 and 41 milliAmps
Routers are expected to operate continuously to support and drive without a power amplifier. With
a power amplifier it will operate
the mesh network and therefore require a constant source of at 100 milliAmps when
power. transmitting. When ‘awake’ but
not transmitting power
End Devices are battery powered radios that only come to life consumption is 7 milliAmps.
when required to transmit or receive information. Usage profiles – When ‘asleep’ power
frequency of transmission and the size of those transmissions - will consumption is less than µ1A.¶
determine the eventual battery requirements.
Frequencies: 868MHz Deleted: or 2.4GHz
Protocols: ZigBee with Smart Energy Profile

Data Specified in the ZigBee Smart Energy Profile which can be added
Exchange to if required.
Format: Deleted: 7-Apr-08
Page 39 of 63 15-Apr-08
Use in other Total ZigBee node and chipset units – 5 million in 2006, 120 million
applications: in 20114
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 Deleted: With relevant power
amplification, ZigBee at 2.4
‘Last Mile’: GHz can operate at a range of
1km line of sight in open air,
For: which is reduced markedly
when there are things in the
Against: way.
Notes: Deleted: Already in use for
Home Automation applications,
adopted by North American,
Solution ZigBee @ www.zigbee.org Swedish and Australian utilities
for smart metering applications
2.4GHz and all the major meter
Description: Open global standard developed by the ZigBee Alliance for low manufacturers will have
products available by Q2 2008
cost low power wireless mesh networking for monitoring and
control. Supported by over 225 member companies and with 19
certified vendors of stack/silicon combinations.
Based on the IEEE 802.15.4 standard MAC and PHY

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

Jennic
Cost: ~$3-$4 for SoC devices in millions of units typical
- ~$5 for SoC devices in low volume (1000-off)
- Typical BOM cost ~$6-$10 depending on volume, antenna etc.
- Modules available <$20 in low volume, <$10 in high volume.
- Prices likely to drop over next 2-3 years due to market maturity,
new technologies and growth.
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.
- 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
4
In-Stat Market Research “ZigBee 2007: What it Iz and What it Iz not” Deleted: 7-Apr-08
Page 40 of 63 15-Apr-08
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:
Use in other Total ZigBee node and chipset units – 5 million in 2006, 120 million
applications: in 20115
Home automation, telecoms (local)
Use in other 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.
5
In-Stat Market Research “ZigBee 2007: What it Iz and What it Iz not” Deleted: 7-Apr-08
Page 41 of 63 15-Apr-08
- Commercial Building Automation, including lighting and heating

control (e.g. TAC/Schneider, Siemens) and fire and safety.
- Industrial control such as ball valve monitoring/control (Eltav)
- Health monitoring products are in early stages of development.
- Niche markets such as marine electronics (e.g. Raymarine)
Geographically, ZigBee has products all around the world.
Maturity: The ZigBee Alliance was formed in 2002. ZigBee was first
released as a standard in December 2004. Since then there have
been 2 major releases of the standard, one in 2006 and the most
recent, adding ZigBee PRO features in 2007. With a number of
products now certifying for Home Automation, Manufacturer
Specific and Smart Energy, ZigBee 2007 is regarded now as
mature.
A number of vendors of ZigBee silicon have had customers with

products in the market for a number of years with earlier variants of
ZigBee stacks. It is generally accepted that about 10 million
ZigBee chips were sold worldwide for inclusion in products in
2007.
Support for ZigBee is well suited to last mile communications because of many
‘Last Mile’: features;
- Scalability of the mesh network allows for many hundreds or
thousands of devices in a single network, communicating across
multiple hops from source to destination.
- Robust communications is provided through retry mechanisms.
- Security can be added, even to the point of having individual
application link keys between electricity meters and the
concentrator.
- A network that makes use of powered devices to provide a mesh
while facilitating battery powered end devices is entirely suitable to
metering systems for electricity, gas and water.
- Excellent bandwidth available at 2.4GHz to provide not only for
AMR and configuration data, but also perhaps other data in the
future, such as alarms or health monitoring of elderly.
- 16 channels at 2.4GHz provide scope for further increased
availability of bandwidth as different networks in the same area
can occupy different channels.
- Excellent range can be achieved within regulations, up to 1Km
line of sight has been shown.
There are a number of examples of the use of ZigBee in last mile

communications for AMR already, the most notable in Europe
being the City of Gothenburg project currently being installed for
gas and electricity meters in Sweden. A number of meter
manufacturers have already implemented AMR systems using
ZigBee.
For: - Open Global Standard, supported by 225 companies and 19
stack/silicon solutions
- A new technology that is mature and accepted by the smart
energy community, yet future proof
- Cost-effective technology that will become even more cost
effective in the next 2-3 years
- Suitable for local communications AND last mile communications,
opening up the possibility of a single communications chip in smart
meters covering both!
- Robust, secure, scalable mesh networking Deleted: 7-Apr-08
Page 42 of 63 15-Apr-08
- Good bandwidth availability for a monitoring and control network,

some scope for future use
- A number of working ZigBee Smart Energy products in the
market and arriving into the market in 2008
Against: - Perception of issues with propagation in buildings , however
building construction effects all wireless technologies and can be
shown not to be an issue with ZigBee at 2.4GHz in most situations.
When there are propagation issues these can usually be mitigated
by use of the ZigBee mesh network.
- Perception of interference issues with other 2.4GHz wireless
technologies, in particular 802.11b/g/n. While there is some basis
for concerns they have been satisfactorily addressed by the
standard, and tested in independent studies (ref: “ZigBee / WiFi
Coexistence Report” by Gilles Thonet and Patrick Allard-Jacquin,
Schneider Electric, 29/01/2008)
Notes:
Solution Z Wave www.z-

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

Hardware:
Cost: BOM cost of the chip (SoC) without module will be $2-3 depending
on the volume, and for the entire module it will be $4-5
Data:
Power: Approximate range of 60 feet indoors.
Frequencies: 868MHz
Protocols:
Data
Exchange
Format:
Use in other Home automation in North America – 220 interoperable products
applications: available
Use in other
markets:
Maturity:
Support for
‘Last Mile’:
For:
Against: Deleted: Is a proprietary
standard.¶
Notes: Questions relating to support
for security requirements.
Deleted: 7-Apr-08
Page 43 of 63 15-Apr-08
Deleted: [please add any

6.2 Other Solution Options additional tables as required] ¶
The table below lists a number of other candidate solutions for Local Formatted: Heading 2
Communications. It gives a short description of the solution, website details

where available, and an explanation of why it is not included in the main
evaluation process.
Solution options may move from 6.2 to 6.1 and vice versa as discussions
within the development group (and iterations of this document) progress.
Solution 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 Field Code Changed
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
including in
evaluation
Solution Bluetooth Formatted: Font: Bold

Formatted: Indent: Left: 0
Description Low power radio for personal area networks with up to seven cm
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 Field Code Changed
Formatted
Reason for not Although there are a number of standards for Bluetooth, some of
including in which may include greater signal propagation and more efficient
evaluation power management, Bluetooth is viewed as too power-hungry and
not capable of sufficient range to meet the SRSM requiements.
Solution EkaNET
Description
Website www.ekasystems.com
Reason for not
including in
evaluation
Deleted: 7-Apr-08
Page 44 of 63 15-Apr-08
Solution HomePlug www.homeplug.org Formatted Table
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 Formatted: Bullets and
Numbering
- 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
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
Reason for not Emphasis on wired solutions does not match gas requirements,
including in also does not currently support secure communications
evaluation
Solution KNX Formatted: Font: Bold
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.
Deleted: 7-Apr-08
Page 45 of 63 15-Apr-08
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 Formatted: Bullets and
Numbering
• 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 Formatted: Bulleted + Level:
1 + Aligned at: 0 cm + Tab
• 3 to 5 year battery life with AAA cell after: 0.63 cm + Indent at:
0.63 cm
Website www.one-net.info
Formatted: Bullets and
Reason for not New standard, main focus appears to be battery operated devices. Numbering
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
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
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 Deleted: 7-Apr-08
Page 46 of 63 15-Apr-08
modems, a low-power wireless network can cover large

geographical areas using the licence-free frequency band at 2,45
GHz. The self-configuring and self-healing properties of the
6LoWPAN network offer redundancy and low maintenance cost.
Website
Reason for not Very new
including in
evaluation
Solution SimpliciTI
Description
Website TI Website
Reason for not
including in
evaluation
Solution Wibree (Ultra Low Power Bluetooth) Formatted: Font: Bold

Formatted: Font: Bold
Description Protocol designed to support small devices, gives example of
equivalency to watch batteries in power consumption.
Operates at 2.4GHz, with a range of 5-10 metres, and a data rate of

1 Mbps.
Initial interoperability profiles have been developed for watches,

sensors and human interface devices.
Website www.wibree.com
Reason for not Immature solution, may not provide signal range required by smart
including in metering.
evaluation
Solution WiFi Formatted: Font: Bold
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.
Solution Wireless HART Formatted: Font: Bold
Description 2.4GHz, Open Standard, MAC addressing

Website www.hartcomm2.org
Reason for not
including in
evaluation
Deleted: 7-Apr-08
Page 47 of 63 15-Apr-08
- EkaNet - www.ekasystems.com Deleted: [should we include: ¶

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

Placeholder to document the potential protocols that could be used for Local
Communications networks. A number of these may be specifically linked to
the physical media solution.
Protocol IPv6
Description:
Used by/for:
For: IPv6 is likely to be the preferred protocol for WAN
Communications.
Potential to use a simple version of IP – STM.

Against: Headers and Footers for IP add significantly to the data packet
size. It would take in excess of 50 ZigBee packets to transmit one
IP packet (and this would result in 50 acks)
Notes:
Protocol IPv4
Description:
Used by/for:
For:
Against:
Notes:
Protocol 6lopan
Description:
Used by/for:
For:
Against:
Notes:
[please add any additional tables as required]
Deleted: 7-Apr-08
Page 49 of 63 15-Apr-08
8 Frequency Considerations
Placeholder to capture and discuss the available licensed and unlicensed
wireless frequency options for local communications.
General principles with regard to frequency bands:

• Higher frequency means shorter wavelength Formatted: Bullets and
Numbering
• 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.
Deleted: In general,
propagation degrades as
frequency increases, but
8.1 Frequency Information specific examples/tests should
be included where possible.
Frequency 169MHz
Description: Licensed band
Used by/for: Paging band, delegated to AMR
Signal [need to add range claims and real world results]
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 [need to add range claims and real world results]
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)
Deleted: 7-Apr-08
Page 50 of 63 15-Apr-08
Frequency 433-
433-434MHz
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: [need to add range claims and real world results]
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-
868-870MHz
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
Power Has well defined maximum duty cycles and transmission powers
requirements: (5mW to 25mW).
Longevity of
frequency
allocation:
Notes: Supports 3 channels.
Current GB regulations prevent use of frequency for Deleted: R
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.45
2.45GHz
Description: Unlicensed worldwide ISM band
Used by/for: ZigBee, WiFi, Bluetooth, Microwave Ovens, Home Video repeaters
Signal Compromised by building construction
Power
Requirements:
Longevity of
frequency
allocation:
Notes: Use of spread spectrum and other techniques to manage 16
available channels
No limits on transmit duty cycle
[please add any additional tables or information as required]
Deleted: 7-Apr-08
Page 51 of 63 15-Apr-08

8.2 Licensed or Unlicensed Numbering
An ideal solution for smart metering would be to use a licensed band. This Formatted: Normal
would guarantee the availability of interference-free bandwidth for many years.
However, the current licensed band for metering in the UK, 184MHz, only
supports one-way communications, operates at a frequency unique to this
country, and has therefore not attracted solution providers in any significant
numbers.
Use of a licensed band for local communications could also restrict the
number of devices within a home that would be capable of communicating
with a meter.
The unlicensed ISM bands do support two way communications, do have

active and growing markets for radio transceivers, and these are the bands
being selected for smart metering and AMI implementations in other markets.
The volumes of silicon chips being sold for these bands make the unit cost
much lower than those for licensed bands ($3 vs. £70)6.
The use of unlicensed bands does come with the risk of interference from
other devices as they establish themselves at particular frequencies. The
2.4GHz band already includes microwave ovens, Bluetooth, Wi-Fi, TV signal
repeaters and more. However, there are a number of techniques in use to
allow devices to co-exist effectively within frequency bands.
Numbering
8.3 Spread Spectrum
Placeholder to discuss properties of spread spectrum and channel usage as
done, for example, by 2.4GHz devices.
Formatted: Heading 2
8.4 Local Communications Group Field Test

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

- four printed circuit boards (two transmitters and two receivers) powered Formatted: Bullets and
Numbering
by battery. Two boards were prepared with 868MHz radio, and two with
2.4GHz radio. In order to make the test as objective as possible the
transmitter output power on all four boards was set to the prescribed
0dBm, and the radio chips were sourced from the same company,
where the chips were manufactured using the same processes.
- Within the time and cost constraints of the project, the boards were as
closely matched as was possible.
- Each board had an LCD display to indicate a numerical interpretation of
the received signal strength.
6 Formatted: English (U.K.)
Technical Architecture for UK Domestic Smart Meter Systems, Alistair Morfey, Cambridge
Consultants 2007 Deleted: 7-Apr-08
Page 52 of 63 15-Apr-08
The test that was performed:

- One board of each pair was set to transmit an encoded data word to its Formatted: Bullets and
Numbering
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 Formatted: Bullets and
Numbering
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. Formatted: Numbered +
Level: 1 + Numbering Style: 1,
2, 3, … + Start at: 1 +
Within each location the electricity meter was identified and the ZigBee Alignment: Left + Aligned at:
transmitter was switched on and placed beside the meter. The corresponding 0.63 cm + Tab after: 1.27 cm
+ Indent at: 1.27 cm
receiver was activated and placed at the following locations within the
dwelling:
Formatted: Numbered +
1 Kitchen window sill. Level: 1 + Numbering Style: 1,
2 Lounge occasional table. 2, 3, … + Start at: 1 +
3 Lounge fireplace mantelpiece. Alignment: Left + Aligned at:
0.63 cm + Tab after: 1.27 cm
4 Hallway table. + Indent at: 1.27 cm
5 Master bedroom. Formatted: Centered
Formatted: Font: 10 pt
The results of the test are set out in the table below. A figure of 255 denotes
Formatted Table
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 Formatted: Centered
relative performance for the two frequencies. Formatted: Font: 10 pt

Formatted: Centered
Location Kitchen Lounge 1 Lounge 2 Hallway Bedroom Formatted ... [7]
2.4 868 2.4 868 2.4 868 2.4 868 2.4 868
Formatted: Font: 10 pt
Stone 35 125 85 155 70 150 50 140 50 140
Cottage Formatted ... [8]
Semi- 85 110 16 110 80 110 90 200 25 150 Formatted: Centered
Detached Formatted: Font: 10 pt
Detached 0 75 40 170 55 115 115 190 35 160
Formatted: Centered
Bungalow
Detached 2 0 20 0 50 0 50 0 30 15 80 Formatted ... [9]
Storey Formatted ... [10]
Detached 2 0 45 0 60 0 50 0 60 0 25
Formatted: Centered
Storey with
Extension Formatted ... [11]
First Floor 25 150 35 155 45 115 35 135 35 135 Formatted: Centered
Flat
Formatted ... [12]
Formatted ... [13]
The writers of the test report observed that:
1 As anticipated, the signal penetration of the 868MHz was superior to Numbering
the 2.4GHz by a factor of 2.5 on average.
Deleted: 7-Apr-08
Page 53 of 63 15-Apr-08
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 Formatted: Bullets and
Numbering
868MHz could be considered at this time.
2 ZigBee data rates and available channels are less at 868MHz than at
2.4GHz, so it should be established if the available data transfer
capability of 868MHz is acceptable for ‘UK Smart’
3 An analysis of the ‘ZigBee Smart Protocol’ (pro feature set) should be
made to see if it meets the ERA requirements
4 An analysis of the ‘ZigBee Smart Protocol’ should be made to see if it
meets the ERA Wide Area Network (WAN) requirements as a common
protocol for both WAN and LAN. This would vastly simplify and
accelerate smart metering rollout in the UK.
A number of group participants responded to the paper in support of 2.4GHz,

with attendant power amplification to improve range.
The full report, and responses from group members can be viewed online at:
http://srsmlocalcomms.wetpaint.com/page/UK+Field+Test+for+Frequency+Com
parison
Deleted: 7-Apr-08
Page 54 of 63 15-Apr-08
9 Data Exchange Format Options

Placeholder to document the potential data exchange format options that
could be used for Local Communications. A number of these may be
specifically linked to the physical media solution.
Data 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
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:
Notes:
Data Obis/Cosem
Exchange
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:
Deleted: Data Exchange
Notes: Parts of the standard are used in MBUS implementations. Format ... [14]
Data STS
Exchange
Format
Description:
Used by/for: Used in South Africa for two way data exchanges with credit and
prepayment smart meters
For:
Against:
Notes: Link - http://www.sts.org.za/resourcestudio/introductiontothests/
Deleted: 7-Apr-08
Page 55 of 63 15-Apr-08
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:
[please add any additional tables as required]
Deleted: 7-Apr-08
Page 56 of 63 15-Apr-08
10 Evaluation Options
Placeholder for consideration of solution options – includes proposed method
for a desktop exercise in 10.2.
Could also include real world testing opportunities such as plug fests and
results from field trials.
Completion of the information within this section will be an iterative process to

establish and refine requirements and evaluation criteria concurrently in the
context of the available solutions.
10.1 Data Traffic Models

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

Local Communications applications. These could include:
- transmission of consumption and tariff information from meter to display
device
- transmission of 24 hours of interval data from gas/water meter to
electricity meter
- etc
It is not envisaged that large data files will be transmitted, or streamed, using
the Local Communications solution. However, the solution should not place an
upper limit on the size of data transmissions, other solutions exist for such
applications and should be the obvious choice.
The development exercise should create a recommendation that provides a

platform suitable for the majority of Local Devices and uses, but which does
not constrain innovation.
10.1.1 Data Traffic Activities

This section of the document presents a series of sample data traffic activities
to assist with assessing the solution options.
Activity Ref DA1 Activity Name Meter Reading (simple)

Element Size (bits) Instances
Register ID 10B 1
Register Reading 10B 1
Notes: Typical expectation for a gas meter reading Total Size 20B
[Some help to ensure we’re capturing the right information here would be
appreciated]
Activity Ref DA2 Activity Name Meter Reading (complex)
Deleted: 7-Apr-08
Page 57 of 63 15-Apr-08
Activity Ref DA2 Activity Name Meter Reading (complex)

Register ID 10B 6
Register Reading 10B 6
Notes: Import and export registers for an electricity Total Size 120B
meter operating with a 3 rate tariff
10.1.2 Data Traffic Usage Profiles

Placeholder to combine activities into sample usage profiles – e.g. daily
messages of interval data, weekly use of debit functionality, regular refresh of
energy display. This will assist with assessing the suitability of solution options
to meet ‘typical’ requirements.
Profile Ref DP1 Profile Name Weekly Electricity Reading

Activity Frequency From To Total Size
DA2 Weekly Meter Supplier 120B
DA6 Etc.
[Some help to ensure we’re capturing the right information here would be
appreciated – the list of process types in 5.4 could be used as a foundation]
10.2 Solution Evaluation Matrix

[The proposal for evaluation shown below is an illustration of a process that
could be followed – the group should determine the most appropriate method
here, which could include the addition of weighting to criteria or the addressing
the concept that ‘highest score=best solution’ is not as straightforward as it
appears].
The table below assesses each of the solution options from section 6 against
criteria derived from the other sections of this document.
Each solution has been assessed by the Local Communications Development

Group against criteria agreed by the group. Where relevant, explanations of
scores are provided in the supplementary table.
Scoring is on a 0 to 5 basis, and scores assigned are objective or subjective

depending on the data available and the type of criteria being assessed:
0 No support/does not meet requirement

1 Very limited support/meets little of requirement
2 Limited support/meets part of requirement
3 Partial support/ meets most of requirement
4 Supports/meets requirement
5 Fully compliant/exceeds requirement
[Note: includes examples for illustration purposes only]

Deleted: 7-Apr-08
Page 58 of 63 15-Apr-08
Solution
Bluetooth
Z Wave
ZigBee
M Bus
KNX
WiFi
Criteria
C.1 Interoperable
C.2 Security features of solution
(see 5.5 for reference
measures)
C.3 Solution is available today 5
(see factor F.5)
Multiple Source Supply Chain
Cost of solution
Volumes deployed for smart
metering
Total Score 5 0 0 0 0 0
10.2.1 Evaluation Matrix Notes

In order to provide a complete record of the evaluation process, any notes and
explanatory text are shown in the table below.
Criteria Solution Score Notes/Explanation

C.3 Bluetooth 5 800 million devices sold in 2007
C.5 KNX
Deleted: 7-Apr-08
Page 59 of 63 15-Apr-08
11 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?
Discussed in 4.5 above
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.
I.5 Definition of a required network topology Potentially both – a meter should
for Local Communications – is the meter be the master of ‘utility’
expected to be a node in a network, or the processes and networks that are
master of a network? specifically related to smart
metering. At the same time,
smart meters should also be
capable of being part of a wider
‘connected home’ network.
Also need to consider what this
would mean in relation to the last
mile.
I.6 Added by Ian Graham of Landis+Gyr Added by Ian
As the UK market allows Customers to Assume that an external
change suppliers of Gas/Electricity, and independent agent (on the LAN)
there is confidentiality of data between is responsible for ensuring only
different suppliers, (and indeed historical permissible data is transferred
suppliers), what requirements are there in/out of the LAN/HAN
for data segregation/encryption within the
Local Network?
I.7 Relating to requirement R2 Understand the implications of the
The initial group workshop discussed the requirement by working through
ability of a meter to support the replication some practical examples.
of ‘WAN’ functionality locally, typically by
a meter operator when WAN
communications has failed. Deleted: 7-Apr-08
Page 60 of 63 15-Apr-08
This may be challenging if Local

Communications supports a restricted set
of functionality with regard to data and
commands.
I.8 From EDF Energy Formatted: Font: Italic
Metal meter cabinets (mantel units) could

adversely impact wireless signals
I.9 From EDF Energy
Use of mesh networks outside premises
could raise data ownership and data
transfer questions – i.e. Supplier X
receives data from Meter A via Meter B,
which is supplied by Supplier Z
12 References
Shown below are references to relevant materials and resources.
Reference Description Link

Itron case studies As requested at first meeting View Online
on meter data of Local Comms Development
collection Group
WELMEC As stated at first meeting of [reference to materials
guidelines on Local Comms Development required]
power Group.
consumption Defines power consumption
for
metrology/communications.
EN 62053-61 Standard entitled – Link to IEC Page for
Electricity Metering Standard
Equipment – Particular
Requirements – Part 61 –
Power Consumption and
Voltage Requirements
Wireless Network Detailed report on wireless View Online
Report networks, including a
technical comparison of
ZigBee and ANT networks
ZigBee & WiFi Report by Schneider Electric View Online
Coexistence investigating the potential
Report interference issues where
ZigBee and WiFi networks co-
exist – used for the discussion
of spread spectrum in 8.2
OpenHAN 2008 US specification of the Download Word Document
Home Area requirements for AMI/Smart
Network System Grid operations using smart
Requirements meters as a gateway to
Specification v1 devices within a home
Release
Deleted: 7-Apr-08
Page 61 of 63 15-Apr-08
Candidate
[please add any additional resources as relevant]
Deleted: 7-Apr-08
Page 62 of 63 15-Apr-08
Appendix: Schedule [X] of Operational

Framework
Placeholder for insertion of final documented standard for local
communications, including specific protocols and data exchange formats.
This could/should just reference the standards for local communications and
potentially the data schema(s).
Deleted: 7-Apr-08
Page 63 of 63 15-Apr-08
Page 3: [1] Deleted Simon Harrison 4/15/2008 7:01:00 PM
Table of Contents................................................................................................ 2
Figures ................................................................................................................ 3
Document Control ............................................................................................... 4
1.1 Version History..................................................................................... 4
1.2 Review Group ...................................................................................... 5
1.3 Intellectual Property Rights and Copyright.......................................... 5
1.4 Disclaimer............................................................................................. 5
2 Executive Summary and Introduction ......................................................... 6
2.1 Executive Summary ............................................................................. 6
2.2 Purpose ................................................................................................ 6
2.3 Scope ................................................................................................... 6
2.4 Objective .............................................................................................. 6
2.5 Structure of this Document .................................................................. 6
3 Glossary & Conventions.............................................................................. 8
3.1 Document Conventions ....................................................................... 8
3.1.1 Meter Location .............................................................................. 8
3.1.2 Meter and Metering System ......................................................... 8
3.2 Glossary ............................................................................................. 10
4 Local Communications Context ................................................................ 12
4.1 General Context ................................................................................. 12
4.2 Smart Utility Context for Local Communications .............................. 13
4.3 Smarter Display Options Using Local Communications ................... 14
4.4 Smart Home Context ......................................................................... 16
4.5 One Interoperability Size Fits All? ..................................................... 17
4.6 A National Standard........................................................................... 19
4.7 Delivering the Last Mile ..................................................................... 19
4.8 Local Device Classification................................................................ 20
4.9 Existing Standards ............................................................................. 21
5 Energy Supplier Requirements ................................................................. 22
5.1 Other Factors ..................................................................................... 24
5.2 Potential Additional Requirements .................................................... 27
5.3 Other Requirements........................................................................... 27
5.4 Processes/Activities Required........................................................... 27
5.5 Security............................................................................................... 28
5.6 Independent Local Networks ............................................................. 29
5.7 Wireless to Wired ............................................................................... 33
5.8 Addressing Protocol........................................................................... 34
5.9 Local Communications Principles ..................................................... 34
6 Solution Options ........................................................................................ 36
7 Network Protocol Options ......................................................................... 43
8 Frequency Considerations ........................................................................ 44
8.1 Frequency Information ....................................................................... 44
8.2 Spread Spectrum ............................................................................... 45
9 Data Exchange Format Options................................................................ 46
10 Evaluation Options................................................................................. 47
10.1 Data Traffic Models............................................................................ 47
10.1.1 Data Traffic Activities.................................................................. 47
10.1.2 Data Traffic Usage Profiles ........................................................ 48
10.2 Solution Evaluation Matrix ................................................................. 48
10.2.1 Evaluation Matrix Notes ............................................................. 49
11 Issues ..................................................................................................... 50
12 References............................................................................................. 51
Appendix: Schedule [X] of Operational Framework......................................... 52
Figure 1: Smart Meter Locations ........................................................................ 8

Figure 2: Smart Metering Systems, Illustration of Flexible Approaches ........... 9
Figure 3: SRSM Operational Framework Scope ............................................. 12
Figure 4: Smart Utility Context ......................................................................... 14
Figure 5: Smart Display Context ...................................................................... 15
Figure 6: Smart Home Context......................................................................... 16
Figure 7: Smart Home Context & Clusters....................................................... 17
Figure 8: End to End Interoperability................................................................ 17
Figure 9: Distinct Local and WAN Interoperability ........................................... 18
Figure 10: Making Interoperability Work .......................................................... 18
Figure 11: Interoperability Illustration Using Water ......................................... 19
Figure 12: Local Communications for the Last Mile ........................................ 20
Figure 13: Simple Collection of Smart Meters and Local Devices .................. 29
Figure 14: Independent Networks .................................................................... 30
Figure 15: Local Communication Signal Range .............................................. 30
Figure 16: Overlapping Wireless Ranges ........................................................ 31
Figure 17: Required Local Comms Range Example ....................................... 32
Figure 18: Mesh Network to Concentrator ....................................................... 32
Figure 19: Interoperability via Web Services Interfaces .................................. 34
Page 37: [3] Deleted Simon Harrison 4/9/2008 11:57:00 AM
Solution Bluetooth www.bluetooth.com
Description: Low power radio for personal area networks with up to seven
nodes
Hardware: Single chip radios available from a wide variety of suppliers.
Cost: Circa $5 per end
Data: 1 MBit/sec
Power: High power consumption - 5000µA
Frequencies: 2.4GHz
Protocols:
Data
Exchange
Format:
Use in other Mobile telephony
applications:
Use in other
markets:
Maturity: Several years old
Support for
‘Last Mile’:
For:
Against: Poor range and propagation
Only supports 8 nodes
Notes:
Solution HomePlug www.homeplug.org
Description: An open standard for powerline communications developed by a
consortium of companies
Hardware: Command and Control is available from Renesas, or Ytran chipset
plus line coupling devices
Cost: Circa $8 per end
Data: 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.
Power:
Frequencies: Wired Solution
Protocols: Open standard
Data
Exchange
Format:
Use in other Use in homes to network Ethernet devices
applications:
Use in other
markets:
Maturity: Homeplug standard is reasonably mature. Command and Control
is a recent development
Support for
‘Last Mile’:
For: Reliable communications unaffected by the building fabric.
Against: Integration with gas meters not readily available. May be affected
by electrical noise on the mains.
Notes:
Solution KNX www.knx.org
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:

Solution WiFi www.wi-
www.wi-fi.org
Description:
Hardware:
Cost:
Data: Up to and beyond 54mb/s
Power: Power consumption is very high compared to other options.
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:
Page 53: [7] Formatted Simon Harrison 4/15/2008 6:27:00 PM
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Font: 10 pt
Data Obix
Exchange
Format
Description:
Used by/for:
For:
Against:
Notes:

SRSM Local Communications Development 0 2 1 - Change Marked

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRSM Local Communications Development 0 2 1 - Change Marked

Uploaded by

Copyright:

Available Formats

SRSM and Beyond

Local Communications Development

Author(s) Simon Harrison

10.1 Data Traffic Models ............................................................................ 57

Figures 2.1 Executive Summary 6¶

Please note that due to

Change marking will be

v0_2 also includes

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

Version Date Author Description

1.2 Review Group

Details of the participants can be viewed online at: http://tinyurl.com/2cvr3g

1.3 Intellectual Property Rights and Copyright

Unless you are a person participating in the Smart Meter Operational

2 Executive Summary and Introduction

It also includes a specimen view of a final schedule proposal for inclusion in

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

Figure 1: Smart Meter Locations

The Operational Framework specifies ‘domestic-sized’ metering, and such

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

3.1.2 Meter and Metering System

Smart Metering Systems – Illustration of Flexible Approaches

The required functionality could be delivered by components:

As defined below, a smart metering system could comprise a number of

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

Figure 7: Smart Home Context & Clusters

4.5 One Interoperability

Figure 8: End to End Interoperability

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

capable of handling an XML file or supporting an IP address, or that the

Figure 9: Distinct Local and WAN Interoperability

Figure 10: Making Interoperability Work

Figure 11: Interoperability Illustration Using Water

4.6 A National Standard

4.7 Delivering the Last Mile

There is no assumption that there is necessarily the same hardware within a

4.8 Local Device Classification