Project

General

Profile

Actions

Bug #3055

closed

osmo-bts-trx: slow TA loop feedback

Added by fixeria about 6 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
osmo-bts-trx
Target version:
-
Start date:
03/10/2018
Due date:
% Done:

0%

Spec Reference:

Description

There is probably an issue of TA loop in osmo-bts-trx: if a delay between
MS and BTS is changed with a big step, e.g. from 0 to 2048 symbol periods,
then a new Timing Advance value would be changed too slow, i.e. step by
step after each measurement period => changing ToA from 0 to 2048 will take
2048 / 256 = 8 measurement periods to compensate the loop...

How to reproduce?

Use both FakeTRX and trxcon from OsmocomBB. There is an auxiliary
command 'FAKE_TOA', which is intended to simulate a delay between MS and BTS:

https://osmocom.org/projects/baseband/wiki/FakeTRX
https://git.osmocom.org/osmocom-bb/commit/?h=fixeria/trx&id=5ab622d2b72ac6df9d71d42736a6a65ac76cfab5


Related issues

Related to OsmoBTS - Feature #1851: generalize power control and TA loop codeResolvedpespin11/18/2016

Actions
Related to OsmocomBB - Bug #2988: unexpected bit errors when using trxcon and osmo-bts-trxResolvedfixeria02/23/2018

Actions
Actions #1

Updated by laforge about 6 years ago

  • Related to Feature #1851: generalize power control and TA loop code added
Actions #2

Updated by laforge about 6 years ago

  • Assignee set to 4368
Actions #3

Updated by fixeria about 6 years ago

  • Related to Bug #2988: unexpected bit errors when using trxcon and osmo-bts-trx added
Actions #4

Updated by laforge almost 6 years ago

We now have a wiki page about timing advance: Timing_Advance

Actions #5

Updated by laforge over 5 years ago

  • Assignee changed from 4368 to tnt
Actions #6

Updated by tnt about 5 years ago

Yes, it's slow. But OTOH it can cope with at least 1 TA value every 2 second, so that's a MS moving at ~ 1000 km/h. The way it's implemented now, it's basically heavily dampened which means it should also be very stable.

An alternative is to make the step proportional to the toa difference, basically reducing the time to adapt.

Instead of doing +1 we'd do + (toa * alpha) alpha being the damped factor. The closer alpha is, the faster it's going to react but also the more it can oscillate in case of measurement noise.

Thoughts ? Is this really an issue ?

Actions #7

Updated by fixeria about 5 years ago

  • Priority changed from Normal to Low

Yes, it's slow. But OTOH it can cope with at least 1 TA value every 2 second, so that's a MS moving at ~ 1000 km/h.

Hmm, you're right. GSM TS 05.10 says: "The control loop for the timing advance shall be implemented in such a way that it will cope with MSs moving at a speed up to 500 km/h", so the current implementation is compliant.

An alternative is to make the step proportional to the toa difference, basically reducing the time to adapt.
Thoughts ? Is this really an issue ?

Are there any other cases when the TA value rapidly changes and we need to react quickly?
If no, feel free to close this issue. Changing priority to low for now.

Actions #8

Updated by laforge about 5 years ago

Hi Sylvain,

On Mon, Jan 21, 2019 at 03:36:46PM +0000, tnt [REDMINE] wrote:

Yes, it's slow. But OTOH it can cope with at least 1 TA value every 2 second, so that's a MS moving at ~ 1000 km/h. The way it's implemented now, it's basically heavily dampened which means it should also be very stable.

Indeed, you're making a very valid point. I don't think we need to react too quickly to large changes,
because something fishy is going on in such cases.

Thoughts ? Is this really an issue ?

I wouldn't think so.

Actions #9

Updated by fixeria about 5 years ago

  • Status changed from New to Closed

Ok, closing. Thank you Sylvain!

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)