Osmocom Libraries » libosmocore

One idea that came up recently was to not use system timers (tied to "real time") in osmo-bts, but to use frame numbers as a time base. So if a LAPDm frame is encoded into bursts of a given frame number, we can then express the "n" milliseconds as frame count and check the uplink frame numbers. Once they exceed the timeout, the timer expires. This way it doesn't really matter how much fn-advance or the like we use: The time-out would always automatically scale with that.

Still, what we would need is to start timers when L1 pulls a L2 frame, which is quite different from the current architecture.

3GPP TS 48.006 Section 8.9 contains some nice tables and explanations on what kind of requirements a "good" T200 setting must fulfill. If it is too short (for our overall processing + propagation delay), we will get plenty of useless retransmissions that reduce our throughput. And if it is too long, we equally loose thorughput as lost frames are detected too late.

I'm wondering how we can make progress here. Ideally, I would want to make the T200 timers scale automatically as configuration parameters like fn-advance change.

1. Tx Delay: pulling a frame from LAPDm, encoding, interleaving it and sending (the last sample of) its last burst over the Um interface, ideally in terms of when it hits the antenna, but I guess when sending the samples to the SDR driver is good enough
2. Rx Delay: time between receiving the (first? last? sample of) I/Q samples of the first burst of a frame and sending it into LAPDm.

The question is, how to determine those values, ideally at runtime, or at the very least once during start-up, so we can use it to configure the various timers.

The precision doesn't have to be very high, but more in the milli-second domain, as that's the basis for T200. If it simplifies things, we can also normalize it to units of frame durations (4.6ms).

Note: I don't think we really need the separate Rx/Tx delay, but the sum would be sufficient.

Can we learn that sum of rx+tx delay (at least quantized to FN granularity) by comparing the FN received in uplink bursts with the FN we use for generating downlink data (i.e. CLOCK IND plus fn-advance)?

Hi Harald,

One idea that came up recently was to not use system timers (tied to "real time") in osmo-bts, but to use frame numbers as a time base.

nice idea!

Can we learn that sum of rx+tx delay (at least quantized to FN granularity) by comparing the FN received in uplink bursts with the FN we use for generating downlink data (i.e. CLOCK IND plus fn-advance)?

Yep, for sure we can. I think this is the easiest way.

The spec reference seems wrong. The T200 is discussed in 04.06, for example: "The task set T200 shall be performed at the instant right before transmitting a frame, when the PH-READY-TO-SEND primitive is received from the physical layer."

The timer itself is defined in 3GPP TS 04.06 Sec. 5.8.1

Patches are made for frame based LAPDm polling and T200 timer. The patches apply to libosmogsm, as well as libosmoisdn. Another patch applies to osmo-bts, that uses the frame based polling. They are pushed to Gerrit.

Patches are merged. Still the osmo-bts patch needs to be merged, to use the new LAPDm code.