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
It helps better understanding the code, and will allow handling
situations where for instance a POWERON in in transit while the BTS is
instructed to shutdown, hence a POWEROFF needs to be sent.
Change-Id: Iaf62217ceab7420afa4140cba61e1c2f983c61b4
config.enabled is always true in that state. Hence, those paths can be
securely dropped since only add confusion.
Change-Id: Icf00c52e61ddedd8e32eb37223cea5686005e6a3
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
This was colliding with the global "show trx" command introduced a few
years ago, and prevented both command from working.
Change-Id: I57f9515292f7bd906599e2cc277542bfaf3b657b
Related: OS#5080
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
This may happen if bts_shutdown starts a poweroff procedure while
POWERON was still not sent to the TRX. In this case, we want to go back
to initial closed state to fullfill expected state when BTS is shutdown.
Change-Id: Id660fa1018ef175ab237733b37629c56313c061d
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
Recent commit added code to reset trx_provision_fsm state fields in orer
to support re-using the FSM once BTS is reconnected to a BSC.
However, some values being reset there are not set up when reconnecting
to the BSC, but rather configured through VTY at startup. Hence those
values should be kept.
Fixes: 32b51eca7d
Change-Id: I5c31241327b98386c313cd9377cf76c009456105
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
Thanks to [1], there is no need to patch chan_nr for PDCH anymore.
The upper layers are now expected to use the correct values.
[1] I01680140c7201bf5284b278bceaea8ae01c122b2
Change-Id: I26eb2081eddb4ce900a7867897bc69c3f77dbd73
Related: OS#5238
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
In functions responsible for Downlink burst scheduling, it may happen
that the buffer, containing a complete set of to be transmitted bursts,
a) is not yet allocated or b) was de-allocated intentionally. In this
case, we return early to avoid NULL pointer dereference. The returned
value is then checked against 0 in _sched_dl_burst().
Returning 0 makes _sched_dl_burst() apply per-burst attenuation, as
well as the A5/x encryption (if enabled). And this makes no sense
in either of the cases mentioned above.
Moreover, in the BCCH power reduction mode, this causes some bursts
(bid > 0) of idle PDTCH/PTCCH blocks to be transmitted at full power,
breaking the energy saving feature.
Change-Id: I18aa73cc950fdfac030b63f7a434a71b4596095d
Related: SYS#4919
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
Pau Espin
Vadim Yanitskiy
Eric Wild
Philipp Maier