| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Right now, it's impossible to see any ACC Ramping information unless RSL
category is set to DEBUG. Barring and Allowing Access Control Class is
an important event which should be printed in most cases.
Increase log levels of messages printed during some error conditions to
be handled as errors.
Backport of osmo-bsc.git commit
67f20bc356a4908bdb71b5dfc6a1932e6c1fac68.
Change-Id: Iec10c2be7aa5efeadd6b0706916678acc5461111
|
|
Take both the operative and administrative states into account
when deciding whether to start ACC ramping, and examine old/new
state values to avoid triggering ramping for a no-op state change.
This requires a fix to gsm_trx_lock_rf(): This function overwrote
the old administrative state of a trx before enqueuing a state
change request towards the BTS.
The BTS will confirm this request with an ACK, at which time a
signal is generated which the ACC ramp code listens to. We must
not overwrite the old state value until the signal has been handled,
otherwise the signal handler cannot tell what the old state was.
Tested with a virtphy setup, nanobts, and osmo-bts.
This is a port of osmo-bsc commit cda994edb20d24032d6ab4e916d0e9411671cfc0
Change-Id: I235d2c5fa962f2f338e77d0c11502921b37f4c36
Related: OS#2591
|
|
Starting an ACC ramping process while TRX 0 is unusable or locked is
pointless. For instance, after loading a config with 'rf_locked 1'
for trx 0, the ramping process was started as soon as the BTS
established RSL, even though the air interface was still down.
ACC ramping should instead be triggered once TRX 0 is unlocked.
This is a port of osmo-bsc commit 4d3d2436cdf3296ddc110be4022dc2ec13d3eb86
Related: OS#2591
Change-Id: I2cc9c1b8193546ea04ea5beb3751c2206f0215f2
|
|
Trigger ACC ramping not only when an Administrative State Change
ACK is received from a BTS, but also when an administrative state
change is reported for TRX 0 in a State Changed Event Report.
This should allow ACC ramping to work with any BTS which reports
an administrative state change to 'unlock' using either of these
OML messages.
Tested with a sysmobts and a nanobts.
The sysmobts only reports TRX locked/unlock changes in Administrative
State Change ACKs, not via State Changed Event Reports.
The nanobts is known to send both of these OML messages in quick
succession, so do not re-trigger ramping if it's already in progress.
This is a port of osmo-bsc commit b06c7a253752ecb67fd20cdf0b069688b561af0e
Change-Id: I6443635b822b6cd776f6dc8a6ee73ab09e865b04
Related: OS#2591
|
|
The word 'enabled' was used in two contexts: Whether ACC ramp is
enabled as a feature, and whether a particular access control class
is permantly allowed/disallowed via VTY configuration.
Rename some helper functions to avoid the use of the word 'enabled'
in the latter context.
This is a port of osmo-bsc commit 0ad90b39b9e638b5e3d926c9261d26e777ca478c
Change-Id: Ic1e5a1f969823cfbfb9fe9e959db87c1717c3a83
Related: OS#2591
|
|
Make ACC ramping listen to network management signals and trigger
or abort ACC ramping based on the RF locked state of TRX 0.
This is a port of osmo-bsc commit 60ecdeffecf3db4ad044c5ee0185f384d1b16eb3
Change-Id: I4124f1da3dadec003de45c1da8435506ee8f0a34
|
|
There are plans to register signal handlers in acc_ramp_init(). Once we
do that, the acc_ramp_init() function should only be called once to
avoid duplicate signal handlers on the handler list.
However, the acc_ramp_init() function currently serves a dual-purpose:
1) Initialize the acc_ramp structure for a bts
2) Enable or disable ACC ramping
Add new functions to support use case 2, and call acc_ramp_init()
just once while reading the configuration file. The VTY commands
which enable/disable ACC ramping use the new APIs instead.
Also, rename acc_ramp_start() to acc_ramp_trigger() and tweak its
semantics so that it can always be called regardless of what the
current configuration settings are. This prepares us for triggering
ACC ramping upon events other than "RSL link-up".
This is a port of osmo-bsc commit ea33341cf7b52d432be98f2280b4a5f3129ef667.
Also remove a call to acc_ramp_init() which should have been removed in
openbsc commit ebc1e39d919f5f919cb176ee9c6cbbccc8d620b1
Change-Id: Iadd25016e6478a9dc5da1db42e6192ce0f5cc746
Related: OS2591
|
|
Silence log messages about no-op changes to access granted to access
control classes. For example, these always occur while configuration
files are being loaded.
This is a port of osmo-bsc commit 53d40e078e9df20103b7ed26daa936720c9dec83
Related: OS#2591
Change-Id: I2f892b998eb8119e623c1d87ffe865b48f7d5a87
|
|
Access Control Class (ACC) ramping is used to slowly make the cell
available to an increasing number of MS. This avoids overload at
startup time in cases where a lot of MS would discover the new
cell and try to connect to it all at once.
Ramping behaviour can be configured with new VTY commands:
[no] access-control-class-ramping
access-control-class-ramping-step-interval (<30-600>|dynamic)
access-control-class-ramping-step-size (<1-10>)
(The minimum and maximum values for these parameters are hard-coded,
but could be changed if they are found to be inadequate.)
The VTY command 'show bts' has been extended to display the
current ACC ramping configuration.
By default, ACC ramping is disabled.
When enabled, the default behaviour is to enable one ACC per
ramping step with a 'dynamic' step interval. This means the
ramping interval (time between steps) is scaled to the channel
load average of the BTS, i.e. the number of used vs. available
channels measured over a certain amount of time.
Below is an example of debug log output with ACC ramping enabled,
while many 'mobile' programs are concurrently trying to connect
to the network via an osmo-bts-virtual BTS. Initially, all ACCs
are barred, and then only one class is allowed. Then the current
BTS channel load average is consulted for scheduling the next
ramping step. While the channel load average is low, ramping
proceeds faster, and while it is is high, ramping proceeds slower:
(bts=0) ACC RAMP: barring Access Control Class 0
(bts=0) ACC RAMP: barring Access Control Class 1
(bts=0) ACC RAMP: barring Access Control Class 2
(bts=0) ACC RAMP: barring Access Control Class 3
(bts=0) ACC RAMP: barring Access Control Class 4
(bts=0) ACC RAMP: barring Access Control Class 5
(bts=0) ACC RAMP: barring Access Control Class 6
(bts=0) ACC RAMP: barring Access Control Class 7
(bts=0) ACC RAMP: barring Access Control Class 8
(bts=0) ACC RAMP: barring Access Control Class 9
(bts=0) ACC RAMP: allowing Access Control Class 0
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 1
(bts=0) ACC RAMP: step interval set to 354 seconds based on 59% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 2
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 3
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
Port of osmo-bsc commit a5c1e8727c391bc56847a00b2ecc08787573b91f
Change-Id: Idd5c4fd7ea2e10086d9b26deee3a71f9469d1280
Related: OS#2591
|
