Virtualized Mesh Network

Introduction

The virtualized mesh network helps to solve the problem of creating meshes using custom transreceivers. All the topology of the mesh is stored in Azure. Each node is classified as a relay node or a controller node (Base as commonly referred in Zigbee terminology). Recently a finish outfit has managed to connect a million IoT devices in a mesh, read about it on their website http://www.wirepas.com/

Therefore I wanted to do one better and make it more effecient utilizing the cloud infrastructure to do the heavy lifting done at Layer 3 of the protocol stack. The radio transreceivers should do the layer 2 effeciently with minimum computing requirements.

The controller node forms a star topology with the relay nodes. However the relay nodes can form a tree topology amongst themselves.

Background

The layer provides - host addressing, message forwarding and ad-hoc joining. For IoT messages wouldn't in most cases require reconstruction of messages, hence we wouldn't need to burden the platform with reconstruction of messages. As in zigbee, the communication works through the base controller. Node 2 can communicate to node 4 only via the base controller. Node 2 however can talk directly to node 1.

Ideally the network addressing for the mesh network would require addressing structure as this for layer 3 routing functionality at the protocol stack,

• Source Address – The 16 bit address of the device sending the packet.
• Destination Address – The 16 bit address of the device receiving the packet.
• Hop – The 16 bit address of the last system to relay the packet, this is used as the jumping off point of the return path. Hop can be set to the destination address in order to prevent relaying, and set to zero in order to request open relaying.
• Size – The size of the packet (bytes) including header.
• Packet Type – The type of packet, connection negotiation, ping, scan etc…
• Sequence & Response – The sequence and response are maintained using a counter and an initial random number which means that only the two systems involved in the communication will easily be able to insert packets into the network directed toward each other. This is not intended as a security measure, only as a mechanism to make it more difficult to inject rogue packets and to allow the mesh to easily maintain connections without using much memory.
• CRC16 – Cyclic Redundancy Check 16bit, the CRC is generated by setting CRC16, Hop, Hops and Attempts to zero when these bytes are in the zero state the packet can be summed and the sum inserted before transmission.
• Fragment & Fragments – Only required for packets which have data, and the data exceeds 239 bytes, the packet will be broken down into a maximum of 255 fragments and each fragment numbered for reassembly on the far side.
• Attempts – The attempts counter.
• Hops – The hop counter.

Virtualized mesh api

A simplified approach to implementing a mesh api on any radio trans receiver. Whenever a node receives a message, it would check in its routing table if its present. If its not present and its a new link address, it would send the message to the base controller with the link information.

Example from the above diagram, these would be the link information that would get sent to the base controller.

1 - 2

4 - 5

5 - 3

Using the link information, the service would build a virtualized routing table. Based on a-priori knowledge of data moved between nodes and link information an effecient virtualized mesh network would be built. The routing table gets updated occasionally with the new routes. For low power nodes, a star based mesh with base controller is the center would be best suited to minimize store forward on the nodes. Currently its under test for tree based topology where we would reset and OTA (over the air) update the nodes.

Each node would have an address and a channel to use for communication.

void begin(uint8_t _channel, uint16_t _node_address );
void update(void);
bool available(void); // check to see if the node is available
void peek(MeshHeader& header);
size_t read(MeshHeader& header, void* message, size_t maxlen);
bool write(MeshHeader& header,const void* message, size_t len);

using nrf24 radio transrecievers,

// nRF24L01(+) radio attached using Getting Started board
RF24 radio(9,10);
 
// Network uses that radio
RF24Network network(radio);
 
// Address of our node
const uint16_t this_node = 1;
 
// Address of the other node
const uint16_t other_node = 0;
 
// How often to send 'hello world to the other unit
const unsigned long interval = 2000; //ms
 
// When did we last send?
unsigned long last_sent;
 
// How many have we sent already
unsigned long packets_sent;
 
// Structure of our payload
struct payload_t
{
  unsigned long ms;
  unsigned long counter;
};

setup -

void setup(void)
{
  Serial.begin(57600);
 
  SPI.begin();
  radio.begin();
  network.begin(/*channel*/ 90, /*node address*/ this_node);
}

In the virtualized mesh, self discovery is minimal since the Azure deployed mesh topology manager would manage the topologies. The azure service publishes the topology to the base controller to be published to the relay nodes. This will update the routing topology of the nodes. The self discovery of the nodes relative to other nodes are initiated when the node boots up, it will send a discovery sos to the all the nodes. The neighboring nodes pick up the sos and passes it along until it reaches the base controller. The relative depth wouldn't exceed 6 nodes from the base controller. If it exceeds 6 nodes, then the route is dopped. In those cases, the virtualized mesh MDM would initiate a service to connect a base controller closer to this node which send the sos. Each node prior to being placed is given a unique location id for asset management in the MDM. This helps draw out the topology before the network sos calls are sent for auto discovery. The sos packet helps draw out the signal strength based on the environment the nodes are present. sos packets must have to be sent intermittently to provide enough information to the analytics engine about the environmental condition.

Adding additional base controller to maintain the depth of the mesh to 6, is not expensive. Since the communication costs are kept down by the MDM based virtual mesh. The MDM maintains the topology and gathers analytics from the base controller. More robust effecient routes can be created by the MDM as compared to the OSPF (shortest path first) computed by the chatty communication between mesh nodes. The MDM based mesh manager would help in bridging different trans receivers to the mesh, by implementing the simple api.

Points of Interest

It was a challenge to create a mesh with low cost radio transreceivers and creating a MDM based virtualized mesh helped allievate the issue. I will be growing the MDM platform to build analytics and improve the mesh api for adding IoT sensors anywhere in the world.

History

Keep a running update of any changes or improvements you've made here.