Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11] AI Offload SG contribution for July 2026



--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Jerome,

Sorry I missed this email earlier.  The use case in the slides depicts the former case where the compute resource is tightly coupled within the AP. I do agree if the compute resource is via the DS to reach the AP, there might not be much the AP can control. The idea in this use case is since the compute resource belongs to the AP, the AP would need to manage it (e.g., when to run what AI model, what STAs to grant access and for how long, etc).

Would be happy to discuss with you further.

BR,
Duncan


From: Jerome Henry <jhenry@xxxxxxxx>
Sent: Wednesday, 15 July 2026 11:11:03
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11 <STDS-802-11@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11] AI Offload SG contribution for July 2026
 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Thank you Duncan for this very interesting presentation!

I do recall that you mentioned that this was just an example, and I wanted to explore the example a bit further with you.

On slide 5, you represent the AP, and mentioned that the AP was running the compute offload service. Do you envision this scenario as literal (where the 802.11 AP also becomes a compute resource), or is it a figure of speech, where the device that performs the AP function also happens to include an OS with a GPU or some compute ability it can make available? In the later case, does it matter if the compute is in the same physical device that holds the AP function, or right behind that device? (i.e. latency of access is the primary concern, and from the 802.11 AP viewpoint, the compute resources in on the DS)?
"Other protocols" (at L7) already care about model access and session setup: why, in the scenario you envision, does it need to be an 802.11 function?

Thanks again for the constructive dialog!

Take care

Jerome  



From: Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx>
To: <STDS-802-11@xxxxxxxxxxxxxxxxx>
Date: Thu, 09 Jul 2026 04:10:43 -0900
Subject: [STDS-802-11] AI Offload SG contribution for July 2026

--- This message came from the IEEE 802.11 Working Group Reflector ---

Hi Gaurang,

 

Could you please help me queue this for presentation? I’ll upload it as soon as it’s ready.


09-Jul-2026 ET
2026
1391
0
AI Offload SG
AI offload framework
Duncan Ho (Qualcomm Technologies, Inc)

Thanks,

Duncan



To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1




To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1