IP-SM-GW Transport

Very funny. Even in 2015 we still rely in many ways on the old good SMS. No, operators are not
making the money on the service as they were used to in the past. However it is not easy for
them to fully replace the service (e.g. by RCS). That’s why the VoLTE standard GSMA
IR.92 says:
The UE must implement the roles of an SM-over-IP sender and an SM-over-IP receiver, the IMS
core network must take the role of an IP-SM-GW.

In other words, the VoLTE network has to support the (legacy) SMS sent over SIP. The VoLTE
phone will receive a common (binary) SMS and the native client will display this message as any
other. The only difference is that this time the SMS is sent from an IMS network over SIP
protocol. Mind the purpose is not just to support common text messages, but (more importantly)
to support OTA messaging for (U)SIM provisioning, SMS ‘non-text’ applications or Message
Waiting Indication for Voice Mail.

SMS over IP
The network functionality which provides messaging service in the IMS network is called IP-SM
Gateway (IP-SM-GW) and from the IMS point of view it is an Application Server.

IPSMGW – Network Architecture

From the picture above we can see that the IP-SM-GW is a bridge between 2/3G networks and
IMS. We have two types of IP-SM-GWs defined in 3GPP TS 23.204 (and some OMA
enhancements in 3GPP TR 23.824). Firstly it is a Service Level Interworking (SLI) which can
work with Session or Pager Mode Messaging. And then it is a Transport Level Interworking
(TLI) which can work with SMS over IP only (SMoIP).  This time we will focus on the TLI. The
specification of the TLI is the 3GPP 24.341. If you are not familiar with the SMS flow you can
read the SMS in 2G/3G first.
3GPP standards describe GSM flows only, however it is possible to have IPSM also for CDMA
(ANSI). The logic remains the same, 3gpp2 standard is X.S0064-0.
Registration
As we said the IP-SM-GW acts as a common AS. If UE wants to use SMoIP it has to indicate
this capability during the registration by “+g.3gpp.smsip” in its Contact header.
 IPSMGW Registration

Once the user is registered, the IPSMGW receives the 3rd party registration from the S-CSCF.
The IPSMGW then should indicate the availability of the user in the IMS. This can be internally
(e.g. IPSMGW is a part of SMSC) or there is a standard ATM message which will clear the UE
Not Reachable for IP – UNRI flag on HLR.
GSM Mobile Application

Component: invoke (1)

invoke

invokeID: 1

opCode: localValue (0)

localValue: anyTimeModification (65)

subscriberIdentity: msisdn (1)

msisdn: 912143658709f1

1... .... = Extension: No Extension

.001 .... = Nature of number: International Number (0x01)

.... 0001 = Number plan: ISDN/Telephony Numbering (Rec ITU-T E.164) (0x01)

Address digits: 12345678901

Country Code: 1 Americas (length 1)

gsmSCF-Address: 912143658700f0

1... .... = Extension: No Extension

.001 .... = Nature of number: International Number (0x01)

.... 0001 = Number plan: ISDN/Telephony Numbering (Rec ITU-T E.164) (0x01)

Address digits:12345678000

Country Code: 1 Americas (length 1)

modificationRequestFor-IP-SM-GW-Data
modifyRegistrationStatus: activate (1)
In case the UNRI flag was set, we send also Ready-For-SM

alertReason: ms-Present (0)

which notifies about subscriber’s availability. That means that SMSC will receive AlertSC fom
HLR and it can start with retries of buffered messages.

So after the registration the messages for the user will be send from SMSC via IPSMGW.

Finally the IPSMGW can update the HSS over the Sh Reference point.
IMS-GSM
If the SIP MESSAGE has an SMS payload (binary content) the Content-Type must contain
“application/vnd.3gpp.sms” tag. This information is being used by the S-CSCF in order to find
out which AS should handle the message (as also other ASs can work with SIP MESSAGEs –
e.g. RCS Application server).  Routing towards application servers is driven by Initial Filter
Criteria (iFC).

iFC

IPSMGW accepts the message and forwards it to SMSC as an MO-FW-SM. In this case the
IPSMGW behaves as an originating MSC in the GSM domain.
 IMS to GSM

Note that the SMS-SUBMIT-REPORT is delivered to the originating UE as another SIP

MESSAGE.

Our message from IMS was delivered into SMSC. This is very interesting because in fact the
application server even for IMS is still the legacy SMSC with its store and forward functionality.
IP-SM-GW for Transport Level Interworking (TLI) is “only” a dummy gateway which is
changing the SIP stack for Sigtran stack and vice versa.
 IP-SM-GW stack

IP-SM-GW Transport layer

The SMS payload remains the same.

Session Initiation Protocol (MESSAGE)

Request-Line: MESSAGE sip:ipsm01@operator.com;user=phone SIP/2.0

P-Asserted-Identity:<tel:+123456789012>

Content-Type: application/vnd.3gpp.sms

Content-Disposition: no-fork

Allow: MESSAGE

P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1223344555145db01

From: <sip:+123456789012@operator.com>;tag=1385483750

To: <sip:+123456789022@operator.com>
Contact: 123456789012@172.12.50.1

CSeq:1 MESSAGE

l:31

P-Asserted-Identity:<sip:+123456789012@operator.com>

P-Charging-Vector:icid-value=1364c01c1d6a912a9abc;orig-ioi=operator.com

P-Served-User:<sip:+123456789012@operator.com>;sescase=orig;regstate=reg

Route:<sip:10.10.40.13:5060;transport=TCP;orig;lr;mode=originating>

Route:<sip:is23@scscf20.operator.com:5090;lr>

Message Body

GSM A-I/F RP - RP-DATA (MS to Network)

Message Type RP-DATA (MS to Network)

RP-Message Reference

RP-Message Reference: 0x09 (9)

RP-Originator Address

Length: 0

RP-Destination Address - (12345655022)

Length: 7

1... .... = Extension: No Extension

.001 .... = Type of number: International Number (0x01)

.... 0001 = Numbering plan identification: ISDN/Telephony Numbering (ITU-T Rec. E.164 / ITU-T Rec. E.163)
(0x01)
BCD Digits: 12345655022

RP-User Data

Length: 19

TPDU (not displayed)

GSM SMS TPDU (GSM 03.40) SMS-SUBMIT

0... .... = TP-RP: TP Reply Path parameter is not set in this SMS SUBMIT/DELIVER
.0.. .... = TP-UDHI: The TP UD field contains only the short message
..0. .... = TP-SRR: A status report is not requested
...1 0... = TP-VPF: TP-VP field present - relative format (2)
.... .0.. = TP-RD: Instruct SC to accept duplicates
.... ..01 = TP-MTI: SMS-SUBMIT (1)
TP-MR: 9
TP-Destination-Address - (123456789022)
Length: 11 address digits
1... .... : No extension
.001 .... : Type of number: (1) International
.... 0001 : Numbering plan: (1) ISDN/telephone (E.164/E.163)
TP-DA Digits: 123456789022
TP-PID: 0
00.. .... : defines formatting for subsequent bits
..0. .... : no telematic interworking, but SME-to-SME protocol
...0 0000 : the SM-AL protocol being used between the SME and the MS (0)
TP-DCS: 0
00.. .... = Coding Group Bits: General Data Coding indication (0)
Special case, GSM 7 bit default alphabet
TP-Validity-Period: 3 day(s)
TP-User-Data-Length: (5) depends on Data-Coding-Scheme
TP-User-Data
SMS text: Test
Of course in the raw SIP message (without the help of wireshark) we would see only the binary
content:

!#U !#UW

Note that the R-URI contains (as defined in 24.341) a PSI of SC. The address of recipient is in
the 23.040 (SMS) content as TP-DA.

GSM-IMS
Now we need to deal with the common GSM-IMS flow. It will look somehow like this:
 GSM to IMS

As the SMSC is not aware of any IPSMGW it will try to deliver an MT message as usually. It
means SMSC will issue an SRI request. In a common deployment the SRI will end up in the
IPSMGW. (Very similar to so-called homerouting.) In case the user is currently in IMS (and the
device has the needed capabilities) the IPSMGW wants to receive the MT message. Therefore it
puts its own Global Title (GT) in the Network Node Number (NNN) field in the SRI response.
If the SRI request ends up on a different (secondary) IPSMGW, this one doesn’t have the
information about the subscriber. Therefore it sends a UDR query over Sh interface to the HSS
and gets the information about the primary AS.
 2 IPSMGW sites

Based on this information the SMSC submits the MT-FWSM to the IPSMGW and IPSMGW
will again cut off the Sigtran stack and replace it with SIP. The SMS-DELIVER-REPORT is sent
as a content of a new SIP MESSAGE operation. Once IPSMGW will receive this message it
forwards it over Sigtran to the SMSC.

In case the user is not currently reachable in the IMS domain, the IPSMGW can perform a
second delivery in the GSM network (SRI, MT-FWSM). Both delivery attempts (1st in IMS, 2nd
in GSM) are done in a transactional mode. The final delivery result is then sent to the SMSC. If
the IPSMGW is not able to deliver the message, it is the SMSC which does the retry. (IPSMGW
updates the HLR with R-SM-DS message.)
 IPSMGW – CS Fallback

For UHD segmented messages the IPSMGW works in the same way (for both IMS-GSM, GSM-
IMS). It forwards each segment as a separate message. The IPSMGW receives only one SRI
request for all the segments.

Note that instead of Sigtran some other protocols can be used – as SMPP (which is very smart
for cloud deployments).