White Paper Corporate SMS System

8/9/2019 White Paper Corporate SMS System

http://slidepdf.com/reader/full/white-paper-corporate-sms-system 1/34

Page 1 of 34

Corporate SMS System

White Paper

1d



Page 2 of 34

Disclaimer

This White Paper is issued for information purposes only. I decline all responsibility for any

errors and any loss or damage deemed to be as a result of the use of the contents of this White

Paper.

Copyright Notification

No part of this document may be reproduced except as authorized by written permission. The

copyright and the foregoing restriction extend to reproduction in all media.



Page 3 of 34

About the Author

William Sengdara is a Lao-Namibian: his mother is Namibian while his father is from Laos. He

was born in Luanda, Angola during Namibia’s independence struggle.

Tertiary education wise, he went through the Information Technology (IT) Certificate as well as

the National Diploma in Information Systems Administration at the Polytechnic of Namibia; it is

there where he discovered his love for programming.

A big thank-you goes out to my Software Engineering Lecturer, Bill Torbitt for introducing Visual Basic 6

at the Polytechnic of Namibia: and the paradigm-shift that went along with this.

William Sengdara

Freelance Custom Software Developer

[email protected]



Page 4 of 34

WHITE PAPER

In this white paper I present how an SMS server can be written for the purpose of utilizing SMS

text messaging as a means of two-way communications between an enterprise and its clients

without the need for a third party.

The SMS system can be extended to interface with an enterprise’s existing data sources so that

very little disruption is caused to any current operations.

It is a considerably much more affordable, maintainable as well as scalable solution: a one-

system solution designed to serve an entire institution.

It should be noted that the COST of sending out SMS text messages is not covered here.

Also, the issue of SHORT CODES, the provision made by the mobile operator to allocate to you,at a cost, a shorter cellular number (4 or 5 digits) instead of, for example, the usual and much

longer 10-digit number, is not covered here either.



Page 5 of 34

ABSTRACT

The SMS service or more popularly known as short text-messaging is a relatively old technology,

yet it remains one of the most effective means of communication that has been offered by the

mobile communications industry. I can say that any person who possesses a mobile phone is

familiar with SMS, has used it to communicate an idea, tell a joke or spam. SMS text messaging

is effectively a much cheaper alternative to making a mobile phone call.

In Namibia, SMS is primarily used by the youth to exchange information, plan dates, or pass on

gossip etc. But SMS is more than the sum of its parts: it is also a tool for easy transmission of

company information. Businesses here in Namibia, provided they have the finances, can

effectively use SMS for, corporate information dissemination, inquiries and even competitions

etc.

SMS Industry in Namibia

We have a small SMS industry here in Namibia: at the moment, a number of entities do exist

with the sole purpose of being the ‘middle-man’ between a business and its wide target

audience: for an agreed-upon fee, they will provide certain SMS capabilities to a company. As

an example, MTC does not deal directly with SMS competitions; they will pass you onto a third

party, an aggregator instead.

The SMS system I present here employs and extends the use of SMS: simple text messaging

used in the context of an enterprise without the need for a third party.



Page 6 of 34

THE AT COMMANDS

The AT commands are used for communications between computer devices (PCs / laptops) and

mobile devices (cellular phones). These commands have been standardized by The European

Telecommunications Standards Institute, ETSI.

AT commands allow for querying mobile device information (cellular model, manufacturer ID

etc), to send as well as receive SMS text messages, connect and disconnect from the internet (if

the mobile device being used has the capability to do so), and much more.

An example, by using AT commands, an application running on a PC can:

1. Send a text message via the mobile device,

2. Read the response from the mobile service provider and

3. Save the results to a database etc.

You can of course test out these AT commands by simply connecting your mobile phone to a

computer or laptop via USB, Infrared or serial port and issuing the appropriate AT commands

using the Microsoft HyperTerminal application. Please refer to the sample images included on

the last pages of the document.

+If able to do so, please do not hesitate to visit the ETSI website to learn more about the AT standard.

The ETSI website: www.etsi.org or e-mail: [email protected]



Page 7 of 34

COMPONENTS OF THE CORPORATE SMS SYSTEM

1. Hardware aspect

Communications Device

For testing purposes, we make use of a Nokia 6020. This model implements the majority

of the AT commands required for the system. As an example, my contact system uses

this model connected to my laptop via USB cable (a Nokia DKU-50) or sometimes

infrared. The reason we do not use this model beyond the testing phase is as the

corporate SMS system is expected to be operational 24/7; this is not feasible as the

model will not work on AC power with the battery removed and is prone to crashing.

Also, the SMS transmission rate is limited.

For the live install, we make use of a USB GSM modem, such as the Huawei E220. This

device is designed specifically for high data transmissions; GPRS or EDGE. In terms of

SMS, it also offers a much higher transmission rate i.e. more SMS text message can be

sent per minute as compared to the mobile phone.

Computing Device

A Personal computer or a Notebook running Windows™, where the SMS system will be

installed and run 24/7, as well as the control applications and their support files.

2. Software aspect

The SMS System core

The Control Center application

Data-access libraries



Page 8 of 34

BASIC SMS SYSTEM ARCHITECTURE (SMSSA)

Diagram 1 © William Sengdara 2008

The white paper will describe an SMS System based roughly on Diagram 1. Please ensure that

the original diagram has been provided with this document.

Please note that the two mobile phones depicted do not represent two devices. They represent only a state:

receiving, and sending. In the actual system, only one USB GSM modem is required.



Page 9 of 34

HOW IT WORKS

Once up and running, the core system is in a permanent loop. In this loop, the system is either

in the state of reading SMS text messages from the USB GSM SIM card or, in the state of

sending out reply SMS text messages read from the database.

1. STATE_SMS_RECV

In this state, the software reads the contents of the USB GSM Modem’s SIM card memory

and if any are present, uses the SMS API to write the SMS text messages to the SMS System

database, into the SMS_RECV table. The SMS text message is immediately deleted from the

USB GSM Modem SIM card memory thereafter. The SMS API can be setup to use rules set

by the system administrators to decide whether the SMS text message is stored in the

database or is discarded. Using this scheme, for example, SMS text messages sent fromnumbers that have been blacklisted will be ignored.

A period of inactivity will follow after the state completes.

2. STATE_SMS_SEND

In this state, the core system will attempt to send SMS text messages read from the

database, specifically the SMS_SEND table. Each department is to have a Notification and

Control Center application installed: it allows a department to view new SMS text messages

destined for that department and reply to them. Sending out these Reply SMS textmessages involves a First-In-First-Out-Unless-Critical (FIFO-UC) algorithm: the system gives

priority to critical SMS text messages. In this way, higher-priority messages will be sent out

first before other messages.

A period of inactivity will follow after the state completes.

Where possible, a server machine maybe allocated specifically for the task of text messaging,the SMS server.



Page 10 of 34

The process of receiving an SMS text message

The SMS system core is permanently running on the server machine. Once an SMS text

message is received in the USB GSM modem SIM memory, using the SMS API, it will be parsed

into the constituent parts before being stored in the SMS_RECV table in the SMS_RECV

database. It is then deleted from the USB GSM modem SIM card memory.

The constituent parts of an SMS text message are thus, but not limited to:

1. Sender number

2. Date and time text message received

3. Department name

4. Critical level flag

5. Number_Of_Send_Attempts counter (only applicable during STATE_SMS_SEND)

6. The text message

The SMS API will add or ignore the entry of an SMS into the SMS_RECV queue based on certain

rules as set by the SMS system administrators beforehand. These rules are for example, but are

not limited to:

1. Where the sender already sent an SMS text message and the reply to that text message

is still pending, unless the new message is flagged as critical, the SMS text message is

not added to the queue. The SMS API method used to query if the sender has text

messages pending is isMessagePending() which expects a CSMSentry object and returns

a boolean value: TRUE or FALSE.2. Where the sender already sent an SMS text message and the reply to that text message

is still pending, before the time difference allowed to a client has been reached, unless

the new message is flagged as critical, the SMS text message is not added to the queue.

The SMS API method used to query if the sender’s timeout limit has been satisfied is

timeOutExpired() which expects a CSMSentry object and returns a boolean value: TRUE

or FALSE

3. Where the sender already sent an SMS text message and the reply to that text message

is still pending, if the message is intended for the same department, unless the new

message is flagged as critical, the SMS text message is not added to the queue.

It should be noted that using rules will of course incur some overhead. Thus, if the majority of

the processing being done turns out to be the validation of rules, then you might be better off

not implementing them at all during SMS receive.



Page 11 of 34

Receiving an SMS text message

Adding an SMS text message to the SMS_RECV table (or queue) is accomplished with a call to

the SMS API function appendToQueue() which expects a CSMSentries object. The CSMSentries

object is a collection of all newly received SMS text messages (a text message is a CSMSentry

object) during a STATE_SMS_RECEIVE session, as returned by a call to the function parseSMS().

By using a CSMSentries parameter, instead of a single CSMSentry, one needs only to make one

‘trip’ to the database (using the CDatabase library) to enter all the SMS text messages received,

as opposed to a trip for each text message, as the database should be kept open for as short a

time period as possible, due to the heavy traffic we would expect if we have many departments

being covered.

An SMS entry in the database requires a unique ID as a primary key has been set in the table.

Also, we have an appendToQueue() function whcih would expect an enum parameter as well:

to indicate where to write the message (the method appendToQueue() is multipurpose, it is

also used to write messages to the SMS_SEND and SMS_SENT queue): these enums would then

be:

SMS_RECV

SMS_SEND

SMS_SENT

The call would then append the new text messages to the SMS_RECV table of the core systemdatabase.

A sample layout for each of these three tables will now be provided.



Page 12 of 34

Database table: SMS_RECV

The SMS_RECV table of the core system database is used to store all text messages that have

been received. It is up to the Control Center applications to query for new text messages that

are intended for them and to remove them from this table thereafter. Unclaimed text messages

should be deleted either automatically or manually, after a certain period has elapsed. This will

ensure that the table does not bloat.

Field Type Size Primary Key AutoNumber

EntryID Text 255 True True

SenderNumber Text 255

DateReceived String -

Department Text 255

Critical Boolean -

Message Text 160



Page 13 of 34

Database table: SMS_SEND

The SMS_SEND table of the core system database is used to store all text messages that are

waiting to be sent out. These messages can be cancelled by a call to the method

cancelMessage(), which would expect a CSMSentry object.

Note that cancelling a message is only possible If the message is not yet flagged as being in

STATE_SMS_SEND. Flagging is done by the call getSendQueue(), as called from

STATE_SMS_SEND, with the CSMSEntry flag SMS_SEND_PENDING set to True (Setting this flag

to True is only applicable to and during this stage).

After sending, messages are moved to the SMS_SENT table. Rules should be setup to determine

how many times (if more than once) a text message should be sent and if cannot be delivered,

before it has to be abandoned and moved to the SMS_SENT table.

Field Type Size Primary

Key

AutoNumber


SenderNumber Text 255

DateAddedToQueue Date -

Department Text 255

Critical Boolean -

Counter_SendAttempts Text 255

Buffer_ReasonsForFailure Text 255Flag_SendPending Boolean -

Message Text 160



Page 14 of 34

Database table: SMS_SENT

The SMS_SENT table of the core system database is used to store all text messages that have

been sent out. Failure is indicated. It is up to the Control Center applications to query for new

text messages that are intended for them only.

An archiving scheme maybe built into the SMS Server so that messages are removed

automatically after a certain period has elapsed to ensure the tables do not bloat.

Field Type Size Primary

Key

AutoNumber


RecipientNumber Text 255

DateAddedToQueue Date -

Department Text 255

Critical Boolean -

Counter_SendAttempts Text 255

Buffer_ReasonsForFailure Text 255

Message Text 255



Page 15 of 34

Concatenated text messages issue

Please be aware of the issue of concatenated SMS text messages: where the same message is

split up into two or more parts as it is too long and each part sent by the mobile operator as a

separate message. The system should be configured to deal with such scenarios as unlike on

the mobile phone; the message is not automatically recombined.

Concatenated messages are arranged in the following manner

Part 3 x@‘ great time. Goodbye.

Part 2 x@ See you all in June and have a

Part 1 x Dear friends, I will be leaving soon.

The x is a random character.

Another much simpler solution is to encourage clients to ensure they do not send extremely

long messages: i.e. typing more characters than are required. A minimum of 160 characters

should be sufficient. Clients should be sufficiently aware of your SMS query scheme

beforehand.



Page 16 of 34

The process of sending out a Reply SMS text message

During STATE_SMS_SEND text messages to be sent out are read from the SMS_SEND table of

the core database. The maximum number of text messages that are allowed per SMS_SEND

session is exactly 5 (five). The SMS_SEND_PENDING flag for each of these SMS text message isthen set to TRUE in the SMS_SEND table of the core database. This is required so that

Notification and Control Center applications doing polling can display the total number of

pending SMS text messages and their details.

The constituent parts of an SMS text message are thus, but not limited to:

1. Sender number

2. Date and time text message received

3. Department name

4. Critical level flag

5. SMS_SEND_PENDING flag

6. Number_Of_Send_Attempts counter (only applicable during STATE_SMS_SEND)

7. Reason_For_Failure (only applicable during STATE_SMS_SEND)

8. The message

Sending out a reply SMS text message is also governed by rules set by the system

administrators beforehand. These rules are for example, but are not limited to:

1. Text messages that are flagged as critical are sent out before text messages that do no have

this flag set.

2. For every send attempt for each SMS text message in SMS_SEND queue, the

Number_Of_Send_Attempts counter for that text message is incremented. When the

counter equals to MAX_SEND_ATTEMPTS_BEFORE_DISCARD as set by the system

administrators beforehand, the text messages is permanently discarded. By default

MAX_SEND_ATTEMPTS_BEFORE_DISCARD is 1 (one).

Once the text message is sent out or discarded it is then moved to the SMS_SENT table in the

core system database. The Notification and Control Center applications doing polling can thendisplay the total number of SMS text messages sent as well as whether they were successfully

sent or discarded.



Page 17 of 34

In the STATE_SMS_SEND, a call is made to the function getSendQueue() which expects a

CSMSentries object. The call fills and returns that same object with a maximum of only 5

CSMSentry objects, provided that the SMS_SEND queue is not empty. The

SMS_SEND_PENDING flag of each CSMSentry is set to TRUE for the Notification and Control

Center applications that are polling to correctly reflect which SMS text messages are currentlybeing sent out.

These SMS text messages cannot be cancelled or deleted. Once sent successfully, the SMS text

message is added to the SMS_SENT table of the core system database for polling applications.

The counter Number_Of_Send_Attempts for that text message is set to 1 by default. If for any

reason, the text message could not be sent, the counter Number_Of_Send_Attempts is

incremented for each attempt. The Reason_For_Failure member for that text message is

updated with a concatenation of all errors received from the USB GSM modem.



Page 18 of 34

Databases and SMS storage

SMS text messages that have been received and those that are queued to be sent out are

stored in password-protected Microsoft Access databases. This is the default database format

used by the core system. It is sufficient and tested to work 100 percent fully with the core

system. A much better alternative would be MySQL Server.

Direct SQL statements and stored procedures are used to retrieve, update, add and delete data

from the relevant tables.

It should be noted that the SMS API encapsulates completely the data-access logic for the core

system.



Page 19 of 34

Databases and their tables

Application Database Tables

SMS System core SMS_Year*.mdb SMS_SEND

- SMS_RECV

Tables would be created as required. We would now require a Database library. It would have a

CDatabase class. This class allows for database creation, table creation and data manipulation.

Possible methods exposed by this class would then be:

createDatabase()

createTable()

tableExists()

appendToQueue()

removeFromQueue()



Page 20 of 34

The SMS Control Center

The Control Center

The Control Center is run as required. It is used to, but not limited to:

1. VIEW received SMS text messages applicable to the department it is being run from,

2. REPLY to SMS text messages ,

3. VIEW the SMS_SEND_QUEUE

4. DELETE/CANCEL SMS text messages from the SMS_SEND_QUEUE

5. CONFIGURATION of data access



Page 21 of 34

SMS Handler

The functionality of the SMS system is extended by SMS handlers. SMS handlers are

applications or scripts that the SMS Server executes each time a new SMS is received.

A SQL trigger in MS SQL Server or MySQL may also be created to do the job of an externalapplication.

One use of an SMS handler is auto-response to all messages received after a certain time.



Page 22 of 34

Understanding the white paper via case studies

To make things easier for you to understand, I have decided to use the scheme of case studies.

Using this approach, I will explain the basic system design, and most of the processes involved

by using fictitious companies. You may then, the interested reader, be able to possibly extend

the concepts presented yourself.



Page 23 of 34

Case Study 1

Institution ID DOCS Ltd

Type Identity Documents

Client base UnlimitedDepartments 1

Dedicated server machine False

In this scenario, ID DOCS Ltd decides to purchase and install the corporate SMS system. The

system comes with a USB GSM modem and its software. The core system is installed on the

machine where the identity documents system is also installed. As this machine has enough

memory and enough processing power, it can be used for other purposes without adversely

affecting the operation of the SMS System.

The Notification and Control Center applications are also installed on this machine.

Sample Scenario

William has made an ID application. Some weeks have passed. He now needs to know whether

the document is ready so that he can go and pick it up. He sends an SMS text message. The SMS

text message may look like this:

The department the request is destined for

The reference number assigned by the ID department

“ID R8019202”

In our sample setup, once an ID is ready to be picked up, the assistants will flag this state in the

identity documents system. As the SMS system is setup to interface with the identity

documents system, it will issue a search for an entry matching the entry specified in the text

message without the need for user-intervention.

The interfacing process may make use of a VB script file. If the entry is found, only then will a

reply be sent out to the requesting number.

In this scenario, the cost of sending out a reply SMS text message is covered by using the free

SMS period offered by the mobile service provider, when applicable.



Page 24 of 34

Case Study 2

Institution Subjects Improved

Type Subject-improvement institution

Client base 2000 peopleDepartments 4

Department1 code FIN

Department2 code MNG

Department3 code EXAM

Department4 code IT

Dedicated server machine True

In this scenario, Subjects Improved purchases and installs the corporate SMS system. The coresystem is installed on a machine specifically dedicated to handling SMS text messaging. This

machine is referred to as the server machine. This machine is never used for anything which is

processor/memory-intensive; as such activities are certain to adversely affect the operation of

the SMS System.

The Notification and Control Center applications are installed on the ‘normal’ machines or

laptops in the business. In our scenario, they are installed on the four machines of the four

departments.

These four departments are

1) The Finance Department which is assigned the code FIN by the SMS system administrators

2) The Management Department which is assigned the code MNG

3) The Exams Department which is assigned the code EXAM

4) The Information Technology Department which is assigned the code IT



Page 25 of 34

Sample Scenario

David is a student at our sample institution. He is now on holiday in Oshakati and needs to

know his exam results. He sends an SMS text message request for the results. The SMS text

message may look like this:

The department the request is aimed at

The student Id the password assigned to the student for authentication

“EXAM uid=200209604 pwd=xxxx”

David might also send out another SMS text message to the Finance Department requesting

how much the institution might be expecting of him financially. The SMS text message may look

like this:

“FIN uid=200209604 pwd=xxxx”

Back in Windhoek, once the SMS text message is received, it will be added to the SMS_RECV

queue. The SMS text message is split up into the constituent parts which are the sender

number, the date and time it was received, the department name, the critical level (if

applicable) and finally the actual text message with the flags removed.

The Notification application running on the EXAM department computer will continuously

query the SMS_RECV queue and if any messages exist and are intended for that department, it

will notify that department of the message and the person available can look up the exam

results of that student, validate that the password supplied matches the stored password and

then post a reply. Unless the reply text message is flagged as being critical, it will not be sent

out immediately.

The system can be set up to respond automatically to certain queries by using VB script files.

This will remove the need for having a person present and posting out replies.

In this scenario, we encountered the issue of authentication: the process of proving to the

system that you have been granted the right to use a particular resource. This usually involves

you providing a password which has been associated beforehand with your account. We shall

now an authentication scheme for use with the SMS System. This method shall be simple to

implement as well as have as little overhead as possible.



Page 26 of 34

Basic authentication

The process of authentication will require that a certain keyword in the text message be

regarded as being part of the password parameter. In this scenario, the keyword used is:

pwd

The format for the authentication is thus:

pwd=#3#56

The password is then whatever text is provided after the equal-to sign, which in this case is

#3#56. The parameter parser class, CParamParser, will strip out white spaces where required.

The constituent parts of an SMS text message will now also include the members

UserIDPassword

These parameters will now be available for use wherever authentication is required.



Page 27 of 34

Authentication in-depth

The authentication process will require that a department-specific authentication table be

created where required, beforehand. This table will contain the list of users, their

corresponding passwords and if required, access right assignments also.

Sample Basic authentication table (BAT) structure

Field Type

UserID Text

Password Text

An example of using the Basic Authentication Table would then look like this:

UserID Password

200209604 #3h4rg

IT Afvdt

JAMES G4hems

Where user right assignments are required, there would instead be an extended table.

Sample Extended Authentication Table (BATEX) structure

Field Type

UserID TextPassword Text

ParameterName String

ParameterValue Boolean

An example of using the Extended Authentication Table scheme would then look like this:

UserID Password ParameterName ParameterValue

200209604 #3h4rg CanQuery True

200209604 #3h4rg CanDelete FalseIT Afvdt CanQuery True

IT Afvdt CanDelete True

JAMES G4hems CanQuery False

JAMES G4hems CanDelete True



Page 28 of 34

Authentication Library

Authentication requires the creation of a separate Authentication library. It has a CAuthenticate

class. A method that might be exposed by this class would be:

authenticateUser()

This method might expect a CSMSentry object and should return a Boolean TRUE or FALSE. This

method should in turn make a call on the CDatabase library to return an Authentication

recordset object as required and attempt to find a match for the user id, the password and any

other properties parsed from the SMS text message beforehand. Where a recordset object is

being returned, you might want to implement a lookup table to reduce traffic: if the majority of

authentication requests are being made to a particular database, records from that particular

table can be cached to speed things up.



Page 29 of 34

Case Study 3

Institution Corporate advertising

Type SMS advertising

Client base UnlimitedDepartments 1

Dedicated server machine False

In this scenario, Corporate advertising decides to purchase and install the corporate SMS

system. The system comes with a USB GSM modem and its software. The core system is

installed on the server machine. The job of this enterprise is to send out the latest prices for

particular products at different stores. Stores submit these prices via e-mail.

Corporate advertising has a MySQL Server database installed. The database has tables with themessages submitted by clients as well a schedule for when the advertising should be sent out.

Another table contains mobile phone numbers to which the text messages are sent.

They require an automatic system. This will require that the function getSendQueue() be

configured to only return a CSMSentries object containing CSMSentry entries where each

SendTime parameter matches the time as setup by the SMS System administrators beforehand.

Sample Scenario

In this scenario, the text message is sent out indiscriminately to all the mobile numbers in the

Mobile Numbers table. Recipients can either accept receiving these text messages or refuse

them. A text message requesting a Yes or No is sent out beforehand. The response is either a

Yes or No.

The response will mean that the mobile number is removed from the Mobile Numbers table so

that no more advertising is sent out to it.



Page 30 of 34

Support images

Image 1 Testing AT commands via Microsoft ® HyperTerminal (COM connection). The mobile

handset in use is a Nokia 6020 connected to a Dell Latitude D600 laptop running Windows XP

SP3. The cable used is a Nokia DKU-50, purchased at a cellular accessory outlet for N$ 150.00.



Page 31 of 34

Image 2 Using the initial one-way SMS Send functionality used in Contact system. The mobile

phone being used is a Nokia 6020 connected via Infrared connection to a Dell Latitude D600

laptop running Windows XP SP3.



Page 32 of 34

Image 3 Reading SMS text messages from SIM memory using COM connection. The mobilehandset in use is a Nokia 6020 connected to a Dell Latitude D600 laptop running Windows XP

SP3 via Nokia DKU-50 cable.



Page 33 of 34

Image 4: Reading from the phonebook (COM connection). The mobile handset in use is a Nokia

6020 connected to a Dell Latitude D600 laptop running Windows XP SP3. The cable used is a

Nokia DKU-50.



Image 5: This is the SMS Server running on Windows XP SP 3. It is what connects directly to the

USB GSM modem and inserts new text messages into SMS_RECV table of the SMS database. It

also sends out all the text messages read from the SMS_SEND table.

Image 6: This is the SMS control center. It allows text messages to be queued into SMS_SEND

table. It also allows for reading messages from SMS_RECV, SMS_PEND and SMS_SENT.