If set, chan_state->dl_ongoing_facch indicates that we're sending
the 2 (out of 6) middle bursts of FACCH/H. In this case there is
no room for encoding an additional frame, because both even and
odd numbered bits are occupied by a previously encoded FACCH/H.
Right after calling tch_dl_dequeue():
* do not check the dequeued message against NULL,
* do not compare the message length to GSM_MACBLOCK_LEN,
* immediately free() it and jump to the sending part.
Change-Id: Ib923b8f5cc1063e9fc18acd2bdd003fd09f4b70f
Related: SYS#5919, OS#4823
Unlike SACCH, FACCH has no dedicated slots on the multiframe layout.
It's multiplexed together with TCH (speech or data) frames basically
by replacing (stealing) them. This is common for both TCH/F and
TCH/H, with the only difference that FACCH/H steals two TCH frames
(not just one) due to a longer interleaving period.
Let's implement the multiplexing in the common function, which is
used to dequeue to be transmitted frames - this slightly reduces
code duplication. Use a new name, so that it's clear what it does.
Change-Id: I9822b1a17185d5487f0f6d3ed0203e806c053d7d
Related: SYS#5919, OS#4823
Manual analysis of code didn't end up in finding any issue, so this
seems a false positive (I can really understand gcc failing to do proper
job here, this function has way to many jumps here and there.
"""
/sched_lchan_tchh.c:88:13: error: ‘rc’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
88 | int rc, amr = 0;
| ^~
"""
Change-Id: Ifebaee63a9dad04976ffb4438c32360687ef095a
Keep collecting C/I samples even if the MS has not yet applied
previously requested codec mode. The C/I ratio is expected to
stay more or less the same, no matter which codec mode is used.
Change-Id: Ieb5473ead7200f652b5d0e339e4e252d6567482d
Related: SYS#5917, OS#4984
With the current implementation the AMR loop is unable to upgrade
the current codec mode unless it reaches the worst possible value.
The problem is in the 'else' statement connection both 'if's.
Change-Id: I4c0fb28813373c3d4addd28c66f5136d2c4f9ed8
Related: SYS#5917, OS#4984
Currently we're logging AMR mode *indexes*, not the actual modes.
Let's make it cleaner for the user by logging both mode and index.
Change-Id: I4feb3a3823799a290a50a48275e45f3331874d1a
Related: SYS#5917, OS#4984
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
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I18ebb7395024a490da743c0bcb20959e6e9c7017
This unit test demonstrates a problem in amr_parse_mr_conf(): the
threshold and hysteresis values are parsed incorrectly. They are
expected to match what we have in amr_fr_bts_mode_def[]:
Mode[0] = 0/13/4
Mode[1] = 2/25/4
Mode[2] = 5/37/4
This will be fixed in a follow-up patch.
Change-Id: Iab7e8878e62f598959e80fcb7e729b7f496962a2
Related: SYS#5917, OS#4984
Both misc_test_{SOURCES,LDADD} were simply ignored because
binary 'misc_test' is not listed in noinst_PROGRAMS...
Change-Id: Ia1739bab76261ff6d50824462b8ed2e0b34fb464
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
Normal blue (34) is really hard to read on terminals with dark
background. Let's use light blue (94) instead.
Change-Id: Iadc9b8fb74ec17455435893a532c2f12e02cb804
3GPP TS 48.058 defines the MultiRate configuration IE as optional,
and states that it's "included if the Channel Mode indicates that a
multi-rate codec is used". If I understand this correctly, it may
be omitted even if a multi-rate codec is requested. Otherwise it
would have been defined as a conditional IE.
For now let's print a warnig if this IE was expected, but missing.
We may need to apply some hard-coded defaults in this case.
If this IE is present, but the Channel Mode indicates a codec other
than AMR, let's send NACK with cause=RSL_ERR_OPT_IE_ERROR, assuming
that the CHAN ACT/MODIFY message is malformed.
Change-Id: I6ddc0b46a268ed56ac727cda57d0d68b2746fd59
Related: SYS#5917, OS#4984
There is nothing else except the AMR link adaptation loop in these files.
Change-Id: Iff2c0d32da5cd89824197d05f4732ce974c12f28
Related: SYS#5917, OS#4984
This check is redundant because it's guaranteed in rts_tchh_fn()
that FACCH/H is always scheduled at the correct frame offset.
Change-Id: I2f0c26f6007455aa1e3e8b27bc9d173f6b1f8c38
Related: SYS#5916, OS#5518
Since change [1], in rts_tchh_fn() we're using a lookup table for
DL FACCH/H. Let's do the same for UL FACCH/H in rx_tchh_fn().
Change-Id: I7c4e3befdd33bef4d89a04a4c7cb1a2d4078c156
Related: [1] I3dba243e5a1b7c8008ef0178ea18ed885256c50d
Related: SYS#5916, OS#5518
Unlike TCH/F, TCH/H imposes some additional requirements on the FACCH
transmission, so that a signalling block can be transmitted only at
specific TDMA frame numbers defined in 3GPP TS 45.002, table 1.
This is why in rts_tchh_fn() we need to check the given TDMA frame
number and tell rts_tch_common() whether FACCH/H is permitted or
not. The check is based on a magic formula, which I find a bit
hard to read and understand. Let's better use a lookup table.
Change-Id: I3dba243e5a1b7c8008ef0178ea18ed885256c50d
Related: SYS#5916, OS#5518
It's guaranteed by the calling function bts_model_l1sap_down() that
the prim's operation is PRIM_OP_REQUEST and that the msg is present.
Change-Id: I6a01bba7b5eb337ae1552c442d74447565c52e25
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Vadim Yanitskiy
Pau Espin