Harq & Arq Interactions in Lte

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 24

HARQ & ARQ INTERACTIONS

IN LTE NORMAL OPERATION


& HANDOVER
- Richa Samel
[email protected]
TECHNOLOGY GOALS
Why use both HARQ and ARQ
Challenges resulting from TCP
requirements and how HARQ & ARQ
provide a solution
Situations where both HARQ & ARQ
are necessary
How this technology addresses the
challenges faced in HSPA
How losses due to mobility are
avoided


OVERVIEW OF HARQ & ARQ
Retransmissions of missing or data units in error are
handled primarily by the hybrid-ARQ mechanism in the MAC
layer, complemented by the ARQ retransmission
functionality of the RLC layer in LTE.

IEEE Communications Magazine April 2009: The LTE Link Layer Design
Need for both HARQ & ARQ
The reasons for having a two-level
retransmission structure can be found in the
trade-off between fast and reliable feedback of
the status reports.
The hybrid-ARQ mechanism provides very fast
retransmissions which is suitable for high
speeds used in LTE, whereas the ARQ is
responsible for reliability
Usually HARQ can deal with most transmission
errors but sometimes the mechanism fails and
another one, that is ARQ is also needed.
HARQ FEEDBACK
HARQ feedback is fast and frequent to correct
transmission errors as soon as possible so
that the end-to-end RTT is low.
A synchronous one-bit ACK/NACK signal is
sent every transmission attempt and the timing
of the feedback message is used to identify
the corresponding data transmission.
However, this binary feedback is
susceptible to transmission errors.
ARQ STATUS REPORTS
An additional ARQ protocol layer provides a
much more reliable feedback mechanism based
on asynchronous status reports with explicit
sequence numbers that are protected by a cyclic
redundancy check (CRC).
This implies that the receiver of the status
report can detect any errors in the report
through the CRC.
HARQ is also applied to status messages.
The combination of the two protocols can be
viewed as ONE retransmission mechanism with
TWO feedback channels.
Challenges due to TCP
requirements
Although it is possible to attain an arbitrarily
low error probability of the hybrid-ARQ
feedback, it comes at a cost in transmission
power.
Keeping the cost reasonable typically results
in a feedback error rate of around 1%, which
results in a hybrid-ARQ residual error rate of
a similar order.
Such an error rate is in many cases far too
high; high data rates with TCP may require
almost error-free delivery of packets to the
TCP protocol layer
Challenges due to TCP
requirements
As an example, for data rates
exceeding 100 Mbit/s, a packet-loss
probability less than 10^(-5) is
required.
The reason is that TCP assumes
packet errors to be due to congestion
in the network.
Any packet error therefore triggers
the TCP congestion-avoidance
mechanism with a corresponding
decrease in data rate.
HARQ & ARQ together satisfy
TCP requirements
Compared to the hybrid-ARQ
acknowledgements, the RLC status reports are
transmitted relatively infrequently and thus the
cost of obtaining a reliability of 10^(-5) or lower
is relatively small.
Hence, the combination of hybrid-ARQ and RLC
attains a good combination of small round-trip
time and a modest feedback overhead where
the two components complement each other
fast retransmissions due to the hybrid-ARQ
mechanism and reliable packet delivery due to
the RLC.
TYPES OF HARQ ERRORS
Residual HARQ errors: NACK is
misinterpreted as ACK, Maximum
number of retransmissions is reached,
DTX misinterpretation as ACK. In
these cases, the receiver does not
get the correct data
Non-Residual HARQ errors: ACK
misinterpreted as NACK. Receiver
gets duplicate data which can be
just discarded.
NEED FOR ARQ/HARQ
INTERACTIONS
For Residual HARQ errors
For RLC Acknowledged Mode(AM)
For non real time, delay tolerant
applications
Eg web browsing, email
SITUATIONS WHERE ARQ
INTERACTS WITH HARQ
When maximum retransmissions are reached
and the data transmission is unsuccessful
When a receiver expects a HARQ
retransmission but sees no transmission in
the expected TTI or receives a new
transmission. This is due to a NACK to ACK
error
If the UE misses the scheduling information
and the eNB misinterprets the DTX as ACK.
NACK TO ACK ERROR
The second error case is detected by the
HARQ receiver, because it expects another
HARQ retransmission but it receives a new
transmission.

http://www.ntpo.org.tw/tjc/presentation/5_A%20Fast%20Retransmission%20Technol
ogy%20for%20the%203GPP%20Long%20Term%20Evolution.pdf
NACK TO ACK ERROR
In this case the receiver sends two
feedback messages. The first is the
ordinary HARQ feedback for the new
transmission.
In addition, it sends an explicit ARQ
feedback message indicating the
residual HARQ error with timing
reference
DTX TO ACK ERROR
The third error case i.e. the receiver failed to
detect the transmission, occurs when a receiver
does not send HARQ feedback, but the transmitter
misinterprets that it received an ACK

http://www.ntpo.org.tw/tjc/presentation/5_A%20Fast%20Retransmission%20Technolo
gy%20for%20the%203GPP%20Long%20Term%20Evolution.pdf
DTX TO ACK ERROR
This cannot be detected at the HARQ layer,
because the receiving HARQ entity is not
aware that it missed anything.
So the RLC at the receiver can detect the
missing PDU based on ARQ Sequence
Number
The ARQ sequence number has to be used
in the reliable feedback, because the receiver
has no timing reference to the failed
transmission.

IMPROVEMENTS IN LTE OVER
HSPA
In HSPA, the HARQ and ARQ protocol
operate basically independent of each other.
The different protocol termination points on
the network side (ARQ in RNC, HARQ in
NodeB) do not provision for a tight coupling
between the two.
For LTE, both HARQ and ARQ are
terminated in the same nodes, in UE and
eNodeB. This allows for a tighter
interworking.

HSPA PROTOCOL STACK
Dr. H. Hmimy s slides on EETS 8315 Advanced Topics in Wireless
Communication
DISADVANTAGE OF
HARQ/ARQ in HSPA
ARQ protocols often use timers to protect
against certain deadlock situations. In
HSPA, the configuration of these timers is
complex since the network architecture
might be very different from one network to
another resulting in different delays.
Thus, the timers often need to be set to
cope with worst case scenarios. This may
slow down the protocol operations
unnecessarily.

ADVANTAGES of HARQ/ARQ in
LTE
If protocols are operated in the same node,
it is more efficient to use triggers to inform
an upper protocol of certain events rather
than relying on upper layer timers. This
eliminates delays.
Second, even if two protocols are specified,
the implementation of these two protocols
might make use of certain shortcuts. For
example, the same memory could be used
to store data units. Also protocol states can
be shared easily
HSPA v/s LTE HANDOVER
In HSPA, since HARQ resides in the
NodeB, while ARQ resides in RNC, the
RNC can keep a track of the RLC
sequence numbers and their current states
and provide this information to the new
NodeB
In LTE this is not possible as both
HARQ/ARQ terminate at the same layer.
The target eNB has no idea of the RLC
states of the source. So the challenge of
how to achieve seamless mobility arises
SOLUTIONS FOR
HANDOVER
During handovers, there are two alternatives
that could be implemented for RLC AM:
1) The complete ARQ state including the
buffers is transferred from one eNB to the
other. This allows that the ARQ can basically
continue in the new cell. Such an approach is
complex
2) In the downlink, all unacknowledged SDUs
are forwarded to the new eNB. In the uplink,
all unacknowledged SDUs are retransmitted
towards the new eNodeB. The RLC/MAC
layers are reset.
SOLUTIONS FOR
HANDOVER
Therefore handover in LTE for RLC AM contains
losses which are dealt by retransmissions.
In order to avoid wasting radio resources by
performing unnecessary retransmissions, the
MAC scheduler tries to complete all ongoing
HARQ processes before the connection in the
old cell is released.
PDCP SN reports are sent by both UE and eNB
to avoid duplicate transmissions. Duplicate
removal and in-sequence delivery of the PDCP
SDUs also are handled by the PDCP, based on
the PDCP SN.

REFERENCES
CHAPTER 12: RETRANSMISSION PROTOCOLS from 4G LTE/
LTE-Advanced for Mobile Broadband by Erik Dahlman, Stefan
Parkvall and Johan Skold
IEEE Paper : ARQ Concept for the UMTS Long-Term Evolution by
Michael Meyer, Henning Wiemann, Mats S gfors, Johan Torsner,
Jung-Fu (Thomas) Cheng
IEEE Communications Magazine April 2009: The LTE Link Layer
Design by Anna Larmo, Magnus Lindstrm, Michael Meyer,
Ghyslain Pelletier, Johan Torsner, and Henning Wiemann
http://www.ntpo.org.tw/tjc/presentation/5_A%20Fast%20Retransm
ission%20Technology%20for%20the%203GPP%20Long%20Term
%20Evolution.pdf
http://www.etsi.org/deliver/etsi_ts/136300_136399/136300/08.06.0
0_60/ts_136300v080600p.pdf ie 3GPP TS 36.300 version 8.6.0
Release 8 Page 45

You might also like