OT Wireless
Search/Menu

Search the field guide, causes, requirements, and glossary

Missing or broken QoS marking

Wi-Fi can only favor control traffic it can recognize, and a marking that is never set, gets stripped, or maps to the wrong access category leaves your I/O queued with everything else.

Ben RutterIndustrial network engineer
On this page5 sections
  1. How it presents
  2. Why it happens
  3. How to confirm it
  4. The fix
  5. Prevent it at design time

Is this your problem? It presents like this

  • Control traffic suffers whenever other traffic rises, even though utilization is not extreme.
  • The problem appeared after a VLAN, SSID, controller, or firmware change.
  • One device model or supplier is worse than others on the same network.
  • Captures show control frames in the best effort access category.
  • Latency tails grow during busy periods while average latency looks fine.
Not sure?
Rank the likely causes from your symptoms

Why it happens

Wi-Fi prioritization runs on a three-bit label. WMM sorts frames into four access categories, voice, video, best effort, and background, each with its own contention timers. The access point picks the category from the frame’s user priority, and many access points derive that priority from the IP DSCP by taking its three most significant bits. That default misfiles traffic: the IETF points out that Expedited Forwarding voice lands in the video category instead of voice.

Industrial devices mark by their own scheme, if they mark at all. The EtherNet/IP QoS object defaults to DSCP 55, 47, 43, 31, and 271 for urgent, scheduled, high, and low priority traffic and explicit messages. A vendor design guide for EtherNet/IP over wireless maps I/O and safety I/O to the video queue and messaging to best effort, and warns that devices have to support QoS and mark correctly for the scheme to work. An unmarked packet rides in best effort.

Marking also breaks in the middle of the path. The same guide notes that applying a VLAN to a radio interface removes the default QoS policy, with significant degradation for I/O and CIP Safety until it is reapplied, and that the WLAN QoS level sets the maximum for traffic through the controller. Upstream, the IETF says to trust DSCP rather than the client’s user priority, because six bits rebuilt from three lose information. Even with every hop right, Wi-Fi priority is a better chance, not a guarantee. Without the marking, your control traffic does not even get the better chance.

Prioritization improves the odds; it does not reserve the channel

Each access category waits a fixed time, then a random one. The ranges overlap, so a lower category sometimes goes first.

Drawn to scale

VoiceAC_VO, 2 to 5 slotsVideoAC_VI, 2 to 9 slotsBest effortAC_BE, 3 to 18 slotsBackgroundAC_BK, 7 to 22 slots024681012141618202224slot times after the medium goes idlefixed wait (AIFSN)random backoff

Default parameters for the first attempt, drawn to scale. A best-effort frame that draws a short backoff (from 3 slots) can beat a video frame that draws a long one (up to 9), which is why 802.11 cannot promise strict priority or a minimum bandwidth to any category. Each failed attempt doubles the window, up to its maximum.

Source: RFC 8325, Figures 3 and 4, which reproduce the IEEE 802.11-2016 defaults.

How to confirm it

  1. Capture over the air and check the WMM access category of control frames in both directions.
  2. Capture on the wired side and check the DSCP value at each hop, from the device to the access point or controller and back.
  3. Check whether the end devices mark their traffic at all. Some ship with marking off.
  4. Check the access point or controller QoS policy, including what it trusts, how it maps DSCP to user priority, and any ceiling the WLAN profile applies.
  5. Check whether a VLAN or SSID change removed the QoS policy from a radio interface.

The fix

  • Enable QoS marking on the end devices and confirm the values on the wire.
  • Map DSCP to user priority explicitly at the access point instead of relying on the default three-bit mapping.
  • Set the WLAN QoS profile so it does not cap control traffic below the class it needs.
  • Reapply QoS policies after VLAN or SSID changes, and verify with a capture.
  • Mark bulk traffic down so control traffic does not compete with it in the same category.

Prevent it at design time

  • Write an end-to-end marking plan that states how each traffic class is marked, where marking is trusted, and how it maps to WMM.
  • Verify the plan with captures at commissioning and after every network change.
  • Require device suppliers to document their default markings.

Related causes

Terms on this page

About this page

Built from 4 sources: 1 standards body or lab, 1 protocol owner or alliance and 2 vendor documents. Researched and drafted with AI assistance, then reviewed and approved by Ben Rutter on . How pages are made

First published
Last updated
Change history (1)
  • First published
Cite this page

Plain

Ben Rutter. "Missing or broken QoS marking." OT Wireless, published October 5, 2026. https://otwireless.com/causes/missing-qos-marking/

APA 7

Rutter, B. (2026, October 5). Missing or broken QoS marking. OT Wireless. https://otwireless.com/causes/missing-qos-marking/

BibTeX

@misc{rutter2026missingqosmarking,
  author = {Rutter, Ben},
  title = {{Missing or broken QoS marking}},
  year = {2026},
  howpublished = {\url{https://otwireless.com/causes/missing-qos-marking/}},
  organization = {OT Wireless},
}