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
Harald Welte
Philipp Maier
Stefan Sperling