Islamic SIM application server

Islamic SIM Card
Application Server v1.40
Aug. 20th 2011
by
Yiannis Hatzopoulos
Technical Architect
Xyrkadia – excellence in tech
1

Architecture
The Islamic SIM Card Application Server (aka ISCAS) is a modular and scalable
application server bundle, consisting of the following components; the basic components
of which are based on open source software.
Linux OS distribution (OpenSuse, Ubuntu etc)
PostgreSQL 8 SQL server or MySQL 5.5 (user selectable)
Up to date Java JDK installation
Apache Tomcat 6 web server
Multiple (1...n) Islamic SIM Card application Boxes (ISCBOX)
Http/SMPP connectivity layer to an MNO's SMSC
Http connectivity to 3rd
Party CellID search engine (optional)
The components described can be residing inside one multi-core physical server, or
placed inside multiple physical or virtual processing machines in the data-center to
maximize the processing throughput, and make use of idle time of other machines to
minimize the deployed hardware cost.
The connection between the modules is executed using Internet protocol (IP) socket
connections and http; which makes it possible to connect the modules in a fault tolerant
manner, and get them operating inside or even outside the data-center in any possible
configuration.
The reader should note that this software is based on industry standards, and robust open
source tools; which guarantee reliability, good performance and low operation cost, even
on low spec server hardware.
The general architecture can be visualized in the following manner
2

The flow? Time after time, the request flow stems from the mobile phone. The user picks
the Islamic SIM applet on his handset, selects something from the applet menu and
submits his request.
This selection can generate an SMS message, which is picked by the operator's SMSC
and sent to the ISCAS tomcat web server for processing. Apache Tomcat parses the
incoming SMS and delegates it to an available ISCBOX under his controlled network. The
ISCBOX executes the math that the Islamic SIM mandates and sends back a response to
the mobile phone using either SMS or MMS, through the operator's SMSC or MMSC.
MNO billing and auditing is transparently integrated into the mix, based on the SMS flow
that is either received or generated.
How to figure out the optimal configuration?
As you can see, the modules that support the ISCAS function are flexible. The
administrator can get them working either inside or outside the data-center, in disparate
geographic locations, redirect internal flow, since it is all based on Internet protocol;
receive automated load balancing -- and in case of faults (power shortages, crashes etc),
automatically get the request flow redirected to the healthy part of the installation.
3

So what are the critical numbers to think when setting up this system?
The one Million user question
Let's assume that we have a population of 1 million users sporting the latest Islamic SIM
applet on their phones. This applet delivers either on demand (high priority) requests; e.g. I
want to know my praying schedule for my current location now! -- I do not want to wait
more than 20 secs!! – or M2M daemon-like services working in the background on the
SIM (low priority).
The figures shown are experimental ones and actual results depend on deployed
hardware.
The ISC admin should expect an average throughput of around 80-100 requests per
second per processor used, depending on hardware.
That means that if the server avails 4 processors, the request throughput should be
around 300+ requests / sec or around 19,000 requests/min. High spec fast servers yield
significantly higher throughput.
Consequently, If we use 2 servers of 4 cores each, the throughput doubles. SMSC
capacity must be adjusted accordingly. Now let's get back to our 1 million users scenario
and let's see how this throughput translates into business terms.
M2M SIM generated low priority requests really require nothing more than 1 SMS
submission from the server to the phone once a week, so they have little impact on the
overall system performance.
Let's assume that 30% of our users have adopted our subscription based services, which
utilize low priority M2M communication. This generates a steady demand flow of 300.000
SMS messages that have to be delivered to the phones once a week, or 42.857 SMS/day;
this translates to just over 29 messages/min. This is low priority stuff, runs transparently
24hrs/day and is evenly spread within the 24hr timeslot.
Let's assume that we have a mid-range server at our disposal, with a fast Hard Disk, 8
Gbytes of RAM, a decent SQL server, 4 processors and a fast connection to a wide
capacity SMSC. We should expect around 300+ requests processed per second, or 18000
requests/minute to pass through the system.
Of those messages, 29 SMS/minute are allocated to serve our subscriber user-base SMS
traffic, which leaves around 17971 messages/minute open to serve on-demand traffic.
What does this translate to?
It all comes down to the statistical behavior of the non-subscription user base. Out of the
700.000 non-subscription users, probably 30% (and a portion of our subscription base...) –
or around 210.000 wake up in the morning and decide to give a check on this day's or next
4

day's praying schedule on their phone. Let's assume that half of them do this within 3
hours between 06.00 – 09.00 in the morning. So this means that 105.000 SMS requests
are sent within 180 mins, leading to an average of 583 requests/min hitting the server.
Good news! Our average allocated capacity of 17971 messages/min is more than
adequate to get the traffic serviced within 30 secs or less of arrival.
What happens when or if statistics are miscalculated and demand outgrows capacity? Still
we can cope. All requests are buffered in an SQL server, and nothing is lost on its way to
the processing board. The service queues may grow and last longer to process, but
service is delivered no matter the load. Nevertheless, we all know that the user does not
want to wait! So what can the admin do to improve the situation?
The answer is simple! Simply start more processing boxes in other machines; declare
them in Tomcat web server -- the load will be evenly distributed, and the processing
queues will be made shorter.
So, what is the best recipe on setting up your servers?
Hint
Start by getting your figures right on the SMSC channel first, then do the math on the
appropriate server resources. Start small, follow your traffic and gradually grow! Since the
user population is dynamic, with people adopting the service, some leaving it to use new
smartphones; or using more of it, the demand is expected to fluctuate as well. Processing
capacity can be added to the system or even removed with in a few minutes.
Is there accurate statistical information or server metrics to consider?
This is a newly introduced service, and the statistical behavior of the user base is hard to
predict.
As far as hardware performance is concerned, since the metrics are influenced by the
actual hardware specs, and the SMSC channel bandwidth deployed, some stress testing
simulation on the deployment machines is the safest way to go; and yes the software
benchmarking tools to do so can be made available.
So if we are talking for going from 1mil to 2 mil... 10 mil users, we must simply multiply the
figures accordingly; and bring in more processing power to the system, taking into
consideration the peak demand that is expected of the service, the available SMS channel
throughput and the median response time the users might be content with.
Based on experimental data, one should expect that around 1,000,000 user pool can be
serviced with in a median 20 sec waiting period per available server processor. Metrics
improve as the hardware speed and resources increase.
5

Installation: the Linux way
Hint
The initial installation of this server can be executed using linux remote desktop, with
assistance by the ISCAS support. The following notes are meant for troubleshooting and
extending the installation to new machines if needed.
Do a preferably clean installation of an up-to-date linux distribution on your server. Likely
candidates are OpenSuse, Ubuntu etc. Disable automated updates to the system. Note
that test work on this system has been done using Ubuntu 10.04 LTS.02. If you feel
content with this distro, by all means use it.
You will receive by the ISCAS support a zipped folder containing a tree a files. Extract at
the folder of your preference; All the support files you need can be found there. Lets
assume you extract this at /home/<username>/ISCDistribution
Also create the following folders
/home/<username>/ISC
/home/<username>/ISC/Images
/home/<username>/ISCLog
Use your designated package manager to download and install
Latest Java JDK (recommended and tested on Open-JDK)
Latest Apache Tomcat 6 (recommended installation path for tomcat /usr/local/tomcat )
PostgreSQL 8 or MySQL 5.5 (user selectable)
pgAdminIII for PostgreSQL 8 or MySQL Administrator based on used SQL server
Your Apache Tomcat Configuration
User rights for the ISCAS web service are registered in the file tomcat-users.xml
found in the suggested installation path at /usr/local/tomcat/conf folder.
The access model follows the industry standard 'Memory Realm' for Tomcat, using basic
user authentication.
6

Tomcat Login Names and Passwords
At the <tomcat-users> section of tomcat-users.xml define two additional roles
<role rolename="ISCAdmin"/>
<role rolename="ISCGuest"/>
Define a login name and password for the Tomcat administrator
<user password="adminpassword" roles="admin,manager" username="tomcatadmin"/>
and related passwords and login names (as many as are necessary) for ISCAdmin and
ISCGuest roles.
Please note that ISCadmin login names MUST contain the word 'admin' in the username
field.
<user username="iscadmin" password="iscadminpassword" roles="ISCAdmin"/>
….
<user username="iscguest1" password="iscguestpassword" roles="ISCGuest"/>
…
<user username="iscguestn" password="iscguestpassword" roles="ISCGuest"/>
The ISCAS tomcat server has been configured to use http port 8080 on the localhost. If
you need external access to the web server – the appropriate setting MUST be introduced
to your router to map incoming traffic to the appropriate internal port.
At path /usr/local/tomcat/webapps/ROOT you must extract CONTROL.zip which contains
the html files that serve as the web console to the system.
Details on this web application will be presented later on in this document...
To start the Tomcat Web server, open a terminal and enter
$ cd /usr/local/tomcat/bin
$ sh startup.sh
To end Tomcat
$ cd /usr/local/tomcat/bin
$ sh shutdown.sh
Next step is to install the Web servlet which powers Tomcat.
Open your browser and point to http://localhost:8080/
Login in as tomcat manager and select for deployment file ISCWeb.war found in
/home/<username>/ISCDistribution
7

Now, when you point your browser to http://localhost:8080/ISCWeb
you should be seeing “ISLAMIC SIM Web Server”
The URL to control the ISCAS server over the web is accessible at
http://<YourWebserverIP>:8080/Control/ISC.html
or on localhost at
http://localhost:8080/Control/ISC.html
You should be seeing the ISCAS web console
8

If all this is OK – the web application segment of the server has been setup OK.
SQL Server Configuration
The SQL server that powers ISCAS can be either PostgreSQL 8 or MySQL 5.5
I will not commend on the installation process. Installation is executed quite easily through
your linux package manager.
You must setup a password and admin login name for the SQL server using your
command line.
Details can be found on the web. The machine in which the SQL Server resides can be
shared to any other module of the ISCAS, or a separate machine can be used as SQL
server if additional processing power is requested.
Using pgAdminIII, which is a GUI control tool for PostgreSQL, you can control your SQL
server, check its performance etc.
Similar procedure allows the installation of MySQL and MySQL administrator.
Next, you must create a database schema called ISC_DATABASES and execute the SQL
Script contained in the file CreateTablePostGreSQL.txt (or CreateTableMySQL.txt)
These SQL tables serve to store CellID repositories and serve as the SMS incoming
request buffer to the system. The systems checks its CellID database to map CellID data
into approximate GPS location. The operator's own CellID tower lists will go into this
Database, as well as third party data CellID data, like OpenCellID. If the desired SMS
throughput is modest (<80 SMS/sec), the system can be configured to use memory
buffering, instead of SQL buffering. Contact ISCAS support for details.
The Processing BOX launch
9

The term BOX in ISCAS terminology is used to described a Socket Server application,
which packs all the Math processing functionality that backs the ISCAS system. ISCAS
uses 1..n BOXes.
Each BOX is a java socket server application, which waits for socket connections in a
specific port.
The default listening port is 4444; port 4445 is reserved for debug tracing; any other value
port value higher than 4445 is acceptable.
To start a new box
open a terminal, go to the folder where ISC_SocketServer.jar is found (…/dist)
enter
java -jar "ISC_SocketServer.jar" (for default port 4444)
To listen to a specific port
java -jar "ISC_SocketServer.jar" <portno>
You will see something like this on your terminal
Host ID set at 4444
User home @:/home/yiannis
MEMORY REQUEST BUFFER
Restricted No of Worker Threads...
RUNNING THREAD......
3rd party Web Cellid Search disabled
Local SQL DB Cellid Search disabled
Web SQL DB Cellid Search disabled
------------------------------------------------------------
RUNNING THREAD......
3rd party Web Cellid Search disabled
Local SQL DB Cellid Search disabled
Web SQL DB Cellid Search disabled
------------------------------------------------------------
Starting Islamic SIM Card Socket Server.
Waiting at IP : port 4444
----------------------------------------------------------------
Version 1.39 - April 8 2011
This delivers some basic information on the active processing threads (In this case, I have
set it up to use 2/8 which are supported per box), the request buffering options MEM/DB,
the CellID search options I requested etc).
Hint
If you need to run or more ISCBOXes on the same machine, they have to listen to
different ports!
10

Note that each processing Box uses a maximum of 10 concurrent connections
to your SQL server.
How to control Boxes from the Command line?
You can control a box individually using a telnet connection to their IP:port
e.g.
telnet localhost 4444
You will see
yiannis@yiannis-desktop:~$ telnet localhost 4444
Trying ::1...
Connected to localhost.localdomain.
Escape character is '^]'.
Connected>
help
HELP ---> This command help list
NEW_PARAMS --> Update SMSC Hosts + Web CellID access URL
NEW_LISTS ---> Update MCC / DST / Timezone lists
SETUP_DB --> Create SQL server tables
LICENSE_INFO --> Get remaining license time
CELLID_DB_ADD;filename.txt --->Adds records to cellID lookup table
GET_ID ---> Request runID to renew license
NEW_LICENSE ---> to apply new license.
STATS ---> Get usage summary
SHOW_DAILY_LOG ---> Get daily activity summary
END_BOX ---> Stops this socket server safely
PAUSE_BOX ---> Stops processing new requests
RESUME_BOX ---> Resumes processing new requests
SMSC_HOSTS ---> Registered SMSC Hosts for sending SMS messages
SYSTEM_INFO ---> Get system load information
----------------------------------------------------------------
ENDRESPONSE
Each ISCBOX can be controlled by telneting to its IP -port and submitting typed text
commands. 'Help' displays the available commands.
Getting the initial license lease on each ISCBox is efficiently done using your telnet
connection.
The current license is projected by entering LICENSE_INFO on your telnet terminal.
11

You will receive the remaining operation time in days.
To renew your license enter GET_ID which yields the Run ID of this BOX.
Send the Byte sequence you will receive to the ISCAS Support, and you will receive a
license certificate which will be imported to the system by using the command
NEW_LICENCE;<CertificateString>
You can verify if the certificate has cleared, by entering LICENSE_INFO.
A license certificate can be used only once for the specific BOX.
There is a very important command which can only be executed by a telnet
connection,
and that is physically ending the BOX in a safe way.
This is done by typing the command END_BOX.
All other commands, although command line driven, are much more easily executed over
the web console as will be explained later on.
Although everything in ISCAS runs fine using just one ISCBOX, it is recommended to
launch a minimum of 2 boxes, either residing in one physical server or more. Thus the load
can be shared evenly; it is simply an easy step to stop a box, end it safely, upgrade its
software if needed and restart it again, while the next one is routed all traffic; so the
service never has to come down this way and runs 24/7.
If more than one physical servers are available, the same concept applies, since it
increases the system's redundancy and throughput. Having 2+ servers in different
locations further increases the fault tolerance of the setup (power shortages etc).
Files /Folders and settings
The ISCAS uses 2 folders /home/<username>/ISC and /home/<username>/ISCLog
The first one houses the configuration files that control its operation and the second one
the logs that are generated during its operation.
Lets examine the most important setup files...
/home/<username>/ISC/DBParameters.txt
we see its typical content:
DBCLASSNAME;org.postgresql.Driver;4444
DBCONNECTION;jdbc:postgresql://localhost:5432/ISC_DATABASES;4444
12

DBUSER;postgres;4444
DBPASSWORD;password;4444
DBADMINEMAIL;xxx@gmail.com
You can see a series of field attributes and related values:
DBADMINEMAIL is the DB admin's email address. An email is sent automatically in case
the DB server declares a fault state.
DBCLASSNAME is the JDBC classname used to connect to the SQL server, in this case
org.postgresql.Driver and 4444 is the port of the Box that will use this connection.
DBCONNECTION is the URL-link that the SQL server exposes, in our case
jdbc:postgresql://localhost:5432/ISC_DATABASES and 4444 is the Box port that will use
this link.
DBUSER and DBPASSWORD responds to the authentication credentials that must be
presented to the SQL server.
If more boxes share the same SQL server, a new entry must be included in this file marked
with the respective BOX port number. If a port number 0 is used, all BOXes that have
access to the specific /home/<username>/ISC folder regardless of port will use the specific
attribute value.
DBCLASSNAME;org.postgresql.Driver;0
/home/<username>/ISC/MCCCountrycodes.txt
This file contains a list of Mobile country codes, the capital city, its GPS coordinate and the
DST (daylight saving time) dates that are known to be applicable for the next 2 years.
This file will be periodically updated and integrated to the ISCAS system, without stopping
the server.
/home/<username>/ISC/RunParameters.txt
OPERATOR_WEB_CELLID_SEARCH_BASEURL;http://localhost:8080/ISCWebCell/CellR
eq?CellID=
SMSCLINK;0;http://localhost:13013/cgi-bin/sendsms?;yiannis;test;123456
SMSCLINK;512;http://localhost:13014/cgi-bin/sendsms?;babalid;iscdemo;0012345678
SMSCLINK;513;http://localhost:13014/cgi-bin/sendsms?;yiannis;test;123456
SMSCLINK;514;http://localhost:13013/cgi-bin/sendsms?;binary;content;+123457899
This file contains the URL for accessing a user defined Web CelliD search server, and the
SMSC URL links that the system uses; including locale,username, password and SMSC
Mobile service number. Changes to these attributes can be made without stopping the
server, using the web console. As similar MMSCLINK will be integrated into the system
soon.
/home/<username>/ISC/Webserviceparams.txt
LOG;OFF
CATALINASTORE;/usr/local/tomcat/webapps/ROOT/Control
13

SOCKET_SERVER;127.0.0.1;4444
SOCKET_SERVER;127.0.0.1;4446
ALLOWED_IP;127.0.0.1
EMAILNOTIFY;yxh@otenet.gr
LOG on or off sets the web server log state; log data is written in
/home/<username>/ISCLog.
CATALINASTORE is the path to tomcat's base URL for web accessible files.
SOCKET_SERVER;<IP>;<port> declares the listening properties of each ISCAS Box. If
new ones are needed, they can be introduced from the web console without stopping the
server.
ALLOWED_IP declares incoming SMS commands from accepted IP sources. More than
one entries can be included. Changes to this attribute can also be executed using the web
console.
EMAILNOTIFY is the email address used by the Server, to send an automated email
notification in case a malfunction is detected (eg a Box being rendered unreachable etc).
This address can also be changed from the web console.
/home/<username>/ISC/Tzlist.txt
Contains a net of known GPS coordinates (major world cities) and their time zones. Used
to track the Mobile user's current timezone if it is not reported from the mobile network.
/home/<username>/ISCLog
In this folder, 2 files are generated and stored: BoxErrorLog.txt and ISCWeblog.txt.
One contains information on incoming SMS messages that failed to be parsed by ISCAS
and the other detailed web activity log, which can be turned on/off.
Web console
ISCAS avails a web console tool, that the admin can use to administer basic operation
properties; and guests can use to receive information on the processing load that have
been served and led to billing charges to the end users.
How to start it?
Point your URL to http://<YourWebIP>:8080/Control/ISC.html
14

You have to login into the system to gain access.
The first selection is “Reports”, which is accessible to both ISCAdmins and ISCGuests
roles.
Reports
There are two kind of reports available. One is the Usage report summary and the other
the Daily user log.
SMS Summary report
This yields something like this....
Right click to Download as .CSV file
----------------------------------------------------------------
GLOBAL SYSTEM REPORT -- Wed Apr 13 09:03:37 EEST 2011
Total count of incoming SMS requests for the whole system, 0
15

Average SMS throughput/min for the whole system, 0.0
SMS throughput in the last 30 mins, 0.0
--->Total count SMS MECCA_DIR_TEXT, 0
--->Total count SMS MECCA_DIR_GRAPHIC, 0
--->Total count SMS PRAYER_SCHEDULER, 0
--->Total count SMS UPDATE_LOCATION, 0
--->Total count SMS PRAYER_TIMES_AT_DATE, 0
--->Total count SMS CALENDAR_UTILS, 0
----------------------------------------------------------------
Response from BOX0
----------------------------------------------------------------
Wed Apr 13 09:03:37 EEST 2011
BOX Total count of SMS messages processed, 0
BOX Total count of failed SMS messages, 0
BOX Average SMS throughput per minute, 0.0
BOX incoming SMS message count in the last 30 mins, 0
BOX processed SMS message count in the last 30 mins, 0
----------------------------------------------------------------
BOX1 Connection unreachable...
You might wonder: Well, what is all that?
-We get a global SMS report plus one on every running Box; and we will be notified if a
Box is unreachable (of course... all the incoming traffic is automatically directed to the
healthy Boxes).
The base SMS types serviced are –
SMS MECCA_DIR_TEXT
SMS MECCA_DIR_GRAPHIC
SMS PRAYER_SCHEDULER
SMS UPDATE_LOCATION
SMS PRAYER_TIMES_AT_DATE
SMS CALENDAR_UTILS
Additionally, we receive the average SMS service throughput per minute on each Box; the
number of SMS requests that have reached the Box and got successfully serviced, the
total count of processed SMS and the number of SMS messages that failed to parse.
All this is critical information for the admin. The throughput averages and the processing
queues must be kept within relative consistency to the system's setup specs. If incoming
16

SMS counts outgrow the processed SMS counts, this means it is time to introduce more
processing boxes into the system.
SMS Daily usage Log
This tool allows either ISCadmin or ISCguest to download a detailed log file, with the daily
activity log serviced by all BOXes for the last 400 days of operation of the ISCSA. This is
intended to be downloaded and processed using Excel, to track down the revenue that
was generated by the service on a day-to-day basis.
Monitoring
Monitoring is a tool designed for the ISCadmin of the ISCAS. It allows him to view the
processing load of active Boxes, change the SMSC links the system uses, alter allowed IP
connections and check the active license of the system's boxes.
Selecting 'processing state' yields a web page, where we can see if a box is OK,
Suspended or Unreachable, its OS kernel, the count of processors that service it, the
system load it induces, the number of active connections it services, its memory usage
profile, HardDisk availability and Uptime.
Eg...
Request result:
ISC admin email:xxx@gmail.com
BOX report
----------------------------------------------------------------
BOX0 :127.0.0.1 :4444 OK
17

Linux 2.6.35-28-generic
Number or processors: 1
Current system load: 0,4
No of active connections: 1
Current Free memory available to Virtual Machine (Kb): 13.854
Max memory available for Virtual Machines (Kb): 506.816
Used memory of Virtual Machine (Kb):2.017
Total Disk space (MB): 18.600
Free Disk space (MB):11.214
Processing BOX Uptime in Days: 0,0152
PostgreSQL Server request buffering used
DB admin email: xxx@gmail.com
----------------------------------------------------------------
BOX1 :127.0.0.1 :4446 UNREACHABLE
----------------------------------------------------------------
SMSC Connections, simply projects the URLs of active SMSC / MMSC server connections
Request result: Response from BOX0
User =yiannis URL=http://localhost:13013/cgi-bin/sendsms? : Locale=0
User =invalid URL=http://localhost:13014/cgi-bin/sendsms? : Locale=512
User =yiannis URL=http://localhost:13014/cgi-bin/sendsms? : Locale=513
User =binary URL=http://localhost:13013/cgi-bin/sendsms? : Locale=514
----------------------------------------------------------------
IP Lists projects the active IP connection filter
Request result: Allowed Incoming IP = *.*.*.*
Active License info projects the license information for each running Box. The license time
for each Box is timed in Days. If the time lease expires, the Box falls into a restricted
mode operation (slows down considerably).
Request result: Response from BOX0
TIME-LEASE EXPIRED. RUNNING IN RESTRICTED MODE. REQUEST NEW LICENSE!
----------------------------------------------------------------
18

Settings
This is the web console tab, which allows the admin to add a new processing box
connections, pause Box connections, resume or remove them. Removing a Box
connection does not physically 'kill' a box; Killing a Box has to be done using a telnet
connection to it and entering the command END_BOX.
To add a new processing Box, the Box must first be started as an ordinary java .jar
application; a telnet connection must be made to it; a new license certificate must be
initially imported as described in a previous section of this document and the BOX IP and
port must be declared in the BOX IP and Port field form.
Pausing / resuming / removing a Box connection is used in case a Box software update
has to be executed. An old Box must be paused, then safely ended, a new one must be
started, and a new connection added.
Incoming SMS command buffering sends all incoming SMS messages to a temporary text
file; essentially stopping them being channeled over to processing boxes. The command
can be revoked likewise. If all BOX connections die (total network failure etc) the incoming
19

SMS messages are automatically buffered; the admin is notified by email (SMS to be
included in the future).
When the network topology is restored, by selecting 'Unbuffer', the admin will send the
buffered content back to the processing Boxes, right along with normal incoming SMS
traffic.
Trace Log On and Off turns the trace log feature on and off. The text file generated is
placed in /home/<username>/ISCLog folder
Utilities
This selection tab groups the licensing lease updates on running Boxes. To renew a Box
lease, request a Box Run ID, send the server response to the support, and import the
license certificate using 'New License key'. A certificate can be used once and only in one
Box.
To import new CellIds (or update existing ones) to the DB, form a text file using the
following format eg.
1,44.8794617951663,-0.52644743414451,208,10,18122,32951790,0 (all decimal values)
or...
20

<arbitrary seq number>,
<latitude>,<longitude>,MCC,MNC,LAC,CELLID,<location height>
Place this text file in /home/<username>/ISC and select import/update cellIDs. Enter the
Box that should receive this data and your filename. If no data is available on location
height, use an approximate value (0..100).
The filename can be followed by an MCC + MNC filter, executed on the source cellid data.
Example: cellid.txt;208;10
will filter and import from cellid.txt those entries, with MCC=208 and MNC=10
Example: cellid.txt;202 with filter and import those entries where MCC=202
Note that the CellID database can be shared by 2+ Boxes as specified by the SQL server
configuration file. So the update need not necessarily have to repeated for shared CellIDs
databases. It will not cause any malfunction, but would take longer to complete.
This import format is supported by the openCellID DB data, which is freely available at
http://www.opencellid.org; so OpenCellID can be readily integrated in your CellID
database.
The operator's own CellID data can be co-imported in the same DB.
DST files are list of Daylight Time Saving lists for all countries; and a revised periodically.
The updated files go into /home/<username>/ISC; an invocation of the DST update service
is done and the Boxes get fresh DST data.
The same reasoning applies to updating SMSC URL lists. New versions go in the
/home/<username>/ISC folder and the update form leads the data down to the actual
Boxes.
New Allowed IP lists go to the designated form. If more than 5 are needed, separate them
using a semi colon eg. 127.0.0.1;168.192.1.1
Hint
Admin Notification Email – you can use this form to update the admin contact email, in
case a malfunction is detected. An automated warning will be sent, in case a problem is
detected. Soon an SMS admin notification service will be integrated to the system.
_____________________
21

Islamic SIM application server

More Related Content

Similar to Islamic SIM application server

More from Yiannis Hatzopoulos

Recently uploaded

Islamic SIM application server