Amazon Sidewalk max payload size.

Short answer is no, the Sidewalk Gateway does not automatically fragment payloads that exceed the link-layer MTU as of the writing of this reply. If you send a payload via SendDataToWirelessDevice that exceeds the Sidewalk link MTU, the message will fail — it will not be silently chunked by the Gateway. The 2048-byte limit in the API documentation is a general AWS IoT Wireless API constraint, not a reflection of what Amazon Sidewalk can actually deliver in a single message over a given radio link.

The Amazon Sidewalk Sid API Developer Guide explicitly defines the application-layer MTU for each link type in Table 2.2:

Link Type	MTU (Bytes)
BLE (Link Type 1)	255
FSK (Link Type 2)	200
LoRa / CSS (Link Type 3)	19

These are the maximum sizes for the application payload — meaning the user_data field inside a custom command. The Sid API Developer Guide states explicitly under Custom Commands (Section 3.2.1) that the included data length shall not exceed 200 bytes for SubG-FSK Endpoints and 19 bytes for SubG-CSS Endpoints.

What Happens If You Exceed the MTU? The Sidewalk stack enforces these limits at the API level. When sid_put_msg is called on the Endpoint side, the API returns SID_ERROR_INVALID_ARGS if "the message size is zero or the message size is greater than 255 bytes". On the cloud-to-device (downlink) path, the Amazon Sidewalk Network Server and Gateway do not perform application-layer fragmentation. The protocol specification explicitly states: "The current release of the protocol does not support frame fragmentation. The field [is_fragment] shall be set to 0."

This means the Network Layer's is_fragment flag is defined in the specification but is not active in the current protocol release. There is no automatic chunking at the Gateway level for standard messages.

The SendDataToWirelessDevice API's 2048-byte PayloadData limit is a generic AWS IoT Wireless API parameter that applies across multiple wireless protocols (LoRaWAN, Sidewalk, etc.). For Sidewalk specifically, the effective maximum is governed by the link-type MTU. Sending a payload larger than the link MTU will result in the message being rejected — not fragmented.

If you need to send data larger than the link MTU (e.g., firmware images), Amazon Sidewalk provides the Sidewalk Bulk Data Transfer (SBDT) feature. SBDT handles fragmentation at the application and network layers: -Files are split into fragments (configurable, 1K–8K) -Fragments are further split into MTU-sized chunks by the Network Server -Each chunk is individually encrypted and transmitted -The Endpoint reassembles fragments and verifies integrity via hash checking

However, SBDT currently supports BLE (Link Type 1) only and is designed for file transfer use cases (OTA firmware updates, configuration downloads), not general-purpose messaging.

Bottom line is that if you need to send payloads larger than the MTU, you will need to frag/defrag at the application level. An example of this for device->cloud can be found in this example: https://github.com/aws-samples/aws-iot-asset-tracker-demo/tree/main Specifically the infra/uplink-decode folder.

and the associated device code that fragments the payloads for WIFI or GNSS types. https://github.com/aws-samples/wm1110-asset-tracker/blob/f27ca9757734cc23cdcef1ddc3faeb8730cab132/src/sidewalk/at_uplink.c#L136

A simple device payload spec with fragmenting for GNSS/WIFI payloads for this can be found here: https://github.com/aws-samples/wm1110-asset-tracker/blob/main/PAYLOADS.md#gnss-location-uplink-message-format

I hope this helps anyone still looking for an answer to this question.

For Sidewalk devices:

1. While SendDataToWirelessDevice API can accept payloads up to 2048 bytes, the actual transmission is constrained by the MTU limits:

• BLE: 255 bytes MTU
• LoRa: 44 bytes MTU

The fragmentation of larger payloads depends on the connection type:

For BLE:

• The Sidewalk gateway will automatically handle fragmenting messages larger than 255 bytes
• You can send payloads up to 2048 bytes, and the gateway manages the chunking

For LoRa:

• Due to bandwidth and power constraints, it's recommended to keep messages within the 44-byte MTU
• While fragmentation is possible, it's best practice to manage message sizes at the application level for LoRa to optimize power consumption and transmission reliability

Best Practices:

• For BLE: You can utilize the full 2048 bytes as the gateway handles fragmentation
• For LoRa: Design your application to work with smaller payloads (≤44 bytes) when possible to ensure optimal performance

Detailed Implementation:

BLE Implementation Example:

import boto3

def send_large_payload_ble(wireless_device_id, payload, session):
    client = boto3.client('iotwireless')
    
    try:
        # For BLE, you can send the full payload (up to 2048 bytes)
        response = client.send_data_to_wireless_device(
            Id=wireless_device_id,
            TransmitMode='0',  # 0 for unacknowledged
            PayloadData=payload,
            WirelessMetadata={
                'Sidewalk': {
                    'Sequence': session
                }
            }
        )
        return response
    except Exception as e:
        print(f"Error sending data: {e}")

LoRa Implementation Example:

import boto3
import math

def send_large_payload_lora(wireless_device_id, payload, session):
    client = boto3.client('iotwireless')
    LORA_MTU = 44
    
    # Split payload into chunks
    chunks = [payload[i:i + LORA_MTU] for i in range(0, len(payload), LORA_MTU)]
    total_chunks = len(chunks)
    
    for index, chunk in enumerate(chunks):
        try:
            # Add metadata to chunk (sequence number and total chunks)
            chunk_metadata = {
                'chunk_number': index + 1,
                'total_chunks': total_chunks,
                'session_id': session
            }
            
            # Combine metadata and chunk data
            formatted_chunk = format_chunk_with_metadata(chunk_metadata, chunk)
            
            response = client.send_data_to_wireless_device(
                Id=wireless_device_id,
                TransmitMode='1',  # 1 for acknowledged
                PayloadData=formatted_chunk,
                WirelessMetadata={
                    'Sidewalk': {
                        'Sequence': session
                    }
                }
            )
            
            # Wait for acknowledgment before sending next chunk
            wait_for_ack(response)
            
        except Exception as e:
            print(f"Error sending chunk {index + 1}: {e}")
            # Implement retry logic here

Additional Considerations:

1. Error Handling:

• Implement retry mechanisms for failed transmissions
• Track successful delivery of all chunks
• Handle timeout scenarios

2. Device-side Implementation:

def receive_and_reassemble_lora():
    chunks = {}
    
    while True:
        chunk = receive_chunk()
        metadata = extract_metadata(chunk)
        
        # Store chunk
        session_id = metadata['session_id']
        if session_id not in chunks:
            chunks[session_id] = {}
            
        chunks[session_id][metadata['chunk_number']] = chunk
        
        # Check if all chunks received
        if len(chunks[session_id]) == metadata['total_chunks']:
            return reassemble_payload(chunks[session_id])

3. Monitoring and Logging:

def monitor_transmission(session_id):
    cloudwatch = boto3.client('cloudwatch')
    
    # Monitor metrics
    cloudwatch.put_metric_data(
        Namespace='IoTWireless',
        MetricData=[
            {
                'MetricName': 'TransmissionLatency',
                'Value': transmission_time,
                'Unit': 'Milliseconds'
            }
        ]
    )