Wi-Fi Stream Classification for Low-Latency Traffic Preemption
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing Wi-Fi standards lack mechanisms for signaling low latency and preemption requirements for event-based traffic flows, which are crucial for supporting applications like cloud gaming and industrial IoT.
Innovation Solution
Implementing Stream Classification Service (SCS) enhancements that allow STAs to register low latency and preemption requirements for event-based traffic, using enhanced QoS elements to manage traffic flows and enable preemption when necessary.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If existing Wi-Fi standards are used without SCS enhancements, then device compatibility and standard simplicity are maintained, but low latency and preemption requirements for event-based traffic cannot be signaled or managed
Solution Approach 1:
The patent segments the QoS management by introducing a dedicated Stream Classification Service (SCS) request mechanism that separates event-based traffic handling from regular traffic. The SCS request contains specific fields for low latency requirements and preemption indicators, allowing the AP to process these requirements independently through policy-based decisions without complicating the entire Wi-Fi protocol stack.
Solution Approach 2:
The patent implements preliminary action by requiring STAs to register their low latency and preemption requirements with the AP through SCS requests before event-based traffic flows are established. This advance registration allows the AP to pre-configure QoS policies and preemption rules, ensuring that when event-based traffic actually occurs, the AP can immediately apply the appropriate handling without real-time negotiation overhead.
2Loss of time
If preemption mechanisms are implemented for event-based traffic, then low latency requirements can be met, but network complexity and policy management overhead increase
Solution Approach 1:
The patent reduces real-time preemption complexity by requiring STAs to register their preemption requirements in advance through SCS requests. The AP uses these pre-registered requirements to make policy-based decisions about preemption eligibility, avoiding complex real-time negotiations when actual preemption is needed.
Solution Approach 2:
The patent implements a lightweight preemption indication mechanism where the SCS request contains a simple boolean preemption indicator and latency requirement fields. These are disposable registration messages that enable complex preemption behavior without requiring persistent complex state management. The AP makes discrete policy decisions based on these simple indicators rather than maintaining complex ongoing negotiations.
3Adaptability or versatility
If QoS elements are enhanced to include preemption requirements, then traffic flow management capability improves, but protocol complexity and processing overhead increase
Solution Approach 1:
The patent segments QoS management by introducing a dedicated SCS request mechanism with specific fields for event-based traffic requirements. Rather than enhancing all QoS elements throughout the protocol stack, the complexity is isolated to the SCS registration phase, where structured fields for low latency requirements and preemption indicators are defined.
Solution Approach 2:
The patent reduces ongoing protocol complexity by moving QoS parameter negotiation to the preliminary SCS request phase. Once registered, the AP stores these requirements and uses them for automatic policy-based decisions, eliminating the need for continuous complex QoS negotiations for each event-based traffic flow.
Data Source
AI summary
Aspects of the present disclosure are directed to receiving, at an access point (AP) from an endpoint, a stream classification service (SCS) request. The SCS request identifies one or more of QoS characteristics and preemption requirements for a traffic flow originating from the endpoint. The method includes determining, by the AP and based on a policy, whether the AP can accept the SCS request for the traffic flow, and transmitting, by the AP and to the endpoint, an SCS response indicating whether the AP can accept the SCS request for the traffic flow or not.