20 Sep
2024
20 Sep
'24
4:32 p.m.
Attention is currently required from: fixeria.
laforge 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: Code-Review+1
(1 comment)
Commit Message:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206/comment/ad03cca5_3a93…
:
PS2, Line 14: and there
: is no way for the PFCPEM to correlate which session belongs to which eNB.
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.
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? 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 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-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 20 Sep 2024 14:32:56 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>