SIST EN 13757-8:2023

Communication systems for meters - Part 8: Adaptation layer

This document describes the functionalities and specifies the requirements of an adaptation layer to be applied when transporting M-Bus upper layers using a wireless communication protocol other than wireless M-Bus. These alternative radio technologies developed outside CEN/TC 294 can be based on Internet Protocol or not and operate either in licensed or unlicensed frequency bands.

Kommunikationssysteme für Zähler - Teil 8: Anpassungsschicht

Dieses Dokument beschreibt die Funktionen und legt die Anforderungen an eine Anpassungsschicht fest, die beim Transport der oberen M Bus-Schichten bei Nutzung anderer drahtloser Kommunikationsprotokolle als dem wireless-M Bus anzuwenden sind. Diese außerhalb von CEN/TC 294 entwickelten alternativen Funktechnologien können auf dem Internetprotokoll basieren oder nicht und werden in lizenzierten oder in nicht-lizenzierten Frequenzbändern betrieben.

Systèmes de communication pour compteurs - Partie 8 : Couche adaptation

Le présent document décrit les fonctionnalités et spécifie les exigences d’une couche adaptation à appliquer lors du transport des couches supérieures M Bus utilisant un protocole de communication sans fil autre que le M Bus sans fil. Ces technologies radio alternatives développées en dehors du CEN/TC 294 peuvent être basées sur le protocole Internet ou sur un autre protocole, et fonctionner sur des bandes de fréquences sous licence ou libres.

Komunikacijski sistemi za merilnike - 8. del: Prilagoditvena plast

Ta dokument opisuje funkcionalnosti in določa zahteve za uporabo prilagoditvene plasti pri prenosu zgornjih plasti M-vodila z brezžičnim komunikacijskim protokolom, ki ni brezžično M-vodilo. Te alternative radijske tehnologije, razvite zunaj odbora CEN/TC 294, lahko temeljijo na
internetnem protokolu ali ne in delujejo v frekvenčnih pasovih z licenco ali brez nje.

General Information

• Status: Published
• Public Enquiry End Date: 08-Mar-2022
• Publication Date: 19-Oct-2023
• ICS: 33.200 - Telecontrol. Telemetering
• ICS: 35.100.01 - Open systems interconnection in general
• Technical Committee: I13 - Imaginarni 13
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 11-Oct-2023
• Due Date: 16-Dec-2023
• Completion Date: 20-Oct-2023
• Directive: 2014/53/EU - Directive 2014/53/EU of The European Parliament and of the Council of 16 April 2014 on the harmonisation of the laws of the Member States relating to the making available on the market of radio equipment and repealing Directive 1999/5/EC
• Mandate: 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
• Ref Project: EN 13757-8:2023 - Communication systems for meters - Part 8: Adaptation layer

Overview

EN 13757-8:2023 (CEN) defines the M-Bus Adaptation Layer (MBAL) to enable transport of M‑Bus upper layers (Transport and Application) over wireless radio technologies other than wireless M‑Bus. The standard covers adaptation requirements for alternative wireless technologies - IP‑based or non‑IP, operating in licensed or unlicensed frequency bands - including Low Power Wide Area Networks (LPWANs). Its purpose is to ensure a smooth transition and interoperability of existing metering systems when migrating from wireless M‑Bus to modern IoT radio technologies.

Key topics and requirements

• Scope and objective
  • Apply an adaptation layer when transporting M‑Bus upper layers over non‑wireless M‑Bus radio protocols.
  • Support both IP and non‑IP based radio technologies in licensed or unlicensed bands.
• Network architecture
  • Defines logical entities: Head End System (HES), Core Network, Gateway, and End Device.
  • Clarifies uplink/downlink roles and interactions for metering deployments.
• Layer and encapsulation structure
  • Describes general layer mapping and encapsulation schemes for:
    • M‑Bus over non‑IP communication technologies
    • M‑Bus over IP communication technologies
• Adaptation layer (MBAL) details
  • MBAL structure and services to present a consistent interface to M‑Bus upper layers.
  • MBAL control field (MBAL‑CL) and other MBAL fields specified to support fragmentation, addressing, and control semantics.
• Implementation guidance
  • Informative annexes provide practical adaptation mechanisms and examples for LPWAN technologies such as NB‑IoT (Cat‑NB), LTE‑M (Cat‑M1), LoRaWAN, MIOTY (TS‑UNB) and Wize.
  • Examples include alarm pulling, user data push/pull, and confirmed data transmission scenarios.
• Security and transport alignment
  • Intended to work with EN 13757‑7 (Transport and security services) and other parts of the EN 13757 series.

Applications and who uses it

• Utility companies and smart metering program managers migrating legacy wireless M‑Bus fleets to LPWAN or cellular IoT.
• Meter manufacturers implementing M‑Bus stacks and radio adapters to ensure compatibility with new radio technologies.
• System integrators and IoT solution providers designing gateways, head-end systems, and network integration layers.
• Mobile network operators and LPWAN providers implementing device onboarding and data transport for metering use cases.
• Regulators and standards bodies assessing interoperability and migration strategies for metering communications.

Related standards

• EN 13757‑1 (Data exchange), EN 13757‑3 (Application protocols), EN 13757‑4 (Wireless M‑Bus), EN 13757‑5 (Relaying), EN 13757‑7 (Transport & security).
• Keywords: EN 13757‑8:2023, M‑Bus Adaptation Layer, MBAL, LPWAN, smart metering, NB‑IoT, LTE‑M, LoRaWAN, Wize, MIOTY, CEN.

Standards Content (Sample)

SLOVENSKI STANDARD
01-december-2023
Komunikacijski sistemi za merilnike - 8. del: Prilagoditvena plast
Communication systems for meters - Part 8: Adaptation layer
Kommunikationssysteme für Zähler - Teil 8: Anpassungsschicht
Systèmes de communication pour compteurs - Partie 8 : Couche adaptation
Ta slovenski standard je istoveten z: EN 13757-8:2023
ICS:
33.200 Daljinsko krmiljenje, daljinske Telecontrol. Telemetering
meritve (telemetrija)
35.100.01 Medsebojno povezovanje Open systems
odprtih sistemov na splošno interconnection in general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 13757-8
EUROPEAN STANDARD
NORME EUROPÉENNE
September 2023
EUROPÄISCHE NORM
ICS 33.200; 35.100.01
English Version
Communication systems for meters - Part 8: Adaptation
layer
Systèmes de communication pour compteurs - Kommunikationssysteme für Zähler - Teil 8:
Partie 8 : Couche adaptation Anpassungsschicht
This European Standard was approved by CEN on 19 June 2023.

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, 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 NORMALISATIO N

E UR O PÄISCHES KOMITEE FÜR NORMUN G

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. EN 13757-8:2023 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Abbreviations and symbols . 7
4.1 Abbreviations . 7
4.2 Symbols . 9
5 Network architecture . 9
5.1 Overview . 9
5.2 General description of network entities . 10
5.2.1 Head End System . 10
5.2.2 Core network . 10
5.2.3 Gateway . 11
5.2.4 End device . 11
6 General layer structure . 12
6.1 Overview . 12
6.2 Encapsulation schemes . 13
6.2.1 M-Bus over non-IP based communication technologies . 13
6.2.2 M-Bus over IP based communication technologies . 14
7 Adaptation layer description . 15
7.1 Adaptation layer structure . 15
7.2 Adaptation layer services . 15
7.2.1 MBAL Control field (MBAL-CL) . 15
7.2.2 Other MBAL fields . 19
Annex A (informative) Overview of LPWAN technologies . 20
A.1 LPWAN features for metering communication . 20
A.2 Segregation matrix . 20
Annex B (informative) MBAL implementation examples . 21
B.1 MBAL for alarm data pulling scenario . 21
B.2 MBAL for user data push and pull . 21
B.3 Confirmed User Data transmission. 22
Annex C (informative) Adaptation mechanism for Cat. NB (NB-IoT) and Cat. M1 (LTE-M) . 23
C.1 Cat. M1 and Cat. NB brief description. 23
C.2 Cat. M1 and Cat. NB characteristics. 23
C.3 Cat. M1 and Cat. NB network architecture . 23
C.4 M-Bus over CIoT . 26
Annex D (informative) Adaptation mechanism for LoRaWAN . 47
D.1 LoRaWAN brief description . 47
D.2 LoRaWAN network architecture . 47
D.3 LoRaWAN security services description . 49
D.4 LoRaWAN main features . 50
D.5 LoRaWAN frame structure overview . 50
D.6 M-Bus over LoRaWAN . 51
Annex E (informative) Adaptation mechanism for TS-UNB . 57
E.1 TS-UNB/MIOTY brief description . 57
E.2 MIOTY network architecture . 57
E.3 MIOTY principles . 58
E.4 MIOTY frame structure overview . 59
E.5 M-Bus over MIOTY . 60
Annex F (informative) Adaptation mechanism for Wize . 64
F.1 Wize brief description . 64
F.2 Wize services . 64
F.3 Wize network architecture . 65
F.4 M-Bus over Wize . 70
Bibliography . 72
European foreword
This document (EN 13757-8:2023) 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 March 2024, and conflicting national standards shall be
withdrawn at the latest by March 2024.
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 has been prepared under a Standardization Request given to CEN by the European
Commission and the European Free Trade Association.
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.
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, 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 the United
Kingdom.
Introduction
This document 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-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. The Technical Report CEN/TR 17167 contains
informative annexes for EN 13757-2, EN 13757-3 and EN 13757-7.
The M-Bus protocol upper layers (Transport and Application) can be used with various lower layers
(Network, Data Link and Physical) as described in EN 13757-1. Systems based on the M-Bus protocol
stack are well established in the metering market in Europe. In parallel, other wireless communication
networks known as LPWAN (Low Power Wide Area Networks) have been widely deployed and target
metering applications as well. The OSI reference model enables the transport of M-Bus upper layers on
top of LPWANs lower layers. To ensure a seamless transition of the legacy systems based on Wireless M-
Bus to LPWAN, an M-Bus Adaptation Layer (MBAL), is needed to provide the necessary services and
information to the upper layers via an adequate interface, to minimize the impact on their existing
implementations.
1 Scope
This document describes the functionalities and specifies the requirements of an adaptation layer to be
applied when transporting M-Bus upper layers using a wireless communication protocol other than
wireless M-Bus. These alternative radio technologies developed outside CEN/TC 294 can be based on
Internet Protocol or not and operate either in licensed or unlicensed frequency bands.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 13757-1:2021, Communication systems for meters — Part 1: Data exchange
EN 13757-3, Communication systems for meters — Part 3: Application protocols
EN 13757-4:2019, Communication systems for meters — Part 4: Wireless M-Bus communication
EN 13757-5, Communication systems for meters — Part 5: Wireless M-Bus relaying
EN 13757-7:2018, Communication systems for meters — Part 7: Transport and security services
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
3.1
core network
set of logical and physical entities providing the communication services between the HES and the end
devices
3.2
downlink
transmission in the direction from a gateway or a Head End System to the end device
3.3
end device
communication end node
EXAMPLE A radio adapter, a meter or similar device.
3.4
frame
unit of transmission at the Data Link Layer
3.5
gateway
intermediate node in a data communication network, connected to two or more logical networks, where
the protocols or modes used on the logical networks are different
3.6
Head End System
system responsible for the management, reading and data collection of end devices applications
3.7
Low Power Wide Area Network
wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very
small packet and application-layer data sizes, and long battery life operation
3.8
L(n)
refers to layer level (n) in the OSI model
3.9
uplink
transmission in the direction from an end device to the gateway or Head End System
4 Abbreviations and symbols
4.1 Abbreviations
AES Advanced Encryption System
AFL Authentication and Fragmentation Layer
APL M-Bus Application Protocol Layer
AS Application Server
Cat NB Narrow band LTE category 1 and 2
Cat M1 LTE category for Machine Type Communication
CBOR Concise Binary Object Representation
CI Control Information (field)
CIoT Cellular IoT
CN Core Network
CoAP Constrained Application Protocol
COSE CBOR Object Signing and Encryption
CSGN CIoT Serving Gateway Node
DLL Data Link Layer
DoNAS Data over NAS
ECM EPS Connectivity Management
ED End Device
eDRX extended Discontinuous Reception
ELL Extended Link Layer
eNB Evolved Node B
EPC Evolved Packet Core
EPS Evolved packet System
E-UTRAN Evolved UMTS Terrestrial Radio Access Network
FUOTA Firmware Update Over The Air
GPRS General Packet Radio Service
GTP-U GPRS Tunnelling Protocol – User Plane
GW Gateway
HARQ Hybrid Automatic Repeat Request
HES Head End System
HTTP Hyper Text Transfer Protocol
IoT Internet of Things
IP Internet Protocol
LLC Logical Link Control
Ln Layer n according to OSI reference model definitions
LPWAN Low Power Wide Area Network
LPWAN ID LPWAN Unique Identifier
LTE Long Term Evolution
MAC Medium Access Control
MBAL M-Bus Adaptation Layer
MCL Maximum Coupling Loss
MME Mobility Management Entity
MNO Mobile Network Operator
NAS Non-Access Stratum
NIDD Non-IP Data Delivery
NWL Network Layer
PCI Protocol Control Information
PDCP Packet Data Convergence Protocol
PDN Packet Data Network
PDU Protocol Data Unit
PGW PDN Gateway
PHY Physical Layer
PSM Power Saving Mode
PTW Paging Transmission Window
RAN Radio Access Network
REST Representational State Transfer
RF Radio Frequency
RFU Reserved for Future Use
RLC Radio Link Control
RRC Radio Resources Control
S1AP S1 Application Protocol
SCTP Stream Control Transmission Protocol
SDU Service Data Unit
SGW Serving Gateway
TAU Tracking Area Update
TCP Transmission Control Protocol
TPL Transport Layer
UDP User Datagram Protocol
UE User Equipment
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 Network architecture
5.1 Overview
The typical LPWAN network architecture is illustrated in Figure 1 showing the physical devices (as
squares) and software instances (as circles).
Key
1 Head End System 5 Gateway
2 Core Network 6 End Device
3 Network Manager 7 Active Link
4 Security Server 8 Spare Link
Figure 1 — LPWAN network architecture overview
An overview of LPWAN technologies is given in Annex A.
5.2 General description of network entities
5.2.1 Head End System
The HES is deployed and managed by the metering service or application provider. HES, and its related
components are responsible for handling TPL/AFL/APL layers. It can be built of several components each
of which is dealing with a given set or subset of functionalities or services, typically fragmentation.
The HES is connected to the Core Network via dedicated interfaces and protocols and uses its services to
exchange data messages with the end devices. It may also be connected to the security server to manage
the communication security requirements.
5.2.2 Core network
5.2.2.1 Network manager
The Network Manager is responsible for managing communication links and infrastructure using
Network, DLL, and MAC services according to the protocol specifications. It allocates the necessary
resources to establish a communication between the HES and the end device. These services enable the
configuration and setting of different communication parameters to optimize network and end devices
resources usage and enforce wireless communication rules.
The network manager may communicate with the end devices through the gateways. Both elements can
be under the control of the network manager. In order to secure the communication link, the network
manager can be connected to the security server to retrieve the adequate security material.
5.2.2.2 Security server
The security server is responsible for managing the security services. It holds the necessary
cryptographic keys and credentials of the end devices. It distributes those to the network server and the
HES, via dedicated and secure interfaces, to achieve the required level of data confidentiality, integrity
and authentication. These security materials are conveyed and stored in the security server in a way
compliant with standard security policies.
5.2.3 Gateway
The gateway is a network element responsible for the transfer of RF frames between the network
manager and the end device. Any frame transmitted to the end device via the gateway is called downlink
frame. Reciprocally, any frame transmitted by the end device to network manager via the gateway is
called uplink frame. One uplink frame can be received on several gateways while a downlink is
transmitted by a single gateway (refer to element 7 and 8 in Figure 1).
A gateway is potentially capable of operating on different frequency bands and/or channels and
transmitting or receiving multiple frames at the same time.
5.2.4 End device
The end device is responsible for managing all layers. It communicates with the gateway on the LPWAN
layers and with the HES on the upper layers (APL/TPL/AFL). An end device is potentially capable of
running several applications using one or multiple LPWAN. The necessary security material is either
stored in the end device’s memory or conveyed from the security server.
Each end device has a unique identifier called LPWAN ID which is equivalent to the MAC address. The
upper layers use the application address, contained in the TPL, to identify the end device when
communicating with the HES.
Attention should be paid to the cases where multiple meters or sensors are served by a single end device
acting as a radio adapter. In that case, the long header format of the TPL shall be used in each application
message in both directions (ED <-> HES) while the end device uses its LPWAN ID at the lower layers.
To announce the relationship between the LPWAN ID and the application address, the latter shall be
transmitted at least during the initialisation phase.
If there is a 1:1 relation between the LPWAN ID and the application address, then the transmission of the
application address may be skipped in any later message transfers. Otherwise, the application address
needs to be provided at any time. Both cases are illustrated in Figure 2.
Key
1 LPWAN module of the end device with a unique LPWAN identifier
2 End device application like a meter with a unique application address
Figure 2— End device LPWAN identifier and application address relations
6 General layer structure
6.1 Overview
This specification describes a mechanism, called M-Bus Adaptation Layer (MBAL), to be used to transport
M-Bus datagrams over different wireless communication protocols, known as LPWAN, using the layered
approach that has been defined in EN 13757-1:2021, 4.2 and the layer model structure specified in
EN 13757-7:2018, 5.1. In the following parts, the upper layers will refer to APL, AFL and TPL that operate
end-to-end while the lower layers refer to Network, Data Link and Physical layers as specified in the OSI
basic reference model [1].
The MBAL is inserted between the M-Bus upper layers and the LPWAN lower layers as depicted in
Table 1. Its goal is to keep the M-Bus data exchange principles effective while using wireless technologies
defined outside of the EN 13757 series to minimize the impact to this transition and to ensure
interoperability at the upper layers level. In this context of “M-Bus over LPWAN”, the MBAL provides the
necessary services to the upper layers as described in Clause 7 of this document.
Table 1 — General layer structure
OSI Model M-Bus Layers (acc. to EN 13757-7) Layers for M-Bus over LPWAN
Application
APL (EN 13757-3) APL according to EN 13757-3
Presentation
TPL (EN 13757-7) TPL according to EN 13757-7
Session
Transport
AFL (EN 13757-7) AFL according to EN 13757-7

a
Adaptation Layer - MBAL according to EN 13757-8
Network NWL (EN 13757-5)
ELL (EN 13757-4)
Data Link LPWAN related specifications
DLL (EN 13757-4)
Physical PHY (EN 13757-4)
a
Adaptation layer is an extension of the original OSI model for the purposes of M-Bus over LPWAN.

6.2 Encapsulation schemes
6.2.1 M-Bus over non-IP based communication technologies
For the sake of end device power efficiency and spectrum occupancy optimizations, some LPWAN
technologies feature a collapsed communication protocol stack where only L1, L2 and potentially L3 for
relaying, are needed and specified.
In that scenario, the M-Bus upper layers PDU is concatenated with the MBAL fields and transmitted to
the LPWAN layers. The latter encapsulates this M-Bus payload as an SDU, adds the appropriate PCI and
sends it to the GW which will use an IP backhaul connection to forward the M-Bus payload to the HES
through the CN. The HES receives the M-Bus payload including the MBAL fields and will process it
according to M-Bus layers specifications.
Symmetrically, in the downlink scenario, the HES upper layers message is appended to the MBAL fields
and transmitted as an M-Bus payload to the CN using the adequate interface and application protocol.
The CN will route the payload to the serving GW to be conveyed using the LPWAN link when the ED
provides an access slot. ED’s LPWAN layers will de-encapsulate the M-Bus payload and present it to the
upper layers which will take care of processing MBAL and M-Bus upper layers fields. Both scenarios are
described in Table 2.
Table 2 — M-Bus over non-IP LPWAN encapsulation
ED  Core Network  HES
APL/TPL/AFL     APL/TPL/AFL
MBAL     MBAL
TCP/UDP  TCP/UDP
IP  IP
LPWAN  L2  L2
LPWAN
L1  L1
The adaptation mechanism is given in respectively Annex D (LoRaWAN), Annex E (TS-UNB) or Annex F
(Wize).
6.2.2 M-Bus over IP based communication technologies
When the LPWAN being used is based on IP, M-Bus payload, including APL/TPL/AFL and MBAL, will be
encapsulated in the IP packet which will be encapsulated itself in the LPWAN frame. In that scenario, the
ED will act as a standard IP node using IPv4/IPv6 address and implements standard IP transport
protocols (like TCP or UDP) procedures to send its payload to the CN. The latter retrieves the IP packet
and sends it using a dedicated interface to the HES which will de-encapsulate the message and retrieve
the initial M-Bus payload. All the intermediate IP nodes are transparent to the M-Bus upper layers and
MBAL which acts on an end-to-end basis between the HES and the ED as described in Table 3.
It should be noted that this encapsulation mechanism may be extended to introduce an intermediate
application protocol layer, considered as an optional “transfer layer” below the MBAL. In that case, the
M-Bus payload is placed in the transfer protocol message which is encapsulated in a TCP/UDP datagram.
Table 3 — M-Bus over IP-based LPWAN encapsulation
ED  Core Network  HES
APL/TPL/AFL     APL/TPL/AFL
MBAL     MBAL
a
Transfer layer     Transfer layer
TCP/UDP  TCP/UDP TCP/UDP  TCP/UDP
IP  IP IP  IP
L2  L2
IP based LPWAN IP based LPWAN
(Cat. M1 & Cat. NB) (Cat. M1 & Cat. NB)
L1  L1
a
The usage of the transfer protocol is optional.

The adaptation mechanism for Cat. M1 (LTE-M) and Cat. NB (NB-IoT) is given in Annex C.
7 Adaptation layer description
7.1 Adaptation layer structure
For the M-Bus Adaption layer the CI-fields according to Table 4 are reserved.
Table 4 — CI-fields of MBAL
CI-field Designation Remarks
CC to CE RFU Reserved for Future Use
h h
CF MBAL MBAL Structure acc. to Table 5
h
The adaptation layer applies a structure according to Table 5.
Table 5 — Structure of M-Bus Adaption layer with CI-field CF
h
Size Field Name Description
(bytes)
a
1 CI Indicates an M-Bus-adaptation layer
1 MBAL-CL MBAL Control field
a
The presence of the CI-field is optional and depends on the applied LPWAN technology.

The LPWAN implementation description provides information on whether a CI field is present. If the CI-
field is not used, the MBAL Control field will be the only byte of the MBAL. For a given LPWAN technology,
the presence of the CI field is described in the related annex.
NOTE The MBAL Control field (version 1) will not use the value of CFh. If the first byte has a value of CFh the
presence of the CI-field as first byte can be assumed.
7.2 Adaptation layer services
7.2.1 MBAL Control field (MBAL-CL)
7.2.1.1 Structure of MBAL Control field
The MBAL Control field provides several subfields which differs between uplink and downlink
communication. The MBAL Control field for the uplink is defined in Table 6 and for the downlink in
Table 7.
Table 6 — MBAL Control field in uplink
MS Bit Bit Bit Bit Bit Bit Bit LS Bit
7 6 5 4 3 2 1 0
V V A A F F F F
Table 7 — MBAL Control field in downlink
MS Bit Bit Bit Bit Bit Bit Bit LS Bit
7 6 5 4 3 2 1 0
V V L L F F F F
The applicable versions are defined in the MBAL-CL subfield version (refer to 7.2.1.2). The content of the
other subfields is described in the following subclauses.
7.2.1.2 Subfield Version
The MBAL Version subfield is used to identify the version of the applied MBAL structure. So far only one
version is supported according to Table 8.
Table 8 — MBAL-CL Version subfield
MBAL-Control bit 7 bit 6 Version
0 0 Version 1 (initial version of MBAL)
0 1 RFU
1 0 RFU
1 1 RFU
7.2.1.3 Subfield Access (uplink)
The MBAL-CL Access subfield is only available in the uplink communication. It describes the current
accessibility of an end device. This information can be used to estimate the availably of an access window
of the end device in the case a command is intended to be sent by the HES. The accessibility is defined in
Table 9 and based on the accessibility of a wireless M-Bus end device as defined in EN 13757-4:2019,
Table 37. When using M-Bus security modes 0 or 5, Bits A and B (Access and Bidirectional) located in the
Configuration field of the TPL (refer to Table 23 of EN 13757-7:2018) should be ignored.
Version
Version
Version
Version
Latency Access
Latency Access
Function code
Function code
Function code Function code
Function code Function code
Function code
Function code
Table 9 — MBAL-CL Access subfield
MBAL-Control bit 5 bit 4
Accessibility
(uplink)
0 0 No access or temporary no access
0 1 Short or limited access window after transmission
1 0 Unlimited or continuous access
1 1 Unused or unavailable
NOTE In case of an MBAL Access subfield 00b, it is useful to postpone the downlink transmission to avoid a
timeout.
7.2.1.4 Subfield Latency (downlink)
The MBAL-CL Latency subfield is only available in the downlink communication. It describes the
proposed latency for the end device response. This information is used by the TPL layer to control the
response timing of the end device. The latency subfield is defined in Table 10.
Table 10 — MBAL-CL Latency subfield
MBAL-Control bit 5 bit 4
Latency
(downlink)
0 0 RFU
Response or TPL ACK can be sent
0 1
with delay
Response or TPL ACK is expected
1 0
as soon as possible
1 1 Unused or invalid
7.2.1.5 Subfield Function code
The MBAL-CL Function code subfield is used in uplink and downlink communication to separate and
distinguish different types of a message.
The function code describes the type and function of a message.
The separation of the message types is essential to avoid confusion between different data streams.
NOTE 1 For example, using the message type helps by not taking an unsolicited SND-NR message from the end
device as a response to a pending request in downlink.
NOTE 2 The function codes of the MBAL are based on the wireless M-Bus function codes as described in
EN 13757-4:2019, 12.5.4 although they are not identical. Since the communication possibilities in the LPWAN
exceed those of the wireless M-Bus, further function codes have been added in Table 11 and Table 12.
Table 11 defines the values of the MBAL-CL subfield Function code used for the uplink and Table 12 for
the downlink.
Table 11 — MBAL-CL Function code subfield (uplink)
MBAL-
Function Control bit 3 Symbolic Confirmed
Function
code to bit 0 name by
(uplink)
The end device acknowledges the reception of -
0 0 0 0 0 TPL-ACK
h
the message
Negative acknowledgement from the end -
a
1 0 0 0 1 TPL-NACK device in case an unknown or unsupported
h
function code was received
Send unsolicited application data and expect an TPL-ACK
b
2 0 0 1 0 SND-UD acknowledgement from HES (refer to
h
Annex B)
3 0 0 1 1 - RFU -
h
Send unsolicited application data and -
4 0 1 0 0 SND-NR
h
b
expecting no response from HES
This message requests an access to the end REQ-UD1
device
c
5 0 1 0 1 ACC-DMD2
h
(Compact communication sequence; refer to
Annex B)
Send manual initiated installation data with CNF-IR
6 0 1 1 0 SND-IR
h
b
request to be registered by the HES
Send solicited/periodical message without -
7 0 1 1 1 ACC-NR application data to provide the opportunity of
h
access to the end device
Response of application data after a request -
8 1 0 0 0 RSP-UD
h
from the HES
9 1 0 0 1 - RFU -
h
This message requests an access to the end TPL-ACK
c
A 1 0 1 0 ACC-DMD
h
device
1 0 1 1 -
B to E to - RFU
h h
1 1 1 0
F 1 1 1 1 - Function code is not used -
h
a
The TPL-NACK is responded to any type of message in the case no valid function code is detected.
b
The statements about an expected response refer to the final recipient (HES) and make no statement about
whether or not the intermediary network acknowledges the reception of a message to the sender.
c
According to EN 13757-4:2019, E.6 the ACC-DMD will be responded with a TPL-ACK. The request of alarm
data happens later. To shorten the communication steps in the LPWAN, the additional ACC-DMD2 is introduced,
which expects a REQ-UD1 as an immediate response.
Table 12 — MBAL-CL Function code subfield (downlink)
MBAL-
Function Control bit 3 Symbolic Confirmed
Function
code to bit 0 name by
(downlink)
The recipient acknowledges the reception of -
0 0 0 0 0 TPL-ACK
h
the message
Negative acknowledgement from the recipient -
a
1 0 0 0 1 TPL-NACK in case an unknown or unsupported function
h
code was received
Send data and expect an acknowledge from TPL-ACK
2 0 0 1 0 SND-UD
h
b
recipients
Send data and expect a response from RSP-UD
3 0 0 1 1 SND-UD2
h
b
recipients
Send data and expect no response from -
4 0 1 0 0 SND-NR
h
b
recipients
Send data to multiple receivers at the same -
5 0 1 0 1 SND-UD3
h
b
time and expect no response from recipients
6 0 1 1 0 CNF-IR Confirms the registration by the recipient -
h
7h 0 1 1 1 SND-NKE Terminates the communication session -
1 0 0 0 -
8 to 9 to - RFU
h h
1 0 0 1
Alarm request, (Request User Data Class 1) RSP-UD or
A 1 0 1 0 REQ-UD1
h
c
from the end device TPL-ACK
Data request (Request User Data Class 2) from RSP-UD
B 1 0 1 1 REQ-UD2
h
the end device
1 0 1 0 -
C to E to - RFU
h h
1 1 1 0
F 1 1 1 1 - Function code is not used -
h
a
The TPL-NACK is responded to any type of message in the case no valid function code is detected.
b
The statements about an expected response refer to the upper layers of end device and make no statement
about whether or not the lower layers acknowledge the reception of a message to the sender.
c
In case there are no alarm data the end device responds with an TPL-ACK.

The mandatory or optional support of message types of Table 11 and Table 12 shall be according to the
rules defined in Table 34 and Table 35 of EN 13757-4:2019. The support of message types not defined in
EN 13757-4:2019 is optional.
7.2.2 Other MBAL fields
With version 1 (refer to 7.2.1.2) no further MBAL fields are supported.
Annex A
(informative)
Overview of LPWAN technologies
A.1 LPWAN features for metering communication
To be used with the defined MBAL mechanism, the LPWAN protocol should fulfil the following conditions:
1) Available in CEN member countries;
2) Technical specifications publicly accessible;
3) Compatible with the use cases within the scope of CEN/TC 294 Communication systems for meters.
On the technical level, the LWPAN technology are characterized by the following properties:
a) Low power consumption: to enable +10 years lifetime;
b) Low-cost modem: to keep affordable price for radio units;
c) Long range: to cope with deep indoor conditions;
d) Robust link: to be resistant to interferences;
e) High capacity: to support thousands of end devices within cities;
f) Support bi-directional communication;
g) Built on a star topology.
A.2 Segregation matrix
Some known and deployed LPWAN technologies are compared according to technical criteria in
Table A.1.
Table A.1 — LPWAN technologies comparison matrix
LPWAN
Cat. M1 Cat. NB LoRaWAN MIOTY Sigfox Wi-Sun WIZE
Technology
a
IP based 1 0/1 0 0 0 1 0
Licensed 1 1 0 0 0 0 0
Spectrum
c b d d d
Confirmed 1 0/1 0/1 0/1 0 1 0/1
Message
Star topology 1 1 1 1 1 0 1
NOTE A value 0 means “False” or “not supported” while 1 value means “True” or “Supported”. 0/1 means that
both options are possible.
a
Cat. NB supports a non-IP based model called NIDD.
b
Cat. NB: Confirmation and repetitions are handled on the RLC layer (HARQ) but not possible on the transport
layer when using UDP.
c
Cat. M1: Confirmation and repetitions are handled on the RLC layer (HARQ) in addition to the transport layer
when using TCP.
d
Confirmation and repetitions are handled on the MAC layer.
Annex B
(informative)
MBAL implementation examples
B.1 MBAL for alarm data pulling scenario
Message types introduced by the function code of the MBAL have been extended to introduce some new
functionalities compared to those provided by EN 13757-4:2019. Figure B.1 describes the usage of MBAL
to access alarm data using the newly defined ACC-DMD2 message type. The communication is established
at the upper layers level between the ED Upper Layers (ED_UL) and the HES Upper Layers (HES_UL).

Figure B.1 — M-Bus alarm data pulling using MBAL
B.2 MBAL for user data push and pull
MBAL allows efficient data exchange between the ED and HES. In the scenario depicted in Figure B.2, the
ED transmits its application data using the SND-NR and provide a short access window. The HES takes
advantage of this opportunity to ask for additional user data by the means of REQ-UD2 message. When
the latter request is received, the ED answer back as soon as possible, given duty cycle and battery
constraints, by sending the application data using RSP-UD message.
Figure B.2 — M-Bus user data push and pull using MBAL
B.3 Confirmed User Data transmission
The usage of the newly defined SND-UD message type in uplink enables the ED to transmit user data and
ask the HES for reception confirmation when the ED provides an access slot. The HES takes notice of the
availability of this reception window to send an acknowledgement using MBAL TPL-ACK message. This
scenario is illustrated in Figure B.3.

Figure B.3 — Confirmed user data transmission with MBAL
Annex C
(informative)
Adaptation mechanism for Cat. NB (NB-IoT) and Cat. M1 (LTE-M)
C.1 Cat. M1 and Cat. NB brief description
Cat. M1 and Cat. NB are both cellular technologies operating in licensed bands. Cat. M1 and Cat. NB are
both 3GPP standardized technologies.
Cat. NB (NB-IoT – Narrowband IoT) supports devices with narrow bandwidth, below 200 kHz. A Cat. NB
carrier can be deployed even in guard-band of an LTE carrier to use the spectrum that is otherwise
unused.
Cat. M1 (or LTE-M) operates at 1,4 MHz bandwidth with higher device complexity/cost than Cat. NB. The
wider bandwidth allows Cat. M1 to achieve higher data rates (up to 1 Mbps), lower latency and more
accurate device positioning capabilities. Cat. M1 supports voice calls and connected mode mobility.
C.2 Cat. M1 and Cat. NB characteristics
A simple comparison between Cat. M1 and Cat. NB is shown in Table C.1.
Table C.1 — Comparison of Cat. M1 and Cat. NB as defined in 3GPP Release 13/14 [8]
Parameter Cat. M1 Cat. NB
Total bandwidth required 1,4 MHz 180 kHz
Downlink peak rate 1 Mbps (full duplex) or Up to 127 kbps
375 kbps (half duplex)
Uplink peak rate 1 Mbps (full duplex) or Up to 159 kbps
375 kbps (half duplex)
Duplex mode Full duplex or half duplex Full duplex or half duplex
Mobility support Full mobility Limited mobility
Latency Low (10–15ms) High (1,6–10s)
Device transmit power 20 / 23 dBm 14 / 20 / 23 dBm
Indoor/underground High (MCL 155,7 dB) Very high (MCL 164 dB)
penetration
C.3 Cat. M1 and Cat. NB network architecture
C.3.1 General introduction
This section gives a general introduction to the architecture, main features and access methods for
cellular based systems. Implementing these features is neither mandatory, nor restricted to the described
features. Not all features can be expected to be implemented by MNOs.
C.3.2 Architecture overview
Figure C.1 shows an overview of a cellular network architecture.

Figure C.1 — Simple architecture overview for an LTE network
User equipment (UE), i.e. the cellular IoT end device, is connected to the Cellular IoT Radio network
(E-UTRAN) using available gateways (eNB). Data over control plane (S1-MME) or data over user plane
(S1-U) are exchanged between the base stations and the core network (EPC). Control
...