Previously osmo-bts created /var/run/osmo-bts.pid which
isn't used by anything and makes it hard to run as non-root
user. Let's get rid of this pre-systemd relic.
Related: OS#4107
Change-Id: I86bcaedbc8cb1297476ad741eaa45585fea3c380
This library will be used soon when adding Osmux support to osmo-bts.
Furthermore, it nice to have it available to make use of other general
interfaces to create connections, primitives, RTP and AMR related
functionalities, etc.
Related: SYS#5987
Change-Id: I49db4de715065c083e1249cbeae6298d6868e229
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
The function is long/complex enough, so having one extra struct in_addr
declared the function top only used in one specific small path to print
the variable is unnecesary.
Let's move it to the conditional path where it is used to print the
ip address.
Change-Id: I4c16bbca6a6779537517b6b196828b47eddaa516
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
3GPP TS 45.008, section 8.3 defines active TDMA frame subsets for
TCH channels, which shall always be transmitted even during the
silence periods in DTX mode of operation. Each frame number
listed in this section corresponds to a single burst.
The Uplink measurements always contain TDMA FN of the *first* burst
of a block, so it does not make sense to match the given FN against
all FNs in the respective subset. Instead, we should match only
specific FNs in accordance with the block mapping rules defined in
3GPP TS 45.002, section 7, table 1.
In the active subset for TCH/F there is only one *complete* block
starting at FN=52. Incomplete blocks {52, 53, 54, 55} and {56, 57,
58, 59} contain only 50% of the useful bits (partial SID) and thus
~50% BER, so we don't treat them as SUB.
In the active subsets for TCH/H there are two *complete* blocks
for each sub-slot. Their respective first FNs can be efficiently
defined in a lookup table (see ts45008_dtx_tchh_fn_map[]). Note
that we can use a single lookup table for both sub-slots of TCH/H
because their TDMA FNs do not overlap.
This patch fixes unexpected SUB-RxQual values > 0 on TCH channels
with DTXu enabled and other than AMR (HR, FR, EFR) codec in use.
Change-Id: I8cc3a755a8ad4dc564439aab2298c1e97ac0592d
Related: SYS#5853
SACCH detection can be simplified by checking the RSL Link ID in
process_l1sap_meas_data(). This eliminates the need to lookup
the multiframe position by calling trx_sched_is_sacch_fn(), which
definitely takes more CPU time than just L1SAP_IS_LINK_SACCH().
Calling trx_sched_is_sacch_fn() is still required for BTS models
reporting the measurements via PRIM_MPH_INFO (legacy way),
separately from the related Uplink blocks.
This patch can be summarized as follows:
* detect SACCH and set .is_sub=1 in process_l1sap_meas_data();
** for PRIM_MPH_INFO use trx_sched_is_sacch_fn();
** for PRIM_PH_DATA use L1SAP_IS_LINK_SACCH();
* do not call trx_sched_is_sacch_fn() from ts45008_83_is_sub();
* modify the unit test - test_ts45008_83_is_sub_single();
** remove test_ts45008_83_is_sub_is_sacch().
Change-Id: I507e96ee34ac0f8b7a2a6f16a8c7f92bc467df60
Related: SYS#5853
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
The gitlog shows that these warnings were added in
744f745d7a by jolly (in 2012!).
As nobody has bothered for the past ten years, degrade them to comments.
Change-Id: Iebf9961cffbd7aa20b263f7dc0016a44782dec60
Related: osmo-bsc.git I9ef7e18f56aa86b48f0ffeec58406260736170f3
OsmoBSC assumed since If91d85331d402c3ab9c32b70c2c66cd7ba6ceb28 that
OsmoBTS has CCN (NACC, Network Assisted Cell Change). With OsmoBSC
Idf2d933aa8b03b1f708e56a08707fe6c620a97aa, instead of hardcoding some
features for OsmoBTS in OsmoBSC, only the features reported by the
BTS are used. Therefore report that BTS_FEATURE_CCN is supported in
OsmoBTS.
For previous OsmoBSC versions, this fixes the message:
Get Attributes Response: reported feature 'CCN' is not supported, while we thought it is.
Related: SYS#5922, OS#5538
Change-Id: Ic407e3be82afe61ed64b1cecf3dc94d2caff380a
I did not realize with my previous patch that there's a common place
where features available for all backends should be enabled. So move it
there.
Related: SYS#5922, OS#5538
Change-Id: Id688ddae5cd714355fcc5324f33c9397fecae261
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
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
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
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
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
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
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
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
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
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
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
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
Max
Pau Espin
Vadim Yanitskiy
Oliver Smith