A mioty smart city network is one radio network, owned or contracted by the city, that carries readings from thousands of battery-powered sensors across the whole urban area: parking bays, waste containers, air quality stations, water meters, river gauges. A few dozen base stations on rooftops and poles receive those readings and pass them to software where each department sees its own part. mioty is a long-range, low-power radio standard built for very high device counts, which is exactly the problem a city has once it gets past its first pilot.

Most cities start smart city projects one department at a time. Parking buys parking sensors with their own network and app, waste management buys fill-level sensors with another, and the environment office runs a third system for air quality. Five years later there are three networks, three contracts and three logins, and nobody can put a flooded underpass next to the rainfall readings that predicted it. One shared network avoids that split.

In short

  • mioty is an ETSI-standardized long-range radio that splits each message into short bursts, which lets very many sensors share the same band.
  • One city-wide mioty network can carry parking, waste, environmental and metering sensors at once, because each sends only small, occasional messages.
  • In a city, base station count is usually set by coverage (streets, basements, underground car parks) long before it's set by capacity.
  • The software side matters as much as the radio: departments need their own views, rules and alarm recipients on shared infrastructure.

What can a mioty smart city network monitor?

Anything that produces a small reading now and then and runs on a battery fits the profile. Typical candidates in a city are:

  • parking bay occupancy, from sensors embedded in or glued to the road surface
  • fill levels in waste containers, glass banks and public bins
  • air quality, noise and temperature at street level
  • water, heat and gas meters in municipal buildings and housing
  • water levels in rivers, storm drains and underpasses
  • the open or closed state of gates, hatches and pump-room doors

What these have in common is the message pattern. A parking sensor reports when a car arrives or leaves, maybe 20 to 40 times a day. A waste fill-level sensor might report every hour. A meter reports hourly or daily. Each message is a few bytes. None of them needs a fast connection, and all of them need to run for years without anyone climbing a ladder.

The value comes from what departments do with those readings. Waste collection is the classic example. A city that empties 1,200 containers on a fixed weekly route visits every container whether it's full or nearly empty. With fill-level readings, the route can include only containers above, say, 70% plus those that will cross that line before the next round. Parking readings feed guidance signs and apps that show free bays by street. River and drain gauges give an early warning before an underpass floods. Air quality and noise readings show which streets exceed local limits and when, which matters for traffic planning and for answering residents' complaints with data.

What doesn't fit is anything with a high data rate. Video, live audio and streetlight dimming with instant response belong on other networks, such as fiber, Wi-Fi or a mobile connection.

The reason mioty suits this profile is a technique called telegram splitting. A mioty device cuts each message into many very short sub-packets and sends them at different times on different frequencies. The base station rebuilds the message even if up to half of those sub-packets are lost to interference, which is useful in a city where the license-free 868 MHz band is shared with alarm systems, remote controls, meters and other networks. The standard behind it is ETSI TS 103 357, developed from work at Fraunhofer IIS.

How many base stations does a mioty smart city need?

Start with capacity, because it's quick to rule out. The figures published by Fraunhofer IIS and the mioty Alliance are up to 110,000 endpoints per base station and up to 3.5 million messages a day per base station, for small payloads sent about hourly. Those are protocol figures; real networks land lower.

For a mid-sized city, with example device counts and intervals, the load looks like this:

Sensor type Devices Messages per device per day Messages per day
Parking bays 2,500 30 75,000
Waste containers 1,200 12 14,400
Air quality and noise 150 144 21,600
Municipal meters 400 24 9,600
Water level gauges 60 96 5,760
Total 4,310 126,360

That total is under 4% of what a single base station is rated for, so the base station count comes down to coverage.

The protocol range figure is roughly 2.5 km per base station, but cities are full of things that shorten it: concrete, steel, parked cars over in-ground parking sensors, metal lids on waste containers, and meters in basements. If you plan with an effective radius of 1 km in the dense center, each base station covers about 3 km². A 30 km² core then needs around 10 sites before overlap, and in practice planners add overlap so most sensors are heard by two base stations. That redundancy keeps readings flowing when one site loses power or a crane blocks a line of sight for a month.

Good sites are ones the city already controls: rooftops of schools, fire stations and town halls, water towers, and lighting poles with a power supply. Each base station needs power and a backhaul connection, which can be fiber, Ethernet, or a mobile data link. A radio survey with test devices at the hardest locations, such as an underground car park, a basement meter room and a street-level parking bay, tells you more than any coverage map. Record the signal strength at each test point, because those numbers become the baseline when a sensor later starts missing reports.

In-ground parking sensors need their own test. They sit flush with the asphalt, so their antenna points at the sky and spends much of the day under a car's steel floor. A sensor that reaches a base station easily from an empty bay can struggle once a van parks on top of it. Mounting base stations higher, so they look down the street rather than across it, usually helps more than adding transmit power, which is capped by regulation anyway.

The network also needs an owner. Someone has to hold the base station contracts, keep their software updated, replace a failed unit, and decide which department may add which devices. Cities usually give that role to their IT department, a municipal utility or a contractor with a service agreement. Since sensor batteries are often specified for 10 years or more, it makes sense to plan the network for at least that long too, including who will plan the battery replacements when the first large batch of sensors reaches the end of its life.

mioty vs LoRaWAN for a smart city

LoRaWAN is the more familiar choice for city IoT, so it's the natural comparison.

LoRaWAN's advantage is its ecosystem. Far more sensor models exist for it, many cities already have LoRaWAN gateways from earlier projects, and in some countries operators or communities run public LoRaWAN networks. If a department needs a specific sensor tomorrow, there's a good chance a LoRaWAN version exists.

mioty's advantage is density and robustness. Telegram splitting was designed so that very large numbers of devices can share a band without their messages destroying each other, and it tolerates interference better in crowded spectrum. mioty is also a formal ETSI standard. The trade-off is a smaller, younger device catalog, so each sensor type in the plan needs checking for a mioty version before the network design is fixed.

Many cities will run both. A mioty network for high-density, long-life sensors such as meters and parking, alongside existing LoRaWAN gateways for specialized sensors, is a reasonable design, provided the data ends up in one place rather than two separate systems.

The decision works best sensor type by sensor type. List every sensor type in the plan with its expected count, reporting interval and mounting location. Types with thousands of units, frequent messages or difficult locations are strong mioty candidates, as long as a mioty version exists. Types with a few dozen units and a specialized measurement, such as a particular gas or a structural sensor on a bridge, often only exist for LoRaWAN, and that's fine. The list also shows where the two networks would overlap, which helps place base stations and gateways on the same rooftops.

Which smart city platform works with mioty?

A mioty base station needs a service center, mioty's name for the network server that manages devices and passes their readings on. After that, the city needs software where departments see their sensors, set thresholds and get alerted.

With Kilo, the service center comes three ways: the open-source Kilo mioty Service Center, which the city's IT team can host on its own servers; the Enterprise edition built into Kilo Cloud, where you add a mioty connector, point the base stations at it and run no mioty infrastructure yourself; or the Enterprise edition licensed and installed on the city's own premises by Kilo, on request. mioty and LoRaWAN devices then share one organization, the same dashboards and the same rules.

The split between departments happens in the alarms. Each alarm escalates in steps, each with its own recipients and delivery channels, so a full container alerts the waste crew while a rising river gauge reaches the on-call engineer and, if nobody responds, the duty manager.

mioty smart city FAQ

Is mioty used in smart city projects?

Smart cities are one of the application areas the mioty Alliance promotes, alongside metering, industry and buildings. The ecosystem is younger than LoRaWAN's, so most cities considering mioty start by checking which of their planned sensor types are available with a mioty radio, then run a pilot in one district.

Does a mioty smart city network need a mobile operator?

No. mioty runs in license-free spectrum, so the city or a contractor installs and operates the base stations, and sensors need no per-device subscription. The base stations themselves still need an internet or private network connection to the service center, and in Europe every device has to respect the duty-cycle limits that apply to the 868 MHz band.

Is mioty secure enough for smart city use?

The mioty standard encrypts and authenticates messages with AES-128, using a key unique to each device, so a reading can't be read or forged by someone listening on the same frequency. The practical risks sit elsewhere: device keys handed over in spreadsheets, base stations with default passwords, and dashboards shared too widely.

Three waste containers and two air quality points on the same street make a one-district pilot with sensors from two departments. Put all five on one dashboard and add a rule that raises an alarm when a container passes 80% full; a pilot of that size runs on Kilo's free plan. After a month you'll know how often each sensor reports, how reliable the radio is at street level, and whether the departments look at a shared screen.