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,
On Mon, Jul 29, 2013 at 08:26:32AM +0200, Holger Hans Peter Freyther wrote:
> Okay. That does make sense. Thanks for going through the specs.
No problem, I looked at this TLLI issue again and again over the years,
and still there seem to be some bugs in the code :/
> > 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.
This is indeed broken. The TBF should be looked up by the IMSI.
Looking it up by TLLI should only be neccessary if the BSSGP-DL-UD has
no IMSI in it (e.g. the IDENTITY REEQUEST (IMSI) after an ATTACH REQUEST
with unknown P-TMSI).
> > 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).
But the LLGMM-ASSIGN.req that we issue at that point (with old and new
tlli != 0xffffffff) explicitly enables both old and new IMSI for uplink,
see my other mail. This is what I believe to be the right thing at that
point. In this case (old and new != all-1) both the new and the old
tlli are accepted.
> > 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.
Yes, we basically override the LLC logic of "accept old and new in Rx,
use new in tx" specifically by setting msgb_tlli(msg) manually to the
old tlli.
The point is, until the GMM message assigning a new P-TMSI has been
successfully received by the MS, the MS has no clue what the new TLLI
might be. So until the SGSN knows that this GMM message has been
successfully received by the MS, the SGSN should continue to use the old
TLLI in downlink. Only once the MS has acknowledged in GMM that the new
P-TMSI has been received (by RAU_COMPLETE / ATTACH_COMPLETE), the SGSN
knows that the MS has successfully switched to the new TLLI. Also, at
the same time, any frame that wer receive from the MS using the new TLLI
will implicitly tell us (even at the LLC layer, without involving GMM)
that the MS has received the new P-TMSI, because it starts to use it.
The specs seem to have some contradiction here. If you look at
24.008 it says in 4.7.1.4.1:
Although the MS derives a local TLLI for addressing at lower layers,
the network should not assume that it will receive only LLC frames
using a local TLLI. Immediately after the successful GPRS attach or
routing area update procedure, the network must be prepared to
continue accepting LLC frames from the MS still using the foreign
TLLI.
Which is a bit odd. Why would we receive old TLLI _after_ the
respective COMPLETE messages?
But at least for downlink, it is pretty clear:
In both cases, the MS shall acknowledge the reception of the assigned
P-TMSI to the network. After receipt of the acknowledgement, the
network shall use the local TLLI for addressing at lower layers.
Furthermore:
Upon receipt of a GMM message containing a new P-TMSI the MS shall
consider the new P-TMSI and new RAI and also the old P-TMSI and old
RAI as valid in order to react to paging requests and downlink
transmission of LLC frames.
For uplink transmission of LLC frames the new P-TMSI shall be used.
i.e. the ATTACH_COMPLETE/RAU_COMPLETE should be the first message with
the new TLLI.
And:
The MS shall consider the old P-TMSI and old RAI as invalid as soon as
an LLC frame is received with the local TLLI derived from the new
P-TMSI.
So maybe we should send an empty frame (LLGMM-TRIGGER.req? but that
exists only on the MS side of LLC, not the SGSN side) in downlink after
the RAU_COMPLETE / ATTACH_COMPLETE with the new TLLI? However, the
transmission is unreliable and it could get lost. So I guess there's no
point in even trying to send a message with new TLLI to the MS, if we
don't get a layer3-acknowledgement back.
So the only really odd part is that 04.64 states that after
LLGMM-ASSIGN(old!=ff, new!=ff) we should use the new TLLI for downlink
transmit, while 24.008 states that we should continue to use the old
TLLI for downlink transmit until we receive the ATTACH_COMPLETE and/or
first uplink LLC message with new TLLI.
As I don't know of what use the 04.64-specified behavior (receive
old+new, transmit with new only) should be, I think it might be wrong
and actually the behavior should be that tx should be done with old
TLLI.
In order to still have LLGMM-ASSIGN.req like specified in 04.64 _and_
fulfill the 24.008 requirements, we override the outgoing TLLI by using
msgb_tlli(msg) = mmctx->tlli (which is the old tlli) in GMM.
> > 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?
yes, this appears to be correct (and thus maybe good that dup.tlli is
not set in current code). In order to do this as per spec (which is
stupid, as the PCU has the IMSI to identify the MS), we would probably
have to keep a flag in the LLME indicating that 'recently the old tlli
was unassigned'. During transmission of the next downlink frame (which
may be hours later!) we then include that 'very_old_tlli' as second
IE_TLLI in the BSSGP-DL-UD. However, if it is really that much later,
then there is no TBF anymore in the PCU anyway ;) So this all only
makes sense if the SGSN is _soon_ after the TLLI/P-TMSI change sending
moere data (signalling or user-data) in downlink.
As TBFs have a very short life-time, I would currently argue to simply
ignore (+ document) this behavior for Gb. Make sure that osmo-pcu uses
the ISMI if present, and hope that other PCU implementors also do it
that way.
> Okay, I will modify the lle_by_tlli_sapi look-up to not use the
> foreign conversion at all. This would fix my case..
Great. I will do some manual testing with sysmobts/osmo-pcu/osmo-sgsn
using that patch later tonight.
> but given the lack of unit tests I don't know what I break. :)
ah well, just be brave :)
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)