Attention is currently required from: fixeria.
Patch set 2:Code-Review +1
1 comment:
Commit Message:
and there
is no way for the PFCPEM to correlate which session belongs to which eNB.
In theory, the S1GW could include a tuple of `{MME-UE-S1AP-ID, ENB-UE-S1AP-ID, e-RAB-ID}`, which would uniquely identify each PFCP session, even at the establishment phase.
I guess even only either MME-UE or ENB-UE side for S1AP-ID would be s ufficient in combination with the e-RAB-ID.
I was considering this at the beginning and the question I had is **what kind of IE**? I could not find suitable PFCP IEs for that and I was not sure if adding Osmocom specific IEs to simplify the job for the testsuite is worth it.
Would have been worth raising the question at the time, IMHO.
If we cannot find a good PFCP IE to include such identity information in, 3GPP TS 29.244 Section 5.9 states we may add vendor-specific IEs anywhere and any implementation not understanding them shall just ignore them: [...]
While I agree that it would also be useful for debugging, I've already put a significant effort into getting this implemented, debugged, and finally working. I hope we can get this merged for now and consider adding Osmocom specific IEs as a further improvement?
It's a bit of a double-edged sword. The mere fact that somebody has worked [far] on a given topic [without prior discussion] by itself doesn't make it the right thing to do, nor does it say we must merge it.
But yes, in this specific instance we can go ahead, the mutex approach is small/self-contained enough that it shouldn't be too hard to remove it later on, if needed.
IMSI is not easily accessible for the S1GW, since it's usually part of the inner NAS PDUs. Digging into NAS in the S1GW (and likely having to keep some context around) sounds like an overkill to me. Some S1AP PDUs, like the `INITIAL CONTEXT SETUP` carry masked IMEISV (not IMSI), which is optional and unlikely can be considered a unique identifier, since it's the serial number part that is being masked.
Indeed, the IMSI is of course not available on S1. I was probably thinking in terms of Iu. Definitely we *should* not dig into NAS or higher protocol layers. On the other hand, as you probably know we will sadly have to do that anyway soon (in s1gw) in order to get per-subscriber statistics.
To view, visit change 38206. To unsubscribe, or for help writing mail filters, visit settings.