Midterm Update

Back

Objectives and Background

Mesh networks have been around for a while now, and are starting to become popular in home devices like the Google Nest product line. In addition, there are recent scenarios where creating a mesh network in conjunction with SpaceX Starlink satellites can be critical for supporting crucial communications. Testing the ease of setup and usability can be an important step to allow for useful internet communications in situations where it is needed.

This approach is a change in direction from our original proposed idea of a quantitative analysis of the available routing protocols to provide a tailored experience for Starlink internet connections in rural or low-income communities. One of the main focuses for the change of direction is news from Russia's current invasion of Ukraine. A Ukrainian official reached out to Elon Musk on Twitter asking for Starlink to give access to the country, and Musk agreed. Shortly after, Starlink terminals were sent to Ukraine and service was enabled for the country. This news, combined with our original idea, prompted a change of direction. When we looked at how to achieve this system (a satellite backhaul and a WMN) with everyday equipment, we found the instructions and information to be outdated or lacking. We want to go through the process ourselves and report on the current state of the community.

We will attempt to create a network deployment using mesh technologies using off-the-shelf hardware and components whilst documenting the process, challenges and experience of creating this network deployment. By attempting a physical deployment rather than a simulation one, we will be able to document our experience of deploying a mesh-based network outside of a lab setting and the challenges it may still face hindering adoption.

There are grassroots, community-based networks that utilize mesh networking like NYCMesh and Freifunk that use commodity, purpose-built hardware. They require volunteers to set up the equipment, and connect the devices. We would like to test how easy it would be for a user, without experience with mesh networks but with networking knowledge (equivalent to CSC 361), to set up a mesh network and connect multiple nodes together using hardware that they might have laying around. We define a user setting up this network having knowledge in basic networking fundamentals like IP/TCP and simple routing protocols like OSPF.

Network Topology Proposal

A small community with a “supernode”, is defined as a node on the network that has backhaul Internet connectivity (4G LTE / Fiber / Starlink etc.) and nodes, which participate in the network. Nodes themselves can provide access via. wireless (WiFi) and wired (Ethernet) means. Nodes can also extend the network by routing traffic through itself.

Clients can connect to these nodes to get network access but these clients themselves will not be part of the mesh network. For the sake of this experiment, we could make everything behind a CGNAT type deployment; however these kinds of administrative and policy decisions are beyond the scope of this project.

We consider having a single supernode and at least 3 nodes to be a minimal proof of concept of this mesh network deployment.

midterm Update Topology

Gateway (Internet)

We will use a mobile wireless connection from a smartphone to act as our Internet gateway connection. In practice, this might be any form of backhaul as mentioned in the background section of this project. Having a backhaul connection will allow nodes within the network to connect to the Internet.

Routing

In this section we briefly cover several routing protocols currently used in deployments and mentioned in papers and community initiatives.

Batman-ADV

A routing protocol created with the intent to replace OLSR, and since its initial release in 2006 has been a part of the official linux kernel. Because of the wide support of the linux kernel on Raspberry Pi, and other embedded/low-power devices this is a prime contender for our needs. We believe that this will interface well with other OpenWrt-supported devices and end users alike.

https://openwrt.org/docs/guide-user/network/wifi/mesh/batman

Babel

A “loop avoiding distance-vector routing protocol”. It is designed to work with both wired and wireless links and works well within these hybrid environments. The most recent RFC is from January 2021 making it still an active project but appears to have lost momentum. However, many of the features of Babel are still appealing to modern mesh networks. Several extensions exist for Babel that extend the functionality beyond the base specification.

https://www.irif.fr/~jch/software/babel/ https://openwrt.org/docs/guide-user/services/babeld

Optimized Link State Routing Protocol (OLSR)

OLSR (Optimized link state routing protocol) is a routing protocol for mobile ad-hoc networks. It is a widely used routing protocol, but has many known downsides. Some of the more known downsides include flooding traffic and reliability issues. There have been many attempts to replace this protocol, Batman-ADV being one of them.

https://openwrt.org/docs/guide-user/network/wifi/mesh/olsr

Open Shortest Path First (OSPF)

Open shortest path first (OSPF) is another link state routing protocol, but is used more in enterprise and large service provider networks. It was designed in 1980 and as such is not a very good use for the modern networks we are investigating. Being simple, it has some advantages but primarily falls short with configuration limitations and being able to adapt to a dynamic network like a mesh one. Overall, it is ill-suited for a mesh network.

Inventory

The following is a list of networking equipment we currently possess:

We may use any subset of this equipment list to achieve the construction of our wireless mesh network.

Measurement

Our plan involves evaluating QoS with qualitative metrics. Some metrics are listed below:

It is important to note that the traditionally quantitative metrics above will be evaluated purely qualitatively.

Updated Schedule

The following is the new project schedule, updated from the project proposal’s schedule:

This change can also be found on our website: https://csc466-wmn-routing.vercel.app.

Related Papers

Since our last update, we have read more research about WMNs. As seen in the below papers, our research focus has shifted with our project’s focus to usability and ease of installation and deployment of WMNs with satellite backhauls.

UrgentMesh

This paper is relevant to our project because it explores the use of DVB satellites with WMNs for emergency video communication. This study of satellites with WMNs may provide some useful information for our own research.

T. A. Hadhrami, Q. Wang, M. Crowe, and C. Grecos, “UrgentMesh: Wireless mesh networks with dvb-satellite for emergency management,” English, IEEE, 2011, pp. 1–6, isbn: 2157-0221. [Online]. Available: https://go.exlibris.link/6tPz3LFX.

WiMesh

WiMesh discusses design tradeoffs for WMNs in disaster recovery and emergency scenarios, most notably including ease of installation. These qualitative analyses will be informative for our own.

U. Ashraf, A. Khwaja, J. Qadir, S. Avallone, and C. Yuen, “Wimesh: Leveraging mesh networking for disaster communication in poor regions of the world,” CoRR, vol. abs/2101.00573, 2021. arXiv: 2101.00573. [Online]. Available: https://arxiv.org/abs/2101.00573.

Wireless Mesh Network for Rural Communities

This paper outlines the routing protocols and open-source solutions available at the time for WMNs in 2007. This provides a good snapshot of the state of WMNs for rural communities at that time.

V. Bilicki, T. Kallai, and M. Kasza, “Wireless mesh network for rural communities,” Jan. 2007. [Online]. Available: https://www.researchgate.net/publication/255584945_WIRELESS_MESH_NETWORK_FOR_RURAL_COMMUNITIES.

© Adam Hultman, Aomi Jokoji, and Isaac Donaldson.