Bug #3572
closedIncorrect TDMA frame number calculation on TCH channels
80%
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
Updated by fixeria almost 6 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
Updated by fixeria over 5 years ago
- Related to Bug #3803: fix frame number calculation in scheduler_trx added
Updated by laforge over 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?
Updated by Hoernchen over 4 years ago
I've stumbled upon this last week, and suspected that it was already fixed by dexter fn calculation fixes.
Updated by tnt over 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 ?
Updated by fixeria over 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.
Updated by laforge over 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.
Updated by fixeria over 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.