JSMSC - TDv3 6 20

Jinny Short Message
Service Centre 3.6

Document version 3.6.20
Technical Description
Jinny Short Message Service Centre Technical Description
Copyright
Copyright 1997 2011 Jinny Software Ltd. All rights reserved. No part
of this publication, or any software included with it may be reproduced,
stored in a retrieval system, or transmitted in any form or by any means,
including photocopying, electronic, mechanical, recording, or otherwise,
without the prior written permission of the copyright holder.
This document contains proprietary information of Jinny Software Ltd. The
contents are confidential and any disclosure to persons other than the
officers, employees, agents, or subcontractors of the owner or licensee of
this document, without the prior written consent of Jinny Ltd. is strictly
prohibited.
Disclaimer
Jinny makes no representations or warranties with respect to the contents
hereof and specifically disclaims any implied warranties of merchantability
or fitness for any particular purpose. Further, Jinny reserves the right to
revise this publication and to make changes from time to time in the
contents hereof without obligation to notify any person of such revision or
changes.
Feedback
Jinny endeavours to provide accurate and useful documentation for all
Jinny products. To achieve this goal, the documentation group welcomes
your comments and suggestions regarding any aspect of Jinny user
documentation. Send your comments by e-mail to: documents@jinny.ie
Trademarks and Registered Trademarks

Products and product names mentioned in this document may be
trademarks or registered trademarks of their respective owners.
Release & Document Numbering

Jinny products follow a standard product release numbering scheme such
as release 1.0 for the first release of a product and then 1.1 and 1.2 and so
on for updates to this release until the next product release of 2.0 reached.
The document numbering scheme follows the same format as above but
carries an additional number to indicate where edits or changes have been
made to documents. For example the first Product Description for release
1.0 of a product would be 1.0.0. However if this document is changed for
any reason, this document becomes 1.0.1, indicating the follow on version
of the document. This document numbering scheme can be broken down
as follows:
Revision History
Version Date Author Modifications
0.1 CFI Initial version
Added MHAs contribution and material from external
0.2 2001-02-25 MHA.TMC
version of this document
Added RAM handling of first time messages and
1.0 2001-06-26 BMC
message handling flow charts
Added Informix information and updated

1.1 2001-08-02 BMC
initialization files
Added information on new SIU signalling units and
1.2 2001-11-16 BMC
GSM network configuration
1.3 2002-02-22 BMC Added Jinny SIU Technical Description
1.4 2002-03-22 MEA Updated to a new format
1.5 2002-06-05 MEA Reorganized content and updated features
1.6 2002-08-01 MHA Added few sections
2.0 2003-02-06 PAC Updated to Jinny SMSC Version 2.8
Updated some sections and added:
ESME Routing Section 4.5.3
High Priority Sending Mode 5.5
2.1 2003-05-06 MHA Close User Group 5.8.3
Blocked List 5.8.5 and Block command 6.3.9
Network Messaging
SMSC configuration
Updated Table 5-3 MT Errors
2.2 2003-09-04 MHA
Added Overload Control Mechanisms Section 5.13
Added Overflow mechanism section 5.13.6 to the
Overload Control section
Added smsc_log_privacy parameter to the SMSC
2.3 2004-02-10 MHA
configuration
Added esme_routing parameter to SMPP server
configuration
Updated to Jinny SMSC Version 3.0
3.0 2004-06-25 MHA.PAC.PAT
Formatted to the new template
Update in SMSC Global Configuration
overflow_db entry removed, only JQ are used
overflow bdb entries removed
prepaid_db values modified, BDB no longer
supported
prepaid bdb entries removed
3.1 2004-10-1 MHA
charge_prepaid_on_mo replaced with
prepaid_post_mo_ckpt
Updated and re-organized jinny smsc
synchronisation information
Added retry algorithm SDL
Added SMSC Generic CDR configuration 9.9
Updated to Jinny SMSC Version 3.6
MHA.FKO.WSA
3.6.0 2006-02-16 Added features in SMSC Version 3.3
ENA
Reformatted with new template
3.6.1 2006-09-12 FKO Updated FWD command
Added a description of the First Delivery Attempt in
3.6.2 2006-09-27 MHA the message handling section, and First Delivery
Attempt configuration parameters
Added description of TLR fields in section 0
3.6.3 2007-01-24 MHA
SMSC History File
Updated the Main SMSC Configuration Files
Updated the Table 9-16 - ESME Servers and SMSC
shared configuration entries
Added the Jinny Filtering Engine to the Interfaces
section
MHA
3.6.4 2007-07-11 Updated the SMSC Generic CDR Configuration
GYA
Added Address Translation
Updated DataBase Synchronization process
(sync_db) Configuration
Updated conformance table
Added Compliancy table
3.6.5 2007-08-28 RFA Added counters in Section 4.5.6
Updated counters in Section 4.8 Jinny Advertising

Engine
The Jinny Advertising Engine
(JADE) allows the operator to insert
text advertisements into SMS
messages to generate additional
revenues. Advertisers have the
power to request specific advertising
strings which are then placed in the
SMS traffic by the operator.
To enable forwarding new incoming
3.6.6 2008-03-14 MHA
messages to the JADE, please refer
to the MO Control Configuration.
The subscriber can use the Sponsor

embedded command to send
messages to the Jinny Advertising
Engine. For more information on how
to use this command, please refer to
the SPONSOR (SP) CONFIGURATION .
Statistics
Added GSM to iDEN conversion (section Network
3.6.7 2008-06-27 MHA Interconnect) and related configuration parameters
Updated SMSC global configuration
3.6.8 2008-10-30 FKO Added SMSC charging scenarios
3.6.9 2008-11-06 JSH Remove Hardware Part
Updated configuration and counters
3.6.10 2009-02-20 MHA
Added SMSC-SNMP traps
Added charging parameters sent to the RTCG.
3.6.11 2009-04-09 FKO.JSH
Minor modifications in the charging scenarios.
Added section describing the different SMSC internal
3.6.12 2009-08-05 FKO.JSH
configurable service types
3.6.13 2009-08-11 MHA.JSH Added the Trace section
3.6.14 2009-09-01 PGH.JSH Updated the distribution lists section.
Updated the lawful interception section.
3.6.15 2009-11-06 PGH.JSH.FKO Added description of translation files in the ini file
Added charging error notification
Corrected aim_type DL value in SMSC history file
Added nodes section in SMSC local configuration
Added spam_check_mo_address_range
3.6.16 2010-04-19 MHA
configuration parameter
Added the prepaid sequence id to the GSM MO and
MT TLR
3.6.17 2011-03-16 FKO.JSH Added Prepaid TLR description
Updated the SMPP AIM Configuration
3.6.18 2011-03-24 PGH.JSH.MHA Added user_response to CDMA/TDMA Short Message
TLR (MO and MT)
3.6.19 2011-04-06 MHA.JSH Added Sample TLRs
- Added prepaid_seqid to GSM Status Report TLR
3.6.20 2011-08-29 MHA.JSH - Fixed description of status, command and
cmd_type in SMSC History File
(J), Jinny are trademarks of Jinny Software Ltd.

Jinny Software Ltd. is a wholly-owned subsidiary of the Acotel Group Spa
Preface
About this document
This document provides a technical description of the Jinny Short
Message Service Centre (SMSC). It describes the systems behaviour,
the interfaces, the architecture, the internal operations, as well as the
standards conformance. It also includes hardware and operating system
specifications.
The distribution of this document is restricted and its contents should be

treated as confidential information. It will only be provided to Customers
under a signed Non-Disclosure Agreement.
Copyright 2011 Jinny Software Ltd - Commercial in confidence 5/251

Contents
1. Product Change Log ................................................... 11
2. Overview ................................................................ 12
3. System Context ........................................................ 13
3.1. SMSC Software ............................................................... 13
3.2. SMSC Modes of Operation.................................................. 14
3.3. SMSC Network Architecture............................................... 14
3.3.1. SMSC Server High Availability ...................................................... 14
3.3.2. IP Failover .............................................................................. 14
4. Interfaces ............................................................... 15
4.1. Signalling Interface Unit ................................................... 15
4.2. OAM System .................................................................. 15
4.3. Billing System ................................................................ 16
4.4. Prepaid System .............................................................. 17
4.5. External Short Message Entity (ESME) Interfaces ..................... 18
4.5.1. Receiver ................................................................................ 18
4.5.2. Transmitter ............................................................................ 18
4.5.3. Routing .................................................................................. 25
4.5.4. Provisioning ............................................................................ 26
4.5.5. Charging ................................................................................ 27
4.5.6. Statistics ................................................................................ 27
4.5.7. Regulation .............................................................................. 27
4.5.8. ESME Queues ........................................................................... 27
4.5.9. SMPP ..................................................................................... 28
4.5.10. EMI .................................................................................... 32
4.5.11. Open Interface Standard (OIS) .................................................. 34
4.6. MIN-MDN Mapping ........................................................... 34
4.7. Jinny Filtering Engine ...................................................... 35
4.8. Jinny Advertising Engine .................................................. 35
4.9. Statistics ...................................................................... 35
4.9.1. Static Counters ........................................................................ 36
4.9.2. Dynamic Counters .................................................................... 42
4.9.3. Counters Hierarchy .................................................................. 44
5. Message Handling ...................................................... 45

5.1. Short Message Mobile Originated ........................................ 45

5.2. Short Message Mobile Terminated ....................................... 46
5.3. Network Interconnect ...................................................... 50
5.4. Background Sending Mode ................................................ 52
5.5. High Priority Sending Mode ............................................... 52
5.6. Retry Algorithm ............................................................. 53
5.6.1. Retry Sequences ...................................................................... 54
5.7. More Messages to Send..................................................... 55
5.8. Restricting Mobile Originated and Terminated Addresses .......... 55
5.8.1. MO White and Black Lists ........................................................... 55
5.8.2. MT White and Black Lists ........................................................... 56
5.8.3. ESME Restrictions ..................................................................... 56
5.8.4. Closed User Group .................................................................... 56
5.8.5. Blocked List ............................................................................ 56
5.9. Address Translation ........................................................ 56
5.10. Lawful Interception ........................................................ 57
5.11. Trace .......................................................................... 58
5.12. Last Resort Address ......................................................... 58
5.13. Overload Control Mechanisms ............................................ 58
5.13.1. ESME Input Throttling ............................................................ 58
5.13.2. Anti-Spamming and MO Control ................................................ 58
5.13.3. Background Messaging ............................................................ 59
5.13.4. Output Regulation ................................................................. 59
5.13.5. Input Protection ................................................................... 59
5.13.6. Overflow Mechanism .............................................................. 59
5.14. First Delivery Attempt ..................................................... 60
5.15. Message Flow ................................................................ 60
5.15.1. Components......................................................................... 60
5.15.2. Messaging ............................................................................ 64
6. Commands .............................................................. 68
6.1. Jinny SMSC Commands Overview ........................................ 68
6.2. Group Feature ............................................................... 68
6.2.1. Create Group .......................................................................... 68
6.2.2. Add User(s) to Group................................................................. 69
6.2.3. Remove User(s) from Group ........................................................ 69
6.2.4. Delete Group(s) ....................................................................... 69
6.2.5. Check Groups .......................................................................... 69
6.2.6. Check Group Users ................................................................... 69

6.2.7. Send Message .......................................................................... 69

6.3. Embedded Commands ...................................................... 70
6.3.1. SMS Calling Line Identification Restriction (CLIR) ............................. 70
6.3.2. Delivery Reports (DR) ................................................................ 71
6.3.3. Message Status (MS) .................................................................. 71
6.3.4. Cancel Pending Message (CPM) .................................................... 71
6.3.5. Future Message (FUTURE) .......................................................... 71
6.3.6. SMS Forwarding (FWD) .............................................................. 71
6.3.7. Alias (ALIAS) ........................................................................... 72
6.3.8. Auto Reply (AR) ....................................................................... 72
6.3.9. Block (BLOCK) ......................................................................... 72
6.3.10. Last Resort Address (LRA) ....................................................... 73
6.3.11. Sponsor (SP) ........................................................................ 73
7. Distribution Lists ...................................................... 74

7.1. Introduction .................................................................. 74
7.2. Process Context ............................................................. 74
7.3. Process Information ........................................................ 75
7.4. Charging Information ....................................................... 79
7.5. Dynamic Information ....................................................... 79
8. SMSC Distributed Architecture...................................... 80
8.1. Overview ..................................................................... 80
8.2. Configuration ................................................................ 81
8.3. Functionality ................................................................. 81
8.3.1. Message Processing Unit ............................................................ 81
8.3.2. Signalling Interface Unit ............................................................ 81
8.3.3. Jinny Application Router (JAR) .................................................... 82
8.4. Synchronization ............................................................. 82
8.4.1. Failure................................................................................... 82
8.4.2. Restart Cases .......................................................................... 83
8.4.3. Synchronization processes ......................................................... 83
8.4.4. Synchronization files ................................................................ 84
8.4.5. Primary Node Procedures ........................................................... 85
8.4.6. Secondary Node Procedures ....................................................... 87
8.4.7. Client Node Procedures ............................................................. 89
8.4.8. Installation ............................................................................. 90
8.4.9. Process Information .................................................................. 91
9. Configuration ......................................................... 100

9.1. Main SMSC Configuration Files .......................................... 101

9.1.1. Local Configuration ................................................................ 101

9.1.2. Global Configuration ............................................................... 103
9.2. ESME Servers Configuration ............................................. 131
9.2.1. SMPP AIM Configuration ........................................................... 133
9.2.2. EMI Configuration ................................................................... 136
9.2.3. SEMA (OIS) Configuration ......................................................... 138
9.3. SMSC Synchronization Configuration .................................. 138
9.4. Node Synchronization process (jsync) Configuration .............. 139
9.5. File Synchronization process (jfsync) Configuration ............... 140
9.6. DataBase Synchronization process (sync_db) Configuration ..... 141
9.7. SMSC CDR Configuration ................................................. 143
9.8. SMSC MCR Configuration ................................................. 145
9.9. SMSC Generic CDR Configuration ...................................... 146
9.10. Database Configuration: High Availability ............................ 155
9.11. SMSC Internal Service Types ............................................ 156
9.12. Prepaid Charging Module Configuration .............................. 157
10. SMSC-SNMP traps .................................................... 162
11. Charging Scenarios .................................................. 169
11.1. SMS-MO Charge Ack ....................................................... 169
11.2. SMS-MO Charge Nack ..................................................... 170
11.3. SMS-MO Charge timeout Ack ............................................ 171
11.4. SMS-MO Charge timeout Nack .......................................... 172
11.5. Commit after delivery.................................................... 173
11.6. Commit After Submission ................................................ 174
11.7. Cancel after permanent error .......................................... 175
12. Charging protocol fields ............................................ 176
12.1. Fields in case of Reserve/Charge ...................................... 176
12.2. Fields in case of Commit/Cancel ....................................... 177
13. Conformance ......................................................... 178
14. Compliancy Table ................................................... 180
15. Appendices ........................................................... 188
15.1. Message Handling Procedure ........................................... 188
15.2. Prepaid charging scenario ............................................... 217
15.3. SMSC History File .......................................................... 221
15.3.1. GSM Short Message TLR (MO and MT) ....................................... 221

15.3.2. GSM Status Report TLR ......................................................... 223

15.3.3. GSM/CDMA Alert TLR ............................................................ 224
15.3.4. Audit TLR .......................................................................... 224
15.3.5. CDMA/TDMA Short Message TLR (MO and MT) ............................. 224
15.3.6. CDMA/TDMA Delivery Acknowledgment TLR .............................. 227
15.3.7. CDMA Read Acknowledgment TLR ........................................... 228
15.3.8. CDMA User Acknowledgment / TDMA Manual Acknowledgment TLR . 229
15.3.9. Sample TLRs ...................................................................... 230
15.4. Prepaid History File ...................................................... 243
15.4.1. Prepaid transaction TLR ....................................................... 243
15.5. UNIX Regular Expressions ............................................... 244
15.6. SMPP Translation Table .................................................. 246
15.7. Format strings conversion characters and precision ............... 248
16. Definitions and References ........................................ 250
16.1. Definitions .................................................................. 250
16.2. References ................................................................. 251

1. PRODUCT CHANGE LOG

Version Modifications
2.5 Replaced Telesoft GMSC with Jinny SIU. Better SMSC performance
Embedded SMSC Commands
Closed User Group
Group Command
2.8
Distribution lists
Virtual Service Centre
Better Performance
GPRS support
2.9
Overload mechanism
Msisdn trace
Caller Event Record
2.9.1 Audit Trail
Improved logging and statistics
Better performance
Distributed architecture
GSM and CDMA network inter-working
Internal queues re-designed from linked lists, to hash lists for numbers
and linked lists for messages
More Messages to Send
Reject duplicates
Improved MT-spamming (regulation on the number of messages pending
3.0
for each msisdn)
Message encryption
Configurable retry sequences
Routing based on PID
Multiple designs for the Overflow, Prepaid and ESME queues
More flexibility with new configuration parameters
Better performance
Multiple SMSC instances per machine
Charging enhancements
Charging engine generic interface
Dynamic retry algorithm for overload protection
Configurable error codes and types
Unconditional forwarding
Check and modify ESME status from the administration interface
Configurable retry schemes per ESME
3.6 Subscribers last resort address
Web administration improvements
Audit trail enhancements
Internal optimization
TDMA SMS Format Support
Inter-carrier gateway support
Length adaptation between different network types
MIN-MDN mapping
Integration with the optional Jinny Filtering Engine (new)

2. OVERVIEW
The Jinny Short Message Service Centre (JSMSC) provides services to
Short Message Service (SMS) users in GSM, CDMA and TDMA networks.
The SMSC is the post-office in the network acting as a store-and-forward
device and saving messages locally so that they can be reliably delivered.
It can be connected to various external application server platforms (also
called External Short Messaging Entities (ESMEs)) that can send and
receive messages to mobile subscribers.
Note: The Jinny SMSC supports interfaces to external short messaging entities
using different protocols. Currently the SMSC supports three protocols:
SMPP, EMI and OIS. Each protocol has its own settings and configuration
parameters. If the administrator requires further information regarding the
protocols, the administrator should refer to the appropriate documentation
(0 for the SMPP, 0 for the EMI and 0 for the OIS).

3. SYSTEM CONTEXT
The Jinny SMSC connects to different external entities. It connects to the
mobile network through the Jinny Signalling Interface Unit (SIU)
implementing the Jinny Gateway Mobile-services Switching Centre (GMSC).
It provides three types of protocols - Short Message Peer to Peer (SMPP),
External Machine Interface (EMI), and SEMA Open Interface Specification
(OIS) - to connect External Short Messaging Entities to the SMSC. They
can use TCP/IP or X.25 protocol as a bearer. In a distributed architecture,
the Jinny Application Router (JAR) is needed to provide a single point of
access for the ESMEs and to distribute the traffic among the MPUs. The
SMSC also connects to the following systems:
Billing System.
Operation, Administration, and Maintenance (OAM) System.
Prepaid System.
ESME ESME ESME
SMPP over EMI over SEMA over

TCP/IP or X.25 TCP/IP or X.25 TCP/IP or X.25
G
M
Mobile Network Jinny SIU Jinny SMSC
S
C
OAM System Billing System Prepaid System
Fig 1 Jinny SMSC Context
3.1. SMSC Software

The software that runs on the SMSC server consists of the following:
The reliable and robust Sun Solaris operating system. The SMSC can
also run on the Linux operating system.
The Informix Dynamic Server database system or the MySQL database
system for all database related tasks.
The SMSC application software.
The SIUs software consists of the following:
The Linux operating system.
The GSM or IS-41 MAP and SS7 protocol software.

3.2. SMSC Modes of Operation

The Jinny SMSC supports four modes of operation. It supports the standard
modes: Store-and-Forward, Forward (transactional) and Datagram as well
as the Jinny specific mode: Direct.
Using the Direct Mode, the SMSC inserts the message received (MO or
ESME originated) into the messages queue. The SMSC attempts delivery of
the message. If the delivery is successful, the SMSC removes the message
from the message queue. Otherwise, it stores it into the database for
further delivery attempts using the SMSC retry algorithm. The non-volatile
message queue guarantees that the messages will not be lost if the SMSC
restarts. They will be discarded only if a hardware problem causes a
failover.
The Datagram and Forward Modes are similar to the Direct Mode except
that the SMSC does not store failed messages. Only ESME clients can
submit messages using these modes. For the Datagram mode, the SMSC
acknowledges reception of the submitted messages upon submission, while
for the Forward mode it acknowledges the delivery (positively or
negatively) based on the MT response.
The Store-and-Forward mode is the most common mode: the message is
stored before it is sent. This mode insures that messages will not be lost in
any cause of failure.
3.3. SMSC Network Architecture

The signalling interface layer normally runs on a separate platform than the
service layer. The signalling unit uses signalling cards and other
components with GMSC software that Jinny specifically developed to handle
load sharing between the signalling units and the connection with the Jinny
SMSC server. This offers up to a maximum of 40 signalling links in a fully
fault tolerant configuration. The unit connects to the SMSC server over a
high speed LAN. The signalling units present a fully fault tolerant
configuration to the network and will be identified by a single point code.
3.3.1. SMSC Server High Availability
The SMSC starting Release 3.0 consists of at least two servers that are
active at the same time. The SMSCs database synchronization processes
will continuously replicate data from the primary server to the other
node(s), so that there will always be at least two up-to-date versions of the
database. Monitoring software will continuously monitor the health of all
elements in the cluster, and in the event of any failures on the primary
system it will initiate a switchover of the services (ESME servers) to the
standby. The switchover is fully automatic and a notification will be sent by
way of an alarm to the operators network management system. The
normal messaging services will not be affected by a node failure (does the
replicated data consist of messages or of EMSE configurations and user
profiles).
3.3.2. IP Failover
The SMSC server platforms have automatic IP failover. Each machine has a
virtual IP address in addition to the real IP addresses. This virtual address
is shared between the primary and secondary nodes. Whenever the
secondary senses that the primary has failed, it takes over the virtual IP
address and starts some services locally. Services consist of two kinds:
TCP/IP server processes and others. The TCP/IP processes can be started
on both the primary and the secondary at the same time. All state
information is stored in the database and in directories that are
synchronized by the SMSC application itself.

4. INTERFACES
4.1. Signalling Interface Unit
The SMSC communicates with the rest of the mobile network using the
GSM or IS-41 Mobile Application Part (MAP) protocol over SS7. It can
communicate directly with Mobile Switching Centres (MSC) and Home
Location Registers (HLR) for the purpose of sending and receiving short
messages to and from mobile handsets. It can also communicate with
these elements through Signalling Transfer Points (STP).
The Jinny SMSC connects to the mobile network through the Jinny SIU. It
implements the GSM 03.40 defined GMSC and Inter Working Function
MSC functions for handling messages to and from the SMSC and the GSM
network. It also implements the 3GPP2 C.S0015 and 3GPP2 N.S0005 for
the cellular operations with the CDMA/TDMA network.
The supplied driver supports the MAP/SS7 stack used to connect to the
public land mobile network (PLMN). UNIX processes implement the higher
layers of the stack, (MAP, TCAP, SCCP, and MTP 3).
4.2. OAM System

A number of different interfaces implement the Operation, Administration,
and Maintenance (OAM) system. They allow an operator to run, configure,
and monitor the SMSC in service in a live network. The interfaces consist of
both graphical web (HTML) and man-machine (UNIX command line)
interfaces.
The smsc.ini file holds most of Jinny SMSCs configurable parameters. The
web-based Administration Interface GUI allows the administrator to easily
change most of these parameters.
The Jinny SMSC OAM Guide 0 describes the interfaces in detail, their
functionality and how to configure the parameters governing the Jinny
SMSC. Later sections discuss the individual parameters and their respective
values.

4.3. Billing System

The Jinny SMSC provides a billing interface that assists the operator with
the vital task of charging subscribers for using the Short Message Service.
The interface consists of fixed format billing and provisioning records being
relayed to a remote billing system for post-paid and non-real-time pre-paid
customers.
The SMSCs billing system is flexible and customizable. The SMSC logs each
event (MO, alert, result of MT attempt, optionally MO to ESME) into a
unified data file according to Jinnys Short Message transaction log record.
The record contains different fields relating to the short message. The
operator decides upon which fields to include in the CDR. Accordingly and
in agreement with the operators requirements; Jinny customizes the billing
process in order to provide the operator with the required CDR formats.
The customized billing process generates the CDRs.
For example, the SMSC can perform charging in the following cases:
The SM is an MO to an MT message and the message reached a desired
final status (delivered or in all cases).
The SM is an MO to an MT message and the SMSC accepted it for
delivery.
The SM is from an ESME to an MT message and the service is
chargeable.
The SM is from a mobile station to an ESME and the service is
chargeable.
The SM is a delivery report and it was delivered within the interval
specified.
In the first two cases, the SMSC charges the originator of the short
message while in the next two cases, it either charges the originator or the
receiver (terminating) of the short message depending on the service
configuration. For the status report charging, the recipient address of the
previously submitted MO message will be charged if the status report was
received within a configurable period of time. In addition, the SMSC does
not charge users for background messages.
The administrator defines the type of charging on the ESME services using
the web-based OAM interface.

4.4. Prepaid System

Jinny provides the operator with the Real-time Charging Gateway (RTCG),
as an option to the SMSC, in order to interface the SMSC with the
operators real-time billing system for pre-paid billing. Among others, this
Gateway currently interfaces with Siemens IN and support for Ericssons
and Openets are included as well.
Alternatively, if the prepaid subscribers list can be stored on the SMSC, the
SMSC can append a record to an external prepaid queue, for each message
to be charged for a prepaid subscriber. Charging will then be done based
on a customized application between the SMSC and the operators billing
system. This can be done without any further modification to the current
SMSC process.
Prepaid charging is triggered by different events during the life cycle of a
message. Charging checkpoints can be enabled/disabled to charge/check
prepaid subscribers at the following times:
Pre MO submission (prepaid_pre_mo_ckpt)
In this section additional conditions can be checked to see weather
charging should occur or not:
Normal MO-MT message (mo_mt)
Roaming MO-MT message (roaming_mo_mt)
MO to International MT (mo_international_mt)
MO to GROUP (mo_groups)
MO to ESME (mo_esme)
An additional flag is set to configure charging group messages as
one bulk message(charge_single_group_message)
Post MO submission (prepaid_post_mo_ckpt)
MO to GROUP (mo_groups)
MO to ESME (mo_esme)
Pre MT attempt (prepaid_pre_mt_ckpt)
ESME to MT (esme_mt)
Post MT attempt (prepaid_post_mt_ckpt)
ESME to MT (esme_mt)
An additional flag is set to configure if the message should be
charged when MT returns an error (charge_on_error)
Please refer the appendix 15.2 Prepaid charging scenario at the end of the
document, for a more detailed description of each charging case.
Please also refer to the SMS Billing Scenarios section in the JMR Technical
Description document.

4.5. External Short Message Entity (ESME) Interfaces

The ESME interfaces allow external non-mobile applications to connect to
and interact with the SMSC. The protocol the ESME uses to interface with
the SMSC governs the type and number of operations it can use for the
interaction. Operators and service providers use the External Short
Message Entity connections to provide mobile subscribers with a variety of
services, such as sending news updates, email notifications, logos, ring
tones, etc. Currently, the SMSC supports three types of interfaces: Short
Message Peer to Peer (SMPP) 0, External Machine Interface (EMI)/Universal
Computer Protocol (UCP) 0, and Open Interface Standard (OIS) protocols
0. Each interface uses a transmitter to transmit messages to and a receiver
to receive messages from the SMSC. They can both be on the same
connection (transceiver) or each one requires a separate connection
(transmitter and/or receiver).
4.5.1. Receiver
The receiver handles all the incoming messaging traffic from the SMSC to
the ESME. The SMSC administrator defines a virtual service centre address,
and/or a range of addresses that identify the ESME. The SMSC routes all
the received MO messages in accordance with the specified address to the
appropriate ESME.
The SMSC routes the ESME terminating messages and notifications to the
corresponding ESME client via the database, as shown in the figure below:
SMSC DB
ESME Server Normal Messages
SMSC ESME Client
Receiver Notifications
ESME
JQ
Fig 2 ESME Receiver
4.5.2. Transmitter
The ESME server transmitter handles all the outgoing messages from the
ESME clients to the SMSC, as shown in Fig 3.
Fig 3 ESME Transmitter

The handling of the submitted messages depends on three parameters: the

SMSC Default mode, the ESME clients message type, and the global
priority flag. The first two parameters are specific to the ESME
configuration while the last one is specific to that of the SMSC. See Fig 7
for a description of the submittal procedure of a message from an ESME
client to the SMSC.
The ESME server transmitter handles messages submitted from the ESME
clients in accordance with each clients SMSC Default Mode value.
For the default Store & Forward mode, the ESME server adds the
messages to the database.
For the Direct, the Datagram and the Forward modes, the ESME server
adds the messages to the SMSC shared messages queue.
Using the Direct Mode allows a higher messages throughput while assuring
the same level of safety as the Store & Forward mode, i.e. the messages
will not be lost in the event of a failure. The Direct Mode is where the SMSC
sends the short message to the subscriber and waits for a response. If the
terminating mobile acknowledges the delivery, the SMSC will delete the
message. Otherwise, it will store it for later retry.
The Datagram Mode is where the ESME sends a message and gets an
acknowledgement from the ESME server of its receipt. The SMSC will
attempt sending it. Upon receiving a positive acknowledgement or an error,
the SMSC will delete the message from its message queue.
The Forward Mode is similar to the Datagram Mode with the exception that
the ESME server notifies the client of the status of the message delivery.
In addition to the Default SMSC Mode, the value of the
global_priority_flag parameter affects the way the ESME Server
handles the messages. Under normal priority, the SMSC adds terminating
messages to the database for users whose mobile status is unreachable.
The SMSC will attempt to deliver it in accordance with the configuration of
the retry algorithm.
When the global_priority_flag is set; the SMSC attempts delivering
the message to the mobile station even when the mobile station is
considered unreachable. This is done in order to account for the case where
the mobile is flagged as unreachable by the HLR due to it being outside
coverage; it comes back into coverage without the HLR updating its status.
This way, the subscriber receives the short message before the HLR
updates its status and notifies the SMSC.
The third parameter is the type of messages. It takes two values: Normal
and Broadcast. If set to normal, the ESME server treats the message as a
normal message. If set to Broadcast, the ESME server treats the messages
as lower priority and the SMSC will send them using the Background Mode
5.4 in order not to disrupt normal traffic.

Fig 4 below illustrates the Software Description Language (SDL) symbols

used to describe the SMSCs various components and processes.

Fig 4 Legend

In the ESME diagrams below Submit SM means an ESME client

submitting a short message to the SMSC.
Fig 5 Handle ESME Submit SM

The Check MO Profile and Check MT Profile Processes are described in

Fig 74 and Fig 75 respectively.
AR means Auto Reply. For further information see sec 6.3.8
Fig 6 - Handle ESME Submit SM (contd)

Submit ESME Message
Start
Global Priority
No
Flag ?
MO or MT in VIP
No
List ?
Yes
Yes
Store & Forward

MT Waiting? No
Mode ?
Store & Forward

Mode ? Datagram or
Transactional
Yes Yes
mode
Add Message to No
Yes
No Configured SMSC
Message
Table
Add Message to requires storage?
Configured SMSC
Store&Forward
Table
or DIrect mode
Yes
Store Message to
Configured SMSC No
Add Message to Table Add Message to
Configured SMSC Configured SMSC
Queue Queue
Handle Intermediate
notification if requested
(SMPP only)
Fig 7 Submit ESME Message

4.5.3. Routing
The SMSC routes incoming messages to the appropriate ESME receiver,
based on the virtual service centre address using the range of the
destination addresses or the range of the protocol id specified for the
message. Each receiver ESME should have at least one of the routing
methods defined. In addition to the above, a lawful interception allows a
message to be forwarded/copied to a specified ESME (refer to section
below).
The SMSC automatically updates its internal routing table periodically

(config_period configuration parameter).
A. Virtual Service Centre

The virtual service centre (VSC) is an alias address for the SMSC. Only MO
messages can use this feature. It requires that the following conditions be
verified:
The VSC address should be set on the SIM as the used service centre.
A route should be defined on the network for the messages to reach
the SMSC.
The VSC prefix should be defined on the GMSC under the SMSC index.
This method can be useful for SIMs distributed by content providers, where
the user does not need to know and remember the short code of the
service. In some cases, this method might reduce the part of the message
used for the command, allowing a better use of the message.
B. Address Range
This method of addressing is the most commonly used. It consists of
defining an address range for each ESME client using a regular expression.
Whether it originated from a mobile or from an ESME, each message with a
destination address matching the defined address range, is routed to the
associated ESME.
This method does not require any settings, but the users must know the
defined address ranges in order to access the services provided.
C. PID Range
In GSM networks, the protocol identifier (pid) is the parameter describing
the above protocol, if any. In other words, if this parameter is set, the SM
is not a simple MO-MT message: it is part of a higher protocol using the
SMSC as a bearer. It can be set using the sending options available for the
user: text, FAX, paging, or Email. While the text messages are always
handled by the SMSC, a receiver ESME can be configured to receive any of
the other protocols. Routing based on PID eliminates the need for a short
code.
Based on the GSM 23.040, the pid values are:
PID Description
34 Telefax
38 National Paging System
50 Internet Electronic Mail
Table 4-1 - Pid values

For each
vsc ESME defined
defined?
no
yes
sc_addre
ss
no
matches
vsc?
yes address
range
return defined?
ESME no
id
yes
daddr
matches
no
address
range?
yes
pid range
no
return defined?
ESME
id
yes
pid
matches
no
pid
range?
yes
return
ESME
id
Fig 8 Routing algorithm applied for each message submitted to the SMSC
4.5.4. Provisioning
The SMSC web administration interface provides the administrator the
means to provision the ESME clients. It provides the administrator with all
the configurable parameters for each of the supported protocols as well as
the list of available choices where appropriate.

4.5.5. Charging
The SMSC provides two methods for charging messages that it exchanges
with the ESME clients. The ESME server handles one and the SMSC handles
the other.
The ESME server charges messages it sends to or receives from the SMSC
based on two parameters: default_service_type and charging_type. If
the first one is set, then the ESME server performs charging; otherwise,
the ESME server performs charging based on the messages service type.
The charging_type parameter takes three values: No charging, MO to
be charged and MT to be charged. The ESME server performs the
charging if the value of the charging_type parameter is different from No
charging. In this case, the ESME server charges messages regardless of
their final status, whether delivered or not.
In the case the parameter default_service_type is set and the
parameter charging_type is set to No charging, the SMSC performs the
charging upon the short message reaching a final status.
For the SMPP interface, the SMPP client can use different values for the
parameter service_type in the short message in order for the ESME
server to charge each aim differently. The ESME server can override the
messages service_type value through the SMSC administrator setting the
parameter default_service_type.
For the other two interfaces, EMI and OIS, the ESME server charges
messages only in the case the parameter default_service_type is set.
4.5.6. Statistics
The SMSC provides the SMSC administrator with different counters
informing the administrator about the usage of the external connection
with the SMSC. The counters offer statistics regarding the total usage of all
the external connections as well as statistics per connection.
4.5.7. Regulation
Releases 2.9 of the SMSC introduced regulation of the throughput on the
connections between the external short messaging entities and the SMSC.
The SMSC administrator can specify the throughput of each ESME
connection to the SMSC on a transmitting client (transmitter or
transceiver). One of the main purposes of this feature is to manage the
throughput generated by the ESMEs and to avoid spamming subscribers by
ESME clients. The feature is configured on a per client basis. The value of
the regulated throughput cannot exceed the global maximum rate specified
in the license site and is configured system-wise (rglt_spam_rate) for
messages delivered to the same destination (MSISDN).
4.5.8. ESME Queues
The JSMSC support 2 methods for passing messages to an ESME receiver:
A. Database
This method insures that no messages are lost in case of a sudden failure
and a failover to the secondary node: messages are stored in the database
until delivered to the corresponding receiver ESME. This is suitable for low
traffic applications.
B. Jinny Queue
The method is useful for real-time applications (like the voting application),
where a burst of messages should be handled in a short period of time.
This method is fast and alleviates the system from unnecessary load on the
database.

4.5.9. SMPP
The Jinny SMSC supports version 3.3 and 3.4 of the Short Messaging Peer
to Peer protocol (SMPP). Please refer to the SMPP v3.4 Protocol
Implementation Conformance Statement (PICS) Proforma for a detailed
list of the features supported. Included in the features is support for UDHI
support, Store & Forward, Datagram and Forward (Transactional) modes.
UDHI indicates that the sent or the received message contains GSM User
Data Header Information.
Communication between an SMPP-based ESME and the SMSC requires
either a single or two network connections. Applications or processes, also
known as Application Interface Modules (AIMs) handle each of the
connections. An AIM can connect/bind as a receiver or a transmitter or a
transceiver.
Three parameters identify an SMPP transmitter AIM: system_id,
system_type and password, which identify and authenticate an ESME. The
SMPP server handles multiple AIMs. The SMSC administrator creates and
manages the AIMs through the web-base administration module. Further
information on SMPP configuration can be found in Section 9.2.
Using SMPP an application can perform the following main tasks:
Bind to the SMSC

Based on SMPP version 3.3, which is a one-way protocol, the ESME must
bind as a transmitter to send messages to the SMSC and also as a receiver
to receive messages from the SMSC. However, support of version 3.4 of
the SMPP protocol allows the ESME to bind as a transceiver, for client
wishing to submit and receive messages on the same connection.
Submit Messages
The ESME submits messages to the SMSC for delivery to subscribers in
accordance with the SMPP specifications. In addition, the ESME can use the
esm_class parameter to send messages in the Datagram Mode and to set
the UDHI flag (as specified in SMPP version 3.4).
Receive Messages
The SMSC delivers messages to ESMEs bound as receivers or transceivers.
Fig 9 and Fig 10 below clarify the above description.

SMPP Server (AIM) Main Process
Start
Initialize
Listen on specified
Client connected? No
port
Yes
Message from client? No Closing the connection
Yes
Bind (RX, TX or TRX)
Successful
authentication?
No
Yes
Not already bound?
Yes
Bind accepted Bind refused
Yes
Fork a child SMPP

Closing the connection
process
child parent
Handle SMPP client
Fig 9 SMPP Server (AIM)

Fig 10 Handle ESME Submit SM_SMPP

Fig 11 - Handle ESME Submit SM_SMPP (contd)

4.5.10. EMI
The EMI is a two-way protocol. The EMI application can create an outbound
connection in order to connect to a remote server or as a listener in order
to allow a remote application to connect to it. Each application can send
and receive messages on the same connection.
The Receiver EMI process is responsible for:
Establishing the connection to the ESME.
Delivering new messages.
Delivering notifications of previously submitted messages
The Transmitter EMI process is responsible for:
Accepting a connection.
Authenticating the client.
Receiving and handling of the submission of new messages
Authentication is based on the IP address (and port) of the client and/or on
the session management. Fig 12 shows the flowchart for EMIs transmitter
connection authentication.
Once the SMSC and the ESME establish an EMI connection between each
other, the ESME can use the following operations:
Session Management (operation 60).
Submission of Short Messages (operation 51).
Delivery of Short Messages (operation 52).
Delivery of Notifications (operation 53).
Modification of a Message (operation 54).
If the message was submitted with a notification request, the notification
will be handled in one of the following two cases:
If the notification address is empty, the SMSC delivers all notifications
via the receiver EMI process.
If the notification address is a mobile address, the SMSC sends a short
message to that mobile.
The reader can find further information on EMI configuration in Sec 9.2.2.

Fig 12 Transmitter EMI Process Authentication

4.5.11. Open Interface Standard (OIS)

SEMAs Open Interface Standard is another protocol used to interface an
ESME with the SMSC. It allows Short Messages and notifications to be
submitted and received to and from the Jinny SMSC based on SEMAs OIS
protocol 0 .
The connection between the SMSC and the ESME can be established over:
TCP/IP.
X.25.
There are two ways to access the SMSC: the most common method is via
the SMSC general X.25 or TCP access gateways that implement access
control. The other way is via a direct dedicated connection to the SMSC.
Once the connection is established, the following operations can be used:
Submission of Short Messages.
Delivery of Short Messages.
Delivery of Status Reports.
SEMA is a two-way protocol. An ESME sends messages to the SMSC and
receives messages and notifications from the SMSC on different
connections.
Submitted messages can use all the options and fields associated with the
SMS messages, e.g. User Data Header, Message Type, and Protocol ID, as
well as the special features provided by the Jinny SMSC (datagram/store
and forward mode, background/normal sending messages mode). It is
possible for applications to request delivery reports from the SMSC.
Note that this version of the SEMA server supports only binary encoding if
its a direct access and Hex or IA5 encoding for X25 access.
The Two Processes

For each SEMA client defined by the administrator, there exists an IP
address through which this client is able to connect. The SEMA server
checks the validity of any connection before it is established.
The first process is the transmitter over which the client submits messages.
In this case, the SEMA server listens on one port waiting for the client to
connect and send messages.
The other process is the receiver which, unlike the transmitter, doesnt
listen on a port. The client would listen on the port, whereas the receiver
checks if the port is available. If so, the receiver validates the
authentication and then delivers all messages from the aim_messages
table to the client. (This task is repeated periodically as long as the
connection is not broken).
In all cases the SEMA server deals with result messages. Using a flag in the
ini file we can enable login operation on both transmit and receive
operations. The authentication is based on:
The IP address.
and/or
The port of the client.
Username and password if login is enabled.
4.6. MIN-MDN Mapping

This feature is used in ANSI networks only.
In cases where no simple rule allows the determination of MIN from MDN,
the SMSC can use an internal database to do the conversion. This database
is populated from the web interface and also using the batch command
admminmdn.
The SMSC is configured to use this feature by setting the following flag in
the smsc.ini file:
use_min_mdn_mapping

4.7. Jinny Filtering Engine

This is an optional product that can be deployed with the Jinny SMSC. The
Jinny Filtering Engine (FE) allows a Network Operator to automatically
detect and block all unwanted content. Benefits include:
SPAM filtering Reduce the occurrence of message spamming and help
maintain the required reputation of your Network.
Content filtering - Block value added content like pictures and ring-
tones from non-network partners and protect your own revenues.
Censorship Create key word filters, which can be applied to all traffic.
To enable forwarding new incoming messages to the Jinny FE, please refer
to the MO Control Configuration.
4.8. Jinny Advertising Engine

The Jinny Advertising Engine (JADE) allows the operator to insert text
advertisements into SMS messages to generate additional revenues.
Advertisers have the power to request specific advertising strings which are
then placed in the SMS traffic by the operator.
To enable forwarding new incoming messages to the JADE, please refer to
the MO Control Configuration.
The subscriber can use the Sponsor embedded command to send

messages to the Jinny Advertising Engine. For more information on how to
use this command, please refer to the SPONSOR (SP) CONFIGURATION .
4.9. Statistics
The Jinny statistics counters provide an insight into the status and
performance of the system. Their value is either incremental or absolute
based on the counters type. The counters are usually collected at a
configured period, and recorded into a statistics file for an offline checking
and analysis. The administrator can also execute the jstat tool on the
command prompt to get a real-time snapshot of the different counters.
This can be very useful when trying to detect and pinpoint problems. There
are two types of counters: static and dynamic. The tables below give a
description of the available counters.

4.9.1. Static Counters

Counter Description
smsc.alive Status of the smsc process
smsc.license Purchased license
Current performance: MO Submit + MT Deliver +
smsc.performance
SMSC to ESME (et-total) + ESME to SMSC (eo-total)
Counters for messages received from the network to the smsc (MO SMS + network
acknowledgements)
smsc.mo-total Total number of the messages received by the SMSC
smsc.mo-packet Total number of packets received by the SMSC
smsc.mo-submit Total number of the MO short messages
Total number of the MO short messages originating
smsc.mo-submit-gsm
from a GSM network
Total number of the MO short messages originating
smsc.mo-submit-cdma
from a CDMA network
Total number of MO messages received with reject
smsc.mo-submit-dup
duplicate set
smsc.mo-submit-term Total number of Network Terminated MO messages
smsc.mo-submit-esme Total number of MO short messages to ESME
smsc.mo-submit-mt Total number of MO MT short messages
smsc.mo-submit-mt-normal Total number of MO MT normal messages
Total number of MO MT messages containing an
smsc.mo-submit-mt-embedded
embedded command
Messages submitted from prepaid numbers to mobile
smsc.mo-submit-mt-prepaid
destinations1
Messages submitted from post-paid numbers to
smsc.mo-submit-mt-postpaid
mobile destinations
Messages submitted to international mobile
smsc.mo-submit-mt-intrntl
destinations2
MO Messages submitted to foreign mobile
smsc.mo-submit-gsm-mt-int
destinations from GSM
smsc.mo-submit-cdma-mt-int
destinations from CDMA
smsc.mo-submit-tdma-mt-int
destinations from TDMA
Messages submitted from roaming mo to mobile
smsc.mo-submit-mt-roaming
destinations
smsc.mo-submit-mt-roaming- Messages submitted from prepaid roaming mo to
pre mobile destinations
smsc.mo-submit-mt-roaming- Messages submitted from post-paid roaming mo to
pos mobile destinations
MO Messages submitted to local offnet mobile
smsc.mo-submit-mt-offnet
destinations
MO Messages submitted to local offnet destinations
smsc.mo-submit-gsm-mt-offnet
from GSM
smsc.mo-submit-cdma-mt-offnet
destinations from CDMA
smsc.mo-submit-tdma-mt-offnet
destinationsfrom TDMA
smsc.mo-submit-group Total number of MO - Group address messages
smsc.mo-submit-embedded Total number of MO - Embedded address messages
smsc.mo-delivery-ack-tdma MO TDMA delivery ack messages
1
Only available if prepaid checking is done on MO submission
2
Only available if local_routing_expr is defined

smsc.mo-manual-ack-tdma MO TDMA manual ack messages

smsc.mo-command Total number of MO commands
smsc.mo-alert Total number of alert messages
Total number of alert messages originating from a
smsc.mo-alert-gsm
GSM network
Total number of alert messages originating from a
smsc.mo-alert-cdma
CDMA network
Total number of User Acknowledgements received
smsc.mo-user-ack
from a CDMA network
Total number of Read Acknowledgments received
smsc.mo-read-ack
from a CDMA network
Total number of successfully received MT (MO-MT or
ESME-MT) messages (SMS or SR).
smsc.mo-ack
Mainly, this counter should be equal to:
mo-ack = mo-ack-sms + mo-ack-sr
Total round trip time (in ms) for successfully
received MT messages. When divided by mo-ack, the
smsc.mo-ack-rt result is the average delay on the network for
positive acknowledgement. Usually this value is
around 8 seconds.
Total number of successfully received international
smsc.mo-ack-intrntl
MT messages
smsc.mo-ack- intrntl-rt received international MT messages. Should be
devided by mo-ack-intrntl
Total number of successfully received local MT
smsc.mo-ack-local
messages
smsc.mo-ack- local-rt received local MT messages. Should be divided by
mo-ack-local
Acknowledgments of local offnet mobile terminated
smsc.mo-ack-offnet
messages
Round trip time of positive acknowledgments to local
smsc.mo-ack-offnet-rt
offnet numbers
Acknowledgments of local onnet mobile terminated
smsc.mo-ack-local-in
messages received within a preconfigured period
Acknowledgments of local offnet mobile terminated
smsc.mo-ack-offnet-in
Acknowledgments of international mobile terminated
smsc.mo-ack-intrntl-in
smsc.mo-ack-sms Total number of successfully received MT SMS
Total number of MT SM successfully received
smsc.mo-ack-sms-prepaid
charged by pre-paid subscribers
Total number of MT SM successfully received
smsc.mo-ack-sms-postpaid
charged by post-paid subscribers
Total number of broadcast MT SM successfully
smsc.mo-ack-sms-brdcst
received
Total number of free ESME MT SM successfully
smsc.mo-ack-sms-free
received
Total number of successfully delivered MT status
smsc.mo-ack-sr
report
Total number of MT SR successfully received by pre-
smsc.mo-ack-sr-prepaid
paid subscribers
Total number of MT SR successfully received by
smsc.mo-ack-sr-postpaid
post-paid subscribers
Total number of positive acknowledgments received
smsc.mo-ack-gsm-gsm
from GSM to GSM
smsc.mo-ack-gsm-cdma Total number of positive acknowledgments received

from GSM to CDMA

smsc.mo-ack-gsm-tdma
from GSM to TDMA
smsc.mo-ack-cdma-gsm
from CDMA to GSM
smsc.mo-ack-cdma-cdma
from CDMA to CDMA
smsc.mo-ack-cdma-tdma
from CDMA to TDMA
smsc.mo-ack-tdma-gsm
from TDMA to GSM
smsc.mo-ack-tdma-cdma
from TDMA to CDMA
smsc.mo-ack-tdma-tdma
from TDMA to TDMA
Total number of errors received for MT (MO-MT or
smsc.mo-error
ESME-MT) messages (SMS and SR)
Total round trip time (in ms) for failed MT messages.
When divided by mo-error, the result is the average
smsc.mo-error-rt
delay on the network for negative
acknowledgements.
smsc.mo-error-intrntl Total number of failed international MT messages 3
Total round trip time (in ms) for failed MT messages.
Should be divided by mo-error-intrntl. Usualy this
error is significantly greater than the mo-error-
local/mo-error-local-rt, due to the fact that no
smsc.mo-error intrntl-rt
response is received for some messages sent to
certain international destinations. In this case, the
local stack generate a system failure error after a
configured timeout (usually 30 s)
Total number of successfully received local MT
smsc.mo-error-local
messages
Total round trip time (in ms) for failed local MT
smsc.mo-error-local-rt
messages. Should be divided by mo-error-local-rt
smsc.mo-error-offnet Errors received for local offnet numbers
smsc.mo-error-offnet-rt Round trip time of errors for local offnet numbers
smsc.mo-error-sms Total number of failed MO SM
smsc.mo-error-sms-prepaid Total number of failed prepaid MO SM4
smsc.mo-error-sms-postpaid Total number of failed postpaid MO SM
smsc.mo-error-sr Total number of failed MO status report
Counter of the system failure error received. Usually
this counter is an indication of a network failure
smsc.mo-error-reason-fail when the ratio mo-error-reason-fail / mo-error
exceeds a certain threshold (for example > 30% of
total errors, depending on the network)
Counter of the no subscriber reply error received. If
the ratio mo-error-reason-noreply / mo-error is high
smsc.mo-error-reason-noreply
during a normal day time, this can be an indication
of a bad network coverage
Counter of the memory capacity exceeded error
smsc.mo-error-reason-memfull
received
Counter of the other errors received (call barred,
teleservice not supported, unknown subscriber,...).
smsc.mo-error-reason-other
Usually the ration mo-error-reason-other / mo-
errors is not significant
3
Only available if local_routing_expr is defined
4
Only available if prepaid checking is enabled

smsc.mo-error-gsm-gsm Total number of errors received from GSM to GSM

smsc.mo-error-gsm-cdma Total number of errors received from GSM to CDMA
smsc.mo-error-gsm-tdma Total number of errors received from GSM to TDMA
smsc.mo-error-cdma-gsm Total number of errors received from CDMA to GSM
smsc.mo-error-cdma-cdma Total number of errors received from CDMA to CDMA
smsc.mo-error-cdma-tdma Total number of errors received from CDMA to TDMA
smsc.mo-error-tdma-gsm Total number of errors received from TDMA to GSM
smsc.mo-error-tdma-cdma Total number of errors received from TDMA to CDMA
smsc.mo-error-tdma-tdma Total number of errors received from TDMA to TDMA
Counters for messages sent from the smsc to the network (Delivery attempts: MT SMS
and SR + MO acknowledgements)
smsc.mt-total Total number of the messages sent by the SMSC
smsc.mt-packet Total number of packets sent by the SMSC
Total number of MT deliver messages SMS and SR:
smsc.mt-deliver
mt-deliver= mt-sms + mt-sr
Total number of MT deliver messages sent to a GSM
smsc.mt-deliver-gsm
network
Total number of MT deliver messages sent to a
smsc.mt-deliver-cdma
CDMA network
smsc.mt-deliver-tdma Messages delivered to TDMA MT
smsc.mt-deliver-mo Total number of MO MT messages delivered
Total number of MT messages delivered that
smsc.mt-deliver-esme
originated from ESMEs
Total number of MT messages sent using the retry
smsc.mt-retry
algorithm
Total number of MT normal messages sent using the
smsc.mt-retry-normal
retry algorithm
Total number of MT background messages sent
smsc.mt-retry-brdcst
using the retry algorithm
Total number of Mobile Terminated Retry messages
smsc.mt-retry-sm
sent
Total number of Mobile Terminated Retry status
smsc.mt-retry-sr
reports sent
Total number of MT messages sent using the Store &
smsc.mt-storefwd
Forward mode
Total number of MT normal messages sent using the
smsc.mt- storefwd-normal
Store & Forward mode
Total number of MT background messages sent
smsc.mt- storefwd-brdcst
using the Store & Forward mode
smsc.mt-storefwd-sm Total number of Store & Forward MT SM sent
smsc.mt-storefwd-sr Total number of Store & Forward MT SR sent
Total number of MT messages sent by the SMSC
smsc.mt-direct
from the direct buffer queue
Total number of normal MT messages sent from the
smsc.mt-direct-normal
direct buffer queue
Total number of brdcst MT messages sent from the
smsc.mt-direct-brdcst
direct buffer queue
Total number of MT messages sent from the direct
smsc.mt-direct-sm
buffer queue
Total number of MT reports sent from the direct
smsc.mt-direct-sr
buffer queue
smsc.mt-sms Total number of MT SM sent by the SMSC
smsc.mt-sr Total number of MT status report sent by the SMSC
Total number of MO messages properly handled by
smsc.mt-ack
the SMSC
smsc.mt-error Total number of rejected MO messages
smsc.mt-packet-mo Total number of MO acknowledgments sent on the

network
smsc.mt-packet-mo Total number of MT messages sent on the network
Counters for messages that expired and deleted messages
smsc. expired Total number of expired messages
Total number of expired messages to be charged by
smsc. expired-prepaid
prepaid subscribers
Total number of expired messages to be charged by
smsc. expired-postpaid
postpaid subscribers
smsc. cancelled Total number of cancelled messages
Total number of cancelled messages to be charged
smsc. cancelled-prepaid
by prepaid subscribers
Total number of cancelled messages to be charged
smsc. cancelled -postpaid
by postpaid subscribers
Counters for internal registers (used mainly for debugging and system monitoring)
Total number of bits sent to the SIU (not a very
smsc.link-bps
useful indication, kept for historical reasons only)
Total number of times the configured link capacity
was reached. If this counter is incrementing, the link
smsc.link-full
value should be set to 0 in the GMSC configuration
of the smsc_conf.ini, to disable the limitation
Total number of messages that were rescheduled for
smsc.retry delivery attempt on next retry time due to a
congestion
smsc.mref Absolute value the number of referenced messages
Total number of attempts to reference a new
message will the reference window is full. If this
smsc.mref-full
value is incrementing, this means that the system is
working on its maximum configured capacity
Total number of reference messages passed to the
smsc.mref-tx
TX process for delivery
smsc.mref-tx-entry Internal counter
smsc.mref-tx-rt Internal counter
Total number of messages to be referenced while
smsc.mref-conflict another message to the same msisdn is already
referenced
smsc.mref-normal Number of normal messages referenced
smsc.mref-retry Number of retry messages referenced
smsc.mref-brdcst Number of broadcast messages referenced
smsc.reference Total number of times referencing new messages
smsc.reference-rt Round trip time for referencing new messages
Total number of MT messages sent to the TX process
smsc.send
for delivery
smsc.send-rt Round trip time to send messages to the TX process
smsc.reference-normal Number of normal messages referenced
smsc.reference-retry Number of retry messages referenced
smsc.reference-normal-rtt Round trip time referencing normal messages
smsc.reference-retry-rtt Round trip time referencing retry messages
Overflow Counters
smsc.overflow-store Total number of overflow messages stored
smsc.overflow-store-sms Total number of overflow SM stored
Total number of overflow MO SM stored due to
smsc.overflow-store-sms-mo
service centre congestion
smsc.overflow-store-sr Total number of overflow SR stored
smsc.overflow-load Total number of overflow messages re-loaded
smsc.overflow-load-sms Total number of overflow SM re-loaded
smsc.overflow-load-sr Total number of overflow SR re-loaded
ESME traffic Counters

Total number of messages exchanged between the

smsc.esme
SMSC and all the ESMEs
smsc.eo-total Total number of messages submitted by ESMEs
Total number of messages destined to an ESME
smsc.et-total (messages and delivery reports)
et-total=et-sms + et-sr
Total number of deliver messages destined to an
smsc.et-sms
ESME
Total number of delivery report messages destined
smsc.et-sr
to an ESME
Applications Status Counters
smsc.aim-alive Status of the SMPP server aim process
smsc.emi-rx-alive Status of the EMI receiver server process
smsc.emi-tx-alive Status of the EMI transmitter server process
smsc.sema-rx-alive status of the SEMA Receiver server
smsc.sema-tx-alive Status of the SEMA transmitter server process
smsc.sema-trx-alive status of the SEMA Transceiver server
smsc.cimd_alive status of the CIMD server
smsc.prepaid-tx-alive Status of the prepaid process
smsc.prepaid-tx Total number of prepaid messages charged
smsc.check-prepaid-tx-alive Status of the check prepaid process
smsc.check-prepaid-rx Total number of check credit requests received
smsc.check-prepaid-tx Total number of check credit request sent
Prepaid Counters
smsc.prepaid-tx-charge number of charge messages sent to prepaid platform
number of reserve messages sent to prepaid
smsc.prepaid-tx-reserve
platform
number of commit messages sent to prepaid
smsc.prepaid-tx-commit
platform
total number of responses received from the prepaid
smsc.prepaid-rx
platform
number of positive responses received from the
smsc.prepaid-rx-ack
prepaid platform
number of error responses received from the prepaid
smsc.prepaid-rx-err
platform
round trip time between sending the request to rtcg
prepaid-rtcg-rtt
and the response (for version 5)
Table 4-2 Jinny SMSC Static Counters
Note that additional static counters might be present. The will be for
internal use (debugging and additional information on internal functions).

4.9.2. Dynamic Counters

The SMSC creates a set of dynamic counters for connection related
information: GMSC connection counters, ESME counters, prepaid charging
counters.
GMSC connection dynamic counters are used to monitor the state of the
SMSC-GMSC connection. A counter is created for each GMSC defined in the
smsc_conf.ini
Counter Name Description

Alive counter for an SMSC-GMSC
smsc.gmsc<nb>-conn-alive connection.
<nb> value = GMSC index - 1
ESME dynamic counters are created at the first connection with an ESME
client.

Total number of messages submitted by
smsc.eo-<esme>
the ESME transmitter client
Total number of messages destined to the
smsc.et-<esme>
ESME receiver client
Total number of deliver messages
smsc.et-<esme>-sms
destined to the ESME receiver client
Total number of delivery report messages
smsc.et-<esme>-sr
destined to the ESME receiver client
smsc.<esme>-<type>-alive Status of the client
Table 4-3 Counters
The <esme> value depends on the configuration of each ESME client and
the interface used:
Interface ESME value

SMPP System_id
EMI Description
SEMA Description
Table 4-4 Interfaces
The <type> value depends on the type of the connection with the client:
Type Description
rx Receiver
tx Transmitter
trx Transceiver
Table 4-5 Types

Prepaid IN dynamic counters are created for each connection to the RTCG.

smsc.prep-i<inst>-c<nb>-
Alive counter for the connection
alive
smsc.prep-i<inst>-c<nb>- Number of transaction Ids currently used.
nbopentx This is an absolute value counter.
The round trip time (in ms) for a
smsc.prep-i<inst>-c<nb>- request/response. To get the average
rtcg-rtt delay, this value should be divided per
number of responses received
smsc.prep-i<inst>-c<nb>-rx Number of responses received
smsc.prep-i<inst>-c<nb>-tx Number of requests sent
With:
Instance as set in the instance
configuration parameter in the
prepaid_in.ini (0 by default). This value
<inst>
should be set if multiple prepaid_in
instances are running on the same
machine
Number of the connection, starting 1. If
multiple rtcg nodes are defined, the
number is added for each connection
defined. For example
[rtcg_nodes]
<nb> #<index>=<nb of connections> <cycle
hosts> [<host1> <port1> <host2>
<port2>...]
1=3 1 test 4044
2=3 1 test 4044
The <nb> will have values 1 to 6.

4.9.3. Counters Hierarchy

Most counters can be grouped together. They usually share the same
prefix. For example: mo-submit, mo-submit-esme, mo-submit-mt,
Where the mo-submit counter is considered as the parent counters, and
the rest as children counters.
The most significant parents and their children are listed below:
mo-total mo-submit + mo-command + mo-alert + mo-ack +

mo-error
mo-submit mo-submit-gsm + mo-submit-cdma + mo-submit-
tdma
mo-submit-mt + mo-submit-esme
mo-ack mo-ack-sms + mo-ack-sr
mo-ack-intrntl + mo-ack-local
mo-error mo-error-sms + mo-error-sr
mo-error-interntl + mo-error-local
mo-eror-reason-fail + mo-error-reason-noreply + mo-
error-reason-memfull + mo-error-reason-other
mt-total mt-deliver + mt-ack-mt-error
mt-deliver mt-deliver-mo + mt-deliver-esme
mt-deliver-retry + mt-deliver-storefwd + mt-deliver-
direct
mt-deliver-sms + mt-deliver-sr

5. MESSAGE HANDLING
This document defines a message as one of the following events:
Mobile Originated Short Message submitted to the SMSC.
Mobile Terminated Short Message delivery attempt by SMSC to a
mobile.
Report message delivery attempt by the SMSC to a mobile.
Short Message submitted from an ESME to the SMSC.
Short Message delivery attempt to an ESME by the SMSC.
Report delivery attempt to an ESME by the SMSC.
Appendix 15.1 includes flow charts describing the SMSC message handling
processes.
5.1. Short Message Mobile Originated

The SMSC processes every short message received according to the
following procedure:
The SMSC translates the originating address to an international format
using the originating address translation file defined for the SMSC in
the configuration file (rx_translation_file).
If the source checking flag (src_restriction) is set in the
configuration file, the MO IMSI is available, and the src_imsi_range is
set, the SMSC checks the IMSI against that range. Otherwise, the
SMSC checks the translated address against the regular expression
defined under the source routing expression entry (src_routing_exp).
If the check finds a match:
The SMSC further checks the MO address against an MO blacklist (if
mo_black is enabled in the configuration file). If the MO blacklist
contains the MO address, the SMSC rejects the message.
If the check does not find a match:
The SMSC checks the MO address against a white list (if mo_white
is enabled in the configuration file).
If the MO address is not found in the list, the SMSC checks the MT
address against the irregular MO to MT list (if mt_white is enabled).
If the white list does not contain the address, the SMSC rejects the
message.
If the charge_prepaid is enabled, the MO profile is checked to see if
the subscriber is an on-hold prepaid. If this is the case, the message is
rejected.
If the MO number is part of a Closed User Group, the MT address is
checked against the CUG list. If not found, the message is rejected.
If the SMSC accepts the originating address, it checks the resulting
destination address against all the address ranges defined for the
ESMEs. If the destination address matches one of the address ranges,
the SMSC checks if the ESME requires a source address checking. If the
originating address is allowed to use the service (source checking not
enabled or originating address matches the Source Address Range
defined), the message is routed to the appropriate ESME using the
corresponding connection.
If the destination address doesnt match any address range, the SMSC
checks it against either the Group Command or Embedded Command
Message addresses.
If it matches a Group Command address, the SMSC further checks if
the Group Command facility is supported and if the MO is a subscriber.
If so, the SMSC adds the message to the Group Command Queue.
If the destination address matches any MO to Embedded Command
Address, the SMSC further checks if the Embedded Command facility is

supported and if the MO is a subscriber. If so, the SMSC verifies the

validity of any Embedded Command process and routes the message.
If there is no match in either case (the Group Command or Embedded
Command Message) the SMSC considers the message as an MT
message and processes it in accordance with the Short Message
Terminated procedure.
Table 5-1 below shows a list of Mobile Originated errors in GSM networks.
The mapping of error causes between Relay Protocol (included in the MAP
protocol) layers is also shown.
Failure Return MAP

Error Return MAP Diagnostic
Description Cause
Facility Not (5) Invalid Short Message
21
Supported (32) Short Entity Address
Mobile Station Not Message
28 (6) Not Subscribed
Subscribed Delivery
Service Centre Failure (4) Service Centre
42
Congestion Congestion
Table 5-1 MO Errors in GSM networks
Table 5-2 shows the list of error cause returned for rejected SMS delivery
Point-to-Point received by the SMSC in CDMA/TDMA networks.
Error Description
2 network resource shortage
98 sms termination denied
97 sms origination problem
100 sms not supported
102 missing expected param
Table 5-2 MO Errors in CDMA/TDMA networks
5.2. Short Message Mobile Terminated

The SMSC handles mobile terminated short messages as follows:
1. The SMSC translates the destination address to a valid network address
in accordance with the destination address translation file,
tx_translation_file, defined in the SMSCs configuration file. This
translation adds the necessary prefixes to the destination address in
order for the SMSC to route it to the appropriate destination.
2. The SMSC also translates the destination address to another value
using the originating address translation file rx_translation_file.
The SMSC stores this value separately from the first value. This
translation normalizes all the destination addresses into the same
format for use by internal processes within the SMSC.
3. If dest_restriction is enabled, the SMSC checks the translated
address against a regular expression to filter out unwanted addresses.
The SMSC administrator defines the regular expression in the
configuration file using the variable dest_routing_expr.
4. If the address does not match the value of the regular expression:
The SMSC checks the address against an MT white list (if mt_white
is enabled).
If the MT white list does not contain the address, the SMSC checks
the MO address against the MO to irregular white list (if mo_white is
enabled).
If the address fails these checks, the SMSC rejects the message.
5. If the address matches the value of the regular expression:

The SMSC checks the address against an MT black list (if mt_black
is enabled). If found, the message is rejected.
6. The MO address is then checked against the Blocked list of the MT
address. If found, the message is rejected.
7. If the message passes the above checks, the SMSC accepts it for
sending.
8. If the reject-duplicates flag parameter is set, the SMSC checks if
another message matching the same originating address, destination
address and mref, is still pending. If found, the message is accepted
but its content is discarded.
9. The SMSC then checks if the Embedded Command process is enabled
(allow_embedded_cmd set).
10. If not, the SMSC checks the message originator address to see if it is in
the VIP MO white list. If so, the SMSC automatically assigns the
message a priority status and moves it to the front of the SMSCs
message waiting queue.
11. However if it is not a Priority message (or if the global_priority_flag
is not set) then the SMSC checks the database table of MT addresses
with messages waiting to see if other messages are waiting for this MT
address to become reachable.
12. If there are messages waiting for this MT address and the message is
not a priority message then the SMSC adds the message to the
messages table in the database.
13. If the message is a priority message or the address does not have any
other messages waiting for it, the SMSC sends the message to the
Mobile Station via the Gateway MSC function on the Signalling Interface
layer. (The customers purchased license determines the rate at which
the SMSC sends the messages to the Signalling Interface.)
14. If the Embedded Command process is enabled, and if the MO address
matches any Embedded Command user, the SMSC checks if a
command is embedded in the message and processes the message
accordingly.
15. The mobile network will return a response indicating if it successfully
delivered the message or not.
16. If the message reaches a final status, the SMSC generates a delivery
report, upon request, and sends back to the originating SME.
17. If the SMSC could not temporarily send the message (mobile out of
coverage, or memory capacity exceeded), then the SMSC sets all the
messages destined to the same MS to waiting, and (unless the
message is in datagram mode message) adds the destination address
to the retry algorithm.
Table 5-3 below shows a list of Mobile Terminated errors in GSM networks.
It also shows the failure diagnostics.
Error Description
1 Subscriber Unknown
5 Subscriber Unidentified
6 Absent Subscriber 0 = no paging response via the MSC
SM (Map phase 3) 1 = IMSI detached
2 = roaming restriction
Diagnostics 3 = deregistered in the HLR for non
GPRS
4 = MS purged for non GPRS
5 = no paging response via the SGSN
6 = GPRS detached
7 = deregistered in the HLR for GPRS
8 = MS purged for GPRS
9 = Unidentified subscriber via the
MSC

10 = Unidentified subscriber via the

SGSN
9 Subscriber Illegal
11 Tele Service Not Provisioned
12 Equipment Illegal
13 Call Barred
20 Error in Mobile Station
21 Facility Not Supported
22 Memory Capacity Exceeded (MAP Phase 1)
27 Subscriber Absent (MAP Phase 2)
29 No Reply from Subscriber (MAP Phase 1)
30 Mobile Station Busy for Mobile Terminated Messages (MAP
Phase 1)
31 Subscriber Busy for Mobile Terminated Messages (MAP
Phase 2)
0 = Memory Capacity Exceeded
Short Message Delivery
1 = Equipment Protocol Error
32 Failure (MAP Phase 2)
2 = No Short Message
Diagnostics
Equipment
34 System Failure
35 Missing Data
36 Unexpected Data Value
Table 5-3 MT Errors in GSM networks
For CDMA/TDMA networks, the errors returned for MT messages are

mapped into their corresponding GSM errors. This has been done to unify
the errors on the SMSC. Table 5-4 below shows the mapping of errors
between IS-41 errors and SMSC application level.
Note: To simplify the interpretation of errors, only the GSM set of errors is used
in the database and transactional log files (DAT files), for both GSM and
CDMA/TDMA networks.
Error Type CDMA/TDMA Error SMSC Error

Network problems
0 address vacant 35 data missing
1 address translation failure 150 address translation failure
2 network resource shortage 37 resource limitation
3 network failure 34 system failure
4 invalid teleservice ID 11 teleservice not provisioned
5-31 other network problem 34 system failure
Terminal problems
32 no page response 46 map no subscriber reply
Sms cause 33 destination busy 30 ms busy for mt sms
code 34 no ack 21 facility not supported
35 destination resource 22 memory capacity exceeded
shortage 20 error in ms
36,48-63 sms delivery 27 absent subscriber
postponed 1 unknown subscriber
37 destination out of service 20 error in ms
38 destination no longer at
this address
39-47 other terminal problem
Radio interface problems

64 radio interface resource 37 resource limitation

shortage 34 system failure
65 radio interface 34 system failure
incompatibility
66-95 other radio interface
problem
General problems
96 encoding problem 36 unexpected data value
97 sms origination problem 13 call barred
98 sms termination denied 13 call barred
99 supplementary service not 21 facility not supported
supported 21 facility not supported
100 sms not supported 34 system failure
101 reserved 35 data missing
102 missing expected param 35 data missing
103 missing mandatory 36 unexpected data value
param 36 unexpected data value
104 unrecognized param 36 unexpected data value
value 36 unexpected data value
105 unexpected param value
106 user data size error
107-255 other general
problems
129 unrecognized MIN 1 unknown subscriber
130 unrecognized ESN 12 illegal equipment
131 MIN-HLR mismatch 1 unknown subscriber
132 operation sequence 145 operation rejected
problem 37 resource limitation
133 resource shortage 21 facility not supported
134 operation not supported 37 resource limitation
User error
135 trunk unavailable 36 unexpected data value
136 parameter error 34 system failure
137 system failure 36 unexpected data value
138 unrecognized parameter 21 facility not supported
value 35 data missing
139 feature inactive
140 missing parameter
1 duplicate invoke_ID 131 dialogue busy
2 not supported service 21 facility not supported
3 mistyped param 36 unexpected data value
4 resource limitation 37 resource limitation
Provider 5 initiating release 38 initiation release
error 6 unexpected response from 147 return result error
peer 143 end without result
7 service completion failure 143 end without result
8 no response from peer 147return result error
9 invalid response received
1,5-63 denied 1 unknown subscriber
Access
2,64-127 postponed 27 absent subscriber
denied
3 unavailable 27 absent subscriber
reason
4 invalid 11 teleservice not provisioned
Table 5-4 Mapping of errors between IS-41 and SMSC errors

5.3. Network Interconnect

The Jinny SMSC can connect simultaneously to the GSM/iDEN and
CDMA/TDMA networks. It will need to connect to at least one SIU with a
GSM implementing the GSM MAP and underlying layers, and another SIU
with the IS-41 MAP and underlying layers. All the functionalities and
services provided by the JSMSC are available for both network types.
The JSMSC can handle inter-network messages and apply the appropriate
conversions from GSM, CDMA or TDMA to GSM, CDMA or TDMA messages.
A special conversion is made also for GSM to iDEN network.
Routing to each network is based on:
Address range.
Subscribers profile.
An intelligent error detection and retry method.
When the message reaches the sending module:
The profile of the destination address is checked. If the network type is
specified for that number, it will be considered the destination network.
Otherwise, the number is checked against the GSM, CDMA, TDMA and
iDEN address ranges (gsm_address_range, cdma_address_range,
tdma_address_range and iDEN_address_range configuration
parameters), and the message is considered destined to the network
associated with the correct address range (the GSM network is the
default network type).
If the JSMSC detects that there is no connection to the destination
network, the message will be added to the waiting list.
If a connection is established, the message is sent to the chosen
network type.
If the destination number is not recognized by the chosen networks HLR,

the message is retried on other networks (if available), and the
subscribers network type in his profile is automatically updated if
successfully delivered.
For GSM to iDEN network, the following conversion rules are applied:
If GSM message is received with 7-bit alphabet encoding, the dcs is set
to 0xF7 and the message is converted to 8-bit text.
If GSM message is binary with dcs in the range 0xF4 to 0xF6, the dcs is
set to 0xF8.
If GSM message is received with dcs = 0xF7, no changes are made
If GSM message contains a user data header, the administrator can
choose to remove the user data header, or keep selected information
elements: concatenated info, application port 8-bit and application port
16-bit.
The total length of the converted iDEN message is limited to 140 bytes
(or as configured). The SMSC will truncate exceeded length.

Fig 13 - Send an available message
Get Network Type
Destination address
Get profile
Profile network type

Yes
specified?
Return
network
type No
Address matches
Yes gsm_address_range
?
Return
GSM No
Address matches
Yes cdma_address_rang
e?
Return
CDMA
No
Address matches
Yes tdma_address_range
?
Return
TDMA
No
Return
GSM
Fig 14 - Get network type algorithm

5.4. Background Sending Mode

The Jinny SMSC introduced the background sending mode feature in order
to eliminate the interference between normal messages and lower priority
messages such as broadcast messages which are not real-time messages.
This mode works by specifying values for two parameters in the SMSCs
configuration file. The parameters are: mref_size and messages_winlen.
The first one specifies the maximum number of messages to send at a time
to all GMSCs, and the second one determines the percentage of normal
messages within that number. The remaining percentage is for the retry
messages and lower priority messages.
The SMSC dynamically regulates the sending of normal and lower priority
messages. If the number of normal messages is less than the allotted
percentage, the SMSC fills up the gap with lower priority messages.
For mref_size of 1024 messages, a messages_winlen of 70 and a full load
mode with no retries (retry_winlen = 30 but does not affect the
calculations), the SMSC will send the messages as follows:
716 normal messages ( = 1024* 0.7)
308 broadcast messages ( = 1024 716)
5.5. High Priority Sending Mode

Messages are considered as high priority messages when one of the
following is verified:
The messages are submitted by an ESME with the priority flag set.
The originator or destination address is a VIP.
These messages benefits from the following special handling:

They are processed and sent before normal and background messages.
A special retry sequence (smsc_priority_retry entry) is applied to
priority waiting message.
They are sent to the PLMN with the Priority information element set
(GSM networks only).
The PLMN behaves differently for a non-priority message than for a priority
message:
Delivery of a non-priority message will not be attempted if the MS has
been identified as temporarily absent.
Delivery of a non-priority message will be attempted if the MS has not
been identified as temporarily absent irrespective of whether the MS
has been identified as having no free memory capacity.
Delivery of a priority message will be attempted irrespective of whether
or not the MS has been identified as temporarily absent, or having no
free memory capacity.
For GSM networks that suffer from coverage problems, the system can be
configured to send all messages to the PLMN with the priority flag set
(gsm_priority configuration param).

5.6. Retry Algorithm

Short Message delivery attempts to mobile subscribers frequently fail due
to factors outside the control of the SMSC. The common reasons for failure
are:
Destination subscriber is unreachable.
SIM card on the destination handset is full and can accept no more
short messages.
No response was received back from the network (network problem or
no response from an international network element).
The SMSC saves the messages that have failed at the first delivery attempt
into the database. It will reattempt their delivery at a later time according
to a configurable retry algorithm. The algorithm implements the following
logic:
The SMSC translates the destination address to an international
number using the originating address translation file defined by the
value of the rx_translation_file entry in the SMSC configuration
file. The SMSC uses this value for its internal message checking.
If the message failed with system failure, the SMSC matches the
resulting address against the value used for filtering local mobile
terminated addresses. The SMSC stores this value in the
local_routing_expr parameter as a regular expression in the
configuration file. (Section 0 contains examples and usage of UNIX
regular expressions). The SMSC appends the destination address to the
waiting table and initiates a retry sequence based on the
smsc_foreign_retry sequence.
If the above is not verified, the SMSC appends the destination address
to the waiting table and initiates a retry sequence. The retry algorithm
uses the retry sequence defined by the ESME retry sequence, error
type or the smsc_retry entry by default, or the smsc_priority_retry
entry in the configuration file based on the priority flag of the message.
Then at each unsuccessful delivery, the retry algorithm increments the
number of retries and sets the next retry time accordingly. The SMSC
will resend the message until it delivers it or its validity period expires
at which point it deletes it.
Note that if the address is local and if the number of retries exceeds the
number specified by the retry sequence, the next retry time will be the last
one specified. The retry algorithm will use this last value indefinitely. If the
address is foreign and the number of retries exceeds the number specified
by the retry sequence, the retry algorithm updates the status of the
messages for that address from waiting to error and will remove the
address from the retry algorithm table.
Starting release 3.6, each retry sequence is paired with an alternative
overload retry sequence: (smsc_retry, smsc_overload retry),
(smsc_priority_retry, smsc_overload_priority_retry),
(smsc_foreign_retry, smsc_overload_foreign_retry). These
sequences will be used when the retry queue reaches a certain percentage
(overload_level).
The following SDL flowchart is an illustration of the above:

Retry Sequence
system_failure
No
?
Yes
foreign
No
number?
Yes
enable_esme_r
No
etry_seq
overload_level
No
reached?
Yes
Yes message from

No
ESME
use use
smsc_overload_for smsc_foreign_retr Yes
priority
eign_retry y No
message?
overload_level
reached? No
Yes
overload_level
Yes
reached?
No
overload_level
use reached?
use
esme_overload_re No
esme_retry_seq
try_seq
Yes
use
use Yes
smsc_overload_pri
smsc_priority_retry
ority_retry
use
smsc_overload_ret use smsc_retry
ry
Fig 15 Retry Sequence
5.6.1. Retry Sequences

The retry sequence is a series of pairs: (number of retries, interval in
minutes). The sequence can have a maximum length of 256 characters.
The first number of each pair specifies the number of attempts to resend a
SM and the second number specifies the time in minutes between each
attempt. If the delay is set to 0, the retry sequence will end, the messages
waiting are removed, and the number is removed from the waiting list.
When the sequence ends, the last pair (number,interval) is used until the
message reaches a final status.
Example
smsc_retry = (1, 5) (1, 8) (5, 15) (10, 30) (100, 1440)
The retry sequence means that the SMSC performs:
the first retry attempt on a normal message after five minutes
the second one after eight minutes
Five next retries after 15 minutes each
Ten retries with half an hour interval
Daily retry for the next 100 days

5.7. More Messages to Send

If more than one message (SM or SR) is pending for delivery to a certain
number, the messages can be delivered to the network with the variable
mms (more message to send) set. Using mms has the advantage of
alleviating the network from unnecessary traffic. So instead of getting the
routing information from the HLR for each message, the information is
requested only once, and all the pending messages are forwarded directly
to the MSC. This option can be enabled/disabled using the mms_flag
configuration parameter.
5.8. Restricting Mobile Originated and Terminated Addresses

The SMSC restricts mobile originating and terminating short messaging
services based on matching mobile originating and mobile terminating
addresses with the src_routing_expr and the dest_routing_expr regular
expressions defined in the smsc.ini file. For the Mobile Number Portability,
a new parameter was introduced, src_imsi_range, which is used to filter
out unauthorized MO imsi numbers (if available). The SMSC uses these
parameters to allow ranges of numbers (such as all national or regional
numbers). The administrator defines these parameters by using the SMSC
administration web interface.
In addition, the SMSC uses:
White and black lists to allow or bar individual addresses from
receiving/sending messages on a system wide basis.
CUG and Blocked list to allow or bar individual addresses from
receiving/sending messages on a subscribers level.
The provisioning is done either by using the admprofiles command line
tool or using the SMSC administration web interface.
Note that the administrator can turn off, on a system wide basis, the use of
the source and destination restrictions and all the MO and MT white and
black lists by using the src_restriction, dest_restriction,
src_imsi_range, mo_white, mo_black, mt_white and mt_black flags
respectively.
5.8.1. MO White and Black Lists

The administrator allows individual mobile originated numbers that do not
match the source routing expressions to access the service by adding them
to one or both of the SMSC MO white lists:
MO white list. This list allows MO numbers that do not match the
src_routing_expr or src_imsi_range to send Short Messages.
MO to irregular MT white list. This list allows MO numbers to send SMS
to MT addresses which would normally be barred from receiving
messages because they are not in the range of the dest_routing_expr
regular expression.
There is also an MO black list that enables the SMSC to blacklist individual
unrelated lists of originating numbers. This is useful in situations where
configuring the src_routing_expr or src_imsi_range parameters are not
appropriate.
Note that if the source_restriction flag is not set then the SMSC checks
neither the src_routing_expr and src_imsi_range nor the MO white and
black lists.

5.8.2. MT White and Black Lists

There is an MT blacklist that enables the SMSC to blacklist individual
unrelated lists of destination numbers. This is useful in situations where
configuring the dest_routing_expr parameter is not appropriate
Similar to the MO individual restriction lists, there exist two types of MT
white lists:
MT white list. This list allows MT numbers that do not match the
dest_routing_expr to receive Short Messages.
MT from irregular MO white list. This list allows MT numbers to receive
SM from MO addresses which would normally be barred from sending
messages because they are not in the range of the src_routing_expr
or src_imsi_range regular expressions.
Note that if the dest_restriction flag is not set then the SMSC checks
neither the dest_routing_expr nor the MT white and blacklists.
5.8.3. ESME Restrictions

If enabled, all the originating address is checked against a source address
range, whether the message is a MO-ESME or ESME-MT. In the addition,
SMSC release 3.6 introduces an additional restriction on the ESME-MT
traffic: the MT address is checked against a destination address range. If
not set, the MT address has to match the dest_routing_expr set on the
SMSC.
5.8.4. Closed User Group

Only the administrator can manage the Closed User Group list. If enabled,
the subscriber will be restricted from sending messages to numbers outside
the CUG list. This feature can be very useful for special pricing packages.
Note that all the ESME services will not be accessible by short code, unless
the short code is defined in the CUG list.
5.8.5. Blocked List

The blocked list is used to block unwanted numbers from sending to a
certain subscriber. This list is accessed from the administration web pages,
and can be managed by the user using the BLOCK command.
5.9. Address Translation

The address translation is applied for every message handled by the SMSC.
There are 2 translation files used:
The first one is used to translate the originating and destination addresses
into an international format needed for profiling and internal searching
The other one is used to translate the destination address into the format
required by the operator for routing purposes on their network.
For each network type (GSM/TDMA/CDMA), a set of 2 translations files can
be set.
Note: For ESME routing, the destination address without translation is checked
against the routing table defined on the system
The address translation format is as follows:
<ton regular expression> <npi regular expression> <address regular

expression> <new ton> <new npi> <command> <command argument>
The command and its arguments are described in the table below:

Command Command argument Description

A <prefix> Append the prefix
AA <prefix size> Append to the destination
address the prefix of the
originating address.
This command is useful when

the SMSC is used to
interconnect regions, with
different country codes
R <old prefix> <new prefix> Replace the old prefix with
the new one
Example of a translation file:

0 [0-1] ^00 1 1 R 00
0 [0-1] ^0 1 1 R 0 961
0 [0-1] ^464[0-9]{4} 1 1 AA xxxx
Based on the previous sample translation file, the following numbers will be
translated as follows:
A party B party Translated B party

Dont care 0 1 009613xxxxxx 1 1 9613xxxxxx
Dont care 0 1 03xxxxxx 1 1 9613xxxxxx
1 1 1268464xxxx 0 1 464yyyy 1 1 1268464yyyy
5.10. Lawful Interception

The lawful interception plays an important role in security and detecting
suspicious activities. It is usually enabled by the operator to allow official
parties to intercept short messages sent and/or received by certain
individuals. The lawful interception should be undetectable by the
originator and destination addresses.
To enable it, the following should be done:
An ESME should be available (a receiver is mandatory; a transmitter is
conditional based on the trace type).
Set the trace parameters in the profile of the number.
The operator has the ability to choose to send a copy of the message, or to
forward the actual message to the controlling receiver ESME. In the latter,
it is the responsibility of the ESME to censor messages and re-send allowed
messages through the transmitter ESME. In order to preserve the
information sent with the original message (for example if a status report
has been requested), the ESME should support the use of some optional
parameters defined by the protocol (for example, the user message
reference optional parameter in the SMPP protocol).
The operator can set the start and final date/time for lawful interception.

5.11. Trace
All the transactions made on the SMSC (MO, MT delivery attempt, Alerts,
ESME traffic), are logged into the transactional SMSC history file. Each
transaction line contain all the parameters for a transaction (refer to
SMSC History File). Direct access to the history files can take a lot of the
system resources, and the output needs to be parsed to get the
information needed. To address this issue, in the latest 3.6 releases, the
jindex tool can optionally be installed to create indices for the originating
and destination addresses. It will provide a quick access to any number
inside the history files. A jtrace tool has also been implemented to access
the indices and retrieve the information required with a simplified or
extended display. The web interface has been optimized to base its search
on the indices resolving the delay issues previously faced on a heavy load
system. For more information about the jindex and jtrace command lines,
please refer to the administrator guide document.
5.12. Last Resort Address

Starting release 3.6, each user can set a last resort address used to receive
messages that failed to be delivered within the validity period. The user
can choose to receive the expired messages to one of the last resort
address types:
FAX.
SMTP (email).
The configuration of the last resort address can be done either from the
administration web pages, or directly from the users mobile using the LRA
command.
5.13. Overload Control Mechanisms

5.13.1. ESME Input Throttling
All ESMEs throughput rates to the SMSC are limited by the rate defined in
the purchased software license.
The operator can limit the throughput of each ESME connection to the
SMSC by setting the value of the throughput through the administrators
web interface. This throttling provides the operator to manage ESMEs in
accordance with its policies.
5.13.2. Anti-Spamming and MO Control

The SMSC imposes a limitation on the size of the pending messages queue
of any subscriber. If this limitation is exceeded, new messages are
rejected. The maximum allowed number of pending messages for a certain
subscriber is configured using the max_ready configuration parameter.
For originating ESME messages, the maximum number of messages
submitted to a single subscriber within a certain interval of time is limited.
The spamming regulation is defined in the ESME server configuration:
rglt_spam_rate, def_rglt_spam_ring_size.
For MT messages, the maximum number of waiting messages released to a
single subscriber is limited. The parameter is defined in the SMSC
configuration: max_free.
In addition to the above, the operator can choose to install the optional
Jinny Filtering Engine. It can be enabled to receive all incoming messages
and filter out spam or unwanted messages. Its configuration is based on

simple filtering rules created by the operator to meet its requirement. For
more information, please refer to the Jinny Filtering Engine documentation.
5.13.3. Background Messaging

Broadcast messages are handled in a different way from normal messages;
they are sent with a lower priority. The SMSC configuration parameters
affecting this mode are: messages_winlen and retry_winlen.
For more information, refer to section 5.3
5.13.4. Output Regulation

The SMSC output is regulated to a maximum rate, which prevents
overloading the signalling links. The limitation is affected by the following
parameters in the SMSC configuration: mref_size, sending_rate,
link_capacity, alternative_sending_rate. The mref_size, defined per
GMSC, specifies the maximum number of unacknowledged messages sent
to that GMSC at a certain time. The sending_rate (in number of messages
per second) regulates the number of messages sent to the network
through the defined connection. The alternative_sending_rate is the
sending_rate in case one of the connections to the SIUs is down. The
alternative_sending_rate is optional and in case it is not defined, the
sending_rate is unchanged. The link_capacity (in bps) should be set to
the maximum capacity allowed on the total of links configured on the
system. The administrator should note that the SMSC does not detect if the
traffic is not well balanced between the links.
5.13.5. Input Protection

If there is a burst of MO traffic that the SMSC cannot handle, messages are
queued in memory up to a certain limit. This ensures that short spikes in
traffic are handled properly. When the queue fills up, the extra incoming
messages are rejected. This keeps the SMSC running at maximum
capacity. The parameters are defined in the SMSC configuration:
primary_list_size, overflow_list_size, msg_list_size.
5.13.6. Overflow Mechanism

In a high traffic load situation, the following problems have the most effect
on the SMSCs performance:
Database bottleneck: when the number of failed messages increases
with the traffic, the database size increases (where the waiting
messages are stored). When this occurs, the database engine starts to
need more and more resources to manage the tables and each request
starts to take more time to execute.
Unbalanced traffic: if the SMSC is receiving more messages than it can
deliver (network delays, license or system limitation), it will get
congested and start rejecting new MO messages. The usual behaviour
of subscribers is to retry sending the rejected messages, increasing
more the incoming traffic.
Knowing that the SMSC consumes more resources as the activity increases
with the load, the above problems will degrade the SMSCs performance
and introduce delays. The SMSC can reach a point when it will no longer be
able to deliver its expected throughput. For this reason, an automatic
overflow mechanism has been introduced to alleviate the load on the SMSC
by storing the excess MO and waiting messages in an external database. At
off-peak time, these messages can be reloaded. The overflow mechanism
can be configured using the following configuration parameters:

overflow, overflow_congestion, overflow_jq_path,

overflow_jq_extent.
5.14. First Delivery Attempt

The Jinny SMSC can be deployed as a FDA (first delivery attempt) server.
The first delivery attempt approach means that the SMSC will not store the
message, and will directly attempt to deliver it. In case of failure, The Jinny
FDA server forwards the message to a centralized server (the JMR) for a
deferred delivery. The JMR is responsible of distributing intelligently the
messages towards the legacy SMSCs.
Since more than 60% of mobile terminated messages are delivered on the
first attempt, an FDA server maximizes by far the capacity of existing
legacy SMSCs.
5.15. Message Flow

5.15.1. Components
Fig 16 SMSC Components

Fig 17 MO MT Successful Delivery on First Attempt
Fig 18 MO ESME Successful Delivery on First Attempt (Database for ESME input)

MO - ESME Successful Delivery
SMSC
PLMN
SMSC RX
2
Process
5
3
RX MO SMSC RX ESME
4
Queue MO Process JQ
1
MO SM 5'
GMSC
MO ACK 6 7
7'
Mobile
Originated
MO Ack 11
TCP/IP
Queue Receiver
8 X.25
Deliver SM
10
9
SMSC TX ACK
6' Transmitter
Process
ESME
ESME
Server
Fig 19 MO ESME Successful Delivery on First Attempt (JQ for ESME input)
Fig 20 ESME-MT Successful Delivery (Direct)

Fig 21 ESME to MT Successful Delivery (Store and Forward)

5.15.2. Messaging
SMSC Messaging
Fig 22 MO to SMSC
Note: If the destination address of the terminated leg of the MO message is

mobile, then the message is stored in shared memory rather than the
database in most cases (Refer to the previous description of message
procedure).
Fig 23 SMSC to MT
Note: If the destination address of the terminated leg is mobile then the message
is stored in shared memory rather than the database in most cases (Refer
to the previous description of message procedure above).

SMSC - ESME - SMSC

ESME
ESME Queue AIM Receiver ESME ESME AIM Transmitter SMSC
(DB or JQ)
New Message / Delivery

Report
Submit New Message
Deliver New SM
Submit New SM
ACK
ACK
Update SM Status
Fig 24 SMSC to ESME Fig 25 ESME to SMSC
Network Messaging
SMSC GMSC HLR MSC MS
MessageTransfer
ForwardShortMessage
MessageTransfer
DeliveryReport
DeliveryReport
DeliveryReport
Fig 26 Successful Mobile Originating Short Message
MessageTransfer
SendRoutingInfoForSM
ForwardShortMessage
MessageTransfer
DeliveryReport
DeliveryReport
DeliveryReport
Fig 27 Successful Mobile Terminating Short Message

MessageTransfer
ForwardShortMessage
mms = 1
MessageTransfer
DeliveryReport
DeliveryReport
DeliveryReport
ForwardShortMessage
mms = 0
MessageTransfer
DeliveryReport
DeliveryReport
DeliveryReport
Fig 28 Successful Mobile Terminating Short Messages (using more message to

send)
MessageTransfer
InformSC
FailureReport
Fig 29 Failed Mobile Terminating Short Message due to an error at the HLR
MessageTransfer
InformSC
ForwardShortMessage
Fig 30 Failed Priority Mobile Terminating Short Message due to an error at the
HLR
Note: For priority messages, the message is forwarded to the MSC even the
number is set considered unreachable at the HLR

MessageTransfer
ForwardShortMessage
FailureReport
SetMessageWaitingData
FailureReport
Fig 31 Failed Mobile Terminating Short Message due to an error at the MSC
MessageTransfer
ForwardShortMessage
MessageTransfer
FailureReport
SetMessageWaitingData
FailureReport
Fig 32 Failed Mobile Terminating Short Message due to an erroneous message

transfer on the radio path

6. COMMANDS
6.1. Jinny SMSC Commands Overview
Release 2.9 of the Jinny SMSC introduced a set of features that helps the
operator differentiate its services offering. There are two categories of
features: the Group feature and the embedded features. The commands
used for these features are operator defined and can be coded in 7-bit
alphabet, binary or UCS2.
6.2. Group Feature

Using the Group feature, a subscriber can group peoples phone numbers
into lists. A short number identifies each group. Whenever the subscriber
wants to send a short message to the group of people, he uses the specific
group short number and the SMSC will deliver the message to all the
people in the group.
The SMSC administrator specifies the maximum number of groups that
each user can create. The maximum number of MSISDNs the subscriber
can include in the group list depends on the format of the MSISDN. The
group list is limited to 512 characters.
Note that the SMSC associates the groups with the group creators
MSISDN. As such, a user cannot use this feature from another users
MSISDN/Mobile.
The SMSC charges the user for each SMS sent to a user on the list. For
example, if a subscriber sends a short message to a group that consists of
five subscribers, the SMSC will charge for five short messages.
The Jinny SMSC provides a set of commands to manage groups: create and
delete a group, add and remove users from a group, and check for the
created groups and obtain the list of numbers in each group. The command
is followed by one or more MSISDNs. The GSM operator provides the
commands short number to which the user appends a group ID. This
number becomes the identification and destination number for the
appropriate group. The following sections assume that:
start character is *
stop character is #
end character is
the command is GROUP
the commands short number is 1444.
The Group commands format follows:
COMMAND <MSISDN LIST>
where COMMAND denotes the command for the appropriate feature.
6.2.1. Create Group

To create a group, the user sends the command *GROUP to the operator
specified command short number concatenated to the group ID. The
following example creates a Group with ID 1.
Subscriber creates a short message with the *GROUP as its content
The subscriber specifies the destination address as 14441 (commands
short number and group ID number)
If successful, the subscriber just created a group list. Otherwise, the
subscriber should check the commands syntax and the destination
number and send it again
The SMSC notifies the subscriber of the status of the group creation
operation whether it is successful or unsuccessful.

6.2.2. Add User(s) to Group

To add one or more users to a specific group, the user sends a message
containing the command *GROUP followed by the list of MSISDNs
separated by space to the appropriate groups destination address. For
example, a subscriber adds two MSISDNs to the first group by sending the
following message *GROUP 9613778899 9613844944 to 14441.
6.2.3. Remove User(s) from Group

To remove one or more users from a specific group, the user sends a
message containing the command #GROUP followed by a single or a list of
MSISDNs separated by spaces, to the appropriate groups destination
address. For example, a subscriber removes two numbers from Group 1
using the following command:
#GROUP 9613778899 9613844944 to 14441.
6.2.4. Delete Group(s)

A subscriber can either delete all the groups or a specific group. In order to
delete all the groups, the subscriber sends the #GROUP message to the
short address without any group ID concatenated to it. For example, the
SMSC deletes all of a users group by sending the message #GROUP to
1444. To delete one specific group, the user sends the #GROUP
message to the appropriate groups destination address. For example, the
SMSC deletes group 2 by sending the message #GROUP to 14442.
6.2.5. Check Groups

To check the created list of groups, the user sends the command
*#GROUP to the group commands destination address. For example,
when a user sends the *#GROUP message to 1444, the SMSC sends the
user all the Group IDs for all the groups the user created.
6.2.6. Check Group Users

To check the list of MSISDNS in a specific group, the user sends the
command *#GROUP to the appropriate groups destination address. For
example, when a user sends the message *#GROUP to 14443, the SMSC
sends the user the list of all the MSISDNs in that group. If the command
message contains a list of MSISDNs, the user checks whether they are
members of the group. For example, if a user sends the message
*#GROUP 9613778899 9613844944 to 14444, the user checks
whether those two MSISDNs are members of Group 4.
6.2.7. Send Message

To send a message to all users in a group, the user sends the message to
the groups destination address. For example, when a subscriber sends a
message to 14441, all the users listed under Group 1 will receive the
message.

6.3. Embedded Commands

They are contained in a short message. If the SMSC detects an
embedded command, it processes the message and removes the
command before sending the message to its final destination.
The subscriber manages his profile by either sending the commands to
an operator specified number or by the SMSCs administrator using the
web interface or the command line.
Fig 56 is a flowchart that describes the Embedded Commands process.
The Jinny SMSC provides a set of embedded commands for the mobile end
user offering several features for SMS messages. The command contains a
start, stop and end characters that the operator defines in the ini file. It
can also contain a combination of start and stop used for querying the
status of the command.
In some cases, one or more MSISDNs follow the command. They are
separated by space and are denoted by MSISDN LIST in the description
below. The list can be up to 256 characters long. The destination address is
either provided by the GSM operator or its the MSISDN of another mobile
subscriber. When the command contains a message, the user sends it to
an MSISDN.
In the following sections, the text between parentheses in the commands
title denotes the command and assumes that the destination address is
1444.
Note that the embedded commands use the * as the start command, the #
as the stop command and space as the end command. The SMSC
administrator can change the characters used for the start, stop, and end
by specifying them in the smsc.ini file.
6.3.1. SMS Calling Line Identification Restriction (CLIR)

This feature restricts the display of a short message originators number on
the receiving SME.
The user activates or deactivates it either per message or for all messages
basis. The user can also query the status of this feature. In addition, the
user can create a list of mobile numbers to which he can apply the feature.
The number of MSISDN entries in the list is limited so that the total list size
is less than 256 digits.
Activate command: *CLIR to 1444
*CLIR <MSISDN LIST> to 1444
Deactivate command: #CLIR to 1444
#CLIR <MSISDN LIST> to 1444
Check commands status: *#CLIR to 1444
*#CLIR <MSISDN LIST> to 1444
Apply command to a message: *CLIR <MESSAGE>
<MESSAGE> to an MSISDN on the
MSISDN LIST
#CLIR <MESSAGE> to an MSISDN on
the MSISDN
LIST to disable it for a single message
Note: Note that for security purposes, this command has to be enabled per
subscriber by the administrator or the customer care personnel using the
web administration pages

6.3.2. Delivery Reports (DR)

This feature allows the subscriber to request a delivery report for one or
more messages. He also checks the status of the feature and creates a list
of mobile numbers to which he can apply the feature.
Activate command: *DR to 1444
*DR <MSISDN LIST> to 1444
Deactivate: #DR to 1444
#DR <MSISDN LIST> to 1444
Status: *#DR to 1444
*#DR <MSISDN LIST> to 1444
Send: *DR <MESSAGE>
#DR <MESSAGE> to an MSISDN on
the MSISDN LIST
6.3.3. Message Status (MS)
This feature allows the subscriber to check the status of pending short
messages sent to a specific MSISDN. The SMSC sends back the number of
pending messages for the specified MSISDN.
Activate: *MS <MSISDN> to 1444
6.3.4. Cancel Pending Message (CPM)

This feature allows the subscriber to cancel any pending message sent to a
specific MSISDN or all his pending messages. The user knows of any
pending messages by using the feature Message Status.
Activate: *CPM to 1444
*CPM <MSISDN> to 1444
6.3.5. Future Message (FUTURE)

This feature allows the user to send a message and defer its delivery by a
maximum of 24 hours.
Activate: *FUTURE <HH:MM> <MESSAGE>
6.3.6. SMS Forwarding (FWD)

This feature allows a user to forward messages to an alternate number he
specifies. Prior to release 3.6, only temporarily undelivered messages are
forwarded (conditional forwarding). With this feature provisioned,
activated, and configured, the SMSC tries to deliver the message to the
subscriber. If this delivery attempt fails, it attempts delivery to the
alternate number. If this also fails, the message is scheduled for later
delivery to the original number.
Release 3.6 introduced the unconditional forwarding where all the
messages destined to the user are automatically forwarded to the
forwarding address regardless of the status of the users handset.
A default forwarding condition can be configured using the
default_forwarding configuration parameter. It is used to specify the
forwarding condition when a user activates its forwarding feature using the
FWD embedded command. Only the administrator/customer care can
modify the forwarding condition of a certain user.
Also starting release 3.6, the user has the option of forwarding his
messages to an email address. The FWD command is then followed by the
optional SMTP when specifying the email address. The user can also
choose to send a copy to the specified forward address, regardless of the
outcome of the delivery. The FWD command is then followed by the
optional COPY.
The operator can turn the feature on or off network wide.

Register: **FWD [<COPY>] [<SMTP>] <address> to

1444.
Activate: *FWD 1444
Register & activate: *FWD [<COPY>] [<SMTP>] <address>
Replaces register and activate steps.
Deactivate: #FWD to 1444
Status: *#FWD to 1444
*#FWD [<COPY>] [<SMTP>] <address> to
1444
6.3.7. Alias (ALIAS)

This feature allows the subscriber to create an alias for his MSISDN. This
alias is a string of a maximum of eleven alphanumeric characters that
replaces the MSISDN in SMS messaging. When the subscriber sends a
message, the receiver mobile handset displays the message as sent from
the sender alias rather than from the sender MSISDN.
Register: **ALIAS <Alias Expression>
Activate: *ALIAS 1444
*ALIAS <MSISDN LIST> to 1444
Deactivate: #ALIAS to 1444
#ALIAS <MSISDN LIST>
#ALIAS <MESSAGE>
Status: *#ALIAS
*#ALIAS <MSISDN LIST>
Send: <MESSAGE>
Note: Note that for security purposes, this command has to be enabled per
subscriber by the administrator or the customer care personnel using the
web administration pages
6.3.8. Auto Reply (AR)

The user edits an auto reply short message and sends it to the SMSC with
the appropriate command. The SMSC initiates the Auto Reply service for
this user. When a subscriber sends a short message to the Auto Reply
user, the sender automatically receives the Auto Reply message. At the
same time, the receiver receives the short message. Note that the
administrator can allow/block the recipient from receiving the message.
Register AR: **AR <MESSAGE> to 1444
Activate: *AR <MESSAGE> to 1444
Deactivate: #AR to 1444
Status: *#AR to 1444
6.3.9. Block (BLOCK)

Even though this command cannot be embedded in a normal MO/MT
message, it is managed using the embedded command address. It is used
to manage the Blocked list (Sec 5.8.5).
Activate command: *BLOCK <MSISDN> to 1444
Deactivate: #BLOCK to 1444
#BLOCK <MSISDN LIST> to 1444
Status: *#BLOCK to 1444
*#BLOCK <MSISDN LIST> to 1444

6.3.10. Last Resort Address (LRA)

Release 3.6 introduced the last resort address used to receive expired
messages. The user can configure the LRA type (FAX or SMTP) and address
(FAX number or email address) using this command. This command cannot
be embedded in a normal MO/MT message, it can only be sent by the user
to the embedded command address for the configuration of this feature.
The operator can turn the feature on or off network wide.
Register: **LRA <FAX|SMTP> <address> to
444.
Activate: *LRA 1444
Register & activate: *LRA <FAX|SMTP> <address>
Replaces register and activates steps.
Deactivate: #LRA to 1444
Status: *#LRA to 1444
6.3.11. Sponsor (SP)

The subscriber can use the Sponsor embedded command to
enable/disable sending messages to the Advertising Engine for sponsoring.
If the A-party sends a message containing this command, then the
message is sent to the JADE for advertising.
The A-party can also send an activation/deactivation message to the
embedded command address so this feature is enabled/disabled for all the
A-party messages. If the Sponsor feature is enabled for the A-party, then
all messages are sent to the JADE. In case the message is sent with the
Sponsor command, then the message is not sent to the JADE.
If the A-party's profile does not have the SPONSOR feature enabled and he
wants to use the SPONSOR feature:
Send *#SP <message> to B-party, and the message will be sent
to the JADE.
If the A-party wants to enable the SPONSOR feature in his profile:

Send *SP to the embedded command address, and the A-party will
receive a confirmation message.
If the A-party wants to send a message with advertisement (while the

feature is enabled in the profile):
Send <message> to B-party, and the message is sent to the JADE.
If the A-party wants to send a message without advertisement (while the

feature is enabled in the profile):
Send *#SP <message> to B-party, and the message is not sent
to the JADE.
If the A-party wants to disable the SPONSOR feature in his profile:

Send #SP to the embedded command address, and the A-party will
receive the confirmation message.

7. DISTRIBUTION LISTS
7.1. Introduction
Distribution lists is a feature that allows an operator or any operator
authorized DL user to easily distribute a single message to a large number
of subscribers.
Note: Starting release 3.0, the SMSC distribution lists can only be used in a
stand-alone architecture; for a distributed architecture, the Jinny
Application Routers distribution lists should be used instead in order to
distribute the traffic among the different MPUs.
The feature comprises the following elements:

DL users
DL files
DL messages
The SMSC provides two management interfaces to the feature: operator
and user. The SMSC provides its administrator full control, which overrides
the control of the user over the management of the distribution lists. The
administrator creates users, distribution lists and messages. The
administrator provides the user with a username and password for the user
to access and manage his distribution list(s). The administrator can limit
the number of distribution list messages submitted by the user.
The user submits the messages and the associated distribution lists
through the user web interface. The user can stop and resume the
distribution of a message or delete a distribution list.
The distribution list consists of a text file containing a list of users
MSISDN, each one on a separate line. Managing these files is done directly
or through the SMSC web interface. A batch loading consists of a simple
file transfer.
7.2. Process Context

SMSC
Database
Sig1 SS7
Mobile Network
SMSC DL
Web Interface SMSC GSM
Client
DL user
TCP
Sig2 SS7
N SMSC
DL Clients
FTP SMSC DataBase
SMSC
Database
Sig1 SS7
Mobile Network
SMSC DL SMSC DL SMSC GSM

SMSC DL
Queue Server TCP
DL files
Client
Sig2 SS7
SMSC
Database
Sig1 SS7
Mobile Network
TCP
SMSC DL SMSC GSM
Client
Sig2 SS7
Fig 33 - Distribution Lists context

7.3. Process Information

The SMSC DL process polls periodically the database for new DL messages
to be distributed. The DL messages can be submitted to the queue using
the SMSC web administration pages (administrator and authenticated
users), or using the admdl command line (administrator).
The message content can be dynamic where a % is added in the dynamic
part of the message. The SMSC DL process will recognize the % and will
form messages replacing the % with the value corresponding to each
MSISDN retrieved from the dynamic MSISDN list.
A child process is spawned for each DL message. It will be responsible for
distributing the messages to all the numbers in the list using the configured
schedule time of the list.
Using the server part of SMSC DL SERVER-CLIENT process, the messages
will be sent over TCP connection to the client side (the client part of SMSC
DL SERVER_CLIENT) that submits the messages to the Jinny SMSC.
A distribution can be stopped, resumed, or deleted.

SMSC DL Process
Hold the status of

all messages in
transaction
New DL
message?
Yes
DL
No
messageexpired?
Fork a child to handle

Yes
the message
Log and Delete

Message
No
Update the status of the
message in transaction
Store the child pid in the

smsc_dl.pid file
Check DL Children
Sleep for poll_timeout
Fig 34 SMSC DL Process


Fig 35 SMSC DL Child Process

7.4. Charging Information

The SMSC DL generates a record in the DL log filename at the following
events:
A DL message expires.
A DL message could not be processed (invalid or missing information).
Start of the processing of a DL message.
End of a DL message.
This file can be used to generate CPRs based on the operators
requirement.
In addition to the DL log file, if the DL user is configured to charge the
subscribers, a CDR record can be generated for each message submitted to
a number in the distribution list.
7.5. Dynamic Information

The SMSC DL process saves the information its need in the smsc_dl.pid
file. This file is located in the same directory as the configuration file. Its
internal structure is similar the standard ini file.
Section Entry Description

smsc_dl Pid Process id of the parent process
The entry is the internal identifier of the DL message
smsc_dl <messageid> currently in process. The value is the process id of the
processing child
The entry is the internal identifier of the DL message that
was suspended. The value is the start line in the
resume <messageid> distribution list file where the distribution should resume.
This entry is added if the process was interrupted or if an
error was encountered while processing the DL message

8. SMSC DISTRIBUTED ARCHITECTURE

8.1. Overview
Version 3.0 of the Jinny SMSC introduces a distributed architecture. The
Jinny Distributed SMC consists of a certain number of Message Processing
Units (MPUs) and a certain number of Signalling Interface Units (SIUs).
The MPUs functionalities are to:
Synchronize configuration and profiles between the primary and the
remaining MPUs.
Handle normal short messaging traffic (incoming and outgoing
messages).
Store waiting messages.
Handle statistics and charging.
The SIU functionalities are to:
Distribute incoming messages among MPUs.
Relay outgoing messages to the appropriate network element(s).
The MPUs and the SIUs connect to each other in a fully meshed
configuration.
MPU 1 MPU n
SIU1 SIUn
SS7
PLMN
Fig 36 - MPUs and SIUs Configuration

8.2. Configuration
The minimal configuration of the Jinny Distributed SMSC consists of two
MPUs and two SIUs. A larger configuration consists of the two MPUs and
the two SIUs and an additional number of similar components based on the
required throughput.
One of the two main MPUs is designated as Primary while the second is
designated as Secondary. If additional MPUs are present, they are simply
designated as clients MPUs. The Secondary MPU and the client MPUs, if
they are present, individually connect to the Primary MPU for
synchronization purposes. There are no connections among the client
MPUs. The Secondary and the client MPUs connect to the Primary using a
virtual IP address, which the Secondary takes over in case the Primary
fails. All MPUs are in the active state.
Each MPU connects to each of the existing SIUs, specifically to the instance
of the gateway SMSC instance running on it, thus forming a fully meshed
configuration.
In addition, the external short messaging entities connect to the Jinny
Application Router, which manages the connections to the MPUs. It acts as
a load balancer and, in case of a connection failure with an MPU or an MPU
failure, distributes its load over to the other MPUs.
8.3. Functionality
8.3.1. Message Processing Unit
Each MPU is considered as an SMSC node and holds the following data:
subscriber profiles, ESME configuration, services, messages, and waiting
messages. The data is divided in two: permanent (or hardly changing) and
constantly changing. The first one covers the profiles, ESME and service
configurations. The second one covers the messages and waiting
messages.
The Primary and Secondary MPUs have additional functionality than the
client MPUs. The Primary receives all the updates for the permanent data
(addition of an ESME, change of profile ), logs all the transaction updates
into log files, and sends this information to the other MPUs in the SMSC.
The logging of this information and its distribution to the other MPUs is
done in order to synchronize this information between all the MPUs.
Additionally, each MPU stores the messages and waiting messages
assigned to it by the rules on the GMSC.
8.3.2. Signalling Interface Unit

The Signalling Interface Unit is responsible for interfacing the MPUs with
the network elements. It holds the SS7 and MAP stacks, the MAP switch
(MAPX) and the GMSC.
The MAP switch is responsible for dispatching an incoming message to its
intended MPU destination. An MPU sends a message through a certain
GMSC and awaits a response from it. Whenever the response reaches a
different SIU, that MAP switch will forward it to the appropriate GMSC,
which in turn, sends it to the originating MPU.
The GMSC implements the Gateway MSC functionality as specified in the
ETSI standards.

8.3.3. Jinny Application Router (JAR)

The Jinny Application Router sits between the MPUs and the ESMEs. All the
ESMEs connect to the JAR as they would connect to an SMSC. In turn, the
JAR connects to each of the existing MPUs.
The JAR allows the operator to regulate the traffic on each ESME
connection to the MPUs by specifying its throughput. In addition, the
operator can also specify the throughput of each connection to the SMSC.
As such, the JAR provides complete flexibility in managing the load of the
external applications on the SMSC. In addition, the JAR provides for failure
management on the connections with the MPUs. If a connection with an
MPU fails, the JAR tags it as unavailable and routes the messages to the
other MPUs. If it comes back online, the JAR detects it and sends messages
through it.
8.4. Synchronization
As far as synchronization is concerned, the Primary MPU is considered as
the centre. Any change to the permanent data on the Primary is directly
executed by the Primary MPU. Otherwise, the Secondary and client MPUs
forward the requests to the Primary, which executes them. Upon
successfully executing a transaction, the Primary MPUs logs it into a
transaction log and then distributes it to the other MPUs. The Secondary
receives the transaction and stores it into two files: the transaction log and
the synchronization file. The Secondary keeps a copy of the transaction for
redundancy purposes in case of the Primarys failure. The remaining MPUs
store a copy of the last transaction they received and store it in a local file.
If the Primary fails, the Secondary takes over and assumes the
functionalities of the Primary as far as synchronization. On the other hand,
if a client MPUs fails for a certain period of time and then comes back
online, it uses the information in its synchronization log and compares it
with that of the Primary. If there are no differences, then the MPU is up-to-
date. Otherwise, it checks the difference and updates itself with the
missing information. On the other hand, if the synchronization file does not
exist on the client MPU (restart of a failed node) then the client MPU
performs a full synchronization.
8.4.1. Failure
Cluster management software runs on both the Primary and Secondary
MPUs. Both the Primary and the Secondary MPUs are assigned a single
Virtual IP address. This Virtual IP is active on the Primary. The other MPUs
connect to the Primary using this Virtual IP.
The software sends a heartbeat signal to check the health of the other
node. If the Secondary node does not detect the heartbeat signal from the
Primary, it assumes it failed and takes over. The heartbeat signal is sent
over two connections between the MPUs: Ethernet and serial connections
using cross cables. This double connection provides for connection
redundancy to account for connection failures rather than MPU failure.
Once the Secondary takes over, it takes over the Virtual IP address. In
turn, the client MPUs connect to the Secondary now turned Primary, using
the Virtual IP address, providing for a minimal interruption of services.
On the other hand, if the Secondary MPU or any client MPU fails, the
system takes no action other than to notify the operator of an MPU failure.

8.4.2. Restart Cases

The Jinny Distributed SMSC provides different cases of restarts:
Cluster restart.
Primary MPU restart.
Secondary MPU restart.
Client MPU restart.
A. Cluster Restart
As a general case, the Jinny SMSC cluster restarts in the following
sequence:
1. Synchronization of the Primary and Secondary MPUs
2. Assignment of Primary and Secondary status
3. Starting of services
When both the Primary and Secondary MPUs are restarting, they exchange
information in order to determine which MPUs have the most recent data.
The information exchanged is contained within counters that are described
later in the document.
The node that has the least recent data synchronizes its data with the
other. Once the data synchronization completes, both nodes change their
state to Secondary. Then, the cluster manager assigns Primary and
Secondary states to the appropriate machines based on how it is
configured.
B. Primary MPU Restart

In case the Primary MPU fails, the Secondary takes over and changes its
state to Primary. Once it restarts, it changes its state to Secondary. The
system can be configured where the failed Primary reclaims its Primary
state. Yet this configuration provides with unnecessary service interruption
and delays in bringing the SMSC online.
C. Secondary MPU Restart

If the Secondary MPU fails and it restarts, it goes back to assuming its role
as Secondary MPU. If, after a certain time, this MPU does not detect the
Primary node, it forces its state to Primary.
D. Client MPU Restart

If a client MPU restarts, it connects to the Primary MPU and performs the
synchronization process.
8.4.3. Synchronization processes

Process Description
This is the main synchronization process. It is
installed on both the primary and secondary nodes.
It detects the most up-to-date database at start-up
and synchronizes the nodes. An entry should be
jsync [--start|--stop|--status]
added to the /etc/rc3.d/ to start this process before
any other SMSC services (heartbeat). It will hang the
execution of other services until the node is
considered synchronized.
This is the file synchronization process that is
installed on both the primary and secondary nodes.
jfsync [-s | -c [-f filename]
It synchronizes the history files as well as the
general configuration files. It is started by inittab
It is the Database synchronization process. It is
installed on all nodes and is responsible for the
sync_db [-s|-c [-q]]
synchronization of the database.
On the primary node, it runs as a server distributing

transactions to all nodes.

On the secondary and client nodes, it runs as a
client, forwarding local requests to and executing
requests from the primary. It is started by the
heartbeat.
This is the cluster manager process that is installed
on both the primary and secondary nodes.
It is responsible for assigning roles to the MPUs,
Linux HA Heartbeat detecting failures, and starting some of the services.
An entry of this process should be added to the
/etc/rc3.d/ with a start number higher than the one
set for the jsync.
8.4.4. Synchronization files
File Description
This is the transaction log file. It contains
/var/jinny/messages/sync_info*.DAT all the requests successfully executed on
the local database.
This is the local transactional log file,
/var/jinny/messages/sync_local_info*.DAT which contains all the local requests to be
sent to the primary node.
External serial counter for the transaction
/var/jinny/shm/smsc_serial
identifiers used in sync_info file.
External serial counter for the transaction
/var/jinny/shm/smsc_local_serial
identifiers used for local requests.
This file contains information about the
/var/jinny/shm/sync_info transaction log: path, timestamp and
identifier of the last transaction executed
This file contains information about the
local transaction log: path, timestamp
/var/jinny/shm/sync_local_info
and identifier of the last transaction
forwarded to the primary
This file contains counters regarding the
number of times a node has been either a
primary or a secondary MPU. These
counters are very important and should
jsync counters
not be deleted in any case. They are used
by the jsync process on start to detect
the most up to date database and
synchronize the data.
Note: * denotes the date the file was created. It takes the form of yyyymmdd
where yyyy is the year, mm is the month and dd is the day.

8.4.5. Primary Node Procedures

A. Local Requests
Fig 37 - Primary Node Procedure: Local Request

A local request originates from:

Web admin interface.
Command line interface.
MO commands.
A txid is generated from the smsc_local_serial file and the request is
appended to the local transactional log (sync_local_info DAT file).
The sync_db process reads the request.
The request is executed. If successful, the local txid executed is saved
in the sync_local_info, a txid is generated from the smsc_serial file,
and a record is appended to the transactional log (sync_info DAT file)
The request is distributed to all nodes asynchronously.
B. External Requests
Primary Node Procedure: External Request
Primary Node
Database
2
sync_db
smsc_serial
sync_info DAT file
Secondary Node Client Node Client Node
Fig 38 - Primary Node Procedure: External Request

An external request originating from any other node is forwarded to the

primary node.
The Primary MPU executes the request. If successful a txid is
generated from the smsc_serial file, and a record is appended to the
transactional log (sync_info DAT file).
The request is distributed to all nodes asynchronously.
Each node, in its turn, executes the request.
8.4.6. Secondary Node Procedures

A. Local Requests
Fig 39 - Secondary Node Procedure: Local Request

A local request originates from an MO command

A txid is generated from the smsc_local_serial file and the request
is appended to the local transactional log (sync_local_info DAT file)
The sync_db process reads the request and forwards it to the primary
node. If successful, the local txid executed is saved in the
sync_local_info.
Fig 40 - Secondary Node Procedure: External Request
An external request is received from the primary node

The request is executed. If successful, it is appended to the
transactional log (sync_info DAT file) and its txid is saved in the
sync_info file.

8.4.7. Client Node Procedures

A. Local Requests
Fig 41 - Client Node Procedure: Local Request
A local request originates from an MO command

A txid is generated from the smsc_local_serial file and the request
is appended to the local transactional log (sync_local_info DAT file)
The sync_db process reads the request and forwards it to the primary
node. If successful, the local txid executed is saved in the
sync_local_info.

Fig 42 - Client Node Procedure: External Request
An external request is received from the primary node

The request is executed. If successful, its txid is saved in the
sync_info file.
8.4.8. Installation
Process Run by
Smsc Inittab
Prepaid Inittab
ESME servers (aim, emi, Inittab
sema)
Jfsync server Heartbeat
Jfsync client Heartbeat
Sync_db Heartbeat
Table 8-1 - Installation Processes Table

8.4.9. Process Information

Jfsync Client SDL
Fig 43 - jfsync Client

jfsync DAT Client
Connect to
Sleep connect_period
host:dat_sync_port
Connected? No
Yes
Get Sync
1
Read new messages

from clients (timeout)
New message? No 2
yes
Reset timer
Get Sync
HSK req Sync resp
resp
HSK rsp
Ack?
Set position to default

Set sync file position (current time, beginning
of file)
file opened? No Open file

Request sent? Timer >

yes
idle_timeout?
No
No Yes
HSK req
New sync record?
Sync req
Fig 44 - Jfsyn DAT Client


Fig 45 - jfsyn File Client
Jfsync Server SDL
Fig 46 - jfsync Server


Fig 47 - jfsync DAT Server


Fig 48 - jfsync File Server

9. CONFIGURATION
All the processes retrieve their configuration parameters from the
corresponding configuration file. The location of the configuration file is
jinny_dir/init with jinny_dir:
Value of the JINNY_DIR environmental variable
Home directory of the user jinny (default value)
The table below describes the parameters that are common for most of the
processes:
Entry Value Default Description

Main section of the process configuration
[ProgramName]
file
Logging and alarms parameters
ProgName X(30) The process name
The script that should be executed to send
AlarmProg X(255)
alarm messages
An alarm is generated for each message
logged with a debug level less than or
AlarmLevel 0 equal to the alarm level specified in the
[0-4] AlarmLevel entry of the application
configuration file.
Debug level (0 = critical, 1 = major, 2 =
DebugLevel 3
minor, 3 = information, 4 = debug)
LogFileName X(255) Full path of the log file
Logging can be either buffered or
BufferedLog 0
unbuffered
Database parameters
dbName smsc The clustered database server name
dbUser X(99) The name of the database user
dbPass The password of the dbUser
Used by Informix. THIS VALUE IS TO BE
dbErrorCmd X(255)
SET BY JINNY ONLY.
When set, it is used by Informix SQL query
optimizer to record how it decided to run a
particular query. Can be useful when
dbsetexplain [0,1] 0
designing programs involving large
database queries. THIS VALUE IS TO BE
SET BY JINNY ONLY.
Statistical parameter
/var/jinny/ The location of the file where the statistical
CounterFile X(255)
shm/counters counters are stored
License parameter
The software license. It is usually
generated based on:
Product name
License X(255) Hostid of the machine where the product is
installed
Expiry date
Maximum rate
The blocking license. It is usually
generated based on:
Product name
Hostid of the machine where the product is
BlockingLicense X(255)
installed
Expiry date
Maximum rate
It is set to the maximum capacity that the


system can provide. When reached, the
smsc will limit the traffic to avoid having a
system failure.
Table 9-1 Configuration Common Parameters
9.1. Main SMSC Configuration Files

The configuration parameters needed by the smsc process, are defined in 2
files:
smsc_conf.ini : Contains the local parameters specific for the current
node
smsc.ini : Contains the global parameters synchronized among all
the nodes in the system.
Note that after any modification made on some of the Internal Parameters,
the administrator should restart the SMSC in order for the modifications to
take place. Most of the other parameters will be in effect at the next
configuration period (config_period parameter).
9.1.1. Local Configuration
The following is a description of the configuration file: smsc_conf.ini

[smsc] SMSC section
Database and License parameters Refer to Table 9-1
Name of the current node. This
value will be appended to the smsc
Node X(32)
transaction log filename
(smsc_log_filename).
If set, if an alert is received
notifying the SMSC that an msisdn
has become reachable again, the
alert_delay Integer
delivery of the waiting messages is
delayed up to this value (in
seconds).
Receiver ESME identifier.
When set to a value > 0:
- if the MT failed with
unknown subscriber error
(error 1 returned from the
HLR), or with system falure
and mnp_esme_on_sys_fail
mnp_esme_rxid Integer is set
- and if the destination
MSISDN matches the
mnp_address_range
The destination number is
considered subscribed to the other
network operator and is forwarded
to the receiver ESME
Type of the ESME:
- 0 smpp
mnp_esme_type [0-2] 0
- 1 emi
- 2 sema


Regular expression to filter MT
mnp_address_range X(255) numbers that should be handled as
MNP
When set, messages failing with
mnp_esme_on_sys_fail system failure will be forwarded to
the receiver ESME if set.
[GMSC] GMSC section
> Format: index = host port
mref_size sending_rate
<alternative_sending_rate>
link_capacity network_type with:
- index = GMSC number (starting at
1)
- host = IP address or hostname of
the Jinny GMSC
- port = JSMSC Listening port
- mref_size = Maximum allowed
number of unacknowledged short
messages sent to the GSM network
(limited by the SIU capability)
- sending_rate = maximum allowed
number of messages sent to the
GMSC per second, limited by the
license purchased.
- alternative_sending_rate = This
parameter is optional and should be
encapsulated in < >. It defines the
sending_rate in case the connection
with one of the other SIUs has gone
down.
- link_capacity = maximum number
of total bits per second sent to the
<index> X(255)
SIUs, This value should be set
based on the numbers of links used.
Total link capacity of the SMSC =
(64000) x (no of links) x (preferred
% usage per link (typ. 30%). This
parameter assists the SMSC process
in regulating output traffic
quantities so that link capacities are
not overloaded
- network type = 0 for GSM, 1 for
CDMA and 2 for TDMA. This
parameter specifies the type of
network the GMSC is attached to.
The sending rate and link_capacity
are used to regulate the SMSC
output traffic.
> pri = x y z
This field configures the network
priorities when multiple network
types are interconnected and
defined. x y and z should be put in
the appropriate order and should
take the values 0 1 or 2(0 for GSM,
1 for CDMA and 2 for TDMA).


Node section used to configure MPU
[node]
nodes in the system
<node><host><dbname><dbuser
><dbpass><local_node>
Entries start at 1
With :
- node: Name of the MPU
node
- host: IP address of the MPU
node
<index> X(255)
- dbname: The database
server name
- dbuser: The name of the
database user
- dbpass: The password of the
dbUser
local_node: 1 if local node 0
otherwise
Table 9-2 SMSC Local Configuration
9.1.2. Global Configuration

The following is a description of the configuration file: smsc.ini
A. Logging and Alarms Configuration

[debug] Logging Configuration
If not specified, the global debug level
will be applied. This section is used if
Process name the administrator needs to change the
debug level of a certain process for
monitoring
Smsc Smsc main process
Refresh Refresh process
Retry Retry process
future Future delivery process
Groups_cmd Groups command process
Embedded_cmd Embedded command process
Q2db [0-4] -1 Queue to Database process
Submit Submit Process
rx Receiver process
Mo_rx MO Receiver process
Mt_rx MT acknowledgements receiver
process
tx Transmitter process
[smsc]
Logging and alarms parameters -1
Refer to Table 9
Table 9-3 SMSC Logging and Alarms Configuration

B. Main configuration

[smsc]
SMSC Main Configuration
0 = Unknown Number
smsc_ton 1 = International Number
2 = National Number
[0,1,2] 1
0 = Unknown numbering plan
smsc_npi 1 = ISDN/telephone numbering plan
2 = National numbering plan
SMSC specific address defined by the
smsc_addr X(20) GSM Operator, used as RP oaddr in
outgoing messages.
Base semaphore key needed to avoid
conflict in synchronising if more than
one smsc instance need to run on the
smsc_base_sem_key Integer 8000 same machine. The administrator
should allow a merge of minimum
1000 between 2 base semaphore key
values on the same machine.
Flag for enabling or disabling sending
status reports when required. This
Status_report [0,1] 0 value affects the processes handling
ESME interface. (0 = no report and 1
= report)
Value in hours used for the validity
sr_vp Integer 24 period of a waiting status report. It
has no effect if set to 0.
Value in hours used if no expiry time
def_expiry_hours Integer 24
is specified in the SM
% of the window_size reserved for
normal messages, i.e. the % of
messages to be considered as normal
by JSMSC. Used to specify the
proportion of normal and retry to
broadcast messages. If normal
messages_winlen [0-100] 70 messages do not need the total of the
percentage assigned, the rest will be
left for broadcast messages. This
entry correlates to the normal
messages parameter (in %) in the
SMSC main configuration file on the
administration interface.
% of the window_size reserved for
retry messages, i.e. the % of
messages sent based on the retry
algorithm. Used to specify the
proportion of normal and retry to
broadcast messages. If retry
retry_winlen [0-100] 30 messages do not need the total of the
percentage assigned, the rest will be
left for broadcast messages. This
entry correlates to the retry
messages parameter (in %) in the
SMSC main configuration file on the
administration interface.


smsc process timeout (ms) for
timeout Integer 100 reading MO messages from the
GMSC.
SMSC process timeout (sec) for
getting an acknowledgement on a
message sent to the charging
check_timeout Integer 10
interface for checking/charging. If this
timer expires, the process will re-
attempt the charging.
Timeout after which the SMC
gmsc_mo_timeout Integer 10 considers that the GMSC has closed
the MO dialog.
SMSC process timeout (sec) for
getting an acknowledgement on a
response_timeout Integer 300
submitted MT message. If this timer
expires, the process will exit.
Period (sec) for checking if the timer
of an unacknowledged messages
response_period Integer 60
expired before getting back a
response.
If set, a first delivery attempt is
global_priority_flag [0,1] 0 performed on a new message even if
the MT is on the waiting list.
Number of concurrent RX processes
to handle GMSC SMSC traffic for
concurrent_rx_number [0-8] 2 outgoing dialogs. It should be set to
the number of active CPUs on the
machine.
Number of concurrent RX processes
to handle GMSC SMSC traffic for
Concurrent_rx_mo_number [0-8] 2 incoming dialogs. It should be set to
the number of active CPUs on the
machine.
The SMSC re-reads its configuration
Config_period Integer 10
file at this period (in minutes)
It connected to multiple GMSCs, the
SMSC will try to establish a
connect_period Integer 10
connection at this interval (in
minutes)
Used to control the GSM priority sent
to the network:
- 0 all messages sent with
normal priority
priority
gsm_priority [0-3] 2 - 2 all messages sent with the
original priority set by the
originator
priority if destination address
matches the
gsm_priority_range
If gsm_priority is set, messages will
be sent with priority if destination
gsm_priority_range X(4095)
address matched this regular
expression
Enable/disable the use of the more
mms_flag [0,1] 0
messages to send flag.


Maximum number of pending
messages allowed for a certain
number. If this number is exceeded,
max_ready Integer 100 the excess messages are rejected.
This parameter is used as an anti MT
spamming protection. If set to 0,
there is no limitation
If set, the validity period of all
max_expiry_hours Integer 0 submitted messages are limited to
that value (in hours)
If set, if 2 messages arrives at the
same second, the SMSC will make
check_scts [0,1] 0 sure that they have different
timestamps, while keeping the
modification to a minimum
If set, the messages are encrypted
msg_encryption [0,1] 0 before storage (in the database and
in the transactional log files)
- 0 sent the GSM message with
the reply path as received
from the MO
disable_reply_path [0-2] 0 - 1 disable the reply path
- 2 set the replay path to 1
regardless of the value
received from the MO
Flag to enable/disable the handling of
handle_mt_rdup [0,1] 0
MO-MT reject duplicates.
handle_esme_rdup [0,1] 0
MO-ESME reject duplicates.
the SMSC control parameters, if
handle_smsc_conrol_param [0,1] 0
present in the user data header of the
message
Flag to enable/disable heartbeat
between the JSMSC and GMSC. This
is useful when the SMSC and GMSC
heartbeat_indicator [0,1] 0
are not on the same machine. If set,
periodic heartbeat messages are sent
to check the health of the connection.
Period in seconds to send heartbeat
heartbeat_interval Integer 0
messages
A timer is set at each heartbeat
message sent. The timer expires if
heartbeat_timeout Integer 0
this value (in seconds) is exceeded
without any response from the GMSC
If the heartbeat timer expires up to
this number, the JSMSC will consider
heartbeat_timeoutnumber Integer 0
the connection is lost and will close
the connection
Path of a script to be executed if
on_exit X(256)
necessary when the smsc exits
Maximum timeout in ms waiting for a
bind_timeout Integer 1000
connected GMSC to bind.
When set, the smsc will reject
max_concatenated_segment concatenated messages with a
Integer 0
s number of segments exceeding this
value

Table 9-4 SMSC Main Configuration
C. SMSC Internal Parameters

[smsc]
SMSC Internal parameters
Size of the shared memory allocated

to sending messages and receipts to
sms_shm_record_size Integer 1024 multiple TX processes equals
(sms_shm_record_size x
sms_shm_records)
sms_shm_records 2048
Size of the shared memory allocated
to sending MO acknowledgements
between RX and TX processes for
mo_shm_record_size 256
each client equals
(mo_shm_record_size x
mo_shm_records)
mo_shm_records 1024
Full path of the RX Queue of
/var/jin
numbers. This file contains all MT
ny/shm/
hash_filename X(255) numbers that have messages ready
smsc_h
to be sent. It consists of a primary
ash.DAT
and an overflow area.
Size of the primary area. It should
primary_list_size Integer 10007
be a prime number.
Size of the overflow area in the case
overflow_list_size Integer 3000 of collisions. If full, the SMSC will be
congested and will reject messages.
/var/jin Full path of the RX queue of
ny/shm/ messages. This file contains all
hash_msg_filename X(255) smsc_h normal MT messages (direct MO/MT,
ash_ms store & forward, future) that need to
g.DAT be sent.
Size of the messages queue. If full,
msg_list_size Integer 10000 the SMSC will be congested and will
reject messages.
Full path of the RX Queue of
/var/jin
broadcast numbers. This file contains
ny/shm/
all MT numbers that have broadcast
brdcst_hash_filename X(255) smsc_br
messages ready to be sent. It
dcst_ha
consists of a primary and an overflow
sh.DAT
area.
brdcst_primary_list_size Integer 10007
be a prime number.
of collisions. If full, the SMSC will be
brdcst_overflow_list_siz
e Integer 3000 congested and will reject messages.
Only priority messages will be stored
in the database.
/var/jin Full path of the RX queue of
ny/shm/ broadcast messages. This file
smsc_br contains all broadcast MT messages
brdcst_hash_msg_filename X(255)
dcst_ha (direct ESME/MT, store & forward)
sh_msg. that need to be sent.
DAT


Size of the messages queue. If full,
the SMSC will be congested and will
brdcst_msg_list_size Integer 10000 reject messages. Only priority
messages will be stored in the
database.
/var/jin Full path of the Retry Queue of
ny/shm/ numbers. This file contains all waiting
retry_hash_filename X(255) smsc_re MT numbers that have a message
try_has that need to be retried. It consists of
h.DAT a primary and an overflow area.
retry_primary_list_size Integer 10007
be a prime number.
of collisions. If full, the SMSC will be
congested the message will be retried
retry_overflow_list_size Integer 3000
on the next retry time. Only priority
messages will be updated in the
database.
/var/jin Full path of the retry queue of
ny/shm/ messages. This file contains all retry
smsc_re MT messages that need to be sent.
retry_hash_msg_filename X(255)
try_has
h_msg.
DAT
Size of the retry messages queue. If
full, the SMSC will be congested and
the message will be retried on the
retry_msg_list_size Integer 10000
next retry time. Only priority
messages will be updated in the
database.
Period (ms) to reference new
list_timeout Integer 50
messages from the list
/var/jin Full path of the internal Groups
ny/shm/ commands queue. This file contains
groups_list_filename X(255) smsc_gr all pending Groups commands.
oups.DA
T
Maximum number of groups
groups_list_size Integer 1000
commands in the queue
/var/jin Full path of the internal embedded
ny/shm/ commands queue. This file contains
embedded_list_filename X(255) smsc_e all pending embedded commands.
mbedde
d.DAT
Maximum number of commands in
embedded_list_size Integer 1000
the queue
/var/jin Full path of the internal store
ny/shm/ messages queue. This file contains all
store_list_filename X(255)
smsc_st messages to be stored
ore.DAT
Maximum number of messages in the
store_list_size Integer 1000
queue
If set, this flag will enable the user
handle_smsc_control_para
m [0,1] 0 data header control parameters (as
set in GSM 03.40).
Table 9-5 SMSC Internal Configuration

D. SMSC Data Storage

[smsc]
SMSC Data Storage
/var/jin Location of the JSMSC transactional

ny/mess log filename (CER (Caller Event
smsc_log_filename X(255) ages/sm Record) Data File)
sc_mess
ages
Fields separator used in the Jinny
smsc_log_separator X(1) |
SMSC transactional log filename
If set, the SMSC logs each result of a
log_status_report [0,1] 0
status report attempt
If set, the SMSC logs each MO
log_mo_accepted [0,1] 0
message accepted
If set, the SMSC logs each MO
log_mo_failed [0,1] 0
message rejected
If set, the SMSC logs each MT
log_mt_final [0,1] 1
attempt that reached a final status
If set, the SMSC logs the result of
log_mt_attempt [0,1] 0
each MT attempt
If set, the SMSC logs the Alert
log_alert [0,1] 0
notifications.
Enable/Disable logging of the
smsc_log_privacy [0,1] 0
message field in DAT files
Table 9-6 SMSC Data Storage Configuration
E. Routing and Interworking Configuration

[smsc]
Routing and Interworking Configuration
Location of the Translation File used

on the originating addresses before
sending the message on the network.
rx_translation_file X(255) It also used internally on the
destination address to get one format
for all numbers. It is limited to 1024
entries.
Location of the translation file used
on the destination addresses before
tx_translation_file X(255)
sending the message on the GSM
network. It is limited to 1024 entries.
cdma_tx_translation_file X(255)
sending the message on the CDMA
tdma_tx_translation_file X(255)
sending the message on the TDMA
tx_oaddr_translation_fil on the originating addresses before
X(255)
e sending the message on the GSM


cdma_
tx_oaddr_translation_fil X(255)
e sending the message on the CDMA
tdma_
tx_oaddr_translation_fil X(255)
e sending the message on the TDMA
on the recipient addresses before
sr_translation_file X(255) sending the Status Report message
on the GSM network. It is limited to
1024 entries.
Regular expression used on MO
src_routing_expr X(4095)
addresses if src_restriction is set
Regular expression used if
dest_restriction is set to filter
dest_routing_expr X(4095) allowed MT addresses, and used by
the processes handling ESME
interfaces
Regular expression used on MO IMSI
src_imsi_range X(4095) 1 numbers if src_restriction is set
(support of MNP).
Flag for source checking. If set, the
src_restriction [0,1] 1 originating addresses of each MO
message are checked
Flag for destination checking. If set,
dest_restriction [0,1] 1 the MT addresses of each message
are checked
Flag to enable/disable the MO white
mo_white [0,1] 1
and MO to irregular MT white lists
Flag to enable/disable the MO black
mo_black [0,1] 1
list
Flag to enable/disable the MT white
mt_white [0,1] 1
list
Flag to enable/disable the MT black
mt_black [0,1] 1
list
Period (min) for updating the internal
routing_table_period Integer 60 routing table. This table is used to
route messages to ESMEs
MAP Error sent if the MO is in the
mo_black_error [0-255] 28 black list. (Default is MS not SC
subscriber).
MAP Error sent if the MT is in the
mt_black_error [0-255] 28 black list. (Default is MS not SC
subscriber).
If set, black listing will apply only to
black_charged [0,1] 0 charge messages. This flag is only
used by ESME servers.
When set, if message is received with
unsupported protocol ID (telematic
check_unsupported_pid [0,1] 0
interworking), the SMSC rejects the
message
Flag to enable/disable interconnection
network_interconnect [0-1] 0 between GSM, CDMA and TDMA
networks.


If set, long messages destined to
other network types with shorter max
network_length_adaptatio
n [0,1] 0 length will be split into 2 messages. If
not set, the message will be
truncated.
Max length of SMS over GSM
interwork_gsm_max_len Integer 160
network.
Max length of SMS over CDMA
interwork_cdma_max_len Integer 160
network.
Max length of SMS over TDMA
interwork_tdma_max_len Integer 160
network.
interwork_iden_max_len Integer 140 Max length of SMS over iDEN network
By default, the user data headeris
removed when sending to iDEN
interwork_iden_keep_conc
atenated [0,1] 0 networks. When set, the
concatenated information element is
kept in the user data header.
By default, the user data headeris
removed when sending to iDEN
interwork_iden_keep_appl networks. When set, the application
[0,1] 0
ication_port port (8-bit and 16-bit) information
element is kept in the user data
header.
Regular expression used to route
messages to the GSM network, based
Empty on their MT address range. This
gsm_address_range X(4095)
String expression is checked if the network
type is not specified in the profile of
the MT address.
messages to the CDMA network,
based on their MT address range. This
cdma_address_range X(4095) expression is checked if the network
the MT address. Checking disabled if
empty
messages to the TDMA network,
based on their MT address range. This
tdma_address_range X(4095) expression is checked if the network
the MT address. Checking disabled if
empty
Regular expression used to filter iDEN
subscriber and do the appropriate
conversion. This expression is
iden_address_range X(4095)
checked if the network type is not
specified in the profile of the MT
address. Checking disabled if empty
TDMA default validity, values based
on TIA/EIA-136 specification:
- 0 indefinite
tdma_validity [0-3] 0 - 1 power down
- 2 system id based registration
area
- 3 display only


TDMA default display time, values
based on TIA/EIA-136 specification:
tdma_display_time [0-2] 0 - 0 temporary
- 1 default
- 2 invoke
TDMA default sms signal, values
based on TIA/EIA-136 specification.
This field is encoded over 12 bits as
follows (bit 11 - bit 0):
- bit 11- bit 10: pitch
- bit 9 bit 4 : cadence
- bit 3 bit 0 : duration
Pitch values (binary format):
- 00 medium pitch
- 01 high pitch
- 10 low pitch
Cadence values (binary format):
- 000000 No Tone: Off
- 000001 Long: 2.0 s on, 4.0 s off
(standard)
- 000010 Short-Short: 0.8 s on, 0.4
s off, 0.8 s on, 4.0 s off
- 000011 Short-Short-Long: 0.4 s
on, 0.2 s off, 0.4 s on, 0.2 s off,
0.8s on, 4.0 s off
- 00100 Short-Short-2: 1.0 s on,
1.0 s off, 1.0 s on, 3.0 s off
- 000101 Short-Long-Short: 0.5 s
on, 0.5 s off, 1.0 s on, 0.5 s off,
0.5s on, 3.0 s off
- 000110 Short-Short-Short-Short:
[0- 0.5 s on, 0.5 s off, 0.5 s on, 0.5 s
tdma_sms_signal 0
4095] off, 0.5 s on, 0.5 s off, 0.5 s on,
2.5 s off
- 000111 PBX Long: 1.0 s on, 2.0 s
off
- 001000 PBX Short-Short: 0.4 s
on, 0.2 s off, 0.4 s on, 2.0 s off
- 001001 PBX Short-Short-Long:
0.4 s on, 0.2 s off, 0.4 s on, 0.2 s
off, 0.8 s on, 1.0 s off
- 001010 PBX Short-Long-Short:
0.4 s on, 0.2 s off, 0.8 s on, 0.2 s
off, 0.4 s on, 1.0 s off
- 001011 PBX Short-Short-Short-
Short: 0.4 s on, 0.2 s off, 0.4 s
on, 0.2 s off, 0.4 s on, 0.2 s off,
0.4 s on, 0.8 s off
- 001100 Pip-Pip-Pip-Pip: 0.1 s on,
0.1 s off, 0.1 s on, 0.1 s off, 0.1 s
on, 0.1 s off, 0.1 s on, 0.1 s off.
Duration values (binary format):
- 0000 1 Cycle of Cadence
(Standard)
- 0001 2 Cycles of Cadence
- ... ...
- 1110 15 Cycles of Cadence
- 1111 Continuous Repeating of
Cadence
Default Call back number address
tdma_default_cbn_encodin encoding based on TIA/EIA-136-123:
[0-1] 0
g - 0 IRA encoding
- 1 TBCD encoding


When set, for TDMA submitted
messages, a MIN is looked up based
on the received MDN, in a MIN-MDN
use_min_mdn_mapping [0-1] 0
table. The administrator is
responsible for filling the MIN-MDN
table with the correct values
When set, the GSM originating
address is translated:
- 0 no translation
- 1 always translate
translate_gsm_oaddr [0-3] 0
- 2 translate if destination
address is national
address is international
When set, the CDMA originating
- 0 no translation
translate_cdma_oaddr [0-3] 0
address is national
When set, the TDMA originating
- 0 no translation
translate_tdma_oaddr [0-3] 0
address is national
Used when converting GSM to TDMA
messages. Special case when the
GSM message contains latin
characters (accents) not supported in
adjust_latin_characters [0-1] 0 the default alphabet, the GSM data
coding used is UCS2. In that case, the
message is converted into ascii
characters and the tdma encoding is
set to text
Flag to enable/disable routing of
smpp [0,1] 1
messages to SMPP ESME clients
emi [0,1] 1
messages to EMI ESME clients
sema [0,1] 1
messages to SEMA ESME clients
Type of the ESME queue used to
route message to receiver ESMEs.
esme_db [0-2] 0 It takes 2 values:
- 0 Database
- 2 Jinny Queue (JQ)
Path where to store the Jinny Queues
/var/jin used for inter process communication
esme_jq_path X(255)
ny/shm/ between the SMSC and the ESME
servers
Number of records to store in each
esme_jq_extent Integer 10000
extent of a JQ


/var/jin Path where to store the fax queue
ny/shm/ needed for MO to fax command and
fax_jq_path X(255)
smsc_fa last resort address
x.jq
fax_jq_extent Integer 10000
extent of a JQ
/var/jin Path where to store the fax queue
ny/shm/ needed for MO to email command and
email_jq_path X(255)
smsc_e last resort address
mail.jq
email_jq_extent Integer 10000
extent of a JQ
When set, a delivery report is
generated for datagram ESME-MT if
handle_datagram_report [0,1] 0
requested. This entry is also read by
the SMPP server process
Table 9-7 SMSC Routing and Interworking Configuration
F. Charging Configuration

[smsc]
Charging
Number of concurrent processes that

will handle messages checked by the
charging engine. In a positive
acknowledgement, the transaction
concurrent_submit [1-8] 2
should resume, while in the opposite
case, the message will end. This
number should be set to the number
of CPUs on the machine
Time (in ms) for getting new checked
submit_time Integer 100
messages.
/var/jin Path of the mutex file needed to
ny/shm/ synchronised the access to the submit
submit_jq_mtx_path X(255) smsc_s queue
ubmit.m
tx
/var/jin Path of the submit JQ. This queue will
ny/shm/ hold all the messages acknowledged
submit_jq_path X(255)
smsc_s by the charging engine.
ubmit.jq
submit_jq_extent Integer 10000
extent of a JQ
If set, the SM that should be charged
to a prepaid customer is inserted into
charge_prepaid [0,1] 0
a specific queue waiting to be handled
by the relevant prepaid process
Service type associated with
sms_servicetype X(20) SMS99 messages to be charged to a prepaid
customer for MO MT messages
If set, status reports will be charged if
charge_status_report [0,1] 0 successfully delivered within a certain
interval


If set to a positive value, only status
charge_status_report_int
erval Integer 0 reports delivered within the specified
value in minutes will be charged.
Service type used when charging
sr_servicetype X(20)
status reports
If set, messages will be charged even
charge_international_mt [0,1] 0
if not delivered
<sms_s Service type used when charging
international_servicetyp ervicety messages to international MT
X(20)
e pe
value>
If set, roaming MO prepaid will be
charge_roaming_prepaid [0,1] 0
charged differently
<sms_s Service type used for charging
roaming_prepaid_servicet ervicety roaming prepaid
X(20)
ype pe
value>
If set, all the customers will be
treated as prepaid. This flag will
all_prepaid_customers [0,1] 0
override any information in the
profiles table
When set, the smsc will consider the
prepaid_addr X(255) subscriber as prepaid if the number
matches this address range
DCS of the FLASH message to be sent
pre_mo_ckpt_dcs Integer 16 in case of error in charging after
gmsc_mo_timeout.
Message FLASH message to be sent in case of
could error in charging after
pre_mo_ckpt_msg_rejected X(255)
not be gmsc_mo_timeout.
sent
TON of originating address of the
FLASH message to be sent in case of
pre_mo_ckpt_oton Integer 1
error in charging after
gmsc_mo_timeout.
NPI of originating address of the
FLASH message to be sent in case of
pre_mo_ckpt_onpi Integer 1
error in charging after
gmsc_mo_timeout.
Originating address of the FLASH
pre_mo_ckpt_oaddr X(255) message to be sent in case of error in
charging after gmsc_mo_timeout.
If set, on the arrival of an MO matching the

configured charging conditions, a message with the
[prepaid_pre_mo_ckpt] corresponding information will be sent to the
charging engine. The MO will be held until a response
is returned from the charging engine. This flag can
be used for pre-MO submission checking.
ckpt [0,1] 0 Enable checkpoint if set.
If set, the smsc will send MO ack
ckpt_ack [0,1] 0
before sending the MO for charging.
If set, normal MO-MT messages will
mo_mt [0,1] 0
be charged
If set, roaming MO-MT messages will
roaming_mo_mt [0,1] 0
be charged.


If set, roaming MO-ESME messages
roaming_mo_esme [0,1] 0 will be charged even if receiving
ESME is free of charge
If set, MO to international MT will be
mo_international_mt [0,1] 0
charged.
mo_groups [0,1] 0 If set, MO to Group will be charged.
mo_esme [0,1] 0 If set, MO to ESME will be charged.
If set, ESME to ESME messages
esme_esme [0,1] 0
should be checked for charging
Bitwise flag to enable/disable
charging of embedded commands:
Bit 0: Auto-Reply charging
embedded_command [0-15] 0
Bit 1: Forward command charging
Bit 2: CLIR command charging
Bit 3: ALIAS command charging
/var/jin Path of the prepaid pre mo JQ.
ny/shm/
smsc_pr
jq_path X(255)
epaid_p
re_mo.j
q
jq_extent Integer 10000 Extent size in records
If set, prepaid MO messages will be charged
immediately on successful submission (previously
charge_prepaid_on_mo). In that case, the smsc will
[prepaid_post_mo_ckpt] does not need to wait for the response from the
charging engine
Messages charged on MO submission will not be
charged again when the message reaches a final
status.
mo_mt [0,1] 0
be charged
be charged.
charged.
mo_groups [0,1] 0 If set, MO to Group will be charged.
mo_esme [0,1] 0 If set, MO to ESME will be charged.
/var/jin Path of the prepaid post mo JQ.
ny/shm/
smsc_pr
jq_path X(255)
epaid_p
ost_mo.
jq
If set, when an MT message is ready to be sent, a

message is sent to the charging engine. The MT will
[prepaid_pre_mt_ckpt] be held until a response is returned from the
charging engine. This flag can be used for pre-MT
checking.
mo_mt [0,1] 0
be charged
be charged.


charged.
esme_mt [0,1] 0 If set, ESME to MT will be charged.
/var/jin Path of the prepaid pre mt JQ.
ny/shm/
smsc_pr
jq_path X(255)
epaid_p
re_mt.j
q
If set, a message will be sent to the charging engine

once the message is delivered or reaches a final
status (depending on the charge_on_error flag). In
[prepaid_post_mt_ckpt] that case, the smsc will does not need to wait for the
response from the charging engine.
If prepaid_post_mo_ckpt is set, MT originated from
MO will not be affected by this flag
mo_mt [0,1] 0
be charged
be charged.
charged.
esme_mt [0,1] 0 If set, ESME to MT will be charged.
charge_on_error [0,1] 0
if not delivered
/var/jin Path of the prepaid post mt JQ.
ny/shm/
smsc_pr
jq_path X(255)
epaid_p
ost_mt.j
q
if not delivered
the charging error notification feature that consists
[charging_errors] of sending back a message to the message sender
explaining the charging problem that occurred.
To enable/disable the charging error
notification feature that consists of
enable_charging_error_no
tification [0-1] 0 sending back a message to the
message sender explaining the
charging problem that occurred.
charging_error_notificat The data coding of the notification
ion_dcs [0-255] 0
charging_error_notificat The protocol Id of the notification
ion_pid [0-255] 0
Message The charging error notification
to %s message. It should contain 2
charging_error_notificat
ion_msg X(320) not sent formatted parameters: msisdn and
due to error string.
%s
Table 9-8 SMSC Charging Configuration

G. SMSC Retry Refresh Future Store Configuration

[smsc]
SMSC Retry Refresh Future Store
Retry sequence applied on normal

messages. The last interval will be
smsc_retry X(255) (1,30)
repeated until the message reaches a
final status.
Retry sequence used instead of
smsc_overload_retry X(255) (1,60) smsc_retry when the retry queue
reaches the overload level.
Retry sequence applied on priority
messages. The last interval will be
smsc_priority_retry X(255) (1,15)
repeated until the message reaches a
final status.
smsc_overload_priority_r
etry X(255) (1,30) smsc_priority_retry when the retry
queue reaches the overload level.
Retry sequence applied on messages
destined to foreign addresses. One
smsc_foreign_retry X(255)
the sequence ends, the message will
be removed.
smsc_overload_foreign_re
try X(255) (1,120) smsc_foreign_retry when the retry
queue reaches the overload level.
Regular expression used to filter local
local_routing_expr X(255)
MT addresses.
Flag to enable/disable using ESME
enable_esme_retry_seq [0-1] 0 retry sequence for waiting ESME-MT
messages
Period (ms) after which the smsc
process checks the status of
retry_time Integer 100
messages waiting in the SMSC
database and processes them.
Numbers of concurrent retry
processes. They are responsible of
putting messages to be retried in the
concurrent_retry Integer 2
corresponding ready messages list.
This number should be set to the
number of CPUs on the machine
Maximum number of messages that
max_retry_records Integer 500 should be resent in a given retry
period.
Maximum number of messages that
can be freed when a number becomes
reachable. Waiting messages that
max_free Integer 100
exceed that number will be set on
hold. The MSISDN will be added to
the MT black list.
If set, no alarm is sent when a
no_alarm_on_max_free [0,1] 0 max_free counter is reached for a
certain subscriber


If an MT message fails successively
with the MS busy for SM error, the
busy_retry Integer 0 message is added to the waiting list
after busy_retry number of
attempts
Period (sec) after which the smsc
process checks the validity period of
refresh time Integer 60 waiting messages and decides
whether they should be classified as
expired
process checks the future and store &
future_time Integer 100 forward messages and sends them
with the proper scheduled delivery
time
Number of concurrent future
processes. They are responsible of
putting store and forward messages
concurrent_future Integer 2 and due future messages in the
corresponding ready messages list.
This number should be set to the
number of CPUs on the machine
process checks the store messages
store_time Integer 100 queue for messages to be stored in
the database (waiting messages,
prepaid messages)
Error Retry Sequences
[error_retry] Error Retry section

This section contains the customized
retry sequences per error. The format
is:
Error=Retry Sequence
The error should be a temporarily
error (27 no subscriber reply, 22
<error> X(255)
memory capacity exceeded, 34
system failure). If a message fails
with an error defined in this section,
the associated retry sequence is used
instead of the default smsc_retry
sequence
Custom Errors
[custom_errors] Custom GSM errors

List of errors separated by space.
When an MT failed with an error in
Permanent X(255) this list, the error will be considered
as permanent and the message will
end.


this list, the error will be considered
Temporary X(255)
as temporary and the message will be
added to the waiting list (direct and
store & forward messages).
Transient X(255) as transient and the message will be
re-send up to a certain value
(busy_retry), before adding it to the
waiting list.
[custom_errors_cmda] Custom CDMA/TDMA errors
Permanent X(255) this list, the error will be considered
as permanent and the message will
end.
Temporary X(255)
as temporary and the message will be
added to the waiting list (direct and
store & forward messages).
Transient X(255) as transient and the message will be
re-send up to a certain value
(busy_retry), before adding it to the
waiting list.
Table 9-9 SMSC Retry Refresh Future Store Configuration

H. SMSC Overflow Parameters

[smsc]
SMSC Overflow Parameters
Flag to enable/disable the automatic

overflow mechanism. If set and the
waiting table in the database has
been detected to exceed the
overflow [0,1] 0
maximum allowed, the smsc will store
the overflow waiting messages to the
overflow_bdb queue (refer to the
overflow section)
Flag to enable/disable the automatic
overflow for new MO if the smsc is
congested. If set, instead of rejecting
overflow_congestion [0,1] 0
new MO messages when congested,
the smsc will store them in the
overflow_bdb for a later delivery.
/var/jin Path of the overflow JQ
ny/shm/
overflow_jq_path X(255) smsc_o
verflow.
jq
overflow_jq_extent Integer 10000 Extent size in records
/var/jin Path of the filename that will hold the
ny/shm/ overflow indicator
overflow_filename X(255)
smsc_o
verflow
Table 9-10 SMSC Overflow Configuration

I. Synchronization Configuration

[smsc]
Synchronisation Configuration
If set, MO commands that will affect

subscribers profiles are executed
directly. Otherwise, the requests are
execute_db [0,1] 1 appended to the sync local
transactional log (sync_local_file),
to be distributed and executed on all
nodes in the distributed system
Path of the sync transaction log file.
This file contains all the pending
/var/jin
requests affecting the global
ny/mess
configuration or profiles. It is used by
sync_local_file X(255) ages/sy
the sync_db process to forward the
nc_local
requests to the primary node where
_info
they will be executed and distributed
to all nodes
File containing nodes status
(primary/secondary) and
sync_file X(255) synchronization status (data
synchronized or not). If not set, no
synchronisation is needed
Internal field separator used in
sync_separator X(1) |
formatting the requests
/var/jin Path of the filename that will be used
ny/shm/ to generate txid for the requests
local_serial_filename X(255) smsc_lo appended to the local sync
cal_seri transactional log (if execute_db is not
al set)
Table 9-11 SMSC Synchronization Configuration
J. SMSC Commands

[smsc]
SMSC Commands
Comma
[cmd] nds
section
start_cmd X(1) * The start command character
stop_cmd # The stop command character
end_cmd Space The end command character
Period (ms) to retrieve the next
cmd_time Integer 100
command from the queue.
embedded_cmd_addr X(255) messages to the Embedded SMSC
Commands process.
Regular expression used to restrict
embedded_cmd_users X(255) the usage of the embedded SMSC
commands.
Flag to enable/disable the usage of
allow_embedded_cmd [0,1] 0
the Embedded SMSC commands


groups_cmd_addr X(255) messages to the SMSC Groups
Command process.
Regular expression used to restrict
groups_cmd_users X(255) the usage of the SMSC groups
command.
Flag to enable/disable the usage of
allow_groups_cmd [0,1] 0
the SMSC groups command.
Unknow Error message sent if the command
n requested is not defined on the
unknown_cmd X(160)
comman SMSC.
d
comman Error message sent if the command
cmd_not_active X(160) d not requested is not active.
active
comman Error message sent if the command
cmd_not_allowed X(160) d not requested is not allowed (for DR and
allowed ALIAS commands).
SMSC Embedded Commands
[clir] sections CLIR command section

[dr] with similar Delivery Reports command section
[block] parameters Block command section
Setting this flag activates the
active [0,1] 0
CLIR or DR command.
The maximum list allowed for
the command. If set to 0, the
max_list [0-20] 0
list contains up to 256
characters.
Setting this flag enables
charging [0,1] charging users for using the
command.
Service type used when
service X(20)
charging the command.
The SMSC notifies the user of
cmd
cmd_active X(160) the successful activation of
active
either the CLIR or DR command.
The SMSC notifies the user that
the command has been
%s
entry_active X(160) activated for the new entry. An
active
entry can be either an MSISDN
or many MSISDNs.
cmd The SMSC notifies the user that
already the command is already activate
entry_already_active X(160)
active for for the new entry.
%s
The SMSC sends this error
message to the user when the
cmd not
not_active X(160) user attempts to use either the
active
CLIR or the DR commands
without activating them first.
cmd not The SMSC notifies the user that
entry_not_active X(160) active for the command has not been
%s activated yet for the new entry.


%s The SMSC notifies the user that
entry_registered X(160) registere a new entry has been registered
d for use with this command.
%s The SMSC notifies the user that
already a new entry is already
entry_already_registered X(160)
registere registered for use with this
d command.
entry list The SMSC notifies the user that
entry_list_full X(160)
full the MSISDN list is full.
%s an existing entry has been
entry_removed X(160)
removed removed from the commands
list.
invalid the recent entrys format does
invalid_entry X(160)
entry not conform to the one specified
in the command.
[ms] Message Status Command section
Setting this flag activates the MS
active [0,1] 1
command.
Setting this flag enables charging
charging 0
users for using the command.
Service type used when charging the
service X(20)
command
%d The SMSC notifies the user of the
pending number of pending messages for the
entry_active X(160)
messag specified user
es
The SMSC notifies the user that the
invalid recent entrys format does not
entry conform to the one specified in the
command.
[cpm] Cancel Pending Messages (CPM) command section
Setting this flag activates the CPM
active [0,1] 1
command.
charging 0
service X(20)
the command
%d The SMSC notifies the user that an
entry_removed X(160) messages existing entry has been removed
deleted from the commands list.
command.
[fwd] Auto-Reply command section
Setting this flag activates the FWD
active [0,1] 1
command.
charging [0,1] 0
service X(20)
command


Flag used to set the default
forwarding condition. It is used when
the subscriber activates the forward
default_forwarding [0,1] 0
feature in its profile.
- 0 Conditional forwarding
- 1 Unconditional forwarding
The SMSC notifies the user that SMS
%s
entry_active X(160) forwarding to the specified entry is
active
active.
cmd The SMSC notifies the user that the
already SMS forward command has already
active been activated for the specified entry.
for %s
cmd not
not_active X(160) SMS forward command has not been
active
activated yet for use.
cmd not The SMSC notifies the user that the
entry_not_active X(160) active SMS forward command has not been
to %s activated for the specified entry.
%s
specified entry has been registered
entry_registered X(160) register
for forwarding SMS to the specified
ed
entry.
command.
[ar] Auto-Reply command section
Setting this flag activates the AR
active [0,1] 1
command.
charging [0,1] 0
service X(5)
the command
Subscriber
def_ar_message X(160) currently Default Auto-Reply message.
away
cmd The SMSC notifies the user of the
active successful activation of the Auto
entry_active X(160)
with msg: Reply command with the specified
%s message.
cmd The SMSC notifies the user that AR
already has already been activated for the
active for specified message.
%s
cmd not
not_active X(160) AR command has not been
active
activated yet.
The SMSC notifies the user that it
msg
entry_registered X(160) registered him to use the
registered
command.
[alias] Alias command section
Setting this flag activates the ALIAS
active [0,1] 1
command.
Maximum list allowed for the
max_list [0-20] 0 command. If set to 0, the list contains
up to 256 characters.


charging [0,1]
service X(20)
command
cmd %s
ALIAS command has been activated
entry_active X(160) active
for the specified entry using the
to %s
specified alias.
already specified alias has already been
active activated.
to %s
cmd not
not_active X(160) ALIAS command hasnt been
active
activated yet and cannot be used.
cmd %s The SMSC notifies the user that the
not specified alias has not been activated
entry_not_active X(160)
active for the entry.
to %s
%s
entry_registered X(160) register
command successfully registered with
ed
the SMSC.
entry
entry_list_full X(160)
list full
MSISDN list is full.
%s
The SMSC notifies the user that it
entry_removed X(160) remove
successfully removed the specified
d
MSISDN from the list.
command.
[future] Future command section
Setting this flag activates the FUTUR
active [0,1] 1
command.
charging [0,1] 0
service X(5)
command
[groups] Groups command section
Setting this flag activates the GROUP
active [0,1] 1
command.
Maximum list allowed for the
max_list [0-20] 0 command. If set to 0, the list
contains up to 256 characters.
charging [0,1]
Flag to determine the charging when
MO-GROUP is to be charged:
- 0 a charge request will be
generated for each destination
number in the group
charge_single_group_mess
age [0,1] 0 - 1 only one request will be
generated. If pre_mo_ckpt is
set and request cannot be
charged, a notification
message is sent back to the
MO


service X(20)
command
The prefix of the groups command
groups_prefix X(255)
address.
Value of the data coding scheme
(based on the GSM 03.38) used for
the Groups command response.
response_dcs [0,16] 0
- 0 = default alphabet coding
- 16 = default alphabet coding with
class 0 messages
Maximum number of groups list per
max_groups Integer 256
subscriber
Unknow The SMSC sends this error message
n to the user when it does not
cmd_unknown X(160)
Comman recognize the sent command as a
d group command.
Comman The SMSC sends this error message
cmd_not_active X(160) d Not when the user uses a command that
Active is not active.
No The SMSC sends this error message
Match when the user specifies a nonexistent
no_groupid_match X(160)
with Group ID in the command.
GroupID
No The SMSC sends this error message
Group when the user does not specify a
no_groupid X(160)
ID Group ID in the command.
specified
The SMSC sends this error message
No
when the user specifies a group in
no_group_available X(160) Group
the command without having created
available
any group.
Comman The SMSC sends this error message
d when the user sends a command that
cmd_format_error X(160)
Format does not conform to its format.
Error
The SMSC sends this error message
List
cmd_list_empty X(160) when the user sends an empty list
Empty
when expecting otherwise.
Group The SMSC sends this error message
cmd_group_exists X(160) already when the user tries to create a new
exists group with an existent group ID.
Maximu The SMSC notifies the user that the
m maximum number of allowed users in
cmd_max_exceeded X(160) allowed a group list has been exceeded.
exceede
d
%d The SMSC notifies the user that it
cmd_add X(160) msisdn( successfully added the msisdn(s) to a
s) added group.
%d The SMSC notifies the user that it
msisdn( successfully deleted the msisdn(s) to
cmd_delete X(160)
s) a group.
deleted
Successf The SMSC notifies the user of the
ul success of the operation of deleting
cmd_success X(160)
Operatio all the groups.
n


The list The SMSC sends the user the list of
cmd_check_list X(160)
is: %s the msisdns in a specific group
The list The SMSC sends the user the list of
of existing groups.
cmd_check_groups X(160)
groupids
: %s
The The SMSC notifies the user of the
group successful creation of a new group
cmd_group_created X(160)
%d was
created
The The SMSC notifies the user that the
msisdn( displayed msisdns are present in the
s) %s is specified group.
(are)
cmd_check_msisdn X(160)
present
in the
groupid
%d
[lra] Last Resort Address section
active [0,1] 1 Setting this flag activates the LRA.
charging [0,1] 0
users for using the LRA.
service X(5)
command
%s The SMSC notifies the user that LRA
entry_active X(160)
active to the specified entry is active.
already SMS LRA has already been activated
active for the specified entry.
for %s
cmd not
not_active X(160) LRA has not been activated yet for
active
use.
cmd not The SMSC notifies the user that the
entry_not_active X(160) active LRA command has not been activated
to %s for the specified entry.
%s The SMSC notifies the user that the
entry_registered X(160) register specified entry has been registered as
ed LRA.
command.
Table 9-12 SMSC Commands Configuration

K. First Delivery Attempt

[smsc]
First Delivery Attempt
use_db [0,1] 1 Use the database when in FDA mode

Use the profiles when in FDA mode.
Flag to enable/disable profiling. If set,
the profile of the originating and
profiling [0,1] 1
destination addresses is retrieved and
all the appropriate restrictions and
subscriptions are handled.
charging [0,1] 1 Enable charging in FDA mode
Flag to enable/disable first delivery
attempt. When set, failed messages
fda [0,1] 0 that meet the first delivery attempt
conditions, are forwarded to the
legacy SMSCs
Flag to enable/disable forwarding
fda_fwd_retry [0,1] 1
failed messages to the legacy SMSCs
If fda_fwd_retry is set, if this flag is
not set, the SMSC will not forward
fda_fwd_roaming_mt [0,1] 1
offnet and international MT addresses
not roaming in HPLMN.
This parameter can have the following
values:
> 0: Receiver identifier
responsible for the forwarding
of the failed messages to the
fda_esme_rxid Integer -1 legacy SMSCs. If set to 0
0 : the failed messages will be
forwarded over SS7 as MO
messages
-1 : the failed messages will be
discarded
Type of the ESME :
0 SMPP
fda_esme_type [0-2] 0
1 EMI
2 SEMA
If this flag is set, then the SMSC will
enable_mo [0,1] 1 be accepting MO messages from the
network.
Table 9-13 SMSC First Delivery Attemp Configuration

M. MO Control Configuration

[mo_control_ckpt]
SMSC MO Control
Flag to enable/disable the MO control.

When enabled, all MO messages
If set, on the arrival of an MO, a
message with the corresponding
ckpt [0,1] 0 information will be sent to the Jinny
Filtering Engine. The MO will be held
until a response is returned from the
filtering engine. This flag is used for
pre-MO submission checking.
If set, the smsc will send MO ack
ckpt_ack [0,1] 1
before sending the MO for control.
/var/jin
ny/shm/
jq_path X(255) smsc_m Path of the MO control receiving JQ
o_contr
ol.jq
jq_extent Integer 10000 Size of the JQ extent
Regular expression to filter the MT
spam_check_address_range X(4095) numbers that needs control. All
numbers are handled if not set.
Regular expression to filter the MO
spam_check_mo_address_ra
nge X(4095) numbers that needs control. All
numbers are handled if not set.
Regular expression to filter the
numbers for sponsoring. When an MO
message is sent to this range of
numbers, the sponsoring scenario is
sponsor_address_range X(4095)
checked to see if the message should
be sent to the JADE for sponsoring or
not. All numbers are handled if not
set.
This flag can take 3 values:
1: A is the subscriber and B gets the
advertisement. 2: B is the subscriber
sponsoring_scenario [1-3] 1
and B gets the advertisement. 3: A is
the subscriber and A gets the
advertisement.
Table 9-14 SMSC MO Control Configuration
N. Network Timezone

[network_timezone]
Network Timezone Format:
index = <network type> <dest_addr_range> <hour_offset>
index Integer Incremental counter

- 0 =GSM
network type [0-2] - 1 = CDMA
- 2 = TDMA


Destination address range (regular
dest_addr_range X(255)
expression)
hour_offset +-[0-9] Offset in hours
Table 9-15 SMSC Network Timezone Configuration
9.2. ESME Servers Configuration

In addition to their own individual configuration files, the ESME server
(transmitter and transceiver) processes use the following entries directly
from the configuration file smsc.ini.

[smsc]
Flag to enable/disable the MO white list. The
mo_white MO white list is only checked if the ESME
client is configured to check the MO address
(def_src_swt set)
Flag to enable/disable the MO black list. The
MO black list is only used if the ESME client is
mo_black [0,1] 1
configured to check the MO address
(def_src_swt set)
dest_restrict
ion If set, the destination address is checked
mt_white Flag to enable/disable the MT white list
mt_black Flag to enable/disable the MT black list
dest_routing_ X[255] The destination address is checked against
expr this regular expression
If set, black listing will apply only to charge
black_charged [0,1] 0
messages.
status_report [0,1] 0 If set, the delivery notifications are handled
If set, the messages submitted will be sent
global_priori
ty_flag [0,1] 0 even if the destination number is in the
waiting list
X(255) /var/jinny Full path of the RX Queue of numbers. This file
hash_filename /shm/sms contains all MT numbers that have messages
c_hash.D ready to be sent. It consists of a primary and
AT an overflow area.
primary_list_ Integer Size of the primary area.
size 10000
Integer Size of the overflow area in the case of
overflow_list
_size 3000 collisions. If full, the SMSC will be congested
and will reject messages.
X(255) /var/jinny Full path of the RX queue of messages. This
hash_msg_file /shm/sms file contains all normal MT messages (direct
name c_hash_m MO/MT, store & forward, future) that need to
sg.DAT be sent.
Integer Size of the messages queue. If full, the SMSC
msg_list_size 10000
will be congested and will reject messages.
X(255) Full path of the RX Queue of broadcast
/var/jinny
numbers. This file contains all MT numbers
brdcst_hash_f /shm/sms
that have broadcast messages ready to be
ilename c_brdcst_
sent. It consists of a primary and an overflow
hash.DAT
area.
brdcst_primar Integer Size of the primary area.
y_list_size 10000

Integer Size of the overflow area in the case of

brdcst_overfl collisions. If full, the SMSC will be congested
3000
ow_list_size and will reject messages. Only priority
messages will be stored in the database.
X(255) /var/jinny Full path of the RX queue of broadcast
/shm/sms messages. This file contains all broadcast MT
brdcst_hash_m
sg_filename c_brdcst_ messages (direct ESME/MT, store & forward)
hash_msg that need to be sent.
.DAT
Integer Size of the messages queue. If full, the SMSC
brdcst_msg_li will be congested and will reject messages.
10000
st_size Only priority messages will be stored in the
database.
The ESME server will start rejecting messages
with a message queue full error, if the
congestion_le pending messages queue is at the
[0-100] 100
vel congestion_level percent full. The queue is
used for normal MO-MT messages, ESME store
& forward messages and future messages.
Maximum number of messages per msisdn in
hash msg list. If set to 0, there is no
limitation. This parameter is used as anti MT
max_ready Integer 100
spamming protection. Messages exceeding
this limitation will be rejected with message
queue full error.
Flag to enable/disable routing message to
smpp
another SMPP ESME clients
Flag to enable/disable routing message to
emi [0,1] 1
another EMI ESME clients
sema Flag to enable/disable routing message to
another SEMA ESME clients
routing_metho [0,1] 0
d
If set, messages to be charged for prepaid
charge_prepai
d [0,1] 0 subscribers will be appended to the prepaid
charging queue
all_prepaid_c When set, all numbers are considered as
[0,1] 0
ustomers prepaid subscribers
Type of the ESME queue used to route
message to receiver ESMEs.
esme_db [0,2] 2 It takes 2 values:
- 0 Database
- 2 Jinny Queue (JQ)
Path where to store the Jinny Queues used
/var/jinny
esme_jq_path X(255) for inter process communication between the
/shm/
SMSC and the ESME servers
esme_jq_exten Number of records to store in each extent of a
Integer 10000
t JQ
Maximum number of ESME that can be
max_esme Inetger 1000
configured on the
If not set, the no profiling and charging will be
use_db [0,1] 1
done
Flag to enable/disable profiling. If set, the
profile of the originating and destination
profiling [0,1] 1
addresses is retrieved and all the appropriate
restrictions and subscriptions are handled.
Indicator if the first delivery attempt is
fda [0,1] 0
enabled on the SMSC

Identifier of the ESME that should handle the

fda_esme_rxid Integer -1
failed FDA traffic
charging [0,1] 1 Flag to enable/disable charging
esme_serial_s - 0 semaphore
[0,1] 1
ync - 1 flock
/var/jinny Name of the file used for generating message
esme_serial_f /shm/sms identifiers for submitted messages. The start
X(255)
ilename c_esme_s and end range are used to avoid conflict with
erial IDs when more than one MPU are deployed
esme_serial_s Start range of returned message identifiers
tart_range Integer 0
esme_serial_e 0xFFFFFF End range of returned message identifiers
Integer
nd_range F
max_expiry_ho If set, the validity period of all submitted
Integer 0
urs messages are limited to that value (in hours)
When used, if a relative validityperiod is
received with value 0, instead of setting the
default_relat
ive_vp Integer 0 validityperiod to 5 minutes (as defined in
3GPP 23.040), the value is used in hours.
(useful in iDEN networks)
[ar]
deliver [0,1] 0 Flag to deliver or not the auto-reply message
[prepaid_pre_mt_ckpt]
/var/jinny
/shm/sms
jq_path X(255) c_prepaid Path of the prepaid JQ
_pre_mt.j
q
jq_extent Integer 10000 Size of the JQ extent
Table 9-16 - ESME Servers and SMSC shared configuration entries
9.2.1. SMPP AIM Configuration

The aim.ini file contains the configuration parameters needed by the AIM.
Note that after each modification made on this file, the administrator
should restart the aim in order for the modifications to take place. The
following table is a description of the configuration file aim.ini.

[time] Contains information about the regional time
settings
Express the relative position of the local time
timezone {+,-} +
in relation to GMT
timezonevalu Time difference expressed in quarter of hours
[0 48] 0
e between the local time and GMT
[aim]
Refer to Table 9-1 Same entries
Port 7000 Port number of the AIM server
Maximum allowed number of short messages
to be retrieved from the database per
window_size 256
database interrogation (this value may not
exceed 256)
Integer
Granularity used to regulate the submitted
granularity 10
messages (in ms)
Maximum number of messages to be sent at
burst 1
each granularity

rglt_spam_ra Maximum number of short messages to be

10
te submitted to the same destination per minute
Default spamming regulation buffer size. This
value is used when there is no regulation (rate
Integer
def_rglt_spa = 0) on the incoming messages from a certain
3000
m_ring_size ESME client. It should be set to the estimated
maximum number of messages submitted per
minute
Flag to enable/disable retry on failed
Deliver_SM messages with error
ESME_RX_T_APPN. This is useful for clients
connecting the smsc with other external
retry [0,1] 0
messaging gateways. Enabling this flag will
require a special database optimization.
Please contact the Jinny Support team to
enable it
retry_sequen Retry sequence applied on temporarily failed
X(255) (1,15)
ce Deliver_SM messages
Reference period (in seconds) used by the
reference_pe
riod Integer 1 transceiver to reference new messages
pending for delivery to the ESME
Internal timeout (in ms) used by the
timeout Integer 100 transmitter and transceiver server when
reading from the ESME
Config_perio The Aim Server re-reads its configuration file
Integer 10
d at this period (in minutes)
reset_on_alr Flag to reset the Aim if already bound
eady_bound [0-1] 0
reset_pid_on Flag to reset the pid if process killed
_kill [0-1] 0
esme_routing [0,1] 1 Flag to enable/disable ESME to ESME routing
When the restrict GTT translation is set on a
certain transmitting ESME configuration,
submitted messages will be rejected if the
destination number does not have a
prefix_trans
f_fname X(255) translation entry in this file. Please refer to
the Jinny SIU documentation for the format of
this file. (This is usually used when a certain
operator forwards some of his international
traffic to a common gateway)
When set, if the transmitting ESME is required
use_single_s
to do the segmentation of a long message,
egmentation_ [0,1] 0
esmeid one identifier is used for all segmented
messages submitted to the SMSC
When set, the receiver will only send one
reassembly_d delivery report for a previously submitted
elivery_repo [0,1] 0 concatenated ESME-MT message. When set,
rts the use_single_segmentation_esmeid is forced
to 1
Period in minute for refreshing the internal
SAR delivery report list, that contains the
sar_dr_refre
sh_period Integer 1 information for the delivery reports received
for previously submitted concatenated ESME-
MT
Timeout in minutes. If after this timeout, not
all delivery reports were received for a
max_sar_dr_t
imeout Integer 10 previously submitted ESME-MT message, a
delivery report with a negative status is
delivered to the ESME

sar_list_siz Maximum number of entries in the internal

Integer 1000
e SAR delivery report list
allow_empty_ When set, empty messages submitted are not
[0,1] 0
messages rejected
failed_deliv When set, if the delivered message fails on
ery_notifica [0,1] 0 the JMR with a JMR message queue full error,
tion a notification is sent back to the MO
The data codign scheme used for the failed
failed_deliv
ery_dcs [0-255] 16 delivery notification. The default value is for a
flash text message
service
failed_deliv temporary
X(320) Failed delivery message
ery_message unavailabl
e
Flag to enable/disable sending the moservmsc
Enable_cw_mo TLV if the routing type is MO Serving MSC or
[0-1] 0
servmsc_tlv if it is Destination Address with ton or npi
set
Enable_moser Flag to enable/disable sending the moservmsc
[0-1] 0
vmsc TLV
Enable_celli
d [0-1] 0 Flag to enable/disable sending the Cell-ID TLV
[smpp]
delivery_rec Value of the esm_class used for delivering
[0-255] 4
eipt notifications
normal_deliv Value of the esm_class used for delivering
[0-255] 0
ery messages
intermediate
Value of the esm_class used for delivering
_notificatio [0-255] 32
n intermediate notifications
[check_prepaid]
Flag to enable/disable checking prepaid
option. If set, for each message (submit,
submit_multi, data_sm) received with a
service type configured to check prepaid
check_prepai subscribers, the process sends a request to
[0,1] 0
d the smsc check prepaid application. If the
subscriber is found not to have enough credits
for the operation, the message is rejected,
otherwise, it is forwarded to the smsc for
delivery
Window size used for referencing check
prepaid requests sent to the check prepaid
window_size Integer 256 application. If the window is full, new
incoming messages that need checking are
rejected
Period (in seconds) at which the ESME server
connect_peri
od Integer 1 tries to establish the connection to the check
prepaid application
Host address used to connect to the check
host X(32) 127.0.0.1
prepaid application.
Port number used to connect to the check
port Integer 0
prepaid application.
Response timeout (in seconds). If this timer
response_tim expires while waiting for a response to a
Integer 60
eout previously sent request, the connection to the
check prepaid application is closed
Timeout (in ms) used while reading from the
timeout Integer 0
check prepaid application

If set, for each message that need prepaid

checking, the ESME server blocks until it
synchronous [0,1] 0
receives a response from the check prepaid
application
Table 9-17 SMPP Configuration
Example: AIM Configuration file
[time]
timezone=+
timezonevalue=0
[smpp]
delivery_receipt=4
normal_delivery=0
[aim]
ProgName=aim
LogFileName=/var/jinny/log/aim
DebugLevel=3
AlarmProg=/usr/jinny/bin/alarmprog.sh
AlarmLevel=0
dbname=smsc
dbuser=Informix
dbpass=Informix
port=6692
window_size=256
granularity=10
burst=1
retry-0
retrysequence=(1,15)
License=ANXMR-LPVAA-AAAAA-FZBJF-AZIOW-KQZXD
rglt_spam_rate=0
def_rglt_spam_ring_size=3000
reference_period=5
timeout=200profiling=1
esme_routing=1
9.2.2. EMI Configuration
The emiserv configuration file is located in [Jinny Dir]/init/emiserv.ini
with [Jinny Dir]:
Home directory of the user jinny.
Path specified by the environmental variable JINNYDIR.
The administrator should note that the emiserv process must be restarted
for every modification made on this file in order for the new configuration
to be loaded. All the parameters described below are optional except the
port which is mandatory.
Entry Format Default Description

[emiserv]
Transmitter
Version number used for
version 9(4) 0100
the session management
port (Mandatory) 9(5) Listening port
If no session management
received after that value,
start_session_timeout Integer 60
connection is closed (in
sec)

def_daddrton Default TON/NPI of

destination address. Value
1
def_daddrnpi based on the description
in GSM 03.40
def_notification_type [0-7] 7 Default notification type
Default protocol identifier.
def_pid Integer 0 Value based on
description in GSM 03.40
Receiver
reference_size [1-100] 100 Reference size
Window size used for
window_size >0 1
windowing
New messages are
receiver_reference_interval referenced from the
database at this interval
1000 (in ms)
Timeout (ms) for reading
receiver_timeout a response (useful for
windowing)
Integer The receiver tries to
receiver_connect_interval 60 establish a connection at
this interval (sec)
The parent receiver
checks the status of each
receiver_refresh_interval 60 child at this interval. It
forks a process for each
inactive RX EMI Process
Message to
buffered_message %s, with Buffered Message
identification Notification
%s buffered
X(160)
delivered_message Message to Delivered Message
%s, with Notification
identification Failed Message
not_delivered_message
%s delivered Notification
Transmitter and Receiver
Initial number allocated
EMI_cnt Integer 20
for TX/RX EMIs
Granularity used to
granularity Integer 10 regulate the submitted
messages (in ms)
Maximum number of
burst Integer 1 messages to be sent at
each granularity
Table 9-18 EMI Configuration

9.2.3. SEMA (OIS) Configuration

The semaserver configuration file is located in [Jinny
Dir]/init/semaserver.ini with [Jinny Dir]:
home directory of the user jinny
path specified by the environment variable JINNYDIR
The administrator should note that the semaserver process must be
restarted for every modification made on this file in order for the new
configuration to be loaded.
Section/Field Format Default Description

[semaserver]
port Integer 0 Listening port
receive_port Integer 0 Receive port
access [0,1] 1 Access type (direct or gateway)
accept_timeout Integer 1000 Time out for TCPCheck (ms)
-1 if no packaging and N if packaging in
packeting_flag -1, Integer -1
N length packets
timeout Integer 100 Time out for TCPreadnt (ms)
result_timeout Integer 10 Time to wait for a result message (sec)
retry Integer 2 Number of retries to send messages
reference_size Integer 256 Reference size
reference_interv New messages are referenced from the
Integer 1000
al database at this interval (ms)
max_users Integer 20 Max concurrent users
Granularity used to regulate the
granularity Integer 10
submitted messages (in ms)
Maximum number of messages to be
burst Integer 1
sent at each granularity
encoding [0-2] 2 0 binary, 1 hex, 2 IA5
use_login [0,1] 1 0 disable login, 1 enable login
Table 9-19 SEMA Configuration
The Semaserver process uses the configuration file of the SMSC (smsc.ini),
for the charge handling and the counters.
9.3. SMSC Synchronization Configuration

The SMSC Synchronization Configuration part of the main SMSC global
configuration describes the configuration parameters related to the
synchronization. Note that these parameters are used also by the CGI for
the web admin and command line interface.

9.4. Node Synchronization process (jsync) Configuration

[jsync] Main section
LogFileName X(255) Log File Name
Debug Level:
0 critical errors
1 important errors/warning
DebugLevel [0-5] 3
2 warning
3 information
4,5 Debugging information
port Integer 7979 Server Listening port
timeout Integer 1000 Timeout in ms, reading new messages
connect_timeou Period in seconds for connecting to server
t Integer 1
accept_timeout Integer 1000 Period in ms for accepting new connections
Timeout in seconds waiting for a response to a
response_timeo
ut Integer 10 previously sent request. If this timer expires,
the jsync process exits with an error
Timeout in seconds. If no message is received
idle_timeout Integer 1 after that timeout, a handshake request is
sent (between which nodes?)
Timeout in seconds waiting for a handshake
hsk_timeout Integer 1 response. If this timer expires, the process
exits with an error
Timeout in seconds waiting for the partner
wait_connected node to request the local state (used by jsync
Integer 10
_timeout client). If this timer expires, the process closes
the connection.
Timeout in seconds waiting for the partner
node to connect (used by jsync server). If this
init_timeout Integer 300 timer expires, the process considers that the
other node will not appear and continue as
primary.
Primitive internal separator. The separator
separator X(1) \ should not be a character that might appear in
the data to be synchronized
Used by the jsync server if at nodes start-up,
the client sent start sync primitive. The server
start_sync_cmd X(256) will spawn a child process for that command.
Normally this command should start the
sync_db process
Used by the jsync server if at nodes start-up,
the synchronization is complete and the client
end_sync_cmd X(256) sent end sync primitive.
Normally this command should stop the
previously started sync_db process
Used by the jsync client if the start sync
primitive previously sent was accepted by the
sync_cmd X(256) server.
Normally this command should start a quick
synchronization, sync_db -q
[node] Partner node
Host address of the partner node. On the jsync
server, the host and port values are used to
Host X(32)
authenticate new connections. On the jsync
client, they are used to connect to the server


port Integer 7979 Port number of the partner node
9.5. File Synchronization process (jfsync) Configuration

[jfsync] Main section
Debug Level:
0 critical errors
DebugLevel [0-5] 3
2 warning
3 information
Host address of the jfsync server (used by
host X(16)
the client)
dat_sync_por Port number used to synchronize DAT files
t Integer 7977
file_sync_po Port number used to synchronize raw files
rt Integer 7978
timeout Integer 1000 Timeout in ms for reading new messages
connect_peri Period in seconds for connecting to server
od Integer 1
accept_perio Period in ms for accepting new connections
d Integer 1000
Timeout in seconds waiting for a response
response_tim
eout Integer 10 to a previously sent request. If this timer
expires, the process exits with an error
Timeout in seconds. If no messages is
idle_timeout Integer 1 received after that timeout, a handshake
request is sent
Timeout in seconds waiting for a handshake
hsk_timeout Integer 1 response. If this timer expires, the process
exits with an error
Primitive internal separator. The separator
should not be a character that might appear
in the data to be synchronized (for example,
separator X(1) \
when synchronizing DAT files, the separator
should not be |, which is the default
separator character of the DAT file)
/var/jinny/m Name of the DAT file that needs to be
filename X(256) essages/smsc synchronized.
_messages
max_file_cli Maximum number of raw file clients
ents Integer 32
rate Integer 1000 Number of records transferred per second
granularity Integer 10 Granularity in ms
Maximum number of records transferred per
burst Integer 10
granularity
[clients] Allowed clients
Authorized clients.
<index>=<nod Format:
e> <host Index = Integer
address> Node = X(32)
Host address = X(32)

9.6. DataBase Synchronization process (sync_db) Configuration

[sync_db]
Debug Level:
0 critical errors
DebugLevel [0-5] 3
2 warning
3 information
Dbname X(100) Database name
Dbuser X(100) Database username
Dbpass X(100) Database users password
port Integer 8000 Listening port (used by server)
primary_host X(32) Primary host address (used by client)
primary_port Integer 8000 Primary port number (used by client)
secondary_host X(32) Secondary host address (used by client)
secondary _port Integer 8000 Secondary port number (used by client)
timeout Integer 1000 Timeout in ms, reading new messages
Timeout in seconds. If no messages is
idle_timeout Integer 60 received after that timeout, a handshake
request is sent
Timeout in seconds waiting for a
hsk_timeout Integer 30 handshake response. If this timer expires,
the process exits with an error
response_timeou Timeout in seconds waiting for a response
Integer 30
t for a previously submitted request
Primitive internal separator. The
separator should not be a character that
separator X(1) \
might appear in the data to be
synchronized
On the server side, maximum number of
local requests executed per second, and
maximum number of database requests
rate Integer 1000 received from client, handled per second.
On the client side, maximum number of
database requests received from server,
handled per seconds
granularity Integer 10 Granularity in ms
burst Integer 10 Maximum rate per granularity
/var/jinny/s File containing the sync data info (local
sync_file X(255) hm/sync_inf transactional log filename and last txid,
o transactional log filename and last txid)
/var/jinny/ Path of the sync local info history file
messages/s
sync_local_file X(255)
ync_local_in
fo
node X(32) Current node
Period in seconds for checking if no
refresh_period Integer 1 response was received for a pending
transaction
window_size Integer 1 Maximum number of pending transactions
If set, the client will log each transaction
log_tx [0,1] 0 handled. This flag should be set if the
node is secondary.


/var/jinny/s Serial filename used to generate txid
serial_filename X(256) hm/smsc_se
rial
The profiles table is considered to
contains a lot of records, when full
empty_profiles_ synchronizing this table, the
[0,1] 0
method administrator can choose :
- value 0 to drop and recreate the table
- value 1 delete the records
sync_profiles Table full synchronization flag. If set, it
sync_aim will be full synchronized if required at
sync_emi startup.
sync_sema
sync_services
sync_commands [0,1] 0
sync_groups
sync_dl
sync_accounts
sync_routing
backup_profiles Backup table flag. At startup, if a full
backup_aim synchronization is required and the full
backup_emi synchronization of the table is set, a
backup_sema backup copy of the table is made before
backup_services dumping the current data and starting the
backup_commands [0,1] 0
full synchronization
backup_groups
backup_dl
backup_accounts
backup_routing
When a backup is required, the following
/usr/local/m command is executed:
backup_command X(255) ysql/bin/my <backup_command> <table> >
sqldump <backup_ouput_path><table>YYYYMMdd
_hhmmss
backup_output_p /var/jinny/t Output where to store the table backup
X(255)
ath mp/
[clients]
Format :
Index = [0-20]
<index>=<host Host address = X(32)
address> <port> Port = Integer
On the server side, used to authenticate
clients

9.7. SMSC CDR Configuration

The smsccdr.ini file contains the configuration parameters needed by the
smsccdr process in order to generate CDRs in the TAP version 1 or 2
format. Some entries can contain multiple values. The values should be
separated by comma (csv format). The following is a description of the
configuration file smsccdr.ini:
Section/Field Format Default Description

[smsccdr]
Refer to Table 9-1 Same entries
Empty
output_path X(256) Output directory of the CDR files
String
specification_version_
number [1,2] 2 1 for TAP 1.0 and 2 for TAP 2.0
Empty
Utc_time_offset X(90) max 15 offsets of 6 bytes
String
international_access_c
ode X(12) 3 codes of 4 bytes
country_code X(8) 2 codes of 4 bytes
0 data from the Jinny SMSC
database
data_from_file [0-1] 0
1 data from the Jinny SMSC
generated data files
Location of the Jinny SMSC
smsc_log_filename X(255)
generated data files
List of characters used as field
smsc_log_separator X(7) | separators in the Jinny SMSC data
files
[mo] | [mt] Sender of the MO MT CDR
sender X(5)
recipient Recipient of the MO MT CDR
Empty
Tax_treatment [Y,N] Flag for tax treatment
character
Empty
Tax_rate X(32) max 8 rates of 4 bytes
String
Sequence of maximum 10
exchange rates.
exchange_rate X(120)
Exchange rate = code X(1) + rate
9(10) + exponent 9(1)
code X(1) + offset +/-HHMM
Utc_time_offset X(90)
max 15 offsets of 6 bytes
The code that specifies the
Utc_time_offset_code X(5) 0 utc_time_offset to be used based
on the utc_time_offset value
E event based, F fixed (one-off)
charged_item E|F
charge
0 filled
Charge X(1023) Value to be charged
string
The code that specifies the tax
0
Tax_rate_code X(1) rate to be used based on the
tax_rate value
The code that specifies the
exchange_rate_code exchange rate to be used based
on the exchange_rate value
Table 9-20 SMSC CDR Configuration

In addition to its own configuration files, the process uses the following
entries directly from the configuration file smsc.ini.

[smsc]
If set, a CDR is generated for failed
messages
If set, a CDR is generated for each
charge_status_report [0,1] 0
delivered status report
Service type associated for the
sr_servicetype X(5)
charging of status reports
charge_status_report_
interval Integer 0 reports delivered within that interval
in minutes will be charged
charge_international_ If set, messages to international MT
[0,1] 0
mt will be charged differently
Service type associated with the
international_service
type X(5) charging of messages to international
MT
Routing expression used to filter the
local_routing_expr X(255) local form the international MT
addresses
Table 9-21 - Charging process and SMSC shared configuration entries
Example SMSCCDR Configuration file

General Rules
#
# format csv for each of the following table entries
#
# - international_access_code (3 codes of 4 bytes)
# - country_code (2 codes of 4 bytes)
# - tax_rate (max 8 rates of 4 bytes)
# - exchange_rate (max 10 rates of 12 bytes)
# - utc time offset (max 15 offsets of 6 bytes)
#
##############################################
#####################
[smsccdr]
ProgName=smsccdr
LogFileName=/var/jinny/log/smsccdr
DebugLevel=1
AlarmProg=
Daemon=0
dbName=smsc
dbUser=Informix
dbPass=Informix
output_path=/export/home/jinny/log
specification_version_number=1
utc_time_offset=+0200
international_access_code=0962
country_code=0079
data_from_file=1
smsc_log_filename=/export/home/jinny/log/cdr/smsc_messages
smsc_log_separator=,|

[mo]
sender=SMS99
recipient=JORFL
tax_treatment=Y
tax_rate=2000,0000,0000,0000,0000,0000,0000,0000
# code X(1) + rate 9(10) + exponent 9(1)
exchange_rate=A00000000000
# code X(1) + offset +/-HHMM
utc_time_offset=A+0200
utc_time_offset_code=A
# charged item: E event based, F fixed (one-off) charge
charged_item=F
#charge: 1 value if charged_item = F, table of 4 values (# 9 digits:
999999.999)
#charge MO/MT , MO/ESME , ESME/MT , ESME/ESME
charge=000000000,000001000,000000000,000000000
tax_rate_code=1
exchange_rate_code=A
[mt]
sender=SMS99
recipient=JORFL
tax_treatment=N
tax_rate=
# code X(1) + rate 9(10) + exponent 9(1)
exchange_rate=A00054945050
# code X(1) + offset +/-HHMM
utc_time_offset=
utc_time_offset_code=
# charged item: E event based, F fixed (one-off) charge
charged_item=F
charge=000000000
tax_rate_code=
exchange_rate_code=
9.8. SMSC MCR Configuration

The smscmcr.ini file contains the configuration parameters needed by the
smscmcr process in order to generate CDRs in the Siemens MCR format.
The following is a description of the configuration file smsccdr.ini:
Entry Values Default Description

[smscmcr]
Refer to Table
9-1 Same entries
output_path X(256) Output directory of the CDR files
prefix X(49) Prefix of the CDR generated file
default_service X(5) Default service used for MO/MT messages
Location of the Jinny SMSC generated data
smsc_log_filename X(255)
files
List of characters used as field separators
smsc_log_separator X(7) |
in the Jinny SMSC data files
version Integer 8 Version of the Siemens MCR
mscid X(4) Value in Hexadecimal string of the MSC id
cellid X(14) Value in Hexadecimal string of the CellId
Value in Hexadecimal string of the MS
ms_classmark X(6)
Classmark
exchange_id X(9)


sc_ton Type of network of the SMSC address
[0,1,2] 1 Numbering plan indicator of the SMSC
sc_npi
address
sc_addr X(22) Service centre address
Table 9-22 SMSC MCR Configuration
Example SMSCMCR Configuration file

[smsccdr]
ProgName=smscmcr
LogFileName=/var/jinny/log/smscmcr
DebugLevel=4
AlarmProg=/export/home/jinny/bin/alarmprog.sh
Daemon=0
dbName=smsc
dbUser=Informix
dbPass=Informix
output_path=/var/jinny/tmp
prefix=JINNY_
version=8
smsc_log_filename=/var/jinny/messages/smsc_messages
smsc_log_separator=|
default_service=SMS01
mscid=84DE
cellId=14F9302823D366
ms_classmark=301881
exchange_id=JINNY
sc_ton=1
sc_npi=1
sc_addr=9656373717
9.9. SMSC Generic CDR Configuration

The smsgencdr.ini file contains the configuration parameters needed by
the smscgencdr process in order to generate customized text CDRs. The
following is a description of the configuration file smcgencdr.ini:
[smscmcr]
Refer to Table 9
-1 (No License needed) Same entries
Rate in lines/second defining the
Rate Integer 1000
processing rate
Granularity (in ms) used for the
Granularity 10
regulation
Burst (in max lines/granularity) used for
Burst 10
the regulation
Path of the output directory.
The name of each CDR service file has the
following format:
<ouput_path><prefix><service>_<date
output_path X(255)
>_<time><sequence no
digits><extension>
Example:
CDRSMS99_20070426_00001.DAT


Prefix of the generated CDR file. The
prefix X(31) CDR service name and sequence number will
be appended to that prefix.
Date format string as defined in strftime
function, used in CDR filename. Most used
format:
- %d The day of the month as a
decimal number (range 01 to 31)
date X(31) - %m The month as a decimal
number (range 01 to 12).
- %y The year as a decimal number
without a century (range 00 to 99).
- %Y The year as a decimal number
including the century
Date format string as defined in strftime
function, used in CDR filename. Most used
format:
- %H The hour as a decimal number
using a 24-hour clock (range 00 to 23).
- %m The month as a decimal
time X(31) number (range 01 to 12)
- %M The minute as a decimal
- %S The second as a decimal
- %T The time in 24-hour notation
(%H:%M:%S). (SU)
If 0, no sequence number will be
sequenceno_digits Integer 5
appended to the name of the file
Maximum number of sequence no. When
max_sequenceno Integer 10000 reached, the sequence no will be reset to
1
When set, used with
date_to_sequenceno_interval, the
sequence number will be calculated as
date_to_sequencen
o [0,1] 0 follows:
Sequenceno = (current_hour x 60 +
current_minute) /
date_to_sequenceno_interval
date_to_sequencen
o_interval Integer 30 Date interval in minutes
Extension appended at the end of the
extension X(32)
CDR filename. For example: .DAT
If set, all the CDR for the different
services will be appended in the same file.
group_services [0,1] 0
Otherwise, a CDR filename will be
generated for each service
create_empty_file [0,1] 0 An empty CDR file is created
Character used to separate the fields in
separator X(1) |
the generated CDR.
If set, the fields in the sm and sr sections
format_fields [0,1] 0 should contain the format used for the
output CDR
When format_fields = 1, the string filler
string_filler X(1)
character is used to left pad a string


When set, a header record is appended at
the beginning of the generated CDR file.
enable_head [0,1] 0
The content of the header is specified by
the header section in the configuration file
When set, a trailer record is appended at
the end of the generated CDR file. The
enable_tail [0,1] 0
content of the trailer is specified by the
trailer section in the configuration file
Flag to set the method used for finding
the starting date in the SMSC history file.
sequential_scan [0,1] 0
- 0 use dichotomy (recommended)
- 1 use sequential scan
When set, for charged MO-ESME
messages, the content of the message is
enable_keyword_de checked to determine the service to
[0,1] 0
tection charge. The search is based on the short
code and keyword inside the message
(first word in the message)
If set, the process will make sure that the
donedate is different in all the CDRs
handle_donedate [0-1] 0 generated for the same destination
number. The modification if needed, is
kept to a minimum (precision in seconds)
handle_concatenat If set, concatenated messages will be
[0-1] 0
ed_msg handled as one message.
Interval (in seconds) used as a limit
between the SMs of a concatenated
message. If the interval between 2
consecutives SM exceed this value, the
max_msg_interval Integer 10 process will consider that the mobile
timed out and that the concatenated
message was discarded by the mobile,
thus will not generate a corresponding
CDR.
Period (in seconds) to refresh
concatenated messages. At this period, if
not all sequences of a concatenated
msg_refresh_perio
d Integer 1 message were not received after
max_msg_time, the message is removed
from the internal queue and will not be
charged
Time (in seconds) used to remove entries
max_msg_time Integer 30 of uncompleted concatenated messages
from the internal list
process_prepaid_r
ecords
process_expired_r Flags to enable/disable processing of
0
ecords prepaid/expired/deleted records
process_deleted_r
ecords [0-1]
process_all_mt
Flags to enable/disable generating a CDR
process_all_mo
record for the corresponding record type.
process_all_sr 1
process_all_alert Used when the smscgencdr is started with
process_all_audit the a argument (append all data record)
When set, a CDR is generated for
process_roaming_o
nly [0-1] 0 messages originated from roaming
subscribers only


Regular expression to be used in case of
mobile number portability and there is a
imsi_prepaid_addr X(255)
need to detect prepaid and postpaid
subscribers
In case the format_fields is enabled, this
empty_field_strin
g X(32) string will be used as the default filler if a
field of format string is empty
Flag to indicate if the error should be set
set_error_on_fail
ure [0-1] 0 only if the message fails. Useful if the
status field is not included in the CDR
Default value to be used if the
mobile_originator
_type X(15) MS-SME client_name field is included in the CDR
and the message is mobile originated
[sm]
[sr]
[header]
[trailer]
Please refer to the corresponding fields present in the SM and SR records in the TLR
file. The same field can be present more than once. The CDR will be generated with
the same order of the fields
The following is the generic format of the fields
The <field> entry is the name of the field
[0-1] or to be included in the CDR:
<field> 0
format 0 field not to be included
1 field to be included
Datetime format:
0 field not to be included
1 date and time included format: yyyy-
[0-3] or
<datetime field> 0 mm-dd hh:mm:ss
format
2 date included in the format: yyyy-mm-
dd
3 time included in the format: hh:mm:ss
In addition to the fields in the TLR, the following fields can be used
No Sequence number of the CDR. It will be
incremented by 1 for each CDR generated
Segmentation and reassembly. Flag
sar indicating if the message is a segment of
a concatenated message
The concatenated message reference.
sar_ref Value between 1 and 255, 0 if not
concatenated message
Total number of segments in
sar_total concatenated message. 0 if not
Sequence number of the current SM.
[0-1] or
sar_seqnum 0 Values between 1 and sar_total, 0 if not
format
It will give the number of characters in
the message. The message field will be
Messagelen appended in hexadecimal format if the
message contains a user data header, or
for binary and UCS2 messages.
deferred Flag to indicate if the message was
scheduled to be sent after its arrival
Values:
orig_group - 1 if ESME originated
- 3 mobile originated
client_name Name of the ESME if ESME originated


Values:
sm_type - 0 for MO-ESME or ESME-MT
- 2 for MO-MT
Filler X(64) When set, the filler string is appended
[header]
[0-3] or
timestamp 0 When set, the current time is appended
format
Filler X(64) When set, the filler string is appended
[trailer]
[0-3] or
start_date 0 When set, the starting date is appended
format
[0-3] or
end_date 0 When set the ending date is appended
format
[0-1] or When set, the number of generated CDR
count 0
format records is appended
filler X(64) When set, the filler string is appended
Table 9-23 SMSC Generic CDR Configuration
The available field types and their corresponding format are as follows:
Field Type Format

Integer %d
String %s
Date %Y%m%d%H%M%S
Constant X(64)
Table 9-24 SMSC Generic CDR Configuration
The field width/precision can be set.
The following table gives a list of the available fields and the type of format
that should be used:
Entry Field Type

[sm]
timestamp String
messageid
type
teleservice
command
cmd_type Integer
status
msg_status
oaddrton
oaddrnpi
oaddr String
daddrton
daddrnpi Integer
daddr String
priority
rp
sri
pid
privacy Integer
reply_option
alert_priority
language_ind

cbni
cbn_mode
cbn_ton
cbn_npi
cbn String
display_mode
deposit_index
multi_encoding
user_response Integer
dcs
msg_encryption
message String
scts
donedate
validityperiod Date
scheddeliverytime
rxaimid
txaimid
msisdn
mref
udhi
mode Integer
error
service
prepaid
aim_type
nt
nadc String
npid Integer
moservmsc
mo_imsi String
mo_esn Integer
mtservmsc
mt_imsi String
mt_esn
esmeid
smsc_dest_table
sar
sar_ref Integer
sar_total
sar_seqnum
messagelen
deferred
orig_group Integer
client_name String
sm_type Integer
filler Constant
[sr]
timestamp String
reportid Integer
msisdn String
status
mref Integer
tp_status
donedate Date
raddrton
raddrnpi Integer
raddr String
messageid Integer
imsi String

servmsc
prepaid Integer
filler Constant
[header]
timestamp Date
filler Constant
[trailer]
start_date Date
end_date Date
count Integer
filler Constant
Table 9-25 SMSC Generic CDR Fields Type
In addition to its own configuration files, the process uses the following
entries directly from the configuration file smsc.ini.

[smsc]
If set, a CDR is generated for failed
messages
Service type associated for the charging of
sms_servicetype X(5) SMS99
normal delivered messages
charge_status_r If set, a CDR is generated for each
[0,1] 0
eport delivered status report
Service type associated for the charging of
sr_servicetype X(5)
status reports
charge_status_r
eport_interval Integer 0 reports delivered within that interval in
minutes will be charged
charge_internat If set, messages to international MT will be
[0,1] 0
ional_mt charged differently
international_s Service type associated with the charging
X(5)
ervicetype of messages to international MT
local_routing_e Routing expression used to filter the local
X(255)
xpr form the international MT addresses
Table 9-26 - Charging process and SMSC shared configuration entries
And the following from the smsc_conf.ini:

[smsc]
node X(32) Name of the node if in distributed mode
/var/jinn
y/messa Location of the JSMSC transactional
smsc_log_filena
me X(255) ges/smsc log filename (CER (Caller Event Record)
_messag Data File)
es
smsc_log_separa Fields separator used in the Jinny SMSC
X(1) |
tor transactional log filename
Table 9-27 Charging process and SMSC local shared Configuration entries

Example SMSCGENCDR Configuration file

[smsgencdr]
[smscgencdr]
ProgName=smscgencdr
LogFileName=/home/jinny/log/smscgencdr
DebugLevel=1
AlarmProg=
Daemon=0
dbName=mc
dbUser=jinny
dbPass=jinny
output_path=/var/jinny/cdr/processed/
prefix=CDR_A
extension=.DAT
date=%y%m%d
time=%H%M%S
#sequenceno_digits=5
max_sequenceno=99999
rate=1500
granularity=1
burst=10
process_deleted_records=1
process_expired_records=1
process_prepaid_records=1
handle_concatenated_msg=0
msg_list_size=1000
max_msg_interval=10
msg_refresh_period=1
#group_services=0 means seperate CDR files group_services=1
means 1 CDR files
group_services=1
separator=
charge_status_report=0
create_empty_file=1
#sequential_scan=1
enable_keyword_detection=1
# 0->Use the normal fields in the [sm]/[sr] sections

# 1->Use the formatted fields in the [sm]/[sr] sections
format_fields=1
# The string values in the formatted fields are filled with the
following character
# (if is is empty it is filled with spaces)
string_filler=
# The following 2 flags are to enable the header and trailer in the
CDR files
enable_head=0
enable_tail=1

[header]
filler=IMSMSMDRH,
filler=V1.0,
timestamp=%m//%d//%y %H:%M:%S
[trailer]
start_date=%Y%m%d%H%M
end_date=%Y%m%d%H%M
count=%d
[sm]
messageid=%10d
#command=%1d
status=%2d
oaddrton=%1d
oaddrnpi=%1d
oaddr=%21s
daddrton=%1d
daddrnpi=%1d
daddr=%21s
priority=%1d
#rp=%1d
sri=%1d
pid=%3d
messagelen=%3d
type=%3d
#dcs=%3d
scts=%Y%m%d%H%M%S
donedate=%Y%m%d%H%M%S
validityperiod=%Y%m%d%H%M
scheddeliverytime=%Y%m%d%H%M
rxaimid=%10d
txaimid=%10d
msisdn=%21s
mref=%3d
#udhi=%1d
#mode=%1d
error=%3d
#service=%6d
#prepaid=%1d
#smsc_dest_table=%1d
mt_imsi=%15s
#message=%320s
aim_type=%3d
moservmsc=%21s
mtservmsc=%21s
#cmd_type=%2d
mo_imsi=%15s
#privacy=%1d
#reply_option=%1d
#language_ind=%3d
#cbni=%1d
#cbn_mode=%2d
#cbn=%33d
#display_mode=%1d
#deposit_index=%3d
#multi_encoding=%1d
#mo_esn=%10d
#mt_esn=%10d

sar= %1d
sar_ref=%3d
sar_total=%3d
sar_seqnum=%3d
service=%6s
[sr]
reportid=%10d
msisdn=%21s
status=%1d
mref=%3d
tp_status=%2d
scts=%Y%m%d%H%M
donedate=%Y%m%d%H%M
raddrton=%1d
raddrnpi=%1d
raddr=%21s
messageid=%10d
imsi=%15s
servmsc=%21s
prepaid=%1d
Example output CDR

File: CDR_A080707373215.DAT
0 311 5076756656801 6748583700 0 18
02007042605095420070426051003200704270609200704260509 0
0 50767485837 23 0714011011280926 0 5076999902
50769999077140110116266920 0 0 0 SMSCU
0 311 5076678036001 6678967700 0 40
02007042605195420070426051958200704270619200704260519 0
0 50766789677 96 0714011000176257 0 5076999906
50769999027140110002866870 0 0 0 SMSCU
0 321 111111 5076710144301127 15
02007042605194720070426051959200704270519200704260519 0
2 50767101443 0 0714011011366539 0
5076999906 1101 3 3 0
200704260510 200704260520 132
9.10. Database Configuration: High Availability

The database is configured from the same configuration file (smsc.ini) used
for all the processes installed on the Jinny SMSC platform. The database
server name, username, and password are all specified in this file. They
are required to connect to the database.
In a distributed architecture, each MPU node has its own database engine
running locally, and the data is first updated on the primary node then
distributed to all the other nodes. The failure of one node will not affect the
service, and on node restart the data is synchronized automatically.
In a smaller configuration where only one node is active, a secondary node
is necessary to avoid service interruption in the case of failure. This is
achieved by installing the database engine and all needed software on a
shared disk using an external RAID. A cluster manager (LINUX HA
Heartbeat) monitors the health of the 2 nodes, and will fail over the
running services to the partner node if the primary is no longer able to
provide the services. The failover do not require a manual intervention, and
all the data is totally preserved. The same method can be applied also in a
distributed architecture (each MPU can have a secondary passive node with
all the needed data on a shared disk).

9.11. SMSC Internal Service Types

The SMSC uses different service types for different traffic types (local,
international, offnet, roaming...). These service types are configured in the
smsc.ini configuration file. The following is a list of the available
configurable service types:

[smsc]
messages to be charged to a
sms_servicetype X(20) SMS99
prepaid customer for MO MT
messages
sr_servicetype X(20)
charging status reports
international_se <sms_servicetype
X(20) charging messages to
rvicetype value>
international MT
roaming_prepaid_ <sms_servicetype Service type used when
X(20)
servicetype value> charging Roaming prepaid
offnet_servicety <sms_servicetype Service type used when
X(20)
pe value> charging messages to offnet MT
messages to be charged to a
sms_servicetype_ <sms_servicetype
X(20) prepaid customer for MO MT
with_sr value>
messages when Status Report is
requested.
international_se
<international_serv charging messages to
rvicetype_with_s X(20)
r icetype value> international MT and Status
Report is requested.
roaming_prepaid_ Service type used when
<roaming_prepaid_
servicetype_with X(20) charging Roaming prepaid and
_sr servicetype value>
Status Report is requested.
offnet_prepaid_s Service type used when
<offnet_servicetype
ervicetype_with_ X(20) charging messages to offnet MT
sr value>
and Status Report is requested.
sponsor_servicet charging normal MO-MT
X(20)
ype messages that went through the
sponsoring module.
sponsor_internat
charging messages to
ional_servicetyp X(20)
e international MT that went
through the sponsoring module.
sponsor_roaming_
charging Roaming MO-MT
prepaid_servicet X(20)
ype messages that went through the
sponsoring module.

9.12. Prepaid Charging Module Configuration

The prepaid module configuration is contained in the prepaid_in.ini file. The
following is a list of the available parameters in this file:

[prepaid_in]
dbName X(255) The smsc database name
Username used to access the
dbUser X(255)
database
Password used to access the
dbPass X(255)
database
The hostname of the machine
host X(255)
hosting the RTCG
The port number used in the
port Integer
connection to the RTCG
The number of connections opened
towards the host/port. These
queuenbr Integer parameters are overridden by the
parameters in the [rtcg_nodes]
section if they exist
Value of the CPU sleeping time
between reference checks. Typically
timeout Integer 10
this should not be changed from
10ms
Timeout, in seconds, while
connect_timeout Integer 30
connecting to the RTCG
Period in seconds between ini file
refresh_period Integer 10
refresh
Period, in ms, between each
attempt to reference messages
reference_period Integer 1000
from the JQ to the main messages
pool
Timeout in seconds before receiving
response_timeout Integer 30
the response for a sent request
get_response_tim TCP timeout while attempting to
Integer 100
eout read a response
send_request_tim TCP timeout while attempting to
Integer 200
eout send a request
The size of the main pool of
window_size Integer 256 messages from which the other
child processes read messages
transaction_id_f /var/jinny/sh This is the transaction ID file used
X(255)
ile m/txid.cnt to get unique Txid
handle_concatena Flag to disable/enable handling
integer 0
ted_msg concatenated messages
/var/jinny/sh Name of the file containing the
qlist_filename X(255) m/prepaid_in_ concatenated messages to be
msg.DAT charged
Number of items that can be stored
qlist_size integer 1000 in the concatenated messages
buffer
Maximum time that a message
max_msg_time integer 60 spends in the concatenated
messages buffer expires

Period, in seconds, after which the

msg_refresh_peri prepaid_in attempts scanning the
integer 10
od concatenated messages list for
expired messages
If this flag is set to 1, then when
multi_request_on the parts of a concatenated
[0-1] 0
_concatenated messages are received, a request is
sent to the RTCG for each part
This is the number of requests sent
child_window_siz
e integer 50 simultaneously to the RTCG from
one connection
Prefix of the 15 digit sequence ID to
seqid_prefix integer 11 be used in this instance of the
prepaid_in
Semaphore key used to access the
mref_shm_key integer message reference shared memory
of this prepaid_in instance
Semaphore key used to access the
qlist_sem_key integer
concatenated messages list
Instance ID of the prepaid_in used
to enable starting multiple
instance integer
instances of the prepaid_in process
on the same machine
prepaid_jq_path X(255) Full path of the prepaid_in queue
prepaid_jq_exten Extent size of the prepaid_in queue
t integer 10000
prepaid_res_jq_p Full path of the prepaid_in result
X(255)
ath queue
prepaid_res_jq_e Extent size of the prepaid_in result
10000
xtent queue
Value used in the USER field when
charge_req_user X(21) SMSC
the charge request is sent
Granularity value used when setting
granularity Integer 1 the sending rate of the sending to
the RTCG
Burst value used when setting the
burst Integer 1 sending rate of the sending to the
RTCG
Rate value used when setting the
rate integer 1 sending rate of the sending to the
RTCG
refresh_services Period in seconds between each
Integer 60
_period attempt to refresh the services
Filename used to store the records
dat_filename X(255)
of data
Separator value used between
dat_separator X(32)
fields
dat_sem_key Operato Semaphore key used while
r accessing the dat file
In case we get the unknown
send_message_on_
subscriber error from the RTCG,
unknown_subscrib Integer
er we continue sending the message
as prepaid
In case we get the execution
retry_on_exec_fa
il Integer failed error from the RTCG, we
retry the same request right away

If this flag is enabled, we retry the

enable_seqid_ret
ry Integer message with the same sequence
ID
max_nb_retry Integer Maximum number of retries
retry_on_connect Retry sending the same requests in
Integer
ion_timeout case a connection timed out
If a request retrieved from the
charging_timeout Integer 0 prepaid JQ is older than this time in
seconds, it will be discarded
If use_sab_productid is not set, this
smsc_product_id X(255) 1111 value is sent to the RTCG in the
PRODUCT field
Maximum number of segments in a
concatenated message. If
max_allowed_conc
handle_concatenated_msg and the
atenated_segment [3-256] 100
s total number of segments of a
concatenated message exceeds this
value, the message is discarded
Flag to allow/reject concatenated
allow_disordered
_concatenated [0-1] 0 messages if the segments are not
received in order
Translation file used to translate
oaddr_translatio the originating address before
X(255)
n_file sending it to the RTCG in the
APARTY field
daddr_translatio the destination address before
X(255)
n_file sending it to the RTCG in the
BPARTY field
msisdn_translati the address to be charged before
X(255)
on_file sending it to the RTCG in the
MSISDN field
enable_send_comm Flag to enable/disable sending a
[0-1] 1
it commit request to the RTCG
enable_send_rese Flag to enable/disable sending a
[0-1] 0
rve reserve request to the RTCG
enable_send_canc Flag to enable/disable sending a
[0-1] 0
el cancel request to the RTCG
Flag to enable/disable charging the
B party if the A party charging was
enable_b_party_c
harging [0-1] 0 successful. This flag is usually used
in CDMA networks when both the A
and B party are charged
enable_send_b_pa Checked only if:
[0-1] 1
rty_reserve enable_b_party_charging is set
[0-1] 1
rty_commit enable_b_party_charging is set
[0-1] 1
rty_cancel enable_b_party_charging is set
This should be set if:
enable_b_party_charging. If the B
party charging fails with unknown
mnp_esme_rxid Integer 0
subscriber, we should send the
message to the receiving ESME
defined by this id
Type of the receiving ESME (usually
mnp_esme_type [0-2] 0
0 for SMPP)

This is used only if the prepaid_in is

running in pass through mode. This
prepaid_error [0-33] 6 error is used if the fail percentage
is not 0. The default value is for the
negative amount
Flag to enable/disable keyword
detection inside the message.
If all the keyword flags below are
set to 0, this flag is used to get the
keyword in MO-ESME and ESME-
ESME messages. If found, it will be
used to set the appropriate
enable_keyword_d
etection [0-1] 0 VASCLASS used to charge the
message (the configuration of the
Keywords is done using the Jinny
SMSC GUI).
If any of the keyword flags are set
to 1, the message will be parsed
and the first word will be sent to
the RTCG in the KEYWORD field
Flag to enable/disable sending
keyword_mo_mt [0-1] 0
keywords for MO-MT messages
keyword_roaming_
mo_mt [0-1] 0 keywords for roaming MO-MT
messages
keyword_mo_esme [0-1] 0
keywords for MO-ESME messages
keyword_esme_mt [0-1] 0
keywords for ESME-MT messages
In case of a binary message and in
case the keyword parsing is
binary_keyword_l
ength Integer 0 enabled, the keyword sent to the IN
has a length of
binary_keyword_length
If set, the amount is set to the
amount_multiplie value in the AMOUNT field received
Integer 1
r in the response x the
amount_multiplier
If the vlrid is set and the serving
default_vlr_id X(63) MSC is not available, this value is
set in the VLRID sent to the RTCG
Prefix added to the B party if the
fwd_prefix X(31) request to be sent is for a
forwarded message
Flag to enable/disable counting the
characters of the message. The
characters are counted based on
the datacoding of the message:
enable_character Text count = sum of characters in
[0-1] 0
_count all segments
Binary count = 160 x number of
segments
UCS2 count = sum of UCS2
characters in all segments
If the vlrid and cellinfo_in_vlrid are
set, the cell info is passed to the
cellid_dest_expr X(255)
RTCG in the VLRID if the B party
matches this regular expression

Prefix added to the cellid. The cellid

cellid_prefix_mc format is:
X(6) 000000
c_mnc <cell_id_prefix_mcc_mn><4-digit
lac><4-digit ci>
teleservice_code String set in the TELESRVCCODE
X(255) 65532
field if required

[rtcg_nodes]
The purpose of this section is to enable the prepaid_in to connect to multiple nodes.
Each node is defined by a different <index> line.
In each node, we define the number of TCP connections to be opened towards this
node.
We then define the node by a list host/port. The prepaid_in first connects to
host1/port1 and in case this connection is lost, it connects to host2/port2, and so on
until host(n)/port(n).
We also define a flag (<cycle hosts>), which can be 0 or 1, that configures the
behaviour in case the connection is lost with host(n)/port(n).
0 - The connection stays down until the process is manually restarted after checking
the problem.
1 - The process attempts to reconnect to host1/port1.
This [rtcg_nodes] section overrides the already existing host/port/queuenbr values in

the prepaid_in.ini, [prepaid_in] section.
In case no nodes have been defined in the [rtcg_nodes] section, then the old values
host/port/queuenbr will be used (for backward compatibility).

10. SMSC-SNMP TRAPS

Jinny defines 5 trap types:
SNMP trap OID
critical enterprises.jinny.x733.0.1
major enterprises.jinny.x733.0.2
minor enterprises.jinny.x733.0.3
warning enterprises.jinny.x733.0.4
cleared enterprises.jinny.x733.0.5
The variables bind in all JINNY trap types contains the following:
Variable Description
hostName The host from where the alarm was
emitted
eventTime The time the alarm was emitted
eventType 1(program alive status)
4(shells alarms)
probableCause 47
perceivedSeverity Alarm severity level:
1(critical)
2(major)
3(minor)
4(warning)
5(cleared)
managedObjectInstance The component affected by the problem
additionalText A message regarding the trap been sent
The most common SNMP traps emitted by Jinny SMSC:

managedObjectInstance Level Message
1 CPU_1
2 CPU_2
CPU 3 CPU_3
4 CPU_4
5 CPU_5
1 DISK_1
2 DISK_2
DISK_STORAGE_$BDEV 3 DISK_3
4 DISK_4
5 DISK_5
1 MEM_1
2 MEM_2
MEMORY 3 MEM_3
4 MEM_4
5 MEM_5
1 BROAD_QUE_1
2 BROAD_ QUE_2
BROADCAST_QUEUE
3 BROAD_ QUE_3
(jbrdmsgshm.sh)
4 BROAD_ QUE_4
5 BROAD_ QUE_5
1 MESS_QUE_1
2 MESS_QUE_2
MESSAGES_QUEUE
3 MESS_QUE_3
(jnormalmsgshm.sh)
4 MESS_QUE_4
5 MESS_QUE_5
1 FAILED_MESS_1
FAILED_MESSAGES
2 FAILED_MESS_2
(jfailedmon.sh)
3 FAILED_MESS_3

4 FAILED_MESS_4
5 FAILED_MESS_5
1 MESS_TAB_1
2 MESS_TAB_2
MESSAGES_TABLE
3 MESS_TAB_3
(jmessagesmon.sh)
4 MESS_TAB_4
5 MESS_TAB_5
1 WAIT_TAB_1
2 WAIT _TAB_2
WAITING_TABLE
3 WAIT _TAB_3
(jwaitingmon.sh)
4 WAIT _TAB_4
5 WAIT _TAB_5
1 smsqueuemon_1
4 smsqueuemon_2
SMSC 1 smsqueuemon_3
(smsqueuemon.sh - crontab) 4 smsqueuemon_4
1 smsqueuemon_5
4 smsqueuemon_6
cdr_generation 1 cdr_generation_1
(ftpcdr.sh cdralarm.sh) 4 cdr_generation_4
HEARTBEAT
3 primary_3
(jheartbeat.sh)
HEARTBEAT
3 secondary_3
(jheartbeat.sh)
JAR_RECEIVER 1 JAR_RECEIVER_1
(jar_receiver.sh) 5 JAR_RECEIVER_5
1 PREP_QUE_1
2 PREP_QUE_2
PREPAID_JQ
3 PREP_QUE_3
(jprepaid.sh)
4 PREP_QUE_4
5 PREP_QUE_5
smsc.alive
smsc.aim-alive
sync_db.alive
jsync.alive
jsync.jfsync_alive
1- Program is dead
jsync.jfsync_client_alive 1 or 5
5- Program is alive
smsc.prepaid-tx-alive
smsc.gmsc<nb>-conn-alive
smsc.<esme>-rx-alive
smsc.<esme>-tx-alive
smsc.<esme>-trx-alive
$BDEV :can be any device partition

<sid> :The system id

TRAP messages definitions:
BROAD_QUE_1 = The Number of broadcast messages is too high, the

SIUs might be not working properly or some ESME might be broadcasting
using a high rate. Please check the rate used by the main Broadcasting
ESMEs or Distribution Users. In case no action was taken, the smsc will
reject the broadcast messages.
BROAD_QUE_2 = The Number of broadcast messages is very serious, the
SIUs might be stopped or some ESME might be broadcasting using a high
rate.Please check the rate used by the main Broadcasting ESMEs or
Distribution Users. In case no action was taken, the smsc will reject the
broadcast messages.
BROAD_QUE_3 = The Number of broadcast messages is increasing,
please check if the SIUs are working normally, and at the same time check
the rate assigned to Broadcasting ESMEs. In case this number increases
more and more, the smsc will stop receiving the broadcast messages.
BROAD_QUE_4 =It seems that the Number of broadcast messages is
reaching high values, it is not yet critical, but you may check if the SIUs
are working normally and also check the rate assigned to Broadcasting
ESMEs.In case this number keeps increasing, it could reach its maximum
value and the smsc will stop receiving broadcast messages.
BROAD_QUE_5 =The Number of Broadcast Messages sent to the smsc is
normal, no action needed.
cdr_generation_1= the generation of cdr files failed

cdr_generation_4= the generation of cdr files succeeded
CPU_1 = The CPU Load is currently critical $NUM_LOAD_AVG%; some
programs might be overloading the CPU; please execute the top command,
check which processes are consuming high CPU resources and inform the
system administrator. If this alarm remains not cleared, the performance
of the machine will degrade and this will affect seriously any system
running on it
CPU_2 = The status of the CPU Load is very serious $NUM_LOAD_AVG%,
some programs might be overloading the CPU; please execute the top
command, check which processes are consuming high CPU resources and
inform the system administrator. If this alarm remains not cleared, the
severity of the CPU Load may increase and the performance of the machine
will degrade and this will affect seriously any system running on it
CPU_3 = The status of the CPU Load is minor $NUM_LOAD_AVG%, you
need to check which processes are consuming this load, please execute the
top command and inform the system administrator. Please consider this
alarm seriously in order to prevent any increase in its severity.
CPU_4 = This is just a warning alarm to inform you that the Load on the
CPU is $NUM_LOAD_AVG%; some processes might be using high loads,
please execute the top command and inform the system administrator.
Kindly take this alarm into consideration in order to prevent any increase in
its severity.
CPU_5 = The Load of the CPU is normal ($NUM_LOAD_AVG%), it is below
the warning level
DISK_1 = The storage on \"$BDEV\" partition reached a critical value

($USED_SP %); this might be due to some extra files. Please check if some
log files are growing too fast or if there are some large unused files that
can be deleted, you may check the Debug Level of the main processes and
also inform the system administrator. In case no action is taken, the
system will be seriously affected.
DISK_2 = The status of the CPU Load is very serious $NUM_LOAD_AVG%,
some programs might be overloading the CPU; please execute the top
command, check which processes are consuming high CPU resources and

inform the system administrator. If this alarm remains not cleared, the
severity of the CPU Load may increase and the performance of the machine
will degrade and this will affect seriously any system running on it
DISK_3 = The storage on \"$BDEV\" partition is still minor ($USED_SP
%), some log files could be growing fast or some unused files need to be
cleaned. Please check large files on this partition and contact your system
administrator. Please consider this alarm seriously in order to prevent any
increase in its severity.
DISK_4 = This is just a warning alarm to inform you that the storage on
\"$BDEV\" partition is increasing ($USED_SP %); you need to check large
files and inform the system administrator. Kindly take this alarm into
consideration in order to prevent any increase in its severity.
DISK_5 = The storage on \"$BDEV\" partition is normal ($USED_SP %), it
is below the warning level.
FAILED_MESS_1 =The Percentage of System Failed messages is critical
($RATIO). It could be due to a Network failure or SIU malfunctioning. You
need to check the Links and the GSM Network, and in case of SIU
malfunctioning, please contact your system administrator. In case no
action was taken, the number of failed messages will increase.
FAILED_MESS_2 =The Percentage of System Failed messages is very
serious ($RATIO). It could be due to a Network failure or SIU
malfunctioning. You need to check the Links and the GSM Network, and in
case of SIU malfunctioning, please contact your system administrator. In
case no action was taken, the number of failed messages will increase.
FAILED_MESS_3 =The Percentage of System Failed messages is
increasing ($RATIO); please check if there is any Network failure, and if
not, contact your system administrator in order to check if the SIUs are
working properly. If the Number of failed messages increases, there will be
degradation in the system
FAILED_MESS_4 =The Percentage of System Failed messages is reaching
high values ($RATIO); it is not yet critical, but you may check if the SIUs
are working normally and also check if there is any Network failure. If the
Number of failed messages increases, there will be degradation in the
system
FAILED_MESS_5 =The Percentage of System Failed messages is normal,
no action needed.
JAR_RECEIVER_1=jar receiver is not running.

JAR_RECEIVER_5=jar receiver is running.
MEM_1 = The MEMORY Usage is currently critical $MEM_LOAD_AVG%;

some programs might be overusing the MEMORY; please execute the top
command, check which processes are consuming high MEMORY resources
and inform the system administrator. If this alarm remains not cleared, the
performance of the machine will degrade and this will affect seriously any
system running on it
MEM_2 = The status of MEMORY Usage is very serious
$MEM_LOAD_AVG%, some programs might be overusing the MEMORY;
please execute the top command, check which processes are consuming
high MEMORY resources and inform the system administrator. If this alarm
remains not cleared, the severity of MEMORY Usage may increase and the
performance of the machine will degrade and this will affect seriously any
system running on it
MEM_3 = The status of MEMORY Usage is minor $MEM_LOAD_AVG%, you
need to check which processes are consuming this memory, please
execute the top command and inform the system administrator. Please
consider this alarm seriously in order to prevent any increase in its
severity.

MEM_4 = This is just a warning alarm to inform you that the Usage of
MEMORY is $MEM_LOAD_AVG%; some processes might be using high
memory, please execute the top command and inform the system
administrator. Kindly take this alarm into consideration in order to prevent
any increase in its severity.
MEM_5 = The Usage of MEMORY is normal ($MEM_LOAD_AVG%), it is
below the warning level.
MESS_QUE_1 =The Number of messages in the queue is very critical, the

MO traffic might be too high, please check if the SIUs might be not working
properly or some ESME/Distribution Users might be sending messages
using high rate. In case no action was taken, the smsc will stop processing
the messages and they will be saved in a sort of external database, in
order to be sent later. Please contact your system administrator
MESS_QUE_2 =The Number of messages in the queue is very serious, the
MO traffic might be too high; please check if the SIUs might be not working
properly or some ESME/Distribution Users might be sending messages
using high rate.Please contact your system administrator and in case no
action was taken, the number of messages in the queue will increase and
once reached its maximum value, the smsc will stop processing the
messages and they will be saved in a sort of external database, in order to
be sent later.
MESS_QUE_3 =The Number of messages in the queue is increasing, the
MO traffic might be higher than usual; please check if the SIUs are
working properly or if any ESME/Distribution User is sending messages
using high rate. The number of messages in the queue may increase and
once reached its maximum value, the smsc will stop processing the
messages and they will be saved in a sort of external database, in order to
be sent later.
MESS_QUE_4 =It seems that the Number of messages in the queue is
reaching high values, it is not yet critical, but you may check if the SIUs
are working normally and also check the rate assigned to
ESMEs/Distribution Users. In case this number keeps increasing, it could
reach its maximum value and the smsc will stop processing the messages
and they will be saved in a sort of external database, in order to be sent
later.
MESS_QUE_5 =The MO Traffic on the smsc is normal, no action needed.
MESS_TAB_1 = The failed messages that need to be retried are stored in

the messages table. The number of records in this table is currently critical
($MESS_COUNT). It could be due to an overload on the system, or it could
be due to high number of errors (especially at night).Please make sure that
the automatic overflow is enabled, if not, please contact the system
administrator. In case the overflow was not enabled, the system
performance will degrade as long as the number of records in the
messages table will increase.
MESS_TAB_2 = "The failed messages that need to be retried are stored in
the messages table. The Number of records in this table is very serious
($MESS_COUNT). It could be due to an overload on the system, or it could
be due to high number of errors (especially at night). Please make sure
that the automatic overflow is enabled, if not, please contact the system
administrator. In case the overflow was not enabled, the system
performance will degrade as long as the number of records in the
messages table still increases.
MESS_TAB_3 = The messages that need to be retried are stored in the
messages table. The number of records in this table is high
($MESS_COUNT); it could be due to an overload on the system, or it could
that the automatic overflow is enabled in order to prevent any degradation

in the system performance if the number of records in the messages table

keeps increasing.
MESS_TAB_4 = The messages that need to be retried are stored in the
messages table. The number of records in this table is increasing
($MESS_COUNT); it could be due to an overload on the system, or it could
that the automatic overflow is enabled in order to prevent any degradation
in the system performance if the number of records in the messages table
keeps increasing.
MESS_TAB_5 = The number of records in the messages table is normal
($MESS_COUNT).
primary_3=Switch to primary machine.
secondary_3= Switch to secondary machine due to primary failure.

smsqueuemon_1= the number of messages exceeds the threshold
$MAXMESS.
smsqueuemon_2= the number of messages is below the threshold
$MAXMESS.
smsqueuemon_3= the number of waiting msisdn exceeds the threshold
$MAXWAIT.
smsqueuemon_4= the number of waiting msisdn is below the threshold
$MAXWAIT.
smsqueuemon_5= the number of prepaid records exceeds the threshold
$MAXPREP.
Smsqueuemon_6= the number of prepaid records is below the threshold
$MAXPREP.
WAIT_TAB_1 = The msisdn(s) of the MT subscribers that did not receive

successfully their messages are stored in the waiting table. The number of
records in this table is currently critical ($WAIT_COUNT). It could be due to
an overload on the system, or it could be due to high number of errors
(especially at night). The automatic overflow is not enabled, or it is not
working properly, please contact the system administrator. In case the
overflow was not enabled, the system performance will degrade.
records in this table is very serious ($WAIT_COUNT). It could be due to an
overload on the system, or it could be due to high number of errors
(especially at night). Please make sure that the automatic overflow is
enabled, if not, please contact the system administrator. In case the
overflow was not enabled, the system performance will degrade as long as
the number of records in the waiting table still increases.
records in this table is high ($WAIT_COUNT); it could be due to an
enabled in order to prevent any degradation in the system performance if
the number of records in the waiting table keeps increasing.
records in this table is increasing ($WAIT_COUNT); it could be due to an
enabled in order to prevent any degradation in the system performance if
the number of records in the waiting table keeps increasing.
WAIT_TAB_5 = The number of records in the waiting table is normal
($WAIT_COUNT).

PREP_QUE_1 = The Number of messages in the prepaid queue is very

critical, the MO traffic might be too high, please check if the
prepaid_in/RTCG/IN is not working properly or some ESME/Distribution
Users might be sending messages using high rate. In case no action was
taken, there will be a severe delay on the messages delivery. Please
contact your system administrator
PREP_QUE_2 = The Number of messages in the prepaid queue is very
serious, the MO traffic might be too high; please check if the
prepaid_in/RTCG/IN is not working properly or some ESME/Distribution
Users might be sending messages using high rate.Please contact your
system administrator and in case no action was taken, there will be a
severe delay on the message delivery.
PREP_QUE_3 = The Number of messages in the prepaid queue is
increasing, the MO traffic might be higher than usual; please check if the
prepaid_in/RTCG/IN are working properly or if any ESME/Distribution User
is sending messages using high rate.
PREP_QUE_4 = It seems that the Number of messages in the prepaid
queue is reaching high values, it is not yet critical, but you may check if
the prepaid_in/RTCG/IN are working normally and also check the rate
assigned to ESMEs/Distribution Users.
PREP_QUE_5 = The traffic on the prepaid is normal, no action needed.

11. CHARGING SCENARIOS

11.1. SMS-MO Charge Ack
MSC SMSC RTCG IN
1 - MO-ForwardSM
2 - Charge or Reserve
Charge or Reserve
Wait for response Charge or reserve ACK
3 - Charge or reserve ACK
Queue message for delivery
4 - MO-ForwardSM-ACK
The SMSC receives a MOForwardSM from the MSC.

A Charge or Reserve request is sent from the SMSC to the RTCG.
The RTCG sends an ACK response to the SMSC.
The SMSC sends a MOForwardSM Ack to the MSC.

11.2. SMS-MO Charge Nack
MSC SMSC RTCG IN
1 - MO-ForwardSM
Charge or Reserve
Wait for response

Charge or Reserve NACK
3 - Charge or Reserve NACK
4 - MO-ForwardSM-NACK

The RTCG sends an error response to the SMSC.
The SMSC sends a MOForwardSM Nack to the MSC.

11.3. SMS-MO Charge timeout Ack
MSC SMSC RTCG IN
1 - MO-ForwardSM
Wait for response

Charge or Reserve
Timeout - Queue message for billing

Charge or Reserve ACK
4 - Charge or Reserve ACK

The RTCG does not send any response in a predefined period so the
SMSC sends an ACK response to the SMSC, and the message is queued
for billing.
The RTCG sends an ACK response to the SMSC.

11.4. SMS-MO Charge timeout Nack
MSC SMSC RTCG IN
1 - MO-ForwardSM
Charge or Reserve
Wait for response
Timeout - Queue message for billing

Charge or Reserve NACK
4 - Charge or Reserve NACK
5 - Flash message NACK

The RTCG does not send any response in a predefined period so the
SMSC sends an ACK response to the SMSC, and the message is queued
for billing.
The RTCG sends an error response to the SMSC.
The SMSC sends a Flash message to the MSC to notify the sender that
the message was actually not sent.

11.5. Commit after delivery
MSC SMSC RTCG IN
1 - MO-ForwardSM
2 - Reserve
Reserve
response
Wait for
Reserve ACK with commit on
3 - Reserve ACK with commit on delivery
delivery
5 - MT-ForwardSM
6 - MT-ForwardSM ACK
7 - Commit
Commit
Commit ACK
8 - Commit ACK

A Reserve request is sent from the SMSC to the RTCG.
The RTCG sends an ACK response to the SMSC, with a parameter
telling the SMSC to commit the reserved amount on delivery of the
message.
The SMSC sends an MT-ForwardSM to the MSC.
The MSC sends an MT-ForwardSM Ack to the SMSC.
The SMSC sends a Commit request to the RTCG.
A commit request Ack is received from the RTCG.

11.6. Commit After Submission
MSC SMSC RTCG IN
1 - MO-ForwardSM
2 - Reserve
Reserve
response
Wait for
Reserve ACK with commit on
3 - Reserve ACK with commit on delivery
delivery
4 - Commit
Commit
Commit ACK
5 - Commit ACK
7 - MT-ForwardSM
8 - MT-ForwardSM ACK

telling the SMSC to commit the reserved amount on submission of the
message.
The SMSC sends a Commit request to the RTCG.
A commit request Ack is received from the RTCG.
The MSC sends an MT-ForwardSM Ack to the SMSC.

11.7. Cancel after permanent error

In case of a permanent error, the prepaid module can be optionally configured to
send a Cancel request to the IN. Otherwise; the reserve request sent to the IN will
timeout and then gets cancelled automatically.
MSC SMSC RTCG IN
1 - MO-ForwardSM
2 - Reserve
Reserve
response
Wait for
Reserve ACK with commit
3 - Reserve ACK with commit on on delivery
delivery
5 - MT-ForwardSM
6 - MT-ForwardSM NACK
with permanent error
7 - Cancel
Cancel
8 - Cancel ACK
8 - Cancel ACK

telling the SMSC to commit the reserved amount on delivery of the
message.
The MSC sends an MT-ForwardSM Nack to the SMSC, containing a
permanent error.
In case it is configured, the SMSC sends a Cancel request to the RTCG.
In case it is configured, a Cancel request Ack is received from the
RTCG.

12. CHARGING PROTOCOL FIELDS

12.1. Fields in case of Reserve/Charge
Field Description
CMD The command identifier, it could be charge or reserve.
SEQID The sequence id of the request. This should be a 15 digit unique
string for each request.
DLGID This field must be returned as it is from the RTCG. It is used by
the smsc prepaid module for performance enhancements.
MSISDN The MSISDN of the party to be charged.
RATE This field is currently always set to 1.
USER This field is set as defined by the parameter charge_req_user
defined in the prepaid_in.ini.
PRODUCT This field is set as defined by the parameter smsc_product_id
APARTY The msisdn of the sender of the message.
BPARTY The msisdn of the recipient of the message.
VASCLASS The service type used for this type of message (local,
international, mo-esme etc). This field is mainly used for rating
on the IN.
VLRID This field contains the address of the MSC where the sender of the
message is attached.
ESMCLASS This field contains the ESM class of the message in SMPP format:
0 -> 0
1 -> 0x40 = 0100 0000
DATACODING This field contains the data coding of the message
HEXMESSAGE The actual content of the message in HEX format.
UNITS The number of concatenated parts of the message in case the
prepaid module is configured to send only one request in case of
concatenated messages.
CONCAT (This field is not used in the normal cases)
DTON Destination type of network.
DNPI Destination numbering plan indicator.
STON Source type of network.
SNPI Source numbering plan indicator.
LAC This field ciontains the Location Area Code of the sender.
CELLID This field ciontains the Cell ID of the sender.
TELESERVCODE This field is set as defined by the parameter teleservice_code
AMOUNT This field is set to 0 in normal cases. In case we know what the
amount to be deducted is, we can put it in this field and the RTCG
will not have to query the rating engine again.
PURPOSE In case the PURPOSE field is returned from the IN, we send it back
to the IN as it is in case we need to retry the request.
KEYWORD This field contains the first word of the message.
RETRY In case a message is retried, then this field is set to the value of
the number of retries.

12.2. Fields in case of Commit/Cancel

Field Description
CMD The command identifier, it could be commit or cancel.
SEQID The sequence id of the request. This should be a 15 digit unique
string for each request.
DLGID This field must be returned as it is from the RTCG. It is used by
the smsc prepaid module for performance enhancements.
MSISDN The MSISDN of the party to be charged.
USER This field is set as defined by the parameter charge_req_user
APARTY The msisdn of the sender of the message.
BPARTY The msisdn of the recipient of the message.
VASCLASS The service type used for this type of message (local,
international, mo-esme etc). This field is mainly used for rating
on the IN.
UNITS The number of concatenated parts of the message in case the
prepaid module is configured to send only one request in case of
concatenated messages.

13. CONFORMANCE
The Jinny SMSC conforms to the following standards:
MTP ITU-T Q.700 - Q.707 Message Transfer Part

ITU-T Q.791 Monitoring and measurements
ITU-T Q.781 MTP level 2 test specification
ITU-T Q.782 MTP level 3 test specification
ANSI T1.111-1992 Message Transfer Part
SCCP ITU-T Q.711 Functional description of the Signalling
connection Control Part
ITU-T Q.712 Definition and function of the Signalling and
Connection Control Part messages
ITU-T Q.713 Signalling and Connection Control Part formats
and codes
ITU-T Q.714 Signalling and Connection Control Part
procedure
ETSI ETS 300 589
ANSI T1.112 Signalling Connection Control Part
TCAP ITU-T Q.771 Functional description of transaction capabilities
1988, 1993
ITU-T Q.772 Transaction capabilities information elements
definitions 1988, 1993
ITU-T Q.773 Transaction capabilities formats and encoding
1988, 1993
ITU-T Q.774 Transaction capabilities procedures 1988, 1993
ITU-T X.680 Abstract Syntax Notation One (ASN.1)
ITU-T X.690 Basic encoding rules for ASN.1
ETSI ETS 300 134 Transaction Capabilities Application Part
(TCAP) 1992
ETSI ETS 300 287 Transaction Capabilities Application Part v
2 (TCAP) 1993
ANSI T1.114 Transaction Capabilities Application Part
MAP GSM 09.02 Version 4.19.1 ETSI ETS 300 599 MAP Phase 2
GSM 09.02 Version 7.15.0 ETSI ETS 300 794 MAP Phase
2+
3GPP 29.002 Version 5.11.0 3GPP Release 5
ANSI41- ANSI/TIA/EIA-41.5-D Cellular Radiotelecommunications
MAP Intersystem Operations for Short Message Service (SMS)
SMS GSM 03.38 Version 7.2.0 ETSI ETS 300 900 Phase 2+
Alphabets
SMS GSM 03.40 Version 7.5.0 ETSI ETS 300 901 Phase 2+

UCS2 ISO/IEC10646: Universal Multiple-Octet Coded Character

Set (UCS); UCS2, 16-bit coding International Standards
Organization
SMPP Short Message Peer to Peer - Interface Specification, Version
3.4, LogicaCMG
EMI/UCP Short Message Service Centre - EMI-UCP Interface
Specification, Version 3.5, CMG Telecommunications &
Utilities BV, Division Advanced Technology, December 1999
OIS Sema SMSC Version G8.1 Open Interface Specification,
Version 5.8, Sema
Smart Smart Messaging - Specification, Revision 3.0.0, Nokia Mobile
Messaging Phones Ltd.
EMS Developers Guidelines - Enhanced Messaging Service, First
Edition, Ericsson Mobile Communications AB, May 2001
Table 13-1 Jinny SMSC Conformance

14. COMPLIANCY TABLE

Fully Partially Not Not Informative
Compliant Compliant Compliant Applicable
FC PC NC N/A IN
Table 14-1 - Acronyms
The table below provides information about the compliance of Jinny Short
Messaging Service Centre (SMSC) release 3.6 with the SMS functional
description provided by the 3GPP documents (GSM 03.40 Version 7.5.0
ETSI ETS 300 901 Phase 2+, 3GPP 23.040 Version 5.8.1 3GPP Release
5).
Section Compliancy Comments

Foreword IN
Introduction IN
1. Scope IN
2. References
2.1 Definitions and abbreviations IN
2.1.1 Definitions IN
2.1.2 Abbreviations IN
3. Services and Service Elements
3.1 Basic services FC
3.2 Short Message Service elements
3.2.1 Validity Period FC
3.2.2 Service Centre Time Stamp FC
3.2.3 Protocol Identifier FC
3.2.4 More Messages to Send FC
3.2.5 Delivery of Priority and non Priority Messages FC
3.2.6 Messages Waiting FC
3.2.7 Alert SC FC
3.2.8 Options concerning MNRG, MNRF, MNRR, MCEF FC
and MWD
3.2.9 Status report capabilities FC
3.2.10 Reply Path FC Refer to
Annex D
3.3 Unsuccessful short message TPDU transfer SC > FC
MS
3.3.1 Errors occurring during transfer of TPDU to MS FC
3.3.2 Errors occurring after TPDU arrives at MS FC
3.4 Unsuccessful short message TPDU transfer MS > FC
SC
3.4.1 Errors occurring during transfer of TPDU to SC FC
3.4.2 Errors occurring after TPDU arrives at SC FC
3.5 Use of Supplementary Services in combination FC
with the Short Message Service
3.6 Applicability of Operator Determined Barring to FC
the Short Message Service
3.7 Multiple short message transfer FC


3.8 SMS and Internet Electronic Mail interworking FC
3.8.1 Basic Format FC
3.8.2 Optional Fields FC
3.8.2.1 Subject FC
3.8.2.2 Real Name FC
3.8.2.3 Optional Control Flag FC
3.8.3 Text concatenation FC
3.8.4 Alternative characters for Internet email FC
addresses in MO SMS.A115
3.9 SMS COMPRESSION FC
3.10 Enhanced Messaging Service FC
3.10.1 Text formatting FC
3.10.2 Pictures FC
3.10.3 Animations FC
3.10.4 Sound FC
3.10.5 vCard and vCalendar FC Transparent
with the
SMSC
3.10.6 WVG (Wireless Vector Graphics) Object FC Transparent
with the
SMSC
3.10.6.1 Overview of WVG Graphical Primitives FC Transparent
with the
SMSC
4. Network architecture
4.1 Basic network structure FC
4.2 Transfer on link 3 FC
5. Service Centre and PLMN interconnection
5.1 Service centre connection FC
5.2 Routing requirements FC
5.2.1 Mobile terminated short message FC
5.2.2 Mobile originated short message FC
6. Service Centre functionality
6.1 Service Centre capabilities FC
6.2 SC functional requirements FC
6.2.1 Subaddressing support NC
6.3 SC EMS Extended Object Data Request FC
Command Feature
7. MS functionality
7.1 MS capabilities N/A
7.2 MS configuration N/A
8. Node functionality
8.1 Node functionality related to SM MT FC
8.1.1 Functionality of the SMS GMSC FC
8.1.2 Functionality of the MSC N/A
8.1.3 Functionality of the SGSN N/A


8.2 Node functionality related to SM MO FC
8.2.1 Functionality of the MSC N/A
8.2.2 Functionality of the SMS IWMSC FC
8.2.3 Functionality of the SGSN N/A
8.3 SMS IWMSC functionality related to alerting FC
9. Protocols and protocol architecture
9.1 Protocol element features FC
9.1.1 Octet and Bit transmission order FC
9.1.2 Numeric and alphanumeric representation FC
9.1.2.1 Integer representation FC
9.1.2.2 Octet representation FC
9.1.2.3 Semi octet representation FC
9.1.2.4 Alphanumeric representation FC
9.1.2.5 Address fields FC
9.2 Service provided by the SM TL FC
9.2.1 General FC
9.2.2 PDU Type repertoire at SM TL FC
9.2.2.1 SMS DELIVER type FC
9.2.2.1a SMS DELIVER REPORT type NC Roadmap:
SMSC v.4.0
9.2.2.2 SMS SUBMIT type FC
9.2.2.2a SMS SUBMIT REPORT type NC Roadmap:
SMSC v.4.0
9.2.2.3 SMS STATUS REPORT type FC
9.2.2.4 SMS COMMAND type FC
9.2.3 Definition of the TPDU parameters
9.2.3.1 TP Message Type Indicator (TP MTI) FC
9.2.3.2 TP More Messages to Send (TP MMS) FC
9.2.3.3 TP Validity Period Format (TP VPF) FC
9.2.3.4 TP Status Report Indication (TP SRI) FC
9.2.3.5 TP Status Report Request (TP SRR) FC
9.2.3.6 TP Message Reference (TP MR) FC
9.2.3.7 TP Originating Address (TP OA) FC
9.2.3.8 TP Destination Address (TP DA) FC
9.2.3.9 TP Protocol Identifier (TP PID) FC
9.2.3.10 TP Data Coding Scheme (TP DCS) FC
9.2.3.11 TP Service Centre Time Stamp (TP SCTS) FC
9.2.3.12 TP Validity Period (TP-VP) FC
9.2.3.12.1 TP-VP (Relative format) FC
9.2.3.12.2 TP-VP (Absolute format) FC
9.2.3.12.3 TP-VP (Enhanced format) FC
9.2.3.13 TP Discharge Time (TP DT) FC
9.2.3.14 TP Recipient Address (TP RA) FC
9.2.3.15 TP Status (TP ST) FC


9.2.3.16 TP User Data Length (TP UDL) FC
9.2.3.17 TP Reply Path (TP RP) FC
9.2.3.18 TP Message Number (TP MN) FC
9.2.3.19 TP Command Type (TP CT) FC
9.2.3.20 TP Command Data Length (TP CDL) FC
9.2.3.21 TP Command Data (TP CD) FC
9.2.3.22 TP Failure Cause (TP FCS) FC
9.2.3.23 TP User Data Header Indicator (TP UDHI) FC
9.2.3.24 TP User Data (TP UD) FC
9.2.3.24.1 Concatenated Short Messages FC
9.2.3.24.2 Special SMS Message Indication FC
9.2.3.24.3 Application Port Addressing 8 bit address FC
9.2.3.24.4 Application Port Addressing 16 bit address FC
9.2.3.24.5 SMSC Control Parameters FC
9.2.3.24.6 UDH Source Indicator FC
9.2.3.24.7 (U)SIM Toolkit Security Headers FC
9.2.3.24.8 Concatenated short messages, 16-bit FC
reference number
9.2.3.24.9 Wireless Control Message Protocol FC
9.2.3.24.10 Enhanced Messaging Service FC
9.2.3.24.10.1 EMS Coding FC
9.2.3.24.10.1.1 Text Formatting N/A Transparent
with the
SMSC
9.2.3.24.10.1.2 Predefined Sound N/A Transparent
with the
SMSC
9.2.3.24.10.1.3 User Defined Sound N/A Transparent
with the
SMSC
9.2.3.24.10.1.4 Predefined Animation N/A Transparent
with the
SMSC
9.2.3.24.10.1.5 Large Animation N/A Transparent
with the
SMSC
9.2.3.24.10.1.6 Small Animation N/A Transparent
with the
SMSC
9.2.3.24.10.1.7 Large Picture N/A Transparent
with the
SMSC
9.2.3.24.10.1.8 Small Picture N/A Transparent
with the
SMSC
9.2.3.24.10.1.9 Variable Picture N/A Transparent
with the
SMSC
9.2.3.24.10.1.10 User Prompt Indicator N/A Transparent
with the
SMSC


9.2.3.24.10.1.11 Standard WVG Object N/A Transparent
with the
SMSC
9.2.3.24.10.1.12 Character Size WVG Object N/A Transparent
with the
SMSC
9.2.3.24.10.1.13 Extended Object N/A Transparent
with the
SMSC
9.2.3.24.10.1.14 Reused Extended Object N/A Transparent
with the
SMSC
9.2.3.24.10.1.15 Compression Control N/A Transparent

with the
SMSC
9.2.3.24.10.1.15.1 LZSS Implementation for EMS N/A Transparent
extended object compression with the
SMSC
9.2.3.24.10.1.15.2 Data Compression N/A Transparent
with the
SMSC
9.2.3.24.10.1.15.3 Data De-compression N/A Transparent
with the
SMSC
9.2.3.24.10.1.15.4 Test Vectors N/A Transparent
with the
SMSC
9.2.3.24.10.1.16 Object Distribution Indicator N/A Transparent
with the
SMSC
9.2.3.24.10.1.17 Reply Address Element N/A Transparent
with the
SMSC
9.2.3.24.10.1.18 Extended Object Data Request N/A Transparent
Command with the
SMSC
9.2.3.24.10.2.1 Example of Basic text formatting IN
and predefined EMS coding
9.2.3.24.10.2.2 Example of User defined Objects IN
EMS coding
9.2.3.24.10.2.3 Concatenation of SMS messages FC
9.2.3.24.10.3 EMS Formats FC
9.2.3.24.10.3.1 Sounds FC
9.2.3.24.10.3.2 Pictures FC
9.2.3.24.10.3.3 Animation FC
9.2.3.24.11 RFC 822 E-Mail Header FC
9.2.3.24.12 Hyperlink format element FC
9.2.3.24.13 Identification of a directory number within FC
the User Data Field
9.2.3.25 TP Reject Duplicates (TP RD) FC
9.2.3.26 TP Status Report Qualifier (TP SRQ) FC
9.2.3.27 TP Parameter Indicator (TP PI) FC
9.3 Service provided by the SM RL


9.3.1 General FC
9.3.2 Protocol element repertoire at SM RL
9.3.2.1 RP MO DATA FC
9.3.2.2 RP MT DATA FC
9.3.2.3 RP ACK FC
9.3.2.4 RP ERROR FC
9.3.2.5 RP ALERT SC FC
9.3.2.6 RP SM MEMORY AVAILABLE N/A
10. Fundamental procedures within SMS
10.1 Short message mobile terminated FC
10.2 Short message mobile originated FC
10.3 Alert transfer FC
11. Mapping of error causes between RP layers
11.1 Mobile Terminated short message transfer FC
11.2 Memory available notification FC
11.3 Mobile Originated short message transfer FC
Annex
Annex A (informative): Protocol stacks for IN
interconnecting SCs and MSCs
Annex B (informative): Information now IN
contained in 3GPP TS 23.038
Annex C (informative): Short message IN
information flow
Annex D (informative): Mobile Station reply IN When using
procedures the same
sc_address
for the reply
MO SM, the
replying MO
address
should match
the source
restriction
defined on
the SMSC.
D.1 Introduction FC
D.2 The scope of applicability FC
D.3 Terminology FC
D.4 The reply path requesting procedure FC
D.5 The reception of an original MT SM FC
D.6 The submission of the reply MO SM FC


D.7 Usage of SCs for replying PC When using
the same
sc_address
for the reply
MO SM, the
replying MO
address
should match
the source
restriction
defined on
the SMSC.
D.8 Replying possibilities for Phase 1 mobile stations FC
D.9 The resulting service for originating SMEs FC
Annex E (normative): Extended Object Format FC
Type
E.1. Predefined Sound FC
E.2. iMelody FC
E.3. Black and white bitmap FC
E.4. 2-bit greyscale bitmap FC
E.5. 6-bit colour bitmap FC
E.6. Predefined animation FC
E.7. Black and white bitmap animation FC
E.8. 2-bit greyscale bitmap animation FC
E.9. 6-bit colour bitmap animation FC
E.10. vCard FC
E.11. vCalendar FC
E.12. Data Format Delivery Request FC
E.13. Standard WVG Object FC
E.14. Polyphonic melody FC
Annex F (informative) : Compression methods N/A
for EMS
F.1. LZSS compression N/A
F.1.1 Introduction N/A
F.1.2 LZSS Basic Algorithm N/A
F 1.3 Informative Example. N/A
Annex G (normative): WVG (Wireless Vector FC
Graphics) data format
G.1. Introduction FC
G.1.1 Standard and Character Size WVG elements FC
G.1.2 Compression methods FC
G.1.3 Coordinate Systems FC
G.1.3.1 Compact Coordinate System FC
G.1.3.2 Flat Coordinate System FC
G.1.3.3 Coordinate values FC
G.1.4 Color schemes FC
G.1.5 Rendering model FC
G.2. Graphical elements FC


G.2.1 Line elements FC
G.2.1.1 Polyline FC
G.2.1.2 Circular Polyline FC
G.2.1.3 Bezier Polyline FC
G.2.1.4 Auto-closure of a line FC
G.2.2 Polygon elements FC
G.2.3 Simple shape elements FC
G.2.3.1 Ellipse FC
G.2.3.2 Rectangle FC
G.2.4 Special shape elements FC
G.2.5 Text element FC
G.2.6 Group elements FC
G.2.7 Reuse element FC
G.2.8 Animation elements FC
G.2.8.1 Simple animation elements FC
G.2.8.2 Standard Animation Element FC
G.2.9 Frame Element FC
G.2.10 Local Element FC
G.2.11 Extended Element FC
G.3. Element attributes FC
G.4. Element Transform FC
G.5. Character Size WVG Element FC
G.6. Data Format BNF FC
G.7. Web Safe Color Palette FC
Annex H (informative): Development Guidelines FC
for Creation of Polyphony Using SP-MIDI
H.1. Running status FC
H.2. File type considerations FC
H.3. File size reduction FC
H.4. Restrictions FC
Annex I (informative): Change history IN

15. APPENDICES
15.1. Message Handling Procedure
SM SC M ain Proce s s
Initialize Internal
Buf f ers, Structures, Start
Shared Mem ory
C reate SMSC R etry , R ef resh, Future, Groups,

Processes Em bedded, QueuetoD B Processes
Establish connection to
unconnected GMSC s
(at connect_period )
N ew GMSC
connected?
Y es
C reate SMSC R X SMSC Process

Processes TX SMSC Process No
C onnection
Established with
No SMSC Exit
at least a GMSC
?
N orm al Messages up to m ess ages_winlen

Y es R etry Messages up to retry _winlen
Broadcast Messages
No
Message
R ef erence
R esponse af ter No
N ewMessages
R esponse
Tim eout ?
Y es
Add Av ailable
Y es C hild Exited ?
Messages to TX Queue
Y es
SMSC Exit No
C onf iguration
Period ?
W ait List Tim eout
No
R e-read C onf iguration

F ile
Fig 49 SMSC Main Process

Fig 50 Retry Process

Refresh Process
Start
Routing Table
Period?
Yes
Re-read Routing Table

No
Refresh MT
Messages
Refresh MO-
ESME Messages
Fig 51 Refresh Process

Retry Messages
Start
Select Numbers from

Waiting for Retry
Fetch ? No
Yes
System
Failure? No
Yes
Local
Number (Match
No
Local Address
Range) ?
ESME message
&
Yes No
esme_retry_seq_
Get Retry Delay enabled?
(SMSC Foreign Retry
Sequence) Priority ? No
No Yes
Yes
Get Retry Delay Get Retry Delay

Get Retry Delay
(SMSC Priority Retry (Error Retry or SMSC
(ESME retry Sequence)
Sequence) Retry Sequence)
Retry Sequence
No Yes
Ended ?
Set Next Retry Time Remove Messages
Add Message to Queue
Retry Msg
> Max Retry
Records ?
yes
Fig 52 Retry Messages

Refresh MT Messages Refresh MO-ESME Messages
Start
Start
Select Expired MT
Messages (Normal,
Select Expired MO-
Broadcast)
ESME Messages
Fetch ? No
Fetch ? No
Yes
Last Resort Yes

Address enabled
and active for the
destination ? Remove Message
Add record the

corresponding LRA
queue (FAX/SMTP) Handle Status
Report
Remove Message
Handle Status
Report
Fig 53 Refresh Messages

The Handle Status Report Process is described in Fig 73.

Store and Forward Process
Start
Future Message
No 1
Ready?
Yes
Allow_Embedded
_Cmd
Yes
AR Set For MT?
Yes
Handle Auto-Reply
No
No
Log and Delete

AR Deliver Set? No 1
Message
Yes
Submit SM to
SMSC
Error Error
Ok
1
Wait Future_Time
Fig 54 Store and Forward Process

The Submit SM to SMSC Process is described in Fig 76.
Fig 55 Groups Process

Fig 56 Embedded Commands Process
The Submit SM to SMSC Process is described in Fig 76.

Fig 57 Handle Embedded Command

Queue To Database Process
Start
New Message ?
Yes
Submit SM to
Database
Wait Store_Time
Fig 58 Queue to Database Process (Future Process)
The Submit SM to SMSC Process is described inFig 76.

RX SMSC Process
Start
RX MO Processes (concurrent_rx-mo-num)
Create RX Children
RX MT Processes (concurrent_rx_num)
Message
Sleep Timeout
from GMSC No
Value (ms)
(Timeout) ?
Yes
MT ACK
Handshake MO SUBMIT MT ERROR
ALERT SC
Handshake Add to MO Messages Add to MT Messages

Response Queue Queue
A Child Ended ? No
Yes
Fig 59 RX SMSC Process

Fig 60 RX MO Child Process

Fig 61 RX MT Child Process

Handle SMS Subm it
- Translate MO and MT Addresses

Get message
MO_SUBMIT using RX Translation File
paramaters
- Get MO and MT Prof iles
OK Check MO Prof ile Error MO_ERROR
MO to
MO to ESME No Groups Command No MO to Embedded No
Address Command Addresse
Y es Y es Y es
Submit SM to ESME Handle MO Group Command Handle MO Embedded

Handle MO MT Message
Message Command Message
OK Error OK Error OK Error OK Error
log_mo_acce log_mo_acce log_mo_acce log_mo_acce

log_mo_acce log_mo_acce log_mo_acce log_mo_acce
pted? pted? pted? pted?
pted? pted? pted? pted?
Append MO to Append MO to Append MO to Append MO to Append MO to Append MO to Append MO to Append MO to

smsc DAT f ile smsc DAT f ile smsc DAT f ile smsc DAT f ile smsc DAT f ile smsc DAT f ile smsc DAT f ile smsc DAT f ile
MO_ACK MO_ERROR MO_ACK MO_ERROR MO_ACK MO_ERROR MO_ACK MO_ERROR
Fig 62 Handle SMS Submit
The Check MO Profile Process is described in Fig 74.

Handle MO Group Command SM
Start
Facility not supported
Allow Groups
Command ? No Error
Yes
MS Not SC Subscriber
MO Matches
Groups Cmd No Error
Users ?
Yes
Add Message to
Groups Command Ok
Queue
Fig 63 Handle MO Group Command SM

Handle MO to Embedded Command SM
Start
Facility not Supported
Allow Embedded
No Error
Command ?
Yes
MS Not SC Subscriber
MO Matches
Embedded No Error
Cmd Users ?
Yes
Handle Embedded
Command
Result
Fig 64 Handle MO to Embedded Command SM
The Handle Embedded Command Message Process was described in Fig 57.

Handle MO-MT Message
Start
-Translate MT address
using tx_translation_file
CheckMTProfile
OK
Allow_Embedded
No
_Cmd?
Yes
Error
Embedded CMD
No
in SM?
Submit SM to
Yes SMSC
MO match Ok
embedded_cmd_
users?
MO prepaid and
prepaid post-mo
Yes Error
No checkpoint?
Check Embedded
Cmd
Add record to prepaid

queue
Ok Error
2
Error Error OK Error Error
Fig 65 Handle MO MT Message

HandleMO-MTMessage(contd)
Future
No
command?
AR set for MT
Yes
and AR deliver?
Submit SM to
SMSC Yes
Submit SM to
SMSC
Ok
MO prepaid and
charge prepaid
No
on MO?
Ok Yes Error
Error
Add record to prepaid
queue
No
Handle Auto-Reply
OK Error OK Error
Fig 66 Handle MO-MT Message (contd)
The Check MT Profile and the Submit SM to SMSC processes are described
in Fig 75 and Fig 76 Respectively.

Fig 67 - Handle MT ACK
The Handle Status Report Process is described in Fig 73.

Handle MT Error
Temporaily Errors Permanent and Unhandled Errors

- No Subscriber Reply - Unknown Subscriber
MT_ERROR
- Memory Capacity Exceeded - Illegal Subscriber
- System Failure - Call Barred
Handle Status
Retry Allow Embedded Report
No No
Message ? Command ?
Yes
Delete Message
Forwarding Set No
for MT ?
Yes Yes
Handle Forwarding Set Waiting
Fig 68 Handle MT Error
The Handle Status Report Process and the Set Waiting Process are
described in Fig 73 and Fig 69 respectively.

Set Waiting
Start
Store & Forward

or Direct Modes
ESME originated
Datagram or Forward
No Store Message over the SMPP
Modes ?
interface?
Yes
Handle Status Report

(intermediate
Yes
notification) No
Handle Status Report Delete Message MT in Waiting List ?
No
Yes
Store All Pending Messages

Message priority >
No
Waiting Priority?
Yes
System Failure
Error ?
Yes
MT international (not
matching Local No ESME message? No Priority ?
Routing Expression)? No
Yes Yes
Get Retry Delay

Get Retry Delay Yes
(SMSC Foreign Retry
(ESME Retry Sequence)
Sequence)
Get Retry Delay Get Retry Delay

(SMSC Priority Retry (Error Retry or SMSC Retry
Sequence) Sequence)
Set Next Retry Time Insert / Update Waiting Info
Fig 69 Set Waiting

The Handle Status Report Process is described inFig 73.

TX SMSC Process
Start
based on link_capcaity and

tcap_header_size
MO Responses ? No
No
Yes
Link Capacity
Yes MT Messages ?
Exceeded
No
No Yes
Fill Packet
Link Capacity
No Fill Packet
Exceeded
No Packet Full ?
Packet Full ?
Yes
Yes
Yes
No Data in Packet ?
Yes
MT_DATA
MO_ACK Send Packet to GMSC According to License Rate
MO_ERROR (or Sending Rate) and Link Capacity
Fig 70 TX SMSC Process

Short Message Completion
Start
SMSC Log MT
attem pt or Log
MT Final?
Yes
Log Mes s age into

SMSC Log Filenam e
No
MO/MT m es s age
Mes s age
Succes s fully and No
No
charge_on_error
Received ?
?
Yes
Yes
Charge Prepaid
&
No
prpaid_pos t_m t_
ckpt?
Yes
prepaid not
charged on m o?
No
(prepaid_pos t_m
o_ckpt)?
Subs criber
MO/MT Mes s age
Yes MO to be Charged to be Charged is No
?
Prepaid ?
No
Yes
MO or MT to be
Service to be
Yes Charged Bas ed on Add Record to Prepaid
Charged ?
Service Charging Type Queue
No
Fig 71 Short Message Completion

Status Report Com pletion
Start
Smsc Log MT
attempt or Log
MT Final?
Y es
Log Status
Report?
Y es
No
Log Status Report into

SMSC Log Filename
Charge Prepaid ? No
Y es
Message
Successf ully
Receiv ed within No
charge_status_r
eport_interv al ?
Y es
Subscriber
to be Charged is No
Prepaid ?
Y es
Add Record to Prepaid

Queue
Fig 72 Status Report Completion

Fig 73 Handle Status Report
The Check MT Profile process is described in Fig 75

Check MO Profile
MO and MT
Prof iles
Y es
src_restriction ? No OK
Y es
MO imsi and
src_imsi_range No
def ined?
Y es
check mo imsi check msisdn

against against
src_imsi_range src_routing_expr
regular regular
expression expression
match ? No
Y es
mo_white enabled
No
and MO in white list?
mo_black enabled mt_white

No
and MO in black list? enabled and MT in
MT f rom irregular MO
Y es white list?
Y es
check_prepaid
enbabled and MO is No
an onhold prepaid? No
Y es
MO has a CUG and

MT not in CUG?
Y es
No
Y es
Error Error OK Error
Fig 74 Check MO Profile

Check MT Profile
MO and MT
Profiles
MT Number Digit ? No Error
yes
MT Number dest_restriction
No MT Starts with 0 ? No
< 6? enabled?
No
Yes Error Yes
OK
Yes
MT Matches
No
dest_routing_expr ?
mt_white enabled
No
and MT in white list ?
Yes
mo_white enabled
and MO in MO to
irregular MT white?
mt_black Yes
enabled and MT in No
black list? Yes
No
MT in MO
Blocked User's List ?
No
Yes
Yes
Error Error OK Error
Fig 75 Check MT Profile

Fig 76 Submit SM to SMSC

Fig 77 SMSC Distribution List

15.2. Prepaid charging scenario

The following SDL diagrams describe a possible prepaid charging scenario.
The charging is triggered by the following events:
Arrival of MO-MT messages.
MO-ESME message delivered and accepted by the EMSE.
End of MO-MT message.
End of ESME-MT message.
Successfully delivered status report.
Arrival of MO
MO-MT? No
Yes prepaid_pre_m
o_ckpt?
No
prepaid_pre_m
No
o_ckpt? Yes
Yes charging on
submit message
ESME?
future
message?
submit message
Yes No Yes
prepaid_post_
mo_ckpt?
Pre MO,
Pre MO, Pre MO,
MO_MT
MO_MT MO_ESME
Future
message message
message
Post MO,
MO_MT
message
No No

MO ESME message (accepted)
Service to be
charged?
Yes
Charge based on
ESME service type
No
MT pending for delivery
normal
message?
Yes
prepaid_pre_m
No
t_ckpt?
Yes
send message
SM MT?
No
Yes
(Status report)
No
Pre MT, Pre MT, (background message)
MT SMS MT SR
message message

End of MO MT message
prepaid_post_
No
mo_ckpt?
prepaid_post_
mt_ckpt?
Yes
message
No
delivered
Yes charge failed

Yes messages?
Post MT,
MT SMS
message Yes
Post MT,
MT SMS
message No
No

End of ESME MT message
normal
message?
Yes
prepaid_post_
mt_ckpt?
Yes
message
delivered
Yes
No
(background message)
charged
service?
No
No
Post MT,
MT SMS
message
End of SR message
prepaid_post_
mt_ckpt?
Yes
message
delivered within
interval?
Yes
No
Post MT,
MT SR
No
message

15.3. SMSC History File

The SMSC history file (commonly known as DAT file) contains all Caller
Event Records (CERs). The location of this file is specified by the
administrator in the smsc_log_filename entry of the smsc.ini configuration
file.
The format of the records is:
Record 1 | record_seprator | record 2 | record_seperator |
with record_seperator: 0x0D
Each record has the following format:
Timestamp | field_separator | record_type | field_separator | TLR
with:
Timestamp (hh:mm:ss.mmm): Timestamp when the record was
logged.
Field_seperator (1 character): Separator character as defined by the
administrator (smsc_log_seperator in the smsc.ini).
Record_type :
Record Type Description

0 MT SMS
1 Status Report
2 MO SMS
3 GSM Alert
4 Audit
5 MT CDMA
6 CDMA Delivery Acknowledgement
7 CDMA SMS Read Acknowledgement
8 CDMA SMS User Acknowledgement
9 MO CDMA
10 CDMA Alert
11 MT TDMA
12 MO TDMA
13 TDMA SMS Delivery Acknowledgement
14 TDMA SMS Manual Acknowledgement
TLR: transaction log record

The field_seperator character separates the fields inside of the TLR.
15.3.1. GSM Short Message TLR (MO and MT)

The short message transaction log record will contain the following fields:
Field Format Description

messageid Integer Database short message identification
number (can be 0 if message reached a
final status on FDA)
command [0-11] Type of the command if present:
- 0 No command
- 1 CLIR
- 2 Delivery Report
- 3 Message Status
- 4 Cancel Pending Messages
- 5 Forward
- 6 Auto-Reply
- 7 ALIAS_CMD 7
- 8 Future
- 9 Block
- 10 Last Resort Address

- 11 Priority
status [-1,0,3,4,5,6] Final status of the short message:
- 0 accepted
- 3 delivered
- 4 waiting
- 5 expired
- 6 deleted
- -1 failed
oaddrton [0,1,2,5] Originating address type of number:
- 0 unknown number
- 1 international number
- 2 National number
- 5 Alphanumeric Address
oaddrnpi [0,1,8] Originating address number plan
indicator:
- 0 Unknown numbering plan
- 1 ISDN/Telephone Numbering Plan
- 8 National Numbering Plan
oaddr X(21) Originating address
daddrton [0,1,2,5] Destination address type of number:
- 0 unknown number
- 2 National number
daddrnpi [0,1,8] Destination address number plan
indicator:
daddr 9(21) Destination address
priority [0-1] Priority ranking of the message
rp [0-1] Reply path
sri [0-1] Status report indicator
pid [0-255] Protocol ID (refer to GSM 03.40 for a
complete description)
dcs [0-255] Data coding scheme (refer to GSM 03.38
for a complete description)
scts Date Server centre time stamp
donedate Date Date when message reached a final status
validityperiod Date Validity period of the message
scheddeliverytime Date Scheduled delivery time of the message
(delayed message delivery)
rxaimid Integer ID number of the receiver aim
txaimid Integer ID number of the transmitter aim
msisdn 9(21) MSISDN of the receiving number
mref [0-255] Mobile internal message reference
number
udhi [0-1] User data header indicator
mode [0-3] Short message transmittal mode (ESME-
MT):
- 0 direct mode
- 1 datagram
- 2 transactional
- 3 store-and-forward
error [0-255] Error cause of message delivery failure
service X(5) Service Type used for charging
prepaid [0-7] This flag is set if chargeable address is a
prepaid customer.
Each bit is an indicator:

Bit 0 : postpaid / prepaid indicator

Bit 1: if set, the message needs to be
committed if delivered
(enable_send_commit set in
prepaid_in.ini)
Bit 2 : if set, the message needs to be
cancelled if not delivered
(enable_send_cancel set in prepaid_in.ini)
smsc_dest_table [0,1,2,5] Type of message sending:
- 0,2 normal
- 1,5 background
mt_imsi 9(14) IMSI of the destination number
Message X(280) Contents of the message. Depending on
the data coding and the presence if the
user data header, the message can be in
ascii characters, or in hexadecimal
format. The operator, for security
reasons, can choose to keep this field
empty
aim_type [0-3,255] Type of protocol used to interface
external entities (0 = SMPP, 1 = EMI, 2
= SEMA, 3 = Distribution List)
moServMsc 9(21) MO serving MSC
mtServMsc 9(21) MT serving MSC
cmd_type [0-3] The command type if present:
- 0 activate
- 1 deactivate
- 2 check
- 3 register
mo_imsi 9(14) IMSI of the originating number
User_response 9(8) Amount deducted by RTCG in a successful
transaction
Message_encryption [0-1] Message encryption flag
Retry number Integer Number of times the message has been
retried.
Esmeid Integer Unique message identifier.
Prepaid_seqid 9(14) Sequence Identifier used if message
charged by IN
15.3.2. GSM Status Report TLR

The status report transaction log record will contain the following field:

reportid Integer Status report identification number
msisdn 9(21) MSISDN of the status report requester
status [-1,3,4,5,6] Status of the message:
- 3 delivered
- 4 waiting
- 5 expired
- 6 deleted
- -1 failed
mref [0-255] Reference of the delivered message
tp_status [0-255] Indicates status of a previously submitted
SMS-SUBMIT for which a status report
has been requested:
- 0 message delivered
- 1 message accepted

- 0x46 message expired

- 0x47 message deleted
- 0x62 message waiting
- 0x40 message failed with
permanent error
scts Date Service centre time stamp
raddrton [0,1,2] Recipient address type of number:
- 0 unknown number
- 2 National number
raddrnpi [0,1,8] Recipient address number plan indicator:
raddr Recipient address
messageid 9(21) Short message identification number
imsi 9(14) IMSI of the destination number
servMsc 9(21) Serving MSC
prepaid [0-1] Flag To indicate if the MSISDN is prepaid
or not
Prepaid_seqid 9(14) Sequence Identifier used if the MO
message was successfully charged by IN
15.3.3. GSM/CDMA Alert TLR

The Alert transaction log record will contain the following field:

Msisdn 9(21) MSISDN/MIN number that became
reachable
hlr_address 9(21) HLR address that generated the Alert
sc_address 9(21) Service Centre address storing the
waiting message
15.3.4. Audit TLR

The status report transaction log record will contain the following field:

id Integer Identifier of the user that performed the
action
type [0-1] Type of the user (0 administrator, 1
customer care)
method Web|adm Method used: web or command line
action X(32) Action performed
table X(32) Table affected
description X(1024) Description of the action
15.3.5. CDMA/TDMA Short Message TLR (MO and MT)


messageid Integer Short message identification number
Command [0-11] Type of the command if present:
- 0 No command
- 1 CLIR

- 2 Delivery Report
- 3 Message Status
- 4 Cancel Pending Messages
- 5 Forward
- 6 Auto-Reply
- 7 ALIAS_CMD 7
- 8 Future
- 9 Block
- 10 Last Resort Address
- 11 Priority
Status [-1,0,3,4,5,6] Final status of the short message:
- 0 accepted
- 3 delivered
- 4 waiting
- 5 expired
- 6 deleted
- -1 failed
- 0 unknown number
- 2 National number
indicator:
- 0 unknown number
- 2 National number
indicator:
priority [0-3] For CMD priority ranking of the message:
- 0 normal priority
- 1 interactive priority
- 2 urgent
- 3 emergency
For TDMA, urgency indicator:
- 0 bulk
- 1 normal
- 2 urgent
- 3 very urgent
rp 0 Reply path (not applicable)
sri [0-1] Status report indicator
pid [0-255] Protocol ID
dcs [0-255] Data coding scheme
rxaimid Integer ID number of the receiver aim

txaimid Integer ID number of the transmitter aim

number
udhi [0-1] User data header indicator
mode [0-3] Short message transmittal mode (ESME-
MT):
- 0 direct mode
- 1 datagram
- 2 transactional
- 3 store-and-forward
service X(5) Service Type used for charging
prepaid [0-7] This flag is set if chargeable address is a
prepaid customer.
Each bit is an indicator:
Bit 0 : postpaid / prepaid indicator
Bit 1: if set, the message needs to be
committed if delivered
(enable_send_commit set in
prepaid_in.ini)
Bit 2 : if set, the message needs to be
cancelled if not delivered
(enable_send_cancel set in prepaid_in.ini)
smsc_dest_table [0,1,2,5] Type of message sending:
- 0,2 normal
- 1,5 background
mt_min 9(20) MIN of the destination number
message X(280) Contents of the message. Depending on
the data coding and the presence if the
user data header, the message can be in
ascii characters, or in hexadecimal
format. The operator, for security
reasons, can choose to keep this field
empty
aim_type [0-3,255] Type of protocol used to interface
external entities (0 = SMPP, 1 = EMI, 2
= SEMA, 3 = Distribution List)
cmd_type [0-3] The command type if present:
- 0 activate
- 1 deactivate
- 2 check
- 3 register
mo_min 9(20) MIN of the originating number
privacy Privacy indicator (0 not restricted, 1
restricted, 2 confidential, 3 secret)
reply_option Reply Option indicates whether SMS
acknowledgment is requested
alert_priority Type of alert used to
distinguish different priorities (0 mobile
default, 1 low-priority, 2 medium-
priority, 3 high-priority)
language_ind [0-255] Language indicator
cbni [0-1] Call-back number indicator
cbn_mode [0-15] For CDMA Call back number mode:
- 0 DTMF

- 1 8-bit ASCII
For TDMA, bits 0-1 represent the
screening indicator, and bit 2-3 the
presentation indicator:
Screening indicator values:
- 0 user-provided, not screened
- 1 user-provided, verified and
passes
- 2 user-provided, verified and failed
- 3 network-provided
Presentation indicator:
- 0 presentation allowed
- 1 presentation restricted
- 2 number not available
- 3 reseverd
cbn X(33) Call-back number
display_mode [0-2] For CDMA only, display mode (0
immediate display, 1 mobile default, 2
user invoke)
deposit_index [0-255] Unique index to the content of the
message assigned by the SMSC
multi_encoding [0-1] Multiple encoding indicator
mo_esn Integer Electronic Serial Number of the
originating number
mt_esn Integer Electronic Serial Number of the
destination number
Message_encryption [0-1] Message encryption flag
Esmeid Integer Unique message identifier.
Teleservice Integer Telservice
User_response 9(8) Amount deducted by RTCG in a successful
transaction
Prepaid_seqid 9(14) Sequence Identifier used if message
charged by IN
15.3.6. CDMA/TDMA Delivery Acknowledgment TLR


- 3 delivered
- 4 waiting
- 5 expired
- 6 deleted
- -1 failed
- 0 unknown number
- 2 National number
indicator:

- 0 unknown number
- 2 National number
indicator:
number
prepaid [0-1] If chargeable address is a prepaid
customer
destination number
Message X(280) User Data if present
Teleservive Integer Teleservice
15.3.7. CDMA Read Acknowledgment TLR


- 0 accepted
- 3 delivered
- 4 waiting
- 5 expired
- 6 deleted
- -1 failed
- 0 unknown number
- 2 National number
indicator:
- 0 unknown number
- 2 National number
indicator:


number
customer
originating number
Message X(280) User Data if present
Teleservice Integer Teleservice
15.3.8. CDMA User Acknowledgment / TDMA Manual Acknowledgment TLR


- 0 accepted
- 3 delivered
- 4 waiting
- 5 expired
- 6 deleted
- -1 failed
- 0 unknown number
- 2 National number
indicator:
- 0 unknown number
- 2 National number
indicator:


number
customer
originating number
destination number
deposit_index [0-255] Unique index to the content of the
message assigned by the SMSC
user_response [0-255] Identifier of a predefined response
message X(280) User Data if present
Teleservice Integer Teleservice
15.3.9. Sample TLRs

The following samples have been collected using simulation. Thus, some
fields may be blank or contain invalid values. The decoded TLRs are the
output generated by the admdat command and may not contain the
complete list of fields.
GSM MO-MT with SR

14:23:24.532|2|0|0|0|1|1|9613111111|1|1|9613222222|0|0|1|0|0|2011-03-
29 14:23:24||2011-03-30 14:23:24|2011-03-29
14:23:24|0|0|9613222222|95|0|0|0||1|0||"testing"|0|961123456||0|123456
789101234|0|0|0|2|
14:23:29.739|0|0|0|3|1|1|9613111111|1|1|9613222222|0|0|1|0|0|2011-03-
29 14:23:24|2011-03-29 14:23:29|2011-03-30 14:23:24|2011-03-29
14:23:24|0|0|9613222222|95|0|0|0||1|2|987654321012345|"testing"|0|9611
23456|9614444444|0|123456789101234|0|0|0|2|
14:23:34.939|1|0|9613111111|3|95|0|2011-03-29 14:23:24|2011-03-29
14:23:29|1|1|9613222222|0|123456789101234|961123456|1
Decoded TLRs:
-------------------------
timestamp=14:23:24.532
type=2 GSM MO
messageid=0
command=0
status=0
oaddrton=1
oaddrnpi=1
oaddr=9613111111
daddrton=1
daddrnpi=1
daddr=9613222222
priority=0
rp=0
sri=1
pid=0
dcs=0

scts=2011-03-29 14:23:24
donedate=
validityperiod=2011-03-30 14:23:24
scheddeliverytime=2011-03-29 14:23:24
rxaimid=0
txaimid=0
msisdn=9613222222
mref=95
udhi=0
mode=0
error=0
service=
prepaid=1
smsc_dest_table=messages
msg_encryption=0
message=testing
aim_type=0
mo_imsi=123456789101234
moservmsc=961123456
mt_imsi=
servmsc=
esmeid=2
prepaid_seqid=
-------------------------
type=0 GSM MT
messageid=0
command=0
status=3
oaddrton=1
oaddrnpi=1
oaddr=9613111111
daddrton=1
daddrnpi=1
daddr=9613222222
priority=0
rp=0
sri=1
pid=0
dcs=0
scts=2011-03-29 14:23:24
donedate=2011-03-29 14:23:29
rxaimid=0
txaimid=0
msisdn=9613222222
mref=95
udhi=0
mode=0
error=0
service=
prepaid=1
smsc_dest_table=normal queue
msg_encryption=0
message=testing
aim_type=0
mo_imsi=123456789101234
moservmsc=961123456
mt_imsi=987654321012345
servmsc=9614444444
esmeid=2
prepaid_seqid=
-------------------------
type=GSM MT SR
reportid=0
msisdn=9613111111
status=3
srq=0
mref=95

tp_status=0
scts=2011-03-29 14:23:24
donedate=2011-03-29 14:23:29
raddrton=1
raddrnpi=1
raddr=9613222222
messageid=0
imsi=123456789101234
servmsc=961123456
prepaid=1
-------------------------

GSM MO to unreachable MT
13:41:48.346|2|0|0|0|1|1|9613111111|1|1|9613222222|0|0|1|0|0|2011-03-
31 13:41:48||2011-04-01 13:41:48|2011-03-31
13:41:48|0|0|9613222222|95|0|0|0||1|0||"testing"|0|961123456||0|123456
78910|0|0|0|1|
13:41:53.552|0|31|0|4|1|1|9613111111|1|1|9613222222|0|0|1|0|0|2011-03-
31 13:41:48||2011-04-01 13:41:48|2011-03-31
13:41:48|0|0|9613222222|95|0|0|27||1|2|419031001447475|"testing"|0|961
123456|9656301008|0|12345678910|0|0|0|1|
Decoded TLRs:
-------------------------
type=2 GSM MO
messageid=0
command=0
status=0
oaddrton=1
oaddrnpi=1
oaddr=9613111111
daddrton=1
daddrnpi=1
daddr=9613222222
priority=0
rp=0
sri=1
pid=0
dcs=0
scts=2011-03-31 13:41:48
donedate=
rxaimid=0
txaimid=0
msisdn=9613222222
mref=95
udhi=0
mode=0
error=0
service=
prepaid=1
msg_encryption=0
message=testing
aim_type=0
mo_imsi=12345678910
moservmsc=961123456
mt_imsi=
servmsc=
esmeid=1
prepaid_seqid=
-------------------------
type=0 GSM MT
messageid=31
command=0
status=4
oaddrton=1
oaddrnpi=1
oaddr=9613111111
daddrton=1
daddrnpi=1
daddr=9613222222
priority=0
rp=0
sri=1
pid=0
dcs=0

scts=2011-03-31 13:41:48
donedate=
rxaimid=0
txaimid=0
msisdn=9613222222
mref=95
udhi=0
mode=0
error=27
service=
prepaid=1
msg_encryption=0
message=testing
aim_type=0
mo_imsi=12345678910
moservmsc=961123456
mt_imsi=419031001447475
servmsc=9656301008
esmeid=1
prepaid_seqid=
-------------------------

GSM MO to unreachable MT with conditional forwarding

09:09:30.781|2|0|0|0|1|1|9613111111|1|1|9613222222|0|0|1|0|0|2011-04-
01 09:09:30||2011-04-02 09:09:30|2011-04-01
09:09:30|0|0|9613222222|95|0|0|0||1|0||"testing"|0|961123456||0|123456
78910|0|0|0|4|
09:09:35.889|0|0|0|4|1|1|9613111111|1|1|9613222222|0|0|1|0|0|2011-04-
01 09:09:30||2011-04-02 09:09:30|2011-04-01
09:09:30|0|0|9613222222|95|0|0|27||1|2|123123123123123|"testing"|0|961
123456|9613606060|0|12345678910|0|0|0|4|
09:09:40.989|0|0|5|3|1|1|9613111111|1|1|9613222222|0|0|1|0|0|2011-04-
01 09:09:30|2011-04-01 09:09:40|2011-04-02 09:09:30|2011-04-01
09:09:30|0|0|9613222222|95|0|0|27||1|2|456456456456456|"testing"|0||96
13606060|0|12345678910|0|0|0|4|
09:09:40.989|0|0|5|3|1|1|9613111111|1|1|9613222222|0|0|1|0|0|2011-04-
01 09:09:30|2011-04-01 09:09:40|2011-04-02 09:09:30|2011-04-01
09:09:30|0|0|9613333333|95|0|0|27|FWD|1|2|456456456456456|"testing"|0|
|9613606060|0|12345678910|0|0|0|4|
09:09:46.189|1|0|9613111111|3|95|0|2011-04-01 09:09:30|2011-04-01
09:09:40|1|1|9613222222|4|12345678910|9613606060|1
Decoded TLRs:
-------------------------
type=2 GSM MO
messageid=0
command=0
status=0
oaddrton=1
oaddrnpi=1
oaddr=9613111111
daddrton=1
daddrnpi=1
daddr=9613222222
priority=0
rp=0
sri=1
pid=0
dcs=0
scts=2011-04-01 09:09:30
donedate=
rxaimid=0
txaimid=0
msisdn=9613222222
mref=95
udhi=0
mode=0
error=0
service=
prepaid=1
msg_encryption=0
message=testing
aim_type=0
mo_imsi=12345678910
moservmsc=961123456
mt_imsi=
servmsc=
esmeid=4
prepaid_seqid=
-------------------------
type=0 GSM MT
messageid=0
command=0
status=4

oaddrton=1
oaddrnpi=1
oaddr=9613111111
daddrton=1
daddrnpi=1
daddr=9613222222
priority=0
rp=0
sri=1
pid=0
dcs=0
scts=2011-04-01 09:09:30
donedate=
rxaimid=0
txaimid=0
msisdn=9613222222
mref=95
udhi=0
mode=0
error=27
service=
prepaid=1
msg_encryption=0
message=testing
aim_type=0
mo_imsi=12345678910
moservmsc=961123456
mt_imsi=123123123123123
servmsc=9613606060
esmeid=4
prepaid_seqid=
-------------------------
type=0 GSM MT
messageid=0
command=5
status=3
oaddrton=1
oaddrnpi=1
oaddr=9613111111
daddrton=1
daddrnpi=1
daddr=9613222222
priority=0
rp=0
sri=1
pid=0
dcs=0
scts=2011-04-01 09:09:30
donedate=2011-04-01 09:09:40
rxaimid=0
txaimid=0
msisdn=9613222222
mref=95
udhi=0
mode=0
error=27
service=
prepaid=1
msg_encryption=0
message=testing
aim_type=0
mo_imsi=12345678910
moservmsc=
mt_imsi=456456456456456

servmsc=9613606060
esmeid=4
prepaid_seqid=
-------------------------
type=0 GSM MT
messageid=0
command=5
status=3
oaddrton=1
oaddrnpi=1
oaddr=9613111111
daddrton=1
daddrnpi=1
daddr=9613222222
priority=0
rp=0
sri=1
pid=0
dcs=0
scts=2011-04-01 09:09:30
donedate=2011-04-01 09:09:40
rxaimid=0
txaimid=0
msisdn=9613333333
mref=95
udhi=0
mode=0
error=27
service=FWD
prepaid=1
msg_encryption=0
message=testing
aim_type=0
mo_imsi=12345678910
moservmsc=
mt_imsi=456456456456456
servmsc=9613606060
esmeid=4
prepaid_seqid=
-------------------------
type=GSM MT SR
reportid=0
msisdn=9613111111
status=3
srq=0
mref=95
tp_status=0
scts=2011-04-01 09:09:30
donedate=2011-04-01 09:09:40
raddrton=1
raddrnpi=1
raddr=9613222222
messageid=4
imsi=12345678910
servmsc=9613606060
prepaid=1
-------------------------

ESME-MT message
10:46:19.697|0|16|0|3|0|0|5657|1|1|9613123456|0|0|0|0|0|2011-04-01
10:46:00|2011-04-01 10:46:19|2011-04-02 10:46:00|2011-04-01
10:46:00|0|2|9613123456|0|0|0|0|test|1|2|123123123123123|"testing"|0||
9613606060|0||1|0|0|500000002|
Decoded TLR:
-------------------------
type=0 GSM MT
messageid=16
command=0
status=3
oaddrton=0
oaddrnpi=0
oaddr=5657
daddrton=1
daddrnpi=1
daddr=9613123456
priority=0
rp=0
sri=0
pid=0
dcs=0
scts=2011-04-01 10:46:00
donedate=2011-04-01 10:46:19
rxaimid=0
txaimid=2
msisdn=9613123456
mref=0
udhi=0
mode=0
error=0
service=test
prepaid=1
msg_encryption=0
message=testing
aim_type=0
mo_imsi=
moservmsc=
mt_imsi=123123123123123
servmsc=9613606060
esmeid=500000002
prepaid_seqid=
-------------------------

CDMA MO-MT with DACK

13:50:45.589|9|0|0|0|0|2|5801111111|0|2|5802222222|0|0|1|0|2|2011-03-
09 13:50:45||2011-03-12 13:50:45|2011-03-09
13:50:45|0|0|5802222222|22|0|0|0||0|0||"testing"|0|015FD6||0|580111111
1|0|2|0|0|1|0|0|5801111111|255|0|0|0x0|0x0|0||34825137|4098|0|
13:50:49.466|5|0|0|3|0|2|5801111111|0|2|5802222222|0|0|1|0|2|2011-03-
09 13:50:45|2011-03-09 13:50:49|2011-03-12 13:50:45|2011-03-09
13:50:45|0|0|5802222222|22|0|0|0||0|2|5801234567|"testing"|0|015FD6|05
35E8|0|5801111111|0|2|0|0|1|0|0|5801111111|255|0|0|0x0|0x80d90000|0||3
4825137|4098|0|
13:57:00.799|6|87118452|3|0|2|5802222222|0|2|5801111111|2011-03-09
13:47:46|2011-03-09 13:47:55||2011-03-09
13:47:55|5801111111|17|27|0|4051234567|D65F01|0x80490000|0||4098
Decoded TLRs:
-------------------------
type=9 CDMA MO
messageid=0
command=0
status=0
oaddrton=0
oaddrnpi=2
oaddr=5801111111
daddrton=0
daddrnpi=2
daddr=5802222222
priority=0
rp=0
sri=1
pid=0
dcs=2
scts=2011-03-09 13:50:45
donedate=
rxaimid=0
txaimid=0
msisdn=5802222222
mref=22
udhi=0
mode=0
error=0
service=
prepaid=0
privacy=0
reply_option=2
alert_priority=0
language_ind=0
cbni=1
cbn_mode=0
cbn_ton=0
cbn_npi=0
cbn=5801111111
display_mode=255
deposit_index=0
multi_encoding=0
user_response=0
message=testing
aim_type=0
mo_imsi=5801111111
mo_esn=0x0
moservmsc=015FD6
mt_imsi=
mt_esn=0x0
mtservmsc=

esmeid=0
teleservice=34825137
-------------------------
type=5 CDMA MT
messageid=0
command=0
status=3
oaddrton=0
oaddrnpi=2
oaddr=5801111111
daddrton=0
daddrnpi=2
daddr=5802222222
priority=0
rp=0
sri=1
pid=0
dcs=2
scts=2011-03-09 13:50:45
donedate=2011-03-09 13:50:49
rxaimid=0
txaimid=0
msisdn=5802222222
mref=22
udhi=0
mode=0
error=0
service=
prepaid=0
privacy=0
reply_option=2
alert_priority=0
language_ind=0
cbni=1
cbn_mode=0
cbn_ton=0
cbn_npi=0
cbn=5801111111
display_mode=255
deposit_index=0
multi_encoding=0
user_response=0
message=testing
aim_type=0
mo_imsi=5801111111
mo_esn=0x0
moservmsc=015FD6
mt_imsi=5801234567
mt_esn=0x80d90000
mtservmsc=0535E8
esmeid=0
teleservice=34825137
-------------------------
type=6 CDMA Delivery Ack
id=87118452
status=3
oaddrton=0
oaddrnpi=2
oaddr=5802222222
daddrton=0
daddrnpi=2
daddr=5801111111
scts=2011-03-09 13:47:46
donedate=2011-03-09 13:47:55
validityperiod=

msisdn=5801111111
mref=17
msg_status=27
prepaid=0
mt_imsi=4051234567
mtservmsc=D65F01
mt_esn=0x80490000
dcs=0
message=
teleservice=4098
-------------------------
CDMA MO to unreachable MT
11:52:00.297|9|0|0|0|1|1|4011111111|1|1|4022222222|0|0|1|0|8|2011-03-
29 11:52:00||2011-03-30 11:52:00|2011-03-30
00:00:00|0|0|4022222222|49|0|0|0||0|0||"test"|0|4011111111||0|40111111
11|0|2|0|0|0|0|0||255|0|0|0x0|0x0|0|7|4098|0|
11:52:05.505|5|23|0|4|1|1|4011111111|1|1|4022222222|0|0|1|0|8|2011-03-
29 11:52:00||2011-03-30 11:52:00|2011-03-30
00:00:00|0|0|4022222222|49|0|0|27||0|2|4022222222|"test"|0|4011111111|
4022222222|0|4011111111|0|2|0|0|0|0|0||255|0|0|0x0|0x112d687|0|7|4098|
0|
Decoded TLRs:
-------------------------
type=9 CDMA MO
messageid=0
command=0
status=0
oaddrton=1
oaddrnpi=1
oaddr=4011111111
daddrton=1
daddrnpi=1
daddr=4022222222
priority=0
rp=0
sri=1
pid=0
dcs=8
scts=2011-03-29 11:52:00
donedate=
rxaimid=0
txaimid=0
msisdn=4022222222
mref=49
udhi=0
mode=0
error=0
service=
prepaid=0
privacy=0
reply_option=2
alert_priority=0
language_ind=0
cbni=0
cbn_mode=0
cbn_ton=0
cbn_npi=0
cbn=
display_mode=255
deposit_index=0
multi_encoding=0
user_response=0
message=test

aim_type=0
mo_imsi=4011111111
mo_esn=0x0
moservmsc=4011111111
mt_imsi=
mt_esn=0x0
mtservmsc=
esmeid=7
teleservice=4098
-------------------------
type=5 CDMA MT
messageid=23
command=0
status=4
oaddrton=1
oaddrnpi=1
oaddr=4011111111
daddrton=1
daddrnpi=1
daddr=4022222222
priority=0
rp=0
sri=1
pid=0
dcs=8
scts=2011-03-29 11:52:00
donedate=
rxaimid=0
txaimid=0
msisdn=4022222222
mref=49
udhi=0
mode=0
error=27
service=
prepaid=0
privacy=0
reply_option=2
alert_priority=0
language_ind=0
cbni=0
cbn_mode=0
cbn_ton=0
cbn_npi=0
cbn=
display_mode=255
deposit_index=0
multi_encoding=0
user_response=0
message=test
aim_type=0
mo_imsi=4011111111
mo_esn=0x0
moservmsc=4011111111
mt_imsi=4022222222
mt_esn=0x112d687
mtservmsc=4022222222
esmeid=7
teleservice=4098
-------------------------

15.4. Prepaid History File

The prepaid history file contains all transactions with the prepaid IN. The
location of this file is specified by the administrator in the dat_filename
entry of the prepaid_in.ini configuration file.
The format of the records is:
Record 1 | record_separator | record 2 | record_seperator |
with record_seperator: 0x0D
Each record has the following format:
Timestamp | field_separator | TLR
with:
Timestamp (hh:mm:ss.mmm): Timestamp when the record was logged
Field_seperator (1 character): Separator character as defined by the
administrator (dat_separator in the prepaid_in.ini)
TLR: transaction log record. The field_separator character separates
the fields inside of the TLR.
15.4.1. Prepaid transaction TLR


Pid Integer Process ID of the prepaid that handled the
request
seqid_str X(15) Sequence identifier returned in a
successful response in the SEQID field. It
should be used to correlate the RESERVE
and COMMIT/CANCEL commands
Aparty X(30) A-party address
Bparty X(30) B-party address
Serving MSC X(30) The MO serving MSC GTT
Service X(20) Service type
Amount X(15) Amount returned in a successful response
in the AMOUNT field.
Cmd X(15) Command send to the IN:
- charge
- reserve
- commit
- cancel
status_id Integer Status of the transaction:
- 1 success
- 3 invalid parameter
- 6 Unknown subscriber
- 7 Negative amount
- 9 Unknown command
- 13 same reference error
- 18 TCP timeout
- 19 IN connection problem
- 23 Execution failed
- 24 Missing parameter
- 25 Error subscriber
- 32 committed
- 33 wait for commit
- 255 response to a commit
status X(15) A descriptive status message

Sample prepaid TLR:
00:05:00.616|13446|12140000041494|255682220333|255787706862|254
733000530|1|0|charge|32|COMMITED
00:05:03.547|13439|12110000041311|255783147386|255782989350|393
205843000|1|0|charge|7|NEGATIVE_AMOUNT
15.5. UNIX Regular Expressions

The routing expression is a UNIX extended regular expression. Full
explanations of UNIX regular expressions can be found in section 5 of the
standard on-line UNIX manuals (man 5 regexp).
Some useful regular expression syntax:
Syntax Description
The ^ char is used to represent beginning with, therefore ^1234 should
^1234
be interpreted as MSISDNs beginning with the sequence 1234
The $ char is used to represent ending with, thus 5678$ will match any
5678$
MSISDN ending with the sequence 5678
A combination of ^ and $ at the beginning and end of a regular
expression, is used to specify an absolute address, i.e. this expression
^123456$
matches MSISDNs beginning with and ending with 123456. The only
value ever matched to this should in fact be 123456 itself
The values enclosed within square brackets [ ] denote a character class.
This expression matches MSISDNs ending with any of 1, 3, 5, 7, or 9.
[13579]$ So that this expression matches MSISDNs ending in an odd digit. If a ^
[^13579]$ character is placed within the brackets, then the match is based on any
character not in the specified class; for example [^13579] $ will
correspond to MSISDNs not ending with any of the specified digits.
The hyphen sign defines a range of characters. This expression
[5-9]$
matches MSISDNs ending with 5, 6, 7, 8 or 9
The parentheses are used to enclose a sub-expression within the regular
()
expression.
This is the OR sign and is used to combine two or more regular
| expressions. For example, the expression (^123) | (789$) will match
MSISDNs starting with 123 or ending with 789
When a regular expression matching a single character, a sub-
expression, is followed by an interval expression of the format {m},
{m,} or {m,n}, together with that interval expression it matches
what repeated consecutive occurrences of the regular expression
would match. The values of m and n will be decimal integers in the
{m}
range 0 < m < n <, where m specifies the exact or minimum number of
{m,n}
occurrences and n specifies the maximum number of occurrences. The
expression {m} matches exactly m occurrences of the preceding
expression, {m,} matches at least m occurrences and {m,n} matches
any number of least m occurrences and {m,n} matches any number of
occurrences between m and n, inclusive.
Table 15-1 UNIX Useful Regular Expressions

The Jinny SMSC administrator can check the regular expression syntax
using two command lines:
EREmatch
>EREmatch
Usage: EREmatch [string to match] [Regular Expression]
BRE match
>BREmatch
Usage: BREmatch [string to match] [Basic Regular
Expression]
Example:
src_routing_expr=(^96279[5678]([0-9]{5}$))
The previous regular expression limits all MO addresses to the customers
subscriber list only.

15.6. SMPP Translation Table

For SMPP messages that use the default SMSC alphabet as the value of the data_coding parameter, the following shows the
decimal values used in the body of the message and the corresponding character that will be displayed on the mobile. The
data_coding parameter indicates the encoding scheme of the short message user data.
SMPP Mobile SMPP Mobile SMPP Mobile SMPP Mobile SMPP Mobile SMPP Mobile
0 Space 44 , 88 X 132 Space 176 O 220
1 Space 45 - 89 Y 133 Space 177 + 221 Y
2 Space 46 . 90 Z 134 Space 178 2 222
3 Space 47 / 91 [ 135 Space 179 3 223
4 Space 48 0 92 \ 136 Space 180 224
5 Space 49 1 93 ] 137 Space 181 u 225 a
6 Space 50 2 94 ^ 138 Space 182 226 a
7 Space 51 3 95 _ 139 Space 183 227 a
8 Space 52 4 96 ` 140 Space 184 228
9 Space 53 5 97 a 141 Space 185 229
10 LF 54 6 98 b 142 Space 186 230
11 Space 55 7 99 c 143 Space 187 231 Space
12 PgBrk 56 8 100 d 144 Space 188 232
13 CR 57 9 101 e 145 Space 189 233
14 Space 58 : 102 f 146 Space 190 Space 234 e
15 Space 59 ; 103 g 147 Space 191 235 e
16 60 < 104 h 148 Space 192 A 236
17 Space 61 = 105 i 149 Space 193 A 237 i
18 62 > 106 j 150 Space 194 A 238 i
19 63 ? 107 k 151 Space 195 A 239 i
20 64 @ 108 l 152 Space 196 240 d
21 65 A 109 m 153 Space 197 241
22 66 B 110 n 154 Space 198 242
23 67 C 111 o 155 Space 199 243 o
24 68 D 112 p 156 Space 200 244 o
25 69 E 113 q 157 Space 201 245 o
26 70 F 114 r 158 Space 202 246
27 Space 71 G 115 s 159 Space 203 247 Space

28 Space 72 H 116 t 160 Space 204 248

29 Space 73 I 117 u 161 Space 205 I 249
30 Space 74 J 118 v 162 Space 206 250 u
31 Euro 75 K 119 w 163 Space 207 251 u
32 Space 76 L 120 x 164 Space 208 252
33 ! 77 M 121 y 165 Space 209 253 y
34 78 N 122 z 166 Space 210 254 p
35 # 79 O 123 { 167 Space 211 255 y
36 $ 80 P 124 | 168 Space 212
37 % 81 Q 125 } 169 Space 213 O
38 & 82 R 126 ~ 170 Space 214
39 83 S 127 Space 171 Space 215
40 ( 84 T 128 Space 172 Space 216
41 ) 85 U 129 Space 173 Space 217
42 * 86 V 130 Space 174 Space 218
43 + 87 W 131 _ 175 219
Table 15-2 SMPP Translation Table

15.7. Format strings conversion characters and precision

Each conversion specification is introduced by the character %. After the %, the
following appear in sequence:
Zero or more flags, which modify the meaning of the conversion

specification.
An optional decimal digit string specifying a minimum field width. If the

converted value has fewer characters than the field width, it will be
padded on the left (or right, if the left-adjustment flag `-', described
below, has been given) to the field width. The padding is with blanks
unless the field width digit string starts with a zero, in which case the
padding is with zeros.
A precision that gives the minimum number of digits to appear for the
d, i, o, u, x, or X conversions, the number of digits to appear after the
decimal point for the e, E, and f conversions, the maximum number of
significant digits for the g and G conversion, or the maximum number
of characters to be printed from a string in s conversion. The precision
takes the form of a period (.) followed by a decimal digit string; a NULL
digit string is treated as zero. Padding specified by the precision
overrides the padding specified by the field width.
An optional l (ell) specifying that a following d, i, o, u, x, or X

conversion character applies to a long integer arg. An l before any
other conversion character is ignored.
A character that indicates the type of conversion to be applied.
A field width or precision or both may be indicated by an asterisk (*) instead of a

digit string. In this case, an integer arg supplies the field width or precision. The
arg that is actually converted is not fetched until the conversion letter is seen, so
the args specifying field width or precision must appear before the arg (if any) to
be converted. A negative field width argument is taken as a -flag followed by a
positive field width. If the precision argument is negative, it will be changed to
zero.
The flag characters and their meanings are:
- The result of the conversion will be left-justified within the field.
+ The result of a signed conversion will always begin with a sign (+ or -).
Blank If the first character of a signed conversion is not a sign, a blank will be
prefixed to the result. This implies that if the blank and + flags both appear, the
blank flag will be ignored.
# This flag specifies that the value is to be converted to an "alternate form." For
c, d, i, s, and u conversions, the flag has no effect. For o conversion, it increases
the precision to force the first digit of the result to be a zero. For x or X
conversion, a non-zero result will have 0x or 0X prefixed to it. For e, E, f, g, and
G conversions, the result will always contain a decimal point, even if no digits
follow the point (normally, a decimal point appears in the result of these
conversions only if a digit follows it). For g and G conversions, trailing zeroes will
not be removed from the result (which they normally are).
The conversion characters and their meanings are:

d, i, o, u, x, X The integer arg is converted to signed decimal (d or i), unsigned

octal (o), unsigned decimal (u), or unsigned hexadecimal notation (x and X),
respectively; the letters abcdef are used for x conversion and the letters ABCDEF
for X conversion. The precision specifies the minimum number of digits to appear;
if the value being converted can be represented in fewer digits, it will be
expanded with leading zeroes. (For compatibility with older versions, padding with
leading zeroes may alternatively be specified by prepending a zero to the field
width. This does not imply an octal value for the field width.) The default precision
is 1. The result of converting a zero value with a precision of zero is a NULL string.
f The float or double arg is converted to decimal notation in the style [-]ddd.ddd
where the number of digits after the decimal point is equal to the precision
specification. If the precision is missing, 6 digits are given; if the precision is
explicitly 0, no digits and no decimal point are printed.
e, E The float or double arg is converted in the style [-]d.ddde+ddd, where there
is one digit before the decimal point and the number of digits after it is equal to
the precision; when the precision is missing, 6 digits are produced; if the precision
is zero, no decimal point appears. The E format code will produce a number with E
instead of e introducing the exponent. The exponent always contains at least two
digits.
g, G The float or double arg is printed in style f or e (or in style E in the case of a
G format code), with the precision specifying the number of significant digits. The
style used depends on the value converted: style e or E will be used only if the
exponent resulting from the conversion is less than -4 or greater than the
precision. Trailing zeroes are removed from the result; a decimal point appears
only if it is followed by a digit.
The e, E f, g, and G formats print IEEE indeterminate values (infinity or not-a-

number) as "Infinity" or "NaN" respectively.
c The character arg is printed.
s The arg is taken to be a string (character pointer) and characters from the
string are printed until a NULL character (\0) is encountered or until the number
of characters indicated by the precision specification is reached. If the precision is
missing, it is taken to be infinite, so all characters up to the first NULL character
are printed. A NULL value for arg will yield undefined results.
% Print a %; no argument is converted.
In no case does a non-existent or small field width cause truncation of a field; if

the result of a conversion is wider than the field width, the field is simply
expanded to contain the conversion result. Padding takes place only if the
specified field width exceeds the actual width.

16. DEFINITIONS AND REFERENCES

16.1. Definitions
AIM Application Interface Module
API Application Programming Interface
BHSM Busy Hour Short Messages
CDR Call Detail Record
CPR Customer Provisioning Record
CUG Close User Group
EMI External Machine Interface
EMS Enhanced Messaging Service
ESME External Short Message Entity
ETSI European Telecommunications Standards Institute
FTP File Transfer Protocol
GMSC Gateway Mobile-services Switching Center
GSM Global System for Mobile Communications
GUI Graphical User Interface
HLR Home Location Register
HTML Hyper Text Markup Language
HTTP Hyper Text Transfer Protocol
ISDN Integrated Services Digital Network
JSMSC Jinny SMSC
LAN Local Area Network
MAP Mobile Application Part
MCR Mobile Call Record
MO Mobile Originated
MPU Message Processing Unit
MNP Mobile Number Portability
MSC Mobile Switching Centre
MSISDN Mobile Station ISDN Number
MT Mobile Terminated
NPI Numbering Plan Indicator
OAM Operation, Administration and Maintenance
OTA Over the Air
PLMN Public Land Mobile Network
RX Receive(r)
SIM Subscriber Identity Module
SIU Signalling Interface Unit
SMPP Short Message Peer-to-Peer
SMS Short Message Service
SMSC SMS Center
SM MO Short Message Mobile Originated
SM MT Short Message Mobile Terminated
SNMP Simple Network Management Protocol
SS7 Signalling System Number 7
STP Signalling Transfer Points
TCAP Transaction Capabilities Application Part
TCP/IP Transmission Control Protocol / Internet Protocol
TLR Transaction Log Record
TON Type of Network
TX Transmit(ter)
UDHI User Data Header Indicator

16.2. References
/1/ Digital Cellular Telecommunications System (Phase 2+); Technical
Realization of the Short Message Service (SMS) Point-to-Point (PP)
(3GPP TS 03.40 Version 7.5.0 Release 1998), European
Telecommunications Standards Institute
/2/ Digital Cellular Telecommunications System (Phase 2+); Mobile

Application Part Specification (3GPP TS 09.02 Version 7.14.10,
Release 1998), European Telecommunications Standards Institute
/3/ Short Message Peer to Peer - Protocol Specification, Version 3.4.

Document version: 12-Oct-1999 Issue 1.2, SMPP Developers
Forum
/4/ Smart Messaging - Specification, Revision 3.0.0, Nokia Mobile

Phones Ltd., 2000
/5/ Short Message Service Center - EMI-UCP Interface Specification,

Version 3.5, CMG Telecommunications & Utilities BV, Division
Advanced Technology, December 1999
/6/ Developers Guidelines - Enhanced Messaging Service, First

Edition, Ericsson Mobile Communications AB, May 2001
/7/ Digital Cellular Telecommunications System (Phase 2+); Alphabets

and Language Specific Information (GSM 03.38 Version 7.2.0,
Release 1998), 3rd Edition, European Telecommunications
Standards Institute
/8/ High Density's Glossary of Internet Terms, High Density

Computing, 4 November 2001
/9/ Mobnet Charging in MSC-Description of Record Layouts, Version

SR8, Siemens, 21 January 2000
/10/ Sema SMSC Version G8.1 Open Interface Specification, Sema,

Version 5.8, 18 January 2001
/11/ Jinny SMSC Operation Administration and Maintenance Guide,

Version 3.0, August 2006
/12/ Jinny Filtering Engine 3.0 Techinal Description, Document version

3.0.0, January 2007

JSMSC - TDv3 6 20

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

JSMSC - TDv3 6 20

Caricato da

Copyright:

Formati disponibili

Jinny Short Message

Service Centre 3.6

Trademarks and Registered Trademarks

Release & Document Numbering

Added Informix information and updated

Updated counters in Section 4.8 Jinny Advertising

The subscriber can use the Sponsor

(J), Jinny are trademarks of Jinny Software Ltd.

The distribution of this document is restricted and its contents should be

Copyright 2011 Jinny Software Ltd - Commercial in confidence 5/251

5. Message Handling ...................................................... 45

Copyright 2011 Jinny Software Ltd - Commercial in confidence 6/251

5.1. Short Message Mobile Originated ........................................ 45

Copyright 2011 Jinny Software Ltd - Commercial in confidence 7/251

6.2.7. Send Message .......................................................................... 69

7. Distribution Lists ...................................................... 74

9. Configuration ......................................................... 100

Copyright 2011 Jinny Software Ltd - Commercial in confidence 8/251

9.1.1. Local Configuration ................................................................ 101

Copyright 2011 Jinny Software Ltd - Commercial in confidence 9/251

15.3.2. GSM Status Report TLR ......................................................... 223

Copyright 2011 Jinny Software Ltd - Commercial in confidence 10/251

1. PRODUCT CHANGE LOG

Copyright 2011 Jinny Software Ltd - Commercial in confidence 11/251

Copyright 2011 Jinny Software Ltd - Commercial in confidence 12/251

ESME ESME ESME

SMPP over EMI over SEMA over

OAM System Billing System Prepaid System

Fig 1 Jinny SMSC Context

3.1. SMSC Software

Copyright 2011 Jinny Software Ltd - Commercial in confidence 13/251

3.2. SMSC Modes of Operation

3.3. SMSC Network Architecture

Copyright 2011 Jinny Software Ltd - Commercial in confidence 14/251

4.2. OAM System

Copyright 2011 Jinny Software Ltd - Commercial in confidence 15/251

4.3. Billing System

Copyright 2011 Jinny Software Ltd - Commercial in confidence 16/251

4.4. Prepaid System

Copyright 2011 Jinny Software Ltd - Commercial in confidence 17/251

4.5. External Short Message Entity (ESME) Interfaces

Fig 2 ESME Receiver

Fig 3 ESME Transmitter

Copyright 2011 Jinny Software Ltd - Commercial in confidence 18/251

The handling of the submitted messages depends on three parameters: the

Copyright 2011 Jinny Software Ltd - Commercial in confidence 19/251

Fig 4 below illustrates the Software Description Language (SDL) symbols

Copyright 2011 Jinny Software Ltd - Commercial in confidence 20/251

Copyright 2011 Jinny Software Ltd - Commercial in confidence 21/251

In the ESME diagrams below Submit SM means an ESME client

Fig 5 Handle ESME Submit SM

Copyright 2011 Jinny Software Ltd - Commercial in confidence 22/251

The Check MO Profile and Check MT Profile Processes are described in

Fig 6 - Handle ESME Submit SM (contd)

Copyright 2011 Jinny Software Ltd - Commercial in confidence 23/251

Submit ESME Message

Store & Forward

Store & Forward

Fig 7 Submit ESME Message

Copyright 2011 Jinny Software Ltd - Commercial in confidence 24/251

The SMSC automatically updates its internal routing table periodically

A. Virtual Service Centre

Copyright 2011 Jinny Software Ltd - Commercial in confidence 25/251