I’ve made other posts about mobile ad-hoc networks, and somewhere there’s probably a post about the Technicity MOOC I participated in. (Another post will go up about that)
As part of that MOOC, there was a project that I never finished. Here’s something like what I would have submitted if I’d had the time. To a greater or lesser extent, wanting to finish this list off, and make it available, was a great motivator for getting this site off the ground and start publishing again.
What I’m suggesting here is just a few GPS based tools which could be used to enhance the Mesh and make it much more useful in a location context way.
A lot of this is assuming a couple of things.
1. a great deal of users in at least 2 of the scenarios discussed will have access to smartphones, and of those, a large number will have built in GPS.
2. that any platform running non-standard router hardware (for example, Raspberry Pis) could, and possibly should, have GPS capability on-board. Disturbingly, given Apple’s “Multipeer Connectivity” (see horrendously technical doc here), and the GPS capability of most iphones, it might be a potential platform for this.
Those assumptions out of the way (and I’ll come back to them repeatedly) then I’ll begin.
In thinking about this problem, I came up with 3 scenarios within which I could see an ad-hoc Mesh network being useful.
1. Urban/rural-urban community with low speed internet access, restricted access to high speed internet, or no internet at all. This could involve using the Mesh to extend a small number of internet access points to a wider audience, but with the intention of using the Mesh to offer additional location based services in a small geographical area. This scenario *may* assume slightly less drop out of nodes and a more static nature geographically.
2. Disaster area where normal internet/communications has been compromised to more or less zero, and the population are highly transient due to circumstances. This scenario would assume high level of dropout due to unreliable or absent power sources for running Mesh nodes. To be frank, it should assume less access to smartphones, or common platforms, but may assume limited web functionality. (ie. a preference for an open source/HTML platform rather than “apps”)
3. Dynamic Political Protest. This is my particular decentralisation anti-system bent, but it fits in nicely with the former scenarios. This scenario assumes state/law enforcement compromisation of the local internet/comms, but assumes high level of technical support otherwise, and ample power availability. Again, the downside of this scenario is probably high likelyhood of DOS attacks on the mesh, which could require a pre-share key style of access to reduce spurious traffic. This scenario also assumes a high degree of geographical mobility, high density of nodes, and possibly high turnover of nodes due to attacks/movement. I imagine that “shortest paths” may be very dynamic.
So, on with the primary functions.
1. Here I Am
Really simple this one. On connecting to the mesh, the client device (eg. Phone) broadcasts to the mesh its GPS location. the MAC address of the Phone would be the primary identifier for the phone/individual. At the minimum it would identify only the device and the location, and at most, the device, the location, and some descriptor of the owner/guardian of the device.
How it would work.
Each Mesh node stored a dynamic table of mac address, and last recorded or broadcast GPS location. If the nodes have a reasonably synchronised time, then should be easy to propagate updates across the network, and this would handle nodes which have dropped out and reconnected. Small enough amount of data should be lightweight enough to throw out quickly? Some sort of protocol for a node to bounce propagation back and say “You’ve already told me that” if update frequency gets too high would probably be needed?
In fact, most of the functions will rely on fast and extremely efficient propagation of new GPS/MAC records through the Mesh, so that any one node will probably have recent, if not actually up to date data. The main decision is how much data to flood through the network and how to reduce the load. I think it would be down to expediency (space on the node/time) how long the record would remain active for before being flushed.
2. Pin This
Rather than a temporary “I’m here” relating to “now”, this would be a “point of interest” or POI, that should remain more or less permanently. Within the context of say a disaster area scenario, this could be anything from “here is a help point/medical centre”, through to (in a more community based scenario) “I’m an expert at X or Y, prepared to help on a barter/freecycle basis”. It could just as easily be the reverse of this, and be along the lines of “At this location is needed resource of X or Y”, where the resource may be physical plant, or merely skilled expertise of some kind.
How it would work
More or less the same as “Here I Am”, with the suffix of not expiring as quickly. The user could perhaps dictate the expiry of the information (ie. “I’m going to be here offering X until Y”)
With additional information (types, or tags) attached to pins, matching or searching could be performed to reduce the requirement for pins to be used. (ie. I “need” a resource, could be matched to someone who could provide the required resource, and the request pin wouldn’t be needed.)
3. Location Alert
Depending on the mission context, The toolset would need some “push” functionality, rather than “on-demand”. Ie. users of the network, depending on the client platform, would be *sent* messages from the Mesh alerting to a location/situation, rather than receiving them on a refresh for example.
How it would work.
Given a suitable heirarchy model of users and/or devices, one device would propagate a message to be delivered, rather than picked up, to any connected device. Given the existence of a hierarchy, this could be filtered to got to certain nodes using standard addressing.
This would require additional data about each device or individual, and the aforementioned hierarchy enabled, allowing high level users to pinpoint individual users, and “guide” them, to points of reference instead of using the tool to send all users an advisory.
Now, I have some ideas for another function, which I think would be important, but possibly not within a general context.
4. Media Stream/Record/Archive
This seemed to me a major consideration in Scenario 3. A tool which would stream incoming audio or video from a phone or other Sousveillance device, to one or more dedicated recording nodes. ensuring that in the event of seizure of hardware or the original recording device, multiple copies would already exist for dissemination from the other nodes (either after the event, or by connecting to the nearest uncompromised storage location outside of the sphere of control.
This could just as easily be used for legitimate purposes by recording any audio/video for playback by any Mesh connected device after the fact, so would have legitimate use as well. The problems to overcome with this particular tool would be ensuring not too many storage nodes existed, to reduce load, but enough to ensure that availability in the future was still likely. as in Tool 3 (Location alert), an amount of “superuser” or hierarchical control of this tool would be required from the outset. The other consideration is that a recording node would have to have much more storage than would otherwise be required for simply throwing around the simple data for Tools 1-3, like an attached HDD at the minimum, which reduced portability/covertness.
Some other thoughts.
1. If maps weren’t to be pre-loaded onto each Mesh node, then at least 1 internet connection would be required so that when a Node goes live, it can retrieve map/gps data relevant to the locality. Obviously the alternative is for map data to be pre-loaded onto nodes during the production stage. Detail & resolution of map data would obviously be mission dependent.
2. Depending on the mission type, different security/traffic protocols would be needed to defend against the probability of attacks that in the main one would presume would be overload based, flooding the system, with traffic. in the case of Scenario 3, perhaps access to the network would be invitation/shared key based. I wouldn’t be able to estimate how that might prevent general requests being applied to overload it though. Anything being run across standard Wifi hardware would obviously be restricted to specific channels/frequencies, which would be vulnerable to jamming as well. Some Meshes are being based on radio on a non-wifi basis, so perhaps could be configured to use frequencies less vulnerable (although there’d be legal issues there, a protest group isn’t likely to be as fussed).
Just some waffly ideas I had for Meshes. If someone’s already documented these kinds of things for an ad-hoc mesh, then I just haven’t done enough research, but they were just ideas in my head I wanted to write down first.