Bug #6118
openosmo-pcu assigns multi-slot TBFs over PACCH to MS with unknwon ms_class
0%
Description
When the DL/UL TBF assignment happens over CCCH (PCH, AGCH) we don't have this problem, since assignment over CCH can only assign a single TS.
However, once that TBF is assigned and MS jumps to packet-active mode (PDCH), new TBF assignment can happen over PACCH.
It can be that at that point in time, the PCU doesn't know the MultiSlot Class of the MS, because the MS used 1phase access (aka no PktResourceReq containing RadioAccessCap) and the SGSN didn't provide the PCU with it during BSSGP-DL-UNITDATA (because it neither knows it).
As a result, when allocating a DL TBF at that time, the current alloc_algo, if the ms_class is not known (=0), it assumes ms_class=12:
#define DEFAULT_MSLOT_CLASS 12
As a result, it ends up assigning up to 4 TS to an MS which may not support it (eg. because it's ms_class=1 but didn't inform the PCU about it, like "modem" osmocom-bb app currently).
Current behavior basically breaks proper operation of MS with ms_class<12 (fortunately most MS nowadays are ms_class=12 or higher).
Updated by pespin 9 months ago
- Assignee set to pespin
This ttcn3 tests shows the bug:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34004 pcu: Introduce test TC_dl_multislot_tbf_ms_class_unknown
Currently test fails with "Expected 1 PDCH slots allocated but got 4" (4 from MS CLASS 12)
Similarly, TC_dl_multislot_tbf_ms_class_from_sgsn also fails due to the same problem: The MS was reserved 4 slots assuming MS_Class=12 during packet-access-procedure, and later when it receives the ra_cap it doesn't re-reserve resources on the MS, so it ends up using only 4 of the 8 possible TS: "Expected 8 PDCH slots allocated but got 4".
Updated by pespin 7 months ago
The situation "improved" a bit because there's at least now a VTY command to change the default MS Class, which means users willing to support all devices (at the expense of potentially allocating less resources and hence lose performance) can set it.
See for more info:
https://gerrit.osmocom.org/c/osmo-pcu/+/33983
This of course doesn't fix the limitations of the current allocation code.
