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.de> What if inter-MSC handover happens during an active USSD session
> before the HLR (or any other 'dst_entity') responds to USSD?
That's no problem. The MSC-A never changes and always remains in charge, the
only difference is that before the DTAP messaging reaches the BSC and MS, it
first gets "tunneled" via GSUP and the remote MSC, which merely acts as a proxy
for the remote BSC. So it is identical to an intra- or an inter-BSC handover
happening in the middle of a USSD session: the DTAP remains transparent between
the unchanged MSC-A and the MS, the MS has merely hopped onto a different route
for DTAP.
> 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.
Interesting to note / thanks for pointing out that a USSD request should still
be directed at the vlr first. This complicates my idea of "Entity" a bit.
To cut a long story short, I wrote a bunch of responses while completely
re-thinking my idea while I wrote. The result of this is a long mail and this
conclusion:
I will add only a GSUP message kind IEI, which indicates the GSUP subsystem and
allows demuxing GSUP messages without switch(msg_type)ing, and I will *not*
name the source/destination entity at all.
enum osmo_gsup_kind {
OSMO_GSUP_KIND_SUBSCRIBER_MANAGEMENT, /* VLR <-> HLR, D-interface for accessing HLR/HSS data */
OSMO_GSUP_KIND_SMS, /* MSC <-> SMSC */
OSMO_GSUP_KIND_USSD, /* MSC <-> { VLR <-> HLR } <-> EUSE */
OSMO_GSUP_KIND_INTER_MSC /* MSC-A <--> MSC-{T,I}, E-interface for inter-MSC Handover */
};
With this, I can still figure out whether responses like a GSUP routing error
are related to inter-MSC or not, while GSUP->MAP->GSUP conversion remains
"trivial", and USSD routing remains implicit without naming each hop.
That is the conclusion I reach below, and you don't really need to read the
rest of this mail, unless anyone wants to follow my reasoning of how I ended up
at that conclusion...
Thanks for your valuable input, Vadim!
~N
~ + ~ + ~
(long reasoning for above choice follows...)
On Sat, Mar 30, 2019 at 08:20:49PM +0700, Vadim Yanitskiy wrote:
> b) a bit more elegant: use entity type of the next
> component until the USSD request is terminated;
[..]
> I prefer this approach. What do you think?
I agree.
> 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,
Only, this would not end up being an OSMO_GSUP_ENTITY_VLR, because we're not
sending a GSUP message to the VLR. Once it goes out past the VLR we get:
> OSMO_GSUP_ENTITY_MSC_USSD -> OSMO_GSUP_ENTITY_HLR
I would then actually also introduce OSMO_GSUP_ENTITY_HLR_USSD.
My idea there still is to separate the kinds of message to avoid demuxing by
message type. But .. see below
> 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.
>
> OSMO_GSUP_ENTITY_MSC_USSD <- OSMO_GSUP_ENTITY_HLR
Ok, so, on the return path, we don't do all the hops MSC_USSD<-VLR<-HLR<-EUSE
anymore, but the response in all cases goes directly to MSC_USSD, right? Makes
sense.
But.
Maybe my idea of combining the message kind and the source/target entity is a
bit clumsy. Now I am thinking it would make more sense to indicate the
subsystem separately from the source and target entities:
enum osmo_gsup_kind {
OSMO_GSUP_KIND_SUBSCRIBER_MANAGEMENT, /* VLR <-> HLR, D-interface for accessing HLR/HSS data */
OSMO_GSUP_KIND_SMS, /* MSC <-> SMSC */
OSMO_GSUP_KIND_USSD, /* MSC <-> { VLR <-> HLR } <-> EUSE */
OSMO_GSUP_KIND_INTER_MSC /* MSC-A <--> MSC-{T,I}, E-interface for inter-MSC Handover */
};
enum osmo_gsup_entity {
OSMO_GSUP_ENTITY_HLR,
OSMO_GSUP_ENTITY_VLR,
OSMO_GSUP_ENTITY_MSC_A,
OSMO_GSUP_ENTITY_MSC_I,
OSMO_GSUP_ENTITY_MSC_T,
OSMO_GSUP_ENTITY_SMSC,
OSMO_GSUP_ENTITY_EUSE,
};
Next, I am reconsidering whether we really need the source and destination
entity for any messages other than the E-interface at all. On the E-interface
I want to explicitly distinguish between MSC-I and MSC-T. However, it is also
a bit questionable how a MAP-to-GSUP converter would figure that out. Has
to switch(message_type)... so maybe it's a bad idea to force this decision into
a compatibility conversion.
For all kinds other than E-interface it would be implicitly clear what the
source/target entities are. The benefit of simpler demuxing into VLR/SMS/USSD
code paths comes from the message kind, the entity kind adds no value.
So I am considering three proposals:
a) add an OSMO_GSUP_KIND_IEI with only the message kind (subscriber-management,
SMS, USSD, E). Include the _KIND_IEI in all messages.
b) Add a), and also add a separate OSMO_GSUP_ENTITY_IEI for source and dest
entity (MSC-A, VLR, HLR, ...). Include the _KIND_IEI in all messages, but
include the _ENTITY_IEI only for E-interface messages.
c) add one OSMO_GSUP_ROUTING_IEI with all of kind, source and destination
entity in a single information element.
My first intuition was to go with c), but we would probably ignore the entity
information for all but the inter-MSC messages.
The second intuition is b), but when I consider that the entity info would be
lost in a GSUP -> MAP -> GSUP conversion, I end up realizing that I should
rather figure out MSC-T or MSC-I from the inter-MSC message kind and MSC state.
So now I end up at a) -- only add a GSUP message kind IEI, which indicates the
GSUP subsystem and allows demuxing GSUP messages without switch(msg_type)ing.
Then we also don't need to figure out the next hop as in HLR or EUSE.
-------------- 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/20190401/80c6fd42/attachment.bin>