- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`-
`
`- Qualcomm considers that we should consider the delay in msec instead of TT|s, so 2 TTls
`of 2 msec, and 1 TTI of 10 msec. Qualcomm considers that 2 msec and 10 msec TTls are
`sufficiently specific that they can be handled independently.
`lnterdigital considers whether we can not just specify the number of RLC PDUs that can be
`created and not need to handle a delay.
`- Qualcomm considers that more RLC PDUs than the number of TTls could be created in
`advance.
`Ericsson considers that the creation should be done based on the current situation.
`
`-
`
`- Open issues (see email discussion 61b_UTRAN):
`o On what should we base the RLC PDU size selection, e.g. grants...
`0 Number of TTls for 2msec and 10 msec
`c Number of RLC PDUs that can be created in advance
`0 How to increase the RLC PDUs
`
`- lnterdigital proposes to create a certain amount of untransmitted RLC PDUs.
`- Qualcomm considers that it would be possible to build RLC PDUs with some
`delay.
`0 How to take care of multiple logical channels
`- Qualcomm considers that the data should be taken in the priority
`o How to handle scheduled and non-scheduled data
`- ALU considers that if in one TTI the was scheduled + non-scheduled data the
`
`E—TFC| would be bigger compared to the case when there would be only
`scheduled data aftenivards.
`
`o How does it work for the delta HARQ depending on the MAC-d flow.
`
`Mixed:
`
`R2-081634 MAC-ifis PDU formatHUAWEl Disc
`
`-
`
`-
`-
`
`-
`
`Ericsson considers that there is no need to change the current agreement, and don't see the
`gain of 10 bits sufficient to change the current agreement.
`Nokia agrees that there is no need to introduce an extra mechanism.
`Huawei considers that there could be some more possible control information that could be
`included in the MAC header. This is mainly for future extensibility.
`Huaweis concern is that there is no possibility for future extension.
`
`R2-081833
`
`RLC buffer management and polling lnterDigital Disc
`- Qualcomm wonders why the buffer overflow would happen, and what is different about the
`flexible RLC that would not happen in the fixed RLC PDU size
`lnterdigital explains that the issue is that today the RNC can calculate a buffer size based on
`the SN space and the PDU size, so choosing the RLC window too low will unnecessarily
`limit this.
`
`-
`
`-
`
`-
`
`- Qualcomm considers that even today there is a need for a flow control between the
`application and the RLC which could prevent the overflow of the RLC buffer
`Ericsson considers that there may be some problem, but that even today we have no
`deterministic assignment, and thus there may not be a real big problem.
`lnterdigital considers that if there is no mechanism specified this would really rely on the fact
`that the RNC creates autonomously status reports. lnterdigital would prefer to have the
`possibility to have some more information.
`Nokia and NSN thinks that there is no need for such a mechanism
`
`-
`
`-
`-
`
`-
`
`-
`
`-
`
`-
`
`lnterdigital considers that if we don‘t specify anything then we end up with option 3.
`lnterdigital wonders whether network vendors have to track the UE buffer, and create the
`Status reports autonomously.
`Ericsson considers that in any way we need to have option 3. Ericsson considers that there
`may be some vatue, but that this is not strictly needed.
`lnterdigital wonders that we are inconsistent then by having a RLC window based
`mechanism, since the network could handle this as well.
`Noted. Might come back if there is more support.
`
`Reconfiguration of L2 protocols between enhanced and non-enhanced cells
`Disc
`
`lnterDigita|
`
`Nokia considers that the cases 1 and 3 for the reconfiguration from flexible to fixed sizezs in
`the UL are quite rare, and that the case of the state transition from CELL_DCH to
`
`R2-081834
`
`Page 45 of 134
`
`ZTE/HTC
`
`Exhibit 1017-0251
`
`ZTE/HTC
`Exhibit 1017-0251
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`CELL_FACH should in the normal case only occur in the case that we have no more data to
`transmit.
`
`Interdigital wonders why the case that there is mobility between Rel-8 and Rel-7 is a rare
`case.
`
`Ericsson considers that the cases 1 and 3 should only be a transitionary case.
`Ericsson considers that the same case that we have for the uplink should apply for the
`downlink.
`
`It is agreed that we support lossless reconfiguration from fixed to flexible RLC PDU size in
`the uplink
`
`Corrections
`
`Correction of a spelling error of E-TFC selection Ericsson CR 25.321
`R2-081504
`Updated in R2-081925
`R2-081925
`Correction of a s ellin
`error of E-TFC selection Ericsson CR 25.321
`The CR (REL-8) is technically endorsed.
`
`I -
`
`I
`
`R2-D81 87?
`
`SamsungCR 25.322
`Introduction of POLL_SUFI for the uplink
`Ericsson wonders how the UE chooses between the Poil Bit and the Poll_Sufi
`Samsung considers that the UE should choose based on the presence of new data. It could
`as well be left to UE implementation
`Ericsson does not consider that the gains will be very big since also in the downlink they
`turn out to be smaller than expected, but at least Ericsson wants the use of the POLL_SUF|
`to be controlled by the network, i.e. is the UE allowed to use POLL_SUF| or not.
`Samsung would be happy to have this network controllabie.
`Samsung wonders why this could not be used by the network.
`Ericsson considers that the gain could be smaller because the cases where the
`retransmission of the last packet could be unnecessary is rather a rare case, since typically
`if the Poll timer expires the last packet has to be retransmitted anyway.
`Samsung considers that there may be 50 percents of the cases.
`Ericsson considers that this only applies to 50% of the poll timers that expire (either the poll
`is lost or the status report)
`Broadcomm considers that if it is not seen usefull by network vendors (i.e. it will not be
`configured) then we better don't have it.
`Nokia thinks that we could leave it open until the next meeting.
`Noted.
`
`R2—08i8'/8
`
`Correction to transmittin AM RLC entit
`The CR {REL-8) is technically endorsed.
`
`-
`
`SamsunCR 25.322
`
`6.4.2
`
`CS voice service over HSPA
`
`(RAN2 W], R[nlmp8-CsHspa, 100%. March 08, closed)
`
`R2-081841
`
`R2-081783
`
`-
`
`-
`
`-
`
`Support for RLC Segmentation in CS voice over HSPA Qualcomm Europe Disc
`Huawei considers that SA4 has pointed out that the RLC SM is important for the dejitter
`buffer handling.
`NSN considers that depending on the UL configuration the TB size can deduced, i.e. clue to
`the fact that the RNC controls the segmentation it can know whether segmentation applies
`or not.
`
`AdHoc chair wonders whether this implies that the Ue has to be controlled by the non-
`scheduled grant.
`Huawei Is in favour of the segmentation in case of 2 msec TTI and wonders whether this
`should be also used for the tomsec TTI
`
`NSN considers that the segmentation would probably only be configured for the 2 msec TTI,
`ut the UE should be allowed to sement as well for the 10 msec 'l'l'l in the secification.
`
`It is agreed to allow segmentation in the UL.
`CS-HSPA UL Segmentation Nokia Siemens Networks, Nokia corporation CR 25.322
`Ericsson rooses some imroved wordin
`
`The CR {REL-8) is technically endorsed.
`
`Page 46 of 134
`
`ZTE/HTC
`
`Exhibit 1017-0252
`
`ZTE/HTC
`Exhibit 1017-0252
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`R2-081839
`
`-
`
`Proposal for Reply to SA4 Qualcomm Europe, Nokia Siemens Networks Disc
`ALU wonders whether there is any specification on how the parameters Max CS delay is
`supposed to be used.
`NSN clarifies that there is a description on how this is used.
`-
`- AdHoc chair proposes to clarify in the last response that the delay is controlled, i.e. there will
`be no additional losses due to late delays.
`Reply Ls based on this in R2-081952
`
`| -
`
`6.4.3
`
`Enhanced Uplink for CELL_FACH State in FDD
`
`(RAN2 W], RANimp-Up1inkEnhStatt:. 50%. June 03)
`
`Resource Release
`
`R2-081501
`
`Implicit release for enhanced uplink in CELL_FACH Ericsson Disc
`- Qualcomm considers that the implicit release for the case of DXCH is not necessarily a
`good idea in order to support the downlink activity. Thus we should rely on the explicit
`release for DXCH_
`Ericsson wonders whether the use is for the Ack Nack in the UL. QC confirms.
`QC clarifies that the UE would maintained with the E-DCH resource until the DL
`transmission would be finished.
`NSN considers that also for the transmission for RLC Acks in the UL the maintenance could
`
`-
`-
`
`-
`
`be a good idea, and if the common resource is released, due to possible backoff the
`transmission of the RLC Ack would then be delayed.
`Ericsson wonders whether for the case where DL traffic is foreseeable it would not be better
`
`-
`
`-
`
`to move the UE to CELL_DCH state.
`- Qualcomm considers that having the UL in order to support the DL is quite usefull for the
`support of the HARQ operation
`Ericsson considers that this feature should be designed in order to be optimal for the case of
`small keep alive traffic for which there is not necessarily a big response.
`NSN agrees to the benefits for the implicit release, but also agree that the E-DCH should
`not be released immediately, but would wait for a small time e.g. several TTls. For the case
`that there would be new data arriving the UE would maintain the E-DCH resource based on
`the timer.
`
`-
`
`- Qualcomm considers that DL and UL should be handled together in the typical TCP case.
`-
`Ericsson considers that adding a timer could be an interesting solution. 5
`
`R2-081581
`
`Empty Buffer Status reporting and Implicit release for CCCH messages using enhanced uplink
`in CELL_FACH Qualcomm Europe Disc
`Interdigital wonders why we would need to modify the SI in order to indicate the empty
`buffer.
`
`QC clarifies that today in MAC it is not allowed to send an Si if the buffer is empty. So the
`trigger has to be changed.
`NSN considers that there would be some interest to limit the maximum message size.
`Noted
`
`-
`
`-
`
`-
`-
`
`MAC model
`
`R2-081503
`
`Location of the MAC-is for CCCH Ericsson Disc
`-
`noted
`
`R2-081770
`
`Some open issues Nokia Corporation, Nokia Siemens Networks Disc
`- Qualcomm considers that the location of MAC-is should rather be in the NodeB due to
`
`-
`-
`
`-
`
`Nokias arguments.
`Huawei prefers to have the MAC-is in the CRNC
`Ericsson wonders why there is a different impact of static resources in the controlling RNC
`or in the NodeB
`
`NSN considers that the RNC is not aware of the EDCH resource usage, thus it can not
`allocate the resources depending on the allocation of the EDCH resources. The NodeB can
`flush the buffer when the EDCH resources are reteased. the CRNC has to wait until a timer
`expires.
`
`Page 47 of 134
`
`ZTE/HTC
`
`Exhibit 1017-0253
`
`ZTE/HTC
`Exhibit 1017-0253
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`-
`
`-
`
`-
`-
`
`-
`-
`
`-
`
`Ericsson wonders whether the RNC would then be a bottleneck. NSN considers that there is
`
`no principal probiem. just a question of dimensioning.
`Ericsson considers that there can be some multiplexing gain if the queue is located in the
`network.
`
`NSN considers that there is a gain in the scalability if the MAC-is for CCCH is in the NodeB.
`Huawei wonders why the processing and buffer requirements would be increased
`significantly. NSN clarifies that the impact from CCCH may not be too large.
`It is agreed that the MAC-is for CCCH is placed in the CRNC
`It is agreed that an E-RNTI can be allocated to UEs in CELL_PCH state. and that the UE
`can autonomously enter CELL_FACH from CELL_PCH and start DTCHKDCCH transmission
`with the E-DCH enhanced random access without sending a CELL UPDATE message to
`request state transition
`It is agreed that we do not allow data flow for CCCHIDTCH I DCCH mapped to FACHlE-
`DCH, Le. a UE that supports E-DCH in the CELL_FACH state has to support HS-DSCH in
`the CELL_FACH state, and a NodeB that supports E-DCH in the CELL_FACH state has to
`support HS-DSCH in the CELL_FACH state.
`
`Aggiicahilig of E-DCH in CELL FACH state
`
`R2-081663
`
`Common E-DCH usage in CELL_FACH state HUAWEI Disc
`NSN considered that in the case that the UE is already in CELL_FACH state for DTCH and
`DCCH the UE is only allowed to use E-DCH if the E-RNTI is provided. Thus it is the SRNC
`responsibility to make sure that both NodeB, CRNC and SRNC are able to handle the E-
`DCH in CELL_FACH state.
`lnterdigital asks whether there is no need for the fallback to the R99 RACH for the case of
`e.g. congestion on the E-DCH for CELL_FACH
`Huawei considers that the blocking probability should not be a very big problem.
`It is agreed that the UE uses the E-DCH for CCCH in all cases when the UE and the NodeB
`are capable of E-DCH in CELL_FACH state
`Adhoc chair wonders whether there is an impact on the lur in order to setup the Common
`Transport Channel resources for the use of E-DCH
`NSN clarifies that there would anyway be a need for an update.
`ALU considers that if there is an inconsistency, then there will be an RRC connection
`release in the case that the SRNC does not support the HS-DSCH in the DL. and probably
`the capability of E-DCH in CELL_FACH state, as well as the capability of E-DCH in
`CELL_FACH state would be the same for both.
`Huawei considers that the scenario will only occur in the case that the case only occurs if
`the HS-DSCH is supported in both the CRNC and the SRNC.
`ALU considers that this case would be temporary, and thus there would be no need to be
`able to maintain the connection if the SRNC is not E-DCH capable for CELL_FACH.
`Ericsson prefers the solution 2.
`Huawei prefers the solution 2.
`Have an L8 to RAN3 stating that RAN2 has a preference for the scenario 2 by Huawei in
`R2-081966.
`
`-
`
`-
`
`-
`-
`
`-
`
`-
`-
`
`-
`
`-
`
`-
`-
`-
`
`Content of E-AGCH
`
`R2-081817
`
`E-DCH explicit resource release with E-AGCH Qualcomm Europe Disc
`- Qualcomm proposes to reserve the highest TIP value or the “lNACTlVE" E-AGCH code
`point with the absolute grant scope of the E-AGCH set to “all HARQ processes” to indicate
`an E-DCH resource release
`
`-
`
`Infl neon wouid prefer to use the “INACTIVE" E-AG-CH code point
`
`R2-081582
`
`Content of E-AGCH for contention resolution, scheduling and explicit resource release
`lnfineon Disc
`
`Updated in R2-081986
`
`R2-081986
`
`Content of E-AGCH for contention resolution, scheduling and explicit resource release
`lnfineon
`
`Page 48 of 134
`
`ZTE/HTC
`
`Exhibit 1017-0254
`
`ZTE/HTC
`Exhibit 1017-0254
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`Interdigital wonders whether the network will still have sufficient control on the load if we
`remove the active I inactive state, e.g. in order to protect the UE from a strong interferer in a
`certain HARQ process.
`NSN considers that this feature for this is not necessary since the transmission is anyway
`started with all processes active, and the transmission will be rather short.
`It is agreed that:
`the Absolute Grant Scope is always set to “All HARQ process"
`we only use one E-RNTI for E-DCH in CELL_FACH state
`the inactive value is used for the resource release
`
`Back-off operation for enhanced uplink in CELL_FACH Ericsson Disc
`LGE comments that in Rel-99 the duration of the resource usage is only one TTI, whereas
`in the E-DCH the resource usage might be longer, so therefore a UE specific control would
`be necessary instead of a general backoff.
`Ericsson wonders whether the backoff would be determined based on the duration when the
`UE uses the resources.
`LGE comments that it is not based on the duration.
`
`Ericsson considers that there is a need for the backoff mostly for the case of collisions, and
`not dependend on the time of usage.
`NSN wonders whether the same backof time would be used for NACK and at explicit
`resource relese.
`
`Ericsson confirms. The intention is to have a different configuration compared to R99
`RACH.
`
`NEG wonders whether this kind of topic should rather be discussed in RAN1 or RAN2.
`RRM is a RAN2 issue, so it would be good to have this handled in RAN2.
`Samsung wonders whether the same backoff parameter is used in the case of unsuccessfuil
`contention resolution and contention.
`
`Backoff
`
`R2-081502
`
`-
`
`-
`
`-
`
`-
`
`—
`
`-
`
`-
`
`-
`
`-
`
`-
`-
`-
`
`-
`
`Samsung considers that the case of contention this is not related to the load situation but.
`So Samsung would like to consider this case differently. So this case should be similar to
`the case when the transmission is stopped.
`- Qualcomm wonders whether there could not be a possibitity to do load balancing using eg.
`the E-AICH channel.
`
`-
`
`Ericsson wonders whether this would imply that there would be the same resources on
`different frequencies.
`It is agreed to have E-DCH specific parameters for the backoff similar to R99
`No UE specific backoff para meters
`Different cases are FFS
`
`-
`
`R2-081829
`
`Load Management on E-DCH resource Release LG Electronics Inc. Disc
`NSN wonders whether this is too complex, and whether this really is worth the effort.
`LGE considers that in the case of E-DCH there is a need for a type of backoff.
`NSN considers that backing off for a certain time is not really a metric for the backoff, but
`the UE should come again as soon as a resource is available.
`Ericsson wonders whether this is depending on the subscriber type, or whether it is
`dependant on the type of data.
`LGe considers that it could depend on the service, or based on charging;
`NSN considers that the problem is not really necessary to be addressed.
`LGE wonders whether the backoff is going to be dependent on the ASC
`NSN wonders what is the use of backing off a certain UE more than another UE. Depending
`on the Q08 it woutd rather stop the connection.
`So far there is no support for a UE specific mechanism.
`
`-
`-
`-
`
`-
`
`-
`-
`-
`-
`
`-
`
`Transition to CELL DCH
`
`R2-081649
`
`Traffic Volume Measurement for enhanced Cell FACH HUAWEI Disc
`
`-
`
`It is agreed to have an RRC message that triggers the state transition to CELL_DCH
`
`Page 49 of 134
`
`ZTE/HTC
`
`Exhibit 1017-0255
`
`ZTE/HTC
`Exhibit 1017-0255
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`R2—0819(}4
`
`-
`
`quick switch to macro diversityLG Electronics Inc. Disc
`- Qualcomm wonders whether TVM would not be the most natural message to be used, so
`what specific would need to be done there.
`LGE clarifies that currently if the event 4a is triggered the UE sends the measurement
`result. LGE considers that also the event 1a should be evaluated to trigger the transmission
`of such a message.
`ALU wonders when the measurement would be sent once that event 1a is triggered and
`whether for option 2 the UE is waiting that a Cel|_Update r'TV|'v1 would be triggered.
`LGE considers that this is applicable only when E-DCH is used in CEi.L_FACH state.
`ALU wonders whether this is done in the case when the UE is CELL_FACH without E-DCH,
`or whether this is only done when an E-DCH transmission is already ongoing.
`Noted for this meeting.
`
`-
`
`-
`-
`
`-
`
`R2-081653
`
`State transition from enhanced CELL_FACH to CELL_DCH state HUAWEI Disc
`
`- Adhoc chair wonders what is the common E-DCh E-RNTI. Huawei considers that there is a
`different E-RNTI used for common E-DCH.
`
`-
`-
`-
`
`-
`-
`-
`
`NSN wonders what is the explicit E-DCH release in the case of the transition.
`Huawei considers that this for security reasons.
`Huawei wonders whether the assumption is that we have to change the E-RNTI in the case
`that we transit to CELL_DCH.
`lnterdigital wonders whether we would have the same problem if we have an activation time.
`NSN still considers that the NodeB would have to know which UE we are moving.
`Huawei considers that today there is no possibility to use the activation time at transition
`from CELL_FACH state to CELL_DCH state.
`- Qualcomm wonders whether this would imply that the NodeB has to monitor for a period of
`time both scrambling codes.
`NSN considers that this is the case, ie. the UE is still receiving the common resource while
`detecting the dedicated resource.
`lnfineon wonders what would happen if the transition to the dedicated resource fails. Does
`the UE have to initiate a new RACH procedure or go back to the common resource?
`Huawei prefers that the UE performs another random access.
`NSN agrees with this.
`It is agreed that;
`the typical transition from CELL_FACH using E-DCH resources would be RB Control
`message with activation time now.
`We need a possibility in RAN3 to match the common resource to the dedicated resource
`The release of the common resource is implicitly learned by the NodeB due to the detection
`of the UE on the dedicated resource.
`-
`This information will be included in the L3 to RAN3.
`Add in the LS that the MAC-is is placed in the CRNC
`
`-
`
`-
`
`-
`-
`-
`
`Inter cell Interference
`
`R2-081619
`
`Cell Reselectton while transmitting E-DCH in CELL_FACH Qualcomm Europe Disc
`NSN highlights that the system simulations assume that all the UL load is carried over E-
`DCH in CELL_FACH, but that in reality there should be a proportion of UEs as well in
`CELL_DCH state.
`NSN states that this is considering only UEs in CELL_FACH states, and that we should
`consider also other scenarios
`
`-
`
`-
`
`- Qualcomm considers that this is an ongoing study
`- Motorola wonders whether there is an impact on the UE, and on whether there the pathloss
`difference measurement is a new measurement.
`
`- Motorola wonders which UEs are supposed to be measured, an how long they would be
`measured.
`
`- Qualcomm comments that this is a measurement that is performed on the neighbouring
`cells. The measurement envisaged is the Ecflo, and not the pathloss.
`lnterdigital agrees that there is a problem for the RoT caused by these measurements and
`wonders.
`
`-
`
`Page 50 of 134
`
`ZTE/HTC
`
`Exhibit 1017-0256
`
`ZTE/HTC
`Exhibit 1017-0256
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`-
`
`Nokia considers that the fast fading in the UE is filtered out, and the period for the
`measurement is in the order of 200 msec, so the UE would then anyway he in CELL_DCH.
`- Qualcomm highlights that the Treselection time is in the order of seconds (at least 1 second)
`so the UE could not be on the best cell.
`
`-
`
`-
`
`-
`-
`
`Proposal 1)
`Expediate the transition to CELL_DCH softhandover based on the measurements of the
`neighbouring cells in addition to buffer measurements.
`Ericsson considers that there is no need to trigger the TVM on a different criteria than the
`buffer load
`
`Huawei considers that the TVM only based on the buffer load is sufficient.
`Proposal 2)
`Reduce the data rate on E-DCH
`
`-
`
`Ericsson considers that the typical cells that have probiems could be handled by setting a
`lower grant, and that thus would be adjusted on a longer term and not case by case.
`- Qualcomm considers that the NodeB can not know the situation of the UE, and that it should
`not be restricted for all UEs.
`
`R2-081812
`
`R2—-J81835
`
`-
`
`-
`
`E-DCH interference in CELL_FACH Ericsson Disc
`Noted
`
`Path loss variations during E-DCH transmission in Cell_FACH interDigital Disc
`NSN considers that only the UEs that that fulfil all conditions would create a certain problem,
`so the issues is not worth to be addressed.
`
`lnterdigital considers that these UEs cause a rather severe damage to the system.
`-
`- Motorola comments that the UE should be allocated a low grant in any way due to the fact
`that the pathioss to the current cell is considered rather high.
`lnterdigital considers that this is even worst.
`-
`- Motorola considers that the power headroom would be even worse.
`- Motorola states that reducing the grant could only reduce the interference only partly, since
`high interference is created by the DPDCH.
`NSN considers that if this is really a problem then already today we would have a problem,
`since today most of the networks don't move the UE to macro diversity.
`- Qualcomm considers that in R99 there is not much data sent on the RACH.
`
`-
`
`Mobility
`
`R2-081650
`
`-
`
`Cell Recelection for UL enhancement in Cell_FACH HUAWEI Disc
`The proposal is to release the E-DCH in the case that we have a high difference in the radio
`between the serving and the neighbouring cell.
`
`Use of HS-DPCCH
`
`R2-D8156?
`
`Efficient utilization of DL HS-resources in CELL_FACH Qualcornm Europe Disc
`NSN considers that there should be some more anaiysis on the reliability e.g. when the HS-
`SCCH orders are lost.
`
`NSN considers that the analysis should be not only done based on the full buffer
`CELL_FACH only UEs.
`NSN considers that in the typical case the UE would respond anyway somehow with the
`RLC Ack, and then the E-DCH would be established in CELL_FACH sometime later, and
`that’s what should be compared.
`lntercligital considers that the benefit is that ifthe E-DCH is not established by the HS-SCCH
`orders then the first transmissions will be less efficient.
`
`Qualomm considers that typically at some point in time the UE would transition to
`CELL_DCH which would take some 100 msecs.
`Due to the proposals several round trip times could be saved.
`Huawei wonders whether the collision and the blocking probability will not be impacted if
`now we start to use the E-DCH resources also for non UL Tx reasons.
`
`-
`
`-
`
`-
`
`-
`
`-
`
`-
`-
`
`- Qualcomm considers that this is an issue of dimensioning.
`-
`Ericsson considers that this is not really need so far for this work and that the usage of the
`HS-DPCCH in CELL_FACH is not that easy.
`- Qualcomm considers that the main purpose is to use the HS-DPCCH.
`
`Page 51 of 134
`
`ZTE/HTC
`
`Exhibit 1017-0257
`
`ZTE/HTC
`Exhibit 1017-0257
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`-
`
`Noted.
`
`CR5
`
`R2-081771
`
`Introduction of Enhanced Uplink in CELL_FACH Nokia Corporation, Nokia Siemens Networks
`CR 25.319
`
`-
`
`-
`-
`-
`
`-
`-
`-
`
`-
`-
`
`-
`
`-
`
`—
`
`-
`
`-
`
`-
`-
`
`-
`
`-
`-
`
`-
`-
`
`lnterdigital wonders whether the CRC is only attached in the case that it is segmented for
`CCCH
`
`NSN confirms that this is only done in the case that segmentation is performed.
`lnterdigital wonders what is an E-DCH buffer.
`NSN clarifies that this should be the HARQ buffer.
`
`lnterdigital wonders whether the TSN should be reset as well.
`NSN considers that everything is reset.
`Ericsson wonders whether there is a definition for HARQ buffer, it should better say flush
`the HARQ ???.
`
`lnterdigital proposes to state reset the MAC-is.
`CR is not agreed
`
`Introduction of Uplink Enhanced CELL_FACH in 25.301 Nokia Corporation, Nokia Siemens
`Networks CR 25.301
`
`It seems kind of odd to have the Enhanced Dedicated Channel (E-DCH) (FDD only) as a
`common channel
`
`CR is not agreed
`
`Enhanced Uplink for CELL_FACH in 25.321
`Disc
`
`Nokia Corporation, Nokia Siemens Networks
`
`Especially section 11.2 needs further checking by detegates.
`
`Introduction of Enhanced Uplink in CELL_FACH in 25.302 Nokia Corporation, Nokia Siemens
`Networks CR 25.302
`
`Noted, i.e. CR is not agreed.
`
`Short impact analysis on 25,331 Nokia Corporation, Nokia Siemens Networks Disc
`Noted.
`
`RRC signalling for Enhanced CELL_FACH Philips, Quaicomm Europe Disc
`NSN proposes that the E-DCH configurations should only be added to SlB5, SlB5bis.
`lnterdigital highlights that reference TFC and power offsets and minimum TFC sets are
`missing
`Ericsson considers that the semantics should be shortened and would be better included in
`
`the procedural text.
`NSN wonders whether the relative grant channel could be removed.
`It should be discussed whether we have to be able to configure both 2 and 10 msec TTI.
`NSN considers that this should be only either or. To be discussed in the next meeting.
`Samsung wonders whether all information has to be configured per channel.
`ALU considers that we should re-use more carefully the already existing names of the
`tabular |Es.
`
`R2-081773
`
`R2-081774
`
`R2-081775
`
`R2-081776
`
`R2-081769
`
`% R
`
`2-081568
`
`R2-081640
`
`Uplink Power Headroom definition for E-DCH in CELL_FACH Qualcomm Europe Disc
`- Motorola wonders whether the intention is to have a new definition in 25.215, orjust a
`change of the performance requirement in RAN4.
`- Qualcomm wants to change only the performance requirements, and possibly allow the
`measurement to be based on the last transmitted preamble.
`NSN considers that there is some need for checking these definitions
`lnterdigital agrees, and in addition there may be a need to define whether a TFC s in
`supported state or not.
`It is up to interested companies to raise the issue in RAN-4.
`Common E-DCH resource usage report Qualcomm Europe Disc
`Noted.
`
`-
`
`-
`
`-
`-
`
`Page 52 of 134
`
`ZTE/HTC
`
`Exhibit 1017-0258
`
`ZTE/HTC
`Exhibit 1017-0258
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`6.4.4
`
`Enhanced UE DRX
`
`(RAN2 W], RAF-limp-DRX. 50%. June 08)
`
`R2-081860
`
`Considerations on Enabling DRX in CELL_FACH Qualcomm Europe Disc
`Nokia considers that we should keep the possibility open.
`-
`- Qualcomm considers that the case is rather a typical case de to the behaviour of TCP
`-
`Ericsson considers that there are error cases that have to be handoed, eg. when the UE
`misses the downtink transmission.
`
`- Qualcomm agree that some error scenarios have to be handled.
`-
`lnterdigital considers that this is linked to HS-SCCH orders. In that case this may help the
`error case as well.
`
`R2—081563 Details of the CELL_FACH DRX scheme Nokia Corporation, Nokia Siemens Networl<sDisc
`- AdHoc chair asks the question on what is the usage of the linkage between E-RNTI and H-
`RNTI.
`
`-
`
`-
`
`-
`
`Nokia explains that if we indicate in the DL transmission that the E-RNTI is the same as the
`H—RNT| then the NodeB could deduce that this is a Rel-8 capable UE supporting the DRX
`operation
`Further question whether there is already a conctuston that a UE supporting DRX operation
`also has to support the E-DCH in CELL_FACH state.
`At this time there is no decision on that.
`
`- We need to decide whether the UE DRX is linked to the support of E-DCH in CELL_FACH
`state or whether it is an independent feature
`- Qualcomm wonders whether having the parameters cell specific would allow to have this
`data sent on BCCH
`
`-
`
`Nokia would prefer to provide this data over CCCH I DCCH because the SRNC is always
`aware of the DRX configuration that the UE has.
`- Qualcomm wonders whether there has been some analysis done to compare the usage of
`resources.
`
`-
`
`RAN3 is impacted due to:
`Rx burst duration, cycle length, inactivity timer are cell specific (Cell setup)
`UE support of UE-DRX + UE support of E-DCH (possibly linked)
`E-RNTI if the E-RNTI can not be mandated to be the same as the H-RNTI. to be checked
`
`-
`
`
`
`It is agreed that:
`the UE shall move to continuous reception when it receives the AICHIE-AICH
`Value ranges are Rx burst 10, 20, 30 and 40 ms and cycle values 60, 80, 100, 120, 140 and
`160 ms. The inactivity timer could be multiple of the cycle length or some absolute value like
`
`
`100, 200, 300, 400, 500, 600, 700 or 800 ms.
`
`
`the Rx burst duration, cycle length, inactivity timer are cell specific
`
`SFN = H-RNTI mod DRX_cycle + n " DRX_cyc|e
`
`
`
`R2-081562
`
`-
`
`Introduction of CELL_FACH DRX Nokia Corporation, Nokia Siemens Networks CR 25.308
`Ericsson wonders whether for the case of a UE initiated traffic that triggers a response from
`the network (e.g. TCP ack) the timer has to be set long enough such that the UE should still
`be in the active reception. Else the TCP ack would be delayed until the next Rx burst.
`Nokia confirms, and this should be done by having a good timer setting.
`Qualoomm agrees, and assumes that the typical round trip time should be around 100
`msec, and thus the typical timer should be a multiple of the round trip time.
`- Qualcomm considers that the value range of 800 msec should be enough for most of the
`RTTs in internet today, but only for the case that the Rx period is extended by the reception
`of DL data.
`
`-
`-
`
`-
`| -
`
`Ericsson wonders whether this would be suitable as well for some DL UDP streaming.
`The OR (REL-8) is technically endorsed.
`
`|
`
`6.4.5
`
`Enhanced CELL_FACH state in 1.28 Mcps TDD
`
`(RAN2 W], RANimp-En]1Statel.2STDD, 40%, Sep. 08)
`
`Page 53 of 134
`
`ZTE/HTC
`
`Exhibit 1017-0259
`
`ZTE/HTC
`Exhibit 1017-0259
`
`

`
`- Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2003
`
`Phvsical [aver feedback
`
`R2-081613 On Physical Layer Feedback for Enhanced DLZTE Disc
`-
`noted
`
`R2-081756 Discussion on Synchronization and HARQ Mechanism in Enhanced CELL_FACH State for
`LCR TDD CATT Disc
`
`- AdHoc chair asks whether the re-synchronization is always done or only in the case that
`new data arrives
`
`-
`-
`
`-
`
`-
`
`-
`
`-
`-
`
`-
`
`-
`-
`
`-
`
`-
`
`CATT clarifies that the synchronization is only done when new data arrives.
`ZTE believes that both solutions can solve the problem, in the ZTE solution it is up to the
`NodeB to decide, and CATT it is a UE independent resolution. GATT has some concern on
`the timing relations. i.e. the HS-SICH comes too short after the HS-SCCH. thus there is no
`time for doing the re-synchronization
`CATT considers that he HS-SCCH is sent during 4 subfrarnes, Le. 20 msec, and thus the
`re-synchronization can be done in good conditions, but in bad conditions it may