blob: 028865ec280228f57b1232072e9d545365e260aa [file] [log] [blame]
Holger Hans Peter Freytherba5543f2013-10-17 20:16:23 +02001* Change functions with 100 parameters to get a struct as param
2* Move move into the TBF class
Holger Hans Peter Freyther3dc56a32013-10-26 21:38:30 +02003* tbf/llc window code appears to be duplicated and nested in other
4 methods. This needs to be cleaned.
Holger Hans Peter Freyther6f791d02013-12-25 18:55:58 +01005
6
7* Possible race condition:
8 When scheduling a Downlink Assignment on the UL-TBF we need to make
9 sure that the assignment is sent _before_ the final ack. With my fairness
10 changes it gets more likely that this event is trigerred.
Holger Hans Peter Freythera09e33c2014-01-16 10:11:57 +010011
12* Optimize:
13After receiving an ACK/NACK.. schedule another one if the window
14is kind of stalled anyway. This way we avoid resending frames that
15might have already arrived. It could increase the throughput..
16
17Do not re-transmit after we got ack/nacked and where in the resending
18mode... and increase the window.
19
20<0004> tbf.cpp:907 - Sending new block at BSN 111
21...
22tbf.cpp:858 - Restarting at BSN 48, because all window is stalled.
23...
24tbf.cpp:1383 - V(B): (V(A)=59)"NNAAAAAAANAAAAANNAAAAAAAAAAAAAAAAAAAXXXXXXXXXXXXXXXXX"(V(S)-1=111) A=Acked N=Nacked U=Unacked X=Resend-Unacked I=Invalid
25.. retransmitting the nacked.. and then the ones that migh have
26already arrived
27<0004> tbf.cpp:834 TBF(TFI=0 TLLI=0xd7b78810 DIR=DL) downlink (V(A)==59 .. V(S)==112)
28<0004> tbf.cpp:840 - Resending BSN 111
29
30
31Figure out scheduling issue. Why do we reach the 20 re-transmits and
32stil haven't received the ACK/NACK? was it scheduled? The whole
33scheduler could be re-worked to be more determestic.. and answer
34questions like if it has been sent or not