--- a/doc/Arch-design	Sat Dec 23 04:09:20 2023 +0000
+++ b/doc/Arch-design	Sat Dec 23 08:07:33 2023 +0000
@@ -826,7 +826,34 @@
 
 4. Interface to local Osmocom GSM network
 
-GSUP and separate MSISDN-to-IMSI lookup, to be described.
+There will be two long-lived daemon processes in ThemWi-SMSC dedicated to
+interfacing with the local Osmocom GSM network:
+
+* themwi-smsc-gsmif will be the main SMSC-to-GSM interface.  It will connect to
+  OsmoHLR via GSUP, and it will appear to the Osmocom network as the SMSC,
+  hiding the other components of ThemWi-SMSC from Osmocom network perspective.
+  This process will be responsible for receiving MO SMs from GSM subscribers
+  and submitting them to themwi-smsc-core, and it will also be responsible for
+  delivering MT SMs to GSM MS once the destination IMSI is known.  It will
+  register with themwi-smsc-core as the role-handler for ROLE_GSM_MT_DELIVERY.
+
+* themwi-smsc-mtimsi will be a much simpler daemon process whose only job will
+  be resolving MSISDNs to IMSIs for MT SMs.  It will register with
+  themwi-smsc-core as the role-handler for ROLE_IMSI_LOOKUP.
+
+In the current (end of 2023) state of Osmocom CNI, there is no way to perform
+an MSISDN-to-IMSI lookup via GSUP.  It is furthermore not obvious how to add
+such capability, and it is not certain if anyone in Osmocom community (other
+than us) even cares about the problem of interfacing external SMSCs via GSUP
+and the associated problem of addressing in the MT direction:
+
+https://osmocom.org/issues/6312
+
+Given this uncertainty and lack of interest from other stakeholders, we shall
+use a not-pretty but very workable solution: themwi-smsc-mtimsi will connect to
+the CTRL interface of OsmoHLR (as opposed to GSUP) and make queries for
+subscriber.by-msisdn-XXXX.imsi - a query-able object that was just recently
+added as a band-aid solution for the current problem.
 
 5. SMPP connection handlers and outside-world SM exchange