## 4 An Architecture for Edge-Fog-Cloud Offloading
The delegator invokes the job expiry mechanism only after its own job queue is exhausted and a steal attempt fails, ensuring efficient resource utilisation while preventing indefinite delays. This proactive design lends itself for more opportunism as the availability and resourcefulness of each worker is unknown a priori, and subject to change any time [6]. For example, a worker's availability can be impacted if/when a worker node receives a call while it is participating in task execution, or if its location changes due to the owner moving away. This process continues until the pool is exhausted, or until a worker disconnects. The resource discovery threads are periodic; hence, potential workers can join at any point in time. ### Upper and Lower Bounds for Speedup

In this section, extending previous work in Honeybee [6], we formulate theoretical upper and lower bounds to analyze the best- and worst-case speedup scenarios within a device-enhanced edge-fog-cloud computing architecture. We assume that a given edge-fog-cloud computing environment consists of \(x\) P2P edge nodes, including the delegator, \(y\) fog workers, and \(z\) cloud workers, where \(x,y,z\) are non-negative integers. Let us denote each node in the device-enhanced edge layer as \(n_{e_{i}}\), where \(1\leq i\leq x\). The delegator is denoted as \(n_{e_{1}}\). Each fog worker is denoted as \(n_{f_{j}}\), where \(1\leq j\leq y\), and each cloud worker is denoted as \(n_{e_{i}}\), where \(1\leq l\leq z\). The time taken to complete \(m\) jobs on the delegator \(n_{e_{1}}\) is denoted as \(t_{e_{1}}\). The time taken for an edge worker \(n_{e_{i}}\) to receive, complete, and return results for \(m\) jobs is denoted as \(t_{e_{i}}\), where \(i>1\). Hence, the relative computational power of an edge worker \(n_{e_{i}}\) compared to the delegator \(n_{e_{1}}\) can be given as:

\[\frac{t_{e_{i}}}{t_{e_{1}}}=k_{e_{i}} \tag{1}\]

Similarly, the time taken for a fog server \(n_{f_{j}}\) to complete and return results for \(m\) jobs is denoted as \(t_{f_{j}}\), and for a cloud server \(n_{c_{i}}\) as \(t_{c_{i}}\). The relative computational powers of fog and cloud workers compared to the delegator \(n_{e_{1}}\) can be represented by constants \(k_{f_{j}}\) and \(k_{c_{i}}\), respectively:

\[\frac{t_{f_{j}}}{t_{e_{1}}}=k_{f_{j}} \tag{2}\]

\[\frac{t_{c_{i}}}{t_{e_{1}}}=k_{c_{i}} \tag{3}\]

The parameters \(k_{c_{i}}\), \(k_{f_{j}}\), and \(k_{c_{i}}\), introduced in Equations (1), (2), and (3), respectively, serve as indicators of the relative efficiency of task execution by worker nodes in comparison to the delegator. Specifically, a value of \(k<1\) signifies that the worker node, be it within the edge, fog, or cloud tier, can process and return the results of the assigned tasks more expediently than the delegator performing the same tasks in a monolithic manner. This computational advantage highlights the potential benefit of offloading tasks to worker nodes with \(k<1\). Conversely, a value of \(k\geq 1\) suggests that task offloading may not yield substantial speedups, as the worker node does not demonstrate a computational speed advantage over the delegator. Even when \(k>1\), indicating a worker's lower computational power compared to the delegator, offloading can still enhance overall performance. This improvement arises because the delegator and workers operate concurrently, increasing total system throughput. Essentially, the collective output of all computing nodes, despite individual limitations, can contribute to achieving speedup. Thus, the decision to offload tasks should consider the system-wide contribution, highlighting the importance of a holistic approach in optimising the edge-fog-cloud architecture's efficiency. It is important to note that the relative computational power indicators \(k_{\epsilon_{i}}\), \(k_{f_{f}}\), and \(k_{\epsilon_{i}}\) are assumed to be constant for the purposes of this theoretical analysis. This simplification is intended to provide a tractable baseline for deriving upper and lower bounds on speedup.