5 Aug
2019
5 Aug
'19
9:05 p.m.
Hi Vadim,
On Tue, Aug 06, 2019 at 12:38:09AM +0700, Vadim Yanitskiy wrote:
This is an interesting idea, though one would have to think
more about what kind of implications this has in terms of staying
as compatible as possible with what happens in MAP based traditional
networks. In the end, whatever we do should be "easily translateable"
to the MAP+ISUP domain, if ever needed.
There are many possible configurations, such as:
1) Full Osmocom CNI networks wanting to interact with external
entities / the SIP world
2) OsmoMSC with a GSUP-DIAMETER or GSUP-MAP converter attached
to a real HLR/HSS.
I don't think we have to consider non-Osmocom MSC with OsmoHLR, as that
doesn't make sense (we don't speak MAP and don't do most of what people
would exect from a real HLR
Lucikily, the RAN doesn't impact any of this, so it doesn't matter
whwether the BSC/RNC/HNBGW attached to the MSC is Osmocom or
non-Osmocom.
Well, only for MT calls arriving either via ISUP or SIP[-I], not
really for anything else. Not for SMS, not for MAP signaling.
* The
osmo-sip-connector should ask the HLR if the number
exists before forwarding the call to MNCC.
I don't think it's a good idea to mix call related stuff
with subscriber management in... MNCC <-> SIP converter.
The same can be done by OsmoMSC on receipt of MNCC_SETUP_REQ,
so if a subscriber is not in the VLR's cache, it would send
OSMO_GSUP_MSGT_SEND_SUBSCR_INFO_REQ (not implemented) to the
OsmoHLR, and respond to OsmoSIPCon depending on the result. * There may be
more than one MSC, in which case the HLR
would inform osmo-sip-connector about which MSC to use.
In commercial networks this problem is solved by the gateway
MSC, which is a kind of entry point for all mobile-terminated
connections. In Osmocom CNI we decided to turn the HLR into a
kind of gateway for USSD and SMS, so it's responsible for the
further routing to the target MSC.
This is natural as both USSD and SMS are transported over GSM signaling
plane and hence MAP in traditional networks.
It doesn't mean that this has to be the same for call control.
We may probably want to encapsulate MNCC protocol into
GSUP,
like we do for SS/USSD (MAP payload) and SMS (SM TPDU), so
OsmoHLR would take care about routing between the MSCs. This
would require adding one more message type, similar to
SS/USSD - OSMO_GSUP_MSGT_PROC_MNCC_{REQ,RES,ERR}.
I really don't like that idea, sorry. Way too far from how 3GPP
networks work.
But then, again, we would have to overload the HLR
with call
related stuff, what is probably even worse than overloading
OsmoSIPCon with subscriber management...
What about a dedicated G-MSC process as I suggested in my other mail?
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)