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/.
Neels Hofmeyr nhofmeyr at sysmocom.deThanks for your input!
Currently, my patch looks like this:
enum osmo_gsup_entity {
OSMO_GSUP_ENTITY_NONE = 0,
OSMO_GSUP_ENTITY_HLR = 1,
OSMO_GSUP_ENTITY_VLR = 2,
OSMO_GSUP_ENTITY_ESME = 3, (see below)
OSMO_GSUP_ENTITY_SMSC = 4,
OSMO_GSUP_ENTITY_MSC_SMS = 5,
OSMO_GSUP_ENTITY_EUSE = 6,
OSMO_GSUP_ENTITY_MSC_USSD = 7,
OSMO_GSUP_ENTITY_MSC_A = 8,
OSMO_GSUP_ENTITY_MSC_I = 9,
OSMO_GSUP_ENTITY_MSC_T = 10,
OSMO_GSUP_ENTITY_MAXVAL = OSMO_GSUP_ENTITY_MSC_T
};
> I don't think we need to overload the entity types with service types
I think we do.
We have various message types that are distinct to individual handlers -- SMS
go to gsm_04_11_gsup.c, USSD to gsm_09_11.c. This is not osmo-msc specific, if
any other MSC would implement these GSUP messages, the individual SMS, USSD,
... parts would always be handled in distinct code paths. So, we need to
demux when receiving GSUP from the HLR.
So far we demux by message type alone. But that means we *must* have distinct
message types for each subsystem. Even for identical semantics (like routing
error responses) we would need distinct msg_type, or other heuristics.
When I am adding this "entity" IE, I want to rather go all the way and make
demuxing in osmo-msc trivial:
static enum osmo_gsup_entity gsup_client_mux_classify(struct gsup_client_mux *gcm,
const struct osmo_gsup_message *gsup_msg)
{
if (gsup_msg->destination_entity)
return gsup_msg->destination_entity; /* <-- this is the "trivial" bit */
LOGP(DLGSUP, LOGL_ERROR, "No destination entity, trying to guess from message type %s\n",
osmo_gsup_message_type_name(gsup_msg->message_type));
switch (gsup_msg->message_type) {
case OSMO_GSUP_MSGT_PROC_SS_REQUEST:
case OSMO_GSUP_MSGT_PROC_SS_RESULT:
case OSMO_GSUP_MSGT_PROC_SS_ERROR:
return OSMO_GSUP_ENTITY_MSC_USSD;
/* GSM 04.11 code implementing MO SMS */
case OSMO_GSUP_MSGT_MO_FORWARD_SM_ERROR:
case OSMO_GSUP_MSGT_MO_FORWARD_SM_RESULT:
case OSMO_GSUP_MSGT_READY_FOR_SM_ERROR:
case OSMO_GSUP_MSGT_READY_FOR_SM_RESULT:
case OSMO_GSUP_MSGT_MT_FORWARD_SM_REQUEST:
return OSMO_GSUP_ENTITY_SMSC;
default:
return OSMO_GSUP_ENTITY_VLR;
}
}
int gsup_client_mux_rx(struct osmo_gsup_client *gsup_client, struct msgb *msg)
{
[...]
entity = gsup_client_mux_classify(gcm, &gsup);
[...]
rc = gcm->rx_cb[entity].func(gcm, gcm->rx_cb[entity].data, &gsup);
which feeds directly into gsm411_gsup_rx(), gsm0911_gsup_rx(), ...
no further interpretation needed
}
If you instead keep the USSD and SMS subsystems in the same "entity", then we
still need to demux between those based on message type.
> AFAIR, ESME is something specific to SMPP only.
Ok, seems I got this wrong then.
ENTITY_MSC_SMS <---[osmo-hlr]---> ENTITY_SMSC
yes?
>
> > 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,
MSC_B didn't make it. Instead I require more distinct MSC-A, MSC-I and MSC-T.
But these will only be used for actual inter-MSC messages. i.e., a USSD
response doesn't go to the MSC-A entity, since that would be the inter-MSC
forwarding subsystem. Rather, it would go to MSC_USSD. That again would figure
out which subscriber is involved and then possibly forward to a remote
ENTITY_MSC_I.
> - OSMO_GSUP_ENTITY_HLR,
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.
This also means we could at some point trivially separate GSUP routing from
the osmo-hlr process if we wanted.
> - OSMO_GSUP_ENTITY_EUSE.
ack.
so:
ENTITY_MSC_USSD <---[osmo-hlr]---> 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
ENTITY_MSC_SMS <---[osmo-hlr]---> ENTITY_SMSC
I will adjust to drop ESME and fix the ENTITY_SMSC being on the wrong side.
Otherwise IMHO it should stay as I have it. Would you agree, or am I still
getting something wrong?
~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190328/7a3e0bf8/attachment.bin>