MIOTY: The Automation Industry Arrives at the LPWAN Table
I’ve spent a fair amount of ink on this site comparing LoRaWAN, LoRa mesh, and Wi-Fi HaLow: LPWAN and radio protocols shaped mostly by hobbyists, network operators, and the odd telco. There’s a fourth contender I’ve been putting off writing about, largely because it comes from a different world entirely. MIOTY didn’t grow out of a maker community or an open-source project. It grew out of Fraunhofer IIS research labs and the boardrooms of German industrial automation, and it arrived at the LPWAN table years after LoRaWAN had already set out the cutlery.
That lateness is worth sitting with for a moment, because it tells you something about who MIOTY is for. The automation sector, companies like ifm, Siemens-adjacent suppliers, Diehl, WIKA, spent the better part of a decade treating wireless sensor networking as somebody else’s problem, content with fieldbus and hardwired I/O. When they finally showed up, they didn’t come empty-handed. They brought a genuinely interesting piece of physics, a serious industry alliance, and, predictably, the pricing structure the automation industry always brings to a party. I want to give MIOTY a proper, technical look here rather than dismiss it as marketing dressed up in Fraunhofer’s credibility. It deserves better than that, even if it’s not going to change how I build networks on rural Australian properties.

Where MIOTY Actually Comes From
The physics underpinning MIOTY isn’t new. Fraunhofer IIS started researching how to split wireless transmissions into short, distributed sub-packets back in 2009, aimed squarely at making low-power networks more robust against interference. That research matured into a formal specification, and in June 2018 ETSI published TS 103 357, the first complete standard for what’s called TS-UNB (Telegram Splitting Ultra Narrowband). A major revision, TS 103 357-2, followed in June 2024, refining the Low Throughput Network protocol underneath MIOTY.
The commercial push came later. In February 2020, at embedded world, a group of research and industry heavyweights launched the MIOTY Alliance: Texas Instruments, Fraunhofer IIS, Diehl Metering, Diehl Connectivity Solutions, ifm electronic, Ragsol, STACKFORCE, and WIKA among the founders. By mid-2022 the Alliance counted 10 full members and 25 associate members, including Swissphone, Sentinum, Loriot, and Weptech. Fraunhofer-Gesellschaft owns the MIOTY trademark, and the underlying patents (held by Fraunhofer-Gesellschaft and Diehl Metering) are licensed through Sisvel International, the same patent-pool operator behind licensing programs for Wi-Fi, cellular IoT, and video codecs. This matters, and I’ll come back to it, because it’s the single biggest practical difference between adopting MIOTY and adopting LoRaWAN.
ifm electronic, one of the founding Alliance members, is also the author of the technical study I want to walk through in detail: a controlled comparison of LoRaWAN and MIOTY, run on ifm’s own R&D campus in Tettnang, Germany, and published in June 2023 by Ons Zerai, Martin Striegel, and Thomas Krone. Read the results with this in mind, upfront: this is not an independent third party’s benchmark. It’s one of MIOTY’s own backers testing its own product. That doesn’t make the methodology bad, and I think it genuinely isn’t, but it’s the kind of thing you flag rather than bury.
Telegram Splitting: The Actual Technical Idea
Here’s the core mechanism, and it’s a genuinely different approach to the interference problem than LoRa’s chirp spread spectrum.
A standard LoRa transmission sends one continuous packet on one channel. It’s a long transmission (particularly at high spreading factors), and if something clobbers it mid-flight, be it another device transmitting on an overlapping channel, a burst of RF noise from nearby machinery, or simple fading, you lose the whole packet.
MIOTY does something closer to what you’d design if you were paranoid about exactly that scenario. It takes a message (a “telegram”) and chops it into many small sub-packets, each transmitted on a narrow 2 kHz channel, each burst lasting around 15 milliseconds, with the sub-packets scattered across different frequencies and different points in time rather than sent back to back. Forward error correction is applied across the set, and the specification’s design tolerance allows message reconstruction even if roughly half the sub-packets never arrive at all. The receiver doesn’t need every piece. It needs enough of the puzzle.
The practical consequence: a single burst of interference, a nearby VFD (variable-frequency drive) kicking in, a forklift’s radio, another sensor network sharing the band, can only ever wipe out the sub-packets that happen to land in that narrow window. The rest of the telegram, scattered elsewhere in time and frequency, sails through unaffected. This is the whole thesis of MIOTY: trade a more complex transmission scheme for resilience against exactly the kind of dense, metal-walled, RF-noisy environment a factory floor actually is. It’s a legitimate piece of engineering, not a rebadge of existing LPWAN ideas.
The ifm/Fraunhofer Study, In Detail
The experimental setup is genuinely well controlled, which is what makes the paper worth reading closely rather than skimming for the headline numbers.
Identical hardware, both protocols. Rather than compare a MIOTY vendor’s device against a LoRaWAN vendor’s device (which would tell you as much about engineering quality as about the protocol), the team used a single custom board: an STM32L4 host talking to a muRata CMWX1ZZABZ-093 module built around Semtech’s SX1276 transceiver, the same silicon that supports both LoRa modulation and the FSK modulation MIOTY uses. Same antenna, same RF front end, same firmware platform, switched between protocols via AT commands. On the receiving end, a single rod antenna on a hybrid VIORYTI base station fed both the LoRaWAN and MIOTY receive chains through a passive splitter, so both protocols absorbed the same 3 dB attenuation penalty. That’s about as fair a physical-layer comparison as you’re going to get.
Five real scenarios, not a lab bench. They deployed devices at five points around ifm’s Tettnang campus: line-of-sight at 5 metres (a sanity check), a basement 72 m away and three floors down with dense Wi-Fi infrastructure and concrete ceilings in between, an office 85 m away with Wi-Fi and other LoRaWAN/MIOTY testbeds contributing interference, an outdoor entrance 107 m away, and a ground-floor production site 99 m away. LoRaWAN ran at Spreading Factor 12, the maximum-range, maximum-airtime configuration, at full 14 dBm transmit power. Retransmissions were disabled on the LoRaWAN side specifically so both protocols were doing the same “fire and forget” thing MIOTY does natively; I’ll return to why that choice matters for interpreting the results.
Here’s what they measured, packet reception rate at the base station:
| Scenario | Distance (horiz/vert) | Packets sent | LoRaWAN PRR | MIOTY PRR |
|---|---|---|---|---|
| ① Line of sight | 5 m / 1 m | 13 | 100% | 100% |
| ② Basement, 3 floors, dense Wi-Fi | 72 m / 24 m | 696 | 0% | 14.3% |
| ③ Office, Wi-Fi + testbed interference | 85 m / 12 m | 3,508 | 58.9% | 75.3% |
| ④ Outdoor entrance | 107 m / 18 m | 601 | 69.7% | 72.0% |
| ⑤ Production floor, ground level | 99 m / 18 m | 265 | 61.9% | 86.8% |
Scenario ② is the number that jumps out. LoRaWAN, at maximum spreading factor and maximum power, got precisely nothing through three floors of concrete and a saturated Wi-Fi environment. MIOTY, on the same antenna, same RF chain, got 14.3% of packets through. That’s not a subtle edge, it’s the difference between a working sensor and a dead one. In the other obstructed scenarios (office, production floor) MIOTY held a 16 to 25 percentage point lead over LoRaWAN. The one scenario where they’re essentially tied is the outdoor entrance, the case with the least structural obstruction and interference, which fits the theory: telegram splitting’s advantage is specifically an interference-robustness advantage, not a raw-range advantage. Where the air is clean, the two are close. Where the air is dirty, MIOTY’s diversity scheme earns its keep.
Energy. The team also measured active and sleep-mode power draw at the office location, using an Otii Arc power meter, and estimated battery life against a 1600 mAh CR123A cell. MIOTY came out to an estimated 10.2 months of battery life against LoRaWAN’s SF12 giving 6.7 months, SF7 giving 9.9 months. The genuinely interesting finding here isn’t just that MIOTY wins, it’s why LoRaWAN loses even at its most efficient setting: the device couldn’t reach its deepest sleep mode between transmissions when running LoRaWAN, because Over The Air Activation (OTAA) requires session keys and related state to be retained in RAM across the sleep cycle. MIOTY, with no equivalent activation handshake to preserve, could sleep deeper. That’s a meaningful real difference, but it’s also partly an implementation detail of OTAA rather than an immutable law of the LoRa PHY. A LoRaWAN stack that persisted its session state to non-volatile memory, rather than holding it in RAM, would likely close at least part of that gap, though the paper doesn’t test that configuration.
Reading the Results Fairly
I want to be straight about what this study does and doesn’t tell you, because the automation industry’s marketing arm is not going to volunteer the caveats.
First, disabling LoRaWAN retransmissions was the right call for isolating the physical-layer question the researchers were asking, but it does mean the headline PRR figures aren’t a like-for-like prediction of production network performance. Real LoRaWAN deployments in marginal coverage routinely use confirmed uplinks with retries to compensate for packet loss. In the office, entrance, and production-floor scenarios, where LoRaWAN was landing 59 to 70% of single-shot packets, three attempts per reading would push delivery above 90% (assuming losses are independent, which is optimistic), at the cost of extra airtime and battery. Scenario ② is different: retries can’t rescue a link that delivered nothing out of 696 attempts, and the realistic LoRaWAN fix there is a second gateway closer to the basement, not more retransmissions. The paper is honest about disabling retransmission as a deliberate methodological choice, and says the effect of retransmission is left for future experiments; the reader still needs to remember it when the headline numbers get quoted out of context, which they inevitably will be.
Second, this is a vendor-backed study. ifm is a MIOTY Alliance founding member testing its own bet. I don’t think that invalidates the physics, telegram splitting’s interference resilience is a real, well-understood property of the scheme, not something ifm invented for the paper, but it’s a reason to treat this specific dataset as a demonstration rather than the final word, and to look for independent replication before leaning too hard on the exact percentages.
That replication has started to arrive, and it complicates the picture. A 2026 preprint from Dortmund University of Applied Sciences and Arts (Röhrig and Cramer), with no Alliance affiliation, pitted off-the-shelf MIOTY and LoRaWAN gear against university basements while trying to reach energy meters. There, LoRaWAN reached every basement test point while MIOTY missed two entirely, and over a month in the same basement server room LoRaWAN at SF12 lost 3.1% of packets against MIOTY’s 10.7%. The authors trace most of that to their MIOTY gateway’s weaker receiver sensitivity (−125 dBm against LoRaWAN’s −138 dBm), not to telegram splitting itself, and the hardware wasn’t matched the way ifm’s was. But their conclusion is worth quoting: MIOTY is more reliable “if the RSSI values are high enough”. Interference resilience and link budget are different things, and a quiet concrete basement tests the second one.
Third, and this is the honest limitation nobody in the Alliance leads with: MIOTY is fundamentally an uplink technology. It’s built for sensors talking to a base station, not for a base station reliably talking back. In most deployed kit, downlink works like LoRaWAN’s Class A: the device opens a short receive window tied to its own last transmission, with real constraints on latency and how often you can practically push a command down to a device. The June 2024 revision of the standard (TS 103 357-2 V2.1.1) does now define Class B (scheduled downlink) and Class C (event-triggered downlink) end-points, but a specification isn’t a product ecosystem, and anyone relying on them should confirm support in the specific modules and base stations before committing. If your use case needs frequent downlink control commands, actuators, remote configuration changes, or real-time setpoint adjustment, MIOTY still isn’t the natural fit. Physical-layer payloads top out at 255 bytes, and the net data rate sits around 500 bits per second, which is telemetry-and-measurement territory, not general-purpose data.
The Cost of Admission
LoRaWAN is not, strictly speaking, free of patent entanglement either, Semtech holds the core IP behind the LoRa chirp spread spectrum PHY, but the ecosystem around it has grown so large and the chip pricing so competitive that this rarely comes up as friction in practice. MIOTY is a different proposition. As a patented technology, it carries royalty fees, licensed through Sisvel’s platform, and that’s a line item vendors have to account for that LoRaWAN vendors mostly don’t think about anymore. Chipset support has broadened well past the original muRata/Semtech combination the ifm study used, Texas Instruments, STMicroelectronics (the STM32WL series), and Silicon Labs offer MIOTY-capable silicon, and Radiocrafts sells certified modules, so it’s not a single-vendor lock-in situation. But you’re still paying into a licensing structure LoRaWAN largely lets you skip, and by 2026 LoRaWAN remains the dominant non-cellular LPWAN technology by a wide margin, which means MIOTY is asking potential adopters to pay a premium to join a much smaller ecosystem.
It’s worth putting actual numbers on that premium rather than leaving it as a vague impression. Checking retail and distributor pricing at the time of writing (September 2026, in US dollars):
| Component | LoRaWAN | MIOTY |
|---|---|---|
| End-node module, single unit | $5.99-6.99 (RAK3172, STM32WLE5-based) | $27.05 (Radiocrafts RC1882CEF-MIOTY1) |
| End-node module, 1,000+ units | Volume discounts apply, not separately quoted here | $18.46 (Radiocrafts, tape & reel) |
| Indoor gateway | ~$139-165 (RAK WisGate Soho Lite, 8-channel) | No publicly priced standalone indoor unit found; hybrid gateways only |
| Outdoor gateway | $337-525 (RAK WisGate Edge Prime/Pro) | $669-859 (RAK WisGate Connect for mioty, hybrid MIOTY+LoRaWAN, depending on RAM/eMMC/LTE config) |
| Industrial base station (the class used in the ifm study) | Comparable AST-X/VIORYTI-tier units are quote-only | AST-X VIORYTI GATE, quote-only, no public pricing |
| Protocol royalty | None; the LoRa PHY licence cost is bundled into the chip price, no separate per-unit fee | Sisvel per-device royalty on top of hardware, rate not publicly disclosed, running-royalty or discounted committed-volume options offered |
Two things stand out. First, at the low end a MIOTY-certified module runs 3-4 times the price of a comparable LoRaWAN module, and that gap holds up even at the 1,000-unit price break: $18.46 against LoRaWAN’s single-unit price of roughly $6 is still triple, and LoRaWAN modules get volume discounts too. Second, every MIOTY gateway I could find with public pricing is a hybrid device that also carries LoRaWAN and usually LTE, which is convenient if you want both protocols on one box but means you can’t buy your way into a MIOTY deployment at the sub-$150 entry point LoRaWAN offers. Add the Sisvel royalty on top of all of that, undisclosed but real, and the fact that neither Sisvel nor the module vendors publish the actual per-device rate is itself informative. LoRaWAN’s total cost of ownership is transparent from a distributor’s product page. MIOTY’s isn’t, until you’re far enough into a sales conversation to get a quote, which is precisely the automation-industry pricing instinct I flagged at the start of this piece.
There is at least one documented deployment outside the lab: in a pilot with Swissphone, Swiss energy company Axpo used MIOTY to automate monitoring of pole disconnectors on its power grid, reporting robust performance even under vibration during test drives at 120 km/h. That’s a genuine industrial use case, grid infrastructure monitoring, where interference resilience and long unattended battery life matter more than raw throughput or fast downlink, exactly MIOTY’s stated strengths, and presumably a case where the customer decided the premium was worth paying.
Where MIOTY Sits in the Landscape
I’ve mapped the wider sub-GHz field before, most directly in my Wi-Fi HaLow vs. LoRa piece comparing LoRaWAN, Meshtastic, Reticulum, and Wi-Fi HaLow. Folding the LoRa mesh options into one column, MIOTY slots in as a fourth philosophy rather than a straight LoRaWAN replacement:
| Feature | LoRaWAN | LoRa Mesh (Reticulum/MeshCore) | Wi-Fi HaLow | MIOTY |
|---|---|---|---|---|
| Primary use case | Massive, enterprise-grade IoT | Resilient, off-grid, multi-bearer networking | High-throughput IoT | Interference-robust industrial telemetry |
| Topology | Star-of-stars | Mesh, transport-agnostic | Star | Star (base station) |
| PHY approach | Chirp spread spectrum | Chirp spread spectrum | OFDM (sub-GHz Wi-Fi) | Telegram-splitting UNB (frequency/time diversity) |
| Downlink | Class A/B/C, workable | Bidirectional, mesh-routed | Native, bidirectional | Limited (Class A in most kit; Class B/C specified in 2024) |
| Data rate | Very low (0.3-50 kbps) | Very low, reliability-optimised | High (150 kbps-78 Mbps) | Very low (~500 bps) |
| Interference resilience | Moderate | Moderate | Moderate | High, by design |
| Licensing | Royalty-free ecosystem (PHY patented by Semtech, rarely a friction point) | Royalty-free, open source | Wi-Fi Alliance certification fees; 802.11 patents licensed on FRAND terms | Patented, licensed via Sisvel |
| Governance | LoRa Alliance | Open-source maintainers | Wi-Fi Alliance | MIOTY Alliance / ETSI |
| Best for | Vast, low-touch sensor deployments over years | Off-grid resilience, sovereignty, community networks | Cameras, high-bandwidth industrial edge | Dense, RF-hostile industrial and utility sites |
My Honest Take
I said at the outset I wasn’t going to dismiss this as automation-industry propaganda, and having gone through the physics and the study in detail, I don’t think it is. Telegram splitting is a real, sensible answer to a real problem: dense industrial and urban RF environments genuinely do chew up single-shot LoRa transmissions in a way that time-and-frequency diverse sub-packets can shrug off. The Scenario ② result, 0% versus 14.3% through three concrete floors, isn’t a rounding error you can wave away.
But I’d be lying if I said this changes anything about how I build networks. My work sits in long-range, rural, and regional connectivity, back paddocks, bushfire corridors, properties where the problem is distance and terrain, not a factory floor packed with VFDs and overlapping Wi-Fi cells. MIOTY’s whole reason for existing is dense, obstructed, RF-hostile environments, mostly not the environments I spend my time in. And the automation industry hasn’t shed its instincts just because it finally noticed LPWAN existed: the Sisvel licensing fees, the narrower chipset ecosystem, the downlink classes that exist on paper well ahead of the hardware, all of it reads like an industry more comfortable selling you a service contract than handing you a royalty-free standard.
There is one corner of my own work where this stops being theoretical, though. I’ve been collaborating with a local wine and beer producer, and their tank farms are close to a textbook case for what telegram splitting is built to survive. Rows of stainless steel fermentation and conditioning tanks, VFDs running pumps, glycol chillers, and refrigeration compressors more or less continuously, the whole lot packed into a steel shed that behaves like a Faraday cage with the odd hole punched in it. That’s a genuinely different problem from a back paddock: it’s dense, all-metal, and electrically noisy in exactly the way Scenario ② was, and a single-shot LoRa transmission trying to carry a tank-level or fermentation-temperature reading out through that racket is fighting the same kind of interference the ifm basement scenario modelled. It’s also, frankly, an environment already dominated by overpriced equipment, six-figure stainless steel and proprietary PLC service contracts, so a Sisvel royalty buried in a sensor module wouldn’t even register as unusual. It’s the one context in my own work where I’d genuinely put MIOTY on the shortlist rather than reach for LoRaWAN out of habit.
That’s not a knock on the engineering, which is sound, well-documented, and backed by a serious research pedigree at Fraunhofer. It’s a statement about fit. If you’re deploying thousands of sensors across a steel-and-concrete plant where LoRaWAN’s packet reception falls off a cliff the moment you go indoors, MIOTY is worth a serious look, and the ifm study, caveats and all, gives you real numbers to start that conversation with. If you’re doing what I do, running links across kilometres of open country where the problem is a hill, not a forklift, LoRaWAN, Reticulum, and Wi-Fi HaLow remain the tools actually built for that job.
Source: Zerai, O., Striegel, M., and Krone, T., “LoRaWAN and MIOTY: A Study on Packet Reception and Energy Consumption in the Industrial Internet of Things”, ifm electronic GmbH, June 2023, technical paper (PDF) via ifm.
Independent comparison: Röhrig, C., and Cramer, B., “Experimental Evaluation of LPWAN Technologies: mioty, LoRaWAN, Sigfox, NB-IoT, and LTE-M in Deep Indoor Environments”, preprint, IEEE VTC2026-Spring, May 2026, arXiv:2605.23483.
Comments
Be the first to comment! Reply to this post from your Mastodon/Fediverse or Bluesky account, or mention this post's URL in your reply. Your comment will appear here automatically via webmention.
Follow this blog on Mastodon at @gaggl.com@web.brid.gy or on Bluesky at @gaggl.com