Overview

Earlier articles in this series, Part 1 and Part 2, examined how an AI assistant responded to Wi-Fi support telemetry and how additional telemetry could improve that response. This article shifts the focus one step earlier to the Wi-Fi telemetry itself. Using Received Signal Strength Indicator (RSSI) as an example, it shows how the value of a Wi-Fi metric can differ based on how it is measured even when it carries the same name.

1. Telemetry’s downstream uses

Wi-Fi telemetry can feed several downstream applications. A dashboard can use it to provide quick network insights, a network optimization rule can use it to trigger an action or an AI assistant can use it to explain what is happening in the network. A downstream application typically sees only the provided metric value, not how it was measured. Therefore, it is important to understand what the telemetry value represents before it is used downstream.

2. Why measurement method matters

Managed Wi-Fi systems often work with summaries such as averages or percentiles rather than raw samples. This is one practical reason why measurement method matters. Summaries help reduce storage requirements while still retaining useful information for downstream applications. If the values used to compute the aggregate are not measured in the same way, then the aggregate value can shift even though the metric name stays the same. Let’s look at it with RSSI as an example.

A closer look at RSSI measurements

RSSI is commonly used to assess Wi-Fi coverage across the network. However, the reported RSSI value can reflect different underlying measurements.

To illustrate this, using the same setup as that described in the previous articles, we look at the RSSI distributions of the beacon frames and data frames captured while downlink traffic was running between the AP and the Wi-Fi client. At the same capture location, the RSSI distributions for the two frame types differ as shown below:

Although this example focuses on beacon frames and data frames, RSSI can also be reported from different RF chains, different bandwidths or averaging windows. The exact RSSI delta can vary depending on the measurement method, but the main point is that both rows above are valid RSSI measurements even though the values differ by a few dB. If these are combined into a single summary, the aggregate can influence downstream interpretation. For example, it can make coverage appear better or worse than it would under a different measurement method. The summary can shift further if invalid RSSI samples are included in the aggregate rather than filtered out first.

3. Conclusion

Production systems generally rely on summaries, and it is appropriate to do so. In the RSSI example, it is useful to keep separate summaries for different frame types and to know which one is used downstream. Aggregation choices like these depend on how the metric is measured, so what is appropriate for RSSI will be different from that for channel utilization or PHY rate. Without guardrails and well-defined aggregation criteria, downstream applications can end up using misleading inputs.

If your team is working through similar telemetry or aggregation questions for your Wi-Fi system, feel free to reach out.

Summary

In the previous article, we looked at a familiar user complaint - ‘Connection ‘feels’ very fast in the living room where the router is located but in the office, the video calls and browsing ‘feel’ slow’ - and examined how an off-the-shelf large language model (LLM) behaved when given the client-side logs (RSSI, noise, SNR, Tx PHY rate, channel, RTT, location). The AI assistant could identify broad Wi-Fi changes between the two locations (drop in signal strength, lower PHY rates) but introduced “interference” as a likely cause without any notion of how busy the wireless medium was. If you haven’t already read the previous article, you can find it here: Part 1

This article adds ‘channel utilization’ as a way to estimate how busy the wireless medium looks during the user’s session. Using the same two room setup and data as before, we compare three cases:

• No channel utilization input
• Quiet channel
• Busier channel

These examples use illustrative utilization values (15% as “low” and “45%” as “busier”) from the AP’s point of view rather than measured numbers. We then look at how the AI assistant’s responses change in each case and qualitatively assess whether the causes and next steps stay grounded in the available evidence, and where they still fall short.

The main takeaway is that giving the assistant ‘utilization’ information helps it reason about the causes of the complaint more concretely. At the same time, when utilization looks similar in both rooms, it tends to de-prioritize interference. In real networks, weak coverage can hurt more when the channel is busy than when it is quiet. An AI-enabled Wi-Fi system should consider utilization and coverage as interdependent factors to arrive at a reasonable explanation.

1. Recap: User Complaint and Setup

Using a simple example, the previous article looked at the assistant’s behavior to extract meaningful lessons.

• User complaint: Connection ‘feels’ very fast in the living room where the router is located but in the office, the video calls and browsing ‘feel’ slow.
• Setup: The router is located in the living room while the office room is farther away.
• Per-second client-side logs: RSSI, noise, SNR, Tx PHY rate, channel, LAN/WAN RTT, location.

In the previous article, we saw that the LLM correctly identified broad patterns such as the office had weaker signal and lower Tx PHY rate but still came up with “interference” as one of the likely causes without any data about interfering sources or the extent of interference. In this part, we provide the assistant with an additional piece of information about the ‘busyness’ of the wireless medium.

2. Interpreting ‘interference’

In this article, we use ‘interference’ to mean ‘medium busyness’ that reduces available airtime due to activity on the channel (Wi-Fi contention and/or non-Wi-Fi energy).

Typically, a Wi-Fi system can estimate this ‘medium busyness’ per radio/interface using:

Clear Channel Assessment (CCA) counters on the Wi-Fi chipset:

Chipset vendors often expose internal counters that track how long the Clear Channel Assessment indicates the medium as busy over a time window. From these, a device (AP or client) can derive the fraction of time the medium was busy. Depending on implementation, these counters may include the time spent by the device’s own traffic as well as other energy (Wi-Fi or non-Wi-Fi) on the channel.

BSS Load indicator:

Some access points advertise the channel utilization they observe in beacons and probe response frames using the BSS Load information element (IE). It provides an insight into the AP’s view of channel busy time.

In a real system, ‘channel utilization’ can come from an AP or a client using their respective counters. Each device presents its perspective of medium busyness, based on where it is located and its own hardware implementation. Understanding which implementation your system uses, whether it separates one’s own airtime from other busy time, and whether the value makes sense is important if you plan to feed it as input to an AI assistant.

In this article, we do not focus on the specifics of each implementation. Instead, for simplicity, we use utilization as a coarse indicator of medium busyness during the user’s video call/browsing session.

3. System View: Adding a ‘busyness’ input

At a high level, the system still follows the conceptual workflow from the previous article where the AI assistant is given the ‘user complaint’ and the relevant telemetry slice consisting of time, location, RSSI, noise, SNR, uplink Tx PHY rate, channel, LAN/WAN RTT. Here, the only change is the addition of a ‘channel utilization’ field as input, which reflects how busy the channel looked during the session.

In the examples that follow, we look at hypothetical utilization values (15% and 45%) that represent lower and higher levels of medium busyness.

4. AI assistant setup changes

We keep the same two room setup, telemetry and model (“gpt-4.1-mini”). The physical setup still consists of a single AP in the living room. The channel utilization is represented as a single value shared by both locations (living room and office) over the entire user session, rather than a per room measurement. The assistant still has to describe changes between the two rooms, suggest likely Wi-Fi causes and propose safe next steps for a home user.

The assistant behavior is illustrated with two changes:

Prompt tweak:

A small guardrail is added to the prompt so that the suggested next steps are tied to its own reasoning. Specifically, the line now reads as “Suggest 3-5 safe next checks or actions for a home user based on the likely causes identified.”

Utilization column variants:

The per-second telemetry table is extended by adding a ‘channel utilization’ column. Three input variants are constructed from the same logs using hypothetical but plausible utilization values:

• No utilization metric
  • The table is exactly as in the previous article. No ‘channel utilization’ column
• Quiet channel (15%)
  • The table now has a ‘channel utilization’ column set to 15% for every row in both the living room and the office (snapshot below).
• Busier channel (45%)
  • The ‘channel utilization’ column is set to 45% for every row (also, same for both locations).

The example snapshot below shows the additional channel utilization column for the ‘quiet’ channel scenario and the prompt tweak as an input to the LLM.

5. Results: how the assistant reacts to utilization

The three input variants change the assistant’s behavior as shown below:

5.1 No channel utilization column:

• As in Part 1, the assistant correctly identifies that RSSI/SNR/Uplink Tx PHY rates are much worse in the office than in the living room. However, it lists ‘interference’ as a likely cause without supporting evidence.
• In this example, it still provides channel change recommendations based on an unsupported ‘interference’ cause, despite adding the prompt guardrail (‘suggest next steps based on the likely causes identified’).

5.2 Channel utilization is low (15%) and set to the same value for both locations

• As in the previous case, the assistant still identifies coverage issues (weak signal, low SNR, low PHY rate) as the main difference between rooms.
• With the new metric, it explicitly notes that channel and utilization values are the same for both locations and uses that to say channel interference is not a likely cause.
• Coverage driven actions (moving closer to the router, repositioning the router, reducing physical obstructions, adding an extender) stay, but now the assistant also focuses on improving range (e.g. switching to a lower 5 GHz channel or the 2.4 GHz band) rather than reducing interference.

5.3 Channel utilization is higher (45%) and set to the same value for both locations

• Weaker coverage in the office is highlighted again as a primary issue.
• Even though the channel utilization is higher (45%) in this case, the model uses the same utilization value for both locations to say ‘interference’ is ‘less likely the main issue’ behind why video calls and browsing feel slower in the office than in the living room.
• Recommendations are similar to the previous case but with higher utilization the assistant also suggests changing to a less congested channel as a secondary mitigation.

6. Analysis: what a simple prompt change and utilization metric accomplished

In our basic AI system, the prompt tweak (“suggest next steps based on the likely causes identified”) encourages the assistant to suggest actions related to stated causes but it cannot repair a hypothesis that was never based on evidence to begin with.

What the utilization metric changes:

• when utilization is low, the assistant prioritizes coverage as a cause for why the office feels ‘slow’
• when utilization is higher, the assistant still highlights coverage as the main problem, with channel change appearing as a secondary next step
• different utilization levels steer which next steps are suggested (eg., whether to bring up channel change at all)

Some suggestions (eg., switching to a lower 5 GHz channel or the 2.4 GHz band) require engineering judgement before recommending. Lower 5 GHz typically offers minimal range benefit over a high 5 GHz channel, and 2.4 GHz range gains often come with tradeoffs (narrower channel widths, more congestion/interference).

Finally, even though we have managed to improve our AI system, it still fails to capture the nuance that the performance can be degraded by multiple factors operating jointly. In a Wi-Fi system, coverage issues can be worsened by congestion. For example, a weak link falls back to lower PHY rates, spends more time on air (see appendix), and therefore suffers more from contention when the channel is busy. A single utilization value applied to both rooms does not make interference harmless. A production system design should accommodate these interdependent factors to be useful in the field.

7. Conclusion

The two room coverage complaint, revisited with a channel utilization metric, surfaced a few general lessons for building an AI-enabled Wi-Fi system:

• prompt changes without the right metrics cannot make up for missing, incomplete, or inaccurate evidence
• additional metrics (like channel utilization) can help constrain when the assistant brings up a cause (like interference or congestion), instead of using it as a generic explanation
• a reliable system requires understanding how different Wi-Fi factors interact, for example, weak signal and congestion can degrade performance together
• some suggestions still require engineering judgement before recommending to the end user (for example, switching to a lower 5 GHz channel or the 2.4 GHz band)

If you’d like to discuss how to choose and validate the right metrics, and design AI-enabled Wi-Fi systems that use them reliably, feel free to reach out.

8. Appendix

In order to get insight into how airtime increases at lower rates, let’s consider a simple example and calculate the time on air for a 1500 byte packet.

• In the living room, the link supports a PHY rate of 867 Mbps. A 1500 byte packet would then require:

• In the office room, the link supports a PHY rate of 41 Mbps. A 1500 byte packet would then require:

In reality, the time required for the successful delivery of a packet is higher than that required for just the payload due to protocol overheads (PHY/MAC headers), contention/backoffs, acknowledgements, and retransmissions. However, this simple example helps illustrate the fact that, in our setup, the data transmission for the same application payload takes more than 20x longer at the office link rate than in the living room.

Summary:

With all the attention surrounding AI over the past few years, an often repeated question in my discussions has been some version of: “What possibilities can be unlocked with AI for Wi-Fi networks?”

Wi-Fi chipset vendors are already building AI-driven features for optimizing performance for the Wi-Fi client. However, this article looks at the support side of the problem: how a general purpose large language model (LLM) could help with Wi-Fi support, using a common and relatable poor Wi-Fi coverage complaint as an example. I hope you find value in this insight.

Using a basic setup, the article:

• describes the user complaint
• explains the physical setup and the telemetry data collected for this scenario
• provides a high-level view of the system
• describes the AI assistant setup
• scrutinizes the AI assistant’s response when given the field data, and
• qualitatively analyzes the AI assistant’s strengths and weaknesses

The example doesn’t span the entire real problem space, but it is simple enough to understand in detail and real enough to extract meaningful lessons. The main takeaway is that, in this simple setup, an off-the-shelf LLM can extract some broad patterns from the data but without the right data or guardrails it can speculate about causes, which can mislead end users. Real field issues and production systems are more complex, and any takeaways here need careful system design before they are applied more broadly.

1. Problem

To make this tangible, I picked a familiar complaint: Connection ‘feels’ very fast in the living room where the router is located but in the office room, the video calls and browsing ‘feel’ slow. This article focuses on this one simple incident and asks: can a simple AI assistant help with it, and if so, to what extent?

2. Setup & data collection

Setup

The setup is simple: a retail dual-band (2.4 GHz /5 GHz) Wi-Fi 5 router and a MacBook client used at two locations:

• Location 1 - in the living room, close to the router
• Location 2 - in the office, farther from the router

At each location, the client is stationary while measurements are collected.

Data logging

A small data-logging script runs on the MacBook and records data once per second:

Wi-Fi link metrics:

• RSSI,
• Noise
• SNR (computed)
• Uplink Tx PHY rate
• Channel

Latency metrics:

• Ping round-trip time (RTT) to the gateway (LAN)
• Ping RTT to the internet (WAN)

These are all client-side measurements. There is no access to AP side data.

AI assistant used

For the AI assistant, I use an off-the-shelf, pre-trained LLM (gpt-4.1-mini). These models are typically trained on a mixture of publicly available data from the web, licensed data and data created by human trainers.

3. High-level system view

The diagram below shows a high level view of the system used in this article.

• The blue blocks are the common pieces: the Wi-Fi network, a data logger on the client, and a simple telemetry database (a CSV file in this case).
• The green block represents a typical current pattern in organizations, where a Wi-Fi engineer analyzes the field situation using logged data.
• The orange blocks represent an AI assistant (pre-trained LLM) that looks at the same data and produces its own summary.

In a production system, a Wi-Fi engineer would usually have access to telemetry from multiple sources captured at different layers (RF, PHY, MAC, network, application), along with firmware and cloud logs when needed.

4. AI assistant setup: a very basic helper

For this experiment, the AI assistant receives:

• the user complaint text
• a time series table of metrics (RSSI, Noise, SNR, uplink Tx PHY rate, channel, LAN/WAN latency) tagged with the location (living room, office), captured from the client only (snapshot below)

• a simple prompt:

“Here is a user complaint and some Wi-Fi telemetry.

Your tasks:

1) Describe what changes between locations (in the living room, in the office).

2) Suggest 2–3 likely causes from the Wi-Fi side.

3) Suggest 3–5 safe next checks or actions for a home user.

• Focus on things a typical home user could reasonably try.

Be explicit and concise.”

5. AI assistant’s response: a closer look

Here’s a snapshot of the summary generated by the LLM:

Scrutinizing the ‘observed changes’ and ‘likely causes’:

From this snapshot, the assistant correctly identifies that the RSSI (~ -46 dBm vs ~ -81 dBm), SNR (~ 43-46 dB vs 11 dB) and uplink Tx PHY rate (867 Mbps vs 41 Mbps) are much better in the living room than in the office. It’s good to see that it treats latencies of ~2-5 ms and noise levels of -89 to -92 dBm as those being more similar than different.

It also does a reasonable job of linking the drop in RSSI/SNR in the office to a deterioration in link quality. Interestingly, it also brings up “throughput” even though it was given Tx PHY rate rather than actual throughput measurements.

However, it also adds generic “interference” as a possible cause without any supporting evidence in the data or a clear way to test the hypothesis.

Zooming into the ‘next checks’:

Some of the suggested next steps can serve as reasonable first checks, such as:

1. moving the device closer to the router to see if the signal strength improves,

2. reducing obstacles between router and office and

3. restarting the router as an easy option for the user to try

But others such as ‘minimize interference’ are too generic and not grounded in facts to show to the end user. Also, advice such as “install a mesh/Wi-Fi range extender” without any context about whether the current Wi-Fi system supports it, or whether an engineer would need to recommend and provision new extender hardware is not realistic. Suggesting the user to use a wired Ethernet connection in the office without understanding the physical limitations such as accessibility can be confusing.

6. Analysis: strengths and weaknesses

In this simple setup, the very basic AI assistant is still useful to:

• notice general trends (for example, “signal strength in the office is worse than in the living room”)
• suggest a few reasonable, simple next steps

However, it clearly falls short in other ways:

• It doesn’t clearly distinguish between different root causes (coverage vs interference).
• It provides generic advice that also seems impractical as one of the first lines of action, such as addition of an extender, without considering user or system constraints.
• It shows no awareness of missing data that would help disambiguate between different causes (for example, use of channel utilization or retry rates to infer interference).

So, the basic assistant is directionally helpful but not sufficient on its own. For this specific example, a simple heuristic such as nudging the user to move close to the router when the RSSI is very low would be already good enough. Using a LLM helps illustrate the model’s behavior in a simple setting when it is presented with real telemetry data. In future articles, we will explore different ways to make these kinds of systems more useful.

7. Conclusion

Conceptually, a high level view of this workflow could look like the image below. Real deployments would include the data infrastructure and orchestration around it.

Even for this simple incident, a production workflow would need more structure around the assistant’s outputs. Some suggestions are actionable for the end user (for example, moving the device), while others are more technical and require due diligence before recommending to the end user (for example, adding an extender).

Overall, this justifies exploring LLM capabilities to augment the current support workflow, especially for capturing patterns in telemetry and turning them into structured hypotheses. If you are thinking about how to choose the right Wi-Fi telemetry, how to judge whether LLM responses are strong enough, or how to bring AI into your managed connectivity system for Wi-Fi use cases, feel free to reach out.

8. Appendix

Data collection details

• Client device: MacBook (macOS 12.7.4)
• Access point: retail dual-band Wi-Fi 5 router (2.4 GHz/5 GHz)
• Sampling interval: 1 sample per second

Capture durations:

• Living room: 2 minutes
• Office: 2 minutes

Wi-Fi metrics (RSSI, noise, Tx PHY rate)

• On macOS, the airport utility was used to collect Wi-Fi metrics

  /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I
  

Round-trip time

• LAN round-trip time (gateway ping)

  ping -c 1 -W 1000 <gateway_ip> 
  

• WAN round-trip time (internet ping)

  ping -c 1 -W 1000 <wan_host>
  

Sequence of actions

Every second, a script executed the following sequence of actions:

• ran the following command:

  airport -I
  

• ran one LAN ping and one WAN ping, and
• parsed the outputs (RSSI, noise, Tx PHY rate, LAN RTT, WAN RTT), computed the SNR and logged along with a timestamp, and location tag (living room, office) into a CSV file.

Recording LLM response

• LLM response was obtained using the following API from OpenAI:

response = client.responses.create(
    model="gpt-4.1-mini", 
    input=[
        {
            "role": "user",
            "content": input_prompt,
        }
    ],
)

answer = response.output[0].content[0].text