Project

General

Profile

Actions

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:
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/


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 supportStalled02/23/2016

Actions
Related to OsmoMSC - Bug #5564: blocking database I/O by SMS databaseStalledlaforge05/15/2022

Actions
Actions #1

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:

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 #2

Updated by fixeria over 5 years ago

Actions #3

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 #4

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 #5

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 #6

Updated by fixeria over 5 years ago

  • Checklist item Document the new SM-related GSUP extensions added
Actions #7

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 #8

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 #9

Updated by fixeria about 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 #10

Updated by fixeria about 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 #11

Updated by fixeria about 5 years ago

  • Checklist item Add MSC diagrams to osmo-gsm-manuals set to Done
Actions #12

Updated by fixeria about 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 #13

Updated by fixeria almost 5 years ago

  • Checklist item Add MSC diagrams to osmo-gsm-manuals set to Done
  • Status changed from Feedback to Stalled
  • Priority changed from High to Normal
Actions #14

Updated by laforge almost 5 years ago

It's confusing to still have this ticket open. Maybe move the MMS related checklist item to a separate ticket and close this one?

Actions #15

Updated by fixeria almost 5 years ago

  • Checklist item OsmoMSC: properly handle MMS indication set to Done
  • Status changed from Stalled to Resolved
  • % Done changed from 90 to 100

It's confusing to still have this ticket open. Maybe move the MMS related checklist item to a separate ticket and close this one?

Since the patch has been merged, we can finally close this ticket.

Actions #16

Updated by laforge almost 2 years ago

  • Related to Bug #5564: blocking database I/O by SMS database added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)