pith. sign in

arxiv: 1907.08278 · v1 · pith:QEUVV2Z5new · submitted 2019-07-18 · 💻 cs.DC

Fog Function: Serverless Fog Computing for Data Intensive IoT Services

Bin Cheng , Jonathan F\"urst , Gurkan Solmaz , Takuya Sanada This is my paper

Pith reviewed 2026-05-24 19:16 UTC · model grok-4.3

classification 💻 cs.DC
keywords fog computingserverless computingIoT servicesfunction as a servicedata-centric modelorchestrationedge computingsmart parking
0
0 comments X

The pith

Fog Function uses data-centric orchestration with three contexts to enable flexible and efficient serverless fog computing for data-intensive IoT services.

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

The paper introduces Fog Function as a programming model that moves beyond event-based or topic-based function triggering in standard FaaS by adopting a data-oriented approach for dynamic service composition. Its orchestration mechanism draws on data context, system context, and usage context to decide when and where to execute functions, addressing the separation of data management and execution that causes inefficiency in existing fog and edge setups. Evaluation on a smart parking use case shows that developers can express service logic more easily than with static topologies, the approach scales to hundreds of fog nodes, internal data traffic drops by 95 percent relative to cloud functions, and service latency falls by 30 percent relative to edge functions.

Core claim

Fog Function is a data-centric programming model for fog computing whose orchestration mechanism leverages data context, system context, and usage context to trigger and place functions. This design supports dynamic service composition for IoT workloads while integrating data handling with execution, unlike conventional FaaS designs. In the smart parking case, the model lets developers define logic without committing to a fixed topology. Performance results establish that the system scales to hundreds of fog nodes, saves 95 percent of internal data traffic compared with cloud functions, and reduces service latency by 30 percent compared with edge functions.

What carries the argument

The Fog Function model and its orchestration mechanism that leverages data context, system context, and usage context to manage function triggering and data movement.

If this is right

  • Service developers can model dynamic logic with less effort than required by static service topologies.
  • Internal data traffic drops by 95 percent relative to cloud-function baselines.
  • Service latency falls by 30 percent relative to edge-function baselines.
  • The approach scales to deployments involving hundreds of fog nodes.
  • Data management and function execution are handled together rather than separately.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same context-driven triggering could be tested on other data-intensive workloads such as video analytics or sensor fusion outside the parking domain.
  • If context collection proves costly in very large or highly mobile node sets, lightweight approximations of the three contexts might still preserve most of the gains.
  • Seamless hand-off between Fog Function instances and conventional cloud FaaS could be explored to handle load spikes.
  • Heterogeneous fog nodes with differing compute and storage capacities may require additional rules inside the orchestration mechanism.

Load-bearing premise

The three contexts can be collected and leveraged for orchestration with low enough overhead to deliver the claimed efficiency gains, and the smart parking evaluation and scalability tests represent typical data-intensive IoT workloads without hidden selection effects.

What would settle it

A controlled measurement on a comparable IoT workload in which the overhead of collecting and acting on the three contexts exceeds the reported 95 percent traffic reduction or 30 percent latency improvement.

Figures

Figures reproduced from arXiv: 1907.08278 by Bin Cheng, Gurkan Solmaz, Jonathan F\"urst, Takuya Sanada.

Figure 1
Figure 1. Figure 1: The connected car use case. the seamless move from code to data or from data to code. Based on the validation and analysis of two use cases, we show that Fog Function is more flexible and efficient than traditional event-based cloud functions to support serverless fog computing for data-intensive IoT services. • We propose a context-driven orchestration mechanism to dynamically and automatically trigger, c… view at source ↗
Figure 2
Figure 2. Figure 2: High level system view proposed technology. More details are provided in the follow￾ing sections. O1 O2 O3 O4 O5 O6 G1 G2 G3 G4 Fog Function Programming Model Content-based Discovery Data-driven Function Orchestration Context-aware Task Deployment/Migration observations gaps technology means [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: The mapping between gaps and observations/proposed [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Context discovery with two-layer design based query and subscription but also geoscope-based or attribute-based query and subscription. D. Data-driven Function Orchestration Figurer 5 shows the major procedure for Orchestrator to orchestrate fog functions based on the update notification of context availability of their input data, provided by Content￾based Discovery. More specifically, the following four … view at source ↗
Figure 6
Figure 6. Figure 6: Design of fog functions for a smart parking use case [PITH_FULL_IMAGE:figures/full_fig_p006_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Initial measurement results of the FogFlow system [PITH_FULL_IMAGE:figures/full_fig_p007_7.png] view at source ↗
read the original abstract

Fog computing can support IoT services with fast response time and low bandwidth usage by moving computation from the cloud to edge devices. However, existing fog computing frameworks have limited flexibility to support dynamic service composition with a data-oriented approach. Function-as-a-Service (FaaS) is a promising programming model for fog computing to enhance flexibility, but the current event- or topic-based design of function triggering and the separation of data management and function execution result in inefficiency for data-intensive IoT services. To achieve both flexibility and efficiency, we propose a data-centric programming model called Fog Function and also introduce its underlying orchestration mechanism that leverages three types of contexts: data context, system context, and usage context. Moreover, we showcase a concrete use case for smart parking where Fog Function allows service developers to easily model their service logic with reduced learning efforts compared to a static service topology. Our performance evaluation results show that the Fog Function can be scaled to hundreds of fog nodes. Fog Function can improve system efficiency by saving 95% of the internal data traffic over cloud function and it can reduce service latency by 30% over edge function.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 1 minor

Summary. The paper proposes Fog Function, a data-centric serverless (FaaS) programming model for fog computing in data-intensive IoT services. It introduces an orchestration layer that leverages data context, system context, and usage context to support dynamic service composition, addressing limitations of event/topic-based triggering and separation of data management from execution. The model is demonstrated via a smart-parking use case that claims reduced developer effort relative to static topologies; empirical results assert scalability to hundreds of fog nodes, 95% reduction in internal data traffic versus cloud functions, and 30% latency reduction versus edge functions.

Significance. If the performance claims and negligible context-collection overhead can be substantiated, the work would advance serverless fog computing by offering a flexible, data-oriented alternative to existing frameworks. The multi-context orchestration idea directly targets inefficiency in data-intensive IoT workloads and could influence future FaaS designs for edge environments.

major comments (3)
  1. [Abstract / Evaluation] Abstract and Evaluation section: the central claims of 95% internal traffic reduction versus cloud functions and 30% latency reduction versus edge functions are stated without any description of experimental methodology, workload parameters, baselines, measurement procedures, or error bars, rendering the numbers unverifiable from the manuscript.
  2. [Orchestration mechanism] Orchestration mechanism (context collection and dissemination): no quantification or analysis is provided of the overhead incurred by continuously gathering and acting on the three contexts; if this overhead is non-negligible relative to the optimized traffic, the net savings claimed in the abstract cannot be guaranteed.
  3. [Smart parking use case / Scalability evaluation] Smart-parking use case and scalability tests: the manuscript does not discuss potential selection effects (e.g., context-update frequency, node homogeneity) or demonstrate that these workloads are representative of broader data-intensive IoT services, weakening the generalizability of the efficiency and scalability results.
minor comments (1)
  1. [Abstract] The abstract would benefit from a single sentence summarizing the evaluation methodology to allow readers to assess the performance claims at a glance.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive comments. We address each major point below and will revise the manuscript accordingly.

read point-by-point responses

  1. Referee: [Abstract / Evaluation] Abstract and Evaluation section: the central claims of 95% internal traffic reduction versus cloud functions and 30% latency reduction versus edge functions are stated without any description of experimental methodology, workload parameters, baselines, measurement procedures, or error bars, rendering the numbers unverifiable from the manuscript.

    Authors: We agree that the Evaluation section requires additional detail for verifiability. We will expand it in the revision with a dedicated subsection describing the experimental methodology, workload parameters, baselines, measurement procedures, and error bars. revision: yes

  2. Referee: [Orchestration mechanism] Orchestration mechanism (context collection and dissemination): no quantification or analysis is provided of the overhead incurred by continuously gathering and acting on the three contexts; if this overhead is non-negligible relative to the optimized traffic, the net savings claimed in the abstract cannot be guaranteed.

    Authors: We acknowledge that the manuscript does not quantify context overhead. We will add measurements and analysis in the revised version to demonstrate that the overhead is negligible relative to the traffic savings. revision: yes

  3. Referee: [Smart parking use case / Scalability evaluation] Smart-parking use case and scalability tests: the manuscript does not discuss potential selection effects (e.g., context-update frequency, node homogeneity) or demonstrate that these workloads are representative of broader data-intensive IoT services, weakening the generalizability of the efficiency and scalability results.

    Authors: We will add a discussion section addressing selection effects (context-update frequency, node homogeneity) and the representativeness of the workloads for broader IoT services to strengthen generalizability. revision: yes

Circularity Check

0 steps flagged

No circularity; claims rest on empirical evaluation without derivations or self-referential fits

full rationale

The paper proposes Fog Function as a data-centric model with orchestration using data/system/usage contexts, then reports efficiency numbers (95% traffic reduction, 30% latency reduction) and scalability from concrete evaluations (smart parking, hundreds of nodes). No equations, fitted parameters, or derivation chains appear. Claims are not produced by renaming inputs, self-citation of uniqueness theorems, or ansatzes smuggled via prior work; they are direct outputs of the described experiments. This matches the default case of a self-contained systems paper whose central results are externally falsifiable via the reported workloads.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The central claim rests on the unverified effectiveness of context collection and orchestration plus representativeness of the reported performance numbers; no free parameters or invented physical entities are visible in the abstract.

axioms (1)
  • domain assumption Fog nodes can dynamically collect and act on data, system, and usage contexts with overhead low enough to achieve the stated efficiency gains.
    Invoked to support the orchestration mechanism and performance claims.
invented entities (1)
  • Fog Function no independent evidence
    purpose: Data-centric programming model and orchestration mechanism for fog computing
    New model introduced to address limitations of existing frameworks; no independent evidence outside the paper is provided.

pith-pipeline@v0.9.0 · 5733 in / 1425 out tokens · 46371 ms · 2026-05-24T19:16:32.514587+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

26 extracted references · 26 canonical work pages · 2 internal anchors

  1. [1]

    A Berkeley View of Systems Challenges for AI

    I. Stoica, D. Song, R. A. Popa, D. Patterson, M. W. Mahoney, R. Katz, A. D. Joseph, M. Jordan, J. M. Hellerstein, J. E. Gonzalez et al. , “A berkeley view of systems challenges for ai,” arXiv preprint arXiv:1712.05855, 2017

    work page internal anchor Pith review Pith/arXiv arXiv 2017

  2. [2]

    Real-time video analytics: The killer app for edge computing,

    G. Ananthanarayanan, P. Bahl, P. Bod ´ık, K. Chintalapudi, M. Philipose, L. Ravindranath, and S. Sinha, “Real-time video analytics: The killer app for edge computing,” computer, vol. 50, no. 10, pp. 58–67, 2017

    work page 2017

  3. [3]

    The emergence of edge computing,

    M. Satyanarayanan, “The emergence of edge computing,” Computer, vol. 50, no. 1, pp. 30–39, 2017

    work page 2017

  4. [4]

    Azure iot edge,

    “Azure iot edge,” https://docs.microsoft.com/en-us/azure/iot-edge/, 2019

    work page 2019

  5. [5]

    Aws iot greengrass,

    “Aws iot greengrass,” https://aws.amazon.com/greengrass/, 2019

    work page 2019

  6. [6]

    “Edgex,” https://www.edgexfoundry.org/, 2019

    work page 2019

  7. [7]

    Openedge,

    “Openedge,” https://github.com/baidu/openedge, 2019

    work page 2019

  8. [8]

    Cloud programming simplified: A berkeley view on serverless computing,

    E. Jonas, J. S. Smith, V . Sreekanti, C.-C. Tsai, A. Khandelwal, Q. Pu, V . Shankar, J. Carreira, K. Krauth, N. Yadwadkar, J. E. Gonzalez, R. A. Popa, I. Stoica, and D. A. Patterson, “Cloud programming simplified: A berkeley view on serverless computing,” 2019

    work page 2019

  9. [9]

    Serverless Computing: One Step Forward, Two Steps Back,

    J. M. Hellerstein, J. Faleiro, J. E. Gonzalez, J. Schleier-Smith, V . Sreekanti, A. Tumanov, and C. Wu, “Serverless Computing: One Step Forward, Two Steps Back,” in The biennial Conference on Innovative Data Systems Research (CIDR) , 2019

    work page 2019

  10. [10]

    Peeking behind the curtains of serverless platforms,

    L. Wang, M. Li, Y . Zhang, T. Ristenpart, and M. Swift, “Peeking behind the curtains of serverless platforms,” in 2018 USENIX Annual Technical Conference (USENIX ATC 18) . Boston, MA: USENIX Association, 2018, pp. 133–146

    work page 2018

  11. [11]

    Cloud-native, event-based pro- gramming for mobile applications,

    I. Baldini, P. Castro, P. Cheng, S. Fink, V . Ishakian, N. Mitchell, V . Muthusamy, R. Rabbah, and P. Suter, “Cloud-native, event-based pro- gramming for mobile applications,” in Proceedings of the International Conference on Mobile Software Engineering and Systems. ACM, 2016, pp. 287–288

    work page 2016

  12. [12]

    The context api in the oma next generation service interface,

    M. Bauer, E. Kovacs, A. Sch ¨ulke, N. Ito, C. Criminisi, L. W. Goix, and M. Valla, “The context api in the oma next generation service interface,” in 2010 14th International Conference on Intelligence in Next Generation Networks, Oct 2010, pp. 1–5

    work page 2010

  13. [13]

    Fogflow: Easy programming of iot services over cloud and edges for smart cities,

    B. Cheng, G. Solmaz, F. Cirillo, E. Kovacs, K. Terasawa, and A. Ki- tazawa, “Fogflow: Easy programming of iot services over cloud and edges for smart cities,” IEEE Internet of Things Journal , vol. 5, no. 2, pp. 696–707, 2018

    work page 2018

  14. [14]

    My vm is lighter (and safer) than your container,

    F. Manco, C. Lupu, F. Schmidt, J. Mendes, S. Kuenzer, S. Sati, K. Yasukata, C. Raiciu, and F. Huici, “My vm is lighter (and safer) than your container,” in Proceedings of the 26th Symposium on Operating Systems Principles. ACM, 2017, pp. 218–233

    work page 2017

  15. [15]

    The case for vm-based cloudlets in mobile computing,

    M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies, “The case for vm-based cloudlets in mobile computing,” IEEE pervasive Computing , no. 4, pp. 14–23, 2009

    work page 2009

  16. [16]

    Kubeedge,

    “Kubeedge,” https://github.com/kubeedge/kubeedge, 2019

    work page 2019

  17. [17]

    Telcofog: A unified flexible fog and cloud computing architecture for 5g networks,

    R. Vilalta, V . L ´opez, A. Giorgetti, S. Peng, V . Orsini, L. Velasco, R. Serral-Gracia, D. Morris, S. De Fina, F. Cugini et al., “Telcofog: A unified flexible fog and cloud computing architecture for 5g networks,” IEEE Communications Magazine , vol. 55, no. 8, pp. 36–43, 2017

    work page 2017

  18. [18]

    Aws step functions,

    “Aws step functions,” https://aws.amazon.com/step-functions/, 2019

    work page 2019

  19. [19]

    SAND: Towards high-performance serverless computing,

    I. E. Akkus, R. Chen, I. Rimac, M. Stein, K. Satzke, A. Beck, P. Aditya, and V . Hilt, “SAND: Towards high-performance serverless computing,” in 2018 USENIX Annual Technical Conference (USENIX ATC 18) . Boston, MA: USENIX Association, 2018, pp. 923–935. The research leading to these results has received funding from the European Com- munity’s Horizon 2020...

    work page 2018

  20. [20]

    SOCK: Rapid task provisioning with serverless-optimized containers,

    E. Oakes, L. Yang, D. Zhou, K. Houck, T. Harter, A. Arpaci- Dusseau, and R. Arpaci-Dusseau, “SOCK: Rapid task provisioning with serverless-optimized containers,” in 2018 USENIX Annual Technical Conference (USENIX ATC 18) , Boston, MA, 2018, pp. 57–70

    work page 2018

  21. [21]

    Occupy the cloud: Distributed computing for the 99%,

    E. Jonas, Q. Pu, S. Venkataraman, I. Stoica, and B. Recht, “Occupy the cloud: Distributed computing for the 99%,” in Proceedings of the 2017 Symposium on Cloud Computing . ACM, 2017, pp. 445–451

    work page 2017

  22. [22]

    Serving deep learning models in a serverless platform,

    V . Ishakian, V . Muthusamy, and A. Slominski, “Serving deep learning models in a serverless platform,” in 2018 IEEE International Conference on Cloud Engineering (IC2E) . IEEE, 2018, pp. 257–262

    work page 2018

  23. [23]

    Serverless foundations for elastic database systems

    J. Schleier Smith, “Serverless foundations for elastic database systems.”

    work page

  24. [24]

    Sprocket: A serverless video processing framework,

    L. Ao, L. Izhikevich, G. M. V oelker, and G. Porter, “Sprocket: A serverless video processing framework,” in Proceedings of the ACM Symposium on Cloud Computing . ACM, 2018, pp. 263–274

    work page 2018

  25. [25]

    Pocket: elastic ephemeral storage for serverless analyt- ics,

    A. Klimovic, Y . Wang, P. Stuedi, A. Trivedi, J. Pfefferle, and C. Kozyrakis, “Pocket: elastic ephemeral storage for serverless analyt- ics,” in 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI18), 2018, pp. 427–444

    work page 2018

  26. [26]

    Reinforcement Learning Based Orchestration for Elastic Services

    M. F. Argerich, B. Cheng, and J. F ¨urst, “Reinforcement learning based orchestration for elastic services,” arXiv preprint arXiv:1904.12676 , 2019. 9

    work page internal anchor Pith review Pith/arXiv arXiv 1904