We already do the intereference measurements on inactive logical
channels. For the active channels we can still use the IDLE
slots, on which the UEs shall not transmit Uplink bursts.
Change-Id: Ic3030dba5eb223177298aa4e43559a93dc3d1392
Related: SYS#5313, OS#1569
In trx_sched_ul_burst(), treat all BURST.ind and NOPE.ind mapped
to inactive logical channels as interference. Average the RSSI
values on the fly using a sliding average with constant a=0.5.
Report averaged values for each logical channel every 104 TDMA
frames (SACCH period) by calling gsm_lchan_interf_meas_push().
Change-Id: I4686448e42a40df56c1d27a14fd0a4d43fd144a5
Related: I78b6d8beffa5228a28231b75728e7aebdd3cb23c
Related: SYS#5313, OS#1569
Starting from TRXDv2 [1], trx_if_send_burst() would keep batching
PDUs to the static buffer, unless it's called with br = NULL, so
we cannot dereference br in the logging statement.
Of course, we could also store TDMA frame number in a static
variable, but I don't think it's worth it just for logging.
Change-Id: I4a361777fc40bdedcebbe54df6274bc5573f77a8
Fixes: [1] I9b4cc8e10cd683b28d22e32890569484cd20372d
Fixes: CID#236232
Each timeslot can have its own Training Sequence Code value, which
may optionally be included in the NM_MT_SET_CHAN_ATTR message sent
over the A-bis/OML. If it's not present, then the TSC value for a
timeslot is derived from the BCC part of BSIC, which is always
included in the NM_MT_SET_BTS_ATTR message.
On the TRXC interface, the BTS global TSC value is indicated to the
transceiver using either of the 'SETTSC' or 'SETBSIC' commands.
The transceiver then applies this value for all timeslots by default,
however it can be redefined for each timeslot individually using
additional arguments of the 'SETSLOT' command (see section 25.2.4.1
in the user manual [1] for more details).
Currently, trx_set_ts_as_pchan() sends TRX_PROV_EV_CFG_TSC to the
transceiver provisioning FSM, together with the per-timeslot TSC
value. This event causes the FSM to modify the global TSC value,
that is going to be or has already been sent to the transceiver.
This is wrong, the global TSC value shall not be overwritten.
Remove the TRX_PROV_EV_CFG_TSC, and include per-timeslot Training
Sequence Code and Set in the data structure that gets passed together
with the TRX_PROV_EV_CFG_TS instead. Implement handling of the
optional per-timeslot TSC in trx_if_cmd_setslot().
[1] https://downloads.osmocom.org/docs/latest/osmobts-usermanual.pdf
Change-Id: Idc5796151e3e83f42d60c2d4cb7c35890d76a7f5
Related: SYS#4895, OS#4941
The TSC (Training Sequence Code) value in 'struct gsm_bts_trx_ts'
is always initialized in oml_rx_set_chan_attr() during the OML
bootstrapping, so there is no need for gsm_ts_tsc() - remove it.
Store the initial TSC value in 'struct gsm_bts_trx_ts', so we can
apply a different TSC value during the RSL CHANnel ACTIVation.
Store the Training Sequence Code/Set in 'struct trx_dl_burst_req'.
These values are indicated to the transceiver (TRXDv2 PDUs, 'MTS'
field) and used by the new TRX_{GMSK,8PSK}_NB_TSC macros.
Change-Id: I3744bc308b99ef941e6e9d139444e414abebc14b
Related: SYS#4895, OS#4941
This change implements TRXD PDU batching approach b), which is described
in section 25.3.4 of the user manual [1]. This approach is quite easy
to implement on the transceiver side, so we can enable it by default.
.Example: datagram structure for combination b)
----
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=0 | BATCH=1 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=1 | BATCH=1 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=2 | BATCH=1 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=7 | BATCH=0 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
----
Other PDU batching approaches can be introduced later.
[1] https://downloads.osmocom.org/docs/latest/osmobts-usermanual.pdf
Change-Id: I9b4cc8e10cd683b28d22e32890569484cd20372d
Related: SYS#4895, OS#4941
In [1] I forgot to update tx_fcch_fn(), where we assume that the
burst buffer is already zero-initialized and do not call memset().
This results in sending dummy bursts on FCCH (instead of zeros).
Change-Id: I491b3b5702b3cfca45c12c002b41e60c629b05b9
Fixes: [1] Iec78989517865b3275a9784d1042a5ebd1d2815f
Currently, in bts_sched_fn() we send a Downlink burst to the PHY
immediately after calling the associated logical channel handler.
Together with the obvious performance advantages, this approach
imposes some serious limitations. The code has already become
quite complex with the introduction of the baseband frequency
hopping, and now it's not possible anymore to extend it further.
TRXD PDU batching, which is essential for VAMOS implementation,
requires us to make the scheduler more flexible at the expense of
increased memory consumption and additional CPU cycles. This patch
splits up Downlink burst scheduling into 3 main steps:
1. bts_sched_init_buffers(): initialization of per-TRX Downlink
burst buffers allocated by phy_instance_create(). For C0/TRX0
all timeslots are pre-initialized with dummy burst.
2. bts_sched_fn(): generating burst bits for all active lchans.
3. bts_sched_flush_buffers(): sending everything to the PHY.
This approach allows us to a) get rid of the ugly tail in bts_sched_fn()
that was responsible for sending dummy bursts on C0/TRX0; b) implement
the PDU batching and have several variants of bts_sched_flush_buffers()
providing the alternative batching approaches later on; c) implement
PDU merging for the upcoming shadow transceivers.
Change-Id: Iec78989517865b3275a9784d1042a5ebd1d2815f
Related: SYS#4895, OS#4941
We assume that it's legal to have dangling PHY instances that are
not associated with any TRX instances in the configuration file.
Obviously, such PHY instances have pinst->trx set to NULL.
The DSP based models seem to handle dangling PHY instances without
any problems, so let's ensure that we always check pinst->trx
against NULL in the osmo-bts-{trx,virtual} specific code.
Change-Id: Ib7d9cb7ae47fead723fa46454cd64bf6e88756bb
Fixes: CID#236092 "Dereference before null check"
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
In change [1] together with the actual implementation I introduced
a serious bug to bts_sched_fn(): if a timeslot is configured to use
frequency hopping, both 'pinst' and 'l1h' pointers are *overwriten*
in the inner loop, so the Downlink burst is re-directed to the
approproate PHY instance. However, if a subsequent timeslot is not
hopping, the Downlink burst would be re-directed to the wrong PHY
instance because both pointers were overwriten during a previous
iteration.
Let's move the 'struct phy_instance' pointer to the inner loop, so
it's properly re-initialized for each timeslot iteration.
Change-Id: I9afbbef8dc5d885763356470c27d4392dce8e815
Fixes: [1] I68f4ae09fd0789ad0d8f1c1e17e17dfc4de8e462
Related: SYS#4868, OS#4546
trx_phy_instance() does assert() that the given TRX pointer is
not NULL. In bts_sched_fn() it can never be NULL, so drop it.
Change-Id: I896ff5117588f2229cc54619ce62fd027a9ef25f
Historically the logical channel handlers like rx_data_fn() used to accept
quite a lot of arguments. With the introduction of additional measurement
parameters it has become clear that we need to group the arguments into
structures. This is why both 'trx_{dl,ul}_burst_{req,ind}' structures
were introduced.
However, both channel type and burst ID were kept untouched, so until
now we had them being passed between the scheduler functions here and
there. This change is a logical conclusion of the original change
mentioned above.
As a part of this change, the new LOGL1SB() macro is introduced. It
does accept a pointer to 'trx_{dl,ul}_burst_{req,ind}' and expands the
context information for the old LOGL1S() macro.
Change-Id: Ic5a02b074662b3e429bf18e05a982f3f3e7b7444
First of all, there is no reason to use a void pointer because
it's always 'struct phy_instance'. Also, no need to encapsulate
this pointer into 'role_bts' because there are no other roles in
osmo-bts (we used to have shared headers years ago).
This commit also fixes a bug in test_sysmobts_auto_band(), where a
pointer to 'struct femtol1_hdl' was directly assigned to trx.pinst.
Change-Id: I9bd6f0921e0c6bf824d38485486ad78864cbe17e
For a long time, we see this annoying -Wstringop-truncation warning:
In function ‘parse_rsp’,
inlined from ‘trx_ctrl_read_cb’ at trx_if.c:647:6:
trx_if.c:416:2: warning: ‘strncat’ output may be truncated copying
between 0 and 45 bytes from a string of length 1495
416 | strncat(rsp->cmd, buf_in + 4, p - buf_in - 4);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is no real need to use strncat() in parse_rsp(), because we
do not concatenate any strings but simply copy TRXC response parts
from the input buffer to the corresponding 'name' and 'parameters'
buffers. Let's use memcpy() instead. This also fixes the warning.
Change-Id: Ia10adf7d76abe9a423b07e828852fbfb53b95125
If the PHY is not powered on and we are not supposed to send any
bursts to it, then trx_if_send_burst() should just return early.
Change-Id: I578bd5a731ad88ebff283c75bb7eb268d9e7e787
Related: SYS#4895, OS#4941, OS#4006
If somehow the TRXC logic negotiates a non-supported TRXD PDU version,
then it's a serious bug in the code. Let's add an assert() for that.
Change-Id: I301377bcebd5e2bbcfc18b3637253ef261bb5b2e
Starting from TRXDv2, several PDUs may be batched together and sent in
all together a single datagram. This requires us to increase the buffer
size that we use for sending and receiving TRXD messages. Let's use
65536 matching the default MTU value for 'lo' interface on Linux.
Given that 65536 is quite a big number, let's allocate a shared Rx/Tx
buffer statically to avoid [potential] stack overflow.
Change-Id: I729451c8ecdc7ff2631beb423f15523db16b3ee3
Related: SYS#4895, OS#4941, OS#4006
This is a preparatory change for the upcoming TRXDv2 support:
* move common TRXDv0/v1 header parser into a separate function;
* move burst handling into a single, version independent function;
** determine modulation and burst length in trx_data_parse_pdu_v0();
Change-Id: I7aedd85a8d4f6d6191cd3b75272a688208fb2879
Related: SYS#4895, OS#4941, OS#4006
All these functions need the PHY instance pointer for logging,
they don't really need a pointer to 'struct trx_l1h'.
Change-Id: I626b4392a8bc57a3fe5e8c931aa1ce9dd505676c
Related: SYS#4895, OS#4941, OS#4006
The 'CHDR' stands for 'Common Header', but this does not apply to
TRXDv2 because TDMA frame number may not be present in the batched
PDUs. Let's avoid potential confusion by removing it.
Change-Id: I80495df474c432f4c0a4cfa6f917821d7b35859a
We do have TRXC/TRXD documentation in osmo-gsm-manuals repository.
This big comment is out of sync with what we have in the manuals,
so let's better remove it to avoid maintaining docs in several places.
Change-Id: Ibfcefcbb5f30fe9b6c691578a93e6fedd5644b30
Related: SYS#4895, OS#4941, OS#4006
TRXDv2 brings significant changes to the whole PDU structure, not
just the header. Let's highlight this in the code / strings.
Change-Id: Id0274bd1ae5c419548596ed1852e6a28ec62b713
Related: SYS#4895, OS#4941, OS#4006
* Calling l1if_provision_transceiver_trx() yelds nothing.
* It does not apply immediately, full restart required.
Change-Id: I93c9e19d0543f19528cec842b8be332b4d93214e
If for whatever reason it fails to initialize the TRXD or TRXC
interface, trx_phy_inst_open() would return an error. This
would cause bts_model_phy_link_open() to call trx_if_close()
on each of the PHY links, including those that were never
opened. This leads to a segfault in trx_if_close().
Make sure that in trx_if_init() we properly init 'struct trx_l1h',
so it's safe to call trx_if_close() at any time and in any state.
Change-Id: I1f128813528f505fede04799e84456f6271058d0
The measurement results / TCH indications that are handed when decoding
the TCH/H are off by two bursts. Since a measurement result / TCH block
is expected every two bursts anyway the problem can only be noticed when
a FACCH transmission is going on and the frame numbers of the BFI TCH
blocks appear to be missaligned towards the FACCH block.
The reason is that the incoming bursts are shifted into a 6 burst wide
buffer. The decoding functions always look at the beginning of that
buffer while the bursts are shifted into the buffer from the end. A
facch will always fit exactly in that buffer but TCH/H blocks are only
4 bursts wide and thereofre they need two additional bursts until they
reach the coverage of the decoding function. Lets fix this by putting
the correct frame number (from two bursts before) into the remap
functions in order to get the correct beginning of the block.
Since the FACCH transmission uses six blocks it takes out two TCH
blocks. This means that if we count the FACCH block we end up with a gap
of one TCH voice block. Lets generate a dummy measurement to compensate
the gap. This will also match the behavior of the osmo-bts-sysmo phy.
Change-Id: I1ad9fa3815feb2b4da608ab7df716a87ba1f2f91
Related: OS#4799
By reordering the instruction, we scheduler the timerfd prior to
processing the FN on the upper layers. This means the first timerfd
expiration even will happen more inline with the expected time, that is,
CLOCK IND time + GSM_TDMA_FN_DURATION_nS.
Let T(trx_sched_fn) be the time spent executing function trx_sched_fn().
With previous order, the timerfd would have been scheduled later, which
in the end would mean expiration would happen at time CLOCK_IND +
GSM_TDMA_FN_DURATION_nS + T(trx_sched_fn), hence ending up with an extra
skew of T(trx_sched_fn) added by ourselves.
This extra skew added may be important specially at startup time (when
this code path is used), since usually the load in the system is high
and skew is usually already higher, which means helping crossing
unacceptable thresholds which may end up in osmo-bts-trx stopping with
"No clock from osmo-trx" reason.
Change-Id: Ie2ba35cd87f0bd4078ac3b4b5ec2eacad36c4258
These fields are always aready set by the only caller of the function
trx_setup_clock(), so there's no use in re-setting them.
Change-Id: Id8a7141984e07eb11abae08e0c63ae7ebc333511
It can happen that the first burst we receive after enabling the PDCH
channel (when PCU connects to the BTS) is bid!=0. As a result,
chan_state->ul_first_fn is never set and defautl value 0 in there is
passed to the upper layers. As a result, when the 2nd block is
transmitted, this time with correct FN, the PCU will see a huge jump in
FNs. Since in PDCH the bursts are always consecutive, let's simply use
bi->fn - 3 as a first_fn and be done with the issue.
Related: OS#5020
Change-Id: Ie982caeb29f3ffd880b44e88a89b85ea3e6e6947
Similar to what we have been doing for TCH channels, we want to make
sure all MAC blocks get to the upper layers, even if containing invalid
data (flagging it with data_len=0) so that upper layers (osmo-pcu
through PCUIF in this case) can rely on FN clock without gaps due to
Rx errors.
Related: OS#5020
Change-Id: I343c7a721dab72411edbca816c8864926bc329fb
In change [1] the new power control structures and default params
were introduced. In change [2], the existing VTY commands for MS
power control in the BTS were deprecated and changed to use the
new structures as storage. Finally, in change [3], handling of
the power control parameters on the A-bis/RSL was implemented.
This change is the final logical step in the mentioned chain: it
makes both MS/BS power control loops use the new parameters, and
removes the old structures. The actual implementation of both
power control loops remains the same, however the expected output
of some unit tests for the Downlink loop needs to be changed:
- TC_fixed_mode: disabling dynamic power control becomes a separate
step of the test script since the field 'fixed' is removed;
- TC_rxlev_target: RxLev thresholds are printed 'as-is'.
Not all of the new parameters are used by the power control loops
yet. Further improvements to be done in the follow up commits.
[1] I6d41eb238aa6d4f5b77596c5477c2ecbe86de2a8
[2] Icbd9a7d31ce6723294130a31a179a002fccb4612
[3] I5a901eca5a78a0335a6954064e602e65cda85390
Change-Id: Ib18f84c40227841d95a36063a6789bf63054fc2e
Related: SYS#4918
When [baseband] frequency hopping is in use, Downlink bursts from
additional transceivers may end up being transmitted on TRX0/C0.
In this case, we must not apply per-lchan attenuation, because
the BTS shall maintain constant power level on that TRX.
Change-Id: Id171df70447283b00da965e1f81dfac20e35495c
Related: SYS#4918
3GPP TS 44.006, section 11 describes a method how the uplink
SACCH transmission can be repeated to increase transmission
reliability.
Change-Id: I7e4cc33cc010866e41e3b594351a7f7bf93e08ac
Related: OS#4795, SYS#5114
3GPP TS 44.006, section 10 describes a method how the downlink
FACCH transmission can be repeated to increase transmission
reliability.
Change-Id: I72f0cf7eaaef9f80fc35e752c90ae0e2d24d0c75
Depends: libosmocore I6dda239e9cd7033297bed1deb5eb1d9f87b8433f
Related: OS#4796 SYS#5114
Now bts_model_vty_init() must be called only once, otherwise the
process would crash when bts_model_init() is called from main().
Change-Id: I262c39896b5db86c54ad9aa7042c7ca6657815d9
Related: SYS#4937, OS#3036
Similar to bts_vty_init(), BTS specific bts_model_vty_init()
requires a pointer to 'struct gsm_bts'. Not only it's used
as a parent talloc context, but also stored locally, so then
it can be used by some VTY commands.
Let's expose the global 'struct gsm_bts' from main, and pass
the application's talloc context like was done in [1].
This finally makes the BTS model specific options appear in
the automatically generated VTY reference (--vty-ref-xml).
[1] Ic356a950da85de02c82e9882a5fbadaaa6929680
Change-Id: Iee7fee6747dd1e7c0af36f9b27326f651ae37aaf
Related: SYS#4937, OS#3036
When the FACCH is generated (while in SPEECH mode), there is also a
fake speech indication handed up to l1sap.c. We must make sure that only
one of the two indications carry a measurement value, so lets invalidate
the measurement values (RSSI in particular) for the generated TCH
indication.
Change-Id: Ie3f2e620ba2a2ab2fecdbae627ef01c6128fce0b
Related: OS#4799
All the Operative State logic to manage a RadioCarrier//BBTransc NM objects is
centralized in these FSM, where other parts of the code simply send
events to it.
This allows keeping state consistent and offloading logic from each bts
backend, since they are only required to submit events now.
The idea in the long run is to also replace other NM objects with
similar FSMs.
This improved logic fixes bug where PHY + RSL link became available before
OPSTART and hence op state changed to Enabled before receiving any OPSTART message.
Change-Id: Ifb249a821c4270918699b6375a72b3a618e8cfbe
This fixes old behavior mimicing broken behavior in nanoBTS (according to TS 12.21)
where BTS Site Mgr NM object was announced as Enabled despite no OPSTART
was sent by the BSC.
With this new FSM, BTS SiteManager will be announced as Disabled Offline
during OML startup conversation, instead of Enabled.
The new osmo-bsc OML management FSMs use this change in behavior to find
out whether it should use the old broken management states (without
Offline state, as per nanoBTS) or use the new state transitions (which
allow fixing several race conditions).
Change-Id: Iab2d17c45c9642860cd2d5d523c1baae24502243
This fix allows osmo-bts to play fine with newer osmo-bsc NM OML FSMs,
which expectes for non-nanoBTS types to follow TS 12.21 guidelines.
Until now, BSC simply waited to received State Event Change Dependency
for each TS and then sent all required commands (Set Chan Attr, Adm
Unlock and Opstart). In newer osmo-bsc FSMs, Opstart is only sent when
in Offline state, so we need to transit to that state. For the above
mentioned reason, since we pass through the Dependency state anyway
after this patch, older osmo-bscs will work correctly too.
Change-Id: Id9e61f8d773e6e6170c68b5b836d276c747d8d69
in function rx_tchh_fn() the variable meas_avg is not initalized. This
is not always a problem, since most of the time trx_sched_meas_avg() is
populating the variable properly. In cases where a FACCH is transmitted
(chan_state->ul_ongoing_facch = true) the variable is left unpopulated.
In order to have at least stable values for those cases, initalize the
variable with zeros for the ongoing facch phase.
Change-Id: I5c3c1c41d22f9edaaf6bd4478dd04f090dca12a9
Fixes: CID#214480
Make sure that we pick the correct UL measurements from the
history when we deal with AMR SID frames (SUB frames).
Change-Id: I902bb47d68742d2589156f61099b67a0edbaf40b
Related: OS#2978
Currently the UL measurements (RSSI, ToA256, C/I) of the burst that
concludes a block are passed up to the higher layers. This means
that the measurement values of the other bursts are skipped.
Let's keep record of all UL measurements and average the values
before we pass them up to the higher layers. Use a simple ring
buffer to store the measurement history (up to 8 unique entries
for now). Remove *_num/*_sum variables from l1sched_chan_state.
Change-Id: I2b02b51fea5664f161382a4ddc63dbf14ffc9ac5
Related: OS#3032, OS#2978
MA (Mobile Allocation) is actually a bit-mask indicating those ARFCNs
of the Cell Allocation, which must be used as the hopping sequence.
What we store in struct gsm_bts_trx_ts is the actual list of hopping
channels, so let's name it properly and eliminate possible confusion.
Change-Id: I677d66e428fa0fe119ebc37bc2a4e6cc05c251c4
In general, it is always set to 1 (Locked) in
st_open_poweroff_on_enter() right after initial POWEROFF, and once the
BSC unlocks it (based on VTY cfg "rf_locked (0|1)") by sending an OML
message, the bts_model_chg_adm_state() call will update it sending
RFMUTE.
This basically fixes the case where osmo-bsc.cfg is configured with
"rf_locked 1" to start with a TRX locked until manually unlocked.
Related: SYS#4920
Change-Id: I96b64cdc901d6f216df628d7be57a67af4a21e25
Since commit 221ee92551,
bts_model_trx_deact_rf() was being called when RF locking the TRX, which
was implemented by resetting the scheduler. This proved to be a messy
and wrong way to emulate disabling RF, since it modifies tate on lots of
structures from which it is later difficult to recover from, causing
bugs and issues like:
82a35a1dbfbe15a12c87eef420d1cahttps://osmocom.org/issues/4694https://osmocom.org/issues/4695https://osmocom.org/issues/4696https://osmocom.org/issues/4697
So for all these reasons, it is believed a good solution to avoid
resetting the scheduler and simply ask lower layers (osmo-trx) to take
care of disabling RF TX/RX on a given TRX. For TRX implementations not
supporting the newly added RFMUTE command, ramping down to -10dBm still
provides for a way to emulate RF locking. In any case, none of this was
supported until recently so it's not like we are breaking some feature
here.
Related: SYS#4920
Change-Id: I1423ddb390ef327ec7d4a27de2ac5dca663773a5
It was reported that both osmo-bsc and osmo-bts-trx may end up
running in a half-broken state, when everything looks good and
the UEs can see the network, but all channel requests get
rejected due to "trx not usable" error:
lchan_select.c:173 (bts=0) lchan_select_by_type(SDCCH)
lchan_select.c:48 looking for lchan CCCH+SDCCH4: (bts=0,trx=0) trx not usable
lchan_select.c:48 looking for lchan SDCCH8: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select SDCCH channel
lchan_select.c:173 (bts=0) lchan_select_by_type(TCH_H)
lchan_select.c:48 looking for lchan TCH/H: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select TCH_H channel
lchan_select.c:173 (bts=0) lchan_select_by_type(TCH_F)
lchan_select.c:48 looking for lchan TCH/F: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select TCH_F channel
As was then figured out, this happens because the Radio Carrier
MO (Managed Object) remains Disabled even after the BSC has
sent OPSTART and the BTS ACKed it:
oml.c:986 OC=RADIO-CARRIER(02) INST=(00,00,ff): Rx OPSTART
l1_if.c:614 Rx OPSTART for RADIO-CARRIER MO
l1_if.c:201 TRX_PROV(phy0-0)[0x1238c0]{OPEN_POWERON}:
Event TRX_PROV_EV_CFG_ENABLE not permitted
oml.c:144 OC=RADIO-CARRIER(02) INST=(00,00,ff): Tx Opstart Ack
It remains a mistery why the TRX_PROV FSM is already in state
OPEN_POWERON, while it's expected to be in state OPEN_POWEROFF,
but we definitely should not ACKnowledge the OPSTART if this
happens. Send a NACK instead with cause NM_NACK_CANT_PERFORM.
Change-Id: I8727460acbf850b84df67a9cbdc25b47dee1fadd
Related: SYS#5063
We already get quite informative message originated from oml.c:
OC=RADIO-CARRIER(02) INST=(00,00,ff): Rx OPSTART
Change-Id: I3d4a4473541327488d3393b1fa7c6391afb3728a
osmotrx fn-advance (which is the clock_advance variable here) and
osmotrx rts-advance together make up the minimum delay the BTS can react
to a channel request, etc.
The default of 20 are around 92ms which is clearly too much. With
modern hardware and using SCHED_RR a lower value should not be an issue.
See OS#4487 for some related measurements on more CPU-limited devices like a
LimeNet-micro3.
Fixes: OS#4487
Fixes: SYS#4885
Related: SYS#4881
Change-Id: I7da3d0948f38e12342fb714b29f8edc5e9d0933d
The idea behind the baseband frequency hopping is quite simple: we
have several RF carriers (transceivers) transmitting and receiving
on fixed frequencies (just like in a regular multi-trx setup), and
an additional burst routing layer between the schedulear and the
transceiver interface (TRXD over UDP).
Speaking in terms of the proposed implementation:
- on Downlink, dlfh_route_br() calculates the ARFCN corresponding
to the current TDMA frame number according to the hopping sequence
parametets, and picks the transceiver with matching ARFCN;
- on Uplink, ulfh_route_bi() iterates over the transceiver list of
of the BTS, calculating hopping ARFCNs for equivalent timeslots,
and picks the one with ARFCN matching the received burst.
In order to avoid frequent transceiver lookups on the Downlink path,
dlfh_route_br() maintains a "cache" in the timeslot state structure.
Unfortunately, this "cache" seems to be useless on the Uplink path,
so ulfh_route_bi() always needs to lookup the matching transceiver
for each burst received over the TRXD interface.
It may also happen that the scheduler will be unable to route an
Uplink or Downlink burst, e.g. due to inconsistent / incorrect
hopping sequence parameters received from the BSC, or in case
if a transceiver gets RF-locked by the BTS operator.
Such events are logged as "FATAL" and aditionally signalled by the
following osmo-bts-trx specific rate counters:
- trx_sched:dl_fh_no_carrier (Downlink), and
- trx_sched:ul_fh_no_carrier (Uplink).
Change-Id: I68f4ae09fd0789ad0d8f1c1e17e17dfc4de8e462
Related: SYS#4868, OS#4546
This change facilitates the upcoming freq. hopping implementation,
in particular scheduling of dummy bursts on C0 with hopping time-
slots. One problem is that we cannot know in advance, whether to
send a dummy burst on a given timeslot unless all transceivers are
processed. For example, trx#3 may want to send a normal burst on
ARFCN of trx#0 (C0), while we have already sent a dummy burst...
Another important aspect is that we shall not be sending dummy
bursts on transceivers other than C0. Scheduling dummy bursts
from _sched_dl_burst() in the context of a single hopping timeslot
of a single transceiver leaves trx_sched_fn() no way to know
whether it's a dummy burst or something else.
Let's solve both problems by moving dummy burst scheduling logic
from _sched_dl_burst() to trx_sched_fn(). Maintain C0 slot-mask
in the inner (per-trx) loop, so that we can fill missing bursts
with dummy bursts afterwards.
Change-Id: I8c3651c27d2991079e83b8abdb7e2c3f95b97a43
Related: SYS#4868, OS#4546
On receipt of either SIGTERM or SIGINT the shutdown FSM initiates
ramping down of the transmit power on Downlink. I noticed that
for some reason osmo-bts-trx stops sending Downlink bursts during
the process of ramping down.
I also noticed the following imporatant message:
DL1C NOTICE scheduler_trx.c:287 No more clock from transceiver
despite the transceiver is still powered on and keeps sending
the clock indications over the TRXC interface.
As it turned out, the problem is that on receipt of either SIGTERM
or SIGINT, we also raise the global 'quit' flag, so in the scheduler
trx_sched_clock() stealthy stops handling the clock indications.
Let's ensure that clock indications are handled regardless of the
state of 'quit' flag, so the ramping down would work as expected.
Change-Id: Ia71133d6f0b900e5e103595c83303a7cc5c06edf
If TRX is administratively locked during startup, for TS conigured as
TCH/F_PDCH the BSC will send a ACT PDCH message, but osmo-bts-trx won't
apply it by signalling it as available to the PCU, since the TRX is
locked.
That means the ts->flags contains the pending action to activate
it until it is unlocked. As a result, calling trx_set_ts() on it was
hitting the assert inside which expects not to apply the TS until it has
been confirmed by the PCU.
Let's still skip setting the TS and let pcu_tx_info_ind() trigger the
activation confirmation from PCU, since the TRX has just been unlocked.
Fixes following assert:
Assert failed (ts->flags & TS_F_PDCH_PENDING_MASK) == 0 /osmo-bts/src/osmo-bts-trx/l1_if.c:34
Change-Id: Ie3cad15d31870346d03a6e2f6dd32a9d2dd3067e
Fix power ramping if administrative state changes while previous
opposite change was already ACKED but power ramping was still ongoing.
With previous code, osmo-bts-trx would have sent a NACK and BSc would
drop the BTs link as a result.
Change-Id: I6c5240710ef6d223651dfb4a8db939b5d2f974ca
They were both half implemented but named differently, due to myself
adding them during the initial FSM implementation. This prevents
osmo-bts-trx sending a POWEROFF when OML link is dropped.
Related: SYS#4864
Change-Id: Ic2dab864b6d4075dfb9a1e4acfd9af013c9c46fe
How to reproduce:
* Configure a TS to be TCH/F_TCH/H_PDCH in osmo-bsc.cfg
* Run the network with osmo-bts-trx, then use osmo-bsc's "rf_locked 1"
* Then, unlock it: "rf_locked 0"
* The following assert will be hit:
Assert failed ts->dyn.pchan_is == ts->dyn.pchan_want /osmo-bts/src/osmo-bts-trx/l1_if.c:349
"""
(gdb) bt
#0 0x00007ffff5bb9355 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff5ba2853 in abort () from /usr/lib/libc.so.6
#2 0x00007ffff6832361 in osmo_panic_default (
fmt=0x555555814e60 "Assert failed %s %s:%d\n", args=0x7fffffffc6e0)
at /libosmocore/src/panic.c:49
#3 0x00007ffff683249d in osmo_panic (
fmt=0x555555814e60 "Assert failed %s %s:%d\n")
at /libosmocore/src/panic.c:84
#4 0x000055555570fdf7 in trx_set_ts (ts=0x7ffff1e6bce8)
at /osmo-bts/src/osmo-bts-trx/l1_if.c:349
#5 0x00005555557133c1 in bts_model_chg_adm_state (bts=0x627000000160,
mo=0x7ffff1e0f8a0, obj=0x7ffff1e0f860, adm_state=2 '\002')
at /osmo-bts/src/osmo-bts-trx/l1_if.c:681
#6 0x0000555555769978 in oml_rx_chg_adm_state (bts=0x627000000160,
msg=0x633000003e00)
at /osmo-bts/src/common/oml.c:1044
#7 0x000055555576a8d3 in down_fom (bts=0x627000000160, msg=0x633000003e00)
at /osmo-bts/src/common/oml.c:1129
#8 0x0000555555770aed in down_oml (bts=0x627000000160, msg=0x633000003e00)
at /osmo-bts/src/common/oml.c:1476
#9 0x00005555557f8174 in sign_link_cb (msg=0x633000003e00)
at /osmo-bts/src/common/abis.c:188
#10 0x00007ffff73b5935 in ipaccess_bts_read_cb (link=0x6120000030a0,
--Type <RET> for more, q to quit, c to continue without paging--
msg=0x633000003e00)
at /libosmo-abis/src/input/ipaccess.c:980
#11 0x00007ffff73a1060 in ipa_client_read (link=0x6120000030a0)
at /libosmo-abis/src/input/ipa.c:72
#12 0x00007ffff73a2458 in ipa_client_fd_cb (ofd=0x62f000038a50, what=1)
at /libosmo-abis/src/input/ipa.c:136
#13 0x00007ffff67ebfa7 in osmo_fd_disp_fds (_rset=0x7fffffffdda0,
_wset=0x7fffffffde40, _eset=0x7fffffffdee0)
at /libosmocore/src/select.c:227
#14 0x00007ffff67ec38c in _osmo_select_main (polling=0)
at /libosmocore/src/select.c:265
#15 0x00007ffff67ec46b in osmo_select_main (polling=0)
at /libosmocore/src/select.c:274
#16 0x00005555557ef089 in bts_main (argc=7, argv=0x7fffffffe208)
at /osmo-bts/src/common/main.c:354
#17 0x00005555556fe621 in main (argc=7, argv=0x7fffffffe208)
at /osmo-bts/src/osmo-bts-trx/main.c:176
"""
Related: OS#4920
Change-Id: Ia3210e24b921fd0c67f77068b7ef4a65f270cd11
Waiting until all other TRX are provisioned before really sending
POWERON helps avoiding race conditions where TRX!=0 are not yet fully
configured at the TRX side before POWERON is called.
This solves for instance the situation where after POWERON RSP the BTS
started ramping up on all TRX while on some NOMTXPOWER RSP was yet not
received...
Related: SYS#4920
Change-Id: I906be4714807c7a2793971cb6062120e24337d7b
The state of each config required is now tracked through the "acked"
variables, this way the FSM can know when all configs are confirmed by
the TRX and can proceed to submit POWERON command.
With this version each TRX is still totally independent (there's an FSM
per TRX), which means POWERON can be sent on TRX0 before TRX!=0 are
fully configured. As a result, powe ramping may start before we know the
NOMTXPOWER of a TRX. This kind of issue will be fixed in next commit.
Related: SYS#4920
Change-Id: I1b736a4be5ce52a854f5767d8609153e1f4c08d9
With prior code state managing the TRXC side of osmo-bts-trx, there are
plenty o cases (race conditions) where things can go wrong/unexpected,
because there's really no infrastructure to wait and synchronize between
different TRXs (eg wait until all are configured to POWERON), or to
simply keep well known per-trx state regarding lower layers.
In order to fix in the future all of those issues and to sanitize
current code, a new per-trx FSM is introduced, which takes care of
submitting TRXC commands and waiting for response when needed to manage
the state of the TRX.
Related: OS#4364
Change-Id: I2a00c23df15840e33fbb232c9e1dd6db128f63f6
At that time we schedule a POWERON command towards osmo-trx, so let the
callback of RSP POWERON set the OPSTATE in l1if_poweronoff_cb rather
than setting it without waiting for confirmation from osmo-trx.
Change-Id: Ib36a073cae5e1522821a04d8806648562f4e0f5b
bts.h refers to struct gsm_bts object, but we still had a bunch of stuff
in bulky gsm_data.* from old days. Let's move stuff where it belongs to
start clean up of gsm_data.
Change-Id: I0a4219e3f64f625ee8b364bf408b8d2bcc8085c5
Ramp down when BTS is administratevly locked, and ramp up when it
becomes unlocked again.
Af ramping down, bts_model_trx_deact_rf is called to make sure all
channels are released.
power_ramp_start() is dropped from inside bts_model_trx_deact_rf since
it's not the proper place. In there we simply want to instantaneously
drop RF.
Related: SYS#4920
Change-Id: Ib7a7b0a0c24779349f142215f0bb32b72c86ce70
This should provide a quick way to check if the system is frequently
overloaded over time and hence downlink FNs are scheduled later than
expected.
Change-Id: I0051b9ab18ebc9f92db11374d856de94f155efa4
I believe the modern compilers are smart enough to optimize the
outer (per-timeslot) loop of trx_sched_fn() in a way that TDMA
frame number is advanced after making sure that a transceiver
is powered on. However, it's still more perspicuous to check
availability of a given transceiver first.
Change-Id: I6a97000c1c84e36096e9ba378a489c82caa4cc5b
According to 3GPP 45.002, section 5.2.4, a frequency correction
burst is basically a sequence of zeros. Since br->burst is already
zero-initialized, there is no need to maintain and memcpy() another
sequence of zeros into it. Just set the length.
Change-Id: Ic4f6d550010da5caf4bc471ff1e184c9fab30c6d
In trx_sched_fn() we schedule Downlink bursts in advance, in order
to give the transceiver some time to process them. This function
handles all timeslots of all transceivers in a loop. The problem
is that the given frame number is overwritten on each iteration.
Let's say we have 4 transceivers, each with default fn-advance 20.
The given frame number N will be advanced 4 times, so the resulting
frame number for 4-th transceiver would be (N + 4 * 20) instead of
(N + 20) as expected. Therefore, all additional transceivers would
be served more and more in the future (depending on their position).
Change-Id: Ie3ab544eac81a675266df09cd2b7740e4183188e
There's a standarized way through OML's Administrate State to control
the status of TRX, so let's use and maintain that one rather than this
ad-hoc hack.
Related: SYS#4920
Change-Id: Ia7f190063c35e0ed8e2e734047b3aff608cd3ce3
Some backends like osmo-bts-trx require exchanging messages like
POWEROFF to close the TRX, and hence need some time. Switch the function
to expect result asynchronously by calling a callback.
This will be used later to wait until all TRX are really powered off
before exiting the process.
Change-Id: I7d76b600fc06e1114b35bf0c2d08eff5bbd1b69a
bts_model_trx_close is only called during bts_shutdown immediately after
bts_model_deact_rf, so its logic keeps being essentially the same after
this code movement.
On the other hand, bts_model_deact_rf is also called during RSL link
establishment if it failed for whatever reason in
bts.c:trx_link_estab(). In that case, we want to make sure the TRX is
not used so we need to implement bts_model_deact_rf.
Change-Id: Id4eae743da81773a04b82e7b454071b0cc66677a
Using the VTY command will force that value and prevent osmo-bts-trx to
use/send NOMTXPOWER cmd over TRXC.
Change-Id: I496753bc74767a7e18b831768d9d422a738192b7
For those osmo-bts-trx specific logical channels with a generic
logical channel state associated, let's finally apply the BS Power
reduction (attenuation) value that was received from the BSC.
Change-Id: Ib692ff1a75a80fceccb481839c8514d4b2a547b9
This change simplifies access to generic logical channel state
(struct gsm_lchan) from osmo-bts-trx specific state (struct
l1sched_chan_state), so there is no need to look it up using
get_lchan_by_chan_nr() on receipt of each Uplink burst.
Change-Id: Ic4378020f980845b962f71b9e4b7faea738bc174
This change is similar to what we did for Uplink bursts:
- group all Downlink burst parameters into a single structure,
- allocate it once and pass a pointer to lchan handlers,
- pass a pointer to trx_if_send_burst().
Given that the structure is allocated and (zero-)initialized in
trx_sched_fn(), we can get rid of some memset() calls in lchan
handlers and thus improve the overall performance a bit.
Change-Id: If3014e69746559963569b77561dbf7b163c68ffa
It's easier to maintain the logical channel handlers in separate
files, rather than in a huge one (scheduler_trx.c, ~2k lines).
Change-Id: Ie5663fd90596b4800a4546675a323250bbb24c80
it was perceived that sometimes based on order of events (OML attr setup
and timing of RSL connections, etc.), the NOMTXPOWER for TRX!=0 can come
after the RSP POWERON, and hence the target power level for TRX!=0 is
not done correcty. This can be seen by running any test using the
ttcn3-bts setup of docker-playgrounds.git.
Change-Id: I2ec8dba61393be6edfab9e7e478e096e2d0933ad
The nominal transmit power is still only configurable manually from
osmo-bts-trx VTY interface. Support to retrieve the nominal power
from osmo-trx will come later.
Change-Id: Ia7c353e4c199e0fc3bcab55c45a4abda2c66d2c1
Looking at GSMTAP during handover, I've noticed many packets on
RACH looking pretty much like false positives, all with RA=0x00.
I correlated GSMTAP traces with TRXD traces, and figured out
that they all are triggered by NOPE indications from osmo-trx.
Since a NOPE.ind carries no valid burst, all its bits are set to
zero. Funny enough, this sequence is still decoded just fine as
a valid RACH, so that's why we see it on GSMTAP. Later on it
gets rejected by L1SAP due to bad RSSI, ToA, and/or C/I ratio.
The is a side effect of [1]. In order to ensure proper Uplink
measurement reporting during handover, including the time
before the handover RACH is received, let's treat and handle
NOPE indications as Normal Bursts.
[1] Ice45d5986610d9bcef2a7e41f0a395ec779e3928
Change-Id: Ic69f3bc2b776a23374c28a6884080a54bc16ef5f
Related: OS#4592
It was a very bad idea to mix "public" BTS features, that are
reported to the BSC via OML, and those features, that are used
locally (and exclusively) in osmo-bts.
Why? At least because we already have the BTS feature manipulation
API in libosmocore, that is used by osmo-bsc, but for some reason
not by osmo-bts. New features added to libosmocore would clash
with the existing "internal" ones like BTS_FEAT_MS_PWR_CTRL_DSP.
So what this change does can be described as follows:
- remove duplicate definition of the "public" features,
- use libosmocore's API for the "public" features,
- separate both "internal" and "public" features:
- the "public" features continue to live in bitvec,
- the "internal" features become flags,
- s/BTS_FEAT/BTS_INTERNAL_FLAG/g.
Change-Id: Icf792d02323bb73e3b8d46384c7890cb1eb4731e
EGPRS support, in particular MCS channel coding, was introduced
to osmo-bts-trx years ago, but we still report that it's not
supported. Let's stop confusing BSC, and set this feature too.
Change-Id: Iaf92764d266e12efd2350967deffae50fbbb3b9e
This value will be soon acquired automatically by osmo-bts-trx by asking
over TRXC to new versions of osmo-trx which is the nominal tx power for a given trx.
However, to still be able to work correctly against older versions of
osmo-trx or other TRX implementation (older or current) not supporting
this new TRX comamnd, let's allow the user to force a given value
through VTY for Tx power to work correctly.
Change-Id: Ib1b6f80d3b54afc42db9d358a79582cc619c6ce4
New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_READ symbol when
copy-pasting somewhere else.
Change-Id: Id51ccb2c273c5f0fa4986f28bbd69a72d2dbaa0e
Currently we do not detect any of the DTX frames (SID_FIRST, SID_UPDATE
etc.) Detecting and tagging those frames as is_sub is important for
measurement processing. Also the RTP marker bit must be set on each
ONSET frame.
- Add detection of DTX frames
- Tag DTX frames as is_sub and set frame type to AMR_SID
- Set RTP marker bit when ONSET frames are received
Change-Id: I5afe730fff2fa3199a5913b0de4f5c7b23a39f31
Depends: libosmocore I2bbdb39ea20461ca08b2e6f1a33532cb55cd5195
Related: OS#2978
Without using the NOPE indication it might happen that we get
into the following situation:
* bursts 0,1,2 of a given block are received
* burst 3 is lost on the radio interface, OsmoTRX sends NOPE
* osmo-bts-trx doesn't pass the NOPE the the rx_tch*_fn()
* we never detect the end of the block, never perform decoding
and even if the burst could be fully decoded, we loose the block
For voice, it can lead to lost RTP frames in uplink, which is also
problematic.
Let's deal with burst_len=0 in rx_tch*_fn() and use it as nope_fn.
Closes: OS#4661
Related: OS#2975
Change-Id: I0fbf4617daf24bd8aecfd9cfe1efd66cf73a277a
This fixes a regression introduced in I710d0b7cf193afa8515807836ee69b8b7db84a84
We (obviously!) cannot compute the BER before performing convolutional
decoding.
Change-Id: I4e57f45d49cb513e4843e56f50c8de6980958fdc
Related: OS#2977
Related: OS#4667
The MPH INFO MEAS IND indication, which contains the uplink measurement
data is sent in parallel to the PH DATA and TCH indications as a
separate indications. This makes the overall uplink measurement data
processing unnecessarly complex. So lets put the data that is relevant
for measurement into the PH DATA and TCH indications directly.
This change only affects osmo-bts-trx at the moment. In order to keep
the upper layers (l1sap.c) compatible we add an autodection to switch
between separate measurement indications and included measurement data.
Related: OS#2977
Depends: libosmocore I2c34b02d329f9df190c5035c396403ca0a4f9c42
Change-Id: I710d0b7cf193afa8515807836ee69b8b7db84a84
The timing advance controller that is implemented in loops.c of
osmo-bts-trx only works for osmo-bts-trx and not for any of the phy
based bts. Lets move the timing advance controller into the common part
and make it available for every bts. Also lets add a unit-test.
Change-Id: If7ddf74db3abc9b9872abe620a0aeebe3327e70a
Related: SYS#4567
osmo-bts currently does not generate a measurement report in case the
SACCH of the related traffic channel is lost. This is a problem because
the moment when reception gets bad measurmenet reporting is crucial to
carry out handover decisions effectively.
The presence of a SACCH block controls the conclusion of the measurement
interval and the sending of the RSL measurement report. The latter one
not only requires a measurmenet indication, it also requires a fully
intact SACCH block.
Lets use the NOPE / IDLE indications from V1 of the TRXD protocol to
ensure a SACCH block is always reported up to l1sap.c. In cases where
the SACCH is bad, trigger the sending of the RSL measurement report
manually without attaching the measurmenet data from the MS (which we do
not have in this case)
Related: OS#2975
Depends: osmo-ttcn3-hacks Ib2f511991349ab15e02db9c5e45f0df3645835a4
Change-Id: Idfa8ef94e8cf131ff234dac8f93f337051663ae2
Let's drop it instead of having code duplication from common code in a
lower layer, and maintain only the one in l1sap for all BTS models.
As a result, osmo-bts-trx loses feature BTS_FEAT_MS_PWR_CTRL_DSP and
will only be able to use "ms-power-control osmo" in VTY, which will be
enabled by default (meaning: change of behavior, now MS Power Control is
enabled by default in osmo-bts-trx and can only by disabled by BSC).
Old bts-trx specific VTY command "(no) osmotrx ms-power-loop" is marked
as deprecated but still working for more usual case (1 TRX configured)
to avoid breaking backward compatibility.
TA low level loop is still kept in loops.c and will be moved to l1sap at
some point too.
Related: OS#1851
Change-Id: I0d8b0c981d9ead91d93999df6e45fb06e426aeb9
On an ARM toolchain:
scheduler_trx.c:294:3: warning: format '%ld' expects argument of type 'long int', but argument 10 has type 'int'
Let's cast it to long int to make sure correct size is applied in all
platforms.
Change-Id: I701b3dbc4e84db21cf02305d374b0df731e70313
There is theoretical risk that when calculating the BER that a division
by zero occurrs. Lets add a check to avoid n_errors / n_bits_total when
n_bits_total is zero.
Change-Id: I1c0731b9a60be4b8c0c84b85b4403168120ceacd
Fixes: CID#205696
A NOPE.ind indicates absence of an Uplink burst, thus it does not
carry a burst. Let's init the burst length to avoid uninitialized
memory access in the scheduler code.
Change-Id: I77f686bf7df385215892e71733a28ff0d90d7222
Fixes: CID#205857
Each logical channel can now optionally have an additional handler,
that will be called when a NOPE / IDLE indication is received from
the transceiver. The aim of that handler is to keep the logical
channel state updated in case if one or more Uplink bursts are lost.
Change-Id: I71c552f44c25e56e9779d8b8ef5d4de9f8475637
Related: OS#3428
It indicates whether BTS model supports managing an MS Power Control
Loop over HW/DSP instead of using the software based osmocom algorithm
present in osmo-bts.
osmo-bts-trx own loop implementation is considered to be a "DSP/HW" one
since it acts on lower layers and interferes with osmocom algorithm
since it controls the same end variable "lchan->ms_power_ctrl.current",
this way we make sure both aren't enabled at the same time.
Old behavior in kept: if common upper-layer algo is not enabled
explicitly in VTY (ms-power-control osmo) and bts-trx specific lower
layer algo is neither enabled (osmotrx ms-power-loop <xyz>), then no
power control is done at all.
Related: OS#1851
Change-Id: I49706926b1e962b18791174627bc3cc0cd0cd9d5
The affirmation written there is not true, since actually it depends on
the band. For instance, for DCS1800 the maximum MS power is provided by
class 3. Let ms_pwr_ctl_lvl() take care of campling instead.
Change-Id: I744e7c315b818a1e7d3dd2579cd483c693d89b73
Make it clear that it contains the maximum MS power level (TS 05.05) and
not the one to be used. The one aimed at is in ms_power_ctrl.current.
Since it's used in related code, move it inside the ms_power_ctrl struct
too.
Related: OS#1851
Change-Id: Ib264ec7dac87355cef6415461ed74bd8e9c8ca52
Vadim Yanitskiy
Pau Espin
Philipp Maier
Daniel Willmann
Vadim Yanitskiy
Harald Welte