IEC 62056-47:2006

INTERNATIONAL IEC
STANDARD 62056-47
First edition
2006-11
Electricity metering –
Data exchange for meter
reading, tariff and load control –
Part 47:
COSEM transport layers for IPv4 networks
Reference number
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the
60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.
Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,
edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the
base publication incorporating amendment 1 and the base publication incorporating
amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
The on-line catalogue on the IEC web site (www.iec.ch/searchpub) enables you to
search by a variety of criteria including text searches, technical committees
and date of publication. On-line information is also available on recently issued
publications, withdrawn and replaced publications, as well as corrigenda.
• IEC Just Published
This summary of recently issued publications (www.iec.ch/online_news/ justpub)
is also available by email. Please contact the Customer Service Centre (see
below) for further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:

Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
INTERNATIONAL IEC
STANDARD 62056-47
First edition
2006-11
Electricity metering –
Data exchange for meter
reading, tariff and load control –
Part 47:
COSEM transport layers for IPv4 networks
© IEC 2006 ⎯ Copyright - all rights reserved
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
PRICE CODE
Commission Electrotechnique Internationale W
International Electrotechnical Commission
МеждународнаяЭлектротехническаяКомиссия
For price, see current catalogue

– 2 – 62056-47 © IEC:2006(E)
CONTENTS
FOREWORD.3

1 Scope.5
2 Normative references .5
3 Terms, definitions and abbreviations .6
4 Overview .6
5 The COSEM connection-less, UDP-based transport layer.8
5.1 General .8
5.2 Service specification for the COSEM UDP-based transport layer .9
5.3 Protocol specification for the COSEM UDP-based transport layer.12
6 The COSEM connection-oriented, TCP-based transport layer.14
6.1 General .14
6.2 Service specification for the COSEM TCP-based transport layer .15
6.3 Protocol specification for the COSEM TCP-based transport layer .25

Annex A (informative) Converting OSI-style transport layer services to and from RFC-
style TCP function calls .32

Bibliography.38

INDEX .39

Figure 1 – COSEM as a standard Internet application protocol .7
Figure 2 – Transport layers of the COSEM_on_IP profile .8
Figure 3 – Services of the COSEM connection-less, UDP-based transport layer .9
Figure 4 – The wrapper protocol data unit (WPDU) .13
Figure 5 – The COSEM connection-less, UDP-based transport layer PDU (UDP-PDU) .13
Figure 6 – Services of the COSEM connection-oriented, TCP-based transport layer .16
Figure 7 – The TCP packet format .26
Figure 8 – Figure TCP connection establishment .27
Figure 9 – Disconnecting a TCP connection.28
Figure 10 – Data communication using the COSEM TCP-based transport layer .30
Figure 11 – High-level state transition diagram for the wrapper sub-layer .30
Figure A.1 – TCP connection state diagram .32
Figure A.2 – MSC and state transitions for establishing a transport layer and TCP
connection .33
Figure A.3 – MSC and state transitions for closing a transport layer and TCP connection .34
Figure A.4 – Polling the TCP sub-layer for TCP abort indication .35
Figure A.5 – Sending an APDU in three TCP packets .36
Figure A.6 – Receiving the message in several packets.37

Table 1 – Reserved wrapper Port numbers in the UDP-based COSEM profile.14

62056-47 © IEC:2006(E) – 3 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
ELECTRICITY METERING –
DATA EXCHANGE FOR METER READING,
TARIFF AND LOAD CONTROL –
Part 47: COSEM transport layers for IPv4 networks

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The International Electrotechnical Commission (IEC) draws attention to the fact that it is claimed that compliance
with this International Standard may involve the use of a maintenance service concerning the stack of protocols on
which the present standard IEC 62056-47 is based.
The IEC takes no position concerning the evidence, validity and scope of this maintenance service.
The provider of the maintenance service has assured the IEC that he is willing to provide services under
reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the
statement of the provider of the maintenance service is registered with the IEC. Information may be obtained from:
DLMS User Association
Geneva / Switzerland
www.dlms.ch
International Standard IEC 62056-47 has been prepared by IEC technical committee 13:
Equipment for electrical energy measurement and load control.
———————
Device Language Message Specification

– 4 – 62056-47 © IEC:2006(E)
The text of this standard is based on the following documents:
FDIS Report on voting
13/1386/FDIS 13/1397/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in
the data related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A list of all parts of IEC 62056 series, published under the general title Electricity metering –
Data exchange for meter reading, tariff and load control, can be found on the IEC website.
A bilingual version of the publication may be issued at a later date.

62056-47 © IEC:2006(E) – 5 –
ELECTRICITY METERING –
DATA EXCHANGE FOR METER READING,
TARIFF AND LOAD CONTROL –
Part 47: COSEM transport layers for IPv4 networks

1 Scope
This part of IEC 62056 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.
Annex A shows how the OSI-style transport layer services can be converted to and from UDP
and TCP function calls.
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
IEC 60050-300:2001, International Electrotechnical Vocabulary (IEV) – Electrical and
electronic measurements and measuring instruments – Part 311: General terms relating to
measurements − Part 312: General terms relating to electrical measurements − Part 313:
Types of electrical measuring instruments − Part 314: Specific terms according to the type of
instrument.
IEC 62051:1999, Electricity metering – Glossary of terms
IEC 62051-1:2004, Ed.1., Electricity metering – Data exchange for meter reading, tariff and
load control – Glossary of terms – Part 1: Terms related to data exchange with metering
equipment using DLMS/COSEM
IEC 62056-53, Electricity metering – Data exchange for meter reading, tariff and load control
− Part 53: COSEM application layer
IEC 62056-62, Electricity metering – Data exchange for meter reading, tariff and load control
− Part 62: Interface classes
STD0005 – Internet Protocol
Author: J. Postel
Date: September 1981
Also: RFC0791, RFC0792, RFC0919, RFC0922, RFC0950, RFC1112

– 6 – 62056-47 © IEC:2006(E)
STD0006 – User Datagram Protocol
Author: J. Postel
Date: 28 August 1980
Also: RFC0768
STD0007 – Transmission Control Protocol
Author: J. Postel
Date: September 1981
Also: RFC0793
See also Bibliography for other related Internet RFCs.
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the definitions given in IEC 60050-300, IEC 62051 and
IEC 62051-1 apply.
3.2 Abbreviations
APDU  Application Layer Protocol Data Unit
COSEM COmpanion Specification for Energy Metering
COSEM_on_IP The TCP-UDP/IP based COSEM communication profile
IP  Internet Protocol
PDU  Protocol Data Unit
PAR  Positive Acknowledgement with Retransmission
TCP  Transmission Control Protocol
UDP  User Datagram Protocol
WPDU  Wrapper Protocol Data Unit

4 Overview
This 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 shown in
Figure 1.
62056-47 © IEC:2006(E) – 7 –
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 1 – COSEM as a standard Internet application protocol
As the COSEM application layer specified in IEC 62056-53 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.
As specified in IEC 62056-53, B.3.3, the COSEM application layer is listening only on one
UDP or TCP port. On the other hand, as defined in IEC 62056-62, 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 2.
– 8 – 62056-47 © IEC:2006(E)
COSEM Application Process COSEM Application Process
TCP Connection
Manager
COSEM application COSEM application
layer services layer services
COSEM Application Layer COSEM Application Layer
COSEM
COSEM connectionless
TCP-
connection-oriented
transport services
ABORT.ind
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 2 – Transport layers of the COSEM_on_IP profile
The service user of 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.
5 The COSEM connection-less, UDP-based transport layer
5.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 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 .
———————
The addressing/identification scheme for the COSEM_on_IP profiles is defined in IEC 62056-53, B.3.3.
TCP-CONNECT services
TCP-DISCONNECT services
62056-47 © IEC:2006(E) – 9 –
As already mentioned in Clause 4, the COSEM application layer is listening only on one UDP
port. On the other hand, as defined in IEC 62056-62, 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.
5.2 Service specification for the COSEM UDP-based transport layer
5.2.1 General
The COSEM UDP-based transport layer provides the same set of services both at the Client
and at the Server sides, as shown in Figure 3.
COSEM Client Application Process COSEM Server Application Process
COSEM Client Application Layer COSEM Server Application Layer
COSEM UDP-based Transport Layer COSEM UDP-based Transport Layer
Wrapper Wrapper
N M
UDP UDP
IP IP
Lower layers: Data link and Physical Lower layers: Data link and Physical

Figure 3 – Services of the COSEM connection-less, UDP-based transport layer
The COSEM UDP-based transport layer provides only data communication services: the
connection-less UDP-DATA services. The service set for the UDP-DATA services is the same
at both the client and server sides: consequently, the service specification for these services
is the same for both the client and server transport layers.
The .request and .indication service primitives are mandatory. The implementation of the local
.confirm service primitive is optional.
NOTE The APDU pre-fixed with the header by the wrapper sub-layer must fit in a single UDP datagram.
UDP-DATA.req
UDP-DATA.cnf
UDP-DATA.ind
UDP-DATA.req
UDP-DATA.cnf
UDP-DATA.ind
– 10 – 62056-47 © IEC:2006(E)
5.2.2 The UDP-DATA services
5.2.2.1 UDP-DATA.request
Function
This service primitive is invoked by the service user COSEM application layer to request the
transmission of an APDU to the peer COSEM application layer.
Service parameters
The semantics of the primitive is as follows:
UDP-DATA.request
(
Local_wPort,
Remote_wPort,
Local_UDP_Port,
Remote_UDP_Port,
Local_IP_Address,
Remote_IP_Address,
Data_Length,
Data
)
The Local_wPort, Local_UDP_Port and Local_IP_Address parameters indicate wrapper Port
number, UDP Port number and IP Address parameters belonging to the device/application
process requesting to send the Data.
The Remote_wPort, Remote_UDP_Port and Remote_IP_Address parameters indicate the
wrapper Port number, UDP Port number and IP Address parameters belonging to the
device/application process to which the Data is to be transmitted.
The Local_UDP_Port and Remote_UDP_Port parameters identify the local and remote UDP
ports respectively. Note, that as no well-known port number is reserved for COSEM
communications, the value of these parameters must be in the non-privileged range (above
1024).
The Data_Length parameter indicates the length of the Data parameter in bytes.
The Data parameter contains the COSEM APDU to be transferred to the peer application
layer.
Use
The UDP-DATA.request primitive is invoked by either the client or the server COSEM
application layer to request sending an APDU to a single peer application layer, or, in the
case of multi- or broadcasting, to multiple peer application layers.
The reception of this service primitive shall cause the wrapper sub-layer to pre-fix the wrapper
header to the APDU received, and then to call the SEND() function of the UDP sub-layer with
the properly formed WPDU, see at 5.3.2, as DATA. The UDP sub-layer shall transmit the
WPDU to the peer wrapper sub-layer as described in STD0006.

62056-47 © IEC:2006(E) – 11 –
5.2.2.2 UDP-DATA.indication
Function
This service primitive is invoked by the COSEM transport layer to indicate to the service user
COSEM application layer that an APDU has been received from a remote application layer.
Service parameters
The semantics of the primitive is as follows:
UDP-DATA.indication
(
Local_wPort,
Remote_wPort,
Local_UDP_Port,
Remote_UDP_Port,
Local_IP_Address,
Remote_IP_Address,
Data_Length,
Data
)
The Local_wPort, Local_UDP_Port and Local_IP_Address parameters indicate wrapper Port
number, UDP Port number and IP Address parameters belonging to the device/application
process receiving the Data.
The Remote_wPort, Remote_UDP_Port and Remote_IP_Address parameters indicate the
wrapper Port number, UDP Port number and IP Address parameters belonging to the
device/application process, which has sent the data.
The Local_UDP_Port and Remote_UDP_Port parameters identify the local and remote UDP
ports respectively. Note, that as no well-known port number is reserved for COSEM
communications, the value of these parameters must be in the non-privileged range (above
1024).
The Data_Length parameter indicates the length of the Data parameter in bytes.
The Data parameter contains the COSEM APDU received from the peer application layer.
Use
The UDP-DATA.indication service primitive is used to indicate to the service user COSEM
application layer that an APDU from the peer layer entity has been received.
The primitive is generated following the reception of an UDP Datagram by the UDP sub-layer,
if both the Local_UDP_Port and Local_wPort parameters of the message received contain
valid wPort numbers, meaning that there is a COSEM application process in the receiving
device bound to the given port numbers. Otherwise, the message received shall simply be
discarded.
5.2.2.3 UDP-DATA.confirm
Function
This optional service primitive is invoked by the COSEM transport layer to confirm to the
service user COSEM application layer the result of the previous UDP-DATA.request service.
The service represents a local confirmation only.

– 12 – 62056-47 © IEC:2006(E)
Service parameters
The semantics of the primitive is as follows:
UDP-DATA.confirm
(
Local_wPort,
Remote_wPort,
Local_UDP_Port,
Remote_UDP_Port,
Local_IP_Address,
Remote_IP_Address,
Result
)
The Local_wPort, Remote_wPort, Local_UDP_Port, Remote_UDP_Port, Local_IP_Address
and Remote_IP_Address parameters carry the same values as the corresponding UDP-
DATA.request service being confirmed.
The value of the Result parameter indicates whether the COSEM UDP-based transport layer
was able to send the requested UDP Datagram (OK) or not (NOK).
Use
If implemented, this service primitive is used to confirm the result of a previous UDP-
DATA.request service. It is locally generated and indicates only whether the Data in the
.request primitive could be sent or not. In other words, an UDP-DATA.confirm with Result ==
OK means only that the Data has been sent, and does not mean that the Data has been (or
will be) successfully delivered to the destination.
5.3 Protocol specification for the COSEM UDP-based transport layer
5.3.1 General
As it is shown on the left side of Figure 2, the COSEM UDP-based transport layer includes the
Internet standard UDP layer, as specified in Internet standard STD0006, and the COSEM-
specific light-weight wrapper sub-layer.
In this communication profile, the wrapper sub-layer is a state-less entity: its only roles are to
ensure source and destination COSEM application process identification using the wPort
numbers and to provide conversion between the OSI-style UDP-DATA.xxx service invoca-
tions and the SEND() and RECEIVE() interface functions provided by the standard UDP.
Although it is not necessary in the UDP-based profile, in order to have the wrapper protocol
control information – in other words the wrapper header – the same in both COSEM transport
layers, the wrapper sub-layer shall also include the Data Length information in the wrapper
protocol data unit.
5.3.2 The wrapper protocol data unit (WPDU)
The WPDU consists of two parts:
• the wrapper header part, containing the wrapper protocol control information, and
• the Data part, containing the DATA parameter – the COSEM APDU – of the corresponding
UDP-DATA.xxx service invocation.

62056-47 © IEC:2006(E) – 13 –
The wrapper header includes four fields, each 16 bits long, as follows:
• Version: this 16 bit long unsigned integer value carries the version number identifying the
version of the wrapper. Its value is controlled by the DLMS User Association. The current
value is 0x0001. Note, that in later versions the wrapper header may have a different
structure.
• Source wPort: this 16 bit long unsigned integer value carries the wPort number identifying
the sender application process.
• Destination wPort: this 16 bit long unsigned integer value carries the wPort number
identifying the destination application process.
• Data length: this 16 bit long, unsigned integer value indicates the length of the DATA field
of the WPDU (the length of the APDU transported).
The Wrapper Protocol Data Unit (WPDU) is shown in Figure 4.
Wrapper control
Data field
information
Wrapper header DATA (APDU)
Version, 2 bytes
Source wPort, 2 bytes
Destination wPort: 2 bytes
Length: 2 bytes
NOTE The maximum length of the APDU should be eight bytes less than the maximum length of the UDP
datagram.
Figure 4 – The wrapper protocol data unit (WPDU)
5.3.3 The COSEM UDP-based transport layer protocol data unit
In this profile, WPDUs shall be transmitted in UDP Datagrams. The UDP Datagram is as it is
specified in Internet standard STD0006, and it shall encapsulate the WPDU, as it is shown in
Figure 5.
UDP protocol control information Data field of the UDP PDU (WPDU)
Wrapper header
UDP header APDU
Source UDP Port, 2 bytes
Destination UDP Port: 2 bytes
UDP Length: 2 bytes
Checksum
Figure 5 – The COSEM connection-less, UDP-based transport layer PDU (UDP-PDU)

– 14 – 62056-47 © IEC:2006(E)
From the external point of view, the COSEM connection-less transport layer PDU is an
ordinary UDP Datagram: any COSEM specific element, including the wrapper-specific header
is inside the UDP Data field. Consequently, standard UDP implementations can be (re-)used
to easily implement this profile.
The Source and Destination UDP ports may refer to either local or remote UDP ports
depending on the direction of the data transfer (i.e. from the point of view of the sending
device, the Source UDP port in a Datagram corresponds to the Local_UDP_port, but from the
point of view of the receiving device, the Source UDP port of a Datagram corresponds to the
Remote_UDP_Port service parameter).
According to the UDP specification, filling the Source UDP Port and Checksum fields with real
data is optional. A zero value – all bits are equal to zero – of these fields indicates that in the
given UDP Datagram the field is not used. However, in the COSEM_on_IP profile, the Source
UDP Port field shall always be filled with the Source UDP port number.
5.3.4 Reserved wrapper port numbers (wPorts)
The following wPort Numbers are reserved:
Table 1 – Reserved wrapper Port numbers in the UDP-based COSEM profile
Client side reserved addresses
Wrapper Port Number
No-station 0x0000
Client Management Process 0x0001
Public Client 0x0010
Server side reserved addresses
Wrapper Port Number
No-station 0x0000
Management Logical Device 0x0001
Reserved 0x0002.0x000F
All-station (Broadcast) 0x007F

5.3.5 Protocol state machine
As the wrapper sub-layer in this profile is state-less, for all other protocol related issues –
protocol state machine, etc. – the governing rules are as they are specified in the Internet
standard STD0006. The only supplementary rule is concerning discarding inappropriate
messages: messages with no valid Destination wPort number – meaning that there are no
COSEM application processes in the receiving device bound to this wPort number – shall be
discarded by the wrapper sub-layer.
6 The COSEM connection-oriented, TCP-based transport layer
6.1 General
The COSEM connection-oriented transport layer is based on the connection-oriented Internet
transport protocol, called Transmission Control Protocol or TCP.

62056-47 © IEC:2006(E) – 15 –
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 Annex A.
6.2 Service specification for the COSEM TCP-based transport layer
6.2.1 General
The COSEM connection oriented, TCP-based transport layer provides the same set of
services both at the client and at the server sides, as it is shown in Figure 6.

– 16 – 62056-47 © IEC:2006(E)
COSEM Client COSEM Server
TCP Connection Manager TCP Connection Manager
Application Process Application Process
COSEM Client COSEM Server
Application Layer Application Layer
COSEM TCP-based Transport Layer COSEM TCP-based Transport Layer
Wrapper Wrapper
N M
TCP TCP
IP IP
Lower layers: Data link and Physical Lower layers: Data link and Physical

Figure 6 – Services of the COSEM connection-oriented, TCP-based transport layer
In this communication profile, the full set of TCP connection management services (TCP-
CONNECT and TCP-DISCONNECT) is provided both at the client and at the server sides. The
purpose of this is to allow the server to initiate and to release a TCP connection, too .
The service user of the TCP connection management services is not the COSEM application
layer, but the TCP connection manager process. The specification of this process is out of the
scope of this standard – however, the COSEM application layer sets some requirements
concerning this. See B.3.4 of IEC 62056-53.
An additional COSEM-ABORT.indication service is provided to indicate to the COSEM
application layer the disruption or disconnection of the supporting TCP connection.
Like in the COSEM UDP-based transport layer, the TCP-DATA.confirm service is also option-
al. However, the TCP-DATA.request service can be confirmed either locally or remotely.
6.2.2 The TCP-CONNECT services
6.2.2.1 TCP-CONNECT.request
Function
This service primitive is invoked by the service user TCP connection manager process to
request the establishment of a TCP connection.
———————
Application association establishment is performed by the client application process.
TCP-CONNECT.req/.cnf
.ind/.res
TCP-DISCONNECT.req/.cnf
.ind/.res
TCP-ABORT.ind
TCP-DATA.req
TCP-DATA.cnf
TCP-DATA.ind
TCP-DATA.req
TCP-DATA.cnf
TCP-DATA.ind
TCP-ABORT.ind
TCP-DISCONNECT.req/.cnf
.ind/.res
TCP-CONNECT.req/.cnf
.ind/.res
62056-47 © IEC:2006(E) – 17 –
Service parameters
The semantics of the primitive is as follows:
TCP-CONNECT.request
(
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address
)
The Local_TCP_Port and Remote_TCP_Port parameters identify the local and remote TCP
ports respectively. As no well-known port number is reserved for COSEM communications,
the value of these parameters must be in the non-privileged range (above 1024).
The Local_IP_Address and Remote_IP_Address parameters indicate the IP Address of the
physical device requesting the TCP connection and of the target physical device, to which the
TCP connection requested is to be established.
Use
The service user TCP connection manager process invokes this service primitive to initiate a
TCP connection establishment with the peer COSEM TCP-based transport layer.
6.2.2.2 TCP-CONNECT.indication
Function
This service primitive is invoked by the COSEM TCP-based transport layer following the
reception of a TCP packet, indicating to the TCP connection manager process that a remote
device is requesting a new TCP connection.
Service parameters
The semantics of the primitive is as follows:
TCP-CONNECT.indication
(
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address
)
The Local_TCP_Port- and Remote_TCP_Port parameters indicate the two TCP ports between
which the requested TCP connection is to be established.
The Local_IP_Address and Remote_IP_Address parameters indicate the IP addresses of the
two devices participating in the TCP connection.
Use
When the COSEM TCP-based transport layer receives a TCP packet indicating that a remote
TCP layer is requesting a new TCP connection, it shall indicate this to the service user TCP
connection manager process using this service primitive.

– 18 – 62056-47 © IEC:2006(E)
6.2.2.3 TCP-CONNECT.response
Function
This service primitive is invoked by the TCP connection manager process to indicate to the
COSEM TCP-based transport layer whether the previously requested TCP connection has been
accepted. The TCP connection manager cannot reject a requested connection.
Service parameters
The semantics of the primitive is as follows:
TCP-CONNECT.response
(
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address,
Result
)
The Local_TCP_Port and Remote_TCP_Port parameters indicate the two TCP ports between
which the requested TCP connection is being established.
The Local_IP_Address and Remote_IP_Address parameters indicate the IP addresses of the
two physical devices participating in the TCP connection.
The Result parameter indicates that the service user TCP connection manager has accepted
the requested TCP connection. Its value must always be SUCCESS.
Use
The service user TCP connection manager process invokes this service to indicate to the
COSEM TCP-based transport layer that it has accepted the previously requested TCP
connection.
6.2.2.4 TCP-CONNECT.confirm
Function
This service primitive is invoked by the COSEM TCP-based transport layer to indicate to the
service user TCP connection manager process the result of a previously received TCP-
CONNECT.request service invocation.
Service parameters
The semantics of the primitive is as follows:
TCP-CONNECT.confirm
(
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address,
Result,
Reason_of_Failure
)
The Local_TCP_Port and Remote_TCP_Port parameters indicate the two TCP ports between
which the TCP connection is being established.

62056-47 © IEC:2006(E) – 19 –
The Local_IP_Address and Remote_IP_Address parameters indicate the IP addresses of the
two physical devices participating in this TCP connection.
The Result parameter indicates, whether the requested TCP connection is established or not.
Note, that this service primitive is normally the result of a remote confirmation – and as a TCP
connection request cannot be rejected, the Result parameter shall always indicate SUCCESS.
However, the Result parameter may also indicate FAILURE, when it is locally confirmed. In
this case the Reason_of_Failure parameter indicates the reason for the failure.
Use
The COSEM TCP-based transport layer shall indicate to the service user TCP connection
manager the result of a previously received TCP-CONNECT.request service invocation with
the help of this service.
6.2.3 The TCP-DISCONNECT services
6.2.3.1 TCP-DISCONNECT.request
Function
This service primitive is invoked by the service user TCP connection manager process to
request the disconnection of an existing TCP connection.
Service parameters
The semantics of the primitive is as follows:
TCP-DISCONNECT.request
(
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address
)
The service parameters are the identifiers of the TCP connection to be released. The
Local_TCP_Port and Local_IP_Address parameters designate the local TCP port and IP
Address of the requesting device and application, the Remote_IP_Address and
Remote_TCP_Port parameters refer to the remote device and application.
Use
This service is used by the TCP connection manager process to request the disconnection of
an existing TCP connection.
6.2.3.2 TCP-DISCONNECT.indication
Function
This service primitive is invoked by the COSEM TCP-based transport layer to the service user
TCP connection manager process to indicate that the peer entity has requested the
disconnection of an existing TCP connection.
The same service is used also to indicate if the transport layer detects a non-solicited
disconnection of an existing TCP connection (for example, when the physical connection
breaks down).
– 20 – 62056-47 © IEC:2006(E)
Service parameters
The semantics of the primitive is as follows:
TCP-DISCONNECT.indication
(
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address,
Reason
)
The Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address para-
meters identify the TCP connection, which is either requested to be released by the peer
device, or has been aborted.
The Reason parameter indicates whether the service is invoked because of the peer device
has requested a TCP disconnection (Reason == REMOTE_REQ), or it is locally originated by
detecting a kind of event, which must imply the disconnection of the TCP connection (Reason
).
== ABORT
Use
The COSEM TCP-based transport layer shall signal the reception of a TCP disconnection
request or a detected TCP connection abort to the service user TCP connection manager with
the help of this service primitive.
6.2.3.3 TCP-DISCONNECT.response
Function
This service primitive is invoked by the TCP connection manager process to indicate to the
COSEM TCP-based transport layer whether the previously requested TCP disconnection is
accepted. Note, that the TCP connection manager process cannot reject the requested
disconnection.
This service primitive is invoked only if the correspon
...