OPEN Meter - D2 - 3 - V1 0 091103

Companion note to
OPEN meter Type of document: Deliverables D2.1, D2.2

Open Public Extended Network metering 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.
Work Package: 2
OPEN meter Type of document: Deliverable
Open Public Extended Network metering
Date: 3.11.2009
Energy Theme; Grant Agreement No 226369

Iberdrola, ACTARIS, ERSE, CTI, DLMS, EDF, ELSTER, ENDESA, KEMA, L&G,
Partners: RWE, STM, UKA, uSYSCOM, ZIV-Media
Responsible:
x Public
Circulation: Confidential
Restricted
Title: D2.3 Version: 1.0 Page: 1 / 48
D 2.3
IDENTIFICATION OF RESEARCH NEEDS FROM BOTTOM-UP

APPROACH
KNOWLEDGE GAPS
DUE DELIVERY DATE: M6
ACTUAL DELIVERY DATE: 10
© Copyright 2009 The OPEN meter Consortium
Project Funded by the European Commission under the 7th Framework Programme Project coordinated by
Work Package: 2
OPEN meter Type of document: Deliverable 2.3
Date: 3.11.2009
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
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 Selected Selected
Technology Technologies and Data models and

Type lower layer upper layer
protocols protocols
PRIME DLMS
MI1 – CI1 PLC
IEC 61334-5-1 SML
CI2 – SI1 Wireless UMTS DLMS
Work Package: 2
Date: 3.11.2009
Interface Selected Selected Selected
Technology Technologies and Data models and

Type lower layer upper layer
protocols protocols
GPRS SML
UMTS DLMS
MI2 – SI2 Wireless
GPRS SML
IEEE802.15.4-2006 DLMS
MI3, CI3 and MUMI2 Wireless
IEEE802.11-2007 SML
IEEE802.15.4-2006 DLMS
MUMI1 - MI4 Wireless IEEE802.11-2007 SML
Wireless M-Bus Wireless M-Bus
DLMS
Zigbee
CI4 Wireless SML
Wifi
IEC 61850
DLMS
Bluetooth
(IEEE802.15.1-2002)
MI5 Wireless SML
Zigbee
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.

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.

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 – CI2 – SI1 MI3 / MUMI2 MI5 CI4
MUMI1 / CI3
Communication media supported by DLMS/COSEM
IEC 61334-
PLC 5-1 S-FSK – – – – – –
PLC
PSTN??
Leased IEC 62056-
EN 13757-2 IEC 62056-
Wired – – lines? 21 optical / –
Wired M-Bus 21 Mode D
current loop
IEC
62056-46
IEC 62056- IEC 62056- IEC 62056-
31 Euridis 31 Euridis 31 Euridis
EN 13757-6
RS 485
Local M-Bus
EN 13757-4, EN 13757-4,
EN 13757-5 EN 13757-5
Wireless (Mode Q) (Mode Q)
– – – –
(dedicated)
Wireless M- Wireless M-
Bus Bus
Wireless GPRS / GPRS /
– – – – –
(public) UMTS UMTS
Internet Internet
Internet
– (Ethernet, – (Ethernet,
(public)
ADSL etc) ADSL etc)
Communication media currently not supported by DLMS/COSEM (gaps)
PLC Prime PLC – – – – – –
Wired – – – – – – –
Wireless IEEE IEEE IEEE
– – – –
(dedicated) 802.15.4 802.15.4 802.15.4
– – Zigbee – Zigbee Zigbee Zigbee
Wireless
– IEEE 802.11 IEEE 802.11 IEEE 802.11 –
(public)
– WIFI WIFI
– – – Bluetooth –
Work Package: 2
Date: 3.11.2009
Interfaces
M1-CI1 MI2 – SI2 MI4 – CI2 – SI1 MI3 / MUMI2 MI5 CI4
MUMI1 / CI3
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

Connection
ACSE xDLMS Security
manager ASE
Supp. layer
Supp. layer
AL
Wrapper
Appl. layer
Appl. layer
Appl. layer
TCP
IPv4
LLC layer LLC layer

Connectionless
(Protocol selection) (Protocol selection)
LLC layer
HDLC IEC 61334-4-32 HDLC
Supporting
layers
MAC +Phy layer

Phy layer
IEC 61334-5-1 S-FSK
3-layer,
TCP-UDP/IP IEC 61334-5-1 S-FSK PLC profiles
CO HDLC
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 can support the

SML over the interface /
interface / media but it has
media has been tested and
not been tested or
documented.
documented.
It does not make sense to SML over the interface /

use SML over the particular media has been tested but
interface / media. not documented.
Interfaces
Media M1-CI1 MI2 – SI2 MI4 – MUMI1 CI2 – SI1 MI3 / MUMI2 / MI5 CI4
CI3
PRIME
PLC 61334-51 (S-
FSK)
Ethernet Ethernet Ethernet
IEC 62056-21
EN 13757-2
optical /
(Wired M-Bus)
current loop
Wired
IEC 62056-31 IEC 62056-31
(dedicated)
Euridis Euridis
KNX KNX
RS 232 / EN 13757-6
RS485 (Local M-Bus)
Internet
Internet
Wired (Ethernet,
(Ethernet,
(public) ADSL
ADSL etc)
etc)
EN 13757-4,
EN 13757-5
(Mode Q)
Wireless
(Wireless M-
(dedicated)
Bus)
IEEE 802.15.4 IEEE 802.15.4
(Zigbee) (Zigbee)
GPRS / GPRS /
UMTS UMTS
Wireless
(public) IEEE IEEE
IEEE 802.11 IEEE 802.11
802.16 802.16
(WiFi) (Wi-Fi)
(WIMAX) (WIMAX)
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
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 SML Transport Protocol
Work Package: 2
Date: 3.11.2009
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 M-Bus/ SML Transport Protocol
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.”

OPEN Meter - D2 - 3 - V1 0 091103

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

OPEN Meter - D2 - 3 - V1 0 091103

Загружено:

Авторское право:

Доступные форматы

Companion note to

OPEN meter Type of document: Deliverables D2.1, D2.2

Companion note to Deliverables D2.1, D2.2 and D2.3

• D2.1: Description of current state-of-the-art of technology and protocols

in the context of the overall project:

Energy Theme; Grant Agreement No 226369

IDENTIFICATION OF RESEARCH NEEDS FROM BOTTOM-UP

DUE DELIVERY DATE: M6

ACTUAL DELIVERY DATE: 10

© Copyright 2009 The OPEN meter Consortium

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

UKA Michael Bauer

CTI Weilin Liu

L+G Heinz Hohl

DLMS User Association Gyozo Kmethy

ERSE Diana Moneta

uSysCom Aitor Arzuaga

RWE Olaf Neumann

CTI Markus BITTNER

ENDESA Robert Denda

L+G Thomas Schaub

KEMA Willem Strabbing

Iberdrola Inigo Berganza

GLOSSARY AND ACRONYMS

GEO GEostationary Orbit

PHY PHYsical layer

2.1 Reference Architecture

Figure 1 – OPEN meter system architecture

Interface Selected Selected Selected

Technology Technologies and Data models and

CI2 – SI1 Wireless UMTS DLMS

Interface Selected Selected Selected

Technology Technologies and Data models and

MUMI1 - MI4 Wireless IEEE802.11-2007 SML

Wireless M-Bus Wireless M-Bus

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

4 KNOWLEDGE GAPS – PLC TECHNOLOGIES

4.1 Analysis of General Knowledge Gaps

4.1.2 Gaps related to EN 50065

It should be analysed if the EN 50065 could be amended by extending specified frequency

4.1.2.2 Assignment of frequency bands to user groups

It has to be clarified whether the assignment of frequency bands, as described in EN 50065,

PLC devices may disturb other equipment.

4.2 KNOWLEDGE GAPS – INTERFACE MI1-CI1

4.2.1.1.1 PRIME conformance test modes and conditions

attenuation model reflecting real-world scenarios is required and a corresponding test

4.2.1.1.2 Coexistence of PLC technologies

4.2.1.1.3 Additional provisions to ensure coexistence with incumbent radio services

4.2.1.2.2 Error control overlay to improve robustness in impulsive noise conditions

Research and development need:

4.2.1.2.3 Identification of possibly unreliable communication links and corresponding

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

Research and development need:

4.2.1.3.1 Feasibility of in-system communication performance tests

Research and development need:

4.2.1.4 Transmission performance

4.2.1.4.1 Data Rate under real-world communication scenarios