Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

DARPA Wants Huge Holy Grail of Mobile Ad Hoc Networks

Soulskill posted about a year ago | from the and-if-wishes-were-horses-we'd-all-be-eatin'-steak dept.

Networking 61

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."

cancel ×

61 comments

Sorry! There are no comments related to the filter you selected.

Your Network's Hairy (3, Funny)

smitty_one_each (243267) | about a year ago | (#43596003)

Your network's hairy
Your servers are duds
Only one way to shave it
And that's drown it in suds!
Burma Shave

CENSORSHIP ON SLASHDOT... apk (-1)

Anonymous Coward | about a year ago | (#43596053)

* Breaking news: currupt Slashdot administrators have modified the site's "lameness filter" to censor true and useful HOST file information. Slashdot admins collude with criminals to prevent you from learning about HOST files. Visit here [slashdot.org] for information Slashdot does not want you to see.

* Older news: corrupt Slashdot administration attempted to ban me for blowing the whistle on their illegal activities, while not banning the criminal who stalks, harasses, and impersonates me. Whistleblower abuse is a federal felony. Lunatic Slashdot admin's have been owned by me in so many tech debates over the past decade that they conspire with criminals to effetely & vainly *try* to "hide" my posts and censor me. Jealousy at it's finest.

=> Lawsuit's and criminal prosecution against Slashdot are now inevitable. Moderation+posting records will be sequestered and anyone acting aginst me will be dealt with permanently.

Previous notice:

A corrupt slashdot luser has pentrated the moderation system to downmod all my posts while impersonating me.

Nearly 330++ times that I know of @ this point for all of March/April 2013 so far, & others here have told you to stop - take the hint, lunatic (leave slashdot)...

Sorry folks - but whoever the nutjob is that's attempting to impersonate me, & upset the rest of you as well, has SERIOUS mental issues, no questions asked! I must've gotten the better of him + seriously "gotten his goat" in doing so in a technical debate & his "geek angst" @ losing to me has him doing the:

---

A.) $10,000 challenges, ala (where the imposter actually TRACKED + LISTED the # of times he's done this no less, & where I get the 330 or so times I noted above) -> http://it.slashdot.org/comments.pl?sid=3585795&cid=43285307 [slashdot.org]

&/or

B.) Reposting OLD + possibly altered models - (this I haven't checked on as to altering the veracity of the info. being changed) of posts of mine from the past here

---

(Albeit massively repeatedly thru all threads on /. this March/April 2013 nearly in its entirety thusfar).

* Personally, I'm surprised the moderation staff here hasn't just "blocked out" his network range yet honestly!

(They know it's NOT the same as my own as well, especially after THIS post of mine, which they CAN see the IP range I am coming out of to compare with the ac spamming troll doing the above...).

APK

P.S.=> Again/Stressing it: NO guys - it is NOT me doing it, as I wouldn't waste that much time on such trivial b.s. like a kid might...

Plus, I only post where hosts file usage is on topic or appropriate for a solution & certainly NOT IN EVERY POST ON SLASHDOT (like the nutcase trying to "impersonate me" is doing for nearly all of March/April now, & 330++ times that I know of @ least)... apk

P.S.=> here [slashdot.org] is CORRECT host file information just to piss off the insane lunatic troll.

--

CENSORED BY SLASHDOT [slashdot.org]
CENSORED BY SLASHDOT [slashdot.org]
CENSORED BY SLASHDOT [slashdot.org]
CENSORED BY SLASHDOT [slashdot.org]
CENSORED BY SLASHDOT [slashdot.org]
CENSORED BY SLASHDOT [slashdot.org]

Re:CENSORSHIP ON SLASHDOT... apk (-1)

Anonymous Coward | about a year ago | (#43596269)

Why would I use a HOSTS file when I can just run CleanMyPC!

Jeremiah Cornelius: Grow up (-1)

Anonymous Coward | about a year ago | (#43596531)

You're embarassing yourself Jeremiah Cornelius http://slashdot.org/comments.pl?sid=3581857&cid=43276741 [slashdot.org] since you posted that using your registered username by mistake (instead of your usual anonymous coward submissions by the 100's the past 2-3 months now on slashdot) giving away it's you spamming this forums almost constantly, just as you have in the post I just replied to.

Re:Jeremiah Cornelius: Grow up (-1)

Anonymous Coward | about a year ago | (#43596551)

You fail it, Paul. Your skill is not enough.

Re:CENSORSHIP ON SLASHDOT... apk (-1)

Anonymous Coward | about a year ago | (#43596659)

It's about time they censored your repetitive blather! Go spam somewhere else.

Disprove my points coward troll... apk (-1)

Anonymous Coward | about a year ago | (#43596721)

See here, explains it all -> http://tech.slashdot.org/comments.pl?sid=3561925&cid=43223585 [slashdot.org]

* :)

I.E./Summary: Trolls had a challenge put to them to validly disprove my points in the post I just replied to - result? Trolls FAIL... lol!

APK

P.S.=> That's what makes me LAUGH harder than ANYTHING ELSE on this forums (full of "FUD" spreading trolls) - When you hit trolls with facts & truths they CANNOT disprove validly on computing tech based grounds, this is the result - Applying unjustifiable downmods to effetely & vainly *try* to "hide" my posts & facts/truths they extoll!

Hahaha... lol, man: Happens nearly every single time I post such lists (proving how ineffectual these trolls are), only showing how solid my posts of that nature are...

Ah yes "geek angst" @ it's 'finest' (not), vs. facts & truths = downmod by /. weak trolls!

... apk

Re:Disprove my points coward troll... apk (0, Redundant)

Anonymous Coward | about a year ago | (#43596871)

No one cares. No one even reads your drivel. Seek professional help.

802.11S (-1)

Anonymous Coward | about a year ago | (#43596077)

They are looking for an expanded and upgraded version of 802.11S? It would be nice, if they could.

Re:802.11S (1)

Opportunist (166417) | about a year ago | (#43596611)

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.

Re:802.11S (3, Informative)

ozmanjusri (601766) | about a year ago | (#43597971)

They could just use Android phones with the Serval Project mesh network [servalproject.org] app installed on them.

dynamicly updated hash table. (2)

happyjack27 (1219574) | about a year ago | (#43596125)

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.

Re:dynamicly updated hash table. (1)

happyjack27 (1219574) | about a year ago | (#43596161)

now the next level to this, for mobile ad-hoc networks, would be using gps data as a pre-fix to the "source" and "destination" address, and if it can't find the actual device, it routes to the known destination with that reduces the gps distance at the greatest rate. then it really becomes a path-finding algorithm with obstacles.

Re:dynamicly updated hash table. (1)

Alex Belits (437) | about a year ago | (#43596251)

So if I'll stand in Oakland with a phone, and there is Macworld in San Francisco, then almost every iPhone in US will route video stream through me?

Re:dynamicly updated hash table. (1)

happyjack27 (1219574) | about a year ago | (#43596357)

no, it will find a tentative shortest path, in terms of latency. and that will improve over time, and if you're filling it up, the latency will go up, so it will start falling over to a different path since now a different path will have lower latency...so now it has two paths that it splits the packets between so as to balance their latency...and then maybe it gets a third, or drops down to one when traffic dies down. but now someone turns their cell phone off, so now it routes around that... etc. it only uses what it needs, and it adjusts what it uses and how it gets routed to adapt to changing needs, changing traffic patterns, and changing network topology.

Re:dynamicly updated hash table. (1)

Alex Belits (437) | about a year ago | (#43596391)

But they will still contact me first, DoSing my phone by routing requests alone!
To avoid that, link status will have to be propagated through the neighbors, but then geometry will be utterly irrelevant.

Re:dynamicly updated hash table. (1)

happyjack27 (1219574) | about a year ago | (#43596497)

link status will have to be propagated through the neighbors - false. for instance, they can use an acknowledge protocol to passively learn link status
but then geometry will be utterly irrelevant - false - geometry - do you mean topology or geolocation? either way topology is relevant, obviously, and geolocation is relevant, insofar as it can provide a good guess when topology is unknown. only way to make it irrelevant is to make topology always known, and that's impossible since the topology is dynamic.

Re:dynamicly updated hash table. (1)

Alex Belits (437) | about a year ago | (#43596923)

link status will have to be propagated through the neighbors - false. for instance, they can use an acknowledge protocol to passively learn link status

What does it mean?

Either everyone is asking me how much I can pass (creating enough traffic that I can't pass anything at all), or I report it to someone, and they distribute it through the network or use only for their local part of the routing mechanism (and then they don't really care where I am physically).

but then geometry will be utterly irrelevant - false - geometry - do you mean topology or geolocation?

Physical distance determined by GPS. What should not be necessary if link parameters and network topology are already known -- if you can hear me over RF, you may be interested in my link, otherwise existence of my link only matters as a part of aggregated data that predicts available bandwidth when you route through my neighbors.

My example with a phone in Oakland demonstrates a situation when there is one obvious route for almost everyone, and it's the wrong one for the vast majority of those who thinks that it may be optimal.

Re: dynamicly updated hash table. (0)

Anonymous Coward | about a year ago | (#43596955)

Perhaps a dedicated device is better than using your phone. It would be better to have your phone connect to the network rather than be the network. phones are getting more powerful, but not that powerful. They also move around too much.

This could be achieved with a solar powered router device. 5 or ten watts, max. I think a good idea would be to have them installed on vehicles. Make the router seoarate from the vehicle so the battery does not drain. it would be useless in motion and should shut off automatically, but for the 8 to 10 hours a day that a vehicle is sitting in a driveway or parking lot, it could be a part of a network infrastructure.

Rush hour would effect this network pretty heavily, but it would be relatively stable most of the time. If mesh networking gets a foothold I am sure someone will start mass producing a device like this.

Re: dynamicly updated hash table. (0)

Anonymous Coward | about a year ago | (#43597109)

Uh huh... you are not tracking my every move with some "network" device. I mean next you'll want me to put a device in my car that can be tracked by satellite. oh wait...

Re: dynamicly updated hash table. (0)

Anonymous Coward | about a year ago | (#43602885)

Uh huh. Like the tracking device you already own, this one is completely voluntary as well. Don't want to participate? don't buy one. Heck most people have no idea it's possible or can comprehend how it is used so mesh networking is largely doomed anyway.

Your privacy argument is nice, but the real hurdle is "what do you mean, share my internet? why would I want to do that?" Even slashdot users are afraid of giving a completely free and open (no password) ssid on their network. So geeks are already out, what makes you think grandma is going to install obe of these in her house, on her cellphone or in her car?

Re:dynamicly updated hash table. (1)

happyjack27 (1219574) | about a year ago | (#43596511)

data structures would be kind of like this:

neighboring_devices table:
[neighboring_device][last_gps_coordinate][last_connected][single_hop_recieve_lag][single_hop_send_lag][last_recieved_time][last_sent_time][packets_recieved][packets_sent]

communicating_devices table:
[communicating_device][last_gps_coordinate][total_recieve_lag][total_send_lag][last_recieved_time][last_sent_time][packets_recieved][packets_sent]

route_stats table:
[communicating_device][neighboring_device][total_recieve_lag][total_send_lag][last_recieved_time][last_sent_time][packets_recieved][packets_sent]

packet header, forward info:
[source_device][destination_device][source_last_gps][destination_last_gps][sent_time][sent_from_last_hop_time]

packet header, feedback info (routing data back-propagation):
[send_back_from_last_hop_time][send_back_single_hop_time]...

Re:dynamicly updated hash table. (1)

happyjack27 (1219574) | about a year ago | (#43596527)

you can think of it kind of like an ant colony; it lays pherome trails.

Re:dynamicly updated hash table. (0)

Anonymous Coward | about a year ago | (#43596897)

So you invented a UDP/IP/ETH stack decades after the original, except this time it has even less reliability, uses even more cycles, and no loop free operation as there is no convergence. 'i dont feel like going in depth' on the ridiculous magnitude of your ego or the ineptitude of your knowledge.

This is obviously for the foot soldier. (-1)

Anonymous Coward | about a year ago | (#43596195)

The size of a battalion is between 300 and 1,200.

Google should win this one - just wait a while and the Google glasses will be the test base.

All that is needed then is to add the add-hoc network from another project (there are several actually).

Power scaling and dynamic ad hoc routing (1)

jimmydevice (699057) | about a year ago | (#43596199)

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?

Give Pirate Bay some money (0)

Anonymous Coward | about a year ago | (#43596337)

They've been experimenting with wireless mesh networking for a long time.

Re:Give Pirate Bay some money (1)

preaction (1526109) | about a year ago | (#43596505)

I think the Gnutella network (Limewire), Kazaa, or Skype are more appropriate. They're more decentralized than BitTorrent (though BitTorrent has some redundancy).

Smart meters (1)

thereitis (2355426) | about a year ago | (#43596687)

I wonder how many homes are on one 'collector': bchydro [bchydro.com]

This problem is more or less solved already (4, Informative)

tlambert (566799) | about a year ago | (#43596939)

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.

Re:This problem is more or less solved already (1)

Anonymous Coward | about a year ago | (#43597241)

So... what's the firmware? No need to keep it a secret.

Re:This problem is more or less solved already (1)

tlambert (566799) | about a year ago | (#43599011)

So... what's the firmware? No need to keep it a secret.

The firmware which has been developed in house by each of these companies, and which is not available because the WNIC vendors would have to submit the firmware and hardware as a unit to the FCC for certification as an SDR (Software Defined Radio). As such, it would be a violation of both the WNIC vendor license agreements and the FCC regulations were it to be distributed. The first loses you your relationship with the WNIC vendor, the second gets you fined at best and thrown in Federal Prison at worst.

If you want to work with this code at Google, go to work for Google and join the Chrome OS networking team. I don't have the contact information for the appropriate teams at the other companies I'm sure are doing similar work. I'm going to guess there are more than six of them, but I will also guess that they are working under the same constraints, and I only know of six from having been aware of a connectathon having been held.

Re:This problem is more or less solved already (1)

Anonymous Coward | about a year ago | (#43597287)

Google don't even want to enable ad-hoc wifi in Android... https://code.google.com/p/android/issues/detail?id=82 .. but it can be added if you are willing to install a modified cyanogenmod: http://www.thinktube.com/android-tech/46-android-wifi-ibss

Re:This problem is more or less solved already (0)

Anonymous Coward | about a year ago | (#43598659)

Google is not even replying to these questions. Talking about evil.

Re:This problem is more or less solved already (1)

tlambert (566799) | about a year ago | (#43599001)

Google don't even want to enable ad-hoc wifi in Android... https://code.google.com/p/android/issues/detail?id=82 [google.com] .. but it can be added if you are willing to install a modified cyanogenmod: http://www.thinktube.com/android-tech/46-android-wifi-ibss [thinktube.com]

Google has zero control ver Android-based product productization. All those decisions are made by the device vendor during the final productization phase by the partner (read: device vendor). This is also why there are so many versions of Android out there; each device has its own Android variant based on the exact state of the source tree at the time they did a local replica in order to start the productization phase.

If Google moved productization in-house, they could cause a more uniform environment for specific release versions, but this would not control UI differences or configuration file differences or feature differences instituted by the partner.

Nor could they force a partner to update the version of Android running on their devices. Once fielded, this would require carrier recertification of the devices before it could be deployed, and it is against the partners best interests to update devices, as that would cannibalize sales of new devices.

Ad Hoc is against the carriers best interests, since the alternative is to charge you SMS charges instead, and it's against the partners best interestes to enable UI for it, since they sell through the carriers, and the carriers do not want it enabled.

So basically you are attempting the Sisyphean task of fighting both the carriers, and their thralls, the partners, and you are holding an uninvolved third party responsible for not doing your job for you.

Re:This problem is more or less solved already (1)

drinkypoo (153816) | about a year ago | (#43599125)

Google has zero control ver Android-based product productization.

While that's true, they set defaults. Why is there still no pinless pairing in Android 4.2? You have to use an app for that, a non-localized app only in Japanese and with a minimum of icons. At least it's free... Ad Hoc networking should be included by default, too. They can't stop carriers from turning it off, but they can provide it.

Re:This problem is more or less solved already (1)

bill_mcgonigle (4333) | about a year ago | (#43600525)

Why is there still no pinless pairing in Android 4.2?

Does that mean something different than not needing a PIN to pair? I just paired my wife's Motorola Froyo phone with a headset last night and it didn't need a PIN.

Re:This problem is more or less solved already (1)

drinkypoo (153816) | about a year ago | (#43600955)

Does that mean something different than not needing a PIN to pair? I just paired my wife's Motorola Froyo phone with a headset last night and it didn't need a PIN.

Some vendors have implemented their own solutions to this problem, especially for headsets, and especially for their headsets. But no, that's all it means. For example, try pairing a PS3 remote.

Re:This problem is more or less solved already (0)

Anonymous Coward | about a year ago | (#43597605)

As I recall, the biggest current problem with this type of network for mobile devices is power. Once the power issue is solved, you're right! Good-bye AT&T. (We can only hope.)

Re:This problem is more or less solved already (1)

khakipuce (625944) | about a year ago | (#43599077)

Because the people at DARPA haven't heard of, or seen any of that!

What about, sharing IP addresses? (1)

GoodNewsJimDotCom (2244874) | about a year ago | (#43596965)

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?

Re:What about, sharing IP addresses? (1)

GoodNewsJimDotCom (2244874) | about a year ago | (#43597021)

This probably doesn't work, just thinking outside the box.

Re:What about, sharing IP addresses? (0)

Anonymous Coward | about a year ago | (#43597441)

It does work -- that's what subnetting *is.*
https://en.wikipedia.org/wiki/Subnetting
I'm pretty sure reaserches know this too, since that's the sort of thing you would learn in your first networking class (or any networking class really), so something tells me that's not where the problem is.

Just use IPv6 (0)

Anonymous Coward | about a year ago | (#43598523)

2^64 -2 addresses available.

Not an issue.

Re:What about, sharing IP addresses? (0)

Anonymous Coward | about a year ago | (#43597647)

You mean like PCs, tablets, phones, consoles, etc might be if hooked up to say, a DSL connection?

Very Easy (0)

Anonymous Coward | about a year ago | (#43597011)

Six Degrees of separation. Each node only needs to know 6 routers around it. When a packet enters the network, it is forward by the least used path (complex metric - bandwidth/traffic volume/ etc) until it strikes its source.

Seek and Yee Shall Find the Route Less Traveled Routing Protocol (SYSFRLTRP).

1. Compromising a node is not very useful.
2. Completely ad-hoc and scalable to billions of nodes.
3. Packets buffered in the cloud. (they can take a scenic route if undeliverable and expire after a set time)
4. Not suitable for time critical streams such as voice, video, real-time telemetry. (although these services could be reserved on demand - optimum pathway)
5. Does not reveal nodes in the cloud...good for stealth.
etc, etc.

IPv6 (1)

johnjones (14274) | about a year ago | (#43597041)

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

From the article (2)

Areyoukiddingme (1289470) | about a year ago | (#43597591)

"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.

Re: From the article (0)

Anonymous Coward | about a year ago | (#43598137)

A mesh network of drones, duh.

Re:From the article (1)

drinkypoo (153816) | about a year ago | (#43599133)

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.

Are you sure you can't theoretically carry 5,000 low-resolution video streams on such a network? With all nodes arranged in a line, of course you couldn't. But with multiple points of egress? You're just making things up, you have no idea what such a network might carry.

Re:From the article (0)

Anonymous Coward | about a year ago | (#43600317)

Indeed. I am starting to collect networking equipment as part of Cisco training. When I'm fiddling my house and my neighbor's (family memeber) are running ad-hoc. With just three continually on systems the bandwidth per link is over 1Gbps wireless. Why? Because I had a dozen 802.11n cards lying around and it was easy to set up. It only takes two or three cards (depending on interference) using channel pairing.

Tweak the data-link protocols (and higher ones if you want to add efficiency) along with software defined broadcast strength and run a cut down wireless version of OSPF/IS-IS. Tada!! Individual cells varying in size based on area saturation with designated control routers per cell and overlapping control, built in redundancy, automation of control, route summarization, and all the good things that get my post from me to you already.

Getting up into Gb wireles range is completely doable, massive mesh networking is already available. The only questions are what is the channel range, how much are they willing to spend on hardware/power, and how much more efficient do they want current ad hoc wireless tech to be?

Routers.. simple. (3, Insightful)

aaronb1138 (2035478) | about a year ago | (#43597707)

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.

Re:Routers.. simple. (0)

Anonymous Coward | about a year ago | (#43597941)

Self configuring routers is no problem, elections are old hat, and the routing/switching function doesn't take that much silicon. Just have each node able to transmit on two or more channels simultaneously. When a node comes up on a channel it consults the local master which understands the channel assignments and tells the radio where to connect so that no single frequency has more than the 50 or so node that can be supported on a single channel.

L2R did this over 12 years ago (0)

Anonymous Coward | about a year ago | (#43597721)

there's a little-known wireless routing protocol developed over 12 years ago

that already does everything they've been looking for, and more.

No one has come close to replicating it yet.

And I ain't holding my breath on anyone coming close any day soon.

DARPA will continue to flounder until they wake up to this technology.

Serval Mesh (1)

itsthebin (725864) | about a year ago | (#43597903)

they should talk to the Serval project people

http://www.servalproject.org/ [servalproject.org]

Re:Serval Mesh (0)

Anonymous Coward | about a year ago | (#43598665)

From their website:

The initial public release of the software is scheduled for late 2012.

Apparently, not much is going on over there...

Re:Serval Mesh (1)

bill_mcgonigle (4333) | about a year ago | (#43600535)

I had it on my phone in February. Maybe nobody is updating the website. Google Play.

B.A.T.M.A.N. Advanced scales into that range (1)

Casandro (751346) | about a year ago | (#43598233)

It's designed to do so, and has proven itself in wireless community mesh networks.

Terrible summary (2)

NoImNotNineVolt (832851) | about a year ago | (#43599881)

DARPA is not new to this: http://www.bbn.com/technology/networking/wnan [bbn.com]

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.

Problem hasn't been solved yet (1)

Anonymous Coward | about a year ago | (#43600055)

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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>