November 2022 doc.: IEEE 802.

11-22/1926r0

Challenges to achieve deterministic low latency in next

generation 802.11
Date: 2022-11-14
Authors:

Submission Slide 1 Intel Corporation

November 2022 doc.: IEEE 802.11-22/1926r0

Introduction
• The need for deterministic (highly reliable) low latency and high
throughput will only grow for consumer and autonomous applications
• AR/VR/XR, remote work, factory/process automation, robotics, audio/video, …
• Wi-Fi (802.11) needs to support these plus typical IT applications in a converged network
• On the other hand serving deterministic traffic also impacts network’s
ability to serve other traffic. 
• This presentation focuses on challenges and directions to address the low
latency requirements of deterministic traffic in next generation 802.11 by
exploiting the known traffic characteristics and scheduling requirements. 

Submission Slide 2 Intel Corporation

 November 2022 doc.: IEEE 802.11-22/1926r0

Applications that need deterministic ultra-low latency

typically have a cyclic behavior
Extended Reality
Isochronous Industrial Control
Control Edge

“Actuation” “Sensing”
Sensing Actuation

C Client

Motion to Photon
Cycle

Rendering
HMD state Video

Latency bound for

communication

Control Cycle: sensing (I/O input), computing (control algorithm) and actuation (I/O output) Motion to Photon Cycle: user tracking, computing (rendering) and display

Submission Slide 3 Intel Corporation

 November 2022 doc.: IEEE 802.11-22/1926r0

Traffic Patterns and Channel Access Requirements

Very frequent periodic channel access for small
data
“Sensing”
(Tracking)
2 msec

“Actuation”
(Display) Periodic channel access for large data volumes
10 msec

• We already have tools for improving channel access for predictable traffic like
• Explicit triggering (SU or MU)
• SP reservation (e.g. rTWT/TWT or similar). Moreover, an AP-controlled SP assume triggered access for better efficiency. 

• In some scenarios the OTA overhead is too high or prohibitive to meet QoS requirements even with the existing mechanisms (see
next slides), e.g.
• Increased number of channel access attempts because of medium fragmentation caused by frequent r-TWT SPs may
increase overall OTA overhead
• Hence, there is a need to improve signaling and efficient use of allocated resources
Submission Slide 4 Intel Corporation
 November 2022 doc.: IEEE 802.11-22/1926r0

State of the Art: Scheduled access with 802.11ax/be

Periodic Data
256 Bytes • OTA overhead is comparable with the actual data transmission time, e.g.
… 2ms … • ~60%, 256B and 20Mhz @MCS8
• ~80%, 256B and 80Mhz @MCS8
• ~40%, 10Kb and 80Mhz @MCS8
UL MU PPDU

• Repetitive channel access cycles can be used to serve both latency sensitive
TF BA and non-latency sensitive traffic
…

SIFS SIFS • Overhead prevents shorter cycles and/or leaves less time to serve other traffic
128µs 16µs 298 µs*
16µs 200µs
(53 µs PHY preamble)

658 µs
• Major sources of overhead:
• Resource allocation (TF and DL MU PPDUs)
Overhead
• Block ack
*256 Bytes at MSC 8, 20 MHz channel, 802.11ax
• PHY Preambles
Submission Slide 5 Intel Corporation
 November 2022 doc.: IEEE 802.11-22/1926r0

Enterprise XR Scenario Simulation Scenario

Video Conf. Display
Traffic parameters
Source/Destination Interarrival
8 video conf. Num of links Size, bytes
audio users description time ms
Camera, UL, sc. update, 20Mbps 4 25000 10
AR/VR DL, video, 50Mbps 4 62000 10
AR/VR UL, IMU/tracking 4 100 2
Camera
AR/VR Audio, DL/UL 4/4 1000 30
Conf DL/UL Audio 8/8 50 20
Holographic/shared
Conf. Video DL/UL, 20Mbps 1/1 40000 16
AR/VR user
view per user
2ms

TF + UL Camera + BA
XR + Video + Voice + BA
TF + XR IMU+ voice + BA

TF + XR IMU + BA
TF +XR IMU + BA

TF +XR IMU + BA
TF + XR IMU

DL Conf Video +

Display + BA
Voice + BA
• Model frame exchanges between STAs and AP using
baseline .11be (single link) signaling
time

• For a given bandwidth configuration an optimal RU allocation is UL DL UL UL UL DL UL DL UL

used for OFDMA type transmission to minimize number of frame TXOP sequence duration defined by 2ms IMU traffic pattern
exchanges

Submission Slide 6 Intel Corporation

November 2022 doc.: IEEE 802.11-22/1926r0

Performance evaluation – Enterprise XR scenario

• With 160Mhz there is no room to
support any other traffic or to support
for possible recovery

• The reduction of overhead translates

of 10 ms into about >1.5ms of free
time that can potentially be used
• to lower data MCS for improved
(MCS5 can be used) reliability
• as an opportunity to transmit some
other data

• Can enable the use case using lower

bandwidth (80MHz) which is
impossible with baseline signaling

Each bar represent time necessary to deliver all buffered data for a given traffic stream assuming 1 ms TXOP

Throughput during free times: throughput using SU DL PPDU @ MCS7 during times left after serving all other scheduled traffic
Submission Slide 7 Intel Corporation
 November 2022 doc.: IEEE 802.11-22/1926r0

Factory scenario
Factory Scenario

Traffic parameters
Interarrival time
Source/Destination description # of links Frame size, bytes
Camera (ms)
15 Controllers .
.
PLC, UL 15 50 1
.

Camera UL 6 1500 2
Robot control, DL 6 50 2
Worker ArVr DL 2 25000 10
Robot Mobile Robot
ArVr IMU control, UL 2 50 2
1ms Possible medium access pattern

TF + PLC + Sync + BA

TF + PLC + Sync + BA
TF + Camera + BA

TF + PLC + Sync + BA
TF + PLC + AR + BA

TF + PLC + AR + BA
AR/VR Safety Heartbeat
Worker

Robot + BA

ARVr + BA

ARVr + BA
time

UL UL UL DL UL DL UL DL UL
This scenario is a compilation of use cases and requirements for 5G and Wi-Fi:
https://avnu.org/wirelessTSN/
https://5g-acia.org/whitepapers/5g-quality-of-service-for-industrial-automation/ TXOP duration/sequence duration defined by 1ms PLC traffic pattern
Submission Slide 8 Intel Corporation
 November 2022 doc.: IEEE 802.11-22/1926r0

Performance evaluation – Factory case

• In presence of small, frequently
arriving packets, the OTA overhead
consume almost all available time
• 256bytes payload is almost MCS independent as

• The reduction of triggering overhead

translates over a period of 10 ms into
about >4ms of free time that can
potentially be used
• To lower data MCS4 vs MCS8 for
improved reliability 
• as an opportunity to transmit
some other data

Submission Slide 9 Intel Corporation

Each bar represent time necessary to deliver all buffered data for a given traffic stream assuming 1 ms TXOP
April 2022 doc.: IEEE 802.11-22/1926r0

Conclusion

• There is a clear need to improve reliability and latency for many applications
• While existing tools enable better control of channel access (i.e. OFDMA TF/
SP allocations/SCS ), they do not take full advantage of known scheduling
requirements from applications, resulting in efficiency/capacity loss for the
overall network
• For example, an AP can use low overhead TF when serving application with known
characteristics (i.e. use same pre-negotiated resources)

Submission Slide 10 Intel Corporation

November 2022 doc.: IEEE 802.11-22/1926r0

BACKUP

Submission Slide 11 Intel Corporation

November 2022 doc.: IEEE 802.11-22/1926r0

Time-Sensitive Applications Requirements

Immersive Industrial IOT

Environments, XR,
xVerse

Traffic Profile Cyclic/Video streaming Isochronous, Cyclic and Events

and Events

Throughput 10 to 10000 Mbps Typically, low throughput with

Downlink (Depending on small packets
video encoding) (<1 – 10 Mbps)
< 1Mbps Uplink (cyclic)

Bounded 10 – 1msec (cyclic) 0.1 – 10 ms (isochronous/cyclic)

Latency 100 – 10 msec (events) 1 – 100 ms (events)

Reliability 99.9 to 99.99% 99.9 to 99.9999%

Security Authentication, integrity, Auth., integrity, and resilience to

and resilience to DOS, time/QoS attacks, safety
DOS/Interference requirements

Power Battery powered clients Mains and battery powered clients

References:
https://avnu.org/wirelessTSN/
https://5g-acia.org/whitepapers/5g-quality-of-service-for-industrial-automation/
Submission Slide 12 Intel Corporation
Jan 2019 doc.: IEEE 802.11-19-0065r6

Use
Use cases
cases and requirements
Intra BSS Jitter
(examples)
Packet loss Data rate/
latency/ms variance/ms Mbps
[4]
Real-time gaming [2] <5 <2 < 0.1 % <1
Cloud gaming [15] < 10 <2 Near-lossless <0.1 (Reverse
[1]

link) >5Mbps
(Forward
link)

Real-time video [3] < 3 ~ 10 < 1~ 2.5 Near-lossless 100 ~ 28,000

Robotics and Equipment control < 1 ~ 10 < 0.2~2 Near-lossless <1
industrial
automation [1] Human safety < 1~ 10 < 0.2 ~ 2 Near-lossless <1
Haptic technology <1~5 <0.2~2 Lossless <1
Drone control <100 <10 Lossless <1
>100 with
video

The main issue is worst-case latency

Real-time applications need both low latency and low jitter
Higher reliability is also an important new requirement
Submission Slide 13 Kate Meng (Tencent)
 November 2022 doc.: IEEE 802.11-22/1926r0

Performance evaluation – Enterprise XR scenario

8 XR and Camera clients

• With 160Mhz there is no room to

support any other traffic or to
support for possible recovery; require
high MCS which lower reliability

• The reduction of overhead over a

period of 10 ms translates into about
>1ms of free time
• lower MCS can be used (MCS7
vs MCS11 for 160Mhz) or
MCS4 vs MCS5 for 320Mhz

• opportunity to transmit some

other data

Each bar represent time necessary to deliver all buffered data for a given traffic stream assuming 2 ms TXOP
Submission Slide 14
 November 2022 doc.: IEEE 802.11-22/1926r0

Performance evaluation – Factory case

PCL interarrival 500us
• Baseline signaling make hard to
support scenarios with traffic streams
that require channel access at sub-
millisecond periodicity;
• Require extreme configuration (i.e.
high MCS and wide band) to support
this traffic configuration
• Optimization is necessary to enable
such use cases starting with 80Mhz
channel width

Each bar represent time necessary to deliver all buffered data for a given traffic stream assuming 2 ms TXOP
Submission Slide 15
November 2022 doc.: IEEE 802.11-22/1926r0

Backoff
Frame Second
exchange frame
finishes exchange
before start with same
of next r- allocation R-TWT SP
R-TWT SP start
TWT SP
start

If r-TWT SPs are scheduled more frequently (potentially incl r-TWT SPs of OBSS
in same channel), STAs (incl. APs) respecting start of those SPs would need to stop
their non-LL frame exchanges frequently as well; also SP length could be smaller
=> Ctrl overhead may be high.

Submission Slide 16 Intel Corporation