| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
osmo-trx-uhd with a B200 has proven to provide bad (lower than usually
considered good) C/I values due to high noise (even with band filters in
place). Hence, default thresholds (gathered from literature on the topic)
are too high and end up in bad algorithm output decisions.
Furthermore, most users of Osmocom don't use it in densely populated
areas, hence RXLEV based algorithm used when C/I based one is disabled
is good enough.
Let's disable C/I based one by default, and let advanced users which
specific needs to enable and confiure thresholds specifically for their
needs (hardware, cell surrounding conditions, etc.).
Related: SYS#4917
Change-Id: If1a73c60695379bcfcd0f44c6ec6dd659563e279
|
|
Increase the reaction time at the expense of more stable loop with less
temporary oscillations.
See updated user manual documentation in this commit for a larger
description.
Related: SYS#5371
Change-Id: I46be244a5e01a74086e3a977ec3ea139742a0074
|
|
* Adds vty option dyn-bsc for ms-power-control -> mode
* Imports power_control.c from osmo-bts project
[at commit 2f3cd4b697972d8484f9a9d3b7ef634086f65fa5]
* Removes unused C/I code from osmo-bts's power_control.c
This patch then calls the power loop on receipt of measurement
reports and updates the MS Power Level accordingly.
Change-Id: Ibc307e758697eb5ca3fb86622f35709d6077db9e
|
|
Improve the current VTY support to allow enabling/disabling C/I logic
independent from value setting. This way C/I support can be quickly
disabled & enabled.
Reminder: changing power parameters still require VTY Command "bts NR
resend-power-control-defaults" to be excuted prior to new parameters
being applied on the BTS.
Related: SYS#4917
Change-Id: Id1224c2d9a52db2ed805c49e048d3086ed0167f5
|
|
Setting LOWER_CMP_N and UPPER_CMP_N for all channel types can be quite
cumbersome and end up in lengthy config files. Let's instead add a
placeholder command to apply it to all channel types of a BTS at once.
This is useful specially since a user disabling C/I capabilities
probably does so because it may require a fair amount of fine-tuning
parameters to have it working perfectly. Hence, a user not willing to
spend time configuring those parameters correctly (and for which default
ones doesn't work properly) will require quick way to get rid of C/I
based MS Power Control Loop. By disabling C/I comparison, osmo-bts will
rely on RxLev only when applying the MS Power Control Loop, which is
fine for non noisy environments.
Related: SYS#4917
Change-Id: I0e1a1a9228a15e9ec9c41b7952b03e1d25309706
|
|
TS 45.008 section 4.7.1:
"""
Upon receipt of a command from an SACCH to change its power level on the corresponding uplink channel, the MS
shall change to the new level at a rate of one nominal 2 dB power control step every 60 ms (13 TDMA frames), i.e. a
range change of 15 steps should take about 900 ms. The change shall commence at the first TDMA frame belonging to
the next reporting period (as specified in subclause 8.4). The MS shall change the power one nominal 2 dB step at a
time, at a rate of one step every 60 ms following the initial change, irrespective of whether actual transmission takes
place or not.
"""
Since the reported MS_PWR in L1 SACCH Header is, according to specs, the
one used for the last block of the previous SACCH period, it becomes
clear the first SACCH block after a requested MS Power Level change by
the network may contain mismatches between the announced MS_PWR by the
MS and the measured Rxlev/RxQual. Hence, let's better use a
P_CON_INTERVAL of 1 which retriggers the MS Power Control Loop every second
SACCH block.
Related: SYS#5371
Change-Id: Iade5b597e0e56b07c6d78995fcec7c641e4e643f
|
|
This commit extends existing VTY and RSL infrastructure to configure and
manage MS Power Parameters used in MS Power Control loop, by adding
support to set up Carrier-to-Interference (CI) parameters.
Using C/I instead of existing RxQual is preferred due to extended
granularity of C/I (bigger range than RxQual's 0-7).
Furthermore, existing literature (such as "GSM/EDGE: Evolution and Performance"
Table 10.3) provides detailed information about expected target values,
even different values for different channel types. Hence, it was decided
to support setting different MS Power Parameters for different channel
types.
These MS Power Parameters are Osmocom specific, ie. supported only by
newish versions of osmo-bts. Older versions of osmo-bts should ignore
the new IEs added just fine. The new IEs containing the MS POwer
Parameters are not send for non osmo-bts BTSs, hence this commit is
secure with regards to running osmo-bsc against an ip.access BTS such
as nanoBTS.
Related: SYS#4917
Depends: libosmocore.git Change-Id Iffef0611430ad6c90606149c398d80158633bbca
Change-Id: I7e76ec47b323d469f777624b74b08752d1f5584f
|
|
Change-Id: I6e0fae81cc60f708e49d5eb8dfc0bbcad926b18f
Related: SYS#4918
|
|
Change-Id: I82e762c0c2b5e0dd739850ee494ab0a798e353de
Related: SYS#4918
|
|
Presence of these lines in the config file does not necessarily mean
that the BTS will not perform measurement pre-processing. It actually
means that the BSC would not include the optional IEs related to the
measurement pre-processing, so the BTS may still apply its default
averaging algorythm with default parameters.
In order to avoid potential confusion, let's avoid printing them.
Change-Id: I585b5bf4fde93d66e47666e0fa9903f21a268b51
Related: SYS#4918
|
|
Change-Id: I43cad92ea50f819ee56101d131d0060c2f8e174f
Related: SYS#4918
|
|
Before the recent changes, the MS Power Parameters IE would always
be included empty in RSL CHANnel ACTIVation messages iff the BTS
type is 'osmo-bts'. Then this behavior was changed, so the user
would need to enable dynamic power control explicitly.
This is a regression, let's revert it back to the old behaviour.
Change-Id: Idb453fc894584ccf4f5f8b45a24421db958e9478
Related: SYS#4918
|
|
According to 3GPP TS 45.008, section A.3.2.1:
c) Comparison of RXQUAL_XX with L_RXQUAL_XX_P (XX = DL or UL):
Increase XX_TXPWR if at least P3 averaged values out of N3
averaged values are greater (worse quality) than L_RXQUAL_XX_P.
d) Comparison of RXQUAL_XX with U_RXQUAL_XX_P (XX = DL or UL):
Decrease XX_TXPWR if at least P4 averaged values out of N4
averaged values are lower (better quality) than U_RXQUAL_XX_P.
Given that RxQual is a value in range 0 .. 7, where 0 is the best
and 7 is the worst: L_RXQUAL_XX_P must define the worst quality,
while U_RXQUAL_XX_P must define the best quality value.
Change-Id: I0f37b23ed360782f3c1f4275234c4e18a17aa89b
Related: SYS#4918
|
|
Change-Id: I66d414a5f761eeec042a47207fc7d295e073cd10
Related: SYS#4918
|
|
Change-Id: I11ca856aba46aaf84d94cbbdf4c39a01ee8289b9
Related: SYS#4918
|
|
Change-Id: Ifd6ea29c3b9dbaccf92856131d5fb2e352b84eb2
Related: SYS#4918
|
