Project

General

Profile

Actions

Bug #3572

closed

Incorrect TDMA frame number calculation on TCH channels

Added by fixeria over 5 years ago. Updated almost 4 years ago.

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

80%

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


Checklist

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

Related issues

Related to OsmoBTS - Bug #3803: fix frame number calculation in scheduler_trxResolveddexter02/15/2019

Actions
Actions #1

Updated by fixeria over 5 years 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
Actions #2

Updated by fixeria almost 5 years ago

  • Related to Bug #3803: fix frame number calculation in scheduler_trx added
Actions #3

Updated by laforge almost 5 years ago

Actions #4

Updated by laforge almost 5 years ago

  • Assignee set to 4368
Actions #5

Updated by laforge almost 4 years ago

  • Status changed from New to Feedback
  • Assignee changed from 4368 to fixeria

fixeria what is the status of this ticket? Is it still a pending issue?

Actions #6

Updated by Hoernchen almost 4 years ago

I've stumbled upon this last week, and suspected that it was already fixed by dexter fn calculation fixes.

Actions #7

Updated by tnt almost 4 years ago

Also ... I don't get the issue really.

Yeah, we assume a L2 frame number that's "arbitrarily" the 5th burst of 8 bursts where data of the L2 frame is spread over. What's the problem exactly ?
They will come at the right "rate" and be spread by the right amount of frame, so why does it matter if we take the first, 5th or last ? What's that number even used for ?

Actions #8

Updated by fixeria almost 4 years ago

  • Checklist item Share TCH/H TDMA frame mapping helpers in libosmocore set to Done
  • Checklist item Implement TCH/F TDMA frame mapping helpers in libosmocore set to Done
  • Checklist item Fix TDMA frame number calculation for TCH/F set to Done
  • Checklist item Fix TDMA frame number calculation for TCH/H set to Done
  • % Done changed from 0 to 80

tnt wrote:

Also ... I don't get the issue really.

Yeah, we assume a L2 frame number that's "arbitrarily" the 5th burst of 8 bursts where data of the L2 frame is spread over. What's the problem exactly ?
They will come at the right "rate" and be spread by the right amount of frame, so why does it matter if we take the first, 5th or last ? What's that number even used for ?

The problem is that some lchan handlers report frame number of the first burst, some report frame number of the last burst... This inconsistency is what I really dislike, but to be honest, I don't know whether it's really that critical. Probably yes for the measurement processing, or maybe for DTX mode of operation (which we don't yet support to my best knowledge).

laforge wrote:

fixeria what is the status of this ticket? Is it still a pending issue?

I quickly checked the source code of the recent master, and it looks good to me. Just submitted a cosmetic change:

https://gerrit.osmocom.org/c/osmo-bts/+/18218 osmo-bts-trx/scheduler: remove a left-over from UL TCH handlers

The libosmocore's frame (re)mapping API has some unit tests, but I have not seen anything covering osmo-bts-trx itself. Let me know if I should implement a TTCN-3 test case.

Actions #9

Updated by laforge almost 4 years ago

On Tue, May 12, 2020 at 01:17:03PM +0000, fixeria [REDMINE] wrote:

The problem is that some lchan handlers report frame number of the first burst, some report frame number of the last burst... This inconsistency is what I really dislike, but to be honest, I don't know whether it's really that critical. Probably yes for the measurement processing, or maybe for DTX mode of operation (which we don't yet support to my best knowledge).

We should have one unified understanding of which frame nubmer we use
for reporting the burst, as this is indeed important for parts of the
common code such as measurement processing and uplink DTX - both or
which are important and supported; DTX historically not for
osmo-bts-trx, but I think actually also by now, dexter has done a lot
of work on this in terms of correctly marking the related frames etc.

The libosmocore's frame (re)mapping API has some unit tests, but I have not seen anything covering osmo-bts-trx itself. Let me know if I should implement a TTCN-3 test case.

I think it's fine as-is, thanks.

Actions #10

Updated by fixeria almost 4 years ago

  • Status changed from Feedback to Closed

I think it's fine as-is, thanks.

Then I am closing this ticket, since there is nothing left to do.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)