Multislot allocation failures and defects

Holger Hans Peter Freyther hfreyther at
Thu Dec 26 10:03:13 UTC 2013

Dear Andreas,

I went through the multislot allocation algorithm and cleaned and
structured the code in testable parts that take over parts of the
allocation and I have added a unit test for some of the allocation
cases (UL first, then DL.. e.g. due a RACH burst and then DL single,
UL and DL update).

Today morning I added a testcase that tests all PDCH combinations
and all MS Classes and verifies that an allocation takes place and
that the DL and UL first_common_ts do match. For (xxOxOOxO) and
MS_Class=5 this assert is wrong. The alloc/AllocTest of the
sysmocom/allocation-cleanups branch should show you this condition.

While reading the code I noticed the following things. Could you
please explain why these are problems or no problems.

* select_first_ts (it exists after the refactoring). It initializes
  i and compares it but it will never increment it. This means that
  the code can look at PDCHs _outside_ of the tx_range.

* first_common_ts handling. When assigning the DL tbf we pick a
  first_common_ts but when the actual UL assignment happens there
  might not be a free USF on the Uplink and at that point the phone
  might not listen on the TS we think.

* Sum for Rx+Tx is not used. I see that in update_rx_win_max you
  modify the window to make some room.

* select_ul_slots. "i" is not incremented in all cases which could
  potentially lead to using slots outside of the tx_range. For the
  MS Type == 1 handling you could introduce a different variable that
  counts how many slots were used?

it would be nice if we could fix that during the 30C3.


- Holger Freyther <hfreyther at>
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

More information about the osmocom-net-gprs mailing list