The RF24 Communication Stack: What are the different layers and which one do I use?

 The RF24 Communication Stack:

What are the different layers and which one do I use?

Over the past number of years, I've been developing a communication stack for nrf24l01+ radios, generally to be used with Arduino and Raspberry Pi devices. The comm. stack is organized into separate layers, per the OSI model, which allows users to establish communication between any number of devices depending on their needs.

1. The RF24 layer: This layer is generally used for simple device-to-device communication, where speed and simplicity are key. One example is for radio control of a single device, where a stream of small data packets are communicated from one device directly to another in rapid succession. Streaming of audio in real-time is another example where the RF24 layer would be used directly. Using the RF24 layer can be a bit complex, and some knowledge of radio communication is beneficial.

2. The RF24Network layer: This layer expands on the RF24 layer by providing a number of features, both to enhance radio communication and provide users with the features of an OSI layer 3 (network) layer. RF24Network nodes are arranged in a static tree topology, and this layer provides all the features to manage them. RF24Network handles routing, fragmentation/reassembly of large packets, and communication to any other device is straight-forward. Users don't require knowledge of the RF24 layer to operate a network of nodes at the RF24Network layer, and it can be much simpler than using the RF24 layer directly. Recommended when not able to use the RF24Mesh library, when there is a need for static nodes, or to simplify one-to-one communication.

3. The RF24Mesh layer: This layer expands on all underlying layers by providing an automated, self-healing network that allows nodes to move around and or re-establish connectivity as required. This layer is generally recommended when creating a network of devices, as it automates addressing for RF24Network, and provides a more seamless interaction. Users generally communicate using the RF24Network API, with RF24Mesh providing address lookups and automation for the network. 

4. The RF24Ethernet/RF24Gateway layer: This layer allows communication using standard networking protocols, such as TCP, UDP, ICMP. It is generally recommended to run RF24Gateway on a Raspberry Pi as the master node, with smaller devices running RF24Ethernet. Allows very simple or very complex communication scenarios, with users requiring little to no knowledge of radio or RF24 programming APIs. 

The RF24Ethernet API is very similar to the Arduino Ethernet API, and RF24Gateway allows users to use standard networking tools to communicate with devices running RF24Ethernet. Recommended for communication scenarios where speed is not essential, but reliability and consistency is, such as a home automation system using MQTT and Node-Red and/or a sensor network reporting data. Users can run a wireless, Arduino based webserver, or interact with nodes using their mobile device over MQTT, HTTP, etc. 

As can be demonstrated, each layer has its place, providing communication capabilities for a very wide range of scenarios, and allowing users to benefit from the built-in features or to dig right in and customize things to the nth degree. Generally, the higher you go up in the stack, the simpler the interaction, with complex underlying code providing the simplest and most advanced user interaction.

Related Code and Documentation:


Arnaud said...

Love you work, been using RF24Mesh for 5 years and still loving it, my dream is to make a network of solar powered mesh nodes around my region to control a UAV with extra long range, i will soon start working on it.

TMRh20 said...

Thanks, that means a lot. Sounds quite challenging, good luck! If you have questions along the way, don't hesitate to ask.

Sullivan said...
This comment has been removed by the author.
Sullivan said...

Really love your work. And I find your project a very intriguing angle to study OSI model and computer network theories.

One question - how did you implement medium access control? - Since almost all high throughput wireless communication systems implement some medium access control, such as CSMA/CA in WIFI (802.11 family) or CDMA/TDMA/TD-CDMA etc. in 3G cellular communication, how is medium access protocol implemented in your project? Should I look into nRF24 (OSI layer2) or other library if I want to research or even improve this?

TMRh20 said...

Interesting question. MAC is mostly implemented at the RF24Network layer. It uses a set combination of radio address bytes an converts them to Octal RF24Network addresses. The code for it is relatively simple and uses a tree topology to arrange the network. RF24Mesh also uses higher layer addressing for its nodes, but the MAC layer is mostly in RF24Network.

Sullivan said...

Thanks for the quick reply.

From what I understand, there are two key components in MAC.

One is addressing which I more or less understand after reading relevant code segments.

The other is channel access control mechanism which I am not sure which code segment to read.

Specifically, in case multiple nRF24L01+ node send data simultaneously in the same room, since they are likely to use the same channel in 2.4Ghz band, collision may happen and the receiving node may not be able to hear the packet. How to resolve this collision? Did you use CSMA/CA like in WIFI(802.11)?

TMRh20 said...

The radios have some features (ESB or Enhanced Shockburst Protocol) that uses a series of timed transmissions to deal with collisions. For this you would want to read the nRF24l01+ datasheet. Essentially, you can configure the radios to retry payloads at timed intervals (staggered intervals in the case of RF24Network) up to 15 times per payload. This is implemented at the physical layer and managed at the data-link layer (the radios themselves and radio driver) and RF24Network extends this capability with extended retries. Essentially, the feature is build into the radios themselves.

TMRh20 said...

Also, see for the relevant code

NRF52840 and Arduino: Encrypted and Authenticated Radio Mesh Networks

 NRF52840 and Arduino:  Encrypted and Authenticated Radio Mesh Networks In a recent post, I mentioned using the on-board encryption module o...