<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">>I don't understand that part? What happens here is that we poll for</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">>a PACKET CONTROL ACK. So we know the TBF based on the FN. </span><br>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Here is an example (You may open the messages in 3GPP message decoder), RRBP = 0, so UL FN = DL FN + 13. </span><span style="font-family:arial,sans-serif;font-size:13px">DL FN is </span><span style="font-size:13px;font-family:arial,sans-serif">known in </span><font face="arial, sans-serif">gprs_rlcmac_rcv_rts_block:</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><div>1379410063.708403 3031788400: [ PCU -> BTS ] PACCH: TS 6 FN 1885970 FN52 34 CNTRL1 raw=(4f2856d9f9fce301a004880801052b2b2b2b2b2b2b2b2b) DL_PACKET_UPLINK_ASSIGNMENT</div>
<div>1379410063.828722 <a href="tel:3064122224" value="+13064122224" target="_blank">3064122224</a>: [ BTS -> PCU ] PhDataInd TS:6 FN:1885983 FN52:47 CNTRL1 raw=(4006db3f3f9f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b) UL_PACKET_CONTROL_ACKNOWLEDGEMENT</div>
<div><br></div><div><br></div><div>
<span style="font-size:13px">>And in this</span><br style="font-size:13px"><span style="font-size:13px">>TBF we notice that the TLLI has changed (ACK is using the new TLLI</span><br style="font-size:13px"><span style="font-size:13px">>that is derived from the P-TMSI).</span><br>
</div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Yep.. I guess so.</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">></span><span style="font-size:13px">From an engineering point of view</span><span style="font-size:13px"> I think linking makes sense because:</span><br style="font-size:13px">
<br style="font-size:13px"><span style="font-size:13px">>* With multiple TBF assignment the tbf_by_tlli will return a list</span><br style="font-size:13px"><span style="font-size:13px"> anyway.</span><br style="font-size:13px">
<span style="font-size:13px">>* For the multiple RACH cases we could it probably handle it more</span><br style="font-size:13px"><span style="font-size:13px"> >nicely.</span><span style="font-size:13px"><br></span></div>
<div><span style="font-size:13px"><br></span></div><div>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.</div>
<div>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 </div><div>context simply inherit the critical data like TA.. Anyway it's only my opinion.</div>
<div><br></div><div><br></div><div><br></div><div><span style="font-size:13px">>E.g. avoid this:</span><br style="font-size:13px"><span style="font-size:13px">><0005> bts.cpp:1035 Got RACH from TLLI=0xcf7611f6 while TBF(TFI=0 TLLI=0xcf7611f6 DIR=DL) still exists. Killing pending DL TBF</span><br style="font-size:13px">
<span style="font-size:13px">><0002> bts.cpp:359 Got IMM.ASS confirm, but TLLI=cf7611f6 does not exit</span><br></div><div><br></div><div>To my mind it's strange situation. If the DL flow still exists why the MS requests resources on RACH?</div>
<div><br></div><div><br></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px"><br></span></div></font></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 30, 2013 at 7:18 PM, Holger Hans Peter Freyther <span dir="ltr"><<a href="mailto:hfreyther@sysmocom.de" target="_blank">hfreyther@sysmocom.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Oct 30, 2013 at 06:26:57PM +0200, Vladimir Rolbin wrote:<br>
<br>
> I don't see any print connected to the Uplink TBF request for "Attach<br>
> accept" (by MS). At this moment the TLLI has been already updated but UL<br>
> TBF still does not exist<br>
<br>
I don't understand that part? What happens here is that we poll for<br>
a PACKET CONTROL ACK. So we know the TBF based on the FN. And in this<br>
TBF we notice that the TLLI has changed (ACK is using the new TLLI<br>
that is derived from the P-TMSI).<br>
<br>
<br>
> (what bts->tbf_by_tlli(m_tlli, GPRS_RLCMAC_UL_TBF) returns?). Corresponding<br>
> to TS 04.60, 11.2.29 Packet Uplink Assignment possibly may use DL TFI to<br>
> address the MS in place of TLLI (we still don't know if it's accepted or<br>
> not by MS). Also the uplink FN may be used to find corresponding UL TBF<br>
> context (according to Packet Uplink Assignment RRBP field) for UL Packet<br>
> Control Ack which contains relevant TLLI. So is it really necessary to<br>
> link UL and DL TBFs in the case? ...<br>
<br>