Possibility to route SMS messages over GSUP
At the moment there is only one way to route short messages between an Osmocom-based
network and some external entity (e.g. SMSC) - SMPP interface. It's implemented in
both OpenBSC and OsmoMSC, and can be optionally enabled during
the build configuration (using --enable-smpp).
The fundamental problem of SMPP is the need of transcoding between its primitives and
pretty complex SMS protocol. Moreover, in some cases this transcoding is not desired.
In commercial networks MAP (Mobile Application Part, see 3GPP TS 29.002) protocol is
used for forwarding MO/MT short messages between different network entities. There is
a special group of short message management services defined in MAP, see section 12.
The problem of MAP comes from the protocol stack it belongs to - SS7, its complexity.
Instead of SS7/MAP, Generic Subscriber Update Protocol (GSUP) is used in Osmocom CNI.
Basically GSUP is an Osmocom-specific non-standard protocol designed around the same
architecture as the MAP messages/operations, but without the complexity of SS7, and
without the need for ASN.1 encoding.
Implementing a possibility to route SMS messages over GSUP would facilitate the
integration of Osmocom CNI with third-party networks and components. In general,
this task would require us to replicate the SM-related messages and IEs in GSUP,
and to implement proper message forwarding in OsmoMSC.
Draft message sequence charts can be found here: https://gerrit.osmocom.org/10604/
- Checklist item Extend libosmocore's GSUP implementation with SM-specific mesages and IEs added
- Checklist item Extend TTCN-3 library/GSUP_Types.ttcn with SM-specific mesages and IEs added
- Checklist item Extend the Wireshark dissector with SM-specific messages and IEs added
- % Done changed from 0 to 10
Draft implementation (to be discussed) of the following messages:
- SRI_FOR_SM (a.k.a. MAP-SEND-ROUTING-INFO-FOR-SM):
- MO/MT FORWARD_SM (a.k.a. MAP-*-FORWARD-SHORT-MESSAGE):
have been sent for review (topic:gsup_sms).
Please note that most likely we also need to replicate the following messages:
let's move this conversation from Gerrit. To give a bit more background
to other potential participants, the following part of this message is my
thoughts about the questions raised in https://gerrit.osmocom.org/11068/.
I think the big questions is how the "Node address" IE contents is defined.
My question was more whether or not that would make sense in the context
of Osmocom and GSUP, where neither VLR nor SGSN have global titles.
It depends on how are we going to evolve the Osmocom CNI in the future.
If we will stick to the idea of isolating the CNI and having a single
GSUP <-> MAP gateway to communicate with other networks, then for sure
we don't need the "Node address" IE at all.
So basically we're talking about the question of who is sending this message?
Is it a MAP message originated from the external MAP world directed to a
Yep, it's usually being sent to HLR by sending SMSC, but in our case the
request would be processed by GSUP-MAP gateway, and forwarded to OsmoHLR.
In this case, we don't need a GSUP encoding for it, because I expect
the MAP gatway would always respond with its Global Title, no matter
which VLR/SGSN inside the GSUP domain is currently "hosting" the subscriber.
Right, makes sense in case of the "isolated" CNI. If all communication is
routed through a single gateway, there is no need to encode this field.
Or is it a message between one (future) OsmoSMSC and another OsmoSMSC
in a roaming situation between two Osmocom networks? In that case,
the (IP?) address of the OsmoHLR should be returned, as it is the
central router/gateway for GSUP at this point, and individual
VLRs/SGSNs are not able to manage multiple GSUP connections
and route between them.
AFAIR, it's only used between an external SMSC and the "target" HLR.
So my preliminary analysis is that we don't appar to need this message
in the Osmocom/GSUP world. It only exists in the MAP domain and I don't
think we want to replicate the direct communication of external MAP
entities with our VLRs/SGSNs. This is what major operators have
been working to fix by home-routed SMS in the past 5+ years
for security reasons.
This message is also used to obtain the IMSI of a subscriber, so then
IMSI will be used in MT-ForwardSM message. How would we make it work
without that? AFAIK, some operators do indicate random IMSI values,
for security reasons I guess. Maybe, such random IMSIs are actually
mapped somewhere to the real IMSIs, I am not sure here...