Project

General

Profile

Bug #3572

Incorrect TDMA frame number calculation on TCH channels

Added by fixeria about 2 months ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
osmo-bts-trx
Target version:
Start date:
09/19/2018
Due date:
% Done:

0%

Spec Reference:
GSM 05.02, GSM 05.03

Description

Unlike the other supported back-ends, osmo-bts-trx is involved in low-level burst processing,
i.e. scheduling, collecting, and decoding. On the Downlink direction, osmo-bts-trx does receive
bursts from TRX (transceiver, e.g. OsmoTRX or FakeTRX), which then are being stored in buffers
of logical channels they belong to. As soon as a full set of bursts is collected, e.g. 4 bursts
for xCCH channels, a L2 frame decoding attempt is performed. If this attempt was successful,
a decoded L2 frame is forwarded upwards to the higher layers.

Every decoded L2 frame gets TDMA frame number, which corresponds to TDMA frame number
of the first burst in set (e.g. bid 0/3 for xCCH). In case of xCCH channels, where
one L2 frame is interleaved over 4 consecutive bursts, it's quite easy to assign
a frame number - it's enough to store it in lachn's state every time the first burst
is received. But TCH interleaving is a bit more complex, and the approach of storing
frame number is not applicable here.

According to GSM TS 05.03, both TCH/F and TCH/H channels are using block-diagonal
interleaving. It means that there is no simple relation between a burst and the
L2 frame it belongs to. Instead, every single burst may carry 57 bits of one L2
frame, and 57 bits of another one (some kind of overlapping).

In case of TCH/F, the result of encoding of either a traffic, or a FACCH/F frame
is 456 bits, which are then being interleaved over 8 consecutive bursts, using
even numbered bits of the first 4 bursts, and odd numbered bits of the last
4 bursts. Please check out this great picture:

So, during the collecting / decoding process in osmo-bts-trx, a new L2 frame
appears every 4 bursts. In other words, every set of 4 bursts do contain the
ending (228 odd bits) of a previous frame, and the beginning (228 even bits)
of a next frame.

For some reason, TDMA frame number of 5/8 (bid=0) burst is assigned to every
decoded L2 frame. This is incorrect and should be fixed.

The world of TCH/H is even more complex, and moreover there is no such great
picture like for TCH/F. The interleaving of traffic and FACCH/H is different:

  • the result of encoding of a traffic frame is 228 codec bits, which are then
    being interleaved over 4 consecutive bursts, using even numbered bits of the
    first two bursts, and odd numbered bits of the last two bursts;
  • the result of encoding of a FACCH/H frame is 456 codec bits, which are then
    being interleaved over 6 consecutive bursts, using even numbered bits of the
    first two bursts, all bits of the middle two bursts, and odd numbered bits of
    the last two bursts;

And like in case of TCH/F, L2 frames, decoded on TCH/H channel, also have
incorrect frame numbers assigned. But, there is an example how to do it properly:

https://git.osmocom.org/osmocom-bb/commit/?id=1bffe899d93ab220c74c93cfc8cc1a6b4b309c70

History

#1 Updated by fixeria about 2 months ago

  • Checklist item Share TCH/H TDMA frame mapping helpers in libosmocore added
  • Checklist item Implement TCH/F TDMA frame mapping helpers in libosmocore added
  • Checklist item Fix TDMA frame number calculation for TCH/F added
  • Checklist item Fix TDMA frame number calculation for TCH/H added
  • Checklist item Implement basic TTCN-3 test coverage added

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)