Osmocom Packet control Unit (PCU): Network-side GPRS (RLC/MAC); BTS- or BSC-colocated https://osmocom.org/projects/osmopcu
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

34 lines
1.4 KiB

* Change functions with 100 parameters to get a struct as param
* Move move into the TBF class
* tbf/llc window code appears to be duplicated and nested in other
methods. This needs to be cleaned.
* Possible race condition:
When scheduling a Downlink Assignment on the UL-TBF we need to make
sure that the assignment is sent _before_ the final ack. With my fairness
changes it gets more likely that this event is trigerred.
* Optimize:
After receiving an ACK/NACK.. schedule another one if the window
is kind of stalled anyway. This way we avoid resending frames that
might have already arrived. It could increase the throughput..
Do not re-transmit after we got ack/nacked and where in the resending
mode... and increase the window.
<0004> tbf.cpp:907 - Sending new block at BSN 111
tbf.cpp:858 - Restarting at BSN 48, because all window is stalled.
tbf.cpp:1383 - V(B): (V(A)=59)"NNAAAAAAANAAAAANNAAAAAAAAAAAAAAAAAAAXXXXXXXXXXXXXXXXX"(V(S)-1=111) A=Acked N=Nacked U=Unacked X=Resend-Unacked I=Invalid
.. retransmitting the nacked.. and then the ones that migh have
already arrived
<0004> tbf.cpp:834 TBF(TFI=0 TLLI=0xd7b78810 DIR=DL) downlink (V(A)==59 .. V(S)==112)
<0004> tbf.cpp:840 - Resending BSN 111
Figure out scheduling issue. Why do we reach the 20 re-transmits and
stil haven't received the ACK/NACK? was it scheduled? The whole
scheduler could be re-worked to be more determestic.. and answer
questions like if it has been sent or not