TS 48.049 states the following rules for the KILL COMPLETE / FAILURE
messages:
The Number of Broadcasts Completed List IE, if present, contains for
each cell the total number of broadcasts of the killed CBS message.
The Cell List IE, if present, contains the cells in which the emergency
message is successfully terminated.
As any message can only be either emergency or CBS, this means that
we can (at maximum) have only one of those two IEs in the message.
As there is no explicit indication in the KILL whether it relates
to CBS or Emergency, we use the "Channel Indicator" IE, which is
specified as "only included if the message refers to a CBS message".
Related: SYS#5906
Closes: OS#5541
Change-Id: I9a43d386da01f085663d231a555b8b5acc99faca
With previous patch Idf2d933aa8b03b1f708e56a08707fe6c620a97aa, the
features get copied from the BTS model to the BTS. For rbs2000, bs11 and
nokia_site, an empty feature set was copied because the features weren't
set at this point. Fix this by moving the set_feature calls to _init().
Notably the set_feature calls had been moved for osmo-bts and nanobts
from _start to _init already in 2013 in the patch e84dd98d
("sysmobts: Avoid a crash when trying to look-up a BTS").
Fixes: 2d818b9f ("Always use reported features if available")
Related: SYS#5922, OS#5538
Change-Id: I43389ae48d5e0f01381602751f6bad902011b158
When building with CFLAGS="-flto -Wall", I get the following:
meas_pcap2db.c: In function ‘pcap_cb’:
meas_pcap2db.c:64:27: warning: pointer targets in initialization of
‘const char *’ from ‘const u_char *’
{aka ‘const unsigned char *’} differ
in signedness [-Wpointer-sign]
64 | const char *cur = bytes;
Change-Id: I84d8e6f290bda0f03476f182f292ecc7a9e520f2
When building with CFLAGS="-flto -Wall", I get the following:
meas_db.c: In function ‘_insert_ud’:
meas_db.c:62:23: warning: unused variable ‘rowid’ [-Wunused-variable]
62 | unsigned long rowid;
meas_db.c: In function ‘meas_db_insert’:
meas_db.c:89:13: warning: unused variable ‘rc’ [-Wunused-variable]
89 | int rc;
meas_db.c: In function ‘check_create_tbl’:
meas_db.c:260:16: warning: unused variable ‘rc’ [-Wunused-variable]
260 | int i, rc;
Change-Id: Id12958f67a47b6b3ebece7252e4f7c0835d4bb96
Make sure we don't check against bts->model->features instead of
bts->features by accident.
Related: SYS#5922, OS#5538
Change-Id: I47eef4978aaf9e20fc00a3ca029568671bd09d8d
Instead of sometimes checking against hardcoded BTS model features, and
sometimes against features reported at runtime (which only some BTS
models do):
* copy the hardcoded BTS model features to BTS features initially
* do all checks against BTS features
Related: SYS#5922, OS#5538
Change-Id: Idf2d933aa8b03b1f708e56a08707fe6c620a97aa
Let all changes of the bts model go through this function, so we can in
a future patch copy over the bts model's features to the bts.
Related: SYS#5922, OS#5538
Change-Id: I8475c8c20eb72411e8ca820181d1c8603c22a56d
Just log all reported features, instead of comparing them against an
expected set of features and logging mismatches. The point of reporting
features from the BTS at runtime is that the BSC can support various BTS
versions with various feature sets.
Related: SYS#5922, OS#5538
Change-Id: Ibd79bc7ef802d8e95e05d746df182ff974b78e29
After the lchan release, the gscon would go into the Clear dance with an
arbitrary cause value. Instead, explicitly ask for a Clear upon
pre-emption, with the proper cause value.
Related: OS#5535
Change-Id: I20108f7b4769400b89b7b0d65c8dab883bf87c46
So far the we indicated pre-emption in the release cause of denying an
emergency setup, instead indicate protocol error.
When emergency calls are disallowed, it is not pre-emption (making room
for an emergency call) but a protocol error (MS asks for emergency call
when the network does not allow it).
Related: OS#5534
Change-Id: Ia195621165cb7bbe33e6c2e915abc42ab16a2a4f
The range used for this variable is 0-100, so no need to use a signed
integer. Morever, uint8_it is enough for the range.
Change-Id: I863d9531baf5308b45a2ebe60266ba02d1041cc3
Its name is totally misleading, since they seem to be related to
GetAttributes messages rather than SetAttributes.
Change-Id: I306cb407dbd9b98e301b5d93046bdadcb466b82b
Currently, the Tx paging_req queue at the BSC always has new paging
requests adding at the end (as long as the subscriber is not already in
the queue).
That means, if the queue is full of retransmitions, it will take a long
time until the first paging_req is sent towards that subscriber.
The rationale here is that it makes sense to attempt the first paging
ASAP, and give lower prio to paging_req retransmitions, since it may
well be that those other subsribers are not available/reachable and
won't answer.
Related: SYS#5922
Change-Id: I1ae6d97152c458247bc538233b97c2d245196359
Having one paging request being sent every PAGING_TIMER (500msec) is too
slow in case BSC is serving lots of subscribers on a BTS. Hence, we want
to send many paging requests at once while still trying not to fill the
BTS buffer.
Morever, we don't want to send tons of paging requests at once, hence we
limit the amount of paging requests sent in one timer iteration
(MAX_PAGE_REQ_PER_ITER) in order to avoid the BSC doing lots of work
there at once, keeping it busy from processing other tasks.
Related: SYS#5922
Change-Id: I609fa67834b426456f48f6fb2acb601c5905f178
The variables are unsigned, so -1 gets actually translated to UNIT16_MAX
when the value is casted to uint16_t. Let's do that explicitly so that
readers don't think those are signed variables.
Change-Id: I02ad80e5d10f1a47cdf712f7f7c576a2e20fe607
If an lchan needs to be released to make room for an emergency call,
send the proper release cause ("pre-emption").
Related: OS#5534
Change-Id: I0423621d15ace11a53ae1653e5e7f5cb93605edb
Order the features and add a comment that reminds of updating OsmoBTS
to actually report the new features that are assumed to be supported
here.
Related: SYS#5922, OS#5538
Change-Id: I6f041648990db4ae479538cf3970c826bc6703ed
pcu_sock.c: In function ‘pcu_tx_info_ind’:
pcu_sock.c:197:2: error: #warning "isn't dl_tbf_ext wrong?: * 10 and no ntohs" [-Werror=cpp]
197 | #warning "isn't dl_tbf_ext wrong?: * 10 and no ntohs"
| ^~~~~~~
pcu_sock.c:199:2: error: #warning "isn't ul_tbf_ext wrong?: * 10 and no ntohs" [-Werror=cpp]
199 | #warning "isn't ul_tbf_ext wrong?: * 10 and no ntohs"
| ^~~~~~~
they made it here from osmo-bts.git
(b4999b60d4 states that the PCUIF support
was copied from there). The gitlog shows that these warnings were added
in 744f745d7a508605254afa8f78412ad410d153b0 by jolly (in 2012!)
together with the PCUIF support, and before
c1368d4ebe49f8e01f1f5fff3bc3583cb5960c1d these warnings were in German:
"ist dl_tbf_ext nicht falsch?"
As nobody has bothered for the past ten years, degrade them to comments.
Change-Id: I9ef7e18f56aa86b48f0ffeec58406260736170f3
From Vadim in https://gerrit.osmocom.org/c/osmo-bsc/+/27818
By checking !(link_id & 0xc0) we actually make sure that this is not
SACCH. So the comment "but not if the link_id contains a TCH flag" is
wrong, there is simply no such thing like "a TCH flag".
Change-Id: I8f0f6d7bf952426fd2f27802f1499d6ee8981982
If the BTS tells us SAPI=0 is gone, there is no point in trying to keep
the lchan around for SAPI=3, as it is not possible to operate GSM with
SAPI=0 gone.
This occurred with RBS6000, which don't seem to send RLL REL IND for
SAPI3 after doing so for SAPI0. However, rather than an
ericsson-specific hack, let's make this the general rule: If SAPI=0
is gone, don't stop the lchan from being released.
Change-Id: Ia9caa5b0a5efdc459d94621367376927959a6e65
Related: OS#5530
If we receive something unexpected, log it (and free the msgb!)
Change-Id: I43fab6a3a1c5e7a6545d6ef848636f5ba1be1576
Related: OS#5530 (only tangentially related)
The penalty timer low_rxqual_as() is only supposed to apply on an
intra-cell re-assignment. However, a segfault has been reported that
apparently applies it to inter-BSC handover.
Make sure that this timer applies only to re-assignment. In effect this
makes sure that the target bts is non-NULL and avoids the segfault.
Related: OS#5525
Change-Id: Ifdb9891fbe7e3f3423a96371def4fcbf2fc0bc0d
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I030c88545cdc71b3ad9e83f9c2ba7b27177c2ac8
When responding to a CBSP KILL with a CBSP KILL COMPLETE, make sure
we include the optional "Number of Broadcasts Completed List" IE
in order to inform the CBC about how many times the just-killed
message had been broadcast before it was killed.
It seems some CBCs expect this IE to be present, while 3GPP TS 48.049
lists it as optional. Since we alrady have code to encode it, let's
just always add it - it certainly won't hurt.
Change-Id: I47aebd613dfc6dd9261ea9019a51aff0cd6470d8
Closes: SYS#5906
This is cosmetic change making the default multi-rate configuration
easier to read/understand and modify.
Change-Id: I3d03c2188d007a60a86961a346744400bc81d4e6
Related: SYS#5917, OS#4984
* Always say 'codec mode', not just 'codec'.
* Suggest proper modes in AMR_{TH,HY}_HELP_STR.
* Use 3GPP's definition of threshold and hysteresis.
* Clarify that threshold and hysteresis values are in 0.5 dB steps.
Change-Id: I996eae8aafeb2850e5e1a6f5a7764d745e1289b5
Related: SYS#5917, OS#4984
Now that we have separate header/code files for the power control,
let's move the related definitions there. This change makes the
code consistent with osmo-bts, where it's already done this way.
Change-Id: I1cb3f6bfba0306e8f371dcd5162d1813beb3a088