Project

General

Profile

Bug #5149

osmo-pcu fails to allocate all DL-TBF possible slots under specific scenario

Added by pespin about 1 month ago.

Status:
New
Priority:
Low
Assignee:
-
Target version:
-
Start date:
05/10/2021
Due date:
% Done:

0%

Spec Reference:

Description

The issue is shown by TTCN3 PCU_Tests.TC_dl_multislot_tbf_ms_class_from_sgsn, where 4 slots are allocated to the DL TBF despite the PCU knowing at that time that the MS_CLASS supports concurrent 8-TX/8-RX.

The scenario is quite corner case, hence I'm marking the ticket as "Lower" priority. It can only happen if pcu is configured to not force two-phase access, then MS starts a UL TBF 1-phase access (hence without ms_class info) and without having interacted recently with the network (MS not in the MS cache in PCU).
In this case, when the UL TBF is allocated and slots for both UL and DL are reserved, since ms_class is unknown (0), DEFAULT_MSLOT_CLASS (12) is picked to reserve the slots. Hence, if afterwards we send some data SGSN->MS (containing MS Radio Access Capability), the DL TBF is created but the DL slots were already reserved before (using the default class 12), hence not all possible slots are used.

The main problem is that osmo-pcu allocator reserves both UL and DL for an MS whenever 1 TBF is created, and that's expected to have whenever the 1st TBF is created (see alloc_algorithm_b() when it calls find_multi_slots()).

In order to fix this case, we'd need to do, upon ms_set_ms_class()/ms_set_egprs_ms_class():

    if (ms->ms_class == 0 && ms_class_ > 0) {
        if (ms->dl_tbf && !ms->ul_tbf) {
            /* update reserved mask for reserved_ul_slots */
        } else {
            /* update reserved mask for reserved_dl_slots */
        }
    }

In order to implement the "/* update reserved mask for reserved_dl_slots */" part, one could split find_multi_slots() into pieces and try to reuse some of that, or simply copy-paste the function and change it to select the best slot set for a direction while keeping the direction already having a TBF in the current fixed size.

I'm still not sure though if we can really have this sort of scenario in real life, that's also another point why I mark the ticket as low.
If we ever find such a case in real life capture or we figure out an exact test which really makes sense, we can go on implementing what I mentioned above.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)