Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-08-07T09:14:59ZOpen Source Mobile Communications
Redmine OsmoHLR - Feature #6135 (Stalled): Implement routing of SMS-over-GSUP messages between connected ...https://osmocom.org/issues/61352023-08-07T09:14:59Zfalconia
<p>As of <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Possibility to route SMS messages over GSUP (Resolved)" href="https://osmocom.org/issues/3587">#3587</a>, 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.</p>
<p>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.</p>
<p>I propose the following design:</p>
<ul>
<li>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.</li>
</ul>
<ul>
<li>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.</li>
</ul>
<ul>
<li>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().</li>
</ul>
<ul>
<li>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.</li>
</ul>
<ul>
<li>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.</li>
</ul>
<p>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.</p>
<p>Any better ideas?</p>