OPEN-Meter WP2 D2.1 Part4 v1.0

Open Public Extended Network metering
OPEN meter
Work Package: Type of document: Date:
WP2/T2.1.3 Deliverable 19.06.2009
Energy Theme; Grant Agreement No 226369 Partners: Responsible: Circulation: Title: D2.1/4
CESI-R, DLMS, ENEL, KEMA, LANDIS&GYR, RWE CESI-R X Public Confidential Restricted State-of-the-art technologies & protocols
Version: 1.0
Page: 1 / 72
D 2.1/PART 4 STATE-OF-THE-ART TECHNOLOGIES & PROTOCOLS DESCRIPTION OF STATE-OF-THE-ART COMMUNICATION

PROTOCOLS AND DATA STRUCTURES
DUE DELIVERY DATE: 30.03.2009 ACTUAL DELIVERY DATE: 19.06.2009

Copyright 2009 The OPEN meter Consortium
Project Funded by the European Commission under the 7th Framework Programme
Project coordinated by
OPEN meter
Work Package: Type of document: Date: Version:1.0
Energy Theme; Grant Agreement No 226369 Title:

State-of-the-art technologies & protocols Page: 2 / 72
Document History
Vers. 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 Issue Date 12.03.09 17.03.09. 18.03.09 23.03.2009 23.03.2009 30.03.2009 31.03.2009 20.04.2009 22.04.2009 19.06.2009 Content and changes ToC comments from the DLMS UA / RWE / KEMA revised ToC revised ToC (application / network layer) overview table first inputs draft completed final inputs and comments from partners inputs from ENDESA, Actaris Final document (with comments from TC)
Document Authors
Partners CESI RICERCA DLMS UA ENEL KEMA LANDIS & GYR RWE ACTARIS ENDESA Contributors Giuseppe Mauri, Diana Moneta Gyozo Kmethy Giuseppe Fantini Willem Strabbing, Wolf Freudenberg Heinz Hohl, Thomas Schaub Timm Gerbaulet, Hans-Werner Kneitinger, Thomas Wiedemann, Gerhard Radtke Frederic Tarruell Jos Comabella
Document Approvers
Partners CTI Approvers Markus BITTNER
OPEN meter
Energy Theme; Grant Agreement No 226369 Title: DLMS UA KEMA RWE

Gyozo Kmethy Willem Strabbing, Wolf Freudenberg Timm Gerbaulet
OPEN meter

TABLE OF CONTENTS 1 2 3 4 PURPOSE INTRODUCTION KEY CHARACTERISTICS OF AMR KEY CARACTERISTICS FOR AMI AND HOME AUTOMATION 4.1 GATEWAY BETWEEN AMI AND HOME AUTOMATION SYSTEM 4.2 DER CONTROL 5 TECHNOLOGIES OVERVIEW 6 COMMUNICATION PROTOCOLS AND DATA STRUCTURES 6.1 IEC 61334 S-FSK PLC 6.1.1 Introduction 6.1.2 Status of standardization 6.1.3 Support organization 6.1.4 Conformance testing and product certification 6.1.5 Field of application 6.1.6 Summary of technical features 6.1.7 Summary 6.2 IEC 62056-21 FLAG 6.2.1 Introduction 6.2.2 Status of standardization 6.2.3 Support organization 6.2.4 Conformance testing and product certification 6.2.5 Field of application 6.2.6 Summary of technical features 6.2.7 Summary 6.3 IEC 62056-31 EURIDIS 6.3.1 Introduction 6.3.2 Status of standardization 6.3.3 Support organization 6.3.4 Conformance testing and product certification 6.3.5 Field of application 6.3.6 Overview of technical features 6.3.7 Summary 6.4 DLMS/COSEM: IEC 62056, EN 13757-1 6.4.1 Introduction 6.4.2 Status of standardization 6.4.3 Support organization 6.4.4 Conformance testing and product certification 6.4.5 Field of application 6.4.6 Overview of technical features 6.4.7 Summary 6.5 M-BUS: EN 13757 6.5.1 Introduction 6.5.2 Status of standardization 6.5.3 Support organization 6.5.4 Conformance testing and product certification 12 13 15 15 16 17 17 19 19 19 19 20 20 20 21 22 22 22 23 23 23 23 24 24 24 24 25 25 25 25 26 26 26 26 28 29 30 30 31 37 38 38 38 39 40
OPEN meter

6.5.5 Field of application 6.5.6 Summary of technical features 6.5.7 Summary 6.6 SMART MESSAGE LANGUAGE (SML) 6.6.1 Introduction 6.6.2 Status of standardisation 6.6.3 Support organization 6.6.4 Conformance testing and product certification 6.6.5 Field of application 6.6.6 Data model 6.6.7 Communication media supported 6.6.8 Summary 6.7 IP TELEMATRIC PROTOCOL E-DIN 43863-4 6.7.1 Introduction 6.7.2 Status of standardisation 6.7.3 Support organization 6.7.4 Conformance testing and product certification 6.7.5 Field of application 6.7.6 Data model 6.7.7 Communication media supported 6.7.8 Summary 6.8 IEC 60870-5 6.8.1 Introduction 6.8.2 Status of standardisation 6.8.3 Support organization 6.8.4 Conformance testing and product certification 6.8.5 Field of application 6.8.6 Data model 6.8.7 Communication media supported 6.8.8 Summary 6.9 IEC 61968-9 6.9.1 Introduction 6.9.2 Status of standardization 6.10 SITRED 6.10.1 Introduction 6.10.2 Protocol Layers 6.11 PRIME 6.12 IEC 61850 6.12.1 Data Information 6.12.2 Logical nodes for the DER plant ECP logical device 6.13 KNX 6.14 ZIGBEE SMARTENERGYPROFILE 6.15 6LOWPAN 6.16 HOMEPLUG 6.17 Z-WAVE 6.18 WAVENIS 6.19 EVERBLU 6.19.1 Introduction 6.19.2 Status of standardization
40 40 44 44 44 46 46 47 47 47 49 50 51 51 51 51 51 52 52 53 53 54 54 55 55 55 55 55 55 56 56 56 57 57 57 58 58 59 59 60 62 63 64 65 65 66 66 66 66
OPEN meter

6.19.3 Field of application 6.19.4 Summary of technical features 6.20 OPERA/UPA 6.21 ITU-G.HN 6.21.1 G.hn Overview 6.21.2 G.hn security 6.21.3 G.hn Layered reference model 6.21.4 G.hn industry support 7 CONCLUSIONS ERROR! BOOKMARK NOT DEFINED. 8 COPYRIGHT ERROR! BOOKMARK NOT DEFINED.
66 67 68 68 68 69 70 71
LIST OF TABLES
Tab. 1 IEC 62056-31 protocol stacks ................................................................................................................. 26
TU UT
LIST OF FIGURES
Fig. 1 General architecture ................................................................................................................................. 13 Fig. 2 The three step approach of DLMS/COSEM ............................................................................................. 27 Fig. 3 COSEM interface objects ......................................................................................................................... 32 Fig. 4 DLMS/COSEM communication profiles examples ................................................................................ 36 Fig. 5 SML communication model ...................................................................................................................... 46 Fig. 6 SML messages and communication paths ................................................................................................ 49 Fig. 7 DIN 86436-4 data model .......................................................................................................................... 52 Fig. 8 PRIME architecture .................................................................................................................................. 59 Fig. 9 IEC 61850 Information model hierarchy ................................................................................................... 60 Fig. 10 Example of ECP for DERs ..................................................................................................................... 61 Fig. 11 ZigBee layers ......................................................................................................................................... 64 Fig. 12 EverBlu architecture ............................................................................................................................... 67 Fig. 13 G.hn layered model ................................................................................................................................ 70
TU UT TU UT TU UT TU UT TU UT TU UT TU UT TU UT TU UT TU UT TU UT TU UT TU UT
OPEN meter

GLOSSARY AND ACRONYMS OPEN meter AMR Open Public Extended Network metering Automatic meter reading technologies include handheld, mobile and network technologies based on telephony platforms (wired and wireless), radio frequency (RF), or power line transmission Advanced Metering Infrastructure refers to systems that measure, collect and analyse energy usage, from advanced devices such as electricity meters, gas meters, and/or water meters, through various communication media on request or on a pre-defined schedule. Solutions include a wide range of applications in the field of remote meter reading, customer relationship management, demand-side management and value added services.
AMI
3rd Generation telephony Application Association Association Control Service Element Application Entity Advanced Encryption Standard Application Process Application Service Element Bill of Material Central Access Server Council of European Energy Regulators Comit Europen de Normalisation European Committee for Electrotechnical Standardization Configuration Initiation ASE (S-FSK PLC) Companion Specification for Energy Metering Conformance Test Tool (DLMS/COSEM) Data Concentrator Distributed Energy Resources Distribution Line Carrier (same as PLC) Distribution Line Message Specification (IEC 61334-4-41) Device Language Message Specification (IEC 62056) DSM Demand Side Management ESCO Energy Service Company EU European Union EURELECTRIC The association of the electricity industry in Europe GCM Galois/Counter Mode (cryptography) GO Grid Operator GPRS General Packet Radio Service GSM Global System for Mobile communications GSM/GPRS Global System for Mobile communications/General Packet Radio Service HA Home Automation HEMS Home & Building Management System HVAC Heating, ventilating, and air conditioning
3G telephony AA ACSE AE AES AP ASE BOM CAS CEER CEN CENELEC CIASE COSEM CTT DC DER DLC DLMS
OPEN meter
Energy Theme; Grant Agreement No 226369 Title: IC IEC IEEE IP ISP LD LLC LV MAC MIB M&S MV OBIS OFDM OSI PDU PHY PLC PSTN SDU S-FSK TCP TCP/IP
Interface class (COSEM) International Electrotechnical Commission Institute of Electrical and Electronic Engineers Internet Protocol Independent Service Provider Logical Device (COSEM) Logical Link Control Low Voltage Medium Access Control Management Information Base Metering & Switching equipment Medium Voltage Object Identification System Orthogonal Frequency Division Multiplex Open Systems Interconnection Protocol Data Unit Physical layer Power Line Carrier / Power Line Communication Public Switched Telephone Network Service Data Unit Spread Frequency Shift Keying Transmission Control Protocol Transport Control Protocol / Internet Protocol
OPEN meter

Name Measuring and switching equipment
Description All equipment installed at the premises of the consumer for measuring consumption of commodities or for (dis)connecting the consumer. The equipment therefore includes: E meter, E-breaker, G meter, G-valve (the same for heat and water) and a communications module. Equipment with measurement functions for electricity, gas, heat, and water. The equipment therefore includes E meters, G meters, H meters, and W meters. All equipment installed at a network hub. Primary function is to facilitate communication with M&S equipment over the network and with central systems over the telecom network. Secondary function is to provide functionality for optimisation of data transfer. The equipment is implemented in a Data Concentrator that therefore includes a communication module. The communication module can be either modular component or integrated part of the Data Concentrator. Data concentrator is present if PLC or Wireless LAN is used. When GPRS is used, then metering equipment communicate directly with the CAS. All equipment installed at the premises of the consumer for measuring consumption of electricity or for (dis)connecting electricity. E-equipment therefore includes: E meter and E-breaker. All equipment installed at the premises of the consumer for measuring consumption of gas or for (dis)connecting gas. G-equipment therefore includes: G meter and G-valve. All equipment installed at the premises of the consumer for measuring consumption of heat or for (dis)connecting it. H-equipment therefore includes: H meter and H-valve. All equipment installed at the premises of the consumer for measuring consumption of water or for (dis)connecting it. W-equipment therefore includes: W meter and W-valve. The implementation of Communication equipment installed at a network hub.
Abbrev. M&S equipment
Metering equipment
Communication equipment
E-equipment
G-equipment
H-equipment
W-equipment
Data Concentrator
DC
OPEN meter

Name Meter State-of-the-art technologies & protocols Description Residential measuring device for either electricity, gas, heat, and water. Meters include E meter, G meter, H meter, and W meter. Residential measuring device for registration of electricity consumption and communication. The part of the E meter that handles communication, the communication module, can be either a modular component or an integrated part of the E meter. Residential measuring consumption. Residential measuring consumption. Residential measuring consumption. device for registration of gas Page: 10 / 72 Abbrev.
E meter
G meter
H meter
device
for
registration
of
heat
W meter
device
for
registration
of
water
Switch
Switching device for either electricity or gas, heat and water. Switching devices for E are called (E-) breakers, switching devices for G are called (G-) valves. The function location for E-equipment. The function location for G-equipment. The function location for H-equipment. The function location for W-equipment. The function location for DC equipment The equipment that is responsible for communication between M&S equipment at a connection and other entities (i.e. central systems or DC equipment). The equipment and software used by the GO to handle requests from Service Companys and ISPs with respect to metering installations. The CAS is also referred to as the central system. CAS
E-connection G-connection H-connection W-connection Network hub Communication module
Central access server
OPEN meter

Name Equipment identifier State-of-the-art technologies & protocols Description A global identifier for the equipment. The equipment identifier is composed of three parts: meter type, serial number and year of manufacturing. The equipment identifier should also include the identifier of the manufacturer. Equipment identifiers are represented as bar codes and also human readable codes. The equipment installed on a connection is composed of multiple pieces of equipment. This equipment is connected through a local network. The E meter functions as a local host for this network and is referred to as the local host in the context of its function as a network component. Equipment provided by an Independent Service Provider or Energy Supplier that can be attached to the P1 port and can receive and process the information provided on P1, e.g. an inhouse Energy Monitor. Also referenced as Other Service Module (OSM). All meters in the distribution area serviced by the DC through a Power Line Carrier (PLC) network. OSM Page: 11 / 72 Abbrev.
Local host
Auxiliary equipment
DC service area
OPEN meter

1 PURPOSE
The conventional functionality of Automatic Meter Reading (AMR) is changing in the direction of Smart multi-metering or multi-functional Advanced Metering Infrastructure (AMI) capable of creating value for energy consumers, network operators, metering operators and retailers. The future AMI supporting the electricity grid will have to include both distributed power generation and consumption, transporting not only electricity but also bi-directional data. This infrastructure includes hardware, software, communication channels, customer associated systems and meter data management software. This document lists communication protocols and data structures currently used for AMR and AMI solutions. In addition, further protocols, not specifically developed for AMR and AMI applications, will be described in short to highlight their possible application in this field.
OPEN meter

INTRODUCTION
In order to have a good overview of the scope and the corresponding protocols used for AMR and AMI, Figure 1 presents the general architecture (interfaces), according to D1.1 scheme. Besides the fact to have an overview, it is important to clearly define the interfaces for both AMR and AMI.
Fig. 1 General architecture With reference to above figure, the following ports can be identified: Port MI1 for the communication between the metering installation and the Data Concentrator (DC). Port MI2 for the communication between the metering installation and the Central Access Server (CAS). Port MI3 for communication with external devices (e.g. hand-held terminal) during installation and on-site maintenance of the metering installation. Port MI4 for the communication between the metering system and one or more metering instruments and/or grid company equipments. The data models and protocols available for use on MI4 are described in chapter 6. The connection to the communication module or Emeter can be a bus system or a serial connection. Port MI5 for the communication between the metering installation and ISP module or auxiliary equipment (a maximum amount of appliances can be connected). MI5 should
OPEN meter

be a bi-directional interface; it can be used for sending data to the metering system. An example for this port is a display and/or a switch. The data models and protocols available for use on MI5 are described in chapter 6. When a Data Concentrator is present, the interface is split to two sections: MI1 between the E-meter/communication module and the DC, and CI2 between the DC and the Central system. The data models and protocols available are described in chapter 6. Port SI3 is the port on the CAS with which independent service providers, suppliers and grid companies gain access to the CAS. Note that SI3 is outside the scope of this document. The roles assigned to this figure may have an impact of the protocols to be used. The roles are as follows: Service providers It is foreseen that ISP or suppliers will provide information to the customers based on the meter data respecting the rules for privacy. The application for this can be various: offers for new contracts, energy savings and warnings regarding anomalous energy consumption. In the case of a pre-paid contract corresponding information such as the remaining credit can be displayed. A two way communication on this level is mandatory to allow intelligent functions regarding demand side management, distributed energy resources and energy savings.
U U
Supplier/Grid operator/Meter data responsible According to the European liberalised energy market, customers have a single company to deal with (supplier or retailer). The grid operator or the meter data responsible party is responsible for the installations of the metering equipment, but in this scenario they dont interact directly with end-users. The module can communicate via the Grid using Power Line Carrier, or over the Internet, or finally on a public or dedicated wireless network (GPRS for example). Connection of all utility meters to the communication module shall be possible. For information of the energy end-user, a customer display unit is necessary, which may have additional functions. In addition to the electricity breaker / gas valve generally integrated to the E-meter and G-meter respectively, the control of external switches may be useful.
U
The breaker/valve can be used to connect / disconnect the supply to the premises when: the contract is opened / closed; in a pre-payment mode, when the credit is exhausted; when the consumption exceeds a pre-set limit. The limit may be a normal operational limit or an emergency limit; after a disconnection, re-connection may be performed by a remote command or manually, if enabled.
OPEN meter

3 KEY CHARACTERISTICS OF AMR

Part 1 provides a detailed analysis of functions to be offered by the Automated Meter Reading technologies. Here only main information are described. AMR technologies include handheld, mobile and network technologies based on telephony latforms (wired and wireless), radio frequency (RF), or power line carrier (PLC). The key characteristic of AMR is that data necessary for billing are collected in an automated way. This task can be performed: locally using hand held terminals, via an optical port, a current loop or any other suitable interface. The most widespread standard for this purpose is IEC 61107 / IEC 62056-21; locally, with the meters connected to a local bus system. The two most widely used standards for this are Euridis, IEC 62056-31 and M-Bus specified in the EN 13757 series. Euridis is widely used in France and M-Bus is widely used in Germany; remotely, using suitable media, like PSTN, GSM, GPRS, Power line carrier, the Internet, and radio mesh networks. These can be one way or two way. The main meter functions are: measurement of energy consumption and demand. In the case of electricity meters, two way energy flow import / export may be measured, to allow integrating local / distributed energy generation, load profiling; power quality measurement; load monitoring and load management: limitation, disconnect / reconnect; event monitoring and logging, including tamper; customer information, etc.
U U
4 KEY CARACTERISTICS AUTOMATION
FOR
AMI
AND
HOME
Advanced Metering Infrastructure (AMI) refers to systems that measure, collect and analyse energy usage data, from advanced devices such as electricity meters, gas meters, heat meters, and/or water meters, through various communication media on request or on a predefined schedule. Remote meter reading and customer information are the core application. AMI solutions can also be used to support customer relationship management, demand-side management, as well as enable various value added services. When addressing the architecture of the AMI, a clear distinction has to be made between system architecture and protocol architecture: The system architecture concerns the role of the E-meter as a gateway, the need (or not) and the location of concentrators, the allocation of certain functions to the various system elements...etc. It may depend on factors like market organization, the communication
OPEN meter

technology selected, whether the smart system rollout is done by the network company the retailers or other entities, the business case drawn up for a certain project etc. The protocol architecture concerns the set of protocol layers selected and the way a lower layer supports the higher layers. Ideally, a common application data model (object model) and common higher protocol layers can be supported by various sets of lower layers, which are themselves dependent on the communication media selected.
AMM means Automated Meter Management systems, communication need to be two ways in order to provide advanced functionalities, like customers relation management, demand side management, local power quality monitoring etc. Several business processes could be considered: customer management, including supplier change energy supply / billing; (pre)payment; load management; network condition and health monitoring; meter condition and health monitoring; outage management; energy services. As a summary, the right system architecture depends on: - the market organization; - the media to be covered; - the communication media used.
4.1
Gateway between AMI and Home Automation System
In several countries energy authorities are considering the opportunity to adapt their Demand Side Management (DSM) strategy to the new liberalised scenario involving LV customers. The customers ability to participate to the energy market will be substantially represented by the aptitude of modulating their own load profile as result of market signals (electricity price) or network signals (emergency). Generally, one refers to Demand Side Management (DSM) of the electric power meaning actions aimed to stimulate final users to modify their demand habits, in response to price signals and other relevant information, hopefully without decreasing the present level of the services offered. DSM requires exchanging information between utilities, meters and load control devices (when available at user side). Therefore, AMI could communicate not only with the distributor but also with customer with to some extent. The content of messages may range from energy prices and meter readings, to complex data structures and commands in case of users deploying advanced load control systems or, even, in the case of third party companies, like Energy Services Company (ESCO), responsible for energy management of user premises.
OPEN meter

Usual applications of Home & building management systems (BEMS) include security, blinds and lighting automation, HVAC, as separate systems. The Local Energy Management system combines signals received from retailer (tariffs) and user preferences regarding comfort and maintains maximum power flow with the network under a specified threshold (that may change every hour). Load and heating management could be proposed, i.e. the possibility of switching off/on some appliances when particular circumstances occur or decide whether if it is better to use electric or gas devices for HVAC purposes.
4.2
DER control
The European Commission and national regulations are supporting a wide diffusion of Distributed Energy Resources (DER). In the future, ancillary services as frequency and voltage control, power balancing, restoration of supply could be requested to local generators. The electricity meter shall receive disconnection/reconnection order from the network operator system as well as disconnection/connection confirmation from external device through the data concentrator or through the meter. In future phases of the OPENmeter project these aspects will be evaluated. In the following, it is highlighted when a protocol supports DER control.
5 TECHNOLOGIES OVERVIEW
This document is a state-of-the-art on Technologies and Protocols. The assessment process will be carried out in further deliverables of WP2. Communication media that may be suitable for the purposes of AMR / AMI are the following: PSTN; GSM/GPRS/UMTS (or other 2.5/3G technologies); Powerline Communication (PLC); Ethernet; Wireless / radio mesh network.
A detailed description of communication technologies is provided in deliverable D2.1 part 2 and part 3. The following table summarizes main characteristics for each protocol.
Field of application AMI Y Y 6.2 6.3 6.4 6.5 Y 6.6 6.7 NA Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y NA NA 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16 6.17 6.18 6.19 6.20 6.21 Y Y Y Y Y NA NA NA NA NA Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y NA NA Y Y Y Y Y Y Y NA Y Y Y Y 6.1
Home automation
Communication media supported Local bus PSTN GSM GPRS Internet PLC Walk by radio Mesh radio Ref. para
Title:
Specification
Local AMR
Remote AMR
Data model
IEC 61334 PLC
IEC 62056-21FLAG
IEC 62056-31 Euridis
IEC 62056 DLMS/COSEM
EN 13757 M-Bus
SML
OPEN meter
DIN 43863-4
IEC 60870-5
IEC 61968-9
NA
NA
Energy Theme; Grant Agreement No 226369
SITRED
State-of-the-art technologies & protocols
PRIME
Date:
I IEC 61850
KNX
Work Package:
Zigbee SmartEnergy
Type of document:
6LoPAN
Version:1.0
Homeplug
Z-Wave
Wavenis
Deliverable
19.06.2009
WP2/T2.1.3
EverBlu
Page: 18 / 72
OPERA/UPA
ITUG.hn
OPEN meter

6 COMMUNICATION STRUCTURES
PROTOCOLS
AND
DATA
For each protocol, the following information is provided (when available): general description; status of standardization, support organization, availability of conformance testing and product certification; field of application: Local AMR, Remote AMR, AMI, Home Automation; DER control only whe supported; summary of technical features: protocol stack, system architecture.
6.1
IEC 61334 S-FSK PLC
For a detailed description of Narrow Band PLC technologies (NPL), please refer to part 2 chapter 3. 6.1.1 Introduction
The IEC 61334 S-FSK profile is part of the IEC 61334 standard suite, developed by IEC TC 57 WG09 at the end of the 90-ies. It is a narrow band PLC technology working in the CENELEC A Band (EN 50065) and using spread frequency shift keying (S-FSK) modulation. Several meter and chip manufacturers are supporting it. The IEC 61334 standard suite also specifies the upper layers: an optional network layer, the Application layer and the DLMS application protocol. Recently, S-FSK PLC has been selected for the Dutch DSMR project. In these project, the lower layers (PHY + MAC + LLC) are used with the upper layers of DLMS/COSEM: the COSEM application layer and the COSEM data model to support smart metering / AMI functionality. This is the MI1 interface between the meters and the Data Concentrators (see 6.4.6.4). The French ERDF project also uses this profile. 6.1.2 Status of standardization
The relevant standards are the following: IEC 61334-4-32 Ed. 1.0:1996, Distribution automation using distribution line carrier systems Part 4: Data communication protocols Section 32: Data link layer Logical link control (LLC) IEC 61334-4-41 Ed.1.0:1996, Distribution automation using distribution line carrier systems Part 4: Data communication protocols Section 41: Application protocols Distribution line message specification
OPEN meter

IEC 61334-4-42 Ed. 1.0: 1996, Distribution automation using distribution line carrier systems Part 4: Data communication protocols Section 42: Application protocols Application layer IEC 61334-4-511 Ed. 1.0:2000, Distribution automation using distribution line carrier systems Part 4-511: Data communication protocols Systems management CIASE protocol IEC 61334-4-512 Ed. 1.0:2001, Distribution automation using distribution line carrier systems Part 4-512: Data communication protocols System management using profile 61334-5-1 Management Information Base (MIB) IEC 61334-5-1 Ed. 2.0:2001, Distribution automation using distribution line carrier systems Part 5-1: Lower layer profiles The spread frequency shift keying (S-FSK) profile These are open international standards. 6.1.3 Support organization
The DLMS UA has extended the COSEM data model with the necessary interface classes / objects to support the S-FSK profile, and specified the new S-FSK PLC communication profile. These new elements are supported by the DLMS UA, and they will become part of the IEC 62056 standard suite. IEC TC 13 and IEC TC 57 will establish a co-operation on maintaining the IEC 61334 series. 6.1.4 Conformance testing and product certification
Performance criteria are defined in IEC 61334-5-1 Ed. 2.0:2001 Distribution automation using distribution line carrier systems Part 5-1: chapter 2.4 Performance Tests. 6.1.5 Field of application
6.1.5.1 Local AMR Not supported. 6.1.5.2 Remote AMR Supported. 6.1.5.3 AMI Supported when used with IEC 62056 DLMS/COSEM. 6.1.5.4 Home Automation Not supported.
OPEN meter
Energy Theme; Grant Agreement No 226369 Title: 6.1.6

Summary of technical features
In this document only main information are described. For further details, please refer to part 2 of this deliverable. 6.1.6.1 The protocol stack The S-FSK profile uses a collapsed OSI model: the physical and MAC layers are specified in IEC 61334-5-1. It specifies the S-FSK modulation scheme, and the services and protocols of the PHY and MAC layers. It also describes the repetition mechanism used to extend the action radius of the PLC signal. For details, please see 6.7.1 in part 2. the connection-less LLC layer specified in IEC 61334-4-32; the IEC 61334-4-42 Application layer with the IEC 61334-4-41 DLMS Application protocol; or the IEC 62056-53 COSEM Application layer, with the IEC 62056-52 COSEM interface classes and the IEC 62056-61 OBIS object identification system (used in the Dutch DSMR and the French ERDF projects); the CIASE protocol, IEC 61334-4-511 specifies how the concentrator (initiator) searches for meters and registers them. The CIASE protocol uses the services of the LLC layer. The DLMS UA has specified an intelligent initiator search mechanism and a Ping service to keep the meters alive. Revision of the standards will be initiated with IEC TC 57; the IEC 61334-4-512 MIB standard specifies management variables for the protocol layers. For the purposes of using the S-FSK PLC profile with DLMS/COSEM, these variables have been mapped to attributes and methods of S-FSK PLC setup COSEM objects. 6.1.6.2 System architecture An LV PLC system consists of one concentrator (also known as initiator) per MV/LV transformer and several meters along the distribution network supplied by that transformer. All communication is initiated by the concentrator. Meters can only access the medium when requested by the concentrator. Data from the concentrator may be stored and are forwarded to the meter management center via a suitable protocol. Example: using web services between the concentrator and the Central Access Server In the Dutch DSMR specification, web services are used between the concentrator and the Central Access Server (CAS), the meter management system. This is specified as the CI2 interface. The salient points are the following.
U
The CI2 interface is introduced because Data Concentrator (DC) can be placed between the Central Access System (CAS) and meters. DC divides the MI2-SI2 interface from the meter to the CAS into two parts: MI1-CI1 and CI2-SI1, where MI1 is based on DLMS/COSEM standard with S-FSK PLC and CI2 is based on Internet standards. The CI2 interface is based on Service Oriented Architecture (SOA) where standards are implemented with Web Services (SOAP) and XML.
OPEN meter

Web Services interoperability is achieved with compliance to WS-I Basic Profile 1.1 or WS-I Basic Profile 1.2. WS-I Basic profiles determine standards which can be used and the guidelines for using them. The following items are addressed: Transport (HTTP and HTTPS); Messaging (SOAP and XML); Service Description (WSDL and XML Schema); Service Publication and Discovery (UDDI); Service Composition (WS-*); Security (SSL/TLS-). CI2 interface uses WS-ResourceTransfer and WS-Eventing to model meter access resources with Web Services. Both Request/Response and Publish/Subscribe message exchange patterns are supported. Meter access resources enable access to COSEM objects in the meters; in other words, the web services know that the resources they are accessing are COSEM objects. 6.1.7 Summary
S-FSK PLC provides reliable communication over power / distribution lines by combining frequency diversity, a robust repetition scheme and extensive error control. Combined with DLMS/COSEM it supports smart metering / AMI functionality. This profile has been selected by the Dutch DSMR project and the French ERDF project.
6.2
6.2.1
IEC 62056-21 Flag

Introduction
IEC 62056-21 is the third edition of the well-known IEC 1107 standard, also known as the Flag protocol. Although it was intended for local data exchange using hand held units (HHU), it is also widely used for remote data exchange with PSTN and GSM modems. It specifies three local physical interfaces: optical, current loop and V.24 / V.28, as well as a data transmission protocol. The protocol permits reading and programming of devices, basically by reading and sending information represented by ASCII characters to / from given memory locations. The following communication modes are available: Mode A supports bi-directional data exchange at 300 baud without baud rate switching. This protocol mode permits data readout and programming with optional password protection; Mode B supports bi-directional data exchange with baud rate switching. This protocol mode permits data readout and programming with optional password protection;
OPEN meter

Mode C supports bi-directional data exchange with baud rate switching and permits data readout, programming with enhanced security and manufacturer-specific modes; Mode D supports unidirectional data exchange at a fixed baud rate of 2400 baud and permits data readout only; Mode E supports advanced protocols, like DLMS/COSEM.
The mode can be negotiated by the HHU and the meter. A meter can support more than one mode: today, support of Mode C and Mode E with DLMS/COSEM is common practice. 6.2.2 Status of standardization
The current standard has been established by IEC 62056-21 WG 14: IEC 62056-21 Ed. 1.0:2002, Electricity metering Data exchange for meter reading, tariff and load control Part 21: Direct local data exchange (third edition of IEC 61107) The standard is open and widely used. However, the memory mapping is not standardized, therefore data exchange requires manufacturer specific information. Meters of different types or from different manufacturers are not readily interoperable: each meter type needs a specific driver. Annex C of the standard specifies formatted codes, but these are not widely used. 6.2.3 Support organization
The mandatory three-letter manufacturer identifiers are allocated by the FLAG Association, in co-operation with the DLMS User Association. The same identifiers are also used for DLMS/COSEM. Some three hundred manufacturers have obtained their manufacturer ID. See at: http://www.dlms.com/organization/flagmanufacturesids/index.html
HTU UTH
6.2.4
Conformance testing and product certification
Not available. 6.2.5 Field of application
6.2.5.1 Local AMR Supported, by using a hand held or a permanently connected device. 6.2.5.2 Remote AMR Supported via PSTN or GSM modems. Several devices can be connected on a current loop. 6.2.5.3 AMI Supported when used in Mode E with DLMS/COSEM and remote two-way communication. 6.2.5.4 Home Automation Not supported.
OPEN meter

6.2.6
Summary of technical features
6.2.6.1 Data model Not available in modes A to D, data are located and manufacturer specific memory addresses. In Mode E, the COSEM data model and protocol stacks are used. 6.2.6.2 Communication media supported The current loop is a local bus supporting up to eight meters. PSTN and GSM are supported with appropriate modems. 6.2.7 Summary
This protocol was the first standard protocol for meter data exchange and is globally used. Today, its main use is for local data exchange.
6.3
IEC 62056-31 Euridis

HTU UTH
Source: http://www.euridis.org/ and the relevant standards and drafts. 6.3.1 Introduction
Euridis is a pragmatic and reliable solution for remote meter reading. Introduced at the beginning of the 1990's, the protocol has been standardised by IEC TC13 WG 14. The standard has been evolved from IEC 61142 to the actual IEC 62056-31. Nowadays, Euridis is the only standardised interface for the remote reading of electricity meters with a twisted-pair cable, using carrier signalling. Euridis: permits to read, write in all security and reliability; is a low cost solution; works with 100 meters between access points; is easy to read for customers and utilities; presents guarantee and openness of international standard (IEC 62056-31). M ain functions: remote reading of registers; remote programming; alarm call back and reset; energy remote supply (water, gas, heating, ...); automatic detection of equipment.
U
S ecurity: magnetic plug to prevent access;

U
OPEN meter

U
Page: 25 / 72
securised data.
U
S implicity: single twisted pair; no connecting and topology bus constraints. P erformance: up to 500 meters local bus; 3 minutes to read 100 meters; baud rate: 1 200 Baud.
U U
6.3.2
Status of standardization
The current standard has been established by IEC TC 13 WG 14: IEC 62056-31 Ed. 1.0:1999 Electricity metering Data exchange for meter reading, tariff and load control Part 31: Using local area networks on twisted pair with carrier signalling Beginning of 2009, an evolution has been proposed for international standardization: to increase speed from 1 200 to 9 600 Baud; to support DLMS/COSEM. IEC 62056-31 is an open standard. 6.3.3 Support organization
HTU UTH
The Euridis specification is supported by the Euridis Association: http://www.euridis.org/. It has some 30 members. 6.3.4 Conformance testing and product certification
A conformance test specification is available at: http://www.euridis.org/pdf/commitee/DossierDeTests_Ed05_GB.pdf

HTU UTH
The list of certified meters is not available. 6.3.5 Field of application
6.3.5.1 Local AMR Supported, by using a hand held or a permanently connected device, via a magnetic plug. Gateways to other protocols are possible. 6.3.5.2 Remote AMR Euridis is a pragmatic and reliable solution for remote meter reading.
OPEN meter
Energy Theme; Grant Agreement No 226369 Title: 6.3.5.3 AMI Not supported. 6.3.5.4 Home Automation Not supported. 6.3.6 Overview of technical features
6.3.6.1 Data model Euridis does not specify a data model. With the new evolution, DLMS/COSEM will be supported. 6.3.6.2 Communication media supported Euridis supports twisted pair local bus with carrier signalling. The standard uses a collapsed OSI model, as shown in Tab. 1. Tab. 1 IEC 62056-31 protocol stacks
With DLMS/COSEM Without DLMS Physical layer Link layer Application layer clause 3.1 clause 3.2 clause 3.3 With DLMS (future) clause 3.1 clause 4.2 Link-E/D IEC 62056-51 clause 3.1 clause 4.2 Link-E/D IEC 62056-53
6.3.7
Summary
IEC 62056-31 Euridis is a protocol for local bus using twisted pair with carrier signalling. It is widely used in France with more than 10 million meters installed in some Francophone countries and some other countries. A revision of the standard has been initiated to adapt it to new needs: higher speed; use with DLMS/COSEM.
6.4
6.4.1
DLMS/COSEM: IEC 62056, EN 13757-1

Introduction
DLMS/COSEM is an open international standard for data exchange with utility meters measuring any kind of energy, more generally, with intelligent devices. It has been developed at the end of the 1990s by leading utilities and meter manufacturers with the objective to provide a means for meter data exchange in a standard, interoperable, energy type and manufacturer independent way, over a range of communication media. To meet
OPEN meter

these objectives, DLMS/COSEM uses a three-step approach, illustrated in the following figure.
1. Modelling
COSEM Interface Objects

n io at i
Def
Register Attribute(s) 1. logical_name 2. value 3. scaler-unit Method(s) 1. reset

(static) (dyn.) (static)
0..n Data Type octet-string instance specific scal_unit_type m/o o
Class_id=3, Version=0
M DL
e Us
oc ss Max rA
Min
Protocol Services to access attributes and methods 2. Messaging

Communication Protocol
Messages : Service_Id( Class_Id, Instance_Id, Attribute_Id/Method_Id ) Encoding: ( APDU ) C0 01 00 03 01 01 01 08 00 FF 02

,.. EC ,I .
3. Transporting
O IS
Fig. 2 The three step approach of DLMS/COSEM Step 1, Application data modelling: this encompasses the COSEM interface object model and the OBIS data identification system; see 6.4.6.1 and 6.4.6.2.
U U
Step 2, Messaging: this encompasses services for using the data model. These are the DLMS services provided by the COSEM application layer; see 6.4.6.3.2.
U U
Step 3, Transporting: this encompasses communication profiles, i.e. the rules for transporting the APDUs through various communication channels; see 6.4.6.4.
U U
Key features of DLMS/COSEM:
OPEN meter

communication and messaging method independent data model and identification system: the COSEM interface objects, identified with OBIS codes, model the application independently of the messaging method and the communication method; multi-energy: all energy types electricity, gas, water and heat etc. are covered. The interface classes are the same, only their OBIS codes are media / energy type specific; self-description: the meter provides information on the resources the list of objects available. The meter also provides in each message the data type used. Consequently, the data collection system and the meter can exchange data based solely on the information taken from the standard and read from the meter, with minimum reliance on information coming from the manufacturer, like passwords, secrets, any manufacturing specific elements. This facilitates plug-and-play; DLMS messaging services common for all ICs / objects: these are used to access the attributes and methods of COSEM objects. This means that new interface classes can be specified to cover new functions, without affecting the protocols. For encoding, the efficient IEC 61334-6 A-XDR standard is used; client-server approach: the meters act as servers, providing the requested data / services to the meter management system, acting as a client. The meters can also send unsolicited information: alarms, pre-defined data sets (push operation); role based access: the server can provide a different scope of access to different clients playing different roles: end user, meter reader, utility engineer, manufacturer... OSI/Internet based protocol stacks carrying the messages. Any communication media, capable of carrying DLMS APDUs is suitable. The communication media currently supported are the following: local optical/electrical ports, PSTN, GSM, Internet, GPRS, PLC, M Bus, Euridis... separation of the data model and the protocols orthogonality: the data model and the protocols are neatly separated. The interface between them is provided by the DLMS messaging services. This means that the object model can be developed without affecting the protocols and the protocols can be developed without affecting the model. This renders the specification to be future proof; alternative messaging methods, like XML are possible and are under consideration; negotiation of capabilities: the client and the server can negotiate features and capabilities at all protocol layer levels and at the model level, to be used during the data exchange. This facilitates interoperability; flexibility and scalability: there are only a few mandatory elements in DLMS/COSEM which must be implemented. This allows building both simple and complex meters and thereby to optimize costs; data transport security: application layer level data transport security is available by using the AES-GCM-128 symmetric key algorithm, providing authenticated encryption. Status of standardization
6.4.2
DLMS/COSEM is internationally standardized by IEC TC 13 for electricity metering and by CEN TC 294 for metering other utilities than electricity. The relevant standards are the following:
OPEN meter

IEC 61334-4-41 Ed.1.0:1996, Distribution automation using distribution line carrier systems Part 4: Data communication protocols Section 41: Application protocols Distribution line message specification IEC 62056-46 Ed. 1.1:2007 Electricity metering Data exchange for meter reading, tariff and load control Part 46: Data link layer using HDLC protocol IEC 62056-47 Ed. 1.0:2006 Electricity metering Data exchange for meter reading, tariff and load control Part 47: COSEM transport layers for IPv4 networks IEC 62056-53 Ed. 2.0:2006 Electricity metering Data exchange for meter reading, tariff and load control Part 53: COSEM Application layer IEC 62056-61 Ed. 2.0:2006 Electricity metering Data exchange for meter reading, tariff and load control Part 61: Object identification system (OBIS) IEC 62056-62 Ed. 2.0:2006 Electricity metering Data exchange for meter reading, tariff and load control Part 62: Interface classes EN 13757-1:2002, Communication system for meters and remote reading of meters Part 1: Data exchange The most up-to-date version of the specification is available in the Coloured books issued by the DLMS UA. These books are available for all members free of charge: DLMS UA 1000-1 Ed. 9.0:2009, Blue Book COSEM Identification System and Interface Classes DLMS UA 1000-2: Ed.6.0:2007, Green Book DLMS/COSEM Architecture and Protocols (Edition 7.0 is in preparation) DLMS UA 1001-1 Ed. 3.0:2007, Yellow Book, DLMS/COSEM Conformance testing process. The revision of the IEC 62056 standards has been initiated to transfer the new elements to international standardisation. The IEC 62056 / EN 137571 DLMS/COSEM standards are open international standards. 6.4.3 Support organization
DLMS/COSEM is supported by the DLMS User Association, having some 130 members from some 50 countries. Membership is open to any person or organization active in meter
OPEN meter

data exchange. The membership fee is nominal. The DLMS UA maintains an official liaison with IEC TC 13 WG 14, acting as a registration authority and a maintenance agency. The DLMS UA provides the following services: registration of standard elements, like OBIS codes, interface class Ids; maintenance and development of the specification by the working groups, open to all members; specification of conformance testing; product certification; user support. For more, see: http://www.dlms.com/index2.php
HT TH
6.4.4
The DLMS UA has developed conformance test plans and provides a Conformance Test Tool, accessible to any members under fair and equal conditions. Both self-testing and third party testing is available. Certificates are issued by the DLMS UA. To date, 100+ meters types have been certified. See at: http://www.dlms.com/conformance/listofcompliantequipment/index.html
HT TH
6.4.5
Field of application
6.4.5.1 AMR with local data exchange DLMS/COSEM supports local data exchange for AMR via an optical port, current loop interface or RS-232. The physical interfaces are specified in IEC 62056-21. Most meters on the market support both Mode C using ASCII data transfer and Mode E using DLMS/COSEM. 6.4.5.2 AMR with remote data exchange DLMS/COSEM is widely used for AMR with two-way remote data exchange over various media. 6.4.5.3 AMI The functions modelled with the COSEM data model support all AMI functionality; see in 6.4.6. Combined with bi-directional data exchange, DLMS/COSEM supports AMI, and it has been selected, among others, as a basis of the Dutch and the French projects. 6.4.5.4 Home automation Home automation is currently not supported by DLMS/COSEM. However, DLMS/COSEM devices may serve as a gateway towards HA systems. The principles of the COSEM model also make it suitable to model HA functionality.
OPEN meter

Overview of technical features
6.4.6.1 The COSEM data model The COSEM data model presents the functionality of the meter at its interfaces. It specifies a library of COSEM interface classes (IC) and the OBIS Object Identification System. The functional requirements are mapped to COSEM objects delivering those functions. Each and every object is identified by its OBIS code. The COSEM model is independent of the communication media, so that the required functionality can be provided the same way over any media. Meters for any utilities like electricity, gas, water, and heat for any application segment, and of any complexity can be modelled and built. Using the COSEM model fosters a common understanding of the metering tasks among the various manufacturers, while leaving freedom in implementation and leaving scope for innovation. A COSEM Interface Class (IC) is characterized by a set of attributes and methods, which serve to describe some externally visible features of the class. Each attribute has a defined meaning; the first attribute (of each COSEM IC) is called the logical name. An attribute can be static, to hold configuration data, or dynamic, updated by the metering process. Each method defines a certain operation on one or more attributes. Attributes may be read or written and methods can be invoked remotely via the communication interface(s) or locally by the metering Application Process (AP). A COSEM IC may have several instances, called COSEM objects, identified with an OBIS code. The COSEM ICs are shown in the following scheme. The interface class Association controls a role-based access to the resources of the meter. The interface class Profile generic has a special importance: it allows packing any data set in single, self-descriptive objects, the contents of which can be retrieved with a single command.
OPEN meter

Base IEC local port setup class_id: 19 IEC HDLC setup class_id: 23 IEC twisted pair (1) setup class_id: 24 Modem configuration class_id: 27 Auto answer class_id: 28 S-FSK PHY&MAC setup class_id: 50 S-FSK Active initiator class_id: 51 S-FSK MAC sync timeouts class_id: 52 S-FSK MAC counters class_id: 53 S-FSK IEC 613344-32 LLC setup class_id: 55 S-FSK Reporting system list class_id: 56 IEC 8802-2 LLC Type 1 setup class_id: 57 IEC 8802-2 LLC Type 2 setup class_id: 58 IEC 8802-2 LLC Type 3 setup class_id: 59
Page: 32 / 72
Data class_id: 1
Association SN class_id: 12
Clock class_id: 8
TCP-UDP setup class_id: 41
Register class_id: 3
Association LN class_id: 15
Script table class_id: 9
IPv4 setup class_id: 42
Extended register class_id: 4
SAP Assignment class_id: 17
Schedule class_id: 10 Special days table class_id: 11 Activity calendar class_id: 20
Ethernet setup class_id: 43
Demand register class_id: 5 Register activation class_id: 6 Profile generic class_id: 7
Image transfer class_id: 18
PPP setup class_id: 44 GPRS modem setup class_id: 45 SMTP setup class_id: 46
Security setup class_id: 64
Register monitor class_id: 21 Single action schedule class_id: 22 Disconnect control class_id: 70 Limiter class_id: 71
Auto connect class_id: 29 M-Bus slave port setup class_id: 25 M-Bus client class_id: 72 Wireless Mode Q channel setup class_id: 73 M-Bus master port setup class_id: 74
Utility tables class_id: 26
Register table class_id: 61
Status mapping class_id: 63
Data storage
Access control and management
Time- and event bound control
Communication channel setup
Fig. 3 COSEM interface objects The COSEM interface classes allow modelling the various metering applications and functions of the meter like: energy and demand metering; measurement of instantaneous values; value monitoring; power quality measurement; gas volume conversion, gas quality measurement; time of use; scheduled activities; load profiles; event logging; load management; setting up the communication channels. A number of new interface classes and new object instances have been specified and added to the specification: connection / disconnection of supply to the premises (electricity breaker, gas valve); firmware update; security setup;
OPEN meter

S-FSK PLC channel setup; customer information; event / alarm handling; data exchange with M-Bus meters.
6.4.6.2 The OBIS Object identification system OBIS is a naming system, based on the German EDIS standard 1, which has been developed also in the 1990s. Its original purpose was to identify data on the meter display in a standard and unambiguous way. OBIS builds on EDIS and it is upper compatible with it. It is used to identify interface objects as well as data elements on the display. OBIS is a hierarchical system, consisting of six value groups A to F. In general, each lower-level value group provides a classification for the quantities identified by upper-level value groups: Value group A (the highest level in the hierarchy) identifies the energy type (media) to be measured. The value A = 0 identifies abstract, media or energy-type independent objects, common for all kind of meters; Value group B classifies the quantities identified by value group A; its typical use is to identify measurement channels; Value group C further classifies the quantities identified by value group A to B. Its typical uses are to identify physical quantities, like voltage, current, active / reactive / apparent power, pressure, volume, flow or abstract data items; Value group D further classifies the quantities identified by value group A to C. The meaning of each value depends on the values A to C. Its typical use is to identify the way a physical quantity is processed for example averaged, integrated, monitored; Value group E further classifies the quantities identified by value group A to D. The meaning of each value depends on the values A to D; its typical use is to identify tariff rates; Value group F further classifies the quantities identified by value group A to E; its typical use is to identify historical values.
T T
The range in each value group is 0 to 255. In some value groups, manufacturer-, country- or consortia-specific ranges are available. Standard OBIS codes are allocated by the DLMS UA. A document called Object definition tables, listing all defined combinations of the values in the six value groups, together with the interface class(es) and data type(s) to be used is maintained by the DLMS UA and it is available at http://dlms.com/members/ListOBIS.htm. It is used by the CTT for conformance testing of the COSEM interface objects.
HT TH
1 EDIS: Energy Data Identification System, DIN 43863-3

T T
OPEN meter

6.4.6.3 Messaging 6.4.6.3.1 Introduction
To exchange data with meters using the COSEM interface model, the information modelled has to be turned into a form, which can be transported via communication channels. Currently only one messaging method is specified, DLMS. Alternative messaging methods for example XML are possible and they are under consideration. 6.4.6.3.2 DLMS services DLMS specifies services and protocols to build messages carrying the information modelled and held by the COSEM objects that are transported over various communication media. It is designed so, that the object model can be extended as required to cover new applications, without affecting the messaging system. The original DLMS standard, IEC 61334-4-41, has been developed by IEC TC 57, as part of the IEC 61334 standard suite for distribution automation using distribution line carrier systems2. On the one hand, DLMS/COSEM uses only a part of the DLMS standard and therefore it is much simpler. On the other hand, it adds a few extensions for an efficient use of the COSEM model. This extended DLMS constitutes the xDLMS ASE of the COSEM application layer.
T T
It is important to note, that DLMS as specified in IEC 61334-4-41 does not provide a meter data model or a naming system. Adding these elements is one of the main evolutions brought by DLMS/COSEM. DLMS/COSEM uses a client/server concept. The data collection system acts as a client, requesting services. The logical devices of the meter act as servers, responding to service requests.
NOTE The metering functionality needed for a particular metering site may be provided by a single physical device or may be distributed across several physical devices, e.g. a metering unit, a tariff- or load control unit, a house gateway and a customer interface unit.
For accessing attributes and methods of COSEM objects, their attributes and methods have to be referenced. There are two possibilities available: Logical Name (LN) referencing: the attributes and methods are referenced with the triplet {class_id, logical_name, attribute/method id}. The services are GET, SET ACTION and EventNotification; Short Name (SN) referencing: each attribute and methods is mapped to a DLMS named variable. The services are Read, Write, UnconfirmedWrite and InformationReport. The mapping is provided by the meter for the client, to obviate the need for manufacturer specific information.
2 The original meaning of DLMS is Distribution Line Message Specification. To reflect the extended scope of application, DLMS stands now for Device Language Message Specification.
T T
OPEN meter

The referencing method is negotiable upon Association establishment. A meter may support both LN and SN referencing. Clients should support both LN and SN referencing to work with any meter in an interoperable way. With this, full interoperability is maintained between the two approaches. 6.4.6.4 Communication profiles DLMS/COSEM specifies a number of communication profiles for various communication media: the 3 layer, HDLC (ISO/IEC 13239) based, connection oriented (CO) profile. It supports data exchange over the local ports: optical, current loop, or RS 232 as well as via PSTN and GSM; the TCP/IP based communication profile. It supports data exchange over the Internet, GPRS; the S-FSK PLC profile (with lower layer as specified in IEC 61334 5-1 and 4-32); M-Bus EN 13757 (with appropriate CI values); Euridis IEC 62056-31. Examples of DLMS/COSEM communication profiles are shown in the following figure. The 3-layer, connection-oriented, HDLC based and the TCP/IP based profiles profile are widely used in the commercial / industrial segment with over PSTN/GSM modems. The TCP/IP based profile with GPRS is also used in smart metering project. In the Dutch DSMR project, this is the MI2 interface between the meters and the Central Access Server (CAS). The S-FSK PLC profile is the CI1 interface between the meters and the concentrator. It has been also selected for the ERDF project.
NOTE used. In the Dutch Project, on the CI2 interface between the concentrator and the CAS, web-services are
In any DLMS/COSEM communication profile, the top layer is the COSEM Application layer. Any set of lower layer can be used, which can transport COSEM APDUs. DLMS/COSEM can be used over any communication media, capable to support the COSEM Application layer. For any new communication media, the following elements have to be specified: addressing of Application Processes / Logical Devices by the supporting layers of the COSEM Application layer; establishment and release of Application Associations; the use of confirmed and unconfirmed Associations, confirmed and Unconfirmed DLMS services.
OPEN meter

COSEM data model
Connection manager
Supp. layer
COSEM Application layer

ACSE xDLMS Security ASE
Wrapper
Appl. layer
AL
Supp. layer
TCP IPv4
LLC
IEC 61334-4-32
HDLC Phy layer
Supporting layers
MAC +Phy
IEC 61334-5-1
S-FSK 3-layer, CO HDLC IEC 61334-5 S-FSK PLC profile
TCP-UDP/IP
Fig. 4 DLMS/COSEM communication profiles examples 6.4.6.5 Data security Data security comprises access security, and data transport security. Access security is controlled by Association objects. For data transport security, DLMS/COSEM has selected the AES-GCM-128 symmetric key algorithm, providing authenticated encryption. This algorithm is believed to provide sufficient protection until 2030 and beyond. 6.4.6.6 The role of companion specification To cover the largest possible range of applications, international standards specify a wide range of possibilities and options. They can be seen as a set of standard building blocks, of
Appl. layer
OPEN meter

which tailor-made applications can be built. On the other hand, they specify only those elements, on which an international consensus can be reached. While the internationals standard has all the indispensable elements that are necessary to build interoperable systems, companion specifications are useful to facilitate achieving interoperability. Such companion specifications are generally project specific, and, among others, specify the following elements: the list of features, elements and functions, which are not mandatory by the international standard, but are necessary to support the required functions; the choices to be taken where the international standard offers alternatives; fixing some parameters; the elements, where the international standard leaves freedom for project specific solutions; handling of any manufacturer specific elements; the flexibility or intelligence required on the data collection system side, to be able to work together with meters from various manufacturers. It is essential that this companion standard be developed by a joint effort of manufacturers and utilities and other stakeholders. The Dutch DSMR specification is a good example for a companion standard to DLMS/COSEM. 6.4.7 Summary
DLMS/COSEM is a modern specification, specifying the COSEM data model, the OBIS identification system, the DLMS messaging services and communication profiles / protocol suites for a range of communication media. It supports all applications: local and remote two-way data exchange, AMR and AMI. Its flexibility makes it suitable for simple and complex systems. Interoperability is supported by its self-descriptive properties, capability- and context negotiation. It uses efficient data organization tools, efficient encoding and advanced access and message security features. Recently, it has been successfully extended to support smart metering / AMI requirements, and its built-in standard extension mechanisms ensure that it can cope with future requirements. With this, it is well positioned as a core standard for smart metering / AMI.
OPEN meter

6.5
6.5.1
M-Bus: EN 13757
Introduction
M-Bus Meter bus is a European standard, used mainly for one-way or two-way data exchange with utility meters. Today, it is mainly used with heat, gas and water meters. It can also be used with various sensors and actuators. It is standardised by CEN TC 294, "Communication systems for meters and remote reading of meters" in the EN 13757 series. TC 294 covers data exchange with all utility meters except electricity meters, which are covered by IEC / CENELEC TC 13. EN 13757-1 is a general standard for meter data exchange, covering several physical media, protocols and the COSEM application data model. The parts EN 13757-2...EN 13757-6 specify the M-Bus protocol layers. M-Bus uses an OSI three-layer (collapsed) protocol architecture, consisting of: the wired or the wireless physical layer; the data link layer based on IEC 60870-5-1 and IEC 60870-5-2; the (M-Bus) dedicated application layer. M-Bus can alternatively be used with DLMS/COSEM: the COSEM Application layer specified in IEC 62056-53, the COSEM objects specified in IEC 62056-62 and the OBIS identification system specified in IEC 62056-61 (electricity) and in EN 13757-1 (other than electricity). On the other hand, devices using DLMS/COSEM e.g. electricity meters or house gateways may be set up as M-Bus masters, exchanging data with M-Bus slaves. M-bus supports the following physical interfaces: twisted pair local bus with base band signalling, according to EN 13757-2; wireless in the unlicensed 868980 MHz SRD (Short Range Device) band, according to EN 13757-4. It is suitable for in-house data exchange, up to 15 m. The action radius can be extended by using the relaying methods specified in EN 13757-5; local bus, according to EN 13757-6. M-Bus is a protocol optimised from the point of view of the meter, allowing simple and low cost implementations and long battery life. 6.5.2 Status of standardization
The relevant standards are the following: EN 60870-5-1, Telecontrol equipment and systems Part 5: Transmission protocols Section 1: Transmission frame formats (IEC 60870-5-1:1990)
OPEN meter

IEC 60870-5-2:1992, Telecontrol equipment and systems Part 5: Transmission protocols Section 2: Link transmission procedures EN 13757-1:2002, Communication system for meters and remote reading of meters Part 1: Data exchange EN 13757-2:2002, Communication system for meters and remote reading of meters Part 2: Physical and Link layer EN 13757-3:2004, Communication systems for and remote reading of meters Part 3: Dedicated application layer EN 13757-4:2005, Communication systems for meters and remote reading of meters - Part 4: Wireless meter readout (Radio meter reading for operation in the 868 MHz to 870 MHz SRD band) EN 13757-5:2008, Wireless meter readout Communication systems for meters and remote reading of meters Part 5: Relaying EN 13757-6: 2007, Communication systems for and remote reading of meters. Part 6: Local bus EN 1443-3:2008, Heat Meters - Part 3: Data exchange and interfaces CEPT/ERC/REC 70-03 E, Relating to the use of short range devices (SRD) ETSI EN 300 220-1, V1.3.1:2000, ElectroMagnetic Compatibility and Radio Spectrum Matters (ERM); Short range devices (SRD); Radio equipment to be used in the 25 MHz to 1 000 MHz frequency range with power levels ranging up to 500 mW; Part 1: Technical characteristics and test methods Dutch Smart Metering Requirements (DSMR) P2 Companion Standard, V2.31 8th January 2009
P P
DLMS User Association 1000-1:2009, Ed. 9.0: Blue Book: COSEM identification system and interface classes. To accommodate the needs of the Dutch DSMR project and the German OMS project, a revision of the M-Bus standards is foreseen. 6.5.3 Support organization
HT TH
M-Bus is supported by the M-Bus Association: h ttp://www.m-bus.com/
OPEN meter

No information is available. 6.5.5 Field of application
6.5.5.1 Local AMR Supported, either using the twisted pair or the wireless profile. 6.5.5.2 Remote AMR Not supported. 6.5.5.3 AMI Supported, when used in conjunction with DLMS/COSEM. 6.5.5.4 Home Automation Supported. 6.5.6 Summary of technical features
For detailed information please refer to Appendix 11.1 in part 1 of this deliverable. In this document only main characteristics are described. 6.5.6.1 The physical and the link layer of the wired (twisted pair) M-Bus profile The physical and the data link layers for data exchange via twisted pairs with base band signalling (there is no carrier signal) are specified in EN 13757-2. Information from the master to the slave is transmitted via voltage level changes. All slaves are constant current sinks: space (0) corresponds to a high current and mark (1) corresponds to a low current. The two wires can be exchanged and they are protected against short circuit. The slave interface can be equipped with an optional reversible mains protection. This option is interesting for devices powered from the mains. Most meters using M-Bus would run on a battery supply, but meters on the twisted pair bus can be optionally supplied from the bus. The total cable length can be a few kilometres. The default baud rate is 300 Bd. Baud rates up to 38,400 Baud are supported. The number of devices on the bus may limit the baud rate to lower values. The data link layer is based on IEC 60870-5-1 and IEC 60870-5-2. The frame format is FT1.2.
OPEN meter

6.5.6.2 The physical and the link layer of the wireless M-Bus profile The physical and the data link layers for wireless data exchange are specified in EN 13757-4. Three modes of operation are available: Stationary mode", mode S, intended for unidirectional or bi-directional communications between stationary or mobile devices: The S1 mode provides one-way and the S2 mode provides two-way communication. The S2 mode is compatible with KNX (see par. 6.13). "Frequent transmit mode", mode T. In this mode, the meter transmits a very short frame (typically 2 ms to 5 ms) every few seconds thus allowing walk-by and/or drive-by readout. There are two sub-modes: Transmit only sub-mode T1. It is the minimal transmission of a meter ID plus a readout value, which is sent periodically or stochastically. The bi-directional sub-mode T2 transmits frequently a short frame containing at least its ID and then waits for a very short period after each transmission for the reception of an acknowledge. Reception of an acknowledge will open a bi-directional communication channel. "Frequent receive mode", mode R2. In this mode, the meter listens every few seconds for the reception of a wakeup message from a mobile transceiver. After receiving such a wakeup, the device will prepare for a few seconds of communication dialog with the initiating transceiver. In this mode a multi-channel receive mode allows the simultaneous readout of several meters, each one operating on a different frequency channel. The link layer is also based on IEC 60870-5-1 and IEC 60870-5-2 with format class FT3. The frame formats depend on the mode. The baud rates are the following: T: 67/16 kBaud; S: 16/16 kBaud R: 2.4 / 2.4 kBaud. An M-Bus device may support one, several or all modes. The M-Bus wireless protocol is optimised for power consumption and low cost. A battery life of 14 years and a BOM of <1 is claimed. 6.5.6.3 EN 13757-5: M-Bus wireless relaying EN 13757-5 specifies relaying for wireless networks, to extend the action radius of the radio signal. The following modes are specified: Mode P, using routers, Mode R2, protocol using gateways;
OPEN meter

Mode Q, protocol supporting precision timing. This mode allows supporting DLMS/COSEM.
6.5.6.4 EN 13757-6: The physical layer for local bus This is an alternative to M-Bus. It is intended for small systems with up to 5 meters, which can be read by a battery operated master. The total cable length is max 50 m. The bus has to be switched on before data exchange. 6.5.6.5 EN 13757-3: The M-Bus dedicated Application layer The Application layer has always a fixed frame structure as described in EN13757-3. It may transport either the dedicated application layer according to EN13757-3 (M-Bus), or alternatively EN13757-1 DLMS/COSEM type communication (primarily used by electricity meters3. Note that the CI field as the first byte of the application layer distinguishes between these two application layer protocol types and frame structure.
T T
All application data are encoded in the bits and bytes of the M-Bus telegrams, carried by the data link layer. An M-Bus telegram contains the following information: the CI field identifies the type of the telegram: e.g. master to slave, slave to master, lower layer management information. A range of CI fields are reserved for DLMS based applications; the Data header, which can be 12, 4 or 0 bytes long: the 12 bytes long header identifies the device, the device type e.g. gas, heat, water etc. meters basic status information and encryption information; 4 bytes: As for CI=7Ah of EN13757-3, If the telegram contains such a short header the meter identification is taken from the link layer, 12 bytes: As for CI=72h of EN13757-3, If the telegram contains such a long header, this header contains the meter identification. the Variable Data Blocks: A VDB consists of the Data Information Block (DIB), the Value Information Block (VIB) and the Data: The DIB consists of one or more Data Information Fields (DIF). The DIF identifies the data type, the function (instantaneous, minimum, maximum, during error) and whether the data is current and historical. Extensions are available to identify storage numbers (identifiers of historical data), tariffs and sub-units within a physical device; The VIB consist of one or more Data Information Fields (VIF). Primary VIFs identify the kind of data: energy, average, instantaneous parameter, the unit and the scaler. VIF extensions are available to further precise the identification.
3 SML is not yet referenced in EN 13757-1 (par. Error! Reference source not found.)
T T
OPEN meter

The Data field carries the data identified by the DIB and the VIB. manufacturer specific data.
Other application layer standards are: M-Bus+: Planned future revision of the EN13757-3 (CI-values reserved so far) DLMS/SML+: EN13757-1, DLMS/COSEM or SML: Planned future revision of the EN13757-3. The DIB and VIB serve roughly the same purpose as the OBIS codes specified in IEC 62056-61 (electricity) and EN 13757-1 (other than electricity). It should be possible to map the M-Bus identifiers to OBIS codes. 6.5.6.6 Data security M-Bus supports data security by encrypting the M-Bus telegrams, using the DES standard, and more recently, the AES standard. Authentication is not supported. 6.5.6.7 Data exchange between devices using DLMS/COSEM and M-Bus: the Dutch project This possibility is the result of the Dutch Smart metering project and it is specified in the DLMS UA Blue Book Edition 9. DLMS/COSEM devices, e.g. electricity meters can be set up, using the appropriate interface classes, as M-Bus clients (M-Bus masters) to exchange data with M-Bus slaves, e.g. gas, water, and heat meters. The M-Bus client can retrieve data from M-Bus masters and store these data in COSEM objects. It can also send commands to the M-Bus slave devices. For wireless systems, the T1 and the T2 mode are used. For simple meters, Mode T1 is used. The meters (M-Bus slaves) send their data at regular intervals to the electricity meter (M-Bus master). For more complex meters, Mode T2 is used providing two way data exchange. This allows sending command to the M-Bus slaves to set the date and time and for example actuating a gas valve. The data collected are stored in COSEM objects and can be collected by the Data Collecting System. Whereas EN 13757-3 specifies only DES encryption, the DSMR specification specifies AES. The DSMR specification contains a number of extensions and deviations, which will have to be accommodated in the next revision to the EN 13757 M-Bus standards.
OPEN meter

Examples for data exchanges between the M-Bus master and slave: scan for and install new M-Bus slaves; send operational encryption key; read / receive M-bus meter registers: real time, hourly and historical values, set date and time in M-Bus slave; command M-Bus gas meter valve. 6.5.7 Summary
M-Bus is a specification for local in house meter data exchange using twisted pair with base-band signalling or by radio in the SDR band. Currently, its main applications are in heat and gas metering. It is optimised for simple devices with battery supply. It can work with DLMS /COSEM in two ways: the M-Bus lower layers supporting the DLMS/COSEM application layer and data model; or DLMS/COSEM devices can be set up as M-Bus masters, exchanging data with meters using M-Bus and acting as M-Bus slaves.
6.6
Smart Message Language (SML)
6.6.1 Introduction SML is a communication protocol which has been developed and is applied by leading utilities (RWE, E.ON, EnBW, Vattenfall). SML has been applied by various manufacturers (Landis+Gyr, Dr.Neuhaus/Sagem, Hager, EMH, Insys, Goerlitz, ITF-EDV Froeschl and others). SML has been developed to meet the requirements of smart metering/grids which include: Suitability for IP-based connections Consistency of data over more than one level Clean separation of protocol layers Support of push and pull procedures Mix of read/write requests for different devices Conditional flow of requests in one pack (if-then-else) Capability to create bundled orders without hand-shake-functions during the working process Sequential or parallel processing of bundled orders Interoperability across different manufacturers.
OPEN meter

SML is a non-proprietary standard, whose specification can be accessed free of charge. Currently, version 1.02 is available. See: http://www.sym2.org/eng/index_eng.html. (SML specification 1.02)
H H
SML has received substantial support by the SyM project, in which a clocked load profile meter has been developed by Landis+Gyr, RWE, E.ON, EnBW, the German Federal Ministry of Economics and the University of Kiel. See: www.sym2.org
H H
Besides the SyM project, SML is applied in the following initiatives: Multi Utility Communication Controller (MUC-C) New Electronic Domestic Supply Meter (EHZ). The goal involved in drawing up the SML specification was the primary wish to find a maximally simple structure also suitable for implementation in low-power embedded systems than can be used for data procurement over wide-area routes. SML represents a communication protocol for applications in the environment of data procurement and equipment parameterisation. SML only defines the application layer independent from communication layers. Regarding the transport layer it refers to existing standards. Only if a standard transport protocol is not provided, the SML transport frame can be applied. A clear separation between different layers permits a clean and efficient process of data transmission. The accomodation of technological and regulatory changes in the future is also facilitated by means of a clear separation of layers.
OPEN meter

Fig. 5 SML communication model

(SML specification 1.02, http://www.sym2.org/eng/sml-spezi_eng.html)
H H
6.6.2
Status of standardisation
P P
According to the official decision of Working Group DKE AK 461.0.14 of 29th april 2009, SML will be prepared to become internationally standardized via the IEC. The working group has decided to work on international standardization right from the beginning rather than first standardizing SML on the national level. Following that decision, SML specification version 1.03 will be passed as a draft by DKE AK 461.0.14 to IEC TC13 WG14 on 30 june 2009. The annex of the SML specification will likewise be passed to IEC TC13 WG14 on 30th september 2009.
P P
6.6.3
Support organization
SML is supported by both DKE AK 461.0.14 and FNN (Forum Network Technology/Mains operation), an independent non-commercial user group.
OPEN meter

Currently it is already being worked on concrete test procedures, test requirements and test systems/infrastructure for SML applications in collaboration with test service providers. Within the SyM project a conformance test procedure already exists which is managed within the group conformance of metering systems within VDE-FNN. Further conformance test procedures for SML applications are currently being developed. 6.6.5 Field of application
SML is independent from the application and from transport. SML functions as a coder which formats and then compresses data in a similar way as XML or HTML do. However, XML and HTML require too much temporary storage (buffers), whereas SML provides streaming and compressing functions on the fly. SML provides the transport container and then the data is coded for transport. Thereby, in the end, the data received can still be divided into its different original components. 6.6.5.1 Local AMR Supported by SML, since SML is independent from transport layer, please see 6.6.1 for general working mechanisms. 6.6.5.2 Remote AMR Supported by SML, since SML is independent from transport layer, please see 6.6.1 for general working mechanisms. 6.6.5.3 AMI Supported by SML, since SML is independent from transport layer, please see 6.6.1 for general working mechanisms. 6.6.5.4 Home Automation Supported by SML, since SML is independent from transport layer, please see 6.6.1 for general working mechanisms. 6.6.6 Data model The data model describes how the single elements of an SML message are built up. Figure 6 illustrates an example of the data model of one SML message. An SML message is either a Request message or a Response message An SML message comprises task and assigned attributes
OPEN meter

Fig. 6 SML messages

H H
A SML file, however, is constituted by several SML messages. Figure 7 illustrates that the SML file denotes a specific self-contained information unit, which is completely detached from the transport technology involved (e.g. internet, telephone). In this sense, SML files can be comprehended as self-contained and self-explanatory information units that (just like an email) are embedded and transmitted in a protocol (see Fig 5). 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. If SML files are used as files on computer systems, these files must be noted without the use of additional frames. 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. Simple SML file structure
Fig. 7 SML file structure

(Source: Sym presentation held at E-world 2008, http://www.sym2.org/docs/EWorld_2008_English.pdf)
OPEN meter

Communication media supported
Basically, any communication media can be used for transmitting SML. For transport of SML files regular standardized procedures for the respective transport medium are used. However, if the transport medium does not provide a protocol for secured data transmission, the SML transport frame can apply which functions as an encoder. This solution is possible for all communication media. SML Structure The basic SML structure is divided into the following elements: Smart Message Language defines a file structure/document structure for recording the useful loads between the end points SML Binary Encoding defines a packed binary coding for SML SML XML Encoding defines the coding for SML in XML SML Transport Protocol, required for serial point-to point links. SML messages, can, like an email in the final analysis, be transported over stateless, secure communication paths. For the duty scenario being targeted, the following model can accordingly be adduced for an overview:
Fig. 6 SML messages and communication paths

OPEN meter

6.6.7.1 Local bus Supported by SML, since SML is independent from transport layer, please see 6.6.1 for general working mechanisms. 6.6.7.2 PSTN Supported by SML, since SML is independent from transport layer, please see 6.6.1 for general working mechanisms. 6.6.7.3 GSM Supported by SML, since SML is independent from transport layer, please see 6.6.1 for general working mechanisms. 6.6.7.4 GPRS Supported by SML, since SML is independent from transport layer, please see 6.6.1 for general working mechanisms. 6.6.7.5 Internet Supported by SML, since SML is independent from transport layer, please see 6.6.1 for general working mechanisms. 6.6.7.6 PLC Supported by SML, since SML is independent from transport layer, please see 6.6.1 for general working mechanisms. 6.6.7.7 Walk by radio Supported by SML, since SML is independent from transport layer, please see 6.6.1 for general working mechanisms. 6.6.7.8 Mesh radio Supported by SML, since SML is independent from transport layer, please see 6.6.1 for general working mechanisms. 6.6.8 Summary
SML .. was developed by utilities to comply with future smart metering requirements: Suitability for IP-based connections Consistency of data over more than one level Clean separation of protocol layers Support of push and pull procedures Mix of read/write requests for different devices Conditional flow of requests in one pack (if-then-else) Capability to create bundled orders without hand-shake-functions during the working process Sequential or parallel processing of bundled orders Interoperability across different manufacturers .. is supported by different manufacturers and implemented in different initiatives
OPEN meter

.. represents an open and therefore non-proprietary protocol which can be accessed freely .. clearly separates communication, application and transport layers which guarantees a clean and efficient process of data transmission Universal applicability to all communication media without having to be adjusted More flexibility with regard to technological and regulatory changes in the future.
6.7
6.7.1
IP Telematric Protocol E-DIN 43863-4

Introduction
The specification for IP telemetry originates in products for the procurement of counter readings for the measurement of electrical energy consumption; it can also be used as a generic solution for comparable applications in automation systems and is hence generally useable in the field of machine-to-machine, M2M, interfaces. E-DIN supports Push and Pull via IP-networks as well as migration from traditional leased circuits and point-to-point switched connections to IP-networks.
6.7.2
DIN 43863-4 Meter data communication - IP-Telemetry:2006 is a draft standard developed by the Deutsches Institut fr Normung (DIN)/ German Institute for Standardization (http://www.dke.din.de/projekte/DIN+43863-4/en/92134004.html). The appropriate WG within DKE at DIN (AK461.0.14) decided already in 2007 to let the (E-) DIN 43863-4 become an international standard. This decision was confirmed in 2008. Due to revision activities the international standardisation was postponed to early 2009. DIN 43863-4 will be passed by DKE AK 461.0.14 to IEC TC13 WG14 on 30 June 2009 to follow its standardisation process. 6.7.3 Support organization
This standard is supported by the Institut fr Normung (DIN)/ German Institute for Standardization, the national standardisation body in Germany. DIN standards are open and non-proprietary. 6.7.4 Conformance testing and product certification
Since E-DIN 43863-4 is also used in the SyM project (see 6.6.1) it is tested according to those conformance testing procedures. Additionally, E-DIN 43863-4 is accompanied by DKE AK 461.0.14 which plans to develop an individual test infrastructure for this norm.
OPEN meter

Field of application
Generally applicable for all wide area transport via IP-based networks. For transport itself however, regular standardized procedures for the respective transport medium are used. 6.7.5.1 Local AMR Not supported 6.7.5.2 Remote AMR Supported, no specific provisions for Remote AMR 6.7.5.3 AMI Supported, no specific provisions for AMI 6.7.5.4 Not supported 6.7.6 Data model Please refer to the following scheme. Home Automation
Fig. 7 DIN 86436-4 data model Application Example IP Telematric in metering (in Germany) A transparent communication channel (=migration channel) between meter devices and remote meter readout control center is built up Metering data is transported through this channel In the end, the connection meter/control center equals a wired connection, trespassing several interfaces, though physically there is no connection
OPEN meter

Control center can read original data of meter in real time Set-up permits IP services without having to change entire system.
The whole purpose of IP Telematric was the ability to use IP-based services without having to change the entire application. By means of the migration channel IP-based transports can be used without changing IP-Telematric. First, IP is built up, then the channel has been migrated, then migrating the application is possible to use desired applications based on IPservices in an ideal manner. 6.7.7 Communication media supported
6.7.7.1 Local bus Not supported 6.7.7.2 PSTN Supported but independent from communication media used. 6.7.7.3 GSM Supported but independent from communication media used. 6.7.7.4 GPRS Supported but independent from communication media used. 6.7.7.5 Internet Supported but independent from communication media used. 6.7.8 Summary IP Telematric Protocol E-DIN 43863-4 denies any attachement to certain application protocols. The specification arises from products for the procurement of meter readings for the measurement of electrical energy consumption. E-DIN 43863-4 covers regulations concerning the dialling-up of participants. It includes commands - from the simple transfer of measurands and readings to complex appication scenarios in machine-to-machine (M2M) communication. E-DIN supports Push and Pull via IP-networks as well as migration from traditional leased circuits and point-to-point switched connections to IP-networks. The whole purpose of IP Telematric via E-DIN 43863-4 was the ability to use IP-based services without having to change the entire application. By means of the migration channel IP-based transports can be used without changing IP-Telematric. First, IP is built up, then the channel has been migrated, then migrating the application is possible to use desired applications based on IP-services in an ideal manner.
OPEN meter

6.8
6.8.1
IEC 60870-5
Introduction
IEC 60870-5 provides a communication profile for sending basic telecontrol messages between two systems, which uses permanent directly connected data circuits between the systems. The IEC Technical Committee 57 (Working Group 03) has developed a protocol standard for Telecontrol, Teleprotection, and associated telecommunications for electric power systems. The result of this work is IEC 60870-5. Five documents specify the base IEC 60870-5: IEC 60870-5-1 Transmission Frame Formats IEC 60870-5-2 Data Link Transmission Services IEC 60870-5-3 General Structure of Application Data IEC 60870-5-4 Definition and coding of Information Elements IEC 60870-5-5 Basic Application Functions. IEC 60870-5-101 (IEC101) is an international standard prepared by TC57 for power system monitoring, control & associated communications. This is completely compatible with IEC 60870-5-1 to IEC 60870-5-5 standards and uses standard asynchronous serial telecontrol channel interface between DTE and DCE. The standard is suitable for multiple configurations like point-to-point, star, mutidropped etc.
H H H H H H
Features of IEC 60870-5-101 Supports unbalanced (master initiated message) & balanced (master/slave initiated message) modes of data transfer. Link address and ASDU addresses are provided for classifying the end station and different sectors under the same. Data is classified into different information objects and each information object is provided with a specific address. Facility to classify the data into high priority (class-1) and low priority (class-2) and transfer the same using separate mechanisms. Possibility of classifying the data into different groups (1-16) to get the data according to the group by issuing specific group interrogation commands from the master & obtaining data under all the groups by issuing a general interrogation. Cyclic & Spontaneous data updating schemes are provided. Facility for time synchronization Schemes for transfer of files
Types supported by IEC 60870-5-101 Single indication without / with 24 / with 56 bit timestamps. Double indication without / with 24 / with 56 bit timestamps. Step position information without / with 24 / with 56 bit timestamps. Measured value normalized, scaled, short floating point without / with timestamps.
OPEN meter

Bitstring of 32 bit without / with timestamps. Integrated totals (counters) without / with timestamps. Packed events (start & tripping ) of protection equipments Single commands Double commands Regulating step command Set point commands of various data formats Bitstring commands Interrogation commands Clock synchronization & delay acquisition commands Test & reset commands
Status of standardisation Internationally standardized via IEC
6.8.2
Open and non-proprietary standard which is internationally standardized via IEC. 6.8.3 Support organization
IEC Technical Committee 57 (Working Group 03). 6.8.4 Conformance testing and product certification
Information not available. 6.8.5 Field of application
6.8.5.1 Local AMR Supported. 6.8.5.2 Remote AMR Supported. 6.8.5.3 AMI Not supported. 6.8.5.4 Home Automation Not supported. 6.8.6 Data model No Data model available 6.8.7 Communication media supported
6.8.7.1 Local bus Supported.
OPEN meter

6.8.7.2 PSTN Not supported. 6.8.7.3 GSM Not supported. 6.8.7.4 GPRS Not supported. 6.8.7.5 Internet Not supported. 6.8.7.6 PLC Not supported. 6.8.7.7 Walk by radio Not supported. 6.8.7.8 Mesh radio Not supported. 6.8.8 Summary
IEC 60870-5 provides a communication profile for sending basic telecontrol messages between two systems, which uses permanent directly connected data circuits between the systems. The IEC Technical Committee 57 (Working Group 03) has developed a protocol standard for Telecontrol, Teleprotection, and associated telecommunications for electric power systems. The result of this work is IEC 60870-5. IEC 60870-5-101 (IEC101) is an international standard prepared by TC57 for power system monitoring, control & associated communications. This is completely compatible with IEC 60870-5-1 to IEC 60870-5-5 standards and uses standard asynchronous serial telecontrol channel interface between DTE and DCE. The standard is suitable for multiple configurations like point-to-point, star, mutidropped etc.
6.9 IEC 61968-9

Source: draft IEC 61968-9, 57/946/CDV. 6.9.1 Introduction
Part 9 of the IEC 61968 standard specifies the information content of a set of message types that can be used to support many of the business functions related to Meter Reading and Control. Typical uses of the message types include meter reading, meter control, meter events, customer data synchronization and customer switching. Although intended primarily for electrical distribution networks, IEC 61968-9 can be used for other metering applications, including non-electrical metered quantities necessary to support gas and water networks.
OPEN meter

The purpose of this document is to define a standard for the integration of Metering Systems (MS), which includes traditional manual systems, and (one or two-way) Automated Meter Reading (AMR) Systems, with other systems and business functions within the scope of IEC 61968. The scope of this standard is the exchange of information between a Metering System and other systems within the utility enterprise. The specific details of communication protocols those systems employ are outside the scope of this standard. Instead, this standard will recognize and model the general capabilities that can be potentially provided by advanced and/or legacy meter infrastructures, including twoway communication capabilities such as load control, dynamic pricing, outage detection, distributed energy resource (DER) control signals and on-request read. In this way, this standard will not be impacted by the specification, development and/or deployment of next generation meter infrastructures either through the use of standards or proprietary means. The capabilities and information provided by a meter reading system are important for a variety of purposes, including (but not limited to) interval data, time-based demand data, time based energy data (usage and production), outage management, service interruption, service restoration, quality of service monitoring, distribution network analysis, distribution planning, demand reduction, customer billing and work management. This standard also extends the CIM (Common Information Model) to support the exchange of meter data. 6.9.2 Status of standardization
IEC 61988-9 is a draft standard developed by IEC TC 57.
6.10 SITRED
6.10.1 Introduction In 1992/94 ENEL (largest Italian distribution company) have proceeded to install the first industrial implementation of a Distribution Automation System (DAS) for both supervision of secondary substations and service to customers. This DAS uses a PLC based solution for a two-way telecommunication system using both MV and LV distribution power networks as data transmission media. Two implementations of the communication protocols over the PLC are utilized which differ in the PHY and MAC layers while share the same Application layer. In this way the two PLC implementations are completely transparent from the Central System point of view. One implementation is based on an extension of the Lontalk protocol while the second is based on the ENEL stack named SITRED. Both implementations are currently in use. SITRED (Integrated System for data Transmission on Electricity Distribution network) protocol stack is a Enels proprietary solution involved in Enel AMM system called
OPEN meter

Telegestore. The Telegestore implementation started in 2001 based on studies and experiments carried out during the previous decade. The following paragraph reports some information about Enel SITRED protocol stack. Further details are given in 6.9.1 in part 2 of this deliverable. 6.10.2 Protocol Layers SITRED protocol implements first, second and seventh layers of ISO stack; some functionalities, typical of unimplemented layers, are embedded on Data Link and Application. Physical Layer At physical layer, SITRED protocol stack manages a Frequency Shift Keying (FSK) modulation profile described in IEC 61334-5-2. Data Link Layer At Data Link Layer, SITRED implements repetition features to improve meters reachability and the procedure to access to mean in master-slave mode. In addiction, the DL layer is able to manage multiples Application Layers. The Data Link Layer is based on IEC 61334-4-33. Application layer (proprietary) The SITREDs stack application layer implements all the features needed to implement the data exchange between DLC networks nodes in a exhaustive way; in addiction it implements some functionality of network management (meters auto-discovery and network auto-configuration). At this level, with regard to data security management, Sitred supports encryption, authentication and playback attacks protection. ENELs SITRED does not support GSM and GPRS, except on the back-haul network (out of scope).
6.11 PRIME
PRIME (PoweRline Intelligent Metering Evolution) is the definition of the lower layers of a system to provide an open, royalty and patent free solution, for physical and media access control layers, together with certain convergence layers definition, for a narrowband PLC solution in CENELEC A band in the low voltage part of the network. Convergence Layer (CL) opens MAC and PHY layers to upper layers and applications. CL classifies traffic associating it with its proper MAC connection. This layer performs the mapping of any kind of traffic into MAC SDUs, providing access to the core MAC functionalities, as detailed in the following figure.
OPEN meter

Fig. 8 PRIME architecture The IPv4 convergence layer provides an efficient method of transferring IPv4 packets over the PRIME network. The IEC 61334-4-32 Convergence Layer supports the same primitives as the IEC 61334-4-32 standard. For further details, please refer to 3.3 of part 2.
6.12 IEC 61850

Distributed energy resources (DER), Demand Side Management, distribution automation and metering services are functions that all need an open standard for communication. IEC 61850 standard is applicable to describe device models and functions of substation and feeder equipment. There are specific IEC 61850 versions for DER (IEC 61850-7-420) and Wind Power Plants that are important for the OPEN meter project. At this moment, the IEC 61850 series does not include any versions specifically dedicated to residential metering or home automation. The IEC 61850 provides the following features: One consistent data model, no complex maintenance of data and no data conversion; Seamless integration into distribution automation and power control systems; Using industrial approved technologies. IEC 61850 uses Logical nodes and Logical devices in its data model. The explanation of the logical nodes will follow after explaining the data information. 6.12.1 Data Information Data information models provide standardized names and structures to the data that is exchanged among different devices and systems. Fig. 9 illustrates the object hierarchy used for developing IEC 61850 information models.
OPEN meter

Logical Devices (LD) Logical Nodes (LN) Logical Nodes Data Objects (DO) Common DataData Class Common Classes (CDC) Common Attributes Common Components Standard Data Types
Fig. 9 IEC 61850 Information model hierarchy The process from the bottom up is described below: a) Standard data types: common digital formats such as Boolean, integer, and floating point. b) Common attributes: predefined common attributes that can be reused by many different objects, such as the quality attribute. These common attributes are defined in Clause 6 of IEC 61850-7-3. c) Common Data Classes (CDC): predefined groupings building on the standard data types and predefined common attributes, such as the single point status (SPS), the measured value (MV), and the controllable double point (DPC). In essence, these CDCs are used to define the type or format of data objects. These CDCs are defined in IEC 61850-7-3 or in Clause 9 of this document. All units defined in the CDCs shall conform to the SI units (international system of units) listed in IEC 61850-7-3. d) Data Objects (DO): predefined names of objects associated with one or more Logical Nodes. Their type or format is defined by one of the CDCs. They are listed only within the Logical Nodes. An example of a DO is Auto defined as CDC type SPS. It can be found in a number of Logical Nodes. e) Logical Nodes (LN): predefined groupings of data objects that serve specific functions and can be used as bricks to build the complete device. Examples of LNs include MMXU which provides all electrical measurements in 3-phase systems (voltage, current, watts, vars, power factor, etc These LNs are described in Clause 5 of IEC 61850-7-4. f) Logical Devices (LD): the device model is composed by the relevant Logical Nodes for providing the information needed for a particular device. Logical devices are not directly defined in any of the IEC 61850 documents, since different products and different implementations can use different combinations of Logical Nodes for the same logical device. 6.12.2 Logical nodes for the DER plant ECP logical device The logical device for the DER plant electrical connection point (ECP) defines the characteristics of the DER plant at the point of electrical connection between one or more DER units and any electric power system (EPS), including isolated loads, microgrids and the utility power system. Usually there is a switch or circuit breaker at this point of connection.
OPEN meter

ECPs can be hierarchical. Each DER (generation or storage) unit has an ECP connecting it to its local power system; groups of DER units have an ECP where they interconnect to the power system at a specific site or plant; a group of DER units plus local loads have an ECP where they are interconnected to the utility power system. In a simple DER configuration, there is one ECP between a single DER unit and the utility power system. However, as shown in Fig. 10, there may be more ECPs in a more complex DER plant installation. In this figure, ECPs exist between: each single DER unit and the local bus; each group of DER units and a local power system (with load); multiple groups of DER units and the utility power system.
= Electrical Connection Point (ECP)

Wind Turbine PV
Local Bus
Utility Power System
Meter Local Power System
DER interconnections
Point of Common Coupling (PCC)
Load interconnection
Fig. 10 Example of ECP for DERs Building logical devices to automate the operation of a PV system for example would require the following functions: Switchgear operation: functions for the control and monitoring of breakers and disconnect devices. This is already covered in IEC 61850-7-4. Protection: functions required to protect the electrical equipment and personnel in case of a malfunction. Already covered in IEC 61850-7-4. A PV specific protection is DC ground fault protection function that is required in many PV systems to reduce fire hazard and provide electric shock protection. This function is covered by the logical node and described in IEC 61850-7-4. Measuring and metering: functions required to obtain electrical measurements like voltage and current. AC measurements are covered in IEC 61850-7-4.
OPEN meter

DC to AC conversion: functions for the control and monitoring of the inverter. Array operation: functions to maximize the power output of the array. These include adjustment of current and voltage level to obtain the MPP and also the operation of a tracking system to follow the sun movement. Islanding: functions required to synchronize the PV system operation with the power system. This includes anti-islanding requirements specified in the interconnection standards. Energy storage: functions required to store excess energy produced by the system. Energy storage in small PV systems is usually done with batteries, while larger PV systems may include compressed air or other mechanisms. Examples of installations with multiple ECPs include the following: One DER device is connected only to a local load through a switch. The connection point is the ECP. Groups of similar DER devices are connected to a bus which feeds a local load. If the group is always going to be treated as a single generator, then just one ECP is needed where the group is connected to the bus. If there is a switch between the bus and the load, then the bus has an ECP at that connection point. Multiple DER devices (or groups of similar DER devices) are each connected to a bus. That bus is connected to a local load. In this case, each DER device/group has an ECP at its connection to the bus. If there is a switch between the bus and the load, then the bus has an ECP at that connection point. Multiple DER devices are each connected to a bus. That bus is connected to a local load. It is also connected to the utility power system. In this case, each DER device has an ECP at its connection to the bus. The bus has an ECP at its connection to the local load. The bus also has an ECP at its connection to the utility power system. This last ECP is identical to the IEEE 1547 PCC.
6.13 KNX
KNX (Konnex) is a standard for home and building control approved as: European Standard (CENELEC EN 50090 and CEN EN 13321-1) International Standard (ISO/IEC 14543-3) Chinese Standard (GB/Z 20965) US Standard (ANSI/ASHRAE 135). KNX is therefore future proof. KNX products made by different manufacturers can be combined the KNX trademark logo guarantees their interworking and interoperability. KNX is therefore the worlds only open Standard for the control in both commercial and residential buildings. This standard is based upon more than 15 years of experience in the market, amongst others with predecessor systems to KNX: EIB, EHS and BatiBUS. Via the KNX medium to
OPEN meter

which all bus devices are connected (twisted pair, radio frequency, power line or IP/Ethernet), they are able to exchange information. Bus devices can either be sensors or actuators needed for the control of building management equipment such as: lighting, blinds / shutters, security systems, energy management, heating, ventilation and air-conditioning systems, signaling and monitoring systems, interfaces to service and building control systems, remote control, metering, audio / video control, white goods, etc. All these functions can be controlled, monitored and signaled via a uniform system without the need for extra control centers.
6.14 ZigBee SmartEnergyProfile

ZigBee is a suite of high level communication protocols using small, low-power digital radios based on the IEEE 802.15.4 standard for wireless personal area networks (WPANs). ZigBee is a registered trademark of the ZigBee Alliance, The ZigBee standard describes in detail the over the air protocol used, however there are a number of layers to consider when looking at ZigBee protocols; 1. MAC layer uses standard IEEE 802.15.4 messaging for point-to-point communications in the mesh network. 2. Network Layer (NWK) ZigBee adds headers for networking in a multi-hop network (end to end device addressing etc.) and security 3. Application Support Sublayer (APS) Provides mechanisms for managing end to end messaging across multiple hops in a mesh network e.g. addressing endpoints in a device, triggering route discovery, managing end-to-end retries 4. ZigBee Cluster Library (ZCL) - ZigBee defines a library of interoperable message types called clusters that cover a variety of device types. This library can be added to when creating support for new applications. The Smart Energy Profile (ZigBee Profile 0x0109) defines device descriptions for Simple Meter Reading, Demand Response and Load Management. Format is defined by the ZigBee specification, in the ZigBee Cluster Library and Application Profiles. Custom protocols / data formats are allowed, but would not be guaranteed interoperable.
OPEN meter

Fig. 11 ZigBee layers

(Source: www.zigbee.org)
In the US, the project OPEN-AMI (EPRI) planned to use ZigBee for in house communications e.g. among home meters, the Home Gateway and home/building automation (generators, storages and user appliances). For further information, please refer to paragraph 5.4.1 in part 3 of this Deliverable.
6.15 6LoWPAN
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) is a low-power wireless personal area networks comprising devices that conform to the IEEE 802.15.4-2003 standard by the IEEE [IEEE802.15.4]. IEEE 802.15.4 devices are characterized by short range, low bit rate, low power, and low cost. Some of the characteristics of LoWPANs are as follows: Small packet size. Given that the maximum physical layer packet is 127 bytes, the resulting maximum frame size at the media access control layer is 102 octets. Link-layer security imposes further overhead, which in the maximum case (21 octets of overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32 and AES-CCM-64, respectively), leaves 81 octets for data packets. Support for both 16-bit short or IEEE 64-bit extended media access control addresses. Low bandwidth. Data rates of 250 kbps, 40 kbps, and 20 kbps for each of the currently defined physical layers (2.4 GHz, 915 MHz, and 868 MHz, respectively).
OPEN meter

Topologies include star and mesh operation.
6.16 Homeplug
Homeplug is a technical specification for powerline communications developed by a consortium of companies. The specifications are available to HomePlug member companies. As an open alliance, any company can become a member and have access to the specifications. Homeplug AV also provides advanced capabilities consistent with new networking standards. Advanced Network Management functions and facilities are capable of supporting user plug-and-play configuration as well as service provider set-up and configuration. HPAV offers tight security based on 128-bit AES and makes provision for dynamic (automatic) change of the encryption keys and for several different user experiences in setting up security and admitting stations to the network. The design allows a station to participate in multiple AV networks. HPAV is backward compatible with HomePlug 1.0 and offers several mandatory and optional co-existence modes enabling multi-network operation, hidden node service and Broadband over Powerline (BPL) co-existence. The Physical Layer (PHY) operates in the frequency range of 228 MHz and provides a 200 Mbps channel rate and a 150 Mbps information rate. Modulation densities from BPSK (which carries 1 bit of information per carrier per symbol) to 1024 QAM (which carries 10 bits of information per carrier per symbol) are independently applied to each carrier based on the channel characteristics between the transmitter and the receiver. An Initiative to develop a common application layer integrated solution for advanced metering infrastructure (AMI) and home area networks (HAN) has started. Using the robust capabilities of the ZigBee Smart Energy public application profile as a baseline, the three groups will expand the application layer and enable it to run on HomePlug technology, providing utilities with both wireless and wired HAN industry standards to select from when implementing new AMI programs. Today is used in homes to network Ethernet devices (thanks to high data rate that support video streaming). HomePlug standard is reasonably mature. For further information, please refer to part 2 of this deliverable and http://www.homeplug.org.
HT TH
6.17 Z-Wave
Z-Wave is a proprietary standard (mesh wireless, especially for home automation); among partners of Z-Wave Alliance are Cooper, Betronic, Black&Decker, Panasonic, Somfy; recently Nokia has launched an home control center based on this standard. Licensing program and technical support is offered.
OPEN meter

This standard offers 9 600 bit/s communication, based on GFSK modulation; it ranges approximately 30 meters ("open air" conditions). The Z-Wave Radio uses the 900 MHz ISM band: 908.42 MHz (USA); 868.42 MHz (Europe); 919.82 MHz (Hong Kong); 921.42 MHz (Australia/New Zealand).
6.18 Wavenis
Wavenis is a wireless communication platform that only covers PHY, MAC & NET layers (that can support many application protocols), optimized for ultra low power and long range WSNs. The Wavenis Open Standard Alliance (www.wavenis-osa.org) which is an independant and a non for profit organization brings Wavenis into a standardization process while taking care of managing specification roadmap. Note that Wavenis-OSA is now considering the adoption of IPSO services for NET layer.
HT TH
For further information, please refer to 5.4.4 in part 3 of this Deliverable.
6.19 EverBlu
6.19.1 Introduction EverBlu is an Automatic Meter Reading system based on wireless mesh point-to-multipoint communication infrastructure for urban, suburban or rural environments. It is suitable for multi-energy applications including water, gas electricity and heat metering. 6.19.2 Status of standardization The LAN layer of EverBlu is coming from the former Radian protocol, designed 10 years ago by a European user association (EDF, GDF, Severn Trent Water, Aquametro, Itron, Schlumberger, Sontex and Viterra). As such, the EverBlu endpoints can be read in dual mode either using EverBlu fixed network or walk-by collection system compatible with Radian protocol. 6.19.3 Field of application 6.19.3.1 Local AMR Supported with two-way local data exchange based on Radian protocol (originally developed in 1998 by Itron). 6.19.3.2 Remote AMR Supported with two-way remote data exchange over various media (eg GPRS).
OPEN meter

6.19.4 Summary of technical features EverBlu is an ultra-low-power (bi-power), bi-frequency, long-range (300m), wireless mesh technology, especially for metering applications. EverBlu operates in major license-free bands: LAN: 433 MHz 10mW (worldwide) NAN*: 868 MHz (Europe) 200mW / 915 MHz 200mW (Australia)
(*) NAN = neighborhood area network
Fixed network application schematic:
Fig. 12 EverBlu architecture

(www.actaris.com)
For further details, please refer to 5.4.11 in part 3 of this Deliverable.
OPEN meter
Energy Theme; Grant Agreement No 226369 Title: 6.19.4.1 AMI Supported. 6.19.4.2 Home automation Not supported.
6.20 OPERA/UPA
OPERA (Open PLC European Research Alliance) was an R&D EU-funded project under the Sixth Framework Program (www.opera-ist.org) which aim was to develop a new-generation PLC technology as an alternative for access in the local loop. Such a standardized technology would enable low cost broadband access for all European citizens with outstanding performance. OPERA started back in January 2004 and finished its first Phase in February 2006. Second Phase lasted from January 2007 to December 2008. The OPERA specification was developed as a result of extensive investigation during the Project life. This is reflected in public Deliverables as output from the Project (D27 of OPERA Phase II). OPERA established a liaison with UPA (www.upaplc.org) to jointly contribute a proposal to the IEEE P1901 group. Although finally the proposal was eliminated, many of the ideas were taken to be included in the baseline IEEE P1901 finally approved (e.g. variable symbol length). OPERA specification still remains as an open PHY and MAC proposal for BPL systems.
H H H H
For additional information, please refer to 5.8.1 in part 2 of this Deliverable.
6.21 ITU-G.hn
G.hn is a standard for wired communications developed by the International Telecommunications Union (ITU). The goal of G.hn is to develop a single PHY/MAC standard that can work over any type of wired media, including power lines, phone lines and coaxial cables. Recommendation G.9960, which descrbes the Physical Layer and System Architecture of G.hn, received consent in Dec 2008. Shortly thereafter, multiple silicon vendors announced support for the standard. For additional information, please refer to 5.7.2 in part 2 of this Deliverable. 6.21.1 G.hn Overview G.hn specifies a single PHY based on FFT OFDM modulation and Low-Density Parity-Check (LDPC) FEC code. G.hn includes the capability to notch specific frequency bands to avoid interference with Amateur Radio bands and other licensed radio services. G.hn includes mechanisms to avoid interference with legacy home networking technologies and also with other wireline systems such as VDSL2 or other types of DSL used to access the home.
OPEN meter

G.hn will provide a data rate of up to 1 Gbit/s. OFDM systems split the transmitted signal into multiple orthogonal sub-carriers. In G.hn each one of the sub-carriers is modulated using QAM. The maximum QAM constellation supported by G.hn is 4096-QAM (12-bit QAM). The G.hn Medium Access Control is based on a TDMA architecture, in which a "domain master" schedules Transmission Opportunities (TXOPs) that can be used by one or more devices in the "domain". There are two types of TXOPs: Contention-Free Transmission Opportunities (CFTXOP), which have a fixed duration and are allocated to a specific pair of transmitter and receiver. CFTXOP are used for implementing TDMA Channel Access for specific applications that require Quality of Service guarantees. Shared Transmission Opportunities (STXOP), which are shared among multiple devices in the network. STXOP are divided into Time Slots (TS). There are two types of TS: o Contention-Free Time Slots (CFTS), which are used for implementing "implicit" Token passing Channel Access. In G.hn, a series of consecutive CFTS is allocated to a number of devices. The allocation is performed by the "domain master" and broadcast to all nodes in the network. There are pre-defined rules that specify which device can transmit after another device has finished using the channel. As all devices know "who is next", there is no need to explicitly send a "token" between devices. The process of "passing the token" is implicit and ensures that there are no collisions during Channel access. o Contention-Based Time Slots (CBTS), which are used for implementing CSMA/CARP Channel Access. In general, CSMA systems cannot completely avoid collisions, so CBTS are only useful for applications that do not have strict Quality of Service requirements.
6.21.2 G.hn security G.hn uses the AES encryption algorithm (with a 128-bit key length) to ensure confidentiality. Authentication and Key exchange is done following ITU-T Recommendation X.1035. G.hn specifies point-to-point security inside a domain, which means that each pair of transmitter and receiver uses a unique encryption key which is not shared by other devices in the same domain. For example, if node Alice sends data to node Bob, node Eve (in the same domain as Alice and Bob) will not be able to eavesdrop their communication. G.hn supports the concept of relays, in which one device can receive a message from one node and deliver it to another node further away in the same domain. Relaying provides extended range for large networks. To ensure security in scenarios with relays, G.hn specifies end-to-end encryption, which means that if node Alice sends data to node Bob
OPEN meter

using node Mallory as an intermediate relay, the data is encrypted in such a way that Mallory can not decrypt it or modify it. The other alternative (used by IEEE P1901, but not by G.hn) would be hop-by-hop encryption, in which data is sent from Alice to Mallory, decrypted by Mallory, encrypted again by Mallory for delivery to Bob and then decrypted by Bob. In this hop-by-hop scenario, data is available in plain text while it's being relayed by Mallory, which makes the system susceptible to a Man-in-the-middle attack. 6.21.3 G.hn Layered reference model G.hn specifies the Physical Layer and the Data Link Layer, according to the OSI model.
Fig. 13 G.hn layered model The G.hn Data Link Layer is divided into three sub-layers: The Application Protocol Convergence (APC) Layer, which accepts frames (usually in Ethernet format) from the upper layer (Application Entity) and encapsulates them into G.hn MAC Service Data Units (MSDUs). The maximum payload of each MSDU is 214 bytes. The Logical Link Control (LLC), which is responsible for encryption, aggregation, segmentation and Automatic repeat-request. This sub-layer is also responsible for "relaying" of MSDUs between nodes that may not be able to communicate through a direct connection. The Medium Access Control (MAC), which schedules Channel Access.
P P
OPEN meter

The G.hn Physical Layer is divided into three sub-layers: The Physical Coding Sub-layer (PCS), responsible for generating PHY headers. The Physical Medium Attachment (PMA), responsible for scrambling and FEC coding/decoding. The Physical Medium Dependent (PMD), responsible for bit-loading and OFDM modulation. The PMD sub-layer is the only sub-layer in the G.hn stack that is "medium dependent" (ie, some parameters may have different values for each media - power lines, phone lines and coaxial cable). The rest of sub-layers (APC, LLC, MAC, PCS and PMA) are "medium independent". The interface between the Application Entity and the Data Link Layer is called A-interface. The interface between the Data Link Layer and the Physical Layer is called Medium Independent Interface (MII). The interface between the Physical Layer and the actual transmission medium is called Medium Dependent Interface (MDI). 6.21.4 G.hn industry support Multiple organizations, including HomeGrid Forum, Universal Powerline Association (UPA), HomePNA, Consumer Electronics Powerline Communications Alliance (CEPCA), Broadband Forum have expressed support for the standard. Multiple silicon and IP vendors, including DS2, Coppergate, Ikanos and Aware have announced plans to support G.hn in future products. Large silicon vendors like Intel, Infineon, Texas Instruments; Consumer Electronics vendors like Panasonic; CE retailers like Best Buy; have expressed support for G.hn as the single next generation standard for wired networking.
7 CONCLUSIONS
The combination of AMI applications (such as Demand Side Management, Distribution Automation, Outage Management, Reduction of Energy Usage, Efficient Customer Switching, decrease of network losses, local balancing by load and generation control) could build a solid business case. But is is also this combination that requires a standards based AMI so that they all can make use of the same infrastructure and seamlessly integrate. Several manufacturers/utilities are proposing their own AMI proprietary solutions, and even if applications are quite similar, there is an important lack of interoperability among these systems, which prevents the large scale adoption of the smart multi metering technology. Although there are various reference models for Smart Metering, as described in this document, some gaps are identified and will have to be filled within this project.
OPEN meter

T
Page: 72 / 72
8 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 WP2 D2.1 Part4 v1.0

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

OPEN-Meter WP2 D2.1 Part4 v1.0

Hochgeladen von

Copyright:

Verfügbare Formate

Open Public Extended Network metering

Work Package: Type of document: Date:

WP2/T2.1.3 Deliverable 19.06.2009

D 2.1/PART 4 STATE-OF-THE-ART TECHNOLOGIES & PROTOCOLS DESCRIPTION OF STATE-OF-THE-ART COMMUNICATION

DUE DELIVERY DATE: 30.03.2009 ACTUAL DELIVERY DATE: 19.06.2009

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009

Energy Theme; Grant Agreement No 226369 Title:

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009

Energy Theme; Grant Agreement No 226369 Title: DLMS UA KEMA RWE

Gyozo Kmethy Willem Strabbing, Wolf Freudenberg Timm Gerbaulet

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009

Energy Theme; Grant Agreement No 226369 Title:

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009

Energy Theme; Grant Agreement No 226369 Title:

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009

Energy Theme; Grant Agreement No 226369 Title:

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009

Energy Theme; Grant Agreement No 226369 Title:

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009

Energy Theme; Grant Agreement No 226369 Title:

Name Measuring and switching equipment

Abbrev. M&S equipment

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009

Energy Theme; Grant Agreement No 226369 Title:

E-connection G-connection H-connection W-connection Network hub Communication module

Central access server

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009

Energy Theme; Grant Agreement No 226369 Title:

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009

Energy Theme; Grant Agreement No 226369 Title:

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009

Energy Theme; Grant Agreement No 226369 Title:

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009

Energy Theme; Grant Agreement No 226369 Title:

Open Public Extended Network metering

Work Package: Type of document: Date: Version:1.0

WP2/T2.1.3 Deliverable 19.06.2009