throbber
3GPP TSG-RAN WG1 #60
`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
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket