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
Before this patch, on each BTS a 500ms timer was used to schedule some
work, sending up to 20 paging requests verytime.
This means, however, for an initial paging request it may take up to
500ms delay to be scheduled to the BTS, which is huge.
While we still want to maintain this 500ms interval for retransmits, it
doesn't make sense to wait that much for other cases. It's far better
sending less requests (10 instead of 20) every half time (250ms instead
of 500ms), since it will spread the load and paging more over time,
allowing for other work to be done in the middle.
Change-Id: I7a1297452cc4734b6ee8c38fb94cf32f38d57c3d
PAging happens over C0 RSL link, not over OML, so let's actually
validate that the C0 RSL link is up before paging instead of the OML
one.
Change-Id: I11e5bb6f952534763935aa01470e514d4af247ed
Decouple credit_timer from event "available_slots became 0".
Let's actually relate credit_timer to the fact of not receiving CCCH
Load Indication: If no CCCH Load Indication is received (cch_load_ind_period * 2),
then assume we are below CCH Load Indication threshold (10% load) and
start estimating the available_slots in a cch_load_ind_period*2 time
frame.
Moreover, in paging_schedule_if_needed(), there's no use in delaying
start of processing work if the work_timer is not already doing work.
Related: OS#5537
Change-Id: I6a0da03c408270044079e81d431f6641527c00cd
From 3GPP TS 48.018:
If only the New Serial Number IE, and not the Old Serial Number IE, is
included in the WRITE-REPLACE message,then the BSC shall interpret the
message as a write request, i.e. a broadcast request of a new emergency
message without replacing an ongoing emergency message broadcast.
Only one emergency message at the time can be broadcasted in a cell. If
a write request is received for a cell where an emergency message
broadcast is currently ongoing, the write request is considered as
failed.
Change-Id: I376c9e796f3a2d26b22d0451f15ef1debbd7f656
Closes: OS#5539
Related: SYS#5906
So far, we only implemented KILL for CBS, but not for Emergency
broadcasts. This patch adds KILL support for Emergency, by which
a CBC can terminate broadcast of a previously-started Emergency
message before its scheduled period ends.
Change-Id: Ie91939b93de6847eeb5d00c97a137c43721c2711
Closes: OS#5540
Related: SYS#5906
ETWS is sent over both dedicated channels and broadcast channels.
Some BTS models may not support the latter, but it is still useful
to start the related timer to ensure bts->etws.active gets set to
false after the emergency period has concluded.
Change-Id: I448be9fd75b87c1f7333a5bfa4f6ba238569fdc3
Only if we store data like the CBSP message_id and serial_number
we are able to later (in a subsequent patch) match a CBSP KILL
for ETWS/PWS and stop emergency broadcast.
Change-Id: Ide74638880d7e3c6a7c774bf6320d3dce4b11c74
Related: OS#5540
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
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
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 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
For the sake of consistency and code readability, initialize the
power loop control interval (P_Con_INTERVAL) for both Uplink and
Downlink directions in the same function.
Change-Id: Ie3d4b481cbfacf27004787616e22b6f8a863b47b
When the assignment succeeds, the assignment_request has taken effect
and whatever it requested should now be in effect.
Hence copy the new RTP information from the assignment_request to the
conn's storage indicating what is currently used, always, not only when
lchan_changed == true. The RTP information may have changed also from a
Mode Modify where the lchan stays the same but changes its mode of use,
e.g. from signalling to voice.
When there is no RTP involved, this data is zero or empty, so there is
no harm in copying it, always.
Related: SYS#5916
Change-Id: I0788d1f013b8f820f559b6ed58a5f9bb8a02e0b4
When the assignment fails, we roll back the MSC side RTP endpoint at the
MGW that may have been created before the failure occured. On success,
we clear the mgcp_ci pointer so it is not rolled back.
Always clear this, not only when lchan_changed == true. That is because
a channel Mode Modify may also have added a voice stream that should
retain the newly created RTP endpoint at the MGW.
If no voice stream is involved, the pointer should already be NULL.
There is no reason to have a condition for clearing this pointer.
Just always clear it.
This fixes all voice calls that modify a TCH lchan from signalling-only
to voice mode. Before this patch, their MSC side RTP endpoint was DLCX'd
right on assignment success.
In particular, this fixes Emergency Calls (which usually get a TCH lchan
assigned right from the start, and hence do a Mode Modify to add voice).
Related: SYS#5916
Change-Id: I5ab10ee7fd9c5d7608e8a06893881d990943feed
According to 3GPP TS 45.002, table 3, unlike the CCCH+SDCCH/4+CBCH
combination, which can only be allocated on C0/TS0, the SDCCH/8+CBCH
can be allocated on C0..n/TS0..3. In other words, having CBCH on
e.g. TRX1/C1 is perfectly legal. This is why in gsm_bts_get_cbch()
we should check all transceivers, not just the C0.
Change-Id: Ie79ccff4f8f0f1134757ec0c35e18b58081cc158
Related: SYS#5905
When bad RxQual causes handover to a cell with weaker RxLev, then
handover oscillation *will* happen, as shown in test_rxqual.ho_vty.
Introduce a penalty timer for a cell where we had bad RxQual.
This delays handover back to the cell with stronger RxLev by the penalty
timeout; hopefully the interference is gone after the timeout.
Usually, we set new configuration elements so that osmo-bsc behaves the
same as before the config item was added. In this instance, this makes
no sense, because no-one ever wants handover oscillation from bad
RxQual, which is guaranteed to happen without the new penalty timer. Set
it to 60 seconds by default, same as other penalty timers.
Related: SYS#5911
Change-Id: I057b156604a104a26a7ce45d1c7adadbf452c932
This add support for handling inbound MESSAGE STATUS QUERY from the CBC,
and responding with MESSAGE STATUS QUERY COMPLETE or MESSAGE STATUS
QUERY FAILURE, as applicable.
Change-Id: I3b738dc29d0ead4f735abeeb6960d3675cb05ae2
Related: SYS#5909
I find it weird that we store the A5 algorithm ID in a format that
is used on the wire: N + 1 (valid for both A-bis and A interfaces).
What confused me even more is that in some functions we print it
as if it was in a normal, human-readable format. And this is
also why one can see weird constructions like:
if (lchan->encr.alg_id > ALG_A5_NR_TO_RSL(0)) { ... }
Let's ensure that our internal structures use the A5/N format:
alg_id=0: A5/0 (0x01 on the A-bis/A interface)
alg_id=1: A5/1 (0x02 on the A-bis/A interface)
alg_id=2: A5/2 (0x03 on the A-bis/A interface)
...
alg_id=7: A5/7 (0x08 on the A-bis/A interface)
so that we can print and compare the value of alg_id without using
additional arithmetics. Let's also rename 'alg_id' to 'alg_a5_n'
as it most clearly indicates which representation it is storing.
This is how the above code snippet would look like:
if (lchan->encr.alg_a5_n > 0) { ... }
Change-Id: Ieb50c9a352cfa5481aebac2379e0a461663543ec
When copying the CBS page content from CBSP to RSL data structures, we
use the User Information Length as length argument in the memcpy. The
logic for that is that only this part of the message contains valid
data.
However, as the user information length is not passed on via RSL or
transmitted over the air, the receiving MS will get a page with
zero-initialized padding, rather than whatever the originator of the
message has specified. As zero bytes in the 8bit domain might get
translated into @-characters in the 7bit domain, this creates problems.
So instead, let's always copy the entire page (82 bytes) to ensure
transparency when passing on information from CBSP to RSL.
Change-Id: Iffcf1f6a7d41a08a2feffc6f2ac5634d940b63aa
Closes: SYS#5904
On receipt of the Perform Location Request message, the BSC needs
to forward it to the SMLC. If the abovementioned IEs are present
in the original message, they must be delivered to the SMLC too.
Change-Id: Ifeb359b0468845da0b4fed9e2e4b79256067fa81
Depends: libosmocore.git I8775a93cf4089b1752d040e43d2cba6b8997f955
Related: SYS#5891
On receipt of the Perform Location Request message, the BSC needs
to forward it to the SMLC. If the LCS Client Type IE is present
in the original message, it must be delivered to the SMLC too.
Change-Id: Id3262e67c3dc25cb93fbd52a40689c5529ca2d41
Related: SYS#5891
It's really confusing having a "default" struct whose inner values are
changing based on previous state. Furthermore, it's only used in
generate_si13() so there's no need to keep it outside the function.
Let's move it inside the function and rename it to avoid confusion.
Change-Id: I3ae4dd017dd4dad10c0365d21727666dd8e9fd41
It makes no sense to enable that field if the ext_info.egprs_supported
field marks EGPRS as disabled.
From TS 44.060 11.2.5a:
"""
This message may be sent by an EGPRS capable mobile station
*in a cell supporting EGPRS* and where the EGPRS_PACKET_CHANNEL_REQUEST
parameter indicates that this message shall be used.
"""
Related: SYS#5891
Change-Id: I5ac173116f8681d7340b75b2baff110158fab9fd
If "bts->gprs.mode" was changed dynamically at runtime (VTY or CTRL), it
could happen that the egprs_supported was kept as "1" if the dynamic
change was EGPRS->GPRS.
In summary, if EGPRS support was set, it couldn't be unset until BSC was
restarted.
Related: SYS#5894
Change-Id: Id2c2319044da474642c4cc710baa27cfee4fb592
Values in ext_info are modified in several places, so it's difficult
validating whether we deviate from default. Let's always send it so that
we always have a clear view on what the MS uses.
This fixes a bug where paging_coordination or ccn_active would not be
announced if GPRS was not enabled.
Related: SYS#5894
Change-Id: If96de3e0d77503cf6344dfbc611f9260ac3281aa
The value in bts->si_common.chan_desc may get out of sync with the
actual value in net->T_defs (e.g. after changing it via the VTY),
so we need to sync it in generate_si3().
Note that synchronizing the values in cfg_net_per_loc_upd_cmd is
a bad idea, because the value of T3212 may also be changed using
generic timer management commands.
Change-Id: Iee291623c2825505eeb5175adcedadfe35375b9e
Related: SYS#5888
This was overlooked during the code review. GCC does not complain
because internally both 'enum handover_scope' and 'bool' are
interpreted as 'int'. Found this while running my WIP testcase
TC_srvcc_eutran_to_geran_a5_3. This change makes it pass.
Change-Id: I807fd4a0e700e54c67ca3547d9c0c1b442dd1c54
Fixes: I4e5b1163a71443d706f14ce4bfd5c2294c320432
Related: SYS#5838
According to 3GPP TS 44.018, section 9.1.15, the RR Handover Command
message may optionally contain the Cipher Mode Setting IE (10.5.2.9).
Section 9.1.15.10 states that this IE may be omitted in case of the
intra-RAT GERAN-to-GERAN handover, however in case of the inter-RAT
handover (e.g. EUTRAN-to-GERAN), this IE *shall* always be included.
Change-Id: I1d270e82d0a9b12897fc94dae4e8999aa132a22f
Related: SYS#5838
When running a multi-trx setup, upon stopping osmo-bts one can see:
DCHAN ERROR lchan_fsm.c:80 lchan(0-1-7-TCH_F-0)[0x612000010120]{UNUSED}:
(type=NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR
DCHAN ERROR lchan_fsm.c:144 lchan(0-1-7-TCH_F-0)[0x612000010120]{UNUSED}:
(type=NONE) lchan activation failed
(lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR)
These messages show up when the following conditions are met:
* BTS model speaks A-bis over IP (ip.access, e.g. nanoBTS), and
* BTS has more than one transceiver configured.
The problem is that unlike traditional E1 based BTS models, ip.access
ones have a single global A-bis/OML link for all transceivers. Thus
when it goes down, in inp_sig_cb() we need to notify all timeslots
*of all TRXes*, not just TRX0.
Change-Id: I3dc657ac5a2c5334747bd4f4db1a658acb323942
Fixes: OS#5479
Historically, we first only had
BSS_MAP_MSG_ASSIGMENT_RQST
^
with missing N. libosmocore has this renamed a long time ago and
provides a shim #define that makes the typo version still work.
Having the typo is bad for grepping, so rather use the non-typo name.
Also rename the constant for the ass req counter which so far has a
similar typo, and fix the same typo in the counter description.
The counter name exposed on CTRL luckily doesn't have this typo in it.
Change-Id: Ieaa4f4e6e6f7e1563b1bd15a83f0c1a9112d2312
The ho_fail() macro includes a newline, so the callers should not add
one. Fix these cases where the extra '\n' fragments the logged message.
Related: SYS#5839
Change-Id: Ifdbce98be70c1aa127ae008d7a77b9795fd250d3
So far we completely ignore the codec list from the MSC in Handover
Request messages. This leads to error messages in subsequent handovers
because there is no Codec List stored on the conn:
DHODEC ERROR handover_decision_2.c:390 [...] No Speech Codec List present, accepting all codecs
Besides the error log, in hodec2 we may subsequently take bogus or
unexpected codec decisions, ignoring the MSC's choice of codecs, or in
the worst case picking an unsupported codec.
This also has implications on what type of lchan we choose for handover
target in hodec2: say, if no half rate codec is supported as per the
MSC's request, we normally avoid handover to a TCH/H, etc.
Intra-BSC HO after an Inter-BSC incoming HO is the only case where this
problem occurs, in every other scenario there is an Assignment Request
from the MSC, from which we properly store the MSC's codec list.
3GPP TS 48.008 does indicate that on AoIP this codec list shall be
included. So reject HO Request with missing Codec List, as we already do
for Assignment Request on AoIP.
This makes TTCN3 BSC_Tests for inter-BSC incoming HO fail, because our
tests so far omit the Codec List (MSC Preferred) on AoIP. The related
fix of the tests is If06de9c9b43d79f749447a4e2a340176eef75c79.
Related: SYS#5839
Depends: If06de9c9b43d79f749447a4e2a340176eef75c79 (osmo-ttcn3-hacks)
Change-Id: I117cc29d6d11db77d160de654f43f5993db6ee21
"inter-BSC MT" was the terminology of an early development stage of
inter-BSC handover, code review requested "incoming" instead. This one
was missed when applying code review.
Same in a code comment.
Related: SYS#5864
Change-Id: I1ca810542e89980ffda11876fd30626467e452d1
Teach osmo-bsc to handle empty N-Connect. So far we were always
expecting user data in an SCCP N-Connect from an MSC. However, it is
perfectly valid for an initial BSSMAP request to follow later.
This is relevant for:
- Handover Request (incoming inter-BSC handover)
- Perform Location Request (query physical location of the MS)
Add state WAIT_INITIAL_USER_DATA with new timeout net X25. Always enter
this state so that we don't have two separate code paths for handling
initial user data.
Related: SYS#5864
Change-Id: I535c791fa01e99a2226392eb05f676ba6c3cc16e
Also increment message counter for the case that a Perform Location
Request came in the initial SCCP N-Connect message.
Related: SYS#5864
Change-Id: I3f78ce73eb16fdff1f19359963405b2235000fc4
During inter-BSC incoming handover, there is no previous lchan to be
switched, so this event always comes in the READY state of
lchan_rtp_fsm. No need to complain about that and confuse log readers.
Related: SYS#5864
Change-Id: I96fd53b8c8da621a40bd65f85070eabd030cc875
According to 3GPP TS 44.018, section 10.5.2.1b.2, only ARFCN values
in range 1..124 can be encoded using the 'bit map 0' format. Before
this patch, ARFCN values belonging to E-GSM band (0, 975..1023) were
ignored in bitvec2freq_list(), and thus not present in the resulting
Cell Channel Description IE.
Change-Id: I17739e6845cd84e2a81bc406dd532541f7c52cb6
Related: SYS#5854
I find it cleaner to relay on the counter ('arfcns' in this case) to
check if the set is empty, rather than checking one of the resulting
values ('max'). There is just a cosmetic change.
Change-Id: I29ca51461beec053bcb8b8210f0ad24bb8c7765f
Related: SYS#5854
The callers of this function do pass different mask values, which
should be passed to gsm48_decode_freq_list(). Instead, 0xce was
passed regardless of the given mask value.
Change-Id: I47f2eab54ef8487b14992fd7a69d5c9ccbb3f5cf
As the comment above the fix suggest, the encoding is in 10ms units.
osmo-bts is also doing the proper:
"""
uint8_t t3105 = *TLVP_VAL(&tp, NM_ATT_BTS_AIR_TIMER);
bts->t3105_ms = t3105 * 10;
"""
Related: SYS#5838
Change-Id: Ie190514ee35d1ca81b70e9180bf7393b973d3504
Improve the function doc. Remove a comment at a caller, because that
information is what the function doc is for.
Rename the array to codec_by_strength, because it is not the codec
strength but the codec number listed in the array.
Related: SYS#5839
Change-Id: Iaed6b97c31e4ccb1f28ca7e64596d5e20563b392
In the field we saw Handover Requests without any Chosen Encryption
Algorithm IE, and osmo-bsc completely failed on those. This made me
understand my mistake from when I wrote this handover code.
So far, from a BSSMAP Handover Request, we (I) used only the Chosen
Encryption Algorithm IE to pick the encryption to use on the target
lchan. That is very wrong.
Instead, figure out the intersection of permitted algorithms MSC & BSC,
and pick the best of those. Which means, actually, completely ignore the
Chosen Encryption Algorithm IE.
In the message, the permitted algorithms are passed as a bitmask. The
current code using gsm0808_dec_encrypt_info() passes this on as an
array. In order to select_best_cipher(), I could convert that array back
to a bitmask. Instead pass the bitmask on from message decoding
alongside the struct gsm0808_encrypt_info in req->ei_as_bitmask.
In handover_end(), change the condition so that we can also pass
HO_RESULT_FAIL_RR_HO_FAIL to emit a Handover Failure.
Related: SYS#5839
Change-Id: Iffedc981b60d309ed2e5decd5efedee07a757b53
The naming confused me so that I wrote buggy code again. Hopefully this
clarifies which representations the code paths are using.
In the macro code, highlight the error case of n <= -1 explicitly.
Also add ALG_A5_NR_TO_PERM_ALG_BITS. I need the 1<<n case in an
upcoming patch.
Related: SYS#5839
Change-Id: I7557ae97764bba09c906748a18e9031dfb362611
This patch imposes no logical change in the code on itself, but makes
sure people compiling osmo-bsc uses an old enough libosmocore
implementing Cell Identifier SAI. This is important since adding the SAI
ID (CELL_IDENT_SAI) displaced CELL_IDENT_WHOLE_GLOBAL_PS to a new
number outside of the 3GPP range for cell IDS (4 bits, this way we
garantee we won't have the same problem again).
This means there was an ABI breakage (see Depends below).
As a result, using an osmo-bsc compiled against an older libosmocore
, and then using at runtime against a newer version of libosmocore, will
most probably provoke some RIM features to not work properly, since
libosmocore will handle CGI-PS cell ids sent by osmo-bsc as SAI ones,
and most probably do wrong comparisons when matching (they only match up
to LAI included).
ABI break analysis:
osmo-bsc uses CELL_IDENT_WHOLE_GLOBAL_PS in:
* gsm0808_dec_cell_id_list2() -> this is called on stuff received from the
network, so it's actually fine handling it
correctly as CELL_IDENT_UTRAN_SAI instead
of CGI_PS.
* gsm0808_cell_id_list_add
same_cell_id_list_entries
gsm0808_enc_cell_id_list2
cell_id_to_cgi-> On old osmo-bsc, When
CELL_IDENT_WHOLE_GLOBAL_PS is passed
to be encoded as CGI, RAC byte is
taken for encoding instead of 2nd CI byte.
* gsm0808_cell_ids_match
gsm0808_cell_id_u_match
cell_id_to_cgi -> If CELL_IDENT_WHOLE_GLOBAL_PS as 0x11
(CELL_IDENT_UTRAN_SAI), 1 byte offset when
comparing (1 byte of RAC is taken converting to
CGI instead of the 2nd byte of CI). That means
match would be wrong if 2nd byte of CI differs.
Related: SYS#5838
Depends: libosmocore.git Change-Id Id25e563febdb7640174540136225f399515a0089
Change-Id: I70972efffefd57fd36332fab539683696c32f4a5
The timer (T4) that controls the re-sending of the BSSMAP RESET can not
be changed via the VTY, althrough it is defined via a tdef struct. Lets
add a description along with default values to make it configurable via
the VTY.
Change-Id: I1fb5699220ab8a643a168567a89c6f381fe433a7
Related: SYS#5796
The SAPI "n" REJECT messages were being sent with DLCI keeping the RSL
LINK ID format, which is not the same for CC bits.
With this patch, TTCN3 test BSC_Tests.TC_rll_sapi_n_reject_dlci_cc
passes again.
Related: OS#4728
Related: SYS#5047
Change-Id: Icc187f594743040a3d9b8beff7d9cfc21dd6eb08
Skip the BSSMAP Clear and SCCP RLSD parts and immediately deallocate the
gscon when there is no SCCP connection present. Before this patch, such
conn would stick around for a minute before a timeout deallocates it.
Related: OS#5337
Change-Id: I8c8537acf6b47b121903197608636c43ae601a57
Properly implement the separate conn release stages in separate FSM
states:
x) sent Clear Request, wait for a Clear Command from the MSC.
Timeout after a configurable 60s.
y) after a Clear Command and sending a Clear Complete, wait for the SCCP
RLSD. Timeout after a configurable 60s.
z) terminate after the RLSD is received / after timeout.
handover_test.c needs a little tweak to make the MGCP release work with
its fake MGCP client, because cleanup now ensures to invoke
gscon_forget_mgw_endpoint() in all cases.
Related: I680ec4ed866aa5f0b1ff29e7e98322615cfb288d (osmo-ttcn3-hacks)
Related: OS#5337
Change-Id: Ie975117d37f38ba853589dc7f8d3e94f8f9586b2
The way the ST_CLEARING is entered before this patch has various
symptoms of how I / we used osmo_fsm when we were still FSM amateurs in
Osmocom. Patch that up:
- In gscon_bssmap_clear(), ask for a state transition to ST_CLEARING
first. Go ahead only if it is allowed.
- move the Clear Request messaging to ST_CLEARING's onenter function.
- Fix the timeout behavior: by using conn_fsm_state_chg(), use the
actual proper X4 timer value for ST_CLEARING from VTY configuration
instead of hardcoded magic numbers.
Related: OS#5337
Change-Id: I234b2a754d0c98031056981823cdbc187e977741
Allow returning a context sensitive cause instead of a hardcoded one in
gscon pre_term().
Also, the conn->cause is needed to move message dispatch to an "onenter"
function in patch I234b2a754d0c98031056981823cdbc187e977741. I Split
this part off as a separate patch for better readability.
Related: OS#5337
Change-Id: Ib6432746040899129d1d73ae8dc59add2d88a915
In lcs_ta_req_wait_ta_onenter(), fix use count leak of 'start-paging':
get() the use count only after the early exits.
osmo-ttcn3-hacks patch I69d4c5c6f8d499bb7f0b96a48af045361433c57b
introduces testing against this leak in various LCS tests (e.g.
BSC_Tests.TC_lcs_loc_req_for_active_ms_ta_req).
Related: OS#5355
Change-Id: Ibbfbfe766eafe42c78048ec5b3b503a11ef5535d
During specific release scenarios, it became clear that an lchan still
pointed at a conn even after it had been deallocated. That was due to
setting conn->lchan = NULL but not lchan->conn = NULL. Fix that.
Do lchan_forget_conn() first, because during gscon_forget_lchan() we may
enter the gscon clearing dance, which in case of no SCCP conn being
present will soon / should immediately deallocate the conn.
Related: OS#5337
Related: I8c8537acf6b47b121903197608636c43ae601a57 (osmo-bsc)
Change-Id: Idbfe4672233ba8105eff5ba77ee07fd871358255
Before:
state_chg to ACTIVE
state_chg to WAIT_RLL_RTP_RELEASED
state_chg to WAIT_SCCP_RLSD
After:
State change to ACTIVE (no timeout)
State change to WAIT_RLL_RTP_RELEASED (T3109, 5s)
State change to WAIT_SCCP_RLSD (X4, 60s)
Change-Id: I94b7dc4d9e5e45dc731bcb3a843ede9fb6cc0839
The checks that make sure that an ARFCN falls in the correct range do
not return with -EINVAL as they should, instead nothing happens. (Only
the check for GSM1800 is corrct)
Change-Id: Iddadafe3fbc47e2f980d8e4ab4f320998cb454ff
Related: SYS#5369
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: Ifbbafe185931c0f508ff8148ef244f25a9620fd8
At the moment the BTS configuration is checked, but the check does not
have much consequence other than that some initialization that is not
executed. The BTS will go into the OML bootstrap phase anyway and most
likely fail at some later point due to the invalid configuration. To
reduce noise and unexpected behaviour of the BTS lets make sure that the
OML boostrap phase can only proceed when the BSC conciders the
configuration as valid.
Change-Id: I42c1c26a9b800600787b1266a871f95f2114c26e
Related: SYS#5369
Counting the Assignment success after osmo_fsm_inst_term() meant that we
were counting a cleared out channel mode, which always yielded
signalling mode.
Count the Assignment success *before* terminating, so that we correctly
count the successful assignment as speech mode.
Related: SYS#4878
Related: Icb1386ec2ccd70eb3c026301b9b08ad7177278f7 (osmo-ttcn3-hacks)
Change-Id: Ie9fcd1e86f27ecb2f11e2e8813faac365cb470b8
Similar to paging:attempted, count paging:expired not only per BTS, but
also for the whole BSC. Add active_paging_requests to struct bsc_subscr,
to increase the counter only once if paging expires, and not once per
BTS where paging expired.
Related: SYS#4878
Change-Id: I9c118e7e3d61ed8c9f1951111255b196905eba4d
osmo-trx-uhd with a B200 has proven to provide bad (lower than usually
considered good) C/I values due to high noise (even with band filters in
place). Hence, default thresholds (gathered from literature on the topic)
are too high and end up in bad algorithm output decisions.
Furthermore, most users of Osmocom don't use it in densely populated
areas, hence RXLEV based algorithm used when C/I based one is disabled
is good enough.
Let's disable C/I based one by default, and let advanced users which
specific needs to enable and confiure thresholds specifically for their
needs (hardware, cell surrounding conditions, etc.).
Related: SYS#4917
Change-Id: If1a73c60695379bcfcd0f44c6ec6dd659563e279
abis_nm locally declares its own struct for the ipaccess firmware
header, even though libosmocore defines it as well. Lets use the
definition from libosmocore.
Change-Id: I69cb45fc40bd20ea2533cc8cd6a68363b59cc408
The function generate_ma_for_bts() is called when the OML TEI comes up.
In the same code path boostrap_bts() is called as well. It would be more
logical to call generate_ma_for_bts() from boostrap_bts() since it is
also part of the bootstrapping process.
Change-Id: Ib2ed5b1eac3701cfb3a3e8dd478488ba5404d1fd
Related: SYS#5369
At the moment check_bts and bootstrap_bts is called only once on startup.
When a new BTS is set up during runtime bootstrap_bts, nor check_bts is
called. This means that some parameters of the BTS stay uninitalized
until osmo-bsc is restarted. Lets rather call check_bts() and then
bootstrap_bts() when the OML TEI of the BTS comes up.
Change-Id: Ie599f809623efd6ea4ab3f39294195fc1ef84b85
Related: SYS#5369
Pau Espin
Oliver Smith
Harald Welte
Vadim Yanitskiy
Neels Hofmeyr
Philipp Maier
Neels Hofmeyr