Telephony Modem Reset History Collection for Availability
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Telephony modems that reset for unknown reasons risk not meeting the five-nines availability requirement, as each reset can take up to 1½ minutes to recover, potentially exceeding the allowed annual downtime, necessitating a method to collect and preserve reset history for system operators to identify and correct issues.
Innovation Solution
A method for collecting and preserving device reset history involves determining the type of reset, retrieving relevant information, and storing it in non-volatile memory, including software and hardware data, to create a historical record that can be analyzed by management systems.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If reset history collection and storage mechanisms are implemented, then system operators can identify and correct issues causing resets, but device complexity increases due to additional memory allocation and data collection functionality
Solution Approach 1:
The patent allocates non-volatile memory space in advance for storing reset history before resets occur. This preliminary preparation allows the system to immediately capture and store reset information without requiring complex real-time memory management during reset events, thus improving reliability while minimizing added complexity.
Solution Approach 2:
The telephony modem automatically monitors its own operational status, detects reset conditions, and stores relevant information in its own non-volatile memory. This self-service approach eliminates the need for external monitoring systems, reducing overall system complexity while maintaining high availability through automated reset tracking.
2Loss of information
If detailed reset information is stored in non-volatile memory, then causes of resets can be identified, but loss of time occurs during reset recovery processes
Solution Approach 1:
The system performs preliminary classification of reset types (software vs. hardware) and stores only the most relevant information for each type. This preliminary processing reduces the time needed to analyze reset causes while ensuring that critical information is preserved, balancing information retention with faster recovery.
Solution Approach 2:
The patent extracts and stores only the essential reset information (reset type, timestamp, and key diagnostic data) in non-volatile memory, separating this critical data from other operational data. This extraction approach minimizes the time required to retrieve and analyze reset causes while maintaining sufficient information for effective troubleshooting.
3Measurement precision
If multiple reset types are monitored and classified, then accurate diagnosis of reset causes is achieved, but device complexity increases due to additional monitoring functions
Solution Approach 1:
The patent segments reset monitoring into distinct categories (software resets and hardware resets) with specific monitoring functions for each type. This segmentation allows the system to implement targeted monitoring strategies for each reset category, achieving accurate diagnosis while managing complexity through modular, organized monitoring approaches.
Solution Approach 2:
The system implements monitoring for the most critical reset types and parameters rather than attempting to monitor all possible reset conditions. By focusing on partial monitoring of key reset causes (software exceptions, operator initiation, hardware failures), the system achieves sufficient diagnostic precision without the complexity of comprehensive monitoring of every possible reset scenario.
Data Source
AI summary
Methods for collection of device reset history from a network communication device comprising: (a) determining whether a reset condition is triggered by software or hardware, (b) for a software triggered reset: (i) upon a software exception, retrieving related reset information, (ii) upon an operator initiation, retrieving related reset information, (iii) allocating space in non-volatile memory, (iv) storing retrieved current reset information together with a corresponding reset time, and (v) adding the current reset information to historical reset information, (c) proceeding with the reset, (d) executing startup code during reboot, (e) upon a hardware triggered reset; (i) retrieving hardware registry and other residual hardware information still present, (ii) allocating space in non-volatile memory, (iii) storing the current retrieved reset information together with a current time that corresponds approximately to the reset and (iv) adding the reset information to historical reset information, and (f) continuing with normal operation of the device.