Project

General

Profile

Feature #2591

ramp up cell slowly based on access control class to avoid severe RACH/SDCCH overload

Added by laforge 9 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
10/23/2017
Due date:
% Done:

0%

Estimated time:
Spec Reference:

Description

When a cell is enabled in presence of many (e.g. 10k) phones and no other network around, the network is severely overloaded. We should implement a variety of ramping mechanisms to slowly grow the cell. This includes
  • ramping of transmit power (pretty useless in case of active antenna distribution system)
  • ramping of access control classes (SIMs are assumed to have equal statistic distribution over all ACC)
  • ramping of "rxlev access min"
The ramping could be split in two parts:
  1. some generic ramping code that increments/decrements a certain value
    • the existing TX power ramping code of osmo-bts can be used as a template?
  2. parameter-specific code that uses the generic code/api for the specific parameter
  3. vty parameters to configure the ramping in terms of
    • initial value
    • maximum (normal) value
    • step size
    • delay between steps
There are some open questions, though:
  • should all ramps execute concurrently?
  • should they execute after each other? If yes, how do we trigger that?

Furthermore, aside the static ramping based on a timer, it would be great to be able to have a feedback loop that automatically runs those ramps using RACH / SDCCH load as input to the feedback loop. If theres no/low load, ramp fast. If load is high, ramp slower. Care must be taken not to completely stall any progress under high load.


Related issues

Related to OsmoBSC - Feature #2592: Use "waiting time" of IMMEDIATE ASSIGN REJECTResolved2017-10-23

Related to OsmoBSC - Feature #2722: document RACH tuning parameters more thoroughly, give explanationsNew2017-12-08

Related to OsmoBSC - Feature #2893: automatic simulator for large LU load Stalled2018-01-27

Related to OsmoBSC - Feature #3097: ramping of "rxlev access min"New2018-03-22

Related to OsmoBSC - Feature #3098: ramping of transmit powerRejected2018-03-22

History

#1 Updated by laforge 9 months ago

  • Tracker changed from Bug to Feature

#2 Updated by laforge 9 months ago

  • Related to Feature #2592: Use "waiting time" of IMMEDIATE ASSIGN REJECT added

#3 Updated by laforge 8 months ago

  • Related to Feature #2722: document RACH tuning parameters more thoroughly, give explanations added

#4 Updated by laforge 6 months ago

  • Assignee changed from sysmocom to stsp

#5 Updated by laforge 6 months ago

  • Related to Feature #2893: automatic simulator for large LU load added

#6 Updated by stsp 6 months ago

  • Status changed from New to In Progress

#7 Updated by stsp 5 months ago

Initial implementation proposal: https://gerrit.osmocom.org/#/c/6324/

#8 Updated by stsp 5 months ago

Access Control Class ramping is now implemented in master.

This issue is also asking for ramping of "rxlev access min". Should we keep this issue open for this reason, or should we spin that off into a separate issue?

#9 Updated by stsp 4 months ago

Access Control Class ramping has now been backported to OpenBSC as well: https://gerrit.osmocom.org/#/c/7295/

#10 Updated by stsp 4 months ago

I have spun off the other ramping approaches into separate issues: issue #3097 and issue #3098

This issue, which in practice was all about access control class ramping, will be closed.

#11 Updated by stsp 4 months ago

  • Subject changed from ramp up cell slowly to avoid severe RACH/SDCCH overload to ramp up cell slowly based on access control class to avoid severe RACH/SDCCH overload
  • Status changed from In Progress to Resolved

#12 Updated by stsp 4 months ago

#13 Updated by stsp 4 months ago

#14 Updated by stsp 3 months ago

  • Status changed from Resolved to In Progress

#16 Updated by stsp 3 months ago

  • Status changed from In Progress to Resolved

Closing this ticket again. Unless new problems show up unexpectedly, this work is now complete.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)