* Don't copy features for osmo-bts and nanobts initially, wait until
BTS reported its features
* Checks for BTS features in VTY cmds: pass if features are not known
(not yet reported by the BTS), fail if the feature is missing
* Once BTS reports its features, check relevant VTY config parts again
Related: SYS#5922, OS#5538
Change-Id: I7fca42a39a4bc98a6ea8b9cfab28c4bad3a6a0aa
The value in bts->si_common.chan_desc may get out of sync with the
actual value in net->T_defs (e.g. after changing it via the VTY),
so we need to sync it in generate_si3().
Note that synchronizing the values in cfg_net_per_loc_upd_cmd is
a bad idea, because the value of T3212 may also be changed using
generic timer management commands.
Change-Id: Iee291623c2825505eeb5175adcedadfe35375b9e
Related: SYS#5888
* 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
From the nature of the lchan_activate_info.tsc_set and .tsc, it is easy
to forget to set tsc_set,tsc = -1 to use default TSC Set and TSC values.
Handover code is one such instance that forgets to set -1.
Change the semantics of tsc_set and tsc so that this kind of error can
not happen again as easily: use a separate bool to flag whether to use
the default config or explicit values.
Implicitly fix the lchan_activate_infos "launched" in handover_fsm.c as
well as abis_rsl_chan_rqd_queue_poll().
Related: OS#5244 SYS#4895
Related: I1ed6f068c85b01e5a2d7b5f2651498a1521f89af (osmo-ttcn3-hacks)
Change-Id: Iae20df4387c3d75752301bd5daeeea7508966393
Since the libosmo-mgcp-client now supports MGW pooling, lets use this
feature in osmo-bsc. Large RAN installations may benefit from
distributing the RTP voice stream load on multiple media gateways.
Depends: osmo-mgw Icaaba0e470e916eefddfee750b83f5f65291a6b0
Change-Id: I8f33ab2cea04b545c403a6fe479aa963a0fc0d0d
Related: SYS#5091
TSC was initially set to -1 (to be picked by callee), but erased when
using designated initializers later on in the function, hence TSC being
set to 0. As a result, TSC 0 would be requested to the BTS, which may
have configured a different BSIC containing BCC!=0.
Related: OS#5219
Change-Id: I26813561ee9e7783a4004f32225f19296bd6319c
Allow resetting the BSSMAP link from VTY, for BSC_Tests.ttcn.
In the field, detecting that an MSC is lost is done by getting three
connection failures in a row. For the BSC_Tests, it is easier to just
provide a VTY command to reset an MSC's link status.
I want to add tests that verify the stat items reflecting the MSC
connection status. To be able to run a test expecting fewer connected
MSC after a test that launched more MSCs requires the links to be reset.
Related: SYS#5542
Related: Ice3056dc46c94f9399f8379db7aeb7193782f2f2 (osmo-ttcn3-hacks)
Change-Id: I1975941b790d2b30d0904d41e456220cba26ecff
In the command
bts <0-255> trx <0-255> timeslot <0-7> sub-slot <0-7> deactivate fr
the final argument indicating the channel type does not make sense and
is not actually used. Define a separate vty command for 'deactivate', so
that it doesn't require arguments only used for 'activate'.
Change-Id: Ibdeca3b1d75b9f6092f566544e9d5f4da67fffce
It's an easy helper, but it helps in standarizing and finding similar
places in code.
Morevoer, it will be used in follow-up commit where we first use
lchan_avail_by_type and finally we select it in a later stage.
Change-Id: I025a40962a5e5d40543b297a0760e47618fb525c
The VTY defun already indicates BSC_VTY_ATTR_RESTART_ABIS_OML_LINK
correctly, but so far we would immediately start using the new values
internally, and wrongly interpret interference levels. Fix that.
Have bts->interf_meas_params twice: interf_meas_params_cfg for the VTY
configured values, and interf_meas_params_used for the values that the
BTS actually knows about, after they were sent via OML.
In a running BSC, when changing the interference level boundaries on the
telnet VTY, the BTS is not immediately told about the change. That would
require a BTS restart. Hence store the cfg values separately in
interf_meas_params_cfg. For comparing/printing interference levels in a
running BTS, only employ the values that were actually sent via OML and
placed in interf_meas_params_used.
Related: SYS#5313
Change-Id: Iad8cf4151ff7f86dc0549158ed5d91d788d40b1f
The rach control parameter value that controls the usage of
call-reestablishment is currently hardcoded. Lets add a VTY option for
this so that we are able to configure call-reestablishment
Change-Id: Ia18c1dde4c001cb4d423f694f8bc146adfd77daf
Related: SYS#5130
Store the config option whether the channel allocator should try to
avoid lchans with higher interference levels reported in RES IND.
The actual implementation of avoiding interference follows in
I844494092193811dfd9fa4d52983cbaed0fc9248
Related: SYS#5313
Change-Id: I8b62d0b41ad9e908b27713db9219e3dbc1ebaab7
They will gain support to be activated as SDCCH/8 soon too.
Related: OS#5309
Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68
Change-Id: Id5b89fe589a52ff88486435ac43809edb4b80f98
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, starting from version 13.0.0 (2015-11) 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.
Introduce a VTY command to turn on and off the BCCH carrier power
reduction operation. Also introduce a CTRL command. On the
A-bis/RSL, abuse the BS POWER CONTROL message by setting
the Channel Number IE to 0x80 (RSL_CHAN_BCCH).
Currently, only osmo-bts-trx is supported. A value greater than
zero makes it reduce the power on *inactive* timeslots of the
BCCH carrier. Sending zero disables the BCCH power reduction
mode completely.
For more details, see 3GPP TS 45.008, section 7.1, and 3GPP TR 45.926.
Change-Id: I047fce33d4d3e4c569dd006ba17858467a2f4783
Related: SYS#4919
The constant is called OSMO_NRI_BITLEN_DEFAULT, NRI_BITLEN_DEFAULT does
not exist and got rendered as "NRI_BITLEN_DEFAULT" in the vty doc.
Add missing vty test for 'nri bitlen'.
Change-Id: I8af840a4589f47eaca6bf10e37e0859f9ae53dfa
follow-up to
0256c89187
Icac06ed554fd61bf7c4bfb1d5c3739a01f2915a4
Previous patch increased the range, but let's also allow one more
argument so that the A5 mask can be fully enabled.
Change-Id: Ie8cd753e4425d7d51397e4dddc24108fa0392de4
Add A5/4 to the internal mask of allowed algorithms.
(Not actually working yet, A5/4 implementation follows in other
patches.)
Related: SYS#5324
Change-Id: Icac06ed554fd61bf7c4bfb1d5c3739a01f2915a4
Make sure that the target lchan has been initialized before attempting
to reassign.
I ran into this in the VAMOS tests, forgetting to set the BTS_FEAT_VAMOS
in osmo-bts-omldummy: the vty command from ttcn attempts to reassign to
a non-initialized lchan, and aborts osmo-bsc.
Change-Id: Ia77a3312dde0e4b8df9ad2f33339266bae06439d
Add VTY command to trigger an intra-cell re-assignment, also allowing to
re-assign to a secondary VAMOS lchan.
Related: SYS#5315 OS#4940
Change-Id: If006f5caaf83b07675f57e5665cfa79328da55e6
The RSL BS Power IE in measurement reports is encoded as dB / 2.
Instead of using this coding all over the code, converting to dB and
often printing confusing values in logging etc, store as plain dB.
The conversions should be at the points where a "weird" format is
defined: the RSL encoding needs divided-by-two, so apply it there. The
meas_vis is (now unfortunately) defined as div-two, and so on. But
internally we now just store the plain dB value and calculate with it
without duplicating the wire decoding step everywhere.
Rename to bs_power_db to clarify the unit of the stored value.
Change-Id: I229db1d6bcf532af95aff56b2ad18b5ed9d81616
According to 3GPP TS 45.008, the BSS shall monitor the levels of
interference on its IDLE traffic channels. The actual measurements
are performed in the BTS and then reported to the BSC over the
A-bis/RSL link(s) in RF RESource INDication messages.
3GPP TS 45.008 defines the following measurement parameters:
* Intave: Interference Averaging period (see table A.1),
* Interference level Boundaries (see table A.1).
Both parameters are sent to the BTS over the A-bis/OML, and can
now be configured via the VTY interface. Only those BTS models
which 'speak' the OML protocol defined in 3GPP TS 52.021 will
actually get the configured parameters, others will keep using
the hard-coded parameters.
Change-Id: I99ebf57aac1f3ca7e0497c3b4f6b0738c6ed7e47
Related: SYS#5313, OS#1866
Without this guard, a command like this can crash osmo-bsc:
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 activate fr
when timeslot 0 is configured as non-combined 'CCCH'.
Change-Id: I0197a6a2595ff9dade58e37383d44d2df3b03288
CLoses: OS#5170
So far we have a couple of macros iterating a specific number of lchans,
depending on dynamic timeslot state etc. With addition of VAMOS lchans,
this would become more complex and bloated.
Instead of separate iteration macros for each situation, only have one
that takes a number of lchans as argument. That allows to more clearly
pick the number of lchans, especially for non-trivial VAMOS scenarios.
Related: SYS#5315 OS#4940
Change-Id: Ib2c6baf73a81ba371143ba5adc912aef6f79238d
So far the number of usable lchans is determined on-the-fly by the
physical channel config. With VAMOS, this becomes more complex, namely
determining whether the BTS is vamos capable.
Instead of calling a function to determine the number of lchans for
every use, rather place the number of valid lchans in int members of the
timeslot struct, and initialize those during timeslot setup.
Actual use of these new fields will follow in a subsequent patch, which
introduces the ts_for_n_lchans() macro to replace current lchan
iteration macros.
Related: SYS#5315 OS#4940
Change-Id: I08027d79db71a23e874b729c4e6173b0f269ee4f
This is particularly interesting for VAMOS multiplexes, but also gives
more prominence to this rather central aspect of GSM RF.
Related: SYS#5315 OS#4940
Change-Id: I7842ff89bece6d88387dae056e350529bae6fc38
Activating / modifying to a VAMOS mode will require picking specific TSC
Set / TSC. It is a bad idea to pick the TSC in each message encoding
function, rather make this choice centrally.
So far we pick the training sequence code to use based on the timeslot
configuration, and this TSC is determined only upon encoding the RSL
messages.
Instead, pick the TSC to use upon the initial lchan activation /
modification request; store this in the request structs and pass through
the activation / modification code paths.
For VAMOS modes, we also need to pick a TSC Set. Do so also upon activ /
modif request. Note that the TSC Set is not yet applied in this patch,
it will be applied in upcoming VAMOS patches.
The activ / modif request may pass -1 for tsc_set and/or tsc to indicate
no specific choice of TSC Set and TSC, resulting in the same behavior as
before this patch.
For example, lchan->activate.info.tsc* may be passed as -1. The exact
choice for tsc_set and tsc is then stored in lchan->activate.tsc*, i.e.
one level up (the .info sub-struct is considered as immutable input
args). The lchan->activate.tsc* are the values actually encoded in RSL
messages. After the ACK, the lchan->activate.tsc* is stored in
lchan->tsc* to indicate the TSC actually in use. Same for modif.
Note that in 3GPP TS 45.002, the TSC Set are numbered 1 to 4, while the
TSC are numbered 0 to 7. On the wire, though, TSC Set is sent as 0 to 3
value. This is a weird discrepancy, odd choice made by the spec authors.
For conformance with the spec wording, I decided to pass the TSC Set
number as a 1-4 ranged value, and only convert it to the 0-3 on-the-wire
format upon message encoding. So log messages and VTY output will
indicate the first TSC Set as "1", but the first TSC as "0", as defined
in 3GPP TS 45.002, even if that is somewhat weird.
Related: SYS#5315 OS#4940
Change-Id: Ic665125255d7354f5499d10dda1dd866ab243d24
Prepare for VAMOS, where there will be secondary "shadow" lchans serving
secondary MS on the same timeslots. For those, RSL messages will need to
reflect a different stream ID aka TEI, via an rsl_link_vamos.
Make sure that every code path that sends an RSL message for a specific
lchan selects the RSL link via the new function rsl_chan_link(). When
VAMOS is implemented, this function can select the proper RSL stream.
Rename gsm_bts_trx.rsl_link to rsl_link_primary. This makes sure I'm not
missing any uses of the RSL link, and clarifies the code.
Related: SYS#5315 OS#4940
Change-Id: Ifbf16bb296e91f151d19e15e39f5c953ad77ff17
I noticed during testing that an lchan used as TCH/F in fact still had
its channel mode set to Signalling -- because on Assignment, the Speech
mode used to be placed in the *previous* lchan and the new lchan was
never updated after the Activ ACK. This is unbearable confusion which I
complained about numerous times, so far mostly for cosmetic reasons. But
implementing re-assignment properly actually requires this to be cleaned
up.
Keep all volatile chan mode settings in lchan->activate.* or
lchan->modify.*, and only update lchan->* members when an ACK has been
received for those settings. So a failed request keeps a sane state.
Make sure that those settings are in fact updated in the proper lchan,
upon an ACK, so that subsequent re-assignment or mode-modify know the
accurate lchan state.
Related are upcoming patches that sort out the AMR multirate
configuration in a similar fashion, see
Iebac2dc26412d877e5364f90d6f2ed7a7952351e
Ia7519d2fa9e7f0b61b222d27d077bde4660c40b9
Ie57f9d0e3912632903d9740291225bfd1634ed47.
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Ie0da36124d73efc28a8809b63d7c96e2167fc412
The amr_mode parameter may be passed as -1 and is directly used as an
array index in amr_modes[]. The AMR related switch case properly checks
against a -1 index, but the EFR does not -- and should not use s15_s0.
Change-Id: I9bae5b4fb8ab8c2002fe785e130dc9faeeda892c
Soon, there will also be enums with ASSIGNMENT_FOR_* and MODIFY_FOR_*
naming. Add the ACTIVATE_ prefix to the existing enum to clarify.
Change-Id: I12190d4d154a1da6a9ebc9a755ccc2fe382ff188
A recent commit removed the references to the per-TRX description, but
wrongly removed the per-BTS in this place too.
Fixes: defb5b1200
Change-Id: Iacaa2a25633a8706bfde9e0c196fee3e5bff1639
This patch caused major breakage in my setup, with BSC printing at
startup: "(bts=0,trx=0) Failed to generate System Information".
And bts-trx printing all the time:
"sysinfo.c:162 PH-RTS-IND: Unable to determine actual BS_AG_BLKS_RES
value as SI3 is not available yet, fallback to 1"
This reverts commit c1a5310a3e.
Change-Id: I5da365c93aedc6668a77b82ee9b68cbec64967e3
The effects of the neighbor configuration depend on the LAC, Cell
Identity, ARFCN, BSIC configuration of neighbor cells. Make sure that
the neighbor ARFCN list in the System Information is updated.
This may seem rather aggressive: updating the SI of all BTS if only one
config item changed. But indeed even modifying one config item of one
BTS may cause a change in the neighbor relations that many other BTS may
have to the changed BTS. For example, if many BTS configure a
'neighbor lac-ci 42 23', and this cell's config changes to LAC 43, all
of those other BTS need to update their neighbor ARFCNs.
Also update the system information even before the BTS are connected and
started up. The main benefit here is that the VTY 'show bts N' command
then already lists the correct neighbor ARFCNs.
In gsm_bts_trx_set_system_infos(), make sure that the updated SI is only
sent to TRXes that are actually usable, otherwise abis_rsl_sendmsg()
spams the log with complaints that a message's dst == NULL. Still return
an error rc in case a TRX is not connected, so that the CTRL command
bts.N.send-new-system-informations accurately returns whether SI were
actually sent to all TRXes.
The desire to have the ARFCNs listed in the VTY before starting up BTSes
came during analysis for Ifb54d9a91e9bca032c721f12c873c6216733e7b1,
which fixes a bug that is now much easier to verify being fixed.
Change-Id: I2222e029fc225152e124ed1e8887f1ffd4a107ef
From 3GPP TS 48.008 sec 3.1.30 "Common ID":
"""
If the SCCP connection is established due to CSFB from E-UTRAN and the MSC supports
return to the last used PLMN after CS fallback, then it should send the COMMON ID message
to the BSS including the Last used E-UTRAN PLMN ID information element if available at
the MSC immediately following the successful SCCP connection setup.
"""
Furthermore, 3GPP TS 48.008 version 16.0.0 Release 16 "3.2.1.21 CLEAR COMMAND",
for field CSFB Indication, states:
"""
NOTE: This information element doesn't serve any useful purpose. MSCs should not send the
information element unless it is required by the recipients (due to the need to interwork
with older versions of the protocol). It is expected that in future versions of the present
document, this information element will be deleted from this message.
"""
Hence, build up the EUTRAN neighbor list based on whether we received
the Last E-UTRAN PLMN ID IE during Common Id. In the future, we should
probably filter the list while populating it based on the received IE.
This change will also allow reusing same mechanism for SRVCC
EUTRAN->GERAN support, where te Last E-UTRAN PLMN ID IE can be found
inside "Old BSS to New BSS information" IE in msg HANDOVER REQUEST.
Related: SYS#5337
Change-Id: I5d290ac55eca5adde1c33396422f4c10b83c03d5
Oliver Smith
Pau Espin
Vadim Yanitskiy
Keith Whyte
Neels Hofmeyr
Philipp Maier
Neels Hofmeyr
Eric Wild