Hi,
after the report about the missing usf assignment I started to refactor the allocation algorithms (remove code duplication, apply information hiding, directly access things).
Looking at the code it appears that algorithm A and B will always select the first (in case of A) or the first and following (in case of B) enabled PDCH.
I have the suspicion that in case of algorithm A only the first PDCH will be used to assign to phones? And in case of algorithm B it is likely that the assignments are not spread equally across the available timeslots?
can someone confirm/deny?
holger
Holger Hans Peter Freyther wrote:
I have the suspicion that in case of algorithm A only the first PDCH will be used to assign to phones? And in case of algorithm B it is likely that the assignments are not spread equally across the available timeslots?
dear holger,
it is true tat algorithm A only assigns the first PDCH time slot. i don't see any problems changing that by spreading TBF usage over all available PDCHs.
in case of algorithm B it is a bit different. we want to assign a certain PDCH time slot for uplink, so we can be sure that the phone is able to receive all supported downlink PDCH slots, if an additional downlink TBF is assigned. for a class 12 mobile (as used today), we can assign up to 4 PDCHs for downlink. in this case we must assign the third PDCH for uplink, otherwise semi-duplex operation is not possible with all 4 time slots. but again, it would be possible to spread uplink and downlink assignment, if we have more than 4 PDCHs. this makes the algorithm more complex.
regards,
andreas
On Sun, Sep 29, 2013 at 10:15:50AM +0200, Andreas Eversberg wrote:
it is true tat algorithm A only assigns the first PDCH time slot. i don't see any problems changing that by spreading TBF usage over all available PDCHs.
okay. I am currently cleaning up the pcu (including the allocations algorithms), refactor and fix the subtle bugs that are due code duplication (e.g. like the one reported by Vladimir Rolbin). This also means that I will be busy and stall your osmo-bts changes until I am done with the clean-up here.
in case of algorithm B it is a bit different. we want to assign a certain PDCH time slot for uplink, so we can be sure that the phone is able to receive all supported downlink PDCH slots, if an additional downlink TBF is assigned. for a class 12 mobile (as used today), we can assign up to 4 PDCHs for downlink. in this case we must assign the third PDCH for uplink, otherwise semi-duplex operation is not possible with all 4 time slots. but again, it would be possible to spread uplink and downlink assignment, if we have more than 4 PDCHs. this makes the algorithm more complex.
Thanks for the explanation. I think we easily end in a situation where we can not allocate bigger windows (or windows at all) because we always start with the first enabled PDCH.
holger
On Sun, Sep 29, 2013 at 11:05:05AM +0200, Holger Hans Peter Freyther wrote:
On Sun, Sep 29, 2013 at 10:15:50AM +0200, Andreas Eversberg wrote:
it is true tat algorithm A only assigns the first PDCH time slot. i don't see any problems changing that by spreading TBF usage over all available PDCHs.
okay. I am currently cleaning up the pcu (including the allocations algorithms), refactor and fix the subtle bugs that are due code duplication (e.g. like the one reported by Vladimir Rolbin). This also means that I will be busy and stall your osmo-bts changes until I am done with the clean-up here.
Okay, I started to read GSM 04.60 and the code. So right now we have "global TFIs" so in each direction we can not allocate 32 TFIs right now.
The spec says this: "Each TBF is assigned a Temporary Flow Identity (TFI) by the network. The mobile station shall assume that the TFI value is unique among concurrent TBFs in the same direction (uplink or downlink) on all PDCHs used for the TBF. The same TFI value may be used concurrently for TBFs on other PDCHs in the same direction and for TBFs in the opposite direction."
So if we combine the tfi/tbf allocation we could remove the current limitation. I have some more ideas for cleanup after reading some more of the code. I would propose to stick with C++ at this point in time as information hiding (e.g. making certain parts of a struct private can help with the structure of the code.)
holger
On Sun, Sep 29, 2013 at 11:05:05AM +0200, Holger Hans Peter Freyther wrote:
okay. I am currently cleaning up the pcu (including the allocations algorithms), refactor and fix the subtle bugs that are due code duplication (e.g. like the one reported by Vladimir Rolbin). This also means that I will be busy and stall your osmo-bts changes until I am done with the clean-up here.
after more re-factoring and writing client code to utilize the allocation. The limiting factor in the DL is the USF assignment. So for alloc_a we are limited to 8 devices at a time (even with multiple PDCHs).
holger
Holger Hans Peter Freyther wrote:
after more re-factoring and writing client code to utilize the allocation. The limiting factor in the DL is the USF assignment. So for alloc_a we are limited to 8 devices at a time (even with multiple PDCHs).
actually we are limited to 7 devices, because USF 7 is reserved. we need this for single block allocation or polling a response from a device. we do not want to have collisions with an ongoing uplink TBF.
a way to provide more downlink/uplink TBFs, is to assign only a subset of PDCHs to each device, if the number of devices is high. it is possible to remove assigned PDCHs from devices when splitting of PDCHs (into a subset) is wanted. but this would make an algorithm more complex. at least for algorithm A (single slot) it would be simpler.
osmocom-net-gprs@lists.osmocom.org
-
Andreas Eversberg -
Holger Hans Peter Freyther