Feature #3906

Automatically adjust LAPDm timer values with 'fn-advance' parameter

Added by fixeria over 2 years ago. Updated over 2 years ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


Currently we use fn-advance=20 by default, so the burst scheduler is working 20 TDMA frames in advance. This advance gives the transceiver some time to receive a burst, process it (i.e. modulate), and send to the Tx buffer of SDR. As a side effect, this increases the delay between UL and DL: 20 TDMA frames => 92.3ms of delay.

Higher fn-advance values cause a longer delay, resulting in LAPDm frame retransmissions.
OsmoBTS should automatically adjust LAPDm timer values with the configured 'fn-advance' value.

Related issues

Related to OsmoBTS - Bug #3506: FACCH LAPDm sequence error (state LAPD_STATE_MF_EST)New08/28/2018

Related to OsmoBTS - Bug #2294: T200 values set by OML (TS 12.21) are ignoredResolved05/27/2017

Related to OsmoBTS - Bug #4037: LAPDm N200 values are incorrectResolved06/02/2019

Associated revisions

Revision 20de6207 (diff)
Added by laforge over 2 years ago

lapdm: Allow user to specify T200 values; Use correct N200 values

TS 04.06 specifies a N200 re-transmission counter that depends on the
channel type, which we didn't care about at all so far. Let's have the
caller tell us the channel type so we can internally look up the correct
N200 value for it.

At the same time, permit the user to specify T200 re-transmission timer
values for each SAPI on both DCCH and ACCH, which is required at least
in the BTS as per GSM TS 12.21. Also, extend the timer resolution of
the API from seconds to milli-seconds, which is more applicable as
particularly on the FACCH the recommended values are in the 200ms range.

Change-Id: I90fdc4dd4720d4e02213197c894eb0a55a39158c
Related: OS#3906
Related: OS#2294
Related: OS#4037

Revision b24ef235 (diff)
Added by laforge over 2 years ago

l1sap: Compute statistics on FN advance in PH-RTS.ind

Let's keep some statistics about the min/max/average frame number
advance that we're observing above L1SAP when comparing the time in the
PH-RTS.ind and the frame number we observe in PH-DATA.ind of data
that was received on the uplink.

The statistics are currently only shown in the VTY, but this is a
precursor to using them to correctly advance the LAPDm timers in a
follow-up patch.

Change-Id: I8f739fdb808a614f080afbc4654641ec3df19eb2
Related: OS#2294
Related: OS#3906

Revision 8ea9ba6a (diff)
Added by laforge over 2 years ago

[correctly] use the LAPDm T200 values received via OML

As per GSM TS 12.21, the LAPDm timers (T200) of the LAPDm instances
in the BTS are configured via OML from the BSC. While OsmoBSC
is sending them and OsmoBTS is parsing them, OsmoBTS stopped to
make use of them from commit 3ca59512d2f4eb1f87699e8fada67f33674918b4
(January 2016) onwards.

The cause for this has been documented and discovered in May 2017
in and it is quite obvious: LAPDm
timers are supposed to start when a given frame is actually transmitted
on the radio interface. PH-RTS.ind and PH-DATA.req are suppsed to be
used over a synchronous interface in some deeply embedded processor.

With OsmoBTS however, we have an asynchronous L1/L2 interface between
a DSP (osmo-bts-{sysmo,lc15,oc2g,octphy}) or OsmoTRX (osmo-bts-trx)
and we receive PH-RTS.ind quite some time ahead. So if we start T200
at that point, then it will start running way before it has been sent
or before the MS has had a chance to receive the message.

The "correct" way to handle this is to actually measure the difference
between frame numbers in PH-RTS.ind (uplink, advanced) and PH-DATA.ind
(downlink) or PH-TIME.ind, and then add that amount to the actual
timeout value. This ensures that the timers will time-out the
user-specified amount of time after the actual transmit.

Change-Id: If8babda9e3e5e219908911ddd9c0756b5ea0bca4
Closes: OS#2294
Closes: OS#3906


#1 Updated by fixeria over 2 years ago

  • Related to Bug #3506: FACCH LAPDm sequence error (state LAPD_STATE_MF_EST) added

#2 Updated by laforge over 2 years ago

  • Related to Bug #2294: T200 values set by OML (TS 12.21) are ignored added

#3 Updated by laforge over 2 years ago

  • Assignee set to laforge
  • Priority changed from Normal to High

#4 Updated by laforge over 2 years ago

  • Related to Bug #4037: LAPDm N200 values are incorrect added

#5 Updated by laforge over 2 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 80

See for a proposed implementation.

#6 Updated by laforge over 2 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

patch merged__

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)