Osmocom Libraries » libosmocore

The roundtrip delay for a LAPD link must be less than T200.

Osmocom-bb runs LAPDm on the host machine via serial interface and USB interface that may cause a roundtrip delay that exceeds T200. Also osmo-bts may have that problem, due to latency between physical interface and osmo-bts software.

What may happen:

An I frame gets lost.

The sending side transmits the next I frame. The receiving side detects the send-sequence error and responds with a REJ frame.

Due to the round trip delay, the T200 expires on the sending side and causes the I frame to be retransmitted with the P bit set, it enters the timer recovery state. The receiving side detects the send-sequence error and responds with a REJ frame with the F bit set.

The sending side will then receive two REJ frames. The first REJ frame will clear the timer recovery state. The second REJ frame (with F bit set) is received when not in timer recovery state, causing an MDL-ERROR-INDICATION.

The layer 2 connection is broken.

Early tests with osmocom-bb in a real network showed exactly this problem.

The solution is to suppress every second REJ frame at the receiving side, until the sequence error condition is cleared. If the first REJ frame gets lost, the sending side would retransmit the I frame again after another expiry of T200. Then the receiving side would respond with a REJ frame again.

The solution for the TTCN3 test case is to resend the I frame twice and then expect the REJ response.

I agree with this analysis.

See also #4074. If we implemented that properly, we would also have solved this issue as real-time would no longer be used in time-outs.