Anced Cell_FACH for DL and UL _ 121209 Enhanced UE DRX in Cell_FACH - FSM Version 01 03 - Preliminary

8/19/2019 Anced Cell_FACH for DL and UL _ 121209 Enhanced UE DRX in Cell_FACH - FSM Version 01 03 - Preliminary

http://slidepdf.com/reader/full/anced-cellfach-for-dl-and-ul-121209-enhanced-ue-drx-in-cellfach-fsm-version 1/126

COPYRIGHT © 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

ENHANCED CELL_FACH (LR14.2.W)Feature Introduction Strategy and Monitoring

Artur VARGAS & Pedro MARTINS – MGR / TEPS / NEA / Wireless Features & Perfo

Inputs from HugoC. and ThangP.

25th

July 2014, Version 01.03 – Preliminary



2


PUBLICATION HISTORY

Author: Artur Vargas & Pedro Martins

Publication History:

• 02/May/2014

- Version 01.01 / EN, DraftCreation eDRX feature

•23/July/2014

- Version 01.02 / EN, Draft

Creation eFACH DL and UL

•25/July/2014

- Version 01.03 / EN, Preliminary

eFACH DL and UL ; Correction of parameters values; monitoring added and feature interaction; Ran model

Livelink Location:

https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?func=ll&objId=67647320&objAction=bro

https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?func=ll&objId=67647320&objAction=browse&viewType=1

https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?func=ll&objId=67647320&objAction=browse&viewType=1



3


ENHANCED CELL_FACH AND ASSOCIATED FEATURES

The enhanced Cell_FACH solution comprises several features:

• PM168710 – Enhanced Cell_FACH for Downlink (LR13.3.W)

- New eFACH R7 AO Thresholds requested for PM118687 (former PM170419)

- New SRB Specific Default CQI requested for PM118687 (former PM170420)

- Mobility Mixity for Enhanced Cell_FACH for Downlink

• PM89563 – Enhanced L2 for Uplink (LR13.3.W)

• PM108103 – Enhanced Cell_FACH for Downlink and Uplink (LR14.2.W)

• PM121209 – Enhanced UE DRX in Cell_FACH(LR14.2.W)

This FSM version includes the last 2 features in the list above and complements the LR13.3.W solution, thus covering t

uplink solution.

10810eFAC



4


CONTENTS

1 | PM108103 – ENHANCED CELL_FACH FOR DOWLINK AND UPLINK

2 | PM121209 – ENHANCED UE DRX IN CELL_FACH



5


ENHANCED CELL_FACH

1 | PM108103 – ENHANCED CELL_FACH FOR DOWNLINK AND UPLIN



6


PM108103 – ENHANCED CELL_FACH IN DOWNLINK AND UPLINK

1. 1 | INTRODUCT ION



7


108103 - FEATURE OVERVIEW

In 3GPP Rel.8 the Ue should support the Enhanced CellFACH in UL. This means

additionally to the DL feature, to have an equivalent behaviour as E-DCH in the

UL for the UE using CellFach.

This constitutes the final step for the complete solution of Enhanced Cell Fach

that allows equivalent performances in CellFach as Cell DCH. With low latency

and low Rtt

The Enhanced Uplink for CELL_FACH in FDD feature supports CCCH, DCCH and

DTCH logical channels that can be mapped on E-DCH in CELL-FACH state.

The ALU solution will allow flexibility for customers to tune differently the AO

mode to “ReleaseOnly” for non eFACH capable devices while allowing

“degraded2AlwaysOnOnly” configuration for eFACH capable devices (R8 devices

supporting eFACH).

Note: Although this feature is reportedly for UL and DL, the description below

will focus mainly on UL as the DL was already described on FSM of PM168710

•This feature is under license in LR14.W, provided by RNC activation Flag.

CQI, ACK/NACK reporting!

CCCH DCCH DTCH BCCH

HS-DSCH

HS-PDSCH HS-SCCH

eFACH



8


108103 - FEATURE BENEFITS

The benefits resulting from having such a type of resources (HSDSCH and EDCH) being allocated on CellFACH state are

knowing the previous difficulties that CellFach experience, specially due to associated Features that increased the Ce

URAPCH or FastDormancy.

Legacy CELL_FACH uses low-throughput RACH/FACH, resources were wasted due to unneeded transiting to CELL_DCH

with small but bursty packet pattern, bringing ; Excessive transition delay (~500ms) ; Unnecessary upsize to CellDCH;

life

Therefore, the benefits for Network are:

•Reduced signaling load due to much less frequent state transition between CELL_FACH and CELL_DCH

•A efficient utilization of radio resource and bandwidth

•Higher uplink capacity: higher bit rate and larger transport block sizes on common E-DCH

•Node B Resource Utilization (HSPA)

Benefits for End users are:

•Better handset battery life

•UL saving: UE does not need to radiate when it has nothing to transmit

•DL saving via additional eDRX feature

•Reduced latency for PS services , the state transition procedure becomes faster thanks to common HSPA for sig

•UE can use eFACH as a normal state and stay in eFACH state much longer to fast send/receive the bursts

•Message size limitations imposed by legacy RACH are now overcome with eRACH



9


108103 - FEATURE REQUIREMENTS

R1&2: Provide support of E-DCH cell resource for users in CELL_FACH(Rel 8) and Provide support of HS-DSCH cell

CELL_FACH (Rel 7)

This Rel8 enhanced UL for CELL_FACH feature is supported. UL ACK and CQI could be sent HS-DPCCH if commCELL_FACH state for DCCH/DTCH transmission after collision is resolved. The requirement over DL eFACH was alrePM168710 -Fully compliant (RNC, iBTS).

R3: Provide specific tuning of Always On upsize for UE supporting enhanced CELL FACH in DL and UL.AO Upsize/Downsize shall be based on Traffic volume threshold - Fully compliant (RNC).

R4: Requirements are applicable to iBTS with eCEM. No feature support is requested on xCEM and iCEM or ONEBTS UC(iBTS).

R5: Identification of baseband capacity impact with enhanced Cell_FACH.

The CE should support 128 eDCH calls, 1 Call on Common EDCH consumes same CE resources as 1 call in CellDCH_impact is forecasted with eFACH in UL node B capacity, assuming same traffic profile- Fully compliant (RNC, iBTS).

R6 & 7: Support R8 eFACH specific always on mode and Support of Direct establishment over efach

Fully compliant (RNC).

R8: RRC state transition from CELL_FACH to CELL_DCH in 400ms

The Current transition time is less than 300ms while legacy FACH holds a record of Around 500ms for the transitionscompliant (RNC).

R9; 10 & 11: Configuration , monitoring and alarms dedicated to UL Efach.

Fully compliant (RNC).

R_Customer: PM 89563 Flexible PDU size in UL. Already available since LR13.3



10


108103 - MAIN SCENARIOS INTERACTIONS

Scenario 1: Light browsing

A user is browsing light-weighted web pages, the user’s HTTP

request/responses can be timely transmitted on common E-

DCH and HS-DSCH in e-CELL_FACH state. The user’s smartphone

battery life is also prolonged thereafter.

Scenario 2: The high traffic

A user is requesting a big web page or downloading/uploading

an email with large attachment, the traffic volume monitoring

will trigger an upsize to CELL_DCH to serve the request. A

smooth transition free of L2 reconfiguration is available since

MAC-i/is (and flexible RLC) are common to both states.

Scenario 3: The Ps + Cs Voice service

A CS call is triggered while being in eCell_FACH (PS session

already established). The call is moved to Cell_DCH. If the CS

call is released first, it will be possible for the UE to transition

back to eCell_FACH if the Always On is set to

“degraded2AlwaysOnOnly”, even if it is set to “ReleaseOnly”

for non R8 eFACH capable devices.

Requirement s ass

R1; R2; R3; R4; R

R1; R2; R3; R4; R5

R1; R2; R3; R4; R5; R

This slide aims at giving a flavor of efach UL under commonly used scenarios, below we also detail some call flows for th



11



1.2 | FEATURE DESCRIPT ION



12


108103 – PRINCIPLES AND ARCHITECTURE – EFACH PROTOCOL MODEL

• The Enhanced CellFACH (eFACH) for Downlink and UpLink advantages pointed above were addressedonly. However the usage of only DL eFACH is a non optimal situation which is not able to deliver all beand throughput.

•This limitation was only solved with 3gppR8 where DL and UL eFACH described here after, this will aof 200 to 400kbps being served over eFACH common resources.

•On the basis of UL eFACH exists a new model of common E-DCH transport channel

Mac-d /Mac-c

DTCH/DCCH CCCH

Mac-is/Mac-i

PHY

Mac-i

PHY

UE Node B

EDCH FP

TNL

Uu Iub

Mac-d /Mac-c

EDCH FP

TNL

UE

Mac-is

DTCH/DCCH CCCH



13


108103 – PRINCIPLES AND ARCHITECTURE – COMMON EDCH BASICS

• The UL eFACH specifies a new common EDCH channel unique for one cell, several UE’s can share it using time multiplexing

•The common eDCH is only supported over 10ms TTI

•This channel is configured by RNC but is under the control of NodeB in terms of allocation of resources. ( NodeB reserves a list of E-RNT

from this resource pool). However RNC is informed about which resources to use on Dedicated

•There is no SHO or SofterHO as the ue is uniquely allocated to one eFACH channel, as it happens with CellFACH legacy state

•The common E-DCH resources configurations are broadcast in SIB5/5bis and shared by UEs in CELL_FACH state and idle mode (3GPP25.33

•When an eFACH UL cell loses the (common) E-DCH capability, it’d be reconfigured to become a legacy R99 cell (and not eFACH DL cell).

•ALU UTRAN doesn’t support on RNC mixity configuration of eFACH DL only and eFACH DL and UL RNC. If there is on same RNC UE doing b

DL and UL it is solely because of UE capability.

•PS MUX or CS+PS are not supported over eFACH

• Mobility between cells with different eFACH UL capability is supported with some restrictions.

•During common HS-DSCH transmission, if the UE has common E-DCH, then the UE can report CQI/ACK/NACK to the NodeB

•eFACH UL over Iur is not supported

•A Ue in Idle mode can use eFACH in UL for transmitting RRC signaling messages. the UE requests to random access the common E-D

preamble signature (and/or access slot) reserved for E-DCH access in CELL_FACH state and Idle mode. However in PCH state the ue needs

state first to get the proper RNTI because on this state the ue variable READY_FOR_COMMON_EDCH is always set to false



14


108103 – FEATURE DESCRIPTION– UE CAPABILITY

• The usage of UL eFACH presumes among several aspects that the UE can support this new feature.

•This information can be retrieved from several messages exchanged with network, namely; RRCCONNIdle mode, CELLUPDATE in CELL_FACH/XX_PCH or URAUPDATE in URA_PCH state

•All these messages should include the “Support of common E-DCH” IE set to TRUE , this IE is option

indicates that the UE does not support the EDCH enhanced random access in CELL_FACH state and Idle If the UE supports common E-DCH then the UE shall also support:

•MAC-i/is

•FDD E-DCH physical layer category 2, 4, 6 or 7

•Enhanced F-DPCH

•HS-PDSCH in CELL_FACH

•UE can also indicate its detailed capabilities in RRC : CONNECTION SETUP COMPLETE and other messagaccess capability” IE --> “Physical channel capability” IE --> “E-DCH physical layer category extension”

cannot support UE category 7, “E-DCH physical layer category” IE shall be used instead

108103 FEATURE DESCRIPTION



15


108103 – FEATURE DESCRIPTION– ENHANCED RACH PROCEDURE 1/3

• The RNC and Node B shall split the PRACH preambles signatures among Enhanced PRACH and legacy PRACH.

•This information is made available to the UE through the SIB5, and the ratio of eRACH and RACH should be aligne

different RACH traffic type market share value.

•On this ratio it is not enough to consider the amount of UE’s or users, but also the amount of rach procedures offered

•From the total preamble signatures available we should thus make a fair design of these resources for eRACH and RACthe figures above.

•Regarding the PRACH resources Sub Channel, 3gpp also considers the sharing between legacy RACH and e-RACH, this

5 where dedicated IE exist to “Available Sub Channel Number” IE and “Preamble scrambling code number” IE.

•However the NBAP PSCR does not include the Available Sub Channel Number, which would made difficult to set a si

on Node B and UE from RNC stand point. ALU decision was the NodeB/RNC to use all 12 sub-channels for eRACH as it is

•For the ASC (Access Service class) RNC may optionally support the resource partition among different Access Serv

order to provide different priorities of the usage of the e-RACH.

•Note: The preamble signatures normally provisioned is 1 for GM market. A CR602574 has been pro

RACH.preambleSignature to allow signature partition between eFACH users and legacy R99 FACH users. Due to board

will only support up to 8 preamble signatures dedicated for eRACH from a total pool of 16 (8 signatures for legacy

•A new power offset parameter powerOffsetPpe , specified in dB, between the power of the last transmitted pream

DPCCH transmission power was defined for eFACH, NodeB shall as well broadcast such new power offset in SIB5 --> “P

IE. The Majority of remaining preamble related parameters are reused from legacy RACH procedure



16



• If all the conditions are met, as referred on previous slides, (UE picks one slot out of 15, RACH subchannels, Acce

preamble signature belongs to Common EDCH and sends the preamble. (for more details on preamble please see back

•In DL depending if EAI is configured the node B can reply with EDCH resource allocation directly.

•The usage of Common Edch resources right from idle state or in FACH Sate is made possible thru the Extended Acqu

over the random access procedure which is detailed in the 3gppR8. The usage of EAI is made available as soon as

other parameters to enable it).

•The UE is informed about the possibility of having EAI’s on the SIB5, this broadcast message is built on RNC after c

EDCH is enabled and that cell can support it (Resources).

•As referred before the Subchannels are not informed to NodeB on PSCR so all the subchannels are available for eR

this means that the only way to distinguish the eRACH from RACH is from the preamble signature.

•The main process relies as well on the AICH as a response of ACK/NACK or no response. However the AICH can “allo

stage the EDCH resources by combining the info of AI with the EAI.

1. For the NodeB to rejects the UE random Access with a NACK it can either:

a) For legacy RACH it is enough to send AI negative (-1) on AICH for the selected preamble on the

(corresponding to the access UL slot of preamble)

b) For eRACH preambles with no EAI (if there is no resources, not common on ALU solution as EAI is always ena

send a negative AI(-1)

c) For eRACH preambles with EAI configured, the Node B should send a negative AI (-1) and EAI=+1 with Signa

to NACK (see table below)



17



1. For the NodeB to accept the UE random Access with a ACK it can either:

a) For legacy RACH it is enough to send AI positive(+1) on AICH for the selected preambleon the corresponding DL slot (corresponding to the access UL slot of preamble)

b) For eRACH preambles with no EAI the NodeB shall send a positive AI (+1) on AICH - the

same handling as the case above. For the e-RACH (without EAI) procedure, UE L1 has to

deduce the default E-DCH resource index to use (see below and TS25.211). Note: assoon as the number of signatures configured for e-RACH < the number of common E-

DCH resource (i.e. very likely to happen in reality), the default E-DCH allocation

without EAI will cause the problem that part of common E-DCH resources will never beallocated as default and thus collision increases. That is why EAI must be supported in

NodeB due to current 3GPP TS25.211 design

c) If it is an e-RACH request and EAI configured, the NodeB shall either

i. send a positive AI (+1) on AICH ( it represents an ACK and the associated default

common E-DCH resource configuration is allocated to the UE) (default commonEDCH is 10ms tti)

ii. send a negative AI (-1) plus a combination of EAI signature and modulation

symbol corresponding to the meaning of “Not NACK” and a specific (i.e. non-

default) allocation of common E-DCH resource index presented on this table

2. Each combination of the table represents a non default common EDCH resource allocated



18


108103 – FEATURE DESCRIPTION– COLLISION RESOLUTION 1/2

•Every time a user is not exchanging data with the network the EDCH resources are reledefined amount of time) however for users remaining in lethargic state in eFACH with SRcontext is kept like the RNTI identifiers.

•On the other hand for UE’s released into idle mode, there is no E-RNTI or any other RNTI id

•This means that for any UE accessing the network on CCCH it does not possess any RNTI not Collision resolution possible, while for a UE being kept in eFACH it can indeed regain reuniquely identified with the help of E-RNTI.

•This process takes place right after a EDCH Preamble being ack by the network so the UE kuse either the Default EDCH resources or any other particular index of EDCH resource as inEAI, however there are different actions to take depending if it is in CCCH or on DTCH/DCCH

•DTCH/DCCH the UE will include the E-RNTI in the MAC-i header during collision resoalso be done through the entire communication by the node B over the Frame protocoRNC can use this information for MAC Flow to be aligned to the correct MAC-is.

•CCCH there is not collision resolution, the messages that will be sent over tRRCConRequest, CellUdpate, URAUpdate.

The Benefits of using common EDCH on CCCH are:

1. Early detection of UL transmission Failure due to the usage of E-HICH and ACK/NACK E-Ddone over a few ms while in pure RACH it can take 4s.

2. Easy of CCCH message size constraints thanks to higher throughput and enhanced L2 for




19



•For the CCCH there is no collision resolution stage, The UE will continuously transmit data until deliver or the Max Allowed EDCH resources for CCCH is exhausted.

•The UE will end the CCCH transmission and release the common E-DCH resource when either (re-)transmit, or the max common-EDCH resource for CCCH (#TTI) is expired, or the radio lichannel establishment failure occurs.

•In the PSCR the RNC also informs about the the maximum E-DCH resource allocated to CCCH (iwhich shall be represented by maxCcchResourceAllocation. (more details below on Synchronizatio

•The possible impact of Collision on CCCH will be the last two options mentioned above.

•The DTCH/DCCH collision resolution stage is terminated by the NodeB explicitly by replying witthe E-AGCH CRCed with the E-RNTI, while this information is not received the UE should keepRNTI on MAC-i.

•There is a timer for the UE to wait for the Collision resolution to finish, this timer is broad

“Maximum period for collision resolution phase” IE in TTI maxPeriodForCollisionResolution, if iwill very easily not receive info from NodeB and consider itself in collision and give-up. If too lonUE can continuously send data even in collision before releasing EDCH resource.

•Even after collision resolution, It is possible to have more than one UE to occupy a single resource. However, because the collision probability still exists between those in “Collision Resbetween those in “Collision Resolution” and those in “Collision Resolved” phase, due to the fact“Collision Resolved” phase is allowed to transmit at any time as long as its “E-DCH transmission coff” timer has not expired edchTxContinuationBackoff (more details on subsequent sections)




20


108103 – FEATURE DESCRIPTION– SYNCHRONIZATION 1/2

•The synchronization procedure AA is the post-verification period of Common EDCH access and it is alw

•As soon as the UE receives a positive AICH, it can transmit in the uplink right away instead of waitingsynchronization (see image below).

•During the first 40ms of the first phase of downlink synchronization procedure, if the F-DPCH quality stop transmit in the uplink.

•If the quality is good, then the downlink synchronization is confirmed. In the first phase of Downlinonly in-synch can be reported, while in the second phase, either in-synch or out of-synch can be report

•The UE shall start transmission onuplink at the time defined for theEnhanced Uplink in CELL_FACH stateand IDLE mode

•It shall use a post-verification periodfor confirming the establishment of thedownlink physical channel as follows:

• During the first 40 ms( first phase ofthe downlink synchronization)

•If the downlink F-DPCH quality isworse than a threshold Qin (TPCcommand error ratio level of 20%), theUE shall shut its transmitter off andconsider post-verification failed.




21


108103 – FEATURE DESCRIPTION – SYNCHRONIZATION 2/2

•If the first phase fails the ue will report it to higher layers which means

that it did not achieve to reach in-Sync state and failed the transmission of

data.

•The final outcome may be a RL failure (see above on collision details)

•The second phase starts only 160ms after. This time is needed as itrepresents the interval needed to trigger Quality evaluation over FDPCH

•On the second phase To declare Out-of-Sync State there are several

conditions described in 25.214. These conditions rely on F-DPCH quality

being worse than a threshold Qout (TPC command error ratio level of 30%)

during 160ms or during last 240 slots depending if UE DRX is disabled or

enabled respectively

•Similarly to what happens on the Synch procedures for CellDCH the In-

sync state can be achieved if the conditions are better than Qin (seedefinition above)

•After the collision resolution stage the NodeB implements the in-synch and

out-of-synch mechanism similar to what are currently handled in CELL_DCH

state.

•The parameters nInSyncIndECellFach, nOutSyncIndECellFach,and

tRlFailureECellFachare introduced as counter-part to existing parameters

nInSyncInd, nOutSyncInd, and tRlFailure, respectively

108103 FEATURE DESCRIPTION ACK CQI



22


108103 – FEATURE DESCRIPTION – ACK-CQI

•The Main Advantage of Rel 8 over R7 is the usage of CQI feedback in UL over HS-DPCCH

•This is known as the “Common E-DCH HS-DPCCH” capability for a common-E-DCH-capable cell and it is activated by FDDCell:isCommonE

•This flag will also allow the alignment NodeB with RNC via NBAP RSI/AUDIT RESPONSE. And UE update through Sib5 that the feature is ac

•Unless indicated by higher layers, the UE shall not transmit any HARQ -ACK or CQI information and DTX shall be used on all the HS-DPCCH

•The UE should not transmit E-DCH during first N TTIs of UL DPCCH transmission, where N ( “Additional E-DCH transmission back o

configurable by OAM additionalEdchTxBackoff . This value shall be 5 for 10ms and 15 for 2ms and it is broadcasted on SIB5

•The initial UL DPCCH power level is derived from the power level of the last PRACH preamble, similar as the power setting for the R99 P

•For each common E-DCH transmission using the EDCH eRACH procedure, the NodeB shall return an E-HICH as response for each tran

DPCCH sub-frame by UE.

108103 – FEATURE DESCRIPTION– COMMON E-DCH RESOURCE RELEASE 1/2



23


108103 FEATURE DESCRIPTION COMMON E DCH RESOURCE RELEASE 1/2

•There are two main procedures to release EDCH resources following a contention resolution

•The Explicit release sent by NodeB, can include a scenario like a UE reporting empty buffer for whi

take the decision to release the resources towards the UE

• The implicit release procedure, depend mainly on the continuation back off that shall not be set timplicit release) to avoid EDCH resource to be waste. This timer is present in Sib5 identified transmission continuation back-off edchTxContinuationBackoff . If the network is not loaded we cavalue for this timer to avoid eRACH procedures (~80tti’s), however if the network is loaded we shouldto a low amount of tti (8 to 4).

Explicit Implicit

CCCH DCCH/DTCH CCCH DCCH/DTCH

•No MAC-i PDU is pending for

transmission;

•The maxE-DCH resource

allocation for CCCH is reached.

•A L1 synch failure

• "E-DCH transmission

continuation back off" is not

to "infinity"

•period for collision resoluti

reached

•a L1 synch failure

• NodeB sends a

special Absolute

Grant on E-AGCH

with inactivity

(error case only)

•N/A

Suppor

ALU RN

Example : E in e-CELL_FACH --> new MAC-i PDU arrives e-RACHcommon E-DCH resource allocatedMACand Collision Resolution phase performed“collision-free” E-DCH access explicitly grantedMAC-i PDU tran

in Collision Resolved phasethe common E-DCH resource either implicitly or explicitly released

108103 – FEATURE DESCRIPTION– COMMON E-DCH RESOURCE RELEASE 2/2



24


108103 FEATURE DESCRIPTION COMMON E DCH RESOURCE RELEASE 2/2

•The particular case of L1 fail on Synch can be a particular case of release as it can be in fact triggeNodeB

• For implicit release:

•UE implicitly releases the common E-DCH resource (/ stops UL DPCH transmission)

•NodeB detects UL out-of-sync

•This is a special case which could be considered as explicit release. This release which is curreimplementation is somewhat similar to the implicit release in the sense that the NodeB does ncommands UE to release common E-DCH resource (e.g. by sending E-AGCH (“INACTIVE”)), it jtransmission.

•160ms later, the UE detects DL out-of-sync and it switches its transmitter off

• NodeB detects UL out-of-sync (Note: before detecting UL out-of-sync event, NodeB should NOgiven common E-DCH to another UE)

• The L1 will consider the common E-DCH resource as free

108103 – FEATURE DESCRIPTION– COMMON EDCH RESOURCES



25


108103 – FEATURE DESCRIPTION– COMMON EDCH RESOURCES

• The efach for Dl and UL is only supported by eCEM (iBTS)

• In practice iBTS should not have more than 32 common edch resources per cell on a 3 cell NB, 24 on a 4 ce

• Although eFACH is only supported by eCEM, it can interact with other boards like xCEM and iCEM

eCEM One Chip

4

Preamble Detector

31

OneChip Resource64

demodulator8 2..3

e

Dedi1

1

1

3

numberOfCommon

EdchResources

Hardware Logical

1

108103 – FEATURE DESCRIPTION– COMMON EDCH RESOURCE CONFIGURATION 1/2



26


108103 FEATURE DESCRIPTION COMMON EDCH RESOURCE CONFIGURATION 1/2

•The RNC/NodeB can theoretically configure up to a maximum number of 32 common E-DCH resouractual and maximum number of common E-DCH resources to be configured per cell shall be representNumberOfCommonEdchResources.

•However there are physical limitations imposed by eCEM configuration and the number of cells assothe resources maximized per eCEM by maxNumberOfCommonEdchResourcesPerBoard. If this limit is

NodeB rejects the PHYSICAL SHARED CHANNEL RECONFIGURAT ION REQUEST (PSCR), which causes talarm. More details below

•In terms of other UL resources or related power and codes there are some information detailed below

•1) An UL DPCCH requiring UL DPCH scrambling code allocation, but same scrambling code is used to caE-DPCH, and HS-DPCCH.

•2) A DL F-DPCH allows up to 10 users per code. To serve up to 32 users would require 4xSF256 codes

•3) A pair of DL E-HICH/E-RGCH share the same channelization code, up to 20 users can share the sameto 32 users would require 2xSF128 codes.

•Depending on the number of common E-DCH resources (configured via the numberOfCommonEdchResources), the RNC computes and allocates the channelization codes foresources at either the top of the code tree directly below the common channels, or at the bottom of t

•If the required codes are not available at both locations, the RNC will fail the eFACH setup and raises

108103 – FEATURE DESCRIPTION– COMMON EDCH RESOURCE CONFIGURATION 2/2



27


108103 FEATURE DESCRIPTION COMMON EDCH RESOURCE CONFIGURATION 2/2

•Regarding the power settings for eFACH UL, there is no direct impact however some extra channeadditional Power in DL that should be accounted for

•The extra Power used for FDPCH factor becomes irrelevant as it’s absorbed in the measuremCarrier Power Of All Codes.

•The power reserved for common E-DCH DL channels is absorbed in the legacy EdchCellClass/eagchErgchEhichTotalPower.

•Examples of common EDCH resource Allocation:

•Initial deployment, if 4 common E-DCH resources per cell are configured in OAM, RNC reserve 1x256 for E-RGCH/E-HICH, 1x256 for F-DPCH.

•Full deployment with high smartphone penetration rate, if 32 common E-DCH resources per cell, RNC

reserve following codes for eFACH operation: 1x256 for E-AGCH, 2x128 for E-RGCH/E-HICH, and 4x256 f

108103 – FEATURE DESCRIPTION– ERROR HANDLING ON RESOURCE AVAILABILITY



28


108103 FEATURE DESCRIPTION ERROR HANDLING ON RESOURCE AVAILABILITY

•Regarding the resources availability the several functionalities are cumulative, which means that if the lowe

ones on top can not continue to be sustained any longer either.

•The HSDPA and E-DCH Capability are indicative of the overall HSPA resources status in both CELL_DCH anHowever practically, when HS-DSCH Resource Operational State is set to Disabled, the NodeB would indicate,

DCH would also be lost. But the reverse is not true:

•when E-DCH Resource Operational State is set to Disabled, it’d mean Common E-DCH is lost, but the eFACHremain. However, the ALU RNC will fall back to R99 cell as opposed to reconfigure the eFACH UL cell to eFACH

•When the PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST ( PSCR) procedure fails either due to a

timed out, no response at all, or not even a PSCR can be sent out due to lack of E-DCH channelization code fowould always fall back to R99 cell configuration.

•Similarly when the eFACH UL is activated, and the NodeB reports either the “Enhanced FACH Capability”

Capability” loss, the RNC use PSCR to remove both the common HS-DSCH and E-DCH resources, and ad

recovery. If the NodeB reports “Common E-DCH Capability” loss, the CELL_NOT_ENHANCED_CELL_FACH_FOR_UL_CAPABLE will also be raised.

•The possible reasons for a NodeB to reject the PSCR, include:

1. If the PSCR message includes the Common E-DCH System Information IE while HS-DSCH Common Systnot present

2. The resource for enhanced FACH is not configured for the cell

3. No enough free E-DCH available on the board to satisfy the number required

4. The number of the total common E-DCHs exceeds the maximum board limit.

108103 – FEATURE DESCRIPTION– SIB5 AND PSCR



29


108103 FEATURE DESCRIPTION SIB5 AND PSCR

•SIB 5 was affected by eFACH DL, but the impact is even greater on eFACH for DL and UL as the informincreased.

•The SIB5/SIB5Bis broadcast of Common EDCHA capabilities are important for the eFACH usage from several IE available in SIB5 in “Common E-DCH system info” IE.

•It can be highlighted; “E-DCH transmission continuation back off”, “Uplink DPCH code info”, “ACK/NADPCCH”, “E-DCH Transmission Time Interval on the E-DPDCH”, “E-DPCCH info”, “E-HICH info”, “E-AGCsignatures for eRACH, PRACH preamble control parameters among others.

•The common EDCH Resources are configured/setup or modified thru same message PHYSICAL RECONFIGURATION REQUEST .

•This message allows to configure all the detail settings on the usage of common resources like, E-DCHOffset, Common E-DCH HS-DPCCH, Common E-DCH CQI, E-AI Indicator, Common E-DCH AICH InformatioF-DPCH, Initial DL Transmission Power, Maximum DL Power, Minimum DL Power, among other IE incldue

to configure RF characteristics on Node B•This information is mainly configured at Cell Setup. The Node B should reply with PHYSICAL RECONFIGURATION RESPONSE where it can include as well some useful info to RNC specially to build tmentioned above (mainly amount of Common edch resources (E-RNTI) that are managed by Node Bvalue.

108103 – FEATURE DESCRIPTION– E-DCH SCHEDULER



30


C SC U

•After the collision resolved phase, the scheduling of users in eFACH UL state is similar to in CELL_DCunder radio overload or transport congestion where the SG is progressively reduced.

•More specifically:

• An initial TB size index (internal tunable parameter) is defined for eFACH, similar to the coCELL_DCH. This parameter acts as input to acquire the initial grant for DCCH/DTCH.

•The CCCH scheduling is not handled by the MAC-e scheduler as there is no E-RNTI so does no usUE would directly use the initial credit provided in the SIB5

• The maximum allowed transport block size is based on whether the UE is at cell edge ocorresponding TB size is configured by the RNC parameter maxTbSizeCellEdgeUsers, and maxrespectively.

• The UE is considered to be at cell edge if the CQI reported by the UcqiThresholdForCellEdgeECellFach. If the CQI is not available (e.g. during the collision resoluti

transmission, the UE is assumed to be in cell edge condition by default.

• The minimum Etfci index is configured via the RNC parameter EdchMinSetEtfci and is passedNBAP message. In case of Iub congestion, the NodeB would reduce the grant to this minimum value

•For the release handling and ambiguity related to the lost of radio synchronization this was already dabove

108103 – FEATURE DESCRIPTION– CALL ADMISSION CONTROL



31


• The legacy behaviour of call admission control on RNC relies on comparing the existing CellFACH userstrbEstThreshold which is used for CellFACH using TRB cases in state transitions. While maxNumberOfUseused for all other cases including cell reselection, RRE and RRCCONNECTIONREQUEST.

•With eFACH in UL and DL, the CAC is only done based on one single parameter,MaxNumberOfEnhancedCellFachUsersPerCell, which will be compared against the current amount of enCellFACH users for all the procedures including the cellReselection, State transition, CCCH and RRE

•We can thus sum up the CAC to be done on following aspects:

1. For eFACH in DL and UL there is only one threshold to be respected; number of current eFACH UL uMaxNumberOfEnhancedCellFachUsersPerCell

2. Total number of users in CELL_FACH <= 256 (maximum UL eFACH + legacy contexts) but values of le(incluing Enhanced DL only depends on the legacy thresholds.

3. On top of these thresholds for number of users we should as well consider the RNTI H-RNTI (256 shaCELL_DCH and CELL_FACH users) and common E-RNTI( theoretical 180 as returned by the NodeB)

108103 – FEATURE DESCRIPTION– E-RNTI MANAGEMENT 1/2



32


•As mentioned before the pool of E-RNTI is shared among eFACH and CellDCH

•The H-RNTI dynamic allocation is fully controlled by RNC, however for E-RNTI RNC can not indicaNodeB, so NodeB manages this pool and will reserve an E-RNTI list for eFACH Ues.

•At the cell setup stage, a set of E-RNTI (up to 256 maximum as per 3GPP) can be used by the NodeB. Fsend to RNC via Physical Shared Channel Reconfiguration response (PSCR) 180 codes reserved for the

The reason for this number is that; with 4 E-RGCH/E-HICH codes reserved for dedicated users,supporting 19 users, what remained for common E-DCH users would be 256-4*19=180.

•In ALU’s implementation, the assignment of dedicated H-RNTI/E-RNTI to CELL_FACH users is performeis sent at every common HS-DSCH frame to the NodeB, along with the payload data. The process howRNCPSCR RequestNodeB; NodeBPSCR Response (E-RNTI List)RNC

108103 – FEATURE DESCRIPTION– E-RNTI MANAGEMENT 2/2



33


•Lets consider the case of an upsize reconfiguration from eFACH to CellDCH to explain how the two RNTI are handled (more details on scenario call flow below)

•RNC RADIO LINK SETUP REQUEST => E-RNTI A (old E-RNTI used in e-CELL_FACH) NodeB (NRNTI to setup context mapping)

•NodeB RADIO LINK SETUP RESPONSE => "E-DCH FDD DL Control Channel" IE => E-RNTI B I

indicates the new E-RNTI to be used in CELL_DCH state)

•RNCRB Reconfiguration (new E-RNTI B)UE (RNC tells UE the new E-RNTI to use in CELL_DCH

•The PM168710 eFACH DL defined three different kinds of H-RNTI; Common H-RNTI, Dedicated Hspecific H-RNTI, these H-RNTI’s have the same role in PM108103 eFACH for DL and UL

•For the E-RNTI there is also a particular case that needs to be described which is the info to be filledFP in UL when there is still no E-RNTI defined (cases using CCCH)

•When the UE has common E-DCH resource and it wants to send a CCCH message, then it does not collision resolution without a valid E-RNTI. However, given that the E-RNTI IE is mandatory in the E- DCis expect that the NodeB fill it with value 0 when sending the CCCH message to RNC .

108103 – FEATURE DESCRIPTION– MEASUREMENT OCCASION AND EDRX



34


•For the users to remain in eFACH is thus very interesting for Smartphone type of application as useconnected (virtually no latency for state transitions) and no resources being wasted.

•Also for network operator side there would be less state transitions, so…

•NO!! There is a major drawback for this which is the battery consumption that ue would be subjecremaining continuously in eFACH state.

•The solution is thus to use another related feature; PM121209 – ENHANCED UE DRX IN CELL_Funfavorable to CellFACH state there are the measurement occasions during eDRX Measurementbattery efficiency increase considerably.

•Ideally the discontinuous period could start right after the release of Common Edch Resources, hoallow some hysteresis a Timer is considered T321

•For more detail please read the feature PM121209 - ENHANCED UE DRX IN CELL_FACH below.

Let’s increaseTimerT2!!??

108103 – FEATURE DESCRIPTION– UL INTERFERENCE FOR COMMON E-DCH IN SIB5 1/2



35


•Early tests revealed that some state transitions involving eFACH were taking longer than what was more).

•The root cause analysis showed that the main issue was the fact that SIB7 was being used for rinterference instead of the newly defined UL Interference for Common E-DCH by 3GPP in SIB5.

•There was several reasons for this, the fact that SIB 5 is already loaded with several new IE, the fact

is updated more quickly (NodeB) than SIB5 (RNC), and difficulty to refresh the SIB5 Interference IE updated value

•However on the other hand the usage of UL Interference for Common E-DCH can bring benefits

1. For E-RACH capable UE and when UL Interference for Common E-DCH is explicitly sent via SImake use of this IE and no longer need to periodically read SIB7 which could save battery. Alsowould be faster.

2. Different from RACH, the E-DCH is power controlled so when the data part is transmitted, on

power would be used without causing interference.• The idea is to have a value that can be set on the following equation and that at same time does nas mentioned above, knowing that even if there is no precise value being used we would still rely on reach the needed UL power.

• Preamble_Initial_Power = Primary CPICH TX power – CPICH_RSCP + UL interference + Constant Value

108103 – FEATURE DESCRIPTION– UL INTERFERENCE FOR COMMON E-DCH IN SIB5 2/2



36


•The solution for updating UL Interference for Common E-DCH in SIB5 with provisioned value configuthe chosen approach.

•In LR14.W time frame the parameter FddCell.isEaiAllowed is redirected to activate the use of ULCommon E-DCH in SIB5.

•When activated, the default value -104 dB would be used. ST’s result shows that there could be extr

drop.•The constraint on the existing FddCell.isEaiAllowed parameters was that it only supports Boolean valuse this paeameter with extra range to introduce several values (interference level for instance)

•Note : this parameter was in fact used to configure the EAI policy to the NodeB, the RNC will hard-codthe NBAP message depending on the activation of general eFACH flag.

•In LR15, a new parameter is defined as part of CommonEdchInfo.isUlInterferenceInSib5Activated (Bool

•If TRUE, populate UL Interference for Common E-DCH with value defined by CommonEdchInfo.U

•If FALSE, do not make use of UL Interference for Common E-DCH CommonEdchInfo.ulInterferenc

•The recent tests on LR14 scope show that in extreme cases we may encounter an extra time of preamin any case are much smaller than the 80ms observed initially

108103 – FEATURE DESCRIPTION– TRAFFIC MEASUREMENT REPORTING



37


•Following the same method as in Legacy CellFACH, the eFACH also considers the traffic monitoring aswhich users need higher data rates and specifically need to be upsized to CellDCH.

•The principle relies on a function of Traffic volume monitoring that will allow to compare the TransporVolume with a certain Reporting threshold configured via OAM.

•If this traffic volume measured thru TVM overcomes the reporting threshold than a measurement

which could then have consequent actions on RNC side

•The repetition of this event is only possible after the traffic Volume decreases below the threshold an(trigger by Crossing threshold method).

•Similarly there is an event associated with a measurement report for a too low traffic volume whichCrossing threshold method.

•These events are associated with Time-To-Trigger and a pending time after trigger

108103 – FEATURE DESCRIPTION– ALWAYS-ON UPSIZE AND DOWNSIZE



38


•The following section not all parameters are detailed as they are presented later on this document ansame rational and explanation of the existing legacy CellFACH behavior. Also many related parameterlegacy eFACH like TimeToTrigger, pendTimeAfterTrig, measTrafficQuant and several other.

•Downsize

•AlwaysOnConf.AoOnEnhancedFachParam.step1DlUlThroughputThresholdeCellfach this is the th

rate for DL and UL transition from CELL_DCH to enhanced CELL_FACH value proposed 32kbps

•AlwaysOnConf.AoOnTimer(x).timerT1forECellfach Timer for UE downsize from CELL_DCH staCELL_FACH state. Set when the UE traffic indicator becomes below the Throughput Threshold SHSDPA/E-DCH.

•AlwaysOnConf.AoOnTimer(x).timerT2forECellfach Inactivity timer for UE downsize from enhastate to URA_PCH/CELL_PCH state or idle mode. Set when the UE traffic indicator becomes belowThreshold Step 2 on common HSDPA/E-DCH.

•Upsize•AlwaysOnConf.AoOnEnhancedFachParam.Step1DlRlcBoThresholdECellfach Threshold on TRB RLC that is monitored by the RNC on the downlink for transition from enhanced CELL_FACH to CELL_DC

•AlwaysOnConf.AoOnEnhancedFachParam.repThresholdECellFach e4a-based UL Upsize thresholdfrom enhanced CELL_FACH to CELL_DCH

108103 – FEATURE DESCRIPTION– ALWAYS-ON TRANSITIONS AND MEASUREMENTS CONF



39


•However, for eFACH it is considered as not enough as the amount of buffered traffic may not be enodecide if a call is handled by eFACH. Additional conditions are taken to not allow efach usage.

•If the IE “Call type” == speech, video, other in RRC message RRCCONNECTIONREQUEST, CELLUPDATE,if IE “Establishment cause” == Originating Conversational Call or Originating Streaming Call Conversational Call or Terminating Streaming Call.

•The principle of most restringing service takes the final call and the fact that no Multi PS is supportedis in Legacy FACH should be respected.

•The same principle will apply to the Setup of Measurement controls that allow the ue (or internal etrigger the changes of state.

•Whenever a call is established, modified or released, the RNC shall setup, (modify) or release tcontrol procedure associated with the triggers via sending new/updated MEASUREMENTCONTROL messa

•Once the RNC decides to switch the UE from CELL_FACH to CELL_DCH state (AO Upsize), it shall alloc

E-DCH resources for the UE by using one of explicit RRC signaling messages; RADIO BEARER RECONFIGBEARER RELEASE, RADIO BEARER SETUP.

•If RNC decides to transit the UE between the enhanced CELL_FACH state (common E-DCH) and the(regular E-DCH), a seamless (without the need of reconfiguration) transition shall be performed wconfigurations for UL in both states: RLC mode, MAC-i/is, TTI.

•In case AO upsize fails when the UE was in CELL_FACH, he RNC shall keep the UE in CELL_FACH state.

108103 – FEATURE DESCRIPTION – TRANSPORT HEADERS DETAIL



40


• The UL eFACH will rely onthe Enhanced L2 for ULPM89563 and flexible PDUsize.

•The benefit of flexible PDUsize allows the network tohandle IP packets with lessfragmentation and thus amore efficient data transferwith less overhead

•The feature follows the sameprinciple as the DL L2enhancement where RLC PDUsize can go up to 1500 Bytes

which can carry an entire IPframe

•The RLC UL (EDCH) for PS IBcan thus vary from 8Kbits to12kbits (1500Bytes) . Howeverthe RLC for SRB will use fixedPDU size

MAC-is PDU<21 B

MAC-i PDU

MAC SD152 B

MAC-c PDU

Assuming m in E-TFCI 1, 10ms TTI (TBS = 186 b its)

MAC-is PDU153 B

IP20 B

I

Applic

Signaling(CCCH)

MAC SDU<20 B

MAC-is S152 B

MAC-is PDU

MAC-is SDU<20 B

TSN

6 bSS

2 b

TSN

6 bSS

2 b

LCH-ID

“1110”

L

11

F

1

Hdr 1

MAC-i PDU < max TBS

Internet Packet

RLC 150

Hdr

16 b

RLC PDU

RLC SDU<20 B

Max Sized PDU Flexible Siz

LCH-ID

4 b

L

11

F

1

Hdr 1

LCH-ID

4 b

S

4

E-RNTI

16

Hdr 0 (Opt.)

MAC-i PDU

MAC-d PDU

MAC-is PDU

RLC PDU

108103 – FEATURE DESCRIPTION – EFACH NEW RLC CONFIGURATIONS



41


•The rule to re-establish the RLC when switching between fixed and flexible mode is observed .

•In nominal operation, the MAC-ehs and Mac-is capability would be available in both CELL_DCH and CEthe RLC mode would be compatible between the RRC state transitions, and by extension, no RLC reestoccur.

•There are new RLC instances associated with RBSetconfs to support eFACH DL and UL. Currently the

1:1 on RLC configurations and RBSetConf

ScenariosSRB/TRB RLC Configuration

DL RLC Configuration UL RLC Configuration

1 R99 FACH/RACHSRB_CellFACH_AMUM SRB_CellFACH_AMUM

TRB_CellFACH_AM TRB_CellFACH_AM

2 R7 eFACH/RACHSRB_COMMON_HSDSCH_EDCH_AMUM SRB_CellFACH_AMUM

PS_IB_COMMON_HSDSCH_EDCH_AM TRB_CellFACH_AM

3 R8 eFACH/ERACHSRB_COMMON_HSDSCH_EDCH_AMUM SRB_COMMON_HSDSCH_EDCH_

PS_IB_COMMON_HSDSCH_EDCH_AM PS_IB_COMMON_HSDSCH_EDC

4 HS-DSCH/E-DCHSRB_HSDSCH_EDCH_AMUM SRB_HSDSCH_EDCH_AMU

PS_HSDSCH_EDCH_IB_AM PS_HSDSCH_EDCH_IB_AM

108103 – FEATURE DESCRIPTION– MAPPING OF UL FLOW, SRB/TRB OVER UU AND IUB 1/



42


•The side picture is pretty elucidativeabout the way the several SRB/TRB logicalchannels will be mapped into the MAC-d

•The different MAC-d will then beencapsulated in MAC-i and later on FP ULCommon MAC Flow of user plane andcontrol plane.

•For DCCH/DTCH transmission, NodeB shallalways include E-RNTI in “Common E-DCHFP” However UE only does that in MAC-iheader up to the Collision Resolutionphase

•Multiple logical channels can be

multiplexed into the same MAC-d flow (e.g.SRB1-4 in MAC-d flow 0) over the Airinterface

•Multiple MAC-d flows can be multiplexedinto the same UL Common MAC flow (e.g.MAC-d flow 0 and 7 for SRB1-4 and SRB0can be in a single UL Common MAC flow)over Iub transport.

108103 – FEATURE DESCRIPTION– IUB, OLS AND QOS DIFFERENTIATION



43


•The usage of QoS differentiation on eFACH is possible through the usage of different priority and QOSto the traffic over UL common MAC flow and Common EDCH MAC-d flow.

•Up to 8 EDCH Common MAC-d flows can be configured, the ones with common QOS transport demapped together on a UL Common MAC flows.

• The common E-DCH Mac-d flows are configured in: FddCell.edchResource->edchCellClass >Com

>CommonEdchMacdFlows.

•The table attach gives an example of QOS of transport layer used for

different MAC-d and logical channels usage also depending on SPI.

Enhanced Cell_FACH is similar to Cell_DCH from a traffic priority pointof view

The main idea is that a user can keep the same Priority and and QOSbetween Cell_DCH and Enhanced Cell_FACH, with similar relative SPIand preserved QoS.

•The Efach traffic is mapped on the transport QOS2

•The flag RAS.RbCongestionControl.eCellFach SlowStartActivation is

added to activate eFACH slow-start independently from legacy HS-

DSCH slow-start on CELL_DCH

(RbCongestionControl.hsdschSlowStartActivation).

• A new OAM CommonPriorityQueue.minBr is added to floor the slow-

start rate

108103 – FEATURE DESCRIPTION– POWER CONTROL IN EFACH 1/3

•There is no outer loop Power control for enhanced UL CellFach Only the inner loop will be enf



44


•There is no outer-loop Power control for enhanced UL CellFach, Only the inner loop will be enfSirTarget (see activation strategy below for more details). This means that this SIR Target is fixed and carefully.

•The most suited Power control Algorithm for the eFACH is the PCA1 independently of 2ms or 10 ms ttiwill cause some challenges as detailed below.

•The most common algorithm used for edch 2mstti is PCA2, mainly for the cases of UeCategoUeCategory6 TTI2ms, this is due to a very fast increase of ue TX power with PCA 1 which could generload.

•This means we will need a reconfiguration of PCA when the call upsizes from eFACH to CellDCHparticular scenario.

RL setup

UE Node B

RRC RB REconfiguration(FACH)

Try Synch PCA1

Case 1 RRC RB Reconfiguration Complete (DCH)

Case 2 RRC RB Reconfiguration Complete (DCH)

No Synch

SynchPC Preamble

Synch

On this case scenario the Node B is

sending to the UE the Synch frames

however the RB reconfiguration

message will be sent out before this

synch is achieved and so the probability

of success is lower for the UL message

to be successfully decoded

On this case the UE needs to send out 7

preambles according to the settings

(Npcp=7; SRBdelay =0), this means 70ms

delay which would allow the synch to be

achieved before the RBReconfiguration

being sent Nominal case for FACH to

DCH transitions

108103 – FEATURE DESCRIPTION– POWER CONTROL IN EFACH 2/3

•In order to detail the issue presented on previous picture it is presented below the two possible scena



45


•In order to detail the issue presented on previous picture, it is presented below the two possible scena

•After NBAP RL Setup is received, the NodeB starts to send the TPC pattern using PCA1. There is no indNode B used because there is no IE since UA8 on the RL Setup message.

•The RB Reconfiguration is sent on CELL_FACH.

•Upon reception of RB Reconfiguration on HS-DSCH, the UE, if it still has the common E-DCH, would r

transmission continuation back-off timer. With the current setting of 24, it’d mean the UE would common E-DCH 240ms later.

•Based on 3GPP requirement, the RB Reconfiguration message has to completely be processed within no need to perform the synch A, then the RB Reconfiguration Complete has to be sent back right awthere are 2 scenarios that happen at about the 100ms point, after RBReconfiguration is sent:

1. No synch achieved yet So the NodeB can’t decode the uplink message; NodeB would synchafter (Ninsynch=2) ~40ms; uplink E-DCH decoding can start, Eventually the HARQ retraReconfiguration Complete (16ms*3=48ms) would be received or the RLC would help to clear textra delay of 143ms for the reconfiguration this scenario is more plausible under bad racell edge

2. On the scenario where synch is achieved already The UE would need to send back the PCframes (Npcp=7; SRB delay=0), as before the Node B needs 40ms for the Synch procedure itime for the UE procedure allow the Node B to complete the Synch and so the UL transfer is already achieved allowing a successful decode on UL for the RB reconfiguration

108103 – FEATURE DESCRIPTION– POWER CONTROL IN EFACH 3/ 3

•There were several solutions identified for this issue the ones presented below are mainly re



46


There were several solutions identified for this issue, the ones presented below are mainly reparameter workaround.

•The solution identified by parameter optimizations are advanced parameter tuning

• One possibility may be to force the upsize to be done over 10ms into CellDCH. We coureconfiguration to 2ms tti based on features like PM 120363 and PM122612 (also known as EDCH40burstyTrafficEdch400kbsReconfigStabiliserTimer

•The flag isECellFachTo2msEdchRestrictionEnabled is thus used to force eFACH users to traCELL_DCH using 10ms-TTI E-DCH instead of 2ms-TTI.

•Another option to correct this is based on the usage of isTpcPattern2ForEdch2msTtiAllowed. This paan algorithm that for all transitions to a target CELL_DCH of 2ms TTI E-DCH using PCA2 would havpower control preamble frame hard-coded to 0, and that of SrbDelay hard-coded to 7. This WorkArothe UE and Node B to synchronize before the message RbReconfigurationComplete is sent. So when thithe PCA2 is already aligned between UE and node B, which allows a correct power to be used and th

chances of successful message in UL.

108103 – FEATURE DESCRIPTION– R8 EFACH SPECIFIC ALWAYS-ON MODE



47


•In Legacy CellFACH we can set two different behaviours for the AlwaysON Mode:

•Degraded2AlwaysOnOnly- where the transition follow as target the Step1 (legacy CellFACH)

•ReleaseOnly – where the CellFACH is bypassed and transition is performed towards Idle or PCH Sta

•In multi-service configuration involving HSPA (i.e. CS + PS HSPA), the CellFACH behavior allow the P

downgraded state (i.e. CS + PS-downgraded HSPA):•1. PS 0/0 if any PCH state is activated or

•2. PS Idle if PCH state is not activated

•When eFACH in UL is activated for R8+ eFACH capable UE, the following behaviours apply:

•The new OAM parameters RadioAccessService.DlRbSetConf.isAlwaysOnAllowedECRadioAccessService.UlRbSetConf.isAlwaysOnAllowedECellFach would overwrite the behavior always-on policy defined by DlRbSetConf.isAlwaysOnAllowed and UlRbSetConf.isAlwaysOnAllowed.

•For mono-PS, the R8-specific always-on timers and thresholds to downsize as defined by this fused.

•For multi-PS and multi-service (i.e. CS + PS HSPA), the handling is unchanged from earlier UE rethresholds and timers are used.

108103 – FEATURE DESCRIPTION – DIRECT ESTABLISHMENT TO EFACH



48COPYRIGHT © 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

•To increase the usage of eFACH in case URA_PCH is not available, it can be possible to allow R8+ UEConnection Setup directly to eFACH, and for TRB to be established in eFACH state.

•However the for R7 and earlier UE, the behavior remains unchanged, which means, all transition froCELL_DCH except for the handling of “Detach” cause.

•This new behaviour can be set through the RNC.RadioAccessService.ServiceInit.UserServices

configuration of SRB depending on the establishment cause.

•The solution consists of cloning another instance RNC.RadioAccessService.ServiceInit.UserServicesECeestablishment specific.

•Upon RRC Connection Request, if the UE is R8 eFACH capable and the eFACH UL is activated in the celSRB configuration (i.e. SRB on eFACH) is selected from that new eFACH specific table to perform theprocedure.

•Likewise at PS I/B RAB Assignment, if the SRB is in eFACH state, and the newly de

RadioAccessService.isTrbSetupInECellFachAllowed is set to TRUE , then the PS is established directlyOtherwise, if the flag RadioAccessService.isTrbSetupInECellFachAllowed is set to FALSE , then the exiestablishment over CELL_DCH would apply.

•To secure iso behavior, all entries in the new table have the same value as in the legacy table.

108103 – FEATURE DESCRIPTION – MOBILITY

Th M bilit diti i FACH b li it d d t l CEM




•The Mobility condition in eFACH may be limited due to several reasons; no CEM resources compaenable on Target/source cell, failure of mobility due to allocation of resources

•These are the 4 mobility cases supported over LR14.2.W:

The list below lists the mixity mobility use cases that are not supported and will result in a abnormal caconsequent pegging of PS drop counters :

• Cell reselection to cell with different eFACH capability during the following state transitions:

- Cell_DCH to Cell_FACH.

- Cell_PCH to Cell_FACH.

• Cell reselection to cell with different eFACH capability during mobility in Cell_FACH.

• Mobility in x_PCH from/to enhanced Cell_FACH capable cell to/from legacy Cell_FACH capable cell.

•These are however low on incidence since the reselection would have to happen during the transition/

4

Cell_FACH

UeCell_FACH

Cell_FACH

eCell_FACH

eCell_FACH

1 2 3

URA_PCH

eCell_FACHeCell_FACH

- URA_PCH to Cell_FACH.

- Cell_PCH to Cell_DCH.

- URA_PCH to Cell_DCH.

- Cell_FACH to Cell_PCH.

- Cell_FACH to U

- Cell_FACH to C

108103 – EXAMPLES OF CALL FLOWS 1/3

U 1 Idl t llFACH




•Use case 1: Idle to cellFACH

• UE initiates eRACH accessand sends RRC ConnectionRequest message (may includeIE “Measured results onRACH”) over Uu, which is

received on CCCH overcommon E-DCH Mac-d flow.

•As soon as the UE finishessending RRC ConnectionRequest on CCCH, it willimmediately release theacquired common E –DCH.(implicit release)

UE SRNCNode B

SRB1: CCCH: common HS-DSCH priority queue: Common HS-DSCH: RRC Connection Setup (Targdedicated H-RNTI, E-RNTI from E-RNTI list, RB mapped to common E-DCH MAC-d flow and common HS

eRACH/ SRB0: CCCH: common E-DCH Mac-d flow 7Common E-DCH : RRC Connection Request (UL data transmission)

(eRACH /) SRB2: DCCH: Common E-DCH MAC-d flow: Common E-

DCH: RRC Connection Setup Complete

Iub HS-DSCH Type2 FP (Common H-RNTI,new IEs: dedicated HRNTI, E-RNTI)

Idle

CellFACH


•Use case 2: eFACH to cellDCH




Use case : e C to cell C

•UE in eFACH state initiates eRACHaccess and directly sends messageover Uu, which is received onDCCH/DTCH over common E-DCHMac-d flow

• While reconfiguring to CellDCHRNC can either re-assign thecurrent dedicated H-RNTI or assigna new dedicated H-RNTI. On theother hand the E-RNTI is reassignedsince it is now part of dedicatedpool

•RB Reconfiguration message

includes the new H-RNTI and E-RNTI that have been allocated forCell_DCH state; but on the HS-DSCH FP frame carrying the RRCmessage still contains dedicated H-RNTI and E-RNTI used duringCELL_FACH state as Cell DCH idwere still not known to UE.

SRB2: DCCH: common HS-DSCH priority queue Common HS-DSCH:RB Reconfiguration (Target State: CELL_DCH, dedicated H-RNTI, dedicated E-RNTI)

UE SRNCNode B

SRB2: DCCH: dedicated E-DCH MAC-d flowDedicated E-DCH: RB Reconfiguration Complete

eRACH / TRB: DTCH: Common E-DCH MAC-d flow: Common E-DCH: Packet Data Transf

NBAP: RL Setup Restore Ind.

Collision Resolution via E-AGCH

NBAP: RL Setup Request (dedicated H-RNTI, CRNC-Communicatio

NBAP: RL Setup Response (dedicated E-RNTI allocated, NodeB-Comm

Iub Setup

CellFACH

CellDCH

TRB: DTCH: dedicated E-DCH MAC-d flow: Dedicated E-DCH: Packet Data Transfer


•Use case 3: CellDCH to eFACH




•if UE is eFACH capable (indicatedby “Common E-DCH support” IE inRRC Connection Request / CellUpdate and Cell have common Edchfeature active then RNC can select

eFACH as target state.

•After getting RB Reconf to move toCell_FACH state, UE has to doeRACH preamble access procedureand after getting anacknowledgement in AICH, can usecommon E-DCH resources.

•It will send RB Reconf Complete on

the common E-DCH resource, it willuse assigned E-RNTI until collisionis resolved.

SRB2: DCCH: common HS-DSCH priority queue Common HS-DSCH:RB Reconfiguration (Target State: CELL_FACH, dedicated H-RNTI, new common E-RNTI)

UE SRNCNode B

eRACH/SRB2: DCCH: commonE-DCH MAC-d flowCommon E-DCH: RB Reconfiguration Complete

Traffic monitoring functions are running and detect low throughput

NBAP: RL Deletion Request (RL_id, CRNC-Communication Contex

NBAP: RL Deletion Response (NodeB-Communication Contex

CellFACH

CellDCH

Traffic monitoring functions are running again in eFACH to detectother possible state transitions needed

Iub HS-DSCH Type2 FP (new IEs: dedicated H-RNTI, E-RNTI)





1.3 | UPGRADE RULES

108103 – UPGRADE RULES

•Feature is activated by the flag RadioAccessService isEnhancedCellFachForUlAllowed at RNC level




•Feature is activated by the flag RadioAccessService.isEnhancedCellFachForUlAllowed at RNC level

•To deactivate the UL common EDCH feature it is enough to set this flag to FALSE.

•However the UL eFACH relies on the DL eFACH, to assure that the eFACH DL and UL are deactivated upgrade we should assure that :

•If in LR13.3 the eFACH DL was deactivated then:

•RadioAccessService.isEnhancedCellFachForDlAllowed at RNC level is set to FALSE

•If in LR13.3 the eFACH DL was activated then:

•RadioAccessService.isEnhancedCellFachForDlAllowed at RNC level is set to TRUE





1. 4 | FEATURE ACT IVAT ION

108103 - FEATURE DEPENDENCIES

The following list of features are mandatory or highly recommended to be used



56


The following list of features are mandatory or highly recommended to be used

•34388 L2 improvements:118687 can be activated only if 34388 is activated

•89563 Enhanced L2 Uplink: Required by PM108103

•PM97427 Local Node-B Iub E-dch Congestion Control Enhancements

•For the next features there are important interactions with PM108103

•PM29810 F-DPCH and SRB on HSPA: Is not needed as a new feature to be activated although the eFACH uses FDPCH. This means pa

“isSrbOverHspaEnabled” can be set to false independently from eFACH activation. When eFACH is activated and isSrbOverHspaEnab

still make use of F-DPCH but only in Enhanced Cell_FACH state (not in Cell_DCH state).

•PM159246/108389 Direct PCH to DCH transition cluster: See next slide

•PM33694 NodeB Fair Sharing of resources: Have to take into account the new common E-DCH resource request when reserving the

•PM120363 NodeB Smart E-DCH Resource Usage: Have to take into account that E-DCH resources reserved by common users can’t b

users.

•UA07.1.2 PM34441 and UA08 82602 E-DCH CAC: PM34441 introduces E-DCH CAC for CELL_DCH state in RNC based on two OAM para

EdchCellClass: edchMaxUsersPerCelland edchMaxLegs2msPerCell. It is expected that the operator will adapt the CELL_DCH CAC Thr

EDCH is configured in the cell. (Note 2mstti efach is not supported)

•PM89857 (iMCRA) would be extended to eFACH UL capable UE. When an EFACH UL capable UE is re-directed via iMCRA to an eFACH

108103 – FEATURE DEPENDENCIES – PCH TO DCH DIRECT TRANSITION

•The initial intent of Direct transition feature is to allow a user standing in PCH state to jump over



57


g j pbecause for some users with high traffic need, CellFACH would be just a useless step.

•This was achieved with the setup of a certain TVI threshold which in practice is the same as the repthis threshold is achieved the RNC decides to bring the call directly to CellDCH.

•Later on a new development considered an Unconditional option where all call in PCH state would

upsize to CellDCH independently of Establishment cause or TVI value.

•With the availability of eFACH the concept of “useless Step” is changed as the eFACH state is actuallow latency and higher throughputs. Which means a different approach may be needed for the eFACH c

•So if eFACH and Direct transition PM 108389 are enabled and UE is eFACH capable the call standing use the AoOnEnhancedFach.repThresholdECellFach as the value configured on ue to decide the CEllUpdate message, which could then trigger the upsize to CellDCH directly.

•This means that normally UE’s eFACH capable will not trigger the transition to CellDCH if the threshold

•On the other hand if Enhanced Direct transition is enabled with unconditional option (PM 159246_2), aactive the upsize target state will depend on:

•Ue is eFACH capable Upsize to eFACH

•UE is not eFACH capable Upsize to CellDCH

108103 - FEATURE ACTIVATION STRATEGY

•The eFACH for UL is activated per cell, but there are several flags/conditions to be observed (more de



58


p , g (

•Feature is activated on the RadioAccessService.isEnhancedCellFachForUlAllowed at RNC level

•Feature is active on FDDCell.isEnhancedCellFachForUlAllowed at Cell level

•Feature is active on EdchConf.isEnhancedCellFachForUlAllowed at BTS level

•As prerequisite it is also mandatory that the related features are enabled as referred on previous sect

•RadioAccessService.isEnhancedCellFachForDlAllowed at RNC level

•FDDCell.isEnhancedCellFachForDlAllowed at Cell Level

•HsdpaConf.isEnhancedCellFachForDlAllowed at BTS level (only iBTS)

•The feature 89563 (enhanced L2 for UL) has been activated with RadioAccessService.isMaciisAllow

and FDDCell.isMaciisAllowed at cell level•The feature 34388 has been activated with RadioAccessService.isMacEhsAllowed at Rnc Level andFDDCell.isMacEhsAllowed at cell level

•Also it is important to verify that the NBAP messages confirm the cell eligibility Common E-DCH and Co

• “Common E-DCH Capability” IE = "Common E-DCH Capable (NBAP RESOURCE STATUS INDICATION)

• " Enhanced FACH Capability IE = “Enhanced FACH capable” (NBAP RESOURCE STATUS INDICATION)

108103 - FEATURE ACTIVATION

•IN order to define the Buffer eFACH thresholds for the Upsize transitions and number of users (which a



59


p (some other resources to reserve), there were some studies from PLM to define initial settings in terms and current penetration of UE eFACH capable

•The result from GM customer show that a good compromise on this case would be:

•RepthresholdECellFACH = trafficRepThrs8K

•step1DlRlcBoThresholdECellfach =10 000

•numbe rO fCommonEdchResou r ce s

=3

ReferenceBHDA per cell

Target

SessionPayload

cEDCH Resources Required

R8 eFACH UE Penetration

1-20% 21-40% 41-60% 61-80%

Mean 1200

≤1KB

2

2

2

2

≤5KB 2 2 3 3

≤10KB 2 3 3 3

≤50KB 2 3 4 4

99.0%-

tile

5500

≤1KB 2 3 3 4

≤5KB 3 4 5 6

≤10KB 3 5 6 7

≤50KB 4 6 7 9

108103 RAN MODEL (1/3) RNC



COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED. ALCATEL-LUCENT — INTERNAL PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION

60

RadioAccessService

NodeB

FDDCell

HsdpaResource

DedicatedConf

HsdpaCellClass

EdchComm

isECellFachTo2msEdchRestrictionEnabled

isEnhancedCellFachForUlAllowed

isRlcReconfigurationECellFachAllowed(NA)

isTpcPattern2ForEdch2msTtiAllowed

isTrbSetupInECellFachAllowedCommonEdchHsdpcchA

isEaiAllowedisEnhancedCellFachForUisFastL1SyncForECellFa

transportQo

MinBr

targetMacCQueueDelay

HsdpaCommonSysInfo

CommonPriorityQueue

Rbsetconf UL & DL

isAlwaysOnAllowedECellFach

Serviceinit

UserServicesECellFach

dlUserServiceIdulUserServiceId

CacConfClass

CacOnFachParam

maxNumberOfEnhancedCellFachUsersPerCell


NodeB




61

RadioAccessService

repThresholdECellFach

step1DlRlcBoThresholdECellFach

step1DlUlThroughputThresholdECellFach

AlwaysOnConf

AlwaysOnEnhancedFach AlwaysOnTimer

timerT1ForECellFach

timerT2ForECellFach

DedicatedConf

EDCHcellClass

FDDCell

EDCH Resource

deltaEdpcch

edchMaxSfCa

edchMinSetEt

edchTfciTable

ergch2IndexS

ergch3IndexS

happyBitDelay

harqInfo

minReducedE

periodicityOfS

periodicityOfS

plNonMax

powerOffsetF

CommonCommonEdchInfo

additionalEdchTxBackoff

edchTxContinuationBackoff

maxCcchResourceAllocationmaxPeriodForCollisionResolution

maxTbSizeCellEdgeUsers

maxTbSizeOtherUsers

numberOfCommonEdchResources

powerCtrlAlgo

ulSirTarget

ulTpcStepSize

CommonEdchMacdFlow

CommonEdchSysInfo/10msTti

CommonEdchMacdFlow

edchHarqMaxRetrans

edchMacdPowerOffset

spi

CommonEdchHsdpcchInfo

ackNackRepetitionFactor

ackPowerOffset

cqiFeedbackCycleKcqiPowerOffset

cqiRepetitionFactor

measurementPowerOffset

nackPowerOffset

isEdchTti2msECellFachAllowed

. . .


NodeB




62

RadioAccessService

DedicatedConf

EDCHcellClass

FDDCell

EDCH Resource

CommonEdchP

powerOffsetPpe

CommonEdchSysInfo/10msTti

CommonEdchFdpchInfo

dlTpcStepSize

fdpchTpcErrorRateTarget

initialDlPower

maxDlPower

minDlPowe

isEdchTti2msECellFachAllowed

CommonEdchPreambleCtrlInfo

mMax

Nb01Max

Nb01Min

BTS Equipment

EDCHConf

maxNumberOfCommonEdchResourcesPerBoard

nInSyncIndECellFach

nOutSyncIndECellFach

tResReleaseSafeGuardECellFach

tMaxCommonEdchResAllocation

tRlFailureECellFach


cqiThresholdForCellEdgeECellFach

HSDPAConf

cqiValidityTimerTtieFachSeThresholdOneHsPdschCodeFallback

FEATURE CONFIGURATION AND PARAMETERS ( MAIN ACTIVATION)

id tit D i ti bj t d it



63


param identity Description object name range and unit

i sCommonEdchHsdpcchA l l owed A cell-level activation flag for Common E-DCH HS-DPCCH sub-feature which allows the HARQ and theCQI reporting. If eFACH DL and UL is used this flag

should be true.

FDDCell Boolean [True, False]

i sEdchT t i 2msECe l l F a chA l l owed This feature enables/disables the support of E-DCHTTI 2ms for enhanced Uplink for CELL_FACH feature

within the radio cell. A cell supporting this eFACH

feature 108103 (3GPP Rel8 baseline) can beconfigured in either 10ms TTI or 2ms TTI, but not

both simultaneous

EdchCellClass Boolean [True, False]

i sEnhancedCe l l F a chForU lA l l owed Cell level feature activation flag for EnhancedCELL_FACH in UL (i.e. common E-DCH

transmission), controlled by NodeBEdchConf Boolean [True, False]

i sEnhancedCe l l F a chForU lA l l owed

Cell level feature activation flag for EnhancedCELL_FACH in UL (i.e. common E-DCH

transmission), controlled by RNCFDDCell Boolean [True, False]

i sEnhancedCe l l F a chForU lA l l owed RNC level feature activation flag for EnhancedCELL_FACH in UL (i.e. common E-DCH

transmission).RadioAccessService Boolean [True, False]

i s F a s tL 1SyncForECe l l F a chA l l owed Allow Activation of Fast L1 at Cell level for eFACH (inrestriction) it means the ue will have to wait for the

40ms of post verification so tha the SYNCH isdeclared before it starts transmitting.

FDDCell Boolean [True, False]

•These are the main flags of feature activation, where the main activation ones are highlighted

•The parameters restricted are marked in red

FEATURE CONFIGURATION AND PARAMETERS (STATE TRANSITION EFACH)

param identit Description object name range and nit



64



repThresholdECe l lFach

E4a-based UL Upsize threshold (traffic volume) fromenhanced CELL_FACH to CELL_DCH

AoOnEnhancedFachEnum [trafficRepThrs8, .. ,

trafficRepThrs8K, ..,trafficRepThrs768K]

s tep1D lR l cBoThr e sho l dECe l l F a ch

RNC U-plane load-based DL Upsize threshold,Threshold on TRB RLC Buffer occupancy that is

monitored by the RNC on the downlink for transitionfrom enhanced CELL_FACH to CELL_DCH.

AoOnEnhancedFach bytes [0 .. 1000000]

s tep1D lU lTh r oughpu tTh r e sho l dECe l l F a ch

RNC U-plane load-based UL/DL Downsize threshold.Threshold on user rate for DL and UL transition from

CELL_DCH to enhanced CELL_FACH. AoOnEnhancedFach bits/s [0 .. 1000000]

t ime rT1ForECe l l F a ch

Timer for UE downsize from CELL_DCH state toenhanced CELL_FACH state. Set when the UE trafficindicator becomes below the ThroughputThreshold

Step 1 on regular HSDPA/E-DCH.

AlwaysOnTimer ms [0 .. 3600000]

t ime rT2ForECe l l F a ch

Inactivity timer for UE downsize from enhancedCELL_FACH state to URA_PCH or CELL_PCH state.

Set when the UE traffic indicator becomes below theThroughputThreshold Step 2 on common HSDPA/E-

DCH.

AlwaysOnTimer ms [0 .. 10800000]

•These parameters are the one used for tuning the state transition behavior in terms of triggering timethreshold

FEATURE CONFIGURATION AND PARAMETERS (IBTS SYNCH AND RESOURCE )




65



ma xN u mb e r O f C ommon E d c h R e sou r c e s P e r Boa

rd

Maximum number of Common E-DCH Resources(combined for all cells) per board (e.g. eCEMboard). This is to control the max number of

shared E-DCH resources assigned for e-Cell_FACHusers (i.e. max number of simultaneous active

eFACH UEs per board)

BTSEquipment Enum. [0 .. 96]

nInSync IndECe l l F a ch

This parameter defines the number of successive

in-sync indications after which the nodeB shallassume the radio link to be in-sync.TS 25.214

N_INSYNC_IND

BTSEquipment frames [1 .. 256]

nOutSync IndECe l l F a ch

This parameter defines the number of consecutiveout-of-sync indications after which the out-of-sync

is detected.TS 25.214 N_OUTSYNC_INDBTSEquipment frames [1 .. 256]

tMaxCommonEdchResA l l oca t i on

This supervision timer defines the maximum timeperiod that a UE is allowed to continuously occupya common E-DCH resource. Once this supervisiontimer expires, the NodeB shall release the Ue (See

detail on Implicit and explicit release)

BTSEquipment s [ .. ]

tRe sRe l ea seSa f eGua rdECe l l F a ch

This timer is used to ensure that the UE hasdefinitely detected DL Sync loss on a common E-

DCH resource and consequently releases it afterthe NodeB has stopped F-DPCH transmission.


tR lFa i lureECe l lFach

The Radio Link Failure procedure shall be triggeredafter this period of time (tRlFailureECellFach) haselapsed with a persisting out-of-sync indication.


•These parameters are referring to L1 Synchronization failures procedures over eFACH. The principle is CellDCH Synch procedures and rely on FDPCH quality monitoring

•The colored parameters refer to Common EDCH resources

FEATURE CONFIGURATION AND PARAMETERS (RNC/RADIOACCESSSERVICE)

param identity Description object nameran



66


param identity Description object name

isECellFachTo2msEdchRestrictionEn

abled

This parameter indicates if the transition from Enhanced Cell Fach for UL to CELL_DCH (2ms TTI E-DCH) is

allowed or not.When the flag is set to TRUE, then the RNC will always force a 10ms TTI E-DCH when transit

from eFACH UL to CELL_DCH.

RadioAccess

ServiceB

isRlcReconfigurationECellFachAllow

ed

This parameter indicates if the target RLC configuration in eFACH should follow the policy as defined in theRbSetConf (when set to FALSE), or follow the hard-coded rule (when set to TRUE). The hard-coded rules

are:If eFACH/RACH is used, then use the Rlc Conf defined by SRB_COMMON_HSDSCH_RACH_AMUM for

SRB and PS_IB_COMMON_HSDSCH_RACH_AM for TRB, in both uplink and downlink directions. Similarly,

if E-RACH/E-RACH is used, then the SRB_COMMON_HSDSCH_EDCH_AMUM andPS_IB_COMMON_HSDSCH_EDCH_AM would apply.

RadioAccess

ServiceB

isTpcPattern2ForEdch2msTtiAllowed

This parameter indicates if its allowed to use the proprietary PCA2 pattern instead of the 3GPP 0-1 pattern

during the initial RL Synchronization or not. To configure the UE, the Npcp is hard-coded to 0, and SRB Delay,

to 7, in this case. The activation of this flag is mutually exclusive to

isECellFachTo2msEdchRestrictionEnabled. Expert ALU tuning only. The 2 parametersisECellFachTo2msEdchRestrictionEnabled and isTpcPattern2ForEdch2msTtiAllowed should not be both set

to true but the other combinations are allowed (notably false/false).

RadioAccess

ServiceB

isTrbSetupInECellFachAllowedThis parameter indicates if its allowed to set up a TRB directly to eFACH state. This policy is only for R8+ UE

when eFACH is activated.

RadioAccess

ServiceB

Note: Besides the exclusive behaviour withi sECe l l FachTo2msEdchRes t r i c t i onEnab led

which is restrithere is also a check when activating this parameter in order to make sure it is only used if the most impoUL category are used. So this parameter should only be set to true if needed to improve the AO upsize traRad ioAccessSe rv i ce isTpcA lgo2ForEdchCa t4

andRad ioAccessSe rv i ce i sTpcA lgo2ForEd chCa t6

isRlcReconfigurationECellFachAllowed : is restricted to False on LR14.2.W. The RLC configuration will

from the RBSetConf pointer.

FEATURE CONFIGURATION AND PARAMETERS (COMMON EDCH 1/2)

param identity Description object name ran



67


param identity Description object name ran

deltaEdpcch (*) it specifies common E-DPCCH Power Offset. NBAP & SIB5CommonEdchEdpchI

nfoEn

edchMaxSfCapabilityit specifies Maximum channelisation codes (i.e. Maximum Set of E-DPDCHs) for common E-DCH

operation. NBAP & SIB5

CommonEdchEdpchI

nfo

edchMinSetEtfci it specifies E-DCH minimum set E-TFCI for common E-DCH operation. NBAP & SIB5 CommonEdchEdpchInfo Ste

edchTfciTableIndex it specifies E-TFCI Table Index for common E-DCH operation.NBAP & SIB5CommonEdchEdpchI

nfoS

ergch2IndexStepThreshold it specifies E-RGCH 2-Index-Step Threshold for common E-DCH operation. NBAP & SIB5.CommonEdchEdpchI

nfoSte

ergch3IndexStepThreshold it specifies E-RGCH 3-Index-Step Threshold for common E-DCH operation. NBAP & SIB5.CommonEdchEdpchI

nfoSte

happyBitDelayThis parameter defines defines the delay to be used by the UE in its procedure to set the Happy Bit for

common E-DCH operation.

CommonEdchEdpchI

nfo

ms

50

5

•(*)Note: The default value is 4, however some simulation result recommend 5 (need field validation)


param identity Description object name range a



68


pa a de y esc p o objec a e a ge a

harqInfo This parameter definesHARQ Info for common E-DCH operation. NBAP & SIB5.CommonEdchEdpc

hInfo

Enu

rvt

minReducedEdpdchGainFactor

This parameter defines Minimum reduced E-DPDCH gain factor for common E-DCH operation. If the

configurable reduced E-DPDCH gain factor is not supported by the UE, the 3GPP default value of 8/15

is used.

CommonEdchEdpc

hInfo

Enum11_15

21_15

42_15

84

periodicityOfSchedInfoGrant

This parameter definesPeriodicity for Scheduling Info – grant for common E-DCH operation. IT is used

to define how often the UE should transmit the Sheduling Information (SI) on the E -DPDCH when the

UE is granted.

CommonEdchEdpc

hInfo

m

[Every

4, 10,

100, 2

10

periodicityOfSchedInfoNoGrant This parameter definesPeriodicity for Scheduling Info – no grant for common E-DCH operation.CommonEdchEdpc

hInfo

m

[Every

4, 10,

100, 210

plNonMax This parameter defines Puncture Limit for common E-DCH operation. NBAP & SIB5.CommonEdchEdpc

hInfo

Step 0

.

powerOffsetForSchedInfo This parameter defines E-DCH Power Offset for Scheduling Info. NBAP & SIB5.CommonEdchEdpc

hInfodB [

(*) “HARQ Info for E-DCH”, is used to indicate the use of redundancy version (RV) for the EDCH HARQ traindicates that the UE will only use E_DCH RV index 0 "rvtable" indicates that the UE will use an RSN basedspecified in 25.212.


•[RNC/RadioAccessService /DedicatedConf/0 EdchCellClass/0 CommonEdchSysInfo/TTI10ms CommonEdcR f Etf iC fLi t/



69


ReferenceEtfciConfList/

•referenceEtfci INTEGER (0..127)

•referenceEtfciPowerOffset INTEGER (0..29)

Table Name ReferenceEtfciConfList referenceEtfci referenceEtfciPowerOffset

10msTTI_Common EDCH0 3 10



FEATURE CONFIGURATION AND PARAMETERS (COMMON EDCH/FDPCH)




70


p y p j g

dlTpcStepSize it specifies FDD TPC DL Step Size for common E-DCH transmission. CommonEdchFdpchInfoEnum

fdpchTpcErrorRateTarget it specifies F-DPCH TPC command error rate target. SIB5. CommonEdchFdpchInfo % [1

initialDlPower it specifies Initial power on F-DPCH. CommonEdchFdpchInfo dB [-3

maxDlPower it specifies Maximum allowed power on F-DPCH. CommonEdchFdpchInfo dB [-3

minDlPower This parameter defines the Minimum allowed power on F-DPCH CommonEdchFdpchInfo dB [-3

•This parameters refer to F-DPCH DL Power. As referred before F-DPCH is used as a consequence of eFA

does not need the activation of the F-DPCH flag, which is thus reserved only for the CellDCH usage.

FEATURE CONFIGURATION AND PARAMETERS (COMMON EDCH HSDPCCH)


u



71


u

ackNackRepetitionFactorThis parameter defines the ACK-NACK Repetition Factor for common E-DCH HS-DPCCH

operation (ACK/CQI feedback).NBAP & SIB5CommonEdchHsdpcchInfo Enum

ackPowerOffsetit specifies ACK Power Offset for common E-DCH HS-DPCCH operation (ACK/CQI feedback).

NBAP & SIB5CommonEdchHsdpcchInfo Enum

cqiFeedbackCycleK This parameter defines the CQI Feedback Cycle k for common E-DCH HS-DPCCH operation(ACK/CQI feedback). NBAP & SIB5

CommonEdchHsdpcchInfo

ms [0

10, 20160,

cqiPowerOffset

This parameter defines the CQI Power Offset for common E-DCH HS-DPCCH operation, which

menas it indicates the power offset used in the UL between the HS-DPCCH slots carrying CQIinformation and the associated DPCCH (ACK/CQI feedback)..NBAP & SIB5

CommonEdchHsdpcchInfo Enum

cqiRepetitionFactorThis parameter defines the CQI Repetition Factor for common E-DCH HS-DPCCH operation.

NBAP & SIB5CommonEdchHsdpcchInfo Enum

measurementPowerOffsetThis parameter defines the Measurement Power Offset for common E-DCH HS-DPCCH

operation (ACK/CQI feedback). NBAP & SIB5CommonEdchHsdpcchInfo dB [

nackPowerOffset This parameter defines the NACK Power Offset for common E-DCH HS-DPCCH operation(ACK/CQI feedback). NBAP & SIB5

CommonEdchHsdpcchInfo Enum

•These parameters are specific for the ul feedback of CQI and HARQ Ack operation

FEATURE CONFIGURATION AND PARAMETERS (COMMON EDCH INFO 1/2)


E



72


additionalEdchTxBackoff This parameter defines the specifies additional E-DCH transmission back off. SIB5 CommonEdchInfo T

edchTxContinuationBackoffThis parameter defines the E-DCH transmission continuation back off. In terms of TTIs. If set to infinity,

implicit common E-DCH resource release is disabled. SIB5CommonEdchInfo

E

D

[

1680

maxCcchResourceAllocationThis parameter defines the Maximum E-DCH resource allocation for CCCH. In terms of TTI. NBAP &

SIB5.CommonEdchInfo

E

TT16

32

maxPeriodForCollisionResolution

This parameter defines the maximum period for collision resolution phase, where a common E-DCH

resource can be used before collision resolution (i.e. if no E-AGCH with UE’s E-RNTI has been receivedwithin this maximum period, then the UE would have to back off and try again. This value should be set

high enough to allow a robust transmission of UE initial MAC - is PDUs towards the network in case of

HARQ retransmission. In terms of TTIs. NBAP & SIB5

CommonEdchInfoET

maxTbSizeCellEdgeUsers

This parameter defines the maximum Transport Block size to be used for UEs at cell edge to optimise

performance. It may be used by the sheduler in order to minimize the cell edge interference for cell edge

users (and other users). NBAP.

CommonEdchInfob

maxTbSizeOtherUsersThis parameter defines themaximum Transport Block size to be used for UEs at cell edge to optimiseperformance. It may be used by the sheduler in order to minimize the cell edge interference for cell edge

users (and other users).

CommonEdchInfob

Note: The additionalEdchTxBackoff value 5 for 10ms TTI gives sufficient time for NodeB to achieve UL

ready for receiving UE UL data, that is, (5+1) x 10ms = 60ms. If operator regards 60ms is not enough, mslightly increased to e.g. 6 or 7 if necessary, but any value less than 4 is not recommended for 10ms TTI.

There’s a possibility to reduce this value from 5 to 4. Need ST and/or field validation

The Value Defined for this parameter can be set according to traffic estimations and to the forecast of penpercentage of UE’s supporting common EDCH

FEATURE CONFIGURATION AND PARAMETERS (COMMON EDCH INFO 2/2)


This parameter defines the actual number of common E DCH resources that is configured in a given cell En



73


numberOfCommonEdchResourcesThis parameter defines the actual number of common E-DCH resources that is configured in a given cell.

NBAP & SIB5.CommonEdchInfo

En

powerCtrlAlgo This parameter specifies algorithm to be used by UE to interpret TPC commands. SIB5 CommonEdchInfo

ulSirTarget This parameter defines the Uplink SIR Target for common E-DCH transmission (Ul Dpch). NBAP. CommonEdchInfodB

ulTpcStepSizeThis parameter specifies the TPC step size. The IE is mandatory present if the IE Power Control

Algorithm (powerCtrlAlgo) is set to algorithm 1, otherwise the IE is not needed. SIB5CommonEdchInfo d

The Value Defined for numberOfCommonEdchResources can be set according to traffic estimations an

penetration percentage of UE’s supporting common EDCH (see example before the paramters tables on th

Knowing that for Cell DCH we have S1, S2, S3 set to 1.07, 1.25, 1.85 respectively as Transmission targets

Thus the Common EDCH SIR target should take the SirTarget_CellDCH + ~1 (4.5 dB +1 = 5.5 dB). This isvalue assuming CommonEDCH will reduce overall noise by nature, as per simulation.

FEATURE CONFIGURATION AND PARAMETERS (COMMON EDCH MAC-D FLOW)




74


edchHarqMaxRetransit specifies Maximum Number Of Retransmissions For a given E-DCH MAC-d flow (up to 8).

NBAP & SIB5.CommonEdchMacdFlow Enum

edchMacdPowerOffset it specifies E-DCH HARQ power offset for a given E-DCH MAC-d flow (up to 8). NBAP & SIB5. CommonEdchMacdFlow Enum

spi

it specifies Scheduling Priority Indicator for a given E-DCH MAC-d flow (up to 8, that is, 8 is

3GPP maximum allowed limit, but in our design, we will define and use only 7 out of 8 commonE-DCH MAC-d flows).

CommonEdchMacdFlow Enum

•The parameters are assigned per different classes

edchHarqMaxRetrans

edchMacdPowerOf fset

SPI

eFACH UL CCCH 2 3 15

eFACH UL PS BKG 3 0 10

eFACH UL PS I Gold 3 0 13

eFACH UL PS I Silver 3 0 12

eFACH UL PS I Bronze 3 0 11

eFACH UL PS SRB 2 3 15

FEATURE CONFIGURATION AND PARAMETERS (RBSETCONF AND ULUSERSERVICES) 1

param identity Description object namerange

un



75


dlUserServiceId

Identifier of the associated dlUserService DL Access Stratum Configuration Id other name:

dlAsConfId.Notice the dlUserServiceId and UlUserServiceId must be coherent for the same

Establishement Cause. So it is recommended to reduce as much as possible the time between the

modification of dlUserServiceId and UlUserServiceId. Between the desynchronisation of

dlUserServiceId and UlUserServiceId calls may fail. SmartActivation Feature is recommended in this

case as it allows to make simultaneous changes.

UserServicesECellF

ach

Enum [SR13.6k

Cell_DCH

3.4k Cell_

SRB

Cell_FAC


Specify the behavior of each Radio Bearer when the always-on downsize is triggered, in the same way

as defined by the existing AlwaysOnAllowed parameter. The difference is this policy is applicable only

to R8+ E-FACH capable UE when E-FACH is enabled in the serving cell.

DlRbSetConf

Enum [dis

degradedysOnonlyreleaseO


Specify the behavior of each Radio Bearer when the always on downsize is triggered, in the same way

as defined by the existing AlwaysOnAllowed parameter. The difference is this policy is applicable only

to R8+ E-FACH capable UE when E-FACH is enabled in the serving cell. If FALSE, then the nominalbehavior would apply: transition from E-FACH UL to CELL_DCH with 2ms TTI E-DCH is allowed. Note

however that the E-DCH TTI may still be restricted by other feature/trigger.

UlRbSetConf

Enum [dis

degraded

ysOnonlyreleaseO

ulUserServiceId

Identifier of the related UlUserService. UL Access Startum Configuration Id other name: ulAsConfId.Notice the dlUserServiceId and UlUserServiceId must be coherent for the same Establishement

Cause. So it is recommended to reduce as much as possible the time between the modification of

dlUserServiceId and UlUserServiceId. Between the desynchronisation of dlUserServiceId and

UlUserServiceId calls may fail. SmartActivation Feature is recommended in this case as it allows to

make simultaneous changes.

UserServicesECellF

ach

Enum [SR

13.6kCell_DCH

3.4k Cell_

SRB

Cell_FAC

The parameters define the EFACH Call establishment UserService ID’s, the proposed values are conservatmostly to CEllDCH, however this depends highy on customer strategy.

The EFACH Call establishment UserService ID’s, depend on the User Equipment capabilities and on eFACHavailability on the cell

FEATURE CONFIGURATION AND PARAMETERS (RBSETCONF AND ULUSERSERVICES) 2

Establishment causes DLUserServiceid ULUserServiceid

Callreestablishment SRB 13.6K CellDCH SRB 13.6K CellDCH



76


Detach SRB Cell_FACH SRB Cell_FACH

EmergencyCall SRB 13.6K CellDCH SRB 13.6K CellDCH

InterRATCellChangeOrder SRB 13.6K CellDCH SRB 13.6K CellDCH

InterRATCellReselection SRB 13.6K CellDCH SRB 13.6K CellDCH

OriginatingBackground SRB 13.6K CellDCH SRB 13.6K CellDCH

OriginatingConversational SRB 13.6K CellDCH SRB 13.6K CellDCH

OriginatingHighPrioritySig SRB 13.6K CellDCH SRB 13.6K CellDCH

OriginatingInteractive SRB 13.6K CellDCH SRB 13.6K CellDCH

OriginatingLowPrioritySig SRB 13.6K CellDCH SRB 13.6K CellDCH

OriginatingStreaming SRB 13.6K CellDCH SRB 13.6K CellDCH

OriginatingSubscribedTraffic SRB 13.6K CellDCH SRB 13.6K CellDCH

Registration SRB 13.6K CellDCH SRB 13.6K CellDCH

Reserved1 to Reserved12 SRB 3.4K CellDCH SRB 3.4K CellDCH

TerminatingBackground SRB 13.6K CellDCH SRB 13.6K CellDCH TerminatingConversational SRB 13.6K CellDCH SRB 13.6K CellDCH

TerminatingHighPrioritySig SRB 13.6K CellDCH SRB 13.6K CellDCH

TerminatingInteractive SRB 13.6K CellDCH SRB 13.6K CellDCH

TerminatingLowPrioritySig SRB 13.6K CellDCH SRB 13.6K CellDCH

TerminatingStreaming SRB 13.6K CellDCH SRB 13.6K CellDCH

Terminatingcauseunknown SRB 13.6K CellDCH SRB 13.6K CellDCH

FEATURE CONFIGURATION AND PARAMETERS (MISC 1/2)


u



77


cqiThresholdForCellEdgeECellF

ach

This parameter is used for the identification of cell edge eFACH users in order to assign

appropriate a maximum transport block size to be used. If the reported Channel Quality

Indicator (CQI) is below this threshold, the user is assumed to be in cell edge

EdchConfInte

30] s

isEaiAllowed A cell-level activation flag for activate the interference based on SIB 5 UL Interference forCommon E-DCH

FDDCell Bo

powerOffsetPpeit specifies, in dB, Power offset between the last transmitted preamble and the initial DPCCH

transmission in the Enhanced Uplink in CELL_FACH state and Idle mode.

CommonEdchPreambleCtrlIn

fo dB [

transportQosIdThis parameter indicates the transport QoS that shall be used for the radio bearer set

configuration on Iub interface.EdchCommonMacFlow

Enu

[0

cqiValidityTimerTtiThis parameter defines the validity period in unit of 2msTTI the last CQI reported by a Rel8

eRACH-capable UE can be used by NodeB before falling back to the default CQI value.HsdpaConf

sub

(2m

1

eFachSeThresholdOneHsPdsch

CodeFallback

If the spectral efficency is less than this threshold, the number of available HSPDSCH codes

shall be set to 1 as input to Mac-ehs Transport Format Resource Combination (TFRC) Look-up

Table (LUT). The special value 0 would disable this SE threshold checking.

HsdpaConfbits/c

[0 .

maxNumberOfEnhancedCellFac

hUsersPerCell

It is to CAC Rel8 onwards eFACH users per cell. It specifies the maximum number of Rel8

onwards enhanced CELL_FACH users per cell allowed.CacOnFachParam

Inte

1

EdchCommonMacFlow Transport QOS idqaal2EquivalentSssarSduLength

fpEquivalentBitRate fpMaxBitRate

TRB_UL_COMMON_MAC_FLOW 2 2585 192384 2048000

SRB_UL_COMMON_MAC_FLOW 0 77 118400 2048000

FEATURE CONFIGURATION AND PARAMETERS (MISC 2/2)


u



78


minBRDefine the slow-start minimum bit rate per SPI level. When multiple SPIs are mapped to the

same common transport, its sum will define the minBR.CommonPriorityQueue

Kbit

2

mMax

This parameter indicates the Maximum number of preamble ramping cycles for L2 eRACH

procedure. If the number of preamble ramping cycles exceeds Mmax, failure of eRACHtransmission is reported to higher layer (UE side) TS25.321.

ERachTxParametersInte

32]

nb01Max

Set upper bound for eRACH transmission random-backoff (as per TS 25.321 Nbo1max)In case

that a negative acknowledgement has been received on AICH, a backoff timer TBO1 is started.Backoff timer TBO1 is set to an integer number NBO1 of 10 ms time intervals, randomly drawnwithin an interval 0<NBO1min< NBO1< NBO1max (with uniform distribution)

ERachTxParameters Integ.. 50

nb01Min

Set lower bound for eRACH transmission random-backoff (as per TS 25.321 Nbo1min). In case

that a negative acknowledgement has been received on AICH, a backoff timer TBO1 is started.Backoff timer TBO1 is set to an integer number NBO1 of 10 ms time intervals, randomly drawn

within an interval 0<NBO1min< NBO1< NBO1max (with uniform distribution)

ERachTxParametersInteg

.. 50

targetMacCQueueDelayDefine the target buffering time inside the MAC-c queue for the common HS-DSCH scheduler.

Used by creditAllocationAlgo 2CommonPriorityQueue ms [




79


1. 5 | FEATURE MONITORING

108103 - FEATURE MONITORING – NEW COUNTERS STATE TRANSITION Counterid Counter Screenings Description

#947: VS_RrcAvgNbrEnhCellFachRnc_From

CellFach Avg, cum, max , min, Nbeve

Average number of UEs in Enhanced CELL_FACH RRC stateScreening : From Cell_FACH E-FACH lower than-greater than FACH mobility)Trigger : Various reasons that cause acontext to enter or leave the Enhanced CELL FACH RRC state



80


CellFach context to enter or leave the Enhanced CELL_FACH RRC state

#946: VS_RrcAvgNbrEnh

CellFach_Avg Avg, cum, max , min, Nbeve

Average number of calls in RRC state Enhanced Cell_FachTrigger : Various reasons thaan RRC context to enter or leave the Enhanced

#898: VS_RrcAvgNbrEnh

CellFachUl Avg, cum, max , min, Nbeve

Average number of UEs in Rel-8 Enhanced CELL_FACH RRC state per cellTrigger : reasons (e.g. due to pre-defined downsize/upsize triggers, UE transits between CELLstate and other RRC states) that cause an RRC context to enter or leave the Rel8 En

Cell_Fach

#899_0..4 VS_RrcAvgNbrEnhCellFachUlRnc_Fro

mCellPch

Avg, cum, max , min, Nbeveand for (FromCellDch,

FromCellPch, FromUraPch,From Idle, FromCellFACh

Average number of UEs in Rel8 Enhanced CELL_FACH RRC state in RNCScreening : reasons (e.g. due to pre-defined downsize/upsize triggers, UE transits between CELLstate and other RRC states) that cause an RRC context to enter or leave the Rel8 EnCELL_FACH RRC state.

#1333 VS_UEStateTrans Att_CellDCH_PCH

_ERACHNA

Attempted UE Transitions from Cell_DCH to Cell_/URA_PCH State for UE that supports 'cE-DCH' from an eRACH cellTrigger : Pegged whenever a RB Reconfiguration RRC messtransmitted to the UE, attempting to transition a UE from Cell DCH to CELL_PCH or URRepeated RB Reconfiguration messages will be ignored. The counter will be pegged agaprimary cell of the SRNC that has eRACH activated when the UE is in Cell_DCH. The Usupport the capability 'common E-DCH'3GPP Counter : VS.UEStateTransAtt.CellDCH_PCH.

U1334 VS_UEStateTransSucc_CellDCH_PC

H_ERACHNA

Successful transitions from CellDCH to Cell/URA PCH State in E-RACH cellTrigger : Pwhenever a RB Reconfiguration Complete message is received on the RNC, indicasuccessful state transition from Cell_DCH to Cell / URA_PCH. Pegged on the same cell / Rthe related attempt counter VS.UEStateTransAtt.CellDCH_PCH.ERACH The counter pegged against the best cell of the SRNC, the UE was in Cell_DCH (sam VS.UEStateTransAtt.CellDCH_PCH.ERACH was pegged). The UE must support the ca'common E-DCH' and the cell has eRACH activated3GPP Count VS.UEStateTransSucc.CellDCH_PCH.ERACH

108103 - FEATURE MONITORING – NEW COUNTERS STATE TRANSITION Counterid Counter Description

U1335_0 VS_UEStateTransAtt_Direct_PCH

_CellDCH_ERACH_Tvi

Attempted UE Transitions from any PCH to CellDCH for UE supporting 'common E-DCH' in E-RACH cellScreening : Based on TVITrigg

Pegged on reception of a Cell Update message from a UE in URA_PCH or CELL_PCH resulting in a direct transition to CELL_D(without going through CELL_FACH) based on the TVI or/and Establishment Cause supported for direct transition which is includedthe Cell Update message. Retransmissions of the Cell Update message shall not cause this PM to be incremented when part of tsame procedure. Pegged on the FDDcell MO representing the cell in which the first cell update message is received. The UE msupport the capability 'common E DCH' and the cell has eRACH activated3GPP Counter



81


support the capability common E-DCH and the cell has eRACH activated3GPP Counter VS.UEStateTransAtt.Direct.PCH.CellDCH.ERACH.Tvi

U1335_1 VS_UEStateTransAtt_Direct_PCH

_CellDCH_ERACH_EstCause

Attempted UE Transitions from any PCH to CellDCH for UE supporting 'common E-DCH' in E-RACH cellScreening : Based Establishment CauseTrigger : Pegged on reception of a Cell Update message from a UE in URA_PCH or CELL_PCH resulting in a dirtransition to CELL_DCH (without going through CELL_FACH) based on the TVI or/and Establishment Cause supported for diretransition which is included in the Cell Update message. Retransmissions of the Cell Update message shall not cause this PM to incremented when part of the same procedure. Pegged on the FDDcell MO representing the cell in which the first cell update messais received. The UE must support the capability 'common E-DCH' and the cell has eRACH activated3GPP CounteVS.UEStateTransAtt.Direct.PCH.CellDCH.ERACH.EstCause

U1336_0 VS_UEStateTransSucc_Direct_PC

H_CellDCH_ERACH_Tvi

Successful UE transitions from URA_PCH or CELL_PCH directly to CELL_DCH (without going through CELL_FACH) in E-RAcellScreening : Based on TVITrigger : Pegged on reception of a RB Reconfiguration Complete indicating a successful UE State diretransition from URA_PCH or CELL_PCH to CELL_DCH (without going through CELL_FACH) based on the TVI or/and Establishment Caincluded in the Cell Update message. To be pegged on the same cell as the related attempt was pegged wVS.UEStateTransAtt.Direct.PCH.CellDCH. The UE must support the capability 'common E-DCH' and the cell has eRACH activated3GCounter : VS.UEStateTransSucc.Direct.PCH.CellDCH.ERACH.Tvi

U1336_1 VS_UEStateTransSucc_Direct_PC

H_CellDCH_ERACH_EstCause

Successful UE transitions from URA_PCH or CELL_PCH directly to CELL_DCH (without going through CELL_FACH) in E-RAcellScreening : Based on Establishment CauseTrigger : Pegged on reception of a RB Reconfiguration Complete indicating a succesUE State direct transition from URA_PCH or CELL_PCH to CELL_DCH (without going through CELL_FACH) based on the TVI or/aEstablishment Cause included in the Cell Update message. To be pegged on the same cell as the related attempt was pegged wVS.UEStateTransAtt.Direct.PCH.CellDCH. The UE must support the capability 'common E-DCH' and the cell has eRACH activated3GCounter : VS.UEStateTransSucc.Direct.PCH.CellDCH.ERACH.EstCause

U1337 VS_UEStateTransAtt_CellDCH_ER

ACH

Attempted UE transitions from CellDCH to Enhanced Cell_FACH UL StateTrigger : This counter should be pegged whenever the Rattempts to transition the UE from any CELL_DCH state to CELL_FACH state, as a result of a Radio Bearer Reconfiguration messagea Radio Bearer Release message with the RRC State Indicator set to CELL_FACH. Repeated RB reconfiguration message or RB relemessage for the same procedure shall not be counted. The UE must support the capability 'common E-DCH' and the cell has eRA

activated3GPP Counter : VS.UEStateTransAtt.CellDCH_ERACH

U1338 VS_UEStateTransSucc_CellDCH_

ERACH

Successful UE transitions from CellDCH to Rel-8 Enhanced Cell_FACH StateTrigger : This counter should be pegged when the Rreceives NBAP Radio Link Deletion Response and the RRC state is changed from any CELL_DCH to CELL_FACH. The counter willpegged against the primary cell of the SRNC when the UE was in Cell_DCH (same cell VS.UEStateTransAtt.CellDCH.ERACH was peggThe UE must support the capability 'common E-DCH' and the cell has eRACH activated3GPP Counter VS.UEStateTransSucc.CellDCH_ERACH


ll

Attempted UE transitions from Enhanced Cell_FACH UL State to CELL_DCH stateScreening : UL DCH a

Whenever the UE successfully or unsuccessfully transitions from Cell_FACH to Cell_DCH meeting either of the

When the RB Reconfiguration / Setup Complete RRC message in Cell_DCH is received by the RNC. In wincremented for the cell in which the last RRC Reconfiguration Message was sent to the UE. 2) When the UE

an RB Reconfiguration / Setup Complete RRC message in Cell DCH and the RNC is to send an Iu Release. In w



82


U1339_0 VS_UEStateTransAtt_ERACH_CellDCH

_DCH_DCH

an RB Reconfiguration / Setup Complete RRC message in Cell_DCH and the RNC is to send an Iu Release. In w

incremented at the time which the RNC decides to abort the transition. The PM is incremented for the cell

Reconfiguration Message was sent to the UE. 3) When resources are not available for the transition an

Cell_FACH state. In which case the performance counter is incremented at the time which the RNC decides toto Cell_DCH. The PM is incremented for the Cell in which the UE was in Cell_FACH prior to abortion of the R

Setup to Cell DCH. The UE must support the capability 'common E-DCH' and the source cell has eRACH acti

VS.UEStateTransAtt.ERACH_CellDCH.DCH_DCH


_DCH_HSDSCH

Attempted UE transitions from Enhanced Cell_FACH UL State to CELL_DCH stateScreening : UL DCH and


When the RB Reconfiguration / Setup Complete RRC message in Cell_DCH is received by the RNC. In wincremented for the cell in which the last RRC Reconfiguration Message was sent to the UE. 2) When the UE

an RB Reconfiguration / Setup Complete RRC message in Cell_DCH and the RNC is to send an Iu Release. In w



Cell_FACH state. In which case the performance counter is incremented at the time which the RNC decides to

to Cell_DCH. The PM is incremented for the Cell in which the UE was in Cell_FACH prior to abortion of the RSetup to Cell DCH. The UE must support the capability 'common E-DCH' and the source cell has eRACH acti

VS.UEStateTransAtt.ERACH_CellDCH.DCH_HSDSCH


_EDCH_HSDSCH

Attempted UE transitions from Enhanced Cell_FACH UL State to CELL_DCH stateScreening : UL EDCH and


When the RB Reconfiguration / Setup Complete RRC message in Cell_DCH is received by the RNC. In w

incremented for the cell in which the last RRC Reconfiguration Message was sent to the UE. 2) When the UEan RB Reconfiguration / Setup Complete RRC message in Cell_DCH and the RNC is to send an Iu Release. In w



Cell_FACH state. In which case the performance counter is incremented at the time which the RNC decides to

to Cell_DCH. The PM is incremented for the Cell in which the UE was in Cell_FACH prior to abortion of the R

Setup to Cell DCH. The UE must support the capability 'common E-DCH' and the source cell has eRACH actiVS.UEStateTransAtt.ERACH_CellDCH.EDCH_HSDSCH

U1344 VS_UEStateTransSucc_PCH_ERACH

Successful UE transitions from any PCH to Rel-8 Enhanced Cell_FACH StateTrigger : Pegged - whenever in tra

PCH or Cell_PCH to Cell FACH - a UTRAN Mobility Information Confirm message is received from the UE i

Update Confirm message. Pegged against the cell, the UTRAN Mobility Information Confirm was received. T

the capability 'common E-DCH' and the cell has eRACH activated3GPP Counter : VS.UEStateTransSucc.PCH.ERA


U1340_0 VS_UEStateTransSucc_ERACH_CellD

CH_DCH_DCH

Successful UE transitions from Rel-8 Enhanced Cell_FACH to CellDCH StateScreening : UL DCH and DL D

whenever the RB Reconfiguration / Setup Complete RRC message in Cell_DCH is received by the RNC in

successfully transitions from Cell_FACH to Cell_DCH. The PM is incremented for the cell in which the last R

Setup Message was sent to the UE. The UE must support the capability 'common E-DCH' and the cell has e



83


Counter : VS.UEStateTransSucc.ERACH_CellDCH.DCH_DCH


CH_DCH_HSDSCH

Successful UE transitions from Rel-8 Enhanced Cell_FACH to CellDCH StateScreening : UL DCH and DL HSDS


successfully transitions from Cell_FACH to Cell_DCH. The PM is incremented for the cell in which the last RSetup Message was sent to the UE. The UE must support the capability 'common E-DCH' and the cell has e

Counter : VS.UEStateTransSucc.ERACH_CellDCH.DCH_HSDSCH


CH_EDCH_HSDSCH

Successful UE transitions from Rel-8 Enhanced Cell_FACH to CellDCH StateScreening : UL EDCH and DL HSDS


successfully transitions from Cell_FACH to Cell_DCH. The PM is incremented for the cell in which the last R

Setup Message was sent to the UE. The UE must support the capability 'common E-DCH' and the cell has e

Counter : VS.UEStateTransSucc.ERACH_CellDCH.EDCH_HSDSCH

U1341 VS_UEStateTransAtt_ERACH_PCH

Attempted UE transitions from Enhanced Cell_FACH UL to Cell/URA PCH StateTrigger : Pegged whenever th

unsuccessfully transitions from Cell FACH UL to Cell_ or URA PCH. 1) When the Reconfiguration Complete

FACH is received by the RNC. The PM is incremented for the cell in which the last RRC Reconfiguration Mes

UE. 2) When the UE fails to respond with an Reconfiguration Complete RRC message in Cell FACH and the

Release. In which case the PM is incremented at the time which the RNC decides to abort the transition. Thfor the cell in which the last RRC Reconfiguration Message was sent to the UE. 3) When a RRC Radio Bea

Failure message in Cell FACH is received by the RNC. The PM is incremented for the cell in which the last

Message was sent to the UE. 4) Other internal failures. The PM is incremented for the cell in which the last

Message was sent to the UE or if the failure occurs prior to transmission of the RRC Reconfiguration

incremented for the cell in which the UE was in Cell_FACH. Note: Pegged once per procedure attempt. Any rRadio Bearer Reconfiguration message will not peg this counter The UE must support the capability 'commonhas eRACH activated3GPP Counter : VS.UEStateTransAtt.ERACH_PCH

108103 - FEATURE MONITORING – NEW COUNTERS STATE TRANSITION

Counterid Counter Description

U1342 VS_UEStateTransSucc_ERACH_PCH

Successful UE transitions from Rel-8 Enhanced Cell_FACH to Cell/URA PCH StateTrigger : Pegged whenev

Reconfiguration Complete message in Cell FACH is received by the RNC indicating the successful UE transi

FACH to Cell_ or URA_PCH. The PM is incremented for the cell in which the last RRC RB Reconfiguration Messa



84


_ _ _ _ _ g

the UE. The UE must support the capability 'common E-DCH' and the cell has eRACH activated3G

VS.UEStateTransSucc.ERACH_PCH

U1343 VS_UEStateTransAtt_PCH_ERACH

Attempted UE transitions from PCH to Rel-8 Enhanced Cell_FACH StateTrigger : Whenever 'Cell Update' messa

URA_PCH or Cell_PCH is received causing the RNC to transition the UE to Cell FACH, the counter shall be

Retransmissions of the Cell Update message shall not cause this counter to be incremented, when part

procedure. Pegged against the cell, the last (in case of retransmission) 'Cell Update' message is received.support the capability 'common E-DCH' and the cell has eRACH activated3GPP Counter : VS.UEStateTransAtt.PC

U1344 VS_UEStateTransSucc_PCH_ERACH

Successful UE transitions from any PCH to Rel-8 Enhanced Cell_FACH StateTrigger : Pegged - whenever in tran

URA PCH or Cell_PCH to Cell FACH - a UTRAN Mobility Information Confirm message is received from the UE iCell Update Confirm message. Pegged against the cell, the UTRAN Mobility Information Confirm was received

support the capability 'common E-DCH' and the cell has eRACH activated3GPP Counter : VS.UEStateTransSucc.P

108103 - FEATURE MONITORING – NEW COUNTERS IU RELEASE




85


U1330_0

VS_IuAbnormalReleaseRequestPs

EfachMixity_MobilityDuringAO

Counts the number of Iu Connection Release triggered due to eFACH mobility mixityScreening : Mobility d

AOTrigger : A mobility between cells with different eFACH capabilty that is triggered during an on-going proc

in eFACH state, which then results in Iu Connection Release3GPP Counter

VS.IuAbnormalReleaseRequestPsEfachMixity.MobilityDuringAO

U1330_1


EfachMixity_MobilityDuringMobility


mobilityTrigger : A mobility between cells with different eFACH capabilty that is triggered during an on-

procedure in eFACH state, which then results in Iu Connection Release3GPP Count

VS.IuAbnormalReleaseRequestPsEfachMixity.MobilityDuringMobility

U1330_2


EfachMixity_MobilityDuringRRE


RRETrigger : A mobility between cells with different eFACH capabilty that is triggered during an on-going proc

in eFACH state, which then results in Iu Connection Release3GPP Counter

VS.IuAbnormalReleaseRequestPsEfachMixity.MobilityDuringRRE

U1330_3


EfachMixity_Others

Counts the number of Iu Connection Release triggered due to eFACH mobility mixityScreening : OthersTriggmobility between cells with different eFACH capabilty that is triggered during an on-going procedure in e

state, which then results in Iu Connection Release3GPP Counter

VS.IuAbnormalReleaseRequestPsEfachMixity.Others

108103 - FEATURE MONITORING – NEW COUNTERS RRC CON REQUEST

Counterid Counter Screenings Description



86


U1331

VS_FirstRrcConnectio

nRequestERach_OrigConvCall

All RRC

establishment

causes

Counts the number of first RRC connection requests for a given UE with cap

of common E-DCH' from a cell that has eRACH activatedScreening : Re

RRC_CONNECTION_REQUEST in a TMU for a given UE with capability 'Suppor

DCH' from a cell that has eRACH activated

U1332_0

RRC_SuccConnEstabE

Rach_OrigConvCall

All RRC

establishment

causes

Number of rrc connection successful from an UE thas has the capability 'Sup

E-DCH' on a cell that has eRACH activatedScreening : Correct

RRC_CONNECTION_SETUP_COMPLETE from an UE thas has the capabil

common E-DCH' on a cell that has eRACH activated

108103 - FEATURE MONITORING – NEW COUNTERS USER PLANE COMMON


Number of bytes in SDUs received by the MAC layer for a DCCH over HS-DSCH in Enhanced CELL_FACH stat



87


U1226

VS_CommonMacDownlinkDcchOverHs

dschFachSduInBytes

directionTrigger : Receipt of SDU at MAC layer for downlink DCCH over HS-DSCH in Enhanced CELL_FACH staVS.CommonMacDownlinkDcchOverHsdschFachSduInBytes

U1227

VS_CommonMacDownlinkDtchOverHs

dschFachSduInBytes

Number of bytes in SDUs received by the MAC layer for a DTCH over HS-DSCH in Enhanced CELL_FACH stat

directionTrigger : Receipt of SDU at MAC layer for downlink DTCH over HS-DSCH in Enhanced CELL_FACH sta

VS.CommonMacDownlinkDtchOverHsdschFachSduInBytes

U1228

VS_CommonMacDownlinkCcchOverHs

dschFachSduInBytes

Number of bytes in SDUs received by the MAC layer for a CCCH over HS-DSCHTrigger : Receipt of SDU at MAC

CCCH over HS-DSCH3GPP Counter : VS.CommonMacDownlinkCcchOverHsdschFachSduInBytes

U1229

VS_CommonMacUplinkCcchOverEdch

FachSduInBytes

Number of bytes in SDUs received by the MAC layer for a CCCH over E-DCHTrigger : Receipt of SDU at MAC laye

over E-DCH3GPP Counter : VS.CommonMacUplinkCcchOverEdchFachSduInBytes

U1230

VS_CommonMacUplinkDcchOverEdch

FachSduInBytes

Number of bytes in SDUs received by the MAC layer for a DCCH over common E-DCH in Rel8 Enhanced CELL_

uplink directionTrigger : Receipt of SDU at MAC layer for uplink DCCH over common E-DCH in Rel8 Enhanced CEL

Counter : VS.CommonMacUplinkDcchOverEdchFachSduInBytes

U1231

VS_CommonMacUplinkDtchOverEdch

FachSduInBytes

Number of bytes in SDUs received by the MAC layer for a DTCH over common E-DCH in Rel8 Enhanced CELL_

uplink directionTrigger : Receipt of SDU at MAC layer for uplink DTCH over common E-DCH in Rel8 Enhanced CEL

Counter : VS.CommonMacUplinkDtchOverEdchFachSduInBytes

U1232_0

VS_CommonHsdpaIubDlControlFrame

s_CommonSrb

Counts the total number of downlink control frames sent to NodeB on common HS-DSCH in Enhanced Cell_Fach sa control frame to NodeB (i.e., Capacity Request Frame)Screening : Common SRBTrigger : Capacity Request to N

: VS.CommonHsdpaIubDlControlFrames.CommonSrb

U1232_1

VS_CommonHsdpaIubDlControlFrame

s_CommonPsIB

Counts the total number of downlink control frames sent to NodeB on common HS-DSCH in Enhanced Cell_Fach s

a control frame to NodeB (i.e., Capacity Request Frame)Screening : Common PS I/BTrigger : Capacity Requ

Counter : VS.CommonHsdpaIubDlControlFrames.CommonPsIB

108103 - FEATURE MONITORING – NEW COUNTERS USER PLANE COMMON


U1233 0

VS_CommonHsdpaIubNonZeroCap

it All C S b

Counts the total number of capacity allocation frames sent by NodeB with non-zero grant on comEnhanced Cell_Fach stateScreening : Common SRBTrigger : Non-Zero Grant Capacity Allocation by Node

VS C H d I bN Z C it All C S b



88


U1233_0 acityAlloc_CommonSrb VS.CommonHsdpaIubNonZeroCapacityAlloc.CommonSrb

U1233_1

VS_CommonHsdpaIubNonZeroCap

acityAlloc_CommonPsIB

Counts the total number of capacity allocation frames sent by NodeB with non-zero grant on com

Enhanced Cell_Fach stateScreening : Common PS I/BTrigger : Non-Zero Grant Capacity AllocationCounter : VS.CommonHsdpaIubNonZeroCapacityAlloc.CommonPsIB

U1234_0

VS_CommonHsdpaIubZeroCapacit

yAlloc_CommonSrb

Counts the total number of capacity allocation frames sent by NodeB with zero grant on common HS-DCell_Fach stateScreening : Common SRBTrigger : Zero Grant Capacity Allocation by NodeB3

VS.CommonHsdpaIubZeroCapacityAlloc.CommonSrb

U1234_1

VS_CommonHsdpaIubZeroCapacit

yAlloc_CommonPsIB

Counts the total number of capacity allocation frames sent by NodeB with zero grant on common HS-D

Cell_Fach stateScreening : Common PS I/BTrigger : Zero Grant Capacity Allocation by NodeBVS.CommonHsdpaIubZeroCapacityAlloc.CommonPsIB

U1235_0VS_CommonHsdpaIubCreditsRequ

ested_CommonSrb

Counts the total credits requested by the I-Node from NodeB in Kilo Bytes on common HS-DSCH in Enh

stateScreening : Common SRBTrigger : Credit Request for new data (i.e., not repeated request for

Counter : VS.CommonHsdpaIubCreditsRequested.CommonSrb

U1235_1

VS_CommonHsdpaIubCreditsRequ

ested_CommonPsIB

Counts the total credits requested by the I-Node from NodeB in Kilo Bytes on common HS-DSCH in EnhstateScreening : Common PS I/BTrigger : Credit Request for new data (i.e., not repeated request for

Counter : VS.CommonHsdpaIubCreditsRequested.CommonPsIB

U1236_0

VS_CommonHsdpaIubCreditsCons

umed_CommonSrb

Counts the total credits grants by NodeB in Kilo Bytes that are actually consumed by the I-Node on com

Enhanced Cell_Fach stateScreening : Common SRBTrigger : Credit Consumed by I-Node3

VS.CommonHsdpaIubCreditsConsumed.CommonSrb

U1236_1VS_CommonHsdpaIubCreditsCons

umed_CommonPsIB

Counts the total credits grants by NodeB in Kilo Bytes that are actually consumed by the I-Node on comEnhanced Cell_Fach stateScreening : Common PS I/BTrigger : Credit Consumed by I-Node3

VS.CommonHsdpaIubCreditsConsumed.CommonPsIB

108103 - FEATURE MONITORING – MODIFIED COUNTERS (SCREENINGS AD

#589: VS.IuAbnormalReleaseRequestPs DlAsCnfEnhCellFach

#936: VS.RrcAvgNbrCellFachRnc FromIdle ; FromCell_FACH

#934: VS RrcAvgNbrCellPch FromR7EFach FromR8ERach



89


#934: VS.RrcAvgNbrCellPch FromR7EFach FromR8ERach

#935: VS.RrcAvgNbrUraPch FromR7EFach FromR8ERach

#2808: VS.UEStateTransSucc.FACH _CellDCH.CsCallSetup FromR7EFach FromR8ERach

#2950: VS.UEStateTransAtt.FACH _CellDCH.CsCallSetup FromR7EFach FromR8ERach

#902: VS.NbrCellUpdateRejects EFachCacFailure & ERachCacFailure

#1652: VS.RadioBearerSetupRequest ; #1650: VS.RadioBearerSetupSuccess ; #1649:

VS.RbEstabUnsucPerDlRbType with screenings TgtCellPSEFachRach & TgtCellPSEFa

1666: VS.DlAsConfIdAvgNbrEstablished DlAsCnfPsEFach

#1667: VS.UlAsConfIdAvgNbrEstablished UlAsCnfPsERach

108103 - FEATURE MONITORING – NEW BTS COUNTERS

Counterid Counter Screenings Description

U10856_Avg

VS_HsdpaMACdPduBitsInBlin

d_Avg

Avg, cum, max , min,

NbeveNumber MAC-d/MAC-c PDU bits transmitted in blind mode (counter is incremented once in

retransmissions).Trigger : Each TTI (2ms)3GPP Counter : VS.HsdpaMACdPduBitsInBlind.Avg

VS H d MACdPd Bi I Bli P SPINumber of MAC-d/MAC-c bits transmitted in blind mode, per SPI (counter is incremented once

f i i ) S i F SPI 0T i U d d h TTI (2 ) 3G



90


U10857_0

VS_HsdpaMACdPduBitsInBlin

dPerSPI_SPI0

Per SPI of retransmissions).Screening : For SPI 0Trigger : Updated at each TTI (2ms).3G

VS.HsdpaMACdPduBitsInBlindPerSPI.SPI0

U10858_0

VS_HsdpaDroppedMACPdusF

orEDrxUEs_DroppedOnT1Expiry

NA

The total number of MAC PDUs which are dropped by the NodeB due to either discardTimer e

expiry for eDRX-capable Ues.Screening : Number of Dropped MAC PDU due to T1 timer

Whenever NodeB is triggered to drop MAC PDUs which are destined towards eDRX-capable UEs,of either discardTimer or timerT1.3GPP Counter : VS.HsdpaDroppedMACPdusForEDrxUEs.Droppe

U10858_1

VS_HsdpaDroppedMACPdusF

orEDrxUEs_DroppedOnDisca

rdTimer

NA

The total number of MAC PDUs which are dropped by the NodeB due to either discardTimer eexpiry for eDRX-capable Ues.Screening : Number of Dropped MAC PDU due to Discard Timer

Whenever NodeB is triggered to drop MAC PDUs which are destined towards eDRX-capable UEs,

of either discardTimer or timerT1.3GPP Cou

VS.HsdpaDroppedMACPdusForEDrxUEs.DroppedOnDiscardTimer

U11201_0

VS_commonEdchResourceUs

age_GrantReq

NA

Counts the number of eRACH requests received within a pre-configured investigation perioallocation of common E-DCH resourceScreening : Granted E-DCH resource allocation requestsTr

NodeB receives an eRACH access request (with reserved eRACH signature) from a Rel8 eRA

asking for the allocation of common E-DCH resource.3GPP Counter : VS.commonEdchResourceUs

U11201_1VS_commonEdchResourceUs

age_RejReq

NA

Counts the number of eRACH requests received within a pre-configured investigation perio

allocation of common E-DCH resourceScreening : Rejected E-DCH resource allocation re

Whenever NodeB receives an eRACH access request (with reserved eRACH signature) from

capable UE, asking for the allocation of common E-DCH resource.3GPPVS.commonEdchResourceUsage.RejReq

U11202

VS_commonEdchResidualTbI

nErrPerCell

NA

Counts the number of common EDCH Transport Blocks in error (across all common EDCH res

within a pre-configured investigation period.Trigger : NodeB should only start to count a resi

after the Collision Resolution phase. Whenever NodeB detects a HARQ failure at E-DPCCH dec

Counter : VS.commonEdchResidualTbInErrorPerCell

U11203

VS_commonEdchTotalTbRec

eivedPerCell

NA

Counts the total number of common EDCH Transport Blocks that are received by NodeB (ac

EDCH resources) per cell within a pre-configured investigation periodTrigger : NodeB shoureceived common EDCH TB after the Collision Resolution phase. If a received common EDCH

need HARQ retransmission, NodeB shall only count once for all transmissions associated with th

transmission and all retransmissions).3GPP Counter : VS.commonEdchTotalTbReceivedPerCell

108103 - FEATURE MONITORING – MODIFIED COUNTERS (SCREENINGS AD

Counter Name New Screening

#10902: eDCHdataBitSentToRNC and #10904: eDCHdataBitRec

New screenings:



91


New screenings:

•2ms_users_regular_edch

•10ms_users_regular_edch

•2ms_users_common_edch


•all_users_edch

#10903: eDCHretransBlocks, #10905: eDCHactiveUsers and #10925: edchNbOfUsersPerB

New screening






92


1.6 | RESTRICT IONS / OTHER ISSUES

108103 - FEATURE RESTRICTIONS 1/2

•In addition, given that eRACH and RACH share the single PRACH in the cell, when Class 3-A1 PRACH parameter chang

aichTransmissionTiming, RNC deletes and re-creates the RACH but not the eRACH. To ensure consistency, if eRACH is c

cell lock/unlock is required when changing the following parameters in RACH MO:



93


•a. preambleSignature

•b. prachScramblingCode

•c. preambleThreshold

•d. aichTransmissionTiming

•e. aichPowerRelativeToPcpich

•No mixity of eFACH DL only and eFACH DL/UL within the same UTRAN is allowed.

•The mixing of eFACH DL and eFACH UL configuration in the same RNC is not supported. Also addition, upon the lost of

eFACH UL cell is reconfigured to R99 CELL_FACH as opposed to eFACH DL only as one could expect.

•Maximum supported configuration

• 1 cell per eCEM with 24 Common EDCH Allocated

• 2 cells per eCEM with 12 Common EDCH Allocated per cell

•3 cells per eCEM with 8 Common EDCH Allocated per cell

108103 - FEATURE RESTRICTIONS 2/2

•No PS MUX supported in eFACH as it is the case already for legacy FACH

•Efach over Iur is not supported



94


•10ms E-RACH only (isEdchTti2msECellFachAllowedshould always set to FALSE)

•Only power control algo1 in E-RACH is supported (PCA1)

•isCommonEdchHsdpcchAllowed should always be set to TRUE

•creditAllocationAlgo only supports algo1; algo2 is not supported

•E-AGCH sending AG=”Inactive” is supported in error case handling only, to release resources the NodeB stops FDPCH t

“pseudo” explicit release

•The rachSubChannels used by the RNC are shared by both RACH and E-RACH.

•Counter 1330 VS.IuAbnormal.ReleaseRquestPSEfachMixity restriction (see details above)

•The flag isRlcReconfigurationECellFachAllowed has no effect. When both R7 and R8 UEs are deployed concurrently, th

of R7 UE may not be optimum

•The use of post-verification period during CELL_FACH to CELL_DCH transition is not supported (i.e. isFastL1SyncForEC

set to FALSE)

ENHANCED CELL_FACH



95


2 | PM121209 – ENHANCED UE DRX IN CELL_FACH

PM121109 – ENHANCED UE DRX IN CELL_FACH



96


1. 1 | INTRODUCT ION

FEATURE OVERVIEW AND BENEFITS

In 3GPP Rel.8 Enhanced UE DRX (support of HS-PDSCH DRX operation in Cell_FACH state) is introduced on top of Enhan

allow UE battery saving. Thanks to Enhanced Cell_FACH, the UE will stay in Cell_FACH state for much longer time than

efficient UE battery management is critical to Enhanced Cell_FACH successful operation.



97


The Enhanced UE DRX in Cell_FACH state feature enables:

• Discontinuous HSDPA (HS-SCCH / HS-DSCH) reception in Cell_FACH state.

• Freeing of FACH measurement occasions thanks to the fact that a UE will be able to make measurements in DRX cyc

Cell_FACH.

The main benefits of the feature are:

• Improvement of battery consumption in case of infrequent small packet data services for smartphone users staying

without the need for state transition.

• A much reduced signalling load due to much less frequent state transitions between Cell_FACH and URA/Cell_PCH.

This feature is under license in LR14.2.W, provided at RNC level.

CUSTOMER REQUIREMENTS AND SCENARIOS

Scenario 1

A user is using a PS I/B service in Cell_F

hil h b k d b l



98


while, the bursty packet data becomes le

triggers a pre-defined inactivity timer

operation. The UE enters discontinuous

downlink traffic and only “wakes up” in

data bursts (active reception w

Scenario 2

Due to infrequent bursty data service, a

enters the Enhanced DRX operation, After

a UL/DL burst makes the UE exit the Enha

and back to normal continuous reception

state.

Scenario 3

Due to infrequent bursty data service, a

enters the Enhanced DRX operation. Afte

inactivity event triggers the downsize tim

to URA_PCH or Cell_PCH s

Requirement 1

Provide support for Enhanced DRX operation inCell_FACH state (Rel.8).

Requirement 2

Provide a mean to keep Enhanced DRX capable UEs

for longer in Cell_FACH state.

Requirement 3

Provide a mean for the operator to configure DRX

cycles and bursts periods.




99


1.2 | FEATURE DESCRIPT ION

DISCONTINUOUS RECEPTION BACKGROUND (1/2) Enhanced UE DRX in Cell_FACH (also known as eDRX, HS-DSCH DRX in Cell_FACH, Cell_FACH HS-DSCH DRX operation) is

and is optional for UE to support.

The Cell_FACH HS-DSCH DRX operation determines the occasions in which the UE is allowed to discontinuously receive



100


_ p y

Cell_FACH state. Thus eDRX feature can help UE save battery life in Cell_FACH state, which is a desirable feature by th

Without eDRX, a UE in Cell_FACH continuously receives the HS-SCCH and associated HS-DSCH to detect data arrival, ex

Measurement Occasion frames, when it performs measurements. To further reduce UE battery consumption, especially

transmission becomes less frequent, two options of discontinuous reception can be enabled by the network as follows

• Downsizing the UE to URA_PCH or Cell_PCH, through a dedicated RRC reconfiguration message.

• Enabling DRX operation for the UE staying in Cell_FACH:

- The UTRAN configures key parameters like Inactivity Timer, DRX Cycle Length and RX Burst Length for such eD

- The UE will enter the eDRX operation if the Inactivity Timer expires. The trigger for the Inactivity Timer to st

DL/UL data transmission activities are ongoing. Upon the expiry of the Inactivity Timer , the UE only needs to r

the RX Bursty Length of the DRX Cycle Length time period configured and does not need to receive HSDPA for t

of each DRX Cycle configured.

- The UE will quit eDRX operation and restores continuous HSDPA reception whenever active data transmission o

detected.

- Cell_FACH HS-DSCH DRX operation is only allowed when the UE has allocated a valid dedicated H-RNTI.

DISCONTINUOUS RECEPTION BACKGROUND (2/2)

RX Burst RX Burst RX B



101


DRX Cycle Length E-DCH Resource Allocated Inactivity Time

Length Length Len

DRX Cycle Length DRX Cycle Lengt

When a eDRX capable UE is in Cell_FACH state in a cell with eDRX configuration, it performs inter-frequency or inter-RCell_FACH state as follows:

• If the UE is using a common E-DCH resource or T321 is running, no measurements are performed.

• If the UE is not using a common E-DCH resource and T321 has expired, it may perform measurements during eDRX g

Note that FACH Measurement Occasion is not applicable to a eDRX capable UE in Cell_FACH state in a cell with eDRX c

activated.

UE CAPABILITY (1/2) The UE informs the RNC about its Enhanced DRX capability through RRC signalling. It may indicate its eDRX support CE

Cell_PCH or URA UPDATE message in URA_PCH state by including the ‘Support of HS-DSCH DRX operation’ IE and set it

This optional UE defines whether the UE supports HS-DSCH DRX operation in Cell_FACH state. If the UE supports HS-DS



102


Cell_FACH state then the UE shall also support HS-PDSCH in Cell_FACH. This IE is optional and its absence indicates tha

support enhanced DRX. If the UE supports it, then it must include this IE and set it to True.

The UE may also indicate its detailed capabilities in RRC CONNECTION SETUP COMPLETE and other messages such as U

INFORMATION and INTER RAT HANDOVER INFO (‘UE radio access capability’ IE “Physical channel capability” IE ‘Su

DRX operation’ IE = True).

The RNC shall notify the Node B of an eDRX capable UE by setting ‘eDRX Indication’ IE = 1 in HS-DSCH FP Type2. This I

the UE in Cell_FACH state supports enhanced UE DRX or not. The IE shall be set to 0 for any eDRX non-capable UE.

The RNC shall set the 'eDRX Indication' IE to “Enhanced UE DRX not supported” for all data frames that are addressed

specific H-RNTI (this obviously means that value “Enhanced UE DRX supported” can be set for a dedicated H-RNTI only

apply eDRX for dedicated H-RNTI only, as 3GPP clearly states that enhanced UE DRX is only applicable to UEs configure

H-RNTI.

UE CAPABILITY (2/2) How to enforce it is fully up to vendor implementation choice. There are two options:

• RNC side enforcement – The RNC has this information and therefore should set the eDRX Indication for BCCH and co

value “Enhanced UE DRX not supported” to avoid the Node B having to check for the H-RNTI type in each and every H



103


• Node B side enforcement – The Node B checks the H-RNTI type in every FP frame. That is, the BCCH H-RNTI and the

RNTI are provided by the RNC to the Node B through the PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST (‘H

System Information’ IE), though the latter (the list of Common H-RNTI) is optional. Thus, in principle, the Node B has

distinguish between the three H-RNTI types (BCCH H-RNTI, Common H-RNTI and Dedicated H-RNTI).

From a performance point of view, the RNC side enforcement is preferable. The Alcatel-Lucent solution uses this optio

CELL CAPABILITY All cells mapped on the same eCEM will report the support of this feature. Hence, the Node B will declare the cell as

cell is mapped in a eCEM board. Note that this feature will not necessarily be activated on all cells of the board, as the

The cell capability regarding eDRX is known from the ‘Enhanced UE DRX Capability’ IE being set to “Enhanced UE DRX



104


messages RESOURCE STATUS INDICATION and AUDIT RESPONSE:

• When an Enhanced UE DRX capable cell is initialized and comes into operation, the Node B will include the ‘Enhanc

IE set to “Enhanced UE DRX Capable” for the cell in RESOURCE STATUS INDICATION message.

• When the eDRX capability has changed for a given cell (either gain or loss of the Enhanced UE DRX capability), the

the new capability in the ‘Enhanced UE DRX Capability’ IE in RESOURCE STATUS INDICATION or AUDIT RESPONSE. The

be due to hardware / software upgrade, failure or recovery reasons.

If the Enhanced UE DRX capability is lost, through the HBBU fault management feature, the UE will be reconfigured to

without eDRX operation. In this state, the eDRX feature of the cell is deactivated, any SIB broadcasting of ‘HS-DSCH D

Information’ IE is stopped via the System Information Update procedure, the UE is notified of system information upd

UTRAN and the UE resume the “FACH Measurement Occasions” operation.

In case the cell becomes Enhanced UE DRX capable, it is beneficial that a capable UE can take this advantage. So, the

cell is activated, the SIB broadcasting of ‘HS-DSCH DRX in CELL_FACH information’ IE shall is started via the System In

procedure, the UE is notified of the system information update and both the UTRAN and the UE start using the specifie

cycle for scheduling DL traffic transfer and inter-system/inter-frequency measurement occasions.

In case of Enhanced UE DRX capability loss or recovery, a warning is sent to the operator.

ENHANCED UE DRX CONFIGURATION IN THE NODE B The RNC configures the Node B with eDRX operation by including the ‘Enhanced UE DRX Information’ IE in PHYSICAL SH

RECONFIGURATION REQUEST message.

As per 3GPP TS25.433, if the PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message includes this IE, then t

i f i E h d UE DRX i i h ll



105


information to execute Enhanced UE DRX operation in the cell.

The Node B rejects the eDRX configuration by returning a PHYSICAL SHARED CHANNEL RECONFIGURATION FAILURE mes

either Enhanced Cell_FACH for Downlink feature (PM168710) is not activated in the cell or the Enhanced Cell_FACH for

are not configured in the cell.

As per TS25.433, if the PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message includes the ‘Enhanced UE D

and if the message does not contain the ‘HS-DSCH Common System Information’ IE or the resource for enhanced Cell_

configured for the cell, the Node B will reject the procedure using the PHYSICAL SHARED CHANNEL RECONFIGURATION

The Node B also rejects the eDRX configuration (by returning the same message to the RNC) in case Enhanced Cell_FAC

Downlink feature (PM108103) is not activated in the cell and the ‘DRX Interruption by H-DSCH Data’ IE is set to False.

configuration that does not allow a way for the UE to exit eDRX operation.

Besides the Physical Shared Channel Reconfiguration procedure, the RNC also configures the UE with the System Inform

procedure to add eDRX relevant SIB parameters.

ENHANCED UE DRX CONFIGURATION IN THE UE The RNC configures the UE with eDRX operation by indicating ‘HS-DSCH DRX in Cell_FACH Information’ IE in SIB5 / SIB

populated by the RNC and broadcast by the Node B. The RNC configures a proper value for eDRX inactivity timer (T321

DSCH arrival intervals (between different packets within a bunch) in the ‘HS-DSCH DRX in CELL_FACH information’ IE.

using parameter t 321 , that determines the time the UE waits until initiating eDRX operation, in milliseconds.



106


The RNC also configures a proper value for eDRX Rx burst period to suit the typical HS-DSCH transmission time needed

volume, throughput and the number of HARQ retransmissions) in ‘HS-DSCH DRX in Cell_FACH Information’ IE ‘HS-DS

This is configured using parameter enhancedDrxRxBurst , that determines the length of the DRX Cycle during DRX ope

It also needs to configure a proper value for the eDRX cycle to suit typical HS-DSCH arrival intervals (between differen

UE battery saving in ‘HS-DSCH DRX in Cell_FACH Information’ IE ‘HS-DSCH DRX Cycle FACH’ IE. This is configured us

enhancedDrxRxCycle , that determines the period within the DRX Cycle that the UE continuously receives HS-DSCH, in

Finally, the configuration of a proper value for the ‘HS-DSCH DRX in Cell_FACH Information’ IE ‘DRX Interruption by

also required. This is configured using parameter isDrxInterruptionByHsdschDataAllowed , that determines whether

be interrupted by downlink HS-DSCH data.

If the operator requires eDRX operation to be interrupted by downlink HS-DSCH data transmission, this IE should be setoperator requires eDRX operation not to be interrupted by downlink HS-DSCH data transmission, this IE should be set t

large portion of data is to be received in downlink while the IE is set to False, the UE is still able to receive a bulk of d

reception burst period, but with a longer delay in receiving this data. Thus there is a clear performance tradeoff betw

and timely data reception. Operators will be able to decide which value to configure in the RAN model to reflect thei

T321 INACTIVITY TIMER The inactivity timer will start:

• After release of the common E-DCH channel.

• In case the UE finishes the HS-DSCH reception and the UE is not using a common E-DCH resource



107


• In case the UE finishes the HS DSCH reception and the UE is not using a common E DCH resource.

• Upon state transition to Cell_FACH state.

Timer t 321 will continue to run and expires if no HS-DSCH (if ‘DRX Interruption by HS-DSCH Data’ IE is set to True) andtransmission occurs during this inactivity time period.

For Enhanced UE DRX, UE DRX will start after expiry of inactivity timer. After the expiry of the inactivity timer, the UE

during the pre-defined Rx bursts (i.e. enter eDRX operation) unless there is an active E-DCH transmission or there is a

transmission when isDrx Int err upt i onByHsdschDat aAllowed is set to True. That is, after the expiry of the inactivity ti

enter eDRX operation unless it is triggered to exit the eDRX mode and return to the normal operation.

The inactivity timer will stop:

• If there is a start of an E-DCH transmission, that interrupts eDRX operation or stops the inactivity timer.

• In case of reception of an HS-DSCH transmission, that interrupts eDRX operation or stops the inactivity timer.

IMPACT OF DOWNLINK TRANSMISSION SCHEDULING AND MEASUREMENT OIf the eDRX feature is activated in a cell, the HSDPA scheduler within the Node B must be aware of a UE (eDRX capable

and only schedule the downlink data transfer to it within the Rx burst periods of the DRX cycles. On the other hand, if

functionality is deactivated, the HSDPA scheduler within the Node B must be aware of the UE FACH Measurement Occa

schedule the downlink data transmission to this UE out of predefined FACH Measurement Occasions periods.



108


When a eDRX capable UE is in Cell_FACH state in a cell with eDRX configuration, it performs inter-frequency or inter-R

Cell_FACH state as follows:

• If the UE is occupying a common E-DCH resource or T321 is running, it performs no measurement.

• If the UE is not occupying a common E-DCH and T321 is expired, it can perform measurements during eDRX gaps.

Note that the FACH Measurement Occasion is not applicable to eDRX capable UE in Cell_FACH state in a cell with eDRX

In order for the HSDPA scheduler to correctly track T321 expiry and know the correct frame / subframe occurrences t

an UE with eDRX enabled, coordination between UL and DL scheduler must be implemented. That is, the HSDPA

consideration both DL and UL activity status to make a reliable judgement on when T321 starts.

IMPACT OF DOWNLINK TRANSMISSION SCHEDULING AND MEASUREMENT OThe relation between the instant this timer is started and the scheduler implementation is described below:

• When the UE finishes the HS-DSCH reception and by that time the UE has not occupied a common E-DCH resource. S

activity, the HSDPA scheduler may, on its own, determine when T321 starts.



109


• The UE releases a common E-DCH Channel. As soon as E-DCH scheduler decides to de-allocate the common E-DCH f

scheduler notifies the HSDPA scheduler. Upon the reception of such notification, the HSDPA scheduler knows when T3

the E-DCH scheduler informs the HSDPA scheduler when the UE has acquired a common E-DCH resource and the bindi

common E-DCH and the dedicated E-RNTI is known after collision is resolved. Then, with the binding between dedica

dedicated E-RNTI known by the HSDPA scheduler itself, the HSDPA scheduler will readily know if a UE with dedicated

common E-DCH resource or not.

• Upon state transition to Cell_FACH state. Before collision is resolved and the dedicated H-RNTI is used for DL comm

won't work in eDRX mode.

In eDRX operation, the UE may use the “sleep” period (out of Rx Burst of the DRX Cycle) to measure other frequencie

(and thus ignore FACH Measurement Occasions). In non-eDRX operation, the UE may at times use FACH Measurement O

temporarily switch to measure other frequencies/systems for mobility purpose.

UE DRX OPERATION SUMMARY (1/2) UE can work in DRX mode in Cell_FACH state (e-DRX), that is, the UE only needs to receive the common HS-DSCH at DR

use the DRX cycle pattern for inter-frequency and inter-RAT measurements in Cell_FACH state, instead of FACH measu

is allowed to be in DRX operation only when it does not have any common E-DCH resource allocated in Cell_FACH state

The following points outline the basic concepts for Cell FACH DRX:



110


The following points outline the basic concepts for Cell_FACH DRX:

• When the UE has common E-DCH resources allocated, it is not in DRX and can continuously receive on downlink.

• After the E-DCH resources are released, the UE initiates inactivity timer T321. This timer is – if still running upon doreception – reset and restarted at the end of the HS-SCCH subframe addressed to this UE. If this timer expires and th

eDRX mode upon downlink data reception, the timer starts at the end of the HS-SCCH subframe addressed to this UE

isDrx Inter rupt ionByHsdschDat aAllow ed is set to True. Such HS-SCCH subframe addressed to this UE can be a subfra

an initial packet transmission or a packet retransmission towards the UE in case of a NACK. In case flag

isDrx Inter rupt ionByHsdschDat aAllow ed is set to False, when the UE has already entered the eDRX operation, eDRX

interrupted by DL data delivery. In this case, the HSDPA scheduler sends UE data only during the Rx Bursts periods. Si

leaves the eDRX mode due to HS-DSCH data transmission, timer T321 does not start at all.

• The timer is stopped if the UE gets a E-DCH resource allocation. It could also be during PRACH transmission.

• If the timer expires, the UE will start to operate in DRX mode, according to the configured pattern.

• The DRX activity is specified in terms of cycle length and gap, and is synchronised with the SFN.

• The DRX activity may be defined per user.

UE DRX OPERATION SUMMARY (2/2) The following points outline the basic concepts for Cell_FACH DRX (cont.):

• The DRX activity is only allowed if the UE has been configured with an E-RNTI or a dedicated H-RNTI.

• Regarding isDrx Inter rupt ionByHsdschDat aAllow ed default value, there is a tradeoff between UE battery saving a



111


g g p y , y g

reception depending on which performance a given operator values the most. If an operator values the maximum UE

saving, this parameter should be set to True. But, if the operator cares more about DL data delivery latency, this par

be set to True.

KEEPING ENHANCED DRX CAPABLE UES FOR LONGER IN CELL_FACH STATIn order to exploit the maximum benefit of eDRX UE operation, it is preferable to retain the eDRX capable UEs in Cell_

possible. For this purpose, a new T2 timer (downsize timer from Cell_FACH state to Cell_PCH / URA_PCH state), t imer

introduced in PM108103 model. The default value for this timer is significantly larger than the previous T2 timer value

Once an eFACH capable UE enters Cell FACH state, the RNC checks if it is eDRX capable or not. If yes, the new timer t



112


Once an eFACH capable UE enters Cell_FACH state, the RNC checks if it is eDRX capable or not. If yes, the new timer t

is applied to the given UE. Otherwise, the legacy t ime rT2 is used instead.

This approach assumes that all eFACH capable UEs will also be eDRX capable UEs.




113


1.3 | UPGRADE RULES

FIRST UPGRADE USING THE FEATURE To ensure the same level of functionality and performance after the upgrade than before (ISO-functionality) the follow

used:

• isEnhancedUeDrxInCellFachAllowed (RadioAccessService) = False. This disables the feature at RNC level.



114


During the upgrade, HsdschDrxInCellFachInfo object is created (with default values) for HsdpaCellClass.




115


1. 4 | FEATURE ACT IVAT ION

FEATURE DEPENDENCIES The enhanced UE DRX in Cell_FACH is dependent on the following features:

• PM168710 – Enhanced Cell_FACH for Downlink.

• PM108103 – Enhanced Cell_FACH for Downlink and Uplink.



116


It is an invalid configuration if UTRAN supports/configures eDRX but no eFACH for downlink. As such, PM168710 must b

advance before PM121209 is activated.

It is an invalid configuration if UTRAN supports/configures eDRX but no eFACH for uplink. As such, PM108103 must be a

before PM121209 is activated.

Despite eDRX being able to still work with Enhanced Cell_FACH for Downlink, it is not really possible to exploit the ma

eDRX feature. Moreover it is likely that both eFACH features will be bundled together in a normal deployment. Thus it

always enable PM108103 before enabling eDRX.

So, even if from a technical point of view eDRX is only dependent on PM168710, eDRX target customers have no intere

without PM108103 being simultaneously enabled. Therefore, Alcatel-Lucent design choice is that both R7 eFACH and R

activated before activating the eDRX feature.

FEATURE ACTIVATION

The Enhanced UE DRX in Cell_FACH feature is activated per cell, when the following conditions are fulfilled:

• The feature has been activated in the RNC, through isEnhancedUeDrxInCellFachAllowed (RadioAccessService) = T

• The cell supports eDRX in Cell_FACh, indicated in NBAP RESOURCE STATUS INDICATION and AUDIT RESPONSE messag

bilit b tti g ‘E h d UE DRX C bilt ’ IE “E h d UE DRX C bl ”



117


capability by setting ‘Enhanced UE DRX Capabilty’ IE = “Enhanced UE DRX Capable”.

• Serving cell is eligible to eDRX, enabled through cell level feature activation flag for eDRX, isEnhancedUeDrxInCel

(FDDCell) = True.

• Feature PM168710 is activated in the RNC / cell.

• Feature PM108103 is activated in the RNC / cell.

Otherwise, the eDRX is not activated. Basically, feature PM121209 can be activated in a cell only if all its RNC level an

turned on and the feature PM108103 is activated for the given cell. Note that PM121209 is also indirectly dependent o

interaction is covered by feature PM108103 (if PM108103 is enabled, PM168710 must be enabled at the same time).

If the feature PM121209 is activated, t imerT2forECel l fach must be set to an appropriate value, in order to keep the state for longer. The other eDRX operation parameters must also be set (t321, enhancedDrxRxBurst , enhancedDrxRx

isDrx Inter rupt ionByHsdschDat aAllow ed ).

When UE is in DRX mode of operation Layer2 (RLC) round trip delay (RTD) may be increased, depending on eDRX confi

length). Hence RLC parameter optimization may be required, considering this delay.

FEATURE CONFIGURATION AND PARAMETERS

Parameter Description Object Range and Unit

i s EnhancedUeD rx InCe l l FachA l l owed

RNC level feature activation flag for EnhancedDRX in Cell_FACH state.

RadioAccessService Boolean {True, False}

Cell level feature activation flag for EnhancedDRX i C ll FACH t t

FDDCell Boolean {True, False}



118


i s EnhancedUeD rx InCe l l FachA l l owed

DRX in Cell_FACH state.FDDCell Boolean {True, False}

enhancedD rxCyc l e

Specifies the length of the DRX Cycle duringDRX operation, in frames.

HsdschDrxInCellFachInfoEnumerate {4 (0), 8 (1), 16

32 (3)} frames

enhancedD rxRxBu r s t

Specifies the period within the eDRX Cycle thatthe UE continuously receives HSDSCH, inframes.

HsdschDrxInCellFachInfoEnumerate {1 (0), 2 (1), 4

(3), 16 (4)} frames

t 3 2 1

Specifies the time the UE waits until initiatingeDRX operation

HsdschDrxInCellFachInfoEnumerate {100 (0), 200

400 (2), 800 (3)} ms

i s D rx In t e r rup ti onByHsd schDa taA l lowed

The flag indicates whether an eDRX operationcan be interrupted by DL HS-DSCH datareception.

HsdschDrxInCellFachInfo Boolean {True, False}

RAN MODEL

RNC

RadioAccessService




119


DedicatedConf

HsdpaCellClass

HsdschDrxInCellFachInfo

enhancedDrxCycle

enhancedDrxBurst

t321isDrxInterruptionByHsdschDataAllowed

RadioAccessService

DedicatedConf


CONTROL RULES AND WIPS CHECKS (1/2)

At RNC level, Enhanced UE DRX in Cell_FACH feature (PM121109) depends on Enhanced Cell_FACH for Downlink and Up

(PM108103). This means:

• The Enhanced UE DRX in Cell_FACH feature can’t be activated if Enhanced Cell_FACH in Downlink and Uplink featur

i.e. isEnhancedUeDrxInCellFachAllowed (RadioAccessService) can’t be set to True if isEnhancedCellFachForUlAllo

(RadioAccessSer ice) is not set to Tr e



120


(RadioAccessService) is not set to True.

• Enhanced Cell_FACH in Downlink and Uplink feature can’t be deactivated, if Enhanced UE DRX in Cell_FACH feature

isEnhancedCellFachForUlAllowed (RadioAccessService) can’t be set to False if isEnhancedUeDrxInCellFachAllowed(RadioAccessService) is not set to False.

At cell level, the Enhanced UE DRX in Cell_FACH feature activation flag must be set to the same value as Enhanced Ce

and Uplink feature activation flag:

• isEnhancedCellFachForUlAllowed (FDDCell) must be set to the same value as isEnhancedUeDrxInCellFachAllowe

CONTROL RULES AND WIPS CHECKS (2/2)

The following consistency checks shall be implemented if isDrx Interr upt i onByHsdschDat aAllowed (HsdschDrxInCellF

• resetTimer (CommonPriorityQueue) ≥ Maximum [t 321 (HsdschDrxInCellFachInfo) / t ime rT1 (CommonPriorityQueu

• t ime rT1 (CommonPriorityQueue) > 10 * enhancedDrxCycle (HsdschDrxInCellFachInfo), which ensures that the MAC

in the UE waits long enough to process HARQ retransmission in subsequent Rx Bursts before forwarding out-of-order



121


in the UE waits long enough to process HARQ retransmission in subsequent Rx Bursts, before forwarding out of order

higher layers.

• discardTimer (CommonPriorityQueue) > t ime rT1 (CommonPriorityQueue).

The DRX Burst length value can’t be greater than the DRX Cycle length:

• enhancedDrxRxBurst (HsdschDrxInCellFachInfo) must be set higher than enhancedDrxCycle (HsdschDrxInCellFach




122


1. 5 | FEATURE MONITORING

NEW COUNTERS IBTS

COUNTER ID 10858

Name VS_HsdpaDroppedMACPdusForEDrxUEs

3GPP Name VS.HsdpaDroppedMACPdusForEDrxUEs

Location Cell



123


Unit Number of MAC PDUs

Range 31 bits

Type CUM

Family HSDPA Statistics (Node B counters)

Meaning, DescriptionTotal number of MAC PDUs that are dropped by the Node B due to either discardTimer expiry or t ime rT1

capable UEs.

Triggering EventWhenever the Node B is triggered to drop MAC PDUs which are destined towards eDRX capable UEs, upon tdiscardTimer or t ime rT1 .

Screening Criteria Distribution according to PDU dropped reason.

LR14.2 Screenings

0 Dropped on T1 Expiry

1 Dropped on Discarded Timer Expiry

NEW COUNTERS ONEBTS

COUNTER ID 35163

Name VS_MAC_DroppedMacPdus4EDrxUEs_ONB

3GPP Name VS.MAC.DroppedMacPdus4EDrxUEs

Location Cell



124


Unit Number of MAC PDUs

Range 31 bits

Type CUM

Family MAC Related Measurements (Node B counters)

Meaning, DescriptionTotal number of MAC PDUs that are dropped by the Node B due to either discardTimer expiry or t ime rT1

capable UEs. When the dropped MAC-ehs PDU contained fractions of a MAC PDU, this fraction is counted as

Triggering EventWhenever the Node B is triggered to drop MAC PDUs which are destined towards eDRX capable UEs, upon tdiscardTimer or t ime rT1 .

Screening Criteria None



108103 – FEATURE DESCRIPTION– ENHANCED RACH PROCEDURE BACKUP SLIDE

•The common E-DCH preamble transmission and power ramping procedures are very similar to

Rel99. As depicted in the Figure : 1. After sending each random access request, "if no ACK/NACK

is received AND if Preamble Retransmission Counter < preambleRetransMax ", the UE increases

its power for the preambles of the next requests.

• After sending each random access request, if ACK is received, the UE stops its power ramping

process.



126


•A new power offset between the last transmitted preamble and the initial DPCCH transmission

is defined for E-RACH, called Ppe and is provisioned via the new OAM parameter

CommonEdchPreambleCtrlInfo.powerOffsetPpe.

•Otherwise, after sending a random access request, "if no ACK/NACK is reveived AND Preamble_

Retransmission_ Counter reaches preambleRetransMax " or "if a NACK (on AI and EAI part (if EAI

is configured)) is received", the UE exits from the physical random access procedure.

•A retry is later made until the L2 maximum number of preamble ramping cycle Mmax is

reached.

• If a NACK is received while Mmax is not reached, the UE would retry again after a random

back-off timer bounded by Nb01minand Nb01max.

•Beside the Ppe parameter, the common E-DCH has a separate set of other parameters to

differentiate from RACH under the

•CommonEdchPreambleCtrlInfo.eRachTxParameters: Mmax, Nb01min, Nb01max as defined

above. The rest of the parameters are shared with the legacy RACH’s.

Documents

Anced Cell_FACH for DL and UL _ 121209 Enhanced UE DRX in Cell_FACH - FSM Version 01 03 - Preliminary