IoT File Chunking for Power-Constrained Firmware Updates

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current IoT devices face challenges in maintaining long-term battery life during firmware/software updates, as existing power-saving features and non-IP data delivery models are inadequate for frequent upgrades and variable binary changes, leading to battery drain and limited service life.

Innovation Solution

An enhanced data download mechanism where an IoT file share server partitions update files into chunks based on device type and available bandwidth, allowing each chunk to be downloaded during a single awake period, thereby minimizing battery consumption and extending device lifespan.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Duration of action of stationary object

If firmware/software updates are downloaded using existing power-saving features (PSM, eDRX), then battery life is extended during normal operation, but update downloads cause significant battery drain and may fail

Engineering Contradiction:
Improvebattery lifeVSAvoidbattery drain during update
Core Design Contradiction:
Duration of action of stationary objectVSLoss of energy

Solution Approach 1:

The update file is divided into multiple chunks that are downloaded sequentially during different awake periods. The server partitions the binary update data into smaller segments, each fitting within the device's buffer capacity for a single awake period, allowing updates to proceed without keeping the device awake continuously.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The server pre-calculates the chunk size based on device category and buffer capacity before the update process begins. Device identity information is used to determine appropriate segmentation parameters in advance, ensuring that each chunk can be downloaded within the device's power-saving schedule without requiring runtime adjustments.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If the device stays awake continuously to download large update files, then complete updates can be received, but battery life is significantly reduced

Engineering Contradiction:
Improveupdate completionVSAvoidbattery life
Core Design Contradiction:
ReliabilityVSDuration of action of stationary object

Solution Approach 1:

Large update files are segmented into multiple smaller chunks that can be downloaded during separate awake periods. The server tracks which chunks have been received and continues transmitting subsequent chunks in later awake periods until the complete update is delivered.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The update download process continues across multiple awake periods without interruption. The server maintains the update session state and resumes transmission in subsequent awake periods, ensuring the update process completes eventually without requiring the device to stay awake continuously.

Inventive Principle:
Principle #20Continuity of useful action

3Productivity

If update files are downloaded in a single awake period, then download speed is maximized, but not all devices can receive complete updates due to buffer limitations

Engineering Contradiction:
Improvedownload speedVSAvoiddevice compatibility
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The server adapts the chunk size and segmentation strategy based on the specific device category and buffer capacity. Different device types receive differently segmented update files optimized for their individual capabilities, allowing each device to download updates at the maximum speed its buffer can handle.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The server dynamically adjusts update delivery parameters including chunk size, number of segments, and transmission timing based on device identity information. This allows the system to optimize download parameters for each device type while maintaining compatibility across the full range of supported devices.

Inventive Principle:
Principle #35Parameter changes

4Use of energy by moving object

If existing non-IP data delivery models are used for infrequent small data communication, then power consumption is reduced, but frequent firmware upgrades with variable binaries cannot be supported

Engineering Contradiction:
Improvepower consumptionVSAvoidfirmware upgrade capability
Core Design Contradiction:
Use of energy by moving objectVSAdaptability or versatility

Solution Approach 1:

The server implements a universal update delivery mechanism that handles both small infrequent data communications and large frequent firmware upgrades through the same chunked download approach. The system adapts to different data sizes and frequencies while maintaining power-efficient operation, supporting variable binary changes without requiring separate communication models.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS10841767B2Enhanced data download mechanism for power constrained Internet of Things devices
Publication Date: 2020.11.17 AT&T INTELLECTUAL PROPERTY I L P
  • US10841767B2 patent drawing
  • US10841767B2 patent drawing
  • US10841767B2 patent drawing

AI summary

Concepts and technologies disclosed herein are directed to an enhanced data download mechanism for power constrained Internet of Things (“IoT”) devices. An IoT file share server can receive an update file from an IoT application server. The IoT file share server can calculate a file chunk size based upon a device type of the IoT device and a file size of the update file. The file chunk size can be calculated such that each file chunk of a plurality of file chunks is downloadable to the IoT device in a single awake period of the IoT device. The IoT file share server can partition the update file into a plurality of file chunks to be sent to the IoT device, each of which can include a portion of the update file, and the portion can be of the file chunk size.