Hi,
I got this log from the pcu while using my E71 (the only sub in this network).
<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 all.
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).
comments? holger
Hi Holger,
Can you send full pcu tbf debug log for this attach procedure? I want to understand, in which place of TBF MS starts use new TLLI. What do you mean by "no content resolution on the UL"? As I know, there are content resolution on network side and on MS side. The contention resolution at one phase access is successfully completed on the MS side when the mobile station receives a PACKET UPLINK ACK/NACK. The contention resolution at two phase access is completed at MS when it receives the second uplink assignment message with its TLLI included.
Also I can't understand why we should use IMSI in pcu? Why it is not enough to use TLLI?
2013/10/27 Holger Hans Peter Freyther hfreyther@sysmocom.de:
Hi,
I got this log from the pcu while using my E71 (the only sub in this network).
<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 all.
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).
comments? holger
--
- Holger Freyther hfreyther@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
On Mon, Oct 28, 2013 at 06:17:50PM +0400, Ivan Kluchnikov wrote:
Hi Holger,
Hi,
Can you send full pcu tbf debug log for this attach procedure? I want to understand, in which place of TBF MS starts use new TLLI. What do you mean by "no content resolution on the UL"?
s/content resolution/contention resolution/. Sorry.
I don't have a log file but with the routing area update, the SGSN may assign a new P-TMSI and if a new P-TMSI was assigned with the "Accept" message, a "Complete" message needs to be generated by the MS. This message can/should already contain the new TLLI (which is derived from the P-TMSI).
Also I can't understand why we should use IMSI in pcu? Why it is not enough to use TLLI?
The TLLI is either random (I have not seen this), foreign or local. In the last two cases it is derived from the P-TMSI. The P-TMSI can change (e.g. at routing area update).
2013/10/28 Holger Hans Peter Freyther hfreyther@sysmocom.de:
I don't have a log file but with the routing area update, the SGSN may assign a new P-TMSI and if a new P-TMSI was assigned with the "Accept" message, a "Complete" message needs to be generated by the MS. This message can/should already contain the new TLLI (which is derived from the P-TMSI).
Ok, I will try to reproduce it.
On Mon, Oct 28, 2013 at 10:02:45PM +0400, Ivan Kluchnikov wrote:
2013/10/28 Holger Hans Peter Freyther hfreyther@sysmocom.de:
Ok, I will try to reproduce it.
It should happen on every attach and routing area update. E.g. if you have periodic updating enabled in the NITB you should see this behavior (bug) every time.
I intend to look at it during wednesday. My current trial will be to change code in here[1]. When the TLLI is changing try to find other TBFs (e.g. if we ever support multiple tbf assignment) and update the TLLI as well.
I would also say that if the tlli is changed, it is valid. So the separate "mark valid" function is probably not needed. But I need to modify the code in bts.cpp for that.
holger
[1] http://git.osmocom.org/osmo-pcu/tree/src/tbf.cpp?h=zecke/features/clean-up#n...
Hi,
Let me participate in the discussion to improve my understanding. If I see well the new TLLI (after changing by Attach Accept for example) may be obtained from the first RLC data block belonging to the UL TBF allocated for Attach Complete transfer (in the case of resource request on RACH) or from still existing DL TBF context (in the case the channel request is included in PACCH downlink packet ack/nack) where it has to be updated on P-TMSI change. For paging group choosing in the later stage (after attaching procedure) it's enough that IMSI is known in SGSN and delivered to pcu with the downlink packets.
Regards, Vladimir.
On Mon, Oct 28, 2013 at 5:23 PM, Holger Hans Peter Freyther < hfreyther@sysmocom.de> wrote:
On Mon, Oct 28, 2013 at 06:17:50PM +0400, Ivan Kluchnikov wrote:
Hi Holger,
Hi,
Can you send full pcu tbf debug log for this attach procedure? I want to understand, in which place of TBF MS starts use new TLLI. What do you mean by "no content resolution on the UL"?
s/content resolution/contention resolution/. Sorry.
I don't have a log file but with the routing area update, the SGSN may assign a new P-TMSI and if a new P-TMSI was assigned with the "Accept" message, a "Complete" message needs to be generated by the MS. This message can/should already contain the new TLLI (which is derived from the P-TMSI).
Also I can't understand why we should use IMSI in pcu? Why it is not enough to use TLLI?
The TLLI is either random (I have not seen this), foreign or local. In the last two cases it is derived from the P-TMSI. The P-TMSI can change (e.g. at routing area update).
--
- Holger Freyther hfreyther@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
On Sun, Oct 27, 2013 at 01:33:13PM +0100, Holger Hans Peter Freyther wrote:
Hi,
<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
this is from a routing area update (with some printf debugging):
TBF(TFI=0 TLLI=0xb68154e6 DIR=DL) TLLLI changed...... 0xb68154e6->0xc782d1de <0002> tbf.cpp:1626 TBF(TFI=0 TLLI=0xb68154e6 DIR=DL) changing tlli to TLLI=0xc782d1de <0002> bts.cpp:941 Got ACK, but UL TBF is gone TLLI=0xc782d1de <0007> gprs_rlcmac_meas.cpp:158 DL packet loss of IMSI=274080000004765 / TLLI=0xc782d1de: 0% <0002> tbf.cpp:664 TBF(TFI=0 TLLI=0xb68154e6 DIR=UL) T3169 timeout during transsmission <0002> tbf.cpp:686 - Assignment was on PACCH <0002> tbf.cpp:690 - No uplink data received yet
So the DL TLLI has been changed and then we get an ACK for a UL tbf with the new TLLI and can't find it. And run into a timeout.
I have applied this change:
diff --git a/src/tbf.cpp b/src/tbf.cpp index fac5aaf..19bb83c 100644 --- a/src/tbf.cpp +++ b/src/tbf.cpp @@ -1618,6 +1618,17 @@ void gprs_rlcmac_tbf::update_tlli(uint32_t tlli) if (tlli == m_tlli) return;
+ printf("%s TLLLI changed...... 0x%08x->0x%08x\n", + tbf_name(this), m_tlli, tlli); + + if (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; + } + #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);
and now the "Attach Complete" comes immediately after the Attach Accept. I will push something like this but we really need a better way to link the DL/UL TBFs together.
holger
Holger Hans Peter Freyther wrote:
printf("%s TLLLI changed...... 0x%08x->0x%08x\n",tbf_name(this), m_tlli, tlli);if (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;}
oops, i am sorry. i did not read all the follow-ups before answering your message...
the update of both DL and UL TBFs seems to be a good solution.
in the function above you wrote this comment:
|* 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.
how can we have multiple TBFs for a single direction? i don't see anything like this in the specs.
|
Holger Hans Peter Freyther wrote:
<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)
hi holger,
can you provide the complete log, starting with the attach request? i looked at the gprs_rlcmac_rcv_control_block() function which already handles some TLLI change, but i am not sure if there is a bug or if there must be some other way to handle TLLI change.
regards,
andreas
On Tue, Nov 05, 2013 at 08:14:05AM +0100, Andreas Eversberg wrote:
Dear Andreas,
can you provide the complete log, starting with the attach request? i looked at the gprs_rlcmac_rcv_control_block() function which already handles some TLLI change, but i am not sure if there is a bug or if there must be some other way to handle TLLI change.
everything that is needed to understand/reproduce the issue has been posted. There is now even a unit test for this behavior.
holger
osmocom-net-gprs@lists.osmocom.org
-
Andreas Eversberg -
Holger Hans Peter Freyther -
Ivan Kluchnikov -
Vladimir Rolbin