- Report of TSG RAN WG2 #61bi5, Shenzhen, China, March 31 — April 4, 2003
`
`Model ofthe physical
`
`112
`I12
`.l
`.2 Other [13
`
`.
`
`Report of LTE control plane session (Al 5.2) ................................................................... 1 14
`Annex G:
`5.2
`Control
`114
`
`5.2.1.2
`5.2.1.3
`
`Connectioncontrol 114
`II9
`
`I21
`Inter-RAT Mobility
`5.2.1.4
`122
`System information
`5.2.1.5
`
`5.2.1.6 Other 126
`5.2.1.?
`PDU contents details
`127
`
`5.2.1.8
`5.2.2
`5.2.2.1
`5.2.2.2
`
`Cell selection & re-selection (36.30-4)
`
`Cell reselection
`
`I28
`128
`128
`[28
`
`5.2.2.3 Paging I29
`5.2.2.4
`Speed Dependant Cell Re-selection
`[29
`5.2.2.5 Other [29
`
`RAN WG2 meeting #6lbis post processing ...................................................................... 131
`Annex H:
`Email diseussionsfapprovals
`l3l
`
`Annex I:
`
`History .................................................................................................................................134
`
`Page 5 of 134
`
`SAMSUNG 1017-0211
`
`SAMSUNG 1017-0211
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`Organisation of the meeting
`
`Meeting:
`Meeting location:
`
`Duration:
`Host:
`
`3GPP TSG RAN WG2 #6 I bis
`Shenzhen, China
`
`Monday 3| .03.2008 - Friday 04.04.2008
`ZTE Corporation
`
`Gert-Jan van Lieshout (Samsungj email: Gert.vanLieshout@samsung.com
`TSG RAN WG2 Chairman:
`TSG RAN WG2 Vice chairman: Richard Burbidge (Motorola)
`email: Richard.Burbidge@molorola.com
`
`TSG RAN WG2 Vice chairman:
`TSG RAN WG2 Secretary:
`
`Patrick Fischer (LG)
`Joem Krause (ETSI MCC)
`
`email: PFischer@lge.com
`email: Joem.KraLzse@etsi.org
`
`Email reflector:
`Technical documents:
`
`3GPP_TSG_RAN_WG2@LlST.ETSl.ORG
`ft
`://ft
`.3
`.or
`ts
`ranfWG2 RLZITSGR2 6| bis/Docs
`
`Ad hocs:
`
`next meetings:
`
`Parallel ad hocs are held (see agenda item 2) on
`- LTE user plane (agenda item 5. 1, Wed-Thu): chaired by Gert-Jan van Lieshout
`
`- LTE control plane (agenda item 5.2, Tue-Thu): chaired by Richard Burbidge
`
`- UTRA/UTRAN (agenda item 6. Mon-Wed): chaired by Patrick Fischer
`
`No joint ad hocs with other WGS were held.
`TSG RAN WG2 #62.
`04.05. - 09.05.2008 Kansas City. USA
`
`TSG RAN #40,
`
`27.05. - 30.05.2008 Prague, Czech Republic
`
`Statistics
`
`TSG RAN WG2 #6Ibis was held 3 weeks after TSG RAN #39.
`
`0
`
`I
`I
`
`I
`
`I
`
`I61 participants
`
`651 Tdocs allocated with actual 605 contributions (including I allocated CR3}
`48 incoming liaison statements
`
`I7 outgoing liaison statements (note: I further LS R2-082048 is still under email discussion)
`
`92 endorsed CR3 from RAN2 #6] bis which will be resubmitted to RAN2 #62 for final agreement:
`0
`0 CR5 for Rel.99
`
`I
`
`-
`
`I
`
`0
`
`I
`
`I CR for Rel.4
`
`1 CR for Rel.5
`
`3 CR5 for Rel.6
`
`31 CR5 for Rel?
`
`56 CR5 for Rel.8 (42 for UTRA Rel.8 and [4 for E-UTRAILTE)
`
`Note: The sequence in which the different topics appear in this report is related to the agenda ofthe meeting. However,
`the Tdocs do not necessarily appear in the sequence as they were treated in the meeting.
`
`Page 6 of 134
`
`SAMSUNG 1017-0212
`
`

`
`- Report of rso RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`1
`
`Opening of the meeting
`
`TSG RAN WG2 chaimian Gert-Jan van Lieshout (Sam.-sung) opened the meeting RAN WG2 #6lbis on Monday
`morning 31.03.2008 at 09:00 o'clock.
`
`On behalf ofthe host {ZTE Corporation) Zhisong Zuo welcomed the delegates to Shenzhen and explained
`organisational issues.
`
`RAN W02 meeting rooms:
`
`Main RAN2 room: Espana l, for about 200 participants. Mon-Fri
`
`First ad hoc room: Madrid 5: for about 70 people, Mon-Thu
`
`2nd ad hoc room: Madrid 8: for about 50 people. Tue-Wed
`
`Other RAN W05:
`*: ad hoc rooms
`
`Same floor {RAN ]: Espana 2 & Madrid 3*. RAN3: Madrid 2. RAN4: Barcelona & Madrid 1*].
`
`1.1
`
`Call for IPR
`
`Gert-Jan van Lieshout (TSG RAN WG2 chairman} made the following call for lPRs and reminded the delegates oftheir
`obligations with respect to |PRs:
`
`The attention of the delegates of this Working 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 delegates were asked to take note that they were hereby invited:
`
`o
`
`to investigate whether their organization or any other organization owns [PR3
`which were, or were likely to become Essential in respect of the work of the
`work of 3GPP.
`
`o
`
`to notify their respective Organizational Partners of all potential IPRS, e.g., for
`ETSI, by means of the IPR Statement and the Licensing declaration forms
`
`.etsi.or flhtt zffweba rt’ .
`
`
`NOTE:
`
`[PR5 may be declared to the Direetor—General or Chairman oFt|1e SDO, but not to the chairmen.
`
`
`
`Page 7 of 134
`
`SAMSUNG 1017-0213
`
`

`
`- Report of TSG RAN WG2 #611315, Shenzhen, China, March 31 — April 4, 2003
`
`2
`
`Approval of the agenda
`
`R2-081400: Proposed agenda for RAN2 #61 bis, Shenzhen, China, 31 .03.-04.04.2008 RAN2 chairman
`=> Approved
`
`Schedule as it was finally carried out:
`
`Dav
`Main RAN2 room
`151 ad hue room
`2nd and hue room
`A] 6.0, 6.1, 6.2—
`before coffee break
`Monr.In_\- Morning
`LTE:./\14.1 [LSi11}
`UNITS:
`after coffee break
`A16.0,6.1. 6.2
`Monday Afternoon
`UMTS:
`A|6.3{excep16.3.91
`AI 6.4.1 {partly}
`
`Monday l'If':45 ->
`
`'I‘u1;-sday
`
`Wetlnesiday
`
`L'|'E: Al 4.3.1, 4.3.2 (partly)
`
`Joint UMTSILTE on:
`Home eN1-3 CR: 4.'1‘.1 (partly).
`i11ter-RAT111obility'. Al 4.10
`LTE: Al 4.3.2 (rest), 4.3.3, 4.3.4,
`L112 control in RRC: A1 4.4.
`Ot|1er1u11icast}:A|4.5
`L‘1‘E UP:
`MAC‘: Al 5.1.1.1-5.1.1.5,5.1.1.6{par1|y}
`
`5.2.2.5
`
`
`UMTS:
`AI 6.3.9, 6.4.1 [rest], 6.4.2 — 6.4.3
`
`UMTS:
`A1644 — 6.4.1], 6.5
`
`LTE CP:
`RRC: AI 5.2.1.1.
`5.2.1.2
`L'1‘E CP:
`RRC: Al 5.2.1.2
`(r1:s:).5.2.|.:'1,
`5.2.1.7 [just R2-
`0816881
`LTE C P:
`RRC:1'\[5.2.1.3,
`5.2.1.4 [partly].
`5.2.1.6 (partly).
`5.2.1.8 (par1|_v}.cc|l
`selection: 5.2.2.3,
`
`L'1'l;' U1’:
`MAC: 5.1.1.? (partly) , 5.1.1.8 (partly),
`R1.C: 5.1.2. PDCP: 5.1.3.
`UE capabilities: 5.1.4
`
`Friday
`
`Reporting |..'|‘|£ CPIUP
`|.c1‘t-overs section 4
`Outgoing l_TE liaisons
`
`Not treated agenda items {A1}:
`4.6 Broadcast services and subsections
`
`4.8 UE specific RRM infonnation at handover
`4.9 SON {Self Optimising Networks)
`5.1.1.10 Other (unicasn
`5.2.1.8 Methodology
`5.2.2.2 Cell reselection
`
`No inputs were submitted to agenda items:
`4.2 Stage-2 status
`4.4.] General (L112 control in RRC]
`4.4.4 RLC (Ll/2 control in RRC]
`5.1.1.9 RRC configurable parameters
`5.1.2.2 RLC header formats
`
`5.1.4.1 Status (ofUE capabilities)
`5.1.5 Model ofthe physical layer (36302) and subsections
`5.2.2.1 Status (ofCell selection & re-5e|ectio11(36.304))
`5.2.2.4 Speed Dependant Cell Reseiection
`
`3
`
`Minutes of the previous meeting/reporting from other
`meetings
`
`R2-081401: Draft report of RAN2 #61, Sorrento, Italy, 11-15.02.2008ETS| MCC
`
`Page 8 of 134
`
`SAMSUNG 1017-0214
`
`SAMSUNG 1017-0214
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`=> Comments to be raised before Friday of RAN2 meeting #61bis.
`Revised in R2-081441 to include some review comments.
`
`R2-081441
`
`Updated draft report of RAN2 #61, Sorrento, Italy, 11-15.02.2008 ETSI MCC
`Contents agreed. Revised in R2-081445 to provide final version.
`
`R2-081445
`
`Final report of RAN2 #61, Sorrento, Italy, 11-15.02.2008ETS| MCC Report
`Agreed.
`
`Chairman '5 report [ram TSG-RA {W3 9:
`CR ’s
`
`RA N2 C'Rsf0r RAN #39 approved except:
`—
`25. 999 company (‘R reptoeed the ot‘iginot' (‘R
`—
`36.32;’, 36.33 .-' .' company (‘Rs (contention resot'tttt’on) reptoced ot'iginot' RA N2 (‘Rs
`— D()B: ("Rs were t'ejected by voting
`
`UMTS:
`
`Tlhree new W! '.s' with RA N2 as I” responsible.’
`- WI: HSPA Vol!’ to H/("DMA/GSM ("Scotttimtity (RP-0802.?9)/lppro1‘ed
`—
`Wt." HS-D.S'(.'H Serving C'ei.l' Change Enhancements (RP-08022 7) Approved
`—
`Wt’: Support of U TR/1 HNB (Ri’—08(H59). In principie agreed.
`0
`RAN} sitoztici review the Wt-sheet, and restrt'ct the objectives to tr setfor 11-’I'3it;I'?
`comptetton in Re!-8 timefrrtme can be t'ecr.s'onobt'y expecteo’,
`
`L TE:
`
`-
`—
`-
`
`No change in time pIcmfot' RA N2
`Not ttnnecesmry re—opert agreemenimfoctts on dosing open issues‘
`"Option prztning "
`
`Ci1tiirnitin'.s' report [rent TSG-SA#39:
`- MBMS was removedfrom Re!-8 (see SP-0802t'8)
`-
`SA‘ i‘8({£i€Si.5’
`the opt'nt'ott of R/1N2 now to ltandie ETWS in Rel-8 given absence of MBMS (See SP-080223}
`-
`t-tome-NB/t-tome-eNB.‘
`
`SA‘ agreed on or CR in SP-080.-"88. RA N2 is" reqtte.s'ted to re1tieu=thr'.s' CR and see n-‘iretiter it cottses any
`pt-obletmgfrom R/t N2 poirtt of 1-'t'en=.
`t_'f'1re itove titty concerns. we s:’»toztt'd t’t'ot.ve urith (‘Ti and (‘H can ot't'gr'note
`an odditionoi CR on 22.0} 1.
`
`Other:
`
`-
`
`ifno concerns are t'oi.s'ed before the end ofthe meeting. intenttotr is to abandon foflowing 2 TR '5:
`0
`25.8i 9 Rei—7 "Z68 Mcps TDD option: L(i_‘r'r.’i' 2 and 3 proroco.’ aspects " 1-‘! . 0.0
`ViIf ‘R TDD: t.'.rtyer 2 and .-’(tyer 3 protocot' aspects
`3 0. 302' Re.-’-7 "184 Maps TD!) etrivcrnced ttpt'irrt't'.' R/1‘ N WG2 Stage 2 deci.s'r'0tr5" V0.2.-9
`R.-"’-30.‘ everttmtfly to be merged into 25,309.
`See agenda item "9 Any other business" for the decision.
`
`0
`
`4
`
`LTE General
`
`Ur.rder' tiris rigerrdrl item we o'r'.s'cr.-55' Stage-2 i:;srtes_ and disc i.I.'.I.'ue5 rim! are too genemi ie.g. itnpactitrg mrtitipie _m‘otocoi.\') or H'J:I'p0i'i(m'." fag. rrrajor
`ittrpoct on other grorrps) to be a'r'.ec:.-ssed in the CP t' UP se.vsion.s‘ .re,nctt‘cttet’_I=.
`
`4.1
`
`Incoming L8 to LTE
`
`R2-081412: Reply L8 to R2-080609 and R2-081363 on various aspects related to GERAN to E-UTRAN
`interworking (GP-080395; to: RAN2, RAN4; cc: -; contact: NSN) GERAN - RAN2 action
`requested
`- Two questions to us:
`-
`Priority algorithm mandated for UMTSIGERAN-only mobile ? => We see no problem
`from our side to mandate this.
`
`-
`
`Predefined t default configurations; see what we can decide this week.
`
`Page 9 of 134
`
`SAMSUNG 1017-0215
`
`SAMSUNG 1017-0215
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`=> Response in R2-081925
`
`R2-081411:
`
`LS on Equal priority Inter-RAT reselection - (GP-080298; to: RAN2; cc: -; contact: NSN)
`GERAN - RAN2 action requested
`=> There are contributions. Can sent response after that discussion in R2-083927
`
`R2-081413: Reply L8 to R2-O75-4?8 on CSG related mobility (stage 2 text) - (GP-080417; to: SA1, RAN2;
`cc: SA2, RAN3, RAN-4, RAN1; contact: NSN) GERAN - RAN2 action requested
`=> There are contributions. Can sent response after that discussion in R2-081928
`
`R2-081403:
`
`LS on Release 8 non-essential SAE features (SP-080218; to: CT1, CT3, CT4, CT6. RAN1,
`RAN2, RAN3, RAN4, 8A1, 8A2, 8A3, 8A4, 8A5, CT, GERAN, RAN; cc: -; contact: Ericsson)
`SA no explicit RAN2 action requested - Janne Peisa (Ericsson}
`=> Noted
`
`R2-081404:
`
`LS on Decision of MBMS and LCS in SAE Re|8 Scope Discussions (SP-080223; to: SA2,
`RAN1. RAN2, RAN3; cc: SA1, GERAN2; contact: NTT) SA - RAN2 action requested -
`presented by Mikio Iwamura (NTT)
`=> There are contributions on the ETWS. Can sent response after discussion in R2-081929
`
`R2—0814-35: Reply L3 to 82-0758‘/4 on Earthquake and Tsunami Warning System — (G2—08D112; to: SA2,
`SA1, GERAN, GERAN1; cc: RAN2, RAN3. CT1. SA3; contact: Telecom ltalia) GERAN2 - no
`RAN2 action requested - presented by Andrea Buldorini (Telecom ltalia)
`=> Noted
`
`R2-081406: Reply L5 to G2-080112 and S2-075874 on ETWS (GP-080410; to:SA1, SA2; cc: RAN2.
`RAN3, CT1, SA3; contact: Vodafone) GERAN - no RAN2 action requested - presented by
`Assen Golaup (Vodafone)
`=> Noted
`
`R2-081407: Reply L8 to S2-075847 on Earthquake and Tsunami Warning System - (R3-080541; to: SA2,
`RAN2; cc: SA1, GERAN2; contact: NTT)
`RAN3 - RAN2 action requested - presented by
`Mikio lwamura (NTT)
`=> Response can be included in R2-081929; Noted
`
`R2-081916: Reply L8 to SA2 to S2-075875 regarding ETWS Security (S3-080219: to: SA2; cc: RAN2.
`RAN3, GERAN2. CT1, SA1; contact: NTT) SA3 - no RAN2 action requested - presented by
`Mikio lwamura (NTT)
`=> Noted (primary notification could be several hundreds of bits)
`
`R2-081409: L8 to establish working assumptions forthe scope of responsibility for optimized handover
`specification (C1-080779; to: RAN2, RAN3, CT4, SA2; cc: -; contact: ALU) CT1 - RAN2 action
`requested - presented by Sudeep Palat (Alcatel-Lucent)
`-
`Does not seem to be our area of expertise. Main input should come from SA2.
`=> Noted without response.
`
`R2-081410: EPS Session management procedure optimisations - (C1-080780; to: RAN2, RAN3, CT4; cc: -
`: contact: Ericsson) CT1 - RAN2 action requested — presented by Vera Vukajlovic (Ericsson)
`-
`ALU thinks this is related to general aspect on NASIAS interaction.
`-
`Currently we don't allow to transfer multiple NAS msgs in one RRC message.
`-
`Samsung wonders ifthere is any difference if the NAS messages are transported in
`different RRC msgs: they might still end up in one TTI. Mot agrees that for the general
`case they should not be concerned. However Mot assumes this is specifically about the
`NAS concatenation with AS procedures (multiple RB establishment).
`Can have response LS after NASIAS interaction discussion in GP-session R2-
`
`=>
`081930
`
`R2-081414:
`
`LS on Change Request for LTE TDD Frame Structure to TS.36.30O vs.3.o - (R1-081112; to:
`RAN2; cc: -; contact: RlTT)RAN1 - RAN2 action requested - (note: R1-081112 arrived already
`at the end of RAN2 #61 but was not treated there clue to a lack of time)
`=> CATT will provide an updated version for the next RAN2 meeting, which is written on the
`latest version of the 36.300.
`
`Page 1'0 of 134
`
`SAMSUNG 1017-0216
`
`SAMSUNG 1017-0216
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`R2-081415:
`
`LS on OR to T836306 - (R1-081125; to: RAN2, RAN4; cc: -; contact: NTT)RAN‘l - RAN2
`action requested - presented by Mikio Iwamura (NTT)
`-
`There is an error in latest version of 306 on the #soft-channel bits for category 1.
`Rapporteur will make CR for next meeting
`=> Noted (already included)
`
`R2-081416:
`
`LS reply to R2-075481 on NDI vs. RV - (R1-081138; to: RAN2; cc: -; contact: Panasonic)
`RAN1 no explicit RAN2 action requested - presented by Takahisa Aoyama (Panasonic)
`So for DL separate 2 bit RV, UL jointly coded.
`LG asks if UL retransmissicns will not change UL format like MOS ? Panasonic replies that
`same modulation scheme is used in retransmissions.
`=> Noted
`
`-
`-
`
`R2-081417:
`
`LS on Redundancy Version Sequences for HARQ - (R1-081141; to: RAN2; cc: -; contact:
`NSN) RAN1 - RAN2 action requested
`=> Noted (there are 3 inputs doc on MAC for this)
`
`R2-081418:
`
`LS on High Interference Indicator - (R1-061148; to: RAN3; cc: RAN2. SA5; contact: Ericsson)
`RAN1 - no RAN2 action requested - presented by Vera Vukajlovic (Ericsson)
`==- Noted
`
`R2-081419:
`
`LS on L1-related parameters to be configured by RRC - (R1-081156; to: RAN2; cc: -; contact:
`Ericsson) RAN1 - no explicit RAN2 action requested - presented by Vera Vukajlovic
`(Ericsson)
`=> Noted (contribution available for handling part of this information in our specifications)
`
`R2-081420: Reply L3 to R2-080621 on RACH retransmission delay requirements - (R1-081160; to: RAN2;
`cc: -; contact: Ericsson, Panasonic) RAN1 - no explicit RAN2 action requested. no LS
`answer? - presented by lvlagnus Lindstrom (Ericsson)
`-
`Chairman asked if the response to c) should be captured in our specs as UE performance
`requirements ? NTT DOM thinks Time to response to UL grant: RAN1. Time to retransmit
`the preamble in RRC.
`Some confusion on what “minimum processing delay really means". We are also
`interested in the maximum processing delay. QC thinks the provided values could also be
`interpreted as the maximum delay. Panasonic also thinks this is a kind of maximum delay
`which we can use for our calculation on next RACH opportunity. Will offline check this
`with RAN1.
`
`-
`
`=> Ericsson will check what of c) will be captured in L1 specifications. and if there is remaining
`requirements that need to be captured in MAC. Ericsson will provide CR to next meeting.
`Might also need to sent an L8 with further questions w.r.t. minimax UE processing
`requirement.
`
`R2-081421: Reply L8 to R4-0?181 3 on Signalling of additional spectrum emission requirements - (R3-
`080449; to: RAN2, RAN4; cc: RAN1; contact: Motorola) RAN3 - RAN2 action requested
`=> Noted
`
`R2—081422:
`
`LS on RAN performance monitoring - (R3—08530; to: SA5; cc: RAN1. RAN2, RAN4; contact:
`NTT) RAN3 - no RAN2 action requested - presented by lvtikio Iwamura (NTT)
`=> Noted
`
`R2-081423:
`
`LS on Self Configuring and Self Optimizing Network Use Cases and Solutions TR - (R3-
`080536; to: SA5, RAN2, RAN-4, RAN1; cc: GERAN2; contact: T-Mobile) RAN3 - no explicit
`RAN2 action requested
`=> Noted
`
`R2-081435:
`
`LS reply to R2-081364 and R3-080530 on RAN Performance monitoring - {S5-080540; to:
`RAN2, RAN3; cc: RAN1, RAN4; contact: NSN)SA5 - RAN2 action requested
`=> Noted: should wait for input from SA5 before continuing on performance monitoring related
`measurements.
`
`Page 1'1 of134
`
`SAMSUNG 1017-0217
`
`SAMSUNG 1017-0217
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`R2—0B1424: Reply L8 to R2-075458. S2-080965 and R2—D80605 on Applicability of “subscriber type"
`indication for UTRAN 8: GERAN - (R3-080543; to: SA2, RAN3, GERAN2; cc: -; contact:
`Vodafone) RAN3 - RAN2 action requested - presented by Assen Golaup (Vodafone)
`Question 1:
`
`-
`
`Vdf thinks the intention was to also use for active mode. Tmob agrees. NSN thinks it is an
`implementation issue, but can be used.
`Question 2:
`-
`Vdf assumes coordination is needed between service based handover infonnation and
`
`-
`
`-
`
`subscriber type in order to avoid ping-pong as a resuit of both information parts. RAN2 has
`not studied detailed consequences.
`Tmob thinks there is a different scope (subscriber type per UE, service based handover
`per RB).
`TIM thinks that one approach would be that in case of clash, service based handover
`should have priority.
`NSN does not see so much need for using the subscriber type in Q08 management
`(already have e.g. QCI). But again implementation issue.
`=> Response along these lines in R2-081931
`
`-
`
`R2-081425:
`
`R2-081426:
`
`R2—081427:
`
`-
`
`LS on LTE-ceIt- and eNB-identification - (R3-080547; to: RAN2, SA2, CT1; cc: -; contact: NSN)
`RAN3 - RAN2 action requested
`—
`NSN points out that if we want to use the same identity over XZIS1 as on BCCH, then the
`BCCH identity probably needs to included an eNB id. Samsung thinks that if we include
`the eNB-Id, we would be including something like 12 bits exta,
`NSN points out that we need to thing about CSG‘s. CT1 will only meet after us. Are CSG's
`handled with a separate identity or included in this one identity.
`Ericsson's understanding from the last meeting was that we were moving in the direction
`of TA + cell-id rather than eNB. In general we should limit the information in SIB1.
`QC points out that since the UE does not read the GCID from the target, anyway the X2
`handover needs to be handled based on the L1 identity reported by the UE. NSN thinks
`that there is a relation, because of ANR.
`=> Response is deferred to next meeting
`
`-
`
`-
`
`LS on RLF Recovery Information over X2 - (R3-080553; to: RAN2; cc: -; contact: Nortel) RAN3
`no explicit RAN2 action requested
`-
`QC is wondering what is "RLF information" ? Does this concern an indication of "handover
`or re-establishment”. In NorteI’s understanding, there is no such differentiation. 80 there is
`only 1 procedure over X2.
`So if we prepare multiple eNB’s. the source will select what handover command to
`forward.
`
`-
`
`-
`
`So it would also mean that any handover preparation shall included the “Re-establishment
`MAC-I".
`
`-
`
`NTT DCM wonders if this means that all targets have to reserve dedicated preambles if
`they want to use dedicated preambles for handovers ? If we don’t discriminate, this would
`indeed be the consequence.
`So basically we agree with the RAN3 assumptions and have only 1 preparation procedure.
`-
`=> Will see response in R2-081955
`
`-
`
`LS on the necessity of Location Reporting procedure in S1 - (R3—080564; to: SA2, RAN2; cc: —;
`contact: NTT) RAN3 - RAN2 action requested - Mikio lwamura (NTT)
`-
`In previous CP discussions, it was clear that there are cases in which the UE needs to
`read the BCCH afler handover (e.g. when change indication is received}. So far, the UE
`does not need to read general system information immediately after handover. There are
`papers in this meeting that would require the UE to read SIB1 after handover.
`Ericsson’s understanding is that the majority of parameters would be sent in HOcmd. So
`far only the TA could be one reason to read BCCH in target. So what are other reasons to
`read system information in connected mode ? Motorola thinks that it is clear that the UE
`needs to read SIB2. Ericsson assumes that RACH requirements are sent as optional in
`HOcmd. Motorola think that the RACH parameters can change while the UE is in
`connected mode (BCCH change information). Ericsson thinks there is a difference
`between only reading on change, or always acquiring some system information.
`Panasonic thinks that the UE always has to obtain the SFN in the target cell from BCCH.
`NTT DCM points out that anyway. always the eNB will know.
`
`-
`-
`
`Page 1'2 of 134
`
`SAMSUNG 1017-0218
`
`SAMSUNG 1017-0218
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`=> Can respond based on discussions in CP—session in R2-081956
`
`R2-081428:
`
`LS on Measurements for self optimisation of cell selection/reselection parameters - (R3-
`080565; to: RAN2; cc: -; contact: NEC) RAN3 - RAN2 action requested
`=> There is an input contribution on this. If we have the time to discuss this, we can respond.
`Otherwise from next meeting.
`
`R2-081429: L8 to RAN 2 on mobility from E-UTRA to UTRA without explicit neighbour cell list - (R4-
`080458; to: RAN2: cc: GERAN; contact: Nokia)
`RAN4
`-
`So for idle mode. we can remove the “full NCL“ option for LTE->UTRAN. Will have a full
`NCL in connected mode.
`
`-
`
`NTT DCM wonders if there is still a reason to list neighbours in the “non-full-NCL option“.
`E.g. no individual cell offsets.
`=> Noted (should be taken into account in updates)
`
`R2-081430: Response L8 to R3-080472 on L8 Automatic Neighbour Relation - (R4-080468; to: RAN3; cc:
`RAN2; contact: Ericsson) RAN4 - no RAN2 action requested - presented by Vera Vukailovic
`(Ericsson)
`=> Noted
`
`R2—081431:
`
`LS on Scale of Reported Measurement Quantities — (R4—080484; to: RAN2; cc: RAN1; contact:
`Ericsson) RAN4 - no explicit RAN2 action requested - presented by Vera Vukajlovic
`(Ericsson)
`=> Noted
`
`R2-081432:
`
`LS on signalling lntrailnter-frequency measurement bandwidth - (R4-080541; to: RAN2, RAN3,
`GERAN; cc: RAN1; contact: NTT)RAN4 - RAN2 action requested - presented by lvlikio
`lwamura (NTT)
`=> Noted
`
`R2-081433: Reply L8 to R2-075464 on RACH Optimization Use Case - {S5-080537; to: RAN2; cc: RAN3;
`contact: Huawei) SA5 - no RAN2 action requested
`=> Noted
`
`R2-081434: Reply LS to R3-072401 on Automatic Neighbour Relation (ANR) function - (S5-080538; to:
`RAN3; cc: RAN2, RAN-4; contact: Huawei) SA5 - no RAN2 action requested
`=> Noted
`
`R2-081917 Response L8 to RAN2 to R2-081369 on Authentication at RRC Connection Re-establishment
`(S3-080226; to: RAN2; cc: -; contact: Samsung) SA3 - RAN2 action requested - Note: There
`is an L8 answer proposal available in R2-081765/R2-081699 - presented by Prateek Basu
`(Samsung)
`-
`Should indicate that change of security algorithms is not supported, and ask if SA3 has
`any security concerns with that.
`- MAC-I: SA3 assumes that the re-establishment message is the input for the MAC-I
`calculation. So no change to the algorithm. No SN is signalled but could be specified.
`Cell-Id: Ericsson assumes that we only have one *keNB derivation. In the handover case,
`the UE will only know the L1 id of the target cell. So then the *keNB derivation in the
`handover and re-establishment cases have to rely on the L1 id rather than the GCID.
`=> Will see response in R2-081958
`
`-
`
`R2-081918: Reply L5 to R2-080601 on outstanding NAS messages - (S3-080229; to: RAN2; cc: RAN3,
`CT1; contact: Ericsson) SA3 - RAN2 action requested - presented by Meg nus Lindstrom
`(Ericsson)
`-
`Contribution R2-081200 is the missing attachment
`=> Are contributions on this. Will see reply after these contributions are discussion in R2-
`081959
`
`R2-081919: Reply L3 to R2-080540 on assumptions about UE security capabilities - (S3-080230; to:
`RAN2; cc: CT1; contact: Ericsson)
`SA3 - no explicit RAN2 action requested - presented by
`Magnus Lindstrom (Ericsson)
`=> Noted
`
`Page 1'3 of 134
`
`SAMSUNG 1017-0219
`
`SAMSUNG 1017-0219
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, zoos
`
`R2-081920: Reply-LS to R2-080602 on security aspects on inter-system handover - (S3-080249; to: RAN2;
`cc: -; contact: Nokia) SA3 - RAN2 action requested
`-
`ALU clarifies that HANDOVER TO UTRAN is not |P'ed because the integrity is only started
`by an SMC after the handover.
`It seems true that for GSM->Utv'lTS there are cases where the handover command is not
`
`-
`
`-
`
`at all protected.
`However currently for LTE we have agreed that for intra-LTE there is no handovers before
`security has been started. So then it would be strange to have looser requirements for
`inter-RAT ?
`
`-
`
`ALU thought we had agreed on the restriction for intra-LTE, only for simplicity (only need
`to support 1 way).
`Handovers from E-UTRAN
`
`-
`
`-
`
`-
`
`Ericsson thinks that the same argument can be used for inter-RAT handovers from E-
`UTRAN to other RAT's. ALU agrees with this. So they should only be executed after
`security has been started in LTE.
`TIM thinks this could delay the handover. So if the alignment is the only reason, then we
`should also consider handovers before security activation.
`NTT DOM assumes that anyway redirection before security activation is in line with SA3
`assumptions.
`- Would also not gain that much if we have handover before SMC because anyway the UE
`capability is required.
`Handovers to E-UTRAN
`
`- What about handovers to LTE ? It seems there are no problems to have handovers before
`security activation.
`=> Will see outgoing L8 in R2-081960 answering along these lines
`
`R2-081921:
`
`LS on C8 Fallback - (S2-081993; to: RAN2, RAN3, CT1, CT4; cc: -; contact: NTT)SA2 no
`explicit RAN2 action requested - presented by Mikio lwamura (NTT)
`-
`Several contributions are available.
`
`=> CP session can decide on response.
`
`R2-082014:
`
`LS on Half-Duplex FDD (R4-080805)
`-
`Bullet d} seems to say that there are eNB's that only support HD. Ericsson thinks this
`could happen in case a band only supports HD.
`In Ericsson's understanding, or each FDD band, a UE has to indicate whether the UE
`support FD of HD.
`=> Noted
`
`-
`
`R2-082024: Reply to LS on applicabiiity of “subscriber type" indication for UTRAN & GERAN
`=> Noted
`
`R2-082025:
`
`LS on E-UTRAN Neighbour Cell List information for GERAN
`=> Noted
`
`Stage-2 status
`4.2
`Old)‘ :'appm'.rer.r:' mpr.-r.' po.femr'm' m_:;_rmrre:.r:' rrpabre p:'opo.m.fs.
`
`No input documents.
`
`4.3
`
`Identified issues
`
`4.3.1
`
`Multi-layer RACH modelling (including Msg3/4 failures)
`
`.‘fi"€ any r.-pdr::e.s' r'eqm'i'ed to eg. RRC or MAC ? Does arr_1'rIr:'r:g need to be c.’anfied ‘|l'J'. I,
`/In email’ a'isc'r.-.s-xion tms taken pi’m'e rm rhik {iF.':'.ic'x.vo1.=} .
`comeririorr r'een!urr'0n in .’rM(‘fRR(‘ re.-1.90 rake .-‘mo accnrmr agree.-.f company CR '3 r0 R,-I.-’\",i
`I’ fig. does M934 cantata: ('(‘(‘H' or D(‘('.’.-'
`.7
`
`Retransmission modelling
`R2-081464: Random Access Procedure modelling Ericsson (Rapporteur)
`
`Page 1'4 of 134
`
`SAMSUNG 1017-0220
`
`SAMSUNG 1017-0220
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`R2-081569: RACH modelling Panasonic
`- Still would like a counter in RRC.
`=> Noted
`
`R2-081514: Multi-layer RACH mode|LG Electronics Inc.
`=> Noted
`
`Discussion
`
`Proposal 4:
`-
`Panasonic wonders if this means RRC can cancel a RA-procedure ‘? Ericsson confirms.
`The interaction is that RRC asks MAC to reset. Panasonic indicates that currently, cell
`reselection is only required to be supported on MAC RA failure. Ericsson thinks that at
`least for handover, we have this functionality aiready.
`
`Question I: Need the .-tire of the gt-tttttjcr cchtettttoti-bttsea' access’ befttl'!_v aj-ntitntc or ctm we
`gttrtmtttee that a U15 wt‘.-’t‘ at-.1-rtys get the stttne UL grattt stze ajftet‘ cotttertttott based
`pt-eutnbt’e_,for M5'g3fOt' rett-anstttt'.s-.s~t'ott.s' (e.g. becttttse the UE has to setect ct pt'ectmh!e_fi-ottt
`the sctme gt'ottpfot- t'e-ctttempts).
`
`-
`
`Panasonic thinks we should limit: 1 size per preamble group. LG agrees with this.
`
`Queflion 4.‘ Shotttd ht'ghet' t'ttyet's (RR?/RLF) be t'tt'.-'r,=h=ed trt eotttetttttm .-'05s ttahdltttg or shotttd this
`prefembty be kept in MA ('39
`
`-
`-
`
`Sarnsung thinks it would be simpler not to involve higher layers.
`Ericsson thinks that since the size of the grants does not need to vary, we can keep it at
`the MAC layer. Infineon shares this opinion.
`
`-
`
`-
`
`-
`
`What is Cond_R ?
`-
`QC would not like to remove Cond_R yet. but would like to study this further.
`-
`Ericsson thinks we could try endlessly in MAC, but we should have an indication to higher
`layers when we have a certain number of failures. So Cond_R is not a termination
`condition but more a “failure indication". So also e.g. for the UL data case, RRC would be
`informed about the problem condition.
`Sarnsung thinks MAC could stop after the failure indication rather than continuing.
`Ericsson thinks this is the same as the L1 loosing sync. You still try to recover and don't
`stop immediately.
`Infineon thinks we could have different cases in MAC: e.g. CCCH one handling, and other
`handling for connected state (MAC indicates RLF kind of condition).
`QC indicates that at least for the DL data case we need a max-attempt counter in MAC. {=
`Cond_R). So why not keep it?
`Nokia wonders what the gain would be from having MAC endlessly retry ? Ericsson sees a
`benefit that backofftpower ramping is all handled in MAC.
`- We assume that max-attempt could be set to a sufficiently high value that no action has to
`be taken on that cell after this max is reached. (no re-atempts are needed).
`Ericsson thinks it we go this way, max-attempts has to be quite high and then we don't
`have a natural point to trigger reselection.
`=> Offline discussion invited (Magnus)
`
`-
`
`-
`
`Question 2: is ee.-’t'-t'e.s'et'ec'ti0t1 heeded ct/?et' etteh host ctmtetttt'0t1 or am’)! (tJ"tet' Cond_R?
`
`I With c0h'tsttm pttobttbtttty tn the ()t‘d(Zt‘ of I 0"—2. is the t_vptca-{delayft1e[udtttgtt1.sg3/4
`mttch dtf/"eretrtft'0m only pon=et- romping? Wftat is the probctbthty qfct tmtt.'h hrmger
`t2'et'a_1-*?
`
`=> Would take place after I (or more) error reports from MAC.
`
`Agreements:
`1.For all access cases, MAC performs RA procedure steps 1-4 (Preamble TX; RAR reception;
`Ms 3 TX; Ms 4 race tion inciudin checkin contention resolution until a condition Cond R
`
`Page 1'5 of 134
`
`SAMSUNG 1017-0221
`
`SAMSUNG 1017-0221
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
` is met.
`2.MAC handles Contention Resolution timer for all cases; i.e.. T300.’301 are not needed.
`3.RRC can trigger cell re-selection, at least before any retry on RRC level (if exists)
`4.RRC can abort MAC RA procedure.
`5.A UE shall only get 1 (cell specific) size per preambte group for the UL grant for Msg3 after a
`contention based preamble for retransmissions after contention loss.
`6.UE shall select preamble from same preamble group after contention loss; if the UE obtains
`a different UL grant size, UE behaviour is not defined.
`7.RACH re-attempts after contention failure shall be initiated by MAC.
`8.After offline discussion the following was agreed
`- Align all cases as much as possible
`- MAC will try endlessly
`- MAC will report failure after preamble-trans-max
`- Should MAC indicate every preamble-trans-max as a failure to RRC or only the
`first time ?
`
`- So RRC will do the supervision of the RA attempts. FFS if this needs to be based on timer
`
`or
`
`counter.
`
`Offline effort will try to go through all the different cases and a summary paper will be provide
`during this week in R2-082029. DL data arrival case should also be considered in this aspect
`(might be limited to preamble-trans-max as agreed earlier.
`
`R2-082029: Random Access Procedure model
`Section 2.1:
`
`-
`
`It was clarifies that it is modelled as MAC continuing endlessly, just to have the same
`behaviour in MAC for all these cases. In practise for this case MAC will be reset. So
`currently there is no timer for this case in RRC.
`It was questioned what trigger the MAC RA procedure in this case ? Currently the MAC RA
`is triggered before, and the CONN REQ is only given to MAC when the RA response is
`received.
`Section 2.2:
`
`-
`
`Panasonic wonders whether we agreed to have T310 in re-establishment ?
`-
`Some errors in the RRC part.
`-
`=> Further comments can be made. Will see update in R2-082030
`R2-082030: Random Access Procedure model
`
`Some details already in RRC could have been missed
`-
`=> Agree with principles