<p>Neels Hofmeyr has uploaded this change for <strong>review</strong>.</p><p><a href="https://gerrit.osmocom.org/13137">View Change</a></p><pre style="font-family: monospace,monospace; white-space: pre-wrap;">large refactoring: split RAN (MSC-I) and MSC-A roles<br><br>As a prerequisite to inter-MSC Handover support, split the RAN connection from<br>subscriber management.<br><br>3GPP TS 49.008 '4.3 Roles of MSC-A, MSC-I and MSC-T' defines distinct roles:<br>- MSC-A is responsible for managing subscribers,<br>- MSC-I is the gateway to the RAN.<br>- MSC-T is a second transitory gateway to another RAN during Handover.<br><br>After inter-MSC Handover, the MSC-I is handled by a remote MSC instance, while<br>the original MSC-A retains the responsibility of subscriber management.<br><br>MSC-T exists in this patch but is not yet used, since Handover is only prepared<br>for, not yet implemented.<br><br>Inter-MSC and inter-BSC Handover are facilitated by the same internal split of<br>MSC roles, where inter-BSC has the obvious simplifications:<br>- all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc<br> instance,<br>- messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface<br> (GSUP),<br>- no call routing between MSC-A and -I via MNCC necessary.<br><br>The following are some details and rationale for this rather huge refactoring:<br><br>* separate MSC subscriber management from ran_conn<br><br>struct ran_conn is reduced from the pivotal subscriber management entity it has<br>been so far to a mere storage for an SCCP connection ID and an MSC subscriber<br>reference.<br><br>The new pivotal subscriber management entity is struct msc_a -- struct msub<br>lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however<br>use msc_a, since MSC-A is where all the interesting stuff happens.<br><br>Before handover, msc_i is an FSM implementation that encodes to the local<br>ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM<br>implementation that instead forwards via/from GSUP. Same goes for the msc_a<br>struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the<br>msc_a->fi is an FSM implementation that merely forwards via/from GSUP.<br><br>* New SCCP implementation for RAN access<br><br>To be able to forward BSSAP and RANAP messages via the GSUP interface, the<br>individual message layers need to be cleanly separated. The IuCS implementation<br>used until now (iu_client from libosmo-ranap) did not provide this level of<br>separation, and needed a complete rewrite. It was trivial to implement this in<br>such a way that both BSSAP and RANAP can be handled by the same SCCP code,<br>hence the new SCCP-RAN layer also replaces BSSAP handling.<br><br>sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN<br>connections. A set of callback functions provides implementation specific<br>details.<br><br>* RAN Abstraction (BSSAP vs. RANAP)<br><br>The common SCCP implementation did set the theme for the remaining refactoring:<br>make all other MSC code paths entirely RAN-implementation-agnostic.<br><br>ran_infra.c provides data structures that list RAN implementation specifics,<br>from logging to NAS de-/encoding to SCCP callbacks and timers. A ran_infra<br>pointer hence allows complete abstraction of RAN implementations:<br><br>- managing connected RAN peers (BSC, RNC) in ran_peer.c,<br>- classifying and de-/encoding NAS PDUs,<br>- recording connected LACs and cell IDs and sending out Paging requests to<br> matching RAN peers.<br><br>* RAN RESET now also for RANAP<br><br>ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also<br>supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide<br>proper RESET handling, which it so far duly ignores. (TODO)<br><br>* NAS de-/encoding abstraction<br><br>The NAS abstraction mentioned above serves not only to separate RANAP and BSSAP<br>implementations transparently, but also to be able to optionally handle NAS on<br>distinct levels. Before Handover, all NAS is handled by the MSC-A role.<br>However, after an inter-MSC Handover, a standalone MSC-I will need to decode<br>NAS PDUs, at least in order to manage Assignment of RTP streams between BSS/RNC<br>and MNCC call forwarding.<br><br>nas.h provides a common API with abstraction for:<br><br>- receiving NAS events from RAN, i.e. passing NAS up from the BSC/RNC and<br> MS/UE: struct nas_up_msg represents NAS messages decoded from either BSSMAP<br> or RANAP;<br>- sending NAS events: nas_down_msg is the counterpart to compose NAS messages<br> that should be encoded to either BSSMAP or RANAP and passed down to the<br> BSC/RNC and MS/UE.<br><br>The RAN-specific implementations are completely contained by nas_a.c and<br>nas_iu.c.<br><br>In particular, Assignment and Ciphering have so far been distinct code paths<br>for BSSAP and RANAP, with switch(via_ran){...} statements all over the place.<br>Using NAS_UP_* and NAS_DOWN_* abstractions, these are now completely unified.<br><br>Note that SGs does not qualify for NAS abstraction: the SGs interface always<br>remains with the MSC-A role, and SGs messages follow quite distinct semantics<br>from the fairly similar GERAN and UTRAN.<br><br>* MGW and RTP stream management<br><br>So far, managing MGW endpoints via MGCP was tightly glued in-between<br>GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP<br>streams between different RAN peers by moving to object-oriented<br>implementations: implement struct call_leg and struct rtp_stream with distinct<br>FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated<br>from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose.<br>Instead of implementing a sequence of events with code duplication for the RAN<br>and CN sides, the idea is to manage each RTP stream separately by firing and<br>receiving events as soon as codecs and RTP ports are negotiated, and letting<br>the individual FSMs take care of the MGW management "asynchronously". The<br>caller provides event IDs and an FSM instance that should be notified of RTP<br>stream setup progress. Hence it becomes possible to reconnect RTP streams from<br>one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP<br>peers (inter-MSC Handover) without duplicating the MGCP code for each<br>transition.<br><br>The number of FSM implementations used for MGCP handling may seem a bit of an<br>overkill. But in fact, the number of perspectives on RTP forwarding are far<br>from trivial:<br>- an MGW endpoint is an entity with N connections, and MGCP "sessions" for<br> configuring them by talking to the MGW;<br>- an RTP stream is a remote peer connected to one of the endpoint's<br> connections, which is asynchronously notified of codec and RTP port choices;<br>- a call leg is the higher level view on either an MT or MO side of a voice<br> call, a combination of two RTP streams to forward between two remote peers.<br><br> BSC MGW PBX<br> CI CI<br> [MGW-endpoint]<br> [--rtp_stream--] [--rtp_stream--]<br> [----------------call_leg----------------]<br><br>* Use counts<br><br>Introduce using the new osmo_use_count API added to libosmocore for this<br>purpose. Each use token has a distinct name in the logging, which can be a<br>globally constant name or ad-hoc, like the local __func__ string constant. Use<br>in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count<br>API.<br><br>* FSM Timeouts<br><br>Introduce using the new osmo_tdef API, which provides a common VTY<br>implementation for all timer numbers, and FSM state transitions with the<br>correct timeout. Originated in osmo-bsc, recently moved to libosmocore.<br><br>Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)<br> Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore)<br> Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore)<br> Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp)<br> I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw)<br> Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw)<br> I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)<br>Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd<br>---<br>M configure.ac<br>A doc/sequence_charts/Makefile.am<br>A doc/sequence_charts/inter_bsc_ho.msc<br>A doc/sequence_charts/inter_msc_ho.msc<br>M include/osmocom/msc/Makefile.am<br>D include/osmocom/msc/a_iface.h<br>D include/osmocom/msc/a_iface_bssap.h<br>D include/osmocom/msc/a_reset.h<br>A include/osmocom/msc/call_leg.h<br>M include/osmocom/msc/gsm_04_08.h<br>M include/osmocom/msc/gsm_04_11.h<br>M include/osmocom/msc/gsm_04_14.h<br>M include/osmocom/msc/gsm_04_80.h<br>M include/osmocom/msc/gsm_09_11.h<br>M include/osmocom/msc/gsm_data.h<br>M include/osmocom/msc/gsm_data_shared.h<br>M include/osmocom/msc/gsm_subscriber.h<br>D include/osmocom/msc/iu_dummy.h<br>D include/osmocom/msc/iucs.h<br>D include/osmocom/msc/iucs_ranap.h<br>M include/osmocom/msc/mncc.h<br>A include/osmocom/msc/msc_a.h<br>M include/osmocom/msc/msc_common.h<br>A include/osmocom/msc/msc_i.h<br>D include/osmocom/msc/msc_ifaces.h<br>D include/osmocom/msc/msc_mgcp.h<br>A include/osmocom/msc/msc_roles.h<br>A include/osmocom/msc/msc_t.h<br>A include/osmocom/msc/msub.h<br>A include/osmocom/msc/nas.h<br>A include/osmocom/msc/nas_a.h<br>A include/osmocom/msc/nas_iu.h<br>A include/osmocom/msc/paging.h<br>M include/osmocom/msc/ran_conn.h<br>A include/osmocom/msc/ran_infra.h<br>A include/osmocom/msc/ran_peer.h<br>A include/osmocom/msc/rtp_stream.h<br>A include/osmocom/msc/sccp_ran.h<br>M include/osmocom/msc/sgs_iface.h<br>M include/osmocom/msc/signal.h<br>M include/osmocom/msc/transaction.h<br>M include/osmocom/msc/vlr.h<br>M include/osmocom/msc/vlr_sgs.h<br>M src/libmsc/Makefile.am<br>D src/libmsc/a_iface.c<br>D src/libmsc/a_iface_bssap.c<br>D src/libmsc/a_reset.c<br>A src/libmsc/call_leg.c<br>M src/libmsc/gsm_04_08.c<br>M src/libmsc/gsm_04_08_cc.c<br>M src/libmsc/gsm_04_11.c<br>M src/libmsc/gsm_04_11_gsup.c<br>M src/libmsc/gsm_04_14.c<br>M src/libmsc/gsm_04_80.c<br>M src/libmsc/gsm_09_11.c<br>D src/libmsc/gsm_subscriber.c<br>D src/libmsc/iu_dummy.c<br>D src/libmsc/iucs.c<br>D src/libmsc/iucs_ranap.c<br>M src/libmsc/mncc_builtin.c<br>A src/libmsc/msc_a.c<br>A src/libmsc/msc_i.c<br>A src/libmsc/msc_i_remote.c<br>D src/libmsc/msc_ifaces.c<br>D src/libmsc/msc_mgcp.c<br>A src/libmsc/msc_net_init.c<br>A src/libmsc/msc_t.c<br>M src/libmsc/msc_vty.c<br>A src/libmsc/msub.c<br>A src/libmsc/nas.c<br>A src/libmsc/nas_a.c<br>A src/libmsc/nas_iu.c<br>D src/libmsc/osmo_msc.c<br>A src/libmsc/paging.c<br>M src/libmsc/ran_conn.c<br>A src/libmsc/ran_infra.c<br>A src/libmsc/ran_peer.c<br>A src/libmsc/ran_up_l2.c<br>M src/libmsc/rrlp.c<br>A src/libmsc/rtp_stream.c<br>A src/libmsc/sccp_ran.c<br>M src/libmsc/sgs_iface.c<br>M src/libmsc/sgs_server.c<br>M src/libmsc/silent_call.c<br>M src/libmsc/smpp_openbsc.c<br>M src/libmsc/smpp_smsc.h<br>M src/libmsc/sms_queue.c<br>M src/libmsc/transaction.c<br>M src/libvlr/vlr.c<br>M src/libvlr/vlr_access_req_fsm.c<br>M src/libvlr/vlr_lu_fsm.c<br>M src/libvlr/vlr_sgs.c<br>M src/libvlr/vlr_sgs_fsm.c<br>M src/osmo-msc/Makefile.am<br>M src/osmo-msc/msc_main.c<br>M tests/msc_vlr/Makefile.am<br>M tests/msc_vlr/msc_vlr_test_authen_reuse.c<br>M tests/msc_vlr/msc_vlr_test_authen_reuse.err<br>M tests/msc_vlr/msc_vlr_test_call.c<br>M tests/msc_vlr/msc_vlr_test_call.err<br>M tests/msc_vlr/msc_vlr_test_gsm_authen.c<br>M tests/msc_vlr/msc_vlr_test_gsm_authen.err<br>M tests/msc_vlr/msc_vlr_test_gsm_ciph.c<br>M tests/msc_vlr/msc_vlr_test_gsm_ciph.err<br>M tests/msc_vlr/msc_vlr_test_hlr_reject.c<br>M tests/msc_vlr/msc_vlr_test_hlr_reject.err<br>M tests/msc_vlr/msc_vlr_test_hlr_timeout.c<br>M tests/msc_vlr/msc_vlr_test_hlr_timeout.err<br>M tests/msc_vlr/msc_vlr_test_ms_timeout.c<br>M tests/msc_vlr/msc_vlr_test_ms_timeout.err<br>M tests/msc_vlr/msc_vlr_test_no_authen.c<br>M tests/msc_vlr/msc_vlr_test_no_authen.err<br>M tests/msc_vlr/msc_vlr_test_reject_concurrency.c<br>M tests/msc_vlr/msc_vlr_test_reject_concurrency.err<br>M tests/msc_vlr/msc_vlr_test_rest.c<br>M tests/msc_vlr/msc_vlr_test_rest.err<br>M tests/msc_vlr/msc_vlr_test_ss.c<br>M tests/msc_vlr/msc_vlr_test_ss.err<br>M tests/msc_vlr/msc_vlr_test_umts_authen.c<br>M tests/msc_vlr/msc_vlr_test_umts_authen.err<br>M tests/msc_vlr/msc_vlr_tests.c<br>M tests/msc_vlr/msc_vlr_tests.h<br>M tests/sms_queue/Makefile.am<br>M tests/sms_queue/sms_queue_test.c<br>124 files changed, 28,010 insertions(+), 21,718 deletions(-)<br><br></pre><pre style="font-family: monospace,monospace; white-space: pre-wrap;">git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/37/13137/1</pre><pre style="font-family: monospace,monospace; white-space: pre-wrap;"><span></span><br></pre><p>To view, visit <a href="https://gerrit.osmocom.org/13137">change 13137</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/13137"/><meta itemprop="name" content="View Change"/></div></div>
<div style="display:none"> Gerrit-Project: osmo-msc </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-MessageType: newchange </div>
<div style="display:none"> Gerrit-Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd </div>
<div style="display:none"> Gerrit-Change-Number: 13137 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: Neels Hofmeyr <nhofmeyr@sysmocom.de> </div>