TECHNOLOGY GOALSWhy 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 & ARQRetransmissions 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 & ARQThe 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 FEEDBACKHARQ 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 REPORTSAn 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 requirementsAs 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 ERRORSResidual 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 INTERACTIONSFor Residual HARQ errorsFor RLC Acknowledged Mode(AM)For non real time, delay tolerant
applicationsEg 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 ERRORThe 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%20Technology%20for%20the%203GPP%20Long%20Term%20Evolution.pdf
NACK TO ACK ERRORIn 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 ERRORThe 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%20Technology%20for%20the%203GPP%20Long%20Term%20Evolution.pdf
DTX TO ACK ERRORThis 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. H’mimy ‘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 LTEIf 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 HANDOVERIn 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 HANDOVERTherefore 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 Lindström, Michael Meyer, Ghyslain Pelletier, Johan Torsner, and Henning Wiemann
http://www.ntpo.org.tw/tjc/presentation/5_A%20Fast%20Retransmission%20Technology%20for%20the%203GPP%20Long%20Term%20Evolution.pdf
http://www.etsi.org/deliver/etsi_ts/136300_136399/136300/08.06.00_60/ts_136300v080600p.pdf ie 3GPP TS 36.300 version 8.6.0 Release 8 Page 45