# Placement of Distributed Machine Learning Services for AI- and Smart Grid-Enabled IoT Platforms

Jérémie Rodez, Patricia Stolf, Thierry Monteil

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

## To cite this version:

Jérémie Rodez, Patricia Stolf, Thierry Monteil. Placement of Distributed Machine Learning Services for AI- and Smart Grid-Enabled IoT Platforms. 2026. hal-05279358

HAL Id: hal-05279358

https://hal.science/hal-05279358v1

Preprint submitted on 4 Feb 2026

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_2.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Placement of Distributed Machine Learning Services for AI- and Smart Grid-Enabled IoT Platforms

Jérémie Rodez¹, Patricia Stolf¹, and Thierry Monteil¹,²

¹University of Toulouse, IRIT, CNRS, Toulouse, France

²INSA, Toulouse, France

{jeremie.rodez,patricia.stolf,thierry.monteil}@irit.fr

## Abstract

Artificial intelligence, fog computing, and smart grids allow for better energy management and personal data control. However, such heterogeneous platforms complexify service placement due to hardware and network heterogeneity. This paper proposes a distributed machine learning service for fog computing platforms model, and two new algorithms that aim to reduce time and energy consumption. The first algorithm groups services geographically, while the second places services vertically in the topology to reduce network usage. The Batsim simulator have been used to deploy distributed AI applications for measuring their duration and energy usage of the fog architecture. Results show that the first algorithm induces higher time and energy consumption than the second one, which outperforms multiple baseline algorithms for both metrics.

## 1 Introduction

Recent advances in artificial intelligence (AI), particularly in deep learning, have paved the way for cutting-edge, sector-specific applications in fields such as medicine, finance, industry or energy. Artificial intelligence raises new challenges, such as preserving privacy over data collections and learning processes based on these data. A solution is to be as close as possible to the user while improving QoS and data confidentiality. In parallel, numerous studies demonstrate the value of fog computing architecture for managing smart grid infrastructures, especially for energy management from the production to the consumption. For example, distributed learning use cases, such as weather or energy production forecasting, make the smart grid more efficient at controlling both small- and large-scale power loads. The combination of fog computing, smart grids, and distributed AI opens new possibilities for energy management in the context of climate change and data privacy issues.

Moreover, due to the need for hardware acceleration for certain components (e.g., training and inference), deployment is more complex than for standard CPU-only IoT services. While some studies classify distributed artificial intelligence for edge, fog, and
cloud deployment, others cover the interest of overlaying fog networks over smart grids [1], [2]. The intersection of these fields leads to new approaches and constraints for service placement.

To address these challenges, we propose a distributed learning service placement model over a fog computing platform, along with algorithms that solve the service placement problem while minimizing time consumption and indirectly energy. The evaluations of the proposed algorithms were conducted through simulations of distributed AI on the continuum of fog-cloud architecture.

This paper will first summarize the state of the literature on subjects related to smart grid, fog computing, distributed learning and the placement in section 2. Then, the placement model including a service workflow model and a platform model will be formalized in section 3. Afterward, section 4 will propose algorithms for placing distributed learning services on a smart grid-enabled fog computing platform. The algorithms presented will be evaluated in section 5 through simulations. Finally, we conclude this paper with a discussion on the results and open perspectives, in section 6.

# 2 Related Work

## 2.1 Distributed AI

Distributed artificial intelligence (AI) refers to the deployment of AI services across multiple devices. These technologies, such as federated learning, can be distributed in different ways within an IoT continuum. Distributed AI is classified into several levels corresponding to the distance of its services from the end user. Full use of AI services on end-devices corresponds to a level where the services are the closest to the user. Intermediate levels correspond to a hybrid use of AI services deployed on edge or fog computing. Another level corresponds to full use of the AI application on cloud [1].

At least three types of part of distributed AI services can be identified. The part of the application that generates data, the part that learns from the data, and the part that aggregates the results of the learning services. These three parts can be considered as services. [1], [3]

As of machine learning, the decentralization of machine learning can limit network data transferred when slow or congested. Federated learning is a commonly distributed ML technology. It uses the same machine that provides the data to train it, thereby increasing privacy. [1], [3]. However, not updating local models regularly with the global model can lead to concept drift.[4]

As for the use of hardware, resource usage will depend on the implementation. Among the most common frameworks (e.g. TensorFlow, Apache MXNet), the use of hardware accelerators is possible and can lead to significant performance improvements [5]. These hardware accelerators are generally GPUs, but can also be other types of hardware acceleration architectures such as TPUs or NPUs, sometimes implemented over an FPGA [1]. These hardware accelerators are generally GPUs, but can also be other types of hardware acceleration architectures such as TPUs or NPUs, sometimes implemented over an FPGA [1], [6], [7].
## 2.2 Fog Computing

Fog computing is a distributed computing paradigm that extends edge computing by providing an unlimited number of layers between end-devices and the cloud [8]. One primary objective is to bring services closer to the data source, which is particularly useful for applications that require privacy preservation, such as federated learning [9]. Fog computing is used in various IoT domains, including smart cities and smart grids [2].

Distributed learning is known to cause performances issues when used over a fog computing platform. These challenges include the heterogeneity of devices and networks, that needs a non-negligible effort on the machine selection when placing the services [3].

## 2.3 Service Placement

Research on service placement over fog computing platforms has been widely studied in the literature [10], [11]. Additionally, studies focus on the placement of AI services on Mobile Edge Computing (MEC) platforms or others IoT paradigms [4], [12]. Some of these studies examine the use of hardware accelerators in the Edge-Cloud continuum and demonstrate their importance in the deployment of machine learning services [4], [12]. In [12] the authors propose a placement of functions of AI model across a MEC platform with hardware accelerators. Their objective was to reduce the latency of distributed learning services by mitigating stragglers.

It is important to keep in mind that the local models of each learning service must be updated regularly to avoid concept drift. Therefore, when placing services, it is essential to consider bidirectional communication between the learning services and the aggregation service [4], [12].

[13] shows that using the edge layer is more time- and energy-efficient for federated learning deployment. However, the authors consider the lowest layers of the network to have the same bandwidth and performance as the fog layer, and do not explore multi-layer placement. The state of the literature lacks sufficient approaches to optimize the deployment of contemporary distributed learning applications on a fog computing platform.

## 2.4 Smart Grid

The climate crisis and the desire to improve energy distribution efficiency have led to the development of smart grids. Smart grids introduce intelligence to the electrical network, making it more flexible and resistant to outages. One key benefit of smart grids is their ability to collect data on energy consumption and production. Data is then used to improve energy production and distribution management.

Several studies have evaluated the use of fog computing architecture for organizing smart grid intelligence. Advantages include reduced latency, scalability, confidentiality, security, and energy efficiency [2], [14].

In terms of architecture, various means of communication have been proposed to connect smart grid elements, including power line communication, 5G, and traditional methods such as optical fibers [15]. A case study of the city of Toulouse revealed that the average number of buildings (condominium) per medium-voltage to low-voltage transformers is 3.4 buildings. Moreover, Toulouse has an average of 33.6 apartments per
condominium<fnref n="1" />. This is an indication of the number of equipments in the fog architecture.

# 3 Model

Distributed AI Machine Learning is used through a set of entities that will be called services. These entities will communicate with each other to perform a succession of distributed machine learning rounds, where each round is divided into several phases. Each round begins with a learning phase, during which data is received. This is followed by a computation phase, during which a local model is computed. Finally, an aggregation phase reconstructs a global model. At the end of each round, the global model is distributed to the learning services to improve the model that will ultimately be used for inference. This service chain requires initial modeling, which must be supplemented by modeling the execution platform. Indeed, the latter uses different computing machines interconnected by networks of varying characteristics within the framework of a fog computing architecture. The ultimate goal is to meet the needs of the target application as quickly as possible while ensuring reasonable energy consumption.

## 3.1 Services workflow model

A service $s_j$ is a code execution entity which requires different resources such as CPU, GPU, memory, I/O or network. In the case of distributed AI machine learning, the class $s_j^{cl}$ of a service could be either *Learning*, *Aggregation*, or data *Generation*. Each class of service has its own behavior, as specified earlier.

An execution of a service can be made when the machine hosting the service has the data required to process, this $i^{th}$ execution is called an invocation of a service $s_j$ and is noted $s_j^i$. These invocations will occur over time, involving computations and communications before being completed. The interactions between services form a directed graph called a service workflow. However, succession of invocations creates a directed acyclic graph in which a same service is called several times. This graph is called an invocation trace.

An example of a service workflow containing 3 *Generation* services, 3 *Learning* services and 1 *Aggregation* service is shown in the figure 1a. The figure 1b shows the data exchanges between the service invocations of the trace.

$\mathbb{S}^{inv}$ is the set of all service invocations and $\mathbb{S}^{wf}$ the set of all services. $\mathcal{A}_i$ represents an application, which gathers services at least weakly connected in the service workflow graph. $\mathcal{A}_i \subset \mathbb{S}^{wf}$ and $\mathcal{A}$ being the set of all applications such that $\mathcal{A}_i \in \mathcal{A}$.

A set of properties is defined to extract the characteristics of a service invocation $s_j^i$ and its corresponding service $s_j$:

* $\mathbb{S}^c$ the set of all service classes such that $\forall s_j \in \mathbb{S}^{wf} : s_j^{cl} \in \mathbb{S}^c$.

<footnote n="1">¹Data on French electrical infrastructure and condominium immatriculation from *Agence ORE* and *Agence Nationale de l'Habitat*
www.data.gouv.fr/datasets/postes-de-distribution-publique-postes-hta-bt-1
www.data.gouv.fr/datasets/registre-national-dimmatriculation-des-coproprietes</footnote>
<figure><img src="image_3.png" /><figcaption>Figure 1: Example of a service workflow and its invocation trace</figcaption></figure>

* $s_j^{cops}, s_j^{gops} \in \mathbb{N}$ respectively the amount of CPU and GPU operations to make for each invocation of the service $s_j$. All invocations of a service $s_j$ are supposed to require the same amount of CPU and GPU operations.

* $s_j^{cmem}, s_j^{gmem} \in \mathbb{N}$ respectively the amount of CPU and GPU memory needed by the service $s_j$. All invocations of a service $s_j$ are supposed to require the same amount of memory.

* $data_{j,j'}^{i,i'}$ the amount of data to be sent from the invocation $s_j^i$ to the invocation $s_{j'}^{i'}$ (in Bytes).

* $succ_j^i \subset \mathbb{S}^{inv}$ and $pred_j^i \subset \mathbb{S}^{inv}$ respectively the set of service invocations that are direct successors and predecessors of the invocation $s_j^i$.

* $state^t(s_j^i) \to \{\text{waiting}, \text{ready}, \text{executing}, \text{finished}\}$ the function that for a service invocation returns its state at time $t$. The *waiting* state corresponds to a state in which the service invocation is waiting for its dependencies to be satisfied (i.e. all predecessors are in the *finished* state). The *ready* state is when the service invocation is ready to be executed (i.e. all predecessors are in the *finished* state). The *executing* state indicates that the service invocation is currently being executed, and the *finished* state corresponds to a state in which the service invocation has been executed.

* $sent^t(s_j^i, s_{j'}^{i'}) \to \{\text{true}, \text{false}\}$ the function that returns *true* when a service $s_{j'}$ received the data $data_{j,j'}^{i,i'}$ sent by $s_j^i$, needed for the invocation of $s_{j'}^{i'}$. It is associated with the properties : $state^t(s_{j'}^{i'}) = \text{ready} \implies (\forall s_j^i \in pred_{j'}^{i'} : sent^t(s_j^i, s_{j'}^{i'}) = \text{true})$ and
  $(\forall s_{j'}^{i'} \in succ_j^i : sent^t(s_j^i, s_{j'}^{i'}) = \text{true}) \Leftrightarrow state^t(s_j^i) = \text{finished}.$

* `starttime(s_j^i)` and `invocduration(s_j^i)` the functions that return respectively the moment when the invocation was made (i.e. entered in the *executing* state) and the duration that the invocation has taken to achieve its computations then all its communications. The result of `starttime(s_j^i)` is defined if and only if `state^t(s_j^i) \in \mathbb{N}`.
`{executing, finished}`, and `invocduration(s_j^i)` if and only if `state^t(s_j^i) = finished` at time t.

The makespan can be computed when all service invocations are in finished state at a time t. It corresponds to the last invocation completion time, as defined in equation (1).

$$ makespan = \max_{s_j^i \in S^{inv}} (starttime(s_j^i) + invocduration(s_j^i)) \quad (1) $$

This paper compares algorithms for placing services over a fog computing platform with the objective of minimizing the *makespan*, that is, the time needed to execute all the service invocations of all services from all applications.

## 3.2 Platform model

According to the National Institute of Standards and Technology (NIST), fog computing is the set of computing resources between sensors or effectors and the cloud [8]. In this paper, the first layer is called the mist layer, and contains the least powerful machines. This layer differs from the other two layers of more powerful machines due to its extreme proximity to sensors and effectors, as well as its low computing and memory capacity (e.g. single-board computers). Machines that serve as gateways to the mist layer are called edge machines, as they connect to mist nodes using edge communication technologies, such as 5G. The most powerful machines, called fog machines, constitute the fog layer.

According to [16], a fog based smart grid can be modelized as a 3-level infrastructure, including a layer containing smart meters, a fog layer and a cloud layer. The layer corresponding to smart meters is named smart grid layer in [16], and will be called mist layer in this paper. In [2], the authors have shown that fog machines can be localized in electrical substations. In this paper, each of the mist, edge, and fog layers corresponds to fog computing and smart grid elements. The mist layer corresponds to apartments, homes, and offices where smart meters are located, while the edge layer corresponds to buildings or groups of homes. The fog layer corresponds to electrical substations.

The physical locations of the machines are called localities. A locality contains a set of machines of the same type, i.e. mist, edge, fog or cloud. There is always a unique mist machine in each mist locality. However, as the edge and fog machines form clusters that act as gateways, there can be several either edge or fog machines in the same locality.

We represent a building as either a PLC or 5G network that connects the mist machines (apartments) and the edge cluster gateway. The cluster of machines composing each edge locality acts as a gateway. These gateways connect the bellowing mist localities and their upper fog locality (substation). The fog localities are connected to their bellowing edge localities by dedicated links as a star topology, and fog machines compose gateways between the edge and the cloud. The fog localities are connected to the cloud in a star topology network representing a wide or metropolitan area network.

The number of fog localities is noted $\mathcal{X}$ and the $x^{th}$ fog locality is noted $fogcluster_x$. Each $fogcluster_x$ has a number $\mathcal{Y}$ of edge cluster below and has a dedicated number $\mathcal{Z}$ of mist localities underneath all its $edgecluster_{x,y}$. Further in this paper, the notion of group will be used to represent a set of localities. For example, an edge-mist group is a set of an $edgecluster_{x,y}$ and all the {$mist_{x,y,1}, \dots, mist_{x,y,Z}$} localities below it. Layers differ from groups in that they represent all the machines of a given locality type (i.e.
mist, edge, fog or cloud). We present an overview on how the localities are connected in the figure 2.

<figure><img src="image_4.png" /><figcaption>Figure 2: General topology of a platform</figcaption></figure>

A **machine** is a physically located node in the infrastructure, which contains some computing units (i.e CPU or GPU). Let $\mathbb{M}$ be the set of physical machines. For each $k^{th}$ physical machine in the computing infrastructure, noted $m_k \in \mathbb{M}$, we define the following properties:

* $lay_k \in \{\text{Mist, Edge, Fog, Cloud}\}$ the layer of the machine $m_k$.

* $ram_k^{max}$ the total amount of main memory (RAM) on the machine $m_k$

* $ram_k^t$ the available main memory (RAM) on the machine $m_k$ at the time $t$.

* $U_k$ the set of all computing units of the machine $m_k$.

- $u_{k,l}^{\text{ded}} \in \{\text{true, false}\}$ the boolean that indicates if the $l^{th}$ computing unit has a dedicated memory or uses the RAM of $m_k$ as a shared memory.

- $u_{k,l}^c \in U_k$ the $l^{th}$ computing unit of a machine $m_k \in \mathbb{M}$.

- $u_{k,l}^c \in U_k$ the $l^{th}$ computing unit of a machine $m_k \in \mathbb{M}$.
  - $u_{k,l}^c \in U_k$ the class of the computing unit $u_{k,l}$ with $U_k = \{\text{CPU, GPU}\}$ the set of all classes of computing units.

- $speed_{k,l}^{\text{max}}$ and $mem_{k,l}^{\text{max}}$ respectively the maximum speed and the maximum memory of the computing unit $u_{k,l}$. Please note that $mem_{k,l}^{\text{max}}$ can be equal to $ram_k^{\text{max}}$ if the computing unit shares its memory with the machine to which it belongs.

- $speed_{k,l}^t$ and $mem_{k,l}^t$ respectively the speed and the memory of the computing unit $u_{k,l}$ at the time $t$. If $u_{k,l}^{\text{ded}} = \text{true}$ then $mem_{k,l}^t = ram_k^t$.

- $pcu_{k,l}^{\text{min}}$ the minimum power consumption of the computing unit, $pcu_{k,l}^{\text{max}}$ the maximum power consumption of the computing unit and $pcu_{k,l}^t$ the power consumption of the computing unit at the time $t$.
**Service placement** is the process of assigning a service $s_j$ to some computing units of a machine $m_k$. It is noted $v_{j,k}$ with $v_{j,k} \subset U_k$. The set of all service placements defined at a time $t$ is noted $\mathbb{P}^t$. A service can only be placed on a machine if the machine has enough resources available to execute the service. We suppose that there is no migration of a service already placed.

# 4 Proposed Algorithms

All algorithms in this paper assume that *Generation* services are randomly placed on mist machines before they start. The algorithms aim to place the services of other classes. Indeed, the selection of the data providers are not the subject of this paper, as the data source quality is addressed in dedicated works such as [4].

Functions and variables common to all algorithms are the following:

* `get_allocation(s_j, m_k, t)` returns $v_{j,k}$, an allocation of available units at time $t$ of a machine $m_k$ for the service $s_j$.

* `sort_applications(A)` returns a sorted set of applications. The sorting algorithm is specific to each algorithm.

* `has_resources(s_j, m_k, t)` returns true if the machine $m_k$ has enough resources to host the service $s_j$ at time $t$. It checks the available RAM and GPU memory by verifying whether some GPU units use dedicated memory or share the machine's RAM. If the memory is shared, it is important to account for $s_j^{cmem}$, in order to not allocate more memory than available. It doesn't take cores into account, so it always allows the cores to time-share and run $s_j$.

## 4.1 Most Processing Time First (MPTF) algorithms

The proposed MPTF algorithms consist of placing service by the service with the most processing time first. In the algorithm 1, we propose a Machine-Grouping MPTF (MG-MPTF) algorithm that groups machines as explained in section 3.2. All the machines in the localities constituting the fog layer are in a dedicated group, as well of cloud machines.

The first objective of this algorithm is to be aware of the GPU needs of every service, and to ignore GPUs in machine selection if a service does not need them. The second objective is to place the services of a same application in the same group if possible, so that the services can communicate with each other without going through the network.

The first step is the creation of two sorted lists of machine groups, one for CPUs and one for GPUs. Depending on whether the service requires a GPU, the algorithm uses either the CPU or GPU machine group list to iterate through the groups. While iterating through the groups, the algorithm searches for a machine that is available to host the service, taking into account a time-sharing factor.

Two lists of machine groups are built from the set of machines, with one corresponding to CPU speeds and one to GPU speeds respectively *cpuSortedGroups* and *gpuSortedGroups*. There are two variants of this algorithm that will differ on the sorting order, which will be either by putting the fastest machines first (*FastestFirstMG*)
or the slowest machines first (SlowestFirstMG). In order to sort the machines in all groups of cpuSortedGroups, using the variant order, the machines are compared by the total amount of computation speeds of their computing units corresponding to the CPU class. The groups are then sorted among themselves by the sum of CPU speed of their machines. Then, the gpuSortedGroups is formed by reproducing the same logic but for units of the GPU class.

These two lists of machine groups are obtained using the sort_groups function in lines 4 and 5 of algorithm 1. sort_groups sorts the machines into groups depending on the provided machine set and the computing units class.

The applications are sorted from the one containing the most services to the least. The services in each application Aᵢ are sorted with sort_services(Aᵢ). This function returns a set of services, where services are sorted by their total computational needs index, from the most to the least. The computational needs index of a service sⱼ is defined in equation (2) using the most CPU and the most GPU computationally intensive values among all services in Aᵢ.

$$ \frac{s_j^{\text{cops}}}{\max_{s_j \in A_i}(s_j^{\text{cops}})} + \frac{s_j^{\text{gops}}}{\max_{s_j \in A_i}(s_j^{\text{gops}})} \quad (2) $$

<figure><img src="image_5.png" /><figcaption>Algorithm 1: Machine-Grouping MPTF</figcaption></figure>

The function is_viable(t, tsFactor, sⱼ, mₖ) checks if the machine mₖ has enough memory at a time t, using has_resources(sⱼ, mₖ, t). It also checks if there is enough GPU count and CPU cores to host the service sⱼ, considering a time-sharing factor tsFactor. The time-sharing factor is applied to the number of GPU and CPU cores, allowing the cores to be shared among the services. This factor is incremented each time no machine
<figure><img src="image_6.png" /><figcaption>Algorithm 2: get_first_machine</figcaption></figure>

has enough resources to host the service $s_j$, with a limit of $MAX\_FACTOR$, reaching this limit means that the platform is unsuitable. The intended behavior of this factor is to limit the cores time-sharing in the platform without blocking the placement of the services.

## 4.2 Data and Learning Grouping (DLG) algorithm

The data and learning grouping algorithm (DLG) aims to place learning services the nearest possible from their data provider. In this algorithm, the applications are sorted among them by their total computational needs index, which is the sum of the normalized sums of the CPU and GPU computational needs of their services. The computational needs index of an application $A_i$ is defined in equation (3). As a result, applications are iterated from the one with the most normalized computational needs to the least.

$$ \frac{\sum_{s_j \in A_i} s_j^{\text{cops}}}{\max_{A_{i'} \in A} \sum_{s_j \in A_{i'}} s_j^{\text{cops}}} + \frac{\sum_{s_j \in A_i} s_j^{\text{gops}}}{\max_{A_{i'} \in A} \sum_{s_j \in A_{i'}} s_j^{\text{gops}}} \quad (3) $$

Different functions are used in this algorithm :

* `get_data_gen(s_j)` returns the unique service $s_{j'}$ with $s_{j'}^{cl} = \text{Generation}$ that for each invocation $s_{j'}^{i'} \in \mathbb{S}^{inv}, \exists s_j^{i'} \in \text{succ}_{j'}^{i'}$.

* `get-learning-services(A_i)` and `get-aggregation-service(A_i)` returns respectively the set of learning services and the aggregation service of the application $A_i$.

* `sort-machines(M)` returns a sorted set of the machines of M.

* `get-placement(s_j, t)` returns the machine $m_k$ such that $\exists! v_{j,k} \in \mathbb{P}^t$.

* `get-edge-cluster(m_k)` returns, for a machine $m_k$ in locality $mist_{x,y,z}$, the set of machines in the edge cluster above $m_k$, corresponding to the locality `edgecluster_{x,y}`.
* `try_placing_in_machine_set(s_j, M, t)` returns the first possible placement of the service `s_j` in the set of machines `M` at time `t`, with machines being sorted using `sort_machines`.

The objective of this algorithm is to minimize the communication time by trying to place the learning services as close as possible to their data generation service while placing the aggregation service preferably on the fog layer. Placing the aggregation service on the fog layer aims to limit the model update impact on the slowest networks. While iterating over the applications, the services are placed over 2 phases. The first phase, presented in algorithm 4, places the learning services by considering the data generation service placement location for each learning service. *DLG* first tries to place the learning service on the same machine as its data generation service, if it is not possible, it tries to place it on an upper machine in the topology.

The second phase, as shown in algorithm 5, places the aggregation service, which is placed considering the placement of the learning services. The aggregation service will be preferably placed on the fog machines. The fog locality with the most learning services below it will be selected first and, inside the cluster corresponding to this locality, the fog machine with the fewest services placed on will be preferred. This list of fog clusters sorted by the number of learning services below is noted *layer_fog_groups*.

The machines inside a fog cluster are sorted from the least service placed on using the function `sort_machines(M)`. If no fog machine has enough resources to host the aggregation service, the service is preferably placed inside the mist-edge group that has the most machines. The list of mist-edge groups sorted by the number of machines is noted *mist_edge_groups*. Inside a group, the machines will be iterated over the returned list of `sort_machines(M)`.

<table><caption>**Algorithm 3:** Data and Learning algorithm entry point</caption><tr><td>1</td><td>Function <i>DLG</i>:</td></tr><tr><td>2</td><td>Input: M, S<sup>wf</sup>, t ∈ ℝ<sup>+</sup></td></tr><tr><td>3</td><td>Output: P<sup>t</sup></td></tr><tr><td>4</td><td>P<sup>t</sup> &larr; ∅</td></tr><tr><td>5</td><td>for A<sub>i</sub> ∈ sort_applications(A) do</td></tr><tr><td>6</td><td>&nbsp;&nbsp;&nbsp;&nbsp;P<sup>t</sup> &larr; P<sup>t</sup> &cup; place-learning_services(A<sub>i</sub>, M, t)</td></tr><tr><td>7</td><td>&nbsp;&nbsp;&nbsp;&nbsp;P<sup>t</sup> &larr; P<sup>t</sup> &cup; place-aggregation-service(A<sub>i</sub>, M, t)</td></tr><tr><td>8</td><td>end</td></tr><tr><td>9</td><td>return P<sup>t</sup></td></tr></table>

# 5 Experimental Results

## 5.1 Methodology and Environment

We used a simulation-based methodology to evaluate the proposed algorithms.

The simulator that we used is Batsim[17], which is well-known in the literature. It focuses on resource management and scheduling while taking energy consumption into account, which is why it was a good choice for our experiments.
An experimental campaign comprises a series of experiments that test multiple algorithms across various numbers of service workflows. Each experiment, defined by a specific algorithm and service-count pair, consists of many samples—simulations that share the same algorithm and service count but differ in the randomized properties (e.g., memory consumption) of each service to ensure statistical accuracy. For each sample, randomization of service properties (normal distribution) on the base workflows as specified in the campaign and input files (repeated per workflow) is performed at first. Next, the simulation is run. Using the algorithm, Batsim simulates the service placements on the machines and their invocations. After all samples complete, a post-processing step analyzes network time and energy consumption. Once every experiment finishes, the pipeline aggregates results and generates plots.

1 **Function place-learning-services:**
2 **Input:** $M, A_i, t \in \mathbb{R}^+$
3 **Output:** $\mathcal{P}$
4 $\mathcal{P} \leftarrow \emptyset$
5 **for** $s_l \in \text{get-learning-services}(A_i)$ **do**
6 $s_g \leftarrow \text{get-data-gen}(s_l)$
7 $m_k \leftarrow \text{get-placement}(s_g, t)$
8 $p \leftarrow \emptyset$
9 **if** $\text{has-resources}(s_l, m_k, t)$ **then**
10 $v_{l,k} \leftarrow \text{get-allocation}(s_l, m_k, t)$
11 $p \leftarrow \{v_{l,k}\}$
12 **end**
13 **if** $p = \emptyset$ **then**
14 $\text{edge-cluster} \leftarrow \text{get-edge-cluster}(m_k)$
15 $p \leftarrow \text{try-placing-in-machine-set}(s_l, \text{edge-cluster}, t)$
16 **end**
17 **if** $p = \emptyset$ **then**
18 $\text{fog-machines} \leftarrow \{m_f | m_f \in M \land \text{lay}_f = \text{Fog}\}$
19 $p \leftarrow \text{try-placing-in-machine-set}(s_l, \text{fog-machines}, t)$
20 **end**
21 **if** $p = \emptyset$ **then**
22 $\text{cloud-machines} \leftarrow \{m_c | m_c \in M \land \text{lay}_c = \text{Cloud}\}$
23 $p \leftarrow \text{try-placing-in-machine-set}(s_l, \text{cloud-machines}, t)$
24 **end**
25 $\mathcal{P} \leftarrow \mathcal{P} \cup p$
26 **end**
27 **return** $\mathcal{P}$

<caption>**Algorithm 4:** DLG learning placement phase</caption>

The entire experimental workflow is implemented in Snakemake and executed in a Nix-defined environment (including Snakemake, Batsim, etc.). This environment is fully specified for recursive reproducibility, isolated from the host system, and ensures that results depend solely on the Nix configuration. A single, fixed random-number-generator seed for the entire campaign guarantees deterministic, reproducible outcomes
<figure><img src="image_7.png" /><figcaption>Algorithm 5: DLG aggregation placement phase</figcaption></figure>

and controls random statistical biases.

## 5.2 Baseline algorithms

In order to compare the studied algorithms to naive ones, different algorithms have been implemented. The AllInCloud algorithm places all services in the cloud. The machines are initially shuffled, and the services are placed with a round-robin distribution. If the machine does not have enough resources to host the service, it is skipped. On the other hand, the IoTFirst algorithm shuffles the machines and sorts them by computation speed in ascending or descending order. The services iterate over the machines until they find a machine that has enough resources to host them. There are two variants, which are named according to the sorting order (i.e. FastestIoTFirst and SlowestIoTFirst).

For both algorithms, the services are sorted using the sort_services function from section 4.1. All of these algorithms iterate on the services by starting with the service with the most amount of operations per invocation.

## 5.3 Input Data

The specifications of the machines, in terms of speed (flops for CPU and TOPs for GPU), memory (RAM and GPU memory), and power consumption, are extracted from the manufacturer or from literature specifications. Each cloud machine is composed of 2 AMD EPYC 9654,256 GB of RAM and 8 NVIDIA Tesla A100. The mist machines are Nvidia Jetson Orin Nano (8GB), the edge machines are Nvidia Jetson Orin NX (16GB), and the fog machines are Nvidia Jetson AGX Orin (32GB).

The number of machines per locality is 1 mist machine, 8 edge machines, 8 fog machines, and 1 cloud machine. The minimum power consumption (pmin) of the GPUs
is counted as 0, since we consider that the system can disable the GPU when it is not used. As for the number of localities, there are $\mathcal{X} = 5$ fog localities. There is also an average of $\mathcal{Y} = 3.4$ edge per fog localities, and each edge locality has an average of $\mathcal{Z} = 33.6$ mist localities underneath. The count of cloud localities is 10 (i.e. 10 cloud machines).

The table 1 give an overview of the values used to implement the platform.

<table><caption>Table 1: Machine hardware specifications</caption><thead><tr><th>layer</th><th>Mist</th><th>Edge</th><th>Fog</th><th>Cloud</th></tr></thead><tbody><tr><td><strong>nb. per locality</strong></td><td>(1)</td><td>(8)</td><td>(8)</td><td>(10)</td></tr><tr><td><strong>machine name</strong></td><td>Nvidia Jetson Orin Nano</td><td>Nvidia Jetson Orin NX</td><td>Nvidia Jetson AGX Orin</td><td>N/A</td></tr><tr><td><strong>CPU memory</strong></td><td>8 GB</td><td>16 GB</td><td>32 GB</td><td>256 GB</td></tr><tr><td><strong>CPU count</strong></td><td>1</td><td>1</td><td>1</td><td>2</td></tr><tr><td><strong>CPU cores</strong></td><td>6</td><td>8</td><td>12</td><td>96 × 2</td></tr><tr><td><strong>CPU speed</strong></td><td>9.96 Gflops</td><td>13.28 Gflops</td><td>19.92 Gflops</td><td>3437.8 Gflops</td></tr><tr><td><strong>CPU pmin</strong></td><td>2.89 W</td><td>3.85 W</td><td>5.78 W</td><td>88.67 W</td></tr><tr><td><strong>CPU pmax</strong></td><td>7.28 W</td><td>9.7 W</td><td>14.56 W</td><td>391 W</td></tr><tr><td><strong>GPU memory</strong></td><td>Shared with the CPU</td><td>Shared with the CPU</td><td>Shared with the CPU</td><td>80 GB</td></tr><tr><td><strong>GPU count</strong></td><td>1</td><td>1</td><td>1</td><td>8</td></tr><tr><td><strong>GPU speed</strong></td><td>40 TOPS</td><td>100 TOPS</td><td>200 TOPS</td><td>624 TOPS</td></tr><tr><td><strong>GPU pmax</strong></td><td>15 W</td><td>25 W</td><td>40 W</td><td>300 W</td></tr></tbody></table>

PLC or 5G links are used between the mist machines and their edge gateways. The PLC values are extracted from the Broadcom BCM60500 module presented in [18], along with an energy consumption model. The 5G base-stations corresponds to an indoor RAKwireless All In One 5G base-station. The bandwidth of the 5G links are defined as a 1.25 Gb/s network between the mist machines and their edge locality. The edge localities are connected to their fog locality through an optical fiber link, which uses a Cisco CGP-ONT-1P optical network terminal and a Cisco CGP-OLT-16T optical line terminal. The network between the cloud and fog layers is a wide area network (WAN). Since it is not managed by the smart grid or cloud provider, we do not account for the energy consumption of this part of the network. A Dell PowerSwitch S5200-ON ethernet switch is used to connect the cloud machines between them. A factor of 0.8 is applied to the speeds of the links to account for network loss. The characteristics of the network links are given in the table 2.

<table><caption>Table 2: Network link classes specifications</caption><thead><tr><th>layer</th><th>Type</th><th>Inner port speed</th><th>Outgoing Speed</th><th>Topology</th><th>Power max</th><th>Reference(s)</th></tr></thead><tbody><tr><td>Cloud</td><td>Ethernet Switch</td><td>25 Gb/s</td><td>1.08 Tb/s</td><td>Star</td><td>455 W</td><td>Dell PowerSwitch S5200-ON</td></tr><tr><td>edge to fog</td><td>Optical Fiber</td><td>1 Gb/s</td><td>25 Gb/s</td><td>Star</td><td>66.6 W</td><td>Cisco CGP-ONT-1P with Cisco CGP-OLT-16T</td></tr><tr><td>mist to edge</td><td>5G</td><td>1.25 Gb/s</td><td>2.5 Gb/s</td><td>Star</td><td>55 W</td><td>RAKwireless All In One 5G</td></tr><tr><td>mist to edge</td><td>PLC</td><td>440 Mb/s</td><td>440 Mb/s</td><td>Mesh</td><td>Variable[18]</td><td>[18]</td></tr></tbody></table>

Each service workflow is based on a distributed learning application, based on MobileNetV2 architecture and the CIFAR-10 dataset. This application is used in the literature for smart grid use-cases [19], [20]. We extracted the service properties by measuring the resource usage of the different services of this application when being distributed into 10 Learning services for 1 Aggregation server. The measurements were done using the Gres cluster on the Grid'5000 platform. When measuring a service, it is run on a different machine in the cluster to avoid any interference. The size of the data used to
train the local model at each round was also measured. This corresponds to the data exchanged from a *Generation* service to a *Learning* service.

The size of the data sent by each *Generation* service invocations is set to 49.152 MB. *Learning* services are set to use 3.01 GB of RAM and 1.536 GB of GPU RAM. Each invocation of *Learning* costs 15.47 GFLOPs of CPU and 338.6 TOPs of GPU. The *Aggregation* service uses 1.01 GB of RAM and 694.7 MFLOPs of CPU (FedAvg). The size of the model exchanged by the *Aggregation* and *Learning* services is 8.8 MB. The base service workflow is so composed of 10 *Generation* services, 10 *Learning* services and 1 *Aggregation* service. There are 50 rounds for each application (i.e. 50 invocations for each service).

For the MG-MPTF algorithms (i.e. *SlowestFirstMG* and *FastestFirstMG*), the *MAX FACTOR* value is set to 10.

## 5.4 Results

Algorithm were compared by simulating a variable number of applications.

The number of applications tested is 1, 20, 40, 60, 80, and 100. Since there are 21 services per application, these numbers correspond to a total of 21, 420, 840, 1260, 1680, and 2100 services, respectively. There are 60 samples (simulations) per experiment, and there is an experiment for each algorithm (6) and application number (6). The total number of simulations is $6 \times 6 \times 60 = 2160$.

The figure 3 shows how the metric results vary as the number of services increases. The result metrics are the makespan (3a), the energy consumed by the network (3b), energy consumption by the machines (3c) and total energy consumption (3d). Each point in these plots represents the mean value of a given metric (y-axis) for a particular combination of an algorithm (color) and a number of services (x-axis).

As shown in figure 3a, *DLG*, *FastestIoTFirst*, *FastestFirstMG* and *AllInCloud* algorithms present the best mean makespan results. On the other hand, *SlowestFirstMG* and *SlowestIoTFirst* diverge from the other algorithms, as their respective mean makespans are 29.8% and 41.1% higher than those of *DLG*, *AllInCloud*, *FastestIoTFirst* and *FastestFirstMG*.

As for the energy consumption, the results in figure 3d show that the *DLG* algorithm consumes the least total energy (network and machines), with a mean energy consumption 1.9 times lower than the second lowest algorithm, *FastestIoTFirst*. *FastestFirstMG* tends to consume less energy as the number of applications increases, but it is still 2.9 times more energy consuming than *DLG*. With respectively 5.2 times and 6.1 times more energy consumed than *DLG*, *SlowestIoTFirst* and *SlowestFirstMG* are the most energy consuming algorithms when reaching 2100 services (100 applications).

A more detailed view of the energy consumption of the network and machines in figure 3b and figure 3c shows additional insights. It appears that *DLG* and *AllInCloud* energy consumptions are mainly due to the machines (i.e. 76.9% and 74.7% for 2100 services). The other algorithms consume more energy in the network with 60.2% for *FastestIoTFirst*, 66.7% for *FastestFirstMG*, 68.9% for *SlowestIoTFirst* and 78.4% for *SlowestFirstMG*.

It seems that the *DLG* algorithm is able to reduce the network energy consumption by placing *Learning* services preferably with the *Generation* ones, and the *Aggregation* service upper in the topology (meaning faster networks). In contrary, *SlowestFirstMG* aims to regroup the *Learning* and *Aggregation* services of an application as close as possible to
<figure><img src="image_8.png" /><figcaption>Figure 3: Mean makespan, links energy, machine energy and total energy for each algorithm and number of services.</figcaption></figure>

each other, discarding the location of the *Generation* services. The results demonstrate the feasibility of efficiently deploying distributed learning services on a fog computing platform at the smart grid scale. However, this is possible when the service placement algorithm focuses on reducing the transfer time of learning data and model exchange, as *DLG* does. The *DLG* algorithm significantly outperforms others in terms of platform energy consumption, particularly with regard to network energy. *DLG* also reduces the makespan to the level of *AllInCloud*, which uses faster computational machines.

# 6 Conclusion and Future Work

In this paper, we focus on the problem of placing distributed learning services in a fog computing platform adapted to AI and scaled for smart grids.

We presented a model for the placement of distributed learning services, as well as a model for a smart grid-dimensioned fog computing platform. A set of algorithms was also proposed to minimize the makespan, and indirectly, the energy consumption of the machines and network, when placing the services.

We evaluated the proposed algorithms using a simulation-based methodology and a large number of samples. The results demonstrate that network usage inherent to distributed machine learning significantly impacts energy consumption, and that *DLG* is able to greatly reduce the energy consumption while not sacrificing the makespan. Future work may focus on replacement strategies for services in cases where machines become unavailable due to failure.

# Acknowledgement

This work was supported by the French State through the National Research Agency (ANR) under the France 2030 program, reference 22-PETA-0004 - AI-NRGY project.
Experiments presented in this paper were carried out using the Grid'5000 testbed, supported by a scientific interest group hosted by Inria and including CNRS, RENATER and several Universities as well as other organizations (see https://www.grid5000.fr).

## References

[1] Z. Zhou, X. Chen, E. Li, L. Zeng, K. Luo, and J. Zhang, "Edge Intelligence: Paving the Last Mile of Artificial Intelligence With Edge Computing," *Proceedings of the IEEE*, 23.2, vol. 107, no. 8, pp. 1738-1762, Aug. 2019, ISSN: 0018-9219, 1558-2256.

[2] S. Zhao et al., "Smart and Practical Privacy-Preserving Data Aggregation for Fog-Based Smart Grids," *IEEE Transactions on Information Forensics and Security*, vol. 16, pp. 521-536, 2021, ISSN: 1556-6021.

[3] S. Hosseinalipour, C. G. Brinton, V. Aggarwal, H. Dai, and M. Chiang, "From Federated to Fog Learning: Distributed Machine Learning over Heterogeneous Wireless Networks," *IEEE Communications Magazine*, vol. 58, no. 12, pp. 41-47, Dec. 2020, ISSN: 0163-6804, 1558-1896.

[4] N.-E.-H. Yellas, B. Addis, S. Boumerdassi, R. Riggio, and S. Secci, "Function Placement for In-network Federated Learning," *Computer Networks*, vol. 256, Jan. 2025, ISSN: 13891286.

[5] S. Shi, Q. Wang, and X. Chu, "Performance Modeling and Evaluation of Distributed Deep Learning Frameworks on GPUs," in *2018 IEEE Intl Conf on Dependable, Autonomic and Secure Computing, Intl Conf on Pervasive Intelligence and Computing, Intl Conf on Big Data Intelligence and Computing and Cyber Science and Technology Congress (DASC/PiCom/DataCom/CyberSciTech)*, Aug. 2018.

[6] Z. Zou, Y. Jin, P. Nevalainen, Y. Huan, J. Heikkonen, and T. Westerlund, "Edge and Fog Computing Enabled AI for IoT-An Overview," in *2019 IEEE International Conference on Artificial Intelligence Circuits and Systems (AICAS)*, Hsinchu, Taiwan: IEEE, Mar. 2019, pp. 51-56, ISBN: 978-1-5386-7884-8.

[7] Y. Hu, Y. Liu, and Z. Liu, "A Survey on Convolutional Neural Network Accelerators: GPU, FPGA and ASIC," in *2022 14th International Conference on Computer Research and Development (ICCRD)*, Jan. 2022, pp. 100-107.

[8] M. Iorga, L. Feldman, R. Barton, M. J. Martin, N. S. Goren, and C. Mahmoudi, "Fog Computing Conceptual Model," Michaela Iorga, Larry Feldman, Robert Barton, Michael J. Martin, Nedim S. Goren, Charif Mahmoudi, Tech. Rep., Mar. 2018.

[9] S. Yi, C. Li, and Q. Li, "A Survey of Fog Computing: Concepts, Applications and Issues," in *Proceedings of the 2015 Workshop on Mobile Big Data*, New York, NY, USA: Association for Computing Machinery, Jun. 2015, pp. 37-42, ISBN: 978-1-4503-3524-9.

[10] C. Liu, J. Wang, L. Zhou, and A. Rezaeipanah, "Solving the Multi-Objective Problem of IoT Service Placement in Fog Computing Using Cuckoo Search Algorithm," *Neural Processing Letters*, vol. 54, no. 3, pp. 1823-1854, Jun. 2022, ISSN: 1573-773X.
[11] O. Skarlat, M. Nardelli, S. Schulte, and S. Dustdar, "Towards QoS-aware Fog Service Placement," May 2017.

[12] Z. Lin, S. Bi, and Y.-J. A. Zhang, "Optimizing AI Service Placement and Resource Allocation in Mobile Edge Intelligence Systems," *IEEE Transactions on Wireless Communications*, vol. 20, no. 11, pp. 7257-7271, Nov. 2021, ISSN: 1558-2248.

[13] S. M. Rajagopal, S. M., and R. Buyya, "FedSDM: Federated learning based smart decision making module for ECG data in IoT integrated Edge-Fog-Cloud computing environments," *Internet of Things*, vol. 22, p. 100784, Jul. 2023, ISSN: 25426605.

[14] S. Zahoor, N. Javaid, A. Khan, B. Ruqia, F. J. Muhammad, and M. Zahid, "A Cloud-Fog-Based Smart Grid Model for Efficient Resource Utilization," in *2018 14th International Wireless Communications & Mobile Computing Conference (IWCMC)*, Jun. 2018, pp. 1154-1160.

[15] M. Saadatmand, b. ramezy, and B. Mozafari, "Review of Communication Technologies for Smart Grid applications," Oct. 2017.

[16] F. Okay and S. Ozdemir, "A fog computing based smart grid model," May 2016.

[17] P.-F. Dutot, M. Mercier, M. Poquet, and O. Richard, "Batsim: A Realistic Language-Independent Resources and Jobs Management Systems Simulator," in *20th Workshop on Job Scheduling Strategies for Parallel Processing*, May 2016.

[18] W. Bakkali, P. Pagani, and T. Chonavel, "Experimental Analysis and Modeling of Energy Consumption Behaviour for MIMO PLC Modems," in *2015 IEEE Global Communications Conference (GLOBECOM)*, Dec. 2015, pp. 1-5.

[19] J. Huang and Q. Wan, "Smart grid line fault detection based on deep learning image recognition algorithm," *International Journal of Low-Carbon Technologies*, vol. 19, pp. 2174-2180, Jan. 2024, ISSN: 1748-1325.

[20] R. Zhao et al., "A Federated-Learning Algorithm Based on Client Sampling and Gradient Projection for the Smart Grid," *Electronics*, vol. 13, no. 11, p. 2023, Jan. 2024, ISSN: 2079-9292.