20 Sep
2024
20 Sep
'24
3:45 p.m.
Attention is currently required from: fixeria, laforge.
fixeria has posted comments on this change by fixeria. (
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email )
Change subject: library: add generic Mutex API for parallel components
......................................................................
Patch Set 2:
(1 comment)
Commit Message:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206/comment/99af334a_6ece…
:
PS2, Line 14: 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 https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email
To unsubscribe, or for help writing mail filters, visit
https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: Id71f43bd5fc78d4bb4417d6c01fcff8112ea6032
Gerrit-Change-Number: 38206
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 20 Sep 2024 13:45:40 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>