Application-Aware Scheduling via Protocol Exchange

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Legacy wireless communication networks lack mechanisms for user equipment (UE) to inform network nodes of application requirements, leading to indifferent handling of internet data and radio capabilities, which limits network performance.

Innovation Solution

A framework for protocol operations that enables application-aware scheduling by allowing UE and network nodes to exchange information about supported protocols, software versions, and capabilities, using extended protocols to establish customized connections that differentiate between instantaneous latency and throughput demands of applications and available network resources.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If legacy policies handle all internet data merged onto the default bearer with the same scheduling, then network operation simplicity is maintained, but application performance differentiation is lost

Engineering Contradiction:
Improvenetwork operation simplicityVSAvoidapplication performance
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent segments the default bearer into multiple radio bearers, each dedicated to specific application types or QoS requirements. This allows differentiated scheduling policies for different applications while maintaining a unified default bearer structure, resolving the contradiction between operational simplicity and performance differentiation.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies local quality by assigning specific scheduling policies and radio bearer configurations to different application types or QoS flows within the network. This enables tailored performance optimization for specific applications (e.g., low latency for voice, high throughput for video) while keeping the overall network structure simple.

Inventive Principle:
Principle #3Local quality

2Ease of operation

If application providers use the same end-to-end transport control for all transactions, then transport simplicity is maintained, but radio capability requirements are not considered

Engineering Contradiction:
Improvetransport simplicityVSAvoidradio capability adaptability
Core Design Contradiction:
Ease of operationVSAdaptability or versatility

Solution Approach 1:

The patent introduces dynamic adaptation mechanisms that allow the transport layer to adjust radio bearer selection and configuration based on real-time radio conditions and application requirements. This enables the system to adapt to varying radio capabilities while maintaining a unified transport control framework.

Inventive Principle:
Principle #15Dynamics

3Device complexity

If network nodes lack visibility into application requirements, then network complexity is reduced, but scheduling optimization is limited

Engineering Contradiction:
Improvenetwork node complexityVSAvoidnetwork throughput
Core Design Contradiction:
Device complexityVSProductivity

Solution Approach 1:

The patent implements feedback mechanisms where UEs report application requirements and QoS parameters to network nodes, and network nodes adjust radio bearer configurations based on this feedback. This enables optimized scheduling and resource allocation without requiring complex application awareness at every network node, balancing complexity and throughput.

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP3855777B1Announcement for application aware scheduling
Publication Date: 2023.12.06 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • EP3855777B1 patent drawingFigure 1~3
  • EP3855777B1 patent drawingFigure 4~6
  • EP3855777B1 patent drawingFigure 7A

AI summary

Methods and devices for announcement messages for application aware scheduling in a wireless communication network include receiving, from the network node, an RRC Connection Reconfiguration message including an announcement message indicating a Network Type and Software Version Number, N-TSVN for an extended protocol. It may be determined that a UE Software Version Number, UE-SVN, is compatible with the N-TSVN received in the announcement message. The UE may transmit to the network node, an initial message including the UE-SVN, in response to the determining that the UE-SVN is compatible with the N-TSVN