Project

General

Profile

Feature #3587

Possibility to route SMS messages over GSUP

Added by fixeria 3 months ago. Updated 24 days ago.

Status:
In Progress
Priority:
High
Assignee:
Target version:
-
Start date:
09/25/2018
Due date:
% Done:

80%

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/


Related issues

Related to OsmoSGSN - Feature #1587: SMS over GPRS supportStalled2016-02-23

History

#1 Updated by fixeria 3 months 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

#2 Updated by fixeria 3 months ago

#3 Updated by fixeria 2 months 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...

#4 Updated by fixeria 24 days 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

#5 Updated by fixeria 24 days 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.

#6 Updated by fixeria 24 days ago

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

#7 Updated by fixeria 24 days 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

#8 Updated by fixeria 24 days 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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)