{"id":"c11c2cd4-37c0-4f3a-a738-6a6105738e6f","arxiv_id":"2509.07410","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"TEGRA shows a service-based 5G core can match consolidated competitors' latency by combining sticky per-UE routing, soft state, and autoscaling without giving up modular microservices.","lead":"This paper presents TEGRA, a 5G network core built from flexible microservices that keeps per-user data local and routes each user's messages to the same server. In tests it handled registration and data-session requests faster than several open-source cores while retaining the modular design 5G standards call for.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 'matches CoreKube' claim rests on a non-reproducible ~CoreKube projection: raw CoreKube is faster as measured, and §6.1.2 gives no valid LoC-to-latency conversion.","rationale":"The reader's weakest assumption identifies the ~CoreKube projection, and I agree it is the load-bearing assumption. I considered the gNBSimRT emulator and the 256-UE ceiling as alternatives, but Figure 11 extends TEGRA vs Aether to 25K real-trace UEs, and the emulator is disclosed as a custom tool. The CoreKube comparison is unique in supporting the abstract's 'state-of-the-art' claim. The projection is unsubstantiated: LoC deltas are not shown to predict runtime, the scaling formula is absent, and for SR no CoreKube measurement exists to scale. Therefore the parity claim cannot be accepted as written. I would keep the reader's CONDITIONAL verdict: the strong comparison against Aether et al. stands, but the headline must either be backed by a measured completed-CoreKube or downgraded to a clearly labeled estimate.","tokens_in":22967,"tokens_out":8808,"duration_ms":94639,"concrete_test":"Extend the referenced CoreKube commit (andrewferguson/corekube5g-worker, commit fd91920d) with the missing SR and downstream PFCP/UPF handling, using Open5GS as the functional reference, and measure REG/PDU/SR end-to-end latency at 32–256 UEs on the same testbed (§6.1.1). Compare against the ~CoreKube projections in Figure 7. If completed CoreKube is faster than TEGRA, the 'matches CoreKube' claim fails; if the projections are not reproduced, §6.1.2's estimation method is invalid.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's headline claim that TEGRA 'matches state-of-the-art cores (e.g., CoreKube) while retaining flexibility' is supported only by the constructed ~CoreKube baseline, not by measured CoreKube. Figure 7 shows CoreKube (as implemented) has the lowest latency; the paper says this is because CoreKube is incomplete. Section 6.1.2 then estimates missing functionality as 67%, 71%, and 733% additional LoCs from Open5GS and 'project[s] the associated runtime overhead by scaling CoreKube's measured latency ... using a 2.2 GHz CPU.' No formula connects LoC percentages to latency, no evidence shows latency scales with code size, and for SR CoreKube has no measured latency to scale because the paper states CoreKube lacks SR support. The ~CoreKube bars in Figure 7 are therefore non-reproducible. This matters because the parity claim is the evidence that disaggregation avoids the flexibility/performance tradeoff; without it, TEGRA only beats other disaggregated SBA cores while the consolidated CoreKube remains faster as implemented.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper argues that service-based architecture (SBA) mobile cores need not sacrifice flexibility for performance and scalability. It presents TEGRA, a Go-based SBA 5G core built by modifying Aether modules and adding gateway microservices, UE-based sticky load balancing, soft-state per-UE caching, a distributed publish/subscribe state-sharing mechanism (DRSM), and horizontal autoscaling. The evaluation on a three-server Proxmox/Kubernetes edge cloud compares TEGRA with Aether, free5GC, Open5GS, Magma, and CoreKube across Registration, PDU Session Establishment, and Service Request, using both synthetic and operator-derived real traces. The paper claims TEGRA is 20x/11x/1.75x faster than free5GC/Open5GS/Aether, matches the state-of-the-art CoreKube while retaining flexibility, and requires orders of magnitude fewer lines of code to extend.","tokens_in":23277,"tokens_out":6355,"duration_ms":73628,"significance":"If the central claims hold, the paper would provide a valuable counterexample to the prevailing assumption that disaggregated SBA cores must trade flexibility for latency. The evaluation is extensive: it includes multiple baselines, three control-plane events, scaling from 32 to 256 UEs, real traces, autoscaling microbenchmarks, state-cache ablation, and failure injection. The design patterns and the soft-state/sticky-load-balancing combination are concrete and plausibly generalizable. However, the headline claim that TEGRA 'matches CoreKube' rests on the authors' constructed ~CoreKube baseline rather than on a measured complete CoreKube implementation. That projection is not reproducible from the information given, and it is load-bearing for the paper's main 'no tradeoff' thesis. The other contributions remain credible, but the parity result needs either rigorous justification or removal from the central claims.","major_comments":[{"comment":"The claim that TEGRA 'matches CoreKube' is supported only by the authors' ~CoreKube construction. Section 6.1.2 estimates missing CoreKube functionality as 67%, 71%, and 733% additional LoCs based on Open5GS, and states that the authors 'project the associated runtime overhead by scaling CoreKube's measured latency ... using a 2.2 GHz CPU.' No formula or empirical relationship connects LoC percentages to latency, and for Service Request CoreKube has no measured latency to scale. The ~CoreKube bars in Figure 7 are therefore non-reproducible. Because the Abstract and Section 6.2 use 'matches CoreKube' as evidence that flexibility does not cost performance, this is a load-bearing issue. Please either present raw CoreKube as a separate measured baseline and remove/qualify the parity claim, or provide a validated overhead model (e.g., per-function profiling) with explicit assumptions, sensiti","section":"§6.1.2, Figure 7, Abstract"},{"comment":"Table 1 labels TEGRA as 'fully 3GPP-compliant' and 'operational,' but the evaluation exercises only Registration, PDU Session Establishment, and Service Request, all via the custom gNBSimRT emulator. No conformance or interoperability tests are reported for other mandatory 3GPP procedures, such as handover, deregistration, AN release, or paging under load. The compliance claim is stronger than the presented evidence. Either add conformance evidence from a recognized test suite or narrow the claim to 'supports the evaluated procedures in a 3GPP-compliant manner.'","section":"§6.1.3, Table 1"},{"comment":"The abstract's headline '20x, 11x, and 1.75x faster than free5GC, Open5GS, and Aether' is not reconciled with Section 6.2, which explicitly reports only 'up to 1.74x speedup for Registration, 1.5x for PDU session establishment, and 1.75x for Service Request at 256 UEs compared to Aether.' The 20x and 11x numbers presumably come from comparisons with free5GC and Open5GS, but the body does not derive them. Please state the event, UE count, and baseline for each number, and ensure the abstract's claims match the presented data.","section":"§6.2, Abstract"}],"minor_comments":[{"comment":"Typo: 'looses' should be 'loses.'","section":"§6.2"},{"comment":"Typo: 'central schedular' should be 'central scheduler.'","section":"§4.1.2"},{"comment":"Formatting: 'TEGRAoptimizes performance' lacks a space; similar spacing issues appear elsewhere.","section":"Abstract"},{"comment":"The figure is hard to parse from the text: panel labels, baseline indication, and the distinction between measured and projected bars should be stated in the caption. It would help to include absolute latencies and confidence intervals, not only speedups.","section":"Figure 7"},{"comment":"The sentence 'Adding a new service (i.e., NRF)' is confusing because TEGRA already includes NRF. Clarify whether the experiment is adding a new NRF instance or a different service, and how the single-line config change is counted.","section":"§6.3.5"},{"comment":"CoreKube's missing functionality is described slightly differently in the footnote (downstream PFCP support) and in §6.1.2 (SR and UPF support). Please harmonize the descriptions.","section":"§2, §6.1.2"},{"comment":"gNBSimRT is built for this paper but no artifact release is mentioned. Please state whether the emulator and trace will be made available, since this affects reproducibility of the evaluation.","section":"§6.1.1"}],"recommendation":"major_revision","confidential_remarks":"The main issue is the non-reproducible ~CoreKube baseline. The parity claim in the Abstract and Section 6.2 should be removed or rigorously supported before acceptance. The rest of the evaluation is solid and the paper fits the journal's scope, so major revision rather than rejection seems appropriate."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's the short version. TEGRA is a serious systems contribution: it shows that a disaggregated SBA core can scale to 256 UEs with lower control-plane latency than Aether, free5GC, Open5GS, and Magma, using per-UE sticky routing, soft state, and a pub/sub state bus. The bidirectional-control-plane insight is real, and the engineering (gateway pattern, UELB, DRSM) is presented in enough detail to be usable. The evaluation against measured baselines is extensive and, as far as I can tell, honest.\n\nWhere it gets shaky is the CoreKube comparison. The paper says CoreKube is incomplete and therefore constructs a ~CoreKube baseline by scaling CoreKube's measured latency by the percentage of additional LoCs needed to implement missing features (67%, 71%, 733% for REG, PDU, SR). There is no model connecting LoCs to latency, and for SR there is no CoreKube measurement at all to scale. The stress-test note is right: the Figure 7 bars for ~CoreKube are not reproducible, and they are the only support for the abstract's 'matching CoreKube' claim. Without that claim, the tradeoff argument weakens—TEGRA beats other disaggregated cores, but the consolidated champs (CoreKube as actually built) remain faster.\n\nThat's a real flaw, but it's localized. The measured wins against Aether at 256 UEs (1.74x REG, 1.5x PDU, 1.75x SR) don't depend on the projection. The failure-resilience and autoscaling microbenchmarks are nice. The LoC comparison for adding a service (1 line vs 1705 lines) is a bit apples-to-oranges, but it's illustrative.\n\nI want error bars and ideally artifacts; the paper leans hard on a custom emulator and trace from prior work, so independent checking is hard without releases. The self-referential test harness is fine, but it makes the results less immediately checkable.\n\nWho is this for? Researchers working on 5G/6G control-plane performance and cloud-native network functions. It deserves a serious referee: send it out, but make the authors either run a complete CoreKube build or cut the parity claim and adjust the narrative. I would accept it after that revision, not before.","headline":"A well-engineered SBA 5G core with real speedups over Aether/free5GC/Open5GS, but the headline 'matches CoreKube' claim rests on an invented baseline that should not survive as stated.","tokens_in":23739,"tokens_out":2150,"would_cite":true,"duration_ms":23966,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"TEGRA shows a 3GPP service-based mobile core can match a consolidated monolithic core's latency while preserving microservice flexibility.","keywords":["5G core","service-based architecture","mobile core","microservices","control plane","autoscaling","resilience","load balancing"],"falsifier":"On the same three-server edge cloud, implement the missing Service Request, PDU session, and UPF support in CoreKube and measure end-to-end control-plane latency at 256 UEs for Registration, PDU establishment, and Service Request; if the completed CoreKube's actual latencies are materially below TEGRA's, the paper's central parity claim fails.","tokens_in":22906,"feed_emoji":"📡","tokens_out":4075,"duration_ms":48867,"temperature":0.7,"pith_summary":"This paper asks whether a service-based 5G mobile core must sacrifice scalability and performance to stay flexible. It answers no, by proposing TEGRA, a 3GPP-compliant core that keeps per-user state in service instances, routes both upstream and downstream control messages to the same instance, and shares load and state information through a distributed publish-subscribe mechanism. In experiments on a three-server edge cloud, TEGRA processes registration, PDU session, and service-request events up to 1.74x, 1.5x, and 1.75x faster than Aether at 256 UEs, and roughly matches the projected performance of the consolidated CoreKube baseline. The paper also claims TEGRA needs orders of magnitude fewer lines of code to add a new service or event, because deploying a new feature can be a single-line configuration change. The broader claim is that the perceived tradeoff between SBA flexibility and control-plane performance is not inherent.","feed_headline":"5G core keeps microservice flexibility and beats consolidated rivals","feed_subtitle":"TEGRA reports up to 1.74x faster control-plane events than Aether while matching a projected monolithic CoreKube baseline.","key_machinery":"The design rests on four microservice patterns: Gateway (separate SCTP and PFCP termination services that proxy into the core), Long-Running (stateful services like AMF, SMF, NRF that keep a soft per-UE cache), Ephemeral (stateless services like UDM, PCF that transform messages without local state), and Storage (persistent databases for UE and service state). These are carried by two mechanisms: UELB, a client-side load balancer that pins each UE to one service instance based on the UE identifier, and DRSM, a distributed publish-subscribe state-sharing service that keeps instances aware of each other's load, instance count, and allocated ID/IP blocks. The soft-state caching is what reduces s","core_discovery":"TEGRA is a high-performance, flexible, scalable, and resilient SBA-based 5G core that avoids reverting to NFV-style consolidation. Its core discovery is that the mobile core's position at the network edge, handling bidirectional asynchronous control events from both UEs and the Internet, allows cloud-native techniques to be re-designed: per-UE soft state cached inside service instances with asynchronous persistence to storage, UE-based sticky load balancing so both directions of a UE's traffic hit the same instance, and a distributed resource-sharing mechanism (DRSM) that shares load and allocation state without a central scheduler. The paper reports end-to-end control-plane latency improvem","pith_inferences":["The headline parity with CoreKube is not a direct measurement: the paper constructs a projected ~CoreKube baseline by estimating missing lines of code and scaling measured latency on a 2.2 GHz CPU, so actual parity with a completed CoreKube remains to be demonstrated.","The four design patterns and UE-sticky routing could generalize beyond cellular cores to other stateful edge services that receive asynchronous events from both clients and the network, such as IoT gateways or real-time session brokers.","Because the evaluation uses one operator's week-long control-plane trace and a custom emulator, the scalability claims are tied to that workload; testing with other operators' traces and with higher UE churn would show how much of the speedup is workload-specific.","TEGRA's microservice decomposition may make hardware acceleration easier: the authors point toward offloading hot services onto SmartNICs, a direction not evaluated in this paper but a natural next test."],"forward_implications":["If TEGRA's central claim holds, operators can horizontally autoscale individual control-plane services like AMF and SMF without losing consistency, because UE-sticky routing keeps bidirectional messages on the same instance.","The soft-state approach implies steady-state control-plane latency can be close to stateful in-memory processing, while failure recovery still works by pulling the latest committed state from storage, so resilience does not have to come from sacrificing performance.","Adding a new service or event in TEGRA reduces to a single-line configuration change plus CI/CD deployment, versus about 1,700 lines and full recompilation in a consolidated core, which would sharply lower the cost of introducing new 5G features.","The paper's results suggest that consolidation-based cores such as CoreKube are not the only way to meet latency targets; a disaggregated SBA core can stay within control-plane latency budgets at hundreds of UEs and in real traces at tens of thousands of UEs."],"supporting_citations":[{"why":"Supplies the Aether SBA core that TEGRA builds on and uses as the primary performance baseline.","marker":"[11]"},{"why":"Defines CoreKube, the consolidated stateless core whose performance TEGRA claims to match and whose missing functionality motivates the projected ~CoreKube baseline.","marker":"[37]"},{"why":"Represents the prior L25GC consolidation approach that TEGRA explicitly contrasts with on flexibility.","marker":"[48]"},{"why":"Defines the 3GPP 5G system architecture and service-based interface that TEGRA must remain compliant with.","marker":"[4]"},{"why":"Provides the real operator control-plane trace used to evaluate TEGRA at large UE counts.","marker":"[64]"},{"why":"Supplies the gNBSim open-source testing tool that the paper extends into gNBSimRT for control-event emulation.","marker":"[40]"},{"why":"Serves as a C-based SBA baseline and is the source of the line-of-code estimates used to project ~CoreKube's missing functionality.","marker":"[73]"},{"why":"Provides the free5GC SBA baseline that TEGRA outperforms in speedup comparisons.","marker":"[38]"},{"why":"Provides Magma, a consolidated mobile core baseline compared in the evaluation.","marker":"[61]"}],"fun_headline_variants":["TEGRA 5G core: flexible, scalable, and beats rivals without consolidation","Edge-smart TEGRA 5G core stays flexible and fast, no tradeoff","TEGRA: SBA 5G core that's flexible, scalable, and faster than rivals","TEGRA uses edge to beat tradeoff: flexibility and speed","TEGRA 5G core: microservice flexibility, monolithic-class performance"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The claim that TEGRA matches CoreKube's performance rests on a projected ~CoreKube baseline built by estimating missing lines of code and scaling measured latency on a 2.2 GHz CPU; if that projection is inaccurate, the parity claim is unsupported.","fun_headline_variants_meta":{"raw":{"variants":["TEGRA 5G core: flexible, scalable, and beats rivals without consolidation","Edge-smart TEGRA 5G core stays flexible and fast, no tradeoff","TEGRA: SBA 5G core that's flexible, scalable, and faster than rivals","TEGRA uses edge to beat tradeoff: flexibility and speed","TEGRA 5G core: microservice flexibility, monolithic-class performance"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001246,"raw_usage":{"total_tokens":4979,"prompt_tokens":805,"completion_tokens":4174,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":549,"completion_tokens_details":{"reasoning_tokens":4065}},"tokens_in":549,"tokens_out":4174,"duration_ms":28828,"temperature":1.0,"reasoning_tokens":4065,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T22:14:04.403836+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"On the same three-server edge cloud, implement the missing Service Request, PDU session, and UPF support in CoreKube and measure end-to-end control-plane latency at 256 UEs for Registration, PDU establishment, and Service Request; if the completed CoreKube's actual latencies are materially below TEGRA's, the paper's central parity claim fails.","supporting_citations":[{"cited_title":"Corekube: An efficient, autoscaling and resilient mobile core system","cited_arxiv_id":null,"evidence_quote":"Defines CoreKube, the consolidated stateless core whose performance TEGRA claims to match and whose missing functionality motivates the projected ~CoreKube baseline."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Represents the prior L25GC consolidation approach that TEGRA explicitly contrasts with on flexibility."},{"cited_title":"Modeling and Generating Control-Plane Traffic for Cellular Networks","cited_arxiv_id":null,"evidence_quote":"Provides the real operator control-plane trace used to evaluate TEGRA at large UE counts."},{"cited_title":"https://github.com/omec-proje ct/gnbsim","cited_arxiv_id":null,"evidence_quote":"Supplies the gNBSim open-source testing tool that the paper extends into gNBSimRT for control-event emulation."},{"cited_title":"https://open5gs.org/open5gs/docs/guide/01-quick start//","cited_arxiv_id":null,"evidence_quote":"Serves as a C-based SBA baseline and is the source of the line-of-code estimates used to project ~CoreKube's missing functionality."},{"cited_title":"Last accessed: 03/2025","cited_arxiv_id":null,"evidence_quote":"Provides the free5GC SBA baseline that TEGRA outperforms in speedup comparisons."},{"cited_title":"https://magmac ore.org","cited_arxiv_id":null,"evidence_quote":"Provides Magma, a consolidated mobile core baseline compared in the evaluation."}],"review_version":1}