Resilience Routing in Data Layered Architecture

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Data Layered Architecture (DLA) systems face challenges in handling failure conditions where the data backend system becomes partly or fully unavailable, leading to disturbances in communication networks and service degradation, such as failed calls and disrupted data communication.

Innovation Solution

The method involves providing routing information for request messages to route them through alternative application front end entities that communicate with data repositories using the application layer's communication protocol, enabling resilience routing and caching of data on application front end entities to ensure data operations can be executed even during data backend system failures.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If data is stored in a data backend system with centralized data storage, then data management is simplified and routing is streamlined, but system availability deteriorates when the data backend system becomes unavailable

Engineering Contradiction:

Improvedata management complexityVSAvoidsystem availability

Core Design Contradiction:

Device complexityVSReliability

Solution Approach 1:

The patent segments the centralized data backend system into distributed data repositories that can operate independently. Each repository stores portions of the data and can serve requests autonomously, eliminating the single point of failure in centralized architecture. This segmentation allows the system to maintain availability even when individual repositories or connection paths fail.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent changes the operational parameters of the system by introducing resilience mode as an alternative state. When the data backend system becomes unavailable, the system transitions from normal operation mode to resilience mode, where application front end entities use cached routing information to continue operating. This parameter change enables the system to maintain functionality under degraded conditions.

Inventive Principle:

Principle #35Parameter changes

2Productivity

If the system operates in normal mode with centralized data backend access, then data operations are efficient and consistent, but service continuity deteriorates during backend unavailability

Engineering Contradiction:

Improvedata operation efficiencyVSAvoidservice continuity

Core Design Contradiction:

ProductivityVSDuration of action of stationary object

Solution Approach 1:

The patent implements preliminary action by caching routing information and data in application front end entities before the data backend system becomes unavailable. During normal operation, entities pre-fetch and store frequently accessed data and routing information locally. This preliminary caching ensures that when the backend becomes unavailable, the cached data can be used immediately without interruption to service continuity.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The patent provides beforehand cushioning by maintaining local copies of routing information and data in application front end entities. These local caches act as a cushion or buffer that protects the system from the impact of backend unavailability. When the data backend system fails, the cached data provides a cushion that allows services to continue operating without immediate failure.

Inventive Principle:

Principle #11Beforehand cushioning (Prior cushioning)

3Device complexity

If routing information is centralized in the data backend system, then routing decisions are centralized and simple, but routing resilience deteriorates when backend connections fail

Engineering Contradiction:

Improverouting decision complexityVSAvoidrouting resilience

Core Design Contradiction:

Device complexityVSReliability

Solution Approach 1:

The patent applies universality by enabling application front end entities to perform multiple functions: they act as both application processors and local routing decision-makers. These entities can retrieve routing information from the data backend system during normal operation and also use cached routing information independently when the backend is unavailable. This multi-functionality distributes routing intelligence throughout the system, enhancing routing resilience without significantly increasing complexity.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentEP2770679B1Resilience operation of a data layered architecture

Publication Date: 2018.04.11 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)

Figure 1~2
Figure 3
Figure 4A~4B

AI summary

Various techniques for routing a request message (400), which requests a service requiring a data operation on data which is stored in a data backend system (101), are discussed. The request message (400) is received by a first application front end entity (320-1) of an application layer (100). Based on the received request message (400), a data operation message (410) is sent from the first application front end entity (320-1) to a first data repository (140-1) of the data backend system (101). The first data repository (140-1) returns routing information (420) to the first application front end entity (320-1), which enables the first application front end entity (320-1) to route the request message (400) to a second application front end entity (320-2) of the application layer (100). The second application front end entity (320-2) communicates with a given data repository (140-2) which stores the data.