M-Bus parsing strategies for LoRaWAN and NB-IoT

Truncate, Split, Multiframe, or MQTT with parsed JSON: matching the transport strategy to the network and the receiving parser

Key takeaways

• An M-Bus parser interprets an M-Bus telegram and converts its encoded records into usable meter values.
• Parsing, filtering, and fragmentation are three different steps. Parsing interprets the data, filtering selects which records to keep, and fragmentation splits data that do not fit into a single network message.
• Filtering comes first. VIF/DIF filtering can reduce the required M-Bus data below the payload limit and remove the need for fragmentation altogether.
• For EU863-870 at DR0 (SF12/125 kHz), the maximum application payload considered here is approximately 51 bytes.
• ACRIOS converters offer three fragmentation strategies for data that still do not fit within a single uplink: Truncate, Split, and Multiframe.
• For NB-IoT, a complete M-Bus frame usually fits within a single message, and ACRIOS can alternatively deliver already-parsed values as JSON over MQTT.
• There is no universal best strategy. The right choice depends on the required data, the network, and the parser on the receiving side.

‍

An M-Bus parser reads the data telegram a meter sends over the M-Bus protocol and extracts the individual values it contains. When that telegram has to travel over LoRaWAN or NB-IoT rather than remain on a wired M-Bus line, its size and the receiving platform's capabilities become important.

A large telegram does not automatically have to be split. It is possible to reduce it to the values the application actually needs. If it still does not fit into the available network payload, the appropriate fragmentation strategy depends on the network and on how the data will be handled on the receiving side.

M-Bus was built for interoperability, not for constrained radio. A single telegram from a heat meter can easily exceed 100 bytes because M-Bus telegrams can include multiple meter values and data records. That works well on a wired bus. It becomes a problem when the same data must travel over a network where the entire frame does not fit within a single uplink.

ACRIOS converters address this in several ways, all of which are selectable directly in the configuration Wizard. There is no universal best strategy. The right one depends on the target network and on the parser or platform on the receiving side. Choose the strategy to match those requirements, not the other way around.

Parsing, filtering, and fragmentation are three different steps

These terms are related, but they solve different problems.

• Parsing means interpreting an M-Bus telegram and turning its encoded records into meaningful values.
• Filtering means selecting which M-Bus records to keep and transmit.
• Fragmentation means dividing data into multiple messages when it does not fit within a single network payload.

‍

This distinction matters because a large M-Bus telegram does not automatically need to be fragmented. If the application only needs a subset of the available values, filtering can reduce the frame enough to fit into a single message.

Filter first: the best fragmentation is none at all

Before deciding how to split a frame, reduce it. VIF/DIF filtering occurs directly on the device, so only the selected values leave the device. Everything else is dropped before it reaches the radio.

For EU863-870 at DR0 (SF12/125 kHz), the target is a frame under approximately 51 bytes, which typically corresponds to about four values. The exact number of values depends on the selected records, so the frame size in bytes is the decisive measure.

If everything the application needs fits within that limit, no fragmentation is required, and downstream fragmentation considerations disappear.

So the first question is not: which fragmentation strategy should be used. It is: can the data be filtered enough to avoid fragmentation in the first place? When that is not possible, there are three fragmentation strategies to choose from.

Why LoRaWAN and NB-IoT are not the same problem

This distinction matters early because it shapes most of the decision that follows.

LoRaWAN

LoRaWAN payload depends on the spreading factor, data rate, and regional parameters. In the EU863-870 region, there is considerably more room at higher data rates; at DR0 (SF12/125 kHz), the maximum application payload considered here is approximately 51 bytes per uplink. Duty cycle also limits the available airtime. Once a filtered frame still exceeds the available payload, fragmentation is unavoidable, and every additional uplink adds airtime.

NB-IoT

NB-IoT does not work under the same constraints. Payloads are much larger, and there is no duty cycle in the LoRaWAN sense, so a full M-Bus frame usually fits within a single message. In practice, this means splitting is rarely needed on NB-IoT. It also opens up a delivery option that LoRaWAN does not offer, which is covered below.

The takeaway: a fragmentation strategy necessary on LoRaWAN may be unnecessary on NB-IoT. Always align the choice with the network.

Strategy 1: Truncate

Only the selected VIF/DIF values are sent, and the rest of the telegram beyond the payload limit is cut off.

• Advantages: the smallest possible uplinks, the lowest cost, and always a single message.
• Trade-offs: data past the cut are gone for good. This is irreversible, so the values that matter must fall within the limit with certainty. What arrives on the receiving side is a fragment, not a standard M-Bus telegram, so a generic parser will not treat it as a complete frame.
• Best fit: deployments that only need a handful of key values and prioritise minimum airtime and transmission cost. A reasonable default on NB-IoT devices where the required data points are already known in advance.

Strategy 2: Split

The full telegram is divided into numbered chunks (0103, 0203, 0303, and so on) and reassembled in the backend. The first two bytes mark the fragment, and a further byte identifies the meter by its index in the converter so that each frame can be assigned to the right meter.

• Advantages: nothing is dropped; the entire telegram is preserved. Overhead stays low because the M-Bus header is not repeated in every fragment.
• Trade-offs: the approach is fragile. If a single frame is lost, the message cannot be reconstructed or parsed at all. The whole reading is lost, not just one value. It is also a non-standard format, so the receiving side needs a parser that understands the ACRIOS chunking and padding scheme. A generic M-Bus parser will not do.
• Best fit: cases where the complete telegram is required, the link is reliable (confirmed uplinks can help here on LoRaWAN), and the parser on the platform side is under direct control.

Strategy 3: Multiframe

Each fragment is sent as a complete, independently valid M-Bus frame, with its own header (68 2D 2D 68 ... 16).

• Advantages: every packet is a valid M-Bus frame on its own so that a generic standard M-Bus parser can be used without custom reassembly logic. Because each frame stands alone, losing one costs only that frame's values, not the entire message.
• Trade-offs: Multiframe has the highest overhead of the three strategies. The M-Bus header is repeated in every frame, so more total bytes are sent across more uplinks, using more airtime and duty cycle.
• Best fit: cases that need the whole telegram and standard-parser compatibility. This is the default choice on LoRaWAN whenever a single filtered frame still does not fit. The additional airtime is the trade-off for compatibility with a standard M-Bus parser.

Split vs Multiframe: what happens if a packet is lost

This is one of the most important practical differences between the two strategies.

With Split, the numbered chunks together form one telegram. All required fragments have to arrive before the original message can be reconstructed. If one is missing, the reading cannot be parsed at all.

With Multiframe, each transmitted frame is independently valid. If one frame is lost, only the values in that frame are unavailable. The remaining frames can still be parsed normally.

The decision is therefore not only about the number of transmitted bytes. It is also about how the receiving platform should behave when a transmission goes missing.

NB-IoT only: MQTT with parsed JSON

On NB-IoT, there is a fourth option that changes the picture. Instead of shipping raw M-Bus frames and parsing them downstream, the device publishes the already parsed values as JSON over MQTT. There is no fragmentation to manage, and no M-Bus parser is needed on the receiving side. MQTT also provides two-way communication, allowing configuration to be adjusted via downlink. The MQTT configuration must be uploaded to the device.

For integrations already running an MQTT broker, this is usually the cleanest integration available.

Each branch above maps to one of the four rows below. The table adds two details the diagram leaves out: how much overhead each option adds, and what the receiving side needs to be able to parse it.

M-Bus fragmentation strategies compared

The practical logic follows directly from the platform: Filter first. If the frame fits under approximately 51 bytes at EU863-870 DR0 (SF12/125 kHz), typically around four values, none of the fragmentation strategies is needed.

On LoRaWAN, when the frame does not fit, Multiframe is the strongest general choice because it produces valid M-Bus frames that a generic parser can read without custom reassembly logic. Choose Split when airtime savings matter and custom reassembly is acceptable. Choose Truncate when only a few key values are required.

On NB-IoT, splitting is usually unnecessary. Send the full frame in a single message, or use MQTT with parsed JSON when a broker is already in place.

Two implementation details worth knowing

Only the first frame in a multi-telegram M-Bus response is supported. The selected strategy is also not fixed at the time of deployment. It is set in the configuration wizard and can later be changed remotely over downlink. If the requirements of a deployment change, the original strategy does not have to remain in place.

Do you need an M-Bus parser? Check out our Wiki pages under tools section for the downloadabale M-Bus parser .js.

Glossary of terms used

• M-Bus: a European standard (EN 13757) for remote reading of utility meters such as heat, water, and gas meters.
• Telegram/frame: the data packet a meter sends over M-Bus, containing protocol and value information.
• M-Bus parser: software that interprets an M-Bus telegram and extracts its encoded meter values.
• VIF/DIF: information in an M-Bus telegram used to identify and interpret the individual values it contains.
• Spreading factor (SF): a LoRaWAN parameter that affects data rate and range. Higher spreading factors, such as SF12, provide a lower data rate and allow for a smaller payload.
• Duty cycle: a regulatory restriction on how much airtime a radio device may use within a given period.
• Fragmentation: dividing data across multiple messages because they do not fit into a single network payload.
• Truncate: an ACRIOS strategy in which data beyond the available payload limit are cut off.
• Split: an ACRIOS strategy in which the telegram is divided into numbered chunks and reassembled on the receiving side.
• Multiframe: an ACRIOS strategy in which the data are divided across independently valid M-Bus frames.
• LoRaWAN: a low-power wide-area network protocol used for long-range IoT connectivity.
• NB-IoT: Narrowband IoT, a cellular low-power wide-area network standard.
• MQTT: a lightweight messaging protocol commonly used for IoT communication.

‍