Cellular Network Infrastructure » Core Network (CN) » OsmoHLR

Thanks to recently implemented features #3587 and #6135, we now have a way to connect an external SMSC to an OsmoMSC+OsmoHLR core network. However, there is one remaining difficulty: when that external SMSC needs to deliver MT SMS to a subscriber, the mechanism of SMS-over-GSUP requires that the target MS be identified by IMSI, while the SMSC will typically only have MSISDN for the recipient. Elaborating a little:

• IMSI is a strictly required IE in every GSUP message, and the design of GSUP thoroughly assumes that every entity that initiates a GSUP exchange (beginning with a request message) knows the IMSI it wishes to operate on.

• Because of the previous point, I don't see an obvious way to add an exchange of "I only know MSISDN, please tell me the corresponding IMSI" to GSUP. What would the requestor put into the mandatory IMSI field of the request message? A dummy? Would the response then replace that dummy with the real IMSI and thus no longer match? Various common GSUP code paths will likely break then - hence this type of query just doesn't seem to fit into GSUP architecture.

• The basic paradigmatic principle that MT-SMS recipients are identified by IMSI rather than MSISDN at the low-level MT delivery protocol level seems correct: one can think of special cases of network-originated SMS (e.g., SIM OTA programming) in which a recipient may not have an MSISDN at all, but does have an IMSI and is thus attached to GERAN or UTRAN. Hence it seems logically correct to me to have MSISDN-to-IMSI resolution as a separate step just prior to actual MT SMS delivery attempt.

One currently workable approach is to have the external SMSC connect to OsmoHLR not only via GSUP, but also connect to OsmoHLR ctrl interface, issue ctrl GET queries for subscriber.by-msisdn-XXXX.info and fish the IMSI out of the verbose multiline ASCII-formatted response. My current plan is to implement this cumbersome and inefficient MSISDN-to-IMSI resolution mechanism in ThemWi-SMSC (my current real-life-need use case for an external SMSC connecting to Osmocom CN), but it would certainly be nice to have a better way. I also reason that a more efficient and more logically sensible way of doing this mapping resolution will be needed before the approach of a separate SMSC (split from OsmoMSC) can become Osmocom mainstream.

One easy-to-implement relief measure would be to add a subscriber.by-*.imsi ctrl variable (like subscriber.by-*.msisdn, but read-only). The benefits will be shorter TCP-carried messages on the ctrl connection for MSISDN-to-IMSI queries, and simpler parsing code in the SMSC - no need to fish the IMSI out of lots of other irrelevant info. But the whole idea of using this ctrl interface for a key internal function still feels philosophically wrong. Any better ideas?