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.
I fixed that and calculate the proper rach fn like in https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1... .
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