Change in osmo-msc[master]: large refactoring: split RAN (MSC-I) and MSC-A roles

Neels Hofmeyr gerrit-no-reply at lists.osmocom.org
Tue Mar 5 22:33:58 UTC 2019


Neels Hofmeyr has uploaded this change for review. ( https://gerrit.osmocom.org/13137


Change subject: large refactoring: split RAN (MSC-I) and MSC-A roles
......................................................................

large refactoring: split RAN (MSC-I) and MSC-A roles

As a prerequisite to inter-MSC Handover support, split the RAN connection from
subscriber management.

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.

Inter-MSC and inter-BSC Handover are facilitated by the same internal split of
MSC roles, where 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.

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 NAS 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 NAS 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)

* NAS de-/encoding abstraction

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

nas.h provides a common API with abstraction for:

- receiving NAS events from RAN, i.e. passing NAS up from the BSC/RNC and
  MS/UE: struct nas_up_msg represents NAS messages decoded from either BSSMAP
  or RANAP;
- sending NAS events: nas_down_msg is the counterpart to compose NAS 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 nas_a.c and
nas_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 NAS_UP_* and NAS_DOWN_* abstractions, these are now completely unified.

Note that SGs does not qualify for NAS 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
---
M configure.ac
A doc/sequence_charts/Makefile.am
A doc/sequence_charts/inter_bsc_ho.msc
A doc/sequence_charts/inter_msc_ho.msc
M include/osmocom/msc/Makefile.am
D include/osmocom/msc/a_iface.h
D include/osmocom/msc/a_iface_bssap.h
D include/osmocom/msc/a_reset.h
A include/osmocom/msc/call_leg.h
M include/osmocom/msc/gsm_04_08.h
M include/osmocom/msc/gsm_04_11.h
M include/osmocom/msc/gsm_04_14.h
M include/osmocom/msc/gsm_04_80.h
M include/osmocom/msc/gsm_09_11.h
M include/osmocom/msc/gsm_data.h
M include/osmocom/msc/gsm_data_shared.h
M include/osmocom/msc/gsm_subscriber.h
D include/osmocom/msc/iu_dummy.h
D include/osmocom/msc/iucs.h
D include/osmocom/msc/iucs_ranap.h
M include/osmocom/msc/mncc.h
A include/osmocom/msc/msc_a.h
M include/osmocom/msc/msc_common.h
A include/osmocom/msc/msc_i.h
D include/osmocom/msc/msc_ifaces.h
D include/osmocom/msc/msc_mgcp.h
A include/osmocom/msc/msc_roles.h
A include/osmocom/msc/msc_t.h
A include/osmocom/msc/msub.h
A include/osmocom/msc/nas.h
A include/osmocom/msc/nas_a.h
A include/osmocom/msc/nas_iu.h
A include/osmocom/msc/paging.h
M include/osmocom/msc/ran_conn.h
A include/osmocom/msc/ran_infra.h
A include/osmocom/msc/ran_peer.h
A include/osmocom/msc/rtp_stream.h
A include/osmocom/msc/sccp_ran.h
M include/osmocom/msc/sgs_iface.h
M include/osmocom/msc/signal.h
M include/osmocom/msc/transaction.h
M include/osmocom/msc/vlr.h
M include/osmocom/msc/vlr_sgs.h
M src/libmsc/Makefile.am
D src/libmsc/a_iface.c
D src/libmsc/a_iface_bssap.c
D src/libmsc/a_reset.c
A src/libmsc/call_leg.c
M src/libmsc/gsm_04_08.c
M src/libmsc/gsm_04_08_cc.c
M src/libmsc/gsm_04_11.c
M src/libmsc/gsm_04_11_gsup.c
M src/libmsc/gsm_04_14.c
M src/libmsc/gsm_04_80.c
M src/libmsc/gsm_09_11.c
D src/libmsc/gsm_subscriber.c
D src/libmsc/iu_dummy.c
D src/libmsc/iucs.c
D src/libmsc/iucs_ranap.c
M src/libmsc/mncc_builtin.c
A src/libmsc/msc_a.c
A src/libmsc/msc_i.c
A src/libmsc/msc_i_remote.c
D src/libmsc/msc_ifaces.c
D src/libmsc/msc_mgcp.c
A src/libmsc/msc_net_init.c
A src/libmsc/msc_t.c
M src/libmsc/msc_vty.c
A src/libmsc/msub.c
A src/libmsc/nas.c
A src/libmsc/nas_a.c
A src/libmsc/nas_iu.c
D src/libmsc/osmo_msc.c
A src/libmsc/paging.c
M src/libmsc/ran_conn.c
A src/libmsc/ran_infra.c
A src/libmsc/ran_peer.c
A src/libmsc/ran_up_l2.c
M src/libmsc/rrlp.c
A src/libmsc/rtp_stream.c
A src/libmsc/sccp_ran.c
M src/libmsc/sgs_iface.c
M src/libmsc/sgs_server.c
M src/libmsc/silent_call.c
M src/libmsc/smpp_openbsc.c
M src/libmsc/smpp_smsc.h
M src/libmsc/sms_queue.c
M src/libmsc/transaction.c
M src/libvlr/vlr.c
M src/libvlr/vlr_access_req_fsm.c
M src/libvlr/vlr_lu_fsm.c
M src/libvlr/vlr_sgs.c
M src/libvlr/vlr_sgs_fsm.c
M src/osmo-msc/Makefile.am
M src/osmo-msc/msc_main.c
M tests/msc_vlr/Makefile.am
M tests/msc_vlr/msc_vlr_test_authen_reuse.c
M tests/msc_vlr/msc_vlr_test_authen_reuse.err
M tests/msc_vlr/msc_vlr_test_call.c
M tests/msc_vlr/msc_vlr_test_call.err
M tests/msc_vlr/msc_vlr_test_gsm_authen.c
M tests/msc_vlr/msc_vlr_test_gsm_authen.err
M tests/msc_vlr/msc_vlr_test_gsm_ciph.c
M tests/msc_vlr/msc_vlr_test_gsm_ciph.err
M tests/msc_vlr/msc_vlr_test_hlr_reject.c
M tests/msc_vlr/msc_vlr_test_hlr_reject.err
M tests/msc_vlr/msc_vlr_test_hlr_timeout.c
M tests/msc_vlr/msc_vlr_test_hlr_timeout.err
M tests/msc_vlr/msc_vlr_test_ms_timeout.c
M tests/msc_vlr/msc_vlr_test_ms_timeout.err
M tests/msc_vlr/msc_vlr_test_no_authen.c
M tests/msc_vlr/msc_vlr_test_no_authen.err
M tests/msc_vlr/msc_vlr_test_reject_concurrency.c
M tests/msc_vlr/msc_vlr_test_reject_concurrency.err
M tests/msc_vlr/msc_vlr_test_rest.c
M tests/msc_vlr/msc_vlr_test_rest.err
M tests/msc_vlr/msc_vlr_test_ss.c
M tests/msc_vlr/msc_vlr_test_ss.err
M tests/msc_vlr/msc_vlr_test_umts_authen.c
M tests/msc_vlr/msc_vlr_test_umts_authen.err
M tests/msc_vlr/msc_vlr_tests.c
M tests/msc_vlr/msc_vlr_tests.h
M tests/sms_queue/Makefile.am
M tests/sms_queue/sms_queue_test.c
124 files changed, 28,010 insertions(+), 21,718 deletions(-)



  git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/37/13137/1


-- 
To view, visit https://gerrit.osmocom.org/13137
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
Gerrit-Change-Number: 13137
Gerrit-PatchSet: 1
Gerrit-Owner: Neels Hofmeyr <nhofmeyr at sysmocom.de>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190305/f6c565b1/attachment-0001.html>


More information about the gerrit-log mailing list