2018-12-05 01:24:30 +00:00
OsmoMSC> enable
OsmoMSC# configure terminal
OsmoMSC(config)# list
...
network
msc
2018-12-03 10:00:04 +00:00
sgs
2018-12-05 01:24:30 +00:00
mncc-int
hlr
...
OsmoMSC(config)# network
OsmoMSC(config-net)# list
...
network country code <1-999>
mobile network code <0-999>
short name NAME
long name NAME
encryption a5 <0-3> [<0-3>] [<0-3>] [<0-3>]
2019-08-13 14:00:37 +00:00
encryption uea <0-2> [<0-2>] [<0-2>]
2018-12-05 01:24:30 +00:00
authentication (optional|required)
rrlp mode (none|ms-based|ms-preferred|ass-preferred)
mm info (0|1)
timezone <-19-19> (0|15|30|45)
timezone <-19-19> (0|15|30|45) <0-2>
no timezone
2019-08-08 13:43:40 +00:00
call-waiting
no call-waiting
2018-12-05 01:24:30 +00:00
2019-08-13 14:00:37 +00:00
OsmoMSC(config-net)# encryption?
encryption Encryption options
OsmoMSC(config-net)# encryption ?
a5 GSM A5 Air Interface Encryption.
uea UTRAN (3G) encryption algorithms to allow: 0 = UEA0 (no encryption), 1 = UEA1, 2 = UEA2. NOTE: the current implementation does not allow free choice of combining encryption algorithms yet. The only valid settings are either 'encryption uea 0' or 'encryption uea 1 2'.
OsmoMSC(config-net)# encryption uea ?
<0-2> UEAn Algorithm Number
OsmoMSC(config-net)# encryption uea 0 ?
[<0-2>] UEAn Algorithm Number
OsmoMSC(config-net)# encryption uea 0 1 ?
[<0-2>] UEAn Algorithm Number
OsmoMSC(config-net)# encryption uea 0 1 2 ?
<cr>
2018-12-05 01:24:30 +00:00
OsmoMSC(config-net)# exit
OsmoMSC(config)# msc
OsmoMSC(config-msc)# list
...
assign-tmsi
2018-12-05 00:11:28 +00:00
mncc internal
mncc external MNCC_SOCKET_PATH
2018-12-05 00:07:03 +00:00
mncc guard-timeout <0-255>
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
2018-11-28 16:05:51 +00:00
ncss guard-timeout <0-255>
2018-12-05 01:24:30 +00:00
no assign-tmsi
auth-tuple-max-reuse-count <-1-2147483647>
auth-tuple-reuse-on-error (0|1)
2019-05-02 08:40:50 +00:00
check-imei-rqd (0|1|early)
2018-12-05 01:24:30 +00:00
cs7-instance-a <0-15>
cs7-instance-iu <0-15>
paging response-timer (default|<1-65535>)
emergency-call route-to-msisdn MSISDN
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-11-19 23:20:53 +00:00
sms-over-gsup
no sms-over-gsup
2019-05-06 17:29:11 +00:00
osmux (on|off|only)
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
2018-12-07 13:47:34 +00:00
handover-number range MSISDN_FIRST MSISDN_LAST
neighbor (a|iu) lac <0-65535> (ran-pc|msc-ipa-name) RAN_PC_OR_MSC_IPA_NAME
neighbor (a|iu) lac-ci <0-65535> <0-65535> (ran-pc|msc-ipa-name) RAN_PC_OR_MSC_IPA_NAME
neighbor (a|iu) cgi <0-999> <0-999> <0-65535> <0-65535> (ran-pc|msc-ipa-name) RAN_PC_OR_MSC_IPA_NAME
no neighbor (a|iu) (ran-pc|msc-ipa-name) RAN_PC_OR_MSC_IPA_NAME
2020-01-25 03:49:14 +00:00
timer [(vlr|mgw|mncc|sccp|geran|utran|sgs)] [TNNNN] [(<0-2147483647>|default)]
2018-12-05 01:24:30 +00:00
mgw local-ip A.B.C.D
mgw local-port <0-65535>
mgw remote-ip A.B.C.D
mgw remote-port <0-65535>
...
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
2018-11-28 16:05:51 +00:00
OsmoMSC(config-msc)# ncss?
ncss Configure call independent Supplementary Services
OsmoMSC(config-msc)# ncss ?
guard-timeout Set guard timer for session activity
2018-12-05 00:11:28 +00:00
OsmoMSC(config-msc)# mncc?
mncc Configure Mobile Network Call Control
OsmoMSC(config-msc)# mncc ?
internal Use internal MNCC handler (default; changes need a program restart)
external Use external MNCC handler (changes need a program restart)
guard-timeout Set global guard timer for mncc interface activity
OsmoMSC(config-msc)# mncc external ?
MNCC_SOCKET_PATH File system path to create the MNCC unix domain socket at
OsmoMSC(config-msc)# mncc external /path/not/used
OsmoMSC(config-msc)# show running-config
...
msc
...
mncc external /path/not/used
...
OsmoMSC(config-msc)# mncc internal
OsmoMSC(config-msc)# show running-config
... ! mncc external
2018-12-05 01:24:30 +00:00
OsmoMSC(config-msc)# exit
OsmoMSC(config)# mncc-int
OsmoMSC(config-mncc-int)# list
...
default-codec tch-f (fr|efr|amr)
default-codec tch-h (hr|amr)
OsmoMSC(config-mncc-int)# exit
OsmoMSC(config)# hlr
OsmoMSC(config-hlr)# list
...
remote-ip A.B.C.D
remote-port <1-65535>
2018-12-19 23:46:40 +00:00
ipa-name NAME
2018-12-05 01:24:30 +00:00
OsmoMSC(config-hlr)# exit
OsmoMSC(config)# exit
OsmoMSC# configure terminal
OsmoMSC(config)# network
OsmoMSC(config-net)# end
2018-12-03 10:00:04 +00:00
OsmoMSC# configure terminal
OsmoMSC(config)# sgs
OsmoMSC(config-sgs)# list
...
local-ip A.B.C.D
local-port <0-65535>
timer (ts5|ts6-2|ts7|ts11|ts14|ts15) <1-120>
counter (ns7|ns11) <0-255>
vlr-name FQDN
OsmoMSC(config-sgs)# end
2018-12-05 01:24:30 +00:00
OsmoMSC# disable
OsmoMSC> enable
OsmoMSC# ! Punching some '...' holes because of optional SMPP, Iu
OsmoMSC# show running-config
...
network
network country code 001
mobile network code 01
short name OsmoMSC
long name OsmoMSC
encryption a5 0
2019-08-13 14:00:37 +00:00
encryption uea 1 2
2018-12-05 01:24:30 +00:00
authentication optional
rrlp mode none
mm info 1
msc
2018-12-05 00:07:03 +00:00
mncc guard-timeout 180
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
2018-11-28 16:05:51 +00:00
ncss guard-timeout 30
2018-12-05 01:24:30 +00:00
assign-tmsi
cs7-instance-a 0
...
auth-tuple-max-reuse-count 3
auth-tuple-reuse-on-error 1
mgw local-port 2728
2020-03-24 19:30:21 +00:00
mgw remote-ip 127.0.0.1
2018-12-05 01:24:30 +00:00
mgw remote-port 2427
mncc-int
default-codec tch-f fr
default-codec tch-h hr
...
hlr
remote-ip 127.0.0.1
remote-port 4222
2018-12-03 10:00:04 +00:00
sgs
2019-02-23 09:16:44 +00:00
local-port 29118
2018-12-03 10:00:04 +00:00
local-ip 0.0.0.0
vlr-name vlr.example.net
2018-12-05 01:24:30 +00:00
end
2019-08-13 14:00:37 +00:00
OsmoMSC# configure terminal
OsmoMSC(config)# network
OsmoMSC(config-net)# encryption uea 0
OsmoMSC(config-net)# show running-config
...
encryption uea 0
...
OsmoMSC(config-net)# encryption uea 1
% Error: the current implementation does not allow free choice of combining
% encryption algorithms yet. The only valid settings are either
% encryption uea 0
% or
% encryption uea 1 2
OsmoMSC(config-net)# show running-config
...
encryption uea 0
...
OsmoMSC(config-net)# encryption uea 2
% Error: the current implementation does not allow free choice of combining
...
OsmoMSC(config-net)# show running-config
...
encryption uea 0
...
OsmoMSC(config-net)# encryption uea 0 1
% Error: the current implementation does not allow free choice of combining
...
OsmoMSC(config-net)# show running-config
...
encryption uea 0
...
OsmoMSC(config-net)# encryption uea 0 2
% Error: the current implementation does not allow free choice of combining
...
OsmoMSC(config-net)# show running-config
...
encryption uea 0
...
OsmoMSC(config-net)# encryption uea 1 2
OsmoMSC(config-net)# show running-config
...
encryption uea 1 2
...