Ethernet over 802.15.4 radio

Mongoose can carry Ethernet frames over IEEE 802.15.4 radio. An NXP RW612 board bridges the radio nodes onto an Ethernet LAN. Each node gets an IPv4 address from the LAN's DHCP server and runs ordinary TCP/IP applications: HTTP, HTTPS, MQTT. No application gateway in between.

In this demo, an NXP MCXW71, a Seeed XIAO MG24 and a XIAO nRF52840 run the same Mongoose HTTP server and MQTT client examples. The application code is unchanged. The network driver handles the radio.

Why Ethernet over a low-power radio?

802.15.4 is the radio technology underneath Thread and Zigbee. Matter can use it through Thread. Those stacks make sense when you need their ecosystem and interoperability. They are a lot to bring along if all you want is a small web server or an MQTT client.

We already have a TCP/IP stack in Mongoose. So we added a radio link underneath it. Ethernet frames go in, radio frames come out. On the receiving side, the radio frames are put back together into Ethernet frames and passed to the stack.

This is a custom link protocol over 802.15.4. It does not make a node into a Thread, Zigbee or Matter device. The payoff is simple: existing TCP/IP application code works over the radio link.

The hardware in the demo

Board	Job
NXP FRDM-RW612	Ethernet-to-radio Layer 2 bridge
NXP FRDM-MCXW71	Radio node running HTTP, HTTPS and MQTT
Seeed XIAO MG24	Same applications on Silicon Labs MG24
Seeed XIAO nRF52840	Same applications on Nordic nRF52840

The RW612 has both Ethernet and an 802.15.4 radio, so it is a handy bridge. Its Ethernet cable goes to a USB Ethernet adapter on my workstation. Internet Sharing supplies DHCP and routes that Ethernet network to the internet over Wi-Fi. USB cables power the boards and carry the flashing and serial traffic. The node application traffic travels over radio.

You can connect the bridge to a regular LAN with a DHCP server instead. The bridge forwards Layer 2 frames; your existing router still handles routing to other networks. With Internet Sharing, the nodes are on the shared Ethernet subnet, not directly on the upstream Wi-Fi subnet.

The bridge gives everyone a turn

The bridge is the boss. It keeps a list of joined nodes and gives each one a chance to talk. There are two kinds of turn: JOIN and DATA.

1. The bridge broadcasts JOIN_DOWN: unjoined nodes may reply now.
2. Unjoined nodes compete to send JOIN_UP. Replies can collide here. A node whose request reaches the bridge gets added to its list.
3. The bridge walks that list. It sends DATA_DOWN to one node, with an Ethernet frame if it has one queued, or just a grant if it has nothing.
4. That node sends its queued Ethernet frame back in DATA_UP, or sends an empty reply. The other nodes stay quiet.
5. After every joined node has had a turn, the bridge opens another JOIN window. Repeat.

With three nodes, a round looks like this:

JOIN -> DATA with A -> DATA with B -> DATA with C -> JOIN -> ...

With no nodes, it is just JOIN -> JOIN -> JOIN until somebody joins. New nodes always get another chance, even while the network is busy.

Scheduled data exchange avoids collisions between participating nodes: only the bridge and the selected node may transmit, and they take turns. Nodes do not need to hear each other. They do need to hear the bridge and follow its grants. Joining still uses contention, and unrelated radio traffic can still interfere.

One Ethernet frame, several radio frames

An Ethernet payload can be 1500 bytes. An 802.15.4 frame is at most 127 bytes, including its MAC overhead. A full Ethernet frame plainly will not fit into one radio packet.

Mongoose splits it into a burst of small radio frames. The receiver reassembles the burst before passing the Ethernet frame on. A DATA turn has a downlink burst from the bridge, followed by an uplink burst from the node. Empty traffic uses short frames instead.

That happens below IP. DHCP, ARP, TCP and the application do not need to know about the fragments. The demo's scheduled strategy does not use per-frame radio ACKs. Scheduling prevents competing nodes from talking over each other; it does not guarantee that every packet arrives.

Run the examples

Start with the build environment instructions and the Mongoose repository. These are the projects used in the video:

Board	Source
RW612 bridge	tutorials/nxp/frdm-rw612/bridge
MCXW71 node	tutorials/nxp/frdm-mcxw71/minimal
MG24 node	tutorials/silabs/xiao-mg24/minimal
nRF52840 node	tutorials/nordic/xiao-52840/minimal

With the board's flashing tools set up, run make flash in its tutorial directory. Start the bridge, then the nodes, and watch the serial logs for the DHCP lease. Use that address from the LAN:

curl http://NODE_IP/

The video also tests HTTPS and exchanges MQTT messages through the public HiveMQ broker. The node runs the existing Mongoose MQTT client example. The same application code works on a wired STM32 and these wireless boards. Board setup and the network driver change; the HTTP and MQTT logic does not.

These examples run bare metal: CMSIS headers, small hardware setup code, Mongoose and a polling loop. No RTOS is required.

Latency, reconnects and limits

More nodes means a longer wait for your next turn. For comparable traffic per node, round time and worst-case waiting time grow roughly linearly with node count. Short or empty exchanges finish sooner than full bursts, so traffic volume matters too.

This is a single-channel star. Every node shares the radio bandwidth and must reach the bridge directly. It suits small requests, telemetry and control traffic. Do not expect Ethernet throughput just because it carries Ethernet frames.

If the bridge misses three replies from a node, it removes that node. If a node goes three rounds without a data grant, it drops its joined state and starts answering JOIN windows again. That lets nodes recover when the bridge restarts, without a manual reset.

Footprint and next steps

The version shown in the video has about 600 lines in src/l2_mesh.c and uses about 4 KB of RAM on a radio node. That is the radio networking implementation, not the entire TCP/IP, TLS and application footprint. The MG24 driver shown is under 200 lines.

Next on the list: more radio hardware, multiple bridges for redundancy, channel hopping, and routing through intermediate nodes. The demo today is a scheduled star. Multi-hop mesh routing is future work.