On Mon, Jul 29, 2013 at 10:19:26AM +0800, Harald Welte wrote:
dup->tlli should be set to the old TLLI, _if_ there
has just been a
change of TLLI. So basically at the time the
gprs_llgmm_assign(old_tmsi=0xffffffff, new_tmsi=....) is happening when
we get the RAU_COMPLETE / ATTACH_COMPLETE in GMM. At that point, the
next BSSGP_DL_UD should have the "TLLI (old)" IE. Only at that point we
can be sure that any further messages from the MS will contain only the
new TLLI, which is indicated by the BSSGP spec:
Okay. That does make sense. Thanks for going through the specs.
I'm not really sure if a PCU really needs this, at
least not as long as
we always include the IMSI as part of BSSGP Downlink Unitdata. At that
point, the PCU can look-up its MS-contaxt based on the IMSI. The spec
says:
The osmo-pcu is broken in this regard. It will only use the TLLI to
identify the temporary block flow (tbf). I will shuffle the code
around to resolve that limitation and create unit tests for that.
So this would be the case if we get an ATTACH_REQ or
RAU_REQ with P-TMSI
only, but have not yet sent the IDENTITY REQUEST or not received the
IDENTITY RESPONSE yet. At that point, we don't issue any llgmm_assign()
requests to LLC yet, and thus are guaranteed that we always know the
IMSI at the time we have a TLLI change.
Do you agree?
Yes, but we do issue llgm_assign in that case (and that is the case
I can simulate right now). I think the llgm_assign should just be for
the foriegn tlli we received (and not from the one dervied by the
P-TMSI that we didn't allocate).
The tlli_new in the mm-context is only used to call
the
gprs_llgmm_assign() function (resembling 1:1 a LLGMM-ASSIGN.req
primitive in 04.64). So in theory, we should not need to keep it in the
mmcontext, but I think it's better to keep it, if not only for
debugging aid ;)
okay, this duplication confused me a bit.
The higher layers of the SGSN (GMM, etc.) don't need the tlli_new for
any other reason. Basically, at time of receiving/processing the ATTACH
or the RA UPDATE, we
If TLLI Old ≠ all 1's and TLLI New ≠ all
1's then TLLI Old and TLLI
New are assigned, and TLLI New shall be used when (re-)transmitting
LLC frames. Both TLLI Old and TLLI New shall be accepted when
received from the peer. It shall be treated as a TLLI change
according to subclause 8.3.2.
but for the above ATTACH case with a unknown P-TMSI/TLLI. We will do
the assignment but use TLLI Old for the transmissionof any frame.
Later, when we get the ATTACH_COMPLETE / RAU_COMPLETE
from the MS,
we
a) set mmctx->tlli = mmctx->tlli_new
b) issue a LLGMM-ASSIGN.req primitive to LLC with old TMSI 0xffffffff
and new TMSI = mmctx->tlli_new. According to spec, this is the
following case:
If TLLI Old = all 1's and TLLI New ≠ all 1's then TLLI New shall be
assigned and used when (re-)transmitting LLC frames. If a TLLI Old ≠
all 1's was assigned to the LLME, then TLLI Old is unassigned. Only
TLLI New shall be accepted when received from the peer. It shall be
treated as a TLLI change according to subclause 8.3.2.
but that means that llme->old_tlli will be all 1's and that even if
we want to.. in gprs_llc we could not set dup.tlli to the previous tlli?
So the next download unitdata can not have the IE_TLLI set?
The foreign/local handling in gprs_llc is different
from the spec as it
predates my full undestanding of specified the TLLI handling. So when
we look-up a LLME based on TLLI, we _always_ convert from foreign2local
during a lookup, which is not according to spec. At the time window
during which the foreign _and_ local TLLI shall be accepted, old_tlli
should be the foreign one and tlli should be the (new) local one, i.e.
the lookup works even without any foreign2local conversion of the lookup
key.
Okay, I will modify the lle_by_tlli_sapi look-up to not use the
foreign conversion at all. This would fix my case.. but given the
lack of unit tests I don't know what I break. :)
This would continue to use the current logic, which is
more liberal than
the spec [see above]. A better approach might be to remove the
tlli_foreign2local() in the lle_by_tlli_sapi() function. This way we
ensure that
okay.
see above, I'm not quite sure if that would work.
Irrespective of BSSGP
spec compliance with non-osmo PCUs, in osmo-pcu we can always look-up by
IMSI.
which we don't[1]. The TBF is only searched by tlli. But that is for
another mailinglist..
I would also like to assert
that msgb_tlli(msg) is not equal to mmctx->llme->tlli/old_tlli.
makes sense, particularly once we remove the foreign2local logic.
okay.
3.) Use the newly assigned tlli as the default.
from which point on? Only _after_ the RAU_COMPLETE / ATTACH_COMPLETE,
which I believe we already do now.
yeah, nothing to be done here.
thanks for the clarifications
holger
[1]
http://git.osmocom.org/osmo-pcu/tree/src/gprs_bssgp_pcu.cpp#n151