Losing ACKs due TLLI changes?

Holger Hans Peter Freyther hfreyther at sysmocom.de
Sun Oct 27 12:33:13 UTC 2013


I got this log from the pcu while using my E71 (the only sub in this

<0007> gprs_rlcmac_meas.cpp:103 UL RSSI of TLLI=0x88661bc6: -67 dBm
<0002> bts.cpp:945 Got ACK, but UL TBF is gone TLLI=0xe512eba3
<0007> gprs_rlcmac_meas.cpp:158 DL packet loss of IMSI=274080000004765 / TLLI=0xe512eba3: 0%
<0002> tbf.cpp:668 TBF TFI=0 TLLI=0x88661bc6 T3169 timeout during transsmission
<0002> tbf.cpp:690 - Assignment was on PACCH
<0002> tbf.cpp:694 - No uplink data received yet

So there is an ACK for TLLI=0xe512eba3 but at the same time the tlli
0x88661bc6 is timing out.

PCU->SGSN TLLI=0x88661bc6 Attach Request
SGSN->PCU TLLI=0x88661bc6 Attach Accept (new P-TMSI)
PCU->SGSN TLLI=0xe512eba3 Attach Complete (new TLLI) (6s later)

Now the question is how the PCU should behave. I think the MS is
allowed to change the TLLI (after a P-TMSI assignment) after the
contention resolution is completed. From my reading there is no content
resolution on the UL. My E71 appears to run into a timeout and then
issue a RACH request to send the Attach Complete. I think I have
seen other equipment failing to transmit the Attach Complete at

I think for the SGSN -> PCU side we should generally look things up
by IMSI (there is already a warning in the code), for the MS->PCU
side. I think we should store the old and new TLLI (and then put
new_tlli into tlli once the new one is being used).


- Holger Freyther <hfreyther at sysmocom.de>       http://www.sysmocom.de/
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

More information about the osmocom-net-gprs mailing list