TLLI problems and proposed solution

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.org
Mon Jul 29 10:04:05 UTC 2013


Hi Holger,

On Mon, Jul 29, 2013 at 08:08:18AM +0200, Holger Hans Peter Freyther wrote:
> > Which I believe is correct. The RAU_COMPLETE / ATTACH_COMPLETE should be
> > the first message in downlink containing the new TLLI from my point of
> > view.
> 
> Thank you for the detailed answer (in the other email). But doesn't this
> mean that the gprs_llgmm_assign in gsm48_rx_gmm_att_req is a bit early?
> 
> E.g. something like this:
> 
>         /* Inform LLC layer about new TLLI but keep old active */
> -       gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new,
> +       gprs_llgmm_assign(ctx->llme, 0xffffffff,, ctx->tlli,

Why?

This would be the following case:

LLGMM-ASSIGN.req (7.2.1.1 of 04.64):
The TLLI Old and TLLI New parameters shall be interpreted as follows:
  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.

This would mean that the tlli_old (which is stored in the LLME up to the
call to your proposed "gprs_llgmm_assign(ctx->llme, 0xffffffff, ctx->tlli")
would no longer be accepted on the Rx side.

However, what we want at this point is to accept old _and_ new TLLI,
which is:

LLGMM-ASSIGN.req (7.2.1.1 of 04.64):
The TLLI Old and TLLI New parameters shall be interpreted as follows:
  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.

So we accept both old and new from the MS, which is what we want.
However, to my understanding, we actually don't want to use the new TLLI
for TX, which is why we use msgb_tlli(msg) = old_tlli to explicitly
request that tlli to be used.

So I still think that at least _this_ part of the existing code is doing
it right.

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)




More information about the OpenBSC mailing list