Serverless5GC: Private 5G Core Deployment via a Procedure-as-a-Function Architecture

Abstract

Open-source 5G core implementations deploy network functions as always-on processes that consume resources even when idle. This inefficiency is most acute in private and edge deployments with sporadic traffic. Serverless5GC is an architecture that maps each 3GPP control-plane procedure to an independent Function-as-a-Service invocation, allowing scale-to-zero operation without modifying the standard N2 interface. The system decomposes 12~network functions (Release~15-17) into 31~serverless procedures, fronted by an SCTP/NGAP proxy that bridges unmodified RAN equipment to an HTTP-based serverless backend. Evaluation against Open5GS and free5GC across five traffic scenarios (idle to 20~registrations/s burst) shows that Serverless5GC achieves median registration latency of 406-522ms, on par with the C-based Open5GS baseline (403-606ms), while maintaining 100% success across 3,000 registrations. A resource-time cost model shows that the serverless deployment (0.002GB-seconds per registration) is cheaper than the always-on baseline when the cluster operates below a 0.65 duty cycle, when two or more tenants share the platform, or on managed FaaS platforms up to 609reg/s. Under worst-case cold-start conditions where all 31 function pods are evicted simultaneously, the system sustains zero failures and converges to warm-start latency within 4-5 seconds.

Figures (4)

• Figure 1: Serverless 5GC architecture. The SCTP/NGAP proxy bridges the N2 interface to HTTP-based function invocations. R15 core functions (21) handle standard procedures; R17 functions (10) add analytics, charging, admission control, and PCF binding. All functions share Redis for state and etcd for NRF service discovery.
• Figure 2: Median (p50) end-to-end UE registration latency across traffic scenarios (3-run average, whiskers show $\pm\sigma$). Serverless5GC achieves latency parity with the C-based Open5GS despite additional proxy and gateway hops.
• Figure 3: Median (p50) registration latency under cold-start storm vs. warm-start conditions (3-run averages, whiskers show $\pm\sigma$). The low scenario (100 UEs) shows an 11$\times$ penalty as all UEs hit initializing containers; in larger populations, the warm majority pulls the median below the warm baseline, with cold-start impact visible only at p95/p99.
• Figure 4: CPU resource consumption rate (seconds per minute of measurement window) across key traffic scenarios. Burst uses a 5-minute window; all other scenarios use a 10-minute window.