Project

General

Profile

Feature #1530

Assign same TFI number in downlink/uplink

Added by zecke over 4 years ago. Updated 9 months ago.

Status:
New
Priority:
Low
Assignee:
-
Target version:
-
Start date:
02/22/2016
Due date:
% Done:

0%

Spec Reference:

Description

        // 12-22-2011: It looked like the Blackberry abandoned an uplink TBF when
        // a downlink TBF was established using the same TFI.   This seems like a horrible
        // bug in the MS, but to work around it, I added the gFixTFIBug which uses
        // a single TFI space for both uplink and downlink.  This eliminated
        // a bunch of msStop calls with cause T3101, so I think this is a genuine
        // problem with MSs and we need this fix in permanently.
        // Update: The TFI is reserved during the time after a downlink ends, so the MS
        // may have been justifiably upset about seeing it reissued for an uplink too soon.

The above is from the OpenBTS code and we should assume this to be a valid issue. In general Jolly's code can also end-up in the situation where DL/UL think they have a common control_ts but in fact they are different. One way to resolve this would be to create a "MS" structure that holds IMSI, TLLI, TFI a pointer to the UL TBF and one to the DL (we don't support multiple TBF anyway). This way we could make sure the reservation is done in the right way.

History

#1 Updated by zecke over 4 years ago

From Jacob:

This might have been related to the old/new TBF handling in those days. Today the MS object keeps track of all active TBF (there can be more than 2 at a time sometimes) and the TFI of all of them are blocked until a timeout expires or a TBF is replaced by another of the same direction.
Thus an too early reuse of a TFI shouldn't happen.

Downlink and uplink TFI are managed independently and is is possible that both directions get the same value. But I haven't observed any problems of this kind with the E71 and the iphone.

#2 Updated by laforge over 2 years ago

  • Assignee deleted (msuraev)

#3 Updated by pespin 9 months ago

My understanding on the current status of this ticket:

There's 2 different issues:
  1. TFI assigned too early: This was fixed a long time ago according to comments about support for related timers. It may be helpful writing a TTCN3 which tries to exhaust TFIs to make sure.
  2. some MS may not like sharing same TFI value for uplink and downlink. This could be fixed by having a common TFI pool for both directions (modify BTS::tfi_find_free() to check both directions). It is still not clear though if this is really an issue for some MS or they failed due to the issue listed in the previous point.

So one would need to test with a blackberry on current osmo-pcu (not one from 4 years ago) and see if there's some TFI issue there, then add some VTY command to enable a common TFI pool if wanted by the user.

Not sure how worth is all this work.

#4 Updated by laforge 9 months ago

On Wed, Jan 22, 2020 at 03:52:54PM +0000, pespin [REDMINE] wrote:

So one would need to test with a blackberry on current osmo-pcu (not one from 4 years ago) and see if there's some TFI issue there, then add some VTY command to enable a common TFI pool if wanted by the user.

not worth it, AFAIK.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)