tbf: Learn and propagate the TLLI changes due a new P-TMSI
During a routing area update a new P-TMSI was assigned. During
the PACKET CONTROL ACK on the DL we notice the change of TLLI
but didn't propagate this. This means that a Routing Area Update
Complete was only sent after a new RACH request.
Addresses:
<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
diff --git a/src/tbf.cpp b/src/tbf.cpp
index fac5aaf..d78090f 100644
--- a/src/tbf.cpp
+++ b/src/tbf.cpp
@@ -1618,9 +1618,32 @@
if (tlli == m_tlli)
return;
-#warning "TODO.. find the DL/UL opposite and update the TLLI too"
- LOGP(DRLCMAC, LOGL_NOTICE, "%s changing tlli to TLLI=0x%08x\n",
- tbf_name(this), tlli);
+ bool changedUl = false;
+
+ /*
+ * During a Routing Area Update (due the assignment of a new
+ * P-TMSI) the tlli can change. We notice this when receiving
+ * a PACKET CONTROL ACK.
+ * When we get a TLLI change on the DL we will look if there
+ * is a UL TBF and change the tlli there as well.
+ *
+ * TODO: There could be multiple DL and UL TBFs and we should
+ * have a proper way to link all the related TBFs so we can do
+ * a group update.
+ */
+ if (m_tlli_valid && direction == GPRS_RLCMAC_DL_TBF) {
+ gprs_rlcmac_tbf *ul_tbf;
+ ul_tbf = bts->tbf_by_tlli(m_tlli, GPRS_RLCMAC_UL_TBF);
+
+ if (ul_tbf) {
+ ul_tbf->m_tlli = tlli;
+ changedUl = true;
+ }
+ }
+
+ LOGP(DRLCMAC, LOGL_NOTICE,
+ "%s changing tlli from TLLI=0x%08x TLLI=0x%08x ul_changed=%d\n",
+ tbf_name(this), m_tlli, tlli, changedUl);
m_tlli = tlli;
}