Platform

Cross-Platform

Description

Feature Request: ACK Aggregation (Batched Acknowledgments)

Summary

Aggregate multiple ACK responses into a single LoRa transmission to reduce airtime overhead in busy mesh networks.

Problem Statement

Currently, every packet sent with want_ack=true generates its own individual ACK packet in response. In a busy mesh with many nodes exchanging messages, position updates, and telemetry, this creates significant airtime overhead:

Example scenario (current behavior):

Node A sends 5 messages to Node B in quick succession (want_ack=true) 
Node B sends 5 separate ACK packets back to Node A = 5 individual LoRa transmissions, each with its own preamble and headers

Each ACK transmission consumes:

• LoRa preamble time
• Packet header overhead
• Transmission slot (which could be used for actual data)
• Radio duty cycle budget

In a mesh with 20+ active nodes during a busy period, ACK traffic can consume a substantial portion of available channel capacity.

Proposed Solution

Implement an optional ACK batching mechanism that queues pending ACKs for a short window (100-500ms) and sends them as a single aggregated packet:

Proposed behavior:

Node A sends 5 messages to Node B in quick succession (want_ack=true) 
Node B waits briefly (e.g., 200ms), collecting pending ACKs 
Node B sends 1 batched ACK packet containing all 5 acknowledgments = 1 LoRa transmission instead of 5

Benefits

Technical Approach

1. New Protobuf Message: Add BatchedRouting message type to aggregate multiple ACK IDs
2. ACK Queue: Buffer non-urgent ACKs in RoutingModule with a configurable time window
3. Flush Triggers: Send batched ACK when either:
   • Batch window expires (e.g., 200ms since first pending ACK)
   • Batch size limit reached (e.g., 10 ACKs)
4. Preserve Urgent ACKs: ACKs with ackWantsAck=true (reliable ACKs) still send immediately
5. Receiver Handling: Update ReliableRouter to handle batched ACK packets and stop retransmissions for all included IDs

Configuration Options

Consider adding a new config option:

message DeviceConfig {
    // ...existing fields...
    bool ack_batching_enabled = X;       // Enable/disable ACK aggregation
    uint32 ack_batch_window_ms = Y;      // Time window to collect ACKs (default: 200ms)
}

Trade-offs to Consider

Use Cases That Benefit Most

• Store & Forward servers processing many queued messages
• Dense deployments with 20+ nodes in range
• Telemetry-heavy meshes with frequent position/sensor broadcasts
• Events or gatherings where many users are actively messaging

Related Work

This is similar to TCP's delayed ACK mechanism (RFC 1122) which batches acknowledgments to reduce overhead, and WiFi block acknowledgments (802.11e).