This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Holger Hans Peter Freyther holger at freyther.deOn 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