There are some situations where it is useful to be able to change the
Radio Link Timeout at runtime, without restarting the BTS.
This adds a new (hidden) command for this:
"bts <0-255> radio-link-timeout (oml|infinite|<4-64>)"
Change-Id: I64674a432cf7751b16d5d0b52f66766fa6e37028
It was a very bad idea to mix "public" BTS features, that are
reported to the BSC via OML, and those features, that are used
locally (and exclusively) in osmo-bts.
Why? At least because we already have the BTS feature manipulation
API in libosmocore, that is used by osmo-bsc, but for some reason
not by osmo-bts. New features added to libosmocore would clash
with the existing "internal" ones like BTS_FEAT_MS_PWR_CTRL_DSP.
So what this change does can be described as follows:
- remove duplicate definition of the "public" features,
- use libosmocore's API for the "public" features,
- separate both "internal" and "public" features:
- the "public" features continue to live in bitvec,
- the "internal" features become flags,
- s/BTS_FEAT/BTS_INTERNAL_FLAG/g.
Change-Id: Icf792d02323bb73e3b8d46384c7890cb1eb4731e
According to 3GPP TS 44.004, section 7.4a, two alternative RACH
block formats are specified: 8 bit (1 octet) and 11 bit. The
bit order is little-endian (right to left).
In L1SAP PH-RACH.ind structure (see ph_rach_ind_param) we use
a field of type uint16_t to store RA values regardles of the
block format. Thus when packing it to bytes, we cannot just
cast uint16_t* to uint8_t*, we need to do some bit shifting.
Change-Id: I0e91d825bb2e1897647dd5403c311d833a89ff2e
In l1sap_ph_data_ind() we can use msgb_pull_l2() which is an exact
implementation of the functionality there.
In l1sap_tch_ind(), the existing code is actually wrong by making the
assumption that the msgb contains exactly an entire osmo_phsap_prim.
Better to also dynamically compute the number of bytes to ensure
we only pull those ahead of the L2 header, no matter what their exact
count.
Change-Id: I13f7f8ba93795e40b1fb4a306fe765e059f642cf
For osmo-bts-sysmo the MPH INFO MEAS IND indication is still sent
separately. Lets merge the measurement information into the PH DATA
Change-Id: Iffe7865727fbf9bca8eb32a96e8ea05cf718a948
Related: OS#2977
This line appears tens of times per second when a call is ongoing,
making it impossible to follow logs on INFO level.
Change-Id: Iadb1baf55df2f6d96f85260f2e8d03627fef7e66
The MPH INFO MEAS IND indication, which contains the uplink measurement
data is sent in parallel to the PH DATA and TCH indications as a
separate indications. This makes the overall uplink measurement data
processing unnecessarly complex. So lets put the data that is relevant
for measurement into the PH DATA and TCH indications directly.
This change only affects osmo-bts-trx at the moment. In order to keep
the upper layers (l1sap.c) compatible we add an autodection to switch
between separate measurement indications and included measurement data.
Related: OS#2977
Depends: libosmocore I2c34b02d329f9df190c5035c396403ca0a4f9c42
Change-Id: I710d0b7cf193afa8515807836ee69b8b7db84a84
Due to relatively small training sequence of Access Bursts, there
can be frequent false-positives (basically noise). Fortunately,
we can distinguish them from the real Access Bursts by checking
the signal measurements attached to them (BER, ToA and C/I).
Let's reduce verbosity of logging messages as they are mostly
useful for debugging and may confuse the users / operators.
Change-Id: I7ab6727ffff00140a7f9e762b299b711481393f1
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
When logging about filtering access bursts, let's indicate if this is
on a CCCH, PDCH or handover related.
Change-Id: I03f21f2b54cbe5aad36ac71a614d5df98867df80
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
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
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
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
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
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
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
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
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
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
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
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
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
Philipp Maier
Harald Welte
Vadim Yanitskiy
Vadim Yanitskiy
Pau Espin
Martin Hauke
Oliver Smith