No need to pass -t num_trx anymore to specify number of TRX to use. It
is calculated based on dynamic allocation from VTY config.
Using parameter -t is flagged as deprecated and is transformed into a
NOOP por backward compatibility.
As a result, TRX now are allocated after the BTS is allocated and
initial config (pre-VTY) is applied.
A new function bts_trx_init() is added, to set default config on each
TRX during allocation and before setting VTY config on it.
A new per BTS model function bts_model_trx_init() is added, to allow
per model specific default configuration of each TRX.
Change-Id: Iab1a754ab12a626759f9f90aa66f87bdce65ac9c
If chan_state->ongoing_facch is set, this code's logic
suggests that both msg_facch and msg_tch could be NULL.
Don't dereference msg_tch unconditionally.
Change-Id: Icf5584396c5b925d55ca9380dd4f869ae5d72da3
Related: CID#172047
This change modifies the logic of TDMA frame loss tracking. To
be more precise, the tracking logic was moved from per timeslot
level to per logical channel level, what makes OsmoBTS more
accurate in its measurements.
But before getting into details, it's important to clarify some
things about the Uplink burst processing in transceiver (OsmoTRX).
If an Uplink burst is detected, OsmoTRX demodulates it and sends
to OsmoBTS. If nothing is detected on a particular timeslot,
OsmoTRX will do nothing. In other words, it will not
notify OsmoBTS about this.
Meanwhile, there are usually a few logical channels mapped to a
single TDMA timeslot. Let's use SDCCH8 channel configuration as
an example (simplified layout):
/* SDCCH/8 (ss=0), subscriber A (active) */
{ TRXC_SDCCH8_0, bid=0 },
{ TRXC_SDCCH8_0, bid=1 },
{ TRXC_SDCCH8_0, bid=2 },
{ TRXC_SDCCH8_0, bid=3 }, // <-- last_fn=X
/* SDCCH/8 (ss=1), subscriber B (inactive) */
{ TRXC_SDCCH8_1, bid=0 },
{ TRXC_SDCCH8_1, bid=1 },
{ TRXC_SDCCH8_1, bid=2 },
{ TRXC_SDCCH8_1, bid=3 },
/* SDCCH/8 (ss=2), subscriber C (active) */
{ TRXC_SDCCH8_2, bid=0 }, // <-- current_fn=X+5
{ TRXC_SDCCH8_2, bid=1 },
{ TRXC_SDCCH8_2, bid=2 },
{ TRXC_SDCCH8_2, bid=3 },
SDCCH8 has 8 sub-slots, so up to 8 subscribers can use a single
timeslot. Let's imagine there are three subscribers: A, B, and C.
Both A and C are active subscribers, i.e. they are continuously
transmitting UL bursts, while B is not using ss=1 anymore.
The original way of TDMA frame loss tracking was the following:
- when an UL burst is received, store it's frame number in
the timeslot state structure (last_fn);
- when the next UL burst is received on same timeslot, compute
how many frames elapsed since the last_fn;
- if elapsed = (current_fn - last_fn) is lower than 10, then
iterate from (last_fn + 1) until the current_fn and send
dummy zero-filled bursts to the higher layers;
- otherwise (elapsed > 10), process the current burst,
and do nothing :/
According to our example, subscriber A is sending 4 bursts, then
nobody is sending anything, and then subscriber C is sending
4 bursts. So, there is a 4 frames long gap between the both
transmissions, which is being substituted by dummy bursts. But,
as the logical channel on ss=1 is not active, they are dropped.
This is not that scary, but the current algorithm produces lots
of false-positives, and moreover is not able to track real frame
drops in longer periods (i.e. >10). So, tracking the frame loss
per individual logical channels makes much more sense.
Let's finally drop this hackish 'while (42) { ... }', and track
the amount of lost / received TDMA frames (bursts) individually
per logical channels. Let's also use the multiframe period as
the loss detection period, instead of hardcoded 10. And finally,
let's print more informative debug messages.
Also, it makes sense to use the amount of lost / received bursts
during the calculation of the measurement reports, instead of
sending dummy bursts, but let's do this separately.
Change-Id: I70d05b67a35ddcbdd1b6394dbd7198404a440e76
Related: OS#3428
Before this patch it was being coded as SDCCH4 TS0 SS 0, and as a
result the state LCHAN_REL_ACT_OML applied in opstart_compl in abused
SDCCH4 TS0 SS 4 was not being checked when deciding whether to send a
Chan Act ACK in rsl_tx_chan_act_acknack.
Fixes: OS#3513
Change-Id: I1641960c9ffbb3ed0de74ab5b53e24e5b4ff3397
Previous implementation made no sense, since chan_nr is never read
before being set below from lchan_nr.
Furthemore, if lcahn_nr=CCH_LCHAN=4, then:
cbits = 0x4 + lchan_nr = 0x8 = b1000 which then becomes SDCCH8 according
to GSM 08.58 9.3.1, so it's totally wrong:
SDCCH/8 + ACCH 0 1 T T T
Change-Id: Id1dee716991e6faa406f02c029e998af5780162a
In the most cases a PDCH time-slot has only one logical channel
allocated. In case of both osmo-bts-trx and osmo-bts-virtual,
there are two kinds of logical channels: PDTCH and PTCCH,
but since they share the same chan_nr value, deactivating
one of them would trigger deactivation of another one.
Let's explicitly address the first logical channel in array.
Change-Id: I8edcb46e887c4db63a425eba89cec4374165763e
Closes: OS#3023
The existing implementation used a simplistic macro, which was wrong
in many ways:
1) it returned a negative value for "fn % 51 < 5" conditions without
raising any error message or asserting
2) it returned a wrong block number for many different input frame
numbers, as it didn't account properly for the FCCH/SCH gaps between
the blocks
Let's replace the simplistic macro with a proper lookup table based on
TS 05.02, and let's OSMO_ASSERT() if this is ever called with non-CCCH
frame numbers.
Change-Id: I11fd6cc558bb61c40c2019e46f56c1fe78ef39f5
Closes: OS#3024
* we have to use modulo 51, not 50
* the check for FACCH/SCH has to be applied to to the fn % 51 result
Change-Id: I540a7eeef3ea3ed7347f0f1b5a5a6fe7ce0ec8bb
The '--with-osmo-pcu' flag dates back to a time where the
'pcu_interface' header was not copied in both repositories
and you had to point one to the other.
Change-Id: I79e494484cb099cc9ca8c27c38b785c5ea8c3bc6
Closes OS#3514
The command implementation says "deprecated", so then the vty command attribute
should also be DEPRECATED. It will be hidden from online docs and vty
reference.
Change-Id: I23e620f1b947e129989fe69c6380c91b9abf7021
We used to permit multiple spaces to enter a new node in the config,
but modern osmo* code writes config files well-formed where every node
equals exactly one indent level.
Change-Id: I3da56b34e87503c46e6bf3c7505b83ec5e6aaa20
Fix compilation warning. At runtime it's not a big issue because the
"list" field is the first field of the led_list (struct
lc15bts_led_timer_list) variable. Hence, the address passed is the same.
Change-Id: Ib8bf07990800d74bfb3ad7a55eccfc65e40cd480
During the investigation of OS#3559, it was discovered that the
log message, which warns that an RSL message was dropped due to
inactive logical channel, has incorrect log level - LOGL_INFO.
This is not informative kind of message, so let's increase the
log level, and additionally let's print the hexdump of message
and it's length.
Change-Id: I26eac5e4466c493ffe08dbb89de20f5e1c2bb85d
As the CBCH replaces SDCCH sub-slot-2 in downlink, we should mark
the uplink as IDLE, just as the associated SACCH in uplink and downlink.
Also, there are no burst_numbers in IDLE slots.
Change-Id: Ib8565d1d0080bfce5d2aec77609709a445a2171c
Unfortunately the code in Icc15603079a1709ec094f400a9bcf0008211890f
was incomplete as it missed a few spots where the CBCH-enabled channel
types weren't yet covered.
Using this patch I can both still perform RACH / Location Update as
well as actually receive SMSCB messages on an attached phone (Galaxy S5).
Change-Id: I311b141668549ef37054cbe74be66bf17ac1d7e6
Closes: OS#1617
Closes: OS#3559
The CBCH (as per GSM specs) always maps on sub-slot 2 of either
the SDCCH/4 or SDCCH/8 that it replaces. However, the way how we
express it as RSL-style channel number (0xC8) doesn't allow room
for any sub-slots. The top 5 bits are used for expressing CBCH, while
the bottom 3 bits are used for the timeslot number (TN).
So when transforming from channel number to lchan, we must handle the
CBCH case specially by using a hard-coded sub-slot number of 2.
Change-Id: I44e2f763d5d25311167f435f2ca7e030b2a3f009
Related: OS#1617
This fixes a bug introduced in "CBCH: Move processing via L1SAP"
commit 02d99db08b
Author: Harald Welte <laforge@gnumonks.org>
Date: Fri Aug 24 23:37:45 2018 +0200
where the full channel number 0xc8 was used instead of the
(right-shifted) C-bits only.
Change-Id: I0fd8d7762e9cc3319a534f261e8857a1aa2220e0
It's very confusing if some log messages log chan_nr as decimal, while
most log it as hexadecimal. Let's standardize on hex everywhere.
Change-Id: Ia6566d5bbee8124fb7c689c962ce34d714208503
Also print a newline at the end of print_hwversion().
In the process of rewrite, fix several warnings in the few lines of this functions:
osmo-bts/src/osmo-bts-litecell15/main.c: In function ‘print_hwversion’:
osmo-bts/src/osmo-bts-litecell15/main.c:162:12: warning: passing argument 1 to restrict-qualified parameter aliases with argument 4 [-Wrestrict]
snprintf(model_name, sizeof(model_name), "%s Rev %c",
^~~~~~~~~~
model_name, (char)rev);
~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:168:12: warning: passing argument 1 to restrict-qualified parameter aliases with argument 4 [-Wrestrict]
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~~~~~~~~~
model_name, model);
~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:162:47: warning: ‘ Rev ’ directive output may be truncated writing 5 bytes into a region of size between 1 and 64 [-Wformat-truncation=]
snprintf(model_name, sizeof(model_name), "%s Rev %c",
^~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:162:3: note: ‘snprintf’ output between 7 and 70 bytes into a destination of size 64
snprintf(model_name, sizeof(model_name), "%s Rev %c",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
model_name, (char)rev);
~~~~~~~~~~~~~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:168:47: warning: ‘ (’ directive output may be truncated writing 2 bytes into a region of size between 1 and 64 [-Wformat-truncation=]
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~
osmo-bts/src/osmo-bts-litecell15/main.c:168:44: note: using the range [0, 4294967295] for directive argument
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:168:3: note: ‘snprintf’ output between 9 and 75 bytes into a destination of size 64
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
model_name, model);
~~~~~~~~~~~~~~~~~~
Change-Id: I079b056a04fe77d2f7f361ff5899232cb70b5a93
Fixes following compilation warning:
osmo-bts/src/osmo-bts-litecell15/lc15bts_vty.c:244:3: warning: implicit declaration of function ‘lchan_deactivate’
Change-Id: Id9b144d068d53393e1c1887aad285ae757156ec6
There is a big difference between both L1 and L2 frames. In the
first case, a TDMA frame is assumed, while a L2 frame is the
result of decoding a few bursts (e.g. 4 for xCCH) arrived
on a few TDMA frames.
Anyway, the purpose of l1if_process_meas_res() is to handle
measurements, not frames.
Change-Id: Ic4362c2869e658c2f42664b4009a30e777f8048c
The unit test that tests lchan_meas_process_measurement() only inputs
test data to lchan_meas_process_measurement() but it is not checked if
the interval end could be detected or not.
- Add a return code to lchan_meas_process_measurement()
- Ensure that the return code is checked in the unit-test
Change-Id: I9e00ce683e8c44528804f65181dbfed9e85e3aed
Related: OS#2975
The function is_meas_overdue() was introduced to allow
lchan_meas_process_measurement() to detect when the end of a measurement
interval has been missed. Interval ends may be missed when the SACCH
block of the related measurement interval gets lost. This is due to the
fact that the SACCH block is used as a trigger to start the measurement
result computation.
The idea behind is_meas_overdue() was to check the frame number of the
current measurement against the frame number of the previous measurement
in order to see if there was a measurement for SACCH in between or not.
Unfortunately SACCH and TCH Voice data is not necessarly processed in
order by each phy. Depending on the phy there may be a jitter between
the timing of SACCH and TCH Voice. Depending on the phy this jitter may
be enough to mess up the timing so that we see a SACCH block earlier
than expected. So we can not use the current frame number of TCH Voice
measurements to check for missed SACCH blocks.
Change-Id: Idfdbf64c1f965f35c12559b3995e2b746c74ee9e
Related: OS#3502
Related: OS#2975
Change cfg file names so they don't overlap when installing different
osmo-bts versions, and make systemd services look for correct new name.
Remove unneeded duplicated EXTRA_DIST files from root dir Makefile.am
Change-Id: I75fdd06cc52ce50628efb1f9b007d2e3926db27d
Convert the if-cascade to a switch().
For any unexpected pchan kind, reject the chan mode immediately instead of
going on to invoke gsm_bts_has_feature on feature = _NUM_BTS_FEAT, and log the
error.
Tweaked-by: neels
Change-Id: Ieaded9258554b15fcc4b7f05d5a8847175b7962f
Fix the chan mode checking for RSL Chan Mode Modif: do not reject
all modes on dyn TS.
In rsl_rx_mode_modif(), bts_supports_cm() should never
be fed with dynamic pchan kinds (e.g. GSM_PCHAN_TCH_F_TCH_H_PDCH).
Feed instead the return value of ts_pchan() that is to say,
the actual pchan type (e.g. GSM_PCHAN_TCH_F).
Change-Id: I7f0c835b25289931bccf96e982ea5564c8be4192
This patch adds scheduler support for the channel combinations that
substitute SDCCH index 2 for a CBCH in either a SDCCH/8 or SDCCH/4.
Change-Id: Icc15603079a1709ec094f400a9bcf0008211890f
Closes: OS#1617
for some historical reason, CBCH handling was not using the normal
L1SAP boundary. Let's change that and traverse L1SAP just like for
e.g. BCCH which is quite similar to CBCH handling.
This also has the added benefit of logging CBCH via GSMTAP.
Change-Id: Ibdba4c5e808330f8406f441a97fe0e81170fce97
Closes: OS#3534
Whenever a CBCH is used, this results in a new physical channel
combination on the relevant timeslot. The chan_nr_by_sapi() function
must handle those cbch-enabled PCHAN types.
Change-Id: I963909bcec8392ec445d0bcf53a2a8d7d9535444
Normally, the "Common Channel" related RSL messages should actually
contain such a common channel. However, since cell broadcast is
implemented inside what's essentially a downlink SDCCH, we should add
some explicit exceptions.
Before this patch, any RSL SMS BC CMD would have been discarded and
an RSL Error Indiciation returned.
Change-Id: I2f7f1dd43505cc27cd33489d8b0e8c981cd93880
Closes: OS#3533
Stefan Sperling
Pau Espin
Harald Welte
Philipp Maier
Keith Whyte