Hello Harald, Thanks for your inputs. On Fri, Jan 17, 2014 at 10:20 PM, Harald Welte <[email protected]> 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
