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
