TE-RAN
2/2/2016
Contents
1 Mobility Design ................................................................................................................... 1
1.1 Service Motivation........................................................................................................ 1
1.2 Scope .......................................................................................................................... 2
1.3 Inputs........................................................................................................................... 2
1.4 Outputs ........................................................................................................................ 2
1.5 Strategy ....................................................................................................................... 2
1.5.1 Intra-frequency
Intra-frequency LTE HO Strategy.......................................................................... 3
1.5.2 Inter-frequency
Inter-frequency LTE HO Strategy.......................................................................... 3
1.5.3 SRVCC HO Strategy............................................................................................12
1.6 Responsibility
Responsibility matrix ...................................................................................................17
1 Mobility Design
Description:
The objective of this service module is to provide a low-level design for new
mobility features for VoLTE introduction as well as modifications to existing
mobility features to cater for VoLTE introduction
1.2 Scope
This solution document will focus on VoLTE mobility design recommendations only
for radio network consisting of Ericsson eNodeBs.
1.3 Inputs
2. Site Database
3. Parameter Settings
4. Activated Features
1.4 Outputs
1. Intra-frequency
Intra-freq uency LTE HO strategy: Features and Parameter Settings
2. Inter-frequency
Inter-freq uency LTE
LTE HO strategy : Features and Parameter Settings
1.5 Strategy
VoLTE deployment does not need a change in the legacy CSFB configuration.
CSFB to be maintained in areas where VoLTE yet to be deployed and also in
VoLTE areas for non-VoLTE capable UEs.
VoLTE and CSFB can co-exist depending on the existing VoLTE deployment
scenario as shown below:
VoLTE enabled UEs will perform VoLTE and then SRVCC in poor
coverage
B. Non-VoLTE capable UEs will still need to use CSFB in VoLTE area
VoLTE
VoLTE Mobil
Mobility
ity
Design Flowchart.
Flowchart. pdf
1.5.1 Intra-frequency
Intra-fr equency LTE HO Strategy
1.5.2 Inter-frequency
Inter-fr equency LTE HO Strategy
1.5.2.1 Coverage-Triggered
Coverage-T riggered Mobility
Mobility between LTE frequencies is only possible for VoLTE calls, QCI1 traffic, if
the feature FAJ 121 0877 Coverage Triggered Inter-Frequency Handover is
Handover is
active in the network. If the feature FAJ 121 0797 Coverage-Triggered Inter-
Frequency Session Continuity is
Continuity is only used in the network, then VoLTE calls will
not be able to perform any LTE Inter-Frequency Handover. In this case QCI1
connection would remain on the source LTE frequency in poor coverage and
eventually drop.
The two events for coverage triggered inter-frequency mobility, namely Event A2
and A5 can have QCI specific offsets applied to them using the feature Service
Triggered Mobility. Using the feature Multi-Layer Service-Triggered Mobility,
events A2 and A5 can have different threshold offset values for QCIs as well as for
different frequency relations. This feature overrides the Service Triggered Mobility
feature when both features are activated.These offsets can be either positive or
negative giving flexibility in where VoLTE mobility would be performed compared
to MBB mobility.
Each QCI profile holds offsets for the thresholds for Event A1, Event A2, Event A5,
and Event B2. This makes it possible to have different coverage triggered mobility
thresholds for different traffic types.
The below equations show the offsets the Service Triggered Mobility introduce and
how these affect normal coverage threshold events.
Note: In the below equations the RSRP thresholds are only referenced however
the same applies if RSRQ thresholds are used.
E vent A 2 Threshold:
Threshold:
+ ℎ2
ℎ2 < 2ℎℎ
2ℎℎ
With Service Triggered Mobility
+ ℎ
ℎ2
2
< 2ℎℎ
2ℎℎ +
E vent A 5 Threshold:
Threshold:
QCI Profile 1:
+ ℎ
ℎ5
5
< 5ℎℎ1 +
− ℎ
ℎ5
5
> 5ℎℎ2 +
The main benefit of this feature is the possibility to tune different services and
frequency relations with different threshold offset values for A2 and A5 events.
This feature overrides the Service Triggered Mobility feature when both features
are activated.
By configuring thresholds per target frequency relation, this feature can
differentiate bad coverage behavior on target frequency.
A1A2SearchThreshol
A1A2SearchThresholdXQCI=Repo
dXQCI=ReportConfigS
rtConfigSearch.a1a
earch.a1a2SearchTh
2SearchThresholdX
resholdX +
ReportConfigSearch. qciA1A2ThrOffsets<qci> .a1a2ThrXQciOffset
If an operator does not want to tune different service with different QCI specific
threshold offset, the threshold offset parameter, in this example,
a1a2ThrXQciOffset in each QCI profile instance qciA1A2ThrOffsets can be set to
0 as default value.
UE’s event A5 threshold1, when the Multi -Layer Service-Triggered Mobility feature
is activated, is calculated in accordance with the following:
A5Threshold1XQCI
A5Threshold1XQCI = ReportConfigA5.a5Th
ReportConfigA5.a5Threshold1X
reshold1X +
EUtranFreqRelation.a5Thr1XFreqOffset +
EUtranFreqRelation.eutranFreqToQciProfileRelation<qci>.a5Thr1XFreqQciOffset
Calculation formulae for the A2 and A5 thresholds are shown below:
It has been seen in live test results that the voice service area in a new VoLTE
network can be smaller than that of MBB service area. It is expected that the
service triggered mobility offsets could get set to a positive value in the range of 2
to 6 dB based on drive test measurements in the tuning phase of the VoLTE
deployment. But in early stages of network it is recommended to set these offsets
to 0 and then tune from there based on network performance after VoLTE launch.
VoLTE connections will not be subject to the critical threshold in Mobility Control at
Poor Coverage in that the connection will not be released and redirected at the
critical threshold unlike MBB connections. However, if Mobility Control at Poor
Coverage is enabled in a pre-VoLTE LTE network, then the Event A1 and Event
A2 threshold
threshold parameters
parameters are replaced
replaced by the search
search thresholds
thresholds as introduced
introduced by
Mobility Control at Poor Coverage. These thresholds will be subject to Service
Triggered Mobility offsets. It is important to be aware of this when designing the
mobility strategy.
E vent A 2
+ ℎ
ℎ2
2
< 2ℎℎ
2ℎℎ + 2ℎℎ
2ℎℎ
With Mobility Control at Poor Coverage
+ ℎ
ℎ2
2
<
+ 2ℎℎ
2ℎℎ
If the UE has an active bearer with QCI1 indicating a voice bearer, a release of the
UE is not allowed and the eNodeB takes no further action, that is, the UE remains
in the cell and waits for another Target Good Enough, Good Coverage, Critical
Coverage or possibly Search Zone measurement report. This can be changed by
setting parameter allowReleaseQci1
allowReleaseQci1 to TRUE, but this parameter only has any
effect when feature SRVCC
feature SRVCC Handover to UTRAN is not OPERABLE. Note that if
the eNodeB performs a release with redirect, the default behavior in a Core
Network is to remove the voice connection .
VoLTE Considerations
∆
∆ > ℎℎ
> 5ℎℎ2
Where
∆
∆ = −
[9 ∗
[
9]
=
In a pre-VoLTE LTE network where only one QCI profile is present, the
subscription ratio is only affected by one QCI type’s contribution. Also the
parameters qciSubscriptionQuanta and cellSubscriptionQuanta are probably
optimized for MBB traffic only.
[
[ ∗
] + [9 ∗
9]
=
The contribution of VoLTE traffic will now affect when the load balancing condition
will be met i.e. as VoLTE traffic increases, the load balancing condition will be
entered earlier if no modification to the existing qciSubscriptionQuanta and
cellSubscriptionQuanta parameters is made.
Alternatively,
Alternatively, it could be decided
decided to remove
remove the contribution
contribution of QCI 1 traffic from
the load balancing calculation. This can be achieved by setting
qciSubscriptionQuanta=0.
When load balancing condition is entered, any UE that qualifies for load
balancing will only move to the target frequency when the target cell’s RSRP is
greater than a5Threshold2Rsrp. To avoid ping-pong though from load balancing
and then nor mal coverage-triggered inter-frequency handover, it is
recommended to set this threshold at least 10dB higher than that of
a2ThresholdRsrp.
The operator can choose whether to use Automated Cell Capacity Estimation
feature in Load Management features by setting useEstimatedCellCap.
useEstimatedCellCap. If
If the
operator chooses to use this feature in Load Management features, these
features will use the attribute dynCellSubscrCap
(EUtranCellFDD.dynCellSubscrCap or EUtranCellTDD.dynCellSubscrCap)
instead of cellSubscriptionCapacity to assess the subscription ratio.
Setting the lbThreshold to a low value will prevent large bursts of load balancing.
It is recommended to keep this at the default value of 3%.
RECOMMENDATIONS:
- Set qciSubscripti
qciSubscriptionQuanta
onQuanta and cellSubscript
cellSubscriptionCapacity
ionCapacity to values
mirroring the minimum expected throughputs per service and the
achievable cell but rate at high cell load.
- If a QCI type is to be ignored from the load balancing calculation then set
qciSubscriptionQuanta=0
- Set a5Thresho
a5Threshold2Rsr
ld2Rsr to a value at least 10db reater than A2 threshold
When the load balancing condition is met for Inter-Frequency Load balancing, UEs
are randomly selected to be moved to the target frequency. However, if we want to
exclude QCI1 from performing any load based handover, the feature Service
Specific Load Management can be activated.
1.5.2.2.2 FAJ 121 3047 Service Specific Load Management
Using thuis feature, we can inhibit either QCI 1 or QCI9 (MBB) connections from
performing a load based handover. This is controlled by the struct
EUtranFreqRelation::eutranFreqToQciProfileRelation. In this struct the parameter
lbQciProfileHandling will instruct which QCI profiles are allowed or not allowed for
load balancing action. This parameter can have the following values:
For example, if it is required that only QCI 9 traffic is subjecedt to a load based
handover then its profiles lbQciProfileHandling value would be set to REQUIRED
and all other QCI profiles would be set to FORBIDDEN.
RECOMMENDATIONS:
- If Service Specific Load Management is to be deployed, it’s recommended
to forbid QCI 1 traffic from performing load based handover and then
review this strategy in optimization phase. This is achieved by setting
lbQciProfileHandling=FORBIDDEN for QCI1 profile
- If Service Specific Load Management is to be deployed, and QCI 1 profile
is allowed to perform load based handover, then it’s recommende d to set
the value
value lbA5Threshold2RsrpOffset to the same value as
a2ThresholdRsrpPrimOffset.
1.5.3 SRVCC HO Strategy
The SRVCC Handover features enables the eNodeB to use handover as the
mechanism to transfer User Equipment (UE) with voice bearers from LTE to either
WCDMA or GSM; with the voice bearers being handed over to the Circuit
Switched (CS) domain.
1.5.3.1 FAJ 121 2027 SRVCC to UTRAN & FAJ 121 3014 SRVCC to GERAN
Events A2 and B2 which are used for SRVCC can have QCI specific offsets
applied to them using the feature Service Triggered Mobility. If the feature Multi-
Layer Service-Triggered Mobility is activated, events A2 and A5 can have different
threshold offset values for QCIs as well as for different frequency relations.
relations. This
feature overrides the Service Triggered Mobility feature when both features are
activated.These offsets can be either positive or negative giving flexibility in where
VoLTE mobility would be performed compared to MBB mobility
Event B2 Threshold
Threshold (Mobility
(Mobility to UTRAN only shown here as example):
QCI Profile 1:
RSRPvng + hysteresis
hysteresisB2
B2 < b2Threshol
b2Threshold1Rsr
d1Rsrpp + b2Threshol
b2Threshold1Rsr
d1RsrpUtr
pUtraOffs
aOffset
et QI
QI
AND
RSCPg − hysteresi
hysteresisB2
sB2
> b2Threshold2RscpUtra
b2Threshold2RscpUtra + b2Threshold2RscpUtraOffset
b2Threshold2RscpUtraOffset QI
QI
SRVCC Failure
Troubleshooting.pptx
Inter-RAT offload feature can be used to hand over traffic load above a configured
threshold from an over-utilized E-UTRAN cell to a configured set of UTRAN-FDD
cells with extra capacity. The amount of offload to a specific target UTRAN cell is
proportional
proportional to the
the lbUtranCellOffloadCapacity parameter of that target UTRAN
cell .This feature is an add-on to feature Inter-frequency Load Balancing. These
two features can either be operated stand-alone, or one at a time or in
combination to attain simultaneous inter-frequency load balancing and inter-RAT
offload.
a1ThresholdRsrpSecOffset,a1ThresholdRsrqPrimOffset,a1ThresholdRsrqSecOffset,a2Thres
holdRsrpPrimOffset,a2ThresholdRsrpSecOffset,a2ThresholdRsrqPrimOffset,a2ThresholdRs
rqSecOffset,a5Threshold1RsrpOffset,a5Threshold1RsrqOffset,a5Threshold2RsrpOffset,a5T
hreshold2RsrqOffset,b2Threshold1RsrpUtraOffset,b2Threshold1RsrpCdma2000Offset,b2Th
reshold1RsrpGeranffset,b2Threshold1RsrqUtraOffset,b2Threshold1RsrqCdma2000Offset,b2
Threshold1RsrqGeranOffset,b2Threshold2Cdma2000Offset,b2Threshold2GeranOffset,b2Th
Service Triggered Mobility reshold2EcNoUtraOffset,b2Threshold2RscpUtraOffset
a1a2ThrRsrpQciOffset,a1a2ThrRsrqQciOffset,a5Thr1RsrpFreqOffset,a5Thr1RsrqFreqOffset,a
5Thr2RsrpFreqOffset,a5Thr2RsrqFreqOffset,a5Thr1R
5Thr2RsrpFreqOffset,a5Thr2RsrqFreqOffset,a5Thr1RsrpFreqQciOffset,
srpFreqQciOffset, a5Thr1RsrqFreqQc
a5Thr1RsrqFreqQciOf
iOf
fset,a5Thr2RsrpFreqQciOffse
fset,a5Thr2RsrpFreqQciOffse t,a5Thr2RsrqFreqQciOffset,b2Thr1RsrpU
t,a5Thr2RsrqFreqQciOffset,b2Thr1RsrpUtraFreqOffset,b
traFreqOffset,b 2Thr1R
2Thr1R
srqUtraFreqOff
srqUtraFreqOff set,b2Thr2EcNoUtr
set,b2Thr2EcNoUtraFreqOffse
aFreqOffse t,b2Thr2RscpU
t,b2Thr2RscpUtraFreqOffset,
traFreqOffset, b2Thr1RsrpUtr
b2Thr1RsrpUtraFr
aFr
eqQciOffse t,b2Thr1RsrqUtr
t,b2Thr1RsrqUtraFreqQciOffset,
aFreqQciOffset, b2Thr2EcNoU
b2Thr2EcNoUtraFreqQciOffset,b2Thr2Rsc
traFreqQciOffset,b2Thr2RscpUtraFr
pUtraFr
eqQciOffset,b2Thr1RsrpUtraFreqOffset,b2Thr1RsrqUtraFreqOffset,b2Thr2RscpUtraFreqOffs
Multi-Layer Service Triggered Mobility et,qciB2ThrOffsets,b2Thr1RsrpUtraFreqQc
et,qciB2ThrOffsets,b2Thr1Rsr pUtraFreqQciOffse
iOffse t,b2Thr1RsrqUtr
t,b2Thr1RsrqUtraFreqQciOffset,b
aFreqQciOffset,b 2Thr2EcN
2Thr2EcN
oUtraFreqQciOffse
oUtraFreqQciOffse t,b2Thr2RscpU
t,b2Thr2RscpUtraFreqQciOffset,b2Thr1RsrpCdma2
traFreqQciOffset,b2Thr1RsrpCdma2000000FreqOffse
FreqOffse t,b2Thr1
RsrqCdma2000Fr
RsrqCdma2000FreqOff
eqOff set,b2Thr2Cdma200
set,b2Thr2Cdma2000FreqOffset,q
0FreqOffset,q ciB2ThrOffsets,b
ciB2ThrOffsets,b 2Thr1RsrpCdma2
2Thr1RsrpCdma20 0
00FreqQciOffse
00FreqQciOffse t,b2Thr1RsrqCdma20
t,b2Thr1RsrqCdma2000Fr00FreqQciOffse
eqQciOffse t,b2Thr2Cdma20
t,b2Thr2Cdma2000Fr
00FreqQciOffse
eqQciOffse t,b2Thr
1RsrpCdma20001xFreqOffset,b2Thr1RsrqCdma20001xFreqOffset,b2Thr2Cdma20001xFreqOf
fset,b2Thr1RsrpGeranFreqOffset,b2Thr1RsrqGeranFreqOffset,b2Thr2GeranFreqOffset,qciB
2ThrOffsets,b2Thr1RsrpGeranFreqQciOffset,b2Thr1RsrqGeranFreqQciOffset,b2Thr2GeranFr
eqQciOffset
a1a2SearchThresholdRsrp,a1a2SearchThresholdRsrq,hysteresisA1A2SearchRsrp,hysteresisA
1A2SearchRsrq,searchEffortTime,timeToTriggerA1Search,timeToTriggerA2
1A2SearchRsrq,searchEffortTime,timeToTriggerA1Search,timeToTriggerA2Search,a2Critical
Search,a2Critical
Mobility Control at Poor Coverage
ThresholdRsrp,a2CriticalThresholdRsrq,hysteresisA2CriticalRsrp,hysteresisA2CriticalRsrq,ti
meToTriggerA2Critical,ueMeasurementsActiveIF,ueMeasurementsActiveUTRAN,ueMeasur
ementsActiveGERAN,ueMeasurementsActiveCDMA2000
Inter-Frequency
Inter-Frequency Load
Load Balancing
Balancing lbThreshold,lbceiling,qc
lbThreshold,lbceiling,qciSubscr
iSubscriptionQua
iptionQuanta,c
nta,cellSubscr
ellSubscriptionCapa
iptionCapacity
city
Service Specific Load Management
Management lbQciProfileHandling
lbQciProfileHandling ,lbA5Threshold2
,lbA5Threshold2Rsrp
RsrpOffset
Offset
Parameter Settings:
Settings :
The following parameters should have same values for QCI 1 in the source and
target cells in order to avoid volte handover failures or call drops:
rlcSNLength
pdcpSNLength
Below is a case study regarding VoLTE HO failure issue due to the discrepancy
in these parameter settings.
VoLTE
VoLTE HO from
Huawei to Ericsson.p