It looks like you're using an Ad Blocker.

Please white-list or disable in your ad-blocking tool.

Thank you.


Some features of ATS will be disabled while you continue to use an ad-blocker.


Leader Says Future Bomber Won’t Go Solo

page: 2
<< 1   >>

log in


posted on Aug, 19 2010 @ 05:39 AM
reply to post by ANNED

The problem is bandwidth.

What happens when you put 20 wireless connections onto a cheap $30 router?

Welcome to the land of packet loss.

Let's say you go the extra mile and buy a more powerful router - you'll do fine, right?

You'll do great until every one of those computers tries to stream real-time video, audio, etc to each other. You'll overwhelm the wireless standard. There's not enough bandwidth in an IEEE 802.2N connection to handle that.

But we're talking milspec - certainly they can do something about it.

No, they can't. They can use a range of different frequencies and open up a lot of bandwidth (they'll need to to reduce vulnerabilities to jamming) - but there's some rather interesting properties of our universe that set limits on how much information can be sent on a given frequency and its side-lobes.

Keep in mind that the lethality of the "pack" concept comes from having multiple eyes in the skies capable of sharing data between each other and using each other's weapons. That means a lot of real-time data has to be streaming to and from those aircraft. That also has to be done alongside a low-latency command link.

In the end, the only solution is to use processing nodes to collect the data from a given pack, process all of it into a single data stream, then update to a regional node (while simultaneously dispensing updates from the regional node).

It's hardly ideal, as all of your drones are going to light up on electronic sensors - your more powerful nodes could probably be hit by HOJ modes at the kind of power they would need to transmit at. And the solution is, obviously, going to have to be airborne to follow the pack around. A regional node would be a satellite or high-altitude blimp - but you would not want a direct satellite uplink from the drones, themselves - you'd want an intermediary that could issue commands and lessen network load on the satellite (and you'd also want a system that could be used, if in a more limited capacity, during solar storms and in the event China toasts the satellite).

posted on Aug, 19 2010 @ 09:53 AM
reply to post by Aim64C

You make a whole lot of assumptions about how the system may be engineered. You have a lot of good points, but their validity depends on whether what you guessed is true.

Multi-player games work reasonably well in real time, with a lot of participants and on a limited bandwidth. Case in point, you need to be smart about engineering the data exchange, and you'll be fine. You don't need to stream real time video from N points to M points. At least not always.

posted on Aug, 19 2010 @ 10:43 AM
reply to post by buddhasystem

There's also a lot less data involved in multiplayer games, and the environment is fairly structured and ordered. MMOs don't transmit a lot of data per person, and don't get into many details (WoW or STO don't actually plot weapon trajectories and the like - that's all part of a separate local rendering layer that is dependent upon the data layer). While a lot of FPS games keep things rather limited because of the amount of data that does have to be transmitted (where you are looking, where you shot, etc). FPS games are also the most drastically influenced by lag and packet loss.

Think about what our combat networks already handle. They can transmit real-time radar images and telemetry to every other system plugged into the network. In theory (and in practice) an E-2 can guide an AMRAAM to its terminal guidance phase - so can a properly connected satellite.

Even so, this is not done by updating the entire network at the rate necessary to provide guidance, it is a separate request that is treated as a sub-network. IE - the E-2 connects to the AMRAAM (directly or through a proxy), the AMRAAM doesn't just plug into the 'big picture' and sort it out on its own. The 'Big picture' is not updated in a manner timely enough for guidance against targets like aircraft, or even ships.

So for a UCAV pack, you need a much more agile network with a lot of bandwidth and very low latency. The only way to do this is to have a node that does two things: creates a tactical picture for the pack to use and make decisions off of, and a strategic picture - which is the 'big picture' that is much slower and more cumbersome.

That way, you retain strategic use of your pack while not sacrificing tactical effectiveness. Although the network requirements will mean that the packs will have to operate independently and exclusively - you couldn't have two separate packs working in transmitter range of each other very effectively. They would crowd bandwidth far too much, and you'd start to see network collisions.

Yes, they're guesses, but educated ones.

And in the end - it would be a very effective system to employ with a manned aircraft being the 'tactical node.' It would be a force-multiplier as opposed to a force replacement. Having a UCAV pack that can run interference for a Wild Weasel or strike aircraft is priceless. You could assign them to transport helicopters, attack helicopters - you name it. At the very least, you give your enemy something else to worry about and take some pressure off of you.

new topics
<< 1   >>

log in