Pith. sign in

REVIEW 3 major objections 5 minor 39 references

EdgeFaaS: A Function-based Framework for Edge Computing

T0 review · 3 major / 5 minor · reviewed 2026-08-02 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read EdgeFaaS claims that heterogeneous IoT, edge, and cloud resources can be unified behind a function-as-a-service abstraction, letting users write functions once and run them anywhere with sufficient resources.

desk verdict Substantial, well-built EdgeFaaS systems paper whose headline tradeoff claims — especially the video optimal-placement result — rest on single runs and a metric that omits its own orchestration overhead; deserves a serious referee but needs major evaluation revision. read the letter →

arxiv 2607.14489 v1 pith:KMI2K4WD submitted 2026-07-16 cs.DC cs.AI

Neha Vadnere , Yu-Ting Wang , Yitao Chen , Sreehari Sadesh , Ming Zhao This is my paper · ORCID
classification cs.DCcs.AI
keywords edgecomputingfunction-as-a-serviceresourcevirtualizationworkfloworchestrationIoTvideoanalyticsfederatedlearningaudioclassification
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

EdgeFaaS is a framework for edge computing that tries to solve the problem of extreme resource heterogeneity and distribution by virtualizing computing and storage resources into a single, consistent function-based pool. The paper's central claim is that with function virtualization, storage virtualization, and workflow orchestration, users can deploy and run the same functions across IoT devices, edge servers, and the cloud without knowing where data or code physically lives. It backs this claim with three representative workflows—video analytics, hierarchical federated learning, and audio classification—run on a real testbed of over 100 geographically distributed devices. If correct, this would give edge applications a practical way to explore deployment tradeoffs such as computation versus communication cost and accuracy versus training speed, simply by adjusting workflow configurations.

What carries the argument

The central mechanism is resource virtualization, specifically function virtualization and storage virtualization. Function virtualization assigns each user function a unique virtual URL and separates deployment into a registration step (virtual deployment) and an actual placement step (physical deployment), allowing the same function description to be mapped to any underlying FaaS endpoint—cloud services, OpenFaaS servers, faasd on Raspberry Pi, or OTA-flashed code on microcontrollers. Storage virtualization similarly exposes virtual buckets with a consistent interface while enforcing data locality and user-trusted placement. Workflow management then parses a Serverless Workflow specificati

What would settle it

Re-run the video analytics, federated learning, and audio classification experiments multiple times (e.g., 10+) on the same testbed and check whether Configuration 3 still consistently yields the lowest end-to-end video latency, whether federated learning accuracy strictly decreases with smaller cluster sizes, and whether the orchestration latency remains flat under 100 requests per minute; if the orderings change across runs, the specific quantitative claims would not be robust.

Watch

Extended reading notes

Core claim

The paper introduces EdgeFaaS, a function-based edge computing framework that consolidates highly diverse and distributed resources—from cloud servers and edge clusters down to microcontrollers—into a unified FaaS resource pool. It provides consistent virtual interfaces for deploying and invoking functions (via URLs of the form workflowName/functionName) and for storing and accessing data (via virtual buckets), hiding the physical location and interface of the underlying resources. EdgeFaaS also extends standard serverless workflow specifications to support pipelined, aggregated, and ML-based edge workflows, and uses a two-level orchestrator (global and edge) to manage function placement, de

Load-bearing premise

The experimental conclusions rest on the assumption that the testbed's measured timings and accuracy numbers are stable and representative, since each reported value comes from a single run without error bars or statistical repetitions.

Editorial extensions

If this is right

  • If EdgeFaaS works as claimed, developers can write a function once and deploy it across IoT, edge, and cloud tiers without per-platform code or configuration changes.
  • Users can experimentally tune tradeoffs for their own workloads—e.g., placing compute-heavy stages in the cloud and communication-heavy stages on the edge to minimize end-to-end latency.
  • The framework can serve as a substrate for more sophisticated function scheduling and data caching algorithms, since placement decisions are made at a virtual layer with consistent interfaces.
  • The demonstrated low orchestration overhead across a 10x increase in invocation rate suggests the architecture can scale to many concurrent workflows without a central bottleneck.
  • The hierarchical federated learning results indicate that adjusting cluster size lets users trade training speed against model accuracy, which is directly actionable for privacy-aware distributed training.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because the workload evaluations report single-run timings without error bars, the specific quantitative orderings (e.g., Configuration 3 giving the lowest video latency) might be sensitive to network jitter or device variability; the real contribution may be the framework's ability to make such tradeoff exploration convenient, not the exact numbers in one testbed run.
  • The same virtual-URL abstraction could generalize beyond the three demonstrated workflows to other streaming IoT pipelines such as anomaly detection, object tracking, or multi-camera fusion, where the compute-communication tradeoff follows the same shape.
  • A likely extension is to integrate intelligent placement policies—the paper notes only basic placement heuristics are used—so that EdgeFaaS could automatically choose function placement based on measured network conditions rather than requiring the user to manually explore configurations.
  • The storage virtualization with trust constraints points toward a privacy-preserving edge data platform, but the paper only demonstrates a simple trusted-endpoint flag; an inference is that richer policy languages (e.g., data residency, access revocation) could be layered on the same abstraction.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. EdgeFaaS is a function-based framework for edge computing that virtualizes compute and storage resources across IoT, edge, and cloud tiers, providing unified REST interfaces for deploying and invoking functions and accessing data. Workflows are specified using an extension of the CNCF Serverless Workflow Specification, parsed into a DAG, and executed by a two-level (global/edge) orchestration system. The paper presents three use cases—video analytics, hierarchical federated learning, and audio classification—implemented on a real testbed of over 100 geographically distributed devices, and reports experiments showing tradeoffs such as compute vs. communication time, training speed vs. accuracy, and fine-tuning frequency vs. accuracy. It separately measures orchestration overhead under a synthetic warm workflow.

Significance. The paper makes a credible systems contribution: a unified FaaS abstraction across highly heterogeneous IoT/edge/cloud resources, with standards-based workflow support, real testbed deployment, and three distinct application workflows. If the quantitative claims are validated, the framework would be a useful platform for edge computing research and practice. The paper's strengths are the breadth of the demonstration, the concrete implementation details, and the open-source claim. However, the current evaluation lacks external baselines and error bars, and its central 'end-to-end latency' tradeoff omits the orchestration overhead that the paper itself measures separately. These issues are fixable but currently leave the main performance-related conclusions unsupported.

major comments (3)
  1. [§V-B and §V-E] Fig. 8's 'end-to-end latency' is defined as the sum of compute and communication times only, explicitly excluding orchestration overhead. Section V-E separately measures this overhead at a median of 376–418 ms for a warm three-function workflow (Fig. 13a). Because the number of DAG partitions, cross-tier dependencies, and dispatch paths change across the 10 video-analytics placements, this overhead cannot be assumed constant. Adding a placement-dependent overhead could change which configuration achieves the lowest end-to-end latency, undermining the central tradeoff claim. Please measure orchestration overhead within the real video workflow for each configuration, or provide a rigorous bound showing it is negligible relative to the differences in Fig. 8.
  2. [§V-A to §V-E (Figs. 6–13)] All quantitative conclusions are based on single-run measurements. No error bars, repetitions, confidence intervals, or statistical tests are reported. For example, the claim that Configuration 3 minimizes end-to-end latency (Fig. 8) and the accuracy ordering in Fig. 11 could well be noise if network RTTs or device performance vary. Table II gives only average RTTs without variance. The paper should report the number of runs and use at least 5–10 repetitions with standard deviation or interquartile ranges, especially for the latency and accuracy measurements that support the tradeoff conclusions.
  3. [§V and §I] The evaluation is self-referential: EdgeFaaS is the only system executed, with no comparison against a baseline such as direct deployment on OpenFaaS/faasd, a non-virtualized placement, or an existing edge-FaaS framework. The introduction's assertion that existing distributed computing frameworks 'cannot adequately handle' heterogeneity and distribution is therefore not supported by the experiments. At a minimum, include a baseline deployment of the same workflows without EdgeFaaS orchestration, or explicitly scope the claims to usability and feasibility rather than comparative advantage.
minor comments (5)
  1. [§III-A, Table III] The text mentions NVIDIA Jetson and Coral Edge TPU as example edge devices, but the testbed in Table III uses only Raspberry Pi and ESP32. Clarify whether any accelerator-equipped edge devices were actually used in the evaluation.
  2. [List 1] The YAML indentation of the workflow specification appears ambiguous, with 'do:' and 'handle:' fields nested inconsistently. Ensure it conforms exactly to the CNCF Serverless Workflow DSL, since the paper's standards-based claim relies on this example.
  3. [Fig. 13] The text reports a median latency range of 376–418 ms, but the y-axis of Fig. 13(a) appears truncated or differently scaled. Report the exact medians, quartiles, and number of samples for each invocation rate.
  4. [§VI] The conclusion states that EdgeFaaS is open-source, but no repository URL or artifact link is given. Provide one in the final version for reproducibility.
  5. [Table III] Typo in the ESP32-S3 row: '16 MB PSRAM OTA' likely means '16 MB PSRAM, supports OTA'. Also, 'OTA' appears as a row entry rather than a feature description.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: EdgeFaaS's claims are supported by direct system measurements, not by equations that reduce to fitted inputs; self-citations are contextual only.

full rationale

The paper is an empirical systems paper: it implements EdgeFaaS and demonstrates three workflows over a testbed. There is no derivation in which an output quantity is defined in terms of the quantity it is claimed to predict. The video placement results (Figs. 6-8) use user-specified configurations and report measured compute, communication, and their sum; the FL results compare measured training time and accuracy across cluster sizes; the audio results compare measured accuracy and fine-tuning time across schedules. None of these is a fitted parameter renamed as a prediction. The self-citations ([9], [17], [31], [33]) appear as related-work context or illustrative applications ('Recent position papers [9]-[11]', 'such as video surveillance [31]'), never as a load-bearing uniqueness theorem, ansatz, or justification of the core design/evaluation. The skeptic's concern that Fig. 8's end-to-end latency excludes the orchestration overhead measured in Fig. 13 is a measurement-validity / metric-completeness issue, not circularity: the paper explicitly defines that latency as compute plus communication, and the conclusion follows from that defined metric without reducing to an input. Similarly, single-run timings and missing external baselines weaken evidential strength but are not instances of definitional or self-citation circularity. Therefore no circular step is exhibited.

Assumptions & free parameters 9 free parameters · 4 assumptions · 0 invented entities

The framework's usability claims are supported by a fixed set of hand-chosen experimental parameters and domain assumptions about the testbed software and hardware. These choices limit the external validity of the quantitative results but are typical for a systems evaluation.

free parameters (9)
  • FL learning rate = 0.1
    Chosen by hand for the MNIST LeNet-5 workflow; affects convergence and accuracy, so the reported accuracy differences depend on this value.
  • FL momentum = 0.5
    Chosen by hand; standard SGD momentum, affects training dynamics.
  • FL batch size = 64
    Chosen by hand; influences gradient estimates and timing.
  • FL local iterations per upload = 100
    Chosen by hand; determines how often devices sync with aggregators and affects training time/accuracy tradeoff.
  • Edge aggregation count per cloud upload = 5
    Chosen by hand; controls hierarchy update frequency, central to the speed/accuracy comparison.
  • Total FL iterations = 2500
    Fixed stopping point; the accuracy comparison is made at this point, and conclusions depend on this choice.
  • FL cluster sizes = 100, 50, 20, 10
    Independent variable in the FL experiment; the observed accuracy/speed tradeoff is a function of these user-chosen values, not a derived optimum.
  • Audio fine-tuning rounds = 12
    The number of rounds over which accuracy and fine-tuning time are compared; arbitrary and hand-chosen.
  • Orchestration invocation rates = 10–100 requests/min
    Range chosen by hand to test scalability; the claim of 'no queuing effect' is bounded by this range.
assumptions (4)
  • domain assumption Underlying FaaS platforms (OpenFaaS, faasd) and object store (MinIO) expose the assumed deployment and invocation APIs.
    The entire function virtualization layer depends on these APIs; the paper does not verify or compare this integration in detail.
  • domain assumption ESP32 microcontrollers can run Python functions via MicroPython with OTA firmware updates as described.
    The IoT tier implementation for audio classification relies on this capability; no independent validation or performance numbers are provided beyond the workflow results.
  • domain assumption The measured network RTTs (Table II) are stable and representative of edge-cloud environments.
    The communication-time results and placement decisions (e.g., closest edge) depend on these measurements; no variance or repetition is reported.
  • domain assumption The selected workloads (video analytics, FL on MNIST, audio classification on ESC-10) are representative of real edge applications.
    The paper uses these to support the claim of 'comprehensive support'; they are simplified and small-scale, so generalization to production workloads is an assumption.

how reviews work

0 comments
Cite this review

Pith. "Pith review of EdgeFaaS: A Function-based Framework for Edge Computing." pith.science (2026). https://pith.science/paper/KMI2K4WD

@misc{pith2026260714489,
  author       = {Pith},
  title        = {Pith review of: EdgeFaaS: A Function-based Framework for Edge Computing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KMI2K4WD}},
  note         = {Machine review of arXiv:2607.14489}
}
read the original abstract

Edge computing brings unique challenges as the resources on the edge are highly diverse in capabilities and capacities, and highly distributed across many users and the physical world. Existing distributed computing frameworks cannot adequately handle this level of heterogeneity and distribution. This paper proposes EdgeFaaS, a novel function-based edge computing framework to enable edge applications to effectively utilize heterogeneous resources distributed across the Internet of Things (IoT), edge, and cloud for computing. It proposes function virtualization and storage virtualization to abstract distributed and heterogeneous physical resources and provides consistent virtual interfaces for deploying and executing functions and storing and accessing data. EdgeFaaS provides comprehensive support to diverse edge computing workflows, and at the same time allows users to flexibly adjust the configurations and explore various important tradeoffs. To demonstrate its usability, the paper also presents the implementation and evaluation of three representative workflows on EdgeFaaS for video analytics, federated learning, and audio classification, on a real testbed of 100+ geographically distributed IoT devices, edge servers, and cloud services. EdgeFaaS allows users to flexibly explore the deployment configurations of these workflows over distributed and heterogeneous resources. For example, users can easily vary the function placement of the video processing pipeline across IoT, edge, and cloud resources and study the tradeoff between computation and communication costs; users can also flexibly adjust the cluster count and size in the hierarchical federated learning system and explore the tradeoff between training accuracy and speed.

Figures

Figures reproduced from arXiv: 2607.14489 by the authors.

Figure 1
Figure 1. EdgeFaaS system architecture. A. Resource Virtualization EdgeFaaS manages heterogeneous resources across differ￾ent tiers, providing computing and storage capabilities for deploying and running functions and storing and accessing data. There are mainly three broad categories of function resources. The first category is FaaS clusters and servers such as cloud FaaS services (e.g., Amazon Lambda [2], Google Cloud Funct… view at source ↗
Figure 3
Figure 3. Hierarchical federated learning workflow The iot-training function’s physical deployment is deter￾mined by following the data accessibility principle that the necessary input data must be accessible from where the function will be placed. In the given example, EdgeFaaS deploys the iot-training function on the IoT nodes containing the private buckets (fl/data1, fl/data2, fl/data3, and fl/data4). Each instance of the … view at source ↗
Figure 5
Figure 5. Configuration settings for video analytics workflow 2) Compute time comparison [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗
Figures from the paper (7 more)
Figure 6
Figure 6. Figure 6: Compute time for video analytics workflow in the entire workflow, we observe that keeping VS and MD on the same tier helps bring down the total communication time. The exception is when VS and MD are co-located on the IoT tier; the weak hardware of the IoT device still…
Figure 7
Figure 7. Figure 7: Communication time for video analytics workflow 4) Compute vs. Communication time [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 9
Figure 9. Figure 9: Configuration settings for federated learning workflow. Con￾figuration 1 illustrates traditional federated learning involving two tiers in a single-cluster scenario. Configurations 2, 3, and 4 depict hierarchical federated learning across three tiers, with cluster size…
Figure 11
Figure 11. Figure 11: Accuracy of federated learning for different configurations When [PITH_FULL_IMAGE:figures/full_fig_p009_11.png]
Figure 10
Figure 10. Figure 10: Total training time of the federated learning workflow for the different configurations 4) Accuracy comparison [PITH_FULL_IMAGE:figures/full_fig_p009_10.png]
Figure 12
Figure 12. Figure 12: (a) Accuracy and (b) fine-tuning time of the audio classifi￾cation workflow for different configurations. 4) Fine-tuning time comparison [PITH_FULL_IMAGE:figures/full_fig_p010_12.png]
Figure 13
Figure 13. Figure 13: (a) shows the end-to-end workflow latency, which includes mainly the orchestration overhead. The results show that EdgeFaaS provides a stable median latency of 376-418 ms across the entire range of workflow invocation rate, a 10× increase in arrival pressure with no m…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

39 extracted references · 1 linked inside Pith

  1. [1]

    Functions as a Service (FaaS),

    E. Alex, “Functions as a Service (FaaS),” [Online]. Available: https://blog. alexellis.io/functions- as- a- service/, 2017, [Accessed: May 6, 2025]

    2017

  2. [2]

    AWS Lambda,

    Amazon Web Services, “AWS Lambda,” [Online]. Available: https://aws.amazon.com/lambda/, [Accessed: June 1, 2026]

    2026

  3. [3]

    CSPOT: portable, multi-scale functions-as-a-service for IoT,

    R. Wolski, C. Krintz, F. Bakir, G. George, and W.-T. Lin, “CSPOT: portable, multi-scale functions-as-a-service for IoT,” inProceedings of the 4th ACM/IEEE Symposium on Edge Computing, 2019

    2019

  4. [4]

    NanoLambda: Imple- menting Functions as a Service at All Resource Scales for the Internet of Things,

    G. George, F. Bakir, R. Wolski, and C. Krintz, “NanoLambda: Imple- menting Functions as a Service at All Resource Scales for the Internet of Things,” in2020 IEEE/ACM Symposium on Edge Computing (SEC)

  5. [5]

    Tinyedge: Enabling rapid edge system customization for IoT applications,

    W. Zhang, Y . Zhang, H. Fan, Y . Gao, W. Dong, and J. Wang, “Tinyedge: Enabling rapid edge system customization for IoT applications,” in2020 IEEE/ACM Symposium on Edge Computing (SEC). IEEE, 2020

    2020

  6. [6]

    CNCF Serverless Workflow,

    Cloud Native Computing Foundation (CNCF), “CNCF Serverless Workflow,” [Online]. Available: https://www.cncf.io/projects/serverless- workflow/, [Accessed: May 28, 2024]

    2024

  7. [7]

    AWS Greengrass

    Amazon Web Services. AWS Greengrass. [Online]. Available: https://aws.amazon.com/greengrass/. [Accessed: June 1, 2025]

    2025

  8. [8]

    Azure IoT Edge,

    Microsoft, “Azure IoT Edge,” [Online]. Available: https://azure.microsoft.com/en-us/products/iot-edge, [Accessed: June 1, 2025]

    2025

Show all 39 references
  1. [9]

    When Edge Meets FaaS: Opportunities and Challenges ,

    R. Jin, Q. Yang, and M. Zhao, “ When Edge Meets FaaS: Opportunities and Challenges ,” in2023 IEEE International Conference on Edge Computing and Communications (EDGE), 2023

    2023

  2. [10]

    EDGELESS: A Software Architecture for Stateful FaaS at the Edge,

    C. Cicconetti, E. Carlini, R. Hetzel, R. Mortier, A. Paradell, and M. Sauer, “EDGELESS: A Software Architecture for Stateful FaaS at the Edge,” inProceedings of the 33rd International Symposium on High- Performance Parallel and Distributed Computing, ser. HPDC ’24, 2024

    2024

  3. [11]

    Towards a serverless platform for edge computing,

    L. Baresi and D. Filgueira Mendonça, “Towards a serverless platform for edge computing,” in2019 IEEE International Conference on Fog Computing (ICFC), 2019, pp. 1–10

    2019

  4. [12]

    CW ASI: A WebAssembly Runtime Shim for Inter-function Communication in the Serverless Edge-Cloud Con- tinuum,

    C. Marcelino and S. Nastic, “CW ASI: A WebAssembly Runtime Shim for Inter-function Communication in the Serverless Edge-Cloud Con- tinuum,” inProceedings of the Eighth ACM/IEEE Symposium on Edge Computing, ser. SEC ’23, 2024

    2024

  5. [13]

    FaDO: FaaS Functions and Data Orchestrator for Multiple Serverless Edge- Cloud Clusters,

    C. P. Smith, A. Jindal, M. Chadha, M. Gerndt, and S. Benedict, “FaDO: FaaS Functions and Data Orchestrator for Multiple Serverless Edge- Cloud Clusters,” in2022 IEEE 6th International Conference on Fog and Edge Computing (ICFEC)

  6. [14]

    DFaaS: Decen- tralized Function-as-a-Service for Federated Edge Computing,

    M. Ciavotta, D. Motterlini, M. Savi, and A. Tundo, “DFaaS: Decen- tralized Function-as-a-Service for Federated Edge Computing,” in2021 IEEE 10th International Conference on Cloud Networking (CloudNet), 2021

    2021

  7. [15]

    Dy- namic workload balancing in decentralized edge systems: A marginal cost approach,

    E. Carlini, P. Dazzi, L. Ferrucci, J. Massa, and M. Mordacchini, “Dy- namic workload balancing in decentralized edge systems: A marginal cost approach,”Future Generation Computer Systems, p. 108167, 2025

    2025

  8. [16]

    DMSA: A decentralized microservice architecture for edge networks,

    Y . Chen, C. Lu, Y . Huang, C. Wu, F. Guo, H. Lu, and C. W. Chen, “DMSA: A decentralized microservice architecture for edge networks,” IEEE Transactions on Mobile Computing, 2026

    2026

  9. [17]

    Waterfall: Fast network flow rules checking and conflict resolution,

    N. Vadnere, D. Huang, A. Sabur, J. Luo, and M. Zhao, “Waterfall: Fast network flow rules checking and conflict resolution,”IEEE Transactions on Networking, vol. 33, no. 2, pp. 881–896, 2025

    2025

  10. [18]

    Google Cloud Functions,

    Google, “Google Cloud Functions,” [Online]. Available: https://cloud.google.com/functions/docs/, [Accessed: June 1, 2025]

    2025

  11. [19]

    Azure Functions,

    Microsoft, “Azure Functions,” [Online]. Available: https://azure.microsoft.com/en-us/services/functions/, 2021, [Accessed: May 26, 2026]

    2021

  12. [20]

    Apache OpenWhisk,

    Apache, “Apache OpenWhisk,” [Online]. Available: https://openwhisk.apache.org/, [Accessed: June 1, 2025]

    2025

  13. [21]

    faasd: A lightweight and portable FaaS engine,

    A. Ellis, “faasd: A lightweight and portable FaaS engine,” [Online]. Available: https://github.com/openfaas/faasd, 2022, [Accessed: May 6, 2025]

    2022

  14. [22]

    "tinyFaaS: A Lightweight FaaS Platform for Edge Environments

    T. Pfandzelter and D. Bermbach, “"tinyFaaS: A Lightweight FaaS Platform for Edge Environments",” inProceedings of the 2020 IEEE International Conference on Fog Computing (ICFC ’20). IEEE, 2020, pp. 17–24

    2020

  15. [23]

    Amazon - Amazon S3,

    Amazon Web Services, “Amazon - Amazon S3,” [Online]. Available: https://aws.amazon.com/s3/, 2021, [Accessed: Dec 1, 2025]

    2021

  16. [24]

    Google Cloud Storage,

    Google, “Google Cloud Storage,” [Online]. Available: https://cloud.google.com/storage/docs/, [Accessed: June 1, 2025]

    2025

  17. [25]

    Microsoft Azure Blob Storage,

    Microsoft, “Microsoft Azure Blob Storage,” [Online]. Available: https://azure.microsoft.com/services/storage/blobs/, [Accessed: June 1, 2025]

    2025

  18. [26]

    Minio - Kubernetes Native, High Performance Object Storage,

    MinIO, “Minio - Kubernetes Native, High Performance Object Storage,” [Online]. Available: https://min.io/, 2021, [Accessed: June 1, 2025]

    2021

  19. [27]

    OGC SensorThings API Specifica- tion,

    Open Geospatial Consortium, “OGC SensorThings API Specifica- tion,” [Online]. Available: https://docs.ogc.org/is/18-088/18-088.html, [Accessed: May 15, 2025]

    2025

  20. [28]

    OpenID Connect provider: How OpenID Connect works,

    OpenID Foundation, “OpenID Connect provider: How OpenID Connect works,” [Online]. Available: https://openid.net/developers/how-connect- works/, 2024, [Accessed: July 4, 2024]

    2024

  21. [29]

    SSD: Single shot multibox detector,

    W. Liu, D. Anguelov, D. Erhan, C. Szegedy, S. Reed, C.-Y . Fu, and A. C. Berg, “SSD: Single shot multibox detector,” inEuropean conference on computer vision. Springer, 2016

    2016

  22. [30]

    Deep residual learning for image recognition,

    K. He, X. Zhang, S. Ren, and J. Sun, “Deep residual learning for image recognition,” inProceedings of the IEEE conference on computer vision and pattern recognition, 2016

    2016

  23. [31]

    Scvs: On ai and edge clouds enabled privacy-preserved smart-city video surveillance services,

    S. Myneni, G. Agrawal, Y . Deng, A. Chowdhary, N. Vadnere, and D. Huang, “Scvs: On ai and edge clouds enabled privacy-preserved smart-city video surveillance services,”ACM Transactions on Internet of Things, no. 4, 2022

    2022

  24. [32]

    A survey of audio classification using deep learning,

    K. Zaman, M. Sah, C. Direkoglu, and M. Unoki, “A survey of audio classification using deep learning,”IEEE Access, vol. 11

  25. [33]

    Low- power weakly-supervised audio detection for real-world mosquito surveillance,

    D. Gupta, M. Zhao, and N. Rajendra Vadnere, “Low- power weakly-supervised audio detection for real-world mosquito surveillance,” inNeurIPS 2025 Workshop on Tackling Climate Change with Machine Learning, 2025. [Online]. Available: https://www.climatechange.ai/papers/neurips2025/108

    2025

  26. [34]

    Esc: Dataset for environmental sound classification,

    K. J. Piczak, “Esc: Dataset for environmental sound classification,” in Proceedings of the 23rd ACM international conference on Multimedia

  27. [35]

    Coral Keyphrase Detector - Keyword Spotter,

    Google, “Coral Keyphrase Detector - Keyword Spotter,” [Online]. Available: https://coral.ai/models/audio-classification/, 2025, [Accessed: Dec 1, 2025]

    2025

  28. [36]

    V oxceleb: a large-scale speaker identification dataset,

    A. Nagrani, J. S. Chung, and A. Zisserman, “V oxceleb: a large-scale speaker identification dataset,”arXiv preprint arXiv:1706.08612, 2017

    2017 arXiv

  29. [37]

    Audio set: An ontology and human-labeled dataset for audio events

    J. F. Gemmeke, D. P. W. Ellis, D. Freedman, A. Jansen, W. Lawrence, R. C. Moore, M. Plakal, and M. Ritter, “Audio set: An ontology and human-labeled dataset for audio events.”

  30. [38]

    The mnist database of handwritten digit images for machine learning research [best of the web],

    L. Deng, “The mnist database of handwritten digit images for machine learning research [best of the web],”IEEE signal processing magazine

  31. [39]

    Transfer learning with Y AMNet for environmen- tal sound classification YamNet Blog,

    “Transfer learning with Y AMNet for environmen- tal sound classification YamNet Blog,” 2025, https://www.tensorflow.org/tutorials/audio/transfer_learning_audio. 11

    2025

Pith tools

Reviewed August 2, 2026 · model on record in the stance chip above.