1 Introduction↩︎

The service-based architecture of the 3GPP 5G Core (5GC) consists of interconnected Network Functions (NFs). Existing open-source implementations, including Open5GS [1] and free5GC [2], typically deploy these NFs as persistent, long-running processes [3]. Because they draw on CPU and memory resources even when inactive, this deployment model introduces substantial inefficiencies. Such resource waste is especially noticeable in private 5G networks, enterprise environments, and emerging markets, where network traffic tends to be intermittent and idle periods are prevalent.

Serverless computing, or Function-as-a-Service (FaaS), offers an alternative: code executes only in response to events, scaling to zero when idle. This model fits the event-driven nature of 3GPP signaling procedures, where operations such as registration, authentication, and session establishment follow well-defined request-response patterns. Recent work on procedure-based decomposition [4] has shown that reorganizing NFs around control plane procedures reduces inter-NF traffic and simplifies orchestration. However, it retains an always-on deployment model, leaving the idle-cost inefficiency unaddressed.

To bridge this gap, this paper proposes Serverless5GC¹, which maps procedure-based decomposition onto a serverless execution model. In this architecture, each 3GPP procedure becomes an independent FaaS invocation that scales to zero when idle. The well-defined request-response semantics of 3GPP signaling align directly with the FaaS execution model, and the resulting cold-start latency remains manageable within 3GPP Non-Access Stratum (NAS) timer budgets. The contributions are:

• A demonstration that procedure-based 5G core decomposition maps to a serverless execution model, with 31 functions across 12 NFs (including Release 17 NFs) that achieve latency parity with always-on baselines and scale to zero when idle.

• An SCTP/NGAP proxy that bridges the standard N2 interface to the serverless HTTP backend, compatible with unmodified RAN (Radio Access Network) equipment and simulators.

• A comparative evaluation against Open5GS and free5GC under five traffic scenarios, quantifying end-to-end latency, cold-start behavior, and resource consumption.

• A resource-time cost model that derives the break-even conditions under which serverless 5G core deployment is cheaper than always-on alternatives across four deployment scenarios (self-hosted, cluster shutdown, multi-tenant, managed FaaS).

2 Background and Related Work↩︎

2.1 5G Core Service-Based Architecture↩︎

The 3GPP 5G System (5GS) architecture [5] defines NFs communicating via HTTP/2 service-based interfaces (SBI). Core NFs include the Access and Mobility Management Function (AMF), Session Management Function (SMF), Unified Data Management (UDM), Unified Data Repository (UDR), Authentication Server Function (AUSF), Network Repository Function (NRF), Policy Control Function (PCF), and Network Slice Selection Function (NSSF). The implementation also incorporates Release 17-compliant versions of the Network Data Analytics Function (NWDAF, TS 29.520), Charging Function (CHF, TS 32.291), Network Slice Admission Control Function (NSACF, TS 29.536), and Binding Support Function (BSF, TS 29.521). Control plane procedures follow standardized flows in TS 23.502 [6]. Open-source implementations include Open5GS [1] (11 NFs, C) and free5GC [2] (14 NFs, Go), both deploying NFs as persistent containerized processes. Benchmarking studies [7], [8] have established baseline performance expectations for these implementations.

2.2 Serverless Computing for Network Functions↩︎

Prior work on serverless networking has focused on the platform level rather than 5G core decomposition. Serverless Network Functions (SNF) [9] proposed an NFaaS platform with flowlet-granularity work assignment for network function chains; QFaaS [10] reduced function chain latency by 40% using QUIC on OpenFaaS (open-source FaaS platform); and DirectFaaS [11] separated control/data flows in serverless chains, cutting execution time by 30.9%. These platform-level optimizations are complementary to our application-level decomposition.

For 5G core networks specifically, Watanabe et al. [12] introduced Proc5GC, a per-UE reactive stateless model using procedure-based decomposition on Linux VMs. Akashi et al. [13] extended this into Cloud5GC, deploying a Registration-only implementation on AWS (Lambda, DynamoDB, SQS). However, Cloud5GC is tightly coupled to proprietary AWS services, unsuitable for on-premises deployments, and delegates SCTP termination to a separate on-premises gateway rather than providing native N2 support.

2.3 Procedure-Based Decomposition↩︎

Goshi et al.introduced procedure-based NF decomposition in PP5GS [4], achieving up to 34% fewer computing resources versus stateful and up to 55% versus stateless baselines, with at least 40% signaling traffic reduction. Subsequent work proposed piggyback state management by appending UE context to inter-NF HTTP messages [14], reducing procedure completion time by up to 44% (Registration) and 70% (Deregistration).

The present work addresses a different problem: cost efficiency under variable load. PP5GS optimizes performance while retaining always-on deployments; Serverless5GC optimizes cost by mapping procedure-based decomposition onto a serverless model where functions scale to zero. This distinction is critical for private networks and edge deployments where traffic is sporadic.

In terms of scope, Cloud5GC covers only the Registration procedure on proprietary infrastructure, delegates SCTP to an on-premises gateway, and provides no baseline comparisons. Serverless5GC provides: (1) a vendor-independent implementation with 31 functions across 12 NFs on open-source infrastructure (OpenFaaS/K3s); (2) an SCTP/NGAP proxy for standard N2 connectivity; (3) Release 17 NF coverage including NSACF; and (4) a comparative evaluation against Open5GS and free5GC. Table 1 summarizes these distinctions.

3 System Architecture↩︎

3.1 Procedure-as-a-Function Design↩︎

Building on the procedure-based decomposition principle established by PP5GS [4], the Serverless5GC architecture maps each 3GPP procedure (as defined in TS 23.502 [6]) to an individual serverless function. Where PP5GS consolidates the procedure-specific logic of multiple NFs into a single always-on Per-Procedure NF (PPNF) to reduce inter-NF signaling traffic and procedure completion time, the present approach takes the opposite direction: each procedure becomes an independent FaaS invocation that is instantiated on demand and scales to zero when idle. Table 2 lists the complete mapping of functions to NFs and procedures. Each function is implemented in Go using the OpenFaaS go-http template, exposing a single Handle() entry point that receives an HTTP request and returns a response.

The Release 17-compliant NFs (NWDAF, CHF, NSACF, BSF) are feature-gated via environment variables, so the system can be evaluated with and without R17 overhead. These NFs are well suited to serverless deployment because their invocation patterns are event-driven and bursty (analytics collection, charging lifecycle, stateless admission checks, CRUD bindings).

Inter-function communication follows the 3GPP SBI pattern via the OpenFaaS gateway using HTTP. During registration, the AMF calls AUSF for authentication, which in turn retrieves authentication vectors from UDM; with R17 enabled, the AMF additionally calls NSACF for slice admission control, and the SMF calls PCF, BSF, CHF, and NSACF during PDU session establishment. The gateway routes calls to available replicas, creating new instances as needed.

3.2 Decomposition Methodology↩︎

The decomposition maps each distinct service operation in the 3GPP SBI specifications (e.g., Namf_Communication, Nsmf_PDUSession) to a standalone serverless function whenever the operation corresponds to a complete request-response transaction. The granularity is guided by three principles: (1) isolation: one procedure type per function; (2) statelessness: UE and session state externalized to Redis/etcd; and (3) minimal fan-out: orchestrator functions call downstream functions sequentially.

3.3 State Management↩︎

Serverless functions are inherently stateless, but 5G core procedures require persistent state [15]: User Equipment (UE) context, Protocol Data Unit (PDU) session data, and authentication vectors must survive across function invocations. The system employs a dual-store architecture fulfilling the role of the 3GPP Unstructured Data Storage Function (UDSF, TS 29.598):

• Redis (transient UDSF): Stores UE context (registration state, security context), PDU session data, authentication vectors, charging sessions, slice admission counters, PCF bindings, and analytics subscriptions. Keys follow the pattern ue:{supi}, pdu-sessions/{session-id}, auth-vectors/{supi}, charging-sessions/{id}, nsacf-counters/{sst}-{sd}, and bsf-bindings/{id}.

• etcd (NRF UDSF): Serves as the NRF service registry, storing NF instance profiles and supporting service discovery through key-prefix queries. Using etcd rather than a dedicated NRF database decouples discovery from NF lifecycle and provides strong consistency guarantees.

All functions access state through a common KVStore interface that abstracts the underlying store and allows mock injection for testing. This design is functionally equivalent to a UDSF [16], [17], where unstructured data associated with UE and NF instances is stored externally so that NF instances remain stateless.

Concurrency. Data races are mitigated through Redis’s single-threaded execution, isolated key schemas, and WATCH/MULTI/EXEC transactions. In practice, the SCTP proxy serializes the NAS state machine per UE, preventing concurrent writes to the same key.

3.4 SCTP/NGAP Proxy↩︎

The N2 interface between the next-generation Node B (gNB) and the AMF uses Stream Control Transmission Protocol (SCTP) transport with NG Application Protocol (NGAP, TS 38.413 [18]) encoding. Since serverless functions are invoked via HTTP, a protocol translation layer is required.

The SCTP proxy (Fig. 1) accepts SCTP connections from gNBs, decodes NGAP and NAS [19] messages, maintains per-UE state machines for signaling flow tracking, and converts HTTP/JSON responses from serverless functions back into security-protected NGAP/NAS messages.

The proxy routes calls to the OpenFaaS gateway via a CoreBackend interface using Go’s http.Client with persistent keep-alive connections. This eliminates per-invocation TCP (Transmission Control Protocol) handshake overhead and accounts for the observed latency parity with direct-call architectures.

Transport limitations. Terminating SCTP at the proxy sacrifices two SCTP properties: (1) multi-homing path redundancy, which must be compensated by redundant proxy replicas behind an SCTP-aware load balancer; and (2) head-of-line (HoL) free streaming, mitigated by Go’s keep-alive TCP connection pooling and the sub-millisecond intra-cluster RTT. The CoreBackend interface accommodates future transport upgrades (e.g., HTTP/3).

3.5 Deployment Infrastructure↩︎

The system deploys on a single-node K3s (lightweight Kubernetes) cluster with OpenFaaS (function lifecycle and scaling), Redis (256 MB, LRU eviction), etcd (NRF registry), and the SCTP proxy on NGAP port 38412. Each function is packaged as a multi-stage Docker container producing a static Go binary on Alpine Linux, served via the OpenFaaS go-http template SDK.

As shown in Table 2, the system decomposes 12 NFs into 31 serverless functions, comparable in coverage to Open5GS (11 NFs) and free5GC (14 NFs), with each procedure scaling independently.

4 Evaluation↩︎

4.1 Experimental Setup↩︎

The evaluation deploys three system configurations on cloud virtual machines in the same region:

1. Serverless5GC: The Procedure-as-a-Function architecture on a 4-vCPU/8 GB VM running K3s v1.31, OpenFaaS CE, Redis 7, etcd 3.5.17, and the SCTP/NGAP proxy (Go 1.25). Internal per-function execution times are measured via the OpenFaaS gateway metrics.

2. Open5GS [1]: v2.7.2 (C-based), deployed via Docker Compose on a 4-vCPU/8 GB VM.

3. free5GC [2]: v4.2.0 (Go-based), deployed via Docker Compose on a 4-vCPU/8 GB VM.

A separate 4-vCPU/8 GB load generator VM hosts UERANSIM (5G UE/RAN simulator) v3.2.6 [20] and the traffic generation scripts. A dedicated monitoring VM of identical specification runs Prometheus v2.51 (5-second scrape interval) and node exporters, collecting metrics from all target VMs and the load generator. All VMs run Ubuntu 24.04.

All VMs reside within the same virtual data center, connected via a private LAN (Local Area Network) with sub-millisecond inter-VM latency. Tests are executed sequentially (one target at a time) to prevent cross-system interference.

4.2 Traffic Scenarios↩︎

The evaluation covers five traffic scenarios, each representing a different operational regime as shown in Table 3:

Each scenario is repeated three times per target configuration. CPU utilization, memory consumption, function invocation counts, and response latencies are collected via Prometheus. The evaluation exclusively targets private and enterprise 5G networks (campus deployments, factory floors, remote-area cells) where 100–1,000 UEs represent realistic operational loads. Carrier-grade networks serving tens of thousands UEs are outside the scope of this work.

UE arrival model: UERANSIM processes UE state machines sequentially within a single process, limiting the effective registration throughput per instance to 50 UEs/s [20]. To reach the target UE counts (500–1,000), multiple UERANSIM instances are launched in batches of 100 UEs, staggered by 30 seconds. In the low scenario (100 UEs), a single batch completes within 2 s. In medium, high, and burst scenarios, only the first batch (10–20% of UEs) arrives within the first 2 s; the remaining 80–90% arrive 30–270 s later (medium/burst: up to 120 s; high: up to 270 s). This batching structure affects the interpretation of cold-start measurements (Section 4.4).

Table 4 shows end-to-end registration latency. Serverless5GC achieves median latency of 406–522 ms across scenarios, matching the C-based Open5GS baseline (403–606 ms), while free5GC is 6–8\(\times\) slower at the median.

4.3 PDU Session Latency↩︎

Table 5 shows PDU session establishment latency. The serverless architecture achieves median PDU latency of 163–195 ms, comparable to Open5GS (109–146 ms) and 8–14\(\times\) faster than free5GC (1,532–2,680 ms). The increased p99 values (average 16,678 ms across all three systems) observed under medium, high, and burst loads reflect UERANSIM’s sequential UE state machine processing: the last UEs in each batch experience queuing delays at the load generator, not at the core network. This artifact affects all systems equally and does not indicate a system-specific bottleneck.

Success rates. The serverless architecture achieves 100% registration and PDU session success across all scenarios (6,300/6,300 total). Open5GS drops 4 registrations under high load (99.94% overall) and free5GC drops 1 (99.98%). Results are reproducible across runs: cross-run \(\sigma\) of the median registration latency ranges from 3 to 47 ms for Serverless5GC and 13 to 97 ms for Open5GS, while free5GC exhibits higher run-to-run variability (54 to 564 ms).

Table 6 shows how long each function takes to execute (HTTP handler only, excluding SCTP and network overhead). Each UE registration triggers 8 function invocations in total; summed, they complete in 16.49 ms, corresponding to just 3.7% of the 444 ms median end-to-end latency. The remaining 96.3% is the 3GPP protocol itself: NAS round trips over the radio and N2 interfaces (Registration Request, Authentication Request/Response, Security Mode Command/Complete, and Registration Accept/Complete), plus UE-side cryptographic processing of the authentication challenge.

Table 7 shows that per-function execution times are virtually independent of load level: even at 10\(\times\) the invocation rate (low to high), the maximum deviation for any function is under 5%. This confirms that the stateless, externalized-state design eliminates contention between concurrent invocations. Each UE registration triggers exactly 8 function invocations across all scenarios, validating the deterministic call graph of the Procedure-as-a-Function model.

The latency measurements above reflect warm-start conditions. Cold-start behavior is evaluated explicitly in the following subsection.

4.4 Cold-Start Storm Behavior↩︎

A key concern for serverless 5G core deployments is the cold-start storm scenario: after a prolonged idle period, the autoscaler has scaled all functions to zero replicas, and a burst of UEs simultaneously attempts registration, forcing the container runtime to provision all function pods concurrently while signaling requests are already in flight. To quantify this worst case, a dedicated cold-start experiment is conducted using the same traffic scenarios as the warm-start evaluation (Table 3).

Methodology. For each run, all 31 function pods are force-deleted (excluding infrastructure: Redis, etcd) and UERANSIM UE registrations are started simultaneously, ensuring the first UEs hit the system while function containers are still initializing. The Kubernetes deployment controller immediately recreates the deleted pods, but each function must complete container startup and Go runtime initialization before serving requests. Each scenario is run 3 times and averages are reported.

Due to the batched UE arrival model (Section 4), the first 100-UE batch arrives within 2 s, overlapping with the 4 s pod recreation window. In the low scenario, every UE is affected. In medium, high, and burst scenarios, only the first batch (10–20%) overlaps with cold-start; the remaining 80–90% hit warm replicas.

Table 8 presents the results. The critical metric is p99: it captures the tail where UEs arrive while pods are still initializing, and it must remain below the 15 s NAS T3510 retransmission timer. In the low scenario (100 UEs, single batch), all UEs arrive within the 4 s pod recreation window; p99 reaches 5,938 ms, consuming 39.6% of the T3510 budget. In multi-batch scenarios (500–1,000 UEs), only the first 100-UE batch overlaps with cold-start; \(\Delta\) p99 ranges from \(+\)​690 ms (medium) to \(+\)​1,402 ms (burst), peaking at 10,873 ms in the high scenario (72.5% of budget).

Across all 12 cold-start runs, the system achieves 100% registration success without T3510 timer expirations. The system converges to warm-start performance within 4–5 seconds, possible by the small memory footprint of each function (approximately 15 MB) and local container image caching.

4.5 Resource Consumption↩︎

Table 9 compares the resource footprint of the three systems. Data represents the average of 3 runs. CPU and memory are measured at the node level via Prometheus node_cpu_seconds_total and node_memory_MemAvailable_bytes, filtered by VM label to isolate each target system. CPU values are reported as busy CPU seconds per minute (sum of non-idle CPU deltas over the measurement window, divided by window length: 10 min for steady-state, 5 min for burst). Memory is reported as used memory (total minus available) in MB.

The serverless architecture has a higher baseline CPU (7.6 s min\(^{-1}\) idle vs. for Open5GS, 3.4 for free5GC) due to the K3s control plane, OpenFaaS, Redis, and etcd. However, CPU growth from idle to high load is only \(+\)​74% (7.6\(\to\)​13.2), compared to \(+\)​245% for Open5GS (2.0\(\to\)​6.9) and \(+\)​650% for free5GC (3.4\(\to\)​25.5). Memory consumption is stable for the serverless architecture (2,105–2,138 MB, \(+\)​1.6% from idle to high), as function replicas carry no per-UE state. The baselines show more variation (Open5GS \(+\)​17%, free5GC \(+\)​15%). Peak utilization reaches 10.6% of the 4-vCPU capacity (free5GC, high scenario).

The higher serverless baseline is attributable to the orchestration platform (K3s + OpenFaaS account for 1,130 MB, or 53.7% of the 2,105 MB total), not the function workload (\(31 \times 15\) MB \(= 465\) MB, comparable to a single Open5GS NF process).

4.6 Cost Model↩︎

The evaluation data (Tables 9 and 6) permit a formal cost comparison between the serverless and always-on deployment models using the platform-independent resource-time metric (GB-seconds). The key measured quantities are:

• Serverless idle memory \(M_s = 2{,}105\) MB (Table 9), decomposed as platform base \(M_p = 1{,}640\) MB (K3s: 820 MB, OpenFaaS: 310 MB, Redis: 85 MB, etcd: 65 MB, operating system: 360 MB) plus function replicas \(M_f = 465\) MB (\(31 \times 15\) MB).

• Always-on baseline \(M_a = 1{,}368\) MB: Open5GS idle memory. Open5GS is chosen as the always-on reference because it achieves latency parity with Serverless5GC (Table 4) and has a lower idle footprint than free5GC (1,368 MB vs.,378 MB), making it the more conservative and fairer cost comparison.

• Minimum infrastructure \(M_i = 150\) MB: state stores only (Redis: 85 MB, etcd: 65 MB), the persistent minimum when functions run on a managed FaaS platform.

• Per-registration resource-time \(g = 0.002\) GB-s: the total FaaS compute consumed per UE registration, computed as \(128\,\text{MB} \times 16.49\,\text{ms} = 0.002\) GB-s, where 128 MB is the minimum AWS Lambda memory allocation (actual function footprint is approximately 15 MB, but Lambda bills at a 128 MB minimum) and 16.49 ms is the summed execution time of all 8 invocations (Table 6).

The total resource-time over period \(T\) (in seconds) depends on the deployment scenario. Let \(\lambda\) denote the average registration rate (reg/s) and \(d \in [0,1]\) the duty cycle, defined as the fraction of \(T\) during which traffic is present.

4.6.1 Self-Hosted, Platform Always On↩︎

Both the serverless platform and always-on baseline run on dedicated VMs. Functions scale to zero during idle, but the platform (K3s, OpenFaaS, Redis, etcd) remains active:

\[\begin{align} G_s &= (M_p + d \cdot M_f) \cdot T + \lambda \cdot d \cdot T \cdot g \tag{1} \\ G_a &= M_a \cdot T \tag{2} \end{align}\]

Setting \(G_s = G_a\) and noting that \(\lambda \cdot d \cdot g\) is negligible (at 20 reg/s: \(\lambda g = 0.04\) GB \(= 41\) MB, about 2.5% of \(M_p = 1{,}640\) MB):

\[d^* \approx \frac{M_a - M_p}{M_f} = \frac{1{,}368 - 1{,}640}{465} = -0.59 \label{eq:d-selfhosted}\tag{3}\]

The negative value indicates that \(M_p > M_a\): the platform overhead alone (1,640 MB) exceeds the always-on baseline (1,368 MB). On a dedicated single-tenant VM, the serverless deployment is never cheaper than the always-on baseline at any duty cycle. This result is a direct consequence of the K3s orchestration overhead (820 MB) and the OpenFaaS gateway (310 MB), which together account for 1,130 MB of fixed cost absent from the Docker Compose baselines.

4.6.2 Self-Hosted, Cluster Shutdown↩︎

If the entire K3s cluster is shut down during idle periods (e.g., via scheduling for predictable traffic patterns), the serverless cost becomes:

\[G_s = M_s \cdot d \cdot T + \lambda \cdot d \cdot T \cdot g\]

Setting \(G_s = G_a\): \[d^* = \frac{M_a}{M_s + \lambda \cdot g} \approx \frac{M_a}{M_s} = \frac{1{,}368}{2{,}105} = 0.65 \label{eq:d-shutdown}\tag{4}\]

The serverless deployment is cheaper when the cluster runs less than 65% of the time. For a private network operating 8 h/day (\(d = 0.33\)), the resource-time cost is 51% of the always-on baseline. For 12 h/day (\(d = 0.50\)), it is 77%.

4.6.3 Multi-Tenant Self-Hosted↩︎

If \(K\) tenants share the K3s/OpenFaaS platform, the per-tenant platform cost is \(M_p/K\), while each tenant adds its own function replicas:

\[G_s^{(K)} = \left(\frac{M_p}{K} + d \cdot M_f\right) \cdot T\]

Setting \(G_s^{(K)} = G_a\) with \(d = 1\) (worst case, all tenants always active): \[\begin{align} K^* &= \left\lceil \frac{M_p}{M_a - M_f} \right\rceil = \left\lceil \frac{1{,}640}{1{,}368 - 465} \right\rceil \nonumber \\ &= \left\lceil \frac{1{,}640}{903} \right\rceil = 2 \label{eq:k-multitenant} \end{align}\tag{5}\]

With two or more tenants on a shared platform, the per-tenant serverless cost falls below the always-on baseline even at full duty cycle.

4.6.4 Managed FaaS↩︎

On a managed platform (e.g., AWS Lambda, Google Cloud Run), the orchestration overhead (\(M_p\)) is absorbed by the provider. Only the state stores (\(M_i = 150\) MB as managed services) and per-invocation costs remain:

\[G_s = M_i \cdot T + \lambda \cdot T \cdot g\]

Setting \(G_s = G_a\): \[\lambda^* = \frac{M_a - M_i}{g} = \frac{1.189\,\text{GB}}{0.002\,\text{GB-s}} = 595\,\text{reg/s} \label{eq:lambda-managed}\tag{6}\]

Below 595 reg/s, the managed serverless deployment consumes less resource-time than the always-on baseline.

4.6.5 Summary↩︎

Table 10 summarizes the four deployment scenarios.

This model identifies the orchestration platform overhead as the dominant cost factor for self-hosted deployments: the 1,130 MB K3s/OpenFaaS footprint must be amortized across idle periods (cluster shutdown) or tenants (shared platform) to offset the always-on baseline. On managed FaaS platforms, this overhead is absent, and the per-invocation cost is low enough that serverless remains cheaper up to 595 reg/s, well above typical private network signaling rates.

4.7 Discussion↩︎

The evaluation results highlight several points for serverless 5G core design:

Orchestration dominance. amf-initial-registration accounts for 46.5% of total function compute time but only 12.5% of invocations, orchestrating 7 downstream calls to 5 functions. This decomposition enables fine-grained scaling: orchestration functions can be allocated more resources without over-provisioning simple lookups where UDM and AUSF functions each complete in under 1 ms.

Burst resilience without pre-provisioning. Under burst traffic (50 reg/s, 2.5\(\times\) the sustained high rate), the serverless architecture absorbs the spike with comparable end-to-end latency (435 ms burst vs. ms medium, \(+\)​7%) and with internal function execution time increasing by only \(+\)​1.7%. No pre-scaling, capacity reservation, or manual intervention was required, which suits event-driven deployments (stadiums, festivals, disaster recovery).

Protocol translation overhead. The total internal function execution time (16.5 ms for 8 invocations) represents 3.7% of the end-to-end registration latency (444 ms). The remainder is dominated by the NAS procedure inherent to 3GPP registration (NAS round trips over the radio interface) plus UE-side cryptographic processing. Serverless invocation overhead is negligible relative to protocol-inherent latency.

Complementarity with PP5GS. PP5GS [4] consolidates NFs per procedure to reduce inter-NF HTTP traffic by 17.5–40%. The Serverless5GC model inherits this benefit, since each function already encapsulates a complete procedure, while adding scale-to-zero capability. A combined approach could apply PP5GS’s piggyback state management [14] within serverless functions to further reduce external state lookups, eliminating inter-NF traffic and idle resource costs.

Toward a hybrid architecture. A production serverless 5G core would benefit from a hybrid deployment model: latency-critical NFs (AMF, SMF) with persistent deployment, combined with FaaS-backed R17 NFs (NWDAF, CHF, NSACF) that are invoked sporadically and tolerate moderate cold-start latency. The Procedure-as-a-Function decomposition enables this hybrid placement directly, since each procedure is an independent deployment unit. Service affinity analysis [21] could further inform placement decisions by co-locating frequently communicating functions.

4.8 Limitations and Future Work↩︎

(1) Scale and platform: the evaluation targets private networks (50 reg/s, 1,000 UEs); carrier-grade deployments would require multi-node K3s clusters, OpenFaaS gateway load balancing, Redis clustering, and redundant SCTP proxy replicas behind an SCTP-aware load balancer. (2) Cold-start and migration: the 8.5\(\times\) p99 tail penalty under low-UE cold-start conditions motivates predictive pre-scaling (e.g., time-of-day traffic models) and container checkpoint/restore [22] for warm replica migration without cold-start penalties. (3) Scope: this work covers control plane only; extending to the UPF using eBPF or DPDK, and validating with physical gNBs and commercial UEs under real radio conditions, remain open.

5 Conclusion↩︎

This paper has presented Serverless5GC, an implementation of 31 serverless functions across 12 3GPP network functions on open-source infrastructure, with an SCTP/NGAP proxy for standard N2 interface compatibility.

The evaluation against Open5GS and free5GC leads to two findings. First, the Procedure-as-a-Function decomposition does not degrade signaling performance: median registration latency (406–522 ms) matches the C-based Open5GS baseline (403–606 ms), internal function execution (16.5 ms for 8 invocations) accounts for 3.7% of end-to-end latency, and 100% registration success is maintained across all scenarios including cold-start storms. Second, the cost advantage of serverless 5G core deployment is conditional, not absolute. The resource-time cost model shows that on a single self-hosted VM, the platform infrastructure overhead (1,640 MB, including K3s, OpenFaaS, Redis, etcd, and OS) exceeds the always-on baseline (1,368 MB), making serverless more expensive at any traffic level. The cost advantage materializes under three conditions: (1) the cluster is shut down during idle periods (break-even at 65% duty cycle, i.e., cheaper for any deployment active less than 15.6 h/day); (2) two or more tenants share the platform; or (3) functions run on a managed FaaS provider, where serverless is cheaper up to 595 reg/s.

This result has a practical implication for private 5G deployments. The serverless model is not a universal replacement for always-on architectures, but it is cost-effective in the case of private networks: intermittent traffic, low duty cycles, and limited subscribers. A campus network active 8 h/day (\(d = 0.33\)) consumes 51% of the resource-time of an always-on equivalent, with no loss in latency or reliability.

References↩︎

---

1. The Serverless5GC implementation is publicly available at https://github.com/haidinhtuan/serverless5gc↩︎