Enabling SLO-Aware 5G Multi-Access Edge Computing with SMEC

TL;DR

This work tackles end-to-end SLO violations in 5G MEC caused by RAN uplink contention and edge compute contention, exacerbated by SLO-unaware schedulers. It introduces SMEC, a decoupled framework with independent RAN and edge resource managers that use lightweight signals from 5G control channels and application lifecycles to perform deadline-aware scheduling without coordination. SMEC demonstrates substantial improvements over baselines, achieving 90–96% SLO satisfaction and up to 122× tail-latency reduction on a private MEC testbed while preserving best-effort throughput. The solution is practical, standards-aligned, and open-sourced, offering a viable path to reliable latency-critical MEC deployments.

Abstract

Multi-access edge computing (MEC) promises to enable latency-critical applications by bringing computational power closer to mobile devices, but our measurements on commercial MEC deployments reveal frequent SLO violations due to high tail latencies. We identify resource contention at the RAN and the edge server as the root cause, compounded by SLO-unaware schedulers. Existing SLO-aware approaches require RAN--edge coordination, making them impractical for deployment and prone to poor performance due to coordination delays, limited heterogeneous application support, and ignoring edge resource contention. This paper introduces SMEC, a practical, SLO-aware resource management framework that facilitates deadline-aware scheduling through fully decoupled operations at the RAN and edge servers. Our key insight is that standard 5G protocols and application behaviors naturally provide information exploitable for SLO-aware management without extensive infrastructure or application changes. Evaluation on our 5G MEC testbed shows that SMEC achieves 90-96% SLO satisfaction versus under 6% for existing approaches, while reducing tail latency by up to 122$\times$. We have open-sourced SMEC at https://github.com/smec-project.

Figures (28)

• Figure 1: Probing-based network latency estimation. Red arrows indicate probing protocol packets while blue arrows indicate application requests and responses.
• Figure 2: Network latency (ms) under dynamic workload.
• Figure 3: End-to-end latency for the augmented reality application without edge resource contention across MEC deployments in three cities. The dotted red line indicates the SLO.
• Figure 4: End-to-end latency for smart stadium under different levels of compute resource contention in City-2. The dotted red line indicates the SLO.
• Figure 5: End-to-end latency for smart stadium under different levels of compute resource contention in City-3. The dotted red line indicates the SLO.