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/layer…
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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)