Hi Experts.
We are facing a typical issue of fast return to NR for one Operator.
EPS fallback is happening smooth, but UE is reluctant to come back to NR.
We have NR-SA of Ericsson, and LTE of Samsung.
SIB24 has been confirmed to be activated in LTE end.
Any other checks to be done? Any suggestions?
Does 5G frequency definition / NBRs correct from LTE side?
5G SSB frequency defined in Eutran end.
4G to 5G NBRs have been created manually.
This is as reported by LTE team (Samsung), no means we can get it validated.
Preparing to put a trace when UE is attempting a FRTN, may be you can help with some cause codes which we need to look for.
Do you see on UE reading and decoding SIB24 properly?
Content of SIB24 should be like this:
SIB 24
: InterRAT/NR Neighbouring cells for cell reselection.
SystemInformationBlockType24-r15 ::= SEQUENCE {
carrierFreqListNR-r15 CarrierFreqListNR-r15 OPTIONAL, -- Need
t-ReselectionNR-r15 T-Reselection,
t-ReselectionNR-SF-r15 SpeedStateScaleFactors OPTIONAL, -- Need OR
lateNonCriticalExtension OCTET STRING OPTIONAL,
...
}
CarrierFreqListNR-r15 ::= SEQUENCE (SIZE (1..maxFreq)) OF CarrierFreqNR-r15
CarrierFreqNR-r15 ::= SEQUENCE {
carrierFreq-r15 ARFCN-ValueNR-r15,
multiBandInfoList-r15 MultiFrequencyBandListNR-r15 OPTIONAL, -- Need OR
multiBandInfoListSUL-r15 MultiFrequencyBandListNR-r15 OPTIONAL, -- Need OR
measTimingConfig-r15 MTC-SSB-NR-r15 OPTIONAL, -- Need OR
subcarrierSpacingSSB-r15 ENUMERATED {kHz15, kHz30, kHz120, kHz240},
ss-RSSI-Measurement-r15 SS-RSSI-Measurement-r15 OPTIONAL, -- Cond RSRQ2
cellReselectionPriority-r15 CellReselectionPriority OPTIONAL, -- Need OP
cellReselectionSubPriority-r15 CellReselectionSubPriority-r13 OPTIONAL, -- Need OR
threshX-High-r15 ReselectionThreshold,
threshX-Low-r15 ReselectionThreshold,
threshX-Q-r15 SEQUENCE {
threshX-HighQ-r15 ReselectionThresholdQ-r9,
threshX-LowQ-r15 ReselectionThresholdQ-r9
} OPTIONAL, -- Cond RSRQ
q-RxLevMin-r15 INTEGER (-70..-22),
q-RxLevMinSUL-r15 INTEGER (-70..-22) OPTIONAL, -- Need OR
p-MaxNR-r15 P-MaxNR-r15,
ns-PmaxListNR-r15 NS-PmaxListNR-r15 OPTIONAL, -- Need OR
q-QualMin-r15 INTEGER (-43..-12) OPTIONAL, -- Need OP
deriveSSB-IndexFromCell-r15 BOOLEAN,
maxRS-IndexCellQual-r15 MaxRS-IndexCellQualNR-r15 OPTIONAL, -- Need OR
threshRS-Index-r15 ThresholdListNR-r15 OPTIONAL, -- Need OR
...,
[[ multiBandNsPmaxListNR-v1550 MultiBandNsPmaxListNR-1-v1550 OPTIONAL, -- Need OR
multiBandNsPmaxListNR-SUL-v1550 MultiBandNsPmaxListNR-v1550 OPTIONAL, -- Need OR
ssb-ToMeasure-r15 SSB-ToMeasure-r15 OPTIONAL -- Need OR
]]
}
MultiBandNsPmaxListNR-1-v1550 ::= SEQUENCE (SIZE (1.. maxMultiBandsNR-1-r15)) OF NS-PmaxListNR-r15
MultiBandNsPmaxListNR-v1550 ::= SEQUENCE (SIZE (1.. maxMultiBandsNR-r15)) OF NS-PmaxListNR-r1
Check properly subpriorities.
Many thanks for your suggestions.
Let me give you a live example:
LTE_Uu_RRC: BCCH_DL_SCH_Message
- . .message:- c1:- systemInformation
- . . . . .criticalExtensions:- systemInformation-r8
- . . . . . . .sib-TypeAndInfo [ 0 ]:- sib24-v1530
- . . . . . . . . .carrierFreqListNR-r15 [ 0 ]
- . . . . . . . . . .carrierFreq-r15: 126490
- . . . . . . . . . .multiBandInfoList-r15 [ 0 ]: 71
- . . . . . . . . . .measTimingConfig-r15
- . . . . . . . . . . .periodicityAndOffset-r15:- sf20-r15: 0
- . . . . . . . . . . .ssb-Duration-r15: 0
- . . . . . . . . . .subcarrierSpacingSSB-r15: 0
- . . . . . . . . . .cellReselectionPriority-r15: 4
- . . . . . . . . . .cellReselectionSubPriority-r15: 2
- . . . . . . . . . .threshX-High-r15: 1 (1)
- . . . . . . . . . .threshX-Low-r15: 1 (1)
- . . . . . . . . . .q-RxLevMin-r15: -60
- . . . . . . . . . .p-MaxNR-r15: 23
- . . . . . . . . . .deriveSSB-IndexFromCell-r15: 1
- . . . . . . . . .carrierFreqListNR-r15 [ 1 ]
- . . . . . . . . . .carrierFreq-r15: 125330
- . . . . . . . . . .multiBandInfoList-r15 [ 0 ]: 71
- . . . . . . . . . .measTimingConfig-r15
- . . . . . . . . . . .periodicityAndOffset-r15:- sf20-r15: 0
- . . . . . . . . . . .ssb-Duration-r15: 0
- . . . . . . . . . .subcarrierSpacingSSB-r15: 0
- . . . . . . . . . .cellReselectionPriority-r15: 4
- . . . . . . . . . .cellReselectionSubPriority-r15: 2
- . . . . . . . . . .threshX-High-r15: 1 (1)
- . . . . . . . . . .threshX-Low-r15: 1 (1)
- . . . . . . . . . .q-RxLevMin-r15: -60
- . . . . . . . . . .p-MaxNR-r15: 23
- . . . . . . . . . .deriveSSB-IndexFromCell-r15: 1
- . . . . . . . . .t-ReselectionNR-r15: 1
It won’t work until you disable Idle load balancing feature from LTE (Samsung) side and change reselection priorities of LTE frequecy.
Check with Samsung.
Alternatively, once VoLTE call is done, IRAT B1 event would be configured to UE.
So UE will come back without going in to idle mode.
Fast return to NR, do you expect it from reselection Or 4G-5G irat HO?
Based on that you need to check parameters.
Check sib24 content for nr-arfcn and reselection thresholds.
If you can share sib24 log can point the parameter.
Yes, Idle mode Mobility control information (IMMCI) from RRC connection release may force your UE to stay on an EARFCN that has no definition to NR in SIB24.
Here is an example of RRC release with IMMCI:
In this case UE will go to earfcn 2950 and will stay there for 3 hours unless a new RRC connection request will happen.