Avoid 'osmo-bts' in parallel to the other osmo-bts components from
the OBS generating confusion and not starting binaries (lib conflicts).
Related: OS#3364
Change-Id: Ie8e8d604afeac55530162a69c4dc94e8048ac78d
All code in osmo-bts goes through APIs in libosmotrau (osmo_ortp.h),
hence direct dependency is not needed. Fixes OBS warnings:
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bts-trx/usr/bin/osmo-bts-trx was not linked against libortp.so.9 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bts-virtual/usr/bin/osmo-bts-omldummy debian/osmo-bts-virtual/usr/bin/osmo-bts-virtual were not linked against libortp.so.9 (they use none of the library's symbols)
Change-Id: I96a9b5f0678331dcf66c007928866a124d8700de
Files from doc/examples/foo/bar.cfg are install to
/usr/share/doc/osmo-bts/examples/osmo-bts-foo/bar.cfg.
Change-Id: I7525d5a3e1a3c83a54f919cce9096303dd506f35
CalypsoBTS is a regular osmo-bts-trx with specific config options, so
let's move the cfg file to correct place. This also makes it easier to
install and package example files later on.
Change-Id: Ie2b968c478f1cf4d3e4cb36e4fb743e413cc93f0
This patch adds extended processing of the high-resolution TOA256
measurement values. It adds reporting of the following values
for each RSL MEAS REP for uplink measurements:
* minimum TOA256 value during reporting period
* maximum TOA256 value during reporting period
* standard deviation of TOA256 value during reporting period
Change-Id: Iea4a4781481f77c6163d82dcd71a844a5be87bf2
The latest octphy firmware release (octsdr-2g-02.11.00-B1927-alpha),
introduces a 16X oversampling option which is not yet supported in
osmo-bts.
- Add oversampling flag in phy_link.h
- Add VTY commands to enable/disable oversampling
- Add phy messages to enable/disable oversampling
- Add conditional compilation to preserve support for legacy
header files and firmware
Change-Id: Ib78f92bfe03ff20aa0a257763c90844fb7b87cf0
Related: SYS#4257
Patch-by: Octasic inc.
osmo-pcu currently sends paging requests in PCU_IF_MSG_DATA_REQ
messages, rather than PCU_IF_MSG_PAG_REQ. Clarify a comment which
already alluded to this, and leave an explicit log entry if a
PCU_IF_MSG_PAG_REQ message is received.
Change-Id: I75fd8f051f943d876b5614fa088fff7e56b310ab
Related: OS#3018
The flag is enabled for all BTS flavour except for lc15, which still
contain several compilation warnings (fixes submitted to gerrit, but not
merged since no contributor is testing lc15 nowadays).
Change-Id: Ib65056633697dafa63831fc2a480b798df550db6
Fixes following compilation warning:
In file included from l1_if.c:32:0:
l1_if.c: In function ‘l1if_mute_rf’:
/include/osmocom/core/utils.h:13:30: error: ‘sizeof’ on array function parameter ‘mute’ will return size of ‘uint8_t * {aka unsigned char *}’ [-Werror=sizeof-array-argument]
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
^
l1_if.c:1405:29: note: in expansion of macro ‘ARRAY_SIZE’
if (!memcmp(mute, unmuted, ARRAY_SIZE(mute))) {
^~~~~~~~~~
l1_if.c:1388:51: note: declared here
int l1if_mute_rf(struct femtol1_hdl *hdl, uint8_t mute[8], l1if_compl_cb *cb)
^~~~
In file included from l1_if.c:32:0:
/include/osmocom/core/utils.h:13:30: error: ‘sizeof’ on array function parameter ‘mute’ will return size of ‘uint8_t * {aka unsigned char *}’ [-Werror=sizeof-array-argument]
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
^
l1_if.c:1408:19: note: in expansion of macro ‘ARRAY_SIZE’
for (i = 0; i < ARRAY_SIZE(mute); ++i)
^~~~~~~~~~
l1_if.c:1388:51: note: declared here
int l1if_mute_rf(struct femtol1_hdl *hdl, uint8_t mute[8], l1if_compl_cb *cb)
^~~~
Change-Id: Id040aeb35549ddb75072942be0093064a89092a6
Fixes following compilation warning:
osmo-bts/src/osmo-bts-sysmo/sysmobts_vty.c:349:3: warning: implicit declaration of function ‘lchan_deactivate’
Change-Id: I1dba0b08fdb2af199f009842c9abf32e25f74be1
This way we give the opportunity to the BSC to release the channel
quicker, otherwise it has to wait until T3101 expires.
Same procedure is already done in rsl.c rsl_rx_imm_ass() when we return
an error (hard limit AGCH queue len reached) from bts_agch_enqueue().
Related: OS#2990
Change-Id: Id9927c0789054ce3ecc7b30380585a1ffe05db5a
We saw in a recent prod setup a BSC with saturated channels. Further
investigation lead to a AGCH queue of 1000 (previous hard_limit)
messages, most of them being regular IMM ASSIGN (non REJ). Hence, we
also want to get rid of other messages in the AGCH queue (like regular
IMM ASSIGN).
Furthermore, In this scenario, sending IMM ASS REJ is as important as other
messages given than nowadays we support dynamic wait indicatior
(calculated based on chan load), which means if we reach the MS, we can
tell it to wait for a long time to reach us again, which is desirable.
Change-Id: I022b8948da8be13fb8f4bc36e7c9dab11c35fddb
In a prod setup, complete channel saturation at the bsc was detected,
and Immediate Assignments were not being answered by the MS once sent by
the BTS.
Further investigation showed that the BTS was all the time printing
messages like this:
"bts.c:540 AGCH: too many messages in queue, refusing message type 0x3f, length = 1001/10"
So it seems the AGCH queue was becoming incredibly full (1000, hard
limit triggered the log), while acgch_queue.max_length was set to 10.
As a result, most probably the Immediate Assignments being sent to the
MS are super old in time, and the MS doesn't known about them anymore
once they are receivied, so no answer is sent back.
Let's try to avoid that by decreasing the hard limit so we never reach
that big queue_len scenario.
The number 100 is selected from data gatherered in agch_test.c which
prints a table of max_length values based on different setups. Some
values can reach around 80 messages, so let's use a slightly bigger hard
limit.
Related: SYS#2695
Change-Id: I272798c959abec123776d2fa8dad5685ec512fbd
It seems I somehow mischecked that the required include for gsm48_rr_msg_name
was not yet present in the file.
Fixes: 44a35902ad
Change-Id: Ia82bc6a5ff7e3989cf0b85ee689d0c3344720eda
The current implementation does not allow the user to specify a port
range in which the BTS is allowed to allocate a local RTP port. Also
the ports the BTS picks do not match the policy described in RFC3550.
An RTP Port must be at an even port number and the matching RTCP
port must be at the following (odd) port number. The BTS currently
picks random port numbers for both.
- Add a VTY command to specify a port range in which the BTS may
assign local ports.
- Pick ports as described in RFC3550.
Change-Id: Id75f1dfaf898ed8750d28b1c4840e188f4cfdc87
Related: OS#2825 OS#2635
When we introduced the n_s verification in
2cc37035d7, the variable name n_s was
used for what is actually n_r N(R) read from the LAPDm frame
Change-Id: Iaef1648f35ceae9d7f4cd1d9d5409e05115d199a
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
A frequent configuration file error is that the unit_id settings of
osmo-bts and osmo-bsc don't match. The BSC already prints an error
in this case. Let the BTS print an error as well.
We use a heuristic for this purpose: If the OML link is dropped within
10 seconds after being established, log a special warning which alerts
the user and recommend a manual configuration file check.
Change-Id: I476ac797458b5a46edea3ae9cfbd491fd7f77f47
Related: OS#3143
To allow switching a dyn TS also between TCH/H <-> TCH/F and anything else,
don't thwart RSL messages just because their chan_nr doesn't reflect the
current pchan mode. For dyn TS, leave that to message handling.
In particular, a TS switch is invoked by a Chan Activ message, in which case
the current pchan by definition mismatches the incoming chan_nr's reflected
channel type.
With this patch, I have tested successful direct TCH/H<->TCH/F switchover on
sysmoBTS, with osmo-bsc patch I72d5d833b186b1e1925d513885b405d8c19aa496 (and
'msc'/'codec-list' vty config to change TCH kinds while gprs mode was none).
Change-Id: I19e5e509101ec91204de9baff04582d99bc8dcb8
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
The existign code only sent an ERROR REPORT, but it failed to actually
send a proper NACK to the related request. This is confusing, as the
operation should always be ACKed or NACKed, and not simply result in no
response.
Change-Id: Ic374a8e5e239ffe37082a54cdb94cb6ac9723e83
Closes: OS#3254
Whenever we encounter an error condition during processing of RSL CHAN
ACT or RSL MODE MODIFY, it's insufficient to simply send an RSL ERROR
INDICATION, but we also must send a proper NACK back to the BSC.
Change-Id: I4dd7ff2fd2cdbc6e892cd329c826ac1bc3b16bb9
The code actually always *wanted* to make lchan activation fail in
case we don't support the algorithm, but it failed ot do so.
The problem is encr_info2lchan() which uses bts_supports_cipher() to
determine if the cipher is supported. However, if bts_supports_cipher()
returns 0 (not supported), it uses this value as return value of
encr_info2lchan() where '0' means success (standard osmocom convention).
This results in channel activation proceeding, which it shouldn't.
Change-Id: I46275b8fc2a1a74f68b4cc60e0f64ba226b108cd
Related: OS#3254
This logging turned up while I was debugging dynamic timeslots:
- OML Set Channel Attributes logging.
- a specific dyn TS pchan error.
- show pchan and lchan types on CHAN ACT ACK and REL ACK logging.
- on RSL message Rx, log the current pchan kind in detail, using
gsm_ts_and_pchan_name(). This logs the underlying pchan as well as the
current pchan mode a dyn TS is in.
- move 2 dyn TS logging from DL1C to DRSL, where all the other dyn ts logging
is.
Change-Id: Ia89c134060e85f7065afd5642d1c541c65dd25ea
In early rsl_rx_chan_activ(), do not use rsl_tx_chan_act_acknack() to trigger
sending a NACK, instead use rsl_tx_chan_act_nack() directly.
Rationale: the previously used rsl_tx_chan_act_acknack() may decide to omit the
NACK, particularly based on the lchan->rel_act_kind. lchan->rel_act_kind
indicates whether the Chan Release or Activation was explicitly requested via
RSL, and thus whether an ACK/NACK should go back to RSL or not. This gets set
only late in rsl_rx_chan_activ(). We cannot set it on top, because we need to
first establish whether the Chan Activ is permitted or not. In case of early
rejection of the Chan Activ, we do not want to modify the lchan state, but
merely reply with a NACK, unconditionally.
Before this patch, NACKs that rsl_rx_chan_activ() wants to trigger would
possibly be not be sent out on RSL, because lchan->rel_act_kind is not
explicitly initialized until later.
Fixes: BTS_Tests.TC_dyn_ipa_pdch_act_tchf_act_nack
Change-Id: Ic981f768cc024f0acd3d7ae55846cfbc7bc089ce
When an RF CHANnel RELease request is received on an already released lchan,
there is no "REL NACK" message or similar, we just ACK the release.
When ACKing the release, make sure to reflect the same chan_nr that the release
was asked for, since the lchan state may actually reflect a different chan_nr.
Factor the actual Rel Ack message sending out of rsl_tx_rf_rel_ack(), which
makes all sorts of decisions around normal Rel Ack: add static tx_rf_rel_ack(),
with chan_nr argument instead of deriving chan_nr from the lchan.
Use this to directly ACK an unusual Chan Rel with the chan_nr that came in with
the request.
Fixes: BTS_Tests.TC_dyn_osmo_pdch_unsol_deact
(after I6b790e866ce4e66d9385b286b727ae41a83d3e67)
Change-Id: Iceaa2e87874ced42d664a2a0b01a1c59e46a19b3
Make osmo-bts send a State Changed Event Report when RF is locked
or unlocked. This behaviour isn't mentioned in the spec as far as
we know, but an ipaccess nanobts also produces these messages.
Change-Id: I37e44ef4881c41f8835428b610e7863f37397c9f
Related: OS#3161
In gsm_lchan2chan_nr(), use a switch to reflect both dyn TS kinds and enrich
with comments. Move GSM_PCHAN_TCH_F_PDCH out of gsm_pchan2chan_nr(), which is
now back to pure standard PCHAN values.
Rationale: it's easier to figure out what is going on and why.
Change-Id: I6a31b44220d97c9173c52d3567a1382541710d10
For ip.access style TCH/F_PDCH, this fixes switch-back to PDCH in case the TCH
use employed encryption.
For Osmocom style TCH/F_TCH/H_PDCH, do the same, purely out of sanity. Roughly
the same should already be happening during PDCH Chan Activ, but make sure to
clear all these fields, so they are cleared even if IEs are missing.
From both dyn TS code paths, call new clear_lchan_for_pdch_activ(), which
clears the same fields that are normally overwritten by an RSL Chan Activ.
Related: OS#3238
Change-Id: I8451039683b54bee910c97c5a3e6873e0ff1b160
When the PCU is not connected, we immediately call rsl_tx_rf_rel_ack() because
we don't need to wait for a PDCH deactivation. Fix: properly mark rel_act_kind
= LCHAN_REL_ACT_PCU to invoke identical behavior as when the PCU were involved.
(When the PCU is connected, a PDCH release on an Osmocom style dyn TS causes an
actual release of the PDCH TS, and then triggers an rsl_tx_rf_rel_ack() with
rel_act_kind == LCHAN_REL_ACT_PCU.)
Clarify the code flow: rc == 1 is the special case of no PCU being connected,
so have that in a separate if{}.
Change-Id: I654b963815b32fcbce050c2e15f3190c97bc259f
When a release of PDCH is complete, actually set the dyn.pchan_is to NONE.
Failure to do so currently caused errors on activation of an Osmocom style dyn
TS as TCH, in the shape of:
rsl.c:636 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK
rsl.c:164 (bts=0,trx=0,ts=2,pchan=TCH/F_TCH/H_PDCH switching PDCH -> NONE) RSL rx DCHAN: mismatching chan_nr=0x12
rsl.c:2611 Rx RSL CHAN_ACTIV for unknown lchan
rsl.c:710 0x12: Sending Channel Activated NACK: cause = 0x64
The Tx RF CHAN REL ACK shows that we're through with PDCH release, but the
following line showing "chan=TCH/F_TCH/H_PDCH switching PDCH -> NONE" shows
that the state still reflects active switching. Thus the DCHAN code decides
that the chan_nr = 0x12 reflecting a TCH/H on TS 2 is a mismatch and NACKs the
TCH activation.
(For ip.access style TCH/F_PDCH, the ts->flags are cleared in
ipacc_dyn_pdch_complete()).
Related: OS#3235
Change-Id: Ic06c8f0fe82ae8a06afa5defd93a685010687965
Use a switch statement and ample comments to clarify what is done and why.
Cosmetically prepares for Ic06c8f0fe82ae8a06afa5defd93a685010687965.
Related: OS#3235
Change-Id: I8a9953b011a4516972aae468754494f57ebc0a3f
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
The caller translates errno values back into NACK codes anyway,
so lets's return NACK codes directly.
Change-Id: I2b1f79e66c778139d64101c89dd6377921807e2d
Related: OS#2295
In addition to logging an error, send a NACK if the BSC attempts
to set more than one ARFCN in Radio Carrier Attributes for a BTS
which does not support frequency hopping.
Change-Id: Ia72e23a3f08f825cf9cf0d9a55302d13cfed51d6
Related: OS#2295
Pau Espin
Harald Welte
Philipp Maier
Stefan Sperling