Smppcube Enterprise Plus v1 Application Architecture

Introduction

Smppcube Enterprise Plus edition provides fantastic end-user interface with

Architecture Overview

Smppcube Enterprise Plus utilises the best and the latest of the tools available to
optimise the performance of the core app. Please have a look at the abstract
representation of the app below:

As you can see how Smppcube sits between your customers and SMSC. It
provides a feature rich interface to compose and get reports for campaigns and
providing billing and routing facilities to the resellers and the aggregator. Lets
briefly understand the flow of SMS campaign for two types of end users:

• Direct or HTTP/XML API clients: These clients will use your platform directly,
they will send SMS either by logging into the app and launching campaign from
compose SMS page. Or they can use HTTP/XML API to send campaign requests
to our app. In both these cases our PHP engine handles these requests. A smaller
campaign (e.g. 1-100 SMS. This can be set by Admin) is sent directly to Kannel
 for processing hence taking a higher priority. In case of bulk submissions, the
system prepares batches and put them in queue. The queue is DB powered
(MariaDB 10). A background process picks these batches and put them in Kannel
in a FIFO manner. The batch size can be decided based on TPS provided by
SMSC.
• SMPP Clients: Processing is little different here for high availability. Every single
SMS (or PDU) is received by Node server and saved in a high speed Redis
storage. Here the SMS are grouped according to system_id (SMPP client who
sent the sms) and time of SMS submission. Then these are processed from Redis
and pushed to SQLBOX which then sends them to Kannel. Using SQLBOX for
SMPP clients achieve a higher performance than HTTP submissions. Redis cleans
the processed SMS from its memory and stores these sent SMS in MariaDB, our
main storage.

SMS Routing #1 - Straight coverage

Let's understand how Smppcube provides various ways to route messages based
on preference of Administrator. The first method is called straight coverage where
the SMS is routed to the SMPP channel selected by sender. In this case SMS
sender will have an option in the compose SMS page to choose the SMS route he/
she wants to use for the campaign. One client can have many routes assigned. To
follow this routing model you would have to make sure 1 route maps to 1 country.
However, one route may have an underlying SMPP which supports multiple
countries. Take a look at this routing:

Here user “Sam” has been assigned Route-1 and Route-2. So if Sam wants to send
campaign to India, he needs to manually choose Route-1 on compose SMS page in
the app. As you can see the SMS sent by Sam will travel from Route-1 to the
SMPP A (if active) or SMPP B (if main SMPP is down). You can define SMS price for
each route separately. Hence Sam could have two separate SMS credit balance in
his account e.g. 50,000 SMS for Route-1, 20,000 SMS for Route-2. If Sam is an
SMPP client, then there must be two SMPP account associated with Sam, one for
each route. This is obviously not preferred by SMPP clients, they usually want
multiple country support. This is achieved below by dynamic routing.

SMS Routing #1 - Dynamic MCC/MNC based

This routing mechanism uses MCC/MNC pricing tables set by Administrator and
based on the SMS Plans defined for each user, the SMS are routed and billed.
Please take a look at the below structure:

As you can observe, here SMS sender doesn’t need to choose route beforehand.
Route selection is done by the system based on MCC and MNC (Mobile Country
Code and Mobile Network Code) and customer is also billed based on the per SMS
cost set for each MCC/MNC pair. Here both SMPP clients and direct clients can
send SMS without manually selecting country or destination coverage. It will be
taken care by the system.

Distributed architecture for load balancing

Smppcube manages load very effectively however it runs on Nginx and the
availability is limited by server resources. There are many load-balancing solutions
which would work similarly as they work with other web based apps. Another
approach could be to distribute the architecture to one or more different servers.
A popular one is Server #1 (Kannel+PHP Layer), Server #2 (Database) and Server
#3 (Node, Redis & SQLBOX)



Enterprise Plus edition also supports multiple kannel instances. So you can have
two or more kannel installed on the same server or one kannel per server and have
as many kannel instances as you need. Each Kannel instance can have many SMPP
accounts connected. Let me demonstrate the architecture:
Here we can see each server has separate Kannel installed and linked with main
server hosting our master app (PHP/Node). All the routes will be created on the
main app and they can be linked to a maximum of 2 SMPP each, one primary one
backup SMPP. Now each SMPP needs to be linked to a Kannel. So while adding
SMPP, administrator needs to select the Kannel on which he/she wants to bind the
SMPP.

When a client sends SMS, the route selection is done either by straight coverage
rule (explained above) or dynamically by MCC/MNC. Once the route is decided, the
SMS is pushed to the main SMPP associated with the route, which then takes it to
the Kannel on which that SMPP is added. This is another way to divide and
distribute large traffic.

Conclusion

Smppcube Enterprise Plus has flexible architecture and allows telemarketers to use
its component based on their preference. These can be set up on a single server
or multiple server and even divided into clusters depending on your business
needs. A complete access to source code allows for any custom routing logic
implementation. This gives you the freedom to offer a unique experience to your
clients and resellers.