Technical aspects of starting a SMS business
Protocols and equipment for SMS: SMSC, ESME, SMPP and others
In the previous post we discussed reasons what makes SMS business attractive and why VoIP operators should consider joining the crowd. Today let's check out what are the building blocks of a small to medium sized SMS operation and what technical knowledge is necessary to start it.
As mentioned before, SMS is integrated into GSM networks and does not require data connection to operate. Delivery of messages is ensured by SMSC (Short Message Service Center), a network element which receives, stores and forwards messages to/from the mobile phones (terminals). Note, there is function of storing, because mobile phones are not available all the time – they might be switched off or out of coverage, thus SMSC stores messages until either phone becomes available or message expires.
Short messages which are sent from mobile phones are called Mobile Originated (MO), and sent to mobile phones are called Mobile Terminated (MT). Sometimes we can also read that messages sent from/to external services or applications are similarly called Application Originated (AO) or Application Terminated (AT). This gives three main different origination-termination combinations: MO-MT, AO-MT and MO-AT.
In case when messages originate or terminate outside of mobile network, and additional piece of equipment is usually used: ESME or External Short Message Entity. It ensures that AO/AT messages are properly routed between applications needing messaging services and SMSCs. ESMEs do not have to deal with mobile or GSM specific issues like roaming, hand-off, storing etc.. instead ESMEs are more application-oriented, and are an interconnection points for applications to reach mobile networks messaging services.
Most widely used protocol for interconnection between SMSCs and ESMEs today is SMPP (Simple Message Peer to Peer). This protocol defines connections or “binds” between two endpoints wishing to exchange messages. If we draw very very rough parallels with SIP, then one can say that SMPP also does similar things: it allows one side (client) to register to the other (server), send and receive messages (like calls in SIP) and check other sides availability. In reality, of course there are differences from SIP. For example, while in SIP you can make call directly by sending INVITE without REGISTER, in SMPP you are always expected to have a bind (registration). Also, what is important, there are three types of binds: Transmit (TX), Receive (TX), or Transmit/receive (transceiver, TXRX). The client allowed for RX, for example will only be allowed to receive messages, not send.
Another important detail of SMPP message is that MT and MO messages have different names, as opposed to SIP where you have same INVITE for any call. In SMPP request to send MT message is called Submit_sm, and request to send MO message is called Deliver_sm. In other words, message is always “submitted” to the phone, and “delivered” when received from the phone.
Apart from text message itself a SMPP PDU contains lots of details necessary for message delivery, like source and destination addresses, addressing types, data encoding scheme, message validity period, and delivery receipt flags. We have discussed mechanics behind data coding in SMPP messages in an earlier post. One small note that in SMPP you can set “delivery receipt” flag which says that sender wants to be notified when/if recipient has received the message. The sender can request to be notified when either SMSC has received the message, or the message has reached the enduser or both cases. Interesting that DLR (delivery request) itself is not a special kind of SMPP message, it is just a regular DeliverSM sent back by SMSC.
One of the weaknesses of SMPP protocol is lack of security: neither the messages, nor PDUs itself use any kind of encryption, and therefore even bind passwords are transmitted cleartext, which makes it possible for third party to eavesdrop the connection and see all communication. For this reason many SMSC providers either choose to use private VPNs when SMPP travels over public network (internet) or use TLS/SSL to encrypt all SMPP traffic entirely from endpoint to endpoint.
Operators entering this market should consider whether they are looking to have thir own ESME server to establish SMPP connections with Carriers SMSCs, or they rather use ESMEs provided by intermediate parties. Each approach has its advantages and disadvantages. Here are few which just came in my mind:
Advantages:
- Cutting intermediate costs;
- Higher network throughput by using SMPP;
- More direct control (due to SMPP: coding, DLRs, etc)
Disadvantages:
- Expenses to administer own SMPP connections (staff, equipment),
- Security (see above)
This was brief technical description of SMPP and related equipment. See also my other post about SMS support in DataTechLabs products.
UPDATE 2019-02-28: See more recent post entry about Practical Steps to start SMS business using our software and Types of SMS Services Small and Medium Operators Can Provide.
