En 13757 3 2018 04

EUROPEAN STANDARD EN 13757-3
NORME EUROPÉENNE
EUROPÄISCHE NORM April 2018
ICS 33.200; 35.100.70; 35.240.99; 91.140.50 Supersedes EN 13757-3:2013
English Version
Communication systems for meters - Part 3: Application

protocols
Systèmes de communication pour compteurs - Partie 3 Kommunikationssysteme für Zähler - Teil 3:
: Protocoles d'application Anwendungsprotokolle
This European Standard was approved by CEN on 8 February 2018.
CEN 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 CEN
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 CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION

COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2018 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 13757-3:2018 E
worldwide for CEN national Members.
EN 13757-3:2018 (E)
Contents Page
European foreword....................................................................................................................................................... 4
Introduction .................................................................................................................................................................... 6
1 Scope .................................................................................................................................................................... 6
2 Normative references .................................................................................................................................... 8
3 Terms and definitions ................................................................................................................................... 8
4 Abbreviations and symbols ......................................................................................................................... 9
4.1 Abbreviations ................................................................................................................................................... 9
4.2 Symbols ............................................................................................................................................................ 10
5 Selection of an application protocol ...................................................................................................... 10
6 M-Bus protocol .............................................................................................................................................. 10
6.1 General ............................................................................................................................................................. 10
6.2 M-Bus data record ........................................................................................................................................ 11
6.3 Data Information Block (DIB) .................................................................................................................. 11
6.4 Value Information Block (VIB) ................................................................................................................ 15
6.5 Manufacturer specific unstructured data block ............................................................................... 27
7 Application reset and application select ............................................................................................. 28
7.1 Application reset .......................................................................................................................................... 28
7.2 Application select with subcode ............................................................................................................. 28
7.3 Overview about CI-Fields for Application reset and Application select ................................... 30
7.4 Rules for application selection ................................................................................................................ 31
7.5 Rules for block selection............................................................................................................................ 32
7.6 Selected application block in M-Bus Application protocol ........................................................... 32
8 Clock synchronization ................................................................................................................................ 32
9 Report of alarm status (slave to master) ............................................................................................. 33
10 Report of application error ...................................................................................................................... 33
10.1 General ............................................................................................................................................................. 33
10.2 Status field ...................................................................................................................................................... 33
10.3 General application layer errors ............................................................................................................ 33
11 Switching baud rate for M-Bus link layer according to EN 13757-2 .......................................... 34
12 Synchronize action ...................................................................................................................................... 35
13 Manufacturer specific protocols ............................................................................................................. 35
14 Other application protocols ..................................................................................................................... 35
15 Image transfer ............................................................................................................................................... 35
Annex A (normative) Coding of data records .................................................................................................. 36
Annex B (normative) Interpretation of hex-codes Ah–Fh in BCD-data fields...................................... 44
B.1 General description standard reference ............................................................................................. 44
2
EN 13757-3:2018 (E)
B.2 Definition ......................................................................................................................................................... 44

Annex C (normative) VIF coding for special units .......................................................................................... 45
C.1 Non-metric units ........................................................................................................................................... 45
C.2 Plain text units ............................................................................................................................................... 45
C.3 Remote enablement/disablement of valve/breaker....................................................................... 46
Annex D (informative) Alarm protocol .............................................................................................................. 47
D.1 M-Bus according EN 13757-2 ................................................................................................................... 47
D.2 Wireless M-Bus according to EN 13757-4 ............................................................................................ 47
Annex E (informative) Special sequences for M-Bus devices..................................................................... 48
E.1 VIF/VIFE/VIFE = FDh 97h 1Dh (error flag) ......................................................................................... 48
E.2 VIF/VIFE/VIFE = FDh 9Fh 1Dh for passing remote control on a node....................................... 50
E.3 Clock synchronization................................................................................................................................. 51
Annex F (normative) Transmission of profiles ............................................................................................... 53
F.1 The standard load profile .......................................................................................................................... 53
F.2 The M-Bus compact profile ....................................................................................................................... 53
Annex G (normative) Compact M-Bus frame.................................................................................................... 59
G.1 General ............................................................................................................................................................. 59
G.2 CI-fields of the Full and the Compact M-Bus frame........................................................................... 59
G.3 Calculation of the Full-Frame-CRC .......................................................................................................... 61
G.4 Calculation of the Format Signature ...................................................................................................... 61
G.5 Frame examples ............................................................................................................................................ 61
Annex H (normative) Translating M-Bus type record descriptors to OBIS-type record
descriptors ...................................................................................................................................................... 64
H.1 General ............................................................................................................................................................. 64
H.2 Translation of predefined data record types ..................................................................................... 64
H.3 Online addition of an entry for the M-Bus to OBIS conversion table ......................................... 82
Annex I (normative) Image Transfer .................................................................................................................. 83
I.1 Image Transfer Phases ............................................................................................................................... 83
I.2 Commands for Image Transfer ................................................................................................................ 85
I.3 Overview Image Transfer ....................................................................................................................... 101
Bibliography .............................................................................................................................................................. 104
3
EN 13757-3:2018 (E)
European foreword
This document (EN 13757-3:2018) has been prepared by Technical Committee CEN/TC 294
“Communication systems for meters”, the secretariat of which is held by DIN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by October 2018 and conflicting national standards shall
be withdrawn at the latest by October 2018.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document together with EN 13757-7:2018 and CEN/TR 17167:2018 will supersede
EN 13757-3:2013.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
This document falls under Mandate EU M/441 “Standardisation mandate to CEN, CENELEC and ETSI in
the field of measuring instruments for the development of an open architecture for utility meters
involving communication protocols enabling interoperability” by providing the relevant definitions and
methods for meter data transmission on application layer level. The M/441 Mandate is driving
significant development of standards in smart metering.
The following significant technical changes have been incorporated in the new edition of this European
Standard:
— extension of application select;
— introduction of second level table for VIFE = FDh;
— introduction of inverse compact load profile;
— introduction of new VIFE for descriptor;
— extension of VIFE = FCh table;
— extension of definitions for DIF = 0Fh/1Fh;
— transport and security services were moved to EN 13757-7;
— informative annexes from previous version of EN 13757-3 were moved to a new technical report
CEN/TR 17167.
EN 13757 is currently composed with the following parts:
— Communication systems for meters — Part 1: Data exchange;
— Communication systems for meters — Part 2: Wired M-Bus communication;
— Communication systems for meters — Part 3: Application protocols ;
4
EN 13757-3:2018 (E)
— Communication systems for meters and remote reading of meters — Part 4: Wireless meter readout
(Radio meter reading for operation in SRD bands);
— Communication systems for meters — Part 5: Wireless M-Bus relaying;
— Communication systems for meters — Part 6: Local Bus;
— Communication systems for meters — Part 7: Transport and security services ;
— CEN/TR 17167, Communication systems for meters — Accompanying TR to EN 13757-2,-3 and −7,
Examples and supplementary information.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
5
EN 13757-3:2018 (E)
Introduction
This European Standard belongs to the EN 13757 series, which covers communication systems for
meters. EN 13757-1 contains generic descriptions and a communication protocol. EN 13757-2 contains
a physical and a link layer for twisted pair based Meter-Bus (M-Bus). EN 13757-4 describes wireless
communication (often called wireless M-Bus or wM-Bus). EN 13757-5 describes the wireless network
used for repeating, relaying and routing for the different modes of EN 13757-4. EN 13757-6 describes a
twisted pair local bus for short distance (Lo-Bus). EN 13757-2 describes transport mechanism and
security methods for data. The Technical Report CEN/TR 17167 contains informative annexes for
EN 13757-2, EN 13757-3:2018 and EN 13757-7.
These upper M-Bus protocol layers can be used with various Physical Layers and with Data Link Layers
and Network Layers, which support the transmission of variable length binary transparent messages.
Frequently, the Physical and Link Layers of EN 13757-2 (twisted pair) and EN 13757-4 (wireless) as
well as EN 13757-5 (wireless with routing function) or the alternatives described in EN 13757-1 are
used. These upper M-Bus protocol layers have been optimized for minimum battery consumption of
meters, especially for the case of wireless communication, to ensure long battery lifetimes of the
meters. Secondly, it is optimized for minimum message length to minimize the wireless channel
occupancy and hence the collision rate. Thirdly, it is optimized for minimum requirements towards the
meter processor regarding requirements of RAM size, code length and computational power.
An overview of communication systems for meters is given in EN 13757-1, which also contains further
definitions.
This standard concentrates on the meter communication. The meter communicates with one (or
occasionally several) fixed or mobile communication partners which again might be part of a private or
public network. These further communication systems might use the same or other application layer
protocols, security, privacy, authentication, and management methods.
To facilitate common communication systems for CEN-meters (e.g. gas, water, thermal energy and heat
cost allocators) and for electricity meters, in this standard occasionally electricity meters are
mentioned. All these references are for information only and are not standard requirements. The
definition of communication standards for electricity meters (possibly by a reference to CEN standards)
remains solely in the responsibility of CENELEC.
NOTE 1 CEN/TR 17167:2018, Annex C specifies how parts of this standard and of EN 13757–2 and
EN 13757–4 can be used to implement smart meter functionalities. Similar functionalities could also be
implemented using other physical and link layers.
NOTE 2 For information on installation procedures and their integration in meter management
systems, see CEN/TR 17167:2018, Annex D.
The European Committee for Standardization (CEN) draws attention to the fact that it is claimed that
compliance with this document may involve the use of a patent concerning Image Transfer given in
Annex I.
CEN takes no position concerning the evidence, validity and scope of this patent right.
The holder of this patent right has ensured CEN that he/she is willing to negotiate licences either free of
charge or under reasonable and non-discriminatory terms and conditions with applicants throughout
the world. In this respect, the statement of the holder of this patent right is registered with CEN.
Information may be obtained from:
ITRON, INC
Shig Furukawa, Associate General Counsel IP, Legal Department
2111 N. Molter Road
6
EN 13757-3:2018 (E)
Liberty Lake, Washington 99019

USA
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights other than those identified above. CEN shall not be held responsible for identifying any or
all such patent rights.
CEN and CENELEC maintain online lists of patents relevant to their standards. Users are encouraged to
consult the lists for the most up to date information concerning patents
(ftp://ftp.cencenelec.eu/EN/IPR/Patents/IPRdeclaration.pdf).
7
EN 13757-3:2018 (E)
1 Scope
This European Standard specifies application protocols for communication systems for meters.
This European Standard specifies application protocols, especially the M-Bus application protocol.
This European Standard is intended to be used with the lower layer specifications determined in
EN 13757-2, EN 13757-4, EN 13757-5, EN 13757-6 and EN 13757-7.
2 Normative references
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.
EN 13757-2, Communication systems for meters - Part 2: Wired M-Bus communication
EN 13757-4, Communication systems for meters and remote reading of meters - Part 4: Wireless meter
readout (Radio meter reading for operation in SRD bands)
EN 13757-5, Communication systems for meters - Part 5: Wireless M-Bus relaying
EN 13757-6, Communication systems for meters - Part 6: Local Bus
EN 13757-7, Communication systems for meters — Part 7: Transport and security services
ISO/IEC 8859-1, Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin
alphabet No. 1
ISO/IEC/IEEE 60559:2011, Information technology — Microprocessor Systems — Floating-Point

arithmetic
3 Terms and definitions

For the purposes of this document, the following terms and definitions apply.
3.1
byte
octet of bits
3.2
datagram
unit of data transferred from source to destination
Note 1 to entry: In previous versions of EN 13757–3 datagram was called telegram.
3.3
fragment
datagram of a fragmented message
3.4
Final DIFE
additional last DIFE with the value 00h that marks a storage number as a register number
8
EN 13757-3:2018 (E)
3.5
Hex-ASCII
base-16 numbers encoded as ASCII characters (‘0’–‘9’, ‘A’–‘F’)
[SOURCE: ANSI X9 TR-31:2010]
3.6
message
functional set of data transferred from source to destination
Note 1 to entry: A message may consist of one or more datagrams.
3.7
Register number
number of a predefined historical value register (like consumption value) corresponding to an OBIS
value group F value
3.8
sublayer
subdivision of a layer
[SOURCE: ISO/IEC 7498-1]
4 Abbreviations and symbols

4.1 Abbreviations
ACK Acknowledge
AES Advanced Encryption Standard
AFL Authentication and Fragmentation Sublayer
APL Application Layer
ASCII American Standard Code for Information Interchange
BCD Binary Coded Decimal numbers
CI Control Information field
CMD Command
DIB Data Information Block
DIF Data Information Field
DIFE Data Information Field Extensions
DLMS Device Language Message Specification
DRH Data Record Header
E Extension bit
LSB Least Significant Byte
LSBit Least Significant Bit
MDH Manufacturer Data Header
MSB Most Significant Byte
9
EN 13757-3:2018 (E)
MSBit Most Significant Bit

OBIS Object Identification System (EN 62056–6-1)
REQ-UD Request User Data (class 1 or 2), (EN 13757–4)
RSP-UD Respond User Data (EN 13757–4)
RSSI Received Signal Strength Indicator
SND-NKE Send Link Reset (EN 13757–4)
SND-UD Send User Data (EN 13757–4)
SND-UD2 Send User Data 2 (EN 13757–4)
TPL Transport Layer
VIB Value Information Block
VIF Value Information Field
VIFE Value Information Field Extensions
4.2 Symbols
Hexadecimal numbers are designated by a following “h”.

Binary numbers are designated by a following “b”.
Decimal numbers have no suffix.
5 Selection of an application protocol

This European Standard supports several application protocols. A specific protocol shall be chosen
accordingly to the selected CI-Field described in EN 13757-7:2018, 4.2. Beside the M-Bus protocol there
are specific protocols described in the following clauses. Further application protocols applying
DLMS/COSEM or M-Bus based usage of OBIS-type value descriptors are referenced in
EN 13757-7:2018, Table 2. Annex H defines translation from M-Bus type record descriptors to OBIS-
type record descriptors.
The support for the different commands or protocols declared by the CI-field is optional in the meter.
6 M-Bus protocol
6.1 General
The single datagram has a maximum length of 255 bytes. The data, together with information regarding
coding, length and the type of data, is transmitted in data records in arbitrary sequence. According to
EN 13757-2, the maximum space for data are 252 bytes. The effective usable space depends on the
layers with variable length below the application layer and the applied header type and the encryption
method. This restriction is required to enable gateways to other link- and application layers.
The M-Bus Application Layer data may consist of two segments of data. The first segment holds M-Bus
data records (see 6.2). The second, optional segment, holds manufacturer specific data. (see Table 1).
Table 1 — Structure of a M-Bus APL with manufacturer specific data
APL Variable data blocks MDH Manufacturer specific data

(Records) (optional) (optional)
Variable number 1 byte Variable number
10
EN 13757-3:2018 (E)
A Manufacturer Data Header (MDH) shall be inserted before the manufacturer specific data. The MDH is
one of the characters 0Fh or 1Fh. The MDH shall be omitted if there is no manufacturer specific data
(see 6.5).
Unencrypted data following encrypted data shall start at a data record boundary, i.e. the first byte of
unencrypted data shall be interpreted as a DIF.
Special data structures are defined in Annex F and in Annex G.
If nothing other declared then multi byte fields shall be transmitted with least significant byte first
(little endian).
6.2 M-Bus data record
The structure of an M-Bus data record is shown in Table 2. The transmission order of the element is
from left to right.
Table 2 — Data record structure
DIF DIFE VIF VIFE Data

1 byte 0 to 10 (1 byte each) 1 byte 0 to 10 (1 byte each) 0 to N bytes
Data Information Block (DIB) Value Information Block (VIB)
Data Record Header (DRH)
Each data record consists of a Data Record Header (DRH) and the value (data). The DRH consists of a
Data Information Block (DIB) and a Value Information Block (VIB). The DIB specifies the length, type
and coding of the data. The VIB specifies the unit for the data and the multiplier to use.
NOTE An application message can contain either just a single data record but also an arbitrary number of
such data records in arbitrary order, each describing and containing a data element. For examples of such multi
record messages see FprCEN/TR 17167:2017, Annex A, or for further information on M-Bus see
FprCEN/TR 17167:2017, Annex C.
6.3 Data Information Block (DIB)

6.3.1 General
The DIB contains at least one byte of Data Information Field (DIF), and can be extended by a maximum
of 10 Data Information Field Extensions (DIFE).
6.3.2 Data Information Field (DIF)
The coding of the DIF is shown in Table 3.

Table 3 — Data Information Field (DIF)
Bit 7 6 5 4 3 2 1 0
Extension bit LSBit of storage Data field:
Function field
(E) number Length and coding of data
6.3.3 Data field
The data field shows how length and coding of data shall be interpreted. Table 4 shows the allowed
codes for the data field.
11
EN 13757-3:2018 (E)
Table 4 — Coding of the data field
Code LengthSize in bit Data type

0000b 0 No data
0001b 8 8 bit integer/binary

0101b 32 32 bit real

1000b 0 Selection for readout
1001b 8 2 digit BCD
1010b 16 4 digit BCD
1101b N Variable length
1111b — Special functions

For a detailed description of data types, refer to Annex A “Coding of data records” (e.g. BCD = type A,
Real = type H). The coding as integer/binary by default implies coding type B (signed integer). The
coding may however be overridden by the settings in VIF/VIFE of the record (e.g. date/time).
Variable length:
A Code of 1101b implies data with variable length. The length is coded in the first byte of the data, after
the DRH and is named LVAR. (e.g. LVAR = 02h shows that two bytes of data follows.)
If LVAR is used as the variable length of a wireless M-Bus data container (see FprCEN/TR 17167:2017,
Annex F) it counts the number of bytes inside the container (Table 5).
12
EN 13757-3:2018 (E)
Table 5 — LVAR interpretation
Range Data Type Calculation

8-bit text string according to
00h–BFha LVAR (0 to 191) characters
ISO/IEC 8859-1
C0h–C9h Positive BCD number (LVAR–C0h)*2 digits, 0 to 18 digits
D0h–D9h Negative BCD number (LVAR–D0h)*2 digits, 0 to 18 digits
E0h–EFh Binary number (LVAR–E0h) bytes, 0 to 15 bytes
F0h–F4h Binary number 4*(LVAR–ECh) bytes, 16, 20, 24, 28, 32 bytes
F5h Binary number 48 bytes
F6h Binary number 64 bytes
Others LVAR values Reserved

a If a wireless M-Bus data container is used it counts the number of bytes inside the container (see also
Table 12, Footnote f).
All multi byte fields following LVAR (according Table 5) shall be transmitted with Least Significant Byte
first.
A Code of 1111b implies coding for special functions as specified in Table 6.
Table 6 — DIF-coding for special functions
DIF Function
0Fh Start of manufacturer specific data structures to end of user data (see 6.5)
1Fh Same meaning as DIF = 0Fh + more records follow in next datagram (see 6.5)
2Fh Idle filler (not to be interpreted), following byte = DIF of next record
3Fh to 6Fh Reserved

7Fh Global readout request (all storage numbers, units, tariffs, function fields)
6.3.4 Function field
The Function Field gives the type of value as specified in Table 7.

Table 7 — Function field
Code Description
00b Instantaneous value
01b Maximum value
10b Minimum value
11b Value during error state
6.3.5 Storage number
Bit 6 of the DIF serves as the LSBit of the storage number of the data concerned, and the slave can in this
way indicate and transmit various stored metering values or historical values of metering data. This bit
13
EN 13757-3:2018 (E)
is the least significant bit of the storage number and allows therefore the storage numbers 0 and 1 to be
coded. If storage numbers higher than “1” are needed, following (optional) DIFE´s contain the higher
bits. The storage number 0 signals a current value.
Each storage number is associated with a dedicated time point. Each data record with the same storage
number refers the value to this (common) time point given by this storage number. A time/date record
for each storage number can be included somewhere in the message to signal this time point associated
with this storage number. This date or date/time is coded with a data record with a VIF = E110110nb.
Normally (but not necessarily) higher storage numbers indicate an older time point. A sequential block
of storage numbers can be associated with a sequence of equidistantly spaced time points (profile).
Such a block can be described by its starting time, the time spacing, the first storage number (of such a
block) and the length of the block. For an example see Annex F.
Some meters require the assignment of historical values (like consumption values) to register numbers
that are represented by OBIS value group F values. In this case the storage number is used to indicate
the register number while the DIB shall be extended by a Final DIFE with the value 00h in order to mark
the storage number as a register number. Register numbers up to 125 can be coded in this way (see
Annex H.2).
6.3.6 Extension bit (E)
Bit 7, the Extension bit of the DIF, indicates when set, that additional data description follows in one or
more Data Field Extension, DIFE, bytes.
6.3.7 Data Information Field Extension (DIFE)
There may be up to 10 successive DIFE bytes. The coding of the DIFE is shown in Table 8. Bit 7 (E) of a
DIFE byte shows whether a further DIFE byte follows. Bit 6 is a part of the numbering of subunits. Bit 5
and 4 is a part of the numbering of the Tariff and bits 3 through 0 are a part of the Storage number. The
full Storage number/Tariff/Subunit number is made up of a concatenation of the information from all of
the DIFE’s for a parameter.
Table 8 — Coding of the Data Information Field Extension (DIFE)
Bit 7 6 5 4 3 2 1 0
Extension Bit (Device)
Value Tariff Storage number
(E) Subunit
With the maximum of 10 DIFEs, which are provided, there are 41 bits for the storage number, 20 bits
for the tariff and 10 bits for the subunit of the meter. There is no application conceivable in which this
immense number of bits could all be used.
The use of the Final DIFE is explained in 6.3.5.
6.3.8 Tariff information
For each (unique) value type designation given by the following VIB at each unique time point (given by
the storage number) of each unique function (given by the function field), there might exist still various
different data, measured or accumulated under different conditions. Such conditions could be time of
day, various value ranges of the variable (i.e. separate storage of positive accumulated values and
negative accumulated values) itself or of other signals or variables or various averaging durations. Such
variables, which could not be distinguished otherwise, are made different by assigning them different
values of the tariff variable in their data information block.
NOTE This includes, but is not necessarily restricted to various tariffs in a monetary sense. It is at the
distinction of the manufacturer to describe for each tariff (except 0) what is different for each tariff number. Again,
as with the storage numbers, all variables with the same tariff information share the same tariff associating
condition.
14
EN 13757-3:2018 (E)
6.3.9 Subunit information
A device (meter) may consist of several functionally/logically independent subunits. Such a device may
either use multiple different primary/secondary addresses or use the subunit information in the DIFE’s
to address independent subunits. The use of multiple addresses is recommended for collections of
physically independent devices. Devices, that share common information, but have different logical
entities, are recommended to use a single address and to differentiate between the different entities
using the subunit information.
6.4 Value Information Block (VIB)
6.4.1 General
A DIB will, with the exception of the special values given in Table 6, be followed by a VIB. The VIB
consists of a Value Information Field (VIF) byte and zero or more (up to 10) Value Information Field
Extension (VIFE) bytes. VIF/VIFE use the same extension mechanism as specified for DIF and DIFE
(see 6.3.6 and 6.3.7). The basic coding of the VIF is shown in Table 9.
Table 9 — Coding of the Value Information Field (VIF)
Bit 7 6 5 4 3 2 1 0
Extension Bit
Value Unit and multiplier (value)
(E)
There are five types of coding depending on the VIF:
a) Primary VIF: E000 0000b to E111 1010b
The unit and multiplier are taken from Table 10.
b) Plain-text VIF: E111 1100b
In case of VIF = 7Ch/FCh, the true VIF is represented by the following ASCII string with the length
given in the first byte.
Clause C.2 shows an example for a plain text VIF.
c) Linear VIF-extension: FDh and FBh
In case of VIF = FDh and VIF = FBh (see Table 11) the true VIF is given by the next byte (i.e. the first
VIFE) and the coding is taken from Table 12 and Table 14, respectively. This extends the available
VIFs by another 256 codes.
d) Any VIF: 7Eh/FEh
This VIF-Code can be used in direction master to slave for readout selection of all VIFs. See special
function in 6.3.3.
e) Manufacturer specific: 7Fh/FFh
In this case, the remainder of this data record including VIFEs has manufacturer specific coding.
15
EN 13757-3:2018 (E)
6.4.2 Primary VIFs (main table)
The first section of the main table contains integral values, the second typically averaged values, the
third typically instantaneous values and the fourth block contains parameters (E: extension bit).
Table 10 — Primary VIF-codes
Coding Description Range coding Range

E000 0nnn Energy 10(nnn–3) Wh 0,001 Wh to 10 000 Wh
E000 1nnn Energy 10(nnn) J 0,001 kJ to 10 000 kJ
E001 0nnn Volumea 10(nnn–6) m3 0,001 l to 10 000 l

E001 1nnn Mass 10(nnn–3) kg 0,001 kg to 10 000 kg
nn = 00b seconds
nn = 01b minutes
E010 00nn On time Duration of meter power up
nn = 10b hours
nn = 11b days
E010 01nn Operating time coded like OnTime Duration of meter accumulation
E010 1nnn Power 10(nnn–3) W 0,001 W to 10 000 W
E011 0nnn Power 10(nnn) J/h 0,001 kJ/h to 10 000 kJ/h
E011 1nnn Volume flow 10(nnn–6) m3/h 0,001 l/h to 10 000 l/h
E100 0nnn Volume flow ext. 10(nnn–7) m3/min 0,000 1l/min to 1 000 l/min
E100 1nnn Volume flow ext. 10(nnn–9) m3/s 0,001 ml/s to 10 000ml/s
E101 0nnn Mass flow 10(nnn–3) kg/h 0,001 kg/h to 10 000 kg/h
E101 10nn Flow temperature 10(nn–3) °C 0,001 °C to 1 °C
E101 11nn Return temperature 10(nn–3) °C 0,001 °C to 1 °C
E110 00nn Temperature difference 10(nn–3) K 1 mK to 1 000 mK

E110 01nn External temperature 10(nn–3) °C 0,001 °C to 1 °C
E110 10nn Pressure 10(nn–3) bar 1 mbar to 1 000 mbar
Date (actual or associated

E110 1100 with a storage YYYY-MM-DDc Data field = 0010b, type G
number/function)
Date and time (actual or
E110 1101b associated with a storage YYYY-MM-DD hh-mmc Data field = 0100b, type F
number/function)
Time (actual or associated
E110 1101b with a storage hh:mm:ssc Data field = 0011b, type J
number/function)
Date and time (actual or
E110 1101b associated with a storage YYYY-MM-DD hh:mm:ssc Data field = 0110b, type I
number/function)
16
EN 13757-3:2018 (E)
Coding Description Range coding Range

YYYY-MM-DD
Date and time or duration
hh:mm:ss,pppppc
E110 1101b (actual or associated with a
or
Data field = 1101b, type M
storage number/function)
ssssssssss,pppppc
E110 1110 Units for HCA. Dimensionless
Reserved for a future third
E110 1111
table of VIF-extensions
E111 00nn Averaging duration nn coded like on time
E111 01nn Actuality duration nn coded like on time
E111 1000 Fabrication no See CEN/TR 17167:2018, Annex A.8.2
E111 1001 (Enhanced) identification
For EN 13757–2: data field 0001b
(1 byte link layer address,, data type C)
E111 1010 Address For EN 13757–4: data field 0110b
(6 byte header-ID) or 0111b
(full 8 byte header)
a For gas it is the temperature converted volume, unless a VIFE signals volume at metering-conditions or
volume at base conditions.
b Meaning depends on data field. Other data fields shall be handled as invalid.
c YYYY – year
MM – month
DD – day
hh – hour
mm – minute
ss – second
pp – part of a second
6.4.3 VIF-codes for special purposes
Table 11 — Special VIF-codes
Coding Description Purpose
1111 1011 (FBh) True VIF is given in the first VIFE and is coded using
First extension of VIF-codes
(Table 14) (128 new VIF-Codes)
VIF in following string
E111 1100 (7C/FC)
(length in first byte) Allows user definable VIF´s (in plain ASCII-String), see C.2a
1111 1101 (FDh) Second extension of VIF- True VIF is given in the first VIFE and is coded using
codes (Table 12) (128 new VIF-Codes)
1110 1111 (EFh) Reserved for third

reserved for a future table especially for electricity meters
extension table of VIF-codes
E111 1110 (7E/FE) Any VIF Used for readout selection of all VIF´s (see 6.3.3, 6.4)
E111 1111 (7F/FF) Manufacturer specific VIFE´s and data of this block are manufacturer specific
a Coding the VIF in an ASCII-String is also allowed in combination with data as ASCII-String (using data field in
DIF = 1101b).
17
EN 13757-3:2018 (E)
6.4.4 VIFE-code extension tables
6.4.4.1 Main VIFE-code extension table (following VIF = FDh for primary VIF)
Table 12 — Main VIFE-code extension table
Coding Description Group
E000 00nn Credit of 10nn–3 of the nominal local legal currency units Currency units
E000 01nn Debit of 10nn–3 of the nominal local legal currency units
Unique message identification (previously named “Access
E000 1000
number (transmission count)”)g,k
E000 1001 Device typek

E000 1010 Manufacturerk
E000 1011 Parameter set identificationk Enhanced identification
E000 1100 Model/Versionk

E000 1101 Hardware version numberk
E000 1110 Metrology (firmware) version numberk
E000 1111 Other software version numberk
E001 0000 Customer locationk
E001 0001 Customerk
E001 0010 Access code userk
E001 0011 Access code operatork Improved selection
E001 0100 Access code system operatork and other user requirements
E001 0101 Access code developerk
E001 0110 Passwordk
E001 0111 Error flags (binary) (device type specific)j (see also E.1)
E001 1000 Error maskk
E001 1001 Security keyi,l,k

E001 1010 Digital output (binary)j
E001 1011 Digital input (binary)j
E001 1100 Baud rate [baud]k
E001 1101 Response delay time [bit-times]k
E001 1110 Retry
E001 1111 Remote control (device specific, e.g. gas valve)j (see C.3)
E010 0000 First storage number for cyclic storagek
18
EN 13757-3:2018 (E)
E010 0001 Last storage number for cyclic storagek
E010 0010 Size of storage block (see F.1)k
E010 0011 Descriptor for tariff and subunitk (see CEN/TR 17167:2018,
Annex F)
E010 01nn Storage interval [sec(s) to day(s)]a management
E010 1000 Storage interval month(s) (see F.1)

E010 1001 Storage interval year(s)
E010 1010 Operator specific datah
E010 1011 Time point second (0 to 59)k
E010 11nn Duration since last readout [sec(s) to day(s)]a,k

E011 0000 Start (date/time) of tariff
E011 00nn Duration of tariff (nn = 01 to 11: min to days)k
E011 01nn Period of tariff [sec(s) to day(s)]a,k
E011 1000 Period of tariff months(s)k Enhanced tariff
E011 1001 Period of tariff year(s)k management
E011 1010 Dimensionless/no VIF
E011 1011 Data container for wireless M-Bus protocolf See CEN/TR 17167:2018
E011 11nn Period of nominal data transmissions [sec(s) to day(s)]a,k Installation and start up
(e.g. for RF-transmissions)
E100 nnnn 10nnnn–9 volts Electrical units
E101 nnnn 10nnnn–12 A

E110 0000 Reset counter
E110 0001 Cumulation counter
E110 0010 Control signal
E110 0011 Day of weeke,k
E110 0100 Week numberk

E110 0101 Time point of day change
E110 0110 State of parameter activationk
E110 0111 Special supplier informationk
E110 10pp Duration since last cumulation [hour(s) to years(s)]c,k
E110 11pp Operating time battery [hour(s) to years(s)]c
E111 0000 Date and time of battery changeb
E111 0001 RF level units: dBmd
19
EN 13757-3:2018 (E)

E111 0010 Daylight savings (beginning, ending, deviation) data type K
E111 0011 Listening window management data type L
E111 0100 Remaining battery life time (days)k

E111 0101 Number times the meter was stoppedk
E111 0110 Data container for manufacture specific protocolf See CEN/TR 17167:2018
E111 0111 –
Reserved
E111 1100
E111 1101 2nd level VIFE code extension table (Table 13)
E111 1110 –
Reserved
E111 1111
a nn = 00b second(s)
01b minute(s)
10b hour(s)
11b day(s)
b The information about usage of data type F (date and time) or data type G (date), I (date and time), J (time)
or M (date and time or duration) can be derived from the data field (see Table 4).
c pp = 00 hour(s)
b
01b day(s)
10b month(s)
11b year(s)
d Typically this VIFE is used in context with a function field of 00b of the leading DIF. If this VIFE used together
with the function field 10b it declares a preset quality limit of the reception level which was exceeded (e.g.
RF-Level > −80dBm). If this VIFE is used together with the function field 11b it declares the typical noise
level detected by this radio device.
e Data type A (1 = Monday; 7 = Sunday, 0 = all the days).
f Using this VIFE as a data container for wireless M-Bus or manufacturer specific protocol in combination with
the variable length DIF = 0Dh (LVAR from 00h to BFh, see CEN/TR 17167:2018, Annex F).
g The unique message identification is not resettable.
h This data point is reserved for the transport of any special information for the operator. It shall not be used
by the vendor!
i Typically the security key needs to be set with data field LVAR, due to its large size.
j Data type D according to Annex A.
k Binary data (see Table 4) shall be interpreted as data type A (unsigned BCD) or data type C (unsigned
integer) according to Annex A.
l This VIFE is deprecated! The Security Information Transfer Protocol according to EN 13757–7, Annex A shall
be used instead.
20
EN 13757-3:2018 (E)
6.4.4.2 2nd level VIFE-code extension table (following VIF = FDh and VIFE = FDh)
Table 13 — 2nd level VIFE code extension table
E000 0000 Currently selected applicationa

E000 0001 Reserved
E000 001pb Remaining battery lifetime (month or years)c

E000 0100 –
Reserved
E111 1111
a The coding of the data content shall be according to 7.2.
b P = 0b month(s)
1b year(s)
c Binary data (see Table 4) shall be interpreted as data type A (unsigned BCD) or data type C (unsigned
6.4.5 Alternate VIFE-code extension table (following VIF = FBh for primary VIF)
Table 14 — Alternate extended VIF-code table
Coding Description Range Coding Range
E000 000n Energy 10(n–1) MWh 0,1 MWh to 1 MWh
E000 001n Reactive energy 10(n) kvarh 1 to 10 kvarh
E000 010n Apparent energy 10(n) kVAh 1 to 10 kVAh

E000 011n Reserved
E000 100n Energy 10(n–1) GJ 0,1 GJ to 1 GJ
E000 101n Reserved
E000 11nn Energy 10(nn–1) MCal 0,1 MCal to 100 MCal
E001 000n Volume 10(n+2) m3

E001 001n Reserved
E001 01nn Reactive power 10(nn–3) kVAR 0,001 kVAR to 1 kVAR
E001 100n Massd 10(n+2) t 100 t to 1 000 t
E001 101n Relative humidityd 10(n–1) % 0,1 % to 100 %
E001 1100 –
Reserved
E001 1111
E010 0000 Volume feet3
E010 0001 Volume 0,1 feet3

E010 0010 Reserved a
21
EN 13757-3:2018 (E)
Coding Description Range Coding Range

E010 0111 Reserved
E010 100n Power 10(n–1) MW 0,1 MW to 1 MW

E010 1010 Phase U-U (volt. to volt.) 0,1°
E010 1011 Phase U-I (volt. to current) 0,1°
E010 11nn Frequency 10(nn–3) Hz 0,001 Hz to 1 Hz
E011 000n Power 10(n–1) GJ/h 0,1 GJ/h to 1 GJ/h

E011 001n Reserved
E011 01nn Apparent power 10(nn–3) kVA 0,001 kVA to 1 kVA
E011 1000 –
Reserved
E101 0111
E101 1000 –
Reserved a
E110 0111
E110 1nnn Reserved
E111 00nn Reserved a
E111 01nn Cold/warm temperature limit 10(nn–3) °C 0,001 °C to 1 °C
E111 1nnn Cum. max. of active power 10(nnn–3) W 0,001 W to 10 000 W

E110 1000 Resulting rating factor, Kd 2(–12) (Units for HCA)/hb
E110 1001 Thermal output rating factor, Kqd Watt
Thermal coupling rating factor overall,

E110 1010 2(–12) 0 to 4c
Kcd
Thermal coupling rating factor room
E110 1011 2(–12) 0 to 4c
side, Kcrd
Thermal coupling rating factor heater
E110 1100 2(–12) 0 to 4c
side, Kchd
E110 1101 Low temperature rating factor, Ktd 2(–12) 0 to 4c
E110 1110 Display output scaling factor, KDd 2(–12) (Units for HCA)/KWhb 0 to 4 kWh(–1)c
NOTE Refer also to Annex C for non-metric units.
a These codes were used until 2004, now they are reserved for future use.
b “Units for HCA” is not physically unit, but a dimensionless quantity.
c Limited to the physical reasonable range.
d Binary data (see Table 4) shall be interpreted as data type A (unsigned BCD) or data type C (unsigned
22
EN 13757-3:2018 (E)
6.4.6 Combinable (orthogonal) VIFE-Code extension table
The code from Table 15 follows immediately the VIF or the VIFE (in case of code extension) and
modifies its meaning.
Table 15 — Combinable (orthogonal) VIFE-table
VIFE-Code Description
Reserved for object actions (master to slave): see 6.4.7 or for error codes (slave to master):
E000 xxxx
see 6.4.8
E001 0000 –
Reserved
E001 0001
E001 0010 Average value
E001 0011 Inverse compact profilec
E001 0100 Relative deviationa
E001 0101 –
Record error codes (slave to master); (see 6.4.8)
E001 1100
E001 1101 Standard conform data contentb
E001 1110 Compact profile with register numbersc
E001 1111 Compact profilec

E010 0000 Per second
E010 0001 Per minute
E010 0010 Per hour
E010 0011 Per day
E010 0100 Per week
E010 0101 Per month
E010 0110 Per year
E010 0111 Per revolution/measurement
E010 100p Increment per input pulse on input channel number p
E010 101p Increment per output pulse on output channel number p
E010 1100 Per litre
E010 1101 Per m3
E010 1110 Per kg
E010 1111 Per K (Kelvin)
E011 0000 Per kWh
E011 0001 Per GJ
E011 0010 Per kW
E011 0011 Per (K ⋅ l) (Kelvin ⋅ litre)
E011 0100 Per V (volt)
E011 0101 Per A (ampere)
23
EN 13757-3:2018 (E)
E011 0110 Multiplied by s
E011 0111 Multiplied by s/V
E011 1000 Multiplied by s/A
E011 1001 Start date(/time) ofd,e
E011 1010 VIF contains uncorrected unit or value at metering conditions instead of converted unit
E011 1011 Accumulation only if positive contributions (forward flow contribution)
E011 1100 Accumulation of abs value only if negative contributions (backward flow)
E011 1101 Used for alternate non-metric unit system (according to Annex C)
E011 1110 Value at base conditionsf
E011 1111 OBIS-declaration (data type C follows in case of binary coding)
E100 u000 U = 1: upper, u = 0: lower limit value
E100 u001 Number of exceeds of lower u = 0)/upper (U = 1) limit
Date (/time) of: b = 0: begin, b = 1: end of, f = 0: first, f = 1: last, u = 0: lower, u = 1: upper limit
E100 uf1b
exceedd,e
E101 ufnn Duration of limit exceed (u, f: as above, nn = durationh)
E110 0fnn Duration of d (f: as above, nn = durationh)

E110 1u00 Value during lower (u = 0), upper (u = 1) limit exceed
E110 1001 Leakage values
E110 1101 Overflow values
E110 1f1b Date (/time) of d,e (f, b: as above)
E111 0nnn Multiplicative correction factor for value (not unit): 10nnn–6
E111 10nn Additive correction constant: 10nn–3 ⋅ unit of VIF (offset)g
E111 1100 Extension of combinable (orthogonal) VIFE-Code (refer to Table 16)
E111 1101 Multiplicative correction factor for value (not unit): 103
E111 1110 Future value
E111 1111 Next VIFEs and data of this block are manufacturer specific
24
EN 13757-3:2018 (E)
a Use the multiplier VIFE E111 0nnn to generate % or ppm values, e.g. multiplier of 10–2.
b This VIFE shall be attached to a special VIFE if the content of the related data point has not a manufacture
specific use but conforms exclusively to the definitions of Annex E.
c This VIFE declares a series of data points as compact profile. According to Annex F.
d “Date(/time) of” or “Duration of” relates to the information which the whole Data Record Header contains.
e The information about usage of data type F (date and time) or data type G (date), I (date and time), J (time)
or M (date and time or duration) can be derived from the data field (see Table 4).
f Used either to indicate that the consumption value is referenced, respectively converted to base conditions
(e.g. gas volume at base temperature and base pressure) or for the base condition itself (e.g. reference/base
temperature or reference/base pressure).
g The additive correction constant is given as a separate data record.
h nn = 00b second(s)
01b minute(s)
10b hour(s)
11b day(s)
The codes of Table 16 follow immediately after the VIFE = FCh of Table 15.
Table 16 — Extension of combinable VIFE-table (following VIFE = FCh of combinable
(orthogonal) VIFE-table)
E000 0000 Reserved
E000 0001 At phase L1
E000 0100 At neutral (N)
E000 0101 Between phase L1 and L2
E000 1000 At quadrant Q1
E000 1100 Delta between import and export (abs(Q1+Q4) – abs(Q2+Q3))
E000 1101 –
Reserved
E000 1111
E001 0000 Accumulation of absolute value for both positive and negative contribution (absolute count)a
E001 0001 Data presented with type C according Annex A
E001 0010 Data presented with type D according Annex A
E001 0011 Reserved
25
EN 13757-3:2018 (E)
E001 0100 Direction: from communication partner to meterb
E001 0101 Direction: from meter to communication partnerb

E001 0110 –
Reserved
E111 1111
a This extension is used in special case if the meter index counts up independent of the polarity of the meter
(for both directions).
b Defines the applicable direction of specific parameters like RSSI-level.
6.4.7 Generalized object layer
The fundamental idea of an object is the encapsulation of data and methods or actions for the data. In
case of writing data to a slave the master software can pack data and information about the action,
which the slave shall do with this data, in one data record. This variable data record with actions is now
called an object. Following any VIF including a VIF = FDh or VIF = FBh with the true value information in
the first VIFE, another (usually the last) VIFE can be added which contains a code signalling object
actions according to Table 17.
Table 17 — Action codes for the generalized object layer (master to slave)
VIFE-Code binary Action Explanation

E000 0000 Write (replace) Replace old with new data
E000 0001 Add value Add data to old data
E000 0010 Subtract value Subtract data from old data
E000 0011 OR (set bits) Data OR old data
E000 0100 AND Data AND old data
E000 0101 XOR (toggle bits) Data XOR old data
E000 0110 AND NOT (clear bits) NOT data AND old data
E000 0111 Clear Set data to zero
E000 1000 Add entry Create a new data record
E000 1001 Delete entry Delete an existing data record
E000 1010 Delayed action A CI = 5Ch will follow and execute the desired action
E000 1011 Freeze data Freeze data to storage no.
E000 1100 Add to readout-list Add data record to RSP-UD
E000 1101 Delete from readout-list Delete data record from RSP-UD
E000 111x Reserved
NOTE The object action “write/replace” (VIFE = E000 0000) is the default and is assumed if there is no VIFE
with an object action for this record.
6.4.8 Record errors
To report errors belonging just to a special record and not to the full application, the slave can add to
the defective record a VIFE containing one of the values of Table 18 to code the type of application
error, which has occurred for this record.
26
EN 13757-3:2018 (E)
Table 18 — Codes for record errors (E = Extension bit)
VIFE-Code Type of record error Error group

E000 0000 None
E000 0001 Too many DIFEs
E000 0010 Storage number not implemented
E000 0011 Unit number not implemented
E000 0100 Tariff number not implemented
DIF errors
E000 0101 Function not implemented
E000 0110 Data class not implemented
E000 0111 Data size not implemented
E000 1000 to
Reserved
E000 1001
E000 1010 Reserved
E000 1011 Too many VIFEs
E000 1100 Illegal VIF-Group
E000 1101 Illegal VIF-Exponent
VIF errors
E000 1110 VIF/DIF mismatch
E000 1111 Unimplemented action
E001 0000 to
Not used for record errors
E001 0100
E001 0101 No data available (undefined value)
E001 0110 Data overflow
E001 0111 Data underflow
Data errors
E001 1000 Data error
E001 1001 to
Reserved
E001 1011
E001 1100 Premature end of record Other errors
In case of record errors the data may be invalid. The slave has some options to transmit the data:
— data field = 0000b: no data;
— data field = 0000b: no data and idle filler (DIF = 02Fh): fill record up to the normal length;
— other data field: dummy data of correct length;
— other data field: unsafe or estimated data.
6.5 Manufacturer specific unstructured data block
The MDH (see 6.1) consists of the character 0Fh or 1Fh (DIF = 0Fh or 1Fh) and indicates that all
following data are manufacturer specific. When the total number of bytes given from the link/network
layers and the number of record-structured bytes and the length of the fixed header is known, the
number of remaining unstructured manufacturer specific bytes can be calculated.
27
EN 13757-3:2018 (E)
NOTE 1 Structured manufacturer specific data (i.e. those with a known data structure including variable length
binary or ASCII but with a manufacturer specific meaning or unit) can be described using normal data records
with a value information field of VIF = 7Fh or FFh (see 6.4.1).
The DIF = 1Fh signals additionally a request from the slave to the master to readout the slave once
again. The master shall readout the slave until there is no DIF = 1Fh inside the responded datagram
(multi datagram message readout) or use an application reset. The variable data block of the next
datagram starts with a normal DIF. If a multi datagram message contains M-Bus records only and no
manufacturer specific data, the DIF 1Fh shall be the last byte in the application frame of all except the
last datagram.
DIF = 1Fh should be used for unencrypted data (security mode 0 in EN 13757-7:2018, Table 19).
DIF = 1Fh shall not be used in combination with enabled fragmentation within AFL (see EN 13757-7,
EN 13757-6). For encrypted multi datagram messages fragmentation in AFL should be applied instead
of DIF = 1Fh.
NOTE 2 If DIF = 0Fh is used in combination with fragmentation in the AFL, the manufacturer specific data are
continued in the successive fragments (without repeated application of DIF = 0Fh at the beginning of the
successive fragment).
In case of partial encryption (see EN 13757-7:2018, 7.6.5) DIF = 0Fh and the manufacturer specific data
shall be located completely outside of the encrypted area.
If manufacturer specific data are to be transported in the encrypted part of a partially encrypted
message, a data record with a suitable DIF (possibly a DIF with variable length — see 6.3.3) and a
VIF = 7Fh or FFh (manufacturer specific data record — see 6.4.1) shall be used instead of the usual
MDH-DIF = 0Fh or 1Fh.
NOTE 3 A MDH hidden in the encrypted part of a partially encrypted message causes misinterpreting of
following unencrypted data as long as encrypted data are not decrypted.
7 Application reset and application select

7.1 Application reset
With the CI-field 50h or 53h (without additional parameter), the master can release a reset of the
application layer in the slaves. Each slave itself decides which parameters to change, e.g. which data
output is default – after it has received such an application reset.
7.2 Application select with subcode
It is allowed to use optional parameters after CI = 50h or 53h. In this case, the CI-field acts as
application select. If more bytes follow, these bytes are the application select subcode. Up to 10 subcode
bytes are possible. The application select subcode defines which message function and which block is
requested by the master. The data type of this parameter is 8 bit binary. The upper 4 bits of each byte
define the message application and the lower 4 bits of each byte define the number of the block or
datagram number (the meaning of this number is device specific). The lower 4 bits may be ignored for
slaves which provide only a single datagram for each application. The use of the value zero for the
number of the block means that all datagrams are requested.
Message application and block number are calculated according to the following rules:
a) message from master to slave: CI = 50h/53h ax by cz;
28
EN 13757-3:2018 (E)
b) message from slave to master: CI = 66h/67h/68h ax by cz;
c) using the bytes ax, by, cz as 8 bit binary:
1) message application: a (if a ≤ Fh);
2) message application: a + b (if a = Fh and b ≤ Fh);
3) message application: a + b + c (if a = Fh, b = Fh and c ≤ Fh);
4) block number: x: Bit 0 to 3;
5) block number: y: Bit 4 to 7;
6) block number: z: Bit 8 to 11.
After the CI field up to 10 additional bytes are permitted. The above stated definitions are using only
3 additional bytes.
NOTE The usage of Fh for the application block ensures backward compatibility to previous revisions of this
standard, e.g. CI = 50h F0h 00h is equal to CI = 50h F0h.
Slaves with only one type of message may ignore application select and the added parameters. The
codes given in Table 19 are used for the upper 4 bits of the parameter bytes following the CI-Field:
29
EN 13757-3:2018 (E)
Table 19 — Coding of the message application
Coding Description Examples

0 All
1 User data Consumption
2 Simple billing Current and fixed date values + dates
3 Enhanced billing Historic values
4 Multi tariff billing
5 Instantaneous values For regulation
6 Load profile values for management
7 Static content
8 Installation and startup Bus address, fixed dates
9 Testing High resolution values
10 Calibration
11 Manufacturing
12 Development
13 Self test
14 Configuration data
15 User defined data Data set selected by the user
16 to 25 Reserved
26 to 45 Manufacturer specific usage
from 46 Reserved
7.3 Overview about CI-Fields for Application reset and Application select
If this feature is used it shall be implemented according to the definition in this clause. The CI fields
given in Table 20 shall be supported for application reset or application select.
30
EN 13757-3:2018 (E)
Table 20 — CI fields for application select
Applica Applica
TPL
CI field ble to ble to Name Description
header
wM-Bus M-Bus
Selects the requested application or block
Application reset or
50h in the application (with parameter) or
None no yes select to device
resets to application to default state
(master to slave)
(without parameter)
Selects the requested application or block
Application reset or
53h in the application (with parameter) or
long yes yes select to device
resets to application to default state
(master to slave)
(without parameter)
Request of selected
54h Readout of selected application and next
none no yes application to device
block (without parameter)
(master to slave)
Request of selected
55h Readout of selected application and next
long yes yes application to device
block (without parameter)
(master to slave)
Response of selected
66h Transmission of selected application and
none no yes application from device
next block
(slave to master)
short yes no application from device
next block
(slave to master)
long yes yes application from device
next block
(slave to master)
All meters supporting several applications or one application with several blocks shall support these CI
fields.
An application reset forces the fall-back to the standard response. The standard response is a
(predefined) application. Typically the standard response is application 0. The standard response starts
with block 0.
A SND-UD with “Request of selected application” is confirmed with ACK. The successive REQ-UD2 shall
be replied with “Response of selected application”. SND-UD2 can be used alternatively: The slave
answers immediately with “Response of selected application”. The return to the M-Bus application
protocol is accomplished by using “Application reset” or “Application select”.
7.4 Rules for application selection
7.4.1 Reset of current slave response
The current application selection is retained until:

— an application reset or application select is received,
— until timeout condition is reached, or
— a device reset has been accomplished.
Master should apply an application select after a voltage drop was detected.
31
EN 13757-3:2018 (E)
NOTE A secondary address selection or deselection, SND-NKE or break does not lead to a change of the
application selection.
7.4.2 Erroneous application select
An erroneous application select (selection of not supported application) shall be processed as

application reset.
7.5 Rules for block selection
— First block:
The first block shall contain the most important information.
— Current block:
The selected application block is delivered as next block by the slave.
— Wrap around:
If no successive block is available the next transmitted block will be the first block (block 0).
— Wrong block selection:
If a master selects a block that is not available the next transmitted block will be the first block
(block 0).
— Application reset:
After application reset the next transmitted block will be the first block (block 0).
7.6 Selected application block in M-Bus Application protocol
Application select shall be used by a master to select an application and a block from the slave. If a
master requests a certain block from a slave and this block is not available in the currently selected
application the slave can transmit a different block. Therefore it is necessary that the slave transmits
the current block number in each block.
Using VIF = FDh FDh 00h the slave should send message application and number of block in a message.
If meters are providing more than one block in a selected application the defined data point shall be
transmitted in each block. Otherwise the data point with the block number can be omitted.
If the M-Bus application protocol is encrypted the encryption of this data point is optional.
8 Clock synchronization
For wireless communication (but not limited to this one), the clock synchronization is executed by a
special protocol for clock synchronization. For this protocol CI-fields 6Ch and 6Dh are used. E.3
specifies the transmission of clock synchronization to meter.
Alternatively, the clock may set by an M-Bus-command. The communication partner may send date and
time in all command messages to ensure that the meter can detect a replay of an old command. The
meter shall not use this time stamp for synchronization of its clock except when a dedicated action code
(see Table 17) was added.
32
EN 13757-3:2018 (E)
9 Report of alarm status (slave to master)

The Alarm state can be reported by Cl = 71h, 74h and 75h. For details of the report of alarm status
errors, see Annex D.
10 Report of application error

10.1 General
The acknowledgement by the data link layer reports only a successful communication. Errors happened
by the handling of the transmitted application data are not automatically reported but need to be
requested by the master separately. After successful transmission of the Application error the meter
response will be reset by sending another command or by applying an Application reset/select.
10.2 Status field
The presence and type of an application error shall be indicated by the status field in the TPL-header
(see EN 13757-7:2018, 7.5.6). The status field is applied in every message with a short or long TPL-
header.
10.3 General application layer errors
For reporting general application errors, a slave can use a RSP-UD datagram with CI = 6Eh, 6Fh or 70h
and zero, one or several data bytes, which describe the type of error.
The defined values for an application error are given in Table 21.
Table 21 — First error code byte for general application errors
Byte Designation Type of error

00h Unspecified error Unspecified error: also if data field is missing
01h CI-field error Unimplemented CI-field
02h Buffer overflow Buffer too long, truncated
03h Record overflow Too many records
04h Record error Premature end of record
05h DIFE overflow More than 10 DIFE’s
06h VIFE overflow More than 10 VIFEs
07h – Reserved
08h Application busy Application too busy for handling readout request
09h Credit overflow Too many readouts (for slaves with limited readouts per time)
0Ah to 0Fh – Reserved
11h No function Function not implemented (command unknown or not supported)a

12h Data error Data to be supplied not availablea
13h Routing/Relaying error Cannot route/relay data furthera
14h Access violation Data access right violationa
33
EN 13757-3:2018 (E)
Byte Designation Type of error

15h Parameter error Parameter is missing or wronga
16h Size error The amount of data requested cannot be handleda
17h to 1Fh – Reserved
20h Message counter check. Decryption or Authentication fails or

Security error
selected key is not available
21h Security mechanism not

Security mechanism is not supported
supported
22h Inadequate security method Security method or key is not applicable for this function
23h to EFh – Reserved
F0h – Dynamic application errorb
F1h to FFh – Manufacture specific application error
a These error codes are applied in EN 13757–5.

b The data point is coded as M-Bus-specific data point with a leading DIF/VIF. The declaration is vendor
specific. The dynamic application error is limited to 7 bytes.
NOTE Errors which belongs to a specific M-Bus record can be coded by a record error (see 6.4.8).
11 Switching baud rate for M-Bus link layer according to EN 13757-2

All slaves shall be able to communicate with the master using the minimum transmission speed of
300 Bd. Split baud rates between transmit and receive are not allowed, but there can be devices with
different baud rates on the bus.
In point to point connections the slave is set to another baud rate by a control frame (SND-UD with L-
Field = 3) with address FEh and one of the following CI-field codes.
For safety reasons a baud rate switch command (Table 25) to the (unacknowledged) broadcast address
255 is not recommended.
Table 22 — CI-field codes for baud rate switching
CI-field B8h B9h BAh BBh BCh BDh BEh BFh
Baud 300a 600b 1 200b 2 400a 4 800b 9 600a 19 200b 38 400b

a Recommended standard baud rates.
b These baud rates are reserved for special operator agreement only.
34
EN 13757-3:2018 (E)
The slave always confirms the correctly received datagram by transmitting an E5h with the old baud
rate and uses the new baud rate from now on, if it is capable of this. Otherwise the slave stays at its
previous baud rate after the E5h acknowledge. To make sure that a slave without auto speed detect has
properly switched to the new baud rate and that it can communicate properly at the new baud rate in
its segment, it is required that, after a baud rate switch to a baud rate other than 300 Bd, the master
attempts immediately (<2 min) after the baud rate switch command a communication. If (even after the
appropriate number of retries) this is not acknowledged by the slave, the master shall issue a baud rate
set command (at the attempted new baud rate) back to the previous baud rate. If a slave without auto
speed detect does not receive a valid communication at the new baud rate within 2 min to 10 min of the
baud rate switch command, the slave shall fall back to its previous baud rate. This is required
individually and sequentially for each addressable slave. For compatibility with older slaves with fall
back to 300 Bd, the master should also attempt a communication at 300 Bd if the slave does not answer
at its last baud rate.
12 Synchronize action
If this feature is used it shall be implemented according to the definition in this clause.
The CI-field 5Ch can be used for synchronizing functions in slaves and masters (e.g. clock
synchronization). Special actions or parameter loads may be prepared (see Table 17). But the final
execution is delayed until the reception of such a special CI-field command. No data follows this CI-code.
13 Manufacturer specific protocols

With the usage of CI-Fields from A0h to B7h manufacturer specific application data protocols can be
announced.
NOTE For the usage of manufacturer specific data inside the M-Bus application protocol refer to 6.5.
14 Other application protocols

Other application layer protocols are defined in EN 13757-7:2018, Table 2.
15 Image transfer
The image transfer protocol is defined in Annex I.
35
EN 13757-3:2018 (E)
Annex A
(normative)
Coding of data records
Keys
X Number of applied bits as defined in the data field (see Table 4)
UI Unsigned integer
I Signed integer
B Array of bits
EXAMPLE UI4 [0 to 3] < 0 to 9 > means the 4 bits from position bit0 to position bit3 are coded as unsigned
integer and can contain values from 0 to 9.
The following data types are used inside the application layer:
Type A: Unsigned integer BCD:
Table A.1 — Type A: Unsigned BCD
7 6 5 4 3 2 1 0 digit 10° UI4 [0 to 3] < 0 to 9 > ; < A to F > a
... ... ... ... ... ... ... ... digit 101 UI4 [4 to 7] < 0 to 9 > ; < A to F > a
…
X–1 X–4 X–5 X–8 digit 10(X/4–2) UI4 [X–8 to X–5]
< 0 to 9 > ; < A to F > a:

digit 10(X/4–1) UI4 [X–4 to X–1]
< 0 to 9 > ; < A to F > a
a Digits values of Ah to Eh in any digit position signals invalid. A hex code Fh in the most significant digit
position signals a negative BCD number in the remaining X–1 digits. For details of this coding see Annex B.
Type B: Binary – Signed integer:
Table A.2 — Type B: Binary — Signed integer
7 6 5 4 3 2 1 0 IX [0 to (X–1)] < (−2(X–1) +1) to (+2(X–1) –1) > ;
... ... < –2(X–1) > : invalid

X–1 X–8
NOTE Negative values are in two’s complement.
36
EN 13757-3:2018 (E)
Type C: Binary – Unsigned integer:

Table A.3 — Type C: Binary — Unsigned integer
7 6 5 4 3 2 1 0 UIX [0 to (X–1)] < 0 to (+2X –2) > ;
... ... < 2X –1 > : invalid

X–1 X–8
NOTE The data field coding as ‘integer/binary’ always applies to Type B (signed integer) except Type C
(unsigned integer) is explicit declared by the special VIF/VIFE.
Type D: Boolean (array of 1 bit binary information)
Table A.4 — Type D: Boolean
7 6 5 4 3 2 1 0 State: B1[i] < 0 to 1 > for 0 ≤ i ≤ (X–1)

... ... < 0 > : false ; < 1 > : true
X–1 X–8
NOTE The data field coding as ‘integer/binary’ always applies to Type B (signed integer) except Type D
(Boolean) is explicit declared by the special VIF/VIFE.
Type E: Obsolete
Type F: Compound CP32: Date and time
Data field = 0100b (32 bits)
Table A.5 — Type F: Date and time (CP32)
7 6 5 4 3 2 1 0 Minute: UI6 [0 to 5] < 0 to 59 > ; < 63 > : every minute

15 14 13 12 11 10 9 8 Hour: UI5 [8 to 12] < 0 to 23 > ; < 31 > : every hour
23 22 21 20 19 18 17 16 Day: UI5 [16 to 20] < 1 to 31 > ; < 0 > : every day
31 30 29 28 27 26 25 24 Month: UI4 [24 to 27] < 1 to 12 > ; < 15 > : every month
Year: UI7 [21 to 23; 28 to 31] < 0 to 99 > a;

< 127 > : every year
Hundred year: UI2 [13 to 14] < 0 to 3 > ;
this year is 1900+100*hundred year + year
IV B1 [7] IV < 0 > : valid ; IV < 1 > : invalid
SU B1 [15] SU < 0 > : standard time ;
SU < 1 > : summer time
RES1 B1 [6] < 0 > : reserved for future use
a For compatibility with old meters with a circular two digit date it is recommended to consider in any master
software the years “00” to “80” as the years 2000 to 2080.
Type G: Compound CP16: Date
37
EN 13757-3:2018 (E)
Table A.6 — Type G: Date (CP16)
Day: UI5 [0 to 4] < 1 to 31 >

7 6 5 4 3 2 1 0
< 0 > : every day
Month: UI4 [8 to 11] < 1 to 12 >
15 14 13 12 11 10 9 8
< 15 > : every month
Year: UI7 [5 to 7; 12 to 15] < 0 to 99 > a

< 127 > : every year
NOTE A value of FFh in both bytes (that means FFFFh) shall be interpreted as invalid.
a For compatibility with old meters with a circular two digit date it is recommended to consider in any master
software the years “00” to “80” as the years 2000 to 2080.
Type H: Floating point
Type binary32 according to ISO/IEC/IEEE 60559:2011:
Fraction F: UI23 [0 to 22] < 0 to (1–2−23) >
Exponent E: UI8 [23 to 30] < 0 to 255 >
Sign S: B1 [31] < 0 > : positive
< 1 > : negative
F < 0 > and E < 0 > : = (−1) S*0 = ± zero
F < ≠0 > and E < 0 > : = (−1) S*2E–126(0.F) = denormalized numbers
E < 1 to 254 > : = (−1) S*2E–127(1.F) = normalized numbers
F < 0 > and E < 255 > : = (−1) S*∞ = ± infinite
F < ≠0 > and E < 255 > : = NaN = not a number, regardless of S
Table A.7 — Type H: Floating point
Bits 7 6 5 4 3 2 1 0
F = Fraction
Octet 1
2−16 2−17 2−18 2−19 2−20 2−21 2−22 2−23
F = Fraction
Octet 2
2−8 2−9 2−10 2−11 2−12 2−13 2−14 2−15
E (LSB) F = Fraction
Octet 3
2−0 2−1 2−2 2−3 2−4 2−5 2−6 2−7
Sign E = Exponent
Octet 4
S 27 26 25 24 23 22 21
The following ranges are specified by ISO/IEC/IEEE 60559:2011 for type binary32 floating point
arithmetic:
Range: (–2128 + 2104) to (+2128 – 2104), that is –3,4 ⋅ 1038 to +3,4 ⋅ 1038
Smallest negative number: –2−149, that is: – 1,4 ⋅ 10−45
Smallest positive number: +2−149, that is: + 1,4 ⋅ 10−45
38
EN 13757-3:2018 (E)
The NaN coding signals “invalid”.

Type I: Year down to second (Local time)
Table A.8 — Type I: Date and time (CP48)
7 6 5 4 3 2 1 0 Second: UI6 [0 to 5] < 0 to 59 > ; < 63 > : every seconda
15 14 13 12 11 10 9 8 Minute: UI6 [8 to 13] < 0 to 59 > ; < 63 > : every minutea

23 22 21 20 19 18 17 16 Hour: UI5 [16 to 20] < 0 to 23 > ; < 31 > : every houra
31 30 29 28 27 26 25 24 Day: UI5 [24 to 28] < 1 to 31 > ; < 0 > : not specifieda
39 38 37 36 35 34 33 32 Month: UI4 [32 to 35] < 1 to 12 > ; < 0 > : not specifieda
47 46 45 44 43 42 41 40 Year: UI7 [29 to 31; 36 to 39] < 0 to 99 > ;
< 127 > : not specifieda

Day of the weekb: UI3 [21 to 23] < 1 to 7 >
< 1 > : Monday; < 7 > : Sunday;
Week: UI6 [40 to 45] < 1 to 53 > ; < 0 > = not specifieda
Time invalid: UI1 [15] < 1 > : invalid ; < 0 > : valid
Time during daylight savings: UI1 [6]
< 1 > : yes (summer time) ; < 0 > = no
Leap year UI1 [7] < 1 > : leap year ; < 0 > : standard year
Daylight savings deviation (hour)c
UI1 [14] < 0 to 1 > < 0 > : “–“ ; < 1 >: “+” ;
UI2 [46 to 47] < 0 to 3 > ; < 0 > : no daylight savings
a Other values reserved for future uses.
b Based on EN 62056–6-1 (COSEM).
c Number of hour by which the local time shall be corrected at daylight savings begin.
39
EN 13757-3:2018 (E)
Key
Y deviation
X time
1 daylight savings begin
2 daylight savings end
Figure A.1 — Change of time by daylight savings
Type J: Time of day (Local time)

Table A.9 — Type J = Time (CP24)
7 6 5 4 3 2 1 0 Second: UI6 [0 to 5] < 0 to 59 > ; < 63 > : every seconda
15 14 13 12 11 10 9 8 Minute: UI6 [8 to 13] < 0 to 59 > ; < 63 > : every minutea
23 22 21 20 19 18 17 16 Hour: UI5 [16 to 20] < 0 to 23 > ; < 31 > : every houra
A value of FFh in all three bytes (that means FFFFFFh) shall be interpreted as invalid.
Note that in EN 13757–3:2013 the 000000h was applied to signal the state “invalid”.
Unused bits shall be 0 except the value is invalid.
a Other values are reserved for future usage.
Type K: Daylight savings
Data field = 0100 (32 bits)
40
EN 13757-3:2018 (E)
Table A.10 — Type K: Daylight savings
7 6 5 4 3 2 1 0 Daylight savings begin (given in local time):
15 14 13 12 11 10 9 8 Hour: UI5 [0 to 4] < 0 to 23 > ; < 31 > : not specifieda
23 22 21 20 19 18 17 16 Day: UI5 [8 to 12] < 1 to 31 > a
31 30 29 28 27 26 25 24 Month: UI4 [24 to 27] < 1 to 12 > a

Daylight savings end: (given in local time):
Day: UI5 [16 to 20] < 1 to 31 > a
Month UI4 [28 to 31] < 1 to 12 > a
Daylight savings enable
UI1 [15] < 0 to 1 >
< 1 > enables daylight savings function
Daylight savings deviation (hour)b
UI1 [23] < 0 to 1 > < 0 > : “–“ ; < 1 >: “+”
UI2 [21 to 22] < 0 to 3 > ; < 0 > : no daylight savings
Deviation from local time to the Greenwich Mean Time (hour):
UI5 [5 to 7; 13 to 14] < 0 to 23 > ;
a Other values are reserved for future uses.
b Number of hour by which the local time shall be corrected at beginning of daylight savings.
Type L: Listening window management
Data field = 1101b (variable length LVAR = EBh)
Table A.11 — Type L: Listening window management
Byte/bit MSBit LSBit

LSB 7 6 5 4 3 2 1 0
15 14 13 12 11 10 9 8
23 22 21 20 19 18 17 16
31 30 29 28 27 26 25 24
39 38 37 36 35 34 33 32
47 46 45 44 43 42 41 40
55 54 53 52 51 50 49 48
63 62 61 60 59 58 57 56
71 70 69 68 67 66 65 64
79 78 77 76 75 74 73 72
MSB 87 86 85 84 83 82 81 80
This command is used to initialize the window listening management, which defines when the meter is
in “normal mode” or “power saved mode”.
We choose the week(s) while the meter could be in normal mode. Set to 1 the matching bit(s): bit 0 to
bit 52. The first week of the year is represented by bit 0 to the 52nd by the bit 51.
41
EN 13757-3:2018 (E)
We choose the day(s) while the meter could be in normal mode. All the weeks are identical for this
choice. Set to 1 the matching bit(s): bit 53 to bit 59. Sunday is represented by bit 53, Monday by bit 54
to Saturday by bit 59.
We choose the hour(s) while the meter could be in normal mode. All the days are identical for this
choice. Set to 1 the matching bit(s): bit 60 to bit 83. The first hour is represented by bit 60 to the 24th
hour by bit 83.
We choose the quarter(s) of an hour, while the meter could be in normal mode. All the hours are
identical for this choice. Set to 1 the matching bit(s): bit 84 to bit 87. The first quarter is represented by
bit 84 to the fourth quarter by the bit 87.
At one point, the meter is in “normal mode” if the bits for week, day and hour are set to 1. The meter is
in “power saved mode” if one or more of the bits for week, day and hour is set to 0.
EXAMPLE
If bits 2, 54, 55, 60 and 61 are set to 1 and the others are set to 0. The meter is in normal mode between 0 h and 2
h on Monday and Tuesday of the third week of the year.
If bits 2, 54, 55, 60, 62, 84 and 85 are set to 1 and the others are set to 0 the meter is in normal mode in the first
and second quarter of hour 0 and hour 2, between 0:00’ and 0:30’ and between 2:00’ and 2:30’, on Monday and
Tuesday of the third week of the year.
Type M: Compound CP_LVAR: Date and time/duration

Data field 1101b (variable length LVAR = E2 to EAh)
This time format is coded according to the coordinated universal time (UTC). It corresponds to Epoch
time. This data type can be adjusted in length and resolution.
Table A.12 — Type M: Date and time (CP_LVAR)
7 6 5 4 3 2 1 0 Duration since the starting time:

... ... I(X–8) [0 to (X–9)] < (−2(X–9) +1) to (+2(X–9) −1) > a
X–9 X–16 < –2X–9 > : signals “invalid”
X–1 X–2 X–3 X–4 X–8 Time Offset: I5 [(X–8) to (X–4)]
< –16 > : relative time (duration)a,b,c

< –12 to +14 > : offset to UTC in hoursa,b
Resolution: B2 [(X–3) to (X–2)]
<0> :2s
<1> :1s
<2> : 1/256 s
<3> : 1/32768 s
Starting time: B1 [X–1]
<0> : 2013–01–01 at 00:00:00 (UTC)c
<1> : 1970–01–01 at 00:00:00 (UNIX-
Time)
a Negative values are in two’s complement.
b Other values are reserved for future uses.
c In case of relative time the bit Starting time shall be 0.
42
EN 13757-3:2018 (E)
The time format Type M contains always the coordinated universal time. A deviation of the local time
zone to UTC can be considered in the field time offset. Daylight savings shall not be used in this time
format.
NOTE This format does not support time zones, which use a fraction of an hour to UTC.
A time offset of 10000b specifies a point in time relative to a reference time. In this case the value in
starting time does not care. If no specific reference time is declared the time of transmission shall be
used.
For the application in the M-Bus-protocol the data type LVAR shall be used. The number of used data
bits X is calculated by X = 8*(LVAR-E0h).
EXAMPLE 1 A timestamp 2013–01–02 at 01:02:03 (UTC) presented by a 4 byte timer with a resolution in
seconds and an offset of 1 h (=2013–01–02 02:02:03 CET) is codes as:
0Dh 6Dh E5h 0Bh 60h 01h 00h 21h (= 90123 s after 2013–01–01 at 00:00:00 UTC).
EXAMPLE 2 An event 34,5 s before the meter transmission presented by a 2 byte timer with a resolution of
256th part of a second is coded as:
0Dh 6Dh E3h 80h DDh 50h (= –8832 ⋅ 1/256 s).
43
EN 13757-3:2018 (E)
Annex B
(normative)
Interpretation of hex-codes Ah–Fh in BCD-data fields
B.1 General description standard reference

B.1.1 General
This standard allows multi-digit BCD-coded data fields. It does, however, not contain information about
what happens if a non-BCD hex code (Ah–Fh) is detected by the master software.
B.1.2 Purpose
a) Define the treatment of non BCD-digits in slave to master RSP-UD-datagrams.
To fully define a master software including error treatment; such a definition would be desirable.
b) Utilize these codes for simplified error treatment by slave.
Simple visible error signalling.
To simplify the design of slaves with integrated displays, the above mentioned non-BCD states of the
variables should be both transmittable in the form of suitable (hex) codes but also be displayable
directly from the value codes of a 7-segment (usually LCD) display by extending the normal 10 entry
BCD to 7-segment decoding a 16-entry decoding table.
B.2 Definition
B.2.1 Hex code meanings
a) Ah–Eh
Such a code in any digit position signals a general error of the complete data field. The display at
the meter or a remote readout device should display an appropriate symbol at the appropriate
display position (see Table B.1).
b) Fh
Such a code in the most significant digit position signals a “minus-sign” in front of the remaining
(N–1) digit number. In any other digit position it signals an error.
EXAMPLE A 4-digit BCD code of “F321” will be interpreted by the master software as “–321” and displayed
as “–321” on a 4-digit only display.
B.2.2 LCD-decoding table
Table B.1 — Decoding table
0 1 2 3 4 5 6 7 8 9 Ah Bh Ch Dh Eh Fh
“0” “1” “2” “3” “4” “5” “6” “7” “8” “9” “A” “b” “C” ““ “E” “–“
44
EN 13757-3:2018 (E)
Annex C
(normative)
VIF coding for special units
C.1 Non-metric units

If the VIF-Extension code 3Dh (non-metric units, see Table 15) is used, the standard metric units of the
VIF table is substituted as shown in Table C.1.
Table C.1 — Metric/non-metric units
Standard VIF Standard unit and range Non-metric unit and range Type
E0000nnn 0,001 Wh to 10 000 Wh 0,001 kBTU to 10 000 kBTU Energy
E0010nnn 0,001 l to 10 000 l 0,001 USgal to 10 000 USgal Volume
0,0001 USgal/min to
E1000nnn 0,0001 l/min to 1 000 l/min Volume flow.
1 000 USgal/min
E0101nnn 0,001 W to 10 000 W 0,001 mBTU/s to 10 000 mBtu/s Power
E10110nn 0,001 °C to 1 °C 0,001°F to 1 °F Temp. forward
E10111nn 0,001 °C to 1 °C 0,001°F to 1 °F Temp. return
E11101nn 0,001 °C to 1 °C 0,001°F to 1 °F Cold/ warm temperature limit
E11000nn 0,001°C to 1 °C 0,001°F to 1 °F Temp. difference
E11001nn 0,001°C to 1 °C 0,001°F to 1 °F External temperature
C.2 Plain text units

In case of VIF = 7Ch/FCh the applied unit is represented by the following ASCII string with the length
given in the first byte. The rightmost character is transmitted first. This plain text VIF allows the user to
code units that are not included in the VIF tables (Table C.2).
Table C.2 — Data record structure for plain text VIF usage
DIB VIB ASCII length ASCII string Value

EXAMPLE (all values are hex):
0C DIF means 8 digit BCD value
FC VIF means plain text VIF following
A2 VIFE means “per hour”
73 VIFE means “*10E–3”
04 ASCII length means 4 bytes ASCII string following
6C 61 67 69 ASCII string means “igal”
26 08 42 75 Value = 75420826
45
EN 13757-3:2018 (E)
Coded value = 75420826 igal/h*10E–3 (= 75420,826 Imperial Gallons/hour)
C.3 Remote enablement/disablement of valve/breaker

The device type « breaker » (20h) and « valve » (21h) allows the definition of physically or logically
separated media controlled device with separate address. Otherwise, the valve/breaker may be
integrated in the metering device. Therefore, the address of the meter shall apply. The
VIF/VIFE = FDh 1Fh allows to control both logically integrated and logically separate valve/breaker. If a
device has other functions in addition to metering, the device type is set according to the metering
function which is associated with the (default) subunit = 0 in the DIF. A (secondary) switch function
shall be associated with the subunit = 1. Other additional functions may use higher subunit numbers. If
detailed functional requirements for the different media are available, more suggestion for the usage of
existing elements to implement these functions would be possible. To enable/disable a valve the values
in the least significant byte after VIF/VIFE = FDh 1Fh shall follow Table C.3.
Table C.3 — Values for the remote control of the valve
Value Meaning
00 Valve closed
01 Valve opened
02 Valve released, not open
03 to 255 Reserved
It is recommended to apply additionally a time stamp or a sequence counter together with the switch
command to detect the replay of an expired switch command.
EXAMPLE To close a valve together with the sequence counter of 3:
04h FDh 08h 03h 00h 00h 00h 01h FDh 1Fh 00
46
EN 13757-3:2018 (E)
Annex D
(informative)
Alarm protocol
D.1 M-Bus according EN 13757-2

The master software polls the maximum 250 alarm devices by requesting time critical data. A slave can
transmit an acknowledgement signalling no alarm or a datagram with alarm protocol with the CI-field
71h (no header), 74h (short header) or 75h (long header) to report an alarm state (EN 13757-7:2018,
Annex A).
The alarm state is coded with data Type D (Boolean; in this case 8 bit). Set bits signal alarm bits or
alarm codes. The meaning of these bits is manufacturer specific.
The time out for time critical communication is set to 11 bit … 33 bit periods to ensure a fast poll of all
alarm devices. With a baud rate of 9 600 Bd and all 250 slaves reporting an alarm just in time before a
timeout occurs each slave will be polled in periods of maximum 5,5 s. This seems to be fast enough for
alarms in building control systems and other applications. For faster alarm systems the number of
alarm sensors could be limited to 63 (reducing the worst case overall signal delay to less than 1,5 s) or
increase the transmission speed to 38 400 Bd and achieve the same speed for up to 250 devices.
The functionality of the FCB- and FCV-bit shall be fully implemented in this alarm protocol to ensure
that one-time alarms are safely transmitted to the master. If the slave has reported a one-time alarm
and the next REQ_UD1 has a toggled FCB (with FCV = 1) the slave will answer with an ACK
(acknowledge) signalling no alarm. Otherwise it will repeat the last alarm frame to avoid that the alarm
message gets lost. If the meter does not support the alarm protocol it has always to respond with an
ACK.
D.2 Wireless M-Bus according to EN 13757-4

The meter may initiate the transmission of an alarm message or response to the REQ-UD1 of the
communication partner. A slave can transmit an acknowledgement signalling no alarm (after REQ-UD1
only) or an alarm message with the CI-field 71h (no header), 74h (short header) or 75h (long header) to
report an alarm state (EN 13757-7:2018, Annex A).
The alarm state is coded with data Type D (Boolean, in this case 8 bit). The 8 bits of data Type D can
signal alarms as single bits or as alarm codes. The meaning of these bits is manufacturer specific.
47
EN 13757-3:2018 (E)
Annex E
(informative)
Special sequences for M-Bus devices
E.1 VIF/VIFE/VIFE = FDh 97h 1Dh (error flag)

If the data point VIF/VIFE/VIFE = FDh 97h 1Dh is used, then the least significant bytes of error flag have
the meaning given in Tables E.1, E.2 and E.3.
Table E.1 — Least significant error byte (EF1)
b7 b6 b5 b4 b3 b2 b1 b0
27 26 25 24 23 22 21 2°
Table E.2 — Meaning of error bits in the least significant error byte (EF1)
Bit Meaning with set bit Explanation

In case of critical mechanical modifications
b0 Mechanical Tampera (e.g. opening the meter, module dismounting)
b1 Battery low Set in case of under voltage or predicted end of life
b2 External alarma A critical error is provided by an external input

b3 Battery cut or disconnection In case of hard voltage drop
e.g. Checksum error of memory chip, watchdog timer, stack
b4 Hardware or software error
overflow
b5 Connection interrupta e.g. Adapter lost connection to meter by wire cut
b6 Magnetic tampera In case of detecting magnetic manipulation
Set to 1: more standardized error bytes will follow

b7 Standardized error byte followingb Set to 0: manufacturer specific error bytes may follow
NOTE A clear bit marks a state of normal operation.
a If this error is used together with a historical error of Table EF3 it should only give the current (real time)
status. If a historical error is not provided this bit should be the (logical OR) combination of historical and real
time behaviour.
b The number of standardized and manufacture specific error bytes is defined by the data field in the DIF (see
Table 4). The last standardized error byte shall use a b7 = 0
b
Table E.3 — Second least significant error byte (EF2)
b7 b6 b5 b4 b3 b2 b1 b0
215 214 213 212 211 210 29 28
48
EN 13757-3:2018 (E)
Table E.4 — Meaning of error bits in the second least significant error byte (EF2)

In case of attempt of unauthorised access via local or remote
b0 Unauthorised access attempt
interface, (e.g. wrong key, counter or password).
b1 Credit limit exceeded Communication credit limit reached
b2 Leakagea Recognizing continuously flow for a longer time

Recognizing no flow for a longer time (e.g. meter blocked or
b3 No flowa removed totally)
Meter not used appropriate e.g. overflow (>Qmax),
b4 Consumption out of range
underflow (<Qmin)
Possible wrong installation of meter, e.g. a sensor detecting
b5 Sensor out of rangea wrong input values like backward flow or too high
temperature
In case of missing synchronisation event or
b6 Clock Sync error
receiving unexpected big correction value
b7 Standardized error byte followingb Set to 0: manufacturer specific error bytes may follow
a If this error is used together with a historical error of Table EF3 it should only give the current (real time)
status. If a historical error is not provided this bit should be the (logical OR) combination of historical and real
time behaviour.
b The number of standardized and manufacture specific error bytes is defined by the data field in the DIF (see
b
Table E.5 — Third least significant error byte (EF3)
b7 b6 b5 b4 b3 b2 b1 b0
223 222 221 220 219 218 217 216
49
EN 13757-3:2018 (E)
Table E.6 — Meaning of error bits in the third least significant error byte (EF3)

In case of past mechanical modifications
b0 Historical mechanical tamper
(e.g. opening the meter, module dismounting).
b1 Historical magnetic tamper In case of past magnetic manipulation
b2 Historical connection interrupt There was a connection problem e.g. to an adapter
b3 Historical external alarm There was a critical error provided by an external input
b4 Historical leakage A continuous flow was recognized for a longer time
b5 Historical no flow No Flow was recognized for a longer time
b6 Historical sensor out of range There was a sensor error like backward flow
b7 Standardized error byte followinga Set to 0: manufacturer specific error bytes may follow
a The number of standardized and manufacture specific error bytes is defined by the data field in the DIF (see
b
If the meter detects an error and marks this condition in this data point it shall also set the related bit in
the status byte. If the meter receives a command clearing one or several bits of this error flag then the
related bits of the status byte shall be cleared too.
E.2 VIF/VIFE/VIFE = FDh 9Fh 1Dh for passing remote control on a node
If the data point VIF/VIFE/VIFE = FDh 9Fh 1Dh for a wireless M-Bus device is used the least significant
byte of remote control has the meaning given in Tables E.4, E.5, E.6, E.7 and E.8.
Table E.7 — Least significant byte of the remote control (RC1)
b7 b6 b5 b4 b3 b2 b1 b0
27 26 25 24 23 22 21 2°
Table E.8 — Remote control (RC1): adjust power
Power adjust for a radio product, the bits of the first byte of
b0 b1
remote control have the following meaning:
0 0 do nothing
0 1 reserved for future use
1 0 decrease power (one step)
1 1 increase power (one step)
50
EN 13757-3:2018 (E)
Table E.9 — Remote control (RC1): enable test mode
b3 b4 b5 Test mode
0 0 0 do nothing
0 0 1 test mode : temporary emission of permanent “0”a
test mode : temporary emission of permanent carrier, no
0 1 1
modulationa
1 0 1 test mode : temporary receptiona

1 1 0 reserved for future use
1 1 1 reserved for future use
a The duration of the temporary emission/reception shall be declared by the
vendor.
Table E.10 — Remote control (RC1): power save mode
b6 Mode select
0 power save mode
1 normal mode
Table E.11 — Remote control (RC1): reserved
b2 reserved for future use

b7 reserved for future use
The meaning of following bytes is reserved for future extensions.
E.3 Clock synchronization

Two additional CI-fields (6Ch and 6Dh) shall be used to set a new date/time, or to do an incremental
time correction independent of the application layer used otherwise. Since these are essentially SND-
UD-type datagrams they shall be acknowledged by the meter with an ACK. They use the full long header
that contains the application address of the slave (in addition to the partner address in the link layer).
The commands should be encrypted and/or authenticated to prevent unauthorized date/time changes
in the meter. The last four 2Fh filler bytes should be used for additional command verification. The date
and time uses data formats I and J as specified in Annex A. The TC-field is used for control timing actions
and is specified as given in Tables E.9, E.10 and E.11.
Table E.12 — Structure of TC-field
Bit no. Value

00b (Bit1 = 0; Bit0 = 0) – set time
01b (Bit1 = 0; Bit0 = 1) – add time difference
0,1
10b (Bit1 = 1; Bit0 = 0) – subtract time difference
11b (Bit1 = 0; Bit0 = 0) – reserved
2 to 7 Reserved (0 by default)
51
EN 13757-3:2018 (E)
a) Set new date and time:
Table E.13 — Application frame “time setting” with CI = 6Ch (Set date and time)
Long Data-Header TC-Field Date/time in Command

Reserved
CI = 6Ch (EN 13757–7:2018, (1 byte) Format I (6 bytes, verification
(3 bytes = 00h)
Annex A) (set time) LSB first) (4 bytes = 4*”2Fh”)
Under metrological aspects, this command is always considered as a clock reset by the slave.
b) Add/Subtract Time Offset:
Add/Subtract Time Offset to the current slave time to either correct a slave clock drift or to correct a
possible slave time error due to a communication delay of a previous set date/time command.
Table E.14 — Application frame “time adjustment” with CI = 6Dh (Add/Subtract Time Offset)
Long Data-Header TC-Field Time in Format J Command

Reserved
CI = 6Dh (EN 13757–7:2018, (1 byte) (add (3 bytes, verification
(6 bytes = 00h)
Annex A) or subtract) LSB first) (4 bytes = 4*”2Fh”)
If this command is either received by the slave more than 60 s after the last command or the partner
access number is different from the last command, then the add/subtract time command shall be
executed, otherwise it is considered as a repetition of the last time correction command and shall be
ignored.
The communication partner shall provide the correct time (UTC) for every bidirectional meter both
periodically and on event. In the following cases, a clock synchronization shall be applied:
— once every day (as long as the partner has a valid time);
— when the partner gets back to the valid time;
— after the installation of a new meter and
— after a communication interrupt for more than 24 h.
The time service of the communication partner is not an obligatory command. The change of the meter
clock is in the responsibility of the meter itself and shall consider device type specific requirements as
defined in dedicated standards and references. An example of clock synchronisation datagram is listed
in CEN/TR 17167:2018, Annex G.6.
52
EN 13757-3:2018 (E)
Annex F
(normative)
Transmission of profiles
F.1The standard load profile

When a meter generates a lot of periodical consumption values in one transmission it may be more
efficient to transport a load profile instead of a list containing pairs of consumption point of time and
consumption value.
For example, Table F.1 gives a load profile of consumption values for a water meter.
Table F.1 — Example for load profile: plain data
1st value at the end of the month 2008–01–31 65 l (10−3 m3)
2nd value at the end of the month 2008–02–29 209 l
3rd value at the end of the month 2008–03–31 423 l
4th value at the end of the month 2008–04–30 755 l
Last value at the end of the month 2008–05–31 1013 l

Table F.2 shows how this load profile shall be transmitted.
Table F.2 — Example for load profile: M-Bus-sequence
Value (Hex)
Description DIF/DIFE (Hex) VIF/VIFE (Hex)
(Example)
Count of transmitted storage numbers (optional) 89 04 FD 22 05
Interval to the next storage number (here 1 month) 89 04 FD 28 01
Date of last storage number (#12) 82 06 6C 1F 15
Storage number #8 8C 04 13 65 00 00 00
Storage number #9 CC 04 13 09 02 00 00
Storage number #10 8C 05 13 23 04 00 00
Storage number #11 CC 05 13 55 07 00 00
Storage number #12 8C 06 13 13 10 00 00
The first transmitted data points are the profile parameter count, data and interval. Thereafter follows
the cumulated consumption value per interval starting from the storage number #8. The lower storage
numbers remain reserved for single values like the current consumption or the consumption at the due
day, etc.
F.2The M-Bus compact profile

F.2.1 General
The M-Bus compact profiles are used to transport a series of values with a fix space between each value.
In addition to the compact profile, a base value and a base time is required to declare a start time and
the value of the profile. Additional base parameters like the OBIS-declaration may be added as well. The
53
EN 13757-3:2018 (E)
base time is chained with the compact profile by using the same storage number in the DIF/DIFE. The
base value and the base parameters are chained with the compact profile by using the same storage-,
tariff- and subunit numbers in the DIF/DIFE of the data record. If one of these numbers differs from the
compact profile, it shall be assumed that the base value or base parameters are missed.
F.2.2 The base value and base parameter
The data point base value (Table F.3) is the oldest value of the data series for VIFE = 1Eh/1Fh
respectively the youngest value for VIFE = 13h. It shall always exist unless the increment mode
“Absolute value” (00b) is used. In the absence of the base value, the first entry in the profile is used as
the first value of the data series instead. The base value and the base parameters may be used with any
DIF/DIFE and VIF/VIFE.
Table F.3 — Base value record (connected via storage-, tariff-, subunit number and VIF/VIFEx)
DIF/DIFE VIF/VIFEx Base value

F.2.3 The base time
The base time (Table F.4) shall be encoded with one of the Types F to J or M (refer to Annex A). It
corresponds to the base value, even if it does not exist. Therefore, the first entry in the compact profile
is always related to the base time added by one space interval.
Table F.4 — Base time record (connected via the storage number)
DIF/DIFE VIF (time/date Type F, G, I, J, M) Time/date value

F.2.4 Structure of the compact profile
The compact profile record (Table F.5) itself starts (like each M-bus data point) with a DIF (DIFE) and a
VIF (VIFE) but with an additional (new) orthogonal VIFE signalling a “compact profile”.
The profile record uses a data structure with variable length (DIF = xDh) followed by a length byte with
values between 3 and 191 (0BFh). The whole length is accumulated by two control bytes plus
N*(element length), where N is the number of elements of the profile. Consequently, the length of “2”
signals an empty profile.
Table F.5 — Profile record (connected via storage-, tariff-, subunit number and VIF/VIFEx)
DIF/DIFE with LVAR

VIF/VIFEx Spacing Spacing value
variable length # bytes Profile Value …
VIFE = 1Eh/1Fh/13h control byte byte
DIF = xDh (03h to BFh)
NOTE 1 For the binary integers (low nibble of the DIF = 1 to 4, 6 or 7) the incremental modes 01b and 10b use
unsigned integers (data type C), whereas the increment modes 00b and 11b use signed integers (data type B).
Refer to Annex A.
The first byte (spacing control byte, Tables F.6 and F.7) of this variable length record structure contains
the data size of each individual element in the lower four bits (as in the lower nibble of the DIF
definitions, but excluding variable length elements). The next higher two bits signal the time spacing
units (00b = sec, 01b = min, 10b = hours and 11b = days). The highest two bits signal the increment
mode of the profile (00b = absolute value (signed), 01b = positive (unsigned) increments (all
differences ≥ 0), 10b = negative (unsigned) increments (all differences ≤ 0), 11b = signed difference,
with: difference = younger value minus older value). All values of the profile are initially preset with the
coding for “illegal”, e.g. −128 for signed byte, 255 for unsigned byte, −32768 for signed word, etc. (refer
to Annex A, type B and C). Invalid values shall also be used in case of an overflow of an incremental
value.
54
EN 13757-3:2018 (E)
Table F.6 — Spacing control byte
b7 b6 b5 b4 b3 b2 b1 b0
27 26 25 24 23 22 21 2°
Table F.7 — Structure of spacing control byte
bit 6 to 7: Increment mode bit 4 to 5: Spacing unit bit 0 to 3: Element size

00b = Absolute value 00b = seconds
Profile DIF,
01b = Increments 01b = minutes/montha low nibble only, but except 0Dh
10b = Decrements 10b = hours/montha and except 0Fh
(see Table 4)
11b = Signed difference 11b = days/montha
a See Table F.8

After the space control byte follows the space value byte (single byte, Table F.8) giving the number of
the time spacing units between the profile values. It allows between 1 and 250 time units (s, m, h, d) as
time spacing. The values 251, 252 and 255 are reserved. To be able to additionally code monthly and
half-monthly profile spacing, the value 253 is used for half-monthly spacing and the value 254 is used
for monthly spacing. Both are used together with the spacing unit “days/month”. Spacing value 0 is used
to code a list of values which are not spaced in time. This could be any type of Table with up to four
columns.
Table F.8 — Spacing value byte
Spacing value Spacing unit Meaning
0 00b to 11ba Elements of an array, not spacing in time
1–250 all Number of days, hours, minutes or seconds between values

251 all Reserved
252 all Reserved
253 00b to 10b Reserved;

11b a half month between values
254 00b Reserved

01b six full months between values
10b three full months between values
11b a full month between values
255 all Reserved

a The spacing unit is used to address up to four columns. If only one column is needed, the spacing unit 00b
shall be used. When more than one column is used, the spacing unit describes the column number by the
formula spacing unit +1 (e.g. spacing unit 01b indicates column 2).
These first two fixed bytes are followed by the oldest value of the profile, the next oldest value, etc., until
the end of the variable length structure is reached. Note that if each profile value uses a DIF-data format
with a length of more than one byte, each individual profile value is in the “least significant byte first”
order.
55
EN 13757-3:2018 (E)
NOTE 2 The order of values is inverse for the "Inverse compact profile" (see F.2.8).
F.2.5 Types of compact profile
The M-Bus supports three types of compact profiles:

— “Compact profile with register numbers” for the transport of a limited number of values with an
assigned register number (e.g. recent value);
— “Compact profile” for the transport of an unlimited number of values as a series with no assignment
to a register number (e.g. load profile);
— “Inverse compact profile” for the transport of an unlimited number of values as a series with no
assignment to a register number (e.g. load profile).
The Compact profile with register numbers applies the storage numbers in a different way than the
Compact profile (without register numbers) and the Inverse compact profile. The transmission of
several profiles (e.g. for two tariffs) in parallel is possible, but it requires a different coding in the
DIF/DIFE or the VIF/VIFE e.g. by the use of different tariff numbers. As long as the storage numbers are
identical, all compact profiles are related to the same base time.
F.2.6 Compact profile with register numbers (orthogonal VIFE = 1Eh)
The Compact profile with register numbers shall be selected if the assignment of a historical value to an
accumulation register number is required.
The first requested register number is coded by the storage number, which is used for the base time, the
base value and the compact profile. The first value inside the compact profile is related to the second
requested register number, the second value to the third register and so on. To support up to 125
register numbers, a coding with a Final DIFEs as specifies in 6.3.5 shall always be used.
A data series may also contain non-periodic entries, e.g. in the case of a changed device status. Such a
case can be transmitted by chaining several profiles (see example).
EXAMPLE Table F.9 and Table F.10 show an absolute profile of monthly consumption values (Tariff 1) of an
electricity meter.
Table F.9 — Example of compact profile with register numbers: Plain data
Event OBIS-Code Date/Time Value

Periodic value 1.8.1*32 01.01.2010 00:00 150 kWh
Non-periodic value 1.8.1*35 25.03.2010 13:12 90 kWh
56
EN 13757-3:2018 (E)
Table F.10 — Example of compact profile with register numbers: M-Bus data records
Data point type Stor. Tariff M-Bus data record
Base time #32 T0 86h 80h 81h 00h 6Dh 00h 00h A0h 41h 11h 35h
Base value #32 T1 84h 90h 81h 00h 03h F0h 49h 02h 00h
8Dh 90h 81h 00h 83h 1Eh 0Ah 34h FEh A0h 86h 01h 00h D0h
Profile 1 (2 values: #33;#34) #32 T1
FBh 01h 00h
Base time #35 T0 C6h 81h 81h 00h 6Dh 0Bh 0Ch 8Dh 59h 13h 0Ch
Base value #35 T1 C4h 91h 81h 00h 03h 90h 5Fh 01h 00h
Base time #36 T0 86h 82h 81h 00h 6Dh 00h 00h 80h 41h 14h 0Dh
Base value #36 T1 84h 92h 81h 00h 03h 50h C3h 00h 00h
Profile 2 (1 value: #37) #36 T1 8Dh 92h 81h 00h 83h 1Eh 06h 34h FEh 00h 71h 02h 00h
F.2.7 Compact profile (orthogonal VIFE = 1Fh)
The compact profiles shall start with the storage number > #0. They may use a flexible number of DIF’s
and DIFE’s. Chained compact profiles use (unlike the compact profiles with register numbers) the next
higher storage number. The use of the storage number #0 is not permitted for compact profiles.
EXAMPLE Tables F.11 and F.12 with incremental load profile; 3 hourly volume values after midnight coded
with BCD.
Table F.11 — Example of compact profile: Plain data
Base value 01.01.2010 00:00 12 300,0 m3

Oldest profile value 01.01.2010 01:00 12 300,3 m3
Second oldest profile value 01.01.2010 02:00 12 300,5 m3
Third oldest profile value 01.01.2010 03:00 12 301,6 m3
Table F.12 — Example of compact profile: M-Bus data records
Base time #8 T0 84h 04h 6Dh 00h 20h 41h 11h
Base value #8 T0 8Bh 04h 15h 00h 30h 12h
Profile #8 T0 8Dh 04h 95h 1Fh 05h 69h 01h 03h 02h 11h
F.2.8 Inverse compact profile (orthogonal VIFE = 13h)
The inverse compact profile (Tables F.13 and F.14) is identical with compact profiles (VIFE = 1Fh)
except the order of data points. For this compact profile the base value is always the youngest value.
57
EN 13757-3:2018 (E)
Table F.13 — Example of inverse compact profile: Plain data
Third youngest value 01.01.2010 00:00 12 300,0 m3
Second youngest value 01.01.2010 01:00 12 300,3 m3
Youngest profile value 01.01.2010 02:00 12 300,5 m3
Base Time/Base value 01.01.2010 03:00 12 301,6 m3
Table F.14 — Example of inverse compact profile: M-Bus data records
Base time #8 T0 84h 04h 6Dh 00h 23h 41h 11h
Base value #8 T0 8Bh 04h 15h 16h 30h 12h
Profile #8 T0 8Dh 04h 95h 13h 05h 69h 01h 11h 02h 03h
Note that in this example the Increment mode in the Profile is set to 01b = Increments, because in the
plain data in Table F.13 the metering values are increasing with the time.
58
EN 13757-3:2018 (E)
Annex G
(normative)
Compact M-Bus frame
G.1 General
Communication channels like radio are limited in capacity of data transfer. The new optional M-Bus-
Compact frame provides an extension of the existing M-Bus Application protocol. It reduces size of
transmitted data up to 40 %, by the separation of the Data Information Fields (DIF/DIFE) and Value
Information Fields (VIF/VIFE) from the M-Bus-data. This is achieved by adding two additional frame
types to the traditional full M-Bus frame:
— M-Bus Compact frame (for the transmission of compact data);
— M-Bus Format frame (for the transmission of Data Information Fields and Value Information
Fields).
The receiver of the M-Bus-Compact frame uses the stored DIF/VIF of an M-Bus-Format frame or full M-
Bus frame in context with the values of the received M-Bus-Compact frame to generate an updated full
M-Bus frame. The suitable M-Bus Format frame can be detected by the Format Signature transmitted in
the M-Bus-Compact frame. The M-Bus-Compact frame shall be used only if the frame structure (order
and coding of data points) remains unchanged for a certain time. If the frame structure changes, an M-
Bus Format frame or a full M-Bus frame shall be transmitted repeatedly until the communication
partner has reliably received it. The communication partner shall check if the stored M-Bus format
frame is outdated by verifying the Full-Frame-CRC with every recovered full M-Bus frame. The original
Full-Frame-CRC is transmitted inside the M-Bus compact frame. It is recommended to repeat the full M-
Bus frame periodically even if the DIF/VIFs of the full M-Bus frame do not change. This provides a
backward compatibility to communication partners that do not support compact M-Bus frames.
The use of the M-Bus-Compact or the M-Bus-Format frame is limited to wireless transmission based on
EN 13757-4.
NOTE The separation of the DIF/VIF (describing unit and resolution of consumption data) from measured
values might be in contradiction with local regulations.
The partial encryption of messages can also be applied for the Compact and Format frame. Be aware
that both the Full-Frame-CRC and the Format Signature are always located in the encrypted part of the
message and will be not readable as long as the applied encryption key is unknown. In case of partial
encryption, the first DIF of the unencrypted part of the message shall not be an idle filler 2Fh.
G.2 CI-fields of the Full and the Compact M-Bus frame

G.2.1 General
The partner may request one of the available frame formats of the wireless meter by applying a special
CI-field (see Table G.1) within the request of user data (REQ-UD2).
59
EN 13757-3:2018 (E)
Table G.1 — CI-fields for the request of Full and Compact and Format M-Bus frame format
Frame CI-fields for the request REQ-UD2
Full M-Bus frame 80h
M-Bus-Compact frame 84h
M-Bus-Format frame 85h
The Full M-Bus frame (Table G.3) shall be supported by each meter, which conforms to this European
Standard. The support of the M-Bus Compact and the M-Bus Format frame is optional. If the meter does
not support the requested frame format it shall response an application error instead (see Table 21).
For the response to a request or for an unsolicited transmission of the wireless meter it marks the
applied frame format by a special CI-field too. Table G.2 shows the related CI-fields for the Full M-Bus
frame as well as for the M-Bus-Compact and the M-Bus-Format frame with all variants of the application
layer header. The content of the short and long header is listed in EN 13757-7:2018, Annex A.
Table G.2 — CI-fields for the full and Compact and Format M-Bus frame format
No data-header Short data-header Long data-header
Full M-Bus frame 78h 7Ah 72h
M-Bus-Compact frame 79h 7Bh 73h
M-Bus-Format frame 69h 6Ah 6Bh

G.2.2 Full M-Bus frame
Table G.3 — Structure of full M-Bus frame
CI Data header DIF [1] VIF [1] Data [1] DIF [2] VIF [2] VIFE [2] Data [2]
The Full M-Bus frame contains all Information of a full M-Bus frame. It can be used to derive an M-Bus
Format frame (Table G.5) including the Format Signature (Table G.4). The Full M-Bus frame can be
transmitted alternative to an M-Bus-Format frame. It provides full backward compatibility but it is even
longer than an M-Bus Format frame.
G.2.3 M-Bus- Compact frame
Table G.4 — Structure of M-Bus-Compact frame
CI Data header Format-Signature Full-Frame-CRC Data [1] Data [2]

The M-Bus Compact frame contains only the data without any Data Information Fields or Value
Information Fields. Immediately after the data header (if existing) follows a 2 byte Format-Signature for
the detection of the related M-Bus Format frame and a 2 byte Full-Frame-CRC for the verification of the
recovered full M-Bus frame. The M-Bus compact frame is intended to be transmitted frequently to
update the communication partner with the current consumption data.
In case of block cipher encryption the remaining bytes of the last block in the M-Bus-Compact frame
shall be filled with value 2Fh.
NOTE The data header contains the AES check bytes if applicable (refer to EN 13757–7:2018, Annex A).
60
EN 13757-3:2018 (E)
G.2.4 M-Bus-Format frame
Table G.5 — Structure of M-Bus-Format frame
CI Data header LF Format-Signature DIF [1] VIF [1] DIF [2] VIF [2] VIFE [2]
The M-Bus Format frame contains no data but Data Information Fields or Value Information Fields of
the M-Bus frame. It shall be transmitted either in case of changed M-Bus format or periodically with a
rare interval. The Format Signature shall be used as identifier to this format frame.
In case of block cipher encryption the remaining bytes of the last block in the M-Bus-Format frame shall
be filled with the value 2Fh. These filler bytes are not included in the length field (LF).
The length field (LF) counts the number of bytes (including the Format Signature) before the idle filler,
which were inserted by the block cipher of the format frame. The default value of the length field is
zero. If no application layer encryption is applied, the length field remains unchanged.
NOTE 1 The length field is in the responsibility of the encryption module.
NOTE 2 The data header contains the AES check bytes if applicable (refer to EN 13757–7:2018, Annex A).
G.3 Calculation of the Full-Frame-CRC

The M-Bus-Compact frame contains a Full-Frame–CRC. The checksum shall be calculated over the full
M-Bus-frame from the first byte of the application data to the end of the last data record (excluding data
header, any AES check bytes in the header and link layer CRC).
The CRC polynomial is: x16 + x13 + x12 + x11 + x10 + x8 + x6 + x5 + x2 + 1
The initial value is: 0
The final CRC is complemented
G.4 Calculation of the Format Signature

The M-Bus Compact frame and the M-Bus Format frame contain a Format Signature. This is a CRC-
Checksum. It shall be calculated only over the M-Bus-Format frame from the first DIF to the last VIF or
DIF (excluding data header, any AES check bytes in the header, Format Signature, length field, any data
bytes, encryption filler bytes in the end and link layer CRC). If the Format Signature is derived from a
full M-Bus frame then an M-Bus Format frame shall be generated first.
The CRC polynomial is: x16 + x13 + x12 + x11 + x10 + x8 + x6 + x5 + x2 + 1
The initial value is: 0
The final CRC is complemented
G.5 Frame examples

G.5.1 General
The following different examples are given to show the relations between the three frame types: Full M-
Bus frame, M-Bus Compact frame and M-Bus Format frame. The meter transmits the following three
data sets:
— Energy = 123,4 Wh;
61
EN 13757-3:2018 (E)
— Volume = 567,8 m3; and
— Power = 901,2 W.
G.5.2 Example without data header
In this example, the frames use the CI-fields without data header. FOS refers to Format Signature, FFC
refers to Full-Frame-CRC and LF refers to length field.
Full M-Bus frame (CI = 78h):
CI DIF VIF Data DIF VIF Data DIF VIF Data
78h 02h 02h D2h 04h 02h 15h 2Eh 16h 02h 2Ah 34h 23h
M-Bus-Format frame (CI = 69h):
CI LF FOS FOS DIF VIF DIF VIF DIF VIF
69h 008h FOS FOS 02h 02h 02h 15h 02h 2Ah
M-Bus-Compact frame (CI = 79h):
CI FOS FOS FFC FFC Data Data Data
79h FOS FOS FFC FFC D2h 04h 2Eh 16h 34h 23h
G.5.3 Example with short data header, no encryption
In this example, the frames use the CI-fields with short data header but no encryption is used. FOS
refers to Format Signature, FFS refers to Full-Frame-CRC and LF refers to length field.
Full M-Bus frame (CI = 7Ah):
CI ACC STS ConfFLD DIF VIF Data DIF VIF Data DIF VIF Data
7Ah 01h 00h 00h 00h 02h 02h D2h 04h 02h 15h 2Eh 16h 02h 2Ah 34h 23h
M-Bus-Format frame (CI = 6Ah):
CI ACC STS ConfFLD LF FOS FOS DIF VIF DIF VIF DIF VIF
6Ah 01h 00h 00h 00h 008h FOS FOS 02h 02h 02h 15h 02h 2Ah
M-Bus-Compact frame (CI = 7Bh):
CI ACC STS ConfFLD FOS FOS FFC FFC Data Data Data
7Bh 01h 00h 00h 00h FOS FOS FFC FFC D2h 04h 2Eh 16h 34h 23h
G.5.4 Example with short data header, encryption mode 5
In this example, the frames use the CI-fields with short data header with the use of encryption mode 5.
FOS refers to Format Signature, FFS refers to Full-Frame-CRC and LF refers to length field. The fields
included in brackets [ ] show the block to be encrypted using encryption mode 5. This example further
shows how partial encrypted frames are handled in M-Bus-Format frames and M-Bus-Compact frames.
Full M-Bus frame (CI = 7Ah):
CI ACC STS ConfFLD AES-CHK DIF VIF Data DIF VIF Data ...
7Ah 01h 00h 10h 05h[2Fh 2Fh 02h 02h D2h 04h 02h 15h 2Eh 16h ...
Filler DIF DIF VIF Data
2Fh 2Fh 2Fh 2Fh 2Fh 2Fh]02h 2Ah 34h 23h
62
EN 13757-3:2018 (E)
M-Bus-Format frame (CI = 6Ah):

CI ACC STS ConfFLD AES-CHK LF FOS FOS DIF VIF DIF VIF DIF ...
6Ah 01h 00h 10h 05h[2Fh 2Fh 0Ch FOS FOS 02h 02h 02h 15h 2Fh ...
DIF DIF DIF DIF DIF Filler DIF DIF VIF
2Fh 2Fh 2Fh 2Fh 2Fh 2Fh] 02h 2Ah
M-Bus-Compact frame (CI = 7Bh):
CI ACC STS ConfFLD AES-CHK FOS FOS FFC FFC Data Data ...
7Bh 01h 00h 10h 05h[2Fh 2Fh FOS FOS FFC FFC D2h 04h 2Eh 16h ...
Filler DIF Data
2Fh 2Fh 2Fh 2Fh 2Fh 2Fh]34h 23h
As shown in the example above, the filler bytes of the Full M-Bus frame are included in the M-Bus-
format frame. This makes it possible to reconstruct the original Full M-Bus frame including filler bytes
and partial encrypted frames.
63
EN 13757-3:2018 (E)
Annex H
(normative)
Translating M-Bus type record descriptors to OBIS-type record descriptors
H.1 General
The following tables are declared to be normative in the sense that if a translation from VIF/DIF values
to OBIS codes is necessary, exactly that translation given in the tables shall be used. It is not meant that
VIF/DIF values shall be used under any circumstances, as OBIS codes can also be transmitted as such.
H.2 Translation of predefined data record types

The following list of Tables H.1 to H.10 describes how a communication partner translates received M-
Bus records into OBIS type records.
The B-Field of the OBIS Code shall be built from the subunit in related DIFE of data point (refer to 6.3.9).
Only when the meter uses one channel the subunit and also the B-Field of the OBIS Code are 0 (as listed
in this table). If a meter uses more than one channel then the subunit and also the B-Field of the OBIS
Code are declared as channel number which starts with 1.
64
EN 13757-3:2018 (E)
Table H.1 — M-Bus to OBIS translation: symbol explanation
Symbol/
Meaning
Bit symbol
M Mandatory (These data objects shall be specified)
Ax Alternatively (At least one of the data objects marked with ‘A’ and an identical number x is mandatory)
O Optional (These data objects do not need to exist)
ssss ssss Status byte, according to EN 13757–7:2018, Table 7
cccc Coding of the data field, according to Table 4 (except real, variable length, selection for readout, special functions)
n One or more bits, according to Tables 10, 12, 13 and 14
VZ Previous recent value(s) 0 ≤ VZ ≤ 99 or 101 ≤ VZ ≤ 125
Definition of the bit of the M-Bus storage number, which is equivalent to the billing period counter (VZ) (see Tables 3 and 8); value range 0
x
to 99 and 101 to 125
65
EN 13757-3:2018 (E)
Table H.2 — M-Bus to OBIS translation: general data (for all devices)
Type OBIS-Code Description DIF/DIFE or fixed fields [binary] VIF/VIFE [binary]

Abstract Value group A = 0 All media
M Error status 0–0:97.97.0*255 Status according to EN 13757–7:2018, Table 15
– Status ssss ssss
M Current time 0–0:0.9.1*255 Local time (Receiving time of communication partner)
– Data object generated automatically by communication partner
M Current date 0–0:0.9.2*255 Local date (Receiving date of communication partner)
– Data object generated automatically by communication partner
M Device address 0–0:96.1.1*255 Device address (assigned by the manufacturer)
– Complete device address (manufacturer, meter ID, version, device type)
O Ownership number 0–0:96.1.9*255 Ownership number/asset identifier (optional)
– Fixed length 0000 cccc 1111 1101 0001 0001
– Variable length 0000 1101 1111 1101 0001 0001
O Metering point ID 0–0:96.1.10*255 Identification of the metering point
– Fixed length 0000 cccc 1111 1101 0001 0000
– Variable length 0000 1101 1111 1101 0001 0000
O Serial number 0–0:96.1.0*255 Serial number (assigned by the manufacturer)
– Fixed length 0000 1100 0111 1000
66
EN 13757-3:2018 (E)
Table H.3 — M-Bus to OBIS translation: electricity meter
Electricity Value group A = 1 02h (see EN 13757–7:2018, Table 13)
A1 Meter count 1–0:1.8.0*255 Active energy import (+A), current valuea

– kWh 10e–6 to 10e+1 0000 cccc 0000 0nnn
– kWh 10e+2 to 10e+3 0000 cccc 1111 1011 0000 000n
– kWh 10e+5 to 10e+6 0000 cccc 1111 1011 1000 000n 0111 1101
O Meter count 1–0:1.8.0*VZ Active energy import (+A), recent valueb
– kWh 10e–6 to 10e+1 1x00 cccc 1000 xxxx 0000 00xx 0000 0nnn
– kWh 10e+2 to 10e+3 1x00 cccc 1000 xxxx 0000 00xx 1111 1011 0000 000n
– kWh 10e+5 to 10e+6 1x00 cccc 1000 xxxx 0000 00xx 1111 1011 1000 000n 0111 1101
A1 Meter count 1–0:2.8.0*255 Active energy export (–A), current valuea
– kWh 10e–6 to 10e+1 0000 cccc 1000 0nnn 0011 1100
– kWh 10e+2 to 10e+3 0000 cccc 1111 1011 1000 000n 0011 1100
1111 1011 1000 000n 1111 1101 0011
– kWh 10e+5 to 10e+6 0000 cccc
1100
O Meter count 1–0:2.8.0*VZ Active energy export (–A), recent valueb

– kWh 10e–6 to 10e+1 1x00 cccc 1000 xxxx 0000 00xx 1000 0nnn 0011 1100
– kWh 10e+2 to 10e+3 1x00 cccc 1000 xxxx 0000 00xx 1111 1011 1000 000n 0011 1100
1111 1011 1000 000n 1111 1101 0011
– kWh 10e+5 to 10e+6 1x00 cccc 1000 xxxx 0000 00xx
1100
O Time of device 1–0:0.9.1*255 Current time at time of transmission
– Type F 0000 0100 0110 1101
O Date of device 1–0:0.9.2*255 Current date at time of transmission
67
EN 13757-3:2018 (E)

– Type G 0000 0010 0110 1100
– Type F 0000 0100 0110 1101
Time, date of Time stamp (local time) of the most recent billing period
O 1–0:0.1.2*255
count (commonly calculated from local date and local time information)
0000 cccc 0111 01nn
O Date of count 1–0:0.1.2*VZ Local date at time of recent meter value, billing periodb
– Type G 1x00 0010 1000 xxxx 0000 00xx 0110 1100
– Type F 1x00 0100 1000 xxxx 0000 00xx 0110 1101
O Time integral 1–0:0.8.2*255 Averaging duration for current power value
– h or min or s 0000 cccc 0111 00nn
a The applied averaging period is provided in 1–0:0.8.2*255.
b Final DIFE shall be according to 6.3.5.
68
EN 13757-3:2018 (E)
Table H.4 — M-Bus to OBIS translation: heat cost allocator
DIF/DIFE or fixed fields

Type OBIS-Code Description VIF/VIFE [binary]
[binary]
HCA Value group A = 4 08h (see EN 13757–7:2018, Table 13)
M Meter count 4–0:1.0.0*255 Unrated integral, current value

– HCA 10e+0 0000 cccc 0110 1110
M Meter count 4–0:1.3.0*255 Unrated integral, set date value
– HCA 10e+0 0100 cccc 0110 1110
– Type F 0000 0100 0110 1101
– Type G 0000 0010 0110 1100
– Type F 0000 0100 0110 1101
Time stamp (local time) of the most recent billing period
O Time, date of count 4–0:0.9.3*255
(commonly calculated from local date and local time information)
0000 cccc 0111 01nn
M Date of count 4–0:0.1.10*255 Local date at set date (target date)
– Type G 0100 0010 0110 1100
O Rating factor 4–x:0.4.0*255 Resulting rating factor, Ka
h(–1) resolution 2(–12) 0000 cccc 1111 1011 0110 1000
O Rating factor 4–x:0.4.1*255 Thermal output rating factor, Kqa

Watt resolution 1 0000 cccc 1111 1011 0110 1001
O Rating factor 4–x:0.4.2*255 Thermal coupling rating factor overall, Kca
resolution 2(–12) 0000 cccc 1111 1011 0110 1010
69
EN 13757-3:2018 (E)

[binary]
O Rating factor 4–x:0.4.3*255 Thermal coupling rating factor room side, Kcra
resolution 2(–12) 0000 cccc 1111 1011 0110 1011
O Rating factor 4–x:0.4.4*255 Thermal coupling rating factor heater side, Kcha
resolution 2(–12) 0000 cccc 1111 1011 0110 1100
O Rating factor 4–x:0.4.5*255 Low temperature rating factor, Kta
resolution 2(–12) 0000 cccc 1111 1011 0110 1101
O Rating factor 4–x:0.4.6*255 Display output scaling factor, KDa
kWh(–1) resolution 2(–12) 0000 cccc 1111 1011 0110 1110
a See also Table 14.
70
EN 13757-3:2018 (E)
Table H.5 — M-Bus to OBIS translation: cooling meter

[binary]
Cooling Value group A = 5 0Ah, 0Bh (see EN 13757–7:2018, Table 13) (Cooling only)
M Meter count 5–0:1.0.0*255 Energy (A), total, current value

– kWh 10e–6 to 10e+1 0000 cccc 0000 0nnn
– kWh 10e+2 to 10e+3 0000 cccc 1111 1011 0000 000n
– kWh 10e+5 to 10e+6 0000 cccc 1111 1011 1000 000n 0111 1101
– GJ 10e–9 to 10e–2 0000 cccc 0000 1nnn
– GJ 10e–1 to 10e+0 0000 cccc 1111 1011 0000 100n
– GJ 10e+2 to 10e+3 0000 cccc 1111 1011 1000 100n 0111 1101
O Meter count 5–0:1.2.0*255 Energy (A), total, set date value
– kWh 10e–6 to 10e+1 0100 cccc 0000 0nnn
– kWh 10e+2 to 10e+3 0100 cccc 1111 1011 0000 000n
– kWh 10e+5 to 10e+6 0100 cccc 1111 1011 1000 000n 0111 1101
– GJ 10e–9 to 10e–2 0100 cccc 0000 1nnn
– GJ 10e–1 to 10e+0 0100 cccc 1111 1011 0000 100n
– GJ 10e+2 to 10e+3 0100 cccc 1111 1011 1000 100n 0111 1101
O Power 5–0:8.0.0*255 Power (energy flow) (P), average, current valuea

– W 10e–3 to 10e+4 0000 cccc 0010 1nnn
– kJ/h 10e–3 to 10e+4 0000 cccc 0011 0nnn
O Flow rate 5–0:9.0.0*255 Flow rate, average (Va/t), current value
– m3/h 10e–6 to 10e+1 0000 cccc 0011 1nnn
71
EN 13757-3:2018 (E)

[binary]
– Type F 0000 0100 0110 1101
– Type G 0000 0010 0110 1100
– Type F 0000 0100 0110 1101
0000 cccc 0111 01nn
O Date of count 5–0:0.1.10*255 Local date at set date
– Type G 0100 0010 0110 1100
72
EN 13757-3:2018 (E)
Table H.6 — M-Bus to OBIS translation: combined heat and cooling meter

0Dh (cooling)
Cooling Value group A = 5 (Combined heat/cooling)
(see EN 13757–7:2018, Table 13)
– kWh 10e–6 to 10e+1 1000 cccc 0001 0000 0000 0nnn
– kWh 10e+2 to 10e+3 1000 cccc 0001 0000 1111 1011 0000 000n
– kWh 10e+5 to 10e+6 1000 cccc 0001 0000 1111 1011 1000 000n 0111 1101
kWh 10e–6 to 10e+1 0000 cccc 1000 0nnn 0011 1100
kWh 10e+2 to 10e+3 0000 cccc 1111 1011 1000 000n 0011 1100
kWh 10e+5 to 10e+6 0000 cccc 1111 1011 1000 000n 1111 1101 0011 1100
– GJ 10e–9 to 10e–2 1000 cccc 0001 0000 0000 1nnn
– GJ 10e–1 to 10e+0 1000 cccc 0001 0000 1111 1011 0000 100n
– GJ 10e+2 to 10e+3 1000 cccc 0001 0000 1111 1011 1000 100n 0111 1101
GJ 10e–9 to 10e–2 0000 cccc 1000 1nnn 0011 1100
GJ 10e–1 to 10e+0 0000 cccc 1111 1011 1000 100n 0011 1100
GJ 10e+2 to 10e+3 0000 cccc 1111 1011 1000 100n 1111 1101 0011 1100
– kWh 10e–6 to 10e+1 1100 cccc 0001 0000 0000 0nnn
– kWh 10e+2 to 10e+3 1100 cccc 0001 0000 1111 1011 0000 000n
– kWh 10e+5 to 10e+6 1100 cccc 0001 0000 1111 1011 1000 000n 0111 1101
– kWh 10e–6 to 10e+1 0100 cccc 1000 0nnn 0011 1100
– kWh 10e+2 to 10e+3 0100 cccc 1111 1011 1000 000n 0011 1100
– kWh 10e+5 to 10e+6 0100 cccc 1111 1011 1000 000n 1111 1101 0011 1100
– GJ 10e–9 to 10e–2 1100 cccc 0001 0000 0000 1nnn
73
EN 13757-3:2018 (E)

– GJ 10e–1 to 10e+0 1100 cccc 0001 0000 1111 1011 0000 100n
– GJ 10e+2 to 10e+3 1100 cccc 0001 0000 1111 1011 1000 100n 0111 1101
– GJ 10e–9 to 10e–2 0100 cccc 1000 1nnn 0011 1100
– GJ 10e–1 to 10e+0 0100 cccc 1111 1011 1000 100n 0011 1100
– GJ 10e+2 to 10e+3 0100 cccc 1111 1011 1000 100n 1111 1101 0011 1100

– W 10e–3 to 10e+4 1000 cccc 0001 0000 0010 1nnn
– kJ/h 10e–3 to 10e+4 1000 cccc 0001 0000 0011 0nnn
– m3/h 10e–6 to 10e+1 1000 cccc 0001 0000 0011 1nnn

– Type F 1000 0100 0001 0000 0110 1101
– Type G 1000 0010 0001 0000 0110 1100
– Type F 1000 0100 0001 0000 0110 1101
O 5–0:0.9.3*255
0000 cccc 0111 01nn
– Type G 1100 0010 0001 0000 0110 1100
– h or min or s 1000 cccc 0001 0000 0111 00nn
This table consists of the cooling meter counts of combined heat/cooling meters (Device Type = 0Dh). Refer to heat meter for heat meter counts.
74
EN 13757-3:2018 (E)
Table H.7 — M-Bus to OBIS translation: heat meter

04h, 0Ch, 0Dh (heat) (see EN 13757–7:2018, (Heat only and combined
Heat Value group A = 6
Table 13) heat/cooling)

– kWh 10e–6 to 10e+1 0000 cccc 0000 0nnn
– kWh 10e+2 to 10e+3 0000 cccc 1111 1011 0000 000n
1111 1011 1000 000n 0111
– kWh 10e+5 to 10e+6 0000 cccc
1101
– GJ 10e–9 to 10e–2 0000 cccc 0000 1nnn
– GJ 10e–1 to 10e+0 0000 cccc 1111 1011 0000 100n
1111 1011 1000 100n 0111
– GJ 10e+2 to 10e+3 0000 cccc
1101
– kWh 10e–6 to 10e+1 0100 cccc 0000 0nnn
– kWh 10e+2 to 10e+3 0100 cccc 1111 1011 0000 000n
1111 1011 1000 000n 0111
– kWh 10e+5 to 10e+6 0100 cccc
1101
– GJ 10e–9 to 10e–2 0100 cccc 0000 1nnn
– GJ 10e–1 to 10e+0 0100 cccc 1111 1011 0000 100n
1111 1011 1000 100n 0111
– GJ 10e+2 to 10e+3 0100 cccc
1101

– W 10e–3 to 10e+4 0000 cccc 0010 1nnn
– kJ/h 10e–3 to 10e+4 0000 cccc 0011 0nnn
75
EN 13757-3:2018 (E)
– m3/h 10e–6 to 10e+1 0000 cccc 0011 1nnn

– Type F 0000 0100 0110 1101
– Type G 0000 0010 0110 1100
– Type F 0000 0100 0110 1101
O 6–0:0.1.2*255
0000 cccc 0111 01nn
– Type G 0100 0010 0110 1100
76
EN 13757-3:2018 (E)
Table H.8 — M-Bus to OBIS translation: gas meter

[binary]
Gas Value group A = 7 03h (see EN 13757–7:2018, Table 13)
A1 Meter count 7–0:3.0.0*255 Volume (meter), metering conditions (Vm), forward, absolute, current value
– m3 10e–6 to 10e+1 0000 cccc 1001 0nnn 0011 1010
– m3 10e–3 to 10e+4 0000 cccc 1001 0nnn 1111 1101 0011 1010
A1 Meter count 7–0:3.1.0*255 Volume (meter), temperature converted (Vtc), forward, absolute, current value
– m3 10e–6 to 10e+1 0000 cccc 0001 0nnn
– m3 10e–3 to 10e+4 0000 cccc 1001 0nnn 0111 1101
A1 Meter count 7–0:3.2.0*255 Volume (meter), base conditions (Vb), forward, absolute, current value
– m3 10e–6 to 10e+1 0000 cccc 1001 0nnn 0011 1110
– m3 10e–3 to 10e+4 0000 cccc 1001 0nnn 1111 1101 0011 1110
O Meter count 7–0:3.0.0*VZ Volume (meter), metering conditions (Vm), forward, absolute, recent valued
– m3 10e–6 to 10e+1 1x00 cccc 1000 xxxx 0000 00xx 1001 0nnn 0011 1010
– m3 10e–3 to 10e+4 1x00 cccc 1000 xxxx 0000 00xx 1001 0nnn 1111 1101 0011 1010
O Meter count 7–0:3.1.0*VZ Volume (meter), temperature converted (Vtc), forward, absolute, recent valued
– m3 10e–6 to 10e+1 1x00 cccc 1000 xxxx 0000 00xx 0001 0nnn
O Meter count 7–0:3.2.0*VZ Volume (meter), base conditions (Vb), forward, absolute, recent valued
77
EN 13757-3:2018 (E)

[binary]
– m3 10e–3 to 10e+4 1x00 cccc 1000 xxxx 0000 00xx 1001 0nnn 1111 1101 0011 1110
O Flow rate 7–0:43.15.0*255 Flow rate at metering conditions, averaging period 1 (default period 5 min), current interval (Vm/t1)a
– m3/h 10e–6 to 10e+1 0000 cccc 1011 1nnn 0011 1010
O Flow rate 7–0:43.63.0*255 Flow rate at metering conditions, averaging period 4 (no default value), current interval (Vm/t1)a
– m3/h 10e–6 to 10e+1 0000 cccc 1011 1nnn 0011 1010
O Flow rate 7–0:43.16.0*255 Flow rate, temperature converted, averaging period 1 (default period 5 min), current interval (Vtc/t1)b
– m3/h 10e–6 to 10e+1 0000 cccc 0011 1nnn
O Flow rate 7–0:43.64.0*255 Flow rate, temperature converted, averaging period 4 (no default value), current interval (Vtc/t1)b
– m3/h 10e–6 to 10e+1 0000 cccc 0011 1nnn
O Flow rate 7–0:43.17.0*255 Flow rate at base conditions, averaging period 1 (default period 5 min), current interval (Vb/t1)c
– m3/h 10e–6 to 10e+1 0000 cccc 1011 1nnn 0011 1110
O Flow rate 7–0:43.65.0*255 Flow rate at base conditions, averaging period 4 (no default value), current interval (Vb/t1)c
– m3/h 10e–6 to 10e+1 0000 cccc 1011 1nnn 0011 1110
O Base temperature 7–0:41.2.0*255 defined Temperature, absolute, at base conditions (Tb) or for conversion (Ttc)
– °C 10e–3 to 10e+0 0000 cccc 1101 10nn 0011 1110
O Base pressure 7–0:42.2.0*255 defined Pressure, absolute, at base conditions (pb)
– bar 10e–3 to 10e+0 0000 cccc 1110 10nn 0011 1110

– bar 10e–6 to 10e–3 0000 cccc 1110 10nn 1111 0011 0011 1110
– Type F 0000 0100 0110 1101
78
EN 13757-3:2018 (E)

[binary]
– Type G 0000 0010 0110 1100
– Type F 0000 0100 0110 1101
O Time, date of count 7–0:0.1.2*255 Time stamp (local time) of the most recent billing period
0000 cccc 0111 01nn
O Date of count 7–0:0.1.2*VZ Local date at time of recent meter value, billing period 1 (default value = 1 day) d
– Type G 1x00 0010 1000 xxxx 0000 00xx 0110 1100
– Type F 1x00 0100 1000 xxxx 0000 00xx 0110 1101
O Time integral 7–0:0.8.28*255 Averaging period for current flow rate value
a If the data point 7–0:0.8.28*255 is present the OBIS-Code 7–0:43.63.0ˣ255 (no default averaging value) applies. Otherwise the OBIS-Code 7–0:43.15.0ˣ255
(averaging period 1) applies.
b If the data point 7–0:0.8.28*255 is present the OBIS-Code 7–0:43.64.0ˣ255 (no default averaging value) applies. Otherwise the OBIS-Code 7–0:43.16.0ˣ255
c If the data point 7–0:0.8.28*255 is present the OBIS-Code 7–0:43.65.0ˣ255 (no default averaging value) applies. Otherwise the OBIS-Code 7–0:43.17.0ˣ255
d Final DIFE shall be according to 6.3.5.
79
EN 13757-3:2018 (E)
Table H.9 — M-Bus to OBIS translation: water meter (cold)

Cold Water Value group A = 8 07h (see EN 13757–7:2018, Table 13)
M Meter count 8–0:1.0.0*255 Volume (V), accumulated, total, current value

– m3 10e–6 to 10e+1 0000 cccc 0001 0nnn
– m3 10e–3 to 10e+4 0000 cccc 1001 0nnn 0111 1101
O Meter count 8–0:1.2.0*255 Volume (V), accumulated, total, set date value
– m3 10e–6 to 10e+1 0100 cccc 0001 0nnn
– m3 10e–3 to 10e+4 0100 cccc 1001 0nnn 0111 1101
O Flow rate 8–0:2.0.0*255 Flow rate, average (Va/t), current valuea
– m3/h 10e–6 to 10e+1 0000 cccc 0011 1nnn

– Type F 0000 0100 0110 1101
– Type G 0000 0010 0110 1100
– Type F 0000 0100 0110 1101
(commonly calculated from local date and local time infomation)
0000 cccc 0111 01nn
– Type G 0100 0010 0110 1100
O Time integral 8–0:0.8.6*255 Averaging duration for current flow rate value
80
EN 13757-3:2018 (E)
Table H.10 — M-Bus to OBIS translation: water meter (hot, warm)

Hot Water Value group A = 9 06h, 15h (see EN 13757–7:2018, Table 13)
M Meter count 9–0:1.0.0*255 Volume (V), accumulated, total, current value

– m3 10e–6 to 10e+1 0000 cccc 0001 0nnn
– m3 10e–3 to 10e+4 0000 cccc 1001 0nnn 0111 1101
O Meter count 9–0:1.2.0*255 Volume (V), accumulated, total, set date value
– m3 10e–6 to 10e+1 0100 cccc 0001 0nnn
– m3 10e–3 to 10e+4 0100 cccc 1001 0nnn 0111 1101
O Flow rate 9–0:2.0.0*255 Flow rate, average (Va/t), current value a
– m3/h 10e–6 to 10e+1 0000 cccc 0011 1nnn

– Type F 0000 0100 0110 1101
– Type G 0000 0010 0110 1100
– Type F 0000 0100 0110 1101
0000 cccc 0111 01nn
– Type G 0100 0010 0110 1100
O Time integral 9–0:0.8.6*255 Averaging duration for current flow rate value
81
EN 13757-3:2018 (E)
H.3 Online addition of an entry for the M-Bus to OBIS conversion table
When a meter uses an M-Bus data point, which is not declared in O.1 “Translation of predefined data
record types” in this draft European standard and which is required for billing, then it should assign the
suggested concerning OBIS code for this data point as static data by this special data point. This OBIS
declaration should be sent as static data (refer to EN 13757-7:2018, Table 20).
The OBIS declaration uses the original DIF/VIF-combination of the declared M-Bus data point added by
the orthogonal VIFE “OBIS declaration” (3Fh so far reserved). The value of this new data point consists
of the assigned OBIS code. The OBIS code may be coded as BCD or binary value. The content of the low
nibble of the original DIF (bold marked) is replaced by length and coding of OBIS code.
The binary value for the OBIS code is always unsigned. Use binary coding if OBIS value group F > 99.
For example, in the case of the max. flow rate of a water meter:
A water meter supports a maximum flow rate value e.g. 0,123 m3/h. The M-Bus data point for max. flow
rate is coded as e.g.:
1Ah DIF; maximum value; 4 digits BCD
3Bh VIF; Flow rate with unit 10−3 m3/h
23h 01h Value 123
The relevant OBIS declaration 8–0:2.5.0*255 will be transmitted either binary or with BCD-numbers.
BCD coding:
The relevant OBIS declaration will be transmitted as 12 digits BCD by:
1Eh DIF; maximum value; 12 digits BCD
BBh VIF; Flow rate with unit 10−3 m3/h; VIFE follows
3Fh VIFE “OBIS declaration”
AAh 00h 05h 02h 00h 08h Value; OBIS code 8–0:2.5.0*255
NOTE The BCD Value “AA” in OBIS value group F signals an invalid value (refer to Annex A). This corresponds
to a current value indicated by 255.
Binary coding:
Alternatively, the relevant OBIS declaration will be transmitted, e.g. as 48-bit binary, by:
16h DIF; maximum value; 48 bit binary
BBh VIF; flow rate with unit 10−3 m3/h; VIFE follows
3Fh VIFE; “OBIS declaration”
FFh 00h 05h 02h 00h 08h Value; OBIS code 8–0:2.5.0*255
82
EN 13757-3:2018 (E)
Annex I
(normative)
Image Transfer
I.1 Image Transfer Phases

I.1.1 General
Image transfer makes it possible to transfer large amount of new generic data like new software, or
configuration tables or tariff information to a device. When image download is performed, then an
image is transferred from a Communicating partner to one or more devices. This may be the meter or a
communications interface attached to the meter. The generic term device is used for the remainder of
this section. The transfer of an image consists of a number of phases, of which some are optional. The
phases are:
— transfer preparation;
— transfer synchronization;
— transfer of image;
— image validation;
— image activation.
Image Transfer is performed using frames with a specific sub-range of CI-fields. The Image Transfer
service is applicable to any device using an M-bus transport protocol. The Image Transfer service is
applicable to, but not constrained, to the M-bus Application Layer. The Image Transfer capability is
Application Layer agnostic, i.e. it may be used for any type of Application Layer.
NOTE Other Application Layer protocols, like DLMS/COSEM, may as well take advantage of the Image
Transfer service.
The details of the different phases are listed in the subsequent sections. An overview of the whole
process is displayed in I.3.
A device may have the capability to enable/disable Image Transfer. Enabling of Image Transfer could be
based on the prior consent of the device user.
It is assumed that users of the receiving device are informed about a download. As precondition an
image download operation should be agreed between the responsible partners by enablement of such
operation. The management of enablement or disablement in a device, including authorization of
partners, is outside the scope of this standard.
I.1.2 Transfer Preparation
This phase is optional. The purpose of this phase is to ensure that the intended receivers of the image
are ready to receive the image at the intended time of transfer. The phase consists of a number of
individually addressed data exchanges between the Communication partner and each of the intended
individual receiving devices. The result of this phase is that the intended receiving devices have
received information about:
— what data will be exchanged,
83
EN 13757-3:2018 (E)
— how data will be exchanged,
— when the data will be exchanged,
— how the data can be validated.
This exchange takes place using command as specified in I.2.4 and I.2.5. The intended receivers are,
when this phase is over, ready to optionally synchronize and then receive the image.
I.1.3 Transfer Synchronization
This phase is optional. The purpose of this phase is to ensure that all of the intended receivers are ready
to receive the image during the transfer phase. The communication partner is transmitting the
synchronization command one or more times. A device that receives a synchronization command once
may be idle until start of image transfer. Commands for initiating and performing the synchronization
are specified in I.2.6.
The meter should open up a reception window which is long enough to catch the synchronization
command, prior to the image transfer e.g.: 10 s before. It is recommended that the gateway provides the
synchronization command sufficiently repeated, e.g.: each one or two seconds.
I.1.4 Image Transfer
This phase is mandatory. The purpose of this phase is to achieve that the intended receivers have
received all the image blocks with full integrity. The phase can be subdivided into the following
elements that may be executed iteratively.
NOTE 1 This takes into account that the Communicating partner will multicast, then check for reception, and
based on this, again multicast a subset of missing blocks, check for reception once more, and so on.
— Transfer of the image. The image is divided into blocks that fit the frame size of the transport
protocol. Transfer is performed one block at a time until all of the blocks in the image have been
transferred. The transfer may be repeated one or more times. This is an activity common to all of
the intended receivers. The Communicating partner will transfer the image to all of the intended
receivers at one time. In case of a multicast the transfer is a no-reply type of transfer (SND-UD3).
The image content structure is out of scope of this standard. The transfer takes place using
commands specified in I.2.7.
— Verification of the reception of the received blocks (of the image). This is an activity individual to
each of the intended receivers. The Communicating partner shall, for each image transferred collect
status individually from each of the intended receivers. The image may be transmitted multiple
times before the status is collected from the intended receivers. The verification takes place using
commands specified in I.2.8.
— Calculation of the number of outstanding blocks and selection of blocks to be (re)transferred in

next attempt until the full image has been transferred to all of the intended receivers. This is an
activity performed by the communicating partner. The way this is implemented is manufacturer
specific and outside the scope of this standard. The activity is based on the commands and
responses specified in I.2.9 and I.2.10.
The intended result of this phase is that the full image, i.e. all of the blocks of the image has been
received by all of the intended receivers, and that the integrity of the overall image has been secured.
NOTE 2 From a complexity point of view it may be easier just to send the image multiple times instead of
checking the individual receivers. A receiver can, if it already has received a block, just skip the reception.
84
EN 13757-3:2018 (E)
NOTE 3 The verification of the reception of the blocks of an image can cause the communicating partner to
‘drop’ one or more of the intended receivers during this phase, if they are not able to receive the blocks reliably.
I.1.5 Image Validation
This phase is mandatory. The purpose of this phase is to validate the image received, i.e. that:
— The entire image has been received. An intended receiver shall discard further processing in this
phase if not all of the image has been received. The integrity and authenticity of the image may be
ensured. This could be achieved by calculating an overall authentication code (MAC) and comparing
it to a stored value previously received.
— The image is intended for the receiver (device). This could include that Image identifier field
(name) of the image and the versions of the image are acceptable to the receiver (meter),
information that may be a part of the internal structure of the image.
— The receiver (device) is in such a state that it is able to activate the image. This could include that
the installed options and the current version of the software and hardware of the receiver support
the activation.
The intended result of this phase is that the receiver (device) has validated the received image as
applicable. A failure of the validation should make the receiver discard the image and report this in its
status information. The detailed activities to perform are manufacturer specific and outside the scope of
this standard. Command initiate the validation in a device and get the status from a device are specified
in I.2.10, I.2.11 and I.2.12. The validation may be started implicitly.
I.1.6 Image Activation
This phase is mandatory. The purpose of this phase is to make the image transferred an active part in
the device. The way this phase is executed is manufacturer specific and outside the scope of this
standard. The intended result of this phase is that the new data are active. A failure of the activation
should let the device be re-activated using a previous or default version of the image. A command that
may be used to activate an image in a device is specified in I.2.15 and I.2.16.
I.2 Commands for Image Transfer

I.2.1 General
Commands for Image Transfer and the corresponding response are identified by specific values of the
CI-field. The applicable CI-fields are listed in Table I.1:
Table I.1 — Image Transfer CI-fields
CI-field Designation Header Remarks

C0h Command to device Long Image Transfer Application
C1h Response from device Short Image Transfer Application
C2h Response from device Long Image Transfer Application

I.2.2 Command and response structure
A message may hold more than one image transfer command. Each command is stored as a segment
and shall have a structure as depicted in Table I.2 below. The segment ID makes it possible to link the
commands and the corresponding responses.
85
EN 13757-3:2018 (E)
Table I.2 — Internal structure of Image Transfer Command
Segment Length Segment ID Function field Sub-function field

Function parameters
(SL) (SID) (F) (SF)
2 bytes 1 byte 1 byte 1 byte n bytes
The different elements are:
Segment Length: Length of this command segment
Segment ID Identifier of the segment
Function Field: Coding of the command (see Table I.4).
Sub-function Field: Optional, control bits for command execution and optional parameters.
The detailed interpretation of this field depends on the function field.
Function parameters: Optional elements holding command specific data.
A response frame holds the concatenated result of the commands sent to a device in the foregoing
command frame. The structure of the response frame is depicted in Table I.3 below.
Table I.3 — Internal structure of Image Transfer Response
Segment Length Segment ID Function field Sub-function field

Function parameters
(SL) (SID) (F) (SF)
2 bytes 1 byte 1 byte 1 byte n bytes
The different elements are:
Segment Length: Length this response segment
Segment ID: Identifier of command segment generating this response
Function Field: Coding of the command responding to (see Table I.4)
Sub-function Field: Control bits for the response and optional parameters.
The detailed interpretation of this field depends on the function field.
Function parameter(s): This optional field holds response specific data.
The segment Length is a multiple byte field. Function parameters may also contain multi byte fields. If
nothing other is declared then multi byte fields shall be transmitted with the least significant byte first
(little endian).
I.2.3 Function Field
The function field for an image transfer command shall have one of the values listed in Table I.4.
86
EN 13757-3:2018 (E)
Table I.4 — Image Download Command/Response, Function Field
Function field Function CMD Resp. Multia Explanation
00h/80hb Prepare X X Send parameters for the download session
01h Synchronize X X Synchronize state prior to the transfer

02h/82h Transfer X X X Transfer the blocks of the image
03h/83h Completion X X Verify completion of transfer
04h/84h State X X Request current download state in the device
05h/85h Validate X X X Validate the received image
06h/86h Activate X X X Activate the image
07h/87h Terminate X X X Terminate current phase or process
08h/88h Active Images X X Retrieve list of active images
09h to 6Fh/ 89h

Reserved Reserved for Future Use
to EFh
70h to 7Fh/ F0h Manufacture

X X X Manufacturer specific commands
to FFh specific
a Whether or not the command is applicable to multicast use as well. There is no response to a multicast
command. Protection has to be taken into account for multicast messages.
b Most significant bit set indicates a response
The different commands are specified in the sections that follow.

I.2.4 Prepare command
I.2.4.1 General
The command sets up the condition for the image transfer. The structure of the command and the order
of the fields is shown in Table I.5 below. The function has the sub-function as the initial field. This may
be followed by optional fields, controlled by the bit mask in the sub-function.
Table I.5 — Prepare command structure
Image
Sub- Date and Size
Function Pace identifier MAC field Add. Info
function Time information
field (optional) field (optional) (optional)
field (optional) (optional)
(optional)
00h 1 byte 4 bytes 1 byte 5 bytes 8 bytes 19 bytes 2 bytes
The assignment of the different bits in the sub-function field is shown in Table I.6 below:
Table I.6 — Prepare command sub-function
b7 b6 b5 b4 b3 b2 b1 b0
RFU RFU INFO MCAS IDEN SZIN ADT MAC
RFU Reserved for future use, set to 0
87
EN 13757-3:2018 (E)
INFO: Additional Information. If this bit is set then the command contains an Additional Information
field.
MCAS: Multicast. If this bit is set then the transfer of image will be done using multicast and the
command contains the fields Date and Time and Pace.
IDEN: Image Identifier. If this bit is set then an Image identifier field is part of the command. The
identity information field makes it possible to detect the proper frames during
synchronization and transfer phases.
SZIN: Size information. If this bit is set then a Size information field is part of the command. The field
specifies the size of the image, the size of the individual blocks and the number of times the
multicast will be repeated.
ADT: Absolute date and time. If this bit is set the Date and Time field is given as an absolute date and
time. If this bit cleared Date and Time is given as a relative value, the time from now until start.
MAC: Message Authentication Code. If this bit is set, a field holding device specific MAC over the full
image is part of the command.
A more detailed description of the different fields follows in the next subclauses.
I.2.4.2 Image Identifier field
This field is an identification of the data/image to be distributed. It is, in case of multiple broadcasts,
used by the device to reject image transfer frames which are not part of the current transfer for this
device. It is structured according Table I.7.
Table I.7 — Structure of Image Identifier field
Manufacturer Manufacturer
Version Device type
(LSB first) Image Identifier
2 bytes 1 byte 1 byte 4 byte
Manufacturer: Manufacturer identification according EN 13757–7:2018, 7.5.2

Version: Version identification according EN 13757–7:2018, 7.5.3
Device type: Device type information according EN 13757–7:2018, 7.5.4
Manufacturer image These four bytes are manufacturer specific. Every image as delivered by the
identifier: manufacturer shall have a unique number.
The image identifier is not necessarily linked to the image content. Manufacturers should take care
about the uniqueness and freshness of the Image identifier field for each new image transfers to devices
located in multiple systems range coverage.
I.2.4.3 Date and Time field
This field holds the time when the synchronization or transfer will start. It indicates to the device when
it shall be ready. It is a 4 bytes field, coded LSB first. The field contains, if the ADT bit in Sub-function is
set, the absolute Date and Time for start, in EPOCH 2013, otherwise the field contains the number of
seconds, to wait from on the end of the reception of the frame before, to start.
The EPOCH 2013 time format corresponds to 0Dh 6Dh E5h xx xx xx xx 20h according to Annex A,
Type M.
88
EN 13757-3:2018 (E)
I.2.4.4 Pace
This field holds the time value between 2 blocks transmission. It is measured from start block to start
block. Unit is seconds.
NOTE Detailed timing is described in 13757–4.
I.2.4.5 Size Information field
This field is 5 bytes. It holds information about the size of the data to be distributed. This is subdivided
into the following:
— Total number of blocks, 2 bytes,
— size of the individual blocks in bytes, 2 bytes,
— number of times the multicast will be repeated, before a check of status is performed, 1 byte. Set to
zero if multicast is not used,
It is structured according Table I.8.

Table I.8 — Structure of size information field
Total number of blocks Individual block size

Repetition
(LSB first) (LSB first)
2 bytes 2 bytes 1 byte
I.2.4.6 MAC field
This field holds a pre-calculated Message Authentication Code of the image, using the individual device
specific key. This is for validation of the integrity of the transmitted image to the M-Bus device
NOTE end-to-end security of the image, between the original distributor or creator of the image and the M-
Bus device may be additionally provided by other means. This is outside the scope of this specification.
The MAC field itself consists of two sub-fields as shown in Table I.9 below
Table I.9 — Structure of MAC field
MAC Algorithm ID Key ID Key Version MAC Value

1 byte 1 byte 1 byte 16 bytes
The first byte indicates which MAC algorithm will be used. The second and third byte identify the
individual device specific key, and version of the key, that shall be used in the MAC calculation. The last
16 bytes contain the MAC Value.
Key ID Identifies the key that is used in the MAC calculation. The exact use of the key is dependent
on the particular MAC algorithm. The Key ID is as defined in EN 13757-7.
Key Version Key version is as defined in EN 13757-7 and identifies the version of the key. Shall be FFh if
no version is used.
The following MAC algorithms, shown in Table I.10, are currently specified:
89
EN 13757-3:2018 (E)
Table I.10 — MAC Algorithms
MAC Algorithm ID MAC Algorithm

01h 8 byte truncated HMAC-SHA256a
02h 16 byte truncated HMAC-SHA256
03h 8 byte truncated AES128-CMACa
04h 16 bytes AES128-CMAC
05h 12 bytes AES128-GMACa
a The MAC and therefore also the MAC field has a fixed length i.e. used in the Prepare
Command. In case of other MAC lengths see the hints how to fill up the MAC field in the
following sections.
Truncated HMAC Algorithms
The HMAC algorithm shall be used as specified in FIPS PUB 198-1. The SHA256 algorithm shall be used
as specified in FIPS PUB 180-4.
MAC: The output of the HMAC-SHA256 algorithm shall be truncated to 8 or 16 bytes as indicated by
the MAC Algorithm ID field. Truncation shall be applied as described in Clause 5 in NIST/SP 800-107
Revision 1, also taking into account the security consequences of truncation. The MAC value is
transmitted MSB first (big endian). In case the MAC is truncated to 8 bytes, the first 8 bytes of the MAC
Value field will be filled with the truncated HMAC-SHA256 value and the last 8 bytes will contain 00h.
CMAC and Truncated CMAC Algorithm
The use of the AES128-CMAC or truncated AES128-CMAC is indicated by the MAC Algorithms ID field,
i.e. value 04h or 03h respectively. The CMAC value or truncated CMAC value shall be calculated
according to NIST/SP 800-38B.
MAC: This field contains the truncated CMAC value or full CMAC value depending on the value of the
MAC Algorithm ID (03h or 04h respectively). The CMAC value is transmitted MSB first (big endian). In
case an 8 bytes truncated CMAC is used, the first 8 bytes of the MAC Value field will be filled with the
truncated AES128-CMAC value and the last 8 bytes will contain 00h.
AES128-GMAC Algorithm
The use of the AES128-GMAC algorithms is indicated by the value 05h in the MAC Algorithm ID field.
The AES128-GMAC algorithm shall be applied according to NIST/SP 800-38D.
MAC: In this case the MAC value shall be the Authentication Tag (T) and has a fixed length of
12 bytes. The first 12 bytes of the MAC Value will contain this Authentication Tag and the last 4 bytes
will contain 00h.
The AES128-GMAC algorithm uses an initialization vector IV as indicated in Table I.11
Table I.11 — GMAC Initialization Vector (IV)
Fixed Field Invocation Field

11 10 9 8 7 6 5 4 3 2 1 0
Manufacturer Device
Identification number (LSB first) Version Manufacturer Image Identifier
(LSB first) Type
The Manufacturer Image Identifier is the invocation field in the IV. The Manufacturer Image Identifier is
part of the Image Identifier field and is defined in I.2.4.2
90
EN 13757-3:2018 (E)
I.2.4.7 Additional Information
The field is optional. It holds additional information defined by the manufacturer. The internal structure
of this 2 bytes field is manufacturer specific.
I.2.5 Prepare response
This is the response to the Prepare command. The structure is shown in Table I.12 below: The optional
fields are controlled by the bit mask in the sub-function field.
Table I.12 — Structure of Prepare response
Image
Additional
Function Sub-function Preparation Identifier Size Information
Information
Field field Result field (optional)
(optional)
(optional)
80h 1 byte 1 byte 8 bytes 5 bytes 2 bytes
The content of the sub-function field shall be interpreted as depicted in Table I.13.
Table I.13 — Prepare response sub-function
b7 b6 b5 b4 b3 b2 b1 b0
RFU RFU INFO MCAS IDEN RDY SZIN AINF
RFU: Reserved for future use, set to 0 set to 0

AINF: Additional Information. If this bit is set then a 2 bytes Additional Info field follows. The
internal structure is manufacturer specific.
MCAS: Multicast. When this bit is set, the device is able to handle multicast.
IDEN If this bit is set then an Image identifier field is part of the response. The field is formatted as
described in I.2.4.2. If this field was present in the prepare command, then it shall also be
present in the prepare response.
RDY: Ready. When this bit is cleared, the device is enabled / ready for software download.
SZIN: Size information. When this bit is cleared the device is able to handle the requested size as
specified in the command. Otherwise this bit will be set and the Size information field is
present (see I.2.4.5). It will then provide information about the supported block size and
number of the meter
The content of the Preparation Result field shall be interpreted as depicted in Table I.14.
In case the Preparation Result field indicates that the Image size is too big (value 06h), the SZIN bit may
be set in the sub-function field and the size information field will then be included in the response and
indicate the image size that the M-Bus device supports.
91
EN 13757-3:2018 (E)
Table I.14 — Preparation results
Value Description
00h No error detected, preparation command accepted
01h SW update version not accepted

02h Minimum SW version not compliant
03h Minimum HW version not compliant
04h SW update disabled for device
05h Image type/update protocol not supported
06h Image size too big
07h Any other error
08h–FFh RFU, set to 0

I.2.6 Synchronize Command
I.2.6.1 General
The command is used for synchronization of the image transfer. It may be sent one or more times
before the start of the image transfer to handle compensation for clock uncertainty between receiving
device and communication partner providing the image. This command is only applicable to wireless
communication. It shall be sent unidirectional. A reply is not expected.
The structure of the command and the order of the fields are shown in Table I.15 below. The function
has the sub-function as the initial field. This may be followed by optional fields, controlled by the bit
mask in the sub-function.
Table I.15 — Synchronize command structure
Image identifier field

Function field Sub-function field Count Down
(optional)
01h 1 byte 8 bytes 2 bytes
See I.2.4.2 for Image identifier field definition.
Table I.16 — Synchronize command sub-function
b7 b6 b5 b4 b3 b2 b1 b0
RFU RFU RFU RFU IDEN CTDN
RFU: Reserved for future use, set to 0

IDEN: Identity information. This bit is set if an Image identifier field field follows. The field is
formatted as shown in I.2.4.2. Identity information may be omitted but this is not
recommended.
CTDN: Countdown. If this bit is set Countdown field contains duration in 1/256 s. If this bit is
cleared the duration is given in seconds.
92
EN 13757-3:2018 (E)
I.2.6.2 Count Down field
This field holds the time until the first packet of image transfer will start. It informs the device as to
when it shall be ready. The internal structure of this field is 2 bytes unsigned data coded LSB first. The
CTDN bit in the sub-function field specifies the scaling.
NOTE Detailed timing is described in 13757–4.
I.2.7 Transfer command
I.2.7.1 General
The command is used for the transfer of the actual image (see Table I.17).
Table I.17 — Transfer command structure
Image
Sub-
Function identifier Block Remaining Additional Info
function Image block
field field number (optional) (optional)
field
(optional)
02h 1 byte 8 bytes 2 bytes 2 bytes 2 bytes n bytes
The assignment of the different bits in the sub-function field is shown in Table I.18:
Table I.18 — Transfer command sub-function
b7 b6 b5 b4 b3 b2 b1 b0
RFU RFU REM IDEN SEQ AINF
RFU: Reserved for Future Use, set to 0

REM: Remaining blocks. If this bit is set then command contains a remaining field.
IDEN: Identity information. This bit is set if an Image identifier field follows. The field is formatted as
shown in I.2.4.2.
SEQ: Sequence State. The bits shall be set as shown below:
00b = Not used
01b = First block
10b = Intermediate block
11b = Last block
AINF: Additional Information. If this bit is set then the command contains an Additional Information
field.
I.2.7.2 Block number
The field is mandatory. It holds the number of the block being transferred. The value shall be in the
range 0 to Number of Blocks –1. Data with a value outside this range shall be discarded. It is a 2 bytes
unsigned value coded LSB first.
93
EN 13757-3:2018 (E)
I.2.7.3 Remaining field
The field is optional. It holds number of outstanding blocks. The value shall be in the range Number of
Blocks –1 to 0. It is a 2 bytes unsigned value coded LSB first.
I.2.7.4 Additional Information
The field is optional. It holds additional information defined by the manufacturer. The internal structure
of this 2 bytes field is manufacturer specific.
NOTE It is the responsibility of a provider of an image to ensure that it fits to the block size. It is the
providers’ task to define any padding algorithm need to support data not fitting the block size.
I.2.7.5 Image block
The field is mandatory. It holds the actual image data to be transferred.

I.2.8 Transfer Response
In case of unicast messaging, a M-Bus device may return an Transfer Response after each Transfer
Command. The format of the response is shown in Table I.19.
Table I.19 — Structure of Transfer Response
Function Sub-function Image identifier field

Field field (optional)
82h 1 byte 8 bytes
Table I.20 — Transfer Response sub-function
b7 b6 b5 b4 b3 b2 b1 b0
RFU RFU RFU IDEN STATE
RFU: Reserved for Future Use, shall be sent bit = 0 and be don’t care value when received.
IDEN Image identifier field information. This bit is set if an Image identifier field follows. If IDEN was
enabled in the received command then device shall also set this bit in the response. The Image
identifier field is formatted as shown in I.2.4.2.
STATE The overall progress state of the transfer of the image, with the states as listed in Table I.29 –
Overall state transfer.
I.2.9 Completion command
The command checks completeness of the image transfer. This is a point-to-point command send
individually to all devices. The format of the command is shown in Table I.21. The receiving device shall
respond to the command with a status whether or not image blocks have been lost.
The function has the sub-function field as the initial field. It may be followed by optional fields
controlled by the bit mask in the sub-function field.
Table I.21 — Completion command structure
Function Sub-function Image identifier field Additional Info

field field (optional) (optional)
94
EN 13757-3:2018 (E)
Table I.22 — Completion command sub-function
b7 b6 b5 b4 b3 b2 b1 b0
RFU RFU RFU RFU RFU RFU IDEN AINF
RFU: Reserved for Future Use, set to 0

IDEN: Image identifier field information. This bit is set if an Image identifier field follows. The Image
AINF: Additional Information. If this bit is set then the command contains an Additional Information
field. It is a 2 bytes field. The format is Manufacturer specific.
I.2.10 Completion response
I.2.10.1 General
This is the response to the Completion command. The structure is shown in Table I.23 below. The
optional fields are controlled by the bit mask in the sub-function field.
Table I.23 — Structure of Completion response
Sub- Image identifier Total Number Lost Blocks

Function
function field of lost blocks field
Field
field (optional) (optional) (optional)
83h 1 byte 8 bytes 2 bytes n × 2 bytes
Table I.24 — Completion response sub-function
b7 b6 b5 b4 b3 b2 b1 b0
RFU RFU RFU RFU IDEN TNLB LIB NBR
RFU: Reserved for future use, set to 0.

IDEN: Image identifier field information. This bit is set if an Image identifier field follows. If IDEN
was enabled in the received command then this bit shall also be set in the response. The
Image identifier field is formatted as shown in I.2.4.2.
TNLB: Total Number of Lost Blocks. If this bit is set a field indicating the total number of lost blocks
is present in the response. If this bit is cleared the field is not included in the response.
LIB: Lost image blocks. If this bit is set, some Image blocks are missing. A list of Lost image blocks
shall be included in the response. If this bit is cleared, all image blocks were received.
NBR No blocks received. If this bit is set it signals that no image blocks are received. As soon as
one block is received this bit is cleared.
I.2.10.2 Total Number of Lost Blocks
This field shall inform to the Gateway the total number of missing blocks and it enables the Gateway to
decide on how to proceed on the download process completion, e.g. full or partial restart. It is a 2 bytes
unsigned value coded LSB first.
95
EN 13757-3:2018 (E)
I.2.10.3 Lost Blocks Field
This field holds an array of 2-bytes elements. Each 2-bytes element refers to the missing block number.
FFFFh is used to indicate that all following blocks in the list are missing. Provide the first element with
FFFFh if no blocks are received. It is a set of unsigned values coded LSB first.
I.2.11 State command
The command requests the state of the individual receiver. The structure is shown in Table I.25. The
optional fields are controlled by the bit mask in the sub-function field.
Table I.25 — State command structure
Image identifier Additional Info

Function field Sub-function field
Table I.26 — State command sub-function
b7 b6 b5 b4 b3 b2 b1 b0
IDEN: Image identifier field information. This bit is set if an Image identifier field follows. If IDEN was
enabled in the received command then M-Bus device shall also set this bit in the response. The
Image identifier field is formatted as shown in I.2.4.2.
AINF Additional Information. If this bit is set then the command contains an Additional Information
I.2.12 State Response
A device shall return a State Response after receiving a State Command. The format of the response is
shown in Table I.27 below.
Table I.27 — Structure of State response

84h 1 byte 8 bytes
Table I.28 — State response sub-function
b7 b6 b5 b4 b3 b2 b1 b0
96
EN 13757-3:2018 (E)
STATE The overall progress state of the transfer of the image, with the states as listed in Table I.29.
Table I.29 — Overall state of the transfer
State Value Description
0 0000b Synchronization activated
1 0001b Synchronization terminated
2 0010b Transfer initiateda
3 0011b Transfer activea
4 0100b Transfer terminatedc
5 0101b Transfer successful
6 0110b Transfer failed
7 0111b Validation initiateda
8 1000b Validation activea
9 1001b Validation successful
10 1010b Validation failed
11 1011b Activation initiateda,b

12 1100b Activation successful
13 1101b Activation failed
14 1110b Image Transfer Terminatedd

15 1111b Idle
a The state initiated is reached once the device has received the command. The
state active is reached once the device is processing/executing the command.
b A device is not expected to be able to respond while it is activating an image.
c To be used if the T_TR bit in the terminate command is set.
d To be used if the T_IT bit in the terminate command is set.
The image identifier field shall be present in the State Response, if this field was also present in the
State Command.
I.2.13 Validate command
The command requests the individual device to validate the image received. The details of the
validation process are manufacturer specific. The state and result of the validation activity can be
retrieved using the State Command. The command, as shown in Table I.30, has only the sub-function as
parameter.
Table I.30 — Validate command structure
Image identifier Additional Info

97
EN 13757-3:2018 (E)
Table I.31 — Validate command sub-function
b7 b6 b5 b4 b3 b2 b1 b2
IDEN Image identifier field information. This bit is set if an Image identifier field follows. The Image
AINF Additional Information. If this bit is set then the command contains an Additional Information
I.2.14 Validate Response
In case of unicast messaging, a M-Bus device shall return an Validate Response after receiving a Validate
Command. The format of the Response is shown in Table I.32.
Table I.32 — Structure of Validate Response

85h 1 byte 8 bytes
Table I.33 — Validate Response sub-function
b7 b6 b5 b4 b3 b2 b1 b0
Overall state of the transfer.
I.2.15 Activate command
The command activates the image once transferred. The activation may be immediate or timed. The
structure of the command and the order of the fields are shown in the following Table I.34.
Table I.34 — Activate command structure
Image
Function field Sub-function field identifier field Date and Time
(optional)
98
EN 13757-3:2018 (E)
Table I.35 — Activate command sub-function
b7 b6 b5 b4 b3 b2 b1 b0
RFU IDEN ADT
RFU: Reserved for future use, set to 0

ADT: Absolute Date and Time. If this bit is set, then activation time information in the Date and Time
field is absolute, and given as EPOCH 2013. If this bit is cleared, then the activation time in the
Data and Time is relative to the current time. An immediate activation is achieved by a Date and
Time value of ‘zero’ and clearing ADT = 0b.
Date and Time field
This field holds the time when the transferred image shall be activated. It is a 4 bytes field coded LSB
first. The field contains, if the ADT bit in Sub-function is set, the absolute Date and Time of activation, in
EPOCH 2013, otherwise the field contains the number of seconds, to wait from on the end of the
reception of the frame before, activation. In case the date is in the past an immediate activation is
achieved.
The EPOCH 2013 time format corresponds to 0Dh 6Dh E5h xx xx xx xx 20h according to Annex A,
Type M.
I.2.16 Activate Response
In case of unicast messaging, a M-Bus device shall return an Activate Response after receiving an
Activate Command. The format of the response is shown in Table I.36 below.
Table I.36 — Structure of Activate Response

86h 1 byte 8 bytes
Table I.37 — Activate Response sub-function
b7 b6 b5 b4 b3 b2 b1 b0
Overall state of the transfer
99
EN 13757-3:2018 (E)
I.2.17 Terminate Command
The command terminates an image transfer phase or the whole image transfer process. The structure is
shown in Table I.38. The optional fields are controlled by the bit mask in the sub-function field. The
State command and State response supply information about the result.
Table I.38 — Terminate Command structure
Image identifier field

(optional)
07h 1 byte 8 bytes
Table I.39 — Terminate command sub-function
b7 b6 b5 b4 b3 b2 b1 b0
RFU RFU RFU RFU RFU IDEN T_TR T_IT
T_IT: Terminate the whole image transfer process and restore initial device state before start of
image download process.
T_TR: Terminate the transfer phase and restore device state before first block transfer
I.2.18 Terminate Response
In case of unicast messaging, a M-Bus device shall return an Activate Response after receiving an
Activate Command. The format of the response is shown in Table I.40 below.
Table I.40 — Structure of Terminate Response

87h 1 byte 8 bytes
Table I.41 — Terminate Response sub-function
b7 b6 b5 b4 b3 b2 b1 b0
Overall state of the transfer.
100
EN 13757-3:2018 (E)
I.2.19 Active Images Command
This is an optional command, and may not be supported by an M-Bus Device. This command shall be
used to report on all images that are currently active on the M-Bus Device (see Table I.42).
Table I.42 — Active images command structure

08h 1 byte
Table I.43 — Active images command sub-function
b7 b6 b5 b4 b3 b2 b1 b0
RFU, set to 0
I.2.20 Active Images Response
A device shall return an Active Images Response after receiving an Active Images Command. The format
of the response is shown in Table I.44.
Table I.44 — Active Images Response structure
Active Images
Function Field Sub-function Field
(optional)
88h 1 byte 1 + n x 8 bytes
The content of the sub-function field shall be interpreted as depicted in Table I.45
Table I.45 — Active Images Response sub-function
b7 b6 b5 b4 b3 b2 b1 b0
RFU RFU RFU RFU RFU RFU RFU LAI
LAI List of Active Images. If this bit is set, the Active Images field will be present in the response.
The Active Images field will report the current active images on the M-Bus device. The Active Images
field is structured as shown in Table I.46:
Table I.46 — Active Images field
Number of Active Images List of Image identifier fields

1 byte n x 8 bytes
The first byte indicates the number of active images on the M-Bus device. The following bytes gives the
corresponding 8 bytes Image Identifier fields of the images that are currently active on the M-Bus
Device.
I.3 Overview Image Transfer

The displayed sequence chart in Figure I.1 and Figure I.2 shows a possible process for Image Transfer
for a general understanding. Some of the phases and messages are optional as stated in the respective
clauses.
101
EN 13757-3:2018 (E)
Key
a Phase 1 (point to point): Transfer Preparation
b Prepare Command
c Prepare Response
d Phase 2 (multicast): Synchronization
e Synchronize Command
f Phase 3A (multicast): Transfer Image
g Transfer Command – Block 1
h Transfer Command – Block 2
i Transfer Command – Block 3
Figure I.1 — Image Transfer phases 1 to 3
102
EN 13757-3:2018 (E)
Key
j Phase 3B (point to point): Check Completeness of transfer
k Complete Command
l Complete Response
m Optionally send a missing block with transfer command
n In case Transfer response reporting success
o Phase 4 (point to point): Image validation
p Validate Command
q Validate Response
r Phase 5 (point to point): Image Activation
s Activate Command
t Activate Response
Figure I.2 — Image Transfer phases 3 to 5
103
EN 13757-3:2018 (E)
Bibliography
[1] EN 1434–3, Heat meters - Part 3: Data exchange and interfaces
[2] EN 60870-5-1, Telecontrol equipment and systems - Part 5: Transmission protocols - Section 1:
Transmission frame formats
[3] EN 13757–1, Communication systems for meters - Part 1: Data exchange
[4] EN 62056-6-2, Electricity metering data exchange — The DLMS/COSEM suite — Part 6-2: COSEM
interface classes
[5] ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference
Model: The Basic Model — Part 1
[6] ANSI X9 TR-31:2010, Interoperable Secure Key Exchange Key Block Specification for Symmetric
Algorithms
[7] EN 62056-6-1, Electricity metering data exchange — The DLMS/COSEM suite — Part 6-1: Object
Identification System (OBIS)
104

En 13757 3 2018 04

Uploaded by

Copyright:

Available Formats

En 13757 3 2018 04

Uploaded by

Document Information

Original Title

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

En 13757 3 2018 04

Uploaded by

Copyright:

Available Formats

EUROPEAN STANDARD EN 13757-3

ICS 33.200; 35.100.70; 35.240.99; 91.140.50 Supersedes EN 13757-3:2013

Communication systems for meters - Part 3: Application

This European Standard was approved by CEN on 8 February 2018.

EUROPEAN COMMITTEE FOR STANDARDIZATION

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels

B.2 Definition ......................................................................................................................................................... 44

— extension of application select;

— introduction of second level table for VIFE = FDh;

— introduction of inverse compact load profile;

— introduction of new VIFE for descriptor;

— extension of VIFE = FCh table;

— extension of definitions for DIF = 0Fh/1Fh;

— transport and security services were moved to EN 13757-7;

EN 13757 is currently composed with the following parts:

— Communication systems for meters — Part 1: Data exchange;

— Communication systems for meters — Part 2: Wired M-Bus communication;

— Communication systems for meters — Part 3: Application protocols ;

— Communication systems for meters — Part 5: Wireless M-Bus relaying;

— Communication systems for meters — Part 6: Local Bus;

— Communication systems for meters — Part 7: Transport and security services ;

Liberty Lake, Washington 99019

EN 13757-5, Communication systems for meters - Part 5: Wireless M-Bus relaying

EN 13757-6, Communication systems for meters - Part 6: Local Bus

ISO/IEC/IEEE 60559:2011, Information technology — Microprocessor Systems — Floating-Point

3 Terms and definitions

Note 1 to entry: In previous versions of EN 13757–3 datagram was called telegram.

[SOURCE: ANSI X9 TR-31:2010]

Note 1 to entry: A message may consist of one or more datagrams.

[SOURCE: ISO/IEC 7498-1]

4 Abbreviations and symbols

MSBit Most Significant Bit

Hexadecimal numbers are designated by a following “h”.

5 Selection of an application protocol

APL Variable data blocks MDH Manufacturer specific data

DIF DIFE VIF VIFE Data

6.3 Data Information Block (DIB)

The coding of the DIF is shown in Table 3.

Table 4 — Coding of the data field

Code LengthSize in bit Data type

0001b 8 8 bit integer/binary

0110b 48 48 bit integer/binary

1100b 32 8 digit BCD

1101b N Variable length

1110b 48 12 digit BCD

1111b — Special functions

Table 5 — LVAR interpretation

Range Data Type Calculation

D0h–D9h Negative BCD number (LVAR–D0h)*2 digits, 0 to 18 digits

E0h–EFh Binary number (LVAR–E0h) bytes, 0 to 15 bytes

F5h Binary number 48 bytes

F6h Binary number 64 bytes

Others LVAR values Reserved

3Fh to 6Fh Reserved

6.3.4 Function field

The Function Field gives the type of value as specified in Table 7.

10b Minimum value

11b Value during error state

6.3.5 Storage number