`Date:
`To:
`
`ext Montojo, Juan
`April 14, 2008 5:46:52 PM (-05)
`3GPP_TSG_RAN_WG1@LIST.ETSI.ORG
`
`Subject:
`
`Re: Email approval of R1-081666 (Transmission of PUCCH format 1)
`
`Attachments:
`
`R1-081699.zip;
`
`Dear All,
`
`Please find attached the CR on transmission of PUCCH format 1 with Tdoc #. The 36.211 CR number is 0009.
`
`BR,
`
`Juan
`
`
`
`From: Dirk Gerstenberger [mailto:dirk.gerstenberger@ericsson.com]
`Sent: Friday, April 11, 2008 9:56 AM
`To: Montojo, Juan; 3GPP_TSG_RAN_WG1@LIST.ETSI.ORG
`Subject: RE: Email approval of R1-081666 (Transmission of PUCCH format 1)
`
`Dear Juan and all,
`
`it seems agreement has been reached now on the revised draft CRs.
`| suggest we consider these versions agreed.
`
`Juan, please obtain a Tdoc number from Patrick and distribute the agreed CR (with CR numbenon the
`reflector.
`
`BR,
`Dirk
`
`
`
`From: Montojo, Juan [mailto:juanm@QUALCOMM.COM]
`Sent: den 11 april 2008 12:47
`To: 3GPP_TSG_RAN_WG1@LIST.ETSI.ORG
`Subject: Re: Email approval of R1-081666 (Transmission of PUCCH format 1)
`
`Dear All,
`
`Weare fine with the mapping similar to PUCCH format 2a/2b although wewill not be able to distinguish DTX
`from NAK when SR and ACK happen in the same subframe. I've modified the CR to capture what seems to be
`everyone's preference.
`
`Please let me know if you have comments/questions.
`
`BR,
`
`IPR2017-1581
`
`Huawei v. NSN
`
`NSN 2004 Page1
`
`NSNH00034658
`
`IPR2017-1581
`Huawei v. NSN
`
`NSN 2004 Page 1
`
`
`
`Juan
`
`
`
`From: Aris Papasakellariou [mailto:aris.papas@PARTNER.SAMSUNG.COM]
`Sent: Thursday, April 10, 2008 3:54 AM
`To: 3GPP_TSG_RAN_WG1@LIST.ETSI.ORG
`Subject: Re: Email approval of R1-081666 (Transmission of PUCCH format 1)
`
`Dear all,
`
`We would like to avoid having two detection possibilities (mappings) for the SR depending on whether or not
`it is multiplexed with ACK/NAK.
`For this reason, we prefer the second option mentioned by Jari and Daniel which is the same as whatis
`mentioned by Zukang.
`
`BR,
`Aris
`
`From: Daniel Larsson N [mailto:daniel.n.larsson@ERICSSON.COM]
`Sent: Thursday, April 10, 2008 1:37 PM
`To: 3GPP_TSG_RAN_WG1@LIST.ETSI.ORG
`Subject: Re: Email approval of R1-081666 (Transmission of PUCCH format 1)
`
`Dear all,
`
`Thanksto Jari for initiating the discussion. We would prefer consistency with ACK/NAKonly transmission when
`transmitting ACK/NAK and SRI. By that we mean that we would prefer either one of the twoinitial suggestion
`by Jari i.e.
`
`For PUCCH format 1, information is carried by the presence/absenceof transmission of PUCCH from the UE.
`In the remainder ofthis section, d(0) = (-1/sqrt(2) -j/sqrt(2)) shall be assumed for PUCCH format 1.
`
`Another possibility is to map scheduling request d(0) = 1 and use the same modulation of ACK/NACK bits as
`with PUCCH formats 2a and 2b (table 5.4.2-1) for 1a and 1b respectively.
`
`BR
`
`Daniel Larsson
`
`
`
`From: Shen, Zukang [mailto:zukang.shen@TI.COM]
`Sent: den 9 april 2008 16:04
`To: 3GPP_TSG_RAN_WG1@LIST.ETSI.ORG
`Subject: Re: Email approval of R1-081666 (Transmission of PUCCH format 1)
`
`Dear Jari,
`
`Thanksfor initiating the discussion. Tl shares the same viewthat for concurrent ACK/NAK and SRI
`transmission, SRI ON shall be mapped to NAK or (NAK, NAK). For consistency with 2a and 2b, we prefer to
`reuse Table 5.4.2-1 for ACK/NAK mapping when ACK/NAKis transmitted together with SRI. For AGig@(R4617-1581
`Huawei v. NSN
`
`NSN 2004 Page 2
`
`NSNH00034659
`
`IPR2017-1581
`Huawei v. NSN
`
`NSN 2004 Page 2
`
`
`
`only transmission, the BPSK/QPSK constellation defined in section 7.1.1 and 7.1.2 in 36.211 can be used.
`Thanks.
`
`Regards,
`Zukang
`
`KRKERERERERERERERERERERERERERERERERERERERE
`
`Zukang Shen, Ph.D.
`Systems Engineer
`DSP Base Station
`
`Communications Infrastructure
`
`Texas Instruments Inc.
`
`Tel: 214-480-3198
`KRKERERERERERERERERERERERERERERERERERERERE
`
`
`
`From: Jari Lindholm [mailto:jari.lindholm@NSN.COM]
`Sent: Wednesday, April 09, 2008 8:05 AM
`To: 3GPP_TSG_RAN_WG1@LIST.ETSI.ORG
`Subject: Email approval of R1-081666 (Transmission of PUCCH format 1)
`
`Dearall,
`
`Wepropose that PUCCH format 1 is transmitted using the same constellation point as NACK or NACK/NACKwith
`PUCCHformats la and 1b respectively. This approach is similar to PUCCH format 2/2a/2b operation i.e. when CQIis
`sent without ACK/NACK (PUCCHformat 2), reference signals are selected so that they correspond to transmission of
`NACK or NACK/NACKwith formats 2a and 2b.
`
`Probably the simpliest way to describe this in the specification is to modify the first paragraph of the chapter 5.4.1:
`For PUCCH format1, information is carried by the presence/absence of transmission of PUCCH from the UE.In the
`remainderof this section, d(0) = (-1/sqrt(2) -j/sqrt(2)) shall be assumed for PUCCH format1.
`
`Anotherpossibility is to map scheduling request d(0) = 1 and use the same modulation of ACK/NACKbits as with
`PUCCHformats 2a and 2b (table 5.4.2-1) for la and 1b respectively.
`
`BR,
`Jari
`
`IPR2017-1581
`
`Huawei v. NSN
`
`NSN 2004 Page 3
`
`NSNH00034660
`
`IPR2017-1581
`Huawei v. NSN
`
`NSN 2004 Page 3
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
