Front-End Server Time Zone Selection Logic
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In telecommunications networks with Data Layered Architecture, executing time-dependent services across different time zones leads to inconsistencies, as the time zone of the subscriber, server, and service data may not match, resulting in incorrect service execution times, affecting user experience.
Innovation Solution
A front-end server in the DLA system defines its own time zone based on geographical location and obtains subscriber-specific time zones from a common directory, selecting the appropriate time zone for service execution after verifying date and time compatibility, ensuring services are executed at the intended time.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If a single time zone is used for service execution in DLA, then the system architecture is simple, but service execution time becomes inaccurate when subscriber, server, and service data are in different time zones
Solution Approach 1:
The patent segments the time zone management into three distinct components: subscriber time zone (stored in CD), server time zone (FETZ defined by FE server location), and service execution time zone (selected based on service type). This segmentation allows each component to maintain its own time zone independently, resolving the contradiction between accuracy and complexity.
Solution Approach 2:
The patent applies local quality by allowing different time zones to be used in different contexts: subscriber time zone for subscription management, server time zone for service execution, and location-based time zone for roaming services. Each entity uses the time zone most appropriate to its local function, achieving accuracy without requiring a single complex global time zone system.
2Ease of operation
If the FE server uses its local time zone for service execution, then service execution is simple, but services may be executed at unexpected times when subscriber is roaming in different time zones
Solution Approach 1:
The patent introduces an intermediary mechanism: the service execution time zone selection logic that mediates between the FE server's local time zone and the subscriber's time zone. This intermediary selects the appropriate time zone based on service type and subscriber location, maintaining simplicity of operation while ensuring reliability of execution time.
Solution Approach 2:
The patent makes the time zone selection dynamic rather than static. The service execution time zone changes based on the subscriber's location and the specific service being executed. This dynamic adaptation ensures that services are executed at reliable times regardless of whether the subscriber is roaming, while keeping the execution mechanism simple through automated selection.
3Adaptability or versatility
If different operators use different time zone criteria, then operator flexibility is maintained, but service execution consistency across networks deteriorates
Solution Approach 1:
The patent creates a universal time zone management framework that can serve multiple functions: it supports operator-specific time zone criteria through the SSTZ parameter while simultaneously ensuring consistent service execution across different networks through the standardized selection process. The FE server and CD interaction model is universal and can be applied by any operator following the same rules.
Solution Approach 2:
The patent uses parameter changes to resolve the contradiction: operators can change the SSTZ parameter to reflect their preferred time zone criteria, while the service execution consistency is maintained through the standardized parameter interaction between FE server and CD. The system adapts to different operator preferences through parameter configuration rather than structural changes.
4Measurement precision
If time zone information is stored in the CD, then subscriber-specific time zone control is achieved, but data storage complexity increases
Solution Approach 1:
The patent extracts only the essential time zone information (time zone identifier and offset) from the complete subscriber profile, storing only what is necessary for time zone management in the CD. This extraction approach achieves accurate subscriber-specific time zone control while minimizing the additional data storage required, avoiding the need to store complete temporal information.
Data Source
AI summary
A data layered architecture (DLA) system includes a front end (FE) server and a common directory (CD). The FE server includes a processing unit which defines an FE time zone (FETZ) based on the FE server's geographical location and that defines a current date and time of the FETZ. The FE server includes a network interfacing unit which obtains from the CD through the network a subscriber default time zone (SDTZ), a subscriber service time zone (SSTZ), a service activation date (SAD) and a service activation time (SAT). The processing unit selects as service time zone (STZ) for executing the service the SSTZ, if a valid SSTZ exists, or the SDTZ, if a valid SSTZ does not exist, or the FETZ, if a valid SDTZ does not exist. Furthermore, the processing unit only executes the service after checking that the SAD and SAT of the STZ correspond to the current date and time of the FETZ.