[Tfug] Remote networking communications and Internet gateways 0uqe6ute

[Bexley Hall]

Hi Angus,

On 4/18/2014 8:43 AM, Angus Scott-Fleming wrote:
> Something like these might work:
>
>      Project Meshnet
>      https://projectmeshnet.org/
>
>      The Smart Phone Ad-Hoc Networks (SPAN) project
>      http://www.networkworld.com/community/blog/android-phones-are-connecting-without-carrier-networks
>
>      FireChat´s anonymous, off-grid messaging app arrives on Android - Tech News and Analysis
>      http://gigaom.com/2014/04/03/firechats-anonymous-off-grid-messaging-app-arrives-on-android/

The problem with mesh solutions is they require cooperation.
E.g., at a "balloon fest", they would be fine -- folks would
know to get their phones charged ahead of time *and* keep
them on "for the benefit of others".  You know, a priori,
how long the "event" will last and can plan accordingly.
"The Organizers" may even "suggest/impose" some scheme whereby
folks deliberately stay "off" to conserve their battery to
extend the coverage for the entire duration (e.g., a 36 hour
event) instead of having everyone "on" at time=0 and everyone's
batteries exhausted long before the event is over!

OTOH, in an emergency/disaster, power can go out and you're stuck
with whatever level of charge you happen to have at the time.  And,
you're probably not keen on leaving *your* phone on, spending *your*
battery just so *others* can relay through it -- especially when
you have no idea as to whether the "event" will last a few hours,
days or weeks!  (without power and services)

> At some point there has to be a connection back to "the real world" to upload
> the streamed video, but these would allow mesh networks to extend into places
> with no WiFi or cell coverage.

I think you can come up with a scalable (service and coverage) solution
that gives you lots of opportunities based on what you have available.

E.g., I tend to favor the store-and-forward approach as it lets you
manage the requirements after the fact (instead of having to build
in lots of capacity ahead of time).  Conceivably (though not a
desirable operating mode), folks could store outgoing messages in
the box.  Then, the box could be sneaker-netted to a facility that
has an outbound connection (a ham shack, land line, pay phone,
satellite uplink, etc.) and the messages uploaded en masse -- or,
even converted to individual telephone calls (by dialing the number
stored with the message).  Similarly, a connection to a "relief
center/orgainzation" can pull down any stored messages intended for
the phones that were "registered" with the box and then "delivered"
when the box is returned to the problem site.

[I.e., in such a scenario, "outsiders" could call the Relief
Center, enter the phone number of the party they are trying to reach,
record their message and have it all stored on a server "local" to
the relief center.  Later, the "suitcases" in the field retrieve
the messages that were cached on that server.  An "outsider" can
query the relief center's server to see if/when the message was
relayed -- and, possibly, gain some information about where the
suitcase that retrieved it was actually deployed (privacy issue?).
Similarly, they would know if their message(s) were *not* getting
passed along...]

Note that the "relief center" in each of these cases could be
a single individual with a single phone line ("external connection")
depending on the volume of traffic expected and delays that will be
tolerated.

So, for (silly) example, kids away at "Camp" could record messages to
their folks at home.  The box can be hand-carried out of the camp
to a nearby pay phone.  And, the messages delivered by the box dialing
out through the pay phone.

(or, dumped to someone at a "base station" who then distributes them
as well as uploading their replies to the box at the next "connect")