Edge Intelligence in Urban Landscapes: Reviewing TinyML Applications for Connected and Sustainable Smart Cities

Abstract

Tiny Machine Learning (TinyML) extends edge AI capabilities to resource-constrained devices, offering a promising solution for real-time, low-power intelligence in smart cities. This review systematically analyzes 66 peer-reviewed studies from 2019 to 2024, covering applications across urban mobility, environmental monitoring, public safety, waste management, and infrastructure health. We examine hardware platforms and machine learning models, with particular attention to power-efficient deployment and data privacy. We review the approaches employed in published studies for deploying machine learning models on resource-constrained hardware, emphasizing the most commonly used communication technologies—while noting the limited uptake of low-power options such as Low Power Wide Area Networks (LPWANs). We also discuss hardware–software co-design strategies that enable sustainable operation. Furthermore, we evaluate the alignment of these deployments with the United Nations Sustainable Development Goals (SDGs), highlighting both their contributions and existing gaps in current practices. This review identifies recurring technical patterns, methodological challenges, and underexplored opportunities, particularly in the areas of hardware provisioning, usage of inherent privacy benefits in relevant applications, communication technologies, and dataset practices, offering a roadmap for future TinyML research and deployment in smart urban systems. Among the 66 studies examined, 29 focused on mobility and transportation, 17 on public safety, 10 on environmental sensing, 6 on waste management, and 4 on infrastructure monitoring. TinyML was deployed on constrained microcontrollers in 32 studies, while 36 used optimized models for resource-limited environments. Energy harvesting, primarily solar, was featured in 6 studies, and low-power communication networks were used in 5. Public datasets were used in 27 studies, custom datasets in 24, and the remainder relied on hybrid or simulated data. Only one study explicitly referenced SDGs, and 13 studies considered privacy in their system design.

1. Introduction

As cities become increasingly connected and reliant on data, the demand for smart systems that are fast, energy-efficient, and secure continues to grow. The rapid expansion of the Internet of Things (IoT), which now includes tens of billions of connected devices, has accelerated efforts to embed intelligence directly at the edge, even on highly resource-constrained hardware [1]. Many smart city applications—like traffic monitoring, environmental sensing, and public safety—require quick decision-making close to where the data is collected. Traditional cloud-based AI methods often struggle in these situations because they depend on constant internet connections and use a lot of power and bandwidth. Tiny Machine Learning (TinyML) is a new solution that brings AI to the very edge of the network, allowing devices to process data locally.

TinyML enables machine learning on low-power microcontrollers with limited memory and power. With tools like TensorFlow Lite Micro and Edge Impulse [2], these devices can run efficient AI models consuming only milliwatts. However, as [3] emphasizes, activation memory—not just model size—is a major constraint, making direct adaptation from mobile models ineffective. The work underscores the need for co-designed architectures tailored to hardware limits and task demands, a theme that recurs throughout this review.

TinyML offers significant benefits for smart city applications. It allows devices to make decisions on their own, without sending all their data to the cloud. This reduces delays and saves energy. Notably, it improves privacy by keeping sensitive data like images or sounds on the device, which is one of the main reasons TinyML is being used in the Internet of Things (IoT), as pointed out in [1,4]. The technical overview by [5] also highlights how TinyML works and why it is useful in limited-resource environments.

However, most current reviews focus on TinyML’s tools and technology, not on how it’s used in real-world smart city projects. For example, ref. [2] gives an overview of TinyML platforms and models but doesn’t look at specific deployments or use cases. The book in [6] provides practical steps for developers but doesn’t compare findings across domains. Although informative, ref. [4] doesn’t analyze how TinyML supports smart city goals like sustainability, mobility, or safety.

Other reviews focus on more general edge computing. Papers like [7,8] discuss large-scale edge and fog systems, showing how AI can run closer to users instead of in distant cloud servers. While useful, they don’t talk about the unique challenges of TinyML devices. Ref. [9] Looks at edge and fog AI for scheduling and quality of service, but doesn’t deal with tiny devices or embedded ML.

Privacy is a key concern in many smart city projects, especially when devices handle images, sounds, or personal data. The review in [10] outlines important techniques like federated learning and data anonymization that enable privacy. But as [11] shows, these methods are mostly used in training systems, not in TinyML deployments that only do inference on-device. Although TinyML is commonly linked to privacy benefits because of its on-device processing, our review shows that few systems explicitly adopt or report privacy-by-design principles as a core objective, even where such considerations would be applicable.

From a broader perspective, ref. [12] argues that smart city technologies must be affordable, power-efficient, and accessible to everyone. TinyML supports these values by running on cheap, low-power hardware. Yet no past review has checked how well current TinyML projects support global goals like the United Nations Sustainable Development Goals (SDGs)—a key part of building responsible and future-ready cities.

To address these gaps, this systematic literature review (SLR) analyzes 66 peer-reviewed studies published between 2019 and 2024 that deploy or simulate TinyML in smart city applications. Following the PRISMA methodology, we categorize the studies by application domain, hardware platforms, learning models, communication technologies, power usage, and whether they report or make use of TinyML’s inherent privacy benefits, as well as whether they address the SDGs. We also identify recurring design patterns, common technology choices, and key areas with development gaps.

Incorporating evidence from various fields, this review surveys the current landscape of TinyML applications in urban areas. It shows both the potential and the current limits of the technology and guides future work toward building secure, efficient, and sustainable smart city systems.

2. Methodology

We employ a systematic literature review (SLR) approach, following the PRISMA (Preferred Reporting Items for Systematic Reviews and Meta-Analyses) [13] framework to ensure transparency, reproducibility, and a structured selection of relevant research. The objective is to evaluate the implementation of Tiny Machine Learning (TinyML) in smart city applications. This systematic review was not registered in a publicly accessible database or registry.

2.1. Eligibility Criteria

The eligibility criteria applied in this review are summarized in Figure 1. To uphold methodological rigor and relevance, studies were included if they met all of the following criteria:

• Edge-AI implementation: Employed TinyML, either through deployment or simulation, for edge devices.
• Smart-city focus: Addressed an application area such as mobility, environmental sensing, public safety, waste management, or infrastructure monitoring.
• Publication quality: Appeared in a peer-reviewed journal or conference between 2019 and 2024, ensuring quality and recency.
• Hardware disclosure: Reported the target edge hardware or simulated platform relevant to deployment.
• Technical transparency: Provided sufficient technical detail to evaluate the TinyML model and its deployment feasibility.

While the review focuses on studies that implement or simulate TinyML models in smart city contexts, several related works were excluded from the core dataset due to methodological limitations. For example, ref. [14] presents a conceptual policy framework involving TinyML but does not implement any machine learning model. Study [15] uses classical edge detection filters (Sobel, Canny) without any ML-based inference. Similarly, ref. [16] proposes a future TinyML use case in a cellular vehicle network but lacks any deployed model, dataset, or evaluation.

2.2. Study Selection Process

A systematic search strategy was employed to identify relevant studies based on the eligibility criteria defined in Section 2.1. The process followed the PRISMA 2020 guidelines to ensure transparency, reproducibility, and methodological rigor.

The literature was retrieved from six major academic databases: Scopus, IEEE Xplore, MDPI, ACM Digital Library, Web of Science, and Google Scholar (used for supplementary searches). Our multi-database strategy aligns with best practices recommended by [17], who emphasize that comprehensive systematic reviews in technology-related fields require both broad and subject-specific databases. Likewise, ref. [18] demonstrated that Scopus and Web of Science each capture unique records, and together offer broader coverage for bibliometric analyses than any single database. Preprint archives were excluded in favor of peer-reviewed sources, ensuring methodological consistency while acknowledging the potential omission of some emerging research. A conceptually consistent set of Boolean search strings was applied across all databases to capture studies at the intersection of TinyML, smart cities, and edge AI. To ensure transparency and reproducibility, the full search queries tailored to each database’s syntax are provided in

Table 1. Boolean Search Queries Used Across Academic Databases for Study Identification.

Database	Search Query
Scopus	TITLE-ABS-KEY((“TinyML” OR “Tiny Machine Learning”) AND (“smart city” OR “urban sensing”) AND (“edge AI” OR “embedded ML”)) AND PUBYEAR > 2018
IEEE Xplore	(“TinyML” AND “smart city”) AND (“edge AI” OR “microcontroller” OR “low-power AI”)
Web of Science	TS = (“TinyML” OR “Tiny Machine Learning”) AND TS = (“smart city” OR “urban”) AND TS = (“edge AI” OR “on-device intelligence”)
ACM DL	“TinyML” AND “smart city” AND “edge AI”
MDPI	“Tiny Machine Learning” AND “smart city”;
Google Scholar	“TinyML” + “smart city” + “embedded AI”;

.

The selection criteria included only peer-reviewed journal articles and conference papers published between 2019 and 2025, and limited to publications in English. All records were imported into EndNote (version 21), where duplicates were automatically identified and removed before screening. This initial filtering step is reflected in the exclusion count presented in Section 2.3.

The selection process consisted of three main stages: title and abstract screening, full-text review, and quality assessment. These steps were designed to exlcude out irrelevant, duplicate, or low-quality studies while retaining those that met all inclusion criteria.

To further support the scope of the review, a trend analysis was conducted in Scopus using the keyword “Tiny Machine Learning.” Scopus was chosen for this analysis due to its broad coverage among the databases used and its reputation as a reliable source for bibliometric research [18]. As shown in Figure 2, the number of related publications has increased significantly since 2021, reinforcing the choice of 2019–2024 as the review period and highlighting the field’s rapid evolution. The full selection flow, which follows the PRISMA 2020 standard [13] and documents the number of studies retained and excluded at each stage, is presented in Section 2.3.

2.3. Screening Process

Following the database search and deduplication, a multi-stage screening process was conducted to identify studies meeting the eligibility criteria defined in Section 2.1. The full screening workflow is summarized in Figure 3, following the PRISMA 2020 guidelines.

In the first stage, duplicate records were removed using EndNote reference management software. Titles and abstracts were then screened to exclude studies that were unrelated to the scope of TinyML deployment in smart city contexts. We excluded studies focused on unrelated domains such as healthcare or smart homes, as well as conceptual proposals, speculative applications, or policy frameworks that lacked technical implementation details.

The remaining studies underwent a full-text review to confirm eligibility. Studies were retained if they described or simulated edge AI implementations with a focus on TinyML, reported the target hardware or simulated deployment platform, and addressed smart city application areas. Only articles satisfying all inclusion criteria were advanced for final assessment. In the final stage, each study was evaluated for methodological quality based on three dimensions:

• Technical depth: the clarity and completeness of model design, optimization techniques, and deployment configuration.
• Application significance: relevance to real-world urban challenges and smart city priorities.
• Experimental validation: inclusion of empirical results, implementation evidence, or simulation-based feasibility.
• Only studies meeting all quality thresholds were included in the final synthesis.

All stages of screening, full-text review, and quality assessment were conducted by a single reviewer. Although this approach may introduce a potential risk of selection bias, this risk was mitigated by strictly adhering to predefined eligibility criteria and applying consistent judgment using a standardized screening protocol.

2.4. Data Extraction Process

After completing the screening process, data were systematically extracted from each included study to enable structured synthesis. A standardized extraction form was developed to record key study characteristics across the following dimensions:

• Publication metadata: publication year, type (journal or conference), and publisher.
• Application domain: the smart city sector is addressed, categorized as mobility, environmental sensing, public safety, infrastructure monitoring, or waste management.
• Technical implementation: an edge hardware platform is used or simulated (e.g., microcontrollers, SBCs, simulations); a machine learning model is employed; and optimization techniques are included (e.g., quantization, pruning).
• Sensor and deployment details: types of sensors integrated (e.g., environmental, acoustic, visual), data acquisition context, and any power or features (e.g., use of low-powered radios or energy harvesting).
• Power efficiency and privacy benefits: Whether these aspects were explicitly reported, and which strategies were used to achieve or evaluate them.
• Alignment with SDGs: Each study was assessed for its contribution to relevant SDGs based on its objectives, application domain, and deployment context. Explicit mentions of SDGs were recorded directly. Where not stated, alignment was inferred from the societal or environmental impact, following the SDG thematic structure.

Each study was coded according to these categories to ensure consistency and facilitate cross-study comparison. Data were extracted and taxonomized using a structured Excel-based template, which was piloted on a subset of studies to ensure consistency and reliability. These dimensions also informed the structure of the Results section (Section 3).

3. Results

This section presents the findings of the 66 studies selected through the multi-stage screening process detailed in Section 2.3. The results are structured according to the analytical dimensions outlined in Section 2.4 and reflect current trends, focus areas, and technical implementations of TinyML within smart city applications.

3.1. Temporal Trends and Keyword Distribution

Figure 4 illustrates the yearly distribution of the 66 reviewed publications between 2019 and 2025. A steady increase in TinyML-related research is observed, with significant growth commencing in 2021 and peaking in 2024. This trend reflects the rapid adoption of TinyML technologies in smart city environments, particularly those with resource constraints, and supports the decision to focus the review period on 2019–2024.

To explore dominant thematic patterns, a keyword frequency analysis was conducted using terms extracted from the titles, abstracts, and author-defined keywords of the selected studies. These fields were programmatically parsed from EndNote RIS exports. Generic academic terms (e.g., “data,” “study,” “results”) were excluded to improve specificity. This analysis was conducted in Python (version 3.13) using standard libraries for text parsing, stop word removal, and normalization of multiword phrases. Figure 5 presents side-by-side bar charts of the top 20 keywords, showing the number of publications containing each keyword (left) and the total raw frequency across all publications (right).

As anticipated, high-frequency terms such as “TinyML,” “Edge,” “Detection,” “Monitoring,” and “Real-Time,” reflect the field’s focus on embedded inference, low-latency sensing, and system-level deployment. In addition, domain-specific keywords provide insights into the primary areas of application within smart city contexts:

• “Traffic” and “Urban” highlight the predominant use of TinyML in intelligent transportation and urban monitoring systems.
• “Sensor,” “Embedded,” “Resource,” “Power,” and “Efficient” emphasize the central importance of hardware efficiency and on-device computation.
• Terms like “System,” “Vision,” and “Smart Cities” indicate interests in system-level integration, computer vision, and broader smart infrastructure.
• Broader architectural terms such as “IoT” and “Intelligent” capture the systems-level integration characteristic of real-world deployments.

Collectively, the keyword analysis illustrates a research landscape oriented toward real-time, power-efficient intelligence to address a range of urban challenges, including traffic optimization, environmental sensing, and infrastructure resilience. These thematic trends are further explored in Section 3.3, which organizes the reviewed studies by their primary application domain.

3.2. Publication Sources

Figure 6 presents the distribution of the 66 selected studies by publishing venue following the screening process. IEEE dominates the landscape, accounting for 58% of publications, reflecting its central role in disseminating research on embedded systems, edge artificial intelligence, and practical deployment. Elsevier and MDPI follow with 20% and 12%, respectively, indicating increasing interdisciplinary engagement with TinyML from journals focused on environmental science, urban systems, and sustainability.

Springer and ACM each contribute a total of 7% of the reviewed articles, while the remaining 3% are distributed across various other publishers. The concentration of publications within IEEE-affiliated venues suggests that the field remains largely rooted in engineering and technical research. In contrast, contributions from policy, social science, or urban planning disciplines remain limited.

3.3. Application Domains of TinyML in Smart Cities

The 66 selected studies were categorized into five key thematic domains to capture the breadth of TinyML applications within smart city environments, as illustrated in Figure 7. This classification reflects each study’s core technological focus and deployment context. Accordingly, studies exhibiting domain overlaps, particularly between Public Safety and Mobility, were assigned to the most representative domain based on their primary use case. For example, study [19] leverages TinyML for real-time passenger counting using overhead thermal sensors in public transport, directly informing transit planning, and is therefore classified under Mobility. In contrast, study [20], although physically integrated into e-scooters, focuses on estimating crowd density for safety and situational awareness, and is thus categorized under Public Safety.

3.3.1. Mobility and Transportation (n = 29)

Mobility-related studies, summarized in

Table 2. Mobility and Transportation: Applications and Corresponding Reviewed Studies.

Application Domain	Studies
Intelligent Traffic Management	[22,24,25,26,27,28,29,30,31,32,33,34]
Vehicle Classification	[21,25,27,28,29,32,35,36,37,38]
Pedestrian & Passenger Safety Monitoring	[19,39,40,41,42,43]
Anomaly Detection for Vehicle Response	[23,25,32,44,45,46]
Driver Assistance & Behavior Monitoring	[26,39,40,41,42,43]
Onboard Vehicle Emission Monitoring	[47,48]

, represent the largest share of the dataset. These studies focus on applications such as intelligent traffic management, vehicle classification, pedestrian and passenger safety, vehicle-based road anomaly detection, driver assistance and behavior monitoring, and onboard vehicle emission monitoring, where emission data is used to inform driving behavior and support eco-mobility strategies. Common sensing modalities include video, acoustic, and inertial data, often processed using convolutional or recurrent neural networks on resource-constrained devices. For example, ref. [21] developed a license plate recognition system embedded in a TinyML-based parking platform. In [22], a real-time adaptive traffic light scheduling algorithm was deployed on low-power hardware. Study [23] introduced smart road reflectors with unsupervised TinyML models for pavement anomaly detection.

3.3.2. Public Safety and Security (n = 17)

This domain covers studies focused on urban safety and emergency response, as detailed in

Table 3. Public Safety and Security: Applications and Corresponding Reviewed Studies.

Application Domain	Studies
Surveillance, Intrusion & Crowd Monitoring	[20,50,51,52,53,54]
Event & Emergency Sound Detection	[55,56,57,58,59,60]
Disaster, Environmental & Public Health Threat Detection	[49,54,61,62,63,64]

. Solutions include surveillance and intrusion detection, acoustic identification of emergency and anomalous events, public crowd monitoring, and systems for early warning of disasters or public health emergencies. While some use environmental inputs (e.g., sound, temperature), their core purpose lies in risk identification and rapid alerting. Study [49] proposed a lightweight convolutional network for flood detection using embedded sensing. In [34], a low-power urban sound classifier was implemented for abnormal event detection. Aerial image-based crowd density estimation using edge devices was presented in [50].

3.3.3. Environmental Sensing and Climate Applications (n = 10)

Studies in this domain, as listed in

Table 4. Environmental Sensing and Climate: Applications and Corresponding Reviewed Studies.

Application Domain	Studies
Noise Pollution Monitoring	[66,67]
Water Quality/Leak Monitoring	[65,68,69]
Air Quality Monitoring	[67,70,71,72,73]
Smart Urban Energy Management	[74]

, address environmental monitoring tasks such as air and water quality assessment, noise pollution analysis, and climate-related sensing. These systems are often designed for low-power, long-term operation in remote or outdoor environments, with several incorporating LPWAN connectivity. Study [65] introduced a TinyML model for real-time water potability assessment, optimized for ultra-low power consumption. In [49], an embedded system combined environmental noise and air pollution sensing with efficient on-device inference.

3.3.4. Waste and Urban Cleanliness Management (n = 6)

In this domain, studies, shown in

Table 5. Waste and Urban Cleanliness: Applications and Corresponding Reviewed Studies.

Application Domain	Studies
Waste Classification & Sorting	[75,76,77,78,79]
General Waste Monitoring	[80]

, focus on urban waste detection, classification, and monitoring of cleanliness. Solutions generally involve low-cost vision sensors and lightweight neural networks capable of local inference. Study [75] developed a smart waste bin using TinyML and LoRaWAN for level detection, while [76] demonstrated an on-device classification of plastic waste to support recycling processes.

3.3.5. Infrastructure and Built Environment (n = 4)

In this domain, studies on the monitoring and maintenance of urban infrastructure, such as buildings, roads, and utilities, are summarized in

Table 6. Monitoring and maintenance of urban infrastructure such as buildings, roads, and utilities.

Application Domain	Studies
Embedded Structural Inspection	[81,83]
UAV-based Structural Inspection & Scene Classification	[82,84]

. Applications typically rely on visual, acoustic, or vibration-based data, processed with quantized or pruned neural networks on low-power hardware. Study [81] used CNNs on embedded devices to monitor canal surfaces in irrigation systems, while [82] deployed UAV-based TinyML models for structural health inspection.

Figure 8 displays a pie chart showing the distribution of the 66 reviewed studies across five primary smart city application domains. Each sector’s angle is proportional to the number of studies assigned to that domain (n = number of studies; total n = 66), with domain labels and counts displayed within each segment. Distinct colors are used to represent each domain: Mobility (n = 28), Public Safety (n = 17), Environment (n = 10), Waste (n = 6), and Infrastructure (n = 4). Studies were manually classified into a single domain based on their main application context. In cases of domain overlap, assignment was made according to the most representative use case.

3.4. Hardware Platforms

To analyze the deployment strategies of TinyML in urban systems, we classified the hardware used across the 66 reviewed studies into five distinct device classes. These categories reflect key architectural and power-related distinctions that shape deployment feasibility in smart city applications.

3.4.1. Device Classification and Architectural Summary

Hardware platforms fall into the following categories:

• Resource-Constrained Microcontrollers (RC-MCU): Ultra-low-power devices such as STM32 Nucleo (STMicroelectronics, Geneva, Switzerland), Arduino Nano BLE (Arduino AG, Somerville, MA, USA), and nRF52840 (Nordic Semiconductor, Oslo, Norway) with limited clock speeds (16–133 MHz) and RAM (2–264 KB), suited for tasks such as anomaly detection and acoustic sensing.
• Mid-Tier Edge MCUs (MT-MCU): Includes dual-core SoCs like ESP32 (Espressif Systems, Shanghai, China), Portenta H7 (Arduino AG, Somerville, MA, USA), and higher-performance STM32H7 variants (STMicroelectronics, Geneva, Switzerland). With 160–480 MHz speeds and up to 8 MB RAM, these devices exceed basic RC-MCUs in compute and integration for tasks like vision and sensor fusion.
• General-Purpose SBCs (GP-SBC): Raspberry Pi models (3B/4B) (Raspberry Pi Foundation, Cambridge, UK), with Linux OS support and higher specifications (1.0–1.5 GHz CPUs, up to 8 GB RAM) used in moderately demanding deployments.
• Accelerated Edge SBCs (AE-SBC): Devices such as Jetson Nano and Xavier (NVIDIA Corporation, Santa Clara, CA, USA), and Coral boards (Google LLC, Mountain View, CA, USA) integrate TPUs or GPUs for real-time vision tasks.

Table 7. Study Mapping by Device Class and Use Case.

Device Class	Representative Boards	Processor	Clock Speed	RAM/Flash
RC-MCU	Arduino Nano 33 series (Arduino AG, Somerville, MA, USA), Raspberry Pi Pico W (Raspberry Pi Foundation, Cambridge, UK), STM32 Nucleo (STMicroelectronics, Geneva, Switzerland), Particle Argon (Particle Industries, San Francisco, CA, USA)	ARM Cortex-M0/M4	16–133 MHz	2–264 KB/32 KB–2 MB
MT-MCU	ESP32 family (Espressif Systems, Shanghai, China), STM32H7 series (STMicroelectronics, Geneva, Switzerland), Portenta H7 (Arduino AG, Somerville, MA, USA)	Xtensa LX6, ARM Cortex-M7	160–480 MHz	512 KB–8 MB/4–32 MB
GP-SBC	Raspberry Pi 3B/3B+/4B/Zero W (Raspberry Pi Foundation, Cambridge, UK)	ARM Cortex-A53/A72	1.0–1.5 GHz	512 MB–8 GB/SD
AE-SBC	Jetson Nano (NVIDIA Corporation, Santa Clara, CA, USA), Coral Dev (Board or USB) (Google LLC, Mountain View, CA, USA)	ARM Cortex-A78 + GPU, TPU	1.5–2.6 GHz	4–8 GB/eMMC or USB

summarizes these four device classes, outlining their processor types, clock frequencies, and memory configurations.

3.4.2. Deployment Across Application Domains

Mapping these platforms to urban domains reveals differentiated usage patterns. While SBCs are more prevalent overall due to the dominance of vision-based tasks in mobility, even lightweight MCUs can effectively support applications such as acoustic event detection, traffic monitoring, or anomaly sensing when paired with efficient models. For instance, in the mobility domain, SBCs are used in traffic sign recognition, vehicle classification, and crowd detection, while MCUs are deployed for lane occupation or vibration analysis. In public safety, SBCs enable human detection and surveillance, whereas MCUs support noise event detection or thermal anomaly classification.

In the environmental domain, which is predominantly sensor-driven (e.g., air quality, temperature, and gas monitoring), MCUs are the most frequent choice, appearing in five studies. This aligns with the low-power, long-term monitoring goals in such applications. Mid-Tier MCUs bridge the gap between simple scalar sensor tasks and more complex vision or fusion workloads. They are seen in multi-sensor fusion for flood monitoring, air quality tracking, and waste bin status detection. Their presence across all domains illustrates their adaptability in moderately complex deployments where resource-constrained MCUs fall short and SBCs may be unnecessary.

Simulated platforms are found in all domains except waste, where practical field deployments are more prevalent. As summarized in

Table 8. Use of Hardware Classes Across Application Domains: multiple entries are possible.

Device Class	Environment	Infrastructure	Mobility	Safety	Waste
RC-MCU	5	1	6	3	1
MT-MCU	3	2	4	7	—
GP-SBC	—	—	8	2	4
AE-SBC	2	1	7	4	—
Simulation	1	—	4	1	—

, these mappings emphasize that power budgets, sensor requirements, and processing demands influence hardware selection across smart city applications.

3.4.3. Sensor Modalities and Renewable Power

Sensor modalities and the integration of renewable power sources are important aspects of TinyML deployments. As seen in

Table 9. Sensor and Power Features by Hardware Category.

Device Category	Vision Sensor	Environmental Sensor	Audio Sensor	Energy Harvesting
RC-MCU	4	2	4	2
MT-MCU	3	4	4	3
GP-SBC	11	3	1	2
AE-SBC	9	3	1	—

Notes: RC-MCU + Vision Sensors: [23,45,54,81]; RC-MCU + Renewables: [49,61]; MT-MCU + Vision Sensors: [20,64,80]; MT-MCU + Energy Harvesting: [46,48,58].

, vision sensors are predominantly used with SBCs and accelerated SBCs, reflecting the higher computational demands of vision-based applications. Environmental and acoustic sensors are found across all hardware categories, which highlights their broad applicability for pollution and noise monitoring. Renewable power, particularly solar energy, is integrated into six studies, with most implementations occurring in MCU-based systems.

3.4.4. Key Deployment Patterns and Takeaways

Hardware usage reflects application complexity and sensor demands. SBCs and accelerated SBCs are primarily used in vision-driven mobility and safety tasks, such as traffic sign detection or surveillance. MCUs appear in studies focused on scalar or acoustic sensing, like noise monitoring or air quality detection, particularly in energy-sensitive deployments. Mid-Tier MCUs appear in fused or moderately complex setups.

LPWAN and solar power are mostly used with MCUs. Vision sensors are almost exclusively deployed on SBCs, while environmental and acoustic sensors are seen across all classes.

3.5. Software Models

This section examines the software models deployed in TinyML-based smart city applications. The reviewed literature spans a range of machine learning approaches, from classical algorithms and compact neural networks to full-scale deep learning architectures and hardware-optimized variants. We first classify these models by architecture and training style, then explore their deployment patterns across edge hardware platforms and toolchains.

3.5.1. Software Model Classification and Architectural Overview

To analyze the diversity of machine learning strategies in edge intelligence systems, we classify the reviewed works into six distinct software categories:

• Classical Machine Learning (Classical ML): Traditional algorithms such as Random Forest, SVM, and TEDA. These models require minimal computational resources and are often used for classification, anomaly detection, and regression on microcontrollers.
• Compact Deep Learning (Compact DL): Lightweight neural networks (e.g., shallow MLPs, GRUs, small CNNs) tailored for edge deployment. These strike a balance between accuracy and memory efficiency.
• Standard Deep Learning (Standard DL): Full-scale deep learning architectures (e.g., MobileNet, ResNet, YOLO) used with minimal optimization. Typically deployed on more capable edge platforms or co-processors.
• Optimized Deep Learning (Optimized DL): Architectures designed or adapted for TinyML, often involving quantization, pruning, binarization, or custom model designs (e.g., MCUNet, FOMO, PhiNet).

For clarity, Compact DL models are designed to be lightweight from the outset, while Optimized DL models originate from larger architectures and are adapted through quantization or pruning.

Table 10. Distribution of reviewed works by software category, including representative model types and tasks.

Category	Studies (n = 66)	Common Model Types	Typical Task Types
Classical ML	12	Random Forest, SVM, TEDA, Decision Tree, k-NN	Classification, Anomaly Detection, Regression
Compact DL	18	GRU, Shallow MLP, FastGRNN, 1D-CNN, TinyCNN, DLN	Classification, Prediction, Sound/Event Detection
Standard DL	17	MobileNet, ResNet, YOLO, Inception, EfficientDet	Object Detection, Image Classification, Regression
Optimized DL	19	FOMO, MCUNet, BNN, PhiNet, MiCrowdNet	Object Detection, KWS, Segmentation, Regression

summarizes the distribution of reviewed works across these categories.

Importantly, several Compact and Optimized DL models are structurally derived from Standard DL models. For instance, FOMO, TinyAerialNet, and MiCrowdNet are explicitly based on MobileNetV2, using techniques such as compression, pruning, or NAS-based adaptation. This illustrates a continuum of model scaling: from general-purpose deep learning to ultra-lightweight designs suitable for deployment on MCU-class hardware. Three of these transformations are benchmarked in real-world deployments, as detailed in Section 3.5.6.

3.5.2. Model Deployment Patterns Across Hardware Platforms

Building on the software taxonomy, this subsection examines how different model types align with hardware tiers, reflecting the practical constraints of deployment in real-world urban applications. For this analysis, each reviewed study was manually assigned to both a model category and a hardware category using a shared spreadsheet. If a study evaluated multiple hardware targets, only the most resource-constrained platform was counted, ensuring that each study appears only once in the dataset. Figure 9 presents a heatmap linking software categories with their hardware deployment targets.

This distribution confirms a clear trend: model complexity scales with available hardware resources, where compression strategies play a pivotal role. Key observations include:

• Compact DL models dominate resource-constrained MCUs, reflecting their efficiency and low-memory footprint.
• Optimized DL models appear across both mid-tier and accelerated platforms, highlighting their versatility through quantization and pruning.
• Standard DL models are largely confined to SBCs and AI accelerators due to their high compute demands.
• Classical ML models exhibit the broadest hardware spread, with deployments on both MCUs and SBCs.

3.5.3. Learning Types and Quantization

Table 11. Overview of Supervised, Unsupervised, and Quantized Learning Models in TinyML Urban Applications.

Software Category	Supervised (n)	Unsupervised (n)	Quantized (n)	Not Quantized (n)
Classical ML	10	2	2	10
Compact DL	17	1	17	1
Standard DL	16	1	8	9
Optimized DL	19	—	18	1

Notes: Classical ML + Unsupervised: [23,47]; Classical ML + Quantized: [24,51]; Compact DL + Unsupervised: [66]; Compact DL + Not Quantized: [34]; Standard DL + Unsupervised: [29]; Standard DL + Quantized: [21,27,29,30,32,56,70,80]; Optimized DL + Not Quantized: [43].

summarizes the distribution of learning paradigms and quantization strategies across the reviewed model categories. Supervised learning dominates, with unsupervised approaches appearing only in a limited number of Classical ML and Compact DL implementations, primarily for clustering or anomaly detection.

Quantization is inconsistently applied among Standard DL models: fewer than half incorporate it, despite the high computational and memory demands of these architectures. This suggests an underutilized opportunity for improving inference efficiency on edge platforms. In contrast, Compact DL and Optimized DL models show more consistent use of quantization, reflecting their alignment with constrained memory and power budgets typical of TinyML hardware. A notable outlier is [43], which employs Sony’s IMX500 sensor and applies a proprietary hardware-level optimization technique in place of conventional quantization.

3.5.4. Framework Usage and Tooling Trends

To enhance clarity, frameworks were grouped under unified labels in

Table 12. Framework Usage Distribution Across Software Classes in TinyML Literature.

Software Class	TFLite (n)	PyTorch (n)	Scikit-Learn (n)	Custom C/C++ (n)	Other (n)
Classical ML	—	—	8	3	1
Compact DL	16	2	—	—	—
Standard DL	10	5	—	—	2
Optimized DL	14	3	—	—	2

Notes: Classical ML + Custom C/C++: [46,47,74]; Classical ML + Other: [42]; Compact DL + PyTorch: [56,82]; Standard DL + Other: [31,37]; Optimized DL + PyTorch: [44,49,57]; Optimized DL + Other: [43,73].

. The TFLite category includes both TensorFlow Lite and TensorFlow Lite Micro (TFLM), which are widely adopted across Compact and Optimized DL implementations due to their quantization support and MCU compatibility. PyTorch appears primarily in Standard and Optimized DL models, though it often requires conversion to other formats (e.g., via STM32Cube.AI or Torch2TRT) for deployment on constrained hardware. Where specified in the original studies, framework versions are noted (e.g., PyTorch 1.7.0 in [44] and PyTorch 2.1.0 in [82]); otherwise, the version is not reported. Classical ML models typically rely on scikit-learn, or are exported through tools like Emlearn, m2cgen, or micromlgen. In some cases, fully manual C/C++ implementations are used, especially for Classical ML or deterministic signal-processing pipelines.

As shown in Table 12, there is a notable convergence toward TensorFlow-based frameworks in deployment, particularly for microcontroller-class targets. Standard DL models, however, retain a broader distribution of tools, reflecting their heavier compute demands and frequent use on GPU-enabled SBCs. Proprietary or hybrid toolchains (e.g., Sony’s IMX500 SDK or NVIDIA’s TensorRT) also appear, typically in advanced vision use cases.

Table 13. Representative toolchains for deployment optimization in embedded TinyML systems.

Toolchain	Origin Framework	Deployment Target	Role	Studies (n)
Edge Impulse	TFLite Micro	RC-MCU, MT-MCU	Training & deployment	7
EloquentTinyML	TFLite Micro	RC-MCU, MT-MCU	Inference-only runtime	2
STM32Cube.AI	PyTorch/TFLite Micro	RC-MCU	Model conversion & code generation	2
Torch2TRT	PyTorch	AE-SBC	Inference optimization	1

Notes: Edge Impulse: [45,61,63,68,76,80,83]; EloquentTinyML: [62,72]; STM32Cube.AI: [50,82]; Torch2TRT: [49].

complements this with deployment-focused toolchains. These tools do not replace the training frameworks but serve as intermediaries between model design and on-device execution. For example, TFLite Micro emerges as a recurring runtime backend, integrated into toolchains like EloquentTinyML or available independently. STM32Cube.AI converts PyTorch or Keras models into firmware-embedded binaries for STM32 boards, while Torch2TRT optimizes inference for NVIDIA Jetson devices. These tools reflect a growing push toward runtime consolidation, especially around the TFLite ecosystem, which supports diverse devices and task types. Models are often converted to TensorFlow Lite Micro using streamlined workflows provided via Google Colab.

Ultimately, the selection of frameworks and toolchains strongly shapes deployment feasibility. Lightweight, open-source options such as TFLite lower the barrier to TinyML adoption on MCUs. The diversity of toolchains observed also underscores an ongoing effort to balance model fidelity with hardware limitations.

3.5.5. Dataset Usage

The origin and composition of training datasets directly influence the validity, generalizability, and reproducibility of TinyML models, especially when deployed in highly constrained or domain-specific environments. Understanding dataset sourcing patterns provides insight into current research practices and limitations.

Table 14. Distribution of Dataset Sources Across the Reviewed TinyML Studies (n = 66).

Category	Studies (n = 66)	Percentage (%)	Criteria
Custom	24	36.4%	Data collected by the authors via sensors or edge devices
Public	27	40.9%	Open and Publicly available datasets (e.g., Kaggle, UrbanSound8K, SDNET2018)
Hybrid	10	15.2%	Mix of public and author-collected data
Simulated	5	7.6%	Artificially generated via simulations

presents the distribution of dataset sourcing strategies across the 66 studies reviewed. The most common approach involved the use of public datasets (40.9%), including well-established resources such as UrbanSound8K [39,56,60], SDNET2018 [82], and a range of Kaggle-hosted datasets [40,61,65,76]. Additional notable sources include ThermoPresence [50], the AI City Challenge [28,77], and Google Speech Commands v2 [52]. These public datasets enable reproducibility and comparative benchmarking across implementations.

In contrast, 36.4% of studies used custom datasets collected through edge devices, embedded sensors, or experimental testbeds. These were often domain-specific and tailored to tasks such as canal surface inspection [81], CO₂ emission estimation [47,48], air quality prediction [73], or acoustic water leak detection [69]. Hybrid datasets were used in 15.2% of studies, where authors extended public datasets with contextual data from field deployments—e.g., combining Kaggle images with locally captured drone footage [80], or augmenting UCF-Crime videos with in-house test data [70]. Simulated datasets (7.6%) appeared in a small number of studies, primarily generated from traffic simulators [34,52] or procedurally created image datasets [64].

3.5.6. Empirical Benchmarks on TinyML Hardware

While the previous sections outlined the TinyML model types and deployment strategies, a subset of studies in the corpus provides a more applied perspective through empirical benchmarking. These works evaluate the on-device performance of adapted models, incorporating techniques such as quantization, pruning, and architectural simplification to assess their feasibility on constrained hardware.

Table 15. Benchmark Study Comparison: Model and Hardware Adaptation.

Study	Original Model	Adapted Model	Original Device	Adapted Device (s)	Inference (ms)
[83]	YOLOv5	FOMO	Jetson Nano	Arduino BLE 33, Portenta H7	21–88
[50]	U-Net	Compressed U-Net	Desktop	ESP32, STM32 Nucleo, BLE 33	38–52
[80]	Faster R-CNN	Quantized F-RCNN	Jetson Nano	Portenta H7, ESP-EYE, Nicla Vision	44–1043

summarizes three such studies, each addressing a distinct urban computer vision task: pothole detection [83], thermal-based people counting [50], and aerial waste classification [80]. These studies begin with high-capacity models—YOLOv5, U-Net, and Faster R-CNN—and apply adaptation strategies including INT8 quantization, network compression, and bounding box refinement to enable deployment on edge platforms. The resulting models are evaluated across devices such as ESP32, STM32 Nucleo, Arduino BLE 33, Portenta H7, and ESP-EYE, with measured inference latencies ranging from 21 ms to over 1 s. While some benchmarks compare performance across both SBCs and MCUs, others focus exclusively on ultra-constrained hardware. Collectively, these results underscore the potential for TinyML systems to move from theoretical design to practical deployment in diverse urban contexts.

3.6. Power Efficiency in TinyML Urban Deployments

Power efficiency is a foundational concern for deploying TinyML in urban environments. Smart city devices are often installed in locations with limited access to continuous power—such as streetlights, sidewalks, or autonomous vehicles—requiring systems to operate on batteries or renewable sources. Sustained operation depends on optimizing every aspect of power consumption, from model inference to wireless communication.

Among the 66 reviewed studies, 65 explicitly mention power constraints, and 61 treat them as critical to deployment success. For instance, ref. [58] describes a solar-powered system in Brooklyn with a complete power budget under 100 mW. Similarly, ref. [74] presents a pollution monitoring device that operates autonomously on harvested power sources.

Common techniques used to reduce power consumption include model quantization, binary networks, duty-cycled sensing, and aggressive pruning. Study [77] developed a low-power sound classifier tailored for MCUs, while [33] achieved sub-100 ms inference on an Arduino Nano BLE by optimizing model architecture for real-time inference.

To provide a balanced overview of power and performance trade-offs across widely used TinyML hardware platforms,

Table 16. Power, Performance, and Battery Life Characteristics of Edge AI Device Classes.

Device Class	Model Size	Inference Time	Power (Active)	Energy per Inference	Approximate Battery Life
RC-MCU	0.2–0.5 MB	0.3–1.0 s	20–100 mW	5–30 mJ	Years
Mid-Tier MCU	0.3–1 MB	0.05–0.9 s	0.5–1.5 W	30–900 mJ	Weeks–months
GP-SBC	0.3–1 MB+	0.01–0.1 s	4–7 W	100–750 mJ	Hours–days (battery); external power required
AE-SBC	10–45 MB+	0.005–0.04 s	10–18 W	50–700 mJ	External power required

presents typical ranges for model size, inference time, power consumption, energy per inference, and battery life. Most values are based on the systematic, cross-platform benchmarking by [50], which offers comparable measurements across several microcontroller and single-board computer platforms using a standardized people-counting model. These results are further corroborated by [65,81,82,84] for RC-MCUs and Mid-Tier MCUs, and by [32,41] for GP-SBCs. For AE-SBCs, direct measurements are not available from [50], and therefore representative values are taken from [26,49].

It should be noted that actual results depend on the specific model architecture, application scenario, and deployment configuration. Nevertheless, these ranges offer a practical reference for expected performance. Resource-constrained MCUs are often capable of multi-year operation on standard batteries under low-frequency workloads, while Mid-Tier MCUs may achieve weeks to months of battery life depending on their duty cycle. In contrast, SBCs offer lower inference latency but generally cannot operate on battery power alone.

These approaches underscore the importance of system-level power planning—not just software optimization but also hardware selection, RF protocol choice, and energy harvesting methods.

3.7. Privacy in TinyML Deployments

Privacy is a key consideration for TinyML systems, particularly in public urban spaces where edge devices often capture sensitive data such as images, sounds, or behavioral patterns. While TinyML inherently enhances privacy through on-device inference, this advantage is rarely prioritized as a core design principle. Privacy was reported in 30 studies and identified as a core system requirement in only 13, as shown in

Table 17. Power Efficiency and Privacy Considerations in Reviewed Studies.

Consideration	Mentioned (n = 66)	Key (n = 66)	Common Techniques	Urban Relevance
Power Efficiency	65	61	Quantized/Binarized models, solar power, pruning	Supports long-term autonomy in infrastructure-limited areas such as traffic systems and sensors
Privacy Considerations	29	13	Federated learning, on-device inference, thermal imaging	Enhances trust in densely populated areas, critical in audio/video surveillance

. In the table, the “Mentioned” column denotes whether privacy was acknowledged in each study, while the “Key” column indicates whether it was regarded as a central design requirement. This relatively low number partly reflects the fact that many TinyML applications, such as environmental monitoring and structural diagnostics, do not involve personally sensitive data and therefore do not require explicit privacy measures.

A subset of studies introduced explicit privacy-preserving techniques. For instance, ref. [73] applied federated learning to keep data localized on edge devices. Study [19] used thermal imaging to avoid collecting identifiable features, and [58] emphasized fully local inference without cloud connectivity. These approaches align with evolving regulatory frameworks and public expectations around surveillance and personal data use.

However, a substantial portion of implementations, particularly those involving audio or video sensing, do not explicitly address privacy considerations. This highlights a significant gap in how the privacy benefits of TinyML are communicated. Although these systems technically avoid data sharing, this aspect is rarely emphasized as a deliberate design choice. Consequently, the potential of TinyML to enhance privacy, especially in sensitive domains, remains underreported in the current literature.

3.8. Representative Real-World City Deployments

To illustrate how TinyML is applied under real-world conditions, we highlight two studies that involve actual deployments using microcontroller-class devices and quantized models, aligning closely with the operational constraints typical of TinyML. These examples, presented in

Table 18. Representative Urban Deployments Using Resource-Constrained Edge Devices.

Study	City/Country	Urban Scale	Urban Context	SLR Domain
[66]	Helsinki, Finland	Capital (~650K)	Smart city project (mySMARTLife) with a focus on privacy	Public Safety
[21]	Tunisian Cities	Mid-sized cities (~600K)	Informal parking with constrained public enforcement capacities	Mobility
[80]	Jaipur, India	Large city (~3M)	Unregulated waste zones with insufficient ground surveillance	Waste Management
[63]	Tandil, Argentina	Small city (~140K)	Areas with limited infrastructure and increased risk of mosquito-borne diseases	Public Safety
[31]	Almaty, Kazakhstan	Megacity (~2M)	Foothill congestion patterns and traffic light inefficiency	Mobility
[19]	Athens, Ohio, USA	Small city (~25K)	Low-infrastructure rural/small-city transit with limited digital monitoring	Mobility
[58]	Brooklyn, USA	Megacity (>8M)	High noise pollution with strong privacy norms	Public Safety
[33]	Siena, Italy	Small city (~50K)	Historic narrow roads with physical limits on sensor deployments	Mobility

, reflect distinct urban scales and deployment requirements.

In Siena, Italy, a small historic city with approximately 50,000 residents, a quantized convolutional neural network was implemented on an Arduino Nano 33 BLE to classify traffic based on roundabout noise [59]. The system was trained on real-world audio data and deployed on-site, leveraging low-power hardware for non-intrusive monitoring in areas with limited infrastructure.

Brooklyn in New York City, a densely populated urban area with over 8 million inhabitants, was selected for deployment of the SONYC-L3 acoustic monitoring network [58]. This system utilized STM32 microcontrollers with LoRa communication and solar power to classify street-level noise locally. The design prioritized decentralized processing and energy autonomy in line with the operational requirements of large scale and long duration city deployments. Although these two case studies addressed different urban needs, both relied on audio-based classification with MCU-class devices, demonstrating the adaptability of sound sensing for lightweight and edge native monitoring.

The broader review considers studies that use advanced edge platforms, such as Jetson Nano for real time environmental monitoring in Seoul [67]. However, this section is limited to implementations based on microcontroller class hardware and lightweight models. This distinction supports isolating cases where TinyML’s core characteristics, including low power consumption, limited computational capacity, and constrained memory, are central to the deployment design.

3.9. Alignment of Reviewed Studies with SDG Targets

This section examines how the reviewed TinyML studies contribute—explicitly or implicitly—to the United Nations Sustainable Development Goals (SDGs), a global policy framework guiding research impact, funding, and deployment priorities. As outlined in Section 2.4, SDG alignment was determined based on either explicitly stated objectives or inferred from each study’s thematic focus and deployment context. Several reviewed studies align with multiple SDGs, with the number of studies corresponding to each SDG presented in

Table 19. Alignment of Reviewed Studies with SDGs Based on Thematic Relevance.

SDG Goal	Studies (n = 66)	Description
SDG 11—Sustainable Cities and Communities	66	Urban mobility, infrastructure monitoring, public service automation
SDG 13—Climate Action	27	Low-emission systems, solar-powered infrastructure, and environmental sensing
SDG 3—Good Health and Well-being	20	Air quality, emergency detection, and wearable health monitoring
SDG 12—Responsible Consumption and Production	6	Waste segregation, smart bins, resource-aware recycling systems
SDG 6—Clean Water and Sanitation	3	Real-time water leak detection and monitoring
Explicit SDG Reference	1	Traffic Monitoring [25]

.

While many studies demonstrate implicit thematic contributions to these goals, only six make explicit reference to SDG terminology or frameworks. The rest contribute through aligned outcomes such as emission reduction, sustainable infrastructure, or health-oriented monitoring. Explicit SDG citation appeared in the case of Study [25], which directly references SDG 11 (Sustainable Cities and Communities) in the context of traffic monitoring and urban sustainability.

Thematically, SDG 11 (Sustainable Cities) aligns with all 66 reviewed studies, covering applications such as smart traffic lights, environmental monitoring, and infrastructure automation. SDG 13 (Climate Action) is addressed in studies that deploy solar-powered, low-emission systems [71,74]. Health-related solutions, including air quality trackers and noise pollution monitors, correspond to SDG 3 (Good Health and Well-Being) and are represented in 21 studies.

Relatively few studies address SDG 12 (Responsible Consumption and Production), with only six focusing on waste management. SDG 6 (Clean Water and Sanitation) appears in three studies: one focused on leak detection in municipal systems [69], another on TinyML based water potability classification [65], and a third on water leakage detection in smart buildings [68].

In summary, TinyML deployments are increasingly adopted across smart city domains, especially in Mobility and Public Safety. Overall, these systems emphasize energy efficiency, local inference, and lightweight models on edge hardware. Key trends and continuing challenges are discussed further in Section 4.

4. Discussion

The systematic review conducted reveals a growing body of research on TinyML applications across diverse smart city domains, including urban mobility, environmental monitoring, public safety, infrastructure health, and waste management. To structure the discussion, a set of critical questions was formulated and aligned with the extraction dimensions used during the review process. Each question is addressed below through an evidence-based synthesis of findings, with reflections on current gaps, methodological trends, and future research opportunities.

4.1. What Target Boards Are Used for TinyML Deployments?

TinyML deployments in smart cities are most commonly built on microcontroller-class platforms such as STM32, ESP32, and Arduino Nano. These devices are well aligned with the low-power, always-on requirements of typical urban tasks, including air quality monitoring, acoustic sensing, and waste classification. More capable microcontrollers, like the STM32H7 series or Portenta boards, appear in tasks involving light image processing or multi-sensor fusion.

Single-board computers (SBCs), such as the Raspberry Pi, are also used in several studies. These platforms support higher computational throughput and flexible prototyping, especially in vision-based applications. However, not all SBC-based deployments are justified by the task’s computational needs. In multiple cases, tasks with static inputs, low-frequency inference, or limited model complexity were deployed on hardware exceeding their requirements.

Table 20. Overprovisioned Edge Deployments in Smart City Contexts.

Study	Hardware	Context	Justification for Overprovisioning
[21]	Raspberry Pi	Smart parking	Low-frequency image input with low processing needs.
[77]	Raspberry Pi+	Waste monitoring	Static classification and sensing with no real-time demands.
[78]	Raspberry Pi 4	Waste sorting	Classification triggered by object presence, low inference.
[79]	Raspberry Pi 3B+	Waste sorting	Controlled visual input with low requirements.
[59]	Raspberry Pi 3B+	Urban sound analysis	Offline audio classification, not real-time.
[34]	Raspberry Pi 4B	Traffic signal timing prediction	Time-series forecasting with low-frequency updates.

highlights representative cases where task type, urban context, and processing demands suggest that microcontroller-class devices could provide comparable functionality at lower power, cost, and system complexity. Addressing this mismatch is key to enabling scalable, energy-efficient TinyML deployment in real-world urban systems.

There are several practical reasons that may explain this trend. First, platforms such as the Raspberry Pi offer well-established software environments and user-friendly tools, making them attractive for prototyping. They also support a wide range of libraries and pretrained models, most of which are designed for Linux based systems and are therefore easier to integrate. As a result, high-power hardware appears to be used out of convenience, even though similar results might be achievable on low-power microcontrollers with additional optimization.

4.2. What RF Communication Technologies Are Employed?

Wi-Fi and Bluetooth Low Energy (BLE) were the most used wireless technologies in the reviewed studies. While they are easy to integrate and support high data rates, they are not always the best fit for TinyML systems that need to operate for long periods on limited power. Wi-Fi, in particular, consumes significant power during transmission and idle time, which limits its use in battery-powered or solar-powered deployments. BLE is more energy-efficient but has a short communication range and is mainly suited for local, low-bandwidth tasks.

In contrast, LoRa and other low-power wide-area network (LPWAN) technologies are better aligned with TinyML goals. LoRa enables very low-power communication over long distances, making it ideal for outdoor or remote deployments, such as environmental sensing, urban noise monitoring, or leak detection. Studies using LoRa, listed in

Table 21. Studies Employing LoRa Technology on Resource-Constrained Microcontrollers.

Study	Target Board	Context	LPWAN Relevance
[35]	Custom Board (Cortex-M4)	Vehicle detection for traffic planning	Power-efficient transmission over long distances
[72]	RP2040	Air quality monitoring	Low-power data upload from distributed nodes
[63]	STM32H7 (OpenMV)	Urban Mosquito monitoring	Remote traps where Wi-Fi is unavailable
[69]	Arduino Due	Urban water leak detection	Long-range communication from buried nodes
[58]	STM32H7	Urban noise classification	Low-bandwidth mesh with low power

, often achieved multi-month or even solar-powered autonomous operation, a major benefit in smart city contexts where power access is limited.

Several factors may explain the limited adoption of LPWAN technologies. First, many projects remain at the prototype or simulation stage, where short-range protocols such as Wi-Fi or BLE are easier to implement and are already integrated into commonly used development boards. As a result, few studies have extended their scope to evaluate the usability or integration challenges associated with LPWAN solutions. In addition, the adoption of LPWAN is further constrained by region-specific regulations, limited data rates, and complex setup procedures, which may discourage broader implementation.

However, LPWAN technologies were used in only a small subset of studies. This suggests that many deployments may be overly reliant on familiar, high-power communication options without fully considering power budgets. There remains a clear opportunity to better align communication methods with application requirements and power constraints.

Future research should focus on evaluating the power cost of wireless communication alongside model inference. Reducing transmission frequency or adopting event-triggered messages over LPWANs can significantly save energy and extend device lifetimes. Emerging LPWANs such as MIOTY, which offers high interference resilience and ultra-low power consumption, show strong potential for such energy-optimized deployments [85]. In addition to protocol-level strategies, advances in ultra-low-power radio hardware, including nanowatt wake-up receivers and data recovery circuits, are further decreasing the energy required for always-on connectivity. Some designs now operate at just 4.78 nW in rest state, as demonstrated by [86]. Designing TinyML systems with communication-aware power optimization will be essential for scaling smart city deployments.

4.3. How Is Privacy Reported?

TinyML enables local inference on low-power devices, which inherently reduces the need to transmit raw data, offering a structural advantage for privacy. Yet, our review finds that privacy is often underexplored as an inherent advantage even in contexts where it is relevant. Of the 66 studies analyzed, 13 identify privacy as integral to application design, and the documentation of privacy benefits remains inconsistent.

A small subset of studies presents concrete privacy-aware system design, particularly in urban environments where vision and audio modalities pose higher risks. For instance, ref. [19] deploys thermal imaging to detect transit users without capturing biometric details. Ref. [50] performs people counting entirely on-device, preventing storage or transfer of surveillance footage. Ref. [66] demonstrates real-time sound anomaly detection without cloud reliance, thereby avoiding the need to retain or process speech data. Study [54] similarly employs edge-only acoustic event processing in health and safety domains. While privacy is not their stated goal, the exclusion of raw audio capture minimizes the risks of identifying individuals, which is particularly important in sensitive environments like care facilities or secure areas. These studies are detailed in

Table 22. TinyML Studies Addressing Privacy Considerations in Urban Deployments.

Study	Context	Urban Relevance
[66]	Noise anomaly detection on streets	Enables monitoring without recording conversations or identities
[50]	People counting in crowded spaces	Supports crowd analytics without capturing biometrics or facial features
[54]	Safety surveillance in semi-public areas	Enables real-time hazard detection without collecting video, identity, or biometric data
[20]	Crowd estimation in open urban areas	Provides real-time density estimates without surveillance imagery
[19]	Passenger detection in public transport	Protects rider anonymity while informing equitable transit planning
[58]	Street noise classification	Complies with noise ordinances without collecting raw audio or speech

.

Despite these examples, privacy benefits remain inconsistently addressed and underreported in relevant smart city applications. Most studies do not reference privacy risks, user consent, or relevant regulatory considerations, even when using vision or audio modalities. This gap may reflect the prototyping nature of the work, where efforts are focused on proving functionality rather than engaging with deployment-level concerns. However, this omission may limit the societal acceptance or policy alignment of future real-world systems.

To support more responsible deployment, future research should recognize the inherited privacy advantages of TinyML. This may include selecting less intrusive sensors, such as thermal or ambient options, minimizing raw data retention, and documenting privacy-preserving methods more clearly. Although advanced techniques like federated learning remain rare in this domain, exploring their feasibility on resource-constrained environments could be an important direction for further work.

4.4. How Is Power Efficiency Reported?

Power efficiency is a key factor in TinyML systems, especially in cities where devices may be placed in busy streets, buildings, or vehicles. While 65 out of 66 studies mention power efficiency, most focus only on optimizing the model, not the full system. A small subset combines this with renewable energy or power strategies that support long-term use.

Urban settings present specific challenges. Devices are often installed in places where running power lines are hard and battery replacement is expensive or disruptive. In these cases, using renewable energy like solar or connecting to existing power sources can make a big difference in keeping systems running with little attention.

A limited number of studies, such as [61,72], use solar power to achieve full autonomy. Ref. [61] runs a mosquito monitoring system in off-grid homes, and [72] supports CO₂ sensing in buildings with optional solar charging. Other systems are powered through existing infrastructure. Study [48] uses the vehicle’s OBD port, a setup that doesn’t use renewable energy, but it avoids the need for separate power systems.

Table 23. Energy Harvesting TinyML Systems in Urban Contexts.

Study	Context	Power Strategy	Urban Relevance
[61]	Mosquito detection and repellent control	Solar-powered MCU with duty cycling	Health interventions in underserved households
[48]	CO2 estimation in connected vehicles	OBD-II power integration	Mobility analytics without a separate power source
[72]	CO2 monitoring in public buildings	Solar charging option for battery backup	Air quality sensing in schools, offices

lists the studies that include renewable or infrastructure power strategies. These examples show different ways TinyML systems can run in urban areas with less need for maintenance or manual support. More work is needed to combine low-power models with long-term, self-sustaining operation.

4.5. Which Learning Strategies Dominate TinyML Use in Smart City Deployments?

Supervised learning dominates among TinyML deployments in smart city applications. This is due to the relative availability of labeled datasets and the compatibility of supervised models with embedded deployment pipelines such as Edge Impulse, TFLite Micro, and STM32Cube.AI. Lightweight CNNs, MLPs, and occasionally classical models (e.g., decision trees, SVMs) are widely used for tasks like object classification, condition monitoring, and event detection.

By contrast, unsupervised methods remain rare. The lack of suitable frameworks for MCUs, coupled with the difficulty of validating results without labels, makes unsupervised learning less practical for current TinyML use cases. Similarly, federated learning, while highly relevant for privacy-preserving urban sensing is rarely implemented on microcontroller-class hardware. One notable example [73] applies a federated learning framework to Jetson Nano devices for air quality prediction. Although outside TinyML constraints, it demonstrates a valuable direction for distributed edge learning in smart cities.

4.6. How Are Complex Models Adapted for TinyML in Smart City Applications?

TinyML research increasingly focuses on adapting complex models for real-time inference on constrained hardware. Rather than developing lightweight models from scratch, many studies restructure or compress existing architectures originally designed for mobile or cloud platforms.

As summarized in

Table 24. Adapted Machine Learning Models for TinyML Deployment in Smart Cities.

Study	Original Model	TinyML Adaptation	Smart City Application
[44]	Standard CNN	CBin-NN	Detection of road anomalies using embedded camera systems
[82]	MobileNetV2	Quantized MobileNetV2	Speed breaker detection with low-resolution road images
[83]	YOLOv8	FOMO	Pothole detection through camera-based monitoring
[50]	U-Net	Light U-Net	People counting via low-resolution thermal sensors
[57]	MCUNet	PhiNet	Voice command recognition for public infrastructure systems

and benchmarked in Section 3.5.6, several studies show the feasibility of this approach. In [83], YOLOv5 is transformed into FOMO, a grid-based detection model that removes bounding boxes, achieving inference on microcontrollers like the BLE 33. In [50], U-Net is compressed for thermal imagery, supporting people counting on ESP32 and STM32 boards. Study [80] quantizes Faster R-CNN with Soft-NMS for real-time aerial waste detection on Portenta H7 and vision MCUs.

Other studies employ architectural simplification for lightweight tasks. For instance, ref. [44] compresses a CNN into a 2.3 KB binary neural network for road anomaly detection, and [82] adapts MobileNetV2 via transfer learning for grayscale road imagery. In [57], PhiNet adpats an RNN architecture to enable low-latency voice recognition in public spaces.

These adaptations reflect a shift from general-purpose compression to task-specific and edge-native model design. Object detection has emerged as a key application area, with models such as FOMO and quantized Faster R-CNN supporting use cases in mobility, sanitation, and safety. Importantly, benchmark data confirm their viability across a range of device, from SBCs to MCUs.

Sensor modality also drives adaptation. As shown in Section 3.4.3, vision sensors are typically paired with SBCs due to their computational load, while thermal and audio sensors allow deployment on more constrained platforms. This highlights the importance of co-design, where sensor characteristics inform both model architecture and hardware selection.

Ultimately, adapting models for TinyML is not just a compression task; it involves aligning sensing, hardware constraints, and application goals. Future work should focus on sensor-aware model adaptation and architectures that dynamically adjust to urban context and input complexity. As noted by [6] effective TinyML design must prioritize activation-aware optimization and sensor-aware architecture co-design, especially in safety-critical and latency-sensitive tasks.

4.7. Are TinyML Models Trained on Public or Custom Datasets?

A recurring challenge identified in Section 3.5.5 is the overreliance on public datasets, which, while essential for benchmarking, often lack the complexity and unpredictability of real-world urban data. Models trained on clean, structured datasets like UrbanSound8K or COCO-derived resources may face domain shift when deployed on noisy street corners, dynamic traffic zones, or constrained IoT platforms. This divergence in data characteristics can lead to degraded model performance, particularly in safety-critical applications like traffic detection or pollution monitoring.

Additionally, the reproducibility of findings is compromised when datasets are not disclosed or are insufficiently described. Several studies fell into an “uncategorized” group due to conceptual framing or the use of pretrained models without clear dataset documentation. This lack of transparency limits the ability of researchers to replicate or validate performance claims, posing a barrier to the scientific rigor in TinyML. Addressing this will require the community to prioritize dataset provenance reporting, shared edge-scale benchmarks, and standardized metadata for embedded data collection.

4.8. Summary of Key Gaps and Future Research Directions

This review highlights several persistent gaps that limit the scalability, sustainability, and social acceptance of current TinyML deployments in smart cities. Hardware provisioning is often suboptimal, with Single-Board Computers (SBCs) used in tasks where microcontroller-class devices would be more efficient, resulting in avoidable power overhead (Section 3.4). While power efficiency is commonly reported, certain studies include empirical power measurements or leverage low-power wide-area network (LPWAN) technologies such as LoRa, which are more suitable for autonomous, battery-powered urban deployments (Section 3.6 and Section 4.2).

Privacy is a critical concern in smart city applications, where data is often collected from public spaces through vision or audio sensors. TinyML enables local, on-device inference that naturally enhances privacy by minimizing raw data transmission. In relevant domains, privacy should be treated as a core design requirement, particularly in use cases involving human monitoring, not merely as a byproduct of edge processing.

In addition, dataset transparency and reproducibility remain inconsistent. Many studies use private or simulated data without providing access or clear documentation, limiting validation and comparability across implementations (Section 3.5.5). Much of the current evidence is derived from controlled or laboratory-based experiments. As machine learning applications in smart cities continue to evolve, the availability of real-world datasets will be increasingly important.

Finally, there is a notable disconnect between TinyML deployments and global sustainability frameworks. Although nearly all studies support sustainable urban goals in practice, only one explicitly references the United Nations Sustainable Development Goals (SDGs) (Section 3.8). Stronger alignment with SDG 11 (Sustainable Cities), SDG 13 (Climate Action), and SDG 3 (Good Health and Well-being) would increase policy relevance and long-term societal impact. To address these gaps, future research should prioritize: (i) optimizing hardware and model co-design for resource efficiency; (ii) integration of low-power communication and energy harvesting sources; (iii) system design that leverages the inherent privacy benefits of TinyML in relevant applications; (iv) open and reproducible dataset practices; and (v) explicit SDG alignment in goals, evaluation, and reporting.

5. Conclusions

This systematic review confirms that TinyML is emerging as a powerful enabler for sustainable and decentralized smart city systems. Applications in mobility, public safety, and environmental monitoring dominate the field, supported by increasingly power-efficient and hardware-optimized models. However, the lack of attention to overprovisioning in hardware deployment, underrepresentation of power and privacy considerations, and limited engagement with global policy frameworks such as the SDGs remain critical gaps.

This review covered 66 studies: 29 focused on mobility and transportation, 17 on public safety, 10 on environmental sensing, 6 on waste management, and 4 on infrastructure monitoring. TinyML was implemented on constrained microcontrollers in 32 studies, while 36 studies adopted optimized models for resource-limited settings. Energy harvesting, mainly through solar power, was incorporated in 6 studies, and low-power communication networks were used in 5. Regarding data practices, 27 studies used public datasets, 24 relied on custom data, and the remainder used hybrid or simulated sources. Only one study explicitly referenced the SDGs, and privacy considerations guided the design in 13 cases.

These numbers highlight both the growing adoption of TinyML technologies and the ongoing need for more deployment-ready design strategies in future urban systems. To bridge research with responsible implementation, future work should prioritize the integration of energy harvesting solutions and power-aware communication architectures. In addition, researchers should advance privacy-preserving model design where applicable and promote greater standardization of dataset disclosure. TinyML is well-positioned to power the next generation of connected and inclusive cities, but only if its development aligns with both technological and ethical imperatives.

Based on the findings of this review, we propose the following directions for future research and implementation of TinyML in smart urban systems. These recommendations aim to guide the field toward more responsible, efficient, and impactful applications in real-world urban contexts:

• Avoid overprovisioned hardware by leveraging MCU-based platforms and optimizing models for low-power operation whenever possible.
• Integrate energy-harvesting solutions to enable sustained operation in resource-constrained environments.
• Expand the use of low-power communication technologies to support long-term, autonomous deployments.
• Make privacy a key consideration in application design for relevant domains, particularly where vision and audio data are involved.
• Improve transparency in dataset practices by providing clearer documentation and increasing access to real-world datasets.
• Encourage future research to explicitly reference relevant SDGs in project objectives and discuss their societal and environmental implications.