Description:FIELD OF THE INVENTION
This invention relates to Method for Adaptive Duty Cycle and Transmission Parameter Adjustment in Low-Power Wide Area Network (LPWAN) Devices Based on Network Conditions and Energy Constraints.
BACKGROUND OF THE INVENTION
Low-Power Wide Area Network (LPWAN) devices, such as remote sensors or asset trackers, are designed to operate for years on a single battery while communicating over long distances. However, they often use fixed, pre-configured settings for how strongly they transmit (Transmission Power), how fast they send data (Data Rate), and how often they wake up to communicate (affecting the Duty Cycle, which is the strict regulatory limit on the percentage of time a device can be actively transmitting). The core problem is that these fixed settings are inefficient and unreliable because the real-world conditions – like the radio signal strength between the device and the network, the remaining battery energy, and even the amount of data needing to be sent – constantly change. Using overly strong settings when the signal is good wastes precious battery life, while using weak settings when the signal is poor leads to lost messages and unreliability. Furthermore, transmitting too often or for too long with fixed settings can inadvertently cause the device to exceed its legal Duty Cycle limits, potentially disrupting other users or facing penalties. This static approach fails to adapt, resulting in significantly shortened device lifespan, poor communication performance, and potential non-compliance with regulations.
EXISTING SOLUTIONS / PRIOR ART/RELATED APPLICATIONS & PATENTS
Currently, there isn't a single commercially available product or standard feature set that perfectly mirrors the proposed invention's holistic, device-centric approach combining real-time network conditions, energy status, and meticulous duty cycle management for transmission parameter and timing adaptation. However, elements of the problem are addressed by existing technologies and practices:
• LoRaWAN Adaptive Data Rate (ADR): This is the most relevant existing mechanism, defined in the LoRaWAN specification.
I. How it works: The LoRaWAN Network Server (LNS) analyzes the signal quality (SNR) of recent uplinks received from a device. Based on this, it periodically sends downlink commands instructing the device to adjust its Transmission Power (Tx Power) and Data Rate (DR) / Spreading Factor (SF).
II. Products implementing it:
 Network Servers: The Things Stack, ChirpStack, AWS IoT Core for LoRaWAN, Actility ThingPark, Senet, Loriot, etc., all implement ADR algorithms on the server-side.
 End-Device Stacks/Modules: Firmware stacks (e.g., Semtech's LoRa Basics™ Modem-E, Mbed OS LoRaWAN stack, Zephyr Project's LoRaWAN support) and hardware modules incorporating these stacks (from vendors like STMicroelectronics, Murata, RAKwireless, Microchip, Seeed Studio) typically implement the client-side of ADR, enabling them to receive and apply the commands from the LNS.
III. Commercial Practice: Using ADR is a standard and recommended practice in mature LoRaWAN deployments to optimize network capacity and basic device energy consumption. However, its effectiveness depends on reliable downlink communication and it typically lacks awareness of the device's specific battery level or fine-grained duty cycle state.
• Static Configuration: A very common commercial practice, especially for simpler or cost-sensitive devices (using various LPWAN technologies like LoRaWAN, Sigfox, NB-IoT), is to use fixed transmission parameters and a fixed transmission interval set during provisioning. This offers no adaptation. Devices might implement simple retry mechanisms on transmission failure but lack proactive optimization.
• Proprietary Firmware Logic: Some manufacturers of end-devices or end-to-end solutions may implement their own proprietary, limited adaptive logic within their device firmware. This might involve basic link checks or simple power adjustments based on ACK success/failure, but typically lacks the multi-factor sophistication (especially integrating energy and detailed duty cycle tracking) of the proposed invention and is not a standardized or widely available "product."
Existing solutions are insufficient to solve the issue entirely mainly because they do not offer a whole, self-governing, and real-time adaptation mechanism at the device that takes into account the entire context:
1. Static Configurations: These inherently lack any adaptability. They cannot react to changing radio environments (leading to failures or inefficiency), ignore the device's depleting energy reserves (shortening lifespan), and risk violating regulatory duty cycle limits if conditions require longer transmission times than initially planned. They represent a "one-size-fits-none" approach in dynamic environments.
2. Network-Controlled Adaptation (e.g., LoRaWAN ADR): While beneficial, ADR is incomplete because:
• It lacks device-specific energy awareness: The network server instructing the device typically doesn't know the actual remaining battery level and might command energy-intensive settings (like high power or high Spreading Factor) that are unsustainable for a device with low energy.
• It's dependent on reliable downlinks: If the communication link is already poor, the device may never receive the adaptation commands from the network, preventing it from adjusting its parameters when needed most.
• It has inherent latency: There's a delay between the network observing conditions, processing them, and the device receiving the command, meaning the adaptation might lag behind real-time changes.
• It doesn't fully manage duty cycle compliance: While ADR helps by potentially reducing Time-on-Air, the ultimate responsibility for tracking cumulative usage across all transmissions and ensuring compliance with strict regulatory limits rests with the device, which ADR commands alone don't guarantee.
3. Simple Device-Side Logic: Existing rudimentary device-side attempts are often insufficient:
• They are often purely reactive: Only acting after a transmission fails (e.g., simple retry or power boost), rather than proactively optimizing based on link quality indicators (RSSI/SNR) before failure occurs.
• They lack holistic integration: They typically don't simultaneously consider and balance network conditions, remaining energy, and precise duty cycle usage state to make an optimal decision. For example, a simple logic might increase power upon failure, ignoring that the device is critically low on battery or nearing its duty cycle limit.
3. Conduct key word searches using Google and list relevant prior art material found?
Low-Power Wide Area Network (LPWAN), Adaptive Duty Cycle, Dynamic Transmission Parameter Adjustment (Tx Power, Data Rate/Spreading Factor), Energy Efficiency, Network Condition Monitoring (RSSI, SNR), Link Reliability, Regulatory Compliance, Battery Optimization.
Basic Differences from Previous Solutions:
• Locus of Intelligence: The core decision-making logic resides on the device firmware, unlike static configurations (no intelligence) or primarily network-centric adaptation (like ADR).
• Input Factors: Integrates network quality, energy status, duty cycle usage, and application needs simultaneously for decision-making, whereas previous solutions typically focus on only one or two (e.g., ADR focuses mainly on network quality, static uses none, simple logic might use only ACK success).
• Scope of Adaptation: Dynamically adjusts both transmission parameters (Power, DR/SF) and duty cycle strategy (transmission timing/interval), whereas ADR mainly controls parameters and static configurations control neither dynamically.
• Adaptation Mechanism: Employs a proactive, state-aware control loop based on continuous monitoring, rather than being fixed (static), reactive only to major failures (simple logic), or dependent on periodic network feedback (ADR).

SUMMARY OF THE INVENTION
This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the invention.
This summary is neither intended to identify key or essential inventive concepts of the invention and nor is it intended for determining the scope of the invention.
To further clarify advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
The illustrated embodiments of the subject matter will be understood by reference to the drawings, wherein like parts are designated by like numerals throughout. The following description is intended only by way of example, and simply illustrates certain selected embodiments of devices, systems, and methods that are consistent with the subject matter as claimed herein, wherein:
Fig 1: System Block Diagram
Fig 2: Process Flowchart
The figures depict embodiments of the present subject matter for the purposes of illustration only. A person skilled in the art will easily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the disclosure described herein.
DETAILED DESCRIPTION OF THE INVENTION
The detailed description of various exemplary embodiments of the disclosure is described herein with reference to the accompanying drawings. It should be noted that the embodiments are described herein in such details as to clearly communicate the disclosure. However, the amount of details provided herein is not intended to limit the anticipated variations of embodiments; on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the present disclosure as defined by the appended claims.
It is also to be understood that various arrangements may be devised that, although not explicitly described or shown herein, embody the principles of the present disclosure. Moreover, all statements herein reciting principles, aspects, and embodiments of the present disclosure, as well as specific examples, are intended to encompass equivalents thereof.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a",” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and/or “including,” when used herein, specify the presence of stated features, integers, steps, operations, elements and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof.
It should also be noted that in some alternative implementations, the functions/acts noted may occur out of the order noted in the figures. For example, two figures shown in succession may, in fact, be executed concurrently or may sometimes be executed in the reverse order, depending upon the functionality/acts involved.
In addition, the descriptions of "first", "second", “third”, and the like in the present invention are used for the purpose of description only, and are not to be construed as indicating or implying their relative importance or implicitly indicating the number of technical features indicated. Thus, features defining "first" and "second" may include at least one of the features, either explicitly or implicitly.
Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which example embodiments belong. It will be further understood that terms, e.g., those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
Our proposed invention solves the problem of inefficient and unreliable communication in LPWAN devices by embedding an intelligent adaptation engine directly within the device's firmware. This engine continuously monitors crucial real-time inputs: network signal quality (like RSSI and SNR from acknowledgements), the device's remaining battery energy level, its cumulative transmission time (Time-on-Air) to ensure compliance with regulatory duty cycle limits, and the priority of data waiting to be sent. Based on these inputs, an on-device decision logic dynamically adjusts key transmission parameters – primarily Transmission Power and Data Rate (or Spreading Factor) – and transmission scheduling before each communication attempt. For instance, it reduces power and increases data rate in good conditions to save energy and duty cycle, boosts power or lowers data rate for reliability in poor conditions (if energy and duty cycle permit), and prioritizes aggressive energy saving or delays transmissions when the battery is critically low or duty cycle limits are approached, thereby ensuring optimal performance, maximized battery life, and regulatory compliance across diverse and changing operating conditions.
NOVELTY
The novelty lies in the embedded device firmware engine that holistically and adaptively co-optimizes LPWAN transmission parameters (like power and data rate) and duty cycle strategy (transmission timing/interval) based on a simultaneous, real-time assessment of network link quality, remaining energy budget, regulatory compliance status, and application data needs.
Advantages of the Proposed Solution over Previous Solutions:
• Improved Energy Efficiency: Unlike static configurations that often use excessive power, the proposed solution dynamically minimizes Transmission Power and Time-on-Air (by adjusting Data Rate/Spreading Factor) when conditions allow, significantly extending battery life.
• Enhanced Reliability: Compared to static settings that fail in poor conditions, this method proactively increases robustness (power/SF) when the link degrades, reducing message loss more effectively than simple retransmit logic.
• Guaranteed Regulatory Compliance: Actively monitors and manages Time-on-Air against limits, preventing duty cycle violations which static configurations or solely network-controlled ADR might inadvertently cause.
• Greater Responsiveness: Adaptation decisions are made locally on the device in near real-time, reacting faster to changing conditions than network-dependent solutions (like LoRaWAN ADR) which rely on downlink commands and inherent latency.
• Holistic Optimization: Considers the device's actual remaining energy level and application data priority, factors often ignored by purely network-quality-focused ADR or simplistic device logic, leading to more balanced performance tailored to the device's specific state.
• Increased Autonomy: Reduces reliance on potentially intermittent downlink commands for adaptation, making the device more robust in challenging network environments where ADR commands might not be received.
Conceptual Pseudo code Snippet (Illustrating Decision Logic):
// Structure to hold transmission settings
struct TxSettings {
int tx_power; // e.g., dBm
int data_rate; // e.g., LoRaWAN DR index (lower is slower/longer range)
bool delay_transmission; // Flag to indicate if Tx should be postponed
int delay_ms; // Delay duration if delay_transmission is true
};
// Thresholds (Example Values - Need Tuning)
#define SNR_THRESHOLD_GOOD 5
#define SNR_THRESHOLD_POOR -10
#define RSSI_THRESHOLD_GOOD -90
#define BATTERY_LEVEL_LOW 20 // Percent
#define BATTERY_LEVEL_CRITICAL 5 // Percent
#define DUTY_CYCLE_THRESHOLD_HIGH 0.8 // 80% of allowed limit reached
#define MAX_TX_POWER 14
#define MIN_TX_POWER 2
#define MAX_DATA_RATE 5 // Fastest DR
#define MIN_DATA_RATE 0 // Slowest DR (highest SF)
// Function to determine optimal settings before transmission
TxSettings determine_tx_settings(float last_snr, float last_rssi, bool ack_received,
int battery_percent, float duty_cycle_used_ratio,
bool is_critical_data)
{
TxSettings settings;
settings.delay_transmission = false;
settings.delay_ms = 0;
// Default settings (can be conservative)
settings.tx_power = MAX_TX_POWER;
settings.data_rate = MIN_DATA_RATE; // Start robust
// --- Priority 1: Critical Constraints ---
// Check Duty Cycle
if (duty_cycle_used_ratio > DUTY_CYCLE_THRESHOLD_HIGH) {
// Try to reduce Time-on-Air if possible
if (last_snr > SNR_THRESHOLD_GOOD && settings.data_rate < MAX_DATA_RATE) {
settings.data_rate++; // Use faster DR
// Re-calculate expected ToA - if still too high...
if (calculate_estimated_toa(settings.data_rate, settings.tx_power) + duty_cycle_used_ratio > 1.0) {
if (!is_critical_data) {
settings.delay_transmission = true;
settings.delay_ms = calculate_required_off_time();
return settings; // Must delay
} else {
// Critical data, cannot delay, potentially reduce power if possible as last resort?
// Or transmit if calculated ToA fits *exactly* within remaining limit. Risky.
}
}
} else if (!is_critical_data) {
settings.delay_transmission = true;
settings.delay_ms = calculate_required_off_time();
return settings; // Must delay
}
// If critical and cannot adjust, may have to transmit if within 1.0 limit (handled by lower layer)
}
// Check Critical Energy
if (battery_percent < BATTERY_LEVEL_CRITICAL) {
settings.tx_power = MIN_TX_POWER; // Minimum power
settings.data_rate = MAX_DATA_RATE; // Fastest DR (lowest ToA/Energy per Tx)
if (!is_critical_data) {
settings.delay_transmission = true; // Consider delaying non-critical data
settings.delay_ms = 60000; // e.g., wait a minute
}
return settings; // Prioritize survival
}
// --- Priority 2: Reliability vs. Efficiency ---
if (ack_received && last_snr > SNR_THRESHOLD_GOOD && last_rssi > RSSI_THRESHOLD_GOOD) {
// Link is strong - Optimize for efficiency
if (settings.tx_power > MIN_TX_POWER) {
settings.tx_power -= 2; // Reduce power first (e.g., by 2dB steps)
} else if (settings.data_rate < MAX_DATA_RATE) {
settings.data_rate++; // If power is min, try faster data rate
}
} else if (!ack_received || last_snr < SNR_THRESHOLD_POOR) {
// Link is weak or failed - Improve reliability (if energy/DC allows)
if (settings.data_rate > MIN_DATA_RATE && battery_percent > BATTERY_LEVEL_LOW) {
settings.data_rate--; // Try slower data rate first (often better range/SNR gain than power)
} else if (settings.tx_power < MAX_TX_POWER && battery_percent > BATTERY_LEVEL_LOW) {
settings.tx_power += 2; // If already slowest DR, increase power
}
}
// Intermediate conditions: Maintain current settings (hysteresis implied)
// --- Add Hysteresis: Only change if condition persists over N attempts (not shown here for simplicity) ---
// Final check to ensure power/DR are within valid ranges
settings.tx_power = max(MIN_TX_POWER, min(MAX_TX_POWER, settings.tx_power));
settings.data_rate = max(MIN_DATA_RATE, min(MAX_DATA_RATE, settings.data_rate));
return settings;
}// Helper functions (placeholders)
float calculate_estimated_toa(int data_rate, int tx_power) { /* ... */ return 0.1; } // Returns estimated seconds
int calculate_required_off_time() { /* ... */ return 36000; } // Returns milliseconds until DC limit resets enough

, Claims:1. Conceptual Claims:
1. A method in an LPWAN device, the method including:
o Monitoring, by the device, a plurality of input factors including:
 at least one network condition indicator derived from communication attempts;
 an estimated remaining energy level of the device's power source; and
 a current duty cycle usage status relative to regulatory limits.
o Processing, by an on-device decision logic engine, said plurality of input factors;
o Dynamically selecting, based on said processing, a set of transmission parameters, said parameters including at least Transmission Power and a Data Rate or Spreading Factor; and
o Dynamically determining, based on said processing, a transmission timing strategy, including potentially adjusting a transmission interval or delaying a transmission;
o Configuring the device's radio transceiver with the selected transmission parameters for a subsequent transmission; and
o Executing the subsequent transmission according to the determined transmission timing strategy;
o Wherein the selecting and determining steps aim to balance communication reliability, energy consumption, and regulatory duty cycle compliance.
2. The method of claim 1, wherein the network condition indicator includes at least one of: Received Signal Strength Indicator (RSSI), Signal-to-Noise Ratio (SNR), or an acknowledgement success rate over a window of time.
3. Claim 1's method, where monitoring the estimated remaining energy level includes measuring a battery voltage or using a coulomb counter.
4. The method of claim 1, wherein monitoring the current duty cycle usage status comprises tracking accumulated Time-on-Air (ToA) for transmissions within specific frequency bands and comparing said accumulated ToA against predefined regulatory limits.
5. The claim 1 method, wherein said plurality of input factors also contains an indicator of data buffer status or application data priority.
6. The claim 1 method, wherein the on-device decision logic engine executes said processing utilizing a state machine or a rule-based system.
7. The method of claim 1, wherein dynamically selecting transmission parameters includes reducing Transmission Power and/or increasing Data Rate (decreasing Spreading Factor) when network conditions are determined to be strong and energy level is sufficient.
8. The method of claim 1, wherein dynamically selecting transmission parameters includes increasing Transmission Power and/or decreasing Data Rate (increasing Spreading Factor) when network conditions are determined to be weak, provided energy level and duty cycle usage permit.
9. The process of claim 1, where dynamically determining the transmission timing strategy involves extending the interval between non-critical transmissions or delaying transmissions when the estimated remaining energy level is less than a critical level or when the current duty cycle usage is nearing a regulatory threshold.
10. An LPWAN device having:
o A radio transceiver;
o A power source;
o A processor;
o A memory keeping instructions that, when run by the processor, make the device do the method of any one of claims 1-9.