In December 1992 there was sent the first SMS. At that time there were several different vendors working on their first SMSCs. I was lucky enough to work later with some of the engineers involved. Anyways that is an ancient history now. Since that the SMS Service and the SMSC have become a must for every mobile network. Perhaps we can go trough the general SMSC network architecture, list some of the typical features and then to discuss the SMS evolution in 5G networks.
The SMSC was designed as an integral part of 2G mobile network, supporting several basic message flows, which are mostly valid even in 2022:
- Person-to-Person (P2P)
- Application-to-Person (A2P/P2A). This was a real game changer. People in late 90s were texting (and paying) as crazy to get new ringing tones, text-frames on their monochromatic displays or at least a weather forecast or bus schedule. The A2P is still a popular way how to create a significant wholesale interconnection and also valid for MIoT (Mobile Internet of Things). Last but not least we shouldn’t forget the importance of SMS in Two-Factor-Authentication (2FA).
- Technical enabler: Over the Air OTA messaging for (U)SIM provisioning. OTA is still critical for many operators. Another example is an IP session wake-up, which might be a key technical enabler for some Machine Type Communication MTC/MioT applications.
The main SMSC task is to provide an interworking between various interfaces (GSM, CDMA, SMPP, SIP, ..) and the Store-and-Forward functionality. Meaning the SMSC provides a guaranteed service. It receives an SMS, provides basic checks (e.g. charging) and if they pass, the SMS is stored. The originator then receives an ACKnowledgement, confirming that the SMS was accepted. Note, that the SMSC is a server located in the originating network and therefore it primarily applies originating services (although it is possible to apply terminating services too, using so-called Homerouting).
Then comes the delivery phase. Based on the Routing Information retrieved from HLR, the SMSC tries to deliver the message. If the delivery fails, the SMS is scheduled for a retry based on (error-dependent) retry scheme. The sender of the SMS will only learn if the recipient has received the SMS if she selected the Delivery Confirmation option. The basic flows are described in SMS in 2G/3G post.
SMS Center Basics
The most important parameter of every SMSC is the throughput. How many SMS per second can be accepted/processed. Vendors often talk about transaction per second – TPS. Depending on scenario (P2P, A2P, SMPP Gateway, ..) there might be 1/2/3 .. TPS required for one SMS to be processed.
As the number of SMS may vary a lot, it is critical that SMSC is able to deal with message storms and handle short bursts of traffic, which go above the licence. Overload protection mechanism is often implemented as some sort of token-bucket algorithm, but there are many other options.
Another important parameter is how many messages can be stored. Typically most of the messages are delivered during the first delivery attempt. That led to an idea to separate queues or even whole nodes (fronted-backend) for the First-Deliver-Attempts (FDA) and Retry Attempts (which require a persistent storage and therefore are more expensive). Also in order to optimize routing of message in the network you can find special types of SMSCs called SMS-Router, MT-Router or Foreign Subscriber Gateway (FSG) which can apply some special services and handle SMS in a proxy or relay mode.
One of the basic functions every SMSC must have, is an ability to manipulate telephone numbers, so that it is possible to handle and translate various numbering formats as well as to apply black/white listing and prefix-specific routing e.g. using distribution lists. For a correct routing of ported numbers it also required support of Mobile Number Portability (MNP).
SMS Content
There are many attributes defining how to handle the SMS. We can send a simple SMS or we can send a concatenated message. We can send SMS with a defined priority level. SMS may contain binary data using User Data Header (UDH) or a command requesting SMSC e.g. to send delivery receipt, defer the delivery or to send the message anonymously.
When it comes to the actual text payload, there are multiple character sets to choose from. It is important to notice that as each character set is using a different number o bits, the selection has an impact on the actual message length and therefore message segmentation. By default the SMS length is 140 octets. With GSM-7bit alphabet we can write up to 160 characters per SMS. Whereas with UCS-2 it is only up to 70 characters. In case of segmentation it is even less as UDH data, controlling the concatenated message, is part of the payload.
The actual message payload may be a subject to content-based filtering or antispam check.
SMS Security
SMS should be a trusted from the end user perspective as well as from the wholesale perspective. However, there have been many security issues identified, see GSMA IR.70 and IR.71 for the details.
- SMS Spamming: an unsolicited SMS traffic received by a subscriber. There are no specific technical aspects. The sending of messages follows the normal procedure.
- SMS Flooding: appears when a very large number of messages is sent to one or more destinations. With specific technical aspects – Protocol is manipulated to send messages bypassing the normal procedure for message sending.
- SMS Faking: is a specific case where SCCP or the MAP originator addresses are manipulated and replaced wrongly or stolen from a valid subscriber. Thepurpose is to deliver the SMS for free (impossible for the receiver network to invoice the correct originator).
- SMS Spoofing: is related to an illegal use of the HPMN SMSC by a third party. To do that, the A-MSISDN that originates the SMS is manipulated to be able to use the HPMNu SMSC. Therefore, the SMS could be sent for free by the sending customer.
- Global Title GT scanning: is sending a SM-MO to ALL GTs of one network to detect SMSC and especially SMSC not controlling the A-number. The final objective is to be able to send the SMS for free.
- Open SMSC: is SMS-C not controlling the A-number. The SMSC can be used by illegal customers (not part of HPMN).
Commercial SMSCs have (licenced) features preventing or mitigating the above-mentioned threats. A typical way how to detect a fraud traffic is to verify the IMSI and location (MSC/SGSN) of the originator.
Charging
Both pre-paid and post-paid charging is supported. In the pass we were relaying on Camel signaling for online charging. Currently the most popular solution is a use of Ro Interface directly from SMSC (so we can handle both Voice and SMS data in a similar fashion). More details at VoLTE Online Charging – SMS.
SMS in 4G
The SMSC was designed for 2G/3G networks. In 4G we faced the issue how to implement the messaging service. The original idea was to replace SMS with GSMA Advanced Messaging – RCS Universal Profile. However it was quickly clear, that this won’t work for everyone. Instead several options were devised. The key thing is that all of them are using the legacy (2G/3G) SMSC.
4G SMS over SGsAP and MAP
With 4G introduction, an intermediate environment without IMS was specified. This is called SMS over the Signalling Gateways SGs (evolved Gs interface) and it is a hybrid approach that allows the transmission of native SMS from a CS infrastructure over the LTE radio network. SMS over SGs was specified in 3GPP TS 29.118. The SGs based on GS is used to handle mobility management and paging procedures between the EPS and CS domain, however for SMS it is used to deliver both mobile originating and terminating SMS.
4G SMS over Diameter (SMS over NAS)
Diameter protocol was introduced with 4G to transport SMS between MME and SMSC. It could also apply on some SGSN supporting EPS interfaces.
SMS in MME enables support of MO and MT SMS over LTE without requiring any involvement of any MSCs. Instead of delivering MT-SMS via the MSC (which would require the UE to be registered in the CS domain), the Short Messages pass directly between the MME and the SMSC using a new Diameter-based interface SGd.
In the 4G context and as specified in 3GPP TS 24.301, the Non Access Stratum NAS Protocol to carry the encapsulated SMS messages between the UE and MME is used. The NAS is a set of protocols in the ePC, which in uour case is used to convey non-radio signalling between UE and MME for LTE/E UTRAN. The SMS messages CP-DATA, CP-ACK and CP-ERROR are carried in the NAS Message Container IE in the Uplink or Downlink NAS Transport message within the NAS PDU. The Diameter protocol support for SMS is defined in 3GPP 29.338.
SMS over MAP/Diameter (SMS over IP)
Apart from RCS messaging, 4G network envisioned support of the SMS sent over SIP (aka SMSoIP). This is probably the most typical 4G messaging solution. However in this case the actual messaging server is not withing the IMS network, as the service is facilitated by the legacy SMSC positioned withing 2G/3G. Instead we are making use of so-called Trasport Level Interworking TLI. The TLI is implemented as IP-SM-GW, placed between the IMS core and the legacy domain.
It is important to note that IP-SM-GW is connected to the HLR/HSS and is able to communicate with it both with MAP or Diameter (standardized in 3GPP TS 23.204 v14.0.0).
The call flows are described in IP-SM-GW Transport Level Interworking post. The diameter based call flow (using OFR, SFR, TFR) is described in NG.111, the Diameter protocol support for SMS is defined in 3GPP 29.338.
SMS in 5G
In 5G we have again two options. Either we can make a use of existing IMS network and use IP-SM-GW or the specification defines a new 5GS network element called SMSF, which supports SMS over NAS transport.
More specifically, in 5G the UE must and the network can support both SMS over IP (same as in 4G) and SMS over NAS signalling methods. However, the network must support at least one of the above methods, i.e. either SMS over IP or SMS over NAS signalling method.
5G SMS in MAP/Diameter (SMS over NAS)
SMS for 5G is defined in 3GPP 23.501 and the SMS architecture in 3GPP 29.891. Again, both MAP and Diameter are supported in 5G between SMSF and SMSC.
The protocols group CT4 has decided that network protocols should be used for SBA. It will be HTTP2 on top of TCP, (no longer SCTP!). 5G signalling (based on HTTP2/JSON) shall apply in the 5G Core Network.
The 5G Support for SMS requires the following functionality:
- Support for SMS over NAS transport between UE and AMF. This applies to both 3GPP and Non 3GPP accesses.
During Registration procedure, a UE that wants to use SMS provides an “SMS supported” indicating the UE’s capability for SMS over NAS. If the 5GS supports the SMS functionality, the AMF includes “SMS allowed” indication to the UE, and whether SMS delivery over NAS is accepted by the network. SMS is transported via NAS transport message, which can carry SMS messages as payload.
- Support for AMF determining the SMSF for a given UE.
- Support for subscription checking and actual transmission of MO/MT-SMS transfer by the SMSF.
- Support for MO/MT-SMS transmission for both roaming and non-roaming scenarios.
- Support for selecting proper domains for MT SMS message delivery including initial delivery and re-attempting in other domains.
MTC/MIoT SMS
Described in 3GPP TS 23.682.
Future SMS architecture
As we could see various architectures exist and are foreseen in the future to transport SMS for 4G (using Diameter), IMS (using SIP) and 5G. The 4G SMS could be transported by Diameter while IMS/5G SMS could select MAP or Diameter in order to interconnect with SMSC and HLR/HSS. GSMA in NG.111 envisions the following SMS architecture:
Generally MNO can select whatever migration path wants to follow and step by step replace the legacy MAP messaging with Diameter. RCS doesn’t take over and even in 5G we bet on legacy SMS service and utilize the existing SMSCs.
Although technically it should be enough to add Store-and-Forward functionality into IPSMGW (or simply merge with SMSC, as it is often done anyways), the standardization bodies are trying to maintain an option to support legacy SMS without the need of IMS network.
For those who want to learn more:
Real Time Communication 