OPEN meter_D2_3_V1 0 091103

Type of document: Companion note to Deliverables D2.1, D2.2 and D2.3

Date: 05/10/09

FP7 ENERGY Project File name: IB09_OPEN meter_Official note for WP2 deliverables Version: 1.0

Companion note to Deliverables D2.1, D2.2 and D2.3 This companion note serves as an official and public communication of the Technical Board of the OPEN meter project, in order to provide clarifying notes about how to interpret the following documents

• D2.1: Description of current state-of-the-art of technology and protocols including: general overview , PLC-based access technology, wireless access technology, communication protocols and data structures

• D2.2: Assessment of potentially adequate telecommunications technologies, including: general requirements, PLC-based technologies, wireless technologies, communication protocols and data structures

• D2.3: Identification of research needs from bottom-top approach: General knowledge gaps and corresponding research needs, Knowledge gaps concerning PLC-based technologies, wireless technologies and communication protocols and data structures

in the context of the overall project: 1. There are still on-going discussions about technologies that could not be

taken into account during the current phase of work package 2. 2. MAXIM PLC technology will be considered in the next revision of the

above mentioned documents. 3. The BPSK-based PLC technology SITRED is in the process of being

opened as announced by Enel, and will be considered in the next revision of the above mentioned documents, if it becomes openly available in due time.

4. Currently, document D2.2 presents only two selected candidate technologies for each interface. The number of selected candidate technologies might be increased in the next revision, due to the rapid development of new technologies and solutions in smart metering. Therefore, new specifications might also be taken into consideration during the project timeframe, as long as these new developments are open and public and they do not interfere in the objectives of the project.

5. New versions of the above mentioned deliverables will be released during the first half of 2010, and, if necessary, the deliverables of the subsequent work packages will be updated accordingly.

6. The above mentioned deliverables serve as important input to work package 3, but are not considered an exclusive selection criterion for the following work packages. The final selection of technologies and protocols will be done within the technical work of work package 3.

OPEN meterOpen Public Extended Network meteringOPEN meterOpen Public Extended Network metering

Work Package: 2

Type of document: Deliverable Date: 3.11.2009

Energy Theme; Grant Agreement No 226369 Partners: Iberdrola, ACTARIS, ERSE, CTI, DLMS, EDF, ELSTER, ENDESA, KEMA, L&G,

RWE, STM, UKA, uSYSCOM, ZIV-Media

Responsible:

Circulation: x Public

Confidential Restricted

Title: D2.3 Version: 1.0 Page: 1 / 48

Project Funded by the European Commission under the 7th Framework Programme Project coordinated by


D 2.3

IDENTIFICATION OF RESEARCH NEEDS FROM BOTTOM-UP APPROACH

KNOWLEDGE GAPS

© Copyright 2009 The OPEN meter Consortium

DUE DELIVERY DATE: M6

ACTUAL DELIVERY DATE: 10

Work Package: 2

Type of document: Deliverable 2.3

Date: 3.11.2009

Energy Theme; Grant Agreement No 226369 Title: D2.3 Version: 1.0 Page: 2 / 48



Document History

Vers. Issue Date Content and changes

0.1 01.09.09 Initial version containing contributions from CTI, L&G and UKA

0.2 09.09.09 Second version containing DLMS/COSEM analysis

0.3 10.09.09 Third version with wireless gaps included

0.4 02.10.09 Feedback from DLMS UA on PLC included

0.5 05.10.09 Final additions to wireless technology gaps

0.6 07.10.09 Final additions to protocol gaps

1.0 3.11.09 Release approved by OPEN meter TB

Document Authors

Partners Contributors

UKA Michael Bauer

Wenqing Liu

Johannes Kallenberg

Klaus Dostert

CTI Weilin Liu

L + G Heinz Hohl

DLMS User Association Gyozo Kmethy

ERSE Diana Moneta

uSysCom Aitor Arzuaga

RWE Olaf Neumann

Andreas Wolff

Work Package: 2


Date: 3.11.2009




Document Approvers

Partners Approvers

CTI Markus BITTNER

ENDESA Robert Denda

L+G Thomas Schaub

KEMA Willem Strabbing

Iberdrola Inigo Berganza

Work Package: 2


Date: 3.11.2009




TABLE OF CONTENTS

1 PURPOSE 10 2 INTRODUCTION 10

2.1 REFERENCE ARCHITECTURE 10 3 EXECUTIVE SUMMARY 11 4 KNOWLEDGE GAPS – PLC TECHNOLOGIES 13

4.1 ANALYSIS OF GENERAL KNOWLEDGE GAPS 13 4.1.1 Gaps related to network addressing and routing 13 4.1.2 Gaps related to EN 50065 13 4.1.3 Gaps related to EMC 14

4.2 KNOWLEDGE GAPS – INTERFACE MI1-CI1 14 4.2.1 Gap Analysis for PRIME 14 4.2.2 Gap Analysis for IEC 61334-5-1 S-FSK PLC 21

5 KNOWLEDGE GAPS – WIRELESS TECHNOLOGIES 23 5.1 WIRELESS INTERFACES IN ELECTRICITY METERS ACCORDING TO OPENMETER SYSTEM

ARCHITECTURE 23 5.2 INTERFACE CI2-SI1 23

5.2.1 Gap analysis for UMTS 23 5.2.2 Gap analysis for GPRS 23

5.3 INTERFACE MI2-SI2 24 5.3.1 Gap analysis for UMTS 24 5.3.2 Gap analysis for GPRS 24

5.4 INTERFACES MI3, CI3 AND MUMI2 24 5.4.1 Gap analysis for IEEE802.15.4 24 5.4.2 Gap analysis for IEEE802.11 24

5.5 INTERFACES MUMI1-MI4 25 5.5.1 Gap analysis for IEEE802.15.4 25 5.5.2 Gap analysis for IEEE802.11 25

5.6 INTERFACE CI4 26 5.6.1 Gap analysis for ZigBee 26 5.6.2 Gap analysis for WiFi 26

5.7 INTERFACE MI5 26 5.7.1 Gap analysis for Bluetooth 26 5.7.2 Gap analysis for ZigBee 27

6 KNOWLEDGE GAPS – DATA MODELS AND “HIGHER LAYER” PROTOCOLS 28 6.1 DLMS/COSEM 28

6.1.1 Overview 28 6.1.2 Data model – COSEM 32 6.1.3 Messaging – DLMS 33

6.2 SML 37 6.2.1 Object Model 44 6.2.2 Shortcoming and development activity 44

6.3 OTHER PROTOCOLS 45 6.3.1 ZigBee SEP 45 6.3.2 KNX 46 6.3.3 IEC 61850 47

Work Package: 2


Date: 3.11.2009




7 COPYRIGHT 48 List of tables Table 3-1: Overview of selected technologies and protocols for all relevant interfaces. ...... 12 Table 6-1: Use of DLMS/COSEM over various interfaces .................................................... 29 Table 6-2: SML and the OSI layers....................................................................................... 39 Table 6-3: SML over the main OPEN-meter interfaces / media............................................ 40 Table 6-4: SML Profile for M1- C1 interface ......................................................................... 41 Table 6-5: SML profile for the MI2-SI2 interface (GPRS) ..................................................... 42 Table 6-6: SML profile for the MI4-MUIMI1 interface (RS232) ............................................. 43 Table 6-7: SML profile for M1 – MUMI1 interface (M-Bus) ................................................... 43 Table 6-8: SML profile for MI5 and MI4 interfaces................................................................ 44

LIST OF FIGURES Figure 1 – OPEN meter system architecture ........................................................................ 10 Figure 2 – DLMS/COSEM Communication profiles .............................................................. 36 Figure 3 – SML system architecture ..................................................................................... 38

Work Package: 2


Date: 3.11.2009




GLOSSARY AND ACRONYMS AC Alternating current ADSL Asymmetric DSL AES Advanced Encryption Standard AMI Advanced Metering Infrastructure AMM Automated Meter Management AMR Automated Meter Reading ANSI American National Standards Institute AVL Automatic Vehicle Location bit/s Bits per second BPL Broadband Power Line BPSK Binary Phase Shift Keying CAPEX Capital Expenditure CI Concentrator Interface CCK Complementary Code Keying CDMA Code Division Multiple Access CEN Comité Européen de Normalisation CENELEC Comité Européen de Normalisation Electrotechnique CEPCA Consumer Electronics Powerline Communications Alliance COSEM Companion Specification for Energy Metering CSD Circuit Switched Data CSMA/CA Carrier Sense Multiple Access/Collision Avoidance D-Bus Dialogue-Bus D-PSK Differential Phase Shift Keying D-2-PSK Differential 2-Phase Shift Keying D-4-PSK Differential 4-Phase Shift Keying D-8-PSK Differential 8-Phase Shift Keying DCSK Differential Code Shift Keying DHS Digitale Home Standard DFS Dynamic Frequency Selection DL Down-Link DLMS Device Language Message Specification DSL Digital Subscriber Line DSLAM DSL Access Multiplexer DSM Demand Side Management DSMR Dutch Smart Metering Requirements DSSS Direct Sequence Spread Spectrum EDGE Enhanced Data Rates for GSM Evolution EIA Electronic Industries Alliance EN European Norm ETSI European Telecommunications Institute FDD Frequency Division Duplex FEC Forward Error Correction FSK Frequency Shift Keying FTTB Fibre To The Building FTTC Fibre To The Curb FTTH Fibre To The Home FTTP Fibre To The Premsises

Work Package: 2


Date: 3.11.2009




GEO GEostationary Orbit GPRS Generalized Packet Radio service GPS Global Positioning System GSM Global System Mobile HAN Home Area Network HD-PLC High Definition PLC HDLC High-Level Data Link Control HFC Hybrid Fibre-Coaxial HSCSD High Speed Circuit Switched Data HSDPA High Speed Data Packet Access HSUPA High Speed Uplink Packet Access IEC International Electrotechnical Commission IEEE Institute for Electrical and Electronic Engineering ISDN Integrated Services Digital Network IP Internet Protocol ISM Industrial, Scientific, and Medical kbit/s Kilobit per second kHz Kilohertz KNX Konnex (standard for home and building control) LAN Local Area Network LEO Low Earth Orbit LLC Logical Link Control LOS Line-of-Sight LTE Long Term Evolution LV Low Voltage MAC Medium Access Control Mbit/s Megabit per second M-Bus Meter-Bus MI Meter Interface MUMI Multi-Utillity-Meter Interface MDM Meter Data Management MIMO Multiple Input Multiple Output MV Medium Voltage N/A Not Applicable NLOS Non-Line-of-Sight NPL Narrowband Power Line OBIS OBject Identification System OFDM Orthogonal Frequency Division Multiplex OM-CR Open MeterCommunication requirement OM-GR Open Meter General Requirement OM-ER Open Meter Economic Requirement OM-FR Open Meter Field Components Functional Requirement OM-SR Open Meter System Requirement OM-TR Open Meter Field Components Technical Requirement OPERA Open PLC European Research Alliance OPEN meter Open Public Extended Network metering OPEX Operational Expenditure OSI Open Systems Interconnection PAMR Public Access Mobile Radio

Work Package: 2


Date: 3.11.2009




PHY PHYsical layer PL Power Line PLC Power Line Communication PMR Private Mobile Radio POTS Plain Old Telephone Service PSK Phase Shift Keying PSTN Public Switched Telephone Network PWLAN Public WLAN QAM Quadrature Amplitude Modulation QoS Quality of Service QPSK Quarternary (Quadrature) Phase Shift Keying RAN Radio Access Network RF Radio Frequency RFID Radio Frequency Identification SAE System Architecture Evaluation SCADA Supervisory Control and Data Acquisition SDU Service Data Unit S-FSK Spread Frequency Shift Keying SI central System Interface SNR Signal to Noise Ratio SMS Short Message Service SRD Short Range Device TCP Transmission Control Protocol TDD Time Division Duplex TDMA Time Division Multiple Access TE Terminal Equipment TETRA TErrestrial Trunked Radio TIA Telecommunications Industry Association UDP User Datagram Protocol UHF Ultra High Frequency UL Up-Link UMTS Universal Mobile Telecommunications System UNB Ultra Narrow Band UPA Universal Powerline Association VDSL Very high speed DSL VHF Very High Frequency VLF Very Low Frequency VoIP Voice over IP WCDMA Wideband CDMA WDS Wireless Distribution System WICA Wireless Internet Compatibility Alliance WiFi Wireless Fidelity WiMAX Worldwide Interoperability for Microwave Access WLAN Wireless Local Area Network WP Work Package WPA Wi-Fi Protected Access WPAN Wireless Personal Area Network xDSL See DSL 2G 2nd Generation

Work Package: 2


Date: 3.11.2009




3G 3rd Generation 3GPP 3rd Generation Partnership Project

Work Package: 2


Date: 3.11.2009




1 PURPOSE

The purpose of this document is to provide a gap analysis for the technological alternatives, PLC and wireless technologies, protocols and data structures analysed in OPEN meter deliverable D1.1 v27, Requirements and D2.2 v1.0, Assessment.

2 INTRODUCTION

The list of identified knowledge gaps described in this document might not be complete. It can be expected that new gaps will arise during the progress of future tasks within working packages 3, 4 and 5, and in particular during the progress of task 3.1, “Initial definition of the architectural model based on OSI conceptualization”. Furthermore, and due to time and R&D constraints, it may also be the case that not all gaps, those already described in 2.3 and those that may be identified in 3.1, can be paid attention to, so prioritization will be applied by WP3 team as the best collaborative effort possible.

2.1 Reference Architecture

The system architecture specified by D1.1 is shown in Figure 1.

Figure 1 – OPEN meter system architecture

Work Package: 2


Date: 3.11.2009




3 EXECUTIVE SUMMARY The purpose of this document is to provide a gap analysis of the selected candidates. This analysis is based on OPEN meter deliverable D1.1 v27, Requirements and D2.2 v1.0, Assessment.

Note, that the intention is that D2.2 proposes generally two technologies per interface for further consideration. This document may need to be revised after a new revision of D2.2 has been released.

It is worth underline that TCP/IP will not be included as such since it is not scope of WP2 to define the complete system architecture. The possibility of using TCP/IP will be investigated in WP3 and then verified in WP4.

For most of the interfaces analyzed under the scope of the OPENMeter project, wireless technologies seem the most reasonable option for low cost, reliable communication. However, given the huge diversity among these interfaces (for instance between MI5 and CI2-SI1), several different technologies have been assessed as candidate in D2.2.

For the MI1 – CI1 interface, only PLC technologies have been selected.

Coming into detail for each of the technology / interface pairing, GPRS/UMTS have been selected as candidate technologies for “long range” interfaces (meter to central system, concentrator to central system), whereas IEEE802.15.4/Zigbee has been selected for “short range” interfaces, along with other technologies for particular interfaces. See table 3-1 for a complete relation of technologies per interface.

Regarding protocols, IEC 62056 / EN 13757-1 DLMS/COSEM and SML are generally good candidates for OPEN meter, as summarized in the following table, but they could be not easily compared, as their scope is different.

Other possible alternatives, such as IEC 61850 for external interfaces on substation level and KNX and/or Zigbee for in-home devices, will be mentioned but not included into the gap analysis.

Interface Selected

Technology Type

Selected

Technologies and lower layer protocols

Selected

Data models and upper layer protocols

MI1 – CI1 PLC PRIME

IEC 61334-5-1

DLMS

SML

CI2 – SI1 Wireless UMTS DLMS

Work Package: 2


Date: 3.11.2009




Interface Selected

Technology Type

Selected

Technologies and lower layer protocols

Selected

Data models and upper layer protocols

GPRS SML

MI2 – SI2 Wireless UMTS

GPRS

DLMS

SML

MI3, CI3 and MUMI2 Wireless IEEE802.15.4-2006

IEEE802.11-2007

DLMS

SML

MUMI1 - MI4 Wireless

IEEE802.15.4-2006

IEEE802.11-2007

Wireless M-Bus

DLMS

SML

Wireless M-Bus

CI4 Wireless Zigbee

Wifi

DLMS

SML

IEC 61850

MI5 Wireless

Bluetooth (IEEE802.15.1-2002)

Zigbee

DLMS

SML

ZigBee SEP

Table 3-1: Overview of selected technologies and protocols for all relevant interfaces.

Note1: The SI3 interface is outside the Scope of the project.

Note 2: For the MI2 – SI2 interface, any technology capable to carry internet traffic (TCP/IP) should be suitable: for example optical cable, xDSL. There is no reason to limit to GPRS / UMTS

Note 3: Wireless M-Bus has not been initially selected in the MUMI1-MI4 interface assessment. However this result is conditioned to IEEE802.11 being able to provide enough battery lifetime for multi-utility meters. If this were not the case for the next revision of deliverable 2.2 (due 2010), then Wireless M-Bus would probably become a selected technology for this interface.

Work Package: 2


Date: 3.11.2009




4 KNOWLEDGE GAPS – PLC TECHNOLOGIES

4.1 Analysis of General Knowledge Gaps

4.1.1 Gaps related to network addressing and routing A system model defining consistent layers and corresponding services should be developed. The issues network addressing and routing, both to be understood in the context of services usually provided by OSI Layer 3 and OSI Layer 4, need to be addressed. It is without doubt that utilizing TCP/IP (to be understood either with IPv4 or with IPv6) would bear great benefit to the user concerning flexibility, as well as a high level of standardization, adaptation and acceptance. In a first step, however, it is necessary to analyze the feasibility of using TCP/IP over PLC links in real networks. It is likely that implementing TCP/IP over PHY and MAC layers compliant with IEC 61334-5-1 is not feasible. TCP/IP over PHY and MAC layers as defined in the PRIME specification is much more likely to be feasible. Crucial issues are the overhead generated by TCP and IP protocols, but also network traffic and latency issues. The addressing scheme must allow for identifying each physical device by a unique address. The address itself may depend on the communication medium to be used. The possibility for using dynamic as opposed to fixed MAC addresses may be analyzed.

4.1.2 Gaps related to EN 50065 Prior to dealing with the gaps listed in the following, information about ongoing work related to the revision of EN 50065 must be gathered.

4.1.2.1 Extend the currently available frequency range specified in EN 50065 The frequency range specified by EN 50065 implies many unfavorable properties of the energy distribution grid for communication devices, e.g. • low access impedance (providing challenges for the design of power amplifiers, coupling

equipment, and power supplies, implying possibly high energy consumption of the communication devices)

• high attenuation levels (obstructing communication signals over long terms) • high noise levels (deteriorating or even obstructing communication signals over long

terms and short terms) It should be analysed if the EN 50065 could be amended by extending specified frequency bands, provided that no insurmountable EMC issues arise.

Work Package: 2


Date: 3.11.2009




Extending the frequency bands to up to 500 kHz may prove to be useful with respect to higher access impedances and less noise, thus allowing for higher data rates with significantly less effort than in the lower bands.

4.1.2.2 Assignment of frequency bands to user groups EN 50065 specifies that the A-band should be reserved for utility use, whereas B-,C-, and D-band should be reserved for private users. It is assumed that A-,B-,C-, and D-band communication signals can be received at any point in the distribution grid (i.e., B-, C-, D-band communication signals injected in the transformer station can be received inside buildings as well). It has to be clarified whether the assignment of frequency bands, as described in EN 50065, is useful or should be amended, e.g. assignment to services instead of user groups.

4.1.3 Gaps related to EMC

PLC devices may disturb other equipment.

Three aspects have been identified so far: 1. The mass application of smart metering devices using PLC should not disturb the

operation of existing devices, like energy saving lamps, dimmers, time switches, TV / HIFI.

2. The PLC system selected for smart metering should be robust against noises typically encountered on the mains grid. It may be useful to specify performance tests for PLC devices similar to those in IEC 61334-5-1. However, it is suggested to define a model for the noise on mains grids and related parameters.

3. Equipment on the network should not block the propagation of the PLC signal.

Since there is no standard defining the “PLC immunity tests” for equipment connected to the mains, it may be necessary to define corresponding tests.

Related to the first item mentioned above, CENELEC TC 210 has recently issued a Questionnaire, TC 210_Sec0591Q, Questionnaire on EMC of non-radio services. It is proposed to obtain the results of this questionnaire in order to decide on the further steps to be taken regarding EMC issues.

4.2 KNOWLEDGE GAPS – INTERFACE MI1-CI1

4.2.1 Gap Analysis for PRIME

4.2.1.1 Standarisation/Openess/Interoperability/Adoption

4.2.1.1.1 PRIME conformance test modes and conditions

Gap:

Work Package: 2


Date: 3.11.2009




The present PRIME standard [1] does not specify standardized test modes and only limited test conditions.

In order to ease PRIME system components and product conformance testing and to ensure that products from different vendors are tested in the same manner, it is proposed to introduce some basic test modes into the standard. Support of such test modes should become mandatory for products declared compliant with the PRIME standard.

The tests to be defined should be also suitable for comparative tests between the two PLC candidate technologies i.e. PRIME and 61334-5-1.

Development Needs: The following test modes are proposed (the list may not be exhaustive)

Continuous mode test transmission: For PRIME EMC, EVM, spectrum and power/level measurements, a continuous (gapless) data modulated transmission mode is proposed. This test transmission signal may be generated using pseudo-random data modulation. This test mode shall support all modulation formats defined in the PRIME standard.

Burst mode test transmission: For PRIME EVM, FER measurements, a burst transmission mode is proposed. Set into burst mode test transmission, a PRIME modem periodically transmits a defined burst consisting of preamble, header and a defined payload containing predetermined pseudo-random data. This test mode shall support all modulation and coding formats defined in the PRIME standard.

Burst mode test reception: For PRIME FER measurements, a burst reception mode is proposed that can be used in conjunction with Burst mode test transmission. Set into burst mode test reception, a PRIME modem acquires, demodulates and decodes Burst mode test transmissions and delivers the CRC result to the test application. This test mode shall support all modulation and coding formats defined in the PRIME standard.

Research Needs: Impulsive noise test channel: Impulsive noise is believed the primary channel impairment in CENELEC bands. Therefore it is considered useful to test products also in realistic channel conditions particularly in impulsive noise conditions e.g. with 50/100/300 Hz synchronous impulsive noise as typically produced by phase controlled circuits. This requires definition of a noise model or recorded noise and a set-up with an impulsive noise generator.

Low access impedance test channel: The LV grid in the CENELEC A-band may exhibit low access impedance to the transmitter. The power output stage and the corresponding coupling equipment must be designed to cope with low access impedance. This requires the definition of an access impedance model reflecting real-world scenarios. A corresponding test procedure should be included into the specification.

High attenuation test channel: Signals transmitted between two or more nodes over the LV grid in the CENELEC A-band may experience high attenuation. The definition of an

Work Package: 2


Date: 3.11.2009




attenuation model reflecting real-world scenarios is required and a corresponding test procedure should be included into the specification.

4.2.1.1.2 Coexistence of PLC technologies

OM-CR12 (“New PLC technologies defined in this project and PLC technologies compliant to standards used within this project should permit coexistence in the same network”).

Gap: The gap is related to CR11 / CR12 from D1.1. At present, the PLC candidate technologies according to the PRIME specification and the IEC 61334-5-1 standard are not designed to coexist in the same network.

Development need: It is suggested to explore possible ways to ensure interoperability of PRIME devices and devices implementing IEC 61334-5-1.

Prior to this, the terms “coexistence” and “interoperability” need to be defined clearly.

Due to the differences between both technologies regarding modulation scheme, medium access control strategy, and also network startup and maintenance, achieving interoperability may not be feasible for economic reasons.

Thus, achieving coexistence appears to be more feasible. It is worth mentioning that, currently, signals transmitted by IEC 61334-5-1 devices must be considered to state noise interfering with signals of PRIME devices and vice versa.

4.2.1.1.3 Additional provisions to ensure coexistence with incumbent radio services

Gap: The present PRIME standard may need additional provisions to ensure coexistence with radio services allocated to a frequency within the PRIME frequency band.

The European Norm [2] includes a note: additional provisions may apply in the event of interference to radio communication service. In practice and certain regions in Europe (e.g. Germany) this may apply to radio clock receivers (DCF77). So far there is little knowledge about any coexistence issues of PRIME and radio clock receivers e.g. receiving at 77.5 kHz.

Research Need: It is therefore proposed to more thoroughly investigate the radio clock coexistence issue particularly for radio clocks located in customer’s premises. Based on these findings and the severity of the issue, it may be decided to introduce additional provisions into the PRIME standard e.g. power control and/or spectrum masking. Such measures may be activated selectively and locally in case of interference complaints via the NW management system.

Work Package: 2


Date: 3.11.2009




4.2.1.2 Robustness Only little knowledge is available on the robustness of OFDM-based solutions. The following knowledge gaps should help to identify possible issues concerning robustness, and to provide means to resolve possible issues.

4.2.1.2.1 Remote interrogation of PHY diagnostics data

Gap: It seems that the present PRIME standard does not sufficiently specify functions and messages to retrieve PHY diagnostic data from network nodes.

Development Need: For managing and monitoring a PRIME network, it is useful to remotely interrogate any desired PRIME service node that has connectivity to a PRIME Base Node and to retrieve PHY diagnostics data e.g. receive signal level, quality, SNR, noise level, or other additional quantities that are vendor specific data e.g. HW diagnostics like temperature, voltages and currents, etc. New functions, messages and message formats may need to be defined and adopted by the standard to ensure interoperability between system components from different vendors.

It is suggested to make use of data from the PRIME Management Information Base. Parameters are to be selected from this information base and made transparent to other devices. If further parameters are found to be necessary, but not existent in the PRIME Management Information Base, they need to be newly defined.

4.2.1.2.2 Error control overlay to improve robustness in impulsive noise conditions

Gap: Impulsive noise is believed the predominant channel impairment in CENELEC bands. There may be methods to enhance the present PRIME PHY for more robustness against impulsive noise and in particular to 50/100/300 Hz synchronous disturbances.

Research and development need: It is proposed to consider additional error control mechanism or error control overlays that would be preferentially implemented at layer 2 and/or layer 3. These mechanisms may either base on forward error correction or feedback error correction (ARQ, selective ARQ) but would act independently of present intra-symbol FEC thus not requiring changes of present PHY specification.

4.2.1.2.3 Identification of possibly unreliable communication links and corresponding parameters

Transmit signals in the A-band of EN 50065 may be received with a low SNR. This can possibly be caused by • significant attenuation along the transmission path, causing low SNR values over long

terms, independent of additive noise, and • impulsive noise (aperiodic and possibly periodic at 50/100/300Hz), being generated and

present in close neighbourhood of a receiver.

Work Package: 2


Date: 3.11.2009




Gap: It is unknown if communication links exist in real-world installations that do not allow for reliable communication at all. Furthermore, it is not known if such links are permanently corrupted.

Research need: In case that totally unreliable communication links are observed in real-world installations, it is necessary to identify the sources of the problems and to analyse the respective parameters.

4.2.1.2.4 Alternative Route-path to reach each node (Open-Meter D1.1 OM-CR10)

Open meter D1.1 OM-CR10 requires storing alternative route-path to reach each node and an automatic mechanism to switch to an alternative route-path. Although this requirement is optional, with respect to the time-variant nature of LV power-line network in the CENELEC band, this requirement can be very important to allow a PLC network to quickly adapt to the change of a power line channel and hence to maintain system stability and performance. The feasibility of implementing this requirement is not yet sure and may depend on the technology used for communication. Gap: The PRIME specification does not mandate to store complete alternative route-paths between the Data Concentrator and a Node nor automatically switch to an alternative route-path. The available channel quality information and signalling mechanism may not be sufficient to assist this new requirement. Today’s PRIME specification provides a simple cost function (based on the used modulation and coding scheme of each link) and basic signalling to assist each node to find an appropriate repeater in the meshed network to forward its data towards the Data Concentrator and vice versa.

Research and development need: Therefore it is proposed to investigate which additional channel quality information should be considered and which signalling mechanism maybe required for PRIME to support this new requirement. Implementing this feature may add additional complexity to the devices. Hence, this feature shall be optional.

4.2.1.3 Manageability

4.2.1.3.1 Feasibility of in-system communication performance tests

Performing in-system communication performance tests as described in OM-FR143 (“The electricity meter shall provide functionality to respond to a communication test initiated by the central system directly or indirectly through the concentrator”) may affect the overall network performance.

Work Package: 2


Date: 3.11.2009




Gap: The effects of single services and operations on network performance are unknown. Research and development need: It should be verified if such tests are feasible to be conducted during normal system operation. If so, it is necessary to provide the corresponding functionality by extending the PRIME specification.

4.2.1.4 Transmission performance

4.2.1.4.1 Data Rate under real-world communication scenarios

Gap: No knowledge is available about the data throughput of PRIME networks that can actually be achieved under real-world conditions.

Research need: In order to determine the actual performance of PRIME, it is necessary to have an estimate of data rates that can actually be achieved.

4.2.1.4.2 Verification of adaptive modulation scheme

Gap: It is not known whether one of the communication modes (modulation schemes) is superior an thus should be preferred while being automatically adapted. Research need: It is necessary to verify the feasibility and benefits of using different automatically selected modulation schemes (differential 2-,4-, and 8-PSK).

4.2.1.4.3 Verification of meshed network approach

The PRIME MAC layer uses a hierarchical communication scheme where multiple nodes are allowed to communicate simultaneously. The intention of this approach is to generate a network architecture that avoids the existence of hidden nodes. Gap: It is unknown if the meshed network approach in fact helps to avoid hidden nodes, or if it causes collisions of frames under critical real-world conditions. In such cases, it is unknown whether the overall network performance is further deteriorated, extending the effects of an error on a larger part of the network or even the whole network. Research need:

Work Package: 2


Date: 3.11.2009




It is necessary to verify the effectiveness of the meshed network philosophy of PRIME against hidden nodes under real-world scenarios.

4.2.1.5 Power consumption

4.2.1.5.1 Determine power consumption for each of the use cases

Power consumption of low frequency NPL communication devices may be high due to low access impedance.

Gap: The power consumption of PRIME-compliant devices under real-world conditions is unknown. Research need: It is necessary to determine the power consumption for PLC equipment under real-world transmission channel conditions covering all relevant use cases appropriately.

4.2.1.6 Functionality

4.2.1.6.1 Define a set of functional requirements that can be implemented in reality

The feasibility of implementing all functional requirements may be questionable since some of the functional requirements may cause significant network load. In case that not all functional requirements can be implemented, due to network performance issues, the number of functional requirements has to be reduced and / or functional requirements have to be adapted.

Gap: It is unknown whether all functional requirements specified in D1.1 can be put into practice under real-world conditions.

Research need: It has to be verified that the total set of functional requirements can be implemented under real-world communication scenarios.

4.2.1.7 General research and development needs All use cases and functional requirements need to be verified to follow OM-ER28 (“Minimise communication activity.”) The cost of nodes / concentrators implementing the PRIME specification has to be determined. A future-proof concept for achieving communication security needs to be developed. It is suggested to search for ways how to achieve coexistence and upgradeability between PRIME devices and devices implementing IEC 61334-5-1.

Work Package: 2


Date: 3.11.2009




It is suggested to analyse if PRIME supports TCP/IPv6 communication under real-world conditions with satisfying performance – and if so, to which extent. This is related to the issue described in section 4.1.1.

4.2.2 Gap Analysis for IEC 61334-5-1 S-FSK PLC

4.2.2.1 Building up and maintaining the S-FSK PLC network Although S-FSK PLC is a ripe technology, standardized and used since 10 years, a few new functions have been recently proposed in the process of building up and maintaining the S-FSK PLC network:

- intelligent search initiator process: this allows the servers (meters) to listen to all concentrators that can be heard, memorize their signal level and MAC address, and select the one providing the best signal level. This process helps to avoid that meters are registered with the wrong initiator, i.e. that can be heard due to cross-talk;

- repeater call procedure: this allows the meters on the network to be dynamically configured as repeaters or non-repeaters, depending on the signal level heard from other devices during the repeater call process. In particular, it helps to avoid interference between meters located closely to each other;

- Ping service: this service allows the initiator to ping the meters on the network, to verify that they are still present on the network, and prevents that meters become forgotten;

- Clear Alarm: this allows to clear alarms in meters. All these features have been specified now by the DLMS UA and are being implemented in systems currently being deployed. They should be tested (WP4) and integrated into the relevant international standards.

4.2.2.2 Interoperability / Coexistence of PRIME and IEC 61334-5-1 It is suggested to search for ways how to guarantee interoperability between PRIME devices and devices implementing IEC 61334-5-1. If interoperability cannot be achieved with reasonable effort, which seems likely, coexistence of PRIME and IEC 61334-5-1 devices should be achieved. Due to the limited PHY data rate, it is doubtful if devices implementing IEC 61334-5-1 support TCP/IP communication. Therefore, it is suggested to analyse if the PHY data rate is sufficiently high. Furthermore, TCP/IP packets may contain a considerable amount of overhead (e.g. headers), which would lead to issues if they were supposed to be transported over a MAC with fixed and comparably short MAC layer PDUs (fragmentation). It is thus also suggested to analyse the relation between overhead and MAC layer PDU size, and to find solutions in case issues occur.

4.2.2.3 Data throughput of IEC 61334-5-1 S-FSK PLC It is necessary to validate if the throughput provided by IEC 61334-5-1 S-FSK PLC can support all functional requirements identified in D1.1, and the best methods to organize

Work Package: 2


Date: 3.11.2009




traffic (for example, reading the daily load profile in several chunks by the concentrator from the meters). It is proposed to investigate if IEC 61334-5-1 S-FSK PLC is suitable to carry IP traffic, from the point of view of overheads caused by TCP/IP and data rate.

Work Package: 2


Date: 3.11.2009




5 KNOWLEDGE GAPS – WIRELESS TECHNOLOGIES

5.1 Wireless interfaces in electricity meters according to OPEN meter system architecture

In the deliverable D2.2 all the interfaces defined in the OPEN meter system architecture have been assessed, and the most suitable technologies for each of these interfaces have been identified. The gap analysis is provided below for all these technologies. However, it is clear that an electricity meter must remain a very low cost device, and as a result of this, it will be impossible for it to embed different wireless technologies. So the WP3 will have to select a technology that best matches all the requirements for the different interfaces, and clears the gaps mentioned below as much as possible. In general, the wireless technologies assessed in deliverable 2.2, are perceived as mature from the technology stability point of view, and also potential applications are quite well defined when compared to PLC technologies. This reason has a direct impact in the number of gaps identified for these technologies. As a result of this, the work of WP3 will be more focused on identifying gaps for PLC technologies, as this is also the main technology focus on the whole project.

5.2 Interface CI2-SI1

5.2.1 Gap analysis for UMTS UMTS has been selected as first candidate technology for the CI2-SI1 (central system to concentrator) interface. However, some gaps remain that need further investigation in the project: • An open issue for this interface is the need of enhancing the coverage in indoor

/underground areas, where the concentrators are usually installed. Usually there is no need

• Currently UMTS network do not support multicast/broadcast delivery of information to many IP addresses (concentrators), and this might be a desirable feature for central systems to send a multicast / broadcast command to a base of concentrators.

• Another issue to be checked is the possible future use of the 900MHz frequency band for UMTS services is Europe, as this would greatly improve the coverage area. As frequency attenuation increases with frequency, the use of lower frequencies (e.g.900MHz) permit cells with a larger radius, and therefore lower the investment needed by the operator to deploy the service, as it can reuse the existing cell infrastructure.

5.2.2 Gap analysis for GPRS GPRS has been selected as alternate candidate technology for the CI2-SI1 interface. In its gap analysis, the first 2 issues in section 5.1.1 apply for GPRS.

Work Package: 2


Date: 3.11.2009




5.3 Interface MI2-SI2

5.3.1 Gap analysis for UMTS UMTS has been selected as first candidate technology for the CI2-SI1 (central system to meter) interface. This technology will enable each meter with an IP address, and every one of these IP addresses will be reachable via the mobile operator’s network infrastructure. However, some gaps remain that need further investigation in the project: • As the number of subscribers is very high, this places a limitation on the addressing

capability of the network and IPv6 may be needed. Currently UMTS networks provide IPv4 addressing schemes to subscribers.

• Also the IP addresses can be public or private. A private addressing scheme (private LAN) is much desired due to the improved security against public addresses. However it is an open issue if the mobile network operators can provide a network of this size (millions of subscribers) with private IP addressing mechanisms, as it places heavy requirements on its network resources.

Also the gaps mentioned under section 5.2 apply to this interface, such as: • Support multicast/broadcast delivery of information to many IP addresses

simultaneously. • Usage of the 900MHz frequency band for UMTS services is Europe, to improve the

coverage area

5.3.2 Gap analysis for GPRS GPRS has been selected as alternate candidate technology for the MI22-SI2 interface. In its gap analysis, all the gaps mentioned for the main technology (UMTS) in section 5.2.1 apply, except for the availability of the 900MHz band.

5.4 Interfaces MI3, CI3 and MUMI2

5.4.1 Gap analysis for IEEE802.15.4 In the assessment process for these interfaces, IEEE802.15.4 technology seems to be a very robust candidate technology, with good marks in all relevant aspects and no gaps. It offers good transmission performance compared with other candidate technologies, except Wifi/IEEE802.11. However it has good advantages, such as its standardization, wide adoption, low cost and improved security. As a result of this, no relevant gaps have been identified for this technology and interface pair.

5.4.2 Gap analysis for IEEE802.11 IEEE802.11 is a good candidate technology for solving wireless access in the interfaces under study. Its degree of adoption in wireless O&M devices is overwhelming. Also its

Work Package: 2


Date: 3.11.2009




transmission performance is far better than those of the other competing technologies, and at the present moment its security mechanisms can be considered state-of-the art. The main drawback of this technology can be the slightly higher power consumption compared to other technologies. To summarize, the gap that IEEE802.11 introduces for interface MI3, CI3 and MUMI2 is the lack of a low power mode, in which the radio may remain in “listening” mode with a reduced power consumption. For IEEE802.11 to perfectly fit the requirements, it must be investigated whether such low power mode can be achieved or is foreseen in the standard. With a view of keeping costs and power consumption low and to avoid interferences, using different technologies on the various interfaces of the devices should be carefully considered.

5.5 Interfaces MUMI1-MI4

5.5.1 Gap analysis for IEEE802.15.4 IEEE 802.15.4 has obtained good results in many key areas of the technology assessment, being open and standardized, low cost, robust and secure. Even though the datarate offered by this technology is not very high compared to other technologies (up to 250 kbit/s), it seems good enough to withstand future application bandwidth increase demands. As a result of this, no relevant gaps have been identified for this technology and interface pair. The protocol layers to be use between the MAC layer and the application layer have to be studied. One candidate is IEEE 802.2 LLC layer with a suitable service specific convergence layer.

5.5.2 Gap analysis for IEEE802.11 IEEE802.11 technology offers a balanced choice, and has therefore obtained good marks in the overall assessment. It has superior performance compared to the other technologies analyzed in this report, adding on the other hand increased power consumption as well. Without any doubt it is a well standardized, future-proof technology and is already used in many areas for point-to-point communications, as is the case for the interface MI4-MUMI1. The main gap for IEEE802.11 technology in this interface, as has been mentioned for MI3 interface (see section 5.3.2), is power consumption, which is slightly high thinking on battery powered devices, such as the Multi Utility Meter. For this reason, it must be verified if the technology has some means now of in the near future to lower its power consumption in Rx mode. If the result is not acceptable, then the candidate technologies shall be re-assessed. The requirement of very low power in standby rx mode is critical for this interface, as the multi-utility meter will be usually powered by a battery with no maintenance. If this requirement cannot be met, in order to obtain a battery life time of 10 years in a multi-utility meter device, then this technology will have to be discarded and a new assessment done for this interface, and another technology that

Work Package: 2


Date: 3.11.2009




5.6 Interface CI4 Currently the interface CI4, which links the concentrator with external devices, is not sufficiently defined as to indentify gaps for the technologies selected as candidate. These technologies have been assessed as best candidates for the given requirements, but as there is no information on the “external devices” that will connect to the concentrator, a detailed gap analysis is not available. For instance, it cannot be assessed if the datarate or the range of a certain wireless technology is good enough for this interface, as the application has not yet been defined. As a result of, this analysis assumes that some kind of external sensor or device, installed in the vicinity of the concentrator, will link and transmit data wirelessly to the concentrator, using low data rate protocols.

5.6.1 Gap analysis for ZigBee Zigbee, being based upon IEEE802.15.4 physical and MAC layers, offers interoperability and standardization ensured by the Zigbee Alliance. It also provides reasonable throughput and low latency. As the external devices which will connect using this interface are not currently defined, it is clear that the level of interoperability provided by Zigbee gives a good advantage over plain lower layer IEEE802.15.4 implementations. Compared to Wifi, for instance, Zigbee offers less throughput with less power consumption and slightly lower cost, while offering similar interoperability. As a result of this, Zigbee is a solid candidate technology for this interface. As explained in section 5.5, no gaps can be identified for this technology in CI4.

5.6.2 Gap analysis for WiFi For interface CI4, the interoperability guaranteed by the Wifi Alliance certification process is a big advantage, as future devices including this technology will be guaranteed to interoperate with the concentrator. In this case the extra cost is well worth its value. This technology offers a considerable performance compared to ZigBee, so it can be a safe bet for the interface CI4. Moreover its acceptance in industrial communication systems is high, so no gaps are anticipated.

5.7 Interface MI5

5.7.1 Gap analysis for Bluetooth Bluetooth has been selected as candidate technology for the MI5 interface (customer devices to meter). However, it has a clear gap, in which its specification, up to now, does not include a specific profile for smart metering access and applications. Thus it must be investigated whether Bluetooth will include this kind of profile to enable metering related protocol application on top of Bluetooth lower layers.

Work Package: 2


Date: 3.11.2009




5.7.2 Gap analysis for ZigBee Zigbee is the second candidate technology for interface MI5. In this case it does include a native Smart Metering profile in its current specification. However its main gap to be investigated is the limited availability of Zigbee consumer products which the users may utilize to interact with their smart meters. In order to be interoperable with consumer products, it is clear that the interoperability assurance provided by the Zigbee certification process is a clear gain over IEEE802.15.4 implementations where no institution guarantees interoperability. This limitation may be overcome in the next few years, or if the customers are provided with some specific gateway device to access their meters.

Work Package: 2


Date: 3.11.2009




6 KNOWLEDGE GAPS – DATA MODELS AND “HIGHER LAYER” PROTOCOLS

6.1 DLMS/COSEM

6.1.1 Overview

DLMS/COSEM has been assessed for the following interfaces, using appropriate communication profiles:

Interfaces

M1-CI1 MI2 – SI2 MI4 – MUMI1

CI2 – SI1 MI3 / MUMI2 / CI3

MI5 CI4

Communication media supported by DLMS/COSEM

PLC IEC 61334-5-1 S-FSK PLC

– – – – – –

Wired – – EN 13757-2 Wired M-Bus

PSTN??

Leased lines?

IEC 62056-46

IEC 62056-21 optical / current loop

IEC 62056-21 Mode D –

IEC 62056-31 Euridis IEC 62056-

31 Euridis IEC 62056-31 Euridis

RS 485 EN 13757-6 Local M-Bus

Wireless (dedicated) –

EN 13757-4, EN 13757-5 (Mode Q)

Wireless M-Bus

–

EN 13757-4, EN 13757-5 (Mode Q)

Wireless M-Bus

– –

Wireless (public) – GPRS /

UMTS – GPRS / UMTS – – –

Internet (public) –

Internet (Ethernet, ADSL etc)

– Internet (Ethernet, ADSL etc)

Communication media currently not supported by DLMS/COSEM (gaps)

PLC Prime PLC – – – – – –

Wired – – – – – – –

Wireless (dedicated) – – IEEE

802.15.4 – IEEE 802.15.4

IEEE 802.15.4 –

– – Zigbee – Zigbee Zigbee Zigbee

Wireless (public) – IEEE 802.11 IEEE 802.11 IEEE 802.11 –

– WIFI WIFI

– – – Bluetooth –

Work Package: 2


Date: 3.11.2009




Interfaces

M1-CI1 MI2 – SI2 MI4 – MUMI1

CI2 – SI1 MI3 / MUMI2 / CI3

MI5 CI4

Internet (public) – – – – – – –

Table 6-1: Use of DLMS/COSEM over various interfaces

Work Package: 2


Date: 3.11.2009




In the following, each solution is briefly described.

MI1-CI1 interface: this is the interface between the meters and the concentrator. For this interface, two PLC technologies have been selected (see chap. 4):

• IEC 61334-5-1 S-FSK: this is already supported by DLMS/COSEM. The details are available in the IEC 61334 series and DLMS UA Blue Book / Green Book, International standardization of the new elements will be launched in QIV 2009.;

• PRIME: the PRIME specification describes how to link the PRIME MAC layer with the COSEM Application layer, either via the IEC 61334-4-32 LLC layer or the IPv4 network layer, through a service-specific Convergence Sublayer (CS). This needs to be validated and then internationally standardized. The COSEM interface classes to set up and control the media have been developed. These have to be validated and integrated into the DLMS/COSEM standards.

MI2- SI2 interface: this is the interface between the meters and the central system (see chapt. 5.3):

• GPRS/UMTS is already supported, using the DLMS/COSEM TCP-UDP/Ipv4 based profile;

MI4 – MUMI1 interface: This is the interface between the electricity meter / communication hub and the Multi-utility (non electricity) meters. On this interface two scenarios are foreseen (chapt. 5.5):

• the electricity meter / communication hub acts as a proxy for the concentrator / Central system. In this case, the concentrator / Central system acts as a master for the electricity meter / communication hub, while the electricity meter / communication hub acts as a master for the multi-utility meters. The electricity meter / communication hub collects data from the multi-utility meters and stores them for retrieval. It also forwards commands to the multi-utility meters.

• the electricity meter / communication hub acts as a proxy gateway, passing application layer level information transparently between the multi-utility meters and the central system using the appropriate protocol stacks on the segments of the end-to-end link. It is noted, that this scenario may also be useful in the case of “meter room” when a lot of electricity or other meters are installed together;

• EN-13757-2 wired M-Bus / proxy: this solution – is already supported by DLMS/COSEM. It is the P2 interface of the Dutch DSMR project. In this case, on the MI4-MUMI2 interface the EN 13757-3 Dedicated application layer is used;

• EN-13757-2 wired M-Bus / gateway proxy: in this case, the COSEM application layer is used on both segments;

• IEC 62056-31 Euridis: In this case, both scenarios need to be studied;

Work Package: 2


Date: 3.11.2009




NOTE The IEC 62056-31 standard is currently under revision by IEC TC 13 WG 14. The draft allows baud rate negotiation and specifies how to use the Euridis lower layers with DLMS/COSEM.

• RS 485: this interface may be worth considering in a meter room scenario, where many meters are installed together. The 3-layer, HDLC, connection-oriented DLMS/COSEM profile can be used;

• EN 13757-4, EN 13757-5 (Mode Q) wireless M-Bus: the possible architectures are essentially the same as in the case of the wired M-Bus, but the Phy and MAC layers are different (wired – wireless);

• IEEE 802.15.4: when only the Phy and MAC layers are used, then the intermediate layers between the MAC layer and the COSEM application layer have to be specified. The need for new interface classes necessary to set up and control the media have to be checked;

• Zigbee: In this case, DLMS/COSEM APDUs can be tunneled using the Zigbee connectivity. The development of a tunneling cluster within the Zigbee Smart Energy Profile (SEP) has been started through the co-operation between the DLMS UA and the Zigbee Alliance;

• IEE 802.11 / WIFI: the DLMS/COSEM TCP-UDP/IPv4 profile can be used. The need for new interface classes necessary to set up and control the media have to be checked.

CI2 – SI1 interface: This is the interface between the concentrator and the Central system (chapt. 5.2):

• On this interface, PSTN or leased lines may be considered, with the 3-layer, HDLC based, connection-oriented profile;

• Otherwise, the proposed solutions are the same as on the MI2-CI1 interface.

NOTE In the Dutch DSMR project, this is the P3.2 interface. This interface uses web services, working with COSEM object resources.

MI3 / MUMI2 / CI3 interface: these are the local O&M interfaces of the electricity meter / communication hub, multi-utility meter and the concentrator (chapt. 5.4):

• IEC 62056-21 Mode E, using either an optical port or a current loop is supported, with the 3-layer, HDLC based, connection oriented profile;

• IEC 62056-31 Euridis can also be used, with DLMS/COSEM;

• when the multi-utility meter uses M-Bus, then the M-Bus local bus, specified in EN 13757-6 can be used. EN 13757-6 can be used with various link and application layers. Frequently, the application layer of EN 13757-3 (M-Bus) or the DLMS based application layer described in EN 13757-1 is used.

• the dedicated and public wireless interfaces selected for the MI4 – MUMI1 interface can also be used.

Work Package: 2


Date: 3.11.2009




NOTE Physical presence of the operation / maintenance personnel may be required to perform the necessary operations, e.g. opening the meter, flipping security switches etc. If no physical presence is needed, then the remote interface can be used.

MI5 interface: This is the interface between the electricity meter / Communication hub and the End Customer Device (chapt. 5.7):

• IEC 62056-21 Mode D can be used. This is the interface P1 in the Dutch DSMR specification;

• the dedicated and public wireless interfaces selected for the MI4 – MUMI1 interface can also be used.

6.1.2 Data model – COSEM

6.1.2.1 Functional extensions

6.1.2.1.1 General

Most functions specified in D1.1 are already fully supported by the COSEM object model. Gaps have been identified concerning:

• Prepayment;

• Distributed generation.

6.1.2.1.2 Prepayment

Minimum requirements are specified in D1.1. OM-SR20. At least the following information shall be managed:

• Credit Available: Value expressed in Wh, indicating the credit available to the customer at this time (default value = 0).This can be modeled with a Register object, with an appropriate OBIS code to be allocated.

• Debt Limit: Wh provided to the customer in the case of credit expired. If this limit is exceeded, the command to open the circuit breaker shall be sent and an alarm will be shown to the customer on meter display and/or be sent to indoor devices.

• Warning Threshold: minimum Wh threshold at which the meter shall provide the customer with a warning message.

• These two latter can be modeled using existing objects, Register monitor, Script and Disconnector objects, with appropriate OBIS codes.

For the modeling of payment metering functionality, the work of IEC TC 13 WG 15, in particular the Technical Report IEC 62055-21, Electricity metering – Payment systems –Part 21: Framework for standardization can be used as a basis.

Work Package: 2


Date: 3.11.2009




6.1.2.1.3 User identification

A new interface class called Login manager is proposed to support the identification of various users to the meter. This is an additional step to the already supported access security mechanisms.

This is to meet OM-TR 19 and OM-TR 20 of D1.1:

• OM-TR 19: The equipment shall provide functionality for unique identification of the source of all data communications on all of its communication interfaces.

• OM-TR 20: The equipment shall provide functionality for the authorisation (ability of a given person to make a connection to a given Interface) of data communications on all of its communication interfaces.

6.1.2.1.4 Distributed generation

Requirements are specified in OM-FR 194 to 199.

The requirements have to be analyzed and the appropriate object model developed.

DLMS/COSEM already supports bi-directional energy and demand metering on multiple tariffs, measuring and monitoring the values of phase voltages, currents and phase angles.

6.1.2.1.5 Extensions to manage communication media

For each communication media not yet supported, the appropriate setup classes have to be specified.

6.1.3 Messaging – DLMS

6.1.3.1 General

The DLMS/COSEM Application layer specifies services to access the attributes and methods of COSEM objects. These services are carried by the xDLMS APDUs.

DLMS/COSEM works primarily on the client/server paradigm, where the central system plays the role of the client and the meters play the role of servers. Unsolicited messages are also available.

The current messaging method is adequate for most situations. However, to optimize performance, three developments are proposed:

• push operation: in this case, the meters can send pre-defined set of data, to pre-defined destinations, following a pre-defined schedule (subscribe- publish). The information may be self-descriptive or not. This evolution may be particularly useful when GPRS/UMTS is used. Self-description may be useful for interpretation, but adds considerable overhead. Therefore it shall possible to avoid sending data repeatedly that is already known by the central system;

Work Package: 2


Date: 3.11.2009




• possibility to include different kind of requests / responses – GET / Read, SET / Write, ACTION – on a single list: the new ACCESS service. This evolution may be useful to minimize the communication traffic.

• XML, as an alternative to DLMS shall be also considered. This would allow to carry COSEM data model information using standard file transfer mechanisms. The appropriate XML schemas have to be developed. The use of XML may be useful on the CI2 - SI1 interface.

6.1.3.2 Push operation

The current DLMS/COSEM specification is based on the client/server paradigm, where the data collection systems act as clients requesting data from the meters, acting as servers. This is also known as pull operation. In addition, DLMS/COSEM allows sending unsolicited data, containing any data, for example alarms.

In some communication environments it may be advantageous if the meter could send predefined data sets on predefined conditions, to the destinations specified, using a predefined packaging and communication media, with or without confirmation by the recipient. This is also known as push operation. Push operation may – and in most cases will – live together with pull operation.

This is the case for example on internet based networks, where the IP address of the meter may be private and dynamic and therefore not known for the COSEM client, or it requires a complex operation to obtain the IP address of the COSEM server. On the other hand, the COSEM client most probably will have an IP address that can be made known to and reached by the COSEM server.

Using push operation also reduces the number of round trips involving the establishment of an Application Association, xDLMS service .request / .response exchanges, and releasing the AA.

Two elements need to be specified:

• the Push DLMS service;

• a Push setup interface class.

This work has already been started by the DLMS UA.

6.1.3.3 ACCESS service

Currently, DLMS/COSEM allows to send a list of GET / Read, SET / Write and ACTION service requests. The response is also a list of service responses containing the result of each request.

Work Package: 2


Date: 3.11.2009




In addition, a new ACCESS service is proposed, allowing to mix these different kind of services in a single list, together with the rules of executing them. This would allow specifying all actions to be performed in a single request and get the result in a single response.

Example: Such a list of requests would allow to connect to the meter, identify it, read and write the necessary data, set the clock then disconnect, all in one step.

This may decrease the number of round-trips, if the resulting – longer – APDUs can be transported without segmenting them. Again, the response may be specified to be self-descriptive or not.


6.1.3.4 Compression

DLMS/COSEM has several tools and mechanisms to ensure an efficient data transport, including the use of profiles to contain multiple data, selective access, the use of null data and compact array encoding.

To further improve efficiency, we propose to add a compression algorithm.


6.1.3.5 Communication Profiles

DLMS/COSEM currently supports the communication profiles shown in Figure 2.

Work Package: 2


Date: 3.11.2009




COSEM Application Process

COSEM Application layer

ACSE xDLMS SecurityASE

ConnectionlessLLC layer

IEC 61334-4-32

Sup

p. la

yer

HDLC

Phy layer

TCP

Appl

. lay

er

IPv4

Supportinglayers

AL

3-layer,CO HDLC TCP-UDP/IP IEC 61334-5-1 S-FSK PLC profiles

Appl

. lay

er

MAC +Phy layerIEC 61334-5-1 S-FSK

Wrapper

Connectionmanager

Sup

p. la

yer

LLC layer(Protocol selection)

HDLC

LLC layer(Protocol selection)

Appl

. lay

er

Figure 2 – DLMS/COSEM Communication profiles

The communication profiles are:

• the 3-layer, connection-oriented (CO), HDLC-based profile. This comprises the COSEM AL, the HDLC-based data link layer and the PhL, for connection-oriented asynchronous data exchange. It supports data exchange via a local – optical or electrical – port according to IEC 62056-21, leased lines and the PSTN or the GSM telephone network;

Work Package: 2


Date: 3.11.2009




• the TCP-UDP/IP based communication profiles. These profiles support data exchange via the Internet over various physical media, like Ethernet, ISDN, GPRS, PSTN or GSM using PPP etc. In these profiles, the COSEM AL is supported by the COSEM transport layer(s), comprising a wrapper and the Internet TCP or UDP protocol. Lower layers can be selected according to the media to be used, as the TCP-UDP layers hide their particularities;

• the S-FSK PLC based communication profiles. These profiles support data exchange via power lines using S-FSK modulation. In these profiles, the COSEM AL is supported by the connectionless LLC layer as specified in IEC 61334-4-32 or the LLC layer using the data link layer based on the HDLC protocol as specified in IEC 62056-46 / Green Book Clause 8. The MAC and the Physical layers are as specified in IEC 61334-5-1.

Further communication profiles to support other media can be easily developed. The elements to be specified in each communication profile are given in Sub-clause “Communication profile specific elements” of the COSEM AL specification. The communication profiles for the media retained by D2.2 have to be specified. See also paragraph §6.1. For data exchange over the Internet, DLMS/COSEM specifies the TCP-UDP/IPv4 communication profile. In the future, the use of IPv6 may become interesting, as it provides better performance and it solves the problem of IP addressing (§4.1.1). Adding IPv6 requires the specification of a new IPv6 setup class.

6.2 SML

The development of SML is closely related to the development of the Synchronous Modular Meter (SYM2), which is a joint venture between RWE, EON and EnBW to develop an industry standard specification for a load profile meter in Germany.

This section summarises the SML communication profiles that are currently specified in a number of supporting documents. It is worth underline that after D2.1 and D2.2 publication a new specification (v1.03) was released, but in this gap analysis the previous v1.02 is considered.

Earlier this year submission was made to CENELEC via the Vilamoura process to develop SML as an international standard. The outcome of this submission is expected in October 2009.

SML specifies a message structure and encoding of data containers, independent from communication layers according to OSI model (see Figure 3).

Work Package: 2


Date: 3.11.2009




Figure 3 – SML system architecture

(SML specification 1.02, http://www.sym2.org/eng/sml-spezi_eng.html)

In respect of the OSI communications model, SML covers the layers as shown in the table below.

OSI Layer SML Structure 7 – Application Layer Smart Message Language defines a file

structure / document structure for exchanging data between several points in an AMI.

6 – Presentation Layer SML Binary Encoding defines a packed binary coding for SML SML XML encoding specification is currently a gap.

5 – Session Layer Not defined 4 – Transport Layer Not defined 3 – Network Layer Not defined 2 – Data Link Layer Not defined 1 – Physical Layer Not defined

Work Package: 2


Date: 3.11.2009




Table 6-2: SML and the OSI layers

With reference to the above table, some detail about layers is given (please refer to D2.1 for further information).

Application layer: SML defines self-contained information units or containers that are completely detached form the transport technology involved. In SML terminology these containers are referred to as “files”. An SML file is always structured as a chain of SML messages. The approach of using SML files means the concept is independent of the task of having to define specific protocols for information interchange. Instead, all that is demanded is to select a certain protocol (e.g. HTTP, FTP, ..) in a particular duty case and parameterise this appropriately. The coding defined with section 6 of the SML specification then has to be used, unless the particular application involved explicitly specifies a divergent stipulation.

The SML file denotes a specific self-contained information unit, which is completely detached from the transport technology involved. Regarding the transport layer it refers to existing standards.

An SML file is always structured as a chain of SML messages.

Both SML document V1.02 and V1.03 do not refer to encryption, because SML provides the framework for transmission of signatures. The encryption method is determined by the selected application (“companion standard”, e.g. Sym2-Specification, MUC-Specification). SML authentication (username and password) is not defined due to the fact that it is referring to the selected application.

Presentation layer: at the presentation layer of the OSI model SML provides SML binary encoding and SML-XML encoding. The data in the SML file is converted into one of these two formats depending on the requirements. The binary encoding format is the default and is optimised to minimise the volume of data that is transmitted. The XML format entails a significantly increased data volume, but supplies SML files in a readable format. The XML-SML transformation will be available end of 2009 due to the fact that the W3C Recommendation for efficient XML interchange will not be available before September 2009 (see http://www.w3.org/XML/2009/02/exi-charter.html#milestones). Transport layer: to guarantee flexibility over different communication media, SML has two different data transport mechanisms for transporting metering data over unsecured serial links and more connection orientated links such as TCP. In typical metering applications SML messages will be transmitted using the TCP or UDP transport layers in conjunction with IP. However, the SML Transport layer will be used for transmitting SML messages over unsecured serial links, such as direct optical readouts, PSTN modems, GSM modems etc. Frame control is part of the SML Transport layer. As mentioned, SML does not specify the lower layers of the OSI model in order to leave the selection to the end-user. The following table provides a summary of how SML has been

Work Package: 2


Date: 3.11.2009




applied, or could theoretically be applied to the different OPEN Meter interfaces and communication media. In the table the following classifications are used:

SML over the interface / media has been tested and

documented.

SML over the interface / media has been tested but

not documented.

SML can support the interface / media but it has

not been tested or documented.

It does not make sense to use SML over the particular

interface / media.

SML over the interface / media has been tested and

documented.

SML over the interface / media has been tested but

not documented.

SML can support the interface / media but it has

not been tested or documented.

It does not make sense to use SML over the particular

interface / media.

Interfaces Media M1-CI1 MI2 – SI2 MI4 – MUMI1 CI2 – SI1 MI3 / MUMI2 /

CI3 MI5 CI4

PRIME PLC 61334-51 (S-

FSK)

Ethernet Ethernet Ethernet

EN 13757-2 (Wired M-Bus)

IEC 62056-21 optical / current loop

IEC 62056-31 Euridis IEC 62056-31

Euridis

KNX KNX

Wired (dedicated)

RS 232 / RS485 EN 13757-6

(Local M-Bus)

Wired (public)



EN 13757-4, EN 13757-5 (Mode Q)

(Wireless M-Bus)

Wireless (dedicated)

IEEE 802.15.4 (Zigbee) IEEE 802.15.4

(Zigbee)

GPRS / UMTS GPRS /

UMTS Wireless (public)

IEEE 802.16 (WIMAX)

IEEE 802.11 (WiFi)

IEEE 802.16 (WIMAX)

IEEE 802.11 (Wi-Fi)

Table 6-3: SML over the main OPEN-meter interfaces / media

The use of SML has been tested and documented for the following technologies: - Wired and wireless M-Bus; - GPRS / UMTS.

Work Package: 2


Date: 3.11.2009




The use of SML for all other technologies should be considered as a gap. In the following, the SML application for each of the interfaces is briefly described. MI1-CI1 interface: This is the interface between the electricity meter / communications hub and the concentrator. The MUC specification specifies the I2.1 profile in which the MUC is the SML server and the concentrator is the SML client.

OSI Layer Description

7 SML Application layer

6 SML binary coded

5

4 Open supplier application

3 RUN-M (1)

2 D2DL(2)

1 DCSK (3)

Table 6-4: SML Profile for M1- C1 interface Notes: (1) Renesas Ubiquitous Network Layer for Metering Applications) von Renesas Technology Corp. Software based on

Open Renesas specification for 3rd parties.

(2) D2DL (Data Link Layer Library) von Renesas Technology Corp./Yitran Communications Ltd (3) DCSK (Differential Code Shift Keying) von Renesas Technology Corp./Yitran Communications Ltd

To cover the PLC network layer the DKE is working on a standard in Working group AK 461.0.14), which is part of the PLC working group. The document will be available in the German language first. The DKE is the German organization responsible for the elaboration of standards and safety specifications covering the area of electrical engineering.

MI2-SI2 interface: This is the interface between the electricity meter/communication hub and the central system. GPRS / UMTS is considered by D2.2 to be most suitable technology. The MUC specification specifies the following GPRS / GSM profile I2.2 for this interface.



6 SML binary coded

5 IP-Telemtrie (DIN 43863-4)

Work Package: 2


Date: 3.11.2009




4 TCP (RFC 0793) TLS

3 IP (RFC 0791)

2 GPRS, Ethernet, PPP

1 Twisted pair,…

Table 6-5: SML profile for the MI2-SI2 interface (GPRS) Either the GPRS service or the CSD data service from the GSM network can be used (in which case Point-to-Point Protocol (PPP) will be used. The IP version supported is IPv4; future support of IPv6 must still be investigated. In the case of GPRS the MUC (communication hub) will initiate a bi-directional "IP-Telemetrie" link over TCP/IP. This will be settled in a new standard DIN 43863-4, available in the German language. DIN 43863-4 will be available end of 2009 in the English language. In the case a normal GSM connection, the application protocol will be transported directly over the GSM data connection. MI4–MUMI1 interface: This is the interface between the electricity meter / communication hub and the multi-utility (non electricity) meters. The electricity meter/ communication hub acts as a proxy for the concentrator / Central system passing application layer level information transparently between the multi-utility meters and the central system using the appropriate protocol stacks on the segments of the end-to-end link. It is noted, that this scenario may also be useful in the case of a “meter room” when a lot of other meters are installed together. On this interface two scenarios are foreseen: The MUC-C specification specifies that the MUC should be directly connected to the Electricity Meter (eHZ) using a wired RS232 connection, while the connection with other meters (G-, W-, H-) should be implemented using wireless M-bus. As a result the following profiles have been defined: a) the I1.1 profile for communication with eHZ (German electricity meter).



6 SML binary coded

5

4

SML Transport Protocol

3

Work Package: 2


Date: 3.11.2009




2

1 RS232

Table 6-6: SML profile for the MI4-MUIMI1 interface (RS232) b) The I1.2 profile for communication with G-, W-, H- meters.


7 M-Bus / SML Application layer

6 SML binary coded

5

4

M-Bus/ SML Transport Protocol

3

2 Wireless M-Bus

1 Wireless M-Bus

Table 6-7: SML profile for M1 – MUMI1 interface (M-Bus) The OMS Volume 2 specifies the implementation of M-Bus as well as Wireless M-Bus for the lower layers. It does not mention the use of RS232. Therefore it appears that the MUC-C specification and the OMS documentation are not completely aligned. CI2 – SI1 interface: This is the interface between the concentrator and the Central system. SML over GPRS / GSM is specified by profile I2.2 in the MUC Specification document. However, this profile is identical to I2.3 as described for the M2-SI2 interface. MI3 / MUMI2 / CI3 interfaces: These are the interfaces between the “Local O&M device” and the electricity meter/communication hub, the multi-utility meter, and the concentrator respectively. These interfaces have not been defined in the OMS or MUC specifications, and as a result no SML profiles have been documented.

MI5 and MI4 interfaces: These have not yet been properly defined by the OPEN Meter and the OMS specification. However the MUC-C specification mainly specifies a TCP/UDP Ethernet connection (I3.2 profile). In this profile the MUC will act as an SML server and the customer end device (Standard Home Unit – SHU) as an SML Client.

Work Package: 2


Date: 3.11.2009






6 SML binary coded

5 SML Transport Protocol, SSL or RSA security

4 TCP (RFC 0793) / UDP (RFC 0768)

3 IP (RC 0791)

IP fixed / DHCP server

2 Ethernet

1 Ethernet

Table 6-8: SML profile for MI5 and MI4 interfaces

Support for IP Version 4 is specified, but future support of IP version 6 is be possible by just changing layer 3.

6.2.1 Object Model SML does not have an object model defined. It also does not define any interface classes as in the case of COSEM. However, it does use the OBIS codes, which are maintained by the DMLS UA, to describe the functions supported by SML. The SML documentation does not however specify which OBIS codes are supported by SML, and therefore a detailed assessment of the OPEN meter functional requirements (specified in D1.1) is required to determine exactly which functions are supported by SML (according to the MUC specification), and where the gaps are. Also, SML may specify additional functionality for which no OBIS codes currently exist. In such cases the codes will need to be submitted to the DLMS UA for review and approval to ensure that the SML codes and the OBIS codes are always in synchronisation. The considered SML document V1.02 refers to compression within chapter 6 (SML binary encoding, directly packed coding).

6.2.2 Shortcoming and development activity Work Package D1.1 of the OPEN Meter project identified a large number of requirements that the smart meters, system and communication standards have to support; these requirements will be further refined in future versions of the deliverable. Mapping of D1.1 (v1.0) clauses on SML features was given in D2.2 (v0.8.5).

Work Package: 2


Date: 3.11.2009




Based on the above findings the following shortcomings have been identified:

1) the standardization process is curently in progress (the Vilamoura procedure is already started).

2) The SML Language specification currently defines the message structure of the protocol and does not specify the functions that are supported. The conclusion for WP3 is to elaborate companion standards for the required functions and interfaces.

3) As stated before, it is not clear how the OPEN Meter functions are supported by SML because some requirements of D1.1 need more specification.

4) Based on Table 6-3, SML is theoretically possible over most communications media, however in the majority of cases the specifications have not been documented or tested.

5) No interfaces have been defined in the OMS and MUC specifications for MI3 / MUMI2 / CI3 interfaces which is the interface between the meter / communications hub (as well as the concentrator) and the local O&M device. It is therefore not clear if SML will be used for these interfaces and this is a shortcoming in respect of the OPEN meter project.

6) SML document V1.03 is currently only available in German language.

7) The XML-SML transformation needs to be documented and tested.

Based on the above shortcomings and in light of the requirements of the OPEN Meter project the following research work and development activities are recommended:

1) The use-case-specific application of SML over different communications media should be investigated and the specifications developed. This specifically includes the following media which is the focus of the OPEN Meter project:

PRIME – please refer to § 4.2.1 for further details;

IEC61334-51 (S-FSK) – §4.2.2;

IEEE 802.11 (WiFi) - § 5.4.2;

IEEE 802.15.4 (Zigbee) – § 5.4.1.

2) Specifications should be developed for the MI3 / MUMI2 / CI3 interfaces which is the interface between the meter / communications hub (as well as the concentrator) and the local O&M device.

3) SML-related documents which could be used like a “companion standard” should be published and made available in English language.

6.3 Other protocols

6.3.1 ZigBee SEP ZigBee Smart Energy enables wireless communication between utility companies and common household devices such as smart thermostats and appliances (MI4 interface in the

Work Package: 2


Date: 3.11.2009




reference architecture, see Figure 1). It improves energy efficiency by allowing consumers to choose interoperable products from different manufacturers giving them the means to manage their energy consumption more precisely using automation and near real-time information. It also helps utility companies implement new advanced metering and demand response programs to drive greater energy management and efficiency, while responding to changing government requirements. ZigBee Smart Energy offers innovative electric, gas and water utilities support for advanced metering, demand response, load control, pricing, and customer messaging programs. It provides communication and control for devices such as in-home displays, programmable communicating thermostats, water heaters, lighting, smart appliances, plug-in hybrid electric vehicles, plus energy service portals and energy management systems. It’s not to consider replacing DLMS or SML. Identified gaps are:

• With the SEP 1.0 the first step is done. The missing tunneling functionality is planned for the next version.

• For GAP GR18 (“System must be interoperable”):

- Mapping SEP to DLMS: see also 6.1 IEEE 802.15.4 (ZigBee and DLMS) - Mapping SEP to SML: no action known

6.3.2 KNX KNX (Konnex) is an open industrial standard (EN 50090), administered by the Konnex Association. in recent years it is moving from building automation to home applications. Then it could represent a good candidate for the MI5 interface in Figure 1. KNX could be coupled with different media: twisted pair; powerline; radio frequency, in the 868 MHz (Short Range Devices) frequency band, KNX Association worked together with CEN TC 294 WG5 and streamlined the parameters of the KNX RF Physical Layer (868 MHz-standard CEPT/ERC 70-03) and the Data Link Layer (based on the FT3-protocol IEC870-5-2) with the M-Bus specifications. Finally, the IP (ethernet): LAN networks as well as Internet can be used to route or tunnel KNX telegrams. Volume 7 of KNX Handbook provides a complete description of possibile applications (lighting, HVAC, access control,..) and Volume 10 specific application standards. Interoperability between devices from different manufacturer is fully guaranteed. Because of its diffusion, especially in the industrial sector, it is advisable to include KNX in the future phases of the project. Possible gaps are: cost (quite high for residential applications) and lacking of “KNX-ready” devices to be connected to the automation system (appliances, etc.).

Work Package: 2


Date: 3.11.2009




6.3.3 IEC 61850 In recent years, the IEC 61850 standard family is extending its scope from primary substation to distribution networks and secondary substation level (CI4 interface in the reference architecture, see Figure 1). This technology could represent an opportunity in the incoming process of integration between protection, control, measurement and monitoring functions within the substation, taking advantages from the availability of Ethernet communications. In future development of the project, evolution of this standard may have to be considered. The suitability of the "candidate technologies" to carry IEC 61850 PDUs (messages) and to support the substation automation processes must be investigated.

Work Package: 2


Date: 3.11.2009




7 Copyright

“Copyright and Reprint Permissions. You may freely reproduce all or part of this paper for non-commercial purposes, provided that the following conditions are fulfilled: (i) to cite the authors, as the copyright owners (ii) to cite the OPEN meter Project and mention that the European Commission co-finances it, by means of including this statement “OPEN meter. Energy Project No 226369. Funded by EC” and (iii) not to alter the information.”

Documents

OPEN meter_D2_3_V1 0 091103