Hi all,
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.
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, 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). To deliver the SMS we need to page the SMS and currently we are paging 20 MSs during 2 seconds.
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.
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.
So here is my problem: - Remove the notion of paging slots... the nanoBTS is not even sending the load indication anyway. - 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.
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.
regards holger
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...
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.
We do with with OpenBTS, too and it works fine. If there's a problem, it's in your local implementation, not in the spec.
On Apr 19, 2010, at 12:27 AM, Harald Welte wrote:
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.
David A. Burgess Kestrel Signal Processing, Inc.
-
David A. Burgess -
Harald Welte -
Holger Freyther