srsm local communications development 0 2

8/14/2019 SRSM Local Communications Development 0 2

1/52

SRSM and Beyond

Local Communications Development

Author(s) Simon HarrisonDocument

Status

Draft

Document Ref.No.

SRSM LCD

DocumentVersion

0_2

Date Issued 10 March 2008


2/52

SRSM and Beyond Local Communications Development Version 0_2

Page 2 of 52 11-Mar-08

Table of ContentsTable 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


3/52



10.2.1 Evaluation Matrix Notes ............................................................ 49 11 Issues .................................................................................................. 50 12 References .......................................................................................... 51 Appendix: Schedule [X] of Operational Framework ....................................... 52

FiguresFigure 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


4/52



Document Control1.1 Version History

Version Date Author Description OnlineVersion0_1 7 February

2008SimonHarrison

Initial draft Download

ViewOnline

0_2 10 March2008

SimonHarrison

Updated following initialmeeting of developmentgroup:- restructuring of

content

- format of document toassist with commentand development

- corrections andadditions throughout

Please note that due tothe scale and scope of thechange from 0_1 to 0_2,the updates are notchange marked.

Change marking will bestandard practice for allsubsequent versions.

v0_2 also includeschanges made to theonline version of thedocument by JohnCowburn of PRI, andmaterials provided off lineby Dave Baker ofMicrosoft and Brian Backof LPRA

Download

ViewOnline

This document is a development of Schedule H of the Smart MeteringOperational Framework Proposals and Options v1 document thedevelopment history of which is shown below.Version Date Author Description0.1 17th July 2007 Simon Harrison Initial draft based upon original consolidated

SRSM Communications Solution Optionsdocument.

0.2 25th July 2007 Alastair

Manson

Minor update following review

0.3 6th August 2007 Simon Harrison Update for Operational Framework publication0.4 December 2007 Simon Harrison Updated following consultation exercise.


5/52



Updated following project workshopUpdated following receipt of related papers fromstakeholders

1.2 Review GroupThis document has been developed with the assistance of a group ofinterested 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 CopyrightAll rights including copyright in this document or the information contained in itare owned by the Energy Retail Association and its members. These materialsare made available for you to review and to copy for the purposes ofparticipating in Smart Meter Operational Framework discussions only. Allcopyright and other notices contained in the original material must be retainedon any copy that you make. All other use is prohibited.

Unless you are a person participating in the Smart Meter OperationalFramework discussions you are not permitted to view or use this document orany information contained in this document in any way whatsoever.All other rights of the Energy Retail Association and its members are reserved.

1.4 DisclaimerThis document presents proposals and options for the operation of smartmetering in Great Britain. It does not present a complete and final frameworkfor the operation of smart metering in Great Britain and the proposals oroptions presented do not represent all possible solutions. We have usedreasonable endeavours to ensure the accuracy of the contents of thedocument but offer no warranties (express or implied) in respect of itsaccuracy or that the proposals or options will work. To the extent permitted bylaw, the Energy Retail Association and its members do not accept liability forany loss which may arise from reliance upon information contained in thisdocument. This document is presented for information purposes only andnone of the information, proposals and options presented herein constitutesan offer.


6/52



2 Executive Summary and Introduction2.1 Executive Summary[Overview and Explanation of the exercise and the scale of the document tobe added when appropriate.]

2.2 PurposeThis document presents the context, requirements, issues and solutionsoptions for two-way Local Communication for smart Metering Systems.

It also includes a specimen view of a final schedule proposal for inclusion inthe Smart Metering Operational Framework.

Any statement of preference for particular communications solution optionsdoes not constitute a firm or binding decision by the Suppliers participating inthe SRSM project.

Further information on the SRSM project is available from:www.energy-retail.org/smartmeters .

2.3 ScopeThe scope of this document is limited to the requirement for two waycommunications between smart gas and electricity meters and local devices.

For ease of understanding and application to a familiar domestic context, thisdocument refers mainly to the Home and uses illustrations of houses torepresent locations for meter points. However, the communications solutionoptions listed here could apply equally to non-domestic premises i.e. LocalCommunications within an office or factory.

This document references, but does not define, the opportunity to use theLocal Communications capability of a smart meter to provide a Last Mileoption to deliver WAN Communications.

This document does not address the commercial issues arising fromcommunications requirements.

2.4 ObjectiveThe objective of the Local Communications Development exercise is to fullydocument and evaluate the options relating to Local Communications forsmart metering, and if possible to produce a solution recommendation (orrecommendations) and draft schedule to the ERA SRSM Steering Group.

2.5 Structure of this DocumentThe sections of this document are:- Section 1 Document Control


7/52



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

- Section 6 Solution Options presentation of options using a standard proforma

- Section 7 Network Protocol Options information relating to specificaddressing requirements

- Section 8 Frequency Options presentation of information relating towireless frequencies

- Section 9 Data Exchange Format Options information relating to dataformatting options

- Section 10 Evaluation Options including a scoring matrix comparing

solution options against set criteria. Also includes usage profiles to assistwith evaluation.- Section 11 Issues as identified during the development of this report- Section 12 References to relevant materials and resources- Appendix Draft specification


8/52



3 Glossary & Conventions3.1 Document Conventions

3.1.1 Meter LocationThroughout, this document refers mainly to the Home and uses illustrationsof houses to represent locations for meter points. However, smart meters andthe communications solution options listed here could apply equally to otherdomestic and non-domestic premises types.

Figure 1: Smart Meter Locations

The Operational Framework specifies domestic-sized metering, and suchmeters could be installed in any type of property where energy consumption iswithin the load/capacity capability of such meters.

The Operational Framework includes a number of Meter Variants, usually toaccommodate specific energy supply requirements of a metering point e.g.polyphase electricity supply or a semi concealed gas meter location (seedefinition of Meter Variant below). Local Communications, unless specificallyexcluded by the Meter Variant definition in the Operational Framework, isrequired in all Meter Variants.

It is also the case that the placement and location of meters as shown indiagrams is illustrative.

3.1.2 Meter and Metering SystemThroughout this document, references to a smart meter, particularly withindiagrams, should not be interpreted as referring only to smart meters where allof the functionality is contained within one box. There is regular use of apicture of an electricity smart meter to represent smart Metering Systems.


9/52



Smart MeteringSystems, with allthe functionality,

includingcommunicationsunder the glass

Metering Systemusing a separate

black box (or boxes) to deliver functionality

Metering Systemusing a separateblack box and

external antennato deliver

functionality

Illustration of how fuels could share(with suitable commercial

arrangements) a single set of blackbox(es) to deliver functionality

Smart Metering Systems Illustration of Flexible Approaches

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 metersor retrofitted to existing); or - external hardware components shared between fuels.

Generally, no component of the smart Metering System will be reliant upon equipmentowned by the customer (e.g. broadband router), or services under the control of thecustomer (e.g. telephony provider). There may be individual circumstances where use of thecustomers equipment is unavoidable (customer chooses to own the meter, or particularlywithin a non-domestic context where additional energy supply contractual terms can beapplied).

Software

Figure 2: Smart Metering Systems, Illustration of Flexible Approaches

As defined below, a smart metering system could comprise a number ofphysical devices (external modems, antennas etc.) to deliver the smartfunctionality requirements.

The potential variety of physical locations and conditions of metering pointscould result in smart metering systems where components are not locatedtogether in the same metering cupboard, or on the same metering board. Itwould not be practical to illustrate or explain these potential variations withinthis document.

Therefore all general references to smart meters and uses of icons torepresent smart meters in this document should be inferred as meaning thedefined Metering System.


10/52


Page 10 of 52 11-Mar-08

3.2 GlossaryA number of these definitions are necessarily drawn directly from the SmartMetering Operational Framework, as they apply across the scope of thatdocument and not just to Local Communications.Term Meaning

Access Control The method by which the Operational Framework controlsaccess to smart Metering Systems, smart metering data andassociated devices.

Authorised Party Means the Supplier or another person authorised byconfiguration of the Access Control security policies in theMetering System to interrogate or configure the MeteringSystem.Authorised Parties could include a communications serviceprovider, a meter operator, a network operator etc.

Data Exchange Electronic interactions including the transmission of data

between Metering Systems and Authorised Parties orMetering Systems and Local DevicesERA Energy Retail AssociationHand 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 MeteringSystem using a dedicated optical port.

Interoperability To allow a smart Metering System to be used within marketrules by the registered Supplier, its nominated agents andparties selected by the customer without necessitating a

change of Metering System.Security of the smart Metering System infrastructure, withstructured Access Control, is a key interoperabilityrequirement.

LocalCommunications

Communications between a Metering System and LocalDevices within the premises in which the Metering System isinstalled.

Local Device A Local Device can be any piece of equipment withinpremises that communicates directly with the MeteringSystem using Local Communications.

Metering System A single device or meter, or a combination of devices usedto deliver the Lowest Common Denominator as defined inthe Operational Framework Schedule L Smart MeterFunctional Specification.

Meter Variant Classification of meter type under the OperationalFramework. A Standard variant is suitable for installation atthe majority of meter points in Great Britain. Other variantsexist to cover specific supply, circuit or customer issues at asite.Examples include Polyphase, Semi-Concealed or 5Terminal 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


11/52


Page 11 of 52 11-Mar-08

Term Meaninginstallation, maintenance, investigation, replacement orremoval of the Metering System.Includes existing energy industry defined roles of MeterOperator, Meter Asset Maintainer, Meter Reader, DataRetriever etc.

Open Standard The European Union definition of an open standard (takenfrom 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 developmentoccurs on the basis of an open decision-makingprocedure available to all interested parties (consensusor majority decision etc.).

The standard has been published and the standardspecification document is available either freely or at anominal 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 availableon a royalty-free basis.

There are no constraints on the re-use of the standard.OperationalFramework

Smart Metering Operational Framework Proposals andOptions

SRSM Project Supplier Requirements of Smart Metering project.Exercise in 2006-08 undertaken by ERA to develop theOperational Framework.

Ongoing at the time of developing this documentSupplier Means an energy retail businessWAN (Wide AreaNetwork)Communications

Communications between a Metering System and a remoteAuthorised Party


12/52


Page 12 of 52 11-Mar-08

4 Local Communications ContextThis section of the document presents an overview of the LocalCommunications Development work and a number of topics and issues forconsideration.

4.1 General ContextIt is a clear requirement of the Operational Framework to implement LocalCommunications capability for smart Metering Systems.

Interoperable Local Communications capability will enable customers andSuppliers to make choices in relation to how energy consumption informationis displayed. It also supports flexibility in the options for delivering smartMetering Systems solutions and potential smart home applications.

Throughout this document applications involving water meters, TV displaysand other non-energy applications are used to illustrate the potential of smartmetering to support a range of known and as yet unknown applications.However the Local Communications solution must, first and foremost, meetthe energy requirements. Smart meters are not intended to be a fullyfunctional alternative to other residential gateway or home hub products these products tend to be capable of handling voice and multimediaapplications that would add significantly to the cost of utility meters.

The diagram below shows the SRSM project representation of the operationalarchitecture for smart metering and therefore the scope of the OperationalFramework this document specifically relates to the Local Comms sectionon the left hand side of the diagram.

D a t aT r an s

p or t

( i n t er n e

t )

I n d u s t r y

I n t e

r f a

c e s

Figure 3: SRSM Operational Framework Scope


13/52


Page 13 of 52 11-Mar-08

Please note that clip on or similar devices where information is captured via apulse counter, optical port, or by use of a sensor around an electricity cableare not considered smart under the definitions of the Operational Frameworkand are not included in this context. However, through the development of astandard for smart metering local communications, any future standalonedevices could utilize the frequencies and protocols defined by the OperationalFramework.

4.2 Smart Utility Context for LocalCommunications

The general perception of Local Communications for smart metering isbetween 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 displaydevice alongside the meter for electricity only. The manufacturer decides uponthe communications medium, the protocols and data formats used.

This one size fits all solution means that all customers get the same solutionthat works straight out of the box, usually an LCD device that is portable orfixed in a more accessible location than the meter itself.

However, having such a closed loop offering for the display of consumptioninformation 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 thesmart meter is under the control of the proprietary solution from themeter manufacturer.

In order to provide a total utility solution, the display device mustcommunicate successfully with the gas and water meters furthercompounding the potential single source/proprietary solution issue.

These issues could be addressed through specification, i.e. requiring thatprotocols are open, or available, introducing flexibility and innovation fordisplay devices.

Shown below is a representation of the basic utility requirements for LocalCommunications for smart metering:


14/52


Page 14 of 52 11-Mar-08

Figure 4: Smart Utility Context

In this example, a water meter is included to illustrate the potential for anextended network, however water metering does not form part of the SmartMetering Operational Framework at present and is included purely to illustratehow a utility context could operate.

As shown, the gas, electricity and water meters can communicate with adisplay device. Further, the gas and water meters may use the samecommunications medium to interact with the electricity meter, which could actas a hub for WAN communications for all utilities.

4.3 Smarter Display Options Using Local

CommunicationsBuilding upon the illustration above, it is a requirement of the OperationalFramework 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 ofdifferent display devices, as shown in the illustration below. The original LCDdevice in Kitchen solution remains, but is supplemented or replaced byoptions 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 theinformation available in a way that is most relevant to individual customers.


15/52


Page 15 of 52 11-Mar-08

Figure 5: Smart Display Context

The step from the illustration of a smart utility context to a smarter displaycontext is one of interoperability. As long as the energy smart meters allcommunicate using the same technology, protocols and a standard dataformat, it will be possible for display functionality to be added to a number ofdiffering delivery devices.

An example could be the use of a USB dongle (and software) for a PCallowing a customer to access sophisticated energy management informationfrom their utility meters. Currently this type of solution is being offered tocommercial customers through a wide range of proprietary offerings.

A number of display applications may rely upon a service provider external tothe home e.g. an energy management website that a customer logs on to, ora specific TV channel. In these types of application, data from smart meters isprocessed and formatted by an external party before being presented back tothe customer. As these types of display services include a remote serviceprovider, they are not within the scope of the Local Communications work.

If smart meters operated on an interoperable open standard for LocalCommunications then this level of energy management could be available to amuch wider range of customers. In this environment, Local Devices caninteroperate independent of the Metering System. For example, the water

meter could prompt the customer to call the water utility using a displaydevice.


16/52


Page 16 of 52 11-Mar-08

4.4 Smart Home ContextEstablishing an interoperable solution for Local Communications, as requiredto support customer choice for the display of consumption information, opensup a range of opportunities for energy related Local Communications.

As shown below, a number of green and other applications could besupported by or interact with smart meters. These types of automated hometechnologies are now being installed, and could become more prevalent ifthey were capable of responding to utility price triggers from smart meters, orcould utilise the WAN communications functionality that smart meters willintroduce to every home.

Figure 6: Smart Home Context

The final context illustration below presents the smart home context for thesmart metering local communications solution(s).


17/52


Page 17 of 52 11-Mar-08

Display Device Cluster

White Goods/Demand Response Cluster

Microgeneration Cluster

Utility Meters

Sensor Cluster

Figure 7: Smart Home Context & ClustersIt is not a requirement of the Smart Metering Operational Framework for smartmeters to act as a (or the) gateway for all of the devices shown in theclusters. More detail on gateways is shown in section 5 below.

The opportunity to offer services that utilise the WAN communications linkwithin a smart meter is a product of establishing an interoperable platform forLocal Communications for smart metering.

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

Figure 8: End to End Interoperability

Following feedback as a result of consulting on the Operational Framework, ithas been suggested that this One Size Fits All approach for interoperabilitymay not be appropriate. A number of potential local devices would not be


18/52


Page 18 of 52 11-Mar-08

capable of handling an XML file or supporting an IP address, or that therequirements of these standards would increase the cost of the hardware tobe used. Similarly, the transfer of information between a meter and athermostat may not be required to support the same level of data security aswould apply to the transmission of energy credit from a supplier to a meter.

The diagram below illustrates distinct solutions for Local Communications andWAN Communications in an example where:

- an energy supplier (or other party) can receive diagnostic informationfrom heating devices within a property via the electricity meter

- an energy supplier could use the smart metering link to send pricingsignals 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 theinfrastructure to the other, there may be additional requirements for the smartmeter, or the Local Communications hardware, to support the following typesof transactions.

? ? ?

Figure 10: Making Interoperability WorkFor completeness, the following diagram shows an interaction between a localdevice, in this case a water meter with Local Communications compatiblehardware, and an Authorised Party who is not an energy supplier.


19/52


Page 19 of 52 11-Mar-08

Water Supplier

Security

Protocol

Data Format

Access Control

IP

XML

Local Access Control

Local Protocol

Local Data Format

WAN CommsLocal Comms

Figure 11: Interoperability Illustration Using Water

4.6 A National StandardWhilst same solution interoperability across the scope of smart metering

might not be appropriate due to the onerous processing and protocolrequirements this could place on simple local devices, in order to ensure thatsmart metering creates an effective platform for the types of applicationspresented above, it is believed that a national standard for localcommunications is required.

This would mean that all smart meters would include hardware capable ofmeeting the local communications standard. This does not necessarily meanthe same chip/hardware in every meter, but would mean conformity in theircapability.

4.7 Delivering the Last MileFor certain topographies it may be possible for the Local Communicationshardware within smart meters to provide the Last Mile physical media forWAN Communications.

This would typically be for high density and metropolitan areas where thesignal propagation and power consumption restrictions of low power radiosolutions are less of an issue.

The SRSM project has considered the potential to use low power radio todeliver the last mile, as shown in the diagram below. This also demonstrates anumber of options for backhaul for WAN Communications, which is out ofscope for the Local Communications Development work.


20/52


Page 20 of 52 11-Mar-08

LowPower

RFType

Low Power RF to Elec

Cellular Infrastructure

D a t aT r an

s p or t

( i n t er n

e t )

Supplier X

Supplier A

Low Power RF Type

Substation

Trans-former

DataConcentrator

Low Power Radio

DataConcentrator

PLCInfrastructure

High Speed Link(Copper/Fibre)

Metering System Options

DataConcentrator

Existing telephonynetwork

Data concentrators could be installed and managed by aservice provider making use of the existing telephonynetwork.The equipment could be housed in telephony street furniture,

or any appropriate location, including potentially withincustomer premises in the form of Concentrator Meters.Data concentrators could be provided as part of theinfrastructure service, or as a separate contracted function.

A number of RFsolutions includethe capability tocreate Meshnetworks, where alarge number of nodes can becrossed to reachthe concentrator.

Figure 12: Local Communications for the Last Mile

There is no assumption that there is necessarily the same hardware within ameter for Local Communications and WAN Communications theoretically twolow power radio chips could be used, possibly at different frequencies. Anexample would be a meter that uses a ZigBee chip at 868MHz for LocalCommunications and a WiFi chip at 2.4GHz for WAN Communications.

4.8 Local Device ClassificationA topic for potential consideration is the classification of Local Devices. Assmart meters are required to be capable of 2 way communication, and energysuppliers expect display devices to be similarly capable of 2 waycommunication, the Local Communications solution(s) need(s) toaccommodate 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 meteringLocal Communications, as distinct groups. The Local Communicationssolution could recognise the classification of local devices in order todetermine the data exchange types, access control details and networkaddressing/protocols.

Finally, there may be devices capable of sending and receiving data, but thatwould not act as network repeaters in a number of topologies.

In v1 of the Operational Framework, the following categories of local deviceare proposed:


21/52


Page 21 of 52 11-Mar-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 meterfunctionality an example of this could be a diagnostic orcommissioning device to be used by a meter worker

Investigation is needed to understand whether there is a requirement forclassification of local devices, and if so, what are the recommendedclassifications and how they can be documented.

4.9 Existing StandardsPlaceholder to include any candidate standards for consideration e.g.CECED, GridWise, MultiSpeak etc. These could be published or indevelopment.

The SRSM project maintains an online reference table of globalinteroperability initiatives at: http://tinyurl.com/yta5m8


22/52


Page 22 of 52 11-Mar-08

5 Energy Supplier RequirementsShown below are the requirements taken from the ERAs Smart MeteringOperational Framework Proposals and Options, as developed sincepublication of that document in August 2007.

These requirements are classified as Mandatory/Highly Desirable/Desirable.

Ref Requirement Mandatory/Desirable

Notes

R.1 The local communicationssolution(s) will be compliant withrelevant legislation andregulations

Mandatory

R.2 There is a requirement for 2 way

communication of data betweenthe Metering System and LocalDevices

Mandatory The maximum

requirement is forintermittentcommunication betweena Metering System and aLocal Device at aconfigurable interval(every 2 minutes, everyhour, on demand etc). Agas meter using lowpower radio for LocalCommunications to anelectricity meter and

onward to a displaydevice on a half-hourinterval was still capableof a 10 year battery life.

The LocalCommunications link willalso be available as anoption to deliver WANcommunicationinformation during a sitevisit from a Meter Workerwith a suitably securedevice.In this instance, if theWAN communications isnot available, it will bepossible to exchangeinformation (meterreadings, tariff settingsetc.) through the use of aMeter Worker device.This failsafe/fallbackfacility could include theexchange of informationwith Metering Systemsusing local


23/52


Page 23 of 52 11-Mar-08


Notes

communications during asite visit or also for adrive by or walk byactivity.

R.3 The local communicationssolution(s) will require thenumber of site visits to a MeteringSystem to address issues orfailures of the communicationssolution(s) to be kept to aminimum.

HighlyDesirable

R.4 Communication to and from aMetering System will be resistantto inappropriate interference byany party including the customer.

Mandatory Inappropriate here,means inadvertent ordeliberate actions thatwould compromise theother requirements. Abalance will need to bemaintained between therequirement for securecommunications withLocal Devices, as definedin the access controlsecurity policies, and theability for customers toestablish localcommunications betweena Metering System and aLocal Device e.g.should a customer haveto call their Supplier toinform them that theyhave purchased a smartWashing Machine andwant to be able to showactual consumption costson their new LocalDevice?

R.5 The local communications

solution(s) shall be resistant toviruses and other malicioussoftware.

Mandatory

R.6 The local communicationssolution(s) will not incur any costsfor transmission of data betweena metering system and a localdevice

Mandatory Transmission of data toor from a remote party viaWAN, to link to a localdevice, could incurcommunications costs.

R.7 The local communicationssolution(s) will not alter, corruptor permanently store any data ittransports.

Mandatory

R.8 The local communicationssolution(s) under reasonable

Mandatory Quoted standard appliesto electricity metering, but


24/52


Page 24 of 52 11-Mar-08


Notes

usage profiles, will not criticallyaffect the power consumption orbattery life of a Metering Systemand will comply with EN 62053-61

principles should alsoapply to gas metering

R.9 Where a gas Metering Systemforms part of a mesh network forLocal or WAN Communications, itwill not act as a primary relaypoint.

HighlyDesirable

In order to preservebattery life

R.10 The local communicationssolution(s) will place minimumrequirements on customers forday to day operation.

Mandatory For example, beyondconfirming connection orremoval of LocalDevices, the customerwill not be expected totake action to re-establishcommunicationsfollowing any failure.

R.11 The local communicationssolution(s) will be capable ofmeeting the data trafficrequirements of the OperationalFramework.

Mandatory Data traffic requirementsremain subject toongoing developments.However, sample modelsand profiles could be builtinto this document toassist with evaluating thesolution options.

R.12 Metering System LocalCommunication will not be reliantupon hardware or equipmentunder the control of the customer

Mandatory Equipment owned orcontrolled by thecustomer could developfaults, be replaced orsimply switched off.

5.1 Other FactorsA number of factors relating to Local Communications solutions are notexplicit within the requirements shown above. These factors are containedwithin, or derived from, the overall Smart Metering Operational Frameworkand 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 theOperational Framework.Current energy Supplierexpectations, based upondiscussions with metermanufacturers, are for an assetlife of 15 years as a minimum,with equivalent battery life (foraverage usage profiles)


25/52


Page 25 of 52 11-Mar-08

Ref Factor/Statement Notes

F.2 Power consumption (linked to R.8)In order to reduce the impact of thepower consumption of smart metersthemselves, either direct consumption of

electricity or as causing a requirement forlarger, more expensive batteries withingas meters, it is a requirement to ensurethat the Local Communications solution isas energy efficient as possible.

The design of the protocol stackwill have an influence on thepower consumption of themeter particularly if there areno restrictions on the number ofattempts to send messages.

F.3 Power within Gas MetersThere have been a number of questionsabout the possibility of avoiding batteryissues within smart gas meters by usingwired power. This would allow forconsideration of a wider range ofsolutions for Local (and WAN)communications.

A number of gas appliances alreadyinclude gas and electricity components.

Some European smart meter installationsuse low power (30v) wired connections tolink gas, water, heat and electricitymeters for communications purposes.

There are key regulations and standardsrelating to gas meters and potentialexplosive atmospheres (ATEX).

Products are available to introduce twoway communications for gas meters thatdo not compromise the safety of themeters, or introduce battery life issues.

The fundamental design of a gas meteras mechanical or electronic will also be afactor in how much power it consumes.

Whilst possible (see standardbelow), gas meters that meetthe safety requirements tosupport electrical connectionsare viewed as too expensive forconsideration for mass marketdeployment.

A particular issue for GB gasmetering is the extensive use ofmeter boxes, which wouldrequire modification to meetATEX requirements.

The Institute of Gas Engineersand Managers (IGEM), at thetime of preparing thisdocument, is consulting upon

the 3rd

Edition of its standardentitled Electrical connectionsand hazardous areaclassification for gas meteringequipment.

F.4 Solution longevityThe preferred local comms solution willbe installed in metering systems with anasset life of at least 10 years, and is likelyto be required to operate for much longer.

Therefore the solution will need to becapable of remaining viable for anextended service period.Some points to consider in relation tothis:

- availability of the frequency

Selection of a solution to beused in smart metering could, ineffect, guarantee its longevityand relevance in the future.


26/52


Page 26 of 52 11-Mar-08

Ref Factor/Statement Notesselected

- resilience of the encryptionstandards as technology develops

- flexibility to support upgrades,

whilst retaining backwardscompatibilityF.5 Solution availability

It is absolutely critical that the solution isavailable for use in line with theexpectations for the installation of smartmeters. today.

The start date for smartmetering remains unclear.

A number of the solutionspresented below are new, orare subject to ongoingdevelopment.

Availability of silicon and

protocols today might notnecessarily mean that these areappropriate for use in smartmetering.

Evaluation of this requirementcould be based on availabilityvs. time to market vs. installedunits

F.6 Visiting Smart Meters (linked to R.3) A key benefit of smart meterswill be a reduction in thenumber and therefore cost offield visits to read and maintainthe meter.However, there is norequirement that smart metersshould result in an end to allvisits.e.g. Customers who use debitfunctionality extensively (dailyor more than daily) couldrequire replacement batterieswithin the expected smart meter

asset life. This would apply toabove average usage of anyfunctionality that would reducebattery life.

F.7 Single Universal Solution

See 4.6 aboveF.8 Linking/Pairing existing and new local

devices to a smart metering system to bequick, easy and secure

F.9 Number of Linked Devices Unlimited/Limit[to be discussed and agreed,alongside the implications of


27/52


Page 27 of 52 11-Mar-08

Ref Factor/Statement Notescreating parameters here]

F.10 Must not cause interference Or be interfered withF.11 Meter Operator/Worker Interface See notes for R.2 and issue I.7F.12 Ability to provide Last Mile coverage for

WAN Communications.

5.2 Potential Additional RequirementsRequirements could also be derived to support the use of LocalCommunications hardware to deliver the Last Mile link for WANCommunications.

Specific requirements for the smart metering system may also arise from theLocal Communications solution where a meter may be required to store datafor onward periodic transmission. Examples could include services configuredto transmit gas meter data on a daily basis via the electricity meter, or anannual boiler diagnostic report.

5.3 Other RequirementsPlaceholder for requirements other than those from ERA members withinSmart Metering Operational Framework. Examples could includerequirements from network operators, water companies or devicemanufacturers.


Notes

O.1

5.4 Processes/Activities RequiredIn order to document and evaluate the potential Local Communicationsolutions, understanding how those solutions will be used is important. Thiswill also assist with understanding the controls and commands that will berequired within the metering system to authorize/manage which local devicescan undertake which activities.

Within the Operational Framework, the SRSM project listed a number ofprocesses/activities that could be expected from a local device (bearing inmind 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


28/52


Page 28 of 52 11-Mar-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 SecurityRequirements R.4 and R.5 above relate to the security capabilities of LocalCommunications solutions. This section of the document illustrates andexpands on the requirements for secure Local Communications.

Due to the nature of data and functionality that will be accessible via LocalCommunications, security is a paramount concern.

Consumption and other data from a smart meter may not initially beconsidered as confidential energy tariffs are publicly available, meterreadings on their own are not personal data or at risk of increasing identitytheft. 1

However, debit balances sent from a meter to a display device could beconsidered by many customers to be personal and private. Further,consumption patterns based on interval data could allow third parties toestablish patterns of occupancy, which would very much be viewed aspersonal data.

Added to this the ability to operate metering functionality using LocalCommunications, 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 protectdata, but it is an obvious solution to the requirement. The strength ofencryption is also not specified as this tends to be a feature that varies bysolution option2.

It is accepted that no solution can be completely secure and resist all attemptsto intercept or interfere.

The Smart Metering Operational Framework v1 requires the following securitymeasures for WAN Communications:

Cryptosecurity e.g. at least 128 bit encryption using AdvancedEncryption Standard (AES).

1 The SRSM project is considering the issues surrounding ownership of smart metering datawithin 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 OperationalFramework document. Requirements (and potentially constraints) arising from the selection ofa Local Communications solution will be considered as part of the development of proposalsfor Access Control by the SRSM project.


29/52


Page 29 of 52 11-Mar-08

Emission security protecting information emanating from the MeteringSystem from intercept and analysis

Physical security safeguarding communications equipment andmaterials 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 frominterception 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 ofthese measures. However, they will be evaluated against each other on thebasis of these measures.

5.6 Independent Local NetworksShown below is a simple illustration of typical utility applications for localcommunications 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 watermeter fitted at the boundary point, and has a TV capable of displaying smartmetering information.

The house on the right differs in that there is no water meter, the gas meter islocated at the rear of the house and the preferred display solution is a portableLCD display, usually kept in the kitchen.

The illustration below shows the required links between devices.


30/52


Page 30 of 52 11-Mar-08

Figure 14: Independent Networks

The topology of the network within premises does not need to be specified, asthese could vary significantly by property type.

However, in order to deliver the necessary signal propagation to link theelectricity meter to the gas meter in the blue house, the range of LocalCommunications of the electricity meter could be as shown below.

Figure 15: Local Communication Signal Range


31/52


Page 31 of 52 11-Mar-08

This simple illustration, without allowing for signal drop off as it passes throughwalls, shows how all of the devices in the left hand house are within reach ofthe electricity meter in the right hand house. It is a requirement for theinformation from one customers metering not to be visible on theirneighbours display.

The illustration below shows how much overlap there will be between signalsfor this simple configuration of smart meters and devices. The TV display inthe 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 thanshown.

Figure 16: Overlapping Wireless Ranges

The requirement is for the Local Communications solution to deliver a networkof Local Devices for each property. It is not practical (or possible) to restrict awireless signal from each meter to the boundaries of each premises.


32/52


Page 32 of 52 11-Mar-08

Figure 17: Required Local Comms Range Example

Finally, there are circumstances where the wireless signal could be required totransfer data between properties.

The illustration below shows where communication between meters indifferent properties would be a desirable feature for Local Communications. Itis a very simple depiction of meters forming a mesh network to reach a dataconcentrator in a substation. Whilst this is effectively the WANCommunications network, it utilises the Local Communications hardware insmart meters.

Figure 18: Mesh Network to Concentrator


33/52


Page 33 of 52 11-Mar-08

5.7 Wireless to Wired[Placeholder to consider opportunity to define a standard covering wired andwireless local communications and any issues that could arise from such adetermination:

- 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 aswell as a wireless option could be beneficial to link to existing and new wireddevices and networks.

A number of appliances and networks will already exist in premises wheresmart meters are installed. Each of these systems will be operating using theirown protocols and data formats, and not necessarily interoperating. Theremay also be network capable appliances that are not yet part of any network.Examples could include white goods with capable of communicating usingCECED standards, but no wireless hardware.

It is not an ambition for smart meters to directly interact with all of thesesystems, as this would introduce complexity and cost into the metersthemselves.

Other smart metering implementations do include wired localcommunications, typically in Northern Europe. Typically these use the M Busprotocol 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 metersmakes 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 optionfor gas metering.

However, it would be beneficial for a number of non-utility systems to interactwith 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 partiesSome customers may already own and use equipment theoretically capable ofproviding a bridge between wireless and wired communications media, andwhich could include the necessary software to make data and servicesinteroperable between distinct networks and systems. The obvious example isa home PC, but broadband routers, set top boxes and games consolesalready include most of the technology to provide a link between smart metersand 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 smartmeter as part of the local network, but not necessarily communicating with allof the devices within that network as there is a WSDL/IP bridge.


34/52


Page 34 of 52 11-Mar-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 itwill not be subject to customer equipment and decisions in order to deliver theutility requirements of intra meter and energy information display processes.

It would not be reasonable to assume that every home would be equippedwith a BT Home Hub, Sky box, Xbox 360 or similar bridge capableequipment, but for those that do then smart meters could form part of theoverall connected home. Energy suppliers could choose to provide bridgeequipment to customers as part of an overall energy services package.

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

5.9 Local Communications PrinciplesFrom the detail presented above, it is possible to infer a number of keyprinciples that apply to Local Communications for smart metering:

Interoperable supporting a range of metering products and localdevice applications

Utility focus the key requirement remains the communication betweensmart meters and energy information display devices. Support for otherservices and applications will be as a result of developing a practicalsolution to the utility requirement.

Use, wherever possible, of open standards and architecture Same solution in all smart meters establishing a nationalsolution/standard


35/52


Page 35 of 52 11-Mar-08

Energy efficient Secure Future Proof/Future Flexible supporting innovation at the same time

as supporting legacy systems etc


36/52


Page 36 of 52 11-Mar-08

6 Solution OptionsThis section of the document presents a number of solution options for thehardware 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 informationto be captured.

Sections 7, 8 and 9 cover aspects of the overall solution that are relevant toLocal Communications, and which are not necessarily options or solutions.

A number of solution options support more than one network protocol, or areoffered by vendors at different frequencies. Therefore there is not always aone to one relationship between the silicon, the frequency, the protocol andthe data set supported.

In order to ensure that all potential considerations and aspects of a solutionare included in this document, details are recorded.

Solution Name

Description: A description of the solutionHardware: 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 basisData: Speed of data transfer, any limits on packet sizesPower: Points relevant to the power usage of the solution when it is

operating or dormant, and how this may effect the powerconsumption of the meter or local devices.

Frequencies: Which of the frequencies (if applicable) does the solution supportProtocols: Does the solution support a variety of protocols? Does it use a

proprietary protocol, or place requirements/restrictions on theprotocol?

DataExchangeFormat:

Does the solution support a variety of data formats? Does it use aproprietary format, or place requirements/restrictions on the dataformat?

Use in otherapplications:

Is the solution used for other purposes, i.e. not for smart metering,but for building controls, telecare, entertainment etc.

Use in othermarkets:

Has the solution been used in a smart metering context in othermarkets? Can include where the solution is being considered byother smart metering initiatives.

Maturity: Is the solution available today? If not, when will it be available?Support forLast Mile:

Capability of the solution to provide last mile coverage for WANCommunications

For: Points supporting the solution in a smart metering context

Against: Issues associated with the solution in a smart metering contextNotes: Any other notes, weblinks to relevant materials etc.


37/52


Page 37 of 52 11-Mar-08

Solutions are presented in alphabetical order.

Solution Bluetooth www.bluetooth.com

Description: Low power radio for personal area networks with up to seven

nodesHardware: Single chip radios available from a wide variety of suppliers.Cost: Circa $5 per endData: 1 MBit/secPower: High power consumption - 5000 AFrequencies: 2.4GHzProtocols:DataExchangeFormat:Use in otherapplications:

Mobile telephony

Use in othermarkets:Maturity: Several years oldSupport forLast Mile:For:Against: Poor range and propagation

Only supports 8 nodesNotes:

Solution HomePlug www.homeplug.org

Description: An open standard for powerline communications developed by aconsortium of companies

Hardware: Command and Control is available from Renesas, or Ytran chipsetplus line coupling devices

Cost: Circa $8 per endData: 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 tometering due to its low cost.

Power:Frequencies: Wired SolutionProtocols: Open standardDataExchangeFormat:


38/52


39/52


Page 39 of 52 11-Mar-08

Standard available as EN 13757Hardware:Cost:Data: Wired M-Bus data transmission speed is very lowPower:Frequencies: 868MHzProtocols:DataExchangeFormat:Use in otherapplications:Use in othermarkets:

Wireless M-Bus used for German heat cost allocators.

Proposed usage of wireless M-Bus in Germany, Austria and theNetherlands.

Maturity:Support forLast Mile:For:Against: Issues relating to the interoperability of the standard and elements

from the overall architecture are not yet resolved.Notes: http://www.m-bus.com/

Pending EN 13757-5 supports the use of repeaters/relays.

Solution WiFi www.wi-fi.org

Description:Hardware:Cost:Data: Up to and beyond 54mb/sPower: Power consumption is very high compared to other options.Frequencies: 2.4GHz

Protocols:DataExchangeFormat:Use in otherapplications:

Many existing solutions already used in homes for internetconnections.

Use in othermarkets:Maturity:Support for

Last Mile:For:


40/52


Page 40 of 52 11-Mar-08

Against: Complex network configuration.Does not support mesh networks.

Notes:

Solution ZigBee www.zigbee.org

Description: Silicon based protocol operating on the IEEE 802.15.4 standard forphysical 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 encryptionHardware: Radio chips available from Ember, ST, TI, Freescale, Renesas,

JennicCost: Circa $5 per end (total BoM)Data: Between 20 and 40 kbit/s at 868MHz (improved by 2006 revision

of 802.15.4 to 100 to 250 kbit/s?)250 kbit/s at 2.4GHz

Power: Varies by individual chip typical average is 1A.

Examples:- Ember EM250 operates at between 35 and 41 milliAmps withouta power amplifier. With a power amplifier it will operate at 100milliAmps when transmitting. When awake but not transmittingpower consumption is 7 milliAmps. When asleep powerconsumption is less than 1A.

ZigBee devices come in two flavours for power consumption routers and end devices.Routers are expected to operate continuously to support and drivethe mesh network and therefore require a constant source of

power.End Devices are battery powered radios that only come to lifewhen required to transmit or receive information. Usage profiles frequency of transmission and the size of those transmissions - willdetermine the eventual battery requirements.

Frequencies: 868MHz or 2.4GHzProtocols: ZigBee with Smart Energy ProfileDataExchangeFormat:

Specified in the ZigBee Smart Energy Profile which can be addedto if required.


41/52


Page 41 of 52 11-Mar-08

Use in otherapplications:

Total ZigBee node and chipset units 5 million in 2006, 120 millionin 20113

Home automation, telecoms (local)Use in othermarkets:

Maturity: Smart Energy Profile due for release March 2008, ZigBee ProStack available January 2008

Support forLast Mile:

With relevant power amplification, ZigBee at 2.4 GHz can operateat a range of 1km line of sight in open air, which is reducedmarkedly when there are things in the way.

For: Already in use for Home Automation applications, adopted byNorth American, Swedish and Australian utilities for smartmetering applications and all the major meter manufacturers willhave products available by Q2 2008

Against:

Notes:

Solution Z Wave www.z-wave.com

Description: Standard developed and supplied exclusively by Zensys.

Supports a maximum of 237 nodes.Hardware:Cost:Data:Power: Approximate range of 60 feet indoors.Frequencies: 868MHzProtocols:DataExchangeFormat:Use in otherapplications:Use in othermarkets:Maturity:Support forLast Mile:For:Against: Is a proprietary standard.

Questions relating to support for security requirements.Notes:

[please add any additional tables as required]

[should we include:

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


42/52


Page 42 of 52 11-Mar-08

- ANT 2.4GHz, very low power (10 years on a watch battery), 1 millionnodes in operation but proprietary,www.thisisant.com

- SimpliciTI -TI Website- EkaNet -www.ekasystems.com- Coronis -www.coronis.com- Wibree -www.wibree.com- Wireless HART 2.4GHz, Open Standard, MAC addressing

www.hartcomm2.org- etc ?]


43/52


Page 43 of 52 11-Mar-08

7 Network Protocol OptionsPlaceholder to document the potential protocols that could be used for LocalCommunications networks. A number of these may be specifically linked tothe 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 oneIP 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]


44/52


Page 44 of 52 11-Mar-08

8 Frequency ConsiderationsPlaceholder to capture and discuss the available licensed and unlicensedwireless frequency options for local communications.

In general, propagation degrades as frequency increases, but specificexamples/tests should be included where possible.

8.1 Frequency Information

Frequency 169MHz

Description: Licensed bandUsed by/for: Paging band, delegated to AMRSignal

Propagation:

[need to add range claims and real world results]

Powerrequirements:

Efficient power per distance

Longevity offrequencyallocation:Notes: No chipsets currently available for 2-way communications it is

used for 1-way communication only

Frequency 184MHz

Description: Licensed bandUsed by/for:SignalPropagation:

[need to add range claims and real world results]

Powerrequirements:

Efficient power per distance

Longevity offrequencyallocation: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 communicationsrequirements with existing products (new chip sets would need tobe developed)

Frequency 433-434MHz

Description: Unlicensed bandUsed by/for: Well used frequency, typically used for car key fobs.

Has been used for heat metering in EuropeSignal

Propagation:

Good

[need to add range claims and real world results]Power More battery efficient than higher frequency options


45/52


Page 45 of 52 11-Mar-08

requirements:Longevity offrequencyallocation:Notes: Support (by existing chips) for open standards is not evident

Security may be an issue (e.g. for financial transactions)

Frequency 868-870MHz

Description: Unlicensed European bandUsed by/for: Z-Wave, M Bus, ZigBee.

Minimal usage in other applicationsSignalPropagation:

Good[need to add range claims and real world results]

Powerrequirements:Longevity offrequencyallocation:Notes: Supports 3 channels.

Regulations prevent use of frequency for communications outsideof a property i.e. could not form a mesh of smart meters in astreet to connect to a data concentrator.Transmit duty cycle limited to 1%, or works on listen beforetransmit basis.Less attractive to higher bandwidth applications.

Frequency 2.45GHz

Description: Unlicensed worldwide bandUsed by/for: ZigBee, WiFi, Bluetooth, Microwave Ovens, Home Video repeatersSignalPropagation:

Compromised by building construction[need to add range claims and real world results]

Longevity offrequencyallocation:Notes: Use of spread spectrum to manage 16 available channels

No limits on transmit duty cycle[please add any additional tables or information as required]

8.2 Spread SpectrumPlaceholder to discuss properties of spread spectrum and channel usage asdone, for example, by 2.4GHz devices.


46/52


Page 46 of 52 11-Mar-08

9 Data Exchange Format OptionsPlaceholder to document the potential data exchange format options thatcould be used for Local Communications. A number of these may bespecifically linked to the physical media solution.

DataExchangeFormat

Obis/Cosem

Description: Definition of standardised metering objects (Electricity, Water,Heat, and Gas Metering covered)

Used by/for: Commonly used in Electricity metering in Europe, gaining adoptionelsewhere in metering

For: Standardised, EN13757-1 (Communication Systems for metersand remote reading of meters -Part 1:Data Exchange)

Against:Notes: Parts of the standard are used in MBUS implementations.

DataExchangeFormat

Obix

Description:Used by/for:For:

Against:Notes:

DataExchangeFormat

XML

Description:Used by/for: Global standard for data exchanges, used in an increasing number

of areasFor:

Against: Use of XML for local communications could place an unacceptablyhigh overhead on the microcontroller itself. XML support couldeasily require more space than is typically available on low powerradio microcontrollers. Implementation is feasible, but at the cost ofadding memory and co-processors and decreasing battery life.

Notes:[please add any additional tables as required]


47/52


Page 47 of 52 11-Mar-08

10 Evaluation OptionsPlaceholder for consideration of solution options includes proposed methodfor a desktop exercise in 10.2.

Could also include real world testing opportunities such as plug fests andresults from field trials.

Completion of the information within this section will be an iterative process toestablish and refine requirements and evaluation criteria concurrently in thecontext of the available solutions.

10.1 Data Traffic ModelsTo support the evaluation of combinations of options, some basic modelling ofdata exchanges will be required.

A number of scenarios and profiles should be considered to support a range ofLocal Communications applications. These could include:

- transmission of consumption and tariff information from meter to displaydevice

- transmission of 24 hours of interval data from gas/water meter toelectricity meter

- etc

It is not envisaged that large data files will be transmitted, or streamed, usingthe Local Communications solution. However, the solution should not place anupper limit on the size of data transmissions, other solutions exist for suchapplications and should be the obvious choice.

The development exercise should create a recommendation that provides aplatform suitable for the majority of Local Devices and uses, but which doesnot constrain innovation.

10.1.1 Data Traffic ActivitiesThis section of the document presents a series of sample data traffic activitiesto assist with assessing the solution options.

Activity Ref DA1 Activity Name Meter Reading (simple)

Element Size (bits) InstancesRegister ID 10B 1Register Reading 10B 1Notes: Typical expectation for a gas meter reading Total Size 20B

[Some help to ensure were capturing the right information here would beappreciated]

Activity Ref DA2 Activity Name Meter Reading (complex)Element Size (bits) Instances


48/52


Page 48 of 52 11-Mar-08

Activity Ref DA2 Activity Name Meter Reading (complex)

Element Size (bits) InstancesRegister ID 10B 6Register Reading 10B 6

Notes: Import and export registers for an electricitymeter operating with a 3 rate tariff Total Size 120B

10.1.2 Data Traffic Usage ProfilesPlaceholder to combine activities into sample usage profiles e.g. dailymessages of interval data, weekly use of debit functionality, regular refresh ofenergy display. This will assist with assessing the suitability of solution optionsto meet typical requirements.

Profile Ref DP1 Profile Name Weekly Electricity Reading

Activity Frequency From To Total SizeDA2 Weekly Meter Supplier 120BDA6 Etc.

[Some help to ensure were capturing the right information here would beappreciated 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 thatcould be followed the group should determine the most appropriate methodhere, which could include the addition of weighting to criteria or the addressingthe concept that highest score=best solution is not as straightforward as itappears].

The table below assesses each of the solution options from section 6 againstcriteria derived from the other sections of this document.

Each solution has been assessed by the Local Communications DevelopmentGroup 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 subjectivedepending on the data available and the type of criteria being assessed:

0 No support/does not meet requirement1 Very limited support/meets little of requirement2 Limited support/meets part of requirement3 Partial support/ meets most of requirement4 Supports/meets requirement5 Fully compliant/exceeds requirement

[Note: includes examples for illustration purposes only]


49/52


Page 49 of 52 11-Mar-08

Solution

CriteriaBuoh

K MB

WiF

ZgB

ZWa

C.1 InteroperableC.2 Security features of solution

(see 5.5 for referencemeasures)

C.3 Solution is available today(see factor F.5)

5

Multiple Source Supply ChainCost of solution

Volumes deployed for smartmetering

Total Score 5 0 0 0 0 0

10.2.1 Evaluation Matrix NotesIn order to provide a complete record of the evaluation process, any notes andexplanatory text are shown in the table below.

Criteria Solution Score Notes/Explanation

C.3 Bluetooth 5 800 million devices sold in 2007C.5 KNX


50/52


Page 50 of 52 11-Mar-08

11 IssuesThe table below provides an ongoing record of issues for consideration andpotential actions to resolve.

No Issue Description Resolution Options

I.1 Data exchange from local device toremote service provider e.g. from LocalData format to WAN Data format. Doesthe format need to be consistent in orderfor a boiler diagnostic alert to reach theend recipient?Discussed in 4.5 above

I.2 Issues with meter location/property type e.g. meters in meter rooms in multi-

occupant premises.

Use of mesh network topology tosecurely transmit data.

Use of wired/wireless repeaters.I.3 Requirement R.9 needs refining to cover

the potential/commercial WAN commsissues where the two fuels are suppliedby different companies

I.4 Future flexibility how do we account forZigBee 2.0 or Z-Wave Extra? Smartmeter assets will have a useful life inexcess of 10 years, and those installed onday one should still be compatible with asmany applications as possible throughouttheir installed life.

I.5 Definition of a required network topologyfor Local Communications is the meterexpected to be a node in a network, or themaster of a network?

Potentially both a meter shouldbe the master of utilityprocesses and networks that arespecifically related to smartmetering. At the same time,smart meters should also becapable of being part of a widerconnected home network.Also need to consider what thiswould mean in relation to the lastmile.

I.6 Added by Ian Graham of Landis+GyrAs the UK market allows Customers tochange suppliers of Gas/Electricity, andthere is confidentiality of data betweendifferent suppliers, (and indeed historicalsuppliers), what requirements are therefor data segregation/encryption within theLocal Network?

Added by IanAssume that an externalindependent agent (on the LAN)is responsible for ensuring onlypermissible data is transferredin/out of the LAN/HAN

I.7 Relating to requirement R2The initial group workshop discussed theability of a meter to support the replicationof WAN functionality locally, typically bya meter operator when WANcommunications has failed.

Understand the implications of therequirement by working throughsome practical examples.


51/52


Page 51 of 52 11-Mar-08

This may be challenging if LocalCommunications supports a restricted setof functionality with regard to data andcommands.

12 ReferencesShown below are references to relevant materials and resources.

Reference Description Link

Itron case studieson meter datacollection

As requested at first meetingof Local Comms DevelopmentGroup

View Online

WELMEC

guidelines onpowerconsumption

As stated at first meeting of

Local Comms DevelopmentGroup.Defines power consumptionformetrology/communications.

[reference to materials

required]

EN 62053-61 Standard entitled Electricity MeteringEquipment ParticularRequirements Part 61 Power Consumption andVoltage Requirements

Link to IEC Page forStandard

Wireless NetworkReport Detailed report on wirelessnetworks, including atechnical comparison ofZigBee and ANT networks

View Online

ZigBee & WiFiCoexistenceReport

Report by Schneider Electricinvestigating the potentialinterference issues whereZigBee and WiFi networks co-exist used for the discussionof spread spectrum in 8.2

View Online

[please add any additional resources as relevant]


52/52


Appendix: Schedule [X] of OperationalFramework

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

This could/should just reference the standards for local communications andpotentially the data schema(s).

srsm local communications development 0 2

Documents