On 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.