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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)