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)