It will be used too by osmux code present in another file. This is a
preparation commit to simplify the one adding osmux support.
Change-Id: Ie7fa57bb04db9ad9b03971467e12ee7b8e4c190a
The queue_limit_to method iterates the entire list of messages every
time a new message is added. Let's use msgb_{enqueue,dequeue}_count()
APIs to do that in constant time. It is true that since the queue is
limited to 1, there's usually at most 1 item in the queue so it's not a
real problem. However, when we add Osmux in the future, we may need to
tweak the amount of messages which can be in the list, due to Osmux
batching mechansim which may be more bursty sometimes.
In any case, this change doesn't make things worse for sure.
The patch also takes the chance to group the queue_limit_to + enqueue
into one function to avoid having the code spread several times.
Change-Id: I61818a3bb521c27bd21a8b6fa70581d27638ec9b
SACCH detection can be simplified by checking the RSL Link ID in
process_l1sap_meas_data(). This eliminates the need to lookup
the multiframe position by calling trx_sched_is_sacch_fn(), which
definitely takes more CPU time than just L1SAP_IS_LINK_SACCH().
Calling trx_sched_is_sacch_fn() is still required for BTS models
reporting the measurements via PRIM_MPH_INFO (legacy way),
separately from the related Uplink blocks.
This patch can be summarized as follows:
* detect SACCH and set .is_sub=1 in process_l1sap_meas_data();
** for PRIM_MPH_INFO use trx_sched_is_sacch_fn();
** for PRIM_PH_DATA use L1SAP_IS_LINK_SACCH();
* do not call trx_sched_is_sacch_fn() from ts45008_83_is_sub();
* modify the unit test - test_ts45008_83_is_sub_single();
** remove test_ts45008_83_is_sub_is_sacch().
Change-Id: I507e96ee34ac0f8b7a2a6f16a8c7f92bc467df60
Related: SYS#5853
It may happen after the A-bis connection recovery that the RF RESource
INDication message gets sent too early, while some timeslots are not
yet configured. This confuses the BSC and provokes error messages.
Change-Id: I00bc6fe67ea1bbedcd5d8640e73bd8b16b9e667f
Related: SYS#5313, SYS#4971
Currently an Uplink SACCH block is being passed to LAPDm first, and
then gets forwareded to the BSC in handle_ms_meas_report(), together
with the Uplink measurements collected so far.
This approach has a serious flaw: handle_ms_meas_report() won't be
called if an Uplink block contains SAPI=3 data (SMS) or was not
decoded at all (len=0) fow whatever reason. Therefore, no RSL
MEASurement RESult message will be sent to the BSC.
Rename handle_ms_meas_report() to lchan_meas_handle_sacch(), and call
it from l1sap_ph_data_ind(). This way perioduc RSL MEASurement RESult
messages will be sent regardless of what happens on Uplink SACCH.
Change-Id: Ifed91f87fd653debc87a09da3fd31ad64a13f330
Fixes: TC_meas_res_speech_{tchf,tchh}_sapi3
Related: SYS#5319
In 2/3 cases when calling process_l1sap_meas_data() we already have
a pointer to the logical channel, so let's pass it as the first
argument instead of a pointer to the transceiver. This way we
avoid calling get_active_lchan_by_chan_nr() two times.
In l1sap_ph_data_ind(), call process_l1sap_meas_data() below the
conditional branch handling PDCH, so it won't be called for
GSM_LCHAN_PDTCH anymore. GPRS specific measurements are handled
by the PCU and not of interest for the BSC.
Change-Id: I9de67a0b2d2b18923f2c2003b400387a0f1af411
After merging the patch [1] fixing handling of the RLL RELease
INDication message in lapdm_rll_tx_cb(), ttcn3-bts-test shows
several regressions:
pass->fail: BTS_Tests.TC_rll_rel_ind_DCCH_0
pass->fail: BTS_Tests.TC_rll_rel_ind_DCCH_3
pass->fail: BTS_Tests.TC_rll_rel_ind_ACCH_0
pass->fail: BTS_Tests.TC_rll_rel_ind_ACCH_3
pass->fail: BTS_Tests_LAPDm.TC_sabm_dm
[1] I823c9101bcca72d5792e16379b02d3602ffc2726
991020c049
The problem is actually *not* in patch [1], but in the older one
[2] which we attempted to fix. While a logical channel is in
signalling mode, the lower layers do not produce PRIM_TCH_RTS,
and thus the l1sap_tch_rts_ind() is not being called.
Unlike l1sap_tch_rts_ind(), the l1sap_ph_rts_ind() is being called
regardless of the channel mode (signalling vs speech), so let's
move handling of lchan->pending_rel_ind_msg there.
Change-Id: I2c380f9045624f0a0a8f988bb207bc73d8354857
Fixes: [2] Ie4f70c75f0137b4bd72d579b3a32575bac2fca3
This avoids triggering all sorts of unexpected paths where one tries to
release an already released lchan, etc.
This can happen for instance if BTS shuts down due to BSC link going
down, and hence resets all lchans, announcing it to the PCU. Then the
PCU may try to deactivate the channel sending act_req (disable), but the
BTS already unilaterally dropped the channels.
That code path seems to trigger some crash, probably because something
in lchan has been freed.
Related: SYS#4971
Change-Id: I093e4d4e23b527b10bf5d6ff538460626c30a8f8
For the sake of consistency, call repeated_dl_facch_active_decision()
from handle_ms_meas_report(), so we have all functions using the
measurement results for Downlink executed in a single place.
Change-Id: Ibd5377ce642e49161f320ac8c33e9f966b3ddfaf
Related: SYS#5114, SYS#5319
Currently, only osmo-bts-trx is capable of reporting the interference
levels to L1SAP. Thus it does not make sense to trigger the averaging
logic and send empty reports over the A-bis/RSL and the PCUIF.
Change-Id: Ic17eb46bdca3c33ac4d6e560a093b635b75424a5
Related: SYS#5313
Starting from [1], interference levels on PDCH timeslots are also
reported over the A-bis/RSL. They may be useful for the BSC to
determine whether dynamic PDCH timeslots might be better used for
new circuit switched connections, or whether alternative PDCH slots
should be allocated for interference reasons.
* Handle GSM_LCHAN_PDTCH in lchan_report_interf_meas().
* Rework pcu_tx_interf_ind() to accept 'struct gsm_bts_trx'.
* Call pcu_tx_interf_ind() from l1sap_interf_meas_report().
Regarding pcu_tx_interf_ind(), it's better to call this function
from the upper layers once, rather than calling it from various
places in the model specific code.
[1] I5b4d1da0920e788ac8063cc765fe5b0223c76758
Change-Id: I3fbaad5dbc3bbd305b3ad4cb4bfb431a42cfbffc
Related: SYS#5313
It's cleaner from the architectural point of view to have the
interference measurements processed in a separate function.
Change-Id: I3981608e01a50585359cad673c38c8a305027d30
Related: SYS#5313
Only once we receive the Measurement Result on L3 from MS we are able to
find out whether DTXu was used, and hence whether SUB or FULL
measurement set should be used.
Let's move all control loops there to have them in one place together,
and have it at a similar level where it would lay if it was to be
implemented in the BSC.
Related: SYS#4917
Change-Id: Ic152473577ff7c33d30b3f4ee7e321fcb523f723
This is a preparation commit in order to move power loops up in the
stack in order to have DTXu information available, in order to decide
whether SUB or FULL ul measurements should be used in the MS Power
Control Loop.
Function rsl_tx_meas_res() is stripped from code changing state, and it
simply encodes content and transmits the message.
Change-Id: Id67259ec9ac4c2c33bd0eef3f64450affbe3fb9f
LOGPLCHAN() prepends the contextual information for us, there
is no need to print trx->nr again. Take a chance to apply
some additional cosmetic changes, like fixing capital letter.
Change-Id: Ia199d584c937eef4118c99af4523fd91b2e46107
This way the PCU can signal idle RLCMAC blocks (no transmission
required) to the BTS, which can then send dummy/fill blocks aplying
power reduction as needed by TRX.
The block with len=0 is submitted to lower layers up to the scheduler,
which will finally drop it in trx_sched_ph_data_req().
Change-Id: I734c66e236bf3e2015a4571ea1fd84849a9ef02c
Related: SYS#4919
As per 3GPP TS 45.008 sec 4.2, the ms_pwr received in L1 SACCH Header is
the value used over previous measurement period. Hence, we need to feed
the algo with the measurements taken over that same period.
Related: SYS#4917
Change-Id: I13c0014fdd73f823ae5b1256c35bfa7d97cfa334
As per 3GPP TS 45.008 sec 4.2, the ms_pwr received in L1 SACCH Header is
the value used over previous measurement period. Hence, we need to feed
the algo with the measurements taken over that same period.
Related: SYS#4917
Change-Id: I00852cb37a3613606e37476c169f5a32d6b5d75e
Field is renamed to look similar to similar fields in power control
loop. This is a preparation commit, next one will add functionality to
skip SACCH blocksi (P_CON_INTERVAL).
Related: SYS#5371
Change-Id: I169ce58ab827e38b64f4b15f935097a9118fa118
First step improving and reworking TA loop:
Move trigger of the loop to similar place done by BS/MS Power Control
Loop, that is, upon receivial of UL SACCH block, which contains
information about the TA used to transmit the block encode in L1SACCH
Header. Hence, from computed received TOA and TA used when transmitting
from the MS, we can infer the desired TA to be used by the MS, which
will send back to it later during DL SACCH block.
The values taken are actually the ones calculated for the previous SACCH
block and stored in lchan->meas.ms_toa256. That's because L1SACCH
contains the TA used for the previous reporting period, similarly to
what's specified for MS Power Control loop (TS 45.008 sec 4.2):
"""
The MS shall confirm the power control level that it is currently employing
in the SACCH L1 header on each uplink channel. The indicated value shall
be the power control level actually used by the mobile for the last burst
of the previous SACCH period.
"""
(The reader may observe that currently this is not properly done for MS
Power Control loop when calling lchan_ms_pwr_ctrl(): this is a bug.)
This new method also permits changing TA quicker, since we have more
confidence that the TA we request is aligned with the one used to
transmit, and we don't simply increment/decrement based on the value we
request to transmit.
Related: SYS#5371
Change-Id: I2d0f128c8dcac93ee382283a1c91fca76623b8fc
This commit extends existing MS Power Control Loop algorithm to take
into account computed C/I values on the UL, received from MS. The
related C/I parameters used by the algorithm are configured at and
provided by the BSC, which transmits them to the BTS similar to already
existing parameters.
Using C/I instead of existing RxQual is preferred due to extended
granularity of C/I (bigger range than RxQual's 0-7).
Furthermore, existing literature (such as "GSM/EDGE: Evolution and Performance"
Table 10.3) provides detailed information about expected target values,
even different values for different channel types. Hence, it was decided
to support setting different MS Power Parameters for different channel
types.
These MS Power Parameters are Osmocom specific, ie. supported only by
newish versions of osmo-bts. Older versions of osmo-bts should ignore
the new IEs added just fine. The new IEs containing the MS POwer
Parameters are not send for non osmo-bts BTSs, hence this commit is
secure with regards to running osmo-bsc against an ip.access BTS such
as nanoBTS.
Related: SYS#4917
Depends: libosmocore.git Change-Id Iffef0611430ad6c90606149c398d80158633bbca
Change-Id: I5dfd8ff9ab6b499646498b507624758dcc160fb6
When generating GSMTAP, we are already suppressing generation for
fill frames on PCH and AGCH. Let's expand that also to dedicated
channels SDCCH, TCH/F and TCH/H. The fill frames just clog up the
logs without providing much benefit.
SACCH is still being logged, as it contains SI or MEAS REP, so every
active channel still sees GSMTAP traffic every 480ms (SACCH interval).
Change-Id: I0dd37d8848eb0379f84d15f5f006142b16823c6a
This reverts commit cd30a40be1.
As a part of SYS#4919 "BTS energy saving", we want to support
constrained (up to 6 dB) BS power control on BCCH carriers.
Change-Id: I0d2b48c4b2af2d8e94f4ad02fa4774dbd0a0a654
Related: SYS#4919
This change implements general interference averaging logic for
the higher layers. In l1sap_info_time_ind(), where we receive
TDMA time updates from BTS model, call rsl_tx_rf_res() for each
transceiver according to the interval defined by the Intave
parameter received from the BSC. In rsl_tx_rf_res() perform
the actual averaging for each inactive logical channel, and
then send everything to the BSC over the A-bis/RSL.
The BTS model specific code needs to report the measurements
for each logical channel every 104 TDMA frames (SACCH period)
by calling gsm_lchan_interf_meas_push().
Change-Id: Id80fdbef087de625149755165c025c0a9563dc85
Related: SYS#5313, OS#1569
Using the normal arithmetic for TDMA frame numbers may result
in getting wrong values. Consider the following situation:
'info_time_ind->fn' is 0 (beginning of period)
'bts->gsm_time.fn' is 2715647 (end of period)
With these input values the following expression:
info_time_ind->fn - bts->gsm_time.fn
will be equal to:
0 - 2715647 or -2715647
In this case osmo-bts does not log an error, because:
if (-2715647 > 0) // is false
As a consequence, we do not increment number of RACH slots that
have passed by since the last time indication:
for (i = 0; i < -2715647; i++) // is false
This is why we introduced GSM_TDMA_FN_{SUB,SUM,DIFF,INC} API.
Change-Id: I6168dd75daea50bbe2e19338e637185ac9ac87ef
For some reason, handling of the Channel Identification IE was done
in l1sap_chan_act(). This function is being called on reciept
of the CHANnel ACTIVation message, but not on MODE MODIFY.
Change-Id: I07f95e69e6230a1daca62cc0a7c64954f191fa8a
Related: SYS#5315, OS#4940
In [1] I introduced a regression, so osmo-bts started to complain:
This PHY does not support lchan TSC 3 != BSIC-TSC 7
on channel activation, despite the TSC in RSL_IE_CHAN_IDENT was 7.
The problem is that this statement:
cd = (const struct gsm48_chan_desc *) TLVP_VAL(tp, RSL_IE_CHAN_IDENT) + 1;
is basically equivalent to:
cd = ((const struct gsm48_chan_desc *) TLVP_VAL(tp, RSL_IE_CHAN_IDENT)) + 1;
so we actually shift the pointer by sizeof(struct gsm48_chan_desc)
and skip 3 octets instead of just one (IEI octet). Fix this.
Change-Id: Ic3a81396b60577e03c541d32839d07dc6d45c838
Fixes: [1] Id100f4c56fd5c1adad5d925d97240bed82981b9b
Fixes: OS#5121
As the prefix in 'GSM48_IE_CHANDESC_2' implies, this IE belongs
to 3GPP TS 04.08 (or TS 44.018), so it can be used in the Radio
Resource assignment messages sent to the MS. While in this
function we're dealing with 3GPP TS 48.058, and thus the IEI
may be (and actually is) different for the RSL messages.
Also, according to 3GPP TS 48.058, section 9.3.5, the Channel
Description IE is included together with its element identifier,
so we need to skip one byte when doing the pointer casting.
Change-Id: Id100f4c56fd5c1adad5d925d97240bed82981b9b
Related: SYS#4895, OS#4941
Instead of blindly assuming what the PHY does support, and what
it does not, let's check the related feature vector.
Change-Id: I699cdddbfab111855998853548d9cfe956f7c60c
Related: SYS#4895, OS#4941
Similar to what we have been doing for TCH channels, we want to make
sure all MAC blocks get to the upper layers, even if containing invalid
data (flagging it with data_len=0) so that upper layers (osmo-pcu
through PCUIF in this case) can rely on FN clock without gaps due to
Rx errors.
Related: OS#5020
Change-Id: I0b04b013b7bad5ff53d6a969ff0128b37f7f62d5
At the moment osmo-bts is not looging much ACCH repetition related
information. This makes testing ACCH repetition difficult. Lets add some
debug output that informs the user when ACCH repetition is turned on or
off. Lets also add an ACCH repetition status display to the show lchan
VTY command.
Change-Id: I59d11fd03be3d29fb8a4279d9945b03006764c0e
Related: SYS#5114
Pau Espin
Vadim Yanitskiy
Harald Welte
Philipp Maier