The GSM air interface does not have any error correction!!
Neither does the HSCDS (with different channel coding than
basic GSM, especially different than what is used for voice)
Both have channel coding, or as I suggested, "error reduction".
The unreduced errors are _corrected_ to error free data
by an end-to-end error correction system.
OK???
----
As the airinterface channel is dynamic, changing,
HSCDS includes at least three different degrees of
"error reduction"
- no error reduction (22kbps, same as "raw data")
- medium error reduction (14.4kbps)
- strong error reduction (9.6kbps)
(there is probably some additional ones from the
original GSM, for 4.8 down to 1.2kbps??)
In addition to this inherent part of the airinterface,
errors are finally corrected by regular end-to-end
mechanisms at both ends.
Your question, slightly corrected, is obviously a
smart question:
"How does the elimination of this GSM error reducing
(was correction) technique nevertheless result in the
transmission of error-free data using ( was by) HSCSD?"
Now it is a qustion which is connected to what
really is done with HSCDS as with most other systems.
The answers:
1. the error _reduction_ system reduces errors to below an
error rate that the _error_ _correction_ system can
handle, to still work efficently with.
2. error free data is _not_ guaranteed by the HSCDS
airinterface, just as it isn't with any telecommunication system.
3. error free (virually, one error in 100 year) is
guaranteed by end-to-end error correction systems.
4. the correction mechanism is usually done in four parts
- grouping the data in blocks, frames
- adding a checksums to the block,frame
- the receiver can detect if data is error free by
comparing the block of data to the checksum
- if not the same, a message is sent to the transmitter
to retransmit the same block, frame of data.
-----
The explanation on how they work together is at its
simplest like this.
block lenght = 1,000 bits
error rate = 1/10,000
works fairly OK, every tenth block, on the average,
containes an error and must be retransmitted.
Net transmission rate decreases by appr 10%
An example where it doesn't work
block lenght = 1,000 bits
error rate = 1/1,000
Now almost every block will have an error, must
be retransmitted, but that block will have another
error.
One or two blocks might get through "by accident"
every know and then.
----
The obvious solution would be to reduce the block lenght
to 100 bits, giving
block lenght = 100 bits
error rate = 1/1,000
Once again 9 out of 10 block go through without errors,
works OK.
But now the overhead, frame,checksum, for that 100 bit block
might be close to another 100 bits, halving the net
transmission rate.
----
In its most rudimentary form this was called an ACK/NAC
for acknowledged, not acknowledged (retransmit) protocol.
The problem that the tranmistter had to wait for a
responce to send the next block of data.
Pretty bad if block size is 100 bits and back and forth
delay is 0.5 seconds, one block every second, 100bps.
The obvious solution to number the blocks, blast out
them "in advance", and the other end replays "please
resend block number 7"
keywords HLDCS (?? long time ago, high level data control
system), MNP (microcom network Protocol).
Adding compression comes close to what is used today,
LAPDM and v42bis, Link Application Protocol..??)
Ilmarinen
The point with voice-data and errors is that voice
(coders) are designed to work almost OK with 1/100
to 1/1000 error rates, few error correction systems
can cope with one error in 100 bits.
But even this is far from reality, where a multipath
fading wireless channel tends to have a lot of
errors in one place, then be better for a "longer" time,
which actually is very short compared to other systems.
I beleive some articles has been written reasently
which try to hammer in this simple fact, wireless
communication is not what wired is, far from it. |
