Hello Harald, Thanks for your inputs.
On Fri, Jan 17, 2014 at 10:20 PM, Harald Welte laforge@gnumonks.org wrote:
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.
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?
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 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.
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