IEC 62056-46:2002

INTERNATIONAL IEC
STANDARD
62056-46
First edition
2002-02
Electricity metering –
Data exchange for meter reading,
tariff and load control –
Part 46:
Data link layer using HDLC protocol
Reference number
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the
60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.
Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,
edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the
base publication incorporating amendment 1 and the base publication incorporating
amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
The on-line catalogue on the IEC web site (www.iec.ch/catlg-e.htm) enables
you to search by a variety of criteria including text searches, technical
committees and date of publication. On-line information is also available on
recently issued publications, withdrawn and replaced publications, as well as
corrigenda.
• IEC Just Published
This summary of recently issued publications (www.iec.ch/JP.htm) is also
available by email. Please contact the Customer Service Centre (see below) for
further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:
Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
INTERNATIONAL IEC
STANDARD
62056-46
First edition
2002-02
Electricity metering –
Data exchange for meter reading,
tariff and load control –
Part 46:
Data link layer using UDLC protocol
 IEC 2002  Copyright - all rights reserved
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission 3, rue de Varembé Geneva, Switzerland
Telefax: +41 22 919 0300 e-mail: inmail@iec.ch IEC web site http://www.iec.ch
Commission Electrotechnique Internationale
PRICE CODE
XB
International Electrotechnical Commission
For price, see current catalogue

– 2 – 62056-46  IEC:2002(E)
CONTENTS
FOREWORD .4
1 Scope.6
2 Normative references .6
3 Terms, definitions and abbreviations .7
4 Overview .8
4.1 The LLC sub-layer.8
4.2 The MAC sub-layer.8
4.3 Specification method .8
5 The LLC sub-layer .9
5.1 The role of the LLC sub-layer .9
5.2 Service specification for the LLC sub-layer.9
5.2.1 Setting up the Data Link Connection.10
5.2.2 Disconnecting the Data Link Connection.13
5.2.3 Data communication .16
5.3 Protocol specification for the LLC sub-layer.20
5.3.1 Overview .20
5.3.2 LLC protocol data unit (LPDU) structure .20
5.3.3 State transition tables for the LLC sub-layer .21
6 The MAC sub-layer.22
6.1 HDLC selections.22
6.2 Service specification for the MAC sub-layer.22
6.2.1 Setting up the MAC connection.22
6.2.2 Disconnecting the MAC connection.26
6.2.3 Data communication .30
6.3 Physical layer services used by the MAC sub-layer .32
6.3.1 Overview .32
6.3.2 Setting up a physical link .33
6.3.3 Disconnecting the physical link .33
6.3.4 Data communication .33
6.4 Protocol specification for the MAC sub-layer .33
6.4.1 The MAC PDU and the HDLC frame .33
6.4.2 MAC addressing .35
6.4.3 Command and response frames .39
6.4.4 Elements of the procedures .42
6.4.5 State transition diagram for the server MAC sub-layer .57
Annex A (informative) FCS calculation.59
Annex B (informative) Data model and protocol .62
Annex C (informative) Data link layer management services .63

62056-46  IEC:2002(E) – 3 –
Figure 1 – Data Link (LLC) services for setting up the Data Link Connection .10
Figure 2 – Data Link (LLC) services for disconnecting the Data Link Connection .13
Figure 3 – Data link layer data communication services .17
Figure 4 – The ISO/IEC 8802-2 LLC protocol data unit format.20
Figure 5 – The used LLC protocol data unit format.20
Figure 6 – MAC sub-layer services for setting up the MAC (DL) connection at the client
and server sides .23
Figure 7 – MAC sub-layer services for disconnecting the MAC (DL) connection at the
client and server sides .26
Figure 8 – MAC sub-layer data communication services .30
Figure 9 – Physical layer services used by the MAC sub-layer.33
Figure 10 – MAC sub-layer frame format (HDLC frame format type 3).34
Figure 11 – Multiple frames.34
Figure 12 – The frame format field .34
Figure 13 – MSC for long MSDU transfer in a transparent manner .51
Figure 14 – Example configuration to illustrate broadcasting.52
Figure 15 – Sending out a pending UI frame with a .response data.53
Figure 16 – Sending out a pending UI frame with a response to a RR frame .54
Figure 17 – Sending out a pending UI frame on receipt of an empty UI frame .54
Figure 18 – State transition diagram for the server MAC sub-layer.58
Figure B.1 – The three-step approach of COSEM .62
Figure C.1 – Layer management services .63
Table 1 – State transition table of the client side LLC sub-layer .21
Table 2 – State transition table of the server side LLC sub-layer.21
Table 3 – Table of reserved client addresses .37
Table 4 – Table of reserved server addresses.37
Table 5 – Handling inopportune address lengths.39
Table 6 – Command and response frames .39
Table 7 – Control field format.40
Table 8 – Example for parameter negotiation values with the SNRM/UA frames .47
Table 9 – Summary of MAC Addresses for the example.52
Table 10 – Broadcast UI frame handling .52

– 4 – 62056-46  IEC:2002(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
___________
ELECTRICITY METERING – DATA EXCHANGE
FOR METER READING, TARIFF AND LOAD CONTROL –
Part 46: Data link layer using HDLC protocol
FOREWORD
1) The IEC (International Electrotechnical Commission) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of the IEC is to promote inter-
national co-operation on all questions concerning standardization in the electrical and electronic fields. To this
end and in addition to other activities, the IEC publishes International Standards. Their preparation is entrusted
to technical committees; any IEC National Committee interested in the subject dealt with may participate in this
preparatory work. International, governmental and non-governmental organizations liaising with the IEC also
participate in this preparation. The IEC collaborates closely with the International Organization for Standardiza-
tion (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of the IEC on technical matters express, as nearly as possible, an interna-
tional consensus of opinion on the relevant subjects since each technical committee has representation from all
interested National Committees.
3) The documents produced have the form of recommendations for international use and are published in the form
of standards, technical specifications, technical reports or guides and they are accepted by the National Com-
mittees in that sense.
4) In order to promote international unification, IEC National Committees undertake to apply IEC International
Standards transparently to the maximum extent possible in their national and regional standards. Any diver-
gence between the IEC Standard and the corresponding national or regional standard shall be clearly indicated
in the latter.
5) The IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with one of its standards.
The International Electrotechnical Commission (IEC) draws attention to the fact that it is claimed that compliance
with this International Standard may involve the use of a maintenance service concerning the stack of protocols on
which the present standard IEC 62056-46 is based.
The IEC takes no position concerning the evidence, validity and scope of this maintenance service.
The provider of the maintenance service has assured the IEC that he is willing to provide services under reason-
able and non-discriminatory terms and conditions for applicants throughout the world. In this respect, the statement
of the provider of the maintenance service is registered with the IEC. Information may be obtained from:
DLMS User Association
Geneva / Switzerland
www.dlms.ch
International Standard IEC 62056-46 has been prepared by IEC technical committee 13:
Equipment for electrical energy measurement and load control.
The text of this standard is based on the following documents:
FDIS Report on voting
13/1267/FDIS 13/1273/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 3.
________
Device Language Message Specification.

62056-46  IEC:2002(E) – 5 –
Annexes A, B and C are for information only.
The committee has decided that the contents of this publication will remain unchanged until
2006. At this date, the publication will be
• reconfirmed;
• withdrawn;
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

– 6 – 62056-46  IEC:2002(E)
ELECTRICITY METERING – DATA ECHANGE
FOR METER READING, TARIFF AND LOAD CONTROL –
Part 46: Data link layer using HDLC protocol
1 Scope
This part of IEC 62056 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.
Annex B gives an explanation of the role of data models and protocols in electricity meter
data exchange.
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
IEC 60050-300:2001, International Electrotechnical Vocabulary –Electrical and electronic
measurements and measuring instruments – Part 311: General terms relating to measure-
ments – Part 312: General terms relating to electrical measurements – Part 313: Types of
electrical measuring instruments – Part 314: Specific terms according to the type of instru-
ment
IEC/TR 62051:1999, Electricity metering –Glossary of terms
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
1)
exchange
________
1)
To be published.
62056-46  IEC:2002(E) – 7 –
IEC 62056-53, Electricity metering – Data exchange for meter reading, tariff and load control
1)
– Part 53 – COSEM Application layer
IEC 62056-61, Electricity metering – Data exchange for meter reading, tariff and load control
1)
– Part 61 – OBIS Object Identification System
IEC 62056-62, Data exchange for meter reading, tariff and load control – Part 62: Interface
1)
Classes
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 13239:2000, Information Technology – Telecommunications and information ex-
change between systems – High-level data link control (HDLC) procedures
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purpose of this part of IEC 62056, the definitions found in IEC 60050-300 and IEC/TR
62051 apply.
3.2 Abbreviations
APDU Application layer Protocol Data Unit
COSEM COmpanion Specification for Energy Metering
DISC DISConnect (an HDLC frame type)
DL Data Link
DM Disconnected Mode (an HDLC frame type)
DPDU Data link Protocol Data Unit
DSAP Data link Service Access Point
DSDU Data link Service Data Unit
FCS Frame Check Sequence
FRMR FRaMe Reject (an HDLC frame type)
HCS Header Check Sequence
HDLC High-level Data Link Control
I Information (an HDLC frame type)
LLC Logical Link Control (Sub-layer)
LSAP LLC sub-layer Service Access Point
LPDU LLC Protocol Data Unit
LSB Least Significant Bit
LSDU LLC Service Data Unit
MAC Medium Access Control (sub-layer)
MSAP MAC sub-layer Service Access Point (here it is equal to the HDLC address)
MSB Most Significant Bit
MSDU MAC Service Data Unit
NDM Normal Disconnected Mode
NRM Normal Response Mode
N(R) Receive sequence Number
________
1)
To be published.
– 8 – 62056-46  IEC:2002(E)
N(S) Send sequence Number
P/F Poll/Final bit
PDU Protocol Data Unit
PH Physical layer
PSDU Physical layer Service Data Unit
RNR Receive Not Ready (an HDLC frame type)
RR Receive Ready (an HDLC frame type)
SAP Service Access Point
SDU Service Data Unit
SNRM Set Normal Response Mode (an HDLC frame type)
TWA Two Way Alternate
UA Unnumbered Acknowledgement (an HDLC frame type)
UI Unnumbered Information (an HDLC frame type)
UNC Unbalanced operation Normal response mode Class
USS Unnumbered Send Status
V(R) Receive state Variable
V(S) Send state Variable
4 Overview
4.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
is used in an extended class I operation, where the LLC sub-layer provides the standard con-
nectionless 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 5.
4.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 exam-
ple 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.
4.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 proce-
dures. Services are the standard way to specify communications between protocol layers.
Through the use of four types of transactions, commonly known as service primitives (Re-
quest, Indication, Response and Confirm) the service provider co-ordinates and manages the
communication between the users. Using service primitives is an abstract, implementation-

62056-46  IEC:2002(E) – 9 –
independent way to specify the transactions between protocol layers. Given this abstract na-
ture 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 spe-
cific 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 ex-
ample 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.
NOTE Data link layer management services are explained in Annex C.
This standard specifies values for parameters of the first category only. The protocol specifi-
cation 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 ex-
changing Data Link messages;
• the interactions that are the result of using the protocol layer.
5 The LLC sub-layer
5.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 op-
eration, 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 connec-
tion, the LLC sub-layer provides transparent MAC connection/disconnection services to the
service user protocol layer.
5.2 Service specification for the LLC sub-layer
This subclause specifies the services required of, or by, the LLC sub-layer at the logical in-
terfaces with the Service User layer and the MAC sub-layer, using connection-oriented proce-
dures. As the Service User layer ‘sees’ the services of the LLC sub-layer as the services of
the data link layer, in this standard these services are called data link layer services and the
prefix “DL” to designate these services is used.

– 10 – 62056-46  IEC:2002(E)
5.2.1 Setting up the Data Link Connection
Overview
Figure 1 shows the services provided by the primary station (client side) and secondary sta-
tion (server side) data link layers to the service user layer for data link connection establish-
ment.
Primary station / Client side Secondary station / Server side
Service user layer
Data Link Layer
LLC sub-layer
MAC sub-layer
Physical Layer
IEC  248/02
Figure 1 – 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 trans-
parently transmit these services to/from the “real” service provider MAC sub-layer as the ap-
propriate MA-CONNECT.xxx service primitive.
5.2.1.1 DL-CONNECT.request
Function
This service primitive is provided only at the client side. The Service User layer invokes this
primitive to request set-up of a data link connection.
DL-CONNECT.req
DL-CONNECT.cnf
DL-CONNECT.ind
DL-CONNECT.res
62056-46  IEC:2002(E) – 11 –
Service parameters
The semantics of the primitive is as follows:
DL-CONNECT.request
(
1)
Destination_MSAP ,
Source_MSAP,
User_Information
)
The Destination_MSAP and Source_MSAP parameters identify the referenced data link layer
connection. The addressing scheme for the MAC layer is discussed in 6.4.2. The specification
of the contents of the optional User_information parameter is not within the scope of this
standard.
Use
The client side Service User layer entity invokes the DL-CONNECT.request primitive, when it
wants to set up a connection with a peer data link layer.
5.2.1.2 DL-CONNECT.indication
Function
This service primitive is provided only at the server side. The LLC sub-layer uses this primi-
tive to indicate to the Service User layer that the peer data link layer requested a Data Link
connection.
Service parameters
The semantics of the primitive is as follows:
DL-CONNECT.indication
(
Destination_MSAP,
Source_MSAP,
User_Information
)
The Destination_MSAP and Source_MSAP identify the referenced data link layer connection.
The addressing scheme for the MAC layer is discussed in 6.4.2. The specification of the con-
tents of the optional User_information parameter is not within the scope of this standard.
Use
The server side LLC sub-layer generates this primitive following the reception of an MA-
CONNECT.indication primitive from the MAC sub-layer.
5.2.1.3 DL-CONNECT.response
Function
This service primitive is provided only at the server side. The Service User layer invokes this
service primitive in order to indicate to the local data link layer whether the previously pro-
posed data link connection can be accepted by the service user layer or not.
Service parameters
The semantics of the primitive is as follows:
________
1)
MSAP in this environment is equal to the HDLC address.

– 12 – 62056-46  IEC:2002(E)
DL-CONNECT.response
(
Destination_MSAP,
Source_MSAP,
Result,
User_Information
)
The Destination_MSAP and Source_MSAP parameters identify the referenced data link layer
connection. The Result parameter (OK, NOK, NO_RESPONSE) indicates whether the pro-
posed connection could be accepted or not, and whether a response frame should be sent or
not.
• Result == OK. This means that the received connect request can be accepted by the
service user layer.
• Result == NOK. This means that the received connect request cannot be accepted by the
service user layer.
• RESULT == NO_RESPONSE: This means that no response to the DL-
CONNECT.indication shall be sent.
The User_Information parameter may be present only when the Result is NOK. The specifica-
tion of its content is not within the scope of this standard.
NOTE The Result parameter indicates only whether the Data Link Connection can or cannot be accepted by the
service user higher layers. The data link layer itself may refuse a proposed connection, (e.g. because it supports
only one connection at a given moment, thus it is not able to support a second one) even if the higher layers could
accept it (Result==OK).
Use
The server side Service User layer entity invokes the DL-CONNECT.response primitive to in-
dicate the result of a previously received request for connection.
5.2.1.4 DL-CONNECT.confirm
Function
This service primitive is provided only at the client side and it can be originated remotely or
locally. The data link layer generates this primitive to indicate to the Service User layer the
result of a previously received DL-CONNECT.request service.
Service parameters
The semantics of the primitive is as follows:
DL-CONNECT.confirm
(
Destination_MSAP,
Source_MSAP,
Result,
User_Information
)
The Destination_MSAP and Source_MSAP parameters reference data link layer connection,
which is confirmed by the service. The Result parameter (OK, NOK-REMOTE, NOK-LOCAL,
NO_RESPONSE) indicates the result of the previously invoked DL-CONNECT.request serv-
ice.
• Result == OK. This means that the connect request was accepted by the remote station.
• Result == NOK-REMOTE. This means that the connect request was not accepted by the
remote station.
62056-46  IEC:2002(E) – 13 –
• Result == NOK-LOCAL. This means that a local error has occurred, for example the serv-
ice user layer tried to establish an already existing data link connection.
• RESULT == NO_RESPONSE. This means that there was no response from the remote
station to the connect request.
The User_Information parameter is present only when the Result is NOK-REMOTE. The
specification of its content is not within the scope of this standard.
Use
The LLC sub-layer indicates the reception of an MA-CONNECT.confirm primitive to the Serv-
ice User layer by using this primitive.
5.2.2 Disconnecting the Data Link Connection
5.2.2.1 Overview
Figure 2 shows the services provided by the client and server side data link layers to the
Service User layer for disconnecting a Data Link connection.
Primary station / Client side
Secondary station / Server side
Service user layer
Data Link Layer
LLC sub-layer
MAC sub-layer
Physical Layer
IEC  249/02
Figure 2 – Data Link (LLC) services for disconnecting the Data Link Connection
Data link disconnection can only be requested by the client device, so the DL-
DISCONNECT.request and .confirm services are provided only at the client side. On the other
hand, the remotely initiated (by the client) DL-DISCONNECT.indication and .response serv-
ices are provided only at the server side.
NOTE When this data link layer is used together with the COSEM application layer as defined in IEC 62056-53,
DL-DISCONNECT services are used to release existing Application Associations.
DL-DISCONNECT.req
DL-DISCONNECT.cnf
DL- DISCONNECT.ind
DL- DISCONNECT.ind
DL- DISCONNECT.res
– 14 – 62056-46  IEC:2002(E)
Both the client and server side LLC sub-layers provide a locally initiated DL-
DISCONNECT.indication service, to signal a non-solicited disconnection, due to an unex-
pected loss of the data link and/or physical connection.
The DL-DISCONNECT.request service primitive – in case of a locally detected error – can be
also locally confirmed.
These services are in fact provided by the MAC sub-layer: the LLC sub-layer shall transpar-
ently transmit these services to/from the MAC sub-layer as the appropriate MA-
DISCONNECT.xxx service primitive.
5.2.2.2 DL-DISCONNECT.request
Function
This service primitive is provided only at the client side. It is invoked by the Service User layer
to request disconnecting of an existing Data Link connection.
Service parameters
The semantics of the primitive is as follows:
DL-DISCONNECT.request
(
Destination_MSAP,
Source_MSAP,
User information
)
The Destination_MSAP and Source_MSAP parameters specify the data link connection to be
disconnected. The specification of the contents of the optional User_information parameter is
not within the scope of this standard.
Use
The client side Service User layer entity invokes this primitive to request a disconnection of a
data link connection to peer data link layer(s).
5.2.2.3 DL-DISCONNECT.indication
Function
This service primitive is provided at the client side and at the server side.
• The server side data link layer generates this primitive to indicate to the Service User
layer that the peer data link layer requests the disconnection of a data link connection.
• On both the server and client sides, this primitive is used to indicate that the data link
and/or physical connection abort occurred in a non-solicited manner (e.g. the physical line
has been disconnected).
Service parameters
The semantics of the primitive is as follows:
DL-DISCONNECT.indication
(
Destination_MSAP,
Source_MSAP,
Reason,
Unnumbered Send Status,
User Information
62056-46  IEC:2002(E) – 15 –
)
The Destination_MSAP and Source_MSAP parameters specify the local and remote MSAPs
of the terminated connection.
The Reason parameter (REMOTE, LOCAL_PHY, LOCAL_DL) indicates the reason for the DL-
DISCONNECT.indication invocation.
• Reason == REMOTE. This means that the data link layer received a disconnection request
from the client side. This case may happen only at the server side.
• Reason == LOCAL_DL. This means that there was a fatal data link connection failure.
• Reason == LOCAL_PHY. This means that there was a fatal physical connection failure.
The value of the USS parameter indicates whether at the moment of the DL-
DISCONNECT.indication service invocation the data link layer has (USS==TRUE) or does not
have (USS==FALSE) pending UI message(s).
The User Information field may be present only when Reason == REMOTE. The specification
of the contents of this parameter is not within the scope of this standard.
Use
The LLC sub-layer generates this primitive following the reception of an MA-
DISCONNECT.indication primitive.
5.2.2.4 DL-DISCONNECT.response
Function
This service primitive is provided only at the server side. The Service User layer invokes this
service primitive in order to indicate to the data link layer whether the previously proposed
data link disconnection can be accepted by the Service User layer or not. As in this environ-
ment the server has no right to refuse the disconnection, the response depends only whether
the referenced Data Link connection is existing or not.
Service parameters
The semantics of the primitive is as follows:
DL-DISCONNECT.response
(
Destination_MSAP,
Source_MSAP,
Result
)
The Destination_MSAP and Source_MSAP parameters specify the local and remote MSAPs
involved in the connection being disconnected. The Result parameter can have values OK,
NOK and NO_RESPONSE.
• Result == OK. This means that the received disconnect request refers to an existing
higher layer connection.
• Result == NOK. This means that the received disconnect request refers to a non-existing
higher layer connection.
• RESULT == NO_RESPONSE: This means that no response to the DL-
DISCONNECT.indication shall be sent.

– 16 – 62056-46  IEC:2002(E)
Use
The server side Service User layer invokes the DL-DISCONNECT.response primitive to indi-
cate the result of a previously received request for disconnecting the data link connection.
5.2.2.5 DL-DISCONNECT.confirm
Function
This service primitive is provided only at the client side. The data link layer generates this
primitive to indicate to the Service User layer the result of a previously received DL-
DISCONNECT.request service. This service can be originated remotely or locally.
Service parameters
The semantics of the primitive is as follows:
DL-DISCONNECT.confirm
(
Destination_MSAP,
Source_MSAP,
Result
)
The Destination_MSAP and Source_MSAP parameters specify the local and remote MSAPs
of the terminated connection. The Result parameter (OK, NOK, NO_RESPONSE) indicates
the result of the attempt to close the data link connection.
• Result == OK. This means that the disconnect request was accepted by the remote sta-
tion.
• Result == NOK. This means that the disconnect request was not accepted by the remote
station.
• Result == NO_RESPONSE. This means that there was no response from the remote sta-
tion to the disconnect request.
Use
The client side LLC sub-layer indicates the reception of an MA-DISCONNECT.confirm primi-
tive to the Service User layer using this primitive.
5.2.3 Data communication
5.2.3.1 Overview
Figure 3 shows the data communication services provided by the data link layer to the Service
User layer to exchange data.
62056-46  IEC:2002(E) – 17 –
Primary station / Client side Secondary station / Server side
Service user layer
Data Link Layer
LLC sub-layer
MAC sub-layer
Physical Layer
IEC  250/02
Figure 3 – Data link layer data communication services
In addition to the two standard .request and .indication services, a DL-DATA.confirm service
is also provided at the server side. This service is necessary for transparent long message
transfers, specified in 6.4.4.5.
5.2.3.2 DL-DATA.request
Function
The Service User layer invokes this primitive when data need to be transmitted to the peer
layer entity(ies).
Service parameters
The semantics of the primitive is as follows:
DL-DATA.request
(
Destination_LSAP,
Source_LSAP,
LLC_Quality,
Destination_MSAP,
Source_MSAP,
Frame_type,
Data
)
DL-DATA.req
DL-DATA.ind
DL-DATA.ind
DL-DATA.req
DL-DATA.cnf
– 18 – 62056-46  IEC:2002(E)
The Source_LSAP and Destination_LSAP parameters specify the referenced data link layer
1)
connection . The value of the LLC_Quality parameter is used as the Control field of the
2)
PDU . See also 5.3.2.
The Source_MSAP and Destination_MSAP parameters specify the local and remote MSAPs
involved in the data unit transmission. The Destination_MSAP can be an individual address, a
group address, or a special HDLC address (ALL_STATION, NO_STATION, etc.). Please refer
to 6.4.2.4.
The Frame_Type parameter indicates for the data link layer which type of frame shall be sent.
Valid frame types are different for the client and server sides. Client side valid frame types
are I_COMPLETE and UI. On the server side valid frame types are I_COMPLETE,
I_FIRST_FRAGMENT, I_FRAGMENT, I_LAST_FRAGMENT, and UI. See also 6.4.3.
The Data parameter contains the Service User LSDU to be transferred to the peer layer. This
parameter may be empty (e.g. when Frame_type == UI, but the UI frame contains no data).
Use
The DL-DATA.request primitive is invoked by the Service User layer entity to request sending
of a protocol data unit to a single peer application entity or, in the case of multicasting and
broadcasting, to multiple peer application entities.
The receipt of this primitive shall cause the LLC sub-layer to append the LLC specific fields
3)
(the two LLC addresses and the LLC_Quality parameter) to the received LSDU, and to pass
the properly formed LPDU to the MAC sub-layer (by invoking the MA-DATA.request primitive)
for transferring it to the peer LLC sub-layer.
5.2.3.3 DL-DATA.indication
Function
This primitive is used to transfer the received data from the data link layer to its Service User
layer.
Service parameters
The semantics of the primitive is as follows:
DL-DATA.indication
(
Destination_LSAP,
Source_LSAP,
LLC_Quality,
Destination_MSAP,
Source_MSAP,
Frame_type,
Data
)
The Source_LSAP and Destination_LSAP identify the referenced data link layer connection.
The value of the LLC_Quality parameter is used as the Control field of the PDU. See
also 5.3.2.
________
1)
For COSEM purposes, the value of the Destination_LSAP parameter is constant and equal to E6 . The
H
value of the Source_LSAP parameter is E6H or E7H depending on whether the Data field corresponds to a
command or to a response.
2) For COSEM purposes, the value of the LLC_Quality parameter is set to 0, and reserved for future use.
3) When Frame_type == I_FRAGMENT or I_LAST_FRAGMENT, no LLC specific field is appended to the
LSDU.
62056-46  IEC:2002(E) – 19 –
The Source_MSAP and Destination_MSAP parameters specify the local and remote MSAPs
involved in the data unit transmission. The Destination_MSAP can be an individual address, a
group address, or a special HDLC address (ALL_STATION, NO_STATION, etc.). Please refer
to 6.4.2.4.
The Frame_Type parameter indicates for the Service User layer which type of frame has been
received. Valid frame types are I_COMPLETE and UI. See also 6.4.3.
The Data parameter contains the Service User layer protocol data unit sent by the peer.
Use
The DL-DATA.indication primitive is used to indicate to the Service User layer entity the re-
ceipt of a protocol data unit from a peer layer entity.
This primitive is generated following the reception of an MA-DATA.indication service issued
by the local MAC sub-layer. First, the LLC sub-layer shall check the LLC addresses. If these
are correct, it shall remove the LLC specific fields (the two LLC addresses and the
LLC_Quality parameter) from the received LPDU, and shall pass the remaining, properly for-
matted LSDU to the service user protocol layer with the help of the DL-DATA.indication serv-
ice primitive. Otherwise the received LPDU shall be discarded.
5.2.3.4 DL-DATA.confirm
Function
This service primitive is provided only at the server side. The data link layer generates this
primitive to indicate to the Service User layer the result of a previously received DL-
DATA.request service, when this .request service has been invoked with Frame_type =
I_FIRST_FRAGMENT, I_FRAGMENT or I_LAST_FRAGMENT. The DL-DATA.confirm service
primitive is generated when the previously requested LSDU has been successfully sent to the
peer data link layer.
Service parameters
The semantics of the primitive is as follows:
DL-DATA.confirm
(
Destination_LSAP,
Source_LSAP,
Destination_MSAP,
Source_MSAP,
Frame_type,
Result
)
The Destination_LSAP and Source_LSAP parameters identify the referenced data link layer
connection.
The Destination_MSAP and Source_MSAP parameters identify the remote and local MSAP-s
involved in the data unit transmission.
The Frame_Type parameter indicates the type of the frame which is confirmed. Valid frame
types are I_FIRST_FRAGMENT, I_FRAGMENT and I_LAST_FRAGMENT.
The value of the Result parameter indicates the result of the transmission of the received
LSDU. Possible values are OK and NOK.

– 20 – 62056-46  IEC:2002(E)
Use
The server side LLC sub-layer indicates the reception of an MA-DATA.confirm primitive to the
Service User layer by using this primitive.
5.3 Protocol specification for the LLC sub-layer
5.3.1 Overview
The LLC sub-layer specification is based on LLC type 1, specified in ISO/IEC 8802-2, which
provides a data-link-connectionless-mode service across a data link with minimum protocol
complexity. The presence of this sub-layer in this connection-oriented profile is somewhat ar-
tificial: the LLC sub-layer is used as a kind of a protocol selector, and the ‘real’ data link layer
functionality is ensured by the MAC sub-layer.
The standard LLC frame format is shown in Figure 4. The LLC frame format for this standard
is specified in 5.3.2.
Destination (remote) LSAP Source (local) LSAP Control Information
8 bits 8 bits 8 or 16 bits n*8 bits
IEC  251/02
Figure 4 – The ISO/IEC 8802-2 LLC protocol data unit format
The LLC sub-layer shall transparently transmit the Information Field between the Service User
layer and the MAC sub-layer.
When a DATA.request service invocation is received from the service user protocol layer, the
LLC sub-layer, if required, shall append the LLC specific fields (the tw
...