You are on page 1of 12

It's very important to use solutions that improve the efficiency of the adopted model in any

data communication system. If the transmission is 'Wireless', this need is even greater.
In this scenario we have techniques that basically checks, or verify if the information sent
by the transmitter correctly arrived in the receiver. In the following example, we have a
packet being sent from the transmitter to the receiver.
If the information arrived properly (complete, the receiver is ready to receive (and process
new data. If the information arrived with some problem, corrupted, the receiver must
request that the transmitter sent the packet again (retransmission.
!et's understand a little more about these concepts increasingly used (and required in the
current systems"
Note: All telecomHall articles are originally written in Portuguese. Following we
translate to English and Spanish. As our time is short, maybe you find some typos
sometimes we !ust use the automatic translator, with only a final and "#uic$" re%iew&. 'e
apologi(e and we ha%e an understanding of our effort. )f you want to contribute
translating * correcting of these languages, or e%en creating and publishing your tutorials,
please contact us: contact.
Error Checking and Correction
We start talking about errors. #rrors are possible, and mainly due to the transmission link.
In fact, we can even 'expect' errors when it comes to Wireless $ata %ransmission.
If we have errors, we need to take some action. In our case, we can divide it into two steps&
error checking and error correction.
#rror checking is required to allow the receiver to verify that the information that arrived is
correct or not.
'ne of the most common methods of error checking is the ()(, or '(yclic )edundancy
(heck', where bits (()( are added to a group of information bits. %he ()( bits are
generated based on the contents of the information bits. If an error happens with the
information bits, the ()( bits are used to verify and help recover the degraded information.
%he level of protection provided is determined by the ratio& number of ()( bits by the
number of information bits. *bove a certain error level, the process is eliminated. ()(
protection is used practically in all existing +oice and $ata applications.
%he following diagram shows a simplified demonstration of how the ()( is used.
*nd the ()( is directly connected to the #rror (orrection methods. %here are various ways
of ,oward #rror (orrection (,#(, but the main idea is, given a level of quality in the link,
try to get the lowest number of required retransmissions.
-inimi.ing the number of retransmissions we ended up having a more efficient data flow
result, including / mainly / the '%hroughput'.
In simplified way& the ()( lets you know if a package arrived ''0' or '1'% '0'. #very
packet that is sent has a ()(, or a '2ignature'. *s an analogy, it's like when we send a letter
to someone, and in the end we sign& '-y ,ull 1ame'. When the other person receives this
letter (information, he checks the signature& '-y Wrong'. In this case, he tells the
-essenger& 'I don't know '-y Wrong', this information has some problems. 3lease ask
sender to send it again4'.
I.e. I do ()( checks. If the ()( is 'wrong', the information is 'wrong'. If the ()( is 'correct',
probably the information is 'correct'.
Retransmissions
)etransmissions are then& send information again (repeat to the receiver, after it make
such a request. %he receiver requests that the information be retransmitted whenever it
cannot decode the packet, or the result of decoding has been an error. %hat is, after
checking that the information reached the receiver is not ''0', we should request it to be
retransmitted.
'f course, when we have a good link (21), without interference or problems that may
affect data integrity, we have virtually no need for retransmissions.
In practice, in real World, this is very difficult to happen, because the links can face the
most different adversities. %hus, an efficient mechanism to enable and manage the
retransmission is essential.
We consider such a mechanism as efficient when it allow data communication in a link meet
quality requirements that the service demands (5o2.
+oice for example, is a service where retransmission does not apply. If a piece of
information is lost, and is retransmitted, the conversation becomes intelligible.
'n the other hand, data services practically rely on retransmission, since most have / or
allows / a certain tolerance to delays 6 some more, some less. With the exception only for
')eal %ime' services.
7ut it is also important to take into account that the greater the number of needed
retransmissions, lower the data transmission rate that is effectively reached& If the
information have to be retransmitted several times, it will take long for the receiver to
obtain the complete / final / information.
ARQ
%ill now we talked in a generic way about data retransmissions, error checking and
correction. !et's now see some real and practical schemes.
%he simplest way (or more common control using what we described above is known as
*)5, or '*utomatic )epeat )equest'.
In *)5, when we have a 'bad' package, the system simply discards it, and asks for a
retransmission (of the same package. *nd for this, it sends a feedback message to the
transmitter.
%hese feedback messages are messages that the receiver uses to inform whether the
transmission was successful or not& '*(0nowledgement' (*(0 and '1on/*(0nowledgement'
(1*(0. %hese messages are transmitted from the receiver to the transmitter, and
respectively informs a good (*(0 or bad (1*(0 reception of the previous packages.
If in the new retransmission the packet keep arriving with errors, the system requests a
new retransmission (still for this same package. %hat is, sends another '1*(0' message.
%he data packets that are not properly decoded are discarded. %he data packets or
retransmissions are separately decoded. %hat is, every time a packet that arrives is bad, it
is discarded, and it is requested that this same package be retransmitted.
7ut see that if there were no retransmissions, the performance of the data flow would be
much better. In the example below, compared with the previous, we transmit more
information / 8 times in the same time interval.
9nfortunately we don't have much to do about the link conditions. 'r better, we are able to
improve the links performance, for example with configuration parameters optimi.ation, but
we'll always be sub:ect to face adverse conditions. In this case, our only way out is to try to
minimi.e retransmissions.
*nd that's where arise other techniques or more 'enhanced' schemes for retransmission.
%he main one is ;*)5.
Hybrid ARQ (HARQ)
%he ;*)5 is the use of conventional *)5 along with an #rror (orrection technique called
'2oft (ombining', which no longer discards the received bad data (with error.
With the '2oft (ombining' data packets that are not properly decoded are not discarded
anymore. %he received signal is stored in a 'buffer', and will be combined with next
retransmission.
%hat is, two or more packets received, each one with insufficient 21) to allow individual
decoding can be combined in such a way that the total signal can be decoded4
%he following image explains this procedure. %he transmitter sends a package <=>. %he
package <=> arrives, and is ''0'. If the package <=> is ''0' then the receiver sends an '*(0'.
%he transmission continues, and is sent a package <?>. %he package <?> arrives, but let's
consider now that it arrives with errors. If the package <?> arrives with errors, the receiver
sends a '1*(0'.
'nly now this package <?> (bad is not thrown away, as it is done in conventional *)5. 1ow
it is stored in a 'buffer'.
(ontinuing, the transmitter send another package <?.=> that also (let's consider arrives
with errors.
We have then in a buffer& bad package <?>, and another package <?.=> which is also bad.
$oes by adding (combining these two packages (<?> @ <?.=> we have the complete
information"
Aes. 2o we send an '*(0'.
7ut if the combination of these two packages still does not give us the complete
information, the process must continue / and another '1*(0' is sent.
*nd there we have another retransmission. 1ow the transmitter sends a third package
<?.?>.
!et's consider that now it is ''0', and the receiver sends an '*(0'.
;ere we can see the following& along with the received package <?.?>, the receiver also has
packages <?> and <?.=>, that have not been dropped and are stored in the buffer.
In our example, we see that the package arrived ? times 'wrong'. *nd what is the limit of
these retransmissions" 9p to B. I#, we can have up to B retransmission in each process.
%his is the maximum number supported by 'buffer'.
Different HARQ Schemes
Coing back a little in the case of (onventional *)5, whenever we send a package and it
arrives with problems, it is discarded.
%aking the above example, when we send the package <?>, and it arrives with errors, it is
discarded. *nd this same package <?> is sent again.
What happens is that we no longer have the concept of 'package version' / <?.=>, <?.?>, etc.
We do not have the 'redundancy' version, or the gain we get in ;*)5 processing.
%o understand this, we need to know that information is divided as follows&
+)nformation , -edundancy , -edundancy.
When we transmit the packet <?> we are transmitting this&
+)nformation , -edundancy , -edundancy.
When retransmit the same package <?> we are retransmiting it again&
+)nformation , -edundancy , -edundancy.
7ut when we use ;*)5, and retransmit packet <?.=> or <?.?>, we have the possibility of&

'r retransmit that same information againD

'r retransmit only the redundancy.


*nd then, if we retransmit less information (only redundancy, we spend less energy, and
that will run much faster. With this we have a gain4
%hat is, we work with different 'versions of redundancy', that allows us to have a gain in the
retransmission. %his is called ')edundancy +ersion', or what version of redundancy.
%he redundancy version, or ;*)5 scheme with '2oft (ombining' can be '(hase (ombination'
or 'Incremental )edundancy'.
HARQ Chase Combination
EChase CombinationF& when we combine the same information (the retransmission is an
identical copy of the original packet.
We transmit an information, which arrived wrong, and we need to do a retransmission. We
retransmit the same information / and there we don't have much gain.
HARQ Incremental Redundancy
EIncremental RedundancyF& where we retransmit only the portion that we didn't
transmitted before. %hus we retransmit less information. !ess information means fewer bits,
less energy. *nd this gives a gain4
)edundancy bits are retransmitted gradually to the receiver, until an *(0 is received.
With this, we adapt to changes in the condition of the link. %he first retransmission can, for
example, contain or not bits of redundancy. If necessary, a small number of these bits is
retransmitted. *nd so on.
inishing for today! "hat are the # ste$s of HARQ% &hy it gi'es me a
(ain%

,irst because from wrong packets = and ? we can get a correct one, since we do not discard
erroneous packets anymore.

2econd because we can / also in retransmission / send less information, and streamline the process.
%he use of ;*)5 with '2oft (ombining' increases the received #bGIo effective value for each
retransmission, and therefore also increases the likelihood of correct retransmissions
decoding, in comparison to conventional *)5.
We send a package, and it arrives with errors& we keep this package. )eceive the
retransmission and then we add or combine both.
HARQ )rocesses (Case Study)
What we have seen so far clarifies the concepts involved. In practice, in retransmission, this
type of 3rotocol is called '2top *nd Wait' (there are other kinds of similar protocols.
What would be& send the information and stop. Wait for the response to send other
information. 2end, wait for response. 2end, wait for response ...
1o4 1ot so in practice. In practice, we work with a number of 'processes', which may vary
for example from B, H or I. %he following image illustrates this more clearly.
*ther ty$es of HARQ
1ew schemes are constantly being developed and used, as the type III ;*)5, which uses
self/decodable packages.
7ut enter these variations, terminology and considerations, is not the scope of our tutorial,
which was simply to introduce the concept of )etransmission, *)5 and ;*)5.
7ased on the key concepts illustrated here today, you can extend your studies the way you
want, however we believe that the most important thing was achieved 6 understand how it
works and what are all the cited concepts.
+A,A A$$let
7elow, you can see how some retransmission schemes work. %here are several *pplets
available, for the many possibilities (*)5, ;*)5, With 2liding Windows, 2elective, etc.
%he next is a link for a J*+* *pplet that simulates a '2elective )epeat 3rotocol transmission'.
http&GGmedia.pearsoncmg.comGawGawKkuroseKnetworkKBGappletsG2)Gindex.html
Conclusion
%his was another tutorial on important issues for those who work with I% and %elecom& data
%ransmission and )etransmission techniques, *)5 and ;*)5.
*)5 is used for applications that allow a certain delay, as Web 7rowsing and 2treaming
*udioGvideo. It is used widely in Wimax and Wi,i communication systems. ;owever, it
cannot be used in +oice transmission, as for example in C2-.
;*)5 for example is used in ;23* and !%#, and therefore must be a well/understood
concept for those who work or want to work with these technologies.
We hope you en:oyed it. *nd until our next tutorial.