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 -- - Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * 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