<figure><img src="image_1.png" /></figure>

HAL
open science

# WiFiQnA: a WiFi Dataset for Large Language Models

Anouar Zouhri, Lynda Zitoune, Iyad Lahsen-Cherif

► To cite this version:

Anouar Zouhri, Lynda Zitoune, Iyad Lahsen-Cherif. WiFiQnA: a WiFi Dataset for Large Language Models. 2025. [hal-05146992](https://hal.science/hal-05146992v1)

HAL Id: hal-05146992

https://hal.science/hal-05146992v1

Preprint submitted on 7 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

Public Domain
# WiFiQnA: a WiFi Dataset for Large Language Models

Anouar Zouhri*, Lynda Zitoune†, Iyad Lahsen-Cherif‡

*INPT, CS department, Rabat, Morocco. Email: zouhri.anouar@master.inpt.ac.ma

†Université Paris-Saclay, CNRS, CentraleSupélec, Laboratoire des Signaux et Systèmes

3, rue Joliot Curie, 91190 Gif-sur-Yvette, France. Email: lynda.zitoune@12s.centralesupelec.fr

‡INPT, CS department, Rabat, Morocco. Email: lahsencherif@inpt.ac.ma

**Abstract**—The telecommunications field is a vast domain that includes several subfields, each offering numerous functionalities to its users. In our case, our research field is Wi-Fi, a technology that has the ability to connect multiple devices. This domain has a lot of potential, and there are still many problems that haven't been explored yet. With the rise of artificial intelligence, this technology seeks to solve existing problems and create innovative solutions. We have chosen to focus on LLMs (Large Language Models), which are becoming increasingly popular. Every week, new models are released, challenging the existing ones. These models have the capability to understand any problem and provide solutions for it. However, they are considered raw materials that need to be highly adapted to specific tasks in order to be more precise, deliver more relevant information, and follow a profile that makes the answers evolve from general to specific. To address this, the technique of fine-tuning has emerged. It focuses on adapting LLM models to specific tasks. However, to achieve this, we need to consider the "missing link" — the dataset. In our article, we created a specialized dataset for the Wi-Fi domain and adapted it to the fine-tuning technique for LLMs. Our dataset is generated using different LLM models, with three approaches applied and two verification and filtering steps. This resulted in a Wi-Fi dataset for LLMs, formatted as questions with options and answers, along with explanations. These questions are divided into two approaches: direct comprehension questions and configuration questions, adding a touch of generality to our dataset.

**Index Terms**—Telecommunications, Dataset, Wi-Fi, LLMs, fine-tuning.

## I. INTRODUCTION

Large Language Models (LLMs), a new trend in Natural Language Processing (NLP), address the challenges of well-known deep learning models, like RNNs and CNNs, and the limitations of their capacity to process large sentences. LLMs can understand and generate human language and handle complex tasks such as translation, summarization, and interactive conversations [1], thanks to advanced architectures, like Transformers [2]. Additionally, LLMs go beyond the NLP and move to new multi-modal versions, representing an important advanced step in prediction [3], by processing data from various modalities, including audio, images, videos, 3D maps, and graphs. Consequently, LLMs are increasingly being

used in many areas, giving space for new ideas and creative solutions, including the telecommunications domain [4].

In the telecommunication field, LLMs can solve issues related to network resources management by using a self-improvement method with a reward function to understand the user feedback [5]. The main goal is to guide the model in providing answers that match human preferences. The system takes the user's opinion about the service and adapts its actions to fix network issues and make the user satisfied [6]. LLM models can optimize power allocation, assist the spectrum detection, and understand protocols using techniques such as black box optimizer [7, 8]. Furthermore, they can generate heuristic algorithms to optimize resource allocation [9].

LLMs are expected to provide AI-native services in 6G networks, more adequate for complex telecom-related issues, and several efforts have been made in this direction [4]. However, the telecoms field is vast, encompassing various wireless communication technologies suitable for both large and small deployments. While the underlying challenges related to complexity, optimization, planning, and debugging are similar across these communication models, the solutions remain inherently dependent on their intrinsic features, particularly WiFi, 5G, and the forthcoming 6G. At the same time, standardization bodies continue to advocate the convergence between cellular networks (5G, 6G) and wireless LANs, WiFi in particular, by specifying interfaces that serve as gateways between the two worlds [10]. Despite this, there has been limited research focused on the utilization of LLMs in WiFi networks, which are equipped with advanced capabilities that bring them closer to cellular networks, such as MU-MIMO, Multi-user operation, and Multi-band operation. Therefore, it is crucial that WiFi networks should be dotted with LLM capabilities. As the complexity of WiFi networks increases to accommodate high device densities across large areas, there is a growing need for the development of large language models (LLMs) tailored for WiFi networks, similar to the enthusiasm currently seen for 6G networks. Without such advancements, these gateways become bottlenecks, hindering the technological convergence between the two worlds.
To effectively tackle these issues, it is crucial first to identify a suitable dataset specifically designed for Wi-Fi networks [11]. This dataset should be compatible with LLMs, meaning it must be understandable, easy to split, and tokenize. Furthermore, it should contain precise technical information as well as general data for its universality.

Regarding the related work, six open-source datasets are available for free utilization. TeleData [12] contains 2.5 billion tokens of telecom resources and paragraphs. TeleEval [12] generated from the previous dataset using a Mixtral-8x7B Instruct model, is presented in question-answer format. TspecLLM [13], a dataset generated based on documentation files from 3GPP standards. For 5G networks, SpecG 5G [14], is presented in two formats: the 5Sum contains summarizations of 5G technical texts, and the 5SC is a classification of these texts based on a security context. Last but not least, TeleQnA [15] contains 9999 multiple-choice questions (MCQs) divided into five categories and includes questions based on technical resources extracted from scientific articles on telecommunication. After analyzing and filtering all these datasets, we found that only TeleQnA contains data concerning WiFi networks, with only 531 questions in the MCQ format. This number is not sufficient to train new targeted LLM models, and motivates us to generate a new Wi-Fi dataset called WiFiQnA.

In this paper, we present the steps we followed to create the WiFiQnA dataset. The first step involved researching existing datasets in the telecom field already used in the literature, along with other resources like articles, books, and blogs focused on the WiFi standard and amendments. The second step focused on creating our dataset with two question formats. The first format, multiple-choice questions (MCQs), includes questions about general knowledge with direct response options. This format is targeted to answer general questions about WiFi. The second format, which is also of a multiple-choice question (MCQs) type, is a more specialized one to answer either configuration questions or networking issues. In this case, the options are proposed in the form of sequential steps to follow in solving a typical issue or in configuring some operation modes. We set up an architecture to generate our dataset by combining three approaches that utilize three LLM models. The first approach generates MCQs based on an existing dataset after introducing a filtering phase. The second approach utilizes external sources (Wi-Fi-oriented), while the third approach relies on the knowledge embedded in an existing LLM to create MCQs. For each approach, we define two prompts for the generation process, one for each question format, and these prompts are updated as needed. The final step involves validating the generated questions. The validation phase itself involves two steps. First, filtering out duplicate questions and testing for similarity, and then validating the answers and filtering out incorrect or misleading questions. To achieve this, we utilize four LLM models to ensure the accuracy of the questions and answers.

In the following, we present pertinent open-source telecom datasets in section II, discussing their usage, characteristics, and the steps for their setup. Section III details the char-

acteristics of the WiFiQnA Dataset, with a focus on the MCQ format. We provide a comprehensive steps involved in generating WiFiQnA in section IV, along with the general architecture that supports our proposal, which is based on three different approaches. In section V, we illustrate a practical use case related to the selected models for dataset generation and address filtering considerations. Section VI offers a thorough explanation of the results we obtained during the application process, highlighting the features and characteristics of the resulting dataset. Finally, in section VII, we summarize our findings and propose ideas for future work based on the WiFiQnA dataset.

## II. RELATED WORK

Since 2023, several datasets have been proposed in the literature to speed up the development of LLMs for telecoms. Here, we focus on existing open-source datasets and highlight the steps followed for designing them and their corresponding resources. The first dataset, TeleData [12], is a large collection of documents used for telecommunications research. It is derived from four main sources: scientific papers from arXiv, 3GPP standards, Wikipedia articles, and websites related to telecommunications taken from Common Crawl dumps. Using keywords, this dataset is filtered using large language models (LLMs) to find telecommunications-relevant materials and topics. Afterwards, the data is cleaned, formatted, and standardized. TeleData is about 2.5 billion tokens, designed to help train large language models for telecommunications tasks. It has four parts: the *ID*, a unique identifier for each data sample; the *Category*, which tells what type of sample it is; the *Content* includes the full text of the sample; and the *Metadata*, extra information about the sample, stored as a JSON object [12]. TeleEval [12], a dataset generated from TeleData, has 750,000 question-and-answer pairs about general telecommunications knowledge and standards. This dataset was created using an LLM-based framework by giving paragraphs of TeleData to the Mixtral-8x7B-Instruct model [16], to generate the questions and answers. The dataset has three parts: the *Statement* (the question), the *Answer*, and the *ID*, to show which part of TeleData was used to create the question and answer. The SPEC5G dataset [14], is targeted to study 5G network protocol specifications. It has 3,547,587 sentences and 134 million words, taken from 13,094 documents on cellular networks and 13 websites. This dataset is split into two sub-datasets: 5GSum and 5GSC. 5GSum for summarizing tasks, contains sentences from the 5G specifications with a summary of the technical information. This means that for each sentence, there is a detailed text that covers all the technical aspects described in that sentence. 5GSC is designed for the security classification. It has three types of sentences: *Non-Security* for sentences not related to security, *Security* for sentences about security, and *Undefined* for unclear sentences or only partially related to security. The TSpec-LLM dataset [13] is derived from Release 8 to Release 19 of 3GPP standards converted into Markdown and DOCX formats. It contains 30,137 documents and 535 million words. TSpec-
LLM keeps all the pages, unlike other datasets like SPEC5G, which remove some information like tables and figures. It also changes math formulas into LaTeX to make them easy to read and analyze. This dataset is useful for telecommunications research and machine learning applications, such as using it in the context of RAG research [13]. The ORAN-Bench-13K is designed to evaluate the performance of LLMs in Open Radio Access Networks (O-RAN). It includes 13,952 MCQs derived from 116 O-RAN specification documents, categorized into three difficulty levels: easy, intermediate, and difficult. The data structure includes a unique identifier for each question, the difficulty level, the question text, and a list of answer choices (typically four), and the correct answer [17]. The TeleQNA dataset is a comprehensive dataset designed to assess LLM knowledge in telecommunications [15]. It contains 9,999 MCQs organized into five categories: Lexicon covering general telecoms terminology; Research Overview providing broad insights into telecoms research; Research Publications, focusing on in-depth inquiries from conference proceedings and journal transactions; Standards summarizing telecoms standards from 3GPP and IEEE; and Standards Specifications, detailing the technical specifications of telecoms systems. TeleQNA is the only dataset that involves the IEEE standards and specifications, with its last two categories being particularly relevant to our work, as they contain detailed information on WiFi networks. All these datasets are classified in the table I, depending on the targeted tasks used and the training data size.

<table><caption>TABLE I: Summary of Telecom Datasets</caption><thead><tr><td>Dataset</td><td>Task</td><td>Size</td></tr></thead><tbody><tr><td>TeleData</td><td>Pre-training NLP models for telecom</td><td>2.5B tokens</td></tr><tr><td>TeleEval</td><td>QA generation and evaluation in telecom</td><td>750K QA pairs</td></tr><tr><td>SPEC5G</td><td>Analysis of 5G protocol specifications</td><td>3.5M sentences, 134M words</td></tr><tr><td>5GSum</td><td>Summarization of 5G technical texts</td><td>713 long articles</td></tr><tr><td>5GSC</td><td>Classification of 5G texts into security categories</td><td>2,401 sentences</td></tr><tr><td>TSpec-LLM</td><td>Processing of 3GPP documentation for NLP</td><td>535 million words</td></tr><tr><td>ORAN-Bench-13K</td><td>Benchmarking LLMs on ORAN</td><td>13.9K MCQs</td></tr><tr><td>TeleQNA</td><td>Evaluation of LLM knowledge in telecom</td><td>10K MCQs</td></tr></tbody></table>

After analyzing TeleQNA, we identified only 543 WiFi-related questions, which is relatively small for an LLM dataset. The datasets, like SPEC5G and ORAN-Bench-13K, it is impossible to classify their statements as sentences related to WiFi, so we can conclude that they don't contain questions specific to WiFi. TeleData contains raw information in the form of paragraphs and needs to be processed as done in TeleEval. However, TeleEval still remains general, as it only contains questions and their answers without explanation or demonstration of how the correct answer was chosen. Another point that remains unexplored within the earlier datasets is the

resolution of practical issues and the use cases for configurations. There is no dataset that contributes or creates questions or statements that include configuration or resolution steps to a practical use case or an issue. Based on these observations, we focused in this work to create a more complete and specific dataset for WiFi networks, covering almost all versions from WiFi 1 to WiFi 6, and going further into configuration questions.

### III. WIFIQNA DATASET FORMAT

As derived from the TeleQNA dataset, WiFiQNA naturally contains multiple-choice questions, a well-suited and well-structured format for LLMs of the major dataset cited in the table I. It is also useful for our future considerations and purposes. Each QnA is composed by the question, the options, and the associated explanations.

**The Question** is represented in two formats: 1) direct question to address standard information and general knowledge about IEEE 802.11 and WiFi. 2) Troubleshooting or configuration questions reflecting real-world situations. With such types of questions, more information needs to be added to the dataset regarding device configuration, network setup, as well as fault, troubleshooting, and configuration issues.

**The Options** contain one correct answer and three false options. The three incorrect answers add more information and more variation to the dataset. As for the other MCQs-based datasets, we fix the number of choices to four, to strike a good balance between difficulty and feasibility. Four answers provide enough choices to test knowledge without complicating decision-making. In other words, adding extra options may make the MCQs more confusing. The format of the options is divided into two. One is direct, and it contains a sentence that directly answers the question. This is usually the most common format for MCQs, box 1 illustrates this type of option. The other one presents options in the form of steps to follow in order to complete the configuration requested or to solve the problem given in the question, box 2 illustrates this type of options.

**The answer** contains the correct choice among the four proposed options. It includes the word *option* and the number indicating the *ID* of the correct option, followed by the answer phrase describing the selected option. Sometimes it also contains the paragraph of the correct option, meaning the answer contains the indication of the chosen option as well as its context.

Finally, **the explanation** part contains a detailed and technical explanation to answer the question and explain why the correct answer is chosen among the options. Furthermore, it provides additional information to add insights to the dataset, it contains important and detailed information to prove that the chosen option is correct. Some examples of such MCQ are given in the section VI to highlight these new formats.
## Box 1: Direct Question format

**Question:** The question text

- Option 1: Answer A

- Option 2: Answer B

- Option 3: Answer C

- Option 4: Answer D

**Answer:** Option 1: Option A

**Explanation:** Detailed explanation of why the correct answer is correct.

## Box 2: Configuration Question format

**Question:** The question text

- Option 1:

- Step 1: ... - Step 2: ... - Step 3: ... - Step 4: ...

- Option 2:

- Step 1: ... - Step 2: ... - Step 3: ...

- Option 3:

- Step 1: ... - Step 2: ... - Step 3: ...

- Option 4:

- Step 1: ... - Step 2: ... - Step 3: ... - Step 4: ... - Step 5: ...

**Answer:** Option X

**Explanation:** Detailed technical explanation of why this option is the best.

# IV. DATASET GENERATION

Our main objective is to create a dataset on WiFi networks that encompasses the most important aspects related to these technologies' specifications. This dataset will include a significant number of related questions. We aim to treat all WiFi versions [11] equally, without favoring any particular version, while taking into account the IEEE 802.11 protocol stack [18]. This balanced approach between versions and standards enables us to build a comprehensive dataset that addresses all aspects of WiFi networks.

To achieve this, we develop a general architecture that implements three processes. These processes can be used separately or together, enabling the generation of a diverse range of questions while minimizing redundancy and accommodating limited computing resources if needed. The proposed architecture operates independently of the LLM models and available computing resources. The main consideration focuses on utilizing LLM APIs, where questions are generated based on a structured prompt that aligns with our dataset format. Consequently, the question generation process depends on the approach selected from the three available options. Below, we outline these approaches and provide detailed explanations for each step.

is the utilization of LLMs APIs compatible with the structured prompt of our dataset. The generation process depends on the type of data resources used to inspire the LLM model, injected into the pipeline at the first step. In the following, we present these approaches following the classic workflow composed of data preparation depending on the input data source, then the MCQ generation, after that the filtering for similarity detection and removal, and finally, the validation step.

## A. Preparation approaches

We will start by explaining the two approaches we adopted for the preparation phase of the input file, which will help us in our main architecture.

1) *Existing dataset filtering:* The first approach involves searching existing datasets for information that is purely related to the WiFi domain. figure 1 illustrates the process. We found that the TeleEval dataset [12] contains questions related to different versions of IEEE 802.11 in the form of statements and responses. Additionally, in the TeleQnA dataset [15] we found 543 WiFi-related questions and answers in multiple-choice format. For this reason, we decided to extract the questions related to WiFi and create a file containing these questions, which will be used as a source of inspiration to generate our dataset,

<figure><img src="image_2.png" /><figcaption>Fig. 1: The Approach of existing dataset filtering</figcaption></figure>

2) *Documentary resources filtering:* The second approach is based on documentary resources such as research journal papers, technical reports, conference articles, and books related to WiFi. These resources include presentations of configuration steps, troubleshooting methods, and industry updates. First, we convert PDF documents into text format to efficiently process all relevant information for better analysis. One of the problems we encountered is that some books and technical reports are available as scanned PDFs. To address this, we used Optical Character Recognition (OCR) technology [19], which works with algorithms to convert handwritten or printed text images into editable digital text, to extract only the most relevant sections. We use an LLM model to identify and group important paragraphs from different sources into a clean file containing key information. The choice of LLM model depends on several criteria, such as the number of supported tokens, whether the API model is free or paid, and whether it is open-source or not. In this work, we used the Gemini Flash 2.0 model [20]. However, the model itself is just an example the key part of our approach is removing pages with irrelevant information, such as tables of contents and appendixes. Additionally, we organize relevant paragraphs by source to create a clean Dataset filtered, which will serve as inspiration for generating our dataset, figure 2 illustrates this process. However there is still a task or a version that is incomplete in this approach. It is about mainly processing information and resources that are in graph format or image format. Sometimes, we find paragraphs that explain these images, but the explanation is still incomplete, and these paragraphs become useless. The only solution is to convert the images and graphs themselves into paragraphs. But this solution has limitations in terms of resources because the models that have the capacity to do this are paid models like GPT-4-Vision or Claude 3 (Anthropic), and also there
are limitations in terms of material resources to be able to
download and use these models locally.

<figure><img src="image_3.png" /><figcaption>Fig. 2: documentary resources filtering approach</figcaption></figure>

B. The proposed architecture

These two approaches are similar the preparation we did
before starting the final step of creating our final architec-
ture. The results of these two approaches serve as inputs or
key elements for the selected LLM model to generate more
questions. The dataset we extracted from the global telecom
dataset or the filtered file that contains technical paragraphs
related to WiFi. These two elements will form the foundation
or the resources that will help the LLM models generate more
questions.

The complete view of our proposed architecture is presented
in Figure 3. We first designed a structured prompt to define the
expected format of the generated data. This prompt was used
to create direct questions and configuration-related questions.
The two prompts were integrated into our code to ensure
consistency in question generation, and to increase the number
and diversity of questions, we used three different approaches:

1) *Question Generation Based on a Dataset:* We used a dataset that we collected from other datasets following the approach in Figure 1 of dataset filtering, containing questions related to IEEE 802.11. The model was asked instructed and to generate new questions using this dataset and a predefined prompt. The prompts for both question formats, configuration and direct question, and in both cases, the model was not installed on our local machine. Instead, we used an API to connect to the model and use it. The content of the API requests includes prompts with a detailed explanation of the question format to be generated, as well as the sub-dataset, which serves as a source of inspiration are an input file. This helps the LLM model to generate questions in the same context and also to adapt the question format to the sub-dataset to create new ones with different formats or variations. The responses received by the API from the model contain all the requested questions, following the exact format defined in the prompt.

2) *Paragraph-Based Question Generation:* Using the same API technique and configuration as in the previous approach, including the request and response format and content, we processed with this method. The only difference is the LLM model used for generating questions, to add more information to our prompts, we used a cleaned and filtered file that we had previously generated from written sources in Figure

2. We used this file to inspire our model in the question generation process. In this approach, we modified the prompt by adding a step to generate questions based on the paragraphs in the filtered file. All these steps ensured that the questions generated in the API responses were based on verified sources.

3) *Model-Informed Question Generation:* This approach did not require any prepared elements or datasets. Instead, we directly asked the model to generate questions based on its own knowledge. This method increased the diversity of the dataset. We used different LLM models for each approach to reduce duplicate questions further. This allowed to generate a variety of questions while also testing the capacity of each model to create the maximum number of unique questions.

C. Filtering phase

We implemented a filtering mechanism to detect and remove
repeated or similar questions, ensuring minimal redundancy.
This mechanism is based on two techniques:

1) *Direct repetition removal:* This technique removes questions that are identical in wording, meaning they appear more than once in the dataset. When comparing the question sentences, they are duplicated.

2) *AI-based similarity detection:* This method uses an LLM model to identify questions that are not exactly the same but share similar words or structures. The model works with a similarity threshold: If the threshold is too low, the model considers even partially similar questions duplicates, including those that share common words but have different meanings. If the threshold is too high, only questions with identical meanings will be filtered out. To ensure proper filtering, we set an optimal similarity threshold so that the model removes only questions that have the same meaning and would receive the same answer and explanation.

D. Validation phase

In this phase, we use LLM models to check if the generated
questions are correct or not. This done by using a prompt that
asks the LLM model if the generated answer for a question
is true or not. Based on the model's knowledge, it will give
a response. To make sure the answer is correct, it is better to
use more than two models for validation. Then, majority vote
of each model is used to decide if the generated answer is
correct or not.

Following this pipeline, we successfully created a new
dataset containing a diverse and comprehensive collection
of WiFi-related and configuration questions across all WiFi
versions.

V. APPLICATION

The steps explained in the previous section represent the
roadmap we followed to create the WiFiQnA dataset. Each
step is very important to ensure the generation of relevant
questions containing useful information for training or fine-
tuning LLM models specialized in the WiFi domain and re-
lated tasks. However, the proposed pipeline remained general,
as shown by its broad approach. The choice of LLM models
<figure><img src="image_4.png" /><figcaption>Fig. 3: Architecture explains the process of dataset generation following three approaches and based on LLM models, passing through three key steps</figcaption></figure>

depends on available hardware resources, financial resources (for paid ones), and time constraints, as new LLM models appear every week, changing the landscape. Therefore, the steps we explained serve as fundamental principles, while the model selection remains specific for each task and each domain.

In our case, three LLM models have been chosen for the generation phase:

*Gemini Flash 2.0* [21], it is the last version released until today, offering advantages such as higher speed, multi-modal generation, and a context window of one million tokens.

*Gemma2-9B* [22], based on a decoder-only transformer architecture. It has 9 billion parameters and was trained on 8 billion tokens, mainly using data in the English language.

*Qwen 2.5* [23], includes models ranging from 0.5 billion to 72 billion parameters and was trained on 18 trillion tokens. It is also based on a decoder-only architecture. In our case, we chose the model with 32B parameters to make good use of this model with a large number of parameters, in order to get as many questions as possible.

The choice of these three models was mainly based on their release date and performance. They are among the latest models published by Google (for Gemini and Gamma 2-9B) and Alibaba (for Qwen 2.5) at the time of this article's creation, and also the number of tokens criterion, allowing for the generation of multiple questions with a single API request.

Additionally, for each approach, we chose an LLM model to generate questions. For the first approach, which is based on a dataset of extracted questions, we chose the Gemini model, for the second approach, which is based on source extraction files, we used the Qwen 2.5 model with 32B parameters, and for the third approach, we allowed gamma 2-9B to generate questions based on its own knowledge. These choices were made to divide the models between the approaches. The decision depends on whether the model is available. It also helps to use the strong points of some models,

like Gamma, which can generate WiFi-related questions using its knowledge, and Qwen 2.5, which can create questions from texts and paragraphs.

After generation, filtering and validation phases are performed. For filtering, we used the LLM model *all-MiniLM-L6-v2*. This model compares the similarity between questions and removes duplicates using cosine similarity technique [24], a mathematical technique that determines how similar two vectors are by calculating the cosine of their angle. To perform this, the model converts the questions into tokens, generates vector representations, and calculates their cosine similarity. To determine similarity, a threshold must be defined to define whether we want to detect similarity in wording or meaning. In our case, we chose a high similarity threshold of 0.95. This is because the prompts given to the LLM generation models might produce very similar questions but differ slightly based on WiFi versions, for example. If the similarity threshold is too low, the model will detect these questions as duplicates and remove them, which we want to avoid. Therefore, choosing the right similarity threshold is key element in our case.

Finally, the last phase is question validation. We used the same LLM models for generation, but this time as validators, *Gemini Flash 2.0*, *Gemma2-9B*, based on the same selection criteria as in the generation phase (number of tokens, stability, and reliability). Additionally, we added two other models that were not used in the generation phase, the first model is *Qwen Turbo* [25], based on Qwen 2.5, which supports an input length of up to 1 million tokens, the second model is *Gemini Flash 1.5 8B* [20], an earlier version of Gemini Flash 2.0. It is smaller but has high efficiency and serves responses faster.

The reason for adding these two models in the validation phase is to avoid the issue where the models used for generating the questions would also be the ones validating them. This could lead to incorrect questions being mistakenly considered correct, and we finish with four LLM models in the validation phase. Additionally by introducing different models,
we aimed to improve validation accuracy. These models verify the questions by comparing the three generated files from the different models for each approach.

## VI. RESULTS

The proposed dataset is generated following the steps we explained: generation, filtering, and validation. We generated 12,097 questions using the three approaches, and by using the two prompts formats one that generates configuration questions and the other for direct questions. Our principle is to ask the three LLM models we used in each approach to create both the configuration questions and the direct questions at the same time. This ensures that the generated questions go through all the steps and benefit from the three approaches presented earlier.

All questions were merged based on the results of the three approaches. Table II, explains how the 12,097 questions are divided into 4,033 configuration questions and 8,064 direct questions.

<table><caption>TABLE II: Number of questions per approach and question type</caption><thead><tr><th></th><th>Configuration Questions</th><th>Direct Questions</th></tr></thead><tbody><tr><td>Approach 1</td><td>904</td><td>1,625</td></tr><tr><td>Approach 2</td><td>2,113</td><td>4,278</td></tr><tr><td>Approach 3</td><td>1,016</td><td>2,161</td></tr><tr><td>Total Question (TQ)</td><td>4,033</td><td>8,064</td></tr><tr><td>TQ after filtering</td><td>4,001</td><td>7,993</td></tr><tr><td>TQ after validation</td><td>3,960</td><td>7,520</td></tr></tbody></table>

This big difference is explained by the number of tokens and the number of words processed. Direct questions have fewer words because of their format. Also, the options are short and direct, and the explanation does not go over one sentence, because it only explains the choice. Box 3 illustrates this.

However, configuration questions are shown as use cases, with real-world situations and configuration problems. The options are not direct answers but rather complete step-by-step procedures to follow. Box 4 illustrates this. And This explains why the number of generated tokens is limited, as in our case, we used the APIs of the three LLM models: Gemini Flash 2.0, Gemma2-9B, and Qwen 2.5. These APIs have limitations in terms of the number of tokens that can be generated.

To better explain the differences in the number of questions in each approach, we can say that the main factor, aside from the power of the LLM model and its performance in terms of the number of tokens it can generate, that the second criterion is the inspiration source.

For example, the second approach, which uses written resources and books, contains the highest number of questions, this is because the files we used to inspire the LLM model to generate the questions have a lot of information. With just a single file, pdf, or even a single paragraph, we can generate many questions. The model will simply take the

paragraph, rephrase it as a question, and add some false options like answers. It can also take a paragraph or section of configuration and turn it into a step-by-step format, making it easier to create questions that have steps to follow.

But in the first approach, we only used 531 questions extracted from the TeleQnA dataset. This explains why the model had less information and fewer data to generate more questions. It will only use the questions that it has to formulate other questions or take information from two questions and generate a new one. Based on its knowledge and the question format and context, it will provide a new one.

The last approach is a bit different because the LLM model generates questions based on its own knowledge. In this approach, the model is free, it has no instructions to follow or phrases to guide it in generating questions. It will generate questions based on what it was trained on. However, these questions go through filtering and validation steps to ensure they are correct.

Finally we merged both types of questions into a single file, and the number of questions became 11,994 due to the filtering process. The first filter removed duplicate questions, and the second filtering with all-MiniLM-L6-v2 model to identify lexically similar questions, and for the validation of our dataset. We used our four LLM models, Gemini Flash 2.0, Gemma2-9B, Qwen Turbo and Gemini Flash 1.5B, and we checked the intersection of incorrect question IDs between the results of each model. This helped us to identify 514 incorrect questions that contained false answers, among this 514, we identified 41 as configuration questions and 473 as direct questions. This distribution seems reasonable due to the significant number of direct questions compared to configuration questions, in at the end, our dataset contains 11,480 correct questions, divided into two parts, 3,960 questions for configuration and 7,520 for direct questions, but in general, the number of questions is influenced by the LLM models and also the resources that we used as input files.

## Box 3: Direct Question Example

Question 6020: In IEEE 802.11ax, what mechanism is introduced to enhance Quality of Service, by providing scheduled transmission opportunities that reduce contention and improve system throughput CSMA/CA?

- Option 1: Spatial Reuse

- Option 2: BSS Color

- Option 3: Ultra-reliable Low Latency Communication

- Option 4: Target Wake Time (TWT)

Answer: Option 4: Target Wake Time (TWT)

Explanation: The Target Wake Time mechanism in IEEE 802.11ax is designed to reduce the power consumption of devices while improving network efficiency.
Box 4: Configuration Question Example

Question 2: You need to set up a new WiFi network using IEEE 802.11a in a crowded office environment with potential interference from other wireless devices. How do you configure the Physical Layer settings to ensure optimal performance?

- Option 1:

- Step 1: Set the modulation type to BPSK.

- Step 2: Choose the 5 GHz frequency band.

- Option 2:

- Step 1: Set the modulation type to OFDM.

- Step 2: Choose the 5 GHz frequency band.

- Step 3: Enable DFS to avoid congested channels.

- Option 3:

- Step 1: Set the modulation type to QPSK.

- Step 2: Choose the 2.4 GHz frequency band.

- Step 3: Enable WMM for multimedia applications.

- Option 4:

- Step 1: Set the modulation type to QAM.

- Step 2: Choose the 5 GHz frequency band.

Answer: **Option 2**

Explanation: Here's why option 2 is the best choice:

* **OFDM:** offering higher data rates and better resistance to interference, and 5 GHz Frequency Band: offers wider bandwidth and less congestion compared to the 2.4 GHz band, DFS: is essential for avoiding interference with other wireless systems operating in the 5 GHz band.

VII. CONCLUSION

Our research focused on Wi-Fi, a subfield of telecommu-
cations. We wanted to explore all its versions, our goal is to
find solutions to the problems that still disturb users, by using
the new trend in AI: Large Language Models (LLMs), but
Our research was conducted based on the lack of a specialized
dataset for WiFi adapted for LLMs. This gap led us to identify
and propose a solution to this problem, and also allowed us
to discover the steps required to convert paper-based and raw
information into structured, easily exploitable data. Ultimately,
our research resulted in a framework—an architecture, or in
other words, a life-cycle that can be generalized to create
datasets adapted to LLMs in any field.

Currently, we present the first version of our dataset as a
starting point or foundation that will open doors for further
research and allow us to improve it, our dataset is still in the
validation phase because there has been no human validation
yet, to add more credibility to the dataset, with confirmation
from experts, which is necessary. This is especially important
when experts in the field check if the questions are well formed
and if the answers are correct and not false. It also helps to
verify the LLM model's ability to generate questions with the
right answers.

We aim to leverage this dataset for techniques such as fine-
tuning LLM models specifically for WiFi-related tasks. The
goal is to answer user queries and enable advanced capabilities
such as automatic configuration and guided administration.
These remain as visions and directions that motivate us to
continue our research in this field, optimizing various tasks
and finding solutions to existing problems.

REFERENCES

[1] Derya Soydaner. "Attention mechanism in neural networks: where it comes and where it goes". In: *Neural Computing and Applications* 34.16 (2022), pp. 13371–13385.

[2] Richard E Turner. "An introduction to transformers". In: *arXiv preprint arXiv:2304.10557* (2023).

[3] Irene de Zarzà et al. “LLM multimodal traffic accident forecasting”. In: *Sensors* 23.22 (2023), p. 9225.

[4] Humza Naveed et al. “A comprehensive overview of large language models”. In: *arXiv preprint arXiv:2307.06435* (2023).

[5] Sulaiman Aftan and Habib Shah. "Using the arabert model for customer satisfaction classification of telecom sectors in saudi arabia". In *Brain Sciences* 13.1 (2023), p. 147.

[6] Minae Kwon et al. “Reward design with language models”. In: *arXiv preprint arXiv:2303.00001* (2023).

[7] Serena Booth et al. “The perils of trial-and-error reward design: misdesign through overfitting and invalid task specifications”. In: *Proc. of the AAAI Conference on Artificial Intelligence*. Vol. 37. 5. 2023, pp. 5920–5929.

[8] Hao Zhou et al. “Large language model (llm) for telecommunications: A comprehensive survey on principles, key techniques, and opportunities”. In: *arXiv preprint arXiv:2405.10825* (2024).

[9] Michal Pluhacek et al. “Leveraging large language models for the generation of novel metaheuristic optimization algorithms”. In: *Proc. of the Companion Conference on Genetic and Evolutionary Computation*. 2023, pp. 1812–1820.

[10] Xingqin Lin. "An overview of 5G advanced evolution in 3GPP release 18". In: *IEEE Communications Standards Magazine* 6.3 (2022), pp. 77–83.

[11] Fen Liu et al. “Survey on WiFi-based indoor positioning techniques”. In: *IET communications* 14.9 (2020), pp. 1372–1383.

[12] Ali Maatouk et al. “Tele-LLMs: A series of specialized large language models for telecommunications”. In: *arXiv preprint arXiv:2409.05314* (2024).

[13] Rasoul Nikbakht, Mohamed Benzaghta, and Giovanni Geraci. “Tspec-llm: An open-source dataset for llm understanding of 3gpp specifications”. In: *arXiv preprint arXiv:2406.01768* (2024).

[14] Imtiaz Karim et al. “SPEC5G: A dataset for 5G cellular network protocol analysis”. In: *arXiv preprint arXiv:2301.09201* (2023).

[15] Ali Maatouk et al. “Teleqna: A benchmark dataset to assess large language models telecommunications knowledge”. In: *arXiv preprint arXiv:2310.15051* (2023).

[16] Albert Q Jiang et al. “Mixtral of experts”. In: *arXiv preprint arXiv:2401.04088* (2024).

[17] Pranshav Gajjar and Vijay K Shah. “Oran-bench-13k: An open source benchmark for assessing llms in open radio access networks”. In: *arXiv preprint arXiv:2407.06245* (2024).

[18] Hua Zhu et al. “A survey of quality of service in IEEE 802.11 networks”. In: *IEEE wireless communications* 11.4 (2004), pp. 6–14.

[19] Ray Smith. "An overview of the Tesseract OCR engine". In: *9th Int. conference on document analysis and recognition*. Vol. 2. IEEE. 2007. pp. 629–633.

[20] Gemini Team et al. “Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context”. In: *arXiv preprint arXiv:2403.05530* (2024).

[21] Omer Aydin et al. “Generative AI in Academic Writing: A Comparison of DeepSeek, Qwen, ChatGPT, Gemini, Llama, Mistral, and Gemma”. In: *arXiv preprint arXiv:2503.04765* (2025).

[22] Gemma Team et al. “Gemma 2: Improving open language models at a practical size”. In: *arXiv preprint arXiv:2408.00118* (2024).

[23] An Yang et al. “Qwen2.5 technical report”. In: *arXiv preprint arXiv:2412.15115* (2024).

[24] Baoli Li and Liping Han. “Distance weighted cosine similarity measure for text classification”. In: *Intelligent Data Engineering and Automated Learning—IDEAL 2013*. Springer. 2013, pp. 611–618.
[25] Rui Yang et al. "Enhancing text-based knowledge graph completion with zero-shot large language models: A focus on

semantic enhancement". In: *Knowledge-Based Systems* 300 (2024), p. 112155.