SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Nokia (NOK) -- Ignore unavailable to you. Want to Upgrade?


To: carranza2 who wrote (12800)6/19/2001 3:48:43 PM
From: Eric L  Read Replies (1) | Respond to of 34857
 
re: Error Correction in HSCSD

What do you have against (lack of or minimized) error correction? When, why, how much is important? If reduced what is the consequence (in wireless mobile or stationary use)?

c2: "Intellectually honest? I try to be as rigorous as possible in my thinking. The HSCSD "cure" you suggest involving backwards de-evolution from GPRS is flawed because of the lack of error correction and cost. Not a mass-market tool, thus unlikely to make money. My opinion."

c2: GPRSux so de-evolve and congest the networks by ripping out error-correction and giving GSM another name. Not a great way to evolve. Just my opinion.

c2: As far as I know, error correction has not yet been incorporated into HSCSD.

EL: Well, has it or hasn't it? Perhaps. Can you verify that? I can't (or haven't taken the time to).

c2: My apologies to Illmarinen for characterizing his statement as "pimping." Uninformed? I'm not so sure. In the ultimate analysis, HSCSD is nothing but GSM without error correction.

Well, Ilmarinen being the class citizen of this thread that he is, I'm sure he will accept the apology.

As for me. You aroused my curiosity

If this sounds funny it is because it is translated from German:

nokia.at

Probably available in English if you care to look.

>> A New Coding Pattern

HSCSD is a new coding pattern for GSM data communication. With GSM altogether 22.8 is kBit/s at bit rate for order, with Datenuebertragungungen of it however only to 9.6 kBit/s is used - the remaining 13,3 kBit/s for error correction bits are used, so that the data arrive complete and safe.

With speech transmissions (thus when normal telephoning) it is already used since beginning of the GSM standard 13 kBit/s which can be explained thereby that the human ear does not register small errors, these during data communication is however inexcusable. What is situated thus more near to use as for data communication more of the max. possible 22.8 kBit/s?

The response to it gives the new channel coding, with which 14.4 kBit/s for the actual data and only the remainder for the error correction bits are used.

The gain of 50% at rate has also a small disadvantage: the cell cover reduces easily, because the further the base station is distant, the error correction bits become the more important. And if fewer corrections can be executed, then the distance of the base station may be to large not, if no problems are to occur. <<

... so now you know. Now I know. It's been like the blind leading the bloody blind. <g>

BTW: As you know GPRS may speed up with new coding schemes - based on reduced error correction - but now that EDGE is nigh, they may nebver be used, but if they are, same consequence:

The first option carriers will have to enhance GPRS is adding new coding schemes that increase rates to 15Kbits/sec or 21Kbits/sec per time slot (up from the current data transfer rate of 13Kbits/sec). These new coding schemes reduce the amount of forward error correction, and so require a strong signal. No carriers have committed to these coding schemes, however, because the next upgrade step, EDGE, offers far better performance.

... of course there are also new vocoders under consideration. GPRS will be around for a long time, and one way or another will get faster.

- Eric -



To: carranza2 who wrote (12800)6/19/2001 7:06:09 PM
From: 49thMIMOMander  Respond to of 34857
 
Carranza, the GPRS "caveat" is those sloppy GPRS networks
some deliver, always almost good enough, every month
sure to be fixed next month. (until the year runs out)

Not the first time, nothing new, but the way some company
cultures are.

HSCSD bypasses all of that, the all-digital channel is there
for those who connect GSM to GSM calls, part of
international GSM roaming. (the bits won't be converted
to analog speech at some weird point, will reach
the destination correctly, in most cases)

However, the 2-3-4 bitstreams might be hooked up,
connected slightly differently, different delays,
if some stuff is not "HSCSD aware", so it must be the
terminals who figure out when to ask for a re-transmit
(whaddyasay error correction??)

Note that voice is OK with some errors here and there,
not necessarily in the airintereface, but because of
sloppy stuff inbetween base stations, still OK for
voice.

GSM (voice) obviously has channel coding to cope with
deep fading,etc, but if the terminal is fairly
pedestrian (like the good doctor) this is not needed.
(additionally the gaussian FSK has some inbuilt
eror correction, channel coding, compared to QAM, ask
Trellis-Viterbi and FSK-Wozencraft)

I'm sure you understand that voice cannot tolerate
varying transmission delays, needs to use convolutional
channel codes, but "data" does not need those guaranteed
delays, can use full raw data speeds using that old
method of whaddyasay when garbage is sometimes received.
(without getting into the grey area where neither one is
good enough, like with regular, mobile CDMA)

One example I often use for educational purposes is
this interesting way of transmitting data using the
tail of meteorites as a reflector.
When that meteorite falls, one can transmit Gbytes of
data for a split second, inbetween nothing.

Not good for full duplex voice transmission, but
great for (military) data, as long as a star falls
every now and then.

Additionally extremely good for understanding the
extremes, meaning of channel coding, interesting case to
have to wait for the next meteorite to be able to say
which data didn't get through, packets still
missing, numbering the missing ones,etc (protocols)

Another good case, including redundancy, is the wife talking
in the kitchen while trying to catch to the news and the
kids are running around the house.

Ilmarinen

That is, a "raw channel" might transmit just garbage
when on the limits, and even if asking for a
retransmit (whaddyasay) it will still be just
the same garbage (static for old radio guys).
Channel coding, or forward error correction, is
used to lift that signal above the "statics"
by kind of switching to a lower bitrate.
(this big shannon thing, almost)

Backward <g> error corrections is adding some checksums
to the data, the receiver can find out if the
(whole block, packet of) data is correct or not.

If OK, no problem.

If not correct, ask the other guy to repeat what he said.

The fear of any system like this, in marriage leading to
divorce, is wasting more time on claiming what was said
correctly and what wasn't (this part of telecom 101 is
mostly targeted on more mature participants)

The beauty of GSM (gaussian FSK) is that users,channels
are fairly isolated from each other, as well as
those in neighboring-neighboring cells on the same
channels.

That is, channel error rates can be fairly well predicted,
are isolated, independent, especially for pedestrian users
for GSM, not so for CDMA.

For fast moving users it gets more complicated,
turns more into that meteorite example, blast
data when data really goes through, don'twaste time when not possible, change fast between high speed, capacity
trucks and slow tractors which eventually will arrive,etc...

Ilmarinen

That is, this thing which is finally hitting the
academic fan, that

- shannon capacity limit can be achieved with infinity
delay in receiving the data. Ie. most of the shannon data
hasn't arrived yet, few will be around when it does.

- considering both latency (delay) limits and
channel limits is still to difficult for regular
academics, but regular folks have always found solutions
for this academic problem (whaddyasaid)