Project

General

Profile

Feature #2591

ramp up cell slowly to avoid severe RACH/SDCCH overload

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

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

0%

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 REJECT New 10/23/2017
Related to OsmoBSC - Feature #2722: document RACH tuning parameters more thoroughly, give explanations New 12/08/2017

History

#1 Updated by laforge 3 months ago

  • Tracker changed from Bug to Feature

#2 Updated by laforge 3 months ago

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

#3 Updated by laforge about 2 months ago

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

Also available in: Atom PDF