`
`
`
`
`“THIS PAGE IS BLANK IN THE ORIGINAL”
`“THIS PAGE IS BLANK IN THE ORIGINAL”
`
`
`
`
`
`

`

`3G TR 25.835 V1.0.0 (2000-09)
`
`Technical Report
`
`3rd Generation Partnership Project;
`Technical Specification Group Radio Access Network;
`Report on Hybrid ARQ Type II/III
`(Release 2000)
`
`
`
`
`
`
`
`
`
`
`The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
`
`
`
`The present document has not been subject to any approval process by the 3GPP Organisational Partners and shall not be implemented.
`This Specification is provided for future development work within 3GPP only. The Organisational Partners accept no liability for any use of this Specification.
`Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organisational Partners' Publications Offices.
`
`
`
`

`

` Release 2000
`
`
`
`
`
`
`
`
`
`3
`
`3G TR 25.835 V1.0.0 (2000-09)
`
`Keywords
`<keyword[, keyword]>
`
`3GPP
`
`Postal address
`
`
`3GPP support office address
`650 Route des Lucioles - Sophia Antipolis
`Valbonne - FRANCE
`Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
`
`Internet
`http://www.3gpp.org
`
`Copyright Notification
`
`No part may be reproduced except as authorized by written permission.
`The copyright and the foregoing restriction extend to reproduction in all media.
`
`© 2000, 3GPP Organizational Partners (ARIB, CWTS, ETSI, T1, TTA,TTC).
`All rights reserved.
`
`
`3GPP
`
`

`

`
`
` Release 2000
`
`4
`
`3G TR 25.835 V1.0.0 (2000-09)
`
`6.4.2.2
`
`6.4.2.3
`
`Contents
`Foreword............................................................................................................................................................. 6
`1
`Scope ........................................................................................................................................................ 7
`2
`References ................................................................................................................................................ 7
`3
`Definitions, symbols and abbreviations ................................................................................................... 7
`3.1
`Definitions ......................................................................................................................................................... 7
`3.2
`Symbols ............................................................................................................................................................. 7
`3.3
`Abbreviations ..................................................................................................................................................... 7
`4
`Background and Introduction ................................................................................................................... 7
`5
`Overview of Hybrid ARQ Type II/III ...................................................................................................... 8
`5.1
`General Mechanism ........................................................................................................................................... 8
`5.2
`Termination of Retransmission .......................................................................................................................... 9
`6
`Layer 2 and Layer 3 Operation with Hybrid ARQ Type II/III Retransmission at RLC ........................... 9
`6.1
`Protocol Architecture ......................................................................................................................................... 9
`6.2
`Usage of logical channels and transport channels............................................................................................ 11
`6.2.1
`Usage of logical channels and transport channels with Case A ................................................................. 11
`6.2.2
`Usage of logical channels and transport channels with Case B .................................................................. 12
`6.3
`Usage of transport channels and physical channels ......................................................................................... 12
`6.3.1
`Usage of transport channels and physical channels with Case A ............................................................... 12
`6.3.2
`Usage of transport channels and physical channels with Case B ............................................................... 12
`6.4
`Examples of Interlayer Procedures .................................................................................................................. 13
`6.4.1
`Examples of Interlayer Procedures for Case A .......................................................................................... 13
`6.4.1.1
`Data Transfer on Uplink ....................................................................................................................... 13
`6.4.1.2
`Data Transfer on Downlink .................................................................................................................. 14
`Data Transfer on Downlink with DCH+DSCH .................................................................................... 15
`6.4.1.3
`6.4.2
`Examples of Interlayer Procedures for Case B ........................................................................................... 16
`6.4.2.1
`HARQ user data and side information are transmitted to receiver using one physical channel,
`DPCH ................................................................................................................................................... 17
`HARQ user data and side information are transmitted to receiver using one physical channel,
`PDSCH ................................................................................................................................................. 17
`HARQ user data and side information are separately transmitted to receiver using two physical
`channels, DPCH and PDSCH ............................................................................................................... 18
` Services provided by the Physical Layer ........................................................................................................ 23
` Functions of Layer 1 ................................................................................................................................. 23
` Interface to Layer 1 ................................................................................................................................... 23
`Interface to Layer 1 for Case A ............................................................................................................ 23
`Interface to Layer 1 for Case B............................................................................................................. 24
`MAC Protocol .................................................................................................................................................. 24
`MAC Protocol for Case A .......................................................................................................................... 24
`MAC Protocol for Case B ......................................................................................................................... 24
` RLC Protocol .................................................................................................................................................. 24
`RLC Protocol for Case A ........................................................................................................................... 24
`RLC Protocol for Case B ........................................................................................................................... 24
` RRC Protocol .................................................................................................................................................. 25
`RRC Protocol for Case A ........................................................................................................................... 25
`RRC Protocol for Case B ........................................................................................................................... 25
`Layer 2 and Layer 3 Operation with Hybrid ARQ Type II/III Retransmission at Layer 1 (Fast
`Hybrid ARQ) .......................................................................................................................................... 25
`Protocol architecture ........................................................................................................................................ 26
`Usage of transport channels and physical channels ......................................................................................... 27
`Services provided by the physical layer ........................................................................................................... 27
`Functions of Layer 1 .................................................................................................................................. 27
`Interface to Layer 1 .................................................................................................................................... 27
`MAC protocol .................................................................................................................................................. 28
`
`6.5
`6.5.1
`6.5.2
`6.5.2.1
`6.5.2.2
`6.6
`6.6.1
`6.6.2
`6.7
`6.7.1
`6.7.2
`6.8
`6.8.1
`6.8.2
`7
`
`7.1
`7.2
`7.3
`7.3.1
`7.3.2
`7.4
`
`3GPP
`
`

`

` Release 2000
`
`5
`3G TR 25.835 V1.0.0 (2000-09)
`7.5
`RLC protocol ................................................................................................................................................... 28
`7.6
`RRC protocol ................................................................................................................................................... 28
`8
`Physical Layer impacts ........................................................................................................................... 28
`8.1
`Overview of physical layer mechanisms ......................................................................................................... 28
`8.2
`Performance evaluation ................................................................................................................................... 28
`8.3
`Impacts to UE and Node B complexity .......................................................................................................... 28
`9
`Impacts on UTRAN Interfaces ............................................................................................................... 29
`9.1
`Impacts on Iub ................................................................................................................................................. 29
`9.2
`Impacts on Iur .................................................................................................................................................. 29
`10
`Specification Impacts ............................................................................................................................. 29
`History .............................................................................................................................................................. 29
`
`
`
`3GPP
`
`

`

`
`
` Release 2000
`
`6
`
`3G TR 25.835 V1.0.0 (2000-09)
`
`Foreword
`This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
`
`The contents of the present document are subject to continuing work within the TSG and may change following formal
`TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
`identifying change of release date and an increase in version number as follows:
`
`Version x.y.z
`
`where:
`
`x
`
`the first digit:
`
`1 presented to TSG for information;
`
`2 presented to TSG for approval;
`
`3 or greater indicates TSG approved document under change control.
`
`y
`
`the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
`updates, etc.
`
`z
`
`the third digit is incremented when editorial only changes have been incorporated in the document.
`
`3GPP
`
`

`

`
`
` Release 2000
`
`7
`
`3G TR 25.835 V1.0.0 (2000-09)
`
`Scope
`1
`This technical report captures the results of the work on the work item “Hybrid ARQ Type II/III”. This includes
`technical solutions and their comparison. The report covers impacts on all RAN WGs.
`
`References
`2
`The following documents contain provisions which, through reference in this text, constitute provisions of the present
`document.
`
`• References are either specific (identified by date of publication, edition number, version number, etc.) or
`non-specific.
`
`• For a specific reference, subsequent revisions do not apply.
`
`• For a non-specific reference, the latest version applies.
`
`[<seq>]
`
`<doctype> <#>[ ([up to and including]{yyyy[-mm]|V<a[.b[.c]]>}[onwards])]: "<Title>".
`
`[1]
`
`[2]
`
`3G TS 25.123: "Example 1, using sequence field".
`
`3G TR 29.456 (V3.1.0): "Example 2, using fixed text".
`
`3
`
`Definitions, symbols and abbreviations
`
`Definitions
`3.1
`For the purposes of the present document, the [following] terms and definitions [given in ... and the following] apply.
`
`Definition format
`
`<defined term>: <definition>.
`
`example: text used to clarify abstract rules by applying them literally.
`
`Symbols
`3.2
`For the purposes of the present document, the following symbols apply:
`
`Symbol format
`
`<Explanation>
`
`<symbol>
`
`Abbreviations
`3.3
`For the purposes of the present document, the following abbreviations apply:
`
`Abbreviation format
`
`<ACRONYM> <Explanation>
`
`Background and Introduction
`
`4
`
`
`3GPP
`
`

`

`
` Release 2000
`8
`5
`Overview of Hybrid ARQ Type II/III
`
`
`3G TR 25.835 V1.0.0 (2000-09)
`
`General Mechanism
`5.1
`There are different variants of hybrid ARQ methods. The terms hybrid ARQ type I, type II, and type III are used
`according to the following definition:
`
`Type I hybrid ARQ
`
`The ARQ method used in current 3GPP specifications is referred to as HARQ type I. In this basic HARQ type I
`the CRC is added and the data is encoded with a forward error correction (FEC) code. In the receiver the FEC
`code is decoded and the quality of the packet is checked (CRC check). If there are errors in the packet, a
`retransmission of the packet (RLC-PDU) is requested. The erroneous packet is discarded and retransmissions use
`the same coding as the first transmission.
`
`
`Type II hybrid ARQ
`
`The type II HARQ is a so-called Incremental Redundancy ARQ scheme. This means that an RLC-PDU that is to
`be retransmitted is not discarded but is combined with some incremental redundancy information provided by
`the transmitter for subsequent decoding.
`For type II HARQ the retransmissions are typically not identical with the original transmission. The
`retransmitted part carries additional redundancy information for error correction purposes. This additional
`redundancy is combined with the previously received packet and the resulting code word with a higher coding
`gain is decoded. In hybrid ARQ type II, the retransmitted amount of redundancy is different for each
`retransmission, and retransmissions can in general only be decoded after combination with previous
`transmissions.
`Type II hybrid ARQ requires that when RLC-PDU are transferred their sequence numbers are signalled with a
`better error protection than the data part of the RLC-PDU. This is because several versions of the RLC-PDU may
`need to be combined in the physical layer before it can be decoded and any identifier contained within the RLC-
`PDU detected.
`
`Type III hybrid ARQ
`
` Like type II hybrid ARQ, type III hybrid ARQ also belongs to the incremental redundancy ARQ schemes. This
`means that retransmissions concerning one RLC-PDU are not discarded but kept at the receiver for combination
`with additional information before decoding.
`With type II hybrid ARQ, retransmissions containing additional incremental code bits sent for a RLC-PDU,
`which was initially received with errors, are in general not self decodable. In situations where the transmitted
`RLC-PDU can be severely damaged, for example, due to interference, it is desirable to have a scheme where any
`additional information sent is self decodable. In type III HARQ each retransmission is self-decodable. Thus, the
`data can be recovered from the retransmitted packet without combining if it is transmitted with sufficient quality.
`
`Type III places similar requirements on the signalling protocol for external RLC-PDU identification and on the
`physical layer as type II hybrid ARQ.
`
`Two subcases of hybrid ARQ type III can be distinguished:
`
`- with multiple redundancy versions
`Different versions of a RLC-PDU are created. Different puncture bits are used in each version. If
`transmission of the first fails then the second version is sent. Transmission of further versions or repeat
`transmissions of the already transmitted versions may be made and combined.
`
`- with one redundancy version
`In this subcase of HARQ type III, the same FEC coding is used for each retransmission, similar to the
`operation of HARQ type I. However, the erroneous packets are stored in the receiver and combined with
`retransmissions of the packet. This is a kind of incremental redundancy coding scheme in the form of a
`repetition code.
`
`3GPP
`
`

`

`
` Release 2000
`9
`5.2
`Termination of Retransmission
`Two alternative approaches to realize hybrid ARQ are presented in this document for consideration.
`
`3G TR 25.835 V1.0.0 (2000-09)
`
`The first option uses hybrid ARQ type II/III retransmissions at RLC layer. This option 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/III functionality as an add-on to the current protocol. This first option is
`described in chapter 6.
`
`The second option uses hybrid ARQ type II/III retransmissions at Layer 1. It adds fast hybrid ARQ type II/III
`functionality to Node B. With this approach the release '99 RLC is not affected. This second option is described in
`chapter 7.
`
`Layer 2 and Layer 3 Operation with Hybrid ARQ
`Type II/III Retransmission at RLC
`
` 6
`
`
`
`
`
`Protocol Architecture
`6.1
`This section gives a general overview of function split for HARQ type II/III in the UE, the Node B, the Controlling or
`Drift RNC, and the Serving RNC in the UL and DL direction.
`
`The following major functions are shown in table 1 and table 2:
`
`• TX buffering: The buffering of data which should be (re)transmitted at the transmitting side.
`
`• Parameter setting for Redundancy Version selection: It is selected with which redundancy version a certain
`(re-)transmission of a PDU is done.
`
`• RX soft decision buffering for combining: Buffering of the received initial and retransmitted data for the
`combining at the receiver side.
`
`• RX buffering for RLC-SDU reassembly: Buffering of the RLC-PDUs to reassemble them to RLC-SDUs.
`
`• Combining of retransmissions: Combining of the initially transmitted and retransmitted data for error correction.
`
`
`
`3GPP
`
`

`

` Release 2000
`
`
`TX buffering
`Parameter setting for
`Redundancy Version
`selection
`RX soft decision buffering
`for combining
`RX buffering for
`RLC-SDU reassembly
`Combining of
`retransmissions
`Table 1: Function split for hybrid ARQ type II/III in the UE, NodeB, CRNC/DRNC, and SRNC in UL
`direction
`Node B
`
`10
`Node B
`
`UE
`
`RLC
`RLC
`
`-
`-
`
`-
`
`-
`
`-
`
`-
`-
`
`Layer 1
`
`-
`
`Layer 1
`
`UE
`
`-
`-
`
`CRNC / DRNC
`
`3G TR 25.835 V1.0.0 (2000-09)
`SRNC
`
`-
`-
`
`-
`
`RLC
`
`-
`
`CRNC / DRNC
`
`SRNC
`
`RLC
`RLC
`
`-
`-
`
`-
`
`-
`
`-
`
`-
`-
`
`
`TX buffering
`Parameter setting for
`Redundancy Version
`selection
`RX soft decision buffering
`for combining
`RX buffering for
`RLC-SDU reassembly
`Combining of
`retransmissions
`
`
`Layer 1
`
`RLC
`
`Layer 1
`
`-
`
`-
`
`-
`
`-
`
`-
`
`-
`
`-
`
`-
`
`-
`
`Table 2: Function split for hybrid ARQ type II/III in the UE, NodeB, CRNC/DRNC, and SRNC in DL
`direction
`To perform the HARQ type II / III operation the physical layer requires additional side information, e.g. sequence
`number, redundancy version, and logical channel identification. The setting of these parameters should be under
`control of RLC. A coordinated data flow of user data and side information from RLC to MAC and L1 is required (see
`figure 1). 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
`
`

`

`
`
` Release 2000
`
`11
`
`3G TR 25.835 V1.0.0 (2000-09)
`
`U-plane
`data
`
`UE
`
`RLC
`
`UTRAN
`
`RLC
`
`U-plane
`data
`
`MAC-c/sh
`
`MAC-d
`
`RLC PDUs
`
`Iur (optional)
`
`MAC-d
`
`MAC-c/sh
`
`MAC PDUs (Transport Blocks) with TFI
`(via Iub interface)
`
`L1 (in UE)
`
`L1 (in Node B)
`
`Physical channel carrying data and HARQ type II/III
`side information
`
`
`
`Figure 1 Protocol stack overview for hybrid ARQ type II/III.
`
`Dotted lines visualise the transport of necessary side information for hybrid ARQ type II/III operation between RLC
`and the Physical Layer. Solid lines show the transport of user data.
`
`
`
`Two different models for handling the additional requirements for hybrid ARQ type II/III in Layer 2 and Layer 3 have
`been proposed and are described in this report.
`
`Case A: One logical channel is used for the transfer of user data and side information between RLC and MAC, and
`one transport channel is used for the transfer of user data and side information between MAC and physical layer.
`
`Case B: Two separate logical channels are used for the transfer of user data and side information between RLC and
`MAC, and two separate transport channels are used for the transfer of user data and side information between
`MAC and physical layer.
`
`6.2
`
`Usage of logical channels and transport channels
`
`Usage of logical channels and transport channels with Case A
`6.2.1
`The necessary side information for hybrid ARQ type II/III operation is included in the same logical channel as the RLC
`PDU data. This logical channel can be mapped to the following transport channels:
`
`a) DTCH can be mapped onto the DCH.
`
`b) DTCH can be mapped onto the DSCH
`
`c) DTCH can be mapped onto the DSCH, but with transmission of side information over DPCH
`
`d) DTCH can be mapped onto the USCH
`
`3GPP
`
`

`

` Release 2000
`12
`3G TR 25.835 V1.0.0 (2000-09)
`
`As already possible in release 99, a second logical channel can be used for RLC control PDUs. The use of this second
`logical channel is independent from the hybrid ARQ type II/III operation.
`
`Usage of logical channels and transport channels with Case B
`6.2.2
`The hybrid ARQ user data and side information can be produced onto two PDUs, respectively. User data and side
`information can be transmitted to MAC-d as following cases:
`
`a) DTCH can be mapped onto the DCH.
`
`b) DTCH can be mapped onto the DSCH
`
`c) DTCH can be mapped onto the DCH and DSCH
`
`The HARQ user data and side information are produced as each RLC PDU and are mapped onto two signals. Since
`RLC and MAC-d are located in a RNC, the co-ordination between both signals is a kind of implement issue(for
`example, using an indicator between HARQ user data and side information).
`
`
`
`6.3
`
`Usage of transport channels and physical channels
`
`6.3.1 Usage of transport channels and physical channels with Case A
`The hybrid ARQ user data and side information can be transmitted on the dedicated or shared channels. Following cases
`can be considered.
`
`a) DCH can be mapped onto the DPCH
`
`b) DSCH can be mapped onto the PDSCH
`
`c) DSCH can be mapped onto the PDSCH + DPCH
`
`d) USCH can be mapped onto the PUSCH
`
`ad a) , b), and d) The HARQ user data and side information is mapped onto the same Physical Channel. Since one
`physical channel is always generated by a common processing chain in Layer 1, no special co-ordination of the user
`data and the side information at the physical layer is needed, as long as the MAC and RLC layer ensure a synchronised
`delivery of user data and side information to the Layer 1.
`
`ad c) The hybrid ARQ type II/III user data can be mapped on a different physical channels than the side information.
`This scenario is especially interesting for the transmission of the user data over the downlink shared channel, while the
`side information is transmitted over a more reliable dedicated channel. The use of two independent physical channels
`requires special attention for the co-ordination of the transmissions on both channels, because the data flow through
`MAC and Layer 1 may be different. This is the case for the simultaneous use of DCH and DSCH, which may be
`influenced by variable and unknown delays, e.g. transmission over the Iur interface and scheduling in MAC-c/sh of the
`controlling RNC.
`
`6.3.2 Usage of transport channels and physical channels with Case B
`The hybrid ARQ user data and side information can be transmitted on the dedicated or shared channels. Following cases
`can be considered.
`
`a) DCH can be mapped onto the DPCH
`
`b) DSCH can be mapped onto the PDSCH
`
`c) DCH and DSCH can be mapped onto the DPCH and PDSCH, respectively
`
`ad a) and b) The HARQ user data and side information are mapped onto the same Physical Channel(s). Since one
`physical channel is always generated by a common processing chain in Layer 1, no special co-ordination of the user
`
`3GPP
`
`

`

` Release 2000
`13
`3G TR 25.835 V1.0.0 (2000-09)
`
`data and the side information at the physical layer is needed, as long as the MAC ensures a synchronised delivery of
`one(or two) signal(s) to the Layer 1.
`
`ad c) The HARQ user data and side information can be separated at MAC and be mapped onto two different transport
`channels(i.e. DSCH and DCH). When there are both MAC-d and MAC-c/sh in one RNC, the synchronisation between
`DSCH and DCH can be done according to the scheduling result of MAC-c/sh. Each transport channel can be mapped
`onto the related physical channel (i.e. DSCH onto PDSCH, DCH onto DPCH).
`
`
`
`6.4
`
`Examples of Interlayer Procedures
`
`
`
`6.4.1 Examples of Interlayer Procedures for Case A
`
`Data Transfer on Uplink
`6.4.1.1
`Following Figure is a modification of “Data Transfer on USCH” as specified in [2]. Additional detail of the data
`transfer in the user plane is shown . The shaded area of the Figure corresponds to a single uplink transmission
`
`MAC-Data-REQ  USCH:Data  MAC-Data-IND
`
`and is equally valid for usage on other transport channels, e.g. DCH.
`
`If the transmission on the Uu interface is corrupted, the physical layer on the receiving side needs to retrieve the Hybrid
`ARQ parameter list of the corrupted data in order to perform Type II operation. Therefore, it is needed that the
`parameter values be stronger encoded on the physical layer than the associated data. Subsequent retransmissions send
`incremental redundancy to the already transferred data. Which redundancy version of the data is sent is indicated
`through the redundancy version parameter (“Red.Vers.”) which is signalled together with all the transmissions. Each
`time an incremental redundancy version of the data is received, the physical layer attempts to decode the concatenated
`versions of all previous transmissions.
`
`
`3GPP
`
`

`

`
`
` Release 2000
`
`14
`
`3G TR 25.835 V1.0.0 (2000-09)
`
`
`
`Figure 2 Example procedure for uplink data transfer using hybrid ARQ type II/III on USCH.
`
`The relevant part in the shaded area is equally valid for usage on other transport channel, e.g. DCH.
`
`
`
`Data Transfer on Downlink
`6.4.1.2
`The following figure is a modification of the “Data Transfer on DSCH” as specified in [2]. Additional detail of the data
`transfer in the user plane is shown. The shaded area of the figure corresponds to a single downlink transmission
`
`MAC-Data-IND  DSCH:Data  MAC-Data-REQ
`
`and is equally valid for usage on other transport channel, e.g. DCH.
`
`In case of corrupted transmission on the Uu interface, the same procedure which was already described for the uplink
`case (in section 6.3.1) applies.
`
`
`
`3GPP
`
`

`

`
`
` Release 2000
`
`15
`
`3G TR 25.835 V1.0.0 (2000-09)
`
`
`
`Figure 3 Example procedure for downlink data transfer using hybrid ARQ type II/III on DSCH in TDD
`mode.
`
`The relevant part in the shaded area is equally valid for usage on other
`transport channel, e.g. DCH.
`
`Data Transfer on Downlink with DCH+DSCH
`6.4.1.3
`Several ways for operating hybrid ARQ type II/III with user data transmission over a downlink shared channel while
`transmitting the side information necessary for combining at the receiver (e.g. sequence number, redundancy version)
`over a more reliable dedicated physical channel are possible.
`
`It is important to assure that the user data and the corresponding side information are transmitted synchronously over
`both channels to allow correct decoding at the receiver. Due to the different handling of dedicated and shared channels
`in the MAC layer, this synchronisation is difficult to achieve by using different logical channels.
`
`Also, additional problems arise if the controlling RNC is not equal to the serving RNC, because the Iur interface with
`high transmission delays has to be involved. In the case of an involved Iur interface, it is suggested not to split data and
`side information on different channels.
`
`A similar synchronisation problem on downlink shared channels and dedicated physical channels was already solved in
`release 99 for the TFCI transmission using logical split of TFCI-word for the transport format on the DSCH. With small
`extensions, this mechanism could also be used to support the hybrid ARQ type II/III case.
`
`The following text and figure have been copied from 25.303V3.4.0. In the figure, three legends have been added to
`mark the important details which can be used to transfer side information for hybrid ARQ type II/III on the dedicated
`physical channel.
`
`3GPP
`
`

`

`DTCH (/ DCCH): MAC-C/SH-Data-REQ
`[Data, HARQ ty pe
`II/II side inf ormation]
`
`Schedule DSCH
`transmission,
`TFI2 def ines TF f or
`DSCH
`
`DSCH: MPHY-Data-REQ
`[Data]
`
`[TFCI(f ield2), , HARQ ty pe
`II/III side inf ormation]
`
`DCH: MPHY-Data-REQ
`[TFI2, HARQ ty pe II/III side
`inf romation]
`
`DCH: MPHY-Data-REQ
`[Data2, TFI1]
`
`Information is passed
`back from MAC-c/sh
`to MAC-d after
`DSCH scheduling.
`
`DSCH related
`information is passed
`to Node B in DCH
`frame protocol for
`synchronized
`transmission.
`
` Release 2000
`16
`3G TR 25.835 V1.0.0 (2000-09)
`
`In the figure, the parameter “HARQ type II/III side information” has been added to the existing procedure at the
`appropriate places to show how a transmission of hybrid ARQ type II/III encoded data using this mechanism could
`work.
`
`UE-RLC
`
`UE-MAC-D
`
`UE-MAC-C/SH
`
`UE-L1
`
`Node B-L1
`
`RNC-MAC-C/SH
`
`RNC-MAC-D
`
`RNC-RLC
`
`Uu
`
`Iub
`
`DTCH (/ DCCH): MAC-D-Data-REQ
`[Data, HARQ ty pe
`II/II side inf ormation]
`
`Synchronized
`transmission of data
`on PDSCH and
`HARQ type II/II side
`infromation on
`DPCH.
`
`(PDSCH)
`[Data]
`(DPCH)
`[Data2, TFCI,
`HARQ ty pe II/III
`side inf romation]
`
`DSCH: MPHY-Data-IND
`[Data, TFI2, HARQ ty pe
`II/II side inf ormation]
`
`MAC-C/SH-Data-IND
`[Data, HARQ ty pe II/II
`side inf ormation]
`
`DTCH (/ DCCH): DCH: Data ACK
`
`MAC-D-Data-IND
`[Data], HARQ ty pe II/II
`side inf ormation
`
`
`
`Figure 4 Data flow for Acknowledged-mode data transmission on DSCH using logical split of TFCI-
`word and split transmission of hybrid ARQ type II/III data and side information.
`
`6.4.2 Examples of Interlayer Procedures for Case B
`Following some flowcharts about the HARQ type II/III scheme for case B scheme
`
`The basic scheme is as follows:
`
`- When RLC receives the data, RLC processes the data based on release 99 specification and produces a new PDU
`including the side information about data PDU, i.e. RLC PDU sequence number, RLC PDU version based on
`previous signalling.
`- Both data PDU and a new PDU including side information, which are produced in RLC, are transmitted to MAC-d.
`- DTCH(s) including the side information and data PDU is(are) mapped to DCH transport channel through MAC-d
`or(and) DSCH transport channel through MAC-d and MAC-c/sh.
`- Data PDU and side information are transmitted to a receiver through DPCH or(and) PDSCH.
`In this document, each scheme in following cases is explained, when CRNC and SRNC are existed in a system.
`
`Case 1) HARQ user data and side information are transmitted to receiver using one physical channel, DPCH.
`
`Case