CRAWO: Custom Resources for Adaptive Workload Orchestration

# CRAWO: Custom Resources for Adaptive Workload Orchestration
Source: [https://arxiv.org/html/2607.20490](https://arxiv.org/html/2607.20490)
###### Abstract

Edge Intelligence has emerged as a key paradigm for enabling real\-time applications in smart cities by shifting computation from centralized cloud data centers to the network edge, thereby reducing latency and bandwidth consumption\. However, deploying Artificial Intelligence \(AI\) pipelines across heterogeneous edge infrastructures remains challenging due to the wide range of device capabilities, from low\-power microcontrollers to accelerator\-equipped systems\. Existing edge orchestration platforms primarily focus on deployment automation and infrastructure management, but these approaches are often inefficient and limit the ability to adaptively allocate resources under dynamic conditions\. To tackle these issues, this paper introduces CRAWO \(Custom Resources for Adaptive Workload Orchestration\), an architectural framework for coordinating AI pipelines across distributed edge environments\. CRAWO follows a control\-loop\-based model that separates allocation intelligence from execution by managing placement decisions, state management, and inter\-stage data flows while instantiating services on edge nodes\. The framework incorporates a hardware\-aware allocator with a pluggable multi\-criteria decision layer that leverages real\-time infrastructure metrics to enable adaptive workload placement\. The reference implementation adopts a microservices architecture deployed on a lightweight Kubernetes distribution \(K3s\), using Custom Resource Definitions \(CRDs\) for domain modeling and a dedicated operator for state reconciliation\. Evaluation in a vehicle surveillance scenario using license plate recognition demonstrates improved workload distribution and reduced reliance on centralized cloud processing in latency\-sensitive environments\.

###### keywords:

edge orchestration , smart cities , Kubernetes , multi\-criteria decision making , Edge Intelligence\.

††journal:Computer Communications\\affiliation

organization=Federal University of Rio Grande do Norte, city=Natal, country=Brazil

## 1Introduction

The shift of computation from centralized cloud data centers to the network edge has positioned edge intelligence as a fundamental paradigm for real\-time applications\. Edge intelligence enables Artificial Intelligence \(AI\) processing at or near data sources by leveraging the enhanced computational capabilities of modern edge devices\. This approach reduces communication latency, alleviates bandwidth pressure, and enables timely analytics at the source\[[15](https://arxiv.org/html/2607.20490#bib.bib7)\], benefits that are often lost in traditional cloud\-based approaches\. These capabilities are particularly crucial for AI\-driven video processing, in which tasks must be performed near the capture devices to meet strict time\-sensitive requirements and avoid the prohibitive overhead of transmitting raw, high\-volume multimedia streams to a remote infrastructure\[[16](https://arxiv.org/html/2607.20490#bib.bib4)\]\.

While cloud\-only architectures simplify management through a global system view, they are often impractical at scale\. For example, in scenarios involving object detection and recognition from images or video streams, even a small number of high\-definition cameras can overload the network backhaul, thereby hampering reliable target identification\. To address this challenge, complex AI workloads are increasingly modeled as data flows by decomposing monolithic applications into modular pipelines\. This structure allows AI services to be expressed as interconnected stages \(e\.g\., detection, recognition, and decision\), enabling each component to be deployed on different nodes across the edge\-cloud continuum to reduce end\-to\-end latency and network overhead\[[3](https://arxiv.org/html/2607.20490#bib.bib1)\]\.

On the other hand, implementing AI pipelines across edge infrastructures remains a significant challenge, as these environments often comprise a wide range of heterogeneous devices, from low\-power microcontrollers to units with integrated GPUs and AI accelerators\[[15](https://arxiv.org/html/2607.20490#bib.bib7)\]\. Such diversity makes static deployment strategies inefficient, as each node exhibits distinct constraints and performance characteristics\. This challenge is further amplified in scenarios such as smart cities, which demand low latency and efficient coordination across interconnected devices and mobile processing units\[[4](https://arxiv.org/html/2607.20490#bib.bib6)\]\. Consequently, an intelligent orchestrator is essential to manage distributed processing\. This orchestrator must translate high\-level service requirements into concrete execution plans by dynamically allocating computationally intensive workloads encapsulated as microservices or containers to the most suitable nodes\. This process must consider resource availability and critical operational constraints to ensure efficiency and scalability under dynamic cluster conditions\[[14](https://arxiv.org/html/2607.20490#bib.bib5),[12](https://arxiv.org/html/2607.20490#bib.bib8),[17](https://arxiv.org/html/2607.20490#bib.bib10)\]\.

To address these issues, this work presents CRAWO \(Custom Resources for Adaptive Workload Orchestration\)\. We designed CRAWO to operate alongside modern workload execution platforms, leveraging their reliability while addressing orchestration challenges in complex edge environments\. A key aspect of the solution is the separation of execution and orchestration concerns\. While the underlying platform manages service deployment and system state, CRAWO introduces a dedicated layer for allocation and context management\. This design enables adaptive coordination without modifying internal execution mechanisms\. By treating processing pipelines as cohesive units, CRAWO allows platforms such as Kubernetes to focus on execution consistency while it manages the “where and when” of pipeline deployment based on runtime conditions\.

The contributions of this work are threefold:

1. 1\.A control\-loop model organized into different planes, featuring a hardware\-aware allocator that employs real\-time metrics and a pluggable multi\-criteria decision layer for dynamic task distribution\.
2. 2\.A reference implementation for CRAWO following a microservices architecture deployed on K3s,111[https://k3s\.io](https://k3s.io/)leveraging Kubernetes Custom Resources Definition \(CDR\) for domain modeling and a Go\-based component for state reconciliation\.
3. 3\.A demonstration of our proposal with a license plate recognition \(LPR\) use case and its performance evaluation considering network conditions and varying high\-resolution video workloads\.

The remainder of this paper is organized as follows\. Section[2](https://arxiv.org/html/2607.20490#S2)introduces a vehicular surveillance scenario as a motivational use case\. Section[3](https://arxiv.org/html/2607.20490#S3)discusses related work\. Section[4](https://arxiv.org/html/2607.20490#S4)details the CRAWO architecture, while Section[5](https://arxiv.org/html/2607.20490#S5)describes the reference implementation\. Section[6](https://arxiv.org/html/2607.20490#S6)demonstrates the practical instantiation for an LPR use case\. Section[7](https://arxiv.org/html/2607.20490#S7)presents the evaluation\. Section[8](https://arxiv.org/html/2607.20490#S8)provides final remarks and directions for future work\.

## 2Motivational use case: Vehicular surveillance in smart cities

Our motivational scenario focuses on mobile law enforcement units, specifically police patrol vehicles operating within a smart city environment\. These vehicles are equipped with high\-definition cameras that continuously record video for monitoring\. To transform this raw data into actionable intelligence, the video streams must be processed efficiently to support immediate police decision\-making\. The critical requirement is to perform LPR in real time, ensuring that suspicious vehicle identification occurs instantly on\-site and that video processing does not depend solely on network connectivity\.

As illustrated in Figure[1](https://arxiv.org/html/2607.20490#S2.F1), the LPR workflow consists of a sequential computer vision pipeline\. This process begins by detecting the vehicle in raw video frames, followed by localizing and isolating the specific license plate area\. Subsequently, the system performs character segmentation to separate individual letters and numbers, followed by Optical Character Recognition \(OCR\) and database queries to verify the vehicle’s legal status\.

![Refer to caption](https://arxiv.org/html/2607.20490v1/images/UC5.jpg)Figure 1:Use case: Vehicular surveillance in smart cities and processing alternatives\.To execute this pipeline, the vehicular infrastructure is highly heterogeneous, offering various processing options with distinct trade\-offs\. The need for local processing is driven by the dynamic nature of vehicular surveillance, which demands response times in the order of milliseconds to effectively identify and intercept moving targets\. Furthermore, the architecture must be able to seamlessly propagate updated detection rules, such as stolen\-vehicle watchlists, from the central cloud to the distributed edge nodes\.

### 2\.1Cloud\-only execution baseline

In the conventional cloud\-only deployment model, the vehicle serves solely as a data generator, with all stages of the AI pipeline executed remotely on a centralized infrastructure\. This approach is commonly adopted in smart city surveillance architectures, as it simplifies management by relying on centralized cloud infrastructure or a single Kubernetes cluster for service execution\[[2](https://arxiv.org/html/2607.20490#bib.bib2)\]\.

However, such centralized processing requires the continuous transmission of high\-volume video streams to remote infrastructures, which introduces significant bandwidth pressure and latency\. These constraints often violate the real\-time requirements of law enforcement applications, as the system remains entirely dependent on the stability and availability of the network backhaul\.

### 2\.2Edge\-distributed execution with orchestration

An edge\-distributed execution model can offload computationally intensive stages to heterogeneous nodes located within the vehicle, closer to the data source\. In this architecture, a microcontroller handles acquisition and virtualization, acting as a device adapter that encapsulates the sensor and standardizes the data flow\. Computationally intensive tasks, such as OCR, are then forwarded over the local network to more robust onboard edge nodes, such as an NVIDIA Jetson or a Raspberry Pi\.

While this approach significantly reduces latency and backhaul bandwidth consumption, it introduces a trade\-off in architectural complexity\. Managing a distributed set of heterogeneous mobile nodes is far more demanding than maintaining a centralized cloud because it requires handling intermittent connectivity, hardware\-specific constraints, and the overhead of local resource coordination\.

To mitigate these challenges, the system’s effectiveness becomes entirely dependent on a sophisticated orchestration layer\. This orchestrator must meet three critical requirements:

1. 1\.Dynamic workload mapping:It must automatically assign AI inference tasks to GPU\-accelerated nodes while keeping lightweight adaptation tasks on microcontrollers to prevent bottlenecks\.
2. 2\.Resource awareness:It must maintain real\-time awareness of the heterogeneous hardware state to ensure millisecond\-range response times and optimize data flows\.
3. 3\.Seamless synchronization:It must support selective synchronization of metadata to the cloud, ensuring the system remains interoperable with broader smart city ecosystems without overloading the network\.

These requirements highlight the limitations of general\-purpose orchestration in specialized edge environments\. To address these challenges, we propose CRAWO to bridge the gap between high\-level AI pipeline definitions and the physical constraints of heterogeneous nodes\. By implementing a control\-loop model that operates alongside existing execution platforms, CRAWO can transform the complex operational requirements of the LPR scenario into a manageable, automated workflow\.

## 3Related work

Orchestration across edge and cloud infrastructures has been widely investigated to support real\-time applications\. Early efforts, such as FogFlow\[[3](https://arxiv.org/html/2607.20490#bib.bib1)\], introduced programming abstractions for deploying Internet of Things \(IoT\) service pipelines across distributed resources, enabling application components to be positioned closer to data sources to reduce latency and network overhead\. More recent platform\-oriented approaches have extended cloud\-native orchestration mechanisms to the edge by leveraging Kubernetes as the underlying execution environment\. These solutions typically maintain compatibility with the Kubernetes control plane while enabling the deployment of containerized services on geographically distributed, resource\-constrained nodes\.

Such frameworks provide localized autonomy and facilitate infrastructure management across heterogeneous devices, supporting container execution, remote management, and partial network independence\[[2](https://arxiv.org/html/2607.20490#bib.bib2)\]\. However, the literature on fog and edge computing consistently identifies heterogeneity, mobility, and dynamic resource variability as persistent challenges, particularly in large\-scale deployments characterized by fluctuating network conditions and diverse hardware capabilities\[[4](https://arxiv.org/html/2607.20490#bib.bib6)\]\. Although existing solutions enable distributed execution, their scheduling logic frequently remains aligned with assumptions inherited from data center environments, where resource stability and network predictability are significantly higher\.

### 3\.1Workload placement and multi\-criteria decision\-making

In many existing systems, workload placement decisions are primarily driven by predefined descriptors such as CPU and memory requests, node labels, or static policies\[[2](https://arxiv.org/html/2607.20490#bib.bib2)\]\. While some solutions incorporate basic network awareness or topology constraints, allocation logic is often tightly coupled to the underlying execution environment and limited to rule\-based or single\-metric optimization strategies\. Under highly dynamic edge conditions, where latency, bandwidth, accelerator availability, and workload intensity continually vary, such approaches often fail to provide sufficiently adaptive decision\-making behavior\.

To address these limitations, recent research explores intelligent workload placement strategies based on multi\-criteria decision\-making \(MCDM\)\. Methods such as the Technique for Order of Preference by Similarity to Ideal Solution \(TOPSIS\) and VIKOR have been applied to balance conflicting objectives, including latency, throughput, and resource utilization in distributed resource selection scenarios\[[17](https://arxiv.org/html/2607.20490#bib.bib10)\]\. While TOPSIS ranks alternatives based on their geometric distance from an ideal reference solution\[[11](https://arxiv.org/html/2607.20490#bib.bib3)\], VIKOR adopts a compromise ranking mechanism that jointly considers aggregate utility and individual regret\[[10](https://arxiv.org/html/2607.20490#bib.bib16)\]\. This strategy allows for more balanced decisions when criteria exhibit inherent conflicts\.

Table[1](https://arxiv.org/html/2607.20490#S3.T1)summarizes representative allocation approaches based on their optimization characteristics and suitability for heterogeneous edge environments\. Traditional load\-balancing approaches, such as Random, Round Robin, and Least Loaded, either neglect multiple decision criteria or assume homogeneous processing capabilities, thus limiting their effectiveness in heterogeneous edge scenarios\. In contrast, MCDM models explicitly capture trade\-offs among performance, latency, and resource utilization\. Among these approaches, VIKOR stands out for its ability to handle conflicting evaluation criteria in dynamic environments\.

Table 1:Comparison of representative workload allocation strategies in edge environments\.StrategyMulti\-criteriaConflictingcriteriaComputationalcomplexityEdge suitabilityRandom Selection✕✕𝒪​\(1\)\\mathcal\{O\}\(1\)Low \(no resource awareness\)Round Robin✕✕𝒪​\(1\)\\mathcal\{O\}\(1\)Low \(assumes homogeneity\)Least Loaded✕✕𝒪​\(m\)\\mathcal\{O\}\(m\)Moderate \(single\-metric adaptation\)TOPSIS⚫❍𝒪​\(m​k\)\\mathcal\{O\}\(mk\)High \(multi\-objective ranking\)VIKOR⚫⚫𝒪​\(m​k\)\\mathcal\{O\}\(mk\)High \(compromise\-based decision\)Legend: ⚫ = fully supported; ❍ = partially supported; ✕ = not supportedmm: number of candidate nodes;kk: number of criteria
### 3\.2Architectural coupling in edge orchestration

Recent Kubernetes\-based edge orchestration proposals enhance scheduling behavior through tightly integrated plugins and control plane extensions\[[13](https://arxiv.org/html/2607.20490#bib.bib35)\]\. Although these approaches improve resource awareness, the allocation logic remains embedded within the underlying environment\. Consequently, decision intelligence is implemented at the scheduler level, resulting in strong coupling between execution control and placement strategy\. This architectural coupling implies that evolving, replacing, or experimentally evaluating alternative decision models often requires modifications to the orchestration framework itself\. Therefore, allocation quality depends not only on deployment capabilities but fundamentally on how decision logic is architecturally positioned\.

Table[2](https://arxiv.org/html/2607.20490#S3.T2)summarizes various edge\-cloud platforms according to the scope of decision criteria supported in their placement logic, as reported in their documentation and the literature\[[3](https://arxiv.org/html/2607.20490#bib.bib1),[2](https://arxiv.org/html/2607.20490#bib.bib2),[4](https://arxiv.org/html/2607.20490#bib.bib6)\]\. We can note that either resource descriptors, network metrics, hardware capability differentiation, or multi\-criteria ranking mechanisms are natively incorporated into allocation decisions\. While several platforms support container deployment across heterogeneous infrastructures, the combination of explicit multi\-criteria ranking with architecturally decoupled allocation intelligence is rarely treated as a primary design principle\.

Table 2:Decision criteria and allocation strategies adopted by representative edge\-cloud orchestrators\.In contrast to these embedded approaches, CRAWO introduces an architectural model that explicitly separates allocation intelligence from execution management\. The reference implementation adopts a VIKOR\-based ranking strategy integrated within a Kubernetes\-native control loop\. However, the decision mechanism is not bound to a specific algorithm, but rather the allocation layer is designed to support many multi\-criteria models without modifying the underlying execution environment\. This separation enables systematic experimentation with alternative decision strategies while maintaining architectural consistency across heterogeneous edge deployments\.

## 4CRAWO: Custom Resources for Adaptive Workload Orchestration

We designed the CRAWO framework to orchestrate multi\-stage AI processing pipelines across heterogeneous edge computing infrastructures\. It addresses the challenge of managing complex workloads on distributed nodes with varying capabilities by providing a high\-level abstraction layer that decouples service definition from infrastructure complexity\.

CRAWO currently works as the orchestrator for the SAALSA \(Stream AI Analytics for Live Situational Awareness\) framework\[[7](https://arxiv.org/html/2607.20490#bib.bib34),[8](https://arxiv.org/html/2607.20490#bib.bib33)\]\. While SAALSA provides the underlying intelligent video processing capabilities, CRAWO orchestrates these analytics to achieve high\-performance situational awareness in smart city environments\.

### 4\.1Architecture

Unlike edge orchestrators that embed decision logic directly within the underlying execution environment, making placement policies inseparable from deployment mechanisms, CRAWO isolates intelligence, domain modeling, and enforcement into three coordinated planes\. This separation allows allocation strategies to evolve independently of infrastructure concerns\. The CRAWO architecture follows a control\-loop model organized into three distinct planes, as depicted in Figure[2](https://arxiv.org/html/2607.20490#S4.F2):

- •TheControl Planeprovides the framework’s intelligence, handles user interactions, manages service compositions, and executes decision\-making logic to map abstract workloads to physical resources, while maintaining a global view of the domain and optimizing execution strategies based on real\-time conditions\.
- •TheData Planedefines standardized domain\-specific data models for edge nodes, AI services, topologies, and task allocations, serving as the common language that binds theControlandExecutionplanes\.
- •TheExecution Planecontinuously monitors the definitions provided by theControl Planeand enforces them on the physical infrastructure, managing the life cycle of deployed services to ensure the actual state converges with the desired state\.

![Refer to caption](https://arxiv.org/html/2607.20490v1/images/architeture-CRAWO1.jpg)Figure 2:CRAWO architecture\.
### 4\.2Core components

The architecture is realized through a set of collaborating components, each fulfilling a distinct role in the orchestration lifecycle\.

TheManageris the orchestration component that coordinates the execution of AI pipelines, maintaining the system’s structural aspects, including the association between data sources and processing tasks, the set of available processing nodes, and the definition of service topologies\. As the entry point for expressing execution intent, it translates high\-level specifications into plans for the underlying platform\. By delegating placement decisions to theAllocator, theManagerfocuses on coordination and enforcement\.

TheAllocatordetermines how execution decisions are derived from current operating conditions\. It consolidates the policies and algorithms used to select suitable nodes for each pipeline stage, taking into account hardware capabilities, resource availability, and performance indicators\. TheAllocatoroperates independently of deployment and execution mechanisms, ensuring that the logic governing allocation decisions is not entangled with infrastructure\-level concerns\. This separation allows allocation strategies to be adjusted or replaced as needed without affecting the orchestration process coordinated by theManager\.

TheContextcomponent provides a real\-time view of the execution environment by aggregating operational data and metrics on node availability and performance to inform allocation decisions\. By limiting this component to reflecting runtime behavior rather than participating in decision\-making, CRAWO establishes clear boundaries between state observation and orchestration logic\.

TheOperatorbridges high\-level decisions made by theControl Planeand low\-level execution on the infrastructure by translating abstract scheduling decisions into concrete resources\. Following a reconciliation pattern, theOperatorcontinuously monitors the desired state and enforces it by provisioning execution units, configuring environment variables, and establishing network services\. It also closes the control loop by observing the lifecycle of running workloads and updating the status of allocation entities\.

### 4\.3Orchestration and interaction workflow

The orchestration process is implemented through a synchronized interaction sequence among the control and execution components\. This workflow translates high\-level user intents into hardware\-aware execution units while maintaining continuous state reconciliation\.

Allocation decision flow\.The workflow begins when a service request is submitted to theManager\. As illustrated in Figure[3](https://arxiv.org/html/2607.20490#S4.F3), theManagervalidates the topology and requirements before delegating the placement decision to theAllocator\. TheAllocatorperforms a hardware\-aware selection by querying theContextcomponent for real\-time metrics and capabilities\. Using a VIKOR\-based multi\-criteria strategy, it ranks candidate nodes and selects a compromise execution target\. Finally, theManagerpersists this intent as aTaskAllocationCustom Resource \(CR\) in the Kubernetes API\.

![Refer to caption](https://arxiv.org/html/2607.20490v1/images/sequence_allocation1.jpg)Figure 3:Sequence diagram illustrating the allocation decision flow, from user request to creating aTaskAllocationCR\.Reconciliation and provisioning flow\.Once theTaskAllocationCR is persisted, theExecution Planetakes control\. As shown in Figure[4](https://arxiv.org/html/2607.20490#S4.F4), theOperatordetects the new resource via a watch mechanism and initiates the reconciliation loop\. It provisions the necessary Kubernetes resources, including aConfigMapfor runtime parameters, aDeploymentfor the service container, and, optionally, aServicefor network access\. Crucially, the Operator injects anodeSelectorconstraint to pin the workload to the node selected by theAllocator\. Throughout the Pod lifecycle, theOperatorcontinuously monitors the workload state and reflects it back into theTaskAllocationstatus field\.

![Refer to caption](https://arxiv.org/html/2607.20490v1/images/sequence_reconciliation1.jpg)Figure 4:Sequence diagram illustrating the reconciliation flow, fromTaskAllocationdetection to status synchronization\.Context awareness and resource monitoring\.A continuous secondary workflow ensures the orchestration engine remains aware of cluster health and performance\. TheContextcomponent periodically pulls metrics from Prometheus \(e\.g\., CPU, RAM, and GPU utilization\) and state information from the Kubernetes API\. As shown in Figure[5](https://arxiv.org/html/2607.20490#S4.F5), these metrics are processed and provided to theAllocatorfor calculating scores for future scheduling decisions, ensuring the system adapts to the dynamic conditions of the edge environment\.

![Refer to caption](https://arxiv.org/html/2607.20490v1/images/sequence_context1.jpg)Figure 5:Sequence diagram illustrating the context awareness flow, and how real\-time metrics influence allocation logic\.
### 4\.4Allocation decision model

CRAWO introduces an explicit decision layer that assigns AI pipeline stages to heterogeneous edge processing nodes\. This layer is conceptually separated from orchestration control and execution concerns, allowing placement decisions to be derived from runtime conditions without coupling them to deployment mechanisms\. Within this model, theAllocatorevaluates candidate nodes and selects an execution target for each pipeline stage based on a structured sequence\.

First, theAllocatoridentifies the set of processing nodes that satisfy basic feasibility constraints, such as architectural compatibility, reachability, and execution capacity\. This filtering step ensures that only nodes capable of executing the service are considered\. From this reduced candidate set, theAllocatorbuilds a decision matrix using runtime information provided by theContextcomponent\.

#### 4\.4\.1Decision criteria and selection strategy

The decision criteria reflect both performance and resource\-utilization aspects relevant to heterogeneous edge environments\. In the current implementation, these criteria include:

- •Inference throughput \(frames per second, FPS\): it is prioritized as a benefit criterion to sustain real\-time processing rates and avoid backlog\.
- •Estimated processing latency: it is treated as a cost criterion to prevent violations of strict response\-time constraints\.
- •Node load: it is treated as a cost criterion to prevent resource saturation and ensure stability under multi\-tenant conditions\.

Together, these indicators capture the inherent trade\-off between maximizing performance and avoiding resource exhaustion\. To rank candidate nodes according to these criteria, the reference implementation for CRAWO uses the VIKOR method\[[10](https://arxiv.org/html/2607.20490#bib.bib16)\]\. This MCDM technique identifies a compromise solution by simultaneously minimizing group utility loss and individual regret\. Its compromise\-ranking formulation enables balanced decisions without privileging any single performance dimension, making it more robust than common baselines\. For instance, Random selection ignores node conditions and may overload constrained devices, Round Robin assumes homogeneous capabilities, and Least Loaded disregards differences in hardware acceleration\. By jointly accounting for throughput, latency, and node load, the VIKOR method yields a more robust compromise solution under dynamic and heterogeneous edge conditions\.

The VIKOR\-based allocation strategy evaluates each candidate node against the three runtime decision criteria that capture the fundamental trade\-off between computational performance and resource saturation in heterogeneous edge environments\. Within the VIKOR method, these criteria jointly contribute to the computation of a compromise ranking that balances overall utility and individual regret\. Table[3](https://arxiv.org/html/2607.20490#S4.T3)summarizes the adopted criteria, their optimization direction, and the relative weights used in the current implementation of theAllocator\.

Table 3:Decision criteria adopted by theAllocatorin CRAWO\.
#### 4\.4\.2Mathematical formulation

The VIKOR method determines a compromise solution by evaluating the relative distance of each alternative from the ideal performance for each criterion\. Initially, a decision matrixF=\[fi​j\]F=\[f\_\{ij\}\]is defined, where each candidate nodeiiis evaluated against criterionjj\. For each criterion, the best valuefj∗f\_\{j\}^\{\*\}and the worst valuefj−f\_\{j\}^\{\-\}are identified\. The limits are defined by Equation[1](https://arxiv.org/html/2607.20490#S4.E1)for benefit criteria \(to be maximized\) and follow Equation[2](https://arxiv.org/html/2607.20490#S4.E2)for cost criteria \(to be minimized\)\.

fj∗\\displaystyle f\_\{j\}^\{\*\}=maxi⁡fi​j,fj−=mini⁡fi​j\\displaystyle=\\max\_\{i\}f\_\{ij\},\\quad f\_\{j\}^\{\-\}=\\min\_\{i\}f\_\{ij\}\(1\)fj∗\\displaystyle f\_\{j\}^\{\*\}=mini⁡fi​j,fj−=maxi⁡fi​j\\displaystyle=\\min\_\{i\}f\_\{ij\},\\quad f\_\{j\}^\{\-\}=\\max\_\{i\}f\_\{ij\}\(2\)
Once the ideal points are established, the normalized distancedi​jd\_\{ij\}of an alternativeiiunder criterionjjis computed\. For benefit and cost criteria, these distances are defined as shown in Equation[3](https://arxiv.org/html/2607.20490#S4.E3)\. These values are subsequently aggregated using predefined weightswjw\_\{j\}to derive the group utilitySiS\_\{i\}and the maximum individual regretRiR\_\{i\}, according to the formulations in Equation[4](https://arxiv.org/html/2607.20490#S4.E4):

Benefit:​di​j=fj∗−fi​jfj∗−fj−Cost:​di​j=fi​j−fj∗fj−−fj∗\\text\{Benefit: \}d\_\{ij\}=\\frac\{f\_\{j\}^\{\*\}\-f\_\{ij\}\}\{f\_\{j\}^\{\*\}\-f\_\{j\}^\{\-\}\}\\quad\\text\{Cost: \}d\_\{ij\}=\\frac\{f\_\{ij\}\-f\_\{j\}^\{\*\}\}\{f\_\{j\}^\{\-\}\-f\_\{j\}^\{\*\}\}\(3\)
Si=∑j=1nwj​di​j,Ri=maxj⁡\(wj​di​j\)S\_\{i\}=\\sum\_\{j=1\}^\{n\}w\_\{j\}d\_\{ij\},\\quad R\_\{i\}=\\max\_\{j\}\(w\_\{j\}d\_\{ij\}\)\(4\)
We defined the adopted weights empirically based on workload requirements observed during controlled experiments in the LPR use case\. In the context of LPR, maximizing throughput \(0\.40\) is prioritized to prevent frame dropping at the source, while latency \(0\.35\) remains critical for timely police response, and node load \(0\.25\) serves as a stabilizing penalty rather than a primary driver\. The configuration prioritizes sustained inference throughput while maintaining latency constraints and preventing resource saturation\. The weight distribution is not fixed by the architectural design and can be adjusted to accommodate different application domains or operational priorities without requiring modifications to the orchestration framework\.

The final selection is based on the compromise ranking indexQiQ\_\{i\}, which balances the overall group utility and individual regret\. LetS∗,S−,R∗,S^\{\*\},S^\{\-\},R^\{\*\},andR−R^\{\-\}be the minimum and maximum values ofSiS\_\{i\}andRiR\_\{i\}, respectively, as shown in Equation[5](https://arxiv.org/html/2607.20490#S4.E5)\. The indexQiQ\_\{i\}is then formulated using a strategy weightv∈\[0,1\]v\\in\[0,1\]\(Equation[6](https://arxiv.org/html/2607.20490#S4.E6)\), wherev=0\.5v=0\.5is typically adopted to provide a neutral balance\. In cases where the denominators\(S−−S∗\)\(S^\{\-\}\-S^\{\*\}\)or\(R−−R∗\)\(R^\{\-\}\-R^\{\*\}\)are zero, the corresponding term is set to zero to prevent division\-by\-zero errors\.

S∗=mini⁡Si,S−=maxi⁡Si,R∗=mini⁡Ri,R−=maxi⁡RiS^\{\*\}=\\min\_\{i\}S\_\{i\},\\quad S^\{\-\}=\\max\_\{i\}S\_\{i\},\\quad R^\{\*\}=\\min\_\{i\}R\_\{i\},\\quad R^\{\-\}=\\max\_\{i\}R\_\{i\}\(5\)
Qi=v​Si−S∗S−−S∗\+\(1−v\)​Ri−R∗R−−R∗Q\_\{i\}=v\\frac\{S\_\{i\}\-S^\{\*\}\}\{S^\{\-\}\-S^\{\*\}\}\+\(1\-v\)\\frac\{R\_\{i\}\-R^\{\*\}\}\{R^\{\-\}\-R^\{\*\}\}\(6\)
Alternatives are evaluated based on theirQiQ\_\{i\}values, and the node with the smallestQiQ\_\{i\}is selected as the compromise solution\. Algorithm[4\.4\.2](https://arxiv.org/html/2607.20490#S4.SS4.SSS2)details this mechanism encapsulated within theAllocator, thus preserving the policy\-agnostic nature of CRAWO\. This separation enables the current VIKOR\-based strategy to be replaced by alternative heuristics or learning\-based approaches without modifications to the orchestration control flow\.

Algorithm 1: VIKOR\-based hardware\-aware node selection

1:Candidate set

N≠∅N\\neq\\varnothing
2:Selected node

nb​e​s​tn\_\{best\}
3:

m←\|N\|m\\leftarrow\|N\|// number of candidates

4:

k←3k\\leftarrow 3// criteria: FPS, latency, load

5:Initialize matrix

F​\[m\]​\[k\]F\[m\]\[k\]
6:

7://Step 1: Construct decision matrixFF

9:

F​\[i,1\]←FPS​\(ni\)F\[i,1\]\\leftarrow\\mathrm\{FPS\}\(n\_\{i\}\)
10:

F​\[i,2\]←Latency​\(ni\)F\[i,2\]\\leftarrow\\mathrm\{Latency\}\(n\_\{i\}\)
11:

F​\[i,3\]←Load​\(ni\)F\[i,3\]\\leftarrow\\mathrm\{Load\}\(n\_\{i\}\)
12:endfor

13:

14://Step 2: Determine best and worst valuesf∗f^\{\*\}andf−f^\{\-\}

16:ifcriterion

jjis benefitthen

17:

f∗​\[j\]←maxi⁡F​\[i,j\]f^\{\*\}\[j\]\\leftarrow\\max\_\{i\}F\[i,j\]
18:

f−​\[j\]←mini⁡F​\[i,j\]f^\{\-\}\[j\]\\leftarrow\\min\_\{i\}F\[i,j\]
19:else

20:

f∗​\[j\]←mini⁡F​\[i,j\]f^\{\*\}\[j\]\\leftarrow\\min\_\{i\}F\[i,j\]
21:

f−​\[j\]←maxi⁡F​\[i,j\]f^\{\-\}\[j\]\\leftarrow\\max\_\{i\}F\[i,j\]
22:endif

23:endfor

24:

25://Step 3: Compute normalized distancesdd

28:if

f∗​\[j\]=f−​\[j\]f^\{\*\}\[j\]=f^\{\-\}\[j\]then

29:

d​\[i,j\]←0d\[i,j\]\\leftarrow 0
30:elseifcriterion

jjis benefitthen

31:

d​\[i,j\]←f∗​\[j\]−F​\[i,j\]f∗​\[j\]−f−​\[j\]d\[i,j\]\\leftarrow\\dfrac\{f^\{\*\}\[j\]\-F\[i,j\]\}\{f^\{\*\}\[j\]\-f^\{\-\}\[j\]\}
32:else

33:

d​\[i,j\]←F​\[i,j\]−f∗​\[j\]f−​\[j\]−f∗​\[j\]d\[i,j\]\\leftarrow\\dfrac\{F\[i,j\]\-f^\{\*\}\[j\]\}\{f^\{\-\}\[j\]\-f^\{\*\}\[j\]\}
34:endif

35:endfor

36:endfor

37:

38://Step 4: ComputeSiS\_\{i\}andRiR\_\{i\}

39:

W←\[0\.40,0\.35,0\.25\]W\\leftarrow\[0\.40,0\.35,0\.25\]
41:

S​\[i\]←∑jW​\[j\]⋅d​\[i,j\]S\[i\]\\leftarrow\\sum\_\{j\}W\[j\]\\cdot d\[i,j\]
42:

R​\[i\]←maxj⁡W​\[j\]⋅d​\[i,j\]R\[i\]\\leftarrow\\max\_\{j\}W\[j\]\\cdot d\[i,j\]
43:endfor

44:

45://Step 5: Compute compromise indexQiQ\_\{i\}

46:

S∗←mini⁡S​\[i\]S^\{\*\}\\leftarrow\\min\_\{i\}S\[i\]
47:

S−←maxi⁡S​\[i\]S^\{\-\}\\leftarrow\\max\_\{i\}S\[i\]
48:

R∗←mini⁡R​\[i\]R^\{\*\}\\leftarrow\\min\_\{i\}R\[i\]
49:

R−←maxi⁡R​\[i\]R^\{\-\}\\leftarrow\\max\_\{i\}R\[i\]
52:

t​e​r​m​S←\{S​\[i\]−S∗S−−S∗,S−≠S∗0,otherwisetermS\\leftarrow\\begin\{cases\}\\dfrac\{S\[i\]\-S^\{\*\}\}\{S^\{\-\}\-S^\{\*\}\},&S^\{\-\}\\neq S^\{\*\}\\\\ 0,&\\text\{otherwise\}\\end\{cases\}
53:

t​e​r​m​R←\{R​\[i\]−R∗R−−R∗,R−≠R∗0,otherwisetermR\\leftarrow\\begin\{cases\}\\dfrac\{R\[i\]\-R^\{\*\}\}\{R^\{\-\}\-R^\{\*\}\},&R^\{\-\}\\neq R^\{\*\}\\\\ 0,&\\text\{otherwise\}\\end\{cases\}
54:

Q​\[i\]←v⋅t​e​r​m​S\+\(1−v\)⋅t​e​r​m​RQ\[i\]\\leftarrow v\\cdot termS\+\(1\-v\)\\cdot termR
55:endfor

56:return

nb​e​s​t←arg⁡mini⁡Q​\[i\]n\_\{best\}\\leftarrow\\arg\\min\_\{i\}Q\[i\]

The computational complexity of the VIKOR scoring procedure is𝒪​\(m​k\)\\mathcal\{O\}\(mk\)for computing theSiS\_\{i\}andRiR\_\{i\}measures, wheremmis the number of candidate nodes andkkis the number of criteria\. The subsequent computation of the compromise indexQiQ\_\{i\}and the selection of the minimum value require𝒪​\(m\)\\mathcal\{O\}\(m\)time, resulting in an overall linear complexity\. In typical edge\-cluster scenarios, where the number of candidate nodes per allocation decision is limited, this cost remains negligible\.

## 5CRAWO implementation

We developed the reference implementation of the CRAWO platform as a distributed system following the microservices architecture pattern\. To ensure portability and scalability across edge environments, the components are containerized and deployed on K3s, a lightweight Kubernetes distribution certified by the Cloud Native Computing Foundation \(CNCF\) and specifically designed for resource\-constrained clusters\. K3s preserves full compatibility with the Kubernetes API while reducing the system footprint by consolidating components and minimizing runtime dependencies, making it well\-suited for edge deployments\.

### 5\.1Control Plane

TheControl Planecomprises three core microservices implemented in Java 17 using Spring Boot 3\.0\. This stack was selected for its mature ecosystem and strong type safety, which are essential for managing complex domain models in distributed systems\.

TheManageracts as the entry point and API Gateway\. In the current implementation, it utilizes a PostgreSQL database to persist infrastructure descriptions and pipeline topologies\. While the CRAWO architecture conceptually models all entities as native Kubernetes CRDs, a relational database is used to accelerate validation of management logic\. The textitManager translates high\-level user requests into strongly typedTaskAllocationCRs, serving as the primary interface between theControl Planeand theExecution Plane\.

TheAllocatoris logically decoupled from the management layer and encapsulates the framework’s core decision\-making logic\. It exposes a RESTful interface to process allocation requests using the VIKOR MCDM method\. The decision process balances performance \(throughput\) against resource constraints \(latency and node load\)\. By relying on data from theContextcomponent, theAllocatorremains independent of direct interactions with the infrastructure\.

TheContextcomponent serves as the framework’s information repository\. It aggregates static hardware descriptions, calibrated performance profiles, and real\-time operational metrics \(e\.g\., node availability and resource utilization\)\. This component provides the situational awareness required for theAllocatorto perform hardware\-aware, adaptive scheduling\.

### 5\.2Data Plane

TheData Planestate is modeled using Kubernetes CRDs that extend the Kubernetes API to support CRAWO’s domain\-specific requirements\. These CRDs establish a formal contract for state synchronization between theControl Planeand theExecution Plane\.

The infrastructure and inputs are represented by theProcessingNodeandDataSourceresources\.ProcessingNodeencapsulates the state of edge compute units \(e\.g\., NVIDIA Jetson, Raspberry Pi\), storing hardware capabilities \(e\.g\., CPU, RAM, and GPU availability\) and scheduling labels\.DataSourcemodels input streams, such as RTSP camera feeds, and encapsulates the connection URIs and authentication credentials required for data consumption\.

The software catalog is defined throughServiceDefinitionandTopologyTemplateresources\. The former defines individual pipeline components, specifying container images and environment variables, while the latter arranges these services into a directed acyclic graph to represent complex workflows\.

Finally, theTaskAllocationserves as the central artifact of the orchestration process\. It binds aTopologyTemplateto a specificProcessingNodeandDataSource, thereby declaring the desired state of a running pipeline and triggering the reconciliation loop\.

### 5\.3Execution Plane

The execution logic resides in theOperator, a custom Kubernetes controller developed in Go using the Kubebuilder framework\.222[https://github\.com/kubernetes\-sigs/kubebuilder](https://github.com/kubernetes-sigs/kubebuilder)This choice leverages Go’s native efficiency and Kubebuilder’s code\-generation capabilities for robust Kubernetes API interactions\.

The Operator employs a watch mechanism onTaskAllocationresources to trigger an idempotent reconciliation sequence\. For each pipeline stage, the controller:

1. 1\.Generates aConfigMapcontaining runtime parameters
2. 2\.Instantiates aDeploymentusing the specified container image\.
3. 3\.Injects anodeSelectorto pin the workload to the specific edge node selected by theAllocator
4. 4\.Provisions aService\(ClusterIP, NodePort, or LoadBalancer\) to ensure network accessibility

The control loop is closed by continuously monitoring the created resources and reflecting their aggregated state \(e\.g\., pending, running, or failed\) back into theTaskAllocationstatus field, providing real\-time feedback to theControl Plane\.

## 6LPR use case using CRAWO

This section demonstrates the practical application of the CRAWO framework by instantiating the vehicular surveillance use case introduced in Section[2](https://arxiv.org/html/2607.20490#S2)\. This LPR solution is being integrated into CAD\-Patrol\[[9](https://arxiv.org/html/2607.20490#bib.bib36)\], a mobile system designed to optimize public safety incident response and enhance situational awareness for officers in the field\. By leveraging 5G connectivity, edge computing, and AI, CAD\-Patrol enables real\-time analysis of video captured by smartphone\-based cameras\. Processing is performed directly on the vehicle’s onboard unit at the network edge, ensuring low latency and operational continuity even in environments with unstable backhaul\.

CAD\-Patrol is developed using the SAALSA framework\[[7](https://arxiv.org/html/2607.20490#bib.bib34),[8](https://arxiv.org/html/2607.20490#bib.bib33)\], which provides the underlying intelligent video processing, and utilizes CRAWO as its primary orchestrator\. Both solutions are part of the SPICI,333[https://smlab\.imd\.ufrn\.br/spici/en](https://smlab.imd.ufrn.br/spici/en)an R&D project aimed at developing integrated public safety applications leveraging 5G networks\. These applications have strict requirements for reliable communication, high availability, and low latency in information transfer\. Consequently, they require a 5G network infrastructure that provides high capacity and communication speed, supporting a massive number of devices with minimal latency\.

To instantiate CRAWO, the LPR pipeline stages are modeled as a set of CRD manifests\. Each resource addresses a specific orchestration concern:

- •ServiceDefinition: describes a containerized pipeline stage\.
- •TopologyTemplate: encodes the processing directed acyclic graph and its hardware requirements\.
- •ProcessingNode: registers the physical edge infrastructure\.
- •DataSource: binds the video feed \(e\.g\., RTSP\) to the pipeline entry point\.
- •TaskAllocation: records the placement decision produced by theAllocator\.

### 6\.1Pipeline definition and implementation

The LPR pipeline is decomposed into four sequential stages, following a cascaded detection\-recognition pattern: Vehicle Detection, Plate Detection, OCR Processing, and Notification \(database verification\)\. The first three stages require GPU acceleration for real\-time inference, while the notification stage performs lightweight lookups that can be handled by any CPU\-based node\. Figure[6](https://arxiv.org/html/2607.20490#S6.F6)\. shows the pipeline dataflow structure\.

![Refer to caption](https://arxiv.org/html/2607.20490v1/images/lpr_pipeline4.jpg)Figure 6:Four\-stage LPR pipelineTheTopologyTemplate\(see Listing[1](https://arxiv.org/html/2607.20490#LST1)\) encodes these relationships\. ThehardwareConstraintsblock at each stage is the only placement directive required from the human operator\. TheAllocatoruses these constraints, along with real\-time node metrics, to determine optimal assignments, removing the need for manual node selection\.

Listing 1:TopologyTemplatefor the LPR pipelineapiVersion:orchestration\.saalsa\.spici/v1

kind:TopologyTemplate

metadata:

name:lpr\-pipeline

spec:

description:"LicensePlateRecognitionPipeline"

stages:

\-name:vehicle\-detection

serviceRef:vehicle\-detector

hardwareConstraints:

gpu:true

minMemoryMB:2048

\-name:plate\-detection

serviceRef:plate\-detector

hardwareConstraints:

gpu:true

minMemoryMB:1024

\-name:ocr\-processing

serviceRef:plate\-ocr

hardwareConstraints:

gpu:true

minMemoryMB:1024

\-name:notification

serviceRef:notification\-service

hardwareConstraints:

gpu:false

minMemoryMB:512

The video source is declared as a separateDataSourceresource \(see Listing[2](https://arxiv.org/html/2607.20490#LST2)\), which binds the RTSP stream from the on\-board camera to the pipeline entry point\. Decoupling the data source from the processing graph allows the sameTopologyTemplateto be reused across different patrol vehicles without modifying the core pipeline definition\.

Listing 2:DataSourcebinding the patrol vehicle’s camera to the LPR pipelineapiVersion:orchestration\.saalsa\.spici/v1

kind:DataSource

metadata:

name:camera\-patrol\-01

spec:

protocol:rtsp

uri:"rtsp://192\.168\.1\.10:554/stream"

pipelineRef:lpr\-pipeline

entryStage:vehicle\-detection

Finally, the heterogeneous nodes aboard the vehicle are registered asProcessingNoderesources\(see Listing[3](https://arxiv.org/html/2607.20490#LST3)\), providing theAllocatorwith a stable hardware profile \(GPU availability, core count, memory\) for constraint filtering and eliminating runtime capability queries during scheduling\.

Listing 3:ProcessingNodedefinitions for the vehicular clusterapiVersion:orchestration\.saalsa\.spici/v1

kind:ProcessingNode

metadata:

name:patrol\-01\-rpi

spec:

hostname:"rpi\-patrol\-01"

capabilities:

cpu:"ARMCortex\-A72"

cores:4

memoryMB:4096

gpu:false

labels:

vehicle:"patrol\-01"

role:"acquisition"

\-\-\-

apiVersion:orchestration\.saalsa\.spici/v1

kind:ProcessingNode

metadata:

name:patrol\-01\-jetson

spec:

hostname:"jetson\-patrol\-01"

capabilities:

cpu:"ARMCortex\-A78AE"

cores:12

memoryMB:32768

gpu:true

gpuModel:"NVIDIAAmpere"

cudaCores:2048

labels:

vehicle:"patrol\-01"

role:"inference"

### 6\.2Allocation decision and orchestration

Upon receiving a deployment request, theManagervalidates theTopologyTemplateagainst the availableProcessingNodepool and invokes theAllocator\. For the three GPU\-dependent stages, the hardware filter immediately identifiespatrol\-01\-jetsonas the only viable candidate, so no multi\-criteria ranking is required\.

For the Notification stage, both the NVIDIA Jetson and the Raspberry Pi devices \(patrol\-01\-rpi\) meet the basic CPU and memory constraints\. In this case, the VIKOR\-based mechanism constructs a decision matrix evaluating processing capacity \(IPT, benefit weight 0\.40\), network Latency \(cost weight 0\.35\), and current processor load \(cost weight 0\.25\)\. If the NVIDIA Jetson is heavily committed to the preceding inference stages, its load score is penalized, allowing the lightly loaded Raspberry Pi to rank higher for this CPU\-bound task\. The resulting placement is persisted as aTaskAllocationresource \(see Listing[4](https://arxiv.org/html/2607.20490#LST4)\), serving as the execution contract between theControl Planeand theExecution Plane\.

Listing 4:TaskAllocationproduced by theAllocatorfor the LPR pipelineapiVersion:orchestration\.saalsa\.spici/v1

kind:TaskAllocation

metadata:

name:lpr\-pipeline\-alloc\-v1

spec:

pipelineRef:lpr\-pipeline

assignments:

\-stage:vehicle\-detection

nodeSelector:

kubernetes\.io/hostname:jetson\-patrol\-01

\-stage:plate\-detection

nodeSelector:

kubernetes\.io/hostname:jetson\-patrol\-01

\-stage:ocr\-processing

nodeSelector:

kubernetes\.io/hostname:jetson\-patrol\-01

\-stage:notification

nodeSelector:

kubernetes\.io/hostname:rpi\-patrol\-01

Upon persistence of theTaskAllocation, theOperatorthen initiates the reconciliation loop described in Section[5](https://arxiv.org/html/2607.20490#S5)\. For each stage, it provisions aConfigMapfor runtime parameters, aDeploymentwith the designatednodeSelector, and aServicefor inter\-stage communication\. This translates the declarative allocation into a running inference pipeline with no further operator intervention\.

## 7Evaluation

This section presents a systematic evaluation of CRAWO through discrete\-event simulation using YAFS \(Yet Another Fog Simulator\)\[[6](https://arxiv.org/html/2607.20490#bib.bib12)\], a Python\-based framework for fog computing environments\. To evaluate the performance and viability of the framework, we formulate three research questions that address the fundamental trade\-offs in edge orchestration:

1. RQ1 –Decision quality and efficacy: How does the VIKOR\-based allocation strategy compare to traditional heuristics and the TOPSIS algorithm regarding end\-to\-end latency, load balancing, and resource utilization? Furthermore, how sensitive is this performance advantage to increases in workload intensity?
2. RQ2 –Scalability and network sensitivity: To what extent does the framework maintain stable performance as the infrastructure scales, and how do varying 5G network conditions impact its coordination efficiency?
3. RQ3 –Deployment architecture: What are the quantifiable benefits of the CRAWO edge\-distributed execution model in terms of latency reduction and bandwidth preservation when compared to a conventional cloud\-only baseline?

We detail the experimental process in the following\. Section[7\.1](https://arxiv.org/html/2607.20490#S7.SS1)defines performance metrics\. Section[7\.2](https://arxiv.org/html/2607.20490#S7.SS2)describes the simulation environment in terms of topology, application, and network models\. Section[7\.3](https://arxiv.org/html/2607.20490#S7.SS3)presents the experimental design\. Section[7\.4](https://arxiv.org/html/2607.20490#S7.SS4)details the simulation implementation\. Results appear in Section[7\.5](https://arxiv.org/html/2607.20490#S7.SS5), followed by a discussion in Section[7\.6](https://arxiv.org/html/2607.20490#S7.SS6)\.

### 7\.1Evaluation metrics

Four complementary metrics are employed to characterize the allocation strategies from distinct performance perspectives, as summarized in Table[4](https://arxiv.org/html/2607.20490#S7.T4):

- •End\-to\-end latency\(Le​2​eL\_\{e2e\}\): it measures total elapsed time from frame capture at the source to notification delivery at the sink, capturing user\-perceived responsiveness\.
- •Processing time\(Tp​r​o​cT\_\{proc\}\): it isolates computational efficiency by aggregating execution time across all pipeline stages, excluding network overhead\.
- •Network delay\(Tn​e​tT\_\{net\}\): it quantifies infrastructure impact as the cumulative transmission and queuing time across all inter\-node hops\.
- •Resource utilization\(UU\): it measures the effectiveness of workload distribution as the mean fraction of computational capacity actively engaged across all edge nodes\.

For each metric, we report the mean and 95% confidence interval across ten independent simulation runs with different random seeds to ensure statistical significance\.

Table 4:Performance metrics
### 7\.2Simulation environment

We utilize YAFS v3\.1 to model computational resources, network links, and application workloads as discrete events, enabling precise measurement of latency distributions and resource utilization patterns under controlled conditions\. The adoption of a simulation environment was a deliberate methodological choice aimed at isolating the pure decision\-making behavior of the allocation algorithms from hardware\-induced noise\. Real\-world edge deployments are subject to confounding factors not captured by the model, including operating\-system scheduling jitter, thermal throttling of edge accelerators under sustained load, flash\-storage I/O bottlenecks, and non\-deterministic 5G handoff events\. By parameterizing the infrastructure as a discrete\-event system with deterministic resource attributes, YAFS establishes a clear theoretical performance bound that allows the correctness and relative efficacy of the VIKOR\-based decision logic to be rigorously validated\. This controlled baseline serves as an essential prerequisite for the physical deployment validation planned as future work \(see Section[8](https://arxiv.org/html/2607.20490#S8)\)\.

#### 7\.2\.1Topology model

The simulated infrastructure represents a hierarchical smart city vehicular surveillance deployment organized into three tiers\. At the top, the cloud tier \(Node 0\) is modeled as a central server \(50,000 MIPS, 128 GB RAM, and GPU support\) with a fixed 100 ms propagation delay to the gateway, reflecting typical wide\-area network round\-trip times\. The gateway tier \(Node 1\) serves as an aggregation point with moderate resources \(1,000 MIPS, 16 GB RAM\) that bridges the cloud and the distributed edge\. At the bottom, the edge tier \(Nodes 2 throughNN\) comprises heterogeneous nodes representing patrol vehicles randomly placed across a 1 km×\\times1 km urban area under a 5G geometric proximity model with a 300 m coverage radius\.

To reflect real\-world diversity, edge nodes are distributed as follows: 25% NVIDIA Jetson\-class \(10,000 MIPS, GPU\), 25% Hailo\-accelerator\-equipped \(10,000 MIPS, GPU\), and 50% Raspberry Pi\-class \(1,000 MIPS, CPU\-only\)\. Network links follow a 5G model with a 300 m coverage radius\. As a result, approximately half of the edge nodes are GPU\-capable, creating the kind of heterogeneity that makes hardware\-aware allocation essential\. Network links between edge nodes and the gateway carry propagation delays computed as the base 5G latency plus 2 ms km\-1, proportional to physical distance\. Peer\-to\-peer links between geographically proximate edge nodes \(within 300 m\) carry half the base latency plus the distance\-dependent term, modeling direct vehicular 5G communication\.

#### 7\.2\.2Application model

The LPR pipeline serves as a stress\-inducing workload for heterogeneous orchestration, transitioning from GPU\-intensive inference \(Vehicle and Plate Detection\) to lightweight CPU\-bound tasks \(OCR and Notification\)\. This worst\-case scenario for hardware\-aware allocation forces the orchestrator to satisfy conflicting resource affinities within a single execution chain\. A policy that routes early stages correctly to GPU\-capable nodes must simultaneously redirect later stages to CPU\-sufficient nodes, forcing genuinely heterogeneous decisions at every pipeline invocation\. This architectural characteristic makes LPR an ideal stress test for theAllocator’s multi\-criteria logic and justifies its use as the sole evaluative workload in this study\.

The pipeline is modeled as a directed acyclic graph comprising four sequential stages, each calibrated to published performance profiles for the target hardware classes\. In the first stage, Vehicle Detection receives 25 KB H\.264\-encoded key\-frames, corresponding to a 6 Mbps stream subsampled to 1 FPS for LPR analysis\[[1](https://arxiv.org/html/2607.20490#bib.bib13)\], and isolates vehicle regions using a YOLO\-based detection model parameterized with150×106150\\times 10^\{6\}instructions, equivalent to approximately 15 ms of inference on a NVIDIA Jetson Xavier NX \(21 TOPS, TensorRT\)\[[5](https://arxiv.org/html/2607.20490#bib.bib14)\]\.

The second stage, Plate Detection, processes 9 KB vehicle region\-of\-interest crops to localize license plate bounding boxes, also requiring150×106150\\times 10^\{6\}instructions\. The third stage, OCR, applies character segmentation and classification to 5 KB cropped plate images using a lightweight convolutional recurrent neural network \(CRNN\) model parameterized with10×10610\\times 10^\{6\}instructions, corresponding to approximately 1 ms on GPU\-enabled nodes\.

The final Notification stage transmits 100 B OCR results to the central cloud for logging and alert generation\. A selectivity threshold of 1\.0 is applied uniformly across all service modules, ensuring that every input frame propagates through all subsequent stages and thereby establishing a worst\-case load scenario for the allocation strategies\.

#### 7\.2\.3Workload and network models

Camera streams generate workload according to a Poisson process with arrival rateλ=1\.0\\lambda=1\.0events/s\-1per camera, corresponding to a 1 FPS key\-frame submission rate for LPR analysis\. This rate reflects the common operational practice in vehicular surveillance systems, where cameras record locally at full frame rate \(e\.g\., 30 FPS\) but forward only selected key\-frames for inference to limit network and computational load\[[1](https://arxiv.org/html/2607.20490#bib.bib13)\]\. The number of cameras per edge node is treated as an experimental variable with three levels \(1, 2, or 4\), enabling evaluation under light, moderate, and high workload conditions, respectively\. At the highest intensity \(four cameras across 100 edge nodes\), the system must process up to 400 FPS, placing substantial stress on GPU\-capable nodes and demanding accurate allocation decisions to prevent saturation of NVIDIA Jetson and Hailo devices while Raspberry Pi nodes \(CPU\-only\) remain ineligible for GPU\-accelerated stages\. Notification sink modules are deployed on all edge nodes, allowing results to be consumed locally without requiring a round\-trip to the cloud\.

Three 5G network profiles, derived from 3GPP Release 16 specifications,444[https://www\.3gpp\.org/specifications\-technologies/releases/release\-16](https://www.3gpp.org/specifications-technologies/releases/release-16)are evaluated to capture a range of operational conditions \(see Table[5](https://arxiv.org/html/2607.20490#S7.T5)\)\. We considered an ideal scenario \(1 ms latency, 1,000 Mbps bandwidth\) representing optimal mmWave 5G conditions, a typical urban scenario \(5 ms, 500 Mbps\) reflecting mid\-band deployment, and a congested scenario \(10 ms, 100 Mbps\) modeling peak\-hour network degradation\.

Table 5:5G network parameters
#### 7\.2\.4Allocation Strategies

We compared five allocation strategies, spanning two MCDM methods and three conventional heuristics\. VIKOR, the default strategy adopted in CRAWO, computes a compromise ranking that jointly minimizes the global weighted utility measureSSand the maximum individual regretRRunder three decision criteria: inference throughput in MIPS as a benefit criterion \(40% weight\), network latency as a cost criterion \(35%\), and current node queue length as a cost criterion \(25%\), with the balance parameter set toν=0\.5\\nu=0\.5\. TOPSIS is included as an MCDM baseline that applies the same criteria and weights but selects the alternative closest to the ideal solution and farthest from the anti\-ideal in the normalized criterion space\.

Three heuristic baselines provide reference points of increasing sophistication\. Random selection assigns each task uniformly at random among feasible nodes without inspecting the runtime state, serving as the simplest possible baseline\. Round\-Robin distributes tasks cyclically across all feasible nodes, implicitly assuming uniform processing capabilities\. Least\-Loaded selects the node with the smallest current queue length at dispatch time, thereby optimizing for immediate resource availability but without accounting for hardware heterogeneity or network distance\.

### 7\.3Experimental design

The evaluation follows a full factorial design with two related test campaigns, summarized in Table[6](https://arxiv.org/html/2607.20490#S7.T6)\.

Table 6:Experimental parameters and scenario configurations\.Scenario 1: Strategy Comparison \(RQ1–RQ2\)ParameterValuesCombinationsEdge nodes10, 50, 1003Cameras per node1, 2, 43StrategiesTOPSIS, VIKOR, Random, Round\-Robin, Least\-Loaded5Network conditions1 ms/1 Gbps, 5 ms/500 Mbps, 10 ms/100 Mbps3Seeds1–1010Total runs = 1,350Scenario 2: Deployment Architecture \(RQ3\)ParameterValuesCombinationsEdge nodes100 \(fixed\)1Cameras per node2 \(fixed\)1Deploymentdistributed/VIKOR, cloud\_only/Random2Network conditions5ms/500Mbps \(fixed\)1Seeds1–1010Total runs = 20Scenario 1 – Strategy Comparisoncrosses all five allocation strategies against three deployment scales \(10, 50, and 100 edge nodes\), three workload intensities \(1, 2, and 4 cameras per node\), and three 5G network profiles\. With ten independent random seeds, this yields a total of 1,350 simulation runs\. At one camera per node, GPU utilization remains near 12%, making most strategies perform similarly\. However, with 4 cameras per node, NVIDIA Jetson and Hailo devices approach saturation, while Raspberry Pi nodes remain ineligible for GPU stages, forcing the allocator to actively differentiate between heterogeneous hardware capabilities\.

Scenario 2 – Deployment Architectureisolates the impact of processing placement\. It compares edge\-distributed execution \(under the VIKOR strategy\) against a cloud\-only baseline at a fixed scale of 100 nodes and two cameras per node under typical 5G conditions \(5 ms, 500 Mbps\)\. Replicated across ten seeds, this adds 20 simulation runs\. To ensure consistent data collection, each simulation runs for 600 s, with the first 120 s as a warm\-up period to bring the system to steady state before performance measurements are recorded\.

### 7\.4Simulation implementation

We implemented the simulation by extending the five core abstractions provided by the YAFS framework\[[6](https://arxiv.org/html/2607.20490#bib.bib12)\]\. TheTopology Abstractionmodels the physical infrastructure as a weighted graph, where nodes carry computational attributes \(processing capacity, memory, GPU availability\) and edges carry network parameters \(bandwidth and propagation delay\)\. TheApplication Abstractiondefines the LPR pipeline as a directed acyclic graph of service modules connected by typedMessageobjects, each parameterized with an instruction count and a payload size in bytes\.

Two placement policies govern the initial deployment of service modules onto topology nodes\. ADistributed Policythat registers all pipeline stages on every node, delegating all runtime routing decisions to the selection strategy, and aCloud\-Only Policyrestricts all modules exclusively to the cloud node, thereby establishing the centralized baseline\. A customPopulation Policygenerates workload by attaching a configurable number of camera sources per edge node \(1, 2, or 4\), each emitting key frames according to an exponential inter\-arrival distribution with rateλ=1\.0\\lambda=1\.0events s\-1, and by placing notification sinks at all edge nodes to enable local result collection\. Finally, theSelection Policyis invoked at runtime for every in\-flight message to determine the target service instance and the associated routing path\. All five allocation strategies are implemented asSelectionsubclasses, each overriding theget\_pathmethod\.

### 7\.5Results

This section presents the experimental results derived from the two test campaigns, directly addressing the three research questions\. Section[7\.5\.1](https://arxiv.org/html/2607.20490#S7.SS5.SSS1)details the results forScenario 1 – Strategy Comparison, which evaluate the efficacy and decision quality \(RQ1\) as well as the scalability \(RQ2\) of the allocation strategies across varying scales, workloads, and 5G network profiles\. Section[7\.5\.2](https://arxiv.org/html/2607.20490#S7.SS5.SSS2)presents the results forScenario 2 – Deployment Architecture, addressing the architectural trade\-offs \(RQ3\) by comparing edge\-distributed execution with a cloud\-only baseline\.

#### 7\.5\.1Scenario 1 results

Table[7](https://arxiv.org/html/2607.20490#S7.T7)reports the mean end\-to\-end pipeline latency \(ms\) by strategy, deployment scale, and workload intensity across three 5G network profiles, averaged over ten seeds\. In turn, TableLABEL:tab:utilization\_resultspresents the corresponding load\-balancing coefficient of variation \(CV=σ/μ=\\sigma/\\mu\) and pipeline failure rate for each strategy, deployment scale, and workload intensity across three 5G network profiles, averaged over ten seeds\.

Table 7:Mean end\-to\-end latency across all experimental conditionsTable 8:Load coefficient of variation \(CV\) and pipeline failure ratesStrategy10 nodes50 nodes100 nodes1 cam2 cam4 cam1 cam2 cam4 cam1 cam2 cam4 camCV — Ideal \(1 ms / 1,000 Mbps\)TOPSIS0\.5410\.5270\.4810\.5170\.4910\.4480\.5400\.5100\.454VIKOR0\.5410\.5270\.4810\.5170\.4910\.4480\.5400\.5100\.454Random0\.0310\.0200\.0150\.0260\.0190\.0210\.0270\.0190\.020Round\-Robin0\.0010\.0000\.0000\.0010\.0000\.0170\.0010\.0000\.014Least\-Loaded0\.0310\.0420\.1210\.0280\.0440\.1450\.0280\.0440\.151CV — Typical \(5 ms / 500 Mbps\)TOPSIS0\.4370\.4330\.4000\.5170\.4910\.4480\.5400\.5100\.454VIKOR0\.5410\.5270\.4810\.5170\.4910\.4480\.5400\.5100\.454Random0\.0260\.0200\.0150\.0280\.0180\.0220\.0260\.0190\.020Round\-Robin0\.0010\.0000\.0000\.0010\.0000\.0170\.0010\.0000\.014Least\-Loaded0\.0250\.0440\.1190\.0270\.0440\.1440\.0290\.0440\.150CV — Congested \(10 ms / 100 Mbps\)TOPSIS0\.5460\.4690\.4081\.847†1\.578†1\.406†0\.5400\.5100\.455VIKOR0\.4480\.4440\.3810\.5170\.4910\.4490\.5400\.5100\.455Random0\.0300\.0190\.0140\.0250\.0190\.0210\.0250\.0190\.020Round\-Robin0\.0010\.0000\.0000\.0010\.0000\.0170\.0010\.0000\.014Least\-Loaded0\.0300\.0410\.1200\.0300\.0440\.1440\.0290\.0450\.150Failure rate \(%\) — Ideal \(1 ms / 1,000 Mbps\)TOPSIS0\.000\.000\.000\.010\.000\.000\.000\.000\.00VIKOR0\.000\.000\.000\.010\.000\.000\.000\.000\.00Random0\.000\.010\.010\.020\.010\.450\.010\.010\.29Round\-Robin0\.000\.000\.000\.010\.010\.470\.010\.010\.30Least\-Loaded0\.000\.000\.730\.020\.011\.010\.020\.010\.59Failure rate \(%\) — Typical \(5 ms / 500 Mbps\)TOPSIS0\.000\.000\.000\.010\.000\.000\.000\.000\.00VIKOR0\.000\.000\.000\.010\.000\.000\.000\.000\.00Random0\.000\.010\.010\.010\.020\.430\.010\.010\.29Round\-Robin0\.000\.000\.000\.010\.010\.460\.010\.010\.30Least\-Loaded0\.000\.010\.710\.010\.011\.010\.010\.010\.58Failure rate \(%\) — Congested \(10 ms / 100 Mbps\)TOPSIS0\.000\.64†1\.81†8\.42†13\.70†20\.28†0\.000\.000\.00VIKOR0\.000\.000\.000\.000\.000\.000\.000\.000\.00Random0\.000\.000\.030\.010\.020\.440\.020\.000\.28Round\-Robin0\.000\.000\.000\.010\.020\.460\.020\.000\.30Least\-Loaded0\.000\.000\.550\.010\.020\.970\.020\.010\.58†denotes TOPSIS routing instability under congestionThree principal observations emerge from the analysis of these two tables\. First, both MCDM methods \(VIKOR and TOPSIS\) consistently achieve substantially lower latencies than the three heuristic baselines across all tested configurations\. Under typical 5G conditions at 100 nodes and four cameras per node, VIKOR and TOPSIS deliver mean latencies of 33 ms, compared to 1,061 ms for Round\-Robin \(a 96\.9% reduction\), 1,189 ms for Random \(97\.2% reduction\), and 1,757 ms for Least\-Loaded \(98\.1% reduction\)\.

Second, VIKOR and TOPSIS perform identically at 50 and 100 nodes under ideal and typical 5G profiles\. Under these favorable conditions, both MCDM strategies exhibit CV values of approximately 0\.44–0\.54 \(see TableLABEL:tab:utilization\_results\), which reflect intentional GPU\-preferential routing rather than load imbalance\. However, under the congested profile \(10 ms, 100 Mbps\), TOPSIS exhibits routing instability at 10 and 50 nodes, with latencies escalating to 7,912 ms \(50 nodes, one camera\), CV exceeding 1\.0, and failure rates reaching 20\.28% \(50 nodes, four cameras\)\. In contrast, VIKOR remains stable across all conditions, maintaining latencies below 43 ms and failure rates lower than 0\.005%\. This confirms VIKOR’s suitability for dynamic edge environments where criteria are inherently conflicting\.

Third, the performance gap between MCDM and heuristics widens as workload intensity increases \(see Figure[7](https://arxiv.org/html/2607.20490#S7.F7)\)\. This reflects the critical role of hardware\-aware allocation as GPU\-capable nodes approach saturation\. Heuristic baselines, lacking hardware awareness, increasingly misroute tasks to CPU\-only Raspberry Pi nodes, causing cascading queue buildup and system\-wide latency spikes\.

![Refer to caption](https://arxiv.org/html/2607.20490v1/images/fig2_workload_intensity.png)Figure 7:Mean end\-to\-end latency \(ms, log scale\) as a function of workload intensity \(cameras per node\) for all five allocation strategies at 100 edge nodes under typical 5G conditions \(5 ms, 500 Mbps\)\.
#### 7\.5\.2Scenario 2 results

Table[9](https://arxiv.org/html/2607.20490#S7.T9)and Figure[8](https://arxiv.org/html/2607.20490#S7.F8)compare edge\-distributed execution under VIKOR against the cloud\-only baseline at 100 edge nodes with two cameras per node under typical 5G conditions\. All throughput and load\-served values are measured over the steady\-state window \(120–600 s\) against an offered load of 200 FPS \(100 nodes×\\times2 cameras×\\times1 FPS\)\. The edge\-distributed deployment achieves a mean end\-to\-end latency of 31\.9 ms with a P95 of 37\.8 ms, compared to 112\.0 ms and 112\.4 ms for the cloud\-only configuration\.

Table 9:Edge\-distributed \(VIKOR\) vs\. cloud\-only deployment at 100 edge nodes, two cameras per node, and typical 5G \(5 ms / 500 Mbps\), averaged over 10 seeds\.More critically, the edge deployment sustains a throughput of 199\.9 pipelines/s, serving 99\.9% of the offered load, whereas the cloud\-only server \(despite its 50,000 MIPS capacity\) reaches compute saturation at approximately 161 FPS and processes only 10\.0 pipelines/s \(5\.0% of the load\), leaving 95% of submitted frames unprocessed in the queue\. Network bandwidth consumption drops from 80\.0 Mbps under the cloud\-only configuration to 21\.2 Mbps under edge\-distributed execution, a 74% reduction\.

![Refer to caption](https://arxiv.org/html/2607.20490v1/images/fig6_edge_vs_cloud.png)Figure 8:Performance comparison of edge\-distributed \(VIKOR\) versus cloud\-only deployment across three metrics at 100 edge nodes and two cameras per node under typical 5G conditions \(5 ms / 500 Mbps\): mean end\-to\-end latency, pipeline throughput, and network bandwidth consumption\.

### 7\.6Discussion

This section discusses the CRAWO’s experimental results, focusing on the efficacy of the VIKOR allocation strategy \(RQ1\), its scalability across varying node counts and 5G conditions \(RQ2\), and the architectural advantages of edge execution over the cloud in terms of latency and network bandwidth \(RQ3\)\.

#### 7\.6\.1Strategy efficacy and decision quality \(RQ1\)

Within the evaluated LPR pipeline and 5G topology, the results indicate that the MCDM\-based allocation significantly outperforms conventional heuristics\. Under typical 5G conditions \(5 ms, 500 Mbps\) at 100 edge nodes, VIKOR reduces mean end\-to\-end latency by 85% compared to Random selection \(31\.4 ms vs\. 213\.7 ms at one camera per node\) and by 85–98%compared to Least\-Loaded across all workload intensities\. The performance gap is most evident at four cameras per node, where VIKOR achieves 33\.0 ms compared to 1,757 ms for Least\-Loaded, representing a 53\-fold improvement\. This widening advantage reflects the critical role of hardware\-aware allocation\. As GPU\-capable devices \(NVIDIA Jetson and Hailo\) approach saturation, any allocator that ignores hardware heterogeneity misroutes tasks to CPU\-only Raspberry Pi nodes\. This triggers a cascading buildup of queues and order\-of\-magnitude latency degradation\.

The comparison between the two MCDM algorithms also reveals an important distinction in robustness:

- •Convergence in ideal conditions:TOPSIS and VIKOR deliver nearly identical latencies at 50 and 100 nodes under favorable network conditions, confirming both methods converge to near\-optimal GPU\-preferential routing\.
- •Sensitivity to topology scale:VIKOR achieves sub\-32 ms latency even at ten nodes, whereas TOPSIS lags \(38\.6 ms\)\. This suggests VIKOR’s compromise\-regret formulation is less sensitive to queue\-length fluctuations in smaller topologies\.
- •Resilience to congestion:Under the congested profile \(10 ms, 100 Mbps\), TOPSIS exhibits instability, with latencies escalating to 7,912 ms and failure rates reaching 20\.28%, as shown in TableLABEL:tab:utilization\_results\. This occurs because elevated network delays inflate the queue\-state data, causing TOPSIS to over\-concentrate load on single nodes\. VIKOR’s regret\-minimization component acts as a safeguard against such concentration, ensuring that no single criterion \(such as a stale queue metric\) dominates the decision\.

#### 7\.6\.2Scalability \(RQ2\)

VIKOR exhibits good scale invariance, maintaining a mean latency below 33 ms across 10 to 100 nodes regardless of workload or network conditions\. This consistency suggests that the compromise\-regret formulation effectively selects GPU nodes even in constrained ten\-node deployments with a low ratio of GPU\-capable to CPU\-only nodes\. In contrast, TOPSIS requires a higher node density \(50 or more\) to achieve comparable performance under typical 5G conditions\.

The heuristic baselines exhibit substantially higher sensitivity to both scale and workload intensity\. Least\-Loaded, for example, incurs latencies of 3,113 ms and 3,041 ms at 10 and 50 nodes, respectively, with four cameras per node before improving to 1,757 ms at 100 nodes, still two orders of magnitude above VIKOR \(representing VIKOR latency reductions of 98\.9%, 98\.9%, and 98\.1% relative to Least\-Loaded at 10, 50, and 100 nodes, respectively\)\. This behavior highlights a limitation of queue\-length\-based heuristics in the heterogeneous environment tested: minimizing queue length without considering per\-node processing capacity misroutes GPU\-dependent tasks to CPU\-only nodes\. Across all 1,350 simulation runs in Scenario 1, VIKOR failure rates remain below 0\.01%, thereby indicating reliable execution within the tested scale range and network profiles\.

The heuristic baselines are highly sensitive to both scale and workload\. For instance, Least\-Loaded incurs latencies exceeding 3,000 ms at smaller scales \(10 and 50 nodes with four cameras per node\) before improving slightly at 100 nodes, even though it remains two orders of magnitude slower than VIKOR\. This behavior highlights the inherent limitation of queue\-length heuristics in the tested heterogeneous environment: minimizing queue length without accounting for processing capacity misroutes GPU\-dependent tasks to CPU\-only nodes\. Across all 1,350 simulation runs in Scenario 1, VIKOR failure rates remained below 0\.01%, proving its reliability across the tested scale range and network profiles\.

#### 7\.6\.3Deployment architecture \(RQ3\)

Scenario 2 quantifies the benefits of edge\-distributed processing\. VIKOR\-based edge execution reduces mean end\-to\-end latency by 71\.5% relative to cloud\-only deployment \(31\.9 ms vs\. 112\.0 ms\) and improves throughput by approximately 20 times \(199\.9 vs\. 10\.0 pipelines/s\), serving 99\.9% of the offered 200 FPS load compared to only 5\.0% for the cloud\-only configuration \(see Table[9](https://arxiv.org/html/2607.20490#S7.T9)\)\. The cloud server, despite its 50,000 MIPS capacity, reaches compute saturation at 161 FPS, leaving 95% of frames unprocessed within the 480 s measurement window\.

Beyond latency and throughput, CRAWO reduces network bandwidth consumption by 74%\. Because only 100\-byte notification messages traverse the wide\-area link \(rather than 25 KB full frames\), the distributed architecture significantly reduces infrastructure costs and preserves network capacity for concurrent smart city services\.

## 8Conclusion

The expansion of smart city applications, particularly real\-time AI video processing, exposes the critical limitations of cloud\-only architectures regarding prohibitive latency and significant pressure on network bandwidth\. While shifting computation to the edge mitigates these issues, the inherent hardware heterogeneity of these environments makes static deployments highly inefficient\. Consequently, AI\-based pipelines executed across diverse edge infrastructures require an intelligent, adaptive orchestration approach\.

To address this challenge, this work introduced the CRAWO framework, designed to manage distributed AI pipelines across heterogeneous edge clusters\. Operating alongside Kubernetes, CRAWO employs a control\-loop model divided into three functional planes\. TheControl Planeis responsible for intelligent decision\-making, theData Planehandles domain modeling using Kubernetes CRDs, and theExecution Planeensures continuous state reconciliation\. By decoupling orchestration logic from execution mechanisms, CRAWO treats processing pipelines as cohesive units and dynamically places stages based on real\-time runtime conditions\.

A fundamental contribution of the CRAWO architecture is its hardware\-aware allocator, which favors an MCDM approach over rigid scheduling rules\. Instead of relying on simplistic heuristics such as Random or Round\-Robin, CRAWO utilizes the VIKOR method to calculate a compromise ranking for task placement\. This strategy balances conflicting goals by maximizing inference throughput while minimizing network latency and node load, ensuring that intensive tasks are routed to appropriate GPU\-enabled nodes\.

We evaluated CRAWO through discrete\-event simulation using the YAFS framework, modeling a multi\-stage LPR pipeline deployed on mobile patrol vehicles under varying 5G network conditions\. The results demonstrated the superiority of the VIKOR\-based approach for:

- •Performance: end\-to\-end latency was reduced by up to 98% under high workload intensities compared to traditional heuristics\.
- •Robustness: unlike the TOPSIS baseline, which exhibited severe routing instability and 20\.28% failure rates in congested networks, VIKOR maintained stable routing with latencies consistently below 43 ms\.
- •Architectural efficiency: edge\-distributed execution reduced mean latency by 71\.5%, boosted throughput by 20 times, and lowered network bandwidth consumption by 74% compared to a cloud\-only model\.

Despite these results, this work has limitations that should be acknowledged\. The evaluation relied on discrete\-event simulation, while real\-world deployments may introduce additional variables not captured by the simulation model, such as hardware failures, operating system scheduling interference, and dynamic 5G handoffs\. Additionally, the study focused on a single LPR use case in a vehicular surveillance context, and we fixed the VIKOR method’s allocation criterion weights\. Generalization to other smart city pipelines or edge topologies requires further investigation\.

Future work will focus on four directions\. First, experimental validation on physical heterogeneous hardware clusters, including NVIDIA Jetson and Hailo\-equipped nodes, will complement simulation results presented in this work\. Next, we will extend VIKOR weight configuration to support adaptive or learned parameterization based on observed runtime performance, reducing the need for manual tuning\. Subsequently, we will evaluate CRAWO on additional AI pipeline use cases, such as anomaly detection and environmental monitoring, to assess its generalizability across diverse smart city applications\. Finally, we plan to replace the current relational database used for allocation state persistence with theetcdkey\-value store native to Kubernetes\. This migration will expose CRAWO’s state directly through the Kubernetes API, enabling atomic watch\-based notifications and seamless integration with the CRD reconciliation loop, thus ultimately reducing operational complexity and aligning the framework with modern cloud\-native models\.

## CRediT authorship contribution statement

Eugênio Santos:Investigation, Software, Formal analysis, Visualization, Writing – original draft\.Daniel Maia:Investigation, Software, Formal analysis, Visualization, Writing – original draft\.Stefano Loss:Investigation, Software, Supervision, Writing – original draft, Writing – review & editing\.José Manoel Silva:Investigation, Software\.Aluizio Rocha Neto:Methodology, Supervision, Validation, Writing – review & editing\.Thais Batista:Funding acquisition, Project administration, Validation, Writing – review & editing\.Everton Cavalcante:Validation, Writing – review & editing\.Nélio Cacho:Validation, Writing – review & editing\.Eduardo Nogueira:Validation, Writing – review & editing\.Daniel Araújo:Methodology, Supervision, Validation, Writing – review & editing\.Frederico Lopes:Funding acquisition, Project administration, Validation, Writing – review & editing\.

## Funding sources

This work is supported by the SPICI project, funded by FINEP \(grant 2827/22\), and the INCT Intelligent Communications Networks and the Internet of Things \- ICoNIoT, funded by CNPq \(grant 405940/2022\-0\) and CAPES \(grant 88887\.954253/2024\-00\)\.

## Declaration of competing interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper\.

## References

- \[1\]A\. Ammar, A\. Koubaa, W\. Boulila, B\. Benjdira, and Y\. Alhabashi\(2023\)A multi\-stage deep\-learning\-based vehicle and license plate recognition system with real\-time edge inference\.Sensors23\(4\)\.External Links:[Document](https://dx.doi.org/10.3390/s23042120)Cited by:[§7\.2\.2](https://arxiv.org/html/2607.20490#S7.SS2.SSS2.p2.1),[§7\.2\.3](https://arxiv.org/html/2607.20490#S7.SS2.SSS3.p1.2)\.
- \[2\]S\. Böhm and G\. Wirtz\(2022\-05\)Cloud\-edge orchestration for smart cities: a review of Kubernetes\-based orchestration architectures\.EAI Endorsed Transactions on Smart Cities6\(18\)\.External Links:[Document](https://dx.doi.org/10.4108/eetsc.v6i18.1197)Cited by:[§2\.1](https://arxiv.org/html/2607.20490#S2.SS1.p1.1),[§3\.1](https://arxiv.org/html/2607.20490#S3.SS1.p1.1),[§3\.2](https://arxiv.org/html/2607.20490#S3.SS2.p2.1),[§3](https://arxiv.org/html/2607.20490#S3.p2.1)\.
- \[3\]B\. Cheng, G\. Solmaz, F\. Cirillo, E\. Kovacs, K\. Terasawa, and A\. Kitazawa\(2017\-04\)FogFlow: easy programming of IoT services over cloud and edges for smart cities\.IEEE Internet of Things Journal5\(2\),pp\. 696–707\.External Links:[Document](https://dx.doi.org/10.1109/JIOT.2017.2747214)Cited by:[§1](https://arxiv.org/html/2607.20490#S1.p2.1),[§3\.2](https://arxiv.org/html/2607.20490#S3.SS2.p2.1),[§3](https://arxiv.org/html/2607.20490#S3.p1.1)\.
- \[4\]T\. P\. da Silva, T\. Batista, F\. Lopes, A\. R\. Neto, F\. C\. Delicato, P\. F\. Pires, and A\. R\. da Rocha\(2022\-11\)Fog computing platforms for smart city applications: a survey\.ACM Transactions on Internet Technology22\(4\)\.External Links:[Document](https://dx.doi.org/10.1145/3488585)Cited by:[§1](https://arxiv.org/html/2607.20490#S1.p3.1),[§3\.2](https://arxiv.org/html/2607.20490#S3.SS2.p2.1),[§3](https://arxiv.org/html/2607.20490#S3.p2.1)\.
- \[5\]P\. Kang and A\. Somtham\(2022\)An evaluation of modern accelerator\-based edge devices for object detection applications\.Mathematics10\(22\)\.External Links:[Document](https://dx.doi.org/10.3390/math10224299)Cited by:[§7\.2\.2](https://arxiv.org/html/2607.20490#S7.SS2.SSS2.p2.1)\.
- \[6\]I\. Lera, C\. Guerrero, and C\. Juiz\(2019\)YAFS: a simulator for IoT scenarios in fog computing\.IEEE Access7,pp\. 91745–91758\.External Links:[Document](https://dx.doi.org/10.1109/ACCESS.2019.2927895)Cited by:[§7\.4](https://arxiv.org/html/2607.20490#S7.SS4.p1.1),[§7](https://arxiv.org/html/2607.20490#S7.p1.1)\.
- \[7\]P\. Lira, K\. Costa, S\. Loss, L\. Lima, D\. Araújo, E\. Nogueira, A\. R\. Neto, T\. Batista, N\. Cacho, E\. Cavalcante, and F\. Lopes\(2026\)Enhancing situational awareness in public safety with frame\-accumulated face recognition and distance\-based evaluation\.InIntelligent Systems,R\. de Freitas and D\. Furtado \(Eds\.\),Lecture Notes in Computer Science, Vol\.16182,pp\. 245–259\.External Links:[Document](https://dx.doi.org/10.1007/978-3-032-15993-9%5F17)Cited by:[§4](https://arxiv.org/html/2607.20490#S4.p2.1),[§6](https://arxiv.org/html/2607.20490#S6.p2.1)\.
- \[8\]S\. Loss, K\. Costa, L\. Gurgel, R\. Sales, V\. Brito, T\. Batista, E\. Cavalcante, F\. Lopes, A\. R\. Neto, and N\. Cacho\(2025\)A framework for live situational awareness in stream\-based 5G applications\.In2025 IEEE Latin Conference on IoT \(LCIoT\),pp\. 202–205\.External Links:[Document](https://dx.doi.org/10.1109/lciot64881.2025.11118567)Cited by:[§4](https://arxiv.org/html/2607.20490#S4.p2.1),[§6](https://arxiv.org/html/2607.20490#S6.p2.1)\.
- \[9\]S\. Loss, K\. Costa, A\. Hedigliranes, P\. Varela, J\. P\. Limão, T\. Batista, A\. R\. Neto, D\. Sabino, N\. Cacho, F\. Lopes, and E\. Cavalcante\(2025\)Um sistema móvel inteligente com computação na borda para atendimento de ocorrências de segurança pública\.InAnais do LII Seminário Integrado de Software e Hardware \(SEMISH 2025\),Brazil,pp\. 251–262\.Note:in PortugueseExternal Links:[Document](https://dx.doi.org/10.5753/semish.2025.8405)Cited by:[§6](https://arxiv.org/html/2607.20490#S6.p1.1)\.
- \[10\]S\. Opricovic and G\. Tzeng\(2004\)Compromise solution by mcdm methods: a comparative analysis of vikor and topsis\.European Journal of Operational Research156\(2\),pp\. 445–455\.External Links:[Document](https://dx.doi.org/10.1016/S0377-2217%2803%2900020-1)Cited by:[§3\.1](https://arxiv.org/html/2607.20490#S3.SS1.p2.1),[§4\.4\.1](https://arxiv.org/html/2607.20490#S4.SS4.SSS1.p3.1)\.
- \[11\]J\. Papathanasiou and N\. Ploskas\(2018\)Multiple criteria decision aid: methods, examples and python implementations\.Springer,Cham, Switzerland\.External Links:[Document](https://dx.doi.org/10.1007/978-3-319-91648-4)Cited by:[§3\.1](https://arxiv.org/html/2607.20490#S3.SS1.p2.1)\.
- \[12\]A\. F\. Rocha Neto\(2021\)Edge\-distributed stream processing for video analytics in smart city applications\.Ph\.D\. Thesis,Federal University of Rio Grande do Norte,Natal, Brazil\.External Links:[Link](https://repositorio.ufrn.br/handle/123456789/32743)Cited by:[§1](https://arxiv.org/html/2607.20490#S1.p3.1)\.
- \[13\]R\. Rosmaninho, D\. Raposo, P\. Rito, and S\. Sargento\(2025\-05\)Edge\-cloud continuum orchestration of critical services: a smart\-city approach\.IEEE Transactions on Services Computing18\(3\),pp\. 1381–1396\.External Links:[Document](https://dx.doi.org/10.1109/TSC.2025.3568251)Cited by:[§3\.2](https://arxiv.org/html/2607.20490#S3.SS2.p1.1)\.
- \[14\]P\. Ruiu, A\. Lagorio, C\. Rubattu, M\. Anedda, M\. Sanna, and M\. Fadda\(2025\-12\)Edge\-to\-cloud continuum orchestrator based on heterogeneous nodes for urban traffic monitoring\.Future Internet17\(12\)\.External Links:[Document](https://dx.doi.org/10.3390/fi17120574)Cited by:[§1](https://arxiv.org/html/2607.20490#S1.p3.1)\.
- \[15\]R\. Singh and S\. S\. Gill\(2023\)Edge AI: a survey\.Internet of Things and Cyber\-Physical Systems3,pp\. 71–92\.External Links:[Document](https://dx.doi.org/10.1016/j.iotcps.2023.02.004)Cited by:[§1](https://arxiv.org/html/2607.20490#S1.p1.1),[§1](https://arxiv.org/html/2607.20490#S1.p3.1)\.
- \[16\]F\. Sonnara, H\. Chihaoui, and F\. Filali\(2025\)Efficient real\-time license plate recognition using deep learning on edge devices\.Journal of Real\-Time Image Processing22\(4\),pp\. 159\.External Links:[Document](https://dx.doi.org/10.1007/s11554-025-01738-3)Cited by:[§1](https://arxiv.org/html/2607.20490#S1.p1.1)\.
- \[17\]E\. Zeydan, J\. Mangues\-Bafalluy, J\. Baranda, R\. Martínez, and L\. Vettori\(2022\)A multi\-criteria decision making approach for scaling and placement of virtual network functions\.Journal of Network and Systems Management30\(2\),pp\. 32\.External Links:[Document](https://dx.doi.org/10.1007/s10922-022-09645-9)Cited by:[§1](https://arxiv.org/html/2607.20490#S1.p3.1),[§3\.1](https://arxiv.org/html/2607.20490#S3.SS1.p2.1)\.