From Megabits to CPU Ticks: Why Your Edge Network Needs a "Computation-First" Strategy

TL;DR

Modern mobile networks are no longer just "pipes" for data; they are distributed compute platforms. However, current network traces only tell us how much data is moving, not how hard the servers have to work to produce it. This paper introduces a methodology to bridge this gap, revealing that low-traffic apps like gaming actually consume 90% of edge CPU resources. By enriching traces with "CPU ticks," the authors provide a blueprint for significantly more efficient MEC (Multi-access Edge Computing) network planning.

The "Data-Compute" Paradox

In the traditional cloud era, we measured network demand in Megabits per second (Mbps). If a user watched a 4K video, the network was "busy." However, in the age of Multi-access Edge Computing (MEC), where servers sit at base stations to transcode video or host world-states for AR gaming, Mbps is a deceptive metric.

The Problem: A gigabit of video streaming is "easy" for a CPU—it's mostly disk I/O. Conversely, a few megabits of a gaming update might involve complex physics calculations and state synchronization. If you design a MEC network based only on data volume, you will over-provision for video and under-provision for gaming, leading to wasted money and laggy experiences.

Methodology: Mapping Traffic to Ticks

To solve this, the authors moved beyond theoretical modeling and conducted empirical experiments using a Docker-based testbed. They analyzed three pillars of modern mobile traffic:

1. Video: Using FFserver/VLC.
2. Gaming: Using Minecraft.
3. Maps: Using OpenMapTiles.

By polling /proc/<PID>/stat in Linux, they measured the actual CPU ticks (10ms units) required per Megabit of traffic.

The Core Discovery: Disproportionality

The results revealed a startling linear relationship where the "slopes" of consumption differ by orders of magnitude:

• $a{u}_{video}$: 0.25 ticks/Mbyte
• $a{u}_{gaming}$: 161.38 ticks/Mbyte
• $a{u}_{maps}$: 67.44 ticks/Mbyte

Figure 1: Notice how the Y-axis for gaming (b) is vastly higher than video (a) despite lower traffic volume.

Transforming the Dataset

The authors took a massive WeFi dataset (millions of records from LA, San Francisco, and Atlanta) and "enriched" it. They categorized apps like Netflix as "video-like" and World of Warcraft as "gaming-like," then applied their CPU-tick coefficients.

The visualization below shows the impact: while gaming is a minority of the traffic, it is the absolute monarch of CPU consumption.

Figure 2: The mismatch between Megabits (Left) and CPU Ticks (Right) is the "Smoking Gun" for why current MEC design is flawed.

MEC Design: Greedy Consolidation

With this enriched "computation-aware" view, the authors proposed a Greedy MEC Design Algorithm.

1. Start Local: Place a server at every base station.
2. Consolidate: Iteratively move servers "up" the network (to rings, then aggregation pods, then the core) to increase efficiency (load sharing) while monitoring the latency penalty.
3. App-Aware Constraints: Gaming is hard-capped at 10ms latency, while video/maps are allowed 50ms.

Performance Gains

By using "ticks" instead of "megabytes" to guide the consolidation score, the researchers achieved a superior Pareto frontier between latency and efficiency.

Figure 3: Enriched traces (dotted lines) consistently outperform original traces (solid lines) by making smarter consolidation decisions.

The Bottom Line

The transition to 5G and 6G isn't just about faster radios; it's about distributed computing. This research proves that domain knowledge—the understanding of what an app actually does inside a CPU—is just as important as network topology for infrastructure planning.

Key Takeaway: If you are an operator planning edge capacity, stop looking at your bit-rate charts. Start looking at your CPU schedules. The "Gaming King" is coming for your resources, and Megabits won't tell you how to prepare.