`San Francisco, USA, 22th – 26th February, 2010
`
`Source:
`Title:
`Agenda Item:
`Document for:
`
`
`Ericsson, ST-Ericsson
`A/N transmission in the uplink for carrier aggregation
`7.1.6
`Discussion and Decision
`
`R1-100909
`
`Introduction
`1.
`Bandwidth extension by means of carrier aggregation has been studied in RAN1 for quite some time, and at the RAN
`plenary meeting in December, the work item was agreed. Considering UE capabilities and spectrum flexibility, the
`support of asymmetric configurations, in the sense that the number of carriers aggregated in uplink and downlink is
`different, is needed. There will then not be a one-to-one relationship between uplink and downlink carriers and this
`has an impact on L1/L2 signaling such as grants, assignments and ACK/NACK feedback. At RAN1 #58bis, the
`following agreements were reached relevant to ACK/NACK transmission in the uplink:
`• Rel10 design supports up to 5 DL CC
`– Consider extendability to larger number of DL CC in the future
`• All A/N for a UE can be transmitted on PUCCH in absence of PUSCH transmission
`–
`Support mapping onto one UE specific UL CC
`• One A/N for each DL CC transport block should be supported
`•
`Limited A/N transmission for the DL CC transport blocks should be supported for power
`limitation
`Support for simultaneous A/N transmission on multiple UL CC is FFS
`• One A/N for each DL CC transport block should be supported
`•
`Limited A/N transmission for the DL CC transport blocks should be supported for power
`limitation
`– Exact method for A/N resource allocation is FFS
`• Do not optimize the A/N feedback for multiple DL CC assuming large number of UEs
`being simultaneously scheduled on multiple DL CC
`• Consider performance and power control issues (CM, BER...)
`
`–
`
`
`Clarifications:
`- A/N mapping onto one UL CC: semi-static and dynamic mapping are not excluded.
`- Multiple PUCCH on an UL CC is not excluded.
`
`
`The present contribution considers ACK/NACK transmission in the uplink and discusses some implications of these
`agreements, more specifically, payload size, formats and resources are discussed.
`2. Discussion
`2.1. ACK/NACK payload size
`The dimensioning case for ACK/NACK feedback in the uplink is clearly the case with five downlink component
`carriers and single uplink component carrier. With MIMO transmission, ACK/NACKs of up to two codewords are
`needed and for the case with five carriers, at least 10 bits are needed. However, since the terminal may miss
`downlink assignments, the case that the UE does not transmit any ACK/NACK feedback, commonly refered to as
`DTX in this context, also needs to be considered. Since resources for both codewords are (also for Rel-10 expected
`to be) assigned with the same jointly coded downlink assignment, there are five possible feedback values for the
`ACK/NACK of an individual component carrier in the case with dual codeword transmission: (ACK,ACK),
`(ACK,NACK), (NACK,ACK), (NACK,NACK) and (DTX). Similarly in the case with single codeword transmission
`there are three possible feedback values, {ACK, NACK, DTX}. Generally with mixed single and dual codeword
`f1
`nf
`, with
` being the number of ACK/NACK
`transmissions the required number of feedback states is
`
`n
`
`nl
`
`Ericsson Exhibit 1022
`Page 1
`ERICSSON v. ETRI
`
`
`
`2
`
`feedbacks per DL component carriers (3 and 5 for single and dual codeword transmission, respectively) and n the
`number of component carriers..
`For the case with five downlink component carriers, and a single associated downlink subframe on each of the five
`55 different values that need to be conveyed. In fact,
`downlink component carriers, there are then in the MIMO case
`the UE may also use DTX to signal to the eNodeB that it has not received any downlink assignments at all, implying
`55 different values. In any case, the maximum number of bits required is
`that there is a need to be able to encode
`1
`12 for the case with MIMO. For the case with no MIMO, the maximum number of bits needed is
`
`5
`.
`3
`log
`8
`1
`
`
`Observation
`
`In the case with carrier aggregation and a single associated downlink subframe on each component carrier,
`55 different messages, corresponding to 12 bits, need to be fed back in case of MIMO transmission.
`up to
`For TDD, the number of ACK/NACK bits for a given subframe also depends on the uplink-downlink asymmetry.
`For a 4DL:1UL asymmetry, the number of different messages that needs to be conveyed is larger. For the case with
`205 different messages, or for binary
`MIMO and two codewords and five downlink component carriers, there are
`encoding around
`
`20
`bits.
`log
`47
`5
`
`2
`Already in rel-8, limited ACK/NACK transmission is supported both in the space domain and in the time domain for
`the two different ACK/NACK feedback modes for TDD. For TDD ACK/NACK multiplexing in Rel-8, spatial
`bundling and mapping of NACK and DTX to the same feedback message is used. While this certainly improves
`uplink performance in terms of coverage it also impacts downlink since it will be more challenging to harvest
`incremental redundancy gains, and since there are no agreements on layer shifting for the downlink which would
`mitigate the impact of spatial bundling. At the same time, assuming that that the major source for failed decoding is
`poor prediction of the channel quality from CQI reports, error events in time-consecutive subframes are more likely
`to be dependent. However, this dependency is not expected to hold for different component carriers with independent
`CQI reports, and hence ACK/NACK bundling over different component carriers needs further study.
`Proposal
` Consider temporal ACK/NACK bundling per component carrier for TDD.
`
`2.2. PUCCH format for multiple ACK/NACK
`In rel-8 and rel-9, there are essentially two different PUCCH formats, format 1 and 2. When it comes to PUCCH
`format 1, and then format 1a or 1b more specifically, a method to consider is PUCCH format 1 combined with
`channel selection. However, since format 1b can carry two bits the amount of PUCCH format 1 resources appears
`26
`, for MIMO
`rather large; for 8 bits, the number of PUCCH format 1b resources needed is in the order of
`64
`210
`correspondingly around
`resource would be needed. Hence, unless aggressive bundling is assumed, the
`1024
`consequence of supporting per transport block ACK/NACK feedback for up to five downlink component carriers is
`that PUCCH format 1a/1b are not appropriate for ACK/NACK transmission.
`Observation
` PUCCH format 1a/1b combined with channel selection appears not appropriate for ACK/NACK
`transmission unless aggressive ACK/NACK bundling is used.
`When it comes to PUCCH format 2, we note that it can carry up to 22 coded bits. The block code for CQI reports on
`PUCCH supports up to 13 information bits. Hence, in principle it would be possible to use the existing block code to
`cater for transmission of ACK/NACKs and re-use PUCCH format 2. What becomes very challenging is that the code
`rate would become very high.
`A key factor to consider in the design of the multiple ACK/NACK is robustness to intra- and inter-cell interference,
`since such interferences likely limit the feedback capacity. In fact during the standardization of LTE TDD Rel-8, as
`noted in [2] at least two options were identified including PUCCH format 2 as well as a DFT-S-OFDM based
`structure. Previous studies indicated the DFT-S-OFDM based structure offers better performance and multiplexing
`capabilities under time-varying, dispersive and interfering scenarios [3][4][5].
`
`Ericsson Exhibit 1022
`Page 2
`ERICSSON v. ETRI
`
`
`
`To support Rel-10 and beyond, the payloads for ACK/NACK are expected to become larger as compared to the
`payloads for Rel-8. We therefore propose to adopt a DFT-S-OFDM based PUCCH such as illustrated in Figure 1.
`Assuming QPSK modulation for the PUCCH, 48 coded bits can be carried by 12 sub-carriers in two slots. Allocation
`of multiple resource blocks to this new PUCCH format is possible if higher processing gain is required. To mitigate
`inter-cell interference, cell-specific scrambling is applied to randomize such interference. Depending whether 1, 2 or
`3 OFDM symbols are devoted to reference symbols, up to 6, 5 or 4 PUCCHs can be multiplexed within the same
`radio resources. Since the UE composes the ACK/NACK messages according to the number of activated CCs as
`discussed in Section 2.1, there is no need to further inflate PDCCH with DAI-like fields. Many PDCCH signaling
`error cases are also removed with the adoption of such a PUCCH format.
`Proposal
` Consider a new PUCCH format based on DFT-S-OFDM for transmission of multiple ACK/NACK in the
`context of carrier aggregation.
`
`
`
`error
`correct.
`coding
`
`cell- specific
`scrambing
`
`cell- specific
`scrambing
`
`
`
`ModMod
`
`
`
`ModMod
`
`cell- specific
`scrambing
`
`Mod
`
`
`
`w[0]w[0]
`
`
`
`w[1]w[1]
`
`w[K - 1]
`
`DFTS - OFDM
`symbol 0
`
`DFTS - OFDM
`symbol 1
`
`DFTS - OFDM
`symbol K -1
`
`
`Figure 1 DFT-S-OFDM based PUCCH, where {w[0], w[1], …, w[K-1]} is a spreading cover.
`
`3. Conclusions
`This contribution discussed the ACK/NACK transmission in the uplink for carrier aggregation in terms of payload
`size, PUCCH formats and resource allocation. Based on the discussions we made the following observations:
`
`In the case with carrier aggregation and a single associated downlink subframe on each component carrier,
`55 different messages, corresponding to 12 bits, need to be fed back in case of MIMO transmission.
`up to
` PUCCH format 1a/1b combined with channel selection appears not appropriate for ACK/NACK
`transmission unless aggressive ACK/NACK bundling is used.
`We therefore propose the following:
` To consider temporal ACK/NACK bundling per component carrier for TDD.
` To consider a new PUCCH format based on DFT-S-OFDM for transmission of multiple ACK/NACK in the
`context of carrier aggregation.
`
`Ericsson Exhibit 1022
`Page 3
`ERICSSON v. ETRI
`
`
`
`References
`[1] R4-091285 “Carrier aggregation: some UE aspects”, Ericsson
`[2] R1-081110 “Multiple ACK/NAK for TDD”, Ericsson, Motorola, Nokia, Nokia Siemens Networks, Qualcomm
`[3] R1-074812 “On PUCCH Structure for CQI Report”, NTT DoCoMo, Nokia Siemens Networks, Nokia,
`Mitsubishi Electric, Toshiba Corporation
`[4] R1-062841 “Multiplexing of L1/L2 Control Signalling when UE has no data to transmit,” Nokia
`[5] R1-072308 “Performance comparison of CAZAC sequence modulation and DFT-S-OFDM method,” Nokia
`Siemens Networks, Nokia
`
`
`
`
`Ericsson Exhibit 1022
`Page 4
`ERICSSON v. ETRI
`
`