Mesh use cases

before talking too much about mesh concepts, let's see end results what useful things can we get of this ?

Flood versus Routing

This is a Flood mesh type opposed to routing mesh types.

• With a Flood mesh, Zero configuration is required, just throw nodes in, every node has its id.
• A Peer to peer message just need to know the destination id, the stack handles an end to end acknowledge with retries if necessary.
• This type of mesh is router less, which means it get advantages such as
  • the nodes do not need routing tables to define the shortest path
  • which is also hard to configure if the nodes move or would have to be identified on startup.
  • A routing mesh would also require a central server or duplication of management in every node acting as a server.
• But there's no magic in here, a Flood Mesh have some compromises to do which might be completely irrelevant in some scenarios.
  
  • The mesh Range is as wide as you have nodes and capacity to live through jumps, yes but then why don't we use a huge time to live for an endless range ?
  • Well the problem is the echo, as the nodes have no routing info, they will keep repeating messages to each other, even back to those they got the messages from !!!
  • This Echo is born from the flood concept itself, it reaches all the nodes around who keep singing along for one single message until that message dies.
  • During a time to live group repetition, all the impacted network is busy with that single message. which highly increases collision chances and messages loss.
  • In the scenario of a home, this compromise is not of much relevance as you barely need a single repetition jump, one Time To Live can get you through a villa, and two through a huge building, this is not fit for a city network as its name says this is a #Home Smart Mesh.
• As two nodes listen to an RF message at exactly the same time, they are likely to react with a repetition at exactly the same time as well. To avoid that, every node uses a per id delay configuration to repeat the message with a shift in time.

Leaf versus Repeater Nodes

Leaf Nodes are acting like beacons. They are wireless low power sensors that cannot keep listening, thus the frequent Broadcast for them is strategically a better compromise than a Message to a server. The unpredictable time listening waiting for the acknowledge can allow to re transmit much more frequently with the same power budget. Additionally, these nodes do not need to be configured to know the server Id.

The Mesh Protocol

• This Mesh protocol was custom designed to take advantages of the hardware it was designed with. The reason it is different than others is simply that the RF transceiver nRF24L01+ is much cheaper. With up to x10 times cheaper, well you get some side effects such as packet size limitation. With 32 bytes, if your protocol header is big, well then you have no more room for a payload.
• The protocol above uses only 8 Bytes at max while fulfilling all conditions of end to end addressing, redundancy checks, acknowledgment and repetitions.
• By design, messages do not have time stamps nor sequence ids, which let the multiple repetitions reception be filtered at the destination side. That means that yes, filtering time has to be slightly higher than the Flood echo time, and the sensors broadcast frequency must be slightly lower than the listeners filtering time.
• The only complexity we get here is in the Pid that has been compacted to handle both the message type (e.g. Temperature, rgb color request,...) and the message status, if it is a broadcast or in case of peer to peer Request or response.
• The source and destination being part of the user software protocol solves the problem of all radio transceivers that have hardware pipes with addresses. Those addresses have to be configured depending on the network and the number of pipes is limited for the nRF24L01 to 5. Well, it is nicer to have more than 5 nodes in your mesh !!!
• The HW acknowledge of the shock-burst is also a waste of resources in a mesh use case with a flood concept as it is a point to point acknowledge opposed to the software one we use which is an end to end acknowledge. The point to point acknowledge is useless here because if two nodes might be interested by repeating the message then which one should send back this acknowledge ? The end to end acknowledge is abstracted from the mesh protocol and the destination decides to send it back as another normal message.
• The CRC is only calculated once and is an end to end CRC, which means that we do not care if a single step has failed as the source is expecting a feedback and would retry otherwise. That makes the intermediate repeaters more efficient and faster to reduce network occupancy time.
• Note that the repeaters can read the message content to know the complete repeated message size which is here the third byte + 2.
• The first byte then limits the size of the messages to a lower value than the id itself, buy here as we use the nRF24L01+ with 32 bytes of payload size, it is safe to use even more bits from the first byte, or scale to another transceiver for up to 222 byte payload.

Security and interoperability

• Security is not forgotten, but omitted here, as not required by this simple standard and left to further customization inside the user's payload. If it is a light sensor which information can also be spied through a window within RF broadcast reach, then why bother protecting it ? But let us be careful here in a way that the server bridge who have internet access must be highly secured that is out of scope of the RF network. Ideally the server access ports are not opened from the router, remote access to the server can for example use a VPN which was the solution I opted for not to bother with custom coded SSL. Note that VPN does not require a third party provider if you get a router that supports the functionality.
• If your neighbor has the same system, you're also covered, as you have 5 bytes of HW addresses that will be shared by all of your nodes, to have a very unique mesh network.

Yet another protocol to for IoT ?

• In a quick evolving IoT scenery we're not lacking network protocol, so why using a custom one ?
• Standards want to cover a big number of use cases which makes them either inefficient or complex, or both.
• Wifi requires considerable power and sw stack size.
• Bluetooth brings the mesh in its version 5, wait few years till you get devices supporting it, who know how much these would cost given the increased requirements in payload size,...
• Zigbee hits the target as it was designed for it, but how much does any 802.15.4 transceiver cost, you're lucky if you get one just x10 times more expensive than the nRF24L01+.
• This Home Smart Mesh Flood implementation in a running bridge application uses overall barely 4 KB including text logs and multiple unused functions (modules non optimized), which makes it fit for ultra low cost devices.
• Without mentioning a last but not least argument, which is simplicity and speed of development which even fits DIY context, as the whole thing can be described in one slide as presented above.