Good Afternoon,
last week at the sysmocom office Daniel and me continued to work on the window handling. We have now a proper abstraction that allows us to unit test the DL and UL window handling. The encode/decode of the RBB is now compatible to itself.
While doing our manual tests (sending a big enough ICMP echo request) we noticed that in the alloc algorithm b case the we get a lot of NACKs. In the same setup (only alloc algorithm is changed) the A algorithm has no NACKs.
I am now going to re-write the allocation handling. In terms of operation on the first DL assignment (through the PCH) we can only use a singleslot but when re-using the TBF we might go for multislot. In case the of UL handling we could always try to use multislot assignments. Is this understanding correct?
holger
Holger Hans Peter Freyther wrote:
I am now going to re-write the allocation handling. In terms of operation on the first DL assignment (through the PCH) we can only use a singleslot but when re-using the TBF we might go for multislot. In case the of UL handling we could always try to use multislot assignments. Is this understanding correct?
hi holger,
when i designed multislot allocation algorithm, i considerd the following:
* for one-phase-access (UL), we don't know the multislot class, so i assume class 12, because it allows the maximum RX slots for semi-duplex operation. for two-phase-access we know the multislot class from the PACKET RESOURCE REQUEST. if the BTS provides 4 or more PDCH slots starting with TS1, the algorithm would select TS3 (iirc), because a later (concurrent) DL TBF with class 12 (or other 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.
* similar to an allocated UL slot, the algorithm must choose the same slot for "control_ts", that is used for polling. even for DL TBF only, the control_ts slot must be allocated as if it would be an UL TS, because the phone must be able to answer, if it is polled. the control_ts and and an assigned UL slot may be the same TS.
* 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?
best regards,
andreas
On 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.
On Wed, Dec 25, 2013 at 06:18:09PM +0100, Holger Hans Peter Freyther wrote:
On 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.
Okay. you are already interleaving Dl/UL and the 3 timeslot offset between DL/UL. It wasn't clear from your graph.
osmocom-net-gprs@lists.osmocom.org
-
Andreas Eversberg -
Holger Hans Peter Freyther -
Holger Hans Peter Freyther