What is WaDeD?

WaDeD stands for Walking Dead Drops. A dead drops is an espionage method, which point is to leave a message in a secret location, known by only the receiver, and he will come and take the message at the specific place. WaDeD takes this concept and improves it, with the advantages of the wireless technologies. WaDeD is composed of two kinds of modules, some fixed and some mobiles carried by users. The users use the mobiles one connected to their Android, and thanks to an app, they will be able to send a message to someone and leave it in a fixed module. But wireless technologies offers more, and even spies would rather not move to get a message. So we are going to use every WaDeD modules as a drop box and will stock every message send. The network don’t have a fixed structure, we have no idea were the receiver is located or if he is even reachable, so every message will flood the network increasing the chance to deliver the message.

WaDeD is a mesh-network, allowing friends to communicate between them, without using 3G network, or any usual paying network.

In the following description of the project the fixed modules will be called Stones and the mobiles one Zombies.

This article will be changed depending of what we decide about the project.

Our Specifications

We need the Stones to be independent, so we have to reach incredible low power consumption level, in order that the Stones can last as long as we can with no maintenance.

The Zombies need to have an autonomy of an expedition (1 or 2 days).

We want a Radio Frequency protocol that have the best range with the lowest consumption. We want that the precise locations of the stones stay hidden. So we want the basics users to received the message by being in the biggest possible sectors.

The Messages

We choose to limit the message size up to 140 characters, just like a Tweet or a SMS (remember the time where you haven’t unlimited SMS?). We know it’s not a lot, but millions of Tweeter users can say it’s already enough. But we are going to implements other type of messages to specific situations (see Use cases), in order to say more with less data.

Use Cases

Here a description of several use cases we want to implement in WaDeD

Communicate with a friend

The user will just want to sent a text message to a friend, to just chat or say how cool where he stands is. Only the other user should be able to see the message.

Set up a meeting

The user wants to invite one or more users to a meeting. She will communicate the place and time at which the meeting takes place. She may want to know whether her message got through or not. Only the selected receivers will see the messages.

Acknowledge a meeting

The response to an invitation. The user may accept or decline a meeting.

Communicate with everyone

The user wants to announce a gather up of some kind, or signal something. Every other user should be able to see the message.

When two users meet

They want to exchange their addresses and public keys to be able to exchange messages in the future.

Trace another user

The user may want to know when is the last time a certain other user was there. She should be able to ask the stone (see “broadcast location”).

Battery status (administration privileges)

Get the battery status of the stones. Each stone may for instance communicate its battery status each time it encounters an user. When propagating, newer data about the stone should replace older data. Recognizing a stone should be easy for the administrator, so he should be able to list them by name.

Firmware update (administration privileges)

An administrator may want to broadcast a new firmware to the stones. Stones should pass the update through the network automatically in packets. When a stone has a complete update, it should reboot automatically on the new firmware.
As this induces vulnerability, the security of this procedure should be dealt with extra care.

Broadcast to surrounding (for stones only)

The stone sends a message to every user around, a warning for instance.
This message is not the be relayed.

Send battery status (for stones only)

See the similar part for the administration uses

Broadcast location (for stones only)

Send a message to everyone each time a user come saying that this user was
here.

Architecture

For more information about our choice I invite you to check up the component survey we made.

Microprocessor Unit

We are going to use a STM32L151CB, the low power version of the STM32. It’s among the lowest level of consumption and we are already familiar with the STM32 family.

Flash Memory for Messages

We choose to use a FRAM (FM25V20 by Ramtron). Communicating on SPI Bus, this type of RAM offers speed and non volatility of the data as a Flash. It offers also good consumption characteristics.

Radio Frequency Solutions

DASH7 (433MHz)

The 433MHz offers range and consumption level characteristics very interesting. The tests was quite satisfying but not as much as JP Norair or the Wikipedia page of the DASH7 announced. Anyway this looks like the best solution, the test was based on WizziMotes by WizziLab, we hope to increase the range and consumption level, by using the SX1231 by Semtech.

The SX1231 is a transceiver sub-1GHz able to transmit up to +17dBm, we are not going to use it at +17dBm because of technical conditions for the PCB that are too strict. But we can at least use it at +13dBm. It also show very interesting consumption level. (Recall, you can check out our survey here). We have succeeded to implement a radio layer based on Dash7 protocol, and the CSMA in order to reduce the interfered messages.

Here is the Schematic of the architecture, and what our PCB looks like.

Image may be NSFW.
Clik here to view.Image may be NSFW.
Clik here to view.

The main objective on this architecture are to make the radio layer, that works for the WaDeD software.

Wake-up Circuits

You should have notice it on the schematics. We offer a micromatch plug where we will be able to connect wake-up circuits. The STM32L has 2 wake-up pin, that can wake-up it from sleep state. The micromatch has 6 pins, two for each wake-up pin, one for the ground, one for a constant power supply, and two connected to GPIOs of the STM32L, to supply power only when the we want (or other . We give to us all the tools to do the best wake-up circuits for where the stone will be.

We have already made tests for a Light wake-up circuits, and a Audio one.

The WaDeD Protocol

First of all, there no guaranty that a message will be delivered.

Wake-up Policy

The stones wake-up when the wake-up circuits indicates to wake-up or periodically (time to determinate). The Zombies have less consumption problems so they will wake-up periodically.

Stateless communication:

The main idea of this communication is that each WaDeD when receiving a message has no idea which messages were sent before. Each WaDeD will only send one message spontaneously, a message composed by the sons of the top hash node. All other messages will be answers for a message received.

The Hash tree

5 levels:

Level 0: Top hash. We’re going to a solution where there is two top hash

Level 1 to 3: Node with 8 sons

Level 4: Messages lists

The top hash is virtual, in the messages that we sent, to sync, we send directly the two sons of the top hash, instead of the top hash. The parse of the two hashes has the same purpose as the top hash.

Nodes are identified by a number 0 to 146 (8 bits)

Messages are identified 0 to 1023 (10 LSB bites of the 64 that compose its hash

As said, all WaDeD will have trees with the same structure, the only thing that can change in each tree are the values given to each node (which represents different messages that needs to be transmitted). Ideally, every node will also have the same value, which means they have the same messages, so no message exchange is needed.

Conflict policy

There may have conflict when we add a message in hash tree, two different WaDeD may have set a message at the same place in the hash tree, and when we try to merge them, a conflict appears.

The location in the hash tree is set by the 10 bits LSB of the hash that is associated to the message. It could appears that several messages have these 10 same bits. So they have the same position in the hash tree.

The solution is to put them at the same position, and using a chained list ordering the messages. there should be few collisions so the comparison of the lists, quick.

How the communication works:

Each WaDeD will only send one message by themselves, which is a message containing the Top hash. Actually it will contains the two sons of the top hash, sending the two sons or the top hash is the same, except that the top hash only doesn’t indicates which branch has the differences. All other messages will be created in response to a received one.

Once a WaDeD receives a message, it will interpret it, and send a proper answer if needed. Once the answer is send, the WaDeD forgets which was the question, and also forgets that he has answered something.

First part: Synchronising the trees

If we receive a message that represents a node from our tree, but has a different value than ours, we’ll check which of our sons have the different value, and will send a message that will be composed of it’s sons. When we receive a message that represents a node from the tree, our answer will never be an upper node,

If the different son is a leaf, we analyse the hashes, two situations can be concluded :

1- We have leafs that the other doesn’t or we both have the leaf, but not the same hash. We start the synchronisation of the associated chained list.

2- The other WaDeD have leafs that we don’t have, so we send our sons from the same node, so when the other WaDeD receives the message, it will fall in his first case.

If we happen to fall in both states in the same time, the first one is has the priority, which means we’ll first synchronise the leaf that we have and only then we send our sons. It’s in order to avoid the situation where two WaDeD keep sending their sons to each other and no message is send to change their state, leaving them stuck in a loop.

Other important point: When we receive a message that represents a node from the tree, our answer will never be an upper node, if that happened we could enter in a loop state since the answer could trigger the same message that generated it. The only case that we don’t move down in the tree is the case 2 explained above (which don’t generate an infinite loop).

Second part: synchronisation of a chained list

A chained list is identified by a hash, made from the parse of all the hash of the messages containing in the list.

In order to sync the list, if the list is composed by only one element, the WaDeD that analysed that the message has to be sent, send directly the message, and let the others analysed, conclude if there is something to do, and add it in there hash trees.

Else, we send the hashes of the messages contained in the list.

Same as above, if the other realise that he is the one that need to receive message, he will send the hashes of his list, to the other.

The send of a message analysed as “to be sent” has the priority above all messages.

A small sequence of messages:

We have two WaDeDs, ‘A’ and ‘B’. ‘A’ has no messages and ‘B’ has only 1 message.

‘A’ or ‘B’ will send the only message send spontaneously, their top node and it’s two sons.
We’ll suppose ‘A’ was the first one to talk. ‘A’ Sends a message with it’s top node and it’s 2 sons. B will receive it, and will realise that his top node hash is different from the one he received (he has no idea who sended him that top hash)

Type of messages :

- Top Hash (level 0)

MAC | 0 | Top Hash (optional) | Son hash 1 | Son hash 2

- Nodes for level 1 to 3

- Leaf (level 4)

- Message

MAC | Hash | msg type | msg

Erasing policy

We though about using a tombstone policy. The point is once the message is delivered, the receiver send a “Tombstone” that acknowledge that the message is received and that we don’t need to sync this message anymore. It implies to only sync the ID and replace the pointer in the leaf by the NULL pointer (or a specific value that indicates that this is a tombstone).
In this case we shorten length of the radio synchronisation.

To free up memory of the tombstones or undelivered messages. Every message has a expiration date and the program will often check for expired message, and erase them from his memory.

For now we will only implements the expiration date, without tombstone.

The Android Application

The Android application is the interface between the stone and the user. It will communicate the user unique ID to the Zombie his connected to (the equivalent of a telephone number) and the Zombie will deliver the messages addressed to this ID to the Android application.
The user will only see a typical message application: he will receive his messages and send some and will have a contact list.
The contact list will contain the name, ID, and public key of a friend.
Thanks to the status messages the application could display a map of last seen people.

The WaDeD group

Tags: WaDeD