GSUP routing for different kinds of entities

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Vadim Yanitskiy axilirator at gmail.com
Thu Mar 28 12:02:40 UTC 2019


Ni Neels,

Sorry for late reply, I am experiencing a big lack of free time :/

> I would much rather have an explicit destination entity advertised in the GSUP
> messages, and an explicit common GSUP MUX stage. In other words, the VLR of
> osmo-msc shouldn't act as a GSUP forwarder, it should merely be one of the GSUP
> consumers, and shouldn't even be involved when the messages are intended for
> inter-MSC, for USSD or for SMS use.

ACK. I like the idea of having source / destination IEs for routing
purposes. I was also thinking about having separate GSUP-connections
for both MSC and VLR, but since VLR is a part of MSC, I don't see
any benefits from this approach.

> Still would like to get input on naming:
> For SMS, we have the SMSC and ESME entities.

Correct, but AFAIR, ESME is something specific to SMPP only.
In case of GSUP (and MAP) we always deal with SMSC. Therefore,
I think we don't need OSMO_GSUP_ENTITY_ESME entity at all.

> Are there similar terms for USSD?  Which is the entity managing
> USSD dialogs? which is the entity sending the USSD messages?

Here we have the following picture:

                                    |- <-GSUP-> EUSE (foo)
  MS / UE <-> RAN <-> MSC <-GSUP-> HLR <-GSUP-> EUSE (bar)
                                    |- <-GSUP-> EUSE (zoo)

EUSE stands for External Unstructured supplementary Services Entity.
One can configure prefix-based routing in OsmoHLR, so USSD requests
coming from MS / UE can be routed to one of the connected EUSEs.

The following entity types from proposed enum are involved here:

  - OSMO_GSUP_ENTITY_MSC_B,
  - OSMO_GSUP_ENTITY_HLR,
  - OSMO_GSUP_ENTITY_EUSE.

> Thinking, in fact if our osmo-msc wasn't siamese twins with
> the SMSC we would have ESME <-> SMSC <-> MSC.

As Harald noted, at some point we would need to rip out the
internal SMSC functionality from OsmoMSC. At the moment, it
can be disabled from the VTY using 'sms-over-gsup' parameter.

>From what I remember, a simplified SMS delivery in our MAP-less
stack (since we use GSUP and HLR as the router) should look
this way:

  MS / UE (Alice) -> RAN -> MSC |-GSUP-> HLR |-GSUP-> OsmoSMSC
                                                         |
  MS / UE (Sarah) <- RAN <- MSC <-GSUP-| HLR <-GSUP-| OsmoSMSC

So we have the following entity types involved here:

  - OSMO_GSUP_ENTITY_MSC_B,
  - OSMO_GSUP_ENTITY_HLR,
  - OSMO_GSUP_ENTITY_SMSC.

For more details, please see:

https://git.osmocom.org/osmo-gsm-manuals/tree/common/chapters/gsup_mo_sms.msc
https://git.osmocom.org/osmo-gsm-manuals/tree/common/chapters/gsup_mt_sms.msc

> MSC-SMS / MSC-USSD

I don't think we need to overload the entity types with service types
they provide. In other words, instead of MSC-SMS / MSC-USSD we can
use single OSMO_GSUP_ENTITY_MSC_B.

With best regards,
Vadim Yanitskiy.



More information about the OpenBSC mailing list