RTA Session Management in WLAN Traffic Streams
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current wireless communication systems using CSMA/CA protocols fail to provide low latency for real-time applications (RTAs) while maintaining high throughput for non-real-time traffic, as they do not adequately differentiate between RTA and non-RTA packets, leading to insufficient support for RTA sessions.
Innovation Solution
The proposed solution enhances IEEE 802.11 protocols by adding additional information exchange during the Traffic Stream (TS) setup procedure to represent RTA sessions, allowing STA to identify and schedule RTA packet transmissions to meet Quality-of-Service (QoS) requirements, thereby supporting coexistence of real-time and non-real-time traffic within the same network.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If CSMA/CA protocol is used for wireless communication, then high throughput is achieved, but low latency capability is not provided
Solution Approach 1:
The patent segments traffic into RTA packets and non-RTA packets, applying different handling mechanisms to each type. RTA packets are identified and scheduled separately to ensure low latency, while non-RTA packets continue to use standard CSMA/CA for high throughput, thus resolving the contradiction between throughput and latency.
Solution Approach 2:
The patent introduces dynamic traffic classification and scheduling mechanisms that adaptively identify RTA packets and apply appropriate QoS policies. This dynamic approach allows the system to prioritize time-sensitive traffic while maintaining efficient handling of non-time-sensitive traffic, balancing throughput and latency requirements.
2Loss of time
If RTA packets are prioritized for low latency, then RTA QoS is improved, but non-RTA traffic throughput may be affected
Solution Approach 1:
The patent applies local quality by implementing traffic-specific handling rules. RTA packets receive specialized priority scheduling and QoS treatment, while non-RTA packets continue to use standard best-effort delivery. This localized differentiation ensures RTA latency requirements are met without unnecessarily impacting non-RTA traffic throughput.
Solution Approach 2:
The patent introduces an intermediary traffic classification and scheduling mechanism that sits between the network layer and data link layer. This intermediary identifies RTA packets, applies appropriate QoS policies, and schedules them separately, thereby protecting RTA latency performance while leaving non-RTA traffic flow unaffected.
3Reliability
If Traffic Stream (TS) operation is used to manage packets, then QoS support is provided, but RTA session representation is not possible
Solution Approach 1:
The patent extends the existing TS operation to serve multiple purposes. By adding RTA session identification fields and parameters to the TS framework, the system can simultaneously support both traditional QoS traffic streams and RTA sessions, making the TS mechanism universal enough to handle diverse traffic requirements including real-time applications.
Solution Approach 2:
The patent implements preliminary action by pre-configuring RTA session parameters and QoS policies during TS setup. The RTA session identification and scheduling rules are established in advance, enabling the system to automatically recognize and prioritize RTA packets without requiring real-time decision-making, thus achieving both QoS reliability and RTA session adaptability.
Data Source
AI summary
A wireless local area network (WLAN) station and protocol configured to support communicating real-time application (RTA) packets that are sensitive to communication delays as well as non-real time packets over a network supporting within traffic stream (TS) operations in which real time application (RTA) traffic and non-RTA traffic coexist. Stations can request establishing a traffic stream from neighboring stations, which can accept or deny the TS for the RTA stream. Additional information can be passed in requesting the stream or by the responder for denying the stream.