Changes to the paging subsystem

[Harald Welte]

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)