This commit rejects an UE that connects by sending RRCConnectionRequest with S-TMSI.
The observed behavior (samsung phone, lte dongle, sequans box) is that the UE keeps connecting over and over again.
when you say "keeps connecting over and over again" how does it connect? Again with S-TMSI or with the initial procedure?
We've been talking about this for a day now.
The conclusion is this:
- THere is no way to signal the UE anything in the RRC layer (RRCConnectionReject does not hold any cause information).
- If we do the reject what this patch does, there is a chance that a UE will stuck in this state and keep retrying with S-TMSI, cause the specs. does not tell explicitly what to do, so there is a high chance that the behavior of the UE in a consecutive RRCReject event will be implementation (vendor) dependent.
- Because of this what we can do is to send an explicit (MME originated) Detach with the "Re-Attach required" required flag set. This also not guarantees that the UE will not try with the S-TMSI again, it needs testing, but still it seems a better way.
- But in the end there is a high chance that we will need to implement S-TMSI handling anyway, cause even if its optional, it seems there is no proper way to handle this through signalling.
Hi Csaba, thanks for this clarification.
Yes, "keeps connecting over and over again" means the UE does it over and over with S-TMSI, at least the ones I tried (with the sequans right now for example). This really was just a test. I still prefer it than the Assert because the eNB does not crash anymore here. But yes, as Csaba says, we need to handle this case properly.
"I still prefer it than the Assert because the eNB does not crash anymore"
Totally aggree with that.