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 :/
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.
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).
It does not what? It doesn't work? You cannot establish SAPI3 on the channel
that's open after location updating accept? That's weird. I think we did this
at HAR and it worked fine. The only thing that doesn't work is sending an SMS
before you have sent the LOC UPD ACCEPT.
Or are you referring that your proprietary MSC doesn't do that ;)
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.
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)
The BTS has something like 200 RACH slots a second... so sending 20 requests on
the downlink is certainly no problem.
Even if two MS are accessing the same channel, it should not result in a readio
link failure. Both will tune to the assigned channel and send the first packet
(SABME with PAGING RESPONSE as L3). The BTS will echo back the received packet
(one of them should have survived). One phone will see its own message echoed
back (good). The other phone will see a different message (bad) and thus
locally close the channel.
However, in your specific setup, the two phones might be received with exactly the same
(high) signal level, so there might be too many errors at the BTS to still be able to
decode the first message.
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.
- 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.
The other reason to write this mail is, I think it is
pretty interesting
to see how our experiments from the congress look different to what I
was seeing due way more paging going on.
apparently yes...
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)