Commit Graph

182 Commits

Author SHA1 Message Date
Neels Hofmeyr c4628a3ad4 large refactoring: support inter-BSC and inter-MSC Handover
3GPP TS 49.008 '4.3 Roles of MSC-A, MSC-I and MSC-T' defines distinct roles:
- MSC-A is responsible for managing subscribers,
- MSC-I is the gateway to the RAN.
- MSC-T is a second transitory gateway to another RAN during Handover.

After inter-MSC Handover, the MSC-I is handled by a remote MSC instance, while
the original MSC-A retains the responsibility of subscriber management.

MSC-T exists in this patch but is not yet used, since Handover is only prepared
for, not yet implemented.

Facilitate Inter-MSC and inter-BSC Handover by the same internal split of MSC
roles.

Compared to inter-MSC Handover, mere inter-BSC has the obvious simplifications:
- all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc
  instance,
- messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface
  (GSUP),
- no call routing between MSC-A and -I via MNCC necessary.

This is the largest code bomb I have submitted, ever. Out of principle, I
apologize to everyone trying to read this as a whole. Unfortunately, I see no
sense in trying to split this patch into smaller bits. It would be a huge
amount of work to introduce these changes in separate chunks, especially if
each should in turn be useful and pass all test suites. So, unfortunately, we
are stuck with this code bomb.

The following are some details and rationale for this rather huge refactoring:

* separate MSC subscriber management from ran_conn

struct ran_conn is reduced from the pivotal subscriber management entity it has
been so far to a mere storage for an SCCP connection ID and an MSC subscriber
reference.

The new pivotal subscriber management entity is struct msc_a -- struct msub
lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however
use msc_a, since MSC-A is where all the interesting stuff happens.

Before handover, msc_i is an FSM implementation that encodes to the local
ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM
implementation that instead forwards via/from GSUP. Same goes for the msc_a
struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the
msc_a->fi is an FSM implementation that merely forwards via/from GSUP.

* New SCCP implementation for RAN access

To be able to forward BSSAP and RANAP messages via the GSUP interface, the
individual message layers need to be cleanly separated. The IuCS implementation
used until now (iu_client from libosmo-ranap) did not provide this level of
separation, and needed a complete rewrite. It was trivial to implement this in
such a way that both BSSAP and RANAP can be handled by the same SCCP code,
hence the new SCCP-RAN layer also replaces BSSAP handling.

sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN
connections. A set of callback functions provides implementation specific
details.

* RAN Abstraction (BSSAP vs. RANAP)

The common SCCP implementation did set the theme for the remaining refactoring:
make all other MSC code paths entirely RAN-implementation-agnostic.

ran_infra.c provides data structures that list RAN implementation specifics,
from logging to RAN de-/encoding to SCCP callbacks and timers. A ran_infra
pointer hence allows complete abstraction of RAN implementations:

- managing connected RAN peers (BSC, RNC) in ran_peer.c,
- classifying and de-/encoding RAN PDUs,
- recording connected LACs and cell IDs and sending out Paging requests to
  matching RAN peers.

* RAN RESET now also for RANAP

ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also
supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide
proper RESET handling, which it so far duly ignores. (TODO)

* RAN de-/encoding abstraction

The RAN abstraction mentioned above serves not only to separate RANAP and BSSAP
implementations transparently, but also to be able to optionally handle RAN on
distinct levels. Before Handover, all RAN messages are handled by the MSC-A
role.  However, after an inter-MSC Handover, a standalone MSC-I will need to
decode RAN PDUs, at least in order to manage Assignment of RTP streams between
BSS/RNC and MNCC call forwarding.

ran_msg.h provides a common API with abstraction for:

- receiving events from RAN, i.e. passing RAN decode from the BSC/RNC and
  MS/UE: struct ran_dec_msg represents RAN messages decoded from either BSSMAP
  or RANAP;
- sending RAN events: ran_enc_msg is the counterpart to compose RAN messages
  that should be encoded to either BSSMAP or RANAP and passed down to the
  BSC/RNC and MS/UE.

The RAN-specific implementations are completely contained by ran_msg_a.c and
ran_msg_iu.c.

In particular, Assignment and Ciphering have so far been distinct code paths
for BSSAP and RANAP, with switch(via_ran){...} statements all over the place.
Using RAN_DEC_* and RAN_ENC_* abstractions, these are now completely unified.

Note that SGs does not qualify for RAN abstraction: the SGs interface always
remains with the MSC-A role, and SGs messages follow quite distinct semantics
from the fairly similar GERAN and UTRAN.

* MGW and RTP stream management

So far, managing MGW endpoints via MGCP was tightly glued in-between
GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP
streams between different RAN peers by moving to object-oriented
implementations: implement struct call_leg and struct rtp_stream with distinct
FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated
from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose.
Instead of implementing a sequence of events with code duplication for the RAN
and CN sides, the idea is to manage each RTP stream separately by firing and
receiving events as soon as codecs and RTP ports are negotiated, and letting
the individual FSMs take care of the MGW management "asynchronously". The
caller provides event IDs and an FSM instance that should be notified of RTP
stream setup progress. Hence it becomes possible to reconnect RTP streams from
one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP
peers (inter-MSC Handover) without duplicating the MGCP code for each
transition.

The number of FSM implementations used for MGCP handling may seem a bit of an
overkill. But in fact, the number of perspectives on RTP forwarding are far
from trivial:
- an MGW endpoint is an entity with N connections, and MGCP "sessions" for
  configuring them by talking to the MGW;
- an RTP stream is a remote peer connected to one of the endpoint's
  connections, which is asynchronously notified of codec and RTP port choices;
- a call leg is the higher level view on either an MT or MO side of a voice
  call, a combination of two RTP streams to forward between two remote peers.

  BSC                 MGW                PBX
                CI          CI
                [MGW-endpoint]
  [--rtp_stream--]          [--rtp_stream--]
  [----------------call_leg----------------]

* Use counts

Introduce using the new osmo_use_count API added to libosmocore for this
purpose. Each use token has a distinct name in the logging, which can be a
globally constant name or ad-hoc, like the local __func__ string constant.  Use
in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count
API.

* FSM Timeouts

Introduce using the new osmo_tdef API, which provides a common VTY
implementation for all timer numbers, and FSM state transitions with the
correct timeout. Originated in osmo-bsc, recently moved to libosmocore.

Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
         Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore)
	 Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore)
	 Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp)
	 I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw)
	 Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw)
	 I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)
Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
2019-05-08 17:02:32 +02:00
Neels Hofmeyr 08aae21fca vlr subscr get/put: also check against NULL
Change-Id: I36929a4ba4abb46909181068d1d0af967b1f5a94
2019-04-26 18:55:25 +00:00
Neels Hofmeyr ff7074a0c7 add LOG_TRANS, proper context for all transactions
Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-04-12 02:15:25 +02:00
Neels Hofmeyr 7c5346cd70 vlr_subscr: use osmo_use_count
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
Change-Id: Ib06d030e8464abe415ff597d462ed40eeddef475
2019-04-12 02:15:25 +02:00
Vadim Yanitskiy 0f52319765 msc/gsm_data.h: drop unused SMS_HDR_SIZE macro
Change-Id: Iea32a26673ebb57b18dc7e86ad321d9ed48e0948
2019-04-08 07:34:20 +00:00
Sylvain Munaut da9f37ed20 libvlr: Allow 2G auth tuples to be re-used without going through AUTH
If the key_seq we get in the first messages matches the last_tuple, then
both we and the MS already know the key to use and we don't need the
AUTH REQUEST/RESPONSE cycle.

Security wise ... not so good, and so IMHO the 'auth required' option
in the MSC should always be set. But this allows to turn on ciphering on
a channel without doing any MM transaction, and so the MS doesn't turn
on the T3240 timer which allows to have a ciphered silent-call channel
that won't timeout.

Change-Id: Ief840a2ae7a0ffd2bf0bf726f209a79e3f787646
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2019-03-19 15:24:01 +00:00
Sylvain Munaut 935583069d libmsc: Allow different channel types to be requested as silent calls
Change-Id: I82645708dd27864cf33ea9cc993ead0983415602
2019-03-14 12:39:31 +00:00
Vadim Yanitskiy 64623e1848 libmsc/gsm_09_11.c: implement guard timer for NCSS sessions
It may happen that either the MS or an EUSE would become
unresponsive during a call independent SS session, e.g.
due to a bug, or a dropped message. In such cases, the
corresponding transaction would remain unfreed forever.

This change introduces a guard timer, that prevents keeping
'stalled' NCSS sessions forever. As soon as it expires, both
sides (i.e. MS and EUSE) are getting notified, and the
transaction is being released.

By default, the timer expires after 30 seconds. As soon as
either the MS, or an EUSE initiates any activity,
the watchdog timer is rescheduled.

The timeout value can be configured from the VTY:

  msc
   ...
   ! Use 0 to disable this timer
   ncss guard-timeout 30

Please note that changing the timeout value at run-time
doesn't affect the existing NCSS sessions, excepting the
case when the timer is disabled at run-time.

This change makes TC_lu_and_ss_session_timeout pass.

Change-Id: Icf4d87c45e90324764073e8230e0fb9cb96dd9cb
Related Change-Id: (TTCN) I3e1791773d56617172ae27a46889a1ae4d400e2f
Related: OS#3655
2019-02-20 03:22:38 +07:00
Harald Welte fd96d45049 a_iface: use 'const' qualifier for ran_conn whenever possible
Change-Id: I8a15c9baae2071569e2ecc4635ddaf5a0001f959
2019-02-18 13:52:09 +01:00
Vadim Yanitskiy 2eaee70ada transaction.h: use #pragma once as include guard
Change-Id: I52787120d5ec59897329d28eab28e0fda3d0f44f
2019-02-15 02:19:30 +07:00
Max d8daaae91e transaction: clarify magic 0xff transaction ID
Change-Id: I2d3a6334f49989bedbb1430d26ffad8b61dfd873
2019-02-15 02:19:30 +07:00
Max 30fb97aa43 transaction: drop meaningless ti_flag of trans_assign_trans_id()
According to GSM 04.07, the TI flag takes one bit and can be
either of the following:

  '0'B - transaction is allocated by sender of a message,
  '1'B - transaction is allocated by receiver of a message.

Since we store transaction ID in gsm_trans structure, we also store
TI flag (as a part of transaction ID), which in this context means:

  '0'B - transaction is allocated by us (OsmoMSC),
  '1'B - transaction is allocated by some MS.

In 100% cases, trans_assign_trans_id() is used to assign transaction IDs
to transactions allocated by us (i.e. OsmoMSC) for MT connections. And
there is no need to use it for MO transactions, because they basically
already do contain a valid transaction ID assigned by the MS.

Change-Id: Ie11999900b1789652ee078d34636dcda1e137eb0
2019-02-15 02:19:24 +07:00
Vadim Yanitskiy 3acfe68b8b libmsc/gsm_04_80.c: add msc_send_ussd_release_complete_cause()
According to GSM 04.80, section 2.5.1, Release complete message
may have an optional Cause IE. Let's add a new function, that
allows to specify cause location and value.

This function will be used by the upcoming changes.

Change-Id: I3b9e8e4f473d113d5b9e9e5d33f7914202077203
Depends Change-Id: (libosmocore) Ie3ac85fcef90a5e532334ba3482804d5305c88d7
2019-02-13 12:50:14 +00:00
Vadim Yanitskiy f20c6b7bd5 libmsc/gsm_04_80.c: use gsm0480_create_release_complete()
The previous implementation of msc_send_ussd_release_complete() was
based on gsm0480_create_ussd_release_complete(), that doesn't
allow to specify GSM 04.07 transaction identifier.

The ability to specify particular transaction identifier
is required for handling multiple SS/USSD transactions.

Change-Id: Id2975c3383f18e83124ba38927c03980d67ddadb
Depends Change-Id: (libosmocore) Ie3ac85fcef90a5e532334ba3482804d5305c88d7
2019-02-13 12:50:14 +00:00
Harald Welte 0df904dea9 Add SGs Interface
Add an SGs interface (3GPP TS 29.118) to osmo-msc in order to support
SMS tunneling and Circuit Switched Fallback (CSFB)

Change-Id: I73359925fc1ca72b33a1466e6ac41307f2f0b11d
Related: OS#3615
2019-02-04 13:36:26 +01:00
Vadim Yanitskiy c7de62cc53 libmsc/gsm_04_11.c: introduce and use gsm411_assign_sm_rp_mr()
Initially, it was assumed that if there is no active RAN connection,
we can just start counting from 0x00, as there are no other SMS
related transactions, and transaction itself is allocated using
talloc_zero(). Until now it was looking good, but...

As soon as we establish RAN connection with subscriber, we already
have a transaction with SM-RP-MR 0x00, but conn->next_rp_ref also
remains 0x00 - it isn't being increased!

It means that we can face a SM-RP-MR conflict (or collision) if
another MT SMS would arrive to the MSC (from SMSC over GSUP)
when this transaction is still active, i.e. the first SMS is
still being sent, because conn->next_rp_ref++ would
return 0x00 again.

Moreover, there might be already a MO SMS transaction, and using
the conn->next_rp_ref counter wouldn't prevent us from having
duplicate SM-RP-MR value.

Let's get rid of this per-connection counter, and introduce a
function instead, that would iterate over existing transactions
and look for an unused SM-RP-MR value.

This change makes the following test cases pass:

  - TC_gsup_mt_sms_rp_mr,
  - TC_gsup_mo_mt_sms_rp_mr.

Discovered by: Neels Hofmeyr
Related Change-Id: (TTCN) I3a52d44f4abde9b6b471b9108c1cee905884c9bc
Related Change-Id: (TTCN) I17cbbaa64d9bce770f985588e93cd3eecd732120
Change-Id: Ife6d954c46b7d8348a4221ab677d0355eb3ee7ac
2019-02-01 18:55:54 +00:00
Vadim Yanitskiy 36c44b2100 transaction: change arguments of trans_find_by_sm_rp_mr()
The need to pass a pointer to RAN connection in order to find
a transaction limits possible use cases of trans_find_by_sm_rp_mr(),
e.g. when we need to find a transaction, but RAN connection is not
established yet.

Moreover, the pointer to RAN connection was only used to obtain
pointers to gsm_network and vlr_subscr, so we can just
pass them directly.

Change-Id: I093f36d63e671e50e54fc6236e97a777cc6da77b
2019-02-01 18:55:54 +00:00
Max 6b3cef08d2 MNCC: use explicit struct type in gsm_call
There's no need to use 'void *' because we have forward declaration for
'struct gsm_network' in the very same header.

Change-Id: I5078ffcf2706adaca1b5df107f8b6a44062ca28c
2019-01-16 12:56:59 +00:00
Oliver Smith 7d05309e3a VLR: send CHECK-IMEI to EIR/HLR
When check-imei-req is enabled in the VTY config, do not accept IMEIs
sent by the ME directly anymore. Send the IMEI to the EIR/HLR and wait
for its ACK or NACK.

OsmoHLR also accepts all IMEIs at this point, but this allows to
optionally store the IMEI in the HLR DB.

Depends: Ib240474b0c3c603ba840cf26babb38a44dfc9364 (osmo-hlr)
Related: OS#3733
Change-Id: Ife868ed71c36cdd02638072abebf61fc949080a7
2019-01-16 10:42:56 +00:00
Neels Hofmeyr 361e571815 refactor log ctx for vlr_subscr and ran_conn
ran_conn_get_conn_id(): instead of a talloc allocated string, return a static
buffer in ran_conn_get_conn_id(). So far this function had no callers.

Refactor ran_conn_update_id() API: during early L3-Complete, when no subscriber
is associated yet, update the FSM Id by the MI type seen in the L3 Complete
message: ran_conn_update_id_from_mi(). Later on set the vsub and re-update.

Call vlr.ops->subscr_update when the TMSI is updated, so that log context
includes the TMSI from then on.

Enrich context for vlr_subscr_name and ran_conn fi name.

Include all available information in vlr_subscr_name(); instead of either IMSI
or MSISDN or TMSI, print all of them when present. Instead of a short log,
rather have more valuable context.

A context info would now look like:

  Process_Access_Request_VLR(IMSI-901700000014706:MSISDN-2023:TMSI-0x08BDE4EC:GERAN-A-3:PAGING_RESP)

It does get quite long, but ensures easy correlation of any BSSAP / IuCS
messages with log output, especially if multiple subscribers are busy at the
same time.

Print TMSI and TMSInew in uppercase hexadecimal, which is the typical
representation in the telecom world.

When showing the RAN conn id
  GERAN_A-00000017
becomes
  GERAN-A-23
- We usually write the conn_id in decimal.
- Leading zeros are clutter and might suggest hexadecimal format.
- 'GERAN-A' and 'UTRAN-Iu' are the strings defined by osmo_rat_type_name().

Depends: I7798c3ef983c2e333b2b9cbffef6f366f370bd81 (libosmocore)
Depends: Ica25919758ef6cba8348da199b0ae7e0ba628798 (libosmocore)
Change-Id: I66a68ce2eb8957a35855a3743d91a86299900834
2019-01-12 09:51:22 +00:00
Neels Hofmeyr 46c06e28c1 add LOG_RAN_CONN() to use the conn->fi->id for context
For each conn, set a default logging category, to distinguish categories for
BSSMAP and RANAP based conns.

LOG_RAN_CONN(): log with the conn's default category,

LOG_RAN_CONN_CAT(): log with a manually set category (mostly for keeping
previous DMM logging on the same category).

In some places, replace LOGP() using manual context with LOG_RAN_CONN(), and
remove the manual context info, now provided by the conn->fi->id.

This is loosely related to inter-BSC and inter-MSC handover: to speed up
refactoring, I want to avoid the need for manual logging context and just use
this LOG_RAN_CONN().

Change-Id: I0a7809840428b1e028df6eb683bc5ffcc8df474a
2019-01-12 09:51:22 +00:00
Vadim Yanitskiy 82cc8a5cfa libmsc/gsm_04_11.c: accept MT SMS messages over GSUP
Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88
Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71
Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f
Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f
Related: OS#3587
2019-01-11 21:42:43 +00:00
Oliver Smith 5598aaef23 VLR: vlr_subscr_{,msisdn_or_}name: const vsub arg
Make the vsub argument of both vlr_subscr_msisdn_or_name()
and vlr_subscr_name() a const.

The LOGVSUBP() macro uses vlr_subscr_name() and will not generate a
warning anymore when used with a const vsub.

Change-Id: If609269191f4df6186d823a2eee14012846328e2
2019-01-09 14:34:34 +00:00
Neels Hofmeyr 7814a83298 use osmo_rat_type from libosmocore
Replace locally defined enum ran_type with libosmocore's new enum
osmo_rat_type, and value_string ran_type_names with osmo_rat_type_names.

The string representations change, which has cosmetic effects on the test suite
expectations.

Depends: I659687aef7a4d67ca372a39fef31dee07aed7631 (libosmocore)
Change-Id: I2c78c265dc99df581e1b00e563d6912c7ffdb36b
2019-01-04 17:26:14 +00:00
Neels Hofmeyr f383d411e6 abort assignment on Assignment Failure
If Assignment fails in the BSC, trigger an EV_TEARDOWN_ERROR in the mgcp_ctx
FSM instance, so that the call gets torn down immediately. Before this, the
non-call would idle around without anything happening.

Related: OS#3236
Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore)
Change-Id: I358cfbaf0f44f25148e8b9bafcb9257b1952b35a
2019-01-04 16:24:59 +00:00
Neels Hofmeyr a35712d576 move trans->assignment_done to cc.assignment_started
The flag is set to true when an assignment has been started, and it is only
relevant for a CC transaction. So fix naming and place in cc struct.

Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and
I0ba216b737909e92080a722db26e3577726c63cb/

Change-Id: I8dacf46141ba0b664e85b0867ade330c97d8495f
2019-01-04 16:24:59 +00:00
Neels Hofmeyr b16259f9ad remove code dup: add msc_mgcp_try_call_assignment()
Various places in the code check a flag whether assignment was started and
launch it. To fix incoming-call-during-ongoing-call, I will tweak that logic.
To be able to do that only in one place, remove code dup.

Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and
I0ba216b737909e92080a722db26e3577726c63cb/

Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore: LOGPFSMSL)
Change-Id: I11c0b7dc3f1a747028629b48e522bb3b864884ba
2019-01-04 16:24:59 +00:00
Max 7916ca1c2d Constify transaction helpers parameters
Change-Id: If002a1ff6ba4218cc16592946798340fcb1852ae
2019-01-04 09:38:07 +00:00
Neels Hofmeyr 1035d90c17 fix vlr ops.subscr_assoc re-association
In rare cases, a conn is already associated with a subscriber. So far, we
abort()ed on that, bringing the entire osmo-msc down. Rather log an error and
keep the service running.

In vlr.ops.subscr_assoc, add success/failure return value, and abort the
LU/PARQ on error.

I haven't figured out in detail yet why/how a subscriber would re-launch a
LU/PARQ on a conn that is already associated, so far it is merely clear that we
do not want to crash the MSC if that happens. A log is in OS#3742.

Related: OS#3742, OS#3743
Change-Id: Ic0d54644bc735700220b1ef3a4384c217d57d20f
2019-01-04 01:46:46 +00:00
Vadim Yanitskiy 76ef72dda8 libmsc/gsm_04_11.c: forward MO SMS messages over GSUP
Change-Id: I7d651fde3d608d02f275a74043dc42262aabb1b8
Depends-on: (core) Ic37f3b2114b8095cfce22977e67133b9103942e3
Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71
Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f
Related Change-Id: (TTCN) I7abc95b8e416f7308d54e11be11c08586d18e6c5
Related Change-Id: (TTCN) Id14bbd8bd51558cdacefea0fe042769cd69ed5c8
Related: OS#3587
2018-12-30 11:48:22 +01:00
Vadim Yanitskiy f40e46fdf4 libmsc/VTY: introduce kill-switch for routing SMS over GSUP
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
2018-12-30 11:48:22 +01:00
Stefan Sperling b361ea7037 use vty->type instead of local variable
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
2018-12-21 12:38:47 +00:00
Max 7d41d870de Remove redundancy in LAC processing
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
2018-12-19 11:48:33 +01:00
Max 4776b0526c VLR: drop unused struct members
Change-Id: I322072653b41cf250aa2c1e346e00bae884feb84
2018-12-18 17:57:27 +00:00
Stefan Sperling 1051c42088 require 'ipa-name' option to be set via config file
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
2018-12-13 10:16:49 +01:00
Neels Hofmeyr 85cb2538f4 Revert "move ASS-COMPL MGCP handling out of a_iface_bssap.c"
Two reasons:

- the caller of msc_mgcp_ass_complete() from Iu, iucs_rx_rab_assign(), failed
  to be adjusted, breaking IuCS, as an --enable-iu --enable-werror build shows.
  Unfortunately our gerrit verification doesn't --enable-werror for osmo-msc.

- the condition of requiring ST_MDCX_RAN is faulty, breaking GSM CS.

This reverts commit 212c0c9bda.

Change-Id: I8348675c2f7c8856ea1682d05ee54160d4cfeb96
2018-12-11 19:52:30 +01:00
Stefan Sperling afa030d6f9 make gsup ipa name configurable in osmo-msc.cfg
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
2018-12-11 13:08:00 +00:00
Neels Hofmeyr 212c0c9bda move ASS-COMPL MGCP handling out of a_iface_bssap.c
BSSMAP Assignment Complete: sort MGCP handling upon Assignment Complete to the
proper locations. a_iface_bssap.c is not the right place to invoke the MGCP
related procedures.

- in a_iface_bssap.c only decode the IEs.
- call ran_conn_assign_compl() and pass decoded values.
- drop msc_assign_compl(), it was dead code; instead:
- add ran_conn_assign_compl()
- pass on all MGCP related info to msc_mgcp_ass_complete()
- move all MGCP ctx related handling from a_iface_bssap.c to msc_mgcp.c.

I'm dropping some comments to save some time, because if I adjust them IMHO
they would still anyway restate the obvious.

ran_conn_assign_compl() is now quite a thin shim, but it makes sense to have
it:

- This is the place that should tear down the ran_conn in case assignment
  failed, left for a future patch.

- In the light of upcoming inter-MSC handover, ran_conn_assign_compl() will be
  the place where the Assignment Complete message might be relayed to a remote
  MSC.

Change-Id: I8137215c443239bddf3e69b5715839a365b73b6c
2018-12-10 14:20:59 +01:00
Neels Hofmeyr 80447ebe6c add VTY commands: mncc internal / external (== -M)
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
2018-12-05 19:35:11 +00:00
Neels Hofmeyr 1263bc8017 move gsm_cbfn to gsm_subscriber.h, the only user
(with two less line feeds)

Change-Id: I375e5b021e643f6b1986ea35ebaf3a6d60e189f5
2018-11-30 22:46:15 +01:00
Neels Hofmeyr 9587759c71 drop cruft from gsm_subscriber.h
Change-Id: If6e2252486fe8d932f229a70ce5a4b6f22f6fc52
2018-11-30 22:46:15 +01:00
Neels Hofmeyr 7b61ffe69b GSM_EXTENSION_LENGTH -> VLR_MSISDN_LENGTH
gsm_subscriber.h contains some legacy cruft, part of which is that the VLR's
max MSISDN length should rather be defined in vlr.h. Same for GSM_NAME_LENGTH
-> VLR_NAME_LENGTH.

Adjust some sms_queue stuff that anyway includes vlr.h already.

Drop gsm_subscriber.h from vlr.h.

Add other (more concise) includes that thus become necessary, since the include
chain vlr.h->gsm_subscriber.h->gsm_data.h is no longer in place.

Change-Id: Iab5c507ec04fc2884187cf946f6ae2240e4a31f8
2018-11-30 22:46:15 +01:00
Neels Hofmeyr 8b6e536007 move gsm_auth_tuple to vlr.h as vlr_auth_tuple
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
2018-11-30 22:46:15 +01:00
Neels Hofmeyr df6d2e3838 cosmetic: drop some unused opaque struct defs
Change-Id: I4d461dd39d0abdc4f2327445671459340ca1c946
2018-11-30 22:46:15 +01:00
Neels Hofmeyr 7992122bac combine several small .h in msc_common.h
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
2018-11-30 22:46:15 +01:00
Neels Hofmeyr a8945ce37c move ran_conn declarations to new ran_conn.h
With the dawn of inter-BSC,MSC handover, adopting the MSC-A,-I,-T roles from
3GPP TS 49.008, the RAN connection shall soon be a neatly separated corner of
osmo-msc, so gravitate ran_conn decarations to files of matching name.

Also, the current chaos of API defined in files with mismatching/meaningless
names drives me crazy.

Change-Id: Ice31e6c43e46678538c65261f150c67e1d0845e5
2018-11-30 22:46:15 +01:00
Neels Hofmeyr 3c20a5ee74 rename some RAN conn related stuff to ran_conn_*
Following previous rename of gsm_subscriber_connection:

Some functions and #defines are still called like "msc_conn" or just "msc_",
while they are clearly about a RAN conn.

To avoid confusion with the future separate concepts of MSC roles and a RAN
connection, rename all those to match the common "ran_conn" prefix.

Change-Id: Ia17a0a35f11911e00e19cafb5d7828d729a69640
2018-11-30 22:46:13 +01:00
Neels Hofmeyr c036b79918 rename gsm_subscriber_connection to ran_conn
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
2018-11-30 22:45:42 +01:00
Neels Hofmeyr d03e728915 drop msc_compl_l3() return value
msc_compl_l3() always returns MSC_CONN_ACCEPT, because the conn FSM handles (or
should handle) all reject cases. The accept/reject return value is a legacy
from libbsc internally passing a conn over to libmsc, in osmo-nitb.

Drop enum msc_compl_l3_rc.
Change msc_compl_l3_rc() to return void.
Change all callers to always act like for acceptance, as they always did anyway.
Drop some local variables now no longer needed.
Adjust the comment to msc_compl_l3().
Drop a bunch of #if-0'd code from msc_compl_l3().

Change-Id: I759d15f4e820d5fc16397ed7210ce92308e52a09
2018-11-30 22:44:23 +01:00
Neels Hofmeyr f41658d52e rename gsm_encr to geran_encr, it is only applicable on GERAN
On UTRAN, Security Mode is used instead of Ciphering Command, which does not
feature an A5 algorithm id.

Change-Id: Idc7ca9da1aa13ae16f5db2cb1024676cbc770820
2018-11-30 22:44:23 +01:00