DLMS / COSEM

What is DLMS?
• DLMS stands for Distribution Line Message Specification.
• It is an international standard established by IEC TC 57 and published as
IEC 61334-4-41.
• The concept was driven forward later to become Device Language
Message Specification with the objective to provide an interoperable
environment for structured modelling and meter data exchange.
• Applications like remote meter reading, remote control and value added
services for metering, any kind of energy, like electricity, water, gas or
heat are supported “Device Language Message specification” it is a
generalized concept for structured modeling of meter data.
• DLMS/COSEM is based on a strict client-server structure. The server is
meant to be within the meter while the client accessing the meter could
be a gateway or the central office. Other use cases where the server is
within the gateway and the client is in the central office are also feasible.
 The key characteristics of data exchange using
DLMS/COSEM are the following:
• Metering devices can be accessed by various parties: clients and third parties;
• Mechanisms to control access to the resources of the metering device are
provided; these mechanisms are made available by the DLMS/COSEM AL and
the COSEM objects (“Association SN / LN” object, “Security setup” object);
• Security and privacy is ensured by applying cryptographical protection to
xDLMS messages and to COSEM data;
• Low overhead and efficiency is ensured by various mechanisms including
selective access, compact encoding and compression;
• At a metering site, there may be single or multiple metering devices. In the
case of multiple metering devices at a metering site, a single access point can
be made available;
• Data exchange may take place either remotely or locally. Depending on the
capabilities of the metering device, local and remote data exchange may be
performed simultaneously without interfering with each other;
• Various communication media can be used on local networks (LN),
neighbourhood networks (NN) and wide area networks (WAN).
 The key characteristics of data exchange using
DLMS/COSEM are the following:
• DLMS/COSEM includes authentication and confidentiality services based on
symmetric encryption. The protocol does not allow the use of TLS/SSL which
could realize these services with asymmetric keys. Support for asymmetric
encryption is being worked on by CENELEC in WG 02 of TC 13.
• IEC 61850 works according to the same client-server principle as
DLMS/COSEM. The server includes an interface object model which can be
accessed through standardized services.
• DLMS/COSEM has the advantage over SML that it is already an international
standard that is widely used in Europe. Numerous parties are working to add
missing features to the standard. The fact that DLMS/COSEM specifies its own
security mechanism is not necessarily an advantage. This way it restricts the
security to symmetric key encryption. If meters should combine their measured
data with digital signatures the meter would need asymmetric keys anyways
and could use the same key pairs for SSL/TLS, if this were allowed.
 What is the DLMS User Association?
• The DLMS Use Association is a non-profit organisation, located in Geneva,
Switzerland and formed in 1997.
• Its mission is to develop, promote and maintain the DLMS/COSEM specification.
• It provides an information exchange forum for users, manufacturers and
system providers, test houses and standardisation bodies. It also provides a
conformance testing and certification scheme for metering equipment
implementing the specification.
• The DLMS UA is formally liased with IEC TC 13 WG 14.
• It address the needs of the metering industry for a standardised protocol for
metering Services are:
• Specification
• Development and maintenance
• Registration of standard elements
• Conformance certification
• Promotion
• Support
 DLMS Standard Books:
1) Blue Book:-Specifies the DATA MODEL comprising the COSEM interface classes
and OBIS codes for the various energy types.

2) Green Book:-Specifies the PROTOCOLS with DLMS on top, for the various
media-specific communication profiles, based on widely used ISO/IEC, Internet,
NIST and FIPS standards.

3) Yellow Book:-Specifies CONFORMANCE TEST plans for the COSEM object

model and the communication layers, and describes the testing and
certification process.

4) White Book:-GLOSSARY OF TERMS helps to understand the specification.

 What is COSEM?
• “Companion Specifications for Energy Metering” is an interface model which
sets the rules for exchanging data with energy meters.

• It provides a view of the functionality available via communication interfaces.

• COSEM achieves this by using object modelling techniques to model all

functions of the meter, without making any assumptions about which functions
need to be supported, how those functions are implemented and how the data
are transported. The formal specification of COSEM interface classes forms a
major part of COSEM.

• To process and manage the information it is necessary to uniquely identify all

data items in a manufacturer-independent way. The definition of OBIS, the
Object Identification System is another essential part of COSEM. It is based on
DIN 43863-3:1997, Electricity meters – Part 3: Tariff metering device as
additional equipment for electricity meters – EDIS – Energy Data Identification
System.
 What is COSEM?
• The set of OBIS codes has been considerably extended over the years to meet
new needs. COSEM models the utility meter as a server application used by
client applications that retrieve data from, provide control information to, and
instigate known actions within the meter via controlled access to the COSEM
objects.

• The clients act as agents for third parties i.e. the business processes of energy
market participants. The standardized COSEM interface classes form an
extensible library. Manufacturers use elements of this library to design their
products that meet a wide variety of requirements. The server offers means to
retrieve the functions supported, i.e. the COSEM objects instantiated. The
objects can be organized to logical devices and application associations and to
provide specific access rights to various clients.
 Three steps approach of DLMS/COSEM: Modelling-
Messaging-Transporting
1) Modelling : This covers the data model of metering equipment as well as rules
for data identification. The data model provides a view of the functionality of
the meter, as it is available at its interface(s). It uses generic building blocks to
model this functionality. The model does not cover internal, implementation-
specific issues.
2) Messaging : A messaging method to communicate with the model and to turn
the data to a series of bytes. This covers the communication services and
protocols for mapping the elements of the data model to application protocol
data units (APDU).
3) Transporting : A transporting method to carry the information between the
metering equipment and the data collection system. This covers the services
and protocols for the transportation of the messages through the
communication channel.
Three steps approach of DLMS/COSEM: Modelling-
Messaging-Transporting
 What is OBIS?
• OBIS is a object identification system
• OBIS codes identify data items used in metering equipment, in a hierarchical
structure using six value groups A to F,

• The value group A defines the media (energy type) to which the metering is
related. Value group A
0: Abstract objects
1: Electricity related objects
4: Heat cost allocator related objects
5: Cooling related objects
6: Heat related objects
7: Gas related objects
8: Cold water related objects
9: Hot water related objects
 What is OBIS?
• OBIS is a object identification system
• OBIS codes identify data items used in metering equipment, in a hierarchical
structure using six value groups A to F,

• The value group B defines the channel number, i.e. the number of the input of
a metering equipment having several inputs for the measurement of energy of
the same or different types
Value group B
0: No channel specified
1: Channel 1
…
64: Channel 64
65…127: Utility specific codes
128…199: Manufacturer specific codes
200…255: Reserved
 What is OBIS?
• OBIS is a object identification system
• OBIS codes identify data items used in metering equipment, in a hierarchical
structure using six value groups A to F,

• The value group C defines the abstract or physical data items related to the
information source concerned, for example current, voltage, power, volume,
temperature. The definitions depend on the value of the value group A.

• The value group D defines types, or the result of the processing of physical
quantities identified with the value groups A and C, according to various
specific algorithms

• The range for value group E is 0 to 255. It can be used for identifying further
classification or processing of values defined by value groups A to D,

• The range for value group F is 0 to 255. In all cases, if value group F is not
used, it is set to 255.
 Basic Structure of DLMS/COSEM
• The COSEM object model (Companion Specification for Energy Metering), described in the Blue
Book defines interface classes close to the metering domain, like registers, profiles, clocks,
schedules. An interface class definition describes the attributes with the data types usable, and
methods allowing the modification of the attributes. Objects may interact with each other to
perform functions like tarification, end of billing period etc. Handling of special events, like clock
setting, power failures, is also defined.
• The functionality of the meter – be it simple or complex - is modelled by instantiating the necessary
number of the appropriate objects, identified and referenced by their logical name attributes as
defined in theOBIS (Object Identification System) standard. Functionality can be freely organised to
several logical devices within a physical device or can be even spread across several physical
devices. COSEM does not standardise and by no way limits the functionality of the meter. The
model supports a wide range of functions and new ones are continuously added. This year, for
example, a range of objects modelling advanced power quality and loss compensation features
have been defined.
• The DLMS-based protocols (Device Language Message Specification) transport the data
represented by attributes and methods of the objects. Access to these is the task of the DLMS
 Basic Structure of DLMS/COSEM
• The DLMS-based protocols (Device Language Message Specification) transport the data
represented by attributes and methods of the objects. Access to these is the task of the DLMS
services provided by the COSEM application layer, the top layer in any protocol stack. Data
exchange is based on the Client/Server paradigm: the data collection system requests services and
the meter provides them. In addition, the meter can initiate reporting events. The DLMS services
are common to all interface classes. This allows defining new ones without affecting the protocol. A
special Association object controls authentication and provides a view of the functionality of the
meter, the objects, their attributes and methods available for a given client. Several associations
may be defined, providing selective access to the various parties, according to their respective
access rights. All data are clearly structured using ASN.1 and efficiently encoded using A-XDR.
Protocol overhead can be significantly reduced by structuring data in profiles and transporting
them in single requests/responses.

• Lower layers of the protocol are selected according to the communication media. For PSTN and
GSM networks, a 3­layer OSI-based protocol stack is defined. The HDLC based data link layer
ensures the integrity of data transport and provides segmentation for long messages, like readout
and load profiles. The physical layer supports the optical port, serial ports and PSTN or GSM
modems. This year a new profile allowing meter data exchange via the internet has been added,
opening the way for DLMS/ COSEM to co-exist with a range of internet applications, like file
transfer, mail service etc. The COSEM application layer is supported by TCP/UDP encapsulated in a
simple wrapper. Below the IP layer, any data link layer and physical layer can be used. The protocols
are described in the new Green Book.
 Objective:-
• The main objective of the COSEM approach is to provide a business domain oriented interface
object model for metering devices and systems while keeping backward compatibility to the
existing DLMS standard. To meet these objectives, COSEM includes an evolution of DLMS.
• Remaining fully compliant to the DLMS standard, COSEM provides amore metering specific view of
the meter through the COSEM interface objects.
• The xDLMS service element of the COSEM application layer is based on DLMS as specified in IEC
61334-4-41.
• A COSEM data exchange session always starts with the AA establishment. This is always initiated by
the client.
• The DLMS services used for accessing attributes and methods of COSEM interface objects are
negotiated between the client and the server with the help of the xDLMS-Initiate service during the
association establishment. If the response is posit ive,the AA is established within the given COSEM
application context and xDLMS context.
• In addition, COSEM specifies a new conformance block extending the number of available DLMS
services.
 Communication Profile
• In general the server and client application processes are located in separate devices and
exchanging messages is done with the help of communication protocol. A complete protocol stack
including the application layer, a physical layer and all protocol layers between these two extreme
layers is called a communication profile. The top layer of the communication protocol is always the
COSEM layer. Currently we are using the HDLC based connection oriented communication profile.
This profile can be used with intelligent modems over the PSTN or GSM network, or over a direct
optical or electrical connection, with a new protocol mode E supporting DLMS/COSEM.

• The client and server COSEM applications use services of the highest protocol layer, that of the
application layer: Consequently, this is the only protocol layer containing COSEM specific
element(s).Data collection system and metering equipment from different vendors following the
COSEM specification can exchange data in an interoperable way.
• A complete protocol stack including the application layer, a physical layer and all protocol layers
between these extreme layers is called a communication profile.

• In our present scope we have used 3 layer HDLC based communication profile.
• Physical layer: Physical layer provides physical media for communication.
• Data Link layer: Communication at data link layer is done in form of frames. At data link layer
negotiation of parameters like maximum information field length –transmit, receive, window
size-transmit, receive is done (Application Association).
• Application Layer : The main component of the client and server COSEM application layers is
the COSEM ASO, which provides services to the COSEM AP, and uses services provided by the
supporting lower layer. Both the client and server side COSEM ASO contains three mandatory
components:
 Communication Profile

• The ACSE. The task of this element is to establish, maintain, and release application associations.
Application association is nothing but an application level connection.
• The Extended DLMS application service element (xDLMS_ASE). The task of this element is to
provide data communication services between COSEM APs. See also 9.5.
• 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.
AARQ request is sent by client to establish connection at COSEM application layer.
 Reference Objects
• Any piece of information modeled by COSEM can be accessed as an attribute or method of a
certain COSEM interface object.
• To access an attribute or method, it has to be referenced. In the metering equipment(server) the
COSEM application layer provides two mechanisms to access the attributes. They are:­
• Logical Name (LN) referencing
• Short Name (SN) referencing
• In the case of LN referencing, COSEM object attributes and methods are referenced via the logical
name (COSEM_Object_Instance_ID) of the COSEM object instance to which they belong.
• In the case of SN referencing, COSEM object attributes and methods are mapped to DLMS named
variables.
• Accordingly, there are two xDLMS ASEs (xDLMS is the data communication services) specified: one
using xDLMS services with LN referencing and one using xDLMS services with SN referencing.
• The data collection system(client) application layer always uses LN referencing. When SN
referencing is used, the attributes and methods of each interface objectare mapped to DLMS
named variables. This is done during the design of the meter. Each named variable is identified
with a short name.
• When SN referencing is used, the DLMS named variables are accessed by the standard DLMS READ
and WRITE services.
• When LN referencing is used, attributes and methods are accessed via the logical name of the
object, specifying the index(es) of the attribute(s) and / or the method(s). Logical names are
defined by OBIS. When LN referencing is used, the attributes and methods are accessed by the
xDLMS GET/SET and ACTION services.
• SN referencing is more suitable for simple devices and LN referencing for complex devices.
Reference Objects
 HDLC Addresses
The DLMS/COSEM AL (Application Layer) is supported by the HDLC based data link layer.
Its main role is to provide a reliable data transfer between the peer layers. It also provides
addressing of the logical devices in such a way, that each logical device is bound to a single HDLC
address.
The Management Logical Device is always bound to the address 0x01. To allow creating
a local network so that several metering devices at a given metering site can be reached through a
single access point, another address, the physical address is also provided by the data link layer.
The logical device addresses are referred to as upper HDLC addresses, while the physical device
address is referred to as a lower HDLC address.
The destination and source link addresses can be of
a) 1-byte
b) 2-byte
c) 4-byte
Depending upon the direction of the frame, both client and server address may be either destination or source.

Extended addressing
i) Address field can be extended (up to 4 octets)
ii) LSB of address octet is reserved to indicate whether the following octet is an extension of address field
HDLC Addresses
 HDLC Addresses
Server Address:
a) Server addresses consists of:­
i) Upper HDLC Address: Logical Device
ii) Lower HDLC Address: Physical Device

b) Lower HDLC Address may be omitted c) Protocol limits HDLC address to be

i) 1 Byte
ii) 2 Bytes
iii) 4 Bytes

One Byte: Only the upper HDLC address present

Upper HDLC Address

Two bytes: one byte upper HDLC address and one byte lower HDLC address is present
Upper HDLC Address Lower HDLC Address

Four bytes: two bytes of upper HDLC address and two bytes of lower HDLC address are present

Upper HDLC Address Upper HDLC Address Lower HDLC Address Lower HDLC Address
HDLC Addresses
 Various time out implemented at server end
• Inactivity time out: If server is kept idle for 60 sec and then request is given for I frame it will not
give any response due to inactivity timeout. This time-out is re-started each time when an octet is
sent or received to/from the PhL. If the Inactivity time-out runs out, the data link layer shall
generate a DL-LM_EVENT.indication that no character has been sent/received during that period,
and re-start the inactivity time-out. The data link layer shall be disconnected. Inter frame timeout:
If request is send by client to server and if next request takes more than inter frame time out, then
it will not give response to request frame and will give error of Inter frame timeout. The maximum
permitted time between the stop bit of a character (octet) and the start bit of the next character
within a frame (Tin) shall be selected to meet the requirements of the physical medium used.
Whenever this time-out occurs in the receiver, the end of the actually received frame shall be
assumed.
• Response timeout : If request is send by client to server and if server takes more than Response
timeout to give response, then it will not give response to request frame and will give error of
Response timeout.
• Disconnection timeout : If disconnection frame is send to server and after Disconnection timeout if
again Disc frame is send to server then server will not give any response and will give error of
disconnection time out.
HDLC Frame structure
HDLC Frame structure
HDLC Frame structure
HDLC Frame structure
 SNRM (Set Normal Response Mode)
• SNRM stands for Set Normal Response Mode. It is one of the commands in the HDLC protocol
which places the secondary station (Server in our case) into NRM (Normal Response Mode). In
NRM only the primary terminal (Client) may initiate data transfer. The Server transmits data only in
response to commands from the Client.

• In SNRM request information field is optional which is used for negotiation of data link layer
parameters. The absence of information field shall be interpreted to mean default values for each
parameter.

• If the secondary station receives a correct SNRM frame, and the requested connection can be
accepted, it shall respond with a UA frame. This UA frame shall carry the result of the HDLC
parameter negotiation. The result shall be calculated by the secondary station by choosing the
smaller value between the proposed value of a parameter (sent with the SNRM frame) and the
value of the corresponding parameter at the secondary station, received with the UA frame.

• The negotiation can be seen in the following SNRM and UA frames.

HDLC Frame structure
 Information transfer command and response
• The function of the information command and response frame – the I frame – is to perform an
information transfer.
The I frame control field shall contain two sequence numbers:
a) N(S), which shall indicate the sequence number associated with the I frame; and
b) N(R), which shall indicate the sequence number (as of the time of transmission) of
the next expected I frame to be received, and consequently shall indicate that the I frames
numbered up to N(R) – 1 inclusive have been received correctly.
• For data integrity reasons, in this profile, the default value of the maximum information field length
– receive and maximum information field length – transmit HDLC parameters is 128 bytes. Other
values may be negotiated at connection establishment time.
• Receive ready (RR) command and response : The Receive ready, RR, frame shall be used by a data
station to:
a) indicate that it is ready to receive an I frame(s); and
b) acknowledge previously received I frames numbered up to N(R) - 1 inclusive.
When transmitted, the RR frame shall indicate the clearance of any busy condition that was
initiated by the earlier transmission of an RNR frame by the same data station.
 Information transfer command and response
• Receive not ready (RNR) command and response : The Receive not ready, RNR, frame shall be
used by a data station to indicate a busy condition, i.e. temporary inability to accept subsequent I
frames. I frames numbered up to N(R) – 1 inclusive shall be considered as acknowledged. The I
frame numbered N(R) and any subsequent I frames received, if any, shall not be considered as
acknowledged; the acceptance status of these frames shall be indicated in subsequent exchanges.
• Set normal response mode (SNRM) command : The SNRM command shall be used to place the
addressed secondary station in the normal response mode (NRM) where all control fields shall be
one octet in length. The secondary station shall confirm acceptance of the SNRM command by
transmission of a UA response at the first respond opportunity. Upon acceptance of this command,
the secondary station send and receive state variables shall be set to zero.
When this command is actioned, the responsibility for all unacknowledged I frames assigned to
data link control reverts to a higher layer. Whether the content of the information field of such
unacknowledged I frames is reassigned to data link control for transmission or not is decided at a
higher layer.
The SNRM command may contain an optional information field that is used for negotiation of data
link parameters and to carry user information transported transparently across the link layer to the
user of the data link.
 Information transfer command and response
• Disconnect (DISC) command : The DISC command shall be used to terminate an operational or
initialization mode previously set by a command. In both switched and non-switched networks, it
shall be used to inform the addressed secondary station(s) that the primary station is suspending
operation and that the secondary station(s) should assume a logically disconnected mode. Prior to
actioning the command, the secondary station shall confirm the acceptance of the DISC command
by the transmission of a UA response. When this command is actioned, the responsibility for all
unacknowledged I frames assigned to data link control reverts to a higher layer. Whether the
content of the information field of such unacknowledged I frames is reassigned to data link control
for transmission or not is decided at a higher layer. An information field may be present in the DISC
command.
• Unnumbered acknowledge (UA) response : The UA response shall be used by the secondary
station to acknowledge the receipt and acceptance of SNRM and DISC commands. The UA response
may contain an optional information field that is used for negotiation of data link parameters.
• Disconnected mode (DM) response : The DM response shall be used to report a status where the
secondary station is logically disconnected from the data link, and is, by system definition, in NDM.
The DM response shall be sent by the secondary station in NDM to request the primary/other
combined station to issue a mode setting command, or if sent in response to the reception of a
mode setting command, to inform the primary station that it is still in NDM and cannot action the
mode setting command. An information field may be present in the DM response. A secondary
station in NDM shall monitor received commands to detect a respond opportunity in order to
(re)transmit the DM response, i.e. no commands (other than UI commands) are accepted until the
disconnected mode is terminated by the receipt of a mode setting command (SNRM).
 Information transfer command and response
• Frame reject (FRMR) response : The FRMR response shall be used by the secondary station in an
operational mode to report that one of the following conditions which is not correctable by
retransmission of the identical frame resulted from the receipt of a frame without FCS error from
the primary station:
• the receipt of a command or a response that is undefined or not implemented;
• the receipt of an I/UI command or response, with an information field which exceeded the
maximum information field length which can be accommodated by the secondary/ combined
station;
• the receipt of an invalid N(R) from the primary/combined station, i.e. an N(R) which identifies
an I frame which has previously been transmitted and acknowledged or an I frame which has
not been transmitted and is not the next sequential I frame awaiting transmission; or
• the receipt of a frame containing an information field when no information field is permitted
by the associated control field.
• The secondary station shall transmit the FRMR response at the first respond opportunity. An
information field that provides the reason for the frame rejection shall be included.
• Unnumbered information (UI) command and response
 Information transfer command and response
• Unnumbered information (UI) command and response : The UI command shall be used to send
information to a secondary station(s) without affecting the V(S) or V(R) variables at any station.
Reception of the UI command is not sequence number verified by the data link procedures.
Therefore, the UI frame may be lost if a data link exception occurs during transmission of the
command, or duplicated if an exception condition occurs during any reply to the command. There
is no specified secondary station response to the UI command. The UI command may be sent
independently of the mode of the data link station (NDM or NRM).

• The UI response shall be used to send information (for example, status, application data,
operation, interruption, or temporal data) to a primary/combined station without affecting the V(S)
or V(R) variables at either station. Reception of the UI response is not sequence number verified by
the data link procedures; therefore, the UI frame may be lost if a data link exception occurs during
transmission of the UI response, or duplicated if an exception condition occurs during any reply to
the UI response. The UI response may be sent during any mode of the data link station
 Connection establishment between Client and Server
• While connection is established between Cient and server, Firstly SNRM Command is sent by Client
to bring meter in normal response mode , in which control field is 93 = 10010011 (means Poll bit is
set).
• The server should confirm acceptance of the SNRM command by sending UA response, in which
control field is 73 = 01110011 (means final bit is set)
• Then client sends AARQ (Application Association Request) to server, in which control field is
10=00010000 (means poll bit is set).
• Server should send AARE (Application Association Response), in which control field 30=00110000
(means final bit is set)
• Then client sends request for meter serial number where 01 00 00 00 00 FF(1.0.0.0.0.255) is the
OBIS code of meter serial number and in response meter serial number is coming in ASCII as55 54
4F 38 34 34 38 38 means UTO8488.
Connection establishment between Client and Server
 Communication between DLMS Client and Server
• When DLMS client wants to communicate to DLMS server, they should be connected at physical
layer, data link layer and COSEM application layer.
1) Physical layer provides physical media for communication.
2) In order to get connected at data link layer SNRM request is sent. In SNRM request different data
link layer parameters are negotiated. Put in simple words in this request DLMS client and server
makes an agreement in how data will be getting transferred like what is the maximum length of
data a client can request or a server can accept or vice versa.
• When sending SNRM frame negotiation of parameters are optional. If client does not mention
parameters then both client and server communicates on default values of parameters.
• After successful request of SNRM and getting response of SNRM, data link layer at both ends are
connected.
SNRM (Set Normal Response Mode)
• In NRM only the primary terminal (Client) may initiate data transfer. The Server transmits data only
in response to commands from the Client.
In SNRM request information field is optional which is used for negotiation of data link layer
parameters. The absence of information field shall be interpreted to mean default values for each
parameter.
• At data link layer two parameters are negotiated:
1) The Maximum information field length parameter; and
2) The Window size parameter;
• The default value of the maximum information field (explained above) length parameter is 128
bytes. The maximum value depends on the quality of the physical channel.
• The default value of the Window size is 1. The maximum value is 7. Window size is number of
consecutive frames client can send without waiting for acknowledgement from server.
 Communication between DLMS Client and Server
The SNRM frame with parameter negotiation looks like:
7E A0 1E 03 21 93 CD 3B 81 80 12 05 01 82 06 01 82 07 04 00 00 00 02 08 04 00 00 00 02 CD BE 7E
Considering the above frame with the structure as explained above:
7E //start Flag
A0 1E //Frame format and length
03 //destination address (server in this case)
21 //source address (client in this case)
93 //Control field for SNRM
CD 3B //HCS
81 80 12 05 01 82 06 01 82 07 04 00 00 00 02 08 04 00 00 00 02 //Information field explained
81 and 80 shall always be present if SNRM frame is having information field.
81 // format identifier;
80 // group identifier;
12 //group length (18 octets);
05 // parameter identifier (maximum information field length – transmit in bytes); means maximum how many bytes can be
transmitted in information field once.
01 //parameter length (1 octet);
82 //parameter value; // 130 bytes
06 //parameter identifier (maximum information field length – receive); means maximum how many bytes
can be received in information field once.
01 //parameter length (1 octet);
82 //parameter value; //130 bytes
07 //parameter identifier (window size, transmit);
04 //parameter length (4 octets);
00 //parameter value (high byte of value);
00 //parameter value;
00 //parameter value;
02 //parameter value (low byte of value);
08 //parameter identifier (window size, receive);
04 //parameter length (4 octets);
00 //parameter value (high byte of value);
00 //parameter value;
00 //parameter value;
02 // parameter value (low byte of value). CD BE //FCS 7E //end Flag
 Communication between DLMS Client and Server
If the secondary station (DLMS server) receives a correct SNRM frame, and the requested connection can be accepted, it shall respond
with a UA frame. This UA frame shall carry the result of the HDLC parameter negotiation. The result shall be calculated by the secondary
station (server) by choosing the smaller value between the proposed value of a parameter (sent with the SNRM frame) and the value of
the corresponding parameter at the secondary station, received with the UA frame.
UA frame
7E //start flag
A0 1E //Frame format and length
21 //destination address (address of client). Note that the destination and source addresses are exchanged in this response frame
compare to the above SNRM frame. Earlier request was made from client to server and now response is coming from server to client and
hence the addresses are exchanged.
03 //source address (address of server)
73 //control field for UA
C3 7A //HCS
81 80 12 05 01 80 06 01 80 07 04 00 00 00 02 08 04 00 00 00 02
81 // format identifier;
80 // group identifier;
12 //group length (18 octets);
05 // parameter identifier (maximum information field length – transmit in bytes);
01 //parameter length (1 octet);
80 //parameter value; server is saying that it can support up to maximum of 128 bytes of information field in a single frame.
06 //parameter identifier (maximum information field length – receive); maximum bytes can be received in information field once.
01 //parameter length (1 octet);
80 //parameter value; //128 bytes
07 //parameter identifier (window size, transmit);
04 //parameter length (4 octets);
00 //parameter value (high byte of value); 00 //parameter value; 00 //parameter value; 02 //parameter value (low byte of value);
08 //parameter identifier (window size, receive);
04 //parameter length (4 octets);
00 //parameter value (high byte of value); 00 //parameter value; 00 //parameter value; 02 // parameter value (low byte of value).
A6 A1 //FCS 7E //end flag
In above SNRM and UA frames, as client has made request for 130 bytes of maximum information field length by sending SNRM. But
server said that it can support 128 bytes of maximum information field length by sending UA. When doing negotiation for any data link
layer parameter, always the smaller value between the two is considered. In this case maximum information field length will be 128
bytes.
 COSEM application layer:
• This is nothing but application layer at which we use COSEM services, that’s why we call it COSEM
application layer. Like negotiation at data link layer, some COSEM layer parameters are negotiated
at this stage. At data link layer we negotiate for frame level parameters but at COSEM layer we
negotiate for application level parameters.
• When data link layer of client and server gets connected, then application layer is connected with
AARQ and AARE frames.
• AARQ (Application association Request) frame looks as:
7E A0 2F 03 21 10 17 DD E6 E6 00 60 21 80 02 0284 A1 09 06 07 60 85 74 05 08 01 01 BE 10 04 0E
01 00 00 00 06 5F 1F 04 00 00 18 98 04 00 A9 32 7E
• Basically in AARQ both client and server negotiates for security mechanism, password
authentication (if password is there) etc.
• Details of AARQ & AARE is explained in later pages.

AARQ : AARQ stands for Application Association Request. It is used for Connection
establishment.
Basically in AARQ both client and server negotiates for security mechanism, password
authentication (if password is there) etc..
 COSEM application layer: 1
AARQ request (With security, i.e. Low level security):
7EA047000200230310413EE6E6006036A1090607608574050801018A0207808B0760857405080201AC0
A80083132333435363738BE10040E01000000065F1F0400001A1DFFFF33897E
Interpretetion:
7E = Opening Flag
A0 = Frame format (for segmented frame A8)
47 = (Decimal) No of bytes in frame except flags 7E
00 02 00 23 =Destination address (Four byte addressing is used for server)
03 = Source address (Client address is always of one byte)
10 = Control Field
413E = HCS
E6E600 = LLC header
60 = Tag for AARQ APDU
36 = (Decimal) Length of AARQ contents field 54
Application context name:A1 09 06
A1 = tag for the application-context-name component
09 = 9(Decimal) means 9 bytes after this byte contains application context name
06 = Choice for application-context-name(OBJECT IDENTIFIER, Universal)
07 = 7(Decimal) Next 7 bytes contains logical name referencing. Application context name length : 7
 COSEM application layer: 2
AARQ request (With security, i.e. Low level security):
7EA047000200230310413EE6E6006036A1090607608574050801018A0207808B0760857405080201AC0
A80083132333435363738BE10040E01000000065F1F0400001A1DFFFF33897E
Interpretetion:
Application Context name (BER Encoded)
60 85 74 05 08
01 = Here 01 means Low level authentication (Mechansim ID)
01 = LN referencing (If it is 02 then it will be SN referencing)
Encoding of an AARQ using low level authentication

--encoding the sender-acse-requirements field component (tagged component, [10] )

8A // encoding the tag for the acse-requirements field component ([10], IMPLICIT,Context -specific
02 // encoding of the length of the tagged component’s value field.
-- encoding the sender-acse-requirements component (ACSE-requirements ::= BIT STRING)
07 // encoding the number of unused bits in the last byte of the BIT STRING
80 // encoding of the authentication functional unit (0)
 COSEM application layer: 3
AARQ request (With security, i.e. Low level security):
7EA047000200230310413EE6E6006036A1090607608574050801018A0207808B0760857405080201AC0
A80083132333435363738BE10040E01000000065F1F0400001A1DFFFF33897E
Interpretetion:
-- encoding the mechanism-name component (tagged component [11])
8B // encoding the tag for the mechanism-name component ([11], IMPLICIT, Context-specific
07 // encoding of the length of the tagged component’s value field
-- encoding of the value of the Object Identifier
60 85 74 05 08 02 01
-- encoding the calling-authentication-value component (tagged component [12])
AC // encoding the tag for the mechanism-name component ([12], Context-specific)
0A // encoding of the length of the tagged component’s value field
-- encoding the calling-authentication-value component (Authentication-information ::= CHOICE)
80 // encoding the choice for Authentication-information (charstring [0] IMPLICIT GraphicString
08 // encoding of the length of the Authentication-information’s value field (8 octets)
-- encoding of the value of the Password (GraphicString “12345678”)
31 32 33 34 35 36 37 38 (Password used = 12345678)
 COSEM application layer: 4
AARQ request (With security, i.e. Low level security):
7EA047000200230310413EE6E6006036A1090607608574050801018A0207808B0760857405080201AC0
A80083132333435363738BE10040E01000000065F1F0400001A1DFFFF33897E
Interpretetion:
User information field: BE 10 04 0E
BE = Tag for the user-information field component
10 = 16(Decimal) length of the User information field(Starting from 04 to 00)
04 = Choice for user-information (OCTET STRING, Universal)
0E = 14(Decimal)length of xDLMS initiate request
xDLMS-Initiate-Request
01 = tag for Initiate request
00 = Dedicated key component
00 = Response allowed(00 by default)
00 = Proposed quality of service
06 = 6(decimal) Proposed DLMS Version number
5F1F = Tag for proposed conformance
04 = 4(decimal) means next 4 bytes are of 'Conformance block'
00 = Unused
 COSEM application layer: 5
AARQ request (With security, i.e. Low level security):
7EA047000200230310413EE6E6006036A1090607608574050801018A0207808B0760857405080201AC0
A80083132333435363738BE10040E01000000065F1F0400001A1DFFFF33897E
Interpretetion:
001A1D = 000000000001101000011101(Binary) means 11th,12th,14th,19th,20th,21st & 23rd bits
are set, that represents that

Block transfer with the GET service is supported

Block transfer with the SET service is supported
LN service Get is supported
LN service Set is supported
LN service Action is supported
Multiple reference is supported
Selective access is supported
(These services are supported relevant to LN referencing. If SN referencing is used then respective other
bits are set by the client itself).
FFFF = 65535(Decimal) bytes, Client max receive pdu size
33 89 = FCS
7E = Closing Flag
 COSEM application layer: 6
AARE (Response of AARQ):- Server sends response to Client in form of AARE.
AARE Response: 7EA03A030002002330AFCCE6E7006129A109060760857405080101A203020100A3
05A103020100BE10040E0800065F1F0400001A1D05DC00075B807E
Interpretetion:
7E = Opening Flag
A0 = Frame format (for segmented frame A8)
3A = 58(Decimal) No of bytes in frame except flags 7E
03 = (Client address is always of one byte)Destination address
00 02 00 23 = Client address(Four byte addressing)
30 = Control Field
AFCC = HCS
E6E700 = LLC header
-- BER encoding the AARE APDU
61 = Tag for AARE APDU
29 = 41(Decimal) Length of AARE contents field
 COSEM application layer: 7
AARE (Response of AARQ):- Server sends response to Client in form of AARE.
AARE Response: 7EA03A030002002330AFCCE6E7006129A109060760857405080101A203020100A3
05A103020100BE10040E0800065F1F0400001A1D05DC00075B807E
Interpretetion:
-- encoding the application -context-name component
Application context name:A1 09 06 07
A1 = tag for the application-context-name component
09 = 9(Decimal) means 9 bytes after this byte contains application context name
06 = Choice for application-context-name(OBJECT IDENTIFIER, Universal)
07 = 7(Decimal) Next 7 bytes contains logical name referencing.
60 85 74 05 08
01 = Here 01 means Low level authentication (Mechansim ID)
01 = Here 01 indicates LN referencing (If it is 02 then it means that client is using SN referencing)
-- encoding the tag & length for the result component
A2 = tag
03 = length of result component
 COSEM application layer: 8
AARE (Response of AARQ):- Server sends response to Client in form of AARE.
AARE Response: 7EA03A030002002330AFCCE6E7006129A109060760857405080101A203020100A3
05A103020100BE10040E0800065F1F0400001A1D05DC00075B807E
Interpretetion:
-- encoding the Result component (INTEGER)
02 = encoding the choice for result (INTEGER, Universal)
01 = Length of result value field
00 = Value of the result (00=Success, 01=rejected permanent)
-- encoding the result-source-diagnostics component
Result source diagnostic: A3 05 A1 03 02 01 00
A3 = encoding the tag for the result-source-diagnostics component
05 = Length of tagged component's value field
A1 = Tag of ACSE service user
03 = Length of tagged components value field
-- encoding the result-source-diagnostics component
02 = Choice for source result diagnostic
01 = Length of the value field
00 = No diagnostic provided
 COSEM application layer: 9
AARE (Response of AARQ):- Server sends response to Client in form of AARE.
AARE Response: 7EA03A030002002330AFCCE6E7006129A109060760857405080101A203020100A3
05A103020100BE10040E0800065F1F0400001A1D05DC00075B807E
Interpretetion:
-- encoding the user-information field component
User information field: BE 10 04 0E
BE = Tag for the user-information field component
10 = 16(Decimal) length of the User information field(Starting from 04 to 00)
04 = Choice for user-information (OCTET STRING, Universal)
0E = 14(Decimal)length of xDLMS initiate request
xDLMS initiate response: 08 00 06 5F 1F 04 00 00 1A 1D 05 DC 00 07
Where 08 = Initiate response
00 = Negotiated quality of service
06 = Negotiated DLMS version number
5F 1F = Tag for negotiated conformance
04 = 4 (decimal) means next 4 bytes are of 'Conformance block'
00 = unused
 COSEM application layer: 10
AARE (Response of AARQ):- Server sends response to Client in form of AARE.
AARE Response: 7EA03A030002002330AFCCE6E7006129A109060760857405080101A203020100A3
05A103020100BE10040E0800065F1F0400001A1D05DC00075B807E
Interpretetion:
001A1D = 000000000001101000011101 (Binary) means 11th,12th,14th,19th,20th,21st & 23rd bits are
set, that represents that
• Block transfer with the GET service is supported
• Block transfer with the SET service is supported
• LN service Get is supported
• LN service Set is supported
• LN service Action is supported
• Multiple reference is supported
• Selective access is supported
5B 80 = FCS
7E = Closing Flag
 Conformance block negotiation : 1
Conformance block is a 24 bit sequence, each bit corresponding to Application layer service
1) Bit value ‘1’ := service supported
2) Bit value ‘0’ := service not supported
Proposed conformance: conformance block sent by the client
Negotiated conformance: services common toboth server and client
Can be obtained by doing “Logical AND”between server conformance block and client conformance
block
Lets say client supports:-
Client conformance:= { Get, Set }
Client conformance block:= 0x000018
 Conformance block negotiation : 2
& Server supports:­Server conformance:= {Get, Action}
Server conformance block:= 0x000011

Then if “Logical AND” operation is performed between server conformance block and client
conformance block then we get the negotiated (common service) between client and server.

Negotiated conformance block >= 1 One or more service (common in server and client conformance
blocks) Only common services (present in negotiated conformance block) will be used during
Application Association
 Selective access : 1
There are two types of selective access which allows reading the buffer selectively.
1) Selective Access by Entry
Selective Access by Entry provides a set of 4 integers to filter the contents of the “buffer” attribute in
response to get requests as illustrated in Fig. 4. The 4 integers are as below
a) From-entry: The index of the first entry to return from the buffer
b) To-Entry: The index of the last entry to return from the buffer
c) From-Value: The index of the first column to return
d) To-Value: The index of the last column to return

Thus the selective access parameters as above can be used to select a subset of the rows from the
buffer table.
 Selective access : 2
2) Selective Access by Range
Selective Access by Range permits a client to retrieve a subset of the rows and columns in the Profile
buffer based on the value of one of the capture objects. Typically the capture object selected for this
purpose is the Clock’s date-time attribute which is usually one of the capture objects in most profiles as
illustrated in Fig. 5. The selective access parameters in this case are as below.
2.1 Restricting object
This parameter identifies the capture object whose value will be used to filter the buffer. The object is
defined by the OBIS code and attribute index of the selected object.
2.2 From-Value
The start-range value for the subset. All selected rows in the buffer will have a value for the restricted
object that is higher than or equal to this limit.
2.3 To-Value
The stop-range value for the subset. All selected rows in the buffer will have a value for the restricting
object that is lower than or equal to this limit.
2.4 Selected-Values
An array of column indices specifying the columns that should be returned from the selected rows.
Selective access : 3
 Interface Classes
An object is a collection of attributes and methods. Attributes represent the characteristics of an object.
The value of an attribute may affect the behaviour of an object. The first attribute of any object is the
logical_name. It is one part of the identification of the object. An object may offer a number of
methods to either examine or modify the values of the attributes. Objects that share common
characteristics are generalized as an interface class, identified with a class_id. Within a specific IC, the
common characteristics (attributes and methods) are described once for all objects. Instantiations of ICs
are called COSEM interface objects. Manufacturers may add proprietary methods and attributes to any
object.
Class Ids:
1) 0-8191 :-DLMS UA defined classes
2) 8192-32767:-Manufacturer specific classes
3) 32768 to 65535 :-User Group specific classes
List of interface classes by class_id

Interface class name class_id version(s) Clause

Data 1 0 4.3.1
Register 3 0 4.3.2
Extended register 4 0 4.3.3
Demand register 5 0 4.3.4
Register activation 6 0 4.3.5
Profile generic 7 1 4.3.6
0 5.4.2
Clock 8 0 4.5.1
Script table 9 0 4.5.2
Schedule 10 0 4.5.3
 Interface Classes - 2
List of interface classes by class_id

Interface class name class_id version(s) Clause

Special days table 11 0 4.5.4
Association SN 12 4 4.4.3
3 5.4.6
2 5.4.5
1 5.4.4
0 5.4.3
Association LN 15 3 4.4.4
2 5.4.9
1 5.4.8
0 5.4.7
SAP Assignment 17 0 4.4.5
Image transfer 18 0 4.4.6
IEC local port setup 19 1 4.7.1
0 5.4.11
Activity calendar 20 0 4.5.5
Register monitor 21 0 4.5.6
Single action schedule 22 0 4.5.7
IEC HDLC setup 23 1 4.7.2
0 5.4.12
IEC twisted pair (1) setup 24 1 4.7.3
0 4.13
 Interface Classes - 3
List of interface classes by class_id
Interface class name class_id version(s) Clause
M-BUS slave port setup 25 0 4.8.2
Utility tables 26 0 4.3.7
Modem configuration 27 1 4.7.4
0 5.4.14
PSTN modem configuration 28 2 4.7.5
Auto answer 1 ----
0 5.4.15
Auto connect 29 2 4.7.6
PSTN Auto dial 1 5.4.17
0 5.4.16
Data protection 30 0 4.4.9
Push setup 40 0 4.4.8.2
TCP-UDP setup 41 0 4.9.1
IPv4 setup 42 0 4.9.2
MAC address setup 43 0 4.9.4, 4.12.10
(Ethernet setup)
PPP setup 44 0 4.9.5
GPRS modem setup 45 0 4.7.7
SMTP setup 46 0 4.9.6
GSM diagnostic 47 0 4.7.8
IPv6 setup 48 0 4.9.3
S-FSK Phy&MAC setup 50 1 4.10.3
0 5.4.1
 Interface Classes - 4
List of interface classes by class_id
Interface class name class_id version(s) Clause
S-FSK Active initiator 51 0 4.10.4
S-FSK MAC synchronization 52 0 4.10.5
Timeouts
S-FSK MAC counters 53 0 4.10.6
IEC 61334-4-32 LLC setup 55 1 4.10.7
S-FSK IEC 61334-4- 32 LLC setup 0 5.4.19
S-FSK Reporting system list 56 0 4.10.8
ISO/IEC 8802-2 LLC Type 1 setup 57 0 4.11.2
ISO/IEC 8802-2 LLC Type 2 setup 58 0 4.11.3
ISO/IEC 8802-2 LLC Type 3 setup 59 0 4.11.4
Register table 61 0 4.3.8
Compact data 62 0 4.3.10
Status mapping 63 0 4.3.9
Security setup 64 1 4.4.7
0 5.4.10
Parameter monitor 65 0 4.5.10
Sensor manager 67 0 4.5.11
Arbitrator 68 0 4.5.12
Disconnect control 70 0 4.5.8
Limiter 71 0 4.5.9
M-Bus client 72 1 4.8.3
0 5.4.20
 Interface Classes - 5
List of interface classes by class_id
Interface class name class_id version(s) Clause
Wireless Mode Q channel 73 0 4.8.4
M-Bus master port setup 74 0 4.8.5
DLMS/COSEM server M-Bus port setup 76 0 4.8.6
M-Bus diagnostic 77 0 4.8.7
61334-4-32 LLC SSCS setup 80 0 4.12.3
PRIME NB OFDM PLC Physical layer counters 81 0 4.12.5
PRIME NB OFDM PLC MAC setup 82 0 4.12.6
PRIME NB OFDM PLC MAC functional parameters 83 0 4.12.7
PRIME NB OFDM PLC MAC counters 84 0 4.12.8
PRIME NB OFDM PLC MAC network 85 0 4.12.9
administration data
PRIME NB OFDM PLC Application identification 86 0 4.12.11
G3-PLC MAC layer counters 90 1 4.13.3
G3 NB OFDM PLC MAC layer counters 0 5.4.21
G3-PLC MAC setup 91 1 4.13.4
G3 NB OFDM PLC MAC setup 0 5.4.22
G3-PLC 6LoWPAN adaptation layer setup 92 1 4.13.5
G3 NB OFDM PLC 6LoWPAN 0 5.4.23
adaptation layer setup
ZigBee® SAS startup 101 0 4.14.2
ZigBee® SAS join 102 0 4.14.3
ZigBee® SAS APS fragmentation 103 0 4.14.4
ZigBee® network control 104 0 4.14.5
ZigBee® tunnel setup 105 0 4.14.6
Account 111 0 4.6.2
Credit 112 0 4.6.3
Charge 113 0 4.6.4
Token gateway 115 0 4.6.5
 Data (Class_id 1)
A data object stores data related to internal meter objects. For example in order to read meter serial
number from meter, we use data class.
Request:
7E A0 1903 21 32 6F D8E6 E6 00 C0 01 8100 0101 00 00 00 00 FF02 00 C6 60 7E
1 byte flag: 7E
2 byte frame format, frame length: A0 19
2 byte destination, source address: 03 21(one byte addressing is used for client and server)
1 byte control field: 32 (shows this is an I frame)
2 byte header check sequence: 6F D8
3 byte LLC header (logical link control): E6 E6 00
2 byte get request: C0 01
1 byte invoke id: 81
1 byte data follows: 00 (00 indicates data follows)

1 byte class id: 01, Class id 01 represents data class

6 byte obis code: 01 00 00 00 00 FF (request in Hex)

Request: 01 00 00 00 00 255 (in decimal)
1.0.0.0.0.255 (request for meter serial no.)
1 byte attribute type: 02, Attribute 02 represents value
1 byte selective access: 00 (00 means no selective access)
2 byte frame check sequence: C6 60
1 byte flag: 7E
 Data (Class_id 1)
A data object stores data related to internal meter objects. For example in order to read meter serial
number from meter, we use data class.

Response: (Meter serial number)

7E A0 1A21 03 52 A4 38E6 E7 00 C4 01 8100 09 08 55 53 4F 38 34 34 38 37 90 21 7E
1 byte flag: 7E
2 byte frame format, frame length: A0 1A
2 byte destination, source address: 21 03
1 byte control field: 52 (shows this is an I frame)
2 byte header check sequence: A4 38
3 byte LLC header (logical link control): E6 E7 00
2 byte get response: C4 01
1 byte invoke id: 81
1 byte data follows: 00 (00 is tag for data)
1 byte data type: 09 here 09 is representing octet string data type. Octet string means an ordered
sequence of octets (8-bit bytes). To interpret this value 09 is representing data type
1 byte length of bytes in hex: 08 (i.e. next 8 bytes contains response of our request) next byte 08 is
representing the length means next 8 bytes are for data.

Response: 54 50 4F 38 34 34 38 37 HEX2ASCII: 54– T, 50- P, 4F- O, 38- 8, 34- 4, 34- 4, 38- 8, 37- 7
i.e. TPO84487 (meter serial no.)

2 byte frame check sequence: 90 21

1 byte flag: 7E
 Register (class_id 3)
A register object stores a process value or a status value with its associated unit.
For example in order to get instantaneous parameters like Voltages, Line currents we use register class.
Following is the request frame for V1:
Request:
7E //Frame header
A0 19// Frame format type and Frame length
03 21// Destination address and source address
76// Control field
4F DC// Header check sequence
E6 E6 00//Logical link control header
C0 01 //Get Request Normal
81 //Invoke-id and priority
00// Tag for data

03 //class id 03 representing Register class.

01 00 20 07 00 FF // OBIS code 1.0.32.7.0.255 for V1

02 //attribute id 02 representing value

00 //no selective access
80 4E//Frame check sequence
7E //Frame trailer
 Register (class_id 3)
A register object stores a process value or a status value with its associated unit.
For example in order to get instantaneous parameters like Voltages, Line currents we use register class.
Following is the request frame for V1:
Response:

7E //Frame header
A0// Frame format type
18// Frame length
21 03//Destination and source address
96// Control field
FA 81// two byte header check sequence
E6 E7 00// Logical Link Control header
C4 01 //Get Response Normal
81 //Invoke-id and priority
00 //Tag for data

09 06 32 34 37 2E 36 39 //09 representing octet string and will be interpreted in the same way as
explained above for meter serial number.
Interpreted value is: 247.69

BA 2A// Frame check sequence

7E //Frame trailer
 Request for scaler_unit:
Request is same as above; only the difference is in attribute id. Here attribute id is 03 requesting for
scaler_unit.
7E A0 19 03 21 54 5F DE E6 E6 00
C0 01
81
00 03
01 00 20 07 00 FF
03 //attribute id 03 representing scaler_unit. It provides information on the unit and the scaler of the
value.
00
58 57 7E
Response: 7E A0 16 21 03 74 A4 EB E6 E7 00
C4 01
81
00 //Tag for data
02 02 // First 02 represents the structure data type as we have requested for attribute 03 which is
scaler_unit and a structure of two elements one is scaler of integer type and next is unit of enumerated
type. Next 02 represents there are two elements in the structure
0F 00 //0F is for integer data type and representing scaler which is the first element of the structure
scaler_unit and here it is 0.
16 23 //16 is for enumerated data type and representing unit which is the second element of the
structure scaler_unit and here it is 23 which denotes unit is ‘V’. For enumerated data type supported in
the COSEM objects refer Blue Book.
F6 5B// Frame check sequence
7E //Frame trailer
 Profile (Class_id 7)
Basically a profile class is used to store dynamic and bulky values.
In order to read load survey, we do request for profile class with different attributes.
Attribute 03 specifies capture objects. Capture objects defines the values to be stored in the buffer.
Attribute 02 specifies buffer data. Buffer data will store the values of capture objects.

For example if we do request for load survey with attribute 03:

7E// Frame header

A0// Frame format type
19// Frame length
03 21// Destination and Source address
98// Control field
3F D2// Header check sequence
E6 E6 00// Logical link control Header
C0 01 // Get-Request[192] Normal [1]
81 //Invoke_id and priority
00 // Tag for data
07 //Class id 7 for profile

01 00 63 01 03 FF //OBIS code for load survey SIP parameter1 i.e. 1.0.99.1.3.255

03 //attribute 03 for capture objects

00 //no selective access

44 78//Frame check sequence
7E //Frame trailer
 Profile (Class_id 7) - 2
Response
7E// Frame header
A0// Frame format type
24// Frame length
21 03//Destination address
B8 40// Header check sequence
92// Control field
E6 E7 00// Logical Link Control header
C4 01 //Get-response[194] Normal [1]
81 //Invoke_id and priority
00 // Tag for data [0] means after 00 the data is coming.
01 01 // First 01 denotes array and second 01 tells that there is one element in array
02 04 // 02 denotes the structure and 04 means four elements in the structure.
The capture object structure is defined as follows:
capture_object_definition:= structure
{
class_id: long-unsigned,
logical_name: octet-string,
attribute_index: integer,
data_index: long-unsigned
}
Logical_name is actually the OBIS Code. Attribute_index refers the attribute of the object.
Attribute_index1 refers to the first attribute; attribute_index2 refers to the second attribute etc.
Data_index refers the specific element of the attribute.
The first element in the attribute structure is identified by data_index 1. If the attribute is not a
 Profile (Class_id 7) - 3
Response
The first element in the attribute structure is identified by data_index 1. If the attribute is not a
structure, then the data_index has no meaning. If the capture object is the buffer of a profile, then the
data_index identifies the captured object of the buffer (i.e. the column) of the inner profile.data_index
0: references the whole attribute
12 00 03 //12 denotes long unsigned data type 0003 is class id denotes Register class.
09 06 01 00 01 08 00 FF// 09 denotes the octet string and 06 denotes the length of octet string is 06,
that means the following 6 bytes 1.0.1.8.0.255 OBIS code
0F 02 //0F denotes the integer data type, 02 denotes the second attribute of register class i.e. value
attribute.
12 00 00 //12 denotes the long unsigned type, 00 00 represents data index.
74 D9// Frame check sequence
7E //Frame trailer

In the above response frame, we find out Class id 3 // Register class

OBIS code 1.0.1.8.0.255 //Logical_name of Active energy (I)
Attribute id 2 //denotes value attribute
Data index 00 that means whole attribute or need not to consider as attribute is not a structure.
That means Active Energy (I) Register value (attribute 2 refers value)
The above capture object tells that when requesting for buffer data we are going to get the active
energy (I) register values.
 Profile (Class_id 7) - 4
The above capture object tells that when requesting for buffer data we are going to get the active
energy (I) register values.
Request with Atrribute id 2 for Buffer data
7E// frame header
A0// Format type
2C// Frame length
03 21// Destination address
BA//Control field
8A F2// Header check sequence
E6 E6 00 // Logical link control Header
C0 01 //Get Request Normal
81 //Invoke-id and priority
00 //Tag for data
07 //class id
01 00 63 01 03 FF //OBIS code 1.0.99.1.3.255
02 //attribute id
01 02 //array of 2 elements
02 04 //structure of four elements
06 00 00 00 00 //06 represents double long unsigned data type from_entry is 0.
06 00 00 00 60 //06 represents double long unsigned data type to_entry is 96.
12 00 01 //12 represents long unsigned data type from_value is 01.
12 00 01 //12 represents long unsigned data type to_value is 01.
In summary we can say that we have made a request for rows 0 to 96 and 1st column.
7D 58// Frame check sequence
7E //frame trailer
 Profile (Class_id 7) - 5
Answer
7E// Frame header
A8// Shows segmented frame
89// Length of frame
21 03//Destination source address
CA// Control field
47 B1//Frame check sequence
E6 E7 00 // Logical Link Control header In this frame, frame format differs from the previous frames. Here the
frame format is A8 telling that this is segmented frame. When we say segmented frame it means the data has
not completed yet and will continue.
C4 01 //Get Response Normal
81 //Invoke-id and priority
00 //Tag for data [0]
01 60 // 01 denotes array and 60 denotes 96 elements in the array.
02 01 12 FF FF //02 tells the structure; 01 says 1 element in the structure; 12 is for long unsigned data type
and then value of energy register FFFFH = 65535D
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
02 01 //here only 02 01 is provided and then frame trailer comes. The data will be continuing in next response
frame as it is a segmented frame as A8 frame format.
B3 20// Frame check sequence 7E //Frame trailer
 Profile (Class_id 7) - 6
Request: 7E A0 07 03 21 F1 1B 41 7E (RR i.e. Receive Ready frame for requesting continued data)

Answer 7E A8 89 21 03 CE 63 F7
12 FF FF //this register value is continuing from previous frame.
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
8C F4
7E flag which indicating the end of previous frame and starting of the new frame.

A0// A0 is specifying that this is the complete frame not segmented frame.
72//Frame length
21 03// Destination Source address
D0 82 E3
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF 02 01 12 FF FF
F0 12
7E //Frame trailer
 Clock (class_id 8)
Request
7E// Frame header
A0// Format type
19// Frame length
03 21//Destination source address
98//Control field
3F D2// Header check sequence
E6 E6 00 //Logical link control header
C0 01 //Get request Normal
81 //Invoke_id and priority
00// Tag for Data
08 //class id (08 is for clock)
00 00 01 00 00 FF //0.0.1.0.0.255 OBIS code for meter date and time
02 //attribute 02 represents time
00 //no selective access
65 D7// Frame check sequence
7E //Frame trailer

Answer 7E// Frame header

A0// Frame format type
1E// Frame length
21 03//Destination address
B8// Control field
1C 02//Header check sequence
E6 E7 00 //Logical link control header
DLMS/COSEM security concept
•The resources of DLMS/COSEM servers – COSEM object attributes and methods – can be
accessed by DLMS/COSEM clients within Application Associations.
•During an AA establishment the client and the server have to identify themselves. The server
may also require that the user of a client identifies itself. Furthermore, the server may require that
the client authenticates itself and the client may also require that the server authenticates itself.
•Once an AA is established, xDLMS services can be used to access COSEM object attributes and
methods, subject to the security context and access rights.
•The xDLMS APDUs carrying the services primitives can be cryptographically protected. The
required protection is determined by the security context and the access rights. To support end-to-
end security between third parties and servers, such third parties can also access the resources of a
server using a client as a broker.
•Moreover, COSEM data carried by the xDLMS APDUs can be cryptographically protected.
•As these security mechanisms are applied on the application process / application layer level,
they can be used in all DLMS/COSEM communication profiles.
•NOTE:-Lower layers may provide additional security.
•DLMS/COSEM AEs are bound to Service Access Points (SAPs) in the protocol layer supporting the
AL. These SAPs are present in the PDUs carrying the xDLMS APDUs within an AA.
•The client user identification mechanism enables the server to distinguish between different
users on the client side and to log their activities accessing the meter.
•NOTE:-Client users may be operators or third parties.
 Identification and Authentication
Identification:
DLMS/COSEM AEs (Application Entity) are bound to Service Access Points (SAPs) in the
protocol layer supporting the Application layer. These SAPs are present in the PDUs
carrying the xDLMS APDUs (Application layer protocol data unit) within an AA
(Application Association). The client user identification mechanism enables the server to
distinguish between different users on the client side and to log their activities
accessing the meter.

Authentication:
Authentication is one of the security aspects addressed by the COSEM specification. To
provide different levels of security for authentication support, COSEM specifies three
levels of authentication securities:
 Identification and Authentication 2
1) No security (Lowest level security) authentication
The purpose of No security (Lowest level security) authentication is to allow the client
to retrieve some basic information from the server. This authentication mechanism
does not require any authentication; the client can access the COSEM object attributes
and methods within the security context and access rights prevailing in the given AA.
DLMS User Association, DLMS/COSEM Architecture and Protocols, Eighth Edition DLMS
User Association 2014-07-07 DLMS UA 1000-2 Ed. 8.0 149/473 © Copyright 1997-2014
DLMS User Association
2) Low Level Security (LLS) authentication
In this case, the server requires that the client authenticates itself by supplying a
password that is known by the server. The password is held by the current “Association
SN / LN” object modelling the AA to be established. The “Association SN / LN” objects
provide means to change the secret. If the password supplied is accepted, the AA can
be established, otherwise it shall be rejected. LLS authentication is supported by the
COSEM-OPEN service
• the client transmits a “secret” (a password) to the server, using the COSEM-
OPEN.request service primitive;
• the server checks if the “secret” is correct;
• if yes, the client is authenticated and the AA can be established. From this moment, the
negotiated contexts are valid;
• if not, the AA shall be rejected;
• the result of establishing the AA shall be sent back by the server using the COSEM-
OPEN.response service primitive, together with diagnostic information.
 Identification and Authentication 3
3) High Level Security (HLS) authentication
In this case, both the client and the server have to successfully authenticate themselves
to establish an AA. HLS authentication is a four-pass process that is supported by the
COSEM-OPEN service and the reply_to_HLS_authentication method of the “Association
SN / LN” interface class:
• Pass 1: The client transmits a “challenge” CtoS and – depending on the authentication
mechanism – additional information to the server;
• Pass 2: The server transmits a “challenge” StoC and – depending on the authentication
mechanism – additional information to the client;
If StoC is the same as CtoS, the client shall reject it and shall abort the AA establishment process.
• Pass 3: The client processes StoC and the additional information according to the rules
of the HLS authentication mechanism valid for the given AA and sends the result to the
server. The server checks if f(StoC) is the result of correct processing and – if so – it
accepts the authentication of the client;
• Pass 4: The server processes then CtoS and the additional information according to the
rules of the HLS authentication mechanism valid for the given AA and sends the result
to the client. The client checks if f(CtoS) is the result of correct processing and – if so – it
accepts the authentication of the server.
 Identification and Authentication 4
3) High Level Security (HLS) authentication
• Pass 1 and Pass 2 are supported by the COSEM-OPEN service.After Pass 2 – provided
that the proposed application context and xDLMS context are acceptable – the AA
isformally established, but the access of the client is restricted to the method
reply_to_HLS_authentication of thecurrent "Association SN / LN” object.
• Pass 3 and Pass 4 are supported by the method reply_to_HLS_authentication of the
“Association SN / LN”object(s). If both passes 3 and 4 are successfully executed, then
the AA is established. Otherwise, either theclient or the server aborts the AA.
• There are several HLS authentication mechanisms available.
• In some HLS authentication mechanisms, the processing of the challenges involves the
use of an HLS secret.
• The “Association SN / LN” interface class provides a method to change the HLS “secret”:
change_HLS_secret.DLMSUser Association, DLMS/COSEM Architecture and Protocols,
Eighth Edition DLMS User Association 2014-07-07 DLMSUA 1000-2 Ed. 8.0 150/473 ©
Copyright 1997-2014 DLMS User Association
 Access Rights
• Access rights are held by the “Association SN / LN” ICs. The access_mode is of data
typeenum. When the enum value is interpreted as an unsigned8, the meaning of the
bits is as shown in Table.
• Access rights to attributes may be: no_access, read_only, write_only, or
read_and_write. Access rights to methods may beno_access or access.
• In addition, access rights may stipulate cryptographic protection to be applied to
xDLMS APDUs carrying the service primitives used to access a particular COSEM object
attribute / method. The protection required on the .request and on the .response can
be independently configured.
• The protection to be applied shall meet the stronger of the requirement stipulated by
the security policy and theaccess rights.
• Access rights to COSEM object attributes and/or methods may require authenticated,
encrypted and / or signedxDLMS APDUs. For this reason, APDUs with more protection
than required by the security policy are always allowed.APDUs with less protection than
required by the security policy and the access rights shall be rejected.
• More protection in this context means that more kinds of protection are applied on the
xDLMS APDU than what isrequested by the security policy: for example, security policy
requires that all APDUs are authenticated but accessrights require that the APDU is
enrcypted and authenticated i.e. a higher protection.
Access Rights
Security Context
The security context defines security attributes relevant for cryptographic
transformations and includes thefollowing elements:
• the security suite, determining the security algorithms available;
• the security policy, determining the kind(s) of protection to be applied generally to
all xDLMS APDUs exchangedwithin an AA;
• the security material, relevant for the given security algorithms, that includes
security keys, initialization vectors,public key certificates and the like. As the
security material is specific for each security algorithm, the elements arespecified
in detail in the relevant clauses.
The security context is managed by “Security setup” objects; see DLMS UA 1000-1 Ed. 12:2014 4.4.7.

Security suite
• Security Suite Id - 0
• Authentication algorithm - AES-GCM-128
• Encryption algorithm - AES-GCM-128
• Key transport method - Key wrapping using AES-128 key
Security Context
Security policy
Attribute access rights
(0) no_access,
(1) read_only,
(2) write_only,
(3) read_and_write,
(4) authenticated_read_only,
(5) authenticated_write_only
(6) authenticated_read_and_write
Method access rights
(0) no_access,
(1) access,
(2) authenticated_access

• Security is not imposed

• All messages authenticated
• All messages encrypted
• All messages authenticated and encrypted