Virtual layer 1 - Questions

Sebastian Stumpf sebastian.stumpf87 at googlemail.com
Sun Feb 19 17:16:09 UTC 2017


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/prim_rach.c#L137-L151
.

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170219/6d445816/attachment-0001.html>


More information about the baseband-devel mailing list