Timer Subscription in Stateless Telecom Architecture
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Stateless architectures in telecommunications networks face challenges in supporting network timers that need to sustain hardware and VM failures, as front-end logic instances must agree on polling the backend database, which is costly in terms of bandwidth and processing, and lacks redundancy in locally stored data.
Innovation Solution
Front-end logic instances subscribe to timer events with the backend database, receiving notifications of timer events such as timeouts, allowing the backend database to manage timers and ensure consistent and reliable timer supervision, even in the presence of hardware or VM failures, using protocols like SOAP or LDAP for communication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If front-end logic instances poll the backend database for timer events, then timer supervision can be achieved, but bandwidth and processing resources are consumed and the system lacks fault tolerance
Solution Approach 1:
Instead of front-end logic instances actively polling the backend database for timer events (conventional approach), the backend database push mechanism inverts the approach by actively notifying subscribed logic instances when timer events occur. This eliminates the need for continuous polling, reducing bandwidth and processing consumption while maintaining reliable timer supervision.
Solution Approach 2:
The backend database performs self-service by automatically managing timer events and proactively notifying subscribed front-end logic instances. This eliminates the need for front-end instances to continuously query the database, reducing their processing burden and network bandwidth usage while ensuring timely notification of timer events.
2Speed
If front-end logic instances store data locally, then access speed is improved, but data redundancy is lost and fault tolerance decreases
Solution Approach 1:
The backend database acts as an intermediary that maintains the authoritative copy of timer data with full redundancy. Front-end logic instances subscribe to timer events through this intermediary, receiving notifications when events occur. This eliminates the need for front-end instances to store redundant data locally, as the backend database provides the single source of truth that all instances can access and subscribe to.
3Productivity
If multiple logic instances are deployed in a cluster, then load distribution is improved, but coordination overhead increases as instances must agree on polling
Solution Approach 1:
The coordination function is extracted from the front-end logic instances and centralized in the backend database. The database maintains the authoritative timer state and subscription information, eliminating the need for logic instances to coordinate with each other. Each instance independently subscribes to timer events, and the database handles all coordination centrally, reducing overall system complexity.
Solution Approach 2:
The backend database provides self-service coordination by automatically managing timer event notifications to all subscribed logic instances. This eliminates the need for instances to negotiate or coordinate polling schedules, as the database autonomously manages the subscription and notification process, simplifying multi-instance deployment.
4Adaptability or versatility
If a stateless architecture is used, then scalability and ease of VM management are improved, but support for persistent timers becomes difficult
Solution Approach 1:
The patent separates timer state management into a different dimension by moving it from the front-end logic instances to the backend database. This dimensional separation allows logic instances to remain stateless and easily manageable in the cloud, while the backend database maintains persistent timer state. The subscription mechanism bridges these dimensions, allowing stateless instances to participate in persistent timer events without compromising scalability.
Data Source
Figure 1
Figure 2~3
Figure 4
AI summary
A front end logic instance (102a-f, 200) of a network function in a stateless architecture of a telecommunications network. The logic instance comprises a logic performer (214) configured to perform network function logic to carry out at least part of a network function of the telecommunications network, the logic performer being configured to control a transmitter (202) and receiver (204) for transmission and reception of data with a backend database (106, 300) during performance of the network function logic. The logic instance comprises a timer subscriber (216) configured to control the transmitter to transmit a request to the backend database to be notified about a timer event relating to a timer run on the backend database, the request comprising data indicating the timer event. The receiver is further configured to receive a notification that the timer event has occurred.