Use the new osmo_mobile_identity API to shed some code dup and simplify.
gsm48_paging_extract_mi() is now unused, drop.
(More refactoring to use osmo_mobile_identity follows in subsequent patch.)
Depends: If4f7be606e54cfa1c59084cf169785b1cbda5cf5 (libosmocore)
Change-Id: Id6cccaac64392b737b3bba8f3a22a88009adb23b
This adds the assignment counters for the BTS as well and changes the
assignment_count() macro to increase both the counters for the BSC as
well as the BTS.
Related: SYS#4877
Change-Id: I0009e51d4caf68e762138d98e2e23d49acc3cc1a
Prepare for MSC pooling by NRI. Before introducing actual NRI decoding and MSC
matching, fix the bsc_find_msc() implementation.
(Indicate the places relevant for NRI by "TODO" comments).
bsc_find_msc() puts an MSC to the end of the internal list of MSCs when it was
used. This has problems:
- Modifying the list affects VTY output, e.g. 'show running-config' and
'show mscs' change their order in which MSCs are shown, depending on how
often a round-robin selection has taken place.
- Emergency calls and normal calls potentially pick quite different sets of
eligible MSCs. When the round-robin choices between these sets affect each
other, the choice is not balanced. For example, if only the first MSC is
allow_emerg == true, every emergency call would reset the round-robin state
to the first MSC in the list, also for normal calls. If there are regular
emergency calls, normal calls will then tend to load more onto the first few
MSCs after those picked for emergency calls.
Fix: Never affect the ordering of MSCs in the internal list of MSCs. Instead,
keep a "next_nr" MSC index and determine the next round-robin target like that.
Keep a separate "next_emerg_nr" MSC index so that emergency call round-robin
does no longer cause normal round-robin to skip MSCs.
Further problems in current bsc_find_msc():
- The "blind:" label should also do round-robin.
- The "paging:" part should not attempt to use disconnected MSCs.
- Both should also heed NRI matches (when they are added).
Fix: instead of code dup, determine Paging Response matching with an earlier
Paging Request right at the start. If that yields no usable MSC, continue into
the normal NRI and round-robin selection.
The loop in this patch is inspired by the upcoming implementation of MSC
pooling by NRI, as indicated by the two TODO comments. The point is that, in
the presence of an NRI from a TMSI identity, we always need to iterate all of
the MSCs to find possible NRI matches. The two round-robin sets (Emergency and
non-Emergency) are determined in the same loop iteration for cases that have no
or match no NRI, or where a matching MSC is currently disconnected.
Change-Id: Idf71f07ba5a17d5b870dc1a5a2875b6fedb61291
The separate struct osmo_bsc_data is like another separate struct gsm_network
for no reason. It is labeled "per-BSC data". These days, all of this is a
single BSC and there will not be different sets of osmo_bsc_data.
Drop struct osmo_bsc_data, move its members directly into gsm_network.
Some places tested 'if (net->bsc_data)', which is always true. Modify those
cases to rather do checks like 'if (net->rf_ctrl)', which are also always true
AFAICT, to keep as much unmodified logic as possible in this patch.
Change-Id: Ic7ae65e3b36e6e4b279eb01ad594f1226b5929e0
Another legacy feature. All that this setting effectively does is prevent MSCs
from being contacted for non-emergency calls. To select which MSCs shall handle
emergency calls, there is the allow_emerg flag.
Change-Id: I7fc630d9c35be9a69a0d378d3de2b2312c69690d
The BSC is the wrong network component to originate USSD messaging, as can be
seen in the hacks in the USSD code: for example, the BSC would send a CM
Service Accept message as if an MSC had accepted the connection, dispatch a
USSD and directly send some RR release message (without proper tear down
messaging like the lchan_fsm does these days). This made sense in the osmo-nitb
world, but by now we are aiming for solid 3GPP compliance. The BSC shall not
originate USSD messages.
Deprecate all VTY and CTRL commands related to USSD:
VTY
[no] bsc-welcome-text
[no] bsc-msc-lost-text
[no] bsc-grace-text
[no] missing-msc-text
(the commands with 'no' are ignored, without 'no' lead to an error)
CTRL
ussd-notify-v1
Drop (already unused) ussd.h.
Drop gsm_04_80.h, gsm_04_80_utils.c, and all calling code.
Drop "RF grace" notification, where osmo-bsc was able to notify active
subscribers that the RF was being turned off.
Change-Id: Iaef6f2e01b4dbf2bff0a0bb50d6851f50ae79f6a
It is not entirely clear to me what this used to do once, but I've stumbled
upon this before. By now I am certain that this is a non-standard legacy
feature. The BSC does *not* redirect connections during CC transactions.
Along with this, a bunch of legacy utility functions can be dropped. All of
this is unused code.
(Preparing for MSC pooling.)
Change-Id: Id54afe8ccf0e11b9121a733224054c9565eafb58
Filtering by IMSI in osmo-bsc is a legacy use case with questionable
usefulness. Remove.
Do not keep deprecated VTY commands: those could be dangerous, since
(presumably non-existing) users might assume that the filtering would still be
in place. Rather fail to start osmo-bsc for config with an IMSI ACL.
The IMSI filtering did, if present, provide the logging with an IMSI to print
for the bsc_subscriber. TMSIs should have ended up in logging likewise, which
has never been implemented. The proper way to learn the IMSI would be by the
Common Id message from the MSC. Furthermore, the upcoming MSC pooling feature
will extract the mobile identity again, and will hence make sure that both IMSI
and TMSI identities, as available, end up in the bsc_subscriber and will be
logged again.
So long, IMSI ACL, and thanks for all the fish.
Change-Id: I89727af5387e8360362e995fdee959883c37d89a
The bsc_msc_data->rtp_base has been unused ever since we introduced the exernal
MGW in osmo-bsc [1]. The vty command also still exists. Deprecate the vty
command, remove the member.
[1] "mgcp: use osmo-mgw to switch RTP streams"
commit 39c609b7c9
Change-Id Ia2882b7ca31a3219c676986e85045fa08a425d7a
Change-Id: Id14fa3066ca5d472a817593074a6222f159168a8
We decode the mesage and print it to the log files at ERROR log level.
We also count it in the BSSMAP message counters. There is not much
else we could do about it.
Depends: If8afd2d096fb66c6c2f255a08fc1129de3d09cec (libosmocore)
Change-Id: Ib4cd94f185f751b2384842222678ff671ac413c4
This is a corner case but still we should count the events to
know when is this happening. And for the number of paging requests
to match the number of paging responses.
Change-Id: I1755be40d29980b75353cb4b8087d1ce0d92854a
We already have counters for Rx side, now we also count Tx side.
See comments in the msc_ctr_description array implementation for
the details.
Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
It's useful to know how many BTS are actually configured to compare
it to a number of connected BTS's.
Change-Id: I41cb60f9cb962003227e4a7b63db05acbcdb6f4c
Currently only supports a single MCTR with fixed configuration
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I96b8bb2c01c05bf153fc924f62bd6aafa96725ee
Starting from G12R13 the MCTR swiches to BSC controlled mode. And
although we think we know how to configure it (via MCTR Conf Req),
something doesn't work right and the timeslot configuration is not
accepted. (TS Conf Result shows "Data not according to request").
So as a workaround for now, we use this version of the protocol where
we don't configure the MCTR (it's in "BTS controlled mode") and with
this protocol, the BTS accepts our timeslot config and we can bring
the system up.
This commit add a generic option to limit either OML or RSL IWD
version to any value. It also keeps track of the actual negotation
version so we can react to it in other places of the code.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I8f0b0ba72056ea4250fe490e7a38630c77c04f65
better version limit
Change-Id: Ia789f8ede3eab7eeca6c759da0109e0b53398f60
The existing Nokia *Site code destroyed the LAPD SAP instance for OML
while processing an OML message. Once the stack frame returned back
to the LAPD code, the LAPD SAP was gone -> segfault.
Let's work around this by moving deletion of the LAPD SAP out-of-line
by starting a timer 0ms in the future. Not particularly nice, but
effective.
Change-Id: I6270c7210f600e53f845561898245d2fd30a368d
Closes: OS#1761
/usr/bin/ld: bsc_subscr_conn_fsm.o:/home/laforge/projects/git/osmo-bsc/src/osmo-bsc/../../include/osmocom/bsc/handover.h:26: multiple definition of `mr'; abis_rsl.o:/home/laforge/projects/git/osmo-bsc/src/osmo-bsc/../../include/osmocom/bsc/handover.h:26: first defined here
See also https://alioth-lists.debian.net/pipermail/debian-mobcom-maintainers/Week-of-Mon-20200413/000649.html
Change-Id: Ic21af84f2a6de48d220940f30dad02a0e7683ce8
According to 3GPP TS 44.060, section 12.24, GPRS Cell Options IE
contains two parameters related to 11 bit Access Burst support:
- ACCESS_BURST_TYPE - whether the 8 or 11 bit format shall be
used in the PACKET CHANNEL REQUEST message, the PTCCH/U block,
PACKET CONTROL ACKNOWLEDGMENT and the PS HANDOVER ACCESS
messages on the PRACH (if present).
- EGPRS_PACKET_CHANNEL_REQUEST - whether EGPRS capable MSs shall
use EGPRS PACKET CHANNEL REQUEST message for Uplink TBF
establishment on the RACH or on the PRACH (if present).
The VTY option 'gprs 11bit_rach_support_for_egprs' actually controls
the second parameter - EGPRS_PACKET_CHANNEL_REQUEST, though it may
be hard to understand this from its name and description.
This patch is actually a group of tightly related changes:
- deprecate 'gprs 11bit_rach_support_for_egprs (0|1)':
- update its description to avoid any possible confusion,
- print a warning if it's used in non-EGPRS mode,
- print a warning if it's still used;
- introduce '[no] gprs egprs-packet-channel-request':
- ensure that it can only set / printed in the EGPRS mode;
- take a chance to clean-up / rename the related struct members:
- 'supports_egprs_11bit_rach' -> bool 'egprs_pkt_chan_request',
- remove 'supports_egprs_11bit_rach' from 'gprs_cell_options'
because we already have 'ext_info.use_egprs_p_ch_req' there.
Change-Id: Ied5bd10a806aeeac65ef32339d4ab0e3700e5da9
This dates back to a time where osmo-bsc_nat was in the same repository,
which is a long time ago.
Change-Id: Id965295dfe04f8bd5ce831db70c86f67b8dc290b
Save OML failure reports from each BTS. Add a VTY command to display them
conveniently and optionally clear the list.
OsmoBSC> show bts 0 fail-rep
[2020-03-23 14:51:22] Type=processing failure, Severity=minor failure, Probable cause=Manufacturer specific values: Software warning, Additional text=test message sent from VTY
[2020-03-23 14:51:19] Type=processing failure, Severity=minor failure, Probable cause=Manufacturer specific values: Software warning, Additional text=test message sent from VTY
Related: OS#1605
Change-Id: I18aa17a721cd5eb1c98926dc2367229c0a50bc78
Separate raw input parsing from handling the failure report. A follow-up
patch will use the new parsing function to print saved failure reports
to the VTY.
While at it, put struct tlv_parsed inside struct nm_fail_rep_signal_data
instead of a pointer, so we don't need an additional alloc. Also add
error handling to the abis_nm_tlv_parse() call.
Related: OS#1605
Change-Id: Ia51004faf620aa4d40435d58c70d758c9d0054d8
Refuse to start with mutually exclusive codec settings, unless
allow-unusable-timeslots is set in the network section of the config.
The checks were already implemented and fill the error log if the config
is invalid.
Related: OS#3739
Change-Id: I3ccfc3b0a8641400cb97a23b24d7ed92d2ad25cd
OM2000 is not only used for the venerable RBS2000 family, but also
for the more modern RBS6000 family, specifically the DUG 20 GSM
baseband unit.
In RBS6000, there are some protocol extensions which are not yet fully
understood. However, we are understanding some bits around the MCTR
(multi carrier transceiver?), a new MO that appears to be present for
every physical RUS (Radio Unit) attached to the DUG 20.
Let's add what we have learned so far.
Thanks to Sylvain Munaut for his help with this.
Change-Id: Ib868358eca12b94c4fcca58e94ec8ab1a4edfda2
Let's not just pass around the raw msgb, but also all other metadata,
such as the decoded parts of the TS 12.21 message.
As there's no current consumer of that signal, this creates no
compatibility issues.
Change-Id: I5d4d9d422b4e23348ffbe69c6e87a31d5574f90d
As per 3GPP TS 45.002, section 3.3.2.3, and table 3 of clause 7,
the following limitations apply mapping of CCCH/BCCH channels:
- TS0/C0 shall be configured as CCCH/BCCH (optionally combined);
- combined CCCH (CCCH+SDCCH4) can only be used on TS0;
- additional CCCHs can be on TS2, TS4, and TS6;
- additional CCCHs are not allowed if TS0 is combined.
Let's make sure that OsmoBSC is properly configured before starring.
Change-Id: I758ef80f7884ba35cdf59d671ee30222ffb9d68b
In addition to transmission of the ETWS Primary Notification via all
dedicated channels, we also need to send it to the BTS for transmission
via PCH (P1 Rest Octets) and for forwarding to PCU for PACCH
transmission.
Change-Id: I7e45b0373458a4348b12b92dd92861062532548b
As soon as we have received an ETWS primary notification message from
the CBC, we should transmit it as "RR Application Information" to all
dedicated channels.
Change-Id: I913d0237cffdcb95037da8489acef5f32a7fc02e
Neels Hofmeyr
Daniel Willmann
Vadim Yanitskiy
Sylvain Munaut
Harald Welte
Oliver Smith
Pau Espin
Martin Hauke