We at Datarella are working together with the UK Department for International Development’s (DFID) innovation and future technology program, Frontier Technology Livestreaming (FTL) and the European Space Agency (ESA) to increase efficiency within humanitarian supply chain.

Our goal is to maximize the value, which is arriving at the people in need by establishing transparency and collaboration between the responsible supply chain stakeholders. In part one of our blog post series, we described how we tested our Track and Trust System. For testing, we tracked a live shipment of 304 family tents from Pakistan to Dubai between the first four parties of DFID’s supply chain. In part two, we described the challenges, which occur when tracking the last-mile of the deliveries. In this post, we are going to go further down the rabbit hole and dive into the technology, which will enable us to overcome the Sisyphean task of last-mile supply chain tracking. 

The story starts after the implementing partner received the goods, loaded the trucks and the driver starts his way to the destination in the crisis area.
The environmental circumstances surrounding humanitarian missions are highly heterogeneous and can range from tropical islands after a hurricane to newly built refugee camps close to a war zone. However, the one thing they have in common is that within the first few weeks after the disaster took place telecommunication infrastructure mostly is not available.

Despite these difficulties, to provide stakeholders within the supply chain with an overview about the current status of the deliveries, we at Datarella are working to test the usability of a LoRa-based Mesh Network which transmits the transaction data offline until it’s finally able to be posted to the blockchain via a satellite uplink. We’re partnering with our friends at Orora Tech who know the ins and outs of the satellite technology quite well since their main business involves the manufacture of nanosatellites. 

Our solution consists of the following components:
1. A user interface implemented as a progressive web app with offline capability
2. A LoRa-based Mesh Network
3. A Globalstar satellite uplink
4. A private permissioned Ethereum Blockchain

Whenever a transfer of goods occurs, the involved parties, e.g. the truck driver and the consignee in a base camp, will use their mobile phones to prepare the necessary blockchain handoff transactions offline. Data about location, time and custody will then be saved within the progressive web app interface (including pre-signed Ethereum transactions when possible).

Then, to transmit this data without having an internet connection, we are planning to use a LoRa-based mesh network.

A LoRa network can be described by its two main characteristics. 

1. As the name indicates, it allows long-range transmissions with a reach of approximately 12km in rural areas.
2. It operates at low power consumption. 

Further, the term “mesh network” describes a network composed of nodes, which connect in a direct, dynamically and non-hierarchical manner. Therefore, these networks are also referred to as “self-healing” since nodes can organize and configure themselves, which allows the network to persist even if some nodes are not available.
For creating a Pymesh LoRa Mesh, we are planning to use  LoPy4, a 4-network (WiFi, BLE, LoRa, and Sigfox) and MicroPython combination controller. Further, we are considering to either equip some of them with Pytrack carrier boards, for very accurate GNSS Glonass GPS. An alternative method of geolocation is to feed in GPS data from the mobile phones of the drivers. 

The network is implemented using OpenThread, an IPv6-based networking protocol. The reasons why we decided for this network type are its following features: 

• Simplicity — Simple installation, start-up, and operation
• Security — All devices in a Thread network are authenticated and all communications are encrypted
• Reliability — Self-healing mesh networking, with no single point of failure, and spread-spectrum techniques to provide immunity to interference
• Efficiency — Low-power Thread devices can sleep and operate on battery power for years (Dependent on how often they wake to transmit)

To create the Pymesh network, we are planning to install LoPy4s on the trucks, which are used to deliver the humanitarian goods to their destination. As soon a truck gets within the reach of another network node, it will transmit the offline transaction to the next router. The transaction will travel through the network node by node in this manner. Here you see a prototype 

Since the reach of the LoRa routers is limited to approximately 12km we are also playing with the idea to install an air-based router, using a fixed-wing drone or a weather balloon, which would extend the reach up to 500km. 

So far so good. Now the transaction data will be transmitted from truck to truck until it reaches a border router, which is connected to a satellite network. So far we have tested an uplink for a very basic JSON RPC transaction over a Globalstar simplex transmitter and successfully sent two data packets to the Globalstar constellation. Each contained a portion of the data needed to make an Ethereum transaction.

After the transaction data is sent via short bursts to the Globalstar constellation it will be received from a ground station, which is connected to the internet and executes the signed transaction in a live blockchain.

Together all of these components should enable a humanitarian agency to roll out tracking for their assets and provide transparency across their entire supply chain despite the total absence of telecommunications infrastructure in the last mile environment. All of this will be backed by a blockchain ledger providing the stakeholders in the humanitarian supply chain a single source of truth regarding custody all the way up until the final aid delivery.