Slashdot Mirror
Peer-to-Peer Cellular
Phos writes: "A cool article over at the O'Reilly Network outlines a possible solution to cellular network outages in the event of an emergency. A P2P SMS technique where individual handsets act as autonomous SMS relays."
← Back to Stories (view on slashdot.org)
I'd give it a week before an open cellphone is considered as antisocial as an open smtp relay.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
The author just had to take a shot at Napster:
Gnutella is a completely decentralized, or peer-to-peer, file-sharing system. Unlike Napster, there is no centralized server that acts as a broker in processing search requests, matching users with each other. Gnutella clients automatically seek out other Gnutella clients elsewhere on the Internet.
(I guess gnutella is free from lawsuit then?)
I'm not so sure I like the idea: what if some cell phone junkie figures out a way to display all of the messages coming into his phone (a friend of mine can do similar things) and he gets to read everyone's text messages... not a good thought.
~ now you know
In order for peer to peer mode to work, you have to have some idea who to send messages you want to get to a certain phone. Which means your phone needs a routing table, and possibly a very large one. Not to mention that all the possible routes need to be sent to every phone. Also, if you send your message to somebody's cell phone, who then leaves the network (power off, phone drops in water, etc) for a long period of time, the message disappears, this possibility might encourage people to just keep trying for a voice connection for messages they need delivered.
Need a Catering Connection
Well, if this was a service that was turned on only in emergencies, you wouldn't have that problem. HOPEFULLY, whatever was causing the cell phones not to work, would be resolved in less than a couple of days. This is just being looked at so that, in event of the apocolypse arriving, you can call your friends in another time zone and give them fair warning.
Humans are slow, innaccurate, and brilliant; computers are fast, acurrate, and dumb; together they are unbeatable
This article examines the task of creating a wireless communication system that can survive a catastrophic failure, and still provide basic communication services to its users.
It's called Amateur or 'ham' radio - every year they have an event called 'field day' which is an exercise in taking your gear out and operating on generators, etc. 2 Meter handy talkies can work thru a repeater or direct simplex (peer-to-peer) if the repeater is down.
I'll never forget listening to a ham during hurricane floyd, w/o power, operating on emergency backup power, 80 meter band, crouched in his garage on the NCarolina cost reporting the fierce winds in the night.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
-sting3r
Even if every phone had a perfect routing table, you'd still have very severe scaling problems.
Even if almost all of the messages being routed are to phones in the same city, the density of messages at each relay node will be large (total traffic is proportional to the number of nodes talking, and for an even distribution, traffic per node is proportional to the square root of this). A city has a million phones or more. This means that each phone would be routing messages for hundreds or thousands of other phones on a *normal* day. *If* all of the load-balancing in the routing table works perfectly.
Fast forward to Sept. 11th. You have everyone in North America trying to call or message relatives in New York City. The traffic densities as you approach New York would be *HUGE*. Inside the city, you'd have phones trying to handle thousands of messages or *more* at *once*, instead of whenever phone users decided to send. This would melt down the message network in the city and for a little ways around it.
All of this assumes that each phone knows the best route for all messages. In practice, they don't. I'll let someone with more network expertise than I have describe how nasty things get when your phone can only fit a small routing table and you have a constantly-shifting pattern of connections that has to update itself in a decentralized manner (instead of being tracked by a central server that knows where everyone is). Short version: It's not going to be pretty.
In summary, I think that the authours of the article are overlooking a significant problem, especially given that they're proposing this as a way of overcoming system load problems in situations like the Sept. 11th attacks.
It is called a Mobile Ad-hoc Network (manet) and the IETF has a working group which has come up with some protocols and such.
. ht ml
http://www.ietf.org/html.charters/manet-charter
Interested readers should probably read A Performance Comparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols to find out why this is difficult.
According to the article, phones would have to exchange and update their routing information all the time, even while everything was working normally (because by definition a phone can not know if a neighboring base station that's just out of reach is still working or not). Every phone would continuously keep broadcasting a list of every other phone and base station in it's reach.
This overhead alone (just to update the routing tables) would consume a big chunk of the bandwith all the time. Since a base station dropout or overload is an exception (hopefully), a dynamic on-demand routing protocol would make much more sense in this case.
Idempotent operation: Like MS software, wether you run it once or often, that doesn't make it any better.
What the article describes is the old military concept of "mobile mesh network". Highly survivable solutions are a must in a combat environment, but their their characteristics make them completely unmarketable. In our specific example, the reasons are as follow :
Full-mesh wireless networks like JTIDS are inherently inefficient because one cannot make
range (timing) and Doppler corrections at the transmitters, and because there is no frequency
reuse. With a repeater-based architecture, all transmitters can adjust timing and frequency to
correct for their range from the repeater and for relative velocity. In a full-mesh network, all of
the other nodes are potential receivers, but one can make range and Doppler corrections for only
one of them. With multiple repeaters (base stations), two repeaters that are not close to one
another can use the same frequencies without interference; such frequency reuse enables large
increases in system capacity over full-mesh and single-repeater architectures. Decreasing cell size in order to increase frequency reuse reduces the survivability of the network.
A closely related concept is that of the self-organizing hierarchical network. These networks are similar to the homogeneous mobile mesh networks, except that nodes organize themselves into clusters and by some means "elect" a cluster head (see, for example, Alwan et. al, 1996). The cluster head is responsible for keeping track of the membership of the cluster and the locations of nearby cluster heads, and for performing routing, switching, and trunking functions. However, since any node must be able to function as the cluster head, cost and battery life are likely to be problematic. Remember that mobile devices are highly contrained.
The problem with military stuff is that it is grossly overengineered from a civilian point of view. We all would like to carry cutting edge radio hardware with us and be ready for all kinds of emergencies, but there is a price to pay and the civilian market won't bear it, preferring to take long term risks and to get more features and more performance in the short term. If survivability was foremost, everyone would be backing up their data. Field experience shows that it is not he case.
Sources :
http://www.google.com/search?q=cache:3fDYY36opQQ:w ww.rand.org/publications/MR/MR960/MR960.chap3.pdf+ tactical+network+relay+node++survivability
http://dss.ll.mit.edu/dss.web/98F-SIW-143.html