GSUP routing for different kinds of entities

[Vadim Yanitskiy]

Hi Neels,

>> AFAIR, ESME is something specific to SMPP only.
>
> Ok, seems I got this wrong then.
> ENTITY_MSC_SMS <---[osmo-hlr]---> ENTITY_SMSC

Yes, correct. Let's drop ESME.

> ENTITY_HLR should only ever appear if we actually interact with the HLR
> database. When osmo-hlr merely does the GSUP routing, no ENTITY_HLR appears in
> the messages. Only ultimate source and destination entities are named.

USSD is not that simple in terms of routing. According to GSM 03.90,
a MO USSD request goes through the following chain:

  MS / UE -> RAN -> MSC -> VLR -> HLR -> EUSE

and either of MSC, VLR, HLR, or EUSE can terminate this request.
In other words, both MSC and VLR can also handle (and initiate)
some USSD requests, and the routing configuration is up to the
service provider. This is how it works in commercial networks.

In our case, we still route a USSD request from MS / UE through
the VLR towards OsmoHLR, which can:

  - either handle it internally (e.g. *#100#, *#101#),
    we call this IUSE - Internal USSD Entity;
  - or route it further to some EUSE (external one).

Therefore, when a USSD request is received at OsmoMSC, we don't
yet know what would be the destination entity: HLR or some EUSE.
As soon as that USSD request is handled somewhere, the handling
entity would indicate itself in the response using 'src_entity'
IE. The question is which 'dst_entity' IE value should we use
at the beginning? ;)

I see two potential approaches here:

  a) the simplest one: just use OSMO_GSUP_ENTITY_EUSE,
     the "farthest" entity in the whole chain;
  b) a bit more elegant: use entity type of the next
     component until the USSD request is terminated;

To clarify b), here is an example of 'dst_entity' permutations:

  1. Some MS / UE initiates USSD request *#100#, and we receive
     it at MSC. Since our OsmoMSC doesn't handle USSD requests
     itself (commercial ones do), it forwards to the VLR:

       OSMO_GSUP_ENTITY_MSC_USSD -> OSMO_GSUP_ENTITY_VLR,

  2. Since our VLR doesn't handle USSD requests itself (commercial
     ones do), it forwards received GSUP message to the HLR:

       OSMO_GSUP_ENTITY_MSC_USSD -> OSMO_GSUP_ENTITY_HLR

  3. OsmoHLR receives that USSD request, and checks the routing
     configuration. By default, *#100# is handled by IUSE called
     'own_msisdn', so the HLR terminates request and responds
     back to OsmoMSC. In TCAP/MAP, the response would go
     directly to OsmoMSC via a new connection. In our case,
     we just (re)use the existing TCP/GSUP connection:

       OSMO_GSUP_ENTITY_MSC_USSD <- OSMO_GSUP_ENTITY_HLR

I prefer this approach. What do you think?
What if inter-MSC handover happens during an active USSD session
before the HLR (or any other 'dst_entity') responds to USSD?

With best regards,
Vadim Yanitskiy.