Project

General

Profile

Bug #3803

fix frame number calculation in scheduler_trx

Added by dexter 2 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
02/15/2019
Due date:
% Done:

0%

Spec Reference:

Description

In rx_tchh_fn() and rx_tchh_fn() there is a formula used to calculate the frame number of the block that is passed up to the higher layers. The two functions collect a set of bursts and when complete, it is passed up. At the moment there are two indications generated when a block is completed. A measurement indication and a tch indication. Both should use the same fn. But the current implementation uses the stored *first_fn for the measurement indication and a formular that gets the fn of the last received block for the tch indication. Both seems to be incorrect because we need to take into account that TCH blocks are interleaved over 8 bursts. We need to tag each block with its starting frame number. To get this correct we need to check the formulas and make sure that the measurement indication and the tch indication use the same fn.


Related issues

Related to OsmoBTS - Feature #2977: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with dataStalled2018-02-21

Related to OsmoBTS - Bug #3572: Incorrect TDMA frame number calculation on TCH channelsNew2018-09-19

History

#1 Updated by dexter 2 months ago

  • Related to Feature #2977: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with data added

#2 Updated by dexter 2 months ago

The first attempt to fix this was to use *first_fn for the tch indications because it sounded logical that the first_fn is indeed the first frame number but it turned out that the burst we see is not really the first burst where the block started. Due to the interleaving the block started earlier than first_fn indicates.

See also: https://gerrit.osmocom.org/#/c/12779/1/src/osmo-bts-trx/scheduler_trx.c (This patch also marks the locations in the code that are problematic)

#3 Updated by dexter 2 months ago

See also #2987 for information about the burst interleaving.

#4 Updated by dexter 2 months ago

Regarding the burst interleaving lets focus on TCH/F first. Each voice block is distributed over 8 half bursts like so:

       A       A 
TTTTTTTTTTTTTTTT
    tttttttttttttttt
   V       V       V

A and V are just markers for blocks which are ready and passed on. T shall be the left half and t shall be the right half. This means that every 4th burst one block gets finished, so we have the illusion that one block is distributed over 4 consecutive bursts, which we see in scheduler_trx.c. So as soon as we see the first burst of the block, we are in reality already at the 2nd of 8 bursts. So the formula basically calculates fn-7, so that looks correct and we could also use *first_fn-1 to get the same result.

I am now asking myself how the SACCH fits int this scheme. The 51 multiframe layout is basically 3 complete blocks, then a SACCH burst, and then again 3 complete blocks. Does the SACCH then use both half bursts at once or is it somehow blurring into to the voice blocks? To me it does not look like this.

T = Single traffic channel burst
S = SACCH
I = Idle
M = Measurement report
                                                                                                    1
          1         2         3         4         5         6         7         8         9         0
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
            v            v            v            v            v            v            v            v

MEASUREMENT REPORTING TCH/F TS0
interval start                                                                              interval end
|------------------------------------------------------------------------------------------------------|
TTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTITTTTTTTTTTTTSTTTTTTTTTTTTI
M   M   M   MM   M   M    M   M   M    M   M   M    M   M   M    M   M   M    M   M   M    M   M   M    

I think we also should trace back where the fn and bit of rx_tchf_fn() comes from and how it is generated. This will presumably come more or less directly from osmo-trx.

#5 Updated by fixeria 2 months ago

In trxcon, I introduced a few functions for TCH/H and FACCH/H frame number calculations.
Please see: https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_lchan_tchh.c#n147

In short, we define the block mappings, coming from GSM 05.02, clause 7, table 1,
i.e. *_block_map[X][Y], where each X is a block, and Y is:

  • fn % 13 for TCH/H
  • fn % 26 for FACCH/H

for example:

/* TCH/H speech block mapping for sub-slot 0 */
static const uint8_t tch_h0_traffic_block_map[3][4] = {
    /* B0(0,2,4,6), B1(4,6,8,10), B2(8,10,0,2) */
    { 0, 2, 4, 6 },
    { 4, 6, 8, 10 },
    { 8, 10, 0, 2 },
};

/* TCH/H speech block mapping for sub-slot 1 */
static const uint8_t tch_h1_traffic_block_map[3][4] = {
    /* B0(1,3,5,7), B1(5,7,9,11), B2(9,11,1,3) */
    { 1, 3, 5, 7 },
    { 5, 7, 9, 11 },
    { 9, 11, 1, 3 },
};

As you can see, the frame numbers of consequent blocks are overlapping.
This is due to the block diagonal interleaving - every TCH/H speech
block (4 bursts) has 50% bits of one L2 frame, 25% bits of the
previous one, and 25% of the next L2 frame.

The algorithm of finding the first TDMA frame number of a block using
the last one is simple:

1) Choose the corresponding block mapping definition. For TCH/H, there
are two block maps - sub-slot 0 and sub-slot 1. For FACCH/H, we
additionally need to distinguish between Uplink and Downlink,
having four maps in total.

2) Iterate over the chosen block mapping, and compare the last TDMA frame
number of each block with a given fn % 26.

3) If the matching block is found, you can compare the difference
between the first TDMA frame number of a block and the last one.

4) Finally, you can subtract this difference from a given last TDMA
frame number to get the first one.

Most likely, the proposed approach still needs some improvements.
While writing this description, I discovered that in case of TCH/H,
the difference between first and last TDMA frame numbers is almost
constant - 6, excluding both { 8, 10, 0, 2 } and { 9, 11, 1, 3 },
where it's 7. In case of FACCH/H, it's either 10, or 11.

For TCH/F it should be even simpler, as both TCH/F and FACCH/F
block types are interleaved over 8 consecutive bursts, unlike
4 and 6 in case of TCH/H and FACCH/H.

I would really love to see the final implementation as a part of
libosmogsm (new gsm_05_02.c?), so it could be also used by trxcon.

#6 Updated by fixeria 2 months ago

I am now asking myself how the SACCH fits int this scheme. The 51 multiframe layout is basically 3 complete blocks,
then a SACCH burst, and then again 3 complete blocks. Does the SACCH then use both half bursts at once or is it
somehow blurring into to the voice blocks? To me it does not look like this.

SACCH has dedicated slots in both TCH/F and TCH/H multi-frames, and doesn't use block-diagonal interleaving.
It works in the same way as any other xCCH - 4 consecutive bursts, so the *first_fn can be safely used.

If you actually meant FACCH, then the situation is different. FACCH has no dedicated blocks on the multi-frame
layout. Instead, one FACCH/F frame replaces one TCH/F (speech or CSD data) frame, and this is indicated by
stealing bits of burst. FACCH/F is interleaved over 8 consecutive bursts, just like a regular TCH/F frame.

Unlike FACCH/F, a FACCH/H frame is interleaved over 6 consecutive bursts, and replaces two regular TCH/H
frames. This is also indicated by stealing bits. This is why we have both dl_ongoing_facch and ul_ongoing_facch
variables - as soon as we have decoded a FACCH/H frame, we need to skip the next decoding attempt, because
we still shift the buffer by two bursts.

#7 Updated by fixeria 2 months ago

... and feel free to look at the multi-frame layouts, it simplifies a lot: https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_mframe.c#n515

#8 Updated by fixeria 21 days ago

  • Related to Bug #3572: Incorrect TDMA frame number calculation on TCH channels added

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)