Repurpose-10K: Sustainable 10K-Node Cloudlet

• Repurpose-10K is a framework that repurposes 10K smartphones as autonomous compute nodes to build sustainable cloudlets for microservice workloads.
• It integrates lightweight Kubernetes, Docker, and carbon-aware charging with managed networking to ensure scalability and energy efficiency.
• Empirical evaluations demonstrate competitive microbenchmarks and up to 18× lower carbon emissions per operation compared to traditional cloud servers.

Repurpose-10K refers to the architectural, operational, and carbon-accounting framework for constructing and deploying a 10,000-node computational cloudlet using repurposed smartphones as described by Switzer et al. The approach leverages the untapped potential of decommissioned mobile devices to assemble scalable, energy-efficient, and carbon-minimizing compute clusters, targeting both sustainable ICT infrastructure and practical cloud microservice workloads (Switzer et al., 2021).

1. Architectural Overview and Node Composition

A Repurpose-10K cloudlet consists of approximately 10,000 homogeneous smartphones, such as Pixel 3A (2019) or Nexus 4 (2012), sourced second-hand. Each node is individually powered, cooled, networked, and monitored as a discrete compute element. Devices are connected to managed smart-plugs for carbon-aware charging and organized in trays or racks with forced-air cooling, sized by aggregate thermal dissipation. Internal smartphone batteries function as distributed uninterruptible power supplies, supporting 30 minutes to 2 hours of autonomy per device. Large-scale networking is enabled by equipping each phone with a USB–Gigabit Ethernet adapter, connecting to a leaf/spine switching fabric, ensuring scalability beyond the wireless limitations encountered at smaller cluster sizes (Switzer et al., 2021).

2. Software Stack and Cluster Orchestration

The node image runs a stripped-down, headless Linux OS (e.g., Ubuntu Touch kernel and rootfs), eliminating interactive layers. Each phone executes standardized container runtimes such as Docker—utilizing BTRFS or overlayFS for layered filesystem management. For orchestration, small clusters employ Docker Swarm, while large-scale deployments (hundreds to tens of thousands of nodes) use lightweight Kubernetes distributions (e.g., k3s, KubeEdge). The architectural layering involves:

• Control plane: 3–5 designated master nodes running etcd, schedulers, and the Kubernetes API server.
• Node agents: Reside on each phone to log health telemetry (CPU, temperature, battery level), facilitate failure detection, and invoke automated rescheduling upon node dropout.
• CNI plugins (Flannel, Calico): Provide overlay IP fabric.
• Monitoring: A central Prometheus/Grafana stack or edge aggregator accumulates node metrics.
• Logging: ELK/EFK pipeline for per-container logs.
• Workload management: Microservices are packaged as Docker images. Resource requests/limits are calibrated to device capacities.

An optional extension supports carbon-aware placement, where the scheduler preferentially utilizes nodes with high battery state-of-charge or low temperature, throttling workloads on thermally-constrained devices (Switzer et al., 2021).

3. Computational Carbon Intensity and Carbon Accounting

To quantify sustainability, Repurpose-10K operational philosophy adopts Computational Carbon Intensity (CCI)—defined as the amortized $\mathrm{CO}_2$-equivalent emissions per useful operation:

$$\mathrm{CCI} = \frac{\mathbb{C}_M + \mathbb{C}_C + \mathbb{C}_N}{\displaystyle\sum_{t=0}^{T}\mathrm{ops}(t)}$$

where:

• $\mathbb{C}_M$: Embodied carbon of manufacture (set to zero for “repurposed” phones).
• $\mathbb{C}_C$: Cumulative carbon from compute power, via

$$\mathbb{C}_C = \mathrm{CI}_{\mathrm{grid}} \times \sum_{t=0}^T (0.10\,P_{100\%} + 0.35\,P_{50\%} + 0.30\,P_{10\%} + 0.25\,P_{\mathrm{idle}})\,\Delta t$$

where $P_{x\%}$ is power draw at $x\%$ CPU, and $\mathrm{CI}_\mathrm{grid}$ is grid carbon intensity.

• $\mathbb{C}_N$: Networking carbon,

$$\mathbb{C}_N = \mathrm{CI}_{\mathrm{grid}} \times \sum_{t=0}^T f_{\mathrm{net}} EI_{\mathrm{net}} \, \Delta t$$

($$\mathrm{CCI} = \frac{\mathbb{C}_M + \mathbb{C}_C + \mathbb{C}_N}{\displaystyle\sum_{t=0}^{T}\mathrm{ops}(t)}$$0 in bytes/sec, $$\mathrm{CCI} = \frac{\mathbb{C}_M + \mathbb{C}_C + \mathbb{C}_N}{\displaystyle\sum_{t=0}^{T}\mathrm{ops}(t)}$$1 in J/byte).

By zeroing $$\mathrm{CCI} = \frac{\mathbb{C}_M + \mathbb{C}_C + \mathbb{C}_N}{\displaystyle\sum_{t=0}^{T}\mathrm{ops}(t)}$$2 for repurposed nodes, CCI reflects the environmental benefit of extended device lifetimes and provides a direct means for lifetime extension versus new server deployment (Switzer et al., 2021).

4. Performance Characteristics and Comparative Analysis

Empirical evaluation of Repurpose-10K nodes demonstrates capability for modern cloud microservices:

Table: Single-Node Microbenchmarks

Device	SGEMM (Gflop/s)	Dijkstra (MTE/s)	MemCopy (GB/s)	Avg Power (W)
PowerEdge	2070	80	19.5	308.7
Pixel 3A	39	4.44	5.45	1.54
Nexus 4	8.12	2.21	3.22	1.78

Cluster-scale results (DeathStarBench workloads) on a 10-node Pixel 3A group yield:

• SocialNetwork-Write: ≈3,500 QPS at 50 ms median, outperforming AWS c5.12xlarge.
• SocialNetwork-Read: ≈3,000 QPS at latencies between c5.4xlarge and c5.9xlarge.
• HotelReservation (mixed): ≈4,000 QPS at 30 ms median, comparable to c5.9xlarge.

Power consumption for a 10-node cluster is ≈17 W, in stark contrast with ≈140 W for a single c5.9xlarge AWS node, highlighting significant carbon and operational efficiency. After three years on the California grid mix, a Pixel 3A cluster delivers up to 18× lower $$\mathrm{CCI} = \frac{\mathbb{C}_M + \mathbb{C}_C + \mathbb{C}_N}{\displaystyle\sum_{t=0}^{T}\mathrm{ops}(t)}$$3 per operation on SocialNetwork-Write workloads compared to c5.9xlarge (Switzer et al., 2021).

5. Scalability Constraints and Operational Management

Key challenges include:

• Networking: Wi-Fi is viable for < 30-node clusters but degrades due to co-channel interference at larger scale. 10,000-node deployments require wired connectivity (USB–GigE or onboard Ethernet) terminating at standard 1 GbE leaf/spine switches, ensuring ample uplink aggregation.
• Thermal and Power Management: Each phone’s sustained design power ≈2–3 W; thermal throttling occurs at 40–50 °C, with device shutdowns at 75–80 °C. Enclosures with 256 phones at full load dissipate ≈666 W, adequately cooled using two 500 W server fans to keep ambient below 40 °C.
• Battery Replacement: Operational models anticipate ≈2,500 charge cycles per phone, translating to ~2.3 years for Pixel 3A under typical use. Embodied carbon for battery replacement is ≈2 kg $$\mathrm{CCI} = \frac{\mathbb{C}_M + \mathbb{C}_C + \mathbb{C}_N}{\displaystyle\sum_{t=0}^{T}\mathrm{ops}(t)}$$4-eq; swap labor ~10 min/device.
• Fault Tolerance: Clusters accommodate unplanned node dropout via health checks and automatic container re-scheduling. Stateless microservice design and replication of stateful components are employed for resiliency.
• Smart Charging: Median 7% $$\mathrm{CCI} = \frac{\mathbb{C}_M + \mathbb{C}_C + \mathbb{C}_N}{\displaystyle\sum_{t=0}^{T}\mathrm{ops}(t)}$$5 savings on Pixel 3A accrue by scheduling charging using real-time grid carbon intensity APIs (e.g., CAISO) and delaying charging when grid intensity is high (Switzer et al., 2021).

6. Best Practices and Design Guidelines

To optimize for maintainability, energy use, and carbon minimization, the following practices are recommended:

• Uniform hardware selection (one or two phone models) to reduce system heterogeneity.
• Deploy Linux-based, non-interactive OS images with container runtimes; enable BTRFS or overlayFS.
• Enforce wired Ethernet for large clusters; restrict wireless-only deployments to <100-device edge pods.
• Operationalize per-node monitoring of thermal, CPU, and battery health; proactively throttle/migrate workloads to avoid thermal shutdown.
• Exploit batteries as distributed UPS, enacting carbon-aware charging policies via managed smart-plug control.
• Anticipate periodic battery replacements, incorporating embodied carbon and labor into ongoing CCI calculus.
• Use CCI as a quantitative selection metric: continue operation when $$\mathrm{CCI} = \frac{\mathbb{C}_M + \mathbb{C}_C + \mathbb{C}_N}{\displaystyle\sum_{t=0}^{T}\mathrm{ops}(t)}$$6; retire or recycle when the advantage no longer holds, such as after extensive battery replacement lifecycles or shifting workload requirements.
• Right-size cooling: provision 500 W of fan capacity per 500 W aggregate phone TDP.
• For bursty, parallelizable microservices (e.g., e-commerce, social feed, or small database workloads), Repurpose-10K delivers aggregate throughput on par with megawatt-scale datacenters at a fraction of their embodied carbon (Switzer et al., 2021).

7. Applications and Implications

Repurpose-10K facilitates substantial carbon reductions in distributed compute infrastructures by exploiting the latent performance reserve of decommissioned smartphones. For microservice-based cloud applications demanding high parallelism and moderate per-node capabilities—such as those in DeathStarBench—the platform can match or exceed commercial server performance clusters in throughput, latency, and energy use per operation. The decoupling of embodied carbon via $$\mathrm{CCI} = \frac{\mathbb{C}_M + \mathbb{C}_C + \mathbb{C}_N}{\displaystyle\sum_{t=0}^{T}\mathrm{ops}(t)}$$7 for reused devices redefines device service lifetime in carbon terms and enables a new tactical frontier for sustainable computing initiatives. A plausible implication is that, under current grid carbon intensities and device characteristics, service providers can deploy high-throughput, carbon-minimized compute pools at scale using neglected consumer hardware, subject to careful management of networking, cooling, and device lifecycle logistics (Switzer et al., 2021).