According to osmo-bsc I0e80ca5afc06737273b6699bde6e325e454b57f6, the
PAGING_COORDINATION feature should be well supported in osmo-bts. Adjust
the bts_model_init functions to report this to the BSC, so it properly
sets this in SI13 and so we can avoid this notice in the log:
Get Attributes Response: reported feature 'PAGING_COORDINATION' is not supported, while we thought it is.
Related: SYS#5922, OS#5538
Change-Id: Ib06829501f4221a7f7b0344ec7991ceba74e7641
Currently (without this patch) if tch_dl_dequeue() yields nothing we're
scheduling dummy FACCH/H *regardless* if it's permitted to start at the
given TDMA FN or not. This may result in misaligned FACCH transmission,
so the MS will not able to decode anything and will report BER>0.
With this patch applied we schedule FACCH/H if it's allowed to start
at the current TDMA FN; otherwise send half-filled bursts with even
numbered bits contaning 232 encoded bits of the previous L2 frame
and 232 odd numbered bits all set to 0.
This patch does not guard against sporadic gaps in the Downlink TCH
queue. However when tch_dl_dequeue() constantly yields nothing, e.g.
when we end up with a codec mismatch, then this additional check saves
us from starting misaligned FACCH/H transmission. If we start at a wrong
TDMA offset, then all subsequent FACCH frames will be scheduled at wrong
offsets and thus none of them will be decoded by the MS.
Change-Id: I6f8af140a6ccf3d5fd7b98f6cb5c18e2c5e2f61b
Related: SYS#5919, OS#4823
* dl_ongoing_facch must be set for correct FACCH/H scheduling;
* dl_facch_bursts must be set for FACCH overpower to work.
Change-Id: Ief12eb67ad80de3b71f5226858dc2e0c8ae76948
Related: SYS#5919, OS#4823
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
Oliver Smith
Vadim Yanitskiy
Pau Espin