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/.
Alexander Chemeris alexander.chemeris at gmail.comHi Holger, On Mon, Jan 27, 2014 at 1:13 AM, Holger Hans Peter Freyther <holger at freyther.de> wrote: > On Mon, Jan 27, 2014 at 12:55:31AM +0400, Alexander Chemeris wrote: > >> At this moment we (Fairwaves) are busy with fixing bugs and improving >> the CS part of NITB (calls and SMS), but I hope we'll get back to GPRS >> as we get more customers demanding it. As usual, one can support this > > Ah that is great news. Do you mind sharing with the community which > defects you are experiencing? Definitely. You've seen some of hose patches at the mailing list. Unfortunately we haven't had enough free time yet to merge them into master, as we've been using jolly-branches. I hope that jolly-branches will be merged into master soon, including the osmo-trx support, and we'll submit those patches for merging to master as well. As an example, we're experiencing issues with SMS delivery in a case of spotty coverage and high network load. It's too early to share anything, as we're still understanding the reasons and how to solve this. We're looking into may be writing a unit test for the NITB's SMSC, but it's not clear yet how to do this cleanly and without too much effort. Another issue with SMS is that validity period is not supported and SMS stay in the DB forever, making to too slow after just a few days of usage. Then, there is an issue with OsmoBTS when there are too many phones are trying to connect to it for LUR. I described this a while ago, but we haven't had time to look more into it yet. So far we just used various workarounds to solve it. We're looking into writing a BS power reduction algorithm, similar to the one used in OpenBTS - If there is a severe congestion for LU's, BS will reduce its power until the load doesn't stabilize. Then it'll slowly increase the power again, until it hits the LU congestion or hits the maximum specified power. Then, there is this whole big thing about using an SQLite DB for everything, from HLR to SMSC to counters storage. This is fine for testing, but has its limitations when you run the system 24/7 under a heavy load. At this moments we're using workarounds like not storing counters in the DB and cleaning up the DB with a script, but we're looking into solving this in a proper way. These all is quite a lot of work, unfortunately, and it distracts us from working more on shiny new features like GPRS and EDGE. PS If there is any interest, I can talk at OsmoDevCon about our experience in running OsmoNITB in production and what we see as the challenges moving forward. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru