SMSC – 30 years later

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.

_{2G/3G SMSC Architecture}

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.

VoLTE Online Charging – SMS

Today we will start with Online Charging, or Ro interface in our terminology. And because Online Charging is a bit more complex than Offline Billing, we’ll split it into several posts. In this first one we will take a look at so-call Direct-Debiting, which is used mainly for charging of SMS Service.

Perhaps from our Charging Overview you remember that we can use two different approaches to the Online Charging – Session based or Event based. SMS Ro Charging is using Event based mechanism. It is easier than the Session based and we will also need it later to complement the Session based Charging for the Voice service.

The SMS Charging architecture is standardized in 3GPP 32.274, the SMS online charging then uses the Credit-Control application as specified in TS 32.299.

Ro Reference Point for SMS

The Online Charging is triggered over Ro Reference point. It is up to a Mobile Operator if they will signal charging operations from IP-SM-GW, SMSC, SMS Router or any combination of these. Typically the charging requests are sent from SMSC only. For simplicity we will refer only to the SMSC in the following text. SMSC may either directly support Ro interface, or it can use CAP (CAMEL) protocol which is then translated to Ro by an Interworking Function (IWF) as described in 3GPP 32.293.

The SMS charging may use two different models:

• Immediate Event Charging (IEC)

or

• Event Charging with Unit Reservation (ECUR)

In this post we will rather focus on IEC, as the ECUR is more complex and in my personal experience it is less common than IEC. The ECUR principle is specified in TS 32.299.

Group … Messaging

RCS could be probably deployed much faster if it wasn’t that general right from the beginning. To implement a simple 1-1 chat is not a big deal. The same applies for voice and video. And honestly one doesn’t expect much from a new product as long as the basic functionality is working fine.

Well, in case of RCS/RCSe group messaging was always referred as a basic one. But sometimes it was not without struggles. There are many ways how a Conference can be established. Just to find out all the relevant RFCs is not an easy task. RCS Group Chat technical realization is based on the “Ad-Hoc Session Mode messaging”. RCS is referencing to OMA-SIMPLE or OMA-CPM. OMA is defining their ways how to handle the chats and pointing to particular RFCs. Many of them. The basic one is the RFC 4353. In this document it is described the logical architecture. Simply put group messaging is a multi 1:1 chat. All the participants will establish a 1:1 chat with a center point called “focus”. This logical role is implemented as a part of RCS (CPM/SIMPLE) server functionality.

Group Chat – focus

As mentioned, in case of RCS we mostly talk about ‘Ad-hoc’ conferencing. That means that the conference does not need to be scheduled or reserved, but is created “on the fly”. The benefit of this approach is that the conference URI doesn’t need to be known to the user; instead it is created by the focus (RCS server) and used by the participants’ UAs. The SIP URI of the Conference Factory is usually provisioned in the client (as in a “create new conference” button).

IP-SM-GW Transport Level Interworking

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.

Messaging in RCS

Instant (multimedia) messaging is a key feature for RCS as it should replace SMS service. There are more types of messages which can be sent through the IMS network.

When we will take a look on the SIP indication of capabilities by Accept header there are quite a few of supported formats:

• Text/plain
• Message/CPIM
• Application/reginfo+xml
• Application/vnd.3gpp.sms
• Message/imdn+xml
• Application/3gpp-ims+xml

For common Instant Messages we typically use Common Profile for Instant Messaging (CPIM). This format allows compatibility among various messaging technologies. Notifications are then sent as in Instant Message Disposition Notification (IMDN) format.

Messages can be exchanged over SIP or MSRP protocol. Sometimes  also http/ws is being used for transfer of rich content.

Update: For the information about RCS Universal profile read the post GSMA Advanced Messaging – RCS Universal Profile.

RCS 5.2 defines two basic types of messaging. They are the Session Mode Messaging which is based on SIP INVITE and MSRP session and the Pager Mode Messaging which is based on SIP Message. The RCS refers to OMA CPM which is considered to be an evolution of the SMS/MMS messaging services.

Note that SIP MESSAGE can be used also for other than messaging purposes in IMS network (e. g. during eSRVCC registration)

 

Session Mode Messaging

Session mode does use SIP INVITE and SDP protocol to establish the session. Within the session MSRP protocol is used. This allows to split ones conversation into dialogs and use “..is typing” notifications. On the other hand more resources is needed.

IMS and MSRP