0% found this document useful (0 votes)
564 views152 pages

Golden Parameter

The document discusses the agreed and golden parameters for random access channel (RACH) procedures for time division duplex (TDD) and frequency division duplex (FDD) deployments. Key parameters include the number of RA preambles, preamble power levels and offsets, response window sizes, and maximum HARQ transmissions. The parameters are tunable based on access load, uplink resource allocation, and first transmission sizes to optimize the RACH process.

Uploaded by

sip ims
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as XLSX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
564 views152 pages

Golden Parameter

The document discusses the agreed and golden parameters for random access channel (RACH) procedures for time division duplex (TDD) and frequency division duplex (FDD) deployments. Key parameters include the number of RA preambles, preamble power levels and offsets, response window sizes, and maximum HARQ transmissions. The parameters are tunable based on access load, uplink resource allocation, and first transmission sizes to optimize the RACH process.

Uploaded by

sip ims
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as XLSX, PDF, TXT or read online on Scribd
You are on page 1/ 152

Idx Title No.

Parameters
TDD FDD (or TDD + FDD)
1 PRACH 5 5
2 RACH 11 11
3 PUCCH 5 5
4 PUSCH 8 8
5 SRS 10 10
6 UL Power Control (Common) 8 8
7 UL Power Control (Dedicated) 7 7
8 SR 2 2
9 MAC 8 8
10 CQI Report 4 4
11 PDSCH 4 4
12 SRB 1&2 - RLC-AM,MAC 10 10
13 DRB-QCI8 - RLC-AM, PDCP, MAC 12 12
14 DRB-QCI5 - RLC-AM, PDCP, MAC 12 12
15 DRB-QCI1 - RLC-AM, PDCP, MAC 10 10
16 Cell Selection & Re-selection 12 12
17 Handover (2300 or 1800 only) 14 14
18 Handover-2300 (2300+1800)
19 Handover-1800 (2300+1800+ noSC)
20 Handover-1800 (2300+1800+b40SC)
21 Paging 2 2
22 RRC Connection Est. and RLF 6 6
23 VoLTE-ROHC 3 3
24 VoLTE-CDRX 5 5
Total 158 158
Agreed Parameters
TDD FDD (or TDD + FDD)
5 5
11 11
5 5
8 8
10 10
8 8
7 7
2 2
8 8
4 4
4 4
10 5
12 5
12 4
10 4
12 5
14 14

2 2
6 6
3 3
5 2
158 122
Status Golden Parameter
Parameter
TDD FDD TDD FDD

prach-ConfigIndex Agreed Agreed 3 3

prach-FreqOffset Agreed Agreed 5 5

zeroCorrelationZoneConfig (Ncs
Agreed Agreed 12 12
Configuration)
rootSequenceIndex Agreed Agreed Cell-specific Cell-specific

highSpeedFlag Agreed Agreed 0 0

go to Master Sheet
RJIL/Samsung Qualcomm View
TDD FDD TDD FDD

Deployment
3 3 same
dependent

Deployment
5 5 same
dependent

12 12 12 (15km cell radius) same


Cell-specific Cell-specific Cell-specific same

TRUE if in high-
0 0 same
speed mobility
Comments Tune-ability

Choose based on the PRACH capacity requirements.


Index 3 provides a PRACH density of 1 (every 10ms).
Tunable - based on
Same index or different index could be used across cell
PRACH capacity demand
with the trade-off being PRACH <> PRACH or
PUSCH<>PRACH interference

Since the UL/DL configuration SA2 has a limited number


of UL subframes, prach-FreqOffset should be set to a Tunable - based on
relatively large value in order to have enough space for PUCCH capacity demand
the transmission of PUCCH by many UEs

Tunable - based on cell


radius
Cell-specific

If FALSE, the unrestricted sets of cyclic shifts of the


Zadoff-Chu root sequences will be used. The UE can use
all the sequence available every integer multiple of Ncs. Tunable - based on high-
However, some sequences are not optimized for high speed mobility
Doppler shift due to high-speed mobility. This parameter requirements
should be optimized along with other related parameters
including Ncs
Samsung Comments
Status Golden Parameter
Parameter
TDD FDD TDD FDD

numberOfRA-Preambles Agreed Agreed 56 56

sizeOfRA-PreamblesGroupA Agreed Agreed 28 28

messageSizeGroupA Agreed Agreed 56 56

messagePowerOffsetGroupB Agreed Agreed 0dB 0dB

ra-PRACH-MaskIndex Agreed Agreed

preambleInitialReceivedTarget
Agreed Agreed -108dBm -108dBm
Power

powerRampingStep Agreed Agreed 2dB 2dB

preambleTransMax Agreed Agreed 10 10


ra-ResponseWindowSize Agreed sf10

mac-
Agreed sf56
ContentionResolutionTimer

maxHARQ-Msg3Tx Agreed 4

go to Master Sheet
RJIL/Samsung Qualcomm View
TDD FDD TDD

60 56 40 – 56 with Contention-Free RACH supported

Implementation dependent.
- If the uplink resource allocation after PRACH is
to be optimized, then we need to configure this
28 28 parameter.
- It depends on the statistic of the first TB size
after the successful RACH procedure.
Implementation dependent.
- If the uplink resource allocation after PRACH is
to be optimized, then we need to configure this
56 56 parameter.
- It depends on the statistic of the first TB size
after the successful RACH procedure.
Implementation dependent.
- If the uplink resource allocation after PRACH is
to be optimized, then we need to configure this
0 dB 0 dB parameter.
- It depends on the statistic of the first TB size
after the successful RACH procedure.

Set it to nonzero if access load is high

dBm-104 to dBm-108
-108 dBm -108 dBm

(eNodeB implementation dependent)

2 dB 2 dB 2 dB

10 10 10
sf10 sf7 4-5 subframes

sf 56 sf64 56 subframes

4 8 4 transmissions
m View
Comments
FDD

Low number of contention-free preambles may


delay handovers into the cell. When contention-free
handover is supported, this value should be function
of handover traffic and can be started with value of
same
56 (8 for contention-free handover) and moving to
lower value (40) based on handover load ( # of
handovers per UE is a KPI that could be monitored
for optimizing this parameters)

Tunable based on first TB size after successful RACH


same
procedure

Tunable based on the distribution of first TB size after


same
successful RACH procedure

Tunable based on the distribution of first TB size after


same
successful RACH procedure

Tunable based on access load. A non-zero value can


same
reduce the chances of RACH collisions

This should be optimised based on avg. number of


preambles observed. This shall be computed as
same -174 + 10Log(RACH BW) + eNodeB NF + RACH
C/I. The eNodeB NF and RACH C/I may depend on
eNodeB implementation

same

same
Too high setting will cause long wait time before
retrying in case of non-responded preamble. This
parameter should be aligned with timers for RRC
same Connection re-establishment (T300 and T301) and
mac-ContentionResolutionTimer. The response
window size should also consider the TDD frame
structure and PDCCH opportunities available

same

same
Tune-ability Samsung Comments

Already changed to 56 from 60.


Tunable - based on
But, we need to optimize again the number of HO
handover statistics
attempts after getting subscriber statistics

Tunable - based on
first TB size after
successful RACH
procedure

Tunable - based on
first TB size after
successful RACH
procedure

Tunable - based on
first TB size after
successful RACH
procedure

Tunable - based on
RACH performance

Tunable - based on
RACH performance

Tunable - based on
RACH performance

Tunable - based on
RACH performance
Rather than making UE send more PRACH, how
about waiting one more radio frame to reduce UL
interference of PRACH resource.
Tunable - based on
From Vellore CLOT result, all Msg2 message is sent
RACH performance
8 subframe later, after sending Msg1.
So, 4~5 subframes QC team is recommending does
not fit to our system.

Tunable - based on
RACH performance

Tunable - based on
RACH performance
Qualcomm Comments
OK. Continue to optimise this
based on further field studies
Status Golden Parameter
Parameter
TDD FDD TDD
deltaPUCCH-Shift Agreed ds2
n1PUCCH-AN Agreed 20
nCS-AN Agreed Agreed 0

nRB-CQI Agreed 2

tdd-AckNackFeedbackMode Agreed Agreed bundling

go to Master Sheet
Golden Parameter RJIL/Samsung
FDD TDD FDD
ds2 ds1
20 14
0 0 0

2 1

NA bundling NA
Qualcomm View
TDD FDD
ds2 same
Cell specific same
non-zero if mix mode PUCCH same
Start with initial value of 2 and increase
based on simultaneous active UEs per same
cell

bundling same
Comments Tune-ability
Network-wide
Network-wide
These parameters should be optimized jointly. With
Network-wide
higher traffic deltaPUCCH-Shift of ds1 may be
required as network gets loaded Tunable - based on
number of UEs per
cell

Network-wide
Samsung Comments
Status
Parameter
TDD FDD

enable64QAM Agreed Agreed

hoppingMode Agreed Agreed

n-SB Agreed Agreed

pusch-HoppingOffset Agreed Agreed

Agreed
( Samsung Value-
cyclicShift 8Jan15) Agreed
(Need to review Again
& continue discussion )

groupAssignmentPUSCH Agreed Agreed

Agreed
( Samsung Value-
groupHoppingEnabled 8Jan15) Agreed
(Need to review Again
& continue discussion )

sequenceHoppingEnabled Agreed Agreed

go to Master Sheet
Golden Parameter RJIL/Samsung
TDD FDD TDD FDD

TRUE (will change to


1 1 1
False)

interSubFrame interSubFrame interSubFrame interSubFrame

1 1 1 1

10 4 10 4

0 0 0 0

0 0 0 0

0 0 0 0

0 0 0 0
Qualcomm View
TDD

FALSE for category 4 and below

interSubFrame

If SRS is enabled, recommend to use the best


portion of the channel instead of hopping (i.e., set
it to 1 to disable hopping).

A positive number if PUSCH hopping is enabled

Nonzero if GroupHoppingEnabled is set to


FALSE

FALSE if GroupHoppingEnabled is set to TRUE


Qualcomm View
FDD

same

same

same

same

same

same

same

same
Comments Tune-ability

Network-wide

Network-wide

Frequency hopping is used to provide frequency


diversity when no or limited frequency-specific Network-wide
channel quality information is available

When PUSCH hopping is enabled, this parameter


should be set greater than the number of RBs Network-wide
reserved for PUCCH format 1/1a/1b and 2/2a/2b

Network-wide

Same sequence patterns for PUCCH and PUSCH Network-wide

Enables PUSCH interference randomization


Network-wide
between different cells

Network-wide
Samsung Comments QC Comments

will change to False

it depends on the purpose of SRS

depending on the UL Scheduler policy

RJIL input required

depending on the UL Scheduler policy

RJIL input required


depending on the UL Scheduler policy
sequence hopping only applies if group hopping is
disabled and sequence hopping is enabled.
(36.211.5.5.1.4) OK
Status
Parameter
TDD FDD

ackNackSRS-
Agreed Agreed
SimultaneousTransmission

srs-BandwidthConfig Agreed Agreed

srs-SubframeConfig Agreed Agreed

cyclicShift Agreed Agreed


duration Agreed Agreed
freqDomainPosition Agreed Agreed

srs-Bandwidth Agreed Agreed

srs-ConfigIndex Agreed Agreed

srs-HoppingBandwidth Agreed Agreed

transmissionComb Agreed Agreed

go to Master Sheet
Golden Parameter RJIL/Samsung
TDD FDD TDD

1 1 1

bw4 bw4 bw4

sc0 sc0 sc1

cs0 cs0 cs0

1 1 1

bw3 bw3 bw3

421, 602 (320ms) 421, 602 (320ms) 421, 602 (320ms)

hbw0 hbw0 hbw0

0, 1 0, 1 0, 1
RJIL/Samsung Qualcomm View
FDD TDD
TRUE If SRS-subframeConfig results in a large
1 percentage of SRS subframes per frame; FALSE
otherwise.

Set it to different than NULL if frequency-selective


bw4
uplink scheduling is desired

sc0 If SRS transmission is enabled, set it as a


(will change in Aug.) function of uplink loading (sc0 for loaded cell)

Variable (depends on UL scheduling


cs0
implementation)
1 TRUE if SRS is enabled

UE / Scheduler dependent
Set it to different than NULL if frequency-selective
bw3
uplink scheduling is desired.
Set it to large number (i.e., 17 – 36) if high uplink
421, 602 (320ms) load;
Set it to small number (i.e., 2 – 6) otherwise
Set it to the value < srs-Bandwidth to enable
hopping when the configured SRS bandwidth
hbw0
(defined by srs-BandwidthConfig and srs-
Bandwidth) is smaller than system bandwidth
0, 1 Scheduler dependent
mm View
Comments
FDD

same

same

The srs-SubframeConfig needs to be set in tandem


with the UL/DL subframe configuration in order to
same ensure that the periodicity & offset combination point to
an UL subframe. Therefore, for sa2, only sc0, sc1, sc8,
or sc10 can be deployed

same

same

same

same

same

same

same
Tune-ability Samsung Comments

Network-wide

Network-wide

Network-wide

Network-wide
Network-wide
Network-wide

Network-wide

Tunable - based on UL
load

Network-wide

Network-wide
Status
Parameter
TDD FDD

deltaPreambleMsg3 Agreed Agreed

p0-NominalPUCCH Agreed Agreed

p0-UE-PUCCH Agreed
Agreed

Agreed
deltaF-PUCCH-Format 1 ( Samsung Value-5Jan15) Agreed
(Need to review Again with real
traffic )
Agreed
deltaF-PUCCH-Format 1b ( Samsung Value-5Jan15) Agreed
(Need to review Again with real
traffic )

deltaF-PUCCH-Format 2 Agreed
Agreed

Agreed
deltaF-PUCCH-Format 2a ( Samsung Value-5Jan15) Agreed
(Need to review Again with real
traffic )

Agreed
deltaF-PUCCH-Format 2b ( Samsung Value-5Jan15) Agreed
(Need to review Again with real
traffic )

go to Master Sheet
Golden Parameter RJIL/Samsung Qualcomm View
TDD FDD TDD FDD TDD

2 dB 2 dB 2 dB 2 dB 2 - 4 dB

Set it above the eNB


-112 -112 -112 -112
PUCCH sensitivity level
0 dB ( implementation
0 0 0 0
dependent)

F0 F0 F0 F0 deltaF2

F1 F1 F1 F1 deltaF3

F0 F0 F0 F0 deltaF0

F0 F0 F0 F0 deltaF2

F0 F0 F0 F0 deltaF2
Qualcomm View
Comments
FDD

same

Ideally, p0- NominalPUCCH = -174 + 10*log(PUCCH


same
BW) + eNB NF + PUCCH C/I + PUCCH RoT 
same

same
Dependent on SR  performance at eNB

A lower value for this parameter may lead to HARQ


same ACK/NAK misdetection which could lead to
degradation in DL throughput due to duplicate DL
transmissions/premature HARQ termination. 1b
carries double the bits as 1a with QPSK modulation.

same

A lower value for this parameter may lead to CQI


same and HARQ ACK/NAK misdetection leading to poor
link adaptation as well as degradation in DL
throughput due to duplicate DL
transmissions/premature HARQ termination.
A lower value for this parameter may lead to CQI
same and HARQ ACK/NAK misdetection leading to poor
link adaptation as well as degradation in DL
throughput due to duplicate DL
transmissions/premature HARQ termination.
Tune-ability Samsung Comments

Tunable - based on
RACH performance

Network-wide the value (-112) is above PUCCH sensitivity level

Network-wide

It depends on PUCCH Power Control Policy. Samsung


Tunable - based on does closed loop power control for PUCCH.
SR performance

It depends on PUCCH Power Control Policy. Samsung


Network-wide does closed loop power control for PUCCH.

It depends on PUCCH Power Control Policy. Samsung


Network-wide does closed loop power control for PUCCH.

It depends on PUCCH Power Control Policy. Samsung


Network-wide does closed loop power control for PUCCH.

It depends on PUCCH Power Control Policy. Samsung


Network-wide does closed loop power control for PUCCH.
QC Comment Samsung Comments

OK

Different number of
bits are carried by the
different PUCCH
formats and would Agree, Power Control works with consideration of
require different different PUCCH Format
amount of power to
be decoded with high
probability
Status Golden Parameter
Parameter
TDD FDD TDD

p0-NominalPUSCH
Agreed Agreed -80

alpha Agreed Agreed al08

deltaMCS-Enabled (Ks) Agreed Agreed en0

accumulationEnabled Agreed Agreed 1

filterCoefficient Agreed Agreed fc4 


p0-UE-PUSCH Agreed Agreed 0
pSRS-Offset
Agreed Agreed 7

go to Master Sheet
Golden Parameter RJIL/Samsung Qualcomm View
FDD TDD FDD TDD

Set it above the eNB


-80 -80 -80
PUSCH sensitivity level.

al08 al08 al08 al08 (0.8)

en0 en0 en0 en1(enabled ; Ks = 1.25)

1 1 1 1

fc4  fc4  fc4  fc4


0 dB ( implementation
0 0 0
dependent)
7 for Ks = 0
7 7 7 3 for Ks = 1.25 ( deltaMCS
enabled)
Qualcomm View
Comments
FDD

same Ideally, p0-NominalPUSCH = -174 + 10*log(PUSCH


BW) + eNB NF + C/I (function of minimum MCS) +
PUSCH RoT 

same

If this parameter is set to en0, UE PUSCH power


cannot be scaled based on UL MCS. Frequent UL
same power control commands combined with UL HARQ
is recommended to ensure appropriate UL power
spectral density and good UL performance.

Accumulative power control has the benefit that it


allows UE power to change over a very large range
same but in steps within the maximum UE power limit and
also the provision of a 0 dB step allows power to be
maintained constant.
same
same
same
Tune-ability Samsung Comments
your comment is valid when alpha equals to 1.
Network-wide currently, we changed it t0 -66dBm with alpha 0.6 for
better UL throughput
currently, we changed it t0 -66dBm with alpha 0.6 for
Network-wide
better UL throughput

Network-wide It is decided by Samsung Power Control Scheme.

Network-wide

Network-wide
Network-wide

Network-wide It is decided by Samsung Power Control Scheme.


Samsung Comments (26,Dec)

After Field Test in Vellore, we concluded to change


-88dBm with alpah 0.8
Status
Parameter
TDD FDD
dsr-TransMax Agreed Agreed
sr-ConfigIndex Agreed Agreed

go to Master Sheet
Golden Parameter RJIL/Samsung
TDD FDD TDD FDD
n64 n64 n64 n64
7 7 7 7
Qualcomm View
TDD FDD
n64 same
0 – 14 for low uplink load same
Comments
Tunable - based on SR performace
Network-wide
Samsung Comments
Status
Parameter
TDD FDD

Agreed
timeAlignmentTimerDedicated /
( Samsung Value- Agreed
timeAlignmentTimerCommon
5Jan15)

Agreed
( Samsung Value-
dl-PathlossChange 5Jan15) Agreed
(Need to review Again
with real traffic )

periodicPHR-Timer Agreed Agreed

Agreed
( Agreed to QC
prohibitPHR-Timer Agreed
values)

maxHARQ-Tx Agreed Agreed

periodicBSR-Timer Agreed Agreed

retxBSR-Timer Agreed Agreed

ttiBundling Agreed Agreed

go to Master Sheet
Golden Parameter RJIL/Samsung
TDD FDD TDD FDD

infinity infinity infinity infinity

dB6 dB6 dB6 dB6

sf100 sf100 sf100 sf100

sf50 sf50 sf100 sf50

n5 n5 n5 n5

sf5 sf5 sf5 sf5

sf320 sf320 sf320 sf320


FALSE (TTIB will FALSE (TTIB will
0 0
come) come)
Qualcomm View
TDD FDD

sf2560 – sf5120 same

dB3 same

sf50 – sf200 same

sf50-sf200 same

n4 or n5 same

sf5 same

sf320 same

0 same
Comments Tune-ability

Higher value leads to the UE being less accurately


synchronized but overhead on the DL would be Network-wide
lower

With higher value , UE will transmit PHR less


frequently. Performance simulation studies suggest
dB1 setting to have close-to-ideal performance in Network-wide
terms of uplink capacity in the absence of periodic
PHR reporting and prohibitPHR-Timer disabled

Depends on device mobility. For high mobility, set it Tunable - based on


to lower value. morphology

It is recommended to keep the timer value lower


Tunable - based on
than periodicPHR-Timer so as to enable PHR
morphology
triggered due to path loss delta (dl-PathlossChange)

Trade off end-to-end delay vs. capacity. For volte,


strongly recommend it to n4, for BE, it can be
Network-wide
relaxed. Lower value enables faster detection of an
RLF if it exists.
Network-wide

Network-wide

TTI bundling not supported for TDD SA2  Network-wide


Samsung Comments QC comments

No need to change to prevent unnecessary TA


command transmission.
Infinity allows eNB to send TA command when it is
needed. Prefer proactive
In addition, there's another way to detect "out-of- approach detection
sync" for UE such as SR max transmission or RLC after service
max retransmission. degradation

trade off of PHR frequency and UL signalling


overhead.
Consdiering time-varying channel phenomenon,
3dB seems too low.
dB3 is preferred

less than sf100


Need to be changed
to lower than sf100
Samsung Comments

Need to clarity why using TA timer is called


proactive approach.
Also other approaches(SR max transmission or
RLC max retransmission) can detect "out-of-sync"
before (proposed) TA timer expire

Could you propose good test methodology to check


the effect of dl-pathlosschange and prohibited
timer?
After joint test, we can conclude.

Could you propose good test methodology to check


the effect of dl-pathlosschange and prohibited
timer?
After joint test, we can conclude.
Status
Parameter
TDD FDD

cqi-FormatIndicatorPeriodic Agreed Agreed

cqi-pmi-ConfigIndex Agreed Agreed

ri-ConfigIndex Agreed Agreed

simultaneousAckNackAndCQI Agreed Agreed

go to Master Sheet
Golden Parameter RJIL/Samsung
TDD FDD TDD FDD

widebandCQI widebandCQI widebandCQI widebandCQI

18, 23 ( Np = 20 => 18, 23 ( Np = 20 => 18, 23 ( Np = 20 => 18, 23 ( Np = 20 =>


20ms) 20ms) 20ms) 20ms)

161 (MRI = 2 => 161 (MRI = 2 =>


161 (MRI = 2 => 40ms) 161 (MRI = 2 => 40ms)
40ms) 40ms)

1 1 1 1
Qualcomm View
TDD FDD

SubbandCQI same

Depends on the type of


services, expected
scheduling rate to same
guarantee the required
QoS, and the mobility
322-482 if Np = 20ms (MRI
322-482 (MRI = 4) = 4)
161-321 if Np = 40ms (MRI
= 2)

same
Comments Tune-ability

With WidebandCQI, a single CQI/PMI is reported for


the entire bandwidth the CQI/PMI may not reflect
the channel quality of each bandwidth part well
enough. With SubbandCQI, a Wideband CQI/PMI
for the entire bandwidth and a subband CQI/PMI for
Network-wide
the selected subband within a bandwidth part are
reported and gives eNB better knowledge about
bandwidth parts. But this would increase the UL
feedback overhead. If Aperiodic CQI is configured
setting of widebandCQI could be sufficient

The appropriate value depends on the type of Network-wide


services, expected scheduling rate to guarantee the
required QoS, and the mobility. These parameters
should be optimized together taking the TDD UL/DL
configuration into consideration
Network-wide

With TRUE reliability of ACK/NACK decreases. With


FALSE ACK/NAK has higher priority in case of a
Network-wide
simultaneous occasion and hence higher reliability
for ACK/NAK.
Samsung Comments QC Comments

After enabling Subband Scheduler, Samsung will


change

Provide timeline to
RJIL
Status
Parameter
TDD FDD
p-b Agreed Agreed

referenceSignalPower Agreed Agreed

p-a Agreed Agreed

nomPDSCH-RS-EPRE-Offset Agreed Agreed

go to Master Sheet
Golden Parameter RJIL/Samsung
TDD FDD TDD FDD
1 1 1 1

15 21 15 21

dB-3 dB-3 dB-3 dB-3

0 0 0 0
Qualcomm View
TDD FDD
1 same

15 21

dB-3 same

0 (except MU MIMO) same


Comments Tune-ability

Network-wide

If set too low, the reference signal quality at the UE


may be unacceptable and negatively impact the
channel estimation. This may deteriorate the
demodulation performance of the various LTE Network-wide
channels such as PBCH, PDCCH, PDSCH which
can ultimately reduce DL throughput and also UL
throughput due to loss of UL grants

Network-wide

Network-wide
Samsung Comments
Status
Parameter
TDD

pollByte Agreed
Agreed
( Samsung Value-8Jan15)
(Need to review Again &
pollPDU continue discussion )
Agreed
( Samsung Value-8Jan15)
(Need to review Again &
t-PollRetransmit continue discussion )

maxRetxThreshold Agreed
Agreed
( Samsung Value-8Jan15)
(Need to review Again &
t-Reordering continue discussion )

t-StatusProhibit Agreed

bucketSizeDuration Agreed

logicalChannelGroup Agreed

prioritisedBitRate Agreed

priority Agreed

go to Master Sheet
Status Golden Parameter
FDD TDD FDD

kBinfinity

plnfinity

ms45

t32

ms35

ms0 ms0
Agreed
ms50 ms50
Agreed
0 0
Agreed

infinity infinity
Agreed
1 for SRB1 1 for SRB1
Agreed 3 for SRB2 3 for SRB2
RJIL/Samsung Qualcomm View
TDD FDD TDD

kBinfinity kBinfinity

pInfinity 32

12 * ( max number of HARQ


ms45 retransmissions -1) + 10ms margin ~60
ms in RJIL case

t32 t32

12 * ( max number of HARQ


ms35 retransmissions -1) + 10ms margin
~60ms in RJIL case

ms0 ms0 ms0


Depends on QoS requirement per
ms50 ms50 radio bearer, set it to 50 ms for BE
traffic.
QoS and eNB scheduler
0 0
implementation dependent

infinity infinity infinity

1 for SRB1 1 for SRB1 Set it in such a way that SRB priority >
3 for SRB2 3 for SRB2 DRB priority
Qualcomm View
FDD

same

same

8*( max number of HARQ retransmissions -1)


+ 10ms margin ~ 40ms

same

8*( max number of HARQ retransmissions -1)


+ 10ms margin ~ 40ms

same

same

same

same

same
Comments Tune-ability

Setting of kBinfinity deactivates triggering a poll due


Network-wide
to the number of bytes in the transmitting PDUs

Setting of Infinity deactivates triggering a poll due to


Network-wide
the number of PDUs

Network-wide

Network-wide

Network-wide

Network-wide

Network-wide

Network-wide

If set it to infinity, it will always be high class, and no


rate control. Infinity is the only possible values for Network-wide
SRB1 and SRB2

Network-wide
Samsung Comments
kBinfinity
It is the default configuration of 3GPP TS 36.331. We
think that pollByte in SRB is not significant since there
are not many packets in SRB. Poll is performed when
it is the last packet in the buffer. Change is
unnecessary.
pInfinity
same as pollByte. Change is unnecessary.

ms45
It is the default configuration of 3GPP TS 36.331.
Since signaling traffic is high priority, it can be
scheduled during 45ms. Change is unnecessary.
t32
same as Qualcomm view.
ms35
It is the default configuration of 3GPP TS 36.331.
Since signaling traffic is high priority, it can be
scheduled during 35ms. Change is unnecessary.
ms0
same as Qualcomm view.
Status
Parameter
TDD FDD

Agreed
( Samsung Value-8Jan15)
(Need to review Again &
pollByte continue discussion )

Agreed
( Samsung Value-8Jan15)
(Need to review Again &
pollPDU continue discussion )

Agreed
( Samsung Value-8Jan15)
(Need to review Again &
t-PollRetransmit continue discussion )

Agreed
( Samsung Value-8Jan15)
(Need to review Again &
maxRetxThreshold continue discussion )

Agreed
( Samsung Value-8Jan15)
(Need to review Again &
t-Reordering continue discussion )

t-StatusProhibit agreed

discardTimer agreed
statusReportRequired agreed agreed

bucketSizeDuration agreed agreed


logicalChannelGroup agreed agreed

prioritisedBitRate agreed agreed

priority agreed agreed

go to Master Sheet
Golden Parameter RJIL/Samsung
TDD FDD TDD FDD

kB50 kB50

p16 p16

ms150
ms200
(eNB Side : ms300)

t32 t32

ms40
ms100
(eNB : ms40)

ms65 ms70

infinity infinity

1 1 1 1

50ms 50ms ms300 50ms


3 3 3 3

kBps8 kBps8 kBps8 kBps8

11 11 11 11
Qualcomm View
TDD FDD

kBinfinity same

32 same

12 * ( max number of HARQ


8*( max number of HARQ retransmissions -1)
retransmissions -1) + 10ms
+ 10ms margin ~ 40ms
margin ~ 60ms

t16 same

12 * ( max number of HARQ


8*( max number of HARQ retransmissions -1)
retransmissions -1) + 10ms
+ 10ms margin ~ 40ms
margin ~ 60ms

ms10 same

Should be set to a value to allow


same
max RLC ARQ retransmissions

1 same

50ms same
QoS and eNB scheduler
same
implementation dependent
With multiple bearers, set to non-
same
infinity value
Set it in according to the QoS
same
requirements for each bearer
Comments Tune-ability

Setting of kBinfinity deactivates triggering a poll due


to the number of bytes in the transmitting PDUs.
Typically, poll triggered by number of PDUs (i.e.
pollPDU) can provide proper trigger of
retransmission.

Network-wide

With a lower value , transmitting RLC-AM entity can


transmit poll too frequently and can lead to
additional bandwidth overhead
Network-wide

With large value, the time required to retransmit a


poll could be larger and this can cause additional
delay in recovering any lost RLC PDUs

Network-wide

For applications with higher layer recovery


mechanisms like BE data a higher value would
result in larger bandwidth overhead for
retransmissions
Network-wide

With large value the time to recover the out of


sequence PDU can be larger due to the delay in
sending the STATUS report
Network-wide
t-StatusProhibit can be smaller or equal to t-
PollRetransmit.
Network-wide

With value of infinity no packets are discarded


Network-wide
TRUE if X2 forwarding is supported Network-wide
With larger value, larger amount of data can be
transmitted on the UL (form the buffer) before the
Bucket level is depleted Network-wide
Network-wide
If set it to infinity, it will always be high class, and no
rate control. Network-wide

Network-wide
Samsung Comments

eNB side : kB50, UE side : kB50


In most cases, pollByte is not triggering condition of status
PDU transmission since poll will be triggered by PollPDU.
Only in case of large RLC PDU, pollByte will be used. If
pollByte is set to infinity, we will receive status PDU by
pollPDU even in the large RLC PDU case. If RLC PDU size
= 4000 Bytes and pollPDU = 32, we have unacked
128KBytes of data. we think that it is too much.

eNB side : p32, UE side : p16


If pollPDU is small, too many status PDU can be a burden
when there are many UEs in a cell. Change is necessary.

eNB side : ms300, UE side : ms130


We determined this parameter in consideration of
scheduling UE capacity per TTI. If this parameter is set
small, RRC connection re-establishment can be occured
due to the frequent retransmission of RLC PDU with pollbit
when there are many UEs in a cell. Change is necessary.

eNB side : t32, UE side : t32


The smaller this parameter, the more RRC connection re-
establishment. Change is unnecessary.

eNB side : ms40, UE side : ms40


We prefer to set small t-reordering parameter. Status PDU
cannot be frequently transmitted due to the short t-
StatusProhibit. Change is necessary.

eNB side : ms65, UE side : ms65


The smaller this parameter, the more Status PDU. It can be
a burden. Change is necessary.
Infinity.
QCI8 traffic is sensitive to the packet loss rather than delay.
Change is unnecessary.

Agreed
Status
Parameter
TDD

Agreed
( Samsung Value-8Jan15)
(Need to review Again &
pollByte continue discussion )
Agreed
( Samsung Value-8Jan15)
(Need to review Again &
pollPDU continue discussion )
Agreed
( Samsung Value-8Jan15)
(Need to review Again &
t-PollRetransmit continue discussion )

maxRetxThreshold agreed

Agreed
( Samsung Value-8Jan15)
(Need to review Again &
t-Reordering continue discussion )

t-StatusProhibit agreed

discardTimer agreed
statusReportRequired agreed

bucketSizeDuration agreed

logicalChannelGroup agreed

prioritisedBitRate agreed

priority agreed

go to Master Sheet
Status Golden Parameter RJIL/Samsung
FDD TDD FDD TDD

kB50 kB50

p16 p16

ms130
ms200
(eNB : ms300)

t32 t32

ms40 ms100

ms65 ms70

infinity infinity

1 1

50ms 50ms ms100


agreed
0 0 0
agreed
kBps8 kBps8 kBps8
agreed
4 4 4
agreed
RJIL/Samsung Qualcomm View
FDD TDD FDD

kBinfinity same

32 same

12 * ( max number of HARQ 8*( max number of HARQ


retransmissions -1) + 10ms retransmissions -1) + 10ms
margin ~ 60ms margin ~ 40ms

t32 same

12 * ( max number of HARQ 8*( max number of HARQ


retransmissions -1) + 10ms retransmissions -1) + 10ms
margin ~ 60ms margin ~ 40ms

ms10 same

Should be set to a value to allow


same
max RLC ARQ retransmissions
1 same

50ms 50ms same

QoS and eNB scheduler


0 same
implementation dependent
kBps8 Set to infinity value same
Set it according to the QoS
4 requirements for each bearer same
( QCI 5 > QCI1 > QCI8)
Comments Tune-ability
Setting of kBinfinity deactivates triggering a poll due
to the number of bytes in the transmitting PDUs.
Typically, poll triggered by number of PDUs (i.e. Network-wide
pollPDU) can provide proper trigger of
retransmission.

With a lower value , transmitting RLC-AM entity can


transmit poll too frequently and can lead to Network-wide
additional bandwidth overhead

With large value, the time required to retransmit a


poll could be larger and this can cause additional Network-wide
delay in recovering any lost RLC PDUs

Network-wide

With large value the time to recover the out of


sequence PDU can be larger due to the delay in Network-wide
sending the STATUS report

t-StatusProhibit can be smaller or equal to t-


Network-wide
PollRetransmit.

With value of infinity no packets are discarded Network-wide

TRUE if X2 forwarding is supported Network-wide


With larger value, larger amount of data can be
transmitted on the UL (form the buffer) before the Network-wide
bucket level is depleted

Network-wide

If set it to infinity, it will always be high class, and no


Network-wide
rate control.
Network-wide
Samsung Comments

eNB side : kB50, UE side : kB50


same as QCI8.

eNB side : p16, UE side : p16


There are not many packets in QCI5. Change is
unnecessary.

eNB side : ms300, UE side : ms130


same as QCI8.

eNB side : t32, UE side : t32


same as Qualcomm view.

eNB side : ms40, UE side : ms40


same as QCI8.

eNB side : ms65, UE side : ms65


same as QCI8.

Infinity. QCI5 traffic is sensitive to the packet loss.


Change is unnecessary.

Agreed
Status
Parameter
TDD
Agreed
( Samsung Value-8Jan15)
(Need to review Again &
t-Reordering continue discussion )

sn-FieldLength (ul-UM-RLC) agreed

sn-FieldLength (dl-UM-RLC) agreed

Agreed
( Samsung Value-8Jan15)
(Need to review Again &
discardTimer continue discussion )

headerCompression agreed

pdcp-SN-Size agreed

bucketSizeDuration agreed

logicalChannelGroup agreed
Agreed
( Samsung Value-8Jan15)
(Need to review Again &
prioritisedBitRate continue discussion )

priority agreed

go to Master Sheet
Status Golden Parameter RJIL/Samsung
FDD TDD FDD TDD

ms40 ms100

size5 size10

size5 size10

ms300 ms100

Used notUsed

len7bits len12bits

50ms 50ms ms100


agreed
2 2 2
agreed

kBps8 kBps8 kBps8


agreed
5 5 5
agreed
RJIL/Samsung Qualcomm View
FDD TDD FDD

8*( max number of HARQ 8*( max number of HARQ


retransmissions -1) + 10ms retransmissions -1) + 10ms
margin margin ~ 40ms

size5 same

size5 same

Delay budget for specific QCI


same
(100ms) + 50ms margin

Should be enabled for QCI 1


same
bearer

len7bits same

ms50 50ms same

QoS and eNB scheduler


2 same
implementation dependent

kBps8 infinity same

Set it in according to the QoS


5 requirements for each bearer same
( QCI 5 > QCI1 > QCI8)
Comments Tune-ability

With larger value, the delay to deliver the received


RLC SDU to the higher layer would be large
Network-wide
With value of size10, the bandwidth overhead for
sending the sequence number in the PDU would be
higher Network-wide
With value of size10, the bandwidth overhead for
sending the sequence number in the PDU would be
higher Network-wide

Network-wide

Network-wide
With len12bits the bandwidth overhead for sending
the sequence number would be higher
Network-wide
With larger value, larger amount of data can be
transmitted on the UL (form the buffer) before the
bucket level is depleted Network-wide

Network-wide

With multiple bearers, set value for QCI to infinity


Network-wide

Network-wide
Samsung Comments
eNB side : ms40, UE side : ms40
To waiting max HARQ retransmission, Samsung
recommends the value of QCI1 t-reordering timer
40msec.

size5
To reduce the overhead, Samsung recommends size5

size5
To reduce the overhead, Samsung recommends size5

ms300
We cannot commit that packet transmitted after 150ms
is not help to enhance the voice quality. Also, Keeping
additional 150ms is not demanding work.

Samsung supports RoHC for QCI1 bearer.


len7bits
To reduce the overhead, Samsung recommends
len7bits

agreed

If we set the value to infinity, the transmission for


IMS(QCI1) may be delayed so that the call release
happens
Parameter Status

2300 only

Priority agreed

Snonintrasearch agreed

Threshserving, low agreed

Qrxlevmin (inter-frequency) agreed

Qrxlevmin (intra-frequency) agreed

q-RxLevMinOffset agreed

Agreed parameter(QC
Value)
Sintrasearch
(Need to review Again with
real Traffic )
Agreed parameter(QC
Value)
QHyst
(Need to review Again with
real Traffic )

Qoffsets,n (intra-frequency) agreed

Qoffsetfrequency agreed

Qoffsets,n ( inter-frequency) agreed

TreselectionEUTRAN agreed

go to Master Sheet
Status Golden Parameter

2300 + 1800 2300 only 2300 + 1800

not used

not used

not used

not used

agreed -128 dBm -129 dBm

agreed Not Used Not Used

40 dB
2 dB

agreed dB0 dB0

not used

agreed dB0 dB0

agreed 1 sec 1 sec


RJIL/Samsung Qualcomm View

2300 only 2300 + 1800 2300 only

not used not used

not used not used

not used not used

not used not used

-64 (-128 dBm) -64 (-128 dBm) -128 dBm

Not Used Not Used Deployment dependant

31 (62 dB) 40 dB
0 dB 2-4 dB

dB0 (Depends on deployment


dB0 dB0
strategy)

not used

dB0 (Depends on deployment


dB0 dB0
strategy)

1 sec 1 sec 1-2 seconds


Qualcomm View

2300 + 1800

"equal priority" for 2300 and 1800

2300 => 23dB


1800 => 48dB

not used

2300 => not used


1800 =>110 dBm

same

same

same
2300 - 4dB
1800 - 4dB

same

2300 => 6dB


1800 => -14dB

same

same
Comments Tune-ability

Based on the proposed layer management strategy

Based on the proposed layer management strategy. UEs do not


prefer one over other
UE on 2300 starts inter-freq measurement below -105dBm
UE on 1800 starts inter-freq measurements below -80dBm

Disallow reselection from B3 to B40 when B40 < -110dBm

UE will perform initial camping to any cell with RSRP better than
Network-wide
-128 dBm.

q-RxLevMinOffset is used to bias the camping of the UE towards


a specific cell. It is applied when a cell is evaluated for cell Tunable - based on
selection during UE higher priority PLMN search while camped on deployment needs
a VPLMN

UE will start measurements for reselection below RSRP of around


-66 dBm. This is not desirable as it would have significant impact Network-wide
on UE stand-by time.
With lower value, UE may perform frequent cell reselection to
cells only marginally better than the current serving cell, which
may lead to excessive battery consumption and frequent ping- Tunable - based on
pongs. It may be better to start with 2dB and observe number of cluster, venue
reselections in the test cluster and move to 4dB if there are large deployment needs
number of very frequent handovers. This parameter shall be
optimized along with TreselectionEUTRAN

Tunable - based on
deployment needs
Along with Qhyst of 4dB on both B40 and B3, this will ensure a
positive bias of 10dB towards B40. B40 to B3 reselection would
be triggered only when B40 is worse than B3 by 10dB or more
and B3 to B40 reselection would be triggered when B3 is better
than B40 by 10dB or lower
Tunable - based on
deployment needs
Tunable - based on
A lower value can potentially cause higher chances of UE ping-
cluster, venue
pong between cells. This shall be optimized along with QHyst
deployment needs
Samsung Comments QC Comments

From our test results, attach is more likely be


succesful even under RSRP -120dBm.
If Qualcomm shares criteria of reliable uplink tx, we
can discuss more

Agree, we need to change after studying RJIL NW


RF environment.
From Vellore CLOT test, inter-sector HO happens
around -70dBm RSRP. When considering that
Vellore is a small city, current setting is sufficient.

90% of the time RSRP at


HO is less than -80dBm.
-80dBm or lower makes
sense
It is trade-off of RF quality and Ping-pong. Not much
big difference.

Hysterisis can reduce


ping pongs

It is trade-off of RF quality and Ping-pong. Not much


big difference.
Samsung Comments (26, Dec)

if we consider 90% and change this value, 10%


handover near site will miss and it cause RLF.
If QC team is concerning on battery, could you
share the your analysis?
In fact, Hysteresis does not work to reduce
Pingpong, MR is triggered right after meeting the
entering condition of A3 event. So, the sum of A3
offset and Hysteresis is important.
QC Comments

UE battery life is a key feature and hence we


have to have a trade-off. We do not see
using 40dB ( = -88dBm) causing RLF issues
– RLF would be in connected mode. In good
RF conditions, after the UE initiates the
connection it would move to the best cell in
case the current one is not the best via
Handover. In not so good RF conditions UE
will anyways measure and will be on the best
possible cell. UE Tx power distribution at
handoff may also be considered
This concerns idle mode cell-reselection for
which the criteria is that the quality of intra-
frequency neighbor must be (Qhyst +
Qoffset) dB better than the serving cell for
Treselection seconds for reselection. A3
offset/A3hysteresis and MR applies to only
connected mode – UE doesn’t send MR in
idle mode.
Status
Parameter
TDD FDD

S-Measure agreed agreed

triggerType
(Measurement Report Trigger agreed agreed
Type)
triggerQuantity
agreed agreed
(Measurement Trigger Quantity)
reportQuantity
agreed agreed
(Measurement Report Quantity)
filtercoefficientRSRP agreed agreed
filtercoefficientRSRQ agreed agreed
timeToTrigger
agreed agreed
(Event A3 Time to Trigger)
a3-Offset (Event A3 Offset) agreed agreed
hysteresis
agreed agreed
(Event A3 Hysteresis)
reportInterval
agreed agreed
(Event A3 Reporting Interval)
reportOnLeave
agreed agreed
(Event A3 Report on Leave)
maxReportCells
agreed agreed
(Event A3 Maximum Number of
Reported Cells)

reportAmount
agreed agreed
(Event A3 Number of Reports)

T304 agreed agreed

go to Master Sheet
Golden Parameter RJIL/Samsung
TDD FDD TDD FDD

97 97 97 97

 Event  Event  Event  Event

RSRP RSRP RSRP RSRP

both both both both

fc4 fc4 fc4 fc4


fc4 fc4 fc4 fc4
256 ms 256 ms 256 ms 256 ms

3 dB 3 dB 3 dB 3 dB

0 dB 0 dB 0 dB 0 dB

240 ms 240 ms 240 ms 240 ms

0 0 0 0

8 8 8 8

r8 r8 r8 r8

1000ms 200 ms 200 ms 200 ms


Qualcomm View
TDD FDD

Event

RSRP

Same As the Trigger


Quantity

fc8-11
fc8-11
320 ms

Adjust by deployment needs

2 dB

240 ms

4 to 6

Infinity

1000ms
Comments Tune-ability

It should be a set to a value where the UE measures


neighbor cells always so that it is served by the best Network-wide
cell. Both 0 and 97 causes almost similar behavior

Network-wide

HO location maintained with using RSRP as the trigger Network-wide

When set to same as trigger quantity, only the same


quantity which triggered the report is included and
Network-wide
hence marginally reduce the size of the measurement
report  

These parameters should be tuned together based on


deployment needs after detailed performance analysis Tunable - based on
for the cluster, venue deployment needs. Total offset of cluster, venue
3dB with a3-Offset and hysterisis should be good to deployment needs
start with

Network-wide

Higher value leades to higher UE processing power


Network-wide
and may lead to poorer battery talk-time

A lower value of this parameter might lead to


delayed handover and hence performance impact
Network-wide
incase previous measurements have not reached
the eNB
A lower value for T304 may not be enough to
Tunable - based on
complete the RACH process in some scenarios.
RACH performance for
This parameter should be optimsed on mobility
handover
drive test data
Samsung Comments

RSRQ information will be missing. With scarificing of


MR size, we'd better have RSRQ, as well
OK

It does not affect too much, most of MR have less


than 4 neihgbor lists.

If RJIL wants to change to Infinity, no objection.


But, most of HO command is transmitted before 8 OK
consecutive MRs.

already changed to 1000ms from 200ms.


But we will reduce it and find the optimized value.
Parameter status

Event-A1 Thresh

Event-A1 Hysterisis

Event-A2 Thresh

Event-A2 Hysterisis

a3-Offset (Event A3 Offset)

hysteresis (Event A3 Hysteresis)

Ofn

Event-A5 Thresh1

Event-A5 Thresh2

Event-A5 Hysterisis

timeToTrigger (for all events)


go to Master Sheet
Golden Parameter RJIL/Samsung Qualcomm View

-101 dBm

2dB

-103 dBm

2dB

3 dB

2 dB

-10 dB

-108 dBm

-109 dBm

2dB

320 ms
Comments Tune-ability

Disable meas gaps when B40 > -99dBm

Configure meas gaps when B40 < -105dBm

Trigger A3 event when B3 is 15dB better than B40

Trigger A5 event when B40 is lower than -110dBm and


B3 is above -107dBm
Samsung Comments QC comments
Parameter status

Event-A1 Thresh

Event-A1 Hysterisis

Event-A2 Thresh

Event-A2 Hysterisis

a3-Offset (Event A3 Offset)

hysteresis (Event A3 Hysteresis)

Ofn

Event-A5 Thresh1

Event-A5 Thresh2

Event-A5 Hysterisis

timeToTrigger (for all events)


go to Master Sheet
Golden Parameter RJIL/Samsung Qualcomm View

-101 dBm

2dB

-103 dBm

2dB

3 dB

2 dB

0 dB

-108 dBm

-109 dBm

2 dB

320 ms
Comments Tune-ability

Disable meas gaps when B3 > -99dBm

Configure meas gaps when B3 < -105dBm

Trigger A3 event when B40 is 5dB better than B3

Trigger A5 event when B3 is lower than -110dBm and


B40 is above -107dBm
Samsung Comments QC comments
Parameter status

Event-A1 Thresh

Event-A1 Hysterisis

Event-A2 Thresh

Event-A2 Hysterisis

a3-Offset (Event A3 Offset)

hysteresis (Event A3 Hysteresis)

Ofn

Event-A4 Thresh

Event-A4 Hysterisis

Event-A5 Thresh1

Event-A5 Thresh2

Event-A5 Hysterisis

timeToTrigger (for all events)


go to Master Sheet
Golden Parameter RJIL/Samsung Qualcomm View

-91 dBm

2dB

-93 dBm

2dB

3 dB

2 dB

0 dB

-90 dBm

-5 dB

-108 dBm

-109 dBm

2 dB

320 ms
Comments Tune-ability

Disable meas gaps when B3 > -89dBm

Configure meas gaps when B3 < -95dBm

Trigger A3 event when B40 is 5dB better than B3

Trigger A4 event to HO to small cell when B40


neighbor small cell is better than -85dBm

Trigger A5 event when B3 is lower than -110dBm and


B40 is above -107dBm
Samsung Comments QC comments
Status
Parameter
TDD FDD
defaultPagingCycle agreed agreed
nB agreed agreed

go to Master Sheet
Golden Parameter RJIL/Samsung
TDD FDD TDD FDD
1280 ms 1280 ms 1280 ms 1280 ms
1T 1T 1T 1T
Qualcomm View
TDD FDD
rf128 (1280 ms) same
oneT same
Comments Tune-ability
Network-wide
With low paging load even 1/4 could be enough to start
Network-wide
with
Samsung Comments
Status
Parameter
TDD FDD

T300 agreed agreed

T301 agreed agreed

T310 agreed agreed

N310 agreed agreed

N311 agreed agreed


T311 agreed agreed

go to Master Sheet
Golden Parameter RJIL/Samsung
TDD FDD TDD

200 ms 200 ms 200 ms

1000ms 1000ms 200 ms

1000 ms 1000 ms 1000 ms

n10 n10 n10

n1 n1 n1
3000 ms 3000 ms 3000 ms
RJIL/Samsung Qualcomm View
FDD TDD FDD

200 ms 600 ms same

200 ms 1000 ms same

Lower than 1000ms for VoLTE


1000 ms same
networks

Lower than n10 for VoLTE


n10 same
networks

n1 n1 same
3000 ms 3000 ms same
Comments Tune-ability

A lower value for T300 may cause the UE to stop


the RRC conncection prematurely without getting
enough time to complete any RACH Contention Tunable - based on
Resolution. It is recommended to start with a higher RACH performance
value and move to a lower value after achieving
good RACH performance

A lower value for T301 may not be enough for the


UE to complete any RACH Contention Resolution
and receive network response in some cases. It is
Tunable - based on
recommended to start with a higher value and move
RACH performance
to a lower value after achieving good RACH
performance. This parameter shall be optimized
based on mobility drive tests

A lower value is recommended for networks with


VoLTE services so as to improve the user
experience via quicker RRC Connection re-
establishment
Tunable - based on RLF
A lower value is recommended for networks with performance analysis
VoLTE services so as to improve the user
experience via quicker RRC re-establishment
Samsung Comments

T300 timer to define how long the UE waits for a response to the RRC
Connection Request message.
After checking the current performance of RRC connection time, we can
disucss to change T300
From, Vellore CLOT test, distribution of time gap between Msg4 and Msg
3 is showing right figure.
Every sample is less than 160ms. So, 600ms seems too high.

already changed to 1000ms from 200ms.


But we will reduce it and find the optimized value same as T304.

Agree to the logic it can reduce RRC reestablishment time.


We need to do the test with shorter value.

Agree to the logic it can reduce RRC reestablishment time.


We need to do the test with shorter value.
Optimize based on further field
study

OK

OK

OK
Status
Parameter
TDD FDD
maxCID agreed agreed
profile0x0001 agreed agreed
profile0x0002 agreed agreed

go to Master Sheet

,
Golden Parameter RJIL/Samsung
TDD FDD TDD FDD
15 15 15 15
1 1 1 1
1 1 1 1
Qualcomm View
TDD FDD
15 same
1 same
1 same
Comments Tune-ability
Network-wide
Network-wide
Network-wide
Samsung Comments
Status Golden Parameter
Parameter
TDD FDD TDD

drx-Config agreed agreed setup

drx-InactivityTimer agreed psf30

onDurationTimer agreed psf8

drx-RetransmissionTimer agreed agreed psf8

longDRX-Cycle agreed sf20

go to Master Sheet

,
Golden Parameter RJIL/Samsung Qualcomm View
FDD TDD FDD TDD

BE - Not enabled
setup setup setup
VoLTE - setup

VoLTE - psf5 for VoLTE/streaming


psf30
psf100 traffic

psf8 for VoLTE/streaming


VoLTE - psf10 psf8
traffic

psf8 VoLTE - psf16 psf8 psf10 for VoLTE

VoLTE - sf20 sf20 sf20 for VoLTE


Qualcomm View
Comments
FDD
With C-DRX not enabled for default bearer , UE's
same will not be able to benefit from battery savings on
default bearer - BE data
With setting to a high value, UE is less probable to
go into a DRX mode. For VoLTE, AMR voice frames
2ms are generated every 20ms. Setting of 100ms may
not allow the UE to enter the DRX state to benefit
from battery savings

BE traffic -> for TDD, set it to the max consecutive #


of subframes in one radio frame corresponding to
the UL/DL configuration.
2ms
VoLTE/streaming traffic-> for TDD set to the min
number of consecutive # subframes in one radio
frame corresponding to the UL/DL configuration

For TDD, set it to the max number of HARQ


<= 8ms
processes supported for the UL/DL configuration.

320 ms
Tune-ability Samsung Comments

Network-wide Agree

Network-wide Agree

Network-wide Agree

Network-wide Agree

Network-wide

You might also like