I agree, it only applies to SA.
I don’t think it happens that often.
The procedure is only applicable for UEs in poor coverage and missed the RRC connection release message from network.
I think, this is the recovery procedure defined by spec to handle the RRC connection mismatch between gNB and UE and also to see if the cell is still accessible or not.
I believe it is similar to initiating TAU after RLF in far cell and UE staying in limited service for a small duration.
This Registration may be just mobility update.
Guys, for RLF we have call re-establishment not registration.
This may be to handle UE reachability from Core NW, as first step after normal RLF is reestablishment.
I think this is for recovery. Because datainactivitytimer expiry is an abnormal case.
Mostly the timer set at network would be smaller than this timer and UE would get RRC release.
Now since this timer expiring is abnormal case, they introduced a recovery mechanism by registration so that UE is reachable by the network.
As defined in 24.501.
Yes, the same highlighted point f in the spec snippet covers this scenario too.
As soon as RLF is detected, RRC performs the RLF recovery.
If RLF recovery too fails, RRC indicates connection failure to NAS and NAS will trigger fresh signalling connection again.
It’s seen after rrc connection reestablishment request ue going for registration phase in SA.
It’s strange behaviour is it 3gpp defined?
Yes, snippets pasted above.
