Service-Aware Overload Handling in Communication Networks

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing communication network throttling mechanisms fail to differentiate between overloaded and non-overloaded application servers, leading to unsatisfactory service availability and user experience when multiple services share the same SIP method, causing unnecessary rejection of requests for services not experiencing overload.

Innovation Solution

Implementing a service-aware throttling mechanism that determines the presence of overload for specific services within the communication network, allowing nodes to forward requests for non-overloaded services while responding with failure messages indicating a retry time window and service identifier for overloaded services, enabling differentiated handling of SIP requests.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a generic SIP method-level throttling mechanism is used, then overload protection is provided for the SIP server, but requests for non-overloaded services are unnecessarily rejected

Engineering Contradiction:
Improveoverload protectionVSAvoidservice availability
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent segments the throttling mechanism from the generic SIP method level to the specific service level. Instead of applying a single throttling window to all services using the same SIP method, the system creates separate throttling windows for each service (e.g., MMTel service, RCS group chat service). This allows independent overload control for each service, preventing the rejection of requests for non-overloaded services while still protecting overloaded ones.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements local quality by making the throttling behavior service-specific rather than uniform across all services. Each service receives customized throttling treatment based on its own overload status. The proxy node determines overload conditions individually for each service and applies appropriate throttling only where needed, rather than applying a blanket throttling mechanism to all services using the same SIP method.

Inventive Principle:
Principle #3Local quality

2Productivity

If a service-specific overload detection mechanism is implemented, then service availability is improved for non-overloaded services, but device complexity increases

Engineering Contradiction:
Improveservice availabilityVSAvoidthrottling mechanism complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent achieves universality by making the proxy node multi-functional. The same proxy node that performs generic SIP message routing also performs service-specific overload detection and throttling control. By integrating multiple functions (SIP routing, service identification, overload detection, and service-specific throttling) into a single node, the system avoids the need for separate complex systems while still achieving fine-grained service-level control.

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

Solution Approach 2:

The system implements self-service by enabling the proxy node to autonomously determine service-specific overload conditions and apply appropriate throttling without external intervention. The proxy node itself performs the overload detection for each service and makes decisions about request forwarding or rejection based on service-specific thresholds, eliminating the need for external centralized control mechanisms.

Inventive Principle:
Principle #25Self-service

Data Source

PatentEP3238400B1Service aware overload handling in a communication network
Publication Date: 2020.06.10 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • EP3238400B1 patent drawingFigure 1
  • EP3238400B1 patent drawingFigure 2
  • EP3238400B1 patent drawingFigure 3

AI summary

A node (100) of a communication network receives a request (101) relating to one of multiple services. Further, the node (100) determines whether an overload with respect to the service is present. In response to determining absence of an overload with respect to the service, the node (100) forwards the request (101) for further processing. In response to determining presence of an overload with respect to the service, the node (100) responds to the request with a failure message (102) indicating that the request was not processed. The failure message (102) comprises an indication of a time window after which the request (101) may be retried and an identifier of the service to which the request (101) relates.