DLMS Green Book Architecture 5th PDF

EXCERPT FROM
Companion Specification
for Energy Metering
COSEM
Architecture
and Protocols
DLMS User Association
device ™
language
message
specification
Reference number: EXCERPT FROM DLMS UA 1000-2:2005, Fifth Edition

© Copyright 1997-2005 DLMS User Association
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
Table of Contents
1. Foreword ......................................................................................................................................................................4
2. Scope ............................................................................................................................................................................5
3. Introduction ..................................................................................................................................................................6
3.1 The COSEM communications framework ....................................................................................................................6
3.1.1 Client/server type operation, communication profiles ................................................................................................6
3.1.2 Connection (association) oriented operation .............................................................................................................7
3.2 Interoperability and interconnectivity in COSEM ..........................................................................................................8
3.3 Ensuring interconnectivity: the protocol identification service.......................................................................................9
3.4 Referenced documents ................................................................................................................................................10
3.5 Terms, definitions and abbreviations............................................................................................................................11
4. Architecture for meter data exchange........................................................................................................................14
4.1 General ........................................................................................................................................................................14
4.2 Application models .......................................................................................................................................................14
4.3 Communication models................................................................................................................................................14
4.4 Model of DLMS/COSEM servers..................................................................................................................................16
4.5 Model of a DLMS/COSEM based client .......................................................................................................................17
4.6 Model of a DLMS/COSEM based data collection system.............................................................................................18
4.7 Access requirements....................................................................................................................................................20
4.8 System integration and meter installation.....................................................................................................................21
4.9 Migration ......................................................................................................................................................................21
5. Physical layer services and procedures for connection oriented asynchronous data exchange ........................22
5.1 Overview ......................................................................................................................................................................22
5.2 Service specification ....................................................................................................................................................23
5.2.1 List of services ..........................................................................................................................................................23
5.2.1.1 Connection establishment/release related services ...............................................................................................23
5.2.1.2 Data communication services ................................................................................................................................23
5.2.1.3 Layer management services ..................................................................................................................................23
5.2.2 Use of the physical layer services .............................................................................................................................24
6. Direct Local Connection (excerpt)..............................................................................................................................25
6.1 METERING HDLC protocol using protocol mode E for direct local data exchange......................................................25
6.1.1 Overview ...................................................................................................................................................................26
6.1.2 Readout mode and programming mode....................................................................................................................26
6.2 Key to protocol mode E flow diagram...........................................................................................................................27
6.3 Physical layer - Introduction .........................................................................................................................................28
7. COSEM transport layers for IPv4 networks ...............................................................................................................29
7.1 Scope...........................................................................................................................................................................29
7.2 Overview ......................................................................................................................................................................29
7.3 The COSEM connection-less, UDP-based Transport layer..........................................................................................31
7.3.1 General .....................................................................................................................................................................31
7.4 The COSEM connection-oriented, TCP-based Transport layer ...................................................................................32
7.4.1 General .....................................................................................................................................................................32
7.5 Converting OSI-style transport layer services to and from RFC-style TCP function calls.............................................33
7.5.1 Transport layer and TCP connection establishment..................................................................................................33
7.5.2 Closing a transport layer and a TCP connection .......................................................................................................34
7.5.3 TCP connection abort ...............................................................................................................................................35
7.5.4 Data communication – the TCP-DATA service .........................................................................................................35
8. Data Link Layer using HDLC-Protocol .......................................................................................................................38
8.1 Overview ......................................................................................................................................................................38
8.2 Overview of the data link layer specification.................................................................................................................38
8.2.1 The LLC sub-layer.....................................................................................................................................................38
8.2.2 The MAC sub-layer ...................................................................................................................................................38
8.2.3 Specification method.................................................................................................................................................39
8.3 The LLC sub-layer........................................................................................................................................................39
8.3.1 The role of the LLC sub-layer....................................................................................................................................39
8.3.2 Service specification for the LLC sub-layer ...............................................................................................................40
8.3.2.1 Setting up the data link connection ........................................................................................................................40
8.3.2.1.1 Overview .............................................................................................................................................................40
8.4 The MAC sub-layer ......................................................................................................................................................41
8.4.1 HDLC selections .......................................................................................................................................................41
8.4.2 Service specification for the MAC sub-layer..............................................................................................................41
8.4.2.1 Setting up the MAC connection..............................................................................................................................41
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 2/55

8.4.2.1.1 Overview............................................................................................................................................................. 41
8.5 Data link layer management services .......................................................................................................................... 42
8.5.1 Overview................................................................................................................................................................... 42
9. COSEM application layer ............................................................................................................................................ 44
9.1 Overview...................................................................................................................................................................... 44
9.1.1 Specification method................................................................................................................................................. 44
9.1.2 Application layer structure......................................................................................................................................... 44
9.1.3 Service specification ................................................................................................................................................. 45
9.1.3.1 Services provided for application association establishment and release.............................................................. 45
9.1.3.2 Data communication services ................................................................................................................................ 45
9.1.4 Layer management services ..................................................................................................................................... 46
9.1.5 Protocol specification ................................................................................................................................................ 47
9.2 COSEM application layer – Service specification ........................................................................................................ 47
9.2.1 Summary of services ................................................................................................................................................ 47
9.2.2 Application association establishment and release................................................................................................... 48
9.2.3 Special application associations ............................................................................................................................... 48
9.2.3.1 Confirmed application associations........................................................................................................................ 48
9.2.3.2 Non-confirmed application associations................................................................................................................. 48
9.2.3.3 Pre-established application associations ............................................................................................................... 49
9.2.3.4 Mandatory application associations ....................................................................................................................... 49
9.2.4 Data communication ................................................................................................................................................. 49
9.3 COSEM application layer protocol specification........................................................................................................... 50
9.3.1 State definitions for the client side control function ................................................................................................... 50
9.3.2 State definitions for the server side control function.................................................................................................. 52
9.3.3 Protocol for application association establishment/release ....................................................................................... 53
9.3.3.1 Establishment of a confirmed application association............................................................................................ 53
Figures
Figure 1 – The three steps approach of COSEM: Modelling - Messaging - Transporting.................................................... 5
Figure 2 – Client / server relationship in COSEM ................................................................................................................ 6
Figure 3 – Exchanging messages via the communication protocol ..................................................................................... 6
Figure 4 – The COSEM application layer on the top of various lower layer stacks .............................................................. 7
Figure 5 – A complete communications session in the CO environment ............................................................................. 8
Figure 6 – DLMS/COSEM application model of a data collection system and metering equipment .................................. 14
Figure 7 – Communication profile models in DLMS/COSEM............................................................................................. 15
Figure 8 – DLMS/COSEM server model............................................................................................................................ 17
Figure 9 – Model of a DLMS/COSEM based client using multiple protocol stacks ............................................................ 18
Figure 10 – Model of a DLMS/COSEM based meter data collection system ..................................................................... 19
Figure 11 – Typical PSTN configuration ............................................................................................................................ 22
Figure 12 – The location of the physical layer.................................................................................................................... 23
Figure 13 – Protocol layer services of the COSEM 3-layer connection-oriented profile..................................................... 24
Figure 14 – Entering protocol mode E (HDLC) .................................................................................................................. 26
Figure 15 – Flow chart and switchover to METERING HDLC in protocol mode E ............................................................. 27
Figure 16 – Physical layer primitives ................................................................................................................................. 28
Figure 17 – Physical layer primitives, simplified example with one mode change only...................................................... 28
Figure 18 – COSEM as a standard Internet application protocol ....................................................................................... 30
Figure 19 – Transport layers of the COSEM_on_IP profile................................................................................................ 31
Figure 20 – TCP connection state diagram ....................................................................................................................... 33
Figure 21 – MSC and state transitions for establishing a transport layer and TCP connection.......................................... 34
Figure 22 – MSC and state transitions for closing a transport layer and TCP connection ................................................. 35
Figure 23 – Polling the TCP sub-layer for TCP abort indication ........................................................................................ 35
Figure 24 – Sending an APDU in three TCP packets ........................................................................................................ 36
Figure 25 – Receiving the message in several packets..................................................................................................... 37
Figure 26 – Data link (LLC) services for setting up the data link connection ..................................................................... 40
Figure 27 – MAC sub-layer services for setting up the MAC (DL) connection at the client and server sides..................... 42
Figure 28 – Layer management services........................................................................................................................... 43
Figure 29 – The structure of the COSEM application layers.............................................................................................. 44
Figure 30 – Structure of the COSEM AL when the server is using SN references ............................................................ 46
Figure 32 – Summary of COSEM application layer services ............................................................................................. 47
Figure 33 – Normal service sequence for the COSEM-OPEN service .............................................................................. 48
Figure 34 – Partial state machine for the client side control function ................................................................................. 51
Figure 35 – Partial state machine for the server side control function ............................................................................... 52
Figure 36 - MSC for successful application association establishment preceded by a successful lower layer connection
establishment .................................................................................................................................................................... 54

1. Foreword
Copyright
© Copyright 1997-2005 DLMS User Association.
This document is confidential. It may not be copied, nor handed over to persons outside the
standardisation environment.
The copyright is enforced by national and international law. The "Berne Convention for the
Protection of Literary and Artistic Works", which is signed by 121 countries worldwide, and other
treaties apply.
Acknowledgement
The actual document has been established by a team of experts working for members of the DLMS
User Association and by working group members of standardisation bodies, for example IEC TC13
WG14, CEN TC294 WG2 and IEC TC57 WG9.
Status of standardization
This fifth edition of the "Green Book" includes the specification of the communication protocol
layers based on:
IEC 62056-42, Electricity metering - Data exchange for meter reading, tariff and load control - Part
42: Physical layer services and procedures for connection-oriented asynchronous data exchange;
IEC 62056-46 Ed 1.0, Electricity metering - Data exchange for meter reading, tariff and load control
- Part 46: Data link layer using HDLC protocol, as amended by 13/1336/CDV, draft Amendment 1;
draft IEC 62056-47 Ed.1.0, 13/1337/CDV, Electricity metering - Data exchange for meter reading,
tariff and load control - Part 47: COSEM transport layers for IPv4 networks
draft IEC 62056-53 ed. 2.0, 13/1338/CDV, Electricity metering - Data exchange for meter reading,
tariff and load control - Part 53: COSEM application layer
Annex E of IEC 62056-21, Electricity metering - Data exchange for meter reading, tariff and load
control Part 21: Direct local data exchange, is incorporated (Clause 6).
For easier use, in this edition, changes compared to Edition 4 are marked by highlighted text.

2. Scope
The data model uses generic building

1. Modelling COSEM Interface Objects
blocks to define the complex functionality
of the metering equipment. It provides a
view of this functionality of the meter as it n
is available at its interface(s). The model t io
a
does not cover internal, implementation- ci
oVersion=0
s
As Max Def
Register 0..n Class_id=3,
specific issues.
er
Attribute(s) Data Type Min
1. logical_name (static) octet-string
Us
2. value (dyn.) instance specific
3. scaler-unit (static) scal_unit_type
The communication protocol defines how S
M
Method(s) m/o
DL
1. reset o
the data can be accessed and
exchanged.
The COSEM specifications follow a three

step approach as illustrated in Figure 1: Protocol Services to access
attributes and methods
Step 1: The meter model and data
identification (data model); Communication Protocol
2. Messaging
Step 2: The mapping of the model into
protocol data units (PDU);
Messages :
Step 3: The transportation of the bits and Service_Id( Class_Id, Instance_Id, Attribute_Id/Method_Id )
bytes through the communication
channel. Encoding: ( APDU )
Metering domain specific Interface C0 01 00 03 01 01 01 08 00 FF 02
Objects are specified by the COSEM
.. .
C,
specification "Identification System and
E
,I
Interface Classes" DLMS UA 1000-1. The 3. Transporting
functionality of the meter is defined by O
the instances of these interface classes, IS
called COSEM objects. Logical names
(OBIS codes) identify the COSEM
objects.
Figure 1 – The three steps approach of COSEM: Modelling - Messaging - Transporting

- The attributes and methods of these COSEM objects can be accessed and used via the messaging
services of the application layer.
- The lower layers (data link layer, transport layer and physical layer) of the protocol transport the
information.
- The application layer, data link layer, transport layer and physical layer are described in this document.
- Conformance testing: see specification DLMS UA 1001-1 "COSEM Conformance Test Process".
- Terms are explained in DLMS UA 1002 "COSEM Glossary of Terms".

3. Introduction
3.1 The COSEM communications framework
3.1.1 Client/server type operation, communication profiles

Communication with metering equipment using the COSEM interface object model is based on the
client/server paradigm, where metering equipment 1 plays the server role. In this environment,
communication takes place always between a client and a server application process: in other
words, the server application process provides remote services to the client application process.
These services are provided via exchanging messages (SERVICE.requests / .responses) between
the client and the server application processes, as it is shown in Figure 2.
Server application
Client application (COSEM device)
SERVICE.request
SERVICE.response
Figure 2 – Client / server relationship in COSEM
In general, the client and the server application processes are located in separate devices;
exchanging messages is done with the help of the communication protocol.
.request
Client .response Server
.request .response
Application
layer
Protocol
Intermediate
protocol layers
Physical layer
Physical channel
Figure 3 – Exchanging messages via the communication protocol
1
The term "metering equipment" is an abstraction; consequently the equipment playing the role of a server may be any type of
equipment for which this abstraction is suitable.

In general, communication protocols are structured in layers. The client and server COSEM
applications use services of the highest protocol layer, that of the application layer: Consequently,
this is the only protocol layer containing COSEM specific element(s). This is called the
xDLMS_ASE. All COSEM interface object related services – the xDLMS application protocol – are
provided by this xDLMS_ASE.
Other protocol layers are independent from the COSEM model, consequently the COSEM
application layer can be placed on the top of a wide variety of lower protocol layer stacks, as it is
shown in Figure 4.
Profile 1 Profile 2 Profile M
Application layer
xDLMS_ASE ACSE
N layer N layer N layer

N-1 layer
………
Physical layer Physical layer

Physical layer
Figure 4 – The COSEM application layer on the top of various lower layer stacks
A complete protocol stack – including the application layer, a physical layer and all protocol layers
between these extreme layers – is called a communication profile.
A communication profile is characterized by the protocol layers included, their parameters, and by
the type – connection-oriented or connectionless – of the ACSE 2 included in the application layer.
3.1.2 Connection (association) oriented operation

The xDLMS application protocol is a connection-oriented protocol. It means, that the client and
server application processes can use the services of the xDLMS_ASE only when these application
processes are associated 3. Therefore, in this environment a communication session consists of
three phases, as it is shown in Figure 5.
2
ACSE = Association Control Service Element
3
Application associations can be considered as application level connections.

Client application Server application
Phase 1.
Connection establishment
Phase 2.
Data communication
Phase 3.
t
Connection release
Figure 5 – A complete communications session in the CO environment
In the DLMS/COSEM environment, application association establishment is normally done by using

the association request/response services of the standard association control service element. On
the other hand, for the purposes of very simple devices, one-way communicating devices and for
multicasting and broadcasting, pre-established application associations are also allowed; see
Clause 9.2.3.3. For such associations, there is no need to use the services of the ACSE: a full
communication session may include only the data communication phase. (It can be considered that
the connection establishment phase has been already done somewhere in the past.)
3.2 Interoperability and interconnectivity in COSEM

In the COSEM environment, interoperability and interconnectivity is defined between a server and a
client application processes. A client and a server must be interconnectable and interoperable to
ensure data exchange between the two systems.
Interoperability is an application level notion: a client application is interoperable with a server

application, if it is able to establish application associations using the Association.request/
.indication/ .response/ . confirm services of the standard connection-oriented ACSE, as it is
specified in the clause describing the COSEM application layer.
Using these services, application associations may be established between a client and a server or
between a client and different servers using various contexts concerning the authentication
mechanism, the xDLMS services available and other parameters. For example, the client may
establish an AA with a server in an xDLMS context using short name (SN) referencing and with
another server in an xDLMS context using logical name (LN) referencing. Although the messages
exchanged depend on the context of the application association established, both servers are
interoperable with the client, if it is able to establish the application association using the right
context with both servers.
With this, using the services of the standard ACSE for application association establishment
ensures interoperability in COSEM.
On the other hand, interconnectivity is a protocol level notion: in order to be able to exchange
messages the client and the server application processes should be interconnectable and
interconnected.
Two application processes are interconnectable if they use the same communication profile. Before
the two application processes can establish an application association, they must be
interconnected first. The two application processes are interconnected, if each peer protocol layers
of both sides, which need to be connected, are connected.

Therefore, in order to be interconnected, the client and server application processes should be
interconnectable and shall establish the required connections.
With this, interconnectivity in DLMS/COSEM is ensured by the ability of the COSEM application
process to establish a connection between all peer layers, which need to be connected.
3.3 Ensuring interconnectivity: the protocol identification

service
In DLMS/COSEM, application association establishment between a server and a client is always
initiated by the client. However, in some cases, the client application process may not have
knowledge about the protocol stack used by an unknown server device (for example when the
server has initiated the physical connection establishment). In such cases, the client must obtain
information about the protocol stack implemented in the server. The COSEM framework provides a
specific, application level service to for this purpose: the protocol identification service.
It is an optional application level service, which allows the client to obtain information, after
establishing a physical connection, about the protocol stack implemented in the server. The
protocol identification service uses directly the data communication services (PH-
DATA.request/.indication) of the physical layer; it bypasses the remaining part of the protocol.
It is recommended to support it in all communication profiles using this Physical layer.

3.4 Referenced documents

Ref. Title
DLMS UA 1000-1 Ed. COSEM Identification System and Interface Objects, "Blue Book"
7.0:2005
DLMS UA 1001-1 Ed. COSEM Conformance Test Process, "Yellow Book"
2.0:2002
DLMS UA 1002 Ed. 1.0:2003 COSEM Glossary of Terms, "White Book"

IEC 61334-4-41 Ed.1.0: 1996 Distribution automation using distribution line carrier systems - Part 4: Data
communication protocols - Section 41: Application protocol - Distribution line message
specification
IEC 61334-6 Ed 1.0: 2000 Distribution automation using distribution line carrier systems – Part 6: A-XDR encoding
rule
IEC 62056-21 Ed 1.0: 2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 21:
Direct local data exchange
IEC 62056-31 Ed 1.0 :1999 Electricity metering – Data exchange for meter reading, tariff and load control – Part 31:
Use of local area networks on twisted pair with carrier signalling
IEC 62056-42 Ed.1.0: 2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 42:
Physical layer services and procedures for connection-oriented asynchronous data
exchange
IEC 62056-46 Ed.1.0:2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 46:
Data link layer using HDLC protocol
Amendment 1: 200X
13/1336/CDV
Draft IEC 62056-47 Ed 1.0 Electricity metering – Data exchange for meter reading, tariff and load control – Part 47:
13/1337/CDV COSEM transport layer for IP networks
IEC 62056-53 Ed 2.0: 200X Electricity metering – Data exchange for meter reading, tariff and load control – Part 53:
13/1338/CDV COSEM application layer
IEC 62056-61 Ed 2.0: 200X, Electricity metering – Data exchange for meter reading, tariff and load control – Part 61:
13/1341/CDV OBIS Object identification system
IEC 62056-62 Ed 2.0: 200X, Electricity metering – Data exchange for meter reading, tariff and load control – Part 62:
13/1342/CDV Interface classes
ISO/IEC 8649 Ed. 2.0: 1996 Information technology - Open Systems Interconnection - Service definition for the
Association Control Service Element
ISO/IEC 8650-1 Ed 2.0: 1996 Information technology - Open systems interconnection - Connection-oriented protocol
for the association control service element: Protocol specification
ISO/IEC 8802-2 Ed. 3.0: 1998 Information technology – Telecommunications and information exchange between
systems – Local and metropolitan area networks – Specific requirements – Part 2:
Logical link control
ISO/IEC 8824: 1990 Information technology - Open Systems Interconnection - Specification of Abstract
Syntax Notation One (ASN.1)
ISO/IEC 8825: 1990 Information technology - Open Systems Interconnection - Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1)
ISO/IEC 13239: Ed. 3.0: 2002 Information Technology - Telecommunications and information exchange between
systems – High-level data link control (HDLC) procedures
EN 13757-2 Ed. 1.0: 2004 Communication system for and remote reading of meters - Part 2 : Physical and Link
Layer, Twisted Pair Baseband (M-Bus)
NEMA C12.21: 1999 Protocol Specification for Telephone Modem Communication
STD0005 (1981) Internet Protocol. Also: RFC0791, RFC0792, RFC0919, RFC0922, RFC0950, RFC1112
STD0006 (1980) User Datagram Protocol. Also: RFC0768

STD0007 (1981) Transmission Control Protocol. Also: RFC0793

3.5 Terms, definitions and abbreviations

Abbreviation Explanation
AA Application Association
AARE Application Association Response

AARQ Application Association Request
ACSE Application Control Service Element
AE Application Entity
AP Application Process
APDU Application Layer Protocol Data Unit

API Application Programming Interface
ARP Address Resolution Protocol
ASE Application Service Element

ASO Application Service Object
ATM Asynchronous Transfer Mode
A-XDR Adapted Extended Data Representation
base_name The short_name corresponding to the first attribute (“logical_name”) of a COSEM object
BER Basic Encoding Rules
CF Control Function
class_id Class identification code
client A station, asking for services. Normally the master station

.cnf .confirm service primitive
CO Connection-oriented
COSEM Companion Specification for Energy Metering
COSEM Interface An instance of a COSEM Interface Class
Object
COSEM_on_IP The TCP-UDP/IP based COSEM communication profile
DCE Data Communication Equipment (communications interface or modem)

DCS Data Collection System
DISC Disconnect (a HDLC frame type)
DLMS Device Language Message Specification
DM Disconnected Mode (a HDLC frame type)
DPDU Data Link Protocol Data Unit

DSAP Data Link Service Access Point
DSDU Data Link Service Data Unit
DTE Data Terminal Equipment (computers, terminals or printers)
FCS Frame Check Sequence
FDDI Fibre Distributed Data Interface

FRMR Frame Reject (a HDLC frame type)
FTP File Transfer Protocol
GMT Greenwich Mean Time
GSM Global System for Mobile communications

HCS Header Check Sequence
HDLC High-level Data Link Control

HHU Hand Held Unit
HLS High Level Security

HTTP Hypertext Transfer Protocol
I Information (a HDLC frame type)
IC Interface Class
IETF Internet Engineering Task Force
.ind .indication service primitive

IP Internet Protocol
LAN Local Area Network
LLC Logical Link Control (Sub-layer)

LLS Low Level Security
LSAP LLC sub-layer Service Access Point

LPDU LLC Protocol Data Unit
LSB Least Significant Bit
LSDU LLC Service Data Unit
m mandatory, used in conjunction with attribute and method definitions

MAC Medium Access Control (sub-layer)
master Central station - station which takes the initiative and controls the data flow
MIB Management Information Base

MSAP MAC sub-layer Service Access Point (here it is equal to the HDLC address)
MSB Most Significant Bit
MSC Message Sequence Chart
MSDU MAC Service Data Unit

NDM Normal Disconnected Mode
NRM Normal Response Mode
N(R) Receive sequence Number

N(S) Send sequence Number
o optional, used in conjunction with attribute and method definitions

OBIS Object Identification System
OSI Open System Interconnection
PAR Positive Acknowledgement with Retransmission
PDU Protocol data unit

P/F Poll/Final
PH Physical Layer
PHPDU PH PDU
PHSDU PH SDU
PSDU Physical layer Service Data Unit
PSDU Physical layer Service Data Unit
PSTN Public Switched Telephone Network

PPP Point-to-Point Protocol
RARP Reverse Address Resolution Protocol
.req .request service primitive

.res .response service primitive

RLRE Application Association Release Response
RLRQ Application Association Release Request

RNR Receive Not Ready (a HDLC frame type)
RR Receive Ready (a HDLC frame type)
SAP Service Access Point

SDU Service Data Unit
SNMP Simple Network Management Protocol

SNRM Set Normal Response Mode (a HDLC frame type)
server A station, delivering services. The tariff device (meter) is normally the server, delivering the requested
values or executing the requested tasks.
slave Station responding to requests of a master station. The tariff device (meter) is normally a slave
station.
TCP Transmission Control Protocol
TWA Two Way Alternate
UA Unnumbered Acknowledge (a HDLC frame type)

UDP User Datagram Protocol
UI Unnumbered Information (a HDLC frame type)
UNC Unbalanced operation Normal response mode Class
USS Unnumbered Send Status

VAA Virtual Application Association
V(R) Receive state Variable
V(S) Send state Variable
WPDU Wrapper Protocol Data Unit
xDLMS-ASE Extended DLMS Application Service Element

4. Architecture for meter data exchange
4.1 General
This clause describes simplified models of DLMS/COSEM based metering equipment and data
collection systems and briefly describes how market requirements for data exchange using
DLMS/COSEM based systems are met.
4.2 Application models

DLMS/COSEM models metering equipment as a set of logical devices, hosted in a single physical
device. Each logical device models a subset of the functionality of the metering equipment as these are
seen through its communication interfaces. The various functions are modelled using the COSEM interface
objects.
Data collection systems are modelled as a set of application processes. Each application process
may have different roles and access rights, granted by the metering equipment.
NOTE The application processes may be hosted by one or several physical devices.
Metering equipment: Server
Logical device #01 Logical device #02 Logical device #0n

Management logical COSEM objects COSEM objects
device
COSEM objects
Data collection system: Client
Application process
Application process Application process
#01
#02 #0m
Public client
Figure 6 – DLMS/COSEM application model of a data collection system and metering equipment
The Public client application process and the Management logical device application process have
a special role and they must always be present.
See more in the clause “COSEM interface classes” in the Blue Book.
4.3 Communication models

Data exchange between a data collection system and metering equipment takes place based on
the client/server paradigm: the client requires services from the server, which provides them. A
client may be able to exchange data with a single server or with multiple servers at the same time.
A server may be able to exchange data with one or more clients at the same time. Servers are not
able to exchange data with each other.

NOTE Data exchange between the logical devices within a physical device may be possible. Similarly, data exchange
between the application processes of a single client or between clients may be possible. Such exchanges are out of the
scope of this specification.
To transport data over various media, communication protocols are required. For such protocols,
DLMS/COSEM has chosen a layered approach, where a communication protocol comprises several
layers, with each layer having distinct tasks, and each layer providing services to the upper layer
and using services of its supporting layer(s). The number and type of layers depend on the
communication media used.
COSEM Client Application Process COSEM Server Application Process
Comm. Comm. Comm. Communication Communication Communication

profile #01 profile #02 profile #0n profile #01 profile #02 profile #0n
COSEM Application layer

xDLMS
ACSE
ASE
Wrapper
Transport layer N-1 layer
N-2 layer
Network layer
Data link layer Data link layer
Physical layer Physical layer Physical layer
e.g. PSTN, GSM
Media xx
Figure 7 – Communication profile models in DLMS/COSEM
The top layer is always the COSEM application layer, providing services to the COSEM application
Process (AP). It may be supported by any layer, which is able to provide the services required by
the COSEM application layer, either directly or through a wrapper.
A given set of protocol layers with the COSEM application layer on top constitutes a COSEM
communication profile. A single device may support more than one communication profiles, to allow
data exchange using various media. It is the task of the client side AP to decide which
communication profile should be used.
This edition of the Green Book specifies the following communication profiles:
- the 3-layer, connection-oriented (CO), HDLC-based profile. This comprises the COSEM application
layer, the HDLC-based data link layer and a physical layer for connection-oriented asynchronous data
exchange. It supports data exchange via a local optical or electrical port according to IEC 62056-21,
leased lines and the PSTN or the GSM telephone network;

- the TCP-UDP/IP based communication profiles. These profiles support data exchange via the Internet
over various physical media, like Ethernet, ISDN, GPRS, PSTN or GSM using PPP etc. In these profiles,
the COSEM application layer is supported by the COSEM transport layer(s), comprising a wrapper and
the internet TCP or UDP protocol. Lower layers can be selected according to the media to be used, as
the TCP-UDP layers hide their particularities.
Further communication profiles to support other media, like twisted pair using base band signalling
(MBUS, EN 13757-2), twisted pair using carrier signalling (EURIDIS, IEC 62056-31), or power line
carrier (PLC) can be easily developed. The elements to be specified in each communication profile
are given in Subclause “Communication profile specific elements” of the COSEM application layer
specification.
In DLMS/COSEM, data exchange on the application level is always connection-oriented:
- to be able to exchange application data, an application level connection, called Application Association
(AA) has to be established between a client AP and a server logical device. This is the task of the
connection-oriented Association Control Service Element (ACSE) of the application layer;
- before initiating the establishment of an AA, the peer physical layers of the client and server side
protocol stacks have to be connected. The intermediate layers may have to be connected or not. Each
layer, which needs to be connected, may support one or more connections simultaneously;
- once the necessary AA(s) are established, application data exchange can take place, by accessing
attributes and methods of the COSEM interface objects. This is the task of the xDLMS service element;
- at the end of the data exchange, the AA(s) have to be released.
4.4 Model of DLMS/COSEM servers

The figure below shows the model of two DLMS/COSEM servers. One of them uses a 3-layer,
connection-oriented, HDLC-based communication profile, and the other one uses a TCP-UDP/IP
based communication profile.
DLMS/COSEM meter DLMS/COSEM meter

using 3-layer, CO, HDLC based profile using TCP-UDP/IP based profile
Log_Dev_1 Web Log_Dev_1

Log_Dev_2 Log_Dev_n Files Log_Dev_2 Log_Dev_m
(Mgmt.) pages (Mgmt.)
COSEM Application layer COSEM Application layer

xDLMS FTP HTTP xDLMS
ACSE ASE ACSE
ASE
COSEM Transport layer
# 01 # 0x # 0y
COSEM wrapper
DLMS/
FTP HTTP
COSEM
port port
Transport layer port
TCP or UDP
Network layer
# 01 # 0x # 0y IP
HDLC based data link layer
Phy Device
Addr Data link layer Data link layer Data link layer
e.g. PPP e.g. Ethernet e.g. ATM
Physical layer Physical layer Physical layer Physical layer

e.g. RS 232, RS 485, optical port, current loop e.g. RS 232 e.g. Ethernet e.g. PPP
Port # 1 Port # 2 Port # k Port # 1 Port # 2 Port # l

Figure 8 – DLMS/COSEM server model
The metering equipment on the left hand side comprises “n” logical devices and supports the 3-
layer, connection-oriented, HDLC-based communication profile.
The COSEM application layer is supported by the HDLC-based data link layer. Its main role is to
provide a reliable data transfer between the peer layers. It also provides addressing of the logical
devices in such a way, that each logical device is bound to a single HDLC address, with the
Management logical device always being bound to the HDLC address 0x01. To allow creating a
LAN so that several metering devices at a given metering site can be reached through a single
access point, another address, the physical address is also provided by the data link layer. The
logical device addresses are also referred to as upper HDLC addresses, while the physical device
address is also referenced as a lower HDLC address.
The physical layer supporting the data link layer provides serial bit transmission between physical
devices hosting the client and server applications. This allows using various interfaces, like RS
232, RS 485, 20 mA current loop, etc. to transfer data locally through PSTN and GSM networks
etc.
The metering equipment on the right hand side comprises “m” logical devices.
The COSEM application layer is supported by the COSEM transport layer, comprising the internet
TCP or UDP layer and a wrapper. The main role of the wrapper is to adapt the OSI-style service
set, provided by the COSEM transport layer to and from TCP and UDP function calls. It also
provides addressing for the logical devices, binding them to a SAP called wrapper port, with the
Management logical device always being bound to wrapper port 0x01. Finally, the wrapper provides
information about the length of the APDUs transmitted, to help the peer to recognise the end of the
APDU. This is necessary due the streaming nature of TCP.
Through the wrapper, the COSEM application layer is bound to a TCP or UDP port number, which
is used for the DLMS/COSEM protocol and application. The presence of the TCP and UDP layers
allows incorporating other internet applications, like FTP or HTTP, bound to their standard ports
respectively.
The TCP layer is supported by the IP layer, which is in turn may be supported by any set of lower
layers depending on the communication media to be used (for example Ethernet, PPP, IEEE 802
etc.).
Obviously, in a single server it is possible to implement several protocol stacks, with the common
COSEM application layer being supported by distinct sets of lower layers. This allows the server to
exchange data via various communication media with clients in different application associations.
Such a structure would be similar to the structure of a DLMS/COSEM client show below.
4.5 Model of a DLMS/COSEM based client

Figure 9 shows the model of a Data Collection System based on DLMS/COSEM.

DLMS/COSEM data collection system

using both 3-layer, CO, HDLC based and TCP-UDP/IP based communication profile
Appl_
Web Appl_ Appl_
Files Process_1
pages Process_2 Process_m
Public client
COSEM Application layer

FTP HTTP ACSE xDLMS
ASE
COSEM Transport layer
# 01 # 0w # 0z
DLMS/COSEM wrapper
DLMS/
FTP HTTP
COSEM
port port
Transport layer port
TCP or UDP
Network layer
IP
# 01 # 0w # 0z
Data link layer Data link layer Data link layer
e.g. PPP e.g. Ethernet e.g. ATM HDLC based data link layer
Physical layer Physical layer Physical layer Physical layer

e.g. RS 232 e.g. Ethernet e.g. PPP e.g. RS 232, RS 485, optical port, current loop
Port # 1 Port # 2 Port # n Port # 1 Port # 2 Port # n
Figure 9 – Model of a DLMS/COSEM based client using multiple protocol stacks
The model of the client – obviously – is very similar to the model of the servers:
- in this particular model, the COSEM application layer is supported either by the HDLC-based data link
layer or the COSEM transport layer, meaning, that the Application layer uses the services of one or the
other, as determined by the application processes. In other words, the APDUs are received from or sent
through the appropriate supporting layer, which in turn use the services of their supporting layers
respectively;
- unlike on the server side, the addressing provided by the HDLC layer has a single level only, that of the
Service Access Points (SAP) of each Application Process (AP).
As we have seen, client APs and server logical devices are identified by their SAPs. Therefore, an
AA between a client and a server side AP can be identified by a pair of client and server SAPs.
The COSEM application layer may be capable to support one or more application associations
simultaneously. Likewise, the lower layers may be capable of supporting more than one connection
with their peer layers. This allows data exchange between clients and servers simultaneously via
the different ports and communication media.
4.6 Model of a DLMS/COSEM based data collection system

The Figure below shows the model of a DLMS/COSED based data collection system.

Metering Metering
site #1 site #n
DLMS
DLMS
DLMS
e.g. RS 485
Ethernet Local DCS
DLMS
DLMS DLMS
DLMS
HHU
Access Point Access Point
Firewall Modem
Server
Portable DCS
WAN
e.g. PSTN, GSM
Internet
Modem Modem
Firewall Firewall
Server Remote DCS Server
Remote DCS

The architecture of the two remote data collection systems is identical. Both systems can reach
both metering sites via either the internet or a PSTN or GSM WAN.
The address of the physical device hosting the client APs is provided by the WAN. The Application
Process address identifies the type of the client only, for example address 0x10 is the address of
the Public Client in each DCS.
Although in the client/server environment data exchange is generally initiated by the client,
DLMS/COSEM provides a non client/server type service, called Event Notification to allow the
server to notify the client about an occurrence of an event in the server.
4.7 Access requirements

DLMS/COSEM meets the following access requirements for data exchange:
- it allows various parties (data collection systems) to have access to metering data;
- it allows to exchange data with a single or multiple metering equipment at a metering site;
- in case of multiple metering equipment at a metering site, a single access point is available;
- it is possible to exchange data with metering equipment either remotely or locally;
- depending on the resources of the metering equipment, local and remote data exchange may be
performed without interfering with each other;
- it is possible to use various communication media both on local area networks (LAN) and wide area
networks (WAN);
- it provides authentication mechanisms to control access to data, these mechanisms are made available
by the COSEM application layer and the interface objects (Association object);
- it supports easy system integration and meter deployment;
- it provides a migration path from legacy systems to DLMS/COSEM based systems.
The key element to ensure that the above requirements are met is the Application Association
provided by the COSEM application layer. For details, see the relevant clauses of this book.
Below, two aspects are dealt with in some detail.

4.8 System integration and meter installation

System installation is supported by DLMS/COSEM in a number of ways.
As shown in Figure 9, the presence of a Public Client (bound to address 0x10 in any profile) is
mandatory in each client system. Its main role is to reveal the structure of an unknown (for example
newly installed) metering equipment. This takes place within a mandatory application association
between the public client and the management logical device (see Figure 10), with no security
precautions. Once the structure is known, data can be accessed with using the proper
authentication mechanisms.
When a new meter is installed in the system, it may generate an event report to the client. Once
this is detected, the client can read the internal structure of the meter, and then download the
necessary configuration information (for example tariff schedules and installation specific
parameters) to the meter. With this, the meter is ready to use.
System integration is also facilitated by the availability of the DLMS/COSEM conformance testing,
described in the Yellow Book. With this, correct implementation of the specification in metering
equipment can be tested and certified.
4.9 Migration
By today, there are thousands of data collection systems - based on legacy protocols, for example
IEC 61107 (or IEC 1107 before) – installed. Obviously, a migration path is necessary.
DLMS/COSEM provides this by adding a new protocol mode “E” to the IEC 62056-21 standard (was
IEC 1107). With this, during the opening sequence, the meter (server) is able to advise the HHU
(client), that the advanced Mode E is available. If the HHU acknowledges it, they will continue the
data exchange using the 3-layer, CO, HDLC-based protocol. The information exchange takes place
then using the COSEM object model. If not, data exchange continues in the conventional Mode C,
although the functionality may be limited.

5. Physical layer services and procedures for

connection oriented asynchronous data exchange
5.1 Overview
From the external point of view, the physical layer provides the interface between the Data
Terminal Equipment (DTE) and the Data Communication Equipment (DCE), see Figure 12. Figure
11 shows a typical configuration for data exchange through a wide area network, for example the
PSTN.
COSEM client COSEM server
DTE DCE DTE

DCE
Sch lumb erg er
Transit network (o)

00001,6
N° 00012356
kWh
10 (40)A 230V 50Hz
DTE to DCE DCE to DTE

ITU-T V. Series ITU-T V. Series
EIA RS232, RS485 EIA RS232, RS485
Hayes, etc... Hayes, etc…
Figure 11 – Typical PSTN configuration
From the physical connection point of view, all communications involve two sets of equipment
represented by the terms caller system and called system. The caller is the system that decides to
initiate a communication with a remote system known as the called party; these denominations
remain valid throughout the duration of the communication. A communication is broken down into a
certain number of transactions. Each transaction is represented by a transmission from the
transmitter to the receiver. During the sequence of transactions, the caller and called systems take
turns to act as transmitter and receiver.
From the data link point of view, the central station normally acts as a master (primary station),
taking the initiative and controlling the data flow. The tariff device is the slave (secondary station),
responding to the master station.
From the application point of view, the central station normally acts as a client asking for services,
and the metering equipment acts as a server delivering the requested services.
The situation involving a caller client and a called server is undoubtedly the most frequent case,
but a communication based on a caller server and a called client is also possible, in particular to
report the occurrence of an urgent alarm.
For the purposes of local data exchange, two DTEs can be directly connected using appropriate
connections. To allow using a wide variety of media, this document does not specify the physical
layer signals and their characteristics. However, the following assumptions are made:
- the communication is point to point or point to multipoint;

- both half-duplex and duplex connections are possible;
- asynchronous transmission with 1 start bit, 8 data bits, no parity and 1 stop bit (8N1).

From the internal point of view, the physical layer is the lowest layer in the protocol stack.
DTE DTE
Client Server
application application
Application Application
layer Transit network layer
Protocol
Protocol
Data Data
Data Link comm. Data Link
comm. layer
layer equipment
equipment
Physical (DCE) Physical
(DCE)
layer layer
Figure 12 – The location of the physical layer
This document defines the services of the physical layer towards its peer layer(s) and the upper
layers, and the protocol of the physical layer.
5.2 Service specification
5.2.1 List of services

ITU-T X.211 defines a set of capabilities to be made available by the physical layer over the
physical media. These capabilities are available via service primitives, as follows:
5.2.1.1 Connection establishment/release related services
PH-CONNECT.request / PH-CONNECT.indication / PH-CONNECT.confirm

PH-ABORT.request / PH-ABORT.confirm / PH-ABORT.indication
5.2.1.2 Data communication services

PH-DATA.request / PH-DATA.indication
5.2.1.3 Layer management services

In addition to the services above, some additional physical layer services may be necessary, which
are used by or provided for the layer management process, which is part of the application
process. Some examples are given below:
PH-INITIALIZE.request / PH-INITIALIZE.confirm
PH-GET_VALUE.request / PH-GET_VALUE.confirm
PH-SET_VALUE.request / PH-SET_VALUE.confirm
PH-LM_EVENT.indication

As these services are of local importance only, their definition is not within the scope of this
specification.
5.2.2 Use of the physical layer services

Figure 13 shows how different service users use the service primitives of the physical layer.
Application
Physical
Layer management Application process connection
process manager
ASO services
AL management
services
Application layer
PH-CONNECT.req /.cnf /.ind

PH-ABORT.req /.cnf /.ind
Connect/disconnect and
data related services
PH-DATA.req /.ind
DL management
Protocol
services
Data link layer
PH-DATA.req /.ind
PH-ABORT.ind
PH management
services
Physical layer
Figure 13 – Protocol layer services of the COSEM 3-layer connection-oriented profile

As it is shown in Figure 13, the connection establishment/release services are used by and provided for the
physical connection manager application process, and not the data link layer.
more details, see complete Green Book ....

6. Direct Local Connection (excerpt)
This chapter is an excerpt of IEC 62056-21 describing hardware and protocol specifications for
local meter data exchange. In such systems, a hand-held unit (HHU) or a unit with equivalent
functions is connected to a tariff device or a group of devices.
Only COSEM related items are described here. The complete information can be found in IEC
62056-21.
6.1 METERING HDLC protocol using protocol mode E for

direct local data exchange
The protocol stack as described in Clauses 4.1, 8 and 0 of this document shall be used.
The switch to the baudrate Z shall be at the same place as for protocol mode C. The switch confirm
message, which has the same structure as the acknowledgement/option select message, is
therefore at the new baud rate but still with parity (7E1). After the acknowledgement, the binary
mode (8N1) will be established.
As the server acknowledgement string is a constant in the server's program, it could be easily
possible to switch to the baud rate and the binary mode (Z Bd. 8N1) at the same time. The
characters ACK 2 Z 2 CR LF shall be replaced by their 8 bit equivalents by adding the correct
parity bit in order to simulate their 7E1 equivalents. This alternative method is not visible to the
client; both have an equivalent behaviour (see also Figure 17).
A client, which is not able to support protocol HDLC mode E (W=2) will answer in a protocol mode
as defined by Y (normally protocol mode C).
The enhanced capability of the server (tariff device) is communicated with the escape sequence
"\W" which is part of the meter identification string (see items 14), 23) and 24) in IEC 62056-21,
Clause 6.3.14) 4.
4
W = @ is used for country specific applications

6.1.1 Overview
Sign on
Client
/ ? Device address ! CR LF
(HHU)
Server
/ XXXZ \W Ident CR LF 300 Bd 7E1
Tariff
device
W=2
Client
ACK 2 Z 2 CR LF ACK V Z Y CR LF
Server not
ACK 2 Z 2 CR LF
accepted
IEC 62056-21 Z Bd. 7E1
Mode Y
End
METERING
Client Z Bd. 8N1
HDLC protocol
initiates ...
Figure 14 – Entering protocol mode E (HDLC)
6.1.2 Readout mode and programming mode

These modes are handled within the higher layers of the protocol. After having established a
transparent channel, the "METERING HDLC protocol" takes care of the correct data handling, and
a DLMS based application handles access rights, read only or read/write access etc. Necessary
procedures are described in chapters 4.1, 8 and 0. The flow chart and the changeover to HDLC for
the direct local data exchange protocol, protocol mode E is shown below.

Client Server
(HHU) (Tariff device)
Yes
START REQUEST Error ?
No
Yes
Error ? IDENTIFICATION
No
Switchover to protocol mode C until No Yes

W=2 Acknowledgement
terminated
Yes Protocol
error ?
No
Yes Data
DATA READOUT
error ?
No
No
Y=2?
Yes
No
Supported ?
Yes
No
V=2?
Yes
HDLC mode
Switchover to HDLC until terminated HDLC Acknowledgement
Figure 15 – Flow chart and switchover to METERING HDLC in protocol mode E
6.2 Key to protocol mode E flow diagram

Message formats
REQUEST /? Device Address ! CR LF

IDENTIFICATION / XXX Z Ident CR LF
Acknowledgement ACK 2 Z 2 CR LF
DATA READOUT (fall back data readout mode A ) STX DATA ! CR LF ETX BCC
NOTE The inactivity time-out period for the tariff device is 60 s to 120 s after which the operation moves from any point
to the start.

6.3 Physical layer - Introduction

The framework is equivalent to "Physical layer services and procedures for connection-oriented
asynchronous data exchange" (see Clause 4.1).
DTE (Client) DTE (Server)

PH-Layer PH-Layer
set mode to 300 baud, 7,E,1
PH-CONNECT.request
Send “/ ? Device Address ! CR LF”
Send “/ X X X Z \ 2 Ident CR LF”
Send “ACK 2 Z 2 CR LF”
change mode to Z baud, 7,E,1
Send “ACK 2 Z 2 CR LF”

PH-CONNECT.confirm PH-CONNECT.indication
change mode to Z baud, 8,N,1

PH-DATA.request
Send Data Frame
PH-DATA.indication
PH-DATA.request
Send Data Frame
PH-DATA.indication
PH-ABORT.request
Send Break Signal l
PH-ABORT.confirm PH-ABORT.indication
Figure 16 – Physical layer primitives
DTE (Client) DTE (Server)

PH-Layer PH-Layer
set mode to 300 baud, 7,E,1
PH-CONNECT.request
Send “/ ? Device Address ! CR LF”
Send “/ X X X 5 \ 2 Ident CR LF”
Send “ACK 2 5 2 CR LF”
change mode to 9600 baud, 8,N,1
PH-CONNECT.confirm Send 06H B2H 35H B2H 8DH 0AH

PH-CONNECT.indication
PH-DATA.request
Send Data Frame
PH-DATA.indication
PH-DATA.request
Send Data Frame
PH-DATA.indication
PH-ABORT.request
Send Break Signal l
PH-ABORT.confirm PH-ABORT.indication
Figure 17 – Physical layer primitives, simplified example with one mode change only

7. COSEM transport layers for IPv4 networks
7.1 Scope
This chapter specifies the transport layers for COSEM communication profiles for use on IPv4
networks.
These communication profiles contain a connection-less and a connection-oriented transport layer,

providing OSI-style services to the service user COSEM application layer. The connection-less
transport layer is based on the Internet standard User Datagram Protocol. The connection-oriented
transport layer is based on the Internet standard Transmission Control Protocol.
Although the major part of the COSEM transport layers is the UDP and TCP as they are specified
in the relevant Internet standards, they include an additional sub-layer, called wrapper.
Clause 7.5 shows how the OSI-style transport layer services can be converted to and from UDP
and TCP function calls.
7.2 Overview
This International Standard specifies two transport layers for the COSEM_on_IP communication
profiles: a connection-less transport layer, based on UDP, Internet standard STD0006 and a
connection-oriented transport layer, based on TCP, Internet standard STD0007.
In these profiles, the COSEM application layer uses the services of one of these transport layers,
which use then the services of the Internet Protocol (IPv4) network layer to communicate with other
nodes connected to the abstract IPv4 network.
When used in these profiles, the COSEM application layer can be considered as another Internet
standard application protocol (like the well-known HTTP, FTP or SNMP) and it may co-exist with
other Internet application protocols, as it is shown in Figure 18.

Application / Data models

WEB COSEM
Files
pages interface model
Standard application protocols

COSEM AL
e.g. FTP e.g. HTTP
... ACSE + xDLMS
Wrapper
Internet Transport Layer (UDP & TCP)
Internet Network layer (IPv4)
Data Link Layer
Physical Layer
Figure 18 – COSEM as a standard Internet application protocol
As the COSEM application layer specified in Clause 0 uses and provides OSI-style services, a
wrapper has been introduced between the UDP/TCP layers and the COSEM application layer.
Therefore, the COSEM transport layers consist of a wrapper sub-layer and the UDP or TCP
transport layer.
The wrapper sub-layer is a lightweight, nearly state-less entity: its main function is to adapt the
OSI-style service set, provided by the COSEM transport layer, to UDP or TCP function calls and
vice versa.
In addition, the wrapper sub-layer has the following functions:
- it provides an additional addressing capability (wPort) on top of the UDP/TCP port;

- it provides information about the length of the data transported. This feature helps the sender to send
and the receiver to recognize the reception of a complete APDU, which may be sent and received in
multiple TCP packets.
The COSEM application layer is listening only on one UDP or TCP port. On the other hand, as
defined in DLMS UA 1000-1, Clause 4.1.5, a COSEM physical device may host several client
application processes or server logical devices. The additional addressing capability provided by
the wrapper sub-layer allows identifying these application processes.
The structure of the COSEM transport layer and their place in COSEM-on_IP is shown in Figure 19.

COSEM Application Process TCP Connection COSEM Application Process

Manager
COSEM application COSEM application
TCP-DISCONNECT services
layer services layer services
TCP-CONNECT services
COSEM Application Layer COSEM Application Layer
COSEM connectionless TCP- COSEM

transport services ABORT.ind connection-oriented
UDP-DATA.req/.ind/(.cnf) transport services
TCP-DATA.req/.ind/(.cnf)
COSEM UDP-based Transport Layer COSEM TCP-based Transport Layer
COSEM Wrapper COSEM Wrapper

TCP function calls
UDP function calls
active/passive OPEN,
SEND, RECEIVE
SEND, RECEIVE
Internet UDP Internet TCP
IP and lower layers IP and lower layers
a) the UDP-based profile b) the TCP-based profile
Figure 19 – Transport layers of the COSEM_on_IP profile
The service user of the both the UDP-DATA and the TCP-DATA services is the COSEM application
layer. On the other hand, the service user of the TCP-CONNECT and TCP-DISCONNECT services
is the TCP Connection Manager Process. The COSEM TCP-based Transport layer also provides a
TCP-ABORT.indication service to the service user COSEM application layer.
7.3 The COSEM connection-less, UDP-based Transport layer
7.3.1 General
The COSEM connection-less transport layer is based on the User Datagram Protocol (UDP) as
specified in STD0006.
UDP provides a procedure for application programs to send messages to other programs with a
minimum of protocol mechanism. On the one hand, the protocol is transaction oriented, and
delivery and duplicate protection are not guaranteed. On the other hand, UDP is simple, it adds a
minimum of overhead, it is efficient and easy to use. Several well-known Internet applications, like
SNMP, DHCP, TFTP, etc. take advantage of these performance benefits, either because of some
datagram applications do not need to be reliable or because the required reliability mechanism is
ensured by the application itself. Request/response type applications, like a confirmed COSEM
application association established on the COSEM UDP-based Transport layer, then invoking
confirmed COSEM data communication services is a good example for this second category.
Another advantage of UDP is that being connection-less, it is easily capable of multi- and
broadcasting.
UDP basically provides an upper interface to the IP layer, with an additional identification
capability, the UDP port number. This allows distinguishing between application processes, hosted
in the same physical device and identified by its IPv4 address.
As already mentioned in Clause 7.2, the COSEM application layer is listening only on one UDP
port. On the other hand, as defined in DLMS UA 1000-1, Clause 4.1.5, a COSEM physical device
may host several client application processes or server logical devices. The additional addressing

capability provided by the wrapper sub-layer, using the wrapper port (wPort) numbers on top of the
UDP/TCP port numbers allows identifying these application processes.
The wrapper also adds length information to the APDU to be transported.
7.4 The COSEM connection-oriented, TCP-based Transport

layer
7.4.1 General
The COSEM connection-oriented transport layer is based on the connection-oriented Internet
transport protocol, called Transmission Control Protocol or TCP.
TCP is an end-to-end reliable protocol. This reliability is ensured by a conceptual “virtual circuit”,
using a method called “Positive Acknowledgement with Retransmission” or PAR. It provides
acknowledged data delivery, error detection, data re-transmission after an acknowledgement time-
out, etc., therefore is dealing with lost, delayed, duplicated or erroneous data packets. In addition,
TCP offers an efficient flow control mechanism and full-duplex operation, too.
TCP, as a connection-oriented transfer protocol involves three phases: connection establishment,

data exchange and connection release. Consequently, the COSEM TCP-based Transport layer
provides OSI-style services to the service user(s) for all three phases:
- for the connection establishment phase, TCP-CONNECT services are provided to the service user TCP
connection manager process;
- for the data communication phase, TCP-DATA services are provided to the service user COSEM
application layer;
- for the connection closing phase, TCP-DISCONNECT services are provided to the service user TCP
connection manager process;
- in addition, a TCP-ABORT.indication service is provided to the service user COSEM application layer.
The COSEM connection-oriented, TCP-based Transport layer contains the same wrapper sub-layer
as the COSEM UDP-based Transport layer. In addition to transforming OSI-style services to and
from TCP function calls, this wrapper provides additional addressing and length information.
The COSEM connection-oriented, TCP-based Transport layer is specified in terms of services and
protocols.
The conversion between OSI-style services and TCP function calls is presented in Clause 7.5.

7.5 Converting OSI-style transport layer services to and from

RFC-style TCP function calls
7.5.1 Transport layer and TCP connection establishment

As specified in STD0007, a TCP connection is established by calling the OPEN function. This
function can be called in active or passive manner.
According to the TCP connection state diagram (Figure 20) a passive OPEN takes the caller device
to the LISTEN state, waiting for a connection request from any remote TCP and port.
anything / reset
begin
CLOSED
ac
passive OPEN
tiv
e
O
CLOSE
PE
N
k
+ ac
/s
/ syn LISTEN
yn
syn SEN
D/s
reset yn
SYN syn / ack SYN CLOSE /

RECVD SENT timeout /
k
/ ac reset
ck
ack +a
syn
ESTAB- fin / ack
CLOSE
LISHED WAIT
CLOSE/ fin
n
/ fi
SE CLOSE/ fin
C LO
fin / ack ack /

FIN LAST
CLOSING
WAIT-1 ACK
fin-
ack
ack / / ac ack /
k timeout after 2 segment lifetimes
FIN fin / ack TIME

WAIT-2 WAIT
Figure 20 – TCP connection state diagram
An active OPEN call shall make the TCP to establish the connection to a remote TCP.
The establishment of a TCP Connection is performed by using the so-called “Three-way

handshake” procedure. This is initiated by one TCP calling an active OPEN and responded by
another TCP, the one, which has already been called a passive OPEN and consequently is in the
LISTEN state.
The message sequence – and the state transitions corresponding to that message exchange – for
this “three-way handshake” procedure are shown in Figure 21.

anything / reset
TCP User TCP User
Protocol Layer TCP Layer Protocol Layer begin
CLOSED
ac
passive OPEN c
tiv
e
O
CLOSE
PE
N
a ck
/s
/s yn + LISTEN
yn
syn SEN
D/s c
d reset yn

active OPEN RECVD SENT timeout /
k
/ ac reset
ack + ack
syn d
e fin / ack
ESTAB- CLOSE
LISHED WAIT
CLOSE/ fin
n
/ fi
E CLOSE/ fin
OS
CL
fin / ack ack /

FIN LAST
CLOSING
WAIT-1 ACK
fin-
ack
ack / / ac ack /
k timeout after 2 segment lifetimes
FIN fin / ack TIME

WAIT-2 WAIT
TCP Connection is established
NOTE In the case of the COSEM transport layer, the TCP user protocol layer is the wrapper sub-layer.
Figure 21 – MSC and state transitions for establishing a transport layer and TCP connection
This process, consisting of three messages, establishes the TCP connection and “synchronizes”
the initial the sequence numbers 5 at both sides. This mechanism has been carefully designed to
guarantee, that both sides are ready to transmit data and know that the other side is ready to
transmit as well. Note, that the procedure also works if two TCPs simultaneously initiate the
procedure.
7.5.2 Closing a transport layer and a TCP connection

Closing a TCP connection is done by calling the CLOSE function, generally when there is no more
data to be sent.
Upon the invocation of the TCP-DISCONNECT.request service primitive by the TCP connection
manager process, the wrapper sub-layer invokes the CLOSE function of the TCP sub-layer.
However, as the TCP connection is full duplex, the other side may still have data to send.
Therefore, after calling the CLOSE function, the TCP-based Transport later may continue to
receive data and send it to the COSEM application layer, until it is told that the other side has
CLOSED, too. At this point it, shall invoke the COSEM-ABORT.indication service, and all
application associations shall be released.
The message sequence chart and the state transitions corresponding to a successful TCP
connection release are shown in Figure 22.
5
Sequence numbers are part of the TCP packet, and are fundamental to reliable data transfer. For more details about
sequence numbers ( or other TCP related issues ), please refer to STD0007.

TCP User TCP User

Protocol Layer TCP Layer TCP Layer Protocol Layer
TCP is in anything / reset

TCP is in
ESTABLISHED ESTABLISHED
state state begin
CLOSED
CLOSE 1
ac
fin passive OPEN
tiv
e
O
CLOSE
PE
TCP is in
1 signal receivedfin
N
k
FIN WAIT-1 + ac
/s
/ syn LISTEN
yn
state syn SEN
D
reset / syn
2 ack
TCP is in TCP is in RECVD SENT timeout /
CLOSE WAIT ack reset
FIN WAIT-2
ac k/
state state ack +
syn
CLOSE fin / ack
fin
2 ESTAB- CLOSE
LISHED
CLOSE/ fin
c WAIT
n
3 TCP is in / fi
LAST ACK OS
E
CLOSE/ fin d
state CL c
ack
fin / ack ack /
3 FIN
CLOSING
LAST
TCP is in WAIT-1 ACK e
TIME WAIT TCP is in f in -
ack
state CLOSED ack / d / ac ack /
timeout after 2 segment lifetimes
4 state k
TCP is in fin / ack
CLOSED FIN TIME
state WAIT-2 WAIT
e f
No TCP Connection is established
NOTE In the case of the COSEM transport layer, the TCP user protocol layer is the wrapper sub-layer.
Figure 22 – MSC and state transitions for closing a transport layer and TCP connection
7.5.3 TCP connection abort

STD0007 does not specify a standard function to indicate an unexpected abort at TCP level.
However, it can be detected by the TCP user entity by polling the status of the TCP with the
STATUS() function, as shown in Figure 23.
COSEM Wrapper TCP

Application sub-layer sub-layer
Layer
S = status( )
Connected
TCP connection is shut down
S = status( )
TCP-ABORT.ind Disconnected
Figure 23 – Polling the TCP sub-layer for TCP abort indication
7.5.4 Data communication – the TCP-DATA service

To send an APDU to the peer, the COSEM application layer shall simply invoke the TCP-
DATA.request service of the COSEM TCP-based Transport layer. Also, when a complete APDU is
received, this shall be indicated to the COSEM application layer with the help of the TCP-

DATA.indication service. Thus, for the application layer the transport layer behaves as if it would
transport the whole APDU in one piece.
However, nothing ensures that an APDU is actually transmitted in one TCP packet. The reason for
that is that TCP is a streaming protocol – in other words, TCP does not preserve data boundaries.
In the COSEM TCP-based Transport layer it is the responsibility of the wrapper sub-layer to “hide”
the streaming nature of the TCP sub-layer. The following example illustrates how the wrapper sub-
layer accomplishes this task.
Let’s suppose, that an application layer 6 entity wants to send an APDU containing 994 bytes via
the COSEM TCP-based Transport layer. It shall invoke the TCP-DATA.request service, with this
APDU as the DATA, service parameter as it is shown in Figure 24.
COSEM Wrapper TCP Peer TCP

Application sub-layer sub-layer sub-layer
Layer
TCP-Data.req( Data )
N = send( WH+Data, 1000 )
DataLength = 992
N = 476
N = send( rem_Data, 524 ) )
N = 302
N = send( rem_Data, 222 )
N = 222
TCP-DATA.cnf
Figure 24 – Sending an APDU in three TCP packets
Upon the reception of this service invocation, the wrapper sub-layer shall construct the WPDU: it
shall pre-fix to the APDU the wrapper header (WH), including the local and remote wPort numbers
and the APDU length. It shall then call the SEND() function of the TCP sub-layer, requesting to
send the WPDU, which is now 1000 bytes long: 8 bytes of wrapper header plus 992 bytes of APDU.
The SEND() function returns with the number of bytes sent or an error (a negative value). Let’s
suppose, that no error occurs, and the SEND() function successfully returns – with the value 476.
The number 476 means the number of bytes sent – and also illustrates the meaning of the
“streaming” nature of the TCP: in fact, the SEND() function returns with success even if the number
of bytes sent is less than the number of bytes requested to be sent.
From the value returned, the wrapper knows, that not the whole WPDU has been sent, and it shall
call the SEND() function again, with the remaining part of the WPDU – and so on, until the
complete WPDU is sent.
Depending on the implementation, the successful return of the SEND() function may even not mean
that something has been really sent to the network. It may mean only that the protocol
implementation took and buffered the data. It may happen that the protocol implementation delays
the transmission to comply with protocol conventions or network traffic related algorithms.
6
Both the client- and server side application layers can be either sender or receiver.

On the receiving side, it is also the responsibility of the wrapper sub-layer to assemble the
complete APDU before invoking the TCP-DATA.indication service. This is possible by using the
length bytes of the WPDU header. The wrapper shall repeat RECEIVE() calls until the number of
bytes, indicated in the WPDU header is received. This is shown in Figure 25.
TCP Wrapper COSEM

Peer TCP Application
sub-layer sub-layer sub-layer
Layer
N = send( WH + Data, 1000 )
N = 476 N = recv( 6, &buff )
N=6
N = recv( 994, &buff )
N = 470
N = send( rem_Data, 524 )
T1
N = 302 N = recv( 524, &buff )
N = send( rem_Data, 222 ) N = 302
N = 222 N = recv( 222, &buff )
N = 222
TCP-Data.ind( Data )
NOTES:
1. As calling the RECEIVE() function is asynchronous with regard to the TCP communications, it is perfectly
possible, that the receiver calls the RECEIVE() function at a moment, when the reception of a TCP packet is in
progress ( T1. on the Figure above) – or even if when no characters have been received since the last
RECEIVE() call. It does not lead to erroneous reception: it increases only the number of necessary RECEIVE()
function calls to get the complete message.
2. It is also possible that one or more SEND() calls result in sending more than one TCP packets. It does not lead
to erroneous reception either: sooner or later the receiver gets the whole message.
Figure 25 – Receiving the message in several packets
All these SEND() and RECEIVE() calls are internal to the COSEM transport layer. The service user
COSEM application layer simply uses the TCP-DATA services, and observes a reliable data
transfer service preserving the data boundaries of the APDUs.

8. Data Link Layer using HDLC-Protocol
8.1 Overview
This chapter specifies the data link layer for connection-oriented, HDLC-based, asynchronous
communication profile.
In order to ensure a coherent data link layer service specification for both connection-oriented and
connectionless operation modes, the data link layer is divided into two sub-layers: the Logical Link
Control (LLC) sub-layer and the Medium Access Control (MAC) sub-layer.
This specification supports the following communication environments:
- point-to-point and point-to-multipoint configurations;

- dedicated and switched data transmission facilities;
- half-duplex and full-duplex connections;
- asynchronous start/stop transmission, with 1 start bit, 8 data bits, no parity, 1 stop bit.
Two special procedures are also defined:
- transferring of separately received Service User layer PDU parts from the server to the client in a
transparent manner. The server side Service user layer can give its PDU to the data link layer in
fragments and the data link layer can hide this fragmentation from the client;
- event reporting, by sending UI frames from the secondary station to the primary station.
Clause 0 gives an explanation of the role of data models and protocols in electricity meter data
exchange.
8.2 Overview of the data link layer specification
8.2.1 The LLC sub-layer

In the connection-oriented profile the only role of the LLC sub-layer is to ensure consistent Data
Link addressing. It can be considered that the LLC sub-layer, defined in ISO/IEC 8802-2:1998 is
used in an extended class I operation, where the LLC sub-layer provides the standard
connectionless data services via a connection-oriented MAC sub-layer.
The LLC sub-layer provides Data Link (DL) connection/disconnection services to the Service User
layer, but it uses the services of the MAC sub-layer to execute these services.
The LLC sub-layer is specified in Clause 8.3.
8.2.2 The MAC sub-layer

The MAC sub-layer - the major part of this data link layer specification - is based on ISO/IEC 13239
concerning high-level data link control (HDLC) procedures.
This standard includes a number of enhancements compared to the original HDLC, for example in
the areas of addressing, error protection and segmentation. These enhancements have been

incorporated in a new frame format, which meets the requirements of the environment found in
telemetry applications for electricity metering and similar industries.
8.2.3 Specification method

Sub-layers of the data link layer are specified in terms of services and protocol.
Service specifications cover the services required of, or by, the given sub-layer at the logical
interfaces with the neighbouring other sub-layer or layer, using connection-oriented procedures.
Services are the standard way to specify communications between protocol layers. Through the
use of four types of transactions, commonly known as service primitives (Request, Indication,
Response and Confirm) the service provider co-ordinates and manages the communication
between the users. Using service primitives is an abstract, implementation-independent way to
specify the transactions between protocol layers. Given this abstract nature of the primitives, their
use makes good sense for the following reasons:
- they permit a common convention to be used between layers, without regard to specific operating
systems and specific languages;
- they give the implementers a choice of how to implement the service primitives on a specific machine.
Service primitives include service parameters. There are three classes of service parameters:
- parameters transmitted to the peer layer, becoming part of the transmitted frame, for example
addresses, control information;
- parameters, which have only local significance;
- parameters, which are transmitted transparently across the data link layer to the user of the data link.
This document specifies values for parameters of the first category only.
The protocol specification for a protocol layer includes:
- the specification of the procedures for the transmission of the set of messages exchanged between
peer-layers;
- the procedures for the correct interpretation of protocol control information;
- the layer behaviour.
The protocol specification for a protocol layer does not include:
- the structure and the meaning of the information which is transmitted by means of the layer (Information
field, User data subfield);
- the identity of the Service User layer;
- the manner in which the Service User layer operation is accomplished as a result of exchanging Data
Link messages;
- the interactions that are the result of using the protocol layer.
8.3 The LLC sub-layer
8.3.1 The role of the LLC sub-layer

The LLC sub-layer used in this profile is based on ISO/IEC 8802-2. The presence of this sub-layer
in the connection-oriented profile is somewhat artificial: the LLC sub-layer is used as a kind of
protocol selector, and the ‘real’ data link layer connection is ensured by the MAC sub-layer. It can
be considered that the standard LLC sub-layer is used in an extended class I operation, where the
LLC sub-layer provides the standard data-link-connectionless services via a connection-oriented
MAC sub-layer. In order to be able to establish the data link connection, the LLC sub-layer
provides transparent MAC connection/disconnection services to the service user protocol layer.

8.3.2 Service specification for the LLC sub-layer

This subclause specifies the services required of, or by, the LLC sub-layer at the logical interfaces
with the Service User layer and the MAC sub-layer, using connection-oriented procedures. As the
Service User layer ‘sees’ the services of the LLC sub-layer as the services of the data link layer, in
this document these services are called data link layer services and the prefix “DL” to designate
these services is used.
8.3.2.1 Setting up the data link connection

8.3.2.1.1 Overview
Figure 26 shows the services provided by the primary station (client side) and secondary station
(server side) data link layers to the service user layer for data link connection establishment.
Primary station / Client side Secondary station / Server side
Service user layer
DL-CONNECT.res
DL-CONNECT.cnf
DL-CONNECT.req
DL-CONNECT.ind
Data link layer
LLC sub-layer
MAC sub-layer
Physical layer
Figure 26 – Data link (LLC) services for setting up the data link connection
Data link connection establishment can only be requested by the primary station, so the DL-
CONNECT.request and .confirm services are provided only at the client (primary station) side. On
the other hand, the DL-CONNECT.indication and .response services are provided only at the
server (secondary station) side.
The DL-CONNECT.request service primitive – in case of a locally detected error – can be also
locally confirmed.
All these services are in fact, provided by the MAC sub-layer: the LLC sub-layer shall transparently
transmit these services to/from the “real” service provider MAC sub-layer as the appropriate MA-
CONNECT.xxx service primitive.

8.4 The MAC sub-layer

The MAC sub-layer is based on ISO/IEC 13239.
The MAC sub-layer – similarly to the LLC sub-layer – is specified in terms of services and
protocols. As the MAC sub-layer behaviour is quite complex, some aspects of the service
invocation handling are discussed in the service specification part, although these are normally
part of the protocol specification.
8.4.1 HDLC selections

For the purpose of this document, the following selections from the HDLC standard ISO/IEC 13239
have been made:
- unbalanced connection-mode data link operation 7;

- two-way alternate data transfer;
- the selected HDLC class of procedure is UNC, extended with UI frames;
- frame format type 3;
- non-basic frame format transparency.
In the unbalanced connection-mode data link operation, two or more stations are involved. The
primary station assumes responsibility for the organization of data flow and for unrecoverable data
link level error conditions by sending command and supervisory frames. The secondary station(s)
respond by sending response frames.
The basic repertoire of commands and responses of the UNC class of procedures is extended with
the UI frame to support multicasting and broadcasting and non-solicited information transfer from
server to the client.
Using the unbalanced connection-mode data link operation implies that the client and server side
data link layers are different in terms of the sets of HDLC frames and their state machines.
8.4.2 Service specification for the MAC sub-layer

This subclause specifies the services required of, or by, the MAC sub-layer at the logical interfaces
with the service user and the Physical (PH) layers, using connection-oriented procedures. As the
client and the server side MAC sub-layers are different, services are specified for both sides.
8.4.2.1 Setting up the MAC connection

8.4.2.1.1 Overview
Figure 27 shows the services provided by the client and server side MAC sub-layers to the service
user layer for MAC connection establishment.
7
In COSEM environment, the choice of an unbalanced mode of operation is natural: it is the consequence of the fact that
communication in this environment is based on the Client/Server paradigm.


Physical Connection
Layer Management Process Application Process
Manager Process
ASO Services
AL Mgmt. Services
Application Layer
Physical Connect/Disconnect
Connect/Disconnect/
Data related services
DL-INITIALIZE.req/.conf
DL-GET_VALUE.req/.conf
DL-SET_VALUE.req/.conf Data Link Layer
DL-LM_Event.ind
PH-DATA.req/.ind
PH Layer Mgmt. PH-ABORT.ing
Services
Physical Layer
Figure 28 – Layer management services

9. COSEM application layer
9.1 Overview
9.1.1 Specification method

The COSEM application layer is specified in terms of structure, services, and protocols.
9.1.2 Application layer structure

The main component of the client and server COSEM application layers is the COSEM ASO, which
provides services to the COSEM AP, and uses services provided by the supporting lower layer.
Both the client and server side COSEM ASO contains three mandatory components:
- The ACSE. The task of this element is to establish, maintain, and release application associations. For
the purposes of connection-oriented profiles, the connection-oriented ACSE, specified in ISO/IEC 8649
and ISO/IEC 8650-1 is used.
- The Extended DLMS application service element (xDLMS_ASE). The task of this element is to
provide data communication services between COSEM APs.
- The Control function (CF). This element specifies how the ASO services invoke the appropriate service
primitives of the ACSE and the xDLMS ASE and the services of the supporting layer.
NOTE Both the client and the server COSEM ASO may contain other, optional application protocol components.
Figure 29 shows ‘minimal’ COSEM ASOs, containing only the three mandatory components .
(interface objects)
Applications

application process application process
COSEM client ASO services Referencing by
COSEM server ASO services Logical Name
Referencing by Logical Name
COSEM client application layer COSEM server application layer

COSEM client ASO COSEM server ASO
Client control function Server control function

(communications)
Protocol
Client Client Server Server

xDLMS_ASE xDLMS_ASE ACSE
ACSE
Supporting layer services Supporting layer services
Supporting layer Supporting layer

and and
other protocol layers other protocol layers
WAN, LAN
Figure 29 – The structure of the COSEM application layers
The COSEM application layer performs also some functions of the OSI presentation layer:

- for encoding the AARQ and AARE APDUs, BER encoding is used (ISO/IEC 8825);
- for encoding the APDUs carrying the data communication services, A-XDR encoding is used (IEC
61334-6).
9.1.3 Service specification

Service specifications cover the services required of, or by the COSEM client and server APs at the
logical interfaces with the respective COSEM application layer, using connection-oriented
procedures.
Services provided by the COSEM ASO fall into three categories:
- application association establishment and release;

- data communication;
- layer management.
The client and server application layer services are specified in Clause 9.2.
9.1.3.1 Services provided for application association establishment and release

These services are the following:
- COSEM-OPEN;
- COSEM-RELEASE;
- COSEM-ABORT.
The COSEM-OPEN service is used during AA establishment phase and relies on the association
request/response services of the ACSE. In the case of pre-established application associations
(9.2.3.3) these services are not used.
In certain COSEM communication profiles – for example in the 3-layer, connection-oriented, HDLC-
based profile – there is a one-to-one relationship between a confirmed AA and the supporting
protocol layer connection. In this case, the COSEM-RELEASE service used during the association
release phase does not rely on the ACSE A_RELEASE services. Confirmed AAs in these profiles
are released simply by disconnecting the corresponding lower layer connection.
Optionally, the COSEM-RELEASE service may rely on the ACSE A_RELEASE service. In some
communication profiles, like in the TCP-UDP/IP based profile, using the ACSE A_RELEASE
services for releasing COSEM AAs is mandatory.
9.1.3.2 Data communication services

DLMS UA 1000-1, Clause 4 specifies two referencing methods for COSEM servers: referencing by
Logical Names (LN) and referencing by Short Names (SN). Therefore, two distinct service sets are
specified for the server side xDLMS_ASE. One set uses exclusively LN references the other set
uses exclusively SN references. Thus, these services are the following:
- COSEM interface object attribute-related services: GET, SET for LN referencing and Read, Write,
Unconfirmed Write for SN referencing;
- COSEM interface object method-related services: ACTION (LN), Read, Write or UnconfirmedWrite (SN);
- the EventNotification (LN), InformationReport (SN) services.
The services rely on the services of the xDLMS_ASE. Most of these services contain references to
attributes or methods of COSEM interface objects.
The service set to be used on the server side during the data communications phase is negotiated
during the association establishment phase using the conformance block. It shall not change during
the lifetime of the established association. Using LN or SN services within a given AA is exclusive.
Therefore, it can be considered that there are two, different server xDLMS_ASE-s: one providing

services with Logical name references and another providing services with Short name references.
The server application layer shall include one or both of these xDLMS_ASEs.
NOTE A server could use both LN and SN referencing in different AAs.
On the client side, in order to handle the different referencing schemes transparently for the
COSEM client AP, the COSEM client application layer provides only one service set, using Logical
Name referencing. This has two major consequences:
- Using a unique, standardized service set between COSEM client applications and the communications
protocol – hiding the particularities of different COSEM servers – allows to specify an Application
Programming Interface (API). This is an explicitly specified interface corresponding to this service set for
applications running in a given computing environment (for example Windows XP, UNIX, etc.) Using this
– public – API specification, client applications can be developed without knowledge about particularities
of a given server.
- When the COSEM server device does not use LN referencing, the client application layer shall include
an additional component. The purpose of this component is to map the LN service set, used by the client
AP into/from the service set, used by the server AP. Figure 30 shows the COSEM client application layer
when the server is using SN referencing. The additional component is called SN_MAPPER_ASE. See
also.
(interface objects)
Applications

application process application process
COSEM client ASO services Referencing by
COSEM server ASO services
Referencing by Logical Name Short Name
COSEM client application layer COSEM server application layer

COSEM client ASO COSEM server ASO
Client control function
Server control function
(communications)
Client
xDLMS_ASE
Protocol
Client Server Server

Client ACSE xDLMS_ASE ACSE
SN_MAPPER
Supporting layer services Supporting layer services
Supporting layer Supporting layer

and and
other protocol layers other protocol layers
WAN, LAN
Figure 30 – Structure of the COSEM AL when the server is using SN references
9.1.4 Layer management services

Layer management services have local importance only. Therefore, specification of these services
is not within the scope of this document.

9.1.5 Protocol specification

The COSEM application layer protocols specify the procedures for the transfer of information for
application association control, authentication (ACSE procedures) and for data exchange between
COSEM clients and servers (xDLMS procedures). These procedures are defined in terms of:
- the interactions between peer ACSE and xDLMS protocol machines through the use of services of the
supporting protocol layer;
- the interactions between the ACSE and xDLMS protocol machines and their service user;
- the abstract syntax (ASN.1, ISO/IEC 8824) representation of Application Protocol Data Units (APDUs) is
also specified with the application protocols.
NOTE All COSEM services are operating on an already established physical connection. Establishment of this physical
connection is done outside of the COSEM protocol therefore it is not within the scope of this document.
9.2 COSEM application layer – Service specification
9.2.1 Summary of services

A summary of the services available at the top of the COSEM application layer is shown in Figure
31.

9.2.2 Application association establishment and release

The COSEM-OPEN, COSEM-RELEASE and COSEM-ABORT services are used for the
establishment and release of AAs.
The COSEM-OPEN.request service is invoked by the COSEM client AP to establish a confirmed or

non-confirmed AA with a COSEM server AP. Invoking this service implies generating a COSEM-
OPEN.indication service primitive at the server side 8. If the association to be established is a
confirmed one, the server shall respond to this request by invoking the COSEM-OPEN.response
service, which is transferred to the client AP as a remote confirmation (COSEM-OPEN.confirm).
This normal opening sequence is shown in Figure 32.
Client Server
application layer application layer
COSEM- COSEM-
OPEN.request OPEN.indication
COSEM-
OPEN.confirm COSEM-
OPEN.response
time
Figure 32 – Normal service sequence for the COSEM-OPEN service

NOTE The COSEM-OPEN.request service may also be locally (negatively) confirmed, for example when the connection
of a lower layer is not successful.
The COSEM-RELEASE service is provided for graceful disconnection of an existing application

association. As COSEM server application processes are not allowed to request a graceful
disconnection, the COSEM-RELEASE.request service is available only for the COSEM client. The
nominal service sequence for the COSEM-RELEASE service is the same as is shown in Figure 32
for the COSEM-OPEN service, replacing the word ‘OPEN’ with the word ‘RELEASE’.
The ABORT service is used to indicate the disconnection of the physical connection. This service is
the same at both sides.
9.2.3 Special application associations

9.2.3.1 Confirmed application associations
For the purposes of this document, the term confirmed application association is used to designate
an AA, which is established between a client and a server AP with the help of an AARQ / AARE
message exchange (see at 9.3.3.1). Establishment of a confirmed AA is always initiated by the
client application in invoking the COSEM-OPEN.request service with Service_Class == Confirmed.
After the establishment of a confirmed AA, any xDLMS data communication services using LN
referencing can be invoked in a confirmed or unconfirmed manner, until the association is released.
NOTE xDLMS services using SN referencing are either confirmed (Read, Write) or Unconfirmed (Unconfirmed Write).
9.2.3.2 Non-confirmed application associations

For the purposes of this document, the term non-confirmed application association is used to
designate an AA, which is established without an AARQ / AARE message exchange: only an AARQ
shall be sent from the client to the server. Similarly to the confirmed AA, establishment of a non-
8
Before the invocation of the COSEM-OPEN.request service, the physical layers must be connected. Depending on the communication
profile, the invocation of the COSEM-OPEN.request service may also imply the connection of the lower layers.

confirmed AA is also always initiated by the Client application, but in invoking the COSEM-
OPEN.request service with Service_Class == Unconfirmed.
After the establishment of a non-confirmed AA, xDLMS data communication services using LN
referencing can only be invoked in unconfirmed manner, until the association is released.
NOTE With SN referencing, in non-confirmed AAs only the UnconfirmedWrite service can be used.
As the establishment of such non-confirmed AAs does not require the Server AP to respond to the
association request coming from the client, in some cases – for example one-way communications
or broadcasting – the establishment of a non-confirmed AA is the only possibility.
9.2.3.3 Pre-established application associations

Pre-established AAs don’t need to be established using the COSEM-OPEN service. It can be
considered, that this COSEM-OPEN has already been done (it does not matter how).
Consequently, pre-established associations can be considered existing from the moment the lower
layers are able to deliver APDUs between the client and the server.
A pre-established AA can be either confirmed or non-confirmed (depending on the way it is pre-

established), but in any case it cannot be released. The purpose of this type of association is to
simplify data exchange with simple devices (for example supporting one-way communication only).
The pre-established AA eliminates the need of connection establishment and release (phases 1
and 3 on Figure 5) and only data communication services are used. These must use
connectionless services of the supporting lower protocol layers 9.
9.2.3.4 Mandatory application associations

The mandatory management logical device in the physical metering device must support an AA
with a public client, with the lowest security level.
In any communication profile, the management logical device and the public client must have a
reserved identifier / address.
9.2.4 Data communication

For data communication purposes, the client application layer provides the following set of
services:
- GET service (.request, .confirm);

- SET service (.request, .confirm);
- ACTION service (.request, .confirm).
All these services refer to attributes or methods of COSEM interface objects via logical names.
Received erroneous confirmed service requests are normally simply discarded at the server side.
However, in that case, COSEM servers may optionally respond with an EXCEPTION-response
APDU, indicating that the previously received service request cannot be correctly processed.
There are also non-client/server type services to support receiving information like alarms from a
COSEM server without first requesting it by the client. These are:
- EventNotification service (.indicate);

- Trigger_EventNotification_Sending (.request).
9
NOTE Pre-established application associations are not possible in profiles, where the supporting lower protocol
layer(s) do not provide connection-less data communication services. As for all application associations, the logical
devices must contain an Association LN /SN interface object for the pre-established associations, too.

In confirmed AAs, the client application layer obtains knowledge about the referencing method
used by the server during the AA establishment phase. In case of a pre-established AA, the client
application layer is expected to know the referencing method used by the server before data
communication services can be used. When the client AP invokes data communication services,
the application layer shall invoke the services and send the APDUs corresponding to the
referencing style used by the server.
When the server is also using LN references, the server side service set is the complementary of
the client side service set (the same service set, but .request services shall be transferred as
.indication services, and the .confirm services are originated as .response services).
When the server is using SN references, the service set is as follows:
- READ service (.indication, .response);

- WRITE service (.indication, .response);
- UNCONFIRMED WRITE service (.indication);
- InformationReport service (.request).
As explained in 9.1.3.2, in order to able to ‘map’ between the different service sets, the client
application layer shall include an additional protocol component, called ‘Client SN_MAPPER’.
The corresponding server application layer shall signal the reception of this (LN or SN referencing)
APDU to the server AP.In most cases, the server AP responds to the received .request service by
invoking the corresponding .response service. Upon the reception of the APDU, corresponding to
that .response invocation, the client application layer shall generate the appropriate logical name
referencing service primitive to the client AP.
9.3 COSEM application layer protocol specification

The COSEM application layer is based on the extended DLMS – xDLMS – and on the connection-
oriented ACSE service elements. Therefore, the protocol of this layer is based on the DLMS and
ACSE protocols, as they are specified in IEC 61334-4-41 and in ISO/IEC 8650-1 respectively.
Both the xDLMS and the application contexts can be negotiated during the AA establishment.
The COSEM application protocol specification includes the specification of the protocol machines
for both the client and server side application layers, and the abstract syntax (ASN.1) for the
representation of APDUs. As the same APDU applies at the client side and at the server side, for
example a .request type APDU, sent by the client is the same as its peer .indication APDU, the
abstract syntax specification is common for both application layer entities.
9.3.1 State definitions for the client side control function

Figure 33 shows the state machine for the client side control function (CF, see Figure 29).

Trigger_EventReport_sending.req
/EventReport.ind
INACTIVE
IDLE
OPEN.req /RELEASE.cnf
/OPEN.cnf(NOK),
/ABORT.ind
/ABORT.ind
ASSOCIATION
ASSOCIATION
RELEASE
PENDING PENDING
/ABORT.ind
/OPEN.cnf(OK) ASSOCIATED RELEASE.req
GET.req /GET.cnf
SET.req /SET.cnf
ACTION.req /ACTION.cnf
/EventReport.ind
NOTE On the state diagrams, the following conventions are used:

− service primitives with no “/” character as first character are “stimulants”: the invocation of these services is the
origin of the given state transition;
− service primitives with an “/” character as first character are “outputs”: the invocation of these services is done on the
state transition path.
Figure 33 – Partial state machine for the client side control function
Definitions of states are as follows:
- INACTIVE – in this state, the client CF (and the application layer) has no activity at all: it neither provides
services to the AP nor uses services of the supporting protocol layer;
- IDLE – this is the state of the CF of the client application layer protocol entity when there is no AA
created, being released or currently established 10. Nevertheless, some data exchange between the
client and server, if the physical channel is already established, is possible in this state.
State transitions between the INACTIVE and IDLE states are controlled outside of the protocol. For
example, it can be considered that the CF, and with it the application layer including it, makes the
state transition from INACTIVE to IDLE state by being instantiated and bound on the top of the
supporting protocol layer. The opposite transition may happen by deleting the given instance of the
CF (application layer).
- ASSOCIATION PENDING – the CF of the application layer entity enters this state when the COSEM
client AP invokes the COSEM-OPEN.request (OPEN.req) service primitive. The CF may exit from this
state either by sending a COSEM-OPEN.confirmation (/OPEN.cnf) service primitive or, in the case of
physical disconnection, by sending a COSEM-ABORT.indication (/ABORT.indication) service primitive to
the AP. Depending on the result of the association request, the client CF shall return to IDLE state
(NOK), or shall enter the ASSOCIATED state;
- ASSOCIATED – the CF shall enter this state when the AA has been successfully established. Data
communication services – GET, SET, ACTION – are provided only in this state. The client CF shall
remain in this state until the AP explicitly requires the release of the association by invoking the COSEM-
RELEASE.request service primitive (RELEASE.req), or a COSEM-ABORT.indication service is invoked;
- ASSOCIATION RELEASE PENDING – the CF of the application layer entity enters this state when the
COSEM client AP invokes the COSEM-RELEASE.request service primitive (RELEASE.req), requesting
10
NOTE that it is the state machine for the application layer: lower layer connections, including the physical connection, are not taken
into account. On the other hand, physical connection establishment is done outside of the protocol.

the release of the established AA. The CF shall remain in this state, waiting for the response to this
request. As the server is not allowed to refuse a release request, after exiting this state, the CF shall
always enter the IDLE state. The exit from this state can be originated either by the reception of a
COSEM-RELEASE.response from the remote server, the local generation of the COSEM-
RELEASE.confirm or by the invocation of a COSEM-ABORT.indication service primitive.
9.3.2 State definitions for the server side control function

Figure 34 shows the state machine for the server side control function, see Figure 29.
INACTIVE EventReport.req
or
InformationReport.req
IDLE
/OPEN.ind RELEASE.res
OPEN.res(NOK),
/ABORT.ind
/ABORT.ind
ASSOCIATION
ASSOCIATION RELEASE
/PENDING PENDING
/ABORT.ind
OPEN.res(OK)
/RELEASE.ind
ASSOCIATED
/GET.ind GET.res /READ.ind READ .res

/SET.ind SET.res /WRITE.ind WRITE .res
/ACTION.ind ACTION.res /UNCONFIRMED WRITE.ind
or
Figure 34 – Partial state machine for the server side control function
Definitions of the states are as follows:
- INACTIVE – in this state, the server CF (and the application layer) has no activity at all: it neither
provides services to the AP nor uses services of the supporting protocol layer;
- IDLE – this is the state of the CF of the server application layer entity when there is no AA created, being
released or currently established. Nevertheless, some data exchange between the client and server, if
the physical channel is already established, is possible in this state;
- ASSOCIATION PENDING – upon the reception of a COSEM-OPEN.request message from a remote
client, the CF of the server application layer protocol entity shall exit the IDLE state. It shall indicate the
reception of this message to the server AP via the COSEM-OPEN.indication service primitive
(/OPEN.indication) and shall enter into ASSOCIATION PENDING state. In this state, the Server CF is
waiting for the response from the AP. If the response is positive – meaning that the AP accepted the
proposed association – the CF shall enter the ASSOCIATED state. If the response is negative – or if a
physical disconnection is detected – the CF shall return to the IDLE state;
- ASSOCIATED – the server CF shall enter this state when the AA has been successfully established.
Data communication services – GET, SET, ACTION or READ, WRITE and UNCONFIRMED WRITE,
depending on the established application context – are provided only in this state. The server CF shall
remain in this state until the remote client explicitly requires the release of the AA by invoking the
COSEM-RELEASE.request service (/RELEASE.ind), or a COSEM-ABORT.indication service is invoked;
- ASSOCIATION RELEASE PENDING – upon the reception of a COSEM-RELEASE.request service
primitive from the remote client AP, the CF of the application layer protocol entity shall indicate it to the
AP (/RELEASE.indication) and shall enter into this state. The CF shall remain in this state, waiting for
the response invocation from the AP. As the server is not allowed to refuse this request, the CF shall

always enter the IDLE state after leaving the ASSOCIATION RELEASE PENDING state. The exit from
this state can be originated also by the invocation of a COSEM-ABORT.indication service primitive.
9.3.3 Protocol for application association establishment/release

9.3.3.1 Establishment of a confirmed application association
Application association establishment with the help of the Association.request/ .indication./
.response/ .confirmation services of the standard ACSE, ISO/IEC 8650-1 , is the key element of
COSEM interoperability. The participants of an AA are the interoperable communications partners:
- a client AP, which is always the originator of an AA request, and

- a server AP 11.
The client AP shall first invoke the COSEM-OPEN.request service of the client COSEM ASO. Upon
the reception of this service invocation, the Control function of the client ASO shall first examine
whether the establishment of a lower layer connection is required for the requested AA or not. In
this case, it shall first establish the required lower layer connection(s).
Figure 35 gives the MSC for the case, when:
- the COSEM-OPEN.request service is requesting for a confirmed AA;

- the connection of the supporting lower layers is required for the establishment of the required AA.
11
In order to be able to provide multicast and broadcast services, in COSEM an AA can also be established between a client
and a group of server application processes.


Client Application supporting supporting Application Server
Application Application Application Application
Application Layer - Protocol Protocol Layer - Application
Layer- Layer- Layer- Layer-
Process Control Layer Layer Control Process
ACSE xDLMS xDLMS ACSE
Function (XX) (XX) Function
Physical connection is established (outside the protocol)
Client Application Layer Server Application

Control Function is in Layer Control Function
IDLE State is in IDLE State
COSEM-OPEN.req
Client Application Layer Control Establishing

Function is in ASSOCIATION the Supporting
PENDING State XX-CONNECT.req Layer
connection
XX-CONNECT.ind
Establishing
Lower Layer XX-CONNECT.res
connections
XX-CONNECT.cnf
The Supporting Layer connection is established

xDLMS-Initiate.req
Build an xDLMS-
Initiate.req PDU
xDLMS-Initiate.req PDU
A-ASSOCIATE.req
Build an AARQ APDU

AARQ-pdu
XX-DATA.request(AARQ)
XX-DATA.indication(AARQ)
AARQ APDU
Extract A-
ASSOCIATE.ind
parameters
A-ASSOCIATE.ind
xDLMS-Initiate.ind PDU
Extract xDLMS-
Initiate.ind
parameters xDLMS-Initiate.ind COSEM-
OPEN.ind
Server Application Layer Control
Function is in ASSOCIATION
PENDING state
xDLMS-Initiate.res COSEM-OPEN.res
Build xDLMS-
Initiate.res PDU
xDLMS-Initiate.res PDU
A-ASSOCIATE.res
Build AARE APDU

AARE APDU
Server Application Layer Control

Function is in ASSOCIATED
state
XX-DATA.ind(AARE)
XX-DATA.req(AARE)
AARE APDU
Set Application Context
A-ASSOCIATE.cnf
xDLMS-Initiate.res PDU
Set DLMS Context

xDLMS-Initiate.cnf
Client Application Layer Control
Function is in ASSOCIATED state
The requested Application Association is successfully established
COSEM-OPEN.cnf(OK)
Figure 35 - MSC for successful application association establishment preceded by a successful lower layer
connection establishment

Once the required lower layer connections are established, the client CF shall assemble an AARQ
APDU with the help of the two application service elements (ACSE and xDLMS) of the client
application layer. This AARQ APDU shall be the first message sent to the server application layer.
The CF of the server application layer shall first give the received AARQ APDU to the ACSE, which
shall extract the ACSE related parameters, then give back the control to the CF. The CF shall send
the contents of the user-information field of the AARQ APDU to the xDLMS-ASE, as a xDLMS-
Initiate.indication DLMS PDU.
The xDLMS-ASE shall retrieve the parameters of the xDLMS-Initiate.indication. It shall then give
back the control to the CF, which shall invoke the COSEM-OPEN.indication service primitive with
the appropriate parameters, extracted from the AARQ APDU 12, to the COSEM server AP. At the
same time, the server Control function shall enter the ‘ASSOCIATION PENDING’ state.
The server AP shall analyze the received COSEM-OPEN.indication primitive, and decide whether it
accepts the proposed AAs or not 13.
Following this verification, and if the proposed AA is confirmed, the COSEM server AP shall invoke
the COSEM-OPEN.response service to indicate the acceptance or non-acceptance of the proposed
association. The CF shall assemble and send the appropriate AARE APDU to the remote peer
client application layer via the supporting lower protocols. If the requested AA is non-confirmed, no
AARE is sent. If the proposed AA has been accepted, the server is able to receive xDLMS data
communication service .request(s) and to send .responses to confirmed service requests within this
AA. In other words, the association has been established, and the server has entered the data
communications phase.
At the client side, the parameters of the received AARE APDU shall be extracted by the help of the
ACSE and the xDLMS-ASE, and shall be sent to the client AP via the COSEM-OPEN.confirm
service primitive. At the same time, the client application layer shall enter the ‘ASSOCIATED’ state.
From this moment, the AA is established within the negotiated application and xDLMS contexts.
12
Some service parameters of this COSEM-OPEN.indication primitive (address information, User_Information) do not come
from the AARQ APDU, but from the supporting layer frame carrying the AARQ APDU. The Service_Class parameter of the COSEM-
OPEN service is linked to the response-allowed field of the xDLMS-Initiate.request APDU.
13
The application service elements only extract the parameters, like the application context, authentication related parameters,
etc. The interpretation of these parameters and the decision whether the association can be accepted or not, is the job of the COSEM
server application process.


DLMS Green Book Architecture 5th PDF

Uploaded by

Copyright:

Available Formats

DLMS Green Book Architecture 5th PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DLMS Green Book Architecture 5th PDF

Uploaded by

Copyright:

Available Formats

EXCERPT FROM

DLMS User Association

Reference number: EXCERPT FROM DLMS UA 1000-2:2005, Fifth Edition

DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 2/55

DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 3/55

DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 4/55

The data model uses generic building

The COSEM specifications follow a three

Figure 1 – The three steps approach of COSEM: Modelling - Messaging - Transporting

DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 5/55

3.1 The COSEM communications framework

3.1.1 Client/server type operation, communication profiles

Figure 2 – Client / server relationship in COSEM

Figure 3 – Exchanging messages via the communication protocol

DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 6/55

Profile 1 Profile 2 Profile M

N layer N layer N layer

Physical layer Physical layer

3.1.2 Connection (association) oriented operation

DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 7/55

Client application Server application

Figure 5 – A complete communications session in the CO environment

In the DLMS/COSEM environment, application association establishment is normally done by using

3.2 Interoperability and interconnectivity in COSEM

Interoperability is an application level notion: a client application is interoperable with a server

DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 8/55

3.3 Ensuring interconnectivity: the protocol identification

It is recommended to support it in all communication profiles using this Physical layer.

DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 9/55

3.4 Referenced documents

DLMS UA 1002 Ed. 1.0:2003 COSEM Glossary of Terms, "White Book"

STD0006 (1980) User Datagram Protocol. Also: RFC0768

DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 10/55

3.5 Terms, definitions and abbreviations

AARE Application Association Response

ACSE Application Control Service Element

APDU Application Layer Protocol Data Unit

ASE Application Service Element

A-XDR Adapted Extended Data Representation

client A station, asking for services. Normally the master station

DCE Data Communication Equipment (communications interface or modem)

DISC Disconnect (a HDLC frame type)

DLMS Device Language Message Specification

DM Disconnected Mode (a HDLC frame type)

DPDU Data Link Protocol Data Unit

DTE Data Terminal Equipment (computers, terminals or printers)

FCS Frame Check Sequence

FDDI Fibre Distributed Data Interface

GMT Greenwich Mean Time

GSM Global System for Mobile communications

HDLC High-level Data Link Control

DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 11/55

HHU Hand Held Unit

HLS High Level Security

I Information (a HDLC frame type)

.ind .indication service primitive

LAN Local Area Network

LLC Logical Link Control (Sub-layer)

LSAP LLC sub-layer Service Access Point