aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2021-11-16Bump version: 1.3.0.348-f42287-dirty → 1.4.01.4.0Pau Espin Pedrol5-23/+391
Change-Id: Ibf3ce0bfd0cf67148229dd988ebde6e6b8d744cc
2021-11-12gsm_lchan_interf_meas_calc_avg(): adapt to the order of boundariesNeels Hofmeyr1-3/+12
The order of interference level boundaries is not clearly defined by 3GPP, so we should support both ascending and descending variants. Change-Id: I88d841d8d835bde8392c7b606b28c9070b7adc6e Related: SYS#5313
2021-11-11gsm_lchan_interf_meas_calc_avg(): fix band calculationVadim Yanitskiy1-2/+5
This patch makes osmo-bts bahave similar to ip.access nanoBTS. Change-Id: I1bcc6d6ba154f82aef95d05fb9af0eab490923c9 Related: SYS#5313
2021-11-11oml: use ARRAY_SIZE() in oml_rx_set_bts_attr()Vadim Yanitskiy1-1/+1
Change-Id: I89dab55e39fe49c8b4d3afb4b46d1b7f2bf3663c
2021-11-09rsl: exclude disabled timeslots from interference reportsVadim Yanitskiy3-0/+14
It may happen after the A-bis connection recovery that the RF RESource INDication message gets sent too early, while some timeslots are not yet configured. This confuses the BSC and provokes error messages. Change-Id: I00bc6fe67ea1bbedcd5d8640e73bd8b16b9e667f Related: SYS#5313, SYS#4971
2021-11-07common/Makefile.am: reformat {AM_CPPFLAGS,AM_CFLAGS,LDADD}Vadim Yanitskiy1-3/+18
Change-Id: If475999cccc215b6792f276b9cc6c494a0c1ad81
2021-11-05gsm_ts_release(): Make sure pchan{,is_want} is reset to NONEPau Espin Pedrol1-0/+4
Let's make sure all ts->pchan* related data is reset when we release the TS. This is important for pchan_is, since in bts-trx upon shutdown finish the PDCH lchan of a osmo dyn TS is set to lchan->state=LCHAN_S_NONE, and as a result when the PCU tries to release it by means of PCUIF act_req later, it may be ignored since the lchan is already in erased state. Related: SYS#4971 Change-Id: Ic7c34c0de23101ce094ffd03e00b4d2f6a551152
2021-11-04measurement: make use of gsm48_meas_res_is_valid()Vadim Yanitskiy1-3/+3
Change-Id: Iea6ab7b69defd7ce88c2aa92fcf2b84370a4c135 Depends: Iae2bd508a08c4b5093d36e514c22218763e11edf
2021-11-04[overpower] Turn it on and off depending on DL RxQualVadim Yanitskiy4-3/+57
Change-Id: Iaa812d4661ee17c4cd4a8c4ae4bd3e94c1a2e6cc Depends: Ia28293a12de0af71f55e701fb65c46e905dae217 Related: SYS#5319
2021-11-04measurement: pass *mr to lchan_bs_pwr_ctrl()Vadim Yanitskiy6-112/+19
As a side effect, we have to sacrifice a unit test (TC_inval_dummy) because it becomes impossible to pass a dummy or invalid SACCH block to lchan_bs_pwr_ctrl(). Change-Id: I937117cf26fb718d57920382f6972390ad498c51 Related: SYS#4918
2021-11-04measurement: pass *mr to repeated_dl_facch_active_decision()Vadim Yanitskiy1-10/+3
Change-Id: Idbf5f95d632aa2270c49b351ad5561ca2182bf9a Related: SYS#5114
2021-11-04measurement: get rid of *le in lchan_meas_handle_sacch()Vadim Yanitskiy1-6/+3
The current Timing Advance value can be obtained either from the L1 SACCH header (if received) or from lchan->ta_ctrl.current. Change-Id: I2b3693a0e49f03f2b4496c9dbd30cf47e9bc86b5
2021-11-04lchan_meas_handle_sacch(): check if Measurement Result is validVadim Yanitskiy1-1/+2
We should not rely on measurement data marked as invalid. Change-Id: I4aaac742674ce3ac15e9a4a32fe7c72db81d32d2
2021-11-04l1sap: rework handling of DATA.ind on SACCHVadim Yanitskiy4-74/+84
Currently an Uplink SACCH block is being passed to LAPDm first, and then gets forwareded to the BSC in handle_ms_meas_report(), together with the Uplink measurements collected so far. This approach has a serious flaw: handle_ms_meas_report() won't be called if an Uplink block contains SAPI=3 data (SMS) or was not decoded at all (len=0) fow whatever reason. Therefore, no RSL MEASurement RESult message will be sent to the BSC. Rename handle_ms_meas_report() to lchan_meas_handle_sacch(), and call it from l1sap_ph_data_ind(). This way perioduc RSL MEASurement RESult messages will be sent regardless of what happens on Uplink SACCH. Change-Id: Ifed91f87fd653debc87a09da3fd31ad64a13f330 Fixes: TC_meas_res_speech_{tchf,tchh}_sapi3 Related: SYS#5319
2021-11-03abis: Try one reconnect to previously connected BSC before trying next onePau Espin Pedrol1-0/+11
This way we keep all BTS connected to the same BSC if there was a spurious network problem. Related: SYS#4971 Change-Id: I16b75da5987584d099edc3a640f3a5cd61f3ad69
2021-11-03abis: Drop unneded if condition in else clausePau Espin Pedrol1-1/+1
priv->current_bsc will for sure be != last, otherwise it would have entered the if clause above it. Change-Id: I0a6519f7b93f0b45c67d19fef4f50daeeefc7340
2021-11-03bts-trx: sched_lchan_tchf: Change log level to debug for line informing ↵Pau Espin Pedrol1-1/+1
about missing dl prim This scenario is actually expected when the call is being set up or torn down, since we may not be receiving RTP from the MGW to send to the MS. Hence, let's lower the log level to DEBUG to avoid having log clogged for each call start/stop if INFO is used. Related: SYS#5676 Change-Id: Ib7f274b97cc66d671316eae429ee4baf16831534
2021-11-03scheduler: Fix FACCH msg with l2len==0 going to lower layers and logging errorsPau Espin Pedrol1-1/+1
Recent commit (see below) changed a check to avoid weird results for msg which had l2h=NULL, since l2len would return unexpected results there. However, some code branches like FACCH or TCH seem to be always setting l2h even if len=0. Hence, we must test either of the 2 scenarios (null pointer and l2len()). This commit fixes the following message appearing all the time during calls: """ TCH/F: Prim has odd len=0 != 23 """ Fixes: fb905b8d235ff2efe6c1cd9fde2b488b311c1cd7 Related: SYS#5676 Related: SYS#4919 Change-Id: I43152bc8484a35cd004d3303d3a6e6efcdefa890
2021-11-03bts-trx: sched_lchan_tchf: Drop impossible code pathPau Espin Pedrol1-6/+0
It cannot happen that msg1 is NULL and msg2 is not null, since they are deuqueed from same place. Only possible combinations are: msg1!=NULL && msg2!=NULL msg1!=NULL && msg2==NULL Change-Id: Ifd789844b1a7dfba596664de440d4c20b9f4c78f
2021-11-01osmo-bts-trx-calypso.cfg: Adjust settings to work with current osmo-bts versionsMartin Hauke1-4/+5
* 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
2021-10-28rsl: fix a memory leak in handle_gprs_susp_req()Vadim Yanitskiy1-0/+1
Change-Id: I65d9c12888aa5e5112680b3b3f38817e322ecc1c
2021-10-28l1sap: make 'l1sap' argument of process_l1sap_meas_data() constVadim Yanitskiy1-4/+4
Change-Id: Idc3004b0c74f7b98c96f20560c8b60a1fb4eb9c8
2021-10-27l1sap: process_l1sap_meas_data() accepts pointer to lchanVadim Yanitskiy1-27/+21
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
2021-10-27l1sap: use designated initializers in process_l1sap_meas_data()Vadim Yanitskiy1-30/+24
Change-Id: I5169a6c5f6865655dbfebb6b68d5f67941d9cdb1
2021-10-27l1sap: move false PTCCH/U detection into PDCH branchVadim Yanitskiy1-9/+8
This check is only relevant for PDCH timeslots. Change-Id: I187fef8f3de0b41b502b0b18acfb11c56c5551f0
2021-10-27l1sap: fix handling of lchan->pending_rel_ind_msgVadim Yanitskiy1-11/+7
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 991020c049c63768e147d49bd2918c2d2e0f6dcb 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
2021-10-26scheduler: Avoid crash upon call to trx_sched_set_lchan if l1ts is uninitializedPau Espin Pedrol1-0/+6
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
2021-10-26l1sap: Avoid re-(de)activating already (de)active lchansPau Espin Pedrol1-0/+13
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
2021-10-25bts-trx: sched: tx_pdtch_fn: Drop log line clogging logsPau Espin Pedrol1-1/+5
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: 300e31ed135c674cd44526b7503d4664a45a9ec3 Change-Id: Ia7045724a1a3206f5890c0b12843711ad2360ed8
2021-10-25scheduler: Fix check against empty PDCH blocksPau Espin Pedrol1-1/+1
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: 300e31ed135c674cd44526b7503d4664a45a9ec3 Change-Id: I18b61fcaa858a53887191a18d560c2e929478c64
2021-10-25Revert "bts-trx: sched: tx_pdtch_fn: Handle PCU idle blocks properly"Pau Espin Pedrol1-5/+2
This reverts commit 8a85b71167c4580ddf9e6c59ea602475fd462b3a. 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
2021-10-25bts-trx: sched: tx_pdtch_fn: Handle PCU idle blocks properlyPau Espin Pedrol1-2/+5
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: 300e31ed135c674cd44526b7503d4664a45a9ec3 Change-Id: I57e215fedeb415db4e67fdc56bf0f1410b5f7130
2021-10-25bts-trx: sched_lchan_pdtch: Refactor tx_pdtch_fn to get rid of goto tagPau Espin Pedrol1-12/+11
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
2021-10-25[overpower] scheduler: handle {sacch,facch}_enabled flagsVadim Yanitskiy1-5/+5
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
2021-10-25[overpower] lchan_dump_full_vty(): print overpower stateVadim Yanitskiy1-0/+31
Change-Id: I052f1d68b27b2dc7203835b4a93d40c94b0c8d82 Depends: Ia28293a12de0af71f55e701fb65c46e905dae217 Related: SYS#5319
2021-10-25[overpower] rsl: store full content of RSL_IE_OSMO_TEMP_OVP_ACCH_CAPVadim Yanitskiy3-9/+13
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
2021-10-25initial support for static userspace probes via systemtapHarald Welte7-1/+97
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
2021-10-23lchan: introduce and use lchan_is_tch() helperVadim Yanitskiy3-3/+5
Change-Id: Icd832667cad1189e3e819c88bde837c4260aa252
2021-10-23rsl: fix handling of REL IND in lapdm_rll_tx_cb()Harald Welte1-9/+9
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
2021-10-23lchan_set_state(): also free pending messages if anyVadim Yanitskiy1-0/+5
A logical channel may have associated messages, which are pending for transmission until some event occurs. Do not leak them. Change-Id: I3264e6caa007e9e9cb9c1c2f8627c408bbb28b9e
2021-10-23osmo-bts-trx: fix potential NULL pointer dereferenceVadim Yanitskiy1-4/+6
Change-Id: Ic9c1f3a3fb9c151bba4f6c3e605746fc8d43f44f Fixes: CID#240207
2021-10-23measurement: fix wrong operator used in handle_ms_meas_report()Vadim Yanitskiy1-1/+1
Change-Id: Iad781dde0406d341bf385734ceddf51999558dd3 Fixes: CID#240263
2021-10-22struct gsm_lchan: move tch.rep_facch to rep_acch.dl_facchVadim Yanitskiy3-20/+18
Finally we have all ACCH repetition state variables in one place. Change-Id: I1469619528bb69c78c2fdc25bc1db208ead936d0 Related: SYS#5114
2021-10-22struct gsm_lchan: group ACCH repetition state fieldsVadim Yanitskiy6-38/+41
Change-Id: I2680c88f2a51b64f085a92233bc125338622babf Related: SYS#5114
2021-10-22cosmetic: s/repeated_acch_capability/rep_acch_cap/gVadim Yanitskiy6-23/+23
Shorter symbol names are easier to read. Change-Id: Ib1d51f91139b4c2fe794e37fc8543b2d7a9b9c07 Related: SYS#5114
2021-10-22measurement: make sure that DL measurements are validVadim Yanitskiy1-0/+2
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
2021-10-22measurement: move repeated_dl_facch_active_decision() hereVadim Yanitskiy4-78/+76
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
2021-10-22measurement: handle_ms_meas_report() accepts const ghVadim Yanitskiy2-4/+8
Change-Id: Iba37c1a92b8b17a8ba8c958fb6c296747578cb1b
2021-10-22rsl: send NACK if BTS_FEAT_ACCH_REP is not supportedVadim Yanitskiy1-4/+13
Change-Id: I7993cf7842ffde561f2bdc50f56516c3a188b2bc Related: SYS#5114
2021-10-22rsl: rsl_tx_meas_res() does not change l3, make it constVadim Yanitskiy2-2/+2
Change-Id: Ie60a34f90f7872464e503dc7b56935aee95f0f80