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
Vadim Yanitskiy
Philipp Maier
Harald Welte