R1-083471
`
`
`
`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`Agenda item
`3
`Title:
` Final Report of 3GPP TSG RAN WG1 #54 v1.0.0
`
`
`(Jeju Island, South Korea, 18 – 22 August, 2008)
`Document for:
` Approval
`Source:
`
`MCC Support
`
`
`
`
`
`
`
`
`Fact Summary
`Meeting:
`Dates:
`Venue:
`Host:
`Attendees:
`Documents:
`
`
`3GPP TSG RAN WG1 #54
`18th through 22nd August, 2008
`The Shilla Jeju hotel in Jeju, SOUTH KOREA
`SAMSUNG Electronics
`155 delegates
`697 (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 2010 - Page 1
`
`

`

`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`
`Table of contents
`
`R1-083471
`
`
`Executive summary ......................................................................................................................................... 3
`1. Opening of the meeting ........................................................................................................................ 5
`1.1
`Call for IPR ....................................................................................................................................................... 5
`2.
`Approval of the agenda ......................................................................................................................... 5
`3.
`Approval of the minutes from previous meeting ............................................................................... 5
`4.
`Liaison statement handling .................................................................................................................. 6
`5. Maintenance of UTRA Release 99 – Release 8 ............................................................................. 13
`6. Maintenance of Evolved UTRA and UTRAN ................................................................................... 17
`6.1
`Corrections for TS 36.211 ............................................................................................................................ 17
`6.2
`Corrections for TS 36.212 ............................................................................................................................ 22
`6.3
`Corrections for TS 36.213 ............................................................................................................................ 28
`6.3.1
`Ad-hoc session on MIMO ....................................................................................................................... 39
`6.4
`Corrections for TS 36.214 ............................................................................................................................ 44
`6.5
`Corrections for TS 36.306 ............................................................................................................................ 45
`7.
`HS-PDSCH Serving Cell Change Enhancements .......................................................................... 46
`8.
`Dual-Cell HSDPA Operation on Adjacent Carriers ......................................................................... 47
`9.
`Enhanced CELL_FACH state in 1.28 Mcps TDD (UL/DL) ............................................................ 53
`10. Continuous Connectivity for packet data users for 1.28Mcps TDD ............................................. 53
`11. MIMO for 1.28Mcps TDD .................................................................................................................... 53
`12. Study Item on LTE-Advanced ............................................................................................................ 55
`13. Closing of the meeting ........................................................................................................................ 63
`Annex A: List of participants at RAN1 #54 .............................................................................................. 64
`Annex B: TSG RAN WG1 meetings in 2008/2009 ................................................................................ 65
`Annex C: List of CRs agreed at RAN1#54 .............................................................................................. 66
`Annex D: List of Outgoing LSs from RAN1#54 ...................................................................................... 74
`Annex E: List of Tdocs at RAN1 #54 ....................................................................................................... 76
`Annex F: List of actions ............................................................................................................................. 77
`
`
`
`2 2
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2010 - Page 2
`
`

`

`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`
`
`R1-083471
`
`Executive summary
`3GPP TSG WG RAN1 #54 meeting took place in Shilla Jeju Hotel, Jeju, SOUTH KOREA.
`
`The meeting started at 9:10 on Monday 18th August and finished at 17:00 on Friday 22nd August 2008.
`
`
`
`The week was scheduled as follows:
`
`• Monday: Common session on Agenda items 1, 2, 3, 4, 6, 6.4, 6.5 and 6.3.
`
`• Tuesday: Common session dedicated to corrections to TS36.213 (Agenda item 6.3).
`
`• Wednesday: Parallel sessions on Agenda items 5, 7, 8, 10 and 11 chaired by Dirk Gerstenberger and Agenda items
`6.2 and 6.1 chaired by Sadayuki Abeta.
`
`• Thursday morning: Common session on Agenda item 12 for LTE-Advanced.
`
`• Thursday afternoon: Parallel sessions; Continue discussions w.r.t LTE-Advanced in main meeting room chaired
`by Dirk Gerstenberger. Dedicated MIMO session chaired by Juho Lee
`
`• Friday morning: Common session on Agenda items 6.1 and 6.2.
`
`• 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 676, and those documents were categorized as followed.
`
`Agenda Item
`Liaison statement handling
`Maintenance of UTRA R99 – Rel8
`Maintenance of Evolved UTRA and UTRAN
`HS-PDSCH serving cell change enhancements
`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-Advanced
`
`Input
`Document
`41
`46
`399
`10
`36
`0
`3
`6
`135
`
`Discussed
`Document
`36
`40
`257
`5
`31
`
`3
`6
`25
`
`
`
`Note: The amount of documents includes those discussed during the email discussion session post meeting.
`
`3 3
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2010 - Page 3
`
`

`

`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`
`The following set of documents is missing. The corresponding contributions have not been handed over by companies.
`
`R1-083471
`
`
`
`
`
`R1-082808
`
`Support to co-existence of different UL/DL allocations for LTE TDD
`
`R1-082842
`
`On UE-specific CQI-reporting
`
`R1-082905
`
`On the PAPR/ESM properties between clustered DFT-S-OFDM and
`NxSC-FDMA
`
`R1-082909
`
`Consideration on TTI Bundling for LTE TDD
`
`R1-082984
`
`CQI reporting with TTI bundling or A/N repetition
`
`Alcatel Shanghai Bell,
`Alcatel-Lucent
`
`ZTE
`
`Spreadtrum
`Communications
`Spreadtrum
`Communications
`
`Panasonic
`
`R1-083057
`
`36.212 CR0040 (Rel-8, F) Introducing missing parameters into 36.212 Ericsson
`
`R1-083222
`
`Link Error Prediction for LTE-A
`
`Motorola
`
`R1-083254
`
`Considerations on Spectrum Aggregation in LTE-Advanced
`
`CHTTL, ITRI
`
`R1-083323
`
`Draft CR for 36.213 regarding DCI format1C
`
`R1-083355
`
`Update of TR 25.929 v0.0.1
`
`R1-083385
`
`SIB1 and SI-x TBS vs Number of Transmissions
`
`R1-083415
`
`36.211 CR0076 (Rel-8, F) Clarification on tree structure for CCE
`aggregation
`
`LGE
`
`TD Tech
`
`Motorola
`
`Ericsson
`
`4 4
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2010 - Page 4
`
`

`

`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`
`
`R1-083471
`
`Opening of the meeting
`1.
`Mr. Dirk Gerstenberger (RAN1 Chairman) welcomed the participants to the 54th RAN WG1 meeting and opened the
`meeting at 09:10.
`
`Juho Lee from Samsung Electronics welcomed the delegates 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#54 meeting
`R1-082770
`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#53bis meeting
`R1-082771
`The document was presented by Patrick Mérias.
`Discussion (Question / Comment): Main effort was focused in listing all “approved in principle” CRs from Warsaw’s
`meeting. They shall be further reviewed during the week.
`Decision: The document is noted and approved.
`
`MCC Support
`
`
`
`5 5
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2010 - Page 5
`
`

`

`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`
`
`Liaison statement handling
`4.
`Incoming LS
`
`R1-083471
`
`Uplink grant format in Random Access Response
`R1-082772
`The document was presented by Juan Montojo from Qualcomm.
`
`RAN2, Qualcomm
`
`= R2-083779
`
`Discussion (Question / Comment): RAN2 has basically decided that the MAC layer will deliver the 20 bits containing to
`the UL grant to the “lower layer” instead of 21bits. Some adjustments are required in RAN1 specifications reflecting it.
`Decision: Document is noted.
`
`
`Qualcomm Europe
`Handling of Uplink Grant in Random Access Response
`R1-083186
`The document (initially under AI 6.3) was presented by Juan Montojo from Qualcomm and proposes:
`
`• Proposal 1: Use 3 bit TPC field in RAR
`
`• Proposal 2: Use 10 bit RB assignment in RAR
`Discussion (Question / Comment): NSN commented that proposal 1 may require further discussion. On the other hand,
`proposal 2 may raise problem in case of 20MHz BW systems.
`Decision: Document is noted.
`
`Nokia Siemens Networks,
`PC of RACH message 3
`R1-083096
`Nokia
`The document (initially under AI 6.3) was presented by Jari Lindholm from NSN and details PC command on RACH
`response. The following statements are proposed:
`
`
`
`• The power control adjustment state of PUCCH is initialized to
`
`g
`
`)0(
`
`P
`∆=
`rampup
`
`δ+
`Msg
`
`2
`
` .
`
`• The power control adjustment state of PUSCH is initialized to
`applies only for non-contention based random access.
`
`f
`
`)0(
`
`
`
`(
`P
`α ∆⋅=
`rampup
`
`+
`
`δ
`2Msg
`
`)
`
` but this
`
`• A new PC formula with full PL compensation is introduced for message 3 transmission during contention based
`RA:
`P
`Msg
`∆
`
`_
`TARGET
`).(
`i
`f
`+
`
`Msg
`
`3
`
`_
`
`POWER
`
`+
`
`PL
`
`+
`
`,
`
`)(
`i
`
`=
`
`3
`
`,0
`
`preamble
`
`_
`
`PREAMBLE
`log
`10
`+
`10
`
`Msg
`
`3
`
`_
`_
`INITIAL
`))(
`(
`i
`M
`
`PUSCH
`
`RECEIVED
`))(
`(
`iTF
`∆+
`
`TF
`
`where the power control adjustment state is initialized to
`)0(
`
`f
`
`Msg
`
`3
`
`P
`∆=
`rampup
`
`δ+
`Msg
`
`2
`
`.
`
`• After successful contention resolution UE switches to the normal PUSCH PC formula with an insertion
`)(
`)(
`3 i
`i
`f
`f
`
`⋅=α
`
`Msg
`
`.
`
`Discussion (Question / Comment): In relation to the LS, NSN is more in favor of 4 bit TPC field in the grant.
`Decision: Document is noted.
`From the above set of contributions, agreement is as follows:
`
`•
`
`•
`
`10 bits for RB allocation
`
`3 bits with 2dB resolution for TPC
`
`Continue off line discussion to prepare the related CR in specifications in R1-083266 (Qualcomm) and the LS reply in R1-
`083267.
`
`6 6
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2010 - Page 6
`
`

`

`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`
`Friday 22nd
`
`R1-083471
`
`R1-083267
`
`DRAFT LS Reply to Uplink grant format in Random Access
`Response
`
`Qualcomm
`
`
`
`
`Qualcomm
`Handling of Uplink Grant in Random Access Response
`R1-083266
`The draft LS was presented by Sandip Sarkar from Qualcomm and informs RAN2 on a way forward to split the 20 bits
`allocated in the Random Access Response for signalling the UL grant with relevant CR attached in R1-083266.
`
`Discussion (Question / Comment): Nokia requested more time for finalizing the CR.
`Decision: Document is noted and is for email approval until 28/08.
`
`
`
`ICIC Signaling
`
`RAN2, Ericsson
`LS on ICIC Signalling
`R1-082773
`The document was presented by Ylva Jading from Ericsson and raised 2 questions:
`
`= R2-083785
`
`Q1: Is the existing measurement report, triggered when the neighbouring cell becomes offset better than the serving cell
`sufficient for ICIC in Rel-8?
`Q2: Can RAN1 indicate if a having triggers for both neighbouring cell becomes offset better than the serving cell and
`when neighbouring cell becomes offset worse than the serving cell would be sufficient for ICIC in Rel-8?
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`
`Huawei
`Proposed response to LS on ICIC signaling (R2-083875)
`R1-083031
`The document was presented by Brian Classon from Huawei and provides replies and considerations related to the issues
`raised in R1-082773.
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`Draft LS on additional RSRP trigger for ICIC
`R1-083252
`The document was presented by Ylva Jading from Ericsson.
`
`Ericsson
`
`(R1-083051)
`
`Discussion (Question / Comment): Huawei reported that the answer to Q1 was similar to Huawei’s view and commented
`that both answers could simply be “NO”.
`Decision: Document is noted.
`
`Necessary RSRP Information for UL and DL ICIC to be
`
`Alcatel-Lucent
`R1-083107
`provided by Layer 2
`The document was presented by Christian Gerlach from Alcatel-Lucent and concludes that the proposal replied by RAN2
`in R1-082773 seems not adequate for ICIC implementation. It has further been shown what kind of RSRP information in
`contrast is necessary to have sufficient information for UL and DL ICIC.
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`Proposed Response LS on RSRP Signalling for ICIC
`R1-083108
`Decision: Document is noted.
`
`Alcatel-Lucent
`
`
`
`
`
`Based on the above contributions, Mr Chairman decided to let the discussion continue off line (during the day) and see if
`more details can be agreed in providing response to RAN2 other than a simple “NO”. LS reply in R1-083265 (Ericsson)
`shall be drafted in that sense.
`
`
`
`
`
`7 7
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2010 - Page 7
`
`

`

`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`
`Monday 18th evening
`
`R1-083471
`
`
`Ericsson
`Draft LS on additional RSRP trigger for ICIC
`R1-083265
`The document was presented by Ylva Jading from Ericsson and provides RAN1 answers to RAN2:
`
`• Q1 answer: No, this will not be sufficient for ICIC purposes.
`
`• Q2 answer: Yes, as indicated above RAN1 would find it sufficient to have multiple trigger conditions for both
`neighbouring cell becoming offset better than the serving cell and when neighbouring cell becomes offset worse
`than the serving cell. RAN1 thinks that at least three additional trigger conditions for ICIC purposes should be
`possible to set if seen feasible from a RAN2 perspective.
`
`Discussion (Question / Comment): RAN3 shall be copied in the LS response.
`Decision: Document is noted and final LS is agreed in R1-083272
`
`
`
`ETWS
`
`Further questions on Earthquake and Tsunami Warning
`R1-082774
`System
`The document was presented by Sadayuki Abeta from NTT DoCoMo
`
`Discussion (Question / Comment): No actions to RAN1.
`Decision: Document is noted.
`
`RAN2, NTT DoCoMo
`
`= R2-083786
`
`
`
`Discussion papers
`
`36.213 CR0066 (Rel-8, F) Alignment of RAN1/RAN2 RACH
`(R1-082459)
`Ericsson
`R1-083138
`specification
`The document was presented by Stefan Parkvall from Ericsson and deals with a disalignment between the physical-
`random-access procedure in 36.213 Section 6 and the corresponding text in MAC specification 36.321.
`
`•
`
`•
`
`36.213 assumes that higher layers provide a preamble transmission power while 36.321 provides a target received
`power
`
`36.213 assumes that higher layers provide a random-access response window, something that is not provided
`according to 36.321.
`
`Discussion (Question / Comment):
`Decision: Document is noted. CR is agreed in principle and shall be merged into CR in R1-083266. Inform RAN2 that
`delta_preamble is assumed to be in MAC.
`
`LG Electronics, Ericsson,
`
`Alignment of L1/L2 PRACH power control specification
`R1-083203
`Qualcomm
`The document was presented by Dragan Vujcic from LGE. It’s the background for previous CR in R1-083138.
`
`Discussion (Question / Comment): Typo error (minus sign should be +) in PRACH output power formula.
`Decision: Document is noted.
`
`LG Electronics, Ericsson,
`
`[DRAFT] LS on PRACH preamble power offset
`R1-083204
`Qualcomm
`The document was presented by Dragan Vujcic from LGE and captures the decisions on PRACH power control formula.
`Discussion (Question / Comment): Panasonic requested to add an action to RAN4 to apply Cubic Matrix also to the
`preamble.
`Decision: Document is noted and shall be revised in R1-083269.
`
`Thursday 21st
`
`[DRAFT] LS on PRACH preamble power offset
`R1-083269
`The document was presented by Dragan Vujcic from LGE.
`
`LG Electronics, Ericsson,
`Qualcomm
`
`(R1-083204)
`
`8 8
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2010 - Page 8
`
`

`

`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`
`Discussion (Question / Comment):
`Decision: Document is noted. Final LS is agreed in R1-083365.
`
`
`R1-083471
`
`(R1-082910)
`LGE
`Discussion on the SI transmission
`R1-083248
`The document was presented by Joon-Kui Ahn from LGE and shows evaluation results on the payload size for SI-1 and
`discusses the possible approaches for the SI-1 payload size setting. Required number of retransmissions of SI-x (x>1) and
`the current RAN2 assumption on the HARQ process for BCCH reception are also discussed.
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`Remaining issues on SIB transmission
`R1-083033
`The document was presented by Ms (…) from Huawei
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`Huawei
`
`
`
` (R1-083212)
`Motorola
`SIB1 and SI-x TBS vs Number of Transmissions
`R1-083258
`The document was presented by Robert Love from Motorola and proposes a maximum TBS for SIB1 and SI-x and gives
`tables for different SI-x TBS and the corresponding number of transmissions required for 1% BLER based on 1TX x 2RX
`downlink antenna deployment and the ETU 30km/h channel.
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`DCI Format 1C and 1.4, 3, 5, and 10 MHz link performance Motorola
`R1-083213
`Document has not been formally reviewed as it’s the background information to R1-083258.
`
`
`
`Draft LS Response to LS on information about new PDCCH
`R1-083257
`Format 1C and LS on SI Scheduling
`The document was presented by Robert Love from Motorola.
`Discussion (Question / Comment): LGE requested extra time for further checking of the draft LS. Typo shall be
`corrected in relation to ETWS spelling.
`Decision: Document is noted and shall be revisited later on.
`
` (R1-083214)
`
`Motorola
`
`
`
`Nokia, Nokia Siemens
`Separate frequency layer for CSG cells
`R1-083264
`
`Networks
`The document was presented by Asbjørn Grøvlen from Nokia and proposes a solution for distinguishing the CSG cells in
`the frequency domain, requiring no changes to the existing physical layer specification in al1 as well as in higher layers.
`
`Proposal: Do not modify the physical layer specifications and stay with the 504 PCIs as they are today. Separate the CSG
`and non-CSG cells in the frequency domain by offsetting the CSG cells by 100 kHz. Indicate RAN2 and RAN4 that the
`CSG and the non-CSG cells can be separated in frequency domain and thus the same PCI space can be used by both
`layers.
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`Nokia, Nokia Siemens
`Physical layer support for CSG
`R1-083081
`Networks
`The document was presented by Asbjørn Grøvlen from Nokia and states that reserving a subset of the existing physical
`layer cell IDs for CSG should be sufficient given the CSG mobility functionality that will be supported for release 8
`
`
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`9 9
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2010 - Page 9
`
`

`

`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`
`
`R1-083471
`
`
`Nortel
`Extension of the cell-ID space
`R1-083139
`The document was presented by Hua Xu from Nortel and compares different options for extending the Physical layer cell
`Identity (PCI) for E-UTRA.
`
`Discussion (Question / Comment): One company commented that the proposed scheme (Nortel’s conclusion) has not
`been agreed by RAN1.
`Decision: Document is noted.
`
`Qualcomm Europe
`Analysis of PCI extension schemes
`R1-083160
`The document was presented by Juan Montojo from Qualcomm and proposes:
`
`
`
`• Once UE finds timing through PSS, UE is to test two hypotheses of SSS location
`o This is similar to blind CP length detection operation in UE
` Blind CP detection is anyway needed in any searcher implementation and its performance is
`very reliable
`o This is also similar to detecting FS1 from FS2 by using relative location of PSS/SSS
`In FS1, PSS and SSS are next to each other
`
`
`
`
`In FS2, PSS and SSS are separated by two OFDM symbols
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`ZTE, CHTTL
`Solutions to Issues on CSG-cell Identification
`R1-082830
`The document was presented by (…) from ZTE and concludes with the following statements:
`
`
`
`• Fairly large identification space with the ability to extend to an even larger identification space without changing
`the air interface protocol, so the knowledge of potential maximum number of CSG-cells per macro-cell is not so
`critical at this stage;
`
`•
`
`•
`
`It has minimum impact to LTE Rel-8 because both SCH signalling and the cell identification philosophy for non-
`CSG-cell keeps unchanged. In addition, the cell-search and initial synchronization to CSG-cell when UE powers
`up in an CSG-cell is also not effected because in this case UE only needs to know cell-ID on SCH;
`
`It keeps the implementation complexity in control when identifying one CSG-cell from a large identification
`space;
`
`• Compatible with CSG-cell that is either semi-statically or dynamically controlled by network;
`
`• Applies to both FDD and TDD in the same way.
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`(R1-081888)
`LGE
`CSG Flag in Physical Cell ID
`R1-082911
`The document was presented by Seunghee Han from LGE and discusses options of PCI extension and reservation for CSG
`cells via technical analysis and simulation results. It concludes as follows;
`
`• PCI reservation
`o The number of PCIs to be reserved for CSG cells is 45 and option C in chapter 4 (reservation to avoid
`ambiguity and collision) is preferable.
`
`• PCI extension
`o The option 1 in chapter 3 (extension by swapping SS) is preferable.
`
`10 10
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2010 - Page 10
`
`

`

`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`As a conclusion of this topic, Mr. Chairman raised the question: does RAN1actually need to modify the Cell search or is
`the current Rel-8 implementation good as it is?
`
`R1-083471
`
`No agreement at this stage for introducing a new layer 1 solution. The topic shall be revisited in case of feedback from
`RAN2 that may come up during the week.
`
`Friday 22nd
`
`
`Qualcomm Europe
`Evaluation of PCI collision for CSG
`R1-083366
`The document was presented by Juan Montojo from Qualcomm and shows a study to analyze the PCI collision probability
`for different home eNB densities and different number of PCIs available for CSG cells.
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`R1-083405
`
`Draft LS on CSG cell identification
`
`The document was presented by Juan Montojo from Qualcomm.
`
`Qualcomm Europe, Nokia,
`Nokia Siemens Networks,
`Ericsson
`
`
`
`Discussion (Question / Comment): Supported by Samsung and Huawei as well.
`Decision: Document is noted. RAN3 shall be in copy. Final LS is agreed in R1-083424
`
`
`
`
`Philips, NXP
`Effect of false positive UL grants
`R1-082792
`The document was presented by Matthew Baker from Philips and highlights two main problems arising from falsely
`detected PDCCHs.
`
`• False activation of an UL SPS transmission
`o Proposal: the UE to receive two PDCCHs in the same subframe before activating an SPS. Since the UE
`would typically try blind decoding all possible PDCCHs within a given search space, there is no
`practical difficulty in receiving sufficient PDCCHs. One message would need to have the SPS-C-RNTI
`encoded in the CRC. Without a correctly received second message (with either SPS-C-RNTI or C-
`RNTI) the SPS message would be rejected.
`
`• False detection of a dynamic UL grant
`o Proposal: since most of the interference is generated by UEs with no data which send only a padding
`BSR in the full granted resources, it’s proposed that any such transmissions should use a minimal
`resource and transport block size derived from the received grant.
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`Remaining issues on PDCCH for semi-persistent
`Huawei
`R1-083032
`scheduling
`The document was presented by (…) from Huawei and provides considerations on:
`Q1: Is the existing measurement report, triggered when the neighboring cell becomes offset better than the serving cell
`sufficient for ICIC in Rel-8?
`
`
`
`• Response: it is not sufficient for ICIC that the UE transmits a single measurement report.
`Q2: Can RAN1 indicate if a having triggers for both neighboring cell becomes offset better than the serving cell and when
`neighboring cell becomes offset worse than the serving cell would be sufficient for ICIC in Rel-8?
`
`• Response: two triggers increase the load without significant benefit, as still cannot accurately follow the
`fluctuation of channel condition for the UE in the ICIC area. So introducing an event for neighboring cell
`becomes offset worse than the serving cell is NOT preferred for RAN1.
`
`11 11
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2010 - Page 11
`
`

`

`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`
`Finally, RAN2 has discussed a solution in which the UE starts periodic reporting based on event that neighboring cell
`becomes offset better than the serving cell (event-triggered periodic reporting), and the RRC measurement events are
`restricted based on information from MAC. This solution would cause significant complexity in RAN2 specifications, but
`could be introduced if deemed necessary by RAN1 analysis.
`
`R1-083471
`
`• Response: the event-triggered periodic reporting is necessary for ICIC and several methods should be considered
`for reducing the signalling overhead.
`
`Discussion (Question / Comment):
`Decision: Document is noted. This shall be revisited depending on feedback from RAN2 on LS in R1-082766 (from
`RAN1#53bis Warsaw’s meeting).
`
`
`
`Incoming LS received during the week
`
`= R2-084764
`RAN2, Ericsson
`LS on considerations on transport block sizes for VoIP
`R1-083346
`The document was presented by Daniel Larsson from Ericsson. RAN1 is tasked to consider the TB sizes as proposed in its
`finalization of TBS tables for LTE release 8 specifications, and if possible to make appropriate changes to improve support
`for VoIP.
`
`Discussion (Question / Comment):
`Decision: Document is noted.
`
`
`
`12 12
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2010 - Page 12
`
`

`

`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`
`
`R1-083471
`
`Maintenance of UTRA Release 99 – Release 8
`
`
`
`5.
`FDD
`
`R1-083071
`
`25.212 CR0271 (Rel-7,F) Correction to the table name and
`the quoted name
`25.212 CR0272 (Rel-8,A) Correction to the table name and
`R1-083072
`the quoted name
`The document was presented by Wang Zongjie from Huawei.
`
`HUAWEI
`
`HUAWEI
`
`
`
`
`
`Discussion (Question / Comment): MCC to correct WI code. Enhanced Uplink feature seems more appropriate. Version
`of specification in R1-083072 shall be v8.2.0.
`Decision: Documents are noted and both CRs are agreed.
`
`
`
`25.213 CR0097 (Rel-7, F) Restricted Beta Factor
`R1-083022
`
`Ericsson
`Combinations for EUL
`The document was presented by Johan Bergman from Ericsson and clarifies that the highest E-DPDCH amplitude factors
`should only be used for SF2 in a 2xSF2+2xSF4 configuration when E-DPCCH boosting is applied.
`
`Discussion (Question / Comment):
`Decision: Document is noted. CR shall be revisited after off line discussion.
`
`Friday 22nd
`
`25.213 CR0097r1 (Rel-7, F) Restricted Beta Factor
`R1-083393
`Combinations for EUL
`Decision: Document is under email approval until 28/08.
`
`
`
`Ericsson
`
`(R1-083022)
`
`
`Ericsson
`Improved EUL power control at UE power limitation
`R1-083023
`The document was presented by Johan Bergman from Ericsson and provides approaches for improved EUL power control
`at power limitation in Rel-8.
`
`.Discussion (Question / Comment):
`
`Decision: Document is noted. RAN1 agrees on having both solutions, configurable βed,k,min and freeze OLPC target.
`
`Draft an LS for RAN2 (for making βed,k,min configurable) and RAN3 (for introducing the OLPC related NodeB signalling
`to the RNC) and discuss further whether draft CRs can be provided too.
`
`
`
`
`HUAWEI
`Enhanced Pilot Reference for E-DPCCH Power Boosting
`R1-083073
`The document was presented by Wang Zongjie from Huawei and identifies problem of power boosting E-DPCCH based
`pilot reference processing. From simulation results, inconsecutive E-DCH transmission with E-DPCCH power boosting
`affects the channel estimation results so as to reduce the peak data rates. Thus it is proposed to study the scheme of E-
`DPCCH preamble and postamble which seems to be a potential approach to solve the problem.
`Discussion (Question / Comment): Nokia commented that such implementation may have big impacts to UE.
`Decision: Document is noted. Based on the discussion, RAN1 doesn’t agree to this proposal.
`
`
`
`TDD
`
`R1-082854
`
`25.221 CR0158 (Rel-5, F) Modification of the timing
`requirement between HS-SCCH and HS-PDSCH for
`1.28Mcps TDD
`
`ZTE, RITT, CATT, TD-
`TECH, Spreadtrum
`Communications
`
`
`
`13 13
`
`IPR2018-01476
`Apple v. INVT
`INVT Exhibit 2010 - Page 13
`
`

`

`3GPP TSG RAN WG1 Meeting #54bis
`Prague, CZ, 29 September – 3 October, 2008
`
`
`R1-083471
`
`R1-082855
`
`R1-082856
`
`R1-082857
`
`ZTE, RITT, CATT, TD-
`25.221 CR0159 (Rel-6, A) Modification of the timing
`TECH, Spreadtrum
`requirement between HS-SCCH and HS-PDSCH for
`Communications
`1.28Mcps TDD
`ZTE, RITT, CATT, TD-
`25.221 CR0160 (Rel-7, A) Modification of the timing
`TECH, Spreadtrum
`requirement between HS-SCCH and HS-PDSCH for
`Communications
`1.28Mcps TDD
`ZTE, RITT, CATT, TD-
`25.221 CR0161 (Rel-8, A) Modification of the timing
`TECH, Spreadtrum
`requirement between HS-SCCH and HS-PDSCH for
`Communications
`1.28Mcps TDD
`The documents were presented by (…) from ZTE and provides a modification of the timing limitation so that the HS-
`PDSCH is always on the following subframe of the associated HS-SCCH. The change is not backward compatible under
`the protocol point of view. In realistic network, the 1.28Mcps TDD UE will implement the change from Rel-5, thus the
`resultant interoperability