Explore
Welcome to the mioty Developer Page!
In this section you will find a comprehensive overview of the new connectivity standard mioty.
What is mioty?
mioty is a software based low-power, wide-area network (LPWAN) protocol that was developed to overcome todays and future wireless connectivity limitations. With its best-in-class reliability and scalability, mioty is designed for massive IoT deployments and challenging radio conditions.

With mioty, messages get split into sub-packets, which are then transmitted over different frequencies and time. An algorithm in the base station permanently scans the spectrum for mioty sub-packets and reassembles them into a complete message. Due to sophisticated Forward Error Correction (FEC), the receiver only needs 50% of the radio bursts in order to completely reconstruct the information. This reduces the impact of corrupted or lost bursts due to collisions and increases the resistance to interference.
mioty software
Remaining exclusively a software solution, mioty deliverables consist of two key components: the mioty sensor node software and the mioty base station software, and does not rely on any proprietary hardware. With a vendor-neutral configuration, today mioty software supports a wide range of commercially available, off-the-shelf-hardware, granting end users with maximum flexibility and minimum complexity in designing their cost-effective IoT architecture.
- The mioty sensor node software stack is a general-purpose software library enabling easy integration in end customer products for immediate setup of low-cost, high performance »smart devices« at the edge. The library is optimized for power efficiency and runs on low-computing microcontrollers. Several stack vendors are available for different
- The mioty base station software is able to run on many industry-standard IoT gateways (e.g. Intel Core i3) connected with a Software De-fined Radio frontend (e.g. SDRplay RSP2 pro). It transforms the gateway into a Big Data Aggregator collecting data packets from trans-mitters staying within up to 15 km radius. The software also provides seamless integration with third-party cloud platform for data computing and analytics.
mioty payload calculator
As an LPWAN technology, mioty® is restricted in maximum payload size and regional radio regulations such as duty cycle limitations. Depending on the region, these regulations may limit a device to a maximum percentage of channel airtime per hour, which directly impacts the maximum number of telegrams that can be transmitted.
In mioty®, the airtime is the accumulated duration of all transmitted bursts only. The total transmission time additionally includes the silent gaps between the bursts and therefore represents the complete time span from the start of the first burst until the end of the last burst. While airtime is typically relevant for regulatory duty cycle calculations and energy consumption, the total transmission time determines how long it takes until a complete telegram is received over the air.
This calculator also includes optional mioty® transmission modes and features. The Low Latency (LL) mode reduces the spacing between bursts, shortening the overall transmission time and enabling faster message delivery. Since the total burst airtime itself remains unchanged, the maximum number of allowed telegrams per hour is not affected.
The calculator also supports ULP8 mode according to ETSI, also referred to as High Data Rate (HDR) mode. In this mode, mioty® telegrams are transmitted eight times faster, reducing airtime and transmission duration, but with reduced communication range as a tradeoff.
| Mode | Dir | Payload | Region | RX Sensitivity | Airtime | Total Tx | Max msg/h | |
|---|---|---|---|---|---|---|---|---|
| No calculations yet — press Calculate to add a row. | ||||||||
This calculator is provided for evaluation purpose only, without any warranty for correctness. Approximations based on ETSI TS 103 357‑2 V2.1.1 (2024‑06). Actual total transmission times might differ slightly.
mioty architecture
The mioty architecture portrays a star network where one or multiple base station aggregate low data-rate messages from thousands of battery-powered sensors operating at the edge. Enabled through the MIOTY™ RF Wireless Link characterized by the Telegram Splitting approach, communication between the base station and end nodes can be achieved over up to 15 km range (in flat terrain) utilizing worldwide license-free sub GHz bands (133-966 MHz).
One or multiple base stations are connected to a mioty backend, consisting of the Service Center and Application Center as functional blocks. The Service Center exists exactly once per network and handles the base stations over the BSSCI interface. The Application Center is the user-facing part of a mioty backend and is used to manage end points, do payload decoding using blueprints (optional) and can exist multiple times, separated by application or vertical, for instance.

Figure: A typical mioty network architecture
Key components and their functions are further explained as follows:
End Points
Devices, which send mioty modulated wireless messages to the base stations or receive messages wirelessly back from the gateways.
Mioty end points (EP) can capture critical field data such as environmental parameters or machinery KPIs and transmit them to a base station using the mioty RF link. They are usually equipped with sensors, actuators and communication components such as radio frequency (RF)-chips, transceivers and system-on-chip (SoC)-solutions, or RF-modules. In addition end-points also have a power source such as a battery/mains energy or a energy harvesting transducer.
Base Stations
The base station is the network device receiving messages from the devices via mioty air interface and forward them to the mioty service center.
A mioty base station (BS) collects messages from all sensor nodes that have been attached to it, processes and decrypts network control data and forwards user data to backend through backhaul connection with higher throughput (e.g. Ethernet, Wi-Fi…). In bi-directional communica-tion, it generates downlink messages based on payload received from the backend. These messages are then transmitted to the respective sensor nodes for remote command and control applications. A mioty network can incorporate more than one base station, in which case, the same message can be received by multiple base stations and shall be deduplicated by the service center.
Base Station – Service Center Interface
The Base Station – Service Center Interface (BSSCI) Specification describes the interface between the Base Station and the Service Center. The interface is based on a persistent TLS secured TCP connection between Base Station and Service Center. Messages exchanged over TLS connection are encoded with JSON/MessagePack. The interface allows to integrate other functionality via sub-channels.
Service & Application Center
The service center is managing a mioty network consisting of base stations. It is responsible for routing the data between end-point applications and the application center.
The service center is responsible for device and network management together with key management of the network-level cryptography. When two or more base stations receive and forward the same message, it additionally carries out deduplication task by eliminating repeated data. In bi-directional communication, the service center further tracks downlink transmission slots and duty cycles, as well as decides which base station is allowed to answer which specific sensor nodes. All devices (sensor nodes and gateways) operating in the same mioty network are registered at the service center for administration and operational control.
The application center interfaces applications to the mioty network via various available interface protocols (such as MQTT, Rest, COAP).
The application center serves as a point of contact with end users or application operators. Node credentials can be entered once here and accordingly transferred to the service center for registration of sensor nodes in the mioty network. When receiving messages from the service center, the application center decrypts and decodes user data by extracting application-specific information (e.g. temperature, pres-sure levels…) from the generic binary packets. Interpretable user data are then forwarded to the application platform. It might connect, configure and manage thousands of end-points.
IoT Platform
The IoT platform typically consists of a database and tools for visualization and analyzing the application data. It can be deployed on public cloud architectures or even be operated on-premise.
The IoT Platform stand for any server or cloud computing systems whose core functions are data storage and analytics. Patterns can be identified and visualized on user interfaces for predictions and execution of timely responses.
Communication layers in the mioty network
The full communication chain of a mioty network entails five main layers which are physical layer, MAC (Medium Access Control) layer, LLC (Logical Link Control) layer, network layer and application layer. These layers are handled by different components along the data chain. In particular, the physical, MAC and LLC layers represent the core of MIOTY™ software to be programmed on sensor nodes and gateways. Network and application layers, on the other hand, are specific to user appli-cations and thus defined by the customers.
Physical Layer
Based on Telegram Splitting technology – a unique transmission modulation developed and patented by Fraunhofer IIS, the physical layer characterizes the MIOTY™ RF Wireless Link and provides data connection between sensor nodes and the central base station. Besides enabling two core qualities of traditional LPWANs – high power efficiency and long transmission range, Telegram Splitting delivers other advanced technical features in the MIOTY™ system in terms of robustness, scalability and mobility
MAC Layer
Connecting the physical with higher layers in the communication stack, the MAC layer provides channel access so that sensor nodes and the central base station can communicate with each other through the MIOTY™ RF. Key func-tions of the MAC layer include address resolution, validation of message in-tegrity and authenticity, decryption of network-level security, and timing con-trol of downlink messages.
LLC layer
Residing above the MAC layer, the LLC layer handles network management information (control data) such as attachment and detachment command, link adaptation command or downlink query by the base station for reception parameters. While physical and MAC layers are operated exclusively at the base station, the LLC layer is partially administered by the service center.
Network and application layers
These two layers are mostly defined by the users. The network layer basically undertakes the task of transporting user data to the application center, where the information is decoded and processed. The application layer is responsible for data presentation and other application-specific services.
Security
mioty provides two built-in security layers consisting of network-level and application-level encryption. The network-level encryption ensures that only authenticated devices and gateways can communicate with each other and messages cannot be accessed and interpreted by unauthorized entities during transmission. The application-level encryption enables end-to-end protection of user data, whereby encrypted sensor data can only be de-crypted at the application center.
Device classes
The mioty specification defines three device types: Class Z, Class A, Class B, and Class C.
All mioty devices must implement Class A, whereas Class B and Class C are extensions to the specification of Class A devices. All device classes support bi-directional communication (uplink and downlink)
Class Z
Class Z devices are unidirectional devices and transmit the data via the mioty protocol to the base station. These battery-powered devices have extremely low energy consumption, long ranges, high scalability and high resistance against interference.
Class A
Class A devices can transmit information unidirectionally via uplink to a base station and can also be configured via downlink (bidirectionality). Class A devices work with the existing advantages from Class Z.
Class B
Class B Devices open scheduled receive windows for receiving downlink messages. They enable use cases such as controlling actuators, switches and machines via broadcast (control of all actuators via downlink) or via multicast (control of a group of actuators via downlink), as well as messaging. In general, a downlink message can be recieved by a class B device in less than a minute.
Class C
These devices extend Class B by keeping the receive windows open unless they are transmitting, This allows for low-latency communication but is more energy consuming than Class B devices. In general, a downlink message can be recieved by a class C device in less than a second.

