Hi All,
I would like to know how to get measurements report in E// enodebs. Please let me know.
Hello All,
Can someone please guide how to fetch B2 measurement report from Ericsson enb?
Hi, @Sooraj, I don’t know what exactly you need, I believe it is in Cell Trace
Hi @vlr9999 thank you so much, yes I was actually looking for measurement report from UE related to SRVCC. I believe is it B2 measurement report we need to look for? Please confirm
Hi, @Sooraj, sorry, this is not my playground.
No problem, once again thank you
Yes — B2 is the right event for SRVCC, and vlr9999 pointed you at the correct tool (Cell Trace). Tying
it together:
Why B2: SRVCC to UTRAN/GERAN is triggered by measurement event B2 — “serving (PCell) becomes worse
than threshold1 AND inter-RAT neighbour becomes better than threshold2.” That’s the two-threshold
event that says “LTE coverage is fading and there’s a 3G/2G cell worth moving the voice call to.” So
for SRVCC you’re looking for the B2 measurement report carrying the UTRAN/GERAN neighbour, not A3/A5
(those are intra-LTE / inter-freq LTE).
How to capture it on an Ericsson eNB — Cell Trace (CTR):
- Start a Cell Trace recording (from ENM/OSS, or on-node). For SRVCC you want the UE measurement +
RRC events, so include the event group covering RRC (INTERNAL_PER_UE… / UE_MEAS events) and the
handover/SRVCC events. - Filter to the UE/cell during a call that undergoes SRVCC (or run it broad and find the SRVCC
sessions after). - Decode the CTR in a trace tool (TEMS Investigation/Discovery, or the Ericsson CTR decoder). Look
for the RRC MeasurementReport with measResultListUTRA / measResultListGERAN populated and the
event id = eventB2 — that’s your UE measurement report for SRVCC. - The full SRVCC sequence in the trace: B2 MeasurementReport (UE) → eNB decides SRVCC → Handover
From EUTRA Preparation Request / SRVCC PS-to-CS toward MME → HO Command to UE → UE leaves LTE.
The measResult in that B2 report is the RSCP/EcNo (UTRAN) or RxLev (GERAN) of the target the call
handed to.
Two checks if B2 never fires in your trace:
- The eNB must be configured with the inter-RAT B2 thresholds and a UTRAN/GERAN freq relation, or the
UE is never told to measure/report the target RAT — no B2 possible. Confirm the inter-RAT
measurement + SRVCC feature config on the cell. - Confirm the UE is on a VoLTE call (SRVCC only applies to an active CS-equivalent bearer / QCI 1) —
no voice bearer, no SRVCC, no B2 for it.
So: B2 is correct; capture it via Cell Trace, decode for RRC MeasurementReport with eventB2 +
measResultListUTRA/GERAN. That report is exactly the UE measurement that drives the SRVCC decision.
Thank you so much, in my case SRVCC is happening very late, I believe I need to reduce the threshold value. Do you know which exact parameter I need to look for in the enodeb? I have already verified SRVCC configuration, which is correct. Just need to understand the parameter name for threshold. Please let me know.
b2Threshold1Rsrp in MO ReportConfigB2Utra is the serving-cell threshold (b2Threshold1Rsrq if triggerQuantityB2 = RSRQ). But check the direction before you touch it — entry condition is:
RSRPserving + hysteresisB2 < b2Threshold1Rsrp
So a lower b2Threshold1Rsrp makes SRVCC fire later, not earlier. To pull SRVCC in earlier (serving cell less degraded) you raise b2Threshold1Rsrp. Reducing it does the opposite of what you want.
Reduce these to speed it up instead:
- timeToTriggerB2 — lower it so B2 confirms faster.
- hysteresisB2 — lower it; it’s added to serving RSRP in the entry condition.
If the delay is actually the target UTRAN cell rarely qualifying, that’s the other side: b2Threshold2RscpUtra (or b2Threshold2EcNoUtra if measQuantityUtraFDD = EcNo) — lower that so the target qualifies sooner.
If Service Triggered Mobility / QCI1 offsets are active for VoLTE, the effective QCI1 serving threshold is b2Threshold1Rsrp + b2Threshold1RsrpUtraOffset — move the offset, not the base.
GERAN target is the same pattern in ReportConfigB2Geran (b2Threshold1Rsrp serving, b2Threshold2RssiGeran target).
We are doing SRVCC from LTE cell to GERAN. SRVCC is happening at -121 dbm. But the tester wanted at -115 dbm. I changed b2Threshold1rsrp to -115 for MO configB2geran, but tester didn’t observed any changes
these are the current values, b2Threshold1Rsrp -115
b2Threshold1Rsrq -195
b2Threshold2Geran -100
hysteresisB2 10
hysteresisB2RsrqOffset 0
reportConfigB2GeranId 1
timeToTriggerB2 480
timeToTriggerB2Rsrq 640
triggerQuantityB2 0 (RSRP)
Total: 1 MOs
No change happened because b2Threshold1Rsrp was already -115 in your dump — you set it to the value it already had, so it was a no-op.
And -115 wouldn’t give a -115 trigger anyway. hysteresisB2 10 = 5 dB, and the entry condition is serving RSRP + hysteresisB2 < b2Threshold1Rsrp, so the real trigger = -115 − 5 = -120 dBm, plus timeToTriggerB2 480 ms of further fade → the -121 you’re seeing. The math matches your field number exactly.
To trigger at -115 dBm, set the serving threshold 5 dB higher to cancel the hysteresis:
b2Threshold1Rsrp = -110 (−110 − 5 dB hysteresis = −115)
on the same ReportConfigB2Geran MO you already edited. Then optionally timeToTriggerB2 480 → 320 to cut the confirmation lag.
Leave b2Threshold2Geran -100 (that’s the GERAN target side) and the Rsrq params (inactive, triggerQuantityB2 = RSRP).
Drive-test check: HO Required for SRVCC should now fire around -115 dBm, not -121.
-115 wouldn’t give a -115 trigger anyway: hysteresisB2 10 = 5 dB, entry condition is serving RSRP + hysteresisB2 < b2Threshold1Rsrp, so trigger = -115 − 5 = -120 dBm, plus timeToTriggerB2 480 ms of fade → the -121 you see.
For a -115 trigger, set it 5 dB higher to cancel the hysteresis, on the same ReportConfigB2Geran MO:
b2Threshold1Rsrp = -110 (−110 − 5 dB = −115)
Optionally timeToTriggerB2 480 → 320 to cut the lag. Leave b2Threshold2Geran -100 and the Rsrq params alone.
The multiplication factor 0.1 is the key — the stored value 10 is not 10 dB, it’s 10 × 0.1 = 1 dB of hysteresis, not 5 dB. Don’t change hysteresisB2.
So redo the math: trigger = b2Threshold1Rsrp − hysteresisB2 = -115 − 1 = -116 dBm (the extra drop to -121 is timeToTriggerB2 480 ms of fade during the confirmation window).
For a -115 dBm trigger:
b2Threshold1Rsrp = -114 (−114 − 1 dB = −115)
on ReportConfigB2Geran. Then timeToTriggerB2 480 → 320 to stop the level sliding further before the report fires. Leave hysteresisB2 at 10.
Thank you, I will do the modifications and will perform the test case.
Let me know the outcome
Sure,I will.
@Frutos My tester informed the SRVCC is still happening at -121/122dbm. Below are the updated values for ReportConfigB2Geran
b2Threshold1Rsrp -114
b2Threshold1Rsrq -195
b2Threshold2Geran -100
hysteresisB2 10
hysteresisB2RsrqOffset 0
reportConfigB2GeranId 1
timeToTriggerB2 480
timeToTriggerB2Rsrq 640
triggerQuantityB2 0 (RSRP)
A 1 dB change on b2Threshold1Rsrp (-115 → -114) with zero movement in the trigger (-121/-122 unchanged) is itself the answer: this ReportConfigB2Geran is not the config gating the SRVCC you’re testing. If this B2 were the lever, the trigger would have shifted with it. It didn’t move at all — so stop tuning this MO, you’ll chase it forever.
Two things to establish before touching any value again, both from a trace, not from the MO dump:
- Pull a UE trace / cell trace from the drive and read two things: the RRC Connection Reconfiguration measConfig the UE actually receives, and when it sends the B2 MeasurementReport. Either the UE never sends B2 until -121 — meaning it was given a different threshold than this MO, so SRVCC is bound to a different ReportConfig instance than the one you’re editing — or it sends B2 at ~-114 but SRVCC only executes at -121, meaning the gate is in HO Required / target selection, not the B2 threshold. Those are two completely different faults with different fixes, and the trace is the only thing that tells you which.
- Confirm reportConfigB2GeranId 1 is the ReportConfig actually bound to the SRVCC/QCI1 measurement for the cell under test, and that the cell you edited is the serving cell during the drive. If SRVCC is driven by a service-triggered mobility profile pointing at a different ReportConfig, this MO is inert for that call.
Send the release and that trace (B2 report RSRP + HO Required timing) and we target the real lever, instead of moving a threshold the UE may not even be using.