Dynamic Generic QoS Parameter for Network Slice Selection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current network slice selection methods based on Application ID and Service Descriptor are not generic, sustainable, and fail to consider latency and jitter effectively, leading to suboptimal resource allocation and interoperability issues between different operators' networks.

Innovation Solution

The introduction of a dynamic generic QoS/SLA parameter (DGQ) allows user equipment (UE) to specify QoS/SLA requirements directly to the network, enabling the network to allocate resources optimally and independently or cooperatively across different slices and operators, considering latency, jitter, and other performance metrics.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If network slice selection is based on Application ID and Service Descriptor, then the network can identify and route specific applications, but the network complexity increases as every new Application ID and Service descriptor must be recognized and evaluated by the network

Engineering Contradiction:
ImproveApplication identification capabilityVSAvoidNetwork evaluation complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent extracts the QoS parameter requirements from the application layer and places them at the network layer through the DGQ parameter. Instead of the network evaluating application-specific descriptors, the UE extracts and signals only the essential QoS requirements (latency, jitter, bandwidth) that the network needs for slice selection, simplifying network processing while maintaining application identification capability

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent inverts the traditional approach by having the UE (user equipment) determine and signal QoS requirements rather than the network determining slice type based on application descriptors. This inversion shifts the intelligence from network to UE, reducing network complexity while improving adaptability through direct QoS-based slice selection

Inventive Principle:
Principle #13The other way round (Inversion)

2Reliability

If standardized Application IDs and Service descriptors are agreed upon, then interoperability between operators is improved, but the flexibility to support new applications and services is reduced

Engineering Contradiction:
ImproveNetwork interoperabilityVSAvoidService deployment flexibility
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The DGQ parameter serves as a universal mechanism that can accommodate any application type and QoS requirement combination. Instead of creating standardized descriptors for each application, the universal DGQ framework allows any application to specify its requirements dynamically, achieving both interoperability through standardized parameter structure and flexibility through arbitrary parameter values

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent introduces dynamic QoS parameter signaling that allows applications to adapt their requirements in real-time. The DGQ parameter enables dynamic adjustment of latency, jitter, and bandwidth requirements based on current service conditions, allowing the network to dynamically select appropriate slices rather than relying on static standardized descriptors

Inventive Principle:
Principle #15Dynamics

3Measurement precision

If the network evaluates each new Application ID and Service descriptor combination, then accurate slice selection is achieved, but latency increases due to the evaluation process

Engineering Contradiction:
ImproveSlice selection accuracyVSAvoidSlice selection latency
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The patent applies preliminary action by having the UE determine and signal QoS requirements before the network performs slice selection. The UE preliminarily analyzes its application's needs and encodes them in the DGQ parameter, so the network receives pre-processed information that requires minimal evaluation, reducing slice selection latency while maintaining accuracy

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent changes the parameter representation from complex Application ID and Service Descriptor combinations to simplified QoS parameter tuples (latency, jitter, bandwidth). This parameter transformation reduces the evaluation space for the network, allowing faster and equally accurate slice selection based on fundamental QoS metrics rather than complex application semantics

Inventive Principle:
Principle #35Parameter changes

4Ease of manufacture

If predefined slice types are used for different applications, then resource allocation is simplified, but the ability to meet specific service requirements is reduced

Engineering Contradiction:
ImproveResource allocation simplicityVSAvoidService requirement fulfillment
Core Design Contradiction:
Ease of manufactureVSReliability

Solution Approach 1:

The patent applies local quality by allowing different QoS parameter combinations to be applied to different parts of the resource allocation process. Instead of one-size-fits-all predefined slices, the DGQ parameter enables local optimization where specific latency, jitter, and bandwidth requirements are matched to specific slice characteristics, ensuring each service receives appropriately tailored resources

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent introduces dynamic resource allocation where slice selection is determined by real-time QoS requirements rather than static predefined mappings. The DGQ parameter enables the system to dynamically adapt resource allocation to current service needs, allowing the network to transition from rigid predefined slices to flexible on-demand slice selection that fulfills specific service requirements

Inventive Principle:
Principle #15Dynamics

Data Source

PatentEP3577982B1Sustainable service selection
Publication Date: 2021.07.14 NOKIA SOLUTIONS & NETWORKS OY
  • EP3577982B1 patent drawingFigure 1
  • EP3577982B1 patent drawingFigure 2
  • EP3577982B1 patent drawingFigure 3~6

AI summary

It is provided a method, comprising requesting a resource for a service from a network, wherein the request includes a requirement indication indicating a requirement to the resource to be fulfilled for the service.