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/.
Harald Welte laforge at gnumonks.orgHi Holger, thanks a lot for debugging. On Sun, Jul 28, 2013 at 10:54:08PM +0200, Holger Hans Peter Freyther wrote: > On Sun, Jul 28, 2013 at 10:01:04PM +0200, Holger Hans Peter Freyther wrote: > > > /* Even if there is no P-TMSI allocated, the MS will switch from > > * foreign TLLI to local TLLI */ > > ctx->tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); > > > > /* Inform LLC layer about new TLLI but keep old active */ > > gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new, > > GPRS_ALGO_GEA0, NULL); > > > > > > So this tlli_new does not appear to be used at all and I don't see > > how/where we would use/create the OLD_TLLI IE? Is it implemented? It seems the BSSGP TLLI (old) is not implemented at this point, as dup->tlli is not set, as you indicated. > Okay, this appears to be incomplete. We would need to put dup.tlli in the > gprs_llc.c code if we want to send a TLLI (but then the PCU doesn't appear > to be bale to look-up the old tbf based on the IE_TLLI). 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: If an SGSN provides a second TLLI, indicating that an MS has recently changed its TLLI, this shall be considered as the "old" TLLI. A BSS uses the "old" TLLI to locate an MS's existing context. Subsequent uplink data transfers for this MS shall reference the current TLLI, and not the old TLLI. What strikes me as odd is that after we have received such a RAU_COMPLETE / ATTACH_COMPLETE, the SGSN is not sending any further GMM messages to the MS. So the BSSGP-DL-UD with the old TLLI is not sent until maybe a long time later, when the SGSN has something to transmit again. Meanwhile, the MS ca happily be sending uplink messages with the new TLLI. 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 SGSN shall include the IMSI in the PDU. As an exception, the SGSN may omit the IMSI in the PDU if the mobile station identified by the TLLI is in MM non-DRX mode period (i.e. during a GMM procedure for GPRS attach or routing area updating defined in GSM 24.008 [11]) and the SGSN does not have a valid IMSI. 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? > Do you have some documentation/brain-dump on how tlli/tlli_new, tlli > and old_tlli interact with each other? E.g. at which point should the > tlli_new be used? 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 ;) 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 a) generate the new (always local, ptmsi derived) TLLI and store it in mmctx->tlli_new. b) issue a LLGMM-ASSIGN.req primitive to LLC, where tlli_old = mmctx->tlli and tlli_new = tlli_new. This is the following clause in the spec: 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. 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. If TLLI Old = all 1's was assigned to the LLME, then this shall be treated as a TLLI assignment according to subclause 8.3.1, and the LLGMM-ASSIGN-REQ shall be the first primitive sent by GMM in order to enable LLC to process requests from layer 3. So basically, the _intended_ functionality is to accept both old and new TLLI for the time until we receive the ATTACH_COMPLETE / RAU_COMPLETE. After that point, the MS is permitted to only use the new TLLI. If we do a P-TMSI allocation (which we do as PTMSI_ALLOC is #defined), then the new TLLI will be completely different (LOCAL, derived from new P-TMSI) than the old one (LOCAL or foreign, based on old P-TMSI). If you disable PTMSI_ALLOC, then the new TLLI will just be the local version of the intiially (potentially) foreign TLLI. 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. > 1.) During the attach msgb_tlli(msg) will be the foriegn tlli > 2.) We will generate a tlli_new based on the reported tmsi... > 3.) We will llgm_assign the tlli_new and tlli. > 4.) msgb_tlli(msg) will still point to the foreign tlli > 5.) We send a Identity Request > 6.) gprs_llc will not provide a dup.tlli > 7.) bssgp_tx_dl_ud will use msgb_tlli(msg) and not put a IE_TLLI Which I so far assume to be what the code should do. The Identity request should still use the foreign TLLI, as we didn't send a ATTACH ACCEPT, ATTACH REJECT, RAU ACCEPT or RAU REJECT yet. The MS will continue to use the foreign TLLI until those messages are recieved: Quote from 04.08 4.7.1.4. i) If the MS has stored a valid P-TMSI, the MS shall derive a foreign TLLI from that P-TMSI and shall use it for transmission of the: - ATTACH REQUEST message of any GPRS combined/non-combined attach procedure; other GMM messages sent during this procedure shall be transmitted using the same foreign TLLI until the ATTACH ACCEPT message or the ATTACH REJECT message is received; and - ROUTING AREA UPDATE REQUEST message of a combined/non-combined RAU procedure if the MS has entered a new routing area, or if the GPRS update status is not equal to GU1 UPDATED. Other GMM messages sent during this procedure shall be transmitted using the same foreign TLLI, until the ROUTING AREA UPDATE ACCEPT message or the ROUTING AREA UPDATE REJECT message is received. After a successful GPRS attach or routing area update procedure, independent whether a new P-TMSI is assigned, if the MS has stored a valid P-TMSI then the MS shall derive a local TLLI from the stored P-TMSI and shall use it for addressing at lower layers. So the question is: What should be done for downlink messages at this point. "After receipt of the acknowledgement, the network shall use the local TLLI for addressing at lower layers. So during this time, using the msgb_tlli(msg) [which is the old, foreign TLLI received from the MS] as the TLLI in downlink messages like IDENTITY REQUEST seems 100% correct to me. > In terms of a patch (which is likely to break the PCU as it does > not support the old tlli): > > 1.) Use tlli_foreign2local in the look-up. 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 a) the foreign TLLI is matched because it is the msgb_tlli() at the time the LLME was allocated b) the old and new TLLI is matched after the first gprs_llgmm_assign() call. c) only the new TLLI is matched after the second gprs_llgmm_assign() call at RAU/ATTACH COMPLETE time IIRC, the foreign2local logic was introduced by me before we had a gprs_llgmm_assign() primitive and before I fully understood the spec in this part. It should be removed. > 2.) Sent the tlli_old if it is not UNASSIGNED and if it is > different to the msgb_tlli(msg). 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. > 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. > 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. Regards, Harald -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)