Pith. sign in

REVIEW 5 major objections 6 minor 48 references

AI5GTest: AI-Driven Specification-Aware Automated Testing and Validation of 5G O-RAN Components

T0 review · 5 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read An LLM pipeline claims it can automate O-RAN testing, cutting each test case to under an hour.

desk verdict A clever LLM pipeline for O-RAN test validation, but the 100% accuracy claim rests on a tiny self-labeled dataset and a one-step-per-log-entry assumption that real nested signaling will break. read the letter →

arxiv 2506.10111 v1 pith:YLAU7JDM submitted 2025-06-11 cs.NI cs.LG

Abiodun Ganiyu , Pranshav Gajjar , Vijay K Shah This is my paper
classification cs.NIcs.LG
keywords O-RANLLM3GPPautomatedtestingspecification-awarevalidationproceduralflowgenerationrootcauseanalysisRAG
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

AI5GTest is a framework that uses three cooperating large language models to automate the testing of 5G O-RAN components against 3GPP and O-RAN specifications. Its central claim is that an LLM pipeline can replace the manual work of extracting expected procedural flows from standards documents and cross-referencing captured signaling logs, reducing test execution time from roughly fifteen hours per test case to under one hour while keeping validation accuracy high. The paper reports perfect validation accuracy on its small evaluation set and lower semantic distance to ground-truth flows than GPT-4o and Gemini across 24 flow-generation tasks. If correct, this would make large-scale, repeatable conformance and interoperability testing of multi-vendor O-RAN components practical.

What carries the argument

The central mechanism is the sequential per-entry validation loop of Val-LLM: a LLaMA-3.1:70B forward pass classifies whether the current procedural step is executed in the current log entry, advancing the step counter only on a positive classification and assuming a single log index cannot satisfy multiple steps. This decomposition into atomic classification calls is designed to avoid attention overflow that the authors say prevents GPT-4o and Gemini from validating entire logs directly. Gen-LLM relies on a reranking-enhanced retrieval pipeline over a database of 5.4 million specification chunks, and Debug-LLM extends the validation loop by exhaustively scanning all log indices for each step to locate chronological violations.

What would settle it

Take a captured O-RAN signaling trace in which a single F1AP or NGAP packet carries two procedural messages that correspond to different steps of an expected flow, run Val-LLM on it, and check whether the one-step-per-entry classification misses one of the steps or produces a spurious failure; a single such misclassification on a compliant trace would disprove the claimed 100% accuracy.

Watch

Extended reading notes

Core claim

The paper claims that a specification-aware LLM framework can automate the full O-RAN test cycle: Gen-LLM retrieves relevant 3GPP and O-RAN specification chunks from a large FAISS-indexed database, reranks them with a BGE-M3 model, and generates expected procedural flows that a human tester approves; Val-LLM then validates captured signaling logs against that flow by making a LLaMA-3.1:70B classification call per log entry, and Debug-LLM performs an exhaustive per-step scan to detect out-of-order executions and missing steps. In the authors' evaluation, the framework achieved 100% validation accuracy (seven true positives, eight true negatives, zero false positives and false negatives) on 15 test case instances, took an average of 48.5 minutes per full test cycle, and produced procedural flows with an average Gemma-Score of 12.581 versus 20.559 for GPT-4o and 20.579 for Gemini.

Load-bearing premise

The whole validation chain rests on the assumption that every procedural step is either fully absent or fully executed within a single log entry, and that no log entry can satisfy more than one step; if a packet bundles several messages or a step spans multiple entries, the strict sequencing logic will misclassify the trace.

Editorial extensions

If this is right

  • O-RAN test execution time could drop from roughly fifteen hours per test case to under one hour, allowing far larger test suites to run in the same validation window.
  • Validation outcomes would no longer depend on individual engineers' interpretation of cross-referenced standards, reducing variability across testers and vendors.
  • The framework could serve as a drop-in validation layer for any 5G system that can export PCAP traces, since its pipeline operates on standardized protocol layers rather than implementation-specific behavior.
  • Debug-LLM's exhaustive step scan could pinpoint exact missing or out-of-order signaling messages, turning a pass/fail verdict into specific root-cause guidance.
  • The human-in-the-loop approval of top-k specifications keeps a human accountable for the generated procedural flow, providing a transparency mechanism before automated validation runs.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The reported 100% accuracy is measured on only 15 instances from a single open-source testbed, so the claim that the pipeline generalizes across vendors and real-world traces is an extrapolation the paper does not directly test.
  • The per-entry LLaMA classification approach could be stress-tested on traces where one packet carries multiple procedural messages or where a single step spans several log entries; the strict one-step-per-entry assumption would likely need revision for such cases.
  • A natural next experiment would be to run the same Val-LLM loop on logs from a second open-source stack or a commercial trace dataset, which would reveal whether the classification prompts transfer across implementations.
  • The Debug-LLM's exhaustive per-step scan costs roughly 42 minutes per failing test case, so future work may need a cheaper way to localize root causes when failures are frequent.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 6 minor

Summary. The paper proposes AI5GTest, an LLM-based framework for automating O-RAN and 3GPP procedural testing. Gen-LLM generates expected signaling flows via RAG over O-RAN and 3GPP specifications with a human-in-the-loop approval step; Val-LLM compares captured packet logs against the expected flow; and Debug-LLM performs root-cause analysis for failures. The evaluation uses 24 test cases for flow generation and 15 test instances for validation on an srsRAN-based testbed, reporting 100% validation accuracy and under one hour per test case when compared with manual testing in an external industry report. The code and packet traces are publicly released.

Significance. If the claims hold, AI5GTest would be a practical step toward reducing manual effort in O-RAN conformance and interoperability testing. The paper's concrete strengths are its modular system design, the public release of code and traces, the use of open-source LLMs, and a systematic comparison against closed-source LLMs on a defined metric. However, the validation chain rests on an unverified single-step-per-log-entry assumption, the ground-truth labels are self-assigned, and the evaluation is small, so the 100% accuracy and timing gains should be read as preliminary rather than established.

major comments (5)
  1. [Section 4.2.6, Algorithm 1] The Val-LLM algorithm advances to the next log index immediately after matching the current procedural step (Algorithm 1, lines 6-8), and Section 4.2.6 states that 'a single log index cannot satisfy multiple procedural steps.' This is not a property of 3GPP/O-RAN signaling: F1AP/NGAP PDUs carry embedded RRC messages, so one captured packet can contain both a transport procedure (e.g., INITIAL UL RRC MESSAGE TRANSFER) and an RRC procedure (e.g., RRCSetupRequest). In such a case, the second step in the same entry is skipped and a compliant trace is classified as Fail; conversely, a step fragmented over multiple PDUs may never be recognized. The evaluation in Section 5.4 uses srsRAN with a monolithic gNB and pre-generated packet captures, which do not exercise this nesting/merging failure mode, so the 100% A_val in Table 1 does not establish generalization to multi-vendor O-RAN traces. Please modify Val-LLM to handle multiple steps per log entry or demonstrate that the PCAP Analyzer splits nested messages into separate log entries, and test this explicitly.
  2. [Section 5.4, Table 1, Eq. (4)] The ground-truth labels for the 15 validation instances were assigned by the authors' manual scrutiny of the same logs that Val-LLM and Debug-LLM are scored against. With 7 TP and 8 TN and no FP/FN, the reported A_val=100% has a 95% Wilson confidence interval whose lower bound is approximately 0.80; a single misclassification would drop accuracy to 93.3%. No confidence interval, inter-rater agreement, or independent labeling is reported. The claim that the framework 'maintains high validation accuracy' therefore needs a larger or independently labeled evaluation, or at minimum an uncertainty estimate, before it can be considered robust.
  3. [Section 5.5, Section 5.6] The timing comparison is not like-for-like. The reported average of 48.551 minutes per test case is the sum of LLM inference times (Gen-LLM, Val-LLM, Debug-LLM) on a testbed with pre-generated packet captures; it does not include testbed setup, test execution, or human review of the top-k specifications. It is compared with a 2021 Aspire Technology pilot [37] that used different test cases, equipment, and team composition. The conclusion that AI5GTest yields 'a significant reduction in overall test execution time' is therefore indicative rather than demonstrated. A controlled comparison on the same test cases, with an explicit statement of what is included in the wall-clock time, is needed.
  4. [Section 5.3, Eqs. (1)-(3), Figure 4] The Gen-LLM comparison relies entirely on Gemma-Score, a Euclidean distance between Gemma-2B embeddings of generated and ground-truth flows. The paper does not validate that this metric tracks procedural correctness (e.g., whether it distinguishes a wrong order from a missing step), and no statistical significance test is reported for the differences between Gen-LLM (12.581) and GPT-4o (20.559) or Gemini (20.579). Because the claim that Gen-LLM 'outperforms' closed-source models is central to the paper's contribution, the authors should add a human evaluation of the generated steps and report variance or a paired test.
  5. [Section 4.2.7, Algorithm 2, Appendix A.2] Algorithm 2 is under-specified and inconsistent with the Appendix's narrative. As written, it selects the earliest log index for each step independently and never removes an index once used; Appendix A.2, however, states that 'all messages are tracked using a used-indices set' so that identical messages for Steps 6, 17, and 21 are not redundantly processed. As written, Algorithm 2 can assign the same message instance to multiple steps and certify an out-of-order or repeated-message trace as chronologically valid. The pseudocode should be aligned with the implementation, and the disambiguation of repeated identical messages should be specified.
minor comments (6)
  1. [Table 2, row TC-06] The test case title 'FI Setup for NR' appears to be a typo for 'F1 Setup for NR', consistent with TC-06 in the text and with reference [26].
  2. [Section 5.2.1] There are typos in this section: 'Gemmna-2B' should be 'Gemma-2B', and the metric name is inconsistently written as 'Gemma-Score' and 'Gemma Score'.
  3. [Appendix A.2] The word 'heirarchical' should be 'hierarchical'.
  4. [Sections 4.1 and 5.1] The component is called both 'PCAP Analyzer' and 'Packet Analyzer'; please standardize the terminology.
  5. [Section 4.2.5] The retrieval parameters (100 documents retrieved, top 15 reranked, top-k presented to the human) are introduced as 'best response' without a sensitivity analysis or ablation; please provide the tuning procedure or a reference to a reproducible configuration.
  6. [Section 4.2.6, Appendix A.1] Please document the JSON schema produced by the PCAP Analyzer, especially how nested protocol layers (e.g., F1AP containing RRC) are represented; the current example contains only an 'f1ap' list, which leaves the single-log-entry assumption unclear.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the reported results are empirical comparisons against external specifications and manual labels, not reductions to the paper's own inputs.

full rationale

AI5GTest is an empirical systems paper; none of its headline numbers is derived by fitting or by definitional identity. Gen-LLM is scored with Gemma-Score against ground-truth procedural flows taken from O-RAN ALLIANCE and 3GPP specifications (Section 5.3), and the reported advantage over GPT-4o and Gemini is an external comparison. Val-LLM and Debug-LLM are scored with A_val computed from TP/TN/FP/FN over 15 test instances whose ground-truth labels are produced by manual scrutiny of logs against 3GPP and O-RAN standards (Section 5.4); the algorithms do not receive these labels during validation, so the 100% accuracy is not forced by construction, although same-author labeling is a legitimate independence limitation. The timing claim is benchmarked against an external industry report [37]. Self-citations ([11], [12], [40]) justify background and component choices (e.g., extending ORANSight's RAG pipeline) but are not the evidence for the central claims. The HITL '100% accuracy with standards' phrasing in the contributions is a definitional design statement rather than an empirical result, and the paper's own Gemma-Score evaluation shows Gen-LLM alone does not achieve perfect alignment. No quoted equation or algorithm reduces a reported prediction to its own input, so no circular step is exhibited.

Assumptions & free parameters 3 free parameters · 4 assumptions · 1 invented entities

The central results rest on a small number of hand-tuned retrieval parameters, the assumption that a single log entry maps to at most one procedural step, and the assumption that srsRAN traces represent multi-vendor O-RAN behavior. The framework itself is the only new conceptual artifact, and its evidence base is the authors' own experiments.

free parameters (3)
  • Initial retrieval count = 100 documents
    Section 4.2.5 states the pipeline retrieves 100 documents and notes that these parameters 'showcased the best response'.
  • Top-k reranked documents = 15 documents
    Section 4.2.5 states the top 15 unique documents from the reranker are used as context, and that increasing the amount of retrieval resulted in lower LLM recall.
  • Human review top-k = 5 specifications
    Section 5.3 says users are offered five specifications for human-in-the-loop approval; this k is a hand-chosen parameter affecting the transparency workflow.
assumptions (4)
  • domain assumption 3GPP and O-RAN specification documents are the correct and complete ground truth for expected procedural flows.
    Used throughout Gen-LLM, Val-LLM, and the evaluation; if specifications are ambiguous, version-mismatched, or misinterpreted, the generated flows and the labels inherit those errors.
  • ad hoc to paper Each procedural step can be reliably detected in a single log entry by LLaMA-3.1:70B, and one log entry cannot contain multiple steps.
    Algorithm 1 advances one step per matched log entry, and Section 4.2.6 explicitly states 'a single log index cannot satisfy multiple procedural steps'.
  • domain assumption srsRAN packet traces expose the same signaling semantics as disaggregated multi-vendor O-RAN components.
    Section 5.1 and footnote 2 acknowledge srsRAN is monolithic, with integrated O-CU and O-DU and no O-RU disaggregation; the evaluation generalizes from this stack to multi-vendor O-RAN.
  • domain assumption Gemma-Score, an embedding distance, is a valid measure of procedural-flow correctness.
    Section 5.2.1 defines Gemma-Score as Euclidean distance between Gemma-2B embeddings; no independent validation shows that lower distance implies correct message names and ordering.
invented entities (1)
  • Cooperative LLM framework (Gen-LLM, Val-LLM, Debug-LLM)
    purpose: Automates generation of expected procedural flows, validation of signaling logs against those flows, and root-cause analysis of failures.
    New architecture introduced by this paper; the only performance evidence is the authors' own 24-case generation study and 15-case validation study, with no independent replication or external benchmark yet.

how reviews work

0 comments
Cite this review

Pith. "Pith review of AI5GTest: AI-Driven Specification-Aware Automated Testing and Validation of 5G O-RAN Components." pith.science (2026). https://pith.science/paper/YLAU7JDM

@misc{pith2026250610111,
  author       = {Pith},
  title        = {Pith review of: AI5GTest: AI-Driven Specification-Aware Automated Testing and Validation of 5G O-RAN Components},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YLAU7JDM}},
  note         = {Machine review of arXiv:2506.10111}
}
read the original abstract

The advent of Open Radio Access Networks (O-RAN) has transformed the telecommunications industry by promoting interoperability, vendor diversity, and rapid innovation. However, its disaggregated architecture introduces complex testing challenges, particularly in validating multi-vendor components against O-RAN ALLIANCE and 3GPP specifications. Existing frameworks, such as those provided by Open Testing and Integration Centres (OTICs), rely heavily on manual processes, are fragmented and prone to human error, leading to inconsistency and scalability issues. To address these limitations, we present AI5GTest -- an AI-powered, specification-aware testing framework designed to automate the validation of O-RAN components. AI5GTest leverages a cooperative Large Language Models (LLM) framework consisting of Gen-LLM, Val-LLM, and Debug-LLM. Gen-LLM automatically generates expected procedural flows for test cases based on 3GPP and O-RAN specifications, while Val-LLM cross-references signaling messages against these flows to validate compliance and detect deviations. If anomalies arise, Debug-LLM performs root cause analysis, providing insight to the failure cause. To enhance transparency and trustworthiness, AI5GTest incorporates a human-in-the-loop mechanism, where the Gen-LLM presents top-k relevant official specifications to the tester for approval before proceeding with validation. Evaluated using a range of test cases obtained from O-RAN TIFG and WG5-IOT test specifications, AI5GTest demonstrates a significant reduction in overall test execution time compared to traditional manual methods, while maintaining high validation accuracy.

Figures

Figures reproduced from arXiv: 2506.10111 by the authors.

Figure 1
Figure 1. High-level overview of AI5GTest Framework. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Reranker score trends for retrieval and procedural [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Testbed setup used for AI5GTest evaluation. [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Heatmap of Gemma-Scores for Different Test Cases. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Visualization of the UE Initial Access over E1 and F1 test case validation with the Ground label Fail (Partial Pass). The Val-LLM converges at Step 11, and the remaining log processing is obtained through the Debug-LLM. The correct procedural flow, as mentioned in 3GPP…
Figure 5
Figure 5. Figure 5: figure 5. The validation process starts with the Val-LLM and Step [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

48 extracted references · 34 canonical work pages

  1. [37]

    Aspire Technology. 2021. Stimulating Open RAN Adoption: Accelerating Vali- dation, Optimization and Deployment. Tech. rep. Accessed: Mar. 5, 2025. Aspire Technology. https://www.aspiretechnology.com/wp-content/uploads/2021/05 /ASPIRE_SUCCESSSTORY_STIMULATINGOPENRANADOPTION_2021.pdf

    work page 2021

  2. [1]

    AI5GTest GitHub Link. 2025. Ai5gtest. (2025). https://github.com/NextG-Lab- NC-State/AI5GTest

    work page 2025

  3. [2]

    O-RAN Alliance. 2023. O-ran certification and badging program. Accessed: 2025-01-10. (2023). https://www.o-ran.org/certification-badging

    work page 2023

  4. [3]

    O-RAN Alliance. 2023. Overview of open testing and integration centre (otic) and o-ran certification and badging program. Accessed: 2025-01-10. (2023). https://www.o-ran.org/o-ran-resources/overview-of-open-testing-and-integra tion-centre-otic-and-o-ran-certification-and-badging-program-white-paper-ap ril-2023

    work page 2023

  5. [4]

    Wilfrid Azariah, Fransiscus Asisi Bimo, Chih-Wei Lin, Ray-Guang Cheng, Navid Nikaein, and Rittwik Jana. 2024. A survey on open radio access networks: challenges, research directions, and open source approaches. Sensors, 24, 3, 1038

    work page 2024

  6. [5]

    Brennan Bogdanovich, Pearl Shah, Parth A Patel, and Carter J Boyd. 2025. Keeping up with ai evolution: chatgpt-4o in surgery. (2025)

    work page 2025

  7. [6]

    L Bonati, S D’Oro, M Polese, S Basagni, and T Melodia. 2021. Intelligence and learning in o-ran for data-driven nextg cellular networks. IEEE Communications Magazine, 59, 10, 21–27

    work page 2021

  8. [7]

    Jianlv Chen, Shitao Xiao, Peitian Zhang, Kun Luo, Defu Lian, and Zheng Liu

Show all 48 references
  1. [8]

    Spirent Communications. 2024. O-ran end-to-end testing: validating open ran deployments. https://www.spirent.com/assets/u/video-o-ran-e2e-testing. Accessed: 2024-02-22. (2024)

    2024

  2. [9]

    Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. 2019. Bert: pre-training of deep bidirectional transformers for language understanding. In Proceedings of the 2019 conference of the North American chapter of the association for computational linguistics: human...

    2019

  3. [10]

    Wireshark Foundation. 2023. Wireshark: TShark Network Protocol Analyzer . https://www.wireshark.org/docs/man-pages/tshark.html

    2023

  4. [11]

    Pranshav Gajjar and Vijay K Shah. 2024. Oran-bench-13k: an open source benchmark for assessing llms in open radio access networks. arXiv preprint arXiv:2407.06245

    2024 arXiv

  5. [12]

    Pranshav Gajjar and Vijay K. Shah. 2025. Oransight-2.0: foundational llms for o-ran. (2025). https://arxiv.org/abs/2503.05200 arXiv: 2503.05200 [cs.CL]

    2025 arXiv

  6. [13]

    Gabriele Gemmi, Michele Polese, Pedram Johari, Stefano Maxenti, Michael Seltser, and Tommaso Melodia. 2024. Open6g otic: a blueprint for programmable o-ran and 3gpp testing infrastructure. (2024). https://arxiv.org/abs/2409.02237 arXiv: 2409.02237 [cs.NI]

    2024 arXiv

  7. [14]

    Dell’Oro Group. 2021. Open ran market: opportunities and risks. Accessed: 2025-01-10. (2021). https://www.delloro.com/wp-content/uploads/2021/11/Dell Oro-Group-Article-Open-RAN-Market-Opportunity-and-Risks.pdf

    2021

  8. [15]

    The TCPDump Group. 2023. TCPDump and Libpcap. https://www.tcpdump.org /. AI5GTest: AI-Driven Specification-Aware Automated Testing and Validation of 5G O-RAN Components WiSec 2025, June 30-July 3, 2025, Arlington, V A, USA

    2023

  9. [16]

    Mathew Jacob, Erik Lindgren, Matei Zaharia, Michael Carbin, Omar Khattab, and Andrew Drozdov. 2024. Drowning in documents: consequences of scaling reranker inference. arXiv preprint arXiv:2411.11767

    2024 arXiv

  10. [17]

    Albert Q Jiang et al. 2023. Mistral 7b. arXiv preprint arXiv:2310.06825

    2023 arXiv

  11. [18]

    Syed Khandker, Michele Guerra, Evangelos Bitsikas, Roger Piqueras Jover, Aan- jhan Ranganathan, and Christina Pöpper. 2024. Astra-5g: automated over-the- air security testing and research architecture for 5g sa devices. In Proceedings of the 17th ACM Conference on Security and...

    2024

  12. [19]

    Aziz Kord, Jason B Coder, and Vu Le. 2024. Evolving open ran interoperability: a large-scale definition. In 2024 IEEE International Conference on Communications Workshops (ICC Workshops). IEEE, 2095–2100

    2024

  13. [20]

    Team Langchain. 2023. Langchain: building applications with llms through composability. https://github.com/langchain-ai/langchain. Accessed: January

    2023

  14. [21]

    Madhusanka Liyanage, An Braeken, Shahriar Shahabuddin, and Pasika Ranaweera

  15. [22]

    Farhad Mehran, Charles Turyagyenda, and Dritan Kaleshi. 2024. Experimental evaluation of multi-vendor 5g open rans: promises, challenges, and lessons learned. IEEE Access, 12, 152241–152261. doi:10.1109/ACCESS.2024.3476963

    2024

  16. [23]

    Ngo, Mao V

    Tuan V. Ngo, Mao V. Ngo, Binbin Chen, Gabriele Gemmi, Eduardo Baena, Michele Polese, Tommaso Melodia, William Chien, and Tony Quek. 2024. Con- sistent and repeatable testing of o-ran distributed unit (o-du) across continents. (2024). https://arxiv.org/abs/2410.04416 arXiv: 241...

    2024 arXiv

  17. [24]

    Rasoul Nikbakht, Mohamed Benzaghta, and Giovanni Geraci. 2024. Tspec-llm: an open-source dataset for llm understanding of 3gpp specifications. arXiv preprint arXiv:2406.01768

    2024 arXiv

  18. [25]

    O-RAN ALLIANCE Fronthaul Interfaces Group (WG 4). 2024. O-RAN Confor- mance Test Specification 11.0. Tech. rep. Version v11.00. Accessed: 2025-01-13. O-RAN ALLIANCE. https://specifications.o-ran.org/specifications

    2024

  19. [26]

    O-RAN ALLIANCE Open Interfaces Group (WG5). 2024. O-RAN Interoperabil- ity Test Specification (IOT) 11.0. Tech. rep. Version v11.00. Accessed: 2025-01-13. O-RAN ALLIANCE. https://specifications.o-ran.org/specifications

    2024

  20. [27]

    O-RAN ALLIANCE Security Work Group (WG11). 2024. O-RAN Security Test Specifications. Tech. rep. Version v08.00. Accessed: 2025-01-13. O-RAN AL- LIANCE. https://www.o-ran.org/specifications

    2024

  21. [28]

    O-RAN ALLIANCE Testing and Integration Focus Group (TIFG). 2024. O-RAN End-to-End Test Specification 6.0. Tech. rep. Version v06.00. Accessed: 2025- 01-13. O-RAN ALLIANCE. https://specifications.o-ran.org/specifications

    2024

  22. [29]

    Hetul Niteshbhai Patel, Azara Surti, Parth Goel, and Bankim Patel. 2024. A comparative analysis of large language models with retrieval-augmented gen- eration based question answering system. In 2024 8th International Conference on I-SMAC (IoT in Social, Mobile, Analytics and ...

    2024

  23. [30]

    Anupam Purwar et al. 2024. Evaluating the efficacy of open-source llms in enterprise-specific rag systems: a comparative study of performance and scala- bility. arXiv preprint arXiv:2406.11424

    2024 arXiv

  24. [31]

    Damien Sileo. 2024. Attention overflow: language model input blur during long-context missing items recommendation. arXiv preprint arXiv:2407.13481

    2024 arXiv

  25. [32]

    Ilja Siroš, Dave Singelée, and Bart Preneel. 2024. Covfuzz: coverage-based fuzzer for 4g5g protocols. (2024). https://arxiv.org/abs/2410.20958 arXiv: 2410.20958 [cs.CR]

    2024 arXiv

  26. [33]

    Weihang Su, Yichen Tang, Qingyao Ai, Junxi Yan, Changyue Wang, Hongning Wang, Ziyi Ye, Yujia Zhou, and Yiqun Liu. 2025. Parametric retrieval augmented generation. arXiv:2501.15915

    2025 arXiv

  27. [34]

    Software Radio Systems. 2024. Srsran: open-source lte/5g ran software suite. GitHub Repository. Accessed: 2024-12-09. https://github.com/srsran/srsRAN

    2024

  28. [35]

    Gemini Team et al. 2024. Gemini 1.5: unlocking multimodal understanding across millions of tokens of context. arXiv preprint arXiv:2403.05530

    2024 arXiv

  29. [36]

    Gemma Team et al. 2024. Gemma: open models based on gemini research and technology. arXiv preprint arXiv:2403.08295

    2024 arXiv

  30. [38]

    National Telecommunications and Information Administration (NTIA). 2023. Evaluating Modular, Interoperable, Multi-Vendor, Open RAN Solutions. Tech. rep. U.S. Department of Commerce. https://its.ntia.gov/publications/download /TM-23-568.pdf

    2023

  31. [39]

    Prabhu Kaliyammal Thiruvasagam, Chandrasekar T, Vinay Venkataram, Vivek Raja Ilangovan, Maneesha Perapalla, Rajisha Payyanur, Senthilnathan M D, Vishal Kumar, and Kokila J. 2023. Open ran: evolution of architecture, deploy- ment aspects, and future directions. (2023). https://...

    2023 arXiv

  32. [40]

    Nishith D Tripathi and Vijay K Shah. 2025. Fundamentals of O-RAN. John Wiley & Sons

    2025

  33. [41]

    Open ran test and integration

    2024. Open ran test and integration . Open RAN: The Definitive Guide , 172–190. doi:10.1002/9781119886020.ch11

    2024 doi

  34. [42]

    Shitao Xiao, Zheng Liu, Peitian Zhang, and Niklas Muennighoff. 2023. C-pack: packaged resources to advance general chinese embedding. (2023). arXiv: 2309 .07597 [cs.CL]

    2023

  35. [43]

    Tianchang Yang, Syed Md Mukit Rashid, Ali Ranjbar, Gang Tan, and Syed Rafiul Hussain. 2024. ORANalyst: systematic testing framework for open RAN implementations. In 33rd USENIX Security Symposium (USENIX Security 24) . USENIX Association, Philadelphia, PA, (Aug. 2024), 1921–19...

    2024

  36. [44]

    Girma M Yilma, Jose A Ayala-Romero, Andres Garcia-Saavedra, and Xavier Costa-Perez. 2025. Telecomrag: taming telecom standards with retrieval aug- mented generation and llms. ACM SIGCOMM Computer Communication Review, 54, 3, 18–23

    2025

  37. [45]

    Tianyi Zhang, Varsha Kishore, Felix Wu, Kilian Q Weinberger, and Yoav Artzi. 2019. Bertscore: evaluating text generation with bert. arXiv preprint arXiv:1904.09675

    2019 arXiv

  38. [46]

    UEContextReleaseRequest

    Hao Zhou et al. 2024. Large language model (llm) for telecommunications: a comprehensive survey on principles, key techniques, and opportunities. IEEE Communications Surveys & Tutorials . A Appendix A.1 Sample Log Index and 𝐿𝐿𝑎𝑀𝐴 We test a positive instance for the Initial UE ...

    2024

  39. [2023]

    Journal of Network and Computer Applications, 214, 103621

    Open ran security: challenges and opportunities. Journal of Network and Computer Applications, 214, 103621

  40. [2024]

    Bge m3-embedding: multi-lingual, multi-functionality, multi-granularity text embeddings through self-knowledge distillation.arXiv preprint arXiv:2402.03216

    arXiv

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.