Attention is currently required from: fixeria, laforge.
1 comment:
Commit Message:
and there
is no way for the PFCPEM to correlate which session belongs to which eNB.
are we 100% sure this is the case?
I could not find an obvious solution that would help with identifying PFCP sessions unambiguously on the wire, so I came up with this Mutex based solution (next patches in this patchset).
Can we not somehow make osmo-s1gw include some kind of IE that allows us to correlate which UE (Iu context, whatever) has caused that PFCP request?
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 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.
This would not only be useful here in the TTCN3 tests, but also any later debugging. Would be great if a PFCP message could be associated with the Iu connection when looking at traces in wireshark etc.
> 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? Also, we should probably move this discussion to the respective patch and make this one WIP for now.
In terms of 3GPP standard IEs, we could include the IMSI of the UE in the "User ID" IE (29.244 Section 8.2.101) for the PFCP session establish request. This would at least allow us to support "one concurrent session establishment per UE". That should be fine for your current use case?
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.
To view, visit change 38206. To unsubscribe, or for help writing mail filters, visit settings.