cosem three layer connection oriented architecture (2002)

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

EXCERPT FROM Companion Specification for Energy Metering COSEM Three Layer Connection Oriented Architecture DLMS User Association

device languagemessagespecification

DLMS User Association, EXCERPT FROM COSEM Communication Profile, Third Edition

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

© Copyright 1997-2002 DLMS User Association




Table of Contents

1. Foreword .......................................................................................................................................................................5

2. Scope .............................................................................................................................................................................5

3. Introduction...................................................................................................................................................................7 3.1 The COSEM Communications Framework ...............................................................................................................7 3.1.1 Client/Server type operation, communication profiles ...........................................................................................7 3.1.2 Connection (Association) Oriented Operation .......................................................................................................8 3.2 Interoperability and Interconnectivity in COSEM .......................................................................................................9 3.3 Ensuring interconnectivity: the Protocol Identification Service ..................................................................................9 3.4 Referenced Documents ............................................................................................................................................10 3.5 Terms, Definitions and Abbreviations........................................................................................................................11

4. Physical layer services and procedures for connection oriented asynchronous data exchange .........................13 4.1 Overview ...................................................................................................................................................................13 4.2 Service Specification.................................................................................................................................................14 4.2.1 List of services ......................................................................................................................................................14 4.2.1.1 Connection establishment/release related services ...........................................................................................14 4.2.1.2 Data communication services.............................................................................................................................14 4.2.1.3 Layer management services ..............................................................................................................................14 4.2.2 Use of the physical layer services .........................................................................................................................14

5. Direct Local Connection (excerpt)...............................................................................................................................16

6. Data Link Layer using HDLC-Protocol ........................................................................................................................17 6.1 Overview ...................................................................................................................................................................17 6.1.1 The LLC sub-layer.................................................................................................................................................17 6.1.2 The MAC sub-layer ...............................................................................................................................................17 6.1.3 Specification method.............................................................................................................................................18 6.2 The LLC sub-layer.....................................................................................................................................................18 6.2.1 The role of the LLC sub-layer................................................................................................................................18 6.2.2 Service specification for the LLC sub-layer ...........................................................................................................18 6.2.2.1 Setting up the Data Link Connection ..................................................................................................................19 6.2.2.1.1 Overview .........................................................................................................................................................19 6.3 The MAC sub-layer ...................................................................................................................................................20 6.3.1 HDLC selections ...................................................................................................................................................20 6.3.2 Service specification for the MAC sub-layer..........................................................................................................20 6.3.2.1 Setting up the MAC Connection .........................................................................................................................20 6.3.2.1.1 Overview .........................................................................................................................................................20 6.4 Data link layer management services .......................................................................................................................21

7. COSEM Application Layer............................................................................................................................................23 7.1 Overview ...................................................................................................................................................................23 7.1.1 Specification method.............................................................................................................................................23 7.1.2 Application Layer structure....................................................................................................................................23 7.1.3 Service specification overview ..............................................................................................................................24 7.1.3.1 Services provided for Application Association establishment and release .........................................................24 7.1.3.2 Data communication services.............................................................................................................................24 7.1.4 Layer Management services .................................................................................................................................25 7.1.5 Protocol specification ............................................................................................................................................25 7.2 COSEM Application Layer – Service specification ....................................................................................................26 7.2.1 Summary of services.............................................................................................................................................26 7.2.2 Application Association establishment and release...............................................................................................26 7.2.3 Special Application Associations...........................................................................................................................27 7.2.3.1 Mandatory Application Associations...................................................................................................................27 7.2.3.2 Pre-established Application Associations...........................................................................................................27 7.2.3.3 Non-Confirmed Application Associations............................................................................................................27 7.2.4 Data communication .............................................................................................................................................27 7.3 COSEM Application Layer protocol specification ......................................................................................................28 7.3.1 State Definitions for the Client side Control Function ............................................................................................29 7.3.2 State Definitions for the Server side Control Function...........................................................................................30 7.3.3 Protocol for Application Association establishment/release ..................................................................................31 7.3.3.1 Establishment of an Application Association ......................................................................................................31 7.4 The 3-layer, connection-oriented, HDLC based profile..............................................................................................33 7.4.1 Introduction ...........................................................................................................................................................33 7.4.2 The HDLC-based Data Link Layer - Overview ......................................................................................................34




Figures Figure 1 – The three steps approach of COSEM: Modelling - Messaging - Transporting ................................................... 6 Figure 2 - Client / Server relationship in COSEM ................................................................................................................ 7 Figure 3 - Exchanging messages via the communications protocol .................................................................................... 7 Figure 4 - The COSEM Application Layer on the top of various lower layer stacks............................................................. 8 Figure 5 - A complete communications session in the CO environment ............................................................................. 8 Figure 6 - Typical PSTN configuration............................................................................................................................... 13 Figure 7 - The location of the Physical Layer .................................................................................................................... 14 Figure 8 - Protocol layer services of the COSEM 3-layer connection oriented profile ....................................................... 15 Figure 9 - Entering protocol mode E (HDLC) .................................................................................................................... 16 Figure 10 - Data Link (LLC) services for setting up the Data Link Connection .................................................................. 19 Figure 11 - MAC sub-layer services for setting up the MAC (DL) connection at the Client- and Server sides................... 21 Figure 12 - Layer management services ........................................................................................................................... 22 Figure 13 - The structure of the COSEM Application Layers............................................................................................. 23 Figure 14 - Structure of the COSEM AL when the Server is using SN references ............................................................ 25 Figure 15 - Summary of COSEM Application Layer Services............................................................................................ 26 Figure 16 - Nominal service sequence for the COSEM-OPEN service ............................................................................. 27 Figure 17 - Partial State machine for the Client side Control Function .............................................................................. 29 Figure 18 - Partial state machine for the Server side Control Function ............................................................................. 30 Figure 19 - MSC for successful Application Association establishment ............................................................................ 32




1. Foreword

Copyright © Copyright 1997-2002 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 world-wide, and other treaties apply. Acknowledgement The actual document has been established by a team of experts working for the meter manufacturers DZG, Enermet, Schlumberger/Actaris and Siemens/Landis&Gyr, with input from other members of the DLMS User Association and from working group members of standardisation bodies, e.g. IEC TC13 WG14 and IEC TC57 WG9. Status of standardization The actual edition 3 of this document provides the same information as IEC 62056-42 (Physical layer services and procedures for connection oriented asynchronous data exchange), IEC 62056-46 (Data link layer using HDLC-protocol), and IEC 62056-53 (COSEM Application layer). Furthermore, Annex E of IEC 62056-21 (Direct local data exchange) has been incorporated. These International Standards were published in 2002.




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 and Physical layer) of the protocol transport the information. • Application layer, Data Link layer and Physical layer are described in this document.

3. Transporting

C0 01 00 03 01 01 01 08 00 FF 02

2. Messaging

Protocol Services to access attributes and methods

ISO, IEC,...

Communication Protocol

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

Encoding: ( APDU )

1. Modelling COSEM Interface Objects

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

DLMS User Associatio

n




3. Introduction

3.1 The COSEM Communications Framework

3.1.1 Client/Server type operation, communication profiles Communication with electricity metering equipment using the COSEM Interface Classes is based on the Client/Server paradigm, where metering equipment1 plays the Server role. In this environment, communication takes place always between a Client and a Server application process: in other words, the Server Application Process provides remote services to the Client Application Process. These services are provided via exchanging messages (SERVICE.requests / .responses) between the Client and the Server Application Processes, as it is shown on Figure 2.

C lient ApplicationServer Application(COSEM device)

SERVIC E.request

SERVICE.response

Figure 2 - Client / Server relationship in COSEM

As generally the Client and the Server Application Processes are located in separate devices, exchanging messages is done with the help of the communications protocol.

Client

ApplicationLayer

IntermediateProtocol Layers

Physical Layer

Server.request

.response

.request .response

Protocol

Physical Channel

Figure 3 - Exchanging messages via the communications protocol

Generally, communication protocols are structured in layers. The Client and Server COSEM Applications use services of the highest protocol layer, the Application Layer: consequently this is the only protocol layer

1 The 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.




which must contain COSEM specific element(s). This is called the xDLMS_ASE. All COSEM Interface Object related services – the xDLMS Application Protocol – are provided by this xDLMS_ASE. Other protocol layers are independent from the COSEM model, consequently the COSEM Application Layer can be placed on the top of a wide variety of lower protocol layer stacks, as it is shown on Figure 4.

xDLMS_ASE ACSE

Application Layer

N LayerN-1 Layer

N Layer N Layer

Physical Layer Physical Layer Physical Layer

Profile 1 Profile 2 Profile M

………

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 Communications Profile. A Communication Profile is characterised by the protocol layers included, their parameters, and by the type – Connection Oriented or Connectionless – of the ACSE2 included in the Application Layer.

3.1.2 Connection (Association) Oriented Operation The xDLMS Application Protocol is a Connection-Oriented protocol. It means, that the Client and Server Application Processes can use the services of the xDLMS_ASE only when these Application Processes are associated3. Therefore, in this environment a communication session consists of three phases, as it is shown on Figure 5.

Client Application Server Application

Phase 1.Connection Establishment

Phase 2.Data Communication

Phase 3.Connection Releaset

Figure 5 - A complete communications session in the CO environment

In the 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 multi- and broad-casting, pre-established Application Associations are also allowed; see 7.2.3.2. For these associations, there 2 ACSE = Association Control Service Element 3 Application Associations can be considered as Application Level connections




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 and a Server Applications are interoperable if they use the Association.request/ .indication/ .response/ .confirmation services of the standard ACSE, as it is specified in the Application Layer chapter, to establish Application Associations4. In these terms, 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 establish a connection, are interconnected. Therefore, in order to be interconnected, the Client and Server Application processes should be interconnectable and shall establish the required connections. In these terms, interconnectivity in COSEM is ensured by the ability to establish a connection between all peer protocol layers, which requires it. In COSEM, Application Association establishment between a Server and a Client is always initiated by the Client. However, in some cases, the Client Application Process may not have knowledge about the protocol stack used by an unknown Server device (e.g. when the Server has initiated the physical connection establishment). In such cases, the Client must obtain information about the protocol stack implemented in the Server. The COSEM framework provides a specific, application level service to for this purpose: the Protocol Identification Service

3.3 Ensuring interconnectivity: the Protocol Identification Service The Protocol Identification Service is an optional Application level service, which allows the Client to obtain information, after establishing a physical connection, about the protocol stack implemented in the Server .The Protocol Identification Service uses directly the data communication services (PH-DATA.request/.indication) of the Physical Layer ; it bypasses the remaining part of the protocol. The Identification service is specified in the Physical Layer chapter (see 4). It is recommended to be supported it by all COSEM Clients and Servers.

4 Note, that using this common application protocol for Application Association (AA) establishment does not mean, that all established

AAs are the same: using the same ACSE protocol one may establish an AA within one application context and somebody else within another one. For instance, there shall be servers which establish AAs within an application context which requires of using of Logical Name references during the data communications phase (phase2), and there shall be servers which establish AAs within a – different – application context which requires of using Short Name references during the data communications phase. Although messages exchanged during the data communications phase between the client and these two types of servers have different syntaxes, the two servers are both interoperable with the Client, which was able to establish the right application association with both servers.




3.4 Referenced Documents Ref. Title DLMS UA 1000-1 COSEM Identification System and Interface Objects, Fifth Edition (2002) IEC 61334-4-41:1996 Distribution automation using distribution line carrier systems - Part 4: Data

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

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

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

IEC 62056-42:2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 42: Physical layer services and procedures for connection oriented asynchronous data exchange

IEC 62056-46:2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 46: Data Link layer using HDLC protocol

IEC 62056-53:2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 53: COSEM Application layer

IEC 62056-61:2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 61: OBIS Object identification system

IEC 62056-62:2002 Electricity metering – Data exchange for meter reading, tariff and load control – Part 62: Interface objects

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

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

ISO/IEC 8802-2:1998 Information technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Specific requirements – Part 2: Logical link control

ISO/IEC 8824:1990 Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)

ISO/IEC 8825:1990 Information technology - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)

ISO/IEC 13239:2000 Information Technology - Telecommunications and information exchange between systems – High-level data link control (HDLC) procedures

NEMA C12.21:1999 Protocol Specification for Telephone Modem Communication




3.5 Terms, Definitions and Abbreviations Abbreviation Explanation 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 ASE Application Service Element ASO Application Service Object 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

DCE Data Communication Equipment (communications interface or modem) DISC Disconnect (a HDLC frame type) DLMS Distribution Line Message Specification DM Disconnected Mode (a HDLC frame type) DPDU Data Link Protocol Data Unit DSAP Data Link Service Access Point DSDU Data Link Service Data Unit DTE Data Terminal Equipment (computers, terminals or printers) FCS Frame Check Sequence FRMR Frame Reject (a HDLC frame type) GMT Greenwich Mean Time HCS Header Check Sequence HDLC High-level Data Link Control HLS High Level Security I Information (a HDLC frame type) IC Interface Class 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 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 PDU Protocol data unit P/F Poll/Final PH Physical Layer PHPDU PH PDU PHSDU PH SDU PSDU Physical layer Service Data Unit .req .request service primitive .res .response service primitive RNR Receive Not Ready (a HDLC frame type) RR Receive Ready (a HDLC frame type) SAP Service Access Point SDU Service Data Unit 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. TWA Two Way Alternate UA Unnumbered Acknowledge (a HDLC frame type) UI Unnumbered Information (a HDLC frame type) UNC Unbalanced operation Normal response mode Class USS Unnumbered Send Status V(R) Receive state Variable V(S) Send state Variable xDLMS-ASE Extended DLMS Application Service Element




4. Physical layer services and procedures for connection oriented asynchronous data exchange

4.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 7. Figure 6 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 6 - Typical PSTN configuration

From the physical connection point of view, all communications involve two sets of equipment represented by the terms Caller system and Called system. The Caller is the system that decides to initiate a communication with a remote system known as the Called party; these denominations remain valid throughout the duration of the communication. A communication is broken down into a certain number of transactions. Each transaction is represented by a transmission from the Transmitter to the Receiver. During the sequence of transactions, the Caller and Called systems take turns to act as Transmitter and Receiver. From the data link point of view the central station normally acts as a master, taking the initiative and controlling the data flow. The tariff device is the slave, responding to the master station. From the application point of view the central station normally acts as a client asking for services, and the tariff device acts as a server delivering the requested services. The situation involving a Caller Client and a Called Server is undoubtedly the most frequent case, but a communication based on a Caller Server and a Called Client is also possible, in particular to report the occurrence of an urgent alarm. For the purposes of local data exchange, two DTEs can be directly connected using appropriate connections. To allow using a wide variety of media, this companion specification does not specify the physical layer signals and their characteristics. However, the following assumptions are made: • the communication is point to point or point to multipoint; • both half-duplex and duplex connections are possible; • asynchronous transmission with 1 start bit, 8 data bits, no parity and 1 stop bit (8N1). From the internal point of view, the physical layer is the lowest layer in the protocol stack.

COSEM Client COSEM Server

DTE DTEDCE DCE




Figure 7 - The location of the Physical Layer

This specification defines the services of the Physical Layer towards its peer layer(s) and the upper layers, and the protocol of the physical layer.

4.2 Service Specification

4.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:

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

4.2.1.2 Data communication services PH-DATA.request / PH-DATA.indication

4.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-INITIALISE.request / PH-INITIALISE.confirm PH-GET_VALUE.request / PH-GET_VALUE.confirm PH-SET_VALUE.request / PH-SET_VALUE.confirm PH-LM_EVENT.indication As these services are of local importance only, their definition is not within the scope of this specification.

4.2.2 Use of the physical layer services Figure 8 shows how different service users use the service primitives of the Physical Layer.

Transit Network

DTE

DataComm.

Equipment(DCE)

COSEM Client COSEM Server

ClientApplication

ApplicationLayer

Data LinkLayer

PhysicalLayer

Pro

toco

l

DTE

ServerApplication

ApplicationLayer

Data LinkLayer

PhysicalLayer

Pro

toco

l

DataComm.

Equipment(DCE)




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

As is shown in Figure 8, the connection establishment/release services are used by and provided for the Physical Connection Manager Application Process, and not the Data Link Layer. The reasons for this are explained in 4. more details, see complete Green Book ....

Application Layer

DL Mgmt. Services

Physical Layer

Data Link Layer

AL Mgmt. Services

PH Mgmt. Services

Connect/Disconnect andData related services

Layer ManagementProcess

ASO Services

Application ProcessPhysical

ConnectionManager

Prot

ocol

Appl

icat

ion

PH

-CO

NN

ECT.

req

/.cnf

/.in

d P

H-A

BOR

T.re

q /.c

nf /.

ind

PH

-DAT

A.re

q /.i

nd

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




5. Direct Local Connection (excerpt)

This chapter is an excerpt of IEC 62056-21 which describes hardware and protocol specifications for local meter data exchange. In such systems, a hand-held unit (HHU) or a unit with equivalent functions is connected to a tariff device or a group of devices. Only COSEM related items are described here. The complete information can be found in IEC 62056-21. Metering HDLC protocol using protocol mode E for direct local data exchange The protocol stack as described in Clauses 4, 6 and 0 of this specification (or IEC 62056-42, IEC 62056-46 and IEC 62056-53) shall be used. The switch to the baudrate Z shall be at the same place as for protocol mode C. The switch confirm message, which has the same structure as the acknowledgement/option select message, is therefore at the new baud rate but still with parity (7E1). After the acknowledgement, the binary mode (8N1) will be established. As the server acknowledgement string is a constant in the server's program, it could be easily possible to switch to the baudrate 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 E. 4). 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 xxxx, Clause 6.3.14).

/ ? 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 9 - Entering protocol mode E (HDLC)

more details, see complete Green Book ....




6. Data Link Layer using HDLC-Protocol

6.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. Overview of the Data Link Layer specification:

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

6.1.2 The MAC sub-layer The MAC sub-layer - the major part of this Data Link Layer specification - is based on ISO/IEC 13239:2000 concerning high-level data link control (HDLC) procedures. This specification includes a number of enhancements compared to the original HDLC, for example in the areas of addressing, error protection and segmentation. These enhancements have been incorporated in a new frame format, which meets the requirements of the environment found in telemetry applications for electricity metering and similar industries. The MAC sub-layer is specified in Clause 6.3.




6.1.3 Specification method Sub-layers of the Data Link Layer are specified in terms of services and protocol. Service specifications cover the services required of, or by, the given sub-layer at the logical interfaces with the neighbouring other sub-layer or layer, using connection oriented procedures. Services are the standard way to specify communications between protocol layers. Through the use of four types of transactions, commonly known as service primitives (Request, Indication, Response and Confirm) the service provider co-ordinates and manages the communication between the users. Using service primitives is an abstract, implementation-independent way to specify the transactions between protocol layers. Given this abstract nature of the primitives, their use makes good sense for the following reasons: • they permit a common convention to be used between layers, without regard to specific operating

systems and specific languages; • they give the implementers a choice of how to implement the service primitives on a specific machine. • Service primitives include service parameters. There are three classes of service parameters: • parameters transmitted to the peer layer, becoming part of the transmitted frame, e.g. addresses, control

information; • parameters which have only local significance (e.g. Physical_Connection_Type). • 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 (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.

6.2 The LLC sub-layer

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

6.2.2 Service specification for the LLC sub-layer This Clause 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.




6.2.2.1 Setting up the Data Link Connection

6.2.2.1.1 Overview Figure 10 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 10 - Data Link (LLC) services for setting up the Data Link Connection

Data link connection establishment can only be requested by the primary station, so the DL-CONNECT.request and .confirm services are provided only at the Client (primary station) side. On the other hand, the DL-CONNECT.indication and .response services are provided only at the Server (secondary station) side. The DL-CONNECT.request service primitive - in case of a locally detected error - can be also locally confirmed. All these services are in fact, provided by the MAC sub-layer: the LLC sub-layer shall transparently transmit these services to/from the "real" service provider MAC sub-layer as the appropriate MA-CONNECT.xxx service primitive. more details, see complete Green Book ....

DL-

CO

NN

ECT.

req

DL-

CO

NN

ECT.

ind

DL-

CO

NN

ECT.

res

DL-

CO

NN

ECT.

cnf

Primary station / Client side Secondary station / Server side

LLC sub-layer

Service user layer

MAC sub-layer

Physical Layer

Data Link Layer




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

6.3.1 HDLC selections For the purposes of this specification, the following selections from the HDLC standard ISO/IEC 13239:2000 have been made: • unbalanced connection-mode data link operation5; • two-way alternate data transfer; • the selected HDLC class of procedure is UNC (Unbalanced operation Normal response mode Class),

extended with UI frames; • frame format type 3 • non-basic frame format transparency. In the unbalanced connection-mode data link operation, two or more stations are involved. The primary station assumes responsibility for the organisation of data flow and for unrecoverable data link level error conditions by sending command frames. The secondary station(s) respond by sending response frames. The basic repertoire of commands and responses of the UNC class of procedures is extended with the Unnumbered Information (UI) frame to support multi- and broadcasting and non-solicited information transfer from Server to the Client. Using the unbalanced connection-mode data link operation implies that the Client- and Server side Data Link Layers are different in terms of the sets of HDLC frames and their state machines.

6.3.2 Service specification for the MAC sub-layer This Clause specifies the services required of, or by, the MAC sub-layer at the logical interfaces with the service user and the Physical (PH) layers, using connection-oriented procedures. As the Client and the Server side MAC sub-layers are different, services are specified for both sides.

6.3.2.1 Setting up the MAC Connection

6.3.2.1.1 Overview shows the services provided by the Client- and Server side MAC sub-layers to the service user layer for MAC connection establishment.

5 In COSEM environment the choice of an unbalanced mode of operation is natural: it is the consequence of the fact that communication

in this environment is based on the Client/Server paradigm.




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

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

6.4 Data link layer management services Figure 12 shows management services provided by the Data Link Layer to the System Management Process. The same service set is used both at the Client and the Server sides. As these services are of local importance only, these Clauses are included here only as guidance.

MA-

CO

NN

ECT.

req

MA-

CO

NN

ECT.

ind

MA-

CO

NN

ECT.

res

MA-

CO

NN

ECT.

cnf

Primary station / Client side Secondary station / Server side

MAC sub-layer

Service user layer

Physical Layer

SNRM command

UA or DM response




Application Layer

DL-INITIALISE.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/.indPH-ABORT.ing

Layer Management Process

ASO Services

Application Process Physical ConnectionManager Process

Phys

ical

Con

nect

/Dis

conn

ect

Figure 12 - Layer management services

more details, see complete Green Book ....




7. COSEM Application Layer

7.1 Overview

7.1.1 Specification method The COSEM Application Layer is specified in terms of structure, services and protocols.

7.1.2 Application Layer structure The main component of the Client and Server COSEM Application Layers is the COSEM Application Service Object (ASO), which provides services to the COSEM Application Process, and uses services provided by the supporting lower layer. • Both the Client- and Server side COSEM ASO contains three mandatory components: • The Association Control Service Element (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:1996 and ISO/IEC/TR2 8650-1:1996 is used.

• The Extended DLMS Application Service Element (xDLMS_ASE). The task of this element is to provide data communication services between COSEM equipment.

• 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 13 shows ‘minimal’ COSEM ASO-s, containing only the three mandatory components

COSEM Client ASOClient Control Function

COSEM Client ASO ServicesReferencing by Logical Name

Supporting Layer Services

ClientxDLMS_ASE

ClientACSE

COSEM ClientApplication Process

COSEM Client Application

COSEM Server ASO

COSEM Server ASO Services


ServerxDLMS_ASE

ServerACSE

COSEM ServerApplication Process

COSEM Server Application

Prot

ocol

Appl

icat

ions

(com

mun

icat

ions

)(In

terfa

ce O

bjec

ts)

WAN, ex. PSTN

Server Control(Server CF)

Supporting layer (data link) and otherprotocol layers


Referencing by LogicalName or by Short Name

(Client CF)

Figure 13 - The structure of the COSEM Application Layers




7.1.3 Service specification overview Service specifications cover the services required of, or by the COSEM Client- and Server Application Processes at the logical interfaces with the respective COSEM Application Layer, using connection oriented procedures. Services provided by the COSEM ASO fall in three categories: • application association establishment and release; • data communication; • layer management. The Client- and Server Application Layer services are specified in 7.2.

7.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 Application Association establishment phase and relies on the Association Request/Response services of the ACSE. In the case of pre-established Application Associations (7.2.3.2) these services are not used. As in any COSEM communications profile there is a one-to-one relationship between an Application Association and a supporting protocol layer connection, the COSEM-RELEASE and COSEM-ABORT services – used during the Connection Release phase – do not rely on the ACSE. Application Associations are released or aborted simply by disconnecting the corresponding supporting layer connection.

7.1.3.2 Data communication services DLMS UA 1000-1 or IEC 62056-62 specifies two referencing methods for COSEM Servers: referencing by Logical Names (LN) and referencing by Short Names (SN). Therefore, two distinct service sets are specified for the Server side xDLMS_ASE. One set uses exclusively LN references the other set uses exclusively SN references. Thus, these services are the following: • COSEM Interface Object attribute-related services: GET, SET for LN referencing and Read, Write,

Unconfirmed Write for SN referencing; • COSEM Interface Object method-related services: ACTION (LN), Write (SN); • The EventNotification (LN), InformationReport (SN) services. The services listed above 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 Application Association is exclusive. Therefore, it can be considered that there are two, different Server xDLMS_ASE-s: one providing services with Logical Name references and another providing services with Short Name references. The Server Application Layer shall include one of these xDLMS_ASE-s. Note: A Server could use both LN and SN referencing in different Application Associations.

On the Client side, in order to handle the different referencing schemes transparently for the COSEM Client Application Process, the COSEM Client Application Layer provides only one service set, using Logical Name referencing. This has two major consequences: • Using a unique, standardised service set between COSEM Client applications and the communications

protocol – hiding the particularities of different COSEM Servers – allows to specify an Application Programming Interface (API). This is an explicitly specified interface corresponding to this service set for applications running in a given computing environment (e.g. Windows98, 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 Logical Name 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 Application Process into/from the service set, used by the Server Application Process. Figure 14 shows the COSEM Client Application Layer when the Server is using Short Name references. The additional component is called SN_MAPPER_ASE.

COSEM Client ASOClient Control Function

COSEM Client ASO ServicesReferencing by Logical Name


ClientxDLMS_ASE Client

ACSE


COSEM Client ApplicationL

COSEM Server ASO

COSEM Server ASO Services


ServerxDLMS_ASE

ServerACSE


COSEM Server ApplicationL

Prot

ocol

Appl

icat

ions

(com

mun

icat

ions

)(In

terfa

ce O

bjec

ts)

PSTN

ClientSN_MAPPER

SN referencing (RD/WR)

Server ControlF ti(Server CF)


Supporting layar (data link) and otherprotocol layers

Figure 14 - Structure of the COSEM AL when the Server is using SN references

7.1.4 Layer Management services Layer Management services have local importance only. Therefore, specification of these services is out of the scope of this document The specific SetMapperTables service is defined in 7.2.

7.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:1990) representation of Application Protocol Data Units

(APDU-s) 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 out of the scope of this document.




7.2 COSEM Application Layer – Service specification

7.2.1 Summary of services A summary of the services available at the top of the COSEM Application Layer is shown on Figure 15.

XX.re

q

ZZ.in

dZZ

.resXX

.cnf

Even

tNot

ifica

tion.

req

orIn

form

atio

nRep

ort.r

eq



Application Layer

ZZ.response

ZZ.request

Even

tNot

ifica

tion.

ind

EventNotification

CO

SEM

-OPE

N.re

qC

OSE

M-O

PEN

.cnf

CO

SEM

-REL

EASE

.req

CO

SEM

-REL

EASE

.cnf

CO

SEM

-ABO

RT.

ind

CO

SEM

-OPE

N.re

sC

OSE

M-R

ELEA

SE.in

dC

OSE

M-R

ELEA

SE.re

s

CO

SEM

-ABO

RT.

ind

Trig

g_Ev

entN

otif.

req

CO

SEM

-OPE

N.in

d

Figure 15 - Summary of COSEM Application Layer Services

Note: On the Figure above XX and ZZ refers to Client/Server type data communication services. These services may be different on the Client side and the Server side, if the Server does not use LN referencing. See in 7.2.4.

7.2.2 Application Association establishment and release The COSEM-OPEN, COSEM-RELEASE and COSEM-ABORT services are used for the establishment and release of application associations. The COSEM-OPEN.request service is invoked by the COSEM Client Application Process to open an Application Association to a COSEM Server Application Process. Invoking this service implies – after connecting the lower layers 6 – to generate a COSEM-OPEN.indication service primitive at the Server side. The Server shall respond to this request by invoking the COSEM-OPEN.response service, which is transferred to the Client Application Process as a remote confirmation (COSEM-OPEN.confirm). This normal opening sequence is shown on Figure 16.

6 Except of the Physical Layer, which should be already connected.




ClientApplication Layer

ServerApplication Layer

COSEM-OPEN.request

COSEM-OPEN.indication

COSEM-OPEN.response

COSEM-OPEN.confirm

time

Figure 16 - Nominal service sequence for the COSEM-OPEN service Note: the COSEM-OPEN.request may also be locally confirmed, e.g. 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 it is shown on Figure 16. 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.

7.2.3 Special Application Associations

7.2.3.1 Mandatory Application Associations As defined in Clause 4.1.6. of DLMS UA 1000-1 or in Clause 4.6. of IEC 62056-62, each Physical Device must contain a Management Logical Device. The mandatory contents of the Management Logical Device is defined in Clause 4.1.6.4 of DLMS UA 1000-1 or in Clause 4.6.4 of IEC 62056-62. The Management Logical Device must support an Application Association to a Public Client, with lowest security level. The Client address 0x10 is reserved for the Public Client.

7.2.3.2 Pre-established Application Associations A pre-established Application Association does not need to be established using the COSEM-OPEN service. It can be considered, that this OPEN has been already done (it is of no importance how). Consequently, pre-established Application Associations should be considered to be existing from the moment of the establishment of the physical connection between the Client and the Server devices. A pre-established Application Association can be either confirmed or non-confirmed (depending on the way it is pre-established), but in any case it can not be released. The purpose of this type of association is to simplify data exchange with simple devices, (e.g. supporting one-way communication only). The pre-established Application Association 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.7

7.2.3.3 Non-Confirmed Application Associations A Client Application may invoke the COSEM-OPEN.request service in two different ways: confirmed or non-confirmed. A non-confirmed COSEM-OPEN.request invocation shall result in the establishment of a non-confirmed Application Association. Within this Application Association the Client COSEM Application Layer shall accept only non-confirmed xDLMS service requests (GET, SET, ACTION).The purpose of having this type of association is to allow multi- and broadcasting.

7.2.4 Data communication For data communication purposes, the Client Application Layer provides the following set of services (referred to as XX on Figure 15): • GET service (.request, . confirm); • SET service (.request, .confirm); 7 Pre-established associations can not be supported by a lower protocol layer not providing non-connected data communication

services.




• ACTION service (.request, .confirm). All these services refer to attributes or methods of COSEM Interface Objects via Logical Names. 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). The Client Application Layer obtains knowledge during the Application Association establishment phase about the referencing method used by the Server. When the Client Application Process invokes the data communication services, the COSEM Client Application Layer shall send the APDU corresponding to the appropriate service invocation to the Server (referred to as ZZ on Figure 15). 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). Note: as explained in 7.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 Application Process.In most cases, the Server Application Process 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 Application Process. more details, see complete Green Book ....

7.3 COSEM Application Layer protocol specification The COSEM Application Layer is based on the extended DLMS - xDLMS, and on the standard 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:1996 and in ISO/IEC/TR2 8650-1:1996 respectively. Both the DLMS and the Application Contexts can be negotiated during the Application Association 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 Application Protocol Data Units (APDU-s). As the same APDU applies at the Client- and at the Server side - e.g. 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 and is given in the complete Green Book.




7.3.1 State Definitions for the Client side Control Function Figure 17 shows the state machine for the Client side Control Function (CF, see Figure 13).

IDLE

ASSOCIATIONPENDING

ASSOCIATED

ASSOCIATIONRELEASEPENDING

OPEN.req

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

/OPEN.cnf(OK)

/ABORT.ind

RELEASE.req

/RELEASE.cnf

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

Trigger_EventReport_sending.req /EventReport.ind

/ABORT.ind

INACTIVE

Figure 17 - Partial State machine for the Client side Control Function

Note: On the state diagrams, the following conventions are used:

Service primitives with no “/” character as first character are “stimulants”: the invocation of these services is the origin of the given state transition.

Service primitives with an “/” character as first character are “outputs”: the invocation of these services is done on the state transition path.

Definitions of states are as follows: • INACTIVE – In this state, the Client CF (and the Application Layer) has no activity at all: it neither

provides services to the Application Process 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

Application Association created, being released or currently established8. 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 Application Process 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 Application Process. 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 Application Association 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

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




invoking the COSEM-RELEASE.request service primitive (RELEASE.req), or the association is aborted due to a non-solicited physical disconnection.

• 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 the disconnection of the established Application Association. 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 the release response from the remote Server or by the reception of a DL-DISCONNECT.indication service primitive meaning that the physical layer has been aborted.

7.3.2 State Definitions for the Server side Control Function Figure 18. shows the state machine for the Server side Control Function , see Figure 13.

IDLE

ASSOCIATION/PENDING

ASSOCIATED

ASSOCIATIONRELEASEPENDING

/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 18 - 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 Application Process 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 Application

Association 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 Application Process 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 Application Process. 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 Application Association 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




association by invoking the COSEM-RELEASE.request service (/RELEASE.ind), or the association is aborted due to a non-solicited physical disconnection.

• ASSOCIATION RELEASE PENDING – Upon the reception of a COSEM-RELEASE.request service primitive from the remote Client Application Process, the CF of the Application Layer protocol entity shall indicate it to the Application Process (/RELEASE.indication) an shall enter to this state. The CF shall remain in this state, waiting for the response invocation from the AP. As the Server is not allowed to refuse this request, the CF shall always enter the IDLE state after leaving the ASSOCIATION RELEASE PENDING state. The exit from this state can be also originated by the reception of a DL-DISCONNECT.indication service primitive, meaning that the physical layer has been aborted.

7.3.3 Protocol for Application Association establishment/release

7.3.3.1 Establishment of an Application Association Application Association establishment with the help of the Association.request/ .indication./ .response/ .confirmation services of the standard ACSE, ISO/IEC/TR2 8650-1:1996 is the key element of COSEM interoperability. The participants of an Application Association are the interoperable communications partners: • a Client Application Process, which is always the originator of a Application Association request, and; • a Server Application Process9. The Client Application Process shall first10 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 establish the required lower layer connections. Supposing that there is no problem, the two supporting layers are connected, as the Message Sequence Chart (MSC) shows on Figure 19.

9 In order to be able to provide multi- and broadcast services, in COSEM an AA can also be established between a Client- and a group

of Server Application processes. 10 Invoking the COSEM-OPEN.request service requires an already established physical connection – but the establishment of this

physical connection takes place outside from the protocol.




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 PDUExtract 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.ind(AARE)

AARE APDUSet 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 19 - MSC for successful Application Association establishment




Once the lower layer connections are established, the Client CF shall assemble an Application Association Request (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 first shall give the received AARQ APDU to the ACSE, which shall extract the ACSE related parameters, than 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 give then back the control to the CF, which shall invoke the COSEM-OPEN.indication service primitive with the appropriate parameters, extracted from the AARQ APDU11, to the COSEM Server Application Process. At the same time, the Server Control Function shall enter the ‘ASSOCIATION PENDING’ state. The Server Application Process shall analyse the received COSEM-OPEN.indication primitive, and decide whether it accepts the proposed Application Associations or not12. Following this verification, the COSEM Server Application Process shall invoke the COSEM-OPEN.response service to indicate the acceptance or non-acceptance of the proposed association. In case of success, the CF shall assemble the appropriate AARE APDU, then shall send it to the remote Client Application Layer via the existing supporting layer connection, and the Server Application Layer shall enter the ‘ASSOCIATED’ state. From this moment, the Server is able to receive data communication service .request(s) and send .responses within this association. 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 Application Process via the COSEM-OPEN.confirm service primitive. At the same time, the Client Application Layer shall enter the ‘ASSOCIATED’ state. From this moment, the Application Association is established within the negotiated Application- and xDLMS Contexts. more details, see complete Green Book ....

7.4 The 3-layer, connection-oriented, HDLC based profile

7.4.1 Introduction The COSEM Application Layer, is the only layer which contains COSEM specific service element, the Extended DLMS Application Service Element (xDLMS). This Application Layer may be used with a variety of lower layer protocols to accomplish the communication function. A full protocol stack – including the Application Layer – is called communication profile. (See 3.1). A communications profile is characterised by: • the lower protocol layers; • the type (Connection-Oriented or Connectionless) of the Application Control Service Element (ACSE)

included in the Application Layer.

11 Some service parameters of this COSEM-OPEN.indication primitive (Address information, User_Information, Service_Class) do not

come from the AARQ APDU, but from the supporting layer frame carrying the AARQ APDU. 12 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.




The first communication profile specified and standardised for COSEM is the 3-layer, Connection-Oriented, HDLC based profile. This profile consists of three protocol layers: • the COSEM Application Layer, including the Connection Oriented ACSE in the Application Layer, as

defined in this document; • the Data Link Layer, based on the ISO/IEC 13239:2000 HDLC protocol, as defined in Clause 6 or in IEC

62056-46, • the Physical Interface Layer, as defined in Clause 4 or in IEC 62056-42.

7.4.2 The HDLC-based Data Link Layer - Overview For the purposes of this profile, the following selections from the HDLC standard ISO/IEC 13239:2000 have been made: • unbalanced connection-mode data link operation13; • two-way alternate data transfer; • the selected HDLC class of procedure is UNC (Unbalanced operation Normal response mode Class),

extended with UI frames; • frame format type 3; • non-basic frame format transparency. In the unbalanced connection-mode data link operation, two or more stations are involved. The primary station assumes responsibility for the organisation of data flow and for unrecoverable data link level error conditions by sending command frames. The secondary station(s) respond by sending response frames. The basic repertoire of commands and responses of the UNC class of procedures is extended with the Unnumbered Information (UI) frame to support connection-less data communication services, in order to provide multi- and broadcasting and non-solicited information transfer from Server to the Client. Using the unbalanced connection-mode data link operation implies that the Client- and Server side Data Link Layers are different in terms of the sets of HDLC frames and their state machines. more details, see complete Green Book ....

13 In COSEM, the primary station corresponds to the Client application, and the secondary station corresponds to the secondary station