CATAN: Communication Assistance Technology over Ad-Hoc Networks

#1

I was recently introduced to Andrew Weinert from MIT’s Lincoln Labs. A few years ago his group created an open source project called CATAN that uses low-cost off-the-shelf technology to enable functionality similar to Google People Finder in situations where centralized infrastructure is unavailable.

At the time they created the CATAN project goTenna did not exist and they used different solutions for long-range back-haul mesh communication between nodes. Adding support for the goTenna Mesh using the Python SDK would make a great update to the CATAN project. Support for the goTenna Mesh would enable people to more easily, quickly and cheaply create a well connected long-range essential communication network in disaster areas.

This project seems like a much more full featured version of the SMS gateway project I proposed earlier. CATAN has already been implemented and just needs some one interested in updating it to use the goTenna Mesh.

The CATAN open source software runs on a Raspberry Pi and communicates with nearby users via web pages served over wifi. This means that people don’t need special software to use the system. I think accessing the system via the goTenna Mesh mobile app would also be a straight forward addition.

Would anyone be interested in adding goTenna Mesh support via the Python SDK to the CATAN system?

More information: github:mit-ll/CATAN

YouTube presentation: ICCM 2014: Hongyi Hu, Hobbyist & Opensource Tech For Crisis Mapping

3 Likes

#2

I like this idea. I also wonder whether the CATAN project appears inactive (github commits at 3+ years) due in part to relying on APRS and Broadband-Hamnet / HSMM-Mesh, both of which require a ham license. Between the licensing requirement and resultant prohibitition of encryption, the user-base is going to be fairly limited. Their use-case being focused on emergencies niches it down another notch. The Broadband-Hamnet project seems relatively defunct, so that could be another limitation. There’s some activity in their forums, but the site itself doesn’t have any significant updates since around 2015.

Did your conversations with Andrew give a different perspective on the current level of interest in the project?

2 Likes

#3

Nothing except speculation from this quarter on CATAN, but sounds to me like the very fact that goTenna Mesh is unlicensed may be what it takes to make CATAN get some traction again. And why reinvent the wheel here if GTM makes a good fit for the purposes for which CATAN was originally conceived? It’s possible the disaster focus came about in part because that’s where you could find a critical mass of radio capacity/operators to make CATAN useful. But if the radio involved no longer required licensed operators, it may be goTenna that makes this a more viable project as originally proposed, but also allow it to escape from the disaster prep focus to more long term community building possibilities.

CATAN certainly sounds interesting to me, because it may be the way to scratch some of the “internet itch” that often comes up in discussions that then ends up dampened due to mesh bandwidth limitations and what I consider the first connectivity need for porting messages in and out of local mesh networks to the internet…

2 Likes

#4

For sure. Do we know what the wheel currently looks like, and if it fits the potential use-case? It would be cool to see an example without having to build a node. The scope of CATAN is not 100% clear to me, and this 2015 paper linked from their github hints that one-to-one communications isn’t an objective:

II. NEEDS ANDASSUMPTIONS

Disasters that require HADR response often experience infrastructure outages that destabilize the communication environment. These outages hinder collaborative command and control across all participating response agencies and impair the ability to collect, process, and distribute accurate information from disparate systems and platforms [16] in a timely manner. Understanding and designing for these conditions is paramount to the success of any technology.

[…]

The implementation of existing standards and technologies to support interoperability has enabled multi-organization collaboration and the support for diverse CONOPS. We emphasize that communication interoperability is critical for HADR because of the large number of organizations that are often involved in disaster response.

One of the things about the disaster.radio project which looked incomplete was the web-based chat. If I remember correctly, the implementation was one-to-many. I don’t want to incorrectly assume the CATAN vision is identical, but disaster-focused projects tend to be structured in a way that they wouldn’t get used outside of disaster scenarios. That makes sense for their use-case, but it limits the potential of GTM.

Not sure the exact state of the CATAN project’s web app today, but it would be good to know if this has progressed since 2015:

VI. FUTUREWORK

While CATAN fulfills our initial design goals, we have since identified some potential directions for future development. For example, photographs have been shown to be invaluable for data sharing applications. We hope to add more photograph functionality to our system (e.g., Snapshot [43],image recognition), while remaining cognizant of both our computational and bandwidth constraints. Similarly, our web-based interface only offers limited access to the user (i.e.users only “pull” information). We are advocating for an application store that will enable users to download native applications, capable of providing a more seamless and responsive experience (e.g., “push” notifications). Finally, we hope to continue maturing our network protocols to simplify the mesh network configuration and minimize the interaction required when bootstrapping a new node.

If that’s where they left it, there may be a lot more dev to this than plugging in GTM on the backhaul.

At first glance, CATAN and disaster.radio both use WiFi for local connections. CATAN uses WiFi for the backhaul mesh, whereas disaster.radio uses LoRa for the mesh. CATAN uses RPi for the controller, and I think disaster.radio was using ESP8266. The plus for CATAN would seem to be that Python, and therefore the current GTM SDK, plays more nicely with RPi than Python on Arduino. Disaster.radio would probably get the check mark as far as lower power consumption. Of course it’s not a CATAN vs. disaster.radio question if the latter won’t fly with the SDK. The main reason I brought it up was because the disaster.radio YouTube channel shows the web interface of their prototype.

I realize my guarded optimism will probably read as negativity. Hopefully it’s just pragmatic skepticism after seeing nearly all open-source mesh projects orphaned before they get solid traction. I really do like the concept, and think it would be cool to see it move forward. While a web app is great for a number of reasons, I also like that they’ve started work on an Android app.

3 Likes