As a side effect, we have to sacrifice a unit test (TC_inval_dummy)
because it becomes impossible to pass a dummy or invalid SACCH block
to lchan_bs_pwr_ctrl().
Change-Id: I937117cf26fb718d57920382f6972390ad498c51
Related: SYS#4918
The current Timing Advance value can be obtained either from the
L1 SACCH header (if received) or from lchan->ta_ctrl.current.
Change-Id: I2b3693a0e49f03f2b4496c9dbd30cf47e9bc86b5
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
This way we keep all BTS connected to the same BSC if there was a
spurious network problem.
Related: SYS#4971
Change-Id: I16b75da5987584d099edc3a640f3a5cd61f3ad69
priv->current_bsc will for sure be != last, otherwise it would have
entered the if clause above it.
Change-Id: I0a6519f7b93f0b45c67d19fef4f50daeeefc7340
Recent commit (see below) changed a check to avoid weird results for msg
which had l2h=NULL, since l2len would return unexpected results there.
However, some code branches like FACCH or TCH seem to be always setting
l2h even if len=0. Hence, we must test either of the 2 scenarios (null
pointer and l2len()).
This commit fixes the following message appearing all the time during
calls:
"""
TCH/F: Prim has odd len=0 != 23
"""
Fixes: fb905b8d23
Related: SYS#5676
Related: SYS#4919
Change-Id: I43152bc8484a35cd004d3303d3a6e6efcdefa890
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
It could happen if for instance l1 code called trx_sched_clean() when
closing the phy, and after that some code called (erroneously)
trx_sched_set_lchan(). Let's make sure we don't allow other modules to
crash the process when using this function.
Related: SYS#4971
Change-Id: I93af7c3dcf0e34e9317eec0ee183dbf18b8d2f3b
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
msgb_l2len() will return nonzero values if msg->l2h is NULL.
Let's check against msg->l2h being NULL instead.
Related: SYS#5676
Related: SYS#4919
Fixes: 300e31ed13
Change-Id: I18b61fcaa858a53887191a18d560c2e929478c64
The new [bit-]fields in the RSL_IE_OSMO_TEMP_OVP_ACCH_CAP allow
more fine-grained control over the overpower feature, which
can be enabled:
* for both SACCH and FACCH,
* for SACCH only, or
* for FACCH only.
Change-Id: Iaaab675a20bbefece832d913963c8c5ae32ff80c
Depends: Ia28293a12de0af71f55e701fb65c46e905dae217
Related: SYS#5319
The new fields in 'struct abis_rsl_osmo_temp_ovp_acch_cap' allow:
* selectively enabling SACCH and/or FACCH,
* setting the RxQual (BER) threshold.
Both features are implemented in the follow-up commits.
Change-Id: I370c8f95fb64eceb60a9dc2eae1412f8a0df0f4e
Depends: Ia28293a12de0af71f55e701fb65c46e905dae217
Related: SYS#5319
This adds a --enable-systemtap configure option, which will then
add static tracepoints to the generated osmo-bts-* binary.
At this point, only two sets of tracepoints are supported, and
only in osmo-bts-trx: ul_data_{start,done} and dl_rts_{start,done}.
The probes are intended to be used for analyzing the amount of time
needed for processing of uplink bursts / generation of downlink bursts.
Change-Id: Ibb4962253f1a195dc1a54405bac058ccb2545799
During the merge of [1] the patch hunk was applied at a slightly
wrong location, so the code path has become unreacheable.
Change-Id: I823c9101bcca72d5792e16379b02d3602ffc2726
Fixes: [1] Ie4f70c75f0137b4bd72d579b3a32575bac2fca3
A logical channel may have associated messages, which are pending
for transmission until some event occurs. Do not leak them.
Change-Id: I3264e6caa007e9e9cb9c1c2f8627c408bbb28b9e
In repeated_dl_facch_active_decision() we rely on the Measurement
Report message, that in some cases may not contain valid Downlink
measurements. In this case, we should simply ignore it.
Change-Id: I0d72b454f2b770d5762303fb70a15a8cdc9d07d7
Related: SYS#5114
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
A bit of archeology, history & recap:
ec1b5a0e9e2b6549e0ede48e803095e569997355 (openbsc.git) Adds assert in gsm_ts2chan_nr()
2f44693fad8505255293d3ed37dbd4e7cabebd37 (openbsc.git) ASSERT is disabled due to reported hit in octphy and
litecell in gerrit for ec1b5a0e9e2b6549e0ede48e803095e569997355
5cef0623ef (osmo-bts,git) minor fixes to gsm_ts2chan_nr() regarding the pragma
c9079d9106 (osmo-bts.git) GSM_PCHAN_NONE case is introduced in gsm_ts2chan_nr()
This code has long evolved and robustness has improved, it's not even
part of openbsc.git for several years now. Let's always assert if we
receive an unexpected value there, since they are all internally handled
values and hence we have control over them.
Related: OS#2906
Change-Id: I25e2cf0c922bc9902336e9add75a47535b9355bf
It can happen when using several TRX that all of them go alreadyunder
shutdown target tx power level, but that due to configuration the BTS
still may want to keep pushing the tx power level even lower. Hence, we
end up in a situation where the FSM is trying to close all the TRX while the
power ramp procedure is ongoing for some of them. As a result, race
conditions can happen where for instance the power ramping procedure for
one TRX ends and calls the cb to send SETPOWER after the TRX PHY has
been closed (and hence TRXC link is unavaialble).
If that happens, the trx_if lower layers store the SETPOWER and attempt
a later retransmit, which may take up to 2 seconds after TRX becomes
active if BTS reconnects immediatelly.
Hence, we end up in some test cases where BTS reconnects and configures
some TRX while others are kep unconfigured for a while due to the
mentioned delay, hence the test attempting to use the TS while it hasn't
been yet configured.
The solution is to avoid this kind of unexpected events with ongoing
powe ramp once we have decided tx power is lower enough to shutdown the
TRX completely. Hence we abort the pending power ramp procedure.
Change-Id: Ibca581131eb142d7c38c917a0d6990efec03123c
Fixes crash when TTCN3 BTS_Tests_LAPDm TC_rr_response_frame_loss
runs run after TC_t200_n200.
The BTS was shutdown after TC_t200_n200 failed (drop oml link), and
lchan was moved ACTIVE->NONE without lapdm_channel_exit() being called
on it. Hence, on next test (TC_rr_response_frame_loss), when
lchan_init_lapdm() was called again, some memory corruption was caused.
The lapdm_channel_exit can be dropped from gsm_lchan_release() and
rsl_tx_rf_rel_ack() since it's already called in the same path:
"""
rsl_rx_rf_chan_rel
gsm_lchan_release(lchan, LCHAN_REL_ACT_RSL);
l1sap_chan_rel(lchan->ts->trx, gsm_lchan2chan_nr(lchan));
l1sap_chan_act_dact_modify(trx, chan_nr, PRIM_INFO_DEACTIVATE)
bts_model_l1sap_down
bts_model_lchan_deactivate_sacch(lchan);
-
lchan_deactivate(lchan);
bts_model_lchan_deactivate
lchan_set_state(lchan, LCHAN_S_NONE); <---------
mph_info_chan_confirm(trx, chan_nr, PRIM_INFO_DEACTIVATE, 0);
l1sap_info_rel_cnf
rsl_tx_rf_rel_ack(lchan);
lapdm_channel_exit(&lchan->lapdm_ch);
lapdm_channel_exit(&lchan->lapdm_ch);
"""
Related: SYS#5262
Change-Id: If0ec5f0c7be4d15c8d684d33e15e24d68bd5192e
osmo-bts-trx/l1_if.c lchan_init_lapdm() for CCCH is already done when
trx_set_ts_as_pchan() calls:
"lchan_set_state(&ts->lchan[CCCH_LCHAN], LCHAN_S_ACTIVE);"
Change-Id: I7a9c3660b9aab57ff8765e2f1526349599630cd9
Let's avoid running over state change conditions or even printing log
lines if there's no state change.
Change-Id: I1ca86aa846084f53751076643665cb6dabc26a06
There's no need to re-setup it every time.
Mark the cb as static since its private to the module, and move it
above its use point so it can be referenced.
Change-Id: I90324f26d8ca09d425c7523a25b3e6c951fa49d6
The OML NM Channel FSM state only apply to primary timeslots, hence we
need to make sure we pick the primary TS (the non-shadow one).
Due to this bug, all channels on shadow TS where NACKed because the
related state was never "Enabled Ok".
Fixes: c97a7f51e1
Related: OS#5249
Related: OS#5251
Change-Id: If47e4bdd45a05ed1b5709b6e3d541f2830723e37
Since non-shadow TS are currently not allocated as talloc contexts,
lchan objects tend to allocate their own memory on trx talloc ctx
instead. That's fine for non-shadow TS, since the TS follow trx lifecycle
since they are part of the same talloc context. However, shadow TS are
recreated (re-allocated) each time the BTS reconnects, hence when htey
are freed we need to free substructs (lchan) memory in order to avoid it
being kept in trx talloc ctx.
Related: OS#5248
Change-Id: I73742535eb3c40a6866731acbff782940dab06c3
Code in oml.c, upon receiving net attributes, merges the new attributes
with old ones (for some reason I don't really know). Hence, if we
disconnect from a BSC and go to NOT_INSTALLED state, we must free
previous nm_attr in order to avoid mixing them once we connect to a new
(potentially different) BSC upon reconnect.
Related: OS#5248
Change-Id: I45cc22dd68121a7930301581bfd0a8db37879c77
Let's rather put it there instead of the shutdown code path, since we'll
be adding more and more reset coe there.
Change-Id: I43a136ade731a2c58c0a29d97875088e9b6d4414
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
This information 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.
Change-Id: I5b4d1da0920e788ac8063cc765fe5b0223c76758
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
It may happen that the BSC requests logical channel activation on a
dynamic timeslot, which is in a process of switching from one pchan
type to another due to a preceding channel activation request.
In this case 'struct gsm_bts_trx_ts' already holds an msgb with the
preceding RSL CHANnel ACTIVation message, that is normally handled
once the PHY completes the process of timeslot re-configuration.
On receipt of subsequent RSL CHANnel ACTIVation messages, in function
dyn_ts_l1_reconnect() we overwrite the preceeding msgb (memleak), by
the most recent one. And once the timeslot re-configuration is done,
only the most recent CHANnel ACTIVation message gets ACKed.
In order to avoid this, let's move the msgb ownership to 'struct
gsm_lchan', so it cannot be overwritten by the CHANnel ACTIVation
message that is related to a different lchan on the same timeslot.
Change-Id: Ia625c2827fca883ea712076706d5ef21ed793ba6
Related: I3b602ac9dbe0ab3e80eb30de573c9b48a79872d8
Fixes: OS#5245
Otherwise after reconnecting some SI are still marked as valid despite
the new BSC conn didn't set them.
Change-Id: I71e2a5cdf4e2e287db7b05df1a165a1e32c958ca
Let's split all lchan and power_control specific stuff into their own headers,
it helps finding out data and operations available related to them.
We already have similar classification in osmo-bsc.
Change-Id: I6424dcbd2e329fc1a516f8886359554ed7e9487e
It makes no sense to transmit load information if the channel is still
not operational. This solves errors messages seen in osmo-bsc.
Related: OS#4872
Change-Id: I7ddda9776158eed0694df9e458f3f91df90bf674
Have a more stable loop with less temporary oscillations at the expense
of increased reaction time.
4 SACCH blocks (P_CON_INTERVAL=2) is the minimum interval to get stable
measurements for the last requested MS Power level. With P_CON_INTERVAL=1,
are also made during a period with stable power being use to transmit,
but the MS Power level used (and announced in MR) is not the last one
requested by the BTS, but the one requested in the previous loop
iteration. This can make the MS and BTS bounce 2 values forth and back,
and create some temporary oscillation.
See osmo-bsc User manual section "Power Control" for more information.
Related: SYS#5371
Change-Id: I91c505447f68714239a4f033d4f06e91893df201
A broken BSC could send a Chan Activation on a TS which has not yet been
enabled (or even configured). This is the case with our TTCN3 tests,
where OML side is currently handled in parallel by an osmo-bsc while
TTCN3 takes care of the RSL side. This can actually be seen as a
malfunctioning BSC, but it was spotted that given this sequence of
events osmo-bts can crash (see ticket below).
Hence, let's NACK any attempt from a BSC to activate an lchan on a
disabled TS.
Related: OS#5249
Change-Id: I9c3b68487c12efc412a057728a561e061560c544
The first check in this function ensures that the state is NONE.
Therefore it does not make sense to print it below..
Change-Id: I62ea4117dd5e1eebb8774809134e5cb73774945c
Each RSL MEASurement RESult message contains a Measurement Number
IE, which is basically a monolithically increasing number. We
shall not increase this counter if for whatever reason the report
has not been sent to the BSC.
Change-Id: I441adb4b202e94ddee8c0b6777849e36ea644b1d
Fixes: Id67259ec9ac4c2c33bd0eef3f64450affbe3fb9f
Fixes: OS#5243
Avoid re-connecting to a new BSC while BTS is in shutting down. All the
FSMs are complex enough to even try to re-start when stopping has not
yet finished...
Change-Id: I1727828a16f4ec8043b00cc6b2e02a4c35f71377
Prior to this patch, the power ramping started when the PHY is
available, but that doesn't necessarily mean the RCARRIER is enabled.
Due to this, it was spotted a situation where BTS bootstrap failed after
PHY turning up, when RSL connection establishment failed. Hence
bts_shutdown_fsm triggered a shutdown while an active power ramping up
was ongoing...
Change-Id: I17208b74ea2649b1bbb717aee0aa355e42b7e860
Previous code creating a new line was really a workaround to have it
working while previous lines were being stacked internally inside
libosmo-abis.
Let's handle reference counts for the line properly and keep using the
same line always (since it can be further configured by libosmo-abis' VTY).
Recent patches to libosmo-abis fixed a bug where e1inp_line_update()
would only work the first time it was called on a e1np_line, and follow
up calls would be no-ops. This fix allows re-configuring and hence
reusing the same line to reconnect to BSC.
Depends: libosmo-abis Change-Id: Iff8092f88726cf238dac2abb99e135ac5864272d
Change-Id: Id7fd3ef81bbc517821def31f1a60f905a0e2fb52
The temporary overpower value that is to be used with FACCH and SACCH is
transferred using a proprietary RSL IE (RSL_IE_OSMO_TOP_ACCH_CAP). The
parsed value is then stored in lchan->bs_acch_overpower_db so that it
can be used.
Change-Id: I426c2510865c4a986c68f2027cc676aaac0d8a4c
Related: SYS#5319
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
GSM/EDGE Evolution and Performance, Section 12.3 suggests Temporary
Overpower as another solution to improve SACCH/FACCH performance in
case of bad C/I. The idea here is that you increment the DL transmit
power by 2..4dB only for FACCH/SACCH bursts, while keeping all voice
bursts at the lower (normal) level as determined by BS power control.
SACCH blocks can be recognized by the channel type, since they're
always transmitted in specific frames of a multiframe. FACCH blocks,
however, are not predictable and can substitute voice blocks at
(almost) any time. Thus we need to mark FACCH bursts as such in
the logical channel handlers (using TRX_BR_F_FACCH).
Change-Id: Ie8a626fefccf1eb07271058e5126ec106cb1abcf
Related: SYS#5319
When I introduced this branch in change [1], I was under assumption
that PDCHs never have an associated 'struct gsm_lchan'. This is
incorrect: the association actually happens during PDCH activation,
i.e. when osmo-pcu establishes connection over the PCUIF.
Enforcing attenuation of 0 dB for other channel types makes no sense.
[1] I3dcee6e910ccc61c5c63c728db9ea04327e2fc98
Change-Id: I77a839725f22be1be4a025f579c4c9ccdfb53460
There is no need to log channel activation / deactivation messages
as LOGL_NOTICE - this is a normal event requiring no attention.
Change-Id: I7765fecb7f7ec67c8f96e91c378626e21e48c71d
The ip.access style dynamic timeslots are a bit special in a way that
on the A-bis/RSL we always use the Channel Number value of TCH/F,
even in PDCH mode. This is why gsm_lchan2chan_nr() would always
return values corresponding to TCH/F for TCH/F_PDCH.
This behavior is only acceptable in the context of RSL messages, while
other parts of the code base may not work properly due to this trick.
A good example is the scheduler in osmo-bts-trx, where we have to
patch Channel Number value to make channel activation work.
DPCU INFO pcu_sock.c:853 Activate request received: TRX=0 TS=5
DL1C INFO l1sap.c:2043 (bts=0,trx=0,ts=5,ss=0) Activating channel TCH/F on TS5
DL1C NOTICE scheduler.c:1097 (bts=0,trx=0,ts=5,ss=0) Activating PDTCH
DL1C NOTICE scheduler.c:1097 (bts=0,trx=0,ts=5,ss=0) Activating PTCCH
In the code branch responsible for channel deactivation, we somehow
forgot to add the same workaround, so deactivation does not work:
DL1C INFO l1sap.c:2076 (bts=0,trx=0,ts=5,ss=0) Deactivating channel TCH/F on TS5
DTRX INFO trx_if.c:255 phy0.0: Enqueuing TRX control command 'CMD NOHANDOVER 5 0'
DRSL NOTICE rsl.c:1286 (bts=0,trx=0,ts=5,ss=0) (bts=0,trx=0,ts=5,ss=0) not sending REL ACK
Because of that, TCH/F_PDCH timeslots actually remain active after
deactivation, so the scheduler keeps producing L1SAP DATA.ind.
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DL1P ERROR l1sap.c:732 1583426/1194/00/29/14 No lchan for DATA MEAS IND (chan_nr=PDCH on TS5)
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DL1P ERROR l1sap.c:732 1583430/1194/04/33/18 No lchan for DATA MEAS IND (chan_nr=PDCH on TS5)
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
Instead of patching Channel Number in various places, let's rather
make the RSL specific behavior configurable by having two variants
of gsm_lchan2chan_nr().
Change-Id: I01680140c7201bf5284b278bceaea8ae01c122b2
Fixes: OS#5238
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
osmo-bts-omldummy is known to be specially in the sense that it has no
phy. This should ideally be changed to have some dummy object, but so
far that's how it is. A recent commit checking the phy's forgot about
the fact that BTS model has no phy. Let's fix it.
Fixes: 4ddc37ce71
Change-Id: Iba7873530aac74b3bf799819890641196dacf170
Previous code creating a new line was really a workaroudn to have it
working while previous lines were being stacked internally inside
libosmo-abis.
Let's handle reference counts for the line properly and erase +
re-create it every time.
Recent patches to libosmo-abis fixed a crash happening when refcount
being 0 and destroying the object (object was not removed from a global
llist).
Depends: libosmo-abis Change-Id I1314d6b917ecb622994507475eb894e649a1a2ad
Change-Id: Ic37ae5bf657247e8cce99182c40d9adf890a5e41
Commit below (see "Fixes" section) wrongly erased the code re-introduced
in this commit, due to not spotting different between "oml_link" and
"osmo_link". This commit is hence a revert of such commit, updated to
current code.
Fixes: c2ba34d9c1
Change-Id: Id436116e5cd0bec024b2f9943fbff8d0bdc956ac
This function is only called during sign_link_up() e1inp callback, hence
only the link!=NULL condition (UP) is ever executed. Let's drop the DOWN
path and make it a function only used to trigger events when link
becomes up, similar to what bts_link_estab() does with OML.
Here it becomes clear the NM_EV_RSL_DOWN was never sent. It's not much
of an issue though since it would only make transition RCARRIER/BBTRANSC
Enabled->DisabledOffline. However, since due to libosmo-abis limitation
we receive a sign_link_down() for the entire line when 1 of its links
goes down, we don't care much since we go for shutdown of the entire BTS
anyway. Ideally, libosmo-abis would support simply telling us 1 of the
links in the line went down and if it was not OML and not RSL TRX==C0,
then we could keep on running and simply disable the related TRX.
Change-Id: Iac553c68339c0da32fd313676995747eb4344087
This feature is not yet used by any bts_shutdown_fsm caller, but will be
used in the future when Abis link goes down.
Change-Id: I5dc282fdbcf862067be326e72b6183dd544222ae
Since recently we support shutting down phys when BTS goes into shutdown
mode. Let's make sure they are opened again when we connect again to the
BSC.
Change-Id: Ia1df6f4a1e0e6daeffe7303d518776a04b023930
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
This way we provide an effective way to disable C/I based decision
taking in the MS Power Control Loop. With this set up, MS Power Level is
decided only based on RxLev. This allows for working setup in following
scenarios:
* BTS L1 not passing proper C/I values to upper layers (eg. TRXDv0).
* User not willing to spend time configuring proper C/I levels for each
channel type.
Related: SYS#4917
Change-Id: Ibd10eb96a5d072d5c19f7449a8b11e64aad1cd4c
This will allow in the future advertising children objects that the
parent object has been configured. It is useful for instance to let TRX
know that the BTS is configured.
Change-Id: Ie319465fd0e991bab8451ea34ec72ff3702533d2
There's no real use for this queue. If the link is gone, it makes no
sense to keep old messages. Instead, BTS should generate new messages
sharing current state when link becomes established (it actually does
so already).
Change-Id: Iecd3c7cb96f5fff3b4c7e04c74e031df0f7a6987
Vadim Yanitskiy
Pau Espin
Harald Welte
Philipp Maier