Skip to content

Provide support and guidance for large UDP datagrams over OpenThread on ESP32-C6 (IDFGH-18190) #19012

Description

@kunjsn123

Is your feature request related to a problem?

I am using ESP-IDF/OpenThread with the following architecture:

  • Thread Border Router: ESP32-S3 + ESP32-C6
  • Thread Client: ESP32-C6
  • Communication: UDP over Thread

Currently, I can receive approximately 1200 bytes in a single UDP message on the ESP32-C6 Thread client.

My application requires transferring larger data from the Thread Border Router to the Thread client while receiving the complete payload as a single UDP datagram at the application layer.

With Wi-Fi, an application can send a relatively large UDP datagram and receive it as one UDP message. I understand that Thread uses IEEE 802.15.4 and therefore large IPv6/UDP packets may require 6LoWPAN fragmentation and reassembly.

I would like to understand whether ESP-IDF/OpenThread can provide the same application-level behavior:

Application sends one large UDP datagram

OpenThread/6LoWPAN fragments it

Multiple IEEE 802.15.4 frames

OpenThread reassembles the packet

Application receives one complete UDP datagram

At present, it is not clear what limits the approximately 1200-byte payload or which ESP-IDF/OpenThread configuration controls this behavior.

Describe the solution you'd like.

I would like ESP-IDF/OpenThread to provide clear support, documentation, configuration guidance, and preferably an example for sending and receiving larger UDP datagrams over Thread.

Specifically, could you please clarify:

  1. Can an ESP32-C6 receive a UDP datagram larger than approximately 1200 bytes as one application-level UDP message?

  2. What is the maximum supported UDP datagram size over OpenThread on ESP32-C6?

  3. If larger datagrams are supported, what configuration/code changes are required on the ESP32-C6 Thread client?

For example:

  • sdkconfig/menuconfig options
  • OpenThread message buffer configuration
  • 6LoWPAN fragmentation/reassembly configuration
  • IPv6 configuration
  • LwIP/UDP receive buffer configuration
  1. Are corresponding configuration changes required on the Thread Border Router?

Our Border Router uses:

ESP32-S3 Host + ESP32-C6 RCP

  1. Is fragmentation/reassembly handled completely by OpenThread/6LoWPAN so that the application still receives one complete UDP datagram?

An ESP-IDF example demonstrating this would be very useful.

Describe alternatives you've considered.

I have considered splitting large application data into multiple smaller packets using:

  • Application-level chunking
  • Multiple UDP packets with sequence numbers
  • CoAP Block-Wise Transfer
  • TCP

These approaches are possible, but before implementing application-level fragmentation, I would like to understand the actual supported limits of UDP/IPv6/6LoWPAN in ESP-IDF OpenThread.

If OpenThread already supports fragmentation and reassembly of larger UDP datagrams, I would prefer to use the standard stack functionality rather than implementing another fragmentation layer in the application.

Additional context.

Current architecture:

ESP32-S3 + ESP32-C6 Thread Border Router
|
| UDP over Thread
|
v
Thread Network
|
v
ESP32-C6 Client
|
v
Receive large UDP payload

Current observed maximum payload is approximately 1200 bytes in one UDP message.

The main questions are:

  • Is ~1200 bytes an expected Thread/IPv6 limit or an ESP-IDF/OpenThread configuration limit?
  • Can this limit be increased?
  • If yes, exactly which code or sdkconfig changes are required?
  • Are changes required on both the ESP32-C6 Thread client and ESP32-S3 + ESP32-C6 Border Router?
  • What is the maximum practical/recommended UDP datagram size over Thread?

It would also be helpful to document how this differs from sending a large UDP datagram over Wi-Fi, where the application can send and receive larger messages while the lower networking layers handle the underlying packet transmission.

If large single UDP datagrams are not recommended for Thread, guidance on the recommended production approach for transferring larger application data would also be appreciated.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions