This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.
Vladimir Rolbin vrolbin at gmail.com>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 at 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 at 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20131031/44e50ba6/attachment.htm>