Tdoc R2-060971
`
`3GPP TSG-RAN WG2 #52
`
`Athens, Greece, March 27-31, 2006
`
`Agenda Item:
`
`6.4
`
`Source:
`
`Title:
`
`Ericsson
`
`Outer ARQ and HARQ
`
`Document for: Discussion and Decision
`
`1 Introduction
`This paper is based on the assumption that in the LTE architecture Outer ARQ is terminated in the NodeB.
`Based on that assumption, a concept for interworking between Outer ARQ and HARQ is described. Since
`Segmentation and Multiplexing are tightly related to the ARQ and HARQ functions, they are also taken into
`account.
`Section 2 outlines requirements which need to be taken into account for the design of the ARQ and HARQ
`entities and their interworking. Section 3 describes the proposed ARQ and HARQ concept. Section 4
`provides a text proposal for the RAN 2 TR [1]. Finally, Section 5 summarizes the conclusions.
`
`2 Requirements for ARQ and HARQ
`For the design of the ARQ and HARQ protocols it is important to understand the requirements they have to
`fulfill. The most important requirement for ARQ protocols is to increase the reliability of the transmission
`link. In earlier contributions [5] it has been argued that for TCP-based applications a residual loss rate below
`10-6 is required in order to support the maximum peak data rates envisioned for LTE. Thus, the protocols
`should be designed in a way that supports sufficiently low residual error rates.
`Furthermore, it is obvious that retransmissions take time and increase perceived delays. Therefore, it is
`important that the retransmission mechanisms operate quickly and do not add unnecessary delays.
`Additionally, ARQ and HARQ protocols require different types of signaling and control information. It is
`important to keep in mind that in particular out-of-band control signaling is expensive in terms of radio
`resources and thus should be kept on a minimal level in order to not affect the system capacity too much. In
`particular, attention should be paid to required sequence number fields, ARQ and HARQ feedback
`signalling, and segmentation and concatenation related control fields.
`Finally, the ARQ protocol complexity is an important issue. It has been argued before that the R6 RLC AM
`protocol is too heavy-weight for a back-up ARQ protocol [2] while the biggest portion of transmission errors
`is corrected by the underlying HARQ protocol. Therefore, it is a requirement to limit the complexity of the
`Outer ARQ functionality to the level required by the requirements on delay and residual error rate.
`Different options for interworking between HARQ and ARQ exist. However, in general the assumption is
`that the HARQ protocol is responsible for correcting the main portion of radio transmission errors with
`minimal delay, while the Outer ARQ protocol is seen as last resort to deal with residual HARQ errors of any
`kind and to provide the required reliability level, which is costly to achieve with a HARQ protocol only.
`Based on the requirements and considerations provided in the section, the preferred solution is described in
`the next section.
`
`NSN 2002 (R2-060971).doc
`
`1/5
`
`2017-10-17
`
`IPR2017-1609
`
`NSN 2002 Page 1
`
`Huawei v. NSN
`
`

`

`3 LTE HARQ and ARQ Concept
`
`3.1 MAC Structure
`The proposed ARQ & HARQ interworking concept assumes that both HARQ and ARQ are sublayers in the
`MAC protocol layer.
`The data flow through the MAC protocol is depicted in Figure 1. Incoming MAC SDUs are the ciphered
`PDUs of different Radio Bearer (RB) flows. Each flow belongs to a certain QoS class and is queued into the
`packet queue associated to that particular QoS class.
`
`
`• UE• UE
`
`CapabilitiesCapabilities
`
`
`
`RBRB
`
`
`
`RBRB
`
`
`
`RBRB
`
`
`PacketPacket
`
`QueueQueue
`
`Mgmt.Mgmt.
`
`
`PacketPacket
`
`QueueQueue
`
`Mgmt.Mgmt.
`
`RB PDURB PDU
`
`DTCH/DCCHDTCH/DCCH
`
`
`PacketPacket
`
`QueueQueue
`
`Mgmt.Mgmt.
`
`
`PacketPacket
`
`QueueQueue
`
`Mgmt.Mgmt.
`
`
`
`DTCH/DCCHDTCH/DCCH
`
`
`
`DTCH/DCCHDTCH/DCCH
`
`
`
`DTCH/DCCHDTCH/DCCH
`
`
`DLDL
`
`SchedulerScheduler
`
`
`Outer ARQOuter ARQ
`
`Segm./Conc.Segm./Conc.
`
`TSNTSN
`
`
`Outer ARQOuter ARQ
`
`Segm./Conc.Segm./Conc.
`
`TSNTSN
`
`
`Outer ARQOuter ARQ
`
`Segm./Conc.Segm./Conc.
`
`TSNTSN
`
`
`Outer ARQOuter ARQ
`
`Segm./Conc.Segm./Conc.
`
`TSNTSN
`
`
`MAC-os PDUMAC-os PDU
`
`Multiplexing UE1Multiplexing UE1
`
`
`
`Multiplexing UEnMultiplexing UEn
`
`
`
`HARQHARQ
`
`
`
`HARQHARQ
`
`
`MAC-o PDUMAC-o PDU
`
`DL-SCHDL-SCH
`
`
`
`DL-SCHDL-SCH
`
`
`• Available• Available
`
`ResourcesResources
`
`• Resource• Resource
`
`QualityQuality
`
`
`• Scheduled• Scheduled
`
`Information BitsInformation Bits
`
`• Scheduled• Scheduled
`
`ResourcesResources
`
`Figure 1: MAC Structure for the eNodeB, downlink
`
`Figure 1 shows the assumed structure of the eNodeB MAC layer for the downlink that is used in the
`following to explain the Outer ARQ and HARQ functionality. The scheduler decides which data is scheduled
`for the transmission in the next TTI under consideration of various inputs, e.g., available radio resources and
`their quality, buffer contents, delays, …
`Once the scheduler has decided, the scheduled data is extracted from the corresponding queues. All data
`from one queue is segmented and/or concatenated and finally encapsulated in one MAC-os PDU. It then gets
`assigned a transmission sequence number (TSN). The TSN sequence number space is maintained per flow
`and is needed for re-sequencing on the receiver side.
`If data from more than one RB transmission chain is scheduled, then these MAC-os PDUs from different
`RBs are multiplexed and the associated MAC-o header is built. A MAC-o PDU is a synonym for transport
`block. More details about the multiplexing can be found in [4]. Here it is only important to understand that
`several MAC-os PDUs can be multiplexed in a single transport block as opposed to HSDPA.
`
`3.2 HARQ and Outer ARQ
`Figure 2 provides a deeper insight into the proposed ARQ and HARQ interactions.
`
`NSN 2002 (R2-060971).doc
`
`2/5
`
`2017-10-17
`
`IPR2017-1609
`
`NSN 2002 Page 2
`
`Huawei v. NSN
`
`

`

`
`
`RBRB
`
`
`
`RBRB
`
`
`PacketPacket
`
`QueueQueue
`
`Mgmt.Mgmt.
`
`
`PacketPacket
`
`QueueQueue
`
`Mgmt.Mgmt.
`
`
`
`RBRB
`
`
`
`RBRB
`
`
`
`DTCH/DCCHDTCH/DCCH
`
`
`
`DTCH/DCCHDTCH/DCCH
`
`
`RB PDURB PDU
`
`DTCH/DCCHDTCH/DCCH
`
`
`
`DTCH/DCCHDTCH/DCCH
`
`
`Outer ARQOuter ARQ
`
`Segm./Conc.Segm./Conc.
`
`TSNTSN
`
`
`Outer ARQOuter ARQ
`
`Segm./Conc.Segm./Conc.
`
`TSNTSN
`
`
`
`Reliable NACKReliable NACK
`
`
`Outer ARQOuter ARQ
`
`Segm./Conc.Segm./Conc.
`
`TSNTSN
`
`
`Outer ARQOuter ARQ
`
`Segm./Conc.Segm./Conc.
`
`TSNTSN
`
`
`
`Multiplexing UE1Multiplexing UE1
`
`
`
`HARQHARQ
`
`
`
`DL-SCHDL-SCH
`
`
`
`HARQ ACK/NACKHARQ ACK/NACK
`
`
`
`L1L1
`
`Figure 2: HARQ/ARQ feedback
`
`
`MAC-os PDUMAC-os PDU
`
`De-Multiplexing UE1De-Multiplexing UE1
`
`
`
`HARQHARQ
`
`
`
`DL-SCHDL-SCH
`
`For the operation of the HARQ it is assumed that for a new transmission a first redundancy version is
`selected and transmitted together with the associated HARQ control signaling. This HARQ control signaling
`provides the HARQ process ID, the redundancy version and the length of the transport block. Similar to
`HSDPA, a synchronous ACK/NAK feedback is expected that indicates whether the data has been
`successfully received and decoded or not.
`This HARQ feedback is used to initiate a retransmission if necessary. It is assumed that a synchronous
`HARQ retransmission is performed, i.e., the retransmission is performed after a fixed number of subframes
`according to the number of used HARQ processes.
`It is assumed that the HARQ process continues to send redundancy versions until either an ACK is received
`or the maximum number of retransmissions is reached. In most cases, the data is successfully received after
`the transmission of one or more redundancy versions. In that case, the HARQ receiver forwards the data to
`the respective MAC de-multiplexing entity. The packet delivery function re-orders received MAC-os PDUs
`based on their TSN and delivers them to higher layers. This re-sequencing is done per QoS flow and it is not
`required that the HARQ entity provides data in the right order.
`In the event of a successful transmission, no outer ARQ-related actions are required. It is proposed that the
`Outer ARQ is a purely NAK-based mechanism. Removal of successfully transmitted MAC-os PDUs from
`the transmitter windows is performed based on a sliding window mechanism and not based on explicit Outer
`ARQ acknowledgements. This saves Outer ARQ feedback messages and thereby reduces the signalling
`overhead significantly. However, the removal needs to be done after a guard period once a HARQ ACK has
`been received. This guard period is important to guard against HARQ feedback transmission errors, namely
`NAK to ACK errors (ACK to NAK errors lead to an unnecessary HARQ retransmission, but do not cause
`further harm.). The guard period needs to be chosen in the order of a few HARQ RTTs, because it takes
`some time until residual HARQ errors are detected at the HARQ receiver and until the outer ARQ NAK is
`transmitted to the Outer ARQ transmitter.
`
`3.3 Residual HARQ Errors
`Outer ARQ performs retransmissions when the HARQ process was not able to deliver the transport block
`correctly. This happens mainly due to two reasons: a HARQ NAK to ACK feedback error occurred or the
`maximum number of HARQ retransmission reached.
`
`NSN 2002 (R2-060971).doc
`
`3/5
`
`2017-10-17
`
`IPR2017-1609
`
`NSN 2002 Page 3
`
`Huawei v. NSN
`
`

`

`In the first case, the HARQ receiver will detect the NAK to ACK error when a new transport block is sent on
`a HARQ process for which it requested a HARQ retransmission before. In response to that the MAC receiver
`generates a reliable outer ARQ feedback message (see Figure 2). It signals the TSNs of all active MAC flows
`which it expects next.
`The second case is slightly different. Based on the assumption that a synchronous HARQ protocol is used
`and that the maximum number of HARQ retransmissions is known at both sender and receiver, the MAC
`receiver does not react with an Outer ARQ feedback if the maximum number of retransmissions is reached
`(signaled with the redundancy version in the HARQ-related control signaling) and the transport block is still
`not correctly received. It is assumed that the MAC sender initiates an outer retransmission without outer
`feedback1.
`The reliable Outer ARQ feedback uses the ordinary data transmission chain including HARQ to achieve the
`desired reliability as required according to section 2.
`
`3.4 Outer Retransmission
`Once the reliable feedback has been received at the MAC sender, the outer ARQ retransmission is initiated.
`It is proposed that the Outer ARQ retransmission unit is a MAC-os PDU. This allows a selective
`retransmission even if data from two MAC flows were multiplexed in the original transport block. For
`example it is possible to retransmit only those MAC-os PDUs, which were part of the failed MAC-o
`transmission that require a high reliability. If a VoIP packet and a TCP packet are multiplexed into one
`MAC-o PDU as two MAC-os PDUs, the outer retransmission may initiate the retransmission for the TCP
`data, but not for the VoIP data. Similarly, it should be possible to multiplex one or more other MAC-os
`PDUs into the new transport block if there are more radio resources available then required for the outer
`retransmission.
`Whether a re-segmentation of MAC-os PDUs, as proposed in [3], in case an outer retransmission is required,
`is for further study. Such functionality introduces complexity and overhead, but maybe appropriate in
`scenarios, where the CQI estimate was significantly off.
`
`3.5 Operation of Sending Window
`As stated above, the Outer ARQ is a purely NAK-based protocol. Therefore, there are no reliable
`acknowledgements which can be used as a trigger to remove MAC-os PDUs from the send window at the
`MAC sender. Instead, the data can be cleared once the HARQ ACK has been received and the guard period
`has expired without receiving an Outer ARQ NAK. A new entry is added to the upper edge of this window
`for each HARQ/ARQ (re-)transmission attempt. Thereby the outer ARQ guard period is re-started for each
`transmission attempt.
`If an outer retransmission request is received and the MAC-os PDU is discarded because the guard timer has
`expired already, a packet loss occurs which can not be corrected by link layer mechanisms. However, if the
`guard time is carefully chosen, this is regarded as a very rare event well below the required reliability levels.
`
`4 Text Proposal
`It is proposed that the following text replaces the preliminary text in section 6 in [1].
`
`+Start of Text proposal +++++++++++++++++++++++++++++++++++++
`
`1 The error case that the maximum number of retransmissions is reached and that a NAK to ACK error for the last redundancy version occurred is
`regarded as rare and the resulting data loss is accepted without providing further means to deal with this error case.
`
`NSN 2002 (R2-060971).doc
`
`4/5
`
`2017-10-17
`
`IPR2017-1609
`
`NSN 2002 Page 4
`
`Huawei v. NSN
`
`

`

`6 ARQ and HARQ
` E-UTRAN provides ARQ and HARQ functionalities.
` In acknowledged mode the ARQ functionality provides correction of residual HARQ errors by
`retransmissions. For the unacknowledged mode, ARQ is not used.
` MAC-os PDUs are the retransmission unit of the ARQ.
` The ARQ is a NAK-based sliding window protocol and does not require ACKs to advance the
`window.
` The HARQ functionality ensures delivery between peer entities at Layer 1. The HARQ functionality
`is controlled by Layer 2.
` The HARQ layer relies on single bit ACK/NAK feedback signals.
` Transport Blocks (MAC-o PDUs) are the retransmission unit of the HARQ.
` HARQ is a synchronous protocol.
`
`+End of Text proposal +++++++++++++++++++++++++++++++++++++
`
`5 Conclusions
`A detailed HARQ and Outer ARQ concept has been proposed and a text proposal for Section 6 has been
`provided. The main guiding principle for the overall concept and the Outer ARQ integration has been
`simplicity, since the residual HARQ error probability is small (e.g. 10-3). Only minor performance gains can
`be expected from a more complex scheme.
`It is proposed to include the text proposal in the TR [1].
`
`6 References
`[1]
`3GPP TR 25.813, Radio Interface Protocol Aspects, February 2006
`[2]
`R2-060374, MAC functions: ARQ, Samsung, RAN WG2#51
`[3]
`R2-060563, HARQ and ARQ Operation, LG Electronics, RAN WG2#51
`[4]
`R2-060970, LTE multiplexing and user plane data flow, Ericsson, RAN WG2#52
`[5]
`R2-052057, Comparison between single and two-layer ARQ for LTE, Ericsson, RAN WG2#48
`
`NSN 2002 (R2-060971).doc
`
`5/5
`
`2017-10-17
`
`IPR2017-1609
`
`NSN 2002 Page 5
`
`Huawei v. NSN
`
`