Launching MESH Networks on Pycom

[Bettina]

(Here's the Blog we just published featuring @catalin https://bit.ly/2mk7KhS)

So, we’ve been busy over the last few months implementing a brand-new MESH solution. This works on all our development boards (LoPy4 and FiPy) and OEM modules (L01 and L04) that support LoRa and it’s an industry first we think!

To give you a bit more insight, we interviewed one of our developers who has been instrumental in the delivery of this new solution. Here we give you a bit more info about the MESH implementation and what’s possible with it. Here’s what we asked and what he said:

What has the implementation been based on and why?

The implementation of LoRa MESH is based on open-source project OpenThread (https://openthread.io) actively developed and supported by industry leaders. Although, Thread is based on 802.15.4-2006, the high flexibility and layered architecture allowed us to port it on LoRa Radio.

Lots of features are already ready out-of-the box, such as IPv6, 6LOWPAN (packet fragmentation), UDP, DHCP, PING and security.

What amazing things can people do with it?
MESH networks allow users to decentralise the network architecture, basically they don't need to care about radio links anymore. The network will create, adapt and heal itself.

For example, for covering a large area, the user can deploy LoRa nodes, which will need at least one radio connection to connect the MESH network. Next, a designated LoRa node will be the Border Router, taking all MESH-traffic to the Internet (for example by relying packets on WiFi backhaul).

Moreover, the nodes’ position may vary, and with our implementation, the MESH network will auto-configure based on Radio signal strength.

Each device from the MESH network can communicate with any other node. And all of them can communicate to Internet (through Boarder Router).

Meanwhile, LoRa's wonderful low power and long range are maintained.

What are the limitations?

LoRa limitation still apply to MESH-network, low data-rate, limited air-time.

This makes the Thread network to have a bigger delay, in network discovery and propagating changes. This is compared with a hardware 802.15.4 MAC capable Radio modem.

In this development build, nodes are FTD (Full Thread Device), by default, they will always listen and rely packets. The MTD (Minimal Thread Device) can be obtained with an additional build (recompile).

What will come with next releases and when?

At the moment, the basic data transfer mechanisms are implemented (UDP Socket, PING, IPv6). We intend to add a solid Border Router functionality and additional data security which will be audited and improved soon.

Based on feedback from our community we would like to enrich our current MicroPython Loramesh library.

A new release is targeted for mid-August 2018.

The main message for me here is that we need lots of community feedback. It’s going to be interesting to see everyone gets up to with a new Lora MESH network.

More information Here
Example scripts: https://github.com/pycom/pycom-libraries/tree/master/lib/lora_mesh
Release: https://forum.pycom.io/topic/3480/new-firmware-development-release-v1-19-0-b4/13
Docs Tutorial: https://docs.pycom.io/v/development_release/tutorials/lora/lora-mesh.html
Docs LoRa class: https://docs.pycom.io/v/development_release/firmwareapi/pycom/network/lora.html

[David B Santiago]

This can only be done when the data transmission rates within the mesh network are very low.

[Bettina]

@ioag apologies, I missed your post. We already have discounted LoPy4 kits available in on the webshop and they'll work for this ;-)

[catalin]

hi @brotherdust, the Bluetooth Mesh is on tests in Espressif (took a long time). Once it's released we'll incorporate it.

[brotherdust]

Really impressive, folks! Thanks for all your hard work!

One question: any plans to enable this for Bluetooth as well? =D

[IOAg]

@bettina MESH will greatly reduce hardware cost, as @philwilkinson highlighted, mesh network allows to reduce number of gateways and takes advantage of all nodes for communication.
Also MESH layout fits well in rugged terrain and remote area to provide private LPWAN. Yet, MESH border router needs bridging to to other LPWAN (LoRaWAN for instance), it is about the entire ecosystem.

Do you envisage to offer a LoRa Mesh kit (5-10 nodes) to trial in real life?

[Bettina]

@philwilkinson Thanks for highlighting.

Here are the correct links:

https://docs.pycom.io/v/development_release/chapter/tutorials/lora/lora-mesh.html

https://github.com/pycom/pycom-libraries/blob/master/lib/lora_mesh/main.py

[philwilkinson]

@catalin thanks for the response and the hyperlinks.

It is a very economical design to have a mesh network of LoPy nodes acting as sensors/actuators but with only one LoPy Node in reach of a LoRaWAN gateway.
Actually it reduces overall cost because less gateways are needed (which are far more expensive than Nodes). Only gateways need to be connected to the internet if the border router can publish via LoRaWAN

There is clearly the constraint on the payload/interval/datarate for any LoRa transmission. Could this constraint be applied separately by the mesh network and LoRaWAN classes?

I am not recommending that the Border Router acts as a 'dumb' router; simply passing through datapackets from the mesh network to the lorawan gateway. This can only be done when the data transmission rates within the mesh network are very low.
Beside, this is just wasting the power of a Pycom ESP32 module!!! My particular use case is that the border router would unpack the data from the mesh network, do some edge computation and then publish some consolidated/summarised data via LoRaWAN. Obviously the Border Router would be unavailable from the mesh network for the time it is transmitting packets to the LoRaWAN gateway.

[catalin]

hi @berlin and @philwilkinson,

Scripts: https://github.com/pycom/pycom-libraries/tree/master/lib/lora_mesh
Release: https://forum.pycom.io/topic/3480/new-firmware-development-release-v1-19-0-b4/13
Docs Tutorial: https://docs.pycom.io/v/development_release/chapter/tutorials/lora/lora-mesh.html
Docs Lora class: https://docs.pycom.io/v/development_release/chapter/firmwareapi/pycom/network/lora.html

Quite interesting the scenario, to have a Border Router to LoRaWAN, it's not impossible and I need to do some tests. Yes, Border Router, could turn-off Mesh interface, and turn-on LoRaWAN interface; though this is not exposed in micropython. Maybe you could help with setting up specs for this scenario.

My assumption would be: Border Router is able to unpack all mesh traffic going "extern"(to LoRaWAN) and can forward (re-pack). Right/wrong?

[berlin]

@philwilkinson that's exactly also my question. thx

[philwilkinson]

@administrators 404 on all your links in this announcement unfortunately.
Can a LoPy acting as the Border Router flick between LoRaMesh and LoraWAN for transmission to a gateway?