Multi-utility remote reading via the SMGW: gas, water and heat at the LMN
This is an analysis of how non-electricity meters bind to the SMGW at the LMN interface, not of the gateway's wide-area side, the backend behind it, the heat-cost reading mandate or the gas market processes. It sets out the LMN interface, how a gas, water or heat meter binds over wireless M-Bus, the right tariff cases TAF 6 and 7, the section 6 MsbG bundling right, the boundary to submetering, and why cross-utility operators have an edge. The neighbouring topics sit close by and are linked, not repeated. Note: SMGW = smart meter gateway; LMN = local metering network, the gateway's inbound side; gMSB = grundzustaendiger Messstellenbetreiber, the grid-responsible metering point operator; wMSB = wettbewerblicher Messstellenbetreiber, the competitive metering point operator; MsbG = Metering Point Operation Act; Stadtwerke is the German term for municipal utilities that often run several utilities at once.
The SMGW faces outward as an electricity gateway, but inward it is a multi-utility receiver. On its local metering network side, the LMN, it offers two paths: a wired bidirectional path over RS-485 with HDLC, and a wireless unidirectional path over wireless M-Bus to EN 13757-4, with mode T mandatory at the gateway. The BSI TR-03109-1 v2.0 explicitly names metering devices for gas, water, thermal energy and electricity at the LMN. The decisive tariff application case for multi-utility is TAF 7, load-profile reading, which the specification covers literally for electrical and thermal energy and for gas and water volumes at a period of 15 or 60 minutes; TAF 6 handles the on-demand single read. TAF 9, 10 and 14 are not reading cases. Battery-powered gas, water and heat meters send one way and are encrypted with AES-128 under OMS Security Profile B, security mode 7, as a rule not by TLS; only bidirectional meters use LMN TLS. There is no separate BSI meter list, so the practical entry key is OMS certification of generation 4, awarded by DVGW CERT and VDE. Section 6 MsbG lets the connection owner choose a metering operator that bundles electricity plus at least one further utility, gas, water, district heat or space heat, over the SMGW at no extra cost. The section 30 price cap is electricity only; the other utilities run as additional services under sections 34 and 35 with no statutory euro cap. The submetering boundary, set by the Heating Costs Ordinance and the FFVAV with the building owner, is real and contested, and the SMGW is not mandatory for submetering. In 2025 and 2026 multi-utility is at pilot stage, not mass market, while the electricity rollout itself stands at around 3.09 million smart metering systems and 5.5 percent.
The LMN interface: the gateway's inbound side
The SMGW faces the outside world as an electricity gateway, but on the inside it is a multi-utility receiver. The local metering network, the LMN, is its inbound side, and it is the door through which gas, water and heat reach the gateway in the first place. Everything that makes multi-utility possible happens here, before the data ever leaves for the wide-area network and the backend. The article on the new SMGW generation and the WAN side of the gateway covers what happens after that point; this piece stays on the inbound side.
The gateway knows two LMN paths. The first is wired and bidirectional, running over RS-485 with HDLC framing. It is worth being precise here, because the wired M-Bus at the SMGW is HDLC over RS-485, not the classic two-wire M-Bus to EN 13757-2 that many people picture when they hear the term. The second path is wireless and unidirectional, using wireless M-Bus to EN 13757-4. For most non-electricity meters the wireless path is the realistic one, because it needs no cabling to each meter and suits battery-powered devices in basements and shafts.
What matters most is that the standard itself anticipates this. The BSI TR-03109-1 v2.0, dated 13 December 2024, explicitly names metering devices for gas, water, thermal energy and electricity at the LMN. Multi-utility is therefore not a workaround bolted onto an electricity device, it is a use the technical guideline foresees. Electricity meters are identified over EN 62056-6-1, while the non-electricity utilities are identified through the OBIS identifiers of EN 13757-1, so the gateway can tell a gas reading from a water reading from a heat reading on the same inbound side.
How a gas, water or heat meter binds to the SMGW
A non-electricity meter does not simply appear on the gateway. It has to be registered, encrypted and conformant before the SMGW will accept its data, and three building blocks decide whether the binding works. Getting these three right is the practical heart of any multi-utility project, far more than the choice of meter brand.
The first block is the radio. Most gas, water and heat meters are battery powered and send their values one way over wireless M-Bus, with mode T mandatory at the SMGW and mode C set as the target. Because the transmission is unidirectional, the meter never has to listen, which is what keeps its battery alive for years. The second block is the encryption, and this is where a common assumption goes wrong: the link is secured symmetrically with AES-128 under OMS Security Profile B, which is wireless M-Bus security mode 7, not by TLS. Only meters that are bound bidirectionally use TLS at the LMN; the battery-powered majority do not.
The third block is registration and conformity. The gateway administrator registers each meter through a meter profile and distributes the key material administratively, so that the gateway knows which device to expect and how to decrypt it. Conformity is the entry gate: there is no separate BSI conformity list for non-electricity meters, so the practical entry key is OMS certification, currently OMS generation 4, awarded by DVGW CERT and VDE. OMS is referenced normatively in the TR-03109, which makes an OMS-certified meter the realistic route onto the gateway rather than just a nice-to-have label. What happens to the keys and devices once the gateway hands the data onward is covered in the article on the backend and PKI behind the gateway.
TAF 6 and TAF 7: the right use cases for multi-utility
Not every tariff application case fits a reading, and the common mix-ups cost planning time. For multi-utility exactly two cases count, and naming them correctly up front saves a great deal of rework later. The full tariff framework on the gateway's outbound side is set out in the article on the new SMGW generation, the TAF framework and the WAN side; here the focus is only on which cases serve the reading of gas, water and heat.
TAF 6 is the on-demand read of meter values, the single read on request, for example when a tenant moves out and a closing read is needed. In v2.0 the function is carried over into an on-demand delivery function, but conceptually it remains the same: a value fetched when someone asks for it. TAF 7 is load-profile reading, the Zaehlerstandsgangmessung, and it is the decisive case for multi-utility. The TR-03109-1 v2.0 names here, literally, the recording of load profiles for electrical energy, thermal energy and for gas and water volumes, at a configured period of 15 or 60 minutes. That single sentence is what makes the gateway a genuine multi-utility reading platform rather than an electricity-only device.
It is worth stating plainly which cases do not apply, because the confusion is widespread. TAF 9 is the provision of the actual feed-in of a generation plant under the renewable and combined-heat statutes; TAF 10 is the provision of grid-state data to the network operator; TAF 14 is the high-frequency provision of values for value-added services such as portal visualisation. None of these is a reading case for gas, water or heat. Anyone planning a multi-utility rollout around TAF 9, 10 or 14 has started from the wrong premise.
On the meter side, the OMS compact profile maps TAF 7 for wireless M-Bus meters, so that battery-powered devices can send one-to-many to a single gateway. In practice this is what lets a single SMGW serve a whole property: vendor figures put it at up to 50 meters per property on one gateway with TAF 7, and at over 80 compatible meter types from around 20 manufacturers in one product line. The reading case and the radio profile fit together, which is the technical reason multi-utility is feasible at all.
Section 6 MsbG: the legal gateway to multi-utility bundling
Multi-utility is not only a matter of technology, it is a clearly regulated right of choice. Section 6 of the MsbG, the Metering Point Operation Act, turns the bundling of utilities over the SMGW into the case the law actually foresees, which is what separates it from a mere engineering possibility.
Section 6 gives the connection owner, in practice the property owner, the right to choose a metering operator that bundles electricity plus at least one further utility, gas, water, district heat or space heat, over the SMGW. The key condition is that this bundling must happen at no extra cost compared with the previously separate services. The law thus does more than permit multi-utility: in the property model it expects the bundle to be cost neutral, so the owner is not asked to pay a premium for the convenience of one operator and one channel.
The pricing of the non-electricity side follows a different logic from electricity. The price cap of section 30 MsbG applies to electricity only. Using the SMGW for gas, water or heat is billed separately as an additional service under sections 34 and 35 MsbG, and for that additional service there is no statutory euro cap, only the open standard of a reasonable charge. The two rules sit side by side: a hard cap on the electricity service, an open but bounded standard on the rest, and within the property model the overriding requirement that the bundle as a whole stays cost neutral.
The boundary to submetering and heat-cost service providers
Whoever wants to read heat and water meets an existing field with its own rules and established players. The boundary between the metering world of the MsbG and the submetering world of the building owner is real, and it is contested, so it deserves to be drawn carefully rather than glossed over.
Legally, the remote reading of heat and water sits in the Heating Costs Ordinance and the FFVAV, the ordinance on full remote-readability, with the building owner and the owner's service providers, not in the MsbG. The mandate and the deadlines on that side are the subject of the article on the Heating Costs Ordinance and the remote-reading mandate. The crucial point for multi-utility is that the SMGW is not mandatory for submetering: parallel non-SMGW systems remain allowed, and many buildings will keep them. The gateway is one valid route to remote-readable heat and water, not the only one.
What makes the boundary contested is that section 6 MsbG lets a metering operator enter this field and, in principle, replace existing submetering arrangements over the gateway. That is why the market shows cooperation and consolidation at the same time: there are pilot partnerships that put submetering data through the SMGW, and there are acquisitions, such as Techem and inexogy, that pull metering and submetering capability under one roof. For a utility weighing multi-utility, the honest reading is that entering the submetering space is possible through section 6, but it means stepping into a field with incumbents and a separate legal basis, not an empty stretch of road.
The municipal-utility advantage and the honest rollout status
Cross-utility municipal utilities, the Stadtwerke, can use the electricity infrastructure several times over, but the status today is pilot, not mass market. Realism beats marketing here, and a utility that mistakes one for the other will misjudge its own timetable.
The structural advantage is genuine. A utility that runs electricity, gas, water and heat uses the same communication channel several times over and spares itself a separate data hub for each utility. The mandated electricity gateway is already in the building, already certified and already connected to a backend, so binding a gas or water meter to it is cheaper at the margin than standing up an independent reading system per utility. For a single-utility actor this advantage simply does not exist, which is why multi-utility is so often described as the municipal-utility case. The gas side of this story, seen from the market-process angle rather than the LMN, is covered in the article on the gas market processes under WiM Gas 2.0.
The honest counterweight is the rollout status. There is no national multi-utility quota, only project figures: cooperations such as Minol with Netze BW and ZENNER, and submetering programmes such as KALO at around 1,000 buildings. The evidence today comes mainly from service providers and vendors, not as a binding statement from the municipal-utility association or the energy industry association. Meanwhile the electricity rollout itself stands at around 3.09 million smart metering systems and 5.5 percent of metering points, and many utilities still read gas, water and heat by hand. Multi-utility over the SMGW is the right direction of travel, and the technology and the law both support it, but in 2025 and 2026 it is a pilot to plan for, not a mass market to assume.
- Treat the LMN as the deciding interface. Plan multi-utility around wireless M-Bus, mode T and OMS Security Profile B, not around TLS as the rule.
- Build the reading on TAF 6 and TAF 7. Use TAF 7 load-profile reading for the recurring case and TAF 6 for on-demand reads, and avoid TAF 9, 10 and 14.
- Make OMS certification a procurement gate. Require OMS generation 4 for every non-electricity meter, since there is no separate BSI list.
- Use section 6 with a cost-neutral bundle. Offer electricity plus at least one further utility at no extra cost, and price the additional service against a reasonable charge.
Further reading
Frequently asked questions
Two cases apply, TAF 6 and TAF 7. TAF 6 is the on-demand read of meter values, the single read on request, for example at a tenancy change. TAF 7 is load-profile reading, the Zaehlerstandsgangmessung, and it is the decisive case for multi-utility, because the BSI TR-03109-1 v2.0 explicitly names load profiles for electrical energy, thermal energy and gas and water volumes at a configured period of 15 or 60 minutes. TAF 9, 10 and 14 are not reading cases: they cover feed-in, grid-state data and value-added services.
Battery-powered gas, water and heat meters send one way over wireless M-Bus and are encrypted symmetrically with AES-128 under OMS Security Profile B, which is wireless M-Bus security mode 7. As a rule this is not TLS. TLS at the LMN is used only by bidirectionally connected meters. The gateway administrator distributes the key material administratively through each meter's profile.
There is no separate BSI conformity list for non-electricity meters. The practical entry key for a gas, water or heat meter at the SMGW LMN is OMS certification, currently OMS generation 4, awarded by DVGW CERT and VDE. OMS is referenced normatively in the BSI TR-03109, so an OMS-certified meter is the realistic route onto the gateway.
The section 30 MsbG price cap applies to electricity only. Using the SMGW for gas, water or heat is billed separately as an additional service under sections 34 and 35 MsbG, for which there is no statutory euro cap, only the open standard of a reasonable charge. In the property model under section 6 MsbG, however, the bundle of electricity plus at least one further utility must be cost neutral against the previously separate services.
No. The remote reading of heat and water sits legally in the Heating Costs Ordinance and the FFVAV with the building owner and the owner's service providers, not in the MsbG. The SMGW is not mandatory for submetering, and parallel non-SMGW systems remain allowed. Through section 6 MsbG a metering operator can nevertheless enter this field and replace existing submetering arrangements.