TSGR1#19(01)0312
`
`TSG-RAN Working Group 1 #19
`Las Vegas, USA
`February 26-March 2
`
`Agenda item:
`Source:
`Title:
`Document for:
`
`AH24, HSDPA
`Lucent Technologies
`Downlink Model for HSDPA
`Discussion
`
`Introduction
`1
`In this paper, clarifications to comments and questions on Lucent’s Downlink model proposal for HSDPA in TSG-RAN
`WG1#17, TSG-RAN WG1#18, and TSG-RAN WG2#18 are provided.
`2
`Downlink Transport Channel Multiplexing Structure
`In [1], a new multiplex structure is proposed. Figure 1 shows the proposed structure with two HS-DSCH transport
`channels input from the MAC layer. The MAC HS-DSCH is a new entity proposed in [2] to support HSDPA and is
`terminated in Node B.
`
`HS-DSCH
`
`HS-DSCH
`
`MAC HS-DSCH
`
`HARQ and Scheduling
`Info Signalling
`
`Hybrid
`ARQ
`Control
`
`TrB Concatenation/
`Code Block
`Segmentation
`
`CRC
`
`Code Blocks
`
`Channel Coding
`
`Rate Matching
`
`Interleaving
`
`TrCH Multiplexing
`
`Physical Channel
`Mapping
`
`
`
`#PhCH w
`
`Figure 1: Proposed HSDPA Multiplex Structure [1]
`
`1
`
`APPLE 1011
`
`

`

`2.1 Code Block or Transport Block Set
`Transport Block Set is the entity exchanged between MAC and the Physical layer via the DSCH transport channel, every
`TTI. As shown in Figure 1, the transport blocks are concatenated and a CRC is appended to the concatenated transport
`blocks. This concatenated transport blocks with its CRC is termed Code Block. Similarly, the Transport Block Set sizes
`are referred to as Code Block Sizes as used [4].
`
`Predefined Code Block sizes of values {640bits, 1280bits, 2560bits, 5120bits} assuming Transport Block size of 320bits
`are proposed in [5]. Support of Code Block sizes based on other Transport Block sizes as proposed for R99 is not
`precluded in this proposal.
`
`As in R99, the Code Blocks sizes as defined above can change from one transmission time interval (TTI) to the next.
`
`2.2 Single CRC Per Code Block
`A single ACK/NACK bit per Code Block is proposed. Due to the smaller radio frame sizes as stated above, the overhead
`of using a CRC per transport block would be very high. To reduce the overhead, a single CRC is used for the
`concatenated transport blocks or the code block. This also allows for using a single bit to feedback the ACK/NACK
`back to the Node B.
`
`2.3 Multiple TTI Values
`The transmission time interval is defined as the inter-arrival time of Transport Block Sets and the MAC delivers one
`Transport Block Set to the Physical layer every TTI. Thus, the TTI is also the time interval for which the HSDPA radio
`resource is allocated to a UE.
`
`In R99, the TTI is a multiple of the radio frame of 10ms, taking on values of {10ms, 20ms, 40ms, and 80ms}. A minimum
`TTI of 1 slot (0.667ms) was proposed in [3] and [4]. In [5], TTI values of {1, 2, 4, 8, 16} slots are proposed. In addition, the
`benefits of using variable TTI are discussed in [6].
`
`Because the TTI is also the interval for the radio resources that are allocated to an UE, minimum TTI of 1 slot also
`corresponds to radio sub-frame of 1 slot.
`
`2.4 Variable TTI
`In R99, the TTI can be changed in the Transport Format and is an attribute in the semi-static part of the Transport
`Format. However, this TTI variation is controlled through control signalling from the RRC and it varies at a slow rate.
`
`Multiple TTI values are proposed in [5], and explained in the previous section. In addition, it has been proposed that the
`TTI be varied during a connection based on the user’s channel condition and data backlog [5]. This variation of the TTI
`is controlled and signalled from the MAC HSDPA which is proposed to be resident in Node B [2] to ensure very fast
`channel response and adaptation.
`2.5 Rate Matching
`In R99, the rate matching function (dynamic rate matching per CCTrCH) is primary to balance the resource between the
`different transport channels by matching the bit rate of the transport channel to one of the limited set of bit rates of the
`downlink (or uplink) physical channels. In addition, more than one transport channel can be multiplexed within a single
`radio frame of 10ms.
`
`A simplification to perform the rate matching per transport channel is proposed in [3]. Minimum TTI of 1 slot or radio
`sub-frame of 1 slot ensures high frame-fill efficiency compared to radio frames with frame duration that is of multiple
`10ms. The small radio sub-frame of single slot avoids the need to multiplex multiple transport channels into a single radio
`frame. Hence, rate matching on a single transport channel is proposed. The rate matching proposed would be part of the
`HARQ function with control entity that resides in the proposed MAC HSDPA.
`
`2
`
`

`

`2.6 Transport Channel Multiplexing
`As explained in the previous section, the proposed radio sub-frame of 1 slot allows for rate matching operation over a
`single transport channel. As a result, the second intra-frame interleaver that performs 10ms radio frame interleaving will
`not be needed and thus is not proposed in the downlink model.
`
`Data stream from other transport channels would be sent serially and the QoS of each of transport channels is provision
`through smart scheduling and the rate matching function.
`
`2.7 One or Multiple HS-DSCH Transport Channels
`In TS 25.321, more than one HS-DSCH transport channels are defined. If only a single HS-DSCH transport channel is
`used, the Coded Composite Transport Channel (CCTrCh) would then be unnecessary for thus will not be supported for
`HSDPA.
`
`Flexibility in scheduling leading to better source adaptation could be achieved when more than one HS-DSCH transport
`channel is used. These are due to the small packets sent during connection set up and tear down of the TCP link and
`HTTP traffic. These packets may only require a small portion of the full 10ms frame to transmit, resulting in high frame
`overhead. To alleviate this problem, more than one HS-DSCH can be used with one or multiple users on the different HS-
`DSCH transport channels, adding flexibility into the system and thus improving the frame fill efficiency. With multiple
`HS-DSCH transport channels, the CCTrCH frame is thus a composite of all the transport channels for one UE or for
`different UEs.
`
`The alternative solution would be by providing flexibility through the use of smaller radio frame, such as the proposed
`sub-frame of 1 slot. Efficient frame filling is possible because of the smaller frame sizes and the smaller frame sizes also
`facilitate fast scheduling among the different UEs onto the CCTrCH.
`
`The proposed downlink model supports the use of single and multiple HS-DSCH transport channels.
`
`3 Summary: Comparison with R99 DL Model
`The table below summarises the similarity and differences between Lucent’s HSDPA proposal and the R99 Downlink
`Shared Channels.
`
`TTI
`
`R99 DSCH Model
`10ms, 20ms, 40ms, and 80ms
`
`Frame Size
`
`Radio frame of 10ms
`
`Lucent Proposed DSCH Model
`Variable TTI with smallest TTI of 1 slot
`(0.667ms)
`
`Radio Sub-frame with minimum duration
`of 1 slot (0.667ms)
`
`Physical Channels
`
`Multiple physical channels per TTI
`
`Multiple physical channels per TTI
`
`SF
`
`SF can vary every TTI
`
`Fixed SF is proposed
`
`DSCH Transport Channels Multiple DSCH Transport Channels
`are defined. However, the need to
`support more
`than one DSCH
`Transport Channels
`has
`been
`proposed for further study.
`Performed on the CCTrCH level or
`across multiple Transport Channels.
`Single or multiple DSCH CCTrCh could
`be defined.
`
`DSCH CCTrCH
`
`Rate Matching
`
`Proposal supports use of multiple DSCH
`Transport Channels
`
`Performed per Transport Channel
`
`Single or multiple DSCH CCTrCh could
`be defined.
`
`UEs sharing Time and Code
`space
`
`Both in Time and Codes. More than
`one DSCH CCTrCH must be supported
`
`Both in Time and Codes. More than one
`DSCH CCTrCH must be supported for
`
`3
`
`

`

`for Codes sharing among UEs.
`
`Codes sharing among UEs.
`
`Table 1: Comparison of the Proposed DL Model and the R99 DL Model
`
`References
`4
`[1] “Downlink Transport Channel Multiplexing Structure for HSDPA”, TSG-RAN #17(00) 1383 Lucent Technologies.
`
`[2] “HSDPA Radio Interface Protocol Architecture”, R2A010023, Ericson, Motorola.
`
`[3] “Downlink and Uplink Channel Structures for HSDPA”, TSG-RAN#17(00) 1383, Lucent Technologies.
`
`[4]
`
` “Physical layer aspects of HSDPA and text proposals for HSDPA TR”, TSG-RAN1#16(00) 1193, Ericsson.
`
`[5] “A2IR – An asynchronous and adaptive Hybrid ARQ scheme for HSDPA”, TSG-RAN1#18, R1-01-0080, Lucent
`Technologies.
`
`[6] “Variable TTI proposal for HSDPA”, TSG-RAN1#18 (00), R1-01-0079, Lucent Technologies.
`
`4
`
`