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/.
Jason DSouza Jason.DSouza at octasic.comHello Harald, Thanks for your inputs. On Fri, Jan 17, 2014 at 10:20 PM, Harald Welte <laforge at 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