<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi Harald,<br><br></div>thanks for the detailed response.<br><br>> I also see that the RACH requesets all are sent with a bogus frame<br>
> number: 42.  This will not work.  The RACH request needs to be sent with<br>
> the current frame number at the time being. <br><br></div><div>I fixed that and calculate the proper rach fn like in <a href="https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1/prim_rach.c#L137-L151">https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1/prim_rach.c#L137-L151</a>.<br></div><div><br>> Also, RACH retransmissions<br>
> are happening way too quick.<br><br></div>Calculating a proper frame number didn't fix the fast retransmissions. <br>They are caused by sending the channel request over the virtual um <br>immediately after getting the rach-request from layer23. Thus also the<br>rach-confirm is sent to l23 immediately, so layer23 thinks "oh fine its <br>already transmitted" and will generate the next rach-request for my <br>layer 1.<br><br>> I think one can do without on the MS side, but then the BTS must<br>
> basically queue the incoming frames until the respective frame number<br>
> indicated in the frame matches the current frame number.<br><br></div> I think to fix the problem with the quick retransmission , I need some type <br>of scheduling. Because if I queue the incoming uplink-msgs in the <br>bts-virtual-layer1 instead, I don't know when they are processed on the ms<br> side and thus don't know when to send the rach-confirm to layer23...<br><br></div>My idea for a simple scheduler would be:<br></div>-- no timing and timer interrupts on ms side, but just set the current fn in<br>the ms state each time we receive a message on downlink to the fn of <br>the received message, which is accessible in the gsmtap header.<br>-- queue the outgoing uplink messages with their confirm callback to l2 <br></div>and process all that with a smaller fn than the current fn in the scheduling <br>function.<br></div>-- calling the scheduling function each time we receive a msg on downlink <br>(so I do not need to handle timer interrupts)<br><br></div>I hope that will be sufficent and try it out tomorrow. I am a bit afraid of trouble <br>caused by the frame number skipping values with the upper incrementation <br>logic.<br><br></div>With kind regards, <br></div>Sebastian Stumpf<br><div><div><div><br></div></div></div></div>