VAMOS lchans are behind the primary ones in the ts->lchan[] array.
For example, for TCH/F, there is a primary ts->lchan[0] and a VAMOS
ts->lchan[1]. We should print 'ss 0' for both of them.
Change-Id: I8e7a5a2ecc9b9a33e3ddb76cb1bc04d7802fd320
This patch adds two stats which track cummulative lchan lifetime by
type TCH and SDCCH. These new counters will accomplish two things:
1) Provide a glanceable way to see if lchan durations look healthy. When
examining a site, short-lived (<5s) and long-lived (>30s) TCH lchans
are difficult to tell apart. If we only see short-lived TCH lchans,
there is most likely an RF or signaling problem to investigate. This
new counter will expose channel ages in the VTY output
2) Provide a more accurate count for Erlangs per site. Currently, we
are basing Erlangs on active TCH channel counts per stats period. This
method skews high very quickly. Each active TCH in that period
translates into the full 10s of activity. This counter should improve
accuracy by two orders of magnitude.
Change-Id: Ie3771233ecbd4bc24a24fb22c1064a18e7b8b2b0
As per TS 48.049 Table 8.1.3.1.1 the WRITE-REPLACE message always
has a Warning Security Information IE if it relates to ETWS. This
is also implemented in the libosmocore CBSP parser.
As the previous Change Id369bb3676ba279bafc234378fbe21dbc7b0614b has
pointed out, the CBSP parser structure doesn't even permit any way
of handing a decoded message to us without the warning_sec_info
static struct member.
So as a result, there's also no need to dynamically allocate
bts_etws_state.input.sec_info via talloc. We can have it in-line
as a static struct member and reduce code complexity and runtime
memory allocations.
Change-Id: Ib1b8e4af37b1f9f9398b81dad29942e82218c70b
The proper way to fix this is having a use count on the SCCP conn, one
each for a busy lchan and a busy Location Request. That would require a
bunch more work and testing.
This patch is the least-effort way to avoid the following scenario:
Emergency call is started;
Location Request is started to locate the emergency;
lchan releases early for any reason;
Perfectly fine Location Request gets canceled by Clear Request;
The information was there, but we did not forward the location;
No help at emergency because of my code.
Allow Location Request to complete for these cases:
- rx RLL REL IND (or any other reason for gscon_lchan_releasing())
- rx RSL CONN FAIL
Related: SYS#5912
Related: Idea690a4aa4aecbe4642a16e96d086cc0538564a (osmo-ttcn3-hacks)
Change-Id: Ib44dd05b0adee84234f671313b156ff6625357cc
ACC used to be stared/stopped based on operational/administrative state
changes. The new S_NM_RUNNING_CHG triggers a single boolean based on the
same logic, so we can now simplify the mechanism.
Change-Id: I2e09bcb18a6c3bb2e88bba98579fb4854a6b0699
This way we avoid triggering timers and doing extra poll loops for each
BTS which is configured but not up. It also has the effect of removing
logging about estimating paging buffers for BTS which are down, which
can be confusing.
Furthermore, since work is delayed until the TRX and cell in general is
configured, the first estimation is properly done now since the correct
configuration is in place at that time.
Related: SYS#5922
Change-Id: I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44
This allows different parts of the code to hook to some signals which
allow start/stopping processes based, for instance, on whether C0 is
available or not.
This can be later used by paging or CBSP code. Also ACC code can be
ported to this new system (acc_ramp_nm_sig_cb()).
Same signal can be used for other NM objects, but is left unimplemented
until there's use for them.
Change-Id: I206d4c7863a77fbab6a600126742a6a6b8fc3614
This way code triggered through signal has an updated view of the object
tree when running generic code which queries the current state of
objects.
This way for instance one can use APIs like trx_is_usable() or alike.
Change-Id: Ib46234e3f3e446e866d27b0dfee65edf4af4d2ba
Found by GCC 12.1.0:
smscb.c: In function 'etws_primary_to_bts':
smscb.c:537:13: warning: the comparison will always evaluate as 'true'
for the address of 'warning_sec_info'
will never be NULL [-Waddress]
537 | if (wrepl->u.emergency.warning_sec_info) {
| ^~~~~
In file included from smscb.c:31:
/usr/local/include/osmocom/gsm/cbsp.h:99:33: note: 'warning_sec_info' declared here
99 | uint8_t warning_sec_info[50];
| ^~~~~~~~~~~~~~~~
Indeed, address of &warning_sec_info[0] is always not NULL.
Change-Id: Id369bb3676ba279bafc234378fbe21dbc7b0614b
Don't wait until RSL link goes up to check the reported features against
the config. Do it in the OML bring up right after the features are
reported.
Related: SYS#5922, OS#5538
Change-Id: I6b1b4ef3e163528ed186050d848ec089a4315a7c
Especially during emergencies / natural disasters, it is particularly
likely that networks become unreliable and BTSs disconnect and
reconnect. If upon reconnect there still is an active ETWS/PWS
emergency message active for this BTS, send it to the BTS to ensure
it re-starts broadcasting that message until disabled.
Change-Id: I175c33297c08e65bdbf38447e697e37f8a64d527
This reverts commit 5e2ac29703.
This patch was found to be a troublemaker regarding osmo-bsc
performance, since it's scheduling one timer every 100ms for each
channel. On a BSC with dozens of BTS, each with several TRX, this ends
up in a huge amount of timers scheduled in a tight timeframe, which ends
up in osmo-bsc spending CPU time getting in and out of the poll() main
loop.
Related: SYS#5922
Change-Id: Ibd5123e7f04ae8f4eb8f08b63525527f526f0b2c
This allows external monitoring to see where the T3113 timer has been
adjusted to, in case it is set dynamically.
Change-Id: I533f2ca3c8e66c143154cbf03b827c9cbbacccdf
Reaching this point will only make system load (CPU, mem) grow, making
it hard for the process to keep up with work to do, with no benefit
since the requests will anyway be scheduled too late.
Related: SYS#5922
Change-Id: I6523c6816a4d16b71084d004e979be40cf0aeeb0
In lchan_fsm_cleanup(), ensure that the time_cc timer is actually inactive
before deallocating. Do so via lchan_reset(), to also make sure the
timer is stopped in all other situations where the lchan is deactivated.
This fixes an infinite-loop deadlock as described in OS#5554:
- run BSC_Tests.TC_chan_act_ack_est_ind_noreply
- restart the BTS process after the test is done
- osmo-bsc enters infinite loop in osmo_timer_del()
The reason is that lchan_fsm_cleanup() fails to stop a running active_cc
timer upon lchan deallocation. TC_chan_act_ack_est_ind_noreply
incidentally terminates OML while the timer is still active.
Related: OS#5554
Change-Id: I901bb86a78d7d021c8efe751fd9d93e5956ac0e0
We have seen an increased CPU load in osmo-bsc recently since the paging
improvements where merged, centered round poll() calls.
It is expected most of them will be fixed with previous patch. In any
case, let's avoid unnecessary poll() calls being called for no reason.
Related: OS#5922
Change-Id: Ie767bdc8d4353aafe375a424e02d698ef7fd3dea
We want to recalculate the timer based on last time the work_timer was
triggered (that is, the time when the worker re-armed the pag req to
retransmit). We don't want to recalculate based on the last time the pag
ret tro retransmit was scheduled.
In loaded paging queue, there's lots of retrans (let's say 200) and it
may take more than 500ms to actually retransmit them. That means in most
cases we could end up in a situation where only pag req to retrans where
in the queue, hitting this recalculate path. Since the 500ms were for
sure elapsed, that would most probably schedule the work_timer at {0,0}
for each new paging request that arrived. As a result, the worker would
be scheduled lots of times per second (once for each new req arriving)
and only submitting 1 pag req (the new one) plus potentially 1 or
serveral pag req to retransmit.
In summary, there was not throthling applied in the scenario where only
pag req to retransmit where in the queue and new pag reqs kept arriving.
This incurrs into augmented paging throughput and also augmented
frequency of polls().
Related: OS#5922
Fixes: 4821c9f4df
Change-Id: I7ce6f436286b50dc31331d218ff256cf7be3f619
There's no need to use pointers there, it is only asking for errors from
code handling the data structe from the signal by attempting to change
them. Even for mem size point of view it doesn't make sense, since it's
3 byte vs a 4 byte pointer.
Furthermore, this is a preparation for new commit, where the NM object
current state will be updated before emitting the signal. This patch
eases a lot the follow up mentioned patch.
Change-Id: I9b648dfd8392b7b40bfe2b38f3345017481f5129
One callback function was being registered for each BTS.
That means, when a C0 RCARRIER of one specific BTS changed NM state,
the outcome on whether to trigger/abort ramping would end up being
applied to all BTS.
Change-Id: I56c4dd1809fdcf8441a69bf77ad173e1ccc8eea7
This makes sure code accessing those fields is not changing its values,
since it would make no sense to change those. Follow up commit will make
convert those pointers to be full structs instead, as there's no need to
have pointers there.
Change-Id: I9979e62eac861e25bbe2161ab187ddb2b40fd097
Having 2 signals makes all code handling them more complex, specially
because S_NM_STATE_CHG_OPER could actually provide any change in
admin/oper/availability.
Both signals already provided the same kind of data (the whole
admin/oper/avail state change), so let's simply merge the signals
themselves. Current code really doesn't act differently for those 2
signals anyway.
Change-Id: Ia86d20a42b859063d0327b940ba528ec1438b04a
This code is not used currently. Furthemore, it makes little sense to
transmit an OPSTART if the BTS already told us it is enabled (because
OPSTART is what moves the BTS into operational enabled state).
Change-Id: I2c65e0803fbde7de9497089b562275baad58936a
This patch adds two stats which track cummulative lchan lifetime by
type TCH and SDCCH. These new counters will accomplish two things:
1) Provide a glanceable way to see if lchan durations look healthy. When
examining a site, short-lived (<5s) and long-lived (>30s) TCH lchans
are difficult to tell apart. If we only see short-lived TCH lchans,
there is most likely an RF or signaling problem to investigate. This
new counter will expose channel ages in the VTY output
2) Provide a more accurate count for Erlangs per site. Currently, we
are basing Erlangs on active TCH channel counts per stats period. This
method skews high very quickly. Each active TCH in that period
translates into the full 10s of activity. This counter should improve
accuracy by two orders of magnitude.
Change-Id: I1b0670c47cb5e0b7776eda89d1e71545ba0e3347
So far we only calculated the expiration time based on the amount of
requests of the same paging group in the BSC queue.
However, also extra time has to be taken into account regarding requests
of other paging groups. This is important because requests of all paging
groups are mixed in the BSC queue, meaning having a lot of requests from
other groups before a certain req will anyway delay transmit of that
req to some extend.
Related: OS#5537
Change-Id: Ib55f947c5d3490b27e1d08d39392992919512f9a
This was so far workarounded in tests by manually freeing the fields.
However, in follow-up patch the paging queue will also be properly
freed, so free of the counters needs to be previously fixed too so that
counters are freed at the right point of time.
Otherwise, during paging queue flush, counters are used and would crash
because they were freed before the BTS object in each test's bts_del().
Change-Id: Id213e21cf9bfc5439021e459c22ba4704d8cae2b
Use the same one as used to decode the message in osmo-bts.
This patch doesn't cause a change in logic since both headers are binary
identical.
Change-Id: Ideb863fdaedf77caac1a320de6696ba4f507a398
* Don't copy features for osmo-bts and nanobts initially, wait until
BTS reported its features
* Checks for BTS features in VTY cmds: pass if features are not known
(not yet reported by the BTS), fail if the feature is missing
* Once BTS reports its features, check relevant VTY config parts again
Related: SYS#5922, OS#5538
Change-Id: I7fca42a39a4bc98a6ea8b9cfab28c4bad3a6a0aa
As pointed out in code review, for nanobts we need to be able to combine
the reported features with a list of features we assume that the bts
model supports. This is because the enum of features is based on what
nanobts is able to report, but was extended for osmo-bts.
Related: SYS#5922, OS#5538
Change-Id: I7bdbf28c148877275048e070dce7f503ca5e6226
If the queue is only holding requests in retransmition state, when we
add a new one, we have to re-calculate the work timer to a lower value
instead of letting it wait for the first retransmit to be ready.
Change-Id: Ibd4f8921c92f7481f0b9943041c141640ab812c8
There's no need to keep the timer running, since anyway upon next
trigger it will simply early exit in paging_handle_pending_requests()
becuase there's no more work to do.
Change-Id: I096ab7231f52c741c5fded37acd5b309e1de06e3
Vadim Yanitskiy
Michael Iedema
Harald Welte
Neels Hofmeyr
Pau Espin
Oliver Smith