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. The individual pieces — adaptive traffic signal priority, parking occupancy sensing, air-quality-based routing — are already deployed technology classes in cities like Singapore, Barcelona, and Kansas City, among others. Not necessarily wired together into the exact composite pipeline above, but the hardware to build that pipeline already exists and is running today. So 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. A mid-sized city deployment can reasonably involve tens to hundreds of thousands of them once you count traffic, air quality, parking, water, and waste sensors across every block — that’s an order-of-magnitude estimate based on typical per-block sensor density, not a documented citywide count, but it’s the scale that makes people’s jaws drop the first time they hear it.
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 one of the more commonly cited platforms across existing smart city camera builds, based on vendor documentation and industry reporting rather than independent market-share data.
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 NVIDIA’s newest and most capable platform for this workload class — whether it becomes the dominant deployed choice is a market outcome still playing out, not something the spec sheet itself proves. 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. If you want to go deeper on how these chips compare across power, latency, and form factor, I covered the full landscape in Edge AI Chips: The Future of AI Hardware and Why They’re Replacing Cloud-Based Intelligence.
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.
Take a pedestrian stepping off a curb in front of a connected vehicle. For that specific class of safety-critical, split-second control decision, you cannot afford 80–120ms of round-trip latency to a cloud data center — you need single-digit milliseconds. That’s the job of edge computing. It’s worth being clear that this urgency applies to safety-critical, real-time control decisions specifically — a lot of city analytics, like weekly traffic pattern trends or long-term air quality modeling, tolerate cloud-level latency just fine. The edge argument is strongest exactly where physical consequences are seconds away.
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 — commonly specified for extended operating ranges around -40°C to +70°C, validated using IEC 60068-2 environmental test methods (thermal cycling, humidity, and shock testing procedures). It’s worth being precise here: IEC 60068-2 defines how to test for these conditions, not a certified range itself — the actual operating range is a manufacturer specification backed by that testing, and it’s a separate track entirely from the IP ingress protection ratings on the enclosure
- 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, for the specific case of dense, synchronized sensor and video networks running near real-time control loops, 4G LTE runs into real limits on data density and latency consistency that 5G is built to solve. HD video streams, real-time vehicle-to-infrastructure (V2X) communication, and dense sensor networks with tight latency requirements are pushing cities toward 5G for exactly this class of workload — this isn’t a claim that 4G LTE can’t handle high data volumes generally, since it clearly does across consumer mobile broadband every day.
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. Typical 4G LTE round-trip latency under real-world network load commonly runs well above those thresholds, which is why engineers generally don’t treat 4G LTE as a reliable foundation for this specific tier of V2X requirement at city scale — though it’s worth noting the 3GPP document itself defines the requirement, not a real-world failure rate.
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 looks, in my judgment, like the practical answer for 2026 — though that’s an engineering call based on current carrier rollouts, not a settled industry consensus.
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.
And if you’re wondering what comes after 5G for smart city infrastructure — the short answer is that the hardware to build 6G doesn’t fully exist yet. I broke down exactly why in 6G Technology Hardware: Why the Infrastructure to Build It Doesn’t Exist Yet.
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 — particularly older municipal installations across the US and parts of Europe — 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: in my experience, the gap between a sensor that fails early — say, within a year or two — and one that runs reliably for a decade often comes down to these manufacturing specs, not the processor inside it. That’s an illustrative contrast from what I’ve watched play out with clients, not a documented failure-rate statistic. 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. This tiered model is representative of how leading deployments are commonly architected, not a single mandated blueprint every city follows.
COC hardware is enterprise-grade:
- Hyperconverged infrastructure (HCI) platforms are common in enterprise-style municipal builds, drawing on the same vendor landscape (Nutanix, VMware vSAN, and others) widely used in general enterprise IT
- 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 sits directly on top of transportation, energy, and water systems that are themselves designated critical infrastructure sectors, which is exactly why the OT security bar here is high, even though “smart city” isn’t itself a named regulatory category.
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 core recommended practice. The NIST guidance 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. The same hardware attack surface shows up in autonomous vehicles sharing the same road infrastructure — something I covered in depth in Self-Driving Cars Have a Hardware Security Problem Nobody Wants to Talk About.
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 recommend these for OT environments connected to public infrastructure. And there’s real federal money moving in this direction: the IIJA-funded State and Local Cybersecurity Grant Program (SLCGP), jointly administered by CISA and FEMA, requires grant recipients to adopt a formal Cybersecurity Plan and adhere to CISA Cyber Hygiene Services as a funding condition — a general risk-reduction requirement rather than one that names specific hardware mechanisms like secure boot by statute, but one that’s pushing municipalities in exactly this direction.
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, as a design principle, holds that every field device — yes, including the parking sensor — should cryptographically attest its identity before joining the network, rather than relying on perimeter segmentation alone. That’s the target architecture cities are increasingly designing toward, not yet a universal requirement in force everywhere today.
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. Given that timeline, it’s a reasonable bet that municipal RFPs will start asking for PQC-ready HSMs and key management infrastructure well before 2035 — I haven’t seen that show up broadly in procurement language yet, but the lifecycle math makes it close to inevitable.
Most cities aren’t there yet. But the smart city hardware being specified today needs a migration path built in from the start. If you want to understand why this matters urgently for embedded devices specifically — not just servers — Your Embedded Hardware Has a Quantum Problem Nobody Is Talking About covers the board-level reality in detail. And for the broader picture of what quantum computing does to today’s encryption standards, The Quantum Computer Is Coming: Why Today’s Encryption Could Soon Be Useless is the right starting point.
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
For more analysis of embedded hardware, electronics, and system-level engineering constraints, explore the Embedded Systems & Electronics Engineering Resource Hub.
This article was developed with AI assistance and edited, fact-checked, and reviewed by the author. 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 – Part 2: Tests (International Electrotechnical Commission) — 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
- CISA / FEMA: State and Local Cybersecurity Grant Program (SLCGP), funded under the Infrastructure Investment and Jobs Act — cisa.gov
Note: City-level deployment statistics vary significantly by source and vintage. For standardized benchmarks, consult the ITU-T FG-SSC reports directly.
