Within this section, we begin by exploring the mobility model of fog nodes, delving into the handover and migration processes involved as fog nodes move. Subsequently, we introduce the M2One policy and our computation-offloading strategy and elaborate on the developed offloading algorithm.
3.1. Mobility Model
This paper delves into the realm of fog node and IoT device mobility. The mobility of IoT devices primarily impacts request generation. As long as a mobile IoT device resides within the designated area, the tasks it generates are routed to the existing fog nodes within that area. When an IoT device departs from the area, it has no bearing on the functionality of the fog environment.
Fog node mobility holds significant importance as these nodes are responsible for processing generated tasks. Any fog node leaving the area without appropriate request management can threaten the system’s reliability. Consequently, it is imperative to develop a model for fog node mobility within this context; therefore, we propose a simple model for the mobility of fog nodes. This model divides each layer into domains where a single IoT application is implemented. The mobility of fog nodes is just considered for the first-tier fog nodes. It is not far from reality because the fog nodes located in the upper tiers (e.g., cloudlets, base stations) are stronger in computing power and storage capability and usually have a fixed location.
According to the stated assumptions, we can consider two types of movement for mobile fog nodes: in-domain movement and off-domain movement. Limited energy resources on IoT nodes mandate low-power and short-range wireless technologies (e.g., BLE, ZigBee); hence, their domain is limited to the distance they can cover, and in-domain movement does not lead to disconnection. Off-domain movement causes problems for the IoT node, which has sent its requests directly to the off-domain fog node, and the requests are offloaded to the off-domain fog node by neighbouring fog nodes. To mitigate disconnection problems, we considered an area called the
boundary area around the domain. This area comprises about 30% of its corresponding domain. The boundary area and mobility procedure are depicted in
Figure 2. A mobile fog node will likely leave the domain when it enters the boundary area. Hence, the handover process and migration process begin to avoid missing the requests that already exist in the off-domain fog node.
The handover process involves finding a new fog node for the IoT node directly connected to that off-domain fog node. As depicted in
Figure 2, in Step (1), the IoT node stops sending requests to that off-domain fog node, and then, in Step (2), it starts a new interaction with a fog node in the domain.
The migration process involves moving a copy of existing requests in the queue of the off-domain fog node to a new fog node in the domain (Step (3) in
Figure 2). At this time, neighbouring nodes stop offloading new requests to that off-domain fog node, but existing requests are processed at that off-domain fog node until they leave the boundary area. When that off-domain fog node leaves the boundary area, the fog node that has received the copy of requests starts processing them.
3.2. M2One Policy: A Fog Node Collaboration Policy
In this section, we introduce the M2One policy in which fog nodes collaborate to handle the requests sent from IoT nodes. The M2One policy manages in a many-to-one scenario where all IoT nodes of a specific application offload their requests to one fog node called the coordinator fog node. In other words, in each domain of fog nodes, there is a central node responsible for managing and deciding where to process requests. The first node of the things-to-cloud continuum that receives requests sent from IoT nodes is selected as the coordinator fog node in our scheme. This decision is made based on the fog nodes’ computing power, queuing delay, transmission and propagation delay, channel status, and the battery life of the mobile fog nodes. The list of notations that have been used in this section is detailed in the Abbreviation section.
Offloading algorithm: In the proposed policy, we assumed there are j fog nodes , , …, , and one of them is the coordinator fog node (). As the fog network manager, the coordinator fog node knows the network topology. It records fog nodes’ location (), fog nodes’ computing power (), and the mobility status of fog nodes in a table, which is called the Coordinator Fog Node (CoFN) table. The coordinator fog node also adds a cloud to its table in case fog nodes cannot fulfil the request objectives (for instance, when fog nodes lack sufficient computing capacity or necessary memory to process a request prior to the deadline). The information in this table is updated when a fog node leaves/enters the domain or a mobile fog node changes its location.
We assumed there are m IoT nodes in the network. These IoT nodes generate i requests , , …, . Each request sent from an IoT node m () contains the ID, the location of the IoT node that generated the request (), the type of request that can be heavy () or light (), the length of request in bit (), the needed computational resource (), and the deadline (). The requests that can be divided into several sub-tasks are considered heavy; otherwise, they are light. The CoFN table information and data are utilised when deciding which fog node to offload a request for processing. Algorithm 1 describes the process of selecting an appropriate node for offloading.
In the first step, the needed computational resources of request (
) are compared with the computing power of all fog nodes (
) of the CoFN table. The fog nodes that can fulfil
are added to the
selected nodes list (Lines 4–6). Then, for all selected nodes, the estimated serving time (
) is calculated (Lines 7–8) based on Equation (
1).
Algorithm 1 M2One: Proposed Offloading Policy |
- Require:
{ID, , Type, , , } - Ensure:
Selected node for offloading ()
- 1:
function OffloadingPolicy() - 2:
Add all fog nodes to CoFN Table - 3:
Add Cloud to CoFN Table - 4:
for all in CoFN Table do - 5:
if ≥ then - 6:
Add to Selected-Nodes - 7:
for all in Selected-Nodes do - 8:
Calculate - 9:
if ≥ then - 10:
Remove from Selected-Nodes - 11:
Sort Selected-Nodes list - 12:
Select two nodes with minimum - 13:
Remove two selected nodes from Selected-Nodes list - 14:
for all node in Two-Selected-Nodes do - 15:
if Is it mobile then - 16:
Calculate - 17:
Calculate RSSI - 18:
if OR then - 19:
Remove this mobile node - 20:
else - 21:
Calculate RSSI - 22:
if RSSI ≤ then - 23:
Remove this node - 24:
if Two-Selected-Nodes list is empty then - 25:
go to (12) - 26:
else - 27:
Return node with the least
|
Estimated serving time: The estimated serving time is the required time for serving
in
.
is a function of the required time to send
from the coordinator fog node (
) to
(
) and the required time to process
in
(
). For simplicity, the required time to send back a response to the IoT node has been omitted in the equations.
is the sum of the transmission delay (
) and propagation delay (
). It is obtained by Equation (
2).
is the channel bit rate between
and
;
is the distance between
and
;
v is the speed of light.
is the sum of the required time to wait in the
queue (
) and the required time to execute
in
(
) and is calculated by Equation (
3).
and
are calculated by Equations (
4) and (
5), respectively.
is the number of light requests in the
queue;
is the number of heavy requests in the
queue;
is the execution time of the running request (
). The running request runs in
when an offloaded request
arrives.
After calculating for all fog nodes, two fog nodes that have met the deadline and have the shortest serving time are selected (Lines 9–13). If the selected node is a mobile fog node, its battery life and channel status are checked (Lines 14–19). Otherwise, the channel status is just checked (Lines 20–23). The battery life is checked based on the remaining energy consumption of each mobile fog node, and the channel status is checked based on the Received Signal Strength Indicator (RSSI). The fog node will remain in the two_selected_nodes list if its and RSSI are greater than the threshold that has been considered for each case. Finally, the node with less is selected as the destination of offloading.
Energy consumption of mobile fog node: The battery life of the mobile fog nodes is a limiting factor in the offloading strategies. Therefore, it is necessary to check the battery status of the mobile fog nodes before offloading requests to them. In this way, we can be sure that the mobile fog node will remain active until the end of the computation. For this purpose, in the M2One policy, a threshold is considered for the remaining energy of the mobile fog nodes (
).
is compared with estimated energy (
) (Line 19), and the node that can fulfil the energy requirement will remain in the
two_selected_nodes list.
is the remaining energy in
after processing
. It is a function of the needed energy for queuing requests’ execution and transmission,
, as well as the execution and transmission energy of the running request
, denoted as
and
, respectively, as described in Equations (
6) and (
7).
is the initial energy of the mobile fog nodes before offloading
to them.
is the required energy to execute
in
.
is the required energy to transmit the response from
to
.
is the power consumption of
when
is executing. It is different for light and heavy requests.
is the transmission power.
RSSI: The received signal strength indicator indicates the signal power of a message received by a node. The proposed offloading policy channel status is checked for the first-tier fog nodes because these nodes usually use low-power wireless communication protocols, which are more vulnerable to noise. The channel status of the selected node is calculated by Equation (
9) and, then, compared with a threshold value (
).
In Equation (
9),
n is the path loss exponent, which varies depending on the environment,
d is the distance between the transmitting and receiving devices, and
A is the signal strength received from a node located at a reference distance. In Equation (
10),
is the transmission power and
is the path loss at a reference distance (
).