Hi Harald,
thanks for the detailed response.
> I also see that the RACH requesets all are sent with a bogus frame
> number: 42. This will not work. The RACH request needs to be sent with
> the current frame number at the time being.
> Also, RACH retransmissions
> are happening way too quick.
Calculating a proper frame number didn't fix the fast retransmissions.
They are caused by sending the channel request over the virtual um
immediately after getting the rach-request from layer23. Thus also the
rach-confirm is sent to l23 immediately, so layer23 thinks "oh fine its
already transmitted" and will generate the next rach-request for my
layer 1.
> I think one can do without on the MS side, but then the BTS must
> basically queue the incoming frames until the respective frame number
> indicated in the frame matches the current frame number.
of scheduling. Because if I queue the incoming uplink-msgs in the
side and thus don't know when to send the rach-confirm to layer23...