DLMS Handbook

DLMS Hand Book
About
This book contains the basic concepts of DLMS. DLMS/COSEM structure is described here alongwith respective sets
of examples. At last some Frequently Asked Questions and DLMS Conformance testing related necessary
informations are also documented.
This book doesn't contains all topics related to DLMS. For details and depth knowledge of DLMS, please refer DLMS
standard books.
General Abbreviations
Abbreviation Explanation
AA Application Association
AARQ A-Associate Request – an APDU of the ACSE
AARE A-Associate Response – an APDU of the ACSE
ACSE Association Control Service Element
AE Application Entity
AL Application Layer
AP Application Process
APDU Application Layer Protocol Data Unit
BER Basic Encoding Rules
COSEM Companion Specification for Energy Metering
DISC Disconnect (a HDLC frame type)
DLMS Device Language Message Specification
DM Disconnected Mode (a HDLC frame type)
HCS Header Check Sequence
HDLC High-level Data Link Control
What is Interoperability?
The capability of a data collection system to exchange data with meters of different types and/or from different
manufacturers, and the capability of metering equipment to exchange data with different data collection systems,
when both parties are compliant to the DLMS/COSEM specification.
In the DLMS/COSEM environment, interoperability and interconnectivity is defined between client and server AEs. A
client and a server AE must be interoperable and interconnectable to ensure data exchange between the two
systems.
Using the COSEM object model to model metering of all kinds of energy, over all communication media ensures
semantic interoperability, i.e. an unambiguous, shared meaning between clients and servers using different
communication media. The semantic elements are the COSEM objects, their logical name i.e. the OBIS code,
definition of their attributes and methods and the data types that can be used.
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 Specificationwith the objective to
provide an interoperable environment for structured modelling and meter exchange.
data Applications like remote
meter reading, remote control and value added services for metering, any kind of energy, like electricity, water, ga
or heat are supported“Device Language Message specification” it is a generalized concept for structured modelin
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).
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.
The most significant difference between SML and the other two protocols is that SML does not rely on an
information model interface and thus does not emphasize the standardization on the functional level. This leaves
more flexibility in the use of the protocol but also means that details (e.g. the message types supported by a
device) have to be specified by other standardization bodies in order to guarantee interoperability. SML is the only
protocol to support the communication of digitial signatures.
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:-
1. Specification
2. Development and maintenance
3. Registration of standard elements
4. Conformance certification
5. Promotion
6. Support
DLMS Standard Books:-
1) Blue Book:- Specifies the DATA MODEL comprising the COSEM interface classes and OBIS codes for the
various energy types.
Internationally standardized by the IEC and CEN.
2) Green Book:- Specifies the PROTOCOLS with DLMS on top, for thevarious media-specific communication
profiles, based on widelyused ISO/IEC, Internet, NIST and FIPS standards. Internationally
standardized by the IEC
and CEN.
3) Yellow Book:- Specifies CONFORMANCE TEST plans for the COSEMobject model and the communication
layers, and describes thetesting and certification process.
4) White Book:-GLOSSARY OF TERMShelps to understand thespecification. Internationally standardized by the

IEC.
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. 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.
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,
A B C D E 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
All other Reserved
The value group B defines the channel number, i.e. the number of the input of a metering equipment having sever
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
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
0 General purpose objects

1 Active power+ (Q1+Q4)
2 Active power - (Q2+Q3)
3 Reactive power + (Q1 + Q2)
4 Reactive power - (Q3 + Q4)
5 Reactive power Q1
6 Reactive power Q2
7 Reactive power Q3
8 Reactive power Q4
9 Apparent power (Q1 + Q4)
10 Apparent power (Q2 + Q3)
11 Current
12 Voltage
13 3 Ph Power factor
14 Frequency
Active power
15
(absolute(Q1+Q4)+absolute(Q2+Q3))
Active power (absolute(Q1+Q4)-
16
absolute(Q2+Q3))
17 Active power Q1
18 Active power Q2
19 Active power Q3
20 Active power Q4
11 Current
12 Voltage
14 Frequency
Active power
15
Active power (absolute(Q1+Q4)-
16
absolute(Q2+Q3))
17 Active power Q1
18 Active power Q2
19 Active power Q3
20 Active power Q4
21 L1 Active power +
22 L1 Active power -
23 L1 Reactive power +
24 L1 Reactive power - (Q3 + Q4)
25 L1 Reactive power Q1
29 L1 Apparent power (Q1 + Q4)
30 L1 Apparent power (Q2 + Q3)
31 L1 Current
32 L1 Voltage
33 L1 Power factor
34 L1 Supply frequency
L1 Active power
35
L1 Active power (absolute(Q1+Q4)-
36
absolute(Q2+Q3))
37 L1 Active power Q1
81 Angles
82 Unit less quantity
83 Transformer and line loss quantities
85 L1 Power factor
86 L2 Power factor
87 L3 Power factor
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
Billing period average(since last
0 reset)
1 Cumulative minimum1
2 Cumulative maximum1
3 Minimum1
4 Current average1
5 Lastaverage1
6 Maximum1
7 Instantaneous value
8 Time integral 1
9 Time integral 2
10 Time integral 3
11 Cumulative minimum 2
12 Cumulative maximum 2
13 Minimum 2
14 Currentaverage2
15 Lastaverage2
16 Maximum2
17 Timeintegral7
18 Timeintegral8
19 Timeintegral9
20 Timeintegral10
21 Cumulative minimum3
22 Cumulative maximum3
23 Minimum3
24 Current average3
25 Lastaverage3
26 Maximum3
27 Currentaverage5
28 Currentaverage6
29 Time integral 5
30 Time integral 6
31 Under limit threshold
32 Under limit occurrence counter
33 Under limit duration
34 Under limit magnitude
35 Over limit threshold
36 Over limit occurrence counter
37 Over limit duration
38 Over limit magnitude
39 Missing threshold
128...254 Manufacturer specific
The range for value group E is 0 to 255. It can be used for identifying further classification or processing
defined by value groups A to D,
0 Total
1 Rate 1
2 Rate 2
3 Rate 3
…
9 Rate 9
…
63 Rate 63
128…254 Manufacturer specific codes

All othersReserved
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 the
OBIS (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 add
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 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 optic
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 orientedinterface object
model for metering devices and systems while keeping backwardcompatibility to the existing DLMS standard. To
meet these objectives, COSEM includes an evolution of DLMS. Remaining fully compliant to the DLMS standard,
COSEM provides a more 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 ofCOSEM interface objects are negotiated
between the client and the server with the help ofthe 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 interoperabl
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.
1. Physical layer: Physical layer provides physical media for communication.

2. 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).
3. The main component of the client and server COSEM application layers is the COSEM ASO, which provides
services to the COSEM AP, and uses services provided by the supporting lower layer. Both the client and server
side COSEM ASO contains three mandatory components:
- The ACSE. The task of this element is to establish, maintain, and release application associations. 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 pie ce of in f or ma tio n mo de le d b y C O S E M can be accessed as an attribute or me thod of a certain C O S E M

interface object. To access an attribute or me thod, it has to be re fe re nced. In the me terin g e qu ip me nt (serv e r) the
COSEM applicatio n lay e r provid e s two me chanis ms 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 colle ctio n system (clie nt) applicatio n lay e r a lways uses LN re fe re ncing . W h e n S N re fe re ncin g is u s e d , the
attributes and me thods of each interface object are ma pp e d to DLMS named varia b le s. This is d o n e du rin g the
desig n o f the me ter. Each na me d v a ria b le is id e n tifie d w ith a short name.
When SN re fe re ncin g is u s e d , the DLMS name d va ria b le s a re accessed by the standard DLMS READ and W RITE
serv ices.
When LN referencin g is u s e d , a ttributes and methods are a ccessed via the lo g ical name o f the object, specifyin g
the ind e x (es) of the attribute(s) and/or the me thod(s). Logical name s a re de fin e d b y O BIS. W hen LN re fer e ncin g is
u s e d , the attributes and me thods are a ccessed by the xDLMS GET/SET and ACTION serv ices.
SN re fe re ncin g is mor e suitable f o r s imple d e v ices and LN re fe re ncin g f o r comple x devices.
LN Referencing SN Referencing
Attribute related (Services)
GET
SET Read
Attribute_0 with GET Write
Attribute_0 with SET UnconfirmedWrite
Block transfer with GET Block transfer is available
Block transfer with SET
Method Related (Services)
Read
ACTION
Write
Block transfer with ACTION
UnconfirmedWrite
Ancillary
Selective access Parametrised access
Multiple references – selective access, block transfer
Priority management Multiple references
Non client-server (services initiated by the server)
EventNotification InformationReport
What are the Association objects?
In DLMS/COSEM, the association objects play a role of a ‘gatekeeper’, controlling access to the information in the
meter and providing information on what is available.
As there are two referencing methods, there are also two types of association objects, one for Short Name and
other for Logical Name referencing.
E.g. The logical name of the current association object is 0.0.40.0.0.255. In case of SN referencing, the
base_name of the current association object is 0xFA00.
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 indicatewhether the following octet is an extension ofaddress field
iii) Only 7(higher) bits can be used for actual address
1) Client Address:-
Client addresses are always of 1-byte
b7 b6 b5 b4 b3 b2 b1 b0
Address Value 1
LSB b0 will be always ‘1’

Bits b1 to b7 represent actual client address
Address range – 0 to 127
Client address = 0x10
Hence Encoded Client address = 0x21
2) 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 1 byte server address
Server Logical address = 0x01
Encoded logical server address =0x03
HDLC 2 byte server address
a) Server Logical address = 0x01

b) Server Physical address = 0x01
Encoded Server HDLC address = 0x0203
Index
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
The DLMS/COSEM AL is supported by the HDLC based data link layer.
The structure of HDLC frame having format type 3 is as follows:
Flag Frame format Destination Source address Control HCS Information FCS Flag
address
Here the frame format type is 3.This frame format is used in those environments where additional error protection, identification of both the source and
the destination, and/or longer frame sizes are needed. Type 3 requires the use of the segmentation subfield, thus reducing the length field to 11 bits.
Frames that do not have information field, for example as with some supervisory frames, or an information field of zero length do not contain an HCS a
an FCS, only an FCS. The HCS and FCS polynomials will be the same. The HCS shall be 2 octets in length.
.............................................................................................................................................................................................................
The details of the respective different field of the frame is mentioned below:-
1) Flag field
The length of the flag field is one byte and its value is 7EH. When two or more frames are transmitted continuously, a single flag is used as both the
closing flag of one frame and the opening flag of the next frame, as it is shown in below figure.
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 BE7E
Flag Frame I Flag Frame I+1 Flag Frame I+2 Flag

Multiple frames
.............................................................................................................................................................................................................
2) Frame format field
The length of the frame format field is two bytes. It consists of three sub-fields referred to as the Format type sub-field (4 bit), the Segme
(S, 1 bit) and the frame length sub-field (11 bit), as it is shown in Figure:
MSB LSB
1 0 1 0 S L L L L L L L L L L L
Format type Frame length sub-field
The value of the format type sub-field shall be 1010 (binary), which identifies a frame
frame
format
length
type
subfield
3.Theis value
the
of octets in the frame excluding the opening and closing frame flag sequences.
7E A0 1E 03 21 93 CD 3B 81 80 12 05 01 82 06 01 82 07 04 7E
00 00 00 02 08 04 00 00 00 02 C
In above sample frame,

A0 1E
represents frame format field.
1010 0 000 0001 1110

Here 1010 tells format type 3. Next segmentation bit which is set to 0 means non segmented frame. Rest is
Length is 1E (In hex) = 30.
Number of bytes in the above frame is 32 – 2 (Here 2 bytes are of starting and ending flag) = 30 bytes
This format is interpreted as mentioned in above figure.
.............................................................................................................................................................................................................
3) Destination and source address fields
There are exactly two address fields in this frame: a destination and a source address field. Depending on the
client and the server addresses can be destination or source addresses.
Client addresses shall always be expressed on one byte.
Server address can be of 1 byte, 2 byte or four byte. In the present DLMS server we have used 1 byte server address. There are reserved client and
server addresses as mentioned in
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
As above frame is sent from client to server (request frame), in this frame 03 is destination address and 21 is source address.
In response of above request frame we get

7E A0 1E 21 03 73 C3 7A 81 80 12 05 01 80 06 01 80 07 04 00 00 00 02 08 04 00 00 00 02 A6 A1
7E
Here destination and source addresses are exchanged. Public client address (reserved) is 0x10 (means in hex).
Now the question comes that how it comes out to be 21.

So it is described here:-
0x10 Hex2Binary 0001 0000
i) Left shift it with 1

It becomes 0010 0000
ii) ORing it with 0x01
0010 0000 OR 0000 0001 = 0010 0001 Binary2Hex will become 21 and so the client address is 21
Management logical device address (reserved) is 0x01
Now the question comes that how it comes out to be 03.
So it is described here:-
0x01 Hex2Binary 0000 0001
i) Left shift it with 1

It becomes 0000 0010
ii) ORing it with 0x01
0000 0010 OR 0000 0001 = 0000 0011 Binary2Hex will become 03 and so the server address is 03
.............................................................................................................................................................................................................
4) Control field
The length of the control field is one byte. The control field indicates the type of commands or responses, and contains sequence numbers, where
appropriate (frames I, RR and RNR) for example 93 control field is fixed for SNRM, 73 is for UA frame etc.
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 BE7E
In this frame 93 is control field which is telling this is SNRM frame.
7E A0 1E 21 03 73 C3 7A 81 80 12 05 01 80 06 01 80 07 04 00 00 00 02 08 04 00 00 00 02 A6 A1 7E
In above frame control field 73 is indicating that this is UA (response of SNRM) frame.
Another type of frame is I frame which is used to transfer information. In I frame’s control field LSB (Least Significant Bit) is always 0. For example the
following frame is an I frame:
7E A0 19 03 21 32 6F D8 E6 E6 00 C0 01 81 00 01 01 00 00 00 00 FF 02 00 C6 60 7E
In this frame 32 is control field in which LSB is 0 and hence indicating that it is an I frame.
MSB LSB
32: hex2binary 0 0 1 1 0 0 1 0
For more details of Control Field and type of frames, please refer to Green Book.
.............................................................................................................................................................................................................
5) Header check sequence (HCS) field
The length of the HCS field is two bytes. HCS is calculated for the bytes of the header, excluding the opening flag and the HCS itself. The HCS is
calculated in the same way as the frame check sequence (FCS). In the below frame, CD 3B is HCS.
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
Frames that do not have an information field contain only an FCS. As in below frame with no information field, there is no HCS. 0F 01 is FCS.
7E A0 07 03 21 93 0F 01 7E
.............................................................................................................................................................................................................
6) Information field
The information field may be any sequence of bytes. For example in the below frame, information field is highlighted.
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
.............................................................................................................................................................................................................
7) Frame check sequence (FCS) field

The length of the FCS field is two bytes. FCS is calculated for the entire length of the frame, excluding the opening flag, closing flag and the FCS
itself.
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
In this frame CD BE is the FCS.
.............................................................................................................................................................................................................
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 types
HDLC Frame types are as follows:-
I <=> Information,
RR <=> Receive Ready,
RNR <=> Receive Not Ready,
SNRM <=> Set Normal Response Mode,
DISC <=> Disconnect,
UA <=> Unnumbered Acknowledge,
DM <=> Disconnected Mode,
FRMR <=> Frame Reject Response,
UI <=> Unnumbered Information
HDLC Info Frame
I Frame contains an information field for the upper layer (COSEM data). Default length is 128 bytes
R R R P/F S S S 0
It is used as both command and response
i) RRR = N( R ), Receive sequence number

ii) SSS = N( S ), Send sequence number
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 – receiv
maximum information field length – transmit HDLC parameters is 128 bytes. Other values may be negotiated
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.
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.
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).
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

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 is93 = 10010011 (means Poll bit is set).
The server should confirm acceptance of the SNRM command by sending UA response, in which control field 73
is =
01110011 (means final bit is set)
Then client sends AARQ (Application Association Request) to server, in which control field is10=00010000 (means
poll bit is set).
Server should sendAARE (Application Association Response), in which control field30=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 as
55 54 4F 38 34 34 38 38 means
UTO8488.
Request Response
SNRM (Set normal response mode) UA (Unnumbered acknowledgement)

AARQ (Application Association Request) AARE (Application Association Response)
Meter serial number OBIS request Response having meter serial number
Set of commands between Client and server (Example of Get Serial number)
SNRM (Set normal response mode) i.e. Client to Server

7E A0 1E 03 2193 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
Unnumbered acknowledgement i.e. Server to Client

7E A0 1E 21 03 73 C3 7A 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 04 00 00 00 01 53 3B 7E
AARQ (Application Association Request) i.e. Client to Server

7E A0 2F 03 2110 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 98 18 00 04 00 27 197E
AARE(Application Association Response) i.e. Server to Client
7E A0 37 21 0330 6C 7C E6 E7 00 61 29 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00
BE 10 04 0E 08 00 06 5F 1F 04 00 18 18 00 00 80 00 07 0B 63 7E
Meter serial number OBIS request i.e. Client to Server

7E A0 19 03 21 32 6F D8 E6 E6 00 C0 01 81 00 01 00 00 00 00 FF02 00 C6 60 7E
Response having meter serial numberi.e. Server to Client

7E A0 1A 21 03 52 A4 38 E6 E7 00 C4 01 81 00 09
08 55 54 4F 38 34 34 38 3867 D9 7E
====================================
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 accep
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.
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.
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;
02 //parameter value (low byte of value);
08 //parameter identifier (window size, receive);

02 // parameter value (low byte of value).
CD BE //FCS
7E //end Flag
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); means maximum how many bytes
can be transmitted in information field once.
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); means maximum how many bytes can be
received in information field once.
80 //parameter value; //128 bytes
07 //parameter identifier (window size, transmit);

02 //parameter value (low byte of value);
08 //parameter identifier (window size, receive);

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.
For more details refer Green Book
3) 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 02 84 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..
AARQ request (With security, i.e. Low level security):-
7EA047000200230310413EE6E6006036A1090607608574050801018A0207808B0760857405080201AC0A80083132333435363738BE10040E01000000065F1F0400001A1DFFFF33897E
Interpretetion:-
7E = Opening Flag
A0 = Frame format (for segmented frame A8)
47 = 71
(Decimal) No of bytes in frame except flags 7E
00 02 00 23 =Destination address (Four byte addressing is used for server)
03 = Sourceaddress (Client address is always of one byte)
10 = Control Field
413E = HCS
E6E600 = LLC header
60 = Tag for AARQ APDU
36 = 54
(Decimal) Length of AARQ contents field
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
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 // enc oding the number of unused bits in the last byte of the BIT STRING
80 // encoding of the authentication functional unit (0)
-- 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)
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
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 referenceis 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
AARE
AARE (Response of AARQ):- Server sends response to Client in form of AARE.
AARE Response:-
7EA03A030002002330AFCCE6E7006129A109060760857405080101A203020100A305A103020100BE10040E0800065F1F0400001A1D05DC00075B807E
Interpretetion:-
7E = Opening Flag
A0 = Frame format (for segmented frame A8)
3A = 58(Decimal) No of bytes in frame except flags 7E
03 = Destination address
(Client address is always of one byte)
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
-- 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
-- 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
-- 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
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 referenceis supported
· Selective access is supported
5B 80 = FCS
7E = Closing Flag
Conformance block negotiation
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
& 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
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.
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 sel
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.
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
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 class_id version(s) Clause

name
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
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 22 0 4.5.7
schedule
IEC HDLC setup 23 1 4.7.2
0 5.4.12
IEC twisted pair (1) 24 1 4.7.3
setup 0 5.4.13
M-BUS slave port 25 0 4.8.2
setup
Utility tables 26 0 4.3.7
Modem 27 1 4.7.4
configuration 0 5.4.14
PSTN modem
configuration
Auto answer 28 2 4.7.5
1 –
0 5.4.15
Auto connect 29 2 4.7.6
PSTN Auto dial 1 5.4.17
0 5.4.16
name
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 50 1 4.10.3
setup 0 5.4.18
S-FSK Active 51 0 4.10.4
initiator
S-FSK MAC 52 0 4.10.5
synchronization
timeouts
S-FSK MAC 53 0 4.10.6
counters
IEC 61334-4-32 LLC 55 1 4.10.7
setup 0 5.4.19
S-FSK IEC 61334-4-
32 LLC setup
S-FSK Reporting 56 0 4.10.8
system list
ISO/IEC 8802-2 LLC 57 0 4.11.2
Type 1 setup
ISO/IEC 8802-2 LLC 58 0 4.11.3
Type 2 setup
ISO/IEC 8802-2 LLC 59 0 4.11.4
Type 3 setup
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
Wireless Mode Q 73 0 4.8.4
channel
M-Bus master port 74 0 4.8.5
setup
DLMS/COSEM server 76 0 4.8.6
M-Bus port setup
M-Bus diagnostic 77 0 4.8.7
61334-4-32 LLC 80 0 4.12.3
SSCS setup
PRIME NB OFDM PLC 81 0 4.12.5
Physical layer
counters
MAC setup
MAC functional
parameters

name
MAC counters
MAC network
administration data
Application
identification
G3-PLC MAC layer 90 1 4.13.3
counters 0 5.4.21
G3 NB OFDM PLC
MAC layer counters
G3-PLC MAC setup 91 1 4.13.4
G3 NB OFDM PLC 0 5.4.22
MAC setup
G3-PLC 6LoWPAN 92 1 4.13.5
adaptation layer 0 5.4.23
setup
G3 NB OFDM PLC
6LoWPAN
adaptation layer
setup
ZigBee® SAS 101 0 4.14.2
startup
ZigBee® SAS join 102 0 4.14.3
ZigBee® SAS APS 103 0 4.14.4
fragmentation
ZigBee® network 104 0 4.14.5
control
ZigBee® tunnel 105 0 4.14.6
setup
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 19 03 21 32 6F D8 E6 E6 00 C0 01 8100 01 01 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
Response: (Meter serial number)

7E A0 1A 21 03 52 A4 38 E6 E7 00 C4 01 81 00 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, 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
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
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
Above request gives us the value for V1. We need to get the unit for it. For this we use attribute 03 with same
class register.
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
When making above two requests and interpreting the responses we get the value 247.69V for V1. In the same
way we can interpret any request made for register class.
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

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
44 78//Frame check sequence
7E //Frame trailer
Response
7E// Frame header

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]
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 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.
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
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
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
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 93 BB 7E A8 89 21 03 DC
F0 C4 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
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
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
65 D7// Frame check sequence
7E //Frame trailer
Answer
7E// Frame header
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 tha
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 SAP
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 si
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:
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.
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.
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 is
formally established, but the access of the client is restricted to the method reply_to_HLS_authentication of the
current "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 the
client 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.DLMS
User Association, DLMS/COSEM Architecture and Protocols, Eighth Edition DLMS User Association 2014-07-07 DLMS
UA 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 type enum. 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 servi
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 the
access rights.
Access rights to COSEM object attributes and/or methods may require authenticated, encrypted and / or signed
xDLMS 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 is
requested by the security policy: for example, security policy requires that all APDUs are authenticated but access
rights require that the APDU is enrcypted and authenticated i.e. a higher protection.
Access rights values
Bit Attribute access Method access

0 read-access access
1 write-access not-used
2 authenticated request authenticated request
3 encrypted request encrypted request
4 digitally signed response digitally signed response
5 authenticated response authenticated response
6 encrypted response encrypted response
7 digitally signed response digitally signed response
enum (3): read-write enum (1): access
enum (6) write access with enum (2): not used
authenticated request enum (4): access with
Examples enum (255): read-write authenticated request
access with authenticated, enum (253): access with
encrypted and digitally signed authenticated, encrypted and
request and response digitally signed request and
response
Security Context
The security context defines security attributes relevant for cryptographic transformations and includes the
following 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 exchanged
within 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 ar
specified 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 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
Conformance Testing and DLMS Certification
DLMS UA provides a conformance testing process. The main elements of the process are:
Conformance test tool
DLMS Certification
Listing of compliant equipment
Conformance test maintenance process.
The process is based on testing, using the Conformance Test Tool (CTT)
Certificate provided by DLMS UA once the manufacturer make product gets passed in the DLMS
compliance:-
DLMS Testing
1) CTT (Conformance Test Tool) is an application that automatically performs predefined tests on devices
implementing the COSEM object model and the DLMS/COSEM 3-layer, connection-oriented, HDLC based
communication profile or the TCP-UDP/IP based communication profile.
2) The purpose of the CTT is to verify whether the device implementation conforms to the standard, and if not it
identifies and displays those which are not correctly implemented.
3) CTT takes as input a text file called the Conformance Test Information file (CTI file) that describes the relevant
device parameters used during the test. The CTI is provided by the manufacturer in the prescribed format.
8 CTT generates:
C Line Traffic which gives the actual communication taking place between the CTT & the DUT.
A A test report showing which all test cases have passed and which all have failed. The test report is a
digitally signed file.
B Log details of the test.
As a Third Party Testing Laboratory, the device is tested using CTT and the reports are forwarded to DLMS UA fo
verification & publishing the certificates.
The certificates are published in the official website of DLMS UAhttp://www.dlms.com)

(
Test outcomes
The test verdict will be PASSED, FAILED or INCONCLUSIVE:

• PASSED – Means that the observed test outcome gives evidence of conformance to the conformance
requirement(s) on which the test purpose of the test case is focused, and is valid with respect to the relevant
specification(s);
• FAILED – Means that the observed test outcome either demonstrates non-conformance with respect to (at least
one of) the conformance requirement(s) on which the test purpose of the test case is focused, or contains at leas
one invalid test event, with respect to the relevant specification(s);
• INCONCLUSIVE – Means that the observed test outcome is such that neither a pass nor a fail verdict can be
given.
CTI File
Conformance test information (CTI)
A statement made by the supplier or implementer of an IUT integrating the PICS, the PIXIT,
the information object ICS and the information object ICT into a single document.
Sample CTI File :-
Note:-
1) Here Application context used in LN referencing. Likewise we should have CTI file for SN also.
2) Password is described as 12345678 for Low level security mechanism.
3) HDLC settings, e.g. HDLC baud rate etc. are mentioned in the HDLC Profile
DLMS Testing through CTT
Install the desired CTT version on Windows 7 / XP (preferably outside of Program files). After the installation procedure is finished, place the licence file (landis+gyr.lic) in the installed folder.
Following are the prerequisites before starting conformance testing through CTT.
a) Fill the following profiles/logs (Minimum 5 entries, Maximum 1000):
i) Billing profile
ii) Load Profiles 1 & 2
iii) Standard Event Log
iv) M-Bus Master Load profile for channel x
b) Configure Security Settings.
c) Firmware Update Log Generation.
d) Fraud Detection Log Generation.
e) Power & Voltage Quality Log Generation.
f) Power Fail Log Generation.
g) M-Bus Event Log.
h) Disconnector Control Log.
i) M-Bus Control Log 1 Generation
j) M-Bus Control Log 2 Generation
k) M-Bus Control Log 3 Generation
l) M-Bus Control Log 4 Generation
m) Check all logs.
Now enable the security setting to run the test cases with security.
CTI (Conformance test information) settings
CTI files are used to define specific information about a meter that is going to be tested. Most of the information about all meters is the same. The specific information that we
and modify if necessary, is:
1. ApplicationContextUsed – different files are used for SN and LN context
2. Firmware version
3. Serial number of the tested meter (Set tested meter Serial No in decimal)
4. PassWord (preferably use default value: 12345678 and set it in a meter as well)
5. ServerLowerMacAddress – use the same value as for attribute device_address.
6. Conformance – defines which DLMS services are implemented in a meter
7. Ident – This field has to reflect Hardware configuration and Software version of the tested meter. Some of the designators may be generic (using x instead of actual value). For example
generic Ident for Lion meters could look like this: Ident = 'Landis+Gyr E450 ZMXi3x0xPUxxxxx.xxS3_V65.01.01.xx'. This field is very important if test report is going to be sent to DLMS UA
for certification.
Testing steps when started with CTT
1) You wil require Objectmodel.dat file e.g. Object_defs_v2.7_released_130717.dat (standard file) to start up testing. The latest version of the Object_defs is 2.7 and it is generated in
accordance to the Blue Book 11
Now open CTT and then use OPTIONS tab and then select the object model.dat file to load it.
2) Now open Communication page (OPTIONS>>Communication) and then update the COMM port. Here we have seen the scenario of testing through OPTICAL port.
3) As we have already learnt that CTI file is used as input file for conformance testing hence now load CTI file (LN or SN) as shown below
Here we can also edit the CTI file. Save it if it is edited.
if CTI file is already loaded and now if you want to view the CTI file which you are using then use VIEW tab as shown below. It will show you the CTI file which is being used
4) Now select test cases which are required to run. Here only HDLC test cases are selected in the below snapshot
if we want to execute only Application layer related test cases then select only APPL related test cases as shown below
Likewise if we want to execute only COSEM related test cases then select All COSEM or if all test cases are required to execute then select ALL.
5) Connect the meter physically to the PC through optical cable. Now select RUN to execute the test cases as shown below
6) When all the test cases are executed then CTT tool will show the report as shown below
7) If we want to generate and save certification report then select HELP>> Create Certification report. It will save certification report in zip file consisting of log file, report file, CTI file
and traffic file (communication between PC and meter during testing).
...............................................................................................................................................................................................................................................................
Examples of Inconclusive test cases
Typical CTT report with allowed INCONCLUSIVE results
Note:-
# The inconclusives shown in snapshot can be ignored, as VADER meters do not support Selective access by entry.
# The inconclusives that should be addressed could be looking like this:
SetupSelectiveAccessTestByRange INCONCLUSIVE(Too few buffer entries (3), required 5)
# Conformance related test cases are basically related to HDLC, Application layer & COSEM interface related objects. The details of the test cases can be easily availbale through HELP
section of CTT tool.
DLMS FAQ
1) How to verify that the information frame is Response frame or Request frame?
Ans:- Request frame always will have LLC header as ‘E6 E6 00’ and C0 for Get-request in information field.In response frame LLC header will be‘E6 E7
00’ and C4 for get-response in information field.
........................................................................................................................................................................................................
2) How to identify a segmented frame?
Ans:- The frame format field tells whether the frame is segmented or not. The highlighted S bit if set (if S = 1) then the frame is segmented and if not
set (if S = 0) then frame is not segmented.
MSB LSB
1 0 1 0 S L L L L L L L L L L L
For example if frame format field is A0 1E means
1010 0 000 0001 1110
Here 1010 tells format type 3. Next segmentation bit which is set to 0 meanssegmented
non frame.
Let’s take another example where frame format field is A8 89 which comes out as
7E A8 89 21 rest of the frame……..

7E
1010 1 000 1000 1001 here the segmentation bit is set means it is a segmented frame.
One more example of segmentation:
7E AA 09 21 03 52
1010 1 010 0000 1001 segmentation bit set is indicating the segmented frame.
........................................................................................................................................................................................................
3) What does P/F bit mean?
Ans:- Poll/Final is a single bit with two names. It is called Poll when set by the primary station to obtain a response from a seconda
Final when set by the secondary station to indicate a response or the end of transmission. In all other cases, the bit is clear.
The bit is used as a token that is passed back and forth between the stations. Only one token should exist at a time. The seco
Final when it has received a Poll from the primary. The primary only sends a Poll when it has received a Final back from the sec
timeout indicating that the bit has been lost.
In NRM, possession of the poll token also grants the addressed secondary permission to transmit. The secondary sets the F-bit in its last response
frame to give up permission to transmit.
In ARM and ABM, the P/F bits force a response. In these modes, the secondary need not wait for a poll to transmit, so need not wait to respond
with a final bit.
If no response is received to a P bit in a reasonable period of time, the primary station times out and sends P again.
The P/F bit is at the heart of the basic checkpoint retransmission scheme that is required to implement HDLC; all other variants (such as the REJ
S-frame) are optional and only serve to increase efficiency. Whenever a station receives a P/F bit, it may assume that any frames that it sent
before it last transmitted the P/F bit and not yet acknowledged will never arrive, and so should be retransmitted.
......................................................................................................................................................................................................
4) What is the difference between association object list and capture objects?
Ans:-Association object list is the list of all the supported objects by DLMS server where as capture objects is the attribute of Profile class. Cap
objects tell what is in the profile and association object list tells what is in the meter?
........................................................................................................................................................................................................
5) What is request for Association LN (Class_id 15) with attribute 2?

Ans:-
In order to get supported COSEM objects by the server, we use Association LN class.
For every association supported in the COSEM logical
device, one instance of this class is created.
7E = Frame trailer
A0 = Frame Format type
19 = Frame length
03 21 = Destination source addresses
32 =Control field
6F D8 =Header check sequence
E6 E6 00 = LLC header
C0 01 =Get request Normal
81 =Invoke_id and priority
00 = Tag for data
0F =class id 15
00 00 28 00 01 FF = OBIS code for logical device name

02 =attribute id 02 for object_list which will provide all the supported objects with their attributes and access rights for all
. objects
00
2F 82 = Frame check sequence
7E = Frame trailer
........................................................................................................................................................................................................
6) What is Invoke Id?

Ans:-The client is allowed to send several requests before receiving the response to the previous Therefore,
ones. to be able to identify which response
corresponds to each request, it is necessary to include a reference in the request.Invoke ID is used for this purpose.
........................................................................................................................................................................................................
7) What is selective access?

Ans:- Selective access allows to access a selective portion of the attribute. Selective access is called by different names in different referencing:-
a) Selective access in LN referencing
b) Parameterized access in SN referencing
........................................................................................................................................................................................................
8) What is multiple referencing?

Ans:- Multiple referencing allows to reference more than one attribute using single request. Attribute 0: Specifying attribute-0 in a request allows access
to all attributes of the referenced object.
........................................................................................................................................................................................................
9) What is conformance block?

Ans:- The conformance block allows clients and servers using the same DLMS/COSEM protocol, but supporting different capabilities to negotiate a
compatible set of capabilities so that they can communicate.
Carried by the DLMS_Conformance parameter of the COSEM-OPEN service (while establishing Application Association).
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 to both server and client
Can be obtained by doing “Logical AND” between server conformance block and client conformance block
The details of the conformance block bit values are:-
........................................................................................................................................................................................................
10) Describe the reference objects i.e. LN and SN with examples
Ans:-
Example
Get attributes of L3 voltage object using the GET service (LN)
C00181//Get.request normal, invoke_id, priority

0003// class_if = 3, register
0101480700FF//logical name 1.1.72.7.0.255
0100//get attribute 1 (logical name) no selective access
C40181//Get.response normal, invoke_id, priority
000906//data, octet string(6)
0101480700FF//logical name 1.1.72.7.0.255, L3 voltage instantaneous
C00181 0003 0101480700FF 0200//Get attribute 2, value
C40181//
000600000905//data double long unsigned,2309D
C00181 0003 0101480700FF 0300//Get attribute 3, scaler_unit
C40181//
000202//data, structure of 2 elements
0FFF//integer, FF (-1 in 2’s complement)>>2309x0.1 = 230.9
1623//enum 23(Hex)=35 (Dec), Volts
and the same using the Read service (SN)
Object 1.1.72.7.0.255 is mapped to Base_name C440
7EA0119575BEE498E6E600// I frame header

0501//Read.request
02//CHOICE variable-name
C440//base name of object 1.1.72.7.0.255 (logical name)
E67C7E//I frame trailer
0C01//Read.response
00//Data
09060101480700FF//Octet string(6), 1.1.72.7.0.255
050102 C448//Read base name+8, attribute 2
0C01000600000937//Read.response,double long unsigned, 2359
050102 C450//Read base name +16, attribute 3
0C01000202// Read.response,structure of 2,
0FFF // first element is integer FF = -1
1623 // second element is enum 23(Hex)=35 (Dec), Volts
L3 voltage is 235.9 V
11) How to verify that the information frame is request frame or response frame?
Ans:- Request frame consists of OBIS code along with the information of class id and attribute type of that OBIS code.
E.g. 7E A0 19 03 21 32 6F D8 E6 E6 00 C0 01 81 00 01 01 00 00 00 00 FF 02 00 C6 60 7E
Whereas Response frame consists of data type and length of the response in hex
7E A0 1A 21 03 52 A4 38 E6 E7 00 C4 01 81 00 09 08 55 53 4F 38 34 34 38 37 90 21 7E
12) What is AA (Application Association)?

Ans:- AAs (Application Association) are modelled by COSEM "Association SN/LN" objects that hold the SAPs identifying the associated partners, Name of
the Application context, Name of the Aunthentication Mechanism & xDLMS context.
..................................................................................................................................................................................................................................................................

DLMS Handbook

Uploaded by

Copyright:

Available Formats

You might also like

DLMS Handbook

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DLMS Handbook

Uploaded by

Copyright:

Available Formats

DLMS Hand Book

DLMS stands for Distribution Line Message Specification.

2. Development and maintenance

3. Registration of standard elements

4) White Book:-GLOSSARY OF TERMShelps to understand thespecification. Internationally standardized by the

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

Three steps approach of DLMS/COSEM: Modelling-Messaging-Transporting-

OBIS is a object identification system

0 General purpose objects

128...254 Manufacturer specific

128…254 Manufacturer specific codes

The range for value group F is 0 to 255.

1. Physical layer: Physical layer provides physical media for communication.

Any pie ce of in f or ma tio n mo de le d b y C O S E M can be accessed as an attribute or me thod of a certain C O S E M

SN re fe re ncin g is mor e suitable f o r s imple d e v ices and LN re fe re ncin g f o r comple x devices.

Attribute related (Services)

Method Related (Services)

The destination and source link addresses can be of

i) Address field can be extended (up to 4 octets)

iii) Only 7(higher) bits can be used for actual address

Client addresses are always of 1-byte

LSB b0 will be always ‘1’

Client address = 0x10

Hence Encoded Client address = 0x21

a) Server addresses consists of:-

b) Lower HDLC Address may be omitted

One Byte: Only the upper HDLC address present

Upper HDLC Address

Upper HDLC Address Lower HDLC Address

HDLC 1 byte server address

Server Logical address = 0x01

Encoded logical server address =0x03

HDLC 2 byte server address

a) Server Logical address = 0x01

The DLMS/COSEM AL is supported by the HDLC based data link layer.

The structure of HDLC frame having format type 3 is as follows:

Flag Frame I Flag Frame I+1 Flag Frame I+2 Flag

2) Frame format field

Format type Frame length sub-field

In above sample frame,

1010 0 000 0001 1110

This format is interpreted as mentioned in above figure.

3) Destination and source address fields

In response of above request frame we get

Now the question comes that how it comes out to be 21.

0x10 Hex2Binary 0001 0000

i) Left shift it with 1

0x01 Hex2Binary 0000 0001

i) Left shift it with 1

In this frame 93 is control field which is telling this is SNRM frame.

5) Header check sequence (HCS) field

7) Frame check sequence (FCS) field

In this frame CD BE is the FCS.

SNRM (Set Normal Response Mode)

HDLC Frame types are as follows:-

HDLC Info Frame

It is used as both command and response

i) RRR = N( R ), Receive sequence number

Information transfer command and response