Project

General

Profile

Actions

Feature #6135

open

Implement routing of SMS-over-GSUP messages between connected MSC/VLRs and SMSCs

Added by falconia 4 months ago. Updated 3 months ago.

Status:
Stalled
Priority:
Normal
Assignee:
Target version:
-
Start date:
08/07/2023
Due date:
% Done:

90%

Spec Reference:

Description

As of #3587, OsmoMSC can suppress its built-in SMSC and instead pass SMS-PP to and from external SMSCs via MAP-mimicking GSUP, following classic GSM architecture. However, current OsmoHLR is unable to route these SMS-over-GSUP messages: if I implement my own GSUP-speaking SMSC and connect it to OsmoHLR, the latter won't know how to forward MO-forwardSM.req from OsmoMSC to the SMSC based on the SC-address in SM-RP-DA, or how to forward MT-forwardSM.req in the opposite direction based on the IMSI.

Themyscira Wireless is currently in need of a custom SMSC, I am starting to implement one, and I am looking to do it in the most GSM-architecture-classic manner. The mechanism of SMS-over-GSUP looks like the right way to do what I seek, or at least from OsmoMSC side the protocol does exactly what it should, pass SM-RP to an external SMSC with minimal transformation. My SMSC would connect to OsmoHLR via GSUP much like EUSEs do for USSD - copy the same model, so far so good. But the routing piece in OsmoHLR is missing.

I propose the following design:

  • Similarly to how EUSEs connect with IPA names of the form EUSE-foobar, require SMSCs to connect with IPA names of the form SMSC-12345, where 12345 is the SC-address of this SMSC, i.e., the number to be programmed as the Service-Centre-Address in the EF_SMSP record on SIM cards.
  • When MO-forwardSM.req comes from MSC/VLR, route it based on SM-RP-DA: require the address type to be SMSC, and look for a connected GSUP peer with name SMSC-12345 or whatever digit string is in the SC address field coming from the MS.
  • To route MO-forwardSM.{resp,err} correctly, the SMSC will be responsible for setting destination_name in the response to a copy of source_name from the request, ideally using osmo_gsup_req_respond().
  • When MT-forwardSM.req comes from an SMSC, route it to the serving VLR based on the IMSI just like MT USSD coming from an EUSE.
  • For MT-forwardSM.{resp,err} routing, OsmoMSC will need to be patched to fill response destination_name with a copy of request source_name, which it currently fails to do.

The only part for which I don't have any solution currently is READY-FOR-SM.req: it's a request coming from MSC/VLR, but there is no SMSC address to route to. In the official architecture the HLR is expected to keep a list of SMSC that attempted and failed MT SMS delivery, and notify all of them upon a single "ready" notification from MSC/VLR - but implementing all that complexity would be a bit too much for me at the present moment. I am thinking of having OsmoHLR simply reply with "success" to READY-FOR-SM.req as a FIXME placeholder in the initial implementation, just so that the MS gets an RP-ACK rather than RP-ERROR (the MS did nothing wrong!), and leave it as a problem to be solved later.

Any better ideas?

Actions #1

Updated by falconia 4 months ago

  • Status changed from New to In Progress
  • Assignee set to falconia
  • % Done changed from 0 to 20

The initial implementation is here:

https://cgit.osmocom.org/osmo-hlr/?h=falconia/os6135
https://cgit.osmocom.org/osmo-msc/?h=falconia/os6135

More work needs to be done, particularly in testing - so far only the MO path has been tested and proven working. Further updates will follow.

Actions #2

Updated by falconia 3 months ago

  • % Done changed from 20 to 40

Both MO and MT SMS paths have now been proven working. See the links above for the branch in osmo-hlr and osmo-msc (patches unchanged), plus these test fixture components:

https://www.freecalypso.org/hg/osmo-playpen/
https://www.freecalypso.org/hg/sms-coding-utils/

The only part which remains to be implemented is routing of READY-FOR-SM messages, which is a non-immediately-obvious problem because neither OsmoMSC nor OsmoHLR remembers which SMSC have tried and failed to deliver SMS to a given IMSI. When fixeria and I discussed this issue, we both concluded that the simplest solution is to replicate READY-FOR-SM.req from an MSC to all connected SMSCs - obviously not particularly efficient, but realistically speaking, how many different SMSCs will be connected to OsmoHLR in a typical Osmocom network...

Actions #3

Updated by falconia 3 months ago

  • % Done changed from 40 to 50

READY-FOR-SM handling is now implemented, same falconia/os6135 branch in osmo-hlr as before. The work that is currently implemented on the branch is expected to be good for production use at Themyscira Wireless; the next step is to rebase the patches to current master and submit to Gerrit for review.

Actions #5

Updated by falconia 3 months ago

  • % Done changed from 60 to 70

OsmoHLR patches have been merged to master. Coming up next: I need to rebase OsmoMSC patches to current master, submit them to Gerrit and get them through review too.

Actions #6

Updated by falconia 3 months ago

  • % Done changed from 70 to 80
Actions #7

Updated by falconia 3 months ago

  • Status changed from In Progress to Stalled
  • % Done changed from 80 to 90

Code implementation is complete: all necessary patches to both OsmoHLR and OsmoMSC have been merged. However, documentation remains to be written: an entirely new facility has just been implemented (ability to connect external SMSC implementations to an otherwise standard and self-contained Osmocom CNI setup), hence it needs to be documented. I reason that OsmoHLR manual would probably be the proper place for the new chapter, as the required SMSC routing configuration needs to be done in OsmoHLR vty.

Documentation is a type of work I tend to be good at, at least in my own projects under FreeCalypso umbrella, but I don't know what kind of difficulties I may run into with editing Osmocom manuals. Common sense tells me that prior to submitting any OsmoHLR manual patches to Gerrit, I will need to make sure that my changes to adoc source compile into PDF locally, and that the result looks as desired - but I have yet to try building any Osmocom component with --enable-manuals, and I have a reasonable fear of running into dependency hell once again.

Because of these considerations, I am marking this feature ticket as Stalled for now.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)