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
Make sure the variables n_errors, n_bursts_bits, n_bits_total are always
initalized. For example in rx_tchh_fn() the value for n_errors is
defined in a switch statement, where the default lets n_errors
uninitalized, which is in that particular case a theoretical problem,
however, lets make sure that the variables n_errors, n_bursts_bits and
n_bits_total are always initalized with 0
Related: CID#205452
Related: CID#205451
Change-Id: If28ea11cc111c7d73ca47b25e65ce399e5baa4c1
When sched_compose_tch_ind, sched_compose_ph_data_ind or l1if_process_meas_res
is called from rx_tchf_fn or rx_tchh_fn the frame number of the beginning of
the block is required. At the moment this frame number is calculated
wrongly using strange formulas. Lets use gsm0502_fn_remap() to calculate
the beginning of the block properly
Change-Id: I37601ddd85e4287dd9e41ad4a8cb7d314de1a83d
Depends: libosmocore I3d71c66f8c401f5afbad9b1c86c24580dab9e0ce
Related: OS#3803
All other Uplink burst handlers print frame number of the last
(currently received) burst. Let's make rx_data_fn() consistent.
Change-Id: Ie5762a132326be3ef4e4e38cc126f05d51098a20
Before this patch, if due to whatever reason the TRX started fine (RSP
POWERON 0) and sockets were created but no CLOCK IND was ever received
by the BTS, it wouldn't notice since the timerfd timeouts
(bts_shutdown("no clock")) are only checked after the first CLOCK IND is
sent by the TRX.
As a result, the BTS would be kept on forever saying everything is fine
but it would be sending no DL burst at all to the TRX (tested with a
modfied osmo-trx dropping clock indication).
With this patch, new APIs are added to indicate the scheduler_trx code
the timeframes where clock ind are expected (between RSP POWERON 0 and
RSP POWEROFF 0); if TRX sends clock indications out of that timeframe,
BTs lower layers will drop them (controlled by "powered" bool).
Hence, the scheduler_trx can now place a timeout (reusing same timerfd
because its new use is exclusive in time with its other previous use)
when it is told that CLOCK IND should start appearing, and if none
arrives in considerable time, then the BTS can be shut down to notify
the rest of the network.
Related: OS#4215
Change-Id: Iba5dbe867aff10e70ec73dbf1f7aeeecb15c0a4d
This variable meaning has been changing its exact meaning over time
until finally not being really clear which kind of state it holds.
Initially it seemed to be used to identfy whether CLOCK IND were being
received. However, over time both osmo-bts and osmo-trx have evolved and
were fixed so that clock indications are only sent by osmo-trx after
POWERON command is sent. As a result, this state can be checked simply by
looking at the "powered" phy_link variable, which is only set to true
once the TRX has confirmed the POWERON command, and hence it is sending
CLOCK IND.
On the other hand, at some point in time "available" started to be set to 1
in bts_model_phy_link_open(), which means available is nowadays almost
always 1 from startup until the end (only dropped during bts_shutdown(),
when we are already exiting the process anyway).
As a result, !available condition in scheduler_trx.c:trx_fn_timer_cb can
almost never happen, because available is set to true already. Only
possibility would be if an old process of osmo-trx (not set up by this
BTS process) is still sending CLOCK INDs, but in that case we for sure
don't want to configure the BTS based on that, but ignore them until
this BTS process has again configured the TRX. So that whole check can
be dropped. We are better checking for "powered" state, which is far
more accurate, and we better do that in trx_if.c before calling
trx_fn_timer_cb().
Other uses of "transceiver_available" being used can be changed to use
plink->state!= PHY_LINK_SHUTDOWN, since available was already being set
to 1 at the same time the plink->state was being set to
PHY_LINK_CONNECTING.
As a result of this state handling re-arrangement, OS#4215 is fixed
since trx_if_powered() is used instead of previous state condition to
check whether data frames should be sent.
Related: OS#4215
Change-Id: I35f4697bd33dbe8a4c76c9500b82c16589c701d4
It can be dropped since bts_shutdown() ends up calling immediatelly
bts_model_trx_close() which in turn calls bts_model_trx_close() which
sets enabled = false and calls l1if_provision_transceiver_trx() to
power off the TRX.
Related: OS#4215
Change-Id: If8b3d2379d7ae102e1c338f4558ac1352de761cc
If a logical channel, on which an Access Burst has been received,
is not either of RACH, PDTCH or PTCCH, then this is a handover
Access Burst, which is always encoded as 8-bit and shall contain
the generic training sequence (TS0).
Access Bursts on a PDCH time-slot are not related to handover.
Change-Id: If7d6135d6c4d7f9bd71d9fab6f8adc3f8cfd10ea
libosmocodec has recently introduced a generic ECU abstraction layer
which supports (pluggable) Error Concealment Units for not only the
FR codec, but potentially any other codec, too.
Change-Id: I001005aae6de76d4e045b8dc572239f057bb150d
Depends: libosmocore I4d33c9c7c2d4c7462ff38a49c178b65accae1915
We call _sched_compose_tch_ind() after the switch statement, so
there is no need to send it from case 'GSM48_CMODE_SPEECH_AMR'.
Change-Id: I0488082494120157ac438d7763b52e3998f0eac7
When sending an AMR BFI, we need to call osmo_amr_rtp_enc() with
AMR_BAD as the last parameter. This function returns the length
of encoded payload, which needs to be at least 2 octets long.
If osmo_amr_rtp_enc() returns a length value lower than 2 octets
(what should not happen in general), we should neither call
memset() on it, nor call _sched_compose_tch_ind().
Change-Id: I70ce98c5697b9ce6fac7ab57a5d70f3201db29d9
Fixes: CID#178648, CID#178637, CID#178651
If gsm0503_tch_hr_decode() returns a negative error, we shouldn't
set the marker bit or pass the negative value as length value into
osmo_hr_check_sid().
Change-Id: If49ca6926c576a2b17507b6a95b6f3ca17877d66
Closes: CID#187645
TSC (Training Sequence Code) is an optional parameter of the UL burst
indication. We need this information in order to decide whether an
Access Burst is 11-bit encoded or not (see OS#1854).
If this information is absent, we try to correlate the received synch.
sequence with the known ones (3GPP TS 05.02, section 5.2.7), and
fall-back to the default TS0 if it fails.
Since the new TRXD header version, the training sequence code is
indicated by the transceiver. Let's use it!
Change-Id: I1e654a2e49cb83c5f1e6249c0de688f99bc466b0
Related: OS#1854, OS#4006
C/I (Carrier-to-Interference ratio) is a value in cB (centiBels),
computed from the training sequence of each received burst,
by comparing the "ideal" training sequence with the actual one.
So far, there was no way to expose more measurements from OsmoTRX,
excluding both RSSI and ToA. Since the new version of TRXD header,
we can receive C/I indications and send the averaged (per 4 bursts)
values to OsmoPCU (as a part of PCUIF_DATA.ind).
Please note that we also need to attach C/I measurements
to the following L1SAP primitives:
- PRIM_PH_RACH.ind,
- PRIM_PH_DATA.ind,
- PRIM_TCH.ind,
but this will be done in the follow up changes.
Change-Id: Ia58043bd2381a4d34d604522e02899ae64ee0d26
Fixes: OS#1855
This change needs to be done in order avoid adding more and more
arguments to the UL logical channel handlers (such as rx_rach_fn).
Since we have different versions of the TRXD header, and may have
other burst-based PHYs in the future, some fields of an Uplink
burst indication have conditional presence.
Change-Id: Iae6b78bafa4b86d0c681684de47320d641d3f7c0
Related: OS#4006, OS#1855
Thanks to both TC_rach_content and TC_rach_count TTCN-3 test cases,
it was discovered that there are possible collisions when trying
to decode a regular 8-bit Access Burst as an 11-bit one. This is
exactly what we are doing in rx_rach_fn():
- calling gsm0503_rach_ext_decode_ber() first,
- if it failed, falling-back to gsm0503_rach_decode_ber().
With default BSIC=63, the following 8-bit RA values are being
misinterpreted as 11-bit Access Bursts:
Successfully decoded 8-bit (0x00) RACH as 11-bit (0x0000): bsic=0x3f
Successfully decoded 8-bit (0xbe) RACH as 11-bit (0x0388): bsic=0x3f
Successfully decoded 8-bit (0xcf) RACH as 11-bit (0x0036): bsic=0x3f
According to 3GPP TS 05.02, section 5.2.7, there are two alternative
synch. (training) sequences for Access Bursts: TS1 & TS2. By default,
TS0 synch. sequence is used, unless explicitly stated otherwise
(see 3GPP TS 04.60).
According to 3GPP TS 04.60, section 11.2.5a, the EGPRS capability
can be indicated by the MS using one of the alternative training
sequences (i.e. TS1 or TS2) and the 11-bit RACH coding scheme.
In other words, knowing the synch. sequence of a received Access
Burst would allow to decide whether it's extended (11-bit)
or a regular (8-bit) one. As a result, we would avoid possible
collisions and save some CPU power.
Unfortunately, due to the limitations of the current TRXD protocol,
there is no easy way to expose such information from the transceiver.
A proper solution would be to extend the TRX protocol, but for now,
let's do the synch. sequence detection in rx_rach_fn(). As soon as
the TRX protocol is extended with info about the synch. sequence,
this code would serve for the backwards-compatibility.
This change makes the both TC_rach_content and TC_rach_count happy,
as well as the new TC_pcu_ext_rach_content() test case aimed to
verify extended (11-bit) Access Burst decoding.
Related (TTCN-3) I8fe156aeac9de3dc1e71a4950821d4942ba9a253
Change-Id: Ibb6d27c6589965c8b59a6d2598a7c43fd860f284
Related: OS#1854
When the ph-data indications for the PDTCH are passed up to l1sap,
then a forumla is used to calculate the frame number of the beginning of
the block that is just passed up. This is not necessary since the start
frame number of the block is stored in *first_fn when the block arrives.
We should use this frame number instead. (For the measurement indication
it is already done this way).
Change-Id: I6c01987be78203acfa689c6decb2c806f8fff3d6
Related: OS#2977
Attempt to decode incoming RACH burst as 11-bit first
and fallback to 8-bit if unsuccessful.
Change-Id: Ia28741603636406744e5e22ffff1fb7a9689955a
Related: OS#1854
Commit acefd0586e introduced the "toa256"
resolution change.
Before the change, _sched_compose_ph_data_ind() used quarter-bits as
units, so multiplying the old "toa" value by four made sense.
However, after said change, the value is in 1/256th of bits, and hence
we need to report the toa256 value without any multiply-by-four.
Change-Id: I9f980236ea1cd635cb229290e187747cc8c86d8d
Related: OS#2977
The previous implementation unconditionally subtracted nanosecond
values from different time measurements, causing overflow if the
current measurement was taken in less of a fraction of a second
than the past measurement. Use timespecsub() instead, which
accounts for nanoseconds correctly.
This is a similar bug as fixed in osmo-pcu for issue OS#3225
While here, switch variables which are calculated based on
struct timespec to 64 bit types. While probably not strictly necessary
in practice, this makes the types used in calculations more compatible.
Change-Id: Idfd9c807e35cd7fb5c80625b9746121f81c24599
Related: OS#3467
Related: OS#3225
Each logical channel (e.g. SACCH, SDCCH, etc.) has a counter of
lost L2 frames. Let's use a bit better name for it, and correct
its description in the 'l1sched_chan_state' struct definition.
Change-Id: I92ef95f6b3f647170cfd434a970701406b0a7c82
Upper layer requires us to trigger all events coming from lower layers
in order to keep the RTP clock in sync. In this case, this is done by
sending an empty payload to indicate there's no data to send.
Change-Id: I0bdfb529f35253ca7e531bb9984a3839c3bfe7e8
Let' wait until the just-merged osmo_timerfd_* functions
of Change-Id Ibeffba7c997252c003723bcd5d14122c4ded2fe7 have made it
into the next tagged release, and then replace the implementation
here.
Change-Id: Ic0f0a7437b6acb535177e5ad6ac7a6d336654c66
Should fix following observed run time errors:
osmo-bts-trx/scheduler_trx.c:1627:65: runtime error: signed integer overflow: -1081823 * 4615 cannot be represented in type 'int'
osmo-bts-trx/scheduler_trx.c:1627:21: runtime error: signed integer overflow: 1852394502 - -697645849 cannot be represented in type 'int'
Related: OS#3213
Change-Id: I36e0d2d0d0c6e35e963f611135453c4a4c00bc99
When a bad voice frame is received, it is replaced by
a silence frame. This may cause unpleasant audio effects.
This change implements a functionality to craft a replacement
frame from the last known good frame using ECU implementation
from libosmocodec. At the moment, only FR is supported.
Depends: libosmocore I06a21f60db01bfe1c2b838f93866fad1d53fdcd1
Change-Id: Iae9e69a9578ae305bca42f834694af96a29084e6
This was useful for software simulation of burst delay, expressed
by ToA (Time of Arrival). Since we have FakeTRX toolkit, ToA value
may be simulated in a more flexible way, so let's remove this code.
Change-Id: Ied0fcfcf58b93efdc6de9666fbbf8fea104e2543
There's no need to express TOA as a float:
* We receive it as signed 16bit integer in units 1/256 symbol periods
* We pass it to L1SAP as signed integer in 1/4 symbol periods
So turn it into an int16_t with 1/256 symbol period accuracy throughout
the code to avoid both float arithmetic as well as loosing any precision.
Change-Id: Idce4178e0b1f7e940ebc22b3e2f340fcd544d4ec
In the past, rach_busy counting was performed below L1SAP, while
reporting was handled above. This lead to subtle differences between
the BTS models, such as osmo-bts-trx missing to increment rach_busy.
Let's move the rach_busy counting above L1SAP to share more code.
This means we need libosmocore Change-Id
I9439810c3a3ad89ea0302753617b850749af887c for the additional required
parameters in ph_rach_ind_param, as well as libosmocore Change-id
I2b1926a37bde860dcfeb0d613eb55a71271928c5 for osmo-bts-trx to determine
the RACH bit error rate.
Change-Id: I3b989580cb38082e3fd8fc50a11fedda13991092
Closes: OS#3003
It seems like some of the functions invoked by _sched_dl_burst()
do not sent nbits properly. This leads to a number of errors on
startup:
trx_if.c:593 Tx burst length 65535 invalid
It happens in conjunction with:
Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
Let's fix this by initializing nbits to 0 to make sure those bursts
are properly ignored.
Change-Id: Iaf85826861163c185925de528c8347ab22779e30
It is required for bts_shutdown used in trx_fn_timer_cb, and compiler
warns about implicit declaration.
Change-Id: I274662cd657ce8c36ed1d262d138590808bfafea
The upper layers (L1SAP, the common part of L1) *always* require frame
numbers in the uplink direction to be reported as the frame number of
the *first* burst, not the last burst of a given block.
This is particularly important in the case of passing up measurement
information, as we use this frame number to detect if the measurement
interval for that specific timeslot has just ended (and hence we must
process the measurements and send an uplink measurement report to the
BSC.
Before this patch, the measurement results were reported with the *last*
frame number, which caused the common/measurement.c code never detect
the end of a measurement window.
On TS2, tons of the following log messages were observed:
<0004> measurement.c:199 (bts=0,trx=0,ts=2,ss=0) no space for uplink measurement, num_ul_meas=104
With this patch, it behves as expected: the measurements of 25 blocks
(= 100 bursts) are aggregated, after which point the report is computed
and sent. Subsequently, num_ul_meas is reset to 0 and the cycle
restarts.
Related: OS#2329
Change-Id: I1065ae9c400bb5240a63ab8213aee59aeb9ceeff
Almost all log statements in scheduler_trx.c were using the wrong
logging subsystem. Let's fix this. Also, make it more obvious from
the log subsystem help text
Change-Id: I4312f8ab0414eb38db0d62f05c95ab961f500c14
In rx_tchf_fn(), if gsm0503_tch_fr_decode() returns a negative
result, we cannot use that result as length argument to
osmo_fr_check_sid()
Change-Id: Ic4080b5bf6c865be3333f923f19a2340e1e272c8
Fixes: Coverity CID#178659
For some reason, osmo-bts-trx attempted to interpret/validate the
contents of the downlink TCH block that it was about to transmit. If
such checks are made, they should clearly be in the common part above
L1SAP, and not in the bts-model specific part.
Also, having the checks in place didn't allow us to send an all-zero
downlink block, as is required for detection of uplink FER in a loopback
testing setup, e.g. with CMU-300.
Change-Id: I6388de98e4a7e20843a1be88a58bba8d2c9aa0d5
The new name makes it clear what the function actually does: Send burst
data via the trx interface.
Change-Id: I5031541d4ae4244a62a18acf71139db2874927fa
Pau Espin
Philipp Maier
Vadim Yanitskiy
Harald Welte