Smart City Hardware Explained: 6 Layers Turning Cities Into Computers
From IoT sensors and AI-powered cameras to edge computing systems and 5G networks, this complete smart city hardware guide covers the physical infrastructure turning modern cities into intelligent, distributed computers.
Table of Contents
Picture your Tuesday morning commute — but not today’s version.
It’s 7:42 a.m. An ambulance is three blocks behind you. Before any driver hears the siren, the smart city hardware grid has already recalculated. Every light on the ambulance’s path flips green in a rolling wave. Your intersection holds red eleven extra seconds. The ambulance gets through. Nobody pressed a button. Nobody made a call. Nobody had to think about it at all.
You pull into the garage. Bay 4B is lit green — the parking occupancy sensor flagged it open, your nav app pulled that data thirty seconds before you arrived. On the bike ride home, your route app silently reroutes you away from the industrial corridor because a PM2.5 sensor at 5th and Main just registered a spike (that’s particulate matter under 2.5 micrometers — the stuff that actually gets into your lungs, not just irritates your nose).
None of that is science fiction. Most of it runs right now in Singapore, Barcelona, and Kansas City. But here’s what nobody actually explains: what smart city hardware is doing all of that? Not the apps. Not the dashboards. The physical stuff — bolted to poles, buried under asphalt, stuffed inside traffic cabinets on street corners.
That’s what this guide is about.
Smart City Hardware Layer 1: IoT Sensors
Smart cities run on data. Data starts with sensors.
IoT (Internet of Things) sensors are the entry point for almost every smart city hardware system. They’re cheap. Small. They run for years on a battery. One mid-sized deployment can involve hundreds of thousands of them across a single city — which honestly still surprises people when they hear it for the first time.
Here’s what they’re actually measuring out there:
- Traffic flow and vehicle counts — inductive loop detectors buried in road surfaces, or newer radar and LiDAR-based units overhead
- Air quality — electrochemical sensors measuring NO₂, CO, ozone, and PM2.5/PM10 concentrations
- Noise levels — MEMS (Micro-Electro-Mechanical Systems) microphones capturing decibel readings without recording actual audio (an important distinction)
- Parking occupancy — magnetometer-based sensors detecting the ferrous mass of a parked vehicle
- Water infrastructure — pressure sensors and acoustic leak detectors inside pipe networks
- Waste fill levels — ultrasonic sensors inside bins that ping collection teams when capacity hits a threshold
I’ve found that most people assume sensors are just “sending data to the cloud.” The reality is messier — and way more interesting.
A lot of modern smart city hardware sensors run on LPWAN (Low Power Wide Area Network) protocols like LoRaWAN or NB-IoT (Narrowband IoT), which trade raw speed for battery life and range.
A LoRaWAN node — in a low-duty-cycle deployment, like a parking sensor reporting every few minutes — can run three to five years on two AA batteries across several kilometers of range, per LoRa Alliance documentation. Battery life compresses fast at higher transmission rates or larger payloads; the figure is configuration-dependent, not a universal spec.
But that tradeoff — long battery life, modest data rate, low cost — is exactly what makes sensors viable at city scale.
Smart City Hardware Layer 2: AI-Powered Cameras
Let me be direct: modern smart city cameras are AI inference hardware with a lens attached.
The shift happened when edge computing got cheap enough to fit inside the camera housing itself. Older CCTV sent everything to a central server. Newer systems — think the Axis Lightfinder series or Bosch FLEXIDOME IP cameras — run on-board neural network processors that analyze video locally and only push results upstream, not raw footage.
This matters enormously for bandwidth, latency, and — depending on your perspective — privacy.
So what are those processors actually doing?
- Vehicle classification — not just “something moved,” but was it a bus, bicycle, scooter, or pedestrian?
- Crowd density estimation — using body-pose and silhouette models that, in their typical deployed configuration, work without facial recognition. Whether a deployment enables or disables facial recognition is a policy and configuration decision, not a hardware-enforced constraint; the same inference hardware can run either class of model.
- Incident detection — falls, fights, abandoned objects, traffic accidents
- License plate recognition (LPR) — via dedicated LPR modules that run separately from general scene analysis
The smart city hardware landscape here varies a lot by vendor — and it’s moving fast.
NVIDIA’s Jetson Orin family — ranging from the Jetson Orin Nano (40 INT8 TOPS sparse, per NVIDIA’s published module datasheet DS-10712) up to the Jetson AGX Orin 64GB (275 INT8 TOPS sparse / 170 TOPS dense, per NVIDIA’s AGX Orin Technical Brief) — is widely deployed across existing smart city camera builds.
That sparse-vs-dense distinction matters when you’re actually speccing these systems. The 275 TOPS headline is for sparse networks. Real-world dense workloads on the top module run at 170 TOPS. That’s not a footnote — it’s the number a procurement engineer actually plans around.
But Orin isn’t the ceiling anymore. NVIDIA announced general availability of the Jetson AGX Thor (Blackwell architecture) in 2025 — up to 2,070 FP4 TFLOPS, 7.5x greater AI compute than Orin, per NVIDIA’s published announcement. For new multi-modal builds running simultaneous LiDAR, radar, camera, and audio processing, Thor is emerging as the leading reference platform. Orin stays the practical workhorse for a massive installed base of mid-tier applications.
Beyond NVIDIA? The market is genuinely fragmented: Hailo, Qualcomm Dragonwing, Intel Core Ultra Edge (via OpenVINO), Ambarella CVflow, AMD Kria, NXP i. MX AI — all competing in specific segments, often with lower power draw suited to battery or solar-powered deployments.
To be honest, the camera is still the least interesting part. The sensor fusion — combining camera output with radar data, audio, and environmental readings — is where the actual intelligence lives.
Smart City Hardware Layer 3: Edge Computing Nodes
Here’s the thing about cloud computing in a real-time city: it’s too slow for some decisions.
A pedestrian steps off a curb. A connected vehicle needs to brake. You cannot afford 80–120ms of round-trip latency to a cloud data center. You need a decision in single-digit milliseconds. That’s the job of edge computing.
Edge computing nodes — technically called MEC (Multi-access Edge Computing) servers, an architecture standardized by ETSI’s Industry Specification Group (ETSI ISG MEC) — are small ruggedized compute units deployed right at or near the data source. Think of them as mini data centers stuffed inside the traffic cabinets you walk past every day without noticing.
A typical smart city hardware edge node carries:
- A ruggedized server chassis — some certified to the -40°C to +70°C range per IEC 60068-2 environmental testing specifications (which covers thermal, humidity, and shock testing — distinct from the IP ingress protection ratings on the enclosure itself; thermal qualification is its own separate track)
- A multi-core CPU — often Intel Xeon D or AMD EPYC Embedded variants, chosen for power efficiency in sealed spaces
- A GPU or dedicated AI accelerator for local inference
- Local SSD storage for buffering when connectivity drops
- Hardware security modules (HSMs) for cryptographic key management
Dell, HPE, and Cisco all publish smart city hardware edge reference architectures — and they all say the same thing: the edge node is not a cloud replacement. It’s a pre-processing layer. It filters, compresses, analyzes locally. Summaries and anomalies go upstream. Raw data mostly doesn’t.
Smart City Hardware Layer 4: 5G and Connectivity
All this hardware has to talk to something. Fast.
Here’s what telecom marketing won’t tell you: for many smart city deployments, fiber is still the actual backbone. Traffic cabinets, cameras, public safety systems in dense urban areas — they frequently run on fiber or municipal Ethernet. More reliable, lower latency, already conduit-installed in most cities. 5G fills the gaps where fiber can’t go: wide-area sensor coverage, mobile assets, locations where you can’t trench.
That said, 4G LTE can’t handle the data density advanced deployments are generating. HD video streams, real-time vehicle-to-infrastructure (V2X) communication, and dense sensor networks with tight latency requirements are pushing cities toward 5G.
V2X latency thresholds vary by application — per 3GPP TS 22.186, cooperative collision warning requires end-to-end latency under 20ms, platooning applications specify under 25ms — and none of those are achievable reliably at scale over 4G LTE.
The 5G NR (New Radio) configurations that actually matter for smart city hardware:
- Sub-6 GHz 5G — wide-area coverage, manageable infrastructure density
- mmWave (millimeter wave) 5G — ultra-high-throughput, low-latency for dense intersections with heavy camera and sensor loads
- 5G RedCap (Reduced Capability, 3GPP Release 17) — this one doesn’t get nearly enough attention. RedCap sits between full 5G NR and legacy NB-IoT: more bandwidth and lower latency than LPWAN, far lower device cost and power draw than full 5G. For the millions of smart city sensors that don’t need full 5G throughput but have outgrown NB-IoT, RedCap is the practical 2026 answer.
On carrier availability: AT&T launched nationwide RedCap coverage across 200M+ POPs in July 2025 (per Fierce Network and RCR Wireless). T-Mobile launched the first commercial RedCap device in North America in October 2024 (per T-Mobile Newsroom). All three major US carriers now support 5G SA networks with RedCap capability, per Semtech/Omdia industry analysis from November 2025.
The radio hardware itself: 5G small cells — low-power base station nodes mounted on streetlights and utility poles. Ericsson, Nokia, and Samsung Networks are the dominant RAN (Radio Access Network) equipment vendors at scale in North American and European smart city projects, supplemented by Dell’Oro Group and Omdia market data.
Open RAN deployments from vendors like Mavenir are gaining some traction in certain municipal programs, but full small cell deployments still skew heavily toward the established vendors.
One piece most people skip entirely: C-RAN (Centralized Radio Access Network) architecture, which separates the radio unit on the pole from the baseband processing unit in a centralized facility. Reduces hardware complexity at every street-level installation point. Not glamorous. Genuinely important.
Smart City Hardware Layer 5: Smart Streetlights and Gateways
Streetlights. Doing a lot of work.
Modern smart city streetlight infrastructure — systems from Signify (formerly Philips Lighting) or Itron’s networked lighting platforms — aren’t just LED fixtures anymore. They’re IoT gateways.
Each pole can carry:
- The primary LED luminaire with dimming control
- An embedded NLC (Networked Lighting Controller) with cellular or mesh connectivity
- Sensor mounting points for air quality, noise, and parking modules
- Power metering hardware for real-time energy tracking
- A small UPS (Uninterruptible Power Supply) buffer for outages
Per Signify’s Interact City platform documentation — the current active system (CityTouch is legacy hardware for installed base; Interact City is what’s shipping now), operating in over a thousand cities globally — individual luminaires can be dimmed, scheduled, and fault-diagnosed remotely. Every node continuously reports energy and operational status upstream.
The pitch for streetlights as a smart city hardware deployment platform is simple: the electrical infrastructure already exists.
But to be honest, it’s not as clean as “just upgrade the pole.” Many legacy streetlight circuits run as unmetered series circuits at constant current — not individually addressable feeds — which means a full smart city retrofit often requires adding circuit breakers, metering hardware, and sometimes entirely new wiring runs on top of the controller and sensor stack. The civil engineering cost is real, even when you keep the poles.
PCB reliability: the specification nobody talks about
Here’s something that almost never gets discussed in smart city hardware coverage: the PCB reliability requirements for outdoor infrastructure are categorically different from consumer electronics.
Cities often expect outdoor infrastructure to stay operational for a decade or longer — through thermal cycling, humidity, vibration, UV exposure.
High-reliability deployments typically specify IPC-6012 Class 3 (or Class 3/A for the most demanding environments) as the manufacturing quality target for rigid PCBs, though requirements vary by application; some deployments use Class 2 with supplementary environmental protection.
Outdoor boards in many installations use conformal coatings qualified to IPC-CC-830, though potting and sealed IP67/IP68 enclosures are equally valid approaches depending on the deployment.
The point is simple: the difference between a sensor that fails in 18 months and one that runs reliably for a decade often comes down to these manufacturing specs — not the processor inside it. I’ve watched this play out firsthand with clients. It’s not abstract.
Smart City Hardware Layer 6: Data Centers and Command Layer
All of this edge data lands somewhere more permanent.
Most advanced smart city deployments run a tiered architecture: edge nodes handle real-time processing, a regional aggregation layer handles city-district data, and a central City Operations Center (COC) — sometimes called a City Brain, though some municipalities have moved away from that term — handles analytics, dashboards, and long-range planning.
COC hardware is enterprise-grade:
- Hyperconverged infrastructure (HCI) platforms — Nutanix and VMware vSAN are common in municipal builds
- High-throughput storage arrays for long-term sensor and video retention
- GPU clusters for batch AI workloads (traffic pattern analysis, predictive maintenance modeling)
- Network operations hardware with redundant uplinks and DDoS mitigation appliances
OT cybersecurity: the threat model most articles get wrong
Cybersecurity matters here — a lot. Smart city hardware infrastructure is critical infrastructure, full stop.
Hardware firewalls, network TAPs (Test Access Points) for passive traffic monitoring, HSMs for key management — all standard at this layer.
Per NIST SP 800-82 Revision 3 (published September 2023, currently the operative authoritative guide to Operational Technology (OT) security), network segmentation between OT and IT networks is a central design requirement. The standard recommends Industrial Demilitarized Zones (IDMZs) to mediate controlled communication between enterprise IT and OT networks — not direct connectivity.
Worth flagging: NIST initiated a pre-draft call for Revision 4 in January 2026, explicitly targeting NIST Cybersecurity Framework (CSF) 2.0 alignment and updated OT threat profiles including Zero Trust and AI-driven OT environments. Final Rev. 4 guidance is expected later in 2026.
Here’s something the hardware list above doesn’t capture: the OT security threat model is fundamentally different from enterprise IT.
Traditional IT prioritizes confidentiality first. OT prioritizes availability and safety first — because a compromised traffic signal controller has physical consequences, not just data ones.
Firmware integrity, hardware root-of-trust mechanisms, secure boot on edge nodes — increasingly specified in serious municipal procurements, not optional extras. CISA and NIST SP 800-82r3 both explicitly recommend these for OT environments connected to public infrastructure. Several US federal grant programs under the Infrastructure Investment and Jobs Act now reference cybersecurity baseline requirements that cover exactly these mechanisms.
What 2026 procurement is adding: ZTA, SBOM, and PQC
What 2026 smart city hardware procurement is adding on top of that foundation: Zero Trust Architecture (ZTA), Software Bill of Materials (SBOM), and early Post-Quantum Cryptography (PQC) planning.
Zero Trust means every field device — yes, including the parking sensor — must cryptographically attest its identity before joining the network, rather than relying on perimeter segmentation alone.
SBOM requirements (driven by the 2021 Executive Order on Improving the Nation’s Cybersecurity and CISA guidance) mean cities are demanding a full manifest of software components in every edge device, so vulnerable dependencies can be found fast when CVEs drop.
And PQC migration matters because of the lifecycle problem: a sensor going in the ground today could still be there in 2035, when current RSA and ECC schemes could be vulnerable to quantum computing attacks. NIST finalized its first PQC standards in 2024 — FIPS 203, 204, and 205. Forward-thinking municipal RFPs are starting to require PQC-ready HSMs and key management infrastructure.
Most cities aren’t there yet. But the smart city hardware being specified today needs a migration path built in from the start.
What Ties the Smart City Hardware Stack Together
Step back. Look at the full stack.
Sensors at the ground level. Edge nodes doing local inference. 5G and fiber connecting everything. Streetlights doubling as IoT gateways. Regional aggregation servers. A central operations platform at the top.
Every layer of smart city hardware is purpose-built for its job, all of them talking to each other in something close to real time.
That’s not metaphor. A city with this infrastructure deployed is, functionally, a distributed computing system. Sensors are the input devices. Edge nodes are the local processors. The COC is the main compute cluster. The city is running software.
The smart city hardware making your Tuesday commute smoother isn’t invisible magic — it’s ruggedized server chassis in traffic cabinets, magnetometers under parking spots, and 5G small cells on the same poles that light your street at night.
Once you see it, you can’t unsee it.
About the Author
Imran Valiani | Sales Director, PCB Electronics Manufacturing — 20+ years working with major Bay Area and global tech clients. Founder of Silicon to Software, where I write about the hardware layer — PCB fab, AI gear, autonomous systems, and cyber — the stuff most tech writers have never touched. Literally.
Follow: X @SiToSoftware | LinkedIn
This post was written with AI assistance. See my full AI disclosure.
Sources
- NVIDIA Jetson Orin NX/Nano Series Module Datasheet, DS-10712 — developer.nvidia.com
- NVIDIA Jetson AGX Orin Series Technical Brief v1.2 — nvidia.com
- NVIDIA Newsroom: “NVIDIA Blackwell-Powered Jetson Thor Now Available” — nvidianews.nvidia.com
- LoRa Alliance Technical Marketing Workgroup documentation — lora-alliance.org
- IEC 60068-2: Environmental Testing for Industrial Electronic Equipment — iec.ch
- ETSI ISG MEC: Multi-access Edge Computing specifications — etsi.org
- 3GPP Release 15/16 (5G NR) and 3GPP TS 22.186 (V2X service requirements) — 3gpp.org
- T-Mobile Newsroom: “5G RedCap — Powering Smart Devices with Smarter 5G” (Dec 2025) — t-mobile.com
- RCR Wireless: “AT&T intros nationwide 5G RedCap for mid-tier IoT” (July 2025) — rcrwireless.com
- Fierce Network: “AT&T ups its IoT game with nationwide 5G RedCap coverage” (July 2025) — fierce-network.com
- Semtech/Omdia: “Is It Time to Move from LTE to RedCap?” (Nov 2025) — sierrawireless.com
- Signify Interact City platform documentation — interact-lighting.com
- NIST SP 800-82 Rev. 3 (2023): “Guide to Operational Technology (OT) Security” — csrc.nist.gov
- NIST SP 800-82 Rev. 4 Pre-Draft Call for Comments (Jan 2026) — csrc.nist.gov
- NIST Post-Quantum Cryptography Project: FIPS 203, 204, 205 — csrc.nist.gov
- IPC-6012 Revision F (Oct 2023): Qualification and Performance Specification for Rigid Printed Boards — ipc.org
- IPC-CC-830: Qualification and Performance of Electrical Insulating Compound for Printed Wiring Assemblies — ipc.org
- Axis Communications product datasheets — axis.com
- Bosch Security Systems FLEXIDOME IP camera documentation — boschsecurity.com
- ITU-T Focus Group on Smart Sustainable Cities (FG-SSC) — itu.int
Note: City-level deployment statistics vary significantly by source and vintage. For standardized benchmarks, consult the ITU-T FG-SSC reports directly. The Silicon to Software URL in the author bio above should be replaced with the live domain before publishing.
