/usr/bin/ld: /home/laforge/projects/git/osmo-bts/tests/sysmobts/../../src/osmo-bts-sysmo/tch.c:584: undefined reference to `femtobts_tch_pl_names'
/usr/bin/ld: l1_transp_hw.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:108: multiple definition of `pdch_msu_size'; main.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:108: first defined here
/usr/bin/ld: l1_transp_hw.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:71: multiple definition of `femtobts_l1prim_type'; main.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:71: first defined here
see also: https://alioth-lists.debian.net/pipermail/debian-mobcom-maintainers/Week-of-Mon-20200413/000651.html
Change-Id: I4a9896153876fcda496365776883827746205f00
When a bad SACCH frame is received the processing of the frame is ended
early and lchan_ms_pwr_ctrl() is not called. This means that the power
control loop does not get informed about a situation where the signal
level is very weak and increasing the ms power would make sense. In
order to ensure that the power control keeps working on lost SACCH
frames, lets call lchan_ms_pwr_ctrl() with the current RSSI and the
requested (BSC) power setting.
Related: OS#4281
Change-Id: I4fb85754b1a69376b02da7f4b175c6e8ec9cc35c
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
osmo-bts-trx used to have its own (low-level) MS Power Control loop,
but recently it has been ripped out. Since [1], the process fails to
start if the configuration file still contains 'ms-power-control dsp'.
Let's be more tolerant: override 'dsp' by 'osmo' and print a warning.
[1] I49706926b1e962b18791174627bc3cc0cd0cd9d5
Change-Id: I4facd21bca3d8cb80d21e83ea267bc013e474533
Rename some variables so that:
* Variables containing power control levels end up with "_lvl".
* Variables containing power levels end up with _dbm.
* Move old current_dbm var to be ms_dbm, to match its power control
level counterpart ms_power_lvl, and add current_dbm to match its
counterpart ns_power_ctrl.current.
Now that variables are more clear, it also becomes clear that old "diff >
0" condition, apart from difficult, was currently wrong, since in order
to print the raise/low verb we want to compare between old and new
values, not between received and new values. Let's fix that in this same
commit.
Change-Id: I4e279a6b93fbcc5da25bf8c9213310939fd493ce
Simplify when the fixed field is set in rsl_rx_chan_activ.
Comment talks about enabling autonoumous control loop, but it is
actually describing it when disabling it, which is confusing.
Change-Id: Id6b444a33ab062f6dab11a0ce62d8aecaea87591
When logging about filtering access bursts, let's indicate if this is
on a CCCH, PDCH or handover related.
Change-Id: I03f21f2b54cbe5aad36ac71a614d5df98867df80
This way it's much easier to introspect the library internal
talloc allocations from the VTY interface.
Change-Id: Ic8d9fc7ce3da8abf0ea73d2b20366133cd801c37
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
Since there can be multiple PDCH channels configured on different
timeslots, different TRXes, and BTSes, the PTCCH/U handling code
in OsmoPCU needs to know the exact origin of a given RACH.ind.
Otherwise, it is not known which subscriber originated a given
PTCCH/U indication, and hence it is impossible to send PTCCH/D
Timing Advance notification properly.
Fortunately, we can extend the RACH.ind message without even
bumping the protocol version, because every single PDU has a
fixed size defined by the largest message - INFO.ind. In case
if the actual message payload is smaller, the rest is filled
with a constant padding byte (0x00).
Older versions of OsmoPCU will consider the new fields as padding,
while the messages from older OsmoBTS versions will always have
both fields set to 0x00. Since C0/TS0 cannot be configured to
PDCH, this can be easily detected on the other end.
Change-Id: Iff38934a108b6b1cd298669834263a7d5296c3f6
Related: OS#4102, OS#1545
It's not a good idea to request big changes in MS Power based on
sporadic bad signal received, let's instead change announced MS power
levels more smoothly to avoid possible big signal strength fluctations,
similar to what is already done in osmo-bts-trx specific loop (loops.c).
Related: OS#1851
Change-Id: Iecc4ec7e21471ec853ad2d5659af4052aba5444c
Use instead the received MS Power currently in use by the MS matching
the measured signal. This way there's no need to wait for the MS to
reach the announced MS power level or add checks in case the MS doesn't
support that specific power level. Furthermore, more fine grained
announced power level value can be obtained faster due to more input
iterations not being dropped while waiting.
osmo-bts-trx specific algo was not following this approach and using
announced MS power instead because it's wowrking at a lower level and
henche was not using the transmitted MS Power level value by the MS as
input for the calculation.
The "if (diff < 2 && diff > -2))" condition is dropped since equal
signal strength may still result in a different MS power level announced
(the one currently used by the MS during tx of last SACCH block).
Related: OS#1851
Change-Id: I4494dc27a295a3dca1d3331d4ff712d486643e13
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
Fix error while starting osmo-bts-virtual with the example config:
"This BTS model has no DSP/HW MS Power Control support"
Fixes: c693067b7e ("Introduce BTS feature BTS_FEAT_MS_PWR_CTRL_DSP")
Change-Id: I4f9a06e85d58294719a24197eb1c42a69fbd03d6
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
Several improvements have been made lately to MS Power Control loop from
osmo-bts-trx in loops.c. Let's port these to the common algorithm.
Related: OS#1851
Change-Id: I579967cc8bb69dc76a315c6c9d3a351f5961d92f
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
Thies field is used to store and retrieve whether MS power needs to be
calculated and updated by osmo-bts software or autonomously by lower
layers. Previous name was not clear
and may have been understood as indicating whether MS Power Control loop
is done or not in general, and the responsible for that is located under
lchan's ms_power_ctrl.fixed.
Related: OS#1851
Change-Id: Ic690ab69866a7377f1597e24aa7b0214831c1cbe
Some bands, such as DCS1800, contain power levels such as 29, 30 and 31 not following same
unified sequence other power levels follow regarding conversion to dBm
values.
This makes extremly complex and prone to error comparing different power
levels. Let's instead use dBm values to calculate and crop desired new
value, and then convert it back to TS 05.05 ms power control level
value.
With this commit the control loop should be able to manage correctly the MS power
levels explained above.
Related: OS#4244
Change-Id: I0160637c5ffa606ee3081ad30be8e6f2a42b725b
Otherwise older ms_power value will be kept and used as a maximum.
From TS 08.58 sec 4.8 "MS power control":
"""
If power control is supported by BTS and it is to be used,
this is indicated by optional parameters in the MS POWER CONTROL
message (or the CHANNEL ACTIVATION message). Based on the
measurements performed on the uplink, TRX then attempts to keep
the power control parameters within the limits set by the
MS POWER CONTROL message (or by the CHANNEL ACTIVATION message).
"""
Change-Id: I0583eef477c33279ee5bfcda80141f365413a276
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
This is similar commit to Ifda92155bd9c277ac150a327a7ab63c854087788,
which previously fixed same issue for osmo-bts-trx specific power
control loop code.
TS 48.058 sec 4.8 MS power control:
"""
TRX then attempts to keep the power control parameters within the limits
set by the MS POWER CONTROL message (or by the CHANNEL ACTIVATION message)
by changing the MS Power Level field of the L1 header sent to MS in each
SACCH block.
"""
Should fix TTCN3 BTS_Tests.TC_rsl_ms_pwr_dyn_max for non-bts-trx BTS
models.
Related: OS#1622
Change-Id: I376b52d7bee44132993a69cf532bd418171d0ca2
TS 48.058 sec 4.8 MS power control:
"""
TRX then attempts to keep the power control parameters within the limits
set by the MS POWER CONTROL message (or by the CHANNEL ACTIVATION message)
by changing the MS Power Level field of the L1 header sent to MS in each
SACCH block.
"""
Fixes TTCN3 BTS_Tests.TC_rsl_ms_pwr_dyn_max
Change-Id: Ifda92155bd9c277ac150a327a7ab63c854087788
All other Uplink burst handlers print frame number of the last
(currently received) burst. Let's make rx_data_fn() consistent.
Change-Id: Ie5762a132326be3ef4e4e38cc126f05d51098a20
Make it obvious for compilers and for coverity, that the sapi value used
to shift a bit for the sapi_mask is always <= 31. The sapi value is an
index of the value string l1sap_common_sapi_names, which has 24 entries.
Fixes: CID#205067, CID#205068
Change-Id: Id8be0ab67479b1f76a4f624bd3a5242e4fe59f4b
Change uint8_t sapi to int, so we can properly assert on errors from
get_string_value().
Fixes: CID#205066, CID#205069
Change-Id: I4d30afacfab93051868ae8f462cee9ad3dbc7fd0
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
Add a new common L1 SAPI enum, to unify all the BTS specific SAPIs.
Translate to this enum, and set the context for uplink messages in
each BTS specific implementation.
Set the context for downlink messages in the common l1sap code, by
converting the osmo_phsap_prim back to the SAPI value (mostly looking at
chan_nr). The new functions for doing this conversion,
get_common_sapi_by_trx_prim() and get_common_sapi_ph_data(), are based
on the existing to_gsmtap() and gsmtap_ph_data() functions.
Note that we can't set the uplink SAPI context in the common code,
because then we can't set it as early as possible. In this patch, the
SAPI context is set for the PHYs where the SAPI is readily available.
With additional conversion from the RSL channel, the SAPI context could
be set for osmo-bts-trx in a follow up patch.
Related: OS#2356
Depends: (libosmocore) I814cb3328d99faca9220adb5a80ffb934f219d7d
Change-Id: I6b7bb2e1d61502b61214f854a4ec5cbb7267545b
The ticket has been closed, BER and C/I measurements are now being
sent to OsmoPCU (see Ia58043bd2381a4d34d604522e02899ae64ee0d26).
Change-Id: I1909a70b82421802f32c1bc4f69a2e4210db5b2d
We don't know whether a data block on PDCH belongs to PDTCH or PACCH
without parsing it, because the latter one is being allocated on
demand. Let's use GSMTAP_CHANNEL_PDTCH by default, rather than
GSMTAP_CHANNEL_PACCH.
Change-Id: I7639215ef936a8ac05ca417a91f4e12755f318d4
First of all, we also need to apply the same filtering to Access
Bursts on PDCH as for the normal ones on RACH, i.e. filter them
by ToA (Timing of Arrival) and BER (Bit Error Rate).
Secondly, we shall not interpret Access Bursts on PDTCH/U as
handover related ones. Instead, let's print a warning and
ignore them since they are not (yet) supported by OsmoBTS.
Finally, in gsmtap_pdch() we need to set a proper channel type
for Access Bursts received on PDCH (PDTCH/U or PTCCH/U).
Change-Id: I461fde9f4543c45c42b591cd3fd0ff3d98673cec
RACH stands for Random Access CHannel, while in rach_pass_filter()
we're dealing with Access Bursts, that may be received on other
logical channels too (e.g. PTCCH, PDTCH or any other).
Change-Id: I1e5ca9930ab491a6916c972865154d54530cbf51
Currently we don't distinguish between CBCH on BCCH+SDCCH/4 and
CBCH on SDCCH/8, but in libosmogsm we have two independent
(non-standard) RSL channel number values for them. Maybe some day
we will, so let's extend the definition of L1SAP_IS_CHAN_CBCH.
Change-Id: I2f6d501a29edaf89dfb17d5d64f930cdb1943630
After getting rid of transceiver_available, this function is not used
anymore by any code, since its per-trx counterpart
l1if_provision_transceiver_trx() is the one used by other
code.
Change-Id: If5a988eb14658a78dd46234dccc052dc12fb872a
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
Use of variables in each code is confusing and mixing configuration with
POWERON/POWEROFF state (which is at least per phy inst and not per TRX,
since those commands are only expected on the 1st phy inst).
* field "poweron" becomes "enabled", and is used as an indicator for
actions to take during TRX provisioning (hether to power it on and
configure it or to power it off).
* poweron/poweroff state becomes "powered", and it is shared by all trx
in same phy_link, and is updated only after confirmation by TRX.
* poweron_set becomes poweronoff_set (because it's used by both POWERON
and POWEROFF), and becomes shared by all trx in same phy_link, since
those CMDs are usually sent by first phy instance of the link (the first
trx).
Related: OS#4215
Change-Id: Icd0b482f1454236432e1952220bbec9d178b8607
check_transceiver_availability() is a loop over every trx, same to what
trx_set_bts() does, so let's call the per-trx version directly.
Change-Id: I8843c1438c6af700631aba7b7e72aae0bdb7ec3a
Currently there's bts-virtual specific fields in gsm_bts which is not used
by other models and are always allocated.
An alternative would be having a union with different structs inside,
one per model, but since we already have the bts_model abstraction, in this
case it makes more sense to use that abstraction instead of filling code
with preprocessor ifdefs to guard against non-defined types, etc.
Existing model specific data is moved there.
This new infra will be user further in forthcoming commits.
Related: OS#4215
Change-Id: Ib17a752cdbaa7d5eb8c5dfa0b197f80a4f38b38e
QTA is a Timing Advance value in units of 1/4 of a symbol. Let's
use ToA256 (1/256 of a symbol) field of L1SAP RACH.ind as a base
for QTA calculation in order to achieve better precision.
Change-Id: I6e6fa7985c430a9bdbd12af2a8b2a5a66f11a41c
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
According to 3GPP TS 45.010, section 5.6.2, for packet-switched
channels the BTS shall monitor the delay of the Access Bursts
sent by the MS on PTCCH and respond with timing advance values
for all MS performing the procedure on that PDCH.
According to 3GPP TS 45.002, section 3.3.4.2, PTCCH (Packet Timing
advance control channel) is a packet dedicated channel, that is
used for continuous Timing Advance control (mentioned above).
There are two sub-types of that logical channel:
- PTCCH/U (Uplink): used to transmit random Access Bursts
to allow estimation of the Timing Advance for one MS in
packet transfer mode.
- PTCCH/D (Downlink): used by the network to transmit
Timing Advance updates for several MS.
As per 3GPP TS 45.003, section 5.2, the coding scheme used for
PTCCH/U is the same as for PRACH as specified in subclause 5.3,
while the coding scheme used for PTCCH/D is the same as for
CS-1 as specified in subclause 5.1.1.
The way we used to handle both PTCCH/U and PTCCH/D is absolutely
wrong - they have nothing to do with xCCH coding. Instead, we
need to use tx_pdtch_fn() for Downlink and rx_rach_fn() for Uplink.
In l1sap_ph_rach_ind() we need to check if an Access Burst was
received on PTCCH/U and forward it to OsmoPCU with proper SAPI
value (PCU_IF_SAPI_PTCCH). To be able to specify a SAPI, a new
parameter is introduced to pcu_tx_rach_ind().
Change-Id: I232e5f514fbad2c51daaa59ff516004aba97c8a3
Related: OS#4102
Otherwise using "logging level set-all info" makes it impossible to see
anything in VTY due to tons of those two lines appearing.
Change-Id: I9c7500c1e56db0c4dcb474f93c882a9c7c004d55
If VTY cmd "osmotrx trxd-max-version 0" is used, max version 0 is used
(default starting one) and hence no need to send SETFORMAT (this is
useful in order to avoid sending SETFORMAT to old TRX implementations
not supporting the command). In this case, let's inform the user that
indeed osmo-bts won't send SETFORMAT because version 0 is assumed.
Change-Id: I7136ea6745c2275278bc400676b58fb4b10da966
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
All MS/UE must be notified of ETWS Primary Notifiations.
Depending on their state, the notification goes different paths:
* CS dedicated mode: BSC sends it as L3 message over LAPDm / DCCH
* CS/PS idle mode: BTS sends paging messages on PCH
* PS TBF active: PCU send Packet Application Info
This enables the last of the three methods by passing any
ETWS Primary Notifications received over RSL via the PCU socket into
the PCU.
Change-Id: Ic0b3f38b400a0ca7e4089061ceb6548b0695faa6
Related: OS#4047, OS#4048
The ETWS (Earthquake and Tsunami Warning System) uses a so-called
ETWS Primary Notification which is sent
* to phones in dedicated mode (via DCCH from the BSC)
* to phones in idle mode (via P1 Rest Octets on PCH/CCCH)
This patch implements the second part of the functionality, i.e.
transmitting the related ETWS Primary Notification via PCH. As
3GPP doesn't specify how this is communicated over Abis, we use
a new, vendor-specific RSL message type.
Closes: OS#4047
Depends: libosmocore I89c24a81ada6627694a9632e87485a61cbd3e680
Depends: libosmocore I36fc2ffc22728887d1cb8768c7fcd9739a8ec0fc
Change-Id: I18c60cdb86b9c19e09f5ec06d66e9b91608880e6
Convert the cell identity to LE when sending it to the PCU via unix
socket, just like we do it with the location area code.
In the Osmocom stack, the CellID is configured in OsmoBSC, sent as BE
via RSL to OsmoBTS, then with a socket to OsmoPCU (where OsmoPCU expects
it to be LE in a LE system). OsmoBTS was always sending the CellID as
BE to OsmoPCU. In March 2018, a regression in OsmoPCU [1] caused an
endianness swap in the CellID on LE systems, resulting by chance in the
correct, LE encoded, CellID as it should have been sent from OsmoBSC
(for LE systems). This regression was fixed in March 2019 [2].
I've verified this fix with a TTCN3 test [3].
[1] I787fed84a7b613158a5618dd5cffafe4e4927234 (osmo-pcu)
[2] I2f6cc930c5dbf8dac386b24b0756df2efe8199e4 (osmo-pcu)
[3] I6516808f4b9e9a2301f9ccc1e55ded14e7334c33 (osmo-ttcn3-hacks)
Related: OS#3854
Change-Id: I68faf4558f0686fb2a3db24077dceaae05bf0262
Some commits started using libosmocore APIs
osmo_gsm48_rest_octets_si3_encode() and lapdm_channel_init2(), which are
only available in latest libosmocore release 1.2.0. Let's update
configure.ac accordingly.
Fixes: 1e96e31c10
Fixes: 46d62b984a
Change-Id: If84c53d8192e8db98eb9439b898d83e94c5e5476
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
API osmo_stats_vty_add_cmds never had a param list but has seem problem
(no "void"), so some users decided to pass a parameter to it.
Change-Id: Ia4d1a7914308d1481fe31fe0986265ead339e61e
Related: OS#4138
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
If the BSC has instructed the BTS via RSL to not autonomously perform
MS power control, we are storing this in lchan->ms_power_ctrl.fixed.
However, osmo-bts-trx would simply ignore that flag in loops.c and
continue to compute new MS power values based on measurement results.
Change-Id: I628d1f4f1094c22248d372c11c2ecc504135b757
This command allows setting a maximum TRXD format version to negotiate
with TRX. osmo-bts-trx will hence end up using that version if supported
by TRX, or a lower one otherwise (or fail if TRX doesn't support any of
them).
Since now the maximum version can be 0, avoid going through SETFORMAT
negotiation in that case, since 0 is the default version. This way we
keep backward compatibility with TRX implementations that exit upon
receival of unknown commands (such as SC5 current one).
The VTY command is located in the "phy" node instead of the "phy
instance" node because instances of same phy are expected to use same
host with same implementation, so TRXD version to use should be the same
for both.
Related: OS#4006
Change-Id: I5eb1fdc002f9d7f4acf475356d8fc998dc8f6326
The radio link quality is defined by C/I (Carrier-to-Interference
ratio), which is computed from the training sequence of each
received burst, by comparing the "ideal" training sequence with
the actual (received) one.
Link quality measurements are used by L1SAP to filter out "ghost"
Access Bursts, and by the link quality adaptation algorithms. One
can define minimum link quality values using the VTY interface.
On the VTY interface we expect integer C/I values in centiBels
(cB, 10e-2 B), while the internal structures are using float
values in deciBels (dB, 10e-1 B). Some PHYs (sysmo, octphy,
oc2g, and litecell15) expose C/I measurements in deciBels,
while on the L1SAP interface we finally send then in centiBels.
Let's avoid this confusion and stick to a single format, that
will be used by the internal logic of OsmoBTS - integer values
(int16_t) in centiBels. This will give us the range of:
-32768 .. 32767 centiBels, or
-3276.8 .. 3276.7 deciBels,
which is certainly sufficient.
Change-Id: If624d6fdc0270e6813af8700d95f1345903c8a01
It was noticed with old Sony Ericsson phones (like W595 and K510i)
that the service provided by Osmocom network becomes unreliable
from time to time. The RSSI indicator on those phones shows that
the signal is lost, so neither CS nor PS services are working.
As it then turned out, System Information 3 broadcasted on the
Um interface is different than the one received from the BSC.
In particular, the content of SI3 Rest Octets IE is different.
Among with the 'GPRS Indicator', which is actually expected to
indicate whether the PCU is connected or not, SI3 Rest Octets
on the Um interface contain both 'Optional Power Offset' and
'Scheduling if and where' IEs, which are not present in the
original messages from the BSC.
Moreover, as soon as the PCU is connected, 'GPRS Indicator' IE
contains different 'GPRS RA Colour' value, and informs the MS
that System Information 13 is sent on extended BCCH, which
is not even supported by OsmoBTS!
The culprit is in rsl_rx_bcch_info(), where we pass a pointer
to osmo_gsm48_rest_octets_si3_decode(). Instead of passing a
pointer to the beginning of SI3 buffer, we actually need to
shift it to the beginning of the SI3 Rest Octets IE.
This change makes my Sony Ericsson phones happy ;)
Change-Id: Ia962cf21903ba674057cf52746996dd3254bc1c6
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
Both TRX2L1 (Uplink) and L12TRX (Downlink) messages should use
the same TRXD header format (and version) as was negotiated.
Change-Id: Idbc598ef7c1871ee8da830f3fbe0a5cc386f873d
Related: OS#4006
This change introduces a new command for TRXD header format
negotiation - SETFORMAT. If the transceiver does not support
the format negotiation, it would reject this command with
'RSP ERR 1'. If the requested version is not supported by
the transceiver, status code of the response message should
indicate a preferred (basically, the latest) version.
The format of SETFORMAT command is the following:
L1 -> TRX: CMD SETFORMAT VER_REQ
L1 <- TRX: RSP SETFORMAT VER_RSP VER_REQ
where:
- VER_REQ is the requested version (suggested by the L1),
- VER_RSP is either the applied version if matches VER_REQ,
or a preferred version if VER_REQ is not supported.
If the transceiver indicates VER_RSP different than VER_REQ,
OsmoBTS is supposed to reinitiate the version negotiation
using the suggested VER_RSP. For example:
L1 -> TRX: CMD SETFORMAT 2
L1 <- TRX: RSP SETFORMAT 1 2
L1 -> TRX: CMD SETFORMAT 1
L1 <- TRX: RSP SETFORMAT 1 1
If no suitable VER_RSP is found, or the VER_REQ is incorrect,
the status code in the response would be -1.
As soon as VER_RSP matches VER_REQ in the response, the process
of negotiation is complete. Changing the header version is
supposed to be done before POWERON.
Change-Id: I8afe950bd1ec2afaf3347ff848ee46e69c4f5011
Related: OS#4006
Since we may have different versions of the TRXD header, some new
fields of an Uplink burst indication have conditional presence.
Therefore we need a smart function to print them conditionally.
Change-Id: I68729dc98a1840d2aa9e091153d176a103d5a228
Related: OS#4006
This kind of debugging can be done using trx_sniff.py tool from
the TRX Toolkit [1]. Probably, this code was needed during the
initial development and testing.
[1] https://git.osmocom.org/osmocom-bb/tree/src/target/trx_toolkit
Change-Id: I50e0e5feeba4c3028f55209dd8e41e09ed5f70b1
The new version adds the following fields to the TRX2L1 message,
keeping the L12TRX message unchanged:
+------+-----+-----+-----+--------------------+
| RSSI | ToA | MTS | C/I | soft-bits (254..0) |
+------+-----+-----+-----+--------------------+
- MTS (1 octet) - Modulation and Training Sequence info, and
- C/I (2 octets) - Carrier-to-Interference ratio (big endian).
== Coding of MTS: Modulation and Training Sequence info
3GPP TS 45.002 version 15.1.0 defines several modulation types,
and a few sets of training sequences for each type. The most
common are GMSK and 8-PSK (which is used in EDGE).
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . . . . . X X X | Training Sequence Code (0..7) |
+-----------------+---------------------------------------+
| . X X X X . . . | Modulation, TS set number (see below) |
+-----------------+---------------------------------------+
| X . . . . . . . | IDLE / nope frame indication (0 or 1) |
+-----------------+---------------------------------------+
The bit number 7 (MSB) is set to high when either nothing has been
detected, or during IDLE frames, so we can deliver noise levels,
and avoid clock gaps on the L1 side. Other bits are ignored,
and should be set to low (0) in this case.
== Coding of modulation and TS set number
GMSK has 4 sets of training sequences (see tables 5.2.3a-d),
while 8-PSK (see tables 5.2.3f-g) and the others have 2 sets.
Access and Synchronization bursts also have several synch.
sequences.
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . 0 0 X X . . . | GMSK, 4 TS sets (0..3) |
+-----------------+---------------------------------------+
| . 0 1 0 X . . . | 8-PSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 0 1 1 X . . . | AQPSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 0 X . . . | 16QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 1 X . . . | 32QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 1 1 X . . . | RESERVED (0) |
+-----------------+---------------------------------------+
== C/I: Carrier-to-Interference ratio
The C/I value is computed from the training sequence of each burst,
where we can compare the "ideal" training sequence with the actual
training sequence, and then express that difference in centiBels.
== Limitations
- The only supported modulation types are GMSK and 8-PSK.
Messages with other modulation types will be rejected.
- IDLE / NOPE indications are not (yet) handled.
- The logical channel handlers do not (yet) handle optional
fields, such as TSC and C/I. This will be implemented
in the follow-up changes.
Change-Id: If61c71d20d590bf07bfd019afb33000a0b6135bd
Related: OS#4006
It may be necessary to extend the message specific header with
more information. Since this is not a TLV-based protocol, we
need to include the header format version.
+-----------------+---------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------+
| X X X X . . . . | header version (0..15) |
+-----------------+---------------------------+
| . . . . . X X X | TDMA TN (0..7) |
+-----------------+---------------------------+
| . . . . X . . . | RESERVED (0) |
+-----------------+---------------------------+
Instead of prepending an additional byte, it was decided to use
4 MSB bits of the first octet, which used to be zero-initialized
due to the value range of TDMA TN (0..7). Therefore the current
header format has implicit version 0.
Otherwise Wireshark (or trx_sniff.py) would have to guess the
header version, or alternatively follow the control channel
looking for the version setting command.
This change introduces a new structure 'trx_ul_burst_ind', which
represents an Uplink burst and the corresponding meta info. The
purpose of this structure is to avoid overloading the existing
functions, such as trx_sched_ul_burst(), with more and more
arguments every time we bump the version.
On receipt of a TRXD message, trx_data_read_cb() now parses
the header version, and calls the corresponding dissector
functions, e.g. trx_data_handle_(hdr|burst)_v0().
Change-Id: I171c18229ca3e5cab70de0064a31e47c78602c0c
Related: OS#4006
This constant actually defines the maximum TRXD message length,
which includes the header and burst bits, not just burst.
Change-Id: I383125e1c4df039fc6b554833bc8736deacbe731
Otherwise t200_ms_dcch array values are left uninitialized with random
values, and passed later on to lapdm_channel_init2().
lapdm_channel_init2() will anyways fail during initial check on
get_n200_dcch() and return -EINVAL, so let's not print garbage or call a
function which will anyways simply return an error.
Catched due to some strange values seen in log (see D0 and D3):
osmo-bts/src/common/bts.c:421 (bts=0,trx=0,ts=0,ss=4) Setting T200 D0=1028672, D3=2, S0=520, S3=520 (all in ms)
Related: OS#4066
Change-Id: I3d7e1883811acf97aac97325739f2ff97fc2aa08
The timers are unfortunately completely broken, so let's go back to the
long default timeout values from 1ff0a2addd
See related issues OS#4066 and OS#4074
Change-Id: Ia44310245a348675dbbf3ffc3dc5b6d207fd62d3
This will generate the VTY/counter documentation for osmo-bts-virtual so
it will be missing documentation for device-specific commands/counters.
Change-Id: Idebb099b69924d6212db119f7a2f2861d4150d7e
Related: OS#1700
By using new libosmocore LAPDm API we can specify the GSM channel type
and hence enable the LAPDm code to use a per-channel-type specific N200
value.
At the same time, this new API also allows us to specify T200 values
when initializing the LAPDm channel, so we don't have to fiddle with
low-level lapdm data structures in what used to be oml_set_lchan_t200().
Change-Id: I0e814fbae13e0feddd148c47255dcc38cb718f48
Depends: libosmocore I90fdc4dd4720d4e02213197c894eb0a55a39158c
Closes: OS#4037
As per GSM TS 12.21, the LAPDm timers (T200) of the LAPDm instances
in the BTS are configured via OML from the BSC. While OsmoBSC
is sending them and OsmoBTS is parsing them, OsmoBTS stopped to
make use of them from commit 3ca59512d2
(January 2016) onwards.
The cause for this has been documented and discovered in May 2017
in https://osmocom.org/issues/2294 and it is quite obvious: LAPDm
timers are supposed to start when a given frame is actually transmitted
on the radio interface. PH-RTS.ind and PH-DATA.req are suppsed to be
used over a synchronous interface in some deeply embedded processor.
With OsmoBTS however, we have an asynchronous L1/L2 interface between
a DSP (osmo-bts-{sysmo,lc15,oc2g,octphy}) or OsmoTRX (osmo-bts-trx)
and we receive PH-RTS.ind quite some time ahead. So if we start T200
at that point, then it will start running way before it has been sent
or before the MS has had a chance to receive the message.
The "correct" way to handle this is to actually measure the difference
between frame numbers in PH-RTS.ind (uplink, advanced) and PH-DATA.ind
(downlink) or PH-TIME.ind, and then add that amount to the actual
timeout value. This ensures that the timers will time-out the
user-specified amount of time after the actual transmit.
Change-Id: If8babda9e3e5e219908911ddd9c0756b5ea0bca4
Closes: OS#2294
Closes: OS#3906
Let's keep some statistics about the min/max/average frame number
advance that we're observing above L1SAP when comparing the time in the
PH-RTS.ind and the frame number we observe in PH-DATA.ind of data
that was received on the uplink.
The statistics are currently only shown in the VTY, but this is a
precursor to using them to correctly advance the LAPDm timers in a
follow-up patch.
Change-Id: I8f739fdb808a614f080afbc4654641ec3df19eb2
Related: OS#2294
Related: OS#3906
Let's avoid fancy alignment in the description of logical channels
for the benefits of having better readability, the ability to add
more comments and fields without making it look ugly.
Get rid of value-string array 'trx_chan_type_names', since each
logical channel has its name defined in 'trx_chan_desc'.
Get rid of field 'chan' of 'trx_lchan_desc' structure since it's
not used anywhere, and not actually needed because the position
of each lchan description is defined by its TRXC_* type.
Replace both 'pdch' and 'auto_active' fields with more generic
bitmask field called 'flags', and define the following flags:
- TRX_CHAN_FLAG_AUTO_ACTIVE,
- TRX_CHAN_FLAG_PDCH.
Use RSL channel mode #defines from libosmogsm instead of having
hard-coded numbers. This increases readability.
As a bonus, let's add a human readable description to each lchan
definition, so it can be printed in the VTY some day.
Change-Id: I9d5d49ec569f133d37b8164b22607d4700474315
Backported from: I2fc61e1cdca4690a34e2861b9ee3b7c64ea64843
I7ab4958801b3422973b67ff0452b90afa8a3f501
This way we unify format. We take the chance to add related information
to some log messages which were not printing that information (and was
confusing when using more than one phy instance).
Change-Id: I5b17a01638ade9a6c41da73e550d5947fa92f568
At the moment, bts_supports_cm() is only called on reception of
RSL Channel MODE MODIFY from the BSC. The idea is to check whether
the indicated RSL channel mode is supported by a BTS model.
RSL Channel MODE MODIFY message may indicate a channel in signalling
mode, i.e. GSM48_CMODE_SIGN, which has always been rejected so far.
Let's assume that signalling is always supported, as there is
no special BTS_FEAT_* definition to check that.
This change should make BTS_Tests.TC_rsl_modify_encr pass.
Change-Id: I8ea98a3eb9dc15a04f665596ee276883eb824b9a
According to 3GPP TS 48.058, section 8.4.1, the Handover Reference
element must be included if channel activation type is 'handover'.
Let's properly reject CHANnel ACTivation messages with missing
RSL_IE_HANDO_REF. Otherwise such requests are misinterpreted
as regular (non-handover) channel requests.
Found using TC_ho_rach() TTCN-3 test case.
Change-Id: I9c50e1dbeb54c5470560adcdfb2bdf5abbe47993
It looks like the status LED on the sysmobts2100 never worked correctly
since lc15bts-mgr expects osmo-bts-lc15 to create and manage
/var/run/osmo-bts/state, but there is nothing to do so in osmo-bts.
This patch copies the functions from oc2g to manage the state file in
lc15.
Change-Id: Iad32a22fc72e2aba45e4f1b9ae585f6e0b8757ed
Related: SYS#4493
osmo-bts-oc2g no longer modifies the status LED and instead leaves that
to the bts manager. The service file now also creates a directory in
/var/run needed for osmo-bts to communicate with oc2gbts-mgr. This
status file is used by oc2gbts-mgr to figure out when the bts is
operational.
Related: SYS#4493
Change-Id: Ifae634c6c2ecec7d32298c0f266f91f3e81308f5
osmo-bts cannot provide GPRS service while osmo-pcu is not connected.
The BSC has no knowledge of the PCU connection state. Prevent MSs
from trying to register for GPRS while the PCU is disconnected by
erasing the GPRS Indicator in SI3.
Change-Id: I1a6f5c636c0fe098ee31c280d4572a3f8122b44b
Depends: I690cf308311f910005a325d50f5d5d825678d2b2 (libosmocore.git)
Depends: I08e0ca9a8d13c7aa40b9d90f34f0e13adb87d4e0 (libosmocore.git)
Depends: I8b1ee2405f6338507e9dfb5f1f437c4c2db2e330 (libosmocore.git)
Related: OS#3075
Remove the '~' from '|= flag', it is plain wrong.
This affects the correct parsing of DSP trace flags from the config
file only. The bug is not present in the interactive VTY command
at runtime.
Change-Id: I915971f49642967c969f5dd475e8faa960ef3960
The existing code ssumed that the RR SUSPEND REQ would be a
LAPDm/RSL unitdata request. I couldn't find any spec reference
that would support this. Rather, the message is sent via the normal
main dedicated channel, which is operated in ABM mode.
As the somewhat similar check for diverting measurement results
is in fact looking for UNITDATA, we have to untangle this slightly.
Change-Id: Ic75486f8edaefa9c07bd92515ba1832b1c482fa6
Related: OS#2249
Related: OS#4023
Example: The fact that the PCU has connected with a given version is not
a *failure* in the first place, particularly not a MAJOR one. Let's
allow callers of oml_tx_failure_event_rep() specify the serverity of the
event that they're reporting to the BSC.
Change-Id: I49af04212568892648e0e8704ba1cc6de8c8ae89
Rather than open-coding "Tx foobar..." in various functions (and
forgetting it in half of them), let's add a generic message into
oml_mo_send_msg().
Change-Id: I5dd4b1749e68fb7fc74cb2e3a778d2418f46b770
Some of our OML log lines were missing any context. Try making more
sense by printing any context information about the given managed
object, TRX, ... as we have it.
Change-Id: I60d1660c6d574f206d7b8cc10082b413142365dd
In case of a Combined CCCH (with SDCCH/4), the number of RACH slots
depends on the frame number. So in case of lost/skipped frame numbers,
we cannot simply compute the value for the current fn and then multiply
it by the number of frame numbers expired. Rather, we have to 'replay'
all missed frame numbers and individually determine how many RACH
slots happened in that frame.
Related: OS#3750
Change-Id: If4f8d2ea55fc722c64c330cde09e833b67ee98fe
We used a bogus multiplication factor of four when computing the number
of expired RACH slots. While there are four RACH slots per block (i.e.
4 times more RACH received than normal MAC blocks), that multiplier
doesn't apply here: We are calling this function per *frame* and not
per *block*. So the maximum number of RACH slots per *frame* is (in
most suual cases with a single CCCH) at maximum 1. Only some obscure
configurations with multiple CCCHs in a single cell would render higher
values. In any case, *blocks* never even enter this equation.
This wrong multiplier resulted in rather weird RACH load reports to the
BSC.
Related: OS#3750
Change-Id: I6b14fd6e7819f9164fb4a09b432a9f419e3b6e5c
While we re-set the PCH load counters after every report, we never
actually re-set the RACH load counters. This meant that the
period/window for RACH load averaging would always grow, rather than
being reset every load indication period.
Related: OS#3750
Change-Id: Icd9150ba56d77d031c3cf496c5936c2de52b364c
The spec is quite clear: If the MS Power Parameters IE is present, then
the BTS shall perform autonomous MS power control. If it's absent,
then the MS power shall be fied. Let's adjust our code accordingly.
Change-Id: Ie43a1fc9cc658677c8c945ae82d03b7bffbe52d5
Related: OS#1622
In the following commit, we introduced transmitting the
RSL DELETE INDICATION on AGCH overflow:
commit 19da7fdea8
Author: Harald Welte <laforge@gnumonks.org>
Date: Sat Feb 24 04:32:29 2018 +0100
So let's sync the manual with the code.
Change-Id: I988778bdb83271355dc11b1a30a59e1a5dba5fb2
Related: OS#2990
There's no point in open-coding what LOGPLCHAN was created to do:
Log some event while stating the name of the logical channel.
Change-Id: I6913ac8fb543811126b85a54118333155c03bc03
This adds the final missing part to full CBCH support:
* keep a tab on the current queue length for basic + extended CBCH
* keep rate counters about the number of sent / transmitted SMSCB
* send CBCH LOAD information via RSL to the BSC
Change-Id: I7068c7937a60a900c40439115bb84dc3ee0d061f
The function get_p_max_out_mdBm() returns a value in 1/1000th of dBm,
"milli-dBm", while trx->nominal_power is only whole dBm. We were
missing the required divider of 1000 ever since Change-Id
Ieff75d5becaa80a2097b6e744c75c2d16259c9a4 was merged in February 2017.
The good news is that this really only affected the VTY output and
not any actual operational aspect of the system.
Change-Id: If92d0b15c48dafc63776b82c7ff5f3c2b3505f68
Closes: SYS#4570
We meanwhile support the SMSCB Channel Indicator IE and hence
can send SMSCB on both BASIC as well as EXTENDED CBCH
Change-Id: I63cc9c8c4c8c80440a61a0687e1f0cb97cc723b7
The logic for Extended CBCH are the same as for the Basic CBCH, we just
need to
* duplicate our related state
* parse the optional RSL_IE_SMSCB_CHAN_INDICATOR IE
* start to send data on the Extended CBCH (TB=4..7)
Change-Id: If2c6dc7da1e2185ab75fc957f8d305ad8db22429
Closes: OS#3535
The BSC can not only send us each to-be-sent message separately, but
it can also configure a DEFAULT message, which is then to be sent
instead of the NULL message. Let's add support for this
Change-Id: I65a79215b54155d128c26d2ca11ff9ff3ed2cdba
Closes: OS#4013
There's no need to keep around a pointer to the next segment
in a SMSCB message. The way how the multiframe structure is
laid out (and how the tb number works), we can use the result
of a modulo-division on the frame number to determine which
of the segments/blocks inside a SMSCB message (page) we have
to transmit.
This also acts as a simplification in preparation of support
for the SMSCB DEFAULT type.
Change-Id: I48faa19fec4a0852e6112ca2faa98960c678d4c5
Related: OS#4013
The first block of "schedule" messages must be advertised with
a special sequence number coding, see Table 1 of 3GPP TS 44.012.
Change-Id: I473edf698eba7ff5008f2fd1ec1776f0aa013858
Closes: OS#4012
This off-by-one error in length verification caused all SACCH INFO IE
to be deemed invalid and hence any RSL CHAN ACT with that IE to be
rejected.
Change-Id: I6436caf5c2caefbf7c089d66e37d8d1babe1c24e
Related: OS#3750
The Radio Link Layer (RLL) messages only make sense when a given
logical channel is active. If it isn't active, let's reject the
messages with an RSL ERROR REPORT with cause "Message sequence error",
wich according to spec means:
"A message with an existing message type which is not possible according
to the specification and to the state of the BTS is erroneous."
Related: OS#3750
Change-Id: I68dbb622aeaee657471664cdc0b69c2ac316d77e
While the CHAN_NR and LINK_ID IEs in ERROR REPORRT are optional, we
still should include it whenever possible to help error analysis.
Related: OS#3750
Change-Id: I8155e0d37096bd7bf3563e4f7853171ca4b3aa58
Send an RSL Error Report in case of unknown/unsupported msg_type,
as describedi in section 7.3 of 3GPP TS 48.058.
Related: OS#3750
Change-Id: Ib2918007410e635b144a7535cec30b9f3378c755
This reverts commit ad7b8bee71.
Unfortunately the osmo-gsm-manuals-dev package isn't working properly
yet, therefore osmo-bts fails to build on nightly OBS now. My apologies
for not testing enough in my own OBS namespace, before merging. I'll do
that in the future. I'm reverting the patch now, so osmo-bts isn't
missing from the nightly repository until I've fixed the
osmo-gsm-manuals package.
Change-Id: I89c2b92c8ae6331d6fff95a378fb58d82059af13
Neither the bug has been reproduced, nor the bug reporter
did respond to request for configuration files.
Change-Id: Ibc9db360be1380abaa9eef4bdf6e9a6d251670da
Support for extended (11-bit) RACH has been implemented:
- in libosmocoding: I85a34a82d5cd39a594ee89d91a2338226066ab5d,
- and OsmoBTS: Ia28741603636406744e5e22ffff1fb7a9689955a.
We also have a TTCN-3 test case called TC_pcu_ext_rach_content,
see I8fe156aeac9de3dc1e71a4950821d4942ba9a253.
Change-Id: I091f4fbd52c29c7d56ca392b8a1b872609829d81
It seems osmo-bts-sysmo does support CBCH (Cell Broadcast), but
for some reason it doesn't report BTS_FEAT_CBCH to the BSC.
Change-Id: I42dd3f84c44c210d9255e17153372bf252f897a1
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
According to 3GPP TS 52.021, sections 9.4.61-62, 'SW Configuration'
shall contain a list of 'SW Descriptions' related to the MO. In
other words, all 'NM_ATT_SW_DESCR' blobs shall be encapsulated
into a single NM_ATT_SW_CONFIG attribute.
For some reason, they were not encapsulated properly, so
OsmoBSC were unable to parse the 'SW Descriptions'.
However, unlike OsmoBSC the old OpenBSC does not expect this
encapsulation, thus after this change it will be unable to
parse the 'SW Descriptions'.
Change-Id: Id26104719891944f3e2151df362bd45bb057a9c5
Related: OS#3938
Instead of allocating two transitional buffers (one static,
another dynamic), we can use the existing message buffer.
Both handle_attrs_bts() and handle_attrs_trx() can put (append)
the reported attributes, and push (prepend) non-reported ones
as per 3GPP TS 52.021, 9.4.64 "Get Attribute Response Info".
Change-Id: I349447a43bce360f59e0c6b435906c65167d158b
Passing a pointer to a packed structure to tmsi_mi_to_uint() may
result in unaligned pointer value. Found with clang-8.
Change-Id: Ief69854973a098e6da7c05f4417dc11988edd777
Found using clang-8:
rsl.c:1646:7: warning: taking address of packed member 'packets_sent'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1646:28: warning: taking address of packed member 'octets_sent'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1647:7: warning: taking address of packed member 'packets_recv'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1647:28: warning: taking address of packed member 'octets_recv'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1648:7: warning: taking address of packed member 'packets_lost'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1648:28: warning: taking address of packed member 'arrival_jitter'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
Change-Id: Ifba33cfd8edeccc99a21c7d076db7119c29d4f40
Found using clang-8:
rsl.c:1607:93: warning: size argument in 'memcmp' call
is a comparison [-Wmemsize-comparison]
rsl.c:1607:7: note: did you mean to compare the result of 'memcmp' instead?
It looks more logical to compare the result of memcmp() against
zero instead of passing 'sizeof(sysinfo_buf_t) != 0' as size.
Change-Id: Ia8b95b017dbbfeb058d479fbaaf4861930569bb5
Both callers of cleanup_attr_msg(), i.e. handle_attrs_trx() and
handle_attrs_bts(), always pass out_offset >= 1, so the length
of the unsupported attributes counter is already accounted.
Otherwise, both callers would copy an additional garbage byte
from uninitialized memory. Discovered using Valgrind:
DOML DEBUG oml.c:539 OC=BTS(01) INST=(ff,ff,ff) Rx GET ATTR
DOML INFO oml.c:265 BTS Tx Get Attribute Response
==25467== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==25467== at 0x623E0BD: send (send.c:27)
==25467== by 0x5685846: __handle_ts1_write (ipaccess.c:358)
==25467== by 0x5683F8B: ipa_client_write (ipa.c:79)
==25467== by 0x5683F8B: ipa_client_fd_cb (ipa.c:140)
==25467== by 0x5F1DC23: osmo_fd_disp_fds (select.c:223)
==25467== by 0x5F1DC23: osmo_select_main (select.c:263)
==25467== by 0x42980B: bts_main (main.c:354)
==25467== by 0x6160F44: (below main) (libc-start.c:287)
==25467== Address 0x7d83895 is 23,669 bytes inside a block of size 102,528 alloc'd
==25467== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25467== by 0x589A6B4: talloc_pool (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.5)
==25467== by 0x5F1E28B: msgb_talloc_ctx_init (msgb.c:316)
==25467== by 0x4293D0: bts_main (main.c:234)
==25467== by 0x6160F44: (below main) (libc-start.c:287)
==25467== Uninitialised value was created by a stack allocation
==25467== at 0x415FE5: oml_tx_attr_resp (oml.c:259)
==25467== by 0x415FE5: oml_rx_get_attr (oml.c:561)
==25467==
Change-Id: Ic7c2c4e54e9f99b60aaf70604044933978be945c
Related: OS#3938
It was noticed that the Get Attribute Response message always
indicates BTS(00,ff,ff) as the addressed OML entity, even if
e.g. Baseband Transceiver(00,00,ff) was requested by the BSC.
Despite neither OsmoBSC nor OpenBSC does complain about this,
such behaviour violates 3GPP TS 52.021. Let's fix this.
Change-Id: Icb1ee75d4bf680deb6365288d8c2053816a12217
Related: OS#3938
When using %lu and sizeof() for printing the compiler may throw a
warning. Lets prevent this by using %zu instead of %lu as conversion
specifier.
Change-Id: If5cb656537b1b73b9361a132801ab47ab7f8a709
The functions oc2gbts_par_get_uptime() and oc2gbts_par_set_uptime() try
to return with NULL, but both functions are declared as int. Lets return
-EINVAL instead.
Change-Id: I63b61be2940c59b221089d3d1501371b0116d89a
fsync() takes an integer file descriptor but we have a *FILE pointer
here. Lets use fileno() first to convert the integer file descriptor to
a FILE pointer.
Change-Id: I46ffd8c680ba0b445cbbd133d5ce92b79e3d8d87
the function bts_cbch_get() is used in l1_if.c. The function is
declared in cbch.h. Lets include this header file in order to be
complete.
Change-Id: I95d7e89eed969dd5b3ccff0eebcc6c568196a97d
In oml_send_msg() we optionally push the A-bis IPA magic string
("com.ipaccess") to a given message buffer as LV (Length Value),
including the terminating null byte ('\0').
There was a mix of both sizeof() and strlen() calls, and worse
luck, memcpy() has been used in a wrong way, skipping the '\0':
memcpy(dest, src, strlen(src));
In general, this is not critical because the headroom of a given
message buffer would most likely be zero-initialized, so the '\0'
is already there. However, msgb_push() gives no such guarantee.
Let's use the libosmocore's TLV API (in particular, lv_put()),
and stick to sizeof(), so the null byte will always be included.
Change-Id: I0c7f8776d0caec40f9ed992db541f43b732e47ae
Closes: OS#3022
As specified in 3GPP TS 03.60 Section 16.2.1 and 44.018 Section 3.4.15,
a Class B MS is sending a "RR GPRS SUSPEND REQ" via a DCCH to the BTS if
it wants to suspend GPRS services. The BSS is now responsible to
somehow forward this to the SGSN. As the Gs interface between BSC and
SGSN is both optional and doesn't have any provision to forward this
message, we have to send it over to the PCU so it can use regular BSSGP
signaling to inform the SGSN of the SUSPEND REQUEST.
This patch requires libosmocore Change-Id
I90113044460a6c511ced14f588876c4280d1cac7 for the related definition of
struct gsm48_gprs_susp_req.
Change-Id: I3c1af662c8f0d3d22da200638480f6ef05c3ed1f
Closes: OS#2249
At some locations in the code a signal to SS_FAIL is dispatched in order
to trigger the sending of an OML failure event report in oml.c. This is
a bit overcomplicated for the task. Lets use oml_tx_failure_event_rep()
to send the failure event reports and lets remove the signal handler for
SS_FAIL.
Change-Id: Ie4fce1273a19cc14f37ff6fc7582b2945c7e7c47
Related: OS#3843
The function oml_tx_failure_event_rep() replaces oml_fail_rep(), so lets
use only oml_tx_failure_event_rep() and remove oml_fail_rep()
Change-Id: I83c4fa9ebd519299fd54b37b5d95d6d7c1da24f6
Related: OS#3843
SIGUSR1/2 and SIGABRT should not trigger a failure event report on
OML since we only use it to get an intermediate talloc report. (In
case of SIGUSR1/2 without leaving the process.)
Change-Id: I99e637496afff2530425b89c6e9befc76db24906
The function gsmnet_from_vty() is used in oc2gbts_vty.c, but it is not
declared in vty.h. Lets add the declaration to vty.h, so that
gsmnet_from_vty() can be used properly by other modules.
Change-Id: I8cf63c6fabdb1f2dc67ca8193704ce4d1d4882d9
Nowadays only known users (OE images) use systemd and don't require this
kind of screen setup.
In any case, this kind of file belongs to scpeific setup and are not
needed here.
Change-Id: I65b0eee44336e4627620443861092b8988f2e01d
This fixes the below compile error:
rsl.c:900:43: error: ‘gsm0808_chosen_enc_alg_names’ undeclared (first use in this function)
Change-Id: I4aed0242737602e61b785862e3c37c963bf48455
The log level of the messages that notify calibration file loading
problems is NOTICE, but since it is a severe problem when calibration
can not be loaded lets change it to FATAL
Change-Id: I32aed25ca7925f1c776f00b37f404a58a85ddbc7
Related: OS#3823
When the TX/RX calibration files can not be loaded a failure event
report should be sent to the BSC. Lets send a failure event report when
calbration data is either bad or can not be loaded (see also remvoed TODOs).
Change-Id: I3318470518b34807a443f7cb78c7091b4a3d4481
Related OS#3823
On links with high latency it can happen that RADIO CARRIER OPSTART is
carried out to early, even before SET BTS ATTRIBUTES is carried out.
This means that important parameters for the initalization are not yet
set and the TRX initalization failed. Lets delay the TRX initalization a
bit in order to be sure that all BTS attributes are set before the
initalization is carried out.
Change-Id: Id3bdc88d28417e422d2c0c33b03be06f1a4706c2
Related: OS#3782
The function vty_install_default() is deprecated and throws a compiler
warning that suggests to remove it, so lets remove it.
Change-Id: I1a4afb6e352bed9a5af794b39b984a7ddef36e08
The static function oml_tx_failure_event_rep() is a lot easier to use
than the currently implemented signal scheme. Lets make it public so
that we can quickly generate failure event reports.
Change-Id: I9c4601840a06119f35cfe4da453fff3b293fe615
Related: OS#3823
According to the OC-2G product specifiacation, the maximum output power
is 25 dBm. This should be reflected in the code, there's no point in
claiming to be able to trnasmit 40 dBm - which just creates confusion on
all levels (such as the logs, where Tx power is claimed to be ramped up
to 40 dBm right now).
Closes: OS#3823
Change-Id: Ia6b3476ab2f9279f8905b8c7cfd07ef7b0a939ed
For some strange historical reason, the baseband transceiver MO was
brought up in state "UNLOCKED".
The object should come up in "locked" state until it's explicitly
unlocked by the BSC.
See Section 6.8.2 of TS 12.21: "If there is yet no administrative state
value explicitly set by the BSC (e.g., at an initialization time), the
object shall be presumed to be administratively locked by default"
Change-Id: Id505594b9f224567566caac84dae2e2ae4477fae
Closes: OS#3790
For the TS 12.21 standard OML attributes, we store a copy of the
most-recently set value for each attribute in "mo->nm_attr". This
somehow was missed when adding support for the IPA specific MOs like
those relevant for GPRS.
Change-Id: I75ebda46da9c1fcecc484311bf3833f31c536ee1
Fix compilation warning. At runtime it's not a big issue because the
"list" field is the first field of the led_list (struct
lc15bts_led_timer_list) variable. Hence, the address passed is the same.
Similar to commit fixing same issue in lc15 in 080302f8.
Change-Id: Ie393a21bc3a725520343c70941cb4f591b313420
it's used in oc2g/main.c and it needs to be in a header file.
Similar as previously done for lc15 in 19795c5a.
Change-Id: Ic6826d8c8ff5c648158493454a80704bb956b51d
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
OsmoBSC used to have a bug in encoding the "GET ATTRIBUTES" OML message,
resulting in the actual message length being three bytes longer than the
encoded length value.
As in Ib98f0d7c2cff9172714ed18667c02564540d65d7 we have introduced
proper consistency checks on length values, all "GET ATTRIBUTES" from
OsmoBSC version suntil today will fail. This patch introduces a
work-around to remain compatible with old OsmoBSC while still keeping
the consistency checks for all other messages.
Change-Id: Ifa24e9e2c71feb2c597557807d675438c2825b2d
Related: OS#3799
For OML, what matters is the length indicated in the OML message header.
If we don't have sufficient bytes, reject the message and send a failure
event report.
If we have more bytes, truncate the message at the number of bytes
indicated in the OML length header.
Change-Id: Ib98f0d7c2cff9172714ed18667c02564540d65d7
TS 12.21 describes segmenting of OML messages using placement
fist/middle/last and the "sequence' number of the OML header. We don't
implement this and hence must ignore or reject any related messages.
Before this patch however, we simply treated such segments as if they
were a complete OML message. Let's fix that.
Change-Id: Idd42cf4edc1bf9ab366853bd9b0f7afd9c060910
Closes: OS#3795
Simply use a "mo" variable on the stack rather than having duplicate
but otherwise identical calls to oml_tx_failure_event_rep()
Change-Id: Ibe6c79e95405b13d041047549d2ffa39aa355eb2
When we send an OML failure event report using
oml_tx_failure_event_rep(), the function itself will not only send
the report to the BSC but also log it. So there's no need to both
have an explicit LOGP() and a call to oml_tx_failure_event_rep().
Change-Id: Ib3fd06b3266d896aebeed4ebe42ac71ff173bb5c
In Change-Id Ic163bcfb6361a8ebd39e0bc0f238ef51e2cb214e we introduced
several additional calls to oml_tx_failure_event_rep() during OML
messaeg processing. However, for some reason, we *overwrite* the
bts_nt/trx_nr/ts_nr of the TRX MO. This is clearly wrong. The
"address" of a managed object doesn't change at runtime!
Change-Id: Idfb80ccd6dd485d52dc006867fae3dde3fb005f3
When osmo-bts connects to the BSC, it sends a ton of "State Change Event
Report" messages indicating the Operational State (NULL), Availability
status (power off) and [as an osmocom extension] also the Administrative
State. However, the value of the administrative state is "0", which is
not defined in TS 12.21 Section 9.4.4
Change-Id: I03f8a4b08b266cd40036076c76f9dc7e8bf08da2
Closes: OS#3785
As per 3GPP TS 12.21 Section 8.2 "ACK messages shall return all the
attributes in the original message". OsmoBTS fails to do so but simply
sends no attributes at all in the ACK.
TS 12.21 is a bit vague whether or not the attributes shall also be
achoed in the NACK. Let's do it and append the CAUSE in this case.
Closes: OS#3788
Change-Id: Ifb305fe75f8305bb04872f26492b8b1bb8c27f49
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
A comma is needed to separate a command definition from its
description, not the parts of description. Let's fix this.
Before this patch:
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# no?
no PHY Instance number
OsmoBTS(phy)# no ?
instance
osmotrx OsmoTRX Transceiver configuration
After this patch:
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# no?
no Negate a command or set its defaults
OsmoBTS(phy)# no ?
instance Select a PHY instance to remove
osmotrx OsmoTRX Transceiver configuration
Change-Id: If10d85abc6506118ba08c37e8101f423d6f838ea
Use the 'else' construct where applicable to avoid too many return paths
from functions
Change-Id: I819f0c80e90855e8b3252795c837f8e3053b6e87
Related: OS#1622, OS#1851
The loops.c code dates back to ancient times when we printed the TRX
number and the raw channel number to identify a logical channel. We
meanwhile have gsm_lchan_name() and should use it to log messages
related to this lchan in a common format.
This commit introduces the LOGPLCHAN() helper macro [similar to
osmo-bsc], and uses it from loops.c.
As a result, some functions don't need a chan_nr argument anymore,
while some need to add a new lchan argument.
Change-Id: I6976dd7444c26b1f52741bc367b0311ebbef1718
Related: OS#1622, OS#1851
The concept of a return value only makes sense if there's actually ever
something non-constant to return, and if the caller actually processes
that return value. If we always "return 0" and ignore it on the caller
side, functions should be of "void" type.
Change-Id: I3575a2cef75f3fd4c3f95eddb40719d28a055b54
Related: OS#1622, OS#1851
The loops.c code is not very easily understood, so let's add some
comments to it.
As can be seen, there are functions of integer type which always return
0, and whose callers don't check for the return value. This will be
adressed in subsequent patches.
Change-Id: Iafea07eb751ed85d29b214576bb0d31ea919cd72
Related: OS#1622, OS#1851
Fix recent commit which broke TTCN3 BTS_tests
TC_dyn_ipa_pdch_tchf_act_pdch_act_nack.
Prior to the breaking commit, logic was still not good, because
1- It didn't return after sending the NACK
2- It sent a NACK in all cases, while for PDCH DEACT we want to force
its deactivation. Going through tests it can be seen that indeed it
can deactivate it in that case:
rsl.c:2206 (bts=0,trx=0,ts=3,pchan=TCH/F_PDCH as PDCH) Request to PDCH DEACT, but lchan is still in state ACTIVE
...
rsl.c:2103 (bts=0,trx=0,ts=3,ss=0) Tx PDCH DEACT ACK
Fixes: 133a3d96dc ("rsl: Avoid sending ipa PDCH DEACT NACK followed by ACK")
Change-Id: I6d6d12aec10c801fe55012ca6e58d0bc8755b15d
This allows running sysmobts-mgr on systems with old gpsd releases
(which may have other software depending on such old release).
GPSD_API_MAJOR_VERSION define was first added in gpsd 2.39, before that
it didn't exist (but this code is known to work against 2.38).
GPSD_API_MAJOR_VERSION == 5 was set in version 2.96.
Related gpsd commits:
3771dba081bd1175adab6096d7b6270d3822aaa1
e69bcb6b01af6b25c6a525fb1961b92ac04f5213
Related: SYS#4290
Change-Id: If3c35021a020a61d5fa3cde5eebcd09908db822b
API prior to that version allocates the pointer internally. Let's change
current code to always use a pointer and in current supported code (gpsd
>= 2.96) point it to a user-allocated struct.
Follow-up patch will introduce necessary ifdefs to support older gpsd.
Change-Id: Iaeb5ac527cc3e58168027021d0f60afa93d1fb6f
Add new environment variables WITH_MANUALS and PUBLISH to control if
the manuals should be built and uploaded. Describe all environment vars
on top of jenkins_bts_model.sh. Change the top description line to look
like all the other contrib/jenkins.sh files (from other repositories),
so it is clear that this is the entry point of Jenkins (and not the
other contrib/jenkins_*.sh scripts).
When WITH_MANUALS is set, install osmo-gsm-manuals like any other
dependency and add --enable-manuals to the configure flags (for "make"
and "make distcheck"). Add the bin subdir of the installed files to
PATH, so osmo-gsm-manuals-check-depends can be used by ./configure.
Related: OS#3385
Change-Id: If51194cc595bd8cf1081b35ab0e1a5ddcd448860
Set AM_DISTCHECK_CONFIGURE_FLAGS in Makefile.am instead of
DISTCHECK_CONFIGURE_FLAGS. This is the recommended way from the
automake manual, as otherwise the flag can't be changed by the user
anymore.
Related: OS#3718
Change-Id: I332c94502cce0f3f11fe3f4d9f6c9918ff0c0263
Moved to doc/manuals/, with full commit history, in preceding merge commit.
Now incorporate in the build system.
Build with:
$ autoreconf -fi
$ ./configure --enable-manuals
$ make
Shared files from osmo-gsm-manuals.git are found automatically if
- the repository is checked out in ../osmo-gsm-manuals; or
- if it osmo-gsm-manuals was installed with "make install"; or
- OSMO_GSM_MANUALS_DIR is set.
Related: OS#3385
Change-Id: I728ebb56ade6dda079a0744c4e592284e1bea4f6
Surrounding with '@' didn't seem to yield the intended result, the
charactars appeared in the compiled document.
Change-Id: I66e7949fa4a6c2164bf9572a2beaf8ace169fa1c
This chapter defines the protocol used between osmo-trx and
osmo-bts-trx.
Most of the text comes originally from osmo-trx.git/README, as it's the
only known documentation of the protocol other than the code itself.
Change-Id: I56c418eef0f826ae1aadbed5b151fbed241c7885
The initial goal was to make sure we don't have overall FORCE rules causing
unnecessary rebuilds -- annoying while writing documentation. As I looked
through possible dependencies, I finally understood what's going on here.
Remove code dup and nicely sort which belongs where in build/Makefile.*.inc. In
each, describe in a top comment how to use it, and also unify how they are
used:
- Rename Makefile.inc to Makefile.docbook.inc and refactor
- Add Makefile.vty-reference.inc
- Add Makefile.common.inc
Make sure that we accurately pick up all dependencies.
Drop use of the macro called 'command', that silenced the actual command lines
invoked and replaced them with short strings: it obscures what is actually
going on and makes the Makefiles hard to read and understand.
Each manual's makefile is greatly reduced to few definitions and a Makefile
include, e.g. one for asciidoc, one for VTY reference.
Move common/bsc_vty_additions.xml to OsmoBSC/vty/libbsc_vty_additions.xml, link
from OsmoNITB. It applies only to OsmoBSC and OsmoNITB.
Add a script that combines a VTY reference file with *all* additions files
found in a manual's vty/ dir. Call this from Makefile.vty-reference.inc.
Change-Id: I9758e04162a480e28c7dc83475b514cf7fd25ec0
All parts referencing GFDL can be easily disabled by removing the
'gfdl-enabled' attribute from the document.
Change-Id: I2489726ad2e90301bceadfada926e31ae0f85986
Add high level description on and a config example for dynamic timeslots in a
new chapter featured in the OsmoBSC and OsmoNITB manuals.
From the OsmoBTS manual's chapter on dynamic timeslots, add references to the
above.
Change-Id: I44ff1e4c2340c65ff23e85408fc6d6a45ea9e046
Add it to Makefile with proper docinfo so it's build automatically
alongside with other documentation.
Change-Id: Iacd7fadc003ce0f9ffd20aa5b36c7d598b04f882
Add two new chapters contributed by Nutaq:
* TCH/AFS Downlink: Inhibiting a SID_FIRST frame
* TCH/AFS Downlink: FACCH/F During DTX Operation
Change-Id: Ic39d035f9d17bd0634c2df78ae3359a5eb7dfd46
Below commit accidentally removed osmobts-abis.pdf from the Makefile entirely.
The pdf was re-added, but the dependencies are still missing, so that
osmobts-abis.pdf is not rebuilt when abis/* is newer. Fix that.
Culprit: 05f5adbe837f2cbfb9301cdb8c9b454ca0bfc825
"OsmoBTS: add vty reference documentation"
Half-fix: 707827196f0734eefa74ce0c35c2ab2fe754cc4c
"OsmoBTS: generate osmobts-abis.pdf again"
Change-Id: Id2ee8177cfb8eb58409d164bdd994ef5e86ad82b
Split both of the lengthy mscgen generated ladder diagrams in two so that the
diagrams are split over two pages and don't bleed into the page footer.
Change-Id: If90250123a85cd275f07c69ee64c6e10a7269f06
Unfortunately a glob like osmo-x__*.{svg,png} doesn't work, so have the
suffixes in separate globs.
Add dashes to indicate that failure should be ignored.
Change-Id: I6bc4d9ea72b43a573acbc860c23397f748de2c7b
There were two separate sections saying basically the same. Move the
entire 'Dynamic Channel Combinations' section further above and combine
with the 'IPA Style PDCH Management' section to avoid repetition.
Change-Id: Ic370ba34de5cb14f0194ff8c8661e45d7ca98e2b
Generate *.check files from asciidoc output and grep for WARNINGs.
Add *.check files to gitignore and to 'make clean'.
Change-Id: Ibccc83a3415930a528f2e8e4e4dda3b81c6d0b64
The section 'Osmocom Style Dynamic Channels' ended in mid-sentence without
naming any of the hard facts. Complete that.
Add section links.
Change-Id: Ib92895fe1bb89fb1b14dc8fcbd88b98bbb6edeee
Consistently name the PDCH act methid 'IPA style', name ip.access only once
in the 'IPA Style Dynamic Channels' section.
Consistently write 'IPA style' without hyphen (not 'IPA-style').
Capitalize section headers ('IPA Style').
Change-Id: I91112c2d8af9424ebe7e1972fd4ef9c77d24a7b4
In effect, this fixes the dangling references from the table of RSL messages
with additions/limitations to the Chan Act message description.
Change-Id: Ic6f83f016ce9ec90af7eb0af1b1f71a10263915d
Including the required changes of the Makefile which is now simliar
as the other projects Makefile's.
Based on: OsmoBTS 0.3.0.283-f869
Change-Id: Id7362ce1c584b1926330b93770d68453e091c71c
The act ack for switchover to PDCH is now issued immediately, after
commit 'dyn TS: if PCU is not connected, allow operation as TCH'.
Adjust the chart accordingly.
The manuals existed in different form for several years in an internal
sysmocom repository. However, since they had just recently been
converted from docboox-xml to asciidoc and all files have been
re-shuffled for enabling the public release, there's not much point in
keeping the history with git-filter-branch.
This commit doesn't change internal logic of any model, only the API to
be able to return result of connect TS asyncrhonously since some models
(like osmo-bts-trx) require some time to process the result. This way
PDCH ACT/DEACT (N)ACK can be sent once the result of this long process
is known. For instance, nowadays in osmo-bts-trx we PDCH (DE)ACT ACK
before getting the result from SETSLOT on the TRX iface.
With this new API, bts_model_ts_connect doesn't return any value
synchronously. Instead, it is expected to always end up calling
cb_ts_connected with the return code from the TS activation process. 0
is considered a successs, while any other value is considered an error.
Change-Id: Ie073a4397dd2f1a691968d12b15b8b42f1e1b0cf
Later on it's expected to add more rsp parsing, so let's return here and
not depend on generic return further down.
Change-Id: I8ddee46374ab329c47dc68e720e236f13d393f66
It was spotted during osmo-gsm-tester test
dynts:trx-sysmocell5000+mod-bts0-dynts67-ipa+cfg-codec-fr-any that
osmo-bts-trx was answering to PDCH DEACT from BSC first with a NACK
followed immediatelly after by an ACK. That happens after the test does
a GPRS pdp ctx act successfuly and then deactivates the ctx and the 2 MS
try to place a call between them (and thus channels need to be moved to
TCH/F).
Most probably the if condition where the lines for this commit are
modified need to be fine-grained. Patch before this one should help to
understand the steates/situation in this scenario, and then a follow-up
patch can be created to improve the logic.
Change-Id: I91c65da6b6b7094f32187d3b083153a87c3219fd
TRX0 is allocated in a different place than other TRX.
Commit that introduced the bug added an initialization step
(bts_trx_init) applied in VTY cmd "trx <0-254>", where TRX are allocated
since same commit, but doesn't initialize TRX0 for reasons explained in
first paragraph.
As a result, some parameters were not applied to TRX0, like
power ramping increment step, which prevented MS from finding the network in
osmo-gsm-tester tests.
Fixes: eebb6a4216 ("bts: Allocate TRX for BTS dynamically, deprecate -t")
Change-Id: I5afd66548634ff53e2af24dc7055d408ca8ca4e3
If POWERON fails, announce to BSC that the TRX is not available, and
announce it as available as soon as POWERON success is received.
Related: OS#3692
Change-Id: Iaa8f497381038fd7f9f779a8211ebc6453837c65
The setup is only needed once, so no need to set it every time we want
to schedule it.
Furthermore, it will ease new code introduced in follow-up patches,
which will schedule this timer under some circumstances without need to
send a message at the same time (because re-try of a cmd after a delay
is wanted).
This commit adds an alloc function and an init function to keep
different parts of the code decoupled and avoid exposing more
implementation details between them (like exposing the trx_if timer).
Change-Id: I3b6461d0130d25284e673c5efce0b3832c48bbb5
The return value of osmo_wqueue_enqueue() isn't checked.
This can result in a memory leak if the message cannot
be enqueued. Log an error an free the message upon failure,
as done elsewhere.
Change-Id: I5671ca364f31d98f2b28d028e7bf1797386de2ec
Related: CID#57662
No need to pass -t num_trx anymore to specify number of TRX to use. It
is calculated based on dynamic allocation from VTY config.
Using parameter -t is flagged as deprecated and is transformed into a
NOOP por backward compatibility.
As a result, TRX now are allocated after the BTS is allocated and
initial config (pre-VTY) is applied.
A new function bts_trx_init() is added, to set default config on each
TRX during allocation and before setting VTY config on it.
A new per BTS model function bts_model_trx_init() is added, to allow
per model specific default configuration of each TRX.
Change-Id: Iab1a754ab12a626759f9f90aa66f87bdce65ac9c
If chan_state->ongoing_facch is set, this code's logic
suggests that both msg_facch and msg_tch could be NULL.
Don't dereference msg_tch unconditionally.
Change-Id: Icf5584396c5b925d55ca9380dd4f869ae5d72da3
Related: CID#172047
This change modifies the logic of TDMA frame loss tracking. To
be more precise, the tracking logic was moved from per timeslot
level to per logical channel level, what makes OsmoBTS more
accurate in its measurements.
But before getting into details, it's important to clarify some
things about the Uplink burst processing in transceiver (OsmoTRX).
If an Uplink burst is detected, OsmoTRX demodulates it and sends
to OsmoBTS. If nothing is detected on a particular timeslot,
OsmoTRX will do nothing. In other words, it will not
notify OsmoBTS about this.
Meanwhile, there are usually a few logical channels mapped to a
single TDMA timeslot. Let's use SDCCH8 channel configuration as
an example (simplified layout):
/* SDCCH/8 (ss=0), subscriber A (active) */
{ TRXC_SDCCH8_0, bid=0 },
{ TRXC_SDCCH8_0, bid=1 },
{ TRXC_SDCCH8_0, bid=2 },
{ TRXC_SDCCH8_0, bid=3 }, // <-- last_fn=X
/* SDCCH/8 (ss=1), subscriber B (inactive) */
{ TRXC_SDCCH8_1, bid=0 },
{ TRXC_SDCCH8_1, bid=1 },
{ TRXC_SDCCH8_1, bid=2 },
{ TRXC_SDCCH8_1, bid=3 },
/* SDCCH/8 (ss=2), subscriber C (active) */
{ TRXC_SDCCH8_2, bid=0 }, // <-- current_fn=X+5
{ TRXC_SDCCH8_2, bid=1 },
{ TRXC_SDCCH8_2, bid=2 },
{ TRXC_SDCCH8_2, bid=3 },
SDCCH8 has 8 sub-slots, so up to 8 subscribers can use a single
timeslot. Let's imagine there are three subscribers: A, B, and C.
Both A and C are active subscribers, i.e. they are continuously
transmitting UL bursts, while B is not using ss=1 anymore.
The original way of TDMA frame loss tracking was the following:
- when an UL burst is received, store it's frame number in
the timeslot state structure (last_fn);
- when the next UL burst is received on same timeslot, compute
how many frames elapsed since the last_fn;
- if elapsed = (current_fn - last_fn) is lower than 10, then
iterate from (last_fn + 1) until the current_fn and send
dummy zero-filled bursts to the higher layers;
- otherwise (elapsed > 10), process the current burst,
and do nothing :/
According to our example, subscriber A is sending 4 bursts, then
nobody is sending anything, and then subscriber C is sending
4 bursts. So, there is a 4 frames long gap between the both
transmissions, which is being substituted by dummy bursts. But,
as the logical channel on ss=1 is not active, they are dropped.
This is not that scary, but the current algorithm produces lots
of false-positives, and moreover is not able to track real frame
drops in longer periods (i.e. >10). So, tracking the frame loss
per individual logical channels makes much more sense.
Let's finally drop this hackish 'while (42) { ... }', and track
the amount of lost / received TDMA frames (bursts) individually
per logical channels. Let's also use the multiframe period as
the loss detection period, instead of hardcoded 10. And finally,
let's print more informative debug messages.
Also, it makes sense to use the amount of lost / received bursts
during the calculation of the measurement reports, instead of
sending dummy bursts, but let's do this separately.
Change-Id: I70d05b67a35ddcbdd1b6394dbd7198404a440e76
Related: OS#3428
Before this patch it was being coded as SDCCH4 TS0 SS 0, and as a
result the state LCHAN_REL_ACT_OML applied in opstart_compl in abused
SDCCH4 TS0 SS 4 was not being checked when deciding whether to send a
Chan Act ACK in rsl_tx_chan_act_acknack.
Fixes: OS#3513
Change-Id: I1641960c9ffbb3ed0de74ab5b53e24e5b4ff3397
Previous implementation made no sense, since chan_nr is never read
before being set below from lchan_nr.
Furthemore, if lcahn_nr=CCH_LCHAN=4, then:
cbits = 0x4 + lchan_nr = 0x8 = b1000 which then becomes SDCCH8 according
to GSM 08.58 9.3.1, so it's totally wrong:
SDCCH/8 + ACCH 0 1 T T T
Change-Id: Id1dee716991e6faa406f02c029e998af5780162a
In the most cases a PDCH time-slot has only one logical channel
allocated. In case of both osmo-bts-trx and osmo-bts-virtual,
there are two kinds of logical channels: PDTCH and PTCCH,
but since they share the same chan_nr value, deactivating
one of them would trigger deactivation of another one.
Let's explicitly address the first logical channel in array.
Change-Id: I8edcb46e887c4db63a425eba89cec4374165763e
Closes: OS#3023
The existing implementation used a simplistic macro, which was wrong
in many ways:
1) it returned a negative value for "fn % 51 < 5" conditions without
raising any error message or asserting
2) it returned a wrong block number for many different input frame
numbers, as it didn't account properly for the FCCH/SCH gaps between
the blocks
Let's replace the simplistic macro with a proper lookup table based on
TS 05.02, and let's OSMO_ASSERT() if this is ever called with non-CCCH
frame numbers.
Change-Id: I11fd6cc558bb61c40c2019e46f56c1fe78ef39f5
Closes: OS#3024
* we have to use modulo 51, not 50
* the check for FACCH/SCH has to be applied to to the fn % 51 result
Change-Id: I540a7eeef3ea3ed7347f0f1b5a5a6fe7ce0ec8bb
The '--with-osmo-pcu' flag dates back to a time where the
'pcu_interface' header was not copied in both repositories
and you had to point one to the other.
Change-Id: I79e494484cb099cc9ca8c27c38b785c5ea8c3bc6
Closes OS#3514
The command implementation says "deprecated", so then the vty command attribute
should also be DEPRECATED. It will be hidden from online docs and vty
reference.
Change-Id: I23e620f1b947e129989fe69c6380c91b9abf7021
We used to permit multiple spaces to enter a new node in the config,
but modern osmo* code writes config files well-formed where every node
equals exactly one indent level.
Change-Id: I3da56b34e87503c46e6bf3c7505b83ec5e6aaa20
Fix compilation warning. At runtime it's not a big issue because the
"list" field is the first field of the led_list (struct
lc15bts_led_timer_list) variable. Hence, the address passed is the same.
Change-Id: Ib8bf07990800d74bfb3ad7a55eccfc65e40cd480
During the investigation of OS#3559, it was discovered that the
log message, which warns that an RSL message was dropped due to
inactive logical channel, has incorrect log level - LOGL_INFO.
This is not informative kind of message, so let's increase the
log level, and additionally let's print the hexdump of message
and it's length.
Change-Id: I26eac5e4466c493ffe08dbb89de20f5e1c2bb85d
As the CBCH replaces SDCCH sub-slot-2 in downlink, we should mark
the uplink as IDLE, just as the associated SACCH in uplink and downlink.
Also, there are no burst_numbers in IDLE slots.
Change-Id: Ib8565d1d0080bfce5d2aec77609709a445a2171c
Unfortunately the code in Icc15603079a1709ec094f400a9bcf0008211890f
was incomplete as it missed a few spots where the CBCH-enabled channel
types weren't yet covered.
Using this patch I can both still perform RACH / Location Update as
well as actually receive SMSCB messages on an attached phone (Galaxy S5).
Change-Id: I311b141668549ef37054cbe74be66bf17ac1d7e6
Closes: OS#1617
Closes: OS#3559
The CBCH (as per GSM specs) always maps on sub-slot 2 of either
the SDCCH/4 or SDCCH/8 that it replaces. However, the way how we
express it as RSL-style channel number (0xC8) doesn't allow room
for any sub-slots. The top 5 bits are used for expressing CBCH, while
the bottom 3 bits are used for the timeslot number (TN).
So when transforming from channel number to lchan, we must handle the
CBCH case specially by using a hard-coded sub-slot number of 2.
Change-Id: I44e2f763d5d25311167f435f2ca7e030b2a3f009
Related: OS#1617
This fixes a bug introduced in "CBCH: Move processing via L1SAP"
commit 02d99db08b
Author: Harald Welte <laforge@gnumonks.org>
Date: Fri Aug 24 23:37:45 2018 +0200
where the full channel number 0xc8 was used instead of the
(right-shifted) C-bits only.
Change-Id: I0fd8d7762e9cc3319a534f261e8857a1aa2220e0
It's very confusing if some log messages log chan_nr as decimal, while
most log it as hexadecimal. Let's standardize on hex everywhere.
Change-Id: Ia6566d5bbee8124fb7c689c962ce34d714208503
Also print a newline at the end of print_hwversion().
In the process of rewrite, fix several warnings in the few lines of this functions:
osmo-bts/src/osmo-bts-litecell15/main.c: In function ‘print_hwversion’:
osmo-bts/src/osmo-bts-litecell15/main.c:162:12: warning: passing argument 1 to restrict-qualified parameter aliases with argument 4 [-Wrestrict]
snprintf(model_name, sizeof(model_name), "%s Rev %c",
^~~~~~~~~~
model_name, (char)rev);
~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:168:12: warning: passing argument 1 to restrict-qualified parameter aliases with argument 4 [-Wrestrict]
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~~~~~~~~~
model_name, model);
~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:162:47: warning: ‘ Rev ’ directive output may be truncated writing 5 bytes into a region of size between 1 and 64 [-Wformat-truncation=]
snprintf(model_name, sizeof(model_name), "%s Rev %c",
^~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:162:3: note: ‘snprintf’ output between 7 and 70 bytes into a destination of size 64
snprintf(model_name, sizeof(model_name), "%s Rev %c",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
model_name, (char)rev);
~~~~~~~~~~~~~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:168:47: warning: ‘ (’ directive output may be truncated writing 2 bytes into a region of size between 1 and 64 [-Wformat-truncation=]
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~
osmo-bts/src/osmo-bts-litecell15/main.c:168:44: note: using the range [0, 4294967295] for directive argument
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:168:3: note: ‘snprintf’ output between 9 and 75 bytes into a destination of size 64
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
model_name, model);
~~~~~~~~~~~~~~~~~~
Change-Id: I079b056a04fe77d2f7f361ff5899232cb70b5a93
Fixes following compilation warning:
osmo-bts/src/osmo-bts-litecell15/lc15bts_vty.c:244:3: warning: implicit declaration of function ‘lchan_deactivate’
Change-Id: Id9b144d068d53393e1c1887aad285ae757156ec6
There is a big difference between both L1 and L2 frames. In the
first case, a TDMA frame is assumed, while a L2 frame is the
result of decoding a few bursts (e.g. 4 for xCCH) arrived
on a few TDMA frames.
Anyway, the purpose of l1if_process_meas_res() is to handle
measurements, not frames.
Change-Id: Ic4362c2869e658c2f42664b4009a30e777f8048c
The unit test that tests lchan_meas_process_measurement() only inputs
test data to lchan_meas_process_measurement() but it is not checked if
the interval end could be detected or not.
- Add a return code to lchan_meas_process_measurement()
- Ensure that the return code is checked in the unit-test
Change-Id: I9e00ce683e8c44528804f65181dbfed9e85e3aed
Related: OS#2975
The function is_meas_overdue() was introduced to allow
lchan_meas_process_measurement() to detect when the end of a measurement
interval has been missed. Interval ends may be missed when the SACCH
block of the related measurement interval gets lost. This is due to the
fact that the SACCH block is used as a trigger to start the measurement
result computation.
The idea behind is_meas_overdue() was to check the frame number of the
current measurement against the frame number of the previous measurement
in order to see if there was a measurement for SACCH in between or not.
Unfortunately SACCH and TCH Voice data is not necessarly processed in
order by each phy. Depending on the phy there may be a jitter between
the timing of SACCH and TCH Voice. Depending on the phy this jitter may
be enough to mess up the timing so that we see a SACCH block earlier
than expected. So we can not use the current frame number of TCH Voice
measurements to check for missed SACCH blocks.
Change-Id: Idfdbf64c1f965f35c12559b3995e2b746c74ee9e
Related: OS#3502
Related: OS#2975
Change cfg file names so they don't overlap when installing different
osmo-bts versions, and make systemd services look for correct new name.
Remove unneeded duplicated EXTRA_DIST files from root dir Makefile.am
Change-Id: I75fdd06cc52ce50628efb1f9b007d2e3926db27d
Convert the if-cascade to a switch().
For any unexpected pchan kind, reject the chan mode immediately instead of
going on to invoke gsm_bts_has_feature on feature = _NUM_BTS_FEAT, and log the
error.
Tweaked-by: neels
Change-Id: Ieaded9258554b15fcc4b7f05d5a8847175b7962f
Fix the chan mode checking for RSL Chan Mode Modif: do not reject
all modes on dyn TS.
In rsl_rx_mode_modif(), bts_supports_cm() should never
be fed with dynamic pchan kinds (e.g. GSM_PCHAN_TCH_F_TCH_H_PDCH).
Feed instead the return value of ts_pchan() that is to say,
the actual pchan type (e.g. GSM_PCHAN_TCH_F).
Change-Id: I7f0c835b25289931bccf96e982ea5564c8be4192
This patch adds scheduler support for the channel combinations that
substitute SDCCH index 2 for a CBCH in either a SDCCH/8 or SDCCH/4.
Change-Id: Icc15603079a1709ec094f400a9bcf0008211890f
Closes: OS#1617
for some historical reason, CBCH handling was not using the normal
L1SAP boundary. Let's change that and traverse L1SAP just like for
e.g. BCCH which is quite similar to CBCH handling.
This also has the added benefit of logging CBCH via GSMTAP.
Change-Id: Ibdba4c5e808330f8406f441a97fe0e81170fce97
Closes: OS#3534
Whenever a CBCH is used, this results in a new physical channel
combination on the relevant timeslot. The chan_nr_by_sapi() function
must handle those cbch-enabled PCHAN types.
Change-Id: I963909bcec8392ec445d0bcf53a2a8d7d9535444
Normally, the "Common Channel" related RSL messages should actually
contain such a common channel. However, since cell broadcast is
implemented inside what's essentially a downlink SDCCH, we should add
some explicit exceptions.
Before this patch, any RSL SMS BC CMD would have been discarded and
an RSL Error Indiciation returned.
Change-Id: I2f7f1dd43505cc27cd33489d8b0e8c981cd93880
Closes: OS#3533
When adding a new measurement also log the frame number by the modulus
of the measurement interval to simplify debuggung
Change-Id: I77a4d947dab32de0d5717ebf13bd8de6179dfe6a
The parameter bs_ag_blks_res, which is loaded into the BTS via the SI3
setting, defines how many of the CCCH blocks shall be used for AGCH. The
remaining CCCH blocks will then be available as PCH for paging.
Unfortunately there is no unit-test yet that verifies that all of the 8
different settings for bs_ag_blks_res.
- Separate the the decision logic that checks if a given fn is part of
an AGCH into a function to have it available in the unit-test.
- Add a test that checks all possible bs_ag_blks_res settings.
Change-Id: Ib9652f4013a4da3766852f8f03ce9ec5590f6989
Related: OS#1575
The unit-test function test_lchan_meas_process_measurement() does not
tag measurements as SUB. Lets make the test function more realistic by
setting the is_sub flag at the correct positions.
- Add SUB-Measurements in the correct position
- Print log lines when adding measurements for sub, also fix
minor bugs in the log printing.
Change-Id: I25c361b21a406c0017ee586f0492c38f2e737e57
Related: OS#3502
Related: OS#2975
At the moment the measurement calculation of osmo-bts works by
collecting the measurement reports the phy emits during a measurement
interval. Normally one would expect a well defind fixed number here, but
some phys will not emit a measurement report for lost blocks. Also
blocks and their reports may get lost because of cpu overload etc.
The computation that is executed at the end of the measurement interval
computes over all received measurement. This evenutally means that
missing measurements will not taken into account and the result will
look better than it is in reality.
To fix this, the interval must be of a defined size and in cases where
less measurements as expected were collected, the algorithm must assume
they have been received with a 100%BER and take that into account.
However, all RSSI and TA/TOA related computations should continue to
rely on actual measurement data.
- make sure the algorithm works over a fixed interval
- replace missing measurements with 100%BER
- fix and extend unit-tests
Change-Id: Idd30fc07603ad7d042c1fb416e247c3bf7d35c8b
Related: OS#2987
The function is_meas_overdue() does not use is_meas_complete() anymore
and therefore the related log output is wrong. Lets correct this.
Change-Id: I9b7aa2f7a7c75bc3eed0c94b6ef9d17e7e36ce96
Related: OS#2975
The lookup table that control the measurement interval endings do not
make clear what their indexes refer to. Lets give them more distinct
names.
rename sdcch8_meas_rep_fn102 to sdcch8_meas_rep_fn102_by_ss
rename sdcch4_meas_rep_fn102 to sdcch4_meas_rep_fn102_by_ss
rename tchf_meas_rep_fn104 to tchf_meas_rep_fn104_by_ts
rename tchh0_meas_rep_fn104 to tchh0_meas_rep_fn104_by_ts
rename tchh1_meas_rep_fn104 to tchh1_meas_rep_fn104_by_ts
Change-Id: I3dc891e1860109f803c1bfa46445e8fef35586d9
Related: OS#2975
The tests TC_meas_res_sign_sdcch4 and TC_meas_res_sign_sdcch8 are
failing mainly because lchan->ts->nr is confused with lchan->nr.
There is also a small problem with one of the formulas that compute
fn_missed_end.
- Add explainatory comment to the lookup tables on what the index
is refering to
- use lchan-nr instead of lchan->ts->nr when dealing with SDCCH/4/8
- simplfy and fix the formula
- increase the testcoverage of the unit tests, give SDCCH/4/8 also
a thorough check.
Change-Id: I5d555a21003943bf720c53f3a611029ba45339a9
Related: OS#2975
The function ts45008_83_is_sub() is an integral part of the measurement
calculation as it automatically tags incoming measurements as SUB
measurements. This is important in the context of DTX. Unfortunately
there is no unit test for this function yet.
- Add unit test for ts45008_83_is_sub()
Change-Id: Ia26774859f4bf31baee075896905079368bddd42
Related: OS#3502
The Table that lists the fn%104 frame number masks that define which of
the incoming measurements to be recognized as SUB measurements contains
one wrong number.
For comparison see also:
3GPP TS 05.08, chapter 8.3 Aspects of discontinuous transmission (DTX)
- Change 29 to 20 in ts45008_83_tch_hs1[]
Change-Id: Id3698551d94866f418e662b9fe81429b16e2621c
Related: OS#3502
We do not test is_meas_complete() individually yet, but it is an
integral part of the measurement processings since this function decides
where a measurement interval ends.
- Add unit tests that test TCH/F, TCH/H, SDCCH/4 and STDCH/8
Change-Id: I8f89d9e7092cd65ba4d5c5649140692dcc20bdd6
Related: OS#2987
For enabling PDCH on a dynamic timeslot, PDTCH and PTCCH SAPIs shall be
enabled. While osmo-bts-sysmo uses the lchan->type to determine which SAPIs to
enable (see lchan_activate() in osmo-bts-sysmo/oml.c:
sapis_for_lchan[lchan->type]), the osmo-bts-trx code instead relies on the
chan_nr indicating RSL_CHAN_OSMO_PDCH = 0xc0 (see trx_sched_set_lchan() in
common/scheduler.c and the PDTCH,PTCCH entries in trx_chan_desc[]).
The 0xc0 cbits are a non-standard invention specifically used for only Osmocom
style dyn TS, so the chan_nr for IPA style dyn TS will and should never include
this cbits pattern. Hence gsm_lchan2chan_nr() correctly always returns the
TCH/F equivalent chan_nr for IPA dyn TS.
Because trx_chan_desc[] relies on the 0xc0 in the chan_nr to activate the PDTCH
and PTCCH SAPIs, internally patch the 0xc0 cbits over the chan_nr in
osmo-bts-trx/l1_if.c for channel de-/activation, iff lchan->type == PDTCH.
This is technically a convoluted mix-up of the cbits usage. Nevertheless, it is
the simplest way to make IPA dyn TS behave the same as Osmocom dyn TS in
scheduler.c.
Apparently, IPA style dyn TS have never worked for osmo-bts-trx before?
Related: OS#3493
Change-Id: I0eed8a135f2ab7e7c0d15ad5c76430b7fe54df3d
osmo-bts-virtual uses UDP multicast to communicate with its virtphy
counterpart. At the momemnt SO_REUSEADDR is not applied for those
multicast connections because OSMO_SOCK_F_UDP_REUSEADDR is not set. This
makes prevents the proper function of UDP multicast.
- Make sure OSMO_SOCK_F_UDP_REUSEADDR is set
Change-Id: I7f27758b7aa786c8dbae669cbcde10baab8e4845
Depends: libosmocore I1399a428467ca12f1564a14eb8ffb294d4f59874
Related: OS#3497
for SDDCH4 channels, the detection is not working correctly since the
function uses the lookup table for SDCCH8 interval endings there. This
needs to be corrected. Also there are two unnecessary assignments in
the code which should be removed.
- use correct table (sdcch4_meas_rep_fn102 instead of
sdcch8_meas_rep_fn102.
- remove unnecessary assignments to last_fn_mod
Change-Id: If8a269ecd3f9fa4eeadf379114db816ef5c77d77
Related: OS#2975
Rewrite an if-statement to better match the description given
in GSM 05.08, and quote the relevant paragraph in a comment.
Since this entire block of code only runs for SDCCH and TCH,
this new condition should provide the same result expect that
in accordance with the standard we now stop sending fill-frames
on a signalling TCH if DTX is in use.
Also note that this code should already cover parts of the
patch proposed at https://gerrit.osmocom.org/c/osmo-bts/+/5753
The changes to osmo-bts-litecell15/l1_if.c proposed there
should be equivalent to the fill-frame logic in this
existing common BTS code which is handling RTS IND.
Change-Id: Ibaf3ecbd0bde4f37e799d5e2f5d00dc695e0139a
Related: OS#1950
the measurement interval end is detected by using the measurement
indication that is related to the SACCH block as a trigger to start the
computation. If the measurement indication for the SACCH gets lost
because the block could not be received then the processing is not
executed. This may cause wrong results or when it happens condecutively
an overflow of the measurement sample buffer.
- Store the frame number of the last received measurement indication
- Use the stored frame number to check if an interval was crossed when
the next measurement indication is received. If we detect that we
missed the interval, catch up by running the computation and
start the next interval.
Change-Id: I3a86cd8185cc6b94258373fe929f0c2f1cf27cfa
Related: OS#2975
At the moment only lchan_meas_reset is reset on channel activation.
All other states are not reset. This may lead to irretations in the
first measurement interval if there are still leftover messages from
a previous connection. Lets ensure everything is reset to zero by
zeroing out the whole .meas struct in struct lchan.
- Add a centralized function that does the reset
- Call that function from rsl_tx_chan_act_ack() in rsl.c
Change-Id: I880ae3030df6dcd60c32b7144c3430528429bdea
Related: OS#2975
Related: OS#2987
In l1sap.c we call lchan_new_ul_meas() and lchan_meas_check_compute()
directly in sequence. Lets unify thos two steps inside measurement.c so
that we only need to call one function from l1sap.c.
Change-Id: If48bc7442dfaab8c36b93949f741de6e836e792a
Related: OS#2975
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
the testcase definitions in meas_test.c that define different test
situations for uplink measurement are quite large. Lets have them in a
separate file so that the code meas_test.c is easier to maintain.
- Move all mtc* and ulm* structs as well as the struct definitions
to meas_testcase.h.
Change-Id: I90139ec535056d2cea6de10e77f435d807ce496e
Related: OS#2987
The .tarball-version file should contain the *source version* uniquely
identifying the git commit, and not the Debian package name.
With https://gerrit.osmocom.org/#/c/osmo-ci/+/10343/ there is a correct
.tarball-version file in the .tar.xz of the nightly source packages.
Change-Id: Idde432ffd3dae3b7beac77c794e60b6ba555e488
Related: OS#3449
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
During SACCH FILL processing, update lchan SI values only
for lchans which follow BTS-global default values, keeping
lchan-specific overrides in place.
Change-Id: I515bbd9983fa894507386b241863a9aa4d279497
Fixes: eee7247ebe
Related: OS#3173
When a SACCH FILL is received, loop over all lchans and update
their copies of system information data.
This change makes BTS_Tests.TC_sacch_multi_chg pass.
Change-Id: I3e63eeb5fcf320fb029de16e4d327e153cc34567
Related: OS#3173
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
Other backends use already msgb in lower layers and eventually call
add_l1sap_header to push TCH data up the stack.
backends using common/scheduler.c (bts-trx, bts-virt) are the only ones
not yet using msgb in lower layer but only creating the msgb
immediatelly before sending it in _sched_compose_tch_ind. Let's add a
log message there too to have similar output in all BTS backends.
Change-Id: Ia90b051f308abcd8b88b84e861da593844b0d81a
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
src/common/sysinfo.c:147:1: warning: control reaches end of non-void function [-Wreturn-type]
}
The compiler warning is actually a false positive since we call
OSMO_ABORT on that path, but let's add a return anyway so the
compiler doesn't throw a warning.
Change-Id: I9b4e06927489a8bc20ce173279a01415a8c4295a
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
At the moment osmo-bts does not compile with the latest header
file release from OCTSDR-2G-02.10.00-B1837-ALPHA as there are
struct members removed and new ones added. The changes do not
affect actual functionality in the existing code. The only
affected parts are vty functions that query status information
about the clock sync manager.
- Add detection logic in configure.ac to detect if the affected
struct members are present
- Add conditional compiling to handle the different combinations
of available struct members.
Change-Id: Ic38d8dc35522205c4ffab583b4e61b5ef03cdba2
Related: SYS#4139
Patch-by: Octasic inc.
in change-id Iebd2571726d1284a7431b3f9b23ad3185e832ed1 we introduced
tighter validation on whether the requested channel number matches the
underlying physical channel configuration. Unfortunately this broke
activation of an osmocom-style dynamic PDCH as TCH/F or TCH/H
rsl_lchan_lookup already permitted a chan_nr if the dynamic PDCH was
already switched to the given TCH mode, or at least the related
switching had already been initiated.
However, in the case of the bug, the current type is NONE, which means
that the compatibility check of rsl_lchan_lookup will fail
Let's relax the checks of rsl_lchan_lookup() slightly to permit
matching for "ts->dyn.pchan_is == GSM_PCHAN_NONE" cases.
This fixes BTS_Tests.TC_dyn_osmo_pdch_tchh_act and
BTS_Tests.TC_dyn_osmo_pdch_tchf_act
Change-Id: I14ae4c4ed2aae0966e5cb5116cf024d6bd890237
Related: OS#3134
It seems that the IPA PDCH ACT ACK contains not only the channel number,
but also the frame number. Let's make sure we're as close as possible
to other implementations to ensure maximum interoperability.
Change-Id: Ibe7988e9ef374e8c7d9429777fb32322d90c2024
When writing chan_nr_is_dchan() in Change-Id: I43a78bec63aeb36dd67043d237b27fe880209349,
I apparently only looked at TS 48.058 without considering the osmocom
extension to it for PDCH activation. The result is complete breakage
for "osmocom style dynamic PDCH" support.
This patch fixes the mistake by making the compare more specific.
Change-Id: I18e0774fdd48966bc95261e715f798464b8b681f
Related: OS#3131, OS#1853
Completely drop bts_log_init(), call osmo_init_logging2() directly instead: all
callers of bts_log_init() passed NULL as category string, so all it ever did
was call osmo_init_logging(). The bts_log_info is already declared in the .h.
Here and there also define a proper talloc root context instead of using NULL.
Change-Id: Ic049f77bef74123b95350bcae182a468e0086b9c
This commit restores ability to read write to the
SuperFemto EEPROM.
Use offsetof() instead of casts to pointers when
calculating the address to pass to
eeprom_read() and eeprom_write()
Fixes: 7cf144b27d
Change-Id: Iaa7318387ad7bb248c261b1f428019244039e7d2
This assumption used while sending the rx data to gsmtap in l1sap_up was
making osmo-bts-virtual crash, since that bts model is allocating the
l1sap in the stack rather than inside the msgb.
Instead, let's use the assumption that l2h is set correctly in msgb by
the bts model lower layer.
crash report:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6234ec3 in __memmove_sse2_unaligned_erms () from /usr/lib/libc.so.6
(gdb) bt
0 0x00007ffff6234ec3 in __memmove_sse2_unaligned_erms () from /usr/lib/libc.so.6
1 0x00007ffff6dbf4c8 in gsmtap_makemsg_ex (type=<optimized out>, arfcn=arfcn@entry=17255, ts=ts@entry=6 '\006',
chan_type=<optimized out>, ss=ss@entry=0 '\000', fn=fn@entry=11249, signal_dbm=0 '\000', snr=0 '\000',
data=0x5555557d5b50 "", len=4294967263) at libosmocore/src/gsmtap_util.c:179
2 0x00007ffff6dbf6d8 in gsmtap_send_ex (gti=0x555555877f10, type=type@entry=1 '\001', arfcn=arfcn@entry=17255,
ts=ts@entry=6 '\006', chan_type=<optimized out>, ss=<optimized out>, fn=11249, signal_dbm=0 '\000', snr=0 '\000',
data=0x5555557d5b50 "", len=4294967263) at libosmocore/src/gsmtap_util.c:311
3 0x00007ffff6dbf765 in gsmtap_send (gti=<optimized out>, arfcn=arfcn@entry=17255, ts=ts@entry=6 '\006',
chan_type=<optimized out>, ss=<optimized out>, fn=fn@entry=11249, signal_dbm=0 '\000', snr=0 '\000',
data=0x5555557d5b50 "", len=4294967263) at libosmocore/src/gsmtap_util.c:330
4 0x0000555555573571 in to_gsmtap (trx=0x7ffff7ef8070, l1sap=0x7fffffffde80)
at osmo-bts/src/common/l1sap.c:397
5 0x0000555555573b9c in l1sap_up (trx=0x7ffff7ef8070, l1sap=l1sap@entry=0x7fffffffde80)
at osmo-bts/src/common/l1sap.c:1285
6 0x000055555555ec06 in virt_um_rcv_cb (vui=<optimized out>, msg=<optimized out>)
at osmo-bts/src/osmo-bts-virtual/l1_if.c:170
7 0x000055555555f5c6 in virt_um_fd_cb (ofd=0x55555587cc30, what=<optimized out>)
at osmo-bts/src/osmo-bts-virtual/virtual_um.c:50
8 0x00007ffff6db6991 in osmo_fd_disp_fds (_eset=0x7fffffffe090, _wset=0x7fffffffe010, _rset=0x7fffffffdf90)
at libosmocore/src/select.c:216
9 osmo_select_main (polling=polling@entry=0) at libosmocore/src/select.c:256
10 0x0000555555576fbc in bts_main (argc=5, argv=0x7fffffffe288)
at osmo-bts/src/common/main.c:364
11 0x00007ffff61b5f4a in __libc_start_main () from /usr/lib/libc.so.6
12 0x000055555555c4ca in _start ()
In the old code when the sizeof(osmo_phsap_prim) was being substracted
it resulted on a negative len which later was casted to unsigned int and
became a really big number.
Fixes: OS#3092
Change-Id: I51a880328497673a06d153bfb76c428265b8cbb8
In omldummy, we don't have a RSL link and hence any transmission
attempts to RSL should silently go to /dev/null rather than printing
error messages via libosmo-abis. So check for the OMLDUMMY variant and
silently discard any RSL message that the code may want to transmit.
Change-Id: I04a9ec7e416822cc1e45c533e6a66628689615ad
This is used only in integration testing, where in the TTCN-3 testsuite
we currently have no A-bis OML implementation, but only a RSL one.
Change-Id: Id8e5f34091e6e32621d8c8673de7ea848dfd252f
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
Rathert han have 11 direct members of gsm_bts_role_bts, group them
into a sub-struct as ew do for other parts like interference, laod, ...
Change-Id: Iefecf4b70c1b11c650913f2ae3783718ffb8a36c
What we remove here is a legacy from sharing this header file with
openbsc/osmo-bsc-sccplite, which we stopped to do quite some time ago
and hence can remove those parts that are only relevant to the BSC but
not to the BTS.
Change-Id: Icac1656da68f6a006a28c779e3b563bbdd905b3d
In order to be able to introspect not only the root application
context, but also all other contexts, e.g. allocated within
libosmocore or other libraries, let's enable tracking the
use of NULL contexts using the corresponding talloc API.
In order to obserbe all existing contexts,
use the following VTY command:
OsmoBTS# show talloc-context all ...
Example of usage:
OsmoBTS# show talloc-context all brief
talloc report on 'null_context' (total 1302808 bytes in 5185 blocks)
lapd context contains 129 bytes in 5 blocks
struct signal_handler contains 40 bytes in 1 blocks
struct pcu_sock_state contains 120 bytes in 1 blocks
struct lookup_helper contains 24 bytes in 1 blocks
struct signal_handler contains 40 bytes in 1 blocks
struct signal_handler contains 40 bytes in 1 blocks
abis contains 49065 bytes in 19 blocks
struct signal_handler contains 40 bytes in 1 blocks
struct signal_handler contains 40 bytes in 1 blocks
struct signal_handler contains 40 bytes in 1 blocks
vty contains 93690 bytes in 5008 blocks
logging contains 2862 bytes in 7 blocks
OsmoBTS context contains 1156678 bytes in 137 blocks
Change-Id: I5e9381902dace7dfd37f98b657e4697b5afcff96
Provide a sane means of adding the -Werror compiler flag.
Currently, some of our jenkins.sh add -Werror by passing 'CFLAGS="-Werror"',
but that actually *overwrites* all the other CFLAGS we might want to have set.
Maintain these exceptions from -Werror:
a) deprecation (allow upstream to mark deprecation without breaking builds);
b) "#warning" pragmas (allow to remind ourselves of errors without breaking
builds)
As a last configure step before generating the output files, print the complete
CFLAGS and CPPFLAGS by means of AC_MSG_RESULT.
Change-Id: I5b37602a117350159183fb53ac330294b94f4195
The existing algorithm (present since 2012!) failed to work
in the sole case that only *one* SACCH filling type was present.
So if you had your BTS configured to only broadcast SI5, but not
broadcast SI5ter, SI6 or any other SACCH filling, it would send
the SI5 message only once on a newly-established channel, and never
again.
The old code was working for more-than-one SACCH filling, as well
as for no SACCH filling at all.
Let's also add a NOTICE message if there is no SACCH filling available
at all. This is highly unusual and definitely a noticeable event.
Change-Id: Ica801f9b9c118f00d9e3dc2780b3123e925f59b4
Closes: OS#3057
Related: OS#2963
Record the mnc_3_digits flag from SI and pass on via the PCU interface.
Instead of changing to e.g. osmo_plmn_id, add the flag separately, and instead
of bool use a uint8_t, to not raise any struct packing issues and clarify the
flag's size beyond any doubt.
Bump the PCU interface version to 9.
This is one part of the three identical pcuif_proto.h patches:
- I49cd762c3c9d7ee6a82451bdf3ffa2a060767947 (osmo-bts)
- I787fed84a7b613158a5618dd5cffafe4e4927234 (osmo-pcu)
- I78f30aef7aa224b2e9db54c3a844d8f520b3aee0 (osmo-bsc)
Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore)
Change-Id: I49cd762c3c9d7ee6a82451bdf3ffa2a060767947
When using a firmware version < 3.6, the call to l1if_mute_rf()
returned an error, which caused an OML CHG ADM STATE NACK.
Let's check if the l1if_mute_rf() call is an un-mute for all
timeslots (which apparently we do always at start-up). If it is, then
acknowledge it even if muting is not supported by earlier firmwares.
I suppose the change causing this problem was introduced in:
commit b26b8fc776
Author: Holger Hans Peter Freyther <zecke@selfish.org>
Date: Tue Mar 4 15:03:59 2014 +0100
sysmobts: Do a RF mute at initialization when the RC is locked
With the current change applied, we can run the BTS with earlier
firmware versions than 3.6.0 again. Tested with 3.1 and 2.4
Change-Id: I1a29c1031d96e65a0111bc812a90f2dbaf2a5aa3
SI1 is only required if frequency hopping is used or if NCH is used. So it's optional.
If OsmoBTS has no SI1 configured, it will transmit the empty SI1 buffer
at TC=0, and as a result no valid SI will be broadcast at TC=0.
Change-Id: I41ab885c00e943199b2e939e98f30e267ecffbee
Closes: OS#3051
Commit c2b4c668f3
I3b989580cb38082e3fd8fc50a11fedda13991092 introduces evaluation of ra_ind
members below the msgb_trim() call that actually invalidates ra_ind.
A symptom is that it breaks detection of Handover RACH, wich always ends up
with lchan == NULL and interpreting all RACH as chan_nr == 0x88.
Fix: do all evaluation of ra_ind before the msgb_trim(), for osmo-bts-sysmo,
litecell-15 and octphy.
To guard against similar mistakes in the future, set ra_ind = NULL before the
msgb_trim() call.
Related: OS#3045
Change-Id: I203021ee57f49cb963679ba8bec5943e2abb67fb
the file l1_tch.c in the octphy spcific code has its root in the
tch.c file of sysmobts. It contains some sysmobts specific ifdefs
which enclose dead code.
- Remove the sysmobts specif ifdefs and the dead code
Change-Id: I33f3e0fd293ca8387fddf5ed20f642621e9680de
In general, RACH bursts should not arrive with negative offset.
Let's limit early signal arrival up to 2 symbols, otherwise it
is most likely noise, interference or a ghost.
TTCN-3 test case: Icccc88545ed3aabd6da28a40599a8a77d1de477d
Change-Id: I662294fe3136cf7a259be13816a3e63f7db9a948
For some reason, the noise / ghost filtering was performed for
normal RACH requests, but not for handover RACH requests. There
are also ghost RACH, interference and noise possible, so let's
extend the filtering coverage.
Change-Id: I94fc15835280d624780200dadc4418210bf565ff
It makes sense to combine both existing BER (Bit Error Rate) and
ToA (Timing of Arrival) checks into a separate funcition, so
this code may be also used for handover RACH.
Change-Id: I1ddda238d5212a88a3dd5c4fc5dfcfea018151bd
Previously, the number of RACH slots with valid non-handover RACH
burst was incremented between both BER (Bit Error Rate) and ToA
(Timing of Arrival) checks. So, if a RACH burst passed the BER
check, but was dropped by ToA check, the counter of valid RACH
requests could be increased anyway.
Change-Id: I31594a8c5dce1f42226ced5b2dc8778152b3d829
The BTS_CTR_RACH_DROP counter is being increased in case if a RACH
request is ignored due to exceeding ToA value, but remains untouched
in case of exceeding BER (Bit Error Rate). Let's fix this.
Change-Id: Ia02e781d6c47d9d8012a4c8846fe4b731aab74d7
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
The current log output logs connect_ip connect_port
speech mode and payload type over multiple lines and without
logging context (lchan name). Also the logging level
incorrectly set.
- shrink log output into one line.
- add context (lchan name)
- encode ip/port into human readable form
Change-Id: I61044edc0672b268aeebf48b59a772887703399f
Closes: OS#3001
Add PCU_IF_MSG_DATA_CNF_DT and PCU_IF_SAPI_AGCH_DT to bring the
pccif_proto into sync. Both commands are required to support the
rb11 with an osmo-bsc co-located pcu.
Change-Id: I6d330aca26249ee94ece5e415079f0b75c6e8b48
PCU_SOCK_DEFAULT is defined in the pcu counterpart of the file pcuif_proto.h
To be consistent with the pcu move the definition pcuif_proto.h
The pcuif_proto.h will be exact the same in the pcu repo and bts repo.
Change-Id: I67f8ec036e219994cc296d0ed5409da7f3ec681e
warning causes the compiler to throw an actual warning. Lets
change those intentional warnings to messages.
Change-Id: I2fc83a1a07db9c569b93f29835bf3a0fd8ef4ef5
In OsmoBTS, we (so far?) only have a single BTS inside each process,
let's make sure we log an error message if the PCU should ever want to
transmit primitives to a non-zero BTS number.
Change-Id: I158f935fed12941737c806c0677a8192ea3418a0
Don't blindly trust that the ts_nr received on the PCU socket will be
small enough to not overflow our timeslot array!
Change-Id: Ie9964c8dc0ca7b049da7dfec0ac0a0d3f1aedd45
The downstream code of pcu_sock.c doesn't contain any length checks,
so let's discard any messages that are shorter than the primitive
length.
Change-Id: I35ac84d4db6d21ea61afbd1864c810bbf601d69b
Normal Abis RSL MEasurement Results contain only the "MS Timing Offset
IE" in units of full symbols. In some use cases it is important to have
higher-accuracy timing information exposed to the BSC.
We do this by adding the average timing offset value during the last
measurement interval in 1/256th symbol accuracy to the "Supplementary
MEasuremen Information" part of the TS 48.058 9.3.25 Uplink Measurements
IE.
In order to avoid any compatibility issues, this feature is only enabled
if the new vty config command "supp-meas-info toa256" at the bts node
is enabled.
Change-Id: Ie85e53b47d4041cc4e6d7b78406ae8b79b2d9397
At the end of a measurement processing window, we currently compute
the ToA / timing offset at 1/256th symbol accuracy, but we only print
it to the log. Let's store the value in the lchan to make it usable
by other code in follow-up patches.
Change-Id: I5f00a16ac966b627d9452a98b8fa70984bed684a
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
When decoding RACH bursts, we should use a BER threshold in order to
help distinguish 'ghost' RACH bursts from real RACH bursts.
The theoretical ideal threshold according to some papers is 7 out of 41
bits qhich aquals to Eb/N0 of 0 dB = 0.1707 (17.07%)
We add a new 'ber10k' parameter to the RACH indication l1sap primitive
(needs separate change for libosmocore), and then fill this value from
osmo-bts-{sysmo,lc15,trx,octphy}. The common part above L1SAP then
applies the threshold, which can be changed from vty using the
"max-ber10k-rach <0-10000>"
command available at the BTS node. The unit is BER in 1/10000, i.e. a
value of 100 equals 1% bit error rate.
Change-Id: Ic41c11f6312a36baa2738547e8dcec80829457f8
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
The existing code contained an ugly hack that if we didn't have any
"SUB" measurements we would simply use the "FULL" values. That's wrong
as TS 45.008 contains quite detailed rules on how the "SUB" values are
to be computed. In some cases, they are identical to "FULL", but in
most they are not.
Let's remove the hack and replace it with an ERROR message, as clearly
something is wrong if we ever encounter a measurement period end in
which no single "SUB" measurement was received. The only situation in
which this can occur is if the related uplink burst/block was missing,
so let's set BER to 100% and level to lowest possible.
Change-Id: I358f7b97fd4ea19264a77eff7abef13da7d5fbcd
The rules on how to compute RX{LEV,QUAL}-SUB are rather convoluted, and
depend on the detailed channel type and mode.
For SDCCH and TCH/H in signalling mode, it's easy: No DTX is allowed,
and all measurements are used in SUB.
For non-AMR (TCH/F and TCH/H in non-signalling mode), we need to count
the SACCH block measurements, as well as any
SID/SID_UPDATE/L3_FILL/DUMMY blocks received in the blocks of table
8.3 of TS 45.008.
Only AMR (TCH/AFS + TCH/AHS) are more difficult, as there are no fixed
blocks/bursts/frames that always contain uplink messages, but the L1
will have to determine if a valid SID_UPDATE was received or not.
This patch implements the above rules (except AMR related) in the common
part of OsmoBTS. The AMR specific bits will have to follow as a later
patch, likely in a BTS specific way, i.e. separate changes to
sysmo/lc15/octphy/trx code.
Related: OS#2978
Change-Id: I16eb3747a1c23df935a4c50dafe46abce512a474
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
Combined CCCH with CBCH is a separate PCHAN type and hence we must
accept it in the list of RACH-carrying pchan types in order to correctly
report the RACH chan_nr when handing RACH requests up to L1SAP.
The bug this fixes likely might have rendered cells with combined CBCH
impossible to use.
Change-Id: I9537463e5eedd2b8b30f298e0d3b308367c5b1fb
L1SAP uses 'ber10k' values, i.e. BER in 1/10000 units, where 10000
is all errors are bit-errors (= 100%).
The PHY on osmo-bts-sysmo and osmo-bts-lc15 is reporting a float fBer
value scaled to 1, i.e. 1.00 = 100% and hence must be 10000 as ber10k.
Before this patch, BER values reported on those BTS models were too
low by a factor of 100, resulting in way too optimistic RxQual values
reported to the BSC.
Closes: OS#3005
Change-Id: I17e2f8fe8055f613da1e554cd36ed13289f56fb3
Let's introduce some functions to hide the details of BER and RSSI
conversion from OCTPHY representation to L1SAP representation.
Change-Id: I517669c87a97b2ba164a2812811c8802fe0b92e8
Since Change-Id: I23fba50f48415314da40cf5bf86fce2ed3e66af6 we were not
reporting measurements for SDCCH channel types due to the wrong
encoding of the sdcch{4,8}_meas_rep_fn102 table.
Let's fix the table by encoding the needed information:
"What is the modulo-102 remainder of the first burst of the last block
before fn%102 reaches 37?" (SDCCH/4)
"What is the modulo-102 remainder of the first burst of the last block
before fn%102 reaches 12?" (SDCCH/8)
The TS 45.002 Clause 7 tables have to be consulted carefully to
determine this information.
Change-Id: Icf02354872670126ab3297b787b216981ca6c309
Related: OS#2965
In case a DLCX _with conn-id_ is issued without any CRCX before,
we ran into a NULL pointer dereference in adding the connection
statistics. Let's handle this gracefully and simply return empty
statistics.
Change-Id: If8b71266c847b90cdc51695b9f47b527c51bd70c
Closes: OS#2996
In case a DLCX is issued without any CRCX before, let's handle this
gracefully and simply ack the DLCX anyway.
Change-Id: I7c5bedccfc5a7cf552a9ce3a2dc712081c7ce177
Closes: OS#2996
The RR PAGING TYPE 3 Rest Octets IE contains (among other things) the
channel type needed for Mobile Identity 3 + 4 in the paging message.
We did not only "forget" to encode those channel type needed field, but
we have a completely wrong definition of those rest octets in
libosmocore/include/gsm/protocol/gsm04_08.h "struct gsm48_paging3"
Change-Id: I3a0bca6707ce95b68459c89f5b2b07f1590a1ab3
Closes: OS#2994
It seems we have been encoding PAGING REQUEST TYPE 1 and
PAGING REQUEST TYPE 2 erroneously all the time. The optional last
Mobile Identity in those messages are TLV, not just LV.
This is a quite serious bug in one of the most fundamental parts of
the Radio Resource layer, and it has likely stayed hidden for a long
time as usually in small networks there's a low paging load, reducing
the amount of pressure to put multiple identities in one PAGING REQUEST
message.
Change-Id: Icc320ed130d0c29e9260a6a2aabe52e7346c3888
Closes: OS#2993
This patch adds generation of a DELETE INDICATION when the BTS AGCH
queue overflows due to too many IMMEDIATE ASSIGN CMDs, as required
by the specs.
The AGCH queue length in OsmoBTS so far is at 1000 entries, which I
consider way too high. But that is for another patch.
Change-Id: Ied3306e85cbdc6f3476b10dc4bb0463cd728b274
Related: OS#2990
Starting the timer in bts_init() may result in it expiring already
before the load indication period is set via OML. Let's make
load_timer_start() safe to call several times and call it from OML
code.
Change-Id: I295d91413542014aa2507d5f09e01243fc3916fa
Fixes: OS#2991
Whenever we receive discontinuous frame numbers from the TRX socket,
osmo-bts-trx is substituting zero-filled bursts for those frame numbers
which we missed. Don't just do this silently, but actually log about
it, as it is an error.
Note: This [currently] happens when using a virtual air interface with trxcon
as opposed to a real SDR receiver with osmo-trx.
Change-Id: If79eab37c80647c9ab64f399fa4676d97af3e9ad
info_meas_ind on the L1SAP always allowed the lower layers to pass
in whether a given measurement is part of the "SUB", or not.
However, the existing l1sap code before this patch simply drops this
information, despite the measurement.c code also having "is_sub" state.
Let's make sure this state is passed from L1SAP into measurement
processing as intended.
Fact is, none of our current lower-layers actually set this is_sub flag
for their primitives passed up in L1SAP, but at least now *if* they
would set that flag, the measurement code would process it as intended.
Related: OS#2978
Change-Id: Ibed2e8d7563b471c6b5dd2214ac4765caf31ed2a
This is currently only used for logging, but will be needed for proper
RX{LEV,QUAL}-SUB reporting in upcoming patches.
Related: OS#2978
Change-Id: I07fd06e8a379cab7c0c2eb111c3f5600037d3c9e
This reverts commit d5fdcfe6d9, which
introduces a new function lchan_meas_update_ordered_TA whose
functionality I still haven't yet managed to fully understand. It
appears to be adjusting the requested timing advance (lchan->rqd_ta) but
outside osmo-bts-trx/loops.c code. This is odd, as rqd_ta is a state
variable of that loops.c code.
So for one part, it is a failure of encapsulation. The TA loop code
should be self-contained, particularly as it is only used for
omso-bts-trx, and not for the other BTS models. The new
lchan_meas_update_ordered_TA() function is used from common code,
applicable to all BTS models.
The resulting interaction between loops.c code and this new (now
reverted) function cause the TA value to only ever grow, despite the MS
never moving at all.
Change-Id: I5a5adac6f18f94a5b51758a5ace8ef6ddfd23e80
Related: OS#2989
For proper measurement processing of RX{LEV,QUAL}-SUB, we will
need this information.
Related: OS#2978
Change-Id: I768fde62452a74dce471ebf946e56eb1e4de1abc
Let's split the look-up of the multiframe scheduler from the asignment
to a given l1ts in trx_sched_set_pchan.
Related: OS#2978
Change-Id: I79548b25aae647ce993a9d83c771d22b08cb1c74
Measurement reports fed into L1SAP so far had their frame number always
set to zero, resulting in higher-layer common code above L1SAP to never
detect the end of the measurement period, which in turn caused no RSL
MEAS REP to be sent.
Related: OS#2978
Change-Id: I67837d19515ea335614928570c12dd5027104c6b
In Change-Id I5703b46c8a59fe00a3cdc063bcf72872980ec5e5 we introduced
LOGL1S and starte to use in in common/scheduler.c as well as
osmo-bts-trx but somehow we didn't introduce it in osmo-bts-virtual
at the time. Let's catch up.
Change-Id: I0b5fd3b7982b9119becda844531108f64c68d19f
Let's make sure whenever we do have a frame number, we print it as
context in the related log line
Change-Id: I751d5ddb3322fce489bc241459738cbcc55c890b
The problem is that measurement processing above L1SAP requires/expects
those PRIM_INFO_MEAS indications from the bts specific parts. Otherwise
it will never generate even uplink-only measurement reports to the BSC,
which is a violation of Abis protocol specs.
Change-Id: I48f73293cb4f0ab4c657dfd00e7ddd032a3c030f
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
The VTY command show bts does not display the bts specific
features yet.
- Also display the feature list in snow-bts
Change-Id: I509f2a7bbfa96c70bdfea4ff2488ee371e914620
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
The feature list does not cover any speech codec related information.
- Add speech codec related items to feature list.
Change-Id: If6d50c6f4e2348b23f31c3415b0f5577a3f5be50
If the Channel Number IE points to a common channel, we cannot
accept such messages in code paths that only process dedicated
channels, such as RLL/DCHAN/IPA.
Related: OS#2972, OS#2971
Change-Id: I43a78bec63aeb36dd67043d237b27fe880209349
If we receive a message for a dedicated channel, whose channel number
structure doesn't match with the physical channel (timeslot) type,
we must properly reject this. For RSL CHAN ACT it means sending a NACK,
and for all other cases it means sending an RSL ERROR REPORT.
Related: OS#2972, OS#2971
Change-Id: Iebd2571726d1284a7431b3f9b23ad3185e832ed1
This avoids compiler warnings like this:
../../src/osmo-bts-sysmo/l1_transp_hw.c:130:13: warning: implicit declaration of function ‘writev’; did you mean ‘write’? [-Wimplicit-function-declaration]
written = writev(fd->fd, iov, count);
Change-Id: Ic67d369a3ca33bfa636ace9f272f1c7257de86e1
This avoids compiler warnings like
../../src/osmo-bts-sysmo/eeprom.c: In function ‘eeprom_WriteSysInfo’:
../../src/osmo-bts-sysmo/eeprom.c:605:58: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
err = eeprom_write( EEPROM_CFG_START_ADDR + ((uint32_t)&ee.cfg.v1.sysInfo - (uint32_t)&ee), sizeof(ee.cfg.v1.sysInfo), (const char *) &ee.cfg.v1.sysInfo );
Change-Id: Ic748038e6f25ec18ccb4a2f2503ca567fb00a586
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
A recurrent kernel crash in sysmobts (several kernel versions)
corrupting kernel memory in random places has been investigated and
reproduced by placing a call against an MSC sending RTP
with bandwidth-efficient AMR payload to osmo-bts-sysmo.
The osmo-bts-sysmo in turn sends the payload to the femtobts related
kernel modules via a msgq, which most probably fail to handle correctly
this bw-efficient AMR payload and corrupt the kernel memory.
First approach was to drop the bw-efficient AMR payloads lower in the
stack in sysmo specific code (l1if_tch_encode), but as there's no bts
model in osmo-bts actually supporting bw-efficient AMR, let's drop it
early in the incoming path for all models to avoid further problems.
Related: SYS#4063
Change-Id: If0c9233c628c724de4ab74e58e3e2affac79e6d0
Previously we always printed error on startup:
l1sap.c:461 Invalid condition detected: Frame difference is 627202-0=627202 > 1!
This is expected and of little practical use. Let's suppress it
by checking that FN was actually initialized.
Change-Id: I4f7cf285e437db0e980e1a2a3ab48a7255945448
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
This adds printing of remote RTP IP/Port, LAPDm SAPI information,
MS Timing offset, propagation delay, encryption algorithm+state,
loopback status and radio link failure counter to the "show lchan"
command. It also adds TODO comments fro those bits that are not yet
printed but which would make sense to print.
Change-Id: Ic4bc47638b7b402aee9344dc912745a9929c37f4
This is more or less a 1:1 import from the BSC side commands. Having
the commands on the BTS side will allow us to expose information that's
not visible to the BSC [in upcoming, separate patches].
Change-Id: I2a596938849a9c84fe6fedcac5d7f71ee97af575
Commit 5eb17e28ac added this warning when
implementing the full function. However, other backends seem to be also
passing the primitive from the stack to l1sap_up without any visible issues.
Furthermore, according to the documentation of l1sap_up, it takes ownership of the
msgb, but doesn't take ownserhip of the prim itself.
Change-Id: I45fe40e3377eac999d1dac5356678195381d94ca
This warning was included in commit
6d7b78bde1 from 2011, and nowadays I only
see this command used in osmo-bts, so I think we most probably drop it
as it doesn't make sense anymore.
Change-Id: Ie277dce00292c8f403b9a2b405efe4429e6af86a
It is required for bts_shutdown used in trx_fn_timer_cb, and compiler
warns about implicit declaration.
Change-Id: I274662cd657ce8c36ed1d262d138590808bfafea
The function rsl_tx_mode_modif_nack() uses abis_bts_rsl_sendmsg().
This function relys on msg->trx to be set (see abis.c). However,
rsl_tx_mode_modif_nack() creates the message buffer, but does
not set msg->trx.
- Make sure that msg->trx is set properly
Change-Id: Ib5990db11df1b25dc5d321193731426b11f8005a
When the RSL_IE_CHAN_MODE is is missing, then the message buffer
is freed and the channel mode modify is nacked using
return rsl_tx_mode_modif_nack()
The function rsl_tx_mode_modif_nack uses abis_bts_rsl_sendmsg()
which returns 0 on success. This eventually leads into a double-
free in rsl_rx_dchan() which frees the message buffer on all
return codes except 1.
- Remove the excess msgb_free() in the error handling path.
Change-Id: I946a927ba35aa115520b1248eefccd91832f69f6
The independent copy of pcuif_proto.h file is used by OsmoBTS so we
don't have to checkout OsmoPCU to obtain it.
Change-Id: If8d7330adf3edc44c3b49b1f6e854cce0eca2d8e
The sysmoBTS-specific headers were never looked for in the current
directory. None of the CI tests use it as well. None of the other BTS
models use such defaults. Let's just drop this to restore expected
header location semantics.
Change-Id: I0b2906e284e1e22a960c4f0f1f38724de009eda5
Previouslywe could end-up passing empty '-I' to compilerif corresponding
_INCDIR variable was not defined during the ./configure step. This is
apparently tolerated by gcc but still seems like a wrong thingto
do. Let's fix this by moving -I inside of *_INCDIR.
Change-Id: I80915e5756d1bf64d789cfd5341fdd417ca8eed9
When testing for sbts2050_header.h during ./configure stage, use proper
include path defined earlier.
Change-Id: I55e50f612ab2a082b34096d71359dd08da150cf1
When testing for the presence of particular BTS model-specific header
during ./configure step, we don't need to add LIBOSMOCORE_CFLAGS because
none of those headers use it for compilation. Moreover, adding it might
hide the problem if the headers under check are available in the same
location where libosmocore headers were checked out.
Change-Id: I64bf1acb9db999567e8a2a6690cfc96d6e4b7ee1
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
The default (for both manual and .deb builds) is to use shared build (as
before) - the static build is entirely optional.
Change-Id: Iabdebefef5c07dd1cd4b94b29ca40c6be0f8adda
Add missing LIBOSMOABIS_CFLAGS and LIBOSMOTRAU_CFLAGS.
Pair the _LIBS below the _CFLAGS in LDADD above (cosmetic).
Fixes the stow-enabled jenkins builds are currently failing like below:
In file included from ../../include/osmo-bts/gsm_data.h:136:0,
from ../../include/osmo-bts/bts.h:4,
from misc_test.c:23:
../../include/osmo-bts/gsm_data_shared.h:21:35: fatal error: osmocom/abis/e1_input.h: No such file or directory
#include <osmocom/abis/e1_input.h>
Change-Id: I94ea8bad8b410550f72ee6a0408f42f6bd8b6cac
Add configure option --with-sysmobts=$INCDIR (like for LC1.5).
Use to fix the jenkins build to fix the build after migration to stow, where we
can no longer use a commin -I to include the sysmobts headers as well.
Tweaked-by: neels
Change-Id: I0416a9f4c428189cd9c3909c8bd016ca2908128a
Passing configure flags in DISTCHECK_CONFIGURE_FLAGS requires enclosing all
flags in quotes. Currently we seem to have no callers with more than one
configure flag, so we were lucky not to break there.
Change-Id: I37bc517a30d00c744eddc8565a0a8181cb3b2cdb
It's prerequisite for jenkins tests fix after migration to stow. The
sysmobts-calib uses hand-coded Makefile instead of automake which makes
it hard to properly propagate build flags. Also, make it optional to
enable excluding it from certain jenkins tests.
Change-Id: I3b54bfa5ef1d89092f6cf13dc27de10874b31b18
The unittest module meas_test.c contains a lot of unused header
files as the result of a cut and paste error made earlier. Also
the reference to stdio.h is missing.
remove all header file references that are not needed.
add missing header reference to stdio.h
Change-Id: I167be096ed25a86b1114de1ada955822a0b42856
In oml_ipa_mo_set_attr_cell, as well as we do in other set functions in
the same file, we want to store a parsed value from a TLV received on
the network into a host local structure. We hence need to use ntohs
instead of htons.
Change-Id: Icbf65f8a4b871b0fa2e84ad6cd2188d4e34f704b
The function trx_by_l1h() is used to fetch the pointer to a an
osmo_bts_trx from a list. The ID that is used to reference the
transceiver comes from the incoming message. If the firmware
sends odd identifiers (firmware bugs, damaged packets) the
transceiver can not be found in the list and a nullpointer is
returned, which then leads into a nullpointer derefernece
problem.
Check the returncode, and depending on the situation either
return with -EINVAL or exit osmo-bts immediately.
Change-Id: I04ef3b4896e1322c2a6d29ea86a88994c7748bf7
Wireshark was showing a Malformed packet alert, and further
ivnestigation showed that "Resource Information" TLV was missing in the
packet. See GSM 08.58 sections 8.6.1 and 9.3.21 for more information.
Indicating interference level is not yet implemented, but at least now
we avoid sending a malformed packet.
Patch has been validated against a running setup with wireshark in my local PC.
Related: OS#2735
Change-Id: Ie97170811aaf8a089febfa20380ab48ea174056a
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
Problem:
lchan->tch.dtx.dl_amr_fsm struct failed to allocate in l1sap_chan_act routine
in l1sap.c due to illegal characters contained in lchan->name which are passed to
osmo_fsm_inst_alloc routine. As a result, lchan->tch.dtx.dl_amr_fsm is NULL
causing BTS crashed (SEG FAULT) when trying to access this struct.
Below is snapshot of crash log obtained by GDB:
...
Fri Nov 24 18:13:55 2017 <0000> rsl.c:1653 payload type: 98
Fri Nov 24 18:13:55 2017 <0000> rsl.c:1463 (bts=0,trx=0,ts=2,ss=0)
RSL Tx IPAC_MDCX_ACK (local 127.0.0.1:11538, remote 127.0.0.1:30012)
Program received signal SIGSEGV, Segmentation fault.
0x00031930 in dtx_dl_amr_fsm_step (lchan=lchan@entry=0xb69592a8,
rtp_pl=rtp_pl@entry=0x87ae8 " \024\351Y\363_\337\345\351f\177\373\300\210\201\200\210",
rtp_pl_len=17, fn=1728481, l1_payload=0x10dd25 "", marker=marker@entry=true,
len=len@entry=0x10ddc4 "\024", ft_out=0xbefff7d7 "\002",
ft_out@entry=0xbefff7cf "\276\341_\032") at msg_utils.c:233
233 msg_utils.c: No such file or directory.
...
Fix:
* Use different formatting for lchan name passed to osmo_fsm_inst_alloc routine
* Refuse channel activation if FSM could not be generated (as opposed to crash)
Related: OS#2606
Reported-by: Minh-Quang Nguyen <minh-quang.nguyen@nutaq.com>
Change-Id: I929ce3703dc57acf8db569ae0e346265644d0b3c
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
The RTCP Sender Description is supposed to contain useful information
to identify the source of the RTP stream. So far, it only contained
compile-time default data of libortp. Let's put the BTS UnitID, the
lchan number and the OsmoBTS version in there.
This change requires libosmo-abis Change-Id Ice794f9e0c6caeea1c67520c12efbfa375d1fb82
Change-Id: Id6ce7188354d3a0517661c9648854ec829ef1cac
Related: OS#2701
The respective errors/events occur as a result of calling osmo_rtp_*
API, and are clearly more fitting into the DRTP category than the DRSL,
even though the respective actions are triggered by RSL.
Change-Id: I52e6f9865492a2f757a37860eb92a3dc49e174ef
Contrary to osmo-bts-sysmo, the OCTPHY-2G does not have different L1
SAPI for AGCH and PCH. It uses cOCTVC1_GSM_SAPI_ENUM_PCH_AGCH for both,
and we convert that to the cbits=0x12 (Downlink CCCH) on the L1SAP.
The code above L1SAP can hence freely decide if it wants to respond with
an AGCH or PCH message, based on its knowledge of BS_AG_BLKS_RES,
without the OCTPHY specific code having to do anything about it.
Hence, there's nothing to do, and the warning can be removed
Change-Id: Ic1038b8dc57bdaf05493cd8479355b960275ea41
Related: OS#1575
There's no point in either having full verbosity in DEBUG level
and not logging any measurement related information in INFO. Let's
at least print the results at the end of each measurement period in INFO
level.
Change-Id: I2c870531478c05ce31cc1015597a068a4a76cf99
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
Despite the CalypsoBTS transceiver is similar to OsmoTRX, there
are some changes required to make it work with OsmoBTS. Let's
add a new configuration example for that.
Change-Id: Ia4b1797de576ab987b05046aa9a9828858023ed3
It seems like rx previously had 'float' type. Remove the comments and
checks which are not relevant since rx is 'int'.
Change-Id: Idb4aad53667f88f9656c5bb1c52e7e75b385f446
Fixes: OS#2223
Recently while testing new osmo-mgw, big RTP packets (around 4K bytes,
see OS#2625 for more info), were being received on the BTS, which was
aborting with the following message:
"msgb(0xff208): Not enough tailroom msgb_put (348 < 1488)"
The crash can be reproduced in a sysmobts as well as on my PC locally
with osmo-bts-trx. I used osmo-bts-trx to test that the patch solved the
abort.
Fixes: OS#2624
Change-Id: Idfde1dacc3dc3d3d5e239cf1f7e39ade7fc25975
When osmo-bts detects a mismatch between the firmware of the DSP
and the header version which it was compile with, a hard exit
is performed. In some cases this may hinder debugging/testing things.
Implement a commandline option to intentinally override the check.
Change-Id: I5774fbb29da832786326afb991014b9bd8b04b59
When determining if a frame is a fill frame or not, the case
statement only conditionally handled AGCH and PCH cases. In
case a non-fill-frame was observed, the return value was uninitialized,
resulting in some non-fill-frames to be missed from GMSTAP
Change-Id: I7b46c720e34cb8ef9a91ae5da28a050439a1937d
Closes: Coverity CID#174175
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
I was unable to start osmo-bts-lc15 with this config file until this
change was made, it said this command didn't exist.
Change-Id: Iae80e2ed504b5e26d748d57be7558ce470555f97
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I5e8e9d7989ee20fe722bdd3109965d5bce9519fb
This marks a new release that's compatible with libosmocore >= 0.10.0,
and which no longer depends on openbsc-dev.
Change-Id: I67405cb5f0f4dea85c67febfdef80f49ae1d41a6
We've had openbsc.org ages ago but have moved everything to osmocom.org
at some point in 2010/2011. This should have been updated back then
Change-Id: I5da8e9fba8f15719414fa81e2a6211f906329c2e
See osmo-ci change I2409b2928b4d7ebbd6c005097d4ad7337307dd93 for rationale.
Depends: I2409b2928b4d7ebbd6c005097d4ad7337307dd93
Change-Id: I830b17462b636e0bf03f4d88000660409503c3e5
We can either try to really build with those old versions or find the
minimum version, or we can simply require latest version of all
libosmo*, which is the safeest choice for now.
Change-Id: I08915540b92d5135b0c325e30b5b6e24f88e6282
Since libosmocore Change-Id I9ef59432f43a3cdb94e4cbb0c44ac3f9b2aac0f2
we enforce that FSM names do not contain illegal characteers such as
spaces. Let's change the DL TX FSM for AMR to comply to this. Also,
actually do check the result of the FSM registration.
Change-Id: Ieccd1dc32c0faf5e544d17daca4a417d1d168c21
Power control loop test outputs next to nothing which is not very
helpful. Make it more verbose. While at it, also move duplicated code
into static function to make test cases less cluttered.
Change-Id: I0a5e65e23e62442ef8758ecbcf8e7820b4f15d7b
Related: OS#2223
There's nothing sysmobts specific in this test so let's move it into
separate directory and run unconditionally. The test itself is unaltered
except for intro text.
Change-Id: I0d1957cd9cf5497826be095c7a42b7bb4fa10397
Related: OS#2223
Previously it could be possible that the attribute request comes from
BSC before the TRX is properly initialized which would lead to SIGABRT
caused by OSMO_ASSERT() in PHY instantiation. Workaround this by
explicitly checking for TRX availability before handling TRX-specific
attributes.
This only happens with osmo-bts-trx and is hard to reproduce. Ideal fix
would be to defer attribute response until we have TRX connected but
that would make corresponding code more complex because we'll need to
save the attribute request and properly hook response routine into TRX
connection handler. Alternatively we can postpone osmo-bts-trx
connection to BSC until TRX is available: it's not very useful without
it anyway.
Change-Id: Id36885e507c4a3203b5662c0fde12c5206174d82
Fixes: OS#2560
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
Previously clock source configured via vty was ignored. Check that it
wasn't configured and only apply default value in that case.
Change-Id: I8de74a12d2096971a8a83946dc6c7cdb9889acd7
Fixes: OS#1944
Make get_clk_cal() public and use it for ctrl commands handling. This
ensures that the calibration is properly selected depending on the clock
source.
Change-Id: I1c809d48f29ef8e8c50641f882d7a954dfcf88f9
Related: OS#1944
The dependency on OpenBSC has been removed in
ec33b0397f so we can drop it from jenkins
scripts too.
Change-Id: Ie28d444f2154f5b4bbbd9a1cb45b74ebca890cb1
Previously the received SI was copied to si_buf unconditionally which
means that the first SI2q message is always overwritten be the last one.
Fix it moving check for SI2q ahead of generic code and moving generic
copy into else branch of SI2q check.
Change-Id: Ib8031d2f0e00368283a40b4aadb3eea616038d04
Related: OS#2357
* 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
When printing BTS via 'show bts ..' let's also print each TRX, which phy
number and version it uses and its description. It's helpful in
troubleshooting low-level issues as it allows vendor-specific code to
easily expose firmware version.
Related: SYS#3884
Change-Id: Iabcc862566b40a9314f3e1d17fda61d8ab24a3cd
* remove leftover from copy-paste of corresponding OpenBSC code
* print OML link state
* print paging load
Change-Id: Ia5e3dc10efe2b5ab212cab1518a10d36b20b8bb2
We re-use the same facility to send different data so it's better to
print actual cause value to avoid confusion.
Change-Id: I9413ecf57eaa6fc661f1a57ccdaa2f04c50ea43b
Previously result of readv() was used unconditionally so when it failed
and returned negative value it was treated like very large positive
which lead to memory corruption. Fix this and add proper error log.
Change-Id: I956c8d551f45c9dd43b5e9de11dfe20dd8783647
Related: SYS#3865
* 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
If SI13 becomes unavailable in runtime than send 0-length message with
BCCH SAPI to PCU to indicate that SI13 have to be removed.
Change-Id: I72aef8bd98f21c4b5ea6eed21fc56b30d85bfc1b
Related: OS#2400
* explicitly set SAPI when sending data_ind to PCU
* drop unused receiving code for BCCH SAPI
* send SI13 when PCU is connected
* send SI13 when new SI is received
Change-Id: I9e83ef792585aa962f99897d9973cef12f186bcf
Related: OS#2400
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
Use Obj. Class and TRX# from abis_om_fom_hdr of incoming request instead
of BTS' MO to properly distinguish between BTS-level and TRX-level
attributes.
Change-Id: I8b5a5ab8bd07daf2500b66dec428b89b7f8cd852
Related: OS#2317
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
When somebody kills the process, it's best to handle the signal
and to use the opportunity for some cleanup. We always did this
in the BTS on SIGINT, but never on SIGTERM. Let's change it.
Change-Id: I10009c08b7178988f646e2b6035197b9640ac9b5
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
* move duplicated code into separate functions in jenkins_common.sh
* use that function in individual builds
Change-Id: I4d09c5f2693b5ac0a4d8f2c840971e13d1ec58cf
Implement API functions bts_model_ts_connect() and
bts_model_ts_disconnect() in order to support dynamic timeslot
allocation.
Change-Id: Ia109d4bfade7bc28442127581f4bb0289146ea71
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
In openbsc.git Change-Id I61c18a7f021fcb1ec00d34a745f4e3ab03416c2d
we changed the gsm_bts_alloc() function signature to include
a second argument (the BTS number). This broke omso-bts, and this
commit is intended to make it build again.
Change-Id: I7ef7654d48c1cfc7e4ecb0b771553ec0740ce2bf
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
There's very little point in sending fill frames (such as empty PAGING)
or dummy UI frames via GSMTAP all the time. They serve no purpose other
than to bloat the log files and make it more difficult for users to find
the interesting bits among all this noise.
Change-Id: Icd18dafb235933c9e6aa9d98ddd8fac1522cc9ac
So far, L1SAP code is hiding RSL_CHAN_OSMO_PDCH from the bts specific
code below L1SAP. This is some kind of a hack/workaround, making code
and debug output / logs more difficult to understand.
So let's teach the lower layer how to treat RSL_CHAN_OSMO_PDCH and
remove the "hiding" code from the common l1sap.c code.
Change-Id: Iaaa833febe45b82166d3901f10cc5466a7591c19
service sets led to orange before/while osmo-bts is being started.
osmo-bts-lc15 sets led to green while operating. (unchanged in here)
service sets led to red when osmo-bts stops running.
Change-Id: If351f49d1ead359192d0d80bbc381afd3459c940
The RSL Channel ID is best read / interpreted as hex value, not as
decimal, primarily due to the fact that it is a bit-mask of various
fields.
Change-Id: I9b72a67407870b485e7f7e8a72fa1ad30fc8ed4d
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
There are plenty of functions stubbed out in osmo-bts-virtual, let's
print a NOTICE level log message to be able to correlate any kind of
erroneous behavior with the fact that a given function has no actual
implementation.
Change-Id: Ib607d192f90af7fb2d5a8747de5527f39e3cfefa
That's mostly changes related to lc15bts-mgr from
https://gitlab.com/nrw_noa/osmo-bts branch nrw/litecell15 based on
eb5b7f80510b603579f7af6d7d5ead296c2fa260 commit:
* adjust comments to simplify further diffs
* add libsystemd dependency to lc15bts-mgr
* add software watchdog which uses it
* ocxo calibration and gps related code
Change-Id: I475a330af771891ba3c897294ce0dd57ec2ba8db
Related: SYS#3732
The sysmobts- and lc15bts- mgr have different semantics for the same
command line option (-n: writing to EEPROM vs writing to ROM). and
different default value. Hence it make sense to use separate files,
similar to osmo-bts-*.service
Change-Id: I645a81e30d7146ff26720391db763b6d585037e6
Related: SYS#3728
In a larger simulated network with multiple BTSs it is normal that one
BTS will see GSMTAP frames for an ARFCN that is not an ARFCN used by the
local BTS. This is just normal operation.
Change-Id: Ic68cace9648ccb17500c94b6ede8814674aa9c29
That's mostly changes related to lc15bts-mgr from
https://gitlab.com/nrw_noa/osmo-bts branch nrw/litecell15 based on
eb5b7f80510b603579f7af6d7d5ead296c2fa260 commit.
I wanted to incorporate vty and hardcoded paths changes so we can use it
from this point without major backward-incompatible changes as a base
for future ports.
Change-Id: Iabbaedc84aaaa594150a4e5445c16dd1f6f89858
Related: SYS#3679
* move common code into separate function
* print error similar to parameter reading code
Change-Id: Icf3285d7bb921d212cb8945e835be2c81189fb87
Related: SYS#3728
Recent introduction of VIRT-PHY broke .deb build. Fix it by installing
osmo-bts-virtual as part of Debian package.
Change-Id: I1ca7eb51019247eb95c6bac752d6e2c4406ce5a2
When no SI 2bis, nor 2ter, nor 2quater is in use, then the code in
bts_sysinfo_get() will return null, causing the transmission of a dummy
frame (0303012B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B) instead of a
system information message. This is - at least - very odd and might not
be backed by the specification. We should simply send any other system
information message instead of sending a frame that does not have a
valid SI header.
While 030301 might be a valid, empty UI frame on a DCCH, it is not a
valid frame for the BCCH, where the header is structured differently.
In fact, bts_sysinfo_get() should never return NULL and always return a
valid BCCH message.
This bug was found while developing
http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo/Test.ttcn
Change-Id: Ifeaed27d1d7ba9994fb8ce67d660648bcc8efece
Closes: OS#2365
It is important that we reliably terminate the BTS in case any of the
VirtPHY multicast sockets dies for whatever reason.
Change-Id: I5ae3fdd7cc35fdf235550a3b8362020fdd287c13
The addresses in the original code make little sense:
* 224.0.0.1 is "All systems on this subnet" and not routed
outside the local ethernet segment
* 225.0.0.1 is in a RESERVED range that shouldn't be used
Change-Id: Iba1ae69f3f193a33f1da343c6562f67bd8d3557f
Frame number will restart at 0 after each superframe (approx. 6.1 sec)
if enabled. Can be enabled by preprocessor define.
Change-Id: If3adf14df5fcd8daf53363c27b3772c42d7122e9
The defaults must be set during bts_model_phy_link_set_defaults()
and can then later be overridden by the vty (from the config file).
They should only be written back to the file if they differ from
the default settings.
Change-Id: I5d7f2c1dc8bc3d11db5c607b664730e4dcd58c96
Timeslot is not encoded in the chan_nr accessible in the channel
description but was taken from there and so it was always 0.
Change-Id: I881a1c61ea47399c9b1385fb220cd587e3593e82
This patch adds a virtual physical layer designed to simulate the
Um air interface between BTS and MS. It does so by encapsulating MAC
blocks (Layer 2 PDUs) via GSMTAP and sending them through multicast UDP
streams, both in uplink and in downlink.
The purpose of this is enable testing without any radio hardware or
related licenses.
OsmocomBB has recently received as similar patch-set, adding a virty_phy
executable that can be run on a PC instead of the classic 'layer1'
firmware on a real phone.
Using GSMTAP means that one can use unmodified wireshark to decode the
messages exchanged on the virtual Um layer.
This code was originally started by Harald in January 2016, continued
by Sebastian Stumpf in late 2016 and early 2017, and finally completed
by Harald in July 2017.
Change-Id: I1bf7670975b1e367c1c62983020865a043542622
The number of SI2quater messages might be updated dynamically by
BSC (via 'bts 0 resend-system-information' command for example). Log it
but do not return error.
Related: OS#2357
Change-Id: I9625be879c672e20543cc40af288828143ffb983
The octasic phy stamps the SACCH channel that carries the
measurmenet indication with the frame number of the last
SACCH that falls within the measurement period.
The higher layers expect the frame number to be aligned
to the SACCH channel after, which marks also the beginning
of the next measurement period.
Make the octphy code compatible to the higher layers by
remapping the measurement indication frame number.
Change-Id: I8ecb27c018bf4ad5151878a6ad34026fd0f801a1
The end of the measurement reporting period is not aligned with the
SACCH block where the results are reported. The tables that are
used to detect the end of the measurement period are therefore
wrong. The frame number of the SACCH block must be used and not the
TDMA frame number (modulo 104) of the measurement reporing interval.
The tables are oriented to the frame number of the first SACCH block,
at the beginning of an interval. However, when a SACCH block is received
it will always contain the result of the recently passed measurement
reporting period.
To match the tables, introduce another lookup table to remap each
SACCH block that ends to the matching beginning block number.
Change-Id: I1eef894e6f15b4449fc8926bebb118624efc7924
l1_if.c does not generate struct osmo_phsap_prim l1sap properly.
The frame number is not included in this struct. This renders the
logic that processes the reported measurements non functional,
since the logic (see measurement.c) is not able to detect the
end of the measurement period. This commit fixes the problem by
adding the missing frame number to the l1sap structure.
Change-Id: I09241d6cc2ff09e71a3d723d90e4468108a27ae1
We should print meaningful error messages in case a user doesn't have
the required local PATH set up, or doesn't specify a required command
line argument.
Change-Id: I30a2935f93ade69222b1e0c3e212ee10e17c1823
ph_data_req() and ph_tch_req() are generating empty (idle)
frames when no data (msg == NULL) is available. Since the
phy is able to generate idle frames internally, there is
no need to waste Host CPU cycles by doing this in software.
Remove the empty frame generation and exit the function
cleanly.
(Patch by Octasic Inc.)
Change-Id: Ib857b7dab490ad426c48d6a9e5e6fa10ef5a0838
Internal l1sap dump_gsmtime has been moved to libosmocore as osmo_dump_gsmtime.
Remove use of internal function and replace with the libosmocore version.
Depends on libosmocore Ib5452e2c20f53006c0f6d197fb055728947125d8
Change-Id: Ia2f89965d970ed5bbb8c0d4f591a043e58c4bd66
After latest changes, l2 expects to receive an event for every TCH
frame, that is, no TCH frame event should be lost on that layer. We
should now then be safe returning always GSM_RTP_DURATION.
The code which used to calculate the variable duration is left there to
assert that indeed we are not longer having this kind of issues.
Change-Id: I9d112c6db142be138e71393e77129e6d069d9973
We want to always call l1if_tch_rx and l1sap_up in order to avoid losing triggering
events on the upper layer.
With this change, the upper layer will increase correctly seq + ts for
RTP. It will then send an RTP packet with only the header and no payload, which is
not correct but at least we avoid drifting the RTP clock. Upcoming patch
in the series solves this issue.
This patch assumes that we are not lossing data events from the physical
layer and that we receive an event every 20ms, even if the MS is not
transmitting due to DTX.
Depends on libosmocore If4ae20c22b881e94585dad710f17b9e37f77bf82
Change-Id: If5df8940fab833eb4e3ed851880b66987d356031
The value string table octphy_cid_vals lacks the strings for
cOCTVC1_MAIN_MSG_APPLICATION_INFO_CID and cOCTVC1_MAIN_MSG_APPLICATION_INFO_CID
(Patch by Octasic Inc.)
Change-Id: I9843137b55534a29938d5c2308244a6950de788f
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
When we're in loopback testing mode for PDTCH, we must make sure to
avoid adding PTCCH blocks to the queue. Only PDTCH blocks must be
enqueued. For the transmit (downlink) side, we already had the PTCCH
check in place.
Change-Id: I7ef40d9bdf74a99375bc6568ed9483499664bf6f
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
The new name makes it clear what the function actually does: Send burst
data via the trx interface.
Change-Id: I5031541d4ae4244a62a18acf71139db2874927fa
There ware some error conditions that the previous code didn't catch
and/or report, such as unparseable TRX control strings, non-terminated
buffers, ...
Change-Id: I354d0c121880553ce1bd59b7394d52b104b7d6da
The layer 1 interface (l1_if.c) for osmo-bts-litecell15 does not include
the frame number into the measurement indications it forwards
to higher layers. The frame number is required to properly
detect the end of a measurement period.
change process_meas_res() to properly include the frame number into the
l1sap primitive (struct osmo_phsap_prim *l1sap)
Change-Id: Iee9c8f88b05cd5dba9920bb08e079a643e713237
The layer 1 interface (l1_if.c) for osmo-bts-trx does not include
the frame number into the measurement indications it forwards
to higher layers. The frame number is required to properly
detect the end of a measurement period.
Change-Id: Ife3c791ff50e8a866a97b9783ac7ef3ef2402a70
This add support for BTS-side lookback of PDTCH channels.
If lchan-loopback is enabled, We take the uplink frames as received in
PH-DATA.ind and put them into the dl_tch_queue for that lchan. When we
receive PH-RTS.ind, we dequeue frames from that queue and transmit them
in downlink. If no frame is found in queue, we transmit an empty
(all-zero) frame of 23 bytes (CS-1).
Change-Id: Idd07a3f4a88c38398d3e844333c0104e2de23864
using gettimeofday() is not suitable for the GSM frame timer, as it
relies on the normal 'wall clock' system time, which may be adjusted by
ntp, gps or other means at runtime.
Switching to a different clock source means we cannot use
osmo_timer_list anymore, but timerfd integrates just fine with our
libosmocore select() loop handling.
Change-Id: I51b19adde14ebb7ef3bb863d45e06243c323e22e
Closes: #2325
When handle_ph_data_ind() runs BER and RSSI is logged. Remove
this log output by removing the call to dump_meas_res
(Patch by Octasic Inc.)
Change-Id: I5e755465daa3daec2e2b4f61bc8d779c49196e9a
nmsg is initalized every time the function runs, even when it
is not needed. Move the initalization into the if (msg) body
so that nmsg is only initalized when we really need it.
(Patch by Octasic Inc.)
Change-Id: If51dc50a9f4bdb4aba62c0ae5fbfac552806f0c0
l1msg is initalized when the variable is declared. This means
the allocation always runs right on the beginning. Even when
the buffer is not needed at all.
do a prober l1msg initalization only when needed and check the
return code.
(Patch by Octasic Inc.)
Change-Id: Ia71d49b9cc109af53d997a687a7fb1b5ed062d1c
Printing the RX payload size is strictly informative, so the
loglevel LOGL_ERROR is wrong. This commit changes it to
LOGL_DEBUG
(Patch by Octasic Inc.)
Change-Id: I712cdd79cbba93f457705d38871bd8d4b7f4e897
* change BCCH Info handler to explicitly support multiple SI2quater
messages sent from BSC
* change SI scheduler to send SI2q in round-robin way
That's resubmission of 340cff51f4 and
186c6bac07 with memory initialization
order change to fix the issue detected by osmo-gsm-tester - see OS#2338.
Change-Id: Ib595733cde108387bc7ee76b1b11ada6a235f13c
Related: OS#1660, OS#2338
The code that receives the uplink measurement data from L1 does not
print the number of already received uplink measurements. Since
this is a valuable information when debugging the log output will
now print this information as well.
(Patch by Octasic Inc.)
Change-Id: I79926f25de088571fcc2c14388c72fc968c2d382
When the lchan is in loopback mode, we loop back all uplink blocks into
downlink blocks. We do not processs any RTP frames for that lchan
anymore. Rather, we discard those RTP frames to avoid mixing
looped-back samples with those received from remote.
Change-Id: I29ef4963e9c491c94c413cbc10436a2388c04d9b
We used to have trx_meas_check_compute() and call that from the
bts-specific code in order to iterate over all timeslots and all lchans
in the timeslots if we have to send measurement reports. This was
executed once per frame, and created unequal CPU load over time, which
in turn might increase different per-ts jitter.
Since 2f028c4e2c in April 2017 we have
lchan_meas_check_compute(), which performs this on a per-lchan basis,
and hence CPU load is distributed over all active timeslots.
Change-Id: I6308cefe4a51e55719ea4ed4d613d3782b805c08
This reverts commit 340cff51f4.
osmo-gsm-tester detected a regression due to this commit, when running
osmo-bts-trx. The modems timed out when waiting for them to register with the
osmo-bts-trx network. osmo-bts-sysmo is apparently not affected. No further
details on the failure cause are known yet. The failure is shown for example by
http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/868/
Change-Id: I15bca30ddc09a7a3044096626016f6130d07636c
This reverts commit 186c6bac07.
osmo-gsm-tester detected a regression due to commit
340cff51f4, which above commit apparently depends
on. Revert this along to avoid conflicts.
Change-Id: I456e9add788393ca781213cef31b5bc3d48fd531
* move code which checks for BTS number (obtained via OML) validity into
separate function
* adjust log messages to match the check
* add spec reference and comments
Change-Id: Id5714fbed910696d30e18d1f20f4c9fced4b9230
Related: OS#2317
This way the name of systemd service file will match the name of the
binary similar to lc15. Add aliases so the user can use both old and new
names regardless of which file is installed. Once the corresponding
changes to OE recipes are applied old file can be removed.
Based on work by Pau Espin Pedrol <pespin@sysmocom.de>
Change-Id: I08615eb625d488603aeb5962ad9f30869c0e77c5
Add jenkins build helper for lc15 and separate header with BTS-agnostic
functions.
Change-Id: Ib47f5a6cc88e784c5662b0dab4ddc03ce9a35132
Related: SYS#3682
Move value_string termination check and OpenBSC headers checkout into
shared jenkins helper from BTS' model-specific helpers to get rid of
copy-pasted code. While at it - also remove unnecessary bash
dependency.
Change-Id: Ic48b1f75179b9008d65219dd5a47c1ab3b886408
* use talloc for file path allocation
* print detailed error on failures
This simplifies troubleshooting of lc15bts-mgr failures.
Change-Id: I86c93a2a4f080e8ac1517be93f58f6ffd00d248c
Related: SYS#3686
In some situations (e.g. when trying to do measurements/testing on the
BTS receiver / uplink) it is useful to have a way to disable the radio
link timeout and keep any channel open until deactivated, irrespective
of whether (valid) data is received or not.
This adds a related feature that can be activated by using an
osmocom-specific value of 0xff for the TS 12.21 Connection Failure
Criterion (9.4.14).
Change-Id: I736f21f6528db5c16fa80cdb905af20673797be5
Check for impossible index and count values of SI2q messages. The limit
is defined in 3GPP TS 44.018 Table 10.5.2.33b.1
Change-Id: I351f8e8641a1cb9548154803da70bfde46ee180d
Fixes: CID 170749
* change BCCH Info handler to explicitly support multiple SI2quater
messages sent from BSC
* change SI scheduler to send SI2q in round-robin way
Change-Id: I3aeb90804edab1b0325c3eb7347526ae995dbf51
Related: OS#1660
* use GSM_BTS_HAS_SI() from OpenBSC instead of local copy
* arrange GSM_BTS_HAS_SI() checks to improve readability
* constify SI scheduler parameters
Change-Id: If74bc536fe7d2bfbc976c07d882151873ecda4f2
Related: OS#1660
Set (possibly incomplete) list of BTS model-specific features and report
them in response to attribute request via OML.
Change-Id: I5f8a6681c3562ec261441e84dde6e085b516d92f
Related: OS#1614
* detect if attributes are requested for BTS or TRX and act accordingly
* report TRX phy version
Change-Id: I9f72305bbf1ab74745bffac1bee9f539f5a6de32
Related: OS#1614
* copy sysmobts-mgr.cfg to sysmo/ directory
* add lc15bts-mgr.cfg
The configuration is BTS-specific so it should be located inside
appropriate subdirs.
Note: the old copy of sysmobts-mgr.cfg can be removed once the image
build recipes are adjusted.
Change-Id: Ic81197464809ba508b2572e86dd978a994f4b116
Related: SYS#3686
Use systemd template specifier for config name instead of hardcoding
it. This will allow to specify different config file name depending on
the name of the service file.
By default sysmobts-mgr.cfg will be used preserving compatibilty with
existing installations but if the unit is named lc15bts-mgr.service than
lc15bts-mgr.cfg will be used. This gives us necessary flexibility to use
BTS-specific configuration.
Change-Id: I475df6a06691390120eea0bd8a61fa469df2bd2d
Related: SYS#3686
The debug log does not print much information about the measured
rxlev and rxqual values. This commit adds debug output to make
measurement debugging simpler
Change-Id: Ic871eed6dcbc7d10aca6cd11dbc803b3e6da449f
The higher layers relay on a normalized version of frame number
in order to detect the end of a measurement period.
The frame number on which the measurement reports are sent may
depend on the phy, so we need to normalize the frame number
before we report it to the higher layers.
Change-Id: I90bd01479e41f04a6b0aefe3845d071e3148d0c6
The offsets used in the lookup tables may be phy dependand. So we
will have to do the alignment in the layer 1 interface of the
phy dependand code before we report the frame number up to the
higher layers.
This reverts commit e0fb3ae52d.
Change-Id: I8acab50cc1bb1cb133831c6a145f4d790e99176c
The priv pointer of the callback function app_info_compl_cb() is
set to null by the pointer. It should be set to pinst instead.
Besides of that there is a memory violation while accessing
the local variable ver_hdr using osmo_strlcpy(). Both is fixed
with this commit.
Change-Id: I558d78ef29e9a4d8f45f4142611f11289d3ed806
This is resubmission of 9eeb0b1a13 with
errorneous use of talloc_asprintf() removed which should fix OS#2316.
Change-Id: I02ae6fffdc808c1ea14185dbb4a720d27a62d4bb
Related: OS#1614
Timing advance is currently not taken into account when computing
the measurement results, this commit fixes that
Change-Id: I2e0dfd13b53e8aa2822985f12bf2985e683ab553
This reverts commit 9eeb0b1a13.
This commit caused osmo-gsm-tester test runs for the sysmoBTS to fail with
SIGABRT consistently. See below redmine issues.
In osmo-bts-sysmo/l1_if.c, it uses talloc_asprintf to write to the char
version[MAX_VERSION_LENGTH]; talloc_asprintf() however is intended to work on
string buffers allocated by talloc, and attempts to reallocate version[].
Furthermore, it is not clear why the patch passes a 'data' arg to
app_info_sys_compl_cb() that is not used.
Hence I will revert this instead of trying to fix. Please resolve issues and
re-submit.
Related: OS#2316 OS#1614
Change-Id: I2c9fd5e6739c1750365c0241476ce4b1aa2df3d4
The so-called "RTP mode" of the DSP contains a bug on all firmware
versions < 5.3.3 which causes the bit-order within each of the
non-aligned codec parameters to be wrong. Introduce a function
originally written by Sylvain Munaut during 32C3 in
http://git.osmocom.org/openbsc/commit/?h=sylvain/32c3_codec&id=5b4a16bbe93a7b1ace65cc23d6cce56ecf4f1275
to bring the bits into [the correct] order.
This has never been seen in a "pure sysmoBTS" setup, as all BTSs would
use the same (wrong) bit-ordering and thus interoperate. This patch now
checks for an affected DSP firmware version and then jumbles (old DSP
firmware version) or does nothing (new DSP firmware version).
Change-Id: Ia0eee4f514fb8fd81c052bb44a4facba898d6afb
Closes: SYS#2452
OsmoBTS won't run without being connected to a BSC. The BTS wouldn't
start to transmit if the BSC doesn't properly initialize it. So if we
want to activate some channels manually for testing, we should do so
from the BSC, and not inside the BTS code. Doing this in the BTS means
that the BSC is not aware of it and might want to use that channel for
something else meanwhile.
Osmo{BSC,NITB} has gained ability to manually activate a channel from
the VTY in Change-Id I44fc3904678eb48bd3ab1a3da8c0c265fa082e0d as can be
seen at https://gerrit.osmocom.org/2759
So let's remove the old/obsoleted code here.
Change-Id: I7ba0301b55cc283aa6a441899f84357e28a97321
For some reason, osmo-bts-trx did another take at parsing
NM_ATT_CONN_FAIL_CRIT and storing the second octet in
btsb->radio_link_timeout, just like the generic code already does in
oml_rx_set_bts_attr(), but without proper checking and any error
message. Let's remove it.
Change-Id: Idb0179e1443c0b5a97e59919dba684a001e90192
Make more use of TLVP_PRES_LEN() instead of plain TLVP_PRESENT() and
implicitly assuming a certain length of the information element.
What this obviously doesn't introduce is some kind of error
generation/reporting in case the minimum length is not fulfilled. An IE
that's too small is silently ignored by TLVP_PRES_LEN() and treated as
if the IE wouldn't exist in the first place.
Change-Id: If5c4eee65711c49bc8ba4675221b1d5fd16198e9
l1_if.c does not generate struct osmo_phsap_prim l1sap properly.
The (logical) frame number is not included in this struct. This
renders the logic that processes the reported measurements non
functional, since the logic (see measurement.c) is no longer
able to detect the end of the measurement period.
This commit fixes the problem by adding the missing frame number
to the l1sap structure.
Change-Id: I2bab40c30d727395eb3096026810917407419cd7
Event handling is done internally in the Octasic BTS. When the TRX is opened,
events are enabled automatically and when TRX is closed events are disabled.
The change is valid for the recent firmware version and for the last couple
of previous releases.
Change-Id: I0652627495f6a9bcb0da2431b8beb839bc22062b
recent octphy firmware versions do support proper channel measurement handling.
The new implementation replaces the old, and for osmo-bts non functional
implementation.
This commit introduces the necessary adjustments. Older firmeware releses will
still work. However, the measurement computation results will still be wrong.
Change-Id: I0f053bb10b1cb112a8814ee591969d607888e686
instead, let's introduce a specific function for that. Also, as this
can be easily determined from the frame number, skip one argument to
tx_tch_common().
Change-Id: Ibbb9b685cf0b6a45339b0874438a500dd6254bc2
gsm0503_conv.c should have been removed as part of
efbef50efc but somehow was left here. It's
not referenced/compiled by the Makefile anymore, and the gsm053_conv.c
in libosmogsm has superseded it anyway.
Change-Id: Icdcca1bc55a83c76ec47918dc4dd301155210091
The DATA-IND, received from the physical layer does not only include the actual
uplink data. It also includes the frames which are received when the channel
is idle (which is just noise). This would falsify the measurement results.
Depending on the BTS model, the phy may also filter the idle frames and not
send a DATA-IND at all, when the channel is idle. If this is the case, the
measurement period end can not be detected properly.
The idle frames are located at the very end of each measurement period. In
order to fix the issue, the measurement perioud has to end early. For TCH/F and
TCH/H 1, one frame has to be skipped. For TCH/H 0 two frames are skipped.
Example: For a TCH/F in TS0, the Measurement perioud would end at frame number
103. However, 103 is reserverd as idle frame. So we need to detect the end of
the measurement period at frame number 103 (-1).
Change-Id: I471a767c7974bdacadc3233d0c3e7b7965f6eafa
After switching to libosmocoding there's no need in low-level bursts
test which is part of libosmocoding anyway.
Change-Id: Icb8caf62ac653a39a7a82f2225e8edeab7f5afb5
Computing the measurement results on in l1sap_info_time_ind() all
at once may peak the host CPU. On smaller systems (arm based
sysmobts) this might cause a noticable delay of other important
tasks (e.g. passing l2 messages back and forth) It makes more
sense to compute the measurement results continously when
l1sap_info_meas_ind() is executed.
Change-Id: Iecb9a30c0d716bfc88221cd752b1ffdc74269e30
lchan_meas_check_compute() is a static function measurement.c.
In order to distribute the measurement result calculation events,
we need to be able to call lchan_meas_check_compute() from l1sap.c
Change-Id: Ideffe896613e0feda443bc13dac59dcdbbc605aa
The measurement reporting for the MS on a SDCCH lacks some of
the periods, defined in 3GPP TS 45.008, section 8.4.2. This
adds the missing conditions by adding complete lookup tables.
Change-Id: I23fba50f48415314da40cf5bf86fce2ed3e66af6
The l1 interface does not explicitly set the flag for 11 bit
rach when a rach request is received. Since the current and
previous octphy firmwares do not support 11 bit rach requests,
the flag should be explicitly set to zero.
Change-Id: Ifa165c56e54d272caafa45d1bf0e177848fcdfbd
Firmware releases OCTSDR-2G-02.07.00-B1314-BETA and newer require
to align the GPRS frame number (fn-3) for ph_data indications.
To preserve compatibility the header version is checked during
compile time and the right method is compiled in.
Change-Id: Ib93d5fb3b34ff92f10021a0e9ce9c8aa3044b7ff
CBCH is activated when the SAPI for TS0 is activated. Since the CBCH can be
configured on any physical TS, we wait until all (TS7 is the last) physical
timeslots are configured.
Change-Id: Ie307bf9f370a346686e3bd8c8a8483953a1bc279
the function is_meas_complete() uses the *_meas_rep_fn104[]
lookup tables, defined at the beginning of the source file.
These lookup tabels contain a lot of magic numbers. This
commit adds a more elaborated comment with a reference
to the specification/section in order make the values
understandable.
Change-Id: Ic6e4037f965772e6b851c67662d5e7bf64cc04eb
the function ber10k_to_rxqual() has only a very brief
comment with the spec reference. This commit adds a more
explainatory comment that makes it easier to understand
from where the ber10k constants are taken.
Change-Id: I3d3488c97d0bffa7d449d3675afcc75b2a6a2703
* move BTS model name resolution into separate function
* add convenience wrappers for BTS type and number fo TRX and use then
in L1 interface
Change-Id: I4649100df8f1b8e095f210fc294567ba014c0b6a
Related: OS#1614
SI2quater support as per 3GPP TS 44.018 will require chnages to the way
System Information is stored because it uses 1:n instead of 1:1 mapping
between SI type and generated SI content. This should not affect other
SI types though. To facilitate this transition:
* convert the code to always use GSM_LCHAN_SI helper instead of
accessing buffer directly
* move duplicated code to inline function
* add logging for buffer truncation and corresponding length values
Requires I74e4e3cb86364cec869a1472a41b4a95af0d50dd in OpenBSC.
Change-Id: Ie97be6ead6ce6d2d425fbfac8429bb90afb95acc
Related: RT#8792
While at it - do not serialize NULL as a string when delivering OML
Failure Report.
Change-Id: I41a731bd719aee0bbb98d3236405fb3a7f3ddec0
Related: OS#1615
When a new TRX is allocated using gsm_bts_trx_alloc() (see gsm_data_shared.c in
openbsc.git), than it is added to the list in order. When octphy is shutting
down the BTS, it uses llist_for_each_entry() to iterate the tansceiver list to
shut all transceivers down. This means it starts the shut down process with
the primary TRX and then continues with the secondary transceivers in order.
However, octphy does not allow to close primary TRX if the secondary TRX is
open. The shutdown sequence must begin with the secondary transceivers and
finish with the primiary transceiver as last item.
The problem can be easily fixed by iterating the transceiver list in reverse
order using llist_for_each_entry_reverse() instead of llist_for_each_entry()
Since this is a change in the common code, all BTS models (not only octphy)
are affected, but from the logical perspective, this change makes sense
for all other BTS models too.
Change-Id: I18485de586b402610f9e98053d69e92bc9b18dc2
Make it possible to store:
* Static vs. DHCP mode
* IPv4 address
* Netmask
* GW IPv4 address
* DNS IPv4 address
Add a simple CRC8 and pick 0xFF as initial value so an all
zero EEPROM will not generate a 0 CRC. The code tries to
differentiate exit code between unreadable EEPROM and CRC error.
This is a reference to see if we want to have store it in the
EEPROM or not.
Change-Id: Id8a37fe952ef2a8ef36778729f506f900accf8d1
RTP jitter increases continuously because duration is not
updated when speech resumes in DTX mode.
Change-Id: Ib51ed95a449369222c957b3acebd9ce1f66c5435
Add optional MS timing offset (3GPP TS 45.010 § 1.2) to RSL MEASUREMENT
RESULT (3GPP TS 48.058 § 8.4.8). The value is calculated either directly
from corresponding BTS measurement or from 3GPP TS 48.058 § 9.3.17
Access Delay (for known TA) and is invalidated after RSL report is sent
until new measurement indication or RACH is received.
Change-Id: I4dfe5c48834a083e757d5de3236a02e15a238b28
Related: OS#1574
add support for the TX/RX antenna-id feature that has been
introduced with release OCTSDR-2G-02.07.00-B1314-BETA. The
user can now set individual ID numbers for the TX and for
the RX antenna.
Change-Id: I872fe3c4d7b593358a4ce2f02cf0726611b9f3aa
With octasics latest release (octsdr-2g-02.07.01-B1351-beta), some struct
members are moved or renamed. This patch adds ifdef-logic and configure
checks to restore compatibilty.
Change-Id: I73287983e8bed8bf64b2ab87e6b810c2c59ea6fd
Making use of the multi-trx feature requires to tell osmo-bts that
more than one transceiver are available. Otherwise it will complain
that not enough transceivers are available. This can be quite
confusing, even a correct config file will fail to parse if it
specifies more transcrivers than available.
This patch adds a hint to the error message so that the user knows
that he should check the -t commandline option
Change-Id: Ifbeacd9d43f7c6cd74a1e1b33288e66828fe843f
Some header file versions support multi-trx and some do not. After
to compiling it is very difficult to find out if the binary is
multi-trx capable por not. This patch adds a log line that should
rule out any doubts.
Change-Id: I257c0a5e7c5ff5df2f0a603d1ede6db5679382e0
octphy_hw_get_rf_ant_tx_config() uses define constant
cOCTVC1_HW_MSG_RF_PORT_INFO_ANTENNA_RX_CONFIG_CID instead of
cOCTVC1_HW_MSG_RF_PORT_INFO_ANTENNA_TX_CONFIG_CID. This commit
replaces exchanges the wrong constant with the correct one.
Change-Id: Ie4de23daf79bb07ca0c0b818eefe350d18d27e4d
In case a system has a high-gain external PA (like a 40dB PA) connected
externally, we cannot simply switch the transceiver to 0 dBm in
trx_init() only to then start the ramping at much lower levels once the
PHJ completes in trx_init_compl_cb(). The result would be a short
0 + 40 dBm spike followed by later ramping. We want to avoid that
spike, particularly its associated inrush current, so let's bring up the
board with smething very conservative like -50 dBm, and then ramp from
there.
Change-Id: I0ad91fce64f65e0213c9fcfde3390ace519055db
Fixes: SYS#3259
Currently the channel combination II is used for TCH/H, which
allows only one lchan to be allocated. The reason is that it
saves a bit of CPU by disabling UL burst detection on lchan 1.
There is also the channel combination III, which allows to
increase channel capacity, providing two lchans on a single
TCH/H timeslot.
Ideally we should implement some dynamic II <-> III switching
depending on the network load level. But for now this change
replaces the channel combination of TCH/H by III, until dynamic
switching is implemented.
Fixes issue: https://osmocom.org/issues/1795
Change-Id: I8fd4abb42c153fcd26bcfe22a2554b5c2d02d810
* DTXu: don't set marker for broken frames
* do not attempt to send 0-length bursts to avoid flood of errors after
bts startup
Change-Id: Icb536f951386b9abe34c0dacbb203f3db1e41bb3
The macro L1SAP_IS_PTCCH(fn) only detects a PTCCH channel at fn%52 = 12,
the detection logic has been extended in order to detect PTCCH at fn%52 = 38.
See also 3GPP TS 05.02, Clause 7, Table 6 of 9
Change-Id: Ia6f3333121e5e920c5e1d562a081d0a1b58a1153
The ra parameter indicates the reason for the received rach
request. osmo-bts uses the ra parameter to determine if the
received rach request is packet access related. If yes,
osmo-bts will forward the request to the PCU.
In order to determine if the ra is packet related or not,
the higher 4 bits must be equel to 0x7 and at least one of
the lower 4 bits must be zero.
The current method lacks checking of the lower 4 bits. It
would also accept 0b01111111, which is reserved for future
use. This commit extends the check to take also the last
4 bits into accound.
See also: 3GPP TS 04.08, Table 9.9
Change-Id: I5eb88c42a91e158d9bfa4105ec9636035baf8959
Log error when handover RACH is detected on wrong channel: according to
3GPP TS 44.018 it can only be seen on SACCH and DCCH.
Change-Id: Iacbcc8441d6cfbb8f808948a8baddde1ebca488a
Related: OS#1898
The VTY commands show phy 0 rf-port-stats and show phy 0 clk-sync-stats
do not output their results on the VTY console. If one of those commands
is entered the user is prompted to view the logtext, which is an
uncomfortable solution. This commit adds the missing functionality to
print the information in the VTY as well.
octphy_hw_api.c contains two value_string structs (radio_std_vals and
clocksync_state_vals) which are now exported in octphy_hw_api.h in
order to access them from octphy_vty.c
Change-Id: Iae5aa91fe2ebba7c2874eed88b15ed66e8c9cd61
This bug was introduced during moving oml definitions from osmo-bts to libosmocore
in libosmocore 0bee65c0d89f81a4b90aa3d484016d9ba680dd46 and
osmo-bts 2cf6b73a42:
The type of abis_nm_att_tlvdef_ipa was changed from struct tlv_definition to
const struct tlv_definition, so:
* create static abis_nm_att_tlvdef_ipa_local variable for oml attribute
definitions
* copy abis_nm_att_tlvdef_ipa to abis_nm_att_tlvdef_ipa_local
* merge abis_nm_att_tlvdef with abis_nm_att_tlvdef_ipa_local
* use abis_nm_att_tlvdef_ipa_local in oml_tlv_parse function
Change-Id: Ia9f3c94ab247adeecb26a01c3ccd6f3a8c17ba1c
This issue occurs in case of osmo-trx restart which leads to losing clock from osmo-trx.
Function bts_shutdown from common/bts.c should be used in this case for proper bts shutdown.
Change-Id: Ie65cf2e8f98cb8bf3314a00048aa53c1f8cd4c25
The simplistic approach of sysmobts_get_nominal_power() is insufficient
to cope for devices that have an internal PA. The Actual transceiver
board is driven to a certain level (0..23 dBm typically), and the
external PA must be handled independent of that. Increasing the return
value of sysmobts_get_nominal_power() would result in the sysmoBTS
mainboard attempting to reach a higher power, which is wrong.
This change affects sysmoBTS 1020 and 1100. It causes power-ramping to
be used by default. For 1002 and 2050, no behavior change is expected.
Change-Id: Ieff75d5becaa80a2097b6e744c75c2d16259c9a4
This issue occurs in case of osmo-nitb restart which leads to abis connection closure.
Function bts_shutdown from common/bts.c should be used in this case for proper bts shutdown.
Change-Id: Id025e703dd5c91896d450d200e88e46552f178f0
According to Table 4 in 3GPP TS 45.003 j=11, b=3 case corresponds to
k=91 and not j=12 as was previously used.
Change-Id: Iad3cf545b2f7e16276466cc37dd7a1e7858467e5
pinst->u.osmotrx.hdl should be allocated before reading phy_instance parameters from config file and applying them.
So allocation of pinst->u.osmotrx.hdl should be moved from l1if_open function to bts_model_phy_instance_set_defaults function,
which is proper place for this allocation according to start-up procedure of osmo-bts.
Change-Id: I6e23f92644400acb268818c9373a8fb10c003da1
Move rxgain and tx-attenuation (power) parameters from phy_link layer to phy_inst layer.
Rxgain and tx-attenuation parameters should be set for each phy_inst and send for each osmo-trx channel accordingly via control commands.
Change-Id: I4861a59d10d1ef91954e0c6ea265e66dec08844f
It's useful to know RTP statistics (number of packets lost, jitter, etc)
when looking at voice call quality issues. Right now this information is
not avialable anywhere and this looks like the best place to start.
Change-Id: Ife9f27c43157b4a1bf71aba41cd7b0f5f41ac99f
The vty write for phy/inst is broken, leading to a written-out config being
unparsable; fix all of these:
- in common/vty.c, actually call bts_model_config_write_phy_inst().
- in sysmo and lc15 write the phy instance elements in
bts_model_config_write_phy_inst() and not in bts_model_config_write_phy(),
which lead to writing the members above their parent 'instance'.
- sysmo, lc15 and oct omit the bts_model_config_write_phy_inst()
implementation. This did not cause a compilation problem because it
was in fact never called.
- sysmo writes 'clock-source None' when clk_src is zero, leading to unparsable
config (related: OS#1944). Instead omit the 'clock-source' when zero.
- osmo-bts-trx seems to be the only part that lacks nothing, yet it
also didn't work properly because bts_model_config_write_phy_inst()
was never called.
This problem existed since commit d784e50747
"Introduce new phy_link and phy_instance abstraction"
Change-Id: Icc54fa70045c8fa58e78cf9f788c21a437edfbd4
In case our SI enums ever move past 31, this static assert will warn us to
enlarge osmo_si_shifted.
Change-Id: I4185d7de590329ff5f523b241721c586ffdbcd8b
In copy_sacch_si_to_lchan(), the variable to hold the bit mask for SI-is-valid
was chosen as uint8_t, and as a result none of the SIs with an enum value >= 8
would ever be sent. Use int for enum value and uint32_t for the bit mask.
Fixes: #1945
Change-Id: I85fa9a50691601bcd103845c6811caa061a39824
Upon rx of a SACCH INFO Modify for an lchan that has no L3 INFO IE, clear only
the si.valid bit in question, instead of clearing all but the one in question.
BTW, It first looked like it could be, but is *not* the cause for OS#1945
(SI5ter never sent to MS).
Change-Id: I0df20b6643b0bfd219ce1df594075838d8406719
This tests the computations of the tx_power.c code using sysmoBTS 1002,
1020, 1100 and 2050 values, as well as the power ramping code.
Change-Id: I1cc88d4c6edff326e2e67d4f869aa02c9b2b1ac5
It seems more user friendly to look at a calibration table in terms of
the delta (positive or negative) compared to the nominal gain value,
rather than a collection of absolute gain values. It has the added
benefit that the (API/data model) user doesn't have to specify a gain
value for each ARFCN, but rather can rely on the default nominal gain in
absence of a calibration table for this specific unit.
Change-Id: I7311815902a88d2fc9d211cf4c62fa6fdc5e86ad
This reverts commit 1965b0d880, which was
a premature change. The 10dB gain are not the power of the TRX board,
but are due to an internal, factory mounted PA, i.e. the
trx_power_params.pa. This will be introduced after adding a set of
tx_power.c unit tests.
Change-Id: I524b63c51fb0fe1f90ced28486a8e712f2dc50ae
Based on GSM 04.08 3.4.13 RR connection release procedure, after the network
sends a deactivate SACCH it receives DISC from MS which cause BTS to
send RLL release indication to BSC in order to stop T3109 timer. It has been
found that after a location update BSC never receives RLL release indication
which causes a T3109 timeout because no TCH is currently allocated. This fix
ensures RLL release indication to be sent to BSC when no TCH is allocated
in the particular case of a location update.
Change-Id: Ibe2a365641eb8c9a7f0a462b7393ec3fd28cc366
The sysmoBTS 1020 is a 2W BTS, hence its nominal transmit powre is
33dBm. We must handle this correctly based on the model-nr in the
EEPROM. As a result, proper power ramping will be made during start of
the unit by default.
Change-Id: I91a78dadfd7d2e1bc74c8086808c55effdcdd132
Improve state handling for for lock/unlock of OC_RADIO_CARRIER obj class. in
bts_model_chg_adm_state()
Change-Id: I034114beca95210169429d8ac1eb8648df12fc6c
Fix SID_FIRST_INH detection during speech and when SID_FIRST is interrupted by FACCH.
Fix SID_UPDATE_INH detection during silence and when SID_UPDATE is interrupted by FACCH.
Add a delay for SID_FIRST to appear at the right time after FACCH.
Fix extra byte sent in downlink for SID_FIRST and SID_UPDATE.
Change-Id: Ia811305e15541f2376005df736bd610e8b0d2f69
In some cases, when successive mobile originated calls are made, the LAPDm UA
message gets lost because the channel is relased to early. Too overcome the
problem we do not send relase indications immediately. Instead a flag will be
set and the message stored and sent on the next TCH-RTS-IND.
This commit adds the functionality to store the release indication msg, to
rsl.c. It also addes the mechanism to forward the release indication to l1sap.c
See also coresponding change in openbsc.git:
Change-Id I15fc1ef8e9e83f009bde96de9a8e95702cffbce6
This patch is is a slightly improved/reformatted version of:
95d1f15ad1
Change-Id: Ie4f70c75f0137b4bd72d579b3a32575bac2fca38
Fix error during FACCH interruption of DTX for AMR HR.
Max's note: added fix for sysmobts.
Change-Id: Ib064952331b4f89676ee68a3d8078b1d9debe570
Related: OS#1801
Fix invalid configuration generated by VTY 'write' command for the 'phy'
section of osmo-bts-octphy.
The problem was introduced during refactoring
commit d784e50747 (Sat Jan 9 13:13:37
2016 +0100, "Introduce new phy_link and phy_instance abstraction")
Change-Id: Ib018e07e332aa8a6144fb2d87889032bd5fc2533
* make oml_tx_failure_event_rep() static and use osmo_signal_dispatch()
wrapped into oml_fail_rep() to trigger event reports outside of oml.c
instead of directly calling into OML layer
* remove unnecessary formatting from text messages
Related: OS#1615
Change-Id: I738555c547926e97b325ab53763c0076c42309bc
There should be no other OpenBSC headers included and nobody is using
bsc_controlif_setup. Remove the include. This was introduced in
4723a19508.
Change-Id: I581f938e8fe9161b1d7076cedd74ff192cea86b2
Use --with-openbsc= to pick up gsm_data_shared.h coming from the
openbsc-dev package. With the revert of the change
Iec6b0f0eb0b7fffaa814c9769c0ee777d641a07f, packaging could work
now.
Change-Id: Ie0a005315454a6450205ce6fd76242b85405de8d
As the Osmocom project is providing packages and we build them
directly from git we should have native packages. openbsc-dev
should provide files in the same directory structure as the git
repository and then --with-openbsc=/usr/src/osmocom/openbsc/openbsc/include/openbsc
can be used. Follow up patches are coming.
This reverts commit 70b71507c2.
Change-Id: I8bc3a5c2b9446d9e94e362ed5d85a61e3a727f8b
Use gsm_data-shared.* from absolute path where it's installed by
openbsc-dev package instead of relative path to fix OBS package
building.
Change-Id: Iec6b0f0eb0b7fffaa814c9769c0ee777d641a07f
Related: OS#1860
This bug was introduced in the recently merged
commit 1e399f888e
aka change-id I87f40f5f160a4f6750c4f3d06997fc4f24049303
Fixes: coverity-scan CID#160156 and CID#160155
Change-Id: I88ed1b3e59213acdf97f88eda097b8172b952a5e
The counting of the expired rach slots in l1sap.c is not correctly
implemented. This commit fixes the implementation. The expired
rach slots are now conted correctly according to the configured
channel combination. If a CCCH and SDCCH are combined, only the
frames related to rach slots are counted.
Change-Id: I87f40f5f160a4f6750c4f3d06997fc4f24049303
Currently the IP address where the control interface is bound
to is hardcoded to 127.0.0.1. This leads to problems with
multiple instances on one and the same machine. This commit
integrates the ctrl interface bind option into the VTY, so
that we can bind the ctrl interface to any IP address, just
like we do it with the VTY already.
Change-Id: If51e0c645c0789a4f4a8c51737fb81fb12f80829
oml_ipa_set_attr() is using gsm_objclass2mo() to determine the
*mo object. However, it is possible that gsm_objclass2mo() returns a
null-pointer. The code following up is using *mo without checking.
Reject instead of dereferencing a NULL *mo.
Fixes: coverity scan CID#159533
Change-Id: Ia2cc9bc504c46ca3843c43d712cd8649bfae9526
The public functions in rsl.c do not check for null pointers,
add assertions to catch null pointers early.
Change-Id: I63f127ce70a4127180f90238f564b63e355216ec
rsl_rx_paging_cmd() checks if the pointer *trx is NULL, this check
does not make much sense since *trx has already been dereferenced
without checking earlier in the code. Furthermore *trx is also a
mandatory parameter which must not be NULL.
Fixes: coverity scan CID#159534
Change-Id: I17dfb42ff404b2a1e18354fb7a7278089b407a79
With libosmocore commits I9c3bc15662949654e7bba6aad5488c69ee7d0c45 and
Ieaaaed19da9c069fe451faa53d24c5b84d7d5615 functions to copy and merge
parsed TLV were added as well as abis_nm_att_tlvdef_ipa TLV definition
with related enums. Hence we can remove it from here.
Change-Id: Ia4980062ea88ffe9019b201f84e92e006ae3c2e3
Add debian/copyright in Debian format which should have been added in
c2ecca6b04.
Change-Id: I4c7ef1286ba6d2f3c6aadc8ea1864be513f8cf1d
Related: OS#1694
Fix pchan value used for uplink measurement decisions for dynamic channels in
TCH mode.
Fixes this error log message flooding the osmo-bts log when a dyn ts is serving
a voice call:
<0004> ../../../src/common/measurement.c:104 (bts=0,trx=0,ts=3,ss=0) no space for uplink measurement
Change-Id: Id19316701fd8de6f295eeae0272eea0c315ab1b7
* Unlike in AMR FR, in AMR HR incoming ONSET have to be treated
differently depending on whether we've recently sent SID UPDATE or
EMPTY frame. Split ST_SID_U FSM state into 2 states to accommodate for
that and make sure that additional states specific to AMR HR are not
used for AMR FR.
* Avoid sending E_VOICE and E_SID_U in corresponding states
as those do not initiate FSM state transitions anyway. This decrease
extra load from FSM signalling which otherwise would be triggered on
per-frame basis.
* Introduce separate signal for SID First P1 -> P2 transition to avoid
confusion with E_COMPL and E_SID_U initiated transitions from P1
state.
* Don't init DTX FSM for SDCCH channels.
Change-Id: I229ba39a38a223fada4881fc9aca35d3639371f8
Related: OS#1801
debian/control:
* restructure to make it easier to incorporate further changes
* update package descriptions
* update project URL
debian/rules:
* use proper hardening syntax
* restructure to make it easier to incorporate further changes
* remove useless comment
* add cleanup and test overrides
debian/compat: update compatibility version
Change-Id: Ibf62448eee1df914d21834f5b54831e3f642b79c
Related: OS#1694
* add vty option to manually enable adaptive RTP jitter
buffering (disabled by default) on per-bts level
* use this setting on per-lchan level when setting jitter parameters via
vty at runtime
* check and log result of osmo_rtp_socket_set_param()
* note: older libosmo-abis will ignore this setting which will be
properly detected via return value
* if jitter buffer is disabled by configuring "rtp jitter-buffer 0" than
adaptive buffering is disabled as well but it will be used if jitter
buffer is set to different value for a givel lchan via vty
Change-Id: I489f3c419039f40b57c2ef0641c176478b8d3566
Previously timestamp was always adjusted according to FN difference. In
case of ONSET event this causes unnecessary TS gap with subsequent
speech packet. Fix this by checking Marker bit before performing
adjustment.
Change-Id: I9bf4b45aa990dd4014334dd846f43f793366056c
Related: OS#1801
Use chan_nr for deactivating lchan instead of lchan->nr: chan_nr is the
RSL Channel Number IE value, a bitfield aggregation of lchan type
bits (cbits) and lchan number (lowest three bits). The error was
introduced in 36153239bf.
Change-Id: I6dd7060422ab9d18743c1ff2ab419e3e7299d74d
Having RTP metadata is useful for debugging - save Sequence Number and
Timestamp next to Marker bit from RTP header.
Change-Id: I359b3bcb74fbfc071547fe2f9d837829374fe997
Check explicitly if DTX is enabled for AMR before checking if SID frame
repetition is optional.
Change-Id: I660688d56505798cade1495c30338fd6806a3259
Related: OS#1801
Previously if multiply phy instances were configured but not used
osmo-bts-trx would segfault. Terminate with clear error message instead
so user can correct configuration. Example configuration which caused
problem:
...
phy 0
instance 0
instance 1
...
trx 0
phy 0 instance 0
Note the 2nd instance of phy 0 which is not used in trx later on.
Change-Id: Id979506731ea92401458f1060e87aeb690901539
Do not assume that 1 == BS_AG_BLKS_RES but take that information from
SI3. Note: due to current implementation quirks we activate channels
before SI3 obtained, than we deactivate channels upon receiving SI3 and
activate them again. This might not be necessary once we migrate to
proper OML state machines.
This affects lc15 and sysmo hw.
Change-Id: I11377b12680ac3b2f77f80e742b6f0af63fc9c1e
Related: OS#1575
Typically, our VTY prompts have space after the '#', but some of the osmo-bts
VTY prompts don't:
OsmoBTS# configure terminal
OsmoBTS(config)# bts 0
OsmoBTS(bts)#gsmtap-sapi ccch
Add spaces after the '#' to yield e.g.
OsmoBTS(bts)# gsmtap-sapi ccch
Change-Id: If0591a359e77f01abb76c4113181af7a7733ddd4
Remove lchan deactivation related code duplication to facilitate future
use for dynamic CCCH re-activation.
Change-Id: Id0d3b19dbfaa16d1734321a07a6eb0355bfd77c9
Add explicit state for recursion (sending the different payload data in
response to the RTS request for same FN) and corresponding
transition. Remove ST_FACCH_V as with new explicit recursion handling it
becomes unreacheable. This makes it easier to maintain
preemption (interruption of current procedure due to FACCH or
Inhibition). This also reduces the number of possible transitions out of
each state thus reducing graph's cyclomatic complexity.
Change-Id: If39b68083d23a4a35f468a5d75f54eb733ebfd14
Originally `maxdly` command in osmo-trx was contrlling max TA for Normal Bursts.
This was not a proper behaviour, because it was used to "control maximum
distance a handset can attach from" which is controlled by Access Bursts max TA.
Osmo-trx was corrected to apply `maxdly` to Access Bursts and a new command was
introduced to contrl max TA for Normal Bursts - `maxdlynb`. This patch adds
support for this configuration command into osmo-bts-trx.
If you wonder why would you need that - some test equipment (namely R&S CMD57)
has really bad timing sync and can generate signal a few symbols off. That
prevents osmo-trx from properly receiving otherwise perfectly good bursts
generated by CMD57. This configuration is a solution for this.
Change-Id: Ib5d255299668ac1ef9f0ce95e016f55ba3c82277
The header file octphy/octvc1/gsm/octvc1_gsm_default.h is not
visible to the configure script when the octphy header files
are referenced via --with-octsdr-2g instead having them
installed in /usr/local/include. This results in a failed
AC_CHECK_MEMBER check for tOCTVC1_GSM_TRX_CONFIG.usCentreArfcn,
even if header files with multi-trx support are used.
The configure.ac script manipulates the CPPFLAGS in order to
make the octphy include files visible to AC_CHECK_ and restores
the original CPPFLAGS when done. This is required when
--with-octsdr-2g is used. AC_CHECK_MEMBER is executed
before the CPPFLAGS are manipulated. This causes no issues
if the headers are properly installed to /usr/local/include,
but does not work when --with-octsdr-2g is used.
This commit moves the AC_CHECK_MEMBER command into the section
where the manipulated CPPFLAGS are valid in order to fix the
problem described above
See also commit: f5494e84e8
Change-Id: I7bdfa4449cd6061c395cce315b372c2833520e37
I noticed that the README is prominently shown on github, so it makes sense
to get rid of the worst typos and misinformation there.
Change-Id: I60defef6224a78bb84d7d0b57bc8da17ad7877bb
This is the easiest way I found to make BTS level loopback to work.
Another way to implement this is to have BSC/NITB to send the OML command, but
it's a longer path with no clear benefits.
Note, that the current code hardcodes the channel to be TCH/F with v1 speech,
which is what we need for the basic BER testing. We may want to extend this
later to support more channel types.
Change-Id: Ia2734afeff023e5b3d6b934c7e8b1ed95a071b72
By default l1sap_tch_ind() returns 0 which signals to its caller that message
has been processed and can be freed. In case of loopback we're forwarding
the message to dl_tch_queue who will free it later. Returning 1 from
l1sap_tch_ind() prevents caller from freeing message.
Change-Id: I1e065075baa51c88fa717f132e1f0a83df68be02
Having duplicated code to fill in fn & tn values makes it harder to read
and modify static gsmtap_p* functions. Fix this by removing the
duplication and moving the common code one level up.
Change-Id: I0e67bf7423424cc11435bc0a5a1110297eeee383
Call vty_init() before handle_options() to make sure the host.app_info is
populated before --version potentially tries to print it.
Change-Id: Ic87b5498b57b2f0f876171a15e769b74c28348c1
Introduce dtx_dl_amr_enabled() function which checks that DTX is enabled
and FSM is allocated and use it for all corresponding checks.
Change-Id: Ifa68b641265ed14f242765c85e40da2d1021a541
Previously, if ONSET happened exactly at the place where next SID FIRST
or UPDATE should be it was incorrectly detected as error. Similarly,
continuos FACCH was misinterpreted as error.
Change-Id: I43fdbceea0dbdb0833c3b1cf0fc3b825803ed30e
The parameters related to support 11bit RACH are initialized in
osmo-trx. These parameter determaine the type of the RACH received
in osmo-pcu.
Change-Id: I164d449303373d0757719d5204f4716975fb517a
* re-introduce ST_ONSET_F to guard from repetitive ONSET messages in case
multiple FACCH occur duriing DTX silence period.
* produce ONSET event after both SID FIRST and UPDATE in case of AMR FR.
* always dispatch E_SID_F (SID FIRST) signal if in talkspurt.
* allow E_SID_* right after ONSET (zero-length talkspurt).
* add missing E_ONSET signal description.
* fix FSM transitions for AMR HR *Inhibited and First P*.
* fix incorrect return from l1if_tch_encode() in ONSET FACCH with
incoming SID UPDATE
Change-Id: I0e9033c5f169da46aed9a0d1295faff489778dcf
Related: OS#1801
superfemto.sh: Expand log converter to use case-insensitive matching to
accommodate for spelling differences in DSP logs. Add strings/events
specific to AMR HR.
dtx_check.gawk: Remove redundand variables from output. Add checks
specific to AMR HR.
Change-Id: Icce3178605f46bbf3cad15d4eaff18a4d164ad1a
It was moved to OpenBSC in 582e4f627674f46310a90d9061e82fb342051b42 as
it's used by both projects.
Change-Id: I8aba987e3cdaa840cf3e14913a8455b0ba759889
Handle ONSET cause by Voice and FACCH separately. In case of Voice we
have RTP payload which we have to cache and send later on in next
response to L1 RTS. FACCH have higher priority so it preempts both voice
and silence alike - hence we can send ONSET immediately but still have
to track previous state in order to get back to it gracefully.
This affects lc15 and sysmo hw as there's no FSM-based DTX
implementation for other models yet.
Note: this requires patch for OpenBSC which adds FACCH buffer to tch.dtx
struct.
Change-Id: Idba14dcd0cb12cd7aee86391fcc152c49fcd7052
Related: OS#1802
Based on the indication from L1, number of bits in RACH and burst
type is determined. Appropriate parameters are filled in
osmo-bts-litecell15. These parameters are sent to osmo-pcu for
processing of the RACH.
Change-Id: Ie5207a15424fb287febf74e830297531232accde
* superfemto.sh can parse superfemto-compatible DSP log output to
properly sort records into MT/MO and DL/UL parts
* dtx_check.gawk can process output of superfemto.sh and check for
common scheduling errors
This allows to check lc15 and sysmo for errors in DTX DL scheduling. As
dtx_check.gawk is generic it can be used with any other BTS hw (or
virtual BTS) as long as raw logs from this hw can be converted to simple
input format 'FN EVENT' per-line.
Change-Id: Ib1c70c4543b24c2a05a7df8eec5ce3f4eda2c02e
Related: OS#1801
Previously SID UPDATE was sometimes scheduled incorrectly. Fix this by:
* avoid rounding error when computing scheduling time difference from FN
* properly saving and updating cached SID type and FN
Change-Id: I7acffae4792e7bddc2ae19a2f04ee921dc194c36
Related: OS#1801
Use ARRAY_SIZE macro for each pointer separately.
Fix suggested by Neels Hofmeyr <nhofmeyr@sysmocom.de>.
Change-Id: I68ec1be33fb743977121d654187d85d6b8451e2b
Fixes: Coverity CID 150132
SDCCH occupy lchan 0..3 in combined configuration so for CCCH we've
always used lchan[4] - replace it with CCCH_LCHAN define and add
comment.
Change-Id: Ic5d742c292d638f119c6b4672120c1950adeb7f0
Use dedicated FSM to handle all DTX DL related events:
- add explicit checks if DTX DL is enabled (fixes regression for non-DTX
setup introduced in 654175f33b)
- fix handling of AMR CMI for SPEECH frames
- add FSM for DTX DL
- sync with corresponding changes in OpenBSC's
- handle FACCH-related DTX ONSET events
This affects both lc15 and sysmobts and requires corresponding change in
OpenBSC (Change-Id: Idac8609faf9b5ced818fde899ccfc6ed0c42e8fd).
Change-Id: I74a0b42cb34d525b8a70d264135e82994ca70d31
in its current statue l1_oml.c does not check if the version
number in the header files (octvc1_main_version.h) matches up
the version that is reported from the DSP during startip. This
patch ads a check to make sure that the currently loaded
firmware and the headers used during compile time match. If
a mismatch is detected, osmo-bts exits immediately.
Change-Id: Icba5756517d632d53b129c5ce1a1dab4936dab91
Previously FN was converted to millisecondss incorrectly due to wrong
conversion between FN and a number of voice samples. The conversion
should be based on following:
* there are 12/13 useful frames for audio in TCH
* there is 1 RTP packet per 4 frame
* there are 160 samples per RTP packet
Fixes: OS#1801
Change-Id: I9cc70cacabde98621aa892cee74f4ac461645093
Use "impossible" dummy value to initialize last_fn to prevent dropping
of 1st RTP frame due to timestamp jump.
Fixes: OS#1803
Change-Id: I485af21f6761048d12dc7f5552fcdd46daf786ed
The constant cOCTVC1_HW_CLOCK_SYNC_MGR_STATE_ENUM_UNUSED in header
file octvc1/hw/octvc1_hw_api.h has been renamed to
cOCTVC1_HW_CLOCK_SYNC_MGR_STATE_ENUM_IDLE. This commit adds an ifdef
decision in to code to ensure that older header files will still work.
Change-Id: I4c0b976d29689ace06741c5943434fc33ee2df14
The multi-trx had to be removed because of build conflicts
with octphy header that lack the struct members for needed
to support multi-trx.
For details see the following revert-commits:
ed6b48e4a5c9a1f284ac
This commit reintroduces multi trx support and ads an ifdef
decision to ensure that header files without multi-trx
support still work.
Change-Id: I7f9b2906cc149c817183745b4c96bcc7f9ebdad0
Explicitly set AC_CONFIG_AUX_DIR.
To reproduce the error avoided by this patch:
rm install-sh # in case it was already generated.
touch ../install-sh # yes, outside this source tree
autoreconf -fi
This will produce an error like
...
configure.ac:16: error: required file '../ltmain.sh' not found
configure.ac:5: installing '../missing'
src/Makefile.am: installing '../depcomp'
autoreconf: automake failed with exit status: 1
See also automake (vim `which automake`) and look for 'sub locate_aux_dir'.
Change-Id: I02153ad52faf1465e9f7821378e04118f17352d2
When ONSET event happens (either via Marker bit or due to unmarked
talkspurt) we should first send Onset event to L1 and than send voice
data in response to the same PH-RTS.ind.
Change-Id: I2a7b89430ca49eee4a350c5f980bd6bcbc386347
Move code from tch.c (lc15, sysmo) into generic function which:
- check if talkspurt is happening
- cache SID if necessary or invalidate cache
- fill in CMR & CMI prefix
This also fixes the problem when SID FIRST was cached without sending
just like SID UPDATE instead of being sent right away.
Change-Id: I6c7016a54749abadeef4fd4f5b6f750b256fb916
* consolidate AMR CMR and CMI handling in common/amr.c
* use it in save_last_sid()
* remove dead code
* properly compute RTP payload length for AMR
* use save_last_sid() for FR & HR as well
* invalidate cached SID if SPEECH frame is received
Fixes: OS #1800, #1801
Change-Id: I5a1c1ad0b0a295a50e67775a4db85f1d331755ed
Note: this also require changes to properly link against libosmocodec -
see 2bb65be159dfdabf664fec569b343320301701b0 in libosmocore.
Change-Id: I96594cf3aa1013d505bd20069d5bf261d9a2aefb
If Marker bit is set than it's a talkspurt which we have to explicitly
indicate to L1 by first sending ONSET message and than actual voice
data in a separate message.
This change affect sysmobts and LC15 hw.
Change-Id: I88c41568bcb0d82699f617adc4ad192603dd1bb6
Related: OS#1750
There is now an exception for ARFCN 0 in osmocom_to_octphy_band to
distingush ARFCN 0 (E-GSM) and 1-124 (P-GSM).
Change-Id: If012f31121e9d0d45b36459807c5f290aa17374f
in l1_oml.c:ts_connect() the payload type (ulPayloadType) was not
configured to full-rate for PDTCHF PACCHF and PTCCHF. Older octasic
firmwares (below octsdr-2g-02.06.00-B964-alpha) will tolerate this,
newer versions will crash during channel initalitation.
Change-Id: Id2f6a439ceb063b10efc7b9d1d70bb5b29a01033
Some phone seems to not send SID_FIRST_P2 message which seems like a
different understanding of the DTX spec. L1 accommodates for that by
using P1 to supply data for SID. Hence we should use it to initiate DTX
and ignore P2 message in case of AMR HR.
Change-Id: Iaf993b89caa0ad49b97d1c745dcaf039f867f018
Previously receiving SID via RTP always caused it's transmission to L1
regardless of the time which might have resulted in excess traffic. Fix
this by only saving SID data and transmitting it later on as necessary
according to 3GPP TS 26.093 A.5.1.1.
Change-Id: Ifcdc5c60d0238b704a94f6778d4e00f2b087b090
Fixes: OS#1801
Previously SID retransmission was scheduled incorrectly based on GSM
frames instead of voice frames. Fix this by using GSM Fn only as elapsed
time estimation:
* move saved SID retransmission into generic function from lc15 and sysmo
specific code
* split retransmission time check into separate generic function
* compute estimation for elapsed time since last retransmission using
GSM Fn
Change-Id: Ib054b458a7345d9ba40dba53754ca59ab099c8e8
Fixes: OS#1799
Previously SID was saved explicitly by each BTS model (lc15, sysmo)
instead of relying on generic function. Fix it by using generic function
and propagating necessary parameters for it.
Change-Id: Ie545212cce5ed2b3ea3228597f18a473f5e1deb4
Fixes: OS#1800
Like most other osmo-* programs, bind the telnet VTY to the address specified
by the 'line vty'/'bind' command. This is added by vty_init(), so until now the
BTS offered this config but ignored it.
Change-Id: Ic4ab32aee08d8a779adeb9943892de0c828c7b3d
Add log_name to lchan_lookup() and pass such from the various RSL rx events
that call it to validate the RSL chan_nr.
Change-Id: I0d9923f47ac655b204169eec302d607412d5754d
The osmo-bts log used to say this a lot:
DL1C <0006> oml.c:758 (bts=0,trx=0,ts=0,ss=1) End of queue encountered. Now empty? 1
- Move this to DEBUG level instead of NOTICE.
- Tweak wording and logic so it says one of:
[...] End of SAPI cmd queue encountered. Queue is now empty.
[...] End of SAPI cmd queue encountered. More pending.
Change-Id: I5a46c90d016cee9b50f32db2af568765d3cb74cc
Based on the indication from L1, number of bits in RACH and burst
type is determined. Appropriate parameters are filled in osmo-bts-sysmo
These parameters are sent to osmo-pcu for processing of the RACH.
Change-Id: I93831ddfb3f31b637e6a576f23a9bb4557758582
Before this patch, Osmocom style TCH/F_TCH/H_PDCH dyn TS were paralyzed if no
PCU was running. The state of the dyn TS would lock up in the PDCH activation
phase since the PCU never completed the process.
Make more robust, i.e. don't concern the BSC with PDCH activation failures.
This matches the way plain PDCH TS work: besides declaring the TS as PDCH, the
BSC is not involved and is not told about errors.
During PDCH deactivation, still wait for the PCU to tear down the PDTCH SAPIs,
but in case no PCU is connected, send a rel ack right away.
Thus, the BSC will happily switch Osmocom style dynamic timeslots to and from
PDCH mode, using the dyn TS as voice channels as needed, and not caring about
possible PDCH failures. GPRS starts working right away as soon as a PCU
connects, regardless of dyn TS having been used for voice any number of times,
and without another switchover needed.
In detail:
In rsl_rx_chan_activ(), upon receiving a PDCH activation, send an RSL chan act
ack right away, unconditionally (with an explaining comment). Do not concern
the Abis link with PDCH activation failures.
Since we're acking right away now, drop the chan act ack that would follow
after the PCU activation: as before dyn TS, only send acks and nacks for
rel_act_kind == LCHAN_REL_ACT_RSL (PDCH runs as LCHAN_REL_ACT_PCU).
In dyn_ts_pdch_release, indicate that the PCU is not connected by means of
returning 1. In rsl_rx_rf_chan_rel(), use this indicator to send a rel ack
right away if the PCU is not connected.
Change-Id: I2a0b9730197786b99ff3bc1f08c75f7d279cb1f7
There was an apparent change of name from
cOCTVC1_HW_CLOCK_SYNC_MGR_STATE_ENUM_IDLE
to
cOCTVC1_HW_CLOCK_SYNC_MGR_STATE_ENUM_UNUSED
in:
git://git.osmocom.org/octphy-2g-headers
commit 953a258aadf18c05e8128a339f15b1c5bb377cfd
"Import headers from OCTSDR-OPENBSC-02.07.00-B708.tgz"
In order to build octphy with these headers, apply the same rename in
osmo-bts-octphy/*.
Change-Id: Ic07055860035a7c1b83ab923817423eeb39f33d3
This reverts commit c4fc00d851, except: we keep
the part that sets the trx_id in bts_model_phy_instance_set_defaults().
Theoretically, this patch makes a lot of sense, but in order to be able to
build osmo-bts-octphy until the headers version is clarified, revert use of
usCentreArfcn:
Above commit uses an usCentreArfcn member that is never defined in the history
of our octphy-2g-headers.git. This usCentreArfcn does exist in a code snapshot
OCTSDR-2G-02.05.00-B780-DEBUG, which is not (yet?) publicly available.
Also, the current headers version is apparently 02.07, though the octasic
version numbers have been known to cause confusion among osmocom folks.
This along with one other revert fixes this build problem:
make[3]: Entering directory '/n/s/octphy/git/osmo-bts/src/osmo-bts-octphy'
CC l1_oml.o
l1_oml.c: In function ‘l1if_trx_open’:
l1_oml.c:1350:13: error: ‘tOCTVC1_GSM_TRX_CONFIG’ has no member named ‘usCentreArfcn’
oc->Config.usCentreArfcn = plink->u.octphy.center_arfcn;
^
l1_oml.c:1352:13: error: ‘tOCTVC1_GSM_TRX_CONFIG’ has no member named ‘usCentreArfcn’
oc->Config.usCentreArfcn = trx->arfcn;
^
In file included from ../../include/osmo-bts/logging.h:5:0,
from l1_oml.c:33:
l1_oml.c:1365:13: error: ‘tOCTVC1_GSM_TRX_CONFIG’ has no member named ‘usCentreArfcn’
oc->Config.usCentreArfcn, oc->Config.usTsc, oc->RfConfig.ulRxGainDb,
^
Change-Id: Ic643709e8fb3df2d66337190ed1f07fd230d7dca
This reverts commit 06968beab9.
Theoretically, this patch makes a lot of sense, but in order to be able to
build osmo-bts-octphy until the headers version is clarified, revert use of
usCentreArfcn:
Above commit uses an usCentreArfcn member that is never defined in the history
of our octphy-2g-headers.git. This usCentreArfcn does exist in a code snapshot
OCTSDR-2G-02.05.00-B780-DEBUG, which is not (yet?) publicly available.
Also, the current headers version is apparently 02.07, though the octasic
version numbers have been known to cause confusion among osmocom folks.
This along with one other revert fixes this build problem:
make[3]: Entering directory '/n/s/octphy/git/osmo-bts/src/osmo-bts-octphy'
CC l1_oml.o
l1_oml.c: In function ‘l1if_trx_open’:
l1_oml.c:1350:13: error: ‘tOCTVC1_GSM_TRX_CONFIG’ has no member named ‘usCentreArfcn’
oc->Config.usCentreArfcn = plink->u.octphy.center_arfcn;
^
l1_oml.c:1352:13: error: ‘tOCTVC1_GSM_TRX_CONFIG’ has no member named ‘usCentreArfcn’
oc->Config.usCentreArfcn = trx->arfcn;
^
In file included from ../../include/osmo-bts/logging.h:5:0,
from l1_oml.c:33:
l1_oml.c:1365:13: error: ‘tOCTVC1_GSM_TRX_CONFIG’ has no member named ‘usCentreArfcn’
oc->Config.usCentreArfcn, oc->Config.usTsc, oc->RfConfig.ulRxGainDb,
^
Change-Id: I222766f6961f5f35aa3651e2907e3e908fe9a66e
Prepare for a dyn TS patch that needs to call rsl_tx_chan_act_ack() directly
without the rel_act_kind decision.
Add function rsl_tx_chan_act_acknack() to wrap rsl_tx_chan_act_ack() and
rsl_tx_chan_act_nack(). Move the decision whether to drop the ack/nack, based
on lchan->rel_act_kind, to the new function, losing some code dup.
Change all callers to use the new function; drop the two older ones from rsl.h
and make them static.
Note: for nack, the exception for dyn TS in PDCH mode was missing
(rsl_tx_chan_act_nack() had only the rel_act_kind != LCHAN_REL_ACT_RSL
condition, but should also have had the dyn TS exception as in
rsl_tx_chan_act_ack()). I already know that this exception will again be
removed in an upcoming commit, but for patch readability it logically makes
sense to add it here. To easily include the nack case, drop the check for which
pchan the dyn TS is operating as, because a rel_act_kind == LCHAN_REL_ACT_PCU
implies that it is either already in or trying to become PDCH mode.
Change-Id: I57ba60c670730c6d7877a6a9b96ece0a7679a0bb
Commit "sysmo,lc15: ts_connect_as(): log error also for pchan_as == TCH/F_PDCH"
introduced a check for TCH/F_PDCH intended only for TCH/F_TCH/H_PDCH. It looked
correct, but TCH/F_PDCH startup was designed differently:
For TCH/F_PDCH, the idea was to look it up in pchan_to_logChComb[] and obtain
the TCH/F channel combination, so that TCH/F_PDCH first initialize as TCH/F.
So pchan was in fact intended to be passed as TCH/F_PDCH.
For Osmocom TCH/F_TCH/H_PDCH, we've in the meantime added a ts_opstart()
function that makes this decision explicitly. So, instead of reverting the
erratic commit, add TCH/F_PDCH to ts_opstart(), for both sysmo and lc15.
In ts_opstart(), move to a switch statement to resolve the actual pchan to use
for ts_connect_as().
Drop TCH/F_PDCH and TCH/F_TCH/H_PDCH from pchan_to_logChComb[] and comment.
Change-Id: I376b92a06f4cbe943c1c913dea7487fac53a7d08
Though this patch theoretically makes a lot of sense, it is not entirely clear
why dyn TS are working without it. Committing due to common sense, not to fix
any actual breakage.
Change-Id: I6136cb42a4d627ebefc963eb5321fadfe63cca4b
Have one common ts_is_pdch(), placed in lchan.c, since this file is pretty
empty and pretty close to ts. Publish in gsm_data.h.
Remove the if-style implementation from l1sap.c, and instead implement in a
switch statement.
This prepares for upcoming ts_is_pdch() usage in ph_data_req() for sysmo and
lc15.
Change-Id: Ib78d663fdbac5a1d7053f1b9d543649b66da00e2
In measurement.c, fix the number of sublots for TCH/F_TCH/H_PDCH, by using
ts_subslots() from gsm_data_shared.c. The local dup of subslots_per_pchan[] is
no longer needed. (depends on recent commit to openbsc.git for ts_sublots())
Change-Id: I9d9df470c49487bffd56dde42c7bec0da2f50642
Interface structure between osmo-bts and osmo-pcu is updated with the
parameters to differentiate the type of RACH and further support 11 bit
RACH. The function prototype and definitions are changed accordingly.
Interface version number is increased.
Change-Id: I4f4c501b2d86d77c78de32a84b1804172ffb6f4d
This reverts commit 53d792c3b0.
See http://osmocom.org/issues/1796
The commit caused this error for PDCH TS with SysmoBTS:
DL1P <0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
DL1C <0006> oml.c:811 Error activating L1 SAPI PTCCH on TS 7: Invalid parameter
DL1C <0006> oml.c:1089 (bts=0,trx=0,ts=7,ss=0) act failed mark broken due status: -4
Plain PDCH TS show this error but continue to function despite the SAPI
activation failure.
As a side effect, the SAPI activation failure breaks dynamic TS. GPRS
initially works, but the broken status prevents transitions to TCH/* modes
in the BSC:
DRLL <0000> chan_alloc.c:355 Failed to allocate TCH_H channel
DRSL <0004> abis_rsl.c:1656 BTS 0 CHAN RQD: no resources for TCH_H 0x45
Since the commit only enabled PTCCH UL in sysmobts, no other BTS models are
affected. Notice that lc15 still has PTCCH UL disabled all the while, before
and after this commit and its revert.
Also note that PTCCH DL is and has been enabled without problems (see
further above in sapi_dir_pdtch_sapis[]). This is only about PTCCH UL.
Related: OS#1796
Change-Id: Ia59d95c75a8a5d3bd596f55cd1dc0906a6a95f7f
Apply similar fixes as for TCH/F_PDCH also for TCH/F_TCH/H_PDCH:
Detect dyn TS in PDCH mode in ts_is_pdch().
In trx_set_ts(), enhance the "if (TCH_F_PDCH)" to a switch statement including
both dynamic channel types. Adjust the comment to include both kinds.
Change-Id: I6669739cd08780cd9ffb9451cdae9f6b9704c4fe
It is not an exceptional situation if the air-interface is experiencing
non-recoverable decoding errors. At bad signal conditions and/or
interference, this is perfectly normal. Let's use DEBUG instead of
NOTICE log level.
Change-Id: Ifd39c53ec22f57cdb5299e5d76ff6ff1482d3beb
As the ARFCN numbers in DCS (1800) and PCS (1900) are not unique,
we need to specify the band in the upper bits of the ARFCN value before
calling gsm_arfcn2freq10().
Change-Id: I637b76bc1fc749eed8e364412d76606589991c02
Fill in values for BER, BTO, Link quality in L1SAP and send them to
PCU. Note: this increases the version of BTS <-> PCU protocol. It also
requires corresponding changes in libosmocore.
All BTS models provide measurements data unless direct DSP access for
PCU is enabled. For BTS-specific notes see below.
Octphy: conversion from sSNRDb to Link Quality uses formulae which works
in practice instead of what's documented for sSNRDb value. Subject to
change in future revisions.
TRX: C / I link quality estimator is not computed.
Change-Id: Ic9693a044756fb1c7bd2ff3cfa0db042c3c4e01c
Related: OS#1616
spatch on Debian 8.0 has already crashed twice and is likely to
crash more and at the same time the value for this static checking
is close to zero (nice idea but never blossomed). So let's remove
it, have a more reliable build and let's coverity find those issues.
Change-Id: Ic1004edf7f0bee8dda30b95554a0aaf0b116b6b8
Allow output of encoded bit count or error count on BER calculation
without requiring both pointers to exist.
Change-Id: I2c78fa6a92a3b3da4aad8f70353e5a43451b0aa5
Fixes: Coverity CID 137963
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
bts_model_ts_disconnect() has nothing to do.
bts_model_ts_connect() merely sets the new pchan on the ts.
Change-Id: Ieb66935d6efc26854e95d238e810c4f8b16cfa88
To be able to set a specific pchan type for dynamic channels, have the
trx_set_ts_as_pchan() function with an explicit pchan argument instead of
using ts->pchan.
Keep trx_set_ts() as a thin wrapper to use ts->pchan directly.
Change-Id: I9eeef05d2a6763f86a5b89ee7c3b4211f6736e4d
In l1sap_ph_rts_ind(), l1sap_ph_data_ind() and to_gsmtap(), the decision
to handle a TS as PDCH was still missing for dynamic TS.
It is not yet clear why this did not impact functionality for dynamic timeslots
on other BTS models. AFAICT they should not work without this patch, but in
fact they do. It would be nice to clarify this some day.
Change-Id: I7b873a089a3de70d980885a7539cb91997464743
Due to missing runtime cmd patching DSP tracing was not possible at phy
level of config file. No it is possible to specify it as follows:
...
phy 0
instance 0
dsp-trace-flag debug
dsp-trace-flag mph_cnf
...
Change-Id: Ibbbf81d2c4b5d3adbcbc1f08a844d262e603e571
Since the osmo_unixsock_listen() was moved to libosmocore
it would be better to use the library's implementation
instead of reinventing the wheel again.
Change-Id: Id5828649d44ef11e70946793696b0d689d6b35e3
Existing interfaces are coded with the implicit expectation of using
a burst sequence length of 148, which is constant with GSM and GPRS.
That changes with EGPRS, where the burst length may be 444 due to
the use of 8-PSK instead of GMSK modulation.
Setup the interface to accept and return a length value with the
burst sequence. This allows 444 length bit vectors to/from the
EGPRS decoder/encoder. Length is explicitly used as a identifier for
8-PSK vs. GMSK modulated sequences.
Change-Id: I90b46b46b11b6ce280e7f8232d5a2fccec2d4f18
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
Handles uplink decoding and downlink encoding procedures for MCS 1-9.
Includes Type 1, 2, and 3 headers and tables from 3GPP TS 44.060 in
order to independently recover coding and puncturing scheme (CPS)
parameters for each coded message.
Change-Id: I0f059ae34c6f36179553cbc972f8becf8179eb55
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
Addition of GSM_PCHAN_TCH_F_TCH_H_PDCH should have added these assertions.
They clarify that only 'real' pchan types are expected in this function.
Change-Id: Ifd4b6820861ef716237e7eeed149b2add9e7d485
For chan_nr_by_sapi(), add GSM_PCHAN_TCH_F_TCH_H_PDCH to pick_pchan().
Add GSM_PCHAN_TCH_F_TCH_H_PDCH to pchan_to_logChComb[] for first pchan
initialization.
In ts_connect_as(), make sure that callers pass proper "real world" pchan
types, i.e. reject the "meta" GSM_PCHAN_TCH_F_TCH_H_PDCH pchan constant.
In ts_opstart(), connect as PCHAN_NONE since we will only know the desired
pchan when the first RSL chan activ is received.
Add GSM_PCHAN_TCH_F_TCH_H_PDCH to lchan_to_GsmL1_SubCh_t(), by using its
current "real" pchan mode.
Call cb_ts_[dis]connected() unconditionally, i.e. not only for TCH_F_PDCH when
a pending flag is set. The cb_ts_[dis]connected() will be a no-op if the pchan
type is not dynamic.
Change-Id: Ie30323f968da25027045c42a7ae7f1e70ca711ae
ts_connect() is only called during OPSTART. Name it such because a special
case for OPSTART will be added there for dyn TS.
Change-Id: Iba6880d94142096a8371b08f7404035912cadbb0
For chan_nr_by_sapi(), add GSM_PCHAN_TCH_F_TCH_H_PDCH to pick_pchan().
Add GSM_PCHAN_TCH_F_TCH_H_PDCH to pchan_to_logChComb[] for first pchan
initialization.
In ts_connect_as(), make sure that callers pass proper "real world" pchan
types, i.e. reject the "meta" GSM_PCHAN_TCH_F_TCH_H_PDCH pchan constant.
In ts_opstart(), connect as PCHAN_NONE since we will only know the desired
pchan when the first RSL chan activ is received.
Add GSM_PCHAN_TCH_F_TCH_H_PDCH to lchan_to_GsmL1_SubCh_t(), by using its
current "real" pchan mode.
Call cb_ts_[dis]connected() unconditionally, i.e. not only for TCH_F_PDCH when
a pending flag is set. The cb_ts_[dis]connected() will be a no-op if the pchan
type is not dynamic.
Change-Id: Iaffd2fc0aa9fc6c4a2acbc534ce6384392e0635b
ts_connect() is only called during OPSTART. Name it such because a special
case for OPSTART will be added there for dyn TS.
Change-Id: I09cc81e79661e8084aeebf8132435c207b2cf422
common/l1sap: For dyn TS, the BSC will issue RSL Chan Activ requests with a
non-standard chan_nr. While the rest of the code now understands that, the L1
phy will not. Translate to standard PDCH (== TCH/F).
common/oml: use dyn TS' current pchan mode for lchans config.
common/pcu_sock: detect desired PDCH mode of dyn TS.
common/rsl: implement reconnection chain of a TS for changing its pchan:
* rsl_rx_chan_activ():
** Add dyn_pchan_from_chan_nr() to derive the requested pchan from the RSL
chan_nr IE.
** Notice the need for a pchan change and invoke dyn_ts_l1_reconnect() (s.b.)
** Make Chan Mode IE presence optional, because the non-standard PDCH
activation message is simpler and does not require it.
** Do PDCH activation via PCU.
* Add dyn_ts_l1_reconnect(): store state and disconnect the L1 channel;
then wait for cb_ts_disconnected().
* Add osmo_dyn_ts_disconnected() to cb_ts_disconnected():
verify state and connect with the new pchan type; then wait for
cb_ts_connected().
* Add osmo_dyn_ts_connected() to cb_ts_connected(), which re-issues
the cached chan activation message from before disconnecting the L1 channel.
* Also send an rf chan rel/act ack for dyn TS upon PDCH de/act via PCU.
* Add dyn_ts_pdch_release(): on channel release of a dyn TS in PDCH mode,
release via the PCU. Call from rsl_rx_rd_chan_rel().
Change-Id: I463bb6b4e57674f091c3badba9257374961c52c7
lchan_lookup in openbsc abis_rsl.c and rsl_lchan_lookup() rsl.c are the
same code, except for the log context, which is only set in abis_rsl.c.
The common code was factored out to gsm_data_shared.c in openbsc.git.
Use the *rc return code argument to keep the logging part in the newly
introduced thin wrapper lchan_lookup() in common/rsl.c. This also removes code
dup for logging
The rsl_lchan_lookup() implementation is removed from osmo-bts, so a recent
openbsc is needed to build this.
Change-Id: Ibc469b75e31560271be8633d524366442d27e6fb
Includes EGPRS specific convolutional codes, interleaving tables
and functions, burst mappings, training sequences, and parity
checks from 3GPP TS 44.060 needed to handle MCS codings 1-9.
Change-Id: Ie270398dd7a72f282ba53e646853d8de1eabee93
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
Move the actual switch from static conf_lchans_for_pchan() into new 'public'
function conf_lchans_as_pchan(), adding an explicit pchan argument. This allows
passing a non-trivial pchan, for dynamic TS.
conf_lchans_as_pchan() now takes a pchan argument, so distinguish the naming
and drop the 'for_pchan' from conf_lchans_for_pchan(), which takes only a ts
argument.
Change-Id: I8e458501fff5503c243512aeb3469c12b1f2bbc4
We're about to introduce a new kind of dynamic channel, which will also use
parts of the ip.access mode dyn PDCH code paths. Make sure the general parts
have general names and mark ip.access specific parts as such.
Rename dyn_pdch_ts_[dis]connected() to cb_ts_[dis]connected().
Rename dyn_pdch_complete to ipacc_dyn_pdch_complete().
From cb_ts_[dis]connected(), factor out the current code into static
functions ipacc_dyn_pdch_[dis]connected() -- this will make sense once the
new dynamic kind is added to cb_ts_[dis]connected().
Change-Id: I7da5b7cb7b48572671f50e0dec97d9eec3083df1
Also remove related cruft: .gitignore, msc-README and adjust an in-code
comment that referenced dyn_pdch.msc.
Change-Id: Ie41a453bb5070c1f18793f646dc053a978f43fba
When receiving an OPSTART for the BTS object, also set the availability state
to OK.
Before, the availability would remain at NM_AVSTATE_DEPENDENCY, which caused an
unfortunate chain reaction resulting in osmo-bts-trx going through the
initialization sequence twice:
BTS BSC
|<-----| SITE_MANAGER OPSTART
n |----->| BTS state change: OPSTATE_DISABLED, AVSTATE_DEPENDENCY
o | | This signals to nm_statechg_event() in bts_ipaccess_nanobts.c
r | | to (a) Set BTS Attributes and (b) send BTS OPSTART
m |<-----| Set BTS Attributes (a)
a | | When osmo-bts-trx receives a Set BTS Attributes, it sends
l |----->| CHANNEL state change: OPSTATE_DISABLED x8
| | This signals the BSC to Set CHANNEL Attributes and OPSTART
i |<-----| Set CHANNEL Attributes x8
n |<-----| CHANNEL OPSTART x8
i |----->| CHANNEL state change: OPSTATE_ENABLED, AVSTATE_OK x8
t | |
|<-----| BTS OPSTART (b)
| | osmo-bts-trx immediately replies with:
|----->| BTS state change: OPSTATE_ENABLED, AVSTATE_DEPENDENCY
| | Unfortunately, availability is left at DEPENDENCY,
| | and the NM_OC_BTS case in nm_statechg_event() only
| | checks for availability, not for the opstate.
| | Hence nm_statechg_event() again feels inclined to
| | to (a) Set BTS Attributes and (b) send BTS OPSTART,
| |
--+------+----- This is where the second round starts
| |
s |<-----| Set BTS Attributes (a)
e | | When osmo-bts-trx receives a Set BTS Attributes, it sends
c |----->| CHANNEL state change: OPSTATE_DISABLED x8
o | | All channels are disabled again, and then re-launched:
n |<-----| Set CHANNEL Attributes x8
d |<-----| CHANNEL OPSTART x8
|----->| CHANNEL state change: OPSTATE_ENABLED, AVSTATE_OK x8
| |
i |<-----| BTS OPSTART (b)
n | | osmo-bts-trx again sets the OPSTATE_ENABLED, but since
i | | this time it was already enabled, no further state change
t | | is sent back to the BSC.
This nightmare pivots on two hinges:
1. osmo-bts-trx fails to set BTS availability to AVSTATE_OK.
2. nm_statechg_event() fails to heed the OPSTATE_ENABLED of the BTS state
change.
Note, the configured channels from the first round were not actually taken
down, only the OML OPSTATE_DISABLED were sent.
In this commit, fix the osmo-bts-trx side: send AVSTATE_OK for the BTS object
upon sending OPSTATE_ENABLED, so that only the part marked "normal init" above
is run.
This change applies the same fix to other OML objects, which should make sense
in the same manner, within the current hackish OML implementation:
* NM_OC_BTS
* NM_OC_SITE_MANAGER
* NM_OC_BASEB_TRANSC
* NM_OC_GPRS_NSE
* NM_OC_GPRS_CELL
* NM_OC_GPRS_NSVC
This means that the NM_OC_CHANNEL case just above is identical, and thus
collapse NM_OC_CHANNEL onto the other cases. Drop the comments from
NM_OC_CHANNEL since they merely rephrase the commands themselves.
See OS#1770 for BTS and NITB logs.
Fixes: OS#1770
Change-Id: I08aa861f6100568c79750f4fbc9a32e1557b9304
Many erratic bursts are expected. To not bloat the log, notifications for this
should be on debug level.
See http://lists.osmocom.org/pipermail/openbsc/2016-July/009482.html
(Tue, 5 Jul 2016 15:38:27 -0700 / Tom Tsou <tom@tsou.cc>
/ Re: osmo-bts-trx error logs -- was: GPRS on osmo-trx not working)
Change-Id: If591c087ba8fd48564139e32930050ee8ab07001
Correct the too short padding I introduced in the commit
a55b166c6c. The result needs to
be 121 and not 120. Add static asserts to make sure it does
not happen again.
Change-Id: I3da7f3b8d3c8e12deb8b805cd15ff52a103d4e56
Back in January in commit 634c3e4648 we
changed the executable name from 'sysmobts' to 'osmo-bts-sysmo', which
is a change that has not been propagated to the contributed screenrc and
systemd init files.
Change-Id: I875a0ce4f470226e1b06ed1b7c74ca9471ebb574
* detect SID and set RTP Marker accordingly (emulate ONSET events)
* set proper FN in TCH_IND
* detect speech pause and do not send dummy 'bad' frames during that
time
Change-Id: Id518e5c667df7773c281effb9e75b66bf898f6fc
Related: OS#1750
Abstract code for checking/setting lchan's UL SID flag and RTP Marker
into generic function and use it for LC15 and sysmoBTS.
Change-Id: Ica5392e92bab29164711163e7b01adb174272883
Related: OS#1750
The cfg_trx_nominal_power_cmd added 12 days ago in
58e4e18206 was floating.
Actually add it to the TRX_NODE.
Change-Id: I89d638b2e2bb1fb9baeabe566035ff171f4bfad0
The function would currently only be called in cases where one of the if
branches catches on, but for safety's and clarity's sake, don't ts_connect
using as_pchan if no reconnect is pending.
Change-Id: I52c34065254e902bb80662fc04540901b36cb4c3
Analogous to 63b296bdd9 on osmo-bts-sysmo.
Implement bts_model_ts_disconnect() by sending an MphDisconnect message to L1.
Pass a disconnect callback to invoke dyn_pdch_ts_disconnected() in
common/rsl.c.
Implement bts_model_ts_connect() by calling ts_connect_as(). Pass a connect cb
to invoke dyn_pdch_connected() in common/rsl.c.
Change-Id: I8c8c3244c726fd6055cedb22ee11706994ff9cd4
Analogous to 294fbe104b on osmo-bts-sysmo.
For upcoming dyn PDCH switching, I want to be able to set the pchan dynamically
upon ts_connect() and not continue with OPSTART ACK, but with the dyn PDCH.
Thus recoin ts_connect(ts) to ts_connect_as(ts, pchan, cb) and leave
ts_connect() as a thin wrapper to leave init code unchanged.
Change-Id: I7a27193168f83e8c40b6e54d1842f4502d0475e5
Analogous to 0d10f0e482 on osmo-bts-sysmo.
According to the PDCH Active flag, handle a TS as TCH/F or PDCH.
Change-Id: I0c97b360136f76bdae8d70d06af9a31fdf75c1ba
Analogous to 7158c2ed08 in osmo-bts-sysmo.
Place a layer 3 handle into GSM L1 messages to better match up confirmations to
respective requests. This handle is a uint32_t transparently returned in the
confirmation messages, so a match-up is easy to add.
So far, a GSM L1 confirmation message received for a preceding L1 Request was
matched only by the prim_id. That meant that only one instance of the same
primitive could be waiting for a confirmation at any given time, or the
responses would get mixed up: the struct wait_l1_conf instances entered into
the fl1h->wlc_list queue would be returned to a possibly mismatching
confirmation handler. (Seen during testing of dyn pdch switching.)
Send the hLayer3 handle out via prim_init(), using new static functions to
produce handles on different scopes:
* l1p_handle_for_trx()
* l1p_handle_for_ts()
* l1p_handle_for_lchan()
(These could possibly move to a more general .h/.c file later.)
Remember the hLayer3 handle in
* struct wait_l1_conf.
Match the incoming confirmations' and stored hLayer3 handles up in, and remove
a now obsolete comment from:
* is_prim_compat()
Since the hLayer3 members are at different byte offsets in
GsmL1_Prim_t.u.*, use large switch statements to set/get the value:
* In prim_init(), extend existing switch statement to set in GsmL1_Prim_t.
* Add l1p_get_hLayer3() to retrieve from GsmL1_Prim_t (could possibly move to a
more general .h/.c file later).
Note that some messages are already using the hLayer3 handle, and will
overwrite it after calling prim_init(), so those are not affected.
Change-Id: I17f95ba744c3e944a2241809106506f8dd1b24f0
When switching to the gsm_chan_t_names string list from libosmogsm,
libosmogsm actually became a dependency of the local libbts.a.
The breaking change is in openbsc.git 29048b2a80b5865ffc41fa4401113c5826227e23
and came in here because gsm_data_shared.h is included from openbsc.
Change-Id: I70e5735fc2a212305182d46a7e8485d0199ade7b
Switch to using libosmocodec functions as a preparation step for DTX
support as they expose necessary bits.
Change-Id: Ie7423032fd06779d78876182ee63538d98906328
Related: OS#1750
Implement bts_model_ts_disconnect() by sending an MphDisconnect message to L1.
Pass a disconnect callback to invoke dyn_pdch_ts_disconnected() in
common/rsl.c.
Implement bts_model_ts_connect() by calling ts_connect_as(). Pass a connect cb
to invoke dyn_pdch_connected() in common/rsl.c.
Change-Id: I61709fdf6b093689a6d3a046f67db6d02f1296ae
For upcoming dyn PDCH switching, I want to be able to set the pchan dynamically
upon ts_connect() and not continue with OPSTART ACK, but with the dyn PDCH.
Thus recoin ts_connect(ts) to ts_connect_as(ts, pchan, cb) and leave
ts_connect() as a thin wrapper to leave init code unchanged.
Change-Id: I09cc794cb424e17411e608c65f2b68e2f2544e07
React on IPAC PDCH ACT and DEACT messages and invoke the PCU and bts_model_ts_*
APIs to effect switchover. The dyn PDCH interaction is described in the comment
to rsl_rx_dyn_pdch(), the main entry point for PDCH switchover.
In case the bts_model_ts_* are not implemented (or return other errors),
reply with an IPAC PDCH ACT/DEACT NACK.
Add callbacks that mark steps in the PDCH switchover process,
dyn_pdch_ts_disconnected(), dyn_pdch_ts_connected() and dyn_pdch_complete().
Add hooks in l1sap.c on channel activation and release confirmation, to call
dyn PDCH callbacks.
BTS dyn PDCH implementations should invoke dyn_pdch_ts_disconnected() and
dyn_pdch_ts_connected() when bts_model_ts_disconnect() or
bts_model_ts_connect() are called, respectively. (upcoming for sysmoBTS)
Change-Id: Id2f5f77121a65d6c14eac127b3d4fb50e97a77ab
Introduce a static function to encapsulate the decision whether a TS is
used for PDCH. Depending on the ts->flags, handle a TCH/F_PDCH TS exactly like
a standard PDCH TS.
Change-Id: Ic72fd06ecc99609823efa3edcf773007cc514b5b
Enhance bts_model_ API in preparation of dyn PDCH switching. These will be used
to re-connect a TCH/F_PDCH TS in a different mode: either as TCH/F or as PDCH.
All implementations so far return -ENOTSUP, and thus will cause a IPAC PDCH ACT
or DEACT *NACK* to be sent to the BSC as soon as these messages are handled.
Also add stubs in tests.
Change-Id: I21e60c028a1333431c3ed000f788b654d1170b0d
It is cosmetic since the 'default:' case already caught TCH_F_PDCH, but it's
good to mention all expected pchans explicitly.
Change-Id: I5aef84209e46c9288f6adf0730178fe08f26764f
Before, only standard ABIS RSL message names were logged, add ip.access
specific ones.
The IPAC_PDCH_ACT and _DEACT msgs are received with an ABIS_RSL_MDISC_DED_CHAN
discriminator, and not with _MDISC_IPACCESS like the others. Thus rsl_rx_dchan()
should be able to log ip.access message types properly.
Change-Id: I9db6826b515bf565fc7ae24fc0760b60928cc89f
Add vty command (under "phy X instance Y" hierarchy) to manually send
POWERON or POWEROFF command. It's useful for debugging issues related to
BTS/TRX initialization.
Change-Id: I6dfebaf118cdf5ad144516b2b839b17350a73ce4
Related: OS#1648
Previously software activation could have been reported multiple times
which broke proper BTS init. Introduce guard variable to ensure
reporting happens only once.
Note: this is just minimal workaround - ideally proper OML state machine
should be implemented.
Change-Id: Ifffbdb756bc5d2864f985c01a3299b839c4de7af
Related: OS#1648
- Change system devices path
- Remove obsoleted sensors and add new sensors
- Change TRX and sensors numbering to 0,1 instead of 1,2 (JFD)
Change-Id: I5172daf68d3145a6398e37df87df21b0e5affe42
Place a layer 3 handle into GSM L1 messages to better match up confirmations to
respective requests. This handle is a uint32_t transparently returned in the
confirmation messages, so a match-up is easy to add.
So far, a GSM L1 confirmation message received for a preceding L1 Request was
matched only by the prim_id. That meant that only one instance of the same
primitive could be waiting for a confirmation at any given time, or the
responses would get mixed up: the struct wait_l1_conf instances entered into
the fl1h->wlc_list queue would be returned to a possibly mismatching
confirmation handler. (Seen during testing of dyn pdch switching.)
Send the hLayer3 handle out via prim_init(), using new static functions to
produce handles on different scopes:
* l1p_handle_for_trx()
* l1p_handle_for_ts()
* l1p_handle_for_lchan()
(These could possibly move to a more general .h/.c file later.)
Remember the hLayer3 handle in
* struct wait_l1_conf.
Match the incoming confirmations' and stored hLayer3 handles up in, and remove
a now obsolete comment from:
* is_prim_compat()
Since the hLayer3 members are at different byte offsets in
GsmL1_Prim_t.u.*, use large switch statements to set/get the value:
* In prim_init(), extend existing switch statement to set in GsmL1_Prim_t.
* Add l1p_get_hLayer3() to retrieve from GsmL1_Prim_t (could possibly move to a
more general .h/.c file later).
Change-Id: Ie4533c6cbc160318917e7a672ab6f9a848f01d1b
We are using up to 48 (actually only 8) bytes to manage the boot
state of the device. Add it to the eeprom reservation. It turns out
the current padding was too large (37 + 84 don't end at 120).
Change-Id: I4c1de5925577f1d0b7b5cc08529642ffa333d7de
We have seen that the DSP time to time rejects PTCCH message from BTS due to invalid block number.
As a result, we patched FN2PTCCHBLOCK calculation according TS 45.0002 Table 6.
Change-Id: I8be1c8b9159c94788857c6de5440a418739f1212
Store last SID received over RTP and repeat is if necessary (no new SID
or SPEECH frames) according to codec-specific scheduling rules.
Related: OS#1563
Copy-paster from I4d23846a27d3dbd2a6e75e481c1efcdb2a85f305 for LC15.
Change-Id: I29acea6e8bbf426330ce52554a48afb5d2ef1679
Store last SID received over RTP and repeat is if necessary (no new SID
or SPEECH frames) according to codec-specific scheduling rules.
Change-Id: I4d23846a27d3dbd2a6e75e481c1efcdb2a85f305
Related: OS#1563
Previously frame number was not saved in case of PRIM_TCH rendering many
debug statements with g_time useless.
Copy-paste from ef30f50d5d.
Change-Id: I952b39458d921622d5964cbdcc2f4e45ff9ea951
This fixes the unstable behavior (BTS loosing subscribers after some
time) in case previous run of osmo-bts was interrupted (with ctrl+c for
example).
Change-Id: Ie2119b0b566d01f0e70b38c8a149fecb47def38d
Use libosmocodec function to parse RTP with AMR payload in sysmoBTS and
LC15. This replaces "manual" parsing of AMR frame with function covered
by test suite and makes adding DTXd support easier.
Related: OS#1563
Change-Id: I1464f9a12e3f92926d03d5dd5d18e8f0f7206dd9
Reviewed-on: https://gerrit.osmocom.org/204
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
* set/clear DTXd activity indicator for measurement reporting
* set DTXd status based on information from RSL
Related: OS#1563
Change-Id: I148a75725c4e5089b6f2da6e9adcbe94170d3257
Depends-On: I4a033b03fcd0deb4db7a38273b5407511dbf1d6c
Reviewed-on: https://gerrit.osmocom.org/220
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Compute RTP user_ts adjustment based on the difference between current
and previous FN instead of hard-coded value.
Change-Id: If1677ddcf754b29990ff7cd846e11c32e3d30b33
Related: OS#1562
Reviewed-on: https://gerrit.osmocom.org/196
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Previously frame number was not saved in case of PRIM_TCH rendering many
debug statements with g_time useless.
Change-Id: Ib8d8c919862d0de8e2ebf7753c2592e0d91b09c5
Reviewed-on: https://gerrit.osmocom.org/195
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
There is implicit invariant in trx_phy_instance() which is actively used
by various hw-specific implementations to get TRX's phy instance. Let's
make sure there's explicit assertion for this because there's been
segfaults in the past related to it.
There are several types of System Information messages with tricky
scheduling rules described in 3GPP TS 05.02 § 6.3.1.3. This GNU Awk
script takes in .csv file with sequence of scheduled SI messages (for
example generated using tshark from GSMTAP capture - see usage note
inside the script) and check the scheduling rules compliance.
I had accidently bumped the version as I thought that osmo_ph_pres_info_type
was part of the ABI. It is not an only internal to the BTS. Revert
this part of the change.
Previously osmo-bts-octphy have not provided in-band presence
information which cause off-by-one errors and misinterpretation of
ph_data_ind by PCU. This fixed now by adding support for explicitly
passing PH-DATA presence info. Corresponding check and in-band passing
of presence information are removed.
Note: this requires libosmocore version with osmo_ph_pres_info_type
support integrated.
[hfreyther/max: Remove + 1 from the decoded length]
In some cases we'd like to run multiple instances of osmo-bts on a
single machine. This is the case where we a multi-TRX PHY is to be used
for several BTSs, or in case osmo-bts-trx has multple SDRs attached.
This wa currently prevented by having a hard-coded PCU socket path
and telnet port, which are now configurable via VTY / config file
itself.
It remains up to the individual BTS hardware models to decide
whether or not to register those commands (depending on whether they
support the feature) via cfg_bts_auto_band_cmd / cfg_bts_no_auto_band_cmd
At the time the phy link / phy instance level VTY configuration
commands are parsed, we did not yet call l1if_open() and thus
pinst->u.{lc15,sysmobts}.hdl == NULL.
PHY or PHY instance specific configuration must thus be stored inside
the phy_link or phy_instance itself, and not inside the (not yet
existing) handle.
We solve this by moving around some parameters:
* clk_use_eeprom/clk_cal/clk_src/calib_path get replicated in
phy_instance
* min_qual_{rach,norm} are moved into the generic part (which means
that osmo-bts-octphy and osmo-bts-trx should also implement them)
Due to the changes introduced by the phy_link API, it's not easy to set
the default DSP trace flags via a command line argument anymore. We now
rather introduce a persitent VTY configuration command, by which the
default DSP tracing configuration can be set (for each PHY).
The persistent trace flags are stored in the phy_instance, while the
current operational run-time flags are in fl1h->phy_instance.
This includes changes required for
* shared main() function accross all BTS models
* use of the new phy_link / phy_instance infrastructure as the basis
for true multi-TRX operation
by using a talloc pool, we avoid having to go back to the libc
malloc pool all the time. The msgb allocations and libortp allocations
happen quite frequently during processing and show up as one of the
high priority items in osmo-bts profiles on sysmoBTS with 14 concurrent
TCH/H calls (highest load scenario).
talloc still consumes significant CPU, this is mostly due to the
zero-initialization of all the associated buffers. Strictly speaking
we shouldn't need this, but any change there would require lots of
testing, as there might be hidden assumptions in the code?
In some percentage of cases, talloc still seems to fall back on malloc
for msgb allocations, which is currently a bit of a mystery. The pools
certainly are large enough, talloc_reprt() rarely reports more than a
few tens of kilobytes used by the msgb pool.
From 2ecbf87130
This commit adds basic support for the Litecell 1.5. Multi-TRX is not
supported yet. Instead, multiple instances of the BTS can be launched
using command line parameter -n <HW_TRX_NR> to specify if TRX 1 or
2 must be used by the bts. Note that only TRX 1 opens a connection to
the PCU. Full support for GPRS on both TRX will come at the same time
than the multi-TRX support.
The BTS manager has been adapted to match the new hardware but otherwise
it has not been improved or changed compared to the one used on the
SuperFemto/Litecell (sysmobts).
When the OML signalling link is lost, first set bts->oml_link = NULL,
then iterate over the RSL links and close them. Closing the RSL link
will cause a OML state change message to be sent, which in turn tries
to use the no-longer-existing OML link.
The code should be cleaned up further to distinguish which signalling
link was lost, and actually communicate a RSL(only) loss to OML.
But for now, it's best to simply close down all links and terminate
osmo-bts to ensure all state is properly reset and recovered.
this introduces the new phy_link / phy_instance interface, which is the
basis of clean support for all kinds of multi-trx configurations with
various BTS modules.
WARNING: This breaks configuration file compatibility. You will need to
introduce config nodes for 'phy' and 'instance', as well as the link
from the 'trx' nodes towards the phy instance.
It seems the right thing to do: Once we know a PHY link is established,
the associated OML managed objects should change their state
accordingly. However, given all the hackery we do with MO states, this
actually breaks things, rather than helping. So I'm disabling that part
for now, but this needs to be re-visited at some point.
This splits the TRX scheduler into a generic part and an osmo-bts-trx
specific part. It is the basis for re-using the scheduler from other
bts modules such as the upcoming osmo-bts-virtual.
the backend is performing the actual encoding and decoding functions,
while the generic part constsits of the TDMA structures and generating
the RTS.ind
The L1 scheduler is a generally useful component that is unfortunately
tied quite a bit into the OsmoTRX support. Let's try to separate it out
by having separate per-trx/per-ts/per-chan data structures pre-fixed
with l1sched_
Using this patch it should be one step easier to use the scheduler for
other BTS models, such as the intended upcoming virtual BTS.
During the L1SAP related changes, somehow an old version of
check_for_ciph_cmd() was re-introduced, which didn't store the N(s) as
part of the lchan. To make things worse, the old code was still present
in the sysmobts specific part, but never executed.
When the oml_link is down or not yet established, we currently lost
any OML messages that were scheduled for transmission to the BSC. Let's
prevent that by keeping a queue of OML messages, which is drained at the
time the OML link comes up again.
Use the right identifier for the timeslot and not the trx number
which would always use ts==0 on the first trx. This should fix
ciphering issues for TS>0 (e.g. SDCCH8 on TS==1)
It seems that once we start to respect the T200 values as specified by
the BSC, we run into all kinds of issues with LAPDm re-transmissions,
REJ frames, unexpected supervisory frames and the like.
The libosmogsm LAPDm T200 defaults of 1s/2s are proven to "work" (i.e.
not expose the above behavior), so let's revert to them until the root
cause of this problem is determined.
The T200 default values should be in milli-seconds (as the variable name
indicates). They are not expected to be divided by the TS 12.21 OML
dividers for T200.
This change doesn't really make a difference with OpenBSC, as the BSC
always sets its own T200 values via OML, overwriting the defaults here.
There's no need to use memcpy(), which adds the risk that the types of
source and destination are not the same (see previous commit). Iterating
over the array and assigning each element is more robust.
t200_ms is an unsigned int [7] array, while the oml_default_t200_ms was
an uint8_t[7] array, which we memcpy() to the former as default
initializer. Fix this by turning oml_default_t200_ms into unsigned int,
too.
We re-use the 'wait_l1_conf' structure for implementing the
unacknowledge command window towards the PHY. This means that thre will
unconditionally be a 'wait_l1_conf' now, even for requests where the
caller didn't provide a call-back.
When re-starting OsmoBTS after unclean shutdown, the PHY is already
sending notifications (PH-DATA.ind, PH-TIME.ind, etc.) for the previous
physical channel / timeslot configuration. At the point those messages
are received, OsmoBTS might not even have A-bis OML up yet, and thus has
no clue how to process such messages (and subsequently likely crashes).
Let's block such primitives from passing further up the code until we
have received the TRX-OPEN response.
When writing the config file from the command line, we must not forget
to write the phy-netdev parameter, otherwise the program will fail to
re-start later :/
sysmobts-calib might be easily patched by a user that does not know
that firmware and firmware headers form a contract that should be
matched. Compare the version numbers and print a warning if it does
not look correct. This should be enough for a user to see that something
is not right. Continue anyway as the firmware might still be compatible
(because the ABI has not changed).
Fixes: SYS#1172
If using a too old kernel on newer devices the eeprom reading will
fail and maybe it is not possible to update the kernel after the
unit has been deployed.
Add a utility to read the EEPROM of revD+ from userspace to be used
to fix up the thing.
by using a talloc pool, we avoid having to go back to the libc
malloc pool all the time. The msgb allocations and libortp allocations
happen quite frequently during processing and show up as one of the
high priority items in osmo-bts profiles on sysmoBTS with 14 concurrent
TCH/H calls (highest load scenario).
talloc still consumes significant CPU, this is mostly due to the
zero-initialization of all the associated buffers. Strictly speaking
we shouldn't need this, but any change there would require lots of
testing, as there might be hidden assumptions in the code?
In some percentage of cases, talloc still seems to fall back on malloc
for msgb allocations, which is currently a bit of a mystery. The pools
certainly are large enough, talloc_reprt() rarely reports more than a
few tens of kilobytes used by the msgb pool.
In some situations, a PHY might send us a primitive for a logical
channel that is not (or no longer) active. Passing such primitives
higher up the stack is asking for trouble. Specifically, LAPDm
instances cannot accept messages once their instance has been released.
We introduce two new helper functions: get_lchan_by_chan_nr() as well as
get_active_lchan_by_chan_nr(). The former just centralizes the look-up
of the lchan by timeslot number and sub-slot number. The latter also
checks to ensure the lchan is active, which is used for PH-DATA / PH-RTS
primitives. To the contrary, MPH primitives generally don't require the
cahnnel to be active for processing.
The way we recycle the msgb with a l1sap header when transforming a
PH-DATA.req L1SAP primitive into a PHY/L1 primitive was flawed in
several ways:
1) the way the L1SAP header was stored in the buffer didn't provide
sufficient tailroom for the L1 primitive
2) the alignment of the data in L1SAP is at a 32bit bounadry, but not
in the L1 primitive, causing unaligned accesses.
OpenBSC introduced a naming change in
615ed46a6ab25f71a7ab0d8201d33b4dbf8fc5b0 but osmo-bts fixes were only
about osmo-bts-sysmo, not osmo-bts-trx. This updates osmo-bts-trx
accordingly.
This reverts commit 94a05abb98.
The tests don't work well with subdir-objects, so we have to live with
the warnings meanwhile until somebody finds time to find the magic spell
to solve the autotools quest.
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
A known issue with this code is that BER is not updated for lost TCH frames,
because osmo-trx doesn't send any indication for them and we don't have
a callback to handle this.
Otherwise the code seem to work fine.
3GPP TS 05.03 "Channel coding" specifies the puncturing matrix (1,0,1)
for class 1 information bits and tail bits valued u(0) to u(103) for a
maximum puncturing index of 311. The puncturing index 313 exceeds the
maximum index and causes osmo_conv_get_output_length() to output the
improper length of 210 instead of 211.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
If frame number is out of range (>= 2715648), the scheduler's process
would end up in an infinite loop. This is because the loop would schedule
bursts until the indicated frame number is reached, which would not be
possible.
The openbts, calypso-bts and osmo-trx might send out out of range clock
indications every 3.5 hour.
RTS (ready-to-send) must be issued in advance, so BTS core and especially
osmo-pcu can provide downlink data frames early enough. In some cases PCU
might provide frames too late, so they must be dropped. If PCU provides
frames too late, due to high system load, this "RTS advance" setting must
be increased.
Instead of limiting the number of TRX at VTY to the actual number of
supported TRX, VTY allows to configure any possible number of TRX. If a
TRX is configured, which is not supported by BTS model, an error message is
returned, which states that the given TRX is not supported.
Handover and assignment may activate channels with ciphering already set,
so we need to tell scheduler to enable/disable ciphering and set the
correct cipher state.
Only if transceiver becomes available, control commands are sent. If
tranceiver is gone, reset scheduler.
The current availability state is sent to BSC via OML state change
commands.
MS uplink power control is required in pretty much any BTS, and we
cannot assume that they PHY / L1 will always take care of it by
itself. So the correspondign code is moved to common/power_control.c
and called from the generic part of L1SAP.
The corresponding VTY paramter has been moved from the sysmobts-specific
trx VTY node to the common BTS VTY node.
There are three transitions:
1. LCHAN_CIPH_NONE -> LCHAN_CIPH_RX_REQ -> LCHAN_CIPH_RX_CONF
It is used to enable ciphering in RX (uplink) direction only.
2. LCHAN_CIPH_RX_CONF -> LCHAN_CIPH_RX_CONF_TX_REQ -> LCHAN_CIPH_RXTX_CONF
It is used to additionally enable ciphering in TX (downlink) direction.
3. LCHAN_CIPH_NONE -> LCHAN_CIPH_RXTX_REQ -> LCHAN_CIPH_RX_CONF_TX_REQ
-> LCHAN_CIPH_RXTX_CONF
It is used to enable ciphering in both TX and RX directions. This is used
when the channel is activated with encryption already enabled. (assignment
or handover)
In order to follow the order of these transitions, the RX direction must
always be set before the TX direction.
If no cipher key is set (A5/0), ciphering is set to ALG 0, but lchan cipher
state remains at LCHAN_CIPH_NONE.
This part moves control channel message primitives from osmo-bts-sysmo to
common part.
In order to control ciphering fo BTS model, CIPHER (MPH_INFO) messages are
used.
The original code handled both the fact where a TIME indication would be
missed (and thus the frame number be higher than previous + 1), as well
as the two cases for combined / non-combined CCCH.
The L1SAP code removed some of those bits, which I'm re-introducing
here.
This is a regression of the code compared to the existing
sysmoBTS code, where the L1 tells us whether its AGCH or
PCH. However, it was not used even in the old code, so
we can afford to simply put a #warning here.
In case of a RACH INDICATION on CCCH, we need to set CHAN_NR to
0x88 (RSL_CHAN_RACH). In other cases, chan_nr needs to reflect
the actual logical channel (TCH/SDCCH) on whcih the handover happened.
... in an effort to avoid introducing new/more spaghetti code
Also, use offsetof() instead of pointer calculation to determine
the start of GsmL1_Prim_t.u.phDataReq.msgUnitParam.u8Buffer
This first part moves BCCH message primitives from osmo-bts-sysmo to common
part. A new file "common/l1sap.c" is introduced to implement handling of
layer 1 messages from/to BTS model.
Spotted by Ciaby while debugging an audio issue. Do not
send anything to port==0 to the BSC/NITB. Look at the
upper bits of the speech_mode to determine if sending is
allowed. 0x1 means recv_only and all other modes allow us
to send.
Manually verified with a single phone call with LCR bridge
mode to send a CRCX early but a MDCX sendrecv later. The
audio starts to flow after the MDCX message. Virtual Addr
space didn't increase over 10 calls. The l1p_msg is freed
by the caller.
The code might not re-set speech_mode from one call to
another but if it is ever != 0 it can be expected that
the BSC will always set it. This is because we do not
(and don't want to) allocate the lchan dynamically on
every usage.
Fixes: SYS#2111
Use the new libosmo-abis API to query the session for the
statistics and then send it as a TLV element to the BSC.
This can be used to do post processing about the call. E.g
to figure out if no audio arrived at all.
The RSL_IE_MEAS_RES_NR is mandatory element with a minimum
of 5 octets (two for TL and three for the value). When we
establish a new channel we might not have had enough time
in a TDMA frame to calculate the average. The issue is not
easy to reproduce. At the point we receive the measurement
report we have two uplink measurements queued. As it is not
easy to reproduce and only occurs when a channel is new
I have decided to drop the message instead of sending made
up uplink measurement reports.
As of now lchan_build_rsl_ul_meas will always return 3 and
the condition will never be false.
Avoids: SYS#1781
The write_queue is designed to have a maximum amount of pending
messages and will refuse to take new messages when it has been
reached. The caller can decide if it wants to flush the queue
and add the message again, create a log. But in all cases the
ownership of the msgb has not been transferred. Fix the potential
memory leak in the failure situation.
Instead of handling primitives directly at layer 1 specific code,
osmo-bts handles primitives at common code.
When all primitive are moved, the l1sap interface will:
- receive PH-DATA indications and forward them to layer 2.
- check for RF link loss and notify BSC.
- receive TCH indications and forward them via RTP.
- receive PH-RTS indications and send PH-DATA requests with content
according to its logical channel.
- receive TCH-RTS indications and send TCH requests with content
received via RTP or loopback from TCH indications.
- send MPH-INFO requests to activate, deactivate and modify logical
channels and handle their confirms.
- receive MPH-INFO indications with measurements from tranceiver.
- forward received and transmitted PH-DATA to GSMTAP.
Use the standard RSL commands to order a logical channel
to use a fixed power level.
The code is not fully verified and there was a last minute
change to invoke bts_model_adjst_ms_pwr.
Currently the DSP is instructed to achieve a given uplink
power target but there are circumstances (e.g. EMV testing)
where we need more control over it. The "manual/software/osmo"
power control can only be implemented per TRX and not per
lchan. Add a very very basic control that checks the MS Power
used by the phone, the actual receive level and then adjust
the power.
The code doesn't take the history into account, if the phone
can not reach the requested power level the code will be stuck
(e.g. no timeout based on multiframes). It has a mode for a
fixed power control but no way to set it yet.
The change of the mode requires a restart of the software.
* Print the GPS FD that was opened (e.g. to see if it was
closed again)
* Print the state changes/expectations
* Print the correct to be applied. I wondered if I shouldo do
a cor = cor * -1.. cor = -cor.. or add CLOCK_CORR(err) macro
to use it inside the printf and correction and decided the
gain is not worth the risk.
Continously run the calibration process. Everytime we call the
reset function classify the outcome. In case of a failure schedule
the next command soon and otherwise wait several hours.
Remember if the process was started through the VTY or the run
loop. In case it can't be started immediately reset and schedule
a new run.
After a reboot the system might have been off for a long time
and the currently used value might be wrong. Remember that we
never ran the calibration and execute it on start.
We should only calibrate the clock if there is a GPS fix. Start
gpsd to determine if there is a fix or not. Work around trimble
decoding issues (sent an email upstream). We need to gain some
more experience to see if there memory leaks. We also need to
re-schedule the calibration depending on the outcome.
Change the sign before passing it as correction value. The error
is the difference between the TCXO and GPS. We need to correct by
the reverse of the error. This seems to be different depending on
the clock source we have.
This is a last minute untested change.
This runs the entire procedure for calibration with reasonable
error and success checking. It can be triggered from the VTY
of the sysmobts-mgr right now.
What is missing is to hook up with GPSD to check if the system
has a fix and provide a mode that will continously run the
calibration command.
The CTRL code should have used/extended the l1_if calibration
code. The sysmobts-mgr code first needs to determine if the
clock adjustment is necessary at all. This is done by first
resetting the counters, then waiting, then asking for the diff
and then applying the correction value. But the reference clock
is only set by the application comand.
Copy more code of l1if_rf_clock_info_reset to set the reference
clock as value. This is leaving some todos inside the code that
will be resolved as part of SYS#835.
Related: SYS#835
In the long run we will connect to GPSD and wait for a fix and
then run the calibration. The first step is to open (and re-open)
the control connection to the BTS.
As the connection is on localhost there should not be a computation
overhead to always have the connection open. When connecting assume
that the ASYNC connect worked directly as otherwise we get no
notification of the failure.
This looks like a "bug" of libosmo-abis that should check if the
socket has been connected or not.
This should handle OML channel combinations with CBCH and activate the
CBCH SAPI towards the DSP correspondingly. What is still missing is
sending any actual information over the CBCH in respons to the
PH-RTS.ind coming up from L1.
2014-12-30 00:28:31 +01:00
352 changed files with 72115 additions and 3710 deletions
# Split common DSP call log file (produced by superfemto-compatible firmware) into 4 separate call leg files (MO/MT & DL/UL) with events in format "FN EVENT_TYPE":
cat $1.raw | cut -f2 -d')'| cut -f1 -d','| cut -f2 -d'>'| sed 's/\[u32Fn/fn/'| sed 's/\[ u32Fn/fn/'| sed 's/fn = /fn=/'| sed 's/fn=//'| sed 's/\[Fn=//'| sed 's/ An Onset will be inserted.//' > $1.tmp1
}
PREP "$1.DL.MT"
PREP "$1.DL.MO"
PREP "$1.UL.MT"
PREP "$1.UL.MO"
RD(){# reformat DL logs for consistency checks
cat $1.tmp1 | sed "$D_FST"| sed "$D_SPE"| sed "$D_FS1"| sed "$D_FS2"| sed "$D_UIN"| sed "$D_FIN"| sed "$D_UPD"| sed "$D_INH"| sed "$D_RP1"| sed "$D_ONS"| sed "$D_EMP"| sed "$D_FAC"| sed "$D_FO1"| sed "$D_FO2"| sed "$D_FP2" > $1.tmp2
}
RU(){# reformat UL logs for consistency checks
cat $1.tmp1 | sed "$U_FST"| sed "$U_SPE"| sed "$U_FP1"| sed "$U_FP2"| sed "$U_UPD"| sed "$U_ONS"| sed "$U_NOD"| sed "$U_UIN"| sed "$U_FIN"| sed "$U_RAT" > $1.tmp2
File diff suppressed because it is too large
Load Diff
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
