Every spawned task can be handled three ways, and the simulator picks whichever minimises a weighted cost of time and energy — this is the classic mobile-edge-computing (MEC) offload decision:
Local: T = C / f_dev E = κ · C · f_dev²
Radio: R = B · log2(1 + SNR) (Shannon capacity)
T_tx = 8D / R E_tx = P_tx · T_tx
Edge: T = T_tx + C/f_edge + t_edge E = E_tx
Cloud: T = T_tx/η + C/f_cloud + t_cloud E = E_tx/η
Cost = α · (T / 1s) + (1-α) · (E / 1J)
- C — task workload in CPU cycles; f — clock frequency. Compute energy grows with f² (dynamic voltage/frequency scaling), so a faster local CPU finishes sooner but burns disproportionately more energy per task.
- R — the wireless link's achievable bit rate, from the Shannon-Hartley limit on bandwidth B and signal-to-noise ratio; a weak link makes offloading slow no matter how idle the servers are.
- t_edge / t_cloud — fixed propagation + queueing delay (a few ms to the edge node on the local network, tens of ms round-trip to the distant cloud backbone) — this is the "distance costs latency" idea from IoT Edge architectures.
- η — a backbone-congestion factor that further throttles the effective cloud data rate compared with the short hop to the edge.
- The α slider re-weights the decision: push it toward energy to favour whichever path drains the least battery, or toward latency to favour whichever finishes fastest, exactly as a real edge-orchestration policy would.
This is the same trade-off Azure IoT Edge, AWS Greengrass and similar platforms manage automatically: cheap, low-latency tasks stay local or on the nearby edge gateway; heavy tasks with a good link get offloaded to the edge; only tasks that tolerate the extra round-trip (or need cloud-scale compute) go all the way to the cloud.