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

Serv erless5GC: Pri v ate 5G Core Deployment via a Procedure-as-a-Function Architecture Hai Dinh-T uan T echnische Uni versit ¨ at Berlin Berlin, Germany hai.dinhtuan@tu-berlin.de Abstract —Open-source 5G core implementations deploy net- work functions as always-on processes that consume resour ces even when idle. This inefficiency is most acute in private and edge deployments with sporadic traffic. Serverless5GC is an architectur e that maps each 3GPP control-plane procedure to an independent Function-as-a-Service in vocation, allo wing scale- to-zero operation without modifying the standard N2 interface. The system decomposes 12 network functions (Release 15–17) into 31 serverless procedur es, fronted by an SCTP/NGAP proxy that bridges unmodified RAN equipment to an HTTP-based serverless back end. Evaluation against Open5GS and free5GC across five traffic scenarios (idle to 20 registrations/s burst) shows that Serverless5GC achie ves median registration latency of 406– 522 ms, on par with the C-based Open5GS baseline (403–606 ms), while maintaining 100% success across 3,000 registrations. A resour ce-time cost model shows that the serverless deployment (0.002 GB-seconds per registration) is cheaper than the always-on baseline when the cluster operates below a 0.65 duty cycle, when two or mor e tenants share the platf orm, or on managed F aaS platforms up to 609 reg/s. Under worst-case cold-start conditions where all 31 function pods ar e evicted simultaneously , the system sustains zero failures and con verges to warm-start latency within 4–5 seconds. Index T erms —5G core network, serverless computing, Function-as-a-Service, procedur e-based decomposition, scale-to- zero I . I N T R O D U C T I O N The 3GPP 5G Core (5GC) defines a service-based ar- chitecture of interconnected Network Functions (NFs). Cur- rent open-source implementations such as Open5GS [1] and free5GC [2] deploy these NFs as long-running processes [3] that consume CPU and memory even when idle. This inef- ficiency is most acute in pri v ate 5G deployments, enterprise networks, and emerging markets, where traffic is sporadic and idle periods are common. Serverless computing, or Function-as-a-Service (FaaS), of- fers an alternative: code ex ecutes only in response to ev ents, scaling to zero when idle. This model fits the e vent-dri ven nature of 3GPP signaling procedures, where operations such as registration, authentication, and session establishment fol- low well-defined request-response patterns. Recent work on procedure-based decomposition [4] has sho wn that reor ganiz- ing NFs around control plane procedures reduces inter-NF traffic and simplifies orchestration, but retains always-on de- ployment models that leav e idle-cost inef ficiency unaddressed. This paper proposes Serverless5GC 1 , which maps procedure-based decomposition onto a serverless ex ecution model: each 3GPP procedure becomes an independent FaaS in vocation that scales to zero when idle. The well-defined request-response semantics of 3GPP signaling align directly with the FaaS ex ecution model, and the resulting cold-start tradeoff is manageable within 3GPP Non-Access Stratum (N AS) timer budgets. The contributions are: • A demonstration that procedure-based 5G core decom- position maps to a serverless e xecution model, with 31 functions across 12 NFs (including Release 17 NFs) that achiev e 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 equipment and simulators. • A comparativ e ev aluation ag ainst Open5GS and free5GC under five traf fic scenarios, quantifying end-to-end la- tency , cold-start behavior , and resource consumption. • A resource-time cost model that deriv es the break-even conditions under which serverless 5G core deployment is cheaper than always-on alternati ves across four de- ployment scenarios (self-hosted, cluster shutdown, multi- tenant, managed FaaS). I I . B AC K G RO U N D A N D R E L A T E D W O R K A. 5G Cor e Service-Based Ar chitectur e 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 Func- tion (AMF), Session Management Function (SMF), Unified Data Management (UDM), Unified Data Repository (UDR), Authentication Server Function (A USF), Network Repository Function (NRF), Policy Control Function (PCF), and Network Slice Selection Function (NSSF). Release 17 adds the Network Data Analytics Function (NWDAF , TS 29.520), Charging Function (CHF , TS 32.291), Network Slice Admission Control Function (NSA CF , TS 29.536), and Binding Support Function (BSF , TS 29.521). Control plane procedures follow standard- ized flo ws in TS 23.502 [6]. Open-source implementations include Open5GS [1] (11 NFs, C) and free5GC [2] (10 NFs, 1 The Serverless5GC implementation is publicly av ailable at https://github . com/haidinhtuan/serverless5gc T ABLE I: Comparison with Related 5GC Re-architectures System Platform NFs/Fn. N2 Focus PP5GS [4] K8s (on) 6/18 Sim. Latency Cloud5GC [14] A WS Lambda 5/8 No Feasibility SNF [9] Custom –/– No Data-plane Serverless5GC OFaaS/K3s 12/31 Y es Cost eff. Go), both deploying NFs as persistent containerized processes. Benchmarking studies [7], [8] hav e established baseline per- formance expectations for these implementations. B. 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] demonstrated FaaS-based packet processing with flo wlet scheduling; Breitgand [10] explored serverless Netw ork Function V irtualization (NFV) for 5G me- dia on OpenWhisk; QFaaS [11] reduced function chain latency by 40% using QUIC on OpenF aaS; and DirectFaaS [12] separated control/data flows in serverless chains, cutting ex e- cution time by 30.9%. These platform-level optimizations are complementary to our application-lev el decomposition. For 5G core networks specifically , Akashi et al. [13] intro- duced Proc5GC, a per-UE reacti ve stateless model on A WS Lambda. W atanabe et al. [14] extended this into Cloud5GC, deploying 5 NFs with 8 functions on A WS (Lambda, Dy- namoDB, SQS). Howe ver , Cloud5GC is tightly coupled to proprietary A WS services, unsuitable for on-premises deploy- ments, and lacks N2 interface (SCTP/NGAP) support. C. Pr ocedur e-Based Decomposition Goshi et al. introduced procedure-based NF decomposition in PP5GS [4], with 34–55% computing resource and 40% signaling traffic reductions. Subsequent work proposed pig- gyback state management via N AS message tokens [15] and demonstrated 50% faster procedure completion. The present work addresses a different problem: cost ef- ficiency under variable load . PP5GS optimizes performance while retaining always-on deployments; Serverless5GC opti- mizes cost by mapping procedure-based decomposition onto a serverless model where functions scale to zero. This distinction is critical for pri vate networks and edge deployments where traffic is sporadic. In terms of scope, Cloud5GC covers only 5 NFs on pro- prietary infrastructure without N2 support or baseline com- parisons. 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 cov- erage including NSA CF; and (4) a comparativ e ev aluation against Open5GS and free5GC. T able I summarizes these distinctions. T ABLE II: Procedure-as-a-Function Decomposition NF Procedur e Count AMF Registration, Deregistration, Service Request, 6 PDU Session Relay , Handov er , Auth Initiate SMF PDU Create, Update, Release, N4 Setup 4 NRF Register , Discov er , Status Notify 3 CHF † Charging Create, Update, Release 3 BSF † Binding Register , Discov er , Deregister 3 UDM Generate Auth Data, Get Subscriber Data 2 UDR Data Read, Data Write 2 PCF Policy Create, Policy Get 2 NWD AF † Analytics Subscribe, Data Collect 2 NSA CF † Slice A vailability Check, Update Counters 2 A USF Authenticate 1 NSSF Slice Select 1 T otal 31 † Release 17 NF (feature-gated) I I I . S Y S T E M A R C H I T E C T U R E A. Pr ocedur e-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 serv erless function. Where PP5GS merges the NFs in volv ed in a procedure into a single always-on service to reduce inter-NF traffic, the present approach takes the op- posite direction: each procedure becomes an independent FaaS in vocation that is instantiated on demand and scales to zero when idle. T able II 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 recei ves an HTTP request and returns a response. The Release 17 NFs (NWD AF , CHF , NSACF , BSF) are feature-gated via environment variables, so the system can be ev aluated with and without R17 ov erhead. These NFs are well suited to serverless deployment because their in vocation patterns are ev ent-dri ven and b ursty (analytics collection, charging lifecycle, stateless admission checks, CR UD bind- ings). Inter-function communication follows the 3GPP SBI pattern via the OpenFaaS gateway using HTTP . During registration, the AMF calls A USF , which calls UDM; with R17 enabled, the AMF additionally calls NSA CF , and the SMF calls CHF and BSF during PDU session establishment. The gatew ay routes calls to av ailable replicas, creating ne w instances as needed. B. 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 whenev er 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 : all state externalized to Redis/etcd; and (3) minimal fan-out : orchestrator functions call downstream functions sequentially . C. State Management Serverless functions are inherently stateless, but 5G core procedures require persistent state [16]: User Equipment (UE) context, Protocol Data Unit (PDU) session data, and authen- tication vectors must surviv e across function in vocations. 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 metrics. K eys follo w the pattern ue: { supi } , pdu: { session-id } , 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 dis- cov ery through k ey-prefix queries. Using etcd rather than a dedicated NRF database decouples discov ery from NF lifecycle and pro vides strong consistency guarantees. All functions access state through a common KVStore interface that abstracts the underlying store and allo ws mock injection for testing. This design is functionally equiv alent to a UDSF [17] as defined in 3GPP TS 29.598, where unstructured UE conte xt is stored externally so that NF instances remain stateless. Concurr ency . Data races are mitigated through Re- dis’ s single-threaded e xecution, isolated key schemas, and WATCH / MULTI / EXEC transactions. In practice, the SCTP proxy serializes the N AS state machine per UE, prev enting concurrent writes to the same key . D. SCTP/NGAP Pr oxy The N2 interface between the next-generation Node B (gNB) and the AMF uses Stream Control T ransmission Proto- col (SCTP) transport with NG Application Protocol (NGAP) encoding, as specified in TS 38.413 [18]. Since serverless functions are in v oked 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 flo w tracking, and con verts HTTP/JSON responses from serverless functions back into security-protected NGAP/N AS messages. The proxy routes calls to the OpenFaaS gate way via a CoreBackend interface using Go’ s http.Client with persistent keep-aliv e connections. This eliminates per- in vocation TCP handshake ov erhead and accounts for the observed latenc y parity with direct-call architectures. T r ansport limitations. T erminating SCTP at the proxy sacri- fices two SCTP properties: (1) multi-homing path redundanc y , which must be compensated by redundant proxy replicas be- hind an SCTP-aware load balancer; and (2) head-of-line (HoL) fr ee str eaming , mitigated by Go’ s pooled TCP connections ( MaxIdleConnsPerHost=100 ) and the sub-millisecond intra-cluster R TT . The CoreBackend interface accommo- dates future transport upgrades (e.g., HTTP/3). E. Deployment Infrastructur e The system deploys on a single-node K3s cluster with OpenFaaS (function lifecycle and scaling), Redis (256 MB, LR U 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 with the OpenFaaS watchdog. As shown in T able II, the system decomposes 12 NFs into 31 serverless functions, comparable in cov erage to Open5GS (11 NFs) and free5GC (10 NFs), with each procedure scaling independently . I V . E V A L UA T I O N A. Experimental Setup The e valuation deploys three system configurations on cloud virtual machines in the same region: 1) Serverless5GC : The Procedure-as-a-Function architec- ture on a 4-vCPU/8 GB VM running K3s v1.31, Open- FaaS CE, Redis 7, etcd 3.5.17, and the SCTP/NGAP proxy (Go 1.25). Internal per-function e xecution times are measured via the OpenFaaS gate way 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 UER- ANSIM 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 ex- porters, collecting metrics from all tar get VMs and the load generator . All VMs run Ubuntu 24.04. All VMs reside within the same virtual data center, con- nected via a pri vate LAN with sub-millisecond inter-VM latency . T ests are ex ecuted sequentially (one target at a time) to prev ent cross-system interference. B. T r affic Scenarios The ev aluation cov ers five traffic scenarios, each represent- ing a different operational regime: Each scenario is repeated three times per target con- figuration. CPU utilization, memory consumption, function in vocation counts, and response latencies are collected via Prometheus. The ev aluation exclusiv ely targets private and enterprise 5G networks (campus deployments, factory floors, K3s Cluster UERANSIM gNB + UE N2 (TS 38.412) SCTP/NGAP Proxy OpenFaaS Gateway R15 Core (21 functions) AMF (6) SMF (4) NRF , UDM, UDR, AUSF , PCF , NSSF (11) R17 (10 functions) CHF (3) BSF (3) NSACF (2) NWDAF (2) Redis UE/Session State etcd NRF Registry UPF Data Plane SCTP HTTP HTTP HTTP Fig. 1: Serverless 5GC architecture. The SCTP/NGAP proxy bridges the N2 interf ace to HTTP-based function in vocations. 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 discov ery . T ABLE III: T raf fic Scenarios Scenario UEs Rate Duration PDU/UE Description Idle 0 – 10 min – No traf fic (scale-to-zero) Low 100 1/s 10 min 1 Sporadic registrations Medium 500 5/s 10 min 2 Moderate steady state High 1000 20/s 10 min 3 Sustained load Burst 500 50/s 5 min 2 Peak o verload remote-area cells) where 100–1,000 UEs represent realistic operational loads. Carrier-grade macro networks serving tens of thousands of concurrent UEs are outside the scope of this work. UE arrival model: UERANSIM processes UE state ma- chines sequentially within a single process, limiting the effec- tiv e registration throughput per instance to 50 UEs/s [20]. T o reach the tar get 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) arri v es within the first 2 s; the remaining 80–90% arriv e 30–120 s later . This batching structure affects the interpretation of cold-start measurements (Section IV -E). C. Contr ol Plane Latency End-to-end control plane latency for the complete UE registration procedure is measured by parsing UERANSIM logs, computing the time delta between “Sending Initial Reg- istration” and “Initial Registration is successful” for each UE, and av eraging across 3 independent runs per scenario. T able IV presents the consolidated registration latency measurements. The central finding is latency parity with Open5GS : the serverless architecture achieves median la- tencies of 406–522 ms across scenarios, closely matching the C-based Open5GS baseline (403–606 ms), despite the serverless path trav ersing the SCTP/NGAP proxy , the Open- FaaS gatew ay , and 8 individual function in v ocations, while Low Medium High Burst 0 2 , 000 4 , 000 463 406 522 435 406 410 606 403 3 , 234 3 , 257 3 , 592 3 , 008 Registration Latenc y , p50 (ms) Serverless5GC Open5GS free5GC Fig. 2: Median (p50) end-to-end UE registration latency across traffic scenarios (3-run av erage, whiskers show ± σ ). Server - less5GC achie ves latenc y parity with the C-based Open5GS despite additional proxy and gate way hops. Open5GS processes registrations in a single monolithic AMF process. The Procedure-as-a-Function decomposition and pro- tocol translation layer therefore introduce negligible o verhead relativ e to the protocol-inherent latency of 3GPP registration. The Go-based free5GC is consistently slower (3,008– 3,592 ms median), though this gap primarily reflects free5GC’ s implementation specifics (its goroutine-heavy NF processing model and Go runtime overhead) rather than a property of the serverless architecture. Under high load, tail latency (p95) increases substantially for all systems, to 9,147 ms for serverless and 8,666 ms for Open5GS, reflecting queueing delays at 20 reg/s as UERANSIM processes UE state machines sequentially . D. PDU Session Latency T able V shows PDU session establishment latenc y . The serverless architecture achie ves median PDU latency of 163– T ABLE IV: End-to-End Registration Latency Comparison (ms) Serverless5GC Open5GS free5GC Scenario p50 p95 p99 p50 p95 p99 p50 p95 p99 Low 463 755 1,162 406 500 1,453 3,234 4,466 5,196 Medium 406 3,770 5,039 410 3,863 5,170 3,257 5,847 6,875 High 522 9,147 9,915 606 8,666 10,185 3,592 10,878 12,661 Burst 435 3,762 5,083 403 4,122 5,166 3,008 5,775 6,760 V alues are 3-run averages. Cross-run σ : Serverless p50 ± 4–47 ms, Open5GS ± 13–97 ms, free5GC ± 54–564 ms. T ABLE V: PDU Session Establishment Latency (ms, 3-run av erages) Serverless5GC Open5GS free5GC Scenario p50 p95 p99 p50 p95 p99 p50 p95 p99 Low 195 363 425 109 157 212 2,680 3,064 3,161 Medium 169 348 16,628 113 357 16,644 1,919 2,849 16,164 High 186 423 16,707 146 361 16,970 1,532 3,075 17,048 Burst 163 382 16,619 119 339 16,730 1,810 2,817 16,591 V alues are 3-run av erages measured from UERANSIM UE logs. All latencies in milliseconds. 195 ms, comparable to Open5GS (109–146 ms) and 8–17 × faster than free5GC (1,532–2,680 ms). The elev ated p99 v alues (av erage 16,678 ms across all three systems) observed under medium, high, and b urst 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 af fects all systems equally and does not indicate a system-specific bottleneck. Success rates. The serverless architecture achiev es 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%). The differences are mar ginal at this scale, b ut the serverless architecture’ s perfect reliability under all conditions, including burst at 50 reg/s, validates the Procedure-as-a-Function error handling. T able VI details the internal per -function execution times (HTTP handler only , excluding proxy and network overhead). The total chain time of 15.56 ms for 8 in v ocations represents 3.4% of the a verage end-to-end re gistration latency (456.5 ms); the remaining 96.6% is attributable to the three NAS round trips inherent to 3GPP registration, UE-side cryptographic processing, and NGAP/N AS encoding. Per-function ex ecution times are stable across load lev els ( < 5% deviation across a 10 × rate increase), indicating that the stateless design eliminates contention. Each registration triggers exactly 8 function in v ocations across all scenarios. The latency measurements above reflect warm-start condi- tions; cold-start impact on aggregate statistics is negligible since only the first UE per run incurs a cold-start penalty . Cold-start behavior is ev aluated explicitly in the following subsection. E. Cold-Start Storm Behavior A ke y 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 T ABLE VI: Internal Function Execution T ime (High Scenario, 3-run avg.) Function A vg (ms) Inv ocations % of Chain amf-initial-registration 7.68 1,000 – amf-auth-initiate 2.33 2,000 30% udm-generate-auth-data 0.84 2,000 11% smf-pdu-session-create 0.93 1,000 – ausf-authenticate 0.80 1,000 10% udm-get-subscriber-data 0.74 1,000 9% Chain %: fraction of amf-initial-registration time. Times exclude proxy/network overhead. Low Medium High Burst 0 2 , 000 4 , 000 6 , 000 5 , 037 366 377 361 463 406 522 435 Registration Latenc y , p50 (ms) Serverless5GC (cold) Serverless5GC (warm) Fig. 3: Median (p50) registration latenc y under cold-start storm vs. warm-start conditions (3-run av erages, whiskers sho w ± σ ). The lo w scenario (100 UEs) sho ws an 11 × penalty as all UEs hit initializing containers; in larger populations, the warm majority pulls the median below the w arm baseline, with cold- start impact visible only at p95/p99. burst of UEs simultaneously attempts registration, forcing the container runtime to provision all function pods concurrently while signaling requests are already in flight. T o quantify this worst case, a dedicated cold-start experiment is conducted using the same traf fic scenarios as the warm-start ev aluation (T able III). Methodology . For each run, all 31 function pods are force- deleted (excluding infrastructure: Redis, etcd) and UERAN- SIM UE registrations are started simultaneously , ensuring the first UEs hit the system while function containers are still initializing. The Kubernetes deployment controller im- mediately 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 arriv al model (Section IV), the first 100-UE batch arriv es within 2 s, ov erlapping with the 4 s pod recreation windo w . In the low scenario, ev ery UE is affected. In medium, high, and burst scenarios, only the first batch (10– 20%) o verlaps with cold-start; the remaining 80–90% hit warm replicas. T able VII presents the results. In the low scenario (100 UEs, single batch), all UEs arri ve during the 4 s pod recreation T ABLE VII: Cold-Start Storm vs. W arm-Start Registration Latency (ms) Cold-Start W arm-Start Scenario p50 p95 p99 Succ. p50 p95 p99 Succ. ∆ p50 Low 5,037 5,791 5,938 100% 463 755 1,162 100% + 4,574 ms Medium 366 5,340 5,729 100% 406 3,770 5,039 100% − 40 ms High 377 8,995 10,873 100% 522 9,147 9,915 100% − 145 ms Burst 361 6,059 6,485 100% 435 3,762 5,083 100% − 74 ms Cold-start: all function pods deleted at UE start. W arm: from T able IV. All values 3-run averages. Low Medium High Burst 0 5 10 15 20 7 . 9 8 . 6 9 . 5 9 . 5 2 . 3 3 . 8 5 . 2 5 . 3 5 . 6 17 . 4 18 18 . 3 CPU Rate (s min − 1 ) Serverless5GC Open5GS Free5GC Fig. 4: CPU resource consumption rate (seconds per minute of measurement window) across key traf fic scenarios. Burst uses a 5-minute window; all other scenarios use a 10-minute window . window , yielding an 11 × median latenc y increase (5,037 ms vs. 463 ms warm). In multi-batch scenarios (500–1,000 UEs), only the first 100-UE batch ov erlaps with cold-start; since 80– 90% of UEs arriv e after pods hav e initialized, the median is comparable to or below the warm baseline ( ∆ p50 of − 40 to − 145 ms). The cold-start cohort is visible in the tail: p95 increases by 1,570–2,297 ms relati ve to warm p95, and p99 reaches 10,873 ms in the high scenario. The ke y finding is that there is zero NAS timeouts. Across all 12 cold-start runs, the system achiev es 100% r e gistration success with no T3510 timer expirations. The worst-case p99 of 10,873 ms consumes 72.5% of the 15 s T3510 budget. The system con ver ges to warm-start performance within 4– 5 seconds, enabled by lightweight Go binaries (15 MB RSS per replica) and local image caching. F . Resour ce Consumption T able VIII 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 v alues are reported as b usy CPU seconds per minute (sum of non-idle CPU deltas over the measurement windo w , divided by window length: 10 min for steady-state, 5 min for burst). T ABLE VIII: Node-Le vel Resource Consumption (3-run avg.) Serverless5GC Open5GS fr ee5GC Scenario CPU Mem CPU Mem CPU Mem Idle 7.6 2105 2.0 1368 3.4 1378 Low 7.9 2130 2.3 1442 5.6 1463 Medium 8.6 2136 3.8 1524 17.4 1522 High 9.5 2138 5.2 1605 18.0 1584 Burst 9.5 2134 5.3 1493 18.3 1535 CPU: busy seconds min − 1 (non-idle delta ÷ window). Mem: used MB (8 GB − av ailable). Memory is reported as used memory (total minus a vailable) in MB. The serverless architecture has a higher baseline CPU (7.6 s min − 1 idle vs. 2.0 for Open5GS, 3.4 for free5GC) due to the K3s control plane, OpenFaaS, Redis, and etcd. Ho wev er , CPU growth from idle to high load is only + 25% (7.6 → 9.5), compared to + 160% for Open5GS (2.0 → 5.2) and + 429% for free5GC (3.4 → 18.0). 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 v ariation (Open5GS + 17%, free5GC + 15%). All utilization levels remain below 8% of the 4-vCPU capacity at this testbed scale. The higher serverless baseline is attributable to the or- chestration platform (K3s + OpenF aaS account for 1,130 MB, or 53.7% of the 2,105 MB total), not the function workload ( 31 × 15 MB = 465 MB, comparable to a single Open5GS NF process). G. Cost Model The ev aluation data (T ables VIII and VI) permit a for - mal cost comparison between the serverless and alw ays-on deployment models using the platform-independent resource- time metric (GB-seconds). The key measured quantities are: • M s = 2 , 105 MB: total serverless memory at idle (T a- ble VIII), decomposed as platform base M p = 1 , 640 MB (K3s: 820, OpenFaaS: 310, Redis: 85, etcd: 65, OS: 360) plus function replicas M f = 465 MB ( 31 × 15 MB). • M a = 1 , 368 MB: Open5GS always-on baseline at idle. • M i = 150 MB: state stores only (Redis: 85, etcd: 65), the minimum persistent infrastructure required if functions run on a managed FaaS platform. • g = 0 . 002 GB-s: resource-time per registration (8 in v o- cations × 128 MB × 15.56 ms total execution). The total resource-time consumption over period T (in seconds) depends on the deployment scenario. Let λ denote the av erage registration rate (reg/s) and d ∈ [0 , 1] the duty cycle , defined as the fraction of T during which traffic is present. 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 acti ve: G s = ( M p + d · M f ) · T + λ · d · T · g (1) G a = M a · T (2) Setting G s = G a and noting that λ · d · g is negligible (at 20 reg/s: λg = 0 . 04 MB, four orders of magnitude below M p ): d ∗ ≈ M a − M p M f = 1 , 368 − 1 , 640 465 = − 0 . 59 (3) The negati ve value indicates that M p > M a : the platform ov erhead alone (1,640 MB) exceeds the alw ays-on baseline (1,368 MB). On a dedicated single-tenant VM, the serverless deployment is ne ver 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 OpenF aaS gate way (310 MB), which together account for 1,130 MB of fixed cost absent from the Docker Compose baselines. 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 · d · T + λ · d · T · g (4) Setting G s = G a : d ∗ = M a M s + λ · g ≈ M a M s = 1 , 368 2 , 105 = 0 . 65 (5) The serverless deplo yment is cheaper when the cluster runs less than 65% of the time. For a pri vate 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%. 3) Multi-T enant 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 ( K ) s =  M p K + d · M f  · T (6) Setting G ( K ) s = G a with d = 1 (worst case, all tenants always active): K ∗ =  M p M a − M f  =  1 , 640 1 , 368 − 465  =  1 , 640 903  = 2 (7) W ith two or more tenants on a shared platform, the per- tenant serverless cost falls belo w the always-on baseline e ven at full duty cycle. 4) Managed F aaS: On a managed platform (e.g., A WS 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-in v ocation costs remain: G s = M i · T + λ · T · g (8) Setting G s = G a : λ ∗ = M a − M i g = 1 . 218 GB 0 . 002 GB-s = 609 reg/s (9) Below 609 reg/s average, the managed serverless deploy- ment consumes less resource-time than the al ways-on baseline. T ABLE IX: Cost Model: Break-Even Conditions Scenario Condition Threshold Self-hosted, platform on Ne ver cheaper M p > M a Self-hosted, cluster of f d < d ∗ d ∗ = 0 . 65 Multi-tenant self-hosted K ≥ K ∗ K ∗ = 2 Managed FaaS λ < λ ∗ λ ∗ = 609 reg/s 5) Summary: T able IX summarizes the four deployment scenarios. This model identifies the orchestration platform ov erhead as the dominant cost factor for self-hosted deployments: the 1,130 MB K3s/OpenFaaS footprint must be amortized across idle periods (cluster shutdo wn) or tenants (shared platform) to of fset the always-on baseline. On managed FaaS platforms, this ov erhead is absent, and the per-in v ocation cost is lo w enough that serv erless remains cheaper up to 609 reg/s, well abov e typical priv ate network signaling rates. H. Discussion The ev aluation results highlight se veral points for serverless 5G core design: Or chestr ation dominance. amf-initial-registration accounts for 46.5% of total function compute time but only 12.5% of in v ocations, 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 A USF functions each complete in under 1 ms. Burst r esilience without pr e-pr ovisioning. Under b urst traffic (50 reg/s, 2.5 × the sustained high rate), the serverless archi- tecture absorbs the spike with comparable end-to-end latency (435 ms b urst vs. 406 ms medium, + 7%) and internal function ex ecution increasing by only + 2.4%. No pre-scaling, capacity reservation, or manual intervention was required, which suits ev ent-dri ven deployments (stadiums, festiv als, disaster recov- ery). Pr otocol translation overhead. The total internal function ex ecution time (15.56 ms for 8 inv ocations) represents 3.4% of the a verage end-to-end re gistration latency (456.5 ms). The remainder is dominated by the multi-step N AS procedure in- herent to 3GPP registration (three SCTP round trips) plus UE- side cryptographic processing. Serverless in vocation ov erhead is therefore negligible relati ve 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 [15] within serverless functions to further reduce external state lookups, eliminating both inter-NF traffic and idle resource costs simul- taneously . T owar d a hybrid arc hitectur e. A production serverless 5G core would benefit from a hybrid deployment model: latency-critical NFs (AMF , SMF) with persistent deployment and reserved capacity , combined with FaaS-backed R17 NFs (NWD AF , CHF , NSA CF) that are in v oked sporadically and tol- erate 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. I. Limitations and Futur e W ork (1) Scale and platform : the e valuation targets pri v ate net- works (50 re g/s, 1,000 UEs); carrier-grade deployments would require multi-node K3s clusters, OpenFaaS gate way load bal- ancing, Redis clustering, and redundant SCTP proxy replicas behind an SCTP-aware load balancer . (2) Cold-start and migration : the 11 × latency penalty under low-UE cold-start conditions motiv ates predicti ve 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 cov ers control plane only; extending to the UPF using eBPF or DPDK, and v alidating with physical gNBs and commercial UEs under real radio conditions, remain open. V . C O N C L U S I O N This paper has presented Serv erless5GC, an implementation of 31 serverless functions across 12 3GPP network functions (Release 15–17) on open-source infrastructure (OpenFaaS, K3s, Redis, etcd), with an SCTP/NGAP proxy for standard N2 interface compatibility . The ev aluation against Open5GS and free5GC leads to two key findings. First, the Procedure-as-a-Function decomposition does not degrade signaling performance: median re gistration latency (406–522 ms) matches the C-based Open5GS baseline (403–606 ms), internal function execution (15.56 ms for 8 in vocations) accounts for 3.4% of end-to-end latenc y , and 100% registration success is maintained across all scenar- ios including worst-case cold-start storms. Second, the cost advantage of serverless 5G core deployment is conditional, not absolute. The resource-time cost model (Section IV -G) shows that on a single self-hosted VM, the orchestration platform overhead (1,640 MB for K3s and OpenFaaS) exceeds the always-on baseline (1,368 MB), making serverless more expensi ve at any traffic le vel. The cost advantage materializes under three conditions: (1) the cluster is shut down during idle periods (break-e ven at 65% duty c ycle, i.e., cheaper for any deployment acti ve less than 15.6 h/day); (2) two or more tenants share the platform; or (3) functions run on a managed FaaS pro vider , where serverless is cheaper up to 609 reg/s. This result has a practical implication for priv ate 5G deploy- ments. The serverless model is not a univ ersal replacement for always-on architectures, but it is cost-effecti ve in the specific case of priv ate networks: intermittent traffic, lo w duty cycles, and limited subscriber counts. A campus network activ e 8 h/day ( d = 0 . 33 ) consumes 51% of the resource- time of an always-on equi valent, with no loss in latency or reliability . R E F E R E N C E S [1] S. Lee, “Open5GS: Open source project of 5GC and EPC, ” https: //open5gs.org/, 2023. [2] free5GC, “free5GC: The free 5G core network, ” https://free5gc.org/, 2023. [3] H. Dinh-T uan, M. Mora-Martinez, F . Beierle, and S. R. Garzon, “De- velopment frame works for microservice-based applications: Ev aluation and comparison, ” in Pr oceedings of the 2020 European Symposium on Softwar e Engineering , 2020, pp. 12–20. [4] E. Goshi, R. Stahl, H. Hark ous, M. He, R. Pries, and W . Kellerer , “PP5GS—An Efficient Procedure-Based and Stateless Architecture for Next-Generation Core Networks, ” IEEE T r ansactions on Network and Service Management , v ol. 20, no. 3, pp. 3318–3333, 2022. [5] 3GPP, “System architecture for the 5g system (5gs), ” 3GPP , T ech. Rep. TS 23.501 v18.6.0, Sep. 2024. [6] ——, “Procedures for the 5g system (5gs), ” 3GPP , T ech. Rep. TS 23.502 v18.6.0, Sep. 2024. [7] T . Mukute, L. Mamushiane, A. A. L ysk o, E.-R. Modroiu, T . Magedanz, and J. Mwangama, “Control Plane Performance Benchmarking and Feature Analysis of Popular Open-Source 5G Core Networks: Openair- interface, open5gs, and free5gc, ” IEEE Access , vol. 12, pp. 113 336– 113 360, 2024. [8] G. Lando, L. A. F . Schierholt, M. P . Milesi, and J. A. Wickboldt, “Evaluating the performance of open source softw are implementations of the 5G network core, ” in NOMS 2023-2023 IEEE/IFIP Network Operations and Mana gement Symposium . IEEE, 2023, pp. 1–7. [9] A. Singhvi, J. Khalid, A. Akella, and S. Banerjee, “SNF: Serverless network functions, ” in Pr oceedings of the 11th A CM Symposium on Cloud Computing , 2020, pp. 296–310. [10] D. Breitgand, A. W eit, S. Rizou, D. Griffin, U. Acar , G. Carrozzo, N. Zioulis, P . Andriani, and F . Iadanza, “T owards serverless NFV for 5G media applications, ” in Pr oceedings of the 11th ACM International Systems and Stora ge Conference , 2018, pp. 118–118. [11] K. Hou, S. Lin, Y . Chen, and V . Y egneswaran, “QFaaS: accelerating and securing serverless cloud networks with QUIC, ” in Pr oceedings of the 13th Symposium on Cloud Computing , 2022, pp. 240–256. [12] Q. Zeng, K. Hou, X. Leng, and Y . Chen, “DirectFaaS: A Clean-Slate Network Architecture for Efficient Serverless Chain Communications, ” in Proceedings of the ACM W eb Conference 2024 , 2024, pp. 2759–2767. [13] H. W atanabe, K. Akashi, K. Shima, Y . Sekiya, and K. Horiba, “A Design of Stateless 5G Core Network with Procedural Processing, ” in 2023 IEEE International Black Sea Conference on Communications and Networking (BlackSeaCom) . IEEE, 2023, pp. 199–204. [14] K. Akashi, S. Y amamoto, H. Sakurai, K. Ito, T . Ishihara, T . Iimura, Y . Sekiya, H. W atanabe, K. Shima, and K. Horiba, “Cloud5GC: Design and Implementation of Scalable and Stateless Mobile Core System on Public Cloud, ” in 2024 International Confer ence on Information Networking (ICOIN) . IEEE, 2024, pp. 310–315. [15] E. Goshi, V . Karunakaran, H. Harkous, R. Pries, and W . Kellerer , “Procedure-A ware Stateless Systems for 5G & Beyond Core Networks, ” in GLOBECOM 2023-2023 IEEE Global Communications Confer ence . IEEE, 2023, pp. 5403–5408. [16] H. Dinh-T uan and F . Beierle, “MS2M: A message-based approach for liv e stateful microservices migration, ” in 2022 5th Conference on Cloud and Internet of Things (CIoT) . IEEE, 2022, pp. 100–107. [17] Y . Y ang and M. C. B. Rodrigo, “Non-Structured Data Storage Function (UDSF) Services, ” 2019, patent WO 2019/015778 A1, T elefonaktiebo- laget LM Ericsson. [18] 3GPP, “NG-RAN; NG application protocol (NGAP), ” 3GPP , T ech. Rep. TS 38.413 v18.2.0, Sep. 2024. [19] ——, “Non-access-stratum (N AS) protocol for 5G system (5GS), ” 3GPP , T ech. Rep. TS 24.501 v18.8.0, Sep. 2024. [20] A. G ¨ ung ¨ or , “UERANSIM: Open source 5G UE and RAN (gNB) implementation, ” https://github .com/aligungr/UERANSIM, 2023. [21] H. Dinh-T uan and F . F . Six, “Optimizing Cloud-Native Services with SA GA: A Service Affinity Graph-Based Approach, ” in 2024 Interna- tional Confer ence on Smart Applications, Communications and Net- working (SmartNets) . IEEE, 2024, pp. 1–6. [22] H. Dinh-T uan and J. Jiang, “Optimizing Stateful Microservice Migration in Kubernetes with MS2M and F orensic Checkpointing, ” in 2025 28th Confer ence on Innovation in Clouds, Internet and Networks (ICIN) . IEEE, 2025, pp. 83–90.