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/layer…
.
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