Fwd: Losing ACKs due TLLI changes?

Vladimir Rolbin vrolbin at gmail.com
Thu Oct 31 09:08:34 UTC 2013


>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.html>


More information about the osmocom-net-gprs mailing list