18 Dec
2013
18 Dec
'13
1:48 p.m.
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 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
18 Dec
18 Dec
3:52 p.m.
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
25 Dec
25 Dec
6:18 p.m.
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.
9:16 p.m.
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:
Okay. you are already interleaving Dl/UL and the 3 timeslot offset
between DL/UL. It wasn't clear from your graph.
--
- 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
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.
3787
days inactive
3794
days old
osmocom-net-gprs@lists.osmocom.org
3 comments
3 participants
participants (3)
-
Andreas Eversberg -
Holger Hans Peter Freyther -
Holger Hans Peter Freyther