Front-End Node Dynamic Preference Routing for UDC Failover

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing data communication methods in UDC architectures face challenges with failover and data consistency when caching user data, as they either ensure consistent data by steering requests to the same Front-End, preventing failover, or allow failover but risk data consistency in caches.

Innovation Solution

Introducing dynamic preference routing in the Diameter protocol, where Front-Ends inform other entities about user data updates and caching status, enabling both caching and failover by indicating preferred and alternative servers for subsequent requests.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Manufacturing precision

If requests are steered to the same Front-End to ensure consistent data in cache, then data consistency is improved, but failover capability deteriorates

Engineering Contradiction:
Improvedata consistencyVSAvoidfailover capability
Core Design Contradiction:
Manufacturing precisionVSReliability

Solution Approach 1:

The patent applies dynamics by making the Front-End selection dynamic rather than static. The load balancer dynamically selects different Front-Ends based on real-time availability status received from Front-End indicators. This allows the system to adapt between ensuring data consistency (by routing to the same Front-End when available) and enabling failover (by routing to alternative Front-Ends when needed), thus resolving the contradiction between data consistency and failover capability.

Inventive Principle:
Principle #15Dynamics

2Speed

If caching is enabled to reduce latency, then response speed is improved, but data obsolescence risk increases

Engineering Contradiction:
Improveresponse speedVSAvoiddata obsolescence
Core Design Contradiction:
SpeedVSLoss of information

Solution Approach 1:

The patent implements feedback through Front-End indicators that continuously provide availability status information to the load balancer. This feedback mechanism allows the load balancer to make informed routing decisions - directing requests to cached data when the original Front-End is available, and switching to alternative Front-Ends when the original is unavailable, thus maintaining data freshness while preserving caching benefits for speed.

Inventive Principle:
Principle #23Feedback

3Productivity

If load balancing distributes traffic equally among Front-Ends, then resource utilization is improved, but data consistency in cache deteriorates

Engineering Contradiction:
Improveresource utilizationVSAvoiddata consistency
Core Design Contradiction:
ProductivityVSManufacturing precision

Solution Approach 1:

The patent transforms static equal load distribution into dynamic load distribution based on Front-End availability. The load balancer uses real-time availability information from Front-End indicators to intelligently distribute traffic - maintaining data consistency by routing to the original Front-End when possible, while still achieving good resource utilization by distributing to alternative Front-Ends when needed, thus resolving the contradiction between resource utilization and data consistency.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentEP3688963B1First front-end node, client node, load balancer node, and methods performed thereby, for supporting data communication
Publication Date: 2024.09.04 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • EP3688963B1 patent drawingFigure 1
  • EP3688963B1 patent drawingFigure 1
  • EP3688963B1 patent drawingFigure 2

AI summary

Method, performed by a first front-end node (111), for supporting data communication. The first front-end node (111) operates in a communications network (100) comprising a pool of front-end nodes (110) for providing access to a database (120). The pool of front-end nodes (110) comprises the first front-end node (111). The first front-end node (111) receives (401), from a load balancer node (130), a first request for data from the database (120), from a client node (101). The first front-end node (111) provides (402), to the client node (101), a first response to the received first request, the first response comprising a first indication indicating that the first front-end node (111) is a preferred node for providing a subsequent response to a subsequent request for data from the client node (101). The subsequent response is allowed to originate from another front-end node (112) in the pool of front-end nodes (110), different than the preferred node.