backtop


Print 61 comment(s) - last by rcc.. on Apr 1 at 4:26 PM


The B2 Bomber's radar frequency was recently sold to a Russian entrepeneur on accident. The incident emphasized the military's increasing spectrum woes.  (Source: U.S. Air Force)

The F22 Raptor's AWACS targeting probably won't work outside the U.S. This is just one of the many costly spectrum issues the Air Force and armed forces are having in the U.S. as civilian spectrum use increases.  (Source: Wikimedia)
Costly blunders and redesigns all part of military networking growth pains

The U.S. military originally had a virtual monopoly of certain communications channels.  It was one of the few entities to be using internet, and it used many areas of the spectrum untouched by civilian communications.  However, with the digital revolution and the expansion of civilians onto the internet and increasing using of the digital spectrum, the military is finding adapting to the deprivation of these bands difficult.

Last year during the bandwidth auction, the portion of the spectrum used by the B-2 bomber's Raytheon APQ-181 radar was accidentally sold to an obscure multinational organization according to Military.com.  As a result, U.S. taxpayers will be footing the over $1B USD bill to replace the radar in the 20 remaining jets.

With users demanding video-ready smartphones, high-speed mobile internet, and other emerging applications, the military is finding that the spectrum is quickly disappearing, and it’s having trouble finding areas for its own sensitive technologies.

Other expensive losses abound.  The Joint Tactical Information Distribution System, a costly system used to get AWACS targeting data to F-22 fighter jets has "limited supportability outside the continental U.S."

Another key issue is the steady creep of civilian communications into the spectrum used for flight-test telemetry.  While there are workarounds to gather some additional information, telemetry data remains essential to testing both manned and unmanned aircraft and protecting pilots from failures.

Ultimately, more data takes more bandwidth -- an unalterable fact -- and to achieve higher frequencies more power is required.  This places inherent limitations to the amount of data capable of being communicated over the spectrum.

Military designers are in a sticky situation as they can't compress their data, in many cases, like civilian applications.  "This is not a cell phone,” said Darrell Ernst. "You can't ask the pilot to wait while you redial."

Ernst works for the Mitre Corp., a member of a U.S.-European delegation trying to raise international awareness of bandwidth issues, and estimates that by 2020 the Air Force will need 600 MHz of spectrum for telemetry data.  Currently the only vacant spot suggested to them is the 5091 and 5150 MHz band.  The Air Force is eager to occupy even this meager 59 MHz offer.  States Mr. Ernst, "If [the flight-test community] can get in there and start using it, we can be established as the primary user and it will be hard for them to throw us out."

When it comes to the spectrum issues, there are few good answers, just more fears and doubts.  As a final example of the industry problems, when the Joint Strike Fighter (JSF) test program is flying two missions no other combat aircraft will be able to fly in the Western U.S.  States Mr. Ernst, "They're the 600-lb. gorilla. They don't see that they have any reason to move, and they don't have the radios to do it."



Comments     Threshold


This article is over a month old, voting and posting comments is disabled

Why can't they compress data??
By estarkey7 on 3/23/2009 12:13:59 PM , Rating: 3
How do you back up the statement that the military can't compress communications data? Can you provide a citation or white paper that would give reasons why this is not possible.

I myself have a hard time believing this is true, unless the data is already compressed as much as it can be...




RE: Why can't they compress data??
By Amiga500 on 3/23/2009 12:45:25 PM , Rating: 2
They can...

High speed data-bursts are compressed data - the shorter your transmission time - the harder it is to detect - kinda critical eh?

I am somewhat confused at the mentioning of that in the article.


RE: Why can't they compress data??
By dever on 3/23/2009 3:16:47 PM , Rating: 2
The question I have is why does the military expect to monopolize any bandwidth? Do they really think an enemy state is going to honor their claim to a certain frequency range? If not, then they should practice at home by similarly having to work around the private sector.


RE: Why can't they compress data??
By Adonlude on 3/23/2009 6:59:40 PM , Rating: 2
I see what you are saying but do you really want the military "working around" the private sector here in America? If so expect droped calls and lost connections as the military jams and overpowers communication signals at will.


By RagingDragon on 3/28/2009 12:47:52 PM , Rating: 2
Or better yet, bombs annoying civilian transmitters? In an actual war blowing up inconvenient enemy tranmitters would be a viable option - but it's not so viable when "working around" the domestic private sector.


RE: Why can't they compress data??
By afkrotch on 3/23/2009 8:46:30 PM , Rating: 1
During peace times, yes. I would expect a differing country to honor their agreements to leave specific freq ranges open.

During war, trying to jam communications would be an obvious tactic. Pinpoint the jam, then drop a bomb on it. Easy work around.


RE: Why can't they compress data??
By Griswold on 3/24/2009 9:50:26 AM , Rating: 2
What agreement? Most countries outside NATO or without US military presence of significance (Japan, S-Korea for example) wont have any agreements with the US of that kind.

Also, a capable military doesnt jam frequencies from one single position that can be destroyed by a single bomb anyway. Thats a hollywood fairytale.


RE: Why can't they compress data??
By Alpha4 on 3/23/2009 12:54:24 PM , Rating: 1
I'm guessing telemetry data can't be compressed because even a 1 millisecond delay to decompress it could compromise a target acquisition and cause even a tiny mis-alignment for precision targeting.

I remember an article discussing the "Surveillance Target Attack Radar System" (STARS) system and how it was completely written in assembly code to minimize processing time. That's probably consistent with all military software, though.


RE: Why can't they compress data??
By barjebus on 3/23/09, Rating: 0
RE: Why can't they compress data??
By Lord 666 on 3/23/09, Rating: 0
RE: Why can't they compress data??
By hyperbolicparody on 3/23/2009 2:42:25 PM , Rating: 4
Ada is still used extensively for aircraft and DoD applications. OFPs are still often written in Ada83, as are a lot of the military flight and ground simulations (both for testing and training purposes) out there, and I think it's a total shame that it wasn't until recently there was a free compiler (GNAT has come a long way in the past few years).

I actually wouldn't be surprised if the data coming off of the OFPs would be remarkably hard to compress. Working on them... hooks for simulation, test and debug are such an afterthought... the engineers are primarily focused on the insane flaming hoops they must jump through to get everything written, verified and approved.

There's rarely ANY overhead written into the hardware specs, and the components are horrifically sensitive to timing requirements. It makes non-normal operation rough... you might find your component locked out of the MS1553 bus (or even worse designed to self-destruct) if it's cycle count is out-of-whack with other components. But that's all done to make components pulled from crashed aircraft useless.

Also, it's tough to compress data fast enough on the hardware available. It's not the size, it's the volume, and it's the hardware on the aircraft. Gathering and packaging all your data at deterministic rates higher than 200Hz is harder than you think... and need all that data transmitted to the ground station with as little transport delay as possible. Also, imagine trying to do all of that on the embedded hardware available to you 10 years ago.

...oh, and some of it is written in FORTRAN. FORTRAN!


By lotharamious on 3/23/2009 3:25:40 PM , Rating: 4
quote:
...oh, and some of it is written in FORTRAN. FORTRAN!

What's wrong with Fortran? It's a powerful computation language. Unless you're talking about something prehistoric like Fortran 4.


RE: Why can't they compress data??
By rcc on 3/23/2009 4:15:40 PM , Rating: 1
True, but anything that is mission critical, or time critical, gets an automatic exception to the requirements for Ada.

For that matter, if you can claim COTS (commercial off the shelf) you can get an automatic exception.

Ada isn't fast, and it isn't small.


RE: Why can't they compress data??
By eachus on 3/24/2009 5:12:33 PM , Rating: 2
True, but anything that is mission critical, or time critical, gets an automatic exception to the requirements for Ada.

I wish I thought you were joking. Just about everyone who works on safety-critical systems, including mission critical systems, now knows that the only sensible choice is SPARK. SPARK is technically a subset of Ada, but the subset of interest is that programs in Ada that cannot be proven correct are not valid SPARK. Even if the Ada compiler produces no errors or warnings, the SPARK Examiner will reject any program, or module, as incorrect or ambiguous if it can't be proven correct. The savings from using SPARK on just about any large program are significant, and it results in even larger savings in safety-critical systems.

Check out this article: http://www.stsc.hill.af.mil/crosstalk/2002/03/amey... on the C130J project. The author said: In my 10-plus years of using SPARK, I have never needed to use a debugger. I have become so used to things working the first time that my debugging skills have almost completely atrophied. The only price I pay for this is the SPARK Examiner pointing at the source code on my terminal and displaying messages telling me I have been stupid again; I find I am grateful for those messages!

The author works for a company that produces SPARK tools, but I can vouch for the above. The only two times in the last 20 years or so of programming in Ada that I have had to use a debugger, the error turned out to be in Solaris. No, I am not knocking Sun or Solaris, and both of those (obscure) bugs have since been fixed. But I knew my program was correct, so the bug had to be in the OS. ;-)

As for efficiency of Ada programs, lots of studies have shown that the code produced from Ada programs identical to the C version are much the same, assuming you chose the right compiler options in both cases. GNAT for example has an option to avoid loading--or using--any compiler run-time. Slower and bigger if you write programs which make heavy use of the run-time, much faster and smaller otherwise.


RE: Why can't they compress data??
By SignoR on 3/23/2009 12:58:57 PM , Rating: 5
I believe what they mean by "compressing" the data is to send a larger amount of data on the same corresponding bandwidth of the EM Spectrum. Satellite companies use Quadrature Phase-shift keying (QPSK:wiki it) to modulate their signals and increase the amount of data that can be sent in the same analog bandwidth. The article talks about the "constellation diagram" QPSK uses 1 point per quadrant(for 4 total 'symbols'). You can increase the number of symbols in each quadrant (64QAM has 16/Quadrant and 1024QAM has 256/quadrant) in order to push more data through, but for each increase in the number of symbols you need a higher SNR ratio in order to not lose data. The higher SNR requirements are not obtainable at the modest speeds of cars on a highway, much less mach 2+.
I assume this is what they define as compression, not running the data through winzip a couple more times.


RE: Why can't they compress data??
By nafhan on 3/23/2009 1:01:10 PM , Rating: 3
Since they were comparing this to civilian communications (cell phones), I'm going to go out on a limb here, and say
he probably meant that they can't overallocate the number of channels in critical applications.
With a cell phone tower, it would be OK to only have enough bandwidth for 5 people even if there are 10 users with cell phones in the area. There might be a rare missed call or dropped signal, but that's OK. It's even standard practice.
With critical military applications, such as telemetry, all 10 users need to have their own channel all the time. No exceptions.


RE: Why can't they compress data??
By nixoofta on 3/23/2009 2:44:18 PM , Rating: 5
RE: Why can't they compress data??
By ebeneezersquid on 3/24/2009 3:15:26 PM , Rating: 2
Why can't they compress data?

Encryption.

They all ready compress the data all they can, then encrypt it with heavy duty keys (256+).
They then may compress again, but the encryption adds a LOT of bulk to the data.
If you want to help, find a slimmer form of encryption that is just as secure, then navigate the byzantine maze of Regulations in order to get it approved for military use.


By MozeeToby on 3/24/2009 6:32:40 PM , Rating: 2
After encryption it would be pointless to try to recompress the data. You can't compress random data, which is what encryption produces.


RE: Why can't they compress data??
By Smilin on 3/27/2009 4:23:01 PM , Rating: 2
Encrypted data cannot use lossy compression.

Furthermore it cannot use lossless compression effectively as highly encrypted data is nearly random and has few patterns.


By RagingDragon on 3/28/2009 1:03:38 PM , Rating: 2
Data can be compressed before it's encrypted, though I guess that might might weaken the encryption. It's also possible that the hardware on the aircraft simply doesn't have the processing power to compress large volumes of data (in addition to whatever else it's doing), and that adding that capability would be prohibitively expensive or time consuming.


"We can't expect users to use common sense. That would eliminate the need for all sorts of legislation, committees, oversight and lawyers." -- Christopher Jennings

Related Articles













botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki