The phrase smart city has carried a lot of marketing weight, which obscures the modest truth: a city is a large owner of physical assets, and IoT lets it know the state of those assets without sending someone to look. Streetlights, bins, parking bays, water pipes, bridges, bus stops and air all become reportable. Most of what a city does with that is operational, not futuristic.
The projects that have lasted are the ones that saved money or improved a service that residents noticed. The projects that failed usually tried to build a city-wide platform first and find uses for it later.
This guide covers the services with a track record, the networks a city uses to reach thousands of small devices, the data and governance questions that come with public infrastructure, and how to tell a durable project from a demo.
The services with a track record
Street lighting. Connected luminaires that report failures, dim on schedule or by occupancy, and meter their own consumption. Lighting is often the largest single line in a municipal electricity bill, so smart lighting tends to be the first project because the savings are measurable and the poles provide power and height for other sensors.
Waste collection. Fill-level sensors in public bins and containers let collection routes follow actual need rather than a fixed schedule. Fewer trucks pass empty bins, overflowing ones are caught earlier.
Parking. In-ground or overhead sensors report bay occupancy for smart parking guidance and enforcement. The benefit is less circling traffic and better use of existing spaces; the pitfall is sensor maintenance in a surface that gets dug up, salted and driven over.
Air quality and noise. Dense networks of low-cost sensors complement the few reference-grade stations a city can afford. The sensors are less accurate, but their number reveals patterns the reference stations miss, which is environmental monitoring at street level. Calibration against reference stations is the ongoing work.
Water. Smart meters for billing and leak detection, pressure and flow sensors on the distribution network to locate bursts, level sensors in storm drains and rivers for flood warning. Water utilities are often the most mature IoT users in a city because leakage is a direct financial loss.
Structures and transport. Structural health monitoring of bridges and tunnels with strain and vibration sensors; traffic counting and signal adaptation; passenger counting and arrival prediction on public transport; shared mobility fleets with telematics.
Each of these is a separate system with a separate owner inside the municipality. Treating them that way, rather than as one grand platform, is usually what makes them work.
Networks for a city full of small devices
City devices are numerous, low-data, often battery-powered and spread over many square kilometers. That profile points to LPWAN technologies.
LoRaWAN lets a city own its network: a few dozen gateways on tall buildings and towers cover a mid-sized city, the city controls the data path, and there is no per-device subscription. Many municipalities run their own LoRaWAN networks precisely to avoid operator dependence and to let departments add sensors cheaply. The trade-offs are the city becoming a network operator, with the maintenance that implies, and the limits on message size and frequency.
NB-IoT and LTE-M use operator networks, which removes the maintenance burden and gives better penetration into basements and underground chambers in some cases. The cost is a recurring subscription per device and dependence on the operator’s roadmap. Mixed deployments are common: LoRaWAN for the bulk of simple sensors, cellular for assets that move or need more bandwidth, Wi-SUN or similar meshes for utility meters and lighting controllers where the installed base is dense enough to mesh.
Street lighting networks deserve a note. Because luminaires are mains-powered and spaced regularly along every street, they form a natural mesh network backbone that other sensors can ride on, and several lighting control systems are sold on exactly that basis.
Data, platforms and the integration problem
The value of city data grows when it is combined: parking occupancy with traffic counts, air quality with weather and traffic, bin levels with collection routes. That requires the departments’ separate systems to publish into something shared. The approach that has gained traction is a city data platform exposing standard APIs and data models, so that a new application can read parking and lighting data without bespoke integration for each, and so that the city can switch vendors for one service without re-plumbing the rest. Open standards and open data policies are the tools against vendor lock-in, which is a real risk when a single supplier offers to run everything.
Edge processing matters for the heavier sources. Traffic cameras and acoustic sensors generate data that should be reduced on site, both for bandwidth and because raw video of a public street is personal data. Counting vehicles or pedestrians at the camera and transmitting only counts is the pattern that regulators and residents accept.
Governance: the part that decides outcomes
Public infrastructure raises questions a private deployment does not.
Privacy is first. Sensors in public space observe everyone, including people who never consented. Cities that have kept public trust have published what each sensor collects, minimized collection to what the service needs, avoided identifying individuals, and run privacy impact assessments before deployment. Cities that deployed face recognition, license plate reading or detailed movement tracking without that process have faced legal challenges and cancelled projects.
Procurement is second. Municipal contracts are long, and a city that buys a closed platform may be locked in for a decade. Specifying open interfaces, data ownership by the city, and exit provisions in the contract is more important than any technical feature.
Operations is third. Sensors fail, batteries die, firmware needs updates, and the department that bought the system must have the budget and skills to keep it running after the pilot funding ends. Many smart city deployments have silently decayed because nobody owned the maintenance.
Equity is fourth. If sensors and services concentrate in the city center, the data and the benefits do too. Coverage decisions are policy decisions.
Telling a project from a demo
A project with a future answers four questions plainly: which department owns it, which cost or service metric it will move, how the devices will be maintained for their lifetime, and how the data will be governed and shared. A demo answers with a vision statement. The technology for both is often identical.
Where to go next
- LoRaWAN explained covers the network many cities choose to own.
- NB-IoT and LTE-M explained explains the operator-run alternative.
- IoT in energy goes into smart metering and grid-side deployments that overlap with municipal utilities.
- Edge computing explained shows why cameras and acoustic sensors should process locally.
Topics: smart city, street lighting, LoRaWAN, NB-IoT, public infrastructure