aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-04-08power_ctrl_params_def_reset(): set .ctrl_interval for both UL/DL2022q1Vadim Yanitskiy1-5/+5
For the sake of consistency and code readability, initialize the power loop control interval (P_Con_INTERVAL) for both Uplink and Downlink directions in the same function. Change-Id: If7c804e51eb104d9fe73294a3867ab3b551d83c3
2022-04-08osmo-bts-trx: rx_tchf_fn(): clarify indexes in the AMR CMI lookup tableVadim Yanitskiy1-4/+11
Change-Id: If81ff0bd449fe20da43cc3d96dadf38568507054 Related: SYS#5916
2022-04-08osmo-bts-trx: rx_tchh_fn(): fix indexes in the AMR CMI lookup tableVadim Yanitskiy1-7/+15
In change [1] I didn't take into account that the TCH/H burst buffer is 6 bursts wide, and that we're decoding 2 bursts late: +---+---+---+---+---+---+ | a | b | c | d | e | f | Burst 'a' received first, 'f' last +---+---+---+---+---+---+ ^^^^^^^^^^^^^^^ Speech frame (bursts 'a' .. 'd') ^^^^^^^^^^^^^^^^^^^^^^^ FACCH frame (bursts 'a' .. 'f') The lookup table for TCH/H was calculated with the assumption that in rx_tchh_fn() the 'bi->fn' indicates TDMA frame number for burst 'd', but in reality it holds the frame number of burst 'f'. Change-Id: I4f22cf49fd52ed26f8017f76461059a701c181e1 Fixes: [1] I46def864729c8f9063af201750456771ea5558d5 Related: SYS#5916
2022-04-08osmo-bts-trx: move AMR CMI lookup tables to the respective filesVadim Yanitskiy3-18/+18
It makes no sense to have these tables in the header file, because they're not used anywhere outside of the respective lchan handlers. Change-Id: Ibdebfb9b1ef78c960b08240ebdb4c7af92cbed11 Related: SYS#5916
2022-04-07osmo-bts-trx: rx_tchh_fn(): fix meas reporting in signalling modeVadim Yanitskiy1-5/+7
In change [1] I broke measurement reporting for TCH/H in signalling mode. The problem is that in rx_tchh_fn() we started to invalidate the Uplink RSSI for FACCH regardless of the channel mode: speech or signalling. In speech mode, the averaged measurements are carried over by the two BFIs. In signalling mode we send no BFIs, so: * let's use the proper averaging mode S6N6 (not S6N4), and * send the averaged measurements together with the FACCH. This change fixes BTS_Tests.TC_meas_res_sign_tchh[_toa256]. Change-Id: If98aa1f0f7255f20344460bdd07e2c896dd6e56f Fixes: [1] I7902b4709bc3f418174e8373f52e87bb31cdc826 Related: SYS#5853
2022-04-07osmo-bts-trx: rx_{tchh,tchf}_fn(): use tch_mode directlyVadim Yanitskiy2-4/+4
There is no reason not to use 'chan_state->tch_mode' directly in the 'switch' statement. If a logical channel is in signalling mode, then both 'chan_state->{rsl,tch}_cmode' are set to RSL_CMOD_SPD_SIGN and GSM48_CMODE_SIGN, respectively. Change-Id: I9e5e2c891c80c32fc522b53c9371b71ea32dd54d Related: SYS#5853
2022-04-05osmo-bts-trx: rx_{tchh,tchf}_fn(): use AMR CMI lookup tablesVadim Yanitskiy3-12/+20
3GPP TS 45.009 defines that Codec Mode Indications shall be sent with speech frames having specific TDMA frame numbers of their *first* bursts, which are defined in tables 3.2.1.3-{1,2,3,4}. Performance-wise it's batter to have these tables implemented as arrays, rather then using the 'switch' statement. We can simplify things even further and have TDMA frame numbers corresponding to the *last* bursts in them. This eliminates the need of doing an additional last-to-first mapping, so that bi->fn can be used. Change-Id: I46def864729c8f9063af201750456771ea5558d5
2022-04-05osmo-bts-trx: rx_{tchf,tchh}_fn(): get TDMA FN from meas historyVadim Yanitskiy4-36/+38
Once we have an Uplink speech or FACCH frame decoded, we need to hand it over to the upper layers indicating TDMA frame number of the *first* burst corresponding to the beginning of a block. Currently we use libosmogsm's gsm0502_fn_remap() API to calculate the first TDMA frame number from the given last frame number. This API involves iterating over the pre-calculated offset tables for different channel and payload types, and thus imposes some additional CPU cycles. Another downside of the current approach is that we have to perform such lookups several times for each decoded L2 frame, e.g. for FACCH on TCH/AHS we do it three times! In this patch I propose an alternative approach of storing TDMA frame numbers in the measurement history, together with the associated samples. This way we can easily get N-th frame number from there without performing any additional computations, other than what we already do during the measurement processing. Change-Id: Id9a2b7b0f1a1ad7cfbbab862faf521e135c90605
2022-04-05osmo-bts-trx: rx_{tchf,tchh}_fn(): ensure complete set of burstsVadim Yanitskiy2-14/+14
The idea of this change is to avoid attempting to decode the burst buffer unless it's filled up completely. This eliminates expected decoding errors in the beginning of lchan's lifetime. Moreover this allows us to be sure that the measurement history is complete, so that we can abuse it to store TDMA frame numbers later. Note that even in the absence of NOPE indications (TRXDv0 case) we can still be sure that the burst mask has no gaps due to lost bursts, because they are compensated by trx_sched_calc_frame_loss(). Change-Id: I56bebe1374eb803e3c1e9f08dda4da50a074ab0b
2022-04-05osmo-bts-trx: rx_{tchf,tchh}_fn(): shift Rx burst buffer on bid=0Vadim Yanitskiy2-7/+6
For both TCH/F and TCH/H, the receive burst buffer needs to be periodically shifted leftwards due to the nature of block-diagonal interleaving. Currently we do this on receipt of bid=3 for TCH/F and bid=1 for TCH/H, right after attempting to decode the buffer. If for some reason we return early before attempting to decode the buffer, the content of that buffer might not be shifted and some bursts might be overwritten. This can be easily avoided by doing the shifting on receipt of bid=0 for both TCH/H and TCH/F. Change-Id: I0bd69f5a8f5c665fb5f00c127bc3fe1d91167abb
2022-04-05osmo-bts-trx: rx_{tchf,tchh}_fn(): also use meas_avg for BFIVadim Yanitskiy2-10/+4
In the current implementation of both TCH/F and TCH/H lchans, we set the 'bfi_flag' to true only if decoding fails. Perhaps this was not the case when I wrote [1], so using meas_avg might result in using uninitialized memory. This is not the case anymore. Pass the *averaged* measurememnts regardless of decoding result. Change-Id: I23f767364a018d30d04885990adf69b50b2c9738 Related: [1] I2b02b51fea5664f161382a4ddc63dbf14ffc9ac5
2022-04-05osmo-bts-trx: rx_tchh_fn(): get rid of chan_state->meas_avg_facchVadim Yanitskiy2-32/+7
FACCH/H takes out two speech frames, so we send two BFIs once we have received it in rx_tchh_fn(). The upper layers responsible for handling of the Uplink measurements expect a fixed amount of measurement samples, so currently we do: * send a FACCH frame with the associated measurememnts (S6N6), * send the 1st BFI with invalidated measurements (RSSI=0), * send the 2nd BFI with the stored measurememnts of FACCH. This is achieved by preserving a copy of the FACCH measurememnts in chan_state->meas_avg_facch and then using it two bursts later. The same goal can be achieved a lot easier by sending the associated measurements with both BFIs as if no FACCH was received: * send a FACCH frame with invalidated measurememnts (RSSI=0), * send the 1st BFI with the associated measurememnts (S6N4), * send the 2nd BFI with the associated measurememnts (S6N4). This eliminates the need to store anything outside of the existing measurement history and simplifies the code a lot. Also, this eliminates the need for using a dedicated averaging mode S6N6. Varified by running BTS_Tests.TC_meas_res_speech_tchh_facch. Change-Id: I7902b4709bc3f418174e8373f52e87bb31cdc826 Related: I1ad9fa3815feb2b4da608ab7df716a87ba1f2f91
2022-04-05osmo-bts-trx: rx_tchh_fn(): indicate BER10k=0 for FACCH BFIsVadim Yanitskiy2-6/+2
It makes no sense to store BER10k value of an Uplink FACCH frame in order to indicate it in a BFI later on. Given that these BFIs are generated artificially, it's fine to indicate BER10k=0. Change-Id: I24d12892760dca0ad0a5c2abca9fc66523d9e614 Related: I1ad9fa3815feb2b4da608ab7df716a87ba1f2f91
2022-04-04doc: rsl: Fix description of 'IP Connection Statistics' IEPau Espin Pedrol1-2/+2
Related: SYS#5915 Change-Id: Ic524d73a0c47fde528b78f9dfe7b72b7286550e1
2022-03-31fix gsm_bts_get_cbch(): CBCH can be allocated on CnVadim Yanitskiy1-10/+11
According to 3GPP TS 45.002, table 3, unlike the CCCH+SDCCH/4+CBCH combination, which can only be allocated on C0/TS0, the SDCCH/8+CBCH can be allocated on C0..n/TS0..3. In other words, having CBCH on e.g. C1/TS2 is perfectly legal. This is why in gsm_bts_get_cbch() we should check all transceivers, not just the C0. Without this change osmo-bts does not send CBCH Load Indications at all if the CBCH is allocated on C1..n. Change-Id: Ib5976783b53521047fbdfc18e0e236e8bce8eaae Related: osmo-bsc.git Ie79ccff4f8f0f1134757ec0c35e18b58081cc158 Related: SYS#5905
2022-03-22trx_sched_ul_burst(): get rid of the 'switch' statementVadim Yanitskiy2-10/+7
Both TRXC_RACH and TRXC_PTCCH are handled in the rx_rach_fn(), so we can eliminate the need of having a 'switch' statement in the general (perfrmance critical) code path. Change-Id: I66d8785a63215af37a77e258039549e4e6292e49
2022-03-18osmo-bts-trx: rx_tchh_fn(): use proper meas averaging modeVadim Yanitskiy3-2/+5
Compared to TCH/F, TCH/H is a bit special in a way that: * speech frames are interleaved over 4 consecutive bursts, * while FACCH frames are interleaved over 6 consecutive bursts. This is why in rx_tchh_fn() we allocate a buffer large enough to store up to 6 bursts. Let's say we have that buffer filled up completely with all 6 bursts (from 'a' to 'f'). Now attempting to decode them may yield either a speech frame or a FACCH frame: +---+---+---+---+---+---+ | a | b | c | d | e | f | Burst 'a' received first, 'f' last +---+---+---+---+---+---+ ^^^^^^^^^^^^^^^ Speech frame (bursts 'a' .. 'd') ^^^^^^^^^^^^^^^^^^^^^^^ FACCH frame (bursts 'a' .. 'f') For FACCH we use measurement averaging mode SCHED_MEAS_AVG_M_S6N6, so that 6 last samples are averaged - so far so good. For speech we use SCHED_MEAS_AVG_M_S4N4, so that 4 last samples corresponding to bursts 'c', 'd', 'e', 'f' are averaged - this is wrong. We actually need to average the *first* 4 samples corresponding to bursts 'a', 'b', 'c', 'd' in the case of speech. Let's add and use a new averaging mode SCHED_MEAS_AVG_M_S6N4 for that. Change-Id: Iea6f4e5471550f4c2b57aaebeac83c80e879489d
2022-03-18osmo-bts-trx: use a lookup table in trx_sched_meas_avg()Vadim Yanitskiy1-35/+18
This should be better performance-wise and would also allow to avoid having the same switch statement duplicated in functions added later. Change-Id: If8124dcd38e7c8408a9f3b9a574d9e3181a2eb15
2022-03-18osmo-bts-trx: use consistent naming for 'enum sched_meas_avg_mode'Vadim Yanitskiy6-21/+21
This is a purely cosmetic change. The new naming clearly indicates how deep to go back in the measurement history (S) and how many samples to average (N). For example: * SCHED_MEAS_AVG_M_S4N4 - go S=4 steps back and average N=4 samples; * SCHED_MEAS_AVG_M_S6N2 - go S=6 steps back and average N=2 samples. Change-Id: I96a8dd08084c7c179f879fc00e75c5edcfb11caa
2022-03-16osmo-bts-trx: rx_tchh_fn(): mark valid SID frames as suchVadim Yanitskiy1-1/+4
Set the FT (Frame Type) in the ToC (Type-of-Content) section as defined in section 5.2 of RFC 5993. Before this change SID frames had FT = 000 (Good Speech frame), because gsm0503_tch_hr_decode() does not distinguish between speech and SID frames internally. Change-Id: I09cec984bb60c754908126acf0300a2cc602485c Related: SYS#5853
2022-03-16osmo-bts-trx: rx_tchh_fn(): fix HR SID detection (wrong offset)Vadim Yanitskiy1-2/+4
According to RFC5993, which is referenced by 3GPP TS 48.103, the complete RTP HR payload consists of a Table-of-Contents (ToC) byte followed by the 14 bytes of the HR codec frame. See section 5.2. gsm0503_tch_hr_decode() outputs frames in the RTP format with length of 15 bytes (120 bits): 1 (ToC) + 14 (HR frame): +-------------+------------------------- | ToC section | HR codec frame ... +-------------+------------------------- osmo_hr_check_sid() expects a HR codec frame of 14 bytes (112 bits) as the input, so we should skip the ToC section when calling it. Change-Id: Ie5fa776dcb2b2203a97aed56ecbf2450af7d87c1 Related: SYS#5853
2022-03-14rsl: fix wrong IE being checked in rsl_rx_chan_activ()Vadim Yanitskiy1-9/+9
According to 3GPP TS 48.058, section 4.1.4, BTS shall start transmission on SACCH if both MS Power and *Timing Advance* IEs are present. There can be no Access Delay IE in the RSL CHANnel ACTIVation message. Change-Id: Icd8ccfd6e37ded8966125a473b5003845ba87fec Fixes: I170b63c9856230d5f1a10654a9d950ada8e730d7 Related: SYS#5838
2022-03-14osmo-bts-trx: rx_tchh_fn(): do not calculate BER10k for FACCH twiceVadim Yanitskiy1-1/+0
We already have BER10k calculated in the generic code path, so do not calculate it once again in the FACCH specific branch. Change-Id: I5d3955d09990e280d11d687385eeaf5edf437395
2022-03-10osmo-bts-trx: do not run osmo_{fr,hr}_check_sid() on FACCH/U framesVadim Yanitskiy2-3/+3
It makes no sense to perform the SID codeword lookup in signalling frames (FACCH), because it can be present only in speech frames. Change-Id: I2f8137993acfe8a8add3fc2af276e5eb4da1605e Related: SYS#5853
2022-03-09VTY: fix ambiguity in BTS specific command definitionsVadim Yanitskiy2-2/+2
Most of the BTS specific VTY commands restrict BTS number to '<0-0>', while bts_c0_power_red_cmd has '<0-255>'. This confuses libosmovty: OsmoBTS# bts ? <0-0> BTS number <0-255> BTS Number OsmoBTS# bts 0 ? % Ambiguous command. OsmoBTS# bts 0 c0-power-red 0 % Ambiguous command. Let's stick to '<0-0>', we don't support multiple BTS anyway. Change-Id: I937ac421143678b97627c1bc4fe573831ce097f6
2022-03-09osmo-bts-trx: new rate counter 'trx_sched:dl_fh_cache_miss'Vadim Yanitskiy3-1/+8
This new rate counter allows to monitor the efficiency of the radio carrier cache used for routing Downlink bursts when baseband frequency hopping is in use. Change-Id: Ie6da829e47298476267c8df2dcedafad564cbbb4 Related: SYS#5855
2022-03-09osmo-bts-trx: cosmetic: use rate_ctr_inc2() instead of rate_ctr_inc()Vadim Yanitskiy1-2/+2
Change-Id: Id4c5999876ff284b80a021e075bf46eb9d4670a2 Related: SYS#5855
2022-03-06osmo-bts-trx: make use of OSMO_UNLIKELY() when handling TRXD PDUsVadim Yanitskiy1-12/+12
Given how often we send and receive TRXD PDUs, I believe it maks sense to use OSMO_UNLIKELY() in the error checking conditions. Theoretically this should improve performance. Change-Id: I9266aaf2bbc0acfe21e9bfb12c9f38621d120553
2022-03-03bts-trx: Log lchan if avaialble in Meas AvgPau Espin Pedrol1-3/+5
Change-Id: I1460715fa46c4195c5aaac91be776ad770d8099e
2022-03-02rsl: Conditionally decrease log level if cause is normal eventPau Espin Pedrol1-1/+3
This avoid a NOTICE log line like the following when gsm_lchan_release() is called. """ rsl.c:2484 (bts=0,trx=0,ts=2,ss=0) Sending RTP delete indication: cause = Normal event, unspecified """ Change-Id: I0ce78c52644983220f5810bc5c661b07afd9e543
2022-03-02Change some log levels NOTICE->INFOPau Espin Pedrol2-4/+4
Change-Id: I65cccf2b48288353c2db2044ad1f3651ca9f68ec
2022-03-02bts-trx: amr: Fix return code of osmo_amr_rtp_dec() checked too latePau Espin Pedrol1-4/+4
If len is < 0, it means osmo_amr_rtp_dec() failed and some of the out variables there are not set. We should check the return code before continuing and using potentially uninitialized values. Change-Id: I76020c6b5dc8d3e52e8c5be8cdecdf8a0bb52ed9
2022-02-08logging: get rid of logging category DSUMVadim Yanitskiy6-14/+9
DSUM is somewhat similar to DMAIN, generic logging category used in other Osmocom projects. This category is rarely used in a few places, where the other categories could fit better. Remove it. Change-Id: Ia9db783bc92b23ba87b4fdf1e4ed07d59ea6bbce
2021-12-28phy_instance_destroy(): fix NULL pointer dereferenceVadim Yanitskiy1-4/+6
It's possible that a PHY instance has no associated TRX instance. Change-Id: Id028577ef92d1b3ce63ba62b63b8b29edb2ae5a4 Fixes: OS#5377
2021-12-14treewide: remove FSF addressOliver Smith1-4/+0
Remove the paragraph about writing to the Free Software Foundation's mailing address. The FSF has changed addresses in the past, and may do so again. In 2021 this is not useful, let's rather have a bit less boilerplate at the start of source files. Change-Id: I12b250e16426b125124def49e124e40ae93d0d58
2021-12-12cbch: cosmetic: use talloc_zero() in bts_process_smscb_cmd()Vadim Yanitskiy1-1/+1
Change-Id: Ibb5090b7cd53c1a485d0b9474c6470fa5831de67
2021-12-12osmo-bts-trx: fix a memleak in trx_sched_set_lchan()Vadim Yanitskiy1-0/+4
An additional burst buffer is allocated in rx_data_fn() for Uplink SACCH repetition, but unlike the main buffer it never gets free()d. Change-Id: I93310e7aed91a49c0511e2ed30e000440617f95a Fixes: I7e4cc33cc010866e41e3b594351a7f7bf93e08ac Related: OS#4795, SYS#5114
2021-12-12osmo-bts-trx: use l1ts as talloc context for burst buffersVadim Yanitskiy5-23/+10
Before a massive refactoring of the scheduler structures [1] it was impossible to have a clean hierarchy, in which the burst buffers get allocated as children of their parent timeslot structures. This change makes it easier to read talloc reports and simplifies memory management, offloading free()ing of the burst bufferes to talloc. Change-Id: Idb1ceaf83c433d2d0eb84d77c2187a00a657905c Related: [1] I7c4379e43a25e9d858d582a99bf6c4b65c9af481
2021-12-12oml: assign unique names to 'struct tlv_parsed' chunksVadim Yanitskiy1-0/+4
Change-Id: Ie248d2a65a11da914324a7e65b767b894ed8644a
2021-12-12oml: fix copy-pasted comments in oml_rx_set_*_attr()Vadim Yanitskiy1-4/+4
Change-Id: Iaa0e630b28b2a86312c069e7e55dd8bc5743759a
2021-12-12oml: use ts->trx as talloc-context in oml_rx_set_chan_attr()Vadim Yanitskiy1-1/+1
Change-Id: I6dc3706a486726afa9eec5d2e5369bd62c511455
2021-12-12oml: use proper talloc context in oml_rx_set_radio_attr()Vadim Yanitskiy1-1/+1
Change-Id: I69b6c72d85f68e4225d7786646f24259a5964998
2021-11-30debian/control: add osmo-bts meta-packageOliver Smith1-2/+17
Add an osmo-bts meta-package that depends on the subpackages osmo-bts-trx and osmo-bts-virtual. This is important, because the downstream packaging of debian does not split osmo-bts in subpackages, it has only one osmo-bts package. So without this, when installing "osmo-bts" in debian while having the Osmocom binary package repository installed and expecting to get the newer version, the user will actually get the older version from debian. Closes: OS#5319 Related: https://salsa.debian.org/debian-mobcom-team/osmo-bts/-/blob/master/debian/control Change-Id: I1a6edf2eb146616ac51b7957368a8d057caa685f
2021-11-25[lc15,oc2g,octphy] Fix memory leak on write queue overflowHarald Welte3-3/+16
Callers of osmo_wqueue_enqueue must always check the return value and free the message themselves in the error case. Change-Id: Ic67fbef23e419c0c8a7bcfb16d134e1bf649de72 Related: OS#5329
2021-11-24cbch: Fix dangling cur_msg leading to double-free in bts_cbch_reset()Harald Welte1-3/+3
If a new default message is installed via RSL, and the old default message is currently being transmitted, we must set cur_msg to NULL. The old default message must be talloc_free()d unconditionally whenever a new default message is being set. We can do that by using the TALLOC_FREE macro. Change-Id: Id32c2074b61cd1f09957b9d1558ffb3a7691a8e0 Related: OS#5325
2021-11-24cbch: Fix bts_smscb_state_reset() to avoid double-freeHarald Welte1-1/+4
If the currently transmitted message is the default message, bts_ss->cur_msg == bts_ss->derfault_msg. In this case we cannot simply talloc_free() both of them, as it would result in a boudle-free. Change-Id: I2d3645e34d31507b012a53ffe12d14223682f808 Closes: OS#5325 Fixes: Ib01d38c59ba9fa083fcc0682009c13d2db3664fe
2021-11-23bts: Properly free bts->shutdown_fi when struct gsm_bts is freedPau Espin Pedrol1-0/+4
Change-Id: I8c59f030c39c83a91b8504d4c5ce3b2058206fcf
2021-11-23bts_shutdown_fsm.h: Remove wrong comment describing enumPau Espin Pedrol1-1/+0
Change-Id: I963234255ce5a648a842ae6dbfd9966a694d0c09
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