SMS Hubbing Considerations

Topic Keywords: SMPP, SMPP Server, SMS hubbing

NowSMS is frequently used to provide SMS message routing connectivity between multiple SMSCs using the SMPP protocol. The purpose of this document is to clarify issues that are frequently encountered in SMS hubbing configurations.

In SMS hubbing configurations, NowSMS is connected to one or more service providers using the SMPP protocol. Service providers route selected SMS messages to NowSMS over an SMPP connection, and NowSMS is then used to route the SMS message to a different service provider over another SMPP connection.

The concept is simple, but the implementation can be challenging, due in part to issues of routing and mobile number portability (MNP), and due to the architecture of the SMPP protocol.

Message routing in NowSMS is controlled by either prefix routing or dynamic HTTP-based routing callbacks. Message routing is discussed in a separate article titled Dynamic SMS Message Routing with HTTP Callbacks.

When configuring an SMPP connection for hubbing, an important consideration is which party initiates the connection. This is important because the SMPP protocol assumes a client-server relationship. The party that initiates a connection is the client, or ESME. The party that accepts the connection is considered the server, or SMSC.

SMPP connections where NowSMS initiates the connection (NowSMS = ESME) are defined in the “SMSC” list.

SMPP connections where the other party initiates the connection (NowSMS = SMSC) are defined in the “SMS Users” list.

An ESME transmits SMS messages to an SMSC using an SMPP data packet called submit_sm.

An SMSC transmits SMS messages to an ESME using an SMPP data packet called deliver_sm.

Figure 1 illustrates the typical message flow in a simple ESME to SMSC configuration.

A hub connection is not a client-server relationship, instead logically it is a peer-to-peer connection. However, the SMPP protocol rules must still be followed and submit_sm or deliver_sm must be used depending on the direction of the connection.

Differences between submit_sm and deliver_sm create problems for message ID tracking, particularly with regard to delivery reports. This is because SMPP message IDs are not global, but exist only on a hop-by-hop basis.

When an ESME submits an SMS message to an SMSC using submit_sm, the SMSC assigns a new message ID when accepting the message, and returns the newly assigned message ID in the submit_sm response. The SMSC has no knowledge of any previously assigned message ID. From this point forward, any delivery reports that might be generated will reference the message by this new message ID. Any upstream SMSC will eventually route a deliver_sm packet containing this delivery report back to the ESME, and the ESME will need to have remembered/tracked the message ID assignment from the submit_sm response in order to know the message to which it refers.

In an SMS hubbing scenario, if an SMSC has a message to route to an ESME, it uses deliver_sm to transfer the message. The deliver_sm packet contains no message ID information, so the receiving ESME has no knowledge of message IDs that were previously assigned to the message. To further process the message, the ESME needs to assign a new message ID to the message. Unlike the submit_sm response, the deliver_sm response cannot report this newly assigned message ID back to the other side of the connection. Any delivery reports generated will reference this new message ID, however this message ID is not known to the original SMSC, and it cannot be tracked back to the original message to which it refers.

Figures 2 and 3 highlight the problems encountered when the SMS hub functions solely in the role of SMSC or ESME.

In a typical SMS aggregator scenario, an upstream SMSC functions as both an SMSC and ESME when routing messages, and is able to successfully route messages from ESME to the upstream SMSC and delivery reports from the upstream SMSC back to the ESME, as shown in Figure 4.

However, this scenario still expects a client-server relationship.

There are two ways to overcome these limitations for true peer-to-peer SMS hubbing.

1.) Each side of a hub connection connect to the other party as both ESME and SMSC. Regular SMS messages are always routed from ESME to SMSC, and delivery reports are always routed from SMSC to ESME. From a NowSMS perspective, the NowSMS initiated connection is defined in the “SMSC” list, and the other party initiated connection is defined in the “SMS Users” list.

This scenario is illustrated in Figure 5.

2.) Instead of using submit_sm and deliver_sm, the SMPP protocol defines an alternative packet format called data_sm. This data_sm packet can be used regardless of the direction of the connection, and when used in place of deliver_sm, can return message ID information. NowSMS 2013 provides configuration settings to enable the use of data_sm for either an ESME or SMSC connection.

This scenario is illustrated in Figure 6.

NowSMS always performs automatic SMPP message tracking, translation and routing for delivery reports. However, the expected flow of delivery reports is from SMSC to ESME. In order for NowSMS to be able to properly understand and route a delivery report received from an ESME (i.e., “SMS Users” connection), NowSMS must be configured to “Use data_sm PDU” when communicating with this account.

Similarly, If the connection is defined in the NowSMS “SMSC” list, it is also normal to enable the setting “Re-Route Received Messages for Outbound Delivery” under the Advanced Settings for the SMPP connection. Normally, messages received from an SMSC connection are routed to a 2-way command for processing. This setting changes the behaviour so that messages received from this SMSC connection are queued for outbound delivery.

Important Note: Do not confuse SMS hubbing and ESME/SMSC roles with the concept of whether or not to use a transceiver connection. The concept of one connection vs. two connections is similar, but different.

When an ESME initiates a connection to an SMSC, it specifies what type of connection it wants. Connection types are transmitter (send only), receiver (receive only) and transceiver (send and receive). When NowSMS connects to an SMSC, the default behaviour is to use separate transmitter and receiver connections. Transceiver mode can be enabled to use a single connection for both sending and receiving messages.

With a transceiver connection, the initiating side of the connection is still considered to be in the role of ESME. Therefore the hubbing considerations of which party is ESME and which is SMSC still apply.