TSG-RAN Working Group 2 (Radio L2 and Radio L3)
`Sophia Antipolis, France, 21th to 25st August 2000
`
`R2-001762
`
`Agenda item: 7.1
`Source:
` Nokia
`
`Title:
`
`Fast Hybrid ARQ description
`Document for: Approval
`
`The HARQ mechanisms presented for inclusion to the technical report on HARQ in RAN WG2 before meeting #15 assume
`termination of the retransmission protocol at the serving RNC. According to simulation results provided by Nokia (R2-
`001419), the block error rate of the first transmission has to be rather high (> 50%) before significant capacity increase is
`experienced. The influences of the increased error rate and roundtrip delay can be experienced in total acknowledged-mode
`transmission delay, UE buffering requirements and Iub interface load.
`
`Due to these concerns it is felt that a mechanism, which allows to terminate the HARQ in Node B, is necessary to be
`included in the comparison of different methods.
`
`This contribution incorporates a proposal for inclusion of a "Fast Hybrid ARQ" mechanism into the technical report. To
`stay consistent with the protocol termination model of release '99, the mechanism is proposed to be incorporated into the
`Node B terminated part of the physical layer. No changes for higher user plane air interface protocol layers are necessary.
`
`Page 1 of 4
`
`

`

`2
`
`Overview of Hybrid ARQ Type II/III
`5
`Two alternative approaches to realize hybrid ARQ are presented in this document for consideration.
`
`Option 1 is based on the present termination of retransmission protocols, i.e. utilizing the retransmission mechanism
`defined in release '99 with the current termination points and adding Type II functionality as an add-on to the current
`protocol. Option one is described in chapter 6.
`
`Option 2 is to add fast hybrid ARQ functionality to Node B. With this approach the release '99 RLC and MAC are not
`affected. Option 2 is described in chapter 7.
`
`6
`
`Option 1: Hybrid ARQ Type II/III in UTRAN Layer 2
`and Layer 3
`
`Option 2: Fast Hybrid ARQ
`7
`The fast HARQ operates with an n-channel stop-and-wait protocol. Dual channel, which can be considered the default
`operation mode, is illustrated in Figure 1. A continuous transmission flow is separated in time into two subchannels,
`both of which independently execute a stop-and-wait retransmission protocol. The dual-channel structure guarantees
`continuous transmission, i.e. the protocol doesn't get stalled waiting for acknowledgements, as long as the roundtrip
`delay for the acknowledgements is short enough so that the response is always available when the slot for the same
`subchannel occurs again.
`
`Using a dual-channel approach brings benefits in receiver buffering requirements and decreases error probability in
`combining retransmissions with earlier received blocks:
`
`-
`
`-
`
`Only the amount of data corresponding to two TTI:s needs to be buffered in the receiver: One for each
`subchannel. If the transmission is not succesful the retransmission takes place in the next TTI for the respective
`subchannel.
`
`For the received data there is only two possibilities: It is either a new transmission or a retransmission of the
`previously transmitted block. Consequently, the soft combining of data can be done reliably.
`
`1
`
`2
`
`3
`
`2
`
`4
`
`ACK
`
`NAK
`
`ACK
`
`ACK
`
`Figure 1 Dual channel stop-and-wait protocol principle.
`
`To perform the fast HARQ operation the physical layer requires some additional side information, e.g. FHARQ
`sequence number, and redundancy version. The selection of these parameters should be under the control of MAC but
`the actual parameter values are generated at L1. The physical layer can encode the data and the side information
`separately, and map them on one, or possibly even different physical channels. At the receiver the buffering and
`recombining of the data is performed.
`
`3GPP
`
`Page 2 of 4
`
`

`

`3
`
`7.1 Protocol architecture
`This section gives a general overview of function split for fast HARQ in the UE, the Node B, the Controlling or Drift
`RNC, and the Serving RNC in the DL direction. Fast HARQ is employed in DSCH only.
`
`Table 1 shows which functions should be fulfilled in the DL direction in the entities.
`
`UE
`
`-
`
`TX buffering of RLC-
`PDUs for AMD service
`
`TX buffering for fast
`HARQ
`
`Redundancy selection
`and Parameter setting
`
`-
`
`RX soft decision
`buffering for combining
`
`Layer 1
`
`RX buffering for
`RLC-SDU reassembly
`
`RLC
`
`Combining of
`retransmissions
`
`Layer 1
`
`Node B
`
`CRNC / DRNC
`
`SRNC
`
`Layer 1
`
`Layer 1
`
`-
`
`-
`
`-
`
`-
`
`-
`
`-
`
`-
`
`RLC
`
`-
`
`-
`
`-
`
`Table 1: Functional split for fast hybrid ARQ type II/III in the UE, NodeB, CRNC/DRNC, and SRNC in
`DL direction
`Dotted lines in Figure 2 visualise the transport of necessary side information for fast hybrid ARQ operation. Solid lines
`show the transport of user data that is to utilize fast hybrid ARQ.
`
`U-plane
`data
`
`UE
`
`RLC
`
`UTRAN
`
`U-plane
`data
`
`RLC
`
`RLC PDUs
`
`MAC-c/sh
`
`MAC-d
`
`MAC-d
`
`MAC-c/sh
`
`MAC PDUs (Transport Blocks) with TFI
`
`L1 (in UE)
`
`L1 (in Node B)
`
`Physical channel carrying data and fast HARQ side information
`
`Figure 2 Protocol stack overview for fast hybrid ARQ type II/III.
`
`3GPP
`
`Page 3 of 4
`
`

`

`
`
`4
`
`7.2 Usage of transport channels and physical channels
`If fast HARQ is operated as a dual-channel model, the side information must be available very quickly since the
`retransmission interval is only one frame. The receiver reads the sequence number and redundancy version after which
`the packet is decoded. The integrity of the packet is checked and an acknowledgement is sent in the current uplink
`frame. Fast HARQ is planned to be employed on DSCH. Side information and sequence number are added by Layer 1
`to facilitate fast decoding at the receiver end.
`
`The fast HARQ feedback information is transmitted once for every TTI. This feedback information can be e.g. inserted
`into uplink DPDCH frame by reserving a few slots in advance or use some of the dedicated physical control channel
`(DPCCH) bits in the given slots.
`
`7.3 Services provided by the physical layer
`
`7.3.1 Functions of Layer 1
`The main functions of the physical layer are listed in [1]. The following additional functions have to be performed for
`fast HARQ operation:
`-
`-
`
`redundancy selection, TX buffering, retransmission control, RX soft decision buffering and combining for data
`
`encoding/decoding, transmission, and error detection on fast HARQ side information (including fast
`acknowledgements)
`
`-
`
`generation of Acknowledgement PDU & Side Information
`
`7.3.2 Interface to Layer 1
`According to the functional split, major parts of the functionality for fast HARQ have to be performed in the physical
`layer. Some fast HARQ parameters are passed from higher layers, the required changes are FFS.
`
`7.4 MAC protocol
`For the basic functionality presented in this document no changes are anticipated to the MAC protocols.
`
`7.5 RLC protocol
`No changes to RLC protocols have been identified. As with release '99, RLC can operate in transparent mode, UM or
`AM independent of whether the fast HARQ is being used.
`
`7.6 RRC protocol
`Some additional parameters for the configuration of fast HARQ will be required.
`
`Physical Layer impacts
`
` 8
`
`
`
`
`
`3GPP
`
`Page 4 of 4
`
`