GPRS, EDGE support

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

David A. Burgess dburgess at jcis.net
Tue Jan 28 11:11:58 UTC 2014


Ralph -

On Jan 27, 2014, at 17:07, Ralph A. Schmid, dk5ras <ralph at schmid.xxx> wrote:

> Hi,
> 
>> Then, there is an issue with OsmoBTS when there are too many phones are
>> trying to connect to it for LUR. I described this a while ago, but we haven't
>> had time to look more into it yet. So far we just used various workarounds to
>> solve it. We're looking into writing a BS power reduction algorithm, similar to
>> the one used in OpenBTS - If there is a severe congestion for LU's, BS will
>> reduce its power until the load doesn't stabilize. Then it'll slowly increase the
>> power again, until it hits the LU congestion or hits the maximum specified
>> power.
> 
> Sure that this is a good idea? It will throw out all users at the edge of the coverage 
> area, maybe cause even more load, when those show up again with their accumulated 
> requests like call attempts, SMS, additional LU, and in fact I have never seen that 
> commercial networks do something like that.
> 
> Is there not some waiting queue defined in the standards, with some timers, 
> commanding the location updaters to wait for some period of time? Has 
> been a long time when I looked into this, but I mean to remember that even 
> OpenBTS does it this way.

There is a hold-off timer sent in the immediate assignment reject message, but it is still possible for the RACH to be so congested that only a small fraction of bursts are decodable.  And it is possible for the AGCH to be so congested that it is impossible to respond to any significant fraction of the requests anyway.  Once this happens, you get a kind of live-lock on the air interface.  If you are the only BTS in the area, this locked condition can persist for hours.  You can either turn down the power and reduce the number of phones in the coverage area and serve that reduced population, or stay in the live-lock condition and not serve anyone.

Yes, you ramp up power on startup.  We just automated that process.  And unless the BTS falls into this kind of live-lock condition, because of the sudden failure of a neighbor cell or some other overlapping network, this mechanism does not take any action.

> 
> Or am I totally wrong?
> 
>> From my point of view slowly increasing TX power is OK for booting a new cell into 
> operation, but during normal operation?!

It’s not normal operation.  It is an emergency measure that takes effect with the network is in a hopeless congestion condition.  And in my experience, this approach changes the recovery time from several hours to several minutes.

> 
>> --
>> Regards,
>> Alexander Chemeris.
>> CEO, Fairwaves LLC / ООО УмРадио
>> http://fairwaves.ru
> 
> Ralph.
> 
> 





More information about the OpenBSC mailing list