It will be used too by osmux code present in another file. This is a
preparation commit to simplify the one adding osmux support.
Change-Id: Ie7fa57bb04db9ad9b03971467e12ee7b8e4c190a
There's no need to maintain a duplicate msgb_queue_flush(), which
returns the amount of freed messages (feature not used at all by the
callers).
Change-Id: I9841e18ca0b7b852130bbb02a510e43a3b3fd93f
The queue_limit_to method iterates the entire list of messages every
time a new message is added. Let's use msgb_{enqueue,dequeue}_count()
APIs to do that in constant time. It is true that since the queue is
limited to 1, there's usually at most 1 item in the queue so it's not a
real problem. However, when we add Osmux in the future, we may need to
tweak the amount of messages which can be in the list, due to Osmux
batching mechansim which may be more bursty sometimes.
In any case, this change doesn't make things worse for sure.
The patch also takes the chance to group the queue_limit_to + enqueue
into one function to avoid having the code spread several times.
Change-Id: I61818a3bb521c27bd21a8b6fa70581d27638ec9b
The logic responsible for enabling and disabling the loop appears
to be broken: during my experiments trx_loop_amr_set() was never
called with loop=1. It's not clear what's the motivation behind
this breaker, so I propose to rip it out for now. This patch
finally makes the loop work (confirmed with a TEMS phone).
Change-Id: I09b649973d4269c4082a4fafa493c37825f95a9c
Related: SYS#5917, OS#4984
Attempting to detect missing Uplink frames in the *Downlink* path
is an ugly hack, that was needed before we had proper per-lchan
detection of missing bursts and NOPE indications in TRXDv1.
* [1] per-lchan detection of missing bursts was fixed in Aug 2018.
* [2] TRXDv1 support was introduced in Jul 2019.
Today is 2022 and it makes no sense to keep this hack. Even if
the transceiver does not support TRXDv1, per-lchan detection
will compensate the missing Uplink bursts.
Change-Id: Ic292d180ba64206fb4d88adb284f9f9d058b4587
Related: [1] I70d05b67a35ddcbdd1b6394dbd7198404a440e76
Related: [2] If61c71d20d590bf07bfd019afb33000a0b6135bd
Looks like this structure was copied from openbsc/osmo-bsc as-is.
The ms_mode[] makes no sense in the context of BTS, so remove it
and rename bts_mode[] to mode[] for the sake of brevity.
Change-Id: I7442360ed857554440a0b9854f2d2bbab9dc5a71
Related: SYS#5917, OS#4984
This configuration will be used as a fall-back when the MultiRate
configuration IE is not included in the CHAN ACT/MODIFY messages.
Change-Id: Ie96af636105ee1ffe2d9a0bd9eea375faebad149
Related: osmo-bsc.git Ic5f8d55d250976d8d4c9cae2d89480fd52326717
Related: SYS#5917, OS#4984
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
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
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
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
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
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
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
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
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
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
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
Currently, only osmo-bts-trx is capable of reporting the interference
levels to L1SAP. Thus it does not make sense to trigger the averaging
logic and send empty reports over the A-bis/RSL and the PCUIF.
Change-Id: Ic17eb46bdca3c33ac4d6e560a093b635b75424a5
Related: SYS#5313
Starting from [1], interference levels on PDCH timeslots are also
reported over the A-bis/RSL. They may be useful for the BSC to
determine whether dynamic PDCH timeslots might be better used for
new circuit switched connections, or whether alternative PDCH slots
should be allocated for interference reasons.
* Handle GSM_LCHAN_PDTCH in lchan_report_interf_meas().
* Rework pcu_tx_interf_ind() to accept 'struct gsm_bts_trx'.
* Call pcu_tx_interf_ind() from l1sap_interf_meas_report().
Regarding pcu_tx_interf_ind(), it's better to call this function
from the upper layers once, rather than calling it from various
places in the model specific code.
[1] I5b4d1da0920e788ac8063cc765fe5b0223c76758
Change-Id: I3fbaad5dbc3bbd305b3ad4cb4bfb431a42cfbffc
Related: SYS#5313
It's cleaner from the architectural point of view to have the
interference measurements processed in a separate function.
Change-Id: I3981608e01a50585359cad673c38c8a305027d30
Related: SYS#5313
It may happen that the BSC requests logical channel activation on a
dynamic timeslot, which is in a process of switching from one pchan
type to another due to a preceding channel activation request.
In this case 'struct gsm_bts_trx_ts' already holds an msgb with the
preceding RSL CHANnel ACTIVation message, that is normally handled
once the PHY completes the process of timeslot re-configuration.
On receipt of subsequent RSL CHANnel ACTIVation messages, in function
dyn_ts_l1_reconnect() we overwrite the preceeding msgb (memleak), by
the most recent one. And once the timeslot re-configuration is done,
only the most recent CHANnel ACTIVation message gets ACKed.
In order to avoid this, let's move the msgb ownership to 'struct
gsm_lchan', so it cannot be overwritten by the CHANnel ACTIVation
message that is related to a different lchan on the same timeslot.
Change-Id: Ia625c2827fca883ea712076706d5ef21ed793ba6
Related: I3b602ac9dbe0ab3e80eb30de573c9b48a79872d8
Fixes: OS#5245
Let's split all lchan and power_control specific stuff into their own headers,
it helps finding out data and operations available related to them.
We already have similar classification in osmo-bsc.
Change-Id: I6424dcbd2e329fc1a516f8886359554ed7e9487e
Have a more stable loop with less temporary oscillations at the expense
of increased reaction time.
4 SACCH blocks (P_CON_INTERVAL=2) is the minimum interval to get stable
measurements for the last requested MS Power level. With P_CON_INTERVAL=1,
are also made during a period with stable power being use to transmit,
but the MS Power level used (and announced in MR) is not the last one
requested by the BTS, but the one requested in the previous loop
iteration. This can make the MS and BTS bounce 2 values forth and back,
and create some temporary oscillation.
See osmo-bsc User manual section "Power Control" for more information.
Related: SYS#5371
Change-Id: I91c505447f68714239a4f033d4f06e91893df201
It helps better understanding the code, and will allow handling
situations where for instance a POWERON in in transit while the BTS is
instructed to shutdown, hence a POWEROFF needs to be sent.
Change-Id: Iaf62217ceab7420afa4140cba61e1c2f983c61b4
Avoid re-connecting to a new BSC while BTS is in shutting down. All the
FSMs are complex enough to even try to re-start when stopping has not
yet finished...
Change-Id: I1727828a16f4ec8043b00cc6b2e02a4c35f71377
Prior to this patch, the power ramping started when the PHY is
available, but that doesn't necessarily mean the RCARRIER is enabled.
Due to this, it was spotted a situation where BTS bootstrap failed after
PHY turning up, when RSL connection establishment failed. Hence
bts_shutdown_fsm triggered a shutdown while an active power ramping up
was ongoing...
Change-Id: I17208b74ea2649b1bbb717aee0aa355e42b7e860
Pau Espin
Vadim Yanitskiy