* Remove deprecated configuration options:
'osmotrx timing-advance-loop' is deprecated, Timing Advance loop is now active by default
'osmotrx ms-power-loop <-127-127>' is deprecated, MS Power Control is now managed by BSC
* Adjust 'ipa unit-id' (1801 -> 6969) to match the one from the example osmo-bsc.cfg
* Set clock advance values to known working values:
+ 'osmotrx fn-advance' -> 20
+ 'osmotrx rts-advance' -> 5
* Set 'nominal-tx-power' since the calypso-bts tranceiver does not support NOMTXPOWER
Change-Id: I69436b914cf1bec57f9fe7acea4a896e7c46b3a9
In 2/3 cases when calling process_l1sap_meas_data() we already have
a pointer to the logical channel, so let's pass it as the first
argument instead of a pointer to the transceiver. This way we
avoid calling get_active_lchan_by_chan_nr() two times.
In l1sap_ph_data_ind(), call process_l1sap_meas_data() below the
conditional branch handling PDCH, so it won't be called for
GSM_LCHAN_PDTCH anymore. GPRS specific measurements are handled
by the PCU and not of interest for the BSC.
Change-Id: I9de67a0b2d2b18923f2c2003b400387a0f1af411
After merging the patch [1] fixing handling of the RLL RELease
INDication message in lapdm_rll_tx_cb(), ttcn3-bts-test shows
several regressions:
pass->fail: BTS_Tests.TC_rll_rel_ind_DCCH_0
pass->fail: BTS_Tests.TC_rll_rel_ind_DCCH_3
pass->fail: BTS_Tests.TC_rll_rel_ind_ACCH_0
pass->fail: BTS_Tests.TC_rll_rel_ind_ACCH_3
pass->fail: BTS_Tests_LAPDm.TC_sabm_dm
[1] I823c9101bcca72d5792e16379b02d3602ffc2726
991020c049
The problem is actually *not* in patch [1], but in the older one
[2] which we attempted to fix. While a logical channel is in
signalling mode, the lower layers do not produce PRIM_TCH_RTS,
and thus the l1sap_tch_rts_ind() is not being called.
Unlike l1sap_tch_rts_ind(), the l1sap_ph_rts_ind() is being called
regardless of the channel mode (signalling vs speech), so let's
move handling of lchan->pending_rel_ind_msg there.
Change-Id: I2c380f9045624f0a0a8f988bb207bc73d8354857
Fixes: [2] Ie4f70c75f0137b4bd72d579b3a32575bac2fca3
It could happen if for instance l1 code called trx_sched_clean() when
closing the phy, and after that some code called (erroneously)
trx_sched_set_lchan(). Let's make sure we don't allow other modules to
crash the process when using this function.
Related: SYS#4971
Change-Id: I93af7c3dcf0e34e9317eec0ee183dbf18b8d2f3b
This avoids triggering all sorts of unexpected paths where one tries to
release an already released lchan, etc.
This can happen for instance if BTS shuts down due to BSC link going
down, and hence resets all lchans, announcing it to the PCU. Then the
PCU may try to deactivate the channel sending act_req (disable), but the
BTS already unilaterally dropped the channels.
That code path seems to trigger some crash, probably because something
in lchan has been freed.
Related: SYS#4971
Change-Id: I093e4d4e23b527b10bf5d6ff538460626c30a8f8
The burst is properly pre-filled to _sched_dummy_burst in
bts_sched_init_buffers(), so we are fine doing nothing on C0.
Related: SYS#5676
Related: SYS#4919
Fixes: 300e31ed13
Change-Id: Ia7045724a1a3206f5890c0b12843711ad2360ed8
msgb_l2len() will return nonzero values if msg->l2h is NULL.
Let's check against msg->l2h being NULL instead.
Related: SYS#5676
Related: SYS#4919
Fixes: 300e31ed13
Change-Id: I18b61fcaa858a53887191a18d560c2e929478c64
This reverts commit 8a85b71167.
This is actually the wrong fix. Proper fix comes as a follow-up patch,
since the root cause happens earlier in upper layers. No msg with
l2h=NULL should reach this point of code ever.
Change-Id: Ie23d94924f824bd7e89437ccf73b260f542477c6
PCU idle blocks are identified by being 0 length, and hence msg->l2h
being null. Don't try to encode those, but simply discard them silently.
In case there's a missing block in C0, we want to log the event since
the BTS is expected to send something on C0.
Related: SYS#5676
Related: SYS#4919
Fixes: 300e31ed13
Change-Id: I57e215fedeb415db4e67fdc56bf0f1410b5f7130
With this change the error case is moved at the end of the function,
which is more usual. At the same time, one goto tag can be removed,
simplifying the function.
This is also a preparation for next patch improvinga bit the logic
around same place.
Related: SYS#5676
Related: SYS#4919
Change-Id: Ifbd95ccbebf4d810b1fe0a162722e63fe69106b8
The new [bit-]fields in the RSL_IE_OSMO_TEMP_OVP_ACCH_CAP allow
more fine-grained control over the overpower feature, which
can be enabled:
* for both SACCH and FACCH,
* for SACCH only, or
* for FACCH only.
Change-Id: Iaaab675a20bbefece832d913963c8c5ae32ff80c
Depends: Ia28293a12de0af71f55e701fb65c46e905dae217
Related: SYS#5319
The new fields in 'struct abis_rsl_osmo_temp_ovp_acch_cap' allow:
* selectively enabling SACCH and/or FACCH,
* setting the RxQual (BER) threshold.
Both features are implemented in the follow-up commits.
Change-Id: I370c8f95fb64eceb60a9dc2eae1412f8a0df0f4e
Depends: Ia28293a12de0af71f55e701fb65c46e905dae217
Related: SYS#5319
This adds a --enable-systemtap configure option, which will then
add static tracepoints to the generated osmo-bts-* binary.
At this point, only two sets of tracepoints are supported, and
only in osmo-bts-trx: ul_data_{start,done} and dl_rts_{start,done}.
The probes are intended to be used for analyzing the amount of time
needed for processing of uplink bursts / generation of downlink bursts.
Change-Id: Ibb4962253f1a195dc1a54405bac058ccb2545799
During the merge of [1] the patch hunk was applied at a slightly
wrong location, so the code path has become unreacheable.
Change-Id: I823c9101bcca72d5792e16379b02d3602ffc2726
Fixes: [1] Ie4f70c75f0137b4bd72d579b3a32575bac2fca3
A logical channel may have associated messages, which are pending
for transmission until some event occurs. Do not leak them.
Change-Id: I3264e6caa007e9e9cb9c1c2f8627c408bbb28b9e
In repeated_dl_facch_active_decision() we rely on the Measurement
Report message, that in some cases may not contain valid Downlink
measurements. In this case, we should simply ignore it.
Change-Id: I0d72b454f2b770d5762303fb70a15a8cdc9d07d7
Related: SYS#5114
For the sake of consistency, call repeated_dl_facch_active_decision()
from handle_ms_meas_report(), so we have all functions using the
measurement results for Downlink executed in a single place.
Change-Id: Ibd5377ce642e49161f320ac8c33e9f966b3ddfaf
Related: SYS#5114, SYS#5319
A bit of archeology, history & recap:
ec1b5a0e9e2b6549e0ede48e803095e569997355 (openbsc.git) Adds assert in gsm_ts2chan_nr()
2f44693fad8505255293d3ed37dbd4e7cabebd37 (openbsc.git) ASSERT is disabled due to reported hit in octphy and
litecell in gerrit for ec1b5a0e9e2b6549e0ede48e803095e569997355
5cef0623ef (osmo-bts,git) minor fixes to gsm_ts2chan_nr() regarding the pragma
c9079d9106 (osmo-bts.git) GSM_PCHAN_NONE case is introduced in gsm_ts2chan_nr()
This code has long evolved and robustness has improved, it's not even
part of openbsc.git for several years now. Let's always assert if we
receive an unexpected value there, since they are all internally handled
values and hence we have control over them.
Related: OS#2906
Change-Id: I25e2cf0c922bc9902336e9add75a47535b9355bf
It can happen when using several TRX that all of them go alreadyunder
shutdown target tx power level, but that due to configuration the BTS
still may want to keep pushing the tx power level even lower. Hence, we
end up in a situation where the FSM is trying to close all the TRX while the
power ramp procedure is ongoing for some of them. As a result, race
conditions can happen where for instance the power ramping procedure for
one TRX ends and calls the cb to send SETPOWER after the TRX PHY has
been closed (and hence TRXC link is unavaialble).
If that happens, the trx_if lower layers store the SETPOWER and attempt
a later retransmit, which may take up to 2 seconds after TRX becomes
active if BTS reconnects immediatelly.
Hence, we end up in some test cases where BTS reconnects and configures
some TRX while others are kep unconfigured for a while due to the
mentioned delay, hence the test attempting to use the TS while it hasn't
been yet configured.
The solution is to avoid this kind of unexpected events with ongoing
powe ramp once we have decided tx power is lower enough to shutdown the
TRX completely. Hence we abort the pending power ramp procedure.
Change-Id: Ibca581131eb142d7c38c917a0d6990efec03123c
Fixes crash when TTCN3 BTS_Tests_LAPDm TC_rr_response_frame_loss
runs run after TC_t200_n200.
The BTS was shutdown after TC_t200_n200 failed (drop oml link), and
lchan was moved ACTIVE->NONE without lapdm_channel_exit() being called
on it. Hence, on next test (TC_rr_response_frame_loss), when
lchan_init_lapdm() was called again, some memory corruption was caused.
The lapdm_channel_exit can be dropped from gsm_lchan_release() and
rsl_tx_rf_rel_ack() since it's already called in the same path:
"""
rsl_rx_rf_chan_rel
gsm_lchan_release(lchan, LCHAN_REL_ACT_RSL);
l1sap_chan_rel(lchan->ts->trx, gsm_lchan2chan_nr(lchan));
l1sap_chan_act_dact_modify(trx, chan_nr, PRIM_INFO_DEACTIVATE)
bts_model_l1sap_down
bts_model_lchan_deactivate_sacch(lchan);
-
lchan_deactivate(lchan);
bts_model_lchan_deactivate
lchan_set_state(lchan, LCHAN_S_NONE); <---------
mph_info_chan_confirm(trx, chan_nr, PRIM_INFO_DEACTIVATE, 0);
l1sap_info_rel_cnf
rsl_tx_rf_rel_ack(lchan);
lapdm_channel_exit(&lchan->lapdm_ch);
lapdm_channel_exit(&lchan->lapdm_ch);
"""
Related: SYS#5262
Change-Id: If0ec5f0c7be4d15c8d684d33e15e24d68bd5192e
osmo-bts-trx/l1_if.c lchan_init_lapdm() for CCCH is already done when
trx_set_ts_as_pchan() calls:
"lchan_set_state(&ts->lchan[CCCH_LCHAN], LCHAN_S_ACTIVE);"
Change-Id: I7a9c3660b9aab57ff8765e2f1526349599630cd9
Let's avoid running over state change conditions or even printing log
lines if there's no state change.
Change-Id: I1ca86aa846084f53751076643665cb6dabc26a06
There's no need to re-setup it every time.
Mark the cb as static since its private to the module, and move it
above its use point so it can be referenced.
Change-Id: I90324f26d8ca09d425c7523a25b3e6c951fa49d6
* Move way too verbose command description to the manuals.
* None of these commands apply immediately, correct the attributes.
** Remove meaningless call to l1if_provision_transceiver_trx().
* Make 'maxdlynb' hidden, so it only appears in the expert mode.
* One GMSK symbol actually corresponds to 550m.
Change-Id: I46839cf56bba2dcdc70303cd393e86d35aa2f3f5
trx_phy_inst_open() already guards against NULL trx ptr when calling
trx_sched_init(). Later on, in same path, trx_phy_inst_close() can be
called which ends up calling trx_sched_clean(trx), this time not being
guarded against NULL trx. This fixes Coverity CID#240498.
Fixes: CID#240498
Change-Id: I00afc739559d57dd98db68c76f2a85006c15e875
- one gsm symbol is 0,00000369 seconds
- 2*550m/c = 0,00000366 seconds
-> one ta symbol is a DISTANCE of 550m (or a RTT of 550m*2) between bts and ue.
-> no idea why this was constrained to TA/2.
Change-Id: I8d79080c82411e6427eec37d008614fa5d5e1ace
Related: OS#5140
The OML NM Channel FSM state only apply to primary timeslots, hence we
need to make sure we pick the primary TS (the non-shadow one).
Due to this bug, all channels on shadow TS where NACKed because the
related state was never "Enabled Ok".
Fixes: c97a7f51e1
Related: OS#5249
Related: OS#5251
Change-Id: If47e4bdd45a05ed1b5709b6e3d541f2830723e37
Since non-shadow TS are currently not allocated as talloc contexts,
lchan objects tend to allocate their own memory on trx talloc ctx
instead. That's fine for non-shadow TS, since the TS follow trx lifecycle
since they are part of the same talloc context. However, shadow TS are
recreated (re-allocated) each time the BTS reconnects, hence when htey
are freed we need to free substructs (lchan) memory in order to avoid it
being kept in trx talloc ctx.
Related: OS#5248
Change-Id: I73742535eb3c40a6866731acbff782940dab06c3
Code in oml.c, upon receiving net attributes, merges the new attributes
with old ones (for some reason I don't really know). Hence, if we
disconnect from a BSC and go to NOT_INSTALLED state, we must free
previous nm_attr in order to avoid mixing them once we connect to a new
(potentially different) BSC upon reconnect.
Related: OS#5248
Change-Id: I45cc22dd68121a7930301581bfd0a8db37879c77