Unified Resource-Pool Architecture

• Unified Resource-Pool Architecture is an abstraction that consolidates diverse physical and virtual resources into a single, unified pool, simplifying management and load balancing.
• It employs a dynamic control mechanism to shift loads among constituent elements, ensuring fairness, resilience, and optimized resource utilization.
• This architecture is applied across domains such as wireless networks, optical systems, and cloud services to enhance efficiency and scalability.

Unified resource-pool architecture denotes an arrangement in which a heterogeneous collection of physical and/or virtual resources is abstracted so that it behaves as a single pooled resource, while a control mechanism shifts load among constituent elements to optimize utilization, fairness, resilience, flexibility, or hardware complexity (Qadir et al., 2016). Qadir et al. identify resource pooling as a key unifying principle for wireless technologies, and later work instantiates the same pattern in switch data planes, hierarchical resource and job management software, battery-swapping networks, direct-detection optical receivers, shared-expert Mixture-of-Experts, proactive Spark cluster pools, and segment-level prefix-cache systems (Du et al., 2018, Milroy et al., 2021, Sloothaak et al., 2019, Liu et al., 18 Jun 2026, Huang et al., 7 May 2026, Ravikumar et al., 2024, Wu et al., 24 Aug 2025).

1. Definition and conceptual scope

In the formulation used for wireless systems, resource pooling involves: “(i) abstracting a collection of networked resources to behave like a single unified resource pool and (ii) developing mechanisms for shifting load between the various parts of the unified resource pool” (Qadir et al., 2016). The stated motivation is that pooling can provide resilience, high utilization, and flexibility at an acceptable cost. In that setting, the pooled objects may be time-slots, frequency blocks, links, processors, storage nodes, or energy budgets, and the architecture maintains the fiction of one super-resource while continuously redistributing load.

Subsequent work broadens the resource type while preserving the same structural idea. In the Resource Pooling Switch Architecture, packets and flows access a global shared resource pool of virtualized network-function instances connected to a switching fabric (Du et al., 2018). In Fluxion, the pooled entity is a dynamic directed graph of physical and virtual resources that can be expanded by subgraph addition and contracted by subgraph removal (Milroy et al., 2021). In battery swapping, a network of stations behaves asymptotically “as good as if there would have been a single station with an aggregated number of resources,” which the paper terms complete resource pooling (Sloothaak et al., 2019). In direct-detection optics, wavelength, polarization, and intensity are jointly organized as a composite optical symbol space rather than being recovered by separate branches (Liu et al., 18 Jun 2026). In UniPool, expert capacity is treated “as a global architectural budget” rather than as layer-private banks (Huang et al., 7 May 2026). In Intelligent Pooling, Spark clusters are proactively provisioned into a pool sized from demand forecasts (Ravikumar et al., 2024). In TokenLake, prefix caches are lifted into a unified segment-level pool that the scheduler queries declaratively rather than managing imperatively (Wu et al., 24 Aug 2025).

A plausible implication is that “resource” is domain-dependent, but “pooling” retains two invariants: an abstraction boundary that hides heterogeneity, and a control regime that decides when, where, and how to reassign demand.

2. Formal abstractions and analytical models

A canonical formalization starts with atomic resources $R=\{r_1,r_2,\dots,r_n\}$, a pooling operator $\Pi:2^R\to\hat{\mathcal R}$, and a load vector $L=(L_1,L_2,\dots,L_n)$ with $L_i\ge 0$ (Qadir et al., 2016). The architecture has two goals: maintain an abstraction layer in which the system behaves as if there is one super-resource $\hat r$ with capacity $\hat C=\mathrm{cap}(\Pi(R))$, and continuously solve a load-shifting problem that reassigns $L$ to optimize an overall utility function $U$. The generic optimization problem is

$$\begin{aligned} \text{maximize}\quad & U(L) \ \text{s.t.}\quad & \sum_{i=1}^n L_i \le \mathrm{cap}(\Pi(R)) \ & L_i \le c_i \quad \forall i=1\dots n \ & Q(L)\ge Q_{\min}, \end{aligned}$$

with common criteria including max-min fairness, proportional fairness through $\sum_i w_i\log(L_i)$, and weighted throughput through $\Pi:2^R\to\hat{\mathcal R}$0 (Qadir et al., 2016).

Fluxion introduces a different but compatible abstraction: a directed resource graph $\Pi:2^R\to\hat{\mathcal R}$1 in which each vertex is a resource unit and each vertex carries a capacity vector $\Pi:2^R\to\hat{\mathcal R}$2 (Milroy et al., 2021). A job request is itself a directed graph $\Pi:2^R\to\hat{\mathcal R}$3 with demand vectors $\Pi:2^R\to\hat{\mathcal R}$4. Allocation is defined by a matching function $\Pi:2^R\to\hat{\mathcal R}$5 that seeks a subgraph $\Pi:2^R\to\hat{\mathcal R}$6 and an injective map preserving capacity constraints and graph structure. Dynamism is explicit: $\Pi:2^R\to\hat{\mathcal R}$7 and $\Pi:2^R\to\hat{\mathcal R}$8 modify the pool incrementally rather than rebuilding it.

Sloothaak et al. provide a queueing-theoretic account of complete resource pooling in a network of battery-swapping stations (Sloothaak et al., 2019). Under the QED provisioning rule,

$\Pi:2^R\to\hat{\mathcal R}$9

with $L=(L_1,L_2,\dots,L_n)$0, the diffusion-scaled queue lengths

$L=(L_1,L_2,\dots,L_n)$1

collapse onto one another after an $L=(L_1,L_2,\dots,L_n)$2 startup. The paper’s state-space-collapse result shows that, in diffusion scale, the station-to-station imbalances vanish and the network behaves like one pooled station.

In high-dimensional direct-detection optics, the pooled object is not capacity in the scheduling sense but symbol space (Liu et al., 18 Jun 2026). The transmitted symbol is

$L=(L_1,L_2,\dots,L_n)$3

with total alphabet size $L=(L_1,L_2,\dots,L_n)$4. The receiver applies a passive linear map $L=(L_1,L_2,\dots,L_n)$5 to the complex optical state $L=(L_1,L_2,\dots,L_n)$6, giving $L=(L_1,L_2,\dots,L_n)$7, and direct photodetection yields

$L=(L_1,L_2,\dots,L_n)$8

Recoverable information is expressed as

$L=(L_1,L_2,\dots,L_n)$9

The architecture therefore pools wavelength, polarization, and intensity into one jointly projected space rather than partitioning them into separate recovery pipelines.

3. Architectural patterns and control mechanisms

A recurring architecture contains three logical layers: an abstraction layer, a control plane, and a data plane (Qadir et al., 2016). The abstraction layer publishes the pooled resource as a single virtual entity and hides heterogeneity of frequencies, protocols, or substrate topologies. The control plane performs resource discovery, admission control, and load balancing, maintains state such as $L_i\ge 0$0, and computes reallocation vectors $L_i\ge 0$1. The data plane forwards traffic or tasks across selected physical resources and reports measurements such as delay, packet loss, and capacity usage back to the control plane. The same source notes that such control may be logically centralized, as in Cloud-RAN or SDN, or distributed, as in mesh DTN/ICN hybrids.

RPSA makes this template explicit in a switch setting (Du et al., 2018). Its three major components are a Global Resource Pool or Network Function Pool, a VOQ-based switching fabric, and Service Function Chains. The Network Function Pool is a farm of commodity servers hosting multiple Virtualized Network Function Instances, with total capacity

$L_i\ge 0$2

Each ingress port maintains VOQs with queue lengths $L_i\ge 0$3, and flows are classified either to direct-forward SFCs or to service SFCs steered through function ports into the pool. To balance heterogeneous queues, RPSA defines an allocation weight

$L_i\ge 0$4

where $L_i\ge 0$5 is last-service time. Its BSC-FIRM scheduler further defines a lexicographically ordered Service Capacity index $L_i\ge 0$6 and redirects each input port’s first-round pointer to the least-served queue. The reported scheduling complexity is

$L_i\ge 0$7

Fluxion organizes schedulers into a fully hierarchical tree and coordinates elasticity through two RPCs: MatchAllocate and MatchGrow (Milroy et al., 2021). MatchGrow performs a bottom-up search for allocatable resources and a top-down grafting of the returned subgraph $L_i\ge 0$8 through $L_i\ge 0$9 and metadata updates. At the top of the hierarchy, an ExternalAPI can acquire cloud resources such as AWS EC2 instances and return them as a new subgraph. Users see a single Fluxion namespace, while nested schedulers only observe their own subgraphs.

In large-scale cloud service, Intelligent Pooling separates prediction, optimization, and actuation into a Predictor, an Allocator, and a Pool Manager (Ravikumar et al., 2024). The Predictor periodically reads the last $\hat r$0 time steps of cluster-request counts, the Allocator solves a small-scale linear or convex program for pool size $\hat r$1 over a one-hour window, and the Pool Manager reconciles desired pool size with the current idle-cluster count. Hyper-parameters such as forecast quantile and history window are adjusted by a proportional feedback rule. The architecture is therefore closed-loop and explicitly cost-aware.

TokenLake adopts a similar separation of concerns for LLM serving, but the pooled object is prefix cache rather than compute clusters (Wu et al., 24 Aug 2025). The scheduler invokes three control-plane calls—get_prefix_tree, get_cache_load, and gen_plans—and four declarative data-plane calls—init_query, query, init_transfer, and put. The cache manager holds a global view of all prefix-cache segments across $\hat r$2 GPUs, while per-GPU compute, query, and transfer engines execute the plan. This design lets the scheduler use existing batching and elasticity techniques without embedding cache-management logic.

4. Representative realizations across domains

The literature presents multiple concrete realizations of unified resource-pool architecture.

System	Pooled resource	Distinctive mechanism
Wireless resource pooling (Qadir et al., 2016)	Networked resources such as channels, links, storage, and energy budgets	Abstraction into one pool plus load shifting across white space networking, community networks, and multihoming
RPSA (Du et al., 2018)	Global shared network-function capacity	VOQ-based switching fabric, SFC steering, BSC-FIRM scheduling
Fluxion and KubeFlux (Milroy et al., 2021)	Dynamic directed graph of physical and virtual resources	MatchAllocate, MatchGrow, AddSubgraph, RemoveSubgraph, ExternalAPI
Battery-swapping network (Sloothaak et al., 2019)	Spare batteries and charging points across stations	Dynamic arrival routing and complete resource pooling via state-space collapse
Direct-detection optical receiver (Liu et al., 18 Jun 2026)	Composite symbol space of wavelength, polarization, and intensity	Optical-domain joint projection in an integrated disordered photonic processor
UniPool (Huang et al., 7 May 2026)	Shared expert capacity across transformer depth	Single global pool of $\hat r$3 experts, per-layer routers, pool-level auxiliary loss, NormRouter
Intelligent Pooling (Ravikumar et al., 2024)	Idle Spark clusters and sessions	ML demand forecasting, LP-based pool sizing, worker/arbitrator pool management
TokenLake (Wu et al., 24 Aug 2025)	Segment-level prefix cache across GPUs	Declarative cache interface, heavy-hitter-aware load balancing, bipartite matching dispatch

In wireless networking, the pooled unit may be channels, paths, or interfaces; in switching, it is function capacity; in converged computing, it is a graph of allocatable units; in battery swapping, it is service capacity distributed over stations; in optics, it is a jointly decoded state space; in MoE, it is expert parameters; in cloud service, it is prewarmed cluster inventory; and in LLM serving, it is prefix-cache memory. This suggests that the architecture is not tied to a particular substrate but to a repeatable relation between abstraction, allocation, and rebalancing.

UniPool is a particularly direct architectural generalization of pooling into model design (Huang et al., 7 May 2026). Conventional MoE assigns each of the $\hat r$4 transformer layers its own private bank of $\hat r$5 experts, whereas UniPool instantiates one shared pool $\hat r$6 and allows each layer $\hat r$7 to route tokens through a sparse top-$\hat r$8 subset. The layer output is

$\hat r$9

and global utilization is stabilized by the pool-level auxiliary loss

$\hat C=\mathrm{cap}(\Pi(R))$0

The paper argues that pool size becomes an explicit depth-scaling hyperparameter.

TokenLake realizes a comparable decoupling for serving systems (Wu et al., 24 Aug 2025). Prefix caches are split into fixed-size segments of length $\hat C=\mathrm{cap}(\Pi(R))$1 tokens and distributed across GPU memory by a combination of heavy-hitter replication and hash assignment. Dispatch uses Power-of-Two-Choices for replicated segments and a minimum-weight perfect matching over batches and GPUs to minimize communicated bytes. The core point is architectural: the scheduler states what cache state it needs, while the pool decides where that state resides.

5. Reported performance and scaling characteristics

The reported gains are domain-specific rather than reducible to one metric.

System	Reported result	Citation
Wireless pooling	TV white-space field trials in rural India report 5–10 Mbps aggregate throughput for 20 users across 10 km mesh; community-mesh capacity utilization improved from 60% to 85% in experiments; multihoming observed 30–50 % throughput improvement and seamless failover	(Qadir et al., 2016)
RPSA	In a $\hat C=\mathrm{cap}(\Pi(R))$2 testbed, BSC-FIRM shows ≈10.5% lower delay than FIRM at $\hat C=\mathrm{cap}(\Pi(R))$3 under uniform traffic, ≈12% lower delay and ≈83% fewer drops under hotspot traffic, and ≈8–9% lower delay with ≈75% fewer drops under bursty traffic	(Du et al., 2018)
Fluxion	MatchAllocate and MatchGrow differ by only ~1.2 µs in match time; MG’s extra AddSubgraph+Update costs ≈0.0056 s; converting the EC2 API response into a $\hat C=\mathrm{cap}(\Pi(R))$4-JGF adds only ≈1.6% overhead; on KubeFlux, a single-pod MA takes ~0.1018 s and an MG for a ReplicaSet grow takes ~0.1003 s	(Milroy et al., 2021)
Battery swapping	Waiting probability converges to $\hat C=\mathrm{cap}(\Pi(R))$5; mean waiting time vanishes as $\hat C=\mathrm{cap}(\Pi(R))$6; charger and battery-pool utilizations tend to $\hat C=\mathrm{cap}(\Pi(R))$7	(Sloothaak et al., 2019)
Optical direct detection	The system resolves 4096 composite symbols, corresponding to 12 bits per symbol slot, with BER $\hat C=\mathrm{cap}(\Pi(R))$8 after 10 km standard-fiber transmission; receiver sensitivity remains at least 98.12% accuracy down to –9 dBm; reach is 97.12% accuracy after 30 km SMF; Table 1 reports 60% PRS savings and 83% HC savings at 12 bits/symbol	(Liu et al., 18 Jun 2026)
UniPool	Across five LLaMA-architecture scales trained on 30B tokens from the Pile, UniPool reduces validation loss by up to 0.0386 relative to vanilla MoE; reduced-pool variants using 41.6%–66.7% of the vanilla expert-parameter budget match or outperform layer-wise MoE	(Huang et al., 7 May 2026)
Intelligent Pooling	Evaluated on large-scale production data, the system achieves up to 43% reduction in cluster idle time compared to static pooling when targeting 99% pool hit rate; dynamic pooling hit-rate is ≈95% versus ≈78% for a static mean-sized pool; monthly resource bill is ≈20% lower while meeting the 90 %+ hit-rate target	(Ravikumar et al., 2024)
TokenLake	Throughput improves by up to $\hat C=\mathrm{cap}(\Pi(R))$9 versus Router and $L$0 versus MoonCake variants; hit rate is up to $L$1 higher than Router and $L$2 higher than PD; load-balance coefficient of variation is <15%	(Wu et al., 24 Aug 2025)

The reported evaluations also differ in timescale and bottleneck. Wireless and battery-swapping studies emphasize utilization, latency, waiting, and resilience; switch and LLM-serving systems emphasize scheduling delay, drop rate, throughput, and load balance; optical work emphasizes symbol-space growth, BER, and hardware complexity; MoE work emphasizes validation loss, perplexity, and parameter efficiency; cloud pooling emphasizes hit-rate, idle time, and COGS. A plausible implication is that unified resource-pool architecture is best understood as a systems principle whose success criteria are inherited from the application domain.

6. Trade-offs, limitations, and open problems

The literature emphasizes that pooling is not synonymous with unrestricted aggregation. In wireless systems, centralized control can achieve near-optimal pooling but incurs higher overhead and single-point delays or failures, whereas distributed control is more robust but may converge more slowly and suffer suboptimal load splits (Qadir et al., 2016). The same source states that pooling boosts utilization but risks “tragedy of the commons” if left unregulated, and that fragmentation can simplify isolation and QoS while lowering statistical multiplexing gains. It also identifies unresolved questions on unified abstractions, metadata schemas, scalability to millions of devices, safe real-time orchestration under SDR and NFV, and incentive models for community-shared pools.

The optical literature rejects a common overstatement: the unified resource-pool receiver “does not surpass Shannon capacity of the fiber channel; rather repurposes existing degrees of freedom more efficiently” (Liu et al., 18 Jun 2026). Its current prototype operates at 100 MHz, requires stable calibration of the transfer matrix $L$3, and would need RF-packaged multi-channel photodiode arrays, >20 GHz ADCs, and high-speed polarization modulators for full high-baud operation. The same work highlights active stabilization or retraining, extension to spatial modes, DSP/FEC integration, energy-per-bit profiling, and classifier robustness as open technical issues.

Shared pools also create training-stability constraints. UniPool reports that pooling without altering the auxiliary loss or router led to unstable collapse, and that NormRouter plus the pool-level loss was critical (Huang et al., 7 May 2026). Token-level load balance in a shared expert pool is therefore not automatic; it must be regularized globally rather than per layer.

Cloud and serving systems stress separation of concerns. Intelligent Pooling recommends decoupling pooling-size control from in-cluster auto-scaling and avoiding VM-level pools when network isolation is required (Ravikumar et al., 2024). TokenLake similarly argues that the scheduler should not encode cache management, and instead exposes declarative interfaces so that cache placement, deduplication, and defragmentation can be optimized globally (Wu et al., 24 Aug 2025). This suggests that a mature unified resource-pool architecture is usually accompanied by a disciplined API boundary, explicit admission and balancing logic, and an account of failure, drift, or incentive misalignment rather than by pooling alone.