Feature #1530
open
Assign same TFI number in downlink/uplink
Added by zecke about 8 years ago.
Updated over 4 years ago.
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.
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.
- Assignee deleted (
msuraev)
My understanding on the current status of this ticket:
There's 2 different issues:
- 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.
- 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.
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
