💻 computer science

Pricing-Driven Resource Allocation in the Computing Continuum

This paper proposes a novel pricing-driven framework for resource allocation in the computing continuum, which leverages pricing structures to represent configuration spaces and utilizes the PRIME engine to compute cost-optimal deployments while satisfying diverse constraints, supported by a new dataset of 9,600 scenarios for benchmarking.

Original authors: Alejandro García-Fernández, Boris Sedlak, José Antonio Parejo, Pantelis Frangoudis, Antonio Ruiz-Cortés, Schahram Dustdar

Published 2026-04-15

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Alejandro García-Fernández, Boris Sedlak, José Antonio Parejo, Pantelis Frangoudis, Antonio Ruiz-Cortés, Schahram Dustdar

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Picture: Building a Digital House in a Global Neighborhood

Imagine you want to build a digital "house" (an application) that needs to run super fast and cheap. But you don't have your own land. Instead, you have to rent rooms from different landlords all over the world.

Some landlords are in the city center (Cloud), some are in the suburbs (Fog), and some are right next door (Edge). Each landlord has different rules:

Landlord A has a huge kitchen but no internet.
Landlord B has super-fast internet but a tiny kitchen.
Landlord C is cheap, but you can't rent from them if you also rent from Landlord A (they are rivals).

Your job is to pick the perfect mix of rooms to build your house so that:

It has enough space for your furniture (resources like memory and CPU).
It's close enough to your neighbors (low latency).
It doesn't break the bank (cost).
You don't accidentally rent from rival landlords who hate each other.

This is the Computing Continuum Resource Allocation Problem. It's a massive puzzle with millions of possible combinations.

The Old Way: Drawing Your Own Map

Usually, when computer scientists try to solve this, they invent a new, complicated language just for that specific problem. It's like every time you want to rent a house, you have to draw a new map from scratch and write a new rulebook. It works for that one house, but it's hard to compare it to other houses or reuse the rules later.

The New Idea: Using a "Menu" (Pricing)

The authors of this paper had a "Eureka!" moment. They looked at how Software as a Service (SaaS) companies (like Zoom or Netflix) sell their products.

These companies use Pricings. A pricing isn't just a list of numbers; it's a structured Menu.

The Base Plan: "You get the basic video call."
Add-ons: "Want 100GB of storage? That's an add-on." "Want to record meetings? That's another add-on."

The menu implicitly tells you everything you can buy. If you try to buy a "Recording" add-on without a "Pro Plan," the menu says "No, that's not allowed."

The Big Insight: The authors realized that renting computer servers is exactly like ordering from a menu.

The "Plan" is the type of server.
The "Add-ons" are the specific resources (RAM, CPU, Location).
The "Rules" (like "No recording on the free plan") are the same as "No renting from Landlord A if you rent from Landlord B."

How They Solved It: The "Smart Waiter"

Instead of building a new map, they decided to translate the whole problem into a Pricing Menu.

Translation: They took the messy list of available servers and turned it into a structured "Menu" (which they call an iPricing).
The Order: They took the user's needs (e.g., "I need 8GB of RAM and low latency") and turned that into a specific order request.
The Waiter (PRIME): They used a special tool called PRIME (a pricing analysis engine). Think of PRIME as a super-smart waiter who looks at the Menu and the Order.
- The waiter instantly knows which combinations are valid.
- He calculates the total cost.
- He finds the cheapest possible combination that still satisfies the order, while respecting all the "rival landlord" rules.

What They Tested

To prove this works, they didn't just talk about it; they built a massive simulation lab.

The Setup: They created 9,600 different scenarios. Imagine 9,600 different people trying to build digital houses in Melbourne, Australia, with different needs (some need video surveillance, some need Virtual Reality, some need robot control).
The Result:
- It Worked: The "Menu" approach could describe every single scenario perfectly.
- It Was Fast: Even with huge, complex problems, the "Smart Waiter" found the best solution in just a few seconds.
- It Was Smart: If a request was impossible (e.g., "I need 1,000 servers but my budget is $5"), the waiter correctly said, "I can't do that," instead of giving a bad answer.

Why This Matters

This is a game-changer because it unifies two different worlds:

The Business World: How companies sell software (Menus/Pricing).
The Engineering World: How computers are built and placed (Resource Allocation).

By treating computer infrastructure like a Menu, we can use existing, powerful tools to solve complex engineering problems. It's like realizing that the same logic used to order a pizza can also be used to design a global network of supercomputers.

In short: They stopped trying to invent new languages for every computer problem and started using a "Menu" system that everyone already understands. It's cheaper, faster, and much easier to manage.

1. Problem Statement

The paper addresses the Resource Allocation Problem within the Computing Continuum (spanning edge, fog, and cloud environments). As infrastructures grow in scale and heterogeneity, selecting the optimal subset of geographically distributed nodes to satisfy application workloads becomes a complex, combinatorial decision problem.

Key Challenges Identified:

Heterogeneity & Multi-vendor Complexity: Providers often have specific interoperability constraints (e.g., Node A works with B but not C), making single-vendor solutions less flexible and multi-vendor configurations harder to optimize.
Ad-hoc Modeling: Existing approaches typically formulate this as a constrained optimization problem using custom, domain-specific representations of topology and demand. This hinders generalization, comparison, and the reuse of existing tools.
Representation Gap: The configuration space (the set of all valid node combinations) is often treated as a given input rather than a first-class artifact that can be systematically modeled and explored.

2. Methodology

The authors propose a novel paradigm shift: interpreting Pricings (traditionally used in Software as a Service to define subscription plans and add-ons) as a general-purpose representation of configuration spaces for infrastructure.

Core Concept: iPricing

The approach leverages iPricings (machine-oriented pricing artifacts) and the PRIME analysis engine. The workflow maps infrastructure problems to the pricing domain:

Mapping Infrastructure to Pricing:
- Infrastructure Nodes $\rightarrow$ Add-ons (optional components).
- Node Types/Capabilities $\rightarrow$ Features.
- Resource Limits (e.g., bandwidth caps) $\rightarrow$ Usage Limits.
- Interoperability/Exclusion Rules $\rightarrow$ Add-on Exclusions (business rules).
- Costs $\rightarrow$ Price Expressions (symbolic formulas based on resource usage).
The Workflow:
- Step 1: Topology Mapping: The infrastructure topology ( $O$ ) is projected into an iPricing. Instead of fixed prices, nodes are assigned symbolic price expressions (e.g., RAM_usage * price_per_GB) because the exact resource consumption depends on the specific demand.
- Step 2: Demand & Request Encoding:
  - Demand ( $D$ ): An aggregate vector of required resources (RAM, CPU, Storage, etc.) is used to bound the usage limits of the add-ons.
  - Request ( $R$ ): Constraints such as maximum budget, maximum number of nodes, geographic distance limits, and allowed providers are encoded as filters.
  - The symbolic price expressions are instantiated with concrete values based on the demand vector.
- Step 3: Optimization & Back-Projection: The PRIME engine (using CSP solvers like Gecode or Choco) treats the problem as a Constraint Satisfaction Optimization Problem (CSOP). It searches the configuration space to find a set of nodes (add-ons) that satisfies all constraints while minimizing total cost. The solution is then mapped back to the infrastructure domain.

3. Key Contributions

The paper makes four primary contributions:

Pricing-Based Formulation: A formal definition of the resource allocation problem where the configuration space is represented via iPricings, enabling the use of existing pricing analysis tools for infrastructure optimization.
Optimization Workflow: A complete pipeline utilizing PRIME to explore the pricing configuration space and compute cost-optimal deployments that satisfy functional (capacity) and non-functional (latency, budget, location) constraints.
Synthetic Generation Processes: Methods to generate realistic synthetic infrastructure topologies (based on the EUA dataset) and workload demands, allowing for reproducible scenario construction.
Benchmark Dataset: A public dataset comprising 9,600 pre-computed resource allocation scenarios covering various topology sizes, demand intensities, and application types to support future benchmarking.

4. Experimental Results

The evaluation was conducted using 9,600 test cases across four application scenarios (CCTV, VR, Robotic Arm, LiDAR) and three scales (Small, Medium, Large).

RQ1 (Modeling Expressiveness): The pricing-based formulation successfully modeled all 9,600 instances, including complex multi-provider interoperability constraints, without requiring ad-hoc adaptations.
RQ2 (Optimization Capabilities): The approach consistently identified cost-optimal and feasible configurations for all solvable instances. It also correctly identified infeasible scenarios (where constraints could not be met) rather than returning suboptimal solutions.
RQ3 (Scalability):
- Demand Scaling: Execution time remained stable as the number of clients (demand) increased. This is because higher demand only tightens constraints (usage limits) without expanding the decision space.
- Topology Scaling: Execution time increased with the number of candidate nodes (decision variables), as expected. However, the growth was manageable; scenarios with up to 200 candidate nodes were solved in under 3 seconds.
- Resource Impact: Scenarios requiring scarce resources (e.g., GPUs for VR) showed steeper performance increases than those relying on abundant resources (e.g., storage).

5. Significance and Implications

Unification of Abstractions: The work bridges the gap between Service Composition (typically a software-layer problem) and Resource Allocation (typically an infrastructure-layer problem). It demonstrates that both share a structural foundation: selecting bindings within a constrained decision space.
Reusability of Tools: By modeling infrastructure as a pricing, the research enables the reuse of mature, off-the-shelf analysis engines (like PRIME) and solvers originally designed for SaaS configuration, avoiding the need to build custom optimization solvers for every new infrastructure topology.
General-Purpose Variability Model: It proposes that "pricings" should not be viewed solely as commercial artifacts but as a general-purpose modeling abstraction capable of structuring decision spaces across the entire computing continuum.
Future Directions: The authors suggest extending this to runtime monitoring for adaptive re-allocation, validating with real production workloads, and applying the abstraction to other domains like federated learning or energy-aware scheduling.

In conclusion, the paper successfully validates that pricing structures are a powerful, expressive, and computationally efficient mechanism for solving complex, multi-vendor resource allocation problems in the computing continuum.