Reference number: EXCERPT FROM DLMS UA 1000-2:2005, Fifth Edition © Copyright 1997-2005 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, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 2/55
© Copyright 1997-2005 DLMS User Association
Table of Contents 1. Foreword ......................................................................................................................................................................4 2. Scope ............................................................................................................................................................................5 3. Introduction ..................................................................................................................................................................6 3.1 The COSEM communications framework ....................................................................................................................6 3.1.1 Client/server type operation, communication profiles ................................................................................................6 3.1.2 Connection (association) oriented operation .............................................................................................................7 3.2 Interoperability and interconnectivity in COSEM ..........................................................................................................8 3.3 Ensuring interconnectivity: the protocol identification service.......................................................................................9 3.4 Referenced documents ................................................................................................................................................10 3.5 Terms, definitions and abbreviations............................................................................................................................11 4. Architecture for meter data exchange........................................................................................................................14 4.1 General ........................................................................................................................................................................14 4.2 Application models .......................................................................................................................................................14 4.3 Communication models................................................................................................................................................14 4.4 Model of DLMS/COSEM servers..................................................................................................................................16 4.5 Model of a DLMS/COSEM based client .......................................................................................................................17 4.6 Model of a DLMS/COSEM based data collection system.............................................................................................18 4.7 Access requirements....................................................................................................................................................20 4.8 System integration and meter installation.....................................................................................................................21 4.9 Migration ......................................................................................................................................................................21 5. Physical layer services and procedures for connection oriented asynchronous data exchange ........................22 5.1 Overview ......................................................................................................................................................................22 5.2 Service specification ....................................................................................................................................................23 5.2.1 List of services ..........................................................................................................................................................23 5.2.1.1 Connection establishment/release related services ...............................................................................................23 5.2.1.2 Data communication services ................................................................................................................................23 5.2.1.3 Layer management services ..................................................................................................................................23 5.2.2 Use of the physical layer services .............................................................................................................................24 6. Direct Local Connection (excerpt)..............................................................................................................................25 6.1 METERING HDLC protocol using protocol mode E for direct local data exchange......................................................25 6.1.1 Overview ...................................................................................................................................................................26 6.1.2 Readout mode and programming mode....................................................................................................................26 6.2 Key to protocol mode E flow diagram...........................................................................................................................27 6.3 Physical layer - Introduction .........................................................................................................................................28 7. COSEM transport layers for IPv4 networks ...............................................................................................................29 7.1 Scope...........................................................................................................................................................................29 7.2 Overview ......................................................................................................................................................................29 7.3 The COSEM connection-less, UDP-based Transport layer..........................................................................................31 7.3.1 General .....................................................................................................................................................................31 7.4 The COSEM connection-oriented, TCP-based Transport layer ...................................................................................32 7.4.1 General .....................................................................................................................................................................32 7.5 Converting OSI-style transport layer services to and from RFC-style TCP function calls.............................................33 7.5.1 Transport layer and TCP connection establishment..................................................................................................33 7.5.2 Closing a transport layer and a TCP connection .......................................................................................................34 7.5.3 TCP connection abort ...............................................................................................................................................35 7.5.4 Data communication – the TCP-DATA service .........................................................................................................35 8. Data Link Layer using HDLC-Protocol .......................................................................................................................38 8.1 Overview ......................................................................................................................................................................38 8.2 Overview of the data link layer specification.................................................................................................................38 8.2.1 The LLC sub-layer.....................................................................................................................................................38 8.2.2 The MAC sub-layer ...................................................................................................................................................38 8.2.3 Specification method.................................................................................................................................................39 8.3 The LLC sub-layer........................................................................................................................................................39 8.3.1 The role of the LLC sub-layer....................................................................................................................................39 8.3.2 Service specification for the LLC sub-layer ...............................................................................................................40 8.3.2.1 Setting up the data link connection ........................................................................................................................40 8.3.2.1.1 Overview .............................................................................................................................................................40 8.4 The MAC sub-layer ......................................................................................................................................................41 8.4.1 HDLC selections .......................................................................................................................................................41 8.4.2 Service specification for the MAC sub-layer..............................................................................................................41 8.4.2.1 Setting up the MAC connection..............................................................................................................................41
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 3/55
© Copyright 1997-2005 DLMS User Association
8.4.2.1.1 Overview.............................................................................................................................................................41 8.5 Data link layer management services ..........................................................................................................................42 8.5.1 Overview...................................................................................................................................................................42 9. COSEM application layer ............................................................................................................................................44 9.1 Overview......................................................................................................................................................................44 9.1.1 Specification method.................................................................................................................................................44 9.1.2 Application layer structure.........................................................................................................................................44 9.1.3 Service specification .................................................................................................................................................45 9.1.3.1 Services provided for application association establishment and release..............................................................45 9.1.3.2 Data communication services ................................................................................................................................45 9.1.4 Layer management services.....................................................................................................................................46 9.1.5 Protocol specification ................................................................................................................................................47 9.2 COSEM application layer – Service specification ........................................................................................................47 9.2.1 Summary of services ................................................................................................................................................47 9.2.2 Application association establishment and release...................................................................................................48 9.2.3 Special application associations ...............................................................................................................................48 9.2.3.1 Confirmed application associations........................................................................................................................48 9.2.3.2 Non-confirmed application associations.................................................................................................................48 9.2.3.3 Pre-established application associations ...............................................................................................................49 9.2.3.4 Mandatory application associations .......................................................................................................................49 9.2.4 Data communication .................................................................................................................................................49 9.3 COSEM application layer protocol specification...........................................................................................................50 9.3.1 State definitions for the client side control function ...................................................................................................50 9.3.2 State definitions for the server side control function..................................................................................................52 9.3.3 Protocol for application association establishment/release.......................................................................................53 9.3.3.1 Establishment of a confirmed application association............................................................................................53
Figures Figure 1 – The three steps approach of COSEM: Modelling - Messaging - Transporting....................................................5 Figure 2 – Client / server relationship in COSEM ................................................................................................................6 Figure 3 – Exchanging messages via the communication protocol .....................................................................................6 Figure 4 – The COSEM application layer on the top of various lower layer stacks..............................................................7 Figure 5 – A complete communications session in the CO environment .............................................................................8 Figure 6 – DLMS/COSEM application model of a data collection system and metering equipment .................................. 14 Figure 7 – Communication profile models in DLMS/COSEM............................................................................................. 15 Figure 8 – DLMS/COSEM server model............................................................................................................................ 17 Figure 9 – Model of a DLMS/COSEM based client using multiple protocol stacks ............................................................ 18 Figure 10 – Model of a DLMS/COSEM based meter data collection system..................................................................... 19 Figure 11 – Typical PSTN configuration ............................................................................................................................ 22 Figure 12 – The location of the physical layer.................................................................................................................... 23 Figure 13 – Protocol layer services of the COSEM 3-layer connection-oriented profile..................................................... 24 Figure 14 – Entering protocol mode E (HDLC) .................................................................................................................. 26 Figure 15 – Flow chart and switchover to METERING HDLC in protocol mode E ............................................................. 27 Figure 16 – Physical layer primitives ................................................................................................................................. 28 Figure 17 – Physical layer primitives, simplified example with one mode change only...................................................... 28 Figure 18 – COSEM as a standard Internet application protocol ....................................................................................... 30 Figure 19 – Transport layers of the COSEM_on_IP profile................................................................................................ 31 Figure 20 – TCP connection state diagram ....................................................................................................................... 33 Figure 21 – MSC and state transitions for establishing a transport layer and TCP connection.......................................... 34 Figure 22 – MSC and state transitions for closing a transport layer and TCP connection ................................................. 35 Figure 23 – Polling the TCP sub-layer for TCP abort indication ........................................................................................ 35 Figure 24 – Sending an APDU in three TCP packets ........................................................................................................ 36 Figure 25 – Receiving the message in several packets..................................................................................................... 37 Figure 26 – Data link (LLC) services for setting up the data link connection ..................................................................... 40 Figure 27 – MAC sub-layer services for setting up the MAC (DL) connection at the client and server sides..................... 42 Figure 28 – Layer management services........................................................................................................................... 43 Figure 29 – The structure of the COSEM application layers.............................................................................................. 44 Figure 30 – Structure of the COSEM AL when the server is using SN references ............................................................ 46 Figure 32 – Summary of COSEM application layer services ............................................................................................. 47 Figure 33 – Normal service sequence for the COSEM-OPEN service .............................................................................. 48 Figure 34 – Partial state machine for the client side control function ................................................................................. 51 Figure 35 – Partial state machine for the server side control function ............................................................................... 52 Figure 36 - MSC for successful application association establishment preceded by a successful lower layer connection establishment .................................................................................................................................................................... 54
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 4/55
© Copyright 1997-2005 DLMS User Association
1. Foreword
Copyright © Copyright 1997-2005 DLMS User Association.
This document is confidential. It may not be copied, nor handed over to persons outside the standardisation environment.
The copyright is enforced by national and international law. The "Berne Convention for the Protection of Literary and Artistic Works", which is signed by 121 countries worldwide, and other treaties apply.
Acknowledgement The actual document has been established by a team of experts working for members of the DLMS User Association and by working group members of standardisation bodies, for example IEC TC13 WG14, CEN TC294 WG2 and IEC TC57 WG9.
Status of standardization This fifth edition of the "Green Book" includes the specification of the communication protocol layers based on:
IEC 62056-42, Electricity metering - Data exchange for meter reading, tariff and load control - Part 42: Physical layer services and procedures for connection-oriented asynchronous data exchange;
IEC 62056-46 Ed 1.0, Electricity metering - Data exchange for meter reading, tariff and load control - Part 46: Data link layer using HDLC protocol, as amended by 13/1336/CDV, draft Amendment 1;
draft IEC 62056-47 Ed.1.0, 13/1337/CDV, Electricity metering - Data exchange for meter reading, tariff and load control - Part 47: COSEM transport layers for IPv4 networks
draft IEC 62056-53 ed. 2.0, 13/1338/CDV, Electricity metering - Data exchange for meter reading, tariff and load control - Part 53: COSEM application layer
Annex E of IEC 62056-21, Electricity metering - Data exchange for meter reading, tariff and load control Part 21: Direct local data exchange, is incorporated (Clause 6).
For easier use, in this edition, changes compared to Edition 4 are marked by highlighted text.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 5/55
© Copyright 1997-2005 DLMS User Association
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.
- The application layer, data link layer, transport layer and physical layer are described in this document. - Conformance testing: see specification DLMS UA 1001-1 "COSEM Conformance Test Process". - Terms are explained in DLMS UA 1002 "COSEM Glossary of Terms".
3. 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
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 6/55
© Copyright 1997-2005 DLMS User Association
3. Introduction
3.1 The COSEM communications framework
3.1.1 Client/server type operation, communication profiles Communication with metering equipment using the COSEM interface object model is based on the client/server paradigm, where metering equipment 1 plays the server role. In this environment, communication takes place always between a client and a server application process: in other words, the server application process provides remote services to the client application process. These services are provided via exchanging messages (SERVICE.requests / .responses) between the client and the server application processes, as it is shown in Figure 2.
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
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 7/55
© Copyright 1997-2005 DLMS User Association
In general, communication protocols are structured in layers. The client and server COSEM applications use services of the highest protocol layer, that of the application layer: Consequently, this is the only protocol layer containing COSEM specific element(s). This is called the xDLMS_ASE. All COSEM interface object related services – the xDLMS application protocol – are provided by this xDLMS_ASE.
Other protocol layers are independent from the COSEM model, consequently the COSEM application layer can be placed on the top of a wide variety of lower protocol layer stacks, as it is shown in Figure 4.
Figure 4 – The COSEM application layer on the top of various lower layer stacks
A complete protocol stack – including the application layer, a physical layer and all protocol layers between these extreme layers – is called a communication profile.
A communication profile is characterized by the protocol layers included, their parameters, and by the type – connection-oriented or connectionless – of the ACSE 2 included in the application layer.
3.1.2 Connection (association) oriented operation The xDLMS application protocol is a connection-oriented protocol. It means, that the client and server application processes can use the services of the xDLMS_ASE only when these application processes are associated 3. Therefore, in this environment a communication session consists of three phases, as it is shown in Figure 5.
2 ACSE = Association Control Service Element 3 Application associations can be considered as application level connections.
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
………
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 8/55
© Copyright 1997-2005 DLMS User Association
Figure 5 – A complete communications session in the CO environment
In the DLMS/COSEM environment, application association establishment is normally done by using the association request/response services of the standard association control service element. On the other hand, for the purposes of very simple devices, one-way communicating devices and for multicasting and broadcasting, pre-established application associations are also allowed; see Clause 9.2.3.3. For such associations, there is no need to use the services of the ACSE: a full communication session may include only the data communication phase. (It can be considered that the connection establishment phase has been already done somewhere in the past.)
3.2 Interoperability and interconnectivity in COSEM
In the COSEM environment, interoperability and interconnectivity is defined between a server and a client application processes. A client and a server must be interconnectable and interoperable to ensure data exchange between the two systems.
Interoperability is an application level notion: a client application is interoperable with a server application, if it is able to establish application associations using the Association.request/ .indication/ .response/ . confirm services of the standard connection-oriented ACSE, as it is specified in the clause describing the COSEM application layer.
Using these services, application associations may be established between a client and a server or between a client and different servers using various contexts concerning the authentication mechanism, the xDLMS services available and other parameters. For example, the client may establish an AA with a server in an xDLMS context using short name (SN) referencing and with another server in an xDLMS context using logical name (LN) referencing. Although the messages exchanged depend on the context of the application association established, both servers are interoperable with the client, if it is able to establish the application association using the right context with both servers.
With this, using the services of the standard ACSE for application association establishment ensures interoperability in COSEM.
On the other hand, interconnectivity is a protocol level notion: in order to be able to exchange messages the client and the server application processes should be interconnectable and interconnected.
Two application processes are interconnectable if they use the same communication profile. Before the two application processes can establish an application association, they must be interconnected first. The two application processes are interconnected, if each peer protocol layers of both sides, which need to be connected, are connected.
Client application Server application
Phase 1. Connection establishment
Phase 2. Data communication
Phase 3. Connection releaset
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 9/55
© Copyright 1997-2005 DLMS User Association
Therefore, in order to be interconnected, the client and server application processes should be interconnectable and shall establish the required connections.
With this, interconnectivity in DLMS/COSEM is ensured by the ability of the COSEM application process to establish a connection between all peer layers, which need to be connected.
3.3 Ensuring interconnectivity: the protocol identification service
In DLMS/COSEM, application association establishment between a server and a client is always initiated by the client. However, in some cases, the client application process may not have knowledge about the protocol stack used by an unknown server device (for example when the server has initiated the physical connection establishment). In such cases, the client must obtain information about the protocol stack implemented in the server. The COSEM framework provides a specific, application level service to for this purpose: the protocol identification service.
It is an optional application level service, which allows the client to obtain information, after establishing a physical connection, about the protocol stack implemented in the server. The protocol identification service uses directly the data communication services (PH-DATA.request/.indication) of the physical layer; it bypasses the remaining part of the protocol.
It is recommended to support it in all communication profiles using this Physical layer.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 10/55
© Copyright 1997-2005 DLMS User Association
3.4 Referenced documents Ref. Title
DLMS UA 1000-1 Ed. 7.0:2005
COSEM Identification System and Interface Objects, "Blue Book"
DLMS UA 1001-1 Ed. 2.0:2002
COSEM Conformance Test Process, "Yellow Book"
DLMS UA 1002 Ed. 1.0:2003 COSEM Glossary of Terms, "White Book"
IEC 61334-4-41 Ed.1.0: 1996 Distribution automation using distribution line carrier systems - Part 4: Data communication protocols - Section 41: Application protocol - Distribution line message specification
IEC 61334-6 Ed 1.0: 2000 Distribution automation using distribution line carrier systems – Part 6: A-XDR encoding rule
IEC 62056-21 Ed 1.0: 2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 21: Direct local data exchange
IEC 62056-31 Ed 1.0 :1999 Electricity metering – Data exchange for meter reading, tariff and load control – Part 31: Use of local area networks on twisted pair with carrier signalling
IEC 62056-42 Ed.1.0: 2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 42: Physical layer services and procedures for connection-oriented asynchronous data exchange
IEC 62056-46 Ed.1.0:2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 46: Data link layer using HDLC protocol
Amendment 1: 200X 13/1336/CDV
Draft IEC 62056-47 Ed 1.0 13/1337/CDV
Electricity metering – Data exchange for meter reading, tariff and load control – Part 47: COSEM transport layer for IP networks
IEC 62056-53 Ed 2.0: 200X 13/1338/CDV
Electricity metering – Data exchange for meter reading, tariff and load control – Part 53: COSEM application layer
IEC 62056-61 Ed 2.0: 200X, 13/1341/CDV
Electricity metering – Data exchange for meter reading, tariff and load control – Part 61: OBIS Object identification system
IEC 62056-62 Ed 2.0: 200X, 13/1342/CDV
Electricity metering – Data exchange for meter reading, tariff and load control – Part 62: Interface classes
ISO/IEC 8649 Ed. 2.0: 1996 Information technology - Open Systems Interconnection - Service definition for the Association Control Service Element
ISO/IEC 8650-1 Ed 2.0: 1996 Information technology - Open systems interconnection - Connection-oriented protocol for the association control service element: Protocol specification
ISO/IEC 8802-2 Ed. 3.0: 1998 Information technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Specific requirements – Part 2: Logical link control
ISO/IEC 8824: 1990 Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)
ISO/IEC 8825: 1990 Information technology - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)
ISO/IEC 13239: Ed. 3.0: 2002 Information Technology - Telecommunications and information exchange between systems – High-level data link control (HDLC) procedures
EN 13757-2 Ed. 1.0: 2004 Communication system for and remote reading of meters - Part 2 : Physical and Link Layer, Twisted Pair Baseband (M-Bus)
NEMA C12.21: 1999 Protocol Specification for Telephone Modem Communication
STD0005 (1981) Internet Protocol. Also: RFC0791, RFC0792, RFC0919, RFC0922, RFC0950, RFC1112
STD0006 (1980) User Datagram Protocol. Also: RFC0768
STD0007 (1981) Transmission Control Protocol. Also: RFC0793
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 11/55
© Copyright 1997-2005 DLMS User Association
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)
DCS Data Collection System
DISC Disconnect (a HDLC frame type)
DLMS Device Language Message Specification
DM Disconnected Mode (a HDLC frame type)
DPDU Data Link Protocol Data Unit
DSAP Data Link Service Access Point
DSDU Data Link Service Data Unit
DTE Data Terminal Equipment (computers, terminals or printers)
FCS Frame Check Sequence
FDDI Fibre Distributed Data Interface
FRMR Frame Reject (a HDLC frame type)
FTP File Transfer Protocol
GMT Greenwich Mean Time
GSM Global System for Mobile communications
HCS Header Check Sequence
HDLC High-level Data Link Control
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 12/55
© Copyright 1997-2005 DLMS User Association
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
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 13/55
© Copyright 1997-2005 DLMS User Association
RLRE Application Association Release Response
RLRQ Application Association Release Request
RNR Receive Not Ready (a HDLC frame type)
RR Receive Ready (a HDLC frame type)
SAP Service Access Point
SDU Service Data Unit
SNMP Simple Network Management Protocol
SNRM Set Normal Response Mode (a HDLC frame type)
server A station, delivering services. The tariff device (meter) is normally the server, delivering the requested values or executing the requested tasks.
slave Station responding to requests of a master station. The tariff device (meter) is normally a slave station.
TCP Transmission Control Protocol
TWA Two Way Alternate
UA Unnumbered Acknowledge (a HDLC frame type)
UDP User Datagram Protocol
UI Unnumbered Information (a HDLC frame type)
UNC Unbalanced operation Normal response mode Class
USS Unnumbered Send Status
VAA Virtual Application Association
V(R) Receive state Variable
V(S) Send state Variable
WPDU Wrapper Protocol Data Unit
xDLMS-ASE Extended DLMS Application Service Element
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 14/55
© Copyright 1997-2005 DLMS User Association
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 #0nCOSEM 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.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 15/55
© Copyright 1997-2005 DLMS User Association
NOTE Data exchange between the logical devices within a physical device may be possible. Similarly, data exchange between the application processes of a single client or between clients may be possible. Such exchanges are out of the scope of this specification.
To transport data over various media, communication protocols are required. For such protocols, DLMS/COSEM has chosen a layered approach, where a communication protocol comprises several layers, with each layer having distinct tasks, and each layer providing services to the upper layer and using services of its supporting layer(s). The number and type of layers depend on the communication media used.
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;
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 16/55
© Copyright 1997-2005 DLMS User Association
- the TCP-UDP/IP based communication profiles. These profiles support data exchange via the Internet over various physical media, like Ethernet, ISDN, GPRS, PSTN or GSM using PPP etc. In these profiles, the COSEM application layer is supported by the COSEM transport layer(s), comprising a wrapper and the internet TCP or UDP protocol. Lower layers can be selected according to the media to be used, as the TCP-UDP layers hide their particularities.
Further communication profiles to support other media, like twisted pair using base band signalling (MBUS, EN 13757-2), twisted pair using carrier signalling (EURIDIS, IEC 62056-31), or power line carrier (PLC) can be easily developed. The elements to be specified in each communication profile are given in Subclause “Communication profile specific elements” of the COSEM application layer specification.
In DLMS/COSEM, data exchange on the application level is always connection-oriented:
- to be able to exchange application data, an application level connection, called Application Association (AA) has to be established between a client AP and a server logical device. This is the task of the connection-oriented Association Control Service Element (ACSE) of the application layer;
- before initiating the establishment of an AA, the peer physical layers of the client and server side protocol stacks have to be connected. The intermediate layers may have to be connected or not. Each layer, which needs to be connected, may support one or more connections simultaneously;
- once the necessary AA(s) are established, application data exchange can take place, by accessing attributes and methods of the COSEM interface objects. This is the task of the xDLMS service element;
- at the end of the data exchange, the AA(s) have to be released.
4.4 Model of DLMS/COSEM servers
The figure below shows the model of two DLMS/COSEM servers. One of them uses a 3-layer, connection-oriented, HDLC-based communication profile, and the other one uses a TCP-UDP/IP based communication profile.
DLMS/COSEM meterusing TCP-UDP/IP based profile
DLMS/COSEM meter using 3-layer, CO, HDLC based profile
COSEM Transport layer
COSEM Application 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
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 17/55
© Copyright 1997-2005 DLMS User Association
Figure 8 – DLMS/COSEM server model
The metering equipment on the left hand side comprises “n” logical devices and supports the 3-layer, connection-oriented, HDLC-based communication profile.
The COSEM application layer is supported by the HDLC-based data link layer. Its main role is to provide a reliable data transfer between the peer layers. It also provides addressing of the logical devices in such a way, that each logical device is bound to a single HDLC address, with the Management logical device always being bound to the HDLC address 0x01. To allow creating a LAN so that several metering devices at a given metering site can be reached through a single access point, another address, the physical address is also provided by the data link layer. The logical device addresses are also referred to as upper HDLC addresses, while the physical device address is also referenced as a lower HDLC address.
The physical layer supporting the data link layer provides serial bit transmission between physical devices hosting the client and server applications. This allows using various interfaces, like RS 232, RS 485, 20 mA current loop, etc. to transfer data locally through PSTN and GSM networks etc.
The metering equipment on the right hand side comprises “m” logical devices.
The COSEM application layer is supported by the COSEM transport layer, comprising the internet TCP or UDP layer and a wrapper. The main role of the wrapper is to adapt the OSI-style service set, provided by the COSEM transport layer to and from TCP and UDP function calls. It also provides addressing for the logical devices, binding them to a SAP called wrapper port, with the Management logical device always being bound to wrapper port 0x01. Finally, the wrapper provides information about the length of the APDUs transmitted, to help the peer to recognise the end of the APDU. This is necessary due the streaming nature of TCP.
Through the wrapper, the COSEM application layer is bound to a TCP or UDP port number, which is used for the DLMS/COSEM protocol and application. The presence of the TCP and UDP layers allows incorporating other internet applications, like FTP or HTTP, bound to their standard ports respectively.
The TCP layer is supported by the IP layer, which is in turn may be supported by any set of lower layers depending on the communication media to be used (for example Ethernet, PPP, IEEE 802 etc.).
Obviously, in a single server it is possible to implement several protocol stacks, with the common COSEM application layer being supported by distinct sets of lower layers. This allows the server to exchange data via various communication media with clients in different application associations. Such a structure would be similar to the structure of a DLMS/COSEM client show below.
4.5 Model of a DLMS/COSEM based client
Figure 9 shows the model of a Data Collection System based on DLMS/COSEM.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 18/55
© Copyright 1997-2005 DLMS User Association
DLMS/COSEM data collection systemusing both 3-layer, CO, HDLC based and TCP-UDP/IP based communication profile
COSEM Transport layer
COSEM Application 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.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 19/55
© Copyright 1997-2005 DLMS User Association
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 physical device 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 for example 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 (EN 13757-2), Euridis (IEC 62056-31) or PLC are also possible.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 20/55
© Copyright 1997-2005 DLMS User Association
The architecture of the two remote data collection systems is identical. Both systems can reach both metering sites via either the internet or a PSTN or GSM WAN.
The address of the physical device hosting the client APs is provided by the WAN. The Application Process address identifies the type of the client only, for example address 0x10 is the address of the Public Client in each DCS.
Although in the client/server environment data exchange is generally initiated by the client, DLMS/COSEM provides a non client/server type service, called Event Notification to allow the server to notify the client about an occurrence of an event in the server.
4.7 Access requirements
DLMS/COSEM meets the following access requirements for data exchange:
- it allows various parties (data collection systems) to have access to metering data; - it allows to exchange data with a single or multiple metering equipment at a metering site; - in case of multiple metering equipment at a metering site, a single access point is available; - it is possible to exchange data with metering equipment either remotely or locally; - depending on the resources of the metering equipment, local and remote data exchange may be
performed without interfering with each other; - it is possible to use various communication media both on local area networks (LAN) and wide area
networks (WAN); - it provides authentication mechanisms to control access to data, these mechanisms are made available
by the COSEM application layer and the interface objects (Association object); - it supports easy system integration and meter deployment; - it provides a migration path from legacy systems to DLMS/COSEM based systems. The key element to ensure that the above requirements are met is the Application Association provided by the COSEM application layer. For details, see the relevant clauses of this book.
Below, two aspects are dealt with in some detail.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 21/55
© Copyright 1997-2005 DLMS User Association
4.8 System integration and meter installation
System installation is supported by DLMS/COSEM in a number of ways.
As shown in Figure 9, the presence of a Public Client (bound to address 0x10 in any profile) is mandatory in each client system. Its main role is to reveal the structure of an unknown (for example newly installed) metering equipment. This takes place within a mandatory application association between the public client and the management logical device (see Figure 10), with no security precautions. Once the structure is known, data can be accessed with using the proper authentication mechanisms.
When a new meter is installed in the system, it may generate an event report to the client. Once this is detected, the client can read the internal structure of the meter, and then download the necessary configuration information (for example tariff schedules and installation specific parameters) to the meter. With this, the meter is ready to use.
System integration is also facilitated by the availability of the DLMS/COSEM conformance testing, described in the Yellow Book. With this, correct implementation of the specification in metering equipment can be tested and certified.
4.9 Migration
By today, there are thousands of data collection systems - based on legacy protocols, for example IEC 61107 (or IEC 1107 before) – installed. Obviously, a migration path is necessary.
DLMS/COSEM provides this by adding a new protocol mode “E” to the IEC 62056-21 standard (was IEC 1107). With this, during the opening sequence, the meter (server) is able to advise the HHU (client), that the advanced Mode E is available. If the HHU acknowledges it, they will continue the data exchange using the 3-layer, CO, HDLC-based protocol. The information exchange takes place then using the COSEM object model. If not, data exchange continues in the conventional Mode C, although the functionality may be limited.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 22/55
© Copyright 1997-2005 DLMS User Association
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 (primary station), taking the initiative and controlling the data flow. The tariff device is the slave (secondary station), responding to the master station.
From the application point of view, the central station normally acts as a client asking for services, and the metering equipment acts as a server delivering the requested services.
The situation involving a caller client and a called server is undoubtedly the most frequent case, but a communication based on a caller server and a called client is also possible, in particular to report the occurrence of an urgent alarm.
For the purposes of local data exchange, two DTEs can be directly connected using appropriate connections. To allow using a wide variety of media, this document does not specify the physical layer signals and their characteristics. However, the following assumptions are made:
- the communication is point to point or point to multipoint; - both half-duplex and duplex connections are possible; - asynchronous transmission with 1 start bit, 8 data bits, no parity and 1 stop bit (8N1).
COSEM client COSEM server
DTE DTE DCE DCE
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 23/55
© Copyright 1997-2005 DLMS User Association
From the internal point of view, the physical layer is the lowest layer in the protocol stack.
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
Transit network
DTE
Data comm.
equipment (DCE)
COSEM client COSEM server
Client application
Application layer
Data Link layer
Physical layer
Pro
toco
l
DTE
Serverapplication
Applicationlayer
Data Linklayer
Physicallayer
Pro
toco
l
Data comm.
equipment (DCE)
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 24/55
© Copyright 1997-2005 DLMS User Association
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.
Figure 13 – Protocol layer services of the COSEM 3-layer connection-oriented profile
As it is shown in Figure 13, the connection establishment/release services are used by and provided for the physical connection manager application process, and not the data link layer. more details, see complete Green Book ....
Application layer
Physical layer
Data link layer
AL management services
Connect/disconnect anddata related services
Layer managementprocess
ASO services
Application processPhysical
connectionmanager
Pro
toco
lA
pplic
atio
n
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
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 25/55
© Copyright 1997-2005 DLMS User Association
6. Direct Local Connection (excerpt)
This chapter is an excerpt of IEC 62056-21 describing hardware and protocol specifications for local meter data exchange. In such systems, a hand-held unit (HHU) or a unit with equivalent functions is connected to a tariff device or a group of devices.
Only COSEM related items are described here. The complete information can be found in IEC 62056-21.
6.1 METERING HDLC protocol using protocol mode E for direct local data exchange
The protocol stack as described in Clauses 4.1, 8 and 0 of this document shall be used.
The switch to the baudrate Z shall be at the same place as for protocol mode C. The switch confirm message, which has the same structure as the acknowledgement/option select message, is therefore at the new baud rate but still with parity (7E1). After the acknowledgement, the binary mode (8N1) will be established.
As the server acknowledgement string is a constant in the server's program, it could be easily possible to switch to the baud rate and the binary mode (Z Bd. 8N1) at the same time. The characters ACK 2 Z 2 CR LF shall be replaced by their 8 bit equivalents by adding the correct parity bit in order to simulate their 7E1 equivalents. This alternative method is not visible to the client; both have an equivalent behaviour (see also Figure 17).
A client, which is not able to support protocol HDLC mode E (W=2) will answer in a protocol mode as defined by Y (normally protocol mode C).
The enhanced capability of the server (tariff device) is communicated with the escape sequence "\W" which is part of the meter identification string (see items 14), 23) and 24) in IEC 62056-21, Clause 6.3.14) 4.
4 W = @ is used for country specific applications
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 26/55
© Copyright 1997-2005 DLMS User Association
6.1.1 Overview
/ ? 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)
6.1.2 Readout mode and programming mode These modes are handled within the higher layers of the protocol. After having established a transparent channel, the "METERING HDLC protocol" takes care of the correct data handling, and a DLMS based application handles access rights, read only or read/write access etc. Necessary procedures are described in chapters 4.1, 8 and 0. The flow chart and the changeover to HDLC for the direct local data exchange protocol, protocol mode E is shown below.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 27/55
© Copyright 1997-2005 DLMS User Association
Error ?REQUEST
IDENTIFICATION
Acknowledgement
Error ?
V = 2 ?
Supported ?
Y = 2 ?
Dataerror ?
Protocolerror ?
DATA READOUT
Switchover to HDLC until terminated HDLC Acknowledgement
Client(HHU)
Server(Tariff device)
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
HDLC mode
START
W = 2YesSwitchover to protocol mode C until
terminatedNo
Figure 15 – Flow chart and switchover to METERING HDLC in protocol mode E
6.2 Key to protocol mode E flow diagram
Message formats
REQUEST /? Device Address ! CR LF IDENTIFICATION / XXX Z Ident CR LF Acknowledgement ACK 2 Z 2 CR LF DATA READOUT (fall back data readout mode A ) STX DATA ! CR LF ETX BCC NOTE The inactivity time-out period for the tariff device is 60 s to 120 s after which the operation moves from any point to the start.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 28/55
© Copyright 1997-2005 DLMS User Association
6.3 Physical layer - Introduction
The framework is equivalent to "Physical layer services and procedures for connection-oriented asynchronous data exchange" (see Clause 4.1).
DTE (Client)
PH-LayerDTE (Server)
PH-Layerset mode to 300 baud, 7,E,1
Send “/ ? Device Address ! CR LF”PH-CONNECT.request
Send “/ X X X Z \ 2 Ident CR LF”
change mode to Z baud, 7,E,1
Send “ACK 2 Z 2 CR LF”
Send “ACK 2 Z 2 CR LF”PH-CONNECT.confirm PH-CONNECT.indication
change mode to Z baud, 8,N,1PH-DATA.request
Send Data FramePH-DATA.indication
PH-DATA.indication Send Data FramePH-DATA.request
PH-ABORT.requestSend Break Signal l
PH-ABORT.confirm PH-ABORT.indication
Figure 16 – Physical layer primitives
DTE (Client)
PH-LayerDTE (Server)
PH-Layerset mode to 300 baud, 7,E,1
Send “/ ? Device Address ! CR LF”PH-CONNECT.request
Send “/ X X X 5 \ 2 Ident CR LF”
change mode to 9600 baud, 8,N,1
Send “ACK 2 5 2 CR LF”
Send 06H B2H 35H B2H 8DH 0AHPH-CONNECT.confirm PH-CONNECT.indication
PH-DATA.requestSend Data Frame
PH-DATA.indication
PH-DATA.indication Send Data FramePH-DATA.request
PH-ABORT.requestSend Break Signal l
PH-ABORT.confirm PH-ABORT.indication
Figure 17 – Physical layer primitives, simplified example with one mode change only
more details, see complete Green Book ....
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 29/55
© Copyright 1997-2005 DLMS User Association
7. COSEM transport layers for IPv4 networks
7.1 Scope
This chapter specifies the transport layers for COSEM communication profiles for use on IPv4 networks.
These communication profiles contain a connection-less and a connection-oriented transport layer, providing OSI-style services to the service user COSEM application layer. The connection-less transport layer is based on the Internet standard User Datagram Protocol. The connection-oriented transport layer is based on the Internet standard Transmission Control Protocol.
Although the major part of the COSEM transport layers is the UDP and TCP as they are specified in the relevant Internet standards, they include an additional sub-layer, called wrapper.
Clause 7.5 shows how the OSI-style transport layer services can be converted to and from UDP and TCP function calls.
7.2 Overview
This International Standard specifies two transport layers for the COSEM_on_IP communication profiles: a connection-less transport layer, based on UDP, Internet standard STD0006 and a connection-oriented transport layer, based on TCP, Internet standard STD0007.
In these profiles, the COSEM application layer uses the services of one of these transport layers, which use then the services of the Internet Protocol (IPv4) network layer to communicate with other nodes connected to the abstract IPv4 network.
When used in these profiles, the COSEM application layer can be considered as another Internet standard application protocol (like the well-known HTTP, FTP or SNMP) and it may co-exist with other Internet application protocols, as it is shown in Figure 18.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 30/55
© Copyright 1997-2005 DLMS User Association
...
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 (IPv4)
Data Link Layer
Physical Layer
Standard application protocols
Figure 18 – COSEM as a standard Internet application protocol
As the COSEM application layer specified in Clause 0 uses and provides OSI-style services, a wrapper has been introduced between the UDP/TCP layers and the COSEM application layer.
Therefore, the COSEM transport layers consist of a wrapper sub-layer and the UDP or TCP transport layer.
The wrapper sub-layer is a lightweight, nearly state-less entity: its main function is to adapt the OSI-style service set, provided by the COSEM transport layer, to UDP or TCP function calls and vice versa.
In addition, the wrapper sub-layer has the following functions:
- it provides an additional addressing capability (wPort) on top of the UDP/TCP port; - it provides information about the length of the data transported. This feature helps the sender to send
and the receiver to recognize the reception of a complete APDU, which may be sent and received in multiple TCP packets.
The COSEM application layer is listening only on one UDP or TCP port. On the other hand, as defined in DLMS UA 1000-1, Clause 4.1.5, a COSEM physical device may host several client application processes or server logical devices. The additional addressing capability provided by the wrapper sub-layer allows identifying these application processes.
The structure of the COSEM transport layer and their place in COSEM-on_IP is shown in Figure 19.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 31/55
© Copyright 1997-2005 DLMS User Association
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 19 – Transport layers of the COSEM_on_IP profile
The service user of the both the UDP-DATA and the TCP-DATA services is the COSEM application layer. On the other hand, the service user of the TCP-CONNECT and TCP-DISCONNECT services is the TCP Connection Manager Process. The COSEM TCP-based Transport layer also provides a TCP-ABORT.indication service to the service user COSEM application layer.
7.3 The COSEM connection-less, UDP-based Transport layer
7.3.1 General The COSEM connection-less transport layer is based on the User Datagram Protocol (UDP) as specified in STD0006.
UDP provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. On the one hand, the protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. On the other hand, UDP is simple, it adds a minimum of overhead, it is efficient and easy to use. Several well-known Internet applications, like SNMP, DHCP, TFTP, etc. take advantage of these performance benefits, either because of some datagram applications do not need to be reliable or because the required reliability mechanism is ensured by the application itself. Request/response type applications, like a confirmed COSEM application association established on the COSEM UDP-based Transport layer, then invoking confirmed COSEM data communication services is a good example for this second category. Another advantage of UDP is that being connection-less, it is easily capable of multi- and broadcasting.
UDP basically provides an upper interface to the IP layer, with an additional identification capability, the UDP port number. This allows distinguishing between application processes, hosted in the same physical device and identified by its IPv4 address.
As already mentioned in Clause 7.2, the COSEM application layer is listening only on one UDP port. On the other hand, as defined in DLMS UA 1000-1, Clause 4.1.5, a COSEM physical device may host several client application processes or server logical devices. The additional addressing
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 32/55
© Copyright 1997-2005 DLMS User Association
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.
more details, see complete Green Book ....
7.4 The COSEM connection-oriented, TCP-based Transport layer
7.4.1 General The COSEM connection-oriented transport layer is based on the connection-oriented Internet transport protocol, called Transmission Control Protocol or TCP.
TCP is an end-to-end reliable protocol. This reliability is ensured by a conceptual “virtual circuit”, using a method called “Positive Acknowledgement with Retransmission” or PAR. It provides acknowledged data delivery, error detection, data re-transmission after an acknowledgement time-out, etc., therefore is dealing with lost, delayed, duplicated or erroneous data packets. In addition, TCP offers an efficient flow control mechanism and full-duplex operation, too.
TCP, as a connection-oriented transfer protocol involves three phases: connection establishment, data exchange and connection release. Consequently, the COSEM TCP-based Transport layer provides OSI-style services to the service user(s) for all three phases:
- for the connection establishment phase, TCP-CONNECT services are provided to the service user TCP connection manager process;
- for the data communication phase, TCP-DATA services are provided to the service user COSEM application layer;
- for the connection closing phase, TCP-DISCONNECT services are provided to the service user TCP connection manager process;
- in addition, a TCP-ABORT.indication service is provided to the service user COSEM application layer. The COSEM connection-oriented, TCP-based Transport layer contains the same wrapper sub-layer as the COSEM UDP-based Transport layer. In addition to transforming OSI-style services to and from TCP function calls, this wrapper provides additional addressing and length information.
The COSEM connection-oriented, TCP-based Transport layer is specified in terms of services and protocols.
The conversion between OSI-style services and TCP function calls is presented in Clause 7.5.
more details, see complete Green Book ....
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 33/55
© Copyright 1997-2005 DLMS User Association
7.5 Converting OSI-style transport layer services to and from RFC-style TCP function calls
7.5.1 Transport layer and TCP connection establishment As specified in STD0007, a TCP connection is established by calling the OPEN function. This function can be called in active or passive manner.
According to the TCP connection state diagram (Figure 20) a passive OPEN takes the caller device to the LISTEN state, waiting for a connection request from any remote TCP and port.
Figure 20 – TCP connection state diagram
An active OPEN call shall make the TCP to establish the connection to a remote TCP.
The establishment of a TCP Connection is performed by using the so-called “Three-way handshake” procedure. This is initiated by one TCP calling an active OPEN and responded by another TCP, the one, which has already been called a passive OPEN and consequently is in the LISTEN state.
The message sequence – and the state transitions corresponding to that message exchange – for this “three-way handshake” procedure are shown in Figure 21.
ESTAB-LISHED
CLOSED
LISTEN
SYN RECVD
SYN SENT
CLOSE WAIT
FIN WAIT-1
FIN WAIT-2
CLOSING
TIME WAIT
LAST ACK
begin
anything / resetactive 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
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 34/55
© Copyright 1997-2005 DLMS User Association
NOTE In the case of the COSEM transport layer, the TCP user protocol layer is the wrapper sub-layer.
Figure 21 – MSC and state transitions for establishing a transport layer and TCP connection
This process, consisting of three messages, establishes the TCP connection and “synchronizes” the initial the sequence numbers 5 at both sides. This mechanism has been carefully designed to guarantee, that both sides are ready to transmit data and know that the other side is ready to transmit as well. Note, that the procedure also works if two TCPs simultaneously initiate the procedure.
7.5.2 Closing a transport layer and a TCP connection Closing a TCP connection is done by calling the CLOSE function, generally when there is no more data to be sent.
Upon the invocation of the TCP-DISCONNECT.request service primitive by the TCP connection manager process, the wrapper sub-layer invokes the CLOSE function of the TCP sub-layer.
However, as the TCP connection is full duplex, the other side may still have data to send. Therefore, after calling the CLOSE function, the TCP-based Transport later may continue to receive data and send it to the COSEM application layer, until it is told that the other side has CLOSED, too. At this point it, shall invoke the COSEM-ABORT.indication service, and all application associations shall be released.
The message sequence chart and the state transitions corresponding to a successful TCP connection release are shown in Figure 22.
5 Sequence numbers are part of the TCP packet, and are fundamental to reliable data transfer. For more details about
sequence numbers ( or other TCP related issues ), please refer to STD0007.
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
CLOSE / timeout / reset
ack /
timeout after 2 segment lifetimesack /
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
TCP is in ESTABLISHED
state
No TCP Connection is established ( both TCPs are in CLOSED state )
1
2
1
2
3
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 35/55
© Copyright 1997-2005 DLMS User Association
NOTE In the case of the COSEM transport layer, the TCP user protocol layer is the wrapper sub-layer.
Figure 22 – MSC and state transitions for closing a transport layer and TCP connection
7.5.3 TCP connection abort STD0007 does not specify a standard function to indicate an unexpected abort at TCP level. However, it can be detected by the TCP user entity by polling the status of the TCP with the STATUS() function, as shown in Figure 23.
Figure 23 – Polling the TCP sub-layer for TCP abort indication
7.5.4 Data communication – the TCP-DATA service To send an APDU to the peer, the COSEM application layer shall simply invoke the TCP-DATA.request service of the COSEM TCP-based Transport layer. Also, when a complete APDU is received, this shall be indicated to the COSEM application layer with the help of the TCP-
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
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
TCP is in ESTABLISHED
state
TCP is in TIME WAIT
state
ack
TCP is in ESTABLISHED
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
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 36/55
© Copyright 1997-2005 DLMS User Association
DATA.indication service. Thus, for the application layer the transport layer behaves as if it would transport the whole APDU in one piece.
However, nothing ensures that an APDU is actually transmitted in one TCP packet. The reason for that is that TCP is a streaming protocol – in other words, TCP does not preserve data boundaries. In the COSEM TCP-based Transport layer it is the responsibility of the wrapper sub-layer to “hide” the streaming nature of the TCP sub-layer. The following example illustrates how the wrapper sub-layer accomplishes this task.
Let’s suppose, that an application layer 6 entity wants to send an APDU containing 994 bytes via the COSEM TCP-based Transport layer. It shall invoke the TCP-DATA.request service, with this APDU as the DATA, service parameter as it is shown in Figure 24.
Figure 24 – Sending an APDU in three TCP packets
Upon the reception of this service invocation, the wrapper sub-layer shall construct the WPDU: it shall pre-fix to the APDU the wrapper header (WH), including the local and remote wPort numbers and the APDU length. It shall then call the SEND() function of the TCP sub-layer, requesting to send the WPDU, which is now 1000 bytes long: 8 bytes of wrapper header plus 992 bytes of APDU.
The SEND() function returns with the number of bytes sent or an error (a negative value). Let’s suppose, that no error occurs, and the SEND() function successfully returns – with the value 476.
The number 476 means the number of bytes sent – and also illustrates the meaning of the “streaming” nature of the TCP: in fact, the SEND() function returns with success even if the number of bytes sent is less than the number of bytes requested to be sent.
From the value returned, the wrapper knows, that not the whole WPDU has been sent, and it shall call the SEND() function again, with the remaining part of the WPDU – and so on, until the complete WPDU is sent.
Depending on the implementation, the successful return of the SEND() function may even not mean that something has been really sent to the network. It may mean only that the protocol implementation took and buffered the data. It may happen that the protocol implementation delays the transmission to comply with protocol conventions or network traffic related algorithms.
6 Both the client- and server side application layers can be either sender or receiver.
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
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 37/55
© Copyright 1997-2005 DLMS User Association
On the receiving side, it is also the responsibility of the wrapper sub-layer to assemble the complete APDU before invoking the TCP-DATA.indication service. This is possible by using the length bytes of the WPDU header. The wrapper shall repeat RECEIVE() calls until the number of bytes, indicated in the WPDU header is received. This is shown in Figure 25.
NOTES:
1. As calling the RECEIVE() function is asynchronous with regard to the TCP communications, it is perfectly possible, that the receiver calls the RECEIVE() function at a moment, when the reception of a TCP packet is in progress ( T1. on the Figure above) – or even if when no characters have been received since the last RECEIVE() call. It does not lead to erroneous reception: it increases only the number of necessary RECEIVE() function calls to get the complete message.
2. It is also possible that one or more SEND() calls result in sending more than one TCP packets. It does not lead to erroneous reception either: sooner or later the receiver gets the whole message.
Figure 25 – Receiving the message in several packets
All these SEND() and RECEIVE() calls are internal to the COSEM transport layer. The service user COSEM application layer simply uses the TCP-DATA services, and observes a reliable data transfer service preserving the data boundaries of the APDUs.
TCP-Data.ind( Data )
N = recv( 6, &buff )
N = 6
COSEMApplication
Layer
Wrappersub-layer
Peer TCPsub-layer
TCPsub-layer
N = send( rem_Data, 524 )
N = 302
N = send( rem_Data, 222 )
N = 222
N = recv( 994, &buff )
N = 470
N = recv( 524, &buff )
N = 302
N = recv( 222, &buff )
N = 222
N = send( WH + Data, 1000 )
N = 476
T1
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 38/55
© Copyright 1997-2005 DLMS User Association
8. Data Link Layer using HDLC-Protocol
8.1 Overview
This chapter specifies the data link layer for connection-oriented, HDLC-based, asynchronous communication profile.
In order to ensure a coherent data link layer service specification for both connection-oriented and connectionless operation modes, the data link layer is divided into two sub-layers: the Logical Link Control (LLC) sub-layer and the Medium Access Control (MAC) sub-layer.
This specification supports the following communication environments:
- point-to-point and point-to-multipoint configurations; - dedicated and switched data transmission facilities; - half-duplex and full-duplex connections; - asynchronous start/stop transmission, with 1 start bit, 8 data bits, no parity, 1 stop bit. Two special procedures are also defined:
- transferring of separately received Service User layer PDU parts from the server to the client in a transparent manner. The server side Service user layer can give its PDU to the data link layer in fragments and the data link layer can hide this fragmentation from the client;
- event reporting, by sending UI frames from the secondary station to the primary station. Clause 0 gives an explanation of the role of data models and protocols in electricity meter data exchange.
8.2 Overview of the data link layer specification
8.2.1 The LLC sub-layer In the connection-oriented profile the only role of the LLC sub-layer is to ensure consistent Data Link addressing. It can be considered that the LLC sub-layer, defined in ISO/IEC 8802-2:1998 is used in an extended class I operation, where the LLC sub-layer provides the standard connectionless data services via a connection-oriented MAC sub-layer.
The LLC sub-layer provides Data Link (DL) connection/disconnection services to the Service User layer, but it uses the services of the MAC sub-layer to execute these services.
The LLC sub-layer is specified in Clause 8.3.
8.2.2 The MAC sub-layer The MAC sub-layer - the major part of this data link layer specification - is based on ISO/IEC 13239 concerning high-level data link control (HDLC) procedures.
This standard includes a number of enhancements compared to the original HDLC, for example in the areas of addressing, error protection and segmentation. These enhancements have been
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 39/55
© Copyright 1997-2005 DLMS User Association
incorporated in a new frame format, which meets the requirements of the environment found in telemetry applications for electricity metering and similar industries.
8.2.3 Specification method Sub-layers of the data link layer are specified in terms of services and protocol.
Service specifications cover the services required of, or by, the given sub-layer at the logical interfaces with the neighbouring other sub-layer or layer, using connection-oriented procedures. Services are the standard way to specify communications between protocol layers. Through the use of four types of transactions, commonly known as service primitives (Request, Indication, Response and Confirm) the service provider co-ordinates and manages the communication between the users. Using service primitives is an abstract, implementation-independent way to specify the transactions between protocol layers. Given this abstract nature of the primitives, their use makes good sense for the following reasons:
- they permit a common convention to be used between layers, without regard to specific operating systems and specific languages;
- they give the implementers a choice of how to implement the service primitives on a specific machine. Service primitives include service parameters. There are three classes of service parameters:
- parameters transmitted to the peer layer, becoming part of the transmitted frame, for example addresses, control information;
- parameters, which have only local significance; - parameters, which are transmitted transparently across the data link layer to the user of the data link.
This document specifies values for parameters of the first category only.
The protocol specification for a protocol layer includes:
- the specification of the procedures for the transmission of the set of messages exchanged between peer-layers;
- the procedures for the correct interpretation of protocol control information; - the layer behaviour. The protocol specification for a protocol layer does not include:
- the structure and the meaning of the information which is transmitted by means of the layer (Information field, User data subfield);
- the identity of the Service User layer; - the manner in which the Service User layer operation is accomplished as a result of exchanging Data
Link messages; - the interactions that are the result of using the protocol layer.
8.3 The LLC sub-layer
8.3.1 The role of the LLC sub-layer The LLC sub-layer used in this profile is based on ISO/IEC 8802-2. The presence of this sub-layer in the connection-oriented profile is somewhat artificial: the LLC sub-layer is used as a kind of protocol selector, and the ‘real’ data link layer connection is ensured by the MAC sub-layer. It can be considered that the standard LLC sub-layer is used in an extended class I operation, where the LLC sub-layer provides the standard data-link-connectionless services via a connection-oriented MAC sub-layer. In order to be able to establish the data link connection, the LLC sub-layer provides transparent MAC connection/disconnection services to the service user protocol layer.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 40/55
© Copyright 1997-2005 DLMS User Association
8.3.2 Service specification for the LLC sub-layer This subclause specifies the services required of, or by, the LLC sub-layer at the logical interfaces with the Service User layer and the MAC sub-layer, using connection-oriented procedures. As the Service User layer ‘sees’ the services of the LLC sub-layer as the services of the data link layer, in this document these services are called data link layer services and the prefix “DL” to designate these services is used.
8.3.2.1 Setting up the data link connection
8.3.2.1.1 Overview
Figure 26 shows the services provided by the primary station (client side) and secondary station (server side) data link layers to the service user layer for data link connection establishment.
Figure 26 – Data link (LLC) services for setting up the data link connection
Data link connection establishment can only be requested by the primary station, so the DL-CONNECT.request and .confirm services are provided only at the client (primary station) side. On the other hand, the DL-CONNECT.indication and .response services are provided only at the server (secondary station) side.
The DL-CONNECT.request service primitive – in case of a locally detected error – can be also locally confirmed.
All these services are in fact, provided by the MAC sub-layer: the LLC sub-layer shall transparently transmit these services to/from the “real” service provider MAC sub-layer as the appropriate MA-CONNECT.xxx service primitive.
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
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 41/55
© Copyright 1997-2005 DLMS User Association
more details, see complete Green Book ....
8.4 The MAC sub-layer
The MAC sub-layer is based on ISO/IEC 13239.
The MAC sub-layer – similarly to the LLC sub-layer – is specified in terms of services and protocols. As the MAC sub-layer behaviour is quite complex, some aspects of the service invocation handling are discussed in the service specification part, although these are normally part of the protocol specification.
8.4.1 HDLC selections For the purpose of this document, the following selections from the HDLC standard ISO/IEC 13239 have been made:
- unbalanced connection-mode data link operation 7; - two-way alternate data transfer; - the selected HDLC class of procedure is UNC, extended with UI frames; - frame format type 3; - non-basic frame format transparency. In the unbalanced connection-mode data link operation, two or more stations are involved. The primary station assumes responsibility for the organization of data flow and for unrecoverable data link level error conditions by sending command and supervisory frames. The secondary station(s) respond by sending response frames.
The basic repertoire of commands and responses of the UNC class of procedures is extended with the UI frame to support multicasting and broadcasting and non-solicited information transfer from server to the client.
Using the unbalanced connection-mode data link operation implies that the client and server side data link layers are different in terms of the sets of HDLC frames and their state machines.
8.4.2 Service specification for the MAC sub-layer This subclause specifies the services required of, or by, the MAC sub-layer at the logical interfaces with the service user and the Physical (PH) layers, using connection-oriented procedures. As the client and the server side MAC sub-layers are different, services are specified for both sides.
8.4.2.1 Setting up the MAC connection
8.4.2.1.1 Overview
Figure 27 shows the services provided by the client and server side MAC sub-layers to the service user layer for MAC connection establishment.
7 In COSEM environment, the choice of an unbalanced mode of operation is natural: it is the consequence of the fact that
communication in this environment is based on the Client/Server paradigm.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 42/55
© Copyright 1997-2005 DLMS User Association
MA-
CO
NN
EC
T.re
q
MA-
CO
NN
ECT.
ind
MA-
CO
NN
ECT.
res
MA-
CO
NN
EC
T.cn
f
Primary station / Client side Secondary station / Server side
MAC sub-layer
Service user layer
Physical layer
SNRM command
UA or DM response
Figure 27 – 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 also be locally confirmed.
more details, see complete Green Book ....
8.5 Data link layer management services
8.5.1 Overview Figure 28 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.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 43/55
© Copyright 1997-2005 DLMS User Association
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 28 – Layer management services
more details, see complete Green Book ....
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 44/55
© Copyright 1997-2005 DLMS User Association
9. COSEM application layer
9.1 Overview
9.1.1 Specification method The COSEM application layer is specified in terms of structure, services, and protocols.
9.1.2 Application layer structure The main component of the client and server COSEM application layers is the COSEM ASO, which provides services to the COSEM AP, and uses services provided by the supporting lower layer.
Both the client and server side COSEM ASO contains three mandatory components:
- The ACSE. The task of this element is to establish, maintain, and release application associations. For the purposes of connection-oriented profiles, the connection-oriented ACSE, specified in ISO/IEC 8649 and ISO/IEC 8650-1 is used.
- The Extended DLMS application service element (xDLMS_ASE). The task of this element is to provide data communication services between COSEM APs.
- The Control function (CF). This element specifies how the ASO services invoke the appropriate service primitives of the ACSE and the xDLMS ASE and the services of the supporting layer.
NOTE Both the client and the server COSEM ASO may contain other, optional application protocol components.
Figure 29 shows ‘minimal’ COSEM ASOs, containing only the three mandatory components.
COSEM client ASO
Client control function
COSEM client ASO services Referencing by Logical Name
Supporting layer services
Client xDLMS_ASE
Client ACSE
COSEM client application process
COSEM server ASO
COSEM server ASO services
Supporting layer 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
Supporting layer and
other protocol layers
Referencing by Logical Name
COSEM client application layer
Figure 29 – The structure of the COSEM application layers
The COSEM application layer performs also some functions of the OSI presentation layer:
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 45/55
© Copyright 1997-2005 DLMS User Association
- for encoding the AARQ and AARE APDUs, BER encoding is used (ISO/IEC 8825); - for encoding the APDUs carrying the data communication services, A-XDR encoding is used (IEC
61334-6).
9.1.3 Service specification Service specifications cover the services required of, or by the COSEM client and server APs at the logical interfaces with the respective COSEM application layer, using connection-oriented procedures.
Services provided by the COSEM ASO fall into three categories:
- application association establishment and release; - data communication; - layer management. The client and server application layer services are specified in Clause 9.2.
9.1.3.1 Services provided for application association establishment and release These services are the following:
- COSEM-OPEN; - COSEM-RELEASE; - COSEM-ABORT. The COSEM-OPEN service is used during AA establishment phase and relies on the association request/response services of the ACSE. In the case of pre-established application associations (9.2.3.3) these services are not used.
In certain COSEM communication profiles – for example in the 3-layer, connection-oriented, HDLC-based profile – there is a one-to-one relationship between a confirmed AA and the supporting protocol layer connection. In this case, the COSEM-RELEASE service used during the association release phase does not rely on the ACSE A_RELEASE services. Confirmed AAs in these profiles are released simply by disconnecting the corresponding lower layer connection.
Optionally, the COSEM-RELEASE service may rely on the ACSE A_RELEASE service. In some communication profiles, like in the TCP-UDP/IP based profile, using the ACSE A_RELEASE services for releasing COSEM AAs is mandatory.
9.1.3.2 Data communication services DLMS UA 1000-1, Clause 4 specifies two referencing methods for COSEM servers: referencing by Logical Names (LN) and referencing by Short Names (SN). Therefore, two distinct service sets are specified for the server side xDLMS_ASE. One set uses exclusively LN references the other set uses exclusively SN references. Thus, these services are the following:
- COSEM interface object attribute-related services: GET, SET for LN referencing and Read, Write, Unconfirmed Write for SN referencing;
- COSEM interface object method-related services: ACTION (LN), Read, Write or UnconfirmedWrite (SN); - the EventNotification (LN), InformationReport (SN) services. The services rely on the services of the xDLMS_ASE. Most of these services contain references to attributes or methods of COSEM interface objects.
The service set to be used on the server side during the data communications phase is negotiated during the association establishment phase using the conformance block. It shall not change during the lifetime of the established association. Using LN or SN services within a given AA is exclusive. Therefore, it can be considered that there are two, different server xDLMS_ASE-s: one providing
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 46/55
© Copyright 1997-2005 DLMS User Association
services with Logical name references and another providing services with Short name references. The server application layer shall include one or both of these xDLMS_ASEs.
NOTE A server could use both LN and SN referencing in different AAs.
On the client side, in order to handle the different referencing schemes transparently for the COSEM client AP, the COSEM client application layer provides only one service set, using Logical Name referencing. This has two major consequences:
- Using a unique, standardized service set between COSEM client applications and the communications protocol – hiding the particularities of different COSEM servers – allows to specify an Application Programming Interface (API). This is an explicitly specified interface corresponding to this service set for applications running in a given computing environment (for example Windows XP, UNIX, etc.) Using this – public – API specification, client applications can be developed without knowledge about particularities of a given server.
- When the COSEM server device does not use LN referencing, the client application layer shall include an additional component. The purpose of this component is to map the LN service set, used by the client AP into/from the service set, used by the server AP. Figure 30 shows the COSEM client application layer when the server is using SN referencing. The additional component is called SN_MAPPER_ASE. See also.
COSEM client ASO Client control function
COSEM client ASO services Referencing by Logical Name
Supporting layer services
Client xDLMS _ASE Client
ACSE
COSEM client application process
COSEM client application layer COSEM server ASO
COSEM server ASO services
Supporting layer 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 by Short Name
Server control function
Supporting layer and
other protocol layers
Supporting layer and
other protocol layers
Figure 30 – Structure of the COSEM AL when the server is using SN references
9.1.4 Layer management services Layer management services have local importance only. Therefore, specification of these services is not within the scope of this document.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 47/55
© Copyright 1997-2005 DLMS User Association
9.1.5 Protocol specification The COSEM application layer protocols specify the procedures for the transfer of information for application association control, authentication (ACSE procedures) and for data exchange between COSEM clients and servers (xDLMS procedures). These procedures are defined in terms of:
- the interactions between peer ACSE and xDLMS protocol machines through the use of services of the supporting protocol layer;
- the interactions between the ACSE and xDLMS protocol machines and their service user; - the abstract syntax (ASN.1, ISO/IEC 8824) representation of Application Protocol Data Units (APDUs) is
also specified with the application protocols. NOTE All COSEM services are operating on an already established physical connection. Establishment of this physical connection is done outside of the COSEM protocol therefore it is not within the scope of this document.
9.2 COSEM application layer – Service specification
9.2.1 Summary of services A summary of the services available at the top of the COSEM application layer is shown in Figure 31.
XX.re
q
ZZ.in
d ZZ
.res XX
.cnf
Even
tNot
ifica
tion.
req
or
Info
rmat
ionR
epor
t.req
COSEM client application process
COSEM server application process
Application layer
ZZ.response
ZZ.request
Even
tNot
ifica
tion.
ind
EventNotification
CO
SEM
-OPE
N.re
q C
OSE
M-O
PEN
.cnf
C
OS
EM
-RE
LEA
SE
.req
CO
SEM
-REL
EAS
E.cn
f
CO
SE
M-A
BOR
T.in
d
CO
SE
M-O
PE
N.re
s C
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
SEM
-OP
EN
.ind
NOTE 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.
Figure 31 – Summary of COSEM application layer services
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 48/55
© Copyright 1997-2005 DLMS User Association
9.2.2 Application association establishment and release The COSEM-OPEN, COSEM-RELEASE and COSEM-ABORT services are used for the establishment and release of AAs.
The COSEM-OPEN.request service is invoked by the COSEM client AP to establish a confirmed or non-confirmed AA with a COSEM server AP. Invoking this service implies generating a COSEM-OPEN.indication service primitive at the server side 8. If the association to be established is a confirmed one, the server shall respond to this request by invoking the COSEM-OPEN.response service, which is transferred to the client AP as a remote confirmation (COSEM-OPEN.confirm). This normal opening sequence is shown in Figure 32.
Clientapplication layer
Serverapplication layer
COSEM-OPEN.request
COSEM-OPEN.indication
COSEM-OPEN.response
COSEM-OPEN.confirm
time
Figure 32 – Normal service sequence for the COSEM-OPEN service NOTE The COSEM-OPEN.request service may also be locally (negatively) confirmed, for example when the connection of a lower layer is not successful.
The COSEM-RELEASE service is provided for graceful disconnection of an existing application association. As COSEM server application processes are not allowed to request a graceful disconnection, the COSEM-RELEASE.request service is available only for the COSEM client. The nominal service sequence for the COSEM-RELEASE service is the same as is shown in Figure 32 for the COSEM-OPEN service, replacing the word ‘OPEN’ with the word ‘RELEASE’.
The ABORT service is used to indicate the disconnection of the physical connection. This service is the same at both sides.
9.2.3 Special application associations
9.2.3.1 Confirmed application associations For the purposes of this document, the term confirmed application association is used to designate an AA, which is established between a client and a server AP with the help of an AARQ / AARE message exchange (see at 9.3.3.1). Establishment of a confirmed AA is always initiated by the client application in invoking the COSEM-OPEN.request service with Service_Class == Confirmed.
After the establishment of a confirmed AA, any xDLMS data communication services using LN referencing can be invoked in a confirmed or unconfirmed manner, until the association is released.
NOTE xDLMS services using SN referencing are either confirmed (Read, Write) or Unconfirmed (Unconfirmed Write).
9.2.3.2 Non-confirmed application associations For the purposes of this document, the term non-confirmed application association is used to designate an AA, which is established without an AARQ / AARE message exchange: only an AARQ shall be sent from the client to the server. Similarly to the confirmed AA, establishment of a non-
8 Before the invocation of the COSEM-OPEN.request service, the physical layers must be connected. Depending on the communication
profile, the invocation of the COSEM-OPEN.request service may also imply the connection of the lower layers.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 49/55
© Copyright 1997-2005 DLMS User Association
confirmed AA is also always initiated by the Client application, but in invoking the COSEM-OPEN.request service with Service_Class == Unconfirmed.
After the establishment of a non-confirmed AA, xDLMS data communication services using LN referencing can only be invoked in unconfirmed manner, until the association is released.
NOTE With SN referencing, in non-confirmed AAs only the UnconfirmedWrite service can be used.
As the establishment of such non-confirmed AAs does not require the Server AP to respond to the association request coming from the client, in some cases – for example one-way communications or broadcasting – the establishment of a non-confirmed AA is the only possibility.
9.2.3.3 Pre-established application associations Pre-established AAs don’t need to be established using the COSEM-OPEN service. It can be considered, that this COSEM-OPEN has already been done (it does not matter how). Consequently, pre-established associations can be considered existing from the moment the lower layers are able to deliver APDUs between the client and the server.
A pre-established AA can be either confirmed or non-confirmed (depending on the way it is pre-established), but in any case it cannot be released. The purpose of this type of association is to simplify data exchange with simple devices (for example supporting one-way communication only). The pre-established AA eliminates the need of connection establishment and release (phases 1 and 3 on Figure 5) and only data communication services are used. These must use connectionless services of the supporting lower protocol layers 9.
9.2.3.4 Mandatory application associations The mandatory management logical device in the physical metering device must support an AA with a public client, with the lowest security level.
In any communication profile, the management logical device and the public client must have a reserved identifier / address.
9.2.4 Data communication For data communication purposes, the client application layer provides the following set of services:
- GET service (.request, .confirm); - SET service (.request, .confirm); - ACTION service (.request, .confirm). All these services refer to attributes or methods of COSEM interface objects via logical names.
Received erroneous confirmed service requests are normally simply discarded at the server side. However, in that case, COSEM servers may optionally respond with an EXCEPTION-response APDU, indicating that the previously received service request cannot be correctly processed.
There are also non-client/server type services to support receiving information like alarms from a COSEM server without first requesting it by the client. These are:
- EventNotification service (.indicate); - Trigger_EventNotification_Sending (.request).
9 NOTE Pre-established application associations are not possible in profiles, where the supporting lower protocol layer(s) do not provide connection-less data communication services. As for all application associations, the logical devices must contain an Association LN /SN interface object for the pre-established associations, too.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 50/55
© Copyright 1997-2005 DLMS User Association
In confirmed AAs, the client application layer obtains knowledge about the referencing method used by the server during the AA establishment phase. In case of a pre-established AA, the client application layer is expected to know the referencing method used by the server before data communication services can be used. When the client AP invokes data communication services, the application layer shall invoke the services and send the APDUs corresponding to the referencing style used by the server.
When the server is also using LN references, the server side service set is the complementary of the client side service set (the same service set, but .request services shall be transferred as .indication services, and the .confirm services are originated as .response services).
When the server is using SN references, the service set is as follows:
- READ service (.indication, .response); - WRITE service (.indication, .response); - UNCONFIRMED WRITE service (.indication); - InformationReport service (.request). As explained in 9.1.3.2, in order to able to ‘map’ between the different service sets, the client application layer shall include an additional protocol component, called ‘Client SN_MAPPER’.
The corresponding server application layer shall signal the reception of this (LN or SN referencing) APDU to the server AP.In most cases, the server AP responds to the received .request service by invoking the corresponding .response service. Upon the reception of the APDU, corresponding to that .response invocation, the client application layer shall generate the appropriate logical name referencing service primitive to the client AP.
more details, see complete Green Book ....
9.3 COSEM application layer protocol specification
The COSEM application layer is based on the extended DLMS – xDLMS – and on the connection-oriented ACSE service elements. Therefore, the protocol of this layer is based on the DLMS and ACSE protocols, as they are specified in IEC 61334-4-41 and in ISO/IEC 8650-1 respectively.
Both the xDLMS and the application contexts can be negotiated during the AA establishment.
The COSEM application protocol specification includes the specification of the protocol machines for both the client and server side application layers, and the abstract syntax (ASN.1) for the representation of APDUs. As the same APDU applies at the client side and at the server side, for example a .request type APDU, sent by the client is the same as its peer .indication APDU, the abstract syntax specification is common for both application layer entities.
9.3.1 State definitions for the client side control function Figure 33 shows the state machine for the client side control function (CF, see Figure 29).
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 51/55
© Copyright 1997-2005 DLMS User Association
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
NOTE On the state diagrams, the following conventions are used:
− service primitives with no “/” character as first character are “stimulants”: the invocation of these services is the origin of the given state transition;
− service primitives with an “/” character as first character are “outputs”: the invocation of these services is done on the state transition path.
Figure 33 – Partial state machine for the client side control function
Definitions of states are as follows:
- INACTIVE – in this state, the client CF (and the application layer) has no activity at all: it neither provides services to the AP nor uses services of the supporting protocol layer;
- IDLE – this is the state of the CF of the client application layer protocol entity when there is no AA created, being released or currently established 10. Nevertheless, some data exchange between the client and server, if the physical channel is already established, is possible in this state.
State transitions between the INACTIVE and IDLE states are controlled outside of the protocol. For example, it can be considered that the CF, and with it the application layer including it, makes the state transition from INACTIVE to IDLE state by being instantiated and bound on the top of the supporting protocol layer. The opposite transition may happen by deleting the given instance of the CF (application layer).
- ASSOCIATION PENDING – the CF of the application layer entity enters this state when the COSEM client AP invokes the COSEM-OPEN.request (OPEN.req) service primitive. The CF may exit from this state either by sending a COSEM-OPEN.confirmation (/OPEN.cnf) service primitive or, in the case of physical disconnection, by sending a COSEM-ABORT.indication (/ABORT.indication) service primitive to the AP. Depending on the result of the association request, the client CF shall return to IDLE state (NOK), or shall enter the ASSOCIATED state;
- ASSOCIATED – the CF shall enter this state when the AA has been successfully established. Data communication services – GET, SET, ACTION – are provided only in this state. The client CF shall remain in this state until the AP explicitly requires the release of the association by invoking the COSEM-RELEASE.request service primitive (RELEASE.req), or a COSEM-ABORT.indication service is invoked;
- ASSOCIATION RELEASE PENDING – the CF of the application layer entity enters this state when the COSEM client AP invokes the COSEM-RELEASE.request service primitive (RELEASE.req), requesting
10 NOTE that it is the state machine for the application layer: lower layer connections, including the physical connection, are not taken
into account. On the other hand, physical connection establishment is done outside of the protocol.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 52/55
© Copyright 1997-2005 DLMS User Association
the release of the established AA. The CF shall remain in this state, waiting for the response to this request. As the server is not allowed to refuse a release request, after exiting this state, the CF shall always enter the IDLE state. The exit from this state can be originated either by the reception of a COSEM-RELEASE.response from the remote server, the local generation of the COSEM-RELEASE.confirm or by the invocation of a COSEM-ABORT.indication service primitive.
9.3.2 State definitions for the server side control function Figure 34 shows the state machine for the server side control function, see Figure 29.
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 34 – Partial state machine for the server side control function
Definitions of the states are as follows:
- INACTIVE – in this state, the server CF (and the application layer) has no activity at all: it neither provides services to the AP nor uses services of the supporting protocol layer;
- IDLE – this is the state of the CF of the server application layer entity when there is no AA created, being released or currently established. Nevertheless, some data exchange between the client and server, if the physical channel is already established, is possible in this state;
- ASSOCIATION PENDING – upon the reception of a COSEM-OPEN.request message from a remote client, the CF of the server application layer protocol entity shall exit the IDLE state. It shall indicate the reception of this message to the server AP via the COSEM-OPEN.indication service primitive (/OPEN.indication) and shall enter into ASSOCIATION PENDING state. In this state, the Server CF is waiting for the response from the AP. If the response is positive – meaning that the AP accepted the proposed association – the CF shall enter the ASSOCIATED state. If the response is negative – or if a physical disconnection is detected – the CF shall return to the IDLE state;
- ASSOCIATED – the server CF shall enter this state when the AA has been successfully established. Data communication services – GET, SET, ACTION or READ, WRITE and UNCONFIRMED WRITE, depending on the established application context – are provided only in this state. The server CF shall remain in this state until the remote client explicitly requires the release of the AA by invoking the COSEM-RELEASE.request service (/RELEASE.ind), or a COSEM-ABORT.indication service is invoked;
- ASSOCIATION RELEASE PENDING – upon the reception of a COSEM-RELEASE.request service primitive from the remote client AP, the CF of the application layer protocol entity shall indicate it to the AP (/RELEASE.indication) and shall enter into this state. The CF shall remain in this state, waiting for the response invocation from the AP. As the server is not allowed to refuse this request, the CF shall
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 53/55
© Copyright 1997-2005 DLMS User Association
always enter the IDLE state after leaving the ASSOCIATION RELEASE PENDING state. The exit from this state can be originated also by the invocation of a COSEM-ABORT.indication service primitive.
9.3.3 Protocol for application association establishment/release
9.3.3.1 Establishment of a confirmed application association Application association establishment with the help of the Association.request/ .indication./ .response/ .confirmation services of the standard ACSE, ISO/IEC 8650-1 , is the key element of COSEM interoperability. The participants of an AA are the interoperable communications partners:
- a client AP, which is always the originator of an AA request, and - a server AP 11. The client AP shall first invoke the COSEM-OPEN.request service of the client COSEM ASO. Upon the reception of this service invocation, the Control function of the client ASO shall first examine whether the establishment of a lower layer connection is required for the requested AA or not. In this case, it shall first establish the required lower layer connection(s).
Figure 35 gives the MSC for the case, when:
- the COSEM-OPEN.request service is requesting for a confirmed AA; - the connection of the supporting lower layers is required for the establishment of the required AA.
11 In order to be able to provide multicast and broadcast services, in COSEM an AA can also be established between a client
and a group of server application processes.
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 54/55
© Copyright 1997-2005 DLMS User Association
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 35 - MSC for successful application association establishment preceded by a successful lower layer
connection establishment
DLMS User Association, EXCERPT FROM COSEM Architecture and Protocols, Fifth Edition
DLMS User Association EXCERPT DLMS UA 1000-2 ed.5 55/55
© Copyright 1997-2005 DLMS User Association
Once the required lower layer connections are established, the client CF shall assemble an AARQ APDU with the help of the two application service elements (ACSE and xDLMS) of the client application layer. This AARQ APDU shall be the first message sent to the server application layer.
The CF of the server application layer shall first give the received AARQ APDU to the ACSE, which shall extract the ACSE related parameters, then give back the control to the CF. The CF shall send the contents of the user-information field of the AARQ APDU to the xDLMS-ASE, as a xDLMS-Initiate.indication DLMS PDU.
The xDLMS-ASE shall retrieve the parameters of the xDLMS-Initiate.indication. It shall then give back the control to the CF, which shall invoke the COSEM-OPEN.indication service primitive with the appropriate parameters, extracted from the AARQ APDU 12, to the COSEM server AP. At the same time, the server Control function shall enter the ‘ASSOCIATION PENDING’ state.
The server AP shall analyze the received COSEM-OPEN.indication primitive, and decide whether it accepts the proposed AAs or not 13.
Following this verification, and if the proposed AA is confirmed, the COSEM server AP shall invoke the COSEM-OPEN.response service to indicate the acceptance or non-acceptance of the proposed association. The CF shall assemble and send the appropriate AARE APDU to the remote peer client application layer via the supporting lower protocols. If the requested AA is non-confirmed, no AARE is sent. If the proposed AA has been accepted, the server is able to receive xDLMS data communication service .request(s) and to send .responses to confirmed service requests within this AA. In other words, the association has been established, and the server has entered the data communications phase.
At the client side, the parameters of the received AARE APDU shall be extracted by the help of the ACSE and the xDLMS-ASE, and shall be sent to the client AP via the COSEM-OPEN.confirm service primitive. At the same time, the client application layer shall enter the ‘ASSOCIATED’ state. From this moment, the AA is established within the negotiated application and xDLMS contexts.
more details, see complete Green Book ....
12 Some service parameters of this COSEM-OPEN.indication primitive (address information, User_Information) do not come from the AARQ APDU, but from the supporting layer frame carrying the AARQ APDU. The Service_Class parameter of the COSEM-OPEN service is linked to the response-allowed field of the xDLMS-Initiate.request APDU. 13 The application service elements only extract the parameters, like the application context, authentication related parameters, etc. The interpretation of these parameters and the decision whether the association can be accepted or not, is the job of the COSEM server application process.