EN 62056-7-3:2017

SLOVENSKI STANDARD
01-september-2017
,]PHQMDYDSRGDWNRYSULPHUMHQMXHOHNWULþQHHQHUJLMH1L]'/06&26(0GHO
3URILOLRåLþHQHLQEUH]åLþQH0%XVL]PHQMDYHSRGDWNRY]DORNDOQDLQVRVHGQMD
RPUHåMD
Electricity metering data exchange - The DLMS/COSEM suite - Part 7-3: Wired and
wireless M-Bus communication profiles for local and neighbourhood networks
Ta slovenski standard je istoveten z: EN 62056-7-3:2017
ICS:
17.220.20 0HUMHQMHHOHNWULþQLKLQ Measurement of electrical
PDJQHWQLKYHOLþLQ and magnetic quantities
35.100.05 9HþVORMQHXSRUDEQLãNH Multilayer applications
UHãLWYH
91.140.50 Sistemi za oskrbo z elektriko Electricity supply systems
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 62056-7-3

NORME EUROPÉENNE
EUROPÄISCHE NORM
June 2017
ICS 17.220.20; 35.100.01; 91.140.50

English Version
Electricity metering data exchange - The DLMS/COSEM suite -
Part 7-3: Wired and wireless M-Bus communication profiles for
local and neighbourhood networks
(IEC 62056-7-3:2017)
Échange des données de comptage de l'électricité - La Datenkommunikation der elektrischen Energiemessung -
suite DLMS/COSEM - Partie 7-3: Profils de communication DLMS/COSEM - Teil 7-3: Kommunikationsprofile für
M-Bus filaires et sans fil pour les réseaux locaux et de drahtgebundenen und funkbasierten M-Bus für lokale und
voisinage Areal-Netze
(IEC 62056-7-3:2017) (IEC 62056-7-3:2017)
This European Standard was approved by CENELEC on 2017-04-11. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden,
Switzerland, Turkey and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2017 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN 62056-7-3:2017 E
European foreword
The text of document 13/1729/FDIS, future edition 1 of IEC 62056-7-3, prepared by
IEC/TC 13 "Electrical energy measurement and control" was submitted to the IEC-CENELEC parallel
vote and approved by CENELEC as EN 62056-7-3:2017.

The following dates are fixed:
(dop) 2018-01-11
• latest date by which the document has to be
implemented at national level by
publication of an identical national
standard or by endorsement
• latest date by which the national (dow) 2020-04-11
standards conflicting with the
document have to be withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC [and/or CEN] shall not be held responsible for identifying any or all such
patent rights.
Endorsement notice
The text of the International Standard IEC 62056-7-3:2017 was approved by CENELEC as a
European Standard without any modification.
In the official version, for Bibliography, the following notes have to be added for the standards indicated:

IEC 60870-5-1:1990 NOTE Harmonized as EN 60870-5-1:1993 (not modified).
IEC 62056-1-0 NOTE Harmonized as EN 62056-1-0.
IEC 62056-7-5 NOTE Harmonized as EN 62056-7-5.
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications

The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.

NOTE 1 When an International Publication has been modified by common modifications, indicated by (mod), the relevant
EN/HD applies.
NOTE 2 Up-to-date information on the latest versions of the European Standards listed in this annex is available here:
www.cenelec.eu
Publication Year Title EN/HD Year

- - Communication systems for meters - EN 13757-1 -
Part 1: Data exchange
- - Communication systems for meters and EN 13757-2 2004
remote reading of meters -
Part 2: Physical and link layer
- - Communication systems for meters and EN 13757-3 2013
remote reading of meters -
Part 3: Dedicated application layer
- - Communication systems for meters and EN 13757-4 2013
remote reading of meters -
Part 4: Wireless meter readout (Radio
meter reading for operation in SRD bands)
IEC 62056-5-3 2016 Electricity metering data exchange - EN 62056-5-3 2016
The DLMS/COSEM suite -
Part 5-3: DLMS/COSEM application layer
IEC 62056-6-1 2015 Electricity metering data exchange - EN 62056-6-1 2016
The DLMS/COSEM suite -
Part 6-1: Object Identification System
(OBIS)
IEC 62056-6-2 2016 Electricity metering data exchange - EN 62056-6-2 2016
The DLMS/COSEM suite -
Part 6-2: COSEM interface classes
1) 1)
IEC 62056-6-2 -  Electricity metering data exchange - EN 62056-6-2 -
The DLMS/COSEM suite -
Part 6-2: COSEM interface classes

1)
At draft stage.
IEC 62056-7-3 ®
Edition 1.0 2017-03
INTERNATIONAL
STANDARD
colour
inside
Electricity metering data exchange – The DLMS/COSEM suite –

Part 7-3: Wired and wireless M-Bus communication profiles for local and

neighbourhood networks
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 17.220.20; 35.100.01; 91.140.50 ISBN 978-2-8322-4012-0

– 2 – IEC 62056-7-3:2017 © IEC 2017
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Terms, definitions and abbreviated terms . 8
3.1 Terms and definitions. 8
3.2 Abbreviated terms . 8
4 Targeted communication environments . 9
5 Use of the communication layers for this profile . 9
5.1 Information related to the use of the standard specifying the lower layers . 9
5.2 Structure of the communication profiles . 9
5.3 Lower protocol layers and their use . 10
5.3.1 Physical layer . 10
5.3.2 Link layer . 10
5.3.3 Transport layer . 11
5.4 Service mapping and adaptation layers . 11
5.4.1 Overview . 11
5.4.2 MBUS-DATA service primitives . 12
5.4.3 MBUS-DATA protocol specification . 14
5.5 Registration and connection management . 16
6 Identification and addressing scheme . 16
6.1 Overview . 16
6.2 Link Layer Address for wired M-Bus . 17
6.3 Link Layer Address for wireless M-Bus . 18
6.4 Link Layer Address for M-Bus broadcast . 18
6.5 Transport layer address . 19
6.6 Application addressing extension – M-Bus wrapper . 21
7 Specific considerations and constraints for using certain services within profile . 22
7.1 Overview . 22
7.2 Application association establishment and release: ACSE services . 22
7.3 xDLMS services . 23
7.3.1 Request – response type services . 23
7.3.2 Unsolicited services . 23
7.3.3 Broadcast messages . 23
7.4 Security mechanisms . 24
7.5 Transporting long application messages . 24
7.6 Media access, bandwidth and timing considerations . 24
8 Communication configuration and management . 24
Annex A (informative) M-Bus frame structures, addressing schemes and examples . 25
A.1 General . 25
A.2 None, short or long M-Bus data header . 26
A.2.1 Wired M-Bus . 26
A.2.2 Wireless M-Bus . 27
A.3 Encoding example: Data-Notification carrying daily billing data . 30
A.3.1 Overview . 30
A.3.2 Example: Daily billing data. 31

IEC 62056-7-3:2017 © IEC 2017 – 3 –
Annex B (normative)  New COSEM interface classes related to the M-Bus
communication profiles . 33
Annex C (informative) Message sequence charts . 34
Bibliography . 37

Figure 1 – Entities and interfaces of a smart metering system using the terminology of
IEC 62056-1-0 . 9
Figure 2 – The DLMS/COSEM wired and wireless M-Bus communication profiles . 10
Figure 3 – Summary of DLMS/COSEM M-Bus-based TL services . 12
Figure 4 – Identification and addressing scheme in the wired M-Bus profile . 17
Figure 5 – Link Layer Address for wireless M-Bus . 18
Figure 6 – M-Bus TPDU formats . 20
Figure 7 – CI without M-Bus data header . 20
TL
Figure A.1 – M-Bus communication paths direct or cascaded . 25
Figure A.2 – Wired M-Bus frame structure, none M-Bus data header . 27
Figure A.3 – Wired M-Bus frame structure with long M-Bus data header . 27
Figure A.4 – Wireless M-Bus frame structure with short ELL, no M-Bus data header . 29
Figure A.5 – Wireless M-Bus frame structure with long ELL, no M-Bus data header . 29
Figure A.6 – Wireless M-Bus frame structure with long ELL and long M-Bus data
header . 30
Figure A.7 – Daily billing data without / with DLMS/COSEM security applied . 32
Figure C.1 – MSC for the COSEM-OPEN service for wired M-Bus, no M-Bus header . 35
Figure C.2 – MSC the GET service for wired M-Bus, no M-Bus header . 36

Table 1 – Wired M-Bus Link Layer Addresses . 18
Table 2 – DLMS/COSEM M-Bus-based TL CI values . 19
TL
Table 3 – CI fields used for link management purposes . 21
Table 4 – Client and server SAPs . 21
Table 5 – Application associations and data exchange in the M-Bus-based profiles . 22
Table A.1 – Example: Daily billing data . 31

– 4 – IEC 62056-7-3:2017 © IEC 2017
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
ELECTRICITY METERING DATA EXCHANGE –
THE DLMS/COSEM SUITE –
Part 7-3: Wired and wireless M-Bus communication
profiles for local and neighbourhood networks

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The International Electrotechnical Commission (IEC) draws attention to the fact that it is
claimed that compliance with this International Standard may involve the use of a
maintenance service concerning the stack of protocols on which the present standard
IEC 62056-5-3 is based.
The IEC takes no position concerning the evidence, validity and scope of this maintenance
service.
IEC 62056-7-3:2017 © IEC 2017 – 5 –
The provider of the maintenance service has assured the IEC that he is willing to provide
services under reasonable and non-discriminatory terms and conditions for applicants
throughout the world. In this respect, the statement of the provider of the maintenance service
is registered with the IEC. Information may be obtained from:
DLMS User Association
Zug/Switzerland
www.dlms.com
International Standard IEC 62056-7-3 has been prepared by IEC technical committee 13:
Electrical energy measurement and control.
The text of this standard is based on the following documents:
FDIS Report on voting
13/1729/FDIS 13/1731/RVD
Full information on the voting for the approval of this International Standard can be found in
the report on voting indicated in the above table.
This document has been drafted in accordance with the ISO/IEC Directives, Part 2.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to
the specific document. At this date, the document will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
___________
1 Device Language Message Specification.

– 6 – IEC 62056-7-3:2017 © IEC 2017
INTRODUCTION
As defined in IEC 62056-1-0, the IEC 62056 DLMS/COSEM suite provides specific
communication profile standards for communication media relevant for smart metering.
Such communication profile standards specify how the COSEM data model and the
DLMS/COSEM application layer can be used on the lower, communication media-specific
protocol layers.
Communication profile standards refer to communication standards that are part of the
IEC 62056 DLMS/COSEM suite or to any other open communication standard.
This International Standard specifies DLMS/COSEM communication profiles for wired and
wireless M-Bus networks using the lower layers specified in the EN 13757 series.
It follows the rules defined in IEC 62056-5-3, Annex A.
The DLMS/COSEM wired and wireless M-Bus communication profiles for local and
neighbourhood networks may be used for smart energy data exchange with meters as well as
with simple consumer displays and home automation systems.

IEC 62056-7-3:2017 © IEC 2017 – 7 –
ELECTRICITY METERING DATA EXCHANGE –
THE DLMS/COSEM SUITE –
Part 7-3: Wired and wireless M-Bus communication
profiles for local and neighbourhood networks

1 Scope
This International Standard specifies DLMS/COSEM wired and wireless M-Bus communication
profiles for local and neighbourhood networks.
Setting up and managing the M-Bus communication channels of M-Bus devices, the M-Bus
network, registering slave devices and – when required – repeaters is out of the scope of this
International Standard.
The scope of this communication profile standard is restricted to aspects concerning the use
of communication protocols in conjunction with the COSEM data model and the
DLMS/COSEM application layer. Data structures specific to a communication protocol are out
of the scope of this standard. Any project-specific definitions of data structures and data
contents may be provided in project-specific companion specifications.
Annex A (informative) provides information on M-Bus frame structures, addressing schemes
and an encoding example.
Annex B (normative) points to COSEM interface classes to set up and manage the wired and
wireless M-Bus communication channel.
Annex C (informative) provides MSCs for representative instances of communication.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their
content constitutes requirements of this document. For dated references, only the edition
cited applies. For undated references, the latest edition of the referenced document (including
any amendments) applies.
IEC 62056-5-3:2016, Electricity metering data exchange – The DLMS/COSEM suite –
Part 5-3: DLMS/COSEM application layer
IEC 62056-6-1:2015, Electricity metering data exchange – The DLMS/COSEM suite –
Part 6-1: Object identification system (OBIS)
IEC 62056-6-2:2016, Electricity metering data exchange – The DLMS/COSEM suite –
Part 6-2: COSEM interface classes
IEC 62056-6-2:— , Electricity metering data exchange – The DLMS/COSEM suite – Part 6-2:
COSEM interface classes
___________
Under preparation. Stage at the time of publication: IEC/CDV 62056-6-2:2016.

– 8 – IEC 62056-7-3:2017 © IEC 2017
EN 13757-1, Communication system for meters – Part 1: Data exchange
EN 13757-2:2004, Communication system for and remote reading of meters – Part 2: Physical
and link layer
EN 13757-3:2013, Communication systems for and remote reading of meters – Part 3:
Dedicated application layer
EN 13757-4:2013, Communication systems for meters and remote reading of meters – Part 4:
Wireless meter readout (Radio meter reading for operation in SRD bands)
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62056-5-3,
IEC 62056-6-1, IEC 62056-6-2 and in the EN 13757 series apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.2 Abbreviated terms
The following M-Bus specific abbreviated terms are used in this standard.
Abbrev. Term Standard domain
ACC Access number field M-Bus
ALA Application Layer Address M-Bus
CFG Configuration byte M-Bus
CI CI field introducing the extended link layer (wireless M-Bus) M-Bus
ELL
CI Field Control Information field M-Bus
CI CI field introducing the transport layer M-Bus
TL
DTSAP Destination Transport Service Access Point Telecontrol
ELL Extended Link Layer M-Bus
ELLA Extended Link Layer Address M-Bus
FIN (bit) Final bit Telecontrol
FT1.2 Data integrity format class FT1.2 Telecontrol
FT3 Data integrity format class FT3 Telecontrol
LLA Link Layer Address M-Bus
MSC Message Sequence Chart General
STS Status byte M-Bus
STSAP Source Transport Service Access Point Telecontrol
TL Transport layer M-Bus
wM-Bus Wireless M-Bus M-Bus
IEC 62056-7-3:2017 © IEC 2017 – 9 –
4 Targeted communication environments
In the context of the smart metering architecture introduced in IEC 62056-1-0 and shown in
Figure 1, the wired and wireless M-Bus communication profiles for local and neighbourhood
networks cover the following interfaces:
• the C interface between an NNAP and metering devices;
• the M interface between an LNAP and metering devices;
• the H1 interface between a metering device and a simple consumer display;
• the H2 interface between an LNAP and a home automation system.
In all cases, metering devices act as DLMS/COSEM servers.
On the C and M interface, metering devices act as M-Bus slaves. The M-Bus master is the
NNAP or the LNAP.
On the H1 and H2 interfaces the metering device acts as a DLMS/COSEM server. It may
operate in pull mode or push mode, as M-Bus master or M-Bus slave, depending on the
selection of wired or wireless M-Bus and the operating mode for wireless M-Bus.
Simple
H1
Metering
consumer
device
Home automation
display
system
G1 C M
L
M
G1 LNAP Local network H2
access point
N
C C
NNAP Neighbourhood network H3
access point
G2
G1
HES Head end system
IEC
Figure 1 – Entities and interfaces of a smart metering
system using the terminology of IEC 62056-1-0
5 Use of the communication layers for this profile
5.1 Information related to the use of the standard specifying the lower layers
The DLMS/COSEM wired and wireless M-Bus communication profiles for local and
neighbourhood networks use the lower-layer protocols specified in the EN 13757 series.
Subclause 5.3.3 provides additional information on the use of the M-Bus transport layer in this
communication profile.
5.2 Structure of the communication profiles
The structure of the DLMS/COSEM M-Bus wired and wireless M-Bus communication profiles
is shown in Figure 2.
WAN Wide area network
NN Neighbourhood
LN Local network
– 10 – IEC 62056-7-3:2017 © IEC 2017
DLMS/COSEM wired DLMS/COSEM wireless
M-Bus profile M-Bus profile
COSEM data model
DLMS UA Blue book / IEC 62056-6-1, IEC 62056-6-2
M-Bus dedicated
DLMS/COSEM Application layer
application layer
DLMS UA Blue book / IEC 62056-5-3
EN 13757-3
DLMS/COSEM M-Bus based transport layer
M-Bus Wrapper
M-Bus transport layer EN 13757-3
CI =
TL CI =
TL
0x00 – 0x1F
Other values
0x60 / 0x7C
see EN 13757-3
0x61 / 0x7D
M-Bus wired link layer M-Bus wireless link layer
EN 13757-2 EN 13757-4 / EN 13757-5
M-Bus wired Phy layer M-Bus wireless Phy layer
EN 13757-2 / EN 13757-6 EN 13757-4

IEC
Figure 2 – The DLMS/COSEM wired and wireless M-Bus communication profiles
5.3 Lower protocol layers and their use
5.3.1 Physical layer
The physical layer is as specified in EN 13757-2:2004 (wired, twisted pair based) and in
EN 13757-4:2013 (wireless).
For battery-operated masters and/or a small number of connected meters, a wired M-Bus
physical layer is specified in EN 13757-6 (twisted pair based for short distances).
5.3.2 Link layer
The M-Bus link layer is as specified in EN 13757-2:2004 (wired) and in EN 13757-4:2013
(wireless).
NOTE For wireless meter readout EN 13757-5:2015 supports simple retransmission (single-hop repeating) as well
as routed wireless networks that allow extending the range of transmission.

IEC 62056-7-3:2017 © IEC 2017 – 11 –
5.3.3 Transport layer
The M-Bus transport layer is as specified in EN 13757-3:2013.
Together with an M-Bus wrapper specified in 6.6, it constitutes the DLMS/COSEM M-Bus-
based transport layer (TL) that acts as an adaptation layer between the link layer and the
DLMS/COSEM AL.
The M-Bus TL allows several application layers to co-exist over the M-Bus lower layers.
These can be:
• the M-Bus dedicated AL;
• the DLMS/COSEM AL; or
• some other AL that may be specified in the future.
The AL used is selected by the Control Information (CI) field of the M-Bus frame.
In the communication profiles specified in this document, only the DLMS/COSEM AL is used.
There are also CI field values for network management purposes. M-Bus frames carrying such
CI field values do not necessarily carry application data.
5.4 Service mapping and adaptation layers
5.4.1 Overview
As already mentioned in 5.3.3, in the wired and wireless M-Bus communication profiles for
local and neighbourhood networks the DLMS/COSEM M-Bus-based TL acts as an adaptation
layer between the M-Bus link layer and the DLMS/COSEM AL.
It comprises the transport layer specified in EN 13757-3:2013 and a wrapper layer.
It provides OSI-style connectionless data services with optional segmentation and reassembly
to the service user DLMS/COSEM AL.
The M-Bus wrapper – specified in 6.6 – provides the addressing capability required to
address client and server DLMS/COSEM APs.
The service primitives are shown in Figure 3 and they are the same on the client and server
side.
The .request service primitive is used to send a COSEM APDU to the peer TL.
The .indication service primitive indicates the reception of a COSEM APDU from the peer TL.
The .confirm service primitive is locally generated. It provides information to the AL about the
status of sending the COSEM APDU.

– 12 – IEC 62056-7-3:2017 © IEC 2017
DLMS/COSEM Application layer
DLMS/COSEM M-Bus based transport layer
M-Bus wrapper
M-Bus transport layer
IEC
Figure 3 – Summary of DLMS/COSEM M-Bus-based TL services
5.4.2 MBUS-DATA service primitives
5.4.2.1 MBUS-DATA.request
Function
The MBUS-DATA.request primitive is used by the DLMS/COSEM AL to request the
DLMS/COSEM M-Bus-based TL to send a COSEM APDU to (a) peer DLMS/COSEM M-Bus-
based transport layer(s).
NOTE Multicast or broadcasting is available only in the direction client to server.
Semantics
The primitive shall provide the service parameters as follows:
MBUS-DATA.request (
M-Bus_Data_Header_Type,
STSAP,
DTSAP,
Data
)
The M-Bus_Data_Header_Type parameter indicates the M-Bus data header type to be used in
the M-Bus frame to be sent. Its value can be None_M-Bus_Data_Header, Short_M-
Bus_Data_Header or Long_M-Bus_Data_Header, see Figure 6.
The STSAP parameter indicates the TL service access point (SAP) belonging to the device /
AP requesting to send the Data.
The DTSAP parameter indicates the TL SAP belonging to the device(s) / AP(s) to which the
Data is to be transmitted.
The Data parameter contains the COSEM APDU to be transferred to the peer AL.
MBUS-Data.req
MBUS-Data.cnf
MBUS-Data.ind
IEC 62056-7-3:2017 © IEC 2017 – 13 –
Use
The MBUS-DATA.request service primitive is invoked by either the client or the server
DLMS/COSEM AL to request sending a COSEM APDU to a single peer AL or – in the case of
multicast or broadcasting (by the client only) – to multiple peer ALs.
The reception of this primitive shall cause the DLMS/COSEM M-Bus-based TL to build the
appropriate M-Bus data header accordingly and to construct the TPDU data unit to be passed
to the M-Bus data link layer.
When the APDU to be sent is too long to fit in a single M-BUS frame, then segmentation may
be used, see 5.4.3.
5.4.2.2 MBUS-DATA.indication
Function
The MBUS-DATA.indication primitive is used by the DLMS/COSEM M-Bus-based TL to pass a
COSEM APDU received from the peer DLMS/COSEM M-Bus-based TL to the service user
DLMS/COSEM AL.
Semantics
The primitive shall provide the service parameters as follows:
MBUS-DATA.indication (
M-Bus_Data_Header_Type,
STSAP,
DTSAP,
Data
)
The M-Bus_Data_Header_Type parameter indicates M-Bus data header type used in the M-
Bus frame received. Its value can be None_M-Bus_Data_Header, Short_M-Bus_Data_Header
or Long_M-Bus_Data_Header, see Figure 6.
The STSAP parameter indicates the TL SAP belonging to the device / AP that has sent the
Data.
The DTSAP parameter indicates the TL SAP belonging to the device / AP that has received
the Data.
The Data parameter contains the COSEM APDU received from the peer AL.
Use
The MBUS-DATA.indication service primitive is generated by the DLMS/COSEM M-Bus-based
TL to indicate to the service user DLMS/COSEM AL that a COSEM APDU from the peer layer
entity has been received.
According to the received M-Bus data header, the TL allocates and passes only the M-
Bus_Data_Header_Type to the DLMS/COSEM AL, but not the values of the received M-Bus
data header.
If the STSAP or DTSAP are not valid – meaning that there is no AA bound to the given SAPs
– the message received shall be simply discarded.

– 14 – IEC 62056-7-3:2017 © IEC 2017
NOTE If the CI field and the elements of the short or long M-Bus data header do not match, the TPDU is
TL
discarded by the EN 13757 M-Bus TL.
5.4.2.3 MBUS-DATA.confirm
Function
The MBUS-DATA.confirm service primitive allows the DLMS/COSEM M-Bus-based TL to
inform the DLMS/COSEM AL about the status of transmitting the data following a .request.
Semantics
The primitive shall provide the service parameters as follows:
MBUS-DATA.confirm (
M-Bus_Data_Header_Type
STSAP,
DTSAP,
Transmission_Status
)
The value of the M-Bus_Data_Header_Type, STSAP and DTSAP parameters shall be the
same as in the .request service primitive being confirmed.
The Transmission_Status parameter indicates the status of sending the data requested by the
previous MBUS-DATA.request service. Its value can be SUCCESS, PENDING or FAILED.
Use
The MBUS-Data.confirm service primitive is generated locally by the DLMS/COSEM M-Bus-
based TL to inform the service user DLMS/COSEM AL on the status of sending the Data in
the .request primitive:
• Transmission_Status == SUCCESS means that the Data has been sent. It does not mean
that the Data has been (or will be) successfully delivered to the destination;
• Transmission_Status == PENDING means that sending the Data has been prepared or is
in progress;
• Transmission_Status == FAILED, means that the Data could not be sent by M-Bus lower
layers.
5.4.3 MBUS-DATA protocol specification
5.4.3.1 Sending COSEM APDUs
When the DLMS/COSEM AL has to send a COSEM APDU to (a) peer AL(s), it invokes the
MBUS-DATA.request primitive.
Upon the reception of this request, the DLMS/COSEM M-Bus-based TL builds the appropriate
TPDU. The fields of the TPDU are the following, see also Figure 6:
• the CI field, that indicates the kind of M-Bus data header used;
TL
• the M-Bus data header, according to the value of the CI field;
TL
• the STSAP;
• the DTSAP; and the
• Data field i.e. the COSEM APDU or – when segmentation is used – a part of it.
The value of the CI field depends on the M-Bus_Data_Header_Type parameter:
TL
IEC 62056-7-3:2017 © IEC 2017 – 15 –
• when M-Bus_Data_Header_Type == None_M-Bus_Data_Header, the value of the CI
TL
field shall be 0x10 when segmentation is not used, and shall be 0x00.0x1F when
segmentation is used (with the FIN bit set to 0 in all segments except in the last segment);
• when M-Bus_Data_Header_Type == Short_M-Bus_Data_Header, the value of the CI
TL
field shall be 0x61 in a M-Bus frame sent by a master and 0x7D in a M-Bus frame sent by
a slave;
• when M-Bus_Data_Header_Type == Long_M-Bus_Data_Header, the value of the CI
TL
field shall be 0x60 in an M-Bus frame sent by a master and 0x7C in an M-Bus frame sent
by a slave.
In the case of a pull operation, the kind of M-Bus data header in M-Bus frames sent by the
slave shall be the same as in the frames received from the master unless when segmentation
needs to be used.
The client shall choose the M-Bus data header type according to the M-Bus media used –
wired or wireless – and the capabilities of the server.
In the case of a push operation – using the xDLMS DataNotification service, see
IEC 62056-5-3:2016, 6.10 – the M-Bus data header type is determined by the M-Bus slave.
The APDU can be sent without segmentation or, when it does not fit to a single M-Bus frame,
with segmentation. Segmentation is available only when no M-Bus data header is used.
Sending COSEM APDUs without segmentation
When the M-Bus-based TL has successfully built the TPDU, it invokes the .request service
primitive.
The .conf service primitive is invoked by the M-Bus-based TL with the value == SUCCESS
once the lower layers confirm that the TPDU has been successfully sent.
If the lower layers cannot immediately send the M-Bus frame for whatever reason, then
the .conf service primitive may be invoked by the M-Bus-based TL with the value ==
PENDING. When the lower layers indicate that the M-Bus frame could not be sent for
whatever reason, then the .conf service primitive shall be invoked by the M-Bus-based TL
with the value == FAILED.
When no M-Bus data header is used and the value of CI = 0x10 (indicating that the payload
TL
is a complete COSEM APDU) or when the short M-Bus data header (CI = 0x61) or the long
TL
M-Bus data header (CI = 0x60) is used, the TPDU has to fit in a single M-Bus frame. If the
TL
TPDU does not fit in a single M-Bus frame, then the MBUS-Data.conf service primitive shall
be invoked by the M-Bus-based TL with the value == FAILED.
Sending COSEM APDUs with segmentation
When the M-Bus_Data_Header_Type indicates None_M-Bus_Data_Header and the APDU to
be sent does not fit in a single M-Bus frame, the transport layer shall use segmentation. The
APDU is divided by the TL into as many parts as necessary so that each segment fits in a
single M-Bus frame. Each TPDU shall contain a CI field with the appropriate value – see
TL
Figure 7 – and one segment of the COSEM APDU. The TPDU containing the next segment
can be sent once the confirmation of sending the previous segment from the lower layers is
received.
The .conf service primitive is invoked by the M-Bus-based TL with the value == SUCCESS
when the lower layers confirm that the last segment has been successfully sent.

– 16 – IEC 62056-7-3:2017 © IEC 2017
The MBUS-Data.conf service primitive can be invoked by the M-Bus-based TL with the value
== PENDING multiple times while the segments are being sent.
5.4.3.2 Receiving COSEM APDUs
The DLMS/COSEM M-Bus-based TL uses the MBUS-DATA.indication primitive to pass the
APDU received from a peer TL to the AL.
When the TL receives an M-Bus frame, it checks the value of the CI and the STSAP/DTSAP
TL
fields. When the values are not valid, the frame shall be discarded.
A STSAP and DTSAP pair is valid if there is an AA bound to these SAPs.
Receiving COSEM APDUs without segmentation
If the CI field indicates that the M-Bus frame contains a complete APDU, then the TL
TL
invokes the .ind service primitive.
Receiving COSEM APDUs with segmentation
If the CI field indicates that the M-Bus frame contains a part of the complete APDU, then
TL
the TL assembles the Data fields received in the segments and invokes the .ind service
primitive when the final segment has been received.
However, if a segment is missing, all segments shall be discarded and the .confirm service
primitive shall not be invoked.
NOTE The M-Bus-based TL does not provide a mechanism to recover lost segments.
5.5 Registration and connection management
Devices hosting DLMS/COSEM servers and implementing these profiles act as M-Bus slaves.
Their installation by the M-Bus master – that may be an LNAP or an NNAP – is out of the
scope of this document.
NOTE The LNAP / NNAP may provide additional services like protocol conversion, security services and other
services for entities outside the local / neighbourhood network as described in CEN / CLC / ETSI TR 50572.
The management of M-Bus entities is described in a general way in EN 13757-3:2013. Specific aspects for wired
M-Bus networks are specified in EN 13757-2:2004 and for wireless M-Bus networks in EN 13757-4:2013 and EN
13757-5:2015.
The primary_address of the device – see 6.2 and 6.3 – is held by the “DLMS/COSEM server
M-Bus port setup” object primary_address attribute. See Clause 8
6 Identification and addressing scheme
6.1 Overview
The wired and wireless M-Bus communication profiles for local and neighbourhood networks
provide three levels of addressing:
• the Link Layer Address LLA identifies the physical device entity on the M-Bus. See 6.2,
6.3 and 6.4;
• the TL address CI acts as a protocol selector and provides information on the structure
TL
of the TPDU and the options and capabilities available. In this profile, it selects the
DLMS/COSEM M-Bus-based TL. See 6.5;

IEC 62056-7-3:2017 © IEC 2017 – 17 –
• the M-Bus wrapper, contained in the TL, provides addressing for COSEM client and server
APs. See 6.6.
NOTE 1 In some cases – e.g. in the case when wireless M-Bus is used and repeaters are present – additional
addressing may be needed, but this is out of the scope of this communication profile specification.
Together, these addresses allow messages to be transported non-ambiguously between a
specific client AP and a specific server AP.
All addresses are provided by a protocol layer and they are present in a layer-specific M-Bus
frame header. An example is shown in Figure 4.
The triplet {LLA, CI , SAP} unambiguously identifies an AP:
TL
• when the client AP#1 (Public Client) wants to send a xDLMS APDU to server AP#1
(Management LD) in server host device #1, the M-Bus frame shall carry the following
addresses:
– LLA = 0x45, CI = 0x61, STSAP = 0x10, DTSAP = 0x01.
TL
• in the response, the M-Bus frame shall carry the following addresses:
– LLA = 0x45, CI = 0x7D, STSAP = 0x01, DTSAP = 0x10.
TL
NOTE 2 For the use of the LLA in the wired M-Bus profile, please see 6.2.
IEC
Figure 4 – Identification and addressing scheme
in the wired M-Bus profile
6.2 Link Layer Address for wired M-Bus
The Link Layer Address (LLA) carries, in both communication directions, the secondary
station (M-Bus slave) address of the physical device entity on the M-Bus which is c
...