TSGR1-02-0927
`
`TSG-RAN Working Group 1 meeting No. 27
`July 2-5, Oulu, Finland
`
`
`Agenda Item:
`
`Source:
`
`Title:
`
`Document for: Approval
`
`_________________________________________________________________________
`
`Revised Minutes for 3GPP TSG-RAN WG1 26h Meeting
`
`-
`
`Secretary
`
`Revised minutes of TSG RAN WG1 #26meeting
`
`
`/*** Rvised points
` Item number 140 (T-doc R1-02-0744) had been classified wrongly. This was correcetd.
` Note numbers were correceted with respect to section 7, item No. 144 and 145. (*5), (*6)  (*4),(*5)
` Note (*26) in section 5 was slightly modified.
`***/
`
`Meeting start: May 13th, 2002, in Gyeongju, Korea
`
`Day 1, started at 09.08
`
`1. Opening of the meeting
`
`
`
`
`
`
`
`
`The chairman, Mr. Antti Toskala (Nokia), opened the meeting.
`
` Mr. Ju Ho Lee (Samsung) welcomed the delegates to the meeting on behalf of hosting company (Samsung).
`
`Social Event (sightseeing) was scheduled on Day2 afternoon.
`
`
`
`
`
`
`
`
`
`
`
`
`2. Approval of agenda
` R1-02-0689 Draft Agenda for TSG RAN WG1 meeting No.26
` Chairman made a brief introduction of the agenda on the screen.
` Agenda was approved with no comments.
` Chairman stated that from now on T-doc number should be asked for with title of the document in order for Chairman to
`
`be able to plan the meeting beforehand. He also suggested that the spare T-doc numbers should be used first.
`
`
`3. Identification of the incoming liaison statements and actions in the answering
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` (09:08 - 09:12)
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` (09:12 - 09:16)
`
` No.
`
`Title
`
`Source To/Cc Tdoc No. Contact point
`
`Notes
`
`1
`
`2
`
` Liaison Statement on BLER Usage for
` HSDPA
` Liaison Statement on Definition of
` UTRAN Transmitted carrier power
`
`RAN
`WG3
`RAN
`WG4
`
`TO R1-02-0691
`(R3-021120)
`TO R1-02-0815
`(R4-020735)
`
`Nortel
`
` (*1)
`
`Fujitsu
`Panasonic
`
` (*2)
`
`Day 1 09:17-09:27
`
`Day 2 18:02-18:21
`
`
`
`
`
`
`
`
`
`
`
`
`(*1) Ms. Sarah Boumendil (Nortel) presented this LS.
` In the current RRC specification (Rel-5), POhsdsch (default Power Offset between HS-PDSCH and
`
` P-CPICH/S-CPICH) and BLER threshold are signalled to the UE as part of the Measurement Feedback Info IE.
`
`
` RAN WG3 was asking following questions.
` Q1. Does the NodeB need to know the BLER threshold and the POhsdsch parameters and for what purpose?
`
`
` Q2. What is the range and the granularity for these two parameters?
`
` Ms. Sarah Boumendil stated that there would be no need to provide the Node B with a BLER threshold information
`
` because we have modified the CQI reporting such that the algorithm in the UE to derive the reported CQI uses a fixed
`
` BLER of 10%. In that sense the parameter should be removed from RRC. She added that however Node B has to be
`
` aware of POhsdsch, power offset between HS-PDSCH and P/S-CPICH in order to interpret the CQI report. Regarding
`
`- 1 -
`
`IPR2021-00908 Honeywell Exh. 1009 - Page 1 of 37
`(Honeywell International, Inc., et al. v. 3G Licensing S.A.)
`
`

`

` Q2 we need to have further discussion.
`
` Chairman asked Ms. Sarah Boumendil to draft an answer LS to RAN WG3. Eventually the answer LS was drafted in
`
` R1-02-0805 and approved in R1-02-0827 on Day2 evening. (See No. 141)
`
`(*2) Panasonic presented this LS.
`
` RAN WG4 seems to be having a problem with the definition of UTRAN Transmitted carrier power and wanted us to
`
` correct the definition of it. Discussion was made on following 2 points.
`
`
`- It is not clear what exactly the problem is with the current definition. Do we have any serious problem ?
`- It is not clear what their suggestion (" the setting of ..") means.
`
`
`
` Finally chairman suggested to see the actual CR starting with R99 correction which will be prepared by Panasonic or
`
` Fujitsu. He invited people to have a chat with their RAN WG4 colleagues to see how serious the issue is. Eventually CR
`
` was drafted in R1-02-0826. This CR was discussed on Day4 but was not approved. (See No. 40)
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`- 2 -
`
`IPR2021-00908 Honeywell Exh. 1009 - Page 2 of 37
`(Honeywell International, Inc., et al. v. 3G Licensing S.A.)
`
`

`

`4. Change Requests for WG1 Release –99 & Release-4 specifications
`
`
`No. R CR rev TS
`
`Tdoc
`
`Title
`
`Cat Source Conclusion Notes
`
`3
`
`4 072
`
`- 25.222 R1-02-0396
`
`4
`
`5 073
`
`- 25.222 R1-02-0396
`
`5
`
`4 087
`
`- 25.224 R1-02-0397
`
`6
`
`5 088
`
`- 25.224 R1-02-0397
`
`7 99 070 1 25.222 R1-02-0445
`
`8
`
`4 071 1 25.222 R1-02-0445
`
`9
`
`5 077
`
`- 25.222 R1-02-0445
`
`10 99 077
`
`- 25.221 R1-02-0732
`
`11 4 078
`
`- 25.221 R1-02-0732
`
`12 5 080 1 25.221 R1-02-0732
`
`13 4 079
`
`- 25.221 R1-02-0733
`
` Correction to addition of padding
` zeros to PICH in 1.28 Mcps TDD
`
` Correction to addition of padding
` zeros to PICH in 1.28 Mcps TDD
` Clarification on power control and
` TxDiversity procedure for 1.28 Mcps
` TDD
` Clarification on power control and
` TxDiversity procedure for 1.28 Mcps
` TDD
` Second stage interleaving and
` physical channel mapping
`
` Second stage interleaving and
` physical channel mapping
`
` Second stage interleaving and
` physical channel mapping
` Clarification of shared channel
` functionality for TDD
`
` Clarification of shared channel
` functionality for TDD
`
` Clarification of shared channel
` functionality for TDD
` Clarification of shared channel
` functionality for TDD
`
`Siemens Approved
`
`(*1)
`
`Day 1 09:37-09:38
`
`Siemens Approved
`
`(*2)
`
`Day 1 09:39-09:39
`
`IPWireless
`Siemens
`
`Approved
`
`(*3)
`
`Day 1 09:40-09:41
`
`F
`
`A
`
`F
`
`A
`
`F
`
`A
`
`A
`
`F
`
`A
`
`Siemens Approved
`
`(*4)
`
`A
`
`F
`
`Day 1 09:42-09:45
`
`Siemens Approved
`
`(*5)
`
`14 5 082
`
`- 25.221 R1-02-0733
`
` Clarification of shared channel
` functionality for TDD
`
`15 99 074
`
`- 25.222 R1-02-0734 Zero padding for TFCI
`
`16 4 075 1 25.222 R1-02-0734
`
`17 5 076 1 25.222 R1-02-0734
`
`18 4 085
`
`- 25.222 R1-02-0734
`
`19 5 086
`
`- 25.222 R1-02-0734
`
` Zero padding for TFCI
` (3.84Mcps)
`
` Zero padding for TFCI
` (3.84Mcps TDD)
`
` Zero padding for TFCI
` (1.28Mcps TDD)
`
` Zero padding for TFCI
` (1.28Mcps TDD)
`
`20 99 015
`
`- 25.201 R1-02-0595 Downlink bit mapping
`
`A
`
`F
`
`A
`
`Day 1 09:45-09:46
`
`A
`
`Panasonic Approved
`
`(*6)
`
`F
`
`A
`
`F
`
`Day 1 09:47-09:48
`
`21 4 016
`
`- 25.201 R1-02-0595 Downlink bit mapping
`
`A
`
`Ericsson Approved
`
`(*7)
`
`22 5 017
`
`- 25.201 R1-02-0595 Downlink bit mapping
`
`23 99 151
`
`- 25.211 R1-02-0596 Downlink bit mapping
`
`A
`
`F
`
`Day 1 11:06-11:30
`
`24 4 152
`
`- 25.211 R1-02-0596 Downlink bit mapping
`
`A
`
`Ericsson Approved
`
`(*7)
`
`25 5 153
`
`- 25.211 R1-02-0596 Downlink bit mapping
`
`26 99 134
`
`- 25.212 R1-02-0597 Downlink bit mapping
`
`A
`
`F
`
`Day 1 11:06-11:30
`
`27 4 135
`
`- 25.212 R1-02-0597 Downlink bit mapping
`
`A
`
`Ericsson Approved
`
`(*7)
`
`28 5 136
`
`- 25.212 R1-02-0597 Downlink bit mapping
`
`A
`
`Day 1 11:06-11:30
`
`- 3 -
`
`IPR2021-00908 Honeywell Exh. 1009 - Page 3 of 37
`(Honeywell International, Inc., et al. v. 3G Licensing S.A.)
`
`

`

`No. R CR rev TS
`
`Tdoc
`
`Title
`
`Cat Source Conclusion Notes
`
`29 99 051 1 25.213 R1-02-0385 Downlink bit mapping
`
`F
`
`30 4 052 1 25.213 R1-02-0385 Downlink bit mapping
`
`A
`
`Ericsson Approved
`
`(*7)
`
`31 5 053 1 25.213 R1-02-0385 Downlink bit mapping
`
`32 99 143 1 25.211 R1-02-0539
`
`33 4 144 1 25.211 R1-02-0539
`
`34 5 149 1 25.211 R1-02-0539
`
`35 99 046 2 25.225 R1-02-0820
`
`36 4 047 2 25.225 R1-02-0820
`
`37 5 050 2 25.225 R1-02-0820
`
`38 5 265 1 25.214 R1-02-0778
`
`39 5 258
`
`- 25.214 R1-02-0641
`
` SCCPCH structure with STTD
` encoding
`
` SCCPCH structure with STTD
` encoding
`
` SCCPCH structure with STTD
` encoding
` Clarification of UE
` measurements Applicability
`
` Clarification of UE
` measurements Applicability
`
` Clarification of UE
` measurements Applicability
` Definition of Qth threshold
` parameter in SSDT
` Correction on the physical
` random access procedure
`
`A
`
`F
`
`Day 1 11:06-11:30
`
`A
`
`Nokia
`
`Approved
`
`(*8)
`
`A
`
`F
`
`A
`
`A
`
`C
`
`Day 1 11:30-11:33
`
`Siemens
`Nokia
`IPWireless
`InterDigital
`
`Approved
`
`(*9)
`
`NEC
`Fujitsu
`
`Approved
`
`Day 3 16:15-16:19
`
`(*10)
`
`Day 3 19:17-19:20
`
`F Mitsubishi LS to be sent
`
`(*11)
`
`Day 3 19:21-19:50
`
`(*12)
`
`Day 4 14:08-14:20
`
`40 5 XXX
`
`- 25.215 R1-02-0826
`
` Corrections to the definition of
` UTRAN transmitted carrier power
`
`F
`
`Fujitsu
`Panasonic
`
`Rejected
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`(*1) Mr. Andreas Höynck (Siemens) presented this pair of CRs.
`
` When the number of bits available to a PICH in a radio frame is greater than the number of actual PICH bits used for
`
` paging indicators, then padding zeros are added. However the function for the addition of the padding zeros is
`
` incorrectly specified for 1.28 Mcps TDD. This CR proposed to correct this error. The corresponding CR for 3.84Mcps
`
` TDD had already been approved in RAN WG1#24 in R1-02-0338 (IPWireless).
`
` The current CR had been already presented in RAN WG1#25 meeting and agreed in principle. Nothing has been
`
` modified since then. This was presented in this meeting for the final approval.
`
` This pair of CRs was approved without any comments.
`(*2) Mr. Andreas Höynck (Siemens) presented this pair of CRs.
`
` This CR proposed some clarification on power control and TxDiversity procedure for 1.28 Mcps TDD in order to align
`
` the other RAN WG1 specifications and to avoid redundant information in different WGs.
`
` The current CR had been already presented in RAN WG1#25 meeting and agreed in principle. Nothing has been
`
` modified since then. This CR was presented in this meeting for the final approval.
`
` This pair of CRs was approved without any comments.
`(*3) Mr. Martin Beale (IPWireless) presented this set of CRs.
`
` This was the revision of R1-02-0339 which had already been provided in RAN WG1#24 meeting. The current CR had
`
` been presented in RAN WG1#25 meeting and agreed in principle. Nothing has been modified since then. This was
`
` presented in this meeting for the final approval.
`
` This set of CRs was approved without any comments.
`(*4) Mr. Andreas Höynck (Siemens) presented this set of CRs.
`
` This CR was just proposing to replace the direct reference to the releases (e.g. R99, Rel-4, etc) with "this version of the
`
` specification". This CR had been presented in RAN WG1#25 in R1-02-0398 and agreed in principle. As there had been
`
` a request from MCC to separate 1.28Mcps TDD part into different CR, the original T-doc was modified accordingly.
`
` This T-doc contained those CRs that were related to 3.84Mcps TDD. This set of CR was approved with no comments.
`(*5) Mr. Andreas Höynck (Siemens) presented this pair of CRs.
`
` This CR was originally packed in CR 079 and CR 080 in T-doc R1-02-0398. The current T-doc contained those CRs
`
` that were related to 1.28Mcps TDD compared to R1-02-0732. In addition to the modification done for 3.84Mcps TDD,
`
` this CR proposed to make some clarifications to the DSCH UE selection via the midamble or the TFCI and also to the
`
` TPC and SS commands.
`
` This pair of CRs was approved with no comments.
`(*6) Mr. Akihiko Nishio (Panasonic) presented this set of CRs.
`
` This CR proposed to clarify the coding method for TFCI in case where TFCI bit number is less than 10bits or 5bits.
`
` Following sentence was proposed to be added.
`
`
`"If the TFCI consists of less than 10[5] bits, it is padded with zeros to 10[5] bits, by setting the most significant bits to zero"
`
` This CR had already been presented in RAN WG1#25 meeting in R1-02-0584 and agreed in principle there. The current
`
` T-doc contained the revisions that had been done according to the request from MCC to separate 3.84Mcps TDD and
`
`- 4 -
`
`IPR2021-00908 Honeywell Exh. 1009 - Page 4 of 37
`(Honeywell International, Inc., et al. v. 3G Licensing S.A.)
`
`

`

` 1.28Mcps TDD. This set of CRs was approved with no comments.
`
`
`/*** Day 1 Coffee break 10:26 - 11:04 ***/
`
`(*7) Mr. Dirk Gerstenberger (Ericsson) presented this set of CRs.
`
`
` This set of CRs had already been presented in RAN WG1#25 meeting in Paris. The decision had been postponed to this
`
`
` meeting. Those CRs for TS 25.213 had been slightly modified to reflect the comment made on the reflector but no
`
`
` modification had been made for other CRs since RAN WG1#25.
`
`
` There were a couple of concerns raised on CR 25.211 from NEC (The term "symbol" is not clear hence it should be
`
`
` removed from section 5.3.1.1.1.) and Mitsubishi (insertion of "DTX" in section 5.3.3.10 is confusing.). However
`
`
` Chairman stated that those concerns were not essential and there would be almost no room for misunderstanding
`
`
` with the current proposed texts even though they were not necessarily the best possible one. Since there were no other
`
`
` comments made for this set of CRs, chairman concluded that these CRs as approved. He added that if some people felt
`
`
` the real necessity for the revision then they should go directly to the proponent during this week.
`
`(*8) Mr. Markku Tarkiainen (Nokia) presented this set of CRs
`
`
` This CR was the revision of R1-02-0312 which had been presented and agreed in principle in RAN WG1#25 meeting.
`
`
` The actual contents of the CR was identical to R1-02-0312. In this version, the reasoning in the cover sheet had been
`
`
` refined.
` The set of CRs was approved with no comments. The "current version of the spec" in the coversheet would be
`
`
`
`
` corrected by the secretary from "3.a.0" to "3.10.0".
`
`
` /*** Mr. Markku Tarkiainen announced that Nokia had withdrawn R1-02-0313 that had been provided in the last meeting. ***/
`
`(*9) Mr. Andreas Höynck (Siemens) presented this set of CR.
`
`
` The original CRs had already been reviewed in RAN WG1#25 in R1-02-0375. This CR proposed to clarify for each UE
`
`
` measurement, in which RRC state it can be requested from the mobile and on which type of cell (intra/inter frequency).
`
`
` The same clarification had already been proposed for FDD mode and approved in TSG RAN #15.
`
`
` The current version was the update of R1-02-0375. It was confirmed that the update was done to be in line with what
`
`
` had been done on the FDD mode side.
`
`
` This set of CRs was approved with no comments.
` (*10) Fujitsu presented this CR.
`
`
` This CR was essentially identical to CR 25.214-234r1 in R1-02-0500 which had been approved in RAN WG1#24
`
`
` meeting. Small modification was made in order to be in line with Rel-5 specification. (R1-02-0500 had been made
`
`
` based on Rel-4 specification as there had not been any Rel-5 specifications in RAN WG1 at the time of RAN WG1#24.)
`
`
` This CR was approved with no comments.
` (*11) Mr. Vincent Belaiche (Mitsubishi) presented this paper.
`
`
` During the PRACH ramp-up procedure the UE has to listen to the AICH on the DL. In case the FACH has a
`
`
` measurement occasion, the UE may need simultaneously to decode the AICH and to perform a measurement on another
`
`
` radio frequency channel, possibly of another RAT. Depending on the UE measurement capability there may be a
`
`
` conflict. The same situation occurs in UL. A conflict can possibly happen between a measurement occasion and either a
`
`
` PRACH preamble or a message. This CR (Rel-5 only) proposed to correct the PRACH procedure in order to avoid
`
`
` conflicts when this would lead to a too significant degradation of the measurements.
`
`
` Mr. Ville Steudle (Nokia) commented that this is an issue to be checked not only by RAN WG1 but also by RAN WG2
`
`
` (RRC spec) and RAN WG4 (measurement).
`
`
` Ms. Evelyne Le Strat (Nortel) questioned why this CR was only for Rel-5 and not for R99 and Rel-4 ?
`
`
` Mr. Vincent Belaiche answered that Mitsubishi was ready to provide R99 and Rel-4 CRs if RAN WG1 people agreed
`
`
` on that however Mitsubishi considered that it would be a bit difficult to have R99 CR on this issue mainly because the
`
`
` problem identified here was depending on the network configuration and therefore it may not happen always. So in that
`
`
` sense it may not necessarily be reasonable to have R99 CR on this issue at this stage. Chairman agreed with this answer
`
`
` and he also thought it would be tricky to have R99 CR on this issue approved in TSG RAN. He said that we could not
`
`
` say that this is an essential correction.
`
`
` There was a also a remark questioning whether the fix proposed in this CR does really solve the problem.
`
`
` In the end, Chairman suggested to send LS to RAN WG2 and RAN WG4 in order to ask their opinion on this topic. He
`
`
` suggested the whole paper, including the explanatory part and proposed CR had better be attached to the LS. Chairman
`
`
` invited Mr. Vincent Belaiche to draft a LS, with the current paper being attached. He said that it should also be
`
`
` mentioned in the LS that RAN WG1 is considering this issue for Rel-4 or Rel-5 and not for R99.
`
`
` Ms. Evelyne Le Strat remarked that the objective of the LS is to discuss the matter with other groups so that there is an
`
`
` evaluation of the problem, how severe it is and in which cases it appears. She said that having the views of other groups
`
`
` we can have a general decision whether we need to do anything for R99, Rel-4 or Rel-5. So the release issue needs not
`
`
` to be mentioned in the LS. Chairman invited Ms. Evelyne Le Strat to join the LS drafting.
`
`
` Eventually LS was drafted by Mr. Vincent Belaiche in R1-02-0852. This LS was reviewed on Day 4 but was not
`
`
` approved. (See No. 145)
` (*12) Panasonic presented this CR.
`
`
` This CR was produced based on the request from RAN WG4 LS (R1-02-0815, R4-020735, See No. 2)
`
`
` A number of concerns were raised from several aspects from mutiple companies. Main opinion was that we did not need
`
`
` this change at all.
`
`
` Based on the discussion Chairman concluded that this CR was rejected. Chairman stated that he would report this issue
`
`
` in his report to RAN #16 and ask RAN WG4 to take care of this in their test definition.
`
`- 5 -
`
`IPR2021-00908 Honeywell Exh. 1009 - Page 5 of 37
`(Honeywell International, Inc., et al. v. 3G Licensing S.A.)
`
`

`

`5. High Speed Downlink Packet Access (Ad Hoc 24)
`
`
`No. Category
`
`T-doc
`
`Title
`
`Source
`
`Conclusion Notes
`
`R1-02-0630
`
`R1-02-0359
`
` HS-DSCH data of equal {0,1}
` distribution
` Further considerations on the HS-SCCH
` power control
`
`Panasonic
`
`LS to be sent
`to R2
`
`LGE
`
`Noted
`
`(*1)
`
`Day 1 13:47-14:07
`
`(*2)
`
`Day 1 14:11-14:19
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Transport
`block
`size
`signalling
`
`41
`
`42
`
`43
`
`44
`
`45
`
`46
`
`47
`
`48
`
`49
`
`50
`
`51
`
`52
`
`53
`
`R1-02-0710 QPSK-only UE for HSDPA
`
`R1-02-0796
`
`R1-02-0718
`
`R1-02-0699
`
` Handling of uplink configuration
` parameters
` Performance of the HS-SCCH with
` different code rates
` Comparison of Detection Schemes for
` the HS-SCCH
`
` Vodafone, Telia,
` Ericsson, Nokia,
` Sony
`
`Postponed
`
`(*3)
`
`Sony
`
`LS to be sent
`to R3
`
`Motorola
`
`Noted
`
`Lucent
`
`Not agreed
`
`(*6)
`
`R1-02-0792 HSDPA – UE capability, SF=512
`
`Qualcomm
`
`Noted
`
`R1-02-0745
`
` Signalling of transport block sizes for
` HS-DSCH
`
`Ericsson
`
`Noted
`
`R1-02-0694 TB size signalling in HSDPA
`
`Lucent
`
`Noted
`
`R1-02-0809 Transport Block Size Set definition
`
`Qualcomm
`
`Noted
`
`R1-02-0749
`
`R1-02-0715
`
` Draft LS on Alignment of UE categories
` and supported transport block sizes
` 16 bit UE ID Based UE Specific
` Masking for HS-SCCH
`
`Ericsson
`
`Noted
`
`InterDigital
`
` CR
`
`R1-02-0771
`
`LGE
`
`Noted
`
`(*9)
`
`Day 1 14:36-15:05
`
`(*4)
`
`Day 1 15:56-16:16
`
`(*5)
`
`Day 1 16:24-16:29
`
`Day 1 16:40-17:17
`
`(*7)
`
`Day 1 17:18-17:43
`
`(*8)
`
`Day 2 09:08-09:15
`
`(*8)
`
`Day 2 09:15-09:32
`
`(*8)
`
`Day 2 09:32-10:06
`
`(*8)
`
`Day 2 09:45-09:47
`
`(*9)
`
`Day 2 10:08-10:29
`
`UE ID
`masking
`
` On the Criterion for UE Specific
` Scrambling Code
`
`R1-02-0723
`
` False alarm performance of various UE ID
` coding, scrambling and CRC schemes
`
`R1-02-0541
`
`R1-02-0703
`
` UE-Specific Scrambling Code (USSC) for HS-SCCH:
` USSC based on a scrambling code with time-varying
` property
` HSDPA UE capabilities with and
` without 16QAM
`
`Use of
`16-QAM
`
`R1-02-0704
`
` CQI tables taking 16QAM optionality
` into account
`
`R1-02-0799
`
`R1-02-0756
`
`R1-02-0754
`
`R1-02-0755
`
` HSDPA system performance
` with/without 16QAM
` Effect of Transmission Gaps on HSDPA
` Coverage
` ACK/NACK signalling with increased
` DPCCH pilot power
` CR 25.214-XXX : Correction of DPCCH
` power during HSDPA operation
`
`R1-02-0764
`
` Impact of separate power control of
` HS-DPCCH on UL DPDCH performance
`
`R1-02-0696
`
` HS-DPCCH Power requirements at edge
` of coverage
`
`R1-02-0705
`
` Performance of uplink HS-DPCCH in
` SHO
`
`54
`
`55
`
`56
`
`57
`
`58
`
`59
`
`60
`
`61
`
`62
`
`63
`
`64
`
`65
`
`66
`
`
`
`
`
`
`
`Ack/
`Nack
`Power
`Offsets
` +
`HS-
`DPCCH
`Power
`Control
`
`Lucent
`
`Noted
`
`LGE
`
`Noted
`
`Nokia
`
`Nokia
`
`Postponed
`
`Motorola
`
`Noted
`
`Philips
`
`Noted
`
`Philips
`
`Noted
`
`Philips
`
`Noted
`
`Samsung
`
`Noted
`
`Lucent
`
`Noted
`
`Nokia
`
`Noted
`
`Day 2 10:55-11:06
`
`(*9)
`
`Day 2 11:06-11:21
`
`(*9)
`
`Day 2 11:22-11:48
`
`(*10)
`
`Day 2 18:26-18:41
`
`(*10)
`
`Day 2 18:41-18:49
`
`(*10)
`
`Day 2 18:49-19:23
`
`(*11)
`
`Day 2 19:29-19:38
`
`(*12)
`
`Day 2 19:38-19:50
`
`(*13)
`
`Day 2 19:50-20:04
`
`(*14)
`
`Day 3 09:12-09:19
`
`(*14)
`
`Day 3 09:20-09:37
`
`(*14)
`
`Day 3 09:37-09:53
`
`(*14)
`
`Day 3 09:53-10:13
`
`(*14)
`
`Day 3 10:13-10:24
`
`R1-02-0760
`
` Simulation results on HS-DPCCH power
` control
`
`NEC
`Telecom MODUS
`
`Noted
`
`R1-02-0713 Channel estimation for HS-DPCCH
`
`Nortel
`
`Noted
`
`- 6 -
`
`IPR2021-00908 Honeywell Exh. 1009 - Page 6 of 37
`(Honeywell International, Inc., et al. v. 3G Licensing S.A.)
`
`

`

`No. Category
`
`T-doc
`
`Title
`
`Source
`
`Conclusion Notes
`
`R1-02-0712
`
` Requirements for HS-DPCCH power
` control
`
`R1-02-0824
`
` HS-DPCCH Power Control in Soft-
` Handoff
`
`R1-02-0364
`
` On the HS-DPCCH performance with
` consideration of the channel estimation
`
`R1-02-0757
`
`R1-02-0795
`
` Performance of differential ACK/NACK
` coding
` Optimal DL signalling for HARQ in
` HSDPA
`
`67
`
`68
`
`69
`
`70
`
`71 HARQ
`optimi-
`sation
`
`72
`
`Nortel
`
`Noted
`
`Motorola
`
`Noted
`
`LGE
`
`Noted
`
`Philips
`
`Noted
`
`NEC
`NEC Australia
`
`Not
`agreed
`
`Not
`agreed
`
`R1-02-0709
`
` 16-QAM Redundancy and Constellation
` Versions
`
`Panasonic
`
`(*14)
`
`Day 3 10:24-10:37
`
`(*14)
`
`Day 3 10:38-10:47
`
`(*14)
`
`Day 3 10:47-10:58
`
`(*14)
`
`Day 3 11:45-11:59
`
`(*15)
`
`Day 3 14:52-15:09
`
`(*16)
`
`Day 3 15:10-15:14
`
`(*17)
`
`Day 3 16:23-16:40
`
`(*17)
`
`Day 3 16:41-16:51
`
`(*17)
`
`Day 3 16:51-17:05
`
`(*17)
`
`Day 3 17:07-17:24
`
`(*17)
`
`Day 3 17:24-17:34
`
`(*17)
`
`Day 3 17:34-17:39
`
`R1-02-0702 Rel’99 Tx-diversity for HSDPA
`
`Nokia
`
`Noted
`
`R1-02-0721
`
`R1-02-0797
`
` HSDPA closed loop transmit diversity
` performance for different schedulers when HS-
` SCCH and Associated DCH are explicitly modelled
` HS-DSCH closed loop Tx diversity
` throughput with feedback error
`
`R1-02-0697
`
` Impact of H-ARQ buffer corruption on
` TxAA performance in HSDPA
`
`Motorola
`
`Noted
`
`Motorola
`
`Noted
`
`Lucent
`
`Noted
`
`Tx-
`diversity
`for
`HSDPA
`
`R1-02-0808
`
` Comments on CL TX Div Feedback
` Signalling on HS-DPCCH
`
`Telecom MODUS
`NEC
`
`Noted
`
`R1-02-0695
`
` TxAA system performance with FB
` signalling on HS-DPCCH
`
`Lucent
`
`Noted
`
`73
`
`74
`
`75
`
`76
`
`77
`
`78
`
`79
`
`Lucent
`
`Noted
`
`(*17)
`
`R1-02-0698
`
` Robustness of transmit diversity on HS-
` SCCH
`
`R1-02-0711
`
` STTD with adaptive transmitted power
` allocation
`
`R1-02-0831
`
` Upper bound of the performance in
` TxAA-HSDPA
`
`Huawei
`
`Noted
`
`Samsung
`
`Noted
`
`Siemens
`
`Noted
`
`Day 3 17:40-17:47
`
`(*17)
`
`Day 3 17:50-18:05
`
`(*17)
`
`Day 3 18:06-18:14
`
`(*18)
`
`Day 3 18:50-19:09
`
`80
`
`81
`
`82
`
`84
`
`85
`
`86
`
`87
`
`88
`
`89
`
`90
`
`91
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`R1-02-0708
`
`83
`
`
`
`R1-02-0789
`
` Transmit Diversity and HSDPA near the
` cell border
` Sequence Numbering for HS-SCCH
` Power Control in TDD
`
`IPWireless
`Siemens
`
`CR  Day4
`
`(*19)
`
`Offline
`discussion.
`LS to R2 to be
`drafted based
`on offline
`discussion
`
`Day 3 20:07-20:22
`
`(*20)
`
`Day 3 20:29-20:36
`
`(*21)
`
`Day 3 20:37-20:41
`
`(*22)
`
`Day 3 20:41-20:52
`
`R1-02-0736 UE Capabilities for 1.28 Mcps TDD
`
`Siemens
`
`R1-02-0833
`
` UE Capability for 3.84Mcps TDD
` HSDPA
`
`IPWireless
`
`R1-02-0806
`
` HSDPA UE Capabilities for 3.84 Mcps
` TDD
`
`Nokia
`
`R1-02-0772 HS-SICH coding for 1.28 Mcps TDD
`
`Samsung
`
`Not agreed
`
`(*23)
`
`R1-02-0787
`
`R1-02-0776
`
`R1-02-0747
`
` HS-SCCH Power Control Scheme based
` on the measurement report for TDD
` TDM method among UEs within one
` code
` Dedicated Pilots as Phase Reference for
` HS-PDSCH Demodulation
`
`R1-02-0832 Parameters for HS-DPCCH
`
`Samsung
`
` Not agreed
`
`Panasonic
`
`Noted
`
`Ericsson
`
`Philips
`
`Decision
`postponed
`Noted for a
`starting point
`
`Day 3 20:53-21:02
`
`(*24)
`
`Day 4 08:34-08:44
`
`(*25)
`
`Day 4 09:26-09:40
`
`(*26)
`
`Day 4 11:20-12:01
`
`(*27)
`
`Day 4 13:54-14:06
`
`
`
`
`
`
`(*1) Mr. Hidetoshi Suzuki (Panasonic) presented this paper.
`
` Method of blind determination of pilot to data power ratio for QAM signals requires equal probabilities of "0"s and "1"s
`
` on HS-DSCH. This paper addressed possible methods to cope with this issue and proposed following 3 possibilities.
`1. Re-introduce the pilot-data ratio signalling to HS-SCCH  (signalling needed)
`
`
`
`- 7 -
`
`IPR2021-00908 Honeywell Exh. 1009 - Page 7 of 37
`(Honeywell International, Inc., et al. v. 3G Licensing S.A.)
`
`

`

`2. To have HS-DSCH data stream always enciphered by KASUMI  (RAN WG2 concerns)
`
`
`
`3. To have L1 level randomising function
`
`
`
` A small discussion took place on
`
`
`
`
`- In which cases does the problem occur ?
`
`
`  [(Very low data rate) + (16 QAM) + (not ciphering) + (lot of {0} or {1} data)]  Not very likely to happen.
`
`
`
`
`
`
`- What level of degradation is foressen ? and whether this kind of randomisation is really needed or not ?
`
`
` Chairman asked Motorola to draft an LS for RAN WG2 informing this issue and asking for their opinion.
`
`
` Eventually the LS was drafted in R1-02-0814 by Motorola and approved in R1-02-0846 on Day 4.
`
`
` Later, RAN WG2 sent back its answer in R2-021468 in which it states
`
`
`RAN2 has reviewed the liaison from RAN1 regarding HS-DSCH data distribution. The opinion of RAN2 is that the existing
`
`
`
`ciphering mechanisms or any new 'non secure' ciphering mode are an unnecessarily complex means to achieve HS-DSCH bit
`
`
`
`scrambling. RAN2 suggests that RAN1 investigates simpler layer 1 solutions to achieve the desired scrambling.
`
`
`
`(*2) LGE presented this paper.
`
`
` This was the sequel to R1-02-0559 on HS-SCCH power control which had been reviewed in RAN WG1#25. In the
`
`
` current paper the required power offset range for HS-SCCH was investigated. The simulation results showed that the
`
`
` power offset should range from –13.5dB to 19.75dB with sufficient (+)() margin added. It suggested that the same
`
`
` range and resolution as PDSCH could be applied.
`
`
` There was no comment made. Chairman mentioned the range and resolution should be the same as PDSCH.
`
`
` LGE proposed that they would inform this results to RAN WG3 in offline via their colleagues.
`
`
` Chairman agreed to this proposal emphasising that it should be informed to RAN WG3 that the same range as PDSCH
`
`
` should be applied. LGE agreed.
`
`(*3) Mr. Yannick Le Pezennec (Vodafone group) presented this paper.
`
`
` This paper proposed to make the support of 16QAM optional (In the current working assumption, 16QAM is
`
`
` mandatory feature.). As one of the reasons, it stated that so far, there is no clear evidence of the system level gain
`
`
` offered by 16QAM for any deployment of HSDPA in urban environments. System level simulations have shown
`
`
` relatively small gain (whenever any gain is really achieved) when using 16 QAM and QPSK with respect to the case
`
`
` where QPSK is solely used. It said in particular, performance of 16 QAM appears to collapse for channel models
`
`
` relatively close to real-life deployment environments (pedestrian B - vehicular A).
`
`
` This paper was a kind of a sequel to R1-01-1116 (Ericsson /Vodafone) which had been presented in RAN WG1#22
`
`
` meeting in Jeju. Unlike the R1-01-1116, in this paper Telia, Nokia and Sony joined in source companies.
`
`
` A bit long discussion took place.
`
`
` Mr. Serge Willenegger (Qualcomm) remarked that we should consider following 2 points with this proposed UE
`
`
` capability.
`
`
`
`- System throughput
`
`
`
`
`If the radio condition is very good, although it would not be so often, then system cannot really take advantage
`
`
`
`
`of good radio conditions for the UE that has only QPSK.
`
`
`
`- Potential code limitation
`
`
`
` Assuming there is code limitation, with the current UE capability there is always the option to switch to QAM
`
`
`
` when there is more power available compared to the code. If we remove the possibility to do QAM the code
`
`
`
`
`limitation issue would be more significant.
`
`
` It was felt a bit difficult to reach agreement on line. Chairman suggested offline discussion and he postponed the
`
`
` decision for a while.
`
`
` Nokia announced that it had prepared 2 relevant papers on this topic.
`
`
` (CR for TS25.306 in R1-02-0703, the modification of CQI tables in R1-02-0704.)
`
`
` This topic was revisited on Day 2 evening. (See No. 56-58)
`
`/*** Day1 coffee break 15:05 – 15:38 ***/
`
`(*4) Mr. Katsutoshi Itoh (Sony) presented this paper.
`
`
` With regard to the handling of uplink configuration parameters, RAN WG3 assumption seems that Node-B is only
`
`
` allowed to indicate its preferred CQI feedback cycle at the HS-DSCH configuration stage which Sony does not feel
`
`
` sufficient. The treatment for the repetition factor for CQI and ACK/NACK follows the same. Sony feels that it would
`
`
` be beneficial for Node-B to request SRNC to change the CQI reporting cycle during the duration of a radio link
`
`
` and this paper requested the view of RAN WG1 on this issue. This paper was suggesting to send a LS to RAN WG3
`
`
` to inform RAN WG1's view.
`
`
` There was no objection made against the proposal. However it was suggested that Node B should be able to
`
`
` suggest the particular rate (because it would depend on Node B implementation and radio environments) so that RNC
`
`
` does not need ask for guidance from Node B every time.
`
`
` Chairman encouraged Mr. Katsutoshi Itoh to make an draft LS to RAN WG3 regarding this issue in R1-02-0816.
`
`
` Eventually this LS was not sent out from RAN WG1 officially. This topic was discussed in the joint session with
`
`
` RAN WG3. RAN WG3 basically agreed with this proposal.
`
`(*5) Mr. Kenneth Stewart(Motorola) presented this paper.
`
`
` This paper was reviewed in connection with the CR 25.212-132 in R1-02-0605 (See No. 102). While the CR was
`
`
` proposing to adopt R=1/3 convolutional code by adapting the rate matching patterns, this paper suggested to keep
`
`
` existing R=1/2 scheme with the reason that there is no big performance improvement (within 0.2dB)
`
`
` There took place a small discussion but no companies supported this paper. In the end Mr. Kenneth Stewart remarked
`
`
` that Motorola can accept the CR from Siemens.
`
`(*6) Lucent presented this paper.
`
`
` This was a sequel to R1-02-0649 which had been discussed in RAN WG1#25. Basically this paper proposed to add
`
`
` parity check bits into the part-I of HS-SCCH coding structure. (puncturing to be done to make the room for the parity.)
`
`- 8 -
`
`IPR2021-00908 Honeywell Exh. 1009 - Page 8 of 37
`(Honeywell International, Inc., et al. v. 3G Licensing S.A.)
`
`

`

` There were some comments saying that we had already made a conclusion on this issue in RAN WG1#25 that we would
`
`
` not have this proposal. Chairman responded to the comments that Lucent had elaborated their proposal with more
`
`
` comprehensive evaluation and therefore we should discussed this issue again in this meeting. However all the comments
`
`
` made were showing that people seemed to prefer to keep the existing structure and not add the parity bits as such. Based
`
`
` on those comments received Chairman concluded that we would stick to the current structure. (No addition of parity
`
`
` bits.)
`
`
`(*7) Mr. Serge Willenegger (Qualcomm) presented this paper.
`
`
` This paper proposed to introduce full-support for SF=512 DPCH in Rel-5 and make its support mandatory for UEs
`
`
` supporting HS-PDSCH to introduce a more code resource effici