2 Report of TSG RAN WG2 #61bis. Shenzhen. China, March 31 — April 4. 2008
`
`-
`
`The alternative would be to have a clear requirement for the PBR enforcement in RAN2.
`Ericsson is fine with that and would prefer than a solution based on the token bucket.
`- Motorola is fine to have guidelines only. but then there should be no RAN5 testcase.
`-
`NSN thinks that if it is a guideline and we don't test it, then there is no value in having it in the
`spec. NSN is fine with a token bucket approach.
`Ericsson thinks one could motivate that the PBR behaviour is only tested: it would mean that
`the detailed behaviour and all corner cases do not need to be specified, but still a rough
`behaviour can be tested. Ericsson thinks that RAN5 could e.g. specified for a RB of 64kbps,
`then the achieved rate should be between 62 and 66kbps over 1 sec. This seems more a
`RAN5 issue.
`
`-
`
`Requirement 4:
`-
`LG thinks that we doh‘t need padding BSR when requirement 4 is agreed.
`-
`Samsung thinks that in some cases it might be better to just include paddig. E.g. if you don't
`want to segment a VOIP packet. This possibility should be allowed. Ericsson would prefer to
`treat this as optimisations. However Ericsson is not aware of examples that would motivate
`exceptions at the moment. QC e.g. wonders for a case of a 4 byte segment. QC is ok to
`accept it as baseline.
`Requirement 5:
`-
`Covered by 1.
`Requirement 6:
`-
`Can be discussed based on the QC document.
`
`Agreements:
`1) Agree that it should be possible to set an "infinite PBR" per RB. In addition it should be
`possible to have a 0-bitrate PBR for an RB.
`2) We shall have an explicit clear requirement in the specification that prevents excessive
`segmentation and that results in testable behaviour. Detailed formulation is FFS.
`3) Will take a “guideline approach" w.r.t. that the UE should try to provide at least the PBR
`to a RB over a period of time. This does not exclude the possibility that RAN5 can come
`up with a test case to test these guidelines.
`4) We shall have an explicit clear requirement that if there is data available, the UE shall
`not include padding.
`
`Will have an email discussion to come to text for 36.321 to try to capture these agreements
`[EMAIL ERICSSON] (aiso refiecting option 1 below)
`
`R2-081778: Clarification on UL Logical Channel Prioritization Qualcomm Europe
`-
`IPW seems to prevent you from using remaining resources for GBR services. This seems
`true if there is insufficient data for the GBR bearers.
`
`-
`
`NSN wonders how you would handle ROHC header size variation ? Does it mean you have
`to set the GBR to the worst ever case ? QC assumes you would set the PBR a bit higher to
`have enough margin.
`NEC thinks there is an implication that the UE knows what bearers are GBR and non-GBR.
`The UE does not know this currently. QC assumes this is known from NAS signalling.
`Ericsson thinks that this duplicates functionality already present in the network, so this is not
`required. NSN shares this concern. It is probably better to stick to what we have.
`=> No support for this proposal: Option 1 will be used as captured in stage—2.
`
`-
`
`-
`
`LG Etectronics Inc.
`R2-081589: BSR priority
`-
`Ericsson wonders whether the cancel mechanism we have already is not sufficient ? LG
`thinks that the current prioritisation seems to argue against this cancellation. So the intention
`is the same.
`NTT DCM thinks this is not needed: if all the data can be fit in the TB and then the BSR is
`
`-
`
`-
`-
`
`-
`
`cancelled. So the prioritisation is not important anymore.
`Panasonic thinks that the point LG is addressing is when you put in the BSR.
`Ericsson does not like the proposal: it seems to make some assumption on how we will the
`TB based on the grant. However only the outcome is important.
`LG wonders what does “cancel" mean. Ericsson thinks it would be very strange to replace it
`with padding. NSN thinks agrees that this clarification is not really needed.
`
`9°’ 134
`
`ZTE/HTC
`Exhibit 1017-0296
`
`ZTE/HTC
`Exhibit 1017-0296
`
`

`
`2 Report of TSG RAN WG2 #61bis. Shenzhen. China, March 31 — April 4. 2008
`
`-
`
`-
`
`Panasonic agrees that the only thing that is important is what comes out. So the clarification
`is not really needed.
`Samsung shares the opinion that the “cancelling” is quite complex and they have a separate
`contribution.
`
`=> Noted: cancelling should be sufficiently clearly specified already.
`
`5.1.1.5
`
`UL Information for scheduler
`
`E.g. derail’: qfB.S'R mfcidarfoir. the rln-c.s'hoM based repo:-ring (msi.-llr L,-feimuf cf:'.s'c:rs.s':'oir [Hmni-ei,’,l. derm'e’.s' ofthe power her.-:.’r-oo.-n report.-‘rig.
`
`BSR calculation
`
`Ericsson
`R2-081450: Text proposal for the BSR calculation
`-
`LG wonders if the PDCP header is considered ? Ericsson clarified that the PDCP header is
`considered. RLCIMAC headers are not considered.
`
`=> MAC text proposal is agreed
`
`R2-081451: Clarification of the BSR calculation Ericsson. CR 36.322, REL-8
`=> Last bullet should be “and RLC PDU segments” not “or RLC PDU segments"
`-
`LG wonders if there could be multiple RLC control PDU’s or only 1 ? Probably max 1 today
`but we can leave it like it is for potential future additional control PDU‘s.
`NSN wonders whether the control PDU would really be buffered ? Ericsson asks when the
`control PDU would be re-assembled ? LG has a contribution on this. NSN assumes that since
`
`—
`
`-
`
`the BSR reflects the buffer status after the current MAC PDU has been built, there should be
`no control PDU left. Can anyway leave it like it is.
`Samsung thinks “that have been negatively acknowiedged" is not needed. E.g. also a polling
`could trigger a retransmission without receiving a negative acknowledgement.
`=> Can remove “that have been negatively acknowledged"
`=> Technically endorsed with the changes
`
`R2-081452: Clarification of the BSR calculation Ericsson, CR 36.323 REL-8
`-
`Samsung thinks the second part is a bit misleading. Probably always a handover happened
`sometime before. So “has previously received an indication from upper layer that a handover
`occurred" is almost always true. Ericsson thinks the following part should only be executed
`when at least one handover has taken place.
`QC remarks that the succesfull delivery could be indicated by the lower layers or the status
`report. Ericsson thinks this would be ok but not needed because on receipt of a status report
`the PDU’s are already no longer considered for retransmission. LG shares the same concern
`from QC. It would be better to have a complete description here.
`It was suggested to add “or by receipt of a PDCP status report” (in addition to lower layer
`indication). However QC thinks that it would be easier to just refer to "PDCP SDU’s that
`require retransmission" since that is already clarified elsewhere. LG would prefer to define it
`also here.
`
`-
`
`-
`
`=> Add "or by receipt of a PDCP status report" (in addition to lower layer indication).
`=> In the second part of the description, it is missing that PDU’s given to the lower layer after
`handover shoutd not be counted any more.
`It is clarified that a PDCP SDU can have been processed by PDCP before the handover, but
`it still remains a PDCP SDU so that it can be reprocessed after handover. IDT thinks this
`could be clarified.
`
`-
`
`=> Technically endorsed with the above changes
`
`R2-081627:
`
`-
`
`-
`
`SDU discard impact on BSR calculation ZTE
`-
`NSN thinks as tong as a PDU is not discarded it can be retransmitted and it should be
`considered. Ericsson agrees with this comment.
`ZTE thinks it is only a general principle: the text proposal can be rephrased to be more
`precise.
`ZTE thinks that it is already clear that when the SDU is discarded, then they are no longer
`retransmittedfcounted. However if you would not have the proposed clarification, you will get
`an UL grant which is unnecessary high (waste of resources).
`Huawei thinks this cannot really work well; you don't know when you get the grant.
`Ericsson thinks that anyway we should not discard that often so there is no reason to
`optimise this reporting to the last bit.
`
`-
`-
`
`91' ’ 134
`
`ZTE/HTC
`Exhibit 1017-0297
`
`ZTE/HTC
`Exhibit 1017-0297
`
`

`
`2 Report of TSG RAN WG2 #61bis. Shenzhen. China, March 31 — April 4. 2008
`
`=> Noted
`
`R2-081628: Details of BSR calculation ZTE
`
`-
`
`Panasonic clarifies that semi-persistent resources are not limited to a logical channel (per
`UE). So the proposal does not seem possible.
`NSN thinks that even if we would find a way to remove the persistent allocation from the
`BSR, still it would probably not be good because the persistent grant could be ovenrvritten
`=> Noted (no support)
`
`-
`
`Threshold based BSR
`
`R2-081856: Summary of email discussion: Threshold BSR triggerHuawei (rapporteur)
`-
`Ericsson does not see a big use case for this trigger. However if RAN2 really wants to have
`this trigger, then Ericsson has a view on how it should look. if we continue with this we should
`first try to agree on a use case for this.
`Huawei agrees that this is not so important for system operation.
`-
`=> No threshold based BSR in Rel-8.
`
`R2-081455: BSR triggers based on buffer level change Ericsson
`=> Noted without presentation
`R2-081534: Threshold based BSR trigger Samsung
`=> Noted without presentation
`
`“Pending SR"
`R2-081597:
`Issues with scheduling request procedure LG Electronics Inc.
`Proposal 1:
`-
`Samsung thinks the proposal is consistent with SR handling.
`-
`Ericsson thinks that based on the Monday procedure, Ericsson assumed an endless RA
`procedure. 80 this repeated triggering would not be needed. NSN had the same comment.
`=> Not needed based on Monday discussion
`Proposal 2:
`—
`Samsung thinks the proposal is technically correct, but it is a corner case. Samsung thinks
`we could leave this to implementation.
`Chairman asks if it is the common understanding whether the UE is monitoring with 2 RNTl’s
`in this case. This is the LG assumption.
`LG clarifies that depending on which grant the UE decides to respond to, his UL scrambling
`will be different.
`
`-
`
`-
`
`-
`
`NSN thinks that the UL-SCH might be larger and thus more important. So it is not clear which
`way is better.
`=> Agree to include a note in the specifications that if the UE receives both a grant on RA-RNTI
`and on C-RNTI, it is up to UE implementation which one he continues with
`
`R2-081848: BSR consideration when Contention Resolution failure ASUSTeK
`
`-
`
`Samsung thinks we should address the reliability of the BSR delivery in general, but probably
`not by specifying an additional trigger. E.g. there is aiso the case that the BSR is not
`delivered due to HARQ failure.
`
`-
`
`Ericsson thinks with the endless repetition and the buffering in MAC as discussed on
`Monday, this is not required anymore.
`- Asustek that repetition in MAC could lead to an old BSR. Chairman proposes to first discuss
`the Monday mechanism in more detail. Then we can later see if futher enhancements are
`needed.
`=> Noted
`
`SR avoidance
`
`R2-081468: Triggering of SR in relation to allocated uplink grants Ericsson
`Proposal 1
`-
`LG agrees with the intention of the proposal, but thinks that an alternative is to consider the
`“SR pending” until UL grant is received up to the actual transmission.
`- Motorola thinks this is almost an artefact of the way the MAC spec is written. So instead of
`writing "if a grant is received for this Til” to “if a grant has been received”. Ericsson does not
`want to delay an SR eg. for 2Ums if the next persistent grant only comes in 20ms.
`
`92/ 134
`
`ZTE/HTC
`Exhibit 1017-0298
`
`ZTE/HTC
`Exhibit 1017-0298
`
`

`
`2 Report of TSG RAN WG2 #61bis. Shenzhen. China, March 31 — April 4. 2008
`
`-
`
`-
`
`-
`-
`
`QC indicates that it seems to assume that even though the UE has 3ms processing time, still
`the UE is able to process it quicker.
`NSN wonders what the gain is by not sending SR. eNB can anyway ignore it because he
`knows the UE witl perform an UL transmission. Motoroia thinks that the UE could have lost
`the PDCCH and then not sending the SR could help.
`Anyway the SR is a dedicated resource.
`Ericsson thinks that the 3ms is only when the UE has to be ready for the UL tx. He will realise
`this a bit in advance.
`
`-
`
`-
`
`-
`
`Samsung thinks there might be a benefit of this in case of a SR-RA. However Samsung
`assumes that this is an optimisation ofa corner case.
`=> Noted; no support
`Proposal 2
`-
`NSN wonders if this is not just a configuration issue. You should be able to avoid this
`unnecessary triggering if the SR is configured immediately after the semi-persistent UL
`allocation. NSN admits that you need to know the inter-packet time for this, however you
`need this knowledge also to do the semi-persistent allocation in the first place.
`Ericsson thinks if you really want to use this type of approach, you would have the semi-
`persistent allocation non-aligned to the speech packet generation moment from the codec.
`NTT DCM is quite supportive of the proposal. E.g. if we would use speech packet grouping
`and only allow an SR every 40ms, you would delay other services unacceptably.
`LG supports the Ericsson proposal.
`QC assumes that we always have dedicated SR when there is semi-persistent resources. So
`we don’t have to be afraid of unnecessary SR.
`Philips supports the proposal. Philips wonders how you configure the LCG specific delay ?
`Ericsson would like to use RRC signalling.
`Chairman asks if this would not cause delay for silence packets and speech burst start.
`Ericsson clarifies that the prohibit timer is counting back from the next available semi-
`persistent resource. So there would be no problem in these cases.
`QC wonders if we are not only talking about an optimisation (VOIP can live with 40ms delay,
`but other service and SRB cannot) ? Ericsson thinks 40ms is just an example. E.g. bundling 3
`speech packets resuits in 60ms.
`QC wonders how often this is really usefull ?
`-
`- Motorola sees nothing breaking if this is not in Rel-B. NSN has the same opinion and thinks it
`is an optimisation that is not required. Samsung speech-bundling is not typical case with
`semi-persistent resource allocation. So Samsung also thinks this is not essential for Rel-8.
`=> Noted (some support, but more lobbying is required)
`
`-
`-
`
`-
`
`-
`
`-
`
`R2-081598:
`
`R2-081767:
`
`Other
`R2-081574:
`
`BSR for persistent scheduling LG Electronics Inc.
`-
`LG thinks that when the D-SR is not configured, this can be a significant optimisation. QC
`cannot think of a good reason not to configure SR when you have semi-persistent
`allocationsltalk-spurt type of allocations.
`QC assumes that even if an SR is triggered. the network might ignore it. QC thinks we do not
`need an optimisation or the case of semi-pers and RA-SR only.
`Samsung thinks we shall configure SR when we have VOIP for transition to talk-spurt.
`-
`=> Noted (similar situation as previous document)
`
`-
`
`Triggering of Scheduling Request Philips
`=> Noted
`
`-
`
`Signalling and configuration of CC}! reporting Panasonic
`-
`NSN wonders what the motivation is for the different reporting for the periodic CQI report.
`NSN assumes that for periodic we would only configure one type. Then if we want another
`type, we would poil.
`Panasonic indicates that 36.213 already includes muitipie CQI types. Panasonic thinks that
`according to RAN1 it is already possible to configure multiple periodic CQI types. NSN sees
`no strong need to alternate. NSN would prefer to have an input from RAN1 on this.
`In the NSN opinion, it would be sufficient to configure 1 type for periodic reporting, and 1 type
`for the triggered CQI.
`
`-
`
`93’ 134
`
`ZTE/HTC
`Exhibit 1017-0299
`
`ZTE/HTC
`Exhibit 1017-0299
`
`

`
`2 Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2008
`
`-
`
`Panasonic assumes that even if we have only 1 type, still we could be reporting for different
`bands (for the band specific CQI report). Then you still need to configure when the different
`bands are reported.
`=> Noted (would be good to have a LS from RAN1 what flexibility is really essential; the simpler
`the better).
`
`-
`
`-
`
`R2-081655: Additional BSR triggers HUAWEI
`-
`NSN wonders whether this keeps track for every single byte in the buffer whether it was part
`of a previously reported BSR ? Huawei confirms.
`Ericsson wonders ifthis is needed. In this case the UE would not report empty buffers. In
`addition this can be solved by having a periodic trigger ?
`Huawei thinks that the absence of padding could be used as an indication that there might
`still be data. However the eNB does not know which RB. So the eNB might schedule the UE
`with the wrong urgency. Huawei agrees that the periodic BSR could solve this but you wouid
`have to set the timer quite short.
`NTT DCM has some sympathy for the proposal. Previously NTT DCM proposed the BSR poll
`bit which could be used for a similar purpose. However when we decided to go for periodic
`BSR, it was also assumed that these cases are handled by periodic BSR. So we should stick
`to that assumption now.
`Huawei thinks that in order to use the periodic, you have to set the trigger very short.
`Ericsson thinks the period does not have to be set very short. And in addition the eNB could
`always give an UL grant to the UE and find out if it contains lower priority data.
`=> Noted
`
`-
`
`-
`
`R2-081880:
`
`LCG reconfiguration via MAC CE Sunplus mMobi|e Inc.
`-
`QC would prefer to use RRC and have the benefits of RLC-AM.
`-
`LG wonders if which case we want to change the LCG grouping ? Sunplus refers to the
`beginning of section 2. LG assumes that the LCG grouping related to the priorities. If the
`priorities are stable. also the LCG grouping should be quite stable. Sunplus thinks this might
`happen during RB SETUP. LG thinks that anyway then you need RRC signalling.
`Panasonic this we have already agreed that logical channels are directly mapped to an LCG.
`Furthermore, proposals 2 and 3 are implementation issues.
`Ericsson also prefers RRC signalling
`-
`=> Noted (will use RRC signalling, should be required infrequently, actual allocation is
`implementation dependant).
`
`—
`
`5.1.1.6
`
`Random Access procedure
`
`R/IFH anode! l’,'rJr'c'l':.-r'e,l. M5g.? details to be r.-g:'eed'. RA CH irijfo in HO—('0rnpIele 9 Onl'_1‘ one or more lhrm one mw.=p.5.=.=g c_1-‘cafes .9 R/l—RNTI n:r.flre
`rilfccolian. ....Derm'l'.s'fnr DI‘. darn r'e.mming rag. PLlCC'Hformar,i.
`
`RA-RNTI allocation
`
`R2-081673: RA-RNTI design CATT
`-
`Ericsson is wondering how many simultaneous PRACH’s there could be in TDD ? Ericsson
`understands it can be up to 9. CATT thinks we should align to the RAN1 agreement whatever
`the number is.
`
`-
`
`-
`
`Samsung wonders why we do not sent the RA-RNTI along with the PRACH configuration ?
`GATT indicates this would cost broadcast overhead, and it would increase the handover
`command. Samsung wonders whether this is thus mainly a signalling optimisation. Yes.
`Huawei agrees with CATT that it would be good to avoid sending it when it seems relatively
`easy.
`- Motorola is also fine with an automatic numbering. However Motorola is concerned about
`limiting the window size to 10 TTl’s. GATT thinks the window size can be discussed. CATT
`assumes 10ms is sufficient.
`
`-
`
`-
`
`QC likes the proposal, and does not think a window larger than 10ms is needed (4ms should
`already be quite ok; it is related to the asymmetry in UUDL, but 4 or 5 should be ok).
`Huawei wonders if windows > 10ms are really needed if we also have backoff. Motorola
`thinks for FDD a 1-Sims window is enough. However for TDD there might not be so many DL
`opportunities to sent Msg2. QC is talking about 10 downlink subframes. Motorola thinks that
`in such a proposal spanning several frames, the proposed solution would not work.
`
`94/ 134
`
`ZTE/HTC
`Exhibit 1017-0300
`
`ZTE/HTC
`Exhibit 1017-0300
`
`

`
`2 Report of TSG RAN WG2 #61bis. Shenzhen. China, March 31 — April 4. 2008
`
`-
`
`Samsung still wonders why this is really needed if it is only a signalling optimisation. We can
`probably optimise in other ways (e.g. only signal number of lowest LSB's). Typically there is
`only 1-3 RACH‘s. LG also thinks this is only an optimisation.
`Can we assume that a UE accessing PRACH in a cell is aware of all PRACH‘s in the cell ?
`-
`For FDD, Ericsson assumes that by only signalling 1 PRACH configuration, you will know the
`complete PRACH configuration
`- Motorola assumes that also for TDD a similar table will be created. So the UE would also eg.
`be aware of the complete configuration at handover.
`Is it sufficient to limit the window to 1 frame, or should it be possible to have windows larger than
`1 frame ?
`
`Samsung assumes 10 subframes is sufficient.
`-
`- Motorola assumes that a solution should be able to extend behond 1 frame (> 10 subframes)
`because of TDD scenario
`
`-
`
`CATT thinks that when the number of DL subframes is small in the configuration. also the
`user density is small. So CATT assumes that in TDD the response can always be handled in
`10rns.
`=> Noted
`
`R2-081559: RA window and RA-RNTI allocation Qualcomm Europe
`-
`QC assumes 9 is to high for pratical purposes. and assumes it is sufficient to only go up to 4.
`Section 2.2:
`
`-
`
`So proposal is to have the window start “3 or 4 or 5” (fixed value) after "N” with "N” the end of
`the PRACH transmission.
`
`-
`
`Ericsson thought the LS indicated that the UE does not need to be able to reply before “N+4",
`however future UE's could reply earlier up to "N+2". Ericsson thinks that for TDD more
`flexibility might be needed. So uncertain if a hard coded value is sufficient.
`- Motorola is fine with coupling the window-start fixed to the minimum processing start. NSN
`also prefers to fix it to “2" so that it does not need to be changed in the future.
`Section 2.3
`
`-
`—
`
`Proposal is to signal a window width system information and handover command.
`NTT DCM assumes we are going to define a maximum window value. Then why would we
`want to set the value shorter than the maximum. QC ciarifies it decreases the ramping cycle
`RTT.
`
`-
`
`Huawei wonders if this is really a big gain. QC indicates the gain depends on the PRACH
`configuration.
`Ericsson assumes we need to configure the window width.
`-
`=> Noted
`
`R2-081842: Mapping between RA-RNTI and PRACH resource
`=> Noted (same proposal as CATTIQC)
`
`HUAWEI
`
`R2-081824: RA-RNTI Allocation Motorola
`-
`Nokia assumes that a 10ms window is sufficient. Nokia assumes 10 DL subframes window
`
`size is always sufficient. Motorola clarifies that a window of 10 DL subframes might span
`many frames in TDD.
`
`R2-081622: Mapping between RA-RNTI and random access slot ZTE
`-
`QC thinks saving 45 out of 64000 RNTl’s (compared to the CATT proposal) is not really an
`issue.
`
`-
`
`-
`
`-
`
`-
`
`Ericsson thinks it would be relatively simple to just give a number to the configured RACH
`occasions.
`
`Ericsson assumes TDD cells are always SFN synchronised. So we could say that unless the
`cells are synchronised, a window larger than a frame should not be used.
`Samsung thinks it would be good to also agree for TDD on a max window of 10 subframes
`(could mean only 2 DL subframes). Anyway the load can be handled by backofi.
`Ericsson thinks it would also depend on the eNB processing delay. So maybe effectively
`there is only 1 DL subframe.
`
`Agreements:
`1) RA window begin is in the 3"’ subframe after the PRACH transmission end (fixed value)
`
`95/ 134
`
`ZTE/HTC
`Exhibit 1017-0301
`
`ZTE/HTC
`Exhibit 1017-0301
`
`

`
`2 Report of TSG RAN WG2 #61bis. Shenzhen. China, March 31 — April 4. 2008
`
`2) Will indicate the RA response window size in system infoihandover command.
`Granularity is FFS.
`3) RA window end is set to the subframe occurring RA response window size DL
`subframes after RA window begin
`4) We will use an automatic allocation for the RA-RNTl's
`5) Any RA-RNTI solution should meet the following constraints:
`a) can assume the UE is aware of the complete PRACH configuration in a cell
`b)
`for FDD there is no need to support windows larger than 10 subframes
`c} FFS what the maximum window size to be supported for TDD would need to be
`6) Different options:
`a) A-RNTI = SubframeNurnber + 1OPRACHlndex
`b) RA-RNTl(t)= (t — RA_WINDOW_BEGIN) + RA_WlNDOW_SlZE*PRachlndex
`c) RA-RNTI = RA-RNTI-COUNT + Sn % N + N*Fi (R2-081622)
`
`It is FFS what the maximum parallel number of PRACH's that needs to be supported for TDD
`shall be (check RAN1 status).
`=> QC will provide OR to capture this for the next meeting w.r.t. agreements.
`=> Offline discussion [CB Friday Motorola offline]
`
`DL data arrival
`
`R2-081558;
`
`PDCCH for DL data arrival Qualcomm Europe
`-
`Ericsson thinks that for proposals 4,5,6, RAN1 should be consulted.
`-
`QC thinks we so far have no indication from RAN1 on the delay between a DL PDCCH and
`UL preamble transmission.
`Proposal 3,4,5,6:
`-
`QC would prefer we take decisions and inform RAN1. Motorola thinks it would be good to ask
`RAN1. Ericsson agrees
`Proposal 3:
`QC assumes that we have not
`-
`LG wonders how this now works with the "endless
`removed the stop condition preab|e_max_retrans for the DL data arrival case.
`Proposal 4:
`-
`LG thinks we should ask how many codepoints are available.
`Proposal 6
`-
`NEC thinks we might need some input from RAN1. Ericsson thinks this is ok given the L1
`response with 4ms.
`CATI’ indicates a potential problem: if N+4 and N+5 have PRACH’s, and you recieve a
`PDCCH in N, you cannot use N+5 (if N+1 is no DL frame). So maybe we need to signal the
`subframe for TDD.
`
`-
`
`Other questions retated to L8:
`-
`NEC questions whether power offset
`—
`QC wonders whether we can agree that we need to specify how soon the UE shall do the first
`attempt ? Either implicitly or explicitly. Motorola thinks we could just say “the first PRACH
`occasion after receival“. Panasonic thinks it is already indicated in the MAC spec that the UE
`shall use the first available RACH resource.
`=> Noted
`
`R2-081467: Assignment of dedicated preamble for DL data arrival
`=> Noted without presentation
`Signalling on DL data arrival NEC
`=> Noted without presentation
`
`R2-081667:
`
`Ericsson
`
`Will sent an L8 to RAN1 indicating our status, and asking them to complete the work w.r.t. the
`issues addressed in proposal 3,4,5,6 in R2-081558.
`Reflect current agreements:
`a) A dedicated PRACH preamble is optionally indicated by PDCCH in case of DL data arrival
`b)
`If dedicated preamble is signalled, no end-time needs to be signalled.
`c)
`If absent, UE must select a Random Access Preamble“
`
`rocessin time is a Iicable. note: revious RAN1 resonse in R2-080590.
`
`Ask whether the same UE processing is applicable as for UL grant, or whether a different
`
`95/ 134
`
`ZTE/HTC
`Exhibit 1017-0302
`
`ZTE/HTC
`Exhibit 1017-0302
`
`

`
`2 Report of TSG RAN WG2 #61bis. Shenzhen, China, March 31 — April 4, 2008
`
`=> LS will be provided in R2-081996 [CB Friday QC]
`
`Msg2 encoding
`R2-081608: DL Assignment in Msg2 LG Electronics Inc.
`-
`NTT DCM wonders whether there is any need for any UL transmission so that the eNB can
`be sure the UE received Msg2, before allocating a DL grant ? NTT DCM had considered this
`solution, but assumes that it would be quite nice to receive an empty BSR in Msg3 in
`response to Msg2, and then the eNB can start to schedule the UE. So in NTT DCM‘s
`understanding, the UL grant field is not totally irrelevant.
`LG thinks it should be a quite rare case that the UE misses the PDCCH. HARQ feedback can
`be used.
`
`-
`
`-
`
`-
`
`LG thinks w.r.t. the UL PUCCH allocation for the ACKINACK for the first DL transmission, the
`eNB can probably do some smart allocations.
`QC thinks this is a clear optimisation, and not really required. Ericsson agrees with this.
`Ericsson thinks potentially the UL grant in Msg2 could atso be used to trigger a CQI report.
`QC thinks you can anyway give a very short UL grant and schedule the UE in the next TTI.
`=> Noted (no support).
`
`Ft2—O81881: RA Response formatsunplus mMobi|e Inc.
`-
`Ericsson thinks that there is no big gain of always having a T-CRNTI (nothing breaks). QC
`shares this opinion.
`No support for introducing the optional presence of T-CRNTI.
`-
`=> Noted
`
`C-RNTI encoding in llllsg2
`-
`Nokia indicates that they would be fine not to consider any optimisations. Samsung is also ok with this. LG
`is also fine with this.
`Huawei thinks there are optimisations that are clear improvements and they don’t bring that much
`complexity. However Huawei can agree they are not essential.
`QC thinks potentially we can even extend the format for Rel-8 e.g.when we have different sets of
`preambles.
`
`-
`
`-
`
`R2-081512: On setting the C-RNTI in RACH message two Nokia Corporation, Nokia Siemens Networks
`R2-081517: Allocation of a “short” CRNTI in rnsg2
`LG Electronics Inc.
`R2-081535: Scheme for C-RNTI Assignment in RACH Samsung
`R2-081652: T-CRNTI assignment in Msg2 HUAWEI
`=> All noted without presentation. Agree that no optimisations are needed for the T-CRNTI
`allocation in Msgz in Rel-8
`
`Other issues
`
`R2-081908: Grants to Temporary C-RNTI Ericsson
`-
`Nokia wonders whether this means that the UE should be listening to the T-CRNTI and the
`C-RNTI all the timer ? Ericsson indicates only from receiving the Msg2 up to Msg4lcontention
`timer expiry.
`- Motorola wonders whether the main benefit is to allow adaptive retransmissions for Msg3 ?
`yes. Currently you cannot do adaptive retransmissions.
`It was questioned why in the middle case of page 3 it is proposed to discard the T-CRNTI ?
`-
`=> Agree that in the succesfull case, we should indicate the promotion, not only the discarding.
`=> Don't have to repeat “the UE shall" in the last sentence of 5.1.5
`-
`Panasonic wonders whether we also allow "suspension" for Msg3 ? Ericsson assumes
`normal handling is applicable.
`=> Agree to this text proposal with the 2 changes.
`
`R2-081605:
`
`LG Electronics Inc.
`Issues on Setting Temporary C-RNTI
`-
`The two points are the timing of the T-CRNTI setting, and the remark w.r.t. the scrambling
`code.
`
`Scrambling of Msg3
`-
`QC thinks scrambling is not so important for M393. It is also one more thing that the UE has
`to do very quickly. Could use CRNT|=0 for scrambling as long as we don‘t have a CRNTI.
`
`97’ 134
`
`ZTE/HTC
`Exhibit 1017-0303
`
`ZTE/HTC
`Exhibit 1017-0303
`
`

`
`2 Report of TSG RAN WG2 #61bis. Shenzhen. China, March 31 — April 4. 2008
`
`-
`
`-
`
`Ericsson thinks we could also use the RA-RNTI.
`
`Samsung EISSUITIBS the simplest approach lS we U38 the UE-specific RNTI TOT all C3385, 50 T-
`CRNTI.
`
`Ericsson has no strong preference.
`-
`=> Can check offline what the RAN1 status is.
`
`R2-081606: Restriction of PDCCH used for Contention Resolution
`UL data arrival case:
`
`LG Electronics Inc.
`
`- W.r.t. UL data arrival, Samsung does not understand why the polling case needs to be
`excluded..
`
`-
`
`Samsung agrees that any sensible network would not poll for CO! on UL data arrival, but we
`do not have to exclude that case.
`
`-
`
`-
`
`QC wonders if the UL data arrival case conflicting with a DL allocation on PDCCH would only
`occur when there is a misalignment in TA timer ?
`Fujitsu think that the timer of eNB and UE will not be perfectly synchronised, so this case
`might happen.
`Panasonic does not see a big problem.
`NTT DCM also thinks this is quite a rare case.
`LG points out that if we do not handle this. e.g. an UL BSR might be lost and the UE would
`be stalling (UE assumes he has delivered BSR).
`Samsung thinks it is not an extremely rare case. If this happens and the BSR was triggered
`by SR8 (highest priority data), there will be no new trigger.
`DL data arrival case
`
`-
`-
`-
`
`-
`
`-
`
`For the DL data case, Samsung assumes it is very unlikeiy that you would receive an UL
`grant
`NTT DCM thinks this is a very rare case.
`-
`=> Can come back in next meeting
`
`R2-081607: UL Timing Control related to Contention Resolution LG Electronics Inc.
`Proposal 1:
`—
`It is clarified that proposal 1 is mainly relevant when the TAT was already running. Then if no
`action is taken, the UE might respond with wrong ACKINACK timing to DL allocations.
`- QC thinks if you had a TAT, you can continue to use the UL TA you have (so ignore the value
`signalled in lvlsg2) until contention resolution is resolved.
`Ericsson would prefer to apply the TA-advance, and restore afterwards. However Ericsson is
`also fine with the QC proposal.
`- QC agrees with the principle that a TA received before contention loss should not be applied.
`-
`Samsung agrees QC proposal is fine. LG also agrees with the QC approach and would not
`like to restore.
`
`-
`
`-
`
`-
`-
`
`Ericsson thinks that it would be a bit better if the UE would appty the TA from lvlsg2 (even if
`the TAT was running), because then we have more Iiketihood of having a difference in timing
`between a possibie winning and loosing UE. If the UE continues to apply its old timing (which
`is correct), even though it is the loosing UE, it will anyway interfere more on lvlsg3. It is true
`that the reverting is a bit more complex for the UE in this solution.
`Panasonic thinks there is no big difference in UE complexity with the Ericsson proposal.
`Samsung thinks nothing goes wrong if we do not specify the behaviour for the case the TAT
`is not running.
`
`Potential agreements (Nothing agreed now. Will have to make the final conclusions in the next
`meeting):
`1)
`If TA was runn