R1-090002
`
`
`
`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`Agenda item
`3
`Title:
` Final Report of 3GPP TSG RAN WG1 #55 v1.0.0
`
`
`(Prague, Czech Republic, 10 – 14 November, 2008)
`Document for:
` Comment
`Source:
`
`MCC Support
`
`
`
`
`
`
`
`
`
`
`Fact Summary
`Meeting:
`Dates:
`Venue:
`Host:
`Attendees:
`Documents:
`
`
`3GPP TSG RAN WG1 #55
`10th through 14th November, 2008
`The Clarion Congress Hotel in Prague, CZECH REPUBLIC
`European Friends of 3GPP
`165 delegates
`626 (including some withdrawn and post-meeting artefacts)
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Patrick Mérias
`ETSI Mobile Competence Center
`F-06921 Sophia Antipolis Cedex
`Tel: +33 4 92 94 42 06
`
`Patrick.merias@etsi.org
`
`1
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2007 - Page 1
`
`

`

`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`
`
`
`R1-090002
`
`2 2
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2007 - Page 2
`
`

`

`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`
`Table of contents
`
`R1-090002
`
`
`Executive summary ......................................................................................................................................... 4
`1. Opening of the meeting ........................................................................................................................ 6
`1.1
`Call for IPR ....................................................................................................................................................... 6
`2.
`Approval of the agenda ......................................................................................................................... 6
`3.
`Approval of the minutes from previous meeting ............................................................................... 6
`4.
`Liaison statement handling .................................................................................................................. 7
`5. Maintenance of UTRA Release 99 – Release 8 ............................................................................. 10
`6. Maintenance of Evolved UTRA and UTRAN ................................................................................... 13
`6.1
`Corrections for TS 36.211 ............................................................................................................................ 16
`6.2
`Corrections for TS 36.212 ............................................................................................................................ 21
`6.3
`Corrections for TS 36.213 ............................................................................................................................ 25
`6.3.1
`Ad Hoc session on CQI ................................................................................................................................ 39
`6.4
`Corrections for TS 36.214 ............................................................................................................................ 41
`6.5
`Corrections for TS 36.306 ............................................................................................................................ 42
`7.
`Dual-Cell HSDPA Operation on Adjacent Carriers ......................................................................... 43
`8.
`Enhanced CELL_FACH state in 1.28 Mcps TDD (UL/DL) ............................................................ 46
`9.
`Continuous Connectivity for packet data users for 1.28Mcps TDD ............................................. 47
`10. MIMO for 1.28Mcps TDD .................................................................................................................... 48
`11. Study Item on LTE-Advanced ............................................................................................................ 49
`11.1
`Bandwidth extension ..................................................................................................................................... 50
`11.2
`UL transmission scheme .............................................................................................................................. 53
`11.3
`DL transmission scheme .............................................................................................................................. 57
`11.4
`Coordinated Multipoint Transmission/Reception (COMP) ....................................................................... 59
`11.5
`Relaying .......................................................................................................................................................... 62
`12. Review of DOB compromise proposal ............................................................................................. 62
`13. Closing of the meeting ........................................................................................................................ 63
`Annex A: List of participants at RAN1 #55 .............................................................................................. 64
`Annex B: TSG RAN WG1 meetings in 2009 .......................................................................................... 65
`Annex C: List of CRs agreed at RAN1#55 .............................................................................................. 66
`Annex D: List of Outgoing LSs from RAN1#55 ...................................................................................... 74
`Annex E: List of Tdocs at RAN1 #55 ....................................................................................................... 75
`Annex F: List of actions ............................................................................................................................. 76
`
`
`
`
`3 3
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2007 - Page 3
`
`

`

`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`
`
`R1-090002
`
`Executive summary
`3GPP TSG WG RAN1 #55 meeting took place in Clarion Congress Hotel, Prague, CZECH REPUBLIC.
`
`The meeting started at 9:10 on Monday 10th November and finished at 17:10 on Friday 14th November 2008.
`
`
`
`The week was scheduled as follows:
`
`• Monday: Common session on Agenda items 1, 2, 3, 4, 6, partially 6.1, 5 and 7.
`
`• Tuesday: Common session dedicated to corrections to TS36.211 (AI 6.1), TS36.214 (AI 6.4) and TS36.213 (AI
`6.3).
`
`• Wednesday morning: Parallel sessions on Agenda item 11.1 chaired by Dirk Gerstenberger and Agenda item 6.3
`(CQI) chaired by Juho Lee
`
`• Wednesday afternoon: Parallel sessions on Agenda item 11.2 chaired by Dirk Gerstenberger and Agenda item 6.2
`chaired by Sadayuki Abeta.
`
`• Thursday morning: Parallel sessions; Continued discussion for LTE-Advanced (AI 11) chaired by Dirk
`Gerstenberger. Dedicated discussion on RNTI chaired by Hidetoshi Suzuki.
`
`• Thursday afternoon: Continue discussions w.r.t LTE-Advanced in main meeting room till coffee break chaired by
`Dirk Gerstenberger. Parallel discussions w.r.t LTE-36.213 (AI 6.3) chaired by Sadayuki Abeta and w.r.t TDD (AI
`8, 9 and 10) chaired by Dirk Gerstenberger.
`
`• Friday morning: Common session on Agenda items 6.1 and 6.3.
`
`• Friday afternoon: Revisions
`
`
`
`The list of action points that required RAN1 close follow-up is listed in Annex F (end of document).
`
`
`The number of contribution documents for this meeting was 605, and those documents were categorized as followed.
`
`Agenda Item
`Liaison statement handling
`Maintenance of UTRA R99 – Rel8
`Maintenance of Evolved UTRA and UTRAN
`Dual-Cell HSDPA Operation on Adjacent Carriers
`Enhanced CELL_FACH in 1.28Mcps TDD (UL/DL)
`Continuous Connectivity for Packet Data users for
`1.28Mcps TDD
`MIMO for 1.28Mcps TDD
`Study Item on LTE-A: Evaluations
`Study Item on LTE-A: Bandwidth extension
`Study Item on LTE-A: UL transmission scheme
`Study Item on LTE-A: DL transmission scheme
`Study Item on LTE-A: COMP
`Study Item on LTE-A: Relaying
`DOB
`
`Input
`Document
`26
`34
`279
`17
`8
`12
`10
`22
`37
`48
`34
`40
`32
`3
`
`Discussed
`Document
`25
`30
`218
`13
`4
`11
`10
`14
`6
`11
`-
`10
`4
`1
`
`
`
`Note: The amount of documents includes those discussed during the email discussion session post meeting.
`
`4 4
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2007 - Page 4
`
`

`

`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`
`The following document are missing. The corresponding contributions have not been handed over by companies.
`
`R1-090002
`
`
`
`
`
`R1-084112
`
`The uplink resource allocation based on beamforming for LTE-Advanced
`
`R1-084116
`
`Hybrid Relay used in different Scenarios
`
`R1-084230
`
`Considerations on the UL control channels in MIMO PUSCH
`
`R1-084289
`
`Improving spectrum utilization for carrier aggregation in LTE-A
`
`R1-084486
`
`DVRB for Beamforming
`
`R1-084603
`
`UE emission control
`
`ZTE
`
`ZTE
`
`Panasonic
`
`CATT,RITT
`
`CATT
`
`Motorola
`
`5 5
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2007 - Page 5
`
`

`

`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`
`
`R1-090002
`
`Opening of the meeting
`1.
`Mr. Dirk Gerstenberger (RAN1 Chairman) welcomed the participants to the 55th RAN WG1 meeting and opened the
`meeting at 09:00.
`
`Georg Wannemacher from T-Mobile welcomed the delegates on behalf of European Friends of 3GPP and informed them
`about logistic issues during the week.
`
`Call for IPR
`1.1
`The Chairman drew attention to Members’ obligations under the 3GPP Partner Organizations’ IPR policies. Every
`Individual Member organization is obliged to declare to the Partner Organization or Organizations of which it is a
`member any IPR owned by the Individual Member or any other organization which is or is likely to become
`essential to the work of 3GPP.
`
`
`The attention of the members of this Technical Specification Group is drawn to the fact that 3GPP
`Individual Members have the obligation under the IPR Policies of their respective Organizational Partners
`to inform their respective Organizational Partners of Essential IPRs they become aware of.
`
`The members take note that they are hereby invited:
`
`•
`
`•
`
`
`
`2.
`
`to investigate in their company whether their company does own IPRs which are, or are likely to become
`Essential in respect of the work of the Technical Specification Group.
`
`to notify the Director-General, or the Chairman of their respective Organizational Partners, of all
`potential IPRs that their company may own, by means of the IPR Statement and the Licensing declaration
`forms (e.g. see the ETSI IPR forms http://webapp.etsi.org/Ipr/).
`
`Approval of the agenda
`
`Draft Agenda for RAN1#55 meeting
`R1-084080
`Dirk Gerstenberger (Chairman) proposed the agenda for the meeting.
`
`RAN1 Chairman
`
`
`
`Discussion (Question / Comment):
`Decision: The agenda was approved.
`
`
`
`3.
`
`Approval of the minutes from previous meeting
`
`Final report of RAN1#54bis meeting
`R1-084512
`The document was presented by Patrick Mérias.
`Discussion (Question / Comment): Concerning the number of CRs (already 73CRs agreed during last meeting), Mr
`Chairman suggested trying to merge CRs as much as possible (especially editorial ones) to avoid increasing the number of
`change request and better reflect the technical stability of the specifications.
`Decision: The document is noted and approved.
`
`MCC Support
`
`(R1-084081)
`
`6 6
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2007 - Page 6
`
`

`

`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`
`
`Liaison statement handling
`4.
`Incoming LS
`
`R1-090002
`
`= C1-084495
`CT1, Panasonic
`LS on draft response LS on Connection recovery by NAS
`R1-084082
`The document was briefly presented by Hidetoshi Suzuki from Panasonic, although the interest to RAN1 is very limited.
`
`Discussion (Question / Comment): No action required from RAN1.
`Decision: Document is noted.
`
`RAN2, Alcatel-Lucent
`Response LS on Connection recovery by NAS
`R1-084085
`The document was presented by Christian Gerlach from Alcatel-Lucent.
`Discussion (Question / Comment): No action required from RAN1.
`Decision: Document is noted.
`
`= R2-085972
`
`Response LS on Connection recovery by NAS
`R1-084086
`The document was presented by (…) from Vodafone
`Discussion (Question / Comment): No action required from RAN1.
`Decision: Document is noted.
`
`
`
`RAN3, Vodafone
`
`= R3-082850
`
`= R2-085958
`RAN2, NTT DoCoMo
`LS on Maximum allowed transmission power on the uplink
`R1-084083
`The document was presented by Sadayuki Abeta from NTT DoCoMo. RAN2 kindly requests RAN1 to confirm the RAN2
`agreements and assumptions in R1-084083, namely:
`
`• To introduce an IE “Pmax” in SIB1 to allow setting of the max allowed transmission power on the uplink to a
`value smaller than the max power defined as UE capability in RAN4, i.e., 23 dBm.
`
`• To introduce an IE “Pmax” also in the handover command to provide the applicable value at the target cell.
`
`“Pmax” above has a value range -40..23 dBm with a step size of 1 dB.
`•
`Discussion (Question / Comment): Panasonic raised the question whether these assumptions should required CR
`Decision: Document is noted. Assumptions are agreed by RAN1 (no need to send a reply LS). FFS to check whether CRs
`are needed in RAN1 specs.
`
`
`
`R1-084084
`LS on Virtual CRC for DL data arrival
`RAN2, Qualcomm
`= R2-085966
`The document was presented by Juan Montojo from Qualcomm. RAN2 kindly asks RAN1 to capture use of virtual CRC
`for PDCCH for DL data arrival in RAN1 specification.
`
`Discussion (Question / Comment): Qualcomm commented that this was fully aligned with current work in RAN1.
`Corresponding CRs are provided under relevant agenda items.
`Decision: Document is noted.
`
`
`
`Response LS on value ranges and high quality criterion
`R1-084087
`The document was presented by Sadayuki Abeta from NTT DoCoMo.
`
`Discussion (Question / Comment): No action required from RAN1.
`Decision: Document is noted.
`
`
`
`RAN4, NTT DoCoMo
`
`= R4-082620
`
`LS on EARFCN number range
`R1-084088
`The document was presented by Yu Ding from CATT
`
`RAN4, CATT
`
`= R4-082638
`
`7 7
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2007 - Page 7
`
`

`

`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`
`Discussion (Question / Comment): No action required from RAN1.
`Decision: Document is noted.
`
`
`R1-090002
`
`= R4-082655
`RAN4, Nokia
`Response LS on indicating radio problem detection
`R1-084089
`The document was presented by Asbjørn Grøvlen from Nokia. RAN4 asks if RAN1 sees any problem defining the radio
`link problem and recovery evaluation related aspects in RAN4 specifications, for example TS 36.133.
`Discussion (Question / Comment): Ericsson confirmed that CR in relation with that topic has been prepared in R1-
`084379.
`Decision: Document is noted.
`
`
`
`Reply LS on Consequence analysis of Low/ Medium
`= R5-084203
`RAN5, NTT DoCoMo
`R1-084090
`features in LTE Rel-8
`The document was presented by Sadayuki Abeta from NTT DoCoMo and is for information only. As a result of the
`feedback from RAN1 and RAN2, it shows RAN5 update and endorsement of the feature and test priority list (so-called
`“the LTE Feature List”).
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`
`
`R1-084093
`
`DRAFT Response to LS on scope and reference for
`parameter “sameRefSignalsInNeighbour”
`
`Philips, NXP
`Semiconductors, ST
`Microelectronics,
`Qualcomm
`The document was presented by Matthew Baker from Philips and drafts a reply to RAN2 for the use of the parameter
`“sameRefSignalsInNeighbour”. RAN1 proposes that this parameter be used to indicate whether the neighbour cells
`transmit a second antenna port or not.
`
`
`
`Discussion (Question / Comment): NSN confirmed that they won’t support the proposed response as their current
`understanding is that such parameter should be removed. The scope of this parameter (originally for TDD) is already
`covered in the specification according to NSN.
`Decision: Document is noted. This shall be rechecked later on, waiting for RAN4 discussion.  See action point LTE
`55/1.
`
`
`
`R1-084244
`
`[Draft] LS on P_A value and L1 parameter range
`
`Panasonic, Alcatel-
`Lucent, Ericsson,
`Motorola, Nokia, Nokia
`Siemens Network,
`Samsung, Sharp, Texas
`Instruments
`The document was presented by Hidetoshi Suzuki from Panasonic and drafts a response asking RAN2 to change the P_A
`values in TS 36.331 as outlined in the LS. In addition RAN1 kindly asks RAN2 to note RAN1’s discussion on the
`handling of L1 parameters.
`
`
`
`Discussion (Question / Comment):
`Decision: Document is noted. Final LS is agreed in R1-084514.
`
`
`
`
`CATT
`Draft LS for SRS transmission
`R1-084278
`The document was presented by Yu Ding from CATT and informs RAN2 on following RAN1 agreements:
`
`• The maximum SRS bandwidth in UpPTS for TDD can be reconfigured to improve the efficiency of UpPTS.
`
`• Such reconfiguration can be enabled/disabled by 1bit cell specific higher layer signalling and the default status is
`‘enable’.
`
`8 8
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2007 - Page 8
`
`

`

`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`
`Discussion (Question / Comment): CATT wondered whether such LS is needed as RAN2 seems to be already aware of
`it.
`Decision: Document is noted. No need to send the LS, as relevant contributions have been already distributed in RAN2.
`
`R1-090002
`
`
`
`Draft LS for CR on 36300
`R1-084281
`The document was presented by Ke Wang from CATT.
`Discussion (Question / Comment): Reference to meeting should be corrected to RAN1#55. One typo to be corrected as
`well. R1-084282 is attached to the LS.
`Decision: Document is noted. Final LS is agreed in R1-084516.
`
`CATT
`
`
`
`Draft CR on Correction of the Description of FS2
`R1-084282
`Decision: Document is noted and agreed.
`
`CATT
`
`
`
`Draft LS on removing delta_offset^PUCCH for PUCCH
`R1-084382
`format 1/1a/1b
`The document was presented by Wanshi Chen from Qualcomm.
`
`Discussion (Question / Comment):
`Decision: Document is noted. Final LS is agreed in R1-084517.
`
`
`Qualcomm Europe
`
`
`
`
`
`
`Qualcomm Europe
`On the need for UL bandwidth default value
`R1-084383
`The document was presented by Juan Montojo from Qualcomm and proposes to use DCI format 1C for carrying SIB1 and
`SIB2, and avoid the need for specifying default UL bandwidth value originated by DCI format 1A.
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`
`
`Texas Instruments
`Draft LS on support of ACK/NACK repetition in Rel-8
`R1-084437
`The document was presented by Zukang Shen from Texas Instruments and details the agreement reached on ACK/NACK
`repetition in Rel-8.
`Discussion (Question / Comment): Motorola requested clarification on the number of repetition of the ACK/NACK.
`Mr Chairman suggested waiting for the discussion on related CRs.
`Decision: Document is noted. LS shall be revisited after that discussion has occurred.
`
`Friday 14th
`
`RAN1, Texas
`(R1-084437)
`LS on support of ACK/NACK repetition in Rel-8
`R1-084649
`Instruments
`Discussion (Question / Comment): Samsung suggested to clarify what happen in case of 2bits repetition of ACK/NACK.
`Decision: Document is noted and LS is agreed.
`
`
`
`Incoming LS received during the week
`
`RAN4, Motorola
`LS on UE emission control
`R1-084569
`The document was presented by Robert Love from Motorola on Friday 14th.
`
`= R4-083197
`
`Discussion (Question / Comment):
`Decision: Document is noted. Reflected in draft CR in R1-084629 (agreed as CR0113 in R1-084666).
`
`
`
`The following LS has not been treated.
`
`9 9
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2007 - Page 9
`
`

`

`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`
`
`R1-090002
`
`R1-084616
`
`LS on Common Test Environment (TS 36.508)
`
`RAN5, NTT DoCoMo
`
`= R5-085515
`
`
`
`
`
`5.
`
`Maintenance of UTRA Release 99 – Release 8
`
`
`
`
`Ericsson
`UE restrictions on E-TFCIs
`R1-084259
`The document was presented by Kai-Erik Sunell from Ericsson and discusses restrictions for E-TFCI selection for Rel-6/7
`UEs. RAN1 is asked to consider these restrictions while corresponding RAN2 CRs have been provided in R2-086439, R2-
`086440 and R2-086442.
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`
`Qualcomm Europe
`Link Analysis of High Code Rate E-DCH Transmissions
`R1-084500
`The document was presented by Sharad Sambhwani from Qualcomm and provides a link-level analysis to study the turbo
`code irregularities on enhanced uplink. The paper suggests reducing the range of restrictions proposed in R1-084259:
`
`• Rel-6 UEs can still use E-TFCI Table 0 and Table 1 since the degradation is small and disappears in multiple
`HARQ transmissions.
`
`• Rel-7 UEs shall not use the following E-TFCIs:
`o E-TFCI 121 in Table 2a
`o E-TFCI 101 in Table 2b
`o E-TFCI 102 in Table 2b
`Discussion (Question / Comment):
`Decision: Document is noted. General agreement on the principle allowing Rel-6 UEs to avoid bad E-TFCIs and
`prohibiting Rel-7 UEs to use bad E-TFCIs. The exact E-TFCIs should be agreed offline.
`Friday 14th : Qualcomm commented that LS to RAN5 gathering RAN2 agreement has been sent in R2-087170.
`
`
`Qualcomm Europe
`
`Qualcomm Europe
`
`
`
`
`
`25.214 CR0520 (Rel-5, A) Clarification of NIR setting in CQI
`mapping tables
`25.214 CR0521 (Rel-6, A) Clarification of NIR setting in CQI
`mapping tables
`25.214 CR0522 (Rel-7, A) Clarification of NIR setting in CQI
`mapping tables
`25.214 CR0515 (Rel-8, F) Clarification of NIR setting in CQI
`
`Qualcomm Europe
`R1-084104
`mapping tables
`Rel-8 CR was presented by Sharad Sambhwani from Qualcomm and clarifies that the UE shall assume number of soft
`channel bits available in the virtual IR buffer (NIR) given in the CQI mapping tables only for CQI reporting purposes
`irrespective of the number of HARQ processes configured.
`Discussion (Question / Comment): NSN raised the question on the real benefit of such clarification as apparently
`everyone has been able to read (so far) the current spec as it should be.
`Decision: Document is noted and CR0515 (Release 8) is agreed according that the “Other core specifications” box is
`blanked (no other specification are impacted)  MCC to correct it. RAN1 agreed to not reflect the change in previous
`releases.
`
`R1-084326
`
`R1-084327
`
`R1-084328
`
`Qualcomm Europe
`
`
`
`
`
`R1-084497
`
`25.214 CR0516R1 (Rel-7,F) Correction to E-DPDCH gain
`factor interpolation in compressed mode
`
`Huawei
`
`(R1-084175)
`
`10 10
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2007 - Page 10
`
`

`

`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`
`
`R1-090002
`
`25.214 CR0517R1 (Rel-8,A) Correction to E-DPDCH gain
`R1-084498
`factor interpolation in compressed mode
`Rel-7 CR was presented by (…) from Huawei
`Discussion (Question / Comment): According to Ericsson only the two changes related to TTI 10msec are needed.
`Decision: Document is noted. Further check shall be done off line and CRs shall be revisited later on.  See action point
`HSPA 55/1
`
`(R1-084176)
`
`Huawei
`
`
`
`Ericsson, Qualcomm
`25.214 CR0518 (Rel-7, F) Clarification of CQI repetition in
`
`R1-084260
`Europe
`case of UE DTX
`Rel-7 CR was presented by Johan Bergman from Ericsson and clarifies that CQI repetition shall be performed regardless
`of any configured CQI transmission pattern.
`
`Discussion (Question / Comment): Nokia requested some off line discussion for further clarification.
`Decision: Document is noted. To be revisited later on. Shadow CR shall be prepared as well for Rel-8.  See action point
`HSPA 55/2
`
`
`
`Agilent Technologies,
`25215 CR0193 (Rel-8, F) Correction to E-DPDCH gain
`R1-084453
`
`Nokia
`factor calculation
`The document was presented by Antti Hiltunen from Nokia on behalf of Agilent who has no RAN1 delegate.
`
`The CR shall apply to 25.214 as indicated on cover sheet and not 25.215 (CR numbering to be aligned).
`
`Discussion (Question / Comment): Ericsson and Samsung found some editorial that could be improved.
`Decision: Document is noted. CR shall be revised in R1-084526 (CR0523 to 25.214).  See action point HSPA 55/3
`
`
`
`
`Nokia
`Open issues with E-DPDCH scaling
`R1-084452
`The document was presented by Antti Hiltunen from Nokia and brings out some clarification on the two open issues
`related to E-DPDCH scaling, one when E-DPDCH transmission is using 4PAM modulation and another when E-DPCCH
`boosting is applied.
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`• RAN1 agrees on proposal 1 from 3.2 (E-DPDCH scaling when E-DPCCH boosting is applied).
`3.1 (E-DPDCH scaling when no DPDCH is configured and 4PAM modulation is applied) shall be discussed
`•
`offline.
`• Prepare CRs for Rel-7/8. See action point HSPA 55/4
`
`
`
`Impacts anslysis of Clarification of F-DPCH TPC Combining
`
`Huawei
`R1-084177
`Rule of cells in the same RLS
`The document was presented by Zongjie Wang from Huawei and brings out some simulation results, which show the
`impacts to the uplink throughput for the case of clarifying the DL power control timing for F-DPCH.
`
`Discussion (Question / Comment): Concerns were raised by Philips and Qualcomm w.r.t the justification of such
`simulation results for inclusion in the informative part of RAN1 specifications.
`Decision: Document is noted. If there is anything new compare to the agreed CR, it shall be revisited.
`
`
`
`Clarification of CPC procedures in HS-DSCH Serving Cell
`Huawei
`R1-084178
`Change Enhancements
`The document was presented by Zongjie Wang from Huawei and states the following proposal:
`
`
`
`• A UE shall resume the previous DRX status if the 2sec timer expires or activation time has passed and UE has not
`received HS-SCCH order.
`
`11 11
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2007 - Page 11
`
`

`

`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`
`Discussion (Question / Comment): Both Ericsson and NSN commented that such proposal should be addressed in RRC
`specification (RAN2) according the way it is written.
`Decision: Document is noted. Discussion off line to check if/how RAN1 specs are impacted.  See action point HSPA
`55/5
`
`R1-090002
`
`
`
`R1-084518
`
`25.224 CR0198R1 (Rel-7, F) Modification of HS-SICH sync
`description
`25.224 CR0199R1 (Rel-8, A) Modification of HS-SICH sync
`R1-084519
`description
`The document were presented by Li Rong from TD Tech.
`
`TD Tech
`
`TD Tech
`
`(R1-084157)
`
`(R1-084158)
`
`Discussion (Question / Comment): MCC to correct with the right Rel-8 specification version.
`Decision: Document is noted and both release CRs are agreed.
`
`
`
`R1-084209
`
`R1-084210
`
`25.224 CR0200 (Rel-7,F) Clarification of precision and
`quantization mode for coderate and beta of E-PUCH for
`1.28Mcps TDD EUL
`25.224 CR0201(Rel-8,A) Clarification of precision and
`quantization mode for coderate and beta of E-PUCH for
`1.28Mcps TDD EUL
`The document were presented by Ms Yanping Xing from CATT.
`Discussion (Question / Comment): There were concerns on the wording used “precision requirement” in RAN1
`specification.
`Decision: Document is noted. Revisit after offline discussion.  See action point HSPA 55/6
`
`CATT
`
`CATT
`
`
`
`
`
`
`
`25.225 CR0090 (Rel-8, B) E-UTRA measurements for TDD
`R1-084208
`
`TD Tech
`UTRA – E-UTRA interworking
`The document were presented by Li Rong from TD Tech. As multi-RAT terminals supporting E-UTRAN need to be able
`to perform measurements on E-UTRAN while in UTRAN, the paper defines E-UTRAN measurements for inclusion in TS
`25.225.
`
`Discussion (Question / Comment): According to CATT, these measurements are already in 25.225.
`Decision: Document is noted
`
`
`12 12
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2007 - Page 12
`
`

`

`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`
`
`R1-090002
`
`6.
`
`Maintenance of Evolved UTRA and UTRAN
`
`
`Rapporteur
`Rel.8 LTE open issue list
`R1-084507
`The document was presented by Sadayuki Abeta from NTT DoCoMo and lists remaining open issues that need to be
`finalized at this meeting since this is last meeting for Rel-8.
`
`Discussion (Question / Comment): Useful document to keep RAN1 focused in the upcoming discussions/decisions.
`Decision: Document is noted.
`
`
`
`Draft CR for 36.201 of Clarification of modular operation
`R1-084182
`The document was presented by Hakseong Kim from LGE
`
`LG Electronics
`
`
`
`Discussion (Question / Comment): Samsung requested some off line discussion for further check
`Decision: Document is noted. Revision shall be made in R1-084520. Consider whether modulo operation for non-integers
`can be avoided in 36211.
`
`36.211 CR0103 (Rel-8, F) Definition of the Modulo
`
`Samsung
`R1-084159
`Operation
`Above document wasn’t discussed, but – shall be joined with the revision of LGE’s contribution R1-084182.
`
`Friday 14th
`
`36.201 CR0002 (Rel-8, F) Clarification of modular
`R1-084520
`operation
`Decision: Document is noted and CR is agreed.
`
`
`Relay implementation
`
`LGE, Panasonic
`
`(R1-084182)
`
`
`Qualcomm Europe
`Specifying blank subframes in Rel-8
`R1-084385
`The document was presented by Juan Montojo from Qualcomm and is based on the discussion paper in R1-083817 that
`presented the advantages to define blank subframes in Rel-8 for enabling relay nodes to support Rel-8 UEs, namely:
`
` Avoiding to incur overhead related to the possible limitation of a relay node to not receive and transmit at the
`same time
`
` Enabling having an eNB-to-relay link (backhaul link) based on current Rel-8 air interface
`Discussion (Question / Comment): Philips wondered whether the terminology “blank subframes” might need to be
`improved, although the concept is fine.
`Alcatel Lucent requested clarification on the neighboring cell configuration and how UE get aware about blank subframe.
`Qualcomm requested off line discussion with RAN2 to address Alcatel Lucent concerns.
`Decision: Document is noted.
`
`Qualcomm Europe
`Support of Rel-8 UEs by LTE-A relays
`R1-084384
`The document was presented by Tingfang Ji from Qualcomm and proposes:
`
`
`
`•
`
`Introduction of blank subframes in Rel 8 for future compatibility
`o Blank subframes enable introduction of various type of relay nodes
`o Since blank subframes could be configured to be 0, this proposal does not preclude other relay designs
`that do not rely on blank subframes.
`
`• Blank subframes can be used for introduction of other non-legacy waveforms as well
`o E.g. new RS design to support 8Tx antennas and network MIMO
`Discussion (Question / Comment):
`
`13 13
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2007 - Page 13
`
`

`

`3GPP TSG RAN WG1 Meeting #55bis
`Ljubljana, Slovenia, 12 – 16 January, 2009
`
`Decision: Document is noted.
`
`R1-090002
`
`Nokia Siemens Networks,
`
`Backward compatible implementation of Relaying
`R1-084325
`Nokia
`The document was presented by Jari Lindholm from NSN and proposes to utilize the existing MBSFN subframes to
`support relaying as proponents believe that the introduction of blank subframes has severe impacts on current R8
`implementation and time-frame. The paper concludes that a flexible allocation of MBSNF subframes can enhance
`performance of both the access and backhaul link by better spacing the available transmission opportunities. If it is feasible
`for RAN2 to implement such slightly more flexible allocations without impact on the R8 timeline, it might be worth to
`consider this option.
`Discussion (Question / Comment): Extension of the existing MBSFN subframe is supported by Orange as well.
`Mr Chairman recalled to the group that the intention wasn’t to go at this stage into details but to get a good overview of
`where we’re and what proposals are around the table.
`Decision: Document is noted.
`
`
`Ericsson
`Efficient support of relaying through MBSFN subframes
`R1-084357
`The document was presented by Stefan Parkvall from Ericsson and concludes that, from a relaying perspective, there is no
`strong reasons for blanking and it is proposed to support relaying in LTE-Advanced by reusing the MBSFN subframes
`already present in Rel-8.
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`
`Motorola
`LTE signaling to support Relay operation
`R1-084412
`The document was presented by Robert Love from Motorola and discusses the operation of in-band Relays for LTE-
`Advanced and proposals that require the addition of new features in the Rel-8 specification and alternatively, solutions that
`are backwards compatible with current Rel-8 specification without requiring new features.
`
`As a conclusion, it is noted that having a bitmap to flexibly label each subframe as a MBSFN subframe or normal
`subframe would like allow more flexibility in the Relay design.
`
`Discussion (Question / Comment)