Project

General

Profile

Bug #3055

osmo-bts-trx: slow TA loop feedback

Added by fixeria over 1 year ago. Updated 5 months 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 codeNew11/18/2016

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

History

#1 Updated by laforge over 1 year ago

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

#2 Updated by laforge over 1 year ago

  • Assignee set to sysmocom

#3 Updated by fixeria about 1 year ago

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

#4 Updated by laforge about 1 year ago

We now have a wiki page about timing advance: Timing_Advance

#5 Updated by laforge 8 months ago

  • Assignee changed from sysmocom to tnt

#6 Updated by tnt 5 months 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 ?

#7 Updated by fixeria 5 months 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.

#8 Updated by laforge 5 months 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.

#9 Updated by fixeria 5 months ago

  • Status changed from New to Closed

Ok, closing. Thank you Sylvain!

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)