M2M Notification Queues and Confirmation for Low-Power Reliability
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
M2M client devices with limited power supplies face challenges in efficiently notifying M2M server devices over extended periods without depleting their power resources, particularly in scenarios where asynchronous data transmission is required.
Innovation Solution
Implementing a method that allows for dynamic configuration of M2M client devices using confirmation notification and notification queue parameters to manage transmission behavior, enabling confirmable or non-confirmable messaging and historical data queuing based on data criticality and device memory resources.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If M2M client devices continuously notify M2M server devices over extended periods, then notification reliability is improved, but power supply is depleted
Solution Approach 1:
The patent implements dynamic configuration of notification parameters including confirmation notification parameters and notification queue parameters that can be adjusted based on operational conditions. This allows the system to adapt notification behavior dynamically - using confirmation mechanisms when reliability is critical and adjusting queue depth based on power availability and network conditions, thereby resolving the contradiction between continuous notification reliability and power consumption
Solution Approach 2:
The patent changes notification parameters such as confirmation status, queue depth, and transmission timing based on device state and environmental conditions. By modifying these parameters dynamically, the system can maintain adequate notification reliability while reducing power consumption during low-battery states or when network conditions permit less frequent transmissions
2Reliability
If confirmation notification parameters are enabled for all variables, then notification reliability is improved, but device complexity increases
Solution Approach 1:
The patent applies local quality by enabling confirmation notification parameters selectively for specific variables or data types rather than uniformly for all notifications. The system can determine which variables require confirmation based on their criticality, allowing confirmation mechanisms to be applied only where needed, thus improving reliability for critical data while avoiding unnecessary complexity for less important data
3Loss of information
If notification queue parameters are increased to store more historical values, then data completeness is improved, but memory resources are consumed
Solution Approach 1:
The patent implements dynamic adjustment of notification queue parameters including queue depth and retention policies based on operational conditions such as network connectivity status, power availability, and data criticality. When connectivity is restored or power becomes available, the system can increase queue depth to capture more historical data. When resources are constrained, the system reduces queue depth, thereby resolving the contradiction between data completeness and memory consumption
Solution Approach 2:
The patent applies preliminary action by pre-configuring notification queue parameters and establishing queue management policies before critical notification events occur. The system pre-establishes queue depth limits, retention periods, and prioritization rules, allowing efficient handling of historical data without requiring excessive memory resources during normal operation
Data Source
Figure 1
Figure 2
Figure 2
AI summary
Method for providing notifications by a client to a server, comprising performing, by the client, the steps of: receiving (120), for at least one variable to be monitored, one or more predefined configuration parameters including at least one of: a confirmation notification parameter indicating at least whether notifications with a value for said at least one variable are to be confirmed, a notification queue parameter related to the storing of one or more historical values for said at least one variable in a notification queue; setting or modifying a configuration (130) of the client to notify values for said at least one variable in accordance with the received one or more predefined configuration parameters; and based on the configuration of the client, notifying (140) one or more values for said at least one variable to the server.