Page 22 - ITU Journal Future and evolving technologies – Volume 2 (2021), Issue 2

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

distributed controllers are implemented in fog‑enabled includes a decision manager that computes the comple‑
vehicles and base stations to ensure fast and ef icient tion time of a task and assigns the task to the required
handover. Handover decision should be kept local thus it sub‑layer which also includes a resource manager. This
important to implement the proposed SDN architecture solution relies entirely on the supposition that there will
in fog enabled devices that only respond to events taking always be a gathering of smart vehicles with enough com‑
place in their vicinity. putational power and resources to operate as fog devices
in high‑traf ic area; however, that is not always the case.
Kapsalis et al. [32] presented a cooperative model, Currently, the ratio of smart vehicles to the regular ones
a fog architecture where the tasks to be completed by is not signi icant, thus a group of parked vehicles might
the nodes are characterized by their computational not be a considerable source of computational resources.
characteristics and are assigned to the appropriate host
subsequently. The model consists of different layers Besides, Bruschi et al. [34] also proposed a frame‑
including a hub layer, device layer, fog layer, and cloud work that leverages fog computing, SDN and NFV
layer. The Device layer includes actual physical devices capabilities to respond to the necessity of bringing
that have small computational power and low storage, services to the edges and make them more accessible
the hub layer contains gateways and is in charge of cre‑ to users to reduce latency during service provision, and
ating fog messages and forwarding them to the fog layer reinforce the personalization of services. The proposed
acting as mediator, the fog layer includes the computing framework operates by considering three main stake‑
edges that function in collaborative way to execute tasks holders including CSPs, telecommunication operators,
and the cloud layer provides a guaranteed execution and end users; it includes several functional blocks and
environment to the tasks. The proposed solution allows interfaces to allow future cloud applications to perform
fog networks to be optimal in executing time critical ef iciently and provide more than standard services, and
tasks. It integrates into edge computing architectures, enable end users and telecommunication operators to
the communication between devices in edge networks bene it by providing application services. Its architecture
via the MQTT messaging protocol and the inclusion of leverages tools such as OpenVolcano, which manages
nearby access points or mobile edges in a collaborative functionalities of the data plane and control plane associ‑
way for speci ic types of tasks, to allow better ef iciency, ated with real‑time analytics, an external controller that
coverage and QoS. However, this solution omitted to take provides decisions on the long‑term.
into account some cases where the expected participa‑
tion of some edge devices cannot be guaranteed. To add additional support to user mobility, allow
service differentiation and help applications achieve
To enhance the scalability of fog‑computing and aug‑ seamless service provision in the MEC environment,
ment its computational power and storage power in Bruschi et al. [35] presented a policy regarding virtual
mobile cloud computing, Sookhak et al. [33] proposed object clustering and migration; the proposed policy
a fog architecture‑based solution called Fog Vehicular takes into consideration end users proximity, and in‑
Computing (FVC). In this solution, it is suggested that a volves a parameter of the subscription‑based proximity
pool of parked smart vehicles can be used as a source ranging to enable service differentiation between users.
of computing resources, referred to as FVC zone. The The authors considered a network of fog‑hosted virtual
maximum capacity of an FVC zone is determined from the objects with a variety of proximity distances and re‑
predicted need of computational power and resources in quirements where an individual user belongs to a given
the area. The FVC architecture has three main layers, the set of virtual objects. User proximity is computed and
policy management layer, the application and services classi ied in different levels according to the different
layer and the abstraction layer. The application and requirements and subscription‑based parameters; vir‑
services layer is responsible for providing real‑time tual objects clustering is performed according to their
applications to end users according to collected data inter‑af inities, which are classi ied in different levels,
from the deployed sensors in the inertial navigation and are merged based on the maximum path lengths and
system; it provides services such as information and proximity levels; after the merging of different clusters,
entertainment as a service, network as a service, storage C clusters and their corresponding minimum proximity
as a service and entertainment as a service. The policy requirements are obtained. The next step involves cluster
management layer allocates appropriate computation migration, in which quality of service is maintained while
and storage resources to different tasks, deals with issues the end user moves from one location to another as some
such as monitoring the system state dynamically, and of the proximity requirements are no longer met; thus,
includes policy, fog, and vehicular cloud. The abstraction migrations are performed based on user’s previous and
layer protects the security and privacy of data; It conceals new locations, access point time, and shortest path length
the FVC heterogeneous platform and reveals a monotonic from the device. This solution is however limited due to
interface for monitoring, delivering, and maintaining the fact that multiple af inity levels and computational
the physical resources, such as memory, processor unit, power and capabilities of different access points and data
and networking. FVC’s architecture’s decision process centers were not considered.

8 © International Telecommunication Union, 2021