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/.
Holger Freyther zecke at selfish.orgOn 04/19/2010 03:27 PM, Harald Welte wrote: > Hi Zecke, > > On Mon, Apr 19, 2010 at 12:37:12PM +0800, Holger Freyther wrote: > >> I will implement the following changes on the on-waves/bsc-master branch >> and if no one is screaming move them over to master shortly afterwards. > > I think they might be a bit controversial - at least in part :/ No problem, I will solve my problem first and then we can see how controversial things are looking. > >> Right now I'm experiencing the following problem. When enabling the RF >> on the BTS hordes of MS come to the network for Location Updating >> Requests and the SDCCHs are close to 100% loaded, > > What I would recommend is to slowly ramp up the power. This is how IMSI > catchers avoid that problem. You start with the lowest transmit power of the > BTS and then increase only once your load at that transmit level is low enough. > > I have no idea how we could easily increase the power of the nanoBTS _while_ it > is operating. Setting the MAX_POWER_RED attribute is done via OML and I'm > almost certain (worth checking) that the transceiver needs to be locked to > change it. I didn't know that. I can give it a try and then see what is going on. It might take a day or two until I have the time to try it. > >> now I want to send a SMS to every new Subscriber welcoming it (ideally one >> would do it during the LU but... well... it does not). > Or are you referring that your proprietary MSC doesn't do that ;) Exactly, or actually... thanks to the closed "market" the module sending the welcome SMS and the MSC have little in common... I would be very interested in a paid study of loss generated by proprietary software... In that case we have to use more power on the network and mobile side for the extra paging and such... :) > >> The first problem is that the nanoBTS can not handle this load for a >> long time, it is sending CPU Overload and as of GSM 08.58 we should >> handle it by throttling the transfer but well that is not implemented. > > I hate the nanoBTS for giving such indifferent error messages... and we might > sooner or later reconsider implementing the throttling after all. Do you happen to know if it is generating messages for the RACH load? I have seen some parsing inside the abis_rsl.c for it, but I can not remember to have seen such a message in the traces. > >> The other problem is with the 20 paging requests every two seconds I'm >> creating a RACH DoS for my BTS to a point that I think (didn't bother to >> do the easy math, and I don't have the spec here right now) we have two >> MS picking the same random number. At least the symptom is that even if >> we assign a channel, it gets closed down with a RF Failure. > > Maybe the RACH retransmission time and count are set too small? > > Maybe somehow we are too slow in responding to the request (remember that > stupid usleep in the ipaccess input plugin? maybe it can be disabled after > the BTS OML startup) Two very good points, we can test one of them easily, while the other is... well we have burned our hands twice, it is time for the third time and with some time we might see what we are doing wrong in regard to the order of messages. > > The BTS has something like 200 RACH slots a second... so sending 20 requests on > the downlink is certainly no problem. Yeah, thanks to the TDMA excercise on OsmocomBB, I assumed that we can easily send that many requests (we can page like 5-8 MS during a 51 multiframe). But just by looking at the symptoms. I do see CPU overload messages and at some point the OML connection drops, and everything is better when I do not send the paging requests (it also means I don't attempt MT-SMS). >> So here is my problem: >> - Remove the notion of paging slots... the nanoBTS is not >> even sending the load indication anyway. > > yes, but other BTS do (like BS-11, and hopefully many others that we will > eventually support. We already have a static const structure representing > a BTS type, so we can simply add this as a flag to that data structure. okay. > >> - Look at free channels (ignoring the requested channel at >> first... something we need to fix later) and have a config >> switch like.. only page if the cell is like 50% loaded or >> such. I will figure out the details while doing the changes. > > As long as that is an option, I have no problems at all. I will see if that cures my problem and then work on a revised version for master.