21 Jan
2014
21 Jan
'14
1:51 p.m.
Hello Harald,
Thanks for your inputs.
On Fri, Jan 17, 2014 at 10:20 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
I investigated this in osmobts. The delay was exactly 20 seconds per physical ts, thus
amounting around 160 seconds approx. The reason seems to be OML_PING_TIMER of 20 sec set
after LINK_STATE_CONNECT in abis_timeout() function. I guess that's the polling time
for the abis messages?
I do not think they are false positives from the phy, neither I think our CRC is weak.
Those are mainly the rach from real commercial phones around.
During the
configuration, openbsc takes quite a long time to configure all the physical timeslots.
I don't think there are any delays in the OpenBSC codes, at least not that I
remember.
The OML configuration on the sysmoBTS or nanoBTS takes only seconds for a single TRX.
We see a lot
of unexpected channels are configured
I suspect this is related to the fact that
the RACH detection only has a very weak CRC,
which means that you get lots of false positives from the PHY. Is that the case? I would strongly argue against running any
'open' network outside a faraday cage.
So I believe you are doing it the 'right' way.
Of course yes! Auth policy
in the config is always closed :)
You can tune a lot of the parameters.
In osmo-bts code itself, you can set a threshold in terms of RxLevel or C/I
and drop all requests below a certain level or C/I
I need to check the support for those messages in our L1.
In the system information, you can play with paramters
such as Rx-Access-Level-Min.
The parameter rxlev access min <0-63> in the openbsc config takes care of this?
But again, this is measurement information I guess and need to be supported by the phy.
Write access is permitted only via git-over-ssh, and
we would need your ssh public key.
If you send that public key by private mail to me, I can autorize you to commit to the
repository.
Ok I will do that in the separate email.
Thanks,
Jason