# Fog computing, from smart city services to natural environment monitoring

Guillaume Pierre

► To cite this version:

Guillaume Pierre. Fog computing, from smart city services to natural environment monitoring. SBRC 2025 - 43rd Brazilian Symposium on Computer Networks and Distributed Systems, May 2025, Natal, Brazil. hal-05084864

HAL Id: hal-05084864

https://inria.hal.science/hal-05084864v1

Submitted on 26 May 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Fog computing, from smart city services to natural environment monitoring

Guillaume Pierre

SBRC 2025 conference, May 22nd 2025
1 From Cloud to Fog computing

2 Fog research for smart city services

3 Fog research for natural environment monitoring

4 Conclusion
Infrastructure

"Infrastructure is the set of facilities and systems that serve a country, city, or other area, and encompasses the services and facilities necessary for its economy, households and firms to function. Infrastructure is composed of public and private physical structures such as roads, railways, bridges, tunnels, water supply, sewers, electrical grids, and telecommunications."

Wikipedia

<figure><img src="image_2.png" /></figure>
☐ Shared between a large number of users (multitenancy)

☐ High resource utilization thanks to statistical multiplexing

☐ Cost model based on usage rather than ownership

<figure><img src="image_3.png" /><figcaption>Friedrich Tellberg, CC BY-SA 3.0.</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>Hirzinger, CC BY-SA 3.0.</figcaption></figure>

Florian
<table><tr><td>App</td></tr><tr><td>Libraries &amp; frameworks</td></tr><tr><td>Operating System</td></tr><tr><td>Hardware</td></tr></table>

Traditional deployment
<figure><img src="image_5.png" /></figure>

Traditional deployment
<figure><img src="image_6.png" /></figure>
<figure><img src="image_7.png" /></figure>
<figure><img src="image_8.png" /></figure>
<figure><img src="image_9.png" /></figure>
<figure><img src="image_10.png" /></figure>
# Opportunities and Challenges of the Cloud Model

<figure><img src="image_11.png" /></figure>

* High resource utilization thanks to multitenancy

<figure><img src="image_12.png" /></figure>

* Access to "infinite" amounts of compute/storage/networking resources

<figure><img src="image_13.png" /></figure>

* Extreme flexibility thanks to a very broad offer of services

(August 2024: AWS proposes 326 services ranging from basic virtualized resources to high-level frameworks, machine learning, security, robotics, quantum, etc.)

<figure><img src="image_14.png" /></figure>

* Externalized system management (maintenance, security...)

<figure><img src="image_15.png" /></figure>

* Business-friendly cost model

<figure><img src="image_16.png" /></figure>

<figure><img src="image_17.png" /></figure>

* Data produced out of data centers must travel far to be processed
(latency, long-distance network usage, sometimes low networking reliability)

<figure><img src="image_18.png" /></figure>

* Data privacy issues

<figure><img src="image_19.png" /></figure>

* Environmental impact

> Fog computing aims to <u>extend the cloud</u>
> to <u>fix (some of) its issues</u>
> without <u>compromizing its amazing capabilities</u>
<figure><img src="image_20.png" /></figure>

Cloud is great but it is far... 😞
<figure><img src="image_21.png" /></figure>

Cloud is great but it is far... 😞

Fog computing extends cloud platforms
with **mini data centers close to the data sources** 😊
<figure><img src="image_22.png" /></figure>
<figure><img src="image_23.png" /></figure>
<figure><img src="image_24.png" /></figure>
## Typical Cloud platform

- Few data centers

- Lots of resources per data center

- High-performance networks

- Cloud resource location is (mostly) irrelevant

<figure><img src="image_25.png" /></figure>

## Typical Fog platform

- Huge number of points-of-presence

- Few resources per PoP

- Commodity networks

- Fog resource location is extremely important

<figure><img src="image_26.png" /></figure>
1 From Cloud to Fog computing

2 Fog research for smart city services

3 Fog research for natural environment monitoring

4 Conclusion
- Accelerate container deployment on RPs (hal-02271434, hal-02473333, hal-02332679, hal-02304285)

- Kubernetes resource scheduling strategies to place application replicas near their users (hal-02917191, hal-02932484)

- Ensure Kubernetes network routes lead to nearby replicas (hal-02048965)

- Fix instability problems of Kubernetes Federations in a fog (hal-02934475)

- Design better types of Kubernetes Federations (hal-03205743, hal-04760398v1)

- Long-distance live container migration (hal-02963913, hal-03587358)

- Better scalability for federated resource monitoring utilities (hal-04736577v1)

- Etc.
## Objectives:

- Process water consumption data from home counters in València, e.g., to detect leaks

- Replace aging technologies with LoRa+Fog

- Reclaim control over the data processing pipelines

<figure><img src="image_27.png" /></figure>

https://youtu.be/e-DdbVseiIA

fogguru

<figure><img src="image_28.png" /><figcaption>Fig. 7: Cumulative number of messages for a day.</figcaption></figure>

<figure><img src="image_29.png" /><figcaption>Fig. 8: Latency (msec) of publishing to MQTT topics.</figcaption></figure>
# Fog for smart cities: marina management

## Objectives:

<figure><img src="image_30.png" /></figure>

- Deploy a fog platform + sensors in València's marina: weather, wind, water quality, waves, people, cars.

<figure><img src="image_31.png" /></figure>

- Answer a number of specific management issues (wind, waves)

<figure><img src="image_32.png" /></figure>

- Run a hackathon to promote fog technologies

<figure><img src="image_33.png" /></figure>

Hackathon winner: an app that detects sedimentation problems that commonly affect ports.

<figure><img src="image_34.png" /></figure>

https://youtu.be/9GJmc8PfK0A
1 From Cloud to Fog computing

2 Fog research for smart city services

3 Fog research for natural environment monitoring

4 Conclusion
# Natural environment monitoring

Researchers in natural sciences like to create observatories where they can measure and observe the ecosystem from multiple points of view

- Define a geographical zone of particular interest

- Collect and archive measurement data

- Derive actionable insight (short-term) and/or long-term analysis

<figure><img src="image_35.png" /></figure>

<figure><img src="image_36.png" /></figure>
We surveyed 34 observatories in France, Germany, Laos, Morocco and Nepal

☐ Long-term observation observatories: periodic data collection over long periods of time (several years)

☐ Event-oriented observatories: interested in short- or medium-duration events such as floods, heat waves and earthquakes. Other periods are not interesting.

<figure><img src="image_37.png" /></figure>
<figure><img src="image_38.png" /></figure>

<table><thead><tr><th>Power supply:</th><th>Electrical grid</th><th>Solar</th><th>Internal batteries</th><th>Other</th></tr></thead><tbody><tr><td></td><td>13%</td><td>43%</td><td>39%</td><td>4%</td></tr></tbody></table>
Failure detection delays ~6 days (wireless reporting), up to ~109 days (manual collection)

<figure><img src="image_39.png" /></figure>
Opportunity: introduce fog computing in observatories

☐ To generate alerts about failures

☐ To aggregate data before transmission

☐ To compare produced data with external data sources

☐ To compare produced data with a model's output

☐ To adjust sampling frequencies or trigger actuators when an interesting event is about to happen

<figure><img src="image_40.png" /></figure>
Use Case: Kaligandaki Observatory

<figure><img src="image_41.png" /></figure>
☐ Running environmental observatory in Nepal since 2012

☐ Two deployed GFZ stations

▷ Various sensors (rain sensors, river gauging station, seismometers...)

▷ Raspberry Pi to collect and send data from sensors

⚠ Manual failure detection

☞ Need a data monitoring service

⚠ Limited & intermittent 3G Internet connection

☞ Interested in in-situ event detection and response

⚠ Lots of ideas for new cool applications

☞ Using AI to classify seismometer data, executing digital twins of the river, ...

⚠ Limited energy availability

☞ Need to offer significant processing power with low energy consumption
<figure><img src="image_42.png" /></figure>
<figure><img src="image_43.png" /></figure>
## Requirements

- [ ] Medium computing capacity

- [ ] Low energy usage → energy proportionality

- [ ] Cost

## Options

- [?] Solar panel + battery

- [?] Raspberry Pi's? Better several old ones than a single recent one?

<figure><img src="image_44.png" /></figure>
<figure><img src="image_45.png" /></figure>

Turing Pi:

☐ 4 slots for RPI compute modules, RK1, Jetson Nano...

☐ Slots can be powered on/off on demand

<figure><img src="image_46.png" /></figure>

Sipeed Nanocluster:

☐ 7 slots for RPI compute modules
<figure><img src="image_47.png" /></figure>

Beware: the Turing Pi board itself adds a fixed 3.4 W power consumption
<figure><img src="image_48.png" /></figure>

Long-term monitoring

<figure><img src="image_49.png" /></figure>

Event-based observatory

How can we design the "best" cluster to handle a given workload?
Idea: make sure each application has enough capacity to process data with no delay

<figure><img src="image_50.png" /></figure>

Configure a cluster with enough modules to handle the sum of all applications' peak demand (here: 2 RK1 + 1 CM4)

<figure><img src="image_51.png" /></figure>

<figure><img src="image_52.png" /></figure>

Almost no processing delay

<figure><img src="image_53.png" /></figure>

Very low resource utilization!

<figure><img src="image_54.png" /></figure>

High energy consumption

<figure><img src="image_55.png" /></figure>

<figure><img src="image_56.png" /></figure>
The budget option: 🍃 green configuration

<figure><img src="image_57.png" /></figure>

Idea: reduce the cluster size as much as possible

<figure><img src="image_58.png" /></figure>

Configure a cluster with enough modules to handle the *mean* demand (here: 1 RK1)

<figure><img src="image_59.png" /></figure>

<figure><img src="image_60.png" /></figure>

Much higher resource utilization

<figure><img src="image_61.png" /></figure>

Energy consumption is much lower

<figure><img src="image_62.png" /></figure>

Very high processing delays when the system is overloaded
Idea: dynamically power compute modules on/off according to demand

<figure><img src="image_63.png" /></figure>

Here: using 2 RK1 + 1 CM4

<figure><img src="image_64.png" /></figure>

😊 Much fewer processing delays (mostly due to boot + load rebalance operations)

😊 Good resource utilization

😊 Fairly low energy consumption
<figure><img src="image_65.png" /></figure>

## DIAMOND CONFIG

<figure><img src="image_66.png" /></figure>

All data will be processed

<figure><img src="image_67.png" /></figure>

Real-time processing guarantees

Guarantees

Cluster provisioned to the peak workload

Technique

<figure><img src="image_68.png" /></figure>

252 Wh/day

<figure><img src="image_69.png" /></figure>

Processing delays:

<figure><img src="image_70.png" /></figure>

Median: 0 s

<figure><img src="image_71.png" /></figure>

99th perc.: 0.03 s

<figure><img src="image_72.png" /></figure>

Max: 20 s

Cost

<figure><img src="image_73.png" /></figure>

26% CPU utilization

For demanding use-cases?
<figure><img src="image_74.png" /></figure>

## GREEN CONFIG

<figure><img src="image_75.png" /></figure>

All data will be processed **eventually**

<figure><img src="image_76.png" /></figure>

No real-time processing guarantee

Guarantees

Cluster provisioned to the **mean** workload

Technique

<figure><img src="image_77.png" /></figure>

162 Wh/day

<figure><img src="image_78.png" /></figure>

Processing delays:

<figure><img src="image_79.png" /></figure>

Median: 0 s

<figure><img src="image_80.png" /></figure>

99th perc.: 15 min

<figure><img src="image_81.png" /></figure>

Max: 17 min

<figure><img src="image_82.png" /></figure>

61.4% CPU utilization

Cost

For long-term observations?

<figure><img src="image_83.png" /></figure>

## DIAMOND CONFIG

<figure><img src="image_84.png" /></figure>

All data will be processed

<figure><img src="image_85.png" /></figure>

Real-time processing guarantees

Cluster provisioned to the **peak** workload

<figure><img src="image_86.png" /></figure>

252 Wh/day

<figure><img src="image_87.png" /></figure>

Processing delays:

<figure><img src="image_88.png" /></figure>

Median: 0 s

<figure><img src="image_89.png" /></figure>

99th perc.: 0.03 s

<figure><img src="image_90.png" /></figure>

Max: 20 s

<figure><img src="image_91.png" /></figure>

26% CPU utilization

For demanding use-cases?
# Fog cluster provisioning strategies (event-driven observatory)

<figure><img src="image_92.png" /></figure>

## GREEN CONFIG

<figure><img src="image_93.png" /></figure>

All data will be processed **eventually**

<figure><img src="image_94.png" /></figure>

No real-time processing guarantee

Cluster provisioned to the **mean** workload

Guarantees

Technique

<figure><img src="image_95.png" /></figure>

## GOLD CONFIG

<figure><img src="image_96.png" /></figure>

All data will be processed

<figure><img src="image_97.png" /></figure>

**Near** real-time processing guarantees

Cluster dynamically autoscaled to the workload

<figure><img src="image_98.png" /></figure>

## DIAMOND CONFIG

<figure><img src="image_99.png" /></figure>

All data will be processed

<figure><img src="image_100.png" /></figure>

Real-time processing guarantees

Cluster provisioned to the **peak** workload

<figure><img src="image_101.png" /></figure>

162 Wh/day

<figure><img src="image_102.png" /></figure>

### Processing delays:

<figure><img src="image_103.png" /></figure>

Median: 0 s

<figure><img src="image_104.png" /></figure>

99th perc.: 15 min

<figure><img src="image_105.png" /></figure>

Max: 17 min

<figure><img src="image_106.png" /></figure>

61.4% CPU utilization

<figure><img src="image_107.png" /></figure>

173 Wh/day

<figure><img src="image_108.png" /></figure>

### Processing delays:

<figure><img src="image_109.png" /></figure>

Median: 0 s

<figure><img src="image_110.png" /></figure>

99th perc.: 0.09 s

<figure><img src="image_111.png" /></figure>

Max: 5 min

<figure><img src="image_112.png" /></figure>

50.9% CPU utilization

<figure><img src="image_113.png" /></figure>

252 Wh/day

<figure><img src="image_114.png" /></figure>

### Processing delays:

<figure><img src="image_115.png" /></figure>

Median: 0 s

<figure><img src="image_116.png" /></figure>

99th perc.: 0.03 s

<figure><img src="image_117.png" /></figure>

Max: 20 s

<figure><img src="image_118.png" /></figure>

26% CPU utilization

For long-term observations?

For event observatories?

For demanding use-cases?
1 From Cloud to Fog computing

2 Fog research for smart city services

3 Fog research for natural environment monitoring

4 Conclusion
Fog for environmental observatories ≠ fog for smart cities or industry

- Often in remote locations

- Often based on poor infrastructure (power, network)

- Multitenancy

- Many new challenges, especially regarding energy management

<figure><img src="image_119.png" /><figcaption>Ammar
Kazem</figcaption></figure>

<figure><img src="image_120.png" /><figcaption>Matthieu
Nicolas</figcaption></figure>

<figure><img src="image_121.png" /><figcaption>Guillaume
Pierre</figcaption></figure>

<figure><img src="image_122.png" /><figcaption>Laurent
Longuevergne</figcaption></figure>

<figure><img src="image_123.png" /><figcaption>Christoff
Andermann</figcaption></figure>