Unlocking AIoT efficiency in the computing continuum - the PANDORA framework

Unlocking AIoT Efficiency in the Computing Continuum - the PANDORA framework Georgios Bouloukakis1,2, Ajay Kattepur3, Dusan Jakovetic4, Alexandros Iosifidis5, Konstantinos Tserpes6, Maria Pateraki6 [email protected],ajay[email protected],dusan.jakov[email protected] [email protected],{tserpes,mpateraki}@mail.ntua.gr 1Department of Electrical and Computer Engineering, University of Patras, Greece 2Telecom SudParis, Institut Polytechnique de Paris, France 3Ericsson Research Artificial Intelligence, India 4Dept. of Math. and Informatics, Faculty of Sciences, University of Novi Sad, Serbia 5Faculty of Information Technology and Communication Sciences, Tampere University, Finland 6National Technical University of Athens, Greece Abstract As Internet of Things (IoT) and IoT-Edge-Cloud continuum technologies evolve, physical environments are increasingly embedded with sensors, driving the development of smart space ecosystems. The vast amounts of data generated by IoT devices are transforming how these ecosystems function through the integration of AI models and algorithms. This convergence has given rise to Artificial Intelligence of Things (AIoT) systems. Designing robust, efficient, and continuously operating AIoT systems generally depends on access to realistic, trustworthy data and innovative strategies for training and inference at runtime. This article presents PANDORA, a comprehensive framework for delivering trustworthy datasets in smart space ecosystems and supporting the deployment and operation of AIoT systems. PANDORA implements novel AI-as-aService (AIaaS) and Compute-as-a-Service (CaaS) components to ensure robust, explainable, and continual AIoT system operation. A prototype implementation of PANDORA is provided, along with a real-world pilot case demonstrating its applicability. CCS Concepts •Computing methodologies → Machine learning approaches; •Computer systems organization → Distributed architectures;•Networks →Cyber-physical networks. Keywords AIoT systems, IoT-Edge-Cloud continuum, AIaaS, CaaS ACM Reference Format: Georgios Bouloukakis 1,2 , Ajay Kattepur 3 , Dusan Jakovetic 4 , Alexandros Iosifidis 5 ,, Konstantinos Tserpes 6 , Maria Pateraki 6 . 2025. Unlocking AIoT Efficiency in the Computing Continuum - the PANDORA framework. In The 15th International Conference on the Internet of Things (IOT 2025), November 18–21, 2025, Vienna, Austria. ACM, New York, NY, USA, 9 pages. https: //doi.org/10.1145/3770501.3770525 This work is licensed under a Creative Commons Attribution 4.0 International License. IOT 2025, Vienna, Austria ©2025 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-1595-2/25/11 https://doi.org/10.1145/3770501.3770525 1 Introduction Artificial Intelligence (AI) and data engineering technologies are now at the forefront of research and industrial innovation [ 7 ], serving as key enablers of digital transformation across application domains such as smart buildings, smart manufacturing, and critical infrastructures. With the rise of the Internet of Things (IoT) and the computing continuum (IoTâĂŞEdgeâĂŞCloud), vast volumes of IoT data are continuously generated, processed, and maintained to address strategic challenges in industrial contexts. This data serves as a vital driver for AI advancement and a foundational element for global economic development [ 2 ]. AI systems must effectively manage and process data from IoT devices within IoTâĂŞEdgeâĂŞCloud to extract value, thereby enabling smarter, more efficient, and responsive systems for critical operations and infrastructure management. Artificial Intelligence of Things (AIoT) refers to the integration of AI capabilities with IoT infrastructure, enabling intelligent decision-making, automation, and optimization across interconnected devices and systems. AIoT systems and their associated services and applications rely on large-scale, real-world data to improve accuracy, robustness, and sustainability. However, the availability of such data is limited due to high deployment costs [ 13 ], labor-intensive data collection, incomplete coverage of relevant scenarios, and concerns over confidentiality and vulnerability disclosure. Moreover, even with accurate training, AIoT systems require novel architectures for managing AI models’ lifecycle, selecting AI models, and deploying them to adapt to the dynamic nature of smart spaces and computing continuum resources. To overcome these limitations, researchers often rely on offline modeling and ML techniques to address data scarcity, but these struggle with domain gaps, semantic variability, and the complexity of dynamic environments [ 3 , 5 , 6 ]. Concerning the adaptation of an AIoT system to dynamic spaces, existing approaches rely on intent-driven AI model management and deployment using AI-as-a-Service (AIaaS) and Compute-as-a-Service (CaaS) architectures [ 12 , 14 , 18 , 20 , 22 , 23 ]. Nevertheless, even if prior to AIoT system deployment excellent work is done with respect to proper data modelling and pre-processing, the overall system must account for continual changes, un-modelled phenomena, and exhibit robustness to such behaviors at runtime. IOT 2025, November 18–21, 2025, Vienna, Austria Bouloukakis et al. Figure 1: PANDORA runtime architecture This article presents PANDORA 1 , an AI-based framework aimed at enhancing data-driven AIoT systems both at design-time and runtime. PANDORA design-time focuses on preparing trustworthy datasets for training AI models 2 . In this article, an AIoT application refers to a pilot deployment within a smart space (e.g., building, factory), designed to provide services to end-users. PANDORA runtime ensures the autonomous, continuous, and efficient operation of AIoT applications through a suite of AIaaS and CaaS components, improving both latency and energy use. The remainder of this paper is organized as follows: Section 2 presents the detailed architecture of PANDORA runtime, as well as the prototype implementation of its core components: the Intent Manager, AIaaS, and CaaS. In Section 3, we illustrate PANDORA’s applicability through Ericsson’s Research AIoT application. Section 4 reviews related work, comparing existing solutions and emphasizing the unique strengths of our approach. Finally, Section 5 summarizes the key findings and suggests directions for future research. 2 The PANDORA Framework: Architecture and Prototype Implementation PANDORAâĂŹs main goal is two-tiered: (i) reproduce customizable and trustworthy datasets for model training and testing for AIoT application deployment (PANDORA design-time); and (ii) support AIoT deployment as well as continual, energy-efficient and robust AIoT operation via a series of AIaaS and CaaS components (PANDORA runtime). Nevertheless, due to space constraints, we assume that datasets provided for training in phase 2 are trustworthy (realistically represent the IoT environment). Thus, this article focuses on the PANDORA runtime architecture and implementation. Figure 1 provides the high-level architecture of PANDORA runtime. In detail, PANDORA proposes the following components: (1) 1https://pandora-heu.eu 2 In PANDORA, trustworthy datasets are introduced to realistically represent the smart environments in which AIoT systems are deployed. However, the methodology for creating these datasets is beyond the scope of this paper. AI Model Registry; (2) AI life-cycle management; (3) Data Collection Mechanism; (4) AI model selection; (5) AI model (re)training; and (6) AI inferencing. The AI model selection component includes already trained models to be used in AIoT applications for AI inference. PANDORA introduces an intent-driven approach for selecting trained models that match the requirements provided by domain administrations or AIoT application end-users. Such intents may relate to, e.g., power consumption of the infrastructure, inference response times, etc. Intents are handled via the Intent Manager. The AI life-cycle management component monitors the AI model to check for errors in terms of accuracy levels, energy violations, etc. This component may act as follows: (i) it selects another AI model; (ii) it triggers the AI model training component (see below); or (iii) it may provide feedback for the customization of the dataset provided at design-time and thus, re-train the same model. While AIoT systems operate in real-time, both AI model training and AI inference components offer novel strategies for privacy preserving, efficient and robust AIoT systems, based on provided intents. Details regarding training and inference strategies are considered future work. To ensure efficient deployment and continual operation of AIoT systems, PANDORA proposes the development of components related to CaaS. Smart space ecosystems employ resources in the IoT-Edge-Cloud continuum where AIoT applications can be deployed based on the provided intents. The CaaS Performance Estimator estimates metrics related to power consumption, latency, etc., in a chosen compute node or set of nodes. Each of the PANDORA runtime components is designed considering the computing continuum infrastructure, and it is implemented at an appropriate infrastructure level of the IoT-Edge-Cloud continuum, considering the energy, storage, and movement costs. 2.1 Intent Manager component Intents represent the formal requirements and constraints that a managed system must fulfill [ 4 ]. Unlike imperative approaches, intent-based management adopts a declarative paradigm, specifying what outcomes are desired rather than how to achieve them. The PANDORA framework IOT 2025, November 18–21, 2025, Vienna, Austria Intents focus on defining objectives without detailing the specific actions or solutions required for their realization. An intent may describe a particular goal along with related contextual details. It should be both human-understandable and machine-interpretable to ensure unambiguous processing. A machine-readable format enables automated configuration and decision-making, particularly in systems involving AI agents. Intents define the target metrics to be achieved, not the methods for achieving them. This abstraction frees consumers from implementation details while granting producers the flexibility to explore alternative strategies and optimize performance. The expectations conveyed by an intent are agnostic to system implementation, technology, and infrastructure. To ensure verifiability, intents must be quantifiable based on system data, allowing for fulfillment to be measured and evaluated. Intents can be categorized based on user roles or management scenarios. They are especially valuable for managing and controlling closed-loop automation, where an intent defines goals that are translated into policies and management tasks executed by the Management Service producer within the loop. In its simplest form, a consumer may use an intent to express the need for: an object 𝑂with characteristics 𝑆 , where the characteristics 𝑆 reflect the requirements, goals and contexts for an object. However, a consumer may need to specify distinct requirements, goals, and contexts for objects with different properties. In such cases, it is necessary to differentiate the expectations for each group of objects sharing the same properties. The combination of these requirements, goals, and contexts for each group constitutes an Intent Expectation. Additionally, when a consumer wishes to distinguish the requirements, goals, and contexts for individual objectsâĂŤeven those with identical propertiesâĂŤeach object instance may be assigned a separate Intent Expectation. Alternatively, the expectations for multiple instances can be combined into a single Intent Expectation [4]. For a given intent expectation, the desired characteristics of the object define the expectation targets to be achieved. These targets may include specific performance metrics or abstract indicators representing the object’s behavior. An intent expectation can specify multiple expectation targets, either for a single object or for different objects sharing the same properties. For example, a consumer may require the network to achieve User throughput > 5 Mbps and latency < 1 ms . Expectation targets may also be context-specific, meaning the intent applies only under particular conditions or environments. When characteristics are defined as a combination of expectation targets and corresponding target contexts, the intent expectation can be formally expressed as: 1ensure that for 2Expectation Object O, 3Expectation Target_1 is T_1 , 4Target Context_1 is C_1 5âĂę., 6Expectation Target_m is T_m , 7Target Context_k is C_k; Each expectation target represents a specific aspect of the desired characteristics of the object under consideration. It defines the required attributes for a given object, specifying that each characteristic should either match a specific value or be constrained Figure 2: PANDORA Intent Manager. within a particular range, as illustrated in Table 1. A target is thus defined by the combination of the characteristicâĂŹs name, the condition constraining it, and the corresponding value or value range. Table 1: Intent Expectation Examples Expectation Obj. Expectation target Condition Value Circuit Board Memory Utilization Is less than 70% Comm Service Average Throughput Is greater than 2𝑀𝑏𝑝𝑠 AI Model Model Accuracy Is greater than 80% To automate the process of accepting intents and analyzing issues across multiple industrial use cases, the intent management component is used within PANDORA at runtime. As seen in Figure 2, the Intent Manager (IM) consists of sub-components such as a user interface, knowledge base, issue generator and goal mapper. For a particular use case, the intent owner (actor) can provide requirements to be met. These intents can be in standardized formats such as those specified by 3GPP [ 1 ]. The intents are interpreted using the domain knowledge artifacts within the knowledge base. Furthermore, based on the current data from the use case environment, the issue generator determines the issues between the current state and the required state (specified by the intent). For instance, if the current temperature reading is 50 𝑜𝐶 and the required state is 40 𝑜𝐶 , these goals will be communicated as targets to the connected AIaaS. In addition to business goals, the intent manager also maps the requirements of the AI model needed to address the issue. These targets may include AI model accuracy, inference time, and energy efficiency. Such requirements are utilized by the AIaaS component when selecting the most suitable model for inference. Intent Specification. Business intents represent the requirements AIoT applications in a formal manner. We base our intent representation on 3GPP specifications [1] with artifacts presented below: –intentExpectations : it describes the expectations including requirements, goals and contexts (including constraints and filter information) given to a system. It states the list of specific outcomes desired to be realized for expectation object(s). –expectationId : a unique identifier of the intentExpectation within the intent. –expectationVerb : it describes the types of intentExpectations. Examples of verbs and their related types of expectation are: (i) DELIVER : delivery Intent Expectation, e.g., provision of a network for a service. (ii) ENSURE : AssuranceIntentExpectation, e.g., ensure the target performance value. IOT 2025, November 18–21, 2025, Vienna, Austria Bouloukakis et al. –expectationTargets : it describes the list of ExpectationTarget(s) which represent specific outcomes on the metrics characterizing the performance of the object(s) to be realized for a given intentExpectation. –targetName : name of the expectation target representing specific outcomes on the object(s) performance. –targetCondition : it expresses the limits within which the targetName is supposed to be. The allowed values include: IS EQUAL TO, IS LESS THAN, IS GREATER THAN, IS WITHIN RANGE, IS OUTSIDE RANGE, IS ONE OF, IS EQUAL TO OR LESS THAN, IS EQUAL TO OR GREATER THAN, IS NOT ONE OF, IS ALL OF. –contextAttribute : it describes characteristics of the system to which the expectation should apply or an attribute related to the operating conditions of the object (e.g., weather conditions, load conditions, etc.). Context conditions have similar notations to targetCondition. –observationPeriod : it represents the observation period for the corresponding ExpectationTargets, IntentExpectations and Intents. At the end of the observation period, the corresponding fulfillment info is updated in the intent report. The observation time is expressed in seconds. In Section 3, we define user intents for a real-world AIoT application based on the specifications outlined above. 2.2 AIaaS component The proliferation of AI deployments has brought in new challenges within AI model hosting, efficient training, inferencing and lifecycle management. To meet these challenges, the concept of AIaaS has emerged [ 22 ]. This can be requested on end-applications, intermediate IoT devices or the network. Rather than locally hosting and maintaining ML models, these devices offload the management of AI/ML models to the AIaaS. Several industrial applications can benefit from such a service. For example, robots operating on a factory floor require object detection and inference capabilities. Instead of executing AI models locally, sensor data can be transmitted in real time to an AIaaShosted model for inference. Autonomous driving scenarios similarly rely on integrating and inferring from diverse data sources, including on-board sensors, traffic signals, nearby vehicles, and geolocation data. Given privacy concerns and computational constraints, hosting and managing these models centrally via AIaaS offers a more efficient solution. Emerging 5G/6G use cases also demand autonomous network reconfiguration. For instance, during a surge in users streaming high-definition video, the network must detect anomalies, allocate resources, and adapt accordingly. AI agents responsible for such decisions are managed by the AIaaS platform, enabling dynamic control of network resources. Figure 3 represents the main sub-components within AIaaS. Superior training or the use of multiple models can be achieved through various learning paradigms, such as continual learning and federated learning. The resulting models may vary in performance metrics, including accuracy, inference time, and robustness. These models are stored in an AI Model Registry, along with metadata detailing their performance. Based on the business and AI-related intent goals provided by the intent manager, the AI model selection Figure 3: PANDORA AI-as-a-Service (AIaaS). Figure 4: PANDORA AIaaS Interactions. component identifies the most suitable model. The selected model is then deployed by the AI model inferencing component onto available compute resources provisioned by CaaS. The inference results are subsequently used to reconfigure the AIoT application to address the specified intent. Another key component in Figure 3 is the AI model lifecycle management component. Utilizing real-time data collected during PANDORA’s runtime, this component monitors for distribution shifts in the input data. Detected shifts can be used to update model accuracy estimates and may also trigger re-training processes to maintain or improve model performance. Figure 4 further elaborates on the interactions within AIaaS. There are four parties involved in this service: The AIaaS-consumer, the AIaaS-provider, the AIaaS components and compute resources. The AIaaS requester may be humans, enterprise devices, or machines, which generate raw data requiring processing, such as AI inference. These consumers offload sensing data and specify requirements (e.g., accuracy, completion times). The resulting inference outputs can then trigger actuations. The AIaaS provider acts as an interface to the AI models, responsible for monitoring and optimally selecting models to meet consumer requirements. Key AIaaS components include a registry of pre-trained models, an AI inferencing engine, and lifecycle management. Metadata on model accuracy and performance is stored in the AI model repository. The AI lifecycle manager detects performance drifts and initiates model The PANDORA framework IOT 2025, November 18–21, 2025, Vienna, Austria re-training. For inference deployment, CaaS nodes host the model inferencing processes. To trigger the use of AIaaS, the following initial conditions must be met: (i) The AIaaS requester lacks sufficient compute, memory, or storage capacity to perform AI model inference locally. For example, a 5G-enabled robot requiring high-accuracy AI-driven object detection may not have adequate on-board resources. (ii) The AIaaS provider hosts pre-trained models on similar datasets that satisfy accuracy and inference requirements. These models are continuously monitored for deviations from their target performance. Once these pre-conditions are satisfied, the following steps are followed to provide the compute service: (1) The AIaaS requester submits a request for AI model inference along with associated constraints, which may include accuracy requirements or deadlines for timely completion. (2) The AIaaS provider selects the optimal model from the available trained models, potentially balancing weighted trade-offs. (3) The data is dispatched to the selected model using the CaaS resources. (4) AI inferencing is completed and returned to the AIaaS provider. (5) The processed output is forwarded to the AIaaS consumer to perform actuation. Offloading AI management via AIaaS offers several benefits. The elapsed time from task generation to output is reduced compared to local processing, while energy consumption on the device is minimized. Model deviations are automatically updated without requiring local monitoring. Additionally, models can be continuously trained on new datasets to enhance inference capabilities. AIaaS Prototype Implementation. One of the primary components within AIaaS is a registry or repository of trained models. To implement the PANDORA registry, we use MLflow 3 , an opensource platform that focuses on lifecycle management of ML models. The MLflow Model Registry offers a centralized, structured system to organize and govern ML models throughout their lifecycle. It enables effective updating of model versions, experiments, and metadataâĂŤcritical for efficient model selection and lifecycle management. As seen in Table 2, an MLflow Model can be registered with the Model Registry. A registered model has a unique name and includes versions, aliases, tags, and other metadata. Each model can have one or more versions. During an experiment run, different modelsâĂŤsuch as XGBoost, Random Forest Regression, and Linear Regression can be trained. Metrics including accuracy, inference time, and training time are recorded. These models can be queried and selected appropriately during runtime. In addition, MLflow exposes APIs, as shown in Table 3. API access is vital for AIaaS, enabling other components to interact with model registries, inference strategies, and metadata. For example, the runs/create API initiates a new experimental run; registered-models/update manages model names and descriptions; and model-versions/get-download-uri provides a URI to download a specific model. Another key consideration is model selection, a fundamental step in deploying ML modelsâĂŤespecially in real-world settings where computational efficiency and adaptability are critical. We propose a graph-based approach to select appropriate models based on AI intent thresholds such as accuracy and inference time. 3https://mlflow.org Table 2: MLFlow Model Features. Field Name Description name Unique name for the model. creation_timestamp Timestamp recorded when this registered_model was created. last_updated_timestamp Timestamp recorded when metadata for this registered_model was last updated. user_id User that created this registered_model NOTE: this field is not currently returned. description Description of this registered_model. latest_versions Collection of latest model versions for each stage. Only contains models with current READY status. tags Tags: Additional metadata key-value pairs for this registered_model. aliases Aliases pointing to model versions associated with this registered_model. Table 3: MLFlow APIs. API endpoint Description /runs/create Create a new run within an experiment. A run is usually a single execution of a machine learning or data ETL pipeline. /runs/log-metric Log a metric for a run. A metric is a key-value pair (string key, float value) with an associated timestamp. Examples include the various metrics that represent ML model accuracy. experiments/set-experiment-tag Set a tag on an experiment. Experiment tags are metadata that can be updated. /registered-models/update Name and description of a registered model. /model-versions/get-download-uri Get URI for model version download. A Directed Acyclic Graph (DAG) is constructed with benchmarked models as nodes, accuracy and inference constraints represented as edges. A greedy search algorithm is applied, where each node evaluates its neighboring nodes to determine if the current model has higher inference time and mean squared error. The following code snippet illustrates this greedy search approach, which aims to find the best trade-off between model accuracy and inference time: 1# Evaluate the condition for each neighbor 2if eval (condition , {"mse": mse , "infe": inference_time}): 3neighbor_mse = model_performance [ neighbor ][" mse "] 4neighbor_inference_time = model_performance [ neighbor ][" inference_time "] 5 6# Greedy step: choose the model with the lowest MSE and inference time 7if neighbor_mse < best_mse and neighbor_inference_time < best_inference_time: 8best_neighbor = neighbor 9best_mse = neighbor_mse 10 best_inference_time = neighbor_inference_time We notice that different models may be selected based on accuracy or inference time. Additional AI intent thresholds such as energy or model re-training may also be specified within the selection process. 2.3 CaaS component With increasing demand for compute-intensive tasks such as object detection, imaging, localization and knowledge gathering being performed on IoT devices, there is an increasing need to offload compute requirements to other devices. To meet these requirements, IOT 2025, November 18–21, 2025, Vienna, Austria Bouloukakis et al. Figure 5: PANDORA Compute-as-a-Service (CaaS). Figure 6: PANDORA CaaS Interactions. Compute-as-a-Service has been proposed in [ 9 ]. CaaS can be used by multiple types of devices (IoT, mobile handhelds, robots) to delegate resource-intensive processing tasks to network connected compute nodes. These compute nodes may be resources onboard devices (Edge), or on the communications infrastructure (Fog) or remote cloud servers. CaaS can be particularly useful for processing AI-intensive workloads in industrial settings. For instance, with path planning and obstacle detection of AGVs through real-time offloading of collected sensor data to also reduce battery consumption. Offloading Augmented-Reality sensor data to meet the Quality of Experience such as low-latency of the device. Collating multiagent sensing information in a central server to produce a central knowledge graph. As seen in Figure 5, the AIaaS component provides training and inference requirements to the CaaS component. CaaS is responsible for deploying the models on available edge, fog or cloud computing resources. In order to map the requirements to compute resources, techniques such as benchmarking, QoS modeling or statistical analysis will be used. In order to learn the efficient mapping between AI requirements and compute resource allocation, techniques such as reinforcement learning [ 10 ] or AI planning [ 24 ] will be employed. Nevertheless, the design and development of these techniques is part of future work. This article describes the sub-components and workflows involved in CaaS (Figure 6). The service involves three main entities: the CaaS consumer, the CaaS provider, and the compute resources. CaaS consumers may include humans, enterprise devices, or machines. These consumers generate raw data that requires processing (e.g., AI inferences). To meet performance needs, they can offload computations along with specific requirements (e.g., compute capacity, completion deadlines). Once processed, the results may trigger actuations. The CaaS provider acts as an interface to the compute resources, responsible for monitoring resource availability and selecting an optimal subset to meet consumer demands. A variety of devices can function as compute nodes: edge devices (e.g., robots, IoT devices, on-premise compute units), fog devices (e.g., routers, switches, gateways across 5G networks), and cloud nodes located remotely. Trade-offs among these resources include differences in compute power, energy efficiency, and latency. Before invoking CaaS, certain preconditions must be met. The CaaS requester must lack sufficient compute, memory, or disk capacity to perform the required computation. For example, a 5G-enabled robot may need high-accuracy, AI-driven object detection that exceeds its on-board computing capabilities. Meanwhile, the CaaS resource provider maintains a registry of compute nodes across the IoT-Edge, Fog, and Cloud layers. These nodes are continuously monitored for available capacity and existing workloads. The following steps are followed to provide the compute service: (1) The CaaS requestor specifies the required compute capacity along with associated constraints, which may include trust, geographic location, or deadlines for completing the computation. (2) The CaaS provider leverages current resource availability and an optimization mechanism to select the most suitable compute node. For parallelizable tasks, multiple nodes may be allocated to enable distributed computation. (3) The workload is deployed on selected nodes by the CaaS provider. (4) The computation is completed and the result is returned to the CaaS provider. In some cases, failure of an assigned node may trigger re-deployment to ensure task completion. (5) The processed output is forwarded to the CaaS consumer to perform actuation. Offloading computation via CaaS offers several potential benefits. It reduces the total elapsed time from task generation to output compared to local processing. Energy consumption on the device side is minimized, and network-based compute resources are utilized more efficiently. 3 Demonstrating PANDORA’s Applicability: 5G-connected robot path-planning system To demonstrate the interactions between various components of PANDORA, we implement an industrial 5G connected robotic AIoT application in Ericsson’s premises. An autonomous robot is deployed in a dynamic environment and must navigate from start to goal location, while avoiding obstacles. The robot uses path planning techniques to ensure (i) speed, (ii) specific 5G throughput/latency observed, and (iii) collision with obstacles prevention. Intents guide the robot to maintain 5G throughput and latency thresholds during path planning. Intents Definition. Using the specifications defined in Section 2, an example of the relevant business intents is provided below: 1Intent: 2id: '5G_App_Intent' 3... 4expectationTargets: 5targetName: 'Average_Network_Throughput ' 6targetCondition: 'IS_GREATER_THAN ' 7targetValueRange: 20 8targetName: 'Average_Network_Latency ' 9targetCondition: 'IS_LESS_THAN ' The PANDORA framework IOT 2025, November 18–21, 2025, Vienna, Austria 10 targetValueRange: 30 11 - targetName: 'Battery_utilization ' 12 targetCondition: 'IS_LESS_THAN ' 13 targetValueRange: '70' 14 observationPeriod : 60 15 intentReportReference : 'AIoT_App_Intent_Report ' The expectation targets (lines 4-13) provide thresholds on average network throughput, average network latency and robot battery utilization. The IM continuously checks for these intent targets and can generate issue goals towards the AIaaS for resolution. Similarly, AI intents may also be specified towards the AIaaS. This process allows components such as model selection to select an appropriate model from a pool of models from AIaaS to perform inferencing. We provide an example target below on the AI model accuracy, which is typically calculated as the ratio of correct predictions to the total number of predictions (often expressed as a percentage). 1Intent: 2id: 'AI_Model_Accuracy_Intent ' 3... 4expectationTargets: 5targetName: 'Average_Model_Accuracy ' 6targetCondition: 'IS_GREATER_THAN ' 7targetValueRange: 95 8observationPeriod : 60 9intentReportReference : ' AI_Model_Accuracy_Intent_Report ' Further details on the intent management process and decomposition of upper level intents to policies may be found in [8]. Testbed Implementation Approach. To enable realistic testing of distributed AI workflows across IoT, Edge, and Cloud tiers, we introduce the PANDORA testbed. This emulates a full-stack deployment architecture using Kubernetes in Docker (KIND). As seen in Figure 7a, the testbed consists of one control plane node (responsible for Kubernetes orchestration) and three worker nodes simulating the IoT, Edge, and Cloud layers. Each node is a containerized environment with configurable CPU and memory resources, allowing precise emulation of real-world constraints (e.g., low-power IoT nodes vs. high-performance cloud backends). Each node hosts containerized services (pods) appropriate to its layer, for example, sensor emulators on IoT, Kafka and inference engines on Edge, and databases like MongoDB on Cloud. The architecture supports internal networking between nodes and can simulate network delays, jitter, or packet loss via Chaos Mesh to reflect realistic conditions like 5G or lossy IoT links. Using the above testbed approach, PANDORA end-users can create resources at multiple IoT-Edge-Cloud levels for deploying their AIoT applications. For the 5G connected robot application, the following script can be specified: 1{ 2"cluster_name ": "5 G-app-testbed ", 3"nodes": [ 4{ "name": "IoT", 5"role": "worker", 6"cpu": "1", 7"memory": "4Gi"}, 8{ "name": "Edge ", 9"role": "worker ", 10 "cpu": "2", 11 "memory ": "8Gi"}, 12 { "name": " Controler ", (a) Testbed for AIoT Application Deployment. (b) Computing Computinum Nodes Required. Figure 7: The PANDORA Testbed Approach. 13 "role": " control-plane ", 14 "cpu": "3", 15 "memory ": "4Gi"}, 16 { "name": "Cloud", 17 "role": "worker ", 18 "cpu": "4", 19 "memory ": "16 Gi" }]} The above script creates the network of resources which is used to deploy the PANDORA components, as well as the 5G application scenario components as seen in Figure 7b. For Ericsson’s AIoT application, all components are deployed on cloud resources. Only specific inferencing models are deployed on IoT/edge resources, depending on the inferencing constraints. Intent manager, AIaaS, CaaS are all non-real time components and can take advantage of the scalability of the cloud. PANDORA Runtime Operation. Now that all PANDORA and 5G scenario components are deployed in the computing continuum, efficient AIoT operation can be supported. In particular, based on the defined user input, the IM component evaluates intent requirements and, if deviations occur, conveys the scenario goals (business and AI) to AIaaS. AIaaS hosts AI models in its registry and uses customized training data to train them. When training is performed under AIaaS, training requirements are sent to CaaS, which estimates performance needs, allocates compute resources, and registers the trained model. During deployment, runtime data is provided to AIaaS along with inference goals. CaaS estimates the required capacity and allocates resources for inference, enabling AIaaS to deploy the selected model. Inference requests on runtime data are processed by the deployed model, and the results drive scenario actuations to resolve issues. Based on the datasets collected in Ericsson’s premises, we run the AIaaS pipeline. An appropriate path planning model is chosen from the AIaaS repository to ensure a throughput of 200 Mbps along an indoor path. The output of path planning is shown in Figure 8. CaaS selects an Edge node to ensure that the inference latency is minimized. We notice that the model enables the robot to traverse the indoor scenario with the following metrics: 1Network Performance Summary : 2Average SNR: 76.97 dB 3Minimum SNR: 61.09 dB IOT 2025, November 18–21, 2025, Vienna, Austria Bouloukakis et al. Figure 8: Intent-driven path planning. 4Average Throughput : 378.49 Mbps 5Minimum Throughput : 194.91 Mbps 6Total path length: 22.65 meters 7SNR violations : 8/41 (19.5\%) Thus, PANDORA provides an intelligent framework for intent management, AIaaS and CaaS. The framework can be extended for other AIoT applications. 4 Related Work This section explores related works on managing and deploying AI models at operation time using AIaaS and CaaS architectures based on the needs (e.g., intent requirements) of end-users. Intent-based Frameworks. Intents are the formal representation of requirements for a system [ 23 ]. As specified in [ 1 ], an intent is associated with two parties: intent owner that creates and manages the intent; and intent handler that fulfills the requirements within an autonomous domain. Intents may be formally defined within RDF graphs as a way to structure intent models and extract their semantic correlation. In [ 17 ], a cognitive core solution is specified that can handle intent driven specifications. In [ 12 ], a comprehensive analysis of the state-of-the-art in intent driven networks including the intent description models, intent life-cycle management and a generalized architectural framework is presented. AaaS/CaaS-based Frameworks. With the increasing integration of AI techniques over most use-cases, the need for the network or compute devices to provide AI-as-a-Service has emerged. AIaaS provides the advantages of hosting and managing AI models at scale and ensuring cost-effective production of AI-based technologies. As presented in [ 22 ], multiple frameworks have been proposed that trade-off compute power, latency and AI-model maturity. As further emphasized in [ 20 ], AIaaS will play a key role in future 6G platforms, allowing cellular network and the compute continuum to host and serve application-centric AI models. An open source framework that we use within PANDORA is MLFlow [ 14 ]. MLFlow allows for model training, model hosting, model deployment and life-cycle management. Compute-as-a-service is an evolution of the ability to offload computations to edge or cloud servers. Specially in AIoT use cases where low-capacity (power, compute) devices operate in a networked environment, the compute continuum can be exploited for efficient operation. As demonstrated in [ 21 ], mobile edge computing may be used for computational offloading. In [ 18 ], the edge-cloud computing framework is proposed to reduce bottlenecks due to network bandwidth and communication latency within AIoT deployments. Table 4: Features supported by AIoT platforms. Features [19] [15] [16] [25] [11] PANDORA Intent Management – ✓– – – ✓ AI Model Selection – ✓✓✓✓✓ AI Model Life-cycle Management – – – – – ✓ Comp. Continuum Optimization ✓– – ✓✓✓ AIaaS may work in tandem with CaaS for efficient model training and serving. Summary. Table 4 compares some of the features of PANDORA with other state-of-the-art solutions. The work by Rang et al. [19] focuses on AIoT application development through edge-cloud compute continuum and data processing. In the works by Nadar and Harri [ 15 , 16 ], AIaaS platforms are presented with requirement specifications and AI model selection. In the work by Zhang et al. [ 25 ], the compute continuum is used to provide distributed intelligence and AI model selection features. The work by Loven et al. [ 11 ] proposes a Neural Pub/Sub paradigm to orchestrate AI models across the computing continuum. Through the use of mapping and funnel patterns, this paper proposes a framework for distributed data processing and AI deployment. Existing frameworks primarily focus on AI model selection, often overlooking whether these models are trained on trustworthy datasets. There is a clear need for methods that generate realistic and reliable datasets tailored to specific IoT environments. Key challenges include improving realism, preserving causality, and enhancing semantic explainability in synthetic IoT sensor data. More broadly, there is a demand for frameworks that integrate state-ofthe-art techniquesâĂŤfrom training AI models with trustworthy data to managing them at runtime based on user-defined intent requirements. PANDORA addresses this need by enabling the definition of intents, which guide the runtime selection and deployment of appropriate AI models across the computing continuum. 5 Conclusion This article presents PANDORA, a domain-informed framework that enables the delivery of trustworthy datasets and supports the continual, robust, and autonomous operation of AIoT systems in smart spaces. It provides a detailed overview of the PANDORA architecture, addressing both the support of AIoT applications prior to deployment (PANDORA design-time) and during operation (PANDORA runtime). Particular emphasis is placed on how the runtime phase ensures reliable and efficient operation through novel Intent-driven managers, AI-as-a-Service (AIaaS) and Compute-asa-Service (CaaS) components. Future work includes the design and implementation of new strategies for trustworthy dataset delivery at design-time, as well as training and inference across the computing continuum at runtime. These strategies, along with the core components of the PANDORA framework, will be implemented, integrated, and released as opensource to support AIoT deployment and operation. Acknowledgments This work is supported by the Horizon Europe project PANDORA under grant agreement number 101135775. The PANDORA framework IOT 2025, November 18–21, 2025, Vienna, Austria References [1] 3GPP. 2024. ntent driven management services for mobile networks. Technical Report. Specification 28.312. [2] Muhammad Abbas Khan, Habib Khan, Muhammad Faizan Omer, Inam Ullah, and Muhammad Yasir. 2024. Impact of artificial intelligence on the global economy and technology advancements. In Artificial General Intelligence (AGI) Security: Smart Applications and Sustainable Technologies. Springer, 147–180. [3] Andrew Chio, Daokun Jiang, Peeyush Gupta, Georgios Bouloukakis, Roberto Yus, Sharad Mehrotra, and Nalini Venkatasubramanian. 2022. Smartspec: Customizable smart space datasets via event-driven simulations. In 2022 IEEE International Conference on Pervasive Computing and Communications (PerCom). IEEE, 152– 162. [4] Dana Cooperson. 2022. Intent in autonomous networks. Technical Report. TMForum. [5] Ashish Dandekar, Remmy AM Zen, and Stéphane Bressan. 2018. A comparative study of synthetic dataset generation techniques. In Database and Expert Systems Applications: 29th International Conference, DEXA 2018, Regensburg, Germany, September 3–6, 2018, Proceedings, Part II 29. Springer, 387–395. [6] Agrim Gupta, Justin Johnson, Li Fei-Fei, Silvio Savarese, and Alexandre Alahi. 2018. Social gan: Socially acceptable trajectories with generative adversarial networks. In Proceedings of the IEEE conference on computer vision and pattern recognition. 2255–2264. [7] Senthil Kumar Jagatheesaperumal, Mohamed Rahouti, Kashif Ahmad, Ala AlFuqaha, and Mohsen Guizani. 2021. The duo of artificial intelligence and big data for industry 4.0: Applications, techniques, challenges, and future research directions. IEEE Internet of Things Journal 9, 15 (2021), 12861–12885. [8] Ajay Kattepur, Snigdha Das, Danesh Daroui, Swarup Mohalik, Marin Orlic, and Sultan Ertas. 2025. DETROIT: Decomposition techniques for a hierarchy of 6G network intent management functions. Comput. Networks 272 (2025), 111657. [9] Xiangjie Kong, Yuhan Wu, Hui Wang, and Feng Xia. 2022. Edge Computing for Internet of Everything: A Survey. IEEE Internet of Things Journal 9, 23 (2022), 23472–23485. [10] Michael L Littman, Andrew W Moore, et al . 1996. Reinforcement learning: A survey. Journal of artificial intelligence research 4, 1 (1996), 237–285. [11] Lauri LovÃľn, Roberto Morabito, Abhishek Kumar, Susanna Pirttikangas, Jukka Riekki, and Sasu Tarkoma. 2023. How Can AI be Distributed in the Computing Continuum? Introducing the Neural Pub/Sub Paradigm. arXiv:2309.02058 [cs.NI] https://arxiv.org/abs/2309.02058 [12] Kashif Mehmood, Katina Kralevska, and David Palma. 2023. Intent-driven autonomous network and service management in future cellular networks: A structured literature review. Comput. Netw. 220, C (Jan. 2023), 19 pages. [13] Sunit Mistry, Lili Wang, Yousuf Islam, and Frimpong Atta Junior Osei. 2022. A comprehensive study on healthcare datasets using AI techniques. Electronics 11, 19 (2022), 3146. [14] MLflow. 2025. A Tool for Managing the Machine Learning Lifecycle. https: //mlflow.org/. [Online; accessed May-2025]. [15] Ali Nadar and JÃľrÃťme HÃďrri. 2024. An AI-as-a-Service Platform for an Artificial Intelligence of Things (AIoT). In 2024 IEEE 99th Vehicular Technology Conference (VTC2024-Spring). 1–7. [16] Ali Nadar and JÃľrÃťme HÃďrri. 2024. Enhancing Network Data Analytics Functions: Integrating AIaaS with ML Model Provisioning. In 2024 22nd Mediterranean Communication and Computer Networking Conference (MedComNet). [17] Jorg Niemoller, Leo Mokrushin, Swarup Mohalik, M Konchylaki, and George Sarmonikas. 2020. Cognitive processes for adaptive intent-based networking. Technical Report. Ericsson Technology Review. [18] Guoping Rong, Yangchen Xu, Xinxin Tong, and Haojun Fan. 2021. An edge-cloud collaborative computing platform for building AIoT applications efficiently. J. Cloud Comput. 10, 1 (July 2021), 14 pages. [19] Guoping Rong, Yangchen Xu, Xinxin Tong, and Haojun Fan. 2021. An edge-cloud collaborative computing platform for building AIoT applications efficiently. J. Cloud Comput. 10, 1 (July 2021), 14 pages. [20] M Saimler, M D’Angelo, D Roeland, A Ahmed, and A Kattepur. 2025. AI as a service: How AI applications can benefit from the network. https://www.ericsson. com/en/blog/2023/12/ai-as-a-service. [Online; accessed May-2025]. [21] Chuanhao Sun, Jizhe Zhou, Jingrong Liuliang, Jiaxin Zhang, Xing Zhang, and Wenbo Wang. 2018. Computation Offloading with Virtual Resources Management in Mobile Edge Networks. In 2018 IEEE 87th Vehicular Technology Conference (VTC Spring). 1–5. [22] Naeem Syed, Adnan Anwar, Zubair Baig, and Sherali Zeadally. 2025. Artificial Intelligence as a Service (AIaaS) for Cloud, Fog and the Edge: State-of-the-Art Practices. Comput. Surveys 57, 8 (2025). [23] TMForum. 2024. Intent Common Model. Technical Report. Specification TR290 v 3.6.0. [24] Daniel S. Weld. 1999. Recent Advances in AI Planning. AI Magazine 20, 2 (Jun. 1999), 93. [25] Mingjin Zhang, Jiannong Cao, Yuvraj Sahni, Qianyi Chen, Shan Jiang, and Tao Wu. 2022. EaaS: A Service-Oriented Edge Computing Framework Towards Distributed Intelligence. In 2022 IEEE International Conference on Service-Oriented System Engineering (SOSE). 165–175.