Multislot allocation failures and defects
Holger Hans Peter Freyther
hfreyther at sysmocom.de
Thu Dec 26 10:03:13 UTC 2013
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.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
More information about the osmocom-net-gprs