This feature apparently assigned a fixed LAC and CI to a specific MSC, but
looking at the implementation was obviously not useful.
Keep the vty commands for legacy compat, now without effect besides logging an
error via vty_out().
Related: OS#4751
Change-Id: I6bee704e7e5d5b6b86473323bae1fa9fce9241ee
Before they were set with a value of 0, which had no related enum field,
but since in general all comparsions are done against NM_STATE_UNLOCKED
they also hold valid.
The major change in behavior with this patch is upon OML link down,
where gsm_bts_mo_reset() is called on all objects. This way, upon OML
re-establishment we have again all objects as Locked again, which is the
expected default value as per TS 12.21.
Change-Id: I68ae0bc51a565f903b47cf72f3e3dd6f1a2d2651
Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that
it can be re-used on the Lb interface.
Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we
have generally established in our osmo_fsm implementations.
Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c.
A difficulty is setting a proper logging category: the FSM definition allows
only one fixed logging category for FSM state transitions and events. Ideally,
the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log
on DLCS. Since that is not possible, introduce a separate DRESET logging
category. This in fact matches an item on my wishlist, because if a given MSC
is configured but currently not connected, the previous RESET FSM would
continuously "spam" log LOGL_NOTICE messages indicating that it is resending
RESET, and I often want to silence those messages without silencing the entire
DMSC category. This is now easily possible by setting DRESET logging to
LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all
interesting info is still visible on DMSC.
Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
The N-CONNECT.req on the A interface is a possible *consequence* of the event
being handled, namely the incoming RSL ESTablish INDication containing the
Complete Layer 3 message: dispatched by bsc_compl_l3().
If an (LCS related) connection is already present on the A-interface when the
lchan is established, there will be no N-CONNECT but an N-DATA sending the
Complete Layer 3. See BSC_Tests.TC_cm_service_during_lcs_loc_req().
Change-Id: Ic43aabeb0d3c58ac62249ad9d3718363d32508f9
During LCS development, I'm getting use count bugs and would like to see use
token strings to figure it out.
Change-Id: I29bf60059d4cf7bb99a00753e6cdc149baf95f94
Allow starting a paging from elsewhere than a BSSMAP Paging Request. For
upcoming Location Services (LCS), a BSSLAP TA Request from the SMLC may require
triggering a Paging.
Change-Id: Iaff91584699d163bd1963927280ff3a8ddd43073
Move conn allocation to bsc_compl_l3(), from gsm0408_rcvmsg().
Drop dispatch of GSCON_EV_A_DISC_IND, because a) we did not receive such
DISC.IND, and b) the lchan release will discard the conn in the regular
fashion.
In upcoming LCS patch, bsc_compl_l3() will decide whether to allocate a new
conn or whether a conn from a Perform Location Request already exists for the
subscriber.
In this patch, it becomes clear that the conn->bsub is always NULL in
bsc_compl_l3(), and that the 'log_set_context(LOG_CTX_BSC_SUBSCR, conn->bsub);'
never has the intended effect. An upcoming patch will change that.
Change-Id: I92af0f0d54c4282d782f2b29d524a64006c3b674
Backwards compatibly, introduce timer groups in OsmoBSC, and move some
non-specified T timers to new X timers:
T993111 -> X3111
T993210 -> X3210
T999 -> X4
Why X4? because there already is an X3 used elsewhere in Osmocom, and I find
it less confusing if X-numbers don't repeat across programs. See
https://osmocom.org/projects/cellular-infrastructure/wiki/List_of_Timer_numbers
Drop unused timers from g_mgw_tdefs. Only X2427 has an actual effect.
(libosmo-mgcp-client recently moved T2427001 to X2427.)
Put libosmo-mgcp-client related timers to the 'mgw' group, like in osmo-msc.
This makes the MGCP timeout configurable for the first time.
Keep previous timer commands as DEFUN_HIDDEN, and also translate the moved T
timers to X timers on-the-fly. All previous VTY commands still work, and new
'timer [(net|mgw)] ...' commands are added. timer.vty shows this.
Remove the "_OPTIONAL" from the legacy "timer" and "show timer" commands, so
that they don't ambiguously overload the new "timer [(net|mgw)] ..." commands.
Related: OS#4539
Related: If097f52701fd81f29bcca1d252f4fb4fca8a04f7 (osmo-mgw)
Change-Id: I4beec47502afa193dee343869c4be55dc6a4b536
Before transitioning some unspecified T timers to X timers, and to introduce
timer groups, first add this timer VTY test. Changes here will illustrate that
the legacy commands will still work and redirect to new timer definitions.
Related: OS#4539
Change-Id: Ie1bc635e16dc9a4040d063e1d9a51cdc76d9d1f2
In commit [1], I replaced the way the CBSP link is configured in the VTY. But
that configuration was already part of a release, hence I should only have
deprecated the old commands. Re-add the legacy config as deprecated.
Try to make the legacy commands take a similar effect as they previously would
be intended for, i.e. switching to server/client/disabled modes, and take
effect immediately when commands are read from telnet.
[1] 641f7f0845
Icaa2775cc20a99227dabe38a775ff808b374cf98
"CBSP: rewrite the CBSP link setup and 'cbc' VTY section"
Related: OS#4702
Change-Id: If6b742f28191b3f19ff1d87a217037a305133f4b
Firstly, make CBSP server and client mutually exclusive: Do not allow osmo-bsc
to be configured as CBC client *and* CBC server at the same time.
cbsp_link.c expects at most one CBSP link to be established, and, upon sending
CBSP messages, probes whether to send the message to a CBSP server or client
link. When both listen-port and remote-ip are configured (regardless of an
actual CBSP connection), osmo-bsc gets confused about where to send CBSP
messages.
One solution would be more accurate probing for an actual established TCP
connection. But the simpler and less confusing solution is to force the user to
configure only server or only client mode, never both.
Introduce 'cbc' / 'mode (server|client|disabled)'.
Secondly, clarify the 'cbc' config structure into distinct 'server' and
'client' subnodes. Refactor the 'cbc' VTY node in such a way that the IP
addresses for server and client mode can remain configured when the CBSP link
is switched between server/client/disabled modes.
To implement the above, switch the struct bsc_cbc_link to use osmo_sockaddr_str
for address configuration.
Related: OS#4702
Related: I7eea0dd39de50ed80af79e0f10c836b8685d8644 (osmo-ttcn3-hacks)
Related: I9e9760121265b3661f1c179610e975cf7a0873f1 (docker-playground)
Change-Id: Icaa2775cc20a99227dabe38a775ff808b374cf98
As 3GPP TS 48.058 clearly states, an RLL RELease INDication is only
sent if the datalink is released by the MS. Thre's no cause value
giving further diagnostics, but if the MS releases the link, it is
clearly not the BSS's fault, and hence "BSS not equipped" is wrong.
Change-Id: I38222e60071841abcd06046a472ddb35907164a4
Related: OS#4728
Prior to this patch, ACC ramping was only used to go 0->N in the
number of allowed ACCs during BTS startup. It could optionally
dynamically stretch or extend the ramping time based on channel load.
With this patch, ACC ramping is kept alive during the entire time the
BTS is active, and subset of allowed ACCs can now be incresed or
decreased based on channel load. A new VTY command
"access-control-class-ramping-chan-load" is added to configure a lower
and an upper threshold. Channel load under the low threshold will
potentially trigger an increment of the subset size of allowed ACCs,
while a channel load over the upper threshold will potentially trigger
the opposite (a decrease in size).
The time between checks is kept fixed per VTY command (reusing old
"access-control-class-ramping-step-size"), but the "dynamic" option
is deprecated and ignored from now on since it provides nothing valuable
in the new implementation, because the size always dynamically changes
based on channel load (configured thresholds).
Related: SYS#4912
Change-Id: Id17f947c92cdfc0eb9541a9bf066338169caaeb5
See updated documentation section in manuals/chapters/bts.adoc regarding
an explanation on how the system works.
Related: SYS#4911
Change-Id: I952c9eeae02809c7184078c655574ec817902e06
With upcoming next commit, the file will contain far more code that
simply ramping, so rename it to be more generic.
Change-Id: I8c368ab87e264439dea4ccf556821a44664cdbb0
The function initializes the struct owned by a bts, so it makes sense to
have it done there instead of somewhere else later.
It was most probably put in bsc_vty when it was initially introduced
because of all the data structure and object file mess I untangled
during last set of patches.
Change-Id: I66c4b208583e92070793183b83b3a7b7edf6ba00
Place all code related to the object into the related file.
Having all the data model in one file made sense in early stage of
development to make progress quickly, but nowadays it hurts more than
helps, due to constantly growing size and more and more bits being
added to the model, gaining in complexity.
Currently, having lots of different objects mixed up in gsm_data.h is a hole
of despair, where nobody can make any sense were to properly put new stuff
in, ending up with functions related to same object in different files
or with wrong prefixes, declarations of non-existing functions, etc.
because people cannot make up their mind on strict relation to objects
in the data model.
Splitting them in files really helps finding code operating on a
specific object and helping with logically splitting in the future.
Change-Id: I00c15f5285b5c1a0109279b7ab192d5467a04ece
In rest_octets.c append_earfcn(), the unconditional bits added are 40, not 25.
Removing only 25 bits from the budget resulted in malformed SI2quater starting
with 4 configured EARFCNs, by adding more EARFCNs than fit in 20 bits.
These malformed SI2quater were also expected in gsm0408_test.c. Update the
expected SI2quater to what is being generated now. This patch passes the ttcn3
testing added in I45382f88686ca60e68569e93569fc4cfb63a0e0d, which provides some
confidence that the coding expected in gsm0408_test.c is now correct.
Related: OS#4652
Change-Id: I5df269f713456a6ccbb874d6b7faac4a6f123c67
Found while playing with "rf_locked 1" on a 2TRX setup with channel
allocator descend. After applying the setting, the 1st TRX is still used
to allocate the channels. After this patch is applied, the BSC correctly
allocates channels from TRX0.
Change-Id: I5201d2749363c9cbd0706177bde09117b163cbe3
For historical reasons we had bsc_vty.c and osmo_bsc_vty.c. Ever since the
osmo-nitb split, there is no reason to keep these files separate. Merge
osmo_bsc_vty.c into bsc_vty.c (because osmo_bsc_vty.c is smaller).
I noticed this particularly because adding the NRI configuration required
adding things like #define NRI_STR in two separate files: once for the
'network' level vty, and once for the 'msc' level.
Change-Id: I7fd2ee631b22e38f3d96d8159dc1deaaca6a7013
As in 3GPP TS 23.236, to offload an MSC, the BSC must be able to avoid
attaching new subscribers to it:
4.5a.1: "UEs being moved from one CN node are stopped from registering to the
same CN node again by an O&M command in BSCs and RNCs connected to the pool."
Change-Id: I6249201c15d0f6565aca643c21d2375c9ca58584
Testing these functions is actually done in libosmocore. Also, with new
osmo_mobile_identity API, the functions being tested are marked deprecated. So
drop the test.
BTW, the test contained an IMSI of 16 digits, which is too long, yet was
expected to succeed. GSM23003_IMSI_MAX_DIGITS == 15. I first considered fixing
the test data, but the test is in the wrong place here anyway.
Change-Id: I902d31ecd72d71892fad7945f695a9f1fb403bf2
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
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
osmo-bsc has crashed with the following backtrace:
0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
1 0x00007f0bc49b38db in __GI_abort () at abort.c:100
2 0x00007f0bc581ba30 in osmo_panic () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
3 0x00005648ceeced69 in conn_get_bts (conn=<optimized out>) at ../../include/osmocom/bsc/gsm_data.h:1392
4 0x00005648cef37164 in conn_get_bts (conn=0x5648cf769e80) at osmo_bsc_filter.c:87
5 bsc_patch_mm_info (conn=conn@entry=0x5648cf769e80, data=<optimized out>, length=<optimized out>) at osmo_bsc_filter.c:48
6 0x00005648cef371b6 in bsc_scan_msc_msg (conn=conn@entry=0x5648cf769e80, msg=msg@entry=0x5648cf77ead0) at osmo_bsc_filter.c:159
7 0x00005648cef33988 in dtap_rcvmsg (msg=0x5648cf72b2f0, length=40, conn=0x5648cf769e80) at osmo_bsc_bssap.c:1215
8 bsc_handle_dt (conn=conn@entry=0x5648cf769e80, msg=0x5648cf72b2f0, len=40) at osmo_bsc_bssap.c:1299
9 0x00005648cef3b2b7 in handle_data_from_msc (msg=<optimized out>, conn=0x5648cf769e80) at osmo_bsc_sigtran.c:152
10 sccp_sap_up (oph=0x5648cf72b378, _scu=<optimized out>) at osmo_bsc_sigtran.c:267
11 0x00007f0bc5813c03 in _osmo_fsm_inst_dispatch () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
12 0x00007f0bc51a8935 in sccp_scoc_rx_from_scrc (inst=inst@entry=0x5648cf6a8d60, xua=xua@entry=0x5648cf720150) at sccp_scoc.c:1695
13 0x00007f0bc51a62f3 in scrc_rx_mtp_xfer_ind_xua (inst=inst@entry=0x5648cf6a8d60, xua=xua@entry=0x5648cf720150) at sccp_scrc.c:459
14 0x00007f0bc51a9545 in mtp_user_prim_cb (oph=0x5648cf7681f8, ctx=0x5648cf6a8d60) at sccp_user.c:182
15 0x00007f0bc51a09c6 in m3ua_rx_xfer (xua=0x5648cf764a80, asp=0x5648cf45f540) at m3ua.c:586
16 m3ua_rx_msg (asp=asp@entry=0x5648cf45f540, msg=msg@entry=0x5648cf71e880) at m3ua.c:739
17 0x00007f0bc51b0763 in xua_cli_read_cb (conn=0x5648cf441ed0) at osmo_ss7.c:1761
18 0x00007f0bc55fab53 in osmo_stream_cli_read (cli=0x5648cf441ed0) at stream.c:232
19 osmo_stream_cli_fd_cb (ofd=<optimized out>, what=1) at stream.c:321
20 0x00007f0bc580edcf in ?? () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
21 0x00007f0bc580f526 in osmo_select_main_ctx () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
22 0x00005648ceecfb2f in main (argc=<optimized out>, argv=<optimized out>) at osmo_bsc_main.c:953
Apparently, there is no lchan allocated at this moment, so
conn_get_bts() crashes. But we only use it to get to "network" which
we can do much easier and safer by doing conn->network.
Change-Id: Id3f7b3efba60c0f050c1be98e5e539f1dab4cd57
Neels Hofmeyr
Pau Espin
Oliver Smith
Vadim Yanitskiy