Project

General

Profile

Bug #3055

osmo-bts-trx: slow TA loop feedback

Added by fixeria 12 months ago. Updated about 1 month 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 codeNew2016-11-18

Related to OsmocomBB - Bug #2988: unexpected bit errors when using trxcon and osmo-bts-trxResolved2018-02-23

History

#1 Updated by laforge 12 months ago

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

#2 Updated by laforge 11 months ago

  • Assignee set to sysmocom

#3 Updated by fixeria 11 months ago

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

#4 Updated by laforge 9 months ago

We now have a wiki page about timing advance: Timing_Advance

#5 Updated by laforge 4 months ago

  • Assignee changed from sysmocom to tnt

#6 Updated by tnt about 1 month 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 about 1 month 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 about 1 month 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 about 1 month 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)