SIST-TP CEN/TR 17167:2024

SLOVENSKI STANDARD
01-februar-2024
Komunikacijski sistemi za merilnike - Spremno tehnično poročilo k EN 13757-2,-3
in -7 - Primeri in dodatni podatki
Communication system for meters - Accompanying TR to EN 13757-2,-3 and -7,
Examples and supplementary information
Kommunikationssysteme für Zähler - Begleitender Technischer Bericht zu EN 13757-2, -
3 und -7, Beispiele und ergänzende Informationen
Systèmes de communication pour compteurs - Rapport technique accompagnant les EN
13757-2,-3 et -7 - Exemples et informations supplémentaires
Ta slovenski standard je istoveten z: CEN/TR 17167:2023
ICS:
33.200 Daljinsko krmiljenje, daljinske Telecontrol. Telemetering
meritve (telemetrija)
35.240.99 Uporabniške rešitve IT na IT applications in other fields
drugih področjih
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TR 17167
TECHNICAL REPORT
RAPPORT TECHNIQUE
December 2023
TECHNISCHER REPORT
ICS 33.200; 35.240.99; 91.140.50 Supersedes CEN/TR 17167:2018
English Version
Communication system for meters - Accompanying TR to
EN 13757-2,-3 and -7, Examples and supplementary
information
Systèmes de communication pour compteurs - Rapport Kommunikationssysteme für Zähler - Begleitender
technique accompagnant les EN 13757-2,-3 et -7 - Technischer Bericht zu EN 13757-2, -3 und -7,
Exemples et informations supplémentaires Beispiele und ergänzende Informationen

This Technical Report was approved by CEN on 6 November 2023. It has been drawn up by the Technical Committee CEN/TC
294.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye 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
© 2023 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 17167:2023 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Symbols and abbreviations . 7
4.1 Abbreviations . 7
4.2 Symbols . 8
5 Overview . 8
Annex A (informative) Examples . 10
Annex B (informative) Secondary search - Instructions for implementation of wildcard
search . 18
Annex C (informative) Consumer feedback for smart metering applications . 20
Annex D (informative) Installation and registration . 23
Annex E (informative) M-Bus data container . 26
Annex F (informative) Datagram examples for the M-Bus and the wM-Bus . 28
Annex G (informative) Descriptors . 84
Bibliography . 90

European foreword
This document (CEN/TR 17167:2023) has been prepared by Technical Committee CEN/TC 294
“Communication systems for meters”, the secretariat of which is held by DIN.
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 supersedes CEN/TR 17167:2018.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
CEN/TR 17167:2018:
— update according new CEN rules IR3.
— update FCB usage and adding new Figure A.1 to be in line with EN 13757-2 (202x)
— add new M-Bus data container for M-Bus upper layers (77h)
— Update datagram example in (sub-)clauses F.4, F.5.4 and F.7.2.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
Introduction
This document belongs to a series of parts of EN 13757, which covers communication systems for meters
and remote reading of 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-3
contains detailed description of the application protocols especially the M-Bus Protocol. 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–7 describes transport mechanism and security methods for data.
These upper M-Bus protocol layers can be used with various physical layers and with 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 document 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 meters and
heat cost allocators) and for electricity meters, in this document 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.
Table 1 gives an overview of the annexes as well as a reference to the corresponding Annexes in the
former EN 13757-3:2013 where applicable.
Table 1 — Relation between the annexes of this Technical report and EN 13757–3:2013
Annex Description Annex in EN 13757–3:2013
A Datagram examples for a twisted pair M-Bus link layer E
B Secondary search implementation instructions F
C Consumer feedback for smart metering applications L
D Installation and registration procedures M
E Implementation of an M-Bus data container N
F Datagram examples for wired and wireless M-Bus P
G Implementation of Descriptors —
1 Scope
This document contains additional information to the requirements determined in EN 13757-2,
EN 13757-3 and EN 13757–7, in particular examples for the implementation, datagram examples
secured by security mechanism of part 7 and additional non-normative requirements beyond meter
communication itself.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at https://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
3.1
byte
octet of bits
3.2
data integrity
property that data has not been altered or destroyed in an unauthorized manner
3.3
datagram
unit of data transferred from source to destination
3.4
integrity
see data integrity
3.5
key derivation
technique by which a (potentially large) number of keys are generated (“derived”) from a single initial
key and non-secret variable data with each resulting key using a non-reversible process
3.6
message
functional set of data transferred from source to destination
Note 1 to entry: A message can consist of one or more datagrams.
3.7
persistent key
cryptographic key which is kept for a prolonged period
3.8
security mechanism
mode of operation of a (symmetric) cryptographic algorithm
3.9
security mode
mode number in configuration field identifying a set of applied security mechanisms
3.10
security service
authenticity, confidentiality and data integrity
4 Symbols and abbreviations
4.1 Abbreviations
ACK Acknowledge
AES Advanced Encryption Standard
AFL Authentication and Fragmentation Layer
APL Application Layer
BCD Binary Coded Decimal numbers
CBC Cipher Block Chaining (AES mode of operation)
CF Configuration Field
CFE Configuration Field Extension
CI Control Information field
CMAC Cipher-based MAC [Source: NIST/SP 800–38B]
CMD Command
CNF-IR Confirm Installation Request
CTR Counter Mode encryption algorithm (AES mode of operation)
DIB Data Information Block
DIF Data Information Field
DIFE Data Information Field Extensions
DLL Data Link Layer
ELL Extended Link Layer
GCM Galois/Counter Mode, an algorithm for authenticated encryption with associated data
(AES mode of operation)
IV Initialisation Vector
LSB Least Significant Byte
MAC Message Authentication Code
NOTE MAC is in other standards also used as an acronym for Media Access Control for data
communication at the Physical Layer
MSB Most Significant Byte
OBIS Object Identification System (see IEC 62056–6-1)
REQ-UD Request User Data (class 1 or 2)
RSP-UD Respond User Data
RSSI Received Signal Strength Indicator
SM-CG Smart Meter Co-ordination Group
SND-IR Send Installation Request
SND-NKE Send Link Reset
SND-NR Send – No Reply
SND-UD Send User Data
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.
The concatenation of fields is indicated by the symbol “||”. E.g. 12 || 34 results in 1234 .
h h h
5 Overview
The supplementary information on the requirements determined in EN 13757-2, EN 13757-3 and
EN 13757–7 is provided in the annexes of this document. Table 2 gives an Overview about these Annexes.
Annexes A, B and D are only applicable to wired M-Bus solution.
Annex C describes how parts of EN 13757-2, EN 13757-3, EN 13757-4 and EN 13757–7 can be used to
implement smart meter functionalities. Similar functionalities could also be implemented using other
physical and link layers.
Annex D provides information on installation procedures wireless meters and their integration in meter
management systems.
Annex E contains a definition of two containers to transport special data via an M-Bus data point.
Annex F provides many examples of plain and encrypted/authenticated M-Bus messages for the wired
and wireless M-Bus.
Annex G defines descriptors, i.e. special M-Bus data points, which have been added to explain the purpose
of other M-Bus data points.
Table 2 — Overview of the Annexes
Applicable for
Annex Description
wired M-Bus wireless M-Bus
A Datagram examples for a twisted pair M-Bus link layer x
B Secondary search implementation instructions x
C Consumer feedback for smart metering applications x x
D Installation and registration procedures  x
E Implementation of an M-Bus data container x x
F Datagram examples for wired and wireless M-Bus x x
G Implementation of Descriptors x x
Annex A
(informative)
Examples
A.1 General
The following examples give the whole datagram for a twisted pair M-Bus link layer (EN 13757-2).
Nevertheless, other physical and link layers (e.g. EN 13757-4) could also be used.
A.2 Example for an RSP-UD
(All values are hex.)
68 1F 1F 68 Link layer header of RSP-UD datagram (length 1F = 31d bytes)
h
08 02 72 C field = 08 (RSP), address 2, CI field 72h
78 56 34 12 Identification number = 12345678
24 40 01 07 Manufacturer ID = 4024 (“PAD”), version = 1, device type = water meter
h
55 00 00 00 ACC = 55 = 85d, status = 00 , configuration field = 0000
h h h
03 13 15 31 00 Data block 1: unit 0, storage No. 0, no tariff, instantaneous volume,
12565 l (24 bit integer)
DA 02 3B 13 01 Data block 2: unit 0, storage No. 5, no tariff, maximum volume flow, 113 l/h (4
digit BCD)
8B 60 04 37 18 02 Data block 3: unit 1, storage No. 0, tariff 2, instantaneous energy, 218,37 kWh
(6 digit BCD)
18 16 Checksum and stop sign
A.3 Example baud rate switch
The master switches the slave (in point-to-point connection) from now 2 400 Bd to 9 600 Bd.
(All values are hex.)
Master to slave: 68 03 03 68 53 FE BD 0E 16 with 2 400 Bd.
Slave to master: E5 with 2 400 Bd.
From that time on the slave communicates with the transmission speed 9 600 Bd, if the slave can handle
9 600 Bd, otherwise it remains at 2 400 Bd.
In bus mode this is followed within < 2 min by an acknowledged communication (i.e. SND-NKE) at
9 600 Bd.
Master to slave: 10 40 FE 3E 16.
Slave to master: E5.
A.4 Example application select with subcode
The master releases an enhanced application select to all slaves. All datagrams of the user data type are
requested.
(All values are hex.)
Master to slave: 68 04 04 68 53 FE 50 10 B1 16.
Slave to master: E5.
A.5 Writing data to a slave
The master can send data to a slave using a SND-UD with CI-field 51 , 5A or 5B .
h h h
The following table shows the data structure for a write message. The order of the first three blocks in
the following Table A.1 can be chosen freely, but the write only data record is at the end of the message.
All records are optional.
Table A.1 — Data structure for writing data
Enhanced identification
Primary address record Normal data records Write only data records
record
Primary address record.
The primary address record is optional and consists of three bytes:
Table A.2 — Coding of primary address
DIF = 01 VIF = 7A
Data = Address (1 byte binary)
h h
With this data record a primary address can be assigned to a slave in point to point connections. The
master knows all the used addresses on the bus and forbids setting the address of a slave to an already
used address. Otherwise, both slaves with the same address could not be read out anymore.
Enhanced identification record.
With this optional data record, the identification (secondary address) can be changed. There are two
cases to be distinguished:
Data are only the identification number
Table A.3 — Coding of single identification number
DIF = 0C VIF = 79
Data = Identification No. (8 digit BCD)
h h
Data are the complete identification
Table A.4 — Coding of complete secondary address
DIF = 07 VIF = 79
Data = complete ID (64 bit integer)
h h
The data are packed exactly as in the readout header of a CI = 72 variable protocol with low byte first.
Table A.5 — Structure of secondary address
Identification no. Manufacturer ID Version Device Type
4 byte 2 byte 1 byte 1 byte
Normal data records:
The data records, which can be read out with a REQ_UD2, are sent back to the slave with the received DIF
and VIF and the new data contents. Additional features can be implemented using the generalized object
layer (see EN 13757-3:2018, 6.4.1).
Write-only data:
Data, which cannot be read out of the slave with a normal data block, can be transmitted using
the VIF = 7F for manufacturer specific coding. The DIF has a value corresponding to the type and length
h
of data.
After receiving the SND-UD correctly without any error in data link layer, the slave answers with an
acknowledgement (E5 ). The slave decides whether to change variables or not after a data write from
h
the master. In case of errors in executing parts of or whole write instructions the slave can decide whether
to change no variables or single correct variables. The slave can report these errors to the master in the
next RSP-UD datagram using some of the methods which are described in EN 13757-3:2018, 10.3.
There are some methods for implementing write protect, for example allowing only one write after a
hardware reset of the processor or enabling write if a protect disable jumper is set.
Examples (all values are hex.)
EXAMPLE 1 Set the slave to primary address 8 without changing anything else:
68 06 06 68 53 FE 51 01 7A 08 25 16
EXAMPLE 2 Set the complete identification of the slave (ID = 01020304 (BCD), Man = 4024h (PAD), Ver = 1, Dev.
Type = 4 (heat):
68 0D 0D 68 53 FE 51 07 79 04 03 02 01 24 40 01 04 95 16
EXAMPLE 3 Set identification number of the slave to “12345678 (BCD)” and the 8 digit BCD-counter (unit
1 kWh) to 107 kWh.
68 0F 0F 68 53 FE 51 0C 79 78 56 34 12 0C 06 07 01 00 00 55 16
A.6 Configuring M-Bus data output
A.6.1 General
For default, the slave transmits all its data according the selected message application by an Application
select protocol (see EN 13757-3:2018, Clause 7). It could be useful for some scenarios to adapt this
preselected message contents by an individual selection or deselection of specific data records.
The individual selection of data records is a temporary adaption of the message content of the currently
selected message application. The next applied application reset or application select (according to
EN 13737-3:2018, 5.3) will clear this temporary data record selection and the meter will send the original
content of the message application.
The message application 15 “User defined” is dedicated to store the individual selected data record
adaptions. Contrary to the other message applications the modification remains permanently even after
an application reset or application select. The message application 15 can initially be empty or predefined
by the manufacturer and is intended to be adapted by the user or operator.
This annex describes two ways to select or deselect data records individually.
A.6.2 Selection of data records with special data field
The selection of the wanted data records can be performed with a SND-UD and M-Bus data records
containing the data field 1000 , which means ”selection for readout request” (according
b
EN 13757-3:2018, Table 4). The following VIF defines the selected data as listed in EN 13757-3:2018 and
no data are transmitted. The answer data field is determined by the slave. The master can select several
variables by sending more data blocks with this data field in the same datagram.
Special multiple values can be selected with the following methods:
Any VIF:
The VIF-code 7E (any VIF) is especially for readout request of “all VIF” from the slave and can be
h
interpreted as a selection wildcard for the value information field.
Global readout request:
The DIF-code 7F is defined as “selection of all data for readout request”, i.e. all storage numbers, units,
h
tariffs and functions. If this DIF is the last byte of user data or the VIF = 7E follows, then all data are
h
requested. So the selection of all data of one slave can be done with a SND-UD and the character 7F as
h
the user data. If a DIF unequal to 7E follows, then all data records with this VIF are selected for readout.
h
All tariffs:
The highest tariff number in the selection record is defined as selection of “all tariffs”. For example, the
tariff 1111 (15) means selection of all tariffs in a record with two DIFE´s.
b
All storage numbers:
A selection of all storage numbers can be done with the maximum storage number if there is a minimum
of one DIFE. For example the highest storage number is 1F (31d) with one DIFE and 1FF (511d) with
h h
two DIFEs.
All units:
“All units” can be selected by using a Data Record Header with minimum two DIFEs and the highest unit
number.
High resolution readout:
The master can select the slave to answer with the maximum resolution to a given value/unit by a VIF
with “nnn” = 000 (minimum exponent for range coding). The meter can then answer with a resolution of
e.g. 1mW (VIF = 0000000 ) or some higher decimal value if required. The unit values have been chosen
h b
so that their minimum provides sufficient resolution even for calibration. A readout request for a VIF with
“nnn” = max (maximum exponent for range coding) signals a request for the standard resolution of the
meter.
After the next REQ-UD2 the slave answers with the selected data in his own format, if the requested data
are available. Otherwise the slave transmits his normal data and the master has to find out that the data
are not the requested. If there is more than one variable with the selected VIF, the device will send all
these data records.
A.6.3 Selection of data records with object action code
The master is able to perform a readout request with a specified data field by using the object action “add
to readout list” (VIFE = E000 1100 ) from VIFE-table for object actions (see EN 13757-3:2018, Table 17).
b
The master transmits a SND-UD with a data record which consists of the desired DIF (data field), VIF and
the VIFE = 0C /8C . No data follows this VIFE and the slave will ignore the data field on reception. The
h h
slave will transmit this data record with the requested data field from now on, if it is capable of this. If the
slave does not support this data field (data coding), it can report a record error using one of the
VIFE = E000 011x (data class not implemented or data size not implemented).
A.6.4 Deselection of data records
The master can release an application reset of the application layer and especially a fall back to the slave
standard RSP-UD datagram by transmitting an application reset or application select.
Single data records can be deselected by transmitting a data record with DIF, VIF and the VIFE for the
object action “Delete from readout-list” (VIFE = E000 1101 ) (see EN 13757-3:2018, Table 17).
b
If the selected data are supported by the slave but too long for one RSP-UD datagram (especially for
readout of all historic values), the slave transmits an additional data record consisting only of the
DIF = 1F , which means that more data records follow in the next respond datagram. In this case the
h
master reads out the slave again until the respond datagram is only a ACK or there is no DIF = 1F in the
h
RSP-UD.
To avoid loss of respond datagrams the slave will in this case support the Frame Count Bit (FCB). If the
master wants to prematurely end such a multi datagram message sequential readout of the selected data,
it can send an application reset or application select instead of further REQ-UD2´s.
EXAMPLE 1 A slave with address 7 is to be configured to respond with the data records containing volume
(VIF = 13h: volume, unit 1l) and flow temperature (VIF = 5Ah: flow temp., unit 0,1 °C):
68 07 07 68 | 53 07 51 08 13 08 5A 28 16
EXAMPLE 2 A slave with address 1 is to be configured to respond with all storage numbers, all tariffs, and all
VIFs from unit 0:
68 06 06 68 53 01 51 C8 3F 7E 2A 16
EXAMPLE 3 A slave with address 3 is to be configured to respond with all data for a complete readout of all
available. After that the master can poll the slave to get the data:
68 04 04 68 53 03 51 7F 26 16
With these actions, the master can alter the data of the slaves or configure the output data of the slaves
(actions 12 and 13). The actions 0 to 6 alter the data of the slave by replacing the old data (action 0, equals
to data write without VIFE) or do arithmetical or logical operations with the old and the transmitted data.
NOTE This method of configuring the readout list (action 12 and 13) allows not only the adding but also the
removal of elements in contrast to the method of using the DIF = 1000 -type of readout request (described before).
b
All these actions can be used for normal slaves and for intelligent masters which are manipulated by a
higher order master.
The functions “add entry” and “delete entry” are useful to tell an intelligent master to add e.g. a new data
record like maximum or minimum values of any slave.
With the action “freeze data to storage #” the master can tell the slave to freeze the current value
corresponding to the transmitted VIF, unit, tariff and function to a certain storage number given in the
DIF/DIFEs. In this case, the data field inside the VIF has got the value 0000 (no data). This action allows
b
freeze of selected values or multiple freeze with VIF = 7E (all VIF). The date/time will also be frozen to
h
the same storage number.
EXAMPLE 4 Set the 8 digit BCD-Counter (instantaneous, current value, no tariff, unit 0) with VIF = 06 (1 kWh)
of the slave with address 1 kWh to 107 kWh:
68 0A 0A 68 53 01 51 0C 86 00 07 01 00 00 3F 16
EXAMPLE 5 Same as in example 1) but add 10 kWh to the old data:
68 0A 0A 68 53 01 51 0C 86 01 10 00 00 00 48 16
EXAMPLE 6 Add an entry with an 8 digit BCD-Counter (instantaneous, current value, no tariff, unit 0,1 kWh)
with the start value of 511 kWh to the data records of the slave with address 5:
68 0A 0A 68 53 05 51 0C 86 08 11 05 00 00 59 16
EXAMPLE 7 Freeze actual flow temperature (0,1 °C: VIF = 5Ah) of the slave with address 1 into the storage
number 1:
68 06 06 68 53 01 51 40 DA 0B CA 16
A.7 FCB and selection
A.7.1 FCB-implementation slave
A slave with implemented secondary addressing and with implemented FCB-administration has a “Last
received FCB”-memory bit for the communication via the pseudo primary address 253 (FD ). If it can
h
communicate also alternatively over some other primary address (except the special address 255) an
additional ”Last received FCB”-memory bit for each of these primary addresses is required. A valid
selection datagram will not only set the internal selection bit but will also clear the internal ”Last received
FCB”-memory bit associated with secondary addressing via the pseudo primary address 253 (FD ). The
h
master will start the communication (REQ_UD2 or SND-UD) after any selection datagram (CI = 52 ) with
h
the FCV-bit set and the FCB-bit set. If a slave has more than one alternative secondary address, only a
single ”Last received FCB”-memory bit for all secondary addresses is required.
The following program flow diagram in Figure A.1 shows the implementation of the FCB in a slave.
Figure A.1 — Flow diagram for FCB implementation
A.7.2 FCB-implementation master
The master implements a ”Next FCB image”-bit for each primary address and for the pseudo primary
address 253 (FD ). Although this “Next FCB image”-bit might be used for many slaves, no confusion
h
exists, since for accessing another slave a selection datagram is required which will define the future FCB
sequence both for slave and master.
If the master applies one of the new application frames with a short or long data header (refer to
EN 13757-7:2018, 7.3 and 7.4), it increases the access number each time when the FCB was changed.
EXAMPLE
Master > SND-NKE 10 40 FD 3D 16
SND-NKE clears the FCB
Master > SELECT 68 0B 0B 68 73 FD 52 78 94 07 57 3B 3D 43 07 cc 16
Slave_1 > ACK E5
SELECT clears the FCB of address 253
Master > REQ-UD2 10 7B FD 58 18
Slave_1 > RSP-UD 68 xx xx 68 08 01 72 Response cc 16
Master > SELECT 68 0B 0B 68 53 FD 52 44 33 22 11 3B 3D 28 07 13 16
Slave_2 > ACK E5
SELECT clears the FCB of address 253
Master > REQ-UD2 10 7B FD 58 18
Slave_2 > RSP-UD 68 xx xx 68 08 02 72 Response_1 1F cc 16
Master > REQ-UD2 10 5B FD 58 18
Slave_2 > RSP-UD 68 xx xx 68 08 02 72 Response_2 1F cc 16
Master missed last RSP-UD and asks again for the same frame
Master > REQ-UD2 10 5B FD 58 18
Slave_2 > RSP-UD 68 xx xx 68 08 02 72 Response_2 1F cc 16
Master understood last RSP-UD and asks for the next frame of the multi frame answer
Master > REQ-UD2 10 7B FD 58 18
Slave_2 > RSP-UD 68 xx xx 68 08 02 72 Response_3 cc 16
Master > SND-UD 68 xx xx 68 53 FD 51 Command_1 cc 16
Slave_2 > ACK E5
A.8 Use of the fabrication number
The fabrication number is a serial number allocated during manufacture. It is part of the variable data
block (DIF = 0C and VIF = 78 ) and coded with 8 BCD packed digits (4 byte).
h h
EXAMPLE
68 15 15 68 header of RSP-UD datagram (length 1Fh = 31d bytes)
08 02 72 C-field = 08 (RSP), address 2, CI field 72H (var., LSB first)
78 56 34 12 identification number = 12345678
24 40 01 07 manufacturer ID = 4024h (PAD in EN 61107), generation 1, water
13 00 00 00 TC = 13 = 19 , Status = 00h, Configuration = 0000h
h d
0C 78 04 03 02 01 fabrication number = 01020304
9D 16 checksum and stop sign
The use of this number is recommended if the identification number is changeable. In this case, two or
more slaves can get the same secondary address and cannot be uniquely selected. The fabrication number
together with manufacturer, version and device type field build a unique number instead. Suitable
masters use this number for an enhanced selection method if two or more slaves have the same
identification number.
Annex B
(informative)
Secondary search - Instructions for implementation of wildcard search
The following program flow diagram in Figure B.1 shows the realization of the wildcard searching
procedure, whereby the search is made only with the identification number. The codes for manufacturer,
version and device type are in general specified with wildcards, but can be changed by the user in order
(for example) to locate all meters from a particular manufacturer. In order to avoid the categorization by
a factor of eight of the “For-To” loops for the eight positions, the array “Value” is defined with 8 byte
numbers, which are intended to define the contents of the positions. The digit number of the identification
number which is presently running is noted in the variable “Pos” of type byte.

Figure B.1 — Flow diagram for slave search with wildcards
The routine begins at the first position, and implements the following actions for the value of this position
from 0 to 9:
— selection with the ID-Nr. Pos 1, Pos 2, …, Pos 8;
— if no reply, Value [Pos] is raised by 1;
— if there is a reply, a REQ_UD2 is sent to address 253, and if the datagram is correctly received the
secondary address is learnt and the Value [Pos] raised by 1;
— if there is a collision a jump is made to the next position (Pos increased by 1), as long as the last
position has not yet been reached;
— after going through a complete position from 0 to 9 the subroutine proceeds to the next lower
position, or ends the search if the position Nr. 1 has already been processed.
The following table shows an example for secondary addresses in order from top to bottom as they will
be found by the master software:
Table B.1 — Secondary addresses found with a wildcard search of four slaves
No. Identification no. Manufacturer (hex.) Version (hex.) Device type (hex.)
1 14 491 001 1057 01 06
2 14 491 008 4567 01 06
3 32 104 833 2010 01 02
4 76 543 210 2010 01 03
Search Process:
1) Start with ID = 0FFFFFFF: no reply
2) ID = 1FFFFFFF: collision between Nr. 1 and Nr. 2
3) ID = 10FFFFFF, 11FFFFFF, 12FFFFFF, 13FFFFFF: no reply
4) ID = 14FFFFFF: collision between Nr. 1 and Nr. 2
5) Repeated steps 3 to 4 up to the ID = 1449100F
6) Learn ID = 14491001 and 14491008
7) Go backwards to 19999999
8) ID = 2FFFFFFF: no reply
9) ID = 3FFFFFFF: learn ID = 32104833
10) ID = 4FFFFFFF, 5FFFFFFF, 6FFFFFFF: no reply
11) ID = 7FFFFFFF: learn ID = 76543210
12) ID = 8FFFFFFF, 9FFFFFFF: no reply
13) End of the search
Annex C
(informative)
Consumer feedback for smart metering applications
C.1 General
This annex describes how the required functionalities of smart metering applications on consumer
feedback as suggested by the Smart Meter Co-Ordination Group (SM-CG) of CEN, CENELEC and ETSI can
be achieved using the standards EN 13757-2, EN 13757-3, EN 13757-4 and EN 13757-5. For twisted pair
connection of meters the physical and link layer of EN 13757-2 are suggested. For wireless connection,
the physical and link layer of EN 13757-4 are suggested. In wireless communication a differentiation is
to be made between “meter” and “communication partner”. Such a communication partner might be a
dedicated receiver, an in-home-device, a concentrator, a multi-utility server for several media or another
(possibly electricity) meter. In any case the partners are located in fixed locations and usually have a
mains supply.
To establish consumer feedback on the basis of meter indexes and/or the instantaneous power or flow
rate, a more frequent transmission of such values appears to be necessary in comparison to the
requirements for billing purposes. A distinction has to be made between the case where the meter itself
generates and transmits the instantaneous power/flow rate values and the case where the in-home-
device or some other device will generate these instantaneous values from index and time differences. In
the latter case, the index values need a sufficient resolution (usually much higher than useful for billing).
If the index value can be generated internally in synchronicity with the wireless transmission time points
the receiving device can calculate the required time difference with sufficient accuracy and resolution.
Even in the case of a fixed delay between value generation and transmission no calculation problem will
occur. Also if the time difference is sufficiently small (i.e. less than 1 s or 1 % of the transmission interval)
there will be no problem. In the remaining cases (i.e. longer or variable delays) a meter (usable for
consumer feedback of instantaneous values) will include a record with the time delay in its message.
The following sections demonstrate possible definitions in future meter standards. As long as an
applicable meter standard does not provide requirements for the utilization of meters according to this
annex, the following requirements will be used. If the applicable meter standard contains specific
requirements for one or several parameters described in this annex, the meter standard has priority.
C.2 Resolution of required values and accuracy of time information
C.2.1 General
Each message for billing purposes contains at least the current metered value with the meter accuracy
and thereof sufficient resolution for billing. Each message for consumer information contains sufficient
information and accuracy to enable the in-home-device to display the power/flow rate with sufficient
accuracy and resolution. This can either be implemented via extra data points for power/flow rate or by
sufficient resolution of the meter index and sufficient information about the time between indexed values.
Unified messages for both purposes can be used if both requirements are met.
C.2.2 Resolution in case of transmission of extra data points for power/flow rate
The value resolutions required for meters with additional data points for power/flow rate are listed in
Table C.1:
Table C.1 — Required value resolution for meters with power/flow rate data
Power/flow rate
Medium Billing
resolution
Electricity ≤ 1 kWh ≤ 1 W
Water 3 No requirement
≤ 1 m
3 3 ≤ 10 l/h
Gas Q ≤ 6 m /h ≤ 1 m
Max
3 3 ≤ 100 l/h
Gas Q ≤ 60 m /h ≤ 1 m
Max
3 3 ≤ 1 000 l/h
Gas Q > 60 m /h ≤ 1 m
Max
3 ≤ 1 kWh No requirement
Heat/Cooling Q < 10 m /h
p
3 ≤ 10 kWh No requirement
Heat/Cooling Q < 100 m /h
p
3 ≤ 100 kWh No requirement
Heat/Cooling Q ≥ 100 m /h
p
Heat cost allocation No requirement No requirement
It is advantageous to set the averaging duration for power/flow rate values similar to the average update
interval (mean time between two transmissions of messages with updated consumption data). A shorter
averaging period might produce strongly variant snapshot values with little user information (especially
for gas and water meters with their typically strong alterations in flow rate). A longer averaging period
will only deliver time delayed display values. If the averaging duration of the meters is below 50 % or
above 200 % of the average update interval the meter documentation will point this out.
C.2.3 Resolution in case of non-transmission of extra data points for power/flow rate
C.2.3.1 General
If the meter transmits only index values, the in-home-device is able to calculate power respectively
flow rate with sufficient resolution and accuracy from the index value and the time interval between the
index values. The index resolutions required for meters with no additional data points for
power/flow rate are listed in Table C.2.
Table C.2 — Required value resolution for meters without power/flow rate data
Medium Index resolution
Electricity ≤ 0,1 Wh
Water 3
≤ 1 m
3 ≤ 10 l
Gas Q ≤ 6 m /h
Max
3 ≤ 100 l
Gas Q ≤ 60 m /h
Max
3 ≤ 1 000 l
Gas Q > 60 m /h
Max
3 ≤ 1 kWh
Heat/Cooling Q < 10 m /h
p
3 ≤ 10 kWh
Heat/Cooling Q < 100 m /h
p
3 ≤ 100 kWh
Heat/Cooling Q ≥ 100 m /h
p
Heat cost allocation No requirement
C.2.3.2 Assumptions on time information for wireless connections
C.2.3.2.1 General
If there is no power/flow rate information coming from the meter directly, there are requirements for
accuracy and resolution of the current time difference between the index values to ensure a time interval
accuracy and resolution of ≤ 1 %. These requirements can be fulfilled by one of the following alternatives.
C.2.3.2.2 Correlated transmission
If the meter spontaneously transmits the index value with a fixed delay of less than half of the
transmission interval and if such a delay varies by less than 1 % of the transmission interval then the in-
home-device can calculate the index time difference from the message arrival time with sufficient
resolution and accuracy.
C.2.3.2.3 Uncorrelated transmission
If the difference of delays of transmission time points varies by more than 1 % of the transmission
interval, each message will contain sufficient time information to calculate this time difference. This can
either be implemented with a date/time data point or time data point with a resolution of 1 s in each
message or with a data point signalling the current time delay between index time and transmission time
with a resolution of 1 s.
C.2.4 Transmission on request
If the meter transmits the index value because of a request, it has to refer to the time of the value
generation at the moment of the first transmission of the request (REQ_UD2) by the in-home-device. The
meter can generate the response with a fixed delay which does not vary by more than 1 s. In that case, a
potential runtime of the request from the in-home-device to the meter is considered. Hence a unique
reference time is given even if the response is repeated several times.
Annex D
(informative)
Installation and registration
D.1 General
The way to equip a building with new meters or exchange existing ones differs significantly depending
on the history and the working process of the meter site operator. This document intends to support
different installation processes. The answers to the following questions decide on the installation
procedure.
Who defines the pairing of the meter and the communication partner?
Is an online connection to the back office of the Meter Site Operator necessary or possible?
Is a fast feedback after the installation to the local service technician required?
To readout a meter, the operator needs the address of the meter and the communication address of the
meter site, e.g. IP-Address of the host communication partner. The operator has to register all
communication partners as well as all meter addresses and their host communication partner. The
pairing of a meter and a communication partner can be done
a) either automatically (no predefinition),
b) predefined
...