Page 19 - ITU Journal Future and evolving technologies Volume 2 (2021), Issue 5 – Internet of Everything

ITU Journal on Future and Evolving Technologies, Volume 2 (2021), Issue 5

(a) if the VF ̂ which can be hosted by a CN or cloud
does not exist in p, then terminate placement;
(b) Otherwise repeat steps 1) − 4).

The pseudocode of the VFs planning strategy is detailed
in Algorithm 3.

Algorithm 4 SRs Allocation Planning
1: until all the SRs are not allocated repeat
2: for each unallocated SR do
3: builds its preferences on and proposes to its fa‑

vorite element in ;

4: end for
5: for each computation site do
6: acceptstheSRrequiringtheVFtypewiththemore
stringent deadline; Fig. 3 – SP revenue by varying communication rounds, considering 100
7: updates the corresponding queuing time; SRs and 20 VFs
8: end for
9: end repeat

4.4 SRs allocation planning
The designed SRs allocation policy is based on the match‑
ing theory principles [47, 48], and consider the EUs’ per‑
spective. In order to better explain this point, it is impor‑
tant to highlight that the SRs allocation strategy is based
on metrics which do not consider the SP revenue, but only
the EUs’ interests. In this regard, the two parts involved
in the matching are the SRs and the computational sites,
referred hereafter, for each SR , as . The set of the com‑

putational sites may be different for diverse SRs since,
given the SR , consists of the CNs which contain the VF

requested by and of the cloud, if this containsthe desired Fig. 4 – MSE by varying the time prediction horizon for type 1 SRs
VF. Each SR expresses the preference in being matched,
6. repeat steps 2) − 6) until all the SRs are allocated.
i.e., in being computed, with each element of and vice

versa. The SRs aim at minimizing their own TSA de ined Algorithm 4 explains in more detail the SRs allocation
as in (7), hence they prefer to be executed on computa‑ planning procedure.
tional sites which lower (7). By contrast, the computa‑
tional sites prefer SRs requiring VFs with stringent dead‑ 5. NUMERICAL RESULTS
line requirements.
Therefore, the matching algorithm consisting of a mod‑ The proposed FL‑based framework has been tested by re-
sorting to numerical simulations in the Tensor low en‑
i ied version of the Gale‑Shapley [47] algorithm can be
vironment. We supposed an IoE scenario consisting of
summarized through the following steps
= 3 CNs, equipped with a CPU frequency equals to
1. Each SR builds its preference on the elements be‑ 2.4 GHz, while the cloud has been equipped with a CPU
longing to ; frequency equals to 4.6 GHz. Furthermore, we set = 70

and = 120.
2. Each SR , proposes to be computed on its most pre‑ The VFs required by SRs have been modeled in a similar
ferred computational site; way as in [39, 49, 50], and we considered the presence
of two priorities, corresponding to the set MovieLens 1M
3. Each computational site, among the received compu‑
dataset [51] and MovieLens 100K dataset [51], respec‑
tational proposals, accepts the SR requiring the VF
tively. We modeled 10 VFs, each of which needs a number
type with the closest deadline, and discards the other
of SRBs uniformly distributed in [50, 80]. All the FL net‑
proposals;
work hyperparameters and the neural architecture have
4. Update queuing time on each CN; been assumed to be the same as those in [39]. Each SR
has been modeled as a number of 64 bits format instruc‑
5. Update preferences of the unallocated SRs; tions uniformly distributed in [250, 800], needing 8 CPU

© International Telecommunication Union, 2021 7