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.
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.
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. The SMSC functionality and network positioning in 2/3/4/5G is explained in SMSC – 30 years after
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.
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).
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.
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.
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:
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.
The way the HLR handles the SRI is standardized in 3GPP 29.002 and 23.204. SRI request sent to HLR is relayed to preconfigured IPSMGW GT. IPSMGW then sends the message back to HLR. Only requests which are received from IPSMGW are responded with SRI_SM_ACK. Technically it is also possible to send requests directly from SMSC to IPSMGW.
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.
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.)
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).
Related posts:
Real Time Communication 