PaperlayerView exact revision on arXiv

Source-linked AI summary

IEEE 802.11bx - WLAN Intelligent Networking (WIN): Toward an AI-Ready Wi-Fi 9

Francesc Wilhelmi, Katarzyna Kosek-Szott, Szymon Szott, Boris Bellalta

arXiv:2610.07900v1cs.NIcs.AI

TL;DR

Wi-Fi 9’s 802.11bx WIN initiative treats AI as a core pillar, while emerging workloads create demands that current traffic handling may not address. This tutorial reviews candidate AI roles and features in Wi-Fi standardization and illustrates AI traffic differentiation with a simulation case study. The case study supports introducing a dedicated access category rather than reusing existing EDCA categories.

  • Problem

    Emerging AI workloads and applications motivate Wi-Fi to support AI-aware operation, computation, and traffic handling.

    Source: §I · p. 1, C. Traffic-Centric Drivers · p. 2

  • Method

    The tutorial surveys standardization developments and candidate features across AI as a protocol, platform, and traffic, then simulates a dedicated access category for AI traffic.

    Source: §I · p. 1, §IV · p. 4, B. Simulation Results · p. 6

  • Results

    The simulation shows that no single existing access-category assignment is safe for every traffic type, supporting a dedicated category for AI traffic.

    Source: B. Simulation Results · p. 6

  • Takeaways & Limitations

    The tutorial concludes that AI traffic differentiation is needed beyond current EDCA categories and identifies open questions for AI-ready Wi-Fi 9.

    Source: §VI · p. 7

Abstract

from arXiv · show

Wi-Fi 9 is expected to go beyond mere communication and provide new services such as sensing or computation. At this juncture, Artificial Intelligence (AI) is taking a leading role in the definition of the 802.11bx amendment, named WLAN Intelligent Networking (WIN). In this tutorial, we survey the recent progress made toward Wi-Fi 9 within IEEE 802.11 standardization, tracing the drivers and technological advances that motivate an AI-ready Wi-Fi 9. We then examine AI's role along three complementary dimensions, i.e., AI as a protocol (AI is applied to Wi-Fi's PHY/MAC operation), AI as a platform (Wi-Fi infrastructure is repurposed to provide AI computation), and AI as traffic (AI flows call for new traffic-handling policies), and discuss candidate features and open challenges along each. As a concrete illustration of the AI as traffic paradigm, we present a case study on AI traffic differentiation, where we explore a potential extension of the current Enhanced Distributed Channel Access (EDCA) to support new AI traffic flows.

I. INTRODUCTION

The 802.11bx WIN initiative makes AI a core pillar of Wi-Fi 9, building on years of IEEE 802.11 study and emerging application demands. The tutorial reviews the drivers, candidate AI roles, and a simulation case study on AI traffic differentiation.

I. INTRODUCTION

  • The WIN name reflects a move toward AI and ML in Wi-Fi standardization following several years of IEEE 802.11 AI/ML study.Advances in AI, including LLMs, alongside XR, sensing, and Industry 4.0 requirements are motivating this direction.Source: §I · p. 1
  • AI is established as Wi-Fi 9’s core pillar, but specific IEEE 802.11bx performance targets are premature while its Project Authorization Request (PAR) is in preparation and expected by 2027.Source: §I · p. 1
  • The tutorial organizes AI’s potential Wi-Fi roles as protocol, platform, and traffic, and presents a simulation-supported case study of AI traffic differentiation.These roles cover improving Wi-Fi operation, using Wi-Fi infrastructure for AI computation, and managing AI workloads with tailored QoS.Source: §I · p. 1

II. DRIVERS FOR AN AI-READY WI-FI 9

Application requirements motivate an AI-ready Wi-Fi 9: immersive communications need demanding networking support, while sensing extends Wi-Fi capabilities and can use AI to interpret channel measurements.

A. Application-Centric Drivers

  • XR combines stringent throughput, latency, and reliability constraints that existing Wi-Fi generations remain hard-pressed to guarantee.Split-rendered XR streaming typically requires about 50 Mb/s and low, stable latency below 10–15 ms; AI-generated content and continuous video models reinforce the need for novel Wi-Fi features and efficient offloading.Source: A. Application-Centric Drivers · pp. 1–2
  • Figure 1 links XR to enhanced PHY/MAC schemes, sensing to expanded device capabilities and possible computation offloading, and AI traffic to revised traffic-treatment policies.The examples include MAPC or intelligent protocols for XR and traffic differentiation for AI flows.Source: Figure 1 · p. 2
  • Wi-Fi sensing uses channel state information to support tasks such as gesture recognition, motion tracking, and environmental monitoring without dedicated sensors or cameras.AI can recognize patterns in complex CSI signals, and sensing is an early candidate for AP inference alongside communication workloads on modest, power-constrained silicon.Source: A. Application-Centric Drivers · p. 2

B. Computation-Centric Drivers

As AI workloads exceed what individual devices can provide locally, Wi-Fi infrastructure is a potential site for computation. Physical AI and multi-agent applications also call for reliable, low-latency links and task-aware network scheduling.

B. Computation-Centric Drivers

  • The paper identifies computation beyond individual devices as a driver for Wi-Fi to support AI workloads, including offloading, physical AI, and multi-agent systems.Network schedulers may need to account for more than traffic class, including the structure of tasks running on top of the network.Source: B. Computation-Centric Drivers · p. 2
  • AI computation offloading shifts inference and reasoning toward the edge, making nearby Wi-Fi APs potential hosts for workloads if they have sufficient compute and memory.The paper cites a report that 50% of AI deployments in production struggle to maintain low latency at scale due to cloud infrastructure delays.Source: B. Computation-Centric Drivers · p. 2
  • Physical AI and multi-agent systems require reliable, low-latency links and joint scheduling that accounts for task structure, agent state, station capabilities, and wireless resources.Some cooperative tasks require submillisecond round-trip delay between controllers and actuators.Source: B. Computation-Centric Drivers · p. 2

C. Traffic-Centric Drivers

AI applications bring traffic with distinct statistical and semantic properties, challenging assumptions behind Wi-Fi traffic handling. The path toward WIN consolidates parallel developments in IEEE 802.11 and the broader technology landscape.

C. Traffic-Centric Drivers

  • AI flows differ from web traffic through longer sustained connections, smoother throughput, and a higher upstream share: 9% versus 0.5% for typical web traffic.The passage estimates AI inference could reach 25% of total WAN traffic by 2035.Source: C. Traffic-Centric Drivers · p. 2
  • Semantic communications shift focus from faithful bit transmission toward the meaning and task value of messages, a direction not yet explicitly considered in Wi-Fi standardization.The passage notes that semantic-aware traffic treatment and reconsideration of all-or-nothing retransmissions might matter in future communications systems.Source: C. Traffic-Centric Drivers · p. 3

III. THE ROAD TO WIN

  • The path toward WIN and TGbx consolidates parallel developments within IEEE 802.11 and across the broader technology landscape; Figure 2 presents key events and a forecasted roadmap.The figure is a timeline of WIN and related developments in IEEE 802.11, AI, and hardware.Source: §III · p. 3, Figure 2 · p. 3

A. 802.11 Mainstream

Wi-Fi 9 work is developing in parallel with Wi-Fi 8, with the WIN Study Group preparing the project scope and a Task Group expected to develop the specification. Other 802.11 activities include earlier AI/ML study, AI offloading, sensing, mmWave, and post-quantum security.

A. 802.11 Mainstream

  • The WIN Study Group is drafting Wi-Fi 9’s Project Authorization Request, after which Task Group bx is expected to develop the specification for the early 2030s.AI-feature inclusion remains uncertain; the PAR is expected through 2027.Source: A. 802.11 Mainstream · p. 3

B. Other Relevant 802.11 Activities

  • The AI/ML Topic Interest Group identified feasible 802.11 use cases, then became a permanent Standing Committee coordinating AI/ML contributions.Use cases included CSI feedback compression, enhanced roaming, DRL-based channel access, AI/ML-driven MAPC, and model sharing.Source: B. Other Relevant 802.11 Activities · p. 3
  • The AI Offload Study Group’s PAR led to TGbu, which is tasked with mechanisms and interfaces for clients to offload computation to APs.The passage describes this as potentially reducing latency compared with cloud-based solutions.Source: B. Other Relevant 802.11 Activities · pp. 3–4
  • Wi-Fi sensing, integrated mmWave, and post-quantum cryptography are concurrent 802.11 activities that may complement AI-related infrastructure changes.The passage links TGbt’s security work with the data requirements of the emerging 802.11bu framework.Source: B. Other Relevant 802.11 Activities · p. 4

C. Advances in AI and Hardware

Advances in AI applications and hardware are strengthening the case for AI-ready Wi-Fi. The proposed Wi-Fi 9 directions distinguish AI-driven changes to Wi-Fi operation, infrastructure for AI computation, and treatment of AI traffic.

C. Advances in AI and Hardware

  • Recent AI advances and rising inference traffic coincide with specialized GPU/NPU hardware appearing in edge and consumer devices.Examples include Qualcomm’s Networking Pro A7 Elite with a 40-TOPS NPU and Wi-Fi chipsets with integrated neural engines.Source: C. Advances in AI and Hardware · p. 4

IV. AI-DRIVEN FEATURES FOR WI-FI 9

  • AI-ready Wi-Fi 9 features are grouped by AI’s role as a protocol, platform, or traffic, alongside their drivers and related 802.11 groups.The roles respectively concern improving PHY/MAC operation, supporting AI computation in Wi-Fi infrastructure, and handling AI traffic.Source: §IV · p. 4

A. AI as a Protocol

AI may improve Wi-Fi operation by extending multi-AP coordination, creating or learning communication rules, and increasing network awareness. These directions remain prospective, and the AI-learned protocol ideas are conceptual rather than concrete standardization proposals.

A. AI as a Protocol

  • AI could extend MAPC beyond two APs, using learning to manage coordination complexity in dense deployments with multiple users and overlapping APs.Possible approaches include clustering, traffic forecasting, federated learning, GNNs, and MARL; for Co-BF, CSI compression becomes more necessary as coordinated APs increase because channel-estimation overhead can erase beamforming gains.Source: A. AI as a Protocol · p. 4
  • AI-learned protocols could create communication and coexistence rules, from adapting CW using traffic patterns to learning protocols that may replace DCF.The broader direction also combines learning across PHY/MAC parameters such as link adaptation and channel coding; it is conceptual at this stage, not a concrete standardization proposal.Source: A. AI as a Protocol · pp. 4–5
  • AI could increase network awareness through roaming predictions and deep-learning-based classification of observed frame formats.Roaming models can predict RSSI evolution to produce candidate AP lists; frame classification could support behavior such as differentiated spatial-reuse policies.Source: A. AI as a Protocol · p. 5

B. AI as a Platform

Wi-Fi infrastructure is being considered as a platform for AI computation, including model sharing and offloading workloads to nearby compute-capable devices. The standardization work must address discovery, service requests and results, resource allocation, and secure offloading.

B. AI as a Platform

  • AI/ML model sharing was considered as a way to support AI over Wi-Fi, with model-exchange traffic raising QoS concerns for traditional applications.The AI/ML TIG suggested accounting for exchange overhead in airtime distribution, potentially through MAC-layer exchange and signaling changes.Source: B. AI as a Platform · p. 5
  • TGbu’s scope includes MAC-layer transport and signaling for secure AI offloading from compute-capable devices, including APs, clients, and devices reachable through a Distribution System.The framework includes advertising offloading services and their location, requesting services, retrieving results, and enforcing mutual trust; session setup must negotiate computation and communication requirements.Source: B. AI as a Platform · p. 5
  • TGbu must standardize compute capability despite differences between hardware such as GPUs and NPUs and changes in available resources such as memory.Compute is another limited resource alongside airtime, so APs must define how to accept, reject, queue, or renegotiate competing requests; 802.11 has no direct precedent for compute-resource allocation.Source: B. AI as a Platform · pp. 5–6
  • Secure offloading also requires work on cryptographic primitives and mutual authentication procedures.The passage identifies this work as synergistic with TGbt activities.Source: B. AI as a Platform · p. 6

C. AI as Traffic

Agentic AI traffic differs from traditional flows in its uplink-heavy, sustained, task-dependent exchanges, motivating both dedicated access-category treatment and differentiation among dependent subtasks. The case study examines a candidate AI access category that supports AI traffic without degrading traditional classes.

C. AI as Traffic

  • Scheduling dependent subtasks can reduce end-to-end latency by 20% and improve task reward by 80% versus task-unaware approaches [15].Agentic flows can include subtasks that depend on one another, making their scheduling a primary concern.Source: C. AI as Traffic · p. 6
  • Agentic AI brings uplink-heavy, sustained, task-dependent exchanges that differ from Wi-Fi’s traditional web, file-exchange, and multimedia flows.A new access category is proposed rather than mapping AI traffic to voice, video, or best effort.Source: C. AI as Traffic · p. 6
  • AI traffic differentiation could account for dependency structure within a flow, giving subtasks that others depend on different treatment from non-critical subtasks.Source: C. AI as Traffic · p. 6

V. CASE STUDY: AI TRAFFIC DIFFERENTIATION IN WI-FI

  • The case study evaluates a candidate EDCA access category for AI traffic against the goal of avoiding degradation to voice, video, and best-effort traffic.Source: §V · p. 6

A. Scenario

The scenario models a 23-station BSS with three traditional traffic flows and AI traffic representing 20 students using LLMs. It specifies bursty uplink and downlink token-generation traffic and identifies a table of simulation parameters.

A. Scenario

  • The 23-station BSS places stations 3 m from the AP; three stations carry voice, video, and best-effort traffic as a high-contention baseline, while 20 represent students using LLMs.The AI sessions correspond to an approximately 6 Mb/s load distributed between uplink prompts and downlink responses.Source: A. Scenario · p. 6
  • Each AI session models uplink token-generation bursts using 4-kbit frames, 10–33 ms inter-arrival times, and 10–60 s burst durations, with 5–30 s idle periods.Source: A. Scenario · p. 6
  • Downlink traffic follows the same model but divides intra-burst rates and idle gaps by the number of students to reflect response aggregation.Table II is identified as providing the main simulation parameters.Source: A. Scenario · p. 6, Table II · p. 6

B. Simulation Results

Simulation results show that no single existing access-category assignment is safe for every traffic type, motivating a dedicated AI category. The conclusion identifies open questions about protocol compatibility, compute allocation, and protecting legacy traffic.

B. Simulation Results

  • AC AI is configured between AC VI and AC BE in priority, with AIFSN 4 and TXOP limit 0; CWmin 8 and CWmax 64 balance access and contention.The stated hierarchy is AC VO ≻ AC VI ≻ AC AI ≻ AC BE ≻ AC BK.Source: B. Simulation Results · p. 6
  • Assigning AI traffic to AC VO minimizes AI delay at 1.15 ms but raises BE median delay to 12.04 ms and its upper-whisker tail to 47.59 ms.Source: B. Simulation Results · p. 6
  • Assigning AI traffic to AC BE raises its median delay by 45% to 2.08 ms and its tail to 16.75 ms, versus 1.43 ms and 7.99 ms with AC AI.Source: B. Simulation Results · p. 6
  • Compared with AC VI, AC AI lowers AI median and tail delay, while raising VO, VI, and BE median delays by 1%, 2%, and 8%, respectively.The paper reports that EDCA prioritization preserves QoS for the two highest-priority classes, VO and VI.Source: B. Simulation Results · p. 6
  • No AI-traffic assignment to an existing access category is safe for every flow, motivating a new AI category; Figure 3 compares per-flow end-to-end delay distributions.Source: B. Simulation Results · p. 6, Figure 3 · p. 7

VI. CONCLUSIONS

  • The tutorial identifies open questions about reconciling AI-driven protocols with backward compatibility, fairly allocating compute, and treating AI traffic without penalizing legacy classes.Source: §VI · p. 7
Loading 2610.07900v1…