Commit Graph

9 Commits

Author SHA1 Message Date
Neels Hofmeyr 6efafb1219 BSSMAP RESET: move cancel-paging call to osmo_bsc_sigtran_reset()
So far we would cancel ongoing Paging for a given MSC only after receiving a
RESET message from that BSC. However, the typical operation would be that
OsmoBSC *sends* a RESET and receives a RESET-ACK.

Instead, move the call to within osmo_bsc_sigtran_reset(). This is also called
when OsmoBSC considers the A-interface link to be lost, from the a_reset.c
code, after multiple SCCP connection failures.

Change-Id: Ia14b916be56563d18632c69a833084e71799a468
2020-10-15 05:28:44 +02:00
Neels Hofmeyr c27ae2da55 BSSMAP RESET: generalize a_reset FSM
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
2020-10-15 05:28:24 +02:00
Neels Hofmeyr 1ae1826245 LCS: implement re-use of existing A-interface conn
Location Services brings a new scenario to OsmoBSC: the MSC may create an
A-interface conn for a subscriber without an lchan being established (N-CONNECT
from MSC to BSC, so far only for an incoming inter-BSC handover).

If an MS becomes active while an A-interface conn is already established,
associate with an existing conn.

Change-Id: I42290f519a419ed7e8dd02a5ed0a5261b30a51e6
2020-10-07 11:40:12 +00:00
Martin Hauke a29affda98 Fix some typos
Fix typos and common misspellings in code comments and in the manual.

Change-Id: I46fc9d424620c77ae9ccf78b58081bd303386d7c
2019-11-13 22:10:41 +01:00
Harald Welte 1626f90946 Re-introduce support for IPA-encapsulated MGCP
Old osmo-bsc-sccplite already supported this, but in the migration
over to libosmo-sigtran and to real 3GPP AoIP, this functionality
got lost.

We now create a UDP proxy socket. Any MGCP commands received via IPA
from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on
this socket.  Any responses back from the MGW received on the UDP
socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA
multiplex.

Closes: OS#2536
Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2019-06-18 18:09:26 +00:00
Harald Welte 68e4be9c84 Remove 'struct bsc_msc_connection' + fix IPA-encapsulated CTRL
The bsc_msc_connection dates back to the old pre-libosmo-sigtran
days, and 90% of the field members weren't used at all (even the
new sigtran specific ones!).  Let's merge what remains into struct
bsc_msc_data.

As a side effect, the already dysfunctional "dest A.B.C.D" VTY
command has been removed from the MSC node.

There's quite a bit of fall-out in the CTRL interface, which was
the code with strongest ties to bsc_msc_connection.  This was
resolved by properly porting CTRL handling over to libosmo-sigtran,
meaning that an IPA/SCCPlite connected MSC can now again send CTRL
GET/SET commands, and can also receive those selective few TRAPs
that old osmo-bsc-sccplite also sent to its MSC[s].

Change-Id: I6b7354f3b23a26bb4eab12213ca3d3b614c8154f
Related: OS#2012
2018-05-27 20:17:02 +02:00
Harald Welte 3561bd4897 introduce an osmo_fsm for gsm_subscriber_connection
In the current implementation of osmo-bsc, the subscriber connection is
not handled (very) statefully. However, there is some state keeping in the
code that handles the mgcp connection, but there are still to much loose ends
which allow odd situations to happen, which then lead severe error situations
(see also closes tags at the end) This commit adds a number of improvements
to fix those problems.

- Use an osmo-fsm to control the gsm_subscriber_connection state and
  make sure that certain operations can only take place at certain states
  (e.g let connection oriented SCCP traffic only pass when an SCCP connection
  actually exists.

  Remove the old osmo_bsc_mgcp.c code. Use the recently developed MGCP client
  FSM to handle the MGCP connections.

  Also make sure that stuff that already works does not break. This in
  particular refers to the internal handover capability and the respective
  unit-tests.

  See also OS#2823, OS#2768 and OS#2898

- Fix logic to permit assignment to a signalling channel. (OS#2762)

- Introduce T993210 to release lchan + subscr_conn if MSC fails to respond

  The GSM specs don't have an explicit timer for this, so let's introdcue
  a custom timer (hence starting with 99).

  This timeout catches the following situation:
  * we send a SCCP CR with COMPL_L3_INFO from the MS to the MSC,
  * the MSC doesn't respond (e.g. SCCP routing failure, program down, ...)

  The MS is supposed to timeout with T3210, 3220 or 3230.  But the BSC
  shouldn't trust the MS but have some timer on its own.

  SCCP would have a timer T(conn est), but that one is specified to be
  1-2min and hence rather long.

  See also: OS#2775

- Terminate bsc_subscr_conn_fsm on SCCP N-DISC.ind from MSC

  If the MSC is disconnecting the SCCP channel, we must terminate the FSM
  which in turn will release all lchan's and other state.

  This makes TC_chan_rel_hard_rlsd pass, see also OS#2731

  As a side-effect, this fixes TC_chan_act_ack_est_ind_refused(),
  where the MSC is answering with CREF to our CR/COMPL_L3.

- Release subscriber connection on RLL RELEASE IND of SAPI0 on main DCCH

  The subscriber connection isn't really useful for anything after the
  SAPI0 main signalling link has been released.  We could try to
  re-establish, but our best option is probably simply releasing the
  subscriber_conn and anything related to it.

  This will make TC_chan_rel_rll_rel_ind pass, see also OS#2730

This commit has been tested using the BSC_Tests TTCN3 testsuit and the
following tests were passed:

TC_chan_act_noreply
TC_chan_act_ack_noest
TC_chan_act_ack_est_ind_noreply
TC_chan_act_ack_est_ind_refused
TC_chan_act_nack
TC_chan_exhaustion
TC_ctrl
TC_chan_rel_conn_fail
TC_chan_rel_hard_clear
TC_chan_rel_hard_rlsd
TC_chan_rel_a_reset
TC_rll_est_ind_inact_lchan
TC_rll_est_ind_inval_sapi1
TC_rll_est_ind_inval_sapi3
TC_rll_est_ind_inval_sacch
TC_assignment_cic_only
TC_assignment_csd
TC_assignment_ctm
TC_assignment_fr_a5_0
TC_assignment_fr_a5_1_codec_missing
TC_assignment_fr_a5_1
TC_assignment_fr_a5_3
TC_assignment_fr_a5_4
TC_paging_imsi_nochan
TC_paging_tmsi_nochan
TC_paging_tmsi_any
TC_paging_tmsi_sdcch
TC_paging_tmsi_tch_f
TC_paging_tmsi_tch_hf
TC_paging_imsi_nochan_cgi
TC_paging_imsi_nochan_lac_ci
TC_paging_imsi_nochan_ci
TC_paging_imsi_nochan_lai
TC_paging_imsi_nochan_lac
TC_paging_imsi_nochan_all
TC_paging_imsi_nochan_plmn_lac_rnc
TC_paging_imsi_nochan_rnc
TC_paging_imsi_nochan_lac_rnc
TC_paging_imsi_nochan_lacs
TC_paging_imsi_nochan_lacs_empty
TC_paging_imsi_a_reset
TC_paging_counter
TC_rsl_drop_counter
TC_classmark
TC_unsol_ass_fail
TC_unsol_ass_compl
TC_unsol_ho_fail
TC_err_82_short_msg
TC_ho_int

Authors:
Harald Welte <laforge@gnumonks.org>
Philipp Maier <pmaier@sysmocom.de>
Neels Hofmeyr <neels@hofmeyr.de>

Closes: OS#2730
Closes: OS#2731
Closes: OS#2762
Closes: OS#2768
Closes: OS#2775
Closes: OS#2823
Closes: OS#2898
Closes: OS#2936
Change-Id: I68286d26e2014048b054f39ef29c35fef420cc97
2018-03-16 18:49:47 +00:00
Harald Welte 519c7e1d42 Structural reform: Get rid of osmo_bsc_sccp_con
There was always a 1:1 correspondence between gsm_subscriber_connection
and osmo_bsc_sccp_con, so there's really no point in having two separate
dynamically allocated data structures with pointers back and forth and
another linked list around.

Let's merge osmo_bsc_sccp_con into gsm_subscriber_connection for
simplicity.

The resulting code might not be elegant in places, but I've tried to
do only the most simple changes in this patch, while further
simplifications can be done in later subsequent patches.

As a side-effect, this patch also fixes lchan clearing if the MSC
(or the local SCCP provider) hard-disconnects the SCCP connection.

Change-Id: Idd2b733477ee90d24dec369755a00f1c39c93f39
2018-02-19 08:20:35 +00:00
Neels Hofmeyr c01647914b move include/openbsc to include/osmocom/bsc
Change-Id: I39e7b882caa98334636d19ccd104fd83d07d5055
2017-09-06 16:26:13 +02:00