Smart city IoT that survives the step from twenty test devices to a whole city.
The radio is rarely the hard part. Datasheets that do not match the hardware, devices that report once a quarter and vendors that never planned to talk to each other are. We extend LoRaWAN network servers, evaluate and integrate multi-vendor devices, write the codecs and connect the data to the systems your utility already runs.
Smart city IoT connects metering, tracking and environmental devices across a city to software the operator can run. This engagement covers LoRaWAN network server work, device evaluation, uplink and downlink codecs, and integration into agreed municipal systems, with a complete handover.
Best for
Municipal utilities and cities scaling a LoRaWAN network beyond a pilot
An in-house team that needs engineering hands for infrastructure, devices and codecs
Consider another approach
Connecting machines inside a plant or production line
Device firmware development or radio planning without a software scope
Scale is different engineering, not a bigger pilot
Radio coverage, battery budgets, reporting intervals and data volume behave differently at city scale than on a test bench. Start with the device type that will carry the rollout and the system that needs its data. For the sector view, see Public Sector & Smart City. For IoT products and connectivity in general, start at Internet of Things. Machines and sensors inside a plant belong with Industrial IoT.
The network server layer
A private network on an open-source network server such as ChirpStack gives a city control over gateways, tenants and integrations, and makes radio operations its own responsibility. A managed LoRaWAN service shifts that work to a provider. We help you choose, then build and scale the option you pick.
Network server and infrastructure
Deploy, extend and scale the network server on infrastructure your team can run, including Kubernetes where the platform has earned it, with gateway and tenant management documented.
Device onboarding
Register devices, manage keys and profiles, and agree who may add, move or retire a device in the field.
Data routing
Route decoded data via MQTT or the network server’s integrations to storage, dashboards and downstream systems, with each integration owned and monitored.
Monitoring
Watch gateways, join failures, silent devices and decoding errors, so a missing water meter shows up as an alert, not as a gap in next month’s report.
Every device, its own dialect
Vendors document payloads differently, and the datasheet does not always match the device in front of you. We write uplink decoders and downlink encoders per device type, capture real packets and replay them offline as fixtures, so a firmware update that silently changes a payload fails a test instead of corrupting data. You can try the same workflow in the free LoRaWAN payload codec tester.
Metering, asset tracking and municipal systems
Decoded data is only useful once it reaches the system that acts on it, for example a metering or billing platform, an asset or fleet register, a GIS layer or an operations dashboard. We map each target system, agree the data owner and the failure handling, and test the path with representative devices. Which systems are in scope is confirmed during the assessment. Our smart city architecture guide explains the layers we start from.
Assess, build, hand over
Each phase is scoped and quoted before work starts. Devices, gateways and network fees are listed separately from software work.
Assessment
Receive a network and device inventory, vendor and codec risks, integration targets and a prioritized plan with acceptance criteria.
Build and acceptance
Receive the agreed network server changes, codecs with fixtures, integrations and monitoring, tested with real devices and accepted by your team.
Handover and support
Receive documentation and a walkthrough for your in-house team. New device integrations and support are agreed separately. This does not establish 24/7 coverage or an uptime SLA.
Public infrastructure must not depend on its contractor
The network, codecs and integrations live in your accounts and repositories. At IKB, Innsbruck’s municipal utility, we worked inside an in-flight Smart City build on infrastructure, devices and codecs, alongside IKB’s own team, then handed the platform over completely and stayed available for new device integrations. That is the shape we aim for. Read the IKB case study for what that engagement covered.
// proof
Engineering inside a city-scale LoRaWAN build
IKB documents engineering inside Innsbruck’s in-flight Smart City build alongside IKB’s own team, covering extension of the Kubernetes cluster running ChirpStack, field tests of water meters and cargo-bike trackers, and per-device decoders and encoders, with the platform handed over completely to IKB’s in-house team. It shows that published scope, not a promise of the same result for another network.
▸These are selected projects, not our full portfolio. We have shipped 100+ products since 2018.
Questions before you start
If you want control over gateways, tenants and integrations and have a team to operate them, a private network server is a strong option. If not, a managed service is often the better start. We compare both against your operating capacity.
No. We write the codecs, onboarding, infrastructure and integrations above the firmware. If firmware work is needed, we say so and point you to a hardware partner.
Yes. Joining an in-flight build and owning clearly cut lanes such as infrastructure, device integration and codecs is exactly the IKB shape. We agree the lanes and the handover with your team first.
No. It suits small, infrequent messages from battery devices. Higher throughput, mobility or low latency can point to NB-IoT, LTE-M or other options. The radio follows the use case.
One decoder per device type, normalized into a shared schema, tested against captured packets. Monitoring flags devices whose payloads stop decoding after a vendor update.
Describe the network, the device types and the municipal systems involved. A short outline is enough. Do not send device keys, network credentials or resident data in the first message.
