3KM Mesh link using Mesh Helper Prototypes

After the short-range testing of the mesh helpers, we then set about creating a longer-range test so that we could determine the maximum useful range.  

As part of the exercise, a VHF repeater was located on a prominent ridge, and this seemed like a good place to put a mesh helper to give us the chance to setup some long-range links.

The VHF repeater is on the left, and our mesh helper is hiding under the plastic bag on the right to keep out of the sun.

Here is a closer view of the mesh helper lashed to the fence post before receiving the plastic bag.  You can get an idea of the kind of vantage point where the gear was placed.

We then proceeded to drive along the road towards Pongaroa with one of the mesh helpers in the car with us.  Monitoring of link budget was using the built-in diagnostic webpage that we incorporated into servald.  

That web page provides continuous link budget, calculated as difference between RSSI and noise-floor recalibrated into dB. I am not completely confident in the reading from this, but it is a good general guide.  

For those interested, the radios we are using are transmitting at +30dBm, and using +3db antennae, that are admittedly poorly placed next to a large LiFePO4 battery and other gear in the buckets. Receiver sensitivity is around -121dB @ 1200bps, and so should be expected to be around -100dB @ 128kbps, giving a link budget of around 133dB.

Earlier, we had setup a second site nearer to the cottage, the results from which are marked as "site 2" in the following table.  The primary site by the repeater is approximately 1km from the cottage, almost in the opposite direction from the road we travelled along, so the distances here are underestimates of the actual distances.  The 2.65km and 2.68km records almost certainly correspond to actual distances of >3km.

The road varied in altitude, and had a lot of road-side vegetation and forest in places, as well as hills completely occluding line-of-sight to the sites where the other mesh helpers were located.  This is reflected in the varying link budgets as we travelled along the road.

Link Margin versus Distance

Link Margin	Distance to Cottage	Notes
11dB	0.36km	Adjacent to the bridge
6dB	0.75km	road side
30dB to site 2	0.76km	road side
13dB to site 2	1.00km	road side
12dB	1.19km	On the hill side
18dB	1.33km	hill side
21dB	1.38km	track
10dB	1.48km	Side of road, next to a gate
2dB	1.63km	road side
13dB	2.00km	road side
23dB	2.00km	parked, antenna vertical
20dB to site 2	2.19km	road side
10dB	2.5km	While driving
22dB to site 2	2.65km	road
3dB to site 2	2.68km
14dB	26.02km	Steady 14db margin, but no lock/link.

It is nice to know that we could maintain a link over distances of around 3km. There were of course spots along the way where link was not possible due to vegetation, hills and other obstacles getting in the way.

Between 3km and the 26km there were hills blocking any line-of-sight, and so measurements were not possible there, except in one place at around 12km, where we could not detect signal.

3KM is way short of what we believe these radios to be capable of, as reflected by the strong link budget (22dB) at around that range. Certainly 12km should be plausible, if not possible.

We are exploring a number of possible reasons why we were not able to obtain links at these distances.

One of the main culprits we are exploring is the forward error correction on the radios.  Currently they can detect and correct 25% BER in every 12 bits.  However, there is no block code or convolution code to allow graceful handling of bursts of errors. The addition of such a code should allow links at greater distances. The 14db reading at 26km, which was steady over several minutes, offers tantalising hope that with improved error correction links over such distances may be possible.  It is also possible that the number of black spots nearer might be reduced by such improvements in forward error correction.  

Something like Turbo Codes would be ideal, but are too complex to implement in the radios, but could be implemented in the wireless router.

Another source of trouble is the prototype units themselves, where all the components are sitting together in a plastic bucket.  There is almost certainly interference, occlusion and other problems occurring as a result.

It is nice to know that several kilometres is possible, and that there are some obvious areas we can work on to improve the range further.

What is significant is that the mesh helpers extend the range to useful distances, compared with the native WiFi capability of smartphones, as the following table summarising our experience shows.

Link Margin versus Distance
(with omnidirectional antennae)

Setting	SmartPhone WiFi	Mesh Helper
Urban, through dwellings	~20m	~200m
Vegetation	~20m	>300m
Rural	~200m	>3KM

Note that we are concentrating on omnidirectional antennae here, because our focus is on networks that are easy for normal people to setup, without having to aim antennae or have significant radio experience.

The Mesh Helper takes the range from being about one house to potentially tens of houses in distance, depending on the setting.

Thanks to the square rule, this means that instead of covering perhaps just one house, this means that we can cover potentially hundreds of dwellings with one unit, thus reducing the density of units required to establish a network -- which is precisely what we set out to achieve.

If it turns out that with improved forward error correction we can push those ranges out further, then the benefit will be even greater.

One of the next steps will be to reduce the size of the mesh helpers to mobile-phone size, to make them truly portable, which is entirely feasible as the core electronics are already small enough.

Mesh link using our prototype Mesh Helper through ~200m of forest

Yesterday we setup a test link between two buildings here on the field exercise.  The distance between the points was about 300m -- in theory short enough for a good WiFi link, like between a pair of Mesh Potatoes.  However, mobile phone WiFi has poorer range for a variety of reasons.  Also, there was 200m or so of damp forest in between, so any WiFi link would be likely to have problems.  You can see the situation here:

A perfect chance to try out our prototype Mesh Helper devices with their UHF packet radios. Basically they look like this, with a OpenWRT router, UHF packet radio and a big LiFePO4 rechargeable battery in a plastic lunch bucket:

So we put one mesh helper at the wool-shed (the building on the left of the image above).  The landing of the wool-shed was ideally situated, a bit elevated and facing towards the other building:

You can see the whole of the front of the wool-shed here.  The large antenna mast is a HF radio link that is part of the exercise.

At the other end, we tried placing the other mesh helper on the roof of one of the out buildings where it was close enough to provide WiFi coverage for nearby phones, but hopefully provide a link to the wool-shed.  

Unfortunately the roof was almost completely blocking signal, and so we didn't quite get link to the wool-shed from there.  But by moving the mesh helper to the back of an adjacent building we got a strong signal (indicated by the RSSI and link-lock from the radios), although I forgot to write down exactly what the link budget was.

We then sent a message from the wool-shed back to the operations room near the other mesh helper device, which was successfully received:

What is nice is that all we have to do is to place the boxes, and everything connects automatically, keeping with our zero-configuration ideal for Serval Mesh networks.

The next step is to do some longer-range tests with one of the units on a good vantage point, so that we can get an idea of the maximum range possible with the current configuration.

Building Serval Mesh Helper Device Prototypes

We finally have all the bits and pieces we need to assemble three prototype Serval Mesh Helper (SMH) devices, that under ideal conditions should be able to support links over tens of kilometres, instead of the tens of metres that WiFi is capable of.  

The SMH has an embedded router (TP-LINK WR703Ns running OpenWRT -- see http://developer.servalproject.org/dokuwiki/doku.php?id=content:meshhelper:prototyping_on_mp2&#etc_config_wireless for more information) running the Serval Mesh software with 802.11n WiFi  running in ad-hoc mode so that the SMH's can mesh with each other.  They will simultaneously run in access-point mode so that phones can connect to them as WiFi clients, and hence not need to be rooted or otherwise able to do ad-hoc mode. This is the core functionality of the helper device.

The other capability in the helper is a long-range UHF radio operating in an appropriate ISM band, so that the mesh helpers can communicate over long distances. We are using RFD900 radios from rfdesign.com.au.

The fundamental components draw less than 1W sustained, and it can probably be optimised down to somewhere around 0.3W on average.

Here are some pictures of the assembly of these units.

First, for the power supply for the radio and RFD900s, we are using UBECs (little 5v switch-mode power supplies that are great for running from batteries).  The RFD900s can be powered from USB to TTL serial cables (we are using FTDI ones at the moment), but at full power it is a bit too much for the WR703N's to pass through, so we are powering them separated. 

This entailed soldering up a power connector that can plug into the UBEC and provide the correct power outlets for the WR703N and the RFD900 radio.

 

Then it was a case of plugging all the bits together.  The following shot shows the connections to the radio modules:

Basically the black wires go on the left-hand edge, with the serial cable underneath, and the power connector on top.

We need a USB memory stick for extra storage (the WR703N has only 4MB flash, much too small for a Serval Rhizome node that might want to cache giga-bytes of data), which entailed adding a passive USB hub so that both the radio and memory stick could share the single USB port on the WR703N.

We are powering the components from large 120Wh LiFePO4 batteries, that should be able to run these units for close to a week.  We opted for using car accessory power connectors as vehicle power is the most likely backup power source we expect to encounter:

One of the (many) nice things about the RFD900 radios is that they support antenna diversity.  We take advantage of this by plugging in two antennae on perpendicular axes, so that we get horizontal and vertical polarisation (assuming we hang them vertically in the box).  We also have some +6db yagis for when the need arises.

 On the charging side of the batteries we used some nice connectors that we also fitted to our RedArc solar regulator, so that we can charge the batteries easily, including while using them to run the helper devices.

With such large batteries it is really important to make sure you have everything fused and protected against short-circuit, especially since we will be flying with these and don't want to accidently melt a hole in a plane.

Then it was time to think about a convenient container that would fit everything, be easy to carry around, and be weather proof enough for use at KiwiEx 2013 in a couple of weeks time.  Some $10 storage tubs did the trick.  We will put a small bag of rice in each when we take them on field to absorb any condensation in the tubs.  You can see everything in there happily running:

Securing Mobile Telecommunications Talk from LinuxConfAU 2013

The full video of my recent talk from Linux Conf AU 2013 is now available:

http://mirror.linux.org.au/linux.conf.au/2013/mp4/Making_Mobile_Communications_Secure.mp4

The abstract for my talk is here:  http://linux.conf.au/schedule/30058/view_talk?day=wednesday

"GSM/3G are surprisingly insecure, which is sad since good cryptographic frameworks exist. During the past year the Serval Project has been working on integrating very strong security into voice, text and data transfers on a mesh network. Rather than implement a secure SIP and secure RTP combination, we have taken a fresh approach and created a light-weight but secure packet and voice transport that is designed from the ground up with mesh networking in mind. One of the key innovations is using public keys as the network address, so that no key exchange or verification is required to setup an end-to-end encrypted channel. Consideration has also been given to how to defeat man-in-the-middle attacks for peers who are not able to verify each others keys prior to connection.

The system will be demonstrated in it's intended application in open-source Serval Mesh telephones to allow secure telephone calls.
Part of the talk will discuss the technical details of the security model, but (hopefully) in a fairly accessible manner that most developers should be able to follow, and in particular avoiding getting buried in mathematics. Feedback on the security model is invited so that any obvious vulnerabilities can be addressed before the software becomes widely distributed."

Breaking the WiFi Barrier - The Serval Mesh Helper Packet-Radio Prototyping (Part 1)

From the outset the Serval Project has been using WiFi in mobile phones to form the mesh network, because that was the easiest radio to make use of in the phone.

However, WiFi has a lot of problems for meshing, especially on Android phones where you need to "root" the phone to even be able to use WiFi in the meshing ad-hoc mode.  Ad-hoc WiFi also has a lot of interoperability issues, power consumption issues, as well as some scaling and mobility problems due to the relatively under-developed standard that underpins it.

But most of all, even if we solve all of those problems, WiFi has limited range. Typically mobile cannot communicate by WiFi over distances greater than 150m, and that's outdoors and without obstructions.  Indoors it can be as bad as 10m, especially when there are walls and fences and other substantial obstructions.

This is why we have been thinking for a long time now about a pocket-sided "Mesh Helper" that will do the ad-hoc WiFi, so your phone doesn't need to be rooted, and won't go flat nearly so fast.  But most importantly, we can put additional radios on the helper, so that we can form useful mesh networks over much greater distances.

A nice side effect of the mesh helper design is that anyone within WiFi range of the mesh helper can join the mesh, so you don't necessarily need one per person.  Also, it means that people can keep on using whatever mobile phone they like, and upgrading it as often as they like, without worrying about mesh compatibility or losing the long-range communications capability.

We have some funding from the NLnet Foundation to explore prototyping the mesh helper device at present, so we have been working on the hardware and software needed to do this.

For a while we had our eyes on the HopeRF RFM23BP 1W ISM 915MHz band radio modules that are  very small and cheap (about $10 in sample quantities), and fairly easy to program.  That said, when you are talking about implementing the kind of frequency hopping required to use the ISM 915MHz band in Australia and the USA, "fairly easy to program" is a bit euphemistic for "not strictly impossible to achieve".

Fortunately, we have been following the progress of Andrew Tridgell (of Samba fame) with long-range telemetry radios for auto-piloting radio controlled model planes or UAVs.  Andrew has been very patient with my frequent probing at Linux Conf AU (LCA) events where I have quizzed him on the current state of the radio equipment they are using, to determine the feasibility of using it to prototype our Mesh Helper device.

This year at LCA, it became clear that there was an excellent radio and firmware combination that would allow us to rapidly advance the prototype to a functional state. The only major trade-off would be that the prototype would feature a point-to-point radio link instead of a true mesh link, so only a pair of Mesh Helpers could operate in an area at a given time.  This is totally acceptable for the prototyping stage.  Also, the radio firmware has been largely written by Andrew, and is open-source, making it an excellent starting point for us to generalise the point-to-point link into a mesh link.

So we ordered a pair of the RFD900 radio modules from RFDesign, which arrived on Monday.  A testament to the quality of the radios and firmware is that by yesterday afternoon we had Serval Mesh traffic flowing over them!

This was tested with a modified version of our servald software (currently living in the "serial" branch of github.com/servalproject/serval-dna, but soon to move into the "development" branch).  The radios were plugged into my mac, and I had a separate instance of servald talk to each, and configured so that they could only communicate with each other via the radios, thus testing the full radio communication path.

After a few glitches with my SLIP-style encapsulation of packets in the serial data link, all was working, as the following video shows.

I did try to grab a couple of screenshots, but they seem to have disappeared into the ether, perhaps during one of the several times that my mac froze hard while talking to the radios.  I need to look into the cause of that, which I suspect may be related to either the FTDI USB to TTL serial port driver or excess current draw by the radios over the USB port (however, the problem still occurred when transmitting at only +10dBm (10mW), which should have been well within the capability of the USB ports).

We also did a couple of indoor/urban tests with the radios. In both cases, a radio was left plugged into a mac either in my house just sitting on the lounge, or on a desk in our lab at work.  We then wandered around with a 2nd computer with the other radio and kept an eye on the link quality to see how far away we could wander.

For the uban test, with the radio indoors, I then wandered outside and proceeded to walk around the block. Our block is about 75m wide and 200m long, with lots of solid brick homes and steel fences between houses.  The radio was sitting only about 0.8m above ground level, well below fence level. The link was sustained almost the whole way around the block, up to about 150m - 200m through all the houses, walls, fences and other obstructions. In other words, if almost any two people on our block were using Mesh Helper devices, they could have easily communicated. In contrast with WiFi everyone on the block would have needed to be part of the mesh.  This is exactly the kind of result we were hoping for. Also, when I got home I realised I didn't have the radios at full power, so it might even have been possible to get right around the block.

For the office test, we walked around inside the building from the 4th floor where our lab is, down to the 3rd and 2nd floors, all the way to the tea room (an important communications destination for us), and were able to maintain link most of the time, including while in the tearoom.  It is worth noting that our building has thick concrete floors and is built into the side of a hill, so there were substantial barriers.  We are not even certain if there is line of sight from the tea room to our lab above the soil of the hill side.

In the process of this, we have discovered that the full link budget (of up to about 125dB at typical noise levels) does not seem usable without some refinement of the forward error correction. This is something that we will look into when we have the opportunity, because it could potentially extend the maximum range in certain situations, where the loss of link is not due to complete obstruction of signal.