Reactive adaptation waits for QoS to break
IoT applications in smart spaces must hold strict Quality of Service (QoS) targets, such as low latency, high availability, and accuracy, while the environment keeps shifting: device counts change, network conditions fluctuate, and computational resources vary. The paper's motivating example is a large-scale smart city during a concert or sports game, where thousands of visitors cause a surge in demand for real-time traffic management, public safety surveillance, and smart parking, producing network congestion and resource bottlenecks at Edge servers.
The paper argues that existing self-adaptive IoT solutions mostly rely on reactive measures and monitor QoS metrics such as network congestion and resource utilization. Because adaptation decisions are often based solely on changes in QoS metrics, these systems tend to act after a violation appears rather than anticipating it. The paper also notes that most prior adaptation logic is tailored to specific application domains, which limits reuse and requires domain expertise.
Causal graphs define which variables to observe
CRAFTER treats causality as a formal framework for analyzing IoT system performance. At design time it takes an IoT metrics dataset, which can be realistic historical monitoring data or synthetic data generated with digital twin or ML-based techniques, and runs causal discovery to produce a causal graph. The paper uses the Causal-Learn Python library with the Peter-Clark (PC) algorithm and Kernel-based Conditional Independence testing to generate the graph in DOT format.
The graph separates two variable sets. The paper defines mu_context as day of the week, time of the day, and number of visitors, and mu_qos as bandwidth, resource allocation, and resource consumption. In the smart museum causal graph, bandwidth allocation, resource allocation, and resource consumption are direct causes of response time, while day and time are direct causes of response time because they also drive fluctuations in visitor numbers. Location acts as an indirect cause, since visitor distribution across halls varies with the popularity of artifacts and paintings.
Context variables enable preemptive adaptation actions
The causal graph changes what the adaptation agent observes. In existing approaches the state space is usually modeled on mu_qos, such as network link congestion, data traffic, and resource consumption. CRAFTER instead defines the RL state set using mu_context, including location, number of occupants, day, and time, while the action set covers available adaptations such as bandwidth and resource allocation.
This lets the agent act on leading indicators rather than lagging symptoms. In the Le Louvre scenario, a higher number of occupants raises the workload on processing nodes. Once that relationship is learned, the agent can monitor occupant count and reconfigure resources as it rises, instead of waiting for processing nodes to become overloaded and produce higher latency or data loss. The paper describes this as preemptive adaptation that reduces the likelihood of QoS violations.
The reward penalizes over-allocation of resources
CRAFTER's reward function is designed to minimize the deviation between each application's QoS requirement and the latency it actually experiences. The formula weights each application by a priority term phi_i, and adds penalty terms c1 and c2 for bandwidth and resources allocated in the system, so that the agent does not simply over-provision to satisfy latency.
This matters because the paper frames adaptation as a trade-off rather than a pure latency minimization problem. The reward is defined over the set of applications in A, and the deviation term compares the latency defined by the application's QoS requirements against the actual latency perceived by that application. The paper's museum setup includes five representative application types with latency QoS requirements ranging from 20 ms for the Metaverse application to 2 s for artifact maintenance.
Causal states improve learning efficiency over SOTA-RL
The paper's headline quantitative result is that CRAFTER improves self-adaptation performance by 25% compared to state-of-the-art Reinforcement Learning-based approaches. The training curve in the paper compares SOTA-RL, CRAFTER-Context Only, and CRAFTER-Mixed across episodes, with reward value plotted against episode number.
The paper attributes this gain to the causal graph reducing the state space and improving convergence. It also states that causal graphs let the agent identify and act on the key factors that lead to degradation, rather than reacting only when QoS metrics change. The 25% figure is reported as a performance improvement over state-of-the-art RL approaches used for self-adaptation, and the paper's discussion repeats this number as the main experimental result.
Causal graphs transfer across three IoT domains
To test whether the approach generalizes beyond the museum, the paper evaluates CRAFTER on three different real-world datasets spanning different IoT use cases: an Autonomous Moving Robot (AMR) scenario with network throughput and latency requirements, a smart factory scenario involving a copper production manufacturing plant with energy consumption requirements, and an anomaly detection scenario.
The paper presents this as evidence that CRAFTER can derive causal graphs across diverse IoT use cases with minimal domain expertise. The design-time pipeline accepts regular CSV datasets collected from monitoring platforms and does not require additional processing or labeling, though the paper notes that enriching the dataset with context information such as date, time, device location, and occupant counts produces richer causal graphs and better adaptation actions.
Dataset quality and simulation bound the claims
The paper's limitations section states that CRAFTER depends on IoT performance metrics datasets for causal discovery, so the quality, diversity, and representativeness of the collected data directly affect the accuracy of the generated causal graph. If important variables are missing, poorly measured, or insufficiently varied, the causal model may be incomplete or biased, and fully mitigating data sparsity and hidden confounders remains challenging in complex real-world deployments.
Two further limits qualify the results. Causal discovery algorithms are known to face scalability issues as the number of variables and dataset size grow, and large-scale smart environments with thousands of devices may require dimensionality reduction, hierarchical causal modeling, or incremental causal discovery that are not yet integrated into CRAFTER. The evaluation also relies primarily on emulated environments and realistic datasets, so a sim-to-real gap may exist in production IoT systems, particularly for safety-critical or latency-sensitive applications. The paper additionally notes that the current implementation does not explicitly enforce safety constraints during exploration.
What the 25% gain actually measures
The most decision-relevant number in this paper is the 25% improvement over state-of-the-art RL-based self-adaptation, but its meaning depends on the setup that produced it. The museum evaluation generated 1,560 different system configurations by varying bandwidth from 20 Mbps to 500 Mbps per location and the percentage of resources allocated to virtual sensors from 10% to 100%, across each day of the week except Tuesday and across morning and evening periods, with weekend days being the most crowded.
For readers comparing adaptation approaches, the paper's specific claim is narrower than a general statement about causality in IoT. The gain is measured against RL-based self-adaptation baselines in emulated environments, and the causal graph's value comes from defining the RL state set with context variables rather than QoS metrics alone. The paper's own framing is that this is the first work to leverage Causal RL through an automated pipeline to analyze key causes of QoS violations in dynamic IoT systems and take tailored adaptation actions, which sets the comparison target as prior RL-based self-adaptation rather than self-adaptation in general.
Sources used in this answer
CRAFTER: Causality-based Self-adaptation for Autonomous IoT Systems
CRAFTER generates causal graphs to identify context and QoS variables that drive IoT performance, then uses them to define the state space of a reinforcement learning adaptation agent, reporting a 25% improvement in self-adaptation performance over state-of-the-art RL-based approaches.