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.
If the transmitter scaled its output power to connect with the closest neighbors without saturating the far field.
Use forwarding and only increase power when QOS was not maintained. Maybe?
I think the Gnutella network (Limewire), Kazaa, or Skype are more appropriate. They're more decentralized than BitTorrent (though BitTorrent has some redundancy).
I think they're basically looking for a combination of 802.11 and 802.15. ZigBee came to my mind when I heard what they want, but I guess that would be a tad bit short ranged.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I wonder how many homes are on one 'collector': bchydro
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.
How about a bunch of nodes share the same IP address, but the data they receive has a precursor integer to tell who gets it, or maybe a different port. You'd get a bunch of garbage information you don't need, but that garbage information is someone else's data.
Then the problem just comes down to how much bandwidth you have. And you gotta be cool with people not snooping you data. Do you even encrypt?
God spoke to me
includes broadcast
basically you need to figure out the phy/eth portion of the network not the software side
so if you can do SDN/Software defined radio and come up with a nice way to scale then your good
I would have thought that zigbee / sensor networks would already scale you just have to boost range but hey thats me just guessing
regards
John Jones
"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 should talk to the Serval project people
http://www.servalproject.org/
...I obey the laws of physics....
They could just use Android phones with the Serval Project mesh network app installed on them.
"I've got more toys than Teruhisa Kitahara."
It's designed to do so, and has proven itself in wireless community mesh networks.
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.
A lot of the comments seem to be sort of ignoring what DARPA is trying to do. If you look at ARPAnet, it was designed as a failure tolerant communications network (a mesh, of all things) using "wired" connections, but with a semi-hierachical topology.
Meshes work and exist but for low data rates and fairly small numbers of nodes (tens or hundreds, not thousands)
"The Internet" is basically ARPAnet all grown up, but is hierachical, and has very high value targets (backbone routers, etc.. MAEwest goes out and California stops talking)
What DARPA wants is essentially wireless "home broadband" kind of connectivity (megabits/sec) across several thousand nodes where
1) there are no high value targets (access points, backbone routers, etc.)
2) most nodes cannot "see" other nodes because there is no practical radio path between them
3) the network link availability is continuously changing.
The challenge is significant:
each node needs to know how to talk to another node (whether directly, or by some sort of multihop scheme "go that general direction")
each node needs to handle its own traffic plus that of others.
adjacent nodes that provide parallel paths need to be able to load share. If A can see E,F,G, and H, and those 4 can see X, but A can't see X, you want the traffic between A and X to be shared among all 4 of E,F,G, and H.
Battery life is important in these applications, so optimizing transmitted power and duty cycles is important as well. If you were only concerned about RF power, then a path from A to B to C to D might be preferable to a path directly from A to D.
Oh yeah, and the whole thing has to work without crippling itself with network management information being transferred around the network. No massive routing tables sucking up joules of battery power as they get replicated.