Slashdot Mirror
Turbo Codes Promise Better Wireless Transmission
captain igor writes "IEEE is running a story about two French professors that have created a new class of encoding, called 'Turbo Codes,' that will allow engineers to pass almost twice as much data through a given communications channel, or equivalently, the same amount of data at half the power. The new codes allow the Shannon Limit (the theoretical maximum capacity of a channel) to be approached to, currently, within .5 dB. Scientists hope that this breakthrough will revolutionize wireless communications, especially with the coming reclamation of large swaths of the EM spectrum." As the article points out, such codes are in use now, but seem poised for much wider implementation.
It also seems to be making a natural progression into new areas, beginning at satellite transmissions 11 years ago and making it's way into other digital wireless applications along the way.
Thanks to timothy for almost clearing this up
Eve Fairbanks says I drive a hybrid!LOL
Like the article says, these codes were introduced in 1993. This would have made a good story - back then.
The problem is that turbo codes are so computationally intensive that using them in consumer electronics is only new becoming feasible.
Yep, it has been, thats what adsl uses I belive...
God, root, what is the difference?
That's the Nyquist limit actually. ;-)
The term "turbo" is applied here in analogy because of the "turbo principle" in the decoder. The outputs of two decoders are compared and then fed back to improve the original estimate (almost like feeding the exhaust energy back into the input stream to improve output).
You are a tard. If you want to start arguing about the misappropriation of terminology, then you grease-covered gearmonkies need to remember that ribogeeks have always known turbo as a genus of gastropoda, and Romageeks have long known that turbo is the nominative singular construction for a whirlwind, and the 1st person present active conjugation of turbo, turbare meaning to disturb or agitate.
In other words, get your wrench out of your ass.
Turbo codes aren't really new. As the article states, they were invented in 1993. I have a big stack of papers on them at home.
Turbo codes have a few problems, though. One, they are a pain to implement and consume a lot of resources. Two, turbo codes are SNR dependent, which makes them harder to use in varried channels.
The article also makes it seem like there were no coding advances since Shannon published his orginal paper on channel capacity. Ungerbock's papers on trellis coded modulation (TCM) from 1987 or so radically altered digital communications, and he should have been mentioned. Some of the current turbo code research is trying to unify TCM and Turbo Coding (TTCM), which has great promise once it is practical.
(S(SKK)(SKK))(S(SKK)(SKK))
Error correction again seems like one of the bottom less pits... like trying to achieve zero kelvin... perfect vacuum and of course this landmark talk by feynman.
Another thing that worries me is why all prepostrous claims are met with so much resistance.... relativity, quantum mechanics, secure-crashfree-windows(oops)...
strange world we live in.
[all generalizations are untrue except this one]
Nyquist is the sample-rate guy (the Nyquist theorem).
Shannon capacity is the theoretical bit-rate you can stuff through a channel of a given physical bandwidth with a given signal to noise ratio:
C = W * Log2(1+S/N)
where C is capacity (bits per second), W is bandwidth (Hz), S is signal power, and N is noise power.
As far as Turbo Codes go, without getting too technical, its an extension of the principle that you can increase the efficiency of a channel while transmitting at a given power by attaching some redundant bits (redundant signal dimensions is probably a better way to look at it, though) to the signal. I'm not too familiar with the particulars of Turbo Coding, but it is a lot like Viterbi coding where these redundant bits are dependent on the data bits and when you detect an error (the redundant bit doesn't match the proper sequence), you back-trace through your data and find the most likely non-errored sequence and adjust your data bits accordingly.
Tim
There are a lot of high data rate links where it's either prohibitively complex to implement turbo codes, or the nature of the channel actually makes trellis codes concatenated with some other code a better choice.
--- Ban humanity.
As other posters have commented, turbo codes have been around along time. Any Digital Modulation Course will cover it.
Turbo Codes do have one major drawback
After partially reading the FA It seems that this scheme is particularly well suited for what it is currently doing, Sat Comm and deep space probes where you have alot of computational and analysis power at the recieving end but not a good way to ask for a re-transmission, when you have a multiple second (or multiple hour) latency in your communication system but really, this is not going to be in a cell phone for quite a while, cell phones are built to make lots of connections from one tower, not to make your phone get insane coverage or to make your battery last longer. especially the stuff abour predicting bit value based on analog value, so now we turn every digital reciever into a digital reciever + Analog to Digital reciever in x bits.... honestly i think most consumer applications are not worth the added cost. keep in mind it has been 11 years since this tech came out... communications companies aren't stupid... it WOULD be on the market if it was feasable/affordable.
Snowden and Manning are heroes.
Sort-of. You may be thinking of the Nyquist criterion, but this is related in a way. Shannon was the first to quantify the concept of information via "entropy", which leads to the concept of "mutual" or shared information (i.e. between inputs and outputs of a channel). Distortion (additive noise or some other form) limits the amount of mutual information shared between the input an output of a channel, and is independent of the nature of the data source. Thus, he proved that communication channels have a theoretical limit to the amount of data that can be reliably (error free) transmitted through them. He also suggested coding as a method to achieve this theoretical limit, which turbo codes approach for certain classes of channels (additive gaussian noise channel, for instance).
well they are not exactly a compression technique... but basically an error correcting technique.... like hamming. And thus help you transfer more reliably at the same power.
see this small writeup
besides changes like the one you talk about would require hardware changes... as i said its not compression
[all generalizations are untrue except this one]
My understanding is that thay aren't employed for modems, but not for any fundamental reason. Rather, turbo decoding requires evaluating certain likelihood functions before the iterations begin, and the likelihood function evaluations can be rather complicated when the channel doesn't fit the additive white Gaussian noise model. Experimental tests indicate that the background interference on phone lines doesn't behave much like white Gaussian noise, especially or ADSL modems. Apparently (older) Reed-Solomon codes work well for these applications.
No. A POTS line has 64000bps of bandwidth (minus 8000bps for signalling). That is the maximum number of bits you can push across the connection per second.
Dewey, what part of this looks like authorities should be involved?
Compression is weird.
You can calculate the best possible compression scheme for handling arbitrary data. That is, the compression algorithm which, if you fed it every possible combination of input data, would compress the data the best. The algorithm is called Huffman coding.
The problem is, in actual use Huffman coding is crap. Why? Because real data isn't random, it doesn't cover the entire space of possible data.
So useful compression algorithms take advantage of the non-randomness of actual data, to do significantly better than Huffman--but only for particular kinds of data. For instance, run-length encoding is fabulous at compressing bitmap graphics which have large areas of the same color--but feed it plain text, and it's hopeless. Lempel-Ziv algorithms are great at compressing plain text, but they're not good at compressing audio files.
As someone else has pointed out in the threads, if you allow your compression scheme to be useful only for particular files, and allow the compression and decompression software to be arbitrarily complex, there's essentially no limit to how tight you can compress data.
For example, suppose I want to write some software which will compress webcam images of playing cards on a table, for transmission across the net. One approach is to have the encoder recognize the cards, and make the decoder contain a complete set of playing card images. That lets me compress a complete 24-bit image of playing cards on a table into a few bytes--a byte to say which card, one to say what angle it's at, and send them in order from back to front. Of course, the resulting code is useless if someone drops a $20 bill on the table, and doing the compression is a bitch.
So in general, there's no way to tell what the technical limit is on compression. There's usually a tradeoff between how specialized the compression is, and how effective; and if your application allows lossy compression, you can compress still further (e.g. JPEG, MP3).
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I just heard about Turbo Codes recently, but from a different perspective. I think at the time, they developed these codes with rates so close to the Shannon limit, and no one believed it. Even then, I don't think they were aware of the theoretical basis for why they worked.
Theory finally caught up with them more recently, from the framework of probabilistic networks. It turned out that if you have a Bayesian network with cycles, inference is difficult. But there is a method of belief propagation through message passing that can be used, and it turned out that this is exactly what these guys were doing. (The network itself would include a probabilistic model of noise and its effect on the messages from the sender to receiver.)
This technique is only for one very small specfic part of the specturm, a communication channel. Communcation channels can very from a few khz in size to a few Mhz, I belive 6Mhz is the biggest which was orginally for TV but channels orginally desinated for TV are not being used for 802.11b and g.
The total spectum goes from 30hz right up past light at some crazy big number. Frequecies below 30Mhz are called HF, these frequceys are pretty full but the total band is only 30 Mhz, thats only 6 TV channels, or alot of small 30khz voice channels. This band is so saturated because its not limited to line of sight and its possible to communicate right around the world on it. Its also the easyest to transmit and recive on because filters for these low frequcencies have very high Q(very narrow bandpass, basicly tune better). At these freq. things are already pretty saturated but are strictly regulated along with most of the spectum up to 300Ghz.
Frequcencys from 30Mhz-1Ghz have been the primary frequecys for local communications for the past 50 years or so. Ever since super-hetrodyning has been around, that allows you to "move" a freq down to a lower intermediated frequecy where you have high Q filters. This range is pretty full too, not much room for new communications, aircraft, broadcast tv and radio, police, cell phones, everything is in this range, old UHF tv channels were resently given up to make room for cellphones. These bands are strickly los, well rf los which is a little better than optical line of sight, lower frequencys refract and difract more than higher frequncy light..
Above 1Ghz has been very expensive to use up untill recently. With the advent of new semiconductors and processes its now viable to use these frequecys. There is lots of bandwidth up here to use, alot of it is tied up in radar and with the miltary which is just legal BS because 99.999% isn't being used. Its more political than techinical. There is also quite a bit of it being wasted by older technology that use like 20Mhz for a 6Mhz signal.
Also alot of companies own rights to these microwave frequenies(above 1Ghz) and have swiched to fiber optics and they are just sitting their idle.
Frequencys above 1Ghz can be used again and a again in diffrent areas provided they are seperated by mountains or the curvature of the earth. The problem with 802.11b is that there are only 3 channels that don't overlap.
Also with frequencys above 1 Ghz you can use a dish to focus the signal in one area rather than using more power in all directions. This way you will only interfear with people using the same frequcys in the direction that your dish is pointing. This flashlight vs a room lamp, the flashlight can light up a small area far away and so can the room lamp, but the room lamp uses more power because it also lights up the full room.
In short there is tones of spectum left, we just need to get some of it back from the military and wasteful users.
God, root, what is the difference?
I've seen that some people are curious about Shannon's limit, so I though I would give a little insight to it. It starts, with Nyquist's theorem which states:
max data rate = 2H log V bits/sec
Here, H is the bandwith available, usually through a low-pass filter, and V is the number of discrete signal levels (V = 2 in a straight binary system).
This equation however is for a noiseless channel, which doesn't exist. So Shannon updated the formula for a channel which contains a signal-to-noise ratio. This turns out to be:
max bits/sec = H log (1 + S/N)
Here the log is again base 2, H is still the bandwith (in Hertz) and S/N is the signal-to-noise ratio in dB. Notice that the parameter V is missing. This is because no matter how many discrete symbols you have, or how often you sample them, this is still the maximum number of bits/sec that you will be able to attain.
Most coding schemes, or modulation techniques as they are also called, rely on shifting signal amplitude, frequency, and phase to transmit more than one bit per symbol. The problem is that the more symbols there are, the harder it is to detect them correctly with the addition of noise. Basically, when you fire up your modem, and you hear all that weird buzzing and beeping, a lot of that is time being spent for your modem trying to determine just how noisy the channel is, and what the best modulation scheme it can use is while still being able to detect symbols correctly.
Microsoft should hire me. I can write code that doesn't work faster than the guys they have doing it now.
No. Huffman coding is only optimal if the block size grows to infinity. In that case, it can approach the Shannon limit. For finite data sets (i.e., all data sets), arithmetic coding performs slightly better on a per-symbol basis, because it is able to use fractional numbers of bits to represent symbols.
Huffman is never used on its own, except as a demonstration of basic compression algorithms. It's commonly used as the final step in entropy-coding the output symbols of another compressor, commonly a lossy compressor, like JPEG, MP3, or MPEG.
The problem is, in actual use Huffman coding is crap. Why? Because real data isn't random, it doesn't cover the entire space of possible data.
In actual coding, it is crap, but not for the reasons you listed. It's crap because it's infeasible to allow the block size to grow without bound, since the number of possible codes increases exponentially.
As someone else has pointed out in the threads, if you allow your compression scheme to be useful only for particular files, and allow the compression and decompression software to be arbitrarily complex, there's essentially no limit to how tight you can compress data.
There's a very clear limit, given by the Shannon entropy (which can vary widely, depending on the transformations you apply to the data). It is also limited by the quite obvious pigeonhole principle. You cannot pick an algorithm which will compress a given data set arbitrarily well.
So in general, there's no way to tell what the technical limit is on compression.
No. The limit is definitely the Shannon entropy. You cannot magically represent data using fewer bits than necessary (and Shannon's entropy tells you how many that is). What changes between compression algorithms is the transformations which are applied to the data, or in other words, the different ways of looking at it which reveal a lower entropy than other ways of looking at it. However, the limit is always the Shannon entropy. The transformations can toss out data which is irrelevant. Your playing card example is a good one -- the information which is relevant is which card it is and possibly its angle. You've applied a transformation to the data -- transformed it from a bitmapped image to a series of card values and positions. You can then compress those pieces of information with Huffman codes (if the entropy allows it).
I have been dying for an article in my field to post on! Actually new classes of LDPC codes based on finite geometries have shown that you can construct them at almost any size (say 1000 bits, much more practical). These 'algebraic' LDPC codes perform much better than both Turbo codes and other LDPC codes mostly because they have more structure and are not generated by random computer searches.
;-)
Also they don't require the more time consuming decoding algorithm needed for Turbo Codes (although they can be used). Check 'em out, you can search for papers on IEEE Xplore. Also someone is working on research to show Turbo Codes are LDPC codes! Crazy.
I almost crapped my pants when I saw that statement that Turbo codes were new.
-Take that Lisa's beliefs!
"Take that Lisa's beliefs!" - Homer Simpson
We're talking about signal loss. Every 3db your signal doubles (or halves if you're talking about loss). If your losing 3db of signal information that means you're only using half of the theoretical bandwidth avalible in a frequency. Which means you can only have half the theoretical amount of people using the same cell phone frequency. Therefore, as you use better encoding algos to lessen the loss in db you can cram more people into the same frequency and get a better density ratio for your signals. So 1db less loss is significant.
-Foxxz
.... was the fate of Shannon. He is the father/creator of information theory which he shared with the world in a brilliant paper. He was afflicted by Alzheimer's disease, and he spent his last few years in a Massachusetts nursing home.
"Consensus" in science is _always_ a political construct.
If you use high-speed "1x" data (e.g. 153 kbps) on the CDMA networks from Verizon, Sprint, others, there is a reasonable chance that you are already using turbo codes (the high-speed data channels also support convolutional codes).
Check here for all the gory detail (WARNING: 2.3 MB PDF).
Gee- thats funny. I work a a satellite internet company, and we use Turbo-codes in our FPGA's. The delay from TPC is in the low milisecond range- trust me.
Anything close to one second would have been unacceptable.
I dont know where you got your numbers from.
This is not some dumb use of turbo to mean fast, it's based on the fact that the decoders are using feedback to improve the error correction. This quote is taken from the article:
It was France Telecom that asked Berrou to come up with a commercial name for the invention. He found the name when one day, watching a car race on TV, he noticed that the newly invented code used the output of the decoders to improve the decoding process, much as a turbocharger uses its exhaust to force air into the engine and boost combustion. Voila: "turbo codes"!
Of course, the fact that I graduated from the school where they're teaching/doing research may be the reason I feel that I need to defend their name choice...
Could turbo codes be used with a 56K modem giving somewhere around 80kbps of bandwidth?
Nope. (They'd actually reduce the data rate if used.)
Turbo codes are members of the class "Forward Error Correction" codes, which are used to correct errors that creap in during signal propagation from a sender to a receiver over a noisy channel. They work by sending EXTRA bits (typically 3 times as many with turbo), then processing what you get to correct the errors.
Turbo codes are typically used on noisy analog channels - such as radio links. Because they make the data bits less susceptable to noise you can reduce the amount of power you use to transmit them. It's like saying the same sentence three times in a noisy room, rather than scraeming over the noise level just once, so the guy at the next table can hear exactly what you said.
Turbo code (and other FEC codes) send more bits. But because the underlying data is so much less likely to be received incorrectly the sender can can reduce the amount of power used for each bit by MORE than enough to make up for the extra bits. You can trade this "coding gain" either for more BPS at a given power level or a lower power consumption at a given BPS.
But adding bits also increases the amount of information you're sending - either by broadening the bandwidth or more finely dividing the signaling symbol (for instance: more tightly specifying and measuring the voltage on a signal). So if your bitrate is limited by the channel capacity rather than the noise level you're stuck. The coding scheme will "hit the wall" and after that the extra bits come right out of your data rate. Not a problem with Ultra Wideband, or with encoding more bits-per-baud to get closer to a noise floor. But a big problem with telephone connections.
If you had a pure analog telephone connection they would be useful for increasing your bandwidth utilization. And in the old days you did. And analog modems struggled to push first 110 BPS, then 300, then 1200 through it despite the distortion and noise. Then they got fancy and cranked it up to 9.6k and beyond by using DSPs.
But these days you don't have an analog connection all the way. Your analog call is digitized into 8,000 8-bit samples per second and transmitted at 64,000 BPS to the far end. No matter WHAT you do to your signal you can't get more than that number of bits through it.
(This is actually very good, by the way, if the connection is more than a couple miles long. The digital signal is propagated pretty much without error, while an analog signal would accumulate noise, crosstalk, and distortion. So for calls outside your neighborhood you usually get a better signal-to-noise ratio with the digital system for the long hops than with an analog system. That's why cross-continent calls these days sound better than cross-town calls in the '50s.)
In practice it's worse than 64,000 BPS - because the system sometimes steals one of the bits from one sample in six for signaling about dialing, off-hook, ringing, etc. And you don't know WHICH sample. So you can only trust 7 of the bits. 56,000 BPS max. (It's a tad worse yet, because some combinations of signals are forbidden due to regulatory restrictions on how much energy you can put on a phone line - a particular signal could slightly exceed the limit. This makes the actual bit rate a little lower. And you have to sacrifice a little bandwidth to keep the receiver synchronized, too.)
And you only get the approximately 56k in the downlink direction, because to use it you have to have a digital connection at the head end to make full use of the digital transmission. At your uplink you can't be sure enough of the sampling moment to create a waveform that would force exactly the right bit pattern out of the A-to-D converter. So you have to fall back to a modulation scheme that allows some slop when you're transmitting at the POTS end of the link. (If you had a digital connection at both ends - i.e. ISDN - yo
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
The article simply says that turbo coding is about to go mainstream.
DSL modems, by the way, shout real loud.
Just for those reading, DSL isn't just louder shouting, it's shouting at a much higher frequency so there's a lot more waves to float your data on. =)
Please consider making an automatic monthly recurring donation to the EFF
I RTFLA and the attached pdf . First, let me say that the PDF sums it up, you can avoid the article. Second, I would like to know, according to this pdf, how did the system rate a +8 on a scale of -7 to +7?
These large block sizes are not a problem at high data rates or on very long deep space links where the propagation delay still exceeds the block transmission time, but they are a problem with heavily compressed voice where low latencies are required.
One way to decrease the average latency associated with a forward error correcting code is to attempt a decode before the entire block has been received. If the signal-to-noise ratio is high, the attempt may succeed; if not, you wait, collect more of the frame and try again, and you've only lost some CPU cycles. This is called "early termination", and it's one of the tricks done in Qualcomm's 1xEV-DO system, now deployed by Verizon as BroadbandAccess. 1xEV-DO is probably the first widespread commercial application of turbo codes. A 128-byte code block is used to get good coding gain. This relatively large block size is practical because 1xEV-DO is primarily designed for Internet access rather than voice.
The original paper is here
E 127/EE127B/handout/berrou.pdf
.. not "new", but currently still a hot topic in telecomm.)
Claude Berrou, Alain Glavieux, and Punya Thitimajshima, "Near Shannon Limit Error-Correcting Coding and Decoding:Turbo-Codes", in Proceedings of IEEE International Conference on Communications, (Geneva, Switzerland), pp. 1064--1070, May 1993.
http://gladstone.systems.caltech.edu/EE/Courses/E
(with 400 citations, as counted by CiteSeer ResearchIndex
http://citeseer.ist.psu.edu/context/31968/0
-- yeah, it is since 1993
about the authors, the first two are French professors who had already mentioned in the article, the last one is Thai, at that time a PhD student at Ecole.
Yes, I hear that Space-Time coding is the 'new deal' for Rayleigh type fading channels. A few people in my dept. have been doing research into these codes. I should probably read the work whenever I don't have other projects, assignments, TA duties, marking, etc. to do. ;-).
What amazes me is how far behind these companies are in actually implementing this technology. 10-years old is actually new.
A friend of mine was saying that even when new research developments are implemented in new hardware the IT people (read: customers) don't understand how to use it anyways or just don't configure it at all (his comments applied specifically to high-end network hardware and new routing schemes). Reminds me of people who setup the company wireless network with 'default'.
"Take that Lisa's beliefs!" - Homer Simpson
Usually the dB refers to the signal power to noise power ratio (SNR) -- noise power is usually proportional to the noise variance. Thus, an SNR of 0 dB means that the signal power and the noise power is the same.
Ability to accurately distinguish bits in a communication system decreases with data rate (crudely speaking, this is because you get less time to "look" at each bit and distinguish it from noise.) For a given communication system, we have an acceptable probability of bit error, say 10^-6. Given this probability, usually we try to find the minimum SNR for a given data rate so that the criterion is achieved. To say that one system has 3 dB gain over another is to say that 3dB is the difference in SNR required to achieve the required probability of error. Since noise power is usually normalized, this means the difference in signal power is 3 dB.
Of course, you can look at the problem from the other direction and say, for fixed SNR, what is the difference in data rate? In this sense, SNR and data rate are interchangeable.
Toronto-area transit rider? Rate your ride.