TSG-RAN WG1 #52
`Sorrento, Italy, February 11 – 15, 2008
`
`R1-080871
`
`Source:
`Title:
`Agenda Item:
`Document for:
`
`Ericsson
`Summary of email discussion on UL control signaling
`6.1.4
`Discussion and Decision
`
`Introduction
`1.
`Between RAN1#51bis and RAN1#52, an e-mail discussion on uplink control signaling took place. The topics
`discussed are summarized below.
`
`2. Multiplexing of control and data on PUSCH
`The details on multiplexing of control and data on PUSCH remain open in the specifications. There is a general
`agreement from RAN1#50 stating that control should be located next to RS and there are some description on
`36.212 capturing this. However, the treatment of ACK/NAK vs CQI when both of them are transmitted on
`PUSCH are not yet settled.
`
`Three alternatives were proposed in an e-mail from LG:
`
`1. CQI mapping consecutive to RS + ACK/NACK mapping consecutive to RS by puncturing CQI
`symbols
`
`2. CQI mapping consecutive to RS + ACK/NACK mapping next to CQI by puncturing Data symbols
`(farther from RS)
`
`3. ACK/NACK mapping consecutive to RS + CQI time-first mapping (near-RS mapping is not
`considered)
`
`Among those 3 alternatives, we currently think the alternative 3 is preferable way considering ACK/NACK
`protection and simplicity in specifications (R1-080267 has detailed description). Alternative 1B and 2 are
`also described in detail in R1-080483.
`
`Discussions expressed support for alternative 3 both from a simplicity and performance perspective (ACK/NAK
`is more important than CQI, especially at high speeds where the CQI anyway tends to be less useful).
`
`One company suggested to place the ACK/NAK bits two modulation symbols (not SC-FDMA symbols) from
`the RS in order not to conflict with time windowing. No comments were received related to this.
`
`One company proposed to reserve ACK/NAK resources next to RS and then map CQI next to ACK/NAK
`(modified alternative 3) to improve CQI performance. The CQI position is independent on whether the
`ACK/NAK is present or not.
`
`Proposed way forward: Adopt alternative 3 above.
`
`3. Coding for CQI on PUSCH
`From kick-off email:
`
`It would be good to settle the coding scheme for control on PUSCH (it has already been settled for
`PUCCH). As the number of bits in CQI reports transmitted on PUSCH can be higher than on PUCCH, it
`seems to make sense to use the convolutional coding and rate matching mechanism already agreed for
`PDCCH and PBCH also for CQI reports on PUSCH. Can we agree on this?
`
`Comments received on the reflector supported reusing convolutional coding/rate matching as specified in 36.212
`for PBCH and PDCCH for the “larger” CQI reports (verify if adjustments needed to support the CQI payload
`sizes).
`
`The need for a CRC for CQI reports on PUSCH and its associated size (16 bits?) was brought up without
`conclusion.
`
`One company commented that a configurable offset between the PUSCH data MCS and the PUSCH control
`code rate is needed as the BLER operating point for data varies over a larger span (depending on the scheduler
`
`Optis Cellular Ex 2018-p. 1
`Apple v Optis Cellular
`IPR2020-00465
`
`

`

`implementation) than the control part (linking the control MCS to the data MCS has already been agreed in the
`past).
`
`Proposed way forward: Coding for CQI on PUSCH uses
`
`
`
`
`
`convolutional coding + rate matching as specified for PBCH and PDCCH for “large” CQI reports
`(above approx. 10 bits)
`
`the PUCCH block code for small CQI reports
`
`Optis Cellular Ex 2018-p. 2
`Apple v Optis Cellular
`IPR2020-00465
`
`