31 Oct
2013
31 Oct
'13
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