Virtual layer 1 - Questions

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Thu Feb 23 14:41:24 UTC 2017


Hi Sebastian,

On Sun, Feb 19, 2017 at 06:16:01PM +0100, Sebastian Stumpf wrote:
> > 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

good.

> > 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 see.  the confirmation should probably be delayed somehow.  As a quick
intermediate hack you might simply add a timer.

> > 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.

yes, that makes sense.

> -- 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.

yes, but please keep in mind that the frame number is wrapping every so
often, so "smaller" must consider that modulo-arithmetic, or you will
(after fn wrap) have pending downlink messages for much higher fn which
are not sent as the wrapped fn is now very small.

> -- calling the scheduling function each time we receive a msg on downlink
> (so I do not need to handle timer interrupts)

yes.  I think it is reasonable to not have any actual timers on the ms
side and always depend on the frame numbers in the downlink messages
from the BTS.  After all, in the worst case you have periodic messages
like the BCCH messages that can be used to update the fn.

> 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.

I don't think skips are that problematic.  But then, I haven't tried it ;)

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list