Feature #3587: Possibility to route SMS messages over GSUP - Cellular Network Infrastructure - Open Source Mobile Communications

Custom queries

all-by-project

Actions

Copy link

Feature #3587

closed

Possibility to route SMS messages over GSUP

Added by fixeria over 5 years ago. Updated almost 5 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

fixeria

Target version:

Start date:

09/25/2018

Due date:

% Done:

100%

Spec Reference:

3GPP TS 29.002

Description

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/

Hide closed

Checklist

Extend libosmocore's GSUP implementation with SM-specific mesages and IEs
Extend TTCN-3 library/GSUP_Types.ttcn with SM-specific mesages and IEs
Extend the Wireshark dissector with SM-specific messages and IEs
OsmoMSC: introduce kill-switch for routing SMS over GSUP
OsmoMSC: forward MO SMS messages over GSUP
OsmoMSC: accept MT SMS messages over GSUP
TTCN-3: testing coverage for MO SMS / SMMA
TTCN-3: testing coverage for MT SMS
TTCN-3: test case for multi-part SMS
Document the new SM-related GSUP extensions
Add MSC diagrams to osmo-gsm-manuals
OsmoMSC: properly handle MMS indication

Related issues

Related to OsmoSGSN - Feature #1587: SMS over GPRS support

Stalled

02/23/2016

Actions

Related to OsmoMSC - Bug #5564: blocking database I/O by SMS database

Stalled

laforge

05/15/2022

Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by fixeria over 5 years ago

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):
- https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11061/
- https://gerrit.osmocom.org/#/c/libosmocore/+/11068/

MO/MT FORWARD_SM (a.k.a. MAP-*-FORWARD-SHORT-MESSAGE):
- https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11062/
- https://gerrit.osmocom.org/#/c/libosmocore/+/11069/

have been sent for review (topic:gsup_sms).

Please note that most likely we also need to replicate the following messages:

MAP-REPORT-SM-DELIVERY-STATUS
MAP-ALERT-SERVICE-CENTRE
MAP-READY-FOR-SM

Actions

Copy link

Updated by fixeria over 5 years ago

Related to Feature #1587: SMS over GPRS support added

Actions

Copy link

Updated by fixeria over 5 years ago

Hi Harald,

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
GSUP-MAP gateway?

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...

Actions

Copy link

Updated by fixeria over 5 years ago

Checklist item Extend libosmocore's GSUP implementation with SM-specific mesages and IEs set to Done
Checklist item Extend TTCN-3 library/GSUP_Types.ttcn with SM-specific mesages and IEs set to Done
Checklist item Extend the Wireshark dissector with SM-specific messages and IEs set to Done
% Done changed from 10 to 40

libosmocore (ready for review):

https://gerrit.osmocom.org/#/c/libosmocore/+/11069/ - GSUP/SMS: introduce MO-/MT-FORWARD-SM messages
https://gerrit.osmocom.org/#/c/libosmocore/+/11751/ - GSUP/SMS: introduce READY-FOR-SM message

TTCN-3 (WIP):

https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11062/ - library/GSUP_Types.ttcn: add MO-/MT-FORWARD-SM messages
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11752/ - library/GSUP_Types.ttcn: add READY-FOR-SM message

Wireshark (WIP):

https://code.wireshark.org/review/#/c/30586/ - GSUP/SMS: add MO-/MT-FORWARD-SM message decoding
https://code.wireshark.org/review/#/c/30587/ - GSUP/SMS: add READY-FOR-SM message decoding

Actions

Copy link

Updated by fixeria over 5 years ago

Checklist item OsmoMSC: introduce kill-switch for routing SMS over GSUP added
Checklist item OsmoMSC: forward MO SMS messages over GSUP added
Checklist item OsmoMSC: accept MT SMS messages over GSUP added
Checklist item TTCN-3: testing coverage for MO SMS / SMMA added
Checklist item TTCN-3: testing coverage for MT SMS added
Checklist item TTCN-3: test case for multi-part SMS added

As was asked by Harald, the new GSUP IEs and message types have been documented:

https://gerrit.osmocom.org/#/c/osmo-gsm-manuals/+/11836/ - chapters/gsup.adoc: document MO-/MT-forwardSM messages
https://gerrit.osmocom.org/#/c/osmo-gsm-manuals/+/11837/ - chapters/gsup.adoc: document READY-FOR-SM message

Neels wrote a few recommendations and warnings, which I am going to address soon.

Actions

Copy link

Updated by fixeria over 5 years ago

Checklist item Document the new SM-related GSUP extensions added

Actions

Copy link

Updated by fixeria over 5 years ago

Checklist item OsmoMSC: introduce kill-switch for routing SMS over GSUP set to Done
Checklist item OsmoMSC: forward MO SMS messages over GSUP set to Done
Checklist item OsmoMSC: accept MT SMS messages over GSUP set to Done

https://gerrit.osmocom.org/#/c/osmo-msc/+/11918/ - libmsc/VTY: introduce kill-switch for routing SMS over GSUP
https://gerrit.osmocom.org/#/c/osmo-msc/+/11919/ - libmsc/gsm_04_11.c: forward MO SMS messages over GSUP
https://gerrit.osmocom.org/#/c/osmo-msc/+/11920/ - libmsc/gsm_04_11.c: accept MT SMS messages over GSUP

Actions

Copy link

Updated by fixeria over 5 years ago

Checklist item TTCN-3: testing coverage for MO SMS / SMMA set to Done
Checklist item TTCN-3: testing coverage for MT SMS set to Done
Status changed from New to In Progress
% Done changed from 40 to 80

https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11718 - MSC_Tests.ttcn: introduce TC_gsup_mo_sms for MO SMS over GSUP
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11776 - MSC_Tests.ttcn: introduce TC_gsup_mo_smma for MO SMMA over GSUP
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11924 - MSC_Tests.ttcn: introduce TC_gsup_mt_sms_{ack|err} for MT SMS over GSUP

Actions

Copy link

Updated by fixeria over 5 years ago

Checklist item Document the new SM-related GSUP extensions set to Done
Checklist item TTCN-3: test case for multi-part SMS set to Done
Status changed from In Progress to Feedback
% Done changed from 80 to 90

Everything seems to be done:

libosmocore was extended with SM extensions (patches merged);
all SM extensions were documented in osmo-gsm-manuals (patches merged);
GSUP dissector in Wireshark was updated (patches merged);
GSUP implementation in TTCN-3 was also extended with SM extensions (patches merged);
Patches for OsmoMSC were rebased and waiting for review now;
TTCN-3 test cases to be merged as soon as OsmoMSC patches are merged.

Actions

Copy link

#10

Updated by fixeria over 5 years ago

Checklist item Add MSC diagrams to osmo-gsm-manuals added

There is an initial version by Harald:

https://gerrit.osmocom.org/#/c/osmo-gsm-manuals/+/10604/

which still needs to be updated.

Actions

Copy link

#11

Updated by fixeria over 5 years ago

Checklist item Add MSC diagrams to osmo-gsm-manuals set to Done

Updated, please see:

https://gerrit.osmocom.org/#/c/osmo-gsm-manuals/+/10604/

Actions

Copy link

#12

Updated by fixeria over 5 years ago

Checklist item OsmoMSC: properly handle MMS indication added
Checklist item Add MSC diagrams to osmo-gsm-manuals set to Not done

All patches, excluding https://gerrit.osmocom.org/#/c/osmo-gsm-manuals/+/10604/ have been finally merged.
laforge, please let me know if I am missing something, or let's finally merge it.

OsmoMSC is now capable to forward both MO and MT messages over GSUP. But we still don't handle MMS
indication in OsmoMSC, so in case of multi-part SMS, every message would cause the channel establishment
and release... The proposed approach in https://gerrit.osmocom.org/#/c/osmo-msc/+/12059/ is still to be
discussed, but it makes the corresponding test case pass.

Actions

Copy link

#13