This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.
Holger Hans Peter Freyther holger at freyther.deOn Wed, Dec 18, 2013 at 03:52:28PM +0100, Andreas Eversberg wrote: > classes) would allow to allocate TS1..TS4, so the phone can still > transmit on TS3. the phone would schedule the following 8 bursts for > one frame: "-tttt-r--" (t=TX, r=RX) if i would provide an UL TBF > with TS1, the phone would be able to do the following scheduling > only: "-tt-r---", so the algorithm can only assign TS1 and TS2 for > RX. this means that the multislot algorithm must consider the RX > slots when choosing a good TX slot, even with no ongoing DL TBF. Could you add TS boundaries to your ascii art? I still didn't read/ understand the constraints with TrX. > * in case of first DL TBF assignment (phone is in packet idle mode), > i use multislot algorithm too, because i know the multislot class > from the LLC-DATA message. it is no problem to assign a single, but > why do you want to assign a single slot here? It is my understanding of the current code. In case we start with a DL TBF. We will need to create an immediate assignment and send it through the PCH. On the immediate assignment we can only announce one TS/PDCH. (We could follow-up with another control command to inform the phone about the other dl assignments it has). PS: My scheduling "fair-ness" patches create another issue. The code should make sure that a DL_ASSIGNMENT is scheduled _before_ the final uplink ack/nack. Even if it requires a bit more memory I think it would make sense if we have a small CTRL command queue inside the TBF.