Project

General

Profile

Actions

Feature #2591

closed

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

Added by laforge about 4 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
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 REJECTResolvedstsp10/23/2017

Actions
Related to OsmoBSC - Feature #2722: document RACH tuning parameters more thoroughly, give explanationsResolveddaniel12/08/2017

Actions
Related to OsmoBSC - Feature #2893: automatic simulator for large LU load Stalled01/27/2018

Actions
Related to OsmoBSC - Feature #3097: ramping of "rxlev access min"New03/22/2018

Actions
Related to OsmoBSC - Feature #3098: ramping of transmit powerRejectedstsp03/22/2018

Actions
Actions #1

Updated by laforge about 4 years ago

  • Tracker changed from Bug to Feature
Actions #2

Updated by laforge about 4 years ago

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

Updated by laforge about 4 years ago

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

Updated by laforge almost 4 years ago

  • Assignee changed from sysmocom to stsp
Actions #5

Updated by laforge almost 4 years ago

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

Updated by stsp almost 4 years ago

  • Status changed from New to In Progress
Actions #7

Updated by stsp almost 4 years ago

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

Actions #8

Updated by stsp almost 4 years 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?

Actions #9

Updated by stsp almost 4 years ago

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

Actions #10

Updated by stsp almost 4 years 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.

Actions #11

Updated by stsp almost 4 years 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
Actions #12

Updated by stsp almost 4 years ago

Actions #13

Updated by stsp almost 4 years ago

Actions #14

Updated by stsp almost 4 years ago

  • Status changed from Resolved to In Progress
Actions #16

Updated by stsp over 3 years ago

  • Status changed from In Progress to Resolved

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

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)