DLMS Image Transfer (Class 18) Block Size Optimization & Verification Failure in OTA Updates

[elena_rostova]

Firmware Upgrade (OTA) Engineering Notes

When performing Over-The-Air (OTA) firmware upgrades on NB-IoT / Cellular smart meters using COSEM Class 18 (Image Transfer), we encountered two major challenges:

1. Block Size Throttling: Negotiating a block size larger than 512 bytes on high-latency cellular connections causes packet fragmentation and retransmissions.
2. Image Verification Failure: Calling method image_verify (Method 3) returned temporary-failure or hardware-fault.

Recommended Block Size by Media

Communication Media	Optimal Block Size	Max Window Size
Optical Probe / Serial	512 - 1024 bytes	1
RS-485 Multi-drop	256 - 512 bytes	1
NB-IoT / LTE-M	192 - 256 bytes	1
Ethernet / TCP-IP	1024 - 2048 bytes	4

Verification Root Cause

In Class 18, before invoking image_verify, the client must check attribute 7 (image_to_verify_image_signature). If your build system prepends a proprietary header to the raw binary file that is not part of the meter's cryptographic hash signature, the on-chip bootloader hash check will fail.

[alex_turner]

To ensure robust Image Transfer over lossy networks, always query attribute 6 (image_transfer_status) and attribute 4 (image_transferred_blocks_indicator) before verifying.

If any bits in the bit-string are 0 (indicating missing blocks), use image_block_transfer to resend only the missing block indices rather than restarting the entire firmware transfer from block 0.

[marcus_vance]

We implemented block-level resume in our Head-End System. For a 500 KB firmware image with 256-byte blocks (2000 blocks), resuming dropped packets reduced total OTA upgrade bandwidth by 78% on cellular meters.