Design and Analysis of Algorithms

The Internet of Vehicles (IoV) has emerged as a key enabling technology for intelligent transportation systems by supporting a wide range of latency-sensitive and computation-intensive applications, including autonomous driving, intelligent navigation, cooperative perception, and real-time traffic management. To satisfy the stringent latency and computational requirements of these applications, Mobile Edge Computing (MEC) extends cloud computing capabilities by deploying computational resources closer to vehicles. By offloading computation-intensive tasks to nearby edge servers, MEC significantly reduces communication latency, improves response time, and alleviates network congestion. However, the highly dynamic nature of vehicular networks, limited edge resources, and the possibility of edge server failures make reliable task execution a challenging problem. Therefore, designing efficient task offloading and resource allocation strategies that ensure reliable service execution while maintaining high system performance has become an important research direction in IoV-enabled edge computing.

The Internet of Vehicles (IoV) supports numerous computation-intensive and latency-sensitive applications, such as autonomous driving, cooperative perception, intelligent transportation, and real-time video analytics, many of which can be represented as Directed Acyclic Graphs (DAGs) due to their task dependency relationships. To support the timely execution of these applications, Mobile Edge Computing (MEC) provides computational resources at the network edge, enabling tasks to be processed closer to vehicles and reducing communication latency. However, dynamic vehicle mobility, heterogeneous edge resources, fluctuating queue conditions, and complex task dependencies make efficient scheduling and task offloading increasingly challenging. Consequently, designing intelligent queue-aware DAG scheduling, task offloading, and resource allocation mechanisms has become essential for improving application performance and efficiently utilizing edge computing resources in IoV environments.

Mobile Edge Computing (MEC) has become a key paradigm for supporting latency-sensitive and computation-intensive applications by bringing computational resources closer to end users. Efficient task offloading and resource allocation are fundamental to improving application performance and resource utilization in such environments. Existing studies have proposed various optimization strategies that allocate computational and communication resources based on the current system state, aiming to reduce task completion delay, energy consumption, or operational cost. While these approaches achieve good short-term performance, they generally focus on immediate scheduling decisions and do not explicitly consider how current resource allocation affects future resource availability, queue evolution, and overall system performance over time.

Resource allocation is one of the most fundamental challenges in edge computing, cloud computing, and distributed systems, where limited computational and communication resources must be efficiently allocated to dynamically arriving tasks. Existing resource allocation strategies primarily aim to optimize performance metrics such as task completion delay, energy consumption, throughput, or overall resource utilization. These approaches have significantly improved system efficiency by allocating resources according to task requirements and system conditions. However, most existing methods implicitly assume that all tasks contribute equally to the overall system performance, focusing primarily on efficient resource usage rather than the actual benefit generated by executing different tasks. In many practical applications, tasks often have varying levels of significance, making resource allocation based solely on traditional performance metrics insufficient for achieving optimal system effectiveness.

Task placement and resource allocation play a critical role in improving the performance of distributed edge computing systems by determining where tasks should be executed and how computational resources should be assigned. Existing approaches typically estimate task resource requirements and make scheduling decisions based on current system conditions or predicted workload characteristics. These methods have demonstrated significant improvements in reducing application completion time and improving resource utilization. However, most existing algorithms assume that task execution characteristics remain relatively stable throughout execution and rarely adjust scheduling decisions according to actual runtime behavior. In dynamic computing environments, execution performance can vary due to changing workloads, resource contention, and system interference, causing static resource allocation decisions to become suboptimal. Consequently, there is a need for resource management strategies that continuously adapt task placement and resource allocation based on real-time execution feedback to maintain efficient system performance.

In an IEEE 802.15.4 DSME network, a coordinator that needs more transmission capacity can turn a nearby Contention Access Period (CAP) into an extended Contention-Free Period (extCFP), giving itself extra Guaranteed Time Slots. TaCFPext makes this decision in a purely local way — a node only checks its own one-hop neighbors before converting a CAP. That works fine in a small, single-cluster network, but real industrial deployments are rarely that simple. They span multiple hops, multiple coordinators, and sometimes multiple PANs, all sharing the same limited pool of CAPs and channels. If two coordinators that are two hops apart both decide, independently and at the same time, to convert the same CAP into an extCFP, their schedules collide — exactly the kind of failure TaCFPext was designed to prevent. This is the multi-hop coordination gap Objective 1 addresses.

TaCFPext only starts converting a CAP into an extended CFP after a node has already failed to allocate a GTS three consecutive times. That means the mechanism is purely reactive — by the time it kicks in, some packets have already been delayed or dropped, and the extGTS negotiation itself takes time to complete. In a genuinely bursty environment, a few superframes of “catching up” after every burst onset is exactly the window where TaCFPext’s own reported gains get eaten away. This objective replaces that fixed, after-the-fact trigger with a predictive one, so the node starts reserving extra capacity before the failure happens rather than after it.

TaCFPext borrows a nearby CAP whenever a single node’s traffic suddenly bursts, but it never questions the skeleton it is operating inside. The three parameters that define that skeleton — macSuperframeOrder (SO), macMultiSuperframeOrder (MO), and macBeaconOrder (BO) — are fixed once at network start-up (3, 5, and 6 in the original paper’s simulation) and never revisited for the rest of the network’s life. TaCFPext’s extCFP mechanism only ever works within that fixed structure. This is fine for short-lived, node-level bursts, but it says nothing about what happens when the entire network’s traffic shifts for good — for example, when more sensors join, or a process line moves from idle monitoring into continuous production. In that case, TaCFPext just keeps patching individual bursts node by node, even though the real problem is that the baseline CAP/CFP split itself has become the wrong size for the network.

STREAM-E ranks GTS requests by traffic class and a packet-rate/buffer-occupancy score, so a Critical-traffic sensor generally gets served before a Normal one. But priority ranking only solves contention — it reorders who gets a slot first, it doesn’t create a slot that doesn’t exist. If the CFP is genuinely full, a Critical or Delay-driven request can still be dropped no matter how high its priority is, because there’s simply nowhere left to put it. STREAM-E has no answer for this situation; it assumes reordering the queue is always enough. This objective gives the coordinator a way to respond when priority alone isn’t sufficient, using only DSME’s own standard, already-defined parameters — not anything borrowed from outside STREAM-E’s own design.