Most of the BTS specific VTY commands restrict BTS number to '<0-0>',
while bts_c0_power_red_cmd has '<0-255>'. This confuses libosmovty:
OsmoBTS# bts ?
<0-0> BTS number
<0-255> BTS Number
OsmoBTS# bts 0 ?
% Ambiguous command.
OsmoBTS# bts 0 c0-power-red 0
% Ambiguous command.
Let's stick to '<0-0>', we don't support multiple BTS anyway.
Change-Id: I937ac421143678b97627c1bc4fe573831ce097f6
Similar to what is already provided for power control loops. However,
there's no existing way to communicate TA control parameters from the
BSC to the BTS, so implement them locally in BTS vty.
Related: SYS#5371
Change-Id: I9fa71f836bb9a79b0ef2567bfcfdf38ff217840b
This commit extends existing MS Power Control Loop algorithm to take
into account computed C/I values on the UL, received from MS. The
related C/I parameters used by the algorithm are configured at and
provided by the BSC, which transmits them to the BTS similar to already
existing 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: I5dfd8ff9ab6b499646498b507624758dcc160fb6
We have two osmocom specific timers used in the BTS, X1 and X2. Expose
those on the VTY configuration, as timer group 'bts'.
This prepares for a subsequent patch, where I would like to add another
configurable timer. This provides the basic infrastructure for that.
Related: SYS#5559
Change-Id: I0f56f9425134679219884b0c3c2f29e77aff5e64
At the moment we can only configure a single BSC in the BTS
configuration. This also means that if this single BSC fails for some
reason the BTS has no alternate BSC to connect to. Lets extend the
remote-ip parameter so that it can be used multiple times so that an
operater can configure any number of BSCs that are tried one after
another during BTS startup.
Change-Id: I205f68a3a7f35fee4c38a7cfba2b014237df2727
Related: SYS#4971
Make gcc 11.1.0 false positivies happy
After my system's gcc was upgraded, I get false positivies in a couple
places. Let's initialize those to make gcc happy.
"""
//git/osmo-bts/src/common/vty.c: In function ‘lchan_summary’:
//git/osmo-bts/src/common/vty.c:1881:23: error: ‘ts’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
1881 | lchan = &ts->lchan[lchan_nr];
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~
//git/osmo-bts/src/common/vty.c:1869:20: error: ‘trx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
1869 | ts = &trx->ts[ts_nr];
| ~~~^~~~~~~~~~~~~~~~~
//git/osmo-bts/src/common/vty.c:1852:34: error: ‘bts’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
1852 | if (trx_nr >= bts->num_trx) {
"""
Change-Id: I93477142a5a4b3f3829b7398d6e564c127263596
They will gain support to be activated as SDCCH/8 soon too.
Related: SYS#5309
Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68
Change-Id: Ia617d20fc52f09dbab8f4516c06fa1efac08e898
The BCCH carrier (sometimes called C0) of a BTS shall maintain
discontinuous Downlink transmission at full power in order to
stay 'visible' to the mobile stations. Because of that, early
versions of 3GPP TS 45.008 prohibited BS power reduction on C0.
However, in the recent 3GPP TS 45.008 there is a feature called
'BCCH carrier power reduction operation'. This is a special
mode of operation, where the variation of RF level for some
timeslots is relaxed for the purpose of energy saving.
In BCCH carrier power reduction operation, for timeslots on the
C0 carrier, except timeslots carrying BCCH/CCCH, the output power
may be lower than the output power used for timeslots carrying
BCCH/CCCH. In this case the maximum allowed difference in output
power actually transmitted by the BTS is 6 dB.
The power reduction operation can be controlled by the BSC by
sending BS POWER CONTROL on the A-bis/RSL with the Channel Number
IE set to 0x80 (RSL_CHAN_BCCH). This makes osmo-bts reduce the
transmission power on inactive timeslots of the BCCH carrier.
This is a non-standard, Osmocom specific extension, so indicate
support of this feature to the BSC in the feature vector. Also
add a VTY command to allow enabling/disabling the power reduction
locally. Add some signalling notes to the A-bis/RSL manual.
For more details, see 3GPP TS 45.008, section 7.1.
Change-Id: I3dcee6e910ccc61c5c63c728db9ea04327e2fc98
Depends: I69283b3f35988fc7a1a1dcf1a1ad3b67f08ec716
Related: SYS#4919
In cfg_trx_phy_cmd(), use phy_instance_link_to_trx() and ensure
that a PHY instance can be bound to a transceiver only once.
Change-Id: I132e08fc496abef278b94254cebfac7a4285a7c2
The TSC (Training Sequence Code) value in 'struct gsm_bts_trx_ts'
is always initialized in oml_rx_set_chan_attr() during the OML
bootstrapping, so there is no need for gsm_ts_tsc() - remove it.
Store the initial TSC value in 'struct gsm_bts_trx_ts', so we can
apply a different TSC value during the RSL CHANnel ACTIVation.
Store the Training Sequence Code/Set in 'struct trx_dl_burst_req'.
These values are indicated to the transceiver (TRXDv2 PDUs, 'MTS'
field) and used by the new TRX_{GMSK,8PSK}_NB_TSC macros.
Change-Id: I3744bc308b99ef941e6e9d139444e414abebc14b
Related: SYS#4895, OS#4941
gsm_bts_trx_alloc() already does initialize some fields of the
allocated 'struct gsm_bts_trx' instance, and having an additional
function for initializing the other fields makes no sense.
Note that I intentionally didn't merge a call to bts_model_trx_init()
into gsm_bts_trx_alloc(), because this would break some assumptions
regarding the order of initialization and cause regressions.
This also allows us to not call bts_model_trx_init() from tests.
Change-Id: I4aefaf47b05a67ec0c4774c1ee7abcc95e04cc13
First of all, there is no reason to use a void pointer because
it's always 'struct phy_instance'. Also, no need to encapsulate
this pointer into 'role_bts' because there are no other roles in
osmo-bts (we used to have shared headers years ago).
This commit also fixes a bug in test_sysmobts_auto_band(), where a
pointer to 'struct femtol1_hdl' was directly assigned to trx.pinst.
Change-Id: I9bd6f0921e0c6bf824d38485486ad78864cbe17e
This significantly simplifies setups in which not only the IP DSCP
but also the IEEE 802.1Q PCP is to be set for RTP packets.
Depends: libosmo-abis.git I52c08f4b2a46981d002ef0c21e6549445d845a6e
Change-Id: Ia3a91e6788285be3e2e73defee63e6bd79c6258e
Related: SYS#5427
At the moment osmo-bts is not looging much ACCH repetition related
information. This makes testing ACCH repetition difficult. Lets add some
debug output that informs the user when ACCH repetition is turned on or
off. Lets also add an ACCH repetition status display to the show lchan
VTY command.
Change-Id: I59d11fd03be3d29fb8a4279d9945b03006764c0e
Related: SYS#5114
So far, the only way to configure GSMTAP Um logging is to use the
cmdline argument '-i'. Let's deprecate it, and add a VTY command
to allow setting the remote host from configuration file.
The legacy '-i' option, if provided, overrides the configuration
file option, and will also appear in 'write file'.
Change-Id: I17676a21c4e0c9cbc88f2c5c53a39c6c6c473ca1
Tweaked by: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
The cfg_out macro is used like a function in the code below its
definition. This means a colon will follow after it is used. When
the vty_out call in the macro already has a colon the final result will
be vty_out(...);;. This works fine as long the macro is not used in one
line if/else if/else constructs without curly braces {}. The compiler
will interpret the double colon as two lines of code and run into an
error then. Lets fix this by removing the colon from the vty_cout in the
macro.
Change-Id: I2c23c38ce892067add0f95f3e504a9c559e24519
These new commands are useful for debugging MS/BS power control
loops, e.g. one can change power control mode, overwrite the
current BS power reduction or MS power level at run-time.
Change-Id: I1ebb033b02c2bc3b1fa7de874e0035a07297f266
Related: SYS#4918
The loopback mode was added for testing, and may be dangerous if
enabled in production. Let's make it appear only in expert mode.
Change-Id: I3f68acd7f2b0231f78516f59fb5e8ef56fb69dbf
In change [1] the new power control structures and default params
were introduced. In change [2], the existing VTY commands for MS
power control in the BTS were deprecated and changed to use the
new structures as storage. Finally, in change [3], handling of
the power control parameters on the A-bis/RSL was implemented.
This change is the final logical step in the mentioned chain: it
makes both MS/BS power control loops use the new parameters, and
removes the old structures. The actual implementation of both
power control loops remains the same, however the expected output
of some unit tests for the Downlink loop needs to be changed:
- TC_fixed_mode: disabling dynamic power control becomes a separate
step of the test script since the field 'fixed' is removed;
- TC_rxlev_target: RxLev thresholds are printed 'as-is'.
Not all of the new parameters are used by the power control loops
yet. Further improvements to be done in the follow up commits.
[1] I6d41eb238aa6d4f5b77596c5477c2ecbe86de2a8
[2] Icbd9a7d31ce6723294130a31a179a002fccb4612
[3] I5a901eca5a78a0335a6954064e602e65cda85390
Change-Id: Ib18f84c40227841d95a36063a6789bf63054fc2e
Related: SYS#4918
MS/BS Power Control parameters have been recently moved to the BSC
and now signaled to the BTS over the A-bis/RSL link. Let's make
sure that the existing VTY commands for Uplink Power Control do:
- trigger deprecation warnings if present in the config file,
- not show up in the online VTY help nor VTY reference,
- affect the fall-back parameters in 'struct gsm_bts',
- still get printed by 'show running-config' command.
Change-Id: Icbd9a7d31ce6723294130a31a179a002fccb4612
Related: SYS#4918
It does not make sense to dump CCCH/CBCH as dedicated channels:
OsmoBTS# show lchan
BTS 0, TRX 0, Timeslot 0, Lchan 4: Type CCCH
State: ACTIVE
BS (Downlink) Power Control (autonomous):
Channel reduction: 0 dB (max 0 dB)
TRX reduction: 0 dB
Actual / Nominal power: 13 dBm / 13 dBm
MS (Uplink) Power Control (autonomous):
Current power level: 0, -39 dBm (max 0, -39 dBm)
Channel Mode / Codec: SIGNALLING
LAPDm SAPIs: DCCH --, SACCH --
Valid System Information: 0x00000060
MS Timing Offset: 0, propagation delay: 0 symbols
Radio Link Failure Counter 'S': 0
so let's only dump SDCCH, TCH/F, and TCH/H.
Change-Id: Id7880de56a93cc9fa4ca576b094cef35ee269822
We already have MS Power Control, which according to 3GPP 45.008
shall be implemented in the MS to minimize the transmit power in
the Uplink direction. The BS Power Control may optionally be
implemented by the network side for the same purpose.
Using Downlink signal measurements reported by the MS, the BSS
(either BSC, or BTS) may control Downlink attenuation in a way
that the transmit power remains as low as possible, or remains
in a specific range corresponding to good RxLev values on the
MS side. This change implements autonomous BS Power Control,
that can optionally be enabled by the BSC.
BS Power Control re-uses parts of the MS Power Control code,
so all parameters can be configured in the same way - via the
VTY interface or a configuration file. This basically means
that features like hysteresis and EWMA based filtering are
also available for BS Power Control.
The only difference is that RxQual values higher than 0 would
trigger the logic to reduce the current attenuation twice.
Note that one of the unit tests ('TC_rxlev_max_min') fails,
as the power step limitations for raising and lowering look
wrong to me, and the related discussion is still ongoing.
Change-Id: I5b509e71d5f668b6b8b2abf8053c27f2a7c78451
Related: SYS#4918
Similar to bts_vty_init(), BTS specific bts_model_vty_init()
requires a pointer to 'struct gsm_bts'. Not only it's used
as a parent talloc context, but also stored locally, so then
it can be used by some VTY commands.
Let's expose the global 'struct gsm_bts' from main, and pass
the application's talloc context like was done in [1].
This finally makes the BTS model specific options appear in
the automatically generated VTY reference (--vty-ref-xml).
[1] Ic356a950da85de02c82e9882a5fbadaaa6929680
Change-Id: Iee7fee6747dd1e7c0af36f9b27326f651ae37aaf
Related: SYS#4937, OS#3036
Otherwise only those commands that are registered by libosmocore
appear in the generated XML VTY reference - change the order.
Instead of a pointer to 'struct gsm_bts', pass the application's
talloc context, as it's only used for dynamic command allocation.
Change-Id: Ic356a950da85de02c82e9882a5fbadaaa6929680
Related: SYS#4937, OS#3036
Recently we've introduced EWMA based uplink power filtering, that
should reduce Uplink power oscillations. However, the power loop
is still quite sensitive to small deviations from the target power
level: even such an insignificant deviation like 2-5 dBm triggers
the loop to increase or decrease the MS power level. Even if the
EWMA based filtering is enabled with 80% smoothing (alpha = 0.2).
This change introduces a new configuration parameter - 'hysteresis':
uplink-power-target <-110-0> hysteresis <1-25>
that together with the 'uplink-power-target' defines a range:
[target - hysteresis .. target + hysteresis]
in which the MS power loop would not trigger any power changes.
This feature is now *enabled* by default, so given that:
- default 'uplink-power-target' is -75 dBm, and
- default 'hysteresis' is 3 dBm,
the default target Uplink power range is: -78 dBm ... -72 dBm.
Change-Id: Iacedbd4d69d3d74e2499af5622a07a8af0423da0
Related: SYS#4916