As a rudiment of OsmoNiTB, OsmoMSC is still involved in SMS
processing, storage (in SQLite DB), and routing (via SMPP).
In real networks this is done by the external entity called
SMSC (SMS Centre), while the MSC is doing re-encapsulation
of GSM 04.11 SM-TL (Transport Layer) payload (i.e. TPDU)
between SM-RL (Relay Layer) and MAP.
Since OsmoMSC itself is not a 'Network in The Box' anymore, it
makes sense to replicate the 'traditional' behaviour of MSC.
The problem is that this behaviour cannot co-exist with the
current implementation, so the key idea is to rip out the
local SMS storage and routing from OsmoMSC, and (re)implement
it in a separate process (OsmoSMSC?).
As a temporary solution, this change introduces a 'kill-switch'
VTY option that enables routing of SMS messages over GSUP
towards ESME (through VLR and HLR), but breaks the local
storage and routing. This is why it's disabled by default.
As soon as we move the SMS processing and storage away from
OsmoMSC, this behaviour would be enabled by default, and
the VTY option would be hidden and deprecated. At the moment,
this option basically does nothing, and will take an effect
in the follow-up changes.
Change-Id: Ie57685ed2ce1e4c978e775b68fdffe58de44882b
Related: OS#3587
We can check if we're parsing the config file by checking
whether vty->type equals VTY_FILE. This avoids the use of
an extra local variable to track the parsing state.
Change-Id: I85161575e025f7c389832427a434bd8e2d6ecc75
Fixes: 1051c42088
Related: OS#3355
When the VLR subscriber information is shown on the VTY it shows IMSI
and TMSI, but not IMEI and IMEISV. Since in some cases this information
might be helpful, lets display it as well.
Change-Id: Iedd75dbb9850388ec1fedb984ed0b8bf4c62e780
Always use LAC which is part of Cell Global ID otherwise we might end up
in a situation where separately stored LAC differs.
Both are described in 3GPP TS 23.008 $2.4 as temporary subscriber data
to be stored in VLR. Both are defined in 3GPP TS 23.003. The LAC is part
of LAI which is part of CGI so there should be no case when those values
differ for a given subscriber.
Change-Id: I993ebc3e14f25e83124b6d3f8461a4b18f971f8e
When a subscriber is displayed the RAN type is not included in the
overview. Meanwhile the MSC supports multiple different ran types it
becomes important to see in which RAN the subscriber is currently
active.
Change-Id: I000cafd5e41b9951d51b6bd6672ee68a224b8212
Related: OS#3615
When a VLR subscriber is displayed on the VTY we get a lot of meta
information, but there are also some flags to handle the internal
subscriber status e.g. conf_by_radio_contact_ind. Lets display those
flags as well as this information can be very helpful when debugging
problems in the VLR
Change-Id: I59a9145a4daad50d68de3fd5c3291f027256917f
Do not show the VTY command's own use count during 'show subscriber <ID>'.
When using 'show subscriber msisdn 2023', I was surprised to see a use count of
2 and suspected a use count leak. With 'show subscriber cache' however, the use
count is 1.
So I realized it is the vty command's own use count that makes it two, besides
the lu_complete=true one.
Change-Id: Id02b57b7ed299b010b9f8b9e809548eb1e6aa699
The 'ipa-name' option can now only be set via the configuration file
because changing the IPA name at run-time conflicts with active
GSUP connections and routes configured in the HLR. The osmo-msc
program must be restarted if its IPA name needs to change.
Change-Id: I6cff91793e646e0396e8f1bc87d0f52709e5f12a
Related: OS#3355
Add a 'ipa-name' VTY command which overrides the default IPA name
used by the MSC. This is a prerequisite for inter-MSC handover.
Related: OS#3355
Change-Id: I317d6c59f77e92fbb2b875a83dc0ec2fa5cb6006
So far the only way to use external MNCC is to pass the -M cmdline arg:
osmo-msc -M /path/to/socket
However, the osmo-msc.service file for systemd is installed by 'make install',
and hence it is quite impractical to depend on such a config item to be
required in the service file:
- It defies any scheme an operator may have in place to compose the
osmo-msc.cfg file -- this option doesn't go in the .cfg file but needs
separate action to add to the installed service file.
- After a make install or package upgrades / re-installations, this option will
be plain overwritten silently, or lead to the need for resolving file
conflicts.
The initial spark for this came from configuring the 35c3 GSM from cfg
templates.
Change-Id: I2ec59d5eba407f83295528b51b93678d446b9cee
I want to add 'mncc internal' and 'mncc external' commands, and IMHO makes most
sense to have a common 'mncc' keyword to start MNCC config commands with. To
put it in terms of VTY online help:
OsmoMSC(config-msc)# mncc ?
internal Use internal MNCC handler
external Use internal MNCC handler
guard-timeout Set global guard timeout
So far only the 'guard-timeout' exists, I want to add 'internal' and 'external'
in a subsequent commit.
Keep the old command 'mncc-guard-timeout' as deprecated alias. That means it
still works from old config files, but online documentation will omit it.
On 'write', write back the new format instead.
Rationale: see I2ec59d5eba407f83295528b51b93678d446b9cee
Change-Id: I52d69af48e1ddc87b3fb54bf66a01b1b8cbf5abe
Along goes GSM_KEYSEQ_INVAL as VLR_*.
It's where it logically belongs, and is almost the only reason why vlr.h
includes gsm_data.h. The remaining reason, GSM_EXTENSION_LENGTH, will be moved
by upcoming patch.
Change-Id: I122feae7ee3cbc59e941daef35a954bce29fec76
For hysterical raisins, there are some header files that contain few
declarations, and where the name doesn't reflect the content. Combine them to
new msc_common.h:
- common.h
- common_cs.h
- osmo_msc.h
Change-Id: I9e3a587342f8d398fb27354a2f2475f8797cdb28
In preparation for inter-BSC and inter-MSC handover, we need to separate the
subscriber management logic from the actual RAN connections. What better time
to finally rename gsm_subscriber_connection.
* Name choice:
In 2G, this is a connection to the BSS, but even though 3GPP TS commonly talk
of "BSS-A" and "BSS-B" when explaining handover, it's not good to call it
"bss_conn": in 3G a BSS is called RNS, IIUC.
The overall term for 2G (GERAN) and 3G (UTRAN) is RAN: Radio Access Network.
* Rationale:
A subscriber in the MSC so far has only one RAN connection, but e.g. for
inter-BSC handover, a second one needs to be created to handover to. Most of
the items in the former gsm_subscriber_connection are actually related to the
RAN, with only a few MM and RTP related items. So, as a first step, just rename
it to ran_conn, to cosmetically prepare for moving the not strictly RAN related
items away later.
Also:
- Rename some functions from msc_subscr_conn_* to ran_conn_*
- Rename "Subscr_Conn" FSM instance name to "RAN_conn"
- Rename SUBSCR_CONN_* to RAN_CONN_*
Change-Id: Ic595f7a558d3553c067f77dc67543ab59659707a
On UTRAN, Security Mode is used instead of Ciphering Command, which does not
feature an A5 algorithm id.
Change-Id: Idc7ca9da1aa13ae16f5db2cb1024676cbc770820
According to GSM TS 04.11, the SMC (Short Message Control) state
machine is a part of CM-sublayer of L3, that is responsible for
connection management (establisment and releasing), and SM-RP
(Relay Protocol) message delivery.
For some reason, the connection establisment request from SMC
(GSM411_MMSMS_EST_REQ) was not handled properly - it was
always assumed that connection is already established.
This is why the code initiating a MT (Mobile Terminated) SMS
transfer had to establish a radio connection with subscriber
manually.
Let's benefit from having the SMC state machine, and offload
connection establishment to it. This change makes the local
implementation closer to GSM TS 04.11, and facilitates the
further integration of GSUP transport.
NOTE: the expected unit test output is changed, because now we
always allocate a transaction first, and then establish a
connection, not vice versa.
Change-Id: I4a07ece80d8dd40b23da6bb1ffc9d3d745b54092
| ../../../git/src/libmsc/msc_vty.c:1202:44: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
| vty_out(vty, "Location Update : %lu attach, %lu normal, %lu periodic%s",
| ^
Change-Id: Iae1c0b20a519ce71a21f72cea3c63694ef10adb4
The external MNCC handler may hang indefinitely in cases where the remote
end of the MNCC ceases to work properly. Add a global guard timer to
make sure the call reaches ACTIVE state.
Change-Id: I7375d1e17cd746aac4eadfe1e587e82cf1630d3d
Related: OS#3599
This change introduces some new rate counters for call-independent
SS/USSD connections. As OsmoMSC doesn't handle the messages itself,
and only responsible for dispatching messages between both
A and GSUP interfaces, the following is taken into account:
- MS-initiated and network-initiated requests to establish
a NC SS/USSD session (transaction) - "nc_ss:m{o|t}_requests";
- successfully established MS-initiated and network-initiated
SS/USSD sessions (transactions) - "nc_ss:m{o|t}_established".
Change-Id: I23c9475abc9951d82f3342fdc5aaa367836f7741
The only reason to use int instead of the enum was the lack of header
iu_client.h when not building with Iu support. Rather use the configure result
properly, include the header when Iu support is built and use the proper enum.
Omit the entire iu sub-struct when building without Iu.
Add LIBOSMORANAP_CFLAGS to libvlr, in order to find the iu_client.h header (now
also included from gsm_data.h).
Rationale: Instead of using a questionable typecast from int* to enum*, we can
now use the enum member directly without needing to silence compiler warnings.
Change-Id: Ic9f8bf53f4b605c166e84cd7edd90c10fe7d7a1f
In the old days, OsmoNITB couldn't process any SMS that wasn't between
two subscribers on the same NITB.
We've long re-worked the internals in order to process SMS with
arbitrary sender MSISDN (e.g. from SMPP). However, the VTY command
"subscriber ... sms" was never updated, it seems.
Change-Id: I62b17e0a67989484415f0df2c8cb4ff1f94dbf2b
Closes: OS#3151
Match osmo-bsc's naming of the subscriber connection's FSM instance; 'conn->fi'
makes more sense anyway than 'conn->conn_fsm'.
BTW, an upcoming commit will do away with the legacy from libbsc/libmsc duality
and firmly glue the conn allocation to the fi.
Related: OS#3122
Change-Id: If442f2ba78d9722b1065ec30c9a13f372b6a8caa
classmark_is_r99() is only used in gsm_04_08.c, move there as static.
rrlp_mode_* is only used in msc_vty.c, move there as static.
Move ran_type_names[] to msc_ifaces.c.
Change-Id: I5381c72af6841829fbc65940fd7d6f4d5cf583df
Now that all VTY definitions are in the same file, we no longer need
gsmnet_from_vty(). Just have one static struct gsm_network *gsmnet populated by
msc_vty_init() and use it in all VTY functions.
Change-Id: I5cb3712a4f4245feb62d42f1b041fe94de5fac1b
From openbsc.git, we still have osmo-msc's VTY definitions spread across
various places. Combine:
- Move the go_parent_cb() and is_config_node() to msc_main.c, drop
common_vty.c.
- Move all of vty_interface_layer3.c into msc_vty.c.
- Move all of common_cs_vty.c into msc_vty.c.
- Move bsc_vty_init_extra() into msc_vty_init().
- Drop some unused definitions
No functional nor cosmetic changes have been made in the moved code, plain
copy-paste moving (even though the unidiff might look like edits in some
places). I might have adjusted some blank lines though.
Change-Id: Ia818c00ab613a19a34080b160d763b55c19f76b1
Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout
the code base to be able to handle an MNC < 100 that has three digits (leading
zeros).
Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore),
Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore)
Change-Id: I82f0016d9512ee8722a3489a3cb4b6c704a271fc
Call osmo_fsm_vty_add_cmds() to make osmo_fsm VTY commands available
in osmo-msc's VTY interface.
Change-Id: Iaf970f6039c3f668f275dd8c21fb9071774a5d9e
Related: OS#2967
OsmoMSC is using whatever reject cause is apropriate in the given
situation. This user-configurable reject cause only had relevance
in OsmoNITB, and hence it is an unused parameter that can be removed
in OsmoMSC.
Related: OS#2528
Change-Id: Ie1f39e706477aaf42051877b52d4b3ae1c5f138e
As in GSM/3GPP networks emergency calls carry no explicit destination
number/address, add a VTY commadn to patch in some destination handler
in the EMERGENCY SETUP before delivering to [internal or external] MNCC.
Change-Id: I7c9f43ba312fadda2b9a9483b3cf50e4abca9599
So far, the administrator had to pick one particular cipher which
would then be used throughout all subscribers/phones. This is a bit
impractical, as e.g. not all phones support A5/3. Extend the VTY
command syntax in a backwards-compatible way to permit for multiple
ciphers.
NOTE: Like the previous code, OsmoMSC does *not yet check* whether
the configured cipher is compatible with the MS capabilities as
reported in CLASSMARK! The network hence might choose an algorithm
not supported by the phone. Fixing this is subject to another patch.
Closes: OS#2460
Change-Id: I79a4e2892eb5fbecc3d84e11dceffb7149db264b
As the include file gsm_data.h is generic (does not depend on osmo-iuh0s
iu_client.h), rab_assign_addr_enc is declared as "int" instead of "enum ranap_nsap_addr_enc".
osmo-msc/src/libmsc/msc_vty.c: In function ‘msc_vty_init’:
osmo-msc/src/libmsc/msc_vty.c:212:30: warning: passing argument 2 of ‘ranap_iu_vty_init’ from incompatible pointer type [-Wincompatible-pointer-types]
ranap_iu_vty_init(MSC_NODE, &msc_network->iu.rab_assign_addr_enc);
^
Change-Id: I1b63ee350911bdf772a2324fff55035275a455c4
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I34708c73d8084db4e6c83a39be8fdaeaa492d743
After osmo-mgw changes I8e0b2d2a399b77086a36606f5e427271c6242df1 and
I99f7faab637cfcc22ece64a1dbcbe590f2042187, apply linking of new
libosmo-mgcp-client and renames to drop the "gw" from mgcp_client_*.
Also rename the gsm_network.mgcpgw to mgw, to indicate that the MGCP client is
used to contact the MGW (Media Gateway).
Depends: I8e0b2d2a399b77086a36606f5e427271c6242df1 (osmo-mgw)
I99f7faab637cfcc22ece64a1dbcbe590f2042187 (osmo-mgw)
Change-Id: I093ad02ca0e532f659447c785e09678b3e6f220d
Rewire build and includes to libosmo-legacy-mgcp.
Drop osmo-bsc_mgcp and related python tests, now found in osmo-mgw.git.
libosmo-legacy-mgcp is installed from osmo-mgw, hence add the dependency to
jenkins.sh (so far using the pre_release branch).
Change-Id: Ic99d681759edce11564da62500c2aac5cf5fffe2
Remove libiu here, use the functions from libosmo-ranap instead, by applying
the ranap_ / RANAP_ prefix.
Corresponding change-id in osmo-iuh.git is I6a3f7ad15be03fb94689b4af6ccfa828c25f45c0
To be able to run the msc_vlr tests for RAN_UTRAN_IU without Iu client headers
available, add iu_dummy.h, containing mere function signatures that match
iu_dummy.c and a mostly empty struct ranap_ue_conn_ctx.
Make sure we can build with and without --enable-iu: include osmo-iuh headers
only with --enable-iu.
Change-Id: Ib8c4fcdb4766c5e575618b95ce16dce51063206b
This was originally a long series of commits converging to the final result
seen in this patch. It does not make much sense to review the smaller steps'
trial and error, we need to review this entire change as a whole.
Implement AoIP in osmo-msc and osmo-bsc.
Change over to the new libosmo-sigtran API with support for proper
SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and
IuPS interfaces.
From here on, a separate osmo-stp process is required for SCCP routing between
OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN
jenkins.sh: build from libosmo-sccp and osmo-iuh master branches now for new
M3UA SIGTRAN.
Patch-by: pmaier, nhofmeyr, laforge
Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
osmo-nitb becomes osmo-msc
add DIUCS debug log constant
add iucs.[hc]
add msc vty, remove nitb vty
add libiudummy, to avoid linking Iu deps in tests
Use new msc_tx_dtap() instead of gsm0808_submit_dtap()
libmgcp: add mgcpgw client API
bridge calls via mgcpgw
Enable MSC specific CTRL commands, bsc_base_ctrl_cmds_install() still needs to
be split up.
Change-Id: I5b5b6a9678b458affa86800afb1ec726e66eed88
Vadim Yanitskiy
Philipp Maier
Pau Espin
Harald Welte
Neels Hofmeyr