path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2020-03-08rsl: make IP DSCP configurablelaforge/virt-voiceOliver Smith3-2/+26
Related: OS#4438 Depends: libosmo-abis I41603db8c1286660ad57ac1c78a8fb393a2b080b Change-Id: Icdef5d40243fefdeae23f3bcf9c6702e8487928a
2020-03-08osmo-bts-virtual: implement GSMTAP_CHANNEL_VOICEHarald Welte2-12/+79
GSMTAP_CHANNEL_VOICE is the mechanism by which GSMTAP can [finally!] be used to transport circuit-switched voice codec payload, and not just signalling. Original patch by Neels Hofmeyr, heavily extended by Harald Welte. Depends: libosmocore.git I952044a17334f35712e087dc41781805000aebc1 Change-Id: I1cd9a251ce0b87181a0822d7940bbfc9f1428543
2020-03-08l1sap: Use msgb_pull_l2() and unify l1sap_tch_ind + l1sap_ph_data_indHarald Welte1-3/+2
In l1sap_ph_data_ind() we can use msgb_pull_l2() which is an exact implementation of the functionality there. In l1sap_tch_ind(), the existing code is actually wrong by making the assumption that the msgb contains exactly an entire osmo_phsap_prim. Better to also dynamically compute the number of bytes to ensure we only pull those ahead of the L2 header, no matter what their exact count. Change-Id: I13f7f8ba93795e40b1fb4a306fe765e059f642cf
2020-03-04osmo-bts-virtual: do not log GSMTAP message sending failure twiceVadim Yanitskiy2-2/+5
Change-Id: I39e9edf35240ef31e3432412b459c2b8fb0de054
2020-03-02osmo-bts-virtual: do not print redundant info in tx_to_virt_um()Vadim Yanitskiy1-13/+2
LOGL1S() already prints enough context information. Change-Id: I29adf9360b96544b7f58766d5cd26d97117884d9
2020-02-29osmo-bts-virtual: fix wrong endianness in gsmtap_hdr_stringify()Vadim Yanitskiy1-1/+3
Change-Id: Ic9e84dc4adc44df735cba102bdace2fb1993ac8e
2020-02-29common/sysinfo: reduce criticality of a logging messageVadim Yanitskiy1-1/+1
During the process of bootstrapping, it may happen that System Information Type 3 is not yet received from the BSC, while the BTS already needs to transmit a block on AGCH or PCH. Since the RSL link is established later than the OML link, it's kind of expected, so we should not log it as error. Change-Id: I41aa3dbe375cf42c39032bafa80dba94d6219d35
2020-02-27vty: fix left shift by 31 cannot be represented in type 'int'Vadim Yanitskiy1-1/+1
Change-Id: I3e5940e8f360bf6563f4c1b5ebd09579f9108c81
2020-02-26virtual: Fix VTY commands to specify GSMTAP multicast groupsHarald Welte1-2/+2
osmo-bts-virtual uses GSMTAP over multicast groups to communicate with one or more virtphy instances. There are some well-known default multicast groups, but those can also be overridden via the VTY. The problem is: If you actually try that, osmo-bts-virtual will abort, as we try to talloc_free() when using osmo_talloc_replace_string() on the constant default string. The proper solution is to talloc_strdup() the constant default string when setting the default value in bts_model_phy_link_set_defaults(). Change-Id: Ia96fea891a22e5a3c47ce658eda130ba8d4fc411
2020-02-25cosmetic: Fix some typos with codespellPau Espin Pedrol3-3/+3
Change-Id: I1bbb4871f764816dcbba86d833194be601fa9228
2020-02-25bts-trx: trx_if.c: Fix some printf formatsPau Espin Pedrol1-3/+3
Compiler from raspberrypi4 warns/errors about those. Change-Id: I4f973eb4ffdf8869b522d14e25853357fcd1e984
2020-02-17osmo-bts-sysmo: merge measurement data and payloadPhilipp Maier7-30/+26
For osmo-bts-sysmo the MPH INFO MEAS IND indication is still sent separately. Lets merge the measurement information into the PH DATA Change-Id: Iffe7865727fbf9bca8eb32a96e8ea05cf718a948 Related: OS#2977
2020-02-17Do not depend on pcu_direct flag when populating ph_data_indPhilipp Maier3-15/+12
The struct members ber10k, ta_offs_256bits and lqual_cb in ph_data_ind are only populated when the pcu_direct flag is not set. The pcu_direct flag is set when the pcu is directly attached to the phy and all pcu related traffic (pdtch) is handled without sending it through osmo-bts-sysmo. For those cases osmo_bts_sysmo will not make use of those struct members, even if they were populated. When the PCU is not directly attached the data is needed because it is sent through the pcu_sock to the PCU. Lets remove the check because it is not required. Also in future patches where measurement indications and data / tch indicatins are merged the struct members are also needed to carry the measurement information for SACCH as well. Change-Id: Iaa37bb62af4f5eb4b6e684cb754e68d11e6fd676
2020-02-12l1sap: Change loglevel of Rx TCH.ind INFO->DEBUGPau Espin Pedrol1-1/+1
This line appears tens of times per second when a call is ongoing, making it impossible to follow logs on INFO level. Change-Id: Iadb1baf55df2f6d96f85260f2e8d03627fef7e66
2020-02-12l1_if: Fix strange formatting of Meas info loggingPau Espin Pedrol4-40/+27
Some use LOGPC, but were used after a LOGP with a trailing newline. Let's simply add some defines/macros to be able to include it into a normal LOGP easily insted of having a function. Change-Id: Ie082b11c9d6d00ff2206184f03f6e3647c3da18c
2020-01-21osmo-bts-sysmo/Makefile.am: fix: do not overwrite bin_PROGRAMSVadim Yanitskiy1-1/+1
src/osmo-bts-sysmo/Makefile.am:25: warning: bin_PROGRAMS was already defined in condition TRUE, which includes condition ENABLE_SYSMOBTS_CALIB src/osmo-bts-sysmo/Makefile.am:10: ... 'bin_PROGRAMS' previously defined here Change-Id: Ib2334dccefd507eaaa6d33e58d4c1e029d7fd540
2020-01-20l1sap: merge MEAS IND into PRIM PH DATA / PRIM TCHPhilipp Maier7-97/+120
The MPH INFO MEAS IND indication, which contains the uplink measurement data is sent in parallel to the PH DATA and TCH indications as a separate indications. This makes the overall uplink measurement data processing unnecessarly complex. So lets put the data that is relevant for measurement into the PH DATA and TCH indications directly. This change only affects osmo-bts-trx at the moment. In order to keep the upper layers (l1sap.c) compatible we add an autodection to switch between separate measurement indications and included measurement data. Related: OS#2977 Depends: libosmocore I2c34b02d329f9df190c5035c396403ca0a4f9c42 Change-Id: I710d0b7cf193afa8515807836ee69b8b7db84a84
2020-01-20measurment: write irssi_full_sum variable correctlyPhilipp Maier1-1/+1
The variable irssi_full_sum is not populated with a dummy value when we are not able to compute irssi_full_sum. Instead we mistakenly write MEASUREMENT_DUMMY_IRSSI to ber_full_sum, which is wrong Change-Id: I44d7cb48e3c68ab1b48c78cceb9381ce3e39d7e8 Related: OS#2987
2020-01-20ta_control: move timing advance code from osmo-bts-trx to commonPhilipp Maier8-78/+66
The timing advance controller that is implemented in loops.c of osmo-bts-trx only works for osmo-bts-trx and not for any of the phy based bts. Lets move the timing advance controller into the common part and make it available for every bts. Also lets add a unit-test. Change-Id: If7ddf74db3abc9b9872abe620a0aeebe3327e70a Related: SYS#4567
2020-01-14L1SAP: use LOGL_DEBUG for logging from rach_pass_filter()Vadim Yanitskiy1-3/+3
Due to relatively small training sequence of Access Bursts, there can be frequent false-positives (basically noise). Fortunately, we can distinguish them from the real Access Bursts by checking the signal measurements attached to them (BER, ToA and C/I). Let's reduce verbosity of logging messages as they are mostly useful for debugging and may confuse the users / operators. Change-Id: I7ab6727ffff00140a7f9e762b299b711481393f1
2020-01-12rsl.c: Fix compiler error on gcc-9.2.1Harald Welte1-1/+1
rsl.c: In function ‘rsl_rx_ipac_XXcx’: rsl.c:2147:39: error: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size 28 [-Werror=format-truncation=] 2147 | snprintf(cname, sizeof(cname), "bts@%s", ipstr); | ^~ rsl.c:2147:3: note: ‘snprintf’ output between 5 and 260 bytes into a destination of size 32 2147 | snprintf(cname, sizeof(cname), "bts@%s", ipstr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change-Id: Id982a814f401e304327d25c77666f039bc156c1f
2020-01-11common/abis.c: make use of RSL TEI from OML IPA RSL ConnectVadim Yanitskiy2-2/+5
Change-Id: I5927f59a49724170a63e87be604973f7c9d5d8be
2020-01-11common/vty.c: get rid of generic exit / end commandsVadim Yanitskiy1-42/+0
Those commands are now handled by libosmovty itself. Change-Id: I425f9058ae15de929e2ba0283d4057bdf767aeeb
2020-01-06measurement: use signed integer for division of ta256b_sumMichael McTernan1-1/+1
The variable ta256b_sum is int32_t and num_ul_meas_actual is unsigned int. When ta256b_sum is negative the division produces the wrong result. This is beacuse the division is performed unsigned as the usual arithmetic conversions promote to unsigned where both both operands are the same width. Lets fix this by casting num_ul_meas_actual to signed. (Note that in the same function there are various other averages computed in the same pattern, but they have unsigned operands and so are correct.) Related: SYS#4728 Change-Id: I37e3f69109c5ca2948bd4cdb7aa017bf2fcb8172
2020-01-03l1sap.c: ensure ms power control loop is runningpmaier/meastestPhilipp Maier1-0/+2
When a bad SACCH frame is received the processing of the frame is ended early and lchan_ms_pwr_ctrl() is not called. This means that the power control loop does not get informed about a situation where the signal level is very weak and increasing the ms power would make sense. In order to ensure that the power control keeps working on lost SACCH frames, lets call lchan_ms_pwr_ctrl() with the current RSSI and the requested (BSC) power setting. Related: OS#4281 Change-Id: I4fb85754b1a69376b02da7f4b175c6e8ec9cc35c
2020-01-03rsl: ensure measurement reports are sentPhilipp Maier4-8/+39
osmo-bts currently does not generate a measurement report in case the SACCH of the related traffic channel is lost. This is a problem because the moment when reception gets bad measurmenet reporting is crucial to carry out handover decisions effectively. The presence of a SACCH block controls the conclusion of the measurement interval and the sending of the RSL measurement report. The latter one not only requires a measurmenet indication, it also requires a fully intact SACCH block. Lets use the NOPE / IDLE indications from V1 of the TRXD protocol to ensure a SACCH block is always reported up to l1sap.c. In cases where the SACCH is bad, trigger the sending of the RSL measurement report manually without attaching the measurmenet data from the MS (which we do not have in this case) Related: OS#2975 Depends: osmo-ttcn3-hacks Ib2f511991349ab15e02db9c5e45f0df3645835a4 Change-Id: Idfa8ef94e8cf131ff234dac8f93f337051663ae2
2019-12-31osmo-bts-trx/vty: ensure backwards compatibility with older config filesVadim Yanitskiy1-2/+11
osmo-bts-trx used to have its own (low-level) MS Power Control loop, but recently it has been ripped out. Since [1], the process fails to start if the configuration file still contains 'ms-power-control dsp'. Let's be more tolerant: override 'dsp' by 'osmo' and print a warning. [1] I49706926b1e962b18791174627bc3cc0cd0cd9d5 Change-Id: I4facd21bca3d8cb80d21e83ea267bc013e474533
2019-12-23l1sap: is_fille_frame(): verify len of data comparedPau Espin Pedrol1-0/+3
Change-Id: Id3d1725ff36091ed5c57927caad09a8baea6f52e
2019-12-05power_control.c: Clarify loop algo vars and use correct ones during logPau Espin Pedrol1-18/+18
Rename some variables so that: * Variables containing power control levels end up with "_lvl". * Variables containing power levels end up with _dbm. * Move old current_dbm var to be ms_dbm, to match its power control level counterpart ms_power_lvl, and add current_dbm to match its counterpart ns_power_ctrl.current. Now that variables are more clear, it also becomes clear that old "diff > 0" condition, apart from difficult, was currently wrong, since in order to print the raise/low verb we want to compare between old and new values, not between received and new values. Let's fix that in this same commit. Change-Id: I4e279a6b93fbcc5da25bf8c9213310939fd493ce
2019-12-05power_control.c: Log maximum allowed MS Power LevelPau Espin Pedrol1-6/+10
Change-Id: I983ff824ef6f54f1e800819d622158d5e2a51f04
2019-12-05rsl: Clarify when autnonoums MS Power Ctrl Loop is usedPau Espin Pedrol1-9/+6
Simplify when the fixed field is set in rsl_rx_chan_activ. Comment talks about enabling autonoumous control loop, but it is actually describing it when disabling it, which is confusing. Change-Id: Id6b444a33ab062f6dab11a0ce62d8aecaea87591
2019-12-04rach_pass_filter(): Add information about channel typeHarald Welte1-10/+11
When logging about filtering access bursts, let's indicate if this is on a CCCH, PDCH or handover related. Change-Id: I03f21f2b54cbe5aad36ac71a614d5df98867df80
2019-12-03rsl_rx_chan_act: Apply bitmask when parsing IE MS_POWERPau Espin Pedrol1-1/+1
Change-Id: I99c6a4d353f405582d5e4f9d12c01c25c7bb4dff
2019-12-02common/abis.c: use tall_bts_ctx as talloc-context for libosmo_abis_init()Vadim Yanitskiy1-1/+1
This way it's much easier to introspect the library internal talloc allocations from the VTY interface. Change-Id: Ic8d9fc7ce3da8abf0ea73d2b20366133cd801c37
2019-12-02common/abis.c: pass gsm_bts_trx to e1inp_sign_link_create()Vadim Yanitskiy1-4/+2
Change-Id: I8a6242d3e02f9bd19d287ecad18e001a5991175f
2019-11-30bts-trx: Drop low layer MS Power Control Loop algoPau Espin Pedrol5-207/+9
Let's drop it instead of having code duplication from common code in a lower layer, and maintain only the one in l1sap for all BTS models. As a result, osmo-bts-trx loses feature BTS_FEAT_MS_PWR_CTRL_DSP and will only be able to use "ms-power-control osmo" in VTY, which will be enabled by default (meaning: change of behavior, now MS Power Control is enabled by default in osmo-bts-trx and can only by disabled by BSC). Old bts-trx specific VTY command "(no) osmotrx ms-power-loop" is marked as deprecated but still working for more usual case (1 TRX configured) to avoid breaking backward compatibility. TA low level loop is still kept in loops.c and will be moved to l1sap at some point too. Related: OS#1851 Change-Id: I0d8b0c981d9ead91d93999df6e45fb06e426aeb9
2019-11-27scheduler_trx.c: cast ptrdiff value to fix printf formatPau Espin Pedrol1-1/+1
On an ARM toolchain: scheduler_trx.c:294:3: warning: format '%ld' expects argument of type 'long int', but argument 10 has type 'int' Let's cast it to long int to make sure correct size is applied in all platforms. Change-Id: I701b3dbc4e84db21cf02305d374b0df731e70313
2019-11-26common/vty.c: fix: properly assert() the result of get_string_value()Vadim Yanitskiy1-2/+2
Change-Id: I6ecd46371e601ad0fb629f9756b36c9c4758a958 Fixes: CID#205067, CID#205068
2019-11-22pcuif_proto.h: extend RACH.ind with TRX and timeslot number fieldsVadim Yanitskiy2-5/+10
Since there can be multiple PDCH channels configured on different timeslots, different TRXes, and BTSes, the PTCCH/U handling code in OsmoPCU needs to know the exact origin of a given RACH.ind. Otherwise, it is not known which subscriber originated a given PTCCH/U indication, and hence it is impossible to send PTCCH/D Timing Advance notification properly. Fortunately, we can extend the RACH.ind message without even bumping the protocol version, because every single PDU has a fixed size defined by the largest message - INFO.ind. In case if the actual message payload is smaller, the rest is filled with a constant padding byte (0x00). Older versions of OsmoPCU will consider the new fields as padding, while the messages from older OsmoBTS versions will always have both fields set to 0x00. Since C0/TS0 cannot be configured to PDCH, this can be easily detected on the other end. Change-Id: Iff38934a108b6b1cd298669834263a7d5296c3f6 Related: OS#4102, OS#1545
2019-11-20power_control.c: Limit speed of announced MS Power Level value changesPau Espin Pedrol1-4/+17
It's not a good idea to request big changes in MS Power based on sporadic bad signal received, let's instead change announced MS power levels more smoothly to avoid possible big signal strength fluctations, similar to what is already done in osmo-bts-trx specific loop (loops.c). Related: OS#1851 Change-Id: Iecc4ec7e21471ec853ad2d5659af4052aba5444c
2019-11-20power_control.c: Don't use announced MS Power level as input for loop ↵Pau Espin Pedrol2-25/+4
calculations Use instead the received MS Power currently in use by the MS matching the measured signal. This way there's no need to wait for the MS to reach the announced MS power level or add checks in case the MS doesn't support that specific power level. Furthermore, more fine grained announced power level value can be obtained faster due to more input iterations not being dropped while waiting. osmo-bts-trx specific algo was not following this approach and using announced MS power instead because it's wowrking at a lower level and henche was not using the transmitted MS Power level value by the MS as input for the calculation. The "if (diff < 2 && diff > -2))" condition is dropped since equal signal strength may still result in a different MS power level announced (the one currently used by the MS during tx of last SACCH block). Related: OS#1851 Change-Id: I4494dc27a295a3dca1d3331d4ff712d486643e13
2019-11-20osmo-bts-trx/trx_if.c: fix: NOPE.ind also contains C/I fieldVadim Yanitskiy1-5/+6
Change-Id: I201b72d2a6f5307ede252d5d707f1ebadafe6a4b
2019-11-20scheduler_trx.c: avoid division by zero when calculating BERPhilipp Maier3-4/+13
There is theoretical risk that when calculating the BER that a division by zero occurrs. Lets add a check to avoid n_errors / n_bits_total when n_bits_total is zero. Change-Id: I1c0731b9a60be4b8c0c84b85b4403168120ceacd Fixes: CID#205696
2019-11-19osmo-bts-trx/trx_if.c: also print both RSSI and ToA256 for NOPE.indVadim Yanitskiy1-3/+3
Change-Id: I36586ac33757705df16e14cfdd92becb96c8cf70
2019-11-19osmo-bts-trx/trx_if.c: fix: always initialize bi->burst_len for NOPE.indVadim Yanitskiy1-1/+3
A NOPE.ind indicates absence of an Uplink burst, thus it does not carry a burst. Let's init the burst length to avoid uninitialized memory access in the scheduler code. Change-Id: I77f686bf7df385215892e71733a28ff0d90d7222 Fixes: CID#205857
2019-11-19osmo-bts-trx: general handling of NOPE / IDLE indicationsVadim Yanitskiy2-8/+18
Each logical channel can now optionally have an additional handler, that will be called when a NOPE / IDLE indication is received from the transceiver. The aim of that handler is to keep the logical channel state updated in case if one or more Uplink bursts are lost. Change-Id: I71c552f44c25e56e9779d8b8ef5d4de9f8475637 Related: OS#3428
2019-11-14Introduce BTS feature BTS_FEAT_MS_PWR_CTRL_DSPPau Espin Pedrol8-4/+22
It indicates whether BTS model supports managing an MS Power Control Loop over HW/DSP instead of using the software based osmocom algorithm present in osmo-bts. osmo-bts-trx own loop implementation is considered to be a "DSP/HW" one since it acts on lower layers and interferes with osmocom algorithm since it controls the same end variable "lchan->ms_power_ctrl.current", this way we make sure both aren't enabled at the same time. Old behavior in kept: if common upper-layer algo is not enabled explicitly in VTY (ms-power-control osmo) and bts-trx specific lower layer algo is neither enabled (osmotrx ms-power-loop <xyz>), then no power control is done at all. Related: OS#1851 Change-Id: I49706926b1e962b18791174627bc3cc0cd0cd9d5
2019-11-14power_control.c: Fix ms pwr ctrl skipped if MS doesn't support announced MS ↵Pau Espin Pedrol2-2/+14
Power Level Related: OS#1851 Change-Id: I1a9c00fe4eb3fa1eaa7997a9ec20716ddfe180a7
2019-11-14power_control.c: Log rx current and target signal levelsPau Espin Pedrol1-4/+6
Change-Id: I31ce7930a1daa20a2ff81f31a37df94298c877d6
2019-11-14power_control.c: Apply latests improvements from loops.cPau Espin Pedrol1-45/+66
Several improvements have been made lately to MS Power Control loop from osmo-bts-trx in loops.c. Let's port these to the common algorithm. Related: OS#1851 Change-Id: I579967cc8bb69dc76a315c6c9d3a351f5961d92f