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

TL;DR

Serverless5GC introduces a serverless architecture for private 5G core networks, enabling resource-efficient, scale-to-zero deployment of network functions with comparable latency to traditional systems.

Contribution

It maps 3GPP control-plane procedures to serverless functions, decomposing 12 network functions into 31 procedures, and demonstrates cost and latency benefits in private 5G deployments.

Findings

Achieves median registration latency of 406-522ms, comparable to baseline.

Maintains 100% success rate across 3,000 registrations.

Cheaper resource usage when operating below 65% duty cycle or with multiple tenants.

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.