Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: I35ae930b59c48892e5ad9a2826e05d6c5d415abc
Fixes: OS#4865
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: Ic3b7c223046a80b51f0bd70ef1b15e12e6487ad0
Fixes: OS#4865
The signal handler function was coded to expect SIGABRT but the signal
handler itself was never enabled for this signal.
Change-Id: Id95d64efe8765fcf19eb09cd3db7895166c6adab
The binary is called 'osmo-bts-lc15', while the containing folder
is named 'osmo-bts-litecell15'. This inconsistency complicates
automatic generation of the XML VTY reference - fix it.
Change-Id: I55c073fbd01aee42871101401d76d87e7c91832e
Related: SYS#4937, OS#3036
Otherwise it ends up in the generated XML VTY reference:
$ head doc/manuals/vty/bts_trx_vty_reference.xml
((*))
|
/ \ OsmoBTS
<vtydoc xmlns='urn:osmocom:xml:libosmocore:vty:doc:1.0'>
<node id='_common_cmds_'>
<name>Common Commands</name>
Also, take a chance to move it below handle_options(), so it
will only be printed if all arguments are parsed successfully.
Change-Id: I5c35f36fdd2a8a80bd501b996f0b161c388d3510
Related: SYS#4937, OS#3036
Now bts_model_vty_init() must be called only once, otherwise the
process would crash when bts_model_init() is called from main().
Change-Id: I262c39896b5db86c54ad9aa7042c7ca6657815d9
Related: SYS#4937, OS#3036
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
The variables num_meas_sub_expect - num_meas_sub must not be subtracted
without prior checking. Depending on the input (which might be
errornous), num_meas_sub might be greater then num_meas_sub_expect. This
eventually leads into odd behavior, which can be difficult to debug.
Change-Id: I381cc637d1c125f279ccf88db114609946fe24fe
Related: OS#4799
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
The logic in measurement.c checks the amount of collected measurement
values. This is done for the total amount of measurements and the amount
of SUB blocks measurements.
The functions that return the expected number of measurement values
currently do not take into account that the mode of a TCH/F or TCH/H has
an effect on the number of expected SUB blocks. (In signalling channels
all blocks count as SUB). Also a TCH/H in signalling mode generates only
half the amount of measurements because the blocks in signalling mode
are sepreded over 6 bursts instead of 4. This also needs to be taken
into account.
Change-Id: I01c7b6cc908c647263ab88f6b6281c4732f88779
Related: OS#4799
SUB frames exist only in voice (or CSD) channels. When a TCH/F is in
signalling mode, all blocks must be counted as SUB blocks. (for TCH/H
the current implementation is correct.)
Change-Id: I04be21200afa1d03afa0d7e476c66fa79cf42249
Related: OS#4799
When the FACCH is generated (while in SPEECH mode), there is also a
fake speech indication handed up to l1sap.c. We must make sure that only
one of the two indications carry a measurement value, so lets invalidate
the measurement values (RSSI in particular) for the generated TCH
indication.
Change-Id: Ie3f2e620ba2a2ab2fecdbae627ef01c6128fce0b
Related: OS#4799
Otherwise, some objects are announced at startup of osmo-bts towards BSC
during State Changed Report as being "NULL".
According to TS 12.21:
"NULL(Operat. state not supported) FF"
Which doesn't make much sense in startup situation. They are in known
state Disabled until they are OPSTARTed.
Change-Id: I5ba6756ea069d0f995f453ee4b27e6839c914eb1
Previous commit 7810a91733 forgot to
introduce this line, though it was planned to be there.
Most of the time it worked fine anyway because the RSL link is not the last
event bb_transc waits for before switching to Enabled, so later events
would trigger inside the bb_transc fsm a recheck (polling) which wuld
allow to advance to Enabled state.
However, in the situation where RSL link UP is the last event to happen,
no more inside-FSM checks are triggered and hence BB Transeiver never
goes to Enabled state, and as a result no event is triggered towards
each RadioChannel which in turn don't go to Enabled state.
Fixes: 7810a91733
Change-Id: I8c777b946e7abcb4b607ec4d136c981a0716b120
All the Operative State logic to manage a RadioCarrier//BBTransc NM objects is
centralized in these FSM, where other parts of the code simply send
events to it.
This allows keeping state consistent and offloading logic from each bts
backend, since they are only required to submit events now.
The idea in the long run is to also replace other NM objects with
similar FSMs.
This improved logic fixes bug where PHY + RSL link became available before
OPSTART and hence op state changed to Enabled before receiving any OPSTART message.
Change-Id: Ifb249a821c4270918699b6375a72b3a618e8cfbe
This fixes old behavior mimicing broken behavior in nanoBTS (according to TS 12.21)
where BTS Site Mgr NM object was announced as Enabled despite no OPSTART
was sent by the BSC.
With this new FSM, BTS SiteManager will be announced as Disabled Offline
during OML startup conversation, instead of Enabled.
The new osmo-bsc OML management FSMs use this change in behavior to find
out whether it should use the old broken management states (without
Offline state, as per nanoBTS) or use the new state transitions (which
allow fixing several race conditions).
Change-Id: Iab2d17c45c9642860cd2d5d523c1baae24502243
This fix allows osmo-bts to play fine with newer osmo-bsc NM OML FSMs,
which expectes for non-nanoBTS types to follow TS 12.21 guidelines.
Until now, BSC simply waited to received State Event Change Dependency
for each TS and then sent all required commands (Set Chan Attr, Adm
Unlock and Opstart). In newer osmo-bsc FSMs, Opstart is only sent when
in Offline state, so we need to transit to that state. For the above
mentioned reason, since we pass through the Dependency state anyway
after this patch, older osmo-bscs will work correctly too.
Change-Id: Id9e61f8d773e6e6170c68b5b836d276c747d8d69
We originally wanted to intrdouce an OML router which would permit
external proceses to implement certain OML MOs. However, that code
was never completed, and all the existing implementation (in three
copies) does is to create a unix domain socket and discard what
is received there.
Change-Id: I7fcbbd5d6b64ddc666ca836dc49abb430be0d5cb
Sometimes the following messages appear in the logging output:
TCH/F: Prim has wrong chan_nr=0xc5 link_id=00, expecting chan_nr=0x0d link_id=00
TCH/F: Prim has wrong chan_nr=0xc2 link_id=00, expecting chan_nr=0x0a link_id=00
when a dynamic timeslot is switched from PDCH to TCH/F (or to TCH/H).
This means that the transmit queue of a timeslot still contains
PDCH frames, that were not properly cleaned on PDCH deactivation.
Let's finally do this in trx_sched_set_lchan().
Change-Id: Ic6560c660c658f36b84e7efa2f1d93e3a870962b
Related: SYS#5108, OS#4804
Trying to (de)activate logical channels that are already (de)activated
is not something that we normally expect. Treat this as error.
Change-Id: I6256280cae35b2b4d7a8ba4b3913ca69cde22611
In this function we already do check that a given timeslot is not
a PDCH slot, so checking if TRX_CHAN_FLAG_PDCH is redundant.
Change-Id: Ie73bdaf0f6bc76ed8d2e95d1fb995333bf617e7e
Both TRXC_PDTCH or TRXC_PTCCH are described in 'trx_chan_desc'
(defined as 'const'), and both have TRX_CHAN_FLAG_PDCH set. So
indeed, this condition can never be true.
Change-Id: Ie185a939b48eb859ac1c8ffa0a4f667fda0cb82b
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
It makes no sense to do further calculations if the actual Uplink
signal strength equals the target value configured in the VTY.
Change-Id: Id99c7013a722403e773df8367b1a9d7a856e639b
Related: SYS#4916
Sending INFO.ind unconditionally in pcu_if_signal_cb() provokes
a lot of warnings during OML bootstrapping / termination:
DPCU INFO pcu_sock.c:247 Sending info
DPCU INFO pcu_sock.c:262 BTS is up
DPCU INFO pcu_sock.c:205 (bts=0,trx=0) unavailable for PCU (op=Disabled adm=Unlocked)
DPCU INFO pcu_sock.c:205 (bts=0,trx=1) unavailable for PCU (op=Disabled adm=Unlocked)
Do not call pcu_tx_info_ind() if the PCU is not connected.
Change-Id: If8bc8bec5ad808be8d40e91278a4a4fde84920b0
So far the Uplink power control loop did not filter the Uplink RSSI
measurements (reported by the BTS) at all. The lack of filtering
makes our implementation too quick on the trigger, so in the real
deployments there will be unneeded Tx power oscillations.
In order to reduce this effect, let's implement a very simple EWMA
(also known as Single Pole IIR) filtering that is defined as follows:
Avg[n] = a * Pwr[n] + (1 - a) * Avg[n - 1]
where parameter 'a' determines how much weight of the latest UL RSSI
measurement result 'Pwr[n]' carries vs the weight of the average
'Avg[n - 1]'. The value of 'a' is usually a float in range 0 .. 1, so:
- value 0.5 gives equal weight to both 'Pwr[n]' and 'Avg[n - 1]';
- value 1.0 means no filtering at all (pass through);
- value 0.0 makes no sense.
This formula was further optimized with the use of '+=' operator.
The floating point math was also eliminated by scaling everything
up (by 100). For more details, see:
https://en.wikipedia.org/wiki/Moving_averagehttps://en.wikipedia.org/wiki/Low-pass_filter#Simple_infinite_impulse_response_filterhttps://tomroelandts.com/articles/low-pass-single-pole-iir-filter
The EWMA filtering is now *enabled by default*, but can be disabled
or (re-)configured over the VTY at any time:
! Completely disable filtering
no uplink-power-filtering
! Enable EWMA smoothing with the given parameters
uplink-power-filtering algo ewma beta <1-99>
Note that the VTY command expects 'beta' instead of 'alpha':
alpha = (100 - beta)
and the value must be in %. This is done for simplicity:
1% means lowest smoothing,
99% means highest smoothing.
Let's say we have EWMA filtering enabled with alpha = 0.4, and get
-98 dBm on the input, while the last output value was -60 dBm.
The new output would be:
Avg[n] = 0.4 * Pwr[n] + 0.6 * Avg[n - 1]
Avg[n] = (0.4 * -98) + (0.6 * -60)
Avg[n] = -75.2 => around -75
Of course, this is not a silver bullet, but better than nothing.
Change-Id: Ib6dcadbf14ef59696c6a546bd323bda92d399f17
Related: SYS#4916
If no PCU is connected, we cannot be providing GPRS services,
and hence should not transmit SI13.
Change-Id: I54320cf8073a33ed9e35b365921df178005e8967
Closes: OS#3075
The commandline option --vty-ref-xml is needed to enable automatic
generation of the VTY reference manual.
Change-Id: I895db6086748a5916874e779963caed589050109
Related: SYS#4937, OS#1601
The PCUIF is a 'brilliant' protocol: some fields are expected to
be in the network byte order, some in the host order. The NSVC
remote address and local/remote ports is a good example:
- byte order of the address must be the network order, and
- byte order of the ports must be the host order.
Change-Id: I383cab0b58b62734090023298da8c5a341c670d5
Fixes: I310699fabbfec4255f0474f31717f215c1201eca
Related: SYS#4915
This is another regresion introduced by [1]. Both local and remote
port numbers recived in the network order, and must be stored as-is.
Change-Id: I3c21a2c27dcbf6de728ce2c7ccbae9e2f517c450
Fixes: I310699fabbfec4255f0474f31717f215c1201eca
Related: SYS#4915
Using gsm_bts_trx_num() involves redundant iterations over the
list of transceivers - we definitely don't want them.
Change-Id: I4bd40ffcc1e925412a21b0a934bbfdeddbc6ad1f
in function rx_tchh_fn() the variable meas_avg is not initalized. This
is not always a problem, since most of the time trx_sched_meas_avg() is
populating the variable properly. In cases where a FACCH is transmitted
(chan_state->ul_ongoing_facch = true) the variable is left unpopulated.
In order to have at least stable values for those cases, initalize the
variable with zeros for the ongoing facch phase.
Change-Id: I5c3c1c41d22f9edaaf6bd4478dd04f090dca12a9
Fixes: CID#214480
The address_family is 8 bit and have a padding byte afterwards.
By using osmo_load16be it's encoding it wrong and result in an
empty/invalid NSVC configuration.
Change-Id: Ie070b5745124d48e74a6dedd8903b74bfb3ce9d2
Since I310699fabbfec4255f0474f31717f215c1201eca the BTS
can decode NM_ATT_OSMO_NS_LINK_CFG. This OML attribute will be
only used if the OML feature IPV6_NSVC is present.
Change-Id: I9910f2afb3ab94167938b0fd356f2f0a8c382130
With PCU interface version 10 it supports IPv6 NSVC. The new OML IE
NM_ATT_OSMO_NS_LINK_CFG allows to configure IPv6 NSVC.
Change-Id: I310699fabbfec4255f0474f31717f215c1201eca
There are some situations where it is useful to be able to change the
Radio Link Timeout at runtime, without restarting the BTS.
This adds a new (hidden) command for this:
"bts <0-255> radio-link-timeout (oml|infinite|<4-64>)"
Change-Id: I64674a432cf7751b16d5d0b52f66766fa6e37028
This regression was introduced in 2ff4592ffc.
There is simply no PHY in case of osmo-bts-omldummy.
Change-Id: I864ac3f15e06462d6ce808b3f2188c5c39a5aad2
Fixes: Ic00df9e7278d42bc10c1e1a1c0edde7e13199299
Make sure that we pick the correct UL measurements from the
history when we deal with AMR SID frames (SUB frames).
Change-Id: I902bb47d68742d2589156f61099b67a0edbaf40b
Related: OS#2978
Currently the UL measurements (RSSI, ToA256, C/I) of the burst that
concludes a block are passed up to the higher layers. This means
that the measurement values of the other bursts are skipped.
Let's keep record of all UL measurements and average the values
before we pass them up to the higher layers. Use a simple ring
buffer to store the measurement history (up to 8 unique entries
for now). Remove *_num/*_sum variables from l1sched_chan_state.
Change-Id: I2b02b51fea5664f161382a4ddc63dbf14ffc9ac5
Related: OS#3032, OS#2978
Introduce a address_type in the NSVC configuration pass the given
protocol. The remote_ip is network byte order, the default
encoding for in_addr and in6_addr.
Change-Id: I6d60277eb5b8d938d9f38114c933d58ee1b884c9
Related: Iae854875a45dbc29cd46a267ccaf60f1f2ac2973
Related: SYS#4915
Otherwise they may be set to ENABLED before CHAN SET ATTR and OPSTART
are sent, and oml_rx_opstart will blindly OPSTART ack (because they are
already enabled) and avoid configuring the timeslots.
That can happen if phy_link & rsl link get ready before receiving all
the OML CHAN SET ATTR and OPSTART commands on all RadioChannels.
Fixes: OS#4757
Change-Id: I50722c4e82faae32371817c3878bb41bfd0175ba
MA (Mobile Allocation) is actually a bit-mask indicating those ARFCNs
of the Cell Allocation, which must be used as the hopping sequence.
What we store in struct gsm_bts_trx_ts is the actual list of hopping
channels, so let's name it properly and eliminate possible confusion.
Change-Id: I677d66e428fa0fe119ebc37bc2a4e6cc05c251c4
If for whatever reason a TS stops being announced as available to the
PCU (for instance because the TRX became administratively locked), the
PCU will send a Release for that channel, but in that case we don't want
to send an RSL RF Channel Release ACK because it was not initiated by
related command from BSC.
In the case of a simple PDCH timeslot (no dynamic), the behavior is
already there but we don't print an error log since it's expected.
In the case of a dyn osmo TS, we only need to respond to RF Channel
Release when PDCH is deactivated here, but in other cases we don't need
to submit anything to BSC.
Change-Id: I8ae9ee450763a0e14edf950e38b64a32df14f44f
Avoid announcing to PCU as available a dyn TS not yet fully
configured in the phy. Otherwise when we receive the Chan Activation
over the PCU sock while pchan_is still is not PDCH, and we fail to fully
activate the channel at that time.
See previous commit description for more information on the issue.
We still want to check for pchan_want because we actually want to stop
announcing the TS when it is in progress of being changed to TCH. This
configuration change is continued/finished once we receive the resulting
Release from PCU.
Change-Id: I8e2b170c1f94e7dfe2576a1fc899bf9c8a826a44
Something is wrong currently with dynamic TS and PDCH activation.
Apparently there's a race condition between activation in BTS lower
layers (example in TRXC) and against PCU.
Currently, when a GSM_PCHAN_TCH_F_TCH_H_PDCH is configured, we set
ts->dyn.pchan_want = GSM_PCHAN_PDCH and submit the async activation
through lower layers (CMD SETSLOT), and once the lower layer acks it we
set ts->dyn.pchan_is = pchan_want (when receiving RSP SETSLOT). However,
we seem to be advertising available TS to PCU based on pchan_want,
instead of pchan_is, which means we advertise channels not yet fully
configured. As a result, we may receive a Channel Act coming from PCU
for a given TS for which we didn't receive confirmation from upper
layers, meaning pchan_is is still GSM_PCHAN_NONE. This is by no means
expected in following code, so let's avoid going further over it.
Actual issue will be fixed in follow-up patch.
Change-Id: I9edb5b8a14ffaed3e24c10c2c7a3f618e05f3a01
It was spotted that sometimes chan_nr BCCH was printed for a TS
containing configured as GSM_PCHAN_TCH_F_TCH_H_PDCH, which was totally
confusing. Indeed the problem is somewhere else, but let's log an error
and return 0 in this case, which will be converted to "UNKNOWN" string
later on.
Change-Id: Ic455af39c668481a13d579f33ac09033fd5c4009
This reverts commit df93a448b7.
It was to early because the frequency hopping wasn't ready to be merged.
Change-Id: I6e67f4cd9828afa53ed4e783b83b039ee6a1d570
Introduce a address_type in the NSVC configuration pass the given
protocol.
The remote_ip is network byte order, the default encoding for in_addr and in6_addr.
Change-Id: I4067b1af041b2cdad60d6fb16c9caee98bc218dd
Operative state is mainly maintained based on 2 requirements:
* phy_link being in CONNECTED state
* RSL connection being up and ready
However, state change report triggered over OMl towards BSC was only
done upon the first event of the two. That means that if for whatever
reason the RSL connection was established AFTER the phy_link became
CONNECTED (ie receiving RSP POWERON in osmo-bts-trx), then the status
towards the BSC would not be updated and hence the BSC would still see
the Radio Carrier object as DISABLED.
The trx_set_available() function is renamed to trx_operability_update()
to keep the logic conditions in one place, and different events
triggering a change in state simply call the function and let it handle
the new state.
Related: SYS#5063
Change-Id: Ic00df9e7278d42bc10c1e1a1c0edde7e13199299
In general, it is always set to 1 (Locked) in
st_open_poweroff_on_enter() right after initial POWEROFF, and once the
BSC unlocks it (based on VTY cfg "rf_locked (0|1)") by sending an OML
message, the bts_model_chg_adm_state() call will update it sending
RFMUTE.
This basically fixes the case where osmo-bsc.cfg is configured with
"rf_locked 1" to start with a TRX locked until manually unlocked.
Related: SYS#4920
Change-Id: I96b64cdc901d6f216df628d7be57a67af4a21e25
Since commit 221ee92551,
bts_model_trx_deact_rf() was being called when RF locking the TRX, which
was implemented by resetting the scheduler. This proved to be a messy
and wrong way to emulate disabling RF, since it modifies tate on lots of
structures from which it is later difficult to recover from, causing
bugs and issues like:
82a35a1dbfbe15a12c87eef420d1cahttps://osmocom.org/issues/4694https://osmocom.org/issues/4695https://osmocom.org/issues/4696https://osmocom.org/issues/4697
So for all these reasons, it is believed a good solution to avoid
resetting the scheduler and simply ask lower layers (osmo-trx) to take
care of disabling RF TX/RX on a given TRX. For TRX implementations not
supporting the newly added RFMUTE command, ramping down to -10dBm still
provides for a way to emulate RF locking. In any case, none of this was
supported until recently so it's not like we are breaking some feature
here.
Related: SYS#4920
Change-Id: I1423ddb390ef327ec7d4a27de2ac5dca663773a5
It was reported that both osmo-bsc and osmo-bts-trx may end up
running in a half-broken state, when everything looks good and
the UEs can see the network, but all channel requests get
rejected due to "trx not usable" error:
lchan_select.c:173 (bts=0) lchan_select_by_type(SDCCH)
lchan_select.c:48 looking for lchan CCCH+SDCCH4: (bts=0,trx=0) trx not usable
lchan_select.c:48 looking for lchan SDCCH8: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select SDCCH channel
lchan_select.c:173 (bts=0) lchan_select_by_type(TCH_H)
lchan_select.c:48 looking for lchan TCH/H: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select TCH_H channel
lchan_select.c:173 (bts=0) lchan_select_by_type(TCH_F)
lchan_select.c:48 looking for lchan TCH/F: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select TCH_F channel
As was then figured out, this happens because the Radio Carrier
MO (Managed Object) remains Disabled even after the BSC has
sent OPSTART and the BTS ACKed it:
oml.c:986 OC=RADIO-CARRIER(02) INST=(00,00,ff): Rx OPSTART
l1_if.c:614 Rx OPSTART for RADIO-CARRIER MO
l1_if.c:201 TRX_PROV(phy0-0)[0x1238c0]{OPEN_POWERON}:
Event TRX_PROV_EV_CFG_ENABLE not permitted
oml.c:144 OC=RADIO-CARRIER(02) INST=(00,00,ff): Tx Opstart Ack
It remains a mistery why the TRX_PROV FSM is already in state
OPEN_POWERON, while it's expected to be in state OPEN_POWEROFF,
but we definitely should not ACKnowledge the OPSTART if this
happens. Send a NACK instead with cause NM_NACK_CANT_PERFORM.
Change-Id: I8727460acbf850b84df67a9cbdc25b47dee1fadd
Related: SYS#5063
We already get quite informative message originated from oml.c:
OC=RADIO-CARRIER(02) INST=(00,00,ff): Rx OPSTART
Change-Id: I3d4a4473541327488d3393b1fa7c6391afb3728a
It's more convenient to use one command to enable/disable sending
of all kinds of UL/DL messages at once, rather than specifying
all of them individually.
Adjust config_write_bts_single(), so it would not print unknown
GSMTAP SAPI entries if gsmtap_sapi_mask is set to UINT32_MAX.
Change-Id: Icd7fce860ecdcf8ffa107bdfee7ec94ea9ea6cb2
Otherwise osmo-bts-omldummy would reject OML Set Channel Attributes
containing the hopping parameters. This change is needed for the
new BSC_Tests.TC_fh_params_* test cases.
Change-Id: I38692252baa7a9fc23078121db0a17557950e4d4
Related: SYS#4868, OS#4545
See previous commit adding the unit test about the error description and
expected behavior.
The wrong behavior appeared due to step_size_mdB being unsigned and the
whole addition at the left side of the comparison being turned too as
unsigned, hence a small negative value turning into a big positive
value, and tpp->p_total_cur_mdBm not being updated to speed up the power
ramping.
Change-Id: I36a34362ebc90226fd8e1e190f898c3718fd923a
osmotrx fn-advance (which is the clock_advance variable here) and
osmotrx rts-advance together make up the minimum delay the BTS can react
to a channel request, etc.
The default of 20 are around 92ms which is clearly too much. With
modern hardware and using SCHED_RR a lower value should not be an issue.
See OS#4487 for some related measurements on more CPU-limited devices like a
LimeNet-micro3.
Fixes: OS#4487
Fixes: SYS#4885
Related: SYS#4881
Change-Id: I7da3d0948f38e12342fb714b29f8edc5e9d0933d
We gain other features from libosmovty for free, like configuring
cpu-affinity of the only thread in the process.
Depends: libosmocore.git Change-Id If76a4bd2cc7b3c7adf5d84790a944d78be70e10a
Depends: osmo-gsm-masnuals.git Change-Id Icd75769ef630c3fa985fc5e2154d5521689cdd3c
Related: SYS#4986
Change-Id: Ice46e406b84fa11afcc7ba31e521e7677df73cf3
The idea behind the baseband frequency hopping is quite simple: we
have several RF carriers (transceivers) transmitting and receiving
on fixed frequencies (just like in a regular multi-trx setup), and
an additional burst routing layer between the schedulear and the
transceiver interface (TRXD over UDP).
Speaking in terms of the proposed implementation:
- on Downlink, dlfh_route_br() calculates the ARFCN corresponding
to the current TDMA frame number according to the hopping sequence
parametets, and picks the transceiver with matching ARFCN;
- on Uplink, ulfh_route_bi() iterates over the transceiver list of
of the BTS, calculating hopping ARFCNs for equivalent timeslots,
and picks the one with ARFCN matching the received burst.
In order to avoid frequent transceiver lookups on the Downlink path,
dlfh_route_br() maintains a "cache" in the timeslot state structure.
Unfortunately, this "cache" seems to be useless on the Uplink path,
so ulfh_route_bi() always needs to lookup the matching transceiver
for each burst received over the TRXD interface.
It may also happen that the scheduler will be unable to route an
Uplink or Downlink burst, e.g. due to inconsistent / incorrect
hopping sequence parameters received from the BSC, or in case
if a transceiver gets RF-locked by the BTS operator.
Such events are logged as "FATAL" and aditionally signalled by the
following osmo-bts-trx specific rate counters:
- trx_sched:dl_fh_no_carrier (Downlink), and
- trx_sched:ul_fh_no_carrier (Uplink).
Change-Id: I68f4ae09fd0789ad0d8f1c1e17e17dfc4de8e462
Related: SYS#4868, OS#4546
This change facilitates the upcoming freq. hopping implementation,
in particular scheduling of dummy bursts on C0 with hopping time-
slots. One problem is that we cannot know in advance, whether to
send a dummy burst on a given timeslot unless all transceivers are
processed. For example, trx#3 may want to send a normal burst on
ARFCN of trx#0 (C0), while we have already sent a dummy burst...
Another important aspect is that we shall not be sending dummy
bursts on transceivers other than C0. Scheduling dummy bursts
from _sched_dl_burst() in the context of a single hopping timeslot
of a single transceiver leaves trx_sched_fn() no way to know
whether it's a dummy burst or something else.
Let's solve both problems by moving dummy burst scheduling logic
from _sched_dl_burst() to trx_sched_fn(). Maintain C0 slot-mask
in the inner (per-trx) loop, so that we can fill missing bursts
with dummy bursts afterwards.
Change-Id: I8c3651c27d2991079e83b8abdb7e2c3f95b97a43
Related: SYS#4868, OS#4546
On receipt of either SIGTERM or SIGINT the shutdown FSM initiates
ramping down of the transmit power on Downlink. I noticed that
for some reason osmo-bts-trx stops sending Downlink bursts during
the process of ramping down.
I also noticed the following imporatant message:
DL1C NOTICE scheduler_trx.c:287 No more clock from transceiver
despite the transceiver is still powered on and keeps sending
the clock indications over the TRXC interface.
As it turned out, the problem is that on receipt of either SIGTERM
or SIGINT, we also raise the global 'quit' flag, so in the scheduler
trx_sched_clock() stealthy stops handling the clock indications.
Let's ensure that clock indications are handled regardless of the
state of 'quit' flag, so the ramping down would work as expected.
Change-Id: Ia71133d6f0b900e5e103595c83303a7cc5c06edf
Until now, power-ramp max-initial was only taken into account in order
to skip ramping if the desired target level was below it, in order to
forbid growin too quickly or applying directly to much power given power
amplifier requirements.
However, in the event that a higher tx power level is desired,
max-initial was not taking into account and ramping simply started from
current tx power level, which could be a lot lower than max-initial.
Allow shortcutting the ramping in that case so that max-initial is
applied directly, and ramping continues from there, in order to have a
more expected behavior (max-initial applied the same).
Since max-initial can since a few commits before handle a negative
value, this means One can for instance set max-initial to -10 and still
keep the old behavior of ramping step by step from -10 (rf-locked in
osmo-bts-trx) to 0 or 7 or whatever is the nominal power
(max_power_red).
Change-Id: I4e5742ecdbf66d77ff9445999f6fff43bbf4856a
If TRX is administratively locked during startup, for TS conigured as
TCH/F_PDCH the BSC will send a ACT PDCH message, but osmo-bts-trx won't
apply it by signalling it as available to the PCU, since the TRX is
locked.
That means the ts->flags contains the pending action to activate
it until it is unlocked. As a result, calling trx_set_ts() on it was
hitting the assert inside which expects not to apply the TS until it has
been confirmed by the PCU.
Let's still skip setting the TS and let pcu_tx_info_ind() trigger the
activation confirmation from PCU, since the TRX has just been unlocked.
Fixes following assert:
Assert failed (ts->flags & TS_F_PDCH_PENDING_MASK) == 0 /osmo-bts/src/osmo-bts-trx/l1_if.c:34
Change-Id: Ie3cad15d31870346d03a6e2f6dd32a9d2dd3067e
This allows for instance ramping up from -10 dBm -> -4 dBm if NOMTXPOWER
of SDR is really low (below 0dBm) or because the max_power_red is >=
NOMTXPOWER.
Related: SYS#4920
Change-Id: I0f27fb7b86b58c5a80f5342b66ff4f5d1b775498
Fix power ramping if administrative state changes while previous
opposite change was already ACKED but power ramping was still ongoing.
With previous code, osmo-bts-trx would have sent a NACK and BSc would
drop the BTs link as a result.
Change-Id: I6c5240710ef6d223651dfb4a8db939b5d2f974ca
Ramping down was set up with a target of -10 dBm, but then the code only
waited for all TRXs to be at least 0dBm, meaning that if operating more
than 1 TRX, the FSM could transit to state ST_WAIT_TRX_CLOSED when one
TRX reached -10 and other were already equal or below 0 (but not yet
-10). As a result, later on, when other TRXs reached -10 dBm they would
trigger EV_TRX_RAMP_COMPL which was not expected (no use) in
ST_WAIT_TRX_CLOSED.
Related: SYS#4864
Change-Id: If7af0b138efe78ec591c199a19fc22b304416a13
They were both half implemented but named differently, due to myself
adding them during the initial FSM implementation. This prevents
osmo-bts-trx sending a POWEROFF when OML link is dropped.
Related: SYS#4864
Change-Id: Ic2dab864b6d4075dfb9a1e4acfd9af013c9c46fe
How to reproduce:
* Configure a TS to be TCH/F_TCH/H_PDCH in osmo-bsc.cfg
* Run the network with osmo-bts-trx, then use osmo-bsc's "rf_locked 1"
* Then, unlock it: "rf_locked 0"
* The following assert will be hit:
Assert failed ts->dyn.pchan_is == ts->dyn.pchan_want /osmo-bts/src/osmo-bts-trx/l1_if.c:349
"""
(gdb) bt
#0 0x00007ffff5bb9355 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff5ba2853 in abort () from /usr/lib/libc.so.6
#2 0x00007ffff6832361 in osmo_panic_default (
fmt=0x555555814e60 "Assert failed %s %s:%d\n", args=0x7fffffffc6e0)
at /libosmocore/src/panic.c:49
#3 0x00007ffff683249d in osmo_panic (
fmt=0x555555814e60 "Assert failed %s %s:%d\n")
at /libosmocore/src/panic.c:84
#4 0x000055555570fdf7 in trx_set_ts (ts=0x7ffff1e6bce8)
at /osmo-bts/src/osmo-bts-trx/l1_if.c:349
#5 0x00005555557133c1 in bts_model_chg_adm_state (bts=0x627000000160,
mo=0x7ffff1e0f8a0, obj=0x7ffff1e0f860, adm_state=2 '\002')
at /osmo-bts/src/osmo-bts-trx/l1_if.c:681
#6 0x0000555555769978 in oml_rx_chg_adm_state (bts=0x627000000160,
msg=0x633000003e00)
at /osmo-bts/src/common/oml.c:1044
#7 0x000055555576a8d3 in down_fom (bts=0x627000000160, msg=0x633000003e00)
at /osmo-bts/src/common/oml.c:1129
#8 0x0000555555770aed in down_oml (bts=0x627000000160, msg=0x633000003e00)
at /osmo-bts/src/common/oml.c:1476
#9 0x00005555557f8174 in sign_link_cb (msg=0x633000003e00)
at /osmo-bts/src/common/abis.c:188
#10 0x00007ffff73b5935 in ipaccess_bts_read_cb (link=0x6120000030a0,
--Type <RET> for more, q to quit, c to continue without paging--
msg=0x633000003e00)
at /libosmo-abis/src/input/ipaccess.c:980
#11 0x00007ffff73a1060 in ipa_client_read (link=0x6120000030a0)
at /libosmo-abis/src/input/ipa.c:72
#12 0x00007ffff73a2458 in ipa_client_fd_cb (ofd=0x62f000038a50, what=1)
at /libosmo-abis/src/input/ipa.c:136
#13 0x00007ffff67ebfa7 in osmo_fd_disp_fds (_rset=0x7fffffffdda0,
_wset=0x7fffffffde40, _eset=0x7fffffffdee0)
at /libosmocore/src/select.c:227
#14 0x00007ffff67ec38c in _osmo_select_main (polling=0)
at /libosmocore/src/select.c:265
#15 0x00007ffff67ec46b in osmo_select_main (polling=0)
at /libosmocore/src/select.c:274
#16 0x00005555557ef089 in bts_main (argc=7, argv=0x7fffffffe208)
at /osmo-bts/src/common/main.c:354
#17 0x00005555556fe621 in main (argc=7, argv=0x7fffffffe208)
at /osmo-bts/src/osmo-bts-trx/main.c:176
"""
Related: OS#4920
Change-Id: Ia3210e24b921fd0c67f77068b7ef4a65f270cd11
Waiting until all other TRX are provisioned before really sending
POWERON helps avoiding race conditions where TRX!=0 are not yet fully
configured at the TRX side before POWERON is called.
This solves for instance the situation where after POWERON RSP the BTS
started ramping up on all TRX while on some NOMTXPOWER RSP was yet not
received...
Related: SYS#4920
Change-Id: I906be4714807c7a2793971cb6062120e24337d7b
The state of each config required is now tracked through the "acked"
variables, this way the FSM can know when all configs are confirmed by
the TRX and can proceed to submit POWERON command.
With this version each TRX is still totally independent (there's an FSM
per TRX), which means POWERON can be sent on TRX0 before TRX!=0 are
fully configured. As a result, powe ramping may start before we know the
NOMTXPOWER of a TRX. This kind of issue will be fixed in next commit.
Related: SYS#4920
Change-Id: I1b736a4be5ce52a854f5767d8609153e1f4c08d9
With prior code state managing the TRXC side of osmo-bts-trx, there are
plenty o cases (race conditions) where things can go wrong/unexpected,
because there's really no infrastructure to wait and synchronize between
different TRXs (eg wait until all are configured to POWERON), or to
simply keep well known per-trx state regarding lower layers.
In order to fix in the future all of those issues and to sanitize
current code, a new per-trx FSM is introduced, which takes care of
submitting TRXC commands and waiting for response when needed to manage
the state of the TRX.
Related: OS#4364
Change-Id: I2a00c23df15840e33fbb232c9e1dd6db128f63f6
the RSL link has nothing to do regarding the state of the Radio Carrier,
as in it being up is not enough to have a working (enabled) Radio
Carrier.
Change-Id: Iefb5c4e1097233b5c31e4d621c544d51516af678
At that time we schedule a POWERON command towards osmo-trx, so let the
callback of RSP POWERON set the OPSTATE in l1if_poweronoff_cb rather
than setting it without waiting for confirmation from osmo-trx.
Change-Id: Ib36a073cae5e1522821a04d8806648562f4e0f5b
Move all struct gsm_bts_trx references from bulky gsm_data to its own
file containing all related definitions and implementations. Also move a
few functions clearly related to that object which were placed in bts.*
Change-Id: Iebaf5b221c48b571f45408af867ce6f9c0cd9f4a
commit d211c490ca avoided sending
GSMTAP packets on the virtual Um interface with type
GSMTAP_CHANNEL_UNKNOWN by relying on gsmtap_makemsg returning NULL.
But that's not the corect approach since it's totally fine to be sending
GSMTAP_CHANNEL_UNKNOWN on some GSMTAP cases (for instance when the
program fails to infer the type when decoding a message), since then
this way one can study pcap files and find the offending encoded
messages which failed to be decoded.
This patch goes togehter with revert patch introduced in libosmocore as
explained in the commit referred above.
Change-Id: I233afd930d3e43f7b120d40192c7c192102e38d9
bts.h refers to struct gsm_bts object, but we still had a bunch of stuff
in bulky gsm_data.* from old days. Let's move stuff where it belongs to
start clean up of gsm_data.
Change-Id: I0a4219e3f64f625ee8b364bf408b8d2bcc8085c5
Ramp down when BTS is administratevly locked, and ramp up when it
becomes unlocked again.
Af ramping down, bts_model_trx_deact_rf is called to make sure all
channels are released.
power_ramp_start() is dropped from inside bts_model_trx_deact_rf since
it's not the proper place. In there we simply want to instantaneously
drop RF.
Related: SYS#4920
Change-Id: Ib7a7b0a0c24779349f142215f0bb32b72c86ce70
This should provide a quick way to check if the system is frequently
overloaded over time and hence downlink FNs are scheduled later than
expected.
Change-Id: I0051b9ab18ebc9f92db11374d856de94f155efa4
Pau Espin
Philipp Maier
Vadim Yanitskiy
Harald Welte
Alexander Couzens
Daniel Willmann