27 Oct
2013
27 Oct
'13
1:33 p.m.
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(a)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
28 Oct
28 Oct
3:17 p.m.
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(a)sysmocom.de>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(a)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
--
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
4:23 p.m.
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(a)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
7:02 p.m.
2013/10/28 Holger Hans Peter Freyther <hfreyther(a)sysmocom.de>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.
--
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
7:28 p.m.
On Mon, Oct 28, 2013 at 10:02:45PM +0400, Ivan Kluchnikov wrote:
2013/10/28 Holger Hans Peter Freyther
<hfreyther(a)sysmocom.de>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#…
--
- Holger Freyther <hfreyther(a)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
29 Oct
29 Oct
11:35 a.m.
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(a)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(a)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
30 Oct
30 Oct
12:17 p.m.
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 Freyther <hfreyther(a)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
5 Nov
5 Nov
8:39 a.m.
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.
|
8:14 a.m.
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
9:04 a.m.
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
--
- Holger Freyther <hfreyther(a)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
4240
days inactive
4249
days old
osmocom-net-gprs@lists.osmocom.org
9 comments
4 participants
participants (4)
-
Andreas Eversberg -
Holger Hans Peter Freyther -
Ivan Kluchnikov -
Vladimir Rolbin