Slashdot Mirror
DARPA Wants Huge Holy Grail of Mobile Ad Hoc Networks
coondoggie writes "Even the often far-reaching researchers at Defense Advanced Research Projects Agency (DARPA) seems to think this one is a stretch: Develop what's known as mobile ad-hoc wireless technology that lets 1000-5000 nodes connect simultaneously and securely in the field. For the past 20 years, researchers have unsuccessfully used Internet-based concepts in attempts to significantly scale mobile ad hoc networks, DARPA said. A constraint with current examples is they can only scale to around 50 nodes before network services become ineffective."
Your network's hairy
Your servers are duds
Only one way to shave it
And that's drown it in suds!
Burma Shave
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
i though of this years ago. probably a decade ago. there is no packet enveloping. the header is fixed length:
[source address][destination address][time initially sent][time from last hop]
the clocks on the units must be synced highly accurately, but there's a way to do that democratically over the same channels, using unused bandwidth. also unused bandwith can be used to exchange hash data to optimize routes.
then the thing you want to figure out, at each point, is, given the destination address, what "port" to send to.
so you have a hash of destination addresses, and each one has a list of ports and their respective latencies, calculated from previous transmissions. just try the best path first. it's like "pruning" in a mini-max algorithm.
i dont feel like going in depth on the details of the algorithm for getting time statistics and dynamically updating them, but i hope you can see that once you start from first principles and work forward, the answer writes itself.
now i designed this for infrequent network changes, where each unit was a physical "router" and thus had a fixed number of "ports". in a mobile ad-hoc network, network changes would be much more frequent and the number of "ports" very dynamic. so the fix for this is to identify each "port", not with a number, but with the unique device id of the device at the other end. and then as devices go out of range you can choose to retire them like you retire a cache line.
so there you have it, basically. the basic data structure layout of a highly scalable highly dynamic, self-repairing, self-optimizing network. the rest is just a bunch of simply algorithms for updating the data in the data structures.
This problem is more or less solved already. It can be done through ad hoc mesh networking, and there is firmware that can be used on Atheros and several other vendors chips.
The problem with deploying any of this is that the ability to do this with civilian devices disintermediates the cell phone user from the cell network providers. So there are huge buckets of money which Do No Want This Firmware Available Anywhere. Deploy it, and you mostly do not need cellular carriers, unless you need lower-than-voice-acceptable latency on your network for higher speed data (e.g. multiplayer video games).
The half a dozen companies that can already do this include Google; I used to sit about 200 feet from the office of the primary researcher.
"This could provide more troops with robust services such as real-time video imagery, enhanced situational awareness and other services that we have not yet imagined."
Uhm. Yeah. There's your problem. Video imagery? Dream on. No, you are not going to get a unique video stream into and out of every single one of 5000 ad hoc wireless network nodes functioning in a mesh. It's stupid even to consider the idea. And no amount of protocol fudgery is going to fix that. The bandwidth simply isn't there in the hardware.
Could all 5000 nodes connect to an IRC server and provide text chat? Yup. With great reliability. I guarantee that would work flawlessly. And you also wouldn't want to do that either. Ever been in an IRC channel with 100 active users? I have. It's bedlam. Readable, if you're REALLY paying attention, and read quickly, but still bedlam. 1000-5000? Useless. Especially when you're busy trying to avoid getting shot. But it would work. So divvy up the people into individual channels for companies, platoons, squads, and fire teams, and now everybody has a reasonable amount of information to keep track of. And everybody's dead. 'cause if you thought trying to text and drive was hazardous...
So here's the thing. What do they really want to do with it? The phrase "enhanced situational awareness" is probably the only really useful thing in that quote. If I was out trying to avoid getting shot, knowing ahead of time where people are who are likely to shoot me seems like the most valuable thing. And that isn't a machine to machine communications problem. That's a man to machine and machine to man communications problem. Mostly it's a man to man mediated by machine communications problem, and I have a feeling if you asked any marine what he wants most, his answer is going to be "make sure my voice radio always always works." 'cause that's the standard any "enhanced situational awareness" has to exceed. Not meet. Exceed.
And that, ladies and gentlemen, is a human-computer interface problem, not a networking problem.
For the kind of bandwidth and performance they want, dedicated routers are needed. A pure ad-hoc setup won't work. The network can be self configuring in an ad-hoc like fashion, with routers acting as supernodes and preferably sending some control data for channel / geographic setup and configuration updates.
Being that this is DARPA, they need to talk to their DOD peers who have solved logistics equations and simulations. You don't send 50+ troops into the field all at equal rank together. You have some sergeants and lieutenants to coordinate command and control. Same thing with a mesh building ad-hoc router. Heck, the math side should work out almost exactly the same for number of equipment tiers and number of equipment pieces at each tiers as for troops in the field.
They could just use Android phones with the Serval Project mesh network app installed on them.
"I've got more toys than Teruhisa Kitahara."
DARPA is not new to this: http://www.bbn.com/technology/networking/wnan
You guys suggesting ridiculously simple approaches don't do this problem justice. Dynamic Spectrum Access, MIMO, Multicast VOIP, and amazing routing smarts, it's all there. There's some crazy-smart people behind WNaN, and it scales beautifully. At the 102-node experiment in 2010, network services were far from "ineffective". I suspect that much larger MANETs would work fine, even with this already-built radio system. The summary doesn't accurately reflect the current state of the art.
That being said, this RFI addresses a different issue. The very premise behind IP networks is inherently non-optimal for ad-hoc networking. When IP was being developed, it was with a specific purpose in mind, with specific underlying assumptions. Many of those assumptions do not hold in a MANET. This RFI is about abandoning these assumptions and starting from square one to develop fundamental new ideas about ad-hoc networking that are optimized for this specific environment.
In some sense, those of you saying that this problem is solved are correct. It is solved. There are commercially available systems that "work". This RFI is not about making something that works. It is about developing new theory, protocols, etc., for MANETs from the ground up, and not extending or tweaking existing networking technology to "solve" a problem that it was not designed for. They want theory, not engineering.
Chuuch. Preach. Tabernacle.