cosem architecture and protocols - dlms · data link layer using hdlc-protocol ... • terms are...

Reference number: EXCERPT FROM DLMS UA 1000-2:2004, Fourth Edition © Copyright 1997-2004 DLMS User Association

EXCERPT FROM Companion Specification for Energy Metering COSEM Architecture and Protocols DLMS User Association

device ™languagemessagespecification

DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fourth Edition

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

© Copyright 1997-2004 DLMS User Association




Table of Contents

1. Foreword ......................................................................................................................................................................5 2. Scope............................................................................................................................................................................6 3. Introduction..................................................................................................................................................................7 3.1 The COSEM communications framework ....................................................................................................................7 3.1.1 Client/server type operation, communication profiles................................................................................................7 3.1.2 Connection (association) oriented operation.............................................................................................................8 3.2 Interoperability and interconnectivity in COSEM ..........................................................................................................9 3.3 Ensuring interconnectivity: the protocol identification service ......................................................................................10 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 ....................................................................................................................20 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.............................................................................................................................23 6. Direct Local Connection (excerpt) .............................................................................................................................25 7. COSEM transport layers for IP networks...................................................................................................................26 7.1 Scope...........................................................................................................................................................................26 7.2 Overview......................................................................................................................................................................26 7.3 The COSEM connection-less, UDP-based transport layer ..........................................................................................28 7.3.1 Introduction ...............................................................................................................................................................28 7.4 The COSEM connection-oriented, TCP-based transport layer ....................................................................................29 7.4.1 Introduction ...............................................................................................................................................................29 7.5 Converting OSI-style transport layer services to and from RFC-style TCP function calls ............................................30 7.5.1 Transport layer and TCP connection establishment .................................................................................................30 7.5.2 Closing a transport layer and a TCP connection.......................................................................................................31 7.5.3 TCP connection abort ...............................................................................................................................................32 7.5.4 Data communication – the TCP-Data service ...........................................................................................................32 8. Data Link Layer using HDLC-Protocol .......................................................................................................................35 8.1 Overview......................................................................................................................................................................35 8.1.1 The LLC sub-layer ....................................................................................................................................................35 8.1.2 The MAC sub-layer ...................................................................................................................................................35 8.1.3 Specification method.................................................................................................................................................36 8.2 The LLC sub-layer .......................................................................................................................................................36 8.2.1 The role of the LLC sub-layer ...................................................................................................................................36 8.2.2 Service specification for the LLC sub-layer ...............................................................................................................37 8.2.2.1 Setting up the data link connection ........................................................................................................................37 8.2.2.1.1 Overview.............................................................................................................................................................37 8.3 The MAC sub-layer ......................................................................................................................................................38 8.3.1 HDLC selections .......................................................................................................................................................38 8.3.2 Service specification for the MAC sub-layer .............................................................................................................38 8.4 Data link layer management services ..........................................................................................................................39 8.4.1 Overview...................................................................................................................................................................39 9. COSEM application layer ............................................................................................................................................41 9.1 Overview......................................................................................................................................................................41 9.1.1 Specification method.................................................................................................................................................41




9.1.2 Application layer structure.........................................................................................................................................41 9.1.3 Service specification .................................................................................................................................................42 9.1.3.1 Services provided for application association establishment and release ..............................................................42 9.1.3.2 Data communication services ................................................................................................................................42 9.1.4 Layer management services .....................................................................................................................................43 9.1.5 Protocol specification ................................................................................................................................................44 9.2 COSEM application layer – Service specification.........................................................................................................44 9.2.1 Summary of services.................................................................................................................................................44 9.2.2 Application association establishment and release ...................................................................................................45 9.2.3 Special application associations................................................................................................................................45 9.2.3.1 Confirmed application associations........................................................................................................................45 9.2.3.2 Non-confirmed application associations.................................................................................................................45 9.2.3.3 Pre-established application associations................................................................................................................46 9.2.3.4 Mandatory application associations .......................................................................................................................46 9.2.4 Data communication .................................................................................................................................................46 9.3 COSEM application layer protocol specification...........................................................................................................47 9.3.1 State definitions for the client side control function ...................................................................................................47 9.3.2 State definitions for the server side control function..................................................................................................49 9.3.3 Protocol for application association establishment/release .......................................................................................50 9.3.3.1 Establishment of a confirmed application association ............................................................................................50

Figures Figure 1 – The three steps approach of COSEM: Modelling - Messaging - Transporting ....................................................6 Figure 2 - Client / server relationship in COSEM .................................................................................................................7 Figure 3 - Exchanging messages via the communication protocol ......................................................................................7 Figure 4 - The COSEM application layer on the top of various lower layer stacks...............................................................8 Figure 5 - A complete communications session in the CO environment ..............................................................................9 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 ............................................................................................................................16 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) ...................................................................................................................25 Figure 15 – COSEM as a standard Internet application protocol .......................................................................................27 Figure 16 – Transport layers of the COSEM_on_IP profile................................................................................................28 Figure 17 – TCP connection state diagram........................................................................................................................30 Figure 18 – MSC and state transitions for establishing a transport layer and TCP connection..........................................31 Figure 19 – MSC and state transitions for closing a transport layer and TCP connection..................................................32 Figure 20 – Polling the TCP sub-layer for TCP abort indication.........................................................................................32 Figure 21 – Sending an APDU in three TCP packets ........................................................................................................33 Figure 22 – Receiving the message in several packets .....................................................................................................34 Figure 23 - Data link (LLC) services for setting up the data link connection.......................................................................37 Figure 24 - MAC sub-layer services for setting up the MAC (DL) connection at the Client- and Server sides ...................39 Figure 25 - Layer management services............................................................................................................................40 Figure 26 – The structure of the COSEM application layers ..............................................................................................41 Figure 27 – Structure of the COSEM AL when the server is using SN references.............................................................43 Figure 28 – Summary of COSEM application layer services..............................................................................................44 Figure 29 – Normal service sequence for the COSEM-OPEN service...............................................................................45 Figure 30 – Partial state machine for the client side control function .................................................................................48 Figure 31 – Partial state machine for the server side control function................................................................................49 Figure 32 - MSC for successful application association establishment preceded by a successful lower layer connection establishment.....................................................................................................................................................................51




1. Foreword

Copyright © Copyright 1997-2004 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, e.g. IEC TC13 WG14, CEN TC294 WG2 and IEC TC57 WG9.

Status of standardization This fourth 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, Electricity metering - Data exchange for meter reading, tariff and load control - Part 46: Data link layer using HDLC protocol, as amended by 13/1313/CD, draft Amendment 1;

IEC 62056-53, Electricity metering - Data exchange for meter reading, tariff and load control - Part 53: COSEM Application layer, as amended by 13/1311/CD, draft Edition 2;

13/1309/NP, Draft IEC 62056-47, Electricity metering - Data exchange for meter reading, tariff and load control - Part 47: COSEM transport layers for IP networks (clause 7);

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).

Furthermore, a new clause on Architecture has been added (Clause 4).

For easier use, in this edition, changes compared to Edition 3 are marked by highlighted text. The new Clauses 4 and 7 are not highlighted.




2. Scope

The data model uses generic building blocks to define the complex functionality of the metering equipment. It provides a view of this functionality of the meter as it is available at its interface(s). The model does not cover internal, implementation-specific issues.

The communication protocol defines how the data can be accessed and exchanged.

The COSEM specifications follow a three step approach as illustrated in Figure 1:

Step 1: The meter model and data identification (data model);

Step 2: The mapping of the model into protocol data units (pdu);

Step 3: The transportation of the bits and bytes through the communication channel.

Metering domain specific Interface Objects are specified by the COSEM specification "Identification System and Interface Classes" DLMS UA 1000-1. The functionality of the meter is defined by the instances of these interface classes, 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.

• 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. Transporting

C0 01 00 03 01 01 01 08 00 FF 02

2. Messaging

Protocol Services to access attributes and methods

ISO, IEC,...

Communication Protocol

Messages :Service_Id( Class_Id, Instance_Id, Attribute_Id/Method_Id )

Encoding: ( APDU )

1. Modelling COSEM Interface Objects

Register 0..n Class_id=3, Version=0Attribute(s) Data Type Min Max Def1. logical_name (static) octet-string2. value (dyn.) instance specific3. scaler-unit (static) scal_unit_typeMethod(s) m/o1. reset o

DLMS User Associatio

n




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 equipment1 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 on Figure 2.

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.

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.

Client application Server application (COSEM device)

SERVICE.request

SERVICE.response

Client

Application layer

Intermediateprotocol layers

Physical layer

Server .request

.response

.request .response

Protocol

Physical channel




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 on Figure 4.

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 ACSE2 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 associated3. Therefore, in this environment a communication session consists of three phases, as it is shown on Figure 5.

2 ACSE = Association Control Service Element 3 Application associations can be considered as application level connections.

xDLMS_ASE ACSE

Application layer

N layer N-1 layer

N layer N layer

Physical layer Physical layer Physical layer

Profile 1 Profile 2 Profile M

………




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.2. 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.

Client application Server application

Phase 1.Connection establishment

Phase 2.Data communication

Phase 3. Connection release t




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 (e.g. 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. The protocol identification service 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. The identification service is specified in the clause describing the Physical layer. 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. 6 COSEM Identification System and Interface Objects, "Blue Book" (2004) DLMS UA 1001-1 ed. 2 COSEM Conformance Test Process, "Yellow Book" (2002) DLMS UA 1002 ed. 1 COSEM Glossary of Terms, "White Book" (2003) IEC 61334-4-41:1996 Distribution automation using distribution line carrier systems - Part 4: Data

communication protocols - Section 41: Application protocol - Distribution line message specification

IEC 61334-6:2000 Distribution automation using distribution line carrier systems – Part 6: A-XDR encoding rule

IEC 62056-21:2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 21: Direct local data exchange

IEC 62056-31: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: 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: 2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 46: Data link layer using HDLC protocol (as amended by 13/1313/CD, draft Amendment 1)

Draft IEC 62056-47 Electricity metering – Data exchange for meter reading, tariff and load control – Part 47: COSEM transport layer for IP networks (13/1309/NP)

IEC 62056-53: 2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 53: COSEM application layer (as amended by 13/1311/CD, draft Edition 2)

IEC 62056-61: 2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 61: OBIS Object identification system (as amended by 13/XXXX/CD, draft Edition 2)

IEC 62056-62: 2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 62: Interface classes (as amended by 13/XXXX/CD, draft Edition 2)

ISO/IEC 8649: 1996 Information technology - Open Systems Interconnection - Service definition for the Association Control Service Element

ISO/IEC/TR2 8650-1: 1996 Information technology - Open systems interconnection - Connection-oriented protocol for the association control service element: Protocol specification




Ref. Title ISO/IEC 8802-2: 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: 2002 Information Technology - Telecommunications and information exchange between systems – High-level data link control (HDLC) procedures

prEN 13757-2 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 Object

An instance of a COSEM Interface Class

COSEM_on_IP The TCP-UDP/IP based COSEM communication profile DCE Data Communication Equipment (communications interface or modem) DISC Disconnect (a HDLC frame type) DLMS Distribution Line 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 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.

Data collection system: Client

Application process#01

Public client

Application process#02

Application process#0m

Metering equipment: Server

Logical device #01Management LogicalDevice

COSEM objects

Logical device #02COSEM objects

Logical device #03COSEM objects

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, but these 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.

Communicationprofile #0n

Communicationprofile #02

Communicationprofile #01

COSEM Application layer

COSEM Server Application Process

ACSE xDLMSASE

Wrapper

N-1 layerTransport layer

Network layer

Data link layer

Physical layer

Data link layer

N-2 layer

Physical layer Physical layer

COSEM Client Application Process

Comm.profile #01

Comm.profile #02

Comm.profile #0n

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, prEN 13757-2) or carrier signalling (EURIDIS, IEC 62056-31), 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 meterusing TCP-UDP/IP based profile

DLMS/COSEM meter using 3-layer, CO, HDLC based profile

COSEM Transport layer


HDLC based data link layer

Log_Dev_1 (Mgmt.) Log_Dev_2 Log_Dev_n

COSEM Application layer ACSE xDLMS

ASE

# 0x # 0y # 01

Physical layere.g. RS 232, RS 485, optical port, current loop

Port # 2 Port # 1 Port # k

Log_Dev_1(Mgmt.) Log_Dev_2 Log_Dev_m

xDLMS ASE

Port # 2Port # 1 Port # l

WebpagesFiles

FTP HTTP

COSEM wrapper # 01 # 0x # 0y

Network layerIP

Data link layere.g. PPP

Data link layere.g. Ethernet

Transport layerTCP or UDP

Data link layer e.g. ATM

Physical layere.g. RS 232

Physical layere.g. Ethernet

Physical layer e.g. PPP

FTPport

HTTPport

DLMS/COSEM

port

Phy DeviceAddr

ACSE

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 (e.g. 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 systemusing both 3-layer, CO, HDLC based and TCP-UDP/IP based communication profile

COSEM Transport layer


HDLC based data link layer

# 0w # 0z# 01

Physical layere.g. RS 232, RS 485, optical port, current loop

Port # 2Port # 1 Port # n

Appl_Process_1

Public client

Appl_Process_2

Appl_Process_m

ACSE xDLMSASE

Port # 2Port # 1 Port # n

WebpagesFiles

FTP HTTP

DLMS/COSEM wrapper

# 01 # 0w # 0z

Network layerIP

Data link layere.g. PPP

Data link layere.g. Ethernet

Transport layerTCP or UDP

Data link layere.g. ATM

Physical layere.g. RS 232

Physical layere.g. Ethernet

Physical layere.g. PPP

FTPport

HTTPport

DLMS/COSEM

port

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 site #1

Ethernet

Metering site #n

e.g.

RS

485

Server Server

Access Point

DLMS

DLMSDLMS

DLMS

DLMS

Access Point

DLMS

DLMS

Modem

Modem

HHU

Internet

Local DCS

Portable DCS

Modem

WANe.g. PSTN, GSM

Remote DCS Remote DCS

FirewallServer

Firewall Firewall

HHU

Figure 10 – Model of a DLMS/COSEM based meter data collection system

On Figure 10, a model of two metering sites and two remote data collection systems are shown.

On metering site #1, metering equipment use a TCP-UDP/IP based communication profile and they are connected to an Ethernet LAN. In addition, a local data collection system (DCS) is installed. Each physicial device with has its own IP address. The entry point to the metering site is the same as the entry point of the LAN. Meters can be reached remotely through the internet, locally through the local data collection system, or directly by a Hand Held Unit (HHU). On the optical port, metering equipment may communicate either using the 3-layer, CO, HDLC based communication profile or the TCP-UDP/IP based communication profile using PPP.

On metering site #2, metering equipment use the 3-layer, CO, HDLC based communication profile. To be able to reach them through a single WAN access point, they are connected to a bus e.g. RS 485. The address of a physical device on the LAN is provided by its lower HDLC address. As RS 485 does not provide a protocol for handling collisions on the bus, the client may exchange data with the servers on the LAN one by one. In other words, the task of the bus master is performed by the client. The access point of the LAN is a modem with an RS 485 interface. Its address is provided by the WAN, which can be either the PSTN or the GSM telephone network. For local data exchange, a portable DCS, connected directly to the RS 485 bus may be used. In this case, remote access may not be available during the local communication. Like at metering site #1, direct local data exchange is available using an HHU.

Other LAN types, like MBUS (prEN 13757-2), Euridis (IEC 62056-31) or PLC are also possible.




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, e.g. 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 on 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 (e.g. 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 (e.g. 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, e.g. 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.

kWh

Sch lumb erg er

00001,6

10 (40)A 230V 50Hz

(o) N° 00012356

Transit network

DTE to DCE

ITU-T V. Series EIA RS232, RS485

Hayes, etc...

DCE to DTE ITU-T V. Series

EIA RS232, RS485 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, taking the initiative and controlling the data flow. The tariff device is the slave, responding to the master station. From the application point of view the central station normally acts as a client asking for services, and the tariff device 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 purpose 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.

COSEM client COSEM server

DTE DTE DCE DCE




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.

Transit network

DTE

Datacomm.

equipment(DCE)

COSEM client COSEM server

Clientapplication

Applicationlayer

Data Linklayer

Physicallayer

Pro

toco

lDTE

Serverapplication

Applicationlayer

Data Linklayer

Physicallayer

Pro

toco

l

Datacomm.

equipment(DCE)




Figure 13 - Protocol layer services of the COSEM 3-layer connection oriented profile

As 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 ....

Application layer

Physical layer

Data link layer

AL management services

Connect/disconnect anddata related services

Layer managementprocess

ASO services

Application processPhysical

connectionmanager

Prot

ocol

Appl

icat

ion

PH

-CO

NN

EC

T.re

q /.c

nf /.

ind

PH

-AB

OR

T.re

q /.c

nf /.

ind

PH

-DA

TA.re

q /.i

nd

PH-DATA.req /.indPH-ABORT.ind

DL management services

PH management services




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. METERING HDLC protocol using protocol mode E for direct local data exchange The protocol stack as described in Clauses 5, 8 and 0 of this specification (or IEC 62056-42, IEC 62056-46 and IEC 62056-53) 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. 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.

/ ? Device address ! CR LF

/ XXXZ \W Ident CR LF

ACK 2 Z 2 CR LF ACK V Z Y CR LF

ACK 2 Z 2 CR LF notaccepted

End

METERINGHDLC protocol

IEC 62056-21Mode Y

Sign on

Client

(HHU)

Server

Tariffdevice

Client

Server

Clientinitiates ...

300 Bd 7E1

Z Bd. 7E1

Z Bd. 8N1

W = 2

Figure 14 - Entering protocol mode E (HDLC)

more details, see complete Green Book ....

4 W = @ is used for country specific applications




7. COSEM transport layers for IP networks

7.1 Scope

This chapter specifies the transport layers for COSEM communication profiles for use on IP 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 (IP) network layer to communicate with other nodes connected to the abstract IP 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 on Figure 15.




...

Files WEBpages

COSEMinterface model

Application / Data models

e.g. FTP e.g. HTTP COSEM ALACSE + xDLMS

Internet Transport Layer (UDP & TCP)

Wrapper

Internet Network layer (IP)

Data Link Layer

Physical Layer

Standard application protocols

Figure 15 – COSEM as a standard Internet application protocol

As the COSEM application layer specified in Clause 0 (or 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.

The COSEM application layer uses only one UDP or TCP port. On the other hand, as defined in DLMS UA 1000-1 (or 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 on Figure 16.




COSEM UDP-based Transport Layer

COSEM Application Layer

COSEM Wrapper

Internet UDP

COSEM application layer services

COSEM connectionlesstransport services

UDP-DATA.req/.ind/(.cnf)

UDP function callsSEND, RECEIVE

a) the UDP-based profile

IP and lower layers

COSEM TCP-based Transport Layer

COSEM Application Process

COSEM Application Layer

COSEM Wrapper

Internet TCP

COSEM applicationlayer services

COSEMconnection-orientedtransport services

TCP-DATA.req/.ind/(.cnf)

TCP function callsactive/passive OPEN,

SEND, RECEIVE

b) the TCP-based profile

IP and lower layers

TCP ConnectionManager

TCP-

CO

NN

ECT

serv

ices

TCP-

DIS

CO

NN

ECT

serv

ices

COSEM Application Process

TCP-ABORT.ind

Figure 16 – 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 Introduction 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 IP address5.

5 The addressing/identification scheme for the COSEM_on_IP profiles is separately defined.




As already mentioned in Clause 7.2, the COSEM application layer uses only one UDP port. On the other hand, as defined in DLMS UA 1000-1 (or 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.


7.4 The COSEM connection-oriented, TCP-based transport layer

7.4.1 Introduction 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 17) a passive OPEN takes the caller device to the LISTEN state, waiting for a connection request from any remote TCP and port.

Figure 17 – 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 on Figure 18

ESTAB-LISHED

CLOSED

LISTEN

SYN RECVD

SYN SENT

CLOSE WAIT

FIN WAIT-1

FIN WAIT-2

CLOSING

TIME WAIT

LAST ACK

begin

anything / reset

active OPEN / syn

SEND / syn

syn / ack

CLOSE

passive OPEN

syn / syn + ack

reset

ack syn + ack / ack

fin / ack

CLOSE / timeout / reset

ack /

timeout after 2 segment lifetimesack /

CLOSE / fin

CLOSE/ fin

fin / ack

ack /

fin / ack

fin-ack / ack

CLOSE/ fin




Note: in the case of the COSEM transport layer, the TCP user protocol layer is the wrapper sub-layer.

Figure 18 – 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 numbers6 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 on Figure 19.

6 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.

ESTAB-LISHED

CLOSED

LISTEN

SYN RECVD

SYN SENT

CLOSE WAIT

FIN WAIT-1

FIN WAIT-2

CLOSING

TIME WAIT

LAST ACK

begin

anything / reset

active OPEN / syn

SEND / syn

syn / ack

CLOSE

passive OPEN

syn / syn + ack

reset

ack syn + ack / ack

fin / ack


ack /


CLOSE / fin

CLOSE/ fin

fin / ack

ack /

fin / ack

fin-ack / ack

CLOSE/ fin

active OPEN

TCP Connection is established

TCP User Protocol Layer TCP User

Protocol LayerTCP Layer TCP Layer

passive OPEN

TCP is in LISTEN

state

TCP is in SYN SENT

state

syn

syn + ack

TCP is in ESTABLISHED

state

TCP is in SYN RECVD

state ack


state

No TCP Connection is established ( both TCPs are in CLOSED state )

1

2

1

2

3




Note: in the case of the COSEM transport layer, the TCP user protocol layer is the wrapper sub-layer.

Figure 19 – 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 on Figure 20.

Figure 20 – 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.

ESTAB-LISHED

CLOSED

LISTEN

SYN RECVD

SYN SENT

CLOSE WAIT

FIN WAIT-1

FIN WAIT-2

CLOSING

TIME WAIT

LAST ACK

begin

anything / reset

active OPEN / synSEND / syn

syn / ack

CLOSE

passive OPEN

syn / syn + ack

reset

ack syn + ack / ack

fin / ack


ack /


CLOSE / fin

CLOSE/ fin

fin / ack

ack /

fin / ack

fin-ack / ack

CLOSE/ fin

S = status( )

Connected

COSEMApplication

Layer

Wrappersub-layer

TCPsub-layer

S = status( )

Disconnected

TCP connection is shut down

TCP-ABORT.ind

TCP User

Protocol Layer TCP UserProtocol LayerTCP Layer TCP Layer

CLOSE

TCP is in CLOSE WAIT

state

TCP is in FIN WAIT-1

state

fin

fin


state

TCP is in TIME WAIT

state

ack


state

ack

CLOSE

TCP is in FIN WAIT-2

state

TCP is in LAST ACK

state

TCP is in CLOSED

state

TCP is in CLOSED

state

signal received fin

No TCP Connection is established

1

2

3

1

2

3

4




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 layer7 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 on Figure 21.

Figure 21 – 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.

7 Both the client- and server side application layers can be either sender or receiver.

TCP-Data.req( Data ) N = send( WH+Data, 1000 )

N = 476

COSEM Application

Layer Wrapper sub-layer

Peer TCP sub-layer

TCPsub-layer

TCP-DATA.cnf

DataLength = 992

N = send( rem_Data, 524 ) )

N = 302

N = send( rem_Data, 222 )

N = 222




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 on Figure 22.

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 22 – 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.

TCP-Data.ind( Data )

N = recv( 6, &buff )

N = 6

COSEMApplication

Layer

Wrappersub-layer

Peer TCPsub-layer

TCPsub-layer


N = 302


N = 222


N = 470


N = 302


N = 222

N = send( WH + Data, 1000 )

N = 476

T1




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 2 gives an explanation of the role of data models and protocols in electricity meter data exchange. Overview of the data link layer specification:

8.1.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.2.

8.1.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. The MAC sub-layer is specified in Clause 8.2.




8.1.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.

NOTE Data link layer management services are separately explained

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.2 The LLC sub-layer

8.2.1 The role of the LLC sub-layer The LLC sub-layer used in this profile is based on ISO/IEC 8802-2:1998. 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.2.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.2.2.1 Setting up the data link connection

8.2.2.1.1 Overview Figure 23 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.

Figure 23 - 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. more details, see complete Green Book ....

DL-

CO

NN

ECT.

req

DL-

CO

NN

ECT.

ind

DL-

CO

NN

ECT.

res

DL-

CO

NN

ECT.

cnf

Primary station / Client side Secondary station / Server side

LLC sub-layer

Service user layer

MAC sub-layer

Physical layer

Data link layer




8.3 The MAC sub-layer The MAC sub-layer is based on ISO/IEC 13239:2000. 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.3.1 HDLC selections For the purposes of this specification, the following selections from the HDLC standard ISO/IEC 13239:2000 have been made: • unbalanced connection-mode data link operation8; • two-way alternate data transfer; • the selected HDLC class of procedure is UNC (Unbalanced operation Normal response mode Class),

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 organisation of data flow and for unrecoverable data link level error conditions by sending command 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 Unnumbered Information (UI) frame to support multi- 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.3.2 Service specification for the MAC sub-layer This Clause 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. Setting up the MAC Connection The following figure shows the services provided by the Client- and Server side MAC sub-layers to the service user layer for MAC connection establishment.

8 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.




Figure 24 - MAC sub-layer services for setting up the MAC (DL) connection at the Client- and Server sides

As data link connection establishment can only be requested by the Client device, the MA-CONNECT.request and .confirm services are provided only at the Client side. On the other hand, the corresponding MA-CONNECT.indication and .response services are provided only at the Server side. The MA-CONNECT.request service primitive - in case of a locally detected error - can be also locally confirmed. more details, see complete Green Book ....

8.4 Data link layer management services

8.4.1 Overview Figure 25 shows management services provided by the data link layer to the system management process. The same service set is used both at the client and the server sides. As these services are of local importance only, these clauses are included here only as guidance.

MA

-CO

NN

ECT.

req

MA-

CO

NN

ECT.

ind

MA

-CO

NN

ECT.

res

MA

-CO

NN

ECT.

cnf

Primary station / Client side Secondary station / Server side

MAC sub-layer

Service user layer

Physical Layer

SNRM command

UA or DM response




Application Layer

DL-INITIALIZE.req/.conf

DL-GET_VALUE.req/.conf

DL-SET_VALUE.req/.conf

DL-LM_Event.ind

Physical Layer

Data Link Layer

AL Mgmt. Services

PH Layer Mgmt. Services

Connect/Disconnect/ Data related services

PH-DATA.req/.ind PH-ABORT.ing

Layer Management Process

ASO Services

Application Process Physical Connection Manager Process

Phys

ical

Con

nect

/Dis

conn

ect

Figure 25 - 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/TR2 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 26 shows ‘minimal’ COSEM ASOs, containing only the three mandatory components.

COSEM client ASO

Client control function

COSEM client ASO servicesReferencing by Logical Name

Supporting layer services

Client xDLMS_ASE

Client ACSE

COSEM client application process

COSEM server ASO

COSEM server ASO services


ServerxDLMS_ASE

Server ACSE

COSEM server application process

COSEM server application layer

Pro

toco

l A

pplic

atio

ns

(com

mun

icat

ions

) (in

terfa

ce o

bjec

ts)

WAN, LAN

Server control function

Supporting layer and

other protocol layers



Referencing by Logical Name

COSEM client application layer

Figure 26 – 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 – e.g. 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 (or IEC 62056-62) 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 (e.g. 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 27 shows the COSEM client application layer when the server is using SN referencing. The additional component is called SN_MAPPER_ASE.

COSEM client ASO Client control function

COSEM client ASO servicesReferencing by Logical Name


Client xDLMS_ASE Client

ACSE

COSEM client application process

COSEM client application layer COSEM server ASO

COSEM server ASO services


ServerxDLMS_ASE

Server ACSE

COSEM server application process

COSEM server application layer

Prot

ocol

A

pplic

atio

ns

(com

mun

icat

ions

) (in

terfa

ce o

bjec

ts)

WAN, LAN

Client SN_MAPPER

Referencing byShort Name

Server control function





Figure 27 – 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. The specific SetMapperTables service is separately defined.




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 28.

XX

.req

ZZ.in

dZZ

.resXX

.cnf

Even

tNot

ifica

tion.

req

orIn

form

atio

nRep

ort.r

eq

COSEM clientapplication process

COSEM serverapplication process

Application layer

ZZ.response

ZZ.request

Even

tNot

ifica

tion.

ind

EventNotification

CO

SE

M-O

PE

N.re

qC

OSE

M-O

PEN

.cnf

CO

SE

M-R

ELE

AS

E.re

qC

OSE

M-R

ELE

ASE.

cnf

CO

SE

M-A

BOR

T.in

d

CO

SE

M-O

PE

N.re

sC

OSE

M-R

ELE

ASE.

ind

CO

SE

M-R

ELE

AS

E.re

s

CO

SE

M-A

BOR

T.in

d

Trig

g_Ev

entN

otif.

req

CO

SE

M-O

PE

N.in

d

Figure 28 – Summary of COSEM application layer services

NOTE In the figure above, XX and ZZ refers to client/server type data communication services. These services may be different on the client side and the server side, if the server does not use LN referencing. See 9.2.4.




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.9 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 29.

Clientapplication layer

Serverapplication layer

COSEM-OPEN.request

COSEM-OPEN.indication

COSEM-OPEN.response

COSEM-OPEN.confirm

time

Figure 29 – 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 29. 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 purpose 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 purpose 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-

9 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 – e.g. 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 (e.g. 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.10

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 (referred to as XX on Figure 28):

• 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).

10 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 (referred to as ZZ on Figure 28).

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, see – 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/TR2 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 30 shows the state machine for the client side control function (CF, see Figure 26).




IDLE

ASSOCIATIONPENDING

ASSOCIATED

ASSOCIATIONRELEASEPENDING

OPEN.req

/OPEN.cnf(NOK), /ABORT.ind

/OPEN.cnf(OK)

/ABORT.ind

RELEASE.req

/RELEASE.cnf

GET.req /GET.cnf SET.req /SET.cnf ACTION.req /ACTION.cnf /EventReport.ind

Trigger_EventReport_sending.req /EventReport.ind

/ABORT.ind

INACTIVE

Figure 30 – Partial state machine for the client side control function 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.

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 established11. 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

11 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 31 shows the state machine for the server side control function, see Figure 26.

IDLE

ASSOCIATION /PENDING

ASSOCIATED

ASSOCIATION RELEASE PENDING

/OPEN.ind

OPEN.res(NOK), /ABORT.ind

OPEN.res(OK)

/ABORT.ind

/RELEASE.ind

RELEASE.res

/GET.ind GET.res /SET.ind SET.res /ACTION.ind ACTION.res

EventReport.reqor

InformationReport.req

/ABORT.ind

INACTIVE

/READ.ind READ .res /WRITE.ind WRITE .res /UNCONFIRMED WRITE.ind

or

Figure 31 – 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/TR2 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 AP12. 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 32 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.

12 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.




ClientApplication

Process

Client Application LayerControl Function is in

IDLE State

ClientApplication

Layer -Control

Function

ServerApplication

Layer-xDLMS

ServerApplication

Layer-ACSE

ServerApplication

Layer -Control

Function

ServerApplication

Process

Physical connection is established (outside the protocol)

ServersupportingProtocol

Layer(XX)

ClientsupportingProtocol

Layer(XX)

ClientApplication

Layer-xDLMS

ClientApplication

Layer-ACSE

COSEM-OPEN.req

Client Application Layer ControlFunction is in ASSOCIATION

PENDING State XX-CONNECT.req

Server ApplicationLayer Control Function

is in IDLE State

Establishingthe Supporting

Layerconnection

EstablishingLower Layerconnections

XX-CONNECT.ind

XX-CONNECT.res

XX-CONNECT.cnf

The Supporting Layer connection is established

xDLMS-Initiate.req

Build an xDLMS-Initiate.req PDU

xDLMS-Initiate.req PDUA-ASSOCIATE.req

Build an AARQ APDUAARQ-pdu XX-DATA.request(AARQ)

XX-DATA.indication(AARQ)AARQ APDU

Extract A-ASSOCIATE.ind

parametersA-ASSOCIATE.ind

xDLMS-Initiate.ind PDU

Extract xDLMS-Initiate.indparameters xDLMS-Initiate.ind COSEM-

OPEN.indServer Application Layer Control

Function is in ASSOCIATIONPENDING state

COSEM-OPEN.resxDLMS-Initiate.res

Build xDLMS-Initiate.res PDU

xDLMS-Initiate.res PDUA-ASSOCIATE.res

Build AARE APDUAARE APDU

Client Application Layer ControlFunction is in ASSOCIATED state

XX-DATA.ind(AARE)XX-DATA.req(AARE)

AARE APDU

Set Application Context

Set DLMS Context

xDLMS-Initiate.res PDU

xDLMS-Initiate.cnf

A-ASSOCIATE.cnf

The requested Application Association is successfully established

COSEM-OPEN.cnf(OK)

Server Application Layer ControlFunction is in ASSOCIATED

state

Figure 32 - 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 APDU13, 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 not14.

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.


13 Some service parameters of this COSEM-OPEN.indication primitive (address information, User_Information, Service_Class) do not come from the AARQ APDU, but from the supporting layer frame carrying the AARQ APDU. 14 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.

cosem architecture and protocols - dlms · data link layer using hdlc-protocol ... • terms are...

Documents