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.