Change in osmo-bts[master]: TA loop: Take into account UL SACCH 'Actual Timing advance' field

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

pespin gerrit-no-reply at lists.osmocom.org
Thu Sep 9 17:31:54 UTC 2021


Hello Jenkins Builder, laforge, fixeria, dexter, 

I'd like you to reexamine a change. Please visit

    https://gerrit.osmocom.org/c/osmo-bts/+/25386

to look at the new patch set (#2).

Change subject: TA loop: Take into account UL SACCH 'Actual Timing advance' field
......................................................................

TA loop: Take into account UL SACCH 'Actual Timing advance' field

First step improving and reworking TA loop:
Move trigger of the loop to similar place done by BS/MS Power Control
Loop, that is, upon receivial of UL SACCH block, which contains
information about the TA used to transmit the block encode in L1SACCH
Header. Hence, from computed received TOA and TA used when transmitting
from the MS, we can infer the desired TA to be used by the MS, which
will send back to it later during DL SACCH block.

The values taken are actually the ones calculated for the previous SACCH
block and stored in lchan->meas.ms_toa256. That's because L1SACCH
contains the TA used for the previous reporting period, similarly to
what's specified for MS Power Control loop (TS 45.008 sec 4.2):
"""
The MS shall confirm the power control level that it is currently employing
in the SACCH L1 header on each uplink  channel. The indicated value shall
be the power control level actually used by the mobile for the last burst
of the  previous SACCH period.
"""
(The reader may observe that currently this is not properly done for MS
Power Control loop when calling lchan_ms_pwr_ctrl(): this is a bug.)

This new method also permits changing TA quicker, since we have more
confidence that the TA we request is aligned with the one used to
transmit, and we don't simply increment/decrement based on the value we
request to transmit.

Related: SYS#5371
Change-Id: I2d0f128c8dcac93ee382283a1c91fca76623b8fc
---
M include/osmo-bts/ta_control.h
M src/common/l1sap.c
M src/common/measurement.c
M src/common/ta_control.c
M tests/ta_control/ta_control_test.c
5 files changed, 74 insertions(+), 28 deletions(-)


  git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/86/25386/2
-- 
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/25386
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I2d0f128c8dcac93ee382283a1c91fca76623b8fc
Gerrit-Change-Number: 25386
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier at sysmocom.de>
Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-MessageType: newpatchset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210909/90d28ff5/attachment.htm>


More information about the gerrit-log mailing list