Specialized Flow QoS for Latency-Sensitive Network Traffic

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current telecommunications networks fail to provide guaranteed low-latency connections for latency-sensitive traffic, such as multiplayer gaming or remote healthcare, as they often route such traffic with non-latency-sensitive data, resulting in suboptimal performance.

Innovation Solution

The system creates specialized flows with specific Quality of Service (QoS) parameters to prioritize low-latency traffic, allowing terminals to request and manage these flows for improved communication latency, using techniques like flow management, bearer creation, and QoS assignment within the network.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If standard network routing is used for all traffic, then network infrastructure complexity is reduced, but latency-sensitive applications experience poor performance

Engineering Contradiction:
Improveperformance reliability for latency-sensitive applicationsVSAvoidnetwork flow management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments network traffic into different flow types (latency-sensitive and non-latency-sensitive) and routes them through different network paths. The network device creates specialized flows with specific QoS parameters for latency-sensitive traffic while using standard routing for other traffic, thereby improving performance reliability without requiring complete network restructuring.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies different quality characteristics to different portions of network traffic. Latency-sensitive traffic receives specialized QoS treatment with prioritized handling, while non-latency-sensitive traffic uses standard routing. This local differentiation improves overall system performance without requiring all network components to be complex.

Inventive Principle:
Principle #3Local quality

2Loss of time

If specialized flows with QoS parameters are created for latency-sensitive traffic, then communication latency is reduced, but network resource allocation complexity increases

Engineering Contradiction:
Improvecommunication latencyVSAvoidflow creation and management complexity
Core Design Contradiction:
Loss of timeVSDevice complexity

Solution Approach 1:

The network device performs preliminary actions by pre-configuring specialized flows with appropriate QoS parameters before latency-sensitive traffic arrives. The flow creation process includes pre-defining latency thresholds, priority levels, and routing parameters, so that when traffic needs to be routed, the path is already prepared and optimization occurs without real-time complexity.

Inventive Principle:
Principle #10Preliminary action

3Ease of operation

If all traffic is routed through the same network path, then network configuration is simplified, but latency-sensitive applications cannot achieve guaranteed low-latency performance

Engineering Contradiction:
Improvenetwork configuration simplicityVSAvoidlatency guarantee for specialized applications
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent segments traffic routing into standard paths and specialized low-latency paths. The network device identifies latency-sensitive traffic and directs it through specialized flows with predetermined QoS characteristics, while other traffic continues using standard routing. This segmentation provides latency guarantees for critical applications while maintaining overall network configuration simplicity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies different routing quality characteristics to different traffic portions. Specialized flows receive local optimization with specific QoS parameters (priority, latency thresholds, routing preferences) only where needed, while the majority of network infrastructure continues operating with standard configuration, thereby maintaining ease of operation for non-critical traffic.

Inventive Principle:
Principle #3Local quality

4Adaptability or versatility

If multiple specialized flows are created for different applications, then service differentiation is improved, but network control complexity increases

Engineering Contradiction:
Improveservice differentiation capabilityVSAvoidflow management and authorization complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The network device implements self-service mechanisms where flows automatically manage their own QoS parameters and routing decisions based on pre-configured policies. The system performs self-authorization and self-management of specialized flows, reducing the need for complex external control mechanisms while maintaining service differentiation capability.

Inventive Principle:
Principle #25Self-service

Data Source

PatentEP3909291B1QOS for latency-sensitive network-traffic flows
Publication Date: 2023.10.11 T MOBILE US INC
  • EP3909291B1 patent drawingFigure 1
  • EP3909291B1 patent drawingFigure 2
  • EP3909291B1 patent drawingFigure 3

AI summary

A telecommunication system can include routing devices, a Quality of Service (QoS) controller, a policy-management device, and a flow-management device. The QoS controller or flow-management device can receive a request from a terminal to create a specialized flow (SF), e.g., for a non-audio, non-video media type. If the request is associated with an authorized user, a setup message can be sent comprising a QoS indicator. The system can create the SF permitting data exchange between the terminal and a routing device. The SF can have QoS characteristics associated with the QoS indicator. In some examples, the terminal can receive network-address information, determine an associated network resource, and send a flow-request message indicating a non-audio, non-video media type. The terminal can then exchange data on the network port with a peer network terminal.