08 RA4704 Mobility Layering Nok

LTE Optimization
Principles [RL50]
Nokia Academy
• Module 08: Mobility and Layering
1 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

Confidential
Course Outlook
1. RF Measurement Quantities
2. KPI Overview
3. Physical RF Optimization
4. Throughput Optimization
5. Basic signaling
6. Call Setup Optimization
7. Call Drop Analysis
8. Mobility and Layering
9. Capacity Management

Confidential
Module Objectives
• After completing this module, you will be able to:

• Give an overview about related network and field KPIs
• Discuss inter-layer mobility use cases
• Summarize relevant features and parameters
• Analyse mobility and layering via means of drive test results

Confidential
Index
- Network + Field KPIs

- Inter-layer Mobility Optimization Use Cases
• UE capabilities Feature Group Indicator
• Tracking Area optimization
• Location Area optimization
• LTE-capable UEs camping in 2G/3G
• LTE inter-frequency handover optimization
• Ping-pong mobility
- Related features
- Project Example
Handover drops are covered in another module of this training

Confidential
Some Important Counter-Based Idle Mode Mobility KPIs
• none in BTS
• In eNB there are no counters for idle mode mobility
• In NSN MME there are counters for TAU success rate

Confidential
Drive Test KPIs for Mobility
- Use case: UE is camping in 2G/3G when LTE coverage is better.

• Analysis requires simultaneous scanner + UE logging
• Field test KPI TBD
- Use case: ping-pong cell reselection
• Field test KPI TBD

Confidential
Index

- Related features
Idle and connected mode parameter knowledge is
- Project Example prerequisite for this module. See LTEPAR
training

Confidential
UE Capabilities Troubleshooting – FGI
- Common problem cases:

• UE does not support LTE inter-frequency handover + meas gaps
• UE does not support LTE3G ISHO
- How to find out UE capabilities?

- Why is this a problem?
• UE firmware feature details are often not known
• Most drive test tools don’t decode Feature Group Indicator in UE Capability msg

Confidential
UE Capability Info, Feature Group Indicator Bitmap
…. Not decoded by all tools,

interRAT-BandList value 5 see TS 36.331 Annex B
interRAT-NeedForGaps : true
interRAT-BandList value 6
interRAT-NeedForGaps : true
featureGroupIndicators
Not all tools decode FGI
Bin : 5E 0D D8 80 (= 1577965696) • Wireshark decodes.
interRAT-Parameters • Nemo 6.1 decodes partly
utraFDD
supportedBandListUTRA-FDD
supportedBandListUTRA-FDD value 1 : bandI
supportedBandListUTRA-FDD value 2 : bandVIII
geran
supportedBandListGERAN
supportedBandListGERAN value 1 : gsm850
supportedBandListGERAN value 2 : gsm900E
interRAT-PS-HO-ToGERAN : false

Confidential
UE Capability Info, Feature Group Indicator Bitmap
featureGroupIndicators: 5e0dd880 [bit length 32]
0... .... = Indicator 1: Intra-subframe freq hopping for PUSCH scheduled by UL grant; DCI format 3a; PDSCH transmission mode 5; Aperiodic CQI/PMI/RI report on PUSCH: Mode 2-0 and 2-2 - Not supported
.1.. .... = Indicator 2: Simultaneous CQI and ACK/NACK on PUCCH (format 2a/2b); Absolute TPC command for PUSCH; Resource alloc type 1 for PDSCH; Periodic CQI/PMI/RI report on PUCCH: Mode 2-0 and 2-1 - Supported
..0. .... = Indicator 3: 5bit RLC UM SN; 7bit PDCP SN - Not supported
...1 .... = Indicator 4: Short DRX cycle - Supported
.... 1... = Indicator 5: Long DRX cycle; DRX command MAC control element - Supported
.... .1.. = Indicator 6: Prioritised bit rate - Supported
.... ..1. = Indicator 7: RLC UM - Supported
.... ...0 = Indicator 8: EUTRA RRC_CONNECTED to UTRA CELL_DCH PS handover - Not supported
0... .... = Indicator 9: EUTRA RRC_CONNECTED to GERAN GSM_Dedicated handover - Not Supported
.0.. .... = Indicator 10: EUTRA RRC_CONNECTED to GERAN (Packet_) Idle by Cell Change Order; EUTRA RRC_CONNECTED to GERAN (Packet_) Idle by Cell Change Order with NACC - Not supported
..0. .... = Indicator 11: EUTRA RRC_CONNECTED to CDMA2000 1xRTT CS Active handover - Not supported
...0 .... = Indicator 12: EUTRA RRC_CONNECTED to CDMA2000 HRPD Active handover - Not supported
.... 1... = Indicator 13: Inter-frequency handover - Supported
.... .1.. = Indicator 14: Measurement reporting event: Event A4 - Neighbour > threshold; Measurement reporting event: Event A5 - Serving < threshold1 & Neighbour > threshold2 - Supported
.... ..0. = Indicator 15: Measurement reporting event: Event B1 - Neighbour > threshold - Not supported
.... ...1 = Indicator 16: non-ANR related periodical measurement reporting - Supported
1... .... = Indicator 17: Periodical measurement reporting for SON / ANR; ANR related intra-frequency measurement reporting events - Supported
.1.. .... = Indicator 18: ANR related inter-frequency measurement reporting events - Supported
..0. .... = Indicator 19: ANR related inter-RAT measurement reporting events - Not supported
...1 .... = Indicator 20: SRB1 and SRB2 for DCCH + 8x AM DRB; SRB1 and SRB2 for DCCH + 5x AM DRB + 3x UM DRB (if indicator 7 is supported) - Supported
.... 1... = Indicator 21: Predefined intra- and inter-subframe frequency hopping for PUSCH with N_sb > 1; Predefined inter-subframe frequency hopping for PUSCH with N_sb > 1 - Supported
.... .0.. = Indicator 22: UTRAN measurements, reporting and measurement reporting event B2 in E-UTRA connected mode - Not supported
.... ..0. = Indicator 23: GERAN measurements, reporting and measurement reporting event B2 in E-UTRA connected mode - Not supported
.... ...0 = Indicator 24: 1xRTT measurements, reporting and measurement reporting event B2 in E-UTRA connected mode - Not supported
1... .... = Indicator 25: Inter-frequency measurements and reporting in E-UTRA connected mode - Supported
.0.. .... = Indicator 26: HRPD measurements, reporting and measurement reporting event B2 in E-UTRA connected mode - Not supported
..0. .... = Indicator 27: EUTRA RRC_CONNECTED to UTRA CELL_DCH CS handover - Not supported
...0 .... = Indicator 28: TTI bundling - Not supported
.... 0... = Indicator 29: Semi-Persistent Scheduling - Not supported
.... .0.. = Indicator 30: Handover between FDD and TDD - Not supported
.... ..0. = Indicator 31: Undefined - Not supported
.... ...0 = Indicator 32: Undefined - Not supported

Confidential
Index

- Related features
training

Confidential
Tracking Area Optimization
Benefits
• Paging carried in
- all cells in a TA, or
- all cells in a list of TAs
• Tracking Area optimization is a trade-off between excessive paging load and excessive TA updates
• Tracking Area optimization potential benefits
- Decrease Physical Downlink Shared Channel (PDSCH) Utilization
• Increase throughput resource available for end users
• Reduce admission control failures for VoLTE
- Increase Physical Random Access Channel (PRACH) Availability
• Improve user experience of network access and latency
- Optimize Mobility Management Entity (MME) Paging and Tracking Update Performance
• Improve the end user system availability experience
- Lengthen UE Battery Life by Reducing Mobility Related Signaling
Confidential
Trade-off
• Paging increases in a linear fashion as a TA is made larger.

• TA Updates are inversely proportional to the TA size. There is a diminishing improvement in TA
updates as the size increases.
• The optimal size of a TA is call model dependent. The rate at which UE move, receive DL data
and enter idle mode influence the optimal size.
• MME paging limitations must be also considered!
• MME paging capacity can be the limiting factor for
TA size.

Confidential
Mobility Patterns
- To minimize TAUs, Tracking Areas should follow user mobility patterns

- These are difficult to measure from BTS counters
– M8015 records handover for source-target pairs
– Even if these are for connected mode, they probably approximate UE mobility patterns
- NSN MME give TAU statistics only at TA level
– Check MME counters in case of other vendor MME

Confidential
Typical Case
Heavy traffic along the road causes tracking area updates
- Optimization solution 1: combine TAs 1-3 to one big TA
• Drawback: heavy paging load in eNBs
TAI = 3
TAI = 1 TAI = 2
Heavy traffic along road

Confidential
Typical Case
- Heavy traffic along the road causes tracking area updates

- Optimization solution 2: put TAs 1-3 to the same TA list
• Drawback: heavy paging load in eNBs
TAI = 3
TAI = 1 TAI = 2
TA
LIST:
Heavy traffic TAI = 1
TAI = 2
17 18/02/2024
Confidential
© Nokia 2014 - File Name - Version - Creator - DocID TAI = 3
Index

- Related features prerequisite for this module. See LTEPAR
- Project Example training

Confidential
Location Area Optimization
• CSFB capable UE makes combined EPS/IMSI attach/TAU in which MME assigns LAC to UE
– LAC assigned based on TAI-LAI-VLR mapping table in MME
• When UE moves to 2G/3G, either because of normal cell reselection or CSFB, it will make LAU
if 2G/3G LAC is different from LTE LAC
• Question: should we set LTE LAC to be the same as 2G or 3G LAC?
– If LTE coverage is patchy, frequent LAU will occur when UE reselects to 2G/3G and back 
signalling load and “CS paging black hole”
– CSFB call setup time could increase because UE must make LAU first
– BUT: there is a danger of UE ending up being unreachable or increased paging time if LTE LAC
is the same as non-LTE LAC and UE goes camping in 2G/3G (next slide)

Confidential
Location Area Optimization, CS Paging Problem
- If CSFB UE does not make LAU when it reselects to 2G or 3G, MSS still assumes UE is in
LTE and pages it first from there, and only afterwards in 2G/3G (depending on core
implementation)
- Solution 1: use Gs interface so that UE makes combined LAU/RAU when it reselects 2G/3G
 MSS will be informed by SGSN that UE is in 2G/3G, and there is no CS paging delay
- Solution 2: make sure that LTE LAC is different from 2G/3G LAC (can use dummy LAC in
MME)
• Also MSS pooling, if used, may require that LTE LAC and 3G LAC are different
- Discuss options with core planning team!!
• Also Idle Mode Signalling Reduction feature might be implemented in core (not all UEs
support yet)…

Confidential
The case where LTE LAC and 3G LAC are different
Time RRC direction RRC message name Attach Accept on LTE side assigns LAC
14:32:40.432 Uplink ATTACH_REQUEST (after combined EPC/IMSI Attach)
14:32:40.432 Uplink PDN_CONNECTIVITY_REQUEST
14:32:40.514 Downlink IDENTITY_REQUEST
14:32:40.514 Uplink IDENTITY_RESPONSE
14:32:40.551 Downlink AUTHENTICATION_REQUEST
14:32:40.731 Uplink AUTHENTICATION_RESPONSE
14:32:40.731 Downlink SECURITY_MODE_COMMAND
14:32:40.731 Uplink SECURITY_MODE_COMPLETE
14:32:51.827 Downlink ATTACH_ACCEPT
14:32:51.827 Downlink ACTIVATE_DEFAULT_EPS_BEARER_CONTEXT_REQUEST
14:32:51.835 Uplink ATTACH_COMPLETE

Here LTEreselection
14:32:51.835 or CSFB to 3G takes
Uplink place, 3G cell has a different LAC than LTE cell
ACTIVATE_DEFAULT_EPS_BEARER_CONTEXT_ACCEPT
14:33:37.280 Uplink LOCATION_UPDATING_REQUEST

14:33:37.280 Uplink ROUTING_AREA_UPDATE_REQUEST
14:33:38.133 Uplink IDENTITY_RESPONSE LA Update Request required since 3G LAC is
14:33:39.359 Downlink AUTHENTICATION_REQUEST different from LTE LAC
14:33:39.359 Downlink AUTHENTICATION_AND_CIPHERING_REQUEST
14:33:39.538 Uplink AUTHENTICATION_RESPONSE
14:33:39.779 Uplink AUTHENTICATION_AND_CIPHERING_RESPONSE
14:33:40.178 Uplink IDENTITY_RESPONSE
14:33:40.840 Downlink GPRS_IDENTITY_REQUEST
14:33:40.840 Uplink GPRS_IDENTITY_RESPONSE
14:33:41.001 Downlink LOCATION_UPDATING_ACCEPT
14:33:41.059 Uplink TMSI_REALLOCATION_COMPLETE
14:33:41.059 Downlink MM_INFORMATION
14:33:41.479 Downlink ROUTING_AREA_UPDATE_ACCEPT
Confidential
Presentation / Author / Date
Index


Confidential
LTE-capable UEs Camping in 2G/3G
• LTE-capable UEs should stay in LTE if there is coverage (and not excessive interference)
• LTE uses Rel8 absolute priority based cell reselection
- In Rel8 3GLTE and 2GLTE HOs not supported
- Hence in initial phases, idle mode mobility optimization is crucial
- RU40 supports RRC Release with Redirect to LTE
• 3GLTE reselection use case:
- LTE layer(s) have higher priority than 3G layer
- LTE coverage area is a subarea of 3G coverage
• 2GLTE reselection use case
- Rural areas of 3G operators and non-3G operators
- LTE layer(s) have higher priority than 2G layer
- LTE coverage area is a subarea of 2G coverage

Confidential
LTE-capable UEs Camping in 3G
• 3GLTE reselection only possible in URA_PCH, CELL_PCH or idle mode
• If possible, shorten DCH and FACH inactivity timer
- Often not allowed or not sensible…
• RU40 Smart LTE Layering feature
- LTE UE redirected to LTE layer immediately
redirect

Confidential
3G -> LTE Smart LTE layering, redirect
Redirect features check UE capability for LTE. Subscriber information checked:

The RAN2717: Smart LTE Layering feature follows special mechanisms to limit/prevent redirection of UEs to LTE:
- 1. It allows the redirection for all UEs or for those UEs that were previously redirected from LTE to 3G. If a UE is
redirected from LTE to 3G, then it had LTE coverage and it is more safe to redirect it back. By default this functionality is not used.
- 2. It allows the redirection only to LTE bands that are supported by the UE (LTE bands supported by UE are checked and
compared against the region-available LTE bands before the redirection to LTE). By default this functionality is in use.
- 3. It allows the redirection if Core Network has not sent E-UTRAN Service Handover IE. This functionality is always in
use. UE is not redirected to LTE, if Core Network has sent E-UTRAN Service Handover IE for any RAB of the UE. The purpose of this
is to prevent redirection to LTE for that kind of user that cannot get any service from LTE side. Those kinds of users are users who do not
have LTE subscription or those that are not in home network and have prevented roaming data
- The above preventions/limitations are used to prevent outages and/or delays that would be caused if the redirected UE could not get
service in LTE. The usage of these functionalities can be controlled with the PRFILE parameter 002:1916 RN60_MAINT_41.
-

Confidential
3GLTE Reselection to Higher Priority LTE Layer
• Important 3G parameters
- ADJL/AdjLAbsPrioCellReselec
- WCEL/AbsPrioCellReselec
• Should be: AdjLAbsPrioCellReselec>AbsPrioCellReselec
• NOTE: These parameters are not allowed to have the same value.
- HOPL/AdjLThreshigh, 0…62 dB
- HOPL/AdjLQrxlevminEUTRA, -140..-44, step 2 dBm
• Check parameters from SIB19 using drive testing!!
• UE performs the cell re-selection to a measured higher priority LTE carrier in case the criterion
LTE RSRP  Qrxlevmin  AdjLThresH igh

is fulfilled for at least TreselectionFACH orLTETreselectionPCH

Confidential
- How often UE searches for higher priority LTE cells depends on WCEL/Sprioritysearch1 and
WCEL/Sprioritysearch2
- Kcarrier=number of LTE carriers in SIB19
RSCPServingCell Inside this region UE shall search

for a E-UTRA layers of higher
priority at least every 60sec.
Outside this region, UE shall be
able to reselect a higher prio LTE
cell within Kcarrier * TdetectE-UTRA
Sprioritysearch2
Sprioritysearch1
RSCPmin
Ec/N0ServingCell
Ec/N0min
Confidential
- From prev slide:

• if SrxlevServingCell <= Sprioritysearch1 or SqualServingCell <= Sprioritysearch2 then UE shall be able to
evaluate whether a new detectable *) LTE cell meets the reselection criteria within Kcarrier *
TdetectE-UTRA
DRX cycle length [s] TdetectE-UTRA [s]
0.08 not in idle mode

0.16 not in idle mode
0.32 not in idle mode 30
0.64
1.28
2.56
60
5.12
28
*)
Definition
18/02/2024 of2014
© Nokia “detectable” given
- File Name - Version in TS- DocID
- Creator 25.133
Confidential
- Example: one LTE 2.6G carrier defined in SIB19 and 3G DRX cycle = 640ms, then UE shall
- In order to accelerate 3GLTE reselection there is not a lot that can be done… Mainly:
• Set Sprioritysearch1 and Sprioritysearch2 to high values.
• Setting DRX cycle to max 1.28sec reduces reselection time to K*30sec
• Using only one LTE carrier in SIB19 results in K=1, which minimizes cell reselection time, <30sec should be possible for
compliant Ues
- Initial field measurements indicate <10sec reselection time from the point when UE moves to PCH or idle state
- HOPL/AdjLQrxlevminEUTRA should be set to the same value as used on LTE, usually around -
130dBm
- To avoid ping-pong, hysteresis can be set to HOPL/AdjLThreshigh =6dB
- On LTE side, A2 RRC redirect trigger and cell reselection thresholds should not result in ping-
pong back to 3G

Confidential
Traffic Signalling Source
3GLTE bearer mapping in MME QCI
Traffic
Class
Handling
Priority
Indication Statistics
Descriptor
1 Conversational N/A N/A Speech
E-RAB modification required in LTE, if 2 Conversational N/A N/A Unknown (NOTE 1)

mapped QCI different to default bearer QCI .
3 Conversational N/A N/A Unknown (NOTE 2)
Check:
4 Streaming N/A N/A Unknown (NOTE 3)
- Activate E-RAB modification
5 Interactive 1 Yes N/A
(actERabModify) = Enabled
6 Interactive 1 No N/A
- QCI parameters are matching:LCG ID, 7 Interactive 2 No N/A
DRX profile ID, PDCP profile ID, RLC 8 Interactive 3 No N/A
profile ID 9 Background N/A N/A N/A
NOTE°1: When QCI 2 is mapped to pre-Rel-8 QoS parameter values, the

Transfer Delay parameter is set to 150 ms. When pre-Rel-8 QoS parameter values are
mapped to a QCI, QCI 2 is used for conversational/unknown if the Transfer Delay
parameter is greater or equal to 150 ms.
EPS Pre-Rel-8 NOTE°2: When QCI 3 is mapped to pre-Rel-8 QoS parameter values, the
Bearer ARP Priority Value ARP Value Transfer Delay parameter is set to 80 ms as the lowest possible value, according to
TS 23.107 [14]. When pre-Rel-8 QoS parameter values are mapped to a QCI, QCI 3 is
1 to H 1
used for conversational/unknown if the Transfer Delay parameter is lower than 150 ms.
H+1 to M 2 NOTE 3: When QCI 4 is mapped to pre-Rel-8 QoS parameter values, it is
mapped to Streaming/Unknown. When pre-Rel-8 QoS parameter values are mapped to
M+1 to 15 3
a QCI, Streaming/Unknown and Streaming/Speech are both mapped to QCI 4.
Table E.1: Mapping of EPS bearer ARP to pre-Rel-8 ARP

Table E.3: Mapping between standardized QCIs and pre-Rel-8 QoS
parameter values
Confidential
- RG20 BSS21353: “LTE system information” supports autonomous cell reselection from the
GSM/EDGE cells to the LTE cells.
• Enables BCCH broadcasting of LTE layers
• When both LTE and WCDMA layers have priority value defined, also the priority parameters
for the WCDMA cell are sent in SI2q message.
- UE will select higher priority LTE layer if the following criterion is fullfilled for duration of
time hysteresis parameter
• RSRP > lteAdjCellMinRxLevel + lteAdjCellReselectUpperThr
- RG30EP1 RG301854 “Fast Return to LTE
from GSM” redirects UE to LTE after GSM call release

Confidential
2GLTE reselection to higher priority LTE layer
• Impact of BTS/timeHysteresis

Confidential
Index


Confidential
Inter frequency cell reselection
• Idle mode strategies:

• 1. Priority layer
LTE coverage
• Limited coverage on capacity layer (hot-spots) Layer
LTE capacity
Layer
Priority 3
Priority 4
• Larger bandwidth on higher priority layer

Confidential
Inter-frequency HO Optimization
- Usually one LTE layer is for coverage and one is for hot spots
- Inter-frequency connected mode mobility parameters must aligned with idle mode reselection
strategy.
- Goal in initial phase is to ensure that UE is connected to the layer with the best RSRP if layers
have the same bandwidth
• Assuming initial deployment with low-to-medium load
• Load balancing features in roadmap
- If the layers have different bandwidths, the lower bandwidth layer should have higher RSRP to
reach equivalent throughput
• Example: About 5-8 dB higher for 10MHz versus 20MHz
• … though handover thresholds could be decided based on many other criteria too

Confidential
- IFHO meas gaps should not be activated too early

• Activating IFHO measurements reduces UE tput due to meas gaps
• Activating IFHO measurements deactivates DRX  increases battery consumption for smart
phones
TCP and UDP DL tput, with and without measurement gap, 10MHz system
80
70
60
MEAS GAP ON UDP
50
tput, Mbps
MEAS GAP OFF UDP

40
MEAS GAP ON TCP
30 MEAS GAP OFF TCP
20
10
0
1 6 11 16 21 26 31 36 41 46 51 56
time, seconds

Confidential
- HO should not be triggered too early, an aggressive trigger point would be RSRP below -
115dBm @20MHz bandwidth if there is coverage from a better neighbour layer
• Otherwise end user experience suffers
• If interference present, threshold may need to be much higher
• Based on field measurements, RSRP <-115dBm results in <20Mbps tput for 20MHz unloaded
system. Anything above this is usually still ok for web browsers…
- Triggering HO at RSRP > -100dBm produces little practical user tput benefit
• TCP and internet limit practical tput of end users
• Speed test users are another story..

Confidential
- A3 offset depending on target layer bandwidth

• If target bw is same: a3offset ~3dB
• If target bw is half: a3offset ~ 8dB
• If target bw is double: a3offset ~ 0dB (or even negative??!!)
- The above rules of thumb are based on the principle that user tput should not suffer in target
layer
• The call should not drop either
• In RL40 load balancing intra eNB, inter eNB / inter RAT in RL50 and beyond
- No point to activate IFHO in cells where there is no other layer coverage
- Settings should be such that ping-pong is not possible for any pair of layers
• At least 5dB margin
Confidential
Index

- Related features
training

Confidential
Ping-Pong Idle + Connected Mode Mobility
For every pair of layers, triggering thresholds should be checked for

– Idle-idle ping-pong
– Idle-connected ping-pong
– Connected-idle ping-pong
– Connected-connected ping-pong
Example of idle-connected ping-pong:
1. 3GLTE idle mode reselection takes place at when LTE received level is RSRP = -125dBm
2. In LTE, UE goes to connected mode due to always-on applications
3. A2 RRC redirect to UTRA threshold has been set to -120dBm
4. A2 is triggered and UE is redirected back to 3G
5. …and so on… go to step 1

Confidential
Index prerequisite for this module. See LTEPAR
training

- Related features
- Project Example

Confidential
Related features
• PS handover based CSFB LTE736 RL40

• SRVCC to WCDMA LTE872 RL40
• E-RAB modification LTE519 RL40
• Inter eNB Inter-Frequency Load Balancing LTE1170 RL50

• Idle Mode Load Balancing LTE487 RL50
• Downlink Carrier Aggregation LTE1089 RL50

Confidential
Index prerequisite for this module. See LTEPAR
training

- Related features
- Project Example

Confidential
Project Example: Connected Mode Mobility
Ping-pong RSRP/RSRQ A3
• Simultaneous activation of RSRP and RSRQ A3 handovers between two different layers may lead to ping pong
HO between these layers. For example, in the previous network example case:
- RSRP is better on 1800: lower frequency ->lower free space loss and penetration loss
- RSRQ is better on 2600: less interference due to lower number of sites
• A UE on a 1800 site when measuring a 2600 neighbor with better RSRQ it performs HO to 2600 site. Once on
2600, the UE measures an 1800 site with better RSRP, performs HO to 2600
Exercise
1. Considering the below settings, suggest two possible solutions to avoid the ping pong (remember, operator
wants to keep traffic in 2600 as long as possible).
Settings for 1800 cells:
- LNHOIF (2600MHz):hysA3OffsetRsrp(/Rsrq)InterFreq = 2dB
- LNHOIF (2600MHz):a3OffsetRsrp(/Rsrq)InterFreq = 2dB
Settings for 2600 cells:
- LNHOIF (1800MHz):hysA3OffsetRsrp(/Rsrq)InterFreq = 3dB
44- LNHOIF
18/02/2024 (1800MHz):a3OffsetRsrp(/Rsrq)InterFreq
© Nokia 2014 - File Name - Version - Creator - DocID = 3dB
Confidential
LTE 2600, Absolute Priority 7 qrxLevMin = -130 dBm
Idle mode reselection sIntraSearch = 62
sNonIntrSearch = 16
RSRP
-68 -114 -130 -140
When RSRP < -68: start to When RSRP < -114: start to
measure intra-freq neighbours. measure on LTE1800 and WCDMA
Reselection to another 2600 cell Reselection to LTE1800 cell Ifwill

no suitable LTE1800 cell is
will happen when the neighbour is happen when serving cell is found, then try WCDMA.
3dB better. below -120dBm and the Reselection to WCDMA will happen
LTE1800 neighbour’s RSRPwhen is serving cell is below -120
LNCEL:Qhyst = 3dB better than -109 dBm. and neighbouring WCDMA cell
IAFIM: qOffestCell = 0dB RSCP > -101
LNCEL:threshSrvLow = 10
Reselection will happen if UE IRFIM:interFrqThrL = 21 LNCEL:threshSrvLow = 10
camps longer than 1 sec in the UFFIM:utraFrqThrL = 10 (relative to
serving cell AND condition has to Reselection will happen if UEUFFIM:qRxLevMinUtra = -111)
be met for a time camps longer than 1 sec in the
LNCEL:tReselEutr = 1s serving cell AND condition has
Reselection will happen if UE
to be met for a time camps longer than 1 sec in the
IRFIM:interTResEutr = 1s serving cell AND condition has to
45 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID be met for a time UFFIM:tResUtra
Confidential = 1s
LTE 1800, Absolute Priority 6 qrxLevMin = -130 dBm
Idle mode reselection sIntraSearch = 62
sNonIntrSearch = 16
RSRP
-68 -114 -130 -140
When RSRP < -68: start to UE will ”always” (=periodically) When RSRP < -114: start to
measure intra-freq neighbours. measure on 2600 cells because measure on WCDMA
2600 has higher priority
Reselection to another 1800 cell Reselection to WCDMA will happen

will happen when the neighbour is when serving cell is below -120
Reselection to 2600 cell will
3dB better. and neighbouring WCDMA cell
happen when 2600 cell is better
RSCP > -101
than -109.
LNCEL:Qhyst = 3dB
IAFIM: qOffestCell = 0dB LNCEL:threshSrvLow = 10
IRFIM:interFrqThrH = 21
UFFIM:utraFrqThrL = 10 (relative to
Reselection will happen if UE UFFIM:qRxLevMinUtra = -111)
Reselection will happen if UE
camps longer than 1 sec in the
camps longer than 1 sec in the
serving cell AND condition has to Reselection will happen if UE
serving cell AND condition has
be met for a time camps longer than 1 sec in the
to be met for a time
LNCEL:tReselEutr = 1s serving cell AND condition has to
IRFIM:interTResEutr = 1s
be met for a time UFFIM:tResUtra
= 1s
Confidential
Intra-frequency Cell Reselection
- The UE will rank the measured cells according to the following rule:
• Rankserving cell = Measured RSRPserving cell + LNCEL:Qhyst
• Rankneighbour cell = Measured RSRPneighbour cell – IAFIM:qOffsetCell

Confidential
When RSRP < -68: start to
measure intra-freq neighbours.
Example
• Default: LNCEL: qHyst = 1dB and IAFIM: qOffsetCell = 2 dB.
• Issue:
- qOffsetCell is in the IAFIM object, where IAFIM is optional. Is 1dB enough to avoid ping-pong if IAFIM is
not defined?
- qOffsetCell is better to be used for specific case, for example, indoor cells, instead of generic offset to avoid
ping-pong. Otherwise, this will make the DB maintenance & consistency more difficult, because:
• All possible neighbors need to be defined in IAFIM, otherwise any ”missing” neighbors” will be better-
off by x dB (set by qOffsetCell) compare to a measured PCI which is defined in IAFIM.
• IAFIM neighbor review is needed whenever a new sites is deployed.
• When make a new PCI plan, you have to change the PCIs in all the IAFIM objects also.
• Solution:
- Instead of having the default, change qHyst to 3 dB and qOffsetCell to 0 (or don’t define the IAFIM at all.
See next slide for details)
Confidential
Intra-frequency Cell Reselection Example
- The IAFIM is optional, meaning that if you want to set qOffsetCell to 0 and you don’t want to
blacklist any cells, you should not define the IAFIM.
- However, there is one reason to have IAFIM. For certain Huawei UEs, it has been seen that
they crash if they don’t receive the SIB4 (where the IAFIM parameters are carried). Therefore
it is recommended to have the SIB4 and just define a ”dummy” PCI in the IAFIM and set the
qOffsetCell to 0.

Confidential
Intra-frequency Cell Reselection Example
- In the Operator X network, LNCEL:qHyst was set to 1 dB, and IAFIM:qOffsetCell was set to
2dB, but it was only defined for intra-site neighbours.
- This means that when reselecting to intra-site neighbours, the total margin is 3 dB (2+1).
However, since there was no IAFIM defined for the other neighbouring cells, there would be
only 1 dB of hysteresis, which is too little, results too many reselections between sites & cells.
List only contains offset for two neighbours

Confidential
Idle mode PCI plot
Before parameter change, cell
After parameter change, less
reselections happening too
ping pong between cells
often

Confidential
Idle mode LTE-3G reselection example
• UE (Lumia 820) placed on a desk, in a single static location
• UE keeps on moving between LTE and 3G in idle mode.
• Reselection parameters:
- LTE3G q-RxLevMin -66 (132dBm) and threshServingLow 5 (10dB)
- 3GLTE qRxLevMinEUTRA -66 (132dBm) and threshXhigh 8 (16dB)
=> 6dB hysteresis in LTE side. It is not enough to prevent idle mode ping-pong at LTE cell edge (even for static terminal) !
For more details see Nemo logs:
Nemo log 8 LTE 3G idle mobility.1.nmf
Nemo log 9 LTE 3G idle mobility SIBs.1.nmf
3G
LTE

Confidential
Confidential

08 RA4704 Mobility Layering Nok

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

08 RA4704 Mobility Layering Nok

Uploaded by

Copyright:

Available Formats

LTE Optimization

1 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

3 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

• After completing this module, you will be able to:

4 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

- Network + Field KPIs

Handover drops are covered in another module of this training

5 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

6 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

- Use case: UE is camping in 2G/3G when LTE coverage is better.

7 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

- Network + Field KPIs

Handover drops are covered in another module of this training

8 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

- Common problem cases:

- How to find out UE capabilities?

9 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

…. Not decoded by all tools,

10 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

11 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

- Network + Field KPIs

Handover drops are covered in another module of this training

12 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

• Paging increases in a linear fashion as a TA is made larger.

14 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

- To minimize TAUs, Tracking Areas should follow user mobility patterns

15 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

Heavy traffic along road

16 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

- Heavy traffic along the road causes tracking area updates

- Network + Field KPIs

Handover drops are covered in another module of this training

18 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

19 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

20 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

14:32:51.835 Uplink ATTACH_COMPLETE

14:33:37.280 Uplink LOCATION_UPDATING_REQUEST

- Network + Field KPIs

Handover drops are covered in another module of this training

22 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

23 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

24 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

Redirect features check UE capability for LTE. Subscriber information checked:

25 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

LTE RSRP  Qrxlevmin  AdjLThresH igh

26 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

RSCPServingCell Inside this region UE shall search

- From prev slide:

0.08 not in idle mode

29 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

1 Conversational N/A N/A Speech

E-RAB modification required in LTE, if 2 Conversational N/A N/A Unknown (NOTE 1)

DRX profile ID, PDCP profile ID, RLC 8 Interactive 3 No N/A

profile ID 9 Background N/A N/A N/A

NOTE°1: When QCI 2 is mapped to pre-Rel-8 QoS parameter values, the

Table E.1: Mapping of EPS bearer ARP to pre-Rel-8 ARP

31 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

32 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

- Network + Field KPIs

Handover drops are covered in another module of this training

33 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

• Idle mode strategies:

34 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID

35 18/02/2024 © Nokia 2014 - File Name - Version - Creator - DocID