The State of Connectivity in Canada’s Remote Communities
Previously, you might recall — I did a piece reviewing the state of connectivity in Guatemala based on data provided by an Akamai state of the Internet report. Last week I had the opportunity to travel to Rigolet, in Labrador to help with the eNuk app. This town is only reachable by plane, boat, ice road or snowmobile. There are many similar communities around Canada — but it seems they are not well reported on, particularly when it comes to connectivity. When you think of Canada and connectivity you probably think we’re one of the best connected in the world, and for most people you would probably be right.
However, after traveling to Rigolet, I have experienced first-hand that there is a massive digital divide right in Canada. At home I have a 1Gbps Internet connection and pay a fairly affordable $60 or so per month. I regularly use upwards of 500GB in a month because I have an unlimited plan. In the country, its likely one of the cheapest “per-byte”internet plans you can have. It is also one of the highest performing. The exact opposite is the case in Rigolet. There is only one (or maybe two if you count satellite) provider. From what I can tell it is some kind of DSL connection. People in Rigolet are often part-time network engineers, with houses often linked with repeaters and more expertise than the typical city-slicker (I found this was often the case in Bangladesh as well — people need to do more work in these types of places to remain connected).
On our first day here, I managed to bring down a three repeater network by accident because I didn’t realize how it was setup and resetting one of the repeaters caused two of them to make connections with each other instead of the main router (don’t worry its fixed now).
Let’s suppose someone in Rigolet pays the same $60 I pay. From some initial performance tests I’ve been conducting, I’ve been able to achieve an average of 0.614 Mbps down and 0.112 Mbps up (0.726Mbps total) with an average end-to-end delay of 823ms (note: the connection is advertised as 1.5Mbps, so it’s been regularly able to achieve about a third of that. There have also been periods where the Internet was non-functional for hours at a time. Let’s assume that a person here uses the full capacity of their connection 24 hours a day for 30 days. (0.726Mbps ~ 0.09075 Megabytes / second * 30 days * 24 hours * 60 mins * 60 seconds). This works out to 235.2 GB (0.235TB) of data in a month (~$255/Tb).
If I used my 1000Mbps connection (which it almost always achieves what is advertised), (125 Megabytes / second * 30 days * 24 hours * 60 mins * 60 seconds) I would be able to get 324 TB of data, at a cost of roughly $0.18 per TB). If I paid the same price as someone in Rigolet, my monthly bill would be $82620. Even if I was more reasonable and used my normal 500Gb or so per month, the cost would still be $127.50 (more than double what I actually pay). On top of the data being more expensive, the service quality is infinitely worse. The variation in throughput and delay is quite large and there are long periods of outages. Since there is only one choice, the company isn’t afraid people will leave and they have no incentive to provide better service to people. Politically it seems nobody in this country has the willpower to force real broadband access to these parts of the country, so it seems like creativity is required in these places.
In Rigolet, the people are very welcoming of innovation and are working with us to develop new ways to connect. If there is very limited Internet connectivity, systems need to be designed in such a way that Internet communication is minimized. Devices should connect first to each other and share information locally (which is what we are hoping to build into the eNuk app).
After being here the better part of a week, and talking to many people from the town, I have an even better picture of what its like to be connected here. There is one incumbent Internet provider who everyone in the town uses. About half the town is connected (they drew me a rough map showing who has connectivity). The provider won’t provide any more phone or Internet lines because their feeder line into town is above capacity. It actually often provides rebates to customers because the service is so terrible. The only time the network is even remotely usable is before around 10am and after about 10pm. The best connection I’ve found so far is at the town hall where I reached just around 2.0Mbps. At the B&B which most people recognize as one of the worst connections its been averaging around 0.6 Mbps down and 0.1Mbps up.
Consider all of the apps we take for granted where we send vidoes, images and text to each other through the Internet, even though we’re right beside each other. Imagine how well this works when the entire town has a bottleneck at the Internet. Imagine how much better it could work if the apps were smart enough to use local communication whenever it could, and fall back to the Internet the rest of the time. You can read more about the benefits of this from my colleague, Aldrin.
We did some basic mesh tests here with the RightMesh library we’re working on. We did one test where we a device inside a house, one outside the house and one much farther down the street. Using no infrastructure we were easily able to send messages between the devices using the middle phone as an intermediary.
We followed this with another test case using five devices, all outside — where we covered almost 900 feet. In this case, two of the devices were hotspots, one in the middle quickly switched between the hotspots and the devices on the ends were simply connected normally to the hotspots. We can continue this pattern indefinitely and likely cover the entire town using this mechanism.
While these tests all showed how far the mesh might be able to spread, we are also interested in it being scalable as it grows. Many other mobile mesh networks use very naiive approaches such as broadcasting every message to every other device. Our mesh is quite different since it actually computes routes between devices. In Rigolet we created a demo that shows this visually. We made an app that lets one device change the colors of other devices in the mesh. The normal way this is done, all devices will always change to the same color. We can do this, but we also made a mode where only the phones on the path to a particularl receiver will change direction (demonstrating that not all devices get broadcast the same messages) This results in a more scalable network as it grows in size.
The result of the trip was really great. We met the community, found out more about their problems with connectivity, made some early and basic measurements (admittedly this needs to be done more systematically, but we are waiting on ethics approval and will obtain proper results next trip). We learned a bit about the eNuk app and how it will help the community with storytelling and data collection about climate change, the environment, and people’s livlihoods and met with some community members working on this project including Inez and Charlie. We tested out the RightMesh technology for early feasibility and found that it will likely be able to connect the entire town easily (and even be usabel for some interesting cases where people leave the town and relay data from remote mesh sensors back into the town mesh when they return). We’ve got some ideas for some simulation tools, a plan for integrating RightMesh into eNuk and have made some great relationships with the community (we participated in cardboard boat building, the Rigolet challenge, a community feast, the salmon festival, bingo and a dance), met other researchers, visiting travellers and generally had a great time. Looking forward to returning!
