30 Oct
2013
30 Oct
'13
5:26 p.m.
Hi,
I don't see any print connected to the Uplink TBF request for "Attach
accept" (by MS). At this moment the TLLI has been already updated but UL
TBF still does not exist
(what bts->tbf_by_tlli(m_tlli, GPRS_RLCMAC_UL_TBF) returns?). Corresponding
to TS 04.60, 11.2.29 Packet Uplink Assignment possibly may use DL TFI to
address the MS in place of TLLI (we still don't know if it's accepted or
not by MS). Also the uplink FN may be used to find corresponding UL TBF
context (according to Packet Uplink Assignment RRBP field) for UL Packet
Control Ack which contains relevant TLLI. So is it really necessary to
link UL and DL TBFs in the case? ...
Regards,
Vladimir Rolbin
On Wed, Oct 30, 2013 at 1:17 PM, Holger Hans Peter Freyther <
hfreyther(a)sysmocom.de> wrote:
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
30 Oct
30 Oct
6:18 p.m.
On Wed, Oct 30, 2013 at 06:26:57PM +0200, Vladimir Rolbin wrote:
I don't see any print connected to the Uplink TBF
request for "Attach
accept" (by MS). At this moment the TLLI has been already updated but UL
TBF still does not exist
I don't understand that part? What happens here is that we poll for
a PACKET CONTROL ACK. So we know the TBF based on the FN. And in this
TBF we notice that the TLLI has changed (ACK is using the new TLLI
that is derived from the P-TMSI).
(what bts->tbf_by_tlli(m_tlli, GPRS_RLCMAC_UL_TBF)
returns?). Corresponding
to TS 04.60, 11.2.29 Packet Uplink Assignment possibly may use DL TFI to
address the MS in place of TLLI (we still don't know if it's accepted or
not by MS). Also the uplink FN may be used to find corresponding UL TBF
context (according to Packet Uplink Assignment RRBP field) for UL Packet
Control Ack which contains relevant TLLI. So is it really necessary to
link UL and DL TBFs in the case? ...
31 Oct
31 Oct
10:08 a.m.
I don't understand that part? What happens here is
that we poll for
a PACKET CONTROL ACK. So we know the TBF based on the FN.
Here is an example (You may open the messages in 3GPP message decoder),
RRBP = 0, so UL FN = DL FN + 13. DL FN is known in
gprs_rlcmac_rcv_rts_block:
1379410063.708403 3031788400: [ PCU -> BTS ] PACCH: TS 6 FN 1885970 FN52 34
CNTRL1 raw=(4f2856d9f9fce301a004880801052b2b2b2b2b2b2b2b2b)
DL_PACKET_UPLINK_ASSIGNMENT
1379410063.828722 3064122224: [ BTS -> PCU ] PhDataInd TS:6 FN:1885983
FN52:47 CNTRL1 raw=(4006db3f3f9f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
UL_PACKET_CONTROL_ACKNOWLEDGEMENT
And in this
TBF we notice that the TLLI has changed (ACK is using the new TLLI
that is derived from the P-TMSI).
Yep.. I guess so.
From an engineering point of view I think linking makes
sense because:
* With multiple TBF assignment the tbf_by_tlli will
return a list
anyway.
* For the multiple RACH cases we could it probably
handle it more
nicely.
The simpler things the better they work. TBFs are the instances with short
life. And with all respect to tlli the id that uniquely identifies the TBF
is TFI.
I think that independent TBF treatment is less complex. In the cases when
the new TBF is created while older TBSs still exist for the MS the new TBF
context simply inherit the critical data like TA.. Anyway it's only my
opinion.
E.g. avoid this:
<0005> bts.cpp:1035 Got RACH from TLLI=0xcf7611f6 while TBF(TFI=0
TLLI=0xcf7611f6 DIR=DL) still exists. Killing pending DL TBF
<0002> bts.cpp:359 Got IMM.ASS confirm, but
TLLI=cf7611f6 does not exit
To my mind it's strange situation. If the DL flow still exists why the MS
requests resources on RACH?
On Wed, Oct 30, 2013 at 7:18 PM, Holger Hans Peter Freyther <
hfreyther(a)sysmocom.de> wrote:
On Wed, Oct 30, 2013 at 06:26:57PM +0200, Vladimir
Rolbin wrote:
I don't see any print connected to the Uplink
TBF request for "Attach
accept" (by MS). At this moment the TLLI has been already updated but UL
TBF still does not exist
I don't understand that part? What happens here is that we poll for
a PACKET CONTROL ACK. So we know the TBF based on the FN. And in this
TBF we notice that the TLLI has changed (ACK is using the new TLLI
that is derived from the P-TMSI).
(what bts->tbf_by_tlli(m_tlli,
GPRS_RLCMAC_UL_TBF) returns?).
Corresponding
to TS 04.60, 11.2.29 Packet Uplink Assignment
possibly may use DL TFI to
address the MS in place of TLLI (we still don't know if it's accepted or
not by MS). Also the uplink FN may be used to find corresponding UL TBF
context (according to Packet Uplink Assignment RRBP field) for UL Packet
Control Ack which contains relevant TLLI. So is it really necessary to
link UL and DL TBFs in the case? ...
From an engineering point of view I think linking makes sense because:
* With multiple TBF assignment the tbf_by_tlli will return a list
anyway.
* For the multiple RACH cases we could it probably handle it more
nicely.
E.g. avoid this:
<0005> bts.cpp:1035 Got RACH from TLLI=0xcf7611f6 while TBF(TFI=0
TLLI=0xcf7611f6 DIR=DL) still exists. Killing pending DL TBF
<0002> bts.cpp:359 Got IMM.ASS confirm, but TLLI=cf7611f6 does not exit
--
- 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
3837
days inactive
3838
days old
osmocom-net-gprs@lists.osmocom.org
2 comments
2 participants
participants (2)
-
Holger Hans Peter Freyther -
Vladimir Rolbin