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.

I think to fix the problem with the quick retransmission , I need some type
of scheduling. Because if I queue the incoming uplink-msgs in the
bts-virtual-layer1 instead, I don't know when they are processed on the ms
 side and thus don't know when to send the rach-confirm to layer23...

My idea for a simple scheduler would be:
-- no timing and timer interrupts on ms side, but just set the current fn in
the ms state each time we receive a message on downlink to the fn of
the received message, which is accessible in the gsmtap header.
-- queue the outgoing uplink messages with their confirm callback to l2
and process all that with a smaller fn than the current fn in the scheduling
function.
-- calling the scheduling function each time we receive a msg on downlink
(so I do not need to handle timer interrupts)

I hope that will be sufficent and try it out tomorrow. I am a bit afraid of trouble
caused by the frame number skipping values with the upper incrementation
logic.

With kind regards,
Sebastian Stumpf