Mobile Network-specialized Large Language Models for 6G: Architectures, Innovations, Challenges, and Future Trends

Abdelaali Chaoub; Muslim Elkotob

REVIEW 3 major objections 6 minor 3 cited by

Mobile Network-specialized Large Language Models for 6G: Architectures, Innovations, Challenges, and Future Trends

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

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

Pith's one-line read This paper argues that the LLM should become an intrinsic building block of the 6G mobile core, and it compares four integration architectures, showing that a standalone LLM network function can autonomously resolve a network-slicing…

desk verdict Useful four-architecture taxonomy of LLM-6G integration, but the abstract's 'prove effectiveness' oversells a qualitative walkthrough. read the letter →

arxiv 2502.04933 v1 pith:BPNE7T2Q submitted 2025-02-07 cs.NI

Abdelaali Chaoub , Muslim Elkotob This is my paper · ORCID

classification cs.NI

keywords 6Gnetworkslargelanguagemodelsnetworkfunctionservice-basedarchitectureautonomousmanagementslicingQoSpolicyNWDAF

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

The paper tries to establish that the Large Language Model should be treated not as an add-on but as an intrinsic building block of the mobile network operator's 6G infrastructure. It proposes four architectural designs for embedding an LLM in the network, from a standalone network function to a fully external application, and argues that the standalone design can autonomously detect, diagnose, and remedy a slicing conflict. The authors position this as the first in-depth comparison of architectural integration options, intended as practical guidance for MNOs. The load-bearing capability is the LNF's ability to turn network observations into correct 3GPP RESTful API calls, a capability that the paper acknowledges is not yet demonstrated.

What carries the argument

The central mechanism is the LLM-based Network Function (LNF), a control-plane NF in the 6G service-based architecture. Its processing pipeline uses a sliding window to feed recent data plus memory summaries into the prompt, CoT/ToT prompting to break solutions into instructions, an NL-to-REST Mapper that consults 3GPP technical specifications to generate API calls, an Executor that invokes them, a Parser for JSON payloads, and a REST-to-NL Mapper for human-readable answers. This modular chain carries the argument: if the mapping from natural-language instructions to correct REST calls is reliable, the autonomous resolution workflow in Section IV works as described.

What would settle it

Present the slicing-conflict scenario to the proposed LNF in a testbed where the generated REST API calls are validated against 3GPP specifications and the network's actual response. If the NL-to-REST Mapper produces malformed, unauthorized, or semantically wrong API calls beyond a small tolerance, or the NWDAF analytics fail to confirm the remedy, the autonomous workflow described in Section IV would not operate as claimed.

Watch

Extended reading notes

Core claim

The central claim is that the LLM, deployed as a standalone network function in the 6G control plane, can close the loop on anomaly resolution: it ingests multi-modal network data, detects unusual traffic patterns, uses chain-of-thought and tree-of-thought reasoning to produce a step-by-step plan, maps each step to 3GPP RESTful API calls, executes them through an Executor, and verifies the outcome by subscribing to NWDAF analytics. The paper contrasts this with three alternatives: embedding the LLM inside an existing NF, a hybrid near-real-time/non-real-time split, and an external application function. It argues that the standalone and hybrid designs inherit 6G's security-by-design properties, while the external option raises data sovereignty and latency concerns. In the illustrative scenario, the LNF detects a traffic surge in an immersive-communications slice, generates a Pareto-optimal QoS policy, enforces it through PCF, SMF, AMF, and UPF, and receives NWDAF analytics confirming the remedy.

Load-bearing premise

The paper assumes that a fine-tuned LLM, augmented with RAG and CoT/ToT prompting, can turn network observations into correct and safe 3GPP RESTful API calls, a capability that has not yet been demonstrated in a prototype.

Editorial extensions

If this is right

An MNO can start with the standalone LNF and migrate to the hybrid design by gradually upgrading an existing NF such as NWDAF to host the near-real-time LLM.
Slicing conflicts of the type described, where a traffic surge in one slice raises latency in another, can be resolved without waiting for human consultation because the LNF generates and enforces a Pareto-optimal QoS policy directly through existing 3GPP control-plane functions.
Security-by-design in 6G would extend to the LLM itself when it is an internal NF, reducing attack surfaces compared to an external application function.
Explainable AI and NOC approval checkpoints can keep a human in the loop, so full autonomy is not required for the LNF to be useful.

Reading between the lines

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

The real bottleneck is not the architecture but the correctness of the LLM's API generation; a benchmark that measures NL-to-REST accuracy against 3GPP specifications would settle whether the standalone LNF can operate without human oversight.
The same four-way architectural comparison could be applied to other generative-AI integration points in 6G, such as intent-based management or automated service negotiation, since the trade-offs of latency, coupling, security, and scalability are generic.
A testable extension is to compare the LNF's autonomous QoS policy against the Pareto-optimal allocation computed by a classical optimizer in the same slicing scenario; the paper describes the optimization but does not quantify its outcome.
The paper's assumption that the MNO's historical data is sufficient for fine-tuning may be the softest link; federated governance and knowledge distillation are proposed as mitigations but the data volume and quality requirements are not derived.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the letter

Here's the quick version: this is a solid position paper that earns a serious referee, but the abstract oversells it. The genuinely new content is the four-way comparative taxonomy of LLM integration into 6G (standalone NF, embedded, hybrid, external AF) plus the component-level breakdown of the standalone LNF and a plausible slicing-conflict walkthrough. The architectures are grounded in 3GPP SBA concepts and the trade-off table is useful. This is the kind of organizing scaffold that gives MNOs and standardization bodies a shared vocabulary. Prior work like Mobile-LLaMA is cited honestly as the starting point.

The paper's own conclusion admits a proof-of-concept is 'ongoing,' so the authors know the state of evidence. The problem is that the abstract says the scenario is used to 'prove the effectiveness' of the framework. That is too strong. The scenario is a qualitative walkthrough; it illustrates the intended call flows but does not measure anything. The load-bearing assumption is the NL-to-REST Mapper and Executor: the whole autonomous resolution depends on an LLM generating correct, safe 3GPP SBI calls without a demonstrated reliability mechanism. The paper mentions RestGPT but does not establish that the mapping is safe at operator-grade reliability. That is a real gap, and it should be flagged in review, but it is not a reason to desk-reject a taxonomy paper.

The citation pattern is fine. Self-citations to SON and INGR are contextual; the LLM-specific references are appropriate. No mathematical claims to check, no fitted parameters, no circularity.

Who is this for? An MNO architect deciding where to place LLM intelligence, a 3GPP contributor wanting a common framework, or a grad student looking for a research entry point. It will not give you measurements or a running system. If the authors reframe the contribution as a design taxonomy with an illustrative walkthrough, the paper's claims and evidence will match. I'd send it to peer review with that request.

Referee Report

3 major / 6 minor

Summary. This paper identifies itself as a first in-depth architectural analysis of integrating large language models (LLMs) into 6G mobile networks. It proposes four deployment options: a standalone LLM-based Network Function (LNF) within the 6G core control plane; a fully integrated LLM embedded inside an existing NF such as NWDAF; a hybrid near-real-time/non-real-time split; and an external LLM-based Application Function (LAF) communicating via NEF. For each option it discusses internal structure, interfaces, advantages, and drawbacks, summarized in Table I. The LNF design in Section III-A includes a data aggregation pipeline, sliding-window summarization, RAG-enhanced prompting, CoT/ToT-based instruction generation, and NL-to-REST mapping to 3GPP SBI calls. Section IV presents a slicing-conflict scenario in which the LNF detects a traffic surge in an immersive-communications slice, proposes a QoS policy change, interacts with PCF/SMF/AMF/UPF via standard procedures, and verifies the outcome via NWDAF analytics. The paper's stated second contribution is that this scenario 'prove[s] the effectiveness' of the framework. The final section surveys challenges and future trends.

Significance. If the architectural taxonomy is accepted, the paper offers a practically useful framing for MNOs: the four architectures map onto concrete 3GPP concepts (NRF, NEF, NWDAF, SBI), and Table I condenses the trade-offs in a readable way. The slicing scenario is also valuable as a concrete end-to-end walkthrough, showing how an LLM-driven loop could attach to standard QoS enforcement procedures. The paper does not ship machine-checked proofs or a prototype; its strength is as a position/architecture paper. The central limitation is that the 'effectiveness' claim for autonomous anomaly handling goes beyond the evidence: the key NL-to-REST mapping step is assumed reliable rather than demonstrated, and the QoS optimization step is described without a formal model. With those claims recalibrated, the paper could be a useful guide for operators and a foundation for future prototype work.

major comments (3)

[Abstract and Section IV] The abstract states that the slicing-conflict scenario is used to 'prove the effectiveness' of the proposed framework, and Section IV concludes that the LNF architecture 'can autonomously and efficiently handle such slicing conflicts.' However, the scenario is entirely qualitative; no numerical results, simulation, or prototype are provided, and Section VI explicitly states that a proof-of-concept is 'ongoing.' The load-bearing capability in this workflow—the NL-to-REST Mapper and Executor of Section III-A (Fig. 2)—is assumed to translate CoT/ToT instructions into valid 3GPP RESTful API calls and to execute them safely, but the paper offers no correctness mechanism, validation step, or fallback (e.g., checking against 3GPP TS schemas, sandboxed execution, or mandatory human approval beyond the optional NOC step). A single malformed payload could disrupt live PDU sessions. The claims should be reframed as an illustrative proposal, and the reliability/open-problem status of the API mapping should be stated explicitly.
[Section IV] The narrative asserts that the LNF 'can find the optimal and precise QoS policy' by performing 'multi-objective optimization among the conflicting slices' and selecting among 'Pareto-optimal solutions,' yet no optimization formulation, objective functions, decision variables, or input metrics are defined anywhere in the paper. The actual policy change described (reducing slice I's bandwidth from 50% to 30%) is identical to the conventional manual solution described earlier, so the reader cannot see what the LNF's optimization contributes. This step is central to the claim of autonomous decision-making; it should be formalized at least at a conceptual level (e.g., a small mathematical example) or explicitly labeled as a future research item.
[Section III-A] The sliding window parameters W and T are introduced as 'adaptively chosen' to balance context, latency, and token limits, but no adaptation rule or even a heuristic is provided. Since the entire LNF pipeline's input construction depends on these parameters, and since the paper does not report any sensitivity analysis or example selection, the architecture as described cannot be assessed for its ability to meet the latency and accuracy requirements that the Section IV scenario assumes. Please either specify a concrete adaptation mechanism or explicitly scope W and T as tunable parameters for the future proof-of-concept.

minor comments (6)

[Fig. 2] The flow from 'Sliding window Wt' and 'Memory Summaries' into 'Prompt engineering' is not visually annotated; consider adding a labeled aggregation step to clarify how context is assembled within the token limit.
[Throughout] There are several typos and spacing errors, e.g., 'Copyr ight' on the first page, 'V odafone' in the author affiliation, and 'Y et another beneﬁt' in Section III-C.
[Section I] The claim of being 'the first attempt' would be more convincing if the authors briefly positioned the four architectures against the closest existing proposals (e.g., the LLM-augmented NWDAF of [4] and the INGR roadmap [13]) in a short related-work paragraph.
[Fig. 3] The box 'Approval required (Optional)' and step 4 'Approval granted' are ambiguous; the text says the policy change is 'subject to MNO's approval.' Please clarify whether the scenario assumes mandatory or optional human approval.
[Table I] Consider adding columns for typical deployment latency and data-privacy exposure to make the trade-offs more directly comparable across the four options.
[References] Reference [14] is an arXiv preprint; if a peer-reviewed version of RestGPT exists, cite that instead, and also note in the text that RestGPT has not been evaluated on 3GPP-specific APIs.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper is a qualitative architecture survey with an illustrative scenario; no quantitative prediction or fitted parameter reduces to its inputs.

full rationale

This paper is a qualitative architecture survey. It makes no quantitative predictions, fits no parameters, and derives no closed-form results. The four integration architectures are presented as a taxonomy with trade-offs; the slicing-conflict scenario is explicitly illustrative, and the conclusion states that a proof-of-concept is ongoing. Self-citations [1] and [13] provide background context on self-organizing networks and the INGR roadmap but are not used to derive the paper's central architectural claim. The assumed reliability of the NL-to-REST Mapper is an unsupported premise rather than a circular one: no equation, fitted value, or definition equates the conclusion to the input. Hence no step reduces to its own inputs by construction.

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

The paper introduces two new architectural entities (LNF and LAF) and a hybrid Near-RT/Non-RT LLM split, all without implementation. The main free parameters are the sliding-window size and period, which are left unspecified. The central assumptions are about LLM reliability for API generation and policy decision-making, both untested.

free parameters (1)

Sliding window size W and period T = not specified
Section III-A describes W and T as adaptive parameters that balance context and token limits, but no method for choosing them is given. They are design choices rather than fitted values.

assumptions (3)

domain assumption A fine-tuned and RAG-powered LLM can produce correct, safe, and complete 3GPP REST API calls from natural-language instructions.
This is the load-bearing premise of the LNF architecture in Section III-A and the autonomous resolution workflow in Section IV. The paper cites RestGPT as evidence that LLM-to-REST integration is feasible, but does not demonstrate reliability for telecom APIs.
domain assumption LLM-generated QoS policy changes can be mapped onto the existing 3GPP policy and session management workflow without breaking SLA guarantees.
Section IV assumes the LNF can identify a Pareto-optimal bandwidth reallocation and communicate it through PCF, SMF, AMF, and UPF, following the same workflow as the conventional case, with only optional human approval.
standard math The existing 3GPP service-based architecture and NWDAF analytics can provide the data and enforcement mechanisms the LLM needs.
The paper relies on the standard 3GPP architecture (SBA, NWDAF, PCF, SMF, AMF, UPF) as background infrastructure without questioning its assumptions.

invented entities (2)

LNF, LLM-based Network Function
purpose: A standalone LLM deployed as a control-plane network function in the 6G core, with middleware for NL-to-REST mapping and execution of generated instructions.
The LNF is a proposed architectural entity with no implementation. The paper mentions an ongoing proof-of-concept but provides no falsifiable handle such as a benchmark or measurement.
LAF, LLM-based Application Function
purpose: An LLM deployed outside the MNO infrastructure as a 3GPP Application Function, communicating through NEF or a trusted data network.
The LAF is a proposed placement option based on the standard AF concept. No implementation or external validation is provided.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Mobile Network-specialized Large Language Models for 6G: Architectures, Innovations, Challenges, and Future Trends." pith.science (2026). https://pith.science/paper/BPNE7T2Q

@misc{pith2026250204933,
  author       = {Pith},
  title        = {Pith review of: Mobile Network-specialized Large Language Models for 6G: Architectures, Innovations, Challenges, and Future Trends},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BPNE7T2Q}},
  note         = {Machine review of arXiv:2502.04933}
}

read the original abstract

Conventional 5G network management mechanisms, that operate in isolated silos across different network segments, will experience significant limitations in handling the unprecedented hyper-complexity and massive scale of the sixth generation (6G). Holistic intelligence and end-to-end automation are, thus, positioned as key enablers of forthcoming 6G networks. The Large Language Model (LLM) technology, a major breakthrough in the Generative Artificial Intelligence (AI) field, enjoys robust human-like language processing, advanced contextual reasoning and multi-modal capabilities. These features foster a holistic understanding of network behavior and an autonomous decision-making. This paper investigates four possible architectural designs for integrated LLM and 6G networks, detailing the inherent technical intricacies, the merits and the limitations of each design. As an internal functional building block of future 6G networks, the LLM will natively benefit from their improved design-driven security policies from the early design and specification stages. An illustrative scenario of slicing conflicts is used to prove the effectiveness of our architectural framework in autonomously dealing with complicated network anomalies. We finally conclude the paper with an overview of the key challenges and the relevant research trends for enabling Mobile Networkspecialized LLMs. This study is intended to provide Mobile Network Operators (MNOs) with a comprehensive guidance in their paths towards embracing the LLM technology.

Figures

Figures reproduced from arXiv: 2502.04933 by the authors.

**Figure 2.** A breakdown of the LNF. NF (e.g. LLM-augmented NWDAF in [4]) or distributed across multiple NFs. A major advantage of LLM-powered NFs is improved interaction between the NOC engineers and the 6G ecosystem, using conversational queries instead of complex commandline interfaces (CLIs). Moreover, embedding the LLM into an NF eliminates the need for intermediary communication interfaces, simplifying the overall system … view at source ↗

**Figure 3.** Workflow of LNF autonomous operation for anomaly dete [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Key challenges for LLM-powered 6G. LLM results. Moreover, MNOs tend to build their private LLMs using open-source solutions (e.g. LLaMA, DeepSeek) instead of commercial ones to avoid exposing sensitive data to thirdparty services [4]. MNO acceptance of LLM-generated i…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

WiLLM: an Open Framework for LLM Services over Wireless Systems
cs.NI 2025-06 conditional novelty 6.0 of 10

WiLLM is a new open-source platform plus dataset for running and measuring LLM services over live wireless networks, with evidence that LLM traffic is bidirectional, bursty, and coupled to network slicing.
OSI Stack Redesign for Quantum Networks: Requirements, Technologies, Challenges, and Future Directions
quant-ph 2025-06 conditional novelty 4.0 of 10

The paper proposes a Quantum-Converged OSI stack with nine layers, adding Layer 0 (Quantum Substrate) and Layer 8 (Cognitive Intent Plane) to the classical OSI model for quantum networks.
Exploring the Role of Large Language Models in Cybersecurity: A Systematic Survey
cs.CR 2025-04 conditional novelty 4.0 of 10

A survey that organizes LLM-based cybersecurity defense by attack-phase, threat-intelligence, and deployment categories, and identifies post-intrusion defense as the main understudied area.

Reference graph

Works this paper leans on

15 extracted references · 14 canonical work pages · cited by 3 Pith papers

[1]

Hybrid S elf- Organizing Networks: Evolution, Standardization Trends, and a 6G Ar- chitecture Vision,

A. Chaoub, A. M¨ ammel¨ a, P . Martinez-Julia, R. Chaparadza, M. Elkotob, L. Ong, D. Krishnaswamy, A. Anttonen, and A. Dutta, “Hybrid S elf- Organizing Networks: Evolution, Standardization Trends, and a 6G Ar- chitecture Vision,” IEEE Communications Standards Magazine , vol. 7, no. 1, pp. 14–22, 2023

work page 2023
[2]

Attention is all you need,

A. V aswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones , A. N. Gomez, L. Kaiser, and I. Polosukhin, “Attention is all you need,” in Proceedings of the 31st International Conference on Neural Information Processing Systems, 2017, p. 6000–6010

work page 2017
[3]

Large Language Models for Telecom: Forthcoming Impact on t he Industry,

A. Maatouk, N. Piovesan, F. Ayed, A. De Domenico, and M. De bbah, “Large Language Models for Telecom: Forthcoming Impact on t he Industry,” IEEE Communications Magazine , vol. 63, no. 1, pp. 62–68, 2025

work page 2025
[4]

Mobile-LLaMA: Instr uction Fine-Tuning Open-Source LLM for Network Analysis in 5G Netw orks,

K. B. Kan, H. Mun, G. Cao, and Y . Lee, “Mobile-LLaMA: Instr uction Fine-Tuning Open-Source LLM for Network Analysis in 5G Netw orks,” IEEE Network , vol. 38, no. 5, pp. 76–83, 2024

work page 2024
[5]

NetConfEval: Can LLMs Facilitate Network Conﬁg ura- tion?

C. Wang, M. Scazzariello, A. Farshin, S. Ferlin, D. Kosti ´ c, and M. Chiesa, “NetConfEval: Can LLMs Facilitate Network Conﬁg ura- tion?” Proc. ACM Netw. , vol. 2, no. CoNEXT2, 2024

work page 2024
[6]

Tele-Knowledge Pre-training for Fault Analys is,

Z. Chen, W. Zhang, Y . Huang, M. Chen, Y . Geng, H. Y u, Z. Bi, Y. Zhang, Z. Y ao, W. Song, X. Wu, Y . Y ang, M. Chen, Z. Lian, Y . Li, L. Cheng , and H. Chen, “Tele-Knowledge Pre-training for Fault Analys is,” in 2023 IEEE 39th International Conference on Data Engineering (IC DE), 2023, pp. 3453–3466

work page 2023
[7]

5G INSTRUCT Forge: An Advanced Data Engineerin g Pipeline for Making LLMs Learn 5G,

A. I. A. Said, A. Mekrache, K. Boutiba, K. Ramantas, A. Kse ntini, and M. Rahmani, “5G INSTRUCT Forge: An Advanced Data Engineerin g Pipeline for Making LLMs Learn 5G,” IEEE Transactions on Cognitive Communications and Networking , pp. 1–1, 2024

work page 2024
[8]

Large Generative AI Models for Telecom: The Next Big Thing?

L. Bariah, Q. Zhao, H. Zou, Y . Tian, F. Bader, and M. Debbah , “Large Generative AI Models for Telecom: The Next Big Thing? ” IEEE Communications Magazine, vol. 62, no. 11, pp. 84–90, 2024

work page 2024

Show all 15 references

[9]

Large Language Model (LLM) for Telecommunications: A Comprehens ive Survey on Principles, Key Techniques, and Opportunities,

H. Zhou, C. Hu, Y . Y uan, Y . Cui, Y . Jin, C. Chen, H. Wu, D. Y ua n, L. Jiang, D. Wu, X. Liu, C. Zhang, X. Wang, and J. Liu, “Large Language Model (LLM) for Telecommunications: A Comprehens ive Survey on Principles, Key Techniques, and Opportunities,” IEEE Com- munications ...

2024
[10]

Resilienc e-by-Design in 6G Networks: Literature Review and Novel Enabling Concep ts,

L. Khaloopour, Y . Su, F. Raskob, T. Meuser, R. Bless, L. J anzen, K. Abedi, M. Andjelkovic, H. Chaari, P . Chakraborty, M. Kreu tzer, M. Hollick, T. Strufe, N. Franchi, and V . Jamali, “Resilienc e-by-Design in 6G Networks: Literature Review and Novel Enabling Concep ts,” IEE...

2024
[11]

Understanding Telecom Language Through Large Language Mo dels,

L. Bariah, H. Zou, Q. Zhao, B. Mouhouche, F. Bader, and M. Debbah, “Understanding Telecom Language Through Large Language Mo dels,” in GLOBECOM 2023 - 2023 IEEE Global Communications Conference , 2023, pp. 6542–6547

2023
[12]

Observations on LLMs for telecom dom ain: capabilities and limitations,

S. Soman and R. HG, “Observations on LLMs for telecom dom ain: capabilities and limitations,” in Proceedings of the Third International Conference on AI-ML Systems , 2023, pp. 1–5

2023
[13]

INGR Road map System Optimization Chapter,

R. Chaparadza, A. Chaoub, B. Chng, N. Davis, A. Dutta, M. Elkotob, D. Krishnaswamy, K. Mahdi, A. M¨ ammel¨ a, P . Martinez-Julia , N. K. Narang, L. Ong, M. Patwary, M. Simsek, J. V oigt, C. Polk, K. Mc - Donnell, J. Niem ¨ oller, D. Milham, and J. Cadman, “INGR Road map System...

2023
[14]

RestGPT: Connectin g Large Language Models with Real-World RESTful APIs,

Y . Song, W. Xiong, D. Zhu, W. Wu, H. Qian, M. Song, H. Huang , C. Li, K. Wang, R. Y ao, Y . Tian, and S. Li, “RestGPT: Connectin g Large Language Models with Real-World RESTful APIs,” arXiv preprint arXiv:2306.06624, 2023. 9

2023 arXiv
[15]

A Survey on Sym bolic Knowledge Distillation of Large Language Models,

K. Acharya, A. V elasquez, and H. H. Song, “A Survey on Sym bolic Knowledge Distillation of Large Language Models,” IEEE Transactions on Artiﬁcial Intelligence , vol. 5, no. 12, pp. 5928–5948, 2024. BIOGRAPHY Abdelaali Chaoub [SM] has been an Associate Professor in Telecommuni...

2024

Pith tools

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

[1] [1]

Hybrid S elf- Organizing Networks: Evolution, Standardization Trends, and a 6G Ar- chitecture Vision,

A. Chaoub, A. M¨ ammel¨ a, P . Martinez-Julia, R. Chaparadza, M. Elkotob, L. Ong, D. Krishnaswamy, A. Anttonen, and A. Dutta, “Hybrid S elf- Organizing Networks: Evolution, Standardization Trends, and a 6G Ar- chitecture Vision,” IEEE Communications Standards Magazine , vol. 7, no. 1, pp. 14–22, 2023

work page 2023

[2] [2]

Attention is all you need,

A. V aswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones , A. N. Gomez, L. Kaiser, and I. Polosukhin, “Attention is all you need,” in Proceedings of the 31st International Conference on Neural Information Processing Systems, 2017, p. 6000–6010

work page 2017

[3] [3]

Large Language Models for Telecom: Forthcoming Impact on t he Industry,

A. Maatouk, N. Piovesan, F. Ayed, A. De Domenico, and M. De bbah, “Large Language Models for Telecom: Forthcoming Impact on t he Industry,” IEEE Communications Magazine , vol. 63, no. 1, pp. 62–68, 2025

work page 2025

[4] [4]

Mobile-LLaMA: Instr uction Fine-Tuning Open-Source LLM for Network Analysis in 5G Netw orks,

K. B. Kan, H. Mun, G. Cao, and Y . Lee, “Mobile-LLaMA: Instr uction Fine-Tuning Open-Source LLM for Network Analysis in 5G Netw orks,” IEEE Network , vol. 38, no. 5, pp. 76–83, 2024

work page 2024

[5] [5]

NetConfEval: Can LLMs Facilitate Network Conﬁg ura- tion?

C. Wang, M. Scazzariello, A. Farshin, S. Ferlin, D. Kosti ´ c, and M. Chiesa, “NetConfEval: Can LLMs Facilitate Network Conﬁg ura- tion?” Proc. ACM Netw. , vol. 2, no. CoNEXT2, 2024

work page 2024

[6] [6]

Tele-Knowledge Pre-training for Fault Analys is,

Z. Chen, W. Zhang, Y . Huang, M. Chen, Y . Geng, H. Y u, Z. Bi, Y. Zhang, Z. Y ao, W. Song, X. Wu, Y . Y ang, M. Chen, Z. Lian, Y . Li, L. Cheng , and H. Chen, “Tele-Knowledge Pre-training for Fault Analys is,” in 2023 IEEE 39th International Conference on Data Engineering (IC DE), 2023, pp. 3453–3466

work page 2023

[7] [7]

5G INSTRUCT Forge: An Advanced Data Engineerin g Pipeline for Making LLMs Learn 5G,

A. I. A. Said, A. Mekrache, K. Boutiba, K. Ramantas, A. Kse ntini, and M. Rahmani, “5G INSTRUCT Forge: An Advanced Data Engineerin g Pipeline for Making LLMs Learn 5G,” IEEE Transactions on Cognitive Communications and Networking , pp. 1–1, 2024

work page 2024

[8] [8]

Large Generative AI Models for Telecom: The Next Big Thing?

L. Bariah, Q. Zhao, H. Zou, Y . Tian, F. Bader, and M. Debbah , “Large Generative AI Models for Telecom: The Next Big Thing? ” IEEE Communications Magazine, vol. 62, no. 11, pp. 84–90, 2024

work page 2024