This actually should have been working since 2015, when the following
patch was merged to libosmcore:
commit f8699ca51eeb4f3d34336501abcaf071b4a95a47
Author: Max <max.suraev@fairwaves.co>
Date: Wed Mar 25 17:20:31 2015 +0100
gsm: Add A5/3-4 cipher support
however, it seems nobody so far bothered to actually enable A5/3 for
osmo-bts-trx!
Change-Id: I8192d6d07cdb87783bce997456ead673c600f7c0
Closes: OS#3253
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
gsm_bts_role_bts was introduced at a time when we still shared
gsm_data_shared.[ch] between BSC and BTS, and where we then subsequently
needed a BTS-private structure. Since that sharing was abandoned quite
some time ago, we can merge gsm_bts_role_bts into gsm_bts and do away
with the bts/btsb dualism in a lot of the code.
Change-Id: I4fdd601ea873d9697f89a748cc77bcf7c978fa3e
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
Before this patch we had:
* osmo-bts-trx internally using 1/256th bit/symbol period
* osmo-bts-sysmo internally using 1/4 bit/smbol period
* PCU interface using 1/4
* L1SAP interface using 1/4
* measurement processing code on top of L1SAP using 1/256
So for sysmo/lc15/octphy we are not loosing resolution, but for
osmo-bts-trx we're arbitrarily reducing the resolution via L1SAP
only then to compute with higher resolution again.
Let's change L1SAP to use 1/256 bits and hence not loose any resolution.
This requires a corresponding change in libosmocore for l1sap.h, which
is found in Change-Id Ibb58113c2819fe2d6d23ecbcfb8b3fce4055025d
Change-Id: If9b0f617845ba6c4aa47969f521734388197c9a7
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
There are use cases for the multiframe scheduler tables outside the
context of the entire scheduler. Let's prepare for that.
Related: OS#2978
Change-Id: I6a501e66c47809ae3cdc55bef2cb6390ee0096b1
osmo-bts has a table of pchan/channel mode combinations for every
bts. This table models the codec capabilitys of the BTS hardware.
However, having the speech codec apabilities modeled inside the
BTS feature list would be much more comfortable and since the
feature list is communicated back to the BSC we would get the
codec capabilities inside the BSC domain as well.
- remove the pchan/channel mode tables
- set speech codec variants for each BTS type
- fix bts_supports_cm so that it queries the feature list
Change-Id: I977dc729ba856631245aedf76afd48eac92166f7
Most of the BTS models do not or do register not all of thier
features to the the feature list.
- Update/extend the feature lists for all BTS-Models
Change-Id: I26765a64153368016921c2ac115b1c4aec9bc5e4
When the BSC sends a MODE MODIFY request with an unsupported
codec, the BTS must respond with a negative acknowledge.
Currently the codec parameter is not checked at all, which may
lead into malfunction or crash of the BTS.
- Introduce a mechanism to check the codec/rate against a
table that is set up in the phy specific code.
- Add tables with supported codec/rate combinations for
octphy, sysmobts, and trx.
Change-Id: Id9b222b7ab19ece90591718bc562b3a8c5e02023
Related: SYS#3212
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
It was detected that under some conditions, osmo-trx (with limesdr)
may take a long time to answer to CMDs, which means trx_ctrl_timer will
trigger re-transmitting the last sent but yet unacked CMD. Due to the
high latency in osmo-trx, the original AND the rentrasnmited CMD are
handled after a while and RSP messages are sent for both. When
osmo-bts-trx receives the first RSP, it was marking the CMD as acked and
carried on with next one. Then, when the RSP from the retransmited CMD
arrives, it already lost state and doesn't know where does that come
from. As a result, osmo-bts-trx shutdowns.
The issue can be seen in the following truncated log from osmo-bts-trx
with TRX category enabled:
20180117135228175 Enqueuing TRX control command 'CMD RXTUNE 1782000'
20180117135228175 Enqueuing TRX control command 'CMD TXTUNE 1877000'
20180117135228175 Enqueuing TRX control command 'CMD SETTSC 7'
20180117135228175 Enqueuing TRX control command 'CMD POWERON'
20180117135228175 Enqueuing TRX control command 'CMD SETRXGAIN 1'
20180117135228175 Enqueuing TRX control command 'CMD SETPOWER 20'
20180117135228175 Enqueuing TRX control command 'CMD SETSLOT 0 5'
...
20180117135249829 Response message: 'RSP POWEROFF 0'
20180117135249855 Response message: 'RSP RXTUNE 0 1782000'
20180117135249876 Response message: 'RSP TXTUNE 0 1877000'
20180117135249876 Response message: 'RSP SETTSC 0 7'
20180117135250648 Response message: 'RSP POWERON 0'
20180117135251150 Response message: 'RSP SETRXGAIN 0 0'
20180117135253151 No response from transceiver for phy0.0 (CMD SETPOWER 20)
20180117135253777 Response message: 'RSP SETPOWER 0 20'
20180117135254535 Clock indication: fn=2018878
20180117135255777 No response from transceiver for phy0.0 (CMD SETSLOT 0 5)
...
20180117135256858 Response message: 'RSP SETPOWER 0 20'
20180117135256858 Discarding duplicated RSP from old CMD 'RSP SETPOWER 0 20'
20180117135256858 Response message: 'RSP SETSLOT 0 0 5'
20180117135256858 Response message: 'RSP SETSLOT 0 0 5'
20180117135256858 Discarding duplicated RSP from old CMD 'RSP SETSLOT 0 0 5'
Change-Id: I3633cba212edde878f83ed36aef922aaca6f503a
First the cached CMD sent (struct trx_ctrl_msg) is reworked to have the
cmdname and the params in different buffers for easier comparison with
RSP later.
For the receive path (trx_ctrl_read_cb), new function helpers are added
to parse the buffer into cmdname+params+code (parse_rsp) and to compare
if a given RSP matches the current CMD we sent (cmd_matches_rsp).
The reasoning behind this patch is that a way to check for parameters
when receiving a RSP will be needed in future work, as before this patch
checking of parameters is ignored. This commit is a preparation for commit
to check for duplicated responses.
Change-Id: I2474cbc3e4457cf04f78e1c168768295e1132034
The move includes a small logic change: If there's a mismatch between
the rsp and the cmd, now we bts_shutdown instead of blindly skipping
expected RSP and continuing with sending the next CMD in the queue. The
change is specially not a problem since next patches are improving the
logic furthermore to account for duplicates, different parameters, etc.
Change-Id: I7018ded23fe51f364f248ade111aaa80ef46187e
While debugging other protocol/timing issues between osmobts-trx and osmo-trx,
I found that sometimes two consecutives "POWER OFF" commands are
enqueued and sent to osmo-trx.
There's no point in doing so, as the write queue already maintains state
and retries the command until a RSP is received, then goes for the next
one.
With this change we hence improve timing response as we don't need to
wait for the second command to be processed, and on top we get cleaner
logs and simplified states which are easier to debug.
Change-Id: Ib6a5e7bfac8bc5e1b372da6a1f801c07a3d5ebb7
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 trx_clk_read_cb(), when calling phy_instance_by_num(), that
function might in error cases return a NULL phy-instance. Let's
put an OSMO_ASSERT() there as safeguard to avoid NULL dereference
when dereferencing pinst->trx->bts.
Fixes: Coverity CID#178657
Change-Id: If6b6b45380368e9ee9e03ca1eb7ac56c21e72b03
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
We unconditionally pass "p+1" into sscanf() despite not knowing
if 'p' is NULL or not.
Change-Id: I40a49c3feb3b55ef577eebd7d567afdbcfe0d624
Fixes: Coverity CID#178661
There's a lot of pointer arithmetic in trx_ctrl_read_cb which is
not so nice. While I believe the current code is safe, Coverity
raises "CID 178665: Insecure data handling (INTEGER_OVERFLOW)"
regardin the use of rsp_len in the strcmp().
Let's put some OSMO_ASSERT() in front and hope that makes Coverity
happy.
Change-Id: I5a9b3307f83cdde7c8e9f66932446604f5623b05
On 'write file':
- Write 'osmotrx' before 'maxdly' and 'maxdlynb' (broken since "Introduce new
phy_link and phy_instance abstraction"
d784e50747)
- Fix indenting of 'write file' output, command 'osmotrx timing-advance-loop',
had a stray space in case there is not a 'no' preceding it.
Add some missing instances of OSMOTRX_STR doc strings.
examples/osmo-bts.cfg:
- Drop 'settsc', the command no longer exists.
- Fix indenting of 'osmotrx rx-gain' command.
osmo-bts does not feature VTY tests, so it is pointless to add example files to
test these fixes. We should probably add VTY tests separately. However, I have
briefly tested manually (and hence found all of these issues).
Change-Id: I018eaef40345bfa26e12eb7d09e83a52596c1000
* copy-paste gsm_data_shared.* from OpenBSC master
* remove corresponding configure check and option
* remove .deb dependency
Actual refactoring with removal of unnecessary structures/parts, moving
common OpenBSC/OsmoBSC parts into libraries etc. are left for further
patches.
Current patch will make coexistence with *BSC easier and will simplify
our build infrastructure.
Change-Id: I9f004fb5c4c1db29d4792dfd281d388c7063da13
Related: OS#1923
* do not deactivate lchan when called with LCHAN_REL_ACT_REACT
* add fixme comment
It's unclear yet if any special steps are required for osmo-bts-trx so
let's just make it compatible with setups [1] using BS_AG_BLKS_RES != 1
for now.
Background: CCCH is auto activated by some OsmoBTS - before we receive
SI3, see 4a85828462. To accommodate for
that we deactivate CCCH in common/rsl.c, which triggers BTS-model
specific callback sapi_deactivate_cb() which updates parameters and
activates it again.
In case of osmo-bts-trx there is no auto-activation and (seems to be) no
need in special interaction with hw to activate channel (no
lchan_activate()) hence we can just skip entire
deactivate/setup/activate again routine.
[1] "channel-descrption bs-ag-blks-res N" in OpenBSC config file.
Related: OS#1575
Change-Id: I20b89ba1e43d1414180b083cd1e085eeffe5d513
Original OpenBTS transcievers add 2 bytes of padding to the end of data
bursts, having in total 158 bytes. As those two extra bytes are being
ignored after the initial validation, let's relax this validation a bit
in order to accept transcievers that decide no to send these two extra
bytes.
Change-Id: I94c3cb160bfed0ba9c41ed7ef5f8d8a65b81ad07
* move TA related globals into phy_link
* move power loop related globals into phy_link
* prefix corresponding vty vars with osmotrx
Change-Id: I01d7c1abad67e51b886a4ecf2de072929d67da27
Related: OS#1848
It was introduced in fe6c75d24a1751341bcee91cb45c7ac7f5d07da3:
* fix typo in config write
* add missing vty help string
Change-Id: Id42359dfbb8ad02f34dd2540db66f3ed69ad5181
New libosmocore has some plugin system which requires dlopen(). So we need
to make sure we always link with libdl, even when building statically.
Note that this doesn't fix static build of tests - they are still failing
with some errors.
Change-Id: I8315d6e032e34528def268a49fd88d07bc06ab2e
We tend to start MS with high power to make sure distant phones get good QoS,
but this also means that we need to reduce their power rather quickly. OTOH
we can't make this step too high because this may lead to power output
oscillation. From my (manual, limited) testing 4dB looks like a reasonable
compromise.
Change-Id: I58785513e5739474b881ed7f2a312ecc690e7e60
The following two commits from 2014-12-06 introduced a new variable to control
MS power - ms_power_ctrl, but kept the old ms_power variable in place. They
have also changed the meaning of the ms_power variable - it now keeps original
RSL configured value. So when much later osmo-trx-bts code was merged to master
the code was compiling fine and this change in the meaning was overlooked.
In osmo-bts:
579651bf30 power/sysmobts: Add a manual ms power level control
In OpenBSC:
f6f86b0eec18da165db136b14bf2db87fde4b4ac osmo-bts: Introduce new struct for a power loop in the BTS code
Change-Id: I713e39b882db32a0d17aa04790d16fa79afa1fb1
There are currently two ways to specify power reductions to be sent to
osmo-trx from osmo-bts-trx:
* osmotrx tx-attenuation oml
* osmotrx tx-attenuation <0-50>
None of them is enabled by default, which means if none of them is
specified in the config file of osmo-bts-trx, SETPOWER cmd won't be sent
to osmo-trx, which in turn won't turn on the transciever.
Let's enable osmo tx-attenuation oml by default and leave it up to the
bsc to decide which power reduction to use. If the user wants to
configure a specific tx-attentuation, it can still do so in exactly the
same way he used to do it.
Change-Id: Ia8640751630ee37e5f5d1f470bad892a08e80654
Whether or not we are talking to an OpenBTS (SETBSIC) or OsmoTRX
(SETTSC) transceiver is a property of the phy_link, and not a property
of the BTS. Also, we *really, really* should never use global
variables. I'm very happy this is being cleaned up, finally.
Change-Id: I51aeb17661dfd63ff347f7b2c0d7ffa383ec814c
Those global variable declarations for non-existing variables were
introduced in 8a8d73a691, let's remove
them again. The source / destination IP address is a parameter of the
phy_link, and not a global variable.
Related: OS#1848
Change-Id: I94b5f934fc3bd00b0467d90029d3053b16594186
In bts_model_l1sap_down() we want to identify BCCH/CCCH channel numbers,
but our check is a bit non-specific. Let's make the check more specific
to only cover the BCCH, Uplink CCCH and Downlink CCCH C-bits as defined
n 3GPP TS 08.58 Section 9.3.1
Change-Id: Ia20ab09b96c87c0dfbfaf98e5b2a8d36423fac67
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
l1h is allocated in bts_model_phy_instance_set_defaults() and not in
trx_phy_inst_open(). Hence, trx_phy_inst_close() should not free() it!
Change-Id: I0ac4e57a882e5a31143499c1662d8d8e52320938
Related code / function structure still dates back to the pre-phy_link
days. Let's clean this up to make things less convoluted and reduce the
number of non-static symbols needed between code split over two files.
Change-Id: I1f30ae1f547a5c01c516d4a05032193294c25f2d
Harald Welte
Pau Espin
Philipp Maier
Vadim Yanitskiy